一、容器的由来及演变史¶
Docker --> Docker-compose --> Docker swarm --> Kubernetes
二、微服务容器化的几种解决方案¶
| 特 性 | Docker Swarm | Kubernetes |
|---|---|---|
| 安装和集群配置 | 安装非常简单，但是集群不是很强大 | 安装很复杂；但是一旦安装完毕，集群就非常强大 |
| 图形用户界面 | 没有官方界面依托第三方 | 自带功能较完善的Kubernetes bashboard |
| 可伸缩性 | 高度可伸缩&比Kubernetes 快5倍 | 高可伸缩性和快速扩展 |
| 自动伸缩 | Docker Swarm不能自动缩放 | Kubernetes可以进行自动缩放 |
| 负载均衡 | Docker Swarm可以自动平衡集群中容器之间的流量 | 基于iptables/ipvs（调度算法丰富） |
| 规模 | 1000节点、50000容器 | 节点数不超过 5000、Pod 总数不超过 150000、容器总数不超过 300000、每个节点的 pod 数量不超过 100 |
| 核心功能 | 管理节点高可用、调度任务、服务发现、回滚、更新、通讯安全、容器HA、服 务自愈、配置管理、健康检查、服务伸缩 | 资源调度、服务发现、服务编排、资源逻辑管理、服务自愈、安全配置管理、job任务支持、自动回滚、内部域名服务、健康检查、扩 容伸缩、负载均衡、灰度升级、应用HA、容灾恢复 |
| 社区主力 | docker | google、redhat、coreos、华为、浙大sel |
| 设计初衷 | 跨宿主机管理容器集群 | 支持分布式、服务化的应用架构 |
2.1 Docker Swarm架构图¶
Manager nodes
-
维护一个集群的状态；
-
对 Services 进行调度；
- 为 Swarm 提供外部可调用的 API 接口；
Worker nodes
- 用来执行 Task；
2.2 Kubernetes架构图¶
- Master Node：作为控制节点，对集群进行调度管理；Master Node由API Server、Scheduler、Cluster State Store和Controller-Manger Server所组成；
- Worker Node：作为真正的工作节点，运行业务应用的容器；Worker Node包含 kubelet、kube proxy和Container Runtime；
- etcd：保存了整个集群的状态，就是一个数据库；
- apiserver：提供了资源操作的唯一入口，并提供认证、授权、访问控制、API 注册和发现等机制；
- controller manager：负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
- scheduler：负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上；
-
kubelet：负责维护容器的生命周期，同时也负责 Volume（CSI）和网络（CNI） 的管理；
-
Container runtime：负责镜像管理以及 Pod 和容器的真正运行（CRI)；
-
kube-proxy：负责为 Service 提供 cluster 内部的服务发现和负载均衡；
三、部署方式选择¶
kubeadm：
- 简单优雅；
- 支持高可用；
- 升级方便；
- 官方支持；
kubernetes二进制：
- 早期线上主流方式；
- 部署耗时长；
- 稳定性较高；
Kubernetes-as-a-Service（公有云服务）
- 阿里云：ACK
- AWS Cloud：EKS
