helm部署仓库中没有的包
Before we dive into the Helm package manager, I'm going to explain some key concepts to deploying any application anywhere. I'll also give you a brief introduction to Kubernetes terminology.
在深入研究Helm软件包管理器之前 ，我将解释一些在任何地方部署任何应用程序的关键概念。 我还将为您简要介绍Kubernetes术语 。
什么是Kubernetes？ (What is Kubernetes?)
Kubernetes (K8s) is an open-source system for automating deployment, scaling, and management of containerized applications
Kubernetes(K8s)是一个开源系统，用于自动化容器化应用程序的部署，扩展和管理
Kubernetes (K8s) is an open-source system for automating deployment, scaling, and management of containerized applications kubernetes.io
Kubernetes(K8s)是一个开源系统，用于自动化容器化应用程序kubernetes.io的部署，扩展和管理。
Now you might be asking yourself, "Well, what does that mean?"
现在您可能会问自己：“嗯，那是什么意思？”
Kubernetes is essentially a very nice set of APIs for deploying, managing, and scaling applications.
Kubernetes本质上是一组非常好的API，用于部署，管理和扩展应用程序。
The applications are packaged with Docker, and then the logic surrounding the deployment of the application is expressed using Helm templates. The templates themselves are instructions that are then run using the Kubernetes API.
应用程序与Docker打包在一起，然后使用Helm模板表达围绕应用程序部署的逻辑。 模板本身就是使用Kubernetes API运行的指令。
There are a ton of Helm packages already created to take care of your application deployment needs!
已经创建了大量的Helm软件包来满足您的应用程序部署需求！
I like to think of Kubernetes + Helm as a one stop shop for my application DevOps needs.
我喜欢将Kubernetes + Helm视为满足我的应用程序DevOps需求的一站式服务。
有趣的事实时间！ (Fun Fact Time!)
The entire container ecosystem, including Docker, has a very fun nautical theme. Docker has whales, Kubernetes has pods (of whales), and its logo looks like the steering portion of a ship, and Helm is the helm of a ship.
包括Docker在内的整个容器生态系统都有一个非常有趣的航海主题。 Docker有一条鲸鱼，Kubernetes有(鲸鱼)吊舱，其徽标看起来像是船舶的转向部分，Helm是船舶的头盔。
Aren't they cute?
他们不是很可爱吗？
在Kubernetes上部署应用程序 (Deploying an Application on Kubernetes)
First of all, no matter where you deploy an application there are going to be some things that remain the same anywhere, and I do mean anywhere! ;-) Whether you are deploying to your laptop, a remote server, an AWS EC2 instance, High Performance Computing systems, or Kubernetes, the underlying concepts do not change.
首先，无论您将应用程序部署在何处，都会在某些地方保持相同，而我的意思是在任何地方！ ;-)无论您是部署到便携式计算机，远程服务器，AWS EC2实例，高性能计算系统还是Kubernetes，其基本概念都不会改变。
I think of pretty much everything, tech concepts in particular, as a series of layers. Once you understand what those fundamental layers are you can get cooking.
我将几乎所有内容(尤其是技术概念)视为一系列层次。 了解了这些基本层之后，您就可以开始烹饪了。
应用层 (Application Layers)
These are:
这些是：
| General | Kubernetes |
|---|---|
| Data Layer | PVC or Persistent Volume Claims |
| Application Layer | Pods |
| Services | SVC |
| 一般 | Kubernetes |
|---|---|
| 资料层 | PVC或永久体积声明 |
| 应用层 | 豆荚 |
| 服务 | SVC |
Let's take these on one at a time.
让我们一次来处理这些。
Data Layer / Persistent Volume Claims (PVCs)
数据层/永久体积声明(PVC)
This is nice and straight forward. When you need to persist data you persist it to a filesystem. This can be local storage or some sort of networked file system (NFS). If you are using a database the database also eventually persists to a filesystem.
这很好，很简单。 当您需要保留数据时，可以将其保留到文件系统中。 这可以是本地存储，也可以是某种网络文件系统(NFS)。 如果您使用的是数据库，则数据库最终还将持久保存到文件系统中。
Application Layer / Pods
应用层/豆荚
The application layer is what we typically think of in a deployment. Its the part we apt-get install, npm run or docker run. An application could be an NGINX web server, a Python or Node.js app, or a Spark application to name a few.
应用层是我们通常在部署中所想到的。 它是我们apt-get install ， npm run或docker run 。 应用程序可以是NGINX Web服务器，Python或Node.js应用程序或Spark应用程序。
Applications are either Kubernetes Deployments or Stateful Set, depending on whether or not they persist data (or have a state).
应用程序是Kubernetes 部署还是状态集 ，具体取决于它们是否保留数据(或具有状态)。
A MySQL database would be an example of a Stateful application. It needs to keep track of information about itself.
MySQL数据库将是有状态应用程序的示例。 它需要跟踪有关自身的信息。
An NGINX server would be a Kubernetes Deployment, because it does not need to keep track of any information about itself — it is stateless.
NGINX服务器将是Kubernetes部署，因为它不需要跟踪有关其自身的任何信息-它是无状态的 。
Services Layer / SVC
服务层/ SVC
The services layer is where we expose our Application to the outside world. This is generally accomplished by saying "Hey, I have an app running on this port". You might have run these directly, or done something like a proxy pass in NGINX or Apache.
服务层是我们将应用程序暴露给外界的地方。 通常可以通过说“嘿，我在此端口上运行一个应用程序”来完成此操作。 您可能已经直接运行了它们，或者在NGINX或Apache中做了类似代理传递的操作。
站点可靠性层 (Site Reliability Layers)
Site reliability is our ability to confidently say our application is up, running, and will probably stay up and running!
站点可靠性是我们自信地说我们的应用程序已启动，正在运行，并且可能会继续运行的能力！
To be real, we want an API to essentially do this. 😜
确实，我们希望API能够做到这一点。 😜
XKCD - Hard Reboot
XKCD-硬重启
| General | Kubernetes |
|---|---|
| Monitoring | metrics-server |
| Scaling (or Load Balancing) | Horizontal Pod Autoscaler (HPA) |
| Service Rules | Container specs |
| 一般 | Kubernetes |
|---|---|
| 监控方式 | 指标服务器 |
| 扩展(或负载平衡) | 水平荚自动缩放器(HPA) |
| 服务规则 | 容器规格 |
Monitoring Layer / Metrics Server
监控层/度量服务器
The monitoring layer answers the question "How is our app doing"? Ideally it would answer questions like "How much CPU is left on that machine?" and "Are we out of memory yet"?
监视层回答问题“我们的应用程序如何运行”？ 理想情况下，它将回答诸如“该计算机上还剩多少CPU？”之类的问题。 和“我们内存不足了吗”？
Scaling Layer / HPA
缩放层/ HPA
Have you ever had an application that worked great until too many people started using it at once? You take care of this by scaling the instances of your application up or down.
在有太多人一次使用它之前，您是否曾经有过一款性能良好的应用程序？ 您可以通过向上或向下缩放应用程序实例来解决此问题。
With web applications, you'll often see the term load balancing, too. This functionality is built into many process managers and https servers such as PM2 and Gunicorn.
在Web应用程序中，您也经常会看到术语负载平衡。 许多流程管理器和https服务器(例如PM2和Gunicorn)都内置了此功能。
In Kubernetes you accomplish this with a Horizontal Pod Autoscaler, or HPA, which you give specific rules for how to scale up or down.
在Kubernetes中，您可以使用Horizontal Pod Autoscaler或HPA来完成此任务，您可以为其指定具体的缩放比例规则。
Service Rules Layer
服务规则层
Have you ever wanted to automate when / how your application should restart? Maybe you want it to restart 3 times and then give up. Or maybe you want it to restart, but not right away.
您是否曾经想过何时/如何重启应用程序进行自动化？ 也许您希望它重新启动3次，然后放弃。 或者，也许您希望它重新启动，但不立即启动。
Give it some time! You may also want some objective measure to test whether or not you application is up and running.
给它一点时间！ 您可能还需要一些客观的措施来测试您的应用程序是否已启动并正在运行。
在Kubernetes上部署应用程序 (Deploying Applications on Kubernetes)
Kubernetes applications can be deployed either through the CLI, or by writing YAML templates that describe the various PVCs, Pods (whether they are Deployments or Stateful sets), and Service (SVC) layers.
Kubernetes应用程序可以通过CLI进行部署，也可以通过编写描述各种PVC，Pod(无论是Deployment还是Stateful集)和Service(SVC)层的YAML模板进行部署。
头盔包管理器 (The Helm Package Manager)
Helm is the best way to find, share, and use software built for Kubernetes.
Helm是查找，共享和使用为Kubernetes构建的软件的最佳方法。
Helm is the best way to find, share, and use software built for Kubernetes. https://helm.sh/
Helm是查找，共享和使用为Kubernetes构建的软件的最佳方法。 https://helm.sh/
The Helm package manager allows us to wire up complex Kubernetes deployments into a single package, that can be installed with a single command.
Helm软件包管理器使我们能够将复杂的Kubernetes部署连接到一个软件包中，该软件包可以使用单个命令进行安装。
Helm uses a templating language on top of Kubernetes YAML definitions to allow more versatility to our deployments.
Helm在Kubernetes YAML定义之上使用了模板语言，以使我们的部署更具通用性。
Probably the most important point to note with Helm is that it has been widely accepted by the community. This means that there are lots of resources for using Helm, getting started, and also oodles of preconfigured Helm Charts!
Helm可能要注意的最重要一点是，它已被社区广泛接受。 这意味着有很多使用Helm的资源，入门指南以及大量预配置的Helm Charts！
It's very rare for me to ever have to create a Helm package completely from scratch. I can nearly always find a good starting point from one or more of the Helm charts that are already available.
对于我而言，完全从零开始创建Helm软件包非常罕见。 我几乎总是可以从一个或多个可用的Helm图表中找到一个良好的起点。
在Kubernetes上部署NGINX (Deploy NGINX on Kubernetes)
First, let's talk about a base NGINX deployment without Helm.
首先，让我们谈谈没有Helm的基本NGINX部署。
As you can see, there is a lot of stuff to keep track of and we probably wouldn't be typing this by hand. That is where the Helm package manager comes in, but it's good to take a look to know what is happening first! ;-)
如您所见，有很多东西需要跟踪，我们可能不会手工输入。 这就是Helm软件包管理器的用武之地，但是最好先了解一下发生了什么！ ;-)
Now let's break down the different parts of the Kubernetes Deployment definition.
现在让我们分解一下Kubernetes部署定义的不同部分。
Metadata
元数据
I want to very briefly touch on the labels. Only briefly, because chances are you will be fine with the defaults and not need to touch them.
我想非常简短地触摸一下labels 。 仅简要介绍一下，因为您可以使用默认设置，而无需触摸它们。
One of the goals of Kubernetes is that it should abstract the actual physical server away. You shouldn't usually have to care if your app is running on node1 or node2. Of course at some point you do care, and then you will start to get into labels.
Kubernetes的目标之一是应该将实际的物理服务器抽象出来。 通常，您不必关心您的应用程序是在node1还是node2上运行。 当然，在某些时候您确实会在意，然后您将开始涉足标签。
Until then, don't worry about them and just stick with the defaults.
在此之前，请不要担心它们，而只需遵循默认值即可。
Containers
货柜
This is the part of the application that will be most relevant to you when you are deploying applications. You need to define your containers.
这是应用程序中与您部署应用程序最相关的部分。 您需要定义容器。
A single Deployment Pod can have many containers. That container has, at the very least a name, a repo, and a tag:
单个Deployment Pod可以具有多个容器。 该容器至少具有一个name ，一个repo和一个tag ：
Once you have the base you need to define the ports that will get picked up by the service. See that separation of concerns?:
一旦有了基础，就需要定义将由服务使用的端口。 看到关注点分离了吗？：
App Rules
应用规则
Then, at some point, we want to know if our app is running. We can even determine exactly where it is in it's lifecycle with the various hooks:
然后，在某个时候，我们想知道我们的应用程序是否正在运行。 我们甚至可以使用各种挂钩来确定它在生命周期中的确切位置：
Names
名字
This is more of a general concept, but I do want to point out that giving things names is very important in the Kubernetes ecosystem. Notice that we gave our container and port a name. Later on when we need to refer to them we use that name.
这更多是一个笼统的概念，但我确实要指出，在Kubernetes生态系统中，给事物起名字非常重要。 注意，我们给container和port name 。 稍后，当我们需要引用它们时，我们使用该name 。
使用Helm Chart在Kubernetes上部署NGINX (Deploy NGINX on Kubernetes with a Helm Chart )
The Helm package manager creates a series of templates that can be modified through the Helm CLI. Each of these templates corresponds to one of our Kubernetes types that we discussed earlier.
Helm软件包管理器创建了一系列模板，可以通过Helm CLI对其进行修改。 这些模板中的每一个都对应于我们前面讨论的Kubernetes类型之一。
Here is an example of the bitnami/nginx helm chart:
这是bitnami / nginx舵图的示例：
Here is that same block with the Helm templating language. For the sake of brevity I have omitted some parts of the template. If you would like to see the whole thing you can take a look at it in the GitHub repo.
这与Helm模板语言相同。 为了简洁起见，我省略了模板的某些部分。 如果您想了解全部内容，可以在GitHub存储库中进行查看。
(This is for demonstration purposes and is not a fully functional Helm chart. Please don't use this. Grab the actual Helm chart instead.)
(这只是出于演示目的，而不是功能齐全的Helm图表。请不要使用它。而是获取实际的Helm图表。)
“舵模板”值从何而来？ (Where do the Helm Template values come from?)
Now, this is what I really like about Helm. The values that are exposed in the template come from one of two places.
现在，这就是我真正喜欢Helm的原因。 模板中公开的值来自两个位置之一。
Templated Functions
模板化功能
They come from the template itself, as shown here.
它们来自模板本身，如下所示。
{{ template "nginx.fullname" . }}We can find that this is defined in our templates/_helpers.tpl, which is a way of getting more complex functions that we could get with just a yaml file.
我们可以发现这是在我们的templates/_helpers.tpl定义的，这是一种获取更复杂功能的方法，而这些功能可以通过yaml文件获得。
Values exposed in the Values.yaml
在Values.yaml中公开的值
This is actually a very neat feature and what makes Helm so powerful and configurable.
这实际上是一个非常简洁的功能，这使Helm如此强大和可配置。
Each Helm chart comes along with a values.yaml. You can put whatever you want in the values.yaml, and then use it throughout your Helm chart, and it's exposed through the CLI!
每个Helm图表都带有values.yaml 。 您可以将所需的内容放在values.yaml ，然后在整个Helm图表中使用它，并且它通过CLI公开！
Then we see this referred to in our templates as:
然后，我们在模板中将其称为：
Everything in the values.yaml can also be modified through the Helm CLI:
还可以通过Helm CLI修改values.yaml所有内容：
It would then render the containers[0].image as image: docker.io/bitnami/nginx:my-new-tag
然后它将containers[0].image为image: docker.io/bitnami/nginx:my-new-tag
结语 (Wrap Up)
That's it! I hope that you've learned a little about Kubernetes and its package manager Helm. Hopefully it isn't quite as scary as it once was.
而已！ 我希望您对Kubernetes及其程序包管理器Helm有所了解。 希望它不会像以前那样可怕。
翻译自: https://www.freecodecamp.org/news/an-introduction-to-the-helm-package-manager-for-kubernetes/
helm部署仓库中没有的包
