Kubernetes基本概念与架构

Kubernetes，面向云原生应用的新“云平台”

Kubernetes：以google Brog为原型

Kubernetes的成长历程：

l  2014年，Kubernetes正式由google开源

l  2015年，谷歌将Kubernetes捐给Linux基金会下属的云原声计算基金会-CNCF

l  2017年，Kubernetes战胜Swarm和 Mesos，成为容器管理与调度编排领域的首选平台和事实标准

Kubernetes作为容器管理平台提供：

l  以Pod(容器组)为基本的编排和调度单元以及声明式的对象配置模型（控制器、configmap、secrect等）

l  资源配额与分配管理

l  健康检查、自愈、伸缩与滚动升级

Kubernetes提供了对微服务的支撑

l  服务发现、服务编排与内部路由支持

l  服务快速部署和自动负载均衡

l  提供对“有状态”服务的支持等

总结一下，Kubernetes提供：

l  新一代应用云化的事实标准，成为云原声的新可移植层，即新“云平台”

l  为用户提供简单且一致的容器化应用部署、伸缩和管理机制，形成新的、通用的应用云化模型

l  云厂商锁定的问题得以解决，云应用支持跨云迁移

Why Kubernetes

从生态圈角度：

l  Google的业内最成熟的容器编排管理经验的输出

l  2017年Kubernetes战胜Swarm和 Mesos，成为容器管理与调度编排领域的首选平台和事实标准

l  传统云平台提供商的全面支持：google k8s engine、 Red Hat的OpenShift、Microsoft的Azure container service,

从云应用角度，Kubernetes带来的好处 ：

l  容器管理、调度和编排的事实标准：摆脱锁定，支持跨云

l  先进的Workload管理之经验模型：Pod和Controllers

l  原生支持微服务抽象：服务注册、服务发现和自动负载均衡

1.Kubernetes架构与组件

Kubernetes架构全图：

Master组件：集群大脑

Master：Kubernetes集群大脑，控制平面：

l  所有集群的控制命令都传递给Master组件并在其上执行

l  每个Kubernetes集群至少有一套Mater组件

l  每套Master组件包括三个核心组件（apiserver,scheduler和controller-manager）以及集群数据配置中心etcd

组件API Server：

l  集群控制的唯一入口，是提供Kubernetes集群控制RESTful API的核心组件

l  集群内各个组件之间数据交互和通信的中枢

l  提供集群控制的安全机制（身份认证、授权以及admission control）

组件：Scheduler

l  通过API Server的Watch接口监听新建Pod副本信息，并通过调度算法为该Pod选择一个最为合适的Node

l  支持自定义调度算法provider

l  默认调度算法内置预选策略，决策考量资源需求、服务质量、软硬件约束、亲缘性、数据局部性等指标参数

组件：ControllerManager

l  集群内各种资源controller的核心管理者

l  针对每一种具体的资源，都有相应的Controller

l  保证其下管理的每个Controller

每个controller的逻辑：

For{

获取资源期望状态

获取资源当前状态

改变：当前状态à期望状态

　　}

组件：Etcd

l  Kubernetes集群的主数据库，存储着所有资源对象以及状态

l  默认与Master组件部署在一个Node上

l  Etcd的数据变更都是通过API Server进行

Node组件：

Node：工作负载节点

Node：Kubernetes急群众真正的工作负载节点

l  Kubernetes集群由多个Node共同承担工作负载，Pod被分配到某个具体的Node上执行

l  Kubernetes通过node controller对node资源进行管理。支持动态在集群中添加或删除Node

l  每个集群Node上都会部署Kubelet和Kube-proxy两个组件

组件Kubelet

l  位于集群中每个Node上的非容器形式的服务进程组件，Master和node之间的桥梁

l  处理Mater下发到本Node上的Pod创建、启停等管理任务；向API Server注册Node信息

l  监控本Node上容器和节点资源情况，并定期向Master汇报节点资源占用情况

组件：Kube-proxy（运行在每个Node上）

l  Service抽象概念的实现，将到Service的请求按策略（负载均衡）算法分发到后端Pod（Endpoint）上

l  默认使用iptables mode实现

l  支持nodeport模式，实现从外部访问集群内的service

总结一下，Kubernetes架构和组件：

l  两类节点：Master和Node

l  Master组件：apiserver，scheduler，controllerManager，etcd

l  节点组件：kubelet，kube-proxy

2.Kubernetes基础概念

Kubernetes对象：是一种持久化的，用于表示集群状态的实体

²  一种声明式的意图的记录，一般使用yaml文件描述对象

²  Kubernetes集群使用Kubernetes对象来表示集群的状态

²  通过API/kubectl管理Kubernetes对象

Name和UID：

²  Kubernetes集群中所有对象都通过name和UID明确标识

²  API中的对象访问路径：/api/{version}/namespaces/{namespace}/{object-kind}/name，比如：/api/v1/namespaces/default/podshello-kubernetes

²  在多媒体信息检索集群的整个生命周期内创建的眉哥哥对象实例都具有不同的UID

Namespace，不仅仅是一个属性，本身也是一个object

²  Namespace：用于将物理集群划分为多个虚拟集群

²  Namespace间完全隔离，因此也常被用来隔离不同的用户（及权限）

²  内置三个Namespace：default、kube-system和kube-public，Node和PersistenVolume不属于任何namespace

Label用于建立集群对象之间的灵活的、松耦合的多维关联关系

²  一个label是一个键-值对，其中key、value均由用户自己定义

²  Label可以附着在任何对象上，每个对象也可以由任意个标签。标签可在对象定义时附加上，也可以通过命令动态管理标签

²  Label可以将有组织有目的的结构映射到集群对象上，从而形成一个与现实世界管理结构同步对应松耦合的，多维的对象管理结构

通过label selector查询和筛选建立对象间的关系

Annotations：可以将任意非标识性元数据附加到对象上

²  Annotations也是可以键值对形式呈现的

²  工具和库可以检索到并使用这些Annotations元数据

²  将数据作为Annotation附着在对象上，有利于创建一些用于部署、管理和做内部检查的共享工具或客户端

Kubernetes对象分类

工作负载：以pod为中心

Pod：一个有特定关系的容器集合

u  Pod是集群中可以创建和部署的最小且最简的Kubernetes对象单元

u  Pod也是一种封装，它封装了应用容器，存储资源，独立的网络IP以及决定容器如何运行的策略选项

u  每个Pod中预置一个Pause容器，其名字空间、IPC资源、网络和存储资源被Pod内其他容器共享。Pod中的所有容器紧密协作，并且作为一个整体被管理、调度和运行

Pod生命周期

Service：与云原生应用中“微服务“概念一一对应

u  Kubernetes集群为每一个Service分配一个集群唯一的IP地址，在service的生命周期内，该IP地址不变；在内部DNS的支持下，轻松实现服务发现机制

u  Service通过label selector关联到实际支撑业务运行的Pod上，并通过集群内置的服务负载均衡将服务请求分发到后端的Pod

u  通过nodeport或设置loadbanlance机制实现集群外部对service的访问

Controller是Kubernetes核心对象之一

u  Controller用于保证集群内一组Pod能始终按照某种期望的状态（desired state）正常运行

u  状态包括：Pod副本数量、节点选择、资源约束、持久化数据维持等

u  Kubernetes支持多种Controller，常用的Deployment、replicaset、statefulset、damonset等

ReplicaSet：确保健康Pod的副本数始终满足用户定义的数量

u  前身是ReplicationController（rc）

u  相比rc，增加集合式label selector的支持

u  支持单独使用，但更多隐藏在Deployment控制器后面，由deployment自动管理

Deployment:为Pod和ReplicaSet提供了声明式的定义（declarative）

u  用户在deploy门头文件中描述期望状态，Deployment controller就会自动将Pod 和Replica Set 的实际状态改变到期望状态

u  Deployment支持Pod的RollingUpdate，并自动管理背后的ReplicaSet

u  Deployment支持将Pod Rollback 到之前的任意version（仅限于pod-template模板改动）

StatefulSet：提供对有状态应用的部署和控制的支持，1.9版本GA

u  适用场景：稳定的持久化存储、稳定的网络标志、有序部署有序扩展、有序收缩有序删除、有序自动滚动升级等

u  Pod的存储必须由PersistentVolume Provisioner根据请求的Storge Class进行配置，或由管理员预先配置好

u  考虑数据安全性，伸缩或删除StatefulSet不会删除关联的存储；另外Stateful目前要求Headless Service负责Pod的网络身份，用户有责任创建此服务

DaemonSet：保证在每个Node上都运行一个Pod副本

u  适用场景：系统Daemon程序、监控跟踪、日志收集等

u  Kubernetes1.6之后，可设置更新策略：支持滚动更新

u  可指定Node：nodeSelector、nodeAffinity、podAffinity

ConfigMap：常用来向Pod提供非敏感的配置信息

u  ConfigMap用于保存配置数据的键值对，可以用来保存单个属性，也可以用来保存配置文件

u  ConfigMap可以使用命令行基于字面值、文件或目录来创建或通过configmap对象定义文件创建

u  ConfigMap可以通过三种方式在Pod中使用：环境变量、容器命令行参数或以文件形式通过数据卷挂载到Pod中

Secret解决的是集群内密码、token、密钥等敏感数据的配置问题

u  常用于与ServiceAccount关联，存储在tmpfs文件系统中，Pod删除后Secret文件也会对应的删除

u  支持Opaque，Kubernetes.io/Service Account, Kubernetes.io/dockerconfigjson三种类型

u  Secrect可以以volume或者环境变量的方式使用