Kubernetes 创建资源的两种方式

一、创建方式分类:

命令 VS 配置文件

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: 2
  template:
    metadata:
      labels:
        name: httpd
    spec:
      containers:
      - name: httpd-app
        image: reg.yunwei.edu/learn/httpd:latest

下面对这两种方式进行比较。

基于命令的方式:

  1、简单直观快捷,上手快。

  2、适合临时测试或实验

基于配置文件的方式:

  1、配置文件描述 What ,即应用最终要达到的状态。

  2、配置文件提供了创建资源的模板,能给重复部署。

  3、可以像管理代码一样管理部署。

  4、适合正式的、跨环境的、规模化部署。

  5、这种方式要求熟悉配置文件的语法,有一定难度。

kubect apply 不但能够创建 Kubernetes 资源,也能对资源进行更新,非常方便。不过 Kubernetes 还提供了几个类似的命令,列如 kubectl creat、kubectl replace、 kubectl edit 和 kubectl patch。

为避免造成不必要的困扰,我们会尽量只使用 kubectl apply。

此命令已经足够应对超过 90% 的场景。

二:读懂 Deployment YAML

Deployment 的配置格式

 分析一个 Deployment 的配置文件。 其他 Controller (比如 DaemonSet)非常类似。

  1. apiVersion 是当前配置格式的版本。
  2. kind 是要创建的资源类型,这里是 Deployment。
  3. metadata 是该资源的元数据,name 是必需的元数据项。
  4. spac 部分是该 Deployment 的规格说明。
  5. replicas 指明副本数量,默认为 1 。
  6. template 定义 Pod 的模板,这是配置文件的重要部分。
  7. metadata 定义 Pod 的元数据,至少要定义一个 label。label 的 key 和 value 可以任意指定。
  8. spec 描述 Pod 的规格,此部分定义 Pod 中每一个容器的属性,name 和 image 是必需的。

运行 yam 的配置文件:

执行如下命令:

kubectl apply -f httpd.yml    运行 pod

kubectl delete -f httpd.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 是通过 lable 来实现这个功能。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 的典型应用场景有:

  1、在集群的每个节点上运行存储 Deamon ,比如 glusterd 或 ceph 。

  2、在每个节点上运行日志收集 Deamon , 比如 flunentd 或 logstash。

  3、在每个节点上运行监控 Deamon , 比如 Prometheus Node Exproter 或 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/lwl117/p/11215703.html