kubernetes简介

kubernetes

介绍

kubernetes，简称K8s，是用8代替名字中间的8个字符“ubernete”而成的缩写。是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes提供了应用部署，规划，更新，维护的一种机制。

传统的应用部署方式是通过插件或脚本来安装应用。这样做的缺点是应用的运行、配置、管理、所有生存周期将与当前操作系统绑定，这样做并不利于应用的升级更新/回滚等操作，当然也可以通过创建虚拟机的方式来实现某些功能，但是虚拟机非常重，并不利于可移植性。

新的方式是通过部署容器方式实现，每个容器之间互相隔离，每个容器有自己的文件系统 ，容器之间进程不会相互影响，能区分计算资源。相对于虚拟机，容器能快速部署，由于容器与底层设施、机器文件系统解耦的，所以它能在不同云、不同版本操作系统间进行迁移。

容器占用资源少、部署快，每个应用可以被打包成一个容器镜像，每个应用与容器间成一对一关系也使容器有更大优势，使用容器可以在build或release 的阶段，为应用创建容器镜像，因为每个应用不需要与其余的应用堆栈组合，也不依赖于生产环境基础结构，这使得从研发到测试、生产能提供一致环境。类似地，容器比虚拟机轻量、更“透明”，这更便于监控和管理。

特性

自动装箱
k8s可以自动完成容器的部署且不影响容器的可用性
自我修复
当容器崩溃了k8s会自动启动一个新的容器代替崩溃的的容器从而实现自我修复
自动实现水平扩展
在物理平台允许的情况下k8s可以无限扩展容器，以保证容器的充足
自动发布和回滚
密匙和配置管理
存储编排
任务批处理运行

架构

master组件：

• API server 用户程序（如kubectl）、K8s其它组件之间通信的接口。K8s其它组件之间不直接通信，而是通过API server通信的。这一点在上图的连接中可以体现，例如，只有API server连接了etcd，即其它组件更新K8s集群的状态时，只能通过API server读写etcd中的数据。
• Scheduler 排程组件，为用户应用的每一可部署组件分配工作结点。
• Controller 确保已创建的容器处于健康状态
• Controller Manager 执行集群级别的功能，如复制组件、追踪工作结点状态、处理结点失败等。Controller Manager组件是由多个控制器组成的，其中很多控制器是按K8s的资源类型划分的，如Replication Manager（管理ReplicationController 资源），ReplicaSet Controller，PersistentVolume controller。
• kube-proxy 在应用组件间负载均衡网络流量。
  node组件：
• Kubelet 管理工作结点上的容器。
• Container runtime Docker, rkt等实际运行容器的组件。

Kubernetes主要由以下几个核心组件组成：

etcd保存了整个集群的状态；

• apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
• controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
• scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
• kubelet负责本Node节点上的Pod的创建、修改、监控、删除等生命周期管理，同时Kubelet定时“上报”本Node的状态信息到Api Server里；
• Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；
• kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；

Kubernetes可以做什么？

使用Web服务，用户希望应用程序能够7*24小时全天运行，开发人员希望每天多次部署新的应用版本。通过应用容器化可以实现这些目标，使应用简单、快捷的方式更新和发布，也能实现热更新、迁移等操作。使用Kubernetes能确保程序在任何时间、任何地方运行，还能扩展更多有需求的工具/资源。Kubernetes积累了Google在容器化应用业务方面的经验，以及社区成员的实践，是能在生产环境使用的开源平台。

专业术语

pod

pod是kubernetes可以部署和管理的最小单元，如果想要运行一个容器，先要为这个容器创建一个pod。同时一个pod也可以包含多个容器，之所以多个容器包含在一个pod里，往往是由于业务上的紧密耦合。
需要注意这里说的场景都非必须把不同的容器放在同一个pod里，但是这样往往更便于管理，甚至后面会讲到的，紧密耦合的业务容器放置在同一个容器里通信效率更高。具体怎么使用还要看实际情况,综合权衡。
pod的特点是可以将多个容器加入到同一个网络名称空间中，同一个pod内不同的容器可以共享存储卷。
node
k8s集群中其他机器被称为node节点，Node可以是一台物理机，也可以是一台虚拟机。当某个node宕机，其上的工作负载会被master自动转移到其他节点上。

Node运行着一些关键进程：

1.kubelet：负责pod对应的容器创建、启停等任务。

2.kube-porxy，实现service通信的重要组件

3.docker engine，docker引擎，负责本机的容器创建和管理。

node节点可以在运行期间动态增加到k8s集群中，在默认情况下kubelet会将master注册自己，并定时想master汇报自身情报。

Label

一个label是一个key=value的键值组合，然后可以通过label selector（标签选择器）查询和筛选拥有某些label的资源对象。

label selector的重要使用场景：

kube-controller进程通过资源对象RC上定义的label selector来筛选要监控的pod的数量，从而实现全自动控制流程。

kube-proxy进程通过service的label selector来选择对应的pod，自动建立起每个service到对应pod的请求转发路由表。从而实现service的智能负载均衡机制。

标签选择器

当大量的pod运行在一个集群当中时，如何实现分类管理?比如想删除某一类pod，比如想让控制器去管理一部分pod，它怎么进行管理?如何挑选、检测出来这些pod呢?值得肯定的是，这么多的pod，我们不能通过pod的名称来识别容器，因为pod随时都会被创建和删除，当一个pod发生故障被删除后，重新生成的pod的名称与被删除的pod名称肯定是不一样的,只不过其内部运行的程序是一样的，所以我们不能靠pod的名称来识别。同时我们有可能要将一类pod归组，比如创建4个nginx的pod,期望使用一个控制器对其进行统一管理，删除一个控制器就把这4个pod都删了，控制器还要保证这4个pod都处于运行状态，缺—个要补一个，多一个要多杀一个，精确符合我们期望的4个pod才行。

为了能够实现pod识别，需要在pod之上附加一些元数据，类似dockerfle中的label标签的方式，比如在创建pod时为其附加一个名为app的key，然后将其值设为nginx，那么当我们在批量进行pod调度管理时，可以检查pod中是否有app这个key，且其值是否为nginx，通过此种方法来识别pod是否是我们想要控制的pod。

标签是在k8s上管理大规模pod资源并且能够分类识别和管理的一个非常重要的途径。

那么怎么从众多的pod中筛选出我们想要的pod呢?通过标签选择器组件我们可以实现这个功能标签选择器就是一种根据标签来过滤符合条件的资源对象的机制。