document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-25 23:11:02 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #16836 from lxbwolf/11-20191219-Kubernetes-namespaces-for-beginners

Browse Source 
translated
This commit is contained in:
Xingyu.Wang 2019-12-29 14:35:49 +08:00 committed by GitHub
commit d7edc87b5e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 189 additions and 192 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

192
sources/tech/20191219 Kubernetes namespaces for beginners.md
View File

@ -1,192 +0,0 @@
[#]: collector: (lujun9972)
[#]: translator: (lxbwolf)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (Kubernetes namespaces for beginners)
[#]: via: (https://opensource.com/article/19/12/kubernetes-namespaces)
[#]: author: (Jessica Cherry https://opensource.com/users/jrepka)
Kubernetes namespaces for beginners
======
What is a namespace and why do you need it?
![Ship captain sailing the Kubernetes seas][1]
What is in a Kubernetes namespace? As Shakespeare once wrote, which we call a namespace, by any other name, would still be a virtual cluster. By virtual cluster, I mean Kubernetes can offer multiple Kubernetes clusters on a single cluster, much like a virtual machine is an abstraction of its host. According to the [Kubernetes docs][2]:
> Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called namespaces.
Why do you need to use namespaces? In one word: isolation.
Isolation has many advantages, including that it supports secure and clean environments. If you are the owner of the infrastructure and are supporting developers, isolation is fairly important. The last thing you need is someone who is unfamiliar with how your cluster is built going and changing the system configuration—and possibly disabling everyone's ability to log in.
### The namespaces that start it all
The first three namespaces created in a cluster are always **default**, **kube-system**, and **kube-public**. While you can technically deploy within these namespaces, I recommend leaving these for system configuration and not for your projects. 
* **Default** is for deployments that are not given a namespace, which is a quick way to create a mess that will be hard to clean up if you do too many deployments without the proper information. I leave this alone because it serves that one purpose and has confused me on more than one occasion.
* **Kube-system** is for all things relating to, you guessed it, the Kubernetes system. Any deployments to this namespace are playing a dangerous game and can accidentally cause irreparable damage to the system itself. Yes, I have done it; I do not recommend it.
* **Kube-public** is readable by everyone, but the namespace is reserved for system usage.
### Using namespaces for isolation
I have used namespaces for isolation in a couple of ways. I use them most often to split many users' projects into separate environments. This is useful in preventing cross-project contamination since namespaces provide independent environments. Users can install multiple versions of Jenkins, for example, and their environmental variables won't collide if they are in different namespaces.
This separation also helps with cleanup. If development groups are working on various projects that suddenly become obsolete, you can delete the namespace and remove everything in one swift movement with **kubectl delete ns <$NAMESPACENAME>**. (Please make sure it's the right namespace. I deleted the wrong one in production once, and it's not pretty.)
Be aware that this can cause damage across teams and problems for you if you are the infrastructure owner. For example, if you create a namespace with some special, extra-secure DNS functions and the wrong person deletes it, all of your pods and their running applications will be removed with the namespace. Any use of **delete** should be reviewed by a peer (through [GitOps][3]) before hitting the cluster.
While the official documentation suggests not using multiple namespaces [with 10 or fewer users][2], I still use them in my own cluster for architectural purposes. The cleaner the cluster, the better.
### What admins need to know about namespaces
For starters, namespaces cannot be nested in other namespaces. There can be only one namespace with deployments in it. You don't have to use namespaces for versioned projects, but you can always use the labels to separate versioned apps with the same name. Namespaces divide resources between users using resource quotas; for example, _this namespace can only have x_ _number_ _of nodes_. Finally, all namespaces scope down to a unique name for the resource type.
### Namespace commands in action
To try out the following namespace commands, you need to have [Minikube][4], [Helm][5], and the [kubectl][6] command line installed. For information about installing them, see my article [_Security scanning your DevOps pipeline_][7] or each project's homepage. I am using the most recent release of Minikube. The manual installation is fast and has consistently worked correctly the first time.
To get your first set of namespaces:
```
jess@Athena:~$ kubectl get namespace
NAME            STATUS   AGE
default         Active   5m23s
kube-public     Active   5m24s
kube-system     Active   5m24s
```
To create a namespace:
```
jess@Athena:~$ kubectl create namespace athena
namespace/athena created
```
Now developers can deploy to the namespace you created; for example, here's a small and easy 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
```
To get your password:
```
`export REDIS_PASSWORD=$(kubectl get secret --namespace athena teset-deploy-redis -o jsonpath="{.data.redis-password}" | base64 --decode)`
```
To connect to your Redis server:
1. Run a Redis pod that you can use as a client: [code] 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
```
2. Connect using the Redis CLI: [code] redis-cli -h teset-deploy-redis-master -a $REDIS_PASSWORD
redis-cli -h teset-deploy-redis-slave -a $REDIS_PASSWORD
```
To connect to your database from outside the cluster:
```
kubectl port-forward --namespace athena svc/teset-deploy-redis-master 6379:6379 &
redis-cli -h 127.0.0.1 -p 6379 -a $REDIS_PASSWORD
```
Now that this deployment is out, you have a chart deployed in your namespace named **test-deploy**.
To look at what pods are in your namespace:
```
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
```
At this point, you have officially isolated your application to a single namespace and created one virtual cluster that talks internally only to itself.
Delete everything with a single command:
```
jess@Athena:~$ kubectl delete namespace athena
namespace "athena" deleted
```
Because this deletes the application's entire internal configuration, the delete may take some time, depending on how large your deployment is.
Double-check that everything has been removed:
```
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
```
This is a list of all the pods and all the known namespaces where they live. As you can see, the application and namespace you previously made are now gone.
### Namespaces in practice
I currently use namespaces for security purposes, including reducing the privileges of users with limitations. You can limit everything—from which roles can access a namespace to their quota levels for cluster resources, like CPUs. For example, I use resource quotas and role-based access control (RBAC) configurations to confirm that a namespace is accessible only by the appropriate service accounts.
On the isolation side of security, I don't want my home Jenkins application to be accessible over a trusted local network as secure images that have public IP addresses (and thus, I have to assume, could be compromised).
Namespaces can also be helpful for budgeting purposes if you have a hard budget on how much you can use in your cloud platform for nodes (or, in my case, how much I can deploy before [segfaulting][8] my home server). Although this is out of scope for this article, and it's complicated, it is worth researching and taking advantage of to prevent overextending your cluster.
### Conclusion
Namespaces are a great way to isolate projects and applications. This is just a quick introduction to the topic, so I encourage you to do more advanced research on namespaces and use them more in your work.
--------------------------------------------------------------------------------
via: https://opensource.com/article/19/12/kubernetes-namespaces
作者：[Jessica Cherry][a]
选题：[lujun9972][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/jrepka
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/ship_captain_devops_kubernetes_steer.png?itok=LAHfIpek (Ship captain sailing the Kubernetes seas)
[2]: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/
[3]: https://www.weave.works/blog/gitops-operations-by-pull-request
[4]: https://kubernetes.io/docs/tasks/tools/install-minikube/
[5]: https://helm.sh/
[6]: https://kubernetes.io/docs/tasks/tools/install-kubectl/
[7]: https://opensource.com/article/19/7/security-scanning-your-devops-pipeline
[8]: https://en.wikipedia.org/wiki/Segmentation_fault

189
translated/tech/20191219 Kubernetes namespaces for beginners.md Normal file
View File

@ -0,0 +1,189 @@
[#]: collector: (lujun9972)
[#]: translator: (lxbwolf)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (Kubernetes namespaces for beginners)
[#]: via: (https://opensource.com/article/19/12/kubernetes-namespaces)
[#]: author: (Jessica Cherry https://opensource.com/users/jrepka)
Kubernetes 命名空间入门
======
命名空间是什么？你为什么需要它？
![Ship captain sailing the Kubernetes seas][1]
kubernetes 命名空间是什么？Shakespeare 以前写过，我们声称的命名空间，或者任何其他名字，仍是一个虚拟集群。命名空间，意味着 kubernetes 可以在单个集群上提供多个 kubernetes 的集群，类似一个对其主机进行抽象的虚拟机。[kubernetes 文档][2] 中的解释：
> kubernetes 在一个物理集群上提供了多个虚拟集群。这些虚拟集群被称为命名空间。
你为什么需要命名空间？一句话概括：隔离。
隔离有很多优点，如它提供了安全和干净的环境。如果你是基础设施的所属者，并且为开发者提供环境，隔离就相当重要。你最不需要的就是，一个不熟悉你集群是如何搭建的人去修改系统配置 — 这可能导致所有人都无法登录。
### 初始命名空间
 一个集群的三个初始命名空间：**default**、**kube-system** 和 **kube-public**。虽然你可以用这三个命名空间作技术部署，但我还是推荐你把这三个命名空间留作系统配置用，而不是你的项目。
* **Default** 某些部署没有指明命名空间，这样部署可以快速创建一个网格，但如果做了很多错误信息的部署，就很能去清理。我不去修改它，因为它在为某一个目的服务时，会在不止一种情况下误导我。
* **Kube-system** 系统相关的所有对象组成的命名空间。任何此命名空间的部署都可能是危险的操作，可能对系统本身造成不可挽回的破坏。没错，我试过；所以我不推荐。
* **Kube-public** 所有人可读，但是这个命名空间是为系统保留的。
### 用命名空间来实现隔离
我用了多种方式通过命名空间来实现隔离。我经常用命名空间来把多个用户项目分割到不同的环境。这种方式可以有效防止跨项目的污染，因为命名空间提供了独立的环境。例如，使用者可以安装不同版本的 Jenkins，如果它们的环境变量是在不同的命名空间，就不会冲突。
这种隔离对于清理也很有帮助。如果部署组的多个项目被废弃，你可以用命令 `kubectl delete ns <$NAMESPACENAME>` 一键删除命名空间，清理命名空间内的所有东西。（请确认被删除的是正确的命名空间。我曾经在生产环境删除了错误的命名空间，这很不好。）
如果你是基础设施所有者，请谨慎操作，因为这可能会引发其他团队的的故障或引发其他问题。例如，如果你创建了一个特定的命名空间，里面有 DNS 函数，其他人删除了它，那么命名空间内的所有 pod 和它们运行的应用都会被清空。所有的**删除**操作在真正实施之前都应该由同事（通过 [GitOps][3]）评审一下。
虽然官方文档不建议 [10 人以下团队][2] 使用多个命名空间，但出于架构需要，在我自己的集群上还是用了多个命名空间。集群越干净越好。
### 关于命名空间管理员应该知道的
首先，命名空间不能嵌套。部署只能在一个命名空间中进行。对于版本化项目，你不一定要用命名空间，你可以使用标签来区分有相同名字的版本化应用。命名空间使用配额来为不同的用户划分资源；例如，*某个命名空间最多能有 x 个 node*。最后，所有的命名空间对于资源类型只能使用一个独一无二的名字。
### 命名空间命令操作
你需要安装 [Minikube][4]、 [Helm][5] 和 [kubectl][6] 命令行，才能使用下面的命名空间命令。我的文章 [_安全浏览你的 DevOps 流水线_][7] 中有它们的安装教程，你也可以去每个工程的官方主页去找安装教程。我使用的是最新的 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 结构信息：
```
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 服务：
1. 运行一个你可以作为客户端用的 Redis pod：
```bash
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
```
2. 使用 Redis CLI 连接：
```bash
redis-cli -h teset-deploy-redis-master -a $REDIS_PASSWORD
redis-cli -h teset-deploy-redis-slave -a $REDIS_PASSWORD
```
从集群外连接你的数据库：
```bash
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** 中部署的图表。
查看你的命名空间中有哪些 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
```
现在，你已经正式把你的应用隔离到了一个命名空间，创建了一个只在内部通信的虚拟集群。
一键删除所有东西：
```bash
jess@Athena:~$ kubectl delete namespace athena
namespace "athena" deleted
```
因为这会删除应用的所有内部配置，所以这个删除操作可能会持续一段时间，持续时间取决于你的部署到底有多大。
再次检查一下所有东西是否被删除了：
```bash
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 等）的配额等级。例如，我通过资源配额和基于角色的访问控制（role-based access control，RBAC）配置来确保只有允许的服务账号可以访问命名空间。
对于隔离方面的安全，我不希望我的私人 Jenkins 应用可以通过一个信任的本地网络被当做有公共 IP 地址的安全镜像来访问（我不得不假定，可能会做出妥协）。
如果你很难提前计算出到底要在你的云平台上部署多少 node（就我而言，在把我的私人服务器放到 [segfaulting][8] 之前可以部署多少个 node），那么命名空间在预算方面也很有用。虽然这超出了本文的讨论范围，而且很复杂，但值得你去调研和使用来防止你的集群过分扩展。
### 总结
命名空间是一个很好的隔离项目和应用的方法。本文仅是一个关于命名空间的简短介绍，所以我建议你更深入地研究下命名空间，在你的实践中更多地去使用它们。
--------------------------------------------------------------------------------
via: https://opensource.com/article/19/12/kubernetes-namespaces
作者：[Jessica Cherry][a]
选题：[lujun9972][b]
译者：[lxbwolf](https://github.com/lxbwolf)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/jrepka
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/ship_captain_devops_kubernetes_steer.png?itok=LAHfIpek (Ship captain sailing the Kubernetes seas)
[2]: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/
[3]: https://www.weave.works/blog/gitops-operations-by-pull-request
[4]: https://kubernetes.io/docs/tasks/tools/install-minikube/
[5]: https://helm.sh/
[6]: https://kubernetes.io/docs/tasks/tools/install-kubectl/
[7]: https://opensource.com/article/19/7/security-scanning-your-devops-pipeline
[8]: https://en.wikipedia.org/wiki/Segmentation_fault