Kubernetes 命名空间中有什么?正如莎士比亚曾经写道,我们称之为命名空间的东西,换成任何其他名称,仍然会是一个虚拟集群。通过虚拟集群,我的意思是 Kubernetes 可以在单个集群上提供多个 Kubernetes 集群,就像虚拟机是其主机的抽象一样。根据 Kubernetes 文档
Kubernetes 支持由同一物理集群支持的多个虚拟集群。这些虚拟集群称为命名空间。
为什么需要使用命名空间?用一个词概括:隔离。
隔离有很多优点,包括它支持安全和干净的环境。如果您是基础设施的所有者并支持开发人员,那么隔离非常重要。您最不需要的就是不熟悉集群构建方式的人去更改系统配置,并可能禁用所有人登录的能力。
启动一切的命名空间
集群中创建的前三个命名空间始终是 default、kube-system 和 kube-public。虽然从技术上讲您可以在这些命名空间中进行部署,但我建议将这些命名空间留给系统配置,而不是用于您的项目。
- Default 用于未指定命名空间的部署,这是一种快速创建混乱的方法,如果您在没有正确信息的情况下进行太多部署,将很难清理。我将其保留不动,因为它服务于一个目的,并且不止一次让我感到困惑。
- Kube-system 用于与 Kubernetes 系统相关的所有事物,正如您所猜测的那样。对该命名空间的任何部署都是在玩危险的游戏,并且可能会意外地对系统本身造成不可弥补的损害。是的,我做过;我不建议这样做。
- Kube-public 可供所有人读取,但该命名空间保留供系统使用。
使用命名空间进行隔离
我以几种方式使用命名空间进行隔离。我最常使用它们将多个用户的项目拆分为独立的环境。这在防止跨项目污染方面很有用,因为命名空间提供独立的环境。例如,用户可以安装多个版本的 Jenkins,并且如果它们位于不同的命名空间中,则其环境变量不会冲突。
这种分离也有助于清理。如果开发团队正在处理的各种项目突然变得过时,您可以使用 kubectl delete ns <$NAMESPACENAME> 一次性删除命名空间并删除其中的所有内容。(请确保它是正确的命名空间。我曾经在生产环境中删除了错误的命名空间,那可不好玩。)
请注意,如果您是基础设施所有者,这可能会对团队造成损害并给您带来问题。例如,如果您创建了一个具有一些特殊的、超安全的 DNS 功能的命名空间,并且错误的人删除了它,那么您的所有 Pod 及其正在运行的应用程序都将随命名空间一起删除。任何使用 delete 都应在点击集群之前由同行审查(通过 GitOps)。
虽然官方文档建议不要在 用户少于 10 个时 使用多个命名空间,但我仍然在自己的集群中出于架构目的使用它们。集群越干净越好。
管理员需要了解的关于命名空间的信息
首先,命名空间不能嵌套在其他命名空间中。只能有一个命名空间包含部署。您不必为版本化项目使用命名空间,但您可以始终使用标签来分隔同名的版本化应用程序。命名空间使用资源配额在用户之间划分资源;例如,此命名空间只能有 x 个 节点。最后,所有命名空间都将范围缩小到资源类型的唯一名称。
命名空间命令实践
要试用以下命名空间命令,您需要安装 Minikube、Helm 和 kubectl 命令行。有关安装它们的信息,请参阅我的文章 安全扫描您的 DevOps 管道 或每个项目的主页。我正在使用最新版本的 Minikube。手动安装速度很快,并且每次都能正确工作。
获取您的第一个命名空间集
jess@Athena:~$ kubectl get namespace
NAME STATUS AGE
default Active 5m23s
kube-public Active 5m24s
kube-system Active 5m24s
创建命名空间
jess@Athena:~$ kubectl create namespace athena
namespace/athena created
现在开发人员可以将部署到您创建的命名空间;例如,这是一个小型且简单的 Helm chart
jess@Athena:~$ helm install teset-deploy stable/redis --namespace athena
NAME: teset-deploy
LAST DEPLOYED: Sat Nov 23 13:47:43 2019
NAMESPACE: athena
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
** Please be patient while the chart is being deployed **
Redis can be accessed via port 6379 on the following DNS names from within your cluster:
teset-deploy-redis-master.athena.svc.cluster.local for read/write operations
teset-deploy-redis-slave.athena.svc.cluster.local for read-only operations
获取您的密码
export REDIS_PASSWORD=$(kubectl get secret --namespace athena teset-deploy-redis -o jsonpath="{.data.redis-password}" | base64 --decode)
连接到您的 Redis 服务器
- 运行一个可以用作客户端的 Redis Pod
kubectl run --namespace athena teset-deploy-redis-client --rm --tty -i --restart='Never' \ --env REDIS_PASSWORD=$REDIS_PASSWORD \ --image docker.io/bitnami/redis:5.0.7-debian-9-r0 -- bash
- 使用 Redis CLI 连接
redis-cli -h teset-deploy-redis-master -a $REDIS_PASSWORD redis-cli -h teset-deploy-redis-slave -a $REDIS_PASSWORD
从集群外部连接到您的数据库
kubectl port-forward --namespace athena svc/teset-deploy-redis-master 6379:6379 &
redis-cli -h 127.0.0.1 -p 6379 -a $REDIS_PASSWORD
现在这个部署已经完成,您已经在名为 test-deploy 的命名空间中部署了一个 chart。
查看您的命名空间中有哪些 Pod
jess@Athena:~$ kubectl get pods --namespace athena
NAME READY STATUS RESTARTS AGE
teset-deploy-redis-master-0 1/1 Running 0 2m38s
teset-deploy-redis-slave-0 1/1 Running 0 2m38s
teset-deploy-redis-slave-1 1/1 Running 0 90s
此时,您已正式将您的应用程序隔离到单个命名空间,并创建了一个仅在内部相互通信的虚拟集群。
使用单个命令删除所有内容
jess@Athena:~$ kubectl delete namespace athena
namespace "athena" deleted
因为这会删除应用程序的整个内部配置,所以删除可能需要一些时间,具体取决于您的部署规模。
仔细检查所有内容是否已删除
jess@Athena:~$ kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-5644d7b6d9-4vxv6 1/1 Running 0 32m
kube-system coredns-5644d7b6d9-t5wn7 1/1 Running 0 32m
kube-system etcd-minikube 1/1 Running 0 31m
kube-system kube-addon-manager-minikube 1/1 Running 0 32m
kube-system kube-apiserver-minikube 1/1 Running 0 31m
kube-system kube-controller-manager-minikube 1/1 Running 0 31m
kube-system kube-proxy-5tdmh 1/1 Running 0 32m
kube-system kube-scheduler-minikube 1/1 Running 0 31m
kube-system storage-provisioner 1/1 Running 0 27m
这是所有 Pod 及其所在的所有已知命名空间的列表。如您所见,您之前创建的应用程序和命名空间现已消失。
命名空间在实践中
我目前将命名空间用于安全目的,包括降低具有限制的用户权限。您可以限制一切——从哪些角色可以访问命名空间到它们对集群资源的配额级别,例如 CPU。例如,我使用资源配额和基于角色的访问控制 (RBAC) 配置来确认命名空间只能由相应的服务帐户访问。
在安全隔离方面,我不希望我的家庭 Jenkins 应用程序可以通过受信任的本地网络作为具有公共 IP 地址的安全映像进行访问(因此,我必须假设,可能会受到威胁)。
如果您对云平台中可以使用的节点数量有硬性预算(或者,就我而言,在 段错误 我的家庭服务器之前我可以部署多少),命名空间也可能对预算目的有所帮助。虽然这超出了本文的范围,并且很复杂,但值得研究和利用它来防止过度扩展您的集群。
结论
命名空间是隔离项目和应用程序的好方法。这只是对该主题的快速介绍,因此我鼓励您对命名空间进行更深入的研究并在您的工作中更多地使用它们。
评论已关闭。