溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
Pod是一組緊密關聯的容器集合，支持多個容器在一個Pod 里共 享網絡和文件系統，可以通過進程間通信和文件共享這種簡單高效的方式完成服務，是Kubernetes調度的基本單位。 Pod的設計理念是 每個Pod都有一個唯一的IP。
Pod具有如下特征：
容器生命周期鉤子函數，用于監聽容器生命周期的特定事件，并在事件發生時執行已注冊的回調函數，支持兩種鉤子函數：postStart和preStop，前者是在容器啟動后執行，后者是在容器停止前執行
Namespace（命名空間）是對一組資源和對象的抽象集合，比如可以用來將系統內部的對象劃分為不同的項目組或者用戶組。常見的pod、service、replicaSet和deployment等都是屬于某一個namespace的(默認是default)，而node, persistentVolumes等則不屬于任何namespace。
常用namespace操作：
# 查詢所有namespaces kubectl get namespace # 創建namespace kubectl create namespace ns-name # 刪除namespace kubectl delete namespace ns-name
刪除命名空間時，需注意以下幾點：
Events是否屬于namespace取決于產生events的對象。
Node是Pod真正運行的主機，可以是物理機也可以是虛擬機。Node本質上不是Kubernetes來創建的， Kubernetes只是管理Node上的資源。為了管理Pod，每個Node節點上至少需要運行container runtime（Docker）、kubelet和kube-proxy服務。
常用node操作：
# 查詢所有node kubectl get nodes # 將node標志為不可調度 kubectl cordon $nodename # 將node標志為可調度 kubectl uncordon $nodename
taint(污點)
使用kubectl taint命令可以給某個Node節點設置污點，Node被設置上污點之后就和Pod之間存在了一種相斥的關系，可以讓Node拒絕Pod的調度執行，甚至將Node已經存在的Pod驅逐出去。每個污點的組成：
key=value:effect，當前taint effect支持如下三個選項：
常用命令如下：
# 為節點node0設置不可調度污點 kubectl taint node node0 key1=value1:NoShedule # 將node0上key值為key1的污點移除 kubectl taint node node0 key- # 為kube-master節點設置不可調度污點 kubectl taint node node1 node-role.kubernetes.io/master=:NoSchedule # 為kube-master節點設置盡量不可調度污點 kubectl taint node node1 node-role.kubernetes.io/master=PreferNoSchedule
容忍(Tolerations)
設置了污點的Node將根據taint的effect：NoSchedule、PreferNoSchedule、NoExecute和Pod之間產生互斥的關系，Pod將在一定程度上不會被調度到Node上。 但我們可以在Pod上設置容忍(Toleration)，意思是設置了容忍的Pod將可以容忍污點的存在，可以被調度到存在污點的Node上。
Service是對一組提供相同功能的Pods的抽象，并為他們提供一個統一的入口，借助 Service 應用可以方便的實現服務發現與負載均衡，并實現應用的零宕機升級。 Service通過標簽(label)來選取后端Pod，一般配合ReplicaSet或者Deployment來保證后端容器的正常運行。
service 有如下四種類型，默認是ClusterIP：
NodeIP:NodePort 來訪問該服務另外，也可以將已有的服務以Service的形式加入到Kubernetes集群中來，只需要在創建 Service 的時候不指定Label selector，而是在Service創建好后手動為其添加endpoint。
默認情況下容器的數據是非持久化的，容器消亡以后數據也會跟著丟失，所以Docker提供了Volume機制以便將數據持久化存儲。Kubernetes提供了更強大的Volume機制和插件，解決了容器數據持久化以及容器間共享數據的問題。
Kubernetes存儲卷的生命周期與Pod綁定
目前Kubernetes主要支持以下Volume類型：
...
PersistentVolume(PV)是集群之中的一塊網絡存儲。跟 Node 一樣，也是集群的資源。PersistentVolume (PV)和PersistentVolumeClaim (PVC)提供了方便的持久化卷: PV提供網絡存儲資源，而PVC請求存儲資源并將其掛載到Pod中。
PV的訪問模式(accessModes)有三種:
不是每一種存儲都支持這三種方式，像共享方式，目前支持的還比較少，比較常用的是 NFS。在PVC綁定PV時通常根據兩個條件來綁定，一個是存儲的大小，另一個就是 訪問模式。
PV的回收策略(persistentVolumeReclaimPolicy)也有三種
Delete，刪除存儲資源
一般情況下我們不需要手動創建Pod實例，而是采用更高一層的抽象或定義來管理Pod，針對無狀態類型的應用，Kubernetes使用Deloyment的Controller對象與之對應。其典型的應用場景包括：
常用的操作命令如下：
# 生成一個Deployment對象 kubectl run www --image=10.0.0.183:5000/hanker/www:0.0.1 --port=8080 # 查找Deployment kubectl get deployment --all-namespaces # 查看某個Deployment kubectl describe deployment www # 編輯Deployment定義 kubectl edit deployment www # 刪除某Deployment kubectl delete deployment www # 擴縮容操作，即修改Deployment下的Pod實例個數 kubectl scale deployment/www --replicas=2 # 更新鏡像 kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 # 回滾操作 kubectl rollout undo deployment/nginx-deployment # 查看回滾進度 kubectl rollout status deployment/nginx-deployment # 啟用水平伸縮（HPA - horizontal pod autoscaling），設置最小、最大實例數量以及目標cpu使用率 kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80 # 暫停更新Deployment kubectl rollout pause deployment/nginx-deployment # 恢復更新Deployment kubectl rollout resume deploy nginx
更新策略
.spec.strategy 指新的Pod替換舊的Pod的策略，有以下兩種類型
RollingUpdate 滾動升級，可以保證應用在升級期間，對外正常提供服務。Recreate 重建策略，在創建出新的Pod之前會先殺掉所有已存在的Pod。Deployment和ReplicaSet兩者之間的關系
當執行更新操作時，會創建一個新的ReplicaSet，Deployment會按照控制的速率將pod從舊的ReplicaSet移 動到新的ReplicaSet中
Deployments和ReplicaSets是為無狀態服務設計的，那么StatefulSet則是為了有狀態服務而設計，其應用場景包括：
支持兩種更新策略：
.spec.template更新時，并不立即刪除舊的Pod，而是等待用戶手動刪除這些舊Pod后自動創建新Pod。這是默認的更新策略，兼容v1.6版本的行為.spec.template 更新時，自動刪除舊的Pod并創建新Pod替換。在更新時這些Pod是按逆序的方式進行，依次刪除、創建并等待Pod變成Ready狀態才進行下一個Pod的更新。9 DaemonSet 守護進程集
DaemonSet保證在特定或所有Node節點上都運行一個Pod實例，常用來部署一些集群的日志采集、監控或者其他系統管理應用。典型的應用包括:
指定Node節點
目前支持兩種策略*
RollingUpdate: 更新DaemonSet模版后，自動刪除舊的Pod并創建新的Pod
Kubernetes中的負載均衡我們主要用到了以下兩種機制：
Service和Pod的IP僅可在集群內部訪問。集群外部的請求需要通過負載均衡轉發到service所在節點暴露的端口上，然后再由kube-proxy通過邊緣路由器將其轉發到相關的Pod，Ingress可以給service提供集群外部訪問的URL、負載均衡、HTTP路由等，為了配置這些Ingress規則，集群管理員需要部署一個Ingress Controller，它監聽Ingress和service的變化，并根據規則配置負載均衡并提供訪問入口。
常用的ingress controller：
Openresty
Job負責批量處理短暫的一次性任務 (short lived one-off tasks)，即僅執行一次的任務，它保證批處理任務的一個或多個Pod成功結束。
CronJob即定時任務，就類似于Linux系統的crontab，在指定的時間周期運行指定的任務。
Horizontal Pod Autoscaling可以根據CPU、內存使用率或應用自定義metrics自動擴展Pod數量 (支持replication controller、deployment和replica set)。
支持三種metrics類型
可以通過如下命令創建HPA：
kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
Service account是為了方便Pod里面的進程調用Kubernetes API或其他外部服務而設計的
授權
Service Account為服務提供了一種方便的認證機制，但它不關心授權的問題。可以配合RBAC(Role Based Access Control)來為Service Account鑒權，通過定義Role、RoleBinding、ClusterRole、ClusterRoleBinding來對sa進行授權。
Sercert-密鑰解決了密碼、token、密鑰等敏感數據的配置問題，而不需要把這些敏感數據暴露到鏡像或者Pod Spec中。Secret可以以Volume或者環境變量的方式使用。有如下三種類型：
Service Account:用來訪問Kubernetes API，由Kubernetes自動創建，并且會自動掛載到Pod的 /run/secrets/kubernetes.io/serviceaccount 目錄中;
Opaque:base64編碼格式的Secret，用來存儲密碼、密鑰等;
kubernetes.io/dockerconfigjson: 用來存儲私有docker registry的認證信息。
ConfigMap用于保存配置數據的鍵值對，可以用來保存單個屬性，也可以用來保存配置文件。ConfigMap跟secret很類似，但它可以更方便地處理不包含敏感信息的字符串。ConfigMap可以通過三種方式在Pod中使用，三種分別方式為:設置環境變量、設置容器命令行參數以及在Volume中直接掛載文件或目錄。
可以使用 kubectl create configmap從文件、目錄或者key-value字符串創建等創建 ConfigMap。也可以通過 kubectl create -f value.yaml 創建。
資源配額(Resource Quotas)是用來限制用戶資源用量的一種機制。
資源配額有如下類型：
計算資源，包括cpu和memory
存儲資源，包括存儲資源的總量以及指定storage class的總量
對象數，即可創建的對象的個數
它的工作原理為:
用戶超額后禁止創建新的資源
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
