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

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 安全机制原理

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

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

2.1 Authentication认证

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

  1. CA,使用HTTPS方式,在API Server启动参数--client_ca_file=SOMEFILE 设定CA的认证授权文件
  2. Token,通过API Server启动参数--token_auth_file=SOMEFILE 指定存储Token的文件。Token文件格式为一个包含三列的CSV文件,该文件第一列为Token,第二列为用户名,第三列为用户UID。同时访问时HTTP请求头中的Authorization域必须包含Bearer SOMETOKEN指定该用户的Token
  3. 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
展开阅读全文

没有更多推荐了,返回首页