关于云原生:云原生入门到进阶1篇就够了

开始阅读文章前，请角色切换：构想你作为一位中小型 IT 公司 CTO，面对云原生技术决策，你须要答复两个问题：

为什么须要上云？

上云有何弊病？

作为一家公司的技术决策者，必须了解上云的利与弊，并联合公司各阶段倒退指标给出最适宜的技术计划。

云原生 - 概述

（一）云原生 - 定义

云原生的定义，业界也是“百家争鸣”各持观点，从技术视角了解云原生会绝对清晰。云原生的关键技术包含：

• 微服务架构：服务与服务之间通过高内聚低耦合的形式交互。

• 容器：作为微服务的最佳载体，提供了一个自蕴含的打包形式。

• 容器编排：解决了微服务在生产环境的部署问题。

• 服务网络：作为基础设施，解决了服务之间的通信。

• 不可变根底：设施晋升公布效率，不便疾速扩大。

• 申明式 API：让零碎更加强壮

命令式 API：能够间接收回让服务器执行的命令，例如：“运行容器”、”进行容器”等。

申明式 API：能够申明冀望的状态，零碎将一直地调整理论状态，直到与冀望状态保持一致。

• DevOps：缩短研发周期，减少部署频率，更平安中央便：

Culture：达成共识

Automation：基础设施自动化

Measurement：可度量

Sharing：你中有我，我中有你

【私人观点】

云原生的定义：利用因云而生，即云原生。

利用原生被设计为在云上以最佳形式运行，充分发挥云的劣势，是上云的最短门路。

（二）云原生 - 技术生态

（三）云原生 - 关键技术

云原生关键技术包含：微服务，容器，容器编排，服务网络，不可变根底，申明式 API。

（1）微服务

微服务是一种用于构建利用的架构计划。

将一个简单的利用拆分成多个独立自治的服务，服务与服务间通过“高内聚低耦合”的模式交互。

微服务典型架构包含：

• 服务重构：单体革新成合乎业务的微服务架构。

• 服务注册与发现：微服务模块间的服务生命周期治理。

• 服务网关：身份认证、路由服务、限流防刷、日志统计。

• 服务通信：通信技术计划如，RPC vs REST vs 异步音讯。

• 可靠性：服务优雅降级，容灾，熔断，多正本。

（2）容器

容器是一种打包利用的形式，能够打包利用中的所有软件和软件所依赖的环境，并可实现跨平台部署。

容器关键技术：namespac 视图隔离，cgroups 资源隔离，Union File System 联结文件系统。

容器劣势：

• 更高效的利用资源。
• 更疾速的启动工夫。
• 一致性的运行环境。

（3）容器编排

容器编排包含：自动化治理和协调容器的零碎，专一于容器的生命周期治理和调度。

外围性能：

• 容器调度：根据策略实现容器与母机绑定。
• 资源管理：CPU、MEM、GPU、Ports、Device。
• 服务治理：负载平衡、健康检查。

（4）服务网格

服务网格（Service Mesh）是致力于解决服务间通信的基础设施层。

• Service Mesh 应答云原生利用的简单服务拓扑，提供牢靠的通信传递。
• 通过一组轻量级网络代理（Sidecar proxy），与利用程序代码部署在一起来实现，且对应用程序通明。

Service Mesh 特点：

• 应用程序间通信的中间层。
• 轻量级网络代理，应用程序无感知。
• 解耦利用的重试、监控、追踪、服务发现。

Service Mesh 支流组件：Istio、MOSN（Modular Open Smart Network）Linkerd。

（5）不可变基础设施

不可变基础设施（Immutable Infrastructure）（宠物 VS 家畜）

• 任何基础设施实例（服务器、容器等各种软硬件）一旦创立之后便成为一种只读状态，不可对其进行任何更改。

• 如果须要批改或降级实例，惟一形式是创立一批新实例以替换。

不可变基础设施的劣势：

• 晋升公布利用效率。
• 没有雪花服务器。
• 疾速程度扩大。

（6）申明式 API

• 命令式 API：可间接收回让服务器执行的命令，例如：“运行容器”、“进行容器”等。

• 申明式 API：可申明冀望的状态，零碎将一直地调整理论状态，直到与冀望状态保持一致。

为什么申明式使零碎更加强壮？

能够类比了解成自动化工程学的闭环自适应模型。

（7）DevOps

DevOps 指标：缩短开发周期，减少部署频率，更牢靠地公布。

从历史上开发和运维绝对孤立到开发和运维之间建设单干，能够减少信赖，更疾速地公布新版本。

DevOps 是一组过程，办法和零碎的统称包含：

• Culture：

文化是 DevOps 中的第一胜利因素。

因为指标不同，开发和运维造成一堵墙，DevOps 通过建设开发和运维之间单干和沟通的文化来打消墙。

• Automation：

自动化软件的开发和交付，通常蕴含继续集成，继续交付和继续部署，云原生时代还包含基础架构的自动化，即 IaC(Infrastructureas code)。

• Measurement：

度量尤其重要，通过主观的测量来确定正在产生的事件的真实性，验证是否按预期进行扭转。并为不同职能部门达成统一建设主观根底。

• Sharing：

1. 开发和运维团队之间长期存在摩擦的次要起因是不足独特的根底。

2. 开发参加运维值班，参加软件的部署和公布，运维参加架构设计。

容器 -Docker

（一）Docker概述

为什么学习容器技术?

云时代从业者：Docker 已成云平台运行分布式、微服务化利用的行业标准。

作为有技术谋求的程序员，有必要了解云原生的关键技术：容器。

Docker 外围概念：镜像、容器、仓库。

镜像(Image)：

• 一个只读模板。
• 由一堆只读层（read-only     layer）重叠。
• 对立文件系统（UnionFileSystem）整合成对立视角。

容器(Container)：

• 通过镜像创立的互相隔离的运行实例。
• 容器与镜像区别：最下面那一层可读可写层。
• 运行态容器定义：一个可读写的对立文件系统，加上隔离的过程空间，以及蕴含在其中的利用过程。

仓库（Repository）：

• 集中寄存镜像文件的中央。
• Docker Registry 可蕴含多个仓库（Repository），每个仓库可蕴含多个标签（Tag），每个标签对应一个镜像。

（二）Docker关键技术

（1）Namespace视图隔离

Linux namespace 是一种内核级别的环境隔离机制，使得其中的过程如同领有独立的零碎环境。

Network namespace 在 Linux 中创立互相隔离的网络视图，每个网络名字空间都有本人独立的网络配置，包含：网络设备、路由表、IPTables 规定，路由表、网络协议栈等。（默认操作是主机默认网络名字空间）

（2）control groups（资源隔离）

Linux Control Group 是内核用于限度过程组资源应用的性能。资源包含：CPU，内存，磁盘 IO 等。

（3）Union File System（联结文件系统）

Union File System，联结文件系统：将多个不同地位的目录联结挂载 (union mount) 到同一个目录下。

• Docker 利用联结挂载能力，将容器镜像里的多层内容出现为对立的 rootfs(根文件系统)。
• Rootfs 打包整个操作系统的文件和目录，是利用运行所须要的最残缺的“依赖库”。

（三）Docker-网络技术

Bridge 模式：Docker0 充当网桥，在默认状况下，被限度在 Network Namespace 里的容器过程，是通过 Veth Pair 设施 + 宿主机网桥的形式，实现跟同其余容器的数据交换。

一旦一张虚构网卡被“插”在网桥上，它就会变成该网桥的“从设施”。

从设施会被“剥夺”调用网络协议栈解决数据包的资格，从而“降级”成为网桥上的一个端口。

而这个端口惟一的作用，就是接管流入的数据包，而后把这些数据包全副交给对应的网桥，由网桥实现转发或者抛弃。

veth 提供一种连贯两个 network namespace 的办法。

Veth 是 Linux 中一种虚构以太设施，总是成对呈现常被称为 Veth pair。

能够实现点对点的虚构连贯，可看成一条连贯两张网卡的网线。一端网卡在容器的 Network Namespace 上，另一端网卡在宿主机 Network Namespace 上。任何一张网卡发送的数据包，都能够对端的网卡上收到。

在物理网络中，如果须要连贯多个主机，会用交换机。

在 Linux 中，可能起到虚构交换机作用的网络设备，是网桥（Bridge）。

它是一个工作在数据链路层的设施，次要性能是依据 MAC 地址学习来将数据包转发到网桥的不同端口（Port）上。

Bridge 网桥相似交换机，两个以上 namespace 接入同一个二层网络。

veth pair 一端虚构网卡退出到 namespace，另一端到网桥上。

路由（routing）是通过互联的网络把信息从源地址传输到目标地址的流动，产生在 OSI 模型的第三层（网络层）。Linux 内核提供 IP Forwarding 性能，实现不同子网接口间转发 IP 数据包。

路由器工作原理：

• 路由器上有多个网络接口，每个网络接口处于不同的三层子网上。
• 依据外部路由转发表将从一个网络接口中收到的数据包转发到另一个网络接口，实现不同三层子网间互通。

容器编排 -Kubernetes

（一）概述 & 架构 & 外围组件

我认为 Kubernetes 最大胜利：让容器利用进入大规模工业生产。

Kubernetes 的提供个性，简直笼罩一个分布式系统在生产环境运行的所有要害事项。包含：

• Automated rollouts and rollbacks(自动化上线和回滚)

应用 Kubernetes 形容已部署容器的所需状态，受控的速率将理论状态更改为冀望状态。

• Self-healing(自我修复)

Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况查看的容器，并且在筹备好服务之前不将其通告给客户端。

• Service discovery and load balancing(服务发现与负载平衡)

Kubernetes 能够应用 DNS 名称或本人的 IP 地址公开容器，如果进入容器的流量很大，Kubernetes 能够负载平衡并调配网络流量，从而实现部署稳固。

• Storage orchestration(存储编排)

Kubernetes 容许你主动挂载抉择的存储系统，例如本地存储、公厂商等。

• Automatic bin packing(主动装箱)

Kubernetes 容许指定每个容器所需 CPU 和内存（RAM）。当容器指定资源申请时，Kubernetes 能够做出更好的决策来治理容器的资源。

• Secret and configuration management(平安和配置管理)

Kubernetes 容许存储和治理敏感信息，例如明码、OAuth 令牌和 ssh 密钥。你可在不重建容器镜像的状况下部署和更新密钥和应用程序配置，也无需在堆栈配置中裸露密钥。

API Service：Kubernetes 各组件通信中枢。

• 资源操作的惟一入口，并提供认证、受权、访问控制、API 注册和发现等机制。
• 为 Pod，Deployment，Service 等各种对象提供 Restful 接口。
• 与 etcd 交互的惟一组件。

Scheduler：负责资源调度，依照预约调度策略将 Pod 调度到相应的机器。

• Predicates(断言)：淘汰制
• Priorities（优先级）：权重计算总分。

Controller manager：负责保护集群的状态，比方故障检测、主动扩大、滚动更新等。

etcd：分布式的 K - V 存储，独立于 Kubernetes 的开源组件。

• 次要存储要害的原数据，反对程度扩容保障元数据的高可用性。
• 基于 Raft 算法实现强一致性，独特的 watch 机制是 Kubernetes 设计的要害。

kubelet：负责保护 Pod 的生命周期，同时负责 Volume（CVI）和网络（CNI）的治理。

kube-proxy：负责为 Service 提供 cluster 外部的服务发现和负载平衡

• kube-proxy 通过在节点上增加 iptables 规定以及从中移除这些规定来治理此端口从新映射过程。

控制器模式的设计思维：

容器类比集装箱，集装箱诚然好用，然而如果它各面赤裸裸的，吊车还怎么把它吊起来摆放好呢？

Pod 对象其实就是容器的升级版，对容器进行组合，增加更多属性和字段。就好比在集装箱上装置了吊环，Kubernetes 这台“吊车”能够更轻松操作容器。

然而 Kubernetes 操作这些“集装箱”的逻辑都是由控制器实现的。

Kubernetes 通过“控制器模式”的设计思维，来对立编排各种对象和资源。

（二）部署 & 资源管制 & 存储

Kubernetes- 集群部署架构

• 所有组件通过 kubelet static pod 的形式启动保障宿主机各组件的高可用，systemd 提供 kubelet 的高可用。

• 每个 Master 的应用 hostNetwork 网络，controller-manager 和 scheduler 通过 localhost 连贯到本节点 apiserver。

• controller-manager 和 scheduler 的高可用通过本身提供的 leader 选举性能（–leader-elect=true）。

• apiserver 高可用，可通过经典的 haporxy+keepalived 保障，集群对外裸露 VIP。

• 内部拜访通过 TLS 证书，在 LB 节点做 TLS Termination，LB 进去 http 申请到对应 apiserver 实例。apiserver 到 kubelet、kube-proxy 相似。

（三）Kubernetes- 网络技术

（1）对外服务

Service 是一个逻辑概念，一组提供雷同性能 Pods 的逻辑汇合，并提供四层负载对立入口和定义拜访策略。

交互流程：Service 可通过标签选取后端服务。匹配标签的 Pod IP 和端口列表组成 endpoints，有 kube-proxy 负责平衡到对应 endpoint。

为什么须要 service？

• 对外提供入口（容器如何被内部拜访）。
• 克服 Pod 动态性（Pod IP 不肯定能够稳固依赖）。
• 服务发现和稳固的服务（Pod 服务发现、负载、高可用）。

Service Type 四种形式

• Cluster IP：配置 endpoint 列表。
• NodePort：默认端口范畴：30000-32767，通过 nodeIP：nodePort 拜访。
• LoadBalancer：实用于私有云，云厂商实现负载，配置 LoadBalance 到 podIP。
• ExternalName：服务通过 DNS CNAME 记录形式转发到指定的域名。

Service Type 为 Cluster IP：

• Kubernetes 的默认服务，配置 endpoint 列表，能够通过 proxy 模式来拜访该对应服务。
• 相似通过 Nginx 实现集群的 VIP。

Service Type 为 Node Port：

在集群所有节点上凋谢特定端口，任何发送到该端口流量借助 Service 的 Iptables 规定链发送到后端 Pod。

注意事项：

• 每个服务对应一个端口，端口范畴只有 30000–32767。
• 须要感知和发现节点变动，流量转发减少 SNAT 流程，Iptables 规定会成倍增长。

实用场景：服务高可用性要求不高或老本不敏感，例如：样例服务或长期服务。

Service Type 为 Load Balancer：

对公网裸露服务倡议采纳此形式，Service 没有对其行为做任何标准，依赖云厂商 LB 具体实现（云厂商免费服务）如：腾讯私有云：CLB。

Service Type 为 External Name：

DNS 作为服务发现机制，在集群内提供服务名到 Cluster IP 的解析。

CoreDNS：DNS 服务，CNCF 第 04 个毕业我的项目，KUBERNETES 的 1.11 版本已反对。

CoreDNS 实现的高性能、插件式、易扩大的 DNS 服务端，反对自定义 DNS 记录及配置 upstream DNS Server，能够对立治理 Kubernetes 基于服务的外部 DNS。

Ingress Controller：定义入流量规定，可做七层 HTTP 负载君合。

Egress Controller：定义出流量规定。

交互流程：通过与 Kubernetes API 交互，动静感知集群 Ingress 规定，依照自定义的规定生成（负载均衡器）配置文件，并通过 reload 来从新加载。

（2）Underlay 与 Overlay 网络

Underlay 网络模式: 底层承载网络，是网络通信的根底。

• 劣势：复用基建，网络扁平，性能劣势。
• 劣势：合作简单，平安问题，治理老本。

很多场景下业务方心愿容器、物理机和虚拟机能够在同一个扁平面中间接通过 IP 进行通信，通过 Floating-IP 网络实现。

Floating-IP 模式将宿主机网络同一网段的 IP 间接配置到容器中。

这种模式为了保障容器与宿主机的交换机二层连通，须要在物理机上搭一个虚构网桥。

具体抉择哪种网桥，支流有：Linux bridge、MacVlan、SRIOV 三种模式。

• BridgeBridge：设施内核最早实现的网桥，性能与 OVS 相当，能够应用到所有场景。

• MacVlan：一个简化版的 bridge 设施，为了隔离须要内核，实现时不容许 MacVlan 容器拜访其宿主机 IP 和 Service Cluster IP。

• SR-IOV 技术：一种基于硬件的虚拟化解决方案，可进步性能和可伸缩性。

SR-IOV 规范容许在虚拟机之间高效共享 PCIe（疾速外设组件互连）设施，并且它是在硬件中实现的，能够取得可能与本机性能媲美的 I/O 性能。

Overlay 网络：是一种建设在另一网络之上的计算机网络。

• 劣势：独立自治，疾速扩大，网络策略。
• 劣势：简单层级，性能损失，定制老本。

Kubernetes 相当于云原生的操作系统。

有人会问，凭什么云原生的操作系统这杆大旗？

次要起因是：Kubernetes 解决了一个分布式操作系统最外围的计算、存储、网络三种资源。

CNI 容器网络统一标准

1. CNCF 我的项目，为 Linux 容器提供配置网络接口的规范和以该规范扩大插件提供根底函数库。
2. CNI 命令行调用标准，其插件在主机上间接切换进入容器网络命名空间，为容器创立网络设备，配置 IP，路由信息。

CNI 标准内容：

1. 输出：ADD/DEL 控制指令，CNI 目录，容器 ID，网络命名空间，网卡名称。
2. 配置文件：规范局部：cniVersion，Name，Type，IPAM。
3. 输入：设施列表、IP 资源列表、DNS 信息。

插件利用如：

1. Bridge：Linux 网桥 CNI 实现，采纳网卡对链接网桥和容器。
2. Host-device：将主机设施间接挪动到容器命名空间中。
3. PTP：创立虚构网卡对，采纳路由形式实现对外互联。
4. MacVlan：网卡多 Mac 地址虚构技术残缺反对 vlan。
5. Vlan：Vlan 设施 CNI 实现，容许容器和主机分属不同 LAN。
6. IPVlan：网卡上基于 IP 实现流量转发。

（3）Overlay 网络 -Flannel 计划

CoreOS（被 Red Hat 收买）为 Kubernetes 专门定制设计的 overlay 网络计划。

03 层网络计划实现：在每台主机部署 flanneld 过程实现网段调配，路由管制，采纳多种转发机制实现流量跨机交互。

Flannel 职责：

1. 子网治理：每个主机调配惟一的子网。
2. 互联形式：为同 Overlay 立体容器调配惟一 IP。

Etcd 存储：容器之间路由映射。

SubNetManager：子网资源划分、IP 资源申请开释的接口定义。

Backend：针对网络互联形式的接口定义。

1. UDP，UDP 封包转发，倡议仅调试应用。
2. VxLAN(倡议)，应用内核 vxlan 个性实现封包转发。
3. Host-GW，主机 2 层互联状况下较高性能互联形式。
4. IPIP，应用 IPIP 隧道实现封包和转发。
5. IPSec，应用 IPSecurity 实现加密封包转发。
6. AliVPC，对接阿里云 VPC 路由表实现网络互联。
7. AWSVPC，对接 Amazon VPC 路由表实现网络互联。

Flannel 的单机互联计划：

子网调配：充当虚构交换机 / 网关角色，连贯所有本机容器，实现虚构子网构建。

Bridge：通过 NAT 借助主机网络实现内部服务拜访。

Veth pair：一端设置到容器网络 namespace，一端链接 bridge 实现容器接入网络。

对外拜访：为每个节点调配独立不抵触的 24 位子网。

Overlay 解决方案：跨 Node 的 Pod 之间通信通过 Node 之间的 Overlay 隧道。

职责：路由管制，数据转发。

次要流程：

• 本节点设置：设施创立、本地路由创立、回写本地信息。
• 监听其余节点信息：更新 ARP 信息、更新 FDB、更新路由信息。

（4）Overlay 网络 -Calico 计划

Calico 我的项目：是纯三层的虚构网络解决方案，旨在简化、扩大和爱护云网络的容器计划。

Calico 劣势：

• 可扩展性：采纳 IP 路由反对大规模网络。扩大便当，容错性高。
• 网络安全：反对 Kubernetes 网络策略，反对自定义网络策略。
• 宽泛集成：集成 Kubernetes，Mesos，反对 OpenStack，AWS，GCE，Azure。

Calico 有余：

• BGP 反对问题：须要网路设施反对 BGP 协定，否则须要追加 IPIP 隧道。
• 布局 2 层直连：须要节点做良好的布局实现 2 层网络间接互联。
• 大规模配置简单：网络布局，手动部署 Route Reflector，减少 API 代理。

要害组件：

• BGP Client：和其余节点互联，公布以后节点路由并学习其余节点路由。
• Confd：同步节点配置信息启动 BGPClient。
• Felix：负责虚构设施监控，ACL 管制、状态同步的 agent。
• Calico：CNI 插件，负责容器设施创立。
• Calico-IPAM：CNI 插件，负责容器网段治理与 IP 地址治理。
• RouteReflector：对接 BGPclient 实现路由直达。
• Etcd/Kube-apiserver：Calico 数据存储。
• typha：应答大规模节点接入时作为数据缓存 proxy。
• RouteReflector 装置：集群超过 100 个节点时强烈建议启用，通过 RR 直达全局路由信息。

Calico 单机互联计划：

• Veth-pair：一端设置到容器，一端搁置在主机上，为容器提供网络出入口。
• 路由策略：针对 IP 和设施设置路由条目，在主机上实现互联。

Calico 跨机互联计划：

• 同网段 /BGP 反对：主机之间通过 2 层直连或者网络反对路由转发至指标主机。
• 跨网段 IPIP 互联：网络设备不反对 BGP 协定状况下，采纳 IPIP 隧道实现跨网段互联。
• 跨网段 VxLAN 互联（Cannel）：集成 flannel，底层通过 VxLAN 实现跨机转发。

服务网格 Istio

（一）服务网格概述

（二）Istio 管制面

（三）Istio 数据面

云原生 - 支流组件

（一）Prometheus

（二）Grafana

（三）Elasticsearch + Fluentd + Kibana

（四）Jaeger

（五）Chaos Engineering

云原生 - 罕用网络技术

（一）主机网络

iptables 是运行在用户空间的应用软件，通过管制 Linux 内核 netfilter，来管理网络数据包的解决和转发，存在“表（tables）”、“链（chain）”和“规定（rules）”三个层面。

• 每个“表”指的是不同类型的数据包解决流程，例如 filter 表示意进行数据包过滤，而 NAT 表针对连贯进行地址转换操作。

• 每个表中又能够存在多个“链”，零碎依照预订的规定将数据包通过某个内建链，例如将从本机收回的数据通过 OUTPUT 链。

• 在“链”中能够存在若干“规定”，这些规定会被逐个进行匹配，如果匹配，能够执行相应的动作，例如批改数据包，或者跳转。

（二）Underlay 网络技术

VLAN 虚构局域网：是将一个物理 LAN 在逻辑上划分成多个播送域的通信技术。每个 VLAN 是一个播送域，VLAN 内的主机间通信就和在一个 LAN 内一样。

没有划分 VLAN：LAN 局域网：

• 劣势：简略，动态，IP 地址与交换机关联。
• 劣势：迁徙域受限，不能机房内随便迁徙。交换机下 IP 须要提前布局好，束缚虚构比。

划分 VLAN：虚构局域网：

劣势：IP 地址与交换机无关，虚拟机能够在机房范畴内迁徙。

VLAN 间则不能间接互通，这样播送报文就被限度在一个 VLAN 内。

有人会问，替换如何辨别不同 VLAN？

交换机可能分辨不同 VLAN 的报文，须要在报文中增加标识 VLAN 信息的字段。数据帧中的 VID（VLAN ID）字段标识了该数据帧所属的 VLAN，数据帧只能在其所属 VLAN 内进行传输。

（三）Overlay 网络技术

VXLAN 虚构扩大局域网：

• 是对传统 VLAN 协定的一种扩大。
• 是一种网络虚拟化技术，试图改善云计算部署的可扩展性问题。

解决哪些问题？

• vlan 的数量限度（12bit->24bit），VLAN 报文 Header 预留长度只有 12bit，只反对 4096 个终端。
• VNI（VXLAN Network Index）标识某条指定隧道。
• 不扭转 IP 实现服务器迁徙。

传统二三层网络架构限度了虚拟机的动静迁徙范畴。

VXLAN 在两台 TOR 交换机之间建设一条隧道，将服务器收回的原始数据帧加以“包装”，好让原始报文能够在承载网络（比方 IP 网络）上传输。

当达到目标服务器所连贯的 TOR 交换机后，来到 VXLAN 隧道，并将原始数据帧复原进去，持续转发给目标服务器。VXLAN 将整个数据中心根底网络虚构成了一台微小的“二层交换机”。

VXLAN 网络模型

• UDP 封装（L2 over L4）：将 L2 的以太帧封装到 UDP 报文即（L2overL4）中，并在 L3 网络中传输。
• VTEP，VXLAN 隧道端点，对 VXLAN 报文进行封装和解封装。
• VNI，VXLAN 隧道标识，用于辨别不同 VXLAN 隧道。

• 矢量性协定：应用基于门路、网络策略或规定集来决定路由。

• AS（自治域）：AS 是指在一个实体管辖下的领有雷同选路策略的 IP 网络。

BGP 网络中的每个 AS 都被调配一个惟一的 AS 号，用于辨别不同的 AS。

• eBGP（域外 BGP）：运行于不同 AS 之间的 BGP，为了避免 AS 间产生环路。为了避免 AS 间产生环路，当 BGP 设施接管 EBGP 对等体发送的路由时，会将带有本地 AS 号的路由抛弃。

• iBGP（域内 BGP）：运行于同一 AS 外部的 BGP，为了避免 AS 内产生环路。

• RR（路由反射器）：通过集中反射同步，解决全连通的网状网格构造路由同步问题。

EBGP+IBGP 实现 AS 间的路由传递：一个常见的 IP 骨干网的拓扑构造，骨干层和汇聚层别离是两个自治零碎，AS100 有两个进口设施 SwitchC 和 SwitchD，两个 AS 之间须要进行路由互通。

总结 - 云原生

云原生利用：docker 利用打包、公布、运行，Kubernetes 服务部署和集群治理，Istio 构建服务治理能力。

云计算以“资源”为核心，关键技术：

• 虚拟化：SDX，NFV。
• 资源池化：弹性疾速扩缩容。
• 多租化：晋升云厂商的资源利用率。

典型代表：计算、网络、存储三大基础设施的云化。

云计算以“利用”为核心，要害导向：

• 设计之初，关注更好适应云，充分发挥云劣势。
• 云原生已成为企业数字翻新的最短门路。
• 云原生一系列 IAAS、PAAS、SAAS 层技术，撑持产品高效交付、稳固运维、继续经营。

【私人观点】

• 以“资源”为核心的云，将成为“底层基础设施”，利用云原生以“利用”为核心赋能本身业务。
• 云的时代，曾经降临。作为云的使用者、从业者，更多思考如何利用云赋能业务产品。
• 商业市场模式从“大鱼吃小鱼”靠信息不对称，向“快鱼吃慢鱼”转变。咱们必须利用趋势，拥抱云原生。