kubernetes基础概念

1.应用程序部署模式变迁

单机部署（2000前）->虚拟化（2001-2009）->容器化（2013年-至今）->云原生（2015-至今），其变迁模式如下图所示：

1.1虚拟化

虚拟化以vmware（2001）、xen（2003）和kvm（2007）为代表。

• 基于虚拟机技术的Amazon Web Service（AWS）开启了Infrastructure-as-a-service(Iaas)的时长，实现了自助的、按需租用的以VM为基本计算单元的计算资源
• openstack（2010）推动开源Iaas平台的快速发展，部署形式包括公有云、私有云、混合云等，服务模式：Iaas、PaaS、SaaS等（当前公有云四巨头：AWS、Azure、Aliyun、GCE）

虚拟机部署模式存在的问题

• 跨云数据迁移困难
• 虚拟器启机慢
• 扩展性差

1.2云原生模式

云原生模式的前提是应用的容器化和微服务化，其中容器是应用部署、运行和管理的基本单元。云原生模式策核心是借助容器管理自动化平台进行动态编排和资源优化利用。经过最近几年的发展，CNCF组织成立为应用上云安全地采用云原生模式提供了更稳、更快、更安全的解决方案、其核心是kubernetes。

云原生模式使得应用部署运行更敏捷、更自动化、更有效率、更低成本

2.Kubernetes是什么

kubernetes是以Google内部容器编排管理平台Brog为原型的开源实现，是一个容器编排管理平台、一个微服务支撑平台、一个可移植的“云平台”

• kubernetes是以Pod（容器组）为基本的编排和调度单元以及生命周期对象的配置模型，它提供了资源配额和分配管理，并提供健康检查、自愈、伸缩与滚动升级功能
• kubernetes是一个微服务支撑平台，可用于服务发现、服务编排和内部路由支持、服务快速部署和自动负载均衡，提供对“有状态”服务的支持等。

从生态圈的角度看，kubernetes是Google在业内最成熟的容器编排的管理经验的输出产物，它于2017年战胜Docker Swarm和Apache Mesos成为云原生应用唯一值得绑定的容器编排管理平台，并且得到了包括Google k8s engine、Red Had的OpenShift、微软的Azure container service、IBM的cloud container service等传统云平台提供商的全面支持。

从云应用的角度看，kubernetes是容器管理、多维度编排的事实标准。它支持跨云，借助先进的Workload管理值经验模型Pod和Controller，原生支持服务抽象：服务注册、服务发现和自动负载均衡等功能。

 

3.kubernetes架构与组件

kubernetes的架构和组件如下图所示：

3.1 master组件：

master组件是kubernetes架构中的大脑，所有的控制命令都传递给master组件并在master组件上执行。每个k8s集群至少有一台Master组件，如果master失效，集群将崩溃。因此生产环境需要多个master节点做高可用

每套master组件包括三个核心组件：API Server、scheduler、ControllerManager，以及集群数据配置中心etcd。

3.1.1 API Server（核心）

API Server 模块是集群控制的唯一入口，是提供kubernetes集群控制Restful api的核心组件，是集群内各个组件之间数据交互和通信的中枢，它提供集群控制的安全机制：身份认证、授权等机制

3.1.2 Scheduler

scheduler模块通过API Server 的watch接口监听新建Pod副本信息，并通过调度算法为该Pod选择一个最合适的Node。其支持自定义调度算法,默认的调度算法内置于预选策略和优选策略，调度决策考量资源需求、服务质量、软硬件约束、亲缘性、数据局部性等指标参数

3.1.3 ControllerManager：

ControllerManager是集群内各种资源的核心管理者，包括node、pod副本、服务节点、命名空间、服务账号等，针对每一种具体的资源，都有相应的controller

ControllerManager能够保证其下管理的每个controller所对应的资源始终处于“期望状态”，比如node挂了，controller会自行执行修复流程，使得node恢复到可用的“期望状态”

3.1.4 etc组件

etc组件是kubernetes集群的主数据库，存储着所有资源对象和状态，默认和master组件部署在一个Node上。Etcd的数据变更都是通过API Server进行的。

3.2 Node组件

Node组件是kubernetes集群中真正工作的负载节点。

其中，kubernetes集群有多个Node共同承担工作负载，Pod被分配到某个具体的Node上执行。kubernetes通过node controller对node资源进行管理，并支持动态在集群中添加或删除Node。每个集群Node上都会部署Kubelet和Kube-proxy

3.2.1 Kubelet模块

Kubelet是Pod的管家，位于集群中每个Node上，并且以非容器形式存在的服务进程组件，是master和node之间的桥梁。其主要工作是：

• 处理master下发到本Node上的Pod创建、启停等管理任务；
• 向Api Server注册Node信息
• 监控本Node上容器和节点资源情况、并定期想Master汇报节点资源占用情况

3.2.2 kube-proxy模块

kube-proxy是Service抽象概念的实现（Service是一组Pod的抽象），将到Service的请求按策略（负载均衡）算法分发到后端Pod（Endpoint）上。

• 默认使用iptables mode实现
• 支持nodeport模式，实现从外部访问集群内的service

 

4.kubernetes的基础概念

kubernetes集群使用kubernetes对象来表示进群的状态，kubernetes对象是一种持久化的、用于表示集群状态的实体，一般使用yaml文件描述对象，并通过API/kubectl来管理kubernetes对象。其对象模型如下：

4.1 Name和UID

kubernetes集群中所有对象都通过name和UID明确标识，并且在kubernetes集群的整个生命周期内创建的每个对象实例都具有不同的UID。API中的对象访问路径：/api/{versino}/namespaces/{namespaces}/{object-kind}/name，比如：

/api/v1/namespaces/default/pods/hello-kubernetes

4.2 namespaces

namespaces不仅是一个属性，本身也是一个对象，它用于将物理机群划分为多个虚拟机群。多个namespace间完全隔离，因此也常被用来隔离不同的用户（和权限）。kubernetes内置三个Namespace：

• default：默认的命名空间
• kube-system：kubernetes平台组件部署的空间，比如api-server，网络插件等
• kube-public：应该是公开的，并且被所有客户可见的资源专用

4.3 label

label也就是标签，用于建立集群对象之间的灵活的、松耦合的多维关联关系。一个label是一个键值对，其中的key、value均由用户自己定义。label可以附着在任何对象上、每个对象也可以有人一个标签。标签可在对象定义时附加上，也可以通过命令动态管理标签。label可以将有组织目的的结构映射到集群对象上，从而形成一个与现实世界观里结构同步对应松耦合的、多为的对象管理结构。通过label selector查询和筛选建立对象间的关系：

4.4 annotation

注解是可以将元素以非标识性元数据附加到对象上，并以键值对形式呈现。

4.5 kubernetes对象的分类

5 Pod和controller

Pod是集群调度的基本单元，所有组件的工作负载均以Pod为中心。

• 它是集群中可以创建和部署的最小且最简的kubernetes对象单元
• 它是一种封装。它封装了应用容器，存储资源、独立的网络IP和决定容器如何运行的策略选项
• 每个Pod中预置一个Pause容器，其名字空间、IPC资源、网络和存储资源被Pod其他容器共享。Pod中的所有容器紧密协作，并且作为一个整理被管理、调度和运行
• 它是一个非持久性实体：在调度失败、节点故障时，将被踢出集群，因此不建议手动创建Pod，而是通过控制器来自动管理Pod，便于复制、升级和管理。

Pod的状态图如下：

5.1 Service

service是pod的一个逻辑分组，与云原生应用中“微服务”概念一一对应。

kubernetes集群为每一个service分配一个集群唯一的IP地址，在service的生命周期内，该IP地址不变；在内部DNS的支持下，轻松实现服务发现机制.service通过label selector关联到实际支撑业务运行的Pod上，并通过集群内置的服务负载均衡将服务请求分发到后端Pod。service通过nodeport或设置loadbalancer机制实现集群外部对service的访问

5.2 controllers

Controller控制器的作用是保证集群内一组Pod能始终按照某种期望的状态（desired state）正常运行，其监控状态包括：Pod副本数量、节点选择、资源约束、持久化数据维持等。

Kubernetes支持多种controller，常用的deployment、replicaset、statefulset、daemonset等

5.2.1 replicaset

replicaset的前身是replicationController（rc），但增加了集合式label selector的支持，支持单独使用，但更多隐藏在deployment控制器后面，由deployment自动管理

5.2.2 deployment

deployment作为最常用的控制器，为Pod和replicaSet提供了声明式的定义，用户在deployment文件中描述期望状态，Deployment controller就会自动将Pod和replicaSet的实际状态改变到期望状态。

• deployment支持Pod的RollingUpdate（滚动更新）。并自动管理背后的replicaSet。
• deployment支持将Pod rollback到之前的任意revision（但仅限于pod-template模板改动）

5.2.3 statefulset

statefulset控制器提供对有状态的应用的部署和控制的支持。其使用场景包括：

• 稳定的持久化存储（集合中的Pod被重调度后，还能访问到相同的存储空间）
• 稳定的网络标志（Pod被重调度后，hostname不变）
• 有序部署有序扩展、有序收缩删除、有序自动滚动升级等（pod部署和升级是有序的，必须根据顺序依次完成）

Pod的存储必须由PersistentVolume Provisioner根据请求的Storage Class进行配置，或由管理员预先配置好，考虑数据安全性，伸缩或删除StatefulSet不会删除关联的存储。StatefulSet要求Headless Service 负责Pof的网络身份，用户有责任创建服务

5.2.4 DaemonSet

DaemonSet控制器保证在每个Node上都运行一个Pod副本。其使用场景：系统Daemon程序、监控跟踪、日志收集等‘

5.3 configMap和Secret

configMap和Secret是配置和存储类对象：

• configMap：常用来向Pod提供非敏感的配置信息
• Secret：解决的是集群内密码、token、密钥等敏感数据的配置问题，常用于与ServiceAccount关联、存储在tmpfs文件系统中，Pod删除后Secret文件也会对应的删除

6 最后

该文档是观看学习《Kubernetes基础：开启云原生之门》后整理而成。