什么是容器
容器就是Container，一般把它形象地比喻成集装箱，它正好和Docker的现实含义相对应，因为码头工人（小鲸鱼）在不停地装运集装箱。
容器跟集装箱一样标准化封装各种货物，容器中封装的货物就是运行中的应用程序，也就是进程，它能够把进程与外界隔离开来，让进程与外部系统互不影响，这样就能够将容器从一个地方迁移到任意的其他地方。
简单的运行一个容器，看一下容器里运行的进程是个什么样子
-
使用
docker pull命令，拉取一个新的镜像--alpine操作系统
-
docker run
-
使用-it参数，暂时离开当前的ubuntu系统，进入到容器内部
-
cat /etc/os-release查看容器的系统信息，这里就是Alpine Linux 3.18.0系统 -
ps -ef容器内只运行了sh进程，是个完全干净的运行环境
也就是说容器内部是一个全新的Alpine系统，与外界的ubuntu系统完全隔离。也就是说容器是一个特殊的隔离环境，它能够让进行只看到这个环境里的有限信息，不能对外界环境施加影响。使用容器技术，就是将应用程序运行在一个有严密防护的沙盒环境当中，它能够在该环境里面自由活动，但绝不能越界，从而保证了容器外系统的安全（防止恶意程序将外部系统搞瘫痪、或正常程序的bug导致信息泄露等）。
此外， 容器技术的另一个本领就是为应用程序加上资源隔离，在系统里切分出一部分资源，让它只能使用制定的配额。（如：只分配一个CPU、1GB内存给该容器）避免容器内进程的过度系统消耗，让有限的资源能够提供稳定可靠的服务。
容器与虚拟机的区别
容器和虚拟机使用的都是虚拟化技术，目的都是隔离资源，保证系统安全，尽量提高资源的利用率。
-
-
容器：是直接利用下层的计算机硬件和操作系统，因为比虚拟机少了一层，所以自然会节约CPU和内存，显得非常轻量级，能够更高效地利用硬件资源。但是，多个容器共用操作系统内核，应用程序的隔离程度就没有虚拟机高。
-
此外，从图上可以看到，同样系统资源，虚拟机只能跑3个应用，其他的资源都用于支持虚拟机运行了，而容器则能够将这部分资源释放出来，同时运行6个应用，运行效率更高
隔离的实现
容器使用的是Linux操作系统内核中为资源隔离提供的三个技术：
-
namespace：创建独立的文件系统、主机名、进程号、网络等资源空间，给进程盖了一间小板房，这样就实现了系统全局资源和进程局部资源的隔离
-
cgroup：用来实现对进程的CPU、内存等资源的优先级和配额限制，相当于给进程的小板房加了天花板
-
chroot：可以更改进程的根目录，也就是限制访问文件系统，相当于给进程的小板房铺上地砖
通过以上三个技术，就能构建出一个具有完善的隔离特性的容器，进程就在这个小板房里面活动。
镜像与仓库
-
镜像（image）：打包了应用程序（包括进程运行所需要的文件系统、依赖库、环境变量、启动参数等信息），并且还有应用运行时的整个系统环境。相当于小板房的”样板间“，操作系统能根据这个”样板间“快速搭建一个容器。
-
具备了非常好的跨平台便携性和兼容性，能让开发者在一个系统上开发（如Ubuntu），然后打包成镜像，再去另一个系统上运行。
-
-
上面，介绍了容器技术docker的简单内容，容器技术的核心概念就是容器、镜像、仓库，使用这三大基本要素我们就可以轻松地完成应用的打包、分发工作，实现”一次开发，到处运行“。但在服务器集群里面大规模实施的时候，却会发现容器技术的创新只是解决了运维部署工作中一个很小的问题。现实生产环境的复杂程度实在是太高了，除了最基本的安装，还会有各式各样的需求，比如服务发现、负载均衡、状态监控、健康检查、扩容缩容、应用迁移、高可用等等。并且服务器集群中运行隔离了数不清的进程，它们之间还需要互相通信、互相协作，那么在这些容器之上的管理、调度工作就叫做容器编排。
k8s是一个生产级别的容器编排平台和集群管理系统，不仅能够创建、调度容器，而且还能够监控、管理服务器。
k8s一般都是运行在大规模的计算集群上，管理很严格。但又提供了一些快速搭建k8s环境的工具，官网推荐：kind和minikube，它们都能在本机上运行完整的k8s环境。
docker与k8s的区别
-
docker是容器技术，k8s是容器编排技术，两者思考的维度不同
-
就容器而言，容器解决的问题是隔离，是一次打包到处运行的问题，最大的价值在于镜像的迁移。
-
编排技术则是关注的是整个系统的问题，如果只关注一个服务，迁移一个服务，docker就足够，但要迁移整个系统以及运维，那就需要编排，包括网络关系、负载均衡、回滚、监控、扩缩容问题则需要容器编排技术。
-
集群中的计算机被称为节点Node，可以是实机也可以是虚拟机
-
少量的节点用作控制面来执行集群的管理维护工作
-
其他大部分节点被划归数据面，用于跑业务应用
-
-
控制面的节点在k8s中叫做Master Node，简称Master
-
数据面的节点叫做Worker Node，一般叫做Worker 或 Node
-
kubectl是k8s的客户端工具，用于操作k8s，不属于集群
Master：
-
apiserver：k8s系统的唯一入口，它对外公开了一系列的RESTful API，并且加上了验证、授权等功能，所有其他组件都只能和它直接通信；
-
etcd：持久化存储，它是一个高可用的分布式key-value数据库，持久化存储系统中的各种资源对象和状态（k8s配置管理员）。它只与apiserver有直接联系，其他组件想要读写etcd中数据需要经过apiserver；
-
scheduler：负责容器的编排工作，检查节点的资源状态，把Pod调度到最合适的节点上运行。因为节点状态和Pod的信息都在etcd中，所以scheduler需要通过apiserver才能获得；
-
controller-manager：负责维护容器和节点等资源状态，实施故障检测、服务迁移、应用伸缩等；controller-manager是很多个controller的集合体，每一个controller负责一种控制循环（如node controller、namespace controller），但为了简化被合并在一个进程里执行
以上四个组件都被容器化，运行在集群的Pod里：
-
kubelet：是Node的代理，负责Node相关的绝大部分操作，Node中只有kubelet才能与apiserver通信，实时状态报告、命令下发、启停容器等；
-
kube-proxy：Node的网络代理，只负责管理容器的网络通信，简单来说就是为Pod转发tcp/udp数据包；--负责本地集群网络，保障Pod间的网络路由与负载均衡
-
container-runtime：是容器和镜像的实际使用者，在kubelet的指挥下创建容器，管理Pod的生命周期；container-runtime可以是docker，也可以是其他的 如：containerd、CRI-O；
-
使用minikube ssh登录到节点后，使用docker ps | grep kube-proxy和ps -ef | grep kubelet查看
-
工作流程：
-
每个Node上的kubelet会定期向apiserver上报节点的状态，apiserver再存到etcd里
-
每个Node上的kube-proxy实现了TCP/UDP反向代理，让容器对外提供稳定的服务
-
scheduler通过apiserver得到当前的节点状态，调度Pod，然后apiserver下发命令给某个Node的kubelet，kubelet调用container-runtime启动容器
-
controller-manager也通过apiserver得到实时的节点状态，监控可能的异常情况，再使用相对应的手段去调节恢复
-
Pod
-
容器技术主要是隔离性，但这种隔离性会带来一些麻烦。因为现实场景中很少有应用是完全独立运行的，经常需要几个进程相互协作才能完成。而多个应用若是结合的非常精密以至于无法将其拆分，那么强制分成多个容器，切断联系，就无法工作。
-
为了解决这样多应用联合运行的问题，同时还要不破坏容器的隔离，就需要在容器外面再建一个“收纳舱”，也就是Pod--这样让多个容器保持相对独立，又能小范围共享网络、存储等资源。
-
Pod的YAML文件中spec.containers字段就是一个数组，定义多个容器。
-
Pod是对容器的打包，里面的容器是一个整体，总是能够一起调度、一起运行，绝不会出现分离的情况，而且Pod属于k8s，可以在不触碰到下层容器的情况下任意定制修改。
-
k8s让Pod去编排处理容器，将Pod作为应用调度部署的最小单位。
-
k8s的Pod不会前台运行，只能后台运行。
-
Pod管理了多个进程，可以理解为Linux里的“进程组”的概念，是一组进程组成的应用，所以Pod也可以称为“容器组”，与实机、虚机对应也可以称为逻辑主机。
Job/CronJob--离线任务
-
Pod是k8s中作为集群里调度运维的最小单位，k8s不会在容器层面来编排业务
-
k8s中有两大类业务：在线服务，如Nginx、Redis、MySQL等【一旦运行，基本不会停】；离线服务，如日志分析、数据建模、视频转码等，一般不直接服务于外部用户，只对内部用户有意义。【运行后必定会退出】
-
离线业务需要考虑运行超时、状态检查、失败重试、获取计算结果等，与容器管理无必然关联，那么Pod就不需要对其管理--引入Job/CronJob
-
-
离线任务分为两类：临时任务：负责的API对象是Job；定时任务：负责的API对象是CronJob。
-
Job可以做一些耗时计算的业务，如：模型的计算、数据的备份等；
-
CronJob可以做一些周期需要执行的业务，如：定期的消息推送、定期的历史数据清理等；
ConfigMap/Sercet--配置管理
-
ConfigMap：保存明文配置，如：服务端口、运行参数、文件路径等；【缩写cm】
-
Secret：保存秘密配置，如：密码、密钥、证书等；secret对象细分很多类：如
-
访问私有镜像仓库的认证信息
-
身份识别的凭证信息
-
HTTPS通信的证书和私钥
-
一般的机密信息（格式由用户自行解释）
-
Deployment--在线任务
-
在线业务不是单纯启动一个Pod，还有多实例、高可用、版本更新等更多复杂操作，要运用好k8s的自动化运维优势，使用Deployment对象来管理在线业务的Pod
DaemonSet--在线任务
-
Daemonset在形式上和Deployment类似，都是管理控制Pod，但管理调度策略不同。
-
Daemonset的目标是在集群的每个节点上运行且仅运行一个Pod--相当于该Pod“守护”该节点。比如以下业务，需要与主机存在绑定关系，必须要依附于节点才能产生价值：
-
网络应用（如kube-proxy）：必须每个节点都运行一个Pod，否则节点无法加入kubernetes网络
-
监控应用（如Prometheus）：每个节点都要有一个Pod用来监控节点状态，上报信息
-
日志应用（如Fluentd）：每个节点都要有一个Pod来搜集容器运行时产生的日志数据
-
安全应用：每个节点都要有个一个Pod来执行安全审计、入侵检查、漏洞扫描等工作
-
-
Deployment则不会关心设置好数量的Pod会在集群的哪个节点上运行，只要数量够，应用程序就能工作，不能保证每个节点上都会对应的Pod
-
Service--服务发现
-
集群内部的负载均衡机制，用来解决服务发现的关键问题
-
service的工作原理跟LVS、Nginx类似，k8s会给它分配一个静态IP地址，然后它再去自动管理、维护后面动态变化的Pod集合，当客户端访问Service，它就根据某种策略，把流量转发给后面的某个Pod
-
Service使用了iptables技术，每个节点上的kube-proxy组件自动维护iptables规则，客户不再关心Pod的具体地址，只要访问Service的固定IP地址，Service就会根据iptables规则转发请求它管理的多个Pod，是典型的负载均衡
本文参考文章：本文是在学习k8s过程中的内容总结，参考的课程链接为：Kubernetes 入门实战课 (geekbang.org)
