容器、Docker、K8S、云原生，这些热词都是啥，他们彼此有啥联系，今天我们简单直白一点，来个你问我答。
容器是什么？和虚拟化到底有啥不一样？
在很久以前，服务器小哥哥都是直接扛活，就像胸口碎大石！
一个服务器，对应一个操作系统，这种玩法，实在是太浪费了，明明可以拼颜值，现在却来碎大石，简直是暴殄天物。
于是乎，虚拟化技术和容器技术被开发出来，目的就是让服务器小哥哥人尽其才、物尽其用。
看图一目了然：容器撇掉了臃肿的操作系统，只需把基础的库文件打包带走就可以了，所以身轻如燕。
一台物理机通常能支持成百上千的容器，而且创建和释放的速度都是秒级的，甩了虚拟机好几条街。
正因为这样，容器才成了当红炸子鸡，大部分云原生架构，都是以容器为算力单元的。
容器就是 Docker 吗？
Docker ≠ 容器，Docker 只是众多容器引擎之一。
容器引擎主要负责两件事：
第一，负责容器的整个生命周期管理，从生到死。
第二、负责本地容器镜像的构建和管理。同时配合镜像仓库，完成海量镜像的存储和管理。
早在 Docker 出现之前，容器就已经存在了，但 Docker 公司生逢其时，推动了容器的大发展，结果，很多人就把Docker 跟容器划了等号。
时至今日，已经有 N 多容器引擎，开始挑战 Docker 的王者地位，也正因为如此，Docker 公司走下了神坛。
既然有了容器引擎，还要 K8S 作甚？
随着容器的火爆，利用容器架构来搭建业务系统的人越来越多。可是，大家在实操中发现，像 Docker 之类的容器引擎，折腾少量容器还行。但如今的云原生应用、机器学习任务或者大数据分析业务，动辄就要使用成百上千的容器。要管理这么多容器，Docker 们就力不从心了。
江山代有才人出，各领风骚三五年，有需求就有改变，于是乎，市场上就出现了一批容器编排工具，典型的是 Swarm、Mesos 和 K8S。
经过几年大浪淘沙，K8S“击败”Swarm 和 Mesos，几乎成了当前容器编排的事实标准。
K8S 最初是由 Google 开发的，后来捐赠给了 CNCF（云原生计算基金会，隶属 Linux 基金会）。
K8S 的全名是 kubernetes，读作“库伯耐踢死”，很多国人既拼不对也写不对，而 K 和 S 之间有 8 个字母，索性就简单一点，叫“开八司”了。
K8S 是个杂技高手，最擅长的就是“搬箱子”，盘各种容器玩。
K8S 的大致架构，就像上面。Master 节点，用来放“脑子”，“腿脚”搭在工作节点上“搬砖”，工作节点就是实际业务容器的存放地。
单个容器或多个关系密切的容器，被编成一组，称为 pod。K8S 就是以 pod 为单位进行编排操作。
同时，K8S 还要和其它相关软件配合，来完成联网、存储、安全等功能。
诞生六年来，K8S 一路高歌，成为容器编排和调度领域的 No.1。但需要注意的是，K8S 和 Docker 们不是替代关系，而是配合关系。
K8S 仍然会使用 Docker 之类的容器引擎（Docker、Containerd、RKT、CRI-O 等），来对容器进行生命周期管理。
K8S 既然那么猛，直接拿来用不香吗？
这样做，看起来没毛病，K8S 是开源软件，社区版 K8S 也很完美。
你可以在网上找到各种安装指导文档，然后从 github 轻松找到最新的版本，然后一步一步搭建集群。
只是安装过程漫长而痛苦，毕竟搭建集群不是我们的目的，我们的目的是利用集群来干活。
搭一个 K8S 学习环境倒也罢了，权当练手涨经验。可当我们要搭建生产环境的时候，事情就变得不一样了。
这时候，为了保证集群的可靠性，我们可能要跨多个可用区来部署 K8S 集群。对于大多数人来说，这个工作不太好玩。
不止搭建集群过程很复杂，后期还要面对更繁琐的 K8S 控制平面维护工作：版本升级、安全管控、数据备份等等。
所以，面对生产级别的业务，大家往往喜欢选择 Turnkey （一站式）的商用方案，而不是自己慢慢鼓捣，老牛拉破车。
云上一站式 K8S 方案，到底哪家强？
目前，各大云服务商几乎都推出了 Turnkey 方案，帮助用户快速搭建 K8S 集群。
到底哪家强呢？王婆卖瓜，自卖自夸，似乎没有定论。
但是有个数据很有参考意义，根据咨询机构「Nucleus Research」的数据，所有云中 K8S 的工作负载，竟然有 82%都是运行在 Amazon Web Services (AWS) 上的。
So，我们差不多可以这样说，云上 K8S，还是 AWS 最强！
AWS 提供了一个神器，叫做 Amazon Elastic Kubernetes Service (Amazon EKS)，可以快速帮我们搭建高可用的云上托管 K8S 服务。
Amazon EKS 到底牛在哪儿？
作为一个从来没摸过 K8S 的生手，我用了不到 10 分钟，就创建了一个横跨 3 个可用区的生产级集群，实在太魔幻了。
整个过程，只需要区区两步↓
在添加工作节点的时候，可以选择各种 Amazon EC2 实例，AWS 准备了丰富的实例类型，满足不同的容器用途。
当然，还可以选择新酷的 AWS Fargate 工作节点，这是一种 Serverless 的方式，说白了，你不需要去考虑什么实例呀、服务器呀，直接按需使用容器即可，要多少有多少，计费精确到容器，而非主机。
集群创建完成后，我们就可采用自己习惯的工具，比如 kubectl，像使用标准 K8S 集群一样，进行各种业务部署的操作了。
除了简单、易用、生产级高可用以外，Amazon EKS 与社区版的 K8S 是保持同步的，原生体验完全一致，可以使用社区所有插件和工具…
So，不需要额外的学习成本，也不用担心锁定，轻松迁移。
作为云上 K8S 大户，AWS 也充分发扬开源精神，源于社区、反哺社区，不断为 K8S 项目做贡献，推动 K8S 的改进。
AWS 为 Amazon EKS 提供了多达 270 种节点，可以满足所有工作负载和业务需求，并提供为 Amazon EKS 定制优化的操作系统镜像，高效、安全、开源。
同时，Amazon EKS 还与 AWS 其他服务无缝集成，诸如负载均衡、弹性伸缩、身份认证、存储、安全、监控、日志，用户不需要苦逼滴自己造轮子，站在 AWS 肩膀上就行。
更令人心动的是，不止于 Amazon EKS，围绕容器、K8S、微服务这些云原生的关键技术，AWS 提供了一揽子解决方案。
随着云计算进入深水区，云原生的理念越来越深入人心，利用 AWS的「容器全家桶」，用户可以轻松搭建各种高可用「云原生」服务，把上云的价值最大化。