kubernetes_距Kubernetes 11分钟路程

kubernetes

So you’ve heard about Kubernetes, you know it’s something about clusters, high availability and…deployments?. But every time you hear about a new technology you say to yourself “Oh, here we go again. Another whole pack of documentation pages that will take me ages to read until I can have something working and I don’t even know if it’s worth the effort”. I said that. A million times. And I’ll surely keep doing it. So this should be a super-packed doc that will give you a slightly more than basic understanding of the platform, and hopefully give you an idea if it’s the thing for you. You’re just 11 minutes away from it. Here we go.

所以您听说过Kubernetes，您知道它与集群，高可用性和…部署有关。 但是，每当您听到一项新技术时，您都会对自己说： “哦，我们再来一次。 另一整套文档页面将使我花很多时间才能阅读，直到我可以进行 某些 工作 为止 ，甚至不知道是否值得付出努力 。” 我说过了。 一百万次。 而且我一定会继续做下去。 因此，这应该是一个超级打包的文档，它将为您提供对该平台的基本了解，并希望让您了解它是否适​​合您。 您距离它只有11分钟的路程。 开始了。

According to their official website, they say:

根据他们的官方网站，他们说：

Kubernetes (K8s) is an open-source system for automating deployment, scaling, and management of containerized applications.

Kubernetes(K8s)是一个开源系统，用于自动化容器化应用程序的部署，扩展和管理。

I think it’s a short yet simple definition. The most common containerisation platform used in Kubernetes is Docker. So this article will start with a simple Docker image, and explain the different moving parts on a Kubernetes cluster that will allow you to deploy and run your application, scale it and manage it.

我认为这是一个简短而简单的定义。 Kubernetes中最常用的容器化平台是Docker 。 因此，本文将从一个简单的Docker镜像开始，并说明Kubernetes集群上的各个移动部件，这些部件将允许您部署和运行应用程序，对其进行扩展和管理。

Never used Docker? Check out below the first part of an article series I wrote to run a project on Kubernetes, where I give a brief practical explanation of Docker and how it can be used. The example is using a Java Spring Boot application, but a lot of the principles/practices dictated in the article can be extrapolated to other languages/frameworks.

从未使用过Docker？ 在我写的在Kubernetes上运行一个项目的文章系列的第一部分下面，请检阅，其中我对Docker及其使用方法进行了简要的实用说明。 该示例使用的是Java Spring Boot应用程序，但是可以将本文中规定的许多原理/实践推论到其他语言/框架。

基础 (The basics)

For starters, if you’ve never heard of the term cluster, just think about it as a group of computers working as a unit, with some processes that coordinate the communication and actions between all these computers, or nodes. The process of managing this and the workloads operating in the cluster is called orchestration (as in Kubernetes is an open-source container-orchestration system for…).

对于初学者，如果您从未听说过“ 集群 ”一词，只需将其视为一组作为一个单元工作的计算机，并通过一些进程来协调所有这些计算机或节点之间的通信和操作。 管理它的过程以及在群集中运行的工作负载的过程称为编排 (如Kubernetes中的…那样， 它是一个开源容器编排系统 )。

To understand the basics of the architecture, think of it as a matryoshka (at least it helped me, I’m kind of a visual type of person).

要了解该架构的基础知识，可以将其视为俄罗斯套娃 (至少它对我有帮助，我是一种视觉类型的人)。

编排工作量 (Orchestrating the workload)

First of all, your container (the one that hosts and runs your Docker image) will run on a Pod. This is the smallest unit of your workload managed by Kubernetes — think of it as the logical units, the instances, of your application. Each Pod can have one or more containers. The idea is that Pods are disposable and you don’t manage them directly: instead you manage a controller that will be in charge of maintaining a given number of these. These Pods contain an ephemeral storage drive attached to it, that will be destroyed when the Pod is destroyed. How can they be disposable? Because you will have a specification (simply called spec) that will tell Kubernetes exactly how its containers should start, so if one dies, there will be another one just like it ready to be fired up.

首先，您的容器(托管和运行Docker映像的容器)将在Pod上运行。 这是Kubernetes管理的最小工作量单位-将其视为应用程序的逻辑单位， 实例 。 每个Pod可以有一个或多个容器。 这个想法是，Pods是一次性的，您不直接对其进行管理：相反，您将管理一个控制器，该控制器负责维护给定数量的控制器。 这些Pod包含一个附加的临时存储驱动器，当Pod销毁时，该驱动器将被销毁。 它们怎么可以一次性使用？ 因为您将拥有一个规范(简称为spec )，它将准确地告诉Kubernetes容器应如何启动，因此，如果一个容器死亡，将有另一个容器准备好启动。

Containers are run in Pods, a ReplicaSet is in charge of ensuring a given number of them are running at any point in time. The Deployment orchestrates all the necessary steps to start and have running the Pods.

容器在Pod中运行，ReplicaSet负责确保给定数量的容器在任何时间点都在运行。 部署精心安排了启动和运行Pod的所有必要步骤。

Now it’s the part where you say “What the…? Where did all those boxes come from? This was supposed to be simple!”. You may say it to yourself. Or even out loud. And your dog may stare at you not really understanding what’s going on. The Deployment: this is the place where you tell Kubernetes how to run your Pods (what containers they’ll have, which Docker image to use, how many resources to allocate, which configuration variables to pick), how many instances you want to spawn (and how to assess their health), etc. In other words, where you’ll define the spec. On the other hand, the ReplicaSet is the responsible of ensuring that the desired number of Pods (“replicas”) are running at any point in time and restarting/replacing them if necessary. It’ll also have for instance the strategy with which the Pods should be replaced when rolling out a new version (i.e.: at least 50% of the new version should be deployed before terminating the Pods of the old version).

现在这是您说“ 什么……？ ”的部分。 这些盒子从哪里来？ 这应该很简单！”。 您可以对自己说。 甚至响亮。 而且您的狗可能盯着您，而不真正了解发生了什么。 部署 ：在这里您可以告诉Kubernetes如何运行Pod(它们将拥有哪些容器，要使用哪个Docker映像，要分配多少资源，要选择哪些配置变量)，要产生的实例数量(以及如何评估其健康状况)等。换句话说，您将在哪里定义规范 。 另一方面， ReplicaSet负责确保所需数量的Pod(“ 副本 ”)在任何时间运行，并在必要时重新启动/替换它们。 例如，它还具有在推出新版本时应使用Pod替换的策略(即：在终止旧版本的Pods之前，应至少部署新版本的50％)。

When creating a Deployment, a ReplicaSet is automatically generated to satisfy the replication requirements. It’s also possible to manually create a ReplicaSet, although it’s not recommended.

创建展开时，将自动生成一个ReplicaSet以满足复制要求。 尽管不建议这样做，也可以手动创建ReplicaSet。

Yes, I know, now you’re going something like: “Seb, this is so far the most beautiful yet simple explanation of Deployments in Kubernetes I’ve ever seen in my life…but I got lost already, how the **** am I supposed to access my API with all these layers? I just want to run a simple curl like in the ol’ days”. Enter the Service. This little fella will be the one exposing your Pods to the “outside”. Why the quotes? Because the “outside” can vary depending if the requests come from within or outside the cluster, and so will the type of Service you’ll use:

是的，我知道，现在您将执行以下操作： “ Seb，这是迄今为止我一生中见过的关于Kubernetes中部署的最美丽，最简单的解释……但是我已经迷路了，如何*是否应该通过所有这些层访问我的API？ 我只想像现在这样简单地卷发。” 输入服务 。 这个小家伙将使您的Pod暴露在“外面”。 为什么要引用？ 因为“外部”可能会有所不同，具体取决于请求是来自集群内部还是外部，因此您将使用的服务类型也会有所不同：

• ClusterIP — your service will only be accessible from within the cluster. It will have an allocated IP which you can use to contact your application.

  ClusterIP-您的服务只能在群集内访问。 它将具有分配的IP，您可以使用该IP与您的应用程序联系。

• NodePort — your service will be exposed on a static port on each Node port, accessible outside the cluster.

  NodePort-您的服务将显示在每个Node端口的静态端口上，可在群集外部访问。

• LoadBalancer — the cluster requests a Load Balancer to the cloud provider, in the form of a static IP (extra charges might apply here). This means it’s accessible outside the cluster too.

  LoadBalancer-群集以静态IP的形式向云提供商请求负载均衡器(此处可能需要支付额外费用)。 这意味着它也可以在集群外部访问。

• ExternalName — creates a CNAME record in Kubernetes’ internal DNS (for example subdomain.domain.com) that will “override” the real DNS record (only within the cluster). For instance, let’s say you’re migrating your workload from your own datacenter and you normally access your DB on db-01.example.com, and before migrating all of it to Kubernetes, you want to migrate only the test environment so you deploy the DB in your cluster. You don’t need to change your application code: just by creating an ExternalName service all the requests will be properly re-routed to the new instance.

  ExternalName — 在Kubernetes的内部DNS(例如subdomain.domain.com )中创建一个CNAME记录 ，该记录将“覆盖”真实的DNS记录(仅在群集中)。 例如，假设您要从自己的数据中心迁移工作负载，并且通常在db-01.example.com上访问数据库，并且在将所有数据迁移到Kubernetes之前，只想迁移测试环境，以便进行部署集群中的数据库。 您不需要更改应用程序代码：只需创建一个ExternalName服务，所有请求都将正确地重新路由到新实例。

ExternalName service created, hence, the requests to ExternalName服务，因此，对 db-01.example.com will resolve normally. In the cluster on the right, the Service is created so the same domain will resolve internally. db-01.example.com的请求将正常解决。 在右侧的群集中，将创建服务，因此相同的域将在内部解析。

• None — this is called a “headless” service: it’s actually a ClusterIP service type with no clusterIP (if that makes sense?). It’s used in cases where you might need explicitly all the Pod IPs (one classic example is MongoDB, where the connection URLs on the client side requires all the instances IPs).

  无 -这被称为“ 无头 ”服务：它实际上是没有clusterIP的ClusterIP服务类型(是否有意义？)。 它用于可能需要显式使用所有Pod IP的情况(一个经典示例是MongoDB，其中客户端的连接URL需要所有实例IP)。

An example of A records automatically configured by the Service, pointing to the Pod IPs

服务自动配置的 A记录示例，指向Pod IP

It creates type A DNS records that will resolve under the service name (if you name your service headless, when doing ping headless from any Pod in the cluster, it will resolve one of the Pod IPs).

它创建将在服务名称下解析的Type A DNS记录(如果您将服务命名为headless ，则从群集中的任何Pod进行ping headless时，它将解析其中一个Pod IP。)

Just one small detail that for the purpose of simplicity I deliberately omitted because of a hard truth: Services don’t give a crap about your Deployments or ReplicaSets. They just want to know which Pods to route the incoming traffic to. So in reality, from the point of view of a Service, your cluster looks something like this:

为了简单起见，出于一个硬道理，我特意省略了一个小细节： 服务不会给您的Deployments或ReplicaSets带来麻烦。 他们只想知道将传入流量路由到哪个Pod。 因此，实际上，从服务的角度来看，您的集群看起来像这样：

indigo. To me it was just purple, but as it turns out, it’s not) 靛蓝 。对我来说，它只是紫色，但事实证明不是)

So for example, the green service will go: “OK, I received this request, who’s got a label app=green? You Pod number 1? There you go buddy. Next!”.

因此，例如，绿色服务将变为： “好，我收到了此请求，谁得到了标签 app=green ？ 您的Pod号为1？ 那里你去哥们。 下一个！”。

Ok, to summarise what we have so far:

好的，总结一下到目前为止我们所拥有的：

• Pods — the smallest computing unit on Kubernetes. These are the instances of your application.
  Pods-Kubernetes上最小的计算单元。 这些是您的应用程序的实例。
• ReplicaSet — the controller responsible of ensuring a certain number of Pods running at any point in time.
  ReplicaSet-负责确保一定数量的Pod在任何时间点运行的控制器。
• Deployment — the orchestra director, organises all the resources so your Pods can run the way you want them to. This will be what you’re going to mainly be working on.
  部署-乐团总监负责组织所有资源，以便您的Pod可以按所需方式运行。 这将是您将主要从事的工作。
• Service — a bridge to the “outside world”
  服务-通往“外部世界”的桥梁

奖励轨道：自动定标器 (Bonus track: Autoscalers)

There’s another component called HorizonalPodAutoscaler (HPA) that, based on some configurable metrics, can adjust the number of running Pods on a ReplicaSet to serve the incoming requests properly, and this number can fluctuate between previously defined upper and lower bounds. CPU, network packets per second, HTTP requests are just some examples of the metrics you can mix and match. This autoscaling will just affect Pods, so it needs to be complemented by a Node autoscaling, otherwise, depending on the bounds configured, there might not be enough resources to host them properly and some of them might not be scheduled.

还有一个称为Horizo​​nalPodAutoscaler(HPA)的组件，该组件可以基于一些可配置的指标来调整ReplicaSet上正在运行的Pod的数量，以正确地处理传入的请求，并且该数量可以在先前定义的上限和下限之间波动。 CPU，每秒网络数据包，HTTP请求只是您可以混合和匹配的指标的一些示例。 这种自动缩放只会影响Pods，因此需要通过Node自动缩放来进行补充，否则，根据配置的范围，可能没有足够的资源来正确托管它们，并且其中某些资源可能未安排。

配置对象 (Configuration objects)

In order to tell Kubernetes how to run our workloads, there are two main configuration objects that allow us to do that:

为了告诉Kubernetes如何运行我们的工作负载，有两个主要的配置对象可以让我们做到这一点：

• ConfigMaps — for general configuration

  ConfigMaps —用于常规配置

• Secrets — for sensitive information

  机密 -敏感信息

There’s not much more to say about this, both are key-value objects that will keep the data you throw at it. The main difference is that a Secret object will have some further considerations (because we’re talking about sensitive information), for example how you can consume it, when these values will be injected in the Pod lifecycle, etc. By default, Kubernetes doesn’t provide an encryption layer for Secrets so it relies on the provider for this (in exchange, for example, GCP provides by default encryption at rest in the Infrastructure layer, and also optionally in the application layer).

关于这一点，没有太多要说的了，它们都是键值对象，这些键值对象将保留您向其抛出的数据。 主要区别在于， Secret对象将需要进一步考虑(因为我们在谈论敏感信息)，例如，如何使用它，何时将这些值注入Pod生命周期等。默认情况下，Kubernetes不会不会为Secrets提供加密层，因此它依赖于提供者(例如，作为交换，GCP默认情况下在基础结构层以及应用程序层中提供静态加密 )。

安全 (Security)

Kubernetes has something called ServiceAccount, and it’s a way to represent a (machine) user that will be allowed to execute certain operations in the cluster. You can define as many as you want, but usually the default is enough. This Service account can be modified and, for example, be given permissions to read a private Container Registry (the repository where the Docker images that the Pods need will be pulled from) that requires authentication.

Kubernetes有一个称为ServiceAccount的东西，它是一种表示(机器)用户的方式，该用户将被允许在集群中执行某些操作。 您可以定义任意多个，但是通常默认值就足够了。 可以修改此Service帐户，例如，授予该服务帐户读取需要身份验证的私有Container Registry(将Pod所需的Docker映像从中提取的存储库)的权限。

Kubernetes内部架构注意事项 (Kubernetes internal architecture considerations)

• What I described aboved are some of what I call logical components of the cluster. Kubernetes has also the concept of Nodes — these in contrast I call them the physical part, which can be bare metal servers, VMs, etc where the Pods will be actually allocated to and consume resources from.

  我上面描述的是集群的一些逻辑组件。 Kubernetes还具有节点的概念-相比之下，我将它们称为物理部分，可以是裸机服务器，VM等，其中Pod将实际分配给它们并从中消耗资源。

• These Nodes are organised in NodePools — they allow you to manage different groups of Nodes that might differ in size, resources, etc within the same cluster. So if you wanted to assign certain workloads to a specific set of Nodes (because for instance, they require more memory than the rest), you could do it with these. Here the concepts of Taints and Tolerations apply, to establish Node affinity, but I won’t cover these at this time (tell me in the comments if you want to have an article about this).

  这些节点在NodePools中进行组织-它们使您可以管理同一集群中大小，资源等可能不同的不同节点组。 因此，如果您想将某些工作负载分配给一组特定的节点(例如，因为它们需要比其余节点更多的内存)，则可以使用这些来完成。 在这里， 污点和容差的概念适用于建立节点亲和力 ，但目前我不介绍这些(如果您想发表有关此事的文章，请在评论中告诉我)。

• Kubernetes has its own administrative workload, and that needs to run in your Nodes, so take this into account when sizing the Node pools. The cloud provider you use might add its own services, so that’s another

  Kubernetes有自己的管理工作量，需要在节点中运行，因此在确定节点池大小时应考虑到这一点。 您使用的云提供商可能会添加自己的服务，因此这是另一个

• Kubernetes organises the objects deployed in the cluster in namespaces. These provide another layer of isolation and security, so for instance, it’s possible to restrict access to certain namespaces to some users. By default, all user-generated workload will go to the default namespace, whilst Kubernetes workload belongs to the kube-system namespace.

  Kubernetes在名称空间中组织部署在集群中的对象。 这些提供了另一层隔离和安全性，因此，例如，可以限制某些用户对某些名称空间的访问。 默认情况下，所有用户生成的工作负载将进入默认名称空间，而Kubernetes工作负载属于kube-system名称空间。

Perhaps there are a few things that you’ll not be regularly involved with but that are good to know (useful for an interview when they ask you if you know Kubernetes, you might go like “Oh yeah, I regularly call my cluster’s control pane through its API to optimise the size of my NodePools” because “I replaced that 2 for a 3 in that textbox” doesn’t sound as fancy).

也许有些事情您不会经常参与，但是很容易了解(当他们询问您是否了解Kubernetes时，在采访中很有用，您可能会想起“哦，是的，我经常给集群的控制面板打电话通过其API优化NodePools的大小”，因为“我在那个文本框中用3替换了2”听起来并不花哨。

无状态与有状态 (Stateless vs stateful)

It’s one of the main differentiators in workloads, and it basically responds to this question: Do I need to keep track of the data stored in this particular Pod?.

它是工作负载的主要区别因素之一，并且基本上可以回答以下问题： 我是否需要跟踪存储在此特定Pod中的数据？ 。

If the answer is no, then you have a stateless deployment. Usually this is the case of most APIs, where the only data you could be saving in the storage is temporary/can be replicated from a spec (like logs, environment variables, config files, etc).

如果答案是否定的，那么您将进行无状态部署。 通常，大多数API都是这种情况，您可以保存在存储中的唯一数据是临时的，可以从规范中复制(例如日志，环境变量，配置文件等)。

If the answer is yes, well then you guessed right, it’s stateful. This means that each Pod will have a sticky ID and besides its ephemeral storage, will have attached a persistent storage that will belong to that Pod in particular. Even if Pods can eventually die and be restarted, the new Pod will take the identity of the deceased Pod (and will reuse the same persistent storage).

如果答案是肯定的，那么您就猜对了，这是有状态的 。 这意味着每个Pod都有一个粘性ID，并且除了其短暂存储之外，还将附加一个持久存储，该持久存储尤其属于该Pod。 即使Pod最终会死掉并重新启动，新Pod也会采用已故Pod的身份(并将重用相同的持久性存储)。

Actually, in Kubernetes a stateless deployment is called Deployment; while a stateful deployment is called StatefulSet

实际上，在Kubernetes中，无状态部署称为Deployment ； 而有状态部署称为StatefulSet

API (The API)

为什么要使用API​​？ (Why an API?)

The Kubernetes API is a REST API, and as any other API, lets you query and modify the components of your cluster. Every operation executed by a user or a process, whether internal or external, will go through this API.

Kubernetes API是REST API，与其他任何API一样，您可以查询和修改集群的组件。 用户或进程执行的每个操作(无论是内部还是外部)都将通过此API。

The API receives objects to create/update/delete (yes, Deployments, Pods, Nodes, Secrets, etc are represented as objects) and then communicates with the corresponding actor of the control plane to execute the necessary actions.

API接收要创建/更新/删除的对象(是，将“部署”，“窗格”，“节点”，“机密”等表示为对象)，然后与控制平面的相应参与者进行通信以执行必要的操作。

As with any other type of objects, these are versioned, allowing evolution in the capabilities of both the API and cluster. These objects are extensible, meaning if you had to, you could create new types on demand.

与任何其他类型的对象一样，这些对象都经过版本控制，从而可以扩展API和群集的功能。 这些对象是可扩展的，这意味着您可以根据需要创建新类型。

You can contact the API as with any other REST API (curl, Postman?) or through the CLI, with a tool called kubectl. It operates mainly in two ways: for example, to create a Deployment you could simply run:

您可以像使用任何其他REST API(curl，Postman？)或通过CLI使用称为kubectl的工具来联系该API。 它主要以两种方式运行：例如，要创建一个Deployment，您可以简单地运行它：

kubectl create deploy my-deployment --image=my-app

or in an IaC fashion (Infrastructure as Code):

或以IaC方式(基础架构作为代码)：

kubectl create apply -f my-deployment.yaml

The advantage of the latter is that it can be versioned in your source control versioning repository, so it’s easier to track changes as of when who and why they were done. In this case, your Deployment spec will look something like:

后者的优点是可以在源代码控制版本库中进行版本控制，因此更容易跟踪更改的时间和原因。 在这种情况下，您的部署规范将类似于：

It might look like more verbose than the first option, but in the long run you don’t need to remember what commands you executed and it’s easily portable to other applications you might have. Said in a different way: favour this method.

它看起来比第一个选项更冗长，但是从长远来看，您无需记住执行了哪些命令，并且可以轻松地将其移植到其他应用程序中。 用另一种方式说：赞成这种方法。

其他一些命令示例 (Some other commands examples)

You can find these on Kubernetes official docs pages, the only reason I’m putting them here is to show how clear they tend to be, so the learning curve here is relatively flat.

您可以在Kubernetes官方文档页面上找到这些，我将它们放在此处的唯一原因是表明它们趋向于清晰，因此此处的学习曲线相对平坦。

Get current running pods

获取当前正在运行的Pod

kubectl get pods

Get a Deployment details

获取部署详细信息

kubectl describe deploy my-deployment

Delete a ReplicaSet

删除副本集

kubectl delete rs my-replicaset

The reason why I use the full name of the object and sometimes a shortened is because Kubernetes has shortcuts for most of the objects. Want to know all of them? Just run kubectl api-resources

之所以使用对象的全名(有时简称为缩写)，是因为Kubernetes具有大多数对象的快捷方式。 想知道所有人吗？ 只需运行kubectl api-resources

Intrigued enough to give it a shot? In a few days I’ll release the second part of the series on how to deploy an application with Kubernetes and Helm! If you liked this article, follow me so you can get notified when I release it.

足够吸引它吗？ 再过几天，我将发布该系列的第二部分，介绍如何使用Kubernetes和Helm部署应用程序！ 如果您喜欢这篇文章，请关注我，以便在我发布它时得到通知。

翻译自: https://medium.com/@scotti.sebastian/11-minutes-away-from-kubernetes-36f355c6c506

kubernetes