Kubernetes 核心概念

Cobub 發布于2019-07-01 16:51 / 930人閱讀

摘要：核心概念是最小的調度單元，可以由一個或者多個容器組成。該模式會跟云服務商有關，比如可以通過等創建一個外部的負載均衡器，將請求轉發到對應的服務組。而可以提供外部服務可訪問的負載均衡器等。

概述

Kubernetes 有各類資源對象來描述整個集群的運行狀態。這些對象都需要通過調用 kubernetes api 來進行創建、修改、刪除，可以通過 kubectl 命令工具，也可以直接調用 k8s api，或者使用對象語言的客戶端庫（例如：golang ， pythion ）。

每個 kubernetes 對象都會包含兩個關鍵字段：Object Spec 和 Object Status。spec 描述了對象所期望達到的狀態，status 描述了該對象的實際狀態。

下面會寬泛的介紹一些 Kubernetes 的核心概念，便于初步的理解它們特征及工作模式。

核心概念 Pod

Pod 是 Kubernetes 最小的調度單元，可以由一個或者多個容器組成。

Pod 的設計理念是支持多個容器在一個 Pod 中共享網絡和文件系統，可以通過進程間通信和文件共享這種簡單高效的方式組合完成服務。

Pod 的特征：

可以包含多個容器，它們之間共享 IPC、Network 、UTC、PID namespace，可以直接通過 localhost 進行通信。

支持 CPU / Mem 超賣

支持一個或者多個 init containers

Pod 可以共享 Volume，使得多個容器之間可以共享數據。

Pod 生命周期短暫，且不會自愈。需要結合 Deployment、DaemonSet、StatefulSet 等控制器來達到容錯。

優雅退出：Pod 刪除的時候先給其進程發送 SIGTERM，等待一段時間（grace period）后才強制停止依然還在運行的進程。

支持（反）親和性

支持指定調度器

支持優先級和搶占性調度（v1.8 及以上）

支持配置 serviceAccount

kubernetes v1.8+ 且 docker >= 1.13.1 才支持容器之間共享 PID namespace，還需要配置 kubelet —docker-disable-shared-pid=false

Init Containers - Kubernetes

Labels & Selectors

Labels 是 Key-Value 對，k8s 用于標識其所有資源；而 Selectors 是標簽選擇器，用于選擇特定 labels 的資源。

Selectors 目前支持兩種選擇器：Equality-based（基于平等）和 Set-based（基于集合）。

1. Equality-based

基于相等的或者不想等的條件用標簽的 keys 和 values 進行過濾。支持三種運算符：“=”，“==” 和 “!=”。還可以使用逗號操作符，連接多個運算符。

2. Set-based

Set-based 的選擇器允許用一組 value 來過濾 key。
支持三種操作符：in，notin 和 exists（僅針對于 key 符號）。

例如：

env in (dev, test, staging, prod)
env notin (staging, prod)
partition
!partition

Set-based 可以和 Equality-based 條件結合使用。

Deployment

Kubernetes 有幾個版本的副本控制器，比如 Replication Controller、Replica Set（RC 升級版）和 Deployments。

Deployment 是邏輯層的一種抽象，為 Pod 和 ReplicaSet 提供了一種聲明式定義，來代替以前的 Replication Controller 更方便的管理應用。

在 Kubernetes 的實際使用中，RS 也屬于底層概念，由 Deployment 來管理，因此用戶一般都是與 Deployment 打交道。

Deployment 有幾種 典型的應用場景，比如：

定義 Deployment 來創建 Pod 和 ReplicaSet

滾動升級和回滾應用，比如藍綠發布，金絲雀發布等等

擴容和縮容

暫停和繼續 Deployment

RC、RS、Deployment 等對象都是為了解決無狀態服務而設計，下面還會針對有狀態服務，介紹對應的對象。

Service

Kubernetes Pod 有自己的生命周期，可以隨時被創建和銷毀，而一旦銷毀就永遠結束了。而每個 Pods 都有自己的 IP，而 Pod 的生命周期也意味著這些 IP 地址不總是穩定可靠的。所以需要有針對容器的服務發現與負載均衡機制，來訪問這個 Pod 邏輯分組。

service 是對一組提供相同功能的 Pods 集合的抽象，為這組Pods提供統一的訪問入口。借助 Service 可以方便的實現服務發現與負載均衡，并實現應用的零宕機升級。

在 Kubernetes 集群中，每個 Node 都會部署一個 kube-proxy 進程。kube-proxy 負責為 Service 實現了一種 VIP (虛 IP)。

Service 有四種類型：

ClusterIP：默認類型，自動分配一個僅 cluster 內部可以訪問的虛擬 IP。

NodePort：該模式會在每臺機器上綁定一個端口，這樣可以通過 NodeIP:NodePort 進行服務訪問。

LoadBalancer：該模式會跟云服務商有關，比如可以通過 aliyun、aws 等創建一個外部的負載均衡器，將請求轉發到對應的服務組。

ExternalName：支持將服務通過 DNS CNAME 記錄方式轉發到指定的域名（通過 spec.externalName 設定）。需要 kube-dns 版本大于 1.7。

Ingress

通常情況下，Service 和 Pod 僅支持在集群內部進行服務訪問。而 Ingress 可以提供外部服務可訪問的 URL / 負載均衡器等。

Ingress 對象只是配置了一些規則，若要實現集群外部的訪問，還需要部署一個 Ingress Controller，它會從 kube-apiserver 監聽 Ingress 和 Service 的變更，并根據 Ingress 的規則配置負載均衡來提供訪問入口。

Job

Job 負責批量處理短暫的一次性任務，僅執行一次，并保證處理的一個或者多個Pod成功結束。

具體的可以查看：深入K8S Job(一)：介紹

PV & PVC

PersistentVolume (PV) 和 PersistentVolumeClaim (PVC) 提供了方便的持久化卷：PV 提供網絡存儲資源，而 PVC 請求存儲資源。這樣，設置持久化的工作流包括配置底層文件系統或者云數據卷、創建持久性數據卷、最后創建 PVC 來將 Pod 跟數據卷關聯起來。PV 和 PVC 可以將 pod 和數據卷解耦，pod 不需要知道確切的文件系統或者支持它的持久化引擎。

PV 也是集群的資源（等同于cpu / mem），但不同于 pod volume，它是獨立于 Pod 的生命周期。

支持類別劃分，比如不同的服務質量級別（SSD / SATA），不同的備份策略等。
支持動態 PV（StorageClass）。
支持卷的擴容及快照（v1.8+ 特性）。
支持 Local Volume，允許將 Node 本地的磁盤、分區或者目錄作為持久化存儲使用。但是需要注意該模式不支持動態創建，使用前需要預先創建好 PV。

PV 是存儲資源，而 PVC 是對 PV 的請求。PVC 和 Pod 類似，Pod 消費 Node 資源，而 PVC 消費 PV 資源；Pod 能夠請求 CPU 和內存資源，而 PVC 請求特定大小和訪問模式的數據卷。

StatefulSet

StatefulSet 用于支持部署有狀態服務，而有狀態的服務很關鍵的就是持久化存儲，這就依賴上面介紹的 PV & PVC 了。

StatefulSet 的應用場景包括：

穩定的持久化存儲，即不需要關心 Pod 的重新調度，服務訪問的還是相同的持久化數據。

穩定的網絡標志，即 Pod 重新調度后其 PodName 和 HostName 不變。

有序部署，即 Pod 的創建是有順序的，在部署或者擴展的時候要依據定義的順序依次進行創建，基于 init containers 來實現。

有序收縮（刪除）。

參考案例：Running ZooKeeper, A Distributed System Coordinator - Kubernetes

推薦在 k8s v1.9 + 的版本使用 statefulSet。

為了保證數據安全，刪除 StatefulSet 是不會刪除 PV 的，需要考慮清理策略。

StatefulSet 需要提前創建一個 Headless Service 來定義 DNS domain。

Other

還有很多別的資源對象，這里暫不一一介紹了，因為涉及的篇幅會比較長。
對于上面或者未提及的資源對象需要多了解一下的，建議查閱官方文檔。

比如：

Namespace

Node

Secret：集群的秘藥管理

ConfigMap：集群的配置管理

Event：記錄k8s集群運行所遇到的各種大事件

HPA（HorizontalPodAutoscaler）：自動擴縮容

DaemonSet：保證每個Node上都運行一個容器副本，常用于部署一些集群服務的agent(日志／監控…), 也可以基于Pod進行親和部署。

GPU云服務器云服務器 Kubernetes Kubernetes 入門基礎 kubernetes 容器云 apt kubernetes

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/32743.html

Kubernetes概念與術語

摘要：標識是與操作對象間的紐帶。集群為每個對象維護三類信息對象元數據期望狀態與實際狀態元數據指對象的基本信息，比如命名標簽注釋等等，用于識別對象期望狀態一般由用戶配置來描述的實際狀態是由集群各個組件上報的集群實際的運行情況。綜述學習Kubernetes時，發現它的概念和術語還是比較多的，光靠啃官方文檔比較晦澀。所以邊學習邊整理，對主要的概念和術語做一下分類及簡要說明。感覺把重要概念都理解...

_Suqin 2019-07-01 17:08 評論0 收藏0
Kubernetes系統架構演進過程與背后驅動的原因

摘要：本文中，我們將描述系統的架構開發演進過程，以及背后的驅動原因。應用管理層提供基本的部署和路由，包括自愈能力彈性擴容服務發現負載均衡和流量路由。帶你了解Kubernetes架構的設計意圖、Kubernetes系統的架構開發演進過程，以及背后的驅動原因。 showImg(https://segmentfault.com/img/remote/1460000016446636?w=1280...

wuaiqiu 2019-07-01 16:49 評論0 收藏0
靈雀云CTO陳愷：從“鴻溝理論”看云原生，哪些技術能夠跨越鴻溝？

摘要：早在年針對高科技行業和高科技企業生命周期的特點，提出了著名的鴻溝理論。今天我們嘗試以鴻溝理論為基礎來分析云原生領域顛覆性的創新技術。回過頭來看，靈雀云從早期全力投入技術棧，是最早進行產品化的廠商。歷史進入2019年，放眼望去，今天的整個技術大環境和生態都發生了很大的變化。在己亥豬年春節剛剛過去的早春時節，我們來梳理和展望一下整個云原生技術趨勢的發展，是一件很有意義的事情，這其中有些變...

hss01248 2019-07-01 17:09 評論0 收藏0
容器監控實踐—Metrics Server

摘要：出現后，新的監控架構將變成上圖的樣子核心流程黑色部分這是正常工作所需要的核心度量，從等獲取度量數據，再由提供給控制器等使用。本文為容器監控實踐系列文章，完整內容見概述從 v1.8 開始，資源使用情況的監控可以通過 Metrics API的形式獲取，具體的組件為Metrics Server，用來替換之前的heapster，heapster從1.11開始逐漸被廢棄。 Metrics-S...

libxd 2019-06-28 16:57 評論0 收藏0
容器監控實踐—Metrics Server

摘要：出現后，新的監控架構將變成上圖的樣子核心流程黑色部分這是正常工作所需要的核心度量，從等獲取度量數據，再由提供給控制器等使用。本文為容器監控實踐系列文章，完整內容見概述從 v1.8 開始，資源使用情況的監控可以通過 Metrics API的形式獲取，具體的組件為Metrics Server，用來替換之前的heapster，heapster從1.11開始逐漸被廢棄。 Metrics-S...

lmxdawn 2019-07-01 17:01 評論0 收藏0