레이블은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이다. 레이블은 오브젝트의 특성을 식별하는 데 사용되어 사용자에게 중요하지만, 코어 시스템에 직접적인 의미는 없다. 레이블로 오브젝트의 하위 집합을 선택하고, 구성하는데 사용할 수 있다. 레이블은 오브젝트를 생성할 때에 붙이거나 생성 이후에 붙이거나 언제든지 수정이 가능하다. 오브젝트마다 키와 값으로 레이블을 정의할 수 있다. 오브젝트의 키는 고유한 값이어야 한다.

"metadata": {
  "labels": {
    "key1" : "value1",
    "key2" : "value2"
  }
}

레이블은 UI 와 CLI 에서 효율적인 쿼리를 사용하고 검색에 사용하기에 적합하다. 식별되지 않는 정보는 어노테이션으로 기록해야 한다.

사용 동기

레이블을 이용하면 사용자가 느슨하게 결합한 방식으로 조직 구조와 시스템 오브젝트를 매핑할 수 있으며, 클라이언트에 매핑 정보를 저장할 필요가 없다.

서비스 배포와 배치 프로세싱 파이프라인은 흔히 다차원의 엔티티들이다(예: 다중 파티션 또는 배포, 다중 릴리스 트랙, 다중 계층, 계층 속 여러 마이크로 서비스들). 관리에는 크로스-커팅 작업이 필요한 경우가 많은데 이 작업은 사용자보다는 인프라에 의해 결정된 엄격한 계층 표현인 캡슐화를 깨트린다.

레이블 예시:

  • "release" : "stable", "release" : "canary"
  • "environment" : "dev", "environment" : "qa", "environment" : "production"
  • "tier" : "frontend", "tier" : "backend", "tier" : "cache"
  • "partition" : "customerA", "partition" : "customerB"
  • "track" : "daily", "track" : "weekly"

이 예시는 일반적으로 사용하는 레이블이며, 사용자는 자신만의 규칙(convention)에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다.

구문과 캐릭터 셋

레이블은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시(/)로 구분되는 선택한 접두사와 이름이라는 2개의 세그먼트가 있다. 이름 세그먼트는 63자 미만으로 시작과 끝은 알파벳과 숫자([a-z0-9A-Z])이며, 대시(-), 밑줄(_), 점(.)과 함께 사용할 수 있다. 접두사는 선택이다. 만약 접두사를 지정한 경우 접두사는 DNS의 하위 도메인으로 해야 하며, 점(.)과 전체 253자 이하, 슬래시(/)로 구분되는 DNS 레이블이다.

접두사를 생략하면 키 레이블은 개인용으로 간주한다. 최종 사용자의 오브젝트에 자동화된 시스템 컴포넌트(예: kube-scheduler, kube-controller-manager, kube-apiserver, kubectl 또는 다른 타사의 자동화 구성 요소)의 접두사를 지정해야 한다.

kubernetes.io/와 k8s.io/ 접두사는 쿠버네티스의 핵심 컴포넌트로 예약되어 있다.

유효한 레이블 값은 다음과 같다.

  • 63 자 이하여야 하고 (공백일 수도 있음),
  • (공백이 아니라면) 시작과 끝은 알파벳과 숫자([a-z0-9A-Z])이며,
  • 알파벳과 숫자, 대시(-), 밑줄(_), 점(.)을 중간에 포함할 수 있다.

다음의 예시는 파드에 environment: production  app: nginx 2개의 레이블이 있는 구성 파일이다.


apiVersion: v1
kind: Pod
metadata:
  name: label-demo
  labels:
    environment: production
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

레이블 셀렉터

이름과 UID 와 다르게 레이블은 고유하지 않다. 일반적으로 우리는 많은 오브젝트에 같은 레이블을 가질 것으로 예상한다.

레이블 셀렉터를 통해 클라이언트와 사용자는 오브젝트를 식별할 수 있다. 레이블 셀렉터는 쿠버네티스 코어 그룹의 기본이다.

API 는 현재 일치성 기준  집합성 기준 이라는 두 종류의 셀렉터를 지원한다. 레이블 셀렉터는 쉼표로 구분된 다양한 요구사항에 따라 만들 수 있다. 다양한 요구사항이 있는 경우 쉼표 기호가 AND(&&) 연산자로 구분되는 역할을 하도록 해야 한다.

비어있거나 지정되지 않은 셀렉터는 상황에 따라 달라진다. 셀렉터를 사용하는 API 유형은 유효성과 의미를 문서화해야 한다.

참고: 레플리카셋(ReplicaSet)과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충하는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다.
주의: 일치성 기준과 집합성 기준 조건 모두에 대해 논리적인 OR (||) 연산자가 없다. 필터 구문이 적절히 구성되어 있는지 확인해야 한다.

일치성 기준 요건

일치성 기준 또는 불일치 기준 의 요구사항으로 레이블의 키와 값의 필터링을 허용한다. 일치하는 오브젝트는 추가 레이블을 가질 수 있지만, 레이블의 명시된 제약 조건을 모두 만족해야 한다. =,==,!= 이 세 가지 연산자만 허용한다. 처음 두 개의 연산자의 일치성(그리고 동의어), 나머지는 불일치 를 의미한다. 예를 들면,

environment = production
tier != frontend

전자는 environment 를 키로 가지는 것과 production 을 값으로 가지는 모든 리소스를 선택한다. 후자는 tier 를 키로 가지고, 값을 frontend 를 가지는 리소스를 제외한 모든 리소스를 선택하고, tier 를 키로 가지며 값을 공백으로 가지는 모든 리소스를 선택한다. environment=production,tier!=frontend 처럼 쉼표를 통해 한 문장으로 frontend 를 제외한 production 을 필터링할 수 있다.

일치성 기준 레이블 요건에 대한 하나의 이용 시나리오는 파드가 노드를 선택하는 기준을 지정하는 것이다. 예를 들어, 아래 샘플 파드는 "accelerator=nvidia-tesla-p100" 레이블을 가진 노드를 선택한다.

apiVersion: v1
kind: Pod
metadata:
  name: cuda-test
spec:
  containers:
    - name: cuda-test
      image: "k8s.gcr.io/cuda-vector-add:v0.1"
      resources:
        limits:
          nvidia.com/gpu: 1
  nodeSelector:
    accelerator: nvidia-tesla-p100

집합성 기준 요건

집합성 기준 레이블 요건에 따라 값 집합을 키로 필터링할 수 있다. in, notin과 exists(키 식별자만 해당)의 3개의 연산자를 지원한다. 예를 들면,

environment in (production, qa)
tier notin (frontend, backend)
partition
!partition
  • (in) 첫 번째 예시에서 키가 environment이고 값이 production 또는 qa 인 모든 리소스를 선택한다.
  • (notion) 두 번째 예시에서 키가 tier 이고 값이 frontend 와 backend 를 가지는 리소스를 제외한 모든 리소스와 키로 tier 를 가지고 값을 공백으로 가지는 모든 리소스를 선택한다.
  • (exists) 세 번째 예시에서 레이블의 값에 상관없이 키가 partition 을 포함하는 모든 리소스를 선택한다.
  • (non-exists) 네 번째 예시에서 레이블의 값에 상관없이 키가 partition 을 포함하지 않는 모든 리소스를 선택한다.

마찬가지로 쉼표는 AND 연산자로 작동한다. 따라서 partition,environment notin (qa)와 같이 사용하면 값과 상관없이 키가 partition인 것과 키가 environment이고 값이 qa와 다른 리소스를 필터링할 수 있다. 집합성 기준 레이블 셀렉터는 일반적으로 environment=production과 environment in (production)을 같은 것으로 본다. 유사하게는 !=과 notin을 같은 것으로 본다.

집합성 기준 요건은 일치성 기준 요건과 조합해서 사용할 수 있다. 예를 들어 partition in (customerA, customerB),environment!=qa 가 있다.

API

LIST와 WATCH 필터링

LIST와 WATCH 작업은 쿼리 파라미터를 사용해서 반환되는 오브젝트 집합을 필터링하기 위해 레이블 셀렉터를 지정할 수 있다. 다음의 두 가지 요건 모두 허용된다(URL 쿼리 문자열을 그대로 표기함).

  • 일치성 기준 요건: ?labelSelector=environment%3Dproduction,tier%3Dfrontend
  • 집합성 기준 요건: ?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29

두 가지 레이블 셀렉터 스타일은 모두 REST 클라이언트를 통해 선택된 리소스를 확인하거나 목록을 볼 수 있다. 예를 들어, kubectl로 apiserver 를 대상으로 일치성 기준 으로 하는 셀렉터를 다음과 같이 이용할 수 있다.

kubectl get pods -l environment=production,tier=frontend

또는 집합성 기준 요건을 사용하면

kubectl get pods -l 'environment in (production),tier in (frontend)'

앞서 안내한 것처럼 집합성 기준 요건은 더 보여준다. 예시에서 다음과 같이 OR 연산자를 구현할 수 있다.

kubectl get pods -l 'environment in (production, qa)'

또는 exists 연산자에 불일치한 것으로 제한할 수 있다.

kubectl get pods -l 'environment,environment notin (frontend)'

API 오브젝트에서 참조 설정

services  replicationcontrollers 와 같은 일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 파드와 같은 다른 리소스 집합을 선택한다.

서비스와 레플리케이션 컨트롤러

services 에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 replicationcontrollers 가 관리하는 파드의 오브젝트 그룹도 레이블 셀렉터로 정의한다.

서비스와 레플리케이션 컨트롤러의 레이블 셀렉터는 json 또는 yaml 파일에 매핑된 일치성 기준 요구사항의 셀렉터만 지원한다.

"selector": {
    "component" : "redis",
}

or

selector:
    component: redis

json 또는 yaml 서식에서 셀렉터는 component=redis 또는 component in (redis) 모두 같은 것이다.

세트-기반 요건을 지원하는 리소스

Job, Deployment, ReplicaSet 그리고 DaemonSet 같은 새로운 리소스들은 집합성 기준 의 요건도 지원한다.

selector:
  matchLabels:
    component: redis
  matchExpressions:
    - {key: tier, operator: In, values: [cache]}
    - {key: environment, operator: NotIn, values: [dev]}

matchLabels 는 {key,value} 의 쌍과 매칭된다. matchLabels 에 매칭된 단일 {key,value} 는 matchExpressions의 요소와 같으며 key 필드는 "key"로, operator는 "In" 그리고 values에는 "value"만 나열되어 있다. matchExpressions 는 파드 셀렉터의 요건 목록이다. 유효한 연산자에는 In, NotIn, Exists 및 DoNotExist 가 포함된다. In 및 NotIn 은 설정된 값이 있어야 한다. matchLabels와 matchExpressions 모두 AND로 되어 있어 일치하기 위해서는 모든 요건을 만족해야 한다.

노드 셋 선택

레이블을 통해 선택하는 사용 사례 중 하나는 파드를 스케줄 할 수 있는 노드 셋을 제한하는 것이다. 자세한 내용은 노드 선택 문서를 참조한다.

'플랫폼 > kubernetes' 카테고리의 다른 글

쿠버네티스 필드 셀렉터  (0) 2022.07.13
쿠버네티스 어노테이션  (0) 2022.07.13
쿠버네티스 네임스페이스  (0) 2022.07.12
쿠버네티스 오브젝트 이름, ID  (0) 2022.07.12
쿠버네티스 오브젝트 관리  (0) 2022.07.12

쿠버네티스에서 네임스페이스는 단일 클러스터 내에서의 리소스를 네임스페이스라는 그룹 단위로 격리하여 관리할 수 있는 메커니즘을 제공한다. 리소스의 이름은 네임스페이스 내에서 유일해야 하지만, 네임스페이스 간에서 유일할 필요는 없다. 네임스페이스 기반 스코핑은 네임스페이스 기반 오브젝트 (예: 디플로이먼트, 서비스 등) 에만 적용 가능하며 클러스터 범위의 오브젝트 (예: 스토리지클래스, 노드, 퍼시스턴트볼륨 등) 에는 적용 불가능하다.

여러 개의 네임스페이스를 사용하는 경우

네임스페이스는 여러 개의 팀이나, 프로젝트에 걸쳐서 많은 사용자가 있는 환경에서 사용하도록 만들어졌다. 사용자가 거의 없거나, 수 십명 정도가 되는 경우에는 네임스페이스를 전혀 고려할 필요가 없다. 네임스페이스가 제공하는 기능이 필요할 때 사용하도록 하자.

네임스페이스는 이름 단위의 범위를 제공한다. 리소스의 이름은 네임스페이스 내에서 유일해야하지만, 네임스페이스를 통틀어서 유일할 필요는 없다. 네임스페이스는 서로 중첩될 수 없으며, 각 쿠버네티스 리소스는 하나의 네임스페이스에만 있을 수 있다.

네임스페이스는 클러스터 자원을 (리소스 쿼터를 통해) 여러 사용자 사이에서 나누는 방법이다.

동일한 소프트웨어의 다른 버전과 같이 약간 다른 리소스를 분리하기 위해 여러 네임스페이스를 사용할 필요는 없다. 동일한 네임스페이스 내에서 리소스를 구별하기 위해서는 레이블을 사용한다.

네임스페이스 다루기

네임스페이스의 생성과 삭제는 네임스페이스 관리자 가이드 문서에 기술되어 있다.

참고: kube- 접두사로 시작하는 네임스페이스는 쿠버네티스 시스템용으로 예약되어 있으므로, 사용자는 이러한 네임스페이스를 생성하지 않는다.

네임스페이스 조회

사용 중인 클러스터의 현재 네임스페이스를 나열할 수 있다.

kubectl get namespace
NAME              STATUS   AGE
default           Active   1d
kube-node-lease   Active   1d
kube-public       Active   1d
kube-system       Active   1d

쿠버네티스는 처음에 네 개의 초기 네임스페이스를 갖는다.

  • default: 다른 네임스페이스가 없는 오브젝트를 위한 기본 네임스페이스
  • kube-system: 쿠버네티스 시스템에서 생성한 오브젝트를 위한 네임스페이스
  • kube-public: 이 네임스페이스는 자동으로 생성되며 모든 사용자(인증되지 않은 사용자 포함)가 읽기 권한으로 접근할 수 있다. 이 네임스페이스는 주로 전체 클러스터 중에 공개적으로 드러나서 읽을 수 있는 리소스를 위해 예약되어 있다. 이 네임스페이스의 공개적인 성격은 단지 관례이지 요구 사항은 아니다.
  • kube-node-lease: 이 네임스페이스는 각 노드와 연관된 리스 오브젝트를 갖는다. 노드 리스는 kubelet 이 하트비트를 보내서 컨트롤 플레인이 노드의 장애를 탐지할 수 있게 한다.

요청에 네임스페이스 설정하기

현재 요청에 대한 네임스페이스를 설정하기 위해서 --namespace 플래그를 사용한다.

예를 들면,

kubectl run nginx --image=nginx --namespace=<insert-namespace-name-here>
kubectl get pods --namespace=<insert-namespace-name-here>

선호하는 네임스페이스 설정하기

이후 모든 kubectl 명령에서 사용하는 네임스페이스를 컨텍스트에 영구적으로 저장할 수 있다.

kubectl config set-context --current --namespace=<insert-namespace-name-here>
# 확인하기
kubectl config view --minify | grep namespace:

네임스페이스와 DNS

서비스를 생성하면 해당 DNS 엔트리가 생성된다. 이 엔트리는 <서비스-이름>.<네임스페이스-이름>.svc.cluster.local의 형식을 갖는데, 이는 컨테이너가 <서비스-이름>만 사용하는 경우, 네임스페이스 내에 국한된 서비스로 연결된다. 개발, 스테이징, 운영과 같이 여러 네임스페이스 내에서 동일한 설정을 사용하는 경우에 유용하다. 네임스페이스를 넘어서 접근하기 위해서는, 전체 주소 도메인 이름(FQDN)을 사용해야 한다.

그렇기 때문에, 모든 네임스페이스 이름은 유효한 RFC 1123 DNS 레이블이어야 한다.

경고:

네임스페이스의 이름을 공개 최상위 도메인 중 하나와 동일하게 만들면, 해당 네임스페이스 내의 서비스의 짧은 DNS 이름이 공개 DNS 레코드와 겹칠 수 있다. 어떠한 네임스페이스 내의 워크로드가 접미점(trailing dot) 없이 DNS 룩업을 수행하면 공개 DNS 레코드보다 우선하여 해당 서비스로 리다이렉트될 것이다.

이를 방지하기 위해, 신뢰하는 사용자만 네임스페이스를 생성할 수 있도록 권한을 제한한다. 필요한 경우, 추가적으로 써드파티 보안 컨트롤을 구성할 수 있으며, 예를 들어 어드미션 웹훅을 이용하여 공개 TLD와 동일한 이름의 네임스페이스 생성을 금지시킬 수 있다.

모든 오브젝트가 네임스페이스에 속하지는 않음

대부분의 쿠버네티스 리소스(예를 들어, 파드, 서비스, 레플리케이션 컨트롤러 외)는 네임스페이스에 속한다. 하지만 네임스페이스 리소스 자체는 네임스페이스에 속하지 않는다. 그리고 노드나 퍼시스턴트 볼륨과 같은 저수준 리소스는 어느 네임스페이스에도 속하지 않는다.

다음은 네임스페이스에 속하지 않는 쿠버네티스 리소스를 조회하는 방법이다.

# 네임스페이스에 속하는 리소스
kubectl api-resources --namespaced=true

# 네임스페이스에 속하지 않는 리소스
kubectl api-resources --namespaced=false

자동 레이블링

기능 상태: Kubernetes 1.21 [beta]

쿠버네티스 컨트롤 플레인은 NamespaceDefaultLabelName 기능 게이트가 활성화된 경우 모든 네임스페이스에 변경할 수 없는(immutable) 레이블 kubernetes.io / metadata.name 을 설정한다. 레이블 값은 네임스페이스 이름이다.

'플랫폼 > kubernetes' 카테고리의 다른 글

쿠버네티스 어노테이션  (0) 2022.07.13
쿠버네티스 레이블, 셀렉터  (0) 2022.07.12
쿠버네티스 오브젝트 이름, ID  (0) 2022.07.12
쿠버네티스 오브젝트 관리  (0) 2022.07.12
쿠버네티스 오브젝트란?  (0) 2022.07.12

클러스터의 각 오브젝트는 해당 유형의 리소스에 대하여 고유한 이름을 가지고, 모든 쿠버네티스 오브젝트는 전체 클러스터에 걸쳐 고유한 UID 를 가진다.

예를 들어, 이름이 myapp-1234인 파드는 동일한 네임스페이스 내에서 하나만 존재할 수 있지만, 이름이 myapp-1234인 파드와 디플로이먼트는 각각 존재할 수 있다.

유일하지 않은 사용자 제공 속성의 경우 쿠버네티스는 레이블과 어노테이션을 제공한다.

이름

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

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

참고: 물리적 호스트를 나타내는 노드와 같이 오브젝트가 물리적 엔티티를 나타내는 경우, 노드를 삭제한 후 다시 생성하지 않은 채 동일한 이름으로 호스트를 다시 생성하면, 쿠버네티스는 새 호스트를 불일치로 이어질 수 있는 이전 호스트로 취급한다.

다음은 리소스에 일반적으로 사용되는 네 가지 유형의 이름 제한 조건이다.

DNS 서브도메인 이름

대부분의 리소스 유형에는 RFC 1123에 정의된 대로 DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다. 이것은 이름이 다음을 충족해야 한다는 것을 의미한다.

  • 253자를 넘지 말아야 한다.
  • 소문자와 영숫자 - 또는 . 만 포함한다.
  • 영숫자로 시작한다.
  • 영숫자로 끝난다.

RFC 1123 레이블 이름

일부 리소스 유형은 RFC 1123에 정의된 대로 DNS 레이블 표준을 따라야 한다. 이것은 이름이 다음을 충족해야 한다는 것을 의미한다.

  • 최대 63자이다.
  • 소문자와 영숫자 또는 - 만 포함한다.
  • 영숫자로 시작한다.
  • 영숫자로 끝난다.

RFC 1035 레이블 이름

몇몇 리소스 타입은 자신의 이름을 RFC 1035에 정의된 DNS 레이블 표준을 따르도록 요구한다. 이것은 이름이 다음을 만족해야 한다는 의미이다.

  • 최대 63개 문자를 포함
  • 소문자 영숫자 또는 '-'만 포함
  • 알파벳 문자로 시작
  • 영숫자로 끝남

경로 세그먼트 이름

일부 리소스 유형에서는 이름을 경로 세그먼트로 안전하게 인코딩 할 수 있어야 한다. 즉 이름이 "." 또는 ".."이 아닐 수 있으며 이름에는 "/" 또는 "%"가 포함될 수 없다.

아래는 파드의 이름이 nginx-demo라는 매니페스트 예시이다.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-demo
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80
참고: 일부 리소스 유형은 이름에 추가적인 제약이 있다.

UID

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

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

쿠버네티스 UID 는 보편적으로 고유한 식별자이다(또는 UUID 라고 한다). UUID 는 ISO/IEC 9834-8 과 ITU-T X.667 로 표준화 되어 있다.

'플랫폼 > kubernetes' 카테고리의 다른 글

쿠버네티스 레이블, 셀렉터  (0) 2022.07.12
쿠버네티스 네임스페이스  (0) 2022.07.12
쿠버네티스 오브젝트 관리  (0) 2022.07.12
쿠버네티스 오브젝트란?  (0) 2022.07.12
쿠버네티스 API  (0) 2022.07.11

kubectl cli 는 쿠버네티스 오브젝트를 생성하고 관리하기 위한 몇 가지 상이한 방법을 지원한다. 

관리 기법

경고: 쿠버네티스 오브젝트는 하나의 기법만 사용하여 관리해야 한다. 동일한 오브젝트에 대해 여러 기법을 혼용하는 것은 예상치 못한 동작을 초래하게 된다.

관리 기법 별 특징

기법 동작 방법 권장 환경 지원하는 작업자 수 난이도
명령형 커맨드 활성 오브젝트 개발 환경 1+ 낮음
명령형(imperative) 오브젝트 구성 개별 파일 프로덕션 환경 1 보통
선언형(declarative) 오브젝트 구성 파일이 있는 디렉터리 프로덕션 환경 1+ 높음

명령형 커맨드

명령형 커맨드를 사용할 경우, 사용자는 클러스터 내 활성 오브젝트를 대상으로 직접 동작시키는 것으로 실행할 작업을 파라미터 또는 플래그로 kubectl cli 에 지정한다.

이것은 클러스터에서 일회성 작업을 개시시키거나 동작시키기 위한 추천 방법이다. 이 기법은 활성 오브젝트를 대상으로 직접적인 영향을 미치기 때문에, 이전 구성에 대한 이력을 제공해 주지 않는다.

예시

디플로이먼트 오브젝트를 생성하여 nginx 컨테이너의 인스턴스를 구동시킨다.

kubectl create deployment nginx --image nginx

장단점

오브젝트 구성에 비해 장점은 다음과 같다.

  • 커맨드는 하나의 동작을 나타내는 단어로 표현된다.
  • 커맨드는 클러스터를 수정하기 위해 단 하나의 단계만을 필요로 한다.

오브젝트 구성에 비해 단점은 다음과 같다.

  • 커맨드는 변경 검토 프로세스와 통합되지 않는다.
  • 커맨드는 변경에 관한 감사 추적(audit trail)을 제공하지 않는다.
  • 커맨드는 활성 동작 중인 경우를 제외하고는 레코드의 소스를 제공하지 않는다.
  • 커맨드는 새로운 오브젝트 생성을 위한 템플릿을 제공하지 않는다.

명령형 오브젝트 구성

명령형 오브젝트 구성에서는 kubectl cli 로 작업(생성, 교체 등), 선택적 플래그, 그리고 최소 하나의 파일 이름을 지정한다. 그 파일은 YAML 또는 JSON 형식으로 오브젝트의 완전한 정의를 포함해야만 한다.

경고: 명령형 replace 커맨드는 기존 spec 을 새로 제공된 spec 으로 바꾸고 구성 파일에서 누락된 오브젝트의 모든 변경 사항을 삭제한다. 이 방법은 spec 이 구성 파일과는 별개로 업데이트되는 리소스 유형에는 사용하지 말아야한다. 예를 들어 LoadBalancer 유형의 서비스는 클러스터의 구성과 별도로 externalIPs 필드가 업데이트된다.

예시

구성 파일에 정의된 오브젝트를 생성한다.

kubectl create -f nginx.yaml

두 개의 구성 파일에 정의된 오브젝트를 삭제한다.

kubectl delete -f nginx.yaml -f redis.yaml

활성 동작하는 구성을 덮어씀으로써 구성 파일에 정의된 오브젝트를 업데이트한다.

kubectl replace -f nginx.yaml

장단점

명령형 커맨드에 비해 장점은 다음과 같다.

  • 오브젝트 구성은 Git과 같은 소스 컨트롤 시스템에 보관할 수 있다.
  • 오브젝트 구성은 푸시와 감사 추적 전에 변경사항을 검토하는 것과 같은 프로세스들과 통합할 수 있다.
  • 오브젝트 구성은 새로운 오브젝트 생성을 위한 템플릿을 제공한다.

명령형 커맨드에 비해 단점은 다음과 같다.

  • 오브젝트 구성은 오브젝트 스키마에 대한 기본적인 이해를 필요로 한다.
  • 오브젝트 구성은 YAML 파일을 기록하는 추가적인 과정을 필요로 한다.

선언형 오브젝트 구성에 비해 장점은 다음과 같다.

  • 명령형 오브젝트 구성의 동작은 보다 간결하고 이해하기 쉽다.
  • 쿠버네티스 버전 1.5 부터는 더 성숙한 명령형 오브젝트 구성을 제공한다.

선언형 오브젝트 구성에 비해 단점은 다음과 같다.

  • 명령형 오브젝트 구성은 디렉터리가 아닌, 파일에 가장 적합하다.
  • 활성 오브젝트에 대한 업데이트는 구성 파일에 반영되어야 한다. 그렇지 않으면 다음 교체 중에 손실된다.

선언형 오브젝트 구성

선언형 오브젝트 구성을 사용할 경우, 사용자는 로컬에 보관된 오브젝트 구성 파일을 대상으로 작동시키지만, 사용자는 파일에서 수행 할 작업을 정의하지 않는다. 생성, 업데이트, 그리고 삭제 작업은 kubectl cli 에 의해 오브젝트마다 자동으로 감지된다. 이를 통해 다른 오브젝트에 대해 다른 조작이 필요할 수 있는 디렉터리에서 작업할 수 있다.

참고: 선언형 오브젝트 구성은 변경 사항이 오브젝트 구성 파일에 다시 병합되지 않더라도 다른 작성자가 작성한 변경 사항을 유지한다. 이것은 전체 오브젝트 구성 변경을 위한 replace API 를 사용하는 대신, patch API 를 사용하여 인지되는 차이만 작성하기 때문에 가능하다.

예시

configs 디렉터리 내 모든 오브젝트 구성 파일을 처리하고 활성 오브젝트를 생성 또는 패치한다. 먼저 어떠한 변경이 이루어지게 될지 알아보기 위해 diff 하고 나서 적용할 수 있다.

kubectl diff -f configs/
kubectl apply -f configs/

재귀적으로 디렉터리를 처리한다.

kubectl diff -R -f configs/
kubectl apply -R -f configs/

장단점

명령형 오브젝트 구성에 비해 장점은 다음과 같다.

  • 활성 오브젝트에 직접 작성된 변경 사항은 구성 파일로 다시 병합되지 않더라도 유지된다.
  • 선언형 오브젝트 구성은 디렉터리에서의 작업 및 오브젝트 별 작업 유형(생성, 패치, 삭제)의 자동 감지에 더 나은 지원을 제공한다.

명령형 오브젝트 구성에 비해 단점은 다음과 같다.

  • 선언형 오브젝트 구성은 예상치 못한 결과를 디버깅하고 이해하기가 더 어렵다.
  • diff를 사용한 부분 업데이트는 복잡한 병합 및 패치 작업을 일으킨다.

'플랫폼 > kubernetes' 카테고리의 다른 글

쿠버네티스 네임스페이스  (0) 2022.07.12
쿠버네티스 오브젝트 이름, ID  (0) 2022.07.12
쿠버네티스 오브젝트란?  (0) 2022.07.12
쿠버네티스 API  (0) 2022.07.11
쿠버네티스 클러스터 구성요소  (0) 2022.07.11

쿠버네티스 오브젝트는 쿠버네티스 시스템에서 영속성을 가지는 오브젝트로, 클러스터의 상태(state)를 나타내기 위해 사용한다. 클러스터의 상태는 아래와 같이 나열할 수 있다.

  • 어느 노드에서 어떤 컨테이너화된 애플리케이션이 동작 중인지
  • 그 애플리케이션이 이용할 수 있는 리소스의 정보
  • 그 애플리케이션이 어떻게 재구동, 업그레이드, 내고장성(fault-tolerance)과 같은 것에 동작해야 하는지에 대한 정책

쿠버네티스 오브젝트는 하나의 "의도(intent)를 담은 레코드"이다. 오브젝트를 생성하게 되면, 쿠버네티스 시스템은 그 오브젝트 생성을 보장하기 위해 지속적으로 작동하고, 사용자가 클러스터의 워크로드를 어떤 형태로 보이고자 하는지에 대해 효과적으로 쿠버네티스 시스템에 전달하는 이것이 바로 여러분의 클러스터에 대해 의도한 상태(desired state)가 된다.

생성이든, 수정이든, 삭제든 쿠버네티스 오브젝트를 동작시키려면, 쿠버네티스 API 를 이용해야 한다. 예를 들어, kubectl cli 를 이용할 때, cli 는 여러분 대신 필요한 쿠버네티스 API 를 호출해 준다. 또한, 클라이언트 라이브러리 중 하나를 이용하여 프로그램에서 쿠버네티스 API 를 직접 이용할 수도 있다.

오브젝트 명세(spec)와 상태(status)

대부분의 쿠버네티스 오브젝트는 오브젝트의 구성을 결정해주는 두 개의 중첩된 오브젝트 필드 object spec 과 object status 을 포함한다. 

spec 은 오브젝트를 생성할 때 리소스에 원하는 특징(desired state)에 대한 설명을 작성하여 설정한다.

status 는 쿠버네티스 시스템과 컴포넌트에 의해 제공되고 업데이트된 오브젝트의 현재 상태(current state)를 제공한다. 쿠버네티스 컨트롤 플레인은 모든 오브젝트의 실제 상태를 사용자가 의도한 상태와 일치시키기 위해 끊임없이 능동적으로 관리한다.

예를 들어, 쿠버네티스 디플로이먼트는 클러스터에서 동작하는 애플리케이션을 표현해줄 수 있는 오브젝트이다. 디플로이먼트를 생성할 때, 디플로이먼트 spec 에 3개의 애플리케이션 레플리카가 동작되도록 설정할 수 있다. 쿠버네티스 시스템은 그 디플로이먼트 spec 을 읽어 spec 에 일치되도록 상태를 업데이트하여 3개의 의도한 애플리케이션 인스턴스를 구동시킨다. 만약, 그 인스턴스들 중 어느 하나가 어떤 문제로 인해 멈춘다면(상태 변화 발생), 쿠버네티스 시스템은 보정(이 경우에는 대체 인스턴스를 시작하여)을 통해 spec 과 status 간의 차이에 매꾸려고 노력한다.

쿠버네티스 오브젝트 작성하기

쿠버네티스에서 오브젝트를 생성할 때, 이름과 같은 오브젝트에 대한 기본적인 정보와 더불어 의도한 상태를 기술한 오브젝트 spec 을 작성해야만 한다. 오브젝트를 생성하기 위해(직접이든 또는 kubectl cli 를 통해서든) 쿠버네티스 API 를 이용할 때, API 요청은 요청 내용 안에 JSON 형식으로 정보를 포함시켜 줘야만 한다. 대부분의 경우 정보를 .yaml 파일로 kubectl 에 제공한다. kubectl cli 는 API 요청이 이루어질 때, .yaml 파일을 JSON 형식으로 정보를 변환시켜 준다.

여기 쿠버네티스 디플로이먼트를 위한 필수 필드와 오브젝트 spec 을 보여주는 .yaml 파일 예시는 아래와 같다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # tells deployment to run 2 pods matching the template
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

위 예시와 같이 .yaml 파일을 이용하여 디플로이먼트를 생성하기 위한 하나의 방식으로는 kubectl cli 에 인자값으로 .yaml 파일을 건네 kubectl apply 커맨드를 이용한다.

kubectl apply -f https://k8s.io/examples/application/deployment.yaml

수행 결과는 아래와 같다.

deployment.apps/nginx-deployment created

필수 속성

생성하고자 하는 쿠버네티스 오브젝트에 대한 .yaml 파일 내에는 다음 필드를 위한 값들을 설정해 줘야한다.

  • apiVersion: 이 오브젝트를 생성하기 위해 사용하고 있는 쿠버네티스 API 버전이 어떤 것인지
  • kind: 어떤 종류의 오브젝트를 생성하고자 하는지
  • metadata: 이름 문자열, UID, 그리고 선택적인 네임스페이스를 포함하여 오브젝트를 유일하게 구분지어 줄 데이터
  • spec: 오브젝트에 대해 어떤 상태를 의도하는지

오브젝트 spec 에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. 쿠버네티스 API 레퍼런스에 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 제공한다.

예를 들어, 파드(pod) API 레퍼런스를 보려면 spec 필드를 참조한다. 각 파드에 대해 .spec 필드는 파드 및 파드의 원하는 상태(desired state)를 기술한다(예: 파드의 각 컨테이너에 대한 컨테이너 이미지). 오브젝트 상세에 대한 또 다른 예시는 스테이트풀셋 API의 spec 필드이다. 스테이트풀셋의 경우, .spec 필드는 스테이트풀셋 및 스테이트풀셋의 원하는 상태(desired state)를 기술한다. 스테이트풀셋의 .spec에는 파드 오브젝트에 대한 템플릿이 존재한다. 이 템플릿은 스테이트풀셋 명세를 만족시키기 위해 스테이트풀셋 컨트롤러가 생성할 파드에 대한 상세 사항을 설명한다. 서로 다른 종류의 오브젝트는 서로 다른 .status를 가질 수 있다. 

'플랫폼 > kubernetes' 카테고리의 다른 글

쿠버네티스 오브젝트 이름, ID  (0) 2022.07.12
쿠버네티스 오브젝트 관리  (0) 2022.07.12
쿠버네티스 API  (0) 2022.07.11
쿠버네티스 클러스터 구성요소  (0) 2022.07.11
쿠버네티스란?  (0) 2022.07.11

+ Recent posts