Kubernetes 05 - Kubernetes Architecture 2

Introduction to Kubernetes

출처 : https://courses.edx.org/courses/course-v1:LinuxFoundationX+LFS158x+3T2020/course/#block-v1:LinuxFoundationX+LFS158x+3T2020+type@chapter+block@48d68448eff24f02bcb78470dec9c6a1

이미지 출처 : https://kubernetes.io/docs

Will Be Check

• Discuss the Kubernetes architecture.
• Explain the different components for master and worker nodes.
• Discuss about cluster state management with etcd.
• Review the Kubernetes network setup requirements.

내용이 또 많아서 다음 글에서 개인적인 풀이 올립니다.

Kubernetes Architecture

지난 글에는 Master Node을 이루는 구조들에 대해서 알아봤는데 이번에는 worker node에 대해서 작성했습니다.

worker node

worker node에 존재하는 구성 요소들은 다음과 같습니다.

• Container Runtime
• Node Agent - kubelet
• Proxy - kube-proxy
• Addons for DNS, Dashboard user interface, cluster-level monitoring and logging.

Worker Node Components

Container Runtime

• 전반적인 아키 텍처

쿠버네티스가 컨테이너 오케스트레이션 중 하나입니다. 하지만 직접적으로 container들을 직접 처리할 수 없습니다.

컨테이너의 라이프 사이클 관리하기 위해 워커 노드에 컨테이너 런타임이 필요합니다.

(컨테이너의 대표적인 Docker는 물론 CRI-o, contained, fraki 등등 에 대한 컨테이너들을 쿠버네티스는 관리할 수 있습니다.)

추가 ) containerd가 너무 막연하게 돼있어서 자료 추가합니다.

위의 그림을 보면 docker cli를 사용하다가 저점 갈수록 containerd를 통해서 container을 관리하게 됐습니다.

위의 이미지 출처 및 설명과 docker와 성능 비교한 것도 있으니 아래 링크 한번 들어가 보시는 걸 추천합니다.

https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/

Node Agent - kubelet

워커 노드 각각에 존재하는 kubectl 마스터 노드에서 이미 본 API server를 통해서 쿠버네티스로 부터 정보를 가져와서 이를 가지고 컨테이너 런타임과 상호작용하면서 컨테이너들을 실행합니다.

위에서 그림에 보면 CRI(Command Line Interface)를 통해서 container runtime과 소통하는 걸 볼 수 있는데 CRI에는 프로토컬 버퍼, gRPC API, library 및 개발 중인 내용들이 있습니다.

위의 그림은 kubelet과 CRI는 grpc로 연결돼있고 서로 통신하고 있는 상태입니다.

CRI에는 2개지 기능이 있습니다.

Image Service : 모든 이미지 관련 작업을 담당합니다.

Runtime Service는 모든 pod와 컨테이너 관련 작업을 당 담합니다.

kubelet - CRI shims

Container Runtime은 kubelet으로 하드 코딩되어있습니다. 하지만 점점 유연하게 변경되고 있습니다.

shim은 Kubernetes에서 지원하는 각 컨테이너 런타임에 특정한 CRI 구현 또는 인터페이스입니다.

Docker는 물론 CRI-o, contained, fraki에서도 kubelet이 작동하게끔 하는 중간에 존재하는 인터페이스

Proxy - kube-proxy

kube-proxy는 노드의 모든 네트워킹 규칙의 동적 업데이트 및 유지 관리를 담당하는 각 노드에서 실행되는 네트워크 에이전트입니다.

포워딩을 담당하며, service API 객체를 통해서 사용자가 정의한 포워딩 규칙을 구현합니다.

위의 말을 쉽게 이야기하자면

k8s의 서비스 정보를 스포 해서 알려드리면 A라는 컨테이너를 1개를 쿠버 네티스에 배포했는데 그런데 A가 죽어버려서 새로운 A를 배포하더라도 client가 A라는 서비스를 찾을 때 죽은 A로는 신호가 안 가고 새로운 A로만 신호를 가게 합니다.

이럴 때 A라는 서비스는 여기로 와야 합니다! 를 알려주는 게 kube-proxy의 역할이라고 보시면 됩니다.

즉, 컨테이너들의 죽고 새로 배포되는 상황에서도 네트워크 주소를 매번 갱신하며 알려주는 역할을 한다고 보시면 됩니다.

• 개인적으로는 pod, container 내용을 자세히 설명하지 않았는데 원문에는 자주 등장해서 어떻게 말을 해야 할지 당황스럽네요 ㅋㅋ

• 아키텍처가 내용이 많아서 다음 글에 Networking Challenges 내용을 올리고 마무리하겠습니다.

  will be check 언제하지...