클래식: NLB 1.0을 사용하여 기본 로드 밸런싱 설정
버전 1.0 NLB는 클래식 클러스터에서만 작성할 수 있으며 VPC 클러스터에서는 작성할 수 없습니다. VPC 클러스터에서 로드 밸런싱하려면 VPC용 로드 밸런서를 사용하여 앱 노출을 참조하십시오.
포트를 노출하고 계층 4 네트워크 로드 밸런서(NLB)의 포터블 IP 주소를 사용하여 컨테이너화된 앱을 노출하십시오. 버전 1.0 NLB에 대한 정보는 NLB 1.0의 컴포넌트 및 아키텍처를 참조하십시오.
다중 구역 클러스터에서 NLB 1.0 설정
시작하기 전에
-
공용 네트워크 로드 밸런서(NLB)를 다중 구역에 작성하려면 하나 이상의 공용 VLAN의 각 구역에서 포터블 서브넷이 사용 가능해야 합니다. 사설 NLB를 다중 구역에 작성하려면 하나 이상의 사설 VLAN의 각 구역에서 포터블 서브넷이 사용 가능해야 합니다. 클러스터의 서브넷 구성에 있는 단계를 수행하여 서비넷을 추가할 수 있습니다.
-
IBM Cloud 인프라 계정에 대해 VRF(Virtual Router Function)를 사용으로 설정하십시오. VRF를 사용으로 설정하려면 VRF 사용을 참조하십시오. VRF가 이미 사용으로 설정되었는지 확인하려면
ibmcloud account show명령을 사용하십시오. VRF를 사용할 수 없거나 사용하지 않으려면 VLAN Spanning을 사용으로 설정하십시오. VRF 또는 VLAN Spanning이 사용으로 설정된 경우, NLB 1.0은 계정의 다양한 서브넷으로 패킷을 라우팅할 수 있습니다. -
default네임스페이스에 대해 ‘Writer’ 또는 ‘Manager’ IBM Cloud IAM 서비스 액세스 역할이 부여되어 있는지 확인하십시오. -
필요한 수의 작업자 노드가 있는지 확인하십시오.
- 클래식 클러스터: 에지 작업자 노드로 네트워크 트래픽을 제한하는 경우에는 NLB가 균등하게 배치되도록 각 구역에서 최소한 두 개의 에지 작업자 노드가 사용으로 설정되었는지 확인하십시오.
-
클러스터 노드가 다시 로드되거나 클러스터 마스터 업데이트에 새
keepalived이미지가 포함되면 로드 밸런서 가상 IP가 새 노드의 네트워크 인터페이스로 이동됩니다. 이러한 상황이 발생하면 로드 밸런서에 대한 지속적인 연결을 다시 설정해야 합니다. 연결을 신속하게 다시 설정하기 위해 애플리케이션에 재시도 로직을 포함시키는 것을 고려하십시오.
다중 구역 클러스터에 NLB 1.0 서비스를 설정하려면 다음을 수행하십시오.
-
클러스터에 앱을 배치하십시오. 배치 구성 파일의 메타데이터 섹션에서 레이블을 추가했는지 확인하십시오. 이 사용자 정의 레이블은 앱이 실행되는 모든 팟(Pod)을 식별하여 로드 밸런싱에 포함시킵니다.
-
공용 또는 사설 네트워크로 노출하려는 앱에 대해 로드 밸런서 서비스를 작성하십시오.
- 예를 들어,
myloadbalancer.yaml이라는 이름의 서비스 구성 파일을 작성하십시오. - 노출하려는 앱에 대한 로드 밸런서 서비스를 정의하십시오. 구역, VLAN 및 IP 주소를 지정할 수 있습니다.
apiVersion: v1 kind: Service metadata: name: myloadbalancer annotations: service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: <public_or_private> service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "<zone>" service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "<vlan_id>" spec: type: LoadBalancer selector: <selector_key>: <selector_value> ports: - protocol: TCP port: 8080 targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise. loadBalancerIP: <IP_address> ``` `service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type` : `private` 또는 `public` 로드 밸런서를 지정하는 어노테이션입니다. 이 어노테이션을 지정하지 않고 작업자 노드가 공용 VLAN에 연결되면 공용 `LoadBalancer` 서비스가 작성됩니다. 작업자 노드가 사설 VLAN에만 연결된 경우에는 사설 `LoadBalancer` 서비스가 작성됩니다. `service.kubernetes.io/ibm-load-balancer-cloud-provider-zone` : 로드 밸런서 서비스가 배치되는 구역을 지정하기 위한 어노테이션입니다. 구역을 보려면 `ibmcloud ks zone ls`를 실행하십시오. `service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan` : 로드 밸런서 서비스가 배치되는 VLAN을 지정하는 어노테이션입니다. VLAN을 보려면 `ibmcloud ks vlan ls --zone <zone>`을 실행하십시오. `selector` : 앱 배치 YAML의 `spec.template.metadata.labels` 섹션에서 사용한 레이블 키(`<selector_key>`) 및 값(`<selector_value>`)입니다. `port` : 서비스가 청취하는 포트입니다. `loadBalancerIP` : 선택사항: 사설 로드 밸런서를 작성하거나 공용 로드 밸런서의 특정 포터블 IP 주소를 사용하려면 사용하려는 IP 주소를 지정하십시오. IP 주소는 어노테이션에 지정한 VLAN 및 구역에 있어야 합니다. IP 주소를 지정하지 않는 경우: : 클러스터가 공용 VLAN에 있는 경우 포터블 공인 IP 주소가 사용됩니다. 대부분의 클러스터는 공용 VLAN에 있습니다. : 클러스터가 사설 VLAN에만 있는 경우, 포터블 사설 IP 주소가 사용됩니다. `2234945`의 사설 VLAN `dal12`에 지정된 IP 주소를 사용하는 사설 NLB 1.0 서비스를 작성하는 구성 파일 예: ```yaml {: codeblock} apiVersion: v1 kind: Service metadata: name: myloadbalancer annotations: service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: private service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "dal12" service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "2234945" spec: type: LoadBalancer selector: app: nginx ports: - protocol: TCP port: 8080 targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise. loadBalancerIP: 172.21.xxx.xxx ``` 3. 선택 사항: ‘ `spec.loadBalancerSourceRanges` ’ 필드에 IP 주소를 지정하여 NLB 서비스를 제한된 IP 주소 범위에서만 사용할 수 있도록 설정할 수 있습니다. ‘ `loadBalancerSourceRanges` ’ 기능은 클러스터 내의 `kube-proxy` 에서 워커 노드의 iptables 규칙을 사용하여 구현됩니다. 자세한 내용은 [‘ Kubernetes ’ 문서를](https://kubernetes.io/docs/concepts/services-networking/){: external} 참조하십시오. 4. 클러스터에 서비스를 작성하십시오. ```sh {: pre} kubectl apply -f myloadbalancer.yaml ``` - 예를 들어,
-
NLB 서비스가 정상적으로 작성되었는지 확인하십시오. 서비스가 작성되고 앱을 사용할 수 있으려면 몇 분 정도 걸릴 수 있습니다.
kubectl describe service myloadbalancer출력 예:
NAME: myloadbalancer Namespace: default Labels: <none> Selector: app=liberty Type: LoadBalancer Zone: dal10 IP: 172.21.xxx.xxx LoadBalancer Ingress: 169.xx.xxx.xxx Port: <unset> 8080/TCP NodePort: <unset> 32040/TCP Endpoints: 172.30.xxx.xxx:8080 Session Affinity: None Events: FirstSeen LastSeen Count From SubObjectPath Type Reason Message --------- -------- ----- ---- ------------- ---- ------ ------- 10s 10s 1 {service-controller } Normal CreatingLoadBalancer Creating load balancer 10s 10s 1 {service-controller } Normal CreatedLoadBalancer Created load balancer -
공용 NLB를 작성한 경우 인터넷에서 앱에 액세스하십시오.
- 선호하는 웹 브라우저를 여십시오.
- NLB 및 포트의 포터블 공인 IP 주소를 입력하십시오.
http://169.xx.xxx.xxx:8080 ``` -
각 영역에 1.0 NLB 버전을 추가하려면 2~4단계를 반복하십시오.
-
NLB 1.0에 대해 소스 IP 보존을 사용으로 설정하도록 선택한 경우에는 에지 노드 친화성을 앱 팟(Pod)에 추가하여 앱 팟(Pod)이 에지 작업자 노드에 스케줄링되도록 하십시오. 수신 요청을 받도록 앱 팟(Pod)이 에지 노드에 스케줄되어야 합니다.
-
선택사항: 로드 밸런서 서비스는 또한 서비스의 NodePort를 통해 앱을 사용할 수 있도록 합니다. NodePort는 클러스터 내의 모든 노드에 대한 모든 공인 및 사설 IP 주소에서 액세스가 가능합니다. NLB 서비스를 사용하는 동안 NodePort에 대한 트래픽을 차단하려면 네트워크 로드 밸런서(NLB) 또는 NodePort 서비스에 대한 인바운드 트래픽 제어를 참조하십시오.
그 다음에는 NLB 하위 도메인을 등록할 수 있습니다.
단일 구역 클러스터에서 NLB 1.0 설정
시작하기 전에
-
네트워크 로드 밸런서(NLB) 서비스에 지정하는 데 사용 가능한 포터블 공인 또는 사설 IP 주소를 보유해야 합니다. 자세한 정보는 클러스터의 서브넷 구성을 참조하십시오.
-
default네임스페이스에 대해 ‘Writer’ 또는 ‘Manager’ IBM Cloud IAM 서비스 액세스 역할이 부여되어 있는지 확인하십시오. -
클러스터 노드가 다시 로드되거나 클러스터 마스터 업데이트에 새
keepalived이미지가 포함되면 로드 밸런서 가상 IP가 새 노드의 네트워크 인터페이스로 이동됩니다. 이러한 상황이 발생하면 로드 밸런서에 대한 지속적인 연결을 다시 설정해야 합니다. 연결을 신속하게 다시 설정하기 위해 애플리케이션에 재시도 로직을 포함시키는 것을 고려하십시오.
단일 구역 클러스터에 NLB 1.0 서비스를 작성하려면 다음을 수행하십시오.
-
클러스터에 앱을 배치하십시오. 배치 구성 파일의 메타데이터 섹션에서 레이블을 추가했는지 확인하십시오. 이 사용자 정의 레이블은 앱이 실행되는 모든 팟(Pod)을 식별하여 로드 밸런싱에 포함시킵니다.
-
공용 또는 사설 네트워크로 노출하려는 앱에 대해 로드 밸런서 서비스를 작성하십시오.
-
예를 들어,
myloadbalancer.yaml이라는 이름의 서비스 구성 파일을 작성하십시오. -
노출하려는 앱에 대한 로드 밸런서 서비스를 정의하십시오.
apiVersion: v1 kind: Service metadata: name: myloadbalancer annotations: service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: <public_or_private> service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "<vlan_id>" spec: type: LoadBalancer selector: <selector_key>: <selector_value> ports: - protocol: TCP port: 8080 targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise. loadBalancerIP: <IP_address> ``` `service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type` : `private` 또는 `public` 로드 밸런서를 지정하는 어노테이션입니다. `service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan` : 로드 밸런서 서비스가 배치되는 VLAN을 지정하는 어노테이션입니다. VLAN을 보려면 `ibmcloud ks vlan ls --zone <zone>`을 실행하십시오. `selector` : 앱 배치 YAML의 `spec.template.metadata.labels` 섹션에서 사용한 레이블 키(`<selector_key>`) 및 값(`<selector_value>`)입니다. `port` : 서비스가 청취하는 포트입니다. `loadBalancerIP` : 선택사항: 사설 로드 밸런서를 작성하거나 공용 로드 밸런서의 특정 포터블 IP 주소를 사용하려면 사용하려는 IP 주소를 지정하십시오. IP 주소는 어노테이션에 지정한 VLAN에 있어야 합니다. IP 주소를 지정하지 않는 경우: : 클러스터가 공용 VLAN에 있는 경우 포터블 공인 IP 주소가 사용됩니다. 대부분의 클러스터는 공용 VLAN에 있습니다. : 클러스터가 사설 VLAN에만 있는 경우, 포터블 사설 IP 주소가 사용됩니다. 사설 VLAN `2234945`에 지정된 IP 주소를 사용하는 사설 NLB 1.0 서비스를 작성하는 구성 파일 예: ```yaml {: codeblock} apiVersion: v1 kind: Service metadata: name: myloadbalancer annotations: service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: private service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "2234945" spec: type: LoadBalancer selector: app: nginx ports: - protocol: TCP port: 8080 targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise. loadBalancerIP: 172.21.xxx.xxx ``` 3. 선택 사항: ‘ `spec.loadBalancerSourceRanges` ’ 필드에 IP 주소를 지정하여 NLB 서비스를 제한된 IP 주소 범위에서만 사용할 수 있도록 설정할 수 있습니다. ‘ `loadBalancerSourceRanges` ’ 기능은 클러스터 내의 `kube-proxy` 에서 워커 노드의 iptables 규칙을 사용하여 구현됩니다. 자세한 내용은 [‘ Kubernetes ’ 문서를](https://kubernetes.io/docs/concepts/services-networking/){: external} 참조하십시오. 4. 클러스터에 서비스를 작성하십시오. ```sh {: pre} kubectl apply -f myloadbalancer.yaml ``` -
-
NLB 서비스가 정상적으로 작성되었는지 확인하십시오. 서비스가 작성되고 앱을 사용할 수 있으려면 몇 분 정도 걸릴 수 있습니다.
kubectl describe service myloadbalancer출력 예:
NAME: myloadbalancer Namespace: default Labels: <none> Selector: app=liberty Type: LoadBalancer Location: dal10 IP: 172.21.xxx.xxx LoadBalancer Ingress: 169.xx.xxx.xxx Port: <unset> 8080/TCP NodePort: <unset> 32040/TCP Endpoints: 172.30.xxx.xxx:8080 Session Affinity: None Events: FirstSeen LastSeen Count From SubObjectPath Type Reason Message --------- -------- ----- ---- ------------- ---- ------ ------- 10s 10s 1 {service-controller } Normal CreatingLoadBalancer Creating load balancer 10s 10s 1 {service-controller } Normal CreatedLoadBalancer Created load balancerLoadBalancer Ingress IP 주소는 NLB 서비스에 지정된 포터블 IP 주소입니다.
-
공용 NLB를 작성한 경우 인터넷에서 앱에 액세스하십시오.
- 선호하는 웹 브라우저를 여십시오.
- NLB 및 포트의 포터블 공인 IP 주소를 입력하십시오.
http://169.xx.xxx.xxx:8080 ``` -
NLB 1.0에 대해 소스 IP 보존을 사용으로 설정하도록 선택한 경우에는 에지 노드 친화성을 앱 팟(Pod)에 추가하여 앱 팟(Pod)이 에지 작업자 노드에 스케줄링되도록 하십시오. 수신 요청을 받도록 앱 팟(Pod)이 에지 노드에 스케줄되어야 합니다.
-
선택사항: 로드 밸런서 서비스는 또한 서비스의 NodePort를 통해 앱을 사용할 수 있도록 합니다. NodePort는 클러스터 내의 모든 노드에 대한 모든 공인 및 사설 IP 주소에서 액세스가 가능합니다. NLB 서비스를 사용하는 동안 NodePort에 대한 트래픽을 차단하려면 네트워크 로드 밸런서(NLB) 또는 NodePort 서비스에 대한 인바운드 트래픽 제어를 참조하십시오.
그 다음에는 NLB 하위 도메인을 등록할 수 있습니다.
소스 IP 보존 사용
이 기능은 버전 1.0 네트워크 로드 밸런서(NLB)에만 해당합니다. 클라이언트 요청의 소스 IP 주소는 기본적으로 버전 2.0 NLB에 의해 보존됩니다.
앱에 대한 클라이언트 요청이 클러스터로 전송되는 경우, 로드 밸런서 서비스 팟(Pod)에서 요청을 수신합니다. 앱 팟(Pod)이 로드 밸런서 서비스 팟(Pod)과 동일한 작업자 노드에 없는 경우 NLB는 요청을 다른 작업자 노드로 전달합니다. 요청의 소스 IP 주소는 로드 밸런서 서비스 포드가 실행되는 워커 노드의 공용 IP 주소로 변경됩니다.
클라이언트 요청의 원래 소스 IP 주소를 유지하려면, 로드 밸런서 서비스에서 소스 IP 기능을 활성화할 수 있습니다. 앱이 개시자의 실제 소스 IP 주소를 볼 수 있도록 TCP 연결은 앱 팟(Pod)으로 계속 진행됩니다. 앱 서버가 보안 및 액세스 제어 정책을 적용해야 하는 경우 등에는 클라이언트의 IP를 유지하는 것이 유용합니다.
소스 IP를 사용할 수 있도록 설정하면 로드 밸런서 서비스 팟(Pod)은 동일한 작업자 노드에 배치된 앱 팟(Pod)에만 요청을 전달해야 합니다. 일반적으로, 로드 밸런서 서비스 팟(Pod)은 앱 팟(Pod)이 배치되는 작업자 노드에도 배치됩니다. 그러나 다음과 같은 일부 상황에서는 로드 밸런서 팟(Pod)과 앱 팟(Pod)이 동일한 작업자 노드에 스케줄되지 않습니다.
- 로드 밸런서 서비스 팟(Pod)만 배치할 수 있도록 오염(taint)된 에지 노드가 있습니다. 이러한 노드에는 앱 팟(Pod)을 배치할 수 없습니다.
- 클러스터가 여러 공용 또는 사설 VLAN에 연결되어 있으며 앱 팟(Pod)이 하나의 VLAN에만 연결된 작업자 노드에 배치될 가능성이 있습니다. NLB IP 주소가 작업자 노드와 다른 VLAN에 연결되어 있어 이러한 작업자 노드에 로드 밸런서 서비스 팟(Pod)을 배치하지 못할 수 있습니다.
로드 밸런서 서비스 팟(Pod) 역시 배치할 수 있는 특정 작업자 노드에 배치하도록 앱을 강제 실행하려면 앱 배치에 친화성 규칙(affinity rule) 및 결함 허용(toleration)을 추가해야 합니다.
에지 노드 친화성 규칙 및 결함 허용 추가
작업자 노드에 에지 노드로 레이블을 지정하고 에지 노드를 오염시키는 경우 로드 밸런서 서비스 팟(Pod)은 해당 에지 노드에만 배치되고 앱 팟(Pod)은 에지 노드에 배치될 수 없습니다. NLB 서비스에 대한 소스 IP가 사용으로 설정되면 에지 노드의 로드 밸런서 팟(Pod)이 다른 작업자 노드의 앱 팟(Pod)에 수신 요청을 전달할 수 없습니다.
앱 포드를 엣지 노드에 배포하도록 강제하려면, 앱 배포에 엣지 노드 어피니티 규칙과 허용 범위를 추가하십시오.
에지 노드 친화성 및 에지 노드 결함 허용을 포함하는 배치 YAML 예:
apiVersion: apps/v1
kind: Deployment
metadata:
name: with-node-affinity
spec:
selector:
matchLabels:
<label_name>: <label_value>
template:
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: dedicated
operator: In
values:
- edge
tolerations:
- key: dedicated
value: edge
...
affinity 와 tolerations 섹션 모두 dedicated 을 key 로, edge 을 value 로 지정하고 있습니다.
여러 공용 또는 사설 VLAN에 대한 친화성 규칙 추가
클러스터가 여러 공용 또는 사설 VLAN에 연결되어 있으면 앱 팟(Pod)이 하나의 VLAN에만 연결된 작업자 노드에 배치될 가능성이 있습니다. NLB IP 주소가 작업자 노드와 다른 VLAN에 연결되어 있는 경우에는 로드 밸런서 서비스 팟(Pod)이 이러한 작업자 노드에 배치되지 않습니다.
소스 IP를 사용할 수 있도록 설정된 경우에는 앱 배치에 친화성 규칙을 추가하여 NLB의 IP 주소와 동일한 VLAN인 작업자 노드에 앱 팟(Pod)을 스케줄하십시오.
시작하기 전에:
계정에 로그인하십시오. If applicable, target the appropriate resource group. 클러스터에 대한 컨텍스트를 설정하십시오.
-
NLB 서비스의 IP 주소를 가져오십시오. LoadBalancer Ingress 필드에서 IP 주소를 확인하십시오.
kubectl describe service <loadbalancer_service_name> -
NLB 서비스가 연결된 VLAN ID를 검색하십시오.
- 클러스터의 포터블 공용 VLAN을 나열하십시오.
ibmcloud ks cluster get --cluster <cluster_name_or_ID> --show-resources ``` 출력 예 ```sh {: screen} ... Subnet VLANs VLAN ID Subnet CIDR Public User-managed 2234947 10.xxx.xx.xxx/29 false false 2234945 169.36.5.xxx/29 true false ``` 2. **Subnet VLANs** 아래의 출력에서 이전에 검색한 NLB IP 주소와 일치하는 서브넷 CIDR을 찾고 VLAN ID를 기록해 두십시오. 예를 들어, NLB 서비스 IP 주소가 `169.36.5.xxx`인 경우 이전 단계의 출력 예에서 일치하는 서브넷은 `169.36.5.xxx/29`입니다. 해당 서브넷이 연결된 VLAN ID는 `2234945`입니다. -
이전 단계에서 기록한 VLAN ID에 대해 앱 배포에 어피니티 규칙을 추가합니다.
예를 들어, 여러 VLAN이 있으나 앱 팟(Pod)이
2234945공용 VLAN의 작업자 노드에만 배치되도록 하려면 다음과 같이 입력하십시오.apiVersion: apps/v1 kind: Deployment metadata: name: with-node-affinity spec: selector: matchLabels: <label_name>: <label_value> template: spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: publicVLAN operator: In values: - "2234945" ...YAML 예에서는 affinity 섹션에서
publicVLAN이key이며"2234945"가value입니다. -
업데이트된 배치 구성 파일을 적용하십시오.
kubectl apply -f with-node-affinity.yaml -
지정된 VLAN에 연결된 작업자 노드에 앱 팟(Pod)이 배치되었는지 확인하십시오.
- 클러스터 내의 팟(Pod)을 나열하십시오.
<selector>를 앱에 사용한 레이블로 대체하십시오.
kubectl get pods -o wide app=<selector> ``` 출력 예 ```sh {: screen} NAME READY STATUS RESTARTS AGE IP NODE cf-py-d7b7d94db-vp8pq 1/1 Running 0 10d 172.30.xxx.xxx 10.176.48.78 ``` 2. 출력에서 앱의 팟(Pod)을 식별하십시오. 해당 팟(Pod)이 있는 작업자 노드의 **NODE** ID를 기록해 두십시오. 이전 단계의 출력 예에서는 앱 팟(Pod) `cf-py-d7b7d94db-vp8pq`가 작업자 노드 `10.176.48.78`에 있습니다. 3. 작업자 노드의 세부사항을 나열하십시오. ```sh {: pre} kubectl describe node <worker_node_ID> ``` 출력 예 ```sh {: screen} NAME: 10.xxx.xx.xxx Role: Labels: arch=amd64 beta.kubernetes.io/arch=amd64 beta.kubernetes.io/os=linux failure-domain.beta.kubernetes.io/region=us-south failure-domain.beta.kubernetes.io/zone=dal10 ibm-cloud.kubernetes.io/encrypted-docker-data=true kubernetes.io/hostname=10.xxx.xx.xxx privateVLAN=2234945 publicVLAN=2234967 ... ``` 4. 출력의 **Labels** 섹션에서 공용 또는 사설 VLAN이 이전 단계에서 지정한 VLAN인지 확인하십시오. - 클러스터 내의 팟(Pod)을 나열하십시오.