一、前言
二、kubernetes和雲原生
Cloud Native 直接翻譯為雲原生，雲原生官網：https://www.cncf.io/
CNCF，表示 Cloud Native Computing Foudation ，翻譯為 雲原生計算基金會，屬于Linux基金會，初衷是圍繞“雲原生”服務雲計算，維護和內建開源技術，支援編排容器化微服務架構應用。
時至今日，Kubernetes逐漸已經成為雲原生失敗的基礎設定。
Docker是容器化技術，Kubernetes是一種容器編排技術，之前還有一個Docker Swarm也是一種容器編排技術，但是已經不被使用。
雲原生這三字，雲表示在雲伺服器上部署，原生的意義就是 部署在一個陌生的環境，像部署在自己熟悉的環境上，類似于 JVM 一次編譯，到處運作。
要實作雲原生這個一次編譯，到處運作，涉及很多元件，從小到大，Docker是容器化部署，Kubernetes是容器編排工具(Docker Swarm也是)，對Docker進行編排，就是通過 yaml 檔案來實作；Helm是包管理工具，對Kubernetes的 yaml 進行編排，Helm 中通過 if 塊可以用 values.yaml 檔案中變量 精确的決定 kubernetes yaml 檔案中哪一行是否需要被運用。
kubernetes是雲原生時代基礎設施，如下圖：
上圖表示，将應用部署在Kubernetes叢集上，這樣 應用就可以在 公有雲 私有雲 混合雲 上無縫遷移。應用包括用于資料存儲的有狀态的應用，使用StatefulSet部署，不用于資料存儲的無狀态的應用，使用Deployment部署。
Kubernetes四種部署方式：Deployment StatefulSet DaemonSet Job(CronJob)
ReplicaSet 存在的意義就是 replicas 這個屬性 how many Pods
Deployment 存在的意義就是無狀态
StatefulSet 存在的意義就是有狀态
DaemonSet 存在的意義就是日志 監控
Job(CronJob) 存在的意義是一次性任務和定時任務
小結：雲原生這三字，雲表示在雲伺服器上部署，原生的意義就是部署在一個陌生的環境，像部署在自己熟悉的環境上，類似于 JVM 一次編譯，到處運作。容器化部署實作了這個目标，Kubernetes是一種容器編排技術，是以說Kubernetes是雲原生時代基礎設施，這就是Docker、Kubernetes與雲原生的關系。
三、從Docker Swarm到Kubernetes
kubernetes本質是一個容器編排技術，docker内置的 docker swarm 也是做容器編排的，都是管理和編排Docker Container容器，但是對于容器編排，k8s更加優秀，是現在的主流。
重點學習kubernetes，docker swarmy了解即可，知道有這個東西即可。
Github上：https://github.com/kubernetes/kubernetes
docker swarm 架構設計（了解即可）
四、kubernetes元件和架構簡介
4.1 kubernetes元件
本節官方位址（K8S Docs Concepts）：https://kubernetes.io/docs/concepts/
4.1.1 Container
(1)先以container為起點，k8s既然是容器編排工具，那麼一定會有container
4.1.2 Pod
那k8s如何操作這些container呢？從感性的角度來講，得要有點逼格，k8s不想直接操作container，因為操作container的事情是docker來做的，k8s中要有自己的最小操作機關，稱之為Pod說白了，Pod就是一個或多個Container的組合
官方解釋 ：https://kubernetes.io/docs/concepts/workloads/pods/pod/
A Pod (as in a pod of whales or pea pod) is a group of one or more containers (such as Docker containers), with shared storage/network, and a specification for how to run the containers.
4.1.3 ReplicaSet
那Pod的維護誰來做呢？那就是ReplicaSet，通過selector來進行管理
官方解釋 ：https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/
A ReplicaSet is defined with fields, including a selector that specifies how to identify Pods it can acquire, a number of replicas indicating how many Pods it should be maintaining, and a pod template specifying the data of new Pods it should create to meet the number of replicas criteria.
4.1.4 Deployment
Pod和ReplicaSet的狀态如何維護和監測呢？Deployment
官網是如何描述的 ：https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
A Deployment controller provides declarative updates for Pods and ReplicaSets. You describe a desired state in a Deployment, and the Deployment controller changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.
4.1.5 Label與Selector
不妨把相同或者有關聯的Pod分門别類一下，那怎麼分門别類呢？Label
官網是如何描述的 ：https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
Labels are key/value pairs that are attached to objects, such as pods.
label 可以在任何類型的資源上，然後用 selector 選擇器來選擇，比如pod、node，都可以打标簽。
4.1.6 Service
具有相同label的service要是能夠有個名稱就好了，Service
看官網上怎麼說 ：https://kubernetes.io/docs/concepts/services-networking/service/
An abstract way to expose an application running on a set of Pods as a network service.
With Kubernetes you don’t need to modify your application to use an unfamiliar service discovery mechanism. Kubernetes gives Pods their own IP addresses and a single DNS name for a set of Pods, and can load-balance across them.
4.1.7 Node
上述說了這麼多，Pod運作在哪裡呢？當然是機器咯，比如一台centos機器，我們把這個機器稱作為Node.
看看官網怎麼說 ：https://kubernetes.io/docs/concepts/architecture/nodes/
A node is a worker machine in Kubernetes, previously known as a minion. A node may be a VM or physical machine, depending on the cluster. Each node contains the services necessary to run pods and is managed by the master components.
4.1.8 多Node節點組成的叢集
難道隻有一個Node嗎？顯然不太合适，多台Node共同組成叢集才行嘛
畫個圖表示一下咯，最好能把之前的Label，Service也一起畫上去，整體感受一下
此時，我們把目光轉移到由3個Node節點組成的Master-Node叢集
4.2 kubernetes架構
這個叢集要配合完成一些工作，總要有一些元件的支援吧？接下來我們來想想有哪些元件，然後畫一個相對完整的架構圖
01-總得要有一個操作叢集的用戶端，也就是和叢集打交道
回答：kubectl，每個叢集node上都可以使用kubectl，隻要 /root/.kube/config 檔案。
02-請求肯定是到達Master Node，然後再配置設定給Worker Node建立Pod之類的 關鍵是指令通過kubectl過來之後，是不是要認證授權一下？
回答：Master Node上的apiserver，/etc/kubernetes/manifests目錄下有 kube-apiserver.yaml 檔案
03-請求過來之後，Master Node中誰來接收？
回答：APIServer
04-API收到請求之後，接下來調用哪個Worker Node建立Pod，Container之類的，得要有排程政策
回答：Master節點的上的靜态Pod Scheduler 來負責。
官方資料：https://kubernetes.io/docs/concepts/scheduling/kube-scheduler/
05-Scheduler通過不同的政策，真正要分發請求到不同的Worker Node上建立内容，具體誰負責？
回答： Controller Manager
06-Worker Node接收到建立請求之後，具體誰來負責？
回答：Kubelet服務，最終Kubelet會調用Docker Engine，建立對應的容器[這邊也反應出一點，在Node上需要有Docker Engine，才能建立維護容器]
07-會不會涉及到域名解析的問題？
回答：主節點上的CoreDNS服務
08-是否需要有監控面闆能夠監測整個叢集的狀态？
回答：Dashboard
09-叢集中這些資料如何儲存？
回答：分布式存儲 ETCD
10-至于像容器的持久化存儲，網絡等可以聯系一下
回答：Docker中的内容
11- 不妨用一個圖檔總結整個流程
回答：
這個圖檔上告訴我們：
(1) 對于主節點來說，kubectl 連接配接主節點的所有操作，都必須通過 apiserver 的認證、授權、準入控制，才能正常進行；
(2) 四個靜态Pod: apiserver controllerManager scheduler etcd 都是運作在主節點上，apiserver用于認證、打開外網、rbac授權、controllerManager用來管理各種controller，包括 replicaset deployment statefulset daemonset job/cronjob，scheduler決定某個Pod配置設定哪個Node上，etcd作為配置中心存放資料。
(3) dashboard 提供簡單的可視化，完整的可視化還是需要 Prometheus+Grafana 監控
(4) 預設情況下主節點有污點Taint，不配置設定Pod運作
(5) 每個節點上都會有 kubelet 服務，可以使用 systemctl status kubelet 檢視
每個節點上都會有 docker 服務 ，可以使用 systemctl status docker 檢視，其作用是将鏡像image運作起來變為容器Container
每個節點上都會有 kube-proxy 容器 ，可以使用 kubectl get pod -o wide -n kube-system 檢視，其作用是将 kubectl 發送到 service 的請求路由到 具體的Pod 上；
每個節點上都會有 calico/fluend 容器 ，可以使用 kubectl get pod -o wide -n kube-system 檢視，其作用Node之間網絡通信；
叢集一些節點上有 dns 容器，可以使用 kubectl get pod -o wide -n kube-system 檢視，其作用使用将 serviceName.namespace 解析為 叢集内ip，也可以解析 外網域名，通過配置 /etc/resolv.conf nameserver域名解析伺服器清單 和 /etc/hosts 本地域名解析檔案來實作。
再來一張橫向架構圖圖，加深了解，如下：
五、尾聲
從雲原生到kubernetes，完成了。