（1）Pod的理解
1）pod是k8s中獨有的概念，爲Kubernetes最(小)基本的操作單元。
2）pod組成：一個pod中有一個pause沙盒容器和若干個業務容器組成。
業務容器關係：一個Pod中的多個容器應用通常是緊密耦合的，一般是將一組密切相關的服務進程放入同一個Pod中。
業務容器和pause關係：這些業務容器共享Pause容器的網絡棧和Volume掛載卷，保證通信和數據交換的高效性！
說明1：pod和容器的關係就像豌豆莢(pod)和裏面籽的關係！
說明2：簡而言之，pod是一組容器(至少一個)，而容器單指一個容器。
相關參考：https://v1-12.docs.kubernetes.io/zh/docs/concepts/workloads/pods/pod/
pod內容器之間的通信機制：localhost
（1）類似docker -p 的端口映射
#(1)指定api版本，此值必須在kubectl api-versions
apiVersion: v1
#(2)聲明資源的類型
kind: Pod
#(3)元數據
metadata:
#1）pod的名字
name: nginx
#2）該pod的標籤
labels:
app: web-nginx
# 備註:name和labels是相同縮進級別,讓YAML處理器知道他們屬於同一map，知道如何調用他們。
#3）註解(列表)-->非必需，提供額外的信息
annotations:
name: String
#age: 11
#(4)specification of the resource content 指定該資源的內容
spec: # container的核心
#1）容器的策略-->表明該容器一直運行，默認k8s的策略，在此容器退出後，會立即創建一個相同的容器
restartPolicy: Always
#2）pod調度到哪臺node上--->以node的label爲條件-->非必需
nodeSelector:
points: test
#3) 核心來了-->關於容器
containers:
#1) 容器的名字
- name: nginx
#2) 容器所使用的鏡像
image: wangzj.club/nginx/nginx
#3) 鏡像的拉取策略
# Always-->每次都遠程拉取，不管本地有沒有
# Never-->從本地拉取，沒有就報錯
# IfNotPresent-->如果本地有就不檢查，如果沒有就拉取
imagePullPolicy: IfNotPresent
#4)容器啓動的命令-->非必需(覆蓋問題)--->沒有則需要加一個常駐進程
# command: ['sh']
#5) 啓動容器的命令參數-->
# args: ["$(str)"]
#6)指定容器的環境變量
env:
- name: JAVA_HOME
value: "WZJ"
#7) 容器對應的資源限制
resources:
#1)容器運行時，最低資源需求，也就是說最少需要多少資源容器才能正常運行
requests:
#CPU資源（核數），兩種方式，浮點數或者是整數+m，0.1=100m，最少值爲0.001核（1m）
cpu: 0.1
#內存使用量
memory: 512Mi
#2)資源使用上限
limits:
cpu: 0.5
memory: 1G
#8)容器端口問題
ports:
- containerPort: 8888 # 容器中開啓端口
name: nginx-port # 端口的名字
protocol: TCP
#9)掛載的問題
volumeMounts:
- name: vol1 # 掛載設備的名字(引用下面的)
mountPath: /data # 掛載點(容器的某一個路徑)
readOnly: True
#10) 定義一組掛載設備
volumes:
- name: vol1
# 這裏掛載設備類型爲hostPath，路徑爲宿主機下的/opt-->默認：eptyDir: {}
hostPath:
path: /opt
核心：pod的健康檢查這裏並沒有寫，生產環境必須配置
備註：原生的k8s支持，但是騰訊雲的TKE由於使用的自研的cni網絡插件，所以暫時不支持，只能用如下的方式！
（2）pod另外一種網絡模式
spec:
#1）容器的策略-->表明該容器一直運行，默認k8s的策略，在此容器退出後，會立即創建一個相同的容器
restartPolicy: Always
#2) pod的網絡
hostNetwork: true
# 備註:將下面的ports註釋！
備註：這種方式和宿主機共享網絡命名空間，所以端口不能衝突！
（2）控制器
控制器：控制的是pod的數量！
引出問題：Pod需要手動管理，好累，能否在Pod發生問題時自動恢復呢，我們先來看下Replication Controller（以下簡稱RC）
RC：RC保證在同一時間能夠運行指定數量的Pod副本，保證Pod總是可用。如果實際Pod數量比預期的多就結束掉多餘的，如果實際數量比預期的少就啓動缺少的。當Pod(主體)失敗、被刪除或被終結時RC(模板)會自動創建新的Pod來保證副本數量，所以即使只有一個Pod也應該使用RC來進行管理。
核心字段：
spec.replicas：副本數量3 # 更新pod的數量
spec.selector：RC通過spec.selector來篩選要控制的Pod
spec.template：這裏寫Pod的定義（但不需要apiVersion和kind）
spec.template.metadata.labels：Pod的label，可以看到這個label與spec.selector相同
備註：RC的測試可以通過刪除pod，看是否能創建新的pod，保證穩定性！
Replica Set目前與RC的區別只是支持的selector不同，後續肯定會加入更多功能。
Deployment使用了Replica Set，是更高一層的概念，所以推薦使用Deployment而不直接使用Replica Set。
總結：一般來說，用戶不需要直接創建 Pod，他們幾乎都是使用控制器進行創建，即使對於單例的創建也一樣使用控制器，例如 Deployments。 控制器提供集羣範圍的自修復以及複製和滾動管理
kubectl create deployment wzj-tomcat --image=tomcat -o yaml --dry-run > tomcat.yaml
# --dry-run參數，打印相應的API對象而不創建它們
# 說明:會將命令行相應的參數寫入，其餘的默認！
創建Service對象
kubectl expose deployment wzj-tomcat --port=80 --target-port=8080 --type=NodePort -o yaml --dry-run >tomcat_svc.yaml
# 暴露服務，默認是Nodeport的方式
備註：需要做一些調整
apiVersion: v1
#(1)資源類型
kind: Service
metadata:
creationTimestamp: null
labels:
k8s-app: wzj-tomcat
qcloud-app: wzj-tomcat
name: wzj-tomcat
spec:
ports:
#(1)Cluster的虛擬IP
- port: 80
protocol: TCP
#(2)容器啓動的端口
targetPort: 8080
#(3)node節點開啓的端口(可能多個node都需要開啓):默認是3000-32768之間的，也可以自定義，但是必須在這個範圍內
#nodePort: 32000
#(3)選擇哪些label爲 app: wzj-tomcat作爲後端的真實服務的pod
selector:
app: wzj-tomcat
#(4)主機端口訪問-->比ClusterIP的方式高級
type: NodePort
status:
loadBalancer: {}
兩種訪問方式：
nodeip：nodport
Clusterip：clusterport
iptables-save做的事情
（3）幾種服務訪問的方式
（2）
https://www.jianshu.com/p/97dd4d59ac5a
https://blog.csdn.net/shida_csdn/article/details/84032019
Kubernetes暴露服務的方式目前只有三種：LoadBalancer Service、ExternalName、NodePort Service
Service --->藉助DNS的服務發現機制！
理解層面：'命令行'、'yaml的方式'、'命令行(便攜式)'、控制檯