이 페이지에서는 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에 연결된 하드웨어에 워크로드를 배포하려면 다음 단계를 완료하세요.
선택사항: 워크로드 데이터에 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 지원을 사용 설정합니다.
선택사항: Distributed Cloud(연결형) 클러스터를Google Cloud에 연결합니다.
선택사항: Cloud VPN을 사용하여 포드가Google Cloud API 및 서비스에 액세스하도록 비공개 Google 액세스를 구성합니다.
선택사항: Cloud VPN을 사용하여 포드가Google Cloud API 및 서비스에 액세스하도록 Private Service Connect를 구성합니다.
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
SR-IOV 기능으로 컨테이너 배포
다음 예에서는 연결된 Distributed Cloud의 SR-IOV 네트워크 기능 연산자 기능을 사용하는 포드를 배포하는 방법을 보여줍니다.
Distributed Cloud 네트워킹 구성요소 만들기
다음과 같이 Distributed Cloud 연결 배포에 필요한 네트워킹 구성요소를 만듭니다. 이러한 구성요소에 대한 자세한 내용은 Distributed Cloud 연결 네트워킹 기능을 참고하세요.
네트워크를 만듭니다.
gcloud edge-cloud networking networks create NETWORK_NAME \ --location=REGION \ --zone=ZONE_NAME \ --mtu=MTU_SIZE다음을 바꿉니다.
NETWORK_NAME: 이 네트워크를 고유하게 식별하는 설명 이름입니다.REGION: 대상 Distributed Cloud 영역이 속한 Google Cloud 리전입니다.ZONE_NAME: 대상 Distributed Cloud 연결된 영역의 이름입니다.MTU_SIZE: 이 네트워크의 최대 전송 단위 (MTU) 크기입니다. 유효한 값은 1500과 9000입니다. 이 값은default네트워크의 MTU 크기와 일치해야 하며 모든 네트워크에서 동일해야 합니다.
서브네트워크를 만듭니다.
gcloud edge-cloud networking subnets create SUBNETWORK_NAME \ --network=NETWORK_NAME \ --ipv4-range=IPV4_RANGE \ --vlan-id=VLAN_ID \ --location=REGION \ --zone=ZONE_NAME다음을 바꿉니다.
SUBNETWORK_NAME: 이 서브네트워크를 고유하게 식별하는 설명 이름입니다.NETWORK_NAME: 이 서브네트워크를 캡슐화하는 네트워크입니다.IPV4_RANGE: 이 서브네트워크가 IP 주소/접두사 형식으로 포함하는 IPv4 주소 범위입니다.VLAN_ID: 이 서브넷의 타겟 VLAN ID입니다.REGION: 타겟 Distributed Cloud 연결 영역이 속한 Google Cloud 리전입니다.ZONE_NAME: 대상 Distributed Cloud 연결된 영역의 이름입니다.
서브넷이 성공적으로 생성될 때까지 상태를 모니터링합니다.
watch -n 30 'gcloud edge-cloud networking subnets list \ --location=REGION \ --zone=ZONE_NAME다음을 바꿉니다.
REGION: 타겟 Distributed Cloud 연결 영역이 속한 Google Cloud 리전입니다.ZONE_NAME: 대상 Distributed Cloud 연결된 영역의 이름입니다.
상태가
PENDING에서PROVISIONING로, 마지막으로RUNNING로 진행됩니다.VLAN ID, 서브네트워크 CIDR 블록, CIDR 블록의 게이트웨이 IP 주소를 기록합니다. 이러한 값은 이 절차의 뒷부분에서 사용됩니다.
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분까지 걸릴 수 있습니다.
- 영향을 받는 노드가 모두 성공적으로 재부팅될 때까지 상태를 모니터링합니다.
kubectl get nodes | grep -v master
각 노드의 상태는 재부팅이 완료되면
not-ready에서ready으로 전환됩니다.
SR-IOV 네트워크 기능용 ToR 스위치 구성
이 섹션의 단계에 따라 SR-IOV 네트워크 기능 작업을 위해 Distributed Cloud에 연결된 랙의 각 Distributed Cloud ToR 스위치에서 네트워크 인터페이스를 구성합니다.
다음 콘텐츠로
mlnc6-pcie1-tor1-sriov.yaml라는 파일을 만듭니다. 이 파일은 첫 번째 ToR 스위치에서 첫 번째 네트워크 인터페이스를 구성합니다.apiVersion: sriovnetwork.k8s.cni.cncf.io/v1 kind: SriovNetworkNodePolicy metadata: name: mlnx6-pcie1-tor1-sriov namespace: sriov-network-operator spec: deviceType: netdevice isRdma: false linkType: eth mtu: 9000 nicSelector: pfNames: - enp59s0f0np0 nodeSelector: edgecontainer.googleapis.com/network-sriov.capable: "true" numVfs: 31 priority: 99 resourceName: mlnx6_pcie1_tor1_sriov
다음 콘텐츠로
mlnc6-pcie1-tor2-sriov.yaml라는 파일을 만듭니다. 이 파일은 첫 번째 ToR 스위치에서 두 번째 네트워크 인터페이스를 구성합니다.apiVersion: sriovnetwork.k8s.cni.cncf.io/v1 kind: SriovNetworkNodePolicy metadata: name: mlnx6-pcie1-tor2-sriov namespace: sriov-network-operator spec: deviceType: netdevice isRdma: false linkType: eth mtu: 9000 nicSelector: pfNames: - enp59s0f1np1 nodeSelector: edgecontainer.googleapis.com/network-sriov.capable: "true" numVfs: 31 priority: 99 resourceName: mlnx6_pcie1_tor2_sriov
다음 콘텐츠로
mlnc6-pcie2-tor1-sriov.yaml라는 파일을 만듭니다. 이 파일은 두 번째 ToR 스위치에서 첫 번째 네트워크 인터페이스를 구성합니다.apiVersion: sriovnetwork.k8s.cni.cncf.io/v1 kind: SriovNetworkNodePolicy metadata: name: mlnx6-pcie2-tor1-sriov namespace: sriov-network-operator spec: deviceType: netdevice isRdma: false linkType: eth mtu: 9000 nicSelector: pfNames: - enp216s0f0np0 nodeSelector: edgecontainer.googleapis.com/network-sriov.capable: "true" numVfs: 31 priority: 99 resourceName: mlnx6_pcie2_tor1_sriov
다음 콘텐츠로
mlnc6-pcie2-tor2-sriov.yaml라는 파일을 만듭니다. 이 파일은 두 번째 ToR 스위치의 두 번째 네트워크 인터페이스를 구성합니다.apiVersion: sriovnetwork.k8s.cni.cncf.io/v1 kind: SriovNetworkNodePolicy metadata: name: mlnx6-pcie2-tor2-sriov namespace: sriov-network-operator spec: deviceType: netdevice isRdma: false linkType: eth mtu: 9000 nicSelector: pfNames: - enp216s0f1np1 nodeSelector: edgecontainer.googleapis.com/network-sriov.capable: "true" numVfs: 31 priority: 99 resourceName: mlnx6_pcie2_tor2_sriov
다음 명령어를 사용하여 ToR 구성 파일을 클러스터에 적용합니다.
kubectl apply -f mlnc6-pcie1-tor1-sriov.yaml kubectl apply -f mlnc6-pcie1-tor2-sriov.yaml kubectl apply -f mlnc6-pcie2-tor1-sriov.yaml kubectl apply -f mlnc6-pcie2-tor2-sriov.yaml
영향을 받는 노드가 차단되고, 드레인되고, 재부팅됩니다.
다음 명령어를 사용하여 노드 상태를 모니터링합니다.
watch -n 5 'kubectl get sriovnetworknodestates -o yaml -A | \ grep "syncStatus\|pool-"|sed "N;s/\n/ /"'
영향을 받는 모든 노드에
syncStatus: Succeeded가 표시되면 Ctrl+C를 눌러 모니터링 명령어 루프를 종료합니다.이 명령어는 다음과 유사한 출력을 반환하여 ToR 스위치에서 SR-IOV 네트워크 기능이 사용 설정되었음을 나타냅니다.
Allocated resources: (Total limits may be over 100 percent, i.e., overcommitted.) Resource Requests Limits -------- -------- ------ cpu 2520m (3%) 7310m (9%) memory 3044Mi (1%) 9774Mi (3%) ephemeral-storage 0 (0%) 0 (0%) hugepages-1Gi 0 (0%) 0 (0%) hugepages-2Mi 0 (0%) 0 (0%) devices.kubevirt.io/kvm 0 0 devices.kubevirt.io/tun 0 0 devices.kubevirt.io/vhost-net 0 0 gke.io/mlnx6_pcie1_tor1_sriov 3 3 gke.io/mlnx6_pcie1_tor2_sriov 0 0 gke.io/mlnx6_pcie2_tor1_sriov 0 0 gke.io/mlnx6_pcie2_tor2_sriov 0 0
NetworkAttachmentDefinition 리소스 구성
다음과 같이 클러스터의 NetworkAttachmentDefinition 리소스를 구성합니다.
다음 콘텐츠로
network-attachment-definition.yaml라는 파일을 만듭니다.apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: sriov-net1 annotations: k8s.v1.cni.cncf.io/resourceName: gke.io/mlnx6_pcie1_tor1_sriov spec: config: '{ "type": "sriov", "cniVersion": "0.3.1", "vlan": VLAN_ID, "name": "sriov-network", "ipam": { "type": "host-local", "subnet": "SUBNETWORK_CIDR", "routes": [{ "dst": "0.0.0.0/0" }], "gateway": "GATEWAY_ADDRESS" } }'
다음을 바꿉니다.
VLAN_ID: 이 가이드의 앞부분에서 만든 서브넷의 VLAN ID입니다.SUBNETWORK_CIDR: 서브네트워크의 CIDR 블록입니다.GATEWAY_ADDRESS: 서브네트워크의 게이트웨이 IP 주소입니다.
다음 명령어를 사용하여 클러스터에 리소스를 적용합니다.
kubectl apply -f network-attachment-definition.yaml
SR-IOV 네트워크 기능으로 포드 배포
이 섹션의 단계를 완료하여 클러스터에 SR-IOV 네트워크 기능이 있는 포드를 배포합니다. 포드의 구성 파일에 있는 annotations 필드는 이 가이드의 앞부분에서 만든 NetworkAttachmentDefinition 리소스의 이름과 배포된 네임스페이스 (이 예에서는 default)를 지정합니다.
다음 콘텐츠로
sriovpod.yaml라는 Pod 사양 파일을 만듭니다.apiVersion: v1 kind: Pod metadata: name: sriovpod annotations: k8s.v1.cni.cncf.io/networks: default/sriov-net1 spec: containers: - name: sleeppodsriov command: ["sh", "-c", "trap : TERM INT; sleep infinity & wait"] image: busybox securityContext: capabilities: add: - NET_ADMIN
다음 명령어를 사용하여 포드 사양 파일을 클러스터에 적용합니다.
kubectl apply -f sriovpod.yaml
다음 명령어를 사용하여 포드가 성공적으로 시작되었는지 확인합니다.
kubectl get pods
다음 명령어를 사용하여 Pod의 명령줄 셸을 설정합니다.
kubectl exec -it sriovpod -- sh
포드 셸에서 다음 명령어를 사용하여 포드가 SR-IOV 네트워크 기능 연산자 기능을 사용하여 ToR 스위치와 통신하는지 확인합니다.
ip addr
이 명령어는 다음과 유사한 출력을 반환합니다.
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 51: net1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 9000 qdisc mq qlen 1000 link/ether 2a:af:96:a5:42:ab brd ff:ff:ff:ff:ff:ff inet 192.168.100.11/25 brd 192.168.100.127 scope global net1 valid_lft forever preferred_lft forever 228: eth0@if229: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue qlen 1000 link/ether 46:c9:1d:4c:bf:32 brd ff:ff:ff:ff:ff:ff inet 10.10.3.159/32 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::44c9:1dff:fe4c:bf32/64 scope link valid_lft forever preferred_lft forevernet1인터페이스에 반환된 정보는 ToR 스위치와 포드 간의 네트워크 연결이 설정되었음을 나타냅니다.
이미지 캐싱을 위한 포드 구성
분산 클라우드 연결 클러스터에서 실행되는 포드가 이미지를 캐시하도록 구성할 수 있습니다. 포드는 저장소에서 처음 가져온 후 캐시된 이미지를 사용하기 시작합니다. 포드를 호스팅하는 노드의 스토리지가 부족하면 새 이미지가 캐시되지 않고 기존 이미지 캐시가 삭제되어 워크로드가 중단 없이 계속 실행됩니다.
포드 구성은 다음 기본 요건을 충족해야 합니다.
- 포드에
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_READAUDIT_WRITECHOWNDAC_OVERRIDEFOWNERFSETIDIPC_LOCKIPC_OWNERKILLMKNODNET_ADMINNET_BIND_SERVICENET_RAWSETFCAPSETGIDSETPCAPSETUIDSYS_CHROOTSYS_NICESYS_PACCTSYS_PTRACESYS_RESOURCESYS_TIME
네임스페이스 제한사항
Distributed Cloud Connected는 다음 네임스페이스를 지원하지 않습니다.
hostPIDhostIPChostNetwork
리소스 유형 제한
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 리소스 유형만 허용됩니다.
csinfslocal
볼륨 유형 제한
Distributed Cloud connected에서는 다음 볼륨 유형만 허용됩니다.
configMapcsidownwardAPIemptyDirhostPathnfspersistentVolumeClaimprojectedsecret
포드 허용 제한사항
Distributed Cloud Connected는 컨트롤 플레인 노드에서 사용자 생성 포드를 허용하지 않습니다. 특히 Distributed Cloud Connected는 다음 허용 키가 있는 포드의 예약을 허용하지 않습니다.
""node-role.kubernetes.io/masternode-role.kubernetes.io/control-plane
가장 제한
Distributed Cloud Connected는 사용자 또는 그룹 가장을 지원하지 않습니다.
관리 네임스페이스 제한사항
Distributed Cloud Connected에서는 다음 네임스페이스에 대한 액세스를 허용하지 않습니다.
ai-systemai-speech-systemai-ocr-systemai-translation-systemanthos-identity-servicecert-managerdataproc-systemdataproc-PROJECT_IDdns-systemg-istio-systemgke-connectgke-managed-metrics-servergke-operatorsg-ospf-servicecontrol-systemg-ospf-systemg-pspf-systemgke-systemgpc-backup-systemiam-systemkube-node-leasekube-publicippools.whereabouts.cni.cncf.io삭제를 제외한kube-systemmetallb-system(configMap리소스를 수정하여 부하 분산 IP 주소 범위를 설정하는 경우는 제외)nf-operatoroclcm-systempredictionrm-systemrobiniosaas-systemsriov-fec-systemsriov-network-operatorvm-system
PROJECT_ID는 대상 Google Cloud 프로젝트의 ID를 나타냅니다.
이름에 g- 접두사가 있는 네임스페이스는 사용하지 마세요. 이러한 네임스페이스는 일반적으로 Distributed Cloud connected에서 사용하는 예약된 네임스페이스입니다.
웹훅 제한사항
Distributed Cloud connected는 다음과 같이 웹훅을 제한합니다.
- 생성하는 모든 변형 웹훅은
kube-system네임스페이스를 자동으로 제외합니다. - 다음 리소스 유형에 대해서는 변경 웹훅이 사용 중지됩니다.
nodespersistentvolumescertificatesigningrequeststokenreviews
포드 우선순위 제한
Distributed Cloud connected를 사용하려면 워크로드 포드의 우선순위를 500000000보다 낮은 값으로 설정해야 합니다.