Azure - 建立 Azure Kubernetes Service - 2020-10-19 version

19 October 2020 — Written by Sky Chang
#Azure#Container#AKS#Log Analytics#ACR#Kubernetes#Docker#Linux#AKS

Update

因目前 AKS 每過一段時就會有一些新的功能與發展,所以重新撰寫了這篇。

舊篇在此

  • 2020-10-19 新增 : 新增建立時,需要注意的功能項目

    • CSI
    • Ubuntu 18.04
    • ContainerD
    • 使用暫存磁碟
    • AAD RBAC 驗證
    • PPG
    • SLA 99.95

前言

現在 Kubernetes 紅得幾乎如日中天,各家都推出自己的 Kubernetes 服務,而在 Microsoft 的 K8S,當然就叫做 Azure Kubernetes Service,雖然以前寫了很多次的如何 Create AKS 的文章,但隨著時間,不斷有很多需要在建置前注意的項目。

原本想在同一篇進行更新,但後來認為,因為網址是透過時間來編排,所以可能會讓人誤導,這篇文章是舊的,所以後續決定還是拉一篇新的來撰寫。

而這篇加入了許多 AKS 提供了非常不錯的 Preview 功能,當然,這些功能很多都必須要一開始建立的時候,就必須 Enable 起來,而且很多是 UI 選不到的,必須透過 az cli 指令來建立 AKS,所以這次,主要針對 AKS 的建立,包含這些 Preview 功能。

建立 Create Log Analytics 工作區

因為 AKS 會使用到 Log Analytics 來存放 Log 資訊,雖然你可以讓他自己建立,但放置的 Resource 位置都醜醜的,所以第一步,我們先來建立 Create Log Analytics 工作區。

找到 Log Analytics 工作區並建立,基本上,裡面也沒什麼可以選的...就順順的建立完成吧。

2020 05 27 16 55 07

建立 Azure Container Registry

通常 AKS 拉的 Images 會來自 ACR ( 你要放到 Docker Hub 也是可以啦 ),所以這邊會建議也先準備好 ACR,因為現在建立 AKS 的時候,可以直接選擇 ACR,讓他直接塞 Service Principal 進去,可以省掉自己加 Service Principal 的步驟。

2020 05 27 17 44 08

這邊不會提到怎麼建 ACR,後續找時間再來補上 ACR 的部分。

建立 AAD Group

如果未來希望讓只有在此 Group 的人才能管理 AKS 的話,那要先新建一個 AAD Group。

建立 AAD Service Principal

在以前,建立 AKS 的第一步,就是要建立 Service Pricnipal,因為 AKS ( Azure Kubernetes Service ) 會需要和其他 Azure 的服務互動,所以我們必須給他一個 AAD Service Principal,如果對於 Service Prinipal 不熟悉的,可以參考底下兩篇文章

但這個時代,建立 AKS 的時候,你可以先不用建立了,而且,不是以前那種建立出來醜醜的 SP,而是現在有直接管理的機制 ( 刪除 AKS,Service Princiap 也會自動刪除喔! ),所以這個時代,這個步驟就可以省略掉了。

建立 Azure Kubernetes Service 前,需要知道的概念

  • 若需要 Preview 功能,請使用 Az cli 建立
  • 若要使用 Preview 功能,請先安裝擴充套件
# 增加擴充功能
az extension add --name aks-preview
az extension list

# 有需要可以 Update
az extension update --name aks-preview

在建立之前,有幾個地方要特別注意。

開時前的觀念

在 K8S 裡面,我們都知道,有 Node 這個概念,所以會有 Master Node ( 也就是 Control Plan Node ),也有 Work Node,當然,既然使用了 AKS,自然就是不用管 Master Node 這件事情了 ( 想碰也碰不到 ),而 AKS 有趣的地方是,將 Node 的概念更加延伸成 Node Pool。

先談談 Node Pool,以前 K8S 的時代,一台主機就代表一個 Node,所以我們可能會需要三台的 Master Node,和三台的 Work Node,這也算是 K8S 最基本的基本盤。而在 AKS 上,這三台 Work Node,因為需要做到 Scale Out 等等的自動機制,所以在 AKS 上,就把這個三台 Work Node 改用 Node Pool 來稱呼 ( 背後就是 Azure VMSS 啊!! ),當然,這也合理,因為使用 VMSS 處理 Scale Out,本來就是在 VM 上常用的手段,而拿到 AKS 上,也是合情合理。

但也因此,在 AKS 上,如果我想要新增一台新的 Node,可能就沒辦法透過自建 VM,然後自己下 Kubeadm 的指令來新增一個新的 Node 進來。

那這時候該怎麼辦??我想要一台 GPU 的機器啊!!!

所以,在 AKS 上,它提供了你建立新的 Node Pool 到這個 AKS 裡面,換言之,你就可以透過指令或是 UI,讓你輕易的把你要的 GPU 變成 VMSS 然後輕易的加入到你的 AKS Node 裡面。

所以,對於 AKS 來說,就是使用 Node Pool 來管理你所有想要的 Node。

所以這邊簡單示範一下,如下圖,這是剛建立好的 AKS,當時選了三個 node,也就是說,有一個 node pool,而這個 node pool 有三個 node。

2020 10 20 22 45 00

基本上,透過 get pod,也只能看到 core-dns,但 etcd、apiserver、kube-controller、kube-scheduler 是看不到的。

2020 10 20 22 48 15

而這邊,多補充一點,其實在 AKS 上,預設建立的第一組 Node Pool,代表的是 System Node Pool ( 和 Control Plan 沒關係喔~ ),他主要用途是拿來放 CoreDns 等等重要服務。我們可以針對第一次建立的其中一個 node 看他的參數,可以看到 Label 裡面敘述了這是 System。

2020 10 20 22 53 51

當然,對於一般應用來說,其實也沒差,你還是可以把你的所有應用程式塞到這個 System Node Pool 裡面,所以在早期的一些專案項目,就直接把 System Node Pool 拿來做使用,也是可以的,但如果要提高效能,使用 PPG ( Proximity Placement Groups 鄰近位置群組 ),就沒辦法那麼單純使用。 ( 關於 PPG 下面會再介紹 )

既然有 System Node Pool 這個模式,那表示可能還有別的模式囉!?是的,其中還有 User Node Pool 和 Spot Node Pool,但 Spot Node Pool 這篇文章不會介紹,簡單的說,就是省錢模式 XDDD

而 User Node Pool,在 AKS 的定義,就是專門拿來放應用程式的 Pool,我們可以先簡單實驗一下,如果這時候,我們加了新的 node pool,就會變成如下。

2020 10 20 22 56 19

沒錯,其實對整個 AKS 而言,新增加一組 Node Pool,其實等同就是加了很多的 node 到這個 AKS 底下。但如果去查看新增加 Node Pool 裡面的其中一個 Node,可以發現,其實是沒有 mode=system 這個 Label 的,而在 AKS 裡面,這稱為 User Node Pool。

2020 10 20 22 58 26

而在 AKS 官方的文件建議下,其實是建議 System Node Pool 是存放比較重要的核心 Pod,而 User Node Pool 則是存放一般的應用。

至於為什麼要在開頭講那麼多,主要還是後面 PPG 啊!!!

Node 的 Pods 數

預設每一個 Node 的最大 Pods 數為 110,若要調整為最大 Pods 數 ( 250 ) 需使用 AZ CLI 底下參數進行設定,目前 UI 沒此參數。

--max-pods=250

雖然正常情況下,一個 Node 的 Pods 數不太會高達超過 110,但如果真的有超過這個的規劃,那可能要使用 Azure Cli 進行建置。( 配置完後, 就不可變更 )

另外,每個 Node 的最少 Pod 數目為 10,但正常情況也沒辦法這定為 10,若要設定每個 Node 最少為 10 個 Pod,那必須要有三個 Node,換言之,每個 Node Pool 至少需要 30 個 Pod 空間。

參考網址

AKS IP 的規劃

在 AKS 下,有分 Kubenet 和 Azure CNI,使用 Kubenet 的話,那 AKS 內部的 IP 會被 NAT,所以 IP 自然不需要大量,但正常情況下,大概只有測試才會使用 Kubenet 當作 CNI,通常我們還是會使用 Azure CNI ,而 Azure CNI 就會遇到需要大量 IP 提供給 Pod 的狀況,而他的公式如下:

EX : 若有 50 個節點,其中也包含相應增加的 10 個節點的佈建:(50 + 10 + 1) + ( (50+10+1) * 30 (default)) = 1,891 (/21 或更大)

所以如果未來有需要有非常多的 Node,則要提前考慮與計算。

也請在開始前,將此網段切好,不然可能只能重新建 AKS 了

Note :

  • +1 是為了升級,通常升級的時候,會建立一個新的 Node 進行升級,再把舊的砍掉,所以會有 +1

以小弟來說,我就有切一個 Study4DevAKS-Node 10.99.100.0/23 (507 個可用) 在 VNET 裡面。

另外也保留了一段 10.99.98.0/23 準備給 AKS Service-cidr ( 此網段不可以加入到 VNET 裡面 )

參考網址

AKS-VNode IP 的規劃

除了使用 Node 外,AKS 支援使用 ACI ( Azure Contianer Instance ) 來進行存放實際的 Pods,通常 VNode 需要一個網段,而每一個 Pods 也會佔用掉一個 IP。

雖然這個功能,在建立完後再 enable / disable,但若有需要,開始前將此網段切好,會比較好。

以小弟來說,我就有切一個 Study4DevAKS-VNode : 10.99.105.0/24 (251 個可用) 在 VNET 裡面。

AKS Node 大小的規劃

AKS 的 Node 規格建立後,就不可以變更了 ( 很重要,請唸三遍 ),所以到底要給大一點的 VM 當作 Node,還是小一點的 VM 當 Node,在一開始的時候,就決定了一切。

AKS 的私人叢集

建立 AKS 的時候,可以決定,是否只有內網 ( VNet 內 ) 才能對 AKS 進行控制 ( EX : 使用 Kubectl ),而這個也會在建立玩成後,無法變更。

但目前將 AKS 放到私人叢集可能會有以下 issue

網路原則

目前 AKS 支援原生、Calico、Azure 三種網路原則,雖然小弟我一定是選 Azure,但如果有需要其他原則的考量,可能也要在部署前思考清楚。

Note : 請注意,這邊網路原則,並不是 CNI

選擇新版本的 Ubunut - Preview 請使用 az cli

目前 AKS 支援 Ubuntu 18.04 Node OS,在高於 1.18.8 的 kubernetes 版本中運作。而小於 1.18.8 的版本,會使用 Ubuntu 16.04。

若要請用此功能,請執行底下指令,先開啟預覽。

# 註冊 自訂 Ubuntu 版本功能
az feature register --name UseCustomizedUbuntuPreview --namespace Microsoft.ContainerService

# 確認狀況
az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/UseCustomizedUbuntuPreview')].{Name:name,State:properties.state}"

# 完成後請重整資源
az provider register --namespace Microsoft.ContainerService

後續可以加上此參數

--aks-custom-headers CustomizedUbuntu=aks-ubuntu-1804

參考資料

選擇 containerd 當作 CRI - Preview 請使用 az cli

如果追求效能,那目前 AKS 可以將 Docker 換掉,換成 containerd ( 可惡,竟然沒有 CRI-O QQ... ),目前這個也是預覽功能,但根據官方說法,未來 contianerd 會變成預設。

這個功能,必須搭配 Ubuntu 18.04,所以必須先啟用上面列之功能。

# 註冊 自訂 containerd 的功能
az feature register --name UseCustomizedContainerRuntime --namespace Microsoft.ContainerService

# 確認狀況
az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/UseCustomizedContainerRuntime')].{Name:name,State:properties.state}"

# 完成後請重整資源
az provider register --namespace Microsoft.ContainerService

後續可以加上此參數

--aks-custom-headers CustomizedUbuntu=aks-ubuntu-1804,ContainerRuntime=containerd

使用第二代 VM - Preview 請使用 az cli

略,目前小弟還是會使用 第一代 VM,但有需求的可以直接參考官網。

參考資料

使用暫存磁碟存放 VM OS - Preview 請使用 az cli

正常情況下,VM 都會將 OS 放到 Azure Storage,這樣當 VM 掛掉的時候,那就可以重新起來,而且原本在 OS 的設定,資料都還在 ( 因為在 Azure Storage ),But 啊,But,在 AKS 的 Node VM,這件事情就有點多餘,因為我們通常不會跑進去 Node VM 去裝東西,或是設定東西。而所有的應用,也全部都 Container 裡面,而 Container 要儲存的東西,也可能透過 Mount PV 的方式,放到 Azure Storage 上,也因此,原本 VM 的 OS 放到 Azure Storage 就顯得很多餘。

所以這邊官方也提供了一種作法,就是整個 OS,就不存到 Azure Storage 上去了,而是用 Temp Disk 的方式來存放 OS。

而這種方法,以會讓整個 VM 起來的速度更快,若有 Node Scale Out 的需求,就會加快速度。但同樣的,缺點就是,選擇 VM 的時候,要選擇 Temp Disk 大小,大於 100G 的。

( 其實也可以透過參數 --node-osdisk-size 來指定 node os 的 disk 最小為 30G,但目前文件沒提到,為什麼要 100G。而當變成 30G 的時候,會不會有什麼影響,目前只想到 container image 太多,不知道 30G 夠不夠....)

總之,要啟用這個功能,可以透過底下指令先註冊

# 註冊 自訂 containerd 的功能
az feature register --name EnableEphemeralOSDiskPreview --namespace "Microsoft.ContainerService"

# 確認狀況
az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/EnableEphemeralOSDiskPreview')].{Name:name,State:properties.state}"

# 完成後請重整資源
az provider register --namespace Microsoft.ContainerService

完成後,可以使用底下參數

--node-osdisk-type Ephemeral

自訂資源群組 - 請使用 az cli

建立 AKS 的時候,會建立兩個資源群組,其中一個通常會用比較難看的方式命名,若有需要,可以透過 az cli 來重新命名。

--node-resource-group myNodeResourceGroup

啟用 CSI - Preview 請使用 az cli

在以前的 K8S,是沒有將各個功能做出 Interface,所以很多都是和核心綁定,而其中一塊,就是針對 Storage 這塊,而目前 AKS 也提供了啟用 CSI 的功能。

若有想使用,可以透過底下指令啟動。

# 註冊 CSI 功能
az feature register --namespace "Microsoft.ContainerService" --name "EnableAzureDiskFileCSIDriver"

# 確認狀況
az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/EnableAzureDiskFileCSIDriver')].{Name:name,State:properties.state}"

# 完成後請重整資源
az provider register --namespace Microsoft.ContainerService

完成後,可以使用底下參數

--aks-custom-headers EnableAzureDiskFileCSIDriver=true

參考資料

建立可用性區域

若啟用可用性區域,則會在物理的層級上,將 Node 分派到不同的區域,來降低故障的機率或是計畫中的維護事件。

  • 雖然啟用有這些好處,但使用 Storage 掛載的時候要特別注意,若使用 Azure 受控磁碟的狀態,會出現問題,因為磁碟無法跨區,所以要自行處理配置的 Pod,當然最好的做法,還是使用 Azure File。
  • 要再開始的時候,就啟用此功能,才能讓 Control Plan Node 分散到不同的區域,若一開始沒啟用,後續針對 Node Pool 新增的時候,也只會針對 Work Node 進行分散,而 Control Plan 是不會分散的。
  • 若要搭配使用 PPG 鄰近位置群組,請特別注意,請參考 PPG 章節

可以使用底下參數

--zones 1 2 3

參考資料

鄰近位置群組 - Preview 請使用 az cli

啟用 PPG 的好處,就是可以讓 Pod 與 Pod 之間的溝通速度加快 ( 因為 Node 和 Node 會建置在附近 ),但對於 Control Plan Node 是不會有任何的效果...

這個功能目前也有一些限制

  • 多個不同的 node pool 可以與同一個 PPG 相關聯
  • node pool 同時間只能與一個 PPG 相關聯
  • PPG 只能對應一個可用性區域

所以,上述的結論就是,建立一個 Node Pool 的時候,搭配可用性區域,是無法達到完整 PPG 和 可用性區域效果的。

所以關於官方文件提到,若要同時使用 PPG + 可用性區域的解決方案。

  • 針對 System Node Pool,可以先不使用此參數,這樣可以確保 System Nod Pod,分散在多個可用性區域中。
  • 後續增加的 User Node Pool,請對應到不同的 PPG,例如 Pool-1 對應到 PPG1,Pool-2 對應到 PPG2。

透過這種方式,就可以達到 System Node Pool 和 CP 都有可用性區域的分散好處,若再搭配 SLA 功能的啟用,就可以讓 CP 達到 SLA 99.95%。雖然沒有 PPG,但 System Pod 或是 CP 上的延遲,通常是可以接受的,反而是 CP 需要 SLA 99.95%。

而後面的 User Node Pool 與 不同 zone 和 PPG 的配置,就可以讓對應上 PPG 的 User Node Pool 裡面的 Pod 與其他放在同一個 PPG 的溝通的速度加快,但相對的,也失去了高可用性的優勢... ( 這個 Zone 掛了,就等於全掛了.... )

Note : 如果下指令對應到多台,也只會出現這個錯誤,所以是 PPG 只能對應到一個 Zone 或 No Zone。

2020 10 21 01 53 22

使用此功能的方法。

# 註冊 PPG 功能
az feature register --namespace "Microsoft.ContainerService" --name "ProximityPlacementGroupPreview"

# 確認狀況
az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/ProximityPlacementGroupPreview')].{Name:name,State:properties.state}"

完成後,可以使用底下參數

--ppg myPPGResourceID

參考資料

關於PPG

Azure AD RBAC 整合 - Preview 請使用 az cli

在正常的 K8S 下,會使用 Role Base 來定義管理 K8S 的權限,而目前 AKS 可以整合 Azure AD RBAC,透過 Azure AD RBAC 控管大部分的權限,例如多個 AKS 叢集,可以使用 SSO 登入,或是直接透過 Azure Portal IAM 來授予權線 ( 超方便 ),雖然這篇可能沒辦法詳細介紹,但如果需要此功能,在預覽版本的狀況下,還是要在建立叢集的時候給予參數。

若有想使用,可以透過底下指令啟動。

# 註冊 AzureRBAC 功能
az feature register --namespace "Microsoft.ContainerService" --name "EnableAzureRBACPreview"

# 確認狀況
az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/EnableAzureRBACPreview')].{Name:name,State:properties.state}"

# 完成後請重整資源
az provider register --namespace Microsoft.ContainerService

完成後,可以使用底下參數

--enable-aad --enable-azure-rbac

參考資料

SLA 99.95 - 請使用 az cli

這個功能,不需要在建立的時候啟用,可以透過 az cli 隨時啟用 ( 但,不能取消使用 )

預設情況下,免費的 Control Plan Node,因為給微軟託管,所以微軟這邊保證了 99.5% 的可用性,讓大家不用擔心 Control Plan Node 死掉。 ( 對,少了 0.9% ) 而如果要拉高到 SLA 99.95%,則需要啟用此功能並且搭配可用性集區的設定。( 單啟用此功能,但可用性集區不啟用,只會達到 99.9% )

另外,若啟用了 SLA 功能,會有額外的費用產生。

若有想使用,可以透過底下指令啟動。

# 啟用 SLA 99.95
 az aks update --resource-group myResourceGroup --name myAKSCluster --uptime-sla

參考資料

建立 AKS

底下分成兩種方法建立,一個是 az cli,一個是透過 UI,目前如上面所敘述,有很多功能目前 UI 都沒提供,所以比較建議透過 az cli 來建立。

建立 Azure Kubernetes Service - az cli

如果想使用 AZ Cli 建立的,可以參考底下,目前底下的 AZ Cli 是需要建立 SP 的過程,若想讓他自己託管,可以將建立指令多加上,詳細可以參考

--enable-managed-identity

底下流程會分兩個階段進行,我們會建立有 可用性區域的 System Node Pool 和 CP,然後會再加上給 App 使用的 User Node Pool。

# 填寫自己的 Resource Group、AKS名稱、地區、PPG ID
RESOURCE_GROUP_NAME=Study4Dev-JE
CLUSTER_NAME=AKS-Study4Dev-JE
AAD_GROUP_ID=xxxxxxx-xxx-xxxx-xxxx-xxxxxxxxxxxx
TENANT_ID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
WORKSPACE_ID=/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx/resourcegroups/study4dev-je/providers/microsoft.operationalinsights/workspaces/loganalytics-aks-study4dev-je

# 其中, VNET Subnet ID 和 ACR ID 會比較麻煩,沒辦法輕易的透過 UI 查看到,所以 $SUBNET_ID 就用 Shell姊 解決。

SUBNET_ID=$(az network vnet subnet show --resource-group $RESOURCE_GROUP_NAME --vnet-name Study4Dev-JE-VNet --name Study4DevAKS-Node --query id -o tsv)

ACR_ID=$(az acr show --name study4dev --resource-group study4dev-je --query id -o tsv)

# 建立 AKS ( System Node Pool )
az aks create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --kubernetes-version 1.19.0 \
    --zones 1 2 3 \
    --max-pods 40 \
    --node-vm-size Standard_Ds2_v2 \
    --node-count 3 \
    --generate-ssh-keys \
    --enable-cluster-autoscaler \
    --min-count 3 \
    --max-count 3 \
    --nodepool-name system \
    --enable-managed-identity \
    --enable-aad \
    --enable-azure-rbac \
    --aad-admin-group-object-ids $AAD_GROUP_ID \
    --aad-tenant-id $TENANT_ID \
    --network-plugin azure \
    --vnet-subnet-id $SUBNET_ID \
    --service-cidr 10.99.98.0/23 \
    --dns-service-ip 10.99.98.10 \
    --docker-bridge-address 172.17.0.1/16 \
    --dns-name-prefix study4dev-aks \
    --load-balancer-sku standard\
    --network-policy azure \
    --attach-acr $ACR_ID \
    --enable-addons monitoring \
    --workspace-resource-id $WORKSPACE_ID \
    --node-resource-group Study4Dev-JE-AKS-Study4Dev-JE-AKSResource \
    --aks-custom-headers EnableAzureDiskFileCSIDriver=true,CustomizedUbuntu=aks-ubuntu-1804,ContainerRuntime=containerd

#啟動 VNode
az aks enable-addons \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --addons virtual-node \
    --subnet-name Study4DevAKS-VNode

# 新增 User Node Pool ( 不使用 可用性區域 , 搭配 PPG )

MY_PPG_RESOURCE_ID=/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/Study4Dev-JE/providers/Microsoft.Compute/proximityPlacementGroups/Study4Dev-JE-PPG

az aks nodepool add \
    --cluster-name $CLUSTER_NAME \
    --name defaultapp \
    --resource-group $RESOURCE_GROUP_NAME \
    --enable-cluster-autoscaler \
    --node-count 3 \
    --max-count 3 \
    --min-count 3 \
    --max-pods 40 \
    --kubernetes-version 1.19.0 \
    --mode User \
    --node-vm-size Standard_D4as_v4 \
    --zones 1 \
    --ppg $MY_PPG_RESOURCE_ID \
    --node-osdisk-size 40 \
    --node-osdisk-type Ephemeral \
    --aks-custom-headers EnableAzureDiskFileCSIDriver=true,CustomizedUbuntu=aks-ubuntu-1804,ContainerRuntime=containerd

完成!

開始建立 - UI

底下流程會敘述 UI 的方式建立,但使用 UI 的方式,會有很多東西設定不到,而這邊會的 UI 設定,只會設定一個 System Node Pool,若有需要再加上 User Node Pool,自行透過 UI 或是上述 az cli 進行建立。

找到 Azure Kubernetes Service

2020 05 27 17 36 00

進行基本的設定,這邊要注意的就是 VM 大小了,建完後,就不可以改了 ( 只能改數量 ),這邊也可以設定可用性區域,可以依據自己的需求看要不要設定可用性區域。

2020 05 27 17 36 50

接著,這邊要決定是否要啟用虛擬節點,通常小弟我會在這邊就直接啟用,後續也可以透過 AZ Cli 來啟用,其次,VM 擴展集也會在這邊勾起來,未來可以讓 Node 自動擴展。

2020 05 27 17 38 23

這邊比較需要注意的,以前只有服務主體可以選擇,也就是說,以前選擇服務主體後,他會自動的幫忙建立一個 Service Principal,而現在,多了一個更方便的選項,就是系統指派的受控識別,選擇此功能,可以讓 AKS 服務自己來管理,也因此,不會多一個 Service Principal 了,甚至砍掉 AKS 的時候,以前會留下 Service Principal,使用受控識別,也不用自己處理了,砍掉的時候,會將受控識別一起砍掉。

RBAC 是一定要起用的,後面有太多的功能會和 RBAC 相依。

另外,目前 UI 也提供了 AKS 管理的 AAD 功能,可以透過此功能,讓 AAD Group 的人,才能管理 AKS,有需要的話可以啟用。

2020 10 21 11 51 50

接下來是網路設定,通常配置如下就可以,提供 Node 使用的網段,VNode 使用的網段,還有 AKS 自己使用的網段,通常我都保持預設。

而需要注意的就是下面那三個,目前私人叢集還有一些問題,所以我目前還不敢打開 XDDD 而網路原則我習慣用 Azure,HTTP 應用程式路由通常是拿來測試使用,再比較正式的環境上,通常會搭配 Ingress 等服務,所以通常會將此功能關閉。

2020 05 27 17 40 30

最後,現在可以和其他服務串再一起,也就是一開始設定 ACR 和 Log Analytics,這邊選定的 ACR,會直接在 ACR 裡面加上受控識別,來讓 AKS 未來可以撈取,當然不設定也可以,只是以後要自己加上去。

最後,這邊也多了一個 Azure 原則可以選,未來可以透過 Azure 派發原則到 AKS 上,不過這塊也還好,後續還是可以透過 Azure Arc 加上去。

2020 10 21 11 57 07

然後就完成了~

啟用 SLA 99.95

若有需要,也可以在最後階段啟用 SLA

az aks update --resource-group study4dev-je --name aks-study4dev-je --uptime-sla

進行測試

完成後,我們希望能透過 Kubectl get nodes,來取得 node 資訊,來驗證是否建置完成。

而在開始前,我們需要先給我自己 Azure Kubernetes Service RBAC Cluster Admin 的權限。

請注意,一定要先設定 IAM,不然的話下載的 Kubeconfig 可能會權限不對,造成無法訪問。

2020 10 21 18 58 39

然後再下載 kubeconfig 檔案。

# 下載驗證
az aks get-credentials --name MyManagedCluster --resource-group MyResourceGroup

# 取得 node 資訊
kubectl get nodes

順利完成!

後記

老實說,建立一個 AKS 不算容易的事情呢....因為建置的過程中,有很多參數是建立完後,就不能再調整的,細節也很多...

當然,在建構這文章的時候,也發現,已經拉的有點太長,但把這些細節分成各個文章,小弟我又怕會讓很多人覺得,建置 AKS 很簡單就完成的錯覺,然後用到正式環境的時候,要改就來不及了 QQ。

所以後續還是決定先整併成一篇吧....

( 好吧,不管怎樣,還是比地端好了... )。

參考資料

Sky & Study4.TW