Cluster, Node Version Upgrade 하기
0. eksctl, kubectl의 차이
-. 기본적으로 EKS를 사용하면서 사용하는 명령어는 eksctl, kubectl을 사용한다.
-. eksctl : AWS 인프라를 관리한다고 생각하면 된다. Cluster, Node 관리를 한다.
-. kubectl : Node들을 관리하는 명령어.
-. 어떠한 환경도 마찬가지겠지만 모르겠으면 --help 명령어를 적극 활용하면 매우 좋다.
-. EKS 버전 업그레이드는 정해진 버전을 맞춰야 한다.
1. 순서
1) kubectl get nodes
2) eksctl get node
3) eksctl upgrade cluster --name <my-cluster> --approve --version 1.1x --region ap-northeast-2
4) 'kube-proxy', 'CoreDNS', 'CNI' 버전 업그레이드
5) Worker Node Upgrade
크게 위 순서로 작업한다고 생각하면 됩니다.
2. 클러스터, 노드 버전 확인
-. 클러스터 버전
kubectl version --short
-. 노드 버전
kubectl get nodes
3. 클러스터 업그레이드
eksctl upgrade cluster --name <my-cluster> --approve --region ap-northeast-2 \
--version 1.1x> 업그레이드 완료 후 'kubectl version --short'를 통해 확인
4. Kube-proxy, CoreDNS, CNI 버전 업그레이드
-. Kube-proxy 버전 확인
kubectl get daemonset kube-proxy --namespace kube-system -o=jsonpath='{$.spec.template.spec.containers[:1].image}'
-. Kube-proxy 버전 업그레이드
kubectl set image daemonset.apps/kube-proxy \
-n kube-system \
kube-proxy=602401143452.dkr.ecr.ap-northeast-2.amazonaws.com/eks/kube-proxy:v1.15.11-eksbuild.1
-. CoreDNS 버전 확인
kubectl describe deployment coredns --namespace kube-system | grep Image | cut -d "/" -f 3
-. CoreDNS 버전 업그레이드
kubectl set image --namespace kube-system deployment.apps/coredns \ coredns=602401143452.dkr.ecr.us-west-2.amazonaws.com/eks/coredns:v1.8.0-eksbuild.1
-. CNI 버전 확인
kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2
-. CNI 버전 업그레이드
curl -o aws-k8s-cni.yaml https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/v1.7.5/config/v1.7/aws-k8s-cni.yaml
sed -i -e 's/us-west-2/ap-northeast-2/' aws-k8s-cni.yaml
kubectl apply -f aws-k8s-cni.yaml> yaml파일로 다운로드 후 업그레이드 하는 방식
----------------------------------------
위 버전들은 혼합되어있으나, 실제 버전은 맨 위와 같이 버전을 맞춰야 합니다.
5. Worker Node Upgrade
eksctl create nodegroup \
--cluster <my-cluster> \
--version <version> \
--name <node-name> \
--node-type m5.xlarge \
--nodes 6 \
--nodes-min 6 \
--nodes-max 6 \
--node-ami auto \
--node-private-networking \
--node-volume-size=30 \
--ssh-access --ssh-public-key=<key-name> \
--region ap-northeast-2> 10분 이상 소요됩니다. 6개 노드를 기준으로 했을 때.
6. cordon, taint
kubectl cordon ip-10-10-10-10.ap-northeast-2.compute.internal \
ip-10-10-10-11.ap-northeast-2.compute.internal\
ip-10-10-10-12.ap-northeast-2.compute.internal> 이렇게 cordon 명령어를 띄어쓰기로 구분하여 한번에 여러개 명령할 수 있습니다.
-. taint 명령 후 'kubectl get nodes'를 입력해보면 아래와 같습니다.
*cordon 명령어는 기존 파드에는 영향을 안주면서 스케줄링을 비활성화 하는 역할을 합니다.
kubectl taint nodes node1 key1=value1:NoSchedule-. taint 명령어로 스케줄링을 정지합니다.
-. cordon은 파드가 스케줄링되지 않도록 하며, taint가 적용된 노드에는 신규 스케쥴은 진행되지 않습니다. 따라서 위 화면을 기준으로 새로 생성된 노드로만 스케쥴이 진행됩니다.
*************
작업간 주의사항 (1)
kubectl get pods -o wide # 해당하는 네임스페이스 내 모든 파드의 상세 목록 조회
kubectl get pods --all-namespaces # 모든 네임스페이스 내 모든 파드의 목록 조회
을 입력하며 정상적으로 pods가 동작하는지 확인할 필요가 있으며,
이상이 있는 pods는
kubectl describe pods <my-pod> 명령어를 통해 어떤 문제가 발생했는지 살펴볼 필요가 있습니다.
작업간 주의사항 (2)
위에서 업그레이드하는 시스템(CoreDNS, CNI, Kube-proxy)과 ingress 설정(위에는 표기하지 않았으며, 추후 공부하며 다시 작성 예정)은 변경 전 kubectl get <블라블라~~~ 조회하고 싶은것> -o yaml > 파일명.yaml 형식으로 백업해두는 것을 추천합니다.
문제 발생 시, apply -f 를 통해 롤백 가능하기 때문.