1. 資源管理

當你定義 Pod 時可以選擇性地為每個 容器設定所需要的資源數量怪与。 最常見的可設定資源是 CPU 和內存（RAM）大小凉蜂；此外還有其他類型的資源琼梆。

當你為 Pod 中的 Container 指定了資源 請求 時性誉，調度器就利用該信息決定將 Pod 調度到哪個節(jié)點上窿吩。 當你還為 Container 指定了資源 限制 時，kubelet 就可以確保運行的容器不會使用超出所設約束的資源错览。 kubelet 還會為容器預留所 請求 數量的系統(tǒng)資源纫雁，供其使用。

在 Kubernetes 體系中倾哺，資源默認是被多租戶共享使用的轧邪，租戶間不可避免地存在資源競爭問題。為了滿足不同租戶多樣的服務質量需求羞海，集群管理員需要為租戶設置非常精細的資源配額以及資源限制忌愚。截止 1.14 版本，Kubernetes 已經支持分別從 Namespace却邓、Pod 和 Container 三個級別對資源進行管理硕糊。

1.1 請求和限制

如果 Pod 運行所在的節(jié)點具有足夠的可用資源，容器可能（且可以）使用超出對應資源 request 屬性所設置的資源量腊徙。不過简十，容器不可以使用超出其資源 limit 屬性所設置的資源量。

例如撬腾，如果你將容器的 memory 的請求量設置為 256 MiB螟蝙，而該容器所處的 Pod 被調度到一個具有 8 GiB 內存的節(jié)點上，并且該節(jié)點上沒有其他 Pods 運行民傻，那么該容器就可以嘗試使用更多的內存胰默。

如果你將某容器的 memory 限制設置為 4 GiB场斑，kubelet （和 容器運行時） 就會確保該約束生效。 容器運行時會禁止容器使用超出所設置資源約束的資源初坠。 例如：當容器中進程嘗試使用超出所允許內存量的資源時和簸，系統(tǒng)內核會將嘗試申請內存的進程終止， 并引發(fā)內存不足（OOM）錯誤碟刺。

約束值可以以被動方式來實現（系統(tǒng)會在發(fā)現違例時進行干預）锁保，或者通過強制生效的方式實現 （系統(tǒng)會避免容器用量超出約束值）。不同的容器運行時采用不同方式來實現相同的限制半沽。

如果某 Container 設置了自己的內存限制但未設置內存請求爽柒，Kubernetes 自動為其設置與內存限制相匹配的請求值。類似的者填，如果某 Container 設置了 CPU 限制值但未設置 CPU 請求值浩村，則 Kubernetes 自動為其設置 CPU 請求 并使之與 CPU 限制值匹配。

1.2 資源類型

CPU 和內存都是資源類型占哟。每種資源類型具有其基本單位心墅。 CPU 表達的是計算處理能力，其單位是 Kubernetes CPUs榨乎。 內存的單位是字節(jié)怎燥。 如果你使用的是 Kubernetes v1.14 或更高版本，則可以指定巨頁（Huge Page）資源蜜暑。 巨頁是 Linux 特有的功能铐姚，節(jié)點內核在其中分配的內存塊比默認頁大小大得多。

例如隐绵，在默認頁面大小為 4KiB 的系統(tǒng)上，你可以指定約束 hugepages-2Mi: 80Mi拙毫。 如果容器嘗試分配 40 個 2MiB 大小的巨頁（總共 80 MiB ）依许，則分配請求會失敗。

你不能過量使用 hugepages- * 資源缀蹄。 這與 memory 和 cpu 資源不同峭跳。

CPU 和內存統(tǒng)稱為計算資源，或簡稱為資源袍患。 計算資源的數量是可測量的坦康，可以被請求、被分配诡延、被消耗滞欠。 它們與 API 資源 不同。 API 資源（如 Pod 和 Service）是可通過 Kubernetes API 服務器讀取和修改的對象肆良。

1.3 Pod 和 容器的資源請求和限制

Pod 中的每個容器都可以指定以下的一個或者多個值：

• spec.containers[].resources.limits.cpu
• spec.containers[].resources.limits.memory
• spec.containers[].resources.limits.hugepages-<size>
• spec.containers[].resources.requests.cpu
• spec.containers[].resources.requests.memory
• spec.containers[].resources.requests.hugepages-<size>

CPU 的含義
CPU資源以毫秒定義筛璧。 如果您的容器需要運行兩個完整的核心逸绎，那么您將設置值2000m。 如果您的容器只需要1/4的核心夭谤，那么您將設置一個250m的值棺牧。

關于CPU請求要記住的一件事是，如果您輸入的值大于最大節(jié)點的核心數朗儒，則永遠不會調度您的Pod颊乘。 假設您有一個需要四個核心的Pod，但您的Kubernetes群集由雙核VM組成——您的Pod將永遠不會被調度醉锄！

除非您的應用程序專門用于利用多個核心（科學計算和某些數據庫）乏悄，否則通常最好將CPU請求保持在1或更低，并運行更多副本以擴展它恳不。 這為系統(tǒng)提供了更大的靈活性和可靠性檩小。

就CPU限制而言，事情其實很有趣烟勋。 CPU被認為是可壓縮資源规求。 如果您的應用程序開始達到您的CPU限制，Kubernetes會開始限制您的容器卵惦。 這意味著CPU將受到人為限制阻肿，使您的應用程序性能可能更差！ 但是鸵荠，它不會被終止或退出冕茅。 您可以使用Liveness探針的運行狀況檢查來確保性能未受影響伤极。

內存的含義
內存資源以字節(jié)為單位定義蛹找。 通常，你給內存一個mebibyte值（這基本上與兆字節(jié)相同）哨坪，實際上你可以提供從字節(jié)到PB的任何單位庸疾。

和CPU一樣，如果您輸入的內存請求大于節(jié)點上的內存量当编，則你的Pod永遠不會被調度届慈。

與CPU資源不同，內存無法壓縮忿偷。 因為沒有辦法限制內存使用量金顿，如果容器超過其內存限制，它將被終止鲤桥。 如果您的Pod由Deployment，StatefulSet，DaemonSet或其他類型的控制器管理马绝，則控制器會輪轉替換。

舉例：

root@k8s-ansible-client:~/yaml/20211031/limit-case# cat mem-and-cpu-limit.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: limit-test-deployment
  namespace: pop
spec:
  replicas: 1
  selector:
    matchLabels: #rs or deployment
      app: limit-test-pod
  template:
    metadata:
      labels:
        app: limit-test-pod
    spec:
      containers:
      - name: limit-test-container
        image: lorel/docker-stress-ng
        resources:
          limits:
            cpu: "500m"
            memory: "300Mi"
          requests:
            memory: "100Mi"
            cpu: "250m"
        args: ["--vm", "2", "--vm-bytes", "256M"]

root@k8s-ansible-client:~/yaml/20211031/limit-case# kubectl apply -f mem-and-cpu-limit.yaml 
deployment.apps/limit-test-deployment created

root@k8s-ansible-client:~/yaml/20211031/limit-case# kubectl get pods,deploy -n pop
NAME                                         READY   STATUS    RESTARTS   AGE
pod/limit-test-deployment-5574ccb468-ld9pt   1/1     Running   0          4s

NAME                                    READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/limit-test-deployment   1/1     1            1           4s

# 這里限制了cpu最高500m,內存300Mi; cpu已經到達上限播揪，內存需要過一會（但是不會超過300Mi以上）
root@k8s-ansible-client:~/yaml/20211031/limit-case# kubectl top pod limit-test-deployment-5574ccb468-ld9pt -n pop
W1113 22:49:28.607818  211109 top_pod.go:140] Using json format to get metrics. Next release will switch to protocol-buffers, switch early by passing --use-protocol-buffers flag
NAME                                     CPU(cores)   MEMORY(bytes)   
limit-test-deployment-5574ccb468-ld9pt   501m         247Mi 

排查錯誤
啟動容器之后，使用describe排查不出來報錯信息的時候筒狠，使用下面方式：

root@k8s-ansible-client:~/yaml/20211031/limit-case# kubectl get deploy limit-test-deployment -n pop -o json

1.3.1 LimitRange

默認情況下猪狈， Kubernetes 集群上的容器運行使用的計算資源沒有限制。 使用資源配額辩恼，集群管理員可以以名字空間為單位雇庙，限制其資源的使用與創(chuàng)建。 在命名空間中灶伊，一個 Pod 或 Container 最多能夠使用命名空間的資源配額所定義的 CPU 和內存用量状共。 有人擔心，一個 Pod 或 Container 會壟斷所有可用的資源谁帕。 LimitRange 是在命名空間內限制資源分配（給多個 Pod 或 Container）的策略對象峡继。

一個 LimitRange（限制范圍） 對象提供的限制能夠做到：

• 在一個命名空間中實施對每個 Pod 或 Container 最小和最大的資源使用量的限制。
• 在一個命名空間中實施對每個 PersistentVolumeClaim 能申請的最小和最大的存儲空間大小的限制匈挖。
• 在一個命名空間中實施對一種資源的申請值和限制值的比值的控制碾牌。
• 設置一個命名空間中對計算資源的默認申請/限制值，并且自動的在運行時注入到多個 Container 中

root@k8s-ansible-client:~/yaml/20211031/limit-case# cat test-limitrange.yaml 
apiVersion: v1
kind: LimitRange
metadata:
  name: limitrange-magedu
  namespace: pop
spec:
  limits:
  - type: Container       #限制的資源類型
    max:
      cpu: "2"            #限制單個容器的最大CPU
      memory: "2Gi"       #限制單個容器的最大內存
    min:
      cpu: "500m"         #限制單個容器的最小CPU
      memory: "512Mi"     #限制單個容器的最小內存
    default:
      cpu: "500m"         #默認單個容器的CPU限制
      memory: "512Mi"     #默認單個容器的內存限制
    defaultRequest:
      cpu: "500m"         #默認單個容器的CPU創(chuàng)建請求
      memory: "512Mi"     #默認單個容器的內存創(chuàng)建請求
    maxLimitRequestRatio:
      cpu: 2              #限制CPU limit/request比值最大為2  
      memory: 2         #限制內存limit/request比值最大為1.5
  - type: Pod
    max:
      cpu: "4"            #限制單個Pod的最大CPU
      memory: "4Gi"       #限制單個Pod最大內存
  - type: PersistentVolumeClaim
    max:
      storage: 50Gi        #限制PVC最大的requests.storage
    min:
      storage: 30Gi        #限制PVC最小的requests.storage

啟用LimitRange

root@k8s-ansible-client:~/yaml/20211031/limit-case# kubectl apply -f test-limitrange.yaml 
limitrange/limitrange-magedu created
root@k8s-ansible-client:~/yaml/20211031/limit-case# kubectl describe limitranges limit -n pop
Name:                  limitrange-magedu
Namespace:             pop
Type                   Resource  Min    Max   Default Request  Default Limit  Max Limit/Request Ratio
----                   --------  ---    ---   ---------------  -------------  -----------------------
Container              memory    512Mi  2Gi   512Mi            512Mi          2
Container              cpu       500m   2     500m             500m           2
Pod                    cpu       -      4     -                -              -
Pod                    memory    -      4Gi   -                -              -
PersistentVolumeClaim  storage   30Gi   50Gi  -                -              -

1.3.2 ResourceRequests/ResourceLimits 設置 Container 資源需求和上限

在 Container 級別可以對兩種計算資源進行管理：CPU 和內存儡循。ResourceRequests 表示容器希望被分配到的可完全保證的資源量舶吗，Requests 的值會被提供給 Kubernetes 調度器，以便優(yōu)化基于資源請求的容器調度择膝；ResourceLimits 表示容器能用的資源上限誓琼，這個上限的值會影響在節(jié)點上發(fā)生資源競爭時的解決策略。

yaml文件里面肴捉，加上以下參數：

resources:
   limits:
     cpu: 500m
     memory: 1Gi
   requests:
     cpu: 10m
     memory: 4Mi

1.4 Namespace 資源的請求和限制

在 Namespace 級別腹侣，可以通過創(chuàng)建 ResourceQuota 對象提供一個總體資源使用量限制：一方面可以設置該命名空間中 Pod 可以使用到的計算資源（CPU、內存）齿穗、存儲資源總量上限傲隶；另一方面可以限制該 Namespace 中某種類型對象（如 Pod、RC窃页、Service跺株、Secret、ConfigMap脖卖、PVC 等）的總量上限乒省。

root@k8s-ansible-client:~/yaml/20211031/limit-case# cat test-resourcequota-pop.yaml 
apiVersion: v1
kind: ResourceQuota
metadata:
  name: quota-magedu
  namespace: pop
spec:
  hard:
    requests.cpu: "46"
    limits.cpu: "46"
    requests.memory: 120Gi
    limits.memory: 120Gi
    requests.nvidia.com/gpu: 4
    pods: "20"
    services: "20"

**啟用ResourceQuota **

root@k8s-ansible-client:~/yaml/20211031/limit-case# kubectl apply -f test-resourcequota-pop.yaml 
resourcequota/quota-magedu created
root@k8s-ansible-client:~/yaml/20211031/limit-case# kubectl describe resourcequotas -n pop
Name:                    quota-magedu
Namespace:               pop
Resource                 Used  Hard
--------                 ----  ----
limits.cpu               0     46
limits.memory            0     120Gi
pods                     0     20
requests.cpu             0     46
requests.memory          0     120Gi
requests.nvidia.com/gpu  0     4
services                 2     20

2. k8s 多賬戶實現案例

2.1 鑒權簡介

在 k8s 中，你必須在鑒權（授予訪問權限）之前進行身份驗證（登錄）畦木，有關身份驗證的信息袖扛， 請參閱訪問控制概述.

k8s 期望請求中存在 REST API 常見的屬性。 這意味著 k8s 鑒權適用于現有的組織范圍或云提供商范圍的訪問控制系統(tǒng)馋劈， 除了 k8s API 之外攻锰，它還可以處理其他 API晾嘶。

k8s 使用 API 服務器對 API 請求進行鑒權。 它根據所有策略評估所有請求屬性來決定允許或拒絕請求娶吞。 一個 API 請求的所有部分都必須被某些策略允許才能繼續(xù)垒迂。 這意味著默認情況下拒絕權限。

（盡管 k8s 使用 API 服務器妒蛇，但是依賴于特定對象種類的特定字段的訪問控制 和策略由準入控制器處理机断。）

當系統(tǒng)配置了多個鑒權模塊時，k8s 將按順序使用每個模塊绣夺。 如果任何鑒權模塊批準或拒絕請求吏奸，則立即返回該決定，并且不會與其他鑒權模塊協(xié)商陶耍。 如果所有模塊對請求沒有意見奋蔚，則拒絕該請求。 被拒絕響應返回 HTTP 狀態(tài)代碼 403

2.2 k8s API請求屬性

• 用戶 - 身份驗證期間提供的 user 字符串烈钞。
• 組 - 經過身份驗證的用戶所屬的組名列表泊碑。
• 額外信息 - 由身份驗證層提供的任意字符串鍵到字符串值的映射。
• API - 指示請求是否針對 API 資源毯欣。
• 請求路徑 - 各種非資源端點的路徑馒过，如 /api 或 /healthz。
• API 請求動詞 - API 動詞 get酗钞、list腹忽、create、update砚作、patch窘奏、watch、 proxy偎巢、redirect蔼夜、delete 和 deletecollection 用于資源請求兼耀。 要確定資源 API 端點的請求動詞压昼，請參閱 確定請求動詞。
• HTTP 請求動詞 - HTTP 動詞 get瘤运、post窍霞、put 和 delete 用于非資源請求。
• Resource - 正在訪問的資源的 ID 或名稱（僅限資源請求）- 對于使用 get拯坟、update但金、patch 和 delete 動詞的資源請求，你必須提供資源名稱郁季。
• 子資源 - 正在訪問的子資源（僅限資源請求）冷溃。
• 名字空間 - 正在訪問的對象的名稱空間（僅適用于名字空間資源請求）钱磅。
• API 組 - 正在訪問的 API 組 （僅限資源請求）∷普恚空字符串表示核心 API 組盖淡。

2.3 請求動作

非資源請求

對于 /api/v1/... 或 /apis/<group>/<version>/... 之外的端點的請求被 視為“非資源請求（Non-Resource Requests）”，并使用該請求的 HTTP 方法的 小寫形式作為其請求動詞凿歼。 例如褪迟，對 /api 或 /healthz 這類端點的 GET 請求將使用 get 作為其動詞。

資源請求

要確定對資源 API 端點的請求動詞答憔，需要查看所使用的 HTTP 動詞以及該請求是針對 單個資源還是一組資源：

Kubernetes 有時使用專門的動詞以對額外的權限進行鑒權虐拓。例如：

• PodSecurityPolicy
  • policy API 組中 podsecuritypolicies 資源使用 use 動詞
• RBAC
  • 對 rbac.authorization.k8s.io API 組中 roles 和 clusterroles 資源的 bind 和 escalate 動詞
• 身份認證
  • 對核心 API 組中 users心俗、groups 和 serviceaccounts 以及 authentication.k8s.io API 組中的 userextras 所使用的 impersonate 動詞

2.4 鑒定模塊

• Node - 一個專用鑒權組件，根據調度到 kubelet 上運行的 Pod 為 kubelet 授予權限蓉驹。 了解有關使用節(jié)點鑒權模式的更多信息另凌，請參閱節(jié)點鑒權。
• ABAC - 基于屬性的訪問控制（ABAC）定義了一種訪問控制范型戒幔，通過使用將屬性組合 在一起的策略吠谢，將訪問權限授予用戶。策略可以使用任何類型的屬性（用戶屬性诗茎、資源屬性工坊、 對象，環(huán)境屬性等）敢订。要了解有關使用 ABAC 模式的更多信息王污，請參閱ABAC 模式。
• RBAC - 基于角色的訪問控制（RBAC）是一種基于企業(yè)內個人用戶的角色來管理對 計算機或網絡資源的訪問的方法楚午。在此上下文中昭齐，權限是單個用戶執(zhí)行特定任務的能力， 例如查看矾柜、創(chuàng)建或修改文件阱驾。要了解有關使用 RBAC 模式的更多信息，請參閱 RBAC 模式怪蔑。
  • 被啟用之后里覆，RBAC（基于角色的訪問控制）使用 rbac.authorization.k8s.io API 組來 驅動鑒權決策，從而允許管理員通過 Kubernetes API 動態(tài)配置權限策略缆瓣。
  • 要啟用 RBAC喧枷，請使用 --authorization-mode = RBAC 啟動 API 服務器。
• Webhook - WebHook 是一個 HTTP 回調：發(fā)生某些事情時調用的 HTTP POST； 通過 HTTP POST 進行簡單的事件通知隧甚。實現 WebHook 的 Web 應用程序會在發(fā)生某些事情時 將消息發(fā)布到 URL车荔。要了解有關使用 Webhook 模式的更多信息，請參閱Webhook 模式戚扳。

2.5 使用RBAC鑒權

基于角色（Role）的訪問控制（RBAC）是一種基于組織中用戶的角色來調節(jié)控制對 計算機或網絡資源的訪問的方法夸赫。

RBAC 鑒權機制使用 rbac.authorization.k8s.io API 組 來驅動鑒權決定，允許你通過 Kubernetes API 動態(tài)配置策略咖城。

要啟用 RBAC茬腿，在啟動 API 服務器 時將 --authorization-mode 參數設置為一個逗號分隔的列表并確保其中包含 RBAC。

kube-apiserver --authorization-mode=Example,RBAC --<其他選項> --<其他選項>

2.5.1 API對象

RBAC API 聲明了四種 Kubernetes 對象：Role宜雀、ClusterRole切平、RoleBinding 和 ClusterRoleBinding

Role 和 ClusterRole

RBAC 的 Role 或 ClusterRole 中包含一組代表相關權限的規(guī)則。 這些權限是純粹累加的（不存在拒絕某操作的規(guī)則）辐董。

Role 總是用來在某個名字空間 內設置訪問權限悴品；在你創(chuàng)建 Role 時，你必須指定該 Role 所屬的名字空間简烘。

與之相對苔严，ClusterRole 則是一個集群作用域的資源。這兩種資源的名字不同（Role 和 ClusterRole）是因為 Kubernetes 對象要么是名字空間作用域的孤澎，要么是集群作用域的届氢， 不可兩者兼具。

ClusterRole 有若干用法覆旭。你可以用它來：

1. 定義對某名字空間域對象的訪問權限退子，并將在各個名字空間內完成授權；
2. 為名字空間作用域的對象設置訪問權限型将，并跨所有名字空間執(zhí)行授權寂祥；
3. 為集群作用域的資源定義訪問權限。

RoleBinding 和 ClusterRoleBinding

角色綁定（Role Binding）是將角色中定義的權限賦予一個或者一組用戶七兜。 它包含若干 主體（用戶丸凭、組或服務賬戶）的列表和對這些主體所獲得的角色的引用。 RoleBinding 在指定的名字空間中執(zhí)行授權腕铸，而 ClusterRoleBinding 在集群范圍執(zhí)行授權惜犀。

一個 RoleBinding 可以引用同一的名字空間中的任何 Role。 或者恬惯，一個 RoleBinding 可以引用某 ClusterRole 并將該 ClusterRole 綁定到 RoleBinding 所在的名字空間向拆。 如果你希望將某 ClusterRole 綁定到集群中所有名字空間，你要使用 ClusterRoleBinding酪耳。

RoleBinding 或 ClusterRoleBinding 對象的名稱必須是合法的 路徑區(qū)段名稱。

2.5.2 命令空間指定帳號授權

在指定namespace創(chuàng)建賬戶

root@k8s-ansible-client:~/yaml/20211031/limit-case# kubectl create serviceaccount pop user1 -n  pop
serviceaccount/pop created

創(chuàng)建role規(guī)則：

root@k8s-ansible-client:~/yaml/20211031/role# cat pop-role.yaml
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: pop
  name: user1-role
rules:
- apiGroups: ["*"]
  resources: ["pods/exec"]
  #verbs: ["*"]
  ##RO-Role
  verbs: ["get", "list", "watch", "create"]

- apiGroups: ["*"]
  resources: ["pods"]
  #verbs: ["*"]
  ##RO-Role
  verbs: ["get", "list", "watch"]

- apiGroups: ["apps/v1"]
  resources: ["deployments"]
  #verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  ##RO-Role
  verbs: ["get", "watch", "list"]

root@k8s-ansible-client:~/yaml/20211031/role# kubectl apply  -f pop-role.yaml 
role.rbac.authorization.k8s.io/user1-role created

root@k8s-ansible-client:~/yaml/20211031/role# kubectl get roles.rbac.authorization.k8s.io -n pop
NAME         CREATED AT
user1-role   2021-11-13T15:29:22Z
root@k8s-ansible-client:~/yaml/20211031/role# kubectl describe roles.rbac.authorization.k8s.io -n pop
Name:         user1-role
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources            Non-Resource URLs  Resource Names  Verbs
  ---------            -----------------  --------------  -----
  pods.*/exec          []                 []              [get list watch create]
  pods.*               []                 []              [get list watch]
  deployments.apps/v1  []                 []              [get watch list]

將規(guī)則與賬戶進行綁定

root@k8s-ansible-client:~/yaml/20211031/role# cat pop-role-bind.yaml 
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: role-bind-pop
  namespace: pop
subjects:
- kind: ServiceAccount
  name: pop
  namespace: pop
roleRef:
  kind: Role
  name: user1-role
  apiGroup: rbac.authorization.k8s.io

root@k8s-ansible-client:~/yaml/20211031/role# kubectl apply -f pop-role-bind.yaml 
rolebinding.rbac.authorization.k8s.io/role-bind-pop created

root@k8s-ansible-client:~/yaml/20211031/role# kubectl describe rolebindings.rbac.authorization.k8s.io -n pop
Name:         role-bind-pop
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  Role
  Name:  user1-role
Subjects:
  Kind            Name  Namespace
  ----            ----  ---------
  ServiceAccount  pop   pop

獲取token

root@k8s-ansible-client:~/yaml/20211031/role# kubectl get secrets -n pop
NAME                  TYPE                                  DATA   AGE
default-token-4nrw2   kubernetes.io/service-account-token   3      24d
pop-token-spgzj       kubernetes.io/service-account-token   3      50m
test-tls-secret       Opaque                                2      14d
user1-token-7dsj9     kubernetes.io/service-account-token   3      14m
www-tls-secret        Opaque                                2      14d

root@k8s-ansible-client:~/yaml/20211031/role# kubectl describe secrets pop-token-spgzj -n pop
Name:         pop-token-spgzj
Namespace:    pop
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: pop
              kubernetes.io/service-account.uid: 4125ee58-e8cd-4d6a-b01d-9af9049edcb8

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1350 bytes
namespace:  3 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IlA3YjBkSVE3QWlJdzRNOVlfcGpHWWI3dTU3OUhtczZTVGJldk91TS1pejQifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJwb3AiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoicG9wLXRva2VuLXNwZ3pqIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6InBvcCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjQxMjVlZTU4LWU4Y2QtNGQ2YS1iMDFkLTlhZjkwNDllZGNiOCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpwb3A6cG9wIn0.MAZrhLoxXzm5CcGaRoSnJmXXVCKTins1wijOFE0OMLKSJO5sUQigd0w55veZS--1rrbLqOBENhQ7Mr5ULPBpH9ARR7TCSby1syG-fFRoWdRXuGCgA6Sy79LsWIFtiE0e93bFS7LfpfsdBdbDzDlccKxLmYfiCLjGqc60CJNWSP9W5woYIZpcOPGNnTa14cBQ44tN5hMQS5o0qGDfM05uXx_Q_mnyk8kbieJnrmNVFn5-9EiX8ELryaJ_onDKxLuILH8aoE2IE0oTuDuqAC178wilFbV2-2v38x4LEYW0s3AFO9T9x62kSdBh2I94dUb5Ai3AthwlEK9J7sVHrTJ0sA

登錄dashboard驗證

image.png

2.5.3 使用kube-config文件登錄dashboard

創(chuàng)建csr文件

root@k8s-ansible-client:~/yaml/20211031/role# cat pop-csr.json 
{
  "CN": "China",
  "hosts": [],
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "CN",
      "ST": "BeiJing",
      "L": "BeiJing",
      "O": "k8s",
      "OU": "System"
    }
  ]
}

自簽證書

# 從mater把ssl里面的證書cp過來
root@k8s-ansible-client:~/yaml/20211031/role# cfssl gencert -ca=/etc/kubernetes/ssl/ca.pem  -ca-key=/etc/kubernetes/ssl/ca-key.pem -config=/etc/kubeasz/clusters/k8s-pop/ssl/ca-config.json -profile=kubernetes pop-csr.json | cfssljson -bare  pop
2021/11/14 00:47:41 [INFO] generate received request
2021/11/14 00:47:41 [INFO] received CSR
2021/11/14 00:47:41 [INFO] generating key: rsa-2048
2021/11/14 00:47:42 [INFO] encoded CSR
2021/11/14 00:47:42 [INFO] signed certificate with serial number 322870458312346521644247569939536038641391898096
2021/11/14 00:47:42 [WARNING] This certificate lacks a "hosts" field. This makes it unsuitable for
websites. For more information see the Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates, v.1.1.6, from the CA/Browser Forum (https://cabforum.org);
specifically, section 10.2.3 ("Information Requirements").

生成普通用戶kubeconfig文件

root@k8s-ansible-client:~/yaml/20211031/role# kubectl config set-cluster k8s-pop --certificate-authority=/etc/kubernetes/ssl/ca.pem --embed-certs=true --server=https://192.168.20.201:6443 --kubeconfig=pop.kubeconfig
Cluster "k8s-pop" set.

root@k8s-ansible-client:~/yaml/20211031/role# cat pop.kubeconfig 
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR1RENDQXFDZ0F3SUJBZ0lVQmNTQWZraUVkdFpPM0pGYjZZNmpza1JEdEJnd0RRWUpLb1pJaHZjTkFRRUwKQlFBd1lURUxNQWtHQTFVRUJoTUNRMDR4RVRBUEJnTlZCQWdUQ0VoaGJtZGFhRzkxTVFzd0NRWURWUVFIRXdKWQpVekVNTUFvR0ExVUVDaE1EYXpoek1ROHdEUVlEVlFRTEV3WlRlWE4wWlcweEV6QVJCZ05WQkFNVENtdDFZbVZ5CmJtVjBaWE13SUJjTk1qRXdPVEkwTVRRME56QXdXaGdQTWpFeU1UQTRNekV4TkRRM01EQmFNR0V4Q3pBSkJnTlYKQkFZVEFrTk9NUkV3RHdZRFZRUUlFd2hJWVc1bldtaHZkVEVMTUFrR0ExVUVCeE1DV0ZNeEREQUtCZ05WQkFvVApBMnM0Y3pFUE1BMEdBMVVFQ3hNR1UzbHpkR1Z0TVJNd0VRWURWUVFERXdwcmRXSmxjbTVsZEdWek1JSUJJakFOCkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4QU1JSUJDZ0tDQVFFQTQyRkhYRlV5VHpGRGtLNGRZQmNVOVBDb2doUUQKMzM1WUU2N1UwK3poK0FVd201c0IvbGVBM25wMGVCakdqUzhnVTM3Y0t1V0haQ3BTMHpLZjF5dTR0VE9ia0p2UwovamxlZWI5ekxSQTEwc1NMVHRNV1cxMWxLNm84cWtmeWh5eFJxN0RqaGhGRTZxWndzWWxqR2t6Wm1zak5TelVBCmdhcy9YQkNOYVVBajZvWVBJc1lkMlJQeGFvVzA4VHd1UVRXcURCbkNUaWZ5c2xaUzdPUWNWL2FZQWVKQ3BPMHUKcnY3dlJRSCs0V3ZNTThyRHdyaSs1aHBsUi9ITnJHSWMzUVI5V3R3VFNhUm9RNzlHMHdGTXVvT0xKcXhNVnVoVQpKSnYxdzRYUlpkOVlYYlVkZVFMYVRpWTZMRE1ycXovYnpEdGs3YkVaRE5JN2ZqVTB6c3pkRGhEVjJ3SURBUUFCCm8yWXdaREFPQmdOVkhROEJBZjhFQkFNQ0FRWXdFZ1lEVlIwVEFRSC9CQWd3QmdFQi93SUJBakFkQmdOVkhRNEUKRmdRVTZhUzJpcWlwVW16UHdIQ2h2ZkhtUjA1NG9ySXdId1lEVlIwakJCZ3dGb0FVNmFTMmlxaXBVbXpQd0hDaAp2ZkhtUjA1NG9ySXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBQVlSb0V5YVZ2akRSRlZDMWFoTVFaMTJwTGhPCnBDQlJGN2pSREE4VUs4RHArUmh2bVRkNGlNb1QvejM4MnFEcjlnTnU0bGp6V0FRalI0UWcyZU5aVEkzYnUyN2YKcGUxZGZCSGpVUEtXTWRUeDd3d3ZyK041UElXZzBEVVpabmFqenZkOWVOVkZEN2Q4ejRIUEl6ZEVyTHQ5b1l0MQpMTDBhdVhxdkdRbU9SUExNVXZEMTY2RWVSQVZtYlo0WFhPSkI2LzZDWWdiK2xYNXQ2WWRaZm5PYUswaWRNQ1RyCkc4WDd6eTdOSUVOTW1tWUtHekRPTStRYUpoUHYwbFJoWUNRd0dQMElRVlBPSjErL3ZoVU9WQUVMdmZWTnV2VkkKQU4xM0c3Qm9WUTdoQ00yOE5GRWJ1RWFtYVNSc1pIa1o1U1d4YzZVdWFnNUx6QW5JZUpTWCs0bE9lUk09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
    server: https://192.168.20.201:6443
  name: k8s-pop
contexts: null
current-context: ""
kind: Config
preferences: {}
users: null

設置客戶端認證參數

root@k8s-ansible-client:~/yaml/20211031/role# kubectl config set-credentials pop \
> --client-certificate=pop.pem \
> --client-key=pop-key.pem \
> --embed-certs=true \
> --kubeconfig=pop.kubeconfig
User "pop" set.
root@k8s-ansible-client:~/yaml/20211031/role# cat pop.kubeconfig 
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR1RENDQXFDZ0F3SUJBZ0lVQmNTQWZraUVkdFpPM0pGYjZZNmpza1JEdEJnd0RRWUpLb1pJaHZjTkFRRUwKQlFBd1lURUxNQWtHQTFVRUJoTUNRMDR4RVRBUEJnTlZCQWdUQ0VoaGJtZGFhRzkxTVFzd0NRWURWUVFIRXdKWQpVekVNTUFvR0ExVUVDaE1EYXpoek1ROHdEUVlEVlFRTEV3WlRlWE4wWlcweEV6QVJCZ05WQkFNVENtdDFZbVZ5CmJtVjBaWE13SUJjTk1qRXdPVEkwTVRRME56QXdXaGdQTWpFeU1UQTRNekV4TkRRM01EQmFNR0V4Q3pBSkJnTlYKQkFZVEFrTk9NUkV3RHdZRFZRUUlFd2hJWVc1bldtaHZkVEVMTUFrR0ExVUVCeE1DV0ZNeEREQUtCZ05WQkFvVApBMnM0Y3pFUE1BMEdBMVVFQ3hNR1UzbHpkR1Z0TVJNd0VRWURWUVFERXdwcmRXSmxjbTVsZEdWek1JSUJJakFOCkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4QU1JSUJDZ0tDQVFFQTQyRkhYRlV5VHpGRGtLNGRZQmNVOVBDb2doUUQKMzM1WUU2N1UwK3poK0FVd201c0IvbGVBM25wMGVCakdqUzhnVTM3Y0t1V0haQ3BTMHpLZjF5dTR0VE9ia0p2UwovamxlZWI5ekxSQTEwc1NMVHRNV1cxMWxLNm84cWtmeWh5eFJxN0RqaGhGRTZxWndzWWxqR2t6Wm1zak5TelVBCmdhcy9YQkNOYVVBajZvWVBJc1lkMlJQeGFvVzA4VHd1UVRXcURCbkNUaWZ5c2xaUzdPUWNWL2FZQWVKQ3BPMHUKcnY3dlJRSCs0V3ZNTThyRHdyaSs1aHBsUi9ITnJHSWMzUVI5V3R3VFNhUm9RNzlHMHdGTXVvT0xKcXhNVnVoVQpKSnYxdzRYUlpkOVlYYlVkZVFMYVRpWTZMRE1ycXovYnpEdGs3YkVaRE5JN2ZqVTB6c3pkRGhEVjJ3SURBUUFCCm8yWXdaREFPQmdOVkhROEJBZjhFQkFNQ0FRWXdFZ1lEVlIwVEFRSC9CQWd3QmdFQi93SUJBakFkQmdOVkhRNEUKRmdRVTZhUzJpcWlwVW16UHdIQ2h2ZkhtUjA1NG9ySXdId1lEVlIwakJCZ3dGb0FVNmFTMmlxaXBVbXpQd0hDaAp2ZkhtUjA1NG9ySXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBQVlSb0V5YVZ2akRSRlZDMWFoTVFaMTJwTGhPCnBDQlJGN2pSREE4VUs4RHArUmh2bVRkNGlNb1QvejM4MnFEcjlnTnU0bGp6V0FRalI0UWcyZU5aVEkzYnUyN2YKcGUxZGZCSGpVUEtXTWRUeDd3d3ZyK041UElXZzBEVVpabmFqenZkOWVOVkZEN2Q4ejRIUEl6ZEVyTHQ5b1l0MQpMTDBhdVhxdkdRbU9SUExNVXZEMTY2RWVSQVZtYlo0WFhPSkI2LzZDWWdiK2xYNXQ2WWRaZm5PYUswaWRNQ1RyCkc4WDd6eTdOSUVOTW1tWUtHekRPTStRYUpoUHYwbFJoWUNRd0dQMElRVlBPSjErL3ZoVU9WQUVMdmZWTnV2VkkKQU4xM0c3Qm9WUTdoQ00yOE5GRWJ1RWFtYVNSc1pIa1o1U1d4YzZVdWFnNUx6QW5JZUpTWCs0bE9lUk09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
    server: https://192.168.20.201:6443
  name: k8s-pop
contexts: null
current-context: ""
kind: Config
preferences: {}
users:
- name: pop
  user:
    client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUQwRENDQXJpZ0F3SUJBZ0lVT0k0REYzdmg0NHBNTndtTmVjb0tUdXA0RGZBd0RRWUpLb1pJaHZjTkFRRUwKQlFBd1lURUxNQWtHQTFVRUJoTUNRMDR4RVRBUEJnTlZCQWdUQ0VoaGJtZGFhRzkxTVFzd0NRWURWUVFIRXdKWQpVekVNTUFvR0ExVUVDaE1EYXpoek1ROHdEUVlEVlFRTEV3WlRlWE4wWlcweEV6QVJCZ05WQkFNVENtdDFZbVZ5CmJtVjBaWE13SUJjTk1qRXhNVEV6TVRZME16QXdXaGdQTWpBM01URXhNREV4TmpRek1EQmFNR0F4Q3pBSkJnTlYKQkFZVEFrTk9NUkF3RGdZRFZRUUlFd2RDWldsS2FXNW5NUkF3RGdZRFZRUUhFd2RDWldsS2FXNW5NUXd3Q2dZRApWUVFLRXdOck9ITXhEekFOQmdOVkJBc1RCbE41YzNSbGJURU9NQXdHQTFVRUF4TUZRMmhwYm1Fd2dnRWlNQTBHCkNTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCQVFER2lJS2VHRTJMQ3VCZGFqUjF5ZVMrYUZTQThTODgKNUdNUXNEQ3NLOEdQYjVuRTVXNUhFQ3hDYlBJeisrenc0Y3lMelhyakxOM3hURzUwWUlPc1kwQmVSYXpJNnZWbwpKWEUvd0pSeUJxTmxweDkxcVYwK1VkR1M2S2ZCdkVFNlhDdzc5emE4d1F3QkEzN016OW5McGtHWkpqWVoyOThzCkZDR3kwb3FZSk1HTFZpNzVZb3VxS2QreHY1R21Jck5kZnl0K3h2OUlHV2hRN3dhWWx2V0VDd0dRaHU0RkhsbW0KRGQyZmNzRlFCcHRBT1lVVmNmZzZYRmVlSVd5dlNEeE5wTDdoNFNQVllyNFgrS05zZ202ZExFaW15eWRJZmNuWAo3SndlcFRPOXRJMnFiV3dvQ2VyRzVIbnBuWDErdUdwY0s3cElBZE5sRktVNFp2QTljZ0VyZVJJUkFnTUJBQUdqCmZ6QjlNQTRHQTFVZER3RUIvd1FFQXdJRm9EQWRCZ05WSFNVRUZqQVVCZ2dyQmdFRkJRY0RBUVlJS3dZQkJRVUgKQXdJd0RBWURWUjBUQVFIL0JBSXdBREFkQmdOVkhRNEVGZ1FVNkszaVNQRWFuM1lSeHcveEt5NndwNE8zdmo0dwpId1lEVlIwakJCZ3dGb0FVNmFTMmlxaXBVbXpQd0hDaHZmSG1SMDU0b3JJd0RRWUpLb1pJaHZjTkFRRUxCUUFECmdnRUJBSzd5cDVZd09nVFF6TXBEeElHM3hLOVV1dnVHbS8zNXNTWHNQVWpnVHRaWUJuNnVUdGFkaUw0NlBIcHIKVVhDUGhxUEYvOHlYZE1UKzZJTysxcytndmNOSjkwZnFJTXdyTFhoc1ZzaVNSZUpwS3FoN3c0ZnFrY1EyV05PRwoxNFRlN3hTbnUraWFRZnM5UFpuRndvRzZ3QWtqRWdiNG9IdEk3R1JST3JKKzBZVU9oTHVuRHN0NEN6NFZvSUdmCndiRFgxSlNwUTVKbnlZWndRN1NkVE1NNUxoSC9QNkc3TjdKOWxFR3RUQVdvb2RmQTZNSFloYmxMRTcrQWlYYS8KeTVaTDMvelE5MXVtcEJGcnkvUi9kaWxvaHlrTW9aVmRDZ3BxcDBFanhQTklsRXdNYVJIRk85NmhWdnV3K3YxUApMbDAxMDJsUnI0RTNZV3pLVzU4NEc5VzN3UkE9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
    client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBeG9pQ25oaE5pd3JnWFdvMGRjbmt2bWhVZ1BFdlBPUmpFTEF3ckN2QmoyK1p4T1Z1ClJ4QXNRbXp5TS92czhPSE1pODE2NHl6ZDhVeHVkR0NEckdOQVhrV3N5T3IxYUNWeFA4Q1VjZ2FqWmFjZmRhbGQKUGxIUmt1aW53YnhCT2x3c08vYzJ2TUVNQVFOK3pNL1p5NlpCbVNZMkdkdmZMQlFoc3RLS21DVEJpMVl1K1dLTApxaW5mc2IrUnBpS3pYWDhyZnNiL1NCbG9VTzhHbUpiMWhBc0JrSWJ1QlI1WnBnM2RuM0xCVUFhYlFEbUZGWEg0Ck9seFhuaUZzcjBnOFRhUys0ZUVqMVdLK0YvaWpiSUp1blN4SXBzc25TSDNKMSt5Y0hxVXp2YlNOcW0xc0tBbnEKeHVSNTZaMTlmcmhxWEN1NlNBSFRaUlNsT0did1BYSUJLM2tTRVFJREFRQUJBb0lCQUdmQVpVcExkeEtudjNMeQpFckpQclF2WXAvaXVram9uUEtJM0FXaW9nVUg5VjRXdlJMODhjM1RQVEkvZ0l3WUxhb0xSQWx5QVVRaE9JaGNOCmJTS0V4OW04WGJ5dUZVdTA3WWNjbERjMnd1Tlh3RGdVSjFkdkdLL0dpQXpWM2R5cTJLOEoxWUEwL3BuMUFxbjAKSVdTczRQRXhKK3JCbmRLQ1BzNGQrekhoVzRmOXVXUnBrdkVIWS82c0ZuZ3dYVUI1bTA1SkRGZUJwWkZtSDEvRgpJRmZyY3FmNTR1YldkRGk3YWlxTG54ZHdNUG9WRnNKdnhneDNQcTBjdjBEUHZDOFVNN2h5MHpnb1h1SERCSW92CkdDeWw3c3I3NmVKcHgweE1yVFQ0RGdlWENzUzIvcXRHNDYxaVJ5a0lYVHhkc2M1RWNrcmZ4QVlUdVZ3QXF5eDcKNU4xTjh2RUNnWUVBNW0rMENKYXJFSlo5Sm8rL3hzZ0VPY2JBd2FnSHY1VnFCVlE1ZmhFbTdxcUZrNC96aUhsYwpSdXA2OUp1c3FnWm5Cd0dtMGVOOHdYT3AwcHYvcVlMUDBtNXpISjZTM1ozQ1Y3ZFFmenZ1dlE1MEpxM1BYY0RHCkxhbUtFazBsMzBROGhoQjlJRTB4R1ZTMUl2UHovRHFaeHA2TFdMUDZhaDZNL3g5Y3JXWnpkTDBDZ1lFQTNJN0YKcmt3MEJHdy9OQUVvMjR6aXEvNzAwOWpZdnhUWUhDdFFVVnVHMHJBWUNqWXd4RGczQXlnK2NnbEtsL3ZWbEtsdQp0dUFSbXlRdmNFdVRTR1FOV0Ewb1F4Z0UrZ1J4SWxPV0NIOGxVUXZ1Szh4RGFzQjdRK1JQNnJDNy9YSVZ3V0hCCkcwSjBxdzZWZVBkSzVmTk16cEg4QTlpQTJ0WTBraWg4ejdwakNlVUNnWUFyNVROaVAzRXVvN3dMVUc2enF2NUQKRXowOHBvbHpVVDcwN09wV3ZXV3hLUUp3N1lieWhFdXpwbzd0Y1lvZWlVR3U3LzJiRmI1NkMxSmFNQ1V2WVIrOQpjaFN6YXZHSERib3JnMXZ1SUxpRmd1OVZQdDYxZVRkSEUzaWRxOXgrL3p5WVBTUFl0MXVXKzYvVmpLcjViU0JGCjJZV3B5Lzd6b0FZend3R2dkbGVmOFFLQmdCdnNNMWlxcXhjNFFSUXJaV25PUDFBNUdmUE1Denk5dmRKckpXTDMKYkcwMkFBVWk4UytXVWxpaStxempRajlWa2FlZGY3ZkZURlZRMG5Tc0RMeG9ka3dFZG1sd0hBa3ZFTWVndjJqWgo5L1ozeFRKa1ROQ3lCNmtEdVo1anU1a05uWFY3RThDSXZFNS9yU3JBWEFvYXNFbWlyNzRvNWI5T3lSOEw0eWxGClZvNkZBb0dCQU1naFU1LzBHOFM5eEk4a05kSFltZkxqS3VtZUR6ZmxSNGwyUDhoZE96UElwbmc5NlN2dGhtaW8KQnduVjk5U2hzMkhGMFNsQzZ3VCtJbCtrc2Vta0VyeHduQWh4ZThJb1NYcklMVWp4NFlNdXhLT2pLaXh5emJrdwpkMG42ZUJFMXhCcTk2ZmlFZFNRcVIrbHY1R0djYVNHb3UySlRTbDc0cW03ZU1YY2x2RjdLCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==

設置上下文參數(多集群使用上下文區(qū)分)

root@k8s-ansible-client:~/yaml/20211031/role# kubectl config set-context k8s-pop \
> --cluster=k8s-pop \
> --user=pop \
> --namespace=pop \
> --kubeconfig=pop.kubeconfig
Context "k8s-pop" created.

設置默認上下文

root@k8s-ansible-client:~/yaml/20211031/role# kubectl config use-context k8s-pop --kubeconfig=pop.kubeconfig
Switched to context "k8s-pop".

將pop用戶token寫入用戶kube-config文件

root@k8s-ansible-client:~/yaml/20211031/role# kubectl describe secrets pop-token-spgzj -n pop
Name:         pop-token-spgzj
Namespace:    pop
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: pop
              kubernetes.io/service-account.uid: 4125ee58-e8cd-4d6a-b01d-9af9049edcb8

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1350 bytes
namespace:  3 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IlA3YjBkSVE3QWlJdzRNOVlfcGpHWWI3dTU3OUhtczZTVGJldk91TS1pejQifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJwb3AiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoicG9wLXRva2VuLXNwZ3pqIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6InBvcCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjQxMjVlZTU4LWU4Y2QtNGQ2YS1iMDFkLTlhZjkwNDllZGNiOCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpwb3A6cG9wIn0.MAZrhLoxXzm5CcGaRoSnJmXXVCKTins1wijOFE0OMLKSJO5sUQigd0w55veZS--1rrbLqOBENhQ7Mr5ULPBpH9ARR7TCSby1syG-fFRoWdRXuGCgA6Sy79LsWIFtiE0e93bFS7LfpfsdBdbDzDlccKxLmYfiCLjGqc60CJNWSP9W5woYIZpcOPGNnTa14cBQ44tN5hMQS5o0qGDfM05uXx_Q_mnyk8kbieJnrmNVFn5-9EiX8ELryaJ_onDKxLuILH8aoE2IE0oTuDuqAC178wilFbV2-2v38x4LEYW0s3AFO9T9x62kSdBh2I94dUb5Ai3AthwlEK9J7sVHrTJ0sA

# token放在最后
root@k8s-ansible-client:~/yaml/20211031/role# vim pop.kubeconfig
...
    token: eyJhbGciOiJSUzI1NiIsImtpZCI6IlA3YjBkSVE3QWlJdzRNOVlfcGpHWWI3dTU3OUhtczZTVGJldk91TS1pejQifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJwb3AiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoicG9wLXRva2VuLXNwZ3pqIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6InBvcCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjQxMjVlZTU4LWU4Y2QtNGQ2YS1iMDFkLTlhZjkwNDllZGNiOCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpwb3A6cG9wIn0.MAZrhLoxXzm5CcGaRoSnJmXXVCKTins1wijOFE0OMLKSJO5sUQigd0w55veZS--1rrbLqOBENhQ7Mr5ULPBpH9ARR7TCSby1syG-fFRoWdRXuGCgA6Sy79LsWIFtiE0e93bFS7LfpfsdBdbDzDlccKxLmYfiCLjGqc60CJNWSP9W5woYIZpcOPGNnTa14cBQ44tN5hMQS5o0qGDfM05uXx_Q_mnyk8kbieJnrmNVFn5-9EiX8ELryaJ_onDKxLuILH8aoE2IE0oTuDuqAC178wilFbV2-2v38x4LEYW0s3AFO9T9x62kSdBh2I94dUb5Ai3AthwlEK9J7sVHrTJ0sA

測試登錄

image.png

image.png

3. k8s 網絡

容器網絡主要問題：

• 高度耦合的容器間通信
• Pod與Pod之間通信
• Pod與Service之間通信
• Pod到外網之間通信

kubernetes CNI
CNI是Container Network Interface的縮寫，它是一個通用的容器網絡插件的k8s網絡接口碗暗，開源社區(qū)里已經有了很多實現容器網絡的方案颈将，不同的網絡實現方案在k8s內都是以插件調用的形式工作，所以這里需要一個統(tǒng)一的標準接口言疗。如果將k8s的Pod視為一臺“虛擬機”晴圾，那么網絡插件的工作就是管理這臺虛擬機的網絡棧，包括給這臺虛擬機插入網卡噪奄、配置路由死姚、IP等；而CNI的工作則是對接網絡插件和kubelet容器運行時管理工具（對于docker容器運行時來說實際上是dockershim）勤篮，主要體現在Pod的創(chuàng)建和刪除過程

CNI插件常用的三種實現模式：
Overlay: 靠隧道打通都毒，不依賴底層網絡
macvlan：靠路由打通，部分依賴底層網絡
underlay ：靠底層網絡能力打通碰缔，強依賴底層

3.1 Overlay

Overlay 在網絡技術領域账劲，指的是一種網絡架構上疊加的虛擬化技術模式，其大體框架是對基礎網絡不進行大規(guī)模修改的條件下金抡，實現應用在網絡上的承載瀑焦，并能與其它網絡業(yè)務分離，并且以基于IP的基礎網絡技術為主梗肝。Overlay 技術是在現有的物理網絡之上構建一個虛擬網絡榛瓮，上層應用只與虛擬網絡相關。一個Overlay網絡主要由三部分組成：

• 邊緣設備：是指與虛擬機直接相連的設備
• 控制平面：主要負責虛擬隧道的建立維護以及主機可達性信息的通告
• 轉發(fā)平面：承載 Overlay 報文的物理網絡巫击。

3.1.1 網絡實現方式

VLAN
VLAN (Virtual Local Area Network)意為虛擬局域網榆芦，是在交換機實現過程中涉及到的概念，由802.1Q標準所定義喘鸟。由于交換機是工作在鏈路層的網絡設備匆绣，連接在同一臺交換機的終端處于同一個三層網中，同時也處于同一個廣播域什黑。當交換機接入較多的終端時崎淳，任意一臺終端發(fā)送廣播報文時（例如：ARP請求），報文都會傳遍整個網絡愕把。對于規(guī)模較大的組網場景拣凹，廣播報文的泛濫對于網絡通信將會造成較大的影響。VLAN技術為這一問題提供了解決方案恨豁，VLAN將同一網絡劃分為多個邏輯上的虛擬子網嚣镜，并規(guī)定當收到廣播報文時，僅僅在其所在VLAN中進行廣播從而防止廣播報文泛濫橘蜜。VLAN技術在鏈路層的層次中實現了廣播域的隔離菊匿。

image.png

VXLAN
VXLAN由RFC7348定義，這是2014年定稿的一個協(xié)議佩厚，VXLAN協(xié)議將Ethernet幀封裝在UDP內姆钉，再加上8個字節(jié)的VXLAN header，用來標識不同的二層網絡抄瓦。VXLAN在三層網絡基礎上構建大二層網絡潮瓶，其物理承載是傳統(tǒng)三層網絡以及專用的VTEP設備。VTEP（VXLAN Tunnel EndPoint）負責VXLAN報文的封裝和解封钙姊，對虛擬機隱藏了其鏈路層幀的轉發(fā)細節(jié)毯辅。

image.png

• 最內層的是VXLAN報文，由VXLAN報文頭部和L2幀組成摸恍。其中頭部包含最重要的字段是VNID悉罕，類似于VLAN中的VID，用于分隔虛擬網絡的二層域空間立镶；
• VXLAN報文被VTEP封裝在UDP報文中壁袄，由VTEP負責封裝和解封；
• Mac幀頭部和IP頭部也是由VTEP進行裝載媚媒，傳輸的過程就是從本地虛擬機所屬的VTEP到目的虛擬機所屬的VTEP嗜逻，對虛擬機隱藏底層傳輸細節(jié)。

VXLAN與VLAN的最大區(qū)別在于缭召，VLAN只是修改了原始的以太網幀頭部栈顷，但是整個網絡數據包還是原來那個數據包，而VXLAN是將原始的以太網幀隱藏在UDP數據里面嵌巷。經過VTEP封裝之后萄凤，在網絡線路上看起來只有VTEP之間的UDP數據傳遞，傳輸細節(jié)對虛擬機透明搪哪，從而做到了在L3網絡上構建虛擬L2網絡靡努。

VXLAN網絡中傳輸的建立依賴于VTEP的組播實現虛擬L2網絡的ARP功能。假設虛擬機A與虛擬機B要進行通信晓折，虛擬機A會將以太網幀發(fā)送給本地VTEP A惑朦，VTEP A將該數據幀封裝后進行端到端傳輸，發(fā)送給虛擬機B的本地VTEP B漓概，接下來就是解封數據幀再廣播給虛擬機B的過程了漾月。

優(yōu)勢：
相比VLAN所支持的二層網絡數量多更多
更為靈活的虛擬機部署——VXLAN可以實現構建在三層網絡上的大二層網絡網絡，通過UDP在L3網絡上傳輸L2網絡數據胃珍，便于虛擬機遷移等梁肿。

缺點：
VXLAN是一種overlay網絡蜓陌，不能獨立存在，必須依賴underlay網絡栈雳，而在構建underlay網絡時护奈，還是需要借助VLAN缔莲。
VXLAN的優(yōu)勢是在大規(guī)模環(huán)境下哥纫，如果數據中心的規(guī)模較小，那么VXLAN將會浪費很多網絡性能痴奏。
需要專屬設備支持蛀骇。
VXLAN因為需要進行外層封裝，每個以太網幀的傳輸都會浪費50字節(jié)读拆，對于小報文的傳輸將會有極大的浪費擅憔。

3.1.2 Flannel

簡介

Flannel是CoreOS團隊針對Kubernetes設計的一個網絡規(guī)劃服務，簡單來說檐晕，它的功能是讓集群中的不同節(jié)點主機創(chuàng)建的Docker容器都具有全集群唯一的虛擬IP地址暑诸。

在默認的Docker配置中，每個節(jié)點上的Docker服務會分別負責所在節(jié)點容器的IP分配辟灰。這樣導致的一個問題是个榕，不同節(jié)點上容器可能獲得相同的內外IP地址。并使這些容器之間能夠之間通過IP地址相互找到芥喇，也就是相互ping通西采。

Flannel的設計目的就是為集群中的所有節(jié)點重新規(guī)劃IP地址的使用規(guī)則，從而使得不同節(jié)點上的容器能夠獲得“同屬一個內網”且”不重復的”IP地址继控，并讓屬于不同節(jié)點上的容器能夠直接通過內網IP通信械馆。

Flannel實質上是一種“覆蓋網絡(overlaynetwork)”，也就是將TCP數據包裝在另一種網絡包里面進行路由轉發(fā)和通信武通，目前已經支持udp霹崎、vxlan、host-gw冶忱、aws-vpc尾菇、gce和alloc路由等數據轉發(fā)方式，默認的節(jié)點間數據通信方式是UDP轉發(fā)朗和。

特點

• 使集群中的不同Node主機創(chuàng)建的Docker容器都具有全集群唯一的虛擬IP地址错沽。

• 建立一個覆蓋網絡（overlay network），通過這個覆蓋網絡眶拉，將數據包原封不動的傳遞到目標容器千埃。覆蓋網絡是建立在另一個網絡之上并由其基礎設施支持的虛擬網絡。覆蓋網絡通過將一個分組封裝在另一個分組內來將網絡服務與底層基礎設施分離忆植。在將封裝的數據包轉發(fā)到端點后放可，將其解封裝谒臼。

• 創(chuàng)建一個新的虛擬網卡flannel0接收docker網橋的數據，通過維護路由表耀里，對接收到的數據進行封包和轉發(fā)（vxlan）蜈缤。

• etcd保證了所有node上flanned所看到的配置是一致的。同時每個node上的flanned監(jiān)聽etcd上的數據變化冯挎，實時感知集群中node的變化底哥。

架構圖

image.png

Cni0:網橋設備，每創(chuàng)建一個pod都會創(chuàng)建一對 veth pair房官。其中一端是pod中的eth0趾徽，另一端是Cni0網橋中的端口（網卡）。Pod中從網卡eth0發(fā)出的流量都會發(fā)送到Cni0網橋設備的端口（網卡）上翰守。

Flannel.1: overlay網絡的設備孵奶，用來進行 vxlan 報文的處理（封包和解包）。不同node之間的pod數據流量都從overlay設備以隧道的形式發(fā)送到對端蜡峰。

Flanneld：flannel在每個主機中運行flanneld作為agent了袁，它會為所在主機從集群的網絡地址空間中，獲取一個小的網段subnet湿颅，本主機內所有容器的IP地址都將從中分配载绿。同時Flanneld監(jiān)聽K8s集群數據庫，為flannel.1設備提供封裝數據時必要的mac肖爵，ip等網絡數據信息卢鹦。

不同node上的pod的通信流程：

• pod中產生數據，根據pod的路由信息劝堪，將數據發(fā)送到Cni0
• Cni0 根據節(jié)點的路由表冀自，將數據發(fā)送到隧道設備flannel.1
• Flannel.1查看數據包的目的ip，從flanneld獲得對端隧道設備的必要信息秒啦，封裝數據包熬粗。
• Flannel.1將數據包發(fā)送到對端設備。對端節(jié)點的網卡接收到數據包余境，發(fā)現數據包為overlay數據包驻呐，解開外層封裝，并發(fā)送內層封裝到flannel.1設備芳来。
• Flannel.1設備查看數據包含末，根據路由表匹配，將數據發(fā)送給Cni0設備即舌。
• Cni0匹配路由表佣盒，發(fā)送數據給網橋上對應的端口。

存在的問題

• 不支持pod之間的網絡隔離顽聂。Flannel設計思想是將所有的pod都放在一個大的二層網絡中肥惭，所以pod之間沒有隔離策略盯仪。

• 設備復雜，效率不高蜜葱。Flannel模型下有三種設備全景，數量經過多種設備的封裝、解析牵囤，勢必會造成傳輸效率的下降爸黄。

3.1.3 Calico

Calico 是一種容器之間互通的網絡方案。在虛擬化平臺中奔浅，比如 OpenStack馆纳、Docker 等都需要實現 workloads 之間互連诗良，但同時也需要對容器做隔離控制汹桦，就像在 Internet 中的服務僅開放80端口、公有云的多租戶一樣鉴裹，提供隔離和管控機制舞骆。而在多數的虛擬化平臺實現中，通常都使用二層隔離技術來實現容器的網絡径荔，這些二層的技術有一些弊端督禽，比如需要依賴 VLAN薇正、bridge 和隧道等技術需频，其中 bridge 帶來了復雜性，vlan 隔離和 tunnel 隧道則消耗更多的資源并對物理環(huán)境有要求夭坪，隨著網絡規(guī)模的增大鹦马，整體會變得越加復雜胧谈。我們嘗試把 Host 當作 Internet 中的路由器，同樣使用 BGP 同步路由荸频，并使用 iptables 來做安全訪問策略菱肖，最終設計出了 Calico 方案。

特點
1.更優(yōu)的資源利用

二層網絡通訊需要依賴廣播消息機制旭从，廣播消息的開銷與 host 的數量呈指數級增長稳强，Calico 使用的三層路由方法，則完全抑制了二層廣播和悦，減少了資源開銷退疫。

另外，二層網絡使用 VLAN 隔離技術鸽素，天生有 4096 個規(guī)格限制褒繁，即便可以使用 vxlan 解決，但 vxlan 又帶來了隧道開銷的新問題付鹿。而 Calico 不使用 vlan 或 vxlan 技術澜汤，使資源利用率更高蚜迅。

2.可擴展性

Calico 使用與 Internet 類似的方案，Internet 的網絡比任何數據中心都大俊抵，Calico 同樣天然具有可擴展性谁不。

3.簡單而更容易 debug

因為沒有隧道，意味著 workloads 之間路徑更短更簡單徽诲，配置更少刹帕，在 host 上更容易進行 debug 調試。

4.更少的依賴

Calico 僅依賴三層路由可達谎替。

5.可適配性

Calico 較少的依賴性使它能適配所有 VM偷溺、Container、白盒或者混合環(huán)境場景钱贯。

架構圖

image.png

Calico網絡模型主要工作組件：

• Felix：運行在每一臺 Host 的 agent 進程挫掏，主要負責網絡接口管理和監(jiān)聽、路由秩命、ARP 管理尉共、ACL 管理和同步、狀態(tài)上報等弃锐。

• etcd：分布式鍵值存儲袄友，主要負責網絡元數據一致性，確保Calico網絡狀態(tài)的準確性霹菊，可以與kubernetes共用剧蚣；

• BGP Client（BIRD）：Calico 為每一臺 Host 部署一個 BGP Client，使用 BIRD 實現旋廷，BIRD 是一個單獨的持續(xù)發(fā)展的項目鸠按，實現了眾多動態(tài)路由協(xié)議比如 BGP、OSPF柳洋、RIP 等待诅。在 Calico 的角色是監(jiān)聽 Host 上由 Felix 注入的路由信息，然后通過 BGP 協(xié)議廣播告訴剩余 Host 節(jié)點熊镣，從而實現網絡互通卑雁。

• BGP Route Reflector：在大型網絡規(guī)模中，如果僅僅使用 BGP client 形成 mesh 全網互聯的方案就會導致規(guī)模限制绪囱，因為所有節(jié)點之間倆倆互聯测蹲，需要 N^2 個連接，為了解決這個規(guī)模問題鬼吵，可以采用 BGP 的 Router Reflector 的方法扣甲，使所有 BGP Client 僅與特定 RR 節(jié)點互聯并做路由同步，從而大大減少連接數。

Felix

Felix會監(jiān)聽ECTD中心的存儲琉挖，從它獲取事件启泣，比如說用戶在這臺機器上加了一個IP，或者是創(chuàng)建了一個容器等示辈。用戶創(chuàng)建pod后寥茫，Felix負責將其網卡、IP矾麻、MAC都設置好纱耻，然后在內核的路由表里面寫一條，注明這個IP應該到這張網卡险耀。同樣如果用戶制定了隔離策略弄喘，Felix同樣會將該策略創(chuàng)建到ACL中，以實現隔離甩牺。

BIRD

BIRD是一個標準的路由程序蘑志，它會從內核里面獲取哪一些IP的路由發(fā)生了變化，然后通過標準BGP的路由協(xié)議擴散到整個其他的宿主機上柴灯，讓外界都知道這個IP在這里卖漫，你們路由的時候得到這里來。

架構特點

由于Calico是一種純三層的實現赠群，因此可以避免與二層方案相關的數據包封裝的操作，中間沒有任何的NAT旱幼，沒有任何的overlay查描，所以它的轉發(fā)效率可能是所有方案中最高的，因為它的包直接走原生TCP/IP的協(xié)議棧柏卤，它的隔離也因為這個棧而變得好做冬三。因為TCP/IP的協(xié)議棧提供了一整套的防火墻的規(guī)則，所以它可以通過IPTABLES的規(guī)則達到比較復雜的隔離邏輯缘缚。

Calico 網絡模式
IPIP
從字面來理解勾笆，就是把一個IP數據包又套在一個IP包里，即把 IP 層封裝到 IP 層的一個 tunnel桥滨。它的作用其實基本上就相當于一個基于IP層的網橋窝爪！一般來說，普通的網橋是基于mac層的齐媒，根本不需 IP蒲每，而這個 ipip 則是通過兩端的路由做一個 tunnel，把兩個本來不通的網絡通過點對點連接起來喻括。

image.png

BGP
邊界網關協(xié)議（Border Gateway Protocol, BGP）是互聯網上一個核心的去中心化自治路由協(xié)議邀杏。它通過維護IP路由表或‘前綴’表來實現自治系統(tǒng)（AS）之間的可達性，屬于矢量路由協(xié)議唬血。BGP不使用傳統(tǒng)的內部網關協(xié)議（IGP）的指標望蜡，而使用基于路徑唤崭、網絡策略或規(guī)則集來決定路由。因此脖律，它更適合被稱為矢量性協(xié)議浩姥，而不是路由協(xié)議。BGP状您，通俗的講就是講接入到機房的多條線路（如電信勒叠、聯通、移動等）融合為一體膏孟，實現多線單IP眯分，BGP 機房的優(yōu)點：服務器只需要設置一個IP地址，最佳訪問路由是由網絡上的骨干路由器根據路由跳數與其它技術指標來確定的柒桑，不會占用服務器的任何系統(tǒng)弊决。

image.png

兩種網絡對比
IPIP網絡：
流量：tunl0設備封裝數據，形成隧道魁淳，承載流量
適用網絡類型：適用于互相訪問的Pod不在同一個網段中飘诗，跨網段訪問的場景，外層封裝的IP能夠解決跨網段的路由問題界逛。
效率：流量需要tunl0設備封裝昆稿，效率略低
BGP網絡：
流量：使用路由信息導向流量
使用網絡類型：適用于互相訪問的Pod在同一個網段。
效率：原生hostGW息拜，效率高

存在的問題
1.缺點租戶隔離問題
Calico 的三層方案是直接在 host 上進行路由尋址溉潭，那么對于多租戶如果使用同一個 CIDR 網絡就面臨著地址沖突的問題。
2.路由規(guī)模問題
通過路由規(guī)則可以看出少欺，路由規(guī)模和 pod 分布有關喳瓣，如果 pod離散分布在 host 集群中，勢必會產生較多的路由項赞别。
3.iptables規(guī)則規(guī)模問題
1臺Host上可能虛擬化十幾或幾十個容器實例畏陕，過多的 iptables 規(guī)則造成復雜性和不可調試性，同時也存在性能損耗仿滔。
4.跨子網時的網關路由問題
當對端網絡不為二層可達時惠毁，需要通過三層路由機時，需要網關支持自定義路由配置堤撵，即 pod 的目的地址為本網段的網關地址仁讨，再由網關進行跨三層轉發(fā)。

3.2 underlay

Underlay網絡模型Underlay網絡就是傳統(tǒng)IT基礎設施網絡实昨，由交換機和路由器等設備組成洞豁，借助以太網協(xié)議、路由協(xié)議和VLAN協(xié)議等驅動，它還是Overlay網絡的底層網絡丈挟，為Overlay網絡提供數據通信服務刁卜。容器網絡中的Underlay網絡是指借助驅動程序將宿主機的底層網絡接口直接暴露給容器使用的一種網絡構建技術，較為常見的解決方案有MAC VLAN曙咽、IP VLAN和直接路由等蛔趴。

1.MAC VLANMAC VLAN支持在同一個以太網接口上虛擬出多個網絡接口，每個虛擬接口都擁有唯一的MAC地址例朱，并可按需配置IP地址孝情。通常這類虛擬接口被網絡工程師稱作子接口，但在MAC VLAN中更常用上層或下層接口來表述洒嗤。與Bridge模式相比箫荡，MAC VLAN不再依賴虛擬網橋、NAT和端口映射渔隶，它允許容器以虛擬接口方式直接連接物理接口羔挡。圖10-9給出了Bridge與MAC VLAN網絡對比示意圖。

image.png

VLAN網絡對比MAC VLAN有Private间唉、VEPA绞灼、Bridge和Passthru幾種工作模式，它們各自的工作特性如下呈野。

• Private：禁止構建在同一物理接口上的多個MAC VLAN實例（容器接口）彼此間的通信低矮，即便外部的物理交換機支持“發(fā)夾模式”也不行。
• VPEA：允許構建在同一物理接口上的多個MAC VLAN實例（容器接口）彼此間的通信际跪，但需要外部交換機啟用發(fā)夾模式商佛，或者存在報文轉發(fā)功能的路由器設備。
• Bridge：將物理接口配置為網橋姆打，從而允許同一物理接口上的多個MAC VLAN實例基于此網橋直接通信，而無須依賴外部的物理交換機來交換報文肠虽；此為最常用的模式幔戏，甚至還是Docker容器唯一支持的模式。
• Passthru：允許其中一個MAC VLAN實例直接連接物理接口税课。

由上述工作模式可知闲延，除了Passthru模式外的容器流量將被MAC VLAN過濾而無法與底層主機通信，從而將主機與其運行的容器完全隔離韩玩，其隔離級別甚至高于網橋式網絡模型垒玲，這對于有多租戶需求的場景尤為有用。由于各實例都有專用的MAC地址找颓，因此MAC VLAN允許傳輸廣播和多播流量合愈，但它要求物理接口工作于混雜模式，考慮到很多公有云環(huán)境中并不允許使用混雜模式，這意味著MAC VLAN更適用于本地網絡環(huán)境佛析。需要注意的是益老，MAC VLAN為每個容器使用一個唯一的MAC地址，這可能會導致具有安全策略以防止MAC欺騙的交換機出現問題寸莫，因為這類交換機的每個接口只允許連接一個MAC地址捺萌。另外，有些物理網卡存在可支撐的MAC地址數量上限膘茎。2. IP VLANIP VLAN類似于MAC VLAN桃纯，它同樣創(chuàng)建新的虛擬網絡接口并為每個接口分配唯一的IP地址，不同之處在于披坏，每個虛擬接口將共享使用物理接口的MAC地址态坦，從而不再違反防止MAC欺騙的交換機的安全策略，且不要求在物理接口上啟用混雜模式刮萌，如圖10-10所示驮配。

image.png

IP VLAN有L2和L3兩種模型，其中IP VLAN L2的工作模式類似于MAC VLAN Bridge模式着茸，上層接口（物理接口）被用作網橋或交換機壮锻，負責為下層接口交換報文；

而IP VLAN L3模式中涮阔，上層接口扮演路由器的角色猜绣，負責為各下層接口路由報文，如圖10-11所示敬特。IP VLAN L2模型與MAC VLAN Bridge模型都支持ARP協(xié)議和廣播流量掰邢，它們擁有直接接入網橋設備的網絡接口，能夠通過802.1d數據包進行泛洪和MAC地址學習伟阔。但IP VLAN L3模式下辣之，網絡棧在容器內處理，不支持多播或廣播流量皱炉，從這個意義上講怀估，它的運行模式與路由器的報文處理機制相同。雖然支持多種網絡模型合搅，但MAC VLAN和IP VLAN不能同時在同一物理接口上使用多搀。Linux內核文檔中強調，MAC VLAN和IP VLAN具有較高的相似度灾部，因此康铭，通常僅在必須使用IP VLAN的場景中才不使用MAC VLAN。一般說來赌髓，強依賴于IP VLAN的場景有如下幾個：

• Linux主機連接到的外部交換機或路由器啟用了防止MAC地址欺騙的安全策略从藤；
• 虛擬接口的需求數量超出物理接口能夠支撐的容量上限催跪，并且將接口置于混雜模式會給性能帶來較大的負面影響；

• 將虛擬接口放入不受信任的網絡名稱空間中可能會導致惡意的濫用呛哟。

  
  
  image.png
  
  

  需要注意的是叠荠，Linux內核自4.2版本后才支持IP VLAN網絡驅動，且在Linux主機上使用ip link命令創(chuàng)建的802.1q配置接口不具有持久性扫责，因此需依賴管理員通過網絡啟動腳本保持配置榛鼎。

3. 直接路由“直接路由”模型放棄了跨主機容器在L2的連通性，而專注于通過路由協(xié)議提供容器在L3的通信方案鳖孤。這種解決方案因為更易于集成到現在的數據中心的基礎設施之上者娱，便捷地連接容器和主機，并在報文過濾和隔離方面有著更好的擴展能力及更精細的控制模型苏揣，因而成為容器化網絡較為流行的解決方案之一黄鳍。一個常用的直接路由解決方案如圖10-12所示，每個主機上的各容器在二層通過網橋連通平匈，網關指向當前主機上的網橋接口地址框沟。跨主機的容器間通信增炭，需要依據主機上的路由表指示完成報文路由忍燥，因此每個主機的物理接口地址都有可能成為另一個主機路由報文中的“下一跳”，這就要求各主機的物理接口必須位于同一個L2網絡中隙姿。于是梅垄，在較大規(guī)模的主機集群中，問題的關鍵便轉向如何更好地為每個主機維護路由表信息输玷。常見的解決方案有：
   1> Flannel host-gw使用存儲總線etcd和工作在每個節(jié)點上的flanneld進程動態(tài)維護路由队丝；
   2>Calico使用BGP（Border Gateway Protocol）協(xié)議在主機集群中自動分發(fā)和學習路由信息。與Flannel不同的是欲鹏，Calico并不會為容器在主機上使用網橋机久，而是僅為每個容器生成一對veth設備，留在主機上的那一端會在主機上生成目標地址赔嚎，作為當前容器的路由條目吞加，如圖10-13所示。

直接路由虛擬網絡示意圖

Calico的直接路由模型示意圖

Calico的直接路由模型示意圖顯然尽狠，較Overlay來說，無論是MAC VLAN叶圃、IP VLAN還是直接路由機制的Underlay網絡模型的實現袄膏，它們因無須額外的報文開銷而通常有著更好的性能表現，但對底層網絡有著更多的限制條件掺冠。

3.3 macvlan

macvlan是kernel新支持的特性之一沉馆，需要Linux kernel v3.9–3.19和4.0+的支持码党。這種模式所配置的container網絡同主機網絡在同一個LAN里面，可以具有和主機一樣的網絡能力斥黑。

使用macvlan可以在主機的一個網絡接口上配置多個虛擬的網絡接口揖盘，這些網絡接口有自己獨立的MAC地址和IP地址。macvlan 下的container網絡和主機在同一個網段中锌奴，共享同一個廣播域兽狭。基于macvlan的聯網方式鹿蜀，可以直接訪問主機所在的LAN箕慧，并且沒有其它諸如bridge等方式帶來的bridge處理和地址翻譯的負擔，是一種高效直接的互聯技術茴恰。

工作模式
macvlan可以在主機的網卡上綁定多個二層mac地址颠焦，每個mac地址對應主機網卡(主接口)的一個子接口，每個container可以綁定一個子接口作為自己的網卡接口往枣。

根據子接口通信方式的不同伐庭，macvlan存在四種工作模式：

• private mode：主接口會過濾掉交換機返回來的來自其子接口的報文，不同子接口之間無法互相通信分冈。
• vepa(Virtual Ethernet Port Aggregator) mode： 發(fā)送出去的報文經過交換機圾另，交換機再發(fā)送到對應的目標地址（即使目標地址就是主機上的其它macvlan子接口），也就是hairpin mode模式丈秩，這個模式需要主接口連接的交換機支持 VEPA/802.1Qbg 特性盯捌；這種方式允許一個主接口上的多個子接口借助外部交換機進行相互通信，而LAN里面的廣播包也會被主接口forward到所有子接口蘑秽。這個種方式的一個典型應用是如果在外部交換機上有一些策略饺著，則可以使用VEPA模式讓所有子接口交互的包都會經由外部交換機的處理，便于統(tǒng)一管理整個子網的所有物理和虛擬接口肠牲。
• bridge mode：通過主機上的macvlan bridge將主接口的所有子接口連接在一起幼衰，不同子接口之間能夠不借助外部交換機而進行直接通信，不需要將報文發(fā)送到主機之外缀雳；因為所有子接口的mac地址都是已知的渡嚣，所以macvlan bridge不需要mac地址學習和STP的能力，所以是一個高效的bridge實現肥印。
• passthru mode：container可以直接使用主機的網絡接口识椰，并具有對接口進行參數調整的能力。

需要注意的是深碱，如果使用macvlan模式腹鹉，雖然主接口和子接口在同一LAN，但是在主機上通過主接口是沒有辦法直接和子接口通信的敷硅；需要額外建立一個子接口功咒，把主接口的IP配置給這個子接口愉阎，這樣才能借助原來主接口的IP和子接口進行通信。