k8s創建資源的兩種方式、訪問pod

創建資源

1.用kubectl命令直接創建,

 

#kubectl run httpd-app --image=reg.yunwei.edu/learn/httpd:latest --replicas=2

在命令行中通過參數指定資源的屬性。

2. 通過配置文件和 kubectl apply 創建,要完成前面同樣的工作,可執行命令:

#kubectl apply -f httpd.yml

httpd.yml 的內容爲:

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

  name: httpd-deployment

spec:

  replicas: 2

  template:

    metadata:

      labels:

        name: httpd

    spec:

      containers:

      - name: httpd-app

        image: reg.yunwei.edu/test/httpd:latest

 

#kubectl apply -f httpd.yml

#kubectl get pod

下面對這兩種方式進行比較。

基於命令的方式:

  1. 簡單直觀快捷,上手快。

  2. 適合臨時測試或實驗。

 

基於配置文件的方式:

  1. 配置文件描述了 What,即應用最終要達到的狀態。

  2. 配置文件提供了創建資源的模板,能夠重複部署。

  3. 可以像管理代碼一樣管理部署。

  4. 適合正式的、跨環境的、規模化部署。

  5. 這種方式要求熟悉配置文件的語法,有一定難度。

 

kubectl apply 不但能夠創建 Kubernetes 資源,也能對資源進行更新,非常方便。不過 Kubernets 還提供了幾個類似的命令,例如 kubectl createkubectl replacekubectl edit 和 kubectl patch

deployment的配置格式

1、apiVersion 是當前配置格式的版本。

2、kind 是要創建的資源類型,這裏是 Deployment。

3、metadata 是該資源的元數據,name 是必需的元數據項。

4、spec 部分是該 Deployment 的規格說明。

5、replicas 指明副本數量,默認爲 1。

6、template 定義 Pod 的模板,這是配置文件的重要部分。

7、metadata 定義 Pod 的元數據,至少要定義一個 label。label 的 key 和 value 可以任意指定。

8、labels打一個標籤

9、spec 描述 Pod 的規格,此部分定義 Pod 中每一個容器的屬性,name 和 image 是必需的。

運行yaml配置文件

運行pod
#kubectl apply -f httpd.yml

刪除pod
#kubectl delete -f httpd.yml

(1)伸縮(Scale Up/Down): 是指在線增加或減少 Pod 的副本數。直接寫改yaml配置文件的replicas: 參數即可出於安全考慮,默認配置下 Kubernetes 不會將 Pod 調度到 Master 節點。

通過修改yaml文件使pod節點增加爲3個

(2)節點故障(Failover): 若其中一個node故障, Kubernetes 會檢查到 k8s-node3 不可用,將 k8s-node1 上的 Pod 標爲 Unknown 狀態,並在 k8s-node2 上新創建兩個 Pod,維持總副本數爲原指定副本數 3。當 k8s-node2 恢復後,Unknown 的 Pod 會被刪除,不過已經運行的 Pod 不會重新調度回 k8s-node2。

 

(3)用 label 控制 Pod 的位置: 默認配置下,Scheduler 會將 Pod 調度到所有可用的 Node。不過有些情況我們希望將 Pod 部署到指定的 Node,比如將有大量磁盤 I/O 的 Pod 部署到配置了 SSD 的 Node;或者 Pod 需要 GPU,需要運行在配置了 GPU 的節點上。

獲取所有節點標記
#kubectl get node --show-labels

給154的節點打個標記
#kubectl label node 192.168.146.154 disktype=ssd

修改yaml文件,添加兩行

刪除節點標籤(指定爲空)
#kubectl label node 192.168.146.154 disktpye-

DaemonSet應用

Deployment 部署的副本 Pod 會分佈在各個 Node 上,每個 Node 都可能運行好幾個副本。DaemonSet 的不同之處在於:每個 Node 上最多隻能運行一個副本。

DaemonSet 的典型應用場景有:

  1. 在集羣的每個節點上運行存儲 Daemon,比如 glusterd 或 ceph。

  2. 在每個節點上運行日誌收集 Daemon,比如 flunentd 或 logstash。

  3. 在每個節點上運行監控 Daemon,比如 Prometheus Node Exporter 或 collectd。

#kubectl get daemonset --namespace=kube-system

DaemonSet calico-node分別負責在每個節點上運行 calico-node 組件。

如何訪問pod

通過service訪問pod

每個 Pod 都有自己的 IP 地址。當舊的Pod down了後, controller 用新 Pod 替代發生故障的 Pod 時,新 Pod 會分配到新的 IP 地址,導致提供服務的Pod的ip會發生變化。

Kubernetes Service 從邏輯上代表了一組 Pod,具體是哪些 Pod 則是由 label 來挑選。Service 有自己 IP,而且這個 IP 是不變的。客戶端只需要訪問 Service 的 IP,Kubernetes 則負責建立和維護 Service 與 Pod 的映射關係。無論後端 Pod 如何變化,對客戶端不會有任何影響,因爲 Service 沒有變。

創建Service

創建service文件
#vim httpd-svc.yml

apiVersion: v1

kind: Service

metadata:

  name: httpd-svc

spec:

  ports:

    - port: 8080

      targetPort: 80

#將service的8080端口映射到pod的80端口

      protocol: TCP

  selector:

    run: httpd

#vim httpd.yml

 

  labels:

    name: httpd

    run: httpd

spec:

  containers:

    ports:

    - containerPort: 80

 

#kubectl apply -f httpd.yml
#kubectl apply -f httpd-svc.yml

修改httpd的編排文件,重新創建,發現pod的ip發生改變,再訪問service ip

    

 Service IP原理

 

Service Cluster IP 是一個虛擬 IP,是由 Kubernetes 節點上的 iptables 規則管理的。可以通過 iptables-save 命令打印出當前節點的 iptables 規則。

由路由轉發規則可知,訪問service ip10.68.225.168:8080時,需要轉發2次,才能訪問到pod ip172.20.182.210:80

DNS訪問Service

 

在 Cluster 中,除了可以通過 Cluster IP 訪問 Service,Kubernetes 還提供了更爲方便的 DNS 訪問。

 

kubeadm 部署時會默認安裝 kube-dns 組件。

coredns 是一個 DNS 服務器。每當有新的 Service 被創建,coredns 會添加該 Service 的 DNS 記錄。Cluster 中的 Pod 可以通過 <SERVICE_NAME>.<NAMESPACE_NAME> 訪問 Service。

比如可以用 httpd-svc.default 訪問 Service httpd-svc。

外網訪問Service

 

#vim httpd-svc.yml

#nodePort: 26055 

#也可以使用隨機端口,端口號範圍2000-40000

ClusterIP 

Service 通過 Cluster 內部的 IP 對外提供服務,只有 Cluster 內的節點和 Pod 可訪問,這是默認的 Service 類型,前面實驗中的 Service 都是 ClusterIP。

 

NodePort 

Service 通過 Cluster 節點的靜態端口對外提供服務。Cluster 外部可以通過 <NodeIP>:<NodePort> 訪問 Service。

 

LoadBalancer 

Service 利用 cloud provider 特有的 load balancer 對外提供服務,cloud provider 負責將 load balancer 的流量導向 Service。目前支持的 cloud provider 有 GCP、AWS、Azur 等。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章