? 一、創建方式分類： 命令 vs 配置文件 Kubernetes 支持兩種方式創建資源： 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 的內容為： 資源的屬性寫在配置文件中，文件格式為 YAML。 apiVersion: extensions/v1beta1 kind: Deployment metadata:name: httpd-deployment spec:replicas: 2template:metadata:labels:name: httpdspec:containers:- name: httpd-appimage: reg.yunwei.edu/learn/httpd:latest

?

下面對這兩種方式進行比較。 基于命令的方式：

簡單直觀快捷，上手快。

適合臨時測試或實驗。

? 基于配置文件的方式：

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

配置文件提供了創建資源的模板，能夠重復部署。

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

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

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

后面我們都將采用配置文件的方式，大家需要盡快熟悉和掌握。 kubectl apply?不但能夠創建 Kubernetes 資源，也能對資源進行更新，非常方便。不過 Kubernets 還提供了幾個類似的命令，例如?kubectl create、kubectl replace、kubectl edit?和?kubectl patch。 為避免造成不必要的困擾，我們會盡量只使用?kubectl apply， 此命令已經能夠應對超過 90% 的場景，事半功倍。 ? ? ? 二：?讀懂 Deployment YAML Deployment 的配置格式 分析一個 Deployment 的配置文件。?其他 Controller（比如 DaemonSet）非常類似。 ①?apiVersion?是當前配置格式的版本。 ②?kind?是要創建的資源類型，這里是?Deployment。 ③?metadata?是該資源的元數據，name?是必需的元數據項。 ④?spec?部分是該?Deployment?的規格說明。 ⑤?replicas?指明副本數量，默認為 1。 ⑥?template?定義 Pod 的模板，這是配置文件的重要部分。 ⑦?metadata?定義 Pod 的元數據，至少要定義一個 label。label 的 key 和 value 可以任意指定。 ⑧?spec?描述 Pod 的規格，此部分定義 Pod 中每一個容器的屬性，name?和?image?是必需的。 ? ? 運行yaml配置文件： ? 執行如下命令： ?kubectl apply -f?httpd.yml??? ?運行pod ?kubectl delete -f http.yml? ? ??刪除pod ? （1）伸縮（Scale Up/Down）:?是指在線增加或減少 Pod 的副本數。直接寫改yaml配置文件的replicas: 參數即可 ? 出于安全考慮，默認配置下 Kubernetes 不會將 Pod 調度到 Master 節點。 ? ? （2）節點故障（Failover）:?若其中一個node故障，?Kubernetes 會檢查到 k8s-node1 不可用，將 k8s-node1 上的 Pod 標記為?Unknown?狀態，并在 k8s-node2 上新創建兩個 Pod，維持總副本數為原指定副本數 3。 ? 當 k8s-node1 恢復后，Unknown 的 Pod 會被刪除，不過已經運行的 Pod 不會重新調度回 k8s-node1。 ? ? （3）用 label 控制 Pod 的位置：?默認配置下，Scheduler 會將 Pod 調度到所有可用的 Node。不過有些情況我們希望將 Pod 部署到指定的 Node，比如將有大量磁盤 I/O 的 Pod 部署到配置了 SSD 的 Node；或者 Pod 需要 GPU，需要運行在配置了 GPU 的節點上。 ? Kubernetes 是通過 label 來實現這個功能的。label 是 key-value 對，各種資源都可以設置 label，靈活添加各種自定義屬性。比如執行如下命令標注 k8s-node3 是配置了 SSD 的節點。 kubectl label node 172.16.254.23 disktype=ssd ? 然后通過：kubectl get node --show-labels??查看節點的 label。 disktype=ssd?已經成功添加到 k8s-node3，除了?disktype，Node 還有幾個 Kubernetes 自己維護的 label。 ? 有了?disktype?這個自定義 label，接下來就可以指定將 Pod 部署到 k8s-node3。編輯 httpd.yml： 在 Pod 模板的?spec?里通過?nodeSelector?指定將此 Pod 部署到具有： label?disktype=ssd?的 Node 上。 部署 Deployment 并查看 Pod 的運行節點： kubectl apply -f . kubectl get pod -o wide 全部 2 個副本都運行在 k8s-node1 上，符合我們的預期。 ? 要刪除 label disktype，執行如下命令：kubectl label node k8s-node1 disktype-?即刪除。?不過此時 Pod 并不會重新部署，依然在 k8s-node1 上運行。 kubectl get node --show-labels 除非在 nginx.yml 中刪除?nodeSelector?設置，然后通過?kubectl apply?重新部署。?Kubernetes 會刪除之前的 Pod 并調度和運行新的 Pod。 Kubernetes 會刪除之前的 Pod 并調度和運行新的 Pod。 ? ? 三、DaemonSet： DeamonSet應用 Deployment 部署的副本 Pod 會分布在各個 Node 上，每個 Node 都可能運行好幾個副本。DaemonSet 的不同之處在于：每個 Node 上最多只能運行一個副本。 DaemonSet 的典型應用場景有：

在集群的每個節點上運行存儲 Daemon，比如 glusterd 或 ceph。

在每個節點上運行日志收集 Daemon，比如 flunentd 或 logstash。

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

其實 Kubernetes 自己就在用 DaemonSet 運行系統組件。執行如下命令： kubectl get daemonset --namespace=kube-system DaemonSet?calico-node分別負責在每個節點上運行?calico-node?組件。 因為?calico-node?屬于系統組件，需要在命令行中通過?--namespace=kube-system?指定 namespace?kube-system。如果不指定則只返回默認 namespace?default?中的資源。

轉載于:https://www.cnblogs.com/zhou2019/p/10799591.html

總結

以上是生活随笔為你收集整理的第5篇K8S创建资源的两种方式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。