- 쿠버네티스의 개념과 구성을 알고 싶어 정리한 내용입니다.
- 아직 부족함이 많은 글이라 공부하면서 추가할 예정입니다.
1. Kubernetes 개념
-
컨테이너화 된 애플리케이션을 쉽고 빠르게 배포/확장하고 관리를 자동화해주는 오픈소스 컨테이너 플랫폼
- 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공
- 애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공
-
K8s라고도 표기함
- "K"와 "s"와 그 사이에 있는 8글자를 나타내는 약식 표기
2. kubernetes architecture
-
클러스터(cluster)가 갖춰야할 특성
- 보안성
- 최신 보안을 따라야 함
- 사용 편의성
- 몇 가지 간단한 명령으로 작동해야 함
- 확장 가능성
- 보안성
클러스터(cluster)?
애플리케이션 컨테이너를 실행하기 위한 일련의 노드 머신
쿠버네티스를 실행 중이라면 클러스터를 실행하는 것
- 쿠버네티스에서는 개별 하드웨어를 노드라고 칭함
- 노드가 여러 개 모여 클러스터를 이루며, 필요에 따라 컴퓨팅 성능 분산 가능
→ 이 클러스터에서 실행되는 것이 Pod - Pod와 강하게 결합된 Pod 속의 컨테이너는 같은 클러스터에서 함께 실행됨
Pod
- 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위
- 하나 이상의 컨테이너 그룹
- 동일한 Pod 내에서는 storage/network를 공유
2.1. 마스터(Master)와 노드(Node)
- 쿠버네티스는 크게 마스터(Master)와 노드(Node) 두 개의 컴포넌트로 분리
2.1.1. 마스터(Master)
-
쿠버네티스 클러스터 전체를 컨트롤 하는 시스템
- 쿠버네티스 설정 환경 저장 및 전체 클러스터를 관리하는 역할
-
구성
- API 서버
- 스케쥴러(scheduler)
- 컨트롤러 매니저(controller manager)
- etcd
-
API 서버
- 쿠버네티스는 모든 명령과 통신을 API를 통해서 진행
- 마스터의 조율자 역할
- 쿠버네티스 컨트롤 플레인의 프론트 엔드
- 중심이 되는 API 서버
- 특징
- 상태 조회 및 변경
- 권한 확인
- 모든 기능을 REST API로 제공
- etcd와 통신
컨트롤 플레인(Control Plane)
컨테이너의 라이프사이클을 정의, 배포, 관리하기 위한 API와 인터페이스들을 노출하는 컨테이너 오케스트레이션 레이어
-
스케쥴러(scheduler)
- Pod, 서비스 등 각 리소스들을 적절한 노드에 할당하는 역할
- CPU 또는 메모리와 같은 pod의 리소스 요구사항과 클러스터 상태를 고려 후 pod를 적절한 컴퓨팅 노드에 예약
-
컨트롤러 매니저(controller manager)
- 클라우드별 컨트롤 로직을 포함하는 쿠버네티스 컨트롤 플레인 컴포넌트
- 실제로 클러스터를 실행
- 클러스터를 클라우드 공급자의 API에 연결하고, 해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와만 상호 작용하는 컴포넌트를 구분할 수 있게 함
- 내부 컨트롤러(Replica controller, Service controller, Volume Controller, Node controller 등)를 생성하고 이를 각 노드에 배포하며 이를 관리
- 하나의 컨트롤러는 스케줄러를 참고하여 정확한 수의 pod가 실행되게 함
- pod에 이상이 있을 시 또 다른 컨트롤러가 이를 감지하고 대응
-
etcd
- 쿠버네티스의 데이터베이스 역할이 되는 서버
- 분산형 key-value 스토어 오픈소스로 클러스터의 상태나 설정 정보를 저장
-
DNS
- 쿠버네티스는 리소스의 엔드포인트(Endpoint)를 DNS로 맵핑하고 관리
- 새로운 리소스가 생기면 그 리소스에 대한 IP와 DNS 이름을 등록하여 DNS 이름을 기반으로 리소스에 접근할 수 있도록 함
2.1.2. 노드(Node)
-
마스터에 의해 명령을 받고 실제 워크로드를 생성하여 서비스 하는 컴포넌트
-
노드에는 Kubelet, Kube-proxy,cAdvisor 그리고 컨테이너 런타임이 배포됨
-
Kubelet
- 노드에 배포되는 에이전트
- 마스터의 API 서버와 통신하면서 노드가 수행해야 할 명령을 받아서 수행하고 반대로 노드의 상태등을 마스터로 전달
-
Kube-proxy
- 네트워크 proxy 역할(부하분산)을 담당
- 노드와 마스터 간의 네트워크 통신을 처리
-
Container runtime
- 노드에는 컨테이너 실행을 위한 컨테이너 런타임 엔진이 존재
- docker, rkt, CRI-O 등 다양한 런타임 존재
-
cAdvisor
- kubelet에 탑재되어 있으며 각 노드에서 기동되는 모니터링 에이전트
- Node의 자원 사용량을 모니터링하고 컨테이너의 성능을 분석
- 정보를 수집하여 마스터 서버의 API 서버로 전달
3. kubernetes 네트워크
3.1. Kubernetes 네트워크를 크게 4가지로 분류
- 서로 결합된 컨테이너와 컨테이너 간 통신
- Pod와 Pod 간의 통신
- Pod와 Service간의 통신
- 외부와 Service간의 통신
3.1.1. 서로 결합된 컨테이너와 컨테이너 간 통신
Container to Container
-
위 그림에서 두 개의 컨테이너는 veth0 라는 동일한 네트워크를 사용
- 두 컨테이너는 동일한 IP를 할당 받음
-
veth0 안에서 각 컨테이너는 고유한 port 번호로 서로를 구분
- 외부에서는 두 컨테이너가 동일한 IP로 보이더라도 port로 서로 구분을 할 수 있음
- 다른 port를 사용하기 때문에 컨테이너끼리 구분이 가능
- Pod 내에서는 각자 고유한 port 번호를 사용이 필수
-
네트워크 인터페이스를 제공하는 컨테이너가 존재
- 각 Pod 마다 존재
- 컨테이너 종류
- coredns
- kube-flannel
- kube-proxy
3.1.2. Pod와 Pod 간의 통신
Pod to Pod
1. 싱글 노드 Pod 네트워크
-
쿠버네티스는 kubenet이라는 기본적인 네트워크 플러그인을 제공
- 간단한 기능만 제공해주기 때문에 크로스노드 네트워킹이나 네트워크 정책 설정과 같은 고급 기능은 구현되어 있지 않음
-
CNI 스펙을 준수하는 다양한 네트워크 플러그 사용을 권장
-
Pod는 고유한 IP 주소를 가지기 때문에 각 Pod는 kubenet 혹은 CNI로 구성된 네트워크 인터페이스를 통하여 고유한 IP 주소로 서로 통신
2. 멀티 노드 Pod 네트워크
- 여러 개의 워커 노드 사이에 각각 다른 노드에 존재하는 Pod가 서로 통신하기 위해 라우터를 거쳐서 통신을 하게 됨
3.1.3. Pod와 Service간의 통신
- Kubernetes에서 pod는 영구적인 것이 아니고 계속해서 재생성이 되는 특징을 가지고 있음
- 따라서 IP가 유동적
- 이를 해결하기 위한 방법이 Service Object
- 서비스 앞단에 reverse-proxy(혹은 load balancer)를 위치시켜 클라이언트에서 proxy로 연결 시 proxy의 역할은 서버들 목록을 관리하며 현재 살아있는 서버에게 트래픽을 전달
- 트래픽을 전달할 때는 몇 가지 요구 사항이 존재
- Kubernetes는 기존 시스템을 잘 활용하여 service 리소스 타입이라는 것을 만듦
참고 사이트
https://ikcoo.tistory.com/11
4. Kubernetes auth policy
- 쿠버네티스에서는 사용자의 접근 권한을 부여받기 전에 사용자가 인증이(로그인) 필요
- 쿠버네티스는 API 서버를 이용하여 API 요청을 인가
- 모든 정책과 비교하여 모든 속성을 평가하고 요청을 허용하거나 거부함
- 리소스 요청은 소문자 HTTP 동사(REST API)를 사용
