NCP YAML 파일에는 모든 NCP 구성 요소를 구성, 설치 및 실행하기 위한 정보가 포함되어 있습니다.
- RBAC 정의
- 다양한 CRD(CustomResourceDefinitions)
- NCP 전용 ncp.ini를 포함하는 ConfigMap. 일부 권장 구성 옵션은 이미 설정되어 있습니다.
- NCP 배포
- nsx-node-agent 전용 ncp.ini를 포함하는 ConfigMap. 일부 권장 구성 옵션은 이미 설정되어 있습니다.
- nsx-node-agent, nsx-kube-proxy 및 nsx-ovs를 포함하는 nsx-node-agent DaemonSet.
- nsx-ncp-bootstrap DaemonSet
NSX CNI 및 OpenvSwitch 커널 모듈은 nsx-ncp-bootstrap initContainers에 의해 자동으로 설치됩니다. OpenvSwitch 사용자 공간 데몬이 각 노드의 nsx-ovs 컨테이너에서 실행되고 있습니다.
NCP 배포 규격 업데이트
- 로그 수준 및 로그 디렉토리
- Kubernetes API 서버 IP, 인증서 경로 및 클라이언트 토큰 경로. 기본적으로 환경 변수의 API 서버 ClusterIP가 사용되고 인증서 및 토큰은 ServiceAccount에서 자동으로 마운트됩니다. 일반적으로 변경은 필요하지 않습니다.
- Kubernetes 클러스터 이름
- NSX Manager IP 및 자격 증명
- NSX 리소스 옵션(예: overlay_tz, top_tier_router, container_ip_blocks, external_ip_blocks 등)
기본적으로 Kubernetes 서비스 VIP/포트 및 ServiceAccount 토큰과 ca_file은 Kubernetes API 액세스에 사용됩니다. 여기서 변경은 필요하지 않지만 ncp.ini의 일부 NSX API 옵션을 채워야 합니다.
- nsx_api_managers 옵션을 지정합니다. RFC3896과 호환되는 쉼표로 구분된 NSX Manager IP 주소 또는 URL 규격일 수 있습니다. 예를 들면 다음과 같습니다.
nsx_api_managers = 192.168.1.181, 192.168.1.182, 192.168.1.183
- 기본 인증을 사용하여 NSX에 연결하도록 NCP를 구성하는 경우, 각각 사용자 이름 및 암호와 함께 nsx_api_user 및 nsx_api_password 옵션을 지정합니다. 이 인증 방법은 덜 안전하므로 권장되지 않습니다. NCP가 클라이언트 인증서를 사용하여 인증하도록 구성된 경우 이러한 옵션은 무시됩니다. 이러한 옵션은 NCP YAML 파일에 표시되지 않습니다. 따라서 수동으로 추가해야 합니다.
- NSX에 대한 인증을 위해 nsx_api_cert_file 및 nsx_api_private_key_file 옵션을 지정합니다. nsx_api_cert_file 옵션은 PEM 형식의 클라이언트 인증서 파일에 대한 전체 경로입니다. 이 파일의 내용은 다음과 같아야 합니다.
-----BEGIN CERTIFICATE----- <certificate_data_base64_encoded> -----END CERTIFICATE-----
nsx_api_private_key_file 옵션은 PEM 형식의 클라이언트 개인 키 파일에 대한 전체 경로입니다. 이 파일의 내용은 다음과 같아야 합니다.-----BEGIN PRIVATE KEY----- <private_key_data_base64_encoded> -----END PRIVATE KEY-----
NCP는 클라이언트 인증서 인증을 사용하여 해당 주체 ID로 NSX 개체를 생성할 수 있습니다. 즉, ID 이름이 동일한 ID가 있어야만 개체를 수정하거나 삭제할 수 있습니다. 따라서 NCP에서 생성된 NSX 개체를 실수로 수정하거나 삭제하는 문제를 방지할 수 있습니다. 관리자는 개체를 수정하거나 삭제할 수 있습니다. 주체 ID를 사용하여 개체가 생성되면 해당 내용의 경고가 표시됩니다.
- (옵션) ca_file 옵션을 지정합니다. 이 값은 NSX Manager 서버 인증서를 확인하는 데 사용할 CA 번들 파일이어야 합니다. 설정하지 않으면 시스템 루트 CA가 사용됩니다. nsx_api_managers에 대해 하나의 IP 주소를 지정하면 하나의 CA 파일을 지정합니다. nsx_api_managers에 대해 3개의 IP 주소를 지정하면 하나 또는 3개의 CA 파일을 지정할 수 있습니다. 하나의 CA 파일을 지정하면 해당 파일이 모든 3개 관리자에 대해 사용됩니다. 3개의 CA 파일을 지정하면 각각 nsx_api_managers의 해당 IP 주소에 대해 사용됩니다. 예를 들면 다음과 같습니다.
nsx_api_managers = 192.168.1.181,192.168.1.182,192.168.1.183 ca_file = ca_file_for_all_mgrs or nsx_api_managers = 192.168.1.181,192.168.1.182,192.168.1.183 ca_file = ca_file_for_mgr1,ca_file_for_mgr2,ca_file_for_mgr3
- (옵션) insecure 옵션을 지정합니다. True로 설정하면 NSX Manager 서버 인증서가 확인되지 않습니다. 기본값은 False입니다.
- NCP 포드 규격에 암호 볼륨을 추가하거나 예제 Secrete 볼륨의 주석 처리를 제거합니다.
- NCP 컨테이너 규격에 볼륨 마운트를 추가하거나 예제 볼륨 마운트의 주석 처리를 제거합니다.
- ConfigMap에서 ncp를 업데이트하여 마운트된 볼륨의 파일을 가리키는 인증서 파일 경로를 설정합니다.
공유 Tier-1 토폴로지가 없는 경우 NCP가 Loadbalancer 서비스에 대해 Tier-1 게이트웨이 또는 라우터를 생성하도록 edge_cluster 옵션을 Edge 클러스터 ID로 설정해야 합니다. 로 이동한 후 Edge 클러스터 탭을 선택하고 Edge 클러스터 이름을 클릭하여 Edge 클러스터 ID를 찾을 수 있습니다.
HA(고가용성)가 기본적으로 사용되도록 설정됩니다. 운영 환경에서는 HA를 사용하지 않도록 설정하지 않는 것이 좋습니다.
참고: 기본적으로 kube-scheduler는 마스터 노드의 포드를 스케줄링하지 않습니다. NCP YAML 파일에는 NCP 포드가 마스터 노드에서 실행할 수 있도록 하는 허용 항목이 추가되었습니다.
ncp.ini의 lb_segment_subnet 매개 변수는 서비스 ClusterIP 자체 액세스에 사용됩니다. 기본값은 169.254.131.0/24입니다. NCP는 이 서브넷의 두 번째 마지막 IP 주소를 SNAT IP로 사용합니다. 예를 들어 lb_segment_subnet이 169.254.100.0/24로 설정된 경우 NCP는 169.254.100.254를 SNAT IP로 사용합니다. Windows 작업자 노드에서 lb_segment_subnet을 169.254.131.0/24가 아닌 값으로 설정해야 합니다. 클러스터를 생성한 후에는 lb_segment_subnet을 변경할 수 없습니다.
SNAT 구성
ncp/no_snat: True
[coe] enable_snat = False
참고: 기존 네임스페이스 SNAT 주석을 업데이트하는 것은 지원되지 않습니다. 이러한 작업을 수행하는 경우 오래된 SNAT 규칙이 남아 있을 수 있으므로 네임스페이스의 토폴로지가 일관되지 않은 상태가 됩니다. 일관되지 않은 상태에서 복구하려면 네임스페이스를 다시 생성해야 합니다.
[nsx_v3] configure_t0_redistribution = True
configure_t0_redistribution이 True로 설정되면 NCP는 다시 배포 규칙에 deny 경로 맵 항목을 추가하여 Tier-0 라우터가 클러스터의 내부 서브넷을 BGP 인접 네트워크로 보급하지 못하게 합니다. 이 기능은 주로 vSphere with Kubernetes 클러스터에 사용됩니다. 재배포 규칙에 대해 경로 맵을 생성하지 않으면 NCP가 해당 주체 ID를 사용하여 경로 맵을 생성하고 규칙에 적용합니다. 이 경로 맵을 수정하려면 새 경로 맵으로 교체하고, NCP 생성 경로 맵에서 항목을 복사하고, 새 항목을 추가해야 합니다. 새 항목과 NCP 생성 항목 간에 발생할 수 있는 충돌을 모두 관리해야 합니다. 재배포 규칙에 대한 새 경로 맵을 생성하지 않고 NCP 생성 경로 맵을 설정 해제하면 NCP가 다시 시작될 때 이전에 생성한 경로 맵이 다시 배포 규칙에 적용됩니다.
NAT 규칙에 대한 방화벽 일치 구성
[nsx_v3] # This parameter indicate how firewall is applied to a traffic packet. # Firewall can be bypassed, or be applied to external/internal address of # NAT rule # Choices: MATCH_EXTERNAL_ADDRESS MATCH_INTERNAL_ADDRESS BYPASS #natfirewallmatch = MATCH_INTERNAL_ADDRESS
nsx-node-agent DaemonSet 규격 업데이트
- 로그 수준 및 로그 디렉토리
- Kubernetes API 서버 IP, 인증서 경로 및 클라이언트 토큰 경로. 기본적으로 환경 변수의 API 서버 ClusterIP가 사용되고 인증서 및 토큰은 ServiceAccount에서 자동으로 마운트됩니다. 일반적으로 변경은 필요하지 않습니다.
- OpenvSwitch 업링크 포트. 예: ovs_uplink_port=eth1
- CNI의 MTU 값
CNI의 MTU 값을 설정하려면 nsx-node-agent ConfigMap에서 mtu 매개 변수를 수정하고 nsx-ncp-bootstrap 포드를 다시 시작합니다. 모든 노드의 포드 MTU가 업데이트됩니다. 이에 따라 노드 MTU도 업데이트해야 합니다. 노드와 포드 MTU가 일치하지 않으면 node-pod 통신(예: TCP 작동 여부 및 준비 프로브)에 영향을 줄 수 있습니다.
nsx-ncp-bootstrap DaemonSet은 노드에 CNI 및 OVS 커널 모듈을 설치합니다. 그런 다음, 노드에서 OVS 데몬을 종료하여 나중에 nsx-ovs 컨테이너가 Docker 컨테이너 내부에서 OVS 데몬을 실행할 수 있도록 합니다. CNI가 설치되어 있지 않으면 모든 Kubernetes 노드가 "준비되지 않음" 상태가 됩니다. 부트스트랩 DaemonSet에는 "준비되지 않음" 상태의 노드에서 실행될 수 있도록 하는 허용 항목이 있습니다. CNI 플러그인을 설치한 후 노드가 "준비" 상태가 됩니다.
NSX OVS 커널 모듈을 사용하지 않는 경우에는 OVS 커널 모듈을 컴파일하는 동안 볼륨 매개 변수 host-original-ovs-db를 OpenvSwitch 데이터베이스가 구성된 올바른 경로로 업데이트해야 합니다. 예를 들어 --sysconfdir=/var/lib를 지정하는 경우 host-original-ovs-db를 /var/lib/openvswitch로 설정합니다. 해당 경로를 가리키는 심볼 링크가 아니라 실제 OVS 데이터베이스의 경로를 사용해야 합니다.
NSX OVS 커널 모듈을 사용하는 경우 use_nsx_ovs_kernel_module = True를 설정하고 마운트할 볼륨 관련 줄의 주석 처리를 제거해야 합니다.
# Uncomment these mounts if installing NSX-OVS kernel module # # mount host lib modules to install OVS kernel module if needed # - name: host-modules # mountPath: /lib/modules # # mount openvswitch database # - name: host-config-openvswitch # mountPath: /etc/openvswitch # - name: dir-tmp-usr-ovs-kmod-backup # # we move the usr kmod files to this dir temporarily before # # installing new OVS kmod and/or backing up existing OVS kmod backup # mountPath: /tmp/nsx_usr_ovs_kmod_backup # # mount linux headers for compiling OVS kmod # - name: host-usr-src # mountPath: /usr/src ... # Uncomment these volumes if installing NSX-OVS kernel module # - name: host-modules # hostPath: # path: /lib/modules # - name: host-config-openvswitch # hostPath: # path: /etc/openvswitch # - name: dir-tmp-usr-ovs-kmod-backup # hostPath: # path: /tmp/nsx_usr_ovs_kmod_backup # - name: host-usr-src # hostPath: # path: /usr/src
포드에 대해 hostPort를 지정하려는 경우 nsx-node-agent-config ConfigMap의 [k8s] 섹션에서 enable_hostport_snat를 True로 설정하십시오. 동일한 ConfigMap에서 CNI 플러그인을 설치하는 경우 use_ncp_portmap을 False(기본값)로 설정해야 합니다. CNI 플러그인을 설치하지 않은 경우 NCP 이미지에서 portmap을 사용하려면 use_ncp_portmap을 True로 설정합니다.
ingress:
- from:
- namespaceSelector:
matchLabels:
project: test
- podSelector:
matchLabels:
app: tea
- ipBlock:
cidr: 172.10.0.3/32
- ipBlock:
cidr: 172.10.0.2/32
...
- nsx-node-agent는 컨테이너 네트워크 인터페이스를 관리합니다. 이 에이전트는 CNI 플러그인 및 Kubernetes API 서버와 상호 작용합니다.
- nsx-kube-proxy는 클러스터 IP를 포드 IP로 변환하여 Kubernetes 서비스 추상화를 구현합니다. 업스트림 kube-proxy와 동일한 기능을 구현하지만 상호 배타적이지 않습니다.
- nsx-ovs는 OpenvSwitch 사용자 공간 데몬을 실행합니다. 또한 OVS 브리지를 자동으로 생성하고 IP 주소와 경로를 node-if에서 br-int로 다시 이동합니다. ncp.ini에서 ovs_uplink_port=ethX를 추가하여 ethX을 OVS 브리지 업링크로 사용할 수 있도록 해야 합니다.
작업자 노드가 Ubuntu를 사용하고 있는 경우 ncp-ubuntu.yaml은 AppArmor 커널 모듈이 사용되도록 설정되어 있다고 가정하며, 그렇지 않은 경우 Kubelet는 AppArmor 옵션으로 구성되어 있으므로 nsx-node-agent DaemonSet 실행을 거부합니다. Ubuntu 및 SUSE의 경우 기본적으로 이 모듈을 사용하도록 설정됩니다. 이 모듈을 사용하도록 설정했는지 확인하려면 /sys/module/apparmor/parameters/enabled 파일을 확인합니다.
- AppArmor 옵션을 제거합니다.
annotations: # The following line needs to be removed container.apparmor.security.beta.kubernetes.io/nsx-node-agent: localhost/node-agent-apparmor - nsx-node-agent 및 nsx-kube-proxy 컨테이너 둘 다에 대해 권한 있는 모드를 사용하도록 설정합니다.
securityContext: # The following line needs to be appended privileged: true
참고: kubelet이 hyperkube 이미지를 사용하는 컨테이너 내에서 실행되는 경우, kubelet이 실제 상태와 관계없이 항상 AppArmor가 사용되지 않도록 설정된 것으로 보고합니다. 위와 동일하게 변경한 후 YAML 파일에 적용해야 합니다.
네임스페이스 이름 업데이트
YAML 파일에서 ServiceAccount, ConfigMap, Deployment와 같은 네임스페이스가 지정된 모든 개체는 nsx-system 네임스페이스 아래에 생성됩니다. 다른 네임스페이스를 사용하는 경우 nsx-system의 모든 인스턴스를 바꿉니다.
백업 및 복원 사용
NCP는 NSX의 백업 및 복원 기능을 지원합니다. 지원되는 리소스는 네임스페이스, 포드 및 서비스입니다.
참고: 정책 모드에서 NCP를 구성해야 합니다.
[k8s] enable_restore = True
nsxcli > get ncp-restore status NCP restore status is INITIAL
상태는 INITIAL, RUNNING 또는 SUCCESS일 수 있습니다. INITIAL은 백업/복원 기능이 준비되었지만 실행 중인 복원이 없음을 의미합니다. RUNNING은 복원 프로세스가 NCP에서 실행되고 있음을 의미합니다. SUCCESS는 복원이 성공적으로 완료되었음을 의미합니다. 복원하는 동안 오류가 발생하면 NCP가 자동으로 다시 시작되고 다시 시도됩니다. 상태가 오랫동안 RUNNING 중이면 NCP 로그에서 오류 메시지를 확인합니다.
