08 Kubernetes应用配置管理

news2024/11/25 18:45:28

课件

在这里插入图片描述

在 Kubernetes 中，secret 是一种用于存储敏感信息的对象。Kubernetes 支持以下三种类型的 secret：

Opaque：这是默认的 secret 类型，可以用于存储任何类型的数据，包括字符串、二进制数据等。
Service Account：这种类型的 secret 是自动生成的，用于存储与 service account 相关的信息，例如 API token 等。
TLS：这种类型的 secret 用于存储 TLS 证书和私钥，用于加密通信。

这三种类型的 secret 在使用方式和配置上略有不同，但都提供了将敏感信息存储在 Kubernetes 集群中的方便方式，同时也提供了一些安全性措施来确保这些信息不会被未授权的人员访问或泄露。

在这里插入图片描述

Pod可以使用Secret存储和访问敏感信息，例如密码、密钥和证书等。以下是两种Pod使用Secret的方式：

Volume方式：

在Pod的定义中声明一个volume，并将Secret挂载到该volume中。然后，可以将该volume挂载到容器中的特定路径。以下是一个使用Volume方式的Pod示例：

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    volumeMounts:
    - name: secret-volume
      mountPath: /etc/my-secret
      readOnly: true
  volumes:
  - name: secret-volume
    secret:
      secretName: my-secret

在上面的示例中，Pod声明了一个名为secret-volume的volume，并使用my-secret Secret将其填充。然后，该volume被挂载到容器的/etc/my-secret路径上。

Environment Variable方式：

可以将Secret的值作为环境变量注入到容器中。在Pod的定义中，使用env字段声明一个或多个环境变量，并使用valueFrom字段从Secret中获取值。以下是一个使用Environment Variable方式的Pod示例：

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    env:
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: my-secret
          key: db-password

在上面的示例中，Pod声明了一个名为DB_PASSWORD的环境变量，并使用my-secret Secret的db-password键从中获取值。容器可以使用$DB_PASSWORD引用该环境变量。

需要注意的是，Secret中的数据是以Base64编码的形式存储的。因此，在使用Secret之前，需要将其进行解码。
在这里插入图片描述
为Secret设置RBAC可以确保只有具有特定权限的用户或实体才能访问该Secret。以下是为Secret设置RBAC的步骤：

创建一个命名空间（如果您还没有创建）：

kubectl create namespace <namespace-name>

创建一个ServiceAccount：

kubectl create sa <service-account-name> -n <namespace-name>

创建一个Role或ClusterRole：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: <role-name>
  namespace: <namespace-name>
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

将Role或ClusterRole绑定到ServiceAccount：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: <role-binding-name>
  namespace: <namespace-name>
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: <role-name>
subjects:
- kind: ServiceAccount
  name: <service-account-name>
  namespace: <namespace-name>

将Secret注入到Pod中：

apiVersion: v1
kind: Pod
metadata:
  name: <pod-name>
spec:
  serviceAccountName: <service-account-name>
  containers:
  - name: <container-name>
    image: <image-name>
    volumeMounts:
    - name: <volume-name>
      mountPath: <mount-path>
  volumes:
  - name: <volume-name>
    secret:
      secretName: <secret-name>

请注意，这些步骤中的名称需要替换为您自己的名称。此外，您可以根据需要更改Role或ClusterRole的规则，以便控制对Secret的访问权限。
在这里插入图片描述

自测题

在这里插入图片描述
是的，Pod只能使用相同命名空间（namespace）中的ConfigMap。这是因为Kubernetes中的命名空间提供了一种隔离资源的方式，使得不同的应用程序或团队可以在同一集群中共享资源，同时保持彼此的独立性。

当创建ConfigMap时，可以指定其所属的命名空间。如果未指定命名空间，则默认为创建ConfigMap的命名空间。同样，当创建Pod时，如果未指定命名空间，则默认为创建Pod的命名空间。

如果您想让Pod使用其他命名空间中的ConfigMap，可以使用Kubernetes中的跨命名空间引用（cross-namespace referencing）。要实现这一点，可以在Pod的定义中使用ConfigMap的完全限定名称（fully qualified name），例如my-configmap.my-namespace，其中my-configmap是ConfigMap的名称，my-namespace是ConfigMap所属的命名空间。

但是，跨命名空间引用通常不是推荐的做法，因为这会破坏命名空间提供的隔离性。相反，建议将相关的ConfigMap和Pod都放在同一命名空间中，以确保资源的隔离和安全。
在这里插入图片描述