#13. Container Orchestration

※ 경기도 x MS 의 클라우드 강의 내용 중 주관적으로 낮설거나 헷갈리는 내용을 정리합니다. 모든 저작권은 최훈성 강사인모가 해당 기관에 있습니다.

Module 1. 쿠버네티스 아키텍처(Kubernetes Architecture)

kubadm vs kubespray

• 요즘은 kubeadm을 많이 사용함

• kubelet, kube-proxy, container-runtime은 worker node에만 필요하다고 잘못생각할 수 있는데, 이 3가지는 master node에도 반드시 필요한 요소 들이다.

• 공식문서 cheat sheet에 completion 관련정보 있음. cka시험시 세팅안되어 있으면 활용

Module 2. 파드(Pod)

• pod가 살아있는지 확인하는 방법 3가지

• 파드 상태 첫확인 언제할래? (initialDelaySeconds)
• 얼마나 자주 상태 확인할래? (periodSeconds)

• pause container는 pod의 안정성을 높여주는 역할을 한다.
• pause container가 1번 pid 역할을 해주어, 다른 컨테이너가 종료되어도 pod는 그대로 존재한다. 만약 pause container가 죽으면 전체 pod가 새로 생성되어, ip도 변경됨
• crictl images 로 pause image를 확인할 수 있다.

• init container는 멀티 컨테이너가 아니다. 멀티컨테이너는 동시에 여러 컨테이너가 떠 있어야 하는데, init은 순서상 본 컨테이너 이전에 떠서 초기화나, 보안목적으로 먼저 설치해야 하는 코드를 관리할 때 사용한다.

• 환경변수 filedPath의 값은 pod를 생성하면 spec 하위에서 볼수 있는 값이다.

멀티컨테이너 디자인 패턴

• Istio가 관리하는 것은 app 컨테이너와 연결된 proxy 컨테이너(sidecar container) 들이다.

• OSI 7계층의 presentation 계층처럼 외부와의 형식을 맞춰준다.

• 쿠버네티스상에서 여러 api가 서로 연결되는 방식, controller가 pod를 찾는방식은 모두 라벨과 관련이 있다.
• 컨트롤러와 파드는 라벨을 통해 loose coupled 될수 있고, 유연한 관리가 가능하다.

• 키값만으로도 파드 선택이 가능하다.
• !key값은 싱글쿼테이션으로 묶어야 에러가 없다.

• nodeSelector는 controller를 통해서 node에 배포되지만, nodeName은 controller 없이 직접적으로 node에 배치된다.

Module 3. 컨트롤러(Controller)

• --cascade=orphan 옵션을 사용하면, pod는 남겨두고 replicaset만 삭제가 가능하다.
• rs이 삭제된후에는 관리하던 pod도 삭제 가능하다. pod에는 controlled by 정보가 있는데, rs를 지우면 이 정보도 삭제된다.
• 다시 rs을 배포하면 삭제해서 부족한 한개만 추가로 생성되고, 기존의 두개의 파드는 rs에 바로 연결된다.

• deployment의 annotation 중 kubernetes.io/change-cause: version 1.16.0
  은 rollout history의 항목으로 보인다.
• yaml을 직접 edit 하여 이미지를 변경하는 경우, annotation도 같이 수정해주어야 history에 이력이 제대로 남는다.
• set image로 이미지 변경을 하는 경우는 --record를 사용하여 이력을 남길수 있다.

• 이미지 변경으로 rollingupdate가 진행되고 있을때 rollout pause를 사용하면, rollingupdate 진행당시 상황에서 멈춘다.
• pause 상황에서 이미지를 다른것으로 다시 업그레이드 해도, 적용이 되지 않는다.
• resume으로 pause를 풀면, 새로운 이미지 생성이 되고, 기존 이미지와, pause로 생성하다 멈춘 이미지가 삭제된다.

• deployment의 배포 전략 중, recreate는 전체 파드를 모두 삭제했다, 다시 만드는 과정을 거치므로, 일시적이라도 다운타임이 발생할수 있다.
• rollingupdate는 배포중, 일시적으로 버전이 섞여서 서비스되는 타임이 존재하므로, 두 버전을 동시에 적용해도 문제가 없는 경우에만 선택하는 것이 좋다.

• rollout history에 --revision 번호를 지정하면 rollout 의 자세한 정보를 볼 수 있다.(실제 배포된 이미지 버전, annotation 정보)
• undo를 이전버전으로 하면 revision 번호는 늘어나고, 돌아가려던 revision번호는 사라진다.
• undo를 계속하면 revision 번호만 늘어나고 최근 두 버전 사이를 돌게 된다.

• 블루그린 배포는 다른버전이 함께 배포되는 문제는 없지만 많은 서버를 유지해야 하는 단점을 지닌다.
• 카나리,블루/그린 배포는 k8s가 공식지원하지 않지만, label전략을 활용해서 쉽게 구현가능하다.

• 블루/그린 배포는 service의 selector label만 변경해주면, 쉽게 blue -> green으로 트래픽을 옮겨서 구현이 가능하다.

• 카나리배포도 selector를 공통과 각각에 두어, selector 변경만으로 가볍게 구현가능하다.

• deployment는 롤링업데이트시 creating이 먼저되지만 ds는 terminating이 먼저된다.
  왜냐하면 ds는 node당 하나씩 생기는 리소스로 creating 되면 배포된 노드가 없기 때문이다.
• OnDelete 옵션으로 업데이트 하는 경우, 데몬셋은 수동으로 기존 파드를 삭제하여야 새롭게 ds가 배포된다.

• activeDeadlineSeconds : 비정상 실행 지나치게 오래 유지되는것을 막는 옵션
  / 이 값 이상 되면 파드 종료후 실패 처리

Module 4. 서비스와 인그레스(Service & Ingress)

• cpu와 memory 할당대상인 pod만이 쿠버네티스에서 인스턴스이다.
• 따라서 svc 리소스는 SPOF 문제는 논의의 대상이 아니다.
• svc의 selector는 Deployment의 이름이 아니라 pod의 이름과 연결된다.

NodePort

• 가상머신의 Inbound에 노드포트의 포트번호를 열어두어야 정상적으로 요청이 가능하다.

• iptables에 0.5 확률로 pod내 가기 때문에 라운드로빈으로 작동

• default는 랜덤 노드로 들어와서 svc를 통해 다른 노드에 존재하는 파드로 요청이 갈수도 있지만, Local으로 지정하면 들어온 노드 내의 pod로 요청을 고정적으로 보내게 된다.

Kube-proxy

• 과거에는 쿠버네티스 파드(ds이 관리) 중 하나인 kube-proxy가 직접 백엔드 서비스에 라우팅을 담당하여 좋지 않은 방법으로 실행되었음

• iptable을 이용하는 방식은 트래픽 처리를 iptable이 처리하기 때문에 처리 성능이 더 좋다.

Module 5. 볼륨(Volume)

• emptyDir은 Pod와 라이프사이클이 같다. 즉 컨테이너가 죽어도 emptyDir은 날아가지 않는다./ 임시저장장시로 머신러닝 학습용데이터 같은거 저장용도로 적합
• hostPath는 pod가 뜨는 노드의 디렉터리에 저장된다. 즉 Node의 생명주기와 함께한다. 노드가 유지되는한 영구적이라고 볼 수 있다.
• emptyDir을 연결된 파드를 배포하면 파드가 배포된 노드위치를 확인한다.
• 해당 노드에서 crictl ps 로 보이는 id를 확인한다.
• crictl inspect id 를 보면 emptyDir로 연결된 경로를 확인할수 있고, 해당 경로에 접근해보면, 컨테이너 내에서 만든 파일이 노드의 해당경로에 존재하는 것을 볼수 있다.
• 당연히 pod를 삭제하면 해당 경로의 파일은 삭제된다.

• hostPath 는 Node의 라이프사이클과 같다

• hostpath type 옵션중 Directory는 연결된 디렉토리가 존재하지 않으면 파드 실행시 에러가 발생한다. 업을때 자동생성을 원하면 DirectoryOrCreate 를 이용하면 된다.

• pod를 삭제해고 다시 배포해도 같은 위치에, 저장해둔 파일이 존재함을 확인할 수 있다.

• pv,pvc를 삭제할때 이를 사용중인 pod가 존재하면, Terminating 상태로 변하지만 삭제는 되지 않는다. 실제 삭제하려면 pod -> pvc -> pv 순으로 삭제해 주어야 한다.

• hostPath의 경로는 pod가 배포되는 Node의 경로이다.
• pv의 Released 상태는 pvc가 삭제되었지만, pv는 아직 초기화되지 않은 상태를 말한다.
• pv의 Failed는 자동 초기화가 실패한 상태를 의미한다.

• manual은 sc를 사용하지 않고, 수동으로 pv를 생성하겠다는 의미이다.

NFS 로 volume 구성

Module 6. 컨피그맵과 시크릿(ConfigMap & Secret)

• 볼륨처럼 쓸수 있으나 volume은 아니다.
• application에서 설정을 분리해, 설정을 참조하는 많은 application의 변경점을 최소화해, 설정변경으로 application의 많은 부분을 수정해야 하는 위험성을 낮춘다. 즉 응집도를 낮춘다.

• 설정파일 전체를 특정 키값 아래에 두도록 할수 있다.

• config맵을 volume으로 사용하면 읽기전용으로 사용된다.
• /config 디렉토리에 키의 이름으로 파일을 생성한다.

Secret

• items 내의 path는 Node의 path 같지만 컨테이너 내의 경로를 생성하는데 쓰인다.

• 도커 이미지를 다운받을때 쓰는 secret을 지정할수 있다 .이때 secret 타입은 docker-registry이다.

Module 7. 스테이트풀셋(StatefulSet)

• volumeClaim도 템플릿을 통해 동적으로 만들어진다.

• statefulset은 각각의 pv를 가지기 때문에, 다른 Pv저장한 내용은 보이지 않는다.
• sts 생성순서 역순으로 삭제된다.

Module 8. 파드 스케쥴링(Pod Scheduling)

• podaffinity : 파드를 배포했을대 개별파드 사이의 관계를 정의하는 용도

• k taint no worker1 color:NoSchedule- 처럼 -로 taint 없앤다
• k taint no worker1 color- 처럼 키값에만 해도 된다.
• k label no worker1 sample=test- 처럼 라벨도 없앨수 있다.
• k lable no worker1 sample- 처럼 키값만 써도 적용된다.

Module 9. 인증과 권한(Authentication & Authorization)

• kube-apiserver의 6443포트는 https의 443포트의 k8s 버전이라 보면된다.
• k get po --v=7 로 k8s api에 요청하는 과정을 볼 수 있다.

• k get po --as system:serviceaccount:default:hpe
• default : ns, hpa : sa
• role 의 get : 개별자원조회
• role 의 list : 여러개 자원 조회

• 클러스터 간 다른 기능을 포함시켜 사용할 수 있다.
• 롤은 네임스페이스에 종속된 리소스라 aggregationRule로 포함시킬 수 없다.

• 1) sa를 만든다 2) k create token sa 로 토큰값을 얻는다.
  3) k config set-credential sa --token = (sa에 토큰값을 지정한다)
  4) sa에 role을 바인딩 한다
  5) k config set-context sa@kubernetes --cluseter= --user=
  로 context를 설정한다.

Module 10. 오토 스케일링(HPA)

• hpa는 새로운 노드가 생성되어야 생성되는 데몬셋에는 적용할 수 없다.

• 테스트 용도에 쓰는 옵션 : --rm, --restart=Never

Appendix. 서비스메시

• 제어플레인이 istiod

• L7계층 분리 가능ㅎ다ㅏ.(쿠키기반, 요청주소기반, subdomain기반 등등)
• 트래픽 제어장애주입, 서킷브레이커, 분산추적,보안(TLS인증)

• ns에도 라벨링 가능하다.
• kiali 로 istio 모니터링 시각화 가능