k8s-組件簡介 - 台部落

前言

下文我將會介紹各種組件 .

Label 標籤

打標的好處肯定就是鑑別出來 , Label 在 k8s 中的用處主要有幾個 :

kube-controller 進程(Master 機器上)通過資源對象RC 上定義的Label Selector 來篩選要監控的Pod 副本的數量，從而實現Pod 副本的數量始終符合預期設定的全自動控制流程。
kube-proxy 進程(各個Node 節點上)通過Service 的Label Selector 來選擇對應的Pod ，自動建立起每個Service到對應Pod 的請求轉發路由表，從而實現Service 的智能負載均衡機制。
通過對某些Node 定義特定的Label.並且在Pod 定義文件中使用NodeSelector 這種標籤調度策略， kube咽heduler 進程可以實現Pod "定向調度"的特性。

Replication Controller (RC)

Replication Controller(RC) 也是一個虛擬概念.
當我們定義了一個RC 並提交到Kubemetes 集羣中以後， Master 節點上的Control1er Manager組件就得到通知，定期巡檢系統中當前存活的目標Pod，並確保日標Pod 實例的數量剛好等於此RC 的期望值，如果有過多的Pod 副本在運行，系統就會停掉一些Pod，否則系統就會再自動創建一些Pod。可以說，通過RC ， Kubemetes 實現了用戶應用集羣的高可用性，並且大大減少了系統管理員在傳統IT 環境中需要完成的許多手主運維工作(如主機監控腳本、應用監控腳本等)

Replication Controller (RC) 和 Replica Set

由於Replication Controller 與Kubemetes 代碼中的模塊Replication Controller 同名，同時這個詞也無法準確表達它的本意，所以在Kubemetes 1.2 的時候，它就升級成了另外→個新的概念一--Replica Set，官方解釋爲"下一代的RC".

它與RC 當前存在的唯一區別是: Replica Sets支持基於集合的Label selector (Set-based selector) ，而RC 只支持基於等式的Label Selector (equality-based selector) ，這使得Replica Set 的功能更強.

Replica Set 的使用

此外，當前我們很少單獨使用Replica Set ，它主要被Deployment 這個更高層的資源對象所使用，從而形成一整套Pod 創建、刪除、更新的編排機制。當我們使用Deployment 時，無須關心它是如何創建和維護Replica Set 的，這一切都是自動發生的。Replica Set 與Deployment 這兩個重要資源對象逐步替換了之前的RC 的作用，是Kubemetes 1.3裏Pod 自動擴容(伸縮)這個告警功能實現的基礎.

Deployment

Deployment 就是一個 部署過程 的抽象過程, 例如我要部署一整套系統 , 或是升級整套系統, 我不會使用 kind : pod這樣的 yaml 文件來執行完成我的部署 ,而是使用一個更高層次的 Deployment .

k8s 中不僅把一些邏輯的概念進行抽象, 還會把平時一系列的動作(例如一個部署過程, 一個容器擴展收縮等)進行抽象 , 這纔是它的厲害的地方

Deployment 使用場景

Deployment 的典型使用場景有以下幾個。

創建一個Deployment 對象來生成對應的Replica Set 並完成Pod 副本的創建過程。
檢查Deployment 的狀態來看部署動作是否完成CPod 副本的數量是否達到預期的值)。
更新Deplo嚴nent 以創建新的Pod C 比如鏡像升級)。
如果當前Deployment 不穩言，則回宿到一個早先的Deployment 版本。

Service (服務)

Service 概述

Service 的位置在哪裏 , 又是如何提供服務的
Service 也是Kubemetes 裏的最核心的資源對象之一， Kubemetes 裏的每個Service 其實就是我們經常提起的微服務架構中的一個"微服務"，之前我們所說的Pod、RC 等資源對象其實都是爲這節所說的"服務"一-Kubemetes Service 做"嫁衣"的。圖1.1 4 顯示了Pod、RC 與Service的邏輯關係。

從圖1.1 4 中我們看到， Kubemetes 的Service 定義了一個服務的訪問入口地址，前端的應用(Pod) 通過這個入口地址訪問其背後的一組由Pod 副本組成的集羣實例， Service 與其後端Pod副本集羣之間則是通過Label Selector 來實現"無縫對接"的。而RC 的作用實際上是保證Service的服務能力和服務質量始終處於預期的標準。

請求如何在 Service 中找到Pod的

既然每個Pod 都會被分配一個單獨的IP 地址，而且每個Pod 都提供了一個獨立的Endpoint(Pod IP+ContainerPort) 以被客戶端訪問，現在多個Pod 副本組成了一個集羣來提供服務，那麼客戶端如何來訪問它們呢?

反向代理

反向代理是不是讓你想起了 nginx , 沒錯 ,k8s 中 Service 分發流量到各個 Pod 也是使用反向代理 , 對外提供一個 IP ,然後把流量都接下來 ,再分到各個 Pod .Pod 對外提供的接口叫 Endpoint, 那麼還有個問題, 類似於註冊中心 (zookeeper, nacos) , 多個 Pod 的 Endpoint 的信息肯定需要上報到某個地方, 方便後續 Service 流量 .

是的, 這個地方就是 ETCD , 然後 kube-proxy 通過 API Servce ,獲取同步節點信息 ,再通過分發算法, 對請求進行分發 . 也就是說 Pod 的增加減少刪除等都會上報給 API Servie !! 而其他對外提供服務的時候或是拓展容器數量, 收縮容器數量的時候是通過 API service 獲取Pod 信息的

Service 服務發現機制

我們已經知道了每個 Service 擁有一個 Cluster IP + 名字 , 那麼外界是如何找到這個 Service 的呢 ?
是通過 DNS 的方式

外部系統訪問Service 的問題

我們先看關於 IP 相關的知識 ,見其它章節的關於三個IP 類型的描述 , 其中和 Service 有關的是 Cluster IP

圖中就是實際部署中的 service 的類型 , 有 ClusterIP 也有 LoadBalancer .
那麼外部是如何訪問 Service 的呢 ?

Node Port 方式

apiVersion: vl
kind: Service
metadata:
    name: tomcat-service
spec:
    type: NodePort
    ports:
        - port: 8080
    nodePort: 31002
selector:
    tier: fronte

NodePort 的實現方式是在Kubemetes 集羣裏的每個Node 上爲需要外部訪問的Service 開啓一個對應的TCP 監昕端口，外部系統只要用任意一個Node 的IP 地址+具體的NodePort 端口號即可訪問此服務，在任意Node 上運行netstat 命令，我們就可以看到有NodePort 端口被監昕:

 netstat -tlp | grep 31002

這種方式就像我們某個機器開個端口和ip一樣 ,實際的部署環境肯定不是這樣. 例如我們需要做負載均衡等等.

LoadBalancer

Load ba1ancer 組件獨立於Kubemetes 集羣之外，通常是一個硬件的負載均衡器，或者是以軟件方式實現的，例如HAProxy 或者Nginx。 對於每個Service ，我們通常需要配置一個對應的Load balancer 實例來轉發流量到後端的Node 上，這的確增加了工作量及出錯的概率。

Volume (存儲卷)

我們學習Docker 的時候都知道 Volume 通過掛載的方式掛載到容器內部 ,在 k8s 中是不是一樣的東西呢?

Volume 是Pod 中能夠被多個容器訪問的共享目錄。Kubemetes 的Volume 概念、用途和目的與Docker 的Volume 比較類似，但兩者不能等價。

Volume在K8S和Volume在容器中的區別

Kubemetes 中的Volume 定義在Pod上，然後被一個Pod 裏的多個容器掛載到具體的文件目錄下
其次， Kubemetes 中的Volume 與Pod 的生命週期相同，但與容器的生命週期不相關，當容器終止或者重啓時， Volume 中的數據也不會丟失。
Kubemetes 支持多種類型的Volume ，例如GlusterES 、Ceph 等先進的分佈式文件系統。

Kubemetes 的 Volume 類型

這塊先略過 , 展開說太多了, 後續篇幅再展開

Namespace (命名空間)

Namespace (命名空間)是Kubemetes 系統中的另一個非常重要的概念， Namespace 在很多情況下用於實現多租戶的資源隔離。Namespace 通過將集羣內部的資源對象"分配"到不同的Namespace 中，形成邏輯上分組的不同項目、小組或用戶組，便於不同的分組在共享使用整個集羣的資源的同時還能被分別管理。

舉一個現實一點的例子 , 例如我是一個雲服務商, 對外爲衆多軟件應用商提供服務 , 我只提供基礎服務 ,例如同時爲 A , B 提供服務 . A , B 分別位於不同的 Namespace (命名空間) 內 NA , NB , NA 享有 2核CPU 500MB內存 , 而 NB 享有 4核CPU 2GB內存, (PS : 這不就是阿里雲的玩法嗎?!)

我們學習容器docker 的時候就知道了 docker 容器的底層技術是 cgroup + nameSpace ,那麼k8s又是如何做的呢? 交給後面的學習哇

Annotation (註解)

Annotation 與Label 類似，也使用key/value 鍵值對的形式進行定義。不同的是Label 具有嚴格的命名規則，它定義的是Kubemetes 對象的元數據( Metadata) ，並且用於Label Selector 。而Annotation 則是用戶任意定義的"附加"信息，以便於外部工具進行查找，很多時候， Kubemetes的模塊自身會通過Annotation 的方式標記資源對象的一些特殊信息。

(有點像變量)

通常來說，用Annotation 來記錄的信息如下。

build 信息、release 信息、Docker 鏡像信息等，例如時間戳、release id 號、PR 號、鏡像hash 值、docker registry 地址等。
日誌庫、監控庫、分析庫等資源庫的地址信息。
程序調試工具信息，例如工具名稱、版本號等。
團隊的聯繫信息，例如電話號碼、負責人名稱、網址等。

其他

k8s 中的IP

Node IP: Node 節點的IP 地址。
PodlP: Pod 的IP 地址。
Cluster IP: Service 的IP 地址。

Node IP

Node IP 是Kubemetes 集羣中每個節點的物理網卡的IP 地址，這是一個真實存在的物理網絡，所有屬於這個網絡的服務器之間都能通過這個網絡直接通信，不管它們中是否有部分節點不屬於這個Kubemetes 集羣。這也表明了Kubemetes 集羣之外的節點訪問Kubemetes 集羣之內的某個節點或者TCP/IP 服務的時候，必須要通過Node IP 進行通信。

PodlP

Pod IP 是每個Pod 的IP 地址，它是Docker Engine 根據dockerO 網橋的IP 地址段進行分配的，通常是一個虛擬的二層網絡，前面我們說過， Kubemetes 要求位於不同Node 上的Pod 能夠彼此直接通信，所以Kubemetes 裏一個Pod 裏的容器訪問另外一個Pod 裏的容器，就是通過PodlP 所在的虛擬二層網絡進行通信的，而真實的TCP幾P 流量則是通過Node IP 所在的物理網卡流出的。

Cluster IP

我們說說Service 的Cluster IP ，它也是一個虛擬的IP ，但更像是一個"僞造"的IP網絡，原因有以下幾點。

Cluster IP 僅僅作用於Kubemetes Service 這個對象，並由Kubemetes 管理和分配IP 地址(來源於Cluster IP 地址池)。
Cluster IP 無法被Ping ，因爲沒有一個"實體網絡對象"來響應。
Cluster IP 只能結合Service Port 組成一個具體的通信端口，單獨的Cluster IP 不具備TCP/IP 通信的基礎，並且它們屬於Kubemetes 集羣這樣一個封閉的空間，集羣之外的節點如果要訪問這個通信端口，則需要做一些額外的工作。

在Kubemetes 集羣之內， Node IP 網、Pod IP 網與Cluster IP 網之間的通信，採用的是Kubemetes 自己設計的一種編程方式的特殊的路由規則，與我們所熟知的IP 路由有很大的不同。Service 的Cluster IP 屬於Kubemetes 集羣內部的地址，無法在集羣外部直接使用這個地址。

想法1

k8s 對兩方面進行抽象 :

過程抽象 : Deployment , ReplicaSet
邏輯抽象 : Pod , Service
資源抽象 : Node

想法2

一組資源 ,比如 CPU 資源和內存資料稱之爲 Node , Pod(容器組) 更像是微服務中的節點 , 例如系統提供售票服務 ,分別有售1節點 , 售2節點, 售3節點, 各節點地址低位一致 .

想法3

pod : 組合不同的容器鏡像
deployment(部署的抽象) : 組合不同的 pod , 當然也可以是相同的 pod , 看部署需求

想法4

現在看阿里的控制檯, 並沒有以service 分類 , 而是以 deployment 分類 , Pod(容器組分類) 等等, 而不是以 Service 去分類, Service 相關只涉及網絡相關的 , 下面的圖, 工作負載 並沒有 Service , Service 被放在 網絡 菜單下

Service <======> 網絡

總結

一個集羣提供的多種服務 , k8s 不斷地從頂層到底層都進行了抽象, 文章介紹了k8s中幾個重要的組件 .

參考資料

<<Kubernetes權威指南>>