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

一，兩種建立資源的方法

1. 基於命令的方式：

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

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

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

環境介紹

主機	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）瀏覽器測試

3、小實驗

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

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節點的信息。