Day10，先来聊聊我的Kubernetes看法

正文

在开始建置之前，今天先来聊聊我自己对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了，希望明天还能继续发文。