Kubernetes配置管理（kubernetes）

实验环境：

在所有节点上拉取镜像；然后把资源清单拉取到第一个master节点上；

同步会话，导入镜像：

configmap/secret

配置文件的映射

变量：

基于valuefrom的方式 cm--》pod

特点：变量的名称可以和之前的不同

可以有选择性的选择--部分变量

基于envfrom

变量的名称和初始名称相同

将cm中的所有变量都引入进pod

字符值

etcd

配置文件 cm pod

数据量小于1M

1：先创建cm，再应用。

2：pod引用的键要存在于cm。

3：基于envFrom的方式，将变量映射到pod，如果你指定的变量不存在于cm中，会无视它。

4：pod和cm需要在相同的命名空间

先创建一个目录；

然后进入到这个目录中进行测试：

针对目录创建一个configmap；

且注意，cm受到命名空间的隔离，名字不能重复。

如何针对文件创建configmap；

创建的时候指定到文件即可；

但是可以查看，新创建的文件不会加入到已创建的cm中；

第二种创建的方式：带有key的方式；

在路径的前面加上名称，就可以为该文件起名字；

以上演示了针对目录及针对文件的创建，下面演示针对多个文件进行创建；

写两个from即可；

如何将变量创建；

第一种可以在生成pod的时候指定变量字段；

第二种就是以创建cm的方式；

创建出来：

如何将字符值创建到容器中；

如何删除configmap：

如何放到pod中；

先创建一个字符值的configmap；

然后打开一个已经编写好的yaml文件；

顶部声明

• apiVersion: v1：这指定了使用Kubernetes API的版本号。v1是Kubernetes中最常用的API版本之一，支持核心Kubernetes对象，如Pods、Services等。

• kind: Pod：这表示我们正在定义一个Pod对象。Pod是Kubernetes中能够创建和管理容器的最小部署单元。

Pod的元数据（metadata）

• name: env-valuefrom：这是Pod的名称，Kubernetes集群中的每个资源都必须有一个唯一的名称。

Pod的规格（spec）

Pod的规格定义了Pod中容器的详细配置。

• containers：这是一个列表，定义了Pod中将要运行的容器。在这个例子中，我们只有一个容器。

  • name: env-valuefrom：这是容器的名称。

  • image: busybox:v1：这指定了容器将使用的镜像。在这个例子中，它使用busybox镜像的v1版本，这是一个非常小的Linux镜像，常用于测试。

  • command: [ "/bin/sh","-c","env" ]：这指定了容器启动时要执行的命令。在这个例子中，它使用/bin/sh（一个shell）来执行env命令，这会列出容器中的所有环境变量。

• env：这是一个列表，用于定义要注入到容器中的环境变量。

  • 第一个环境变量my-name01的值来源于ConfigMap对象spec-config-2中的name1键。

  • 第二个环境变量my-name02的值同样来源于ConfigMap对象spec-config-2中的name2键。

  • 这里使用了valueFrom字段，特别是configMapKeyRef，它允许Pod从ConfigMap中读取键值对作为环境变量的值。这是配置容器以从Kubernetes资源中获取配置信息的常用方法。

• restartPolicy: Never：这指定了Pod的重启策略。Never表示Pod一旦终止（无论是成功还是失败），都不会自动重启。这是用于运行一次性任务的Pod（如批处理作业）的常用策略。

总结

这个YAML文件定义了一个名为env-valuefrom的Pod，该Pod包含一个容器，该容器在启动时运行env命令来列出其环境变量。其中两个环境变量（my-name01和my-name02）的值是从名为spec-config-2的ConfigMap中读取的，分别对应于该ConfigMap中的name1和name2键。这种配置方法允许Pod以动态方式从Kubernetes资源中获取配置信息，提高了配置的灵活性和可管理性。

将这个pod创建出来：

由于yaml文件中已经指定在创建pod的时候执行env命令，所以不必登录进去；

查看日志即可；

查看关于env的yaml文件；

• apiVersion: v1：指定了Kubernetes API的版本为v1。

• kind: Pod：声明这个YAML文件定义的是一个Pod资源。

• metadata：包含了Pod的元数据。

  • name: env-envfrom：Pod的名称被设置为env-envfrom。

• spec：定义了Pod的规格说明。

  • containers：列表中包含了一个或多个容器定义。

    • name: env-envfrom：容器的名称被设置为与Pod相同的名称，即env-envfrom。

    • image: busybox:v1：指定容器使用的镜像为busybox的v1版本。

    • command: [ "/bin/sh","-c","env" ]：容器启动时执行的命令。这里，它使用/bin/sh shell来执行env命令，该命令会列出容器中的所有环境变量。

    • envFrom：这是一个列表，用于从资源（如ConfigMap）中批量添加环境变量到容器中。

      • configMapRef：指示envFrom字段应该从哪个ConfigMap中读取环境变量。

        • name: spec-config-2：指定了ConfigMap的名称为spec-config-2。这意味着Pod中的容器将从spec-config-2 ConfigMap中读取所有键值对，并将它们作为环境变量添加到容器中。

• restartPolicy: Never：指定了Pod的重启策略为Never，即Pod一旦终止，就不会自动重启。

创建一个cm；

然后再尝试将cm放入到pod中；

• apiVersion: v1：指定了Kubernetes API的版本为v1，这是Pod资源的基本版本。

• kind: Pod：声明了这是一个Pod资源。

• metadata：包含了Pod的元数据。

  • name: dapi-test1-pod：Pod的名称被设置为dapi-test1-pod。

• spec：定义了Pod的规格说明。

  • containers：列表中包含了一个或多个容器定义。

    • name: dapi-test1-pod：容器的名称被设置为与Pod相同的名称，但通常建议为容器指定更具描述性的名称。

    • image: kubeguide/tomcat-app:v1：指定容器使用的镜像为kubeguide/tomcat-app的v1版本。

    • ports：定义了容器内部暴露的端口。

      • containerPort: 8080：表示容器内的Tomcat应用监听在8080端口上。

    • volumeMounts：定义了容器内的挂载点，用于挂载卷（Volumes）到容器内的指定路径。

      • name: config-volume：指定了卷的名称为config-volume。

      • mountPath: /etc/conf：指定了卷在容器内的挂载路径为/etc/conf。

• volumes：定义了Pod中可用的卷（Volumes）。

  • name: config-volume：定义了卷的名称为config-volume，这与上面volumeMounts中引用的卷名称相匹配。

  • configMap：指定了这个卷是由ConfigMap创建的。

    • name: spec-config02：指定了ConfigMap的名称为spec-config02。Kubernetes将从这个ConfigMap中读取数据并将其挂载到容器中。

    • items：这是一个可选字段，用于从ConfigMap中选择性地挂载特定的键。然而，在您的YAML中，items字段后面没有给出具体的键名或路径映射，这通常意味着您想要挂载ConfigMap中的所有数据，或者您的YAML文件在这里被截断了。如果确实需要选择性地挂载数据，您应该在这里列出ConfigMap中的键和它们应该被挂载到容器内的哪个路径（使用key: path格式）。

创建出来，然后登录到容器中。

验证：

假使cm中有多个文件，但是只想调用指定的文件，就可以参考一下yaml文件。

apiVersion: v1

这指定了YAML文件使用的Kubernetes API的版本，这里是v1，表示使用Kubernetes的核心API的第一个稳定版本。

kind: Pod

这指定了YAML文件定义的资源类型为Pod。Pod是Kubernetes中可以创建和管理的最小部署单元，它通常封装了一个或多个容器。

metadata

metadata部分包含了Pod的元数据，如名称、标签等。

• name: dapi-test2-pod：这定义了Pod的名称为dapi-test2-pod。

spec

spec部分定义了Pod的规格说明，包括容器列表、存储卷等。

• containers: 这是一个容器列表，每个容器都有它的配置。

  • name: 容器的名称为dapi-test2-pod，这里容器名称和Pod名称相同，但在实际使用中，容器名称可以不同。

  • image: 指定了容器使用的镜像，这里是kubeguide/tomcat-app:v1。

  • ports: 定义了容器需要暴露的端口。这里暴露了8080端口，但请注意，这仅表示容器内部端口，要使这个端口对外部可见，还需要配置Service等资源。

  • volumeMounts: 定义了如何将存储卷挂载到容器内部。

    • name: 挂载的存储卷名称为config-volume。

    • mountPath: 存储卷在容器内部的挂载路径为/etc/conf。

• volumes: 定义了Pod中使用的存储卷。

  • name: 存储卷的名称为config-volume，与上面volumeMounts中引用的名称相同。

  • configMap: 表示这个存储卷来自于一个ConfigMap。

    • name: ConfigMap的名称为spec-config02。

    • items: 定义了ConfigMap中哪些键值对应该被挂载到Pod中，以及它们在容器内部的文件名。

      • key: app1.conf 和 path: app1.cfg：表示ConfigMap中名为app1.conf的键的值将被挂载到容器中的/etc/conf/app1.cfg文件。

      • key: app2.conf 和 path: app2.cfg：类似地，app2.conf的键的值将被挂载到/etc/conf/app2.cfg文件。

针对文件修改权限；

apiVersion: v1

这指定了YAML文件使用的Kubernetes API版本为v1，这是Kubernetes核心API的稳定版本。

kind: Pod

这表示YAML文件定义的资源类型为Pod。

metadata

metadata部分包含了Pod的元数据。

• name: dapi-test3-pod：定义了Pod的名称为dapi-test3-pod。

spec

spec部分定义了Pod的规格说明。

• containers: 这是一个容器列表，这里只有一个容器。

  • name: 容器的名称为dapi-test3-pod。

  • image: 指定了容器使用的镜像为kubeguide/tomcat-app:v1。

  • ports: 定义了容器需要暴露的端口，这里是8080端口。但请注意，这仅表示容器内部端口，要使这个端口对外部可见，还需要配置Service等资源。

  • volumeMounts: 定义了如何将存储卷挂载到容器内部。

    • name: 挂载的存储卷名称为config-volume。

    • mountPath: 存储卷在容器内部的挂载路径为/etc/conf。

• volumes: 定义了Pod中使用的存储卷。

  • name: 存储卷的名称为config-volume，与上面volumeMounts中引用的名称相同。

  • configMap: 表示这个存储卷来自于一个ConfigMap。

    • name: ConfigMap的名称为spec-config02。

    • items: 定义了ConfigMap中哪些键值对应该被挂载到Pod中，以及它们在容器内部的文件名和文件权限。

      • key: app1.conf 和 path: app1.cfg：表示ConfigMap中名为app1.conf的键的值将被挂载到容器中的/etc/conf/app1.cfg文件。

        • mode: 0644：指定了文件在容器内的权限为644（即文件所有者具有读写权限，而组用户和其他用户只有读权限）。

      • key: app2.conf 和 path: app2.cfg：类似地，app2.conf的键的值将被挂载到/etc/conf/app2.cfg文件。但这里没有为app2.cfg指定mode，因此它将使用defaultMode（如果指定了的话）。

    • defaultMode: 这是一个可选字段，用于为未显式指定mode的挂载文件设置默认权限。在这个例子中，它被设置为0666（即所有用户都具有读写权限，但请注意，在Unix和类Unix系统中，可执行权限位（如7的末尾位）对于非可执行文件通常没有意义，因此这里的0666实际上意味着所有用户都有读写权限，但没有执行权限）。然而，需要注意的是，并不是所有的Kubernetes环境都支持在ConfigMap挂载时设置文件权限，这取决于你使用的Kubernetes版本和底层存储系统。

请注意，虽然defaultMode被设置为0666，但由于app1.cfg已经显式设置了mode: 0644，因此app1.cfg的权限将是0644，而app2.cfg（如果没有其他配置覆盖）将继承defaultMode的值（如果环境支持的话）。但是，如之前所述，defaultMode的支持可能因环境而异。