一，兩種創建資源的方法

1. 基於命令的方式：

簡單直觀快捷，上手快。
適合臨時測試或實驗。

2. 基於配置清單的方式：

配置文件描述了 What，即應用最終要達到的狀態。
配置文件提供了創建資源的模板，能夠重複部署。
可以像管理代碼一樣管理部署。
適合正式的、跨環境的、規模化部署。
這種方式要求熟悉配置文件的語法，有一定難度。

環境介紹

主機	IP地址	服務
master	192.168.1.21	k8s
node01	192.168.1.22	k8s
node02	192.168.1.23	k8s

二. 配置清單（yam，yaml）

在k8s中，一般使用yaml格式的文件來創建符合我們預期期望的pod，這樣的yaml文件我們一般稱爲資源清單

/etc/kubernetes/manifests/ k8s存放（yam、yaml）文件的地方

**kubectl explain deployment（通過explain參數加上資源類別就能看到該資源應該怎麼定義）

kubectl explain deployment.metadata 通過資源類別加上帶有Object標記的字段，我們就可以看到一級字段下二級字段的內容有那些怎麼去定義等

kubectl explain deployment.metadata.ownerReferences 通過加上不同級別的字段名稱來看下字段下的內容，而且前面的[]號代表對象列表

1.常見yaml文件寫法，以及字段的作用

(1) apiVersion：api版本信息

（用來定義當前屬於哪個組和那個版本，這個直接關係到最終提供使用的是那個版本）

[root@master manifests]# kubectl api-versions
//查看到當前所有api的版本

(2) kind: 資源對象的類別

(用來定義創建的對象是屬於什麼類別，是pod，service，還是deployment等對象，可以按照其固定的語法格式來自定義。)
(3) metadata: 元數據名稱字段（必寫）

提供以下幾個字段：
　　creationTimestamp: "2019-06-24T12:18:48Z"
　　generateName: myweb-5b59c8b9d-
　　labels: （對象標籤）
　　　　pod-template-hash: 5b59c8b9d
　　　　run: myweb
　　name: myweb-5b59c8b9d-gwzz5 （pods對象的名稱，同一個類別當中的pod對象名稱是唯一的，不能重複）
　　namespace: default （對象所屬的名稱空間，同一名稱空間內可以重複，這個名稱空間也是k8s級別的名稱空間，不和容器的名稱空間混淆）
　　ownerReferences:

apiVersion: apps/v1
blockOwnerDeletion: true
　　　　controller: true
　　　　kind: ReplicaSet
　　　　name: myweb-5b59c8b9d
　　　　uid: 37f38f64-967a-11e9-8b4b-000c291028e5
　　resourceVersion: "943"
　　selfLink: /api/v1/namespaces/default/pods/myweb-5b59c8b9d-gwzz5
　　uid: 37f653a6-967a-11e9-8b4b-000c291028e5
　　annotations（資源註解，這個需要提前定義，默認是沒有的）
通過這些標識定義了每個資源引用的path：即/api/group/version/namespaces/名稱空間/資源類別/對象名稱

(4) spec：用戶期望的狀態

（這個字段最重要，因爲spec是用來定義目標狀態的‘disired state’，而且資源不通導致spec所嵌套的字段也各不相同，也就因爲spec重要且字段不相同，k8s在內部自建了一個spec的說明用於查詢）

(5) status：資源現在處於什麼樣的狀態

（當前狀態，’current state‘，這個字段有k8s集羣來生成和維護，不能自定義，屬於一個只讀字段）

2.編寫一個yaml文件

[root@master ~]# vim web.yaml
kind: Deployment  #資源對象是控制器
apiVersion: extensions/v1beta1   #api的版本
metadata:      #描述kind（資源類型）
  name: web   #定義控制器名稱
spec:
  replicas: 2   #副本數量
  template:     #模板
    metadata:    
      labels:   #標籤
        app: web_server
    spec:
      containers:   #指定容器
      - name: nginx  #容器名稱
        image: nginx   #使用的鏡像

執行一下

[root@master ~]# kubectl apply -f web.yaml

查看一下

[root@master ~]# kubectl get deployments.  -o wide
//查看控制器信息

[root@master ~]# kubectl get pod -o wide
//查看pod節點信息

3.編寫一個service.yaml文件

[root@master ~]# vim web-svc.yaml
kind: Service  #資源對象是副本
apiVersion: v1   #api的版本
metadata:
  name: web-svc
spec:
  selector:     #標籤選擇器
    app: web-server  #須和web.yaml的標籤一致
  ports:              #端口
  - protocol: TCP
    port: 80            #宿主機的端口
    targetPort: 80      #容器的端口

使用相同標籤和標籤選擇器內容，使兩個資源對象相互關聯。

創建的service資源對象，默認的type爲ClusterIP，意味着集羣內任意節點都可訪問。它的作用是爲後端真正服務的pod提供一個統一的接口。如果想要外網能夠訪問服務，應該把type改爲NodePort

（1）執行一下

[root@master ~]# kubectl apply -f web-svc.yaml

（2）查看一下

[root@master ~]# kubectl get svc
//查看控制器信息

（3）訪問一下

[root@master ~]# curl 10.111.193.168

4.外網能夠訪問服務

（1）修改web-svc.yaml文件

kind: Service  #資源對象是副本
apiVersion: v1   #api的版本
metadata:
  name: web-svc
spec:
  type: NodePort    #添加 更改網絡類型
  selector:     #標籤選擇器
    app: web_server  #須和web.yaml的標籤一致
  ports:              #端口
  - protocol: TCP
    port: 80            #宿主機的端口
    targetPort: 80      #容器的端口
    nodePort: 30086     #指定羣集映射端口，範圍是30000-32767

（2）刷新一下

[root@master ~]#  kubectl apply -f web-svc.yaml

（3）查看一下

[root@master ~]# kubectl get svc

（4）瀏覽器測試

三、小實驗

基於上一篇博客實驗繼續進行

1.使用yaml文件的方式創建一個Deployment資源對象，要求鏡像使用個人私有鏡像v1版本。replicas爲3個。

編寫yaml文件

[root@master ~]# vim www.yaml
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: xgp
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: www_server
    spec:
      containers:
      - name: web
        image: 192.168.1.21:5000/web:v1

（1）執行一下

[root@master ~]# kubectl apply -f web-svc.yaml

（2）查看一下

[root@master ~]# kubectl get deployments. -o wide
//查看控制器信息

[root@master ~]# kubectl get pod -o wide
//查看pod節點信息

（3）訪問一下

2. 使用yaml文件的方式創建一個Service資源對象，要與上述Deployment資源對象關聯，type類型爲： NodePort，端口爲:30123.

編寫service文件

[root@master ~]# vim www-svc.yaml
kind: Service
apiVersion: v1
metadata:
  name: www-svc
spec:
  type: NodePort
  selector:
    app: www_server
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
    nodePort: 30123

執行一下

[root@master ~]# kubectl apply -f www-svc.yaml

查看一下

[root@master ~]# kubectl get svc

訪問一下

四. 總結

1. Pod的作用

在k8s中pod是最小的管理單位，在一個pod中通常會包含一個或多個容器。大多數情況下，一個Pod內只有一個Container容器。
在每一個Pod中都有一個特殊的Pause容器和一個或多個業務容器，Pause來源於pause-amd64鏡像,Pause容器在Pod中具有非常重要的作用：

Pause容器作爲Pod容器的根容器，其本地於業務容器無關，它的狀態代表了整個pod的狀態。

Pod裏的多個業務容器共享Pause容器的IP，每個Pod被分配一個獨立的IP地址，Pod中的每個容器共享網絡命名空間，包括IP地址和網絡端口。Pod內的容器可以使用localhost相互通信。k8s支持底層網絡集羣內任意兩個Pod之間進行通信。

Pod中的所有容器都可以訪問共享volumes，允許這些容器共享數據。volumes還用於Pod中的數據持久化，以防其中一個容器需要重新啓動而丟失數據。

2. Service的作用

Service 是後端真實服務的抽象，一個 Service 可以代表多個相同的後端服務

Service 爲 POD 控制器控制的 POD 集羣提供一個固定的訪問端點，Service 的工作還依賴於 K8s 中的一個附件，就是 CoreDNS ，它將 Service 地址提供一個域名解析。

NodePort 類型的 service

clusterIP：指定 Service 處於 service 網絡的哪個 IP，默認爲動態分配

NodePort 是在 ClusterIP 類型上增加了一個暴露在了 node 的網絡命名空間上的一個 nodePort，所以用戶可以從集羣外部訪問到集羣了，因而用戶的請求流程是：Client -> NodeIP:NodePort -> ClusterIP:ServicePort -> PodIP:ContainerPort。

可以理解爲 NodePort 增強了 ClusterIP 的功能，讓客戶端可以在每個集羣外部訪問任意一個 nodeip 從而訪問到 clusterIP，再由 clusterIP 進行負載均衡至 POD。

3.流量走向

我們在創建完成一個服務之後，用戶首先應該訪問的是nginx反向代理的ip，然後通過nginx訪問到後端的k8s服務器（master節點）的“NodePort暴露IP 及映射的端口“，通過”master節點“的“ip+映射端口”訪問到後端k8s節點的信息。

k8s創建資源(2)<基於配置清單>

一，兩種創建資源的方法

1. 基於命令的方式：

2. 基於配置清單的方式：

環境介紹

二. 配置清單（yam，yaml）

1.常見yaml文件寫法，以及字段的作用

2.編寫一個yaml文件

執行一下

查看一下

3.編寫一個service.yaml文件

（1）執行一下

（2）查看一下

（3）訪問一下

4.外網能夠訪問服務

（1）修改web-svc.yaml文件

（2）刷新一下

（3）查看一下

（4）瀏覽器測試

三、小實驗

1.使用yaml文件的方式創建一個Deployment資源對象，要求鏡像使用個人私有鏡像v1版本。replicas爲3個。

編寫yaml文件

（1）執行一下

（2）查看一下

（3）訪問一下

2. 使用yaml文件的方式創建一個Service資源對象，要與上述Deployment資源對象關聯，type類型爲： NodePort，端口爲:30123.

編寫service文件

執行一下

查看一下

訪問一下

四. 總結

1. Pod的作用

2. Service的作用

NodePort 類型的 service

3.流量走向