This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

포드 및 컨테이너 네트워킹

이 항목에서는 기본 Antrea 이외의 CNI(클러스터 컨테이너 네트워크 인터페이스) 사용 및 VMware NSX 네트워킹이 포함된 vSphere의 워크로드 클러스터에 대해 공개적으로 라우팅 가능한 비-NAT IP 주소 지원 등 워크로드 클러스터의 포드 및 컨테이너 네트워킹을 사용자 지정하는 방법을 설명합니다.

기본값이 아닌 CNI를 사용하여 클러스터 생성

Tanzu CLI를 사용하여 워크로드 클러스터를 배포하면 클러스터에서 Antrea CNI(클러스터 네트워크 인터페이스)가 자동으로 사용되도록 설정되어 있습니다. 또는 Calico CNI 또는 자체 CNI 제공자를 사용하도록 설정할 수 있습니다.

자동 관리 패키지는 Tanzu Kubernetes Grid에서 관리되기 때문에 일반적으로 구성을 업데이트할 필요가 없습니다. 그러나 Calico와 같은 사용자 지정 CNI를 사용하는 워크로드 클러스터를 생성할 수 있습니다. 다음 섹션에는 Calico와 같은 사용자 지정 CNI를 구성하는 단계가 나와 있습니다.

독립형 관리 클러스터 배포 클러스터용 사용자 지정 CNI

1.2.x 이전의 Tanzu Kubernetes Grid 버전과 함께 독립 실행형 관리 클러스터에 의해 배포된 후 v1.3으로 업그레이드된 워크로드 클러스터는 Calico를 CNI 공급자로 계속 사용합니다. 이러한 클러스터의 CNI 제공자는 변경할 수 없습니다.

구성 파일에 CNI 변수를 지정하여 독립형 관리 클러스터에서 배포하는 워크로드 클러스터의 기본 CNI를 변경할 수 있습니다. CNI 변수는 다음 옵션을 지원합니다.

  • (기본값) antrea: Antrea를 사용하도록 설정합니다.
  • calico: Calico를 사용하도록 설정합니다. Calico CNI를 참조하십시오. Windows에서는 이 옵션이 지원되지 않습니다.
  • none: 사용자 지정 CNI 제공자를 사용하도록 설정할 수 있습니다. 사용자 지정 CNI를 참조하십시오.

CNI 변수를 설정하지 않으면 Antrea가 기본적으로 사용하도록 설정됩니다.

Calco CNI

워크로드 클러스터에서 Calico를 사용하도록 설정하려면 구성 파일에서 다음을 지정합니다.

CNI: calico

클러스터 생성 프로세스가 완료되면 워크로드 클러스터에 연결 및 검사에 설명된 대로 클러스터를 검사할 수 있습니다.

사용자 지정 CNI

워크로드 클러스터에서 Calico 이외의 사용자 지정 CNI 제공자를 사용하도록 설정하려면 아래 단계를 따르십시오.

  1. 클러스터를 생성할 때 구성 파일에 CNI: none을 지정합니다. 예:

    CNI: none

    클러스터에 CNI를 적용할 때까지 클러스터 생성 프로세스가 성공하지 않습니다. 관리 클러스터의 클러스터 API 로그에서 클러스터 생성 프로세스를 모니터링할 수 있습니다. 클러스터 API 로그에 액세스하는 방법은 로그 및 모니터링을 참조하십시오.

  2. 클러스터가 초기화되면 CNI 제공자를 클러스터에 적용합니다.

    1. 클러스터의 admin 자격 증명을 가져옵니다. 예:

      tanzu cluster kubeconfig get my-cluster --admin

    2. kubectl의 컨텍스트를 클러스터로 설정합니다. 예:

      kubectl config use-context my-cluster-admin@my-cluster

    3. 클러스터에 CNI 제공자를 적용합니다.

      kubectl apply -f PATH-TO-YOUR-CNI-CONFIGURATION/example.yaml
  3. tanzu cluster list 명령을 사용하여 클러스터의 상태를 모니터링합니다. 클러스터 생성이 완료되면 클러스터 상태가 creating에서 running으로 변경됩니다. 클러스터를 검토하는 방법에 대한 자세한 내용은 워크로드 클러스터에 연결 및 검사를 참조하십시오.

Supervisor 또는 단일 노드 클래스 기반 워크로드 클러스터용 Calico CNI

Supervisor에서 배포한 또는 단일 노드 워크로드 클러스터로 배포한 클래스 기반 클러스터에서 antrea 대신 calico를 설치하려면 다음과 같이 클러스터의 ClusterBootstrap 개체를 먼저 사용자 지정해야 합니다.

  1. 다음 Kubernetes 개체를 포함하는 YAML 파일을 생성합니다.

    apiVersion: cni.tanzu.vmware.com/v1alpha1
kind: CalicoConfig
metadata:
name: CLUSTER-NAME
namespace: CLUSTER-NAMESPACE
spec:
calico:
  config:
    vethMTU: 0
---
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: ClusterBootstrap
metadata:
annotations:
  tkg.tanzu.vmware.com/add-missing-fields-from-tkr: TKR-VERSION
name: CLUSTER-NAME
namespace: CLUSTER-NAMESPACE
spec:
additionalPackages: # Customize additional packages
- refName: metrics-server*
- refName: secretgen-controller*
- refName: pinniped*
cni:
  refName: calico*
  valuesFrom:
    providerRef:
      apiGroup: cni.tanzu.vmware.com
      kind: CalicoConfig
      name: CLUSTER-NAME

    형식 설명:

    • CLUSTER-NAME은 생성하려는 워크로드 클러스터의 이름입니다.
    • CLUSTER-NAMESPACE는 워크로드 클러스터의 네임스페이스입니다.

    • TKR-VERSION은 워크로드 클러스터에 사용하려는 TKr(Tanzu Kubernetes 릴리스)의 버전입니다. 예:

  2. 단일 노드 클러스터의 경우 spec.additionalPackages 정의에서 ClusterBootstrap 블록을 삭제합니다. 단일 노드 클러스터에는 추가 metrics-server, secretgen-controller, pinniped 패키지가 없습니다.

  3. Supervisor이든 독립형 관리 클러스터이든, 관리 클러스터에 kubectl apply -f 명령을 실행하여 파일을 적용합니다.

  4. 다음 구성을 포함하는 Cluster 개체에 YAML 파일을 생성합니다.

    apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
name: CLUSTER-NAME
namespace: CLUSTER-NAMESPACE
spec:
clusterNetwork:
  services:
    cidrBlocks: ["SERVICES-CIDR"]
  pods:
    cidrBlocks: ["PODS-CIDR"]
  serviceDomain: "SERVICE-DOMAIN"
topology:
  class: tanzukubernetescluster
  version: TKR-VERSION
  controlPlane:
    replicas: 1
  workers:
    machineDeployments:
      - class: node-pool
        name: NODE-POOL-NAME
        replicas: 1
  variables:
    - name: vmClass
      value: VM-CLASS
    # Default storageClass for control plane and node pool
    - name: storageClass
      value: STORAGE-CLASS-NAME

    형식 설명:

    • CLUSTER-NAME은 생성하려는 워크로드 클러스터의 이름입니다.
    • CLUSTER-NAMESPACE는 워크로드 클러스터의 네임스페이스입니다.
    • SERVICES-CIDR은 서비스의 CIDR 블록입니다. 예: 198.51.100.0/12.
    • PODS-CIDR은 포드의 CIDR 블록입니다. 예: 192.0.2.0/16.
    • SERVICE-DOMAIN은 서비스 도메인 이름입니다. 예: cluster.local.
    • TKR-VERSION은 워크로드 클러스터에 사용하려는 TKr의 버전입니다. 예: v1.23.5+vmware.1-tkg.1.
    • NODE-POOL-NAME은 machineDeployments의 노드 풀 이름입니다.
    • VM-CLASS는 클러스터에 사용할 VM 클래스의 이름입니다. 예: best-effort-small.
    • STORAGE-CLASS-NAME은 클러스터에 사용할 스토리지 클래스의 이름입니다. 예: wcpglobal-storage-profile.

    예:

    apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
name: my-workload-cluster
namespace: my-workload-cluster-namespace
spec:
clusterNetwork:
 services:
   cidrBlocks: ["198.51.100.0/12"]
 pods:
   cidrBlocks: ["192.0.2.0/16"]
 serviceDomain: "cluster.local"
topology:
 class: tanzukubernetescluster
 version: v1.23.5+vmware.1-tkg.1
 controlPlane:
   replicas: 1
 workers:
   machineDeployments:
     - class: node-pool
       name: my-node-pool
       replicas: 1
 variables:
   - name: vmClass
     value: best-effort-small
   # Default storageClass for control plane and node pool
   - name: storageClass
     value: wcpglobal-storage-profile

  5. 위 단계에서 생성한 Cluster 개체 정의 파일을 tanzu cluster create 명령의 -f 옵션으로 전달하여 워크로드 클러스터를 생성합니다.

Supervisor 배포 TKC 기반 클러스터용 Calico CNI

calico 유형의 Supervisor 배포 워크로드 클러스터에 antrea 대신 TanzuKubernetesCluster를 설치하려면 워크로드 클러스터를 생성하는 데 사용할 클러스터 구성 파일에서 CNI 구성 변수를 설정한 다음, -f 명령의 tanzu cluster create 옵션에 파일을 전달합니다. 예: CNI: calico.

여러 CNI 제공자 사용

macvlan, ipvlan, SR-IOV 또는 DPDK과 같이 워크로드 클러스터에서 여러 CNI 제공자를 사용하도록 설정하려면 Multus 패키지를 설치하고, Antrea 또는 Calico CNI를 이미 실행 중인 클러스터에 Multus 패키지를 설치하고, CNI에 대한 추가 NetworkAttachmentDefinition 리소스를 생성합니다. 그런 다음, 여러 주소 범위에 대해 서로 다른 네트워크 인터페이스를 사용하는 클러스터에 새 포드를 생성할 수 있습니다.

자세한 내용은 워크로드 클러스터에 Multus 배포를 참조하십시오.

라우팅 가능한 비-NAT IP 주소(NSX)를 사용하여 포드 배포

NSX 네트워킹 및 Antrea 컨테이너 네트워크 인터페이스(CNI)가 있는 vSphere에서 Worker 포드의 라우팅 가능한 IP 주소를 워크로드 클러스터를 구성할 수 있으며, 포드에서 들어오고 나가는 외부 요청에 대해 NAT(네트워크 주소 변환)를 우회합니다.

포드의 라우팅 가능 IP 주소를 사용하면 다음을 수행할 수 있습니다.

  • 소스 IP 주소가 NAT 주소가 아니라 라우팅 가능한 포드 IP 주소이기 때문에 공통 공유 서비스에 대한 발신 요청을 추적합니다.
  • NAT를 우회하여 외부 인터넷에서 포드로 직접 인증된 수신 요청을 지원합니다.

라우팅 가능-IP 포드의 NSX 구성

작업자 포드의 라우팅 가능한 IP 주소를 지원하도록 NSX를 구성하려면 다음을 수행합니다.

  1. NSX 서버로 이동하고 네트워킹(Networking) 탭을 엽니다.

  2. 연결(Connectivity) > Tier-1 게이트웨이(Tier-1 Gateways)에서 Tier-1 게이트웨이 추가(Add Tier-1 Gateway)를 클릭하고 라우팅 가능한 IP 포드 전용으로 새 Tier-1 게이트웨이를 구성합니다.

    • 이름: 라우팅 가능한 포드 T1 게이트웨이의 이름을 구성합니다.
    • 연결된 Tier-0 게이트웨이: Tanzu Kubernetes Grid에 대해 다른 Tier-1 게이트웨이가 사용하는 Tier-0 게이트웨이를 선택합니다.
    • Edge 클러스터: 기존 Edge 클러스터를 선택합니다.
    • 라우팅 알림: 모든 고정 경로(All Static Routes), 모든 NAT IP(All NAT IP’s), 모든 연결된 세그먼트 및 서비스 포트(All Connected Segments & Service Ports)를 사용하도록 설정합니다.

    저장(Save)을 클릭하여 필터를 저장합니다.

  3. 연결(Connectivity) > 세그먼트(Segments)를 클릭하고 세그먼트 추가(Add Segment)를 클릭하고 라우팅 가능한 포드가 포함된 워크로드 클러스터 노드에 새 NSX 세그먼트(논리적 스위치)를 구성합니다.

    • 이름: 워크로드 클러스터 노드의 네트워크 세그먼트 이름을 구성합니다.
    • 연결: 방금 생성한 Tier-1 게이트웨이를 선택합니다.
    • 전송 영역: 오버레이 전송 영역(예: tz-overlay)을 선택합니다.
    • 서브넷: 클러스터 노드의 IP 주소 범위(예: 195.115.4.1/24)를 선택합니다. 이 범위는 DHCP 프로파일 서버 IP 주소 값과 겹치지 않아야 합니다.
    • 라우팅 알림: 모든 고정 경로(All Static Routes), 모든 NAT IP(All NAT IP’s), 모든 연결된 세그먼트 및 서비스 포트(All Connected Segments & Service Ports)를 사용하도록 설정합니다.

    저장(Save)을 클릭하여 필터를 저장합니다.

라우팅 가능한 IP 주소가 있는 Supervisor 배포 TKC 포드

라우팅 가능한 비-NAT IP 주소가 있는 Worker 포드를 사용하여 TKC 클러스터를 배포하는 방법은 v1beta1 예: 라우팅 가능한 포드 네트워크가 있는 클러스터를 참조하십시오.

라우팅 가능한 IP 주소를 사용하여 독립형 관리 클러스터 배포 포드

독립형 관리 클러스터를 사용하여 라우팅 가능한 비-NAT IP 주소가 있는 Worker 포드로 워크로드 클러스터를 배포하려면 다음을 수행합니다. CLUSTER_CIDR 설정은 공개적으로 라우팅할 수 있는 IP 주소의 범위를 구성합니다.

  1. 워크로드 클러스터 구성 파일 생성에 설명된 대로 다음과 같이 워크로드 클러스터 구성 파일을 생성합니다.

    • Worker 포드에 할당된 라우팅 가능 IP 주소 블록을 설정하려면 다음 중 하나를 수행할 수 있습니다.
      • 워크로드 클러스터 구성 파일에서 CLUSTER_CIDR을 설정하거나
      • 다음 단계에 표시된 것처럼 tanzu cluster create 명령을 CLUSTER_CIDR= 설정으로 추가합니다.
    • NSXT_POD_ROUTING_ENABLED을 "true"로 설정합니다.
    • NSX Manager IP 주소로 NSXT_MANAGER_HOST를 설정합니다.
    • NSXT_ROUTER_PATH를 라우팅 가능 IP에 대해 새로 추가된 Tier-1 게이트웨이의 인벤토리 경로로 설정합니다. 게이트웨이 이름 왼쪽에 있는 메뉴 아이콘(선명도 세로 줄임표 아이콘)을 클릭하고 클립보드에 경로 복사(Copy Path to Clipboard)를 클릭하여 NSX Manager > 연결(Connectivity) > Tier-1 게이트웨이(Tier-1 Gateways)에서 이 이름을 가져옵니다. 이 이름은 "/infra/tier-1s/로 시작합니다.
    • 구성 파일 변수 참조의 NSX 포드 라우팅 테이블에 따라 NSX에 액세스하는 다른 NSXT_ 문자열 변수를 설정합니다. 포드는 4가지 방법 중 하나로 NSX를 인증할 수 있으며 가장 안전하지 않은 항목은 마지막에 인증할 수 있습니다.
      • 인증서: NSXT_CLIENT_CERT_KEY_DATA, NSXT_CLIENT_CERT_KEY_DATA를 설정합니다. CA에서 발급한 인증서의 경우 NSXT_ROOT_CA_DATA_B64입니다.
      • VMC(VMware Cloud)에서 VMware Identity Manager 토큰: NSXT_VMC_AUTH_HOST 및 NSXT_VMC_ACCESS_TOKEN을 설정합니다.
      • Kubernetes 암호에 저장된 사용자 이름/암호: NSXT_SECRET_NAMESPACE, NSXT_SECRET_NAME, NSXT_USERNAME, NSXT_PASSWORD를 설정합니다.
      • 구성 파일에서 일반 텍스트로 사용자 이름/암호: NSXT_USERNAME 및 NSXT_PASSWORD을 설정합니다.

  2. 워크로드 클러스터 생성에 설명된 대로 tanzu cluster create를 실행합니다. 예:

    $ CLUSTER_CIDR=100.96.0.0/11 tanzu cluster create my-routable-work-cluster -f my-routable-work-cluster-config.yaml
Validating configuration...
Creating workload cluster 'my-routable-work-cluster'...
Waiting for cluster to be initialized...
Waiting for cluster nodes to be available...

라우팅 가능 IP 검증

워크로드 포드에 대한 라우팅 가능 IP 주소를 테스트하려면 다음을 수행합니다.

  1. 웹 서버를 라우팅 가능한 워크로드 클러스터에 배포합니다.

  2. kubectl get pods --o wide를 실행하여 라우팅 가능한 포드의 NAME, INTERNAL-IP, EXTERNAL-IP 값을 검색하고 나열된 IP 주소가 동일하고 라우팅 가능한 CLUSTER_CIDR 범위 내에 있는지 확인합니다.

  3. kubectl get nodes --o wide를 실행하여 라우팅 가능 IP 포드를 포함하는 워크로드 클러스터 노드의 NAME, INTERNAL-IP, EXTERNAL-IP 값을 검색합니다.

  4. 다른 워크로드 클러스터의 제어부 노드에 로그인합니다.

    1. kubectl config use-context CLUSTER-CONTEXT를 실행하여 컨텍스트를 다른 클러스터로 변경합니다.
    2. kubectl get nodes를 실행하여 현재 클러스터의 제어부 노드 IP 주소를 검색합니다.
    3. 방금 검색한 IP 주소를 사용하여 ssh capv@CONTROLPLANE-IP를 실행합니다.
    4. ping webserver를 배포한 라우팅 가능 IP 주소로 curl 요청을 보내고 응답을 확인합니다.
      • ping 출력은 웹 서버의 라우팅 가능한 포드 IP를 소스 주소로 나열해야 합니다.

  5. 브라우저에서 NSX 로그인하고 라우팅 가능 IP 포드에 대해 생성한 Tier-1 게이트웨이로 이동합니다.

  6. 고정 경로(Static Routes)를 클릭하고 라우팅 가능한 CLUSTER_CIDR 범위 내에 다음 경로가 생성되었는지 확인합니다.

    1. 워크로드 클러스터의 제어부 노드에 있는 포드의 경로이며, 다음 홉이 제어부 노드 자체의 주소로 표시됩니다.
    2. 워크로드 클러스터의 Worker 노드에 있는 포드의 경로이며, 다음 홉이 Worker 노드 자체의 주소로 표시됩니다.

라우팅 가능 IP 삭제

라우팅 가능 IP 포드가 포함된 워크로드 클러스터를 삭제한 후 T1 라우터에서 해당 주소를 삭제하여 라우팅 가능 IP 주소를 해제해야 할 수 있습니다.

  1. NSX Manager > 연결(Connectivity) > Tier-1 게이트웨이(Tier-1 Gateways)에서 라우팅 가능 IP 게이트웨이를 선택합니다.

  2. 고정 경로 아래에서 목록을 열 경로 수를 클릭합니다.

  3. 삭제된 클러스터 이름을 포함하는 경로를 검색하고 경로 이름 왼쪽의 메뉴 아이콘(선명도 세로 줄임표 아이콘)에서 각각을 삭제합니다.

    1. 사용 권한 오류로 인해 메뉴에서 경로를 삭제할 수 없는 경우(인증서에 의해 경로가 생성된 경우) API를 통해 경로를 삭제합니다.
      1. 경로 이름 옆의 메뉴에서 클립보드에 경로 복사(Copy Path to Clipboar)를 선택합니다.
      2. curl -i -k -u 'NSXT_USERNAME:NSXT_PASSWORD' -H 'Content-Type: application/json' -H 'X-Allow-Overwrite: true' -X DELETE https://NSXT_MANAGER_HOST/policy/api/v1/STATIC-ROUTE-PATH를 실행합니다. 여기서:
        • NSXT_MANAGER_HOST, NSXT_USERNAME, NSXT_PASSWORD는 NSX 관리자 IP 주소 및 자격 증명입니다.
        • STATIC_ROUTE_PATH는 클립보드에 방금 복사한 경로입니다. 이름은 /infra/tier-1s/로 시작하고 /static-routes/를 포함합니다.

CNI의 네트워크 정책 설정

워크로드 클러스터가 VMware vCenter 서버 관리 인터페이스에 액세스하지 못하도록 제한하려면 Antrea 및 Calico CNI에서 적절한 네트워크 정책을 설정합니다. 이러한 정책을 구성하면 컨테이너 네트워크에서 발생하는 트래픽만 필터링됩니다. 정책은 CSI(컨테이너 스토리지 인터페이스) 및 CPI(클라우드 제공자 인터페이스) 포드를 제외한 모든 포드에서 시작되는 트래픽을 차단합니다.

Antrea의 클러스터 네트워크 정책 설정

워크로드 클러스터의 antrea-policy-csi-cpi.yaml 파일을 통해 Antrea의 클러스터 네트워크 정책을 설정합니다. 이렇게 하려면 다음을 수행합니다.

  1. Tanzu CLI에서 워크로드 클러스터 컨텍스트로 전환합니다.

    kubectl config use-context WORKLOAD-CLUSTER-CONTEXT

  2. 다음 예와 같이 antrea-policy-csi-cpi.yaml 파일을 생성합니다.

    apiVersion: crd.antrea.tanzu.vmware.com/v1alpha1
kind: TierEntitlement
metadata:
  name: edit-system-tiers
spec:
  permission: edit
  tiers:
  - emergency
  - securityops
  - networkops
  - platform
# application and baseline Tiers are not restricted
---
apiVersion: crd.antrea.tanzu.vmware.com/v1alpha1
kind: TierEntitlementBinding
metadata:
  name: admin-edit-system-tiers
spec:
  # Allow only admin to attach Antrea ClusterNetworkPolicy and NetworkPolicy to system Tiers
  subjects:
  - kind: User
    name: admin
  tierEntitlement: edit-system-tiers
---
apiVersion: crd.antrea.io/v1alpha3
kind: ClusterGroup
metadata:
  name: vc-ip
spec:
  ipBlocks:
  - cidr: VC_IP_CIDR # Enter the IP CIDR of vCenter Server, for example 192.168.1.1/3.
---
apiVersion: crd.antrea.io/v1alpha3
kind: ClusterGroup
metadata:
  name: csi-cpi-pods
spec:
  namespaceSelector:
    matchLabels:
      kubernetes.io/metadata.name: kube-system
    podSelector:
      matchExpressions:
      - key: k8s-app
        operator: In
        values: [vsphere-cloud-controller-manager]
---
apiVersion: crd.antrea.io/v1alpha1
kind: ClusterNetworkPolicy
metadata:
  name: allow-csi-cpi-egress-vc
spec:
  priority: 5
  tier: emergency
  appliedTo:
  - group: csi-cpi-pods
  egress:
  - action: Pass
    to:
    - group: vc-ip
---
apiVersion: crd.antrea.io/v1alpha1
kind: ClusterNetworkPolicy
metadata:
  name: drop-egress-vc
spec:
  priority: 10
  tier: emergency
  appliedTo:
  - namespaceSelector: {}  # Selects all Namespaces in the cluster
  egress:
  - action: Drop
    to:
    - group: vc-ip
    참고

    cidr: 필드에 vCenter Server의 IP CIDR(예: 192.168.1.1/32)을 입력합니다.

  3. 파일을 적용합니다.

    kubectl apply -f antrea-policy-csi-cpi.yaml

Calico의 네트워크 정책 설정

워크로드 클러스터의 gnp.yaml 파일을 통해 Calico의 클러스터 네트워크 정책을 설정합니다. 이렇게 하려면 다음을 수행합니다.

  1. Github 위치에서 운영 체제에 맞는 calicoctl 유틸리티 바이너리를 다운로드합니다.

  2. 시스템에 유틸리티를 설치합니다. 예를 들어 Linux 시스템에 유틸리티를 다운로드하고 설치하려면 다음을 수행합니다.

    wget https://github.com/projectcalico/calico/releases/download/CALICO-VERSION/calicoctl-linux-amd64
mv calicoctl-linux-amd64 calicoctl
chmod +x calicoctl

  3. Tanzu CLI에서 워크로드 클러스터 컨텍스트로 전환합니다.

    kubectl config use-context WORKLOAD-CLUSTER-CONTEXT

  4. 다음 예와 같이 gnp.yaml 파일을 생성합니다.

    apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
name: vcenter-egress-deny-all
spec:
order: 1000
types:
  - Egress
egress:
  - action: Allow
    destination:
      notNets:
      -  VC_IP_CIDR # Enter the IP CIDR of vCenter Server, for example 192.168.1.1/32.

---
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
name: vcenter-egress-allow-csi-cpi
spec:
order: 0
types:
  - Egress
egress:
  - action: Allow
    source:
      selector: app == 'vsphere-csi-node' || app == 'vsphere-csi-controller' || k8s-app == 'vsphere-cloud-controller-manager'
    destination:
      nets:
      - VC_IP_CIDR # Enter the IP CIDR of vCenter Server, for example 192.168.1.1/32.
    참고

    notNets: 및 nets: 필드에 vCenter Server의 IP CIDR(예: 192.168.1.1/32)을 입력합니다.

  5. 파일을 적용합니다.

    ./calicoctl apply -f gnp.yaml

Calico의 선택기 옵션에 대한 자세한 내용은 Calico 설명서의 EntityRule을 참조하십시오.

포드 보안 승인 컨트롤러(기술 미리보기)

Kubernetes v1.23 이상을 실행하는 클러스터 내의 네임스페이스의 경우 TKG는 kubernetes 설명서의 Pod 보안 기준에 설명된 대로 PSA(포드 보안 승인) 컨트롤러를 통해 privileged, baseline 또는 restricted 유형의 포드 보안 정책을 적용할 수 있습니다.

참고

이 기능은 지원되지 않는 기술 미리보기 상태입니다. TKG 기능 상태를 참조하십시오.

노드의 PSP(포드 보안 정책)는 Kubernetes에서의 사용 중단을 반영하기 위해 TKG v2.1에서 더 이상 사용되지 않습니다. PSP에서 PSA 컨트롤러로 포드를 마이그레이션하는 방법에 대한 자세한 내용은 PodSecurityPolicy에서 기본 제공 PodSecurity 승인 컨트롤러로 마이그레이션을 참조하십시오.

기본적으로 Kubernetes v1.24 클러스터 네임스페이스에는 포드 보안 warn 및 audit 모드가 baseline으로 설정으로 설정되어 있습니다. 이는 강제 적용 안 함 설정입니다. 즉, PSA 컨트롤러로 마이그레이션하면 정책을 위반하는 포드에 대한 주의가 표시될 수 있지만 포드는 계속 실행됩니다.

일부 TKG 패키지 및 구성 요소가 baseline 모드를 준수하지 않는 것은 알려진 문제입니다. 이 경우 가장 빠른 해결 방법은 영향을 받는 네임스페이스에서 audit=privileged 및 warn=privileged 레이블을 설정하여 위반 감사 메시지 및 경고를 감지하는 것입니다.

kubectl label --overwrite ns NAMESPACE pod-security.kubernetes.io/audit=privileged
kubectl label --overwrite ns NAMESPACE pod-security.kubernetes.io/warn=privileged

여기서 NAMESPACE는 아래에 나열된 설치된 패키지 또는 구성 요소의 네임스페이스입니다.

네임스페이스 패키지 또는 구성 요소
avi-system AKO(load-balancer-and-ingress-service)
cert-manager Cert Manager
pinniped-concierge Pinniped
sonobuoy Sonobuoy
tanzu-auth 인증 서비스(독립형 관리 클러스터용)
tanzu-system-ingress Contour, Envoy
tanzu-system-logging Fluent Bit
tanzu-system-monitoring Prometheus
velero Restic, Velero
vmware-system-auth 인증 서비스(Supervisor용)

이러한 네임스페이스에는 패키지 자체가 설치되는 사용자 선택 네임스페이스 또는 default와 다른 패키지 구성 요소가 포함됩니다.

check-circle-line exclamation-circle-line close-line
Scroll to top icon