HCIP学习笔记-云原生技术-7

云原生的概念与背景

1.1 背景 - 企业IT数字化转型的“三阶段两转变”

• 服务器阶段 : 其特点是以硬件设备为中心，业务应用随不同厂商设备、操作系统虚拟化软件的差异化进行定制;设备的安装、调试，应用的部署、运维基本靠人力完成，自动化程度低，缺乏统一的设备和应用管理能力。后期随着虚拟化软件的出现,资源的利用率、扩缩容器的灵活性方面得到一定的提升，但并未从根本上解决基础设施与软件割裂、运维复杂的难题。
• 云化阶段: 传统模式下分布离散的设备，被统一起来，实现了备类资源如计算、存储网络的池化，通过统一的虚拟化软件平台，为上层业务软件提供统一的资源管理接口实现资源管理能力的自动化，屏蔽一部分基础设施的差异，使得应用的通用性增强,但因为虚拟化软件平台差异化较大，尤其是各厂商的一些商业化增强，无法在厂商间进行能力共享，应用还是无法以完全标准化的模式构建，应用部署还是以资源为中心
• 云原生阶段:在这”阶段，企业的关注点从以资源为中心转移到以应用为中心，包括应用敏捷交付、快速弹性、平滑迁移、无损容灾等。因此，企业开始考虑如何将基础设施与业务平台融合，为业务应用提供标准的运行、监控、治理平台，并将业务的通用能力下沉到平台侧，更好的帮助企业实现应用的自动化。

1.2 什么是云原生

• 2015年云原生基金会CNCF成立，标志着云原生从技术理念转化为开源实现。CloudNative Computing Foundation，由Google、华为等多家企业联合创建于2015年7月21日。华为云是云原生基金会7CNCF)的亚洲唯一创始会员，国内唯一白金会员。
• 云原生计算基金会(CNCF)致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。
• CNCF 致力于通过培养和维持一个开源、供应商中立的项目生态系统来推动云原生技术的广泛采用，进而实现让云原生无处不在的愿景。CNCF对云原生的定义让云原生的概念进一步具体化，从而让云原生更容易被各行业理解，为云原生在全行业广泛应用奠定了基础。过去几年中，云原生关键技术正在被广泛采纳，CNCF调查报告显示超过8 成的用户已经或计划使用微服务架构进行业务开发部署等，这使得用户对云原生技术的认知和使用进入新的阶段技术生态也在快速的更迭。

1.3 云原生发展

• 云原生开源项目从基础的容器引擎出发，不断扩展应用领域，对边缘、异构等各类场景的适配能力不断深入。从早期开源的容器引擎项目Docker，到实现容器高效编排的Kubernetes、Swarm、Mesos，再到为了更好的解决微服务治理的难题，基于Service Mesh技术推出的Istio，以及针对边缘场景推出的KubeEdge、K3s (一个轻量级Kubernetes发行版)、面向高性能异构计算场景的Volcano等项目，无一不成为加速云原生与行业融合、推动各行业创新的助推器
• 2020年，中国信息通信研究院基于对云原生的深入分析和全面调研，结合国内云原生产业发展现状和趋势，编写了《2020年云原生发展白皮书》。2020年华为云第一次向业界提出云原生2.0的概念，并希望通过云原生2.0让每个企业都变成“新云原生企业”

1.4 云原生2.0

• 企业数字化转型初期，主要是将业务从线下搬迁上云，在这一阶段企业主要是的把业务简单部署和运行在云上，可以称之为ON CLOUD。这种形态下，通过资源池云化,解决了IDC 时代运维、部署、扩容的难题，但传统应用单体架构厚重、烟囱式架构等带来的一系列应用层面的问题并没有得到有效解决，云对业务的价值主要还停留在资源供给的阶段，无法充分发挥出云的价值。
• 云原生1.0时期，云原生技术集中在基础设施层，单体架构，以资源为中心，支持的应用生态比较单一，主要是在互联网行业得以应用。
• 随着企业数字化转型的深入，企业需要充分享受云计算带来的红利，需要让业务能力生于云、长于云，由现在的ON CLOUD 进阶到IN CLOUD，同时基于云构建的新生能力与既有能力有机协同、立而不破。生于云是指基于云原生的技术、架构和服务来构建企业应用，长于云是指充分利用云的优势来助力企业应用和业务发展，将企业的数字化建设、业务智能升级带入新阶段，我们称之为云原生2.0 时代
• 云原生2.0，企业云化从“ON Cloud”走向“IN Cloud”，生于云、长于云且立而不破企业新生能力基于云原生构建，使其生于云，应用、数据和AI的全生命周期云上完成使其长于云;同时，既有能力通过立而不破的方式继承下来，并与新生能力有机协同智能升级新阶段，赋能“新云原生企业”。云原生2.0是企业
• 智能升级的新阶段，企业云化从“ON Cloud”走向“IN Cloud”，成为”新云原生企业“。新生能力与既有能力立而不破、有机协同，实现资源高效、应用敏捷、业务智能，安全可信。

1.5 云原生2.0的优势

• 在云原生2.0时代:
  • 云原生技术要从以资源为中心转向以应用为中心，云原生基础设施要能感知应用特征，而应用能更智能、更高效的使用云原生基础设施
  • 基于云原生多云架构，支持云原生应用的分布式化趋势，可以支持端边云协同多云协同，支持政企的复杂全场景应用。
  • 云原生2.0是-个开放系统，新生能力和既有能力有机协同、立而不破
  • 云原生2.0是一个全栈能力，云原生能力扩展到应用、大数据、数据库、AI等全栈技术。

1.6 云原生2.0十大架构模式

1.7 华为云云原生2.0架构全景

• 云原生硬件层: 以追求云算力极致性价比为目标，通过引入云基础设施服务感知的硬件PCI板卡(SDI/擎天卸载)、自研通用CPU (鹏)、异构NPU (异腾)，经一系列面向同构及异构计算的硬件卸载及深度软硬协同，打造与容器、虚拟机运行时配合的最极致性价比的算力平台。
• 云原生OS: 除标准操作系统功能外，云上下文内这一层的职责在于“资源大分小”将物理服务器资源切分为多个虚机、多个容器，通过Euler OS，从而为上层的智能资源调度及柔性计算提供支撑，并通过硬件直通最小化存储及网络虚拟化性能开销.
• 云原生弹性资源层: 云上下文内这一层的职责是小聚大的过程，比如面向云原生计算特别是K8S容器集群及其扩展任务，以及瑶光智能调度系统，拉通云边、跨Reqion的全域调度，云原生的网络虚拟化功能及，云原生的分布式存储及其高级存储如容灾高可靠等。
• 云原生应用与数据使能层: 涵盖了云原生分布式中间件、区块链、云原生边缘,云安全使能，云原生数据库，以及云原生大数据，AI ModelArts普惠AI开发平台，云原生视频，以及云原生IOT物联网。
• 云原生应用生命周期: 包括DevSecOPS流水线，云原生的服务治理与编排，、面向租户自己部署业务的CMDB，监控与运维服务等。
• 云原生多租框架:面向云服务多租认证与权限管理(云服务及云资源能力接入的身份认证，以及对云服务对象实例的访问权限管理)，云原生的运营与计费，云服务API能力开放(云服务消费界面入口)，以及云原生Console(云服务消费界面入口)等

开源容器技术介绍

2.1 什么是容器技术

• Docker是第一个使容器能在不同机器之间移植的系统。它不仅简化了打包应用的流程也简化了打包应用的库和依赖，甚至整个操作系统的文件系统能被打包成一个简单的可移植的包，这个包可以被用来在任何其他运行Docker的机器上使用容器技术在业界的定义是以Docker为代表的容器引擎技术和以K8S为标准的容器编排技术，很多其他容器技术都遵循或者兼容OCI标准，如Kata安全容器。
• 相比于使用虚拟机，容器有如下优点:
  • 更高效的利用系统资源:由于容器不需要进行硬件虚拟以及运行完整操作系统等开销，容器对系统资源的利用率更高。包括应用执行速度、内存损耗等。
  • 更快速的启动时间:传统的虚拟机技术启动应用服务往往需要数分钟，而Docker容器应用，由于直接运行于宿主内核，无需启动完整的操作系统，因此可以做到秒级:甚至毫秒级的启动时间
  • 一致的运行环境:开发过程中一个常见的问题是环境一致性问题。由于开发环境、测试环境、生产环境不一致，导致有些问题并未在开发过程中被发现。而Docker的镜像提供了除内核外完整的运行时环境，确保了应用运行环境一致性
  • 更轻松的迁移:由于Doker确保了执行环境的一致性，使得应用的迁移更加容易。并可以在很多平台上运行，无论是物理机、虚拟机，其运行结果是一致的
  • 更轻松的维护和扩展:Docker使用的分层存储以及镜像的技术，使得应用重复部分的复用更为容易，也使得应用的维护更新更加简单。此外，Docker团队同各个开源项目团队一起维护了大批高质量的官方镜像，既可以直接在生产环境使用，又可以作为基础进一步定制，大大的降低了应用服务的镜像制作成本。

2.2 关键技术介绍

• Docker所应用的几个关键技术都不是docker发明的，而是Linux早就成熟的技术Docker将这几个技术整合，形成了革命性的成果。
• 其中Namespace负责运行环境的隔离，即每个容器都是一个独立进程，通过namespace技术进行隔离
• Cqroup是负责运行资源的隔离或者说独占，可以为每个容器指定资源数量，互相不侵占。每个容器互相不可见，包括进程隔离、网络隔离、文件隔离。
• Union filesystem是解决应用运行的小型化统一标准，容器镜像提供了容器运行的基础，但容器镜像并不等于容器。容器镜像是通过存储驱动技术管理的。系列分层的只读文件，而当容器镜像运行为容器时，就会在镜像的最上层添加一个可写的层，也就是容器层，所有对于运行时容器的修改其实都是对这个容器读写层的修改，所有对容器的变化，比如写新的文件，修改已有文件，都只会作用在这个容器层之中。
• 因为容器是操作系统内核自带的能力，所以不需要再在这基础上运行虚拟化和新的内核，本质上是进程级别的隔离，因此更加轻量级，部署运维和性能的损耗也更小。同时也因为容器是应用和运行环境一起打包的，所以可移植性好，标准化程度也高，为应用的大规模灵活扩展和管理提供了良好的基础。
• Dockerd是docker架构中一个常驻在后台的系统进程，称为docker daemon
• Containerd是dockerd和runc之间的一个中间交流组件，docker对容器的管理和操作基本都是通过containerd完成的。
• Containerd-shim是一个真实运行容器的载体，每启动一个容器都会起一个新的containerd-shim的一个进程。
• RunC是一个命令行工具，用来运行OCI标准格式的应用

2.3 Kata Containers介绍

• Kata容器是Intel、华为、红帽等公司发起的开源容器项目，提供直接在裸机上运行容器管理工具并实现工作负载强安全隔离的能力，将虚拟机的安全优势与容器的速度和可管理性完美统一。

2.4 Docker容器典型使用流程

2.5 Kubernetes

• Kubernetes这个单词来自于希腊语，含义是舵手或领航员。因为K到s有8个字母，也简称k8s。Kubernetes是谷歌贡献给开源社区的，是谷歌根据自己内部容器borg(布谷鸟)，在去除自己业务属性后开源的一个产品。Kubernetes是业界公认的容器编排领域的事实标准，几乎所有的公有云厂商的容器技术都是基于kubernetes实现的。
• K8s的标准架构中是以集群为整体的，一个集群就是一套完整的K8s产品，大多数企业K8s的标准架构中是以集群为整体的，会在其上封装管理面进行集群级别的管理。
• 对应用开发者而言，可以把Kubernetes看成一个集群操作系统。Kubernetes提供服务发现、伸缩、负载均衡、自愈甚至选举等功能，让开发者从基础设施相关配置等解脱出来
• 基于它的技术特点，具有如下的优势:由定义的应用状态自动部署、重启、迁移、伸缩，插件机制使K8S兼容各类基础设施(公有云、私有云);灵活的隔离机制能够快速为不同团队构建运行环境。
• 集群中会有一个主控节点Master，负责管理整个容器集群，一般由于其中使用的etcd高可用场景下Master的数量至少是3个。集群中会有很多的业务节点Node，负责运行容器应用。Master会在每个Node上安装kubelet作为其管理Node的Agent。

2.5.1 Kubernetes集群架构介绍

• Master节点:
  • API Server: 各组件互相通讯的中转站，接受外部请求，并将信息写到ETCD中
  • Controller Manager:执行集群级功能，例如复制组件，跟踪Node节点，处理节点故障等等。
  • Scheduler: 负责应用调度的组件，根据各种条件(如可用的资源、节点的亲和性等 )将容器调度到Node上运行
  • Etcd: 一个分布式数据存储组件，用于保存集群所有的网络配置和对象的状态信息。
• Node节点:
  • Kubelet:kubelet主要负责同Container Runtime打交道，并与API Server交互管理节点上的容器。通过cAdvisor对Node机器上的资源及容器进行实时监控和性能数据采集
  • Kube-proxy:应用组件间的访问代理，解决节点上应用的访问问题
  • Container Runtime:负责运行容器的软件，例如 Docker、containerd、CRI-O以及Kubernetes CRI等。
• Kubectl是Kubernetes集群的命令行工具，可以将kubectl安装在任意一台机器上，通过kubectl命令操作Kubernetes集群。
• 用户使用K8s时通过Master上的apiserver，调用声明式的接口里定义所需要的应用服务等各类资源对象，master的控制器和调度器会根据用户的定义，在Node中进行创建，并且时刻监控其状态，保证一直符合用户的定义。在Node上容器应用，通过kube-proxy提供统”访问能力。

2.5.2 资源管理-Pod

• Kubernetes编排的最小单位并不是容器，是一个叫做Pod的东西。Pod翻译成中文就是豌豆英的意思，在一个豌豆英里可以有很多豌豆，这些豌豆就是一个个的容器实例。
• 很多时候需要使用容器承载微服务(什么是微服务呢，简单来说就是小而单一的服务)。在做微服务设计的时候，一般推荐一个应用一个进程，如果承载体为容器的话那就是一个容器一个进程。但是现实是很多时候为了管理微服务我们需要安装相关的服务监控软件或数据读取软件。也就意味着我们需要在一个容器中安装多个软件，也就是多个进程。这样就破坏了我们刚刚说的一个容器一个进程的原则。为了完成符合微服务的设计原则，设计了Pod这个概念。一般一个Pod中会有多个容器，一个服务容器(用于提供服务)，多个辅助容器(用于完成服务容器的监控或数据的管理)打个比方我们有个Pod，Pod内有三个容器，分别是: web容器、监控容器和日志读取容器。首先web容器中只运行web软件，对外暴露的端口为80监控容器中运行web容器的监控软件，此监控软件只需要监控127.0.0.1:80即可完成web服务的监控。因为Pod内的容器共享IP地址。日志读取容器，只需要将相关路径下的文件读取上报给对应的日志管理平台即可，因为ROD内的容器共享数据存储。
• 容器运行时接口( Container Runtime Interface)简称 CRI。CRI 中定义了容器和镜像的服务的接口，因为容器运行时与镜像的生命周期是彼此隔离的，因此需要定义两个服务。CRI是 kubelet 和容器运行时之间通信的主要协议。

2.5.3 资源探测

• 探针类型:
  • 存活探针: 指示容器是否正在运行。如果存活态探测失败，则kubelet会杀掉容器，并且容器将根据其重启策略决定。
  • 就绪探针:容器是否准备好为请求提供服务。如果就绪态探测失败，端点控制器将从与Pod匹配的所有服务的端点列表中删除该Pod的IP地址。
  • 启动探针:容器中的应用是否已经启动。如果提供了启动探针，则其他探针都会被禁用，直到此探针探测成功为止。如果启动探测失败，kubelet将杀死容器而容器依其重启策略进行重启
• DaemonSet的一些典型用法
  • 在每个节点上运行集群守护进程;
  • 在每个节点上运行日志收集守护进程:
  • 在每个节点上运行监控守护进程
• Kubernetes支持节点和Pod两个层级的亲和与反亲和。通过配置亲和与反亲和规则.可以允许用户指定硬性限制或者偏好，例如将前台Pod和后台Pod部署在一起、某类应用部署到某些特定的节点、不同应用部署到不同的节点等等。

2.5.4 资源调度

• Kubernetes提供了Controller(控制器)来管理Pod，Controller可以创建和管理多个Pod，提供副本管理、滚动升级和自愈能力。
• Deployment:目前最常用的控制器就是Deployment，创建Deployment时也会自动创建ReplicaSet。Deployment可以管理一个或多个RS,w并且通过RS来管理Pod。
• Deployment控制器下的Pod都有个共同特点，那就是每个Pod除了名称和IP地址不同其余完全相同。需要的时候，Deployment可以通过Pod模板创建新的Pod;不需要的时候，Deployment就可以删除任意一个Pod。通常情况下: Pod中包含一个容器，或关系特别紧密的几个容器。一个ReplicaSet中包含一个或多个相同的Bod。Deployment中包含一个或几个不同的ReplicaSet。
• Kubernetes提供了StatefulSet来解决这个问题，其具体如下:StatefulSet给每个Pod提供固定名称，Pod名称增加从0-N的固定后缀，Pod重新调度后Pod名称和HostName不变。StatefulSet通过Headless Service给每个Pod提供固定的访问域名Service的概念会在后面章节中详细介绍。StatefulSet通过创建固定标识的PVC保证hw35802903Pod重新调度后还是能访问到相同的持久化数据。
• Job和CronJob是负责批量处理短暂的一次性任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束。
  • Job:是Kubernetes用来控制批处理型任务的资源对象。批处理业务与长期伺服业务(Deployment、Statefulset)的主要区别是批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。Job管理的Pod根据用户的设置把任务成功完成就自动退出。
  • CronJob: 是基于时间的Job，就类似于Linux系统的crontab文件中的一行，在指定的时间周期运行指定的Job。

2.5.5 资源配置

• Secret与ConfigMap相同，是以键值对形式保存数据，所不同的是在创建时，Secret的Value必须使用Base64编码。
• Secret:
  • 在创建、查看和编辑Pod的流程中Secret暴露风险较小。
  • 系统会对Secret对象采取额外的预防措施，例如避免将其写入磁盘中可能的位置。
  • 只有Pod请求的Secret在其容器中才是可见的，一个Pod不能访问另一个Pod的Secret。

2.5.6 Kubernetes网络

• 不同节点间的网桥连接有很多种方式，这跟具体实现相关。但集群要求Pod的地址唯一，所以跨节点的网桥通常使用不同的地址段，以防止Pod的IP地址重复。
• Pod内容器间通信: Pod内各容器共享同一网络名称空间，该名称空间通常由基础架构容器所提供。所有运行于同一Pod内的容器与同一主机上的多个进程类似，彼此之间可通过环回接口完成交互。不同Pod之间不存在端口冲突的问题，因为每个Pod都有自己的IP地址。
• 集群中的任何其他Pod和节点都可以通过IP直接与Pod通信，这种通信不需要借助任何的网络地址转换、隧道或代理技术。Pod内部和外部使用的是同eet个iP，这也意味着标准的命名服务和发现机制，比如DNS可以直接使用。此类通信模型中的通信需求也是K8s的各网络插件需要解决的问题，它们的实现方式有叠加网络模型和路由网络模型等，流行的解决方案有十数种之多，例如flannel等。
• Pod间通信: Pod间可以直接通过IP地址通信，但前提是Pod得知道对方的IP。在集群中，Pod可能会频繁的销毁和创建，也就是说Pod的IP不是固定的。为了解决Pod的IF不是固定的问题，sefice提供了访问Pod的抽象层。无论后端的Pod如何变化，Service都作为稳定的前端对外提供服务。同时，Service还提供了高可用和负载均衡功能，Service负责将请求转发给正确的Pod。
• Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的容器都具有全集群唯一的虚拟IP地址。
• Calico相较于Flannel的简单而言，Calico以其性能、灵活性而闻名。Calico的功能更为全面，不仅提供主机和pod之间的网络连接，还涉及网络安全和管理。

2.5.7 Kubernetes网络- Service

• Pod创建完成后，直接访问Pod会有如下几个问题:
  • Pod会随时被Deployment这样的控制器删除重建，那访问Pod的结果就会变得不可预知。
  • Pod的IP地址是在Pod启动后才被分配，在启动前并不知道Pod的IP地址
  • 应用往往都是由多个运行相同镜像的一组Pod组成，逐个访问Pod也变得不现实
• RC、RS和Deployment只是保证了支撑服务的微服务Pod的数量，但是没有解决如何访问这些服务的问题。一个Pod只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的IP启动一个新的Pod，因此不能以确定的IP和端口号提供服务。要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作，是针对客户端访问的服务，找到对应的的后端服务实例。在K8s集群中，客户端需要访问的服务就是 Service对象。每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟 IP 访问一个服务。
• Kubernetes Service定义了这样一种抽象:逻辑上的一组Pod，一种可以访问它们的策略 - 通常称为微服务。这一组Pod能够被Service访问到，通常是通过 LabelSelector实现的。
• Service的实现类型主要有
  • ClusterIP:提供一个集群内部的虚拟IP地址以供Pod访问(默认模式)。
  • NodePort: 在Node上打开go个端口以供外部访问
  • LoadBalancer:通过外部的负载均衡器来访问。

2.5.8 Kubernetes网络- Ingress

• lngress可以提供负载均衡、SSL 终结和基于名称的虚拟托管。Ingress公开了从集群外部到集群内服务的HTTP和HTTPS路由。流量路由由Ingress资源上定义的规则控制。
• 要使用Ingress功能，必须在Kubernetes集群上安装Ingresscontroller。IngressController有很多种实现，最常见的就是Kubernetes官方维护的NGINX IngressController;不同厂商通常有自己的实现，例如华为云CCE使用华为云弹性负载均衡服务ELB实现Ingress的七层负载均衡。

2.5.9 持久化存储

• Volume的生命周期与挂载它的Pod相同，但Volume里面的文件可能在Volume消失后仍然存在，这取决于Volume的类型。Pod中的所有容器都可以访问Volume，但必须要挂载，且可以挂载到容器中任何目录
  • PV: 是持久化存储卷，主要定义的是一个持久化存储在宿主机上的目录，比如一个NFS的挂载目录
  • PVC:是Pod所希望使用的持久化存储的属性，比如，Volume存储的大小、可读写权限等等。
• PV和PVC方法虽然能实现屏蔽底层存储，但是PV创建比较复杂，通常都是由集群管理员管理。Kubernetes解决这个问题的方法是提供动态配置PV的方法，可以自动创PV。管理员可以部署PV配置器( provisioner)，然后定义对应的StorageClass，这样开发者在创建PVC的时候就可以选择需要创建存储的类型，PVC会把StorageClass传递给PV provisioner，由provisioner自动创建PV。
• StorageClass描述了集群中的存储类型“分类”，在创建PVC/PV均需要指定StorageClass.
• Kubernetes管理员设置好网络存储的类型，提供对应的PV描述符配置到Kubernetes,使用者需要存储的时候只需要创建PVC，然后在Pod中使用Volume关联PVC，即可让Pod使用到存储资源。

2.6 本地K8S集群上云迁移流程简介

• 集群迁移大致包含如下6个步骤:
  • 目标集群资源规划。详细了解CCE集群与自建集群间的差异，参考目标集群资源规划中的关键性能参数，:按需进行资源规划，建议尽量保持迁移后集群与原集群中性能配置相对一致。
  • 集群外资源迁移。若需对集群外的相关资源进行迁移，华为云提供了对应的迁移解决方案。包括容器镜像迁移和数据库与存储迁移
  • 迁移工具安装。完成集群外资源迁移后，可通过迁移工具在原集群和目标集群内分别进行应用配置的备份和还原。
  • 集群内资源迁移。可以使用开源灾备软件Velero等工具，将原集群内资源备份至对象存储中，并在目标集群中进行恢复。
    • 原集群应用备份:当用户执行备份时，首先通过Velero工具在原集群中创建Backup对象，并查询集群相关的数据和资源进行备份，并将数据打包上传至s3协议兼容的对象存储中，各类集群资源将以JSON格式文件进行存储。
    • 目标集群应用恢复: 在目标集群中进行还原时，Velero将指定之前存储备份数据的临时对象桶，并把备份的数据下载至新集群，再根据JSON文件对资源进行重新部署。0335802903
  • 资源更新适配。迁移后的集群资源可能存在无法部署的问题，需要对出现错误的资源进行更新适配，可能发生的适配问题主要包括如下几类:镜像更新适配访问服务更新适配、StorageClass更新适配、数据库更新适配
  • 其余工作。集群资源正常部署后，需对迁移后应用内的功能进行验证，并将业务流量切换至新集群。最后确定所有服务正常运行后，可将原集群下线。

华为云容器服务介绍

3.1 云容器引擎CCE

• 云容器引擎深度整合了华为云高性能的计算(ECS/BMS )、网络(VPC/EIP/ELB )存储( EVS/OBS/SFS)等服务，并支持GPU、ARM等异构计算架构，支持多可用区(Available zone，简称AZ)、多区域( Region)容灾等技术构建高可用Kubernetes集群，并提供高性能可伸缩的容器应用管理能力，简化集群的搭建和扩容等工作。

3.2 CCE集群架构及特点

• CCE团队是国内最早投入Kubernetes社区的团队，是容器开源社区主要贡献者和容器生态领导者。CCE服务是全国最早的Kubernetes商业产品，是全球首批通过CNCF-致性认证的产品。CCE的主要价值在于开放和开源的生态、增强的商业化特性、灵活兼容易购基础设施。
• Volcano: 原生K8S对于批量计算业务支持较弱，volcano在批量计算领域做了两方面增强，一方面是做了高级作业管理: 比如排队，优先级，驱逐，回填，防饿死等等能力，另一方面做了智能调度能力，比如有拓扑感知的亲和性调度、动态driver-executor比例调整等能力，同时也在调度上支持Gang Scheduling、PS-Worker等多种调度及分布式框架
• 用户可以通过CCE控制台、Kubectl命令行、Kubernetes API使用云容器引擎服务

3.3 CCE节点

• 节点是容器集群组成的基本元素，在云容器引擎CCE中，主要采用高性能的弹性云服务器ECS或裸金属服务器BMS作为节点来构建高可用的Kubernetes集群。
• 安全容器的概念主要与普通容器进行比较的。和普通容器相比，它最主要的区别是每个容器(准确地说是Pod )都运行在一个单独的微型虚拟机中，拥有独立的操作系统内核，以及虚拟化层的安全隔离。因为云容器引擎CCE的容器安全隔离比独立拥有私有Kubernetes集群有更严格的要求。通过安全容器，不同容器之间的内核、计算资源网络都是隔离开的，保护了Pod的资源和数据不被其他Pod抢占和窃取。
• 工作负载是在Kubernetes上运行的应用程序。无论工作负载是单个组件还是协同工作的多个组件，都可以在Kubernetes上的一组Pod中运行它。
• CCE提供基于Kubernetes原生类型的容器部署和管理能力，支持容器工作负载部署配置、监控、扩容、升级、御载、服务发现及负载均衡等生命周期管理。

3.4 集群网络构成

• 网段规划建议:
  • 网段不能重叠，否则会导致冲突。且集群所在VPC下所有子网(包括扩展网段0子网)不能和容器网段、服务网段冲突。
  • 保证每个网段有足够的IP地址可用。节点网段的IP地址要与集群规模相匹配否则会因为IP地址不足导致无法创建节点。容器网段的IP地址要与业务规模相匹配，否则会因为IP地址不足导致无法创建Pod。
• 云原生网络2.0模型下，由于容器网段与节点网段共同使用VPC下的网络地址，建议容器子网与节点子网不要使用同58个子网，否则容易出现IP资源不足导致容器或节点创建失败的情况。
• CCE支持的容器网络模型有:容器隧道网络、VPC网络、云原生2.0网络
• 容器隧道网络在节点网络基础上通过隧道封装另构建的独立于节点网络平面的容器网络平面，CCE集群容器隧道网络使用的封装协议为VXLAN;0猎端虚拟交换机采用的是openvswitch，VXLAN是将以太网报文封装成UDP报文进行隧道传输。容器隧道网络具有付出少量隧道封装性能损耗，即可获得通用性强、互通性强等优势，可以满足大多数性能要求不高的场景。

3.5 云原生网络2.0

• 优点: 容器网络直接使用的VPC，网络问题易排查、性能最高。支持VPC内的外部网络与容器IP直通。可直接利用VPC提供的负载均衡、安全组、弹性公网IP等能力。
• 缺点:由于容器网络直接使用的VPC，会消耗VPC的地址空间，创建集群前需要合理规划好容器网段。
• 仅CCE Turbo集群支持使用云原生网络2.0。

3.6 CCE容器存储

• 云容器引擎CCE的容器存储功能基于Kubernetes存储系统，并深度融合云存储服务完全兼容Kubernetes原生的存储服务，例如EmptyDir、HostPath、Secret、ConfigMap等存储。CCE基于Kubernetes社区容器存储接口( csl，即ContainerStorage Interface)实现了云存储服务接入能力，旨在能为容器编排引擎和存储系统间建立一套标准的存储调用接口，通过该接口能为容器编排引擎提供存储服务
• CSI( Container Storage Interface ): 容器存储接口，提供存储资源，通过CSI接口Kubernetes可以支持各种类型的存储。例如华为云CCE就可以方便的对接华为云块存储(EVS )、文件存储(SFS)和对象存储( OBS)。
• CCE集群中的CSI容器存储插件名为Everest，Everest是一个云原生容器存储系统，基于CSI(即Container Storaqe Interface)为Kubernetes集群对接华为云云硬盘服务EVS、对象存储服务OBS、弹性文件服务SFS、极速文件存储SFS Turbo等存储服务的能力。该插件为系统资源插件，kubernetes1.15及以上版本的集群在创建时默认安装

3.7 CCE和CCE Turbo特点对比

3.8 自建Kubernetes集群跟云容器引擎对比

3.9 容器镜像服务SWR

• 简单易用:
  • 无需自行搭建和运维，即可快速推送拉取容器镜像
  • 容器镜像服务的管理控制台简单易用，支持镜像的全生命周期管理
• 安全可靠:
  • 容器镜像服务遵循HTTPS协议保障镜像安全传输，提供帐号间、帐号内多种安全隔离机制，确保用户数据访问的安全
  • 容器镜像服务依托华为专业存储服务，确保镜像存储更可靠
• 镜像加速
  • 容器镜像服务通过华为自主专利的P2P镜像下载加速技术，使CCE集群下载时在确保高并发下能获得更快的下载速度。
  • 容器镜像服务智能调度全球构建节点，根据所使用的镜像地址自动分配至最近的主机节点进行构建?可以拉取国外镜像，根据负载自动分配到空闲节点，可以加速镜像的获取效率。

3.10 CCE适用场景

• 根据客户和伙伴的实践，根据CCE的基本功能，以如下四个场景为例:
  • 传统T架构的渐进式转型。最传统的架构一般是单一的重型应用，把单一的重型应用解耦拆分为多个轻量的模块，每个模块使用适配的K8S资源形态承载，如无状态应用使用Deployment，有状态使用StatefulSet等，使每个模块升级伸缩更加灵活，轻松应对市场变化。
  • 提升业务的上线效率。容器镜像贯穿从开发到测试到运维的各环节，保证业务运行环境一致性，业务开箱即用，快速上线
  • 应对业务负荷波动明显的场景。容器的快速自动弹性伸缩保证业务在突发浪涌的情况下仍旧性能稳定，系统秒级自动弹性扩容，快速响应并发高峰。
  • 节省资源降低成本。由于容器能在虚拟机上更细粒度地划分资源，应用能更充分使用资源，从而提高资源利用率

3.11 云容器实例CCI

• Serverless是一种架构理念，是指不用创建和管理服务器、不用担心服务器的运行状态(服务器是否在工作等)，只需动态申请应用需要的资源，把服务器留给专门的维护人员管理和维护，进而专注于应用开发，提升应用开发效率、节约企业IT成本。
• CCE提供的是半托管式的集群，因为还需要对集群进行管理，华为云同时提供了另一类的全托管式的集群华为云云容器实例CCI。
• 产品功能:
  • 一站式容器生命周期管理: 使用云容器实例，无需创建和管理服务器集群即可直接运行容器
  • 支持多种类型计算资源，云容器实例提供了多种类型计算资源运行容器，包括0CPU，GPU、Ascend芯片(华为自研AI芯片)
  • 支持多种网络访问方式:云容器实例提供了丰富的网络访问方式，支持四层七层负载均衡，满足不同场景下的访问诉求。
  • 支持多种持久化存储卷:云容器实例支持将数据存储在华为云的云存储上，当前支持的云存储包括:EVS、SFS、OBS等。
  • 支持极速弹性扩缩容:云容器实例支持用户自定义弹性伸缩策略，并可以自由组合多种弹性策略以应对业务高峰期的突发流量浪涌。
  • 全方位容器状态监控: 云容器实例支持监控容器运行的资源使用率，包括CPU、内存、GPU和显存的使用率等。
  • 支持专属容器实例:云容器实例提供专属容器实例，基于高性能物理服务器运行Kata容器，实现虚机级别安全隔离，同时性能无损耗。

3.12 CCI产品架构

• 用户使用CCI时，不需要太关注底层硬件及资源利用率，只需要专注自己的业务，同时CCI提供按需按秒计费，方便客户使用。
• 专属容器实例租户独占物理服务器，支持多部门业务隔离，其基于高性能物理服务器运行Kata容器，实现虚机级别安全隔离，同时性能无损耗。服务器的升级和维护工作nWc由华为云承担，用户只需要关注自身业务。

3.13 高安全

• 云容器实例同时具备容器级别的启动速度和虚拟机级别的安全隔离能力，提供更好的容器体验。
  • 原生支持Kata Container。
  • 基于Kata的内核虚拟化技术，提供全面的安全隔离与防护
  • 自有硬件虚拟化加速技术，获得更高性能的安全容器

3.14 极速弹性

• 比如当前主流的大数据、AI训练和推理等应用(如Tensorflow、Caffe )均采用容器化方式运行，并需要大量GPU、高性能网络和存储等硬件加速能力，并且都是任务型计算，需要快速申请大量资源，提供高性能计算、网络和高IO存储，满足密集计算nw.33的诉求，计算任务完成后快速释放。按需秒级计费: 根据实际使用的资源数量，
• 按需按秒计费，避免业务不活跃时段的费用开销，降低用户成本。
• Volcano是一个基于Kubernetes的批处理平台，提供了机器学习、深度学习、生物信息学、基因组学及其他大数据应用所需要而Kubernetes当前缺失的一系列特性。Volcano提供了高性能任务调度引擎、高性能异构芯片管理、高性能任务运行管理等通用计算能力，通过接入AI、大数据、基因、渲染等诸多行业计算框架服务终端用户(目前Volcano项目已经在Github开源)

3.15 免运维

• 用户无需感知集群和服务器，大幅简化运维工作、降低运维成本

3.16 适用场景

• CCI主要适用于任务型的场景，包括:
  • 基于对异构硬件的支持提供的AI训练推理场景，可以把训练任务托管在CCI。
  • HPC场景，例如基因测序场景
  • 长稳运行环境的突发扩容场景，例如电商秒杀、热点营销等
• 主要优势是随需使用导致的成本降低，全托管导致的免运维，镜像标准化导致的一致和可扩展性。
• 计费模式为按需收费和购买套餐包两种计费模式，费用计算的核时为核数*时间，例如:730核时，可以730核用1小时，也可以730小时用1核。
  • 按需计费模式:以实例为单位，采用按量付费的计费模式，按秒计费，以小时为出账周期
  • 套餐包模式:购买的资源包在有效期内，扣费方式是先扣除已购买的资源包内的额度后，超出部分以按需付费的方式进行结算。用户可重复购买资源包，当存在多个资源包时，优先从过期时间早的资源包中扣除。

3.17 应用编排服务AOS

• 使用应用编排服务，只需要创建一个描述自己所需的云资源和应用的模板，在模板中自行定义云资源和应用的依赖关系 引用关系等，AOS将根据模板来创建和配置这些云资源和应用。例如创建弹性云服务器(包括虚拟私有云和子网)，只需要编写模板定义弹性云服务器、虚拟私有云和子网，并定义弹性云服务器与虚拟私有云、子网的依赖关系，子网与虚拟私有云的依赖关系，然后通过AOS使用该模板创建堆栈，虚拟私有云、子网和弹性云服务器就创建成功了。
• 产品功能:
  • 支持自动化编排资源: AOS提供自动化的编排能力，支持编排华为云主流云服务，具体请参见支持编排的云服务。AOS还提供资源规划、应用设计、部署、变更等生命周期管理等相关服务，通过自动化降低运维成本。
  • 支持应用与云服务资源混合编排:可通过标准语言(YAML/JSON)统描述所需基础资源、应用系统、应用上层配套服务及三者之间的关系。根据统一描述可一键式按照定义的依赖顺序，自动完成资源开通、应用部署、应用加载。对于部署的资源和应用，可以统一的进行管理。
  • 提供丰富的应用模板:AOS模板市场提供丰富的免费资源，包括基础资源模板服务组合模板、行业场景模板等，覆盖热点应用场景。可以直接使用公共模板一键创建，完成全云化业务秒级部署。

3.18 多云容器平台MCP

• Karmada( Kubernetes Armada)是基于Kubernetes原生API的多集群管理系统。在多云和混合云场景下，Karmada提供可插拔，全自动化管理多集群应用，实现多云集中管理、高可用性、故障恢复和流量调度。
• 统一集群管理:多云容器平台通过集群联邦实现对多个云运营商的集群进行统一管理支持动态集群接入和全局集群监控仪表盘。
• 全局应用管理: 基于多集群与Federation联邦技术，多云容器平台可以实现多个不同区域、不同云的Kubernetes管理，支持统一的全局应用管理，支持基于Kubernetes社区集群联邦标准化接口的跨集群应用的部署、删除、升级等全生命周期管理。
• 跨集群的弹性伸缩能力: 多云容器平台支持跨集群的应用弹性伸缩策略，用以均衡各集群的应用实例分布，实现全局负载均衡。
• 跨集群的服务发现能力:多云容器平台支持创建联邦服务，支持跨集群的服务发现机制，能够基于服务就近访问原则实现业务的区域亲和，降低网络时延
• 标准兼容: 多云容器平台兼容Kubernetes社区最新Federation架构，提供原生Kubernetes API及Karada APl。
• 单集群应用多云化:多云容器平台支持将单集群应用一键式转换为多云应用，将应用实例部署到多云多集群，方便快捷的完成业务多云容灾、多云业务流量分担等场景。
• 跨集群应用克隆和迁移能力: 多云容器平台支持将某个集群的应用克隆或者迁移到其他集群，可以使用该能力完成跨云跨集群的应用主动迁移，或者跨云跨region的镜像环境复制等场景应用

3.19 云原生服务中心OSC

• 服务发布: 服务提供商上传服务包，验证服务在OSC的生命周期管理以及服务的业务特性，发布成供其它租户订阅的商品。
• 服务订阅:服务中心包含华为自研服务、生态伙伴发布的服务以及开源服务，所有服务都支持用户订阅，用户订阅成功才能部署实例。
• 服务退订:用户可以随时退订服务，退订服务时系统会自动删除已部署的服务及实例
• 私有服务上传: 用户按照Helm、Operator Framework或者OSC服务规范开发的服务可上传到OSC作为私有服务进行管理。
• 服务升级:当服务提供商针对某服务发布了新版本后，订阅此服务的用户会收到升级提示，用户可选择是否将服务升级到最新版本。
• 实例部署: 用户在订阅服务后可部署实例，用户可根据服务能力指定部署的region,hw3580hw3580容器集群以及运行参数。
• 实例运维:提供实例的运维视图，可以查看实例的监控、日志等运维信息，如果需要深入的数据分析，可以从运维视图跳转到对应的云服务。
• 实例更新:用户可以修改实例的运行配置。
• 实例删除:当实例承载的业务生命周期结束，用户可以删除实例回收相关资源.
• 服务发布:支持服务提供商在OSC管理商品的服务包。服务提供商先在OSC上传服务包，格式校验和漏洞扫描都通过以后，才能正式发布商品。当服务首次发布成功后后续只需要上传服务新版本，新用户订阅服务时订阅的是最新版本。

Serverless概述

4.1 什么是Serverless

• Serverless计算并不意味着我们不再使用服务器来托管和运行代码;这也不意味着不再需要运维工程师。它指的是serverless计算的消费者不再需要花费时间和资源来进行服务器配置，维护，更新，扩展和容量规划。所有这些任务和功能都由serverless平台处理。因此，开发人员专注于编写应用程序的业务逻辑。运维工程师能够将重点更多的放到关键业务任务上。
• Serverless两和形态:
  • Functions-as-a-Service (FaaS)通常提供事件驱动计算。开发人员使用由事件或HTTP请求触发的function来运行和管理应用程序代码。开发火员将代码的小型单元部署到FaaS，这些代码根据需要作为离散动作执行，无需管理服务器或任何其他底层基础设施即可进行扩展
  • Backend-as-a-Service (BaaS)它是基于API的第三方服务，可替代应用程序中的核心功能子集。因为这些API是作为可以自动扩展和透明操作的服务而提供的,w所以对于开发人员表现为是Serverless。
• 简单来说FaaS负责执行函数/代码，BaaS只以API的方式提供应用依赖的后端服务

4.2 Serverless价值

• Serverless产品或平台为开发人员带来以下好处:
  • 零服务器运维:serverless通过消除维护服务器资源所涉及的开销，显着改变了运行软件应用程序的成本模型。
    • 无需配置，更新和管理服务器基础设施。管理服务器，虚拟机和容器对于公司而言是一项重大费用，其中包括人员，工具，培训和时间。
    • 灵活的可扩展性:Serverless的FaaS或BaaS产品可以即时而精确地扩展以处理每个单独的传入请求。对于开发人员来说，Serverless平台没有“预先计划容量”的概念，也不需要配置“自动缩放”的触发器或规则。
  • 闲置时无计算成本:从消费者的角度来看，Serverless产品的最大好处之一是空闲容量不会产生任何成本。例如，Serverless计算服务不对空闲虚拟机或容器收费:换句话说，当代码没有运行或者没有进行有意义的工作时，不收费。 当然这不包括其他成本，例如有状态存储成本或添加的功能/功能/特性集。
• 通常，当工作负载为以下情况时，推荐采用Serverless: 异步，并发，易于并行化为独立的工作单元。不经常或有零星的需求，在扩展要求方面存在巨大的，不可预测的差异。无状态，短暂的，对瞬间冷启动时间没有重大需求。在业务需求变更方面具有高度动态性，需要加快开发人员的速度。

4.3 华为Serverless服务-FunctionGraph

• 用户使用FunctionGraph时，不需要开通或者预配置计算、存储、网络等服务，由FunctionGraph提供和管理底层计算资源，包括服务器CPU、内存、网络和其他配置资源维护、代码部署、弹性伸缩、负载均衡、安全升级、资源运行情况监控等，用户只需要按照FunctionGraph支持的编程语言提供程序包，上传即可运行。
• 函数支持Node.js、Java、Python、Go、C#等多种运行时语言;支持在线编辑代码OBS文件引入、上传ZIP包、上传JAR包等方式;函数支持SMN、APIG和OBS等多种类型触发器;提供调用函数的监控指标和运行日志的采集和展示，实时的图形化监控指标展示，在线查询日志，方便用户查看函数运行状态和定位问题，函数流是用来编排FunctionGraph函数的工具，可以将多个函数编排成一个协调多个分布式函数任务执行的工作流，统一插件开发和调试(云上云下相一致);HTJP函数专注于优化Web服务场景，用户可以直接发送HTTP请求到URL触发函数执行;用户通过页面函数配置开启调用链，开启后可以链接到APM服务页面查看ivm、调用链等信息，当前仅支持JAVA函数，支持用户直接打包上传容器镜像，由平台加载并启动运行。
• FunctionGraph2.0是新一代函数计算与编排服务
  • 与CloudIDE深度集成，多函数并行调测，调用链追踪，函数应用向导式构建全生命周期管理
  • 6大类编程语言和自定义运行时，百毫秒内冷启动时延，毫秒级弹性伸缩.
  • 国内首发支持有状态函数，可视化函数编排功能
  • 支持Web应用零改造实现Serverless化。

4.4 Serverless生命周期管理

• 应用开发: 开箱即用的云上IDE环境，针对集群化的多个Serverless应用展开全链条跟踪调测，支持代码断点、堆栈查看、调用拓扑和代码热替换
• CICD:跟Serverless运行时服务深度集成的持续交付工具，与应用运维观测工具，形成Serverless应用轻量级DevOps能力。
• 函数应用托管:Serverless应用生命周期管理: 统一的Serverless应用规范，提供应用全生命周期管理能力，通过模板、市场，支持应用的快速体验和复用。
• CAE(Cloud Application Engine云应用引擎)是一个面向应用的Serverless托管服务提供极速部署、极低成本、极简运维的一站式应用托管方案。支持从源码、软件包、镜像包快速发布应用，秒级弹性伸缩、按量付费。可做到基础设施免运维，根据可观测的运行指标对应用进行生命周期管理。

4.5 可视化函数流支持复杂业务场景

• 用户通过在可视化的编排页面，将事件触发器、函数和流程控制器通过连线关联在-个流程图中，每个节点的输出作为连线下一个节点的输入。编排好的流程会按照流程图中设定好的顺序依次执行，执行成功后支持查看工作流的运行记录，方便用户轻松地诊断和调试。

4.6 统一插件支持云上和云下的开发与调试

• CloudIDE支持(云上): 通过模板创建函数，在云端查看函数并下载到云，使用IDE在线调试，将函数推送到云端。
• VSCode插件支持(云下): 通过模板创建函数，在云端查看函数并下载到本地调试使用VSCode插件调试，将本地函数推送到云端

4.7 改造成本低

• HTTP函数专注于优化Web服务场景，用户可以直接发送HTTP请求到URL触发函数执行。在函数创建编辑界面增加类型。HTTP函数只允许创建APIG/APIC的触发器类型其他触发器不支持

4.8 支持容器镜像

• 从传统应用开发转为Serverless 函数的开发方式还面临不少困难
  • 运行时和交付件的格式不统一: Serverless函数厂商提供的运行时环境有的是docker，有的是microVM，交付件的格式和函数签名也不尽相同，这都需要开发者做适配，给开发者带来了不小的学习成本。
  • 生态不成熟:缺少流行开源工具(如 CI/CD 流水线)的支持
• 另一方面，容器成熟的生态很好了解决了可移植性和敏捷交付的问题，容器镜像已成为云原生时代标准的交付物。然而，容器本身并没有减轻运维、降低资源闲置成本等难题。
• 开发者可以在事件函数下创建自定义镜像，也可以在HTTP函数下创建自定义镜像。

4.9 适用场景

思考题

完结撒花