k8s备忘 - 下

调度

简介

Scheduler是k8s的调度器，主要任务是定义的pod分配到集群的节点上

调度原则

• 公平：保证每个节点都能被分配资源
• 资源高效利用：集群所有资源最大化被使用
• 效率：调度的性能要好，能够尽快地对大批量的pod完成调度工作
• 灵活：允许用户根据自己的需求控制调度的逻辑
  Scheduler是作为单独的程序运行的，启动之后会一直坚挺（持续连接）APIServer，获取PodSpec.NodeName为空的pod，对每个pod都会创建一个binding，表明该pod应该放到哪个节点上
  指定了PodSpec.NodeName后scheduler不需要参与进来，除此外都会参与
  -#### 调度过程

调度分为几个部分：首先是predicate（预选）：过滤掉不满足条件的节点；然后是priority（优选）：对通过的节点按照优先级排序；最后是从中选择优先级最高的节点，如果中间任何一步有错，则直接返回错误
【Predicate常见算法】

• PodFitsResources：节点上剩余的资源是否大于pod请求的资源
• PodFitsHost：如果pod指定了NodeName，检查节点名称是否和NodeName匹配
• PodFitsHostPorts：节点上已经使用的port是否和pod申请的port冲突
• PodSelectorMatches：过滤掉和pod指定的label不匹配的节点
• NoDiskConflict：已经mount的volume和pod指定的volume不冲突，除非他们都是只读

如果在predicate过程中没有合适的节点，pod会一直在pending状态，不断重试调度，直到有节点满足条件。
经过这个步骤，如果有多个节点满足条件，就继续priorities过程：按照优先级大小对节点排序：
【优先级】由键值对组成，键是名称，值是权重：

• LeastRequestedPriority：通过计算CPU和Memory的使用率来决定权重，使用率越低权重越高，换句话说，这个优先级指标倾向于资源使用比例更低的节点
• BalancedResourceAllocation：节点上CPU和Memory使用率越近，权重越高。这个应该和上面的一起使用，不应该单独使用
• ImageLocalityPriority：倾向于已经有要使用镜像的节点，镜像总大小值越大，权重越高
  通过算法对所有的优先级项目和权重进行计算，得出最终的结果

自定义调度器

（不满足于官方提供的调度器，可自行编写）
通过spec:schedulername参数指定调度器的名称，可以为pod选择某个调度器进行调度，比如下面的pod选择my-scheduler进行调度。而不是默认的default-scheduler：

apiVersion: v1
kind: Pod
metadata:
  name: annotation-second-scheduler
  labels:
    name: mulischeduler-example
spec:
  schedulername: my-scheduler
  containers:
  - name: pod-with-second-annotation-container
    image: gcr.io/google_containers/pause:2.0

调度亲和性

节点亲和性（pod和node间）

pod.spec.nodeAffinity下声明

• preferredDuringSchedulingIgnoredDuringExecution：软策略
• requiredDuringSchedulingIgnoredDuringExecution：硬策略

  举例：分班级，我更倾向于张三老师的班级，如果我是pod，张三老师就是node，这就是所谓的节点亲和性。有个说法就是，我必须去 硬策略、我想去，典型的软策略

## 硬策略：不满足就不运行
apiVersion: v1
kind: Pod
metadata:
  name: affinity
  labels:
    app: node-affinity-pod
spec:
  containers:
  - name: with-node-affinity
    image: hub.jade.com/library/myapp:v1
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoreDuringExecution:
        nodeSelectorTerms:
        # notin 只要不是kubernetes.io/hostname标签，值为k8s-node02的节点就行
        - matchExpressions:
          - key: kubernetes.io/hostname
            operator: NotIn
            values:
            - k8s-node02
# 结果始终运行在node02
          
## 软策略：如果有的话就运行，没有就算了
apiVersion: v1
kind: Pod
metadata:
  name: affinity
  labels:
    app: node-affinity-pod
spec:
  containers:
  - name: with-node-affinity
    image: hub.jade.com/library/myapp:v1
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        prefernece:
          matchExpressions:
          - key: kubernetes.io/hostname
            operator: In
            values:
            - k8s-node03
# 结果 不存在node03，到node01上运行
            
## 合体：先满足硬策略再满足软策略
apiVersion: v1
kind: Pod
metadata:
  name: affinity
  labels:
    app: node-affinity-pod
spec:
  containers:
  - name: with-node-affinity
    image: hub.jade.com/library/myapp:v1
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoreDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/hostname
            operator: NotIn
            values:
            - k8s-node02
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: kubernetes.io/hostname
            operator: In
            values:
            - k9s-node03

【键值运算关系】：

• In：label的值在某个列表中
• NotIn：label的值不在某个列表中
• Gt：label的值大于某个值
• Lt：label的值小于某个值
• Exists：某个label存在
• DoesNotExist：某个label不存在
  如果nodeSelectorTerms下面有多个选项的话，满足任何一个条件就可以了
  如果matchExpressions有多个选项，则必须同时满足这些条件才能正常调度pod

Pod亲和性（pod和pod间）

pod.spec.affinity.podAffinity/podAntiAffinity下声明

• preferredDuringSchedulingIgnoredDuringExecution：软策略
• requiredDuringSchedulingIgnoredDuringExecution：硬策略

  举例：原来同桌叫李四，我想和李四一个班级，这就是pod亲和性，李四在的班级我一定要去 硬策略，一不去不行；李四在的班级我想去 软策略，想的概念就是不去也可以

# 首先新建一个在node01上的pod-1
# 然后创建pod-3利用亲和性和pod1在一个node
apiVersion: v1
king: Pod
metadata:
  name: pod-3
  labels:
    app: pod-3
spec:
  containers:
  - name: pod-3
    image: hub.jade.com/library/myapp:v1
  affinity:
    podAffinity:# 想让两个pod运行在同一个node用pod亲和性
      requiredDuringSchedulingIgnoreDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - node01
            # 当pod标签app存在pod-1时就选择，不存在就不运行
        topologykey: kubernetes.io/hostname # 通过这个值判断两个pod是否在同一node上
    podAntiAffinity:# 不想让两个pod运行在同一个node上用pod反亲和性
      preferredDuringSchedulingSchedulingIgnoreDuringExecution:
      - weight: 1
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - node01

亲和性/反亲和性调度策略比较如下：

(同一拓扑域：同一labels下)

调度策略	匹配标签	操作符	拓扑域支持	调度目标
nodeAffinity	主机	In NotIn Exists DoesNotExist Gt Lt	否	指定主机
podAffinity	POD	In NotIn Exists DoesNotExist	是	pod与指定pod同一拓扑域
podAnitAffinity	POD	In NotIn Exists DoesNotExist	是	pod与指定pod不在同一拓扑域

Taint和Toleration

节点亲和性，是pod的一种属性（偏好或硬性要求），它使pod被吸引到一类特定的节点
Taint则相反，是node的属性，它使节点能够排斥一类特定的pod
Taint和toleration相互配合，可以用来避免pod被分配到不合适的节点上。每个节点上都可以应用一个或多个taint，这表示对于那些不能容忍这些taint的pod，是不会被该节点接受的。如果将toleration应用于pod上，则表示这些pod可以（但不要求）被调度到具有匹配taint的节点上
(举例：相亲，有些人不喜欢对方打呼，容忍不了)

污点（Taint）

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

key=value:effect
# 每个污点有一个key和value作为污点的标签，其中value可为空，effect描述污点的作用

当前taint effect支持如下三个选项：

• NoSchedule：表示k8s将不会调度到具有该污点的node上；master节点天生就被打了这个污点标签，所以pod不会运行到master上
• PreferNoSchedule：表示k8s将尽量避免将pod调度到具有该污点的node上
• NoExecute：表示k8s将不会将pod调度到具有该污点的node上，同时会将node上已经存在的Pod驱逐出去

污点的设置、查看和去除

# 设置污点
kubectl taint nodes node1 key1=value1:NoSchedule

# 节点说明中查找Taints字段
kubectl describe pod pod-name

# 去除污点
kubectl taint nodes node1 key1:NoSchedule-

容忍（Tolerations）

设置了污点的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: 3600
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"
- key: "key2"
  operator: "Exists"
  effect: "NoSchedule"

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

  # 1.当不指定key时，表示容忍所有的污点key
  tolerations:
  - operator: "Exists"
  # 2.当不指定effect值时，表示容忍所有的污点作用
  tolerations:
  - key: "key"
    operator: "Exists"
  # 3.有多个master存在时，防止资源浪费，可以设置如下
  kubectl taint nodes Node-Name node-role.kubernetes.io/master=:PreferNoSchedule # 尽可能不在该节点运行

指定调度节点

pod.spec.nodeName将pod直接调度到指定的node节点上，会跳过Scheduler的调度策略，该匹配规则是强制匹配

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: myweb
spec:
  replicas: 7
  template:
    metadata:
      label:
        app:myweb
    spec:
      nodeName: k8s-node01
      containers:
      - name: myweb
        image: hub.jade.com/library/myapp:v1
        ports:
        - containerPort: 80

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

# 没有匹配标签会一直peding
kubectl label node k8s-node01 disk=ssd

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: myweb2
spec:
  replicas: 2
  template:
    metadata:
      label:
        app:myweb2
    spec:
      nodeSelector:
        disk: ssd
      containers:
      - name: myweb2
        image: hub.jade.com/library/myapp:v1
        ports:
        - containerPort: 80

---

安全

机制说明

k8s作为一个分布式集群的管理工具，保证集群的安全性是一个重要的任务
apiServer是集群内部各个组件通信的中介，也是外部控制的入口。
所以k8s的安全机制基本就是围绕保护apiServer来设计的
k8s使用了认证(Authentication)、鉴权(Authorization)、准入控制(Admission Control)三步来保证APIServer的安全

认证（Authentication）

• HTTP Token认证：通过一个Token来识别合法用户
  • HTTP Token的认证是用一个很长的特殊编码方式且难以被模仿的字符串-Token来表达客户的一种方式
    每一个token对应一个用户名存储在APiServer能访问的文件中，当客户端发起API调用请求时，需要在HTTP Header里放入Token
• HTTP Base认证：通过用户名+密码的方式认证
  • 用户名+:+密码 用base64算法进行编码后的字符串放在HTTP Request中的Heather Authorization域里发送给服务端，服务端收到后进行编码，获取用户名及密码
• HTTPS证书认证（最严格的）：基于CA根证书签名的客户端身份认证方式（服务端客户端双向认证）

HTTPS证书认证

需要认证的节点

两种类型

• k8s组件对APIServer的访问：kubectl、ControllerManager、Scheduler、Kubelet、Kube-proxy
• k8s管理的pod对容器的访问：Pod（dashboard也是以pod形式运行）

安全性说明

• （本机访问）ControllerManager、Scheduler与APIServer在同一台机器，所以直接使用APIServer的非安全端口访问，–insecure-bind-address=127.0.0.1
• （远程访问，需防止第三方攻击）kubectl、kubelet、kube-proxy访问APIServer就都需要证书进行HTTPS双向认证

证书颁发

• 手动签发：通过k8s集群的根ca进行签发HTTPS证书（kubeadm安装，不涉及手动，都是自动）
• 自动签发：kubelet首次访问APIServer时，使用token做认证，通过后，ControllerManager会为kubelet生产一个证书，以后的访问都是用证书做认证了

kubeconfig

kubeconfig文件包含集群参数（CA证书、APIServer地址），客户端参数（上面生成的证书和私钥），集群context信息（集群名称、用户名）
k8s组件通过启动时指定不同的kubeconfig文件可以切换到不同的集群
【位置】：.kube

ServiceAccount

pod中的容器访问APIServer，因为pod的创建销毁是动态的，所以要为pod手动生成证书不可行，

Secret和SA关系

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

• token：使用apiserver私钥签名的JWT，用于访问apiServer时服务端认证
• ca.crt：根证书，用于client端验证APIServer发送的证书
• ns：标识这个service-account-token的作用域名空间

  Json web token（JWT）：是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（[RFC 7519]），该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密

kubectl get secret --all-namespaces
kubectl describe secret default-token-5gm9r --namespace=kube-system

默认情况下，每个ns都会有一个sa，如果pod在创建时没有指定sa，就会使用pod所属的ns的sa
默认挂载目录：/run/secrets/kubernetes.io/serviceaccount/

鉴权（Authorization）

认证通过后并不意味着拥有访问资源的可能，还需鉴权后才能有访问具体对象的能力
上面认证过程，只是确认通信的双方都确认了对方是可信的，可以相互通信
而鉴权，是确定请求方有哪些资源的权限

API Server目前支持一下几种授权策略

（通过API Server的启动参数–authorization-mode设置）

• AlwaysDeny：表示拒绝所有请求，一般用于测试
• AlwaysAllow：允许接收所有请求，如果集群不需要授权流程，则可以采用该策略
• ABAC（Attribute-Based Access Control）：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制
• Webhook：通过调用外部REST服务对用户进行授权
• RBAC（Role-Based Access Control）：基于角色的访问控制，现行默认规则

RBAC授权模式

RBAC（Role-Based Access Control）：基于角色的访问控制，在k8s1.5中引入，现行版本成为默认标准，相对其他访问控制方式，拥有一下优势：

• 对集群中的资源和非资源均拥有完整的覆盖
• 整个RBAC完全由几个API对象完成，同其他API对象一样，可以用kubectl或API进行操作
• 可以在运行时进行调整，无需重启API Server（ABAC修改完还需重启）

1. RBAC的API资源对象说明
   RBAC引入了4个新的顶级资源对象：Role、ClusterRole、RoleBinding、ClusterRoleBinding，4种对象类型均可以通过kubectl与API操作
   
   需要注意的是k8s并不会提供用户管理，那么User、Group、ServiceAccount指定的用户又是从哪里来的呢？
   Kubernetes组件（kubectl、kube-proxy）或是其他自定义的用户在向CA申请证书时，需要提供一个证书请求文件

   # API Server会把客户端证书的CN字段作为User，把names.0字段作为Group
   
   {
       "CN": "admin", # 用户名
       "hosts": [],
       "key": {
           "algo": "rsa",
           "size": 2048
       },
       "names": [
       {
           "C": "CN",
           "ST": "HangZhou",
           "L": "XS",
           "O": "system:masters",# 组
           "OU": "System"
       }]
   }

   kubelet使用TLS Bootstraping认证时，APIServer可以使用Bootstrap Tokens或者Token authentication file验证=token，无论哪一种，k8s都会为token绑定一个默认的User和Group

Pod使用sa认证时，service-account-token中JWT会保存User信息

有了用户信息，再创建一对角色/角色绑定（集群角色/集群角色绑定）资源对象，就可以完成权限绑定了

2. Role and ClusterRole
   在RBAC API中，Role表示一组规则权限，权限只会增加（累加），不存在一个资源一开始就有很多权限而通过RBAC对其进行减少的操作；Role可以定义在一个ns中，如果想要跨ns则可以创建ClusterRole

   kind: Role
   apiVersion: rbac.authorization.k8s.io/v1beta1
   metadata:
     namespace: default
     name: pod-reader
   rules:
   - apiGroups: [""] # "" indicates the core API group
     resources: ["pods"]
     verbs: ["get", "watch", "list"]
     
   kubectl create role pod-reader --verb=get,watch,list --resource=pods

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

• 集群级别的资源控制（例如node访问权限）
• 非资源型endpoints（例如/healthz访问）
• 所有命名空间资源控制（例如pods）

  kind: ClusterRole
  apiVersion: rbac.authorization.k8s.io/v1beta1
  metadata:
    # "namespace" omitted since ClusterRoles are not namespaced
    name: secret-reader
  rules:
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get", "watch", "list"]
    
  kubectl create clusterrole secret-reader --verb=get,watch,list --resource=secrets

3. RoleBinding and ClusterRoleBinding
   RoleBinding可以将角色中定义的权限授予用户或用户组
   RoleBinding包含一组权限列表（subjects），权限列表中包含有不同形式的待授予权限资源类型（users，groups，or service accounts）
   RoleBinding同样包含对被bind的role引用
   RoleBinding适用于某个ns内授权，而ClusterRoleBinding适用于集群范围内的授权
   rolebinding可以绑定role、clusterrole；clusterrolebinding只能绑定clusterrole

将default命名空间的pod-reader Role授予jane用户，伺候jane用户在default ns中将具有pod-reader的权限

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

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

例如，以下RoleBinding引用了一个ClusterRole，这个ClusterROle具有整个集群内对secrets的访问权限；但是其授权用户dave只能访问development空间中的secrets（因为RoleBinding定义在develop命名空间）

# This role binding allows "dave" to read secrets in the "deployment" namespcae.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-secrets
  namespace: development # This only grants permissions within the "development" namespace.
subjects:
- kind: User
  name: dave
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

使用ClusterRoleBinding可以对整个集群中的所有ns资源权限进行授权；以下ClusterRolebinding样例展示了授权manager组内所有用户在全部ns中对secrets进行访问

# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager
  apiGroup: tbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

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

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

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

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

5. to Subjects
   RoleBinding和ClusterRoleBinding可以将Role绑定到Subjects；
   Subjects可以是groups、users或者service accounts

Subjects中Users使用字符串表示，它可以是一个普通的名字字符串，如”alice”；
也可以是email格式的邮箱地址，如”jade@qq.com“
甚至是一组字符串形式的数字ID
但是Users的前缀system:是系统保留的，集群管理员应该确保普通用户不会使用这个前缀格式

Groups书写格式与Users相同，都为一个字符串，并且没有特定的格式要求；同样system:前缀为系统保留

实践

创建一个用户只能管理dev空间

# 创建用户
useradd devuser
passwd devuser

# 创建devuser的证书请求
cd /user/local/install-k8s
mkdir -p cert/devuser
cd cert/devuser && vim devuser-csr.json
{
    "CN": "devuser",
    "hosts": [], # 不写代表所有
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [{
        "C": "CN",
        "ST": "BeiJing",
        "L": "BeiJing",
        "O": "k8s",
        "OU": "System"
    }]
}

# 下载证书生成工具
wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
mv cfssl_linux-amd64 /usr/local/bin/cfssl

wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
mv cfssljson_linux-amd64 /usr/local/bin/cfssljson

wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64
mv cfssl-certinfo_linux-amd64 /usr/local/bin/cfssl-certinfo

cd /usr/local/bin/
chmod a+x *

cd /etc/kubernetes/pki/ # 存放的都是密钥信息
cfssl gencert -ca=ca.crt -ca-key=ca.key -profile=kubernetes /usr/local/install-k8s/cert/devuser/devuser-csr.json | cfssljson -bare devuser

# 设置集群参数
cd /usr/local/install-k8s/cert/devuser
export KUBE_APISERVER="https://192.168.66.10:6443"
kubectl config set-cluster kubernetes \
--certificate-authority=/etc/kubernetes/pki/ca.crt \
--embed-certs=true \
--server-${KUBE APISERVER} \
--kubeconfig=devuser.kubeconfig
cat devuser.kubeconfig

#设置客户端认证参数
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 # 写入kubeconfig文件

#设置上下文参数（绑定至某一个空间）
kubectl create namespace dev
kubectl config set -context kubernetes \
--cluster=kubernetes \ # 默认集群名称
--user=devuser \
--namespace=dev \
--kubeconfig=devuser.kubeconfig

# devuser可以在dev中拥有admin权限
kubectl create rolebinding devuser-admin-binding --clusterrole=admin --user=devuser --namespace=dev

cp -f ./devuser.kubeconfig /home/.kube/config
chown devuser:devuser /home/.kube/config

#设置默认上下文（切换）
kubectl config use-context kubernetes --kubeconfig=config

kubectl run nginx --image=hub.jade.com/library/myapp:v2
kubectl get pod会展示刚刚创建的nginx
默认nv是dev，查看default无权限

准入控制（Admission Control）

准入控制是API Server的插件集合，通过添加不通的插件，实现额外的准入控制规则。甚至于APIServer的一些主要的功能都需要通过Admission Controllers实现，比如SA

官方文档上有一份针对不同版本的准入控制器推荐列表，其中最新的1.14的推荐列表是

NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota

列举几个插件的功能：

• NamespaceLifecycle：防止在不存在的namespace上创建对象，防止删除系统预置ns，删除ns时，连带删除它的所有资源对象
• LimitRanger：确保请求的资源不会超过资源所在的ns的LimitRange的限制
• ServiceAccount：实现了自动化添加ServiceAccount
• ResourceQuota：确保请求的资源不会超过资源的ResourceQuota限制

---

Helm

定义

没使用helm之前，向k8s部署应用，我们要依次部署deployment、svc等，步骤较繁琐。
况且随着很多项目微服务化，复杂的应用在容器中部署以及管理显得较为复杂，helm通过打包的方式，支持发布的版本管理和控制，很大程度简化了k8s应用的部署和管理

helm本质就是让k8s的应用管理（deploy、svc等）可配置，能动态生产。通过动态生产k8s资源清单文件（deploy.yaml、svc.yaml），然后调用kubectl自动执行k8s资源部署

Helm是官方提供的类似于YUM的包管理器，是部署环境的流程封装。

Helm有两个重要的概念：chart和release

chart

是创建一个应用的信息集合，包括各种k8s对象的配置模板、参数定义、依赖关系、文档说明等。
chart是应用部署的自包含逻辑单元。可以将chart想象成apt、yum中的软件安装包

release

是chart的运行实例，代表了一个正在运行的应用
当chart被安装到k8s集群，就生产一个release
chart能够多次安装到同一个集群，每次安装都是一个release

组件

Helm包含两个组件：Helm客户端和Tiller服务器，如下图所示

Helm客户端负责chart和release的创建和管理以及和Tiller的交互
Tiller服务器运行在k8s集群中，处理Helm客户端的请求，与k8s API Server交互

Helm部署

# 下载helm命令行工具到master节点的/usr/local/bin下，这里下载2.13.1版本
ntpdate ntp1.aliyun.com
wget https://storage.googleapis.com/kubernetes-helm/helm-v2.13.1-linux-amd64.tar.gz
cd /usr/local/install-k8s
mkdir helm
mv helm-v2.13.1-linux-amd64.tar.gz ./helm
cd helm
tar -zxvf helm-v2.13.1-linux-amd64.tar.gz
cd linux-amd64/
cp helm /usr/local/bin/
chmod a+x /usr/local/bin/helm

为了安装服务端tiller，还需要在这台机器上配置好kubectl工具和kubeconfig文件，确保kubectl工具可以在这台机器上访问apiserver且正常使用，这里的node1节点已经配置好了kubectl

因为kubernetes APIServer开启了RBAC访问控制，所以需要创建tiller使用的service account:tiller并分配合适的角色给它。详细内容可以查看helm文档中的Role-based Access Control 这里简单起见直接分配cluster-admin这个集群内置的ClusterRole给它。创建rbac-config.yaml文件

vim rbac.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: tiller
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/vlbeta1
kind: ClusterRoleBinding
metadata:
  name: tiller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: tiller
  namespace: kube-system
  
kubectl create -f rbac-config.yaml
serviceaccount/tiller created
clusterrolebinding.rbac.authorization.k8s.io/tiller created

helm init --service-account tiller --skip-refresh

# tiller默认被部署在k8s集群中的kube-system这个ns下
kubectl get pod -n kube-system -I app=helm
NAME                          READY STATUS  RESTARTSAGE
tiller-deploy-c4fd4cd68-dwkhv  1/1  Running  83s

# 查看当前版本信息
helm version
Client: &version.Vension{SemVer:"v2.13.1"，GitCommit;"618447cbf203d147601b4b9bd7f8c37a5d39fbb4", GitTreeState:"clean"}
Server: &version.Vension{SemVer:"v2.13.1"，GitCommit:"618447cbf203d147601b4b9bd7f8c37a5d39fbb4", GitTreeState:"clean"}

# 页面查看helm仓库
helm.sh
hub.helm.sh

Helm自定义模板

# 创建文件夹
$ mkdir ./hello-world
$ cd ./hello-world

# 创建自描述文件 Chart.yaml ，这个文件必须有 name 和 version 定义
$ cat <<'EOF' > ./Chart.yaml
name: hel1o-world
version: 1.0.@
EOF

# 创建模板文件，用于生成 Kubernetes 资源清单 (manifests)
$ mkdir ./templates
$ cat <<'EOF' > ./templates/deployment .yaml
apiVersion: extensions/vibeta1
kind: Deployment
metadata:
  name: hello-world
spec:
  replicas: 1
  template:
    metadata :
      labels:
        app: hello-world
    spec:
      containers:
      - name: hello-world
        image: hub.atguigu.com/library/myapp:v1
        ports:
        - containerPort: 80
          protocol: TCP
EOF

$ cat <<'EOF' > ./templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: hello-world
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  selector:
    app: hello-world
EOF

# 使用命令 helm install RELATIVE PATH TO_CHART 创建一次Release
$ helm install .

# 列出已经部署的 Release
$ helm ls
# 获取pod发现镜像下载失败，修改为本地镜像后更新helm
kubectl get pod 
# 更新helm
$ helm uograde nobby-eel .
# 查看helm历史
$ helm history nobby-eel
#查询一个特定的 Release 的状态
$ helm status ${RELEASE_NAME}
# 移除所有与这个 Release 相关的 Kubernetes 资源
$ helm delete nobby-eel
# helm rollback ${RELEASE_NAME} ${REVISION_NUMBER}
$ helm rollback nobby-eel 1
# 使用 helm delete --purge ${RELEASE_NAME} 移除所有与指定 Release 相关的 Kubernetes 资源和所有这个Release 的记录
$ helm delete --purge nobby-eel
$ helm ls --deleted

## 灵活使用helm，使用配置文件、引用；更改配置文件即可修改镜像 或者通过--set的方式指定镜像
# 1.配置体现在配置文件 values.yaml
$ cat <<'EOF' > ./values.yaml
image:
  repository: hub.jade.com/library/myapp
  tag: 'v1'
EOF

# 这个文件中定义的值，在模板文件中可以通过 .VAlues对象访问到
$ cat <<'EOF' > ./templates/deployment.yaml
apiVersion: extensions/vibeta1
kind: Deployment
metadata:
  name: hello-world
spec :
  replicas: 1
  template:
    metadata :
      labels :
        app: hello-world
    spec:
      containers:
      - name: hello-world
        image: (( .Values.image.repository ]}:{{ .Values.image.tag }}
        ports :
        - containerPort: 888
          protocol: TCP
EOF
# 修改版本为v2后更新
$ helm uograde nobby-eel .


# 2.在 values.yam1 中的值可以被部署 release 时用到的参数 --values YAML_FILE_PATH 或 --setkey1=value1，key2=value2 覆盖掉
$ helm install --set image.tag='v3" .
helm upgrade -f values.yaml nobby-eel .
or
# 覆盖版本为v3并直接升级
$ helm uograde nobby-eel --set image.tag='v3" .

Debug

# 使用模板动态生成K8s资源清单，非常需要能提前预览生成的结果。
# 使用--dry-run --debug 选项来打印出生成的清单文件内容，而不执行部署
helm install .--dry-run --debug --set image.tag=latest

使用Helm部署dashboard

cd /usr/local/install-k8s/plugin
mkdir dashboard && cd dashboard
# 更新chart仓库
helm repo update
# 查看
helm repo list
# 下载
helm fetch stable/kubernetes-dashboard

# kubernetes-dashboard.yaml
vim kubernetes-dashboard.yaml
image:
  repository: k8s.gcr.io/kubernetes-dashboard-amd64
  tag: v1.19.1
ingress:
  enabled: true
  hosts:
  - k8s.frognew.com
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
  tls:
  - secretName: frognew-com-tls-secret
    hosts:
    - k8s.frognew.com
rbac:
  clusterAdminRole: true

helm install . -n kubernetes-dashboard --namespace kube-system -f kubernetes-dashboard.yaml

# 查询dashboard token以便登录dashboard
kubectl -n kube-system get secret | grep kubernetes-dashboard-token
kubernetes .io/service-account-token   3   3m7s kubectl describe -n kube-system
secret/kubernetes-dashboard-token-pkm2s Name:kubernetes-dashboard-token-pkm2sNamespace:kube-system Labels:<none> Annotations: kubernetes.io/service-account.name:kubernetes-dashboard kubernetes,io/service-account,uid: 2f0781dd-156a-11e9-b0f0-080027bb7c43Type: kubernetes.io/service-account-token Data ==== ca.crt:1025 bytes namespace: 11 bytes
token:
eyJhbGci0iJSUzI1NiIsImtpZCI6Ii9.eyJpc3Mi0iJrdwJlcm51dGVzL3N1cnZpy2VhY2NvdW50Iiwia3VizXJuzXRlcy5pby9zzXJ2aWNIYWNjb3VudC9uYW11c3BhY2Ui0iJrdWJ1LXN5c3RIbSIsImt1YmVybmV@ZXMuaM8vc2VydmljzWFjY291bn0Vc2VjcmV9Lm5hbwUi0iJrdWlcm5ldGVzLWRhc2hib2FyZC10b2tlbi1wa20ycyIsImt1YmVybmV@zXMuaW8vc2VydmljzwjY291bnOvc2VydmljZS1hY2NvdW50Lm5hbwUi0iJrdWJlcm51dGZLWRhc2hib2FyzcIsImt1YmVybmV@zXMuaW8vc2VydmliZWFiY291bn0vc2VvamliZS1Y2NvdM50LnVZCI6IJmMDC4MRKLTE1NmEMTF10S1MGYWLTA4MDAVN2JiN2MOMVISIn1YiI6InN5C3RIbTpzzXJ2aMN1YWNjb3VudDprdWJ1LXN5C3RIbTprdwJlcm51dGVzLWRhc2hib2FyzCJ9.24ad6ZgZMxdydpwlmYAiMxZ9VSIN7dDR706-RLWOqC81ajXoQKHAyrEGpIonfld3ggbE0x08nis skpmlkQra72-9X6sBPoBygIKyTs083BO1ME2sfoJemWDOHazwsCiySOax-bUlg9HgH2vEXzpFuSS6Sv7RbfzLX1EuggNoC4MfA4E2hF10X m18iAKx-49y1B00e5FGWyCyBSi1TDZpVs44H5gIvsGK2kcvi0JT4oHXtWjjQBKLIWL7xxyRCSE4HmUZT2StIHn0w1X7IEIB0oBX4mPg2 xNGnqwcu-80ERU9IOgAAE2cZav3b50:IPrcxrVOukYRIUMA

kubectl edit svc kubernetes-dashboard -n kube-system
修改 ClusterIP 为 NodePort

使用Helm部署metrics-server

# metrics-server.yaml
args:
- --logtostderr
- --kubelet-insecure-tls
- --kubelet-preferred-address-types=InternalIp

helm install stable/metrics-server -n metrics-server --namespace kubesystem -f metrics-server.yaml

# 使用下面的命令可以获取到关于集群节点基本的指标信息
kubectl top node
NAME     CPU(cores)  CPU%   MEMORY(bytes)  MEMORY%
node1    65m         32%    1276Mi         73%
node2    73m         3%     527Mi          30%

kubectl top pod --all-namespaces

使用Helm部署prometheus

metrics-server和prometheus只能选一种使用，因为prometheus集成了metrics-server
[prometheus github地址]：https://github.com/coreos/kube-prometheus

组件说明

• MetricServer：是k8s集群资源使用情况的聚合器，收集数据给k8s集群内使用，如kubectl，hpa，scheduler等
• PrometheusOperator：是一个系统监测和警报工具箱，用来存储监控数据
• NodeExporter：用于各node的关键度量指标状态数据
• KubeStateMetrics：收集k8s集群内资源对象数据，制定告警规则
• Prometheus：采用pull方式收集apiserver，scheduler，controller-manager，kubelet组件数据，通过http协议传输
• Grafana：是可视化数据统计和监控平台

部署

cd /usr/local/install-k8s/plugin
mkdir prometheus && cd prometheus

# 下载prometheus
git clone https://github.com/coreos/kube-prometheus.git
cd kube-prometheus/mainfests

# 修改grafana-service.yaml文件，使用nodeport方式访问grafana：
vim grafana-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: grafana
  namespace: monitoring
spec:
  type: NodePort  # 添加内容
  ports:
  - name: http
    port: 3000
    targetPort: http
    nodePort: 30100  # 添加内容
  selector:
    app: grafana
    
# 修改prometheus-service.yaml，改为nodeport
vim prometheus-service.yaml
apiVersion: v1
kind: Service
metadata:
  labels:
    prometheus: k8s
  name: prometheus-k8s
  namespace: monitoring
spec:
  type: NodePort  # 添加内容
  ports:
  - name: web
    port: 9090
    targetPort: web
    nodePort: 30200  # 添加内容
  selector:
    app: prometheus
    prometheus: k8s
    
# 修改alertmanager-service.yaml，改为ndeport
vim alertmanager-service.yaml
apiVersion: v1
kind: Service
metadata:
  labels:
    alertmanager: main
  name: alertmanager-main
  namespace: monitoring
spec:
  type: NodePort  # 添加内容
  ports:
  - name: web
    port: 9093
    targetPort: web
    nodePort: 30300  # 添加内容
  selector:
    alertmanager: main
    app: alertmanager
    
# 部署（部署前可以先导入要用的镜像）
kubectl apply -f ../manifests/
# 查看
kubectl get pod -n monitoring
kubectl top node
kubectl get svc --all-namespaces

Horizontal Pod Autoscaling

# Horizontal Pod Autoscaling 可以根据CPU利用率自动伸缩一个Replication Controller、Deployment或者Replica Set中的Pod数量
# hpa-example镜像：谷歌做的hpa测试镜像，基于php，非常消耗资源的应用程序，通过循环调用造成资源占用，来演示hpa扩展
kubectl run php-apache --image=gcr.io/google_containers/hpa-example --requests=cpu=200m --expose --port=80

kubectl top pod php-apache-2342343-5df

# 创建HPA控制器
kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
# 阈值 cpu利用率一旦超过50就开始创建新的pod，最大10个，cpu利用率减少会回收（回收较慢），最少1个
kubectl get hpa

# 增加负载，查看负载节点数目
kubectl run -i --tty load-generator --image=busybox /bin/sh
while true; do wget -1 -O- https://php-apache.default.svc.cluster.local; done
# 新开窗口
kubectl get hpa -w
kubectl get pod -w

资源限制 - Pod

k8s对资源的限制实际上是通过cgroup来控制的，cgroup是容器的一组用来控制内核如何运行进程的相关属性集合。针对内存、CPU和各种设备都有对应的cgroup

默认情况下，pod运行没有cpu和内存的限额。这意味着系统中的任何pod将能够像执行该pod所在的节点一样，消耗足够多的cpu和内存。一般会针对某些应用的pod资源进行资源限制，这个资源限制是通过resources的requests和limits来实现

spec:
    containers:
    - image: xxxx
      imagePullPolicy: Always
      name : auth
      ports:
      - containerPort: 8888
        protocol: TCP
      resources:
        limits:
          cpu: "4"
          memory: 2Gi
      requests :
          cpu: 250m
          memory: 250Mi

requests要分配的资源，limits为最高请求的资源值。可以简单理解为初始值和最大值

资源限制 - 名称空间

# 1.计算资源配额
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
  namespace: spark-cluster
spec:
  hard:
    pods: "20"
    requests.cpu: "20"
    requests.memory: 100Gi
    limits.cpu: "40"
    limits.memory: 200Gi

# 2.配置对象数量配额限制
apiVersion: v1
kind: ResourceQuota
metadata:
  name: object-counts
  namespace: spark-cluster
spec:
  hard:
    configmaps: "10"
    persistentvolumeclaims: "4"
    replicationcontrollers: "20"
    secrets: "10"
    services: "10"
    services.loadbalancers: "2"

# 3.配置CPU和内存LimitRange
apiVersion: v1
kind: LimitRange
metadata:
  name: mem-limit-range
spec:
  limits:
  - default:
      memory: 50Gi
      cpu: 5
    defaultRequest:
      memory: 1Gi
      cpu: 1
      type: Container

# default 即limit的值
# defaultRequest 即request的值

访问prometheus

prometheus对应的nodeport端口为30200
http://masterIP:30200

prometheus web界面提供了基本的查询k8s集群中每个pod的cpu使用情况
sum by (pod_name)( rate(container_cpu_usage_seconds_total{image!=””, pod_name!=””}[1m] ) )

访问grafana

查看grafana服务暴露的端口号
kubectl get service -n monitoring | grep grafana
grafana NodePort 10.107.56.143 3000:30100/TCP 20h
http://masterIP:30100 默认admin/admin

使用Helm部署EFK平台

# 节点上的pod日志信息目录
/var/log/containers

cd /usr/local/install-k8s
mkdir efk && cd efk

# 添加Google incubator仓库
helm repo add incubator http://storage.googleapis.com/kubernetes-charts-incubator

# 部署Elasticsearch
kubectl create namespace efk
helm fetch incubator/elasticsearch
helm install --name els1 --namespace=efk -f values.yaml uncubator/elasticsearch
kubectl run cirror-${RANDOM} --rm -it --image=cirros -- /bin/sh
    curel Elasticsearch:Port/_cat/nodes
    
# 部署Fluentd
helm fetch stable/fluentd-elasticsearch
vim values.yaml # 更改其中 Elasticsearch 访问地址
helm install --name flul --namespace=efk -f values.yaml stable/fluentd-elasticsearch

# 部署kibana
helm fetch stable/kibana --version.14.8
helm install --name kibl --namespace=efk -f values.yaml stable/kibana --version 0.14.8

# 修改为NodePort，访问后可查看收集的日志
kubectl edit svc kib1-kibana -n efk

---

证书

# 查看证书
cd /etc/kubernetes/pki
openssl x509 -in apiserver.crt -text -noout（有效期1年）
openssl x509 -in ca.crt -text -noout（有效期10年）

1. go环境部署

   百度"go 中文社区" -> 下载 -> Linux
   或者wget
   wget https://dl.google.com/go/go1.12.7.linux-amd64.tar.gz
   tar -zxvf go…… -C /usr/local/
   vim /etc/profile
   	export PATH=$PATH:/usr/local/go/bin
   source /etc/profile
   go version

2. 下载源码

   mkdir /data && cd /data
   git clone https://github.com/kubernetes/kubernetes.git
   cd kubernetes/
   kubeadm version
   git checkout -b remotes/origin/release-1.15.1 v1.15.1

3. 修改kubeadm源码包更新证书策略

   vim staging/src/k8s.io/client-go/util/cert/cert.go # kubeamd1.14版本前
   vim cmd/kubeadm/app/util/pkiutil/pki_helpers.go # kubeadm1.14之后
   1.16之后查看kubernetes官网查看开发者手册应该修改哪个文件
   	const duration3650d = time.Hour * 24 * 365  *10
   	NotAfter:    time.Now().Add(duration3650d).UTC(),
   
   mkdir WHAT=cmd/kubeadm GOFLAGS=-v
   cp _output/bin/kubeadm /root/kubeadm-new

4. 更新kubeadm

   # 将kubeadm进行替换
   cp /usr/bin/kubeadm /usr/bin/kubeadm.old
   cp /root/kubeadm-new /usr/bin/kubeadm
   chmod a+x /usr/bin/kubeadm

5. 更新各节点证书至master节点

   cp -r /etc/kubernetes/pki /etc/kubernetes/pki.old
   cd /etc/kubernetes/pki
   kubeadm alpha certs renew all --config=/usr/local/install-k8s/core/kubeadm-config.yaml
   openssl x509 -in apiserver.crt -text -noout | grep Not

6. HA集群其余master节点证书更新

   #!/bin/bash
   
   masterNode="192.168.66.20 192.168.66.21"
   #for host in $masterNode}; do#scp /etc/kubernetes/pki/(ca.crt,ca.key,sa.key, sa.pub,front-proxy-ca.crt,front-proxy-ca, key)"$(USER}"@$host:/etc/kubernetes/pki/
   # scp /etc/kubernetes/pki/etcd/(ca.crt,ca.key) "root"@$host:/etc/kubernetes/pki/etcd
   # scp /etc/kubernetes/admin.conf "root"@$host:/etc/kubernetes/
   #done
   for host in $(CONTROL_PLANE_IPS}; do
       scp /etc/kubernetes/pki/{ca.crt,ca.key,sa.key,sa.pub,front-proxy-ca.crt,front-proxy-ca.key} "${USER}"@$host:/root/pki/
       scp /etc/kubernetes/pki/etcd/{ca.crt,ca.key} "root"@$host:/root/etcd
       scp /etc/kubernetes/admin.conf "root"@shost:/root/kubernetes/
   done