)
文檔/教程【免費下載鏈接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.項目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps點擊查看免費下載導讀本篇基于 90DaysOfDevOps 學習路線中第 49 天2022/vi/Days/day49.md的內容系統(tǒng)講解 Kubernetes 的全景圖為什么單靠容器不足以支撐規(guī)?;萜骶幣臗ontainer Orchestration解決了什么問題Kubernetes 六大核心能力是什么以及一個集群由哪些節(jié)點、組件和對象構成。讀完本文你將掌握 Kubernetes 從概念到架構的完整認知框架并能結合倉庫內附的 Vagrant 多節(jié)點集群腳本與實際 YAML 清單理解控制平面、工作節(jié)點、Pod、Deployment、StatefulSet、Service 之間的協(xié)作關系為后續(xù)深入學習 kubectl、YAML、Ingress 與持久化存儲打下基礎。為什么容器之后還需要 Kubernetes上一階段我們學習了容器Containers。容器的確改變了云原生系統(tǒng)的構建與分發(fā)方式但當談到**規(guī)模化scaling與編排orchestration**時僅靠容器本身是不夠的——最樂觀的情況下我們只能用 docker-compose 把多個容器一起拉起。docker-compose 適合單機多容器的開發(fā)編排卻無法自動應對流量變化、節(jié)點故障、跨主機的服務發(fā)現(xiàn)等問題。Kubernetes 正是一個Container Orchestrator容器編排器它帶來的是以自動化方式、或依據(jù)應用與服務的負載動態(tài)進行擴縮容scale up/down的能力。原文檔特別強調了一個 DevOps 視角的重要觀點Kubernetes 只是運行應用的另一個選項與裸金屬bare metal、虛擬化virtualisation以及云服務并列是工程師需要具備基礎認知的一類平臺而非唯一答案。容器編排是什么需要區(qū)分兩個概念Kubernetes一項具體的開源技術容器編排Container Orchestration技術背后的概念與流程。容器編排并非 Kubernetes 獨占生態(tài)中還有 Docker Swarm、HashiCorp Nomad 等平臺。原文檔指出Kubernetes 正從強到更強going from strength to strength因此本系列選擇它作為主線索但同時提醒讀者它并非唯一選擇。容器編排負責管理容器的部署、放置與生命周期具體職責包括集群管理Cluster management將多臺主機融合為一個統(tǒng)一的管理目標調度管理Schedule management通過調度器scheduler把容器分布到各節(jié)點nodes服務發(fā)現(xiàn)Service discovery知道容器位于哪些節(jié)點并把客戶端請求分發(fā)給它們復制Replication確保為請求的工作負載保留足夠數(shù)量的節(jié)點與容器健康管理Health management檢測并替換不健康的容器與節(jié)點。Kubernetes 是什么六大核心能力官方定義這樣描述 KubernetesKubernetes 是一個可移植、可擴展的開源平臺用于管理容器化的工作負載與服務支持聲明式配置與自動化。它擁有龐大且快速增長的生態(tài)系統(tǒng)其服務、支持與工具廣泛可用。值得注意的歷史背景Kubernetes 起源于 Google被捐贈給Cloud Native Computing FoundationCNCF此后由開源社區(qū)與大型企業(yè)廠商共同推動演進。容器本身并不能直接給你生產(chǎn)環(huán)境所需的體驗Kubernetes 則提供了以下六項能力能力說明服務發(fā)現(xiàn)與負載均衡Service discovery and load balancing可以用 DNS 名稱或 IP 地址暴露容器當容器流量較高時Kubernetes 自動負載均衡并分發(fā)網(wǎng)絡流量保證部署穩(wěn)定。存儲編排Storage orchestration自動掛載你選擇的存儲系統(tǒng)如本地存儲、公有云存儲等。自動化上線與回滾Automated rollouts and rollbacks聲明期望狀態(tài)Kubernetes 以受控速率把實際狀態(tài)收斂到期望狀態(tài)例如自動創(chuàng)建新容器、移除舊容器并回收其資源。自動裝箱Automatic bin packing提供節(jié)點集群后你只需告訴 Kubernetes 每個容器所需的 CPU 與內存RAM它會自動把容器塞進合適的節(jié)點最大化資源利用率。自愈Self-healing重啟失敗的容器、替換容器、殺掉不響應自定義健康檢查的容器并且在這些容器未就緒前不把流量導向它們。密鑰與配置管理Secret and configuration management存儲并管理密碼、OAuth token、SSH key 等敏感信息可在不重建鏡像、不把密鑰暴露在堆棧配置中的前提下完成部署與更新。倉庫中的 pacman-stateful-demo.yaml 就是對上述能力的落地印證其中定義了mongodb-users-secretSecret 管理、readinessProbe與livenessProbe自愈所依賴的健康檢查、PersistentVolumeClaim存儲編排等資源后面我們會展開分析。聲明式模型Kubernetes 的關鍵范式Kubernetes 的關鍵范式key paradigm是聲明式模型declarative model你只需提供想要的最終狀態(tài)Kubernetes 負責把現(xiàn)實收斂到該狀態(tài)。如果你需要五個實例你不需要自己逐個啟動五個實例只需告訴 Kubernetes我需要五個實例它會自動**對賬reconcile**狀態(tài)當其中一個實例故障Kubernetes 仍記得你的期望狀態(tài)會在可用節(jié)點上重新創(chuàng)建實例。這也解釋了為何 Kubernetes 常被稱為操作系統(tǒng)級的控制循環(huán)它不是一次性命令式執(zhí)行而是持續(xù)比較期望狀態(tài)與實際狀態(tài)并不斷糾正。節(jié)點Node與集群Cluster的基本單元一個 Kubernetes集群Cluster是節(jié)點的集合每個節(jié)點可以是物理機bare metal或虛擬機VM。每個節(jié)點上都運行著容器運行時與 kubelet 服務并通過 kube-proxy 把 Pod 與外部組件如 Service連接起來。控制平面Control Plane節(jié)點每個 Kubernetes 集群都需要一個Control Plane 節(jié)點??刂破矫娴慕M件負責對集群做出全局決策例如調度并檢測與響應集群事件。在生產(chǎn)環(huán)境中控制平面可以做成**高可用HA**部署與工作節(jié)點承擔不同的角色。工作節(jié)點Worker Node工作節(jié)點是運行 Kubernetes 工作負載的機器可以是物理機或 VM。每個節(jié)點可以承載一個或多個 Pod節(jié)點由控制平面管理。kubeletkubelet是運行在每個節(jié)點上的代理agent確保容器運行在 Pod 中。它通過多種機制接收一組 PodSpec并確保這些 PodSpec 描述的容器處于運行且健康的狀態(tài)。kubelet 不管理非 Kubernetes 創(chuàng)建的容器。kube-proxykube-proxy是運行在每個節(jié)點上的網(wǎng)絡代理實現(xiàn) Kubernetes Service 概念的一部分。它維護節(jié)點上的網(wǎng)絡規(guī)則允許集群內外的網(wǎng)絡會話與你的 Pod 通信如果操作系統(tǒng)提供可用的包過濾層packet filtering layerkube-proxy 會優(yōu)先使用它否則由 kube-proxy 自行轉發(fā)流量。容器運行時Container runtime容器運行時是負責真正運行容器的軟件。Kubernetes 支持多種運行時Docker、containerd、CRI-O以及任何符合 Kubernetes CRIContainer Runtime Interface的實現(xiàn)。倉庫中的部署腳本與這一節(jié)直接呼應2022/Days/Kubernetes/scripts/common.sh 先卸載舊版運行時再安裝docker-ce docker-ce-cli containerd.io隨后執(zhí)行containerd config default生成/etc/containerd/config.toml并重啟 containerd最終輸出ContainerD Runtime Configured Successfully——即該腳本以containerd 作為實際容器運行時來滿足 CRI 要求。控制平面的四個核心組件原文檔詳細介紹了控制平面內四個關鍵組件它們通過 API Server 共享集群狀態(tài)并協(xié)作kube API Serverkube API Server對包括 Pods、Services、Replication Controllers 等 API 對象的數(shù)據(jù)進行驗證與配置。它提供 REST 操作是整個集群共享狀態(tài)的前端所有其他組件都通過它交互。從倉庫腳本看kubeadm 初始化時正是通過--apiserver-advertise-address與--apiserver-cert-extra-sans指定 API Server 的對外地址與證書 SAN見 2022/Days/Kubernetes/scripts/master.sh。Scheduler調度器Scheduler是控制平面進程負責把 Pod 分配到 Node。它依據(jù)約束條件與可用資源判斷調度隊列中的每個 Pod 哪些節(jié)點是合法放置位置再對每個合法節(jié)點排序最終把 Pod 綁定到合適的節(jié)點。Controller Manager控制器管理器Controller Manager是一個守護進程內嵌 Kubernetes 自帶的核心控制循環(huán)core control loops。在機器人或自動化領域控制循環(huán)是一個永不停歇、持續(xù)調節(jié)系統(tǒng)狀態(tài)的循環(huán)在 Kubernetes 中控制器通過 API Server 監(jiān)視集群共享狀態(tài)并做出變更把當前狀態(tài)推向期望狀態(tài)。etcdetcd是一致且高可用consistent and highly-available的鍵值存儲作為 Kubernetes 全部集群數(shù)據(jù)的后端存儲保存整個集群的配置與狀態(tài)。它是集群狀態(tài)的事實來源也是理解共享狀態(tài) 控制循環(huán)這一架構的關鍵。kubectl與集群對話的 CLIkubectl是 Kubernetes 的命令行工具它直接與 API Server 交互。你可以用它部署應用、檢查與管理集群資源、查看日志。在倉庫腳本中kubectl 的典型使用方式包括kubectl apply -f calico.yaml安裝 Calico 網(wǎng)絡插件kubectl apply -f ...components.yaml安裝 Metrics Server并用kubectl patch deployment為其增加--kubelet-insecure-tls參數(shù)通過kubectl -n kubernetes-dashboard get secret ...提取 Dashboard 管理員 token見 2022/Days/Kubernetes/scripts/master.sh。這些命令展示了 kubectl 在真實集群初始化中的三個典型職責應用清單、修補運行中的資源、查詢集群狀態(tài)。核心工作負載對象從 Pod 到 Service理解了節(jié)點與組件之后接下來是 Kubernetes 的積木塊——工作負載對象。原文檔用一套簡潔筆記勾勒出它們的分工。Pods最小的部署單元Pod是一組容器構成的邏輯應用。例如一個 Web 應用同時運行 NodeJS 容器與 MySQL 容器兩者可以放在同一個 Pod 中。Pod 可以共享數(shù)據(jù)卷volumes并共享同一個網(wǎng)絡命名空間networking namespace。關鍵特性Pod 為容器處理 Volumes、Secrets 與配置Pod 是**臨時性ephemeral**的故障后會被自動重啟應用橫向擴縮容時Pod 由 ReplicaSet 復制每個 Pod 運行相同容器代碼Pod 運行在工作節(jié)點上Kubernetes 通過Labels鍵值對標簽這種簡單而高效的方式標識 Pod。Deployments讓 Pod 持續(xù)運行直接運行 Pod 的話Pod 死了就是死了Deployment讓 Pod 持續(xù)運行Deployment 允許無停機without downtime更新正在運行的應用Deployment 還定義了 Pod 死亡時的重啟策略restart strategy。倉庫中的 nginx-stateless-demo.yaml 給出了一個完整的 Deployment 示例聲明replicas: 1、selector.matchLabels.app: nginx、容器鏡像nginx并暴露containerPort: 80配合同文件中的 Service 形成Deployment Service的無狀態(tài)應用范式。ReplicaSets保證期望副本數(shù)Deployment 可以創(chuàng)建 ReplicaSetReplicaSet確保你的應用擁有期望數(shù)量的 PodReplicaSet 基于 Deployment 創(chuàng)建并擴縮容 Pod 組Deployment、ReplicaSet、Pod 之間并非互斥關系而是層層管理的關系Deployment 管理 ReplicaSetReplicaSet 管理 Pod。StatefulSets有狀態(tài)應用的唯一身份你的應用是否需要保存狀態(tài)信息數(shù)據(jù)庫就需要狀態(tài)StatefulSet的 Pod不可互換not interchangeable每個 Pod 擁有唯一、持久的標識符unique, persistent identifier控制器會在任何重新調度rescheduling中維持該標識。倉庫中的 pacman-stateful-demo.yaml 是 StatefulSet 的完整實戰(zhàn)kind: StatefulSet、serviceName: mongo、通過persistentVolumeClaim: mongo-storage掛載持久卷、初始化容器修正/bitnami/mongodb目錄權限fsGroup: 1001并使用bitnami/mongodb:4.4.8鏡像。它還示范了 Secret 的消費方式——通過secretKeyRef從mongodb-users-secret注入MONGODB_ROOT_PASSWORD、MONGODB_DATABASE等環(huán)境變量正是前文密鑰與配置管理能力的直接體現(xiàn)。DaemonSets每個節(jié)點一個 PodDaemonSet面向持續(xù)進程continuous process它在每個節(jié)點上運行一個 Pod集群每新增一個節(jié)點DaemonSet 就會在該節(jié)點啟動一個新 Pod非常適合監(jiān)控、日志采集等后臺任務每個 Pod 擁有唯一、持久的標識符由控制器在重新調度中維持。Services訪問 Pod 的統(tǒng)一入口Service是訪問 Pod 的單一端點single endpoint它提供統(tǒng)一的方式把流量路由到集群、最終路由到一組 Pod借助 ServicePod 可以被拉起或銷毀而不影響任何調用方。在 nginx-stateless-demo.yaml 中nginx-service通過selector.app選擇后端 Pod并將port: 80映射到容器的targetPort: 80而在 pacman-stateful-demo.yaml 中mongoService 采用ClusterIP供集群內部訪問pacman 前端通過MONGO_SERVICE_HOST: mongo連接pacman Service 則采用LoadBalancer對外暴露。兩者恰好對應原文檔所述Service 統(tǒng)一路由流量的兩種典型場景。倉庫實戰(zhàn)一條龍搭建多節(jié)點集群原文檔是概念性全景圖而倉庫的 Kubernetes 目錄提供了與之配套的可運行的多節(jié)點集群搭建資源可作為理解上述架構的直接佐證Vagrantfile定義 1 個 master 節(jié)點 2 個 worker 節(jié)點的拓撲使用bento/ubuntu-21.10鏡像master 分配 4GB 內存/2 核worker 各 2GB/1 核并寫入/etc/hosts主機名映射master-node、worker-node01、worker-node02。scripts/common.sh所有節(jié)點共用的初始化——關閉 swap、加載br_netfilter與overlay內核模塊、配置 sysctlnet.bridge.bridge-nf-call-iptables、net.ipv4.ip_forward等、安裝 Docker Engine 與 containerd 并生成 containerd 默認配置、最后安裝并apt-mark hold固定kubelet kubeadm kubectl版本1.23.3-00。scripts/master.sh在 master 上執(zhí)行kubeadm init參數(shù)--apiserver-advertise-address10.0.0.10、--pod-network-cidr192.168.0.0/16、--ignore-preflight-errors Swap復制 kubeconfig把 join 命令寫入/vagrant/configs/join.sh隨后部署 Calico 網(wǎng)絡插件、Metrics Server 與 Kubernetes Dashboard并創(chuàng)建admin-user的ServiceAccountClusterRoleBinding。scripts/node.shworker 節(jié)點執(zhí)行/vagrant/configs/join.sh -v加入集群并打上node-role.kubernetes.io/worker標簽。configs/join.sh由 master 腳本生成的真實 join 命令示例格式為kubeadm join API地址:6443 --token ... --discovery-token-ca-cert-hash sha256:...直觀展示工作節(jié)點如何通過 API Server 令牌與證書哈希加入集群。這套腳本與本文的架構描述一一對應master-node對應控制平面節(jié)點承載 API Server、Scheduler、Controller Manager、etcdworker-node01/02對應工作節(jié)點承載 kubelet、kube-proxy、容器運行時與 Pod。需要說明的是原文檔寫作時以 Docker 作為運行時示例而倉庫腳本實際落地為 containerd 運行時 Docker 工具鏈這恰好印證了Kubernetes 支持多種 CRI 運行時的論斷。本系列后續(xù)將覆蓋的主題原文檔在結尾給出了 Kubernetes 系列的路線圖本文只是全景開篇后續(xù)將繼續(xù)深入Kubernetes 架構Architecturekubectl 命令Kubectl CommandsKubernetes YAMLKubernetes IngressKubernetes ServicesHelm 包管理器Helm Package Manager持久化存儲Persistent Storage有狀態(tài)應用Stateful Apps下一站是 Day 50在哪里運行 Kubernetes 集群將聚焦集群部署位置的選擇與存儲細節(jié)。參考資料官方 Kubernetes 文檔概念總覽什么是 Kubernetes一節(jié)原文檔推薦的新手首選TechWorld with Nana 的 Kubernetes 入門教程4 小時完整課程TechWorld with Nana 的 Kubernetes 零基礎速成課Kunal Kushwaha 的 Kubernetes 入門與架構簡化講解說明以上外部學習資源來自原文檔的參考文獻列表本文僅作指引性描述正文的全部技術結論均以本倉庫文檔與源碼為準。贊分享文檔/教程【免費下載鏈接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.項目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps點擊查看免費下載相關推薦90DaysOfDevOps 第49天Kubernetes 全景圖——從容器編排概念到集群核心組件90DaysOfDevOps 第49天Kubernetes 全景圖——從容器編排概念到集群核心組件 導讀 本文是 90DaysOfDevOps 學習系列中 K文檔/教程90DaysOfDevOps 之 Kubernetes 全景入門從容器編排到核心組件架構90DaysOfDevOps 之 Kubernetes 全景入門從容器編排到核心組件架構 導讀 本文源自 90DaysOfDevOps https://lin文檔/教程90DaysOfDevOps Day 49Kubernetes 全景入門——從容器編排概念到核心組件與工作負載原語90DaysOfDevOps Day 49Kubernetes 全景入門——從容器編排概念到核心組件與工作負載原語 Kubernetes 是當前云原生基礎設施文檔/教程創(chuàng)作聲明:本文部分內容由AI輔助生成(AIGC),僅供參考