본문 바로가기
DevOps/K8S

[Kubernetes] 쿠버네티스 자주 등장하는 용어 정리

by 스파이디웹 2022. 10. 29.
728x90

쿠버네티스 관련 용어

1. 오브젝트 (Object)

  • K8s 시스템의 엔티티(최소의 기능을 하는 단위)로서, 파드나 서비스 컨트롤러같은 인스턴스를 지칭
  • 오브젝트는 같은 네임스페이스에서 같은 종류 오브젝트가 다수 존재할 경우 이 오브젝트들은 각각 다른 이름을 가져야만 함

2. 파드 (Pod)

  • 컨테이너를 실행하기 위한 오브젝트
  • 파드에서는 한 개 혹은 다수의 컨테이너를 담을 수 있음
  • 파드는 로깅과 같이 보완적인 기능을 추가하기 위한 사이드카 컨테이너를 선택적으로 실행할 수 있음
  • 파드는 보통 디플로이먼트에 의해서 관리
  • deployment에는 등록되지 않은 pod는? deployment vs pod 보고 정리

3. 워크로드 (Workload)

  • K8S에서 구동되는 애플리케이션
  • 오브젝트들을 묶어서 나타내는 하나의 그룹
  • 데몬셋, 디플로이먼트, 잡, 레플리카셋, 그리고 스테이트풀셋 오브젝트를 포함해서 서로 다른 워크로드의 유형이나 부분을 대표하는 다양한 핵심 오브젝트
    ex) 웹 서버와 데이터베이스가 있는 워크로드는 데이터베이스를 한 스테이트풀셋 안에서 실행할 것이며, 웹서버를 디플로이먼트를 통해 실행할 것

4. 클러스터 (Cluster)

컨테이너로 구성된 애플리케이션을 실행하는 노드의 집합

5. 컨트롤러 (Controller)

  • 컨트롤러는 API 서버를 통하여 클러스터의 상태를 확인하면서 파드의 실행을 제어하는 오브젝트
  • 컨트롤러에는 디플로이먼트(Deployment), 스테이트풀셋(StatefulSet) 등 여러 타입이 존재하며 각각의 기능을 이해하고 목적에 맞게 구별하여 사용해야 함
  • 일부 컨트롤러는 컨트롤 플레인 내부에서 실행되며, 쿠버네티스 작업의 핵심인 컨트롤 루프를 제공
    ex) 디플로이먼트 컨트롤러, 데몬셋 컨트롤러, 네임스페이스 컨트롤러 그리고 퍼시스턴트 볼륨 컨트롤러(및 그 외)는 모두 "kube-controller-manager" 내에서 실행

6. 쿠버네티스 API (Kubernetes API)

  • RESTFul 인터페이스를 통하여 쿠버네티스의 기능을 제공하고 클러스터의 상태를 저장하는 애플리케이션
  • 쿠버네티스에 대한 조작은 API를 통해 이루어지며 사용자는 kubectl을 사용하여 상호 작용할 수 있음
  • 쿠버네티스 리소스와 "의도에 대한 레코드"는 모두 API 오브젝트로 저장되며, API로의 RESTful 호출을 통해서 수정
  • API는 구성이 선언적인 방법으로 관리되도록 함
  • 사용자는 쿠버네티스 API와 직접 상호 작용할 수 있으며, kubectl과 같은 툴을 사용할 수도 있음
  • 쿠버네티스 API의 핵심은 유연하며 사용자 정의 리소스를 지원하기 위해 확장될 수도 있음

7. API 서버(kube-apiserver)

  • 쿠버네티스 API를 노출하는 쿠버네티스 컨트롤 플레인 컴포넌트
  • 쿠버네티스 컨트롤 플레인의 프론트 엔드
  • 쿠버네티스 API 서버의 주요 구현은 kube-apiserver
  •  kube-apiserver는 수평으로 확장되도록 디자인 즉, 더 많은 인스턴스를 배포해서 확장할 수 있음
  • 여러 kube-apiserver 인스턴스를 실행하고, 인스턴스간의 트래픽을 균형있게 조절

8. 서비스 (Service)

  • 사용자와 파드를 연결하는 역할을 수행
  • 네트워크 트래픽을 현재 워크로드를 위한 파드 집합으로 보낼 수 있는지 판별
  • 파드 집합에서 실행중인 애플리케이션을 네트워크 서비스로 노출하는 추상화 방법
  • 서비스의 대상이 되는 파드 집합은 (보통) 셀렉터로 결정
  • 많은 파드가 추가되거나 제거되면, 셀렉터와 일치하는 파드의 집합도 변경, 서비스는 네트워크 트래픽을 현재 워크로드를 위한 파드 집합으로 보낼 수 있는지 확인
  • deployment(pod)가 제거되면 service는 등록되어 있더라도, 실제로 svc를 담는 pod가 사라지므로 접근을 하려해도 할 수 없음

9. 컨트롤 플레인 (Control Plane)

  • 컨테이너의 라이프사이클을 정의, 배포, 관리하기 위한 API와 인터페이스들을 갖는 컨테이너 오케스트레이션 레이어
  • etcd, API 서버, 스케줄러, 컨트롤러 매니저, 클라우드 컨트롤러 매니저 같은 컴포넌트들로 구성

10. kube-controller-manager

  • 컨트롤러 프로세스를 실행하는 컨트롤 플레인 컴포넌트
  • 논리적으로, 각 컨트롤러는 분리된 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고 단일 프로세스 내에서 실행

11. kube-proxy

  • kube-proxy는 클러스터의 각 노드에서 실행되는 네트워크 프록시로, 쿠버네티스의 서비스 개념의 구현부
  • kube-proxy는 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신을 할 수 있도록 해줌
  • kube-proxy는 운영 체제에 가용한 패킷 필터링 계층이 있는 경우, 이를 사용. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)

12. kubectl

  • 쿠버네티스 API를 사용하여 쿠버네티스 클러스터의 컨트롤플레인과 통신하기 위한 커맨드라인 툴
  • 쿠버네티스 오브젝트를 생성, 점검, 업데이트, 삭제할 때 사용

13. kubelet

  • 클러스터의 각 노드에서 실행되는 에이전트
  • Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리
  • Kubelet은 다양한 메커니즘을 통해 제공된 파드 스펙(PodSpec)의 집합을 받아서 컨테이너가 해당 파드 스펙에 따라 건강하게 동작하는 것을 확실히 함
  • Kubelet은 쿠버네티스를 통해 생성되지 않는 컨테이너는 관리하지 않음

14. namespace

  • 쿠버네티스에서 하나의 클러스터 내에서 리소스 그룹의 격리를 지원하기 위해 사용하는 추상적 개념
  • 네임스페이스는 클러스터의 오브젝트를 체계화하고 클러스터의 리소스를 분리하는 방법을 제공
  • 리소스의 이름은 네임스페이스 내에서 유일해야 함. 그러나, 네임스페이스 간에서 유일할 필요는 없음

15. 데이터 플레인

컨테이너가 실행되고 네트워크에 연결될 수 있게 CPU, 메모리, 네트워크, 스토리지와 같은 능력을 제공하는 레이어

16. deployment

  • 일반적으로 로컬 상태가 없는 파드를 실행하여 복제된 애플리케이션을 관리하는 API 오브젝트
  • 각 레플리카는 파드로 표현되며, 파드는 클러스터의 노드에 분산된다. 로컬 상태가 필요한 워크로드의 경우 스테이트풀셋의 사용을 고려
  • deployment를 expose하게 되면 service가 된다.(외부-사용자가 접근 할 수 있는 형태)

17. node

  • 노드는 쿠버네티스의 작업 장비(worker machine)
  • 작업 노드는 클러스터에 따라 VM이거나 물리 머신
  • 파드 실행에 필요한 로컬 데몬과 서비스를 가지고 있으며, 콘트롤 플레인에 의해서 관리
  • 노드에 있는 데몬은 kubelet, kube-proxy와 도커(Docker) 같이 컨테이너 런타임을 구현한 CRI를 포함

18. docker

도커(구체적으로, 도커 엔진)는 운영 시스템 수준의 가상화를 제공하는 소프트웨어 기술이며, containers로도 알려져 있음

19. docker shim

  • 도커심(Dockershim)은 쿠버네티스 버전 1.23 이하의 구성 요소이다. kubelet이 도커엔진과 통신할 수 있게 함
  • 1.24버전 부터 도커심(Dockershim)은 쿠버네티스에서 제거
    -> 쿠버네티스 자체에 도커심을 대체할 코드를 추가시켰음

20. replica pod set

  • 레플리카셋은 (목표로) 주어진 시간에 실행되는 레플리카 파드 셋을 유지 관리
  • 디플로이먼트(Deployment) 와 같은 워크로드 오브젝트는 레플리카셋을 사용해서 해당 레플리카셋의 스펙에 따라 구성된 파드 의 수를 클러스터에서 실행

21. 매니페스트(manifest)

  • JSON 또는 YAML 형식으로 명시한 쿠버네티스 API 오브젝트의 명세
  • 매니페스트는 사용자가 해당 매니페스트를 적용했을 때 쿠버네티스가 유지해야 하는 오브젝트의 의도한 상태(desired state)를 나타낸다. 각 구성 파일은 여러 매니페스트를 포함할 수 있음

22. 애플리케이션

컨테이너화된 다양한 애플리케이션들이 실행되는 레이어

23. 어노테이션(Annotation)

  • 임의의 식별되지 않는 메타데이터를 오브젝트에 첨부할 때 이용하는 키-밸류 쌍.
  • 어노테이션으로 된 메타데이터는 작거나 클 수 있고, 구조화되어 있거나 구조화되어 있지 않을 수도 있고, 레이블에서는 허용되지 않는 문자도 포함할 수 있음
  • 툴과 라이브러리와 같은 클라이언트로 메타데이터를 검색할 수 있음

24. 컨테이너(Container)

  • 소프트웨어와 그것에 종속된 모든 것을 포함한 가볍고 휴대성이 높은 실행 가능 이미지
  • 컨테이너는 애플리케이션과 기반이 되는 호스트 인프라의 관계를 분리시켜서, 애플리케이션을 다른 클라우드 또는 OS 환경에서도 쉽게 디플로이하고 쉽게 스케일되게 함

25. 컨테이너 런타임(Container run time)

  • 컨테이너 런타임은 컨테이너 실행을 담당하는 소프트웨어
  • 쿠버네티스는 container-d,CRI-O와 같은 컨테이너 런타임 및 모든 Kubernetes CRI (컨테이너 런타임 인터페이스) 구현체를 지원

26. 잡(JOB)

  • 완료를 목표로 실행되는 유한 또는 배치 작업
  • 하나 이상의 파드 오브젝트를 생성하고 지정된 수의 파드가 성공적으로 종료되는지 확인
  • 파드가 성공적으로 완료됨에 따라, 잡은 해당 성공적인 완료를 추적

27. etcd

  • 모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성·고가용성 키-값 저장소.
  • 엣시디라고 읽기도하지만 원래는 etc + d 이다. etc daemon
  • etcd와 직접적으로 통신하는 유일한 컴포넌트는 API server
  • 모든 컴포넌트는 API server를 이용하여 etcd에 데이터를 읽고 씀. 즉 쿠버네티스 클러스터 상태 및 메타 데이터를 저장하는 유일한 장소

 

 

출처:

https://kubernetes.io/ko/docs/reference/glossary/?fundamental=true

728x90

댓글