目錄

Pod

參考文檔：Pod | Kubernetes

Pod配置文件：simple-pod.yaml

對(duì)master進(jìn)行如下操作

Pod的狀態(tài)有：

參考文檔：(70條消息) Pod生命周期中的狀態(tài)解釋_pod狀態(tài)_鬧玩兒扣眼珠子的博客-CSDN博客

進(jìn)入Pod內(nèi)的nginx容器：

當(dāng)我們創(chuàng)建一個(gè)Pod，其中的步驟是什么？（啟動(dòng)Pob的流程）

大概步驟：

k8s的?控制器有哪些：

創(chuàng)建Pod過(guò)程中提出的問(wèn)題：?

Scheduler在做任務(wù)的時(shí)候，使用了那些調(diào)度算法呢？

根據(jù)Pod的調(diào)度策略和方法：（K8s有哪些調(diào)度算法？）

Pod與Pod之間如何進(jìn)行通信？

k8s啟動(dòng)Pod

1、啟動(dòng)nginx的Pod

2、控制器deployment的使用

我們?nèi)绻胪Ｖ筆od的運(yùn)行，我們刪除ReplicaSet 控制器是沒(méi)有用的（因?yàn)閯h除掉后deployment控制器會(huì)重新啟用ReplicaSet 控制器），我們必須刪除deployment控制器（命令：kubectl delete deployment）

?3、conctroller 控制器

參考文檔：DaemonSet | Kubernetes

DaemonSet?確保全部（或者某些）節(jié)點(diǎn)上運(yùn)行一個(gè) Pod 的副本。

下面的 daemonset.yaml 文件描述了一個(gè)運(yùn)行 fluentd-elasticsearch（日志收集） Docker 鏡像的 DaemonSet：

我們?yōu)槭裁匆O(shè)置容忍度呢，其實(shí)原因很簡(jiǎn)單，因?yàn)閗8s會(huì)對(duì)master進(jìn)行污點(diǎn)標(biāo)記，導(dǎo)致Pod無(wú)法在master運(yùn)行，但是我們的日志收集的目的是可以在所有節(jié)點(diǎn)上運(yùn)行的，因此設(shè)置容忍度可以使這個(gè)Pod在master上也能正常運(yùn)行

污點(diǎn)和容忍度：

參考文檔：污點(diǎn)和容忍度 | Kubernetes

配置一：?

配置二：?

先檢查key是否匹配，匹配是看operator是exists或者equal，這表示匹配，就會(huì)允許在有污點(diǎn)的node節(jié)點(diǎn)上啟動(dòng)這個(gè)Pod，effect可以理解為如果key不匹配，就不允許調(diào)度到這個(gè)污點(diǎn)節(jié)點(diǎn)。

4、Pod的資源控制

參考文檔：為容器和 Pod 分配內(nèi)存資源 | Kubernetes?

指定內(nèi)存請(qǐng)求和限制

創(chuàng)建一個(gè)命名空間，以便將本練習(xí)中創(chuàng)建的資源與集群的其余部分隔離。

你將創(chuàng)建一個(gè)擁有一個(gè)容器的 Pod。 容器將會(huì)請(qǐng)求 100 MiB 內(nèi)存，并且內(nèi)存會(huì)被限制在 200 MiB 以?xún)?nèi)。 這是 Pod 的配置文件：

開(kāi)始創(chuàng)建 Pod：

驗(yàn)證 Pod 中的容器是否已運(yùn)行：

查看 Pod 相關(guān)的詳細(xì)信息：

運(yùn)行?kubectl top?命令，獲取該 Pod 的指標(biāo)數(shù)據(jù)（前提是你已經(jīng)有在運(yùn)行中的?metrics-server）

刪除 Pod：

支持容器訪問(wèn)策略和容器帶寬限制：istio組件

5、一個(gè)Pod里面運(yùn)行多個(gè)容器：

Pod 的配置文件：

創(chuàng)建multi_c.yaml文件存儲(chǔ)Pod

開(kāi)始創(chuàng)建 Pod：

?驗(yàn)證 Pod 中的容器是否已運(yùn)行：

內(nèi)部訪問(wèn)我創(chuàng)建的nginx容器：

6、將創(chuàng)建的Pod發(fā)布出去：

參考文檔：?服務(wù)（Service） | Kubernetes

定義一個(gè)內(nèi)有nginx容器的Pod，并創(chuàng)建成功

開(kāi)始創(chuàng)建 Pod：

查看是否創(chuàng)建成功：

創(chuàng)建Service服務(wù)，暴露我們的nginx容器服務(wù)（發(fā)布服務(wù)（服務(wù)類(lèi)型））

開(kāi)始創(chuàng)建 Pod（service服務(wù)）：?

Service發(fā)布成功了?

訪問(wèn)發(fā)布的Pod

我們只需要隨便訪問(wèn)k8s集群里的任何一臺(tái)node節(jié)點(diǎn)服務(wù)器，包括master

訪問(wèn)nginx容器的模擬圖：（外面的用戶(hù)訪問(wèn)Pod的數(shù)據(jù)流程：）

Pod

參考文檔：Pod | Kubernetes

Pod配置文件：simple-pod.yaml

apiVersion: v1     #k8s里的api版本  --》用來(lái)給我們的k8s傳參的
kind: Pod          #k8s里的資源對(duì)象類(lèi)型：pod deployment replicaSET daemonSET service等對(duì)象
metadata:          #定義的元數(shù)據(jù)、起描述資源對(duì)象的數(shù)據(jù)
  name: nginx       #pod的名字
spec:                #詳細(xì)的信息、指定的信息
  containers:        #容器
  - name: scnginx      #容器名  可以存在多個(gè)容器  
    image: nginx:1.14.2     #鏡像及其版本
    ports:                  #容器暴露的端口
    - containerPort: 80     #具體的端口
  #- name redis        #指定第二個(gè)容器為redis
  # image: nginx:1.14.2
  # ports:
  # - containerPort: 80

對(duì)master進(jìn)行如下操作

[root@master pod]# pwd
/root/pod
[root@master pod]# ls
nginx.yaml
[root@master pod]# cat nginx.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: scnginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80
[root@master pod]# kubectl apply -f nginx.yaml
pod/scnginx created
[root@master pod]# kubectl get pod
NAME                         READY   STATUS              RESTARTS   AGE
k8s-nginx-6d779d947c-f72hf   1/1     Running             0          5h57m
k8s-nginx-6d779d947c-hnhf5   1/1     Running             0          5h57m
k8s-nginx-6d779d947c-xgjzg   1/1     Running             0          5h57m
scnginx                      0/1     ContainerCreating   0          14s
[root@master pod]# 

如上所示，我使用了nginx.yaml文件創(chuàng)建了一個(gè)關(guān)于nginx的pod，其中的pod的狀態(tài)

Pod的狀態(tài)有：

1. Pending（等待中）：Pod 已經(jīng)被創(chuàng)建，但還未被調(diào)度到任何節(jié)點(diǎn)上運(yùn)行。

2. Running（運(yùn)行中）：Pod 已經(jīng)被調(diào)度到節(jié)點(diǎn)上并且至少有一個(gè)容器正在運(yùn)行。

3. Succeeded（已成功）：Pod 中的所有容器已經(jīng)成功地完成任務(wù)并且終止。

4. Failed（已失?。?/strong>：Pod 中的所有容器已經(jīng)執(zhí)行失敗，并且已終止。

5. Unknown（未知）：無(wú)法獲取 Pod 的狀態(tài)信息。

6. ImagePullBackoff：鏡像拉取失敗(ImagePullBackoff )

7. CrashLoopBackOff ：運(yùn)行時(shí)程序崩潰( CrashLoopBackOff )，頻繁重啟

8. 配置錯(cuò)誤,比如掛載的Volume不存在( RunContainerError)，導(dǎo)致容器運(yùn)行錯(cuò)誤

9. Pending：磁盤(pán)掛載失敗( Pending ),比如容器掛載的puvc并沒(méi)有Pend特定的pv

10. OOMKilled：你需要申請(qǐng)的CPU和內(nèi)存資源超過(guò)了宿主機(jī)的允許

11. ContainerCreating：正在創(chuàng)建容器的過(guò)程中

[root@master pod]# kubectl get pod -o wide      #查看Pod的詳細(xì)信息
NAME                         READY   STATUS    RESTARTS   AGE     IP           NODE    NOMINATED NODE   READINESS GATES
k8s-nginx-6d779d947c-f72hf   1/1     Running   0          6h10m   10.244.1.4   node1   <none>           <none>
k8s-nginx-6d779d947c-hnhf5   1/1     Running   0          6h10m   10.244.3.2   node3   <none>           <none>
k8s-nginx-6d779d947c-xgjzg   1/1     Running   0          6h10m   10.244.2.2   node2   <none>           <none>
scnginx                      1/1     Running   0          14m     10.244.2.3   node2   <none>           <none>
[root@master pod]# kubectl exec -it scnginx bash    #進(jìn)入scnginx容器內(nèi)
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
root@scnginx:/# 

建議使用： kubectl exec -it scnginx -- bash 

4、然后副本控制器會(huì)幫助我們?nèi)?strong>監(jiān)控Pod數(shù)量，一旦少了 副本控制器還會(huì)幫我們再啟一個(gè)Pod。

5、Kubelet 檢測(cè)到需要被創(chuàng)建的Pod，會(huì)分配資源（如Docker創(chuàng)建）將Pod創(chuàng)建（在Node上）

6、Kubeproxy最后會(huì)管理Pod需要的內(nèi)存、流量，保障Pod穩(wěn)定運(yùn)行（在Node上）

k8s的?控制器有哪些：

Kubernetes 中有多個(gè)控制器（Controller），用于確保系統(tǒng)中的資源狀態(tài)與期望狀態(tài)保持一致。以下是 Kubernetes 中常見(jiàn)的控制器：

1. ReplicaSet 控制器：用于管理 Pod 的副本數(shù)，確保指定數(shù)量的 Pod 副本處于運(yùn)行狀態(tài)。

2. Deployment 控制器：基于 ReplicaSet 控制器，提供了滾動(dòng)更新和回滾功能，用于管理應(yīng)用程序的發(fā)布和更新。

3. StatefulSet 控制器：用于管理有狀態(tài)應(yīng)用的部署，確保有序的創(chuàng)建、更新和刪除 Pod。

4. DaemonSet 控制器：確保在集群的每個(gè)節(jié)點(diǎn)上都運(yùn)行一個(gè) Pod 的副本，常用于運(yùn)行守護(hù)進(jìn)程或日志收集器等任務(wù)。

5. Job 控制器：用于一次性任務(wù)的執(zhí)行，確保任務(wù)成功完成后自動(dòng)終止，如批處理任務(wù)或定時(shí)任務(wù)。

6. CronJob 控制器：基于 Job 控制器，用于按計(jì)劃定期執(zhí)行任務(wù)，如定時(shí)清理任務(wù)或數(shù)據(jù)備份任務(wù)。

7. Namespace 控制器：用于創(chuàng)建和管理命名空間，將集群內(nèi)的資源隔離和分類(lèi)。

創(chuàng)建Pod過(guò)程中提出的問(wèn)題：?

1、kubelet是定期主動(dòng)訪問(wèn)api server知道有哪些pod需要啟動(dòng)，還是Scheduler主動(dòng)去通知kubelet去訪問(wèn)api server的呢？

2、etcd數(shù)據(jù)庫(kù)發(fā)生了變化，那些控制器是如何知道的呢？是其他程序通知的，還是定時(shí)檢查的呢？

3、這么多的控制的，那么哪些控制器先啟動(dòng)，哪些控制器后啟動(dòng)呢，他們的啟動(dòng)順序是怎樣的呢？（deployment、replicaSet、Scheduler）

其他控制器（daemonSet：會(huì)在每臺(tái)node節(jié)點(diǎn)上啟動(dòng)一個(gè)Pod，不會(huì)啟動(dòng)多了，flannel上就有）

（job：批量處理的控制器）

（cronjob：計(jì)劃任務(wù)的控制器）

Scheduler在做任務(wù)的時(shí)候，使用了那些調(diào)度算法呢？

為什么master上沒(méi)有啟動(dòng)業(yè)務(wù)app pod？

因?yàn)檫@是Scheduler調(diào)度器會(huì)根據(jù)調(diào)度策略，避免了在master上建立Pod

污點(diǎn)：taint（會(huì)導(dǎo)致這個(gè)node節(jié)點(diǎn)機(jī)器不接受這個(gè)被污點(diǎn)標(biāo)記的Pod）

根據(jù)Pod的調(diào)度策略和方法：（K8s有哪些調(diào)度算法？）

1、deployment：全自動(dòng)調(diào)度：會(huì)根據(jù)node的綜合算力（cpu、內(nèi)存、帶寬、已經(jīng)運(yùn)行的Pod等）

2、node selector：定向調(diào)度

3、nodeaffinity：它會(huì)盡量把不同的Pod的放到一臺(tái)node節(jié)點(diǎn)機(jī)器上 --》affinity（親和度）

4、podaffinity：它會(huì)盡量把相同的Pod的放到一起去（yaml文件中才會(huì)存在）

5、taints和tolerations：污點(diǎn)和容忍

Pod與Pod之間如何進(jìn)行通信？

其實(shí)我看可以看做docker宿主機(jī)和內(nèi)部容器間的通信流程

我們使用的技術(shù)是overlay（基礎(chǔ)是vxlan）（flannel）、ipip和BGP（cailco）

k8s啟動(dòng)Pod

1、啟動(dòng)nginx的Pod

kubectl create deployment k8s-nginx --image=nginx -r 3

2、控制器deployment的使用

查看deployment的使用

[root@master pod]# kubectl get deployment
NAME        READY   UP-TO-DATE   AVAILABLE   AGE
k8s-nginx   3/3     3            3           8h
[root@master pod]# 

我們?nèi)绻胪Ｖ筆od的運(yùn)行，我們刪除ReplicaSet 控制器是沒(méi)有用的（因?yàn)閯h除掉后deployment控制器會(huì)重新啟用ReplicaSet 控制器），我們必須刪除deployment控制器（命令：kubectl delete deployment）

?3、conctroller 控制器

參考文檔：DaemonSet | Kubernetes

DaemonSet?確保全部（或者某些）節(jié)點(diǎn)上運(yùn)行一個(gè) Pod 的副本。

當(dāng)有節(jié)點(diǎn)加入集群時(shí)， 也會(huì)為他們新增一個(gè) Pod 。 當(dāng)有節(jié)點(diǎn)從集群移除時(shí)，這些 Pod 也會(huì)被回收。刪除 DaemonSet 將會(huì)刪除它創(chuàng)建的所有 Pod。

DaemonSet 的一些典型用法：

• 在每個(gè)節(jié)點(diǎn)上運(yùn)行集群守護(hù)進(jìn)程
• 在每個(gè)節(jié)點(diǎn)上運(yùn)行日志收集守護(hù)進(jìn)程
• 在每個(gè)節(jié)點(diǎn)上運(yùn)行監(jiān)控守護(hù)進(jìn)程

下面的 daemonset.yaml 文件描述了一個(gè)運(yùn)行 fluentd-elasticsearch（日志收集） Docker 鏡像的 DaemonSet：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      tolerations:
      # 這些容忍度設(shè)置是為了讓該守護(hù)進(jìn)程集在控制平面節(jié)點(diǎn)上運(yùn)行
      # 如果你不希望自己的控制平面master節(jié)點(diǎn)運(yùn)行 Pod，可以刪除它們
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
        effect: NoSchedule
      - key: node-role.kubernetes.io/master
        operator: Exists
        effect: NoSchedule
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log

我們?yōu)槭裁匆O(shè)置容忍度呢，其實(shí)原因很簡(jiǎn)單，因?yàn)?strong>k8s會(huì)對(duì)master進(jìn)行污點(diǎn)標(biāo)記，導(dǎo)致Pod無(wú)法在master運(yùn)行，但是我們的日志收集的目的是可以在所有節(jié)點(diǎn)上運(yùn)行的，因此設(shè)置容忍度可以使這個(gè)Pod在master上也能正常運(yùn)行

污點(diǎn)和容忍度：

參考文檔：污點(diǎn)和容忍度 | Kubernetes

節(jié)點(diǎn)親和性?是?Pod?的一種屬性，它使 Pod 被吸引到一類(lèi)特定的節(jié)點(diǎn)?（這可能出于一種偏好，也可能是硬性要求）。?污點(diǎn)（Taint）?則相反——它使節(jié)點(diǎn)能夠排 Pod。

容忍度（Toleration）?是應(yīng)用于 Pod 上的。容忍度允許調(diào)度器調(diào)度帶有對(duì)應(yīng)污點(diǎn)的 Pod。 容忍度允許調(diào)度但并不保證調(diào)度：作為其功能的一部分， 調(diào)度器也會(huì)評(píng)估其他參數(shù)。

污點(diǎn)和容忍度（Toleration）相互配合，可以用來(lái)避免 Pod 被分配到不合適的節(jié)點(diǎn)上。 每個(gè)節(jié)點(diǎn)上都可以應(yīng)用一個(gè)或多個(gè)污點(diǎn)，這表示對(duì)于那些不能容忍這些污點(diǎn)的 Pod， 是不會(huì)被該節(jié)點(diǎn)接受的。

污點(diǎn)：給node和master節(jié)點(diǎn)打污點(diǎn)

容忍度：pod去容忍污點(diǎn)節(jié)點(diǎn)

你可以使用命令?kubectl taint?給node節(jié)點(diǎn)增加一個(gè)污點(diǎn)。比如：

kubectl taint nodes node1 key1=value1:NoSchedule

給節(jié)點(diǎn)?node1?增加一個(gè)污點(diǎn)，它的鍵名是?key1，鍵值是?value1，效果是?NoSchedule。 這表示只有擁有和這個(gè)污點(diǎn)相匹配的容忍度的 Pod 才能夠被分配到?node1?這個(gè)節(jié)點(diǎn)。

若要移除上述命令所添加的污點(diǎn)，你可以執(zhí)行：

kubectl taint nodes node1 key1=value1:NoSchedule-

你可以在 Pod 規(guī)約中為 Pod 設(shè)置容忍度。 下面兩個(gè)容忍度均與上面例子中使用?kubectl taint?命令創(chuàng)建的污點(diǎn)相匹配， 因此如果一個(gè) Pod 擁有其中的任何一個(gè)容忍度，都能夠被調(diào)度到?node1：

配置一：?

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"

#equal 就需要寫(xiě)key和value

配置二：?

tolerations:
- key: "key1"
  operator: "Exists"
  effect: "NoSchedule"

#exists 就不需要寫(xiě)value

先檢查key是否匹配，匹配是看operator是exists或者equal，這表示匹配，就會(huì)允許在有污點(diǎn)的node節(jié)點(diǎn)上啟動(dòng)這個(gè)Pod，effect可以理解為如果key不匹配，就不允許調(diào)度到這個(gè)污點(diǎn)節(jié)點(diǎn)。

這里是一個(gè)使用了容忍度的 Pod：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  tolerations:
  - key: "example-key"
    operator: "Exists"
    effect: "NoSchedule"

?operator?的默認(rèn)值是?Equal。

一個(gè)容忍度和一個(gè)污點(diǎn)相“匹配”是指它們有一樣的鍵名和效果，并且：

• 如果?operator?是?Exists（此時(shí)容忍度不能指定?value），或者
• 如果?operator?是?Equal，則它們的?value?應(yīng)該相等。

詳細(xì)請(qǐng)看官方文檔：污點(diǎn)和容忍度 | Kubernetes

4、Pod的資源控制

參考文檔：為容器和 Pod 分配內(nèi)存資源 | Kubernetes?

指定內(nèi)存請(qǐng)求和限制

創(chuàng)建一個(gè)命名空間，以便將本練習(xí)中創(chuàng)建的資源與集群的其余部分隔離。

kubectl create namespace mem-example

要為容器指定內(nèi)存請(qǐng)求，請(qǐng)?jiān)谌萜髻Y源清單中包含?resources: requests?字段。 同理，要指定內(nèi)存限制，請(qǐng)包含?resources: limits。

你將創(chuàng)建一個(gè)擁有一個(gè)容器的 Pod。 容器將會(huì)請(qǐng)求 100 MiB 內(nèi)存，并且內(nèi)存會(huì)被限制在 200 MiB 以?xún)?nèi)。 這是 Pod 的配置文件：

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo
  namespace: mem-example
spec:
  containers:
  - name: memory-demo-ctr
    image: polinux/stress
    resources:
      requests:
        memory: "100Mi"              #該 Pod 中容器的內(nèi)存請(qǐng)求為 100 MiB，內(nèi)存限制為 200 MiB。
      limits:
        memory: "200Mi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]

#配置文件的 args 部分提供了容器啟動(dòng)時(shí)的參數(shù)。 "--vm-bytes", "150M" 參數(shù)告知容器嘗試分配 150 MiB 內(nèi)存。

開(kāi)始創(chuàng)建 Pod：

kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit.yaml --namespace=mem-example

驗(yàn)證 Pod 中的容器是否已運(yùn)行：

kubectl get pod memory-demo --namespace=mem-example

查看 Pod 相關(guān)的詳細(xì)信息：

kubectl get pod memory-demo --output=yaml --namespace=mem-example

運(yùn)行?kubectl top?命令，獲取該 Pod 的指標(biāo)數(shù)據(jù)（前提是你已經(jīng)有在運(yùn)行中的?metrics-server）

添加?metrics-server：(73條消息) k8s集群安裝metrics-server_k8s安裝metrics_MssGuo的博客-CSDN博客

kubectl top pod memory-demo --namespace=mem-example

輸出結(jié)果顯示：Pod 正在使用的內(nèi)存大約為 162,900,000 字節(jié)，約為 150 MiB。 這大于 Pod 請(qǐng)求的 100 MiB，但在 Pod 限制的 200 MiB之內(nèi)。

NAME                        CPU(cores)   MEMORY(bytes)
memory-demo                 <something>  162856960

刪除 Pod：

kubectl delete pod memory-demo --namespace=mem-example

支持容器訪問(wèn)策略和容器帶寬限制：istio組件

5、一個(gè)Pod里面運(yùn)行多個(gè)容器：

Pod 的配置文件：

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo
  namespace: mem-example
spec:
  containers:
  - name: memory-demo-ctr
    image: polinux/stress
    resources:
      requests:
        memory: "100Mi"             
      limits:
        memory: "200Mi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]
  - name: webleader2
    image: docker.io/nginx
    resources:
      requests:
        cpu: 100m
        memory: "100Mi"             
      limits:
        memory: "200Mi"
    ports:
      - containerPort: 80

創(chuàng)建multi_c.yaml文件存儲(chǔ)Pod

[root@master pod]# vim multi_c.yaml 

開(kāi)始創(chuàng)建 Pod：

[root@master pod]# kubectl apply -f multi_c.yaml 
pod/memory-demo created

?驗(yàn)證 Pod 中的容器是否已運(yùn)行：

[root@master pod]# kubectl get pod -n mem-example   #表示有兩個(gè)容器在這個(gè)命名空間運(yùn)行
NAME          READY   STATUS    RESTARTS   AGE
memory-demo   2/2     Running   0          56s

內(nèi)部訪問(wèn)我創(chuàng)建的nginx容器：

[root@master pod]# curl 10.244.3.4
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a >nginx.org</a>.<br/>
Commercial support is available at
<a >nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
[root@master pod]# 

6、將創(chuàng)建的Pod發(fā)布出去：

參考文檔：?服務(wù)（Service） | Kubernetes

定義一個(gè)內(nèi)有nginx容器的Pod，并創(chuàng)建成功

[root@master pod]# cat my_nginx.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      run: my-nginx
  replicas: 3
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
        ports:
        - containerPort: 80
[root@master pod]# 

開(kāi)始創(chuàng)建 Pod：

[root@master pod]# kubectl apply -f my_nginx.yaml 

查看是否創(chuàng)建成功：

[root@master pod]# kubectl get pod -o wide
NAME                         READY   STATUS    RESTARTS   AGE   IP           NODE    NOMINATED NODE   READINESS GATES
k8s-nginx-6d779d947c-f72hf   1/1     Running   0          16h   10.244.1.4   node1   <none>           <none>
k8s-nginx-6d779d947c-hnhf5   1/1     Running   0          16h   10.244.3.2   node3   <none>           <none>
k8s-nginx-6d779d947c-xgjzg   1/1     Running   0          16h   10.244.2.2   node2   <none>           <none>
my-nginx-cf54cdbf7-8sbns     1/1     Running   0          13m   10.244.1.5   node1   <none>           <none>
my-nginx-cf54cdbf7-ptjw7     1/1     Running   0          8s    10.244.3.5   node3   <none>           <none>
my-nginx-cf54cdbf7-wf48x     1/1     Running   0          13m   10.244.2.4   node2   <none>           <none>
scnginx                      1/1     Running   0          10h   10.244.2.3   node2   <none>           <none>
[root@master pod]# 

創(chuàng)建Service服務(wù)，暴露我們的nginx容器服務(wù)（發(fā)布服務(wù)（服務(wù)類(lèi)型））

[root@master pod]# cat  my_service.yaml 
apiVersion: v1
kind: Service
metadata:
  name: my-nginx
  labels:
    run: my-nginx
spec:
  type: NodePort
  ports: 
    # 默認(rèn)情況下，為了方便起見(jiàn)，`targetPort` 被設(shè)置為與 `port` 字段相同的值。
  - port: 8080
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    run: my-nginx
    
[root@master pod]# 

開(kāi)始創(chuàng)建 Pod（service服務(wù)）：?

[root@master pod]# kubectl apply -f my_service.yaml 
service/my-nginx created
[root@master pod]# 

Service發(fā)布成功了?

[root@master pod]# kubectl get service
NAME         TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)          AGE
kubernetes   ClusterIP   10.0.0.1      <none>        443/TCP          19h
my-nginx     NodePort    10.6.55.120   <none>        8080:32465/TCP   63s
[root@master pod]# 

訪問(wèn)發(fā)布的Pod

我們只需要隨便訪問(wèn)k8s集群里的任何一臺(tái)node節(jié)點(diǎn)服務(wù)器，包括master

curl http://192.168.2.150:32465   #master的IP地址 + 端口

訪問(wèn)nginx容器的模擬圖：（外面的用戶(hù)訪問(wèn)Pod的數(shù)據(jù)流程：）

如上圖所示： 瀏覽器訪問(wèn) 192.168.2.150:32465? --》訪問(wèn)到?node1/2/3上 my-nginx 10.6.55.120:8080?--》最后訪問(wèn)到node節(jié)點(diǎn)里面的Pod內(nèi)的nginx容器? 10.244.1.5:80

其實(shí)中間還會(huì)存在一臺(tái)LB（負(fù)載均衡器）來(lái)分發(fā)流量給node1/2/3節(jié)點(diǎn)文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-534264.html

到了這里，關(guān)于Kubernetes 啟動(dòng)Pod的方法-Pod的調(diào)度算法-Pod間的通信-k8s的控制器-Pod資源控制-發(fā)布Service服務(wù)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！