传统部署方式
java --> package --> 放到服务器上 --> Tomcat
如果是同时进行写操作,会存在并发问题.
用户 --网络带宽–> 服务器 -->服务
同一个服务器上,多个服务:
网络资源的占用
内存的占用
cpu的占用
…
资源争抢
复杂度可以通过脚本来解决.
虚拟化部署/隔离机制/占用资源过多
java --> package --xx.jar–> linux服务器(虚机[Tomcat < xx.jar文件 >])
带来了,资源占用过度问题
虚机的启动是分钟级别
容器化部署
容器的启动是 秒级别的.
为了解决以上问题,需要什么?
自我修复
弹性伸缩
自动部署和回滚
服务发现和负载均衡
机密和配置管理
存储编排
批处理
企业级服务调度平台有哪些?
概念: 资源管理器,把所有的资源管理,调度,主从模式,zookeeper给主节点提供服务注册,服务发现功能,通过Framework Marathon 提供容器调度能力.
优势: 发布时间早,5w+节点控制,大规模节点的管理.
缺点: 面向节点,而不是容器
概念: 标准版的Docker API
优势: 和Docker是集成的.
缺点: 已经弃用了.没人用.
概念: 使用Label和Pod的概念来将容器分为逻辑单元.Pods是同步地写作(co-located)容器的集合. 这是kubernetes 和其他两个框架哎的主要区别.简化了管理.
优势: 通过pods这一抽象的概念,解决了Container之间的依赖于通信问题,Pods,Services, Deployment 是独立部署的部分,可以通过 Selector 提供更多的灵活性,内置服务注册表和负载均衡.
缺点: 相比于 Apache Mesos 管理节点规模小
kube-apiserver
接口服务,REST风格,k8s接口服务
kube-controller-manager
控制器管理器: 管理各个类型的控制器,管理k8s的各个资源
cloud-controller-manager
云控制器管理器: 第三方云平台提供的控制器API对接管理平台
kube-scheduler
调度器: 负责将pod给予一定算法,将其调用到合适的节点(Node)上
etcd
k8s的数据库,键值对,分布式数据库,基于Raft算法,
老版本: 基于内存
新版本: 持久化存储
kubelet
负责容器的生命周期
负责Volume(CVI)挂载,存储
网络(CNI)管理
kube-proxy
网络代理,负责Service的服务发现,负载均衡(4层负载)
container-runtime
负责镜像管理已经Pod和容器的真正运行(CRI容器运行环境接口)
docker,containerd,CRI-O,
kube-dns
kube-dns 负责为整个集群提供 DNS 服务
ingress Controller
Ingress Controller 为服务提供外网入口
Prometheus
Prometheus 提供资源监控
Dashboard
Dashboard 提供 GUI
Federtion
Federation 提供跨可用区的集群
Fluentd-elasticsearch
Fluentd-elasticsearch 提供集群日志采集、存储与查询
生态系统
- Kubernetes 外部:日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS 应用、ChatOps 等
- Kubernetes 内部:CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等
接口层
kubectl 命令行工具、客户端 SDK 以及集群
管理层
系统度量(如基础设施、容器和网络的度量),自动化(如自动扩展、动态 Provision 等)以及策略管理(RBAC、Quota、PSP、NetworkPolicy 等)
应用层
部署(无状态应用、有状态应用、批处理任务、集群应用等)和路由(服务发现、DNS 解析等)
核心层
Kubernetes 最核心的功能,对外提供 API 构建高层的应用,对内提供插件式应用执行环境
无状态
举例: Nginx /Apache
优点: 对客户端透明,无依赖关系,可以高效实施扩容,迁移
缺点: 不能储存数据,需要额外的数据服务支撑
有状态
举例: Mysql/Redis
优点: 可以独立存储数据,实现数据管理
缺点: 集权环境下需要实现主从,数据同步,备份,水平扩容复杂
Horizontal Pod Autoscaler(HPA)
Pod 自动扩容:可以根据 CPU 使用率或自定义指标(metrics)自动对 Pod 进行扩/缩容。
- 控制管理器每隔30s(可以通过–horizontal-pod-autoscaler-sync-period修改)查询metrics的资源使用情况
- 支持三种metrics类型
- 预定义metrics(比如Pod的CPU)以利用率的方式计算
- 自定义的Pod metrics,以原始值(raw value)的方式计算
- 自定义的object metrics
- 支持两种metrics查询方式:Heapster和自定义的REST API
- 支持多metrics
PodTemplate
Pod Template 是关于 Pod 的定义,但是被包含在其他的 Kubernetes 对象中(例如 Deployment、StatefulSet、DaemonSet 等控制器)。控制器通过 Pod Template 信息来创建 Pod。
LimitRange
可以对集群内 Request 和 Limits 的配置做一个全局的统一的限制,相当于批量设置了某一个范围内(某个命名空间)的 Pod 的资源使用限制。
Namespace
Kubernetes 支持多个虚拟集群,它们底层依赖于同一个物理集群,这些虚拟集群被称为命名空间。
作用是用于实现多团队/环境的资源隔离。
命名空间 namespace 是 k8s 集群级别的资源,可以给不同的用户、租户、环境或项目创建对应的命名空间。
默认 namespace:
- kube-system 主要用于运行系统级资源,存放 k8s 自身的组件
- kube-public 此命名空间是自动创建的,并且可供所有用户(包括未经过身份验证的用户)读取。此命名空间主要用于集群使用,关联的一些资源在集群中是可见的并且可以公开读取。此命名空间的公共方面知识一个约定,但不是非要这么要求。
- default 未指定名称空间的资源就是 default,即你在创建pod 时如果没有指定 namespace,则会默认使用 default
Node
不像其他的资源(如 Pod 和 Namespace),Node 本质上不是Kubernetes 来创建的,Kubernetes 只是管理 Node 上的资源。虽然可以通过 Manifest 创建一个Node对象(如下 json 所示),但 Kubernetes 也只是去检查是否真的是有这么一个 Node,如果检查失败,也不会往上调度 Pod。
ClusterRole
ClusterRole 是一组权限的集合,但与 Role 不同的是,ClusterRole 可以在包括所有 Namespace 和集群级别的资源或非资源类型进行鉴权。
ClusterRoleBinding
ClusterRoleBinding:将 Subject 绑定到 ClusterRole,ClusterRoleBinding 将使规则在所有命名空间中生效。
####### 工作负载型