1. 배경
분산형 구조를 기반으로 서비스의 수나 시스템의 분할 등 관리해야 할 서비스가 많고, 서비스 능력의 관점에서 계층적 관리와 제어가 가능하나 서비스 계층이 상당히 많고 변경 및 업데이트 빈도가 매우 낮아 인식이 불분명하다.
제가 현재 연구 개발에 참여하고 있는 시스템을 예로 들면, K8S를 통해 관리되는 서비스가 거의 100개에 달하고 이 중 일부는 클러스터 모드를 채택하고 있습니다.
2. 지속적인 통합
이전에 이 주제에 대해 Jenkins, Docker 및 K8S와 같은 구성 요소의 사용 수준에 중점을 두고 소스 코드 컴파일, 패키징, 이미지 구성 및 배포의 자동 관리 프로세스를 요약한 완전한 실제 사례를 작성했습니다.
Jenkins : 빌드, 테스트 및 배포를 포함한 다양한 작업을 자동화하기 위한 확장성이 매우 뛰어난 소프트웨어입니다.
Docker : 오픈 소스 애플리케이션 컨테이너 엔진으로서 이미지 이미지 파일을 생성하기 위해 애플리케이션 및 관련 종속성을 패키징할 수 있습니다.표준 운영 환경이며 지속 가능한 전달 기능을 제공합니다.
Kubernetes : 오픈 소스 컨테이너 오케스트레이션 엔진으로 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하는 데 사용됩니다.
3. K8S 아키텍처
1. 핵심 부품
컨트롤 플레인 구성 요소: 컨트롤 플레인 구성 요소
리소스 예약, 탐지, 사고 대응과 같은 클러스터에 대한 글로벌 의사 결정은 클러스터의 모든 노드에서 실행할 수 있습니다.
- api: K8S의 API를 열고 구성 요소가 API를 통해 상호 작용합니다. 이는 컨트롤 플레인의 프런트 엔드에 해당합니다.
- controllermanager: 논리적으로 별도의 프로세스인 컨트롤러 프로세스를 실행합니다.
- 스케줄러: 실행 중인 노드를 지정하지 않은 새로 생성된 Pod를 모니터링하고 Pod에 대해 실행 중인 노드를 선택합니다.
- etcd: K8S 데이터를 저장하기 위한 배경 라이브러리로서 일관성과 고가용성을 갖춘 키-값 데이터베이스
노드: 노드 구성 요소
이 구성 요소는 각 노드에서 실행되며 실행 중인 Pod를 유지 관리하고 Kubernetes 운영 환경을 제공합니다.
- kubelet: 컨테이너가 Pod에서 실행 중인지 확인하기 위해 각 노드에서 실행되는 에이전트.
- kube-proxy: 각 노드에서 실행되는 네트워크 프록시로 노드에서 네트워크 규칙을 유지합니다.
컨테이너 런타임: 컨테이너 런타임
컨테이너 실행을 담당하는 소프트웨어는 Docker, containerd 및 CRI-O와 같은 여러 컨테이너 운영 환경과 Kubernetes-CRI 컨테이너 운영 환경을 구현하는 모든 인터페이스를 지원합니다.
2. 계층 구조
전체 기능을 고려할 때 K8S 클러스터는 사용자, 제어 평면 및 노드의 세 가지 모듈로 나눌 수 있습니다.
사용자 측 : CLI 명령줄이든 UI 인터페이스이든 제어 패널의 API 서버와 상호 작용하고 API 서버는 다른 구성 요소와 상호 작용하고 최종적으로 해당 작업 명령을 실행합니다.
컨트롤 플레인 : 이전에 마스터라고도 알려진 핵심 구성 요소에는 API 서버, 컨트롤러, 스케줄러 등이 포함되며 주로 전체 클러스터를 예약하고 글로벌 결정을 내리는 데 사용됩니다.
Node : 노드에서 실행되는 Pod에 컨테이너를 넣어 워크로드를 실행하며 워크로드에 대한 간단한 이해는 다양한 애플리케이션 등 노드의 핵심 구성요소로는 Pod, kubelet, Container-Runtime, kube-proxy 등이 있다.
3. 핵심역량
연구 개발의 관점에서 K8S는 매우 강력한 애플리케이션 서비스 관리 기능을 제공합니다.
3.1 검색 및 로드
서비스 서비스는 일반적으로 리소스 개체를 필터링하는 태그를 사용하여 하나 또는 포드 그룹에서 실행되는 네트워크 애플리케이션을 네트워크 서비스로 노출할 수 있습니다.
3.2 스케줄링
스케줄러는 모니터링 메커니즘을 사용하여 클러스터에서 새로 생성되고 아직 노드에 예약되지 않은 Pod를 검색합니다. Pod의 컨테이너와 Pod 자체의 리소스 요구 사항이 다를 수 있으므로 스케줄러는 Pod를 적절한 노드에 배치합니다.
3.3 자동 스케일링
K8S는 CPU 사용률, 응답 시간, 메모리 사용률 등의 지표를 통해 워크로드의 리소스 요구 사항을 확인하여 확장이 필요한지 여부를 결정할 수 있습니다.수직적 차원은 더 많은 리소스 할당이 될 수 있고 수평적 차원은 더 많은 클러스터 배치가 될 수 있습니다.
K8S는 자동 확장 및 자동 복구 기능이 있으며, 노드에 장애가 발생하거나 애플리케이션 서비스가 비정상인 경우 이를 확인하고 노드를 마이그레이션하거나 다시 시작할 수 있습니다.
4. 적용 사례
1. 서비스 전개
이전의 실제 사례에서 배포 작업은 CLI 명령줄 및 스크립트 파일을 사용하여 완료되었으며 전체 프로세스에는 클러스터의 여러 구성 요소, 여러 통신 및 스케줄링의 협력이 포함되었습니다.
kubectl create -f pod.yaml
2. 인터랙션 프로세스
- CLI 명령줄과 UI 인터페이스는 위에서 언급한 Pod 배포 작업과 같이 APIserver 인터페이스를 통해 클러스터의 내부 구성 요소와 상호 작용합니다.
- API 서버가 요청을 받은 후 저장 작업을 완료하기 위해 직렬화된 상태의 개체를 etcd에 기록합니다.
- 스케줄러 스케줄러는 클러스터에서 새로 생성되고 Watch 메커니즘을 통해 아직 노드에 예약되지 않은 Pod를 검색합니다.
- 클러스터에서 Pod의 스케줄 가능한 모든 노드를 찾아 이 스케줄 가능한 노드에 점수를 매기고 점수가 가장 높은 노드를 선택하여 Pod를 실행하면 스케줄러가 스케줄링 결정을 API 서버에 알립니다.
- API 서버가 정보 저장을 완료한 후 Kubelet에 해당 노드를 알립니다.
- Kubelet은 PodSpec을 기반으로 작동하여 이러한 PodSpecs에 설명된 컨테이너가 실행되고 양호한 상태인지 확인합니다. 각 PodSpec은 Pod를 설명하는 YAML 또는 JSON 개체입니다.
- Pod는 하나 이상의 컨테이너를 포함하여 Kubernetes에서 만들고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위입니다.