如何虚拟容器核数

Kubernetes学习笔记

• K8S入门

• 为什么要学习Kubernetes

• 轻装上阵
• 全面拥抱微服务架构
• 无缝迁移
• 弹性扩容
• 充分利用服务器资源
• 自动化的运维平台

• Kubernetes基础理论

• 服务部署模式演变形态
• Kubernetes基本概述

• 容器及容器编排技术

• 容器技术
• Docker 容器
• 容器编排技术

• Docker-Compose
• Docker-Swarm
• Mesos
• Kubernetes

• 云原生技术

• 什么叫云原生技术
• 云知识扩展

• Kubernetes核心组件原理

• Kubernetes架构

• 整体架构
• Master 节点
• Node 节点
• 核心组件工作流程

• Kubernetes核心组件架构

• Kubernetess是干什么的？
• 服务部署架构

• 无状态服务
• 有状态服务

• Kubernetes核心资源对象

• 标签 Label
• 副本控制器
• Deployment
• HPA
• DaemonSet
• StatefullSet
• Volume

K8S入门

为什么要学习Kubernetes

• 以kubernetes【k8s】为核心的云原生技术正在吃掉整个世界，以kubernetes核心的技术正在成为企业技术的标准。
• 越来越多的企业正在把应用迁移到云原生平台上面。
• 无论是传统企业，互联网企业都在做数字化转型，云原生是企业数字化转型唯一路径；一旦使用了云原生技术以后，企业开发效率将会得到成倍的增长。
• 市场的发展，架构发展趋势（云原生架构—很多企业采用这样架构标准）。

根据技术发展趋势：

• JDK：跨平台(JVM)

• 劣势：占用内存，依赖JVM，导致Java语言性能不如一些脚本语言（go语言）。
• 优势：庞大生态系统，庞大用户群体。
• 改进： 2021发布JDK新的版本，全面拥抱云原生技术——编译Java程序，去掉JVM，编译成类似可执行脚本语言，然后以一个非常轻量级的形式实现在云原生平台上运行。

• 云原生：跨平台(容器化跨平台)

轻装上阵

• 一旦使用kubernetes技术，不需要关心那些和项目业务没有太多关系的底层模块代码（通信组件），服务治理相关的组件。只需要关心项目业务即可，因此开发团队只需要一个小而精悍的团队（一个架构师，10个程序员，一个运维）。

全面拥抱微服务架构

• 微服务架构体系（拆分比较细，按照function进行拆分），一旦使用微服务架构以后，关心整个服务调用链路情况（链路追踪），服务治理相关动作，因此微服务架构体系给团队添加了很多不必要工作。
• 但是使用kubernetes技术以后，就不需要关心服务治理相关的内容，只需要关心业务开发即可。

无缝迁移

项目开发（开发环境） — 持续集成（集成测试） ------ 发版（软件质量评审） ------ 上线部署（生产环境）

• 问题：测试环境，生产环境不一致性导致项目上线出现很多问题。

弹性扩容

服务上线

• 促销活动 ------ 流量增大 ------ 预演，压测预案 （限流，降级）------ 扩容服务器
• 突发事件 ------ 社交网站（明星结婚）------ 突然爆发的流量 ------- 弹性扩容

• 案例：根据 CPU、内存利用率进行弹性扩容

充分利用服务器资源

• 服务器 CPU 资源，内存资源在部署应用程序，无法得到充分利用。尤其是一些高性能计算机，内存、CPU 资源占用率非常底，如果不能实现很到的部署调度，存在大量的资源浪费。

• 使用k8s技术构建云计算平台，充分利用服务器资源，实现服务部署合理的调度，使得服务以更好组态来实现运行或者计算。
• Kubernetes可以把各个节点无缝整合在一起，形成一个整体，以更好的组态来实现运行计算。例如： 以下n 多个节点组织在一起，看起来就相当于一台计算机；CPU、内存就是所有的节点 CPU、内存相加之和。

自动化的运维平台

• 使用kubernetes后，可以构建一套自动化的运维平台； 运维更加智能化，最终结果： AiOPS，noOps。

Kubernetes基础理论

服务部署模式演变形态

• 第一代服务部署模式：物理机部署模式，即把应用程序都部署到物理机。

• 物理机：10W 台服务器，怎么管理？——人工管理

• 第二代服务部署模式：虚拟机部署模式

• 虚拟机：10W 虚拟机，OpenStack

• 第三代服务部署模式：云原生部署模式

• 容器化：几十万容器，如何管理？——Kubernetes 容器编排（管理）技术，容器云的操作系统。

• 问题：Kubernetes 是什么？
• 答案：Kubernetes 就是一个容器编排（管理）技术，也把 Kubernetes 叫做容器云的操作系统（管理，调度）。

Kubernetes基本概述

• Kubernetes设计之初就是为了管理，调度容器技术，是google开发的一套开源的容器化编排技术。
• 官网地址：https://kubernetes.io/

• Google在15年之前就已经使用服务编排技术，borg系统（战略级武器，google数十亿服务之所以能平稳运行）。容器化技术发展了以后，很多产品服务编排技术（mesos,docker-swarm）。使用go语言，参考google的borg架构，开发一套容器编排技术，就是kubernetes，因此 kubernetes 是站在巨人肩膀上成长起来。

容器及容器编排技术

容器技术

• LXC：Linux Containers，集成到 Linux 内核中容器化技术。LXC 没有一套详细的可操作的 api，因此 docker 对 LXC 做了一个封装，开发出了一套完善接口，且 docker 发布之初走开源路线，一经发布就非常火。

Docker 容器

• Docker原理： 依赖于镜像，容器之间隔离使用 cgroup + namespace 实现隔离的。

容器编排技术

Docker-Compose

• Docker-Compose 是一个容器管理技术，可以实现容器批量创建、删除、更新。但是它不能实现容器精细化控制（自愈，弹性扩容，服务治理……），且Docker-compose仅仅是单机版的容器编排技术，不能实现跨服务器调度。

Docker-Swarm

• 目前三大主流的容器平台 Swarm，Mesos 和 Kubernetes 具有不同的容器调度系统。
• Swarm的特点是直接调度Docker容器，并且提供和标准Docker API一致的API。
• 每台服务器上都装有 Docker 并且开启了基于 HTTP 的 Docker API。这个集群中有一个 SwarmManager 的管理者，用来管理集群中的容器资源。管理者的管理对象不是服务器层面而是集群层面的，也就是说通过 Manager，我们只能笼统地向集群发出指令而不能具体到某台具体的服务器上要干什么（这也是Swarm的根本所在）。至于具体的管理实现方式，Manager向外暴露了一个HTTP接口，外部用户通过这个HTTP接口来实现对集群的管理。

• Docker公司研发的开源的容器编排技术，通过http协议实现服务调度，不能实现容器的精细化控制。

Mesos

• Mesos针对不同的运行框架采用相对独立的调度系统，其框架提供了Docker容器的原生支持。 Mesos并不负责调度而是负责委派授权，毕竟很多框架都已经实现了复杂的调度。

Kubernetes

• Kubernetes则采用了 Pod 和 Label 这样的概念，把容器组合成一个个的互相存在依赖关系的逻辑单元。相关容器被组合成 Pod后 被共同部署和调度，形成服务（Service）。这个是Kubernetes和Swarm，Mesos的主要区别。
• Kubernetes（k8s）是自动化容器操作的开源平台，这些操作包括部署，调度和节点集群间扩展。如果你曾经用过Docker容器技术部署容器，那么可以将Docker看成Kubernetes内部使用的低级别组件。Kubernetes不仅仅支持Docker，还支持Rocket，这是另一种容器技术。

使用Kubernetes可以：

• 自动化容器的部署和复制
• 随时扩展或收缩容器规模
• 将容器组织成组，并且提供容器间的负载均衡
• 很容易地升级应用程序容器的新版本
• 提供容器弹性，如果容器失效就替换它，等等…

云原生技术

什么叫云原生技术

• 定义：云原生技术是以 K8S 为核心的一套云原生架构体系，是一套软件架构体系。架构师在架构时遵循 kubernetes 云原生架构设计模式，把这种架构模式叫做云原生架构。
• 云原生：

• 架构思想：软件架构开发的思想。
• 应用角度：让所有的软件服务都必须运行在容器中，然后使用容器编排技术进行管理，这样的架构就叫做云原生架构。

• 云原生特点：

• 容器化：所有应用程序都必须运行在容器中。
• 微服务：项目最好是采用微服务架构，适合运行在容器中（云端），实现云原生架构模式。
• DevOps：开发+运维的结合体，DevOps 是一种敏捷开发的思想，一种组织形式，实现开发的流水线生产模式。
• CI/CD：可持续部署，可持续集成。

• CNCF(云原生组织)：对云原生架构体系扩展，ServiceMesh 服务网格架构 （istio）——云原生架构

云知识扩展

• 云计算三层架构：（IAAS : 基础设施即服务 ，PAAS : 平台及服务 ， SAAS: 软件即服务）。

• caas (container as a service) : 容器即服务
• faas（function as a service） 函数即服务——serverless
• ServiceMesh：还需要学习ServiceMesh
• serverless 无服务架构（开发人员不需要关心服务器任何东西，只需要开发代码即可）

Kubernetes核心组件原理

Kubernetes架构

整体架构

• Kubernetes是一个分布式架构体系，一个 master 对应一群 node 节点，实现 kubernetes 高可用，就需要有多个master，来实现master故障切换。
• Master 节点：主要负责任务调度，不进行服务部署。
• Node 节点：部署服务。

Master 节点

核心组件功能剖析：

• apiServer：网关，所有的请求指令都必须经过 apiServer 认证。
• scheduler：调度器，负责把要部署的服务调度到一个合适的 node 节点进行部署。但是其并不会帮助我们直接部署服务，而是通过 etcd 存储调度映射关系，而是由 node 节点中 kubelet 组件实现服务的部署，以达到解耦的目的。
• controller-manager：控制器，管理服务资源对象，实现资源对象 CRUD。
• etcd：nosql数据库，用来存储集群状态，存储资源对象。

Node 节点

• Node 节点是用来部署服务的，服务的部署形态：服务部署在容器中，而容器又被 Pod 所封装。

Node核心组件：

• docker引擎： 服务部署在容器，容器由docker引擎来创建，因此每一个node节点都会有一个 docker。
• kubelet：node节点代理，kubelet实现本node节点服务部署的代理工作。
• kube-proxy：负载均衡。
• fluentd：日志收集组件，第三方插件。
• pod：K8S 服务部署的最小单元，所有服务都被部署在pod内部的容器中。

核心组件工作流程

Kubernetes核心组件架构

Kubernetess是干什么的？

• K8S 用来编排（管理）容器的，但是 K8S 并不会直接操作容器，而是通过管理 pod 来进行管理容器的。
• pod 是 K8S 管理服务的最小操作单元。

• 总结：K8S 用来部署服务（应用程序），不仅仅用来编排服务，部署服务，还可以让服务以更好的组态实现在服务器中运行。

服务部署架构

无状态服务

• 没有实时的数据需要存储（即使有数据，这些数据也是静态数据）。
• 服务的集群网络中，把一个服务从集群中拿掉，一段时间后，再把服务放回去，对服务集群没有任何影响。

• 无状态服务部署结构：进行服务部署的时候，创建了三个对象：deployment、ReplicaSet、POD。

有状态服务

• 有实时的数据需要存储。
• 服务的集群网络中，把一个服务从集群中拿掉，一段时间后，再把服务放回去，对服务集群有影响。
• 影响数据的完整性、一致性，数据可能会丢失。
• POD 是运行在操作系统中的一个进程，被设计之初就是一个生命周期比较短暂的服务。POD 可能出现宕机、异常，一旦 POD 异常，数据就会丢失。

• 有状态服务部署的核心思想： 数据存储（在有状态服务模式下，考虑数据存储问题，如何保障数据完整性）。
• 因此其核心的思想就是要解决数据存储问题，解决pod异常，宕机后，数据也不能丢失，且 POD 恢复以后还能找到原来的数据。

Kubernetes核心资源对象

K8S 的核心资源对象主要有：标签、副本控制器（ReplicationController、ReplicaSet）、Deployment、HPA、DeamonSet、Volume。

标签 Label

• 在k8s中，使用标签对k8s所有资源对象打上标签，实现资源对象精细化控制，可以根据标签精细化定位资源对象。
• 标签格式：key : value。
• Kubernetes中任意API对象都是通过Label进行标识，Label的实质是一系列的 Key/Value 键值对，其中key于value由用户自己指定。
• Label可以附加在各种资源对象上，如Node、Pod、Service、RC等，一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上去。
• 版本标签：“release”:“stable”,“release”:“canary”…
• 环境标签：“environment”:“dev”,“environment”:“qa”,“environment”:“production”
• 架构标签：“tier”:“frontend”,“tier”:“backend”,“tier”:“middleware”
• 分区标签：“partition”:“customerA”,“partition”:“customerB”
• 质量管控标签：“track”:“daily”,“track”:“weekly”

副本控制器

副本控制器资源对象名称：ReplicationController、ReplicaSet。

• 作用：用来保证副本的数量，永远和预期所设定的数量一致。也就是说副本控制器可以让服务永远处理可用状态，且是自动的。
• 场景：当服务（POD）异常、宕机，副本控制器立马对 pod 进行重建。保证 POD 服务是可用的，且 POD 服务数量还要和预期设定的数量一致。
• 注意：在新版本中，副本控制器 ReplicaSet 取代了 ReplicationController，因为 ReplicaSet 功能比 ReplicationController 强大，支持复合标签选择器，而 ReplicationController 只支持单个标签选择器。

问题：副本控制器如何知道哪些 POD 被它控制？
答案：标签

Deployment

• 部署资源对象名称：Deployment
• 作用：Deployment 为 Pod 和 ReplicaSet 提供了一个 声明式定义方法，用来替代以前的 ReplicationController 来方便的管理应用。
• 典型的应用场景：

• 定义 Deployment 来创建 Pod 和 ReplicaSet
• 滚动升级和回滚应用
• 扩容和索容
• 暂停和继续 Deployment

• Deployment不仅仅可以滚动更新，而且可以进行回滚，如果发现升级到V2版本后，发现服务不可用，可以回滚到V1版本。

HPA

• Horizontal Pod Autoscaling 仅适用于 Deployment 和 ReplicaSet，在V1版本中仅支持根据Pod的CPU利用率扩容，在vlalpha版本中，支持根据内存和用户自定义的metric扩缩容。

DaemonSet

• DaemonSet 部署服务的时候，把一个服务确保部署到每一个节点中。
• Node上运行一个Pod的副本，当有Node加入集群时，也会为他们新增一个Pod。当有 Node 从集群移除时，这些Pod也会被回收。删除 DaemonSet 将会删除他创建的所有Pod，使用DaemonSet 的一些典型用法：

• 运行集群存储daemon，例如在每个Node上运行 glustered、ceph。
• 在每个Node上运行日志收集Daemon，例如：fluentd、logstash。
• 在每个Node上运行监控Daemon，例如：Prometheus Node Exporter。

• Job 负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个 Pod 成功结束。
• Cron Job管理基于时间Job，即：在给定时间点只运行一次，周期性地在给定时间点运行。

StatefullSet

• StatefullSet 是为了解决有状态服务的问题（对应Deployments 和 ReplicaSets 是为无状态服务而设计），其应用场景包括：

• 稳定的持久化存储，即Pod重新调度后还是能访问的相同持久化数据，基于PVC来实现。
• 稳定的网络标志，及Pod重新调度后其 PodName 和 HostName 不变，基于Headlesss Service（即没有 Cluster IP 的 Service）来实现。
• 有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行（即从 0 到 N-1,在下一个Pod运行之前所有之前的Pod必须都是Running 和 Ready 状态），基于 init containers 来实现。
• 有序收缩，有序删除（即从N-1 到 0）。

Volume

• 容器宕机，volume数据不会消失，一直存在。
• pod宕机，volume就会消失，因此 volume 数据卷不能用来挂载有状态服务数据。