용어집

이 용어집은 쿠버네티스 용어의 종합적이고 표준화된 리스트를 제공한다. 용어집은 K8s 고유의 기술 용어 뿐만 아니라, 맥락을 이해하는데 유용한 더 일반적인 용어도 포함한다.

다음 [+] 표시를 클릭하면 각 용어에 대한 더 자세한 설명을 볼 수 있다.

• API 그룹(API Group)LINK

  쿠버네티스 API의 연관된 경로들의 집합.

  [+]

  API 서버의 구성을 변경하여 각 API 그룹을 활성화하거나 비활성화할 수 있다. 특정 리소스에 대한 경로를 비활성화하거나 활성화할 수도 있다. API 그룹을 사용하면 쿠버네티스 API를 더 쉽게 확장할 수 있다. API 그룹은 REST 경로 및 직렬화된 오브젝트의 apiVersion 필드에 지정된다.

  • 자세한 내용은 [API 그룹(/ko/docs/concepts/overview/kubernetes-api/#api-그룹과-버전-규칙)을 참조한다.
• API 서버LINK

  별칭:kube-apiserver
  

  API 서버는 쿠버네티스 API를 노출하는 쿠버네티스 컨트롤 플레인 컴포넌트이다. API 서버는 쿠버네티스 컨트롤 플레인의 프론트 엔드이다.

  [+]

  쿠버네티스 API 서버의 주요 구현은 kube-apiserver 이다. kube-apiserver는 수평으로 확장되도록 디자인되었다. 즉, 더 많은 인스턴스를 배포해서 확장할 수 있다. 여러 kube-apiserver 인스턴스를 실행하고, 인스턴스간의 트래픽을 균형있게 조절할 수 있다.

• API를 이용한 축출(Eviction)LINK

  API를 이용한 축출은 축출 API를 사용하여 생성된 Eviction 오브젝트로 파드를 정상 종료한다.

  [+]

  kubectl drain 명령과 같은 kube-apiserver의 클라이언트를 사용하여 축출 API를 직접 호출해 축출 요청을 할 수 있다. Eviction 오브젝트가 생성되면, API 서버가 파드를 종료한다.

  API를 이용한 축출은 사용자가 설정한 PodDisruptionBudgets 및 terminationGracePeriodSeconds 값을 준수한다.

  API를 이용한 축출은 노드-압박 축출과 동일하지 않다.

  • 더 많은 정보는 API를 이용한 축출을 참고한다.
• Application ArchitectLINK

  A person responsible for the high-level design of an application.

  [+]

  An architect ensures that an app's implementation allows it to interact with its surrounding components in a scalable, maintainable way. Surrounding components include databases, logging infrastructure, and other microservices.

• Application DeveloperLINK

  A person who writes an application that runs in a Kubernetes cluster.

  [+]

  An application developer focuses on one part of an application. The scale of their focus may vary significantly in size.

• cAdvisorLINK

  cAdvisor (Container Advisor) provides container users an understanding of the resource usage and performance characteristics of their running containers.

  [+]

  It is a running daemon that collects, aggregates, processes, and exports information about running containers. Specifically, for each container it keeps resource isolation parameters, historical resource usage, histograms of complete historical resource usage and network statistics. This data is exported by container and machine-wide.

• cgroupLINK

  선택적으로 리소스를 격리, 관리, 제한하는 리눅스 프로세스의 그룹.

  [+]

  cgroup은 프로세스 집합에 대해서 리소스 사용(CPU, 메모리, 디스크 I/O, 네트워크)을 격리하고, 관리하며, 제한하는 리눅스 커널 기능이다.

• CIDRLINK

  CIDR (Classless Inter-Domain Routing)은 IP 주소 블록을 설명하는 표기법으로 다양한 네트워킹 구성에서 많이 사용한다.

  [+]

  쿠버네티스에서는 CIDR을 사용하여 시작 주소와 서브넷 마스크로 각 노드에 IP 주소 범위를 할당한다. 이를 통해 노드는 각 파드에 고유한 IP 주소를 할당할 수 있다. 원래 IPv4를 위한 개념이었지만 CIDR은 IPv6도 포함하도록 확장됐다.

• CLA (컨트리뷰터 사용권 계약|Contributor License Agreement)LINK

  컨트리뷰터가 기여한 것에 대한 사용권을 오픈 소스 프로젝트에 허락하는 계약 조건.

  [+]

  CLA는 기부된 자료 및 지적 재산권(IP)과 관련된 법적 분쟁을 해결하는 데 도움이 됩니다.

• Cluster ArchitectLINK

  A person who designs infrastructure that involves one or more Kubernetes clusters.

  [+]

  Cluster architects are concerned with best practices for distributed systems, for example: high availability and security.

• containerdLINK

  A container runtime with an emphasis on simplicity, robustness and portability

  [+]

  containerd is a container runtime that runs as a daemon on Linux or Windows. containerd takes care of fetching and storing container images, executing containers, providing network access, and more.

• CRI-OLINK

  A tool that lets you use OCI container runtimes with Kubernetes CRI.

  [+]

  CRI-O is an implementation of the Container runtime interface (CRI) to enable using container runtimes that are compatible with the Open Container Initiative (OCI) runtime spec.

  Deploying CRI-O allows Kubernetes to use any OCI-compliant runtime as the container runtime for running Pods, and to fetch OCI container images from remote registries.

• Downstream (disambiguation)LINK

  May refer to: code in the Kubernetes ecosystem that depends upon the core Kubernetes codebase or a forked repo.

  [+]

  • In the Kubernetes Community: Conversations often use downstream to mean the ecosystem, code, or third-party tools that rely on the core Kubernetes codebase. For example, a new feature in Kubernetes may be adopted by applications downstream to improve their functionality.
  • In GitHub or git: The convention is to refer to a forked repo as downstream, whereas the source repo is considered upstream.
• Downward APILINK

  Kubernetes' mechanism to expose Pod and container field values to code running in a container.

  [+]

  It is sometimes useful for a container to have information about itself, without needing to make changes to the container code that directly couple it to Kubernetes.

  The Kubernetes downward API allows containers to consume information about themselves or their context in a Kubernetes cluster. Applications in containers can have access to that information, without the application needing to act as a client of the Kubernetes API.

  There are two ways to expose Pod and container fields to a running container:

  • using environment variables
  • using a downwardAPI volume

  Together, these two ways of exposing Pod and container fields are called the downward API.

• EndpointSliceLINK

  A way to group network endpoints together with Kubernetes resources.

  [+]

  A scalable and extensible way to group network endpoints together. These can be used by kube-proxy to establish network routes on each node.

• etcdLINK

  모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성·고가용성 키-값 저장소.

  [+]

  쿠버네티스 클러스터에서 etcd를 뒷단의 저장소로 사용한다면, 이 데이터를 백업하는 계획은 필수이다.

  etcd에 대한 자세한 정보는, 공식 문서를 참고한다.

• FlexVolumeLINK

  FlexVolume is a deprecated interface for creating out-of-tree volume plugins. The Container Storage Interface is a newer interface that addresses several problems with FlexVolume.

  [+]

  FlexVolumes enable users to write their own drivers and add support for their volumes in Kubernetes. FlexVolume driver binaries and dependencies must be installed on host machines. This requires root access. The Storage SIG suggests implementing a CSI driver if possible since it addresses the limitations with FlexVolumes.

  • FlexVolume in the Kubernetes documentation
  • More information on FlexVolumes
  • Volume Plugin FAQ for Storage Vendors
• Horizontal Pod AutoscalerLINK

  별칭:HPA
  

  CPU 사용률 또는 사용자 정의 메트릭을 기반으로 파드의 레플리카 수를 자동으로 조절하는 API 리소스이다.

  [+]

  HPA는 일반적으로 레플리케이션 컨트롤러, 디플로이먼트, 레플리카셋과 함께 사용된다. 조절할 수 없는 개체(예: 데몬셋)에는 적용할 수 없다.

• IstioLINK

  마이크로서비스의 통합을 위한 통일된 방법을 제공하는 오픈 플랫폼(쿠버네티스에 특정적이지 않음)이며, 트래픽 흐름을 관리하고, 정책을 시행하고, 텔레메트리 데이터를 모은다.

  [+]

  Istio를 추가하는 것은 애플리케이션 코드 변경을 요구하지 않는다. 그것은 서비스와 네트워크 사이의 인프라스트럭처 레이어이다. 이는 서비스 디플로이먼트와 조합되었을 때, 일반적으로 서비스 메시라고 일컫는다. Istio의 컨트롤 플레인은 쿠버네티스, Mesosphere 등과 같은 하부의 클러스터 관리 플랫폼을 추상화한다.

• KopsLINK

  A CLI tool that helps you create, destroy, upgrade and maintain production-grade, highly available, Kubernetes clusters.

  [+]

  Note: kops has general availability support only for AWS. Support for using kops with GCE and VMware vSphere are in alpha.

  kops provisions your cluster with:

  • Fully automated installation
  • DNS-based cluster identification
  • Self-healing: everything runs in Auto-Scaling Groups
  • Limited OS support (Debian preferred, Ubuntu 16.04 supported, early support for CentOS & RHEL)
  • High availability (HA) support
  • The ability to directly provision, or to generate Terraform manifests

  You can also build your own cluster using Kubeadm as a building block. kops builds on the kubeadm work.

• kube-controller-managerLINK

  컨트롤러 프로세스를 실행하는 컨트롤 플레인 컴포넌트.

  [+]

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

• kube-proxyLINK

  kube-proxy는 클러스터의 각 노드에서 실행되는 네트워크 프록시로, 쿠버네티스의 서비스 개념의 구현부이다.

  [+]

  kube-proxy는 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다.

  kube-proxy는 운영 체제에 가용한 패킷 필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)한다.

• kube-schedulerLINK

  노드가 배정되지 않은 새로 생성된 파드 를 감지하고, 실행할 노드를 선택하는 컨트롤 플레인 컴포넌트.

  [+]

  스케줄링 결정을 위해서 고려되는 요소는 리소스에 대한 개별 및 총체적 요구 사항, 하드웨어/소프트웨어/정책적 제약, 어피니티(affinity) 및 안티-어피니티(anti-affinity) 명세, 데이터 지역성, 워크로드-간 간섭, 데드라인을 포함한다.

• kubeadmLINK

  쿠버네티스를 빠르게 설치하고 안전한(secure) 클러스터를 설정하는 도구

  [+]

  kubeadm을 사용하여 컨트롤 플레인과 워커 노드 구성 요소를 설치할 수 있다.

• KubectlLINK

  별칭:kubectl
  

  쿠버네티스 API를 사용하여 쿠버네티스 클러스터의 컨트롤 플레인과 통신하기 위한 커맨드라인 툴

  [+]

  사용자는 쿠버네티스 오브젝트를 생성, 점검, 업데이트, 삭제하기 위해서 kubectl을 사용할 수 있다.

• KubeletLINK

  클러스터의 각 노드에서 실행되는 에이전트. Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리한다.

  [+]

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

• MasterLINK

  Legacy term, used as synonym for nodes hosting the control plane.

  [+]

  The term is still being used by some provisioning tools, such as kubeadm, and managed services, to label nodes with kubernetes.io/role and control placement of control plane pods.

• MinikubeLINK

  로컬에서 쿠버네티스를 실행하기 위한 도구.

  [+]

  Minikube는 VM이나 사용자 컴퓨터에서 단일 노드 클러스터를 실행한다. Minikube를 사용하여 학습 환경에서 쿠버네티스 시도하기를 할 수 있다.

• Operator patternLINK

  The operator pattern is a system design that links a Controller to one or more custom resources.

  [+]

  You can extend Kubernetes by adding controllers to your cluster, beyond the built-in controllers that come as part of Kubernetes itself.

  If a running application acts as a controller and has API access to carry out tasks against a custom resource that's defined in the control plane, that's an example of the Operator pattern.

• Platform DeveloperLINK

  A person who customizes the Kubernetes platform to fit the needs of their project.

  [+]

  A platform developer may, for example, use Custom Resources or Extend the Kubernetes API with the aggregation layer to add functionality to their instance of Kubernetes, specifically for their application. Some Platform Developers are also contributors and develop extensions which are contributed to the Kubernetes community. Others develop closed-source commercial or site-specific extensions.

• Pod Disruption BudgetLINK

  별칭:PDB
  

  A Pod Disruption Budget allows an application owner to create an object for a replicated application, that ensures a certain number or percentage of Pods with an assigned label will not be voluntarily evicted at any point in time.

  [+]

  Involuntary disruptions cannot be prevented by PDBs; however they do count against the budget.

• QoS 클래스(QoS Class)LINK

  QoS 클래스(서비스 품질 클래스)는 쿠버네티스가 클러스터 안의 파드들을 여러 클래스로 구분하고, 스케줄링과 축출(eviction)에 대한 결정을 내리는 방법을 제공한다.

  [+]

  파드의 QoS 클래스는 생성 시점의 컴퓨팅 리소스 요청량과 제한 값에 기반해서 설정된다. QoS 클래스는 파드의 스케줄링과 축출을 위한 결정을 내릴 때 사용된다. 쿠버네티스는 파드에 Guaranteed, Burstable 또는 BestEffort 중 하나를 QoS 클래스로 할당할 수 있다.

• RBAC(역할 기반 엑세스 제어)LINK

  인가 결정을 관리하며, 운영자가 쿠버네티스 API를 통해서 동적으로 엑세스 정책을 설정하게 해준다.

  [+]

  RBAC은 퍼미션(permission) 규칙을 포함하는 역할 과 역할에 정의된 퍼미션을 사용자 집합에 부여하는 역할 바인딩 을 이용한다.

• Security ContextLINK

  The securityContext field defines privilege and access control settings for a Pod or container.

  [+]

  In a securityContext, you can define: the user that processes run as, the group that processes run as, and privilege settings. You can also configure security policies (for example: SELinux, AppArmor or seccomp).

  The PodSpec.securityContext setting applies to all containers in a Pod.

• Shuffle-shardingLINK

  A technique for assigning requests to queues that provides better isolation than hashing modulo the number of queues.

  [+]

  We are often concerned with insulating different flows of requests from each other, so that a high-intensity flow does not crowd out low-intensity flows. A simple way to put requests into queues is to hash some characteristics of the request, modulo the number of queues, to get the index of the queue to use. The hash function uses as input characteristics of the request that align with flows. For example, in the Internet this is often the 5-tuple of source and destination address, protocol, and source and destination port.

  That simple hash-based scheme has the property that any high-intensity flow will crowd out all the low-intensity flows that hash to the same queue. Providing good insulation for a large number of flows requires a large number of queues, which is problematic. Shuffle-sharding is a more nimble technique that can do a better job of insulating the low-intensity flows from the high-intensity flows. The terminology of shuffle-sharding uses the metaphor of dealing a hand from a deck of cards; each queue is a metaphorical card. The shuffle-sharding technique starts with hashing the flow-identifying characteristics of the request, to produce a hash value with dozens or more of bits. Then the hash value is used as a source of entropy to shuffle the deck and deal a hand of cards (queues). All the dealt queues are examined, and the request is put into one of the examined queues with the shortest length. With a modest hand size, it does not cost much to examine all the dealt cards and a given low-intensity flow has a good chance to dodge the effects of a given high-intensity flow. With a large hand size it is expensive to examine the dealt queues and more difficult for the low-intensity flows to dodge the collective effects of a set of high-intensity flows. Thus, the hand size should be chosen judiciously.

• SIG(special interest group)LINK

  대규모 쿠버네티스 오픈소스 프로젝트에서 진행되는 내용을 공동으로 관리하는 커뮤니티 멤버들이다.

  [+]

  SIG 멤버들은 아키텍처, API, 또는 문서화 같이 특정 영역을 발전시키는 데 공통적으로 관심을 갖고 있다. 기본적으로 SIG 거버넌스 지침을 따라야 하지만, 자체적으로 기여 정책이나 소통 채널을 가질 수 있다.

  자세한 내용은 kubernetes/community 저장소 및 현재 존재하는 SIG 및 WG 목록을 참조한다.

• sysctlLINK

  sysctl은 동작 중인 유닉스 커널의 속성을 읽거나 수정하는 데 사용하는 (준)표준 인터페이스이다.

  [+]

  유닉스 계열 시스템에서 sysctl은 관리자가 이러한 설정을 확인하고 수정하는데 사용하는 도구의 이름이기도 하고, 해당 도구가 사용하는 시스템 콜이기도 하다.

  컨테이너 런타임과 네트워크 플러그인은 특정 방식으로 설정된 sysctl 값에 의존성이 있을 수 있다.

• UIDLINK

  오브젝트를 중복 없이 식별하기 위해 쿠버네티스 시스템이 생성하는 문자열.

  [+]

  쿠버네티스 클러스터가 구동되는 전체 시간에 걸쳐 생성되는 모든 오브젝트는 서로 구분되는 UID를 갖는다. 이는 기록상 유사한 오브젝트의 출현을 서로 구분하기 위함이다.

• Upstream (disambiguation)LINK

  May refer to: core Kubernetes or the source repo from which a repo was forked.

  [+]

  • In the Kubernetes Community: Conversations often use upstream to mean the core Kubernetes codebase, which the general ecosystem, other code, or third-party tools rely upon. For example, community members may suggest that a feature is moved upstream so that it is in the core codebase instead of in a plugin or third-party tool.
  • In GitHub or git: The convention is to refer to a source repo as upstream, whereas the forked repo is considered downstream.
• user namespaceLINK

  A kernel feature to emulate root. Used for "rootless containers".

  [+]

  User namespaces are a Linux kernel feature that allows a non-root user to emulate superuser ("root") privileges, for example in order to run containers without being a superuser outside the container.

  User namespace is effective for mitigating damage of potential container break-out attacks.

  In the context of user namespaces, the namespace is a Linux kernel feature, and not a namespace in the Kubernetes sense of the term.

• WG(working group)LINK

  위원회(committee), SIG 내, 또는 SIG 간 노력을 위한 단기적이거나, 좁은 범위를 다루거나, 혹은 서로 연관되지 않은 프로젝트의 토론 및 구현을 촉진한다.

  [+]

  WG은 별개의 작업을 수행하기 위해 사람들을 조직하는 한 방법이다.

  자세한 내용은 kubernetes/community 저장소 및 현재 존재하는 SIG 및 WG 목록을 참조한다.

• 가비지(Garbage) 수집LINK

  쿠버네티스가 클러스터 자원을 정리하기 위해 사용하는 다양한 방법을 종합한 용어이다.

  [+]

  쿠버네티스는 가비지 수집을 이용하여 사용되지 않는 컨테이너와 이미지, 실패한 파드, 타겟 리소스가 소유한 오브젝트, 종료된 잡, 그리고 만료되거나 실패한 리소스 같은 리소스를 정리한다.

• 개발자(Developer) (의미 명확화)LINK

  애플리케이션 개발자, 코드 기여자, 또는 플랫폼 개발자를 가리킨다.

  [+]

  하나 이상의 의미를 갖는 개발자라는 용어는 문맥에 따라 다른 의미로 해석할 수 있다.

• 네임스페이스(Namespace)LINK

  쿠버네티스에서 하나의 클러스터 내에서 리소스 그룹의 격리를 지원하기 위해 사용하는 추상적 개념.

  [+]

  네임스페이스는 클러스터의 오브젝트를 체계화하고 클러스터의 리소스를 분리하는 방법을 제공한다. 리소스의 이름은 네임스페이스 내에서 유일해야 한다. 그러나, 네임스페이스 간에서 유일할 필요는 없다. 네임스페이스 기반 스코핑은 네임스페이스 기반 오브젝트(예: 디플로이먼트, 서비스 등)에만 적용 가능하며 클러스터 범위의 오브젝트(예: 스토리지클래스, 노드, 퍼시스턴트볼륨 등)에는 적용 불가능하다.

• 네트워크 폴리시(Network Policy)LINK

  파드 그룹들이 서로에 대한 그리고 다른 네트워크 엔드포인트에 대한 통신이 어떻게 허용되는지에 대한 명세이다.

  [+]

  네트워크 폴리시는 어떤 파드들의 연결을 서로 허용할지, 어떤 네임스페이스가 통신 가능하도록 허용할지, 더 상세하게는 어떤 포트 번호에 각 정책을 시행할지도 선언적으로 구성할 수 있게 도와준다. NetworkPolicy 리소스는 파드를 선택하고 선택된 파드에 어떤 트래픽을 허용할지 명시하는 규칙을 정의하기 위해서 레이블을 사용한다. 네트워크 폴리시는 네트워크 프로바이더에 의해 제공되는 네트워크 플러그인 지원에 의해 구현된다. 네트워크 리소스를 그것을 구현하는 컨트롤러 없이 생성하는 것은 아무런 효과가 없음을 주의하기 바란다.

• 노드-압박 축출LINK

  별칭:kubelet eviction
  

  노드-압박 축출은 kubelet이 노드의 자원을 회수하기 위해 파드를 능동적으로 중단시키는 절차이다.

  [+]

  kubelet은 클러스터 노드의 CPU, 메모리, 디스크 공간, 파일시스템 inode와 같은 자원을 모니터링한다. 이러한 자원 중 하나 이상이 특정 소모 수준에 도달하면, kubelet은 하나 이상의 파드를 능동적으로 중단시켜 자원을 회수하고 고갈 상황을 방지할 수 있다.

  노드-압박 축출은 API를 이용한 축출과는 차이가 있다.

• 노드(Node)LINK

  노드는 쿠버네티스의 작업 장비(worker machine)이다.

  [+]

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

  초기 쿠버네티스 버전에서는 노드를 "미니언(Minions)"으로 불렀었다.

• 데몬셋(DaemonSet)LINK

  파드 복제본을 클러스터 노드 집합에서 동작하게 한다.

  [+]

  일반적으로 모든 노드에서 실행돼야 하는 로그 수집기 및 모니터링 에이전트 등의 시스템 데몬을 배포하기 위해서 사용된다.

• 데이터 플레인(Data Plane)LINK

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

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

• 도커(Docker)LINK

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

  [+]

  Docker는 리눅스 커널의 리소스 격리 기능을 사용하며, 그 격리 기능의 예는 cgroups, 커널 네임스페이스, OverlayFS와 같은 조합 가능한 파일 시스템, 컨테이너가 단일 리눅스 인스턴스에서 독립적으로 실행되게 하여 가상 머신(VM)을 시작하고 관리하는 오버헤드를 피할 수 있도록 하는 기타 기능 등이 있다.

• 도커심(Dockershim)LINK

  도커심(Dockershim)은 쿠버네티스 버전 1.23 이하의 구성 요소이다. kubelet이 도커 엔진과 통신할 수 있게 한다.

  [+]

  1.24버전 부터 도커심(Dockershim)은 쿠버네티스에서 제거되었다. 자세한 사항은 Dockershim FAQ를 참고한다.

• 동적 볼륨 프로비저닝(Dynamic Volume Provisioning)LINK

  사용자가 스토리지 볼륨의 자동 생성을 요청할 수 있게 해준다.

  [+]

  동적 프로비저닝은 클러스터 관리자가 스토리지를 사전 프로비저닝할 필요가 없다. 대신 사용자 요청에 따라 자동으로 스토리지를 프로비저닝한다. 동적 볼륨 프로비저닝은 API 오브젝트인 스토리지클래스(StorageClass)를 기반으로 한다. 이 스토리지클래스는 볼륨 및 볼륨 플러그인에 전달할 파라미터 세트를 프로비저닝하는 볼륨 플러그인을 참조한다.

• 디플로이먼트(Deployment)LINK

  일반적으로 로컬 상태가 없는 파드를 실행하여 복제된 애플리케이션을 관리하는 API 오브젝트.

  [+]

  각 레플리카는 파드로 표현되며, 파드는 클러스터의 노드에 분산된다. 로컬 상태가 필요한 워크로드의 경우 스테이트풀셋(StatefulSet)의 사용을 고려한다.

• 레이블(Label)LINK

  사용자에게 의미 있고 관련성 높은 특징으로 식별할 수 있도록 오브젝트에 태그를 붙인다.

  [+]

  레이블은 파드와 같은 오브젝트에 붙일 수 있는 키/값 쌍이다. 레이블은 오브젝트의 하위 집합을 구성하고 선택하는데 사용된다.

• 레플리카셋(ReplicaSet)LINK

  레플리카셋은 (목표로) 주어진 시간에 실행되는 레플리카 파드 셋을 유지 관리 한다.

  [+]

  디플로이먼트(Deployment) 와 같은 워크로드 오브젝트는 레플리카셋을 사용해서 해당 레플리카셋의 스펙에 따라 구성된 파드 의 수를 클러스터에서 실행한다.

• 레플리케이션 컨트롤러(ReplicationController)LINK

  특정한 수의 파드 인스턴스가 실행 중인지 확인하면서 복제된 애플리케이션을 관리하는 워크로드 리소스이다.

  [+]

  컨트롤 플레인은 일부 파드에 장애가 발생하거나, 수동으로 파드를 삭제하거나, 실수로 너무 많은 수의 파드가 시작된 경우에도 정의된 수량의 파드가 실행되도록 한다.

  참고: 레플리케이션컨트롤러는 사용 중단되었다. 유사한 것으로는 디플로이먼트를 본다.
• 로깅(Logging)LINK

  로그는 클러스터나 애플리케이션에 의해 로깅된 이벤트의 목록이다.

  [+]

  애플리케이션과 시스템 로그는 클러스터 내부에서 어떤 일이 벌어지고 있는지 이해하는데 도움을 준다. 특히 로그는 문제를 디버깅하거나 클러스터 활동을 모니터링할 때 유용하다.

• 리뷰어(Reviewer)LINK

  프로젝트 일부에 대한 코드를 품질과 정확성 관점에서 검토하는 사람.

  [+]

  리뷰어는 코드베이스와 소프트웨어 엔지니어링 원칙에 대해 잘 알고 있다. 리뷰어의 상태는 코드베이스의 일부로 범위가 한정된다.

• 리소스 쿼터(Resource Quotas)LINK

  네임스페이스당 전체 리소스 소비를 제한하는 제약을 제공한다.

  [+]

  타입에 따라 네임스페이스에서 생성될 수 있는 오브젝트의 수량과 해당 프로젝트의 리소스에 의해서 소비되는 컴퓨팅 리소스의 총량도 제한한다.

• 매니지드 서비스(Managed Service)LINK

  타사 공급자가 유지보수하는 소프트웨어.

  [+]

  매니지드 서비스의 몇 가지 예시로 AWS EC2, Azure SQL Database 그리고 GCP Pub/Sub이 있으나, 애플리케이션에서 사용할 수 있는 모든 소프트웨어 제품이 될 수 있다.

• 매니페스트(Manifest)LINK

  JSON 또는 YAML 형식으로 명시한 쿠버네티스 API 오브젝트의 명세.

  [+]

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

• 멤버(Member)LINK

  K8s 커뮤니티에서 지속적으로 활동하는 컨트리뷰터.

  [+]

  멤버는 이슈와 풀 리퀘스트를 할당받을 수 있으며 GitHub 팀을 통해 SIG에 참여할 수 있다. 멤버의 풀 리퀘스트에 대해 병합 전 테스트(pre-submit test)가 자동으로 실행된다. 멤버는 커뮤니티에 적극적으로 기여할 것으로 기대된다.

• 미러 파드(Mirror Pod)LINK

  Kubelet이 스태틱 파드를 표현하는 파드 오브젝트

  [+]

  Kubelet이 설정에서 스태틱 파드를 찾으면, 자동으로 쿠버네티스 API 서버에 파드 오브젝트 생성을 시도한다. 이렇게 생성된 파드를 API 서버에서 확인할 수는 있지만, API 서버를 통해 제어할 수는 없다.

  (예를 들어, 미러 파드를 제거하더라도 kubelet 데몬이 해당 파드를 멈추지 않는다.)

• 범위 제한(LimitRange)LINK

  네임스페이스 내에 컨테이너나 파드당 리소스 소비를 한정하는 제약 조건을 제공한다.

  [+]

  범위 제한은 타입별로 만들 수 있는 오브젝트의 개수와 네임스페이스 안에 개별 컨테이너나 파드가 요청하거나 소비할 컴퓨팅 리소스의 양을 제한한다.

• 볼륨 플러그인(Volume Plugin)LINK

  볼륨 플러그인은 파드(Pod) 내에서의 스토리지 통합을 가능하게 한다.

  [+]

  볼륨 플러그인을 사용하면 파드에서 사용할 스토리지 볼륨을 연결하고 마운트할 수 있다. 볼륨 플러그인은 인-트리(in tree) 혹은 아웃-오브-트리(out of tree) 일 수 있다. 인-트리 플러그인은 쿠버네티스 코드 리포지터리의 일부이며 동일한 릴리즈 주기를 따른다. 아웃-오브-트리 플러그인은 독립적으로 개발된다.

• 볼륨(Volume)LINK

  데이터를 포함하고 있는 디렉터리이며, 파드의 컨테이너에서 접근 가능하다.

  [+]

  쿠버네티스 볼륨은 그것을 포함하고 있는 파드만큼 오래 산다. 결과적으로, 볼륨은 파드 안에서 실행되는 모든 컨테이너 보다 오래 지속되며, 데이터는 컨테이너의 재시작 간에도 보존된다.

  더 많은 정보는 스토리지를 본다.

• 서비스 카탈로그(Service Catalog)LINK

  쿠버네티스 클러스터 내에서 실행되는 응용 프로그램이, 클라우드 공급자가 제공하는 데이터 저장소 서비스와 같은 외부 관리 소프트웨어 제품을 쉽게 사용할 수 있도록 해주던 이전의 확장 API이다.

  [+]

  서비스 생성 또는 관리에 대한 자세한 지식 없이도 외부의 매니지드 서비스의 목록과 프로비전, 바인딩하는 방법을 제공한다.

• 서비스(Service)LINK

  파드 집합에서 실행중인 애플리케이션을 네트워크 서비스로 노출하는 추상화 방법

  [+]

  서비스의 대상이 되는 파드 집합은 (보통) 셀렉터로 결정된다. 많은 파드가 추가되거나 제거되면, 셀렉터와 일치하는 파드의 집합도 변경된다. 서비스는 네트워크 트래픽을 현재 워크로드를 위한 파드 집합으로 보낼 수 있는지 확인한다.

• 서비스어카운트(ServiceAccount)LINK

  파드에서 실행 중인 프로세스를 위한 신원(identity)을 제공한다.

  [+]

  파드 내부의 프로세스가 클러스터에 엑세스할 때, API 서버에 의해서 특별한 서비스 어카운트(예를 들면, 기본(default))로 인증된다. 파드를 생성할 때, 서비스 어카운트를 명시하지 않는다면, 동일한 네임스페이스의 기본 서비스 어카운트가 자동적으로 할당된다.

• 선점(Preemption)LINK

  쿠버네티스에서 선점(preemption)은 노드에서 낮은 우선 순위를 가지는 파드(Pod)를 축출함으로써 보류 중인 파드가 적절한 노드(Node)를 찾을 수 있도록 한다.

  [+]

  파드를 스케줄링 할 수 없는 경우, 스케줄러는 우선 순위가 낮은 파드를 선점하여 보류 중인 파드를 스케줄링할 수 있게 한다.

• 셀렉터(Selector)LINK

  사용자가 레이블에 따라서 리소스 리스트를 필터할 수 있게 한다.

  [+]

  셀렉터는 리소스 리스트를 질의할 때 리스트를 레이블에 따라서 필터하기 위해서 적용된다.

• 수량(Quantity)LINK

  SI 접미사를 사용하는 작거나 큰 숫자의 정수(whole-number) 표현.

  [+]

  수량은 SI 접미사가 포함된 간결한 정수 표기법을 통해서 작거나 큰 숫자를 표현한 것이다. 분수는 밀리(milli) 단위로 표시되는 반면, 큰 숫자는 킬로(kilo), 메가(mega), 또는 기가(giga) 단위로 표시할 수 있다.

  예를 들어, 숫자 1.5는 1500m으로, 숫자 1000은 1k로, 1000000은 1M으로 표시할 수 있다. 또한, 이진 표기법 접미사도 명시 가능하므로, 숫자 2048은 2Ki로 표기될 수 있다.

  허용되는 10진수(10의 거듭 제곱) 단위는 m (밀리), k (킬로, 의도적인 소문자), M (메가), G (기가), T (테라), P (페타), E (엑사)가 있다.

  허용되는 2진수(2의 거듭 제곱) 단위는 Ki (키비), Mi (메비), Gi (기비), Ti (테비), Pi (페비), Ei (엑비)가 있다.

• 스태틱 파드(Static Pod)LINK

  특정 노드의 Kubelet 데몬이 직접 관리하는 파드로,

  [+]

  API 서버가 관찰하지 않는다.

• 스테이트풀셋(StatefulSet)LINK

  파드 집합의 디플로이먼트와 스케일링을 관리하며, 파드들의 순서 및 고유성을 보장한다 .

  [+]

  디플로이먼트와 유사하게, 스테이트풀셋은 동일한 컨테이너 스펙을 기반으로 둔 파드들을 관리한다. 디플로이먼트와는 다르게, 스테이트풀셋은 각 파드의 독자성을 유지한다. 이 파드들은 동일한 스팩으로 생성되었지만, 서로 교체는 불가능하다. 다시 말해, 각각은 재스케줄링 간에도 지속적으로 유지되는 식별자를 가진다.

  스토리지 볼륨을 사용해서 워크로드에 지속성을 제공하려는 경우, 솔루션의 일부로 스테이트풀셋을 사용할 수 있다. 스테이트풀셋의 개별 파드는 장애에 취약하지만, 퍼시스턴트 파드 식별자는 기존 볼륨을 실패한 볼륨을 대체하는 새 파드에 더 쉽게 일치시킬 수 있다.

• 스토리지 클래스(Storage Class)LINK

  스토리지클래스는 관리자가 사용 가능한 다양한 스토리지 유형을 설명할 수 있는 방법을 제공한다.

  [+]

  스토리지 클래스는 서비스 품질 수준, 백업 정책 혹은 클러스터 관리자가 결정한 임의의 정책에 매핑할 수 있다. 각 스토리지클래스에는 클래스에 속한 퍼시스턴트 볼륨(Persistent Volume)을 동적으로 프로비저닝해야 할 때 사용되는 provisioner, parameters 및 reclaimPolicy 필드가 있다. 사용자는 스토리지클래스 객체의 이름을 사용하여 특정 클래스를 요청할 수 있다.

• 승인자(Approver)LINK

  쿠버네티스 코드 컨트리뷰션을 리뷰하고 승인할 수 있는 사람.

  [+]

  코드 리뷰는 코드의 품질과 정확성에 초점을 맞추지만, 승인은 컨트리뷰션의 수용 여부(acceptance)를 전체적인 측면에서 바라본다. 전체적인 검토에는 앞뒤 버전과의 호환성, API 및 플래그 규칙 준수, 미묘한 성능 및 정확성 문제, 시스템의 다른 부분과의 상호작용 등이 포함된다. 승인자 자격은 코드 베이스의 일부로 범위가 한정된다. 승인자는 이전에 메인테이너라고 지칭되었다.

• 시크릿(Secret)LINK

  비밀번호, OAuth 토큰 및 ssh 키와 같은 민감한 정보를 저장한다.

  [+]

  민감한 정보를 사용하는 방식에 대해 더 세밀하게 제어할 수 있으며, 우발적인 노출 위험을 줄인다. 시크릿 값은 기본적으로 base64 문자열로 인코딩되어 암호화되지 않은 채로 저장되지만, 안전하게 암호화되도록 설정할 수 있다. 파드는 볼륨 마운트 내의 파일 형태로 시크릿에 접근하며, 시크릿은 또한 kubelet이 파드를 위해 이미지를 풀링할 때에도 사용될 수 있다. 시크릿은 기밀 데이터를 다루는 용도로 적합하며, 컨피그맵은 기밀이 아닌 데이터를 다루는 용도로 적합하다.

• 애그리게이션 레이어(Aggregation Layer)LINK

  애그리게이션 레이어를 이용하면 사용자가 추가로 쿠버네티스 형식의 API를 클러스터에 설치할 수 있다.

  [+]

  쿠버네티스 API 서버에서 추가 API 지원을 구성하였으면, 쿠버네티스 API의 URL 경로를 "요구하는" APIService 오브젝트 추가할 수 있다.

• 애드온(Add-ons)LINK

  쿠버네티스의 기능을 확장하는 리소스.

  [+]

  애드온 설치에서는 클러스터에서 애드온을 사용하는 자세한 방법을 설명하며, 인기 있는 애드온들을 나열한다.

• 애플리케이션(Applications)LINK

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

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

• 앱 컨테이너(App Container)LINK

  애플리케이션 컨테이너(또는 앱 컨테이너)는 파드 내의 모든 초기화 컨테이너가 완료된 후 시작되는 컨테이너이다.

  [+]

  초기화 컨테이너를 사용하면 전체 워크로드에 대해서 중요한 초기화 세부 사항을 분리할 수 있으며, 애플리케이션 컨테이너가 시작된 후에는 계속 동작시킬 필요가 없다. 만약 파드에 설정된 초기화 컨테이너가 없는 경우, 파드의 모든 컨테이너는 앱 컨테이너이다.

• 어노테이션(Annotation)LINK

  임의의 식별되지 않는 메타데이터를 오브젝트에 첨부할 때 이용하는 키-밸류 쌍.

  [+]

  어노테이션으로 된 메타데이터는 작거나 클 수 있고, 구조화되어 있거나 구조화되어 있지 않을 수도 있고, 레이블에서는 허용되지 않는 문자도 포함할 수 있다. 툴과 라이브러리와 같은 클라이언트로 메타데이터를 검색할 수 있다.

• 어드미션 컨트롤러(Admission Controller)LINK

  쿠버네티스 API 서버에서 요청을 처리하여 오브젝트가 지속되기 전에 그 요청을 가로채는 코드 조각.

  [+]

  어드미션 컨트롤러는 쿠버네티스 API 서버에서 구성할 수 있고, "유효성 검사"나 "변조하기" 혹은 모두를 진행할 수 있다. 모든 어드미션 컨트롤러는 요청을 거부할 수 있다. 변조하는 컨트롤러는 자신이 승인하는 오브젝트를 수정할 수 있지만 유효성 검사 컨트롤러는 수정할 수 없다.

  • 쿠버네티스 문서에서 어드미션 컨트롤러
• 어피니티 (Affinity)LINK

  쿠버네티스에서 어피니티 는 파드를 배치할 위치에 대한 힌트를 스케줄러에 제공하는 일련의 규칙이다.

  [+]

  어피니티에는 다음의 두 가지 종류가 있다.

  • 노드 어피니티
  • 파드 간 어피니티

  어피니티 규칙은 쿠버네티스 레이블 및 파드에 명시된 셀렉터를 이용하여 정의되며, 스케줄러에서 얼마나 엄격하게 적용할지에 따라 필수 또는 선호사항으로 지정할 수 있다.

• 엔드포인트(Endpoints)LINK

  엔드포인트는 서비스(Service) 셀렉터(Selector)에 매치되는 파드의 IP 주소를 추적한다. (API에서 해당 kind의 명칭은 Endpoints이며, 복수형이 기본임을 유의한다.)

  [+]

  엔드포인트는 셀렉터를 명시하지 않고도 서비스(Service)에 대해 수동으로 구성할 수 있다. 엔드포인트슬라이스(EndpointSlice) 리소스는 엔드포인트의 대안으로, 확장성(scalability)과 확장 가능성(extensibility)을 제공한다.

• 오브젝트(Object)LINK

  쿠버네티스 시스템의 엔티티이다. 쿠버네티스 API가 클러스터의 상태를 나타내기 위해 사용하는 엔티티이다.

  [+]

  쿠버네티스 오브젝트는 일반적으로 "의도를 담은 레코드"이다. 당신이 오브젝트를 생성하게 되면, 쿠버네티스 컨트롤 플레인은 그 아이템이 실제 존재함을 보장하기 위해 지속적으로 작동한다. 객체를 생성함으로써 당신의 클러스터의 워크로드 해당 부분이 어떻게 보이길 원하는지 쿠버네티스 시스템에 효과적으로 알리는 것이다. 이것은 당신의 클러스터의 의도한 상태이다.

• 워크로드(Workloads)LINK

  워크로드는 쿠버네티스에서 구동되는 애플리케이션이다.

  [+]

  데몬셋, 디플로이먼트, 잡, 레플리카셋, 그리고 스테이트풀셋 오브젝트를 포함해서 서로 다른 워크로드의 유형이나 부분을 대표하는 다양한 핵심 오브젝트.

  예를 들어, 웹 서버와 데이터베이스가 있는 워크로드는 데이터베이스를 한 스테이트풀셋 안에서 실행할 것이며, 웹서버를 디플로이먼트를 통해 실행할 것이다.

• 이름(Name)LINK

  /api/v1/pods/some-name과 같이, 리소스 URL에서 오브젝트를 가리키는 클라이언트 제공 문자열.

  [+]

  특정 시점에 같은 종류(kind) 내에서는 하나의 이름은 하나의 오브젝트에만 지정될 수 있다. 하지만, 오브젝트를 삭제한 경우, 삭제된 오브젝트와 같은 이름을 새로운 오브젝트에 지정 가능하다.

• 이미지(Image)LINK

  컨테이너의 저장된 인스턴스이며, 애플리케이션 구동에 필요한 소프트웨어 집합을 가지고 있다.

  [+]

  소프트웨어가 컨테이너 레지스트리에 저장되고, 로컬 시스템에 풀(pull)되고, 애플리케이션으로서 실행되도록 패키징하는 방법. 메타 데이터는 이미지에 포함되며, 실행할 실행 파일, 작성자 및 기타 정보를 나타낸다.

• 이벤트(Event)LINK

  각 이벤트는 클러스터 어딘가에서 발생한 이벤트에 대한 보고서이다. 일반적으로 시스템의 상태 변화를 나타낸다.

  [+]

  이벤트의 보존(retention) 시간은 제한되어 있으며, 트리거(trigger)와 메시지(message)는 시간에 따라 변화할 수 있다. 이벤트 소비자는 일관성 있는 기본 트리거를 반영한다거나 이벤트가 지속적으로 존재한다는 특정 이유로 이벤트의 타이밍에 의존해서는 안 된다.

  이벤트는 유익(imformative)해야 하고, 최선을 다한(best-effort), 보완적(supplemental) 데이터로 취급되어야 한다.

  쿠버네티스에서, 감사(auditing)는 다른 종류의 이벤트 레코드를 생성한다. (API 그룹 audit.k8s.io).

• 익스텐션(Extensions)LINK

  익스텐션은 새로운 종류의 하드웨어를 지원하기 위해 쿠버네티스를 확장하고 깊게 통합시키는 소프트웨어 컴포넌트이다.

  [+]

  많은 클러스터 관리자가 호스트된 쿠버네티스 또는 쿠버네티스의 배포 인스턴스를 사용하고 있다. 이러한 클러스터는 익스텐션이 미리 설치되어 제공된다. 그 결과, 대부분의 쿠버네티스 사용자는 익스텐션을 별도로 설치할 필요가 없으며, 익스텐션을 새로 만들어야 하는 사용자 역시 거의 없을 것이다.

• 인그레스(Ingress)LINK

  클러스터 내의 서비스에 대한 외부 접근을 관리하는 API 오브젝트이며, 일반적으로 HTTP를 관리함.

  [+]

  인그레스는 부하 분산, SSL 종료, 명칭 기반의 가상 호스팅을 제공할 수 있다.

• 인증서(Certificate)LINK

  암호화된 안전한 파일로 쿠버네티스 클러스터 접근 검증에 사용한다.

  [+]

  인증서는 쿠버네티스 클러스터에서 애플리케이션이 쿠버네티스 API에 안전하게 접근할 수 있게 한다. 인증서는 클라이언트의 API 접근 허용 여부를 검증한다.

• 임시 컨테이너(Ephemeral Container)LINK

  파드 내에 임시적으로 실행할 수 있는 컨테이너 타입.

  [+]

  문제가 있는 실행 중 파드를 조사하고 싶다면, 파드에 임시 컨테이너를 추가하고 진단을 수행할 수 있다. 임시 컨테이너는 리소스 및 스케줄링에 대한 보장이 제공되지 않으며, 워크로드 자체를 실행하기 위해 임시 컨테이너를 사용해서는 안 된다.

  더 자세한 정보는 파드 API의 EphemeralContainer를 참고한다.

• 잡(Job)LINK

  완료를 목표로 실행되는 유한 또는 배치 작업.

  [+]

  하나 이상의 파드 오브젝트를 생성하고 지정된 수의 파드가 성공적으로 종료되는지 확인한다. 파드가 성공적으로 완료됨에 따라, 잡은 해당 성공적인 완료를 추적한다.

• 장치 플러그인(Device Plugin)LINK

  장치 플러그인은 워커
  노드에서 실행되며, 공급자별 초기화 또는 설정 단계가 필요한 로컬 하드웨어와 같은 리소스에 접근할 수 있는 파드.

  [+]

  장치 플러그인은 kubelet에 리소스를 알리기에 워크로드 파드는 해당 파드가 실행중인 노드와 관련된 하드웨어 기능에 접근할 수 있다. 장치 플러그인을 데몬셋(DaemonSet)으로 배포하거나, 각 대상 노드에 직접 장치 플러그인 소프트웨어를 설치할 수 있다.

  장치 플러그인 의 더 자세한 정보를 본다

• 중단(Disruption)LINK

  중단은 하나 이상의 파드를 중단시키게 만드는 이벤트를 의미한다. 중단은 디플로이먼트(Deployment)와 같이 해당 영향을 받는 파드에 의존하는 워크로드 리소스에도 영향을 준다.

  [+]

  클러스터 오퍼레이터로서, 애플리케이션에 속한 파드를 직접 파괴하는 경우 쿠버네티스는 이를 자발적 중단(voluntary disruption) 이라고 칭한다. 노드 장애 또는 더 넓은 영역에 장애를 일으키는 정전 등으로 인해 파드가 오프라인 상태가 되면 쿠버네티스는 이를 비자발적 중단(involuntary disruption) 이라고 한다.

  자세한 정보는 중단을 확인한다.

• 초기화 컨테이너(Init Container)LINK

  앱 컨테이너가 동작하기 전에 완료되기 위해 실행되는 하나 이상의 초기화 컨테이너.

  [+]

  한 가지 차이점을 제외하면, 초기화 컨테이너는 일반적인 앱 컨테이너와 동일하다. 초기화 컨테이너는 앱 컨테이너가 시작되기 전에 완료되는 것을 목표로 실행되어야 한다. 초기화 컨테이너는 연달아 실행된다. 다시말해, 각 초기화 컨테이너의 실행은 다음 초기화 컨테이너가 시작되기 전에 완료되어야 한다.

• 축출(Eviction)LINK

  노드에 있는 한 개 이상의 파드를 중단하는 프로세스이다.

  [+]

  축출에는 두 가지 종류가 있다.

  • 노드-압박 축출
  • API를 이용한 축출(API-initiated Eviction)
• 커스텀 리소스 데피니션(CustomResourceDefinition)LINK

  사용자 정의 서버를 완전히 새로 구축할 필요가 없도록 쿠버네티스 API 서버에 추가할 리소스를 정의하는 사용자 정의 코드.

  [+]

  만약 공개적으로 지원되는 API 리소스가 사용자의 요구를 충족할 수 없는 경우, 커스텀 리소스 데피니션은 사용자의 환경에 따라 쿠버네티스 API를 확장하게 해준다.

• 컨테이너 네트워크 인터페이스(Container network interface, CNI)LINK

  컨테이너 네트워크 인터페이스(CNI) 플러그인은 appc/CNI 스펙을 따르는 네트워크 플러그인의 일종이다.

  [+]

  • 쿠버네티스와 CNI에 대한 정보는 "네트워크 플러그인"에서 볼 수 있다.
• 컨테이너 라이프사이클 훅(Container Lifecycle Hooks)LINK

  라이프사이클 훅은 컨테이너 관리 라이프사이클에 이벤트를 노출하고 이벤트가 발생할 때 사용자가 코드를 실행할 수 있도록 한다.

  [+]

  컨테이너에는 두 개의 훅(컨테이너가 생성된 직후에 실행되는 PostStart와 컨테이너가 종료되기 직전에 차단되고 호출되는 PreStop)이 노출된다.

• 컨테이너 런타임LINK

  컨테이너 런타임은 컨테이너 실행을 담당하는 소프트웨어이다.

  [+]

  쿠버네티스는 containerd, CRI-O와 같은 컨테이너 런타임 및 모든 Kubernetes CRI (컨테이너 런타임 인터페이스) 구현체를 지원한다.

• 컨테이너 런타임 인터페이스(Container runtime interface, CRI)LINK

  컨테이너 런타임 인터페이스(CRI)는 노드의 Kubelet과 컨테이너 런타임을 통합시키기 위한 API이다.

  [+]

  API와 스펙에 대한 정보는 CRI를 참고한다.

• 컨테이너 런타임 인터페이스(Container Runtime Interface)LINK

  Kubelet과 컨테이너 런타임 사이의 통신을 위한 주요 프로토콜이다.

  [+]

  쿠버네티스 컨테이너 런타임 인터페이스(CRI)는 클러스터 컴포넌트 kubelet과 container runtime 사이의 통신을 위한 주요 gRPC 프로토콜을 정의한다.

• 컨테이너 스토리지 인터페이스(CSI)LINK

  컨테이너 스토리지 인터페이스(CSI)는 컨테이너에 스토리지 시스템을 노출하는 표준 인터페이스를 정의한다.

  [+]

  CSI를 통해 공급업체는 쿠버네티스 저장소(트리 외 플러그인)를 추가하지 않고도 쿠버네티스용 사용자 스토리지 플러그인을 생성할 수 있다. 스토리지 제공자가 CSI 드라이버를 사용하려면, 먼저 클러스터에 배포해야 한다. 그런 다음 해당 CSI 드라이버를 사용하는 스토리지클래스(StorageClass)를 생성할 수 있다.

  • 쿠버네티스 문서에서 CSI
  • 사용 가능한 CSI 드라이버 목록
• 컨테이너 환경 변수(Container Environment Variables)LINK

  컨테이너 환경 변수는 파드에서 동작 중인 컨테이너에 유용한 정보를 제공하기 위한 이름=값 쌍이다.

  [+]

  컨테이너 환경 변수는 중요한 리소스에 대한 정보와 함께 실행 중인 컨테이너화 된 애플리케이션이 요구하는 정보를 해당 컨테이너에 제공한다. 예를 들면, 파일 시스템 상세 정보, 컨테이너 스스로에 대한 정보, 서비스 엔드포인트와 같은 다른 클러스터 리소스에 대한 정보 등이 있다.

• 컨테이너(Container)LINK

  소프트웨어와 그것에 종속된 모든 것을 포함한 가볍고 휴대성이 높은 실행 가능 이미지.

  [+]

  컨테이너는 애플리케이션과 기반이 되는 호스트 인프라의 관계를 분리시켜서, 애플리케이션을 다른 클라우드 또는 OS 환경에서도 쉽게 디플로이하고 쉽게 스케일되게 한다.

• 컨트롤 플레인(Control Plane)LINK

  컨테이너의 라이프사이클을 정의, 배포, 관리하기 위한 API와 인터페이스들을 노출하는 컨테이너 오케스트레이션 레이어.

  [+]

  이 계층은 다음과 같은 다양한 컴포넌트로 구성된다(그러나 제한되지는 않는다).

  • etcd
  • API 서버
  • 스케줄러
  • 컨트롤러 매니저
  • 클라우드 컨트롤러 매니저

  이러한 컴포넌트는 기존 운영체제 서비스(데몬) 또는 컨테이너로 실행할 수 있다. 이러한 컴포넌트를 실행하는 호스트를 마스터라 한다.

• 컨트롤러(Controller)LINK

  쿠버네티스에서 컨트롤러는 클러스터 의 상태를 관찰 한 다음, 필요한 경우에 생성 또는 변경을 요청하는 컨트롤 루프이다. 각 컨트롤러는 현재 클러스터 상태를 의도한 상태에 가깝게 이동한다.

  [+]

  컨트롤러는 api 서버 (컨트롤 플레인(Control Plane)의 일부)를 통해 클러스터의 공유 상태를 감시한다.

  일부 컨트롤러는 컨트롤 플레인 내부에서 실행되며, 쿠버네티스 작업의 핵심인 컨트롤 루프를 제공한다. 예를 들어 디플로이먼트 컨트롤러, 데몬셋 컨트롤러, 네임스페이스 컨트롤러 그리고 퍼시스턴트 볼륨 컨트롤러(및 그 외)는 모두 "kube-controller-manager" 내에서 실행 된다.

• 컨트리뷰터(Contributor)LINK

  쿠버네티스 프로젝트 또는 커뮤니티를 돕기 위해 코드, 문서 또는 시간을 기부하는 사람.

  [+]

  기여에는 풀 리퀘스트(PR), 이슈, 피드백, 분과회(special interest groups) 참여, 또는 커뮤니티 행사 조직이 포함됩니다.

• 컨피그맵(ConfigMap)LINK

  키-값 쌍으로 기밀이 아닌 데이터를 저장하는 데 사용하는 API 오브젝트이다. 파드는 볼륨에서 환경 변수, 커맨드-라인 인수 또는 구성 파일로 컨피그맵을 사용할 수 있다.

  [+]

  컨피그맵을 사용하면 컨테이너 이미지에서 환경별 구성을 분리하여, 애플리케이션을 쉽게 이식할 수 있다.

• 코드 컨트리뷰터(Code Contributor)LINK

  쿠버네티스 오픈소스 코드베이스에 코드를 개발하고 기여하는 사람.

  [+]

  그들은 하나 이상의 Special Interest Group (SIG)에 참여하는 활동적인 커뮤니티 멤버이기도 하다.

• 쿠버네티스 API(Kubernetes API)LINK

  RESTful 인터페이스를 통해서 쿠버네티스 기능을 제공하고 클러스터의 상태를 저장하는 애플리케이션.

  [+]

  쿠버네티스 리소스와 "의도에 대한 레코드"는 모두 API 오브젝트로 저장되며, API로의 RESTful 호출을 통해서 수정된다. API는 구성이 선언적인 방법으로 관리되도록 한다. 사용자는 쿠버네티스 API와 직접 상호 작용할 수 있으며, kubectl과 같은 툴을 사용할 수도 있다. 쿠버네티스 API의 핵심은 유연하며 사용자 정의 리소스를 지원하기 위해 확장될 수도 있다.

• 크론잡(CronJob)LINK

  주기적인 일정에 따라 실행되는 잡을 관리.

  [+]

  crontab 파일의 라인과 유사하게, 크론잡 오브젝트는 크론 형식을 사용하여 일정을 지정한다.

• 클라우드 공급자LINK

  별칭:Cloud Service Provide
  

  클라우드 컴퓨팅 플랫폼을 제공하는 사업자 또는 다른 조직

  [+]

  클라우드 공급자, 때로는 클라우드 서비스 공급자(CSP) 부르며, 클라우드 컴퓨팅 플랫폼 또는 서비스를 제공한다.

  많은 클라우드 공급자들은 관리되는 인프라를 제공한다(이를 Infrastructure as a Service 또는 IaaS 라 부른다). 관리되는 인프라를 통해 클라우드 공급자는 서버, 스토리지 그리고 네트워킹을 담당하고 쿠버네티스 클러스터 실행과 같은 계층을 관리한다.

  사용자는 쿠버네티스를 관리되는 서비스로 찾을 수 있다. 때로는 이것을 Platform as a Service 또는 PaaS라 부른다. 관리되는 쿠버네티스를 사용하면 클라우드 공급자가 쿠버네티스 컨트롤 플레인만 아니라, 노드와 연관되는 인프라(네트워킹, 스토리지 그리고 로드밸런서와 같은 기타 요소) 를 책임진다.

• 클라우드 네이티브 컴퓨팅 재단(CNCF)LINK

  클라우드 네이티브 컴퓨팅 재단(CNCF)은 지속 가능한 생태계를 구축하고 컨테이너를 마이크로서비스 아키텍처의 일부로 오케스트레이션 하는 프로젝트 를 중심으로 커뮤니티를 조성한다.

  쿠버네티스는 CNCF 프로젝트이다.

  [+]

  CNCF는 리눅스 재단의 산하 기구이다. CNCF의 목표는 어디서나 클라우드 네이티브 컴퓨팅을 활용할 수 있도록 만드는 것이다.

• 클라우드 컨트롤 매니저LINK

  클라우드별 컨트롤 로직을 포함하는 쿠버네티스 컨트롤 플레인 컴포넌트이다. 클라우드 컨트롤러 매니저를 통해 클러스터를 클라우드 공급자의 API에 연결하고, 해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와만 상호 작용하는 컴포넌트를 구분할 수 있게 해 준다.

  [+]

  쿠버네티스와 기본 클라우드 인프라스터럭처 간의 상호 운용성 로직을 분리함으로써, cloud-controller-manager 컴포넌트는 클라우드 공급자가 주요 쿠버네티스 프로젝트와 다른 속도로 기능들을 릴리스할 수 있도록 한다.

• 클러스터 운영(Cluster Operations)LINK

  쿠버네티스 클러스터 관리에 관련된 작업: 일살정인(day-to-day) 운영 관리 및 업그레이드 조정.

  [+]

  클러스터 운영의 예: 클러스터를 확장하기 위한 신규 노드 배포; 소프트웨어 업그레이드 진행; 보안 조치(security control) 시행; 스토리지 추가 또는 삭제; 클러스터 네트워킹(cluster networking) 구성; 클러스터 전체 관찰가능성(observability) 관리; 이벤트 대응.

• 클러스터 운영자(Cluster Operator)LINK

  클러스터를 구성, 제어 및 모니터링하는 사람.

  [+]

  클러스터 운영자의 주된 책임은 클러스터를 가동 상태로 유지하는 것이며 이는 정기적인 유지보수 작업 또는 업그레이드를 포함한다.
  

  참고: 클러스터 운영자는 쿠버네티스 API를 확장하는 오퍼레이터 패턴과는 다르다.
• 클러스터 인프라스트럭처(Cluster Infrastructure)LINK

  인프라스트럭처 계층은 VM, 네트워킹, 보안 그룹 등을 제공하고 유지한다. [+]

  인프라스트럭처 계층은 VM, 네트워킹, 보안 그룹 등을 제공하고 유지한다.

• 클러스터(Cluster)LINK

  컨테이너화된 애플리케이션을 실행하는 노드라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다.

  [+]

  워커 노드는 애플리케이션의 구성요소인 파드를 호스트한다. 컨트롤 플레인은 워커 노드와 클러스터 내 파드를 관리한다. 프로덕션 환경에서는 일반적으로 컨트롤 플레인이 여러 컴퓨터에 걸쳐 실행되고, 클러스터는 일반적으로 여러 노드를 실행하므로 내결함성과 고가용성이 제공된다.

• 테인트(Taint)LINK

  세 가지 필수 속성: 키(key), 값(value), 효과(effect)로 구성된 코어 오브젝트. 테인트는 파드가 노드나 노드 그룹에 스케줄링되는 것을 방지한다.

  [+]

  테인트 및 톨러레이션(toleration)은 함께 작동하며, 파드가 적절하지 못한 노드에 스케줄되는 것을 방지한다. 하나 이상의 테인트가 노드에 적용될 수 있으며, 이것은 노드에 해당 테인트를 극복(tolerate)하지 않은 파드를 허용하지 않도록 표시한다.

• 톨러레이션(Toleration)LINK

  세 가지 필수 속성: 키(key), 값(value), 효과(effect)로 구성된 코어 오브젝트. 톨러레이션은 매칭되는 테인트(taints)를 가진 노드나 노드 그룹에 파드가 스케줄링되는 것을 활성화한다.

  [+]

  톨러레이션 및 테인트는 함께 작동하며, 파드가 적절하지 못한 노드에 스케줄되는 것을 방지한다. 하나 이상의 톨러레이션이 파드에 적용될 수 있다. 톨러레이션은 매칭되는 테인트를 가진 노드나 노드 그룹에 파드가 스케줄링되는 것을 허용(그러나 필수는 아님)하도록 표시한다.

• 파드 라이프사이클(Pod Lifecycle)LINK

  파드가 수명(lifetime) 동안 통과하는 상태의 순서이다.

  [+]

  파드 라이프사이클은 파드의 라이프사이클에 대한 고수준의 요약이다. 다섯 가지 파드 단계가 있다: Pending, Running, Succeeded, Failed, 그리고 Unknown. 파드 스테이터스의 phase 필드에 파드 상태에 대한 자세한 설명이 요약되어 있다.

• 파드 시큐리티 폴리시(Pod Security Policy)LINK

  파드 생성과 업데이트에 대한 세밀한 인가를 활성화한다.

  [+]

  파드 명세에서 보안에 민감한 측면을 제어하는 클러스터 수준의 리소스. PodSecurityPolicy 오브젝트는 파드가 시스템에 수용될 수 있도록 파드가 실행해야 하는 조건의 집합과 관련된 필드의 기본 값을 정의한다. 파드 시큐리티 폴리시 제어는 선택적인 어드미션 컨트롤러로서 구현된다.

  파드 시큐리티 폴리시는 쿠버네티스 v1.21에서 사용 중단되었고, v1.25에서 제거되었다. 그 대신에 파드 시큐리티 어드미션 또는 써드파티 어드미션 플러그인을 사용한다.

• 파드 중단(Disruption)LINK

  파드 중단은 노드에 있는 파드가 자발적 또는 비자발적으로 종료되는 절차이다.

  [+]

  자발적 중단은 애플리케이션 소유자 또는 클러스터 관리자가 의도적으로 시작한다. 비자발적 중단은 의도하지 않은 것이며, 노드의 리소스 부족과 같은 피할 수 없는 문제 또는 우발적인 삭제로 인해 트리거가 될 수 있다.

• 파드 프라이어리티(Pod Priority)LINK

  파드 프라이어리티는 다른 파드에 대한 상대적인 중요도를 나타낸다.

  [+]

  파드 프라이어리티는 특정 파드에 다른 파드와 비교하여 높거나 낮은 스케줄링 우선 순위를 설정할 수 있도록 해 주며, 이는 프로덕션 클러스터 워크로드에 있어서 중요한 기능이다.

• 파드(Pod)LINK

  가장 작고 단순한 쿠버네티스 오브젝트. 파드는 사용자 클러스터에서 동작하는 컨테이너의 집합을 나타낸다.

  [+]

  파드는 일반적으로 하나의 기본 컨테이너를 실행하기 위해서 구성된다. 또한 파드는 로깅과 같이 보완적인 기능을 추가하기 위한 사이드카 컨테이너를 선택적으로 실행할 수 있다. 파드는 보통 디플로이먼트에 의해서 관리된다.

• 파이널라이저(Finalizer)LINK

  파이널라이저는 쿠버네티스가 오브젝트를 완전히 삭제하기 이전, 삭제 표시를 위해 특정 조건이 충족될 때까지 대기하도록 알려주기 위한 네임스페이스에 속한 키(namespaced key)이다. 파이널라이저는 삭제 완료된 오브젝트가 소유한 리소스를 정리하기 위해 컨트롤러에게 알린다.

  [+]

  파이널라이저를 가진 특정한 오브젝트를 쿠버네티스가 삭제하도록 지시할 때, 쿠버네티스 API는 .metadata.delationTimestamp을 덧붙여 삭제하도록 오브젝트에 표시하며, 202 상태코드(HTTP "Accepted")을 리턴한다. 대상 오브젝트가 Terminating 상태를 유지하는 동안 컨트롤 플레인 또는 다른 컴포넌트는 하나의 파이널라이저에서 정의한 작업을 수행한다. 정의된 작업이 완료 후에, 그 컨트롤러는 대상 오브젝트로부터 연관된 파이널라이저을 삭제한다. metadata.finalizers 필드가 비어 있을 때, 쿠버네티스는 삭제가 완료된 것으로 간주하고 오브젝트를 삭제한다.

  파이널라이저가 리소스들의 가비지 컬렉션을 제어하도록 사용할 수 있다. 예를 들어, 하나의 파이널라이저를 컨트롤러가 대상 리소소를 삭제하기 전에 연관된 리소스들 또는 인프라를 정리하도록 정의할 수 있다.

• 퍼시스턴트 볼륨 클레임(Persistent Volume Claim)LINK

  컨테이너의 볼륨으로 마운트될 수 있도록 퍼시스턴트볼륨(PersistentVolume)에 정의된 스토리지 리소스를 요청한다.

  [+]

  스토리지의 양, 스토리지에 엑세스하는 방법(읽기 전용, 읽기 그리고/또는 쓰기) 및 재확보(보존, 재활용 혹은 삭제) 방법을 지정한다. 스토리지 자체에 관한 내용은 퍼시스턴트볼륨 오브젝트에 설명되어 있다.

• 퍼시스턴트 볼륨(Persistent Volume)LINK

  클러스터의 스토리지를 나타내는 API 오브젝트이다. 보통은 개별 파드보다 수명이 긴 플러그 가능한 형태의 리소스로 제공한다.

  [+]

  퍼시스턴트볼륨(PV)은 스토리지를 어떻게 제공하고 사용하는지를 추상화하는 API를 제공한다. PV는 스토리지를 미리 생성할 수 있는 경우에 사용한다(정적 프로비저닝). 온-디맨드 스토리지(동적 프로비저닝)가 필요한 경우에는 퍼시스턴트볼륨클레임(PVC)을 대신 사용한다.

• 프록시(Proxy)LINK

  컴퓨팅에서 프록시는 원격 서비스를 위한 중개자 역할을 하는 서버이다.

  [+]

  클라이언트는 프록시와 통신한다. 프록시는 클라이언트에게 받은 데이터를 복사하여 실제 서버에게 보내고 실제 서버는 이에 대한 응답을 프록시에게 보낸다. 마지막으로 프록시는 실제 서버에게 받은 응답을 클라이언트에게 전달한다.

  kube-proxy는 클러스터의 각 노드에서 실행되는 네트워크 프록시로, 쿠버네티스 서비스 개념의 일부를 구현한다.

  kube-proxy를 일반 사용자 영역 프록시(plain userland proxy) 서비스로 실행할 수 있다. 운영체제가 지원한다면, 더 적은 시스템 리소스를 사용하여 동일한 효과를 내는 하이브리드 방식으로 kube-proxy를 대신 실행할 수 있다.

• 헬름 차트(Helm Chart)LINK

  헬름(Helm) 도구를 통해 관리할 수 있는 사전 구성된 쿠버네티스 리소스 패키지

  [+]

  차트는 쿠버네티스 애플리케이션을 생성하고 공유하는 반복 가능한 방법을 제공한다. 단일 차트는 Memcached 파드와 같이 간단한 것부터 HTTP 서버, 데이터베이스, 캐시 등이 포함된 전체 웹 앱 스택과 같은 복잡한 것까지 배포하는 데 사용할 수 있다.

• 호스트에일리어스(HostAlias)LINK

  호스트에일리어스는 파드의 hosts 파일에 주입될 IP 주소와 호스트네임간의 매핑이다.

  [+]

  호스트에일리어스은 명시된 경우에만 파드의 hosts 파일에 주입되는 호스트네임 및 IP 주소의 선택적 목록이다. 이는 hostNetwork 모드를 사용하고 있지 않은 파드에서만 유효하다.