在昨天我們談完如何使用Azure Container Registry異地複寫建立多份Container Image後
我們來聊聊如何企業中使用Azure Kubernetes Service,我們會談到Azure
Kubernetes Service Cluster,部署YAML檔案,整合Azure Container
Registry以部署container images。
Cluster是基於Node的 , Kubernetes Cluster中有兩種類型的Node可以提供特定
的功能。
-Control plane nodes：這些Node承載Cluster Control plane,並保留用於
控制Cluster服務。他們負責提供您和所有其他Node用於通信的API。這些Node上
沒有部署或計劃任何工作負載。
-Nodes：這些Node負責執行自定義工作負載和應用程式。
-Single control plane and multiple nodes
Single control plane and multiple nodes是最常見的架構模式。此模式最
容易部署，但不能為Cluster的cluster's core management提供高可用性。
儘管可用性不如其他架構好，但這種架構對於大多數情況而言應該足夠了。如果
您要處理生產方案，則此體系結構可能不是最佳解決方案。
-Single control plane and a single node
Single control plane and a single node結構是先前體系結構的變體，並用
於開發環境中。此體系結構僅提供一個同時承載control plane和Work Node,在
測試或嘗試不同的Kubernetes概念時，它很有用。Single control plane and
a single node限制了Cluster擴展，並使該體系結構不適用於生產使用。
當建立新的AKS Cluster時，需要設定幾個不同的資訊項目。 每個項目都會影響
Cluster的最後設定。
這些項目包括：
-Node pools
-Node count
-Automatic routing
你要建立「 node pools 」，以分組 AKS Cluster中的Node。 當建立Node
Pool時，您要為node pool.中的每個Node指定VM大小,node pool會使用virtual
machine scale sets作為基礎結構，以供Cluster調整node pool中的node數目
。 在node pool中建立的新Node，其大小一律與您在建立node pool時所指定的
大小相同。
Node count是Cluster在Node Pool中將擁有的Node數目,Node是Azure VM,你
可以變更其大小和計數以符合使用模式。
根據預設，Kubernetes Cluster會封鎖所有的外部通訊。 例如，假設你要部署
可供所有用戶端存取的網站,你必須以手動方式建立「輸入」，其包含允許連入
用戶端連線到該特定服務的例外狀況。 此設定需要與網路相關的變更，以將要求
從用戶端轉送到叢集上的內部 IP，最後再送達應用程式。 視特定需求而定，
此程序可能會很複雜。
輸入控制器可供將應用程式部署至全球並予以公開，卻不必設定與網路相關的服務。
Ingress controllers會建立反向 Proxy 伺服器，其會自動允許從單一DNS輸出
提供所有要求,你不必在每次部署新服務時建立 DNS 記錄,輸入控制器會負責處理
。 當新的輸入部署到Cluster時，Ingress controller會在Azure受控DNS區域
上建立一筆新記錄，並將其連結至現有的負載平衡器。 此功能可供透過網際網路
輕鬆存取資源，而不需要額外的設定。
Kubernetes Pod 會將容器和應用程式分組成邏輯結構。 這些 Pod 沒有智慧，
且由一或多個應用程式Container所組成,其每一個都有一個 IP 位址、網路規則
和公開的連接埠。
Kubernetes manifest files可供以宣告方式使用YAML 格式來描述工作負載，
並簡化 Kubernetes 物件管理,假設必須手動部署工作負載,你必須考慮和管理
數個層面,你必須建立Container、選取特定的Node、將Node包在Pod 中、
執行 Pod、監視執行等,manifest files範例如下:
# deployment.yaml
# ...
spec:
selector:
matchLabels:
app: contoso-website
# ...
容器的網路設定為暫時性。 容器的設定和容器內資料不會在執行之間持續。 在
刪除容器之後，除非設定使用磁碟區，否則便會遺失所有資訊。 這同樣適用於
容器的網路設定和任何指派給容器的 IP 位址。
Kubernetes 服務是一種工作負載，其會抽象化網路工作負載的 IP 位址。
Kubernetes 服務會作為負載平衡器，並使用連接埠轉送規則，將流量重新導向
到特定連接埠的特定連接埠。
-ClusterIP：這個值只會在內部公開應用程式。 此選項允許服務作為連接埠
轉寄站，並會在Cluster內部開放使用服務。 根據預設在省略時會使用這個值。
-NodePort：這個值會向外部公開服務。 其會為每個Node指派能回應該服務
的靜態連接埠,透過 nodeIp:port 存取時，節點會自動將要求重新導向到
ClusterIP 類型的內部服務。 此服務接著會將要求轉送至應用程式。
-LoadBalancer：這個值會使用 Azure 的負載平衡解決方案向外部公開
服務。 建立時，這個資源會啟動 Azure 訂用帳戶內的 Azure Load
Balancer資源。 此外，這個類型會自動建立 NodePort 服務，負載平衡器
的流量會重新導向到這個服務，且會建立 ClusterIP 服務以在內部進行轉送。
-ExternalName：這個值會透過 CNAME 記錄使用 DNS 解析來對應
服務。 您可以使用這個服務類型來將流量導向位於 Kubernetes Cluster
外部的服務。
Ingress會向Cluster內部的服務公開來自Cluster外部的 HTTP 和 HTTPS 流量
的路由,你會使用ingress rules來定義ingress routes。 若沒有定義這些route
，Kubernetes Cluster會拒絕所有傳入流量。
假設想要允許用戶端透過 http://contoso.com 網址存取網站。 若要讓
用戶端存取Cluster內部的應用程式，則Cluster必須回應網站的 CNAME，並將要求
路由到相關的 Pod。
以下為ingress.yaml範例檔內容
#ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: contoso-website
annotations:
kubernetes.io/ingress.class: addon-http-application-routing
spec:
rules:
- host: contoso.<uuid>.<region>.aksapp.io
http:
paths:
- backend: # How the ingress will handle the requests
serviceName: contoso-website # Which service the request will be forwarded to
servicePort: http # Which port in that service
path: / # Which path is this rule referring to
手把手建立Azure Kubernetes Service Cluster步驟
手把手建立Azure Kubernetes Service Cluster部署應用程式步驟
https://docs.microsoft.com/zh-tw/learn/modules/aks-deploy-container-app/5-exercise-deploy-app
手把手啟用應用程式的網路存取步驟
https://docs.microsoft.com/zh-tw/learn/modules/aks-deploy-container-app/7-exercise-expose-app
Day27教學教材：
https://docs.microsoft.com/zh-tw/learn/modules/aks-deploy-container-app/
iThome鐵人賽
看影片追技術