Kubernetes学习（六）配置管理ConfigMap

ConfigMap

ConfigMap是一种API对象，用来将非机密性数据保存到键值对中。使用时可以用作环境变量、命令行参数或者存储卷中的配置文件。

ConfigMap将配置信息和容器镜像解耦，便于应用修改配置，当需要存储机密数据时可以使用Secret对象。

注意：ConfigMap并不提供保密或加密功能。如果想存储加密数据，请使用Secret，或者使用其他第三方工具来保证数据的私密性。

ConfigMap配置Pod中的容器：

1、容器entrypoint的命令行参数

2、容器的环境变量

3、在只读卷里面添加一个文件，让应用来读取

4、编写代码在pod中运行，使用Kubernetes API来读取ConfigMap

这些不同的方法适用于不同的数据使用方式。对前三个方法，kubelet使用ConfigMap中的数据在Pod中启动容器

第四种方法必须编写代码才能服务ConfigMap和数据。然而，由于是直接使用Kubernetes API，因此是要ConfigMap发生更改，应用能够通过订阅来获取更新。通过直接进入Kubernetes API，可以获取到不同命名空间里的ConfigMap。

示例：通过环境变量方式使用ConfigMap

使用envForm ，可以实现在Pod环境中将ConfigMap中定义的key=value自动生成为环境变量

apiVersion: v1
kind: Pod
metadata:
  name: myapp
  labels:
    name: myapp
spec:
  containers:
  - name: myapp
    image: busybox
    command: ["/bin/sh","-c","env"]
    envFrom:
      - configMapRef:
          name: my-db-config
    resources:
      limits:
        memory: "128Mi"
        cpu: "500m"

[root@master k8s]# kubectl logs myapp
KUBERNETES_SERVICE_PORT=443
KUBERNETES_PORT=tcp://10.96.0.1:443
HOSTNAME=myapp
SHLVL=1
username=root
HOME=/root
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
KUBERNETES_PORT_443_TCP_PORT=443
password=root
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_SERVICE_HOST=10.96.0.1
PWD=/
db-url=localhost

注意：环境变量名称收POSIX命名规范约束，不能以数字开头。如果配置中包含非法字符，系统将会跳过这条环境变量的创建，并记录一个Event用来提醒用户环境变量无法生成，但并不阻止Pod的启动。

Secret

Secret对象类型用来存放敏感信息，例如密码、OAuth令牌和SSH秘钥。将这些信息放在Secret中比放在Pod的定义或容器镜像中更加安全和灵活。

Pod可以有三种方式来使用Secret：

1、作为挂载到一个或多个容器上的卷中的文件

2、作为容器的环境变量

3、由kubelet在为Pod拉取镜像时使用

示例：

kubectl create secret generic root-user-pass --form-file=./login.txt

[root@master k8s]# kubectl describe  secret root-user-pass
Name:         root-user-pass
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
login.txt:  12 bytes
[root@master k8s]#

默认情况下，kubectl get 和kubectl describe 不显示密码的内容，这是为了防止机密被意外的暴露给旁观者或者存储在终端日志中。

Kubernetes配置管理的最佳实践

普通配置

• 定义配置时，请指定最新的稳定的API版本
• 在推送到集群之前，配置文件应存储在版本控制中。这允许用户在必要的时候快速回滚配置更改，它还有助于集群重建和恢复。
• 使用YAML而不是JSON编写配置文件，虽然这些格式几乎可以在任意场景中替换，但YAML对用户更加友好
• 只要有意义，就将相关对象分组到一个文件中，一个文件通常比几个文件更容易管理

“Naked” Pods与ReplicaSet，Deployment和Jobs

如果可能，不要使用独立的Pods（即未绑定到ReplicaSet或Deployment的Pod）。如果节点发生故障，将不会重新调度Pods。

Deployment会创建一个ReplicaSet以确保所需数量的Pod始终可用，并指定替换Pod的策略，除了一些显示的restartPolicy:Never场景之外，几乎总是优先考虑直接创建Pod。Job可能也是合适的。

服务

在创建相应的后端工作负载（Deployment或ReplicaSet），以及在需要访问它的任何工作负载之前创建服务。当Kubernetes启动容器时，它提供指向启动容器时正在运行的所有服务的环境变量。例如，如果存在名为foo的服务，则所有容器将在其初始环境变量中获得以下变量：

FOO_SERVICE_HOST=<the host the Service is running on> FOO_SERVICE_PORT=<the port the Service is running on>

这确实意味着顺序上的要求：必须在Pod本身被创建之前创建Pod想要访问的Service，否则环境变量不会生效，DNS没有此限制。

• 一个可选的集群插件是DNS服务器（尽管强烈推荐）。DNS服务器为新的Service监视Kubernetes API，并未每个创建一组DNS记录。如果在整个集群中启用了DNS，则所有Pod能够自动对Service进行名称解析。
• 除非绝对必要，否则不要为Pod指定hostPort。将Pod绑定到hostPort时，它会限制Pod可以调度的位置数，应为每个组合必须是唯一的。如果没有明确指定hostIP'和protocol，Kubernetes会使用0.0.0.0作为默认的hostIP和TCP作为默认protocol。如果只需要访问端口进行调试，则可以使用apiservice proxy或kubectl port-forward。

• 如果明确需要在节点上公开Pod的端口，请在使用hostPort之前考虑使用NodePort服务
• 避免使用hostNetwork，原因与hostPort相同
• 当不需要使用kube-proxy负载均衡时，使用无头服务（ClusterIP被设置为None）比便于服务发现

标签

• 定义并使用标签来识别应用或Deployment的语义属性，可以使用这些标签来为其他资源选择合适的Pod，例如，一个选择所有tier:frontend Pod的服务，或者app：myapp的所有phase：test组件
• 通过从选择器中省略特定发行版的标签，可以使服务跨越多个Deployment。Deployment可以在不停机的情况下轻松更新正在运行的服务。
• Deployment描述了对象的期望状态，并且如果对该规范的更改被成功应用，则Deployment控制器以受控速率将实际状态更改为期望状态。

容器镜像

• imagePullPolicy和镜像标签会影响kubectl何时尝试拉取指定的镜像
• imagePullPolicy：ifNotPresent：仅当镜像在本地不存在时才被拉取
• imagePullPolicy：Always：每次启动Pod的时候都会拉取镜像
• imagePullPolicy省略时，镜像标签为latest或不存在，使用Always值
• imagePullPolicy省略时，指定镜像标签并且不是latest时，使用ifNotPresent值
• imagePullPolicy：Never：假设镜像已经存在本地，不会尝试拉取镜像

注意：在生产中部署容器时，应避免使用latest标记，这样更难跟踪正在运行的镜像版本，并且更难正确回滚。底层镜像驱动程序的缓存语义能够使即便imagePullPolicy：Always的配置也更高效。例如，对于Docker，如果镜像已经存在，则拉取尝试很快，因为镜像层都被缓存并且不需要下载。

kubectl

使用kubectl apply -f，它在给定的所有.yaml.yml和json文件中查找Kubernetes配置，并将其传递给apply

使用标签选择器进行get和delete操作，而不是特定的对象名称。