1 Kubelet运行机制

Kubenetes集群中的每个Node节点都会启动一个Kubelet服务进程用于处理Master下发到该节点的任务，管理Pod及其中的容器
Kubelet进程在API Server上注册信息，定期向Master节点汇报Node资源情况，并通过cAdvise监控容器和节点资源

1.1 节点管理

Kubelet进程在启动时设置参数--register-node=true设置向APIServer主动注册节点信息
当设置非自动注册时，需要配置Node的资源信息以及给Kubelet指定API Server位置
Kubelet启动参数

--api-server    //设置api server位置
--kubeconfig    //设置访问api server的证书
--cloud-provider    //如何从云服务读取相关元数据
--node-status-update-frequency  //向api server报告的间隔时间，默认10s

1.2 Pod管理

非API Server方式创建的Pod称为Static Pod，Kubelet将Static Pod状态汇报给API Server，而后API Server为该Static Pod创建一个Mirror Pod与其相匹配
Kubelet监听etcd中所有对Pod的操作
Kubelet读取到创建和修改Pod任务处理：
1. 为该Pod创建一个数据目录
2. 从API Server读取该Pod清单
3. 为该Pod挂载外部卷(Extenal Volume)
4. 下载Pod用到的Secret
5. 检查已经运行在节点中的Pod，如果Pod没有容器或Pause容器没有启动则停止Pod中所有容器进程。如果Pod中有需要删除的容器则删除
6. 用Pause镜像为每个Pod创建一个容器，其用于接管Pod中所有其他容器的网络
7. 为Pod中的每个容器做如下处理：
  - 校验容器的hash值
  - 如果容器被中止且容器没有指定restartPolicy则不做任何处理
  - 调用Docker Client下载容器镜像，运行容器

1.3 容器健康检查

LivenessProbe探针用于判断容器是否健康，如果不健康则Kubelet将删除该容器并根据重启策略进行处理，实现方式有：
- ExecAction：在容器内部执行一个命令如果命令退出状态码为0则容器健康
- TCPSocketAction：通过容器IP和端口执行TCP检测
- HTTPGetAction：通过容器IP和端口及路径调用HTTP Get方法，判断响应的状态码
Readiness探针用于判断容器是否启动完成，且准备接受请求。如果检测失败则Pod状态将被修改，Endpoint Controller将从Service的Endpoint中删除包含该容器所在Pod的条目

2 安全机制原理

集群的安全性必须考虑如下几个目标：

保证容器与其所在宿主机的隔离
限制容器给基础设施及其他容器带来的消极影响的能力
最小权限原则——合理限制所有组件的权限
明确组件间边界的划分
划分普通用户和管理员用户
在必要时允许将管理员权限赋给普通用户
允许拥有Secret数据(Keys,Certs,Passwords)的应用在集群中运行

2.1 Authentication认证

Kubelet对API的调用使用如下方式：

CA，使用HTTPS方式，在API Server启动参数--client_ca_file=SOMEFILE 设定CA的认证授权文件
Token，通过API Server启动参数--token_auth_file=SOMEFILE 指定存储Token的文件。Token文件格式为一个包含三列的CSV文件，该文件第一列为Token，第二列为用户名，第三列为用户UID。同时访问时HTTP请求头中的Authorization域必须包含Bearer SOMETOKEN指定该用户的Token
HTTP Base，通过API Server启动参数--basic_auth_file=SOMEFILE 指定存储用户和密码的基本认证文件。该文件为CSV文件，第一列为密码，第二列为用户名，第三列为UID。HTTP请求头中的Authorization域必须包含Basic BASE64ENCODEDUSER:PASSWORD 即base64加密后的用户名和密码

2.2 Authorization授权

授权(Authorization)是认证(Authentication)后的一个独立步骤，作用于API Server主要端口的所有HTTP访问
授权流程通过访问策略比较请求上下文属性，通过API访问资源之前必须通过访问策略进行校验，配置如下：

--authorization_mode=AlwaysDeny     //表示拒绝所有请求
--authorization_mode=AlwaysAllow    //接受所有请求
--authorization_mode=ABAC           //使用用户配置的授权策略去管理访问API Server的请求，ABAC(Attribute-Based Access Control)基于属性的访问控制

Kubernetes中HTTP请求包含如下4个能被授权进程识别的属性：
1. 用户名
2. 是否是只读请求(REST中的GET操作均为只读)
3. 被访问的是哪一类资源
4. 被访问对象所属Namespace
如果请求中不带对应的某个属性则默认零值
选择ABAC模式则需要在API Server启动时设置--authorization_polic_file=SOMEFIME 指定授权策略的JSON文件，文件的每一行为一个JSON的Map对象且不包含List，主要包含以下属性：
- user(用户名)，字符串类型
- readonly，布尔型，为true时表示只接受GET访问
- resource，字符串来自于URL的资源
- namespace，字符串表明该策略允许访问的某个Namespace
授权文件中一个未设置的属性表示匹配HTTP请求中该属性的任何值
对请求的4个属性和授权文件的策略对象逐个匹配，如果至少有一个策略对象被匹配上则该请求被授权通过

2.3 Admission Control准入控制

用于拦截所有经过认证和鉴权后的访问API Server请求的可插入代码，这些插件运行在API Server进程中，每个Admission Control插件按照配置顺序执行，如果其中任意一个插件拒绝该请求，则API Server将拒绝请求

配置API Server启动参数admission_control,该参数中加入需要的插件列表，逗号隔开

2.4 Secret私密凭据

主要作用是保管私密数据，如密码、OAuth Token、SSH Keys等，将这些私密信息放在Secret对象比直接放入Pod或Docker Image中要安全。

如果Pod指定了Service Account则该Pod自动添加包含凭证信息的Secrets，用于访问API Server和下载Image

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:   //全部是Base64编码值
  password: 123 //Base64编码值
  username: 123

Secret被使用的方式：
- 在创建Pod时通过为Pod指定Service Account来自动使用该Secret
- 通过挂载Secret到Pod，spec.volumes.secret指定
- 在创建Pod时，指定Pod的spec.ImagePullSecret来引用
目前Secret只支持API Server创建
在使用Mount方式挂载Secret时，容器中Secret的data域中的各个key值作为目录中的文件，value值被Base64编码后存储在相应的文件中
通过API Server创建Pod时不会校验引用的Secret是否存在，只有当Pod被调度时将试着去获取Secret，如果此时获取不到则将按一定时间间隔定期重试，并发送一个Event解释Pod没启动的原因
Secret包括Opaque、ServiceAccount和Dockercfg三种类型

2.5 Service Account

Service Account是多个Secret的集合，包含普通Secret用于访问API Server和imagePullSecret用于下载容器镜像

apiVersion: v1
kind: ServiceAccount
metadata:
  name: myserviceaccount
secrets:
  -  kind: Secret
     name: secret1
     apiVersion: v1
  -  kind: Secret
     name: secret2
     apiVersion: v1
  imagePullSecrets:
    -  name: secret1

如果创建Pod时没指定ServiceAccount则将在对应Namespace中制定一个名为default的ServiceAccount

https://www.cnblogs.com/suolu/p/6841848.html

《Kubernetes权威指南》——运维技巧

1 Node的隔离和恢复

方法1：
1. 创建新的Node配置文件指定spec.unschedulable: true
2. 通过kubectl replace完成对Node的状态修改
```
    kubectl replace -f xxx.yaml
```
1. 此时Node的状态增加一项SchedulingDisabled，后续创建Pod将不会对该Node进行调度

方法2：

    kubectl patch node name -p '{"spec":{"unschedulable":true}}'

将Node脱离调度后，Node上运行的Pod不会自动停止
将Node重新纳入集群只需要将spec.unschedulable: false 可用上述两种方法

2 Node扩容

在新Node上安装Docker、Kubelet和kube-proxy服务
在Kubelet和kube-proxy的启动参数中的Master URL指定为当前Master地址

3 Pod动态扩容和缩放

通过kubectl scale rc 调整副本数

kubectl scale rc name --replicas=3

4 更新资源对象的Label

kubectl label pod name role=backend     #加一个role=backend的label

kubectl label pod name role-    #删除key为role的label

kubectl label pod name role=master --overwrite  #修改role的label

5 将Pod调度到指定的Node

通过Node的label与Pod的nodeSelector匹配实现
1. 给Node设置label
2. Pod的配置文件中spec.nodeSelector 中设置与Node中相同的label

6 应用的滚动升级

Kubernetes提供rolling-update功能实现
该命令创建一个新的RC然后自动控制旧的RC中的Pod数逐渐减少到0，同时新的RC中Pod从0逐渐增加
必须是相同Namespace中的RC
方法一使用配置文件，新的RC配置文件需要注意的地方：
- RC名字不能与旧的相同
- selector中至少有一个Label与旧RC的Label不同
```
    kubectl rolling-update 旧RC -f 配置文件
```
方法二不使用配置文件，指定新版镜像名实现
```
    kubectl rolling-update RC名 --image=新镜像名
```
更新过程有误可以通过kubectl rolling-update --rollback 实现Pod版本回滚
```
     kubectl rolling-update RC名 --image=新镜像名 --rollback
```

《Kubernetes权威指南》Kubelet运行机制与安全机制，k8s运维技巧