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-T에 연결하도록 NCP를 구성하는 경우, 각각 사용자 이름 및 암호와 함께 nsx_api_user 및 nsx_api_password 옵션을 지정합니다. 이 인증 방법은 덜 안전하므로 권장되지 않습니다. NCP가 클라이언트 인증서를 사용하여 인증하도록 구성된 경우 이러한 옵션은 무시됩니다. 이러한 옵션은 NCP YAML 파일에 표시되지 않습니다. 따라서 수동으로 추가해야 합니다.
- NSX-T에서 인증을 받기 위한 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-T 개체를 생성할 수 있습니다. 즉, ID 이름이 동일한 ID가 있어야만 개체를 수정하거나 삭제할 수 있습니다. 따라서 NCP에서 생성된 NSX-T 개체를 실수로 수정하거나 삭제하는 문제를 방지할 수 있습니다. 관리자는 개체를 수정하거나 삭제할 수 있습니다. 주체 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 포드가 마스터 노드에서 실행할 수 있도록 하는 허용 항목이 추가되었습니다.
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가 다시 시작될 때 이전에 생성한 경로 맵이 다시 배포 규칙에 적용됩니다.
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
NCP 3.1.1부터 hostPort가 지원됩니다. 포드에 대해 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는 DaemonSet 옵션으로 구성되어 있으므로 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의 모든 인스턴스를 바꿉니다.
