Kubernetes 노드를 준비하는 대부분의 단계는 각각 nsx-node-agent 및 nsx-ncp-bootstrap DaemonSet에서 실행되는 두 개의 컨테이너인 nsx-ovs 및 nsx-ncp-bootstrap을 통해 자동화됩니다.

NCP를 설치하기 전에 Kubernetes 노드에 Python이 설치되어 있고 명령줄 인터페이스를 통해 액세스할 수 있는지 확인하십시오. Linux 패키지 관리자를 사용하여 설치할 수 있습니다. 예를 들어, Ubuntu에서 apt install python 명령을 실행할 수 있습니다.

Ubuntu의 경우 NSX-T CNI 플러그인을 설치하면 AppArmor 프로파일 파일인 ncp-apparmor가 /etc/apparmor.d에 복사되고 로드됩니다. 설치 전에 AppArmor 서비스를 실행해야 하며 /etc/apparmor.d 디렉토리가 있어야 합니다. 없으면 설치가 실패합니다. 다음 명령을 실행하여 AppArmor 모듈이 사용되는지 여부를 확인할 수 있습니다. 
    sudo cat /sys/module/apparmor/parameters/enabled
다음 명령을 실행하여 AppArmor 서비스가 시작되었는지 여부를 확인할 수 있습니다. 
    sudo /etc/init.d/apparmor status

ncp-apparmor 프로파일 파일에 포함된 NSX 노드 에이전트용 AppArmor 프로파일인 node-agent-apparmor는 다음과 같은 점에서 docker-default 프로파일과 다릅니다.

  • deny mount 규칙이 제거되었습니다.
  • mount 규칙이 추가되었습니다.
  • 일부 network, capability, file 및 umount 옵션이 추가되었습니다.

node-agent-apparmor 프로파일을 다른 프로파일로 바꿀 수 있습니다. 이 경우 NCP YAML 파일에서 프로파일 이름 node-agent-apparmor를 변경해야 합니다.

NSX NCP 부트스트랩 컨테이너는 호스트에서 NSX CNI의 설치 및 업데이트를 자동화합니다. 이전 릴리스에서는 NSX CNI가 deb/rpm 패키지를 통해 설치되었습니다. 이번 릴리스에서는 파일이 간단히 호스트에 복사됩니다. 부트스트랩 컨테이너는 패키지 관리자의 데이터베이스에서 이전에 설치된 NSX CNI 구성 요소를 제거합니다. 다음 디렉토리 및 파일이 삭제됩니다.
  • /etc/cni/net.d
  • /etc/apparmor.d/ncp-apparmor
  • /opt/cni/bin/nsx
부트스트랩 컨테이너는 10-nsx.conflist 파일을 확인하고 nsxBuildVersion 태그에서 CNI 버전 번호를 찾습니다. 이 버전이 부트스트랩 컨테이너에 있는 것보다 이전 버전인 경우 다음 파일이 호스트에 복사됩니다.
  • /opt/cni/bin/nsx
  • /etc/cni/net.d/99-loopback.conf
  • /etc/cni/net.d/10-nsx.conflist
  • /etc/apparmor.d/ncp-apparmor

/opt/cni/bin/loopback 및 /etc/cni/net.d/99-loopback.conf 파일이 있는 경우 덮어쓰지 않습니다. OS 유형이 Ubuntu인 경우 ncp-apparmor 파일도 호스트에 복사됩니다.

또한 부트스트랩 컨테이너는 IP 주소와 경로를 br-int에서 node-if로 이동합니다. 또한 호스트에서 실행 중이면 OVS는 nsx-ovs 컨테이너 내에서 실행되기 때문에 중지됩니다. nsx-ovs 컨테이너가 없으면 br-int 인스턴스가 생성되고, 노드 논리적 스위치에 연결된 네트워크 인터페이스(node-if)를 br-int에 추가한 후 br-int 및 node-if 링크 상태가 실행 중인지 확인합니다. IP 주소와 경로를 node-if에서 br-int로 이동합니다. nsx-node-agent 포드 또는 nsx-ovs 컨테이너가 다시 시작되면 몇 초 동안 다운타임이 발생합니다.

참고: nsx-node-agent DaemonSet이 제거되면 OVS가 호스트(컨테이너 또는 호스트의 PID)에서 더 이상 실행되지 않습니다.
네트워크 구성을 업데이트하여 IP 주소 및 경로를 영구적으로 설정합니다. 예를 들어, Ubuntu의 경우 /etc/network/interfaces를 편집하여(해당 환경의 실제 값 사용) IP 주소 및 경로를 영구적으로 설정합니다. 
auto eth1
iface eth1 inet static
address 172.16.1.4/24
#persistent static routes
up route add -net 172.16.1.3/24 gw 172.16.1.1 dev eth1

그런 후 ifdown eth1; ifup eth1 명령을 실행합니다.

RHEL의 경우 /etc/sysconfig/network-scripts/ifcfg-<node-if>를 생성한 후 편집하여(해당 환경의 실제 값 사용) IP 주소를 영구적으로 설정합니다. 
HWADDR=00:0C:29:B7:DC:6F
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=none
IPADDR=172.10.0.2
PREFIX=24
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV4_DNS_PRIORITY=100
IPV6INIT=no
NAME=eth1
UUID=39317e23-909b-45fc-9951-849ece53cb83
DEVICE=eth1
ONBOOT=yes

그런 후 systemctl restart network.service 명령을 실행합니다.

RHEL의 영구 경로 구성에 대한 자세한 내용은 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sec-configuring_static_routes_in_ifcfg_files를 참조하십시오.

참고: VM을 다시 시작한 후에 Kubernetes API 서버에 대한 연결이 손실되지 않도록 하려면 IP 및 정적 경로가 업링크 인터페이스에서 유지되어야 합니다( ovs_uplink_port로 지정).
참고: 기본적으로 nsx-ovs에는 이름이 host-original-ovs-db이고 경로가 /etc/openvswitch인 볼륨 마운트가 있습니다. 이것은 OVS가 conf.db 파일을 저장하는 데 사용하는 기본 경로입니다. OVS가 다른 경로를 사용하도록 구성되거나 경로가 소프트 링크인 경우 올바른 경로로 host-original-ovs-db 마운트를 업데이트해야 합니다.

필요한 경우 부트스트랩 컨테이너로 인해 변경된 사항을 실행 취소할 수 있습니다. 자세한 내용은 Kubernetes 노드 정리를 참조하십시오.