스테이트풀(Stateful) 워크로드 만들기

이 페이지에서는 Google Distributed Cloud (GDC) 오프라인 어플라이언스 Kubernetes 클러스터 내에서 스테이트풀 워크로드를 만들고 관리하는 방법을 설명합니다. 스테이트풀(Stateful) 워크로드를 사용하면 영구 스토리지를 사용하여 애플리케이션 배포를 확장할 수 있습니다. 영구 스토리지는 워크로드의 예약 위치와 관계없이 애플리케이션에 일관된 ID와 안정적인 호스트 이름을 제공합니다.

이 페이지는 조직의 애플리케이션 워크로드를 만드는 애플리케이션 운영자 그룹 내 개발자를 위한 페이지입니다.

시작하기 전에

사전 구성된 베어메탈 Kubernetes 클러스터에 대해 명령어를 실행하려면 다음 리소스가 있어야 합니다.

1. Kubernetes 클러스터 이름을 찾거나 플랫폼 관리자에게 클러스터 이름을 문의합니다.

2. Kubernetes 클러스터의 kubeconfig 파일이 없는 경우 로그인 및 생성합니다.

3. Kubernetes 클러스터의 kubeconfig 경로를 사용하여 이 안내의 CLUSTER_KUBECONFIG를 바꿉니다.

스테이트풀 워크로드를 만드는 데 필요한 권한을 얻으려면 조직 IAM 관리자에게 프로젝트 네임스페이스의 네임스페이스 관리자 역할 (namespace-admin)을 부여해 달라고 요청하세요.

StatefulSet 리소스 만들기

StatefulSet 매니페스트를 작성하고 kubectl apply를 실행하여 리소스를 만들어 StatefulSet 객체를 만듭니다. 클라이언트가 StatefulSet 리소스의 포드로 요청을 보내는 안정적인 방법을 제공하려면 Service 객체도 만들어야 합니다.

kubectl apply 명령어는 매니페스트 파일을 사용하여 클러스터에서 리소스를 생성, 업데이트, 삭제합니다. 이는 객체 구성의 선언적 메서드입니다. 이 메서드는 변경사항을 객체 구성 파일에 다시 병합하지 않고 실시간 객체에 대한 쓰기를 보관합니다.

StatefulSet 및 Service 리소스를 만들려면 다음을 실행하세요.

kubectl --kubeconfig CLUSTER_KUBECONFIG -n NAMESPACE \
    apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: SERVICE_NAME
  labels:
    app: APP_NAME
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: APP_NAME
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: STATEFULSET_NAME
spec:
  selector:
    matchLabels:
      app: APP_LABEL_NAME
  serviceName: "SERVICE_NAME"
  replicas: NUMBER_OF_REPLICAS
  template:
    metadata:
      labels:
        app: APP_LABEL_NAME
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: CONTAINER_NAME
        image: CONTAINER_IMAGE
        resources:
          requests:
            nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1
          limits:
            nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: CONTAINER_STORAGE_VOLUME_PATH
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi
EOF

다음을 바꿉니다.

• CLUSTER_KUBECONFIG: 컨테이너 워크로드를 배포할 Kubernetes 클러스터의 kubeconfig 파일입니다.

• NAMESPACE: 컨테이너 워크로드를 배포할 프로젝트 네임스페이스입니다.

• SERVICE_NAME: Service 객체 이름 StatefulSet 객체가 serviceName의 Service 객체도 설정하는지 확인합니다.

• APP_NAME: 배포 내에서 실행할 애플리케이션의 이름입니다.

• APP_LABEL_NAME: StatefulSet 객체에 속하는 포드를 결정하는 라벨 선택기입니다.

• STATEFULSET_NAME: StatefulSet 객체의 이름입니다.

• NUMBER_OF_REPLICAS: 배포에서 관리하는 복제된 Pod 객체 수입니다.

• CONTAINER_NAME: 컨테이너의 이름입니다.

• CONTAINER_IMAGE: 컨테이너 이미지의 이름입니다. REGISTRY_PATH/nginx:1.23와 같은 컨테이너 레지스트리 경로와 이미지 버전을 포함해야 합니다.

• CONTAINER_STORAGE_VOLUME_PATH: 스토리지 볼륨이 마운트되는 컨테이너 내의 경로입니다.

참고: kubectl apply -f DIRECTORY를 사용하여 디렉터리에 저장된 구성 파일에 정의된 새 객체를 만들 수도 있습니다.

예를 들어 다음 StatefulSet 객체와 해당 Service 객체는 스테이트풀 컨테이너 워크로드를 만듭니다.

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx
  serviceName: "nginx"
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: REGISTRY_PATH/nginx:1.23
        resources:
          requests:
            nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1
          limits:
            nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

중요: 컨테이너에 GPU 워크로드를 배포하는 경우 자세한 내용은 GPU 컨테이너 워크로드 관리를 참고하세요.

이 예에서는 다음과 같이 정의됩니다.

• metadata: name 필드로 표시된 nginx이라는 Service 객체가 생성됩니다. Service 객체는 labels.app: nginx 및 selector.app: nginx로 표시된 nginx이라는 앱을 대상으로 합니다. Service 객체는 포트 80을 노출하고 이름을 web으로 지정합니다. 이 Service 객체는 네트워크 도메인을 제어하고 인터넷 트래픽을 StatefulSet 객체로 배포된 컨테이너화된 애플리케이션으로 라우팅합니다.
• replicas: 3 필드에 설정된 대로 복제된 Pod 객체가 3개인 StatefulSet(이름: web)가 생성됩니다.
• .spec.template 섹션에서 설정된 Pod 템플릿은 Pod 객체에 app: nginx 라벨이 지정되었음을 나타냅니다.
• .template.spec 섹션에서 설정한 Pod 사양은 StatefulSet의 포드가 버전 1.23에서 nginx 이미지를 실행하는 nginx 컨테이너 한 개를 실행함을 나타냅니다.
• Pod 사양은 Service 객체로 열린 웹 포트를 사용합니다.
• .template.spec.volumeMounts 섹션은 www라는 mountPath 필드를 지정합니다. mountPath는 스토리지 볼륨이 마운트되는 컨테이너의 경로입니다.
• StatefulSet는 프로비저닝된 스토리지가 각각 1GB인 web-www-0, web-www-1, web-www-2라는 세 개의 PersistentVolumeClaim 객체를 프로비저닝합니다.

생성된 후 StatefulSet는 선택된 수의 Pod 객체가 항상 실행되고 사용 가능한 상태로 유지되도록 합니다. StatefulSet은 오류가 발생했거나 해당 노드에서 축출된 Pod 객체를 자동으로 교체하고, 새 Pod 객체를 StatefulSet 객체의 Pod 사양에 정의된 스토리지 리소스, 리소스 요청 및 제한, 기타 구성과 연결합니다.

StatefulSet 리소스에서 영구 스토리지 요청

영구 스토리지는 필요 시 기본 볼륨이 생성되도록 동적으로 프로비저닝할 수 있습니다. 애플리케이션은 PersistentVolumeClaim 객체를 사용하여 영구 스토리지를 요청할 수 있습니다.

일반적으로 Pod 객체를 만드는 것 외에도 PersistentVolumeClaim 객체를 만들어야 합니다. 하지만 StatefulSet 객체에는 PersistentVolumeClaim 객체를 생성하는 volumeClaimTemplates 배열이 포함됩니다. 각 StatefulSet 복제본은 자체 PersistentVolumeClaim 객체를 가져옵니다.

자세한 내용은 컨테이너 스토리지 구성을 참고하세요.