기본 배치 메타데이터

배치하는 Kubernetes 오브젝트 유형에 대해 적절한 API 버전을 사용하십시오. API 버전은 사용자가 사용할 수 있는 Kubernetes 오브젝트에 대해 지원되는 기능을 결정합니다. 메타데이터에 지정하는 이름은 해당 레이블이 아니라 오브젝트의 이름입니다. 오브젝트와 상호작용할 때 이 이름을 사용합니다(예: kubectl get deployment <name>).

apiVersion: apps/v1
kind: Deployment
metadata:
  name: wasliberty

복제본 세트

앱의 가용성을 높이기 위해 배치에 복제본 세트를 지정할 수 있습니다. 복제본 세트에는 배치할 앱 인스턴스 수를 정의합니다. 복제본 세트는 Kubernetes 배치에 의해 관리되고 모니터링됩니다. 하나의 앱 인스턴스가 작동 중지 상태가 되면 Kubernetes는 자동으로 앱의 새 인스턴스를 스핀업하여 지정된 앱 인스턴스 수를 유지합니다.

spec:
  replicas: 3

Labels

레이블을 사용하면 클러스터에 있는 서로 다른 유형의 리소스를 동일한 key: value 쌍으로 표시할 수 있습니다. 그 후에는 해당하는 다른 리소스에 빌드할 수 있도록 하기 위해 레이블을 비교하도록 선택기를 지정할 수 있습니다. 앱을 외부에 노출하려는 경우에는 서비스에 지정하는 선택기와 일치하는 레이블을 사용해야 합니다. 이 예에서 배치 스펙은 다음 레이블과 일치하는 템플리트를 사용합니다. app: wasliberty.

예를 들어, staging 또는 production 컴포넌트를 보기 위해 클러스터에서 레이블 지정된 오브젝트를 검색할 수 있습니다. 예를 들면, 클러스터에 있는 모든 네임스페이스에서 env: production 레이블이 있는 모든 리소스를 나열하는 경우 있습니다. 참고: 이 명령을 실행하려면 모든 네임스페이스에 대한 액세스 권한이 필요합니다.

kubectl get all -l env=production --all-namespaces

• 라벨에 대한 자세한 내용은 ‘ Kubernetes ’ 문서를 참조하십시오.
• 작업자 노드에 레이블을 적용하십시오.
• 더 자세한 예는 레이블을 사용하여 특정 작업자 노드에 앱 배치를 참조하십시오.

selector:
  matchLabels:
    app: wasliberty
template:
  metadata:
    labels:
      app: wasliberty

선호도

포드가 어떤 워커 노드에 스케줄링될지 더 세밀하게 제어하고 싶을 때는 어피니티(동일 노드 배치)를 지정하십시오. 친화성은 스케줄 시에만 팟(Pod)에 영향을 줍니다. 예를 들어, 팟(Pod)이 동일한 노드에 스케줄될 수 있도록 하지 않고 작업자 노드 간에 배치를 분산시키려는 경우에는 표준 클러스터에 podAntiAffinity 옵션을 사용하십시오. 팟(Pod) 반친화성에는 선호 및 필수의 두 가지 유형이 있습니다.

자세한 내용은 Kubernetes 의 ‘노드에 파드 할당’ 문서를 참조하십시오.

필수 비유사성

작업자 노드가 있는 복제본 수만 배치할 수 있습니다. 예를 들어, 클러스터에 세 개의 작업자 노드가 있으나 YAML 파일에 다섯 개의 복제본을 정의하는 경우에는 세 개의 복제본만 배치됩니다. 각 복제본은 서로 다른 작업자 노드에 상주합니다. 남은 두 개의 복제본은 보류 상태로 유지됩니다. 클러스터에 다른 작업자 노드를 추가하면 남은 복제본 중 하나가 자동으로 새 작업자 노드에 배치됩니다. 한 작업자 노드가 실패하는 경우, 친화성 정책이 필요하므로 해당 팟(Pod)은 다시 스케줄되지 않습니다. 필수 조건이 포함된 YAML 예제는 ‘필수 포드 반친화성(anti-affinity)이 적용된 Liberty 앱’을 참조하십시오.

선호 비유사성

사용 가능한 용량으로 노드에 팟(Pod)을 배치할 수 있으며, 이렇게 하면 워크로드의 유연성이 향상됩니다. 가능한 경우 팟(Pod)은 서로 다른 작업자 노드에 스케줄됩니다. 예를 들어, 클러스터에 용량이 충분한 세 개의 작업자 노드가 있는 경우에는 노드 전체에 다섯 개의 복제본 팟(Pod)을 스케줄할 수 있습니다. 그러나 클러스터에 워커 노드를 두 개 더 추가하더라도, 어피니티 규칙은 기존 노드에서 실행 중인 두 개의 추가 포드가 사용 가능한 노드로 재스케줄링되도록 강제하지는 않습니다.

작업자 노드 유사성

베어메탈과 같은 특정 작업자 노드에서만 실행하도록 배치를 구성할 수 있습니다. 자세한 정보는 레이블을 사용하여 특정 작업자 노드에 앱 배치를 참조하십시오.

선호 반친화성의 예

spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - wasliberty
          topologyKey: kubernetes.io/hostname

컨테이너 이미지

컨테이너에 대해 사용할 이미지, 이미지의 위치 및 이미지 가져오기 정책을 지정하십시오. 이미지 태그를 지정하지 않으면 기본적으로 latest로 태그 지정된 이미지를 가져옵니다.

프로덕션 워크로드에 대해서는 latest 태그를 사용하지 마십시오. Docker Hub 또는 IBM Cloud Container Registry와 같은 공용 또는 공유 저장소를 사용하고 있는 경우에는 워크로드를 최신 이미지에 대해 테스트하지 않았을 수 있습니다.

예를 들어, 공용 IBM 이미지의 태그를 나열하려면 다음을 수행하십시오.

1. 글로벌 레지스트리 지역으로 전환하십시오.

   ibmcloud cr region-set global
   

2. IBM 이미지를 나열하십시오.

   ibmcloud cr images --include-ibm
   

기본 imagePullPolicy는 이미지가 로컬에 없는 경우에만 이를 가져오는 IfNotPresent입니다. 컨테이너가 시작할 때마다 이미지를 가져오도록 하려면 imagePullPolicy: Always를 지정하십시오.

containers:
- name: wasliberty
  image: icr.io/ibm/liberty:webProfile8
  imagePullPolicy: Always

앱 서비스의 포트

앱의 서비스를 열 컨테이너 포트를 선택하십시오. 어느 포트를 열어야 하는지 알아보려면 앱 스펙 또는 Dockerfile을 참조하십시오. 이 포트는 사설 네트워크에서 액세스할 수 있지만, 공용 네트워크 연결에서는 액세스할 수 없습니다. 앱을 외부에 노출하려면 NodePort, 로드 밸런서 또는 Ingress 서비스를 사용해야 합니다. Service 오브젝트를 작성하는 경우에 이와 동일한 포트 번호를 사용합니다.

포트 25는 IBM Cloud의 모든 서비스에 대해 차단됩니다.

ports:
- containerPort: 9080

리소스 요청 및 한계

클러스터 관리자는 클러스터 내의 각 Kubernetes 네임스페이스에 대해 ‘ ResourceQuota ’ 객체를 생성함으로써, 클러스터를 공유하는 팀들이 컴퓨팅 리소스(메모리 및 CPU)를 공정한 할당량 이상으로 차지하지 않도록 관리합니다. 클러스터 관리자가 컴퓨팅 리소스 할당량을 설정하는 경우 배치 템플리트 내의 각 컨테이너는 메모리 및 CPU에 대한 리소스 요청 및 한계를 지정해야 하며, 이렇게 하지 않으면 팟(Pod) 작성이 실패합니다.

1. 네임스페이스에 대해 리소스 할당량이 설정되었는지 확인하십시오.

   kubectl get quota --namespace=<namespace>
   

2. 할당량 한계가 얼마인지 확인하십시오.

   kubectl describe quota <quota_name> --namespace=<namespace>
   

리소스 할당량이 설정되지 않은 경우에도, 작업자 노드 리소스 관리 능력을 향상시키기 위해 배치에 리소스 요청 및 한계를 포함시킬 수 있습니다.

컨테이너가 한계를 초과하면 해당 컨테이너가 다시 시작되거나 실패할 수 있습니다. 컨테이너가 요청을 초과하는 경우, 작업자 노드에서 초과된 리소스가 모두 사용되면 해당 팟(Pod)이 제거됩니다. 문제점 해결에 대한 자세한 정보는 팟(Pod) 다시 시작이 계속 실패하거나 팟(Pod)이 예기치 않게 제거됨을 참조하십시오.

요청

컨테이너에서 사용할 수 있도록 스케줄러가 예약하는 최소 리소스 양입니다. 이 양이 한계와 동일한 경우에는 요청이 보장됩니다. 이 양이 한계보다 작은 경우 요청은 여전히 보장되지만, 스케줄러가 다른 컨테이너의 리소스를 만족시키기 위해 요청과 한계의 차이를 사용할 수 있습니다.

한계

컨테이너가 이용할 수 있는 최대 리소스 양입니다. 컨테이너 전체에서 사용되는 리소스의 양이 작업자 노드에서 사용 가능한 양을 초과하는 경우에는 공간을 확보하기 위해 컨테이너가 제거됩니다. 제거를 방지하려면 리소스 요청을 컨테이너의 한계와 동일하게 설정하십시오. 한계가 지정되지 않은 경우 기본값은 작업자 노드의 용량입니다.

자세한 내용은 ‘ Kubernetes ’ 문서를 참조하십시오.

resources:
  requests:
    memory: "512Mi"
    cpu: "500m"
  limits:
    memory: "1024Mi"
    cpu: "1000m"

활성 상태 및 준비 상태 프로브

기본적으로 Kubernetes는 팟(Pod) 내의 모든 컨테이너가 시작되면 앱 팟(Pod)에 트래픽을 전송하며, 컨테이너가 충돌하면 이를 다시 시작합니다. 사용자는 상태 검사를 설정하여 서비스 트래픽 라우팅의 내구성을 향상시킬 수 있습니다.

예를 들면, 사용자의 앱에 시작 지연 시간이 있습니다. 이 앱 프로세스가 전체 앱이 완전히 준비되기 전에 시작될 수 있으며, 이는 응답(특히 많은 인스턴스로 스케일 확장할 때)에 영향을 줄 수 있습니다. 상태 검사를 사용하면 앱의 실행 중 여부 및 요청 수신 준비 여부를 시스템에 알려 줄 수 있습니다. 이러한 프로브를 설정하면 앱의 롤링 업데이트를 수행할 때 작동 중단 시간을 방지하는 데도 도움을 줄 수 있습니다. 사용자는 활성 상태 프로브와 준비 상태 프로브의 두 가지 상태 검사를 설정할 수 있습니다.

활성 프로브

컨테이너가 실행 중인지 여부를 확인하려면 활성 상태 프로브를 설정하십시오. 이 프로브가 실패하면 컨테이너가 다시 시작됩니다. 컨테이너가 활성 상태 프로브를 지정하지 않은 경우, 이 프로브는 컨테이너가 Running 상태이면 컨테이너가 작동 중이라고 가정하므로 성공합니다.

준비 프로브

컨테이너가 요청 및 외부 트래픽을 수신할 준비가 되었는지 여부를 확인하려면 준비 상태 프로브를 설정하십시오. 이 프로브가 실패하면 팟(Pod)의 IP 주소가 제거되며 해당 주소가 팟(Pod)과 일치하는 서비스를 위한 사용 가능한 IP 주소가 되지만, 컨테이너가 다시 시작되지는 않습니다. 앱이 시작되는 데 시간이 다소 걸리는 경우, 초기 지연 시간을 설정하여 준비 상태 프로브를 구성하는 것이 특히 중요합니다. 초기 지연 시간이 경과하기 전에는 프로브가 시작되지 않으며, 이는 컨테이너가 준비를 완료할 시간을 줍니다. 컨테이너가 준비 상태 프로브를 제공하지 않은 경우, 이 프로브는 컨테이너가 Running 상태이면 컨테이너가 작동 중이라고 가정하므로 성공합니다.

명령, HTTP 요청 또는 TCP 소켓으로 프로브를 설정할 수 있습니다. 다음 예는 HTTP 요청을 사용합니다. 준비 상태 프로브보다 활성 상태 프로브에 더 많은 시간을 지정하십시오. 자세한 내용은 ‘ Kubernetes ’ 문서를 참조하십시오.

livenessProbe:
  httpGet:
    path: /
    port: 9080
  initialDelaySeconds: 300
  periodSeconds: 15
readinessProbe:
  httpGet:
    path: /
    port: 9080
  initialDelaySeconds: 45
  periodSeconds: 5

팟(Pod) 중단 비용

앱의 가용성을 높이기 위해, PodDisruptionBudget 객체를 사용하여 원하는 가용성 유형에 따라 앱이 장애 상황에 어떻게 대응할지 제어할 수 있습니다.

팟(Pod) 중단 비용은 앱 배치를 업데이트하여 직접적인 다시 시작을 시작할 때와 같은 자발적 중단 또는 커널 패닉과 같은 비자발적 중단 중에 앱의 작동 방법을 계획하는 데 도움이 될 수 있습니다. minAvailable : 중단이 발생한 후에도 여전히 사용 가능해야 하는 팟(Pod)의 백분율 또는 수를 지정할 수 있습니다.

maxUnavailable

중단이 발생한 후 사용 불가능한 팟(Pod)의 백분율 또는 수를 지정할 수 있습니다. 예에서는 maxUnavailable: 1을 사용합니다.

selector

PodDisruptionBudget 가 적용될 파드 집합을 선택하려면 레이블을 입력하세요. 다른 팟(Pod) 배치에서 이 동일한 레이블을 사용한 경우에도 팟(Pod)이 적용됩니다.

자세한 내용은 ‘ Kubernetes ’ 문서를 참조하십시오.

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: wasliberty
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: wasliberty

앱 노출 서비스

앱을 노출하는 서비스를 작성할 수 있습니다. spec 섹션에서, port 및 레이블 값이 배치에 사용한 것과 일치하도록 하십시오. 이 서비스는 다음 예에서 app: wasliberty와 같은 레이블과 일치하는 오브젝트를 노출합니다.

• 기본적으로 서비스는 ClusterIP를 사용하며, 이로 인해 해당 서비스는 클러스터 내부에서만 접근할 수 있고 클러스터 외부에서는 접근할 수 없습니다.
• NodePort, 로드 밸런서 또는 Ingress 서비스를 작성하여 앱을 외부에 공개할 수 있습니다. 이러한 서비스에는 두 개의 IP 주소(하나는 외부, 하나는 내부)가 있습니다. 외부 IP 주소에 트래픽이 수신되면, 이는 내부 클러스터 IP 주소로 전달됩니다. 그 후 이 트래픽은 내부 클러스터 IP 주소에서 앱의 컨테이너 IP 주소로 라우팅됩니다.
• 다음 예는 NodePort를 사용하여 서비스를 클러스터 외부에 노출합니다. 외부 액세스를 설정하는 방법에 대한 자세한 정보는 NodePort, 로드 밸런서 또는 Ingress 서비스 선택을 참조하십시오.

apiVersion: v1
kind: Service
metadata:
  name: wasliberty
  labels:
    app: wasliberty
spec:
  ports:
  - port: 9080
  selector:
    app: wasliberty
    type: NodePort

특정 포트에서 청취하도록 hostNetwork 팟(Pod)을 배치하거나 hostPort을(를) 사용하여 작업자 노드의 특정 포트에 앱 팟(Pod)을 노출하기 위한 요구사항이 있는 경우 11000-11200 범위의 포트를 사용하십시오. IBM Cloud Kubernetes Service에서는 로컬 포트 및 IBM Cloud Kubernetes Service에서 사용하는 기타 포트와의 충돌을 방지할 목적으로 작업자 노드에서 11000-11200 포트 범위를 지정합니다. hostNetwork 포트 및 hostPorts가 특정 작업자 노드 IP 주소를 참조하므로 팟(Pod)은 해당 노드에서만 실행되도록 제한됩니다. 작업자 노드가 제거되거나 리소스가 부족한 경우와 같이 예상치 못한 사항이 발생한 경우 팟(Pod)을 다시 스케줄할 수 없습니다. 작업자 노드에 팟(Pod)의 포트를 노출할 경우 NodePort 서비스 사용을 대신 고려하십시오. 자세한 내용은 모범 사례 Kubernetes 문서를 참조하십시오.

컨테이너 환경 변수를 위한 ConfigMap

ConfigMap은 배치 워크로드의 민감하지 않은 구성 정보를 제공합니다.

다음 예는 ConfigMap의 값을 배치 YAML의 컨테이너 spec 섹션에서 환경 변수로서 참조하는 방법을 보여줍니다. ConfigMap의 값을 참조함으로써, 사용자는 이 구성 정보를 배치로부터 분리하여 컨테이너화된 앱을 포터블 상태로 유지할 수 있습니다.

• 변수에 대해 Kubernetes ConfigMap 또는 Secret 오브젝트 중 어느 것을 사용할지 결정하는 데 도움을 주십시오.
• configmap을 활용하는 더 많은 방법은 Kubernetes 문서를 참조하세요.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: wasliberty
spec:
  replicas: 3
  template:
    ...
    spec:
      ...
      containers:
      - name: wasliberty
        ...
        env:
          - name: VERSION
            valueFrom:
              configMapKeyRef:
                name: wasliberty
                key: VERSION
          - name: LANGUAGE
            valueFrom:
              configMapKeyRef:
                name: wasliberty
                key: LANGUAGE
        ...
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: wasliberty
  labels:
    app: wasliberty
data:
  VERSION: "1.0"
  LANGUAGE: en

컨테이너 환경 변수를 위한 Secret

Secret은 배치 워크로드의 비밀번호와 같은 민감한 구성 정보를 제공합니다.

다음 예는 시크릿의 값을 배치 YAML의 컨테이너 spec 섹션에서 환경 변수로서 참조하는 방법을 보여줍니다. Secret을 볼륨으로서 마운트할 수도 있습니다. Secret의 값을 참조함으로써, 사용자는 이 구성 정보를 배치로부터 분리하여 컨테이너화된 앱을 포터블 상태로 유지할 수 있습니다.

• 변수에 대해 Kubernetes ConfigMap 또는 Secret 오브젝트 중 어느 것을 사용할지 결정하는 데 도움을 주십시오.
• 시크릿을 생성하려면 ‘ Kubernetes ’ 문서를 참조하세요.

클러스터 전체의 모든 시크릿을 중앙 집중식으로 관리하고 애플리케이션 런타임에 인젝션을 수행하려는 경우에는 IBM Cloud Secrets Manager을(를) 사용해 보십시오.

apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: wasliberty
  spec:
    replicas: 3
    template:
      ...
      spec:
        ...
        containers:
        - name: wasliberty
          ...
          env:
          - name: username
            valueFrom:
              secretKeyRef:
                name: wasliberty
                key: username
          - name: password
            valueFrom:
              secretKeyRef:
                name: wasliberty
                key: password
          ...
  ---
  apiVersion: v1
  kind: Secret
  metadata:
    name: wasliberty
    labels:
      app: wasliberty
  type: Opaque
  data:
    username: dXNlcm5hbWU=
    password: cGFzc3dvcmQ=

컨테이너 스토리지를 위한 지속적 볼륨

지속적 볼륨(PV)은 컨테이너 워크로드를 위한 지속적 데이터 스토리지를 제공하기 위해 물리적 스토리지와 상호작용합니다.

다음 예는 앱에 지속적 스토리지를 추가하는 방법을 보여줍니다. 지속적 스토리지를 프로비저닝하려면 지속적 볼륨 클레임(PVC)을 작성하여 원하는 파일 스토리지의 유형 및 크기를 나타냅니다. PVC를 생성하면 동적 프로비저닝을 통해 영구 볼륨과 물리적 스토리지가 자동으로 생성됩니다. 이 스토리지는 배치 YAML의 PVC를 참조하여 사용자의 앱 팟(Pod)에 자동으로 마운트됩니다. 팟(Pod)의 컨테이너가 /test 마운트 경로 디렉토리에 데이터를 기록하면 해당 데이터가 NFS 파일 스토리지 인스턴스에 저장됩니다. 프로비저닝할 수 있는 다른 스토리지 유형에 대한 선택사항은 고가용성 지속적 스토리지 계획을 참조하십시오.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: wasliberty
spec:
  replicas: 3
  template:
    ...
    spec:
      ...
      containers:
      - name: wasliberty
        ...
        volumeMounts:
        - name: pvmount
          mountPath: /test
      volumes:
      - name: pvmount
        persistentVolumeClaim:
          claimName: wasliberty
        ...
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: wasliberty
  annotations:
    volume.beta.kubernetes.io/storage-class: "ibmc-file-bronze"
  labels:
    billingType: "hourly"
    app: wasliberty
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 24Gi