kubernetes建立资源的两种方式

1、建立方式分类：

命令 vs 配置文件

Kubernetes 支持两种方式建立资源：

1.用 kubectl 命令行的方式直接建立，好比：

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

删除

kubectl delete deployment httpd-app

在命令行中经过参数指定资源的属性。

2.经过配置文件和 kubectl apply （就是编排文件，咱们能够把建立这个应用的过程写到编排文件里，而后让文件帮我建立应用）建立，要完成前面一样的工做，可执行命令：

kubectl apply -f httpd.yml

编排文件以下图，它通常都是以.yml为结尾的。

 

httpd.yml 的内容为：

资源的属性写在配置文件中，文件格式为 YAML。

apiVersion: extensions/v1beta1 #API版本 kind: Deployment #启动应用的类型 metadata: #对该资源的元数据的描述，就是说针对于Deployment他的元数据是什么 name: httpd-deployment #元数据里面最少要有一个name参数 spec: #对这个应用规格的描述 replicas: 2 #副本数（我启动这个应用他帮我编排几份） template: #模板（最少包含metadata、labels、name） metadata: #元数据，这是关于规格的元数据 labels: #标签 name: httpd spec: #这是容器的规格 containers: #容器 - name: httpd-app #容器的名字 image: reg.yunwei.edu/learn/httpd:latest  #容器应用的镜像

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

基于命令行的方式：

简单直观快捷，上手快。

适合临时测试或实验。

基于配置文件的方式：

配置文件描述了建立应用的过程，即应用最终要达到的状态。

配置文件提供了建立资源的模板，可以重复部署。

能够像管理代码同样管理部署。

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

这种方式要求熟悉配置文件的语法，有必定难度。

后面咱们都将采用配置文件的方式，你们须要尽快熟悉和掌握。

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配置文件：

执行以下命令：

#运行pod 
kubectl apply -f httpd.yml #删除pod 
kubectl delete -f http.yml

（1）伸缩（Scale Up/Down）: 是指在线增长或减小 Pod 的副本数。直接写改yaml配置文件的replicas: 参数便可

出于安全考虑，默认配置下 Kubernetes 不会将 Pod 调度到 Master 节点。

演示：

编排文件以下

 

如今咱们经过编排文件启动一下这个应用

kubectl apply –f httpd.yml

而后咱们获取一下pod

kubectl get pod

 

咱们在查看一下pod的详细信息

kubectl get pod –o wide

 

　　如今是每一个节点都有一个pod，由于咱们设置的3副本，假如说有一天我172.16.254.23节点宕机了，那么他节点上的两个pod就不能正常工做了，那么怎么办么？它会把这两个pod迁移到172.16.254.22这个节点上，在22节点运行了3个副本，这就是弹性伸缩。

你还能够直接从三副本设置成1副本

vim httpd.yml replicas： 1 kubectl apply –f httpd.yml

 

（2）节点故障（Failover）: 好比Kubernetes 检查到 k8s-node3 不可用，将 k8s-node3 上的 Pod 标记为 Unknown 状态，并在 k8s-node2 上新建立两个 Pod，维持总副本数为原指定副本数 3。

当 k8s-node3恢复后，Unknown 的 Pod 会被删除，不过已经运行的 Pod 不会从新调度回 k8s-node3。

（3）用 label 控制 Pod 的位置： 默认配置下，Scheduler 会将 Pod 调度到全部可用的 Node。不过有些状况咱们但愿将 Pod 部署到指定的 Node，好比将有大量磁盘 I/O 的 Pod 部署到配置了 SSD 的 Node；或者 Pod 须要 GPU，须要运行在配置了 GPU 的节点上。（指定应用的启动）

Kubernetes 是经过 label 来实现这个功能的。label 是 key-value 对，各类资源均可以设置 label，灵活添加各类自定义属性。

演示：

咱们先查看默认的node的标记（label）方式

kubectl get node --show-labels

 

如今的每一个节点的labels都是同样的，都是公平的，如今咱们给23升个级，给它打个别的标记。

好比执行以下命令标注 k8s-node3 是配置了 SSD 的节点。

 #这是先给要想启动到的节点打个标记

kubectl label node 172.16.254.23 disktype=ssd

而后咱们在看一下各个node的标记

kubectl get node --show-labels

 

disktype=ssd 已经成功添加到 k8s-node3，除了 disktype，Node 还有几个 Kubernetes 本身维护的 label。

有了 disktype 这个自定义 label，接下来就能够指定将 Pod 部署到 k8s-node3。编辑 httpd.yml：

 

　　在 Pod 模板的 spec 里经过 nodeSelector （选择）指定将此 Pod 部署到具备：label disktype=ssd 的 Node 上。咱们将副本数调为3，看看是否pod都起在了标有disktype=ssd 的labels上。

执行编排文件

kubectl apply –f http.yml

获取pod详细信息

kubectl get pod –o wide

 

要删除 label disktype，执行以下命令：

kubectl label node k8s-node1 disktype-

即删除。 不过此时 Pod 并不会从新部署，依然在原来的node上运行。

 

kubectl get node --show-labels

除非在 nginx.yml 中删除 nodeSelector 设置，而后经过 kubectl apply 从新部署。 Kubernetes 会删除以前的 Pod 并调度和运行新的 Pod。

 

Kubernetes 会删除以前的 Pod 并调度和运行新的 Pod。

3、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 组件。

kubectl get daemonset –n kube-system –o wide

 

　　由于 calico-node 属于系统组件，须要在命令行中经过 --namespace=kube-system 指定 namespace kube-system。若是不指定则只返回默认 namespace default 中的资源。

calico的编排文件以下：