[쿠버네티스] 쿠버네티스 내부 이해

쿠버네티스 아키텍처

 

 

쿠버네티스의 주요 컴포넌트

컨트롤 플레인 (마스터 노드)	워커 노드
etcd 분산 스토리지	Kubelet
api 서버	쿠버네티스 서비스 프록시 (Kube-proxy)
스케줄러	컨테이너 런타임 (Docker, rkt, …)
컨트롤 매니저
클라우드 컨트롤러 매니저

 

 

 

쿠버네티스 컴포넌트 간 커뮤니케이션 방법

오직 API 서버를 통해 통신

 

API 서버

• 모든 컴포넌트와 클라이언트(ex. kubectl)가 사용하는 중앙 컴포넌트
• RESTful API를 통해 클러스터 상태를 쿼리 및 수정할 수 있는 CRUD 인터페이스 제공
  • 그 상태를 etcd에 저장
• 포드 등 오브젝트의 변경 요청이 들어올 경우 요청사항을 etcd에 저장하고 모든 감시자들(클라이언트들)에게 갱신된 오브젝트를 전달

 

ETCD

• 포드, 레플리카셋, 서비스, 시크릿 등 쿠버네티스 클러스터 상태 및 메타 데이터를 영구적으로 저장
• key value 저장소. 분산 스토리지
• 강력한 낙관적 잠금 시스템과 유효성 검사 시스템 : RAFT 합의 알고리즘

https://itnext.io/how-etcd-works-in-kubernetes-e18adf97d24d

How etcd works in Kubernetes

 

 

API 서버 접근 제어

• 사용자의 경우 : kubectl, 클라이언트 라이브러리, REST 요청
• Pod의 경우 : Service Account를 통해 접근

1. 클라이언트 인증 : 클라이언트 신원 확인
   1. ex) Bearer Token, Client Certificates, OIDC, Basic Authentication
2. 권한 승인 : 인증된 사용자가 요청된 액션을 요청된 리소스에 대해 수행할 수 있는지 결정
   1. ex) RBAC, ABAC
3. 요청 받은 리소스를 확인/수정
   1. 리소스 생성/수정/삭제 요청일 경우 3번 과정 수행
   2. ex) AlwaysPullImages, ServerAccount, NamespaceLifeCycle, ResourceQuota
4. etcd에 저장 후 클라이언트에 응답

https://kubernetes.io/ko/docs/concepts/security/controlling-access/

쿠버네티스 API 접근 제어하기

 

https://velog.io/@jean1042/Kubernetes-API-Server-%EB%B3%B4%EC%95%88-Securing-API-Server

Kubernetes : API Server 보안 (Securing API Server)

 

 

 

스케줄러

• API 서버의 감시 메커니즘을 통해 새롭게 생성된 포드를 기다리고 노드에 아직 할당되지 않은 새로운 포드를 노드에 할당
• 필터링, 스코어링 2단계 작업을 통해 포드를 띄울 최적의 노드 선택
• 선택된 노드에 지시하는 것이 아니라 API 서버를 통해 포드의 정의를 업데이트 함
  • 클라이언트에서 api서버로 포드 업데이트 요청 → api서버: 스케줄러에 포드 업데이트 요청 통지 → 스케줄러: 포드 업데이트 정의 → api서버: kubelet에 포드 업데이트 통지 → 대상 노드의 kubelet: 포드 생성 및 실행

 

컨트롤러

• 컨트롤 루프 시스템으로 리소스 상태를 지속적으로 모니터링
• 컨트롤러 매니저에서 실행됨
• 리소스의 변경을 감시, 새로운 오브젝트를 생성하거나 갱신, 삭제 등 변경을 위한 동작을 수행
• 컨트롤러 간 통신 X. 서로 알지도 못함. kubelet과도 직접 통신X. 오직 API 서버를 통해서만 동작
• 주요 컨트롤러 : replication controller, endpoints controller, namespace controller, and serviceaccounts controller

 

 

Kubelet

• 모든 워커노드에서 실행
• 워커노드에서 실행되는 모든 것에 책임을 가지는 컴포넌트
• 컨테이너 런타임을 통해 컨테이너를 실행. 실행 중인 컨테이너를 모니터링하여 API 서버에 보고

쿠버네티스 서비스 프록시 (kube-proxy)

• 모든 워커노드에서 실행
• 쿠버네티스 클러스터에서 서비스와 관련된 네트워킹 관리 컴포넌트
• API 서버와 통신하며 클러스터 내의 포드 간 네트워크 통신을 가능하게 해줌
• 다양한 방식으로 서비스를 외부에 노출하고, 서비스가 연결된 포드로 트래픽을 라우팅
• 운영 모드
  • userspace 모드: 오래된 방식으로, Kube-proxy가 사용자의 공간에서 직접 트래픽을 라우팅하는 방식. 성능이 떨어지기 때문에 현재는 주로 테스트나 디버깅 용도로 사용
  • iptables 모드: Kubernetes 클러스터의 iptables를 사용하여 서비스의 트래픽을 Pod로 라우팅. 효율적이고 높은 성능을 제공
  • https://coffeewhale.com/k8s/network/2019/05/11/k8s-network-02/

[번역] 쿠버네티스 네트워킹 이해하기#2: Services

 

 

애드온 (Add-ons)

• 쿠버네티스 클러스터의 기능을 확장하거나 특정 작업을 자동화하기 위해 클러스터에 추가되는 컴포넌트 or 서비스
• ex) dashboard, CoreDNS, Ingress Controller, CNI 플러그인

 

Pause Container (Infrastructure Container)

• Pod에서 사용자 정의 컨테이너보다 먼저 생성되는 컨테이너
• cgroups과 namespace를 보유
• 포드 내의 모든 사용자 정의 컨테이너는 Pause Container의 네임스페이스를 사용

https://kubernetes.io/docs/concepts/windows/intro/#pause-container

Windows containers in Kubernetes

https://velog.io/@baeyuna97/K8s-pause-%EC%BB%A8%ED%85%8C%EC%9D%B4%EB%84%88

K8s pause 컨테이너

 

 

컨테이너 네트워크 원리

• 동일한 노드에서 파드 간의 통신 활성화
  • 파드 생성 시 노드를 기준으로 veth(가상 네트워크 인터페이스) 쌍이 생성됨
  • veth는 노드, eth0는 파드의 pause 컨테이너에 생성됨
  • 동일 노드에 있는 파드 간의 통신은 네트워크 브릿지를 통해 이루어진다
    • Pod A eth0 → veth 123 → 브릿지 → veth234 → Pod B eth0
• 서로 다른 노드에서 파드 간의 통신 활성
  • 트래픽이 노드A-노드B 사이를 움직일 수 있어야 한다
  • 일반적으로는 네트워크 브릿지 → 물리 어댑터 → 회선 → 물리 어댑터 .. 형색으로 패킷이 전달됨
  • SDN (Software Defined Network)를 사용해서 네트워크 구성 시, 하부 네트워크 토폴로지가 어떻게 되어있건 하나의 네트워크에 연결되어있는 것 처럼 볼 수 있음
    • CNI는 SDN의 기술을 이용하여 노드 간 통신을 가능하게 만들음

CNI (Container Network Interface) 플러그인을 통해 컨테이너를 네트워크에 쉽게 연결 가능

CNI 설치 시, 쿠버네티스는 데몬셋을 이용해 각 노드에 Network Agent를 배포하고, Agent를 이용해 우리가 원하는 형식으로 통신할 수 있게 됨

ex) Calico, Flannel, Amazon VPC CNI(EKS)

https://ojt90902.tistory.com/1509

Kubernetes in Action : Chapter11. 쿠버네티스 내부 이해

 

물리적 네트워크에 대입해보자면

 

 

 

고가용성 클러스터 실행

• 컨트롤 플레인을 복수의 노드로 실행
• 리더 선출 매커니즘 사용