This presentation start from basic concept such as container and container orchestration
And then go through Kubernetes internal especially Master Node components and Work Node components and show and explain core mechanism with codes.
15. kube-apiserver
§ 쿠버네티스 API를 노출하는 마스터 상의 컴포넌트. 쿠버네티스 컨트롤 플레인에 대한
프론트엔드이다.
§ 수평적 스케일(즉, 더 많은 인스턴스를 디플로이하는 스케일)을 위해 설계되었다.
etcd
§ 모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성·고가용성 키-값
저장소.
§ 쿠버네티스 클러스터 정보를 담고 있는 etcd 데이터에 대한 백업 계획은 필수이다.
kube-scheduler
§ 노드가 배정되지 않은 새로 생성된 파드를 감지하고 그것이 구동될 노드를 선택하는 마스터 상의
컴포넌트.
§ 스케줄링 결정을 위한 어카운트 내 요소들로는 개별 및 공동의 리소스 요건,
하드웨어/소프트웨어/정책 제약, 친밀 및 배격 명세, 데이터 지역성, 워크로드-간 간섭,
데드라인들이 포함된다.
kube-controller-manager
§ 컨트롤러를 구동하는 마스터 상의 컴포넌트.
§ 논리적으로, 각 컨트롤러는 개별 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로
컴파일되고 단일 프로세스 내에서 실행된다.
§ 노드 컨트롤러: 노드가 다운되었을 때 통지와 대응에 관한 책임을 가진다.
§ 레플리케이션 컨트롤러: 알맞는 수의 파드들을 유지시켜 주는 책임을 가진다.
§ 엔드포인트 컨트롤러: 서비스와 파드를 연결시킨다
16. kubelet
§ 클러스터의 각 노드에서 실행되는 에이전트로 컨테이너가 포드에서 실행
중인지 확인합니다.
§ kubelet은 다양한 메커니즘을 통해 제공되는 PodSpec을 가져 와서 해당
PodSpec에 설명 된 컨테이너가 실행 중이며 건강한 상태를 유지하도록
합니다 .
§ kubelet은 Kubernetes가 생성하지 않은 컨테이너를 관리하지 않습니다.
kube-proxy
§ kube-proxy는 호스트 상에서 네트워크 규칙을 유지하고 연결에 대한
포워딩을 수행함으로서 쿠버네티스 서비스 추상화가 가능하도록 해준다.
Container Runtime
§ 컨테이너 런타임은 컨테이너의 동작을 책임지는 소프트웨어다.
쿠버네티스는 몇몇의 런타임을 지원하는데 Docker, containerd, cri-
o, rktlet 그리고 Kubernetes CRI (Container Runtime Interface)를 구현한
모든 런타임이다.
18. Pod IP : 10.244.2.xx : Node2
Pod IP : 10.244.1.xx : Node1
K8snode1
cni0 : 10.244.1.1
Docker0 : 172.17.0.1
Enp0s3 : 10.0.2.15
Enp0s8 : 192.168.56.111
Flannel.1 : 10.244.1.0
Pod
vethxxxx
CNI0 : 10.244.1
VB Net
19. § Components 상태
§ $kubectl get componentstatuses
§ Node 상태
§ $kubectl get node
§ Pod 상태
§ $kubectl get pod
20. § YAML Descriptor
§ Kind
§ Label
§ Replicas
§ Selector
§ MatchLabels
§ MatchExpression
§ Template
§ Spec
§ Container
§ Image
§ ports
§ Components 상태
§ $kubectl get componentstatuses
§ Node 상태
§ $kubectl get node
§ Pod 상태
§ $kubectl get pod
21. kubectl create -f https://k8s.io/examples/controllers/nginx-deployment.yaml
kubectl get rs
kubectl get deployments
kubectl get pods --show-labels
https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
22. kubectl get rs
kubectl scale --replicas=4 rs/nginx-deployment-75bd58f5c7
kubectl get pods --show-labels
https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
kubectl get po ngnix-deployment-xxx –o yaml
kubectl edit po ngnix-deployment-xxx –o yaml
33. § Namespace
§ Hostname
§ Process IDs
§ File System
§ Network interfaces
§ Inter-Process Communication (IPC)
§ Cgroup(Control Group)
§ CPU
§ RAM
§ Block I/O
§ Network I/O
Cgroups = limits how much you can use;
namespaces = limits what you can see (and therefore use)
https://www.ianlewis.org/en/what-are-kubernetes-pods-anyway
35. § Hostname
§ Network
§ IPC
§ Volume 공유
§ 특징
§ 단일 컨테이너 당 하나의 파드
§ 또는 다중 컨테이너 (Side - Car)
§ 스케일링의 단위
- Deployment
- StatefulSet
- DamonSet
https://www.ianlewis.org/en/what-are-kubernetes-pods-anyway
41. Confidential – Oracle Internal/Restricted/Highly Restricted 41
Master Component
- API Server
42. § RESTful API를 통해서 kubectl와 같은 클라이언트와 통신
§ RESTful API를 통해서 클러스터 상태를 쿼리 및 수정(CRUD)하고
§ 그정보를 etcd에 저장한다.
§ 모든 클라이언트와 컴포넌트는 오직 API 서버를 통해서만 상호작용한다.
§ 클러스터에 대한 Gatekeeper 역할을 하며, 인증(Authen), 권한(Authoriz), 객체의 유효성
검사(Validation) and admission control
§ JSON 기반의 HTTP API 가 기본이지만, 클러스터 내부 통신은 Protocol Buffer 도 지원
43. § API 버전 규칙
§ 리소스나 필드 수준보다는 API 레벨에서 버전을 선택했는데, API가 명료하고, 시스템 리소스와
행위 관점에서 일관성있으며, 더 이상 사용하지 않는 API나 실험적인 API에 접근을 제어할 수
있도록 하기 위함이다.
§ Alpha(ex: v1alpha1)
§ 버그가 있을 수 있고, 기능을 활성화하면 버그가 노출될 수 있다. 기본적으로 비활성화
§ Beta (ex: v2beta3)
§ 코드가 잘 테스트되었고, 안정하다. 기본적으로 활성화
§ Stable(ex: v2)
§ 안정화버전
44. § 쿠버네티스 API를 보다 쉽게 확장하기 위해서, API 그룹을 구현했다. API 그룹은 REST 경로와 직렬화된
객체의 apiVersion 필드에 명시된다.
§ 현재 다양한 API 그룹이 사용되고 있다.
§ 핵심 그룹 또는 레거시 그룹 이라고 하는 그룹은 REST 경로 /api/v1에서 apiVersion: v1을 사용한다.
§ 이름이 있는 그룹은 REST 경로 /apis/$GROUP_NAME/$VERSION에 있으며 apiVersion:
$GROUP_NAME/$VERSION을 사용한다 (예: apiVersion: batch/v1). 지원되는 API 그룹 전체의
목록은 Kubernetes API reference에서 확인할 수 있다.
45.
46. § kubectl create -f xxx.yaml
à json Converting
§ 인증, 권한
§ 요청한 Client의 인증서(key, token)
를 검사
§ 요청된 액션을 수행할 권한 체크
§ Admission Control
§ 리소스 스펙에 누락된 것을
디폴트값이나 상속된 값으로 채움
§ Ex) AlwaysPullImages
NamespaceLifeCycle
§ Resource Validation
§ ETCD에 /Registry 밑에 계층구조로 저장
47. § 1. API 그룹 조회
§ 2. 노드 리스트 조회
- http://127.0.0.1:8001/api/v1/nodes/
- http://127.0.0.1:8001/api/v1/nodes/k8snode1
50. kube-controller-manager
컨트롤러를 구동하는 마스터 상의 컴포넌트.
논리적으로, 각 컨트롤러는 개별 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고
단일 프로세스 내에서 실행된다.
API 서버를 통해서 Shared State(ETCD)의 정보를 Control loop를 통해 감시(watch)하고 있다가 Current
State를 Desired State로 변경을 시도한다.
이들 컨트롤러는 다음을 포함한다. (약 26개)
•노드 컨트롤러: 노드가 다운되었을 때 통지와 대응에 관한 책임을 가진다.
•레플리케이션 컨트롤러: 시스템의 모든 레플리케이션 컨트롤러 오브젝트에 대해 알맞는 수의 파드들을
유지시켜 주는 책임을 가진다.
•엔드포인트 컨트롤러: 엔드포인트 오브젝트를 채운다(즉, 서비스와 파드를 연결시킨다.)
•서비스 어카운트 & 토큰 컨트롤러: 새로운 네임스페이스에 대한 기본 계정과 API 접근 토큰을 생성한다.
53. 모든 컨트롤러는 API 서버를 통해 API 오브젝트를 가지고 동작한다.
컨트롤러는 Kubelet와 직접 통신하거나 어떤 종류의 명령도 내리지 않는다. 사실 kubelet의 존재하는지
조차 알지 못한다.
컨트롤러가 API 서버에서 리소스를 업데이드한 이후로 Kubelets와 쿠버네티스 서비스 프록시는 컨트롤러의
존재를 알지 못한다. 그리고 포드의 컨테이너를 회전시키고 네트워크 스토리지에 연결하거나 포드의 실제
로드 밸런싱을 설정한다.
컨트롤 플레인은 전체 시스템 동작의 한 부분을 처리하므로, 이런 동작이 쿠버네티스 클러스터에서 어떻게
펼쳐지는지 완전히 이해하려면 kubelet과 서비스 프록시가 하는 일을 이해할 필요가 있다.
55. So let’s see how the scheduling lifecycle really looks
like:
1.A pod is created and its desired state is saved
to etcd with the node name unfilled.
2.The scheduler somehow notices that there is a
new pod with no node bound.
3.It finds the node that best fits that pod.
4.Tells the apiserver to bind the pod to the node ->
saves the new desired state to etcd.
5.Kubelets are watching bound pods through
the apiserver, and start the containers on the
particular node.
https://banzaicloud.com/blog/k8s-custom-scheduler/
56. 단순화한 Scheduler
- client-go library의 watch를 이용해 Event를 받는데 FieldSelector 에 spec.nodeName=’’
- 노드가 할당되지 않은 pod에만 관심
- Scheduling 에 관련된 Factor
58. § 쿠버네티스 클러스터의 저장소
§ 빠르고, 분산되며, 일관된 Key-Value Store
§ Raft Consensus algorithm
§ 클러스터는 fault-tolerant를 위해 3,5,7 과 같은
홀수개로 운영
§ 정족수(quorum)
59. Master 노드의 ETCD Pod로 들어가서 그안의 etcdctl 을 아래처럼 부르면 조회 가능
ETCDCTL_API = 3 etcdctl --cacert =/etc/kubernetes/pki/etcd/ca.crt --cert
=/etc/kubernetes/pki/etcd/peer.crt --key =/etc/kubernetes/pki/etcd/peer.key get
/registry/namespaces/default -w=json | jq .
•base64로 인코딩되어 있기 때문에 base64로 디코딩해야 읽을 수 있다.
•이때 합의 알고리즘 “raft_term”:14도 보인다.
62. Node에서 Agent 역할을 하며 하며 Pod의 Lifecycle 을 관리한다.
지속적으로 실행중인 컨테이너를 모니터링하고 상태와 이벤트, 리소스등을 API 서버에 보고 한다.
1) Pod Management
2) Contiainer Health Check
3) Contiainer Monitoring
- Resouce Usage from
cAdvisor
§ File path
§ URL HTTP Endpoint
§ API Server
63. kubelet의 구성 요소
§ Kubelet Server는 kube-apiserver 및 metrics-server와 같은
서비스 호출을위한 API를 제공합니다. 예를 들어, kubectl
exec는 Kubelet API / exec / {token}을 통해 컨테이너와 상호
작용해야합니다.
Read
Only API
64.
65. kubelet의 구성 요소
§ 컨테이너 관리자는 CGroups, QoS, cpuset, device 등과 같은
컨테이너의 다양한 자원을 관리합니다.
§ 볼륨 관리자는 디스크의 포맷, 노드 로컬에 마운트,
마지막으로 마운트 경로를 컨테이너에 전달하는 것과 같이
컨테이너의 스토리지 볼륨을 관리합니다.
§ Eviction 관리자 는 자원이 충분하지 않을 때 우선 순위가
낮은 컨테이너의 퇴출 시키는 것과 같이 우선 순위가 높은
컨테이너의 운영을 보장하기 위해 컨테이너 퇴거를
담당합니다.
§ cAdvisor는 컨테이너에 Metrics를 제공합니다.
§ 메트릭 및 통계는 메트릭과 같은 컨테이너 및 노드에 대한
메트릭을 제공합니다. / stats / summary를 통해 추출 된 서버
메트릭은 HPA의 자동 확장을위한 기본 요소입니다.
§ 일반 런타임 관리자는 CRI 상호 작용 및 컨테이너 및 미러링
관리를 담당하는 컨테이너 런타임 관리자입니다.