精华内容
下载资源
问答
  • 本文主要简单介绍了nodeName,nodeValue,nodeType,typeof 的区别,算是知识点的一个小总结,希望对小伙伴们有所帮助
  • 本文详细介绍了nodeName、nodeValue和nodeType属性
  • Kubernetes K8S之固定节点nodeName和nodeSelector调度详解与示例

    Kubernetes K8S之固定节点nodeName和nodeSelector调度详解与示例

    主机配置规划

    服务器名称(hostname)系统版本配置内网IP外网IP(模拟)
    k8s-masterCentOS7.72C/4G/20G172.16.1.11010.0.0.110
    k8s-node01CentOS7.72C/4G/20G172.16.1.11110.0.0.111
    k8s-node02CentOS7.72C/4G/20G172.16.1.11210.0.0.112

    nodeName调度

    nodeName是节点选择约束的最简单形式,但是由于其限制,通常很少使用它。nodeName是PodSpec的领域。

    pod.spec.nodeName将Pod直接调度到指定的Node节点上,会【跳过Scheduler的调度策略】,该匹配规则是【强制】匹配。可以越过Taints污点进行调度。

    nodeName用于选择节点的一些限制是:

    • 如果指定的节点不存在,则容器将不会运行,并且在某些情况下可能会自动删除。
    • 如果指定的节点没有足够的资源来容纳该Pod,则该Pod将会失败,并且其原因将被指出,例如OutOfmemory或OutOfcpu。
    • 云环境中的节点名称并非总是可预测或稳定的。

    nodeName示例

    获取当前的节点信息

    [root@k8s-master scheduler]# kubectl get nodes -o wide
    NAME         STATUS   ROLES    AGE   VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE                KERNEL-VERSION           CONTAINER-RUNTIME
    k8s-master   Ready    master   42d   v1.17.4   172.16.1.110   <none>        CentOS Linux 7 (Core)   3.10.0-1062.el7.x86_64   docker://19.3.8
    k8s-node01   Ready    <none>   42d   v1.17.4   172.16.1.111   <none>        CentOS Linux 7 (Core)   3.10.0-1062.el7.x86_64   docker://19.3.8
    k8s-node02   Ready    <none>   42d   v1.17.4   172.16.1.112   <none>        CentOS Linux 7 (Core)   3.10.0-1062.el7.x86_64   docker://19.3.8
    

    当nodeName指定节点存在

    要运行的yaml文件

    [root@k8s-master scheduler]# pwd
    /root/k8s_practice/scheduler
    [root@k8s-master scheduler]# cat scheduler_nodeName.yaml 
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: scheduler-nodename-deploy
      labels:
        app: nodename-deploy
    spec:
      replicas: 5
      selector:
        matchLabels:
          app: myapp
      template:
        metadata:
          labels:
            app: myapp
        spec:
          containers:
          - name: myapp-pod
            image: registry.cn-beijing.aliyuncs.com/google_registry/myapp:v1
            imagePullPolicy: IfNotPresent
            ports:
              - containerPort: 80
          # 指定节点运行
          nodeName: k8s-master
    

    运行yaml文件并查看信息

    [root@k8s-master scheduler]# kubectl apply -f scheduler_nodeName.yaml 
    deployment.apps/scheduler-nodename-deploy created
    [root@k8s-master scheduler]# 
    [root@k8s-master scheduler]# kubectl get deploy -o wide
    NAME                        READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES                                                      SELECTOR
    scheduler-nodename-deploy   0/5     5            0           6s    myapp-pod    registry.cn-beijing.aliyuncs.com/google_registry/myapp:v1   app=myapp
    [root@k8s-master scheduler]# 
    [root@k8s-master scheduler]# kubectl get rs -o wide
    NAME                                  DESIRED   CURRENT   READY   AGE   CONTAINERS   IMAGES                                                      SELECTOR
    scheduler-nodename-deploy-d5c9574bd   5         5         5       15s   myapp-pod    registry.cn-beijing.aliyuncs.com/google_registry/myapp:v1   app=myapp,pod-template-hash=d5c9574bd
    [root@k8s-master scheduler]# 
    [root@k8s-master scheduler]# kubectl get pod -o wide
    NAME                                        READY   STATUS    RESTARTS   AGE   IP             NODE         NOMINATED NODE   READINESS GATES
    scheduler-nodename-deploy-d5c9574bd-6l9d8   1/1     Running   0          23s   10.244.0.123   k8s-master   <none>           <none>
    scheduler-nodename-deploy-d5c9574bd-c82cc   1/1     Running   0          23s   10.244.0.119   k8s-master   <none>           <none>
    scheduler-nodename-deploy-d5c9574bd-dkkjg   1/1     Running   0          23s   10.244.0.122   k8s-master   <none>           <none>
    scheduler-nodename-deploy-d5c9574bd-hcn77   1/1     Running   0          23s   10.244.0.121   k8s-master   <none>           <none>
    scheduler-nodename-deploy-d5c9574bd-zstjx   1/1     Running   0          23s   10.244.0.120   k8s-master   <none>           <none>
    

    由上可见,yaml文件中nodeName: k8s-master生效,所有pod被调度到了k8s-master节点。如果这里是nodeName: k8s-node02,那么就会直接调度到k8s-node02节点。

    当nodeName指定节点不存在

    要运行的yaml文件

    [root@k8s-master scheduler]# pwd
    /root/k8s_practice/scheduler
    [root@k8s-master scheduler]# cat scheduler_nodeName_02.yaml 
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: scheduler-nodename-deploy
      labels:
        app: nodename-deploy
    spec:
      replicas: 5
      selector:
        matchLabels:
          app: myapp
      template:
        metadata:
          labels:
            app: myapp
        spec:
          containers:
          - name: myapp-pod
            image: registry.cn-beijing.aliyuncs.com/google_registry/myapp:v1
            imagePullPolicy: IfNotPresent
            ports:
              - containerPort: 80
          # 指定节点运行,该节点不存在
          nodeName: k8s-node08
    

    运行yaml文件并查看信息

    [root@k8s-master scheduler]# kubectl apply -f scheduler_nodeName_02.yaml 
    deployment.apps/scheduler-nodename-deploy created
    [root@k8s-master scheduler]# 
    [root@k8s-master scheduler]# kubectl get deploy -o wide
    NAME                        READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES                                                      SELECTOR
    scheduler-nodename-deploy   0/5     5            0           4s    myapp-pod    registry.cn-beijing.aliyuncs.com/google_registry/myapp:v1   app=myapp
    [root@k8s-master scheduler]# 
    [root@k8s-master scheduler]# kubectl get rs -o wide
    NAME                                   DESIRED   CURRENT   READY   AGE   CONTAINERS   IMAGES                                                      SELECTOR
    scheduler-nodename-deploy-75944bdc5d   5         5         0       9s    myapp-pod    registry.cn-beijing.aliyuncs.com/google_registry/myapp:v1   app=myapp,pod-template-hash=75944bdc5d
    [root@k8s-master scheduler]# 
    [root@k8s-master scheduler]# kubectl get pod -o wide
    NAME                                         READY   STATUS    RESTARTS   AGE   IP       NODE         NOMINATED NODE   READINESS GATES
    scheduler-nodename-deploy-75944bdc5d-c8f5d   0/1     Pending   0          13s   <none>   k8s-node08   <none>           <none>
    scheduler-nodename-deploy-75944bdc5d-hfdlv   0/1     Pending   0          13s   <none>   k8s-node08   <none>           <none>
    scheduler-nodename-deploy-75944bdc5d-q9qgt   0/1     Pending   0          13s   <none>   k8s-node08   <none>           <none>
    scheduler-nodename-deploy-75944bdc5d-q9zl7   0/1     Pending   0          13s   <none>   k8s-node08   <none>           <none>
    scheduler-nodename-deploy-75944bdc5d-wxsnv   0/1     Pending   0          13s   <none>   k8s-node08   <none>           <none>
    

    由上可见,如果指定的节点不存在,则容器将不会运行,一直处于Pending 状态。

    nodeSelector调度

    nodeSelector是节点选择约束的最简单推荐形式。nodeSelector是PodSpec的领域。它指定键值对的映射。

    Pod.spec.nodeSelector是通过Kubernetes的label-selector机制选择节点,由调度器调度策略匹配label,而后调度Pod到目标节点,该匹配规则属于【强制】约束。由于是调度器调度,因此不能越过Taints污点进行调度。

    nodeSelector示例

    获取当前的节点信息

    [root@k8s-master ~]# kubectl get node -o wide --show-labels
    NAME         STATUS   ROLES    AGE   VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE                KERNEL-VERSION           CONTAINER-RUNTIME   LABELS
    k8s-master   Ready    master   42d   v1.17.4   172.16.1.110   <none>        CentOS Linux 7 (Core)   3.10.0-1062.el7.x86_64   docker://19.3.8     beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-master,kubernetes.io/os=linux,node-role.kubernetes.io/master=
    k8s-node01   Ready    <none>   42d   v1.17.4   172.16.1.111   <none>        CentOS Linux 7 (Core)   3.10.0-1062.el7.x86_64   docker://19.3.8     beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node01,kubernetes.io/os=linux
    k8s-node02   Ready    <none>   42d   v1.17.4   172.16.1.112   <none>        CentOS Linux 7 (Core)   3.10.0-1062.el7.x86_64   docker://19.3.8     beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node02,kubernetes.io/os=linux
    

    添加label标签

    运行kubectl get nodes以获取群集节点的名称。然后可以对指定节点添加标签。比如:k8s-node01的磁盘为SSD,那么添加disk-type=ssd;k8s-node02的CPU核数高,那么添加cpu-type=hight;如果为Web机器,那么添加service-type=web。怎么添加标签可以根据实际规划情况而定。

    ### 给k8s-node01 添加指定标签
    [root@k8s-master ~]# kubectl label nodes k8s-node01 disk-type=ssd
    node/k8s-node01 labeled
    #### 删除标签命令 kubectl label nodes k8s-node01 disk-type-
    [root@k8s-master ~]# 
    [root@k8s-master ~]# kubectl get node --show-labels
    NAME         STATUS   ROLES    AGE   VERSION   LABELS
    k8s-master   Ready    master   42d   v1.17.4   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-master,kubernetes.io/os=linux,node-role.kubernetes.io/master=
    k8s-node01   Ready    <none>   42d   v1.17.4   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,disk-type=ssd,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node01,kubernetes.io/os=linux
    k8s-node02   Ready    <none>   42d   v1.17.4   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node02,kubernetes.io/os=linux
    

    由上可见,已经为k8s-node01节点添加了disk-type=ssd 标签。

    当nodeSelector标签存在

    要运行的yaml文件

    [root@k8s-master scheduler]# pwd
    /root/k8s_practice/scheduler
    [root@k8s-master scheduler]# 
    [root@k8s-master scheduler]# cat scheduler_nodeSelector.yaml 
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: scheduler-nodeselector-deploy
      labels:
        app: nodeselector-deploy
    spec:
      replicas: 5
      selector:
        matchLabels:
          app: myapp
      template:
        metadata:
          labels:
            app: myapp
        spec:
          containers:
          - name: myapp-pod
            image: registry.cn-beijing.aliyuncs.com/google_registry/myapp:v1
            imagePullPolicy: IfNotPresent
            ports:
              - containerPort: 80
          # 指定节点标签选择,且标签存在
          nodeSelector:
            disk-type: ssd
    

    运行yaml文件并查看信息

    [root@k8s-master scheduler]# kubectl apply -f scheduler_nodeSelector.yaml 
    deployment.apps/scheduler-nodeselector-deploy created
    [root@k8s-master scheduler]# 
    [root@k8s-master scheduler]# kubectl get deploy -o wide
    NAME                            READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES                                                      SELECTOR
    scheduler-nodeselector-deploy   5/5     5            5           10s   myapp-pod    registry.cn-beijing.aliyuncs.com/google_registry/myapp:v1   app=myapp
    [root@k8s-master scheduler]# 
    [root@k8s-master scheduler]# kubectl get rs -o wide
    NAME                                       DESIRED   CURRENT   READY   AGE   CONTAINERS   IMAGES                                                      SELECTOR
    scheduler-nodeselector-deploy-79455db454   5         5         5       14s   myapp-pod    registry.cn-beijing.aliyuncs.com/google_registry/myapp:v1   app=myapp,pod-template-hash=79455db454
    [root@k8s-master scheduler]# 
    [root@k8s-master scheduler]# kubectl get pod -o wide
    NAME                                             READY   STATUS    RESTARTS   AGE   IP             NODE         NOMINATED NODE   READINESS GATES
    scheduler-nodeselector-deploy-79455db454-745ph   1/1     Running   0          19s   10.244.4.154   k8s-node01   <none>           <none>
    scheduler-nodeselector-deploy-79455db454-bmjvd   1/1     Running   0          19s   10.244.4.151   k8s-node01   <none>           <none>
    scheduler-nodeselector-deploy-79455db454-g5cg2   1/1     Running   0          19s   10.244.4.153   k8s-node01   <none>           <none>
    scheduler-nodeselector-deploy-79455db454-hw8jv   1/1     Running   0          19s   10.244.4.152   k8s-node01   <none>           <none>
    scheduler-nodeselector-deploy-79455db454-zrt8d   1/1     Running   0          19s   10.244.4.155   k8s-node01   <none>           <none>
    

    由上可见,所有pod都被调度到了k8s-node01节点。当然如果其他节点也有disk-type=ssd 标签,那么pod也会调度到这些节点上。

    当nodeSelector标签不存在

    要运行的yaml文件

    [root@k8s-master scheduler]# pwd
    /root/k8s_practice/scheduler
    [root@k8s-master scheduler]# 
    [root@k8s-master scheduler]# cat scheduler_nodeSelector_02.yaml 
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: scheduler-nodeselector-deploy
      labels:
        app: nodeselector-deploy
    spec:
      replicas: 5
      selector:
        matchLabels:
          app: myapp
      template:
        metadata:
          labels:
            app: myapp
        spec:
          containers:
          - name: myapp-pod
            image: registry.cn-beijing.aliyuncs.com/google_registry/myapp:v1
            imagePullPolicy: IfNotPresent
            ports:
              - containerPort: 80
          # 指定节点标签选择,且标签不存在
          nodeSelector:
            service-type: web
    

    运行yaml文件并查看信息

    [root@k8s-master scheduler]# kubectl apply -f scheduler_nodeSelector_02.yaml 
    deployment.apps/scheduler-nodeselector-deploy created
    [root@k8s-master scheduler]# 
    [root@k8s-master scheduler]# kubectl get deploy -o wide
    NAME                            READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES                                                      SELECTOR
    scheduler-nodeselector-deploy   0/5     5            0           26s   myapp-pod    registry.cn-beijing.aliyuncs.com/google_registry/myapp:v1   app=myapp
    [root@k8s-master scheduler]# 
    [root@k8s-master scheduler]# kubectl get rs -o wide
    NAME                                       DESIRED   CURRENT   READY   AGE   CONTAINERS   IMAGES                                                      SELECTOR
    scheduler-nodeselector-deploy-799d748db6   5         5         0       30s   myapp-pod    registry.cn-beijing.aliyuncs.com/google_registry/myapp:v1   app=myapp,pod-template-hash=799d748db6
    [root@k8s-master scheduler]# 
    [root@k8s-master scheduler]# kubectl get pod -o wide
    NAME                                             READY   STATUS    RESTARTS   AGE   IP       NODE     NOMINATED NODE   READINESS GATES
    scheduler-nodeselector-deploy-799d748db6-92mqj   0/1     Pending   0          40s   <none>   <none>   <none>           <none>
    scheduler-nodeselector-deploy-799d748db6-c2w25   0/1     Pending   0          40s   <none>   <none>   <none>           <none>
    scheduler-nodeselector-deploy-799d748db6-c8tlx   0/1     Pending   0          40s   <none>   <none>   <none>           <none>
    scheduler-nodeselector-deploy-799d748db6-tc5n7   0/1     Pending   0          40s   <none>   <none>   <none>           <none>
    scheduler-nodeselector-deploy-799d748db6-z8c57   0/1     Pending   0          40s   <none>   <none>   <none>           <none>
    

    由上可见,如果nodeSelector匹配的标签不存在,则容器将不会运行,一直处于Pending 状态。

    相关阅读

    1、官网:Pod分配调度

    2、Kubernetes K8S之调度器kube-scheduler详解

    3、Kubernetes K8S之affinity亲和性与反亲和性详解与示例

    4、Kubernetes K8S之Taints污点与Tolerations容忍详解

    完毕!


    ———END———
    如果觉得不错就关注下呗 (-^O^-) !

    在这里插入图片描述

    展开全文
  • nodename-6f8c4686f5-22dr7 0/1 Terminating 0 4m1s k8s-node1 test-nodename-6f8c4686f5-26548 0/1 Terminating 0 4m18s k8s-node1 test-nodename-6f8c4686f5-27wsv 0/1 Terminating 0 4m12s k8s-node1 test-...

    和前面学习的Affinity类似的,还可以直接在pod的声明中指定一个node去调度。这种方式简单粗暴,我们一起来学习看。

    我是T型人小付,一位坚持终身学习的互联网从业者。喜欢我的博客欢迎在csdn上关注我,如果有问题欢迎在底下的评论区交流,谢谢。

    实践操作

    固定节点因为比较简单粗暴,所以直接上操作。分为两类,一类是指定单个node,另一类是指定node的label。

    以下所有yaml文件托管在我的Github仓库

    单个node

    直接在pod.spec.nodeName字段声明node的名字即可。

    通过下面的yaml文件test-nodename.yaml来创建deployment

    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      name: test-nodename
    spec:
      replicas: 3
      template:
        metadata:
          labels:
            app: deployment-app
        spec:
          nodeName: k8s-node1  
          containers:
            - name: mynginx
              image: mynginx:v2
              ports:
                - containerPort: 80
    

    所有的pod都在node1

    [root@k8s-master nodename]# kubectl apply -f test-nodename.yaml
    deployment.extensions/test-nodename created
    [root@k8s-master nodename]# kubectl get pod -o wide
    NAME                             READY   STATUS    RESTARTS   AGE   IP             NODE        NOMINATED NODE   READINESS GATES
    test-nodename-6f8c4686f5-4vx9h   1/1     Running   0          5s    10.244.1.143   k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-59mq5   1/1     Running   0          5s    10.244.1.142   k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-rzs8c   1/1     Running   0          5s    10.244.1.141   k8s-node1   <none>           <none>
    

    即使扩容也是

    [root@k8s-master nodename]# kubectl scale --replicas=7 deployment/test-nodename
    deployment.extensions/test-nodename scaled
    [root@k8s-master nodename]# kubectl get pod -o wide
    NAME                             READY   STATUS    RESTARTS   AGE    IP             NODE        NOMINATED NODE   READINESS GATES
    test-nodename-6f8c4686f5-4vx9h   1/1     Running   0          115s   10.244.1.143   k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-59mq5   1/1     Running   0          115s   10.244.1.142   k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-82trn   1/1     Running   0          4s     10.244.1.145   k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-rzs8c   1/1     Running   0          115s   10.244.1.141   k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-sr6q5   1/1     Running   0          4s     10.244.1.146   k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-tvx7g   1/1     Running   0          4s     10.244.1.147   k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-z7lcf   1/1     Running   0          4s     10.244.1.144   k8s-node1   <none>           <none>
    

    测试一下如果对node1加上污点会是啥情况

    警告:下面的操作可能会很危险,谨慎尝试

    kubectl taint nodes k8s-node1 xiaofu=good:NoExecute
    

    之后这些pod因为污点而被销毁,然后又因为Deployment而被自动创建,然后又被销毁,于是满屏幕都是Terminating

    [root@k8s-master nodename]# kubectl get pod -o wide
    NAME                             READY   STATUS        RESTARTS   AGE     IP             NODE        NOMINATED NODE   READINESS GATES
    test-nodename-6f8c4686f5-22dr7   0/1     Terminating   0          4m1s    <none>         k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-26548   0/1     Terminating   0          4m18s   <none>         k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-27wsv   0/1     Terminating   0          4m12s   <none>         k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-28vpt   0/1     Terminating   0          4m13s   <none>         k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-29gpl   0/1     Terminating   0          4m28s   <none>         k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-29lnj   0/1     Terminating   0          4m21s   <none>         k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-2b5dc   0/1     Terminating   0          4m17s   <none>         k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-2fqw2   0/1     Terminating   0          4m20s   <none>         k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-2ksnn   0/1     Terminating   0          4m2s    <none>         k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-2r2gs   0/1     Terminating   0          4m20s   <none>         k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-2st4d   0/1     Terminating   0          4m19s   <none>         k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-2xdvr   0/1     Terminating   0          4m27s   <none>         k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-2xphz   0/1     Terminating   0          4m20s   <none>         k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-44tps   0/1     Terminating   0          4m15s   <none>         k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-4gbpp   0/1     Terminating   0          4m22s   <none>         k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-4gr6m   0/1     Terminating   0          4m17s   <none>         k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-4jb6w   0/1     Terminating   0          4m16s   <none>         k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-4lbms   0/1     Terminating   0          4m6s    <none>         k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-4m4fm   0/1     Terminating   0          4m25s   <none>         k8s-node1   <none>           <none>
    test-nodename-6f8c4686f5-4mcsk   0/1     Terminating   0          4m17s   <none>         k8s-node1   <none>           <none>
    ...
    ...
    

    赶紧去掉污点,删除deployment,等着几百个pod自己慢慢销毁吧。

    node标签选择器

    也可以在字段pod.spec.nodeSelector中指定node要满足的label。

    通过下面的yaml文件test-nodeselector.yaml创建deployment

    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      name: test-nodeselector
    spec:
      replicas: 3
      template:
        metadata:
          labels:
            app: deployment-app
        spec:
          nodeSelector:
            level: boss
          containers:
            - name: mynginx
              image: mynginx:v2
              ports:
                - containerPort: 80
    

    这里希望node有level:boss的标签,但是没有一个node有这个标签,于是所有pod处于pending状态

    [root@k8s-master nodename]# kubectl apply -f test-nodeselector.yaml
    deployment.extensions/test-nodeselector created
    [root@k8s-master nodename]# kubectl get pod -o wide
    NAME                               READY   STATUS    RESTARTS   AGE   IP       NODE     NOMINATED NODE   READINESS GATES
    test-nodeselector-b8fd4ccf-2sc6c   0/1     Pending   0          4s    <none>   <none>   <none>           <none>
    test-nodeselector-b8fd4ccf-8xjtl   0/1     Pending   0          4s    <none>   <none>   <none>           <none>
    test-nodeselector-b8fd4ccf-mcn8l   0/1     Pending   0          4s    <none>   <none>   <none>           <none>
    

    给node1打一个label之后成功被调度

    [root@k8s-master nodename]# kubectl label node k8s-node1 level=boss
    node/k8s-node1 labeled
    [root@k8s-master nodename]# kubectl get pod -o wide
    NAME                               READY   STATUS    RESTARTS   AGE   IP             NODE        NOMINATED NODE   READINESS GATES
    test-nodeselector-b8fd4ccf-2sc6c   1/1     Running   0          87s   10.244.1.175   k8s-node1   <none>           <none>
    test-nodeselector-b8fd4ccf-8xjtl   1/1     Running   0          87s   10.244.1.176   k8s-node1   <none>           <none>
    test-nodeselector-b8fd4ccf-mcn8l   1/1     Running   0          87s   10.244.1.174   k8s-node1   <none>           <none>
    

    删除label

    [root@k8s-master nodename]# kubectl label node k8s-node1 level-
    node/k8s-node1 labeled
    

    总结

    这样三种自定义调度pod的方式就都学习完了

    • Affinity/AntiAffinity
    • Taint/Toleration
    • Nodename/Nodeselector
    展开全文
  • 调度nodeName、nodeSelector、亲和性、污点、容忍、删除节点1、什么是调度?2、nodeName3、nodeSelector(1)节点亲和性(2)pod亲和与反亲和4、Taints(污点)(1)NoSchedule+标签选择(2)容忍1.NoSchedule2....

    1、什么是调度?

    调度器通过 kubernetes 的 watch 机制来发现集群中新创建且尚未被调度到 Node 上的 Pod。调度器会将发现的每一个未调度的 Pod 调度到一个合适的 Node 上来运行。

    kube-scheduler 是 Kubernetes 集群的默认调度器,并且是集群控制面的一部分。kube-scheduler 是很灵活的,在设计上是允许你自己写一个调度组件并替换原有的 kube-scheduler。

    在做调度决定时需要考虑的因素包括:单独和整体的资源请求、硬件/软件/策略限制、亲和以及反亲和要求、数据局域性、负载间的干扰等等。

    默认策略可以参考:https://kubernetes.io/docs/reference/scheduling/policies/

    2、nodeName

    nodeName 是节点选择约束的最简单方法,但一般不推荐。如果 nodeName 在 PodSpec 中指定了,则它优先于其他的节点选择方法。直接就指定在哪个节点调度。

    使用 nodeName 来选择节点的一些限制:
    (1)如果指定的节点不存在。
    (2)如果指定的节点没有资源来容纳 pod,则pod 调度失败。
    (3)云环境中的节点名称并非总是可预测或稳定的。

    编辑pod.yaml 文件

    apiVersion: v1
    kind: Pod
    metadata:
      name: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
          nodeName: server2 		%寻找node是server2的节点
    
    [root@server2 ~]# kubectl  apply  -f pod.yaml 	%应用,创建pod
    pod/nginx created
    [root@server2 ~]# kubectl  get pod
    NAME    READY   STATUS    RESTARTS   AGE
    nginx   1/1     Running   0          5s
    [root@server2 ~]# kubectl  get pod  -o wide	%调度到了server2(server2是master,一般不用它工作的,原因后面讲)
    NAME    READY   STATUS    RESTARTS   AGE     IP               NODE      NOMINATED NODE   READINESS GATES
    nginx   1/1     Running   0          19s     10.244.179.115   server2   <none>           <none>
    		%实验完成,删除pod
    

    3、nodeSelector

    nodeSelector 是节点选择约束的实用形式,它的原理是匹配某些特殊的标签,满足该条件的节点就可以被调度过去。

    创建目录
    在这里插入图片描述
    编辑pod.yaml文件

    apiVersion: v1
    kind: Pod
    metadata:
      name: nginx
      labels:
        env: test		%该pod的标签是env=test
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
      nodeSelector:		%选择标签disktype=ssd的node
        disktype: ssd
    

    在这里插入图片描述
    应用pod.yaml文件,创建pod,查看状态为pending,因为三个节点都没有ssd这个标签。
    在这里插入图片描述
    给server3加标签disktype=ssd,再次查看pod的状态,已经running了
    在这里插入图片描述
    删除标签后,查看pod的状态,还是running,这是因为,pod已经调度过去了,删除标签也不影响
    删除pod,净化环境
    在这里插入图片描述

    (1)节点亲和性

    nodeSelector 提供了一种非常简单的方法来将 pod 约束到具有特定标签的节点上。亲和与反亲和功能极大地扩展了你可以表达约束的类型。你可以发现规则是“软”/“偏好”,而不是硬性要求,因此,如果调度器无法满足该要求,仍然调度该 pod。
    节点亲和中的三个参数:
    (1)requiredDuringSchedulingIgnoredDuringExecution 必须满足
    (2)preferredDuringSchedulingIgnoredDuringExecution倾向满足
    (3)IgnoreDuringExecution 表示如果在Pod运行期间Node的标签发生变化,导致亲和性策略不能满足,则继续运行当前的Pod。
    nodeaffinity还支持多种规则匹配条件的配置如下:

    表示含义
    Inlabel 的值在列表内
    NotInlabel 的值不在列表内
    Gtlabel 的值大于设置的值,不支持Pod亲和性
    Ltlabel 的值小于设置的值,不支持pod亲和性
    Exists设置的label 存在
    DoesNotExist设置的 label 不存在

    参考:https://kubernetes.io/zh/docs/concepts/scheduling-eviction/assign-pod-node/

    编辑pod1.yaml

    apiVersion: v1
    kind: Pod
    metadata:
      name: node-affinity
    spec:
      containers:
      - name: nginx
        image: nginx
      affinity:
        nodeAffinity:				%node亲和性
          requiredDuringSchedulingIgnoredDuringExecution:	%必须满足该模块的条件
               nodeSelectorTerms:
               - matchExpressions:
                 - key: kubernetes.io/hostname
                   operator: In		%以下条件在列表内,才可调度
                   values:			%调度的节点必须是server3或server4
                   - server3
                   - server4
          preferredDuringSchedulingIgnoredDuringExecution:	%优先匹配满足该模块条件的节点,不满足也没事
          - weight: 1				%权重为1
            preference:
              matchExpressions:
              - key: disktype		%匹配条件是disktype这个键值为ssd
                operator: In
                values:
                - ssd  
    

    在这里插入图片描述
    应用,创建pod,由于现在server3和server4都没有ssd这个标签,且都满足硬性条件,所以随机调度到了server3
    在这里插入图片描述
    删除上个pod,给server4添加disktype=ssd这个标签,再次创建pod,查看,调度到了server4
    在这里插入图片描述
    查看详细信息也可以看到,该pod由于node的亲和性,调度到了server4
    在这里插入图片描述

    (2)pod亲和与反亲和

    除了上面的节点的亲和性,也可以使用 pod 的标签来约束,而不是使用节点本身的标签,来允许哪些 pod 可以或者不可以被放置在一起。

    pod 亲和性和反亲和性:
    (1)podAffinity 主要解决POD可以和哪些POD部署在同一个拓扑域中的问题(拓扑域用主机标签实现,可以是单个主机,也可以是多个主机组成的cluster、zone等。)即pod2想和某些特殊的pod1在同一个节点工作
    (2)podAntiAffinity主要解决POD不能和哪些POD部署在同一个拓扑域中的问题。它们处理的是Kubernetes集群内部POD和POD之间的关系。即pod2想避开某些特殊的pod1所在的那个节点

    Pod 间亲和与反亲和在与更高级别的集合(例如 ReplicaSets,StatefulSets,Deployments 等)一起使用时,它们可能更加有用。可以轻松配置一组应位于相同定义拓扑(例如,节点)中的工作负载。Pod 间亲和与反亲和需要大量的处理,这可能会显著减慢大规模集群中的调度。

    首先纯净实验环境
    在这里插入图片描述
    编辑 pod2.yaml 文件

    apiVersion: v1
    kind: Pod
    metadata:
      name: nginx
      labels:			%nginx这个pod的标签是app=nginx
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
    ---
    apiVersion: v1
    kind: Pod
    metadata:
      name: mysql
      labels:			%mysql这个pod的标签是app=mysql
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:5.7
        env:			%环境变量
         - name: "MYSQL_ROOT_PASSWORD"
           value: "westos"
      affinity:
        podAffinity:		%pod亲和性
          requiredDuringSchedulingIgnoredDuringExecution:	%必须满足以下条件
          - labelSelector:
              matchExpressions:
              - key: app			%标签app=nginx
                operator: In
                values:
                - nginx
            topologyKey: kubernetes.io/hostname
    
    

    在这里插入图片描述

    在这里插入图片描述
    应用pod2.yaml 文件,创建pod,查看两个pod,他们在同一个节点上,因为mysql专门匹配有nginx这个标签的pod,nginx去哪个节点,mysql就去哪个节点,生产环境中也确实有这种需要,nginx服务和mysql数据库要放在一起。
    在这里插入图片描述
    下面测试pode的反亲和。修改pod2.yaml 文件,由原来的pod亲和变为pod反亲和
    在这里插入图片描述
    应用pod2.yaml 文件,创建pod,可以看到,mysql和nginx专门不在同一个节点上
    在这里插入图片描述

    4、Taints(污点)

    NodeAffinity节点亲和性,是Pod上定义的一种属性,使Pod能够按我们的要求调度到某个Node上,而Taints则恰恰相反,它可以让Node拒绝运行Pod,甚至驱逐Pod。

    Taints(污点)是Node的一个属性,设置了Taints后,Kubernetes是不会将Pod调度到这个Node上的,于是Kubernetes就又给Pod设置了个属性Tolerations(容忍),只要Pod能够容忍Node上的污点,那么Kubernetes就会忽略Node上的污点,就能够(不是必须)把Pod调度过去。

    举个不太恰当的例子:假如一个人有犯罪前科(Taints)来应聘,我是饭店老板,那么我可能不喜欢他,甚至驱逐他,不让他在这工作等等,但是如果我比较大度(Tolerations),我不计较你的前科(Taints),那我就可以把你留在我这当服务生。

    可以使用命令 kubectl taint 给节点增加一个 taint:
    kubectl taint nodes node1 key=value:NoSchedule 创建
    kubectl describe nodes server1 |grep Taints 查询
    kubectl taint nodes node1 key:NoSchedule- 删除

    其中[effect] 可取值: [ NoSchedule | PreferNoSchedule | NoExecute ]

    参数含义
    NoSchedulePOD 不会被调度到标记为 taints 的节点
    PreferNoScheduleNoSchedule 的软策略版本(最好不要调度到标记为 taints 的节点)
    NoExecute该选项意味着一旦 Taint 生效,如该节点内正在运行的 POD 没有对应 Tolerate 设置,会直接被逐出

    注意上面的nodename调度方式无视污点,nodename的优先级最高,nodename说去哪里就去哪里

    (1)NoSchedule+标签选择

    前面说到server2是集群的master,默认不会work只会调度,原因就在与server2有污点,NoSchedule
    在这里插入图片描述
    编辑pod.yaml 文件

    apiVersion: v1
    kind: Pod
    metadata:
      name: nginx
      labels:
        env: test
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
      nodeSelector:
        roles: master		%匹配标签roles=master的节点
    

    在这里插入图片描述
    给server2添加roles=master标签,应用pod.yaml 文件,创建pod,查看pod的状态为pending。原因是创建pod时,要寻找标签是roles=master的节点,找到了server2,但是server2上有污点,NoSchedule,pod就无法调度到server2,那么pod只能等待。说明标签选择无法覆盖污点
    在这里插入图片描述
    显示调度失败
    在这里插入图片描述

    (2)容忍

    tolerations中定义的key、value、effect,要与node上设置的taint保持一致:
    (1)如果 operator 是 Exists ,value可以省略。
    (2)如果 operator 是 Equal ,则key与value之间的关系必须相等。
    (3)如果不指定operator属性,则默认值为Equal。
    还有两个特殊值:
    (1)当不指定key时,再配合Exists 就能匹配所有的key与value ,可以容忍所有污点。
    (2)当不指定effect时 ,则匹配所有的effect。

    1.NoSchedule

    修改pod.yaml 文件

    apiVersion: v1
    kind: Pod
    metadata:
      name: nginx
      labels:
        env: test
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
      nodeSelector:
        roles: master
      tolerations:			%容忍NoSchedule这个污点,即装作看不见NoSchedule这个污点
      - operator: "Exists"
        effect: "NoSchedule"
    

    在这里插入图片描述
    删除上个的pod,重新应用pod.yaml 文件,查看状态,running了
    在这里插入图片描述
    删除上个的pod,给server3也添加一个污点,NoSchedule。
    在这里插入图片描述

    修改pod.yaml 文件,注释掉匹配标签模块和容忍模块。
    在这里插入图片描述
    应用pod.yaml 文件,节点只能去server4,因为server2和server3都有污点
    在这里插入图片描述

    2.NoExecute

    NoExecute:该选项意味着一旦 Taint 生效,如该节点内正在运行的 POD 没有对应 Tolerate 设置,会直接被逐出。被驱逐到其他node节点。

    删除以前的pod
    在这里插入图片描述

    修改pod.yaml 文件

    apiVersion: v1
    kind: Pod
    metadata:
      name: nginx
      labels:
        env: test
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
      nodeSelector:
        disktype: ssd		%匹配标签disktype=ssd
      tolerations:
      - operator: "Exists"
        effect: "NoSchedule"	%容忍NoSchedule这个污点
    

    在这里插入图片描述
    查看标签,之前给server4添加了ssd这个标签。应用pod.yaml 文件,pod被调度到server4
    在这里插入图片描述
    给server4添加污点key=value:NoExecute,可以看到添加完成后,之前在server4上的pod立马被驱离了
    在这里插入图片描述
    当pod.yaml 文件改为

    apiVersion: v1
    kind: Pod
    metadata:
      name: nginx
      labels:
        env: test
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
      nodeSelector:
        disktype: ssd		%匹配标签disktype=ssd
      tolerations:
      - operator: "Exists"
        effect: "NoExecute"	%容忍NoExecute这个污点
    

    为Pod设置容忍后,应用pod.yaml 文件,server4又可以运行Pod了

    测试完成后,取消污点kubectl taint nodes server4 key:NoExecute-

    5、cordon、drain、delete

    影响Pod调度的指令还有:cordon、drain、delete,后期创建的pod都不会被调度到该节点上,但操作的暴力程度不一样,逐渐递增。

    (1)cordon隔离

    cordon 停止调度。影响最小,只会将node调为SchedulingDisabled,新创建pod,不会被调度到该节点,节点原有pod不受影响,仍正常对外提供服务。

    隔离server3后,状态为SchedulingDisabled,新的pod不会被调度到server3。
    取消隔离后,恢复正常
    在这里插入图片描述

    (2)drain驱逐

    drain 驱逐节点:
    首先驱逐node上的已有pod,在其他节点重新创建,然后将节点调为SchedulingDisabled。

    驱逐server3时,显示错误,是因为有daemonset这个控制器,他的特点就是每个节点上部署一个,和驱逐策略冲突,所以我们需要忽略daemonset产生的pod,把其他pod驱逐。查看状态会显示SchedulingDisabled。同时可以查看pod的数量锐减
    在这里插入图片描述

    kubectl uncordon server3		%恢复
    

    (3)delete删除

    delete 删除节点。最暴力的一个,首先驱逐node上的pod,在其他节点重新创建,然后,从master节点删除该node,master失去对其控制,

    kubectl delete node server3		%删除server3
    

    可以看到删除后,连接直接拒绝了
    在这里插入图片描述
    如要恢复调度,需进入node节点server3,重启kubelet服务,重新连接master

    [root@server3 ~]# systemctl restart kubelet	%基于node的自注册功能,恢复使用
    

    server3恢复正常
    在这里插入图片描述

    补充:上面讲了已经连接过的节点被删除后,如何恢复。下面讲解如何添加一个新的节点。
    我们第一想法是使用刚开始初始化后产生的token令牌添加新的节点,但是那个token只有24小时的有效期,所以需要重新建立token。如下图,建立token,查看,有效期确实为24小时。然后把这个新的token给准备添加的节点,加入集群。
    在这里插入图片描述

    展开全文
  • 固定节点调度有两种方式,一种是使用Pod.spec.nodeName节点名称去选择,或者使用节点的标签去选择。通过这两种方式将pod固定在节点上运行。 指定调度节点 I、Pod.spec.nodeName 将 Pod 直接调度到指定的 Node ...

    前面已经说了调度的亲和性,其实都比较含蓄,比如软硬亲和性,污点和容忍。

    固定节点就比较粗暴了,可以通过节点名称去选择,也可以通过节点的标签去选择,固定在某个节点上运行。这就是所谓固定节点的调度。

    固定节点调度有两种方式,一种是使用Pod.spec.nodeName节点名称去选择,或者使用节点的标签去选择。通过这两种方式将pod固定在节点上运行。

     

    Kubernetes Pod调度说明 


    简介

    Scheduler 是 Kubernetes 的调度器,主要任务是把定义的Pod分配到集群的节点上,听起来非常简单,但要考虑需要方面的问题:

    • 公平:如何保证每个节点都能被分配到资源

    • 资源高效利用:集群所有资源最大化被使用

    • 效率:调度性能要好,能够尽快的对大批量的Pod完成调度工作

    • 灵活:允许用户根据自己的需求控制调度的流程

    Scheduler 是作为单独的服务运行的,启动之后会一直监听API Server,获取 podSpec.NodeName为空的Pod,对每个Pod都会创建一个binding,表明该Pod应该放在哪个节点上。

     

    调度过程


    调度流程:

    1. 首先过滤掉不满足条件的节点,这个过程称为predicate
    2. 然后对通过的节点按照优先级的顺序,这个是priority
    3. 最后从中选择优先级最高的节点。如果中间有任何一步报错,则直接返回错误信息。(对于调度过程分为两部分,一部分是预选,一部分是优选)

    Predicate有一系列的算法可以使用:

    • PodFitsResources:节点上剩余的资源是否大于 Pod 请求的资源

    • PodFitsHost:如果Pod指定了nodeName,检查节点名称是否和nodeName匹配

    • PodFitsHostPort:节点上已经使用的port是否和Pod申请的port冲突

    • PodSelectorMatches:过滤和Pod指定的 label 不匹配的节点

    • NoDiskConflict:已经 mount 的 volume 和 Pod 指定的volume不冲突,除非他们都是只读

    如果在predicate过程中没有适合的节点,Pod会一直处于Pending状态,不断重新调度,直到有节点满足条件,经过这个步骤,如果多个节点满足条件,就会进入priority过程:按照优先级大小对节点排序,优先级由一系列键值对组成,键是该优先级的名称,值是它的权重,这些优先级选项包括:

    • LeastRequestedPriority:通过计算CPU和Memory的使用率来决定权重,使用率越低权重越高,换句话说,这个优先级倾向于资源使用率低的节点

    • BalanceResourceAllocation:节点上CPU和Memory使用率非常及接近,权重就越高,这个要和上边的一起使用,不可单独使用

    • ImageLocalityPriority:倾向于已经要使用镜像的节点,镜像的总大小值越大,权重越高

    通过算法对所有的优先级项目和权重进行计算,得出最终的结果

    自定义调度器

    除了Kubernetes自带的调度器,也可以编写自己的调度器,通过spec.schedulername参数指定调度器的名字,可以为Pod选择某个调度器进行调度,比如下边的Pod选择my-scheduler进行调度,而不是默认的default-scheduler。

    apiVersion: v1
    kind: Pod
    metadata:
      name: scheduler-test
      labels:
        name: example-scheduler
    spec:
      schedulername: my-scheduler
      containers:
      - name: Pod-test
        image: nginx:v1

     

    指定调度节点 


    I、Pod.spec.nodeName 将 Pod 直接调度到指定的 Node 节点上,会跳过 Scheduler 的调度策略,该匹配规则是强制匹配

    [root@k8s-master ~]# cat test1.yml 
    apiVersion: apps/v1
    kind: Deployment
    metadata:  
      name: myapp
      namespace: default
      labels:
        app: busybox
    spec:  
      replicas: 8
      selector:
        matchLabels:
          app: busybox
      template:   
         metadata:      
           labels:        
             app: busybox    
         spec:
           nodeName: k8s-node1    
           containers:      
           - name: buxybox        
             image: busybox   
             ports:
             - containerPort: 22
             command: ["/bin/sh","-c","sleep 3600"]
    
    
    [root@k8s-master ~]# kubectl get pod -o wide
    NAME                     READY   STATUS    RESTARTS   AGE     IP            NODE         NOMINATED NODE   READINESS GATES
    myapp-544cb6f798-5fjdh   1/1     Running   0          88s     10.244.1.9    k8s-node1    <none>           <none>
    myapp-544cb6f798-7wfjz   1/1     Running   0          88s     10.244.1.10   k8s-node1    <none>           <none>
    myapp-544cb6f798-chlxz   1/1     Running   0          88s     10.244.1.13   k8s-node1    <none>           <none>
    myapp-544cb6f798-cl8x8   1/1     Running   0          7m12s   10.244.1.7    k8s-node1    <none>           <none>
    myapp-544cb6f798-gdqbg   1/1     Running   0          88s     10.244.1.12   k8s-node1    <none>           <none>
    myapp-544cb6f798-q54fk   1/1     Running   0          88s     10.244.1.8    k8s-node1    <none>           <none>
    myapp-544cb6f798-tdhxz   1/1     Running   0          88s     10.244.1.11   k8s-node1    <none>           <none>
    myapp-544cb6f798-tq448   1/1     Running   0          7m12s   10.244.1.6    k8s-node1    <none>           <none>

    可以看到全部在node1上面,公平调度没有发挥作用,不经过调度器,即使节点上有污点也忽略,因为不经过调度器。

    前面亲和性,nodeselector,污点都是经过调度器。之前配置相关调度的属性它都不起作用了,如果调度器出现故障,希望pod可以快速部署到某个节点,可以使用nodename。

     

    nodeSelector


    II、Pod.spec.nodeSelector:通过 kubernetes 的 label-selector 机制选择节点,由调度器调度策略匹配 label,而后调度 Pod 到目标节点,该匹配规则属于强制约束

    nodeSelector:用于将Pod调度到匹配Label的Node上,如果没有匹配的标签会调度失败。

    作用:

    • 约束Pod到特定的节点运行

    • 完全匹配节点标签

    应用场景:

    • 专用节点:根据业务线将Node分组管理

    • 配备特殊硬件:部分Node配有SSD硬盘、GPU

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

    Kubernetes 是通过 label 来实现这个功能的。

    label 是 key-value 对,各种资源都可以设置 label,灵活添加各种自定义属性。比如执行如下命令标注 k8s-node2 是配置了 SSD 的节点。

    [root@k8s-master ~]# kubectl label node k8s-node2 disktype=ssd
    node/k8s-node2 labeled

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

    [root@k8s-master ~]# kubectl get node --show-labels
    NAME         STATUS   ROLES    AGE   VERSION   LABELS
    k8s-master   Ready    <none>   51d   v1.18.3   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-master,kubernetes.io/os=linux
    k8s-node1    Ready    <none>   50d   v1.18.3   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node1,kubernetes.io/os=linux
    k8s-node2    Ready    <none>   50d   v1.18.3   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,disktype=ssd,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node2,kubernetes.io/os=linux

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

    有了 disktype 这个自定义 label,接下来就可以指定将 Pod 部署到 k8s-node2。编辑 nginx.yml:

    [root@k8s-master ~]# cat test2.yml 
    apiVersion: apps/v1
    kind: Deployment
    metadata:  
      name: myapp
      namespace: default
      labels:
        app: nginx
    spec:  
      replicas: 8
      selector:
        matchLabels:
          app: myapp
      template:   
         metadata:      
           labels:        
             app: myapp    
         spec:
           nodeSelector:
             disktype: ssd
           containers:      
           - name: nginx        
             image: nginx   
             ports:
             - containerPort: 80
    
    [root@k8s-master ~]# kubectl apply -f test2.yml 
    deployment.apps/myapp created

    在 Pod 模板的 spec 里通过 nodeSelector 指定将此 Pod 部署到具有 label disktype=ssd 的 Node 上。

    部署 Deployment 并查看 Pod 的运行节点:

    [root@k8s-master ~]# kubectl get pod -o wide
    NAME                     READY   STATUS    RESTARTS   AGE     IP            NODE         NOMINATED NODE   READINESS GATES
    myapp-9bf5d74f5-4jlhr    1/1     Running   0          112s    10.244.2.12   k8s-node2    <none>           <none>
    myapp-9bf5d74f5-5b94h    1/1     Running   0          2m39s   10.244.2.9    k8s-node2    <none>           <none>
    myapp-9bf5d74f5-6wvrv    1/1     Running   0          3m      10.244.2.5    k8s-node2    <none>           <none>
    myapp-9bf5d74f5-7tbpk    1/1     Running   0          3m      10.244.2.6    k8s-node2    <none>           <none>
    myapp-9bf5d74f5-l5h9w    1/1     Running   0          3m      10.244.2.7    k8s-node2    <none>           <none>
    myapp-9bf5d74f5-n8zs8    1/1     Running   0          2m23s   10.244.2.10   k8s-node2    <none>           <none>
    myapp-9bf5d74f5-sf8j6    1/1     Running   0          3m      10.244.2.8    k8s-node2    <none>           <none>
    myapp-9bf5d74f5-vs4v6    1/1     Running   0          2m8s    10.244.2.11   k8s-node2    <none>           <none>

    全部 8个副本都运行在 k8s-node2上,符合我们的预期。

    要删除 label disktype,执行如下命令:

    [root@k8s-master ~]# kubectl label node  k8s-node2 disktype-
    node/k8s-node2 labeled
    [root@k8s-master ~]# kubectl get  node  k8s-node2 --show-labels
    NAME        STATUS   ROLES    AGE   VERSION   LABELS
    k8s-node2   Ready    <none>   51d   v1.18.3   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node2,kubernetes.io/os=linux

    - 即删除。

    [root@k8s-master ~]# kubectl get pod -o wide
    NAME                     READY   STATUS    RESTARTS   AGE     IP            NODE         NOMINATED NODE   READINESS GATES
    myapp-9bf5d74f5-4jlhr    1/1     Running   0          5m23s   10.244.2.12   k8s-node2    <none>           <none>
    myapp-9bf5d74f5-5b94h    1/1     Running   0          6m10s   10.244.2.9    k8s-node2    <none>           <none>
    myapp-9bf5d74f5-6wvrv    1/1     Running   0          6m31s   10.244.2.5    k8s-node2    <none>           <none>
    myapp-9bf5d74f5-7tbpk    1/1     Running   0          6m31s   10.244.2.6    k8s-node2    <none>           <none>
    myapp-9bf5d74f5-l5h9w    1/1     Running   0          6m31s   10.244.2.7    k8s-node2    <none>           <none>
    myapp-9bf5d74f5-n8zs8    1/1     Running   0          5m54s   10.244.2.10   k8s-node2    <none>           <none>
    myapp-9bf5d74f5-sf8j6    1/1     Running   0          6m31s   10.244.2.8    k8s-node2    <none>           <none>
    myapp-9bf5d74f5-vs4v6    1/1     Running   0          5m39s   10.244.2.11   k8s-node2    <none>           <none>

    不过此时 Pod 并不会重新部署,依然在 k8s-node2 上运行。除非在 nginx.yml 中删除 nodeSelector 设置,然后通过 kubectl apply 重新部署。Kubernetes 会删除之前的 Pod 并调度和运行新的 Pod。

    如果多个节点都有该标签会选择一个最合适的,因为这几个节点都可以匹配,根据其调度算法选择最合适的匹配。如果没有集群当中没有该标签,那么就无法调度,会一直处于pending。

    [root@k8s-master ~]# cat pod-nodeselector.yml 
    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-nodeselector2
    spec:
      nodeSelector:
        gpu: "nvidia"
      containers:
      - name: web
        image: nginx
    
    
    Events:
      Type     Reason            Age   From  Message
      ----     ------            ----  ----  -------
      Warning  FailedScheduling  36s         0/3 nodes are available: 3 node(s) didn't match node selector.
      Warning  FailedScheduling  36s         0/3 nodes are available: 3 node(s) didn't match node selector.

     

    展开全文
  • easyui- nodeName

    2019-04-10 10:54:36
    Uncaught TypeError: Cannot read property ‘nodeName’ of undefined 问题 html: 日期:<input type="text" name="time1" id="time1" class="easyui-datetimebox" Style="width: 120px; margin-top: 25px" />...
  • K8S之nodeName

    2021-04-12 16:47:01
    一、概念 指定节点名称,将Pod调度到指定的Node上,不经过调度器,不受Taint的限制 二、使用 spec: nodeName: k8s-node1 containers: - name: nginx image: nginx
  • 元素节点的 nodeName 是标签名称 属性节点的 nodeName 是属性名称 文本节点的 nodeName 永远是 #text 文档节点的 nodeName 永远是 #document 注释:nodeName 所包含的 XML 元素的标签名称永远是大写的 (二)...
  • DOM之nodeName与nodevalue

    2019-08-24 15:12:27
    console.log(document.doctype.nodeName + "/" + document.doctype.nodeValue); //文档片段节点 var frag = document.createDocumentFragment(); console.log(frag.nodeName + "/" + frag.nodeValue); ...
  • 2. nodeName:返回当前节点的名称 console.log(ele.nodeName); console.log(att.nodeName); console.log(txt.nodeName); 3. nodeValue:返回或者当前节点的值 console.log(ele.nodeValue); console.log(att....
  • 下面小编就为大家带来一篇浅谈JS之tagNaem和nodeName。小编觉得挺不错的,现在就分享给大家,也给大家做个参考。一起跟随小编过来看看吧
  • 使用节点的nodeName和nodeValue属性可以读取节点的名称和值。这两个属性完全取决于节点的类型,具体如下表: 节点的nodeName和nodeValue属性说明: 节点类型 nodeaName返回值 nodeValue返回值 Document #...
  • 在启动 tensorboard时候遇到 socket.gaierror: [Errno 8] nodename nor servname provided, or not known 问题 办法 增加ip配置即可 lixiang@lixiangdeMacBook-Pro-4 checkpoint % python3 -m tensorboard.main --...
  • nodeName

    千次阅读 2010-11-02 16:46:00
    1,nodeName属性 : 节点的名字。 如果节点是元素节点,那么返回这个元素的名字。此时,相当于tagName属性。 比如: <p>aaaa : 则返回 p ; 如果是属性节点,nodeName将返回这个...
  • 为了验证这种情况,可以用nodeName 属性来增加一项测试: if (placeholder.nodeName != "IMG") return false; 请注意,nodeName 属性总是返回一个大写字母的值,即使元素在 HTML文档里是小写字母。 参考目录 ...
  • kubernetes调度之nodeName与NodeSelector

    千次阅读 2020-01-03 15:42:05
    Kubernetes的调度有简单,有复杂,指定NodeName和使用NodeSelector调度是最简单的,可以将Pod调度到期望的节点上。 本文主要介绍kubernetes调度框架中的NodeName和NodeSelector。 NodeName Pod.spec.nodeName用于...
  • nodeName、nodeValue 以及 nodeType 包含有关于节点的信息...元素节点的 nodeName 是标签名称属性节点的 nodeName 是属性名称文本节点的 nodeName 永远是 #text文档节点的 nodeName 永远是 #document 注释:node...
  • 文章目录k8s----pods调度约束一:kubernetes 创建Pod 的 工作流1.1:调度方式1.2:nodeName方式1.3:nodeSelector方式1.4:常见错误状态的问题 我们知道Pod是Kubernetes中最小的调度单元,平时我们操作Pod的时间也是...
  • 翻译结果: 未捕获的TypeError:无法读取未定义的属性“nodeName” 我的是选择器里面的值写错了,找不到相应的元素
  • Uncaught TypeError: Cannot read property ‘nodeName’ of undefined 恶心的错误花了3个小时找问题,结果 使用easyui datagrid,可编辑表格,错误提示: Uncaught TypeError: Cannot read property ‘nodeName’ of...
  • sqlalchemy.exc.OperationalError: (pymysql.err.OperationalError) (2003, 'Can\'t connect to MySQL server on \'"rm-bp1jcmm1ly09ef034zm.mysql.rds.aliyuncs.com"\' ([Errno 8] nodename nor servname provided,...
  • 目录一、kubernetes调度简介二、nodeName三、nodeSelector1.节点亲和2.pod亲和与反亲和四、Taints(污点)五、设定tolerations容忍标签 一、kubernetes调度简介 1、调度器通过 kubernetes 的 watch 机制来发现集群中新...
  • kubernetes Scheduler 调度器 Scheduler定义 Scheduler调度过程 Ⅰ、predicate 预选算法: Ⅱ、priorities 优选选项: Ⅲ、自定义调度器 固定节点调度 NodeName NodeSelector 节点标签固定调度 Pod 节点扩容 ...
  • nodeName与tagName的区别

    千次阅读 2018-03-22 16:54:18
    原文链接: 详情链接 DOM里面一共有12种节点类型,常见的3种节点...总结:tagName只能用在元素节点上,而nodeName可以用在任何节点上,可以说nodeName涵盖了tagName,并且具有更多的功能,因此建议总是使用nodeName
  • 问题描述:在MAC OS 上用jupyter运行spark时,出现错误 sc is not defined,很奇怪这玩意还要defined 吗,后来根据其他blog的描述下载了 findspark ,查出了错误 gaierror: [Errno 8] nodename nor servname ...
  • 原因是hostname 没有写在/etc/hosts里。有些代码里面可能需要根据主机名称来去本地的DNS里找对应的IP地址,由于本地的DNS配置中没有指定主机名这个IP地址是什么,也就会提示这个错误了。 在命令行输入使用python ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 58,765
精华内容 23,506
关键字:

nodename