有道云笔记写编程学习笔记_Kubernetes学习笔记（ii）_机器学习_weixin

有道云笔记写编程学习笔记

There are two ways to set up your k8s cluster up and running, declarative and imperative. In this blog, we are focusing on how to using YAML file to set up k8s containers declaratively. And for imperatively we do it through kubectl in next blog.

有两种方法可以设置和运行k8s集群：声明式和命令式。在此博客中，我们重点介绍如何使用YAML文件以声明方式设置k8s容器。势在必行，我们将在下一个博客中通过kubectl进行操作。

YAML is a human-readable text-based format for specifying configuration-type information. YAML is a superset of JSON, which means that any valid JSON file is also a valid YAML file. In the context of k8s, we mainly use two data structures of YAML: list and map.

YAML是一种人类可读的基于文本的格式，用于指定配置类型信息。 YAML是JSON的超集，这意味着任何有效的JSON文件也是有效的YAML文件。在k8的上下文中，我们主要使用YAML的两个数据结构：列表和映射。

YAML lists are literally a sequence of objects. For example:

YAML列表实际上是一个对象序列。例如：

YAML listports:
- containerPort: 5432//in json
{
   "ports": ["containerPort":"5432"]
}YAML map (map the key-value pairs)apiVersion: apps/v1
kind: Deployment

Kubernetes对象 (Kubernetes objects)

Kubernetes objects are persistent entities in the Kubernetes system. Specifically, they can describe:

Kubernetes对象是Kubernetes系统中的持久实体。具体来说，它们可以描述：

What containerized applications are running (and on which nodes)

哪些容器化应用程序正在运行(以及在哪些节点上)
The resources available to those applications

这些应用程序可用的资源
The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance

有关这些应用程序行为的策略，例如重新启动策略，升级和容错

Object Spec and Status

对象规格和状态

Almost every Kubernetes object includes two nested object fields that govern the object’s configuration: the object spec and the object status. For objects that have a spec, you have to set this when you create the object. The status describes the current state of the object, supplied and updated by the Kubernetes and its components. The Kubernetes control plane continually and actively manages every object’s actual state to match the desired state you supplied.

几乎每个Kubernetes对象都包含两个嵌套的对象字段，用于控制对象的配置：对象 spec 和对象 status 。对于具有spec对象，必须在创建对象时进行设置。 status描述了对象的当前状态 ，由Kubernetes及其组件提供和更新。 Kubernetes控制平面持续主动地管理每个对象的实际状态以匹配您提供的所需状态。

Required Fields

必填项

In the .yaml file for the Kubernetes object you want to create, you’ll need to set values for the following fields:

在您要创建的Kubernetes对象的.yaml文件中，您需要为以下字段设置值：

apiVersion - Which version of the Kubernetes API you’re using to create this object

apiVersion您用来创建此对象的Kubernetes API版本
kind - What kind of object you want to create

kind您要创建哪种对象
metadata - Data that helps uniquely identify the object, including a name string, UID, and optional namespace

metadata -有助于唯一标识对象的数据，包括name字符串， UID和可选的namespace
spec - What state you desire for the object.

spec 您希望对象处于什么状态。

Pod, Deployment and Service

Pod，部署和服务

A Pod is the most basic unit that Kubernetes deals with. It wraps containers inside it. Containers inside a pod containers share a life cycle, and their environment, volumes, and IP space. Usually, pods consist of a primary container and optionally some support containers.

Pod是Kubernetes处理的最基本的单元。它在其中包装容器。 Pod容器中的容器共享生命周期，以及它们的环境，卷和IP空间。通常，吊舱由主容器和可选的一些支撑容器组成。
A Deployment is an object that lets you manage a set of identical pods using Replication sets. It eases the life cycle management of replicated pods. Deployments can be modified easily by changing the configuration and Kubernetes will adjust accordingly.

部署是一个对象，可让您使用复制集管理一组相同的容器。它简化了复制吊舱的生命周期管理。可以通过更改配置轻松修改部署，Kubernetes会进行相应调整。
a Service defines a logical set of Pods and a policy by which to access them. A service’s IP address remains stable regardless of changes to the pods it routes to. Any time you need to provide access to one or more pods to another application or to external consumers, you should configure a service. Although services, by default, are only available using an internally routable IP address, they can be made available outside of the cluster by choosing one of several strategies.

服务定义Pod的逻辑集和访问策略的策略。服务的IP地址保持稳定，而不管对其路由到的Pod的更改如何。任何时候需要提供对另一个应用程序或外部使用者的一个或多个Pod的访问权限时，都应配置服务。尽管默认情况下仅通过内部可路由的IP地址提供服务 ，但是可以通过选择以下几种策略之一使它们在群集外部可用。

A Pod is the smallest unit of work which can be scheduled in Kubernetes. A Pod encapsulates an application containers, storage resources, unique network IP. Normally, higher level abstractions are used to deploy pods such as Deployments, Replica Sets, Daemon Sets, Stateful Sets, or Jobs.

Pod是可以在Kubernetes中预定的最复杂的工作单元 。 Pod封装了应用程序容器，存储资源，唯一的网络IP。通常，更高级别的抽象用于部署Pod，例如Deployments，副本集，Daemon集，Stateful Set或Jobs。

Now let’s use some examples to look into how these objects work.

现在，让我们使用一些示例来研究这些对象的工作方式。

//client-pod.ymlapiVersion: v1
kind: Pod
metadata:
  name: client-pod
  labels:
    component: web
spec:
  containers:
    - name: client
      image: elfiy/multi-worker
      resources:
        limits:
          memory: "128Mi"
          cpu: "500m"
      ports:
        - containerPort: 3000//client-deployment.ymlapiVersion: apps/v1
kind: Deployment
metadata:
  name: client-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      component: web
  template:
    metadata:
      labels:
        component: web
    spec:
      containers:
        - name: client
          image: stephengrider/multi-client
          resources:
            limits:
              memory: "128Mi"
              cpu: "500m"
          ports:
            - containerPort: 3000//client-node-port.ymlapiVersion: v1
kind: Service
metadata:
  name: client-node-port
spec:
  selector:
    component: web
  type: NodePort
  ports:
    - port: 3050
      targetPort: 3000
      nodePort: 31515

There are some keys worth mentioning from above:

从上面有一些值得一提的关键：

apiVersion:Which version of the Kubernetes API you’re using to create this object.

apiVersion ：用于创建此对象的Kubernetes API的哪个版本。
Metadata: The metadata contains information of the object. The information in the metadata usually contains the name you want to give the object , the labels, and the annotation.

元数据：元数据包含对象的信息。元数据中的信息通常包含您要赋予对象的名称，标签和注释。
Spec: is about the desired status of our object.

Spec ：关于我们对象的期望状态。
Container: Here you specify:the name of the container that you’ll run in your pod (client in our first example); the image of the application you want to run in your pods (elfiy/multi-worker); the containerPort is the port your application in your container is listening to (3000).

容器：您在此处指定：要在容器中运行的容器的名称(在第一个示例中为client )；您要在pod中运行的应用程序的图像( elfiy/multi-worker )； containerPort是容器中的应用程序正在侦听的端口( 3000 )。

You may notice there are some differences in each object, for example in Deployment yml, we have something extra:

您可能会注意到每个对象都有一些差异，例如在Deployment yml中，我们还有一些额外的优点：

Replicas sets the number of instances of the pod that the deployment should run.

副本设置部署应运行的Pod实例的数量。
Label selector is to match the pods to the deployment. This is equivalent of “all the pods matching these labels are included in the deployment.” (in our case it’s the pod with name “web”)

标签选择器用于将吊舱与部署进行匹配。这等效于“与这些标签匹配的所有容器都包含在部署中。” (在我们的例子中，它是名称为“ web ”的广告连播)
Template is added by the deployment controller to every ReplicaSet that a Deployment creates or adopts. It is just a pod spec. When the deployment creates pods, it will create them using this template.

模板由部署控制器添加到部署创建或采用的每个ReplicaSet中。这只是一个豆荚规格。部署创建Pod时，它将使用此模板创建它们。

Lastly on the Service object, notice the 3 different ports:

最后，在Service对象上，注意3个不同的端口：

ClusterIP (default) — Exposes the Service on an internal IP in the cluster. This type makes the Service only reachable from within the cluster. There may be other pods that need access to this pod.(3050)

ClusterIP (默认)—在群集的内部IP上公开服务。这种类型使得只能从群集内访问服务。可能还有其他容器需要访问该容器。( 3050 )
NodePort — Exposes the Service on the same port of each selected Node in the cluster using NAT. Makes a Service accessible from outside the cluster using <NodeIP>:<NodePort>.(31515) Note that if we go to localhost:31515 we won’t get anything. Since k8s has a VM and we need the IP assigns to this VM instead using

NodePort —使用NAT在群集中每个选定节点的相同端口上公开服务。使用<NodeIP>:<NodePort>使服务可以从群集外部访问。( 31515 )请注意，如果我们转到localhost：31515，将不会得到任何信息。由于k8s有一个VM，因此我们需要为该VM分配IP，而不是使用

$minikube ip 
192.168.64.2So visit to go to http://192.168.64.2/31515

TargetPort — This is the port on the pod that the request gets sent to. (3000)

TargetPort —这是请求发送到的Pod上的端口。 ( 3000 )
Additionally, note that there are some use cases with Services that involve not defining selector in the spec. A Service created without selector will also not create the corresponding Endpoints object. This allows users to manually map a Service to specific endpoints. Apart from these ports, there’s also Loadbalancer port and Ingress which we will touch later.

此外，请注意，在Services中有一些用例涉及在规范中未定义selector 。没有selector创建的服务也不会创建相应的Endpoints对象。这使用户可以将服务手动映射到特定端点。除了这些端口之外，还有Loadbalancer端口和Ingress ，我们将在后面介绍。