Kubernetes Pod调度说明

简介

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

  • 公平：如何保证每个节点都能被分配到资源
  • 资源高效利用：集群所有资源最大化被使用
  • 效率：调度性能要好，能够尽快的对大批量的Pod完成调度工作
  • 灵活：允许用户根据自己的需求控制调度的流程

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

调度过程

调度流程：首先过滤掉不满足条件的节点，这个过程称为predicate；然后对通过的节点按照优先级的顺序，这个是priority；最后从中选择优先级最高的节点。如果中间有任何一步报错，则直接返回错误信息。

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

一、亲和性

注意，以下所有的测试都是1Master、1Node的情况下：

[root@Centos8 scheduler]# kubectl get node

NAME          STATUS   ROLES    AGE    VERSION

centos8       Ready    master   134d   v1.15.1

testcentos7   Ready    <none>   133d   v1.15.1

1、节点亲和性

pod.spec.affinity.nodeAffinity

  • preferredDuringSchedulingIgnoredDuringExecution：软策略

    • 软策略是偏向于，更想(不)落在某个节点上，但如果实在没有，落在其他节点也可以
  • requiredDuringSchedulingIgnoredDuringExecution：硬策略
    • 硬策略是必须(不)落在指定的节点上，如果不符合条件，则一直处于Pending状态
requiredDuringSchedulingIgnoredDuringExecution硬策略

vim node-affinity-required.yaml

apiVersion: v1

kind: Pod

metadata:

  name: affinity-required

  labels:

      app: node-affinity-pod

spec:

  containers:

  - name: with-node-required

    image: nginx:1.2.1

    imagePullPolicy: IfNotPresent

  affinity:

    nodeAffinity:

      requiredDuringSchedulingIgnoredDuringExecution:

        nodeSelectorTerms:

        - matchExpressions:

          - key: kubernetes.io/hostname    #节点名称

            operator: NotIn        #不是

            values:

            - testcentos7          #node节点
[root@Centos8 ~]# kubectl get node --show-labels    #查看node节点标签

NAME          STATUS   ROLES    AGE    VERSION   LABELS

centos8       Ready    master   133d   v1.15.1   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=centos8,kubernetes.io/os=linux,node-role.kubernetes.io/master=

testcentos7   Ready    <none>   133d   v1.15.1   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=testcentos7,kubernetes.io/os=linux

## 目前只有两个节点，一个master 一个node，策略中表示此Pod不在testcentos7这个节点上

## Pod创建之后，因为除去testcentos7节点已再无其他node，所以一直处于Pending状态


[root@Centos8 scheduler]# kubectl create -f node-affinity-required.yaml

pod/affinity-required created

[root@Centos8 scheduler]# kubectl get pod

NAME                READY   STATUS    RESTARTS   AGE

affinity-required   /     Pending             4s

[root@Centos8 scheduler]# kubectl describe pod affinity-required

default-scheduler  / nodes are available:  node(s) didn't match node selector, 1 node(s) had taints that the pod didn't tolerate.

将yaml文件中，NotIn改为In

affinity:

    nodeAffinity:

      requiredDuringSchedulingIgnoredDuringExecution:

        nodeSelectorTerms:

        - matchExpressions:

          - key: kubernetes.io/hostname    #节点名称

            operator: In        #是，存在

            values:

            - testcentos7            #node节点

再次创建，已经落在指定node节点中

[root@Centos8 scheduler]# kubectl get pod -o wide

NAME                READY   STATUS    RESTARTS   AGE   IP             NODE

affinity-required   /     Running             11s  10.244.3.219  testcentos7
preferredDuringSchedulingIgnoredDuringExecution软策略

vim node-affinity-preferred.yaml

apiVersion: v1

kind: Pod

metadata:

  name: affinity-preferred

  labels:

    app: node-affinity-pod

spec:

  containers:

  - name: with-node-preferred

    image: nginx:1.2.

    imagePullPolicy: IfNotPresent

  affinity:

    nodeAffinity:

      preferredDuringSchedulingIgnoredDuringExecution:

      - weight:     #权重为1,软策略中权重越高匹配到的机会越大

        preference:  #更偏向于

          matchExpressions:

          - key: kubernetes.io/hostname #node名称

            operator: In  #等于，为

            values:

            - testcentos7   #node真实名称
## 更想落在node节点名称为testcentos7的node中

[root@Centos8 scheduler]# kubectl create -f node-affinity-prefered.yaml

pod/affinity-prefered created

[root@Centos8 scheduler]# kubectl get pod -o wide

NAME                READY   STATUS    RESTARTS   AGE   IP             NODE

affinity-prefered   /     Running             9s    10.244.3.220 testcentos7

更改一下策略，将node节点名称随便更改为不存在的node名称，例如kube-node2

affinity:

    nodeAffinity:

      preferredDuringSchedulingIgnoredDuringExecution:

      - weight:     #权重为1,软策略中权重越高匹配到的机会越大

        preference:  #更偏向于

          matchExpressions:

          - key: kubernetes.io/hostname #node名称

            operator: In  #等于，为

            values:

            - kube-node2   #node真实名称
[root@Centos8 scheduler]# kubectl create -f node-affinity-prefered.yaml

pod/affinity-prefered created

##创建后，同样是落在了testcentos7节点上，虽然它更想落在kube-node2节点上，但没有，只好落在testcentos7节点中

[root@Centos8 scheduler]# kubectl get pod -o wide

NAME                READY   STATUS    RESTARTS   AGE   IP             NODE

affinity-prefered   /     Running             17s   10.244.3.221 testcentos7
软硬策略合体

vim node-affinity-common.yaml

apiVersion: v1

kind: Pod

metadata:

  name: affinity-node

  labels:

    app: node-affinity-pod

spec:

  containers:

  - name: with-affinity-node

    image: nginx:v1

    imagePullPulicy: IfNotPresent

  affinity:

    nodeAffinity:

      requiredDuringSchedulingIgnoredDuringExecution:

        nodeSelectorTerms:

        - matchExpressions:

          - key: kubernetes.io/hostname

            operator: NotIn

            values:

            - k8s-node2

      preferredDuringSchedulingIgnoredDuringExecution:

      - weight:

        preference:

        matchExpressions:

        - key: source

          operator: In

          values:

           - hello

软硬结合达到一个更为准确的node选择，以上文件意思为此Pod必须不存在k8s-node2节点中，其他的节点都可以，但最好落在label中source的值为hello的节点中

键值运算关系
  • In：label 的值在某个列表里
  • NotIn：label 的值不在某个列表中
  • Gt：label 的值大于某个值
  • Lt：label 的值小于某个值
  • Exists：某个 label 存在
  • DoesNotExist：某个 label 不存在

如果nodeSelectorTerms下面有多个选项，满足任何一个条件就可以了；如果matchExpressions有多个选项，则必须满足这些条件才能正常调度

2、Pod亲和性

pod.spec.affinity.podAffinity/podAntiAffinity

  • preferedDuringSchedulingIgnoredDuringExecution：软策略

    • 软策略是偏向于，更想(不)落在某个节点上，但如果实在没有，落在其他节点也可以
  • requiredDuringSchedulingIgnoredDuringExecution：硬策略
    • 硬策略是必须(不)落在指定的节点上，如果不符合条件，则一直处于Pending状态
先创建一个测试Pod

vim pod.yaml

apiVersion: v1

kind: Pod

metadata:

  name: pod-

  labels:

    app: nginx

    type: web

spec:

  containers:

  - name: pod-

    image: nginx:1.2.

    imagePullPolicy: IfNotPresent

    ports:

    - name: web

      containerPort: 
[root@Centos8 scheduler]# kubectl create -f pod.yaml

pod/pod- created

[root@Centos8 scheduler]# kubectl get pod --show-labels

NAME    READY   STATUS    RESTARTS   AGE   LABELS

pod-   /     Running             4s    app=nginx,type=web
requiredDuringSchedulingIgnoredDuringExecution Pod硬策略

vim pod-affinity-required.yaml

apiVersion: v1

kind: Pod

metadata:

  name: affinity-required

  labels:

    app: pod-

spec:

  containers:

  - name: with-pod-required

    image: nginx:1.2.

    imagePullPolicy: IfNotPresent

  affinity:

    podAffinity:   #在同一域下

      requiredDuringSchedulingIgnoredDuringExecution:

      - labelSelector:

          matchExpressions:

          - key: app    #标签key

            operator: In

            values:

            - nginx     #标签value

        topologyKey: kubernetes.io/hostname #域的标准为node节点的名称

以上文件策略为：此必须要和有label种app：nginx的pod在同一node下

创建测试:
[root@Centos8 scheduler]# kubectl create -f pod-affinity-required.yaml

pod/affinity-required created

[root@Centos8 scheduler]# kubectl get pod -o wide

NAME                READY   STATUS    RESTARTS   AGE   IP             NODE

affinity-required   /     Running             43s   10.244.3.224 testcentos7

pod-               /     Running             10m   10.244.3.223 testcentos7

# 和此标签Pod在同一node节点下

将podAffinity改为podAnitAffinity，使它们不在用于node节点下

apiVersion: v1

kind: Pod

metadata:

  name: required-pod2

  labels:

    app: pod-

spec:

  containers:

  - name: with-pod-required

    image: nginx:1.2.

    imagePullPolicy: IfNotPresent

  affinity:

    podAntiAffinity:

      requiredDuringSchedulingIgnoredDuringExecution:

      - labelSelector:

          matchExpressions:

          - key: app    #标签key

            operator: In

            values:

            - nginx     #标签value

        topologyKey: kubernetes.io/hostname #域的标准为node节点的名称

此策略表示，必须要和label为app:nginx的pod在不用的node节点上

创建测试：
[root@Centos8 scheduler]# kubectl create -f pod-affinity-required.yaml

pod/required-pod2 created

[root@Centos8 scheduler]# kubectl get pod

NAME                READY   STATUS    RESTARTS   AGE

affinity-required   /     Running             9m40s

pod-               /     Running             19m

required-pod2       /     Pending             51s

## 由于我这里只有一个节点，所以required-pod2只能处于Pending状态
preferedDuringSchedulingIgnoredDuringExecution Pod软策略
vim pod-affinity-prefered.yaml

...

apiVersion: v1

kind: Pod

metadata:

  name: affinity-prefered

  labels:

    app: pod-

spec:

  containers:

  - name: with-pod-prefered

    image: nginx:v1

    imagePullPolicy: IfNotPresent

  affinity:

    podAntiAffinity:    #不在同一个域下

      preferedDuringSchedulingIgnoredDuringExecution:

      - weight:

        podAffinityTerm:

          labelSelector:

            matchExpressions:

            - key: app

              operator: In

              values:

              - pod-

          topologyKey: kubernetes.io/hostname

...

软策略和硬策略的方法基本类似，只是添加了权重，表示更喜欢而已，也可以接受其他，在此就不再演示

亲和性/反亲和性调度策略比较如下：
调度策略 匹配标签 操作符 拓扑域支持 调度目标
nodeAffinity 主机 In,NotIn,Exists,DoesNotExists,Gt,Lt 否 指定主机
podAffinity Pod In,NotIn,Exists,DoesNotExists,Gt,Lt 是 pod与指定pod在一拓扑域
podAnitAffinity Pod In,NotIn,Exists,DoesNotExists,Gt,Lt 是 pod与指定pod不在一拓扑域

二、污点(Taint)和容忍(Toleration)

节点亲和性，是Pod的一种属性（偏好或硬性要求），它使Pod被吸引到一类特定的节点，Taint则相反，它使节点能够 排斥 一类特定的Pod

Taint与Toleration相互配合，可以用来避免Pod被分配到不合适的节点上，每个节点上都可以应用一个或两个taint，这表示对那些不能容忍这些taint和pod，是不会被该节点接受的，如果将toleration应用于pod上，则表示这些pod可以（但不要求）被调度到具有匹配taint的节点上

注意，以下所有的测试都是1Master、1Node的情况下：

[root@Centos8 scheduler]# kubectl get node

NAME          STATUS   ROLES    AGE    VERSION

centos8       Ready    master   134d   v1.15.1

testcentos7   Ready    <none>   133d   v1.15.1

1、污点（Taint）

（1）污点的组成

使用kubectl taint 命令可以给某个node节点设置污点，Node被设置上污点之后就和Pod之间存在了一种相斥的关系，可以让Node拒绝Pod的调度执行，甚至将已经存在得Pod驱逐出去

每个污点的组成如下：

key=value:effect

每个污点有一个 key 和 value 作为污点标签，其中 value 可以为空，effect描述污点的作用，当前 taint effect 支持如下三个选项：

  • NoSchedule：表示 k8s 不会将Pod调度到具有该污点的Node上
  • PreferNoSchedule：表示 k8s 将尽量避免将Pod调度到具有该污点的Node上
  • NoExecute：表示 k8s 将不会将Pod调度到具有该污点的Node上，同时会将Node上已有的Pod驱逐出去
（2）污点的设置、查看和去除

k8s的master节点本身就带有污点，这也是为什么k8s在调度Pod时，不会调度到master节点的原因，具体查看如下：

[root@Centos8 scheduler]# kubectl describe node centos8

Taints:             node-role.kubernetes.io/master:NoSchedule

## 设置污点

kubectl taint nodes [node name] key1=value:NoSchedule

## 节点说明中，查看Taint字段

kubectl describe node [node name]

## 去除污点

kubectl taint nodes [node name] key1:NoSchedule-

测试效果：

## 查看当前节点所拥有Pod，都在testcentos7中

[root@Centos8 scheduler]# kubectl get pod -o wide

NAME                READY   STATUS    RESTARTS   AGE   IP             NODE

affinity-required   /     Running             68m   10.244.3.224 testcentos7

pod-               /     Running             78m   10.244.3.223 testcentos7

required-pod2       /     Pending             59m   <none>         <none>   

## 给testcentos7设置NoExecute污点

[root@Centos8 scheduler]# kubectl taint nodes testcentos7 check=vfan:NoExecute

node/testcentos7 tainted

## 查看Pod有没被驱逐出去

[root@Centos8 scheduler]# kubectl get pod

NAME            READY   STATUS    RESTARTS   AGE

required-pod2   /     Pending             62m

## 只剩一个Pending状态的Pod，因为他还没创建，所以还未分配Node

查看 testcentos7 节点信息

[root@Centos8 scheduler]# kubectl describe node  testcentos7

Taints:             check=vfan:NoExecute

目前所有的节点都被打上了污点，新建Pod测试下效果：

[root@Centos8 scheduler]# kubectl create -f pod.yaml

pod/pod- created

[root@Centos8 scheduler]# kubectl get pod

NAME            READY   STATUS    RESTARTS   AGE

pod-           /     Pending             4s

required-pod2   /     Pending             7h18m

新建的Pod会一直处于Pending状态，因为没有可用的Node节点，这时候就可以使用容忍(Toleration)了

2、容忍(Toleration)

设置了污点的Node将根据 taint 的 effect:NoSchedule、PreferNoSchedule、NoExecute和Pod之间产生互斥的关系，Pod将在一定程度上不会被调度到 Node 上。但我们可以在 Pod 上设置容忍(Toleration)，意思是设置了容忍的 Pod 将可以容忍污点的存在，可以被调度到存在污点的Node上

Pod.spec.tolerations

tolerations:

- key: "key1"

  operator: "Equal"

  value: "value1"

  effect: "NoSchedule"

  tolerationSeconds:

- key: "key1"

  operator: "Equal"

  value: "value1"

  effect: "NoExecute"

- key: "key2"

  operator: "Exists"

  effect: "NoSchedule"
  • 其中 key、value、effect 要与Node中的 taint 保持一致
  • operator 的值为 Exists 将会忽略 value 的值
  • tolerationSeconds 用于描述当Pod需要驱逐时可以在Node上继续保留运行的时间

（1）当不指定key时，表示容忍所有污点的key：

tolerations：

- operator: "Exists"

例如：

vim pod3.yaml

apiVersion: v1

kind: Pod

metadata:

  name: pod-

  labels:

    app: nginx

    type: web

spec:

  containers:

  - name: pod-

    image: nginx:1.2.

    imagePullPolicy: IfNotPresent

    ports:

    - name: web

      containerPort:

  tolerations:

  - operator: "Exists"

    effect: "NoSchedule"
[root@Centos8 scheduler]# kubectl create -f pod3.yaml

pod/pod- created

[root@Centos8 scheduler]# kubectl get pod -o wide

NAME    READY   STATUS    RESTARTS   AGE   IP             NODE          NOMINATED NODE   READINESS GATES

pod-   /     Pending             14m   <none>         <none>

pod-   /     Running             11m   10.244.3.229   testcentos7

pod-   /     Running             9s    10.244.0.107   centos8

yaml策略为：可以容忍所有为NoSchedule的污点，因为centos8为master节点，污点默认为NoSchedule，所以Pod-3被调度到master节点

（2）当不指定 offect 值时，表示容忍所有的污点类型

tolerations:

- key: "key1"

  value: "value1"

  operator: "Exists"

（3）Pod容忍测试用例：

vim pod2.yaml

apiVersion: v1

kind: Pod

metadata:

  name: pod-

  labels:

    app: nginx

    type: web

spec:

  containers:

  - name: pod-

    image: nginx:1.2.

    imagePullPolicy: IfNotPresent

    ports:

    - name: web

      containerPort:

  tolerations:

  - key: "check"

    operator: "Equal"

    value: "vfan"

    effect: "NoExecute"
[root@Centos8 scheduler]# kubectl create -f pod2.yaml

pod/pod- created

[root@Centos8 scheduler]# kubectl get pod

NAME    READY   STATUS    RESTARTS   AGE

pod-   /     Pending             3m25s

pod-   /     Running             4s

设置容忍的Pod，可以正常调度到Node节点，而没有设置容忍的，还一直处于Pending状态

最后将Node污点去除：

kubectl taint nodes testcentos7 check=vfan:NoExecute-

去除node污点仅需在创建命令的最后加一个 - 即可

三、指定调度节点

注意，以下所有的测试都是1Master、1Node的情况下：

[root@Centos8 scheduler]# kubectl get node

NAME          STATUS   ROLES    AGE    VERSION

centos8       Ready    master   134d   v1.15.1

testcentos7   Ready    <none>   133d   v1.15.1

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

vim nodeName1.yaml

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

  name: nodename-

  labels:

    app: web

spec:

  replicas:

  template:

    metadata:

      labels:

        app: web

    spec:

      nodeName: testcentos7

      containers:

      - name: nodename-

        image: nginx:1.2.

        imagePullPolicy: IfNotPresent

        ports:

        - containerPort: 
[root@Centos8 scheduler]# kubectl apply -f nodeName1.yaml

deployment.extensions/nodename- created

[root@Centos8 scheduler]# kubectl get pod -o wide

NAME                 READY   STATUS    RESTARTS   AGE   IP             NODE

nodename--7f4c7db4d4-hdcjv   /  Running      92s   10.244.3.240 testcentos7

nodename--7f4c7db4d4-xxrj8   /  Running      93s   10.244.3.238 testcentos7

nodename--7f4c7db4d4-zkt2c   /  Running      92s   10.244.3.239 testcentos7

以上策略表示，所有Deployment所有的副本，均要调度到testcentos7节点上

为了对比效果，修改yaml文件中Node节点为centos8

nodeName: centos8

再次创建测试

[root@Centos8 scheduler]# kubectl delete -f nodeName1.yaml 

[root@Centos8 scheduler]# kubectl apply -f nodeName1.yaml

deployment.extensions/nodename- created

NAME                          READY   STATUS    RESTARTS   AGE    IP     NODE

nodename--7d49bd7849-ct9w5   /     Running     2m2s   10.244.0.112  centos8

nodename--7d49bd7849-qk9mm   /     Running     2m2s   10.244.0.113  centos8

nodename--7d49bd7849-zdphd   /     Running     2m2s   10.244.0.111  centos8

全部落在了centos8节点中

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

vim nodeSelect1.yaml

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

  name: node-

  labels:

    app: web

spec:

  replicas:

  template:

    metadata:

      labels:

        app: myweb

    spec:

      nodeSelector:

        type: ssd    # Node包含的标签

      containers:

      - name: myweb

        image: nginx:1.2.

        ports:

        - containerPort: 
[root@Centos8 scheduler]# kubectl apply -f nodeSelect1.yaml

deployment.extensions/node- created

[root@Centos8 scheduler]# kubectl get pod

NAME                      READY   STATUS    RESTARTS   AGE

node--684b6cc685-9lzbn   /     Pending             3s

node--684b6cc685-lwzrm   /     Pending             3s

node--684b6cc685-qlgjq   /     Pending             3s

[root@Centos8 scheduler]# kubectl get node --show-labels

NAME          STATUS   ROLES    AGE    VERSION   LABELS

centos8       Ready    master   135d   v1.15.1   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=centos8,kubernetes.io/os=linux,node-role.kubernetes.io/master=

testcentos7   Ready    <none>   134d   v1.15.1   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=testcentos7,kubernetes.io/os=linux

以上策略表示：将Deployment的三个副本全部调度到标签为type:ssd的Node节点上，因为没有Node节点有此标签，所以一直处于Pending状态

下面我们将testcentos7节点打上标签type:ssd

[root@Centos8 scheduler]# kubectl label node testcentos7 type=ssd

node/testcentos7 labeled

[root@Centos8 scheduler]# kubectl get pod

NAME                      READY   STATUS    RESTARTS   AGE

node--684b6cc685-9lzbn   /     Running             4m30s

node--684b6cc685-lwzrm   /     Running             4m30s

node--684b6cc685-qlgjq   /     Running             4m30s

打上标签后，Pod恢复Running状态

文中有不足之处欢迎指出，不胜感激！

Kubernetes-14：一文详解Pod、Node调度规则(亲和性、污点、容忍、固定节点)的更多相关文章

  1. Docker Kubernetes 服务发现原理详解

    Docker Kubernetes  服务发现原理详解 服务发现支持Service环境变量和DNS两种模式: 一.环境变量 (默认) 当一个Pod运行到Node,kubelet会为每个容器添加一组环境 ...

  2. 一文详解Hexo+Github小白建站

    作者:玩世不恭的Coder时间:2020-03-08说明:本文为原创文章,未经允许不可转载,转载前请联系作者 一文详解Hexo+Github小白建站 前言 GitHub是一个面向开源及私有软件项目的托 ...

  3. 一文详解 Linux 系统常用监控工一文详解 Linux 系统常用监控工具(top,htop,iotop,iftop)具(top,htop,iotop,iftop)

    一文详解 Linux 系统常用监控工具(top,htop,iotop,iftop)     概 述 本文主要记录一下 Linux 系统上一些常用的系统监控工具,非常好用.正所谓磨刀不误砍柴工,花点时间 ...

  4. Kubernetes K8S之Ingress详解与示例

    K8S之Ingress概述与说明,并详解Ingress常用示例 主机配置规划 服务器名称(hostname) 系统版本 配置 内网IP 外网IP(模拟) k8s-master CentOS7.7 2C ...

  5. Kubernetes,kubectl常用命令详解

    kubectl概述 祭出一张图,转载至 kubernetes-handbook/kubectl命令概述 ,可以对命令族有个整体的概念. 环境准备 允许master节点部署pod,使用命令如下: kub ...

  6. 从零开始入门 K8s| 详解 Pod 及容器设计模式

    作者|张磊 阿里云容器平台高级技术专家,CNCF 官方大使 一.为什么需要 Pod 容器的基本概念 我们知道 Pod 是 Kubernetes 项目里面一个非常重要的概念,也是非常重要的一个原子调度单 ...

  7. kubernetes Traefik ingress配置详解

    理解Ingress 简单的说,ingress就是从kubernetes集群外访问集群的入口,将用户的URL请求转发到不同的service上.Ingress相当于nginx.apache等负载均衡方向代 ...

  8. Mysql高手系列 - 第14篇：详解事务

    这是Mysql系列第14篇. 环境:mysql5.7.25,cmd命令中进行演示. 开发过程中,会经常用到数据库事务,所以本章非常重要. 本篇内容 什么是事务,它有什么用? 事务的几个特性 事务常见操 ...

  9. Kubernetes架构及相关服务详解

    11.1.了解架构 K8s分为两部分: 1.Master节点 2.node节点 Master节点组件: 1.etcd分布式持久化存储 2.api服务器 3.scheduler 4.controller ...

随机推荐

  1. JDK下载和安装教程，超详细

    下载并安装JDK JDK的全称是JavaSE Development Kit,即java开发工具包,是sun公司提供的一套用于开发java应用程序的开发包,它提供了编译.运行java程序所需的各种工具 ...

  2. 【HNOI2011】数学作业 题解（递推+矩阵快速幂）

    题目链接 题目大意:求$1-n$所拼接起来的数$mod\ m$的值. ----------------------------------- 递推式子很好想:$f_i=f_{i-1}*10^{\lg ...

  3. 【NOIP2015】斗地主 题解(DFS+贪心)

    题目描述 牛牛最近迷上了一种叫斗地主的扑克游戏.斗地主是一种使用黑桃.红心.梅花.方片的AAA到KKK加上大小王的共545454张牌来进行的扑克牌游戏.在斗地主中,牌的大小关 系根据牌的数码表示如下: ...

  4. PCL使用RANSAC拟合三位平面

    1.使用PCL工具 //创建一个模型参数对象,用于记录结果 pcl::ModelCoefficients::Ptr coefficients(new pcl::ModelCoefficients); ...

  5. boost之signal的使用

    文章目录 简介 代码 模板实现: 测试代码 运行结果 简介 boost是C++的一个扩展库,被称为C++准标准库,里面的组件很丰富,并且引用方便,85%的组件只需要引用头文件即可使用. 并且在嵌入式系 ...

  6. 嵌入式linux简介

    嵌入式linux系统应用非常广泛,涵盖各行各业,基于ARM.mips等微处理器架构的硬件平台.基于嵌入式linux系统的设备已经深入生活中各个角落,随处可见.   我们常说的嵌入式linux系统,其实 ...

  7. java_流程控制语句、权限修饰符

    判断语句 if语句第一种格式: if if(关系表达式){ 语句体; } if语句第二种格式: if…else if(关系表达式) { 语句体1; } else { 语句体2; } if语句第三种格式 ...

  8. 我搭的神经网络不work该怎么办！看看这11条新手最容易犯的错误

    1. 忘了数据规范化 2. 没有检查结果 3. 忘了数据预处理 4. 忘了正则化 5. 设置了过大的批次大小 6. 使用了不适当的学习率 7. 在最后一层使用了错误的激活函数 8. 网络含有不良梯度 ...

  9. 冷饭新炒：理解Snowflake算法的实现原理

    前提 Snowflake(雪花)是Twitter开源的高性能ID生成算法(服务). 上图是Snowflake的Github仓库,master分支中的REAEMDE文件中提示:初始版本于2010年发布, ...

  10. C#LeetCode刷题之#434-字符串中的单词数​​​​​​​（Number of Segments in a String）

    问题 该文章的最新版本已迁移至个人博客[比特飞],单击链接 https://www.byteflying.com/archives/3941 访问. 统计字符串中的单词个数,这里的单词指的是连续的不是 ...