Kubernetes系列——Kubernetes 组件、对象（二）

1、Kubernetes 组件

介绍了Kubernetes集群所需的各类二进制组件。

Master 组件

Master组件提供集群的管理控制中心。

Master组件能够在集群中任何节点上运行。可是为了简单起见，一般在一台VM/机器上启动全部Master组件，而且不会在此VM/机器上运行用户容器。请参考 构建高可用群集以来构建multi-master-VM。

kube-apiserver

kube-apiserver用于暴露Kubernetes API。任何的资源请求/调用操做都是经过kube-apiserver提供的接口进行。请参阅构建高可用群集。

ETCD

etcd是Kubernetes提供默认的存储系统，保存全部集群数据，使用时须要为etcd数据提供备份计划。

kube-controller-manager

kube-controller-manager运行管理控制器，它们是集群中处理常规任务的后台线程。

逻辑上，每一个控制器是一个单独的进程，但为了下降复杂性，它们都被编译成单个二进制文件，并在单个进程中运行。

这些控制器包括：

一、节点（Node）控制器。

二、副本（Replication）控制器：负责维护系统中每一个副本中的pod。

三、端点（Endpoints）控制器：填充Endpoints对象（即链接Services＆Pods）。

四、Service Account和Token控制器：为新的Namespace 建立默认账户访问API Token。

cloud-controller-manager

云控制器管理器负责与底层云提供商的平台交互。云控制器管理器是Kubernetes版本1.6中引入的，目前仍是Alpha的功能。

云控制器管理器仅运行云提供商特定的（controller loops）控制器循环。能够经过将 flag设置为external启动kube-controller-manager ，来禁用控制器循环。

cloud-controller-manager 具体功能：--cloud-provider

    节点（Node）控制器

    路由（Route）控制器

    Service控制器

    卷（Volume）控制器

kube-scheduler

kube-scheduler 监视新建立没有分配到Node的Pod，为Pod选择一个Node。

插件 addons

插件（addon）是实现集群pod和Services功能的 。Pod由Deployments，ReplicationController等进行管理。Namespace 插件对象是在kube-system Namespace中建立。

DNS

虽然不严格要求使用插件，但Kubernetes集群都应该具备集群 DNS。

群集 DNS是一个DNS服务器，可以为 Kubernetes services提供 DNS记录。

由Kubernetes启动的容器自动将这个DNS服务器包含在他们的DNS searches中。

了解更多详情

用户界面

kube-ui提供集群状态基础信息查看。更多详细信息，请参阅使用HTTP代理访问Kubernetes API

容器资源监测

容器资源监控提供一个UI浏览监控数据。

Cluster-level Logging

Cluster-level logging，负责保存容器日志，搜索/查看日志。

节点（Node）组件

节点组件运行在Node，提供Kubernetes运行时环境，以及维护Pod。

kubelet

kubelet是主要的节点代理，它会监视已分配给节点的pod，
具体功能：

    安装Pod所需的volume。

    下载Pod的Secrets。

    Pod中运行的 docker（或experimentally，rkt）容器。

    按期执行容器健康检查。

    Reports the status of the pod back to the rest of the system, by creating a mirror pod if necessary.

    Reports the status of the node back to the rest of the system.

kube-proxy

kube-proxy经过在主机上维护网络规则并执行链接转发来实现Kubernetes服务抽象。

docker

docker用于运行容器。

RKT

rkt运行容器，做为docker工具的替代方案。

supervisord

supervisord是一个轻量级的监控系统，用于保障kubelet和docker运行。

fluentd

fluentd是一个守护进程，可提供cluster-level logging.。

 

2、Kubernetes对象

了解Kubernetes对象

Kubernetes对象是Kubernetes系统中的持久实体。Kubernetes使用这些实体来表示集群的状态。
具体来讲，他们能够描述：

    容器化应用正在运行(以及在哪些节点上)

    这些应用可用的资源

    关于这些应用如何运行的策略，如从新策略，升级和容错

Kubernetes对象是“record of intent”，一旦建立了对象，Kubernetes系统会确保对象存在。经过建立对象，能够有效地告诉Kubernetes系统你但愿集群的工做负载是什么样的。

要使用Kubernetes对象（不管是建立，修改仍是删除），都须要使用Kubernetes API。例如，当使用kubectl命令管理工具时，CLI会为提供Kubernetes API调用。你也能够直接在本身的程序中使用Kubernetes API，Kubernetes提供一个golang客户端库 （其余语言库正在开发中-如Python）。

对象（Object）规范和状态

每一个Kubernetes对象都包含两个嵌套对象字段，用于管理Object的配置：Object Spec和Object Status。Spec描述了对象所需的状态 - 但愿Object具备的特性，Status描述了对象的实际状态，并由Kubernetes系统提供和更新。

例如，经过Kubernetes Deployment 来表示在集群上运行的应用的对象。建立Deployment时，能够设置Deployment Spec，来指定要运行应用的三个副本。Kubernetes系统将读取Deployment Spec，并启动你想要的三个应用实例 - 来更新状态以符合以前设置的Spec。
若是这些实例中有任何一个失败（状态更改），Kuberentes系统将响应Spec和当前状态之间差别来调整，这种状况下，将会开始替代实例。

有关object spec、status和metadata更多信息，请参考“Kubernetes API Conventions”。

描述Kubernetes对象

在Kubernetes中建立对象时，必须提供描述其所需Status的对象Spec，以及关于对象（如name）的一些基本信息。
当使用Kubernetes API建立对象（直接或经过kubectl）时，该API请求必须将该信息做为JSON包含在请求body中。
一般，能够将信息提供给kubectl .yaml文件，在进行API请求时，kubectl将信息转换为JSON。

如下示例是一个.yaml文件，显示Kubernetes Deployment所需的字段和对象Spec：

nginx-deployment.yaml
apiVersion: apps/v1beta1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80

使用上述.yaml文件建立Deployment，是经过在kubectl中使用kubectl create命令来实现。将该.yaml文件做为参数传递。以下例子：

$ kubectl create -f docs/user-guide/nginx-deployment.yaml --record

其输出与此相似:

deployment "nginx-deployment" created

必填字段

对于要建立的Kubernetes对象的yaml文件，须要为如下字段设置值：

    apiVersion - 建立对象的Kubernetes API 版本

    kind - 要建立什么样的对象？

    metadata- 具备惟一标示对象的数据，包括 name（字符串）、UID和Namespace（可选项）

还须要提供对象Spec字段，对象Spec的精确格式（对于每一个Kubernetes 对象都是不一样的），以及容器内嵌套的特定于该对象的字段。Kubernetes API reference能够查找全部可建立Kubernetes对象的Spec格式。

下一步？

• 了解最重要的Kubernetes对象，如Pod