| Table of Contents |
|---|
K8s는 여러 컨테이너 런타임을 지원하며, 여기서는 Docker 런타임을 기본으로 설명한다.
(Docker 18.09 이상에서는 containerd를 Docker에서 기본으로 탑재한다)
그러므로, Docker에 대한 기본 개념 및 사용법을 알고 있다고 가정한다.
...
K8s는 하나 이상의 container로 이루어진 pod 클러스터를cluster를, 하나의 어플리케이션인 것처럼 운영하는 방법을 제시한다는 철학을 기반으로 하여, planning 하고 독립적이고 조합 가능한 제어 프로세스들로 구성된 오픈소스 플랫폼.
...
지원하는 애플리케이션의 유형을 제약하지 않는다.
소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다.
애플리케이션 레벨의 서비스를 제공하지 않는다.
로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 즉, 메트릭을 수집하고 노출하는 메커니즘을 제공한다.
쿠버네티스는 K8s는 단순한 오케스트레이션 시스템이 아니다. 사실, 쿠버네티스는 K8s는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, 쿠버네티스는 K8s는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도한 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.
Architecture Components
...
Master node: 컨트롤 플레인(control plane) 컴포넌트
kube-apiserver
API 서버는 쿠버네티스 K8s 컨트롤 플레인의 프론트 엔드이다.
etcd
모든 클러스터 cluster 데이터를 담는 쿠버네티스 K8s backend consistent and highly-available key value storestore.
kube-scheduler
Node가 배정되지 않은 새로 생성된 pod를 감지하고, 실행할 node를 선택하는 컨트롤 플레인 컴포넌트.
스케줄링 결정을 위해서 고려되는 요소는 리소스에 resource에 대한 개별 및 총체적 요구 사항, 하드웨어/소프트웨어/정책적 제약, 어피니티(affinity) 및 안티-어피니티(anti-affinity) 명세, 데이터 지역성, 워크로드-간 간섭, 데드라인을 포함한다.
kube-controller-manager
컨트롤러를 구동하는 마스터 상의 컴포넌트.
논리적으로, 각 컨트롤러는 개별 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고 단일 프로세스 내에서 실행된다.
이들 컨트롤러는 다음을 포함한다.
노드 컨트롤러(NC): 노드가 다운되었을 때 통지와 대응에 관한 책임을 가진다.
리플리케이션 컨트롤러(RC): 시스템의 모든 레플리케이션 컨트롤러 오브젝트에 object에 대해 알맞은 수의 파드들을 유지시켜 주는 책임을 가진다.
엔드포인트 컨트롤러(EC): 엔드포인트 오브젝트를 object를 채운다(즉, 서비스와 파드를 연결시킨다.)
서비스 어카운트(SAC) & 토큰 컨트롤러(TC): 새로운 네임스페이스에 Namespace에 대한 기본 계정과 API 접근 토큰을 생성한다.
cloud-controller-manager
클라우드별 컨트롤 로직을 포함하는 쿠버네티스 컨트롤 K8s 컨트롤 플레인 컴포넌트
cloud-controller-manager는 클라우드 제공자 전용 컨트롤러만 실행한다. 자신의 사내 또는 PC 내부의 학습 환경에서 쿠버네티스를 K8s를 실행 중인 경우 클러스터에는 cluster에는 클라우드 컨트롤러 매니저가 없다
kube-controller-manager와 마찬가지로 cloud-controller-manager는 논리적으로 독립적인 여러 컨트롤 루프를 단일 프로세스로 실행하는 단일 바이너리로 결합한다. 수평으로 확장(두 개 이상의 복제 실행)해서 성능을 향상시키거나 장애를 견딜 수 있다.
다음 컨트롤러들은 클라우드 제공 사업자의 의존성을 가질 수 있다.
노드 컨트롤러: 노드가 응답을 멈춘 후 클라우드 상에서 삭제되었는지 판별하기 위해 클라우드 제공 사업자에게 확인하는 것
라우트 컨트롤러: 기본 클라우드 인프라에 경로를 구성하는 것
서비스 컨트롤러: 클라우드 제공 사업자 로드밸런서를 생성, 업데이트 그리고 삭제하는 것
Worker Node 컴포넌트
kubelet
클러스터의 cluster의 각 노드에서 실행되는 에이전트.
Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리.Kubelet은 8s를 통해 생성되지 않는 컨테이너는 관리하지 않는다.
kube-proxy
kube-proxy는 클러스터의 cluster의 각 노드에서 실행되는 네트워크 프록시로, 쿠버네티스의 K8s의 서비스 개념의 구현부
kube-proxy는 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 cluster 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다.
kube-proxy는 운영 체제에 가용한 패킷 필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)한다.
Container runtime
컨테이너 실행을 담당하는 소프트웨어
도커(Docker), containerd, CRI-O 그리고 Kubernetes CRI (컨테이너 런타임 인터페이스)를 구현한 모든 소프트웨어 지원.
Addon
애드온은 쿠버네티스 리소스K8s resource(데몬셋, 디플로이먼트 등)를 이용하여 클러스터 cluster 기능을 구현한다.
이들은 클러스터 cluster 단위의 기능을 제공하기 때문에 애드온에 대한 네임스페이스 리소스는 Namespace resource는 kube-system 네임스페이스에 Namespace에 속한다.(Not all).
선택된 일부 애드온은 아래에 설명하였고, 사용 가능한 전체 확장 애드온 리스트는 애드온을 참조한다
DNS
쿠버네티스에 K8s에 의해 구동되는 컨테이너는 DNS 검색에서 이 DNS 서버를 자동으로 포함한다
웹 UI (대시보드)
컨테이너 리소스 resource 모니터링
컨테이너 리소스 resource 모니터링은 중앙 데이터베이스 내의 컨테이너들에 대한 포괄적인 시계열 매트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공해 준다.
클러스터cluster-레벨 로깅
클러스터cluster-레벨 로깅 메커니즘은 검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 진다.
Understanding Terms(중요)
| Info |
|---|
K8s에서 사용되는 용어 및 개념 이해는 아래 링크에 전체적으로 잘 나와있으므로, 참고 하도록 한다.
여기서는 위 여기서는 아래 블로그를 포함하여 각종 관련 사이트 및 K8s 공식 사이트 문서를 참고하여, 보다 간략히 k8s에 대한 이해에 반드시 필요한 개념 위주로 추려서 기술한다. 내용 中 일부 출처: https://bcho.tistory.com/1256?category=731548 [조대협의 블로그] |
아래 object들은 대부분 [yaml or json] 파일 형식으로 선언 및 정의하여, 사용 혹은 재 사용 된다.
상세한 명세는 k8s 공식 가이드를 참고할 수 있으며, 여기에서는 이후 별도로 다룰 예정이다.
참고로, 현재는 거의 모든 오픈소스 소프트웨어든 특정 벤더 소프트웨어든 간에, dockerfile, docker 이미지 및 k8s object 명세 파일을 각 제품의 배포(설치) 방식에 포함하고 있다.
따라서 대부분의 경우, 해당 소프트웨어의 k8s object 명세 파일을 받아서 사용 환경에 맞게 커스터마이즈하여 사용하게 된다.
...
된다.
Namespace
Namespace 는 한 K8s cluster내의 논리적인 분리 단위라고 보면 된다.
Pod,Service 등은 Namespace 별로 생성이나 관리가 될 수 있고, 사용자의 권한 역시 이 Namespace 별로 나눠서 부여할 수 있다.
즉 하나의 cluster 내에, 개발/운영/테스트 환경이 있을 때, cluster를 개발/운영/테스트 3개의 Namespace 로 나눠서 운영할 수 있다. Namespace로 할 수 있는 것은,
사용자 별로 Namespace 별 접근 권한을 다르게 운영할 수 있다.
Namespace 별로 resource quota(할당량)을 지정할 수 있다. 개발계에는 CPU 100, 운영계에는 CPU 400과 GPU 100개 식으로, 사용 가능한 resource량을 지정할 수 있다.
Namespace 별로 resource를 나눠서 관리할 수 있다. (Pod, Service 등)
...
<Billing 부서와 Commerce 부서의 resource 사용을 서로 논리적으로 분리한 예>
K8s는 처음에 네 개의 초기 namespace를 갖는다.
default다른 namespace가 없는 object를 위한 default namespace.kube-systemK8s 시스템에서 생성한 object를 위한 namespace.kube-public이 namespace는 자동으로 생성되며 모든 사용자(인증되지 않은 사용자 포함)가 읽기 권한으로 접근할 수 있다. 이 namespace는 주로 전체 cluster 중에 공개적으로 드러나서 읽을 수 있는 resource를 위해 예약되어 있다. 이 namespace의 공개적인 성격은 단지 관례이지 요구 사항은 아니다.kube-node-leasecluster가 스케일링될 때 노드 하트비트의 성능을 향상시키는 각 노드와 관련된 리스(lease) object에 대한 namespace.
모든 object가 특정 namespace에 속하지는 않으며, namespace에 속할 수 없는 속성의 것들도 있다.
예를 들어, Node나 Persistent Volume Claims과 같은 저수준 resource는 어느 namespace에도 속하지 않는다.
다음은 namespace에 속하거나 속하지 않는 K8s resource에 대한 전체 목록을 조회하는 방법이다.
| Code Block | ||
|---|---|---|
| ||
# 네임스페이스에 속하는 리소스
$ kubectl api-resources --namespaced=true
NAME SHORTNAMES APIGROUP NAMESPACED KIND
componentstatuses cs false ComponentStatus
namespaces ns false Namespace
nodes no false Node
persistentvolumes pv false PersistentVolume
mutatingwebhookconfigurations admissionregistration.k8s.io false MutatingWebhookConfiguration
validatingwebhookconfigurations admissionregistration.k8s.io false ValidatingWebhookConfiguration
customresourcedefinitions crd,crds apiextensions.k8s.io false CustomResourceDefinition
apiservices apiregistration.k8s.io false APIService
tokenreviews authentication.k8s.io false TokenReview
selfsubjectaccessreviews authorization.k8s.io false SelfSubjectAccessReview
selfsubjectrulesreviews authorization.k8s.io false SelfSubjectRulesReview
subjectaccessreviews authorization.k8s.io false SubjectAccessReview
certificatesigningrequests csr certificates.k8s.io false CertificateSigningRequest
ingressclasses networking.k8s.io false IngressClass
runtimeclasses node.k8s.io false RuntimeClass
podsecuritypolicies psp policy false PodSecurityPolicy
clusterrolebindings rbac.authorization.k8s.io false ClusterRoleBinding
clusterroles rbac.authorization.k8s.io false ClusterRole
priorityclasses pc scheduling.k8s.io false PriorityClass
csidrivers storage.k8s.io false CSIDriver
csinodes storage.k8s.io false CSINode
storageclasses sc storage.k8s.io false StorageClass
volumeattachments storage.k8s.io false VolumeAttachment
# 네임스페이스에 속하지 않는 리소스
$ kubectl api-resources --namespaced=false
NAME SHORTNAMES APIGROUP NAMESPACED KIND
bindings true Binding
configmaps cm true ConfigMap
endpoints ep true Endpoints
events ev true Event
limitranges limits true LimitRange
persistentvolumeclaims pvc true PersistentVolumeClaim
pods po true Pod
podtemplates true PodTemplate
replicationcontrollers rc true ReplicationController
resourcequotas quota true ResourceQuota
secrets true Secret
serviceaccounts sa true ServiceAccount
services svc true Service
controllerrevisions apps true ControllerRevision
daemonsets ds apps true DaemonSet
deployments deploy apps true Deployment
replicasets rs apps true ReplicaSet
statefulsets sts apps true StatefulSet
localsubjectaccessreviews authorization.k8s.io true LocalSubjectAccessReview
horizontalpodautoscalers hpa autoscaling true HorizontalPodAutoscaler
cronjobs cj batch true CronJob
jobs batch true Job
leases coordination.k8s.io true Lease
endpointslices discovery.k8s.io true EndpointSlice
events ev events.k8s.io true Event
ingresses ing extensions true Ingress
ingresses ing networking.k8s.io true Ingress
networkpolicies netpol networking.k8s.io true NetworkPolicy
poddisruptionbudgets pdb policy true PodDisruptionBudget
rolebindings rbac.authorization.k8s.io true RoleBinding
roles rbac.authorization.k8s.io true Role |
Pod
Pod 는 K8s에서 가장 기본적인 배포 단위로, 적어도 하나 이상의 컨테이너를 포함하는 단위이다.
다시 말해서, K8s는 컨테이너 하나하나의 단위로 관리하지 않고, 하나 이상의 컨테이너로 묶인 pod 단위로 관리한다.
...