k8s學習

docker的出現解決了微服務的部署問題，k8s的出現解決了docker的叢集問題

https://www.cnblogs.com/wangyongqiang/articles/12564373.html

----->kubernetes.io/zh/docs/tutorials/kubernetes-basics/

Master 管理叢集，Node 用於託管正在執行的應用。

    Master 負責管理整個叢集。 Master 協調叢集中的所有活動，例如排程應用、維護應用的所需狀態、應用擴容以及推出新的更新。

    Node 是一個虛擬機器或者物理機，它在 Kubernetes 叢集中充當工作機器的角色 每個Node都有 Kubelet , 它管理 Node 而且是 Node 與 Master 通訊的代理。 Node 還應該具有用於??處理容器操作的工具，例如 Docker 或 rkt 。處理生產級流量的 Kubernetes 叢集至少應具有三個 Node 。

    在 Kubernetes 上部署應用時，您告訴 Master 啟動應用容器。 Master 就編排容器在叢集的 Node 上執行。 Node 使用 Master 暴露的 Kubernetes API 與 Master 通訊。終端使用者也可以使用 Kubernetes API 與叢集 互動。

    Deployment 指揮 Kubernetes 如何建立和更新應用程式的例項。建立 Deployment 後，Kubernetes master 將應用程式例項排程到叢集中的各個節點上。建立應用程式例項後，Kubernetes Deployment 控制器會持續監視這些例項。 如果託管例項的節點關閉或被刪除，則 Deployment 控制器會將該例項替換為群集中另一個節點上的例項。 這提供了一種 自我修復機制來解決機器故障維護問題。 擴充套件 Deployment 將建立新的 Pods，並將資源排程請求分配到有可用資源的節點上，收縮 會將 Pods 數量減少至所需的狀態。Kubernetes 還支援 Pods 的自動縮放。 除了應用容器，Pod 還可以包含在 Pod 啟動期間執行的 ( Init 容器是一種特殊容器，在   內的應用容器啟動之前執行。Init 容器可以包括一些應用映象中不存在的實用工具和安裝指令碼) 。 你也可以在叢集中支援  ( 臨時容器與其他容器的不同之處在於，它們缺少對資源或執行的保證，並且永遠不會自動重啟， 因此不適用於構建應用程式, 當由於容器崩潰或容器映象不包含除錯工具而導致  kubectl exec  無用時， 臨時容器對於互動式故障排查很有用。)的情況外，為除錯的目的注入臨時性容器。

    建立 Deployment 時, Kubernetes 新增了一個 Pod 來託管你的應用例項。 Pod 是 Kubernetes 抽象出來的，表示一組一個或多個應用程式容器（如 Docker）， Pod 的共享上下文包括一組 Linux 名字空間、控制組（cgroup）和可能一些其他的隔離 方面，即用來隔離 Docker 容器的技術。 在 Pod 的上下文中，每個獨立的應用可能會進一步實施隔離。 這些 共享資源包括:

• 共享儲存，當作卷(Pod 中的所有容器都可以訪問該共享卷，從而允許這些容器共享資料)

• 網路，作為唯一的叢集 IP 地址( 共享網路名字空間 pod中的多個容器有一樣的ip,mac和port, Pod 內  的容器可以使用  localhost  互相通訊)

• 有關每個容器如何執行的資訊，例如容器映像版本或要使用的特定埠。

重啟 Pod 中的容器不應與重啟 Pod 混淆。 Pod 不是程式，而是容器執行的環境。 在被刪除之前，Pod 會一直存在。

     通常你不需要直接建立 Pod，甚至單例項 Pod。 相反，你會使用諸如   或   這類工作負載資源 來建立 Pod。 每個 Pod 都有一個唯一的 IP 地址，但是如果沒有 Service ，這些 IP 不會暴露在群集外部。你也可以在建立 Deployment 的同時用 --expose建立一個 Service 。

更新應用程式

使用者希望應用程式始終可用，而開發人員則需要每天多次部署它們的新版本。在 Kubernetes 中，這些是通過滾動更新（Rolling Updates）完成的。 滾動更新 允許通過使用新的例項逐步更新 Pod 例項，零停機進行 Deployment 更新。新的 Pod 將在具有可用資源的節點上進行排程。

1、應用部署方式：

    傳統的應用部署方式是通過外掛或指令碼來 安裝應用。這樣做的缺點是應用的執行、配置、管理、所有生存週期將與當前作業系統繫結，這樣做並不利於應用的升級更新/回滾等操作，當然也可以通過建立虛擬機器的方式來實現某些功能，但是虛擬機器非常重，並不利於可移植性。
優勢：：

    新的方式是通過 部署容器方式實現，每個容器之間互相隔離，每個容器有自己的檔案系統 ，容器之間程式不會相互影響，能區分計算資源。相對於虛擬機器，容器能快速部署，由於容器與底層設施、機器檔案系統解耦的，所以它能在不同雲、不同版本作業系統間進行遷移。容器佔用資源少、部署快，每個應用可以被打包成一個容器映象，每個應用與容器間成一對一關係也使容器有更大優勢，使用容器可以在build或release 的階段，為應用建立容器映象，因為每個應用不需要與其餘的應用堆疊組合，也不依賴於生產環境基礎結構，這使得從研發到測試、生產能提供一致環境。類似地，容器比虛擬機器輕量、更“透明”，這更便於監控和管理。

2、pod內部容器之間通訊

一組容器的集合pod,pod中的容器共享網路名稱空間與儲存，這種情況下容器通訊比較簡單，因為 k8s pod內部容器是共享網路空間的，所以容器直接可以使用localhost訪問其他容器。k8s在啟動容器的時候會先啟動一個pause容器，這個容器就是實現這個功能的。

Pod 是 Kubernetes 中最基本的構造模組，是 Kubernetes 物件模型中你可以建立或部署的 最小、最簡單元。你不可以在同一 Pod 中部署 Windows 和 Linux 容器。 Pod 中的所有容器都會被排程到同一節點（Node），而每個節點代表的是一種特定的平臺 和體系結構。

3、service實現了後端pod的負載均衡,Service Cluster IP （ 只能在叢集內訪問）是一個虛擬 IP，是由 Kubernetes 節點上的 iptables 規則管理的。 Cluster 的每一個節點都配置了相同的 iptables 規則，這樣就確保了整個 Cluster 都能夠通過 Service 的 Cluster IP 訪問 Service。

LoadBalancer（metallb）

LB後端繫結每個節點的 NodePort，LB 接收外界流量，轉發到其中一個節點的 NodePort 上，再通過 Kubernetes 內部的負載均衡，使用 iptables 或 ipvs 轉發到 Pod。

—— IPVS 是 LVS 專案的一部分，是一款執行在Linux kernel當中的4層負載均衡器，效能異常優秀。 根據 這篇文章 的介紹，使用調優後的核心，可以輕鬆處理每秒10萬次以上的轉發請求。目前在中大型網際網路專案中， IPVS被廣泛的使用，用於承接網站入口處的流量。

4、k8s statefulSet 有狀態應用和無狀態應用區別

無狀態服務：

    就是沒有特殊狀態的服務,各個請求對於伺服器來說統一無差別處理,請求自身攜帶了所有服務端所需要的所有引數(服務端自身不儲存跟請求相關的任何資料,不包括資料庫儲存資訊)。無狀態的伺服器程式，最著名的就是WEB伺服器。每次HTTP請求和以前都沒有啥關係，只是獲取目標URI。得到目標內容之後，這次連線就被殺死，沒有任何痕跡。在後來的發展程式中，逐漸在無狀態化的過程中，加入狀態化的資訊，比如COOKIE。服務端在響應客戶端的請求的時候，會向客戶端推送一個COOKIE，這個COOKIE記錄服務端上面的一些資訊。客戶端在後續的請求中，可以攜帶這個COOKIE，服務端可以根據這個COOKIE判斷這個請求的上下文關係。COOKIE的存在，是無狀態化向狀態化的一個過渡手段，他通過外部擴充套件手段，COOKIE來維護上下文關係。

有狀態服務：

    有狀態服務 可以說是需要資料儲存功能的服務、或者指多執行緒型別的服務，佇列等。（mysql資料庫、kafka、zookeeper等）每個例項都需要有自己獨立的持久化儲存，並且在k8s中是通過申明模板來進行定義。持久卷申明模板在建立pod之前建立，繫結到pod中，模板可以定義多個。

5、Kubernetes 對 Windows 的支援

    若要在 Kubernetes 中啟用對 Windows 容器的編排，只需在現有的 Linux 叢集中包含 Windows 節點。在 Kubernetes 上排程   中的 Windows 容器與呼叫基於 Linux 的容器一樣簡單、一樣容易。為了執行 Windows 容器，你的 Kubernetes 叢集必須包含多個作業系統， 控制面 節點執行 Linux， 工作節點則可以根據負載需要執行 Windows 或 Linux。 Windows Server 2019 是唯一被支援的 Windows 作業系統.

--->kubernetes.io/zh/docs/setup/production-environment/windows/