kubernetes 내부

20 May 2019

컨트롤 플레인 컴포넌트

etcd

생성한 모든 오브젝트(포트, 레플리케이션컨트롤러, 서비스…)는 API 서버가 다시 시작하거나 실패하더라도 생존하기 위해 어딘가에 영구적으로 저장해야 합니다. 이를 위해 쿠버네티스는 빠르고, 분산되며, 일관된 키 값 스토리지인 etcd를 사용합니다.

etcd와 직접 통신하는 유일한 컴포넌트는 쿠버네티스 API 서버입니다.

API server

모든 컴포넌트와 kubectl 같은 클라이언트가 사용하는 중앙 컴포넌트입니다. 또한 RESTful API를 통해 클러스터 상태를 쿼리 및 수정할 수 있는 CRUD 인터페이스를 제공합니다. 그 상태를 etcd 안에 저장합니다.

객체의 유효성 검사 수행하여 잘못 구성된 객체가 저장되는 것을 막고 낙관적인 잠금도 처리하여 동시 업데이트를 방지합니다.

낙관적 동시성 제어: 데이터를 잠그고 읽지 못하도록 하는 것이 아니라 데이터가 업데이트되면 해당 조각에 버전 번호를 포함하여 관리합니다. 데이터가 업데이트됐을 때 버전 번호는 증가하고 데이터를 읽은 시간과 업데이트가 요청된 시간 사이에 버전 번호가 증가했다면 클 업데이트를 거절합니다.

스케줄러

API 서버의 감시 메커니즘을 통해 새롭게 생성된 포드를 기다리고 노드에 아직 할당되지 않은 새로운 포드를 노드에 할당합니다.

컨트롤러 매니저

API 서버를 통해 배포된 리소스에 지정된 대로 시스템의 실제 상태가 원하는 상태로 수렴되는지 확인합니다.

컨트롤러 매니저 프로세스는 다양한 조정 작업을 수행하는 다수의 컨트롤러로 결합되어 있습니다.

컨트롤러는 API 서버에 연결하고 감시 메커니즘을 사용해 컨트롤러가 책임지는 리소스의 목록에 변화가 감지됐을 때 통지합니다.

워커노드

Kubelet

워커노드에서 실행되는 모든 것에 책임을 가지는 컴포넌트입니다.

• API 서버에 노드를 등록하고 스케줄됐던 포드에 대해 API 서버를 모니터합니다.

• 포드의 컨테이너를 관리하고 지속적으로 실행 중인 컨테이너를 모니터링하고 상태와 이벤트, 리소스의 소모를 API 서버에 보고합니다.

• 컨테이너 라이브니스 프로브를 실행하는 컴포넌트이며 프로브에 오류가 발생했을 때 컨테이너를 다시 시작합니다.

Kube-proxy

쿠버네티스 API를 통해 정의한 서비스에 클라이언트가 연결할 수 있도록 합니다.

서비스가 둘 이상의 포드로 백업되면 프록시는 해당 포드에서 로드 밸런싱을 수행합니다.

애드온

애드온은 클러스터 내부에서 필요한 기능들을 위해 실행되는 포드들입니다. 애드온에 사용되는 포드들은 디플로이먼트, 리플리케이션컨트롤러, 데몬 세트 등에 의해 관리됩니다. 애드온이 사용하는 네임스페이스는 kube-system입니다.

DNS 서버

클러스터의 모든 포드는 클러스터의 내부 DNS 서버를 사용하도록 구성됩니다.

쿠버네티스에서 사용하는 내부 도메인은 서비스와 포드에 대해서 사용할 수 있고 일정한 패턴을 가지고 있습니다.

• service 접근 domain: ..svc.cluster.local

• pod 접근 domain: <10-10-10-10(pod ip의 .을 -로 변경)>..pod.cluster.local

  • pod ip를 그대로 사용하면 도메인 네임을 사용하는 장점이 사라집니다.

• subdomain 사용

  apiVersion: v1
  kind: Deployment
  ...
  template:
   ...
   spec:
    hostname: hname
    subdomain: subname
  

  subdomain 접근: ..default.srv.cluster.local

  Ex) hname.subname.default.srv.cluster.local

DNS 서버 포드는 kube-dns 서비스를 통해 익스포트하고 다른 포드들터럼 포드가 클러스터상에서 이동할 수 있습니다.

서비스의 IP 주소는 클러스터에 배포되는 매 컨테이너 내부의 /etc/resolv.conf 파일의 nameserver에 지정됩니다.

서비스 구현 방식

Kube-proxy

서비스와 관련된 모든 것은 각 노드에서 실행되는 kube-proxy 프로세스에 의해 처리됩니다.

초기에 kube-proxy는 연결을 기다리는 실제 프록시(userspace 프록시 모드)였지만 성능이 더 우수한 iptables 프록시 모드로 교체되었습니다.

각 서비스는 고유의 안정된 IP주소(가상 IP)와 포트를 가집니다.

pod에서 pod 통신

1. 패킷의 목적지는 처음에 서비스의 IP와 포트로 설정됩니다.

2. 네트워크로 보내지기 전에 패킷은 먼저 노드에 설정된 iptables 규칙에 따라 노드 A의 커널에 의해 처음 처리됩니다.
3. 커널은 패킷이 iptables 규칙 중 하나와 일치하는지 확인합니다. 일치하는 규칙이 있으면 패킷의 목적지 IP와 포트를 무작위로 선택된 포드의 IP와 포트로 대체합니다.