deployment.yaml 中的环境与命名空间答案

【问题标题】：environment vs namespace in deployment.yamldeployment.yaml 中的环境与命名空间
【发布时间】：2021-02-18 19:27:33
【问题描述】：

我正在查看一些较旧的deployment.yaml 文件，我对environment: 的使用感到好奇。

这是上下文：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: client-deployment-dev
  # namespace: development        # wouldn't this accomplish the same thing?
spec:
  replicas: 1
  revisionHistoryLimit: 5
  selector:
    matchLabels:
      component: client
      environment: development       #here
  template:
    metadata:
      labels:
        component: client
        environment: development      #here
    spec:
      containers:
        - name: client
          image: client
          ports:
            - containerPort: 3000
          env:
          - name: DOMAIN
            valueFrom:
              secretKeyRef:
                name: app-dev-secrets
                key: DOMAIN

production 和 staging 相似：environment: staging 和 environment: production。

这显然使环境保持分离并防止 kubectl apply -f ... 定位错误的环境（即意外地将开发配置应用于生产）。

但是使用namespace: development、namespace: staging 和namespace: production 不会也能完成同样的事情吗？是否有一个用例来使用另一个？

我想使用 environment 的一个好处是您可以将所有内容放在 default 命名空间中，同时保持 Pod 分离？

【问题讨论】：

是的，您可以为每个环境拥有一个单独的命名空间。随心所欲地使用标签——这一切都取决于你想如何组织事物。有些还使用单独的集群进行生产。

标签： kubernetes

【解决方案1】：

TL;博士；

您指的是两个完全不同的 Kubernetes 对象，它们是 Namespace 和 Labels/Selectors

命名空间

Kubernetes 支持由同一个物理集群支持的多个虚拟集群。这些虚拟集群称为命名空间。

为什么使用 Kubernetes 命名空间？这个问题的答案在What is a Kubernetes Namespace? 文章中有很好的描述。

允许团队或项目存在于自己的虚拟集群中，而不必担心影响彼此的工作。

通过将用户和进程限制在某些命名空间中来增强基于角色的访问控制 (RBAC)。

通过资源配额在多个团队和用户之间分配集群资源。

提供一种分离容器化应用程序的开发、测试和部署的简单方法，使整个生命周期都在同一个集群上进行。

简而言之，命名空间允许您分隔对象。除了default，还有一些namespaces，比如由Kubernetes 系统创建的kube-system。在 namespace 中，您有像 kube-dns 或 kube-proxy 这样的系统 pod，它们负责网络配置。

另一个例子是许多Helm Charts被配置为在不同的namesapce而不是default中部署对象。

部分资源是namespaced:

$ kubectl api-resources
NAME                              SHORTNAMES   APIVERSION                        NAMESPACED   KIND
bindings                                       v1                                true         Binding
componentstatuses                 cs           v1                                false        ComponentStatus
configmaps                        cm           v1                                true         ConfigMap
endpoints                         ep           v1                                true         Endpoints
...

这意味着他们需要定义命名空间，否则你会发现找不到资源的错误。

$ kubectl get po
No resources found in default namespace.
$ kubectl get pod --namespace kube-system
NAME                                                        READY   STATUS    RESTARTS   AGE
event-exporter-gke-666b7ffbf7-kjcn2                         2/2     Running   0          2m42s
fluentbit-gke-njk6d                                         2/2     Running   0          2m30s
fluentbit-gke-wlwsp                                         2/2     Running   0          2m29s
...

如果您不指定namespace，Kubernetes 将在所有情况下（创建、删除、获取等）使用default 命名空间。

您可以在namespace 中配置Quota 来限制数量或pod、服务等。

$ kubectl describe namespaces
Name:         default
Labels:       <none>
Annotations:  <none>
Status:       Active

Resource Quotas
 Name:                       gke-resource-quotas
 Resource                    Used  Hard
 --------                    ---   ---
 count/ingresses.extensions  0     100
 count/jobs.batch            0     5k
 pods                        0     1500
 services                    1     500

用例

当您删除namespace 时，您将删除该特定namespace 中的所有对象。
如果您将所有pods 放在一个namespace 中，$ kubectl delete pod --all 之类的命令将删除所有 pod。如果您将它们以namespace 分隔，它将从一个特定的namespace 中删除所有pods。

标签/选择器

标签是附加到对象（例如 pod）的键/值对。标签旨在用于指定对用户有意义且相关的对象的标识属性，但不直接暗示核心系统的语义。标签可用于组织和选择对象的子集。

Labels / Selectors 常用来连接Application with Services。部署和服务具有相同的labels/selectors，因此它们是connected。

用例

您已经测试了一些特定的软件，并且您使用了 2 个标签为 env: prod、app: nginx 和 2 个标签为 env: dev 和 app: nginx 的 pod。现在您可以删除具有特定 label 的 pod。

$ kubectl get po --show-labels
NAME     READY   STATUS    RESTARTS   AGE   LABELS
dev-1    1/1     Running   0          8s    app=nginx,env=dev
dev-2    1/1     Running   0          14s   app=nginx,env=dev
pord-1   1/1     Running   0          64s   app=nginx,env=prod
pord-2   1/1     Running   0          26s   app=nginx,env=prod
$ kubectl delete po -l env=prod
pod "pord-1" deleted
pod "pord-2" deleted
$ kubectl get po --show-labels
NAME    READY   STATUS    RESTARTS   AGE   LABELS
dev-1   1/1     Running   0          70s   app=nginx,env=dev
dev-2   1/1     Running   0          76s   app=nginx,env=dev

结论

production 和 staging 相似：environment: staging 和 environment: production。

这是两个不同的对象 - Namespace 这是某种虚拟集群，可以帮助我们组织项目或环境。 Labels 是一个键值对，分配给 Kubernetes 资源，如 Pod、Deployment 等。

我想使用环境的一个好处是您可以将所有内容放在默认命名空间中，同时保持 Pod 分离？

在某些情况下可以，但对于每个命令，您需要指定 label。

如果您要列出所有namespaces 中的资源，您可以使用--all-namespaces 例如$ kubectl get po --all-namespaces 或标记-A，如$ kubectl get po -A

其他链接

如果您还有其他问题，请告诉我。

【讨论】：