kubernetes基础

We learned about Docker in this article how Docker helps us to have an easy and efficient deployment of an application. Dockers are scalable, but it requires a manual effort to achieve it. There are some problems we encounter if we don't use any docker container orchestrator.

我们在本文中了解了Docker，它是如何帮助我们轻松，高效地部署应用程序的。 Docker是可扩展的，但是需要人工来实现。 如果不使用任何docker容器编排器，就会遇到一些问题。

1. Containers could not communicate with each other.
   容器无法相互通信。
2. Traffic distribution becomes a big problem.
   交通分配成为一个大问题。
3. Container management is overhead to manage the cluster manually.
   容器管理是手动管理群集的开销。
4. Auto-scaling is not possible.
   无法自动缩放。

In a production environment, we really need to think about these problems to have a robust, highly available, economical application. Here containers orchestrator comes to rescue us. There are many orchestrators available today where Kubernetes from Google is the most famous and used one. Kubernetes project is one of the top-ranked projects on Github.

在生产环境中，我们确实需要考虑这些问题，以实现健壮，高度可用的经济应用程序。 在这里，容器协调器来营救我们。 如今，有许多协调器可供使用，其中来自Google的Kubernetes是最著名和使用最多的。 Kubernetes项目是Github上排名最高的项目之一。

什么是Kubernetes？ (What is Kubernetes?)

Kubernetes is an open-source platform, very often called containers’ orchestrator. It eliminates many of the manual processes involved in deploying and scaling containerized applications. Each Kubernetes cluster has multiple components:

Kubernetes是一个开源平台，通常被称为容器的协调器。 它消除了部署和扩展容器化应用程序涉及的许多手动过程。 每个Kubernetes集群都有多个组件：

1. Master
   主
2. Nodes
   节点数
3. Kubernetes objects (namespace, pods, containers, volumes, deployment, Service, etc)
   Kubernetes对象(命名空间，pod，容器，卷，部署，服务等)

Kubernetes集群中的名称空间是什么？ (What is a namespace in the Kubernetes cluster?)

It is a cluster inside a Kubernetes cluster. It provides logical segregation of the applications from different teams/for different purposes. We create a namespace for each team and restrict their access to the assigned namespace only so that none of the team can access other team’s namespace or interfere with other’s containers and resources.

它是Kubernetes集群内部的集群。 它提供了来自不同团队/出于不同目的的应用程序的逻辑隔离。 我们为每个团队创建一个名称空间，并仅限制他们对分配的名称空间的访问，以使任何团队都无法访问其他团队的名称空间或干扰其他团队的容器和资源。

Each Kubernetes cluster comes with 4 default namespaces:

每个Kubernetes集群都带有4个默认名称空间 ：

1. Kube-system: We don't modify and create anything in this namespace. It has processes like master process, kubectl process, system process, etc.

   Kube系统：我们不会在此名称空间中修改和创建任何内容。 它具有诸如主进程，kubectl进程，系统进程等进程。

2. Kube-public: It has public accessible data like configMap. Try this command to get cluster-info kubectl cluster-info

   Kube-public：它具有可公开访问的数据，例如configMap。 试试这个命令来获取cluster-info kubectl cluster-info

3. Kube-node-lease: It is used to read the heartbeats of the nodes to determine the availability of the nodes in the cluster.

   Kube-node-lease：用于读取节点的心跳，以确定集群中节点的可用性。

4. Default: It is the namespace used by us to create resources. We can create our own namespace if multiple teams are utilizing the same cluster.

   默认值：这是我们用于创建资源的名称空间。 如果多个团队正在使用同一个集群，我们可以创建自己的名称空间。

kubectl get namespace // to get the list of all available namespaceskubectl create namespace MyNamespace1 // to create a namespace

We can also use a namespace using a configuration file which is a recommended way to create a namespace.

我们还可以使用配置文件来使用名称空间，这是创建名称空间的推荐方法。

什么是kubectl？ (What is kubectl?)

The kubectl command-line tool lets you control Kubernetes clusters.

使用kubectl命令行工具可以控制Kubernetes集群。

kubectl [command] [TYPE] [NAME] [flags]examples:kubectl get namepaceskubectl get podskubectl describe pod-labelkubectl delete pod-label

• command: Specifies the operation that you want to perform on one or more resources, for example create, get, describe, delete.

  command ：指定要在一个或多个资源上执行的操作，例如create ， get ， describe ， delete 。

• TYPE: Specifies the resource type. Resource types are case-insensitive and you can specify the singular, plural, or abbreviated forms.

  TYPE ：指定资源类型 。 资源类型不区分大小写，您可以指定单数，复数或缩写形式。

• NAME: Specifies the name of the resource. Names are case-sensitive. If the name is omitted, details for all resources are displayed, for example kubectl get pods.

  NAME ：指定资源的名称。 名称区分大小写。 如果省略名称，则会显示所有资源的详细信息，例如kubectl get pods 。

• flags: Specifies optional flags. For example, you can use the -s or --server flags to specify the address and port of the Kubernetes API server.

  flags ：指定可选标志。 例如，可以使用-s或--server标志来指定Kubernetes API服务器的地址和端口。

Kubernetes组件： (Kubernetes components:)

1. kube-apiserver: Command line interface talks with kube-apiserver to talk with Kubernetes cluster.

   kube-apiserver：命令行界面与kube-apiserver对话，与Kubernetes集群对话。

2. etcd: It is a distributed reliable key-value store. Kubernetes cluster stores master/worker nodes related information in this store to manage the cluster. It is also known as a cluster brain.

   etcd：这是一个分布式的可靠键值存储。 Kubernetes集群在该存储中存储了主节点/工作节点的相关信息以管理集群。 它也被称为集群大脑。

3. kube-scheduler: It distributes the work to all the worker nodes across the cluster based on node capacity, container requirement, affinity, etc.

   kube-scheduler：根据节点容量，容器要求，亲和力等，将工作分配给集群中的所有工作节点。

4. kube-controller-manager: It is responsible for identifying an issue in a node/container. If it encounters any failure, it replaces the failed node with the new one.

   kube-controller-manager：它负责标识节点/容器中的问题。 如果遇到任何故障，它将用新节点替换故障节点。

5. cloud-controller-manager: It is used when we deploy our Kubernetes cluster on the cloud.

   cloud-controller-manager：当我们在云上部署Kubernetes集群时使用。

6. kubelet: It is a service/process agent that runs on every node to make sure all containers are up and running. It is also known as the captain of the worker ship to whom master talks.

   kubelet：它是一个服务/进程代理，在每个节点上运行，以确保所有容器都已启动并正在运行。 它也被称为船长与船长交谈的船长。

7. kube-proxy: It maintains network rules on nodes. These network rules allow network communication to your Pods from network sessions inside or outside of your cluster.

   kube-proxy：它维护节点上的网络规则。 这些网络规则允许从群集内部或外部的网络会话与Pod进行网络通信。

8. Container runtime(docker agent): It is used to run the containers. In our case, it is a docker container runtime to run docker containers.

   容器运行时(docker代理)：用于运行容器。 在我们的例子中，运行Docker容器是docker容器运行时。

什么是POD？ (What is a POD?)

It’s an abstraction on top of the container/s. Each pod has its own unique IP address. Each IP address is reachable from all other pods in the K8s cluster. Pods are the smallest deployable units of computing that you can create and manage in Kubernetes. Kubernetes runs containerized apps. However, we cannot run a container in a cluster directly. Containers have to run inside a pod only.

这是容器顶部的抽象。 每个Pod都有其自己的唯一IP地址 。 每个IP地址都可以从K8s群集中的所有其他容器访问。 Pod是您可以在Kubernetes中创建和管理的最小的可部署计算单元。 Kubernetes运行容器化的应用程序。 但是，我们不能直接在集群中运行容器。 容器只能在吊舱内运行。

Pods are mortal. They are created, they live and they die, Kubernetes never restores them back. Instead, Kubernetes creates a new one in its place.

豆荚是凡人。 它们是被创造出来的，它们是生存的，并且是死亡，Kubernetes永不恢复它们。 相反，Kubernetes会在其位置创建一个新的。

Why do we need this abstraction?

为什么我们需要这种抽象？

1. It helps us with the container port mapping problem. It becomes difficult to keep the track of free ports in the big cluster to get the free port to run your container as containers run on the same port without pods conflict with each other.
   它可以帮助我们解决容器端口映射问题。 跟踪大型集群中的可用端口以使可用端口运行您的容器变得非常困难，因为容器在同一端口上运行而没有Pod相互冲突。
2. It helps to replace the container runtime easily. Suppose, today we are using docker, tomorrow we could use vagrant. With pods, K8s configurations would stay the same while replacing the container runtime.
   它有助于轻松替换容器运行时。 假设今天我们正在使用docker，明天我们可以使用无业游民。 使用Pod，在替换容器运行时时，K8s配置将保持不变。

Pod as scaling unit

Pod作为缩放单位

We add/remove pod to scale up/down an application respectively. Containers are not added to the existing pod to scale up the application. As the pod resources will be divided into multiple containers, which does not help to scale up the application/container.

我们添加/删除Pod分别放大/缩小应用程序。 不会将容器添加到现有的容器中以扩展应用程序。 由于pod资源将被划分为多个容器，因此无助于扩展应用程序/容器。

Now, we understood running multiple containers in a single pod is not a correct approach to scale up our containers. then, Why does Kubernetes allow multiple containers in a pod?

现在，我们知道在单个容器中运行多个容器不是扩大容器规模的正确方法。 那么， 为什么Kubernetes可以在一个Pod中允许多个容器？

The primary purpose of a multi-container Pod is to support co-located, co-managed helper processes for a primary application. Having multiple containers in a single Pod makes it relatively straightforward for them to communicate with each other. They can do this using several different methods.

多容器Pod的主要目的是为主应用程序支持位于同一地点，受共同管理的帮助程序。 在单个Pod中拥有多个容器，使它们彼此之间进行通信相对比较容易。 他们可以使用几种不同的方法来做到这一点。

1. In Kubernetes, you can use a shared Kubernetes Volume as a simple and efficient way to share data between containers in a Pod. In most cases, it is sufficient to use a directory on the host that is shared with all containers within a Pod.

   在Kubernetes中，您可以使用共享的Kubernetes卷作为一种简单有效的方法在Pod中的容器之间共享数据。 在大多数情况下，使用主机上与Pod中所有容器共享的目录就足够了。

2. Containers in a Pod share the same IPC namespace, which means they can also communicate with each other using standard inter-process communications such as SystemV semaphores or POSIX shared memory.

   Pod中的容器共享相同的IPC名称空间 ，这意味着它们还可以使用标准的进程间通信(例如SystemV信号量或POSIX共享内存)相互通信。

How to create a pod using a configuration file?

如何使用配置文件创建Pod？

# shivanshu$ vi create_pod.yaml# shivanshu$ kubectl apply -f create.pod.yaml# shivanshu$ kubectl get pods# shivanshu$ kubectl describe pod new_podapiVersion: kind: PodmetaData:name: new_podlabels: app: my_web_applicationenv: devspec:containers:name: my_web_containerimage: web_container_image

Let’s understand the YAML configuration file in Kubernetes in depth.

让我们深入了解Kubernetes中的YAML配置文件。

Each configuration file has 3 parts:

每个配置文件包含3个部分：

1. MetaData: To identify the component with its name and labels.

   元数据：使用其名称和标签来标识组件。

2. Specification: Attributes to spec are specific to the Kind of the component. kind is the second field in each configuration to identify the kind of component. It can have values like Pod, ReplicaSet, Deployment, Service, etc.

   规范：规范的属性特定于组件的种类。 kind是每种配置中用于标识组件类型的第二个字段。 它可以具有Pod，ReplicaSet，Deployment，Service等值。

3. Status: It is automatically generated and added by Kubernetes. How does it work? There are 2 states: Actual or Desired. Desired is what we define in spec like replicas: 2 in the below example, if the actual number of replicas is 1, then Kubernetes will launch a new container to match the desired and actual states.

   状态：它由Kubernetes自动生成和添加。 它是如何工作的？ 有2种状态：“实际”或“期望”。 我们在规格中定义了所需的replicas: 2 (如以下示例) replicas: 2在下例中为replicas: 2 ，如果副本的实际数量为1，则Kubernetes将启动一个新容器以匹配所需状态和实际状态。

apiVersion: kind: DeploymentmetaData: name: my_web_deploymentlabels: ...spec:replicas: 2selector: ...

Where does the K8s cluster get the status?

K8s集群在哪里获得状态？

Remember the etcd (the brain of the cluster), It keeps the status for each K8s component.

记住etcd( 集群的大脑 )，它保持每个K8s组件的状态。

Let’s understand the use of labels and selectors.

让我们了解标签和选择器的用法。

As our Kubernetes cluster grows, There is a need arises to label each object present in the cluster to keep things organized(to help us and Kubernetes identify the objects to act upon).

随着我们的Kubernetes集群的发展，有必要标记集群中存在的每个对象，以保持事物的有条理(以帮助我们和Kubernetes识别要采取行动的对象)。

Labels are key-value pairs that we can attach to objects like pods. They are used to describe meaningful and relevant information about an object.

标签是键值对，我们可以将其附加到诸如Pod之类的对象上。 它们用于描述有关对象的有意义和相关的信息。

Selectors are the way to express how to select an object based on its label/s. We can specify if a label equals to given criteria or if it fits inside a set of criteria.

选择器是表达如何根据其标签选择对象的方法。 我们可以指定标签是否等于给定标准，或者是否适合一组标准。

1. Equality-based
   基于平等
2. Set-based
   基于集合

什么是部署？ (What is deployment?)

Deployment is responsible for creating and updating instances of your application. It monitors the containers and provides a self-healing mechanism in case of machine failure.

部署负责创建和更新您的应用程序实例。 它监控容器并在机器故障时提供自愈机制。

We can deploy our containers using Pod configuration files directly. However, using deployment is a recommended way to deploy pods. It brings a lot of advantages:

我们可以直接使用Pod配置文件部署容器。 但是， 建议使用部署来部署pod的方法 。 它带来许多优点：

• It provides a self-healing mechanism in case of machine failure. If the Node hosting an instance goes down or is deleted, the Deployment controller replaces the instance with an instance on another Node in the cluster.
  它在机器出现故障时提供了一种自我修复机制。 如果承载实例的节点出现故障或被删除，则部署控制器将实例替换为群集中另一个节点上的实例。
• We don't need to worry about managing pods. If any pod goes down, the deployment controller will create a new pod in its place immediately in order to keep the desired number of pods running.
  我们不必担心管理窗格。 如果任何Pod发生故障，部署控制器将立即在其位置创建一个新Pod，以保持所需数量的Pod运行。

• Here, we have only one file, where Pod specification and the desired number of running Pods are defined. Pod specification is under spec.template key, whereas number or running Pods is under spec.replicas

  在这里，我们只有一个文件，其中定义了Pod规范和所需的运行Pod数量。 荚规范正在spec.template键，而数字或运行吊舱正在spec.replicas

Sample deployment file:

样本部署文件：

apiVersion: apps/v1kind: Deploymentmetadata:name: nginx-deploymentlabels:app: nginxspec:replicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:      - name: nginximage: nginx:1.14.2ports:        - containerPort: 80

• A Deployment named nginx-deployment is created, indicated by the .metadata.name field.

  创建一个名为nginx-deployment ，由.metadata.name字段指示。

• The Deployment creates three replicated Pods, indicated by the .spec.replicas field.

  部署将创建三个复制的.spec.replicas ，由.spec.replicas字段指示。

• The .spec.selector field defines how the Deployment finds which Pods to manage. In this case, you simply select a label that is defined in the Pod template (app: nginx).

  .spec.selector字段定义部署如何查找要管理的.spec.selector 。 在这种情况下，您只需选择在Pod模板中定义的标签( app: nginx )。

• The .spec.template.spec is the blueprint of the pod.

  .spec.template.spec是吊舱的蓝图。

A ReplicaSet ensures that a specified number of pod replicas are running at any given time. However, a Deployment is a higher-level concept that manages ReplicaSets and provides declarative updates to Pods along with a lot of other useful features. Therefore, we recommend using Deployments instead of directly using ReplicaSets, unless you require custom update orchestration or don’t require updates at all.

ReplicaSet确保在任何给定时间都运行指定数量的Pod副本。 但是，部署是一个高级概念，用于管理副本集，并提供对Pod的声明性更新以及许多其他有用的功能。 因此，除非您需要自定义更新编排或完全不需要更新，否则我们建议使用部署而不是直接使用副本集。

什么是服务？ (What is a service?)

We learned about how to deploy our containers, manage replicas of the containers, how does Kubernetes scale up and scale down the containers based on load. Now, our containers are up and running in the Kubernetes cluster. But, the question is Can we access these containers outside the container? How do we expose our containers to the outside world?

我们了解了如何部署容器，管理容器的副本，Kubernetes如何根据负载扩大和缩小容器。 现在，我们的容器已在Kubernetes集群中启动并运行。 但是，问题是我们可以在容器外部访问这些容器吗？ 我们如何将我们的容器暴露于外界？

Service is another Kubernetes object while helps us to expose our containers to be accessed from outside. Its job is to listen to the port and forward the request to the target pod.

服务是Kubernetes的另一个对象，它可以帮助我们公开要从外部访问的容器。 它的工作是监听端口并将请求转发到目标容器。

Let’s look at the service in details:

让我们详细了解该服务：

shivanshu$ vi service-definition.ymlshivanshu$ kubectl create -f service-definition.ymlshivanshu$ kubectl get services

So far, we saw service is mapped with a single pod. But, It’s not true in the production environment, Suppose we have multiple pods for the same container(all pods have the same label — in our case myapp) in a node to have high availability.

到目前为止，我们已经看到服务映射到单个pod。 但是，在生产环境中并非如此，假设我们在一个节点中有多个容器用于同一个容器(所有容器具有相同的标签，在我们的示例中为myapp)，以具有高可用性。

Do we need to modify our service to distribute the load among all pods?

我们是否需要修改服务以在所有Pod之间分配负载？

The answer is No. There will be no change in service definition when we add/remove pods for an application. Even if any pod goes down, there will no impact on end-user as service is still available to serve the end-user on the IP:PORT.

答案是否定的。当我们为应用程序添加/删除Pod时，服务定义不会改变。 即使任何吊舱掉落，也不会对最终用户造成影响，因为服务仍然可以在IP:PORT上为最终用户提供服务。

It uses random algorithm to choose a pod to serve the request.The range for nodePort: 30000 to 32767IP inside the service box is clusterIP.

它使用随机算法来选择一个Pod来服务请求。nodeBox的范围：服务框中的30000到32767 IP是clusterIP。

Even when we deploy pods on different nodes, Kubernetes automatically creates the service that spans across all the nodes in the cluster and we will be able to access the container using any node IP on port 30010.

即使将Pod部署在不同的节点上，Kubernetes也会自动创建跨集群中所有节点的服务，我们将能够使用端口30010上的任何节点IP来访问容器。

To summarize, single pod on a single node, multiple pods on a single node, multiple pods on multiple nodes, adding/removing pods from the node/s — the same service will work without any modification.

总而言之，单个节点上的单个Pod，单个节点上的多个Pod，多个节点上的多个Pod，从节点中添加/删除Pod的方法-相同的服务无需任何修改即可工作。

服务种类 (Types of services)

We set it using spec.type in the service-definition file.

我们在服务定义文件中使用spec.type对其进行设置。

• ClusterIP: the default one. It allocates a cluster-internal IP address, and it makes our Pods reachable only from the inside the cluster.

  ClusterIP：默认值。 它分配了一个群集内部的IP地址，并使Pod仅可从群集内部访问。

• NodePort: built on top of the ClusterIP. The service is now reachable not only from the inside of the cluster through the service’s internal cluster IP but also from the outside: curl <node-ip>:<node-port>. Each Node opens the same port (node-port), and redirects the traffic received on that port to the specified Service. This is the one which we used above.

  NodePort：建立在ClusterIP之上。 现在，不仅可以从群集内部通过服务的内部群集IP访问服务，还可以从外部访问： curl <node-ip>:<node-port> 。 每个节点都打开相同的端口( node-port )，并将在该端口上收到的流量重定向到指定的服务。 这是我们上面使用的那个。

• LoadBalancer: built on top of the NodePort. The service is accessible outside the cluster: curl <service-EXTERNAL-IP>. Traffic is now coming via LoadBalancer, which then is redirected to the Nodes on a specific port (node-port).

  LoadBalancer：构建在NodePort之上。 该服务可在群集外部访问： curl <service-EXTERNAL-IP> 。 现在，流量通过LoadBalancer进入，然后将其重定向到特定端口( node-port )上的node-port 。

There is one more important thing to know which is Ingress.

还有另外一件重要的事情要知道，那就是Ingress 。

Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the Ingress resource.

Ingress公开了从群集外部到群集内服务的 HTTP和HTTPS路由。 流量路由由Ingress资源上定义的规则控制。

An Ingress may be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name-based virtual hosting. An Ingress controller is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic.

可以将Ingress配置为提供服务可外部访问的URL，负载平衡流量，终止SSL / TLS并提供基于名称的虚拟主机。 入口控制器通常通过负载平衡器负责实现入口，尽管它也可以配置边缘路由器或其他前端以帮助处理流量。

I tried to cover the basic fundamentals of Kubernetes which can help us to start with it. Kubernetes' official documentation is really cool to read more about it.

我试图介绍Kubernetes的基本基础知识，这可以帮助我们开始使用它。 Kubernetes的官方文档真的很酷，可以阅读更多有关它的信息。

Hope it helps! Thanks for reading!

希望能帮助到你！ 谢谢阅读！