昨天簡單介紹並快速體驗了Kubernetes的基本功能，今天開始就要來深入一點去了解。

Kubernetes Clusters

首先我們昨天成功建立了Kubernetes Clusters，但是Clusters是甚麼呢?他的結構又是如何呢?
Kubernetes Cluster是一組用來執行容器化應用程式(containerized application)的節點機器，透過協調連接單個unit在一起工作的高可用性計算機集群。聽不懂嗎？沒關西，看張圖就會瞭解了。
如圖(一)中表示Clusters具有至少一個Master作為協調，以及多個Node用來運行多個應用程序的程序，因而稱作節點機器。

圖(一) Cluster架構

Kubernetes會自動將容器化的應用程序部署到集群，而無需將它們專門綁定到單個機器。透過這種方式部屬可以更加有彈性，且Kubernetes以更有效的方式自動在整個集群中分配和調度應用程序容器。能夠輕鬆達成效能及資源利用最大化。

剛剛提到了master負責管理群集，Node則是各個單獨的VM用來運行APP。除此之外仔細看得話，每個節點上都具有一個Kubelet，Kubelet是甚麼呢？
Kubelet是用於管理節點並與master通信的代理人，如果Master是老闆Kubelet就是經理、主管。而結點上還有Docker則是用來處理container的工具。
至於具體上Kubelet是怎麼溝通呢？Node會透過Master公開的Kubernetes API來與Master通信，而使用者也就是我們，也可以透過Kubernetes API直接操作Clusters，而不需要直接進到Clusters裡面，算是很方便的單一介面呢。

Deployments

還記得怎麼開始建立Kubernetes Clusters嗎？

minikube start --driver=docker

快速建立好Clusters之後就可以部屬容器化的APP了，但是要如何部屬呢？首先需要先創建一個部屬Kubernetes的配置，透過配置Kubernetes才知道如何創建和更新應用程序。

創建一個簡單API範例

kubectl create deployment kubernetes-bootcamp --image=gcr.io/google-samples/kubernetes-bootcamp:v1

而在我們創建完應用程序後，K8s會持續監視這些應用程序(with K8s Deployment Controller)。如果運行應用程序的節點出現故障或被刪除，便會將應用程序替換為群集中另一個節點上的應用程序。也就是昨天提到K8s的特點之一自我修復功能(self-healing)。
圖(二)為部屬完容器化APP後的Clusters結構。

圖(二) 部屬容器化APP

Proxy代理

正常來說，這個時候外部的我們是訪問不到Clusters的應用程序，除了可以使用昨天提到的expose來公開，也可以使用接下來會運用的技巧，我們可以使用kubectl命令創建一個proxy，並透過proxy將通信轉發到Clusters的專用網絡中，當然這樣是比較麻煩啦，畢竟要一直監聽。

kubectl proxy

執行完的輸出

Starting to serve on 127.0.0.1:8001

接下來我們就能直接訪問localhost的8001端來訪問APP了。
訪問http://localhost:8001/api會得到

{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "172.17.0.3:8443"
    }
  ]
}

總結:

明天會來學習Kubernetes如何乘載應用程序並如何觀察，以及公開APP的理論及方法。

參考文獻:
Kubernetes官方文件