我如何構建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?

使開發人員能夠訪問我們的部署平臺的安全方法是什么？

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
我們希望允許我們的開發人員構建自己的項目(也許是個人的)，而無需征求管理員的許可或資源來部署新的應用程序進行測試或試驗
Our developers can deploy their own application, update it, or remove it
我們的開發人員可以部署，更新或刪除自己的應用程序
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, Kubernetes 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身份驗證。對于不認識的人， Kubernetes是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:

我們希望同事擁有自己的用戶憑據才能訪問群集。由于他們不需要為每個用戶開設新帳戶，因此節省了管理員時間。新用戶可以自己生成憑據，或者如果丟失憑據則可以生成新憑據。我們正在尋找一種可以滿足以下所有要求的身份驗證解決方案：

Admin time should be saved (since they are also our developers)
應當節省管理員時間(因為他們也是我們的開發人員)
New users can generate their own credentials without needing the admin
新用戶無需管理員即可生成自己的憑據
User credential is always private for security reasons
出于安全原因，用戶憑據始終是私有的
Developers have their own space to experiment
開發人員有自己的實驗空間
Project spaces can be accessed and changed by multiple users
多個用戶可以訪問和更改項目空間
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. Open ID Connect (OIDC): 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).

與基于用戶名/密碼的方法類似，管理員仍需要參與生成令牌。 開放ID連接(OIDC) ：在我們構建Kubernetes集群時，OIDC支持還沒有完全成熟，并且我們不確定如何將OIDC與Google帳戶集成。如果OIDC由Kubernetes API服務器和客戶端命令完全實現(這是我上次檢查時未實現)，則是一個不錯的選擇。

使用GitHub身份驗證的5個簡單原因 (5 simple reasons to use GitHub authentication)

GitHub Authentication was a simple solution because:

GitHub身份驗證是一個簡單的解決方案，因為：

Everyone in our company already has a GitHub account
我們公司中的每個人都已經有一個GitHub帳戶
This solves our admin overhead problem since people manage their own tokens
由于人們管理自己的令牌，這解決了我們的管理開銷問題
Users can easily generate an access token on github.com
用戶可以在github.com上輕松生成訪問令牌
It’s highly flexible as users can access the Kubernetes cluster on different computers, just by generating new tokens
由于用戶可以通過生成新令牌訪問不同計算機上的Kubernetes集群，因此具有很高的靈活性
Access can always be revoked by removing the access token on github.com (in case the github token is leaked)
始終可以通過刪除github.com上的訪問令牌來撤消訪問(以防github令牌泄漏)

實施GitHub身份驗證 (Implementing GitHub authentication)

We authenticate our team members using GitHub token. Kubernetes supports a webhook token authenticator plugin 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 implement the WebHook:

我們使用GitHub令牌對團隊成員進行身份驗證。 Kubernetes支持Webhook 令牌身份驗證器插件，以允許遠程服務進行身份驗證。因此，我們要做的就是實現一個Webhook來驗證令牌。當用戶嘗試通過Kubernetes API進行身份驗證時，Kubernetes API服務器將調用此身份驗證器以驗證承載令牌。該驗證器使用GitHub API檢查訪問令牌是否有效，并通過檢查請求的用戶是否有權訪問資源來將GitHub用戶名返回給API服務器。它使用基于角色的訪問控制(RBAC)規則。請注意，我們必須在Kubernetes主服務器上運行webhook，以便API服務器訪問它。這就是我們實際實現WebHook的方式：

We used RBAC 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:

我們之所以使用RBAC，是因為它提供了最高的靈活性，而無需在API服務器上進行配置更改。除了RBAC，Kubernetes還具有多種授權策略。目前，GitHub身份驗證尚未完全刪除管理員職責。在某些情況下，仍然需要管理員：

If a user wants their own personal namespace, the admin still needs to create the namespace and set RBAC rules for this user
如果用戶需要自己的個人名稱空間，則管理員仍需要創建該名稱空間并為此用戶設置RBAC規則
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 this github repository. You can also feel free to implement this solution in your own cluster.

每當我們的隊友需要為他們的項目進行新的部署時(甚至是個人的)，他們都可以從GitHub獲得令牌。我們希望這會鼓勵我們的團隊構建一些有趣的東西而不必擔心穩定的部署。歡迎您查看此github存儲庫中的確切實現。您也可以在自己的集群中隨意實施此解決方案。

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

建立應用程式？ 我目前正在Oursky上從事開源后端的工作，這將使您的工作更輕松。