by cheungpat

通過cheungpat

我如何構(gòu)建Kubernetes集群，以便我的同事可以更快地部署應(yīng)用程序 (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.

您如何鼓勵(lì)您的開發(fā)團(tuán)隊(duì)構(gòu)建更多項(xiàng)目而又不會(huì)陷入部署困境？ 作為一家構(gòu)建移動(dòng)和Web產(chǎn)品的公司，我們首先要?jiǎng)?chuàng)造一個(gè)環(huán)境，使團(tuán)隊(duì)成員專注于構(gòu)建而不是部署。

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.

但是，即使我們有一個(gè)部署平臺(tái)，我們?nèi)匀恍枰腥藖砉芾砉芾怼?作為工程師，我們必須重復(fù)的任何事情都想實(shí)現(xiàn)自動(dòng)化。

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

使開發(fā)人員能夠訪問我們的部署平臺(tái)的安全方法是什么？

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

我們希望允許我們的開發(fā)人員構(gòu)建自己的項(xiàng)目(也許是個(gè)人的)，而無需征求管理員的許可或資源來部署新的應(yīng)用程序進(jìn)行測(cè)試或試驗(yàn)

Our developers can deploy their own application, update it, or remove it

我們的開發(fā)人員可以部署，更新或刪除自己的應(yīng)用程序

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身份驗(yàn)證。 對(duì)于不認(rèn)識(shí)的人， Kubernetes是Google開發(fā)的可用于生產(chǎn)的容器編排引擎。 這是一個(gè)開放源代碼平臺(tái)，可實(shí)現(xiàn)容器操作的自動(dòng)化。 跨主機(jī)(或節(jié)點(diǎn))群集進(jìn)行部署和擴(kuò)展之類的事情。

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，我們可以為需要部署應(yīng)用程序并無縫推出新功能的客戶提供支持，而無需沉重的管理開銷。 容器技術(shù)是打包后端應(yīng)用程序并在服務(wù)器上運(yùn)行它們的良好實(shí)踐。我們?cè)谕患褐羞\(yùn)行來自不同項(xiàng)目的容器。 Kubernetes使我們可以減少對(duì)單個(gè)服務(wù)器的關(guān)注。 我們可能會(huì)將Kubernetes視為“一臺(tái)大型計(jì)算機(jī)”，我們的團(tuán)隊(duì)成員可以在其中運(yùn)行容器。

使我們的團(tuán)隊(duì)可以訪問集群 (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:

我們希望同事?lián)碛凶约旱挠脩魬{據(jù)才能訪問群集。 由于他們不需要為每個(gè)用戶開設(shè)新帳戶，因此節(jié)省了管理員時(shí)間。 新用戶可以自己生成憑據(jù)，或者如果丟失憑據(jù)則可以生成新憑據(jù)。 我們正在尋找一種可以滿足以下所有要求的身份驗(yàn)證解決方案：

Admin time should be saved (since they are also our developers)

應(yīng)當(dāng)節(jié)省管理員時(shí)間(因?yàn)樗麄円彩俏覀兊拈_發(fā)人員)

New users can generate their own credentials without needing the admin

新用戶無需管理員即可生成自己的憑據(jù)

User credential is always private for security reasons

出于安全原因，用戶憑據(jù)始終是私有的

Developers have their own space to experiment

開發(fā)人員有自己的實(shí)驗(yàn)空間

Project spaces can be accessed and changed by multiple users

多個(gè)用戶可以訪問和更改項(xiàng)目空間

In the future, we may want to enable auditing to track changes

將來，我們可能希望啟用審核以跟蹤更改

嘗試-大多數(shù)現(xiàn)有的身份驗(yàn)證策略不適合 (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.

首先，許多現(xiàn)有的身份驗(yàn)證方法仍然需要管理員來生成或管理帳戶。 這是我們排除其中大多數(shù)的主要原因。 下面，我將列出一些常見的參考，但是如果您只是想了解我們?yōu)槭裁催x擇GitHub身份驗(yàn)證，請(qǐng)隨時(shí)跳到下一部分。

基于證書 (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.

每個(gè)用戶都有自己的私有SSL證書來訪問群集，這可能會(huì)很復(fù)雜。 這意味著管理員需要管理公共密鑰基礎(chǔ)結(jié)構(gòu)(即證書頒發(fā)機(jī)構(gòu))來簽署用戶證書。 此外，在1)有新用戶，2)證書過期或3)用戶丟失了證書/私鑰時(shí)，管理員需要執(zhí)行此操作。 最后，當(dāng)用戶想在多臺(tái)計(jì)算機(jī)上使用相同的SSL證書時(shí)，用戶必須管理自己的私鑰材料，這是潛在的安全漏洞。

基于用戶名/密碼 (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.

由于每個(gè)人都知道如何使用用戶名和密碼，因此比基于證書的身份驗(yàn)證更容易實(shí)現(xiàn)。 但是，Kubernetes沒有一個(gè)易于使用的界面供我們的團(tuán)隊(duì)成員創(chuàng)建自己的帳戶，這意味著我們?nèi)匀恍枰芾韱T才能為每個(gè)用戶生成一組用戶名和密碼。 此外，這意味著如果用戶丟失密碼，管理員需要重設(shè)用戶密碼。 如果沒有用戶友好的UI，用戶也很難更改密碼。 當(dāng)用戶名/密碼列表更改時(shí)，Kubernetes還要求重新啟動(dòng)API服務(wù)器。

預(yù)先生成的基于令牌的 (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) ：在我們構(gòu)建Kubernetes集群時(shí)，OIDC支持還沒有完全成熟，并且我們不確定如何將OIDC與Google帳戶集成。 如果OIDC由Kubernetes API服務(wù)器和客戶端命令完全實(shí)現(xiàn)(這是我上次檢查時(shí)未實(shí)現(xiàn))，則是一個(gè)不錯(cuò)的選擇。

使用GitHub身份驗(yàn)證的5個(gè)簡(jiǎn)單原因 (5 simple reasons to use GitHub authentication)

GitHub Authentication was a simple solution because:

GitHub身份驗(yàn)證是一個(gè)簡(jiǎn)單的解決方案，因?yàn)?#xff1a;

Everyone in our company already has a GitHub account

我們公司中的每個(gè)人都已經(jīng)有一個(gè)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

由于用戶可以通過生成新令牌訪問不同計(jì)算機(jī)上的Kubernetes集群，因此具有很高的靈活性

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

始終可以通過刪除github.com上的訪問令牌來撤消訪問(以防github令牌泄漏)

實(shí)施GitHub身份驗(yàn)證 (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令牌對(duì)團(tuán)隊(duì)成員進(jìn)行身份驗(yàn)證。 Kubernetes支持Webhook 令牌身份驗(yàn)證器插件，以允許遠(yuǎn)程服務(wù)進(jìn)行身份驗(yàn)證。 因此，我們要做的就是實(shí)現(xiàn)一個(gè)Webhook來驗(yàn)證令牌。 當(dāng)用戶嘗試通過Kubernetes API進(jìn)行身份驗(yàn)證時(shí)，Kubernetes API服務(wù)器將調(diào)用此身份驗(yàn)證器以驗(yàn)證承載令牌。 該驗(yàn)證器使用GitHub API檢查訪問令牌是否有效，并通過檢查請(qǐng)求的用戶是否有權(quán)訪問資源來將GitHub用戶名返回給API服務(wù)器。 它使用基于角色的訪問控制(RBAC)規(guī)則。 請(qǐng)注意，我們必須在Kubernetes主服務(wù)器上運(yùn)行webhook，以便API服務(wù)器訪問它。 這就是我們實(shí)際實(shí)現(xiàn)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，是因?yàn)樗峁┝俗罡叩撵`活性，而無需在API服務(wù)器上進(jìn)行配置更改。 除了RBAC，Kubernetes還具有多種授權(quán)策略。 目前，GitHub身份驗(yàn)證尚未完全刪除管理員職責(zé)。 在某些情況下，仍然需要管理員：

If a user wants their own personal namespace, the admin still needs to create the namespace and set RBAC rules for this user

如果用戶需要自己的個(gè)人名稱空間，則管理員仍需要?jiǎng)?chuàng)建該名稱空間并為此用戶設(shè)置RBAC規(guī)則

If there is a new project, the admin still needs to create the namespace and set RBAC rules for this project

如果有一個(gè)新項(xiàng)目，管理員仍然需要?jiǎng)?chuàng)建名稱空間并為此項(xiàng)目設(shè)置RBAC規(guī)則

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.

設(shè)置項(xiàng)目時(shí)，管理員可以指定團(tuán)隊(duì)負(fù)責(zé)人，為參與團(tuán)隊(duì)的成員控制RBAC規(guī)則，并控制有權(quán)訪問項(xiàng)目名稱空間的人。

現(xiàn)在Oursky團(tuán)隊(duì)成員可以使用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.

每當(dāng)我們的隊(duì)友需要為他們的項(xiàng)目進(jìn)行新的部署時(shí)(甚至是個(gè)人的)，他們都可以從GitHub獲得令牌。 我們希望這會(huì)鼓勵(lì)我們的團(tuán)隊(duì)構(gòu)建一些有趣的東西而不必?fù)?dān)心穩(wěn)定的部署。 歡迎您查看此github存儲(chǔ)庫中的確切實(shí)現(xiàn)。 您也可以在自己的集群中隨意實(shí)施此解決方案。

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

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

翻譯自: https://www.freecodecamp.org/news/how-i-built-a-kubernetes-cluster-so-my-coworkers-could-deploy-apps-faster-ad5567bf6fa8/

總結(jié)

以上是生活随笔為你收集整理的我如何构建Kubernetes集群，以便我的同事可以更快地部署应用程序的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。