這是本系列文章的第四篇，也是最後一篇，在前文中說明了NSX整合Antrea的方案架構，並詳細說明在流程一，包含預先安裝NSX、Kubernetes Cluster、下載對應NSX Agent配置檔的相關事項，本文將接續說明後續的流程二到流程六的操作步驟。
本文接續前篇討論Antrea與NSX Manager整合的手動安裝第一個流程，接下來要繼續後面的五個步驟，整個流程圖如圖1所示，本篇要由流程二：建立自簽安全憑證開始。也同樣提醒大家，相關的步驟於官方文件（https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.2/administration/GUID-DFD8033B-22E2-4D7A-BD58-F68814ECDEB1.html , " Registering an Antrea Container Cluster to NSX-T Data Center"）內有正式的說明。
圖1 Antrea與NSX Manager整合安裝流程。
流程二：建立自簽安全憑證
流程二中將使用Linux內的OpenSSL工具，建立一個在Kubernetes Cluster與NSX Manager間使用、可相互信任的自簽公私鑰。找一台已經安裝了OpenSSL工具的機器，在上面執行下列指令：
# openssl genrsa -out tkgs-122- cluster-private.key 2048 # openssl req -new -key tkgs-122- cluster-private.key -out tkgs-122- cluster.csr -subj "/C=US/ST=CA/ L=Palo Alto/O=VMware/OU=Antrea Cluster/CN=tkgs-122-cluster" # openssl x509 -req -days 3650 -in tkgs-122-cluster.csr -signkey tkgs-122-cluster-private.key -out tkgs-122-cluster.crt
簡單解釋一下上面的指令。假設這裡採用vSphere with Tanzu建立了一個新的Kubernetes Cluster，名稱叫做tkgs-122-cluster，接著：
第一行指令內，先建立一個長度為2,048位元（bit）的私鑰，檔名為tkgs-122-cluster-private.key。
第二行指令中，利用前面建立的私鑰，建立一個名稱叫tkgs-122-cluster.csr的憑證簽署要求檔（Certificate Signing Request）。這步驟內非常重要的是在Subject內填入的CN（Common Name）值，此處填入的就是Kubernetes Cluster名稱叫tkgs-122-cluster。這個名稱務必與流程三內，在NSX Manager內建立Principal Identity User時填入的Node-ID完全一致。
在第三行指令內，使用第一行指令產生的私鑰，以及第二行指令產生的CSR檔，產出對應的憑證檔案tkgs-122-cluster.crt，簽署期可以自行調整，這裡是10年。
由上述指令產出的私鑰tkgs-122-cluster-private.key與憑證tkgs-122-cluster.crt，在後續流程三與流程四都會繼續用到。
流程三：在NSX內建立Principal Identity User並加入憑證
流程三中，需要在NSX管理介面內建立一個對應這個Kubernetes Cluster的Principal Identity User。Principal Identity User是NSX內的特殊帳戶，專門提供給外部服務連接NSX使用，觀念就等同於AWS的Service Account，是給外部服務使用，不是給人用的。在Antrea與NSX註冊時，每個Kubernetes Cluster都需要有一個自己的Principal Identity User。例如，在圖2中建立了三個Principal Identity User，分別對應到三個不同的Kubernetes Cluster要註冊到NSX內來使用。
圖2 建立三個Principal Identity User，並對應到三個不同的Kubernetes Cluster要註冊到NSX內來使用。
進入NSX管理介面後，選擇System - Settings - User Management就可以進入上述介面，在ADD內選擇要建立一個Principal Identity with Role，如圖3所示，填入需求的對應值。其中：
圖3 在ADD內選擇要建立一個Principal Identity with Role。
‧Principal Identity欄位填入一個能夠識別的名稱，這裡是填tkgs-122-cluster-admin。
‧Roles內選擇Enterprise Admin。
‧Node Id填入與前面流程二內CN（Common Name）一模一樣的Kubernetes Cluster名稱，本例是tkgs-122-cluster。
‧Certificate PEM要填入的值，請複製由流程二內產出的憑證檔（tkgs-122-cluster.crt）的內容進來。Linux內就直接用cat指令，然後剪貼所有內容進來即可，記得包括前面與後面的-----BEGIN CERTIFICATE----與------END CERTIFICATE-----都要複製進來。
然後按SAVE儲存，就完成了。
流程四：修改安裝配置檔，輸入NSX及憑證相關資訊
流程一（請參考前篇文章「VMware主力K8s構件‧Antrea容器網路（三）」的介紹）中由VMware官網下載了NSX interworking agent的配置檔，包含interworking.yaml、bootstrap-config.yaml、deregisterjob.yaml，而本流程要修改這些YAML檔內相關的參數。首先，在interworking.yaml和deregisterjob.yaml這兩個檔案中，要告知這個NSX interworking agent的image檔來源在哪裡。
在大部分的安裝環境有Internet連線的話，上述的image於VMware Public Harbor Registry都有，路徑可以這樣找：
‧在流程一中，先確定了Kubernetes Cluster內安裝的Antrea商業版本。此時，到這個對應Antrea商業版本的Release Note頁面。
‧確認安裝的TKC或是原生Kubernetes Cluster內，Worker Node的作業系統是哪種。在Tanzu部署的TKC配置時，通常底層Worker Node的作業系統是Ubuntu或是Photon OS。在Release Note內，依據作業系統型態，找到對應的NSX interworking agent的下載路徑。
在這幾篇文章的展示中，利用vSphere with Tanzu建立的TKC 1.22.9，內建的Antrea商業版本是v1.3.1-1.2.3（請參閱前篇流程一）。同時，配置TKC時選擇的底層OS是Photon。圖4是VMware Container Networking with Antrea 1.3.1-1.2.3版的Release Notes（https://docs.vmware.com/en/VMware-Container-Networking-with-Antrea/1.3.1/rn/VMware-Container-Networking-with-Antrea-Version-131-123-Release-Notes.html）。
圖4 VMware Container Networking with Antrea 1.3.1-1.2.3版的Release Notes。
請注意，圖4內的框選部分，就是對應到不同K8s Node作業系統的NSX interworking agent的下載路徑。因為這裡的K8s底層是Photon，因此路徑就是這裡所標示的projects.registry.vmware.com/antreainterworking/interworking-photon:0.2.0。本步驟內，請到interworking.yaml與deregisterjob.yaml這兩個YAML配置檔內，找到所有的image部分，把上述的image下載路徑輸入進去，如圖5所示。在v1.3.1-1.2.3的interworking.yaml有六個地方要改，deregisterjob.yaml有一處。
圖5 輸入image下載路徑。
如果是Air-Gap，沒有Internet連結到VMware Public Harbor Registry的環境呢？此時的做法就是將在流程一內同時已有下載的image檔案，放到內部Harbor Registry，或是手動安裝到每個Worker Node裡面。請參考正式文件「https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.2/administration/GUID-DFD8033B-22E2-4D7A-BD58-F68814ECDEB1.html , " Registering an Antrea Container Cluster to NSX-T Data Center"」，裡面的最後一段有相關指令說明，如圖6所示。
圖6 相關指令說明。
接著下個步驟是，在bootstrap-config.yaml配置檔內，找到下列四個欄位輸入：
‧clusterName：輸入這個K8s Cluster的名稱。必須與流程二與流程三內輸入的CN Name與Node ID完全一致。在這個範例內，是tkgs-122-cluster。
‧NSXManagers：在括弧內填入NSX Manager的IP地址，依據環境是有單台或三台NSX Managers，把IP全部填入。
‧tls.crt：利用「cat <流程二-憑證檔名> | base64 -w 0」指令，將結果複製貼上。
‧tls.key：利用「cat <流程二-私鑰檔名> | base64 -w 0」指令，將結果複製貼上。
在前面流程二中建立的憑證檔是tkgs-122-cluster.crt，私鑰檔是tkgs-122-cluster-private.key。執行「cat / base64」指令，取得的結果如圖7所示。
圖7 執行「cat / base64」指令後取得的結果。
把圖7內所示的憑證、私鑰完整剪貼到bootstrap-config.yaml內，千萬不要遺漏。圖8就是要修改的bootstrap-config.yaml範例圖，包含前面討論要修改的四個部分。
圖8 修改bootstrap-config.yaml。
這樣所有的配置檔就修改完成了！上述參數的詳細輸入與範例，也請參考正式文件說明（https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.2/administration/GUID-1AC65601-8B35-442D-8613-D3C49F37D1CC.html），裡面有很完整的討論。
流程五：啟用配置檔
流程五極為直接，將上述配置檔放到可控制這個Kubernetes Cluster的跳板機內，並執行下列kubectl指令進行安裝：
# kubectl apply -f bootstrap- config.yaml -f interworking.yaml
接著，利用「kubectl get pods -n vmware-system-antrea」指令查看NSX interworking-agent的安裝狀態。若一段時間後，STATUS停留在Running，四個內部Container都是顯示READY，如圖9所示，就安裝完成了。
圖9 STATUS停留在Running，四個內部Container都顯示READY。
流程六：在NSX Manager 內檢視相關Kubernetes Cluster Inventory資訊
當前面步驟順利完成，此時到NSX Manager - Inventory - Containers - Clusters就可以看到剛剛安裝的Kubernetes Cluster出現，也可以查詢相關的Cluster、Nodes、Pods、Services資訊，如圖10所示。接著，就可以參考網管人雜誌212期「VMware主力K8s構件‧Antrea容器網路（二）」的說明，進行微分段功能的相關配置。
圖10 查詢相關的Cluster、Nodes、Pods、Services資訊。
除此之外，在圖10中，可以看到同一個NSX Manager可以管理多個Kubernetes Cluster。上面的配置內接了一個Tanzu Kubernetes Grid產出的Cluster（tkgm-122-tkc03）、本範例內以vSphere with Tanzu配置的Cluster（tkgs-122-cluster），以及另一個手動建立的原生K8s叢集（vanilla-cluster）。如前所述，這些不同方式建立的Kubernetes叢集，都可以透過一模一樣的流程，連接到NSX Manager內進行管理。
結語
在前期與本期這兩篇文章內詳細討論了如何將一個採用Antrea作為Container Networking Interface的K8s叢集，註冊到NSX Manager內的完整六個流程。以NSX來管理Kubernetes Pod東西向防火牆是很多VMware Tanzu客戶喜愛或打算部署的功能，因此大家應該也會有機會在自己或客戶的環境內進行相關配置，希望前面的討論有順利涵蓋到安裝時需要注意的各個面向。
到目前為止，討論的都著重在使用Antrea整合NSX做容器環境的安全保護。下一篇文章想介紹完全不同的課題，針對企業客戶運作Kubernetes叢集，常會需要能夠「Pod對外連線指定IP地址」功能，這在Antrea內如何實現，將與大家進行說明。
＜本文作者：饒康立，VMware資深技術顧問，主要負責VMware NSX產品線，目前致力於網路虛擬化、軟體定義網路、微分段安全防護技術，以及新應用遞送方案的介紹與推廣。＞