随着集群规模的扩大和业务复杂度的增加,如何有效地管理和组织资源成为了一个重要的问题。为了解决这个问题,Kubernetes提供了名字空间(Namespace)这一强大的功能,它允许将集群中的资源进行细分,从而实现更好的资源隔离和管理。接下来将详细介绍如何使用Kubernetes名字空间来细分集群。
Kubernetes 名字空间有助于不同的项目、团队或客户去共享 Kubernetes 集群。名字空间通过以下方式实现:
- 为名字设置作用域;
- 为集群中的部分资源关联鉴权和策略的机制。
使用多个名字空间是可选的。
一、准备
必须拥有一个 Kubernetes 的集群,同时必须配置 kubectl 命令行工具与集群通信。 建议在至少有两个不作为控制平面主机的节点的集群上运行本教程。 如果还没有集群,可以通过 Minikube 构建一个自己的集群,或者可以使用下面的 Kubernetes 练习环境之一:
- Killercoda
- 玩转 Kubernetes
要获知版本信息,请输入 kubectl version.
二、环境准备
此示例作如下假设:
- 已拥有一个配置好的 Kubernetes 集群;
- 已对 Kubernetes 的 Pod、 服务 和 Deployment 有基本理解。
三、理解默认名字空间
默认情况下,Kubernetes 集群会在配置集群时实例化一个默认名字空间,用以存放集群所使用的默认 Pod、Service 和 Deployment 集合。
假设有一个新的集群,可以通过执行以下操作来检查可用的名字空间:
kubectl get namespaces
NAME STATUS AGE
default Active 13m
四、创建新名字空间
在本练习中,将创建两个额外的 Kubernetes 名字空间来保存的内容。假设一个场景,某组织正在使用共享的 Kubernetes 集群来支持开发和生产:
- 开发团队希望在集群中维护一个空间,以便他们可以查看用于构建和运行其应用程序的 Pod、Service 和 Deployment 列表。在这个空间里,Kubernetes 资源被自由地加入或移除, 对谁能够或不能修改资源的限制被放宽,以实现敏捷开发。
- 运维团队希望在集群中维护一个空间,以便他们可以强制实施一些严格的规程, 对谁可以或谁不可以操作运行生产站点的 Pod、Service 和 Deployment 集合进行控制。
- 该组织可以遵循的一种模式是将 Kubernetes 集群划分为两个名字空间:development 和 production。
让创建两个新的名字空间来保存的工作。
文件 namespace-dev.yaml 描述了 development 名字空间:
apiVersion: v1 kind: Namespace metadata: name: development labels: name: development
使用 kubectl 创建 development 名字空间。
kubectl create -f https://k8s.io/examples/admin/namespace-dev.yaml
将下列的内容保存到文件 namespace-prod.yaml 中, 这些内容是对 production 名字空间的描述:
apiVersion: v1 kind: Namespace metadata: name: production labels: name: production
让使用 kubectl 创建 production 名字空间。
kubectl create -f https://k8s.io/examples/admin/namespace-prod.yaml
为了确保一切正常,列出集群中的所有名字空间。
kubectl get namespaces --show-labels
NAME STATUS AGE LABELS
default Active 32m <none>
development Active 29s name=development
production Active 23s name=production
五、创建Pod
Kubernetes 名字空间为集群中的 Pod、Service 和 Deployment 提供了作用域。与一个名字空间交互的用户不会看到另一个名字空间中的内容。
为了演示这一点,让在 development 名字空间中启动一个简单的 Deployment 和 Pod。首先检查一下当前的上下文:
kubectl config view
apiVersion: v1 clusters: - cluster: certificate-authority-data: REDACTED server: https://130.211.122.180 name: lithe-cocoa-92103_kubernetes contexts: - context: cluster: lithe-cocoa-92103_kubernetes user: lithe-cocoa-92103_kubernetes name: lithe-cocoa-92103_kubernetes current-context: lithe-cocoa-92103_kubernetes kind: Config preferences: {} users: - name: lithe-cocoa-92103_kubernetes user: client-certificate-data: REDACTED client-key-data: REDACTED token: 65rZW78y8HbwXXtSXuUw9DbP4FLjHi4b - name: lithe-cocoa-92103_kubernetes-basic-auth user: password: h5M0FtUUIflBSdI7 username: admin
kubectl config current-context
lithe-cocoa-92103_kubernetes
下一步是为 kubectl 客户端定义一个上下文,以便在每个名字空间中工作。 “cluster” 和 “user” 字段的值将从当前上下文中复制。
<code class="language-shell" data-lang="shell">kubectl config set-context dev --namespace=development \ --cluster=lithe-cocoa-92103_kubernetes \ --user=lithe-cocoa-92103_kubernetes kubectl config set-context prod --namespace=production \ --cluster=lithe-cocoa-92103_kubernetes \ --user=lithe-cocoa-92103_kubernetes
默认情况下,上述命令会添加两个上下文到 .kube/config 文件中。 现在可以查看上下文并根据希望使用的名字空间并在这两个新的请求上下文之间切换。
查看新的上下文:
kubectl config view
apiVersion: v1 clusters: - cluster: certificate-authority-data: REDACTED server: https://130.211.122.180 name: lithe-cocoa-92103_kubernetes contexts: - context: cluster: lithe-cocoa-92103_kubernetes user: lithe-cocoa-92103_kubernetes name: lithe-cocoa-92103_kubernetes - context: cluster: lithe-cocoa-92103_kubernetes namespace: development user: lithe-cocoa-92103_kubernetes name: dev - context: cluster: lithe-cocoa-92103_kubernetes namespace: production user: lithe-cocoa-92103_kubernetes name: prod current-context: lithe-cocoa-92103_kubernetes kind: Config preferences: {} users: - name: lithe-cocoa-92103_kubernetes user: client-certificate-data: REDACTED client-key-data: REDACTED token: 65rZW78y8HbwXXtSXuUw9DbP4FLjHi4b - name: lithe-cocoa-92103_kubernetes-basic-auth user: password: h5M0FtUUIflBSdI7 username: admin
切换到 development 名字空间进行操作。
kubectl config use-context dev
可以使用下列命令验证当前上下文:
kubectl config current-context
dev
此时,从命令行向 Kubernetes 集群发出的所有请求都限定在 development 名字空间中。
让创建一些内容。
apiVersion: apps/v1 kind: Deployment metadata: labels: app: snowflake name: snowflake spec: replicas: 2 selector: matchLabels: app: snowflake template: metadata: labels: app: snowflake spec: containers: - image: registry.k8s.io/serve_hostname imagePullPolicy: Always name: snowflake
应用清单文件来创建 Deployment。
kubectl apply -f https://k8s.io/examples/admin/snowflake-deployment.yaml
创建了一个副本大小为 2 的 Deployment,该 Deployment 运行名为 snowflake 的 Pod, 其中包含一个仅提供主机名服务的基本容器。
kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
snowflake 2/2 2 2 2m
kubectl get pods -l app=snowflake
NAME READY STATUS RESTARTS AGE
snowflake-3968820950-9dgr8 1/1 Running 0 2m
snowflake-3968820950-vgc4n 1/1 Running 0 2m
让切换到 production 名字空间,展示一个名字空间中的资源如何对另一个名字空间不可见。
kubectl config use-context prod
production 名字空间应该是空的,下列命令应该返回的内容为空。
kubectl get deployment kubectl get pods
生产环境需要以放牛的方式运维,让创建一些名为 cattle 的 Pod。
kubectl create deployment cattle --image=registry.k8s.io/serve_hostname --replicas=5 kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
cattle 5/5 5 5 10s
kubectl get pods -l run=cattle
NAME READY STATUS RESTARTS AGE
cattle-2263376956-41xy6 1/1 Running 0 34s
cattle-2263376956-kw466 1/1 Running 0 34s
cattle-2263376956-n4v97 1/1 Running 0 34s
cattle-2263376956-p5p3i 1/1 Running 0 34s
cattle-2263376956-sxpth 1/1 Running 0 34s
此时,应该很清楚的展示了用户在一个名字空间中创建的资源对另一个名字空间是不可见的。随着 Kubernetes 中的策略支持的发展,将扩展此场景,以展示如何为每个名字空间提供不同的授权规则。