Kubernetes之配置管理

前言：在k8s中，使用一个容器镜像来启动一个container，其实有很多需要配套的问题待解决：

• 不能把一些可变的配置写到镜像里，当这个配置需要变化的时候，可能需要我们重新编译一次镜像
• 一些敏感信息的存储和使用，比如token
• 容器要访问自身群集，比如访问 kube-apiserver，那么本身就有一个身份认证的问题
• 容器在节点上运行之后，它的资源需求
• 对于容器的安全管控，毕竟容器在节点上，它们是共享内核的
• 容器启动之前的一个前置条件检验。比如在容器启动之前需要确认DNS服务以及确认网络是否连通

那么这些其实就是一些前置的校验

一、Pod的配置管理

• 如下图所示
  
  • 可变配置就用 ConfigMap
  • 敏感信息是用 Secret
  • 身份认证是用 ServiceAccount 这几个独立的资源来实现的
  • 资源配置是用 Resources
  • 安全管控是用 SecurityContext
  • 前置校验是用 InitContainers 这几个在 spec 里面加的字段，来实现的这些配置管理

二、Secret与ConfigMap

1.Secret

• Secret是用来保存小片敏感数据的k8s资源，例如密码，token，或者秘钥。这类数据当然也可以存放在Pod或者镜像中，但是放在Secret中是为了更方便的控制如何使用数据，并减少暴露的风险
• 用户可以创建自己的secret，系统也会有自己的secret
• Pod需要先引用才能使用某个secret，Pod有2种方式来使用secret：作为volume的一个域被一个或多个容器挂载；在拉取镜像的时候被kubelet引用

2.ConfigMap

• 我们知道，在几乎所有的应用开发中，都会涉及到配置文件的变更，比如说在web的程序中，需要连接数据库，缓存甚至是队列等等
• 而我们的一个应用程序从写第一行代码开始，要经历开发环境、测试环境、预发布环境只到最终的线上环境
• 而每一个环境都要定义其独立的各种配置。如果不能很好的管理这些配置文件，运维工作将顿时变的无比的繁琐
• 为此业内的一些大公司专门开发了自己的一套配置管理中心，如360的Qcon，百度的disconf等
• kubernetes也提供了自己的一套方案，即ConfigMap。kubernetes通过ConfigMap来实现对容器中应用的配置管理

三、Secret解析

• Secret解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者Pod Spec中
• 用于加密数据并存放在Etcd中，让Pod的容器以挂载Volume方式访问
• Secret使用：
  • Volume
  • 环境变量
• 应用场景：凭据
• 功能：
  • 对数据进行加密并且进行保存参数
  • 能够实现数据卷的挂载

1.类型

• Secret有三种类型：
  • 1.Service Account：用来访问Kubernetes API，由Kubernetes自动创建，并且会自动挂载到Pod的/run/secrets/kubernetes.io/serviceaccount目录中
  • 2.Opaque：base64编码格式的Secret，用来存储密码、密钥等
  • 3.kubernetes.io/dockerconfigjson：用来存储私有docker registry的认证信息

2.Secret使用注意要点

• Secret 的文件大小限制
  • 这个跟 ConfigMap 一样，也是 1MB
• Secret 采用 base-64 编码
  • 它跟明文也没有太大区别
  • 所以说，如果有一些机密信息要用 Secret 来存储的话，还是要很慎重考虑。也就是说谁会来访问你这个集群，谁会来用你这个 Secret，还是要慎重考虑，因为它如果能够访问这个集群，就能拿到这个 Secret
  • 如果是对 Secret 敏感信息要求很高，对加密这块有很强的需求，推荐可以使用 Kubernetes 和开源的 vault做一个解决方案，来解决敏感信息的加密和权限管理
• Secret 读取的最佳实践
  • 建议不要用 list/watch，如果用 list/watch 操作的话，会把 namespace 下的所有 Secret 全部拉取下来，这样其实暴露了更多的信息
  • 推荐使用 GET 的方法，这样只获取你自己需要的那个 Secret

3.创建与使用

1）内建的Secrets

• 由ServiceAccou