Kubernetes 筆記

Master組件

master組件包括API Server, Controller Manager, Scheduler, ETCD.

API Server

API Server 提供HTTP/HTTPS 服務, 該服務為Kubernetes主機的所有組件提供RESTFUL API支持. 例如,可以通過GET請求獲取資源狀態, 通過POST請求創建新的資源或者監控資源. API Server還會讀取并更新ETCD

Controller Manager

控制器管理器控制集群中的不同資源.

• Replication Controller 確保系統中每個物件都按照設定數量的容器運行.
• Node Controller 在節點宕機是回應, 會疏散運行在節點上的POD.
• Endpoint Controller 關聯服務與POD之間的聯系
• Service Account Controller 為新的命名空間創建默認賬戶
• Token Controller 創建API訪問令牌

ETCD

ETCD是一個開源的分布式鍵值存盤系統, Kubernetes用他存盤所有的RESTful API物件

Scheduler

調度器會根據節點上的資源容量或者資源利用率選擇合適POD運行的節點, 還會考慮將同一集合中的POD分散到不同節點

作業節點組件

每個節點上都需要安裝和運行以下組件， 記錄pod的運行時狀態， 并報告給master

kubelet

kubelet是節點中的主要行程，周期性的將節點活動報告給apiserver， 例如pod的健康狀態， 節點的健康狀態和存活探針，kubelet通過容器運行時運行容器， 例如Docker和rkt

kube-proxy

kube-proxy負責處理Pod負載均衡器（Service）和pod之間的路由， 以及從外部訪問服務的路由， 提供兩種代理模式，userspace和iptables， userspace模式切換內核空間和用戶空間帶來了大量的開銷，而iptables模式通過修改linux中的iptables nat以實作跨容器的tcp和udp的資料包路由， 是目前默認的代理模式

docker

docker是容器的一種實作， kubernetes使用docker作為默認的容器引擎

master與節點通信

客戶端使用kubectl向api服務器發送請求， api服務器回應該請求， 在etcd中推送和提取對應的物件資訊， 調度器決定應該分配哪個節點執行任務，控制器管理器監控正在運行的任務， 當狀態例外時做出回應， 另一方面， api服務器通過kubelet從pod獲取日志， 并作為master組件之間的轉發中心

kubernetes 命令

config

kubectl config get-clusters # 查詢所有cluster
kubectl config use-context ${context_name} # 切換不同的context
kubectl config current-context # 查詢所有的context
kubectl config view # 查詢kubeconfig的配置

explain

# 用法 kubectl explain ${resource}
kubectl explain deployment # 查詢deployment的說明

get

kubectl get pods -o wide
kubectl get pods -l key=value # label 選擇器

每個pod有一個狀態資訊PodStatus, 包含一組映射PodConditions, 其中的健可能有PodScheduled, Ready, Initialized 和 Unschedulable, 值可能為TRUE, FALSE和unknown.如果pod沒有被創建出來, PodStatus會簡要說明失敗的原因.

Pod與服務賬戶關聯, 該服務賬戶為正在運行pod的行程提供標識, 它由API服務器中的服務賬戶和令牌控制器控制. Pod中的/var/run/secrets/kubernetes.io/serviceaccount目錄會掛載一個只讀存盤卷, 里面包含了具有API訪問權限的token, Kubernetes會創建一個默認的服務賬戶, 可以使用kubectl get serviceaccounts 命令查看.

scale

kubectl scale deployment ${app} --replica 5 # 擴展pod數量

deployment 管理replicaset, replicaset管理pod
deployment 和 replicaset控制器的異同
相似: 確保pod數量, 確保pod健康, 彈性伸縮, 滾動升級
不同: deployment支持replicaset全部特性, 額外功能: 回滾, 版本記錄, 暫停和啟動

kubernetes 組件

service

service是一個抽象層, 用于把流量路由到一組pod, 不需要跟蹤每個pod的ip地址, 服務通常用標簽選擇器選擇需要路由的pod.
service型別有四種, nodeport, clusterip(默認), loadbalancer, externalname

ExternalName 被用來訪問外部的資源(即用作正向代理), 需要先創建沒有selector的service, 然后創建同名的endpoint, endpoint中指定外部的IP

minikube 下不能直接訪問nodeport的服務, 需要使用minikube service [-n ${NameSpace}] ${SVC} --url建立隧道, 才能訪問service

secrets

Secrets 以鍵值對形式創建存盤秘鑰的物件, 用于向pod提供敏感資訊, 可以是密碼, 訪問秘鑰或者token. secrets不會存盤到磁盤, 而是存盤在每個節點的tmpfs檔案系統中. secrets不用來存盤大量資料, 大小限制1M

secrets包含三種型別:

• generic 將要在應用程式中使用的文本
• docker-registry 存盤私有鏡像倉庫的憑據
• TLS 存盤集群管理的CA證書

docker-registry 型別的secret也被稱為image pull secrets, 拉取鏡像時通過kubelet傳遞私有docker registry 的密碼, 不需要在每個節點執行docker login

kubectl create secret docker-registry ${REGISTRY_NAME} \
--docker-server=${DOCKER_SERVER} \
--docker-username=${DOCKER_USERNAME} \
--docker-password=${DOCKER_PASS} \
--docker-email=${DOCKER_EMAIL}

# secrets 掛載實體
apiVersion: v1
kind: Pod
metadata:
  name: secret-access
spec:
  containers:
  - name: centos
    image: centos
    command: ["/bin/sh", "-c", "cat /secret/password-example;done"]
    volumeMounts:
      - name: secret-vol
        mountPath: /secret
        readOnly: true
  volumes:
    - name: secret-vol
      secret: 
        secretName: mypassword
        # items  可選
        items:
        - key: mypassword
          path: password-example
# secrets 檔案將掛載在/mountPath/secretName中, 如果指定了item, 則為/mountPath/Path


# secrets 掛在到環境變數中
...
spec:
  containers:
  - name: centos
    imagee: centos
    command: ["/bin/sh", "-c", "while:;do echo ${MY_PASSWORD};sleep 10;done;"]
    env:
      - name: MY_PASSWORD
        valueFrom: 
          secretKeyRef:
            name: mypassword
            key: mypassword 

# 創建generic的key
kubectl create secret generic mytest --from-literal=key1=value1 --from-literal=key2=value2

ConfigMap

ConfigMap是一可以將配置保留在Docker鏡像之外的方法，配置資料通過鍵值對的形式注入到pod， secrets用于存盤敏感資料， ConfigMap用于存盤不敏感資料，

configmap 與 secret的區別在于describe pod的時候， secret的值不會直接顯示出來

Kubernetes存盤

emptydir

emptydir 在pod被分配到node的時候創建, pod從節點上移除的時候, emptydir也會永久洗掉.

容器崩潰并不會影響emptydir

statefulset

sts 部署有狀態應用, pod會按順序啟動, 保留IP和存盤

Kubernetes的QoS

Gurantee, Brustable, Best Effort
Best Effort 只需要將資源限制設定為0, 或者不指定資源限制, 用于worker行程, 代理或快取節點
如果namespace有定義資源限制, 如果沒有給pod設定限制, 則不會設定Best effort.

Gurantee用于運行關鍵任務, 如服務主節點或者帶持久卷的后端資料庫.
配置Guarantee 需要將資源限制和資源請求設定為相同值.

Brustable 資源限制不是強制性的, 會盡可能消耗資源.request 和 limit不一致

如果一個pod中兩個容器, 一個是bustable, 一個是gurantee, 則pod是brustable, 因為Kubernetes不知道brustable會消耗多少資源.

網路與安全

kubernetes 的網路要求

1. 所有的容器之間可以互相訪問, 無論在哪個節點上
2. 所有的節點可以與所有容器互相通信
3. 容器看自己的IP與其他容器一致

Pod 內部容器的通信:
Kubernetes 同一個pod中的容器彼此視為localhost, 由網路容器實作,該改容器充當為Pod中每個容器流量轉發的橋梁. 比如一個Pod宣告了兩個容器, 在節點上試用docker ps -a 可以看到實際啟動的是3個容器, 網路容器包含了其他容器共享的網路命名空間. 統一網路命名空間的容器共享相同的IP和相同的網路配置.

Pod 間通信:
默認情況下, 同一節點內的pod通信會通過網橋, pod1和pod2通信時, 資料包通過pod1的網路命名空間傳遞到回應的veth pair vethXXX, 然后進入網橋, 網橋廣播目標IP幫助資料包找到路徑.

跨節點Pod 通信:
Kubernetes通過容器網路介面(CNI)實作這個功能. 用戶可以選擇不同的實作方式, 如L2,L3, overlay, overlay網路是常見的解決方案之一, 也被稱為資料包封裝, 在資料包離開資料源之前封裝, 導致overlay會增加網路延遲和復雜性

minikube 啟動時, 可以用minikube start --network-plugin=cni 來指定CNI插件啟動.

Pod的網路策略(Network Policy)

網路策略是Pod的軟體防火墻, 默認情況下, 每個pod都可以互相通信, 沒有任何邊界, 網路策略可以應用于Pod的隔離, 通過命名空間選擇器, 定義了誰可以訪問哪個Pod的哪個埠. 如果Pod啟用了網路策略, 它會拒絕其他任何流量.

kubenertes 持續集成

patch

kubectl patch 會根據輸入的json引數部分進行修改, 如果想更新鏡像, 命令如下

kubectl patch deployment my-app -p '{"spec": {"template": {"spec": {"containers": [{"name": "app", "image": "alpine:3.6"}]}}}}'

set

kubectl set 對某些屬性進行修改

kubectl set image deployment my-app app=alpine:3.6

edit

kubectl edit 打開編輯器以互動方式進行編輯, 保存后立即生效

replace

kubectl replace 用另一個模板檔案進行替換, 如果資源尚未創建, 或者包含無法更改的屬性, 則會提示報錯

apply

kubectl apply 如果資源已經存在, 則會更新, 如果不存在則會創建. 創建資源時, 功能相當于kubectl create --save-config

rollout

kubectl rollout 命令用來管理滾動更新

# 查看更新狀態
> kubectl rollout status deployment ${DEPLOYMENT} 
# 查看更新歷史
> kubectl rollout history deployment ${DEPLOYMENT}
REVISION  CHANGE-CAUSE
1         <none>
2         <none>
3         <none>
4         <none>
5         <none>
# change cause 為none, 如果要記錄更新的命令, 使用kubectl patch的時候, 加上--record.

# 回滾到特定版本, 如果不加revision則回滾到上一個版本
kubectl rollout undo deployment ${DEPLOYMENT} --to-revision=<REVISION #>

特性

探針

探針是容器健康狀況的指示器, 通過kubectl定期對容器執行診斷操作來判斷其健康狀態.

• liveness 探針, 指示容器是否存活, 如果容器在此探測上失敗, 則kubectl會將其終止, 并且根據Pod的restartPolicy重新啟動.
• readiness 探針指示容器是否已經準備好接收流量, 如果服務后端的Pod未準備好, Pod就緒之前不會創建對應的端點.

restartPolicy 告訴Kubernetes在Pod故障或者終止時如何進行處理, 有三種模式, Always, OnFailure和Never, 默認選項為Always.

有三種探針操作可以配置

• exec: 在容器內執行已定義的命令, 如果退出代碼為0 則成功
• tcpSocket: 通過TCP測驗指定埠, 如果埠打開則成功
• httpGet: 對目標容器的IP地址執行HTTP GET操作, header可以自定義, 如果狀態碼滿足200~400, 則被認為是健康的.

還有五個引數定義探測器的行為:

• initialDelaySeconds: 第一次探測之前, kubelet應該等待多久
• successThreshold: 連續探測成功通過該閾值的時候, 容器被認為是健康的
• failureThreshold: 定義失敗的閾值
• timeoutSeconds: 單個操作的時間限制
• periodSeconds: 探針操作之間的間隔

初始化容器

init容器是一個或多個容器, 在應用容器啟動之前啟動, 并按照順序逐個啟動, 如果任何容器發生故障, Pod會根據restartPolicy策略重新開始, 知道所有容器能正常退出.
init容器與應用容器的區別:

• init容器沒有readiness探針
• init容器的埠不會被服務捕獲
• 如果一個init容器超過了所有普通容器資源限制的總和, Kubernetes會根據init容器的資源限制來調度Pod.

終止Pod

Kubernetes收到洗掉的呼叫請求后，發送SIGTERM信號到要洗掉的Pod，并將Pod的狀態變為Terminating，同時，如果Pod作為Service的后端，Kubernetes將洗掉該Pod的端點以停止進一步的請求，有時候有些Pod不能正常退出，可能是Pod沒有處理SIGTERM信號，也可能僅僅因為它們的任務沒有完成，這種情況下，Kubernetes會在配置的終止時間后發送SIGKILL強行終止這些Pod，這個時間配置為．spec.terminationGracePeriodSeconds.

SIGTERM信號在ash / dash 的shell中不會轉發, 如果想保證應用程式順利接收SIGTERM信號, 應該使用exec的方式運行程式, 而不是使用shell方式

# exec 方式
CMD ["python", "-u", "app.py"]
# shell 方式
CMD python -u app.py 

某些情況下, SIGTERM不會觸發行程的終止處理程式, 例如將SIGTERM發送到nginx實際上會導致快速關閉, 為了優雅地關閉nginx, 必須發送帶有nginx -s quit 的SIGQUIT. 為了將SIGTERM以外的信號發送到容器, 可以使用生命周期鉤子.

生命周期鉤子

生命周期鉤子是對容器執行的事件感知的操作, 作業方式類似單個Kubernetes探針操作, 但只會在容器的生命周期內觸發事件, 支持以下兩類事件.

• PostStart: 在創建容器后立即執行, 這類鉤子與容器的入口點是異步觸發的, 無法保證在容器啟動之前執行, 一般不用來初始化容器的資源.
• PreStop: 在將SIGTERM發送到容器之前執行, PreStop是同步呼叫, SIGTERM在PreStop退出后發送.

鉤子的另一個特性是可能以某種方式影響Pod的狀態, 除非PostStart鉤子成功退出, 否組Pod不會運行, Pod設定為在洗掉時立即終止, 除非PreStop鉤子成功退出, 否則不會發送SIGTERM.

資源配額和默認配額

ResourceQuota限制命名空間內可以消耗的資源, 通過設定資源限制, 避免消耗所有節點的資源.
LimitRange指定命名空間的默認資源請求和限制. 如果Pod 未指定請求和限制則使用默認值.

新建集群用戶

添加用戶賬戶認證

root@master-0:~# openssl genrsa -out yun.key 2048
root@master-0:~# openssl req -new -key yun.key -out yun.csr -subj "/CN=yun"
root@master-0:~# openssl x509 -req -in yun.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out yun.crt -days 3650
root@master-0:~# kubectl config set-credentials yun --client-certificate=yun.crt --client-key=yun.key
root@master-0:~# kubectl config set-context yun-context --cluster=kubernetes --user=yun

基于角色的授權

# 把新建的用戶系結到cluster-admin 角色
kubectl create clusterrolebinding user-binding --clusterrole cluster-admin --user yun

標籤：其他

上一篇：白話電子簽章原理及風險

下一篇：【Deep Learning】SML部分代碼閱讀