- 문서
- 쿠버네티스 블로그
- 교육
- 파트너
- Community
- 사례 연구
- 버전
- Release Information
- v1.24
- v1.23
- v1.22
- v1.21
- v1.20
- 한국어 (Korean)
- English
- 中文 (Chinese)
- 日本語 (Japanese)
- Français (French)
- Italiano (Italian)
- Deutsch (German)
- Español (Spanish)
- Português (Portuguese)
- Bahasa Indonesia
- Tiếng Việt (Vietnamese)
- Русский (Russian)
- Polski (Polish)
- Українська (Ukrainian)
용어집
이 용어집은 쿠버네티스 용어의 종합적이고 표준화된 리스트를 제공한다. 용어집은 K8s 고유의 기술 용어 뿐만 아니라, 맥락을 이해하는데 유용한 더 일반적인 용어도 포함한다.
태그에 따라 용어 필터링
.
Architecture
Community
Core Object
Extension
Fundamental
Networking
Operation
Security
Storage
Tool
User Type
Workload
모두 선택
모두 선택 해제다음 [+] 표시를 클릭하면 각 용어에 대한 더 자세한 설명을 볼 수 있다.
- Affinity
In Kubernetes, affinity is a set of rules that give hints to the scheduler about where to place pods.
[+] - API 그룹(API Group)
쿠버네티스 API의 연관된 경로들의 집합.
[+]API 서버의 구성을 변경하여 각 API 그룹을 활성화하거나 비활성화할 수 있다. 특정 리소스에 대한 경로를 비활성화하거나 활성화할 수도 있다. API 그룹을 사용하면 쿠버네티스 API를 더 쉽게 확장할 수 있다. API 그룹은 REST 경로 및 직렬화된 오브젝트의
apiVersion
필드에 지정된다.- 자세한 내용은 [API 그룹(/ko/docs/concepts/overview/kubernetes-api/#api-그룹과-버전-규칙)을 참조한다.
- API 서버별칭:kube-apiserver
API 서버는 쿠버네티스 API를 노출하는 쿠버네티스 컨트롤 플레인 컴포넌트이다. API 서버는 쿠버네티스 컨트롤 플레인의 프론트 엔드이다.
[+]쿠버네티스 API 서버의 주요 구현은 kube-apiserver 이다. kube-apiserver는 수평으로 확장되도록 디자인되었다. 즉, 더 많은 인스턴스를 배포해서 확장할 수 있다. 여러 kube-apiserver 인스턴스를 실행하고, 인스턴스간의 트래픽을 균형있게 조절할 수 있다.
- cgroup
선택적으로 리소스를 격리, 관리, 제한하는 리눅스 프로세스의 그룹.
[+]cgroup은 프로세스 집합에 대해서 리소스 사용(CPU, 메모리, 디스크 I/O, 네트워크)을 격리하고, 관리하며, 제한하는 리눅스 커널 기능이다.
- Disruption
Disruptions are events that lead to one or more Pods going out of service. A disruption has consequences for workload resources, such as Deployment, that rely on the affected Pods.
[+]If you, as cluster operator, destroy a Pod that belongs to an application, Kubernetes terms that a voluntary disruption. If a Pod goes offline because of a Node failure, or an outage affecting a wider failure zone, Kubernetes terms that an involuntary disruption.
See Disruptions for more information.
- Dockershim
The dockershim is a component of Kubernetes version 1.23 and earlier. It allows the kubelet to communicate with Docker Engine.
[+]Starting with version 1.24, dockershim has been removed from Kubernetes. For more information, see Dockershim FAQ.
- Ephemeral Container
A Container type that you can temporarily run inside a Pod.
[+]If you want to investigate a Pod that's running with problems, you can add an ephemeral container to that Pod and carry out diagnostics. Ephemeral containers have no resource or scheduling guarantees, and you should not use them to run any part of the workload itself.
- Event
Each Event is a report of an event somewhere in the cluster. It generally denotes some state change in the system.
[+]Events have a limited retention time and triggers and messages may evolve with time. Event consumers should not rely on the timing of an event with a given reason reflecting a consistent underlying trigger, or the continued existence of events with that reason.
Events should be treated as informative, best-effort, supplemental data.
In Kubernetes, auditing generates a different kind of Event record (API group
audit.k8s.io
). - Finalizer
Finalizers are namespaced keys that tell Kubernetes to wait until specific conditions are met before it fully deletes resources marked for deletion. Finalizers alert controllers to clean up resources the deleted object owned.
[+]When you tell Kubernetes to delete an object that has finalizers specified for it, the Kubernetes API marks the object for deletion by populating
.metadata.deletionTimestamp
, and returns a202
status code (HTTP "Accepted"). The target object remains in a terminating state while the control plane, or other components, take the actions defined by the finalizers. After these actions are complete, the controller removes the relevant finalizers from the target object. When themetadata.finalizers
field is empty, Kubernetes considers the deletion complete and deletes the object.You can use finalizers to control garbage collection of resources. For example, you can define a finalizer to clean up related resources or infrastructure before the controller deletes the target resource.
- kube-proxy
kube-proxy는 클러스터의 각 노드에서 실행되는 네트워크 프록시로, 쿠버네티스의 서비스 개념의 구현부이다.
[+]kube-proxy는 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다.
kube-proxy는 운영 체제에 가용한 패킷 필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)한다.
- Manifest
Specification of a Kubernetes API object in JSON or YAML format.
[+]A manifest specifies the desired state of an object that Kubernetes will maintain when you apply the manifest. Each configuration file can contain multiple manifests.
- Master
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. - Minikube
로컬에서 쿠버네티스를 실행하기 위한 도구.
[+]Minikube는 VM이나 사용자 컴퓨터에서 단일 노드 클러스터를 실행한다. Minikube를 사용하여 학습 환경에서 쿠버네티스 시도하기를 할 수 있다.
- QoS 클래스(QoS Class)
QoS 클래스(서비스 품질 클래스)는 쿠버네티스가 클러스터 안의 파드들을 여러 클래스로 구분하고, 스케줄링과 축출(eviction)에 대한 결정을 내리는 방법을 제공한다.
[+]파드의 QoS 클래스는 생성 시점의 컴퓨팅 리소스 요청량과 제한 값에 기반해서 설정된다. QoS 클래스는 파드의 스케줄링과 축출을 위한 결정을 내릴 때 사용된다. 쿠버네티스는 파드에
Guaranteed
,Burstable
또는BestEffort
중 하나를 QoS 클래스로 할당할 수 있다. - Shuffle-sharding
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.
- UID
오브젝트를 중복 없이 식별하기 위해 쿠버네티스 시스템이 생성하는 문자열.
[+]쿠버네티스 클러스터가 구동되는 전체 시간에 걸쳐 생성되는 모든 오브젝트는 서로 구분되는 UID를 갖는다. 이는 기록상 유사한 오브젝트의 출현을 서로 구분하기 위함이다.
- 가비지(Garbage) 수집
쿠버네티스가 클러스터 자원을 정리하기 위해 사용하는 다양한 방법을 종합한 용어이다.
[+]쿠버네티스는 사용되지 않는 컨테이너와 이미지, 실패한 파드, 타겟 리소스가 소유한 오브젝트, 종료된 잡, 그리고 만료되거나 실패한 리소스를 정리하기 위해 가비지 수집을 사용한다.
- 노드(Node)
노드는 쿠버네티스의 작업 장비(worker machine)이다.
[+]작업 노드는 클러스터에 따라 VM이거나 물리 머신일 것이다. 파드 실행에 필요한 로컬 데몬과 서비스를 가지고 있으며, 콘트롤 플레인에 의해서 관리된다. 노드에 있는 데몬은 kubelet, kube-proxy와 도커(Docker) 같이 컨테이너 런타임을 구현한 CRI를 포함한다.
초기 쿠버네티스 버전에서는 노드를 "미니언(Minions)"으로 불렀었다.
- 데이터 플레인(Data Plane)컨테이너가 실행되고 네트워크에 연결될 수 있게 CPU, 메모리, 네트워크, 스토리지와 같은 능력을 제공하는 레이어. [+]
컨테이너가 실행되고 네트워크에 연결될 수 있게 CPU, 메모리, 네트워크, 스토리지와 같은 능력을 제공하는 레이어.
- 도커(Docker)
도커(구체적으로, 도커 엔진)는 운영 시스템 수준의 가상화를 제공하는 소프트웨어 기술이며, containers 로도 알려져 있다.
[+]Docker는 리눅스 커널의 리소스 격리 기능을 사용하며, 그 격리 기능의 예는 cgroups, 커널 네임스페이스, OverlayFS와 같은 조합 가능한 파일 시스템, 컨테이너가 단일 리눅스 인스턴스에서 독립적으로 실행되게 하여 가상 머신(VM)을 시작하고 관리하는 오버헤드를 피할 수 있도록 하는 기타 기능 등이 있다.
- 디플로이먼트(Deployment)
일반적으로 로컬 상태가 없는 파드를 실행하여 복제된 애플리케이션을 관리하는 API 오브젝트.
[+]각 레플리카는 파드로 표현되며, 파드는 클러스터의 노드에 분산된다. 로컬 상태가 필요한 워크로드의 경우 스테이트풀셋(StatefulSet)의 사용을 고려한다.
- 레플리카셋(ReplicaSet)
레플리카셋은 (목표로) 주어진 시간에 실행되는 레플리카 파드 셋을 유지 관리 한다.
[+]디플로이먼트(Deployment) 와 같은 워크로드 오브젝트는 레플리카셋을 사용해서 해당 레플리카셋의 스펙에 따라 구성된 파드 의 수를 클러스터에서 실행한다.
- 스테이트풀셋(StatefulSet)
파드 집합의 디플로이먼트와 스케일링을 관리하며, 파드들의 순서 및 고유성을 보장한다 .
[+]디플로이먼트와 유사하게, 스테이트풀셋은 동일한 컨테이너 스펙을 기반으로 둔 파드들을 관리한다. 디플로이먼트와는 다르게, 스테이트풀셋은 각 파드의 독자성을 유지한다. 이 파드들은 동일한 스팩으로 생성되었지만, 서로 교체는 불가능하다. 다시 말해, 각각은 재스케줄링 간에도 지속적으로 유지되는 식별자를 가진다.
스토리지 볼륨을 사용해서 워크로드에 지속성을 제공하려는 경우, 솔루션의 일부로 스테이트풀셋을 사용할 수 있다. 스테이트풀셋의 개별 파드는 장애에 취약하지만, 퍼시스턴트 파드 식별자는 기존 볼륨을 실패한 볼륨을 대체하는 새 파드에 더 쉽게 일치시킬 수 있다.
- 이름(Name)
[+]/api/v1/pods/some-name
과 같이, 리소스 URL에서 오브젝트를 가리키는 클라이언트 제공 문자열.특정 시점에 같은 종류(kind) 내에서는 하나의 이름은 하나의 오브젝트에만 지정될 수 있다. 하지만, 오브젝트를 삭제한 경우, 삭제된 오브젝트와 같은 이름을 새로운 오브젝트에 지정 가능하다.
- 커스텀 리소스 데피니션(CustomResourceDefinition)
사용자 정의 서버를 완전히 새로 구축할 필요가 없도록 쿠버네티스 API 서버에 추가할 리소스를 정의하는 사용자 정의 코드.
[+]만약 공개적으로 지원되는 API 리소스가 사용자의 요구를 충족할 수 없는 경우, 커스텀 리소스 데피니션은 사용자의 환경에 따라 쿠버네티스 API를 확장하게 해준다.
- 컨테이너 런타임
컨테이너 런타임은 컨테이너 실행을 담당하는 소프트웨어이다.
[+]쿠버네티스는 containerd, CRI-O와 같은 컨테이너 런타임 및 모든 Kubernetes CRI (컨테이너 런타임 인터페이스) 구현체를 지원한다.
- 컨테이너(Container)
소프트웨어와 그것에 종속된 모든 것을 포함한 가볍고 휴대성이 높은 실행 가능 이미지.
[+]컨테이너는 애플리케이션과 기반이 되는 호스트 인프라의 관계를 분리시켜서, 애플리케이션을 다른 클라우드 또는 OS 환경에서도 쉽게 디플로이하고 쉽게 스케일되게 한다.
- 컨트롤러(Controller)
쿠버네티스에서 컨트롤러는 클러스터 의 상태를 관찰 한 다음, 필요한 경우에 생성 또는 변경을 요청하는 컨트롤 루프이다. 각 컨트롤러는 현재 클러스터 상태를 의도한 상태에 가깝게 이동한다.
[+]컨트롤러는 api 서버 (컨트롤 플레인(Control Plane)의 일부)를 통해 클러스터의 공유 상태를 감시한다.
일부 컨트롤러는 컨트롤 플레인 내부에서 실행되며, 쿠버네티스 작업의 핵심인 컨트롤 루프를 제공한다. 예를 들어 디플로이먼트 컨트롤러, 데몬셋 컨트롤러, 네임스페이스 컨트롤러 그리고 퍼시스턴트 볼륨 컨트롤러(및 그 외)는 모두 "kube-controller-manager" 내에서 실행 된다.
- 쿠버네티스 API(Kubernetes API)
RESTful 인터페이스를 통해서 쿠버네티스 기능을 제공하고 클러스터의 상태를 저장하는 애플리케이션.
[+]쿠버네티스 리소스와 "의도에 대한 레코드"는 모두 API 오브젝트로 저장되며, API로의 RESTful 호출을 통해서 수정된다. API는 구성이 선언적인 방법으로 관리되도록 한다. 사용자는 쿠버네티스 API와 직접 상호 작용할 수 있으며,
kubectl
과 같은 툴을 사용할 수도 있다. 쿠버네티스 API의 핵심은 유연하며 사용자 정의 리소스를 지원하기 위해 확장될 수도 있다. - 테인트(Taint)
세 가지 필수 속성: 키(key), 값(value), 효과(effect)로 구성된 코어 오브젝트. 테인트는 파드가 노드나 노드 그룹에 스케줄링되는 것을 방지한다.
[+]테인트 및 톨러레이션(toleration)은 함께 작동하며, 파드가 적절하지 못한 노드에 스케줄되는 것을 방지한다. 하나 이상의 테인트가 노드에 적용될 수 있으며, 이것은 노드에 해당 테인트를 극복(tolerate)하지 않은 파드를 허용하지 않도록 표시한다.
- 파드 시큐리티 폴리시(Pod Security Policy)
파드 생성과 업데이트에 대한 세밀한 인가를 활성화한다.
[+]파드 명세에서 보안에 민감한 측면을 제어하는 클러스터 수준의 리소스.
PodSecurityPolicy
오브젝트는 파드가 시스템에 수용될 수 있도록 파드가 실행해야 하는 조건의 집합과 관련된 필드의 기본 값을 정의한다. 파드 시큐리티 폴리시 제어는 선택적인 어드미션 컨트롤러로서 구현된다.파드 시큐리티 폴리시는 쿠버네티스 v1.21에서 사용 중단되었고, v1.25에서 제거될 예정이다. 파드 시큐리티 어드미션 또는 써드파티 어드미션 플러그인으로 이전(migrate)하는 것을 추천한다.
최종 수정 June 18, 2021 at 4:18 PM PST: [ko] Remove exec permission on markdown files (bf00b72c79)