原生技术基础学习(基础概念)

云原生技术基础学习

• 这是阿里的一个技术公开课，视频链接

基础

• 容器基本概念：
  • namespace 资源视图隔离
  • cgroup 控制资源使用率
  • chroot 独立的文件系统
  • 容器是一个视图隔离，资源可限制、独立文件系统的进程集合。
  • 容器镜像: 运行容器所需要的所有文件集合
    • Dockerfile 来描述镜像构建步骤。
    • 构建步骤所产生出文件系统的变化叫做 changeset
    • disk snapshot, 提高分发效率，减少磁盘压力。
• Kubernetes 的概念:
  • Kubernetes 是自动化的容器编排平台， 包括部署、弹性、管理
  • 核心功能: (kubernetes 的水平伸缩， 自动恢复， 调度)
    • 服务发现与负载均衡
    • 容器自动装箱
    • 存储编排
    • 自动容器恢复
    • 自动发布与回滚
    • 批量执行
    • 水平伸缩
  • 架构简介:
    • Kubernetes 架构是一个比较典型的二层架构 和 server-client 架构。master 作为作为中央的控制节点会与Node 进行一个连接。
    • 所有 UI，client 这些user侧组件只会和 Master 进行连接，把希望的状态或像执行的命令下发给master, master 会把这些命令或者状态下发给相应的节点，进行最终的执行。
    • Kubernetes 的 master 包含四个主要的组件: API Server, Contronller, Scheduler 以及 etcd。
      • API Server: Kubernetes 中的所有组件都会和 API Server 进行连接， 组件与组件之间不进行独立的连接，都依赖于 API Server 进行消息的传送。
        • 部署结构上，API Server 是一个可以水平扩展的一个部署组件
      • Controller: 是控制器，它用来完成对集群状态的一些管理。自动对容器进行修复和自动进行水平扩张，都是由 Kubernetes 的 Controller 来进行完成的。
        • Controller 是一个可以进行热备的部署组件，它只有一个active。
      • Scheduler: 是调度器，是完成调度的操作，把用于提交的 Container 依据它对CPU/Mem请求的大小，找到一台合适的节点，进行放置。
        • 调度器也是一个 active 的部署组件，可以进行热备。
      • etcd: 是一个分布式的存储系统，API Server 中所需的原信息都被放置在 etcd 中，etcd 本身是一个高可用系统，通过 etcd 保证整个 Kubernetes 的 Master 组件的高可用性。
    • Kubernetes 的 Node 架构:
      • Kubernetes 的 Node 是真正运行业务负载的，每个业务负载会以 Pod 的形式运行。
      • 一个 Pod 中运行的一个或者多个容器，真正去运行这些 Pod 的组件是被叫做 kubelet (Node上最为关键的组件)，kubelet会把 从API Server 接收到需要Pod运行的状态，然后提交到 Container Runtime 组件中。
      • 在 OS 上去创建容器所需要运行的环境，最终将容器或者Pod运行起来，需要对存储和网络进行管理，kubernetes 并不会直接进行网络存储的操作，他们会靠 Storage Plugin 或者 网络的 Plugin 来操作。
      • Kube-proxy 是真正完成 service 组网的组件，它利用 iptable 的能力来进行组建 Kubernetes 的 Networks, 也就是 cluster network。
    • Pod 是 Kubernetes 的一个最小调度以及资源单元， Pod 中也可以包含一些其他所需要的资源: 比如 Volume 卷的存储资源， 在 Pod 里买呢可以去定义容器所需要运行的方式，运行容器的 Command，以及运行容器的环境变量等。
    • Pod 这个抽象是给里面的容器提供一个共享的运行环境，他们会共享同一个网络环境，这些容器可以用 localhost 来进行直接的连接。而 Pod 与 Pod 之间，是互相有 isolation 隔离的。
    • Volume 卷的概念，它用来管理 Kubernetes 存储的，是用来声明在 Pod 中的容器可以访问文件目录的，一个卷可以被挂载在 Pod 中一个或多个容器的指定路径下。
    • Volume 本身是一个抽象的概念，一个 Volume 可以去支持多种的后端的存储。
      • 比如 Kubernetes 的 Volume 就支持了很多存储插件，可以支持本地存储，可以支持分布式存储(ceph, GlusterFS)，也可以支持云存储(云盘等)。
    • Deployment 是在 Pod 这个抽象上更为上层的一个抽象，它可以定义一组 Pod 的副本数目、 以及这个 Pod 的版本。
      • 一般用 Deployment 这个抽象来做应用真正的管理，而 Pod 是 组成 Deployment 的最小单元。
      • Kubernetes 是通过 Controller(控制器) 去维护 Deployment 中 Pod 的数目，它也会去帮助 Deployment 自动恢复失败的 Pod。
    • Service 提供了一个或者多个 Pod 实例的稳定访问地址。
      • 一个 Deployment 可能有 两个甚至更多个完全相同的 Pod, 但对于一个外部用户来讲，访问那个其实都一样，所以希望做一次负载均衡，在做负载均衡的同时，希望只访问某一个固定的 VIP(Virtual IP), Kubernetes 对网路IP地址的抽象就叫做 Service.
      • Service 有多种实现方式，Kubernetes 支持 Cluster IP, kuber-proxy 的组网也支持 nodePort，LoadBalancer.
    • Namespace 是用来做一个集群内部的逻辑隔离的，它包括鉴权、资源管理等。
      • Kubernetes 的每个资源，比如 Pod, Deployment, Service都属于一个 Namespace, 同一个 Namespace 中的资源需要命名的唯一性，不同的 Namespace 中的资源可以重名。
    • Kubernetes 的 API:
      • 从 high-level上看， Kubernetes API 是 HTTP + JSON 组成的，用户访问的方式是 HTTP，访问 API 中的 content 是 JSON 格式的。
      • Kubernetes 的 kuberctl 是 command tool, Kubernetes UI, 或者有时候用 curl 直接与 Kubernetes 进行通信， 都是 HTTP + JSON。
      • 对 Pod 类型的资源， 它 HTTP 访问路径，就是 API， 然后是 aipVersion: V1, 之后是相应的 Namespaces，以及 Pods 资源， 最终是 Podname（Pod的名字）。
• Pod 的概念:
  • pod是一个逻辑单位，多个容器的组合,
  • kubernetes的原子调度单位
  • Pod = “进程组”, 在 kubernetes 里面，Pod 实际上正是 kubernetes 项目为你抽象出来的一个可以类比为进程组的概念
  • 由于容器实际上是一个“单进程”模型
    • Linux 容器的“单进程”模型，指的是容器的生命周期等同于 PID=1 的进程（容器应用进程）的生命周期，而不是说容器里不能创建多进程。
    • 一般情况下，容器应用进程并不具备进程管理能力，所以你通过 exec 或者 ssh 在容器里创建的其他进程，一旦异常退出（比如 ssh 终止）是很容易变成孤儿进程的。
  • 容器是进程级别的隔离, 使用独立的文件系统
  • task co-schedulering
    • 资源囤积 (resource hoarding)
    • 乐观调度处理冲突, 乐观锁的实现更加复杂
    • kubernetes pod
  • 容器之间原本是被 Linux Namespace 和 cgroups 隔离开的，Pod 之间共享网络是通过 Infra Container 方式共享同一个 Natwork Namespace
    • k8s.gcr.io/pause 镜像，汇编语言编写的，永远处于于暂停。
    • 一个Pod只有一个IP地址，也就是这个Pod的NetWork Namespace 对应的IP地址
      • 所有网络资源，都是一个Pod一份，并且被该Pod中的所有容器共享
    • 整个Pod的生命周期跟Infra容器一致，与其他容器无关
    • shared-data 对应在宿主机上的目录会被同时绑定挂载进除Infra以外的容器中
  • 容器设计模式:
    • Sidecar: 应用与日志收集，代理容器，适配器容器
  • Pod 是Kubernetes 项目里实现 "容器设计模式" 的核心机制
  • 容器设计模式 是google Borg 的大规模容器集群管理最佳实践之一
    • 容器设计模式 进行复杂应用编排的基础依赖之一
  • 所有 "设计模式" 的本质都是: 解耦和重用