什么是云原生？

不同企业对云原生有不同的解释，最为广泛接受的是：云原生是一类技术的统称 或者 是一套指导进行软件架构设计的思想，通过云原生技术，我们可以构建出更易于弹性扩展的应用程序。它包含了当前业界的一些热门的技术，比如：容器、微服务、DevOps等。

第二讲 容器的基本概念

什么是容器？

容器是一个视图隔离（能够看见部分进程等 namespace）、资源可限制（限制资源使用率 cgroup）、独立文件系统（chroot）。

容器运行时所需要的所有文件集合称为容器镜像。通常采用Dockerfile构建镜像。

容器运行时的生命周期

• 单进程模型

  启动容器时，会选择相应的文件系统（镜像来提供），以及指定相应的运行程序，那么这个运行程序我们称为init进程。在容器运行过程中，我们会发现，当这个init进程启动了，那么这个容器也启动了，当这个init进程退出了，那么这个容器也就随之退出了。所以，init进程的生命周期与容器生命周期一致。

• 数据持久化

  数据卷volume，独立于容器的生命周期；

容器项目的架构

• moby容器引擎架构

  moby daemon会提供关于容器、镜像、网络以及volume的管理。它依赖的最重要的组件是containerd（容器运行时管理引擎），独立于moby daemon，containerd-shim管理容器生命周期，可被containerd动态接管。

容器和VM的差异

VM是利用Hypervisor虚拟化技术来模拟硬件资源，需要Guest OS（装在VM上的系统），可以提供更好的隔离效果。但是，我们需要将一部分的计算资源交给虚拟化，导致很难充分利用计算资源，并且每个Guest OS需要占用大量的磁盘空间。

容器无需Guest OS，只需要一个独立的文件系统。所有的隔离级别都是进程级别的；启动时间更快；但隔离效果较弱。

第三讲 Kubernetes核心概念

什么是Kubernetes

自动化的容器编排平台

核心功能：

• 服务发现与负载均衡；
• 容器自动装箱（把一个容器放到某个集群的某个机器上）；
• 存储编排；
  • 自动容器恢复（节点健康检查，将有问题的节点上的容器迁移到其他节点上去）；
• 自动发布与回滚；
• 配置与密文管理；
• 批量执行；
• 水平伸缩（业务负载检查，可以对负载过高的服务进行扩容）；

Kubernetes架构

• API Server：消息传送；
• Controller：完成对集群状态的管理；
• Scheduler：调度；
• etcd：分布式存储，API Server中所需要的信息都放在etcd中；

用户可以通过ui或cli向kubernetes提供一个pod进行部署，API Server会将相关信息存储到etcd中，Scheduler会通过API Server的watch或者notification机制得到这个信息（有一个pod需要被调度），Scheduler会根据它的资源状态进行一次调度决策，在完成这次调度之后，Scheduler会向API Server通知这个pob需要被调度到某个节点上，API Server会将调度的结果再次写入到etcd中。然后，API Server会通知对应的节点进行pob的启动和执行。相应节点的kubelet会得到这个通知，调用Container runtime来配置、启动这个容器的运行环境，去调用Storage Plugin来配置存储，调用Network Plugin来配置网络。

Kubernetes核心概念和API

• Pod

  • 最小的调度以及资源单位；
  • 由一个或者多个容器组成；
  • 在Pob中可以定义容器运行的方式（Command、环境变量等）；
  • 提供给容器共享的运行环境（网络、进程空间，pob与pob之间是有隔离的）；

• Volume

  • 用来声明容器的访问目录（Pob中的容器可以访问的文件目录）；
  • 一个volume可以被挂载在一个Pob中的一个或多个容器的指定路径下；
  • volume是一个抽象的概念，它可以支持多种后端的存储（分布式、云存储…）；

• Deployment

• 定义一组Pob的副本数目、版本等；

• 通过Colltroller维持Pob的数目，Controller可以自动恢复失败的Pod；Deployment中Pob的数目是通过Controller来指定的，当一个Pod失败时，Controller可以检测到，来生成新的Pob。

• 可以通过Controller以指定的策略控制版本：滚动升级、重新生成、回滚；

• Service

  

  • 提供访问一个或多个Pod实现的稳定访问地址（负载均衡）；

• Namespace

  

  • 一个集群内部的逻辑隔离机制（鉴权、资源调度）；
  • 每个资源都属于一个Namespace；
  • 同一个Namespace中的资源命名唯一；

第四讲 理解Pod和容器设计模式

由四个进程共同组成的应用helloworld，在kubernates中会被定义为拥有四个容器的Pod。Pob只是一个逻辑单位，真正启来的实际上是四个容器。

为什么Pod必须是原子调度单位？

举例：两个紧密协作（需要部署在一台机器上）的容器App和LogCollector；

内存要求：App—1G、LogCollector：0.5G；

当前可用内存：Node_A：1.25G、Node_B：2G；

如果App先被调度到了Node_A上，那么就会导致LogCollector调度失败。

这就是Task co-scheduling问题：

• Mesos的解决办法：资源囤积；所有设置了Affinity约束的任务都到达时，才开始同一进行调度；带来的问题是：调度效率损失、死锁；
• Google Omega：乐观调度；不管冲突，出现冲突之后回滚；
• Kubernetes：Pod；不存在上面的问题；App和LogCollector属于一个Pob，一起被调度；

亲密关系：两个应用需要运行在同一台宿主机上（Pod之间）；通过调度解决；

超亲密关系：会发生直接的文件交换；使用localhost或者socket文件进行本地通信；会发生非常频繁的RPC调用；会共享某些Linux Namespace（比如：一个容器要加入另一个容器的Network Namespace，就可以看到另一个容器的网络设备以及网络信息）；通过Pod解决；

Pod实现机制

容器之间原本是被Linux Namespace和cgroups隔离开的，那么如何让一个Pod里的多个容器之间最高效的共享某些资源和数据？

• 共享网络

  

  在每一个Pod里会启动一个Infra container小容器来共享整个Pod的Network Namespace。Pob内部容器直接使用localhost进行通信；每个容器看到的网络设备跟Infra容器看到的一样；一个Pod只有一个IP地址，也就是这个Pod的Network Namespace对应的IP地址；所有网络资源都是一个Pod一份，并且被该Pod中的所有容器共享；整个Pod的生命周期跟Infra容器一致，而与内部的其他容器无关；

• 共享存储

  挂载到同一个volume；