正文

在開始建置之前，今天先來聊聊我自己對Kubernetes的想法，Kubernetes是一套container orchestration platform眾所皆知，而其前世今生的緣由就不多談了，網路上已經有很多相關的資料可以查詢。

我自己認為Kubernetes有趣的地方在於，Kubernetes中大部分的內容、Resources、APIs等......都是基於declarative、基於標準來建立的。而這樣的方式直接與間接促成了強大的共通性。這也是為什麼常常有人說學一套Kubernetes，可以穿梭地端(自建或vendor support)與雲端(AKS、EKS、GKE......)，儘管這未必完全正確。

這樣提及強大的共通性，其實指的是在platform上operator的這一塊，而非是system architecture這一塊。也就是說如果找10個人來建置Kubernetes Cluster、那很高的機率就會建出10個不太一樣的Cluster、但對於Cluster的使用來者來說卻又是高度互通的。

為什麼會說每個人建的Kubernetes，很容易都會產生些許的落差呢？

以核心元件(kubelet、kube-scheduler、kube-apiserver、kube-controller-mangement、kube-proxy(iptables/ipvs)、etcd.....)來說功能倒是大同小異。

但從大方向來說，第一步面臨到可能就是該選擇哪個的Opertaion System?，作業系統百百種支援Kubernetes建置的亦不在少數。接著是要以何種方式建立？Container、Binary、Kubeadm，還有如核心元件是不是要用static pod等等......議題，或是整個直接使用CNCF Certified installer的project(open source or subscription)，或著直接使用Cloud PaaS，這些其實都是能夠納入考量的環節。

再從細一點的方向來說，Kubernetes著重在interface的標準、提供interface、只要符合實作便能為之所用，這也讓建置者更加選擇障礙了XD，三個著名的標準分別要選擇的是：

• CRI (Container Runtime Interface)
  也就是選擇容器執行的agent，現行來說也有很多選擇，如Containerd、CRI-O、Kata Container等等......

  要注意Docker並非CRI的一環，Docker是透過Dockershim才符合CRI的，而Dockershim目前也將面臨deprecated的問題。

• CNI (Container Network Interface)
  CNI指的大概就是Cluster中，Container與Container之間的網路交換是基於那些方式&Protocol，與host之間的關係去實作的。在實務上我們會根據一些特性需求或環境限制去決定要使用那個CNI。

  過去學習時看過別人整理的CNI清單(不確定後續有沒有持續更新)有需要可以參考。

• CSI (Container storage interface)
  指的就是Cluster中與Storage之間的行為與關係，為了讓服務(pod)能夠去存取不同的storage架構、自由的叫用空間資源，而需要實作統一的介面。

此外像是LoadBalancer type這種東西也需要做抉擇，也許是cloud vendor support、也許是地端open source solution，也許是地端hardware vendor support......諸如此類好像還有很多東西沒提到，不過就先這樣吧~

就像汽車一樣，不一樣的鋼板、螺絲、引擎，輪胎.......合成的車車，最終只要駕駛有駕照都可以上路。

閒聊

今天這一篇好像全部都是閒聊的範圍呢XD，選擇很多很複雜、同時也因為選擇很多而生動有趣。常常會看到有些人說，你真的需要Kubernetes嗎? 阿我就做做homelab阿~

等等要來去打AZ了，希望明天還能繼續發文。