Labels,Replication Controllers,Services和Health

Labels

已经了解了Pod和如何去创建它们，你可能已经等不及想要创建很多很多的Pod。请这样做吧！然而最后你会需要一个系统来组织这些pod。Kubernetes中是通过Labels标签来实现这样的功能的。Labels是和对象相关的键值对。标签选择器可以通过REST列表来向API服务器发送请求来获取相应Labels的对象列表。

想要增加一个Labels，metadata中的一个标签块可以在pod中通过如下的方式来进行定义：

  labels:
    app: nginx

如下是一个有Labels的pod定义 (pod-nginx-with-label.yaml)

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

创建有Labels的pod (pod-nginx-with-label.yaml)

$ kubectl create -f docs/user-guide/walkthrough/pod-nginx-with-label.yaml

列出所有Labels app=nginx的pod:

$ kubectl get pods -l app=nginx

详细信息，参见Labels。在Kubernetes中还有两个核心的概念叫做：Replication Controllers和Services。Replication Controllers好的，现在你已经知道如何做一也不起的多容器，打有Labels 的pod，然后你想要用它们来创建应用，你可能想要开始创建一个个单独的pod。然而你可能会有很多操作方面的担忧。比如：你怎么去扩展这些pod，怎么样去保证所有的pod都是平均分布呢？答案就是Replication Controllers。Replication Controllers会把Pod创建模板以及一系列的预定复本都是组合进一个Kubernetes 对象中。Replication Controllers也会包含一个Labels选择器来找到其所管理的对象。它会不断地检测和预定状态的差距，然后创建和删除pod。比如，以下是一个Replication Controllers，它实例化了两个nginx pods (replication-controller.yaml)

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx-controller
spec:
  replicas: 2
  # selector identifies the set of Pods that this
  # replication controller is responsible for managing
  selector:
    app: nginx
  # podTemplate defines the 'cookie cutter' used for creating
  # new pods when necessary
  template:
    metadata:
      labels:
        # Important: these labels need to match the selector above
        # The api server enforces this constraint.
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

Replication Controllers管理创建一个nginx Replication Controllers(replication-controller.yaml)

$ kubectl create -f docs/user-guide/walkthrough/replication-controller.yaml

列出所有的复本控制器：

$ kubectl get rc

按名字删除复本控制器：

$ kubectl delete rc nginx-controller

详细信息参见 Replication Controllers Services一旦你有了一组Pod集合，你需要一个抽象，它可以让不同层次的应用相互连接。比如，如果你有一个管理后台任务的Replication Controllers，在你扩展后台的时候，你都不需要重新配置你的应用。同样的，如果后台任务被调度到不同的机器上时，你也不需要重新配置你的前端应用。在Kubernetes中，通过Services来实现这个目的。Services提供了一种方式让一组pod（同一个标签）可以拥有同一个静态IP地址。如果需要它也可以提供负载均衡。下面这个例子，是一个可以在之前创建好的nginx Replication Controllers中可以来均衡的一个服务(service.yaml)

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  ports:
  - port: 8000 # the port that this service should serve on
    # the container on each pod to connect to, can be a name
    # (e.g. 'www') or a number (e.g. 80)
    targetPort: 80
    protocol: TCP
  # just like the selector in the replication controller,
  # but this time it identifies the set of pods to load balance
  # traffic to.
  selector:
    app: nginx

Service Management 服务管理创建nginx服务(service.yaml):

$ kubectl create -f docs/user-guide/walkthrough/service.yaml

列出所有的服务:

$ kubectl get services

大多数情况下，服务的IP并不可以被外界访问到。最简单的方式是创建一个busybox pod 然后远程执行命令。详见 command execution documentation 。假如服务的IP是可以访问到的，你可以通过curl来直接访问http服务的80端口。

$ export SERVICE_IP=$(kubectl get service nginx-service -o go-template=)
$ export SERVICE_PORT=$(kubectl get service nginx-service -o go-template'=')
$ curl http://${SERVICE_IP}:${SERVICE_PORT}

按名字删除服务：

$ kubectl delete service nginx-service

当创建时，每一个服务都被分配了一个独特的IP地址。这个IP地址依附在整个服务的生命周期中，只要服务存活便不会变动。Pod可以被配置以和服务进行交互，需要了解的是和服务的通信是会在同一个标签下的pod间自动做负载均衡的。更多信息，参见Services。健康检测 Health Checking我写的代码从来不崩溃，对吗？可是事实并不是这样的…与其觉得自己写的代码无bug，更好的做法是通过管理系统来做定时的健康检测和应用修复。这样在应用之外的一个系统需要负责进行监控和修复。这个系统在你的应用之外是很重要的，因为如果你的应用崩溃了而健康检测的代理是在应用内部的话，健康检测本身也有可能失败，而这样你就无从得知了系统崩溃原因。在Kubernetes中健康检测是由kubelet代理来完成的。处理健康检测最简单的方法是对应用做进程级别的检测。Kubelet不断地询问Docker daemon应用是否还在运行，如果没有的话窗口会自动重启这个应用。 在目前为止运行的所有的Kubernetes示例中，健康检测实际上是已经都默认启用的。在每一个在Kubernetes上运行的空口中此功能都开启。应用健康检测然而，在很多情况下，这种低级别的健康检测是不够的。考虑一下如下代码。

lockOne := sync.Mutex{}
lockTwo := sync.Mutex{}

go func() {
  lockOne.Lock();
  lockTwo.Lock();
  ...
}()

lockTwo.Lock();
lockOne.Lock();

这是一个在计算机中典型的叫做“Deadlock”的例子。从Docker的角度，你的应用仍然在运行，进程也依然存在。然而从你的应用角度来看，你的代码已经死锁而且永远也不会正确地响应了。为了解决这个问题，Kubernetes支持用户自定义的应用健康检测。 这些检测被kublet来执行以确保你的应用是以你定义的正常的方式在运行。目前有三种健康检测方式供你选择：

• HTTP Health Checks – Kubelet会调用一个a web hook。如果它返回200到399，那么它被认为是正常的，否则便是不正常。
• Container Exec – Kubelet会在你的容器中运行一个命令行。如果它返回状态码0，那么它会认为是正常的。
• TCP Socket – Kubelet会试图打开一个指向容器的socket。如果它可以建立一个连接，容器便被认为是健康的，否则不正常。

所有的情况下，一旦Kubelet发现应用有问题，容器便会重启。容器的健康检测被定义在容器配置文件的livenessProbe部分。 这里你可以定义一个initialDelaySeconds的参数这是一个很好的方式来定义应用启动到进行健康检测之间间隔的方式，这允许你的容器可以做一些必要的初始化。以下是一个有HTTP健康检测的示例配置(pod-with-http-healthcheck.yaml)

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-healthcheck
spec:
  containers:
  - name: nginx
    image: nginx
    # defines the health checking
    livenessProbe:
      # an http probe
      httpGet:
        path: /_status/healthz
        port: 80
      # length of time to wait for a pod to initialize
      # after pod startup, before applying health checking
      initialDelaySeconds: 30
      timeoutSeconds: 1
    ports:
    - containerPort: 80

更多讨论：QQ交流群  513817976  入群暗号: kubernetes.org.cn