쿠버네티스(kubernetes) 구성요소

쿠버네티스는 클러스터를 관리하는 도구입니다. 클러스터라 함은 단일 컴퓨터가 아니라 여러대의 컴퓨터를 하나의 묶음으로 취급하는걸 의미합니다. 그러다보니 하나의 프로세스가 아니라 여러가지 요소로 구성되어 있습니다. 

프로세스들은 크게 3가지 종류로 구분됩니다. 클러스터를 관리하기위해 필수적인 마스터(master), 노드(node)와 필수는 아니지만 추가로 사용가능한 애드온(addon)으로 구분됩니다.

마스터 구성요소

마스터 구성요소들은 실질적으로 클러스터의 전체적인 관리를 하는 것들입니다. etcd, kube-apiserver, kube-scheduler, kube-controller-manager, cloud-controller-manager등이 마스터 구성요소입니다.

ETCD

etcd는 고가용성을 제공하는 키-밸류(key-value) 저장소입니다. 쿠베네티스에서 필요한 모든 데이터를 저장하는 실질적인 데이터베이스입니다. 원래 쿠버네티스는 처음에 구글내부의 보그(borg)라는 컨테이너 오케스트레이션 도구의 오픈소스화를 진행하면서 나왔습니다. 보그가 구글에서 사용될때는 구글 내부의 처비(chubby)라는 분산 저장 솔루션을 사용했었습니다. 이와 비슷한 솔루션을 사용하기 위해서 쿠버네티스로 오픈소스화할때 etcd를 사용하게 되었습니다. etcd는 프로세스 1개만 띄워서 사용할수도 있지만 데이터의 안정성을 위해서는 여러개의 장비에 분산해서 etcd자체를 클러스터링을 구성해서 띄우는게 일반적인 방법입니다. etcd가 안정적이기는 하지만 보다 안정적으로 쿠버네티스를 운영하려면 주기적으로 etcd에 있는 데이터를 백업해 두는게 좋습니다.

kube-apiserver

쿠버네티스는 MSA(마이크로서비스아키텍처, Micoro Service Architecture) 구조로 되어 있습니다. 그래서 여러개의 분리된 프로세스로 구성되어 있습니다. 그중에서 kube-apiserver는 쿠버네티스 클러스터의 api를 사용할수 있게 해주는 프로세스입니다. 클러스터로 요청이 왔을때 그 요청이 유효한지 검증하는 역할을 합니다. 쿠버네티스로의 모든 요청은 kube-apiserver를 통해서 다른 곳으로 전달되도록 되어 있습니다. kube-apiserver는 수평적으로 확장이 가능하게 설계가 되어 있어서, 여러대의 장비에 여러개를 띄워놓고 사용할 수 있습니다. kube-apiserver를 실행할때 사용할 수 있는 다양한 옵션은 다음과 같습니다.

이름	타입	기본값	설명
--admission-control	stringSlice	[AlwaysAdmit]	어떤 기능들을 가능하게할지 못하게 할지에 대한 설정을 합니다. 우선 변경에 관한 플러그인들이 실행되고나서 유효성 검사에 대한 플러그인들이 실행됩니다. 사용 가능한 값 : AlwaysAdmit, AlwaysDeny, AlwaysPullImages, DefaultStorageClass, DefaultTolerationSeconds, DenyEscalatingExec, DenyExecOnPrivileged, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, InitialResources, Initializers, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PVCProtection, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodPreset, PodSecurityPolicy, PodTolerationRestriction, Priority, ResourceQuota, SecurityContextDeny, ServiceAccount, ValidatingAdmissionWebhook
--admission-control-config-file	string	없음	어드미션 컨트롤에 대한 설정 파일입니다.
--advertise-address	ip	없음	클러스터의 다른 멤버들이 apiserver에 접근하기위한 ip주소입니다. 이 값을 명시하지 않으면 --bind-address에 설정된 값이 사용됩니다. --bind-address도 설정되어 있지 않으면 호스트의 기본 IP주소가 사용됩니다.
--allow-privileged		false	컨테이너가 privileged 모드로 실행될 수 있게 합니다.
--anonymous-auth		true	apiserver의 보안 포트에 사용자 명시 없이 익명으로 요청이 가능하게 합니다. 들어온 요청은 익명요청으로 처리되고 사용자명은 system:anonymous, 그룹명은 system:unauthenticated 을 사용하게 됩니다.
--apiserver-count	int	1	클러스터내에서 실행되는 apiserver의 개수입니다.
--audit-log-format	string	json	클러스터내에서 어떤일이 일어났는지 기록해두는 audit값을 어떤 형식으로 기록해 둘지 지정합니다. json이 기본값이고, legacy로 설정하면 별다른 포맷없이 1줄의 로그 형식으로 기록합니다.
--audit-log-maxage	int		audit 로그를 최대 며칠까지 유지하고 있을지 설정합니다.
--audit-log-maxbackup	int		오래된 audit 로그 파일을 최대 몇개까지 보관하고 있을지 설정합니다.
--audit-log-maxsize	int		audit 로그 파일을 최대 몇 메가바이트까지 유지하고 있다가 로테이션 시킬지를 설정합니다.
--audit-log-path	string		apiserver로 들어오는 모든 요청을 설정된 파일에 저장합니다. "-"로 두면 표준출력으로 내보냅니다.
--audit-policy-file	string		audit 정책을 설정해둔 파일입니다.
--audit-webhook-batch-buffer-size	int	10000	이벤트를 배치로 웹훅으로 보내기전에 보관해둘 버퍼의 크기입니다. 배치모드에서만 사용됩니다.
--audit-webhook-batch-initial-backoff	duration	10s	요청이 실패하면 지정한 시간뒤에 재시도 합니다. 배치모드에서만 사용됩니다.
--audit-webhook-batch-max-size	int	400	웹훅으로 보내는 배치의 최대 크기입니다. 배치모드에서만 사용됩니다.
--audit-webhook-batch-max-wait	duration	30s	배치가 최대크기만큼이 안됐어도 지정된 시간이 되면 보냅니다. 배치모드에서만 사용됩니다.
--audit-webhook-batch-throttle-burst	int	15	ThrottleQPS가 사용되지 않았을때 동시에 보낼수 있는 요청의 최대개수입니다. 배치모드에서만 사용됩니다.
--audit-webhook-batch-throttle-qps	float32	10	요청을 초당 최대 얼마나 보낼수 있는지 설정하는 값입니다.배치모드에서만 사용됩니다.
--audit-webhook-config-file	string		audit 웹훅 설정을 kubeconfig형식으로 저장해둔 파일의 위치입니다.
--audit-webhook-mode	string	batch	audit 이벤트를 어떻게 처리할지에 대한 값입니다. batch는 이벤트를 모았다가 한번에 보내는 비동기 처리를 합니다. blocking은 이벤트를 보낼때 서버응답을 막도록 합니다.
--authentication-token-webhook-cache-ttl	duration	2m0s	웹훅 토큰 인증기의 응답을 캐시하는 시간입니다.
--authentication-token-webhook-config-file	string		토큰 인증에 대한 설정을 kubeconfig 형식으로 가지고 있는 파일입니다. apiserver가 여기 설정된 외부 서비스에 토큰의 인증 여부를 문의합니다.
--authorization-mode	string	AlwaysAllow	인증에 사용할 플러그인들을 순서대로 입력합니다. 사용가능한 값 : AlwaysAllow, AlwaysDeny, ABAC, Webhook, RBAC, Node
--authorization-policy-file	string		인증 정책을 csv 형식으로 가지고 있는 파일입니다.
--authorization-webhook-cache-authorized-ttl	duration	5m0s	웹훅 인증 서비스로부터 받은 "인증되었다"는 응답을 얼마나 캐시하고 있을지에 대한 값입니다.
--authorization-webhook-cache-unauthorized-ttl	duration	30s	웹훅 인증 서비스로부터 받은 "인증불가"라는 응답을 얼마나 캐시하고 있을지에 대한 값입니다.
--authorization-webhook-config-file	string		--authorization-mode=Webhook 옵션을 사용했을때 웹훅 설정을 kubeconfig 형식으로 가지고 있는 파일입니다.
--azure-container-registry-config	string		애저(Azure) 컨테이너 저장소의 설정을 가지고 있는 파일입니다.
--basic-auth-file	string		이 옵션이 설정되면 apiserver의 보안포트로 들어온 요청들에 대해서 http 기본인증을 하는데 사용됩니다.
--bind-address	ip	0.0.0.0	--secure-port port로 설정된 포트로 들어오는 요청을 받을 ip 주소입니다. 클러스터의 다른 멤버들이나 kubectl같은 클라이언트가 접근가능한 주소여야 합니다.
--cert-dir	string	/var/run/kubernetes	TLS인증서들이 있는 경로입니다. --tls-cert-file이나 --tls-private-key-file 옵션이 제공되면 이 옵션은 무시됩니다.
--client-ca-file	string		이 파일에 있는 클라이언트 인증서를 사용하는 요청은 클라이언트 인증서에 명시된 CommonName에 있는 값으로 인증됩니다.
--cloud-config	string		클라우드 제공자의 설정파일입니다.
--cloud-provider	string		클라우드 서비스 제공자 입니다.
--contention-profiling			프로파일링이 활성화 되어 있을경우 락(lock) 경합에 대한 프로파일링을 활성화 합니다.
--cors-allowed-origins	stringSlice		CORS를 허용하는 목록입니다. 하위 도메인을 표현하기 위해 정규표현식을 사용할수 있습니다. 이 옵션이 없는 경우 CORS를 사용할 수 없습니다.

kube-scheduler

kuber-scheduler는 이름에서 알 수 있듯이 새로운 포드들이 만들어질때 현재 클러스터내에서 자원할당이 가능한 노드들 중에서 알맞은 노드를 선택해서 그곳에 포드를 띄우는 역할을 합니다. 포드는 처음 실행될때 여러가지 조건을 지정해서 실행하는데, kube-scheduler가 그 조건에 맞는 노드를 찾아주는 역할을 합니다. 필요한 하드웨어 요구사항이라던가, 어피니티/안티어피니티(affinity/anti-affinity) 조건을 만족하는지, 특정 데이터가 있는 노드에 할당한다던가 하는 다양한 설정을 할 수 있습니다.

kube-controller-manager

쿠버네티스는 각각의 컨트롤러(controller)들이 포드들을 관리하는 역할을 합니다. kube-controller-manager는 이런 각각의 컨트롤러들을 실행하는 역할을 합니다. 각 컨트롤러들은 논리적으로는 개별 프로세스이지만 복잡도를 줄이기 위해서 하나의 바이너리 파일로 컴파일되어 있고, 하나의 단일 프로세스로 실행됩니다. 쿠버네티스는 golang언어로 개발되어 있는데, 클러스터내에서 새로운 컨트롤러가 사용될때는 그 컨트롤러에 해당하는 구조체가 만들어진 다음에 그걸 kube-controller-manager가 관리하는 큐에 넣어서 실행하는 방식으로 작동합니다.

cloud-controller-manager

cloud-controller-manager 는 클라우드 서비스를 제공해 주는 곳들에서 쿠버네티스의 컨트롤러들을 자신들의 서비스와 연계해서 사용하기 위해서 사용합니다. 관련된 코드는 각 클라우드 서비스 제공사들에서 직접 관리하도록 되어 있습니다. 다음 4가지 컨트롤러들이 관련있는 컨트롤러들입니다.

• 노드 컨트롤러(Node Controller) : 클라우드 서비스 내에서 노드를 관리하기 위해서 사용합니다.
• 라우트 컨트롤러(Route Controller) : 각 클라우드 인프라내에서의 네트워크 라우팅을 관리하는데 사용합니다.
• 서비스 컨트롤러(Service Controller) : 각 클라우드 서비스에서 제공하는 로드밸런서를 생성/갱신/삭제하는데 사용합니다.
• 볼륨 컨트롤러(Volume Controller) : 클라우드 서비스에서 볼륨을 생성해서 노드에 붙이고 마운트해서 볼륨을 관리하는데 사용합니다.

노드 구성요소

노드 구성요소는 모든 노드에서 실행되면서, 각 노드에서 포드가 실행되는걸 관리하고 쿠버네티스 실행환경을 관리하는 역할을 합니다. kubelet, kube-proxy, 컨테이너 런타임 등이 있습니다.

kubelet 

kubelet은 클러스터내의 모든 모드에서 실행되는 에이전트 입니다. 포드내의 컨테이너들이 실행되는걸 직접적으로 관리하는 역할을 합니다. kubelet은 PodSpecs라는 설정을 받아서 그 조건에 맞게 컨테이너를 실행하고 컨테이너가 정상정으로 실행되고 있는지 상태 체크를 진행합니다. 노드안에 있는 컨테이너라고 하더라도 쿠버네티스가 만들지 않은 컨테이너는 관리하지 않습니다.

kube-proxy

쿠버네티스는 클러스터 내부에 별도의 가상 네트워크를 설정하고 관리합니다.  kube-proxy는 이런 가상 네트워크가 동작할 수 있게 하는 실질적인 역할을 하는 프로세스입니다. 호스트의 네트워크 규칙을 관리하거나 커넥션 포워딩을 하기도 합니다.

컨테이너 런타임(Container Runtime)

컨테이너 런타임은 실제로 컨테이너를 실행시키는 역할을 합니다. 가장 많이 알려진 런타임으로는 도커(Docner)가 있고, 그외 rkt, runc같은 런타임도 지원합니다. 그외에도 컨테이너에 관한 표준을 제정하는 역할을 하는 OCI(Open Container Initiative, https://www.opencontainers.org/)의 런타임 규격(runtime-spec)을 구현하고 있는 컨테이너 런타임이라면 쿠버네티스에서 사용할 수 있습니다.

애드온(Addons)

애드온은 클러스터 내부에서 필요한 기능들을 위해 실행되는 포드들입니다. 애드온에 사용되는 포드들은 디플로이먼트, 리플리케이션컨트롤러등에 의해 관리됩니다. 애드온이 사용하는 네임스페이스는 kube-system입니다. 애드온에는 몇가지 종류들이 있습니다.

네트워킹 애드온

쿠버네티스는 클러스터 내부에 가상네트워크를 구성해서 사용하는데, 이때 kuby-proxy이외에 네트워킹 관련한 애드온을 사용합니다. AWS, 애저, 구글클라우드같은 클라우드 서비스에서 제공하는 쿠버네티스를 사용한다면 별도의 네트워킹 애드온을 사용하지 않더라도 각 클라우드 벤더에서 구현하고 있으니 신경쓰지 않아도 됩니다. 하지만 쿠버네티스를 직접 보유중인 서버들에 설치해서 구성을 하려고 하려면 네트워킹 관련 애드온을 설치해서 사용해야합니다. 이 부분이 쿠버네티스를 직접 설치할때 가장 까다로운 부분이기도 합니다. 네트워킹 애드온의 종류는 10개가 넘을 정도로 다양하게 있습니다. ACI, Calico, Canal, Cilium, CNI-Genie, Contiv, Falannel, Multus, NSX-T, Nuage, Romana, Weave Net등이 있고, OCI의 CNI(Container Network, Interface) 를 구현하고 있다면 다른 애드온들도 사용할 수 있습니다.

DNS 애드온

DNS 애드온의 경우 실제로 클러스터 내에서 작동하는 DNS 서버입니다. 쿠버네티스 서비스들에 DNS 레코드를 제공하는 역할을 합니다. 쿠버네티스 내부에서 실행된 컨테이너들은 자동으로 DNS서버에 등록됩니다. dns 서비스로는 kube-dns와 core-dns가 있습니다.

대시보드 애드온

쿠버네티스를 소개할때 대부분의 경우 kubectl이라는 CLI(Command Line Interface)를 많이 사용합니다. 하지만 웹 UI가 필요한 경우가 있을수도 있는데, 이런경우에 사용할수 있는 대시보드가 있습니다. 보이는 것 처럼 클러스터 현황을 한눈에 쉽게 파악할 수 있습니다.

컨테이너 자원 모니터링

클러스터 내부에서 실행중인 컨테이너의 상태를 모니터링하기 위해서는 cpu, 메모리 같은 필요한 메트릭 데이터들을 시계열형식으로 저장하고 볼수 있는 방법을 제공하는데 필요한 애드온입니다. kubelet안에 cAdvisor라는 컨테이너 모니터링 도구가 포함되어 있는데요. 이 데이터들을 수집해서 사용할 수 있는 힙스터(heapster)를 이용하면 손쉽게 필요한 데이터들을 수집해서 모니터링에 이용할 수 있습니다.

클러스터 로깅

클러스터내의 각 개별 컨테이너에서 나오는 로그와 쿠버네티스 구성요소들에서 나오는 로그들을 중앙화된 로그 수집 시스템에 모아서 볼 수 있습니다. 이것 역시 클라우드 서비스를 이용중이라면 각 클라우드 벤더에서 제공해주는 로깅 서비스들과 잘 연동이 되어 있겠지만, 직접 쿠베네티스를 설치해서 사용할때는 고려해야 하는 요소입니다. 클러스터 내의 각 노드에 로그를 수집하는 포드를 실행해서 한곳으로 로그를 수집하도록 합니다. 로그를 수집해서 제공해주는 역할로는 ELK(ElasticSearch, Logstash, Kibana)를 많이 사용합니다.