Kubernetes简介

Kubernetes简介

文章目录

kubernetes介绍

Kubernetes是容器集群管理系统，是一个开源的平台，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。

通过Kubernetes你可以：

  • 快速部署应用
  • 快速扩展应用
  • 无缝对接新的应用功能
  • 节省资源，优化硬件资源的使用

Kubernetes的目标是让部署容器化的应用简单且高效(powerful)，kubernetes提供了应用部署，规划，更新，维护的一种机制。

Kubernetes一个核心的特点就是能够自主的管理容器来保证云平台中的容器按照用户的期望状态运行着（比如用户想让apache一直运行，用户不需要关心怎么去做，Kubernetes会自动去监控，然后去重启，新建，总之，让apache一直提供服务），管理员可以加载一个微型服务，让规划器来找到合适的位置。

现在Kubernetes着重于不间断的服务状态（比如web服务器或者缓存服务器）和原生云平台应用（Nosql），在不久的将来会支持各种生产云平台中的各种服务，例如，分批，工作流以及传统数据库。

在Kubernetes中，所有的容器均在pod中运行，一个pod可以运行一个或者多个相关的容器，在后边的案例中，同一个pod中的容器会部署在同一个物理机器上并且能够共享资源。一个pod也可以包含0个或多个volumes，这些卷组将会以目录的形式提供给一个容器，或者被所有pod中的容器共享，对于用户创建的每个pod，系统会自动选择那个健康并且有足够容量的机器，然后创建类似容器的容器，当容器创建失败时，容器会被node agent自动重启，这个node agent叫kubelet，但是，如果是pod失败或者机器，它不会自动转移并启动，除非用户定义了replication controller。

kubernetes特性

  1. 一致性

    通过一次运行多个容器，kubernetes为软件开发，DevOps，QA，系统管理员和其他专家提供了一个整体的生产环境。无论在运行kubernetes集群时可能发生什么变化，SDLC(Software Development Life Cycle，即软件生命周期)的整体完整性都会得到保留。它为高性能和风险最小化做出了巨大贡献。

  2. 可移植性

    Kubernetes可以把在裸机或虚拟机(VM)群集上运行的容器，轻松的迁移到云环境中使用，由于应用程序时容器化的，因此它们完全与平台无关，并且可以跨各种框架进行编排。容器编排技术支持当今的大多数编程语言，这是迁移的另一个巨大优势。

  3. 可扩展性

    Kubernetes在处理与应用程序相关的工作负载时，完全可以应付任何扩展挑战。由于其弹性和容器集群过程的自动化，可以轻松地减轻负担，并在公司数据中心，私有云和公有云的功能之间重新分配负担，而不会造成任何应用程序性能问题或宕机。这对于DevOps而言意义重大，因为可自动灵活扩展的工作负载是一项巨大的改进。

  4. 安全

    确保你的容器编排绝对安全。Kubernetes通过透明的控制机制和合规性协议为你提供了支持，例如基于角色的访问控制(RBAC)，轻型目录访问协议(LDAP)，增强安全性的Linux(SELinux)和可扩展访问控制标记语言(XACML)。Kubernetes提供增强的安全功能，可以保护你的IT基础架构，并确保跨各种生产环境运行的应用程序的安全。

Kubernetes架构

Kubernetes集群包含有节点代理kubelet和Master组件(APIs, scheduler, etc)，一切都基于分布式的存储系统。下面这张图是Kubernetes的架构图

GcKPtE.png

kubernetes节点

在这张系统架构图中，我们把服务分为运行在工作节点上的服务和组成集群级别控制板的服务。

kubernetes节点有运行应用容器必备的服务，而这些都是受Master的控制。

每个节点上都要运行docker。docker来负责所有具体的镜像下载和容器运行。

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

  • etcd保存了整个集群的状态
  • apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制
  • controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等
  • scheduler负责资源的调度，按照预定的调度策略将pod调度到相应的机器上
  • kubelet负责维护容器的生命周期，同时也负责Volume(CVI)和网络(CNI)的管理
  • container runtime负责镜像管理以及pod和容器的真正运行(CRI)
  • kube-proxy负责为service提供cluster内部的服务发现和负载均衡

除了核心组件，还有一些推荐的Add-ons：

  • kube-dns负责为整个集群提供DNS服务
  • lngress controler为服务提供外网入口
  • Heapster提供资源监控
  • Dashboard提供GUI
  • Federation提供跨可用区的集群
  • Fluentd-elasticsearch提供集群日志采集、存储与查询

GcKfD6.png

GcKjGn.png

Kubernetes专业术语

官方把kubernetes属于分为12类：

系统结构、社区、核心对象、扩展、基础、网络、操作、安全、存储、工具、用户类型、工作负载

因为kubernetes的术语实在太多了，这里只介绍一些常用的术语。

pods

在kubernetes中，最小的管理单元不是一个个独立的容器，而是pod，pod是最小的，管理，创建，计划的最小单元。

labels

标签其实就是一对key/value，被关联到对象上，比如pod；标签的使用我们倾向于能够标示对象的特殊特点，并且对用户而言是有意义的(就是一眼就能看出这个pod是干嘛的)；但是标签对内核系统是没有直接意义的。标签可以用来划分特定组的对象(比如，所有男的)，标签可以在创建一个对象时直接给予，也可以在后期随时修改，每一个对象都可以拥有多个标签，但是，key值必须是唯一的

"labels":{
	"key1":"value1"
	"key2":"value2"
}

namespace

namespace是对一组资源和对象的抽象集合，比如可以用来将系统内部的对象划分为不同的项目组或用户组。产检的pods，services，replication controllers和deployments等都是属于某一个namespace的(默认是default)，而node，persistentVolumes等则不属于任何namespace。

namespace常用来隔离不同的用户，比如Kubernetes自带的服务一般运行在kube-system namesapce中。

Replication Controller

Replication Controller 保证了在所有时间内，都有特定数量的Pod副本正在运行，如果太多了，Replication Controller就杀死几个，如果太少了，Replication Controller会新建几个，和直接创建的pod不同的是，Replication Controller会替换掉那些删除的或者被终止的pod，不管删除的原因是什么（维护阿，更新啊，Replication Controller都不关心）。基于这个理由，我们建议即使是只创建一个pod，我们也要使用Replication Controller。Replication Controller 就像一个进程管理器，监管着不同node上的多个pod,而不是单单监控一个node上的pod，Replication Controller 会委派本地容器来启动一些节点上服务（Kubelet ,Docker）。

Node
Node是Pod真正运行的主机，可以物理机，也可以是虚拟机。为了管理Pod，每个Node节点上至少要运行container runtime（比如docker或者rkt）、kubelet和kube-proxy服务。

GcUJkD.md.png

ReplicaSets
ReplicaSet是下一代复本控制器。ReplicaSet和 Replication Controller之间的唯一区别是现在的选择器支持。Replication Controller只支持基于等式的selector（env=dev或environment!=qa），但ReplicaSet还支持新的，基于集合的selector（version in (v1.0, v2.0)或env notin (dev, qa)）。在试用时官方推荐ReplicaSet。

Services
Kubernetes Pod是平凡的，它门会被创建，也会死掉（生老病死），并且他们是不可复活的。 ReplicationControllers动态的创建和销毁Pods(比如规模扩大或者缩小，或者执行动态更新)。每个pod都由自己的ip，这些IP也随着时间的变化也不能持续依赖。这样就引发了一个问题：如果一些Pods（让我们叫它作后台，后端）提供了一些功能供其它的Pod使用（让我们叫作前台），在kubernete集群中是如何实现让这些前台能够持续的追踪到这些后台的？

答案是：Service

Kubernete Service 是一个定义了一组Pod的策略的抽象，我们也有时候叫做宏观服务。这些被服务标记的Pod都是（一般）通过label Selector决定的（下面我们会讲到我们为什么需要一个没有label selector的服务）

举个例子，我们假设后台是一个图形处理的后台，并且由3个副本。这些副本是可以相互替代的，并且前台并需要关心使用的哪一个后台Pod，当这个承载前台请求的pod发生变化时，前台并不需要直到这些变化，或者追踪后台的这些副本，服务是这些去耦

对于Kubernete原生的应用，Kubernete提供了一个简单的Endpoints API，这个Endpoints api的作用就是当一个服务中的pod发生变化时，Endpoints API随之变化，对于哪些不是原生的程序，Kubernetes提供了一个基于虚拟IP的网桥的服务，这个服务会将请求转发到对应的后台pod。

Volumes
容器中的磁盘的生命周期是短暂的，这就带来了一系列的问题，第一，当一个容器损坏之后，kubelet 会重启这个容器，但是文件会丢失-这个容器会是一个全新的状态，第二，当很多容器在同一Pod中运行的时候，很多时候需要数据文件的共享。Kubernete Volume解决了这个问题。

Deployment
Deployment为Pod和ReplicaSet提供了一个声明式定义(declarative)方法，用来替代以前的ReplicationController来方便的管理应用。典型的应用场景包括：

  • 定义Deployment来创建Pod和ReplicaSet
  • 滚动升级和回滚应用
  • 扩容和缩容
  • 暂停和继续Deployment

Job
Job负责批量处理短暂的一次性任务 (short lived one-off tasks)，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束。

Kubernetes支持以下几种Job：

  • 非并行Job：通常创建一个Pod直至其成功结束
  • 固定结束次数的Job：设置.spec.completions，创建多个Pod，直到.spec.completions个Pod成功结束
  • 带有工作队列的并行Job：设置.spec.Parallelism但不设置.spec.completions，当所有Pod结束并且至少一个成功时，Job就认为是成功