目录
docker容器和虚拟机区别
k8s集群组件
1、Master组件
2、Node组件
3、核心附件
k3s集群管理平台
k3s原理架构图：
k3s 工作原理：
k8s和k3s对比
其他轻量级docker容器管理工具：swarm
swarm原理架构图：
前言：
官方定义1：Docker是一个开源的应用容器引擎，开发者可以打包他们的应用及依赖到一个可移植的容器中，发布到流行的Linux机器上，也可实现虚拟化。
官方定义2：k8s是一个开源的容器集群管理系统，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。
图1:
图1是Docker容器与传统虚拟化方式的不同之处，传统的虚拟技术，在将物理硬件虚拟成多套硬件后，需要再每套硬件上都部署一个操作系统，接着在这些操作系统上运行相应的应用程序。而Docker容器内的应用程序进程直接运行在宿主机(真实物理机)的内核上，Docker引擎将一些各自独立的应用程序和它们各自的依赖打包，相互独立直接运行于未经虚拟化的宿主机硬件上，同时各个容器也没有自己的内核，显然比传统虚拟机更轻便。（每个集群有多个节点，每个节点可创建多个容器，kuberbete就是管理这些应用程序所在的小运行环境（container）而生。）
图2:
图2是虚拟机和docker进行的对比。传统虚拟机（代表为：VMWare和OpenStack），占用空间大，启动慢等。容器则相反。
- 1、API Server
K8S对外的唯一接口，提供HTTP/HTTPS RESTful API，即kubernetes API。所有的请求都需要经过这个接口进行通信。主要负责接收、校验并响应所有的REST请求，结果状态被持久存储在etcd当中，所有资源增删改查的唯一入口。
- 2、etcd
负责保存k8s 集群的配置信息和各种资源的状态信息，当数据发生变化时，etcd会快速地通知k8s相关组件。etcd是一个独立的服务组件，并不隶属于K8S集群。生产环境当中etcd应该以集群方式运行，以确保服务的可用性。
etcd不仅仅用于提供键值数据存储，而且还为其提供了监听（watch）机制，用于监听和推送变更。在K8S集群系统中，etcd的键值发生变化会通知倒API Server，并由其通过watch API向客户端输出。
- 3、Controller Manager
负责管理集群各种资源，保证资源处于预期的状态。Controller Manager由多种controller组成，包括replication controller、endpoints controller、namespace controller、serviceaccounts controller等 。由控制器完成的主要功能主要包括生命周期功能和API业务逻辑，具体如下：
- 生命周期功能：包括Namespace创建和生命周期、Event垃圾回收、Pod终止相关的垃圾回收、级联垃圾回收及Node垃圾回收等。
- API业务逻辑：例如，由ReplicaSet执行的Pod扩展等。
- 4、调度器（Schedule）
资源调度，负责决定将Pod放到哪个Node上运行。Scheduler在调度时会对集群的结构进行分析，当前各个节点的负载，以及应用对高可用、性能等方面的需求。
Node主要负责提供容器的各种依赖环境，并接受Master管理。每个Node有以下几个组件构成。
- 1、Kubelet
kubelet是node的agent，当Scheduler确定在某个Node上运行Pod后，会将Pod的具体配置信息（image、volume等）发送给该节点的kubelet，kubelet会根据这些信息创建和运行容器，并向master报告运行状态。
- 2、Container Runtime
每个Node都需要提供一个容器运行时（Container Runtime）环境，它负责下载镜像并运行容器。目前K8S支持的容器运行环境至少包括Docker、RKT、cri-o、Fraki等。
- 3、Kube-proxy
service在逻辑上代表了后端的多个Pod，外借通过service访问Pod。service接收到请求就需要kube-proxy完成转发到Pod的。每个Node都会运行kube-proxy服务，负责将访问的service的TCP/UDP数据流转发到后端的容器，如果有多个副本，kube-proxy会实现负载均衡，有2种方式：LVS或者Iptables
K8S集群还依赖一组附件组件，通常是由第三方提供的特定应用程序。如下图：
- 1、KubeDNS
在K8S集群中调度并运行提供DNS服务的Pod，同一集群内的其他Pod可以使用该DNS服务来解决主机名。K8S自1.11版本开始默认使用CoreDNS项目来为集群提供服务注册和服务发现的动态名称解析服务。
- 2、Dashboard
K8S集群的全部功能都要基于Web的UI，来管理集群中的应用和集群自身。
- 3、Heapster
容器和节点的性能监控与分析系统，它收集并解析多种指标数据，如资源利用率、生命周期时间，在最新的版本当中，其主要功能逐渐由Prometheus结合其他的组件进行代替。
- 4、Ingress Controller
Service是一种工作于4层的负载均衡器，而Ingress是在应用层实现的HTTP(S)的负载均衡。不过，Ingress资源自身并不能进行流量的穿透，，它仅仅是一组路由规则的集合，这些规则需要通过Ingress控制器（Ingress Controller）发挥作用。目前该功能项目大概有：Nginx-ingress、Traefik、Envoy和HAproxy等。如下图就是Nginx-ingress的应用，具体可以查看博文：https://www.cnblogs.com/linuxk/p/9706720.html
k3OS 由容器软件提供商 Rancher Labs发布，这是业界首个专为 Kubernetes 而生的极轻量操作系统，资源消耗极低，操作极简，秒级启动，能大大简化在低资源计算环境中的 Kubernetes 操作，提高 Kubernetes 运维的安全性，全面赋能边缘计算场景。
k3OS 可以用于公有云和虚拟化集群，但除此之外，它在以边缘计算为代表的计算资源极其有限的环境中，尤其具有巨大的价值。其主要功能包括：
-
快速安装：k3OS只需10秒即可启动，且与此同时k3s是无需时间、立即可用的。
-
简化配置：Cloud-init支持在系统引导启动期间自动配置k3s，将其从通用镜像快速轻松地转换为已配置的k3s实例。
-
简化系统补丁和升级：管理员可以通过一组通用的YAML文件管理Kubernetes发行版和Linux发行版，并利用Kubernetes协调部署操作系统升级。
-
内置k3s：k3OS中内置了k3s，必要的一些系统服务（如ssh、udev、bash和iptables等）都已内置于分发镜像中，无需包管理器。
-
Ubuntu内核：Rancher借助Canonical的Ubuntu Server Kernel团队的出色工作，确保及时的安全更新和全面的设备支持。
-
多架构支持：k3OS现已支持x86_64，对ARM的支持也将很快完成。
适用场景不同：如果你要进行大型的集群部署，建议选择使用K8s；如果你处于边缘计算等小型部署的场景或仅仅需要部署一些非核心集群进行开发/测试，那么选择k3s则是性价比更高的选择。
K3s的四大使用场景为：
-
边缘计算
-
与应用程序绑定使用
-
嵌入式设备
-
CI环境
k3s 旨在成为完全兼容的 Kubernetes 发行版，相比 k8s 主要更改如下：
- 旧的、Alpha 版本的、非默认功能都已经删除。
- 删除了大多数内部云提供商和存储插件，可以用插件替换。
- 新增 SQLite3 作为默认存储机制，etcd3 仍然有效，但是不再是默认项。
- 封装在简单的启动器中，可以处理大量 LTS 复杂性和选项。
- 最小化到没有操作系统依赖，只需要一个内核和 cgroup 挂载。
K3s是一个轻量的K8s，主要面向IOT、Edge、CI等场景。
Lightweight Kubernetes. 5 less than k8s.
K3s和K8s的对比，移除了：
- 非默认的、遗留的特性
- Alpha阶段的特性
- In-tree的云服务提供商
- In-tree的存储驱动
- Docker (可选)
带来了：
- 简化安装
- SQLite3支持，替代etcd
- TLS管理
- 自动的Manifest和Helm Chart管理
- containerd, CoreDNS, Flannel
Swarm的基本架构很简单：每个主机运行一个Swarm代理，一个主机运行Swarm管理器（在测试的集群中，这个主机也可以运行代理），这个管理器负责主机上容器的编排和调度。Swarm能以高可用性模式（etcd、Consul 或ZooKeeper 中任何一个都可以用来将故障转移给后备管理器处理）运行。当有新主机加入到集群，有几种不同的方式来发现新加的主机，在Swarm中也就是服务发现。默认情况下使用的是token，也就是在Docker Hub上会储存一个主机地址的列表。
Swarm的优势：
swarm API兼容docker API，使得swarm 学习成本低，同时架构简单，部署运维成本较低。
Swarm的劣势：
同样是因为API兼容，无法提供集群的更加精细的管理。
在网络方面，默认docker容器是通过桥接与NAT和主机外网络通信，这样就出现2个问题，一个是因为是NAT，外部主机无法主动访问到容器内（除了端口映射），另外默认桥接IP是一样的，这样会出现不同主机的容器有相同的IP的情况。这样两容器更加不能通信。同时网络性能方面，有人测试经过桥接的网络性能只有主机网络性能的70%。当然以上问题可以通过其他工具解决，比如用 Flannel 或者 OVS网桥。
K8s 的优势：
容器的高可用性，集群的精细管理，复杂的网络场景。
K8s 的劣势：
K8s的学习曲线陡峭，同时运维的成本相对高点。
总结：对内使用，当作私有云来使用场景，或者对容器的可靠性要求不高，swarm比较合适；对外服务，或者需要提供高可靠服务的场景，k8s更合适（仅供参考）。
参考优质博文链接：
1.https://www.jianshu.com/p/f1f94c6968f5
2.https://www.cnblogs.com/haha-9527/p/10463466.html
3.https://www.cnblogs.com/linuxk/p/10291178.html
4.https://blog.csdn.net/liuliuzi_hz/article/details/51655569