피터의 개발이야기

ㅁ 들어가며 ㅇ 운영 EKS 업그레이드 작업 시 작성한 작업절차를 정리하였다. ㅁ EKS 업그레이드 테스트EKS 업그레이드 - 1탄: EKS, AddOn - 2탄: WorkNode - 3탄:  kubectl위의 글은 업그레이드를 하기 전에 EKS를 현 버젼으로 구성하여 업그레이드 하는 과정을 테스트하고 그 과정을 정리하였다. ㅁ 신규 Bastion 서버 부팅 ㅇ 신규 EKS를 관리하기 위한 Bastion 서버를 사전 준비하였다. ㅇ [EKS] Amazon EKS 버전 업그레이드, #3 kubectl 설치 또는 업데이트 ㅇ [kubernetes] eksctl 설치 및 zsh bash 쉘 자동 완성 활성화, eksctl 자동완성 ㅇ eksctl 트러블슈팅:     ㄴ bastion에서 eksctl 설치 및..

ㅁ 개요 ㅇ 테스트를 위해 신규 EKS 클러스터를 생성하였다. ㅇ 하지만 기존 EKS 클러스터dml kubeconfig가 남아 있어서 신규 EKS 클러스터와의 config 설정이 실패하였다. ㅇ 기존 kubeconfig를 삭제하고 신규 kubeconfig를 연결하는 과정을 이력남김. ㅁ 신규 클러스터 생성 시 에러 상황 ㅇ 신규 클러스트를 생성하였지만 실패메시지가 확인되었다. ㅇ AWS console에서 확인한 결과 정상 생성이 완료되었다. ㅇ 신규 클러스터의 상태를 확인하기 위해 pod 정보를 조회하여 보았지만 connection 실패가 확인되었다. ㅁ 로컬 use context확인 ㅇ kubectl config get-contexts 명령어를 통해 kubectl context정보를 확인하였다. ㅇ 기..

ㅁ 개요 ㅇ 검수기는 비용절감을 위해 스케쥴로 가동된다. ㅇ Pod들이 ContainerCreating 상태로 교착상태에 빠져 있었고, 이를 해결하는 과정을 걸리하였다. ㅁ 증상 ㅇ 거의 모든 Pod들이 ContainerCreating 상태에서 바뀌지 않고 교착상태에 빠져 있었다. ㅁ Pod 상세 확인 $ kubectl describe pod example_pod ㅇ 위 명령어를 통해 Pod의 이벤트를 확인한다. Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "d423cb5bb261338d384bf2266fbadc05bc074b432319df49b6011c7f954364f3" ..

ㅁ 개요 ㅇ EKS 업그레이드 과정에 대해서 작성한 스크립트를 정리하였다. ㅇ EKS를 핸들링하기 위한 Bastion 서버 구성을 위한 작업 스크립트를 정리하였다. ㅁ 사전구성-1 (PM시작 전에 구성가능) 1. 신규 클러스터 및 kubectl 설치를 위한 신규 Bastion 서버 생성 (0) Bastion userdata 를 기존 Main노드그룹에서 사용하는 userdata 활용하여 적용 (1) 인스턴스 생성 및 ID/PW 로그인활성화, 보안그룹은 기존 Bastion것을 재활용, Disk는 gp3로 30G로 구성 (#중요. 클러스터생성을 위한 인스턴스 IAM을 user아닌 role로 사전세팅할것) (2) EFS Mount 및 Kubectl 설치 (#주의. Kubectl 작업 시에는 root 계정이 아닌..

ㅁ 이전 글 [Kubernetes] 쿠버네티스 볼륨 개념 2편 (pv, pvc, AWS EBS, AWS EFS ) 글에서 EBS와 EFS의 차이를 설명하였다. 이번 글에서는 AWS EKS에 EFS를 연동하는 방법에 대해서 공부하였다. ㅁ AWS EBS와 AWS EFS 차이 EBS는 쿠버네티스 PV 설정 시 ReadWriteOnce(노드 하나에만 읽기쓰기 가능)만 가능하다. 그 이유는 AvailabilityZone에 종속되기 때문에 다른 AZ에 있는 WorkNode에 EBS 스토리지를 공유할 수 없다. 쿠버네티스의 철학에 시스템 이중화를 위해 2개 이상의 AZ에 WorkNode을 생성하게 되면 작업 상 공유가 필요한 파일이 있는 경우 EFS를 활용해야 한다. AWS EFS를 사용하기 위해서는 EFS CSI..

ㅁ 개요 현재 [EKS] Amazon EKS 클러스터(v1.20)에서 Kubernetes v1.22로 업그레이드 진행 중이다. (관련 글은 여기) 세부적으로 사용 중인 Ingress 객체를 업그레이드 하면서 ingress controller 무중단 업데이트를 테스트 중이다. 그 과정에서 운영 적용 시 최적화를 위해 시뮬레이터 테스트 환경을 구축하여 무중단 업그레이드 테스트를 진행 중 Spring boot DNS Cache 이슈를 겪게 되어 그 과정을 정리하였다. ㅁ NLB + ingress controller(ALB) 이중화를 이용한 업데이트 시나리오 우선 ingress controller 업그레이가 필요한데, 이 부분은 여기를 참조하여 이해가 필요하다. 외부에서 들어오는 트래픽이 ingress cont..

1편 kubernetes에게 Etcd란? kubernetes 백업의 필요성 Etcd의 백업 및 복구(Backup and Restore) Etcd의 백업의 두가지 방법 2편 etcd 내장 스냅샷 3편 Velero를 이용한 AWS EKS 백업 복구 방법 ㅁ 개요 ㅇ 지난 시간 Etcd 내장 스냅샷 기능에 대해서 실습하는 과정을 정리하였다. ㅇ 이번 글에서는 Velero를 이용한 AWS EKS 백업 복구 방법을 정리하도록 하겠다. ㅁ EKS Cluster ㅇ 백업 대상이 되는 EKS Cluster이다. ㅁ WorkNode Scale Out $ eksctl scale nodegroup --name=work-nodes --cluster=k8s-peterica --nodes=1 --nodes-min=1 --node..

ㅁ 개요 ㅇ 지난 시간 kubernetes에게 Etcd란, 백업과 복원을 위한 2가지 방법에 대해서 알아보았다. ㅇ Etcd 내장 스냅샷 기능에 대해서 실습하는 과정을 정리하였다. ㅇ 테스트환경은 minikube 환경을 사용하였다. ㅇ 테스트는 스냅샷을 생성하고 테스트 Pod를 삭제 후 스냅샷 복구하여 삭제된 Pod를 복구하려 한다. ㅇ 결론적으로 minikube 환경에서는 etcd가 pod타입이어서 복구가 불가하였다. ㅇ 하지만 그 과정과 다른 참조페이지를 정리하였다. 1편 kubernetes에게 Etcd란? kubernetes 백업의 필요성 Etcd의 백업 및 복구(Backup and Restore) Etcd의 백업의 두가지 방법 2편 etcd 내장 스냅샷 3편 Velero를 이용한 AWS EKS 백..

ㅁ 개요 AWS EKS 백업을 하는 방법을 공부하였다. 공부의 목적인 EKS 백업을 위한 방법을 찾기 위한 목적이었지만, 레퍼런스 검증단계에서 etcd 내장 스냅샷 기능으로는 AWS EKS를 백업할 수 없었다. 그래서 대안으로 Velero를 이용한 EKS 백업 및 복구하는 방법까지 정리하게 되었다. 공부가 진행되면서 글이 길어져서 Etcd의 개념과 백업 복구의 필요성에 대해서 설명하고 etcd 백업하는 두가지 방법에 대해서 총 3편으로 글을 쓰게 되었다. 1편 kubernetes에게 Etcd란? kubernetes 백업의 필요성 Etcd의 백업 및 복구(Backup and Restore) Etcd의 백업의 두가지 방법 2편 etcd 내장 스냅샷 3편 Velero를 이용한 AWS EKS 백업 복구 방법 ㅁ..

ㅁ 개요 ㅇ 자주 사용하는 eksctl 명령어를 저장하기 위한 글이다. ㅇ 사용했던 명령어를 조금씩 업데이트하고 있다. ㅁ EKS 클러스터 생성 eksctl create cluster --name k8s-peterica \ --region ap-northeast-2 \ --version 1.21 \ --nodegroup-name work-nodes \ --nodes 1 \ --nodes-min 1 \ --nodes-max 3 \ --node-type t3.medium \ --node-volume-size=20 \ --with-oidc \ --ssh-access \ --ssh-public-key aws-login-key \ --managed ㅁ 노드그룹 scale 조정 [ec2-user@ip-172-31-..