kubernetes configmap的作用类似传统环境中的配置中心。
当有一系列的服务，并且很类似，需要把它们配置文件抽离出来。原来的方案是添加一个agent端，实时地去监控文件的变化，以此达到文件重载配置文件的目的。
在kubernetes集群中，有一个资源对象configmap，它可以做到热更新。我们只需要把配置文件抽象出来，存储在configmap中。在使用的时候，可以使用环境变量，把环境变量变成命令的方式，也可以把它变成卷插件，以文件的方案进行调用。
需要特别强调的话，如果需要使用热更新这个特性的话，我们必须要以卷插件的方案使用才可以。
configmap有一个选项immutable，它的作用是判断当前configmap是否要开启我们所谓的热更新。如果此选项开启的话，那么代表我们不再对api-server发起对configmap变化的监听，可以减少更多的压力，也可以避免一些需求的更改或者恶意更改。
在我们确认configmap保存的数据不需要改变的时候，此选项建议开启。
configmap有一个特性是：明文。它所有的保存数据都是以明文的方案进行展示和使用的。这在某种情况下去考虑可能不太安全。资源对象secret可以解决这种问题。
secret的安全机制是基于编码而实现的，也叫基于编码的安全。 secret是基于base64编码实现的，编码不是加密，编码是可逆的，只需要编码的参照表就可以。
但是加密不是可逆的，尤其是非对称加密，可能加密和解密加密的密钥完全不同。
Secret用来保存敏感信息，比如密码、OAuth令牌和 ssh密钥、数据库的口令等。把这些信息放在secret中比放在pod的定义或者容器镜像中来说更加安全和灵活。
更加灵活的原因是secret支持热更新。
安全是因为它是非明文的，在调用的时候是看不到数据本身的。
为了安全，它还做了一些后续的动作配合和编码，来保证安全性。
Kubernetes通过仅仅将secret分发到需要访问secret的pod所在的机器节点来保障安全性。
secret只会存储在节点的内存中，用不写入物理存储，这样从节点删除secret时就不需要删除磁盘数据。磁盘是非易失性存储器，内存是易失性存储器。
从kubernetes 1.7版本开始，etcd会以加密形式存储secret，从一定程度上保证了secret的安全性，当然也可以把secret解密回来。也就是直接连接etcd，读取secret的对象信息，它不是一个明文的展示，可以通过一些手段把secret的密文给解密出来。解密方法是：
echo "$key" | base64 --decode
尽管secret的安全性在一直提升，但是不能当做唯一的方式去用，因为secret是可以解密的。
比如有一个数据库非常重要，拿到它的权限之后，危害非常大，可能能够把整个集群的所有服务的所有数据都获取到。如果只靠secret去做保护，还是比较危险的，还需要一些第三方的工具去做数据的加密和解密。
Secret只是进行编码和解码，并不是真正的非常安全的非对称加密。
Secret的分类：
①：Opaque 用户定义的任意数据
②：
kubernetes.io/service-account-auth 服务账号令牌
③：kubernetes.io/dockercfg ～/.dockercfg 文件的序列化形式
④：
kubernetes.io/dockerconfigjson ~/.docker/config.json 文件的序列化形式
⑤：kubernetes.io/basic-auth用于基本身份认证的凭据
⑥：kubernetes.io/ssh-auth 用于SSH身份认证的凭据
⑦：kubernetes.io/tls 用于TLS客户端或者服务端的数据
⑧：
bootstrap.kubernetes.io/auth 启动引导令牌数据
查看某个命名空间中的资源：
kubectl get all -n $namespace_name
鼓励的话语：为财聚，为利散！