쿠버네티스 용어

Kubernetes 용어, k8s 용어

쿠버네티스 용어

1 기초

영어명	한국어명	설명
Affinity	어피니티	팟(Pod)을 배치할 위치에 대한 힌트를 스케줄러에 제공하는 규칙 세트
Annotation	애노테이션	객체에 임의의 메타데이터를 붙이기 위한 키-값 쌍. 애노테이션 내의 메타데이터는 소량 또는 대량이거나, 구조화 또는 비구조화될 수 있으며, 레이블로는 허용되지 않는 문자(character)도 포함할 수 있다. 툴, 라이브러리 등의 클라이언트는 이 메타데이터를 조회할 수 있다.
API Group	API 그룹	쿠버네티스 API에서 상대경로 세트
API server	API 서버	(kube-apiserver) 쿠버네티스 API를 노출하는, 컨트롤 플레인 컴포넌트. 쿠버네티스 컨트롤 플레인에 대한 프론트엔드. 수평적 스케일링(즉, 더 많은 인스턴스를 디플로이하는 스케일링)을 위해 설계되었다. 쿠버네티스 고가용성 클러스터 구축 참고
Cluster	클러스터 ★★★	'노드'라고 불리는 머신들의 집합. 쿠버네티스가 관리하는 컨테이너화된 애플리케이션들을 구동함. 클러스터는 최소 1개 이상의 컨트롤 플레인 컴포넌트와 노드로 구성된다.
Container	컨테이너	경량·포터블 실행가능 이미지. 소프트웨어와 그에 필요한 의존성 모듈들을 포함함. 컨테이너는 하부의 호스트 인프라스트럭처로부터 애플리케이션을 분리함으로써, 다른 클라우드 또는 다른 OS 환경에 배포하거나 스케일링하는 것을 간편하게 해준다.
Container Environment Variables	컨테이너 환경 변수	Pod에서 실행되는 컨테이너들 내부로 유용한 정보를 제공하는 키/값 쌍들. 작동중인 컨테이너화 애플리케이션들이 필요로 하는 중요 리소스 정보를 컨테이너에 제공한다. 예: 파일시스템, 컨테이너 자체에 대한 정보, 다른 클러스터 리소스(서비스 엔드포인트) 등.
Controller	컨트롤러	API 서버를 통해 클러스터 공유된 상태를 감시하고, 현재 상태를 원하는 상태로 이행시키도록 하는 컨트롤 루프. 현재 쿠버네티스에 포함된 컨트롤러의 예시: 레플리케이션 컨트롤러, 엔드포인트 컨트롤러, 네임스페이스 컨트롤러, 서비스어카운트 컨트롤러
CustomResourceDefinition	커스텀 리소스 정의	(CRD) 커스텀 서버를 구축하는 대신, 쿠버네티스 API서버에 추가하기 위해 리소스를 정의하는 커스텀 코드. 공개 지원되는 API 리소스가 당신의 요구조건에 맞지 않는다면, 이것을 이용하여 쿠버네티스 API를 확장할 수 있다.
DaemonSet	데몬셋	Pod 복사본이, 클러스터 내 어느 노드 집합에서든 잘 작동하게 함. 흔히 모든 노드에서 작동해야 하는 시스템 데몬(예: 로그 수집기, 모니터링 에이전트)을 배포하는 데에 사용한다.
Deployment	디플로이먼트 ★★★	복제된(replicated) 애플리케이션을 관리하는 API 객체. 각 레플리카는 각각 하나의 Pod로 대표되며, 그러한 Pod들은 클러스터 내 노드들에 걸쳐 배포된다.
docker	도커	OS수준 가상화(즉 컨테이너)를 제공하는 소프트웨어 기술. 도커는 리눅스 커널의 리소스 격리 기능(cgroups, 커널 네임스페이스)과 유니온 마운트 가능 파일시스템(OverlayFS)을 이용하여, 독립된 "컨테이너들"이 하나의 리눅스 인스턴스 내에서 구동될 수 있게 함으로써, 가상머신(VM)을 구동시키는 오버헤드를 피할 수 있다.
Image	이미지	애플리케이션 실행에 필요한 소프트웨어 집합을 가지고 있는 저장된 컨테이너 인스턴스. 컨테이너 레지스트리에 저장하고, 로컬 시스템으로 가져오고(pull), 애플리케이션으로서 실행할 수 있는 소프트웨어 패키징 방법. 이미지 내에 포함되는 메타데이터에는, 구동해야 할 실행파일, 누가 빌드했는지 등 여러가지 정보를 담을 수 있다.
Init Container	이닛 컨테이너	1개 이상의 초기화 컨테이너. 앱 컨테이너 실행 전에 구동 완료되어야 함. 초기화(init) 컨테이너는 일반적인 앱 컨테이너와 거의 유사하지만 일부 다른 점이 있음: 모든 앱 컨테이너들이 시작하기 전에 구동 완료되어야 한다. init 컨테이너들은 연쇄적으로 실행된다: 각 init 컨테이너는 다음 init 컨테이너가 시작하기 전에 구동 완료되어야 한다.
Job	잡	(작업) 완결적으로 수행되는 유한·배치 작업. 1개 이상의 Pod 객체를 생성하고, 그것들이 지정한 개수만큼이 성공적으로 완료되게 한다. Pod들이 성공적으로 완료되면 Job은 그것을 인지한다.
kube-apiserver	큐브-API서버	(API서버) 쿠버네티스 API를 노출하는, 컨트롤 플레인 컴포넌트. 쿠버네티스 컨트롤 플레인에 대한 프론트엔드. 수평적 스케일링(즉, 더 많은 인스턴스를 디플로이하는 스케일링)을 위해 설계되었다. 쿠버네티스 고가용성 클러스터 구축 참고
kube-controller-manager	큐브-컨트롤러-매니저	(컨트롤러-매니저) 컨트롤러를 구동하는 컨트롤 플레인 컴포넌트. 논리적으로, 각 컨트롤러는 개별 프로세스이지만, 복잡성을 낮추기 위해, 모두가 단일 바이너리로 컴파일되고 단일 프로세스 내에서 실행된다.
kube-proxy	큐브-프록시 ★★★	클러스터 내 각 노드에서 실행되는 네트워크 프록시
Kubectl	큐브컨트롤	쿠버네티스 API 서버와 통신하는 커맨드라인 도구. kubectl을 이용하여 쿠버네티스 객체를 생성, 검사, 업데이트, 삭제할 수 있다.
Kubelet	큐블릿	클러스터 내 각 노드에서 실행되는 에이전트. kubelet은 다양한 메커니즘으로 제공된 PodSpec 집합을 가지며, PodSpec에 기술된 컨테이너들이 정상적으로 작동하도록 한다. kubelet은 쿠버네티스에 의해 생성되지 않은 컨테이너들은 관리하지 않는다.
Kubernetes API	쿠버네티스 API	RESTful 인터페이스를 통해 쿠버네티스 기능을 제공하고, 클러스터의 상태를 저장하는 애플리케이션. 쿠버네티스 리소스와 "의도된 레코드들"은 모두 API 객체로서 저장되며, API에 대한 RESTful 호출을 통해 변경된다. API는 설정이 선언적인 방식으로 관리되게 한다. 사용자는 쿠버네티스 API와 직접, 또는 kubectl과 같은 도구를 통해, 상호작용할 수 있다. 코어 쿠버네티스 API는 유연하며, 커스텀 리소스를 지원하기 위해 확장될 수 있다.
Label	레이블	(라벨) 사용자에게 의미있는 속성들을 식별하는 태그 객체. 레이블은 Pod 등 객체에 부착되는 키/값 쌍들이다. 일부 객체들을 묶음 짓거나 선택하기 위해 사용된다.
Minikube	미니큐브	로컬에서 쿠버네티스를 구동하는 도구. 미니큐브는 하나의 VM 내에 단일노드 클러스터를 구동한다.
Name	네임	(이름) 리소스 URL(예: /api/v1/pods/some-name)에 대한 객체를 참조하는 문자열. 클라이언트가 생성함. 주어진 종류(kind) 내에서 특정한 이름은 동시에 하나의 객체만이 가질 수 있다. 즉, 해당 객체를 삭제하고 나면 그 이름으로 새로운 객체를 만들 수 있다.
Namespace	네임스페이스	(이름공간) 동일한 물리 클러스터에서 여러 가상 클러스터를 지원하기 위해 쿠버네티스가 사용하는 추상화. 네임스페이스는 클러스터 내의 객체들을 묶음지을 때 사용하며, 클러스터 내 리소스들을 구분하는 방법이 된다. 리소스 이름은 하나의 네임스페이스 내에서 유일(unique)해야 한다.
Node	노드 ★★★	(미니언) 쿠버네티스의 worker 머신. 워커 머신은 클러스터에 속하는 VM이거나 물리 머신이다. 노드는 Pod들을 구동하기 위해 필요한 서비스들을 가지며, 컨트롤 플레인 컴포넌트에 의해 관리된다. 노드 상의 서비스들로는 도커, kubelet, kube-proxy가 포함된다.
Pod	포드 ★★★	(팟) 최소단위 쿠버네티스 객체. 클러스터 상에서 동작하는 컨테이너 집합. Pod는 흔히 단일 프라이머리 컨테이너를 구동하기 위해 셋업된다. 로깅과 같은 보조 기능을 가지는 추가 사이드카 컨테이너를 구동할 수 있다. Pod들은 일반적으로 Deployment로 관리된다.
Pod Security Policy	Pod 보안 정책	Pod 생성·업데이트에 관한 세밀한 권한인증 제공. Pod 스펙에 대한 보안적 측면을 통제하는 클러스터-수준 리소스. PodSecurityPolicy 객체는, 관련 필드들에 대한 기본값들을 포함하여, Pod가 시스템 내로 받아들여지기 위해 구동될 때의 조건들 집합을 정의한다. Pod 보안정책 통제는 선택적인 입장승인 컨트롤러로서 구현된다.
RBAC (Role-Based Access Control)	RBAC	정책 권한인증 결정을 관리함. 쿠버네티스API에 대한 접근정책을 관리자가 동적으로 설정 가능. RBAC는, 퍼미션 규칙을 포함하는 역할(roles)과, 사용자 집합에 역할로 정의된 퍼미션들을 승인하는 역할 바인딩(role bindings)을 이용한다.
ReplicaSet	레플리카셋	차세대 레플리케이션 컨트롤러. ReplicationController과 마찬가지로, 특정 수의 pod 레플리카들이 동시에 구동되도록 한다. 단 Replication Controller가 균등-기반의 셀렉터 요건만을 지원하는 반면, ReplicaSet은 새로 나온 집합-기반의 셀렉터 요건(레이블 사용자 가이드에 기술됨)도 지원한다.
Resource Quotas	리소스 쿼타	네임스페이스 당 리소스 총소비량을 제한하는 제약. 프로젝트 내에서 리소스들이 소비할 수 있는 컴퓨팅 리소스 총량 뿐만 아니라, 유형에 따라 하나의 네임스페이스 내에 생성할 수 있는 객체의 수량을 제한한다.
Selector	셀렉터	(선택자) 레이블 기준으로 리소스 목록을 필터링할 수 있게 함 레이블로써 리소스를 필터링하기 위해 리소스 목록을 조회할 때 적용된다.
Service	서비스 ★★★	Pod 집합과 같은 애플리케이션들에 접근하는 방법을 기술하는 API 객체. 포트, 로드밸런서를 기술할 수 있음. 클러스터에 대한 액세스 포인트는 내부(internal)일수도 외부(external)일수도 있다.
Service Account	서비스 어카운트	(서비스 계정) Pod 내에서 구동되는 프로세스에 대한 식별 제공. Pod 내 프로세스들이 클러스터에 접근할 때, 특정 서비스 계정(예: default)으로 API 서버에게 인증을 받는다. Pod를 생성할 때 서비스 계정을 지정하지 않으면, 동일 네임스페이스 내의 기본 서비스 계정이 자동으로 할당된다.
StatefulSet	스테이트풀셋	Deployment, Pod의 스케일링을 관리하고, Pod들에 대한 배치와 유일성을 보장함. Deployment와 마찬가지로 동일 컨테이너 스펙을 기반으로 Pod들을 관리하지만, Deployment와는 달리 Pod 각각에 대해 스티키 identity를 유지한다. Pod들은 같은 스펙으로 생성되지만 교체는 불가능하다: 각각은 persistent 식별자를 가지며, 리스케줄링시에도 계속 유지된다. StatefulSet은 기타 다른 컨트롤러와 같은 패턴으로 운영된다. StatefulSet 객체에 원하는 상태를 정의하면, StatefulSet 컨트롤러는 현재 상태에서 그 원하는 상태로 이행하기 위해 필요한 업데이트를 생성한다.
UID	UID	객체 식별자 문자열. 쿠버네티스 시스템이 생성함. 쿠버네티스 클러스터의 전체 수명주기에 걸쳐 생성되는 모든 객체는 각각의 UID를 가진다. 유사한 개체들의 발생 이력들을 구분하기 위한 것이다.
Volume	볼륨	데이터를 담는 디렉토리. Pod 내 컨테이너들이 접근가능함. 쿠버네티스 볼륨은 pod에 소속되는 동안 유지된다. 즉, 볼륨은 pod 내에서 구동되는 컨테이너들보다 오래 유지되며, 그 데이터는 컨테이너가 재시작되더라도 계속 보존된다.

2 도구, 코어객체, 아키텍처 등

영어명	한국어명	설명
도구
Helm Chart	헬름 차트	(차트) 미리-설정된 쿠버네티스 리소스 패키지. Helm 도구로 관리 가능. 차트는 쿠버네티스 애플리케이션을 생성·공유하는 재현가능한 방법을 제공한다. 단일 차트는 단순한 것(예: memchached Pod)이나 복잡한 것(HTTP 서버, 데이터베이스, 캐시 등을 가지는 전체 웹앱 스택)을 배포할 때 사용될 수 있다.
Kops	콥스	쿠버네티스 클러스터를 생성·삭제·업그레이드·유지보수(프로덕트급·고가용성)하는 CLI 도구. ( 현재 공식지원되는 환경은 AWS임. GCE와 VMware vSphere는 알파버전 ) kops는 클러스터 배포 과정: 전자동 설치, DNS-기반 클러스터 식별, 자가-치유(모든 것이 오토스케일링 그룹 내에서 구동됨), 제한적 OS 지원(Debian 권장, 우분투 16.04 지원함, CentOS와 RHEL 조기 지원), 고가용성(HA) 지원, 직접적인 배포능력 또는 테라폼 매니페스트 생성. 구성요소로서 Kubeadm을 사용하여 클러스터를 구축할 수 있다. kops는 kubeadm 작업 기반.
Kubeadm	큐브어드민	빠르게 쿠버네티스를 설치하고 보안 클러스터를 구성할 수 있는 도구. kubeadm으로 컨트롤 플레인과 노드 컴포넌트들 설치 가능
코어 오브젝트
ConfigMap	컨피그맵	非기밀 데이터를 키-값 쌍으로 저장하기 위해 사용하는 API 객체. 환경변수, 커맨드라인 인자, 볼륨 내의 설정파일로 사용될 수 있음. 컨피그맵을 사용하면 컨테이너 이미지에서 해당 환경에 국한된 설정을 분리할 수 있다. 그렇게 하면 애플리케이션을 어디로든 쉽게 이전할 수 있게(portable) 된다. 단, 기밀 데이터를 저장할 때는 Secret을 이용하라.
Secret	시크릿	(비밀) 패스워드, OAuth 토큰, SSH key와 같은 민감한 정보를 담은 것. rest 암호화를 포함하여, 민감한 정보가 사용되는 방법을 통제하고 사고로 노출될 위험성을 낮추어 준다. Pod는, 볼륨 마운트 내의 파일로서, 또는 pod用 kubelet pulling 이미지에 의해 시크릿을 참조한다. Secret은 기밀 데이터 취급에 적합하고, ConfigMaps는 非기밀 데이터 취급에 적합하다.
Dynamic Volume Provisioning	동적 볼륨 프로비저닝	사용자가 스토리지 볼륨 자동생성을 요청할 수 있게 해주는 것. 동적 프로비저닝을 이용하면, 클러스터 관리자가 스토리지를 미리 프로비저닝해 둘 필요가 없고, 사용자 요청에 따라 자동으로 프로비저닝된다. 동적 볼륨 프로비저닝은 API 객체, StorageClass을 기반으로 하며, 볼륨을 프로비저닝하는 볼륨 플러그인과 그것에 전달되는 파라미터 집합을 참조하여 이루어진다.
Persistent Volume	영구 볼륨	(PV) 클러스터 내 스토리지 일부 조각을 나타내는 API 객체. 개별 Pod의 수명주기를 넘어 보존되는 범용·플러그가능 자원으로서 가용함. PV들은 스토리지를 사용하고자 할 때 그 제공방식의 세부사항들을 추상화하는 API를 제공한다. 스토리지가 사전에 생성되는 시나리오(정적 프로비저닝)에서는 PV들이 직접 사용된다. 반면 온디멘드 스토리지를 필요로 하는 시나리오(동적 프로비저닝)에서는 PV 대신 PVC가 사용된다.
Persistent Volume Claim	영구 볼륨 클레임	(PVC, 영구볼륨 청구) 영구 볼륨 내에 정의되는 스토리지 자원 청구권. 컨테이너에 볼륨으로 마운트되게 함. 스토리지 총량, 스토리지 접근 방법(읽기-전용, 읽기-쓰기 및 독점사용여부), 재청구(유지, 재활용, 삭제) 방법을 지정한다. 단, 스토리지 자체에 대한 세부사항은 PersistentVolume 스펙 내에 있다.
Storage Class	스토리지 클래스	여러가지 스토리지 유형을 표현하는 것 (관리자가 설정함) 클러스터 관리자가 정의한 QoS 수준, 백업정책, 기타 정책에 매핑된다. 각 스토리지클래스는 provisioner, parameters, reclaimPolicy 필드를 포함하며, Persistent Volume을 동적으로 프로비저닝하기 위해 클래스에 소속시킬 때 그 필드들이 사용된다.
Volume Plugin	볼륨 플러그인	Pod 내에서 스토리지 연동을 가능하게 하는 플러그인. 볼륨 플러그인으로 스토리지 볼륨을 Pod에서 사용할 수 있게 부착·마운트할 수 있다. 볼륨 플러그인은 트리 내부에 있을 수도 있고, 트리 외부에 있을 수도 있다. 트리 내부 플러그인은 쿠버네티스 코드 저장소의 일부로서 그것의 릴리즈 사이클을 따름. 트리 외부 플러그인은 독립적으로 개발된다.
Cloud Controller Manager	클라우드 컨트롤러 매니저	1.8에서 알파 기능. 쿠버네티스를 다른 클라우드와 연동하는 방법으로서 릴리즈될 예정. 쿠버네티스 v1.6에는 '클라우드-컨트롤러-매니저'라는 새로운 바이너리가 추가된다. 클라우드-컨트롤러-매니저는 클라우드-관련 컨트롤 루프를 내장한 데몬이다. 클라우드-관련 컨트롤 루프들은 원래는 큐브-컨트롤러-매니저에 있던 것이다. 쿠버네티스 프로젝트에 비해 클라우드 프라바이더들은 각기 다른 페이스(pace)로 개발·배포하기 때문에, 특정 프로바이더에 국한된 코드를 클라우드-컨트롤러-매니저 바이너리로 추상화함으로써 클라우드 벤더들이 코어 쿠버네티스 코드와 독립적으로 발전할 수 있게 한다.
Replication Controller	레플리케이션 컨트롤러	Pod의 인스턴스가 항상 특정 개수로 작동하도록 유지하는 쿠버네티스 서비스 pod에 대한 설정값에 따라 자동으로 pod 인스턴스를 추가·제거한다. 실수로 pod 인스턴스가 삭제되거나 너무 많이 구동되었을 때, 정의된 개수로 복구한다.
아키텍처
kube-scheduler	큐브-스케줄러	노드가 배정되지 않은 새로 생성된 pod을 감지하고 그것이 구동될 노드를 선택하는 컨트롤 플레인 컴포넌트. 스케줄링 결정을 위한 어카운트 내 요소들로는 개별 및 공동의 리소스 요건, 하드웨어/소프트웨어/정책 제약, 연관 및 배격 명세, 데이터 지역성, 워크로드-간 간섭, 데드라인들이 포함된다.
Ingress	인그레스	클러스터 내의 서비스들에 대한 외부 접근(특히 HTTP)을 관리하는 API 객체. 인그레스는 로드 밸런싱, SSL 터미네이션, 이름-기반 버추얼 호스팅을 제공할 수 있다.
Istio	이스티오	마이크로서비스 연동, 트래픽 흐름 관리, 정책 적용, 측정값 수합에 관한 일관된 방법을 제공하는 오픈 플랫폼 (쿠버네티스에 국한된 것은 아님). Istio를 추가할 때 애플리케이션 코드를 변경할 필요는 없다. 그것은 서비스와 네트워크 사이의 인프라스트럭처 계층으로서, 일반적으로 서비스 디플로이먼트들과 결합될 때 서비스 메시로서 참조된다. Istio의 컨트롤 영역은, 하부에 있는 클러스터 관리 플랫폼(예: 쿠버네티스, 메소스피어 등)을 추상화한다.
Network Policy	네트워크 정책	Pod 그룹에 대해, 서로간 또는 외부 네트워크 엔드포인트와의 통신여부를 결정하는 정책 네트워크 정책으로 Pod간 통신, 네임스페이스간 통신, 포트 번호 지정 등을 서술적으로 설정할 수 있음. NetworkPolicy 리소스들은, Pod들을 선택하고 선택된 Pod들에 허용되는 트래픽을 특정하는 규칙을 정의하기 위해, 레이블을 사용한다. 네트워크 정책들은 네트워크 프로바이더가 제공하는 네트워크 플러그인을 통해 실현된다. 그것을 실현해주는 컨트롤러 없이 네트워크 리소스를 만드는 일은 소용 없다는 점을 알아두자.
etcd	etcd	모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성·고가용성 키-값 저장소. 쿠버네티스 클러스터 정보를 담고 있는 etcd 데이터에 대한 백업 계획은 필수이다. etcd에 대해 자세히 알아보려면 etcd 문서를 참고하라.
익스텐션
Managed Service	매니지드 서비스	서드파티 프로바이더가 관리·제공하는 소프트웨어 서비스. 어떤 것이든, 애플리케이션에서 이용할 수 있는 소프트웨어 오퍼링. ( 예: AWS EC2, Azure SQL Database, GCP Pub/Sub )
Service Broker	서비스 브로커	서드파티가 제공·유지보수하는 매니지드 서비스 묶음의 엔드포인트. 서비스 브로커들은 오픈 서비스 브로커 API 스펙을 실현하고, 매니지드 서비스들을 이용하기 위한 애플리케이션用 표준 인터페이스를 제공한다. 서비스 카탈로그는 서비스 브로커를 통해 제공되는 매니지드 서비스에 대한 목록조회·프로비저닝·바인딩 방법을 제공한다.
Service Catalog	서비스 카탈로그	쿠버네티스 클러스터 내에서 구동되는 애플리케이션이, 외부 매니지드 소프트웨어 제공품(예: 클라우드 프로바이더가 제공하는 데이터저장소 서비스)을 간편하게 쓸 수 있도록 해주는 확장기능 API. 서비스 브로커로부터의 외부 매니지드 서비스에 대한 록조회·프로비저닝·바인딩 방법을 제공한다.
운영
Horizontal Pod Autoscaler	수평 Pod 오토스케일러	(HPA) CPU 사용률 등 기타 메트릭 지정대상을 기준으로 pod 레플리카 수를 자동으로 조절하는 API 리소스 주로 레플리케이션 컨트롤러, 디플로이먼트, 레플리카 셋과 함께 사용된다. 스케일링될 수 없는 객체(예: 데몬셋)에는 적용 불가하다.
PodPreset	Pod프리셋	시크릿, 볼륨 마운트, 환경변수와 같은 정보를, pod 생성시 그 내부에 넣어주는 API 객체. 이 객체는 표준 셀렉터들을 이용하여 정보를 넣을 pod를 선택한다. 이것은 podspec 정의들을 불특정(nonspecific)하게 하고, podspec을 특정환경 기준의 설정과 분리(decoupling)한다.
보안
Certificate	인증서	쿠버네티스 클러스터 접근의 유효성 검증을 위해 사용하는 암호학적 보안 파일. 쿠버네티스 클러스터 내의 애플리케이션들이 보안상 안전하게 쿠버네티스 API에 접근할 수 있게 해줌. 특정 API에 대한 클라이언트의 접근권한이 유효한지 검증한다.
Security Context	보안 컨텍스트	Pod 또는 컨테이너의 권한부여, 환경설정 접근을 정의하는 securityContext 필드. 런타임 UID, GID를 포함함. Pod 또는 컨테이너 내의 securityContext 필드는 컨테이너 프로세스들이 사용하는 사용자(runAsUser)와 그룹(fsGroup), 가용량, 권한 설정, 보안 정책(SELinux/AppArmor/Seccomp)을 설정하기 위해 사용된다.
워크로드
CronJob	크론잡	정기 스케줄에 따라 작업이 수행되도록 관리함. 크론잡 객체는, crontab 파일과 유사하게, Cron 형식에 따라 스케줄을 지정한다.

3 사용자 및 커뮤니티

영어명	한국어명	설명
사용자
Developer (여러 뜻)	개발자	(쿠버네티스 개발자) 애플리케이션 개발자 + 코드 컨트리뷰터 + 플랫폼 개발자. 이 용어는 맥락에 따라 다른 의미를 가질 수 있다.
Application Developer	애플리케이션 개발자	쿠버네티스 클러스터에서 작동하는 애플리케이션을 만드는 사람. 애플리케이션 개발자는 애플리케이션의 한 부분에 집중한다. 그들이 관심을 가지는 범위는 규모에 따라 매우 다양할 수 있다.
Code Contributor	코드 컨트리뷰터	(코드 기여자, 커뮤니티 개발자) 쿠버네티스 오픈소스 코드베이스를 개발하고 코드를 기여하는 사람. 1가지 이상의 SIG에 참여하는 활동적인 커뮤니티 멤버이기도 하다.
Platform Developer	플랫폼 개발자	(쿠버네티스 개발자, 익스텐션 개발자) 쿠버네티스 플랫폼을 그들의 프로젝트에 맞게 커스터마이징하는 사람. 플랫폼 개발자는 쿠버네티스 인스턴스(특히 애플리케이션)에 기능을 추가하기 위해 커스텀 리소스를 사용하거나, 애그리게이션 계층으로 쿠버네티스 API를 확장함. 일부 플랫폼 개발자들은 쿠버네티스 커뮤니티에 확장기능을 개발·기여하는 컨트리뷰터이기도 하다. 그외에 일부 개발자들은 클로즈드-소스로 상업용 또는 특정사이트용 확장기능을 개발하기도 한다.
Application Architect	애플리케이션 아키텍트	애플리케이션의 고수준 설계를 담당하는 사람. 아키텍트는 앱 구현체가 그 주변 컴포넌트들과 스케일링·유지보수가능한 방식으로 상호작용하게 한다. 여기서 주변 컴포넌트란 데이터베이스, 로깅 인프라스트럭처 및 기타 마이크로서비스들을 포괄하는 의미이다.
Cluster Architect	클러스터 아키텍트	1벌 이상의 쿠버네티스 클러스터에 관련된 인프라스트럭처를 설계하는 사람. 클러스터 아키텍트는 분산 시스템의 베스트 프랙티스(예: 고가용성, 보안)에 관심을 가진다.
Cluster Operator	클러스터 운영자	(클러스터 관리자) 클러스터들을 설정·제어·모니터링하는 사람. 그들의 주요 책임은 클러스터의 정상적인 작동상태를 유지하는 것이며, 주기적인 유지보수 활동이나 업그레이드와 관련이 있다.
커뮤니티
Approver	승인자	쿠버네티스 코드 기여를 검토하고 승인할 수 있는 사람. '코드 리뷰'는 코드 품질과 정확성에 중점을 두는 반면, '승인'은 기여의 전반적 인수에 중점을 둔다. '전반적 인수'에는 하위·상위 호환성, API와 플래그 컨벤션 부합여부, 세세한 성능과 정합성 이슈, 시스템의 다른 부분과의 상호작용 등이 포함된다. 승인자 지위는 코드베이스의 한 부분을 범위로 한다.
CLA (Contributor License Agreement)	컨트리뷰터 라이선스 동의서	컨트리뷰터가 오픈소스 프로젝트에 참여할 때 동의해야 하는 조건. CLA는 기여된 자료와 지적 재산권(IP)에 수반되는 법적 분쟁을 해소하는 데 도움을 준다.
Cloud Provider	클라우드 프로바이더	쿠버네티스 클러스터를 구동할 수 있는 클라우드 컴퓨팅 플랫폼을 제공하는 회사. 클라우드 프로바이더 또는 클라우드 서비스 프로바이더(CSP)는 클라우드 컴퓨팅 플랫폼을 제공한다. 주로 IaaS, PaaS 따위의 서비스를 제공한다. 클라우드 프로바이더는 쿠버네티스 클러스터를 호스팅하며, 클러스터와 상호작용하는 서비스(로드밸런서, 스토리지 클래스 등)도 제공한다.
Contributor	컨트리뷰터	(기여자) 코드, 문서화에 기여하거나 쿠버네티스 프로젝트 또는 커뮤니티를 돕는 사람. 기여에는 pull 요청(PR), 이슈, 피드백, SIG 참여, 커뮤니티 이벤트 준비가 포함된다.
Downstream (여러 뜻)	다운스트림	코어 쿠버네티스 코드베이스(또는 포크된 저장소)에 의존적인 쿠버네티스 생태계 내의 코드 쿠버네티스 커뮤니티에서는: 다운스트림이라 하면 주로, 코어 쿠버네티스 코드베이스에 의존하는 '생태계, 코드, 서드파티 도구'를 의미한다. 예를 들어, 애플리케이션 기능성 향상을 위해 쿠버네티스의 새로운 기능을 애플리케이션 다운스트림에 반영할 수 있다. GitHub 또는 git에서는: 포크된 저장소를 '다운스트림'이라 하고, 원본소스 저장소는 '업스트림'이라 한다.
Upstream (여러 뜻)	업스트림	코어 쿠버네티스(또는 포크된 저장소). 쿠버네티스 커뮤니티에서는: 업스트림이라 하면 주로, 보편 생태계, 다른 코드, 서드파티 도구에 의존하는 '코어 쿠버네티스 코드베이스'를 의미한다. 예를 들어, 커뮤니티 멤버들은 플러그인 또는 서드파티 도구에 있는 어떤 기능을 코어 코드베이스에 포함시키는 업스트림 반영을 제안할 수 있다. GitHub 또는 git에서는: 원본소스 저장소를 '업스트림'이라 하고, 포크된 저장소는 '다운스트림'이라 한다.
Maintainer	메인테이너	(유지보수자) 교차 영역에 대한 오너십을 가지고 프로젝트의 GitHub 저장소에 쓰기접근을 하는, 쿠버네티스 여러 영역에 활동적인 숙련된 기여자. 메인테이너는, 코드 개발 또는 더 광범위한 조직 활동을 통해 프로젝트의 안정성와 성과를 유지하고 견고한 기여가 되도록, 프로젝트 전반에 걸쳐 활동한다.
Member	멤버	쿠버네티스 커뮤니티에서 지속적으로 활동하는 기여자. 멤버는 이슈와 PR을 자신에게 할당하거나 GitHub 팀을 통해 SIG에 참여할 수 있다. 멤버들의 PR에 대해 pre-submit 테스트가 자동으로 수행된다. 멤버들이 커뮤니티에 활동적인 기여자로서 남아주길 기대한다.
Reviewer	리뷰어	(검토자) 프로젝트의 어떤 부분에 대한 품질과 정확성을 위해 코드를 검토하는 사람. 리뷰어는 코드베이스와 소프트웨어 공학 원리에 대한 지식이 있다. 리뷰어 지위는 코드베이스의 한 부분을 범위로 한다.
SIG (special interest group)	SIG	쿠버네티스 오픈소스 프로젝트에서 진행중인 일부분 또는 거시적 관점을 협업하여 관리하는 커뮤니티 멤버들. SIG 멤버들은 특정 영역(예: 아키텍처, API 체계, 문서화)을 발전시키는 일에 대한 관심을 공유한다. SIG는 SIG 거버넌스 가이드라인을 준수해야 하지만, 그들만의 기여 정책, 소통 채널을 가질 수 있다.
WG (working group)	워킹그룹	(작업그룹) 위원회, SIG, SIG간 활동을 위해 단기·한정·별도 프로젝트의 토론·구현을 촉진하는 그룹. 워킹그룹은 개별 태스크를 완료하기 위해 사람들을 조직하는 방법이며, 새로 만들거나 비활성화될 때 해산하는 것이 비교적 용이하다. 자세히 내용은 kubernetes/community 저장소와 SIG 및 워킹그룹의 현재 목록을 참고하라.

4 같이 보기

• 쿠버네티스
• 도커 용어

5 참고

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