VMware NSX Container Plugin 4.2

4.2 4.1 4.0 3.2 3.1 3.0
简体中文 Deutsch Español Français Italiano 日本語 한국어 繁體中文 English

Kubernetes 노드 준비

Kubernetes 노드를 준비하는 대부분의 단계는 각각 nsx-node-agent 및 nsx-ncp-bootstrap DaemonSet에서 실행되는 두 개의 컨테이너인 nsx-ovs 및 nsx-ncp-bootstrap을 통해 자동화됩니다.
NCP를 설치하기 전에 Kubernetes 노드에 Python이 설치되어 있고 명령줄 인터페이스를 통해 액세스할 수 있는지 확인하십시오. Linux 패키지 관리자를 사용하여 설치할 수 있습니다. 예를 들어, Ubuntu에서
apt install python
 명령을 실행할 수 있습니다.
Ubuntu의 경우
NSX
 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
 명령을 실행합니다.
VM을 다시 시작한 후에 Kubernetes API 서버에 대한 연결이 손실되지 않도록 하려면 IP 및 고정 경로가 업링크 인터페이스에서 유지되어야 합니다(
ovs_uplink_port
로 지정).
기본적으로 nsx-ovs에는 이름이
host-original-ovs-db
이고 경로가
/etc/openvswitch
인 볼륨 마운트가 있습니다. 이것은 OVS가
conf.db
 파일을 저장하는 데 사용하는 기본 경로입니다. OVS가 다른 경로를 사용하도록 구성되거나 경로가 소프트 링크인 경우 올바른 경로로
host-original-ovs-db
 마운트를 업데이트해야 합니다.
필요한 경우 부트스트랩 컨테이너로 인해 변경된 사항을 실행 취소할 수 있습니다. 자세한 내용은 Kubernetes 노드 정리 항목을 참조하십시오.

Content feedback and comments