核心概念
[toc]
认识Kubernetes?
开源的、用于管理云平台中多个主机上的容器化的应用,目标是然给部署容器化的应用简单并且高效(Docker-compose不借助其他工具只可以管理单主机上的)
为什么需要Kubernetes
传统部署
两个应用之间环境不隔离(比如写文件时冲突)
虚拟化部署(部署在虚拟机上)
占用资源过多(启用虚拟机要分配较大的内存)
容器化部署
环境隔离、占用资源少
Kubernetes的特点
- 自我修复
- 弹性伸缩
- 自动部署和回滚
- 服务发现和负载均衡
- 机密和配置管理
- 存储编排
- 批处理
企业级容器调度平台
Apache Mesos:
一个分布式调度系统内核、遭遇DOcker产生,Mesos作为资源管理器,从DC/OS角度提供资源视图,主/从结构工作模式,主节点分配任务,并用从节点上的Executor负责执行,通过Zookeeper给主节点提供服务注册、服务发现功能。通过Framwork Marthon提供容器调度的能力。支模拟测试支持超过5w+节点,在大规模上拥有较大优势。
Docker Swarm:
一个有Docker开发的调度框架。好处之一是标准Docker API的使用。由于随Docker引擎一起发布,无需额外安装,配置简单,支持服务注册、服务发现,内置Overlay Network以及Load Balancer。与Docker CLI非常类似的操作命令,对熟悉Docker的人非常容易上手。适用于中小型系统。
Google Kubernetes:
最流行的容器编排解决方案框架,基于Google庞大的生态圈及社区产生的产品。通过Pods这一抽象的概念,解决Container之间的依赖与通信问题。Pods,Services,Deployments是独立部署的部分,可以通过Selector提供更多的灵活性,内置服务注册表的负载均衡。实用度更广,功能更强大,相较于Mesos拉力说哦节点规模较小。
集群架构与组件
- 节点分为主、从节点
- 只有从节点部署任务
- 主节点可只做主节点,也可以同时做从节点
- 所有的操作有个汇聚中心api-server,它维护了k8s中所有对于节点或者任务处理的操作
- 对于用户而言,我们通过命令行操作k8s,经由api-server,转换为api调用请求,所以对于机器而言,看到的是restful的请求
相关组件
控制面板组件(在Master节点上)
- kube-api-server
- kube-controller-manager
- cloud-controller-manager
- kube-scheduler
- etcd
节点组件(普通节点上)
- kubelet
- kube-proxy
- container runtime
- 一台服务器是一个节点
- 一个节点中可以有多个Pod
- 一个Pod中至少有一个容器
附加组件(可选)
- kube-dns:负责为整个集群提供DNS服务
- Ingress Controller:为服务提供外网入口
- Heapster(或者Prometheus):提供资源监控
- Dashboard:提供GUI
- Federation:提供可用区的集群
- Fluentd-elasticsearch:提供集群日志采集、存储与查询
分层架构
- 生态系统
- 接口层
- 管理层:系统度量(如基础设施、容器和网络的度量)、自动化(如自动扩展、动态Provision等)以及策略管理(RVAC、Quota、PSP、NetworkPolicy等)
- 应用层:部署(无状态应用、有状态应用、批处理任务、集群应用等)和路由(服务发现、DNS解析等)
- 核心层:最核心的功能、对外提供API构建高层的应用,对内提供插件式应用执行环境
服务的分类
无状态应用
- Nginx
- Apache
不会对本地环境产生任何依赖,例如不会存储数据到本地磁盘
优点:对客户端透明,无依赖关系,可以高效实现扩容、迁移
缺点:不能存储数据,需要额外的数据服务支撑
有状态应用
- MySQL
- Redis
会对本地环境产生依赖,例如需要存储数据到本地磁盘
优点:可以独立存储数据,实现数据管理
缺点:集群环境下需要实现主从、数据同步、备份、水平扩容复杂
资源和对象
k8s中所有内容都抽象为资源,如Pod、Service、Node等都是资源。“对象”就是“资源”的实例。
对象的创建、删除、修改,都是通过Kubernetes API(即Api Server)进行的。
资源的分类
- 元数据:
- Horizontal Pod Autoscaler(HPA):
- Pod自动扩容,可以根据CPU使用率或自定义指标自动对Pod进行扩/缩容
- 控制管理器每隔30s,查询metrics地资源使用情况
- 支持三种metrics类型
- 预定义metrics(比如Pod的CPU),以利用率地方式计算
- 自定义地Pod metrics,以原始值(raw value)的方式计算
- 自定义的object metrics
- 支持两种metrics查询方式:Heapster和自定义的REST API
- 支持多metrics
- PodTemplate:
- 关于Pod的定义,到那时被包含在其他的Kubernetes对象中(例如Deployment、StatefulSet、DaemonSet等控制器)。控制器通过Pod Template信息来创建Pod。
- LimitRange:
- 对集群内Request和Limits的配置做一个全局统一的限制,相当于批量设置了某一个范围内(某个命名空间)的Pod的资源使用限制
- Horizontal Pod Autoscaler(HPA):
- 集群:
- Namespace
- Node
- 节点相当于一台服务器的概念
- ClusterRole
- ClusterRoleBinding:将ClusterRole和Role绑定到对应的集群上去
- 命名空间
工作负载型(Pod)
Pod(容器组)是Kubernetes中最小的可部署单元。一个Pod(容器组)包含了一个应用程序容器(某些情况下可以是多个)、存储资源、一个唯一的网络IP地址、以及一些确定容器该如何运行的选项。Pod容器代表了Kubernetes中一个独立的应用程序运行实例,该实例可能有单个容器或者几个紧耦合在一起的容器组成。
Docker是Kubernetes Pod中施一公最广泛的容器引擎
Kubernetes集群中的Pod存在如下两种使用途径
- 一个Pod中只运行一个容器
- 一个Pod中运行多个需要互相协作的容器。
副本(replicas):一个Pod可以被复制成多份,每一份可以称为一个副本
控制器:每一个控制器都是一个Pod对象
适用无状态服务
- ReplicationController(RC):
- V1.11就已经废除了
- 在资源足够情况下,帮助动态更新Pod的副本数
- ReplicaSet(RS):
- 对RC的一次升级
- 帮助我们动态更新Pod的副本数
- 可以通过selector来选择对哪些Pod生效
- 只有扩容、缩容能力
- Deployment
- 对RS的更高层次的封装
- 创建Replica Set/Pod
- 滚动升级/回滚
- 平滑扩容和缩容
- 暂停与恢复Deployment
- ReplicationController(RC):
适用有状态服务
StatefulSet:专门针对有状态服务的控制器
介绍:
- StatefulSet中每个Pod的DNS格式为statefulSetName(0,…,N-1).serviceName.namespace.svc.cluster.local
- serviceName为Headless Service的名字
- 0,…,N-1为Pod所在的序号,从0开始到N-1
- statefulSetName为StatefulSet的名字
- namespace为服务所在的namespace,Headless Service和StatefulSet必须在相同的namespace
- .cluster.local为Cluster Domain
- StatefulSet中每个Pod的DNS格式为statefulSetName(0,…,N-1).serviceName.namespace.svc.cluster.local
特点
解决网络、数据、顺序问题
稳定的持久化存储
稳定的网络标志
有序部署、有序扩展(即Pod是有顺序的,在部署或者扩展的时候要依据定义的顺序依次进行,即从0到N-1,在下一个Pod运行之前所有之前的Pod必须是Running和Ready状态)(基于init containers来实现)
有序收缩、有序删除
组成
- Headless Service:用于定义网络标志
- Domain Name Server
- 域名服务将域名与ip绑定映射
- 服务名 => 访问路径(域名) => ip
- VolumeClaimTmplate
- 用于创建持久化卷的模板
- Domain Name Server
- Headless Service:用于定义网络标志
注意事项:
守护进程
- DaemonSet:为每一个匹配的Node都部署一个守护进程
- 保证在每个Node上都运行一个容器副本,常用来部署一些集群的日志、监控或者其他系统管理员应用。有:
- 日志搜集,比如fluentd,logstash等
- 系统监控,比如Prometheus Node Exporter,colletd,New Relic agent,Ganglia gmond等
- 系统程序,比如kube-proxy,kube-dns,glusterd,ceph等
- 保证在每个Node上都运行一个容器副本,常用来部署一些集群的日志、监控或者其他系统管理员应用。有:
- DaemonSet:为每一个匹配的Node都部署一个守护进程
任务/定时任务:
- Job:一次性任务,运行完成后Pod销毁,不再重新启动新容器
- CronJob:在Job基础上加上了定时功能
服务发现
Service:
- k8s集群内部的网络通信,简写“svc”。Pod不能直接提供给外网访问,而是应该使用service。Service就是把Pod暴漏出来提供服务,Service才是真正的“服务”,它的中文名就叫“服务”
- Service是一个应用服务的抽象,定义了Pod逻辑集合和访问这个Pod集合的策略。Service代理Pod集合,对外表现为一个访问入口,访问该入口的请求将经过负载均衡,转发到后端Pod中的容器。
Ingress::实现嫁给你k8s内部服务暴漏给外网访问的服务
- ingress-nginx
- 反向代理
- 负载均衡(七层负载)
- ingress-nginx
存储:
- Volume:数据卷,共享Pod中容器使用的数据。用来放持久化的数据,比如数据库数据。
- CSI(Container Storage Interface):
- 来自Kubernetes、Mesos、Docker等社区成员联合制定的一个行业标准接口规范,旨在将任意存储系统暴漏给容器化应用程序
- CSI规范定义了存储提供商实现CSI兼容的Volume Plugin的最小操作集和部署建议。CSI规范的主要焦点是声明Volume Plugin必须实现的接口。
特殊类型配置:
- ConfigMap:“键值对”配置文件
- Secret:作用同ConfigMap,区别在于可以加密
- Service Account:用来访问Kubernetes API,由Kubernetes自动创建,并且会自动挂载到Pod的/run/secrets/kubernetes.io/serviceaccount目录中
- Opaque:base64编码格式的Secret,用来存储密码、密钥等
- kubernetes.io/dockerfonfigjson:用来存储私有docker
- DownwardAPI:这个模式和其他模式不一样的地方在于它不是为了存放容器的数据也不是用来进行容器和宿主机的数据交换的,而是让pod里的容器能够直接获取到这个pod对象本身的一些信息。
- downwardAPI提供了两种方式用于将pod的信息注入到容器内部
- 环境变量:用于单个变量,可以将pod信息和容器信息直接注入容器内部
- volume挂在:将pod信息生成文件,直接挂在到容器内部中去
- downwardAPI提供了两种方式用于将pod的信息注入到容器内部
其他:
- Role:一组权限的集合,例如Role可以包含列出Pod权限及列出Deployment权限,Role用于给某个Namespace中的资源进行鉴权
- RoldBinding:绑定到对应的命名空间去,可以作用于Role和ClusterRole
资源清单
对象规约和状态
规约(Spec)
必需的,描述对象的期望状态
状态(Status)
表示对象的实际状态,该属性有k8s自己维护,k8s会通过一系列的控制器对对应对象进行管理,让对象尽可能地让实际状态与期望状态重合