k8s创建资源 - 猪肉佬！

一、创建方式分类：

命令 vs 配置文件

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

1.用 kubectl 命令直接创建（适用于少数的pod创建）

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

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

[root@cicd ~]# kubectl run httpd-app --image=reg.yunwei.edu/learn/httpd:latest --replicas=2
deployment "httpd-app" created


查看创建的pod信息
[root@cicd ~]# kubectl get pod -o wide
NAME                        READY     STATUS    RESTARTS   AGE       IP             NODE
httpd-app-cfb6dc947-lq58d   1/1       Running   0          6m        172.20.135.5   192.168.253.10
httpd-app-cfb6dc947-rp8wm   1/1       Running   0          6m        172.20.104.3   192.168.253.11

查看deployment信息
[root@cicd ~]# kubectl get deployment -o wide 
NAME        DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE       CONTAINERS   IMAGES                              SELECTOR
httpd-app   2         2         2            2           9m        httpd-app    reg.yunwei.edu/learn/httpd:latest   run=httpd-app

可以看到容器名为httpd-app，deployment名为httpd-app

2）查看名为httpd-app的deployment详细描述。

[root@cicd ~]# kubectl describe deployment httpd-app

可以看到deploy的命名空间default和deplyment的来源以及创建了一个名为replicaset的子组件。组件名为httpd-app-cfb6dc947。

deployment的子组件取名方式为在父名后面加上-字符串。

3）我们再通过查看replicaset 的详细信息来了解创建的流程。

[root@cicd ~]# kubectl describe replicaset httpd-app-cfb6dc947

名称和空间

标签（labels）

容器

然后最重要的是来源controller-replicaset，并且创建了两组pod资源

由此可见创建流程为：

controller——deployment——relpicaset——pod

当然如果想更加直观简单的查看replicaset等状态，可以执行：

[root@cicd ~]# kubectl get replicaset 
NAME                  DESIRED   CURRENT   READY     AGE
httpd-app-cfb6dc947   2         2         2         13m
[root@cicd ~]# kubectl get replicaset -o wide
NAME                  DESIRED   CURRENT   READY     AGE       CONTAINERS   IMAGES                              SELECTOR
httpd-app-cfb6dc947   2         2         2         13m       httpd-app    reg.yunwei.edu/learn/httpd:latest   pod-template-hash=796287503,run=httpd-app

2. 通过配置文件和 kubectl apply 创建，要完成前面同样的工作，可执行命令：

kubectl apply -f httpd.yml

httpd.yml 的内容为：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: httpd-deployment
spec:
  replicas: 1
  template:
    metadata:
      labels:
        name: httpd
    spec:
      containers:
      - name: httpd-app
        image: reg.yunwei.edu/learn/httpd:latest

httpd.yml

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

基于命令的方式：

简单直观快捷，上手快。
适合临时测试或实验。

基于配置文件的方式：

配置文件描述了 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

[root@cicd ~]# kubectl apply -f httpd.yml 
deployment "httpd-deployment" configured

kubectl delete -f http.yml 删除pod

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

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

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

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

如果需要调回，可以更改配置文件来指定调度。

（3）用 label 控制 Pod 的位置（指定node时）：默认配置下，Scheduler 会将 Pod 调度到所有可用的 Node。不过有些情况我们希望将 Pod 部署到指定的 Node，比如将有大量磁盘 I/O 的 Pod 部署到配置了 SSD 的 Node；或者 Pod 需要 GPU，需要运行在配置了 GPU 的节点上。

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

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

kubectl label node 192.168.253.11 disktype=ssd

[root@cicd ~]# kubectl label node 192.168.253.11 disktype=ssd
node "192.168.253.11" labeled

2、然后通过：kubectl get node --show-labels 查看节点的 label。

disktype=ssd 已经成功添加到192.168.253.11，除了 disktype，Node 还有几个 Kubernetes 自己维护的 label。

[root@cicd ~]# kubectl get node --show-labels
NAME             STATUS                     ROLES     AGE       VERSION   LABELS
192.168.253.10   Ready                      <none>    21h       v1.9.7    beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=192.168.253.10
192.168.253.11   Ready                      <none>    21h       v1.9.7    beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,disktype=ssd,kubernetes.io/hostname=192.168.253.11
192.168.253.14   Ready,SchedulingDisabled   <none>    21h       v1.9.7    beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=192.168.253.14

3、有了 disktype 这个自定义 label，接下来就可以指定将 Pod 部署到 11节点。编辑 httpd.yml：

在 Pod 模板的 spec 里通过 nodeSelector 指定将此 Pod 部署添加到到具有 label disktype=ssd 的 Node 上，也就是11节点上。

在httpd.yml文件的末尾添加下面两行：

nodeSelector：
disktype: ssd

注意nodeSelector的大小写以及与container的对齐

4、部署 Deployment 并查看 Pod 的运行节点：

kubectl apply -f .

kubectl get pod -o wide

5、然后查看pod状态

发现全部 3 个副本都运行在 k8s-node1 上，符合我们的预期。

[root@cicd ~]# kubectl get pod -o wide
NAME                               READY     STATUS    RESTARTS   AGE       IP              NODE
httpd-deployment-957479bb9-xpvn4   1/1       Running   0          2h        172.20.135.11   192.168.253.10
httpd-deployment-957479bb9-xpvrl   1/1       Running   0          2h        172.20.104.13   192.168.253.10
httpd-deployment-957479bb9-zqzgw   1/1       Running   0          2h        172.20.135.12   192.168.253.10

6、要删除 label disktype，执行如下命令：kubectl label node k8s-node1 disktype- 即删除。

[root@cicd ~]# kubectl label node 192.168.253.11 disktype-
node "192.168.253.11" labeled

7、再次查看pod状态，发现disktype=ssh的标签已经删除。不过此时 Pod 并不会重新部署，依然在 k8s-node1 上运行。

kubectl get node --show-labels

root@cicd ~]# kubectl get node --show-labels
NAME             STATUS                     ROLES     AGE       VERSION   LABELS
192.168.253.10   Ready                      <none>    21h       v1.9.7    beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=192.168.253.10
192.168.253.11   Ready                      <none>    21h       v1.9.7    beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=192.168.253.11
192.168.253.14   Ready,SchedulingDisabled   <none>    21h       v1.9.7    beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=192.168.253.14

除非在 nginx.yml 中删除 nodeSelector 设置，然后通过 kubectl apply 重新部署。 Kubernetes 会删除之前的 Pod 并调度和运行新的 Pod。

#　　nodeSelector：
# 　　disktype: ssd

以及 kubectl apply -f http.yml

三、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

[root@cicd ~]# kubectl get daemonset --namespace=kube-system -o wide
NAME          DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE       CONTAINERS                IMAGES                                 SELECTOR
calico-node   3         3         3         3            3           <none>          19h       calico-node,install-cni   calico/node:v3.0.6,calico/cni:v2.0.5   k8s-app=calico-node

DaemonSet calico-node分别负责在每个节点上运行 calico-node 组件。

因为 calico-node 属于系统组件，需要在命令行中通过 --namespace=kube-system 指定 namespace kube-system。如果不指定则只返回默认 namespace default 中的资源。

posted on 2019-06-20 15:25 猪肉佬！阅读(260) 评论(0) 编辑收藏举报