Component And Network
쿠버네티스 컴포넌트
kube-apiserver
kube-apiserver는 쿠버네티스 클러스터의 제어 평면(Control Plane)의 핵심 구성 요소로, 클러스터의 상태를 관리하고 제어하는 역할을 한다. 모든 REST API 요청을 처리하며, 클러스터 내의 모든 컴포넌트와 통신한다. API 서버는 클러스터의 상태 정보를 etcd에 저장하고, 이를 기반으로 클러스터를 관리한다.
주요 역할
- 클러스터의 중앙 관리 지점: 모든 API 요청을 처리하고, 클러스터의 상태를 관리한다.
- 인증 및 인가: 클러스터에 대한 접근을 제어하기 위한 메커니즘을 제공한다.
- 데이터 저장 및 조회: 클러스터의 상태 정보를 etcd에 저장하고, 필요한 데이터를 조회한다.
- 요청 인증 및 유효성 검증: 모든 요청은 먼저 인증과 검증 과정을 거친다.
kube-apiserver에 접근하는 예제 코드
kubectl --kubeconfig=config.yaml get pods
etcd
etcd는 쿠버네티스 클러스터의 상태 정보를 저장하고 관리하는 분산형 키-값 저장소이다. 고가용성과 일관성을 제공하며, 쿠버네티스의 핵심 데이터 저장소로 사용된다.
주요 역할
- 클러스터 상태 관리: 클러스터의 모든 구성 요소와 리소스의 상태를 영구적으로 저장한다.
- 고가용성과 일관성 제공: Raft 합의 알고리즘을 사용하여 데이터가 항상 일관되게 유지된다.
- 데이터 보안: 데이터 암호화와 인증 메커니즘을 제공하여 데이터의 보안을 유지한다.
etcd는 다중 노드로 구성된 클러스터 형태로 운영되며, 각 노드는 서로 통신하며 데이터를 복제하고 장애 복구를 지원한다. etcd 클러스터는 최소 3개의 노드로 구성하는 것이 일반적이다.
외부 etcd 클러스터 설정 예제
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: stable
controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
etcd:
external:
endpoints:
- https://ETCD_0_IP:2379
- https://ETCD_1_IP:2379
- https://ETCD_2_IP:2379
kube-scheduler
kube-scheduler는 워커 노드에서 Kubernetes pod의 스케줄링을 담당한다. 새로 생성된 Pod 중 아직 노드에 할당되지 않은 Pod들을 찾아내고, 해당 Pod가 실행될 최적의 Node를 찾는 역할을 한다.
스케줄러의 동작 과정
- Scheduling cycle: 최적의 노드를 선택하기 위해 filtering과 scoring 작업을 수행한다.
- Binding cycle: binding 이벤트를 생성하여 그 변화를 클러스터에 적용한다.
scheduling cycle에서는 다음과 같은 과정을 거친다.
- Pod가 생성되면 Scheduling Queue에 추가된다.
- Queue 내의 Pod들은 Priority에 따라 정렬된다.
- 순차적으로 Pod를 스케줄할 수 있는 가장 적합한 노드를 찾는다.
kube-proxy
kube-proxy는 Service IP 주소를 해당 Service에 속한 Pod의 IP 주소에 매핑하는 네트워크 라우팅 테이블을 유지함으로써 Service-Pod 간 매핑을 지원한다. 새로운 Service에 대한 요청이 오면, kube-proxy는 이 정보를 매핑하여 패킷이 Service에 속한 Pod로 전달될 수 있도록 한다.
kube-proxy의 동작 방식
- API Server와 인증을 설정한다.
- 새로운 Service나 Endpoint(Pod IP)가 생성 및 삭제되었을 때, 이러한 변경 사항을 API Server로부터 전달받는다.
- 변경사항을 Node의 NAT 룰로 적용시킨다.
kube-proxy는 클러스터 내의 모든 노드에 설치되며 주로 DaemonSet으로 동작한다.
kube-controller-manager
Kube Controller Manager는 여러 컨트롤러를 관리하는 중앙 프로세스이다. 클러스터 내부의 다양한 리소스를 모니터링하고 정상적인 상태를 유지하도록 자동으로 조정하는 역할을 한다.
주요 컨트롤러
- Node Controller: 노드의 상태를 5초마다 체크하고, 응답이 없는 노드를 관리한다.
- Replication Controller: ReplicaSet을 감시하며 항상 지정된 개수의 Pod이 유지되도록 관리한다.
- Deployment Controller: Deployment 리소스를 관리한다.
- Service Controller: Kubernetes service를 관리한다.
- Namespace Controller: 네임스페이스를 관리한다.
Kube Controller Manager의 설정 옵션
- -node-monitor-period: 노드의 상태를 확인하는 주기(기본값 5초)
- -node-grade-period: 노드를 Unreachable로 표기하기 전 대기 시간(기본값 40초)
- -pod-eviction-timeout: Unreachable 노드에서 Pod를 제거하기 전의 대기시간(기본값 5분)
쿠버네티스 네트워킹
Pod/Service Network (Calico)
Calico는 쿠버네티스에서 동작하는 CNI(Container Network Interface)이다. Calico CNI를 설치하면 Calico-node Pod가 배포되며, 다음 3가지 프로세스를 통해 동작한다:
- Felix: 인터페이스 관리, 라우팅 정보 관리, ACL 관리, 상태 체크 등을 담당한다.
- BIRD: BGP Peer에 라우팅 정보 전파 및 수신, BGP RR(Route Reflector, 자신의 라우팅 정보를 또 다시 다른 라우터에게 전달) 역할을 한다.
- Confd: calico global 설정과 BGP 설정 변경 시(트리거) BIRD에 적용한다.
그 외에도 다음과 같은 구성요소를 포함한다
- Calico IPAM plugin: 클러스터 내에서 파드에 IP 대역을 할당한다.
- Calico-kube-controllers: calico 동작 관련 감시(watch) 역할을 한다.
Calico에서 노드간 라우팅 정보 공유는 BGP 프로토콜을 통해 이루어진다. 각 노드의 Calico-node Pod는 BGP Peering을 맺어 통신한다.
Pause Container
Pause 컨테이너는 파드가 가동될 때 다른 컨테이너를 위해 Network, Volume Mount 등의 상태를 세팅해주는 역할을 한다. Pause 컨테이너는 모든 컨테이너들의 부모 컨테이너 역할을 하며, 그 어떤 다른 컨테이너보다 먼저 생성되어 동작한다.
Pause 컨테이너의 주요 역할
- Linux Namespace 생성 후 공유: Network, IPC, UTS 등의 네임스페이스를 파드 내 모든 컨테이너와 함께 공유한다.
- 좀비 프로세스 제거: 하나의 파드 내부에 여러개의 컨테이너가 가동될 경우 발생할 수 있는 좀비 프로세스 문제를 해결한다.
Pause 컨테이너는 가장 먼저 생성되어 네임스페이스를 생성한 후 다른 작업은 하지 않는다. 이를 통해 파드 내부 컨테이너는 상호 통신이 가능하며 IP를 함께 사용할 수 있다.
다중 컨테이너 파드 예제
apiVersion: v1
kind: Pod
metadata:
name: myweb2
spec:
containers:
- name: myweb2-nginx
image: nginx
ports:
- containerPort: 80
protocol: TCP
- name: myweb2-netshoot
image: nicolaka/netshoot
command: ["/bin/bash"]
args: ["-c", "while true; do sleep 5; curl localhost; done"]
terminationGracePeriodSeconds: 0
해당 파드에서는 두 컨테이너가 동일한 IP를 공유하며, 이는 Pause 컨테이너가 Network 네임스페이스를 생성하고 공유하기 때문에 가능하다.
'기록 > Kubenetes' 카테고리의 다른 글
Kubernetes (9) (0) | 2025.04.21 |
---|---|
Kubernetes (7) (0) | 2025.04.17 |
Kubernetes (6) (0) | 2025.04.16 |
Kubernetes (5) (1) | 2025.04.15 |
Kubernetes (4) (0) | 2025.04.14 |