一,deployment
Deployment為Pod和Replica Set下一代Replication Controller）提供宣告式更新
1，配置示例
apiVersion: apps/v1 # 1.9.0 之前的版本使用 apps/v1beta2，可通過命令 kubectl api-versions 查看
kind: Deployment #指定創建資源的角色/型別
metadata: #資源的元資料/屬性
name: nginx-deployment #資源的名字，在同一個namespace中必須唯一
namespace: xxxx #命名空間
labels:
app: demo #標簽
spec:
replicas: 3 #副本數量3
strategy:
rollingUpdate: ##由于replicas為3,則整個升級,pod個數在2-4個之間
maxSurge: 1 #滾動升級時會先啟動1個pod
maxUnavailable: 1 #滾動升級時允許的最大Unavailable的pod個數
selector: #定義標簽選擇器,部署需要管理的pod（帶有該標簽的的會被管理）需在pod 模板中定義
matchLabels:
app: web-server
template: #這里Pod的定義
metadata:
labels: #Pod的label
app: web-server
spec: # 模板的規范
containers:
- name: nginx #容器的名字
image: nginx:1.12.1 #容器的鏡像地址
command: [ "/bin/sh","-c","cat /etc/config/path/to/special-key" ] #啟動命令
args: #啟動引數
- '-storage.local.retention=$(STORAGE_RETENTION)'
- '-storage.local.memory-chunks=$(STORAGE_MEMORY_CHUNKS)'
- '-config.file=/etc/prometheus/prometheus.yml'
- '-alertmanager.url=http://alertmanager:9093/alertmanager'
- '-web.external-url=$(EXTERNAL_URL)'
#如果command和args均沒有寫，那么用Docker默認的配置，
#如果command寫了，但args沒有寫，那么Docker默認的配置會被忽略而且僅僅執行.yaml檔案的command（不帶任何引數的），
#如果command沒寫，但args寫了，那么Docker默認配置的ENTRYPOINT的命令列會被執行，但是呼叫的引數是.yaml中的args，
#如果如果command和args都寫了，那么Docker默認的配置被忽略，使用.yaml的配置，
imagePullPolicy: IfNotPresent
# IfNotPresent ：默認值,本地有則使用本地鏡像,不拉取，如果不存在則拉取
# Always： 總是拉取
# Never： 只使用本地鏡像，從不拉取
livenessProbe:
#表示container是否處于live狀態，如果LivenessProbe失敗，LivenessProbe將會通知kubelet對應的container不健康了，隨后kubelet將kill掉container，并根據RestarPolicy進行進一步的操作，默認情況下LivenessProbe在第一次檢測之前初始化值為Success，如果container沒有提供LivenessProbe，則也認為是Success；
httpGet:
path: /health #如果沒有心跳檢測介面就為/
port: 8080
scheme: HTTP
initialDelaySeconds: 60 ##啟動后延時多久開始運行檢測
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 5
readinessProbe:
readinessProbe:
httpGet:
path: /health #如果沒有心跳檢測介面就為/
port: 8080
scheme: HTTP
initialDelaySeconds: 30 ##啟動后延時多久開始運行檢測
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 5
resources: ##CPU記憶體限制
requests:
cpu: 2
memory: 2048Mi
limits:
cpu: 2
memory: 2048Mi
env: ##通過環境變數的方式，直接傳遞pod=自定義Linux OS環境變數
- name: LOCAL_KEY #本地Key
value: value
- name: CONFIG_MAP_KEY #局策略可使用configMap的配置Key，
valueFrom:
configMapKeyRef:
name: special-config #configmap中找到name為special-config
key: special.type #找到name為special-config里data下的key
ports:
- name: http
containerPort: 8080 #對service暴露埠
volumeMounts: #掛載volumes中定義的磁盤
- name: log-cache
mount: /tmp/log
- name: sdb #普通用法，該卷跟隨容器銷毀，掛載一個目錄
mountPath: /data/media
- name: nfs-client-root #直接掛載硬碟方法，如掛載下面的nfs目錄到/mnt/nfs
mountPath: /mnt/nfs
- name: example-volume-config #高級用法第1種，將ConfigMap的log-script,backup-script分別掛載到/etc/config目錄下的一個相對路徑path/to/...下，如果存在同名文件，直接覆寫，
mountPath: /etc/config
- name: rbd-pvc #高級用法第2中，掛載PVC(PresistentVolumeClaim)
#使用volume將ConfigMap作為檔案或目錄直接掛載，其中每一個key-value鍵值對都會生成一個檔案，key為檔案名，value為內容，
volumes: # 定義磁盤給上面volumeMounts掛載
- name: log-cache
emptyDir: {}
- name: sdb #掛載宿主機上面的目錄
hostPath:
path: /any/path/it/will/be/replaced
- name: example-volume-config # 供ConfigMap檔案內容到指定路徑使用
configMap:
name: example-volume-config #ConfigMap中名稱
items:
- key: log-script #ConfigMap中的Key
path: path/to/log-script #指定目錄下的一個相對路徑path/to/log-script
- key: backup-script #ConfigMap中的Key
path: path/to/backup-script #指定目錄下的一個相對路徑path/to/backup-script
- name: nfs-client-root #供掛載NFS存盤型別
nfs:
server: 10.42.0.55 #NFS服務器地址
path: /opt/public #showmount -e 看一下路徑
- name: rbd-pvc #掛載PVC磁盤
persistentVolumeClaim:
claimName: rbd-pvc1 #掛載已經申請的pvc磁盤
2，相關使用
一個典型的用例如下：
使用Deployment來創建ReplicaSet，ReplicaSet在后臺創建pod，檢查啟動狀態，看它是成功還是失敗，
然后，通過更新Deployment的PodTemplateSpec欄位來宣告Pod的新狀態，這會創建一個新的ReplicaSet，Deployment會按照控制的速率將pod從舊的ReplicaSet移動到新的ReplicaSet中，
如果當前狀態不穩定，回滾到之前的Deployment revision，每次回滾都會更新Deployment的revision，
擴容Deployment以滿足更高的負載，
暫停Deployment來應用PodTemplateSpec的多個修復，然后恢復上線，
根據Deployment 的狀態判斷上線是否hang住了，
清除舊的不必要的ReplicaSet
創建deployment
kubectl create -f nginx-deployment.yaml --record ##--record 為True 在annotation中記錄當前命令創建或者升級了該資源,如查看在每個Deployment revision中執行了哪些命令
kubectl get deployments
kubectl get rs #Replica Set的名字總是<Deployment的名字>-<pod template的hash值>
kubectl get pods -n xxxx #命名空間
kubectl get pods --show-labels #查看標簽更新deployment
注意： Deployment的rollout當且僅當Deployment的pod template（例如.spec.template）中的label更新或者鏡像更改時被觸發，其他更新，例如擴容Deployment不會觸發rollout.
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 #更新鏡像
或使用edit命令來編輯Deployment，修改 .spec.template.spec.containers[0].image ，將nginx:1.7.9 改寫成 nginx:1.9.1
kubectl edit deployment/nginx-deployment
kubectl rollout status deployment/nginx-deployment #rollout狀態
回退deployment
kubectl describe deployment #查看狀態
kubectl rollout history deployment/nginx-deployment #檢查升級記錄
kubectl rollout history deployment/nginx-deployment --revision=2 #查看version資訊
暫停和恢復
kubectl get deploy
kubectl rollout pause deployment/nginx-deployment
kubectl set image deploy/nginx nginx=nginx:1.9.1
kubectl rollout history deploy/nginx
二，SERVICE
service 的作用
防止Pod失去聯系（服務發現）
定義一組Pod的訪問策略（負載均衡）
支持ClusterIP，NodePort以及LoadBalancer三種型別
Service的底層實作主要有iptables和ipvs兩種網路模式
pod 與service的關系
通過lable-selector相關聯
通過Service實作Pod的負載均衡（TCP/UDP 4層）
組態檔
[root@k8s-master-128 dome]# cat deploy-nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels: # 這里是定義Deployment的標簽
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx # 選擇關聯Deployment標簽
template:
metadata:
labels: # 給Pod定義一個標簽，方便其他服務關聯這個Pod
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector: # Service 的selector 指定標簽 app:nginx 來進行對Pod進行關聯 ；(這里的app:nginx就是上面Deployment配置里labels定義的標簽 )
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
type: NodePortService的三種型別
發布的服務型別有三種：ClusterIP、NodePort和LoadBalancer
官網地址：https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types
ClusterIP
分配一個內部集群IP地址，只能在集群內部訪問（同Namespaces內的Pod），不對外提供訪問服務！默認ServiceTpye
kubectl get svc 暴露的集群ip和集群埠，只能在k8s集群內部訪問
Node節點上能查看到創建的iptables規則
Nodeport
分配一個內網集群IP地址，并在內個節點上啟用一個埠來暴露服務，可以在集群外部訪問
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80 # 需要暴露的集群埠(service暴露的)
targetPort: 9376 # 容器的埠(后端容器提供服務的埠）
nodePort: 30000
type: NodePort映射到物理機的埠范圍為：The range of valid ports is 30000-32767
kubectl get svc -o wide 暴露的埠在node 節點上由kube-proxy來啟動并監聽的，可通過NodeIP+埠的方式直接進行訪問，因為kube-proxy進行了代理，
kube-proxy是如何代理訪問到容器的呢？因為kube-proxy在啟動的時候通過--proxy-mode=ipvs可以指定底層內核代理模式，默認是iptables進行代理轉發，kube-proxy通過這兩種模式來代理直接對外提供服務
參考的寫法
apiVersion: v1
kind: Pod
metadata:
name: eureka
labels:
ccb: eureka
spec:
containers:
- name: test-container
image: eureka
ports:
- name: eureka
containerPort: 8082
protocol: TCP
imagePullPolicy: Never
volumeMounts:
- name: appconfig
mountPath: /jar/application.yml
subPath: application.yml
volumes:
- name: appconfig
configMap:
name: insight-application
items:
- key: registry-application.yml
path: application.yml
restartPolicy: Never
---
apiVersion: v1
kind: Service
metadata:
name: eureka
labels:
ccb: eureka
spec:
ports:
- port: 8082
targetPort: 8082
protocol: TCP
nodePort: 30000
type: NodePort
selector:
ccb: eureka
LoadBalancer
分配一個內部集群IP地址，并在每個節點上啟用一個埠來暴露服務，
除此之外，Kubernetes會請求底層云平臺上的負載均衡器，將每個Node（[NodeIP]:[NodePort]）作為后端添加進去，
LoadBalancer只適用于云平臺，AWS默認就支持，阿里云社區開發也支持
Service代理模式
service有三組代理模式：userspace、iptables和ipvs
常用命令
kubectl get svc -o wide
kubectl describe pod nginx-deployment-6dd86d77d-kxkmt #注意命名空間
來源：https://nicksors.cc/2019/06/21/kubernetes%E7%B3%BB%E5%88%97%E4%B9%8B%E3%80%8AService%E3%80%8B.html
三,定義pod
apiVersion: v1
kind: Pod
metadata:
name: eureka
labels:
ccb: eureka
spec:
containers:
- name: test-container
image: eureka
ports:
- name: eureka
containerPort: 8082
protocol: TCP
imagePullPolicy: Never #使用本地鏡像
volumeMounts:
- name: appconfig
mountPath: /jar/application.yml
subPath: application.yml
volumes:
- name: appconfig
configMap:
name: insight-application
items:
- key: registry-application.yml
path: application.yml
restartPolicy: Never
---
apiVersion: v1
kind: Service
metadata:
name: eureka
labels:
ccb: eureka
spec:
ports:
- port: 8082 #集群開放的的埠
targetPort: 8082 #后端容器開放的埠
protocol: TCP
nodePort: 30000 #宿主機開放的埠，范圍大于30000
type: NodePort #指定service型別為暴露物理節點的埠，必須
selector:
ccb: eureka #service 管理的pod1,創建pod流程
用戶通過kubectl命令創建一個Pod的流程：
客戶端提交創建請求，可以通過API Server的Restful API，也可以使用kubectl工具，支持json和yaml格式；
Api Server處理用戶請求，存盤Pod資訊資料到etcd集群中；
Scheduler調度器通過API Server查看未系結的Pod，嘗試為Pod進行分配主機，通過調度演算法選擇主機后，系結到這臺機器上并且把調度資訊寫入etcd集群；
kubelet根據調度結果執行Pod創建操作，成功后將資訊通過Api Server更新到etcd集群中；
整個Pod創建程序完成，每個組件都在于Api Server進行互動，Api Server就是k8s集群的中間者，組件之間的協同者，是一個集群訪問入口
2，Pod的多種控制器
ReplicaSet: 代用戶創建指定數量的pod副本數量，確保pod副本數量符合預期狀態，并且支持滾動式自動擴容和縮容功能，
ReplicaSet主要三個組件組成：
用戶期望的pod副本數量
標簽選擇器，判斷哪個pod歸自己管理
當現存的pod數量不足，會根據pod資源模板進行新建幫助用戶管理無狀態的pod資源，精確反應用戶定義的目標數量，但是RelicaSet不是直接使用的控制器，而是使用Deployment，
Deployment：作業在ReplicaSet之上，用于管理無狀態應用，目前來說最好的控制器，支持滾動更新和回滾功能，還提供宣告式配置， 參考文章：https://blog.csdn.net/bbwangj/article/details/82011573
DaemonSet：用于確保集群中的每一個節點只運行特定的pod副本，通常用于實作系統級后臺任務,比如ingress,elk.服務是無狀態的,服務必須是守護行程，參考文章：https://www.cnblogs.com/xzkzzz/p/9553321.html
Job：只要任務或程式運行完成就立即退出，不需要重啟或重建， 參考文章：https://blog.csdn.net/bbwangj/article/details/82011610
Cronjob：周期性任務控制，執行后就退出, 不需要持續后臺運行， 參考文章：https://blog.csdn.net/bbwangj/article/details/82867830
StatefulSet：管理有狀態應用,比如redis,mysql
3,POD管理
# 創建Pod資源
$ kubectl create -f pod.yaml
# 查看pods
$ kubectl get pods nginx-pod
# 查看pod描述
$ kubectl describe pod/nginx-pod
# 更新資源
$ kubectl apply -f pod.yaml
# 洗掉資源
$kubectl delete -f pod.yaml
or
$kubectl delete pods nginx-pod4,資源限制
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
resources: # 資源限制標簽
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"requests和limits都是做資源限制的，他們的區別在于：
requests # pod在創建時向k8s請求的資源大小；
limits # 限制了這個Pod運行的最大資源空間；
5,調度約束
Pod.spec.nodeName # 強制約束Pod調度到指定Node節點上
Pod.spec.nodeSelector # 通過lable-selector機制選擇節點
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
labels:
app: nginx
spec:
# nodeName:node01
nodeSelector:
env_role: dev
containers:
- name: nginx
image: nignx通過label給Node主機設定標簽：
kubectl label nodes k8s-node-129 env_role=dev
通過–show-labels查看Node的標簽：
$ kubectl get node --show-labels
6,重啟策略
Always: 當容器停止，總是重建容器，默認策略，
OnFailure： 當容器例外退出（退出狀態碼非0）時，才重啟容器，
Never：當容器終止退出，從不重啟容器，
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
restartPolicy: OnFailure7,鏡像拉取策略
IfNotPresent：默認值，鏡像不存在宿主機上時才拉取
Always：每次創建Pod時都會重新拉取一次鏡像
Never：Pod永遠不會主動拉取這個鏡像
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent8,健康檢查
提供Probe機制，有以下兩種型別：
livenessProbe
如果檢查失敗，將容器殺死，根據Pod的restartPolicy來操作，
readinessProbe
如果檢查失敗，Kubeneres會把Pod從service endpoints中剔除，robe支持以下三種檢查方法：
httpGet
發送HTTP請求，回傳200-400范圍狀態碼為成功，
exec
執行Shell命令回傳狀態碼是0為成功，
tcpSocket
發起TCP Socket建立成功，
9，問題定位
kubectl describe type/name
kubectl logs type/name [-c container]
kubectl exec --namespace=xxx -it pod -C 容器名稱 -- bash來源：https://nicksors.cc/2019/06/18/kubernetes%E7%B3%BB%E5%88%97%E4%B9%8B%E3%80%8APod%E3%80%8B.html
快速生成YAML檔案
1，命令生成
$ kubectl run --image=nginx my-deploy -o yaml --dry-run >my-deploy.yaml
$ kubectl create -f deploy-nginx.yaml -o yaml --dry-run >my-deploy.yaml
$ kubectl create -f deploy-nginx.yaml -o json --dry-run >my-deploy.json # 指定輸出json格式
– image # 指定模板鏡像
my-deploy # 運行標簽名稱
–dry-run # 只測驗運行,不會實際運行pod
-o yaml # 指定輸出格式
2，get匯出
kubectl get deploy/my-deploy -o=yaml --export > my-deploy.yaml
3，查詢Pod容器的欄位資源內部檔案
使用kubectl explain –help 查詢pod欄位內部說明
$ kubectl explain pods # 每一個層級的指令都會有欄位資訊
$ kubectl explain pods.spec
$ kubectl explain pods.spec.containers轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/55281.html
標籤：其他
上一篇：如何高效的學習技術