K8s 초보를 위한 쿠버네티스 안내서(44bits) 정리

유데미 CKA 강의를 듣기 전에 한글로 친절히 설명된 44BITS의 유튜브 강의를 먼저 듣고 개념을 정립해 두고 싶었다.

• 유튜브 링크: link

---

필요한 이유

• 컨테이너 형태로의 환경제약이 적은 자유로운 배포 및 운영관리
• aws로 치면 서버 개별 실행, 매핑, 스토리지 설정, 로드 밸런싱, 웹서버에 프록시 연결 등등
• devops는 더 빠르고 안전하게 서비스나 애플리케이션을 배포 제공하는 것인데 k8s 를 통해서 이를 달성할 수 있음

실습

• 코드 수정을 반영해 다시 배포하면 기존 것은 남아있고 새로운 컨테이너가 떠서 블루그린 배포를 진행한다
• 쿠버네티스의 상태관리
  • desired state 다음 3개 사이클 반복
    • 상태 체크
    • 차이점 발견
    • 조치

• scheduler: 서버 자원 확인 
• controller: 컨테이너 상태 확인 (healthy status)

• 구성
  • 마스터
    • 각종 상태확인 등의 체크
      • 상태저장 및 조회에 etcd 사용
    • 실행 명령
  • 노드
    • 명령을 실행하는 주체

---

마스터 상세

1. etcd

• 모든 상태와 데이터를 저장
• 고가용성 추구 (분산 시스템)
• 가볍고 빨라야함

  2. API Server

• 상태를 바꾸거나 조회
• 유일하게 etcd와 통신한다(REST api 형태)
• kubectl말고도 다른 내부 모듈들과 소통

  3. Scheduler

• 새로 생성된 pod를 감지하고 실행할 노드를 결정
• 노드의 현재 상태와 Pod의 요구사항을 체크 -> 서버 자원 확인

  4. Controller

• 논리적으로 다양한 컨트롤러 존재
• replica 컨트롤러, 엔드포인트 컨트롤러, 노드 컨트롤러
• 끊임없이 상태를 체크하고 원하는 상태를 유지
• 복잡성을 낮추기위해 하나의 프로세스로 실행

마스터 조회 흐름

컨트롤러 - API Server - etcd

• 컨트롤러가 api서버에 현재 상태 조회 요청
• 컨트롤러의 권한 확인하고 상태 전달
• 컨트롤러가 원하는 상태로 변경됐을 경우 이 또한 전달

노드 - kubelet

• 역시 Api server랑만 통신
• CRI 덕분에 docker뿐 아니라 다른 여러 컨테이너 런타임을 통해 컨테이너를 control할 수 있음

  노드 - proxy

  

• 역시 Api server랑만 통신

전반적 그림

추가 컴포넌트 (addons)

• 네트워크(cni) 및 dns 

쿠버네티스 오브젝트

Pod(팟)

• 가장 작은 배포 단위
• 컨테이너를 직접 관리하지 않고 pod이라는걸로 감싸서 관리(즉, 컨테이너를 배포하는게 아니라 팟을 배포하는 것)
• 전체 클러스터에서 고유한 ip를 할당함
• 여러개의 컨테이너가 하나의 팟에 속할 수 있음 (localhost와 port로 공유 및 통신가능)

레플리카셋(ReplicaSet)

• 신규 pod는 pod template을 참조해서 생성

  Deployment

  

• 버젼을 업데이트하면 롤링 업데이트가 일어난다

• 별도로 deployment만의 버젼 관리 기법이 존재하여 버젼별 개수 조절 및 관리가 가능한 게 아니라 ReplicaSet을 활용하여 개수 조절을 수행하는 것

기타 Workloads

데몬셋

• 모든 pod에 하나씩은 떠잇길 바라는 팟을 만들고자 할 때 설정하는 것 (ex. logging, 모니터링) Stateful Sets
• 순서대로 팟을 실행하고 싶거나 같은 볼륨을 계속 재활용하고 싶을 때 Job
• 한 번 실행하고 죽는 단발성 배치 프로세스

서비스

ClusterIP

• 네트워크도 별도의 서비스로 오브젝트로 관리한다

• 팟 상위 단위에서 내부 팟들로의 트래픽 로드밸런싱을 수행하는 서비스

• cluster ip로 요정을 보내면 3개의 팟 중 하나로 전달됨

• 팟은 스케일링되며 내부 ip가 계속 바뀔 수 있지만 클러스터 ip는 고정이다

NodePort

• 클러스터 ip는 팟과 클러스터 내부에서 통신하는 내부망이다. 외부에 노출되어 밖에서 접근 가능하기 위해서는 NodePort 서비스를 이용해야함 (ECS 서비스는 ALB로 빼서 하나의 public ipv4 를 갖지만 서비스 구성 인스턴스들은 변동적인 ip를 갖고 scalable하게 움직이는 것과 유사)
• 노드에 포트가 생기고 해당 위치로 통신 가능

• web -> node port -> cluster ip -> pod

• 어떤 노드로 보내도 알아서 클러스터 ip리다이렉트해줌

Load Balancer

• 노드포트 달아 public 접근 가능하게 만들어도 노드가 죽으면 서버 접속 안됨. 노드1번이 죽을때 해당 노드포트와 연결해놓았으니 새 노드가 뜨고 다시 붙게하기 위해서는 설정이 필요함.
• lb를 통해서 이를 해결

Ingress

• 도메인 이름이나 path를 활용해 라우팅가능
• 기존에 이미 존재하는 nginx haproxy alb 를 k8s에 맞게 재활용해서 사용함

일반적인 구성

• 팟만 쓰는 경우는 없다. 버젼관리 deployment로 감싸 자동 pod 개수 관리되는 ReplicaSet 쓰고 서비스로 감싼 뒤 ingress로 라우팅
• ingress붙이면 lb와 node port는 자동으로 따라옴

API 호출

• yaml에 기재된 내용 따라 Api 서버 실행
  • API서버가 정보를 etcd에 저장
  • 각 컨트롤러는 지속적으로 자기 상태를 확인하던 도중 etcd에 신규 할당된 pod이 있음을 알게되고 올린 뒤 올렸다는 상태를 추적해 API 서버에 전달 및 etcd에 기록
• 각 api version에 따라 spec이 다름

API를 호출한다는것?

ReplicaSet flow sample

---

+cka 공부하기 전 맛보기로 보았으나 생각보다 강의가 좋았다.