by cheungpat

通过cheungpat

我如何构建Kubernetes集群，以便我的同事可以更快地部署应用程序 (How I built a Kubernetes cluster so my coworkers could deploy apps faster)

How do you encourage your development team to build more projects without being bogged down with deployment? As a company that builds mobile and web products, it’s a priority that we create an environment where our team members focus on building rather than deploying.

您如何鼓励您的开发团队构建更多项目而又不会陷入部署困境？ 作为一家构建移动和Web产品的公司，我们首先要创造一个环境，使团队成员专注于构建而不是部署。

But even if we have a deployment platform, we’ll still need someone to manage the administration. As engineers, anything we have to repeat, we want to automate.

但是，即使我们有一个部署平台，我们仍然需要有人来管理管理。 作为工程师，我们必须重复的任何事情都想实现自动化。

What would be a secure way to give our developers access to our deployment platform?

使开发人员能够访问我们的部署平台的安全方法是什么？

1. We want to allow our developers to build their own projects (perhaps personal) without needing to ask an administrator for permission or resources to deploy a new application for testing or experimenting
   我们希望允许我们的开发人员构建自己的项目(也许是个人的)，而无需征求管理员的许可或资源来部署新的应用程序进行测试或试验
2. Our developers can deploy their own application, update it, or remove it
   我们的开发人员可以部署，更新或删除自己的应用程序
3. Lower barriers for trying out new things (so to speak)
   降低尝试新事物的门槛(可以这么说)

我们的解决方案：Kubernetes (Our solution: Kubernetes)

Our solution was to use GitHub Authentication for our Kubernetes cluster. For those of you who don’t know, is a production-ready container orchestration engine developed by Google. It’s an open-source platform that enables automation for container operations. Things like deployment and scaling across a cluster of hosts (or nodes).

我们的解决方案是将Kubernetes集群使用GitHub身份验证。 对于不认识的人， 是Google开发的可用于生产的容器编排引擎。 这是一个开放源代码平台，可实现容器操作的自动化。 跨主机(或节点)群集进行部署和扩展之类的事情。

With Kubernetes, we are able to support our developers as customers who need to deploy applications and seamlessly roll out new features without a heavy admin overhead. Container technologies are a good practice for packaging backend applications and running them on a server.We run containers from different projects in the same cluster. Kubernetes allows us to focus less on individual servers. We may think of Kubernetes as “a big computer” where our team members can run containers on top of it.

借助Kubernetes，我们可以为需要部署应用程序并无缝推出新功能的客户提供支持，而无需沉重的管理开销。 容器技术是打包后端应用程序并在服务器上运行它们的良好实践。我们在同一集群中运行来自不同项目的容器。 Kubernetes使我们可以减少对单个服务器的关注。 我们可能会将Kubernetes视为“一台大型计算机”，我们的团队成员可以在其中运行容器。

使我们的团队可以访问集群 (Giving our team access to the cluster)

We want colleagues to have their own user credentials to access the cluster. This saves admin time since they don’t need to open a new account for each user. New users can generate the credential themselves, or new ones if they lose their credentials. We were looking for an authentication solution that could meet all of the requirements below:

我们希望同事拥有自己的用户凭据才能访问群集。 由于他们不需要为每个用户开设新帐户，因此节省了管理员时间。 新用户可以自己生成凭据，或者如果丢失凭据则可以生成新凭据。 我们正在寻找一种可以满足以下所有要求的身份验证解决方案：

1. Admin time should be saved (since they are also our developers)
   应当节省管理员时间(因为他们也是我们的开发人员)
2. New users can generate their own credentials without needing the admin
   新用户无需管理员即可生成自己的凭据
3. User credential is always private for security reasons
   出于安全原因，用户凭据始终是私有的
4. Developers have their own space to experiment
   开发人员有自己的实验空间
5. Project spaces can be accessed and changed by multiple users
   多个用户可以访问和更改项目空间
6. In the future, we may want to enable auditing to track changes
   将来，我们可能希望启用审核以跟踪更改

尝试-大多数现有的身份验证策略不适合 (Attempts — most existing authentication strategies do not fit)

First of all, many existing authentication methods still require an admin to generate or manage accounts. This is the main reason we ruled most of them out. Below, I’ll list out some common ones for reference, but feel free to skip to the next section if you just want to understand why we chose GitHub Authentication.

首先，许多现有的身份验证方法仍然需要管理员来生成或管理帐户。 这是我们排除其中大多数的主要原因。 下面，我将列出一些常见的参考，但是如果您只是想了解我们为什么选择GitHub身份验证，请随时跳到下一部分。

基于证书 (Certificate-Based)

Each user has their own private SSL certificate for accessing the cluster, which can be complicated to set up. This means an admin needs to manage a public-key infrastructure (i.e. Certificate Authority) to sign the user certificate. In addition, the admin needs to do this when 1) there is a new user, 2) the certificate expires, or 3) the user has lost the certificate/private-key. Finally, the user has to manage their own private key materials when they want to use the same SSL certs on multiple computers — a potential security weakness.

每个用户都有自己的私有SSL证书来访问群集，这可能会很复杂。 这意味着管理员需要管理公共密钥基础结构(即证书颁发机构)来签署用户证书。 此外，在1)有新用户，2)证书过期或3)用户丢失了证书/私钥时，管理员需要执行此操作。 最后，当用户想在多台计算机上使用相同的SSL证书时，用户必须管理自己的私钥材料，这是潜在的安全漏洞。

基于用户名/密码 (Username/Password-Based)

Since everyone knows how to use a username and password, this is easier to implement than certificate-based authentication. However, Kubernetes doesn’t have a user-friendly interface for our team members to create their own account, which means we still need an admin to generate a set of username and password for each user. Additionally, this means the admin needs to reset a user’s password if the user loses it. Without a user-friendly UI, it is difficult for the user to change the password, too. Kubernetes also requires the API server to be restarted when the username/password list changes.

由于每个人都知道如何使用用户名和密码，因此比基于证书的身份验证更容易实现。 但是，Kubernetes没有一个易于使用的界面供我们的团队成员创建自己的帐户，这意味着我们仍然需要管理员才能为每个用户生成一组用户名和密码。 此外，这意味着如果用户丢失密码，管理员需要重设用户密码。 如果没有用户友好的UI，用户也很难更改密码。 当用户名/密码列表更改时，Kubernetes还要求重新启动API服务器。

预先生成的基于令牌的 (Pre-Generated Token-Based)

Similar to the Username/Password-based approach, the admin is still involved to generate a token. : At the time we built the Kubernetes cluster, OIDC support was not fully-baked, and we were not sure about how to integrate OIDC with Google accounts. OIDC is a good option if it is fully implemented by the Kubernetes API server and client command (this was not implemented last time I checked).

与基于用户名/密码的方法类似，管理员仍需要参与生成令牌。 ：在我们构建Kubernetes集群时，OIDC支持还没有完全成熟，并且我们不确定如何将OIDC与Google帐户集成。 如果OIDC由Kubernetes API服务器和客户端命令完全实现(这是我上次检查时未实现)，则是一个不错的选择。

使用GitHub身份验证的5个简单原因 (5 simple reasons to use GitHub authentication)

GitHub Authentication was a simple solution because:

GitHub身份验证是一个简单的解决方案，因为：

1. Everyone in our company already has a GitHub account
   我们公司中的每个人都已经有一个GitHub帐户
2. This solves our admin overhead problem since people manage their own tokens
   由于人们管理自己的令牌，这解决了我们的管理开销问题

3. Users can easily generate an access token on

   用户可以在上轻松生成访问令牌

4. It’s highly flexible as users can access the Kubernetes cluster on different computers, just by generating new tokens
   由于用户可以通过生成新令牌访问不同计算机上的Kubernetes集群，因此具有很高的灵活性

5. Access can always be revoked by removing the access token on (in case the github token is leaked)

   始终可以通过删除上的访问令牌来撤消访问(以防github令牌泄漏)

实施GitHub身份验证 (Implementing GitHub authentication)

We authenticate our team members using GitHub token. Kubernetes supports a to allow a remote service to authenticate. So all we have to do is implement a webhook that verifies the token. When a user tries to authenticate to the Kubernetes API, the Kubernetes API server calls this authenticator to verify the bearer token. This authenticator checks if the access token is valid using GitHub API and returns the GitHub username to the API server by checking whether the requested user has access to the resource. It uses Role-Based Access Control (RBAC) rules. Note that we have to run the webhook on Kubernetes master, in order for the API server to access it. This is how we actually :

我们使用GitHub令牌对团队成员进行身份验证。 Kubernetes支持Webhook 以允许远程服务进行身份验证。 因此，我们要做的就是实现一个Webhook来验证令牌。 当用户尝试通过Kubernetes API进行身份验证时，Kubernetes API服务器将调用此身份验证器以验证承载令牌。 该验证器使用GitHub API检查访问令牌是否有效，并通过检查请求的用户是否有权访问资源来将GitHub用户名返回给API服务器。 它使用基于角色的访问控制(RBAC)规则。 请注意，我们必须在Kubernetes主服务器上运行webhook，以便API服务器访问它。 这就是我们实际 ：

We used because it offers the highest flexibility without making config changes on the API server. Besides RBAC, Kubernetes has various authorization strategies. For now, GitHub Authentication doesn’t entirely remove admin responsibilities. An admin is still needed in certain scenarios:

我们之所以使用是因为它提供了最高的灵活性，而无需在API服务器上进行配置更改。 除了RBAC，Kubernetes还具有多种授权策略。 目前，GitHub身份验证尚未完全删除管理员职责。 在某些情况下，仍然需要管理员：

1. If a user wants their own personal namespace, the admin still needs to create the namespace and set RBAC rules for this user
   如果用户需要自己的个人名称空间，则管理员仍需要创建该名称空间并为此用户设置RBAC规则
2. If there is a new project, the admin still needs to create the namespace and set RBAC rules for this project
   如果有一个新项目，管理员仍然需要创建名称空间并为此项目设置RBAC规则

When setting up the project, the admin can designate a team lead to control RBAC rules for the participating team members and control who has access to the project namespace.

设置项目时，管理员可以指定团队负责人，为参与团队的成员控制RBAC规则，并控制有权访问项目名称空间的人。

现在Oursky团队成员可以使用GitHub访问集群 (Now Oursky team members can access the cluster with GitHub)

Whenever our teammates need a new deployment for their project (even for personal ones), they could just obtain a token from GitHub. We hope this encourages our team to build something interesting without worrying about stable deployment. You are welcome to take a look at the exact implementation in . You can also feel free to implement this solution in your own cluster.

每当我们的队友需要为他们的项目进行新的部署时(甚至是个人的)，他们都可以从GitHub获得令牌。 我们希望这会鼓励我们的团队构建一些有趣的东西而不必担心稳定的部署。 欢迎您查看中的确切实现。 您也可以在自己的集群中随意实施此解决方案。

Building an app? I’m currently working on an at that will make your job easier.

建立应用程式？ 我目前正在上从事的 ，这将使您的工作更轻松。

翻译自: