컨트롤 플레인 컴포넌트

API 서버

kube-apiserver

• API서버는 쿠버네티스 API를 노출하는 쿠버네티스 컨트롤 플레인 컴포넌트입니다.
• API서버는 쿠버네티스 컨트롤 플레인의 프론트 엔드입니다.

쿠버네티스 API 서버의 주요 구현은 kube-apiserver 입니다. kube-apiserver는 수평으로 확장되도록 디자인되었습니다. 이로인해 많은 인스턴스를 배포하서 확장할 수 있습니다. 여러 kube-apiserver 인스터스를 실행하고, 인스턴스간의 트래픽을 균형있게 조절할 수 있습니다.

쿠버네티스 API

RESTful 인터페이스를 통해서 쿠버네티스 기능을 제공하고 클러스터의상태를 저장하는 애플리케이션입니다.

쿠버네티스 리소스와 "의도에 대한 레코드"는 모두 API 오브젝트로 저장되며, API로는 RESTful 호출을 통해서 수정됩니다. API 구성이 선언적인 방법으로 관리되도록합니다. 사용자는 쿠버네티스 API와 직접 상호 작용할 수 있으며 kubectl과 같은 툴을 사용할 수도 있습니다. 쿠버네티스의 API의 핵심은 유연며 사용자 정의 리소스를 지원하기 위해 확장될 수도 있습니다.

API 그룹

쿠버네티스 API의 연관된 경로들의 집합

API서버의 구성을 변경하여 각 API 그룹을 활성화하거나 비활성화할 수 있습니다.

• 특정 리소스에 대한 경로를 비활성화하거나 활성화할 수도 있습니다.
• API그룹을 사용하면 쿠버네티스 API를 더 쉽게 확장할 수 있습니다.
• API그룹은 REST 경로 및 직렬화된 오브젝트의 apiVersion 필드에 지정됩니다.

API 그룹과 버전 규칙

필드를 쉽게 제거하거나 리소스 표현을 재구성하기 위해, 쿠버네티스는 각각 /api/v1또는 /api/rbac.authorication.k8s.io/v1alpha1과 같은 서로 다른 API 경로에서 여러 API 버전을 지원합니다.

필드??

etcd

모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성 고가용성 키-값 저장소입니다.

쿠버네티스 클러스터에서 etcd를 뒷단의 저장소로 사용하게된다면 백업하는 계획은 필수입니다.

kube-conctroller-manager

컨트롤러 프로세스를 실행하는 컨트롤 플레인 컴포넌트

논리적으로,각 컨트롤러는 분리된 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너르로 컴파일되고 단일 프로세스 내에서 실행됩니다.

kube-scheduler

노드가 배정되지 않은 새로 새성된 파드를 감지하고, 실행할 노들르 선택하는 컨트롤 플레인 컴포넌트

스케줄링 결정을 위해서 고려되는 요소는 리소스에 대한 개별 및 총체적 요구 사항, 하드웨어/소프트웨어/정책적 제약,어피니티 및 안티-어피니티 명세, 데이터 지역성,워크로드-간 간섭, 데드라인을 포함합니다.

컨트롤러

쿠버네티스에서 컨트롤러는 클러스터의 상태를 관찰 한 다음, 필요한 경우에 생성 또는 변경을 요청하는 컨트롤 루프입니다.

각 컨트롤러는 현재 클러스터 상태를 의도한 상태에 가깝게 만들고자합니다.

컨트롤러는 API 서버를 통해 클러스터의 공유 상태를 감시합니다.

일부 컨트롤러는 컨트롤 플레인 내부에서 실행되며, 쿠버네티스 작업으 ㅣ핵심인 컨트롤 루프를 제공합니다. 예를 들어 디플로이먼트 컨트롤러,데몬셋 컨트롤러, 네임스페이스 컨트롤러 그리고 퍼시스턴트 볼륨 컨트롤러는 모두 kube-controller-manager내 에서 실행됩니다.

클라우드 컨트롤 매니저

클라우드별 컨트롤 로직을 포함하는 쿠버네티스 컨트롤 플레인 컴포넌트입니다.

클라우드 컨트롤러 매니저를 통하여 클러스터를 클라우드 공급자의 API에 연결하고, 해당 클라우드 플랫폼과 상호작용하는 컴포넌트와 클러스터와만 상호 작용하는 컴포넌트를 구분할 수 있게 해줍니다.

쿠버네티스와 기본 클라우드 인프라스트럭처 간의 상호 운용성 로직을 분리함으로써, cloud-controller-manager 컴포넌트는 클라우드 공급자가 주요 쿠버네티스 프로젝트와 다른 속도로 기능들을 릴리스할 수 있도록합니다.

lstio

마이크로서비스의 통합을 위한 통일된 방법을 제공하는 오픈 플랫폼이며, 트래픽 흐름을 관리하고, 정책을 시애하며 텔레메트리 데이터를 모읍니다.

lstio를 추가하는 것은 애플리케이션 코드 변경을 요구하지 않습니다. 서비스와 네트워크 사이의 인프라스트럭쳐 레이어입니다. 이는 서비스 Deployment와 조합되었을 때, 일반적으로 서비스 메시라고 일컫습니다. lstio의 컨트롤 플레인은 쿠버네티스, Mesosphere 등과 같은 하부의 클러스터 관리 플랫폼을 추상화 합니다.

Operator pattern

운영자 패턴은 컨트롤러를 하나 이상의 사용자 지정 리소스에 연결하는 시스템 설계입니다.

• 클러스터에 컨트롤러를 추가하여 쿠버네티스를 확장할 수 있습니다.
• 쿠버네티스 자체의 내장 컨트롤러 이상의 효과를 가지고있습니다.

실행 중인 애플리케이션이 컨트롤러 역할을 하고 컨트롤 플레인에 정의된 사용자 지정 리소스에 대해 작업을 수행하기 위한 API 액세스 권한이 있는 경우 이는 Operator 패턴의 예입니다.

QoS 클래스

QoS 클래스는 쿠버네티스가 클러스터 안의 파드들을 여러 클래스로 구분하고, 스케줄링과 축출에 대한 결정을 내리는 방법을 제공합니다.

• 파드의 QoS 클래스는 생성 시접의 컴퓨터 리소스 요청량과 제한 값에 기반해서 설정됩니다.
• Qos 클래스는 파드의 스케줄링과 축출을 위한 결정을 내릴 때 사용됩니다.

쿠버테니스는 파드에 Guaranteed, Burstable 또는 BestEffort 중 하나를 QoS 클래스로 할당할 수 있습니다.

네트워크 폴리시

파드 그룹들이 서로에 대한 그리고 다른 네트워크 엔드포인트에 대한 통신이 어떻게 허용되는지에 대한 명세입니다.

• 네트워크 폴리시는 어떤 파드들의 연결을 서로 허용할지, 어떤 네임스페이스가 통신 가능하도록 허용할지, 더 상세하게는 어떤 포트 번호에 각 정책을 시행할지도 선언적으로 구성할 수 있게 도와줍니다. 네트워크 폴리시 리소스는 파드를 선택하고 선택된 파드에 어떤 트래픽을 허용할지 명시하는 규칙을 정의하기 위해서 레이블을 사용합니다.
• 네트워크 폴리시는 네트워크 프로바이더에 의해 제공되는 네트워크 플러그인 지원에 의해 구현됩니다.
• 네트워크 리소스를 그것을 구현하는 컨트롤러 없이 생성하는 것은 아무런 효과가 없음을 주의하셔야 합니다.

로깅

로그는 클러스터나 애플리케이션에 의해 로깅된 이벤트의 목록입니다.

애플리케이션과 시스템 로그는 클러스터 내부에서 어떤 일이 벌어지고 있는지 이해하는데 도움을 줍니다.

리소스 쿼터

네임스페이스당 전체 리소스 소비를 제한하는 제약을 제공합니다.

타입에 따라 네임스페이스에서 생성될 수 있는 오브젝트의 수량과 해당 프로젝트의 리소스에 의해서 소비되는 컴퓨팅 리소스의 총량도 제한합니다.

• 네임스페이스
  쿠버네티스에서 동일한 물리 클러스터에서 다중의 가상 클러스트를 지원하기 위해 사용하는 추상화. ?? 가상 클러스트를 만들수있다?

범위 제한

네임스페이스 내에 컨테이너나 파드당 리소스 소비를 한정하는 제약 조건을 제공합니다.

범위 제한은 타입별로 만들 수 있는 오브젝트의 개수와 네임스페이스 안에 개별 컨테이너 파드가 요청하거나 소비할 컴퓨팅 리소스 양을 제한합니다.

애그리게이션 레이어 (집합레이어)

애그리게이션 레이어를 이용하면 사용자가 추가로 쿠버네티스 형식의 API를 클러스터에 설치할 수 있습니다.

쿠버네티스 API 서버에서 추가 API 지원을 구성하였으면, 쿠버네티스 API의 URL 경로를 요구하는 APIService 오브젝트를 추가할 수 있습니다.

인그레스

클러스터 내의 서비스에 대한 외부 접근을 관리하는 API 오브젝트이며, 일반적으로 HTTP를 관리합니다.

인그레스는 부하 분산,SSL 종료,명칭 기반의 가상 호스팅을 제공할 수 있습니다.

정리