應用部署方式演變

在部署應用程序的方式上，主要經歷了三個時代：

傳統部署

互聯網早期，會直接將應用程序部署在物理機上

優點：簡單，不需要其它技術的參與缺點：不能為應用程序定義資源使用邊界，很難合理地分配計算資源，而且程序之間容易產生影響

虛擬化部署

可以在一臺物理機上運行多個虛擬機，每個虛擬機都是獨立的一個環境

優點：程序環境不會相互產生影響，提供了一定程度的安全性缺點：增加了操作系統，浪費了部分資源

容器化部署

與虛擬化類似，但是共享了操作系統

優點：可以保證每個容器擁有自己的文件系統、CPU、內存、進程空間等運行應用程序所需要的資源都被容器包裝，并和底層基礎架構解耦容器化的應用程序可以跨云服務商、跨Linux操作系統發行版進行部署

容器化部署方式給帶來很多的便利，但是也會出現一些問題，比如說：

• 一個容器故障停機了，怎么樣讓另外一個容器立刻啟動去替補停機的容器
• 當并發訪問量變大的時候，怎么樣做到橫向擴展容器數量

這些容器管理的問題統稱為容器編排問題，為了解決這些容器編排問題，就產生了一些容器編排的軟件：

• Swarm：Docker自己的容器編排工具
• Mesos：Apache的一個資源統一管控的工具，需要和Marathon結合使用
• Kubernetes：Google開源的的容器編排工具
  

K8s簡介

K8s全稱叫做kubernetes。是一個全新的基于容器技術的分布式架構領先方案，是谷歌嚴格保密十幾年的秘密武器----Borg系統的一個開源版本，于2014年9月發布第一個版本，2015年7月發布第一個正式版本。

kubernetes的本質是一組服務器集群，它可以在集群的每個節點上運行特定的程序，來對節點中的容器進行管理。目的是實現資源管理的自動化，主要提供了如下的主要功能：

• 自我修復：一旦某一個容器崩潰，能夠在1秒中左右迅速啟動新的容器
• 彈性伸縮：可以根據需要，自動對集群中正在運行的容器數量進行調整
• 服務發現：服務可以通過自動發現的形式找到它所依賴的服務
• 負載均衡：如果一個服務起動了多個容器，能夠自動實現請求的負載均衡
• 版本回退：如果發現新發布的程序版本有問題，可以立即回退到原來的版本
• 存儲編排：可以根據容器自身的需求自動創建存儲卷

K8s架構描述

一個K8s集群主要由控制（master）節點和工作（node）節點構成，每個節點上都會安裝不同的組件。

master節點：

master節點是整個集群的控制平面，負責集群的決策、管理，其由幾個組件構成：

• kube-apiserver：k8s集群資源操作的唯一入口，接收用戶通過kubectl輸入的命令，提供認證、授權、API注冊和發現等機制
• etcd：分布式鍵值存儲數據庫，持久化保存集群所有狀態數據（如 Pod、節點、配置等），簡單點來說就是負責存儲集群中各種資源對象的信息
• kube-scheduler：負責集群資源調度，按照預定的調度策略將Pod調度到相應的node節點上
• kube-controller-manager：負責維護集群的狀態，比如程序部署安排，故障檢測、自動擴展、滾動更新等，簡單點來說就是確保集群實際狀態與期望狀態一致。
• cloud-controller-manager（可選）：對接云服務商（如 AWS、Azure、GCP），處理云平臺相關邏輯。管理負載均衡器、存儲卷、節點生命周期（如自動擴縮容）。僅在使用云服務時啟用，本地環境無需此組件。

node節點：

node節點是整個集群的數據平臺，負責為容器提供運行環境，簡單點來說node節點就是負責干活的，其由幾個節點構成：

• kubelet：管理Pod的生命周期和上報當前節點的狀態。
• kube-proxy：負責Pod的訪問路由及負載均衡實現
• 容器運行時環境：負責拉取鏡像、運行容器。其中主要包含Docker、Containerd等組件，通過 CRI（Container Runtime Interface）與 kubelet 交互。

K8s單master架構

下圖是一個K8s單master架構圖，當一個master節點宕機之后，整個集群處于不可用的狀態。

K8s多master架構

下圖是一個K8s多master架構圖，當一個master節點宕機之后，可以通過VIP飄移實現集群的高可用

K8s常用術語

OCI:

OCI（Open Container Initiative）是指開放容器標準，它是一個輕量級、開放的治理結構，致力于圍繞容器格式和運行時創建開放的行業標準
通過支持OCI規范，Kubernetes可以與多種容器運行時兼容，這使得K8s在容器編排和管理方面更加靈活和強大。

CRI

CRI（Container Runtime Interface）是Kubernetes定義的一組與容器運行時進行交互的接口。
CRI是Kubernetes用來與容器運行時進行交互的標準接口。它定義了一套RPC（遠程過程調用）API，這些API被用來管理容器的生命周期。

目前實現了CRI spec的Runtime有Docker Engine、containerd、CRI-O、Mirantis Container Runtime（Docker企業版）等。
已經棄用的有docker-shim

2020年k8s宣布棄用docker-shim，2022年k8s的1.24版本正式棄用docker-shim，這個時候如果容器使用docker的話，需要單獨部署docker-shim。
所以在1.24版本之后推薦使用containerd做為容器運行時環境

CNI:

CNI（Container Network Interface）是一個規范和框架，它允許Kubernetes通過插件化的方式集成各種網絡解決方案，以實現集群內部容器之間的網絡通信。
支持的網絡模式：Overlay Network，Underlay Network，flannel，calico，cannel，cilium