七、集群调度原理以及集群调度策略略

一、k8s调度器Scheduler原理以及调度步骤：

节点预选(Predicate)：排除完全不满足条件的节点，如内存大小，端口等条件不满足。

节点优先级排序(Priority)：根据优先级选出最佳节点

节点择优(Select)：根据优先级选定节点

首先用户通过 Kubernetes 客户端 Kubectl 提交创建 Pod 的 Yaml 的文件，向Kubernetes 系统发起资源请求，该资源请求被提交到

Kubernetes 系统中，用户通过命令行工具 Kubectl 向 Kubernetes 集群即 APIServer 用 的方式发送“POST”请求，即创建 Pod 的请求。

APIServer 接收到请求后把创建 Pod 的信息存储到 Etcd 中，从集群运行那一刻起，资源调度系统 Scheduler 就会定时去监控 APIServer

通过 APIServer 得到创建 Pod 的信息，Scheduler 采用 watch 机制，一旦 Etcd 存储 Pod 信息成功便会立即通知APIServer，

APIServer会立即把Pod创建的消息通知Scheduler，Scheduler发现 Pod 的属性中 Dest Node 为空时（Dest Node=””）便会立即触发调度流程进行调度。

而这一个创建Pod对象，在调度的过程当中有3个阶段：节点预选、节点优选、节点选定，从而筛选出最佳的节点

节点预选：基于一系列的预选规则对每个节点进行检查，将那些不符合条件的节点过滤，从而完成节点的预选

节点优选：对预选出的节点进行优先级排序，以便选出最合适运行Pod对象的节点

节点选定：从优先级排序结果中挑选出优先级最高的节点运行Pod，当这类节点多于1个时，则进行随机选择

二、k8s的调用工作方式

Kubernetes调度器作为集群的大脑，在如何提高集群的资源利用率、保证集群中服务的稳定运行中也会变得越来越重要Kubernetes的资源分为两种属性。

可压缩资源（例如CPU循环，Disk I/O带宽）都是可以被限制和被回收的，对于一个Pod来说可以降低这些资源的使用量而不去杀掉Pod。

不可压缩资源（例如内存、硬盘空间）一般来说不杀掉Pod就没法回收。未来Kubernetes会加入更多资源，如网络带宽，存储IOPS的支持。

三、常用预选策略

四、常用优先函数

(cpu(10 sum(requested) / capacity) + memory(10 sum(requested) / capacity)) / 2

默认没有启用 |

五、节点亲和性调度

1、节点亲和性规则：

硬亲和性 required 、软亲和性 preferred。

硬亲和性规则不满足时，Pod会置于Pending状态，软亲和性规则不满足时，会选择一个不匹配的节点

当节点标签改变而不再符合此节点亲和性规则时，不会将Pod从该节点移出，仅对新建的Pod对象生效

2、节点硬亲和性

requiredDuringSchedulingIgnoredDuringExecution

方式一：Pod使用 spec.nodeSelector (基于等值关系)

方式二：Pod使用 spec.affinity 支持matchExpressions属性 (复杂标签选择机制)

# 调度至 zone = foo 的节点
kubectl label nodes kube-node1 zone=foo
apiVersion: v1
kind: Pod
metadata:
  name: with-required-nodeaffinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:  # 定义硬亲和性
        nodeSelectorTerms:
        - matchExpressions:   #集合选择器
          - {key: zone,operator: In,values: ["foo"]}
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1

六、节点软亲和性

preferredDuringSchedulingIgnoredDuringExecution

• 柔性控制逻辑，当条件不满足时，能接受被编排于其他不符合条件的节点之上
• 权重 weight 定义优先级，1-100 值越大优先级越高

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deploy-with-node-affinity
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      name: myapp-pod
      labels:
        app: myapp
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:   #节点软亲和性
          - weight: 60
            preference:
              matchExpressions:
              - {key: zone, operator: In, values: ["foo"]}
          - weight: 30
            preference:
              matchExpressions:
              - {key: ssd, operator: Exists, values: []}
      containers:
      - name: myapp
        image: ikubernetes/myapp:v1

七、Pod资源亲和调度

• Pod对象间亲和性，将一些Pod对象组织在相近的位置(同一节点、机架、区域、地区)

• Pod对象间反亲和性，将一些Pod在运行位置上隔开

调度器将第一个Pod放置于任何位置，然后与其有亲和或反亲和关系的Pod据此动态完成位置编排

基于MatchInterPodAffinity预选策略完成节点预选，基于

位置拓扑，定义"同一位置"

Pod硬亲和调度

requiredDuringSchedulingIgnoredDuringExecution

Pod亲和性描述一个Pod与具有某特征的现存Pod运行位置的依赖关系；即需要事先存在被依赖的Pod对象

# 被依赖Pod
kubectl run tomcat -l app=tomcat --image tomcat:alpine
kubectl explain pod.spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution.topologyKey

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:  # 硬亲和调度
      - labelSelector:
          matchExpressions:    #集合选择器
          - {key: app, operator: In, values: ["tomcat"]}  # 选择被依赖Pod
          # 上面意思是，当前pod要跟标签为app值为tomcat的pod在一起
        topologyKey: kubernetes.io/hostname  # 根据挑选出的Pod所有节点的hostname作为同一位置的判定
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1

Pod软亲和调度

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-with-preferred-pod-affinity
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      name: myapp
      labels:
        app: myapp
    spec:
      affinity:
        podAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 80
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - {key: app, operator: In, values: ["cache"]}
              topologyKey: zone
          - weight: 20
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - {key: app, operator: In, values: ["db"]}
              topologyKey: zone
      containers:
      - name: myapp
        image: ikubernetes/myapp:v1

Pod反亲和调度

Pod反亲和调度用于分散同一类应用，调度至不同的区域、机架或节点等

将 spec.affinity.podAffinity替换为 spec.affinity.podAntiAffinity

反亲和调度也分为柔性约束和强制约束

apiVersion: v1
kind: Pod
metadata:
    name: pod-first
    labels: 
        app: myapp
        tier: fronted
spec:
    containers:
    - name: myapp
      image: ikubernetes/myapp:v1
---
apiVersion: v1
kind: Pod
metadata:
    name: pod-second
    labels:
        app: backend
        tier: db
spec:
    containers:
    - name: busybox
      image: busybox:latest
      imagePullPolicy: IfNotPresent
      command: ["/bin/sh", "-c", "sleep 3600"]
    affinity:
      podAntiAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - {key: app, operator: In, values: ["myapp"]}
          topologyKey: zone

八、污点和容忍度

污点 taints 是定义在节点上的键值型属性数据，用于让节点拒绝将Pod调度运行于其上，除非Pod有接纳节点污点的容忍度容忍度 tolerations 是定义在Pod上的键值属性数据，用于配置可容忍的污点，且调度器将Pod调度至其能容忍该节点污点的节点上或没有污点的节点上

**1、**预选策略、优选函数

使用PodToleratesNodeTaints预选策略和TaintTolerationPriority优选函数完成该机制

节点亲和性使得Pod对象被吸引到一类特定的节点 (nodeSelector和affinity)

污点提供让节点排斥特定Pod对象的能力

2、定义污点和容忍度

污点定义于nodes.spec.taints容忍度定义于pods.spec.tolerations

语法： key=value:effect

3、effect定义排斥等级：

NoSchedule，不能容忍，但仅影响调度过程，已调度上去的pod不受影响，仅对新增加的pod生效。

PreferNoSchedule，柔性约束，节点现存Pod不受影响，如果实在是没有符合的节点，也可以调度上来

NoExecute，不能容忍，当污点变动时，Pod对象会被驱逐

4、在Pod上定义容忍度时：

等值比较 容忍度与污点在key、value、effect三者完全匹配

存在性判断 key、effect完全匹配，value使用空值

一个节点可配置多个污点，一个Pod也可有多个容忍度

5、管理节点的污点

同一个键值数据，effect不同，也属于不同的污点

给节点添加污点：

kubectl taint node <node-name> <key>=<value>:<effect>
kubectl taint node node2 node-type=production:NoShedule  #举例

查看节点污点：

kubectl get nodes <nodename> -o go-template={{.spec.taints}}

删除节点污点：

kubectl taint node <node-name> <key>[:<effect>]-
kubectl patch nodes <node-name> -p '{"spec":{"taints":[]}}'
kubectl taint node kube-node1 node-type=production:NoSchedule
kubectl get nodes kube-node1 -o go-template={{.spec.taints}}
# 删除key为node-type，effect为NoSchedule的污点
kubectl taint node kube-node1 node-type:NoSchedule-
# 删除key为node-type的所有污点
kubectl taint node kube-node1 node-type-
# 删除所有污点
kubectl patch nodes kube-node1 -p '{"spec":{"taints":[]}}'

给Pod对象容忍度

spec.tolerations字段添加

tolerationSeconds用于定义延迟驱逐Pod的时长

# 等值判断
tolerations:
- key: "key1"
  operator: "Equal"  #判断条件为Equal
  value: "value1"
  effect: "NoExecute"
  tolerationSeconds: 3600
# 存在性判断
tolerations:
- key: "key1"
  operator: "Exists"    #存在性判断，只要污点键存在，就可以匹配
  effect: "NoExecute"
  tolerationSeconds: 3600

apiVersion: v1
kind: Deployment
metadata:
    name: myapp-deploy
    namespace: default
spec:
    replicas: 3
    selector:
        matchLabels:
            app: myapp
            release: canary
    template:
        metadata:
            labels:
                app: myapp
                release: canary
        spec:
            containers:
            - name: myapp
            image: ikubernetes/myapp:v1
            ports:
            - name: http
              containerPort: 80
            tolerations:
            - key: "node-type"
              operator: "Equal"
              value: "production":
              effect: "NoExecute"
              tolerationSeconds: 3600

九、问题节点标识

自动为节点添加污点信息，使用NoExecute效用标识，会驱逐现有Pod

K8s核心组件通常都容忍此类污点

node.kubernetes.io/not-ready 节点进入NotReady状态时自动添加

node.alpha.kubernetes.io/unreachable 节点进入NotReachable状态时自动添加

node.kubernetes.io/out-of-disk 节点进入OutOfDisk状态时自动添加

node.kubernetes.io/memory-pressure 节点内存资源面临压力

node.kubernetes.io/disk-pressure 节点磁盘面临压力

node.kubernetes.io/network-unavailable 节点网络不可用

node.cloudprovider.kubernetes.io/uninitialized kubelet由外部云环境程序启动时，自动添加，待到去控制器初始化此节点时再将其删除

十、Pod优选级和抢占式调度

优选级，Pod对象的重要程度

优选级会影响节点上Pod的调度顺序和驱逐次序

一个Pod对象无法被调度时，调度器会尝试抢占(驱逐)较低优先级的Pod对象，以便可以调度当前Pod

Pod优选级和抢占机制默认处于禁用状态

启用：同时为kube-apiserver、kube-scheduler、kubelet程序的 --feature-gates 添加 PodPriority=true

使用：

事先创建优先级类别，并在创建Pod资源时通过 priorityClassName属性指定所属的优选级类别

八、 集群安全机制

学习目标：集群的认证 鉴权 访问控制 原理及流程

一、认证：

A、HTTP Token认证：通过一个Token来识别合法用户。

HTTP  Token的认证是用一个很长的特殊编码方式的并且难以被模仿的字符串-token来表达客户的一种方式。Token是一个很长很复杂的字符串，每一个token对应一个用户名存储在API Server能访问的文件中。当客户端发起API调用请求的时候，需要在HTTP Header里放入token。

B、 HTTP Base认证：通过用户名+密码的方式认证

用户名+密码使用base64算法进行编码后的字符串放在HTTP Request中的Header Authorization域里发送给服务端，服务端收到后进行编码，获取用户名和密码

C、最严格的HTTPS证书认证：基于CA根证书签名的客户端身份认证方式

二、需要认证的节点

A、两种类型

kubernetes组件对API Server的访问：kubectl、Controller Manager、Scheduler、kubelet、kube-proxy

kubernetes管理的pod对容器的访问：pod(dashboard是以pod形式运行)

B、安全性说明

Controller Manager、Scheduler与API Server在同一台机器，所以直接使用API Server的非安全端口访问， --insecure-bind-address=127.0.0.1

kubectl、kubelet、kube-proxy访问API Server就需要证书进行HTTPS双向认证

证书颁发

a. 手动签发：通过k8s集群的根ca进行签发HTTPS证书

b. 自动签发：kubelet首次访问API Server时，使用token做认证，通过后，Controller Manager会为kubelet生成一个证书，以后的访问都是用证书做认证了。

C、kubeconfig

kubeconfig文件包含集群参数（CA证书、API  Server地址），客户端参数（上面生成的证书和私钥），集群context信息（集群名称，用户名）。kubernetes组件通过启动时指定不同的kubeconfig文件可以切换到不同集群。

D、ServiceAccount

Pod中的容器访问API Server。因为Pod的创建、销毁是动态的，所以要为它手动生成证书就不可行了。kubernetes使用了ServiceAccount解决pod访问apiserver的认证问题。

E、Secret和SA之间的关系

kubernetes设计了一种资源对象叫做Secret，分为两类，一种是用于ServiceAccount的service-account-token，另一种是用于保存用户自定义保密信息的Opaque。ServiceAccount中用到包含三个部分：Token、ca.crt、namespace

a. token是使用api server私钥签名的JWT。用于访问API Server，Server端认证。

b. ca.crt，根证书用于Clien端验证API Server发送的证书。

c. namespace，标识这个server-account-token的作用域空间

e. kubectl get secrets --all-namespace

kubectl describe secret default-token-59mfg --namespace-kube-system

f. 默认情况下每个namespace都会有一个ServiceAccount，如果Pod在创建时没有指定ServiceAccount,就会使用Pod所属的namespace的ServiceAccount

默认挂载目录：/run/secrets/kubernetes.io/serviceaccount/

 F、总结

三、鉴权（Authorization）

A、上面认证过程，只是确认了通信的双方是可信的，可以互相通信。而鉴权是确定请求方有哪些资源的权限。API Server目前支持以下几种授权策略（通过API Server的启动参数“–authorization-mode”设置）

AlwaysDeny：表示拒绝所有请求，一般用于测试

AlwaysAllow：允许接收所有请求，如果集群不需要授权流程，则可以采用该策略。

ABAC（Attribute-Based Access Control）：基于属性的访问控制，表示使用用户配置的授权规则对用户进行匹配和控制

webbook：通过调用外部的REST服务对用户进行授权

RBAC（Role-Based Access Control）：基于角色的访问控制，现行默认

B、RBAC授权模式

RBAC的API资源对象说明

RBAC引入了4个新的顶级资源对象：Role、ClusterRole、RoleBinding、ClusterRoleBinding，4中对象类型均可以通过kubectl和API操作

2. kubernetes组件（kubectl、kube-proxy）或是其它自定义的用户在向CA申请证书的时候，需要提供一个证书请求文件

{
  "CN": "admin",
    "hosts": [],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "name": {
        "C": "CN",
        "ST": "hangzhou",
        "L": "XS",
        "O": "system:masters",
        "OU": "System"
    }
}

API Server会把客户端的CN字段作为User，把names.O字段作为组Group

C、Role和ClusterRole

1. Role要定义在一个namespace中，如果想要跨namespac则可以创建ClusterRole

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
  metadata:
    name: pod-reader
    namespace: default
rules:
  - apiGroups: [""] # ""代表API核心组
    resources: ["pods"]
  verbs: ["get", "watch","list"]

2.ClusterRole和Role具有相同的权限角色控制能力，不同的是ClusterRole是集群级别的，ClusterRole可以用于：

a. 集群级别的资源控制（例如node访问权限）

b. 非资源型endpoints（例如/healz访问）

c. 所有名称空间资源控制（如pods）

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
# 这里不要定义namespace，因为ClusterRole是集群概念下的，不是名称空间概念下的
  name: secret-reader
rules:
  - apiGroup: [""]
  resources: ["secrets"]
  verbs: ["get","watch","list"]

D、RoleBind 和 ClusterRoleBinding

RoleBinding可以将角色中定义的权限授予用户或用户组，RoleBinding包含一组权限列表（subjects），权限列表中包含有不同形式的待授权资源类型（users，groups,or service  account）；RoleBind同样包含对被Bind的Role的引用；RoleBinding适用于某个名称空间内授权，而ClusterRoleBinding适用于集群范围内额授权。

a. 例子

kind: RoleBinding
apiServer: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-pods
  namespace: default
subjects:
  - kind: User
  name: jane
  apiGroup: rbac.autorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

2. RoleBing同样可以引用ClusterRole来对当前namespace内用户、用户组或ServiceAccount进行授权，这种操作允许集群管理员在整个集群内定义一些通用的ClusterRole，然后在不同的namespace中使用RoleBinding来引用。

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta
metadata:
  name: read-secrets
  namespace: development #这只会给development名称空间下的授予权限
subjects:
  - kind: User
  name: dave
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secrets-reader
  apiGroup: rbac.authorization.k8s.io

3.使用ClusterRoleBinding可以对整个集群中的所有命名空间资源进行授权

a. 例子

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-secret-global
subjects:
  - kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

F、Resources

Kubernetes集群内一些资源一般以其名称字符串来表示，这些字符串一般会在API的URL地址中出现；同时某些资源也会包含子资源，例如logs资源就属于pods的子资源，API中的URL样例如下

GET /api/v1/namespaces/{namespace}/pods/{pod}/log

如果要在RBAC授权模式中控制这些子资源的访问权限，可以通过/分隔符来实现，一下是一个定义pods资源logs访问权限的Role定义样例

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: pod-and-pod-logs-reader
  namespace: default
rules:
  - apiGroup: [""]
  resources: ["pods","pods/log"]
  verbs: ["get","list"]

H、实验：创建一个用户只能管理dev空间

1. user add devuser
   
2. passwd devuser
   
3. cd /usr/local/install-k8s/ && mkdir cert && cd cert && vim devuser-csr.json
   

{
    "CN": "devuser",
    "hosts": [],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "ST": "BeiJing",
            "L": "BeiJing",
            "O": "k8s",
            "OU": "System"
        }
    ]
}

\4. 下载证书工具到/usr/local/bin下：

a. wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64

mv cfssl_linux-amd64 cfssl

b. wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64

mv cfssljson_linux-amd64 cfssljson

c. wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64

mv cfssl-certinfo_linux-amd64 cfssl-certinfo

d. cd /etc/kubernetes/pki/

f. cfssl gencert -ca=ca.crt -ca-key=ca.key -profile=kubernetes  /usr/local/install-k8s/cert/devuser/devuser-csr.json | cfssljson -bare  devuser

设置集群参数

a. export KUBE_APISERVER=“https://192.168.66.10:6443”

b. kubectl config set-cluster kubernetes  --certificate-authority=/etc/kubernetes/pki/ca.crt --embed-certs=true  --server=${KUBE_APISERVER} --kubeconfig=devuser.kubeconfig

设置客户端认证参数

a. kubectl config set-credentials devuser  --client-certificate=/etc/kubernetes/pki/devuser.pem  --client-key=/etc/kubernetes/pki/devuser-key.pem --embed-certs=true  --kubeconfig=devuser.kubeconfig

设置上下文参数

a. kubectl config set-context kubernetes --cluster=kubernetes  --user=devuser --namespace=dev --kubeconfig=devuser.kubeconfig

设置默认上下文

c. 创建一个rolebinding将admin角色绑定至dev名称空间下的devuser：kubectl create  rolebinding devuser-admin-binding --clusterrole=admin --user=devuser  --namespace=dev

e. 将devuser.kubeconfig拷贝至devuser下.kube目录下: cp devuser.kubeconfig /home/devuser/.kube/

f. 改变devuser.kubeconfig的所有者为devuser组下的devuser: chown devuser:devuser /home/devuser/.kube/devuser.kubeconfig

g. 将devuser.kubeconfig文件名修改为config: mv devuser.kubeconfig config

h. 切换上下文：kubectl config use-context kubernetes --kubeconfig=/home/devuser/.kube/config

四、准入控制

A、准入控制是Api Server的插件集合，通过添加不同的插件，实现额外的准入控制规则。甚至API  Server的一些主要功能都需要通过Admission  Controllers实现，比如ServiceAccount，官方文档上有一份针对不同版本的准入控制器推荐列表。

B、列举几个插件的功能

NamespaceLifeCycle：防止在不存在的namespace上创建对象，防止删除系统预置的namespace，删除namespace时，连带删除它的所有资源对象。

LimitRanger：确保请求的资源不会超过资源所在的Namespace的LimitRange

ServiceAccount：实现了自动化添加ServiceAccount

ResourceQuota：确保请求资源不会超过资源的ResourceQuota限制

查看系统运行日志：journalctl -f