云原生虚拟化+Docker+k8s+Istio

在Linux中，容器技术是一种进程隔离的技术，应用可以运行在一个个相互隔离的容器中，与虚拟机相同的是，可以为这些容器设置计算资源限制，挂载存储，连接网络，而与虚拟机不同的是，这些应用运行时共用一个Kernel。
这些技术的基础是Linux的LXC(linux Container),通过将Cgroups的资源管理能力和Linux Namespace的隔离能力组合在一起。

概念-Cgroups

其名称源自控制组群（Control groups）的简写，是Linux内核的一个功能，用来限制、控制与分离一个进程组的资源（包含cpu、内存-memory、devices子系统、磁盘输入与输出等）。

概念-Namespace

提供了一种内核级别隔离系统资源的方法，通过将系统的全局资源放在不同的Namespcae中，实现资源隔离的目的。不同的Namespace程序，可以享有一份独立的系统资源。

隔离内容包括：

UTS-主机名与域名
IPC-信号量、消息队列和共享内存
PID-进程编号
Network-网络设备，网络栈、端口
Mount-挂载点（文件系统）
User-用户和用户组

Docker介绍

一个用于开发，交付和运行应用程序的开放平台。Docker能够将应用程序与基础架构分开，从而快速交付软件。大大减少编写代码和在生产环境中运行代码之间的延迟。

Docker VS VM

1 Docker启动快速属于秒级别，虚拟机通常几分钟去启动
2 Docker需要的资源更少，docker在操作系统级别进行虚拟化，docker容器和内核交互，几乎没有性能损耗，性能优于通过Hypervisor层和内核层的虚拟化
3 docker更轻量，docker的架构可以公用一个内核与共享应用程序库，所占内存极小
4 高可用和可恢复性：docker对业务的高可用支持是通过快速重新部署实现的
5 快速创建、删除：虚拟化创建是分钟级别的，Docker容器创建是秒级别的，Docker的快速迭代性，决定了无论是开发、测试、部署都可以节约大量时间
6 交付、部署：虚拟机可以通过镜像实现环境交付的一致性，但镜像分发无法体系化；Docker在Dockerfile中记录了容器构建过程，可以在集群中实现快速分发和快速部署

Docker使用流程

1 首先开发者在开发环境机器上开发应用并制作镜像。Docker执行命令，构建镜像并存储在机器上。
2 开发者发送上传镜像命令，docker收到命令后，将本地镜像上传到镜像仓库。
3 开发者向生产环境机器发送运行镜像命令，生产环境机器收到命令后，docker会从镜像仓库拉取镜像到仓库上，然后基于镜像运行容器。

Docker镜像

一种新型的应用打包、分发和运行机制。容器镜像将应用环境，包括代码、依赖库、工具、资源文件和元信息等，打包成一种操作系统发行版无关的不可变更软件包。

镜像仓库

容器镜像服务（Software Repository for Container,简称SWR）是一种支持镜像全生命周期管理的服务，提供简单易用、安全可靠的镜像管理服务，帮助快速不是容器化服务。

核心功能：镜像全生命周期管理、私有镜像仓库、镜像源加速、镜像仓库触发器、镜像安全扫描

使用Dockerfile进行镜像构建

Build image-->push image-->pull image
结合阿里云平台的提交过程：Docker初体验-“AI Earth”人工智能创新挑战赛——AI助力精准气象和海洋预测 - 简书

# Dockerfile文件
# Base Images
## 从天池基础镜像构建
FROM registry.cn-shanghai.aliyuncs.com/tcc-public/python:3

## 把当前文件夹里的文件构建到镜像的根目录下
ADD . /

## 指定默认工作目录为根目录（需要把run.sh和生成的结果文件都放在该文件夹下，提交后才能运行）
WORKDIR /

## Install Requirements
RUN pip install -i https://pypi.tuna.tsinghua.edu.cn/simple -r requirements.txt

## 镜像启动后统一执行 sh run.sh
## 本题用如下代码，如果自己测试，用此代码，CMD ["sh", "code/run.sh"]
CMD ["sh", "run.sh"]

三：Kubernetes系统快速入门

“云”的资源在使用者看来是无限扩展的，并且可以随时获取、按需使用、随时扩展，按使用付费。

1、 K8S介绍

可分为内核层、应用层、治理层、接口层，其中生态层不属于K8S范围

K8S架构分层

各层的详细定义

接口层(工具、SDK库、UI等)

K8S官方的项目会提供库、工具、UI等外围工具
外部可提供自有的实现

治理层：策略执行和自动化编排

对应用运行的可选层，没有这层功能不影响应用的执行
自动化API:水平弹性伸缩、租户管理、集群管理、动态LB等
策略API:限速、资源配额、pod可靠性策略、network policy等

应用层：部署（无状态/有状态应用、批处理、集群应用等）和路由（服务发现、DNS解析等）

K8S发行版必备功能和API，K8S会提供默认的实现，如scheduler
controller和scheduler可以被替换为各自的实现，但必须通过一致性测试
业务管理类Controller

内核层：K8S最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境

由主流K8S codebase实现（主项目），属于K8S的内核，最小特性表。等同于Linux Kernel
提供必不可少的Controller, Scheduler的默认实现
集群管理类Controller

2、 K8S基本概念

关键概念-pod

pod是能够创建、调度、管理的最小部署单元，是一组容器的集合，而不是单独的应用容器
同一个pod里面的容器共享同一个网络命名空间，IP地址及端口空间
从生命周期来说，pod是短暂的而不是长久的的应用。pods被调度到节点，保持在这个节点上直到被销毁
容器包括：基础容器（infrastructure container）、初始化容器（InitContainers）、业务容器（containers）

pod与工作负载的关系

pod通过工作负载（work load）实现应用的运维，如伸缩、升级等

3、 K8S总体架构

基于list-watch机制的控制器架构

四：K8S集群管理

常见部署形态

K8S集群的常见部署方式：

本地调试
第三方工具托管
认证云平台托管

生产集群及其特点

高可用：满足业务容需求
弹性伸缩：满足动态资源需求
安全和权限管理：满足组织权限管理需求

自建与运维K8S集群

优势：高灵活性，可定制开发
缺点：重资产、高投入、运维成本高、跨云迁移困难

使用CNCF认证的K8S容器平台

优势：轻资产、低投入、运维成本低，跨云迁移方便
缺点：灵活性较低，迭代依赖于云厂商

K8S节点生命周期介绍

k8s中定义：业务负载（Pod）是资源的消费者；节点（Node）是业务负载的载体；云厂商Provider是基础资源的生产者

通过节点池管理集群集群节点资源（节点池：集群中具有相同配置的一组节点，一个节点池包含一个节点或多个节点）。

K8S工作负载管理

工作负载（Workload）介绍

工作负载是在K8s上运行的应用程序。无论负载是单一组件还是由多个一同工作的组件构成，在K8S中可以在一组pods中运行。在K8S中，pod代表的是集群上处于运行状态的一组容器。

无状态工作负载：管理的Pod集合是相互等价的，需要的时候可以被替换

Deployment
ReplicaSet
ReplicationController

有状态工作负载：为每个Pod维护了一个唯一的ID，能够保证Pod的顺序性和唯一性，每个Pod是不可替换的。可使用持久存储来保存服务产生的状态

StatefulSet

守护进程工作负载：保证每个节点上运行着这样一个守护进程

DaemeonSet

批处理工作负载：一次性的任务

Job
CronJob

Deployment概述

Deployment是一组不具有唯一标识的多个Pod的集合：

确保集群中有期望数量的Pod运行
提供多种升级策略以及一键回滚能力
提供暂停/恢复的能力
典型应用场景：Web Server等无状态应用

Job/CronJob概述

Job主要处理一些短暂的一次性任务：

保证指定数量Pod成功运行结束
支持并发执行
支持错误自动重试
支持暂停/恢复Job
典型应用场景：计算以及训练任务，如批量计算，AI训练任务等

CronJob主要处理周期性或者重复性的任务：

基于Crontab格式的时间调度
可以暂停/恢复CronJob
典型的使用场景：周期性的数据分析服务；周期性的资源回收服务

DaemonSet概述

DaemonSet（守护进程集）功能：

确保每一个节点或者期望的节点上运行一个Pod
新增节点时自动部署一个Pod
移除节点时自动删除Pod
典型应用场景：日志监控采集进程，如fluented, icagent; 节点运维进程，如Node Problem Detector; k8s必要组件，如Everest Driver

总结

Deployment: 无状态应用，保证集群中应用数量，并提升升级，回滚，暂停等能力
Job: Job会创建一个或者多个Pod，直到指定数量的Pod成功终止
Cronjob：简称cj，周期执行job
DamemonSet：简称ds,确保每个或者某一类节点上运行Pod副本。

五：持久化数据卷管理

在生产环境中，除了一些无状态应用外，还有一部分应用需要将结果数据（也即：状态）缓存下来，并永久的记录在存储中，以供后续使用——有状态应用。
与“无状态应用“相比，我们期望”有状态应用“具有哪些能力：

计算维度

每个pod的名字需要是稳定的，不会发生变化的；
pods之间的启动、升级，退出可以按照某种顺序控制的。

存储维度

存储是持久的，拥有独立于pod的生命周期，不会随着pod的生命周期结束而销毁；
每个pod与其使用的存储关系是稳定的，不会因升级等因素而发生变化。

网络维度

每个pod有独立、稳定的网络标识

有状态应用&持久化存储的最佳实践

小结

各参数类比解释

StatefulSet：简称sts，有状态应用，一种K8S为用户提供一组具有有序，唯一、稳定的应用实例集合。与Deployment通过ReplicaSet来管理pod生命周期不同，StatefulSet是直接管理pod的。
Volume：卷，K8S为存算分离所做的解耦设计，让用户更加专注于业务功能设计。它在K8S中是依托于pod而使用的。
PersistentVolume：简称pv，持久化存储，是K8S为云原生应用提供一种拥有独立生命周期的、用户可管理的存储抽象设计。
PersistentVolumnClaim：简称pvc，持久化存储声明，是K8S为解耦云原生应用提供和数据存储而设计的，通过PVC可以让资源管控更细更灵活，团队职责分离，应用模板更通用，进一步解除了用户被云平台锁定的顾虑。
StorageClass：简称sc,存储类，是K8S平台为存储提供商提供存储接入的一种声明，通过sc和相应的存储插件（csi/flexvolume）为容器应用提供动态分配存储卷的能力。

六：网络与服务管理

Kubernstes工作负载部署应用服务，需要通过Service或者Ingress暴露给其他服务或者外部用户。

Service基本概念和使用场景

K8S service定义了这样一种抽象：一个pod的逻辑分组，一种可以访问它们的策略——通常称为微服务。这一组pod能够被Service访问到，通常是通过label selector实现的。

ClusterIP: K8S集群内部虚拟服务IP，由kube-proxy实现
Endpoints: k8s资源对象service实际服务后端的集合。手动创建或Endponts controller自动生成。

Service类型：

类型1：services without selectors
类型2：headless service。通过指定Cluster IP 的值为”none“来创建headless service。headless service不会分配Cluster IP, kube-proxy不会处理该类service，可以通过域名解析直接访问backend pod 一跳直达，具体实现取决于DNS（域名）实现。

发布服务-服务类型

ClusterIP: 通过集群的内部IP暴露服务，选择该值，服务只能够在集群内部访问
NodePort: 通过每个Node上的IP和静态端口（NodePort）暴露服务。NodePort服务会路由到ClusterIP服务，这个ClusterIP服务会自动创建。通过请求<NodeIP>:<NodePort>, 可以从集群的外部访问一个NodePort服务。
LoadBalancer: 使用云提供商的负载均衡器，可以向外部暴露服务。外部的负载均衡器可以路由到NodePort服务和ClusterIP服务。
ExternalName: 通过返回CNAME 和它的值，可以将服务映射到externalName字段的内容。没有任何类型代理被创建，这只有K8S 1.7 或更高版本的kube-dns才支持。

Service背后的实现：Kube-proxy

每台机器上面都运行着一个kube-proxy服务，他监听API server 中的service和endpoint等来为服务配置负载均衡

Ingress基本概念和使用场景

Ingress是从k8s集群外部访问集群内部服务的入口
通常情况下，service和pod仅可在集群内部网路中通过IP地址访问。所有到达边界路由器的流量或被丢弃或被转发到其他地方。

Ingress controllers

Ingress controllers负责实现ingress，是K8S Ingress能够生效的先决条件。为了使Ingress正常工作，集群中必须运行Ingress controller

七：K8S应用配置管理

Service和Ingress解决的是服务暴露问题，具体的服务实现还需要Pod来完成。Pod的运行通常需要为其提供配置。

应用配置管理概述

应用配置：数据库配置、证书配置、应用自定义配置
K8S应用配置：ConfigMap(一般性配置)，Secret(敏感信息配置)

ConfigMap概述

ConfigMap是一种存储非敏感数据的资源对象

以<key-value>形式存储配置数据

ConfigMap设计要素

解耦应用程序（镜像）和配置参数
不用于存储大块数据（<=1MB）

ConfigMap主要服务于Pod

为容器提供环境变量
为容器提供命令行参数
为容器提供配置文件

ConfigMap资源对象

API设计：没有Spec字段
Data字段：用来保存UTF-8字节序列；域名不能与BinaryData重叠
BinaryData：用来保存二进制数据（base64编码）；域名不能与Data重叠
Immutable(v1.19 版本)：不可变更；保护性能；提升性能

ConfigMap使用小结

ConfigMap用于存储非敏感应用配置
每个ConfigMap大小限制为1MB
ConfigMap必须先于Pod创建，否则Pod无法启动
Pod只能使用同Namespace下的ConfigMap
使用ConfigMap挂载配置文件，会自动更新
使用ConfigMap配置环境变量时，不会自动更新

Secret概述

secret是一种资源对象

以<key-value>形式存储敏感数据（密码，token等）

secret设计要素

数据通常采用base-64编码保存（非加密）
通常结合RBAC rules来加强安全性

Secret主要服务于Pod

为容器提供环境变量
为容器提供镜像仓库钥匙（由kubelet使用）
为容器提供配置文件

Secret使用小结

Secret用于存储敏感位置（区别于ConfigMap）
每个Secret大小限制为1MB
Pod只能使用同Namespace下的Secret
Secret数据使用Base64编码，本身不提供数据加密（由于Secret会以纯文本方式存储在ETCD,需要限制ETCD的访问权限；为Secret设置严格的RBAC规则，限制资源访问）

八：Istio服务网格快速入门

CNCF(Cloud Native Computing Foundation)对云原生的定义：云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性收缩扩展的应用。云原生的代表性技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

云原生构成

趋势：服务治理和业务逻辑逐步解耦，服务治理能力下沉到基础设施，服务网格以基础设施的方式提供无侵入的连接控制、安全、可监测性，灰度发布等治理能力，如华为ASM,谷歌GCP。

服务网格的基本概念和发展历程

服务网格是承载微服务架构理念的云原生技术形态，具有连接、安全、观测、控制功能。

服务网格是一种云原生的、应用层的网络技术

云原生：面向弹性、（微）服务化、去中心化业务场景
应用层：以应用为中心，关注应用的发布、监控、恢复等
网络：关注应用组件之间的接口、流量、数据、访问安全等

Istio项目发展历程：多个头部云厂商参与，已经商业Ready

发展历程

Istio的基本概念、技术架构和功能特性

1 基本概念

Istio是一种云原生的、应用层的、网络技术，用于解决组成应用的组件之间的连接、安全、策略、可观察性等问题。
对于云原生应用，采用Kubernetes构建微服务部署和集群管理能力，采用Istio构建服务治理能力，将逐渐成为应用微服务转型的标准配置。

k8s & Istio 融合

1 容器和微服务共同的轻量、敏捷的特点，微服务运行在容器中日益流行
2 K8S在容器编排领域成为事实标准
3 Istio提供Service Mesh方式无侵入微服务治理能力，成为微服务治理的趋势
4 Istio和K8S紧密结合。基于K8S构建，补齐了K8S的治理能力，提供了端到端的微服务运行治理平台。

2 Istio技术架构

逻辑划分

数据平面：由一组智能代理（Envoy）组成，被部署为sidecar
控制平面：管理并配置代理来进行流量路由

Istio核心组件

Pilot：为Enovy sidecar提供服务发现、用于智能路由的流量管理功能（如A/B测试，金丝雀发布）以及弹性功能（超时、重试、熔断器等）
Citadel: 通过内置的身份和证书管理，可以支持强大的服务到服务以及最终用户的身份验证
Gallery: Istio的配置验证、提取、处理和分发组件。

3 Istio功能特性

核心理念

非侵入式Sidecar注入技术，将数据面组件注入到应用所在的容器，通过劫持应用流量来进行功能实现，应用无感知
北向API基于K8S CRD实现，完全声明式，标准化
数据面与控制面通过xDS gRPC标准化协议通信，支持订阅模式。

核心特性

服务&流量治理：熔断，故障注入，丰富的负载均衡算法，限流，健康检查，灰度发布，蓝绿部署等
流量与访问可视化：提供应用级别的监控，分布式调用链，访问日志等
安全连接：通过mTLS、认证、鉴权等安全措施帮助企业在零信任的网络中运行应用。

Istio的应用场景

灰度发布：版本升级平滑过渡的一种方式
流量管理：负载均衡，连接池管理，熔断、故障注入等
访问可视化：监控数据采集、运行指标分析、应用拓扑和调用链展示等
应用场景：电商应用，政务业务，视频业务等

10：Istio灰度发布管理

灰度发布的定义和分类

灰度发布是迭代的软件产品在生产环境安全上线的一种重要手段
应用服务网格基于Istio提供的服务治理能力，对服务提供多版本支持和林获得流量策略，从而支持多种灰度发布场景

金丝雀发布
在生产环境上引一部分实际流量对一个新版本进行测试，测试新版本的性能和表现，在保证系统整体稳定运行的前提下，尽早发现新版本在实际环境上的问题。
通过线上运行的服务中，新加入少量的新版本的服务，然后从这少量的新版本中快速获得反馈，根据反馈决定最后的交付形态

灰度发布的两种形式

1 基于权重的灰度发布：根据需要灵活动态的调整不同服务版本的流量比例
2 基于内容的灰度发布：可根据请求的内容控制其流向的服务版本（Cookie, Header, OS, bROWSER）

蓝绿发布

蓝绿发布提供了一种零宕机的部署方式。不停老版本，部署新版本进行测试，确认OK，将流量切换到新版本，然后老版本同时也升级到新版本。始终有两个版本同时在线，有问题可以快速切换。
在部署应用的过程中，应用始终在线。并且新版本上线过程中，不会修改老版本的任何内容，在部署期间老版本状态不受影响。只要老版本的资源不被删除，可以在任何时候回滚到老版本。
可根据需要将全量流量在新旧版本之间切换。

灰度发布的流程

灰度发布全流程自动化管理：

灰度版本一键部署，流量切换一键生效
配置式灰度策略，支持流量比例，请求内容（Cookie, OS, 浏览器等）、源IP
一站式健康、性能、流量监控，实现灰度发布过程量化、智能化、可视化

十：Istio流量治理与监控管理

1 Istio服务治理介绍

微服务：互联网高速发展以及传统分布式、SOA架构无法适应快速的开发迭代等多重因素共同推动下的产物
微服务雏形：微服务架构概念最早由Fred George在2012年的一次技术大会上提出，拆分SOA服务实现解耦。

服务治理介绍

服务治理与服务发现
服务负载均衡、路由、灰度、蓝绿
服务降级、熔断
服务限流
服务监控
微服务架构：SpringCloud、Dubbo

服务网格与微服务框架流量治理对比

	微服务框架	服务网格
业务侵入性	SDK，倾入式开发	Sidecar, 无侵入
开发语言	语言强相关，JAVA生态支持较好	开发语言无关
灵活性	静态配置。更新配置需要重启	非常灵活，动态配置
升级	需要业务开发优雅处理服务升级，具有很大难度	优雅升级简单

2 Istio常用的流量治理策略

流量治理策略一：服务注册&发现

流量治理策略二：负载均衡
支持的负载均衡算法：加权轮询、最少请求、环形hash、随机、优先级负载均衡、Locality加权

Field	类型	意义
simple	SimpleLB(ONEOF)	简单的负载均衡策略
consistentHash	ConsistentHashLB(oneof)	一致性Hash负载均衡算法
localityLbSetting	localityLoadBalancerSetting	基于位置信息的负载均衡
distribute	Distribute[]	显式的指定跨不同可用域的负载均衡权重
failover	Failover[]	显式的指定负载均衡故障转移策略，指明当本区域的服务实例变得不健康时，请求转移到哪些区域

流量治理策略三：路由（流量切分、灰度发布）

Field	类型	意义
match	HTTPMatchRequest[]	HTTP匹配（url,header, scheme, method,query param）
route	HTTPRouteDestination	路由目的端，支持权重设置

流量治理策略四：熔断、降级

Field	类型	意义
tcp	TCPSettings	TCP连接池设置
http	HTTPSettings	HTTP连接池设置

流量治理策略五：故障注入
故障注入可以用来识别系统最薄弱的环节，支持的类型：1、HTTP请求响应延时注入；HTTP 、gRPC错误码注入。

流量治理策略六：限流
Istio支持两种先流方式：1、中心集中式限流；2、本地限流。

流量治理策略七：失败重试

Field	类型	意义
attempts	int32	重试次数
preTryTimeout	HTTPSettings	每次重试的超时时间
retryOn	string	重试条件
retryRemoteLocalities	BoolValue	是否重试到其他地域的Endpoints