버전 정보는 연결된 Distributed Cloud 출시 노트를 참고하세요.

워크로드 배포

이 페이지에서는 Google Distributed Cloud Connected 하드웨어에 워크로드를 배포하는 단계와 워크로드를 구성할 때 준수해야 하는 제한사항을 설명합니다.

이 단계를 완료하기 전에 Distributed Cloud 연결 설치 요구사항을 충족하고 Distributed Cloud 하드웨어를 주문해야 합니다.

Google Distributed Cloud(연결형) 하드웨어가 선택한 목적지에 도착하면 Distributed Cloud(연결형)를 주문할 때 지정한 하드웨어, Google Cloud, 일부 네트워크 설정으로 사전 구성됩니다.

Google 설치 프로그램이 실제 설치를 완료하고 시스템 관리자가 Distributed Cloud connected를 로컬 네트워크에 연결합니다.

하드웨어가 로컬 네트워크에 연결되면 Google Cloud 와 통신하여 소프트웨어 업데이트를 다운로드하고Google Cloud 프로젝트에 연결합니다. 그런 다음 Distributed Cloud Connected에서 노드 풀을 프로비저닝하고 워크로드를 배포할 수 있습니다.

배포 개요

Distributed Cloud에 연결된 하드웨어에 워크로드를 배포하려면 다음 단계를 완료하세요.

선택사항: Distributed Cloud Edge Network API를 사용 설정합니다.
선택사항: Distributed Cloud Connected 영역의 네트워크 구성을 초기화합니다.
선택사항: Distributed Cloud 네트워킹 구성
Distributed Cloud(연결형) 클러스터를 만듭니다.
선택사항: 워크로드 데이터에 CMEK를 지원하도록 Cloud Key Management Service와 통합하려면 로컬 스토리지에 고객 관리 암호화 키 (CMEK) 지원 사용 설정을 선택합니다. Distributed Cloud connected에서 워크로드 데이터를 암호화하는 방법에 대한 자세한 내용은 로컬 스토리지 보안을 참고하세요.
노드 풀 만들기 이 단계에서는 노드를 노드 풀에 할당하고, 선택적으로 워크로드 데이터를 암호화하기 위해 Cloud KMS를 사용하여 Linux Unified Key Setup (LUKS) 비밀번호를 래핑 및 래핑 해제하도록 노드 풀을 구성합니다.
클러스터를 테스트하기 위해 클러스터의 사용자 인증 정보를 가져옵니다.
프로젝트에서 Edge Container 뷰어 역할(roles/edgecontainer.viewer) 또는 Edge Container 관리자 역할(roles/edgecontainer.admin)을 사용자에게 할당하여 클러스터에 대한 액세스 권한을 부여합니다.
RoleBinding 및 ClusterRoleBinding를 사용하여 클러스터 리소스에 대한 세분화된 역할 기반 액세스를 사용자에게 할당합니다.
선택사항: Distributed Cloud Connected의 가상 머신에서 워크로드를 실행하기 위해 Google Distributed Cloud의 VM 런타임 지원을 사용 설정합니다.
선택사항: Distributed Cloud Connected에서 GPU 기반 워크로드를 실행하기 위해 GPU 지원을 사용 설정합니다.

NGINX 부하 분산기를 서비스로 배포

다음 예에서는 분산 클라우드 연결 클러스터에 NGINX 서버를 배포하고 서비스로 노출하는 방법을 보여줍니다.

다음 콘텐츠로 nginx-deployment.yaml이라는 YAML 파일을 만듭니다.

apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
labels:
  app: nginx
spec:
replicas: 1
selector:
  matchLabels:
     app: nginx
template:
  metadata:
     labels:
     app: nginx
  spec:
     containers:
     - name: nginx
     image: nginx:latest
     ports:
     - containerPort: 80

다음 명령어를 사용하여 YAML 파일을 클러스터에 적용합니다.
```
kubectl apply -f nginx-deployment.yaml
```

다음 콘텐츠로 nginx-service.yaml이라는 YAML 파일을 만듭니다.

apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
type: LoadBalancer
selector:
  app: nginx
  ports:
     - protocol: TCP
       port: 8080
       targetPort: 80

다음 명령어를 사용하여 YAML 파일을 클러스터에 적용합니다.
```
kubectl apply -f nginx-deployment.yaml
```

다음 명령어를 사용하여 MetalLB 부하 분산기에서 서비스에 할당한 외부 IP 주소를 가져옵니다.

kubectl get services

이 명령어는 다음과 유사한 출력을 반환합니다.

NAME            TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)          AGE
nginx-service   LoadBalancer   10.51.195.25   10.100.68.104   8080:31966/TCP   11d

`NodeSystemConfigUpdate` 리소스 구성

클러스터의 각 노드에 대해 다음과 같이 NodeSystemConfigUpdate 네트워크 기능 연산자 리소스를 구성합니다.

다음 명령어를 사용하여 대상 클러스터의 노드 풀에서 실행 중인 노드를 나열합니다.
```
kubectl get nodes | grep -v master
```
이 명령어는 다음과 유사한 출력을 반환합니다.
```
NAME                                 STATUS   ROLES       AGE     VERSION
pool-example-node-1-01-b2d82cc7      Ready    <none>      2d      v1.22.8-gke.200
pool-example-node-1-02-52ddvfc9      Ready    <none>      2d      v1.22.8-gke.200
```
반환된 노드 이름을 기록하고 짧은 이름을 파생시킵니다. 예를 들어 pool-example-node-1-01-b2d82cc7 노드의 경우 닉네임은 node101입니다.

이전 단계에서 기록한 각 노드에 대해 다음 콘텐츠가 포함된 전용 NodeSystemConfigUpdate 리소스 파일을 만듭니다.

apiVersion: networking.gke.io/v1
kind: NodeSystemConfigUpdate
metadata:
name: nodesystemconfigupdate-NODE_SHORT_NAME
namespace: nf-operator
spec:
kubeletConfig:
  cpuManagerPolicy: Static
  topologyManagerPolicy: SingleNumaNode
nodeName: NODE_NAME
osConfig:
  hugePagesConfig:
     ONE_GB: 2
     TWO_MB: 0
  isolatedCpusPerSocket:
     "0": 40
     "1": 40
sysctls:
  nodeLevel:
     net.core.rmem_max: "8388608"
     net.core.wmem_max: "8388608"

다음을 바꿉니다.

NODE_NAME: 대상 노드의 전체 이름입니다. 예를 들면 pool-example-node-1-01-b2d82cc7입니다.
NODE_SHORT_NAME: 전체 이름에서 파생된 타겟 노드의 짧은 이름입니다. 예를 들면 node101입니다.

각 파일 이름을 node-system-config-update-NODE_SHORT_NAME.yaml로 지정합니다.

다음 명령어를 사용하여 각 NodeSystemConfigUpdate 리소스 파일을 클러스터에 적용합니다.
```
kubectl apply -f node-system-config-update-NODE_SHORT_NAME.yaml
```
NODE_SHORT_NAME을 해당 타겟 노드의 단축 이름으로 바꿉니다.

클러스터에 리소스를 적용하면 영향을 받는 각 노드가 재부팅되며, 이 작업은 최대 30분까지 걸릴 수 있습니다.
1. 영향을 받는 노드가 모두 성공적으로 재부팅될 때까지 상태를 모니터링합니다.
```
kubectl get nodes | grep -v master
```
각 노드의 상태는 재부팅이 완료되면 not-ready에서 ready으로 전환됩니다.

이미지 캐싱을 위한 포드 구성

분산 클라우드 연결 클러스터에서 실행되는 포드가 이미지를 캐시하도록 구성할 수 있습니다. 포드는 저장소에서 처음 가져온 후 캐시된 이미지를 사용하기 시작합니다. 포드를 호스팅하는 노드의 스토리지가 부족하면 새 이미지가 캐시되지 않고 기존 이미지 캐시가 삭제되어 워크로드가 중단 없이 계속 실행됩니다.

포드 구성은 다음 기본 요건을 충족해야 합니다.

포드에 gdce.baremetal.cluster.gke.io/cache-image: true 라벨을 설정해야 합니다.
비공개 이미지 저장소를 사용하는 경우 ImagePullSecret 리소스의 유형은 kubernetes.io/dockerconfigjson이어야 합니다.
타겟 이미지의 캐시된 사본이 항상 사용되도록 포드의 풀 정책을 IfNotPresent로 설정해야 합니다. 캐시된 사본을 로컬에서 사용할 수 없는 경우 이미지가 저장소에서 풀됩니다.

다음 예시에서는 캐싱이 사용 설정된 포드 구성을 보여줍니다.

apiVersion: v1
kind: Pod
metadata:
  name: cached-image-pod
  labels:
    gdce.baremetal.cluster.gke.io/cache-image: "true"
spec:
  containers:
    - name: my-container
      image: your-private-image-repo/your-image:tag
      imagePullPolicy: IfNotPresent
  imagePullSecrets:
    - name: my-image-secret  # If using a private registry

다음 예에서는 캐싱이 사용 설정된 Deployment 구성을 보여줍니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cached-image-deployment
spec:
  template:
    metadata:
      labels:
        gdce.baremetal.cluster.gke.io/cache-image: "true"
    spec:
      containers:
        - name: my-container
          image: your-private-image-repo/your-image:tag
          imagePullPolicy: IfNotPresent
      imagePullSecrets:
        - name: my-image-secret  # If using a private registry

Distributed Cloud 워크로드의 제한사항

Distributed Cloud 연결 워크로드를 구성할 때는 이 섹션에 설명된 제한사항을 준수해야 합니다. 이러한 제한사항은 Distributed Cloud 연결 하드웨어에 배포하는 모든 워크로드에 Distributed Cloud 연결에 의해 적용됩니다.

Linux 워크로드 제한사항

Distributed Cloud connected는 워크로드에 다음 Linux 기능만 지원합니다.

AUDIT_READ
AUDIT_WRITE
CHOWN
DAC_OVERRIDE
FOWNER
FSETID
IPC_LOCK
IPC_OWNER
KILL
MKNOD
NET_ADMIN
NET_BIND_SERVICE
NET_RAW
SETFCAP
SETGID
SETPCAP
SETUID
SYS_CHROOT
SYS_NICE
SYS_PACCT
SYS_PTRACE
SYS_RESOURCE
SYS_TIME

네임스페이스 제한사항

Distributed Cloud Connected는 다음 네임스페이스를 지원하지 않습니다.

hostPID
hostIPC
hostNetwork

리소스 유형 제한

Distributed Cloud Connected는 클라이언트가 서명 요청에 따라 X.509 인증서가 발급되도록 요청할 수 있는 CertificateSigningRequest 리소스 유형을 지원하지 않습니다.

보안 컨텍스트 제한사항

Distributed Cloud Connected는 권한 모드 보안 컨텍스트를 지원하지 않습니다.

포드 바인딩 제한사항

Distributed Cloud Connected는 HostNetwork 네임스페이스에서 포드를 호스트 포트에 바인딩하는 것을 지원하지 않습니다. 또한 HostNetwork 네임스페이스는 사용할 수 없습니다.

`hostPath` 볼륨 제한

Distributed Cloud Connected에서는 읽기/쓰기 액세스 권한이 있는 다음 hostPath 볼륨만 허용합니다.

/dev/hugepages
/dev/infiniband
/dev/vfio
/dev/char
/sys/devices

`PersistentVolumeClaim` 리소스 유형 제한사항

Distributed Cloud connected에서는 다음 PersistentVolumeClaim 리소스 유형만 허용됩니다.

csi
nfs
local

볼륨 유형 제한

Distributed Cloud connected에서는 다음 볼륨 유형만 허용됩니다.

configMap
csi
downwardAPI
emptyDir
hostPath
nfs
persistentVolumeClaim
projected
secret

포드 허용 제한사항

Distributed Cloud Connected는 컨트롤 플레인 노드에서 사용자 생성 포드를 허용하지 않습니다. 특히 Distributed Cloud Connected는 다음 허용 키가 있는 포드의 예약을 허용하지 않습니다.

""
node-role.kubernetes.io/master
node-role.kubernetes.io/control-plane

가장 제한

Distributed Cloud Connected는 사용자 또는 그룹 가장을 지원하지 않습니다.

관리 네임스페이스 제한사항

Distributed Cloud Connected에서는 다음 네임스페이스에 대한 액세스를 허용하지 않습니다.

ai-system
ai-speech-system
ai-ocr-system
ai-translation-system
anthos-identity-service
cert-manager
dataproc-system
dataproc-PROJECT_ID
dns-system
g-istio-system
gke-connect
gke-managed-metrics-server
gke-operators
g-ospf-servicecontrol-system
g-ospf-system
g-pspf-system
gke-system
gpc-backup-system
iam-system
kube-node-lease
kube-public
ippools.whereabouts.cni.cncf.io 삭제를 제외한 kube-system
metallb-system(configMap 리소스를 수정하여 부하 분산 IP 주소 범위를 설정하는 경우는 제외)
nf-operator
oclcm-system
prediction
rm-system
robinio
saas-system
vm-system

PROJECT_ID는 대상 Google Cloud 프로젝트의 ID를 나타냅니다.

이름에 g- 접두사가 있는 네임스페이스는 사용하지 마세요. 이러한 네임스페이스는 일반적으로 Distributed Cloud connected에서 사용하는 예약된 네임스페이스입니다.

웹훅 제한사항

Distributed Cloud connected는 다음과 같이 웹훅을 제한합니다.

생성하는 모든 변형 웹훅은 kube-system 네임스페이스를 자동으로 제외합니다.
다음 리소스 유형에 대해서는 변경 웹훅이 사용 중지됩니다.
- nodes
- persistentvolumes
- certificatesigningrequests
- tokenreviews

포드 우선순위 제한

Distributed Cloud connected를 사용하려면 워크로드 포드의 우선순위를 500000000보다 낮은 값으로 설정해야 합니다.

포드의 런타임 클래스 구성

Distributed Cloud connected를 사용하면 runtimeClassName 필드를 사용하여 구성에서 포드의 런타임 클래스를 지정할 수 있습니다. 이렇게 하면 클러스터 수준에서 지정된 기본 런타임 클래스가 재정의됩니다. 사용 가능한 런타임 클래스는 runc 및 gvisor입니다. 예를 들면 다음과 같습니다.

apiVersion: v1
kind: Pod
metadata:
  name: myPod
spec:
  runtimeClassName: gvisor
  containers:
  - name: myPod
    image: myPodImage 
  restartPolicy: OnFailure

포드 구성에서 이를 생략하면 포드에서 클러스터 수준에서 지정된 클래스를 사용합니다. 클러스터 생성 및 관리에 설명된 대로 --default-container-runtime 매개변수를 사용하여 기본 런타임 클래스를 구성하지 않는 한 기본 클러스터 수준 런타임 클래스는 runc입니다.

Pod 또는 클러스터 수준에서 런타임 클래스를 변경하는 경우 변경사항을 적용하려면 영향을 받는 Pod를 다시 시작해야 합니다.

`gvisor` 런타임 클래스

gvisor 런타임 클래스를 지정하면 포드가 gVisor를 기반으로 하는 Open Container Initiative (OCI) 보안 런타임으로 전환됩니다. gVisor는 워크로드와 호스트 간에 강력한 격리를 도입하는 샌드박스 솔루션입니다.

다음 단계

보안 권장사항 적용하기

워크로드 배포 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.