profile
viewpoint

YuPengZTE/awesome-go 0

A curated list of awesome Go frameworks, libraries and software

YuPengZTE/cadvisor 0

Analyzes resource usage and performance characteristics of running containers.

YuPengZTE/cloud-native-sandbox 0

Cloud Native Sandbox can help you setup a standalone Kubernetes and Istio environment with Docker on you own laptop.

YuPengZTE/cni 0

Container Network Interface - networking for Linux containers

YuPengZTE/community 0

Kubernetes community content

YuPengZTE/compose 0

Define and run multi-container applications with Docker

YuPengZTE/container-engine-accelerators 0

Collection of tools and examples for managing Accelerated workloads in Kubernetes Engine

YuPengZTE/containerd 0

An open and reliable container runtime

YuPengZTE/distribution 0

The Docker toolset to pack, ship, store, and deliver content

push eventCloudNativeIndustryAlliance/whitepaper2020

Yu Peng

commit sha 83b310ddbad111d310578d7c4ad4d952fbe0a39f

修改笔误 云原声 -> 云原生

view details

push time in 14 days

create barnchCloudNativeIndustryAlliance/whitepaper2020

branch : YuPengZTE-patch-1

created branch time in 17 days

issue commentcntt-n/CNTT

[TSC]Is it in scope of CNTT, Openstack dynamically provides node resources for Kubernetes cluster?

Yes, similar to Kubernetes cloud provider, but this cloud is a private cloud, which is provided by OpenStack.

YuPengZTE

comment created time in 20 days

startedmarktext/marktext

started time in 25 days

Pull request review commentCloudNativeIndustryAlliance/whitepaper2020

big data with cloud

+---+authors: ["yujunwang"]+company: ["腾讯"]+reviewers: [""]+---++### 大数据云原生需求+++  大数据技术,起源于Google,发展于Hadoop。随着Hadoop生态的日益成熟,大数据领域及应用逐渐成长起来。然而,伴随着大数据生态的发展和技术的变革,越来越多的问题也逐渐显露出来。在大数据领域,部署大数据应用遇到的最大挑战之一,是如何应对生产环境中呈指数级增长的在、离线数据量,同时,资源利用率的低下,存算耦合带来的性能瓶颈和扩展问题、居高不下成本问题、任务之间的底层资源依赖问题,随着云原生理念的萌生和优秀实践的落地,越来越成为各大企业关注的重点。++​  借助云原生理念及其生态优势,以上存在的问题将会得以解决。++​  **提高资源利用率。** 通过统一调度平台,将原来分散在各个集群中的业务统一在一个集群中,充分利用长短任务及不同业务的削峰填谷,同时支持在、离线混部,很大程度上提升了集群资源的利用率。++​  **加强应用之间的隔离性。** 云原生提倡容器平台托管应用,借助容器,不仅完美的满足了CPU,内存,网络IO等资源的隔离性要求,还支持一次构建随处运行、易于自动化部署运维等特性,同时解耦了大数据应用和底层平台软件依赖,从而提高了大数据应用的部署效率、降低了运维成本。++​  **完善的弹性扩缩容能力。** 云原生基础架构提供完善的自动横向扩容和纵向扩容,面对大数据应用的突发流量、随机任务和离线任务,可以实时扩容满足生产需要,借助云原生完善的监控体系,实现弹性缩容以降低成本和提高资源利用率。++​  **统一技术栈。** Hadoop的yarn调度和资源管理方案,专为Hadoop生态应用而设计,其功能与当今容器编排领域的事实标准Kubernetes存在重叠,然而Kubernetes不仅可以支持在线业务,在大数据、AI、边缘计算场景都能够支持,对于企业来说,同时维护两套系统和技术栈,无形增加了研发、运维等运维成本。++​  **存储计算分离。** 云原生理念提倡存算分离,在Hadoop体系设计之初,多盘挂载的磁盘支持并行处理,在吞吐量上远胜于网络IO,为了解决网络IO带来的性能瓶颈,Hadoop沿用了Google的存算耦合架构,通过在集群内复制代码而非传输数据这种将数据本地化的机制,以本地IO速度弥补网络IO速度的不足,提高了计算性能,然而时至今日,网络带宽已取得了巨大的进步,曾经的网络IO已不在是系统性能的瓶颈,存算分离将是新的趋势,这种架构具有灵活性高,成本低的优势,同时解决了存算耦合的资源浪费、机型配比更新频繁、扩展难等问题。

已不在是

-> 已不再是

kinderyj

comment created time in 25 days

Pull request review commentCloudNativeIndustryAlliance/whitepaper2020

big data with cloud

+---+authors: ["yujunwang"]+company: ["腾讯"]+reviewers: [""]+---++### 大数据云原生需求+++  大数据技术,起源于Google,发展于Hadoop。随着Hadoop生态的日益成熟,大数据领域及应用逐渐成长起来。然而,伴随着大数据生态的发展和技术的变革,越来越多的问题也逐渐显露出来。在大数据领域,部署大数据应用遇到的最大挑战之一,是如何应对生产环境中呈指数级增长的在、离线数据量,同时,资源利用率的低下,存算耦合带来的性能瓶颈和扩展问题、居高不下成本问题、任务之间的底层资源依赖问题,随着云原生理念的萌生和优秀实践的落地,越来越成为各大企业关注的重点。++​  借助云原生理念及其生态优势,以上存在的问题将会得以解决。++​  **提高资源利用率。** 通过统一调度平台,将原来分散在各个集群中的业务统一在一个集群中,充分利用长短任务及不同业务的削峰填谷,同时支持在、离线混部,很大程度上提升了集群资源的利用率。++​  **加强应用之间的隔离性。** 云原生提倡容器平台托管应用,借助容器,不仅完美的满足了CPU,内存,网络IO等资源的隔离性要求,还支持一次构建随处运行、易于自动化部署运维等特性,同时解耦了大数据应用和底层平台软件依赖,从而提高了大数据应用的部署效率、降低了运维成本。++​  **完善的弹性扩缩容能力。** 云原生基础架构提供完善的自动横向扩容和纵向扩容,面对大数据应用的突发流量、随机任务和离线任务,可以实时扩容满足生产需要,借助云原生完善的监控体系,实现弹性缩容以降低成本和提高资源利用率。++​  **统一技术栈。** Hadoop的yarn调度和资源管理方案,专为Hadoop生态应用而设计,其功能与当今容器编排领域的事实标准Kubernetes存在重叠,然而Kubernetes不仅可以支持在线业务,在大数据、AI、边缘计算场景都能够支持,对于企业来说,同时维护两套系统和技术栈,无形增加了研发、运维等运维成本。

这个小节提出了问题,是否能把隐含的意思表述出来? 例如 yarn 的调度和 Kubernetes 的调度统一到 XXX ?

kinderyj

comment created time in 25 days

Pull request review commentCloudNativeIndustryAlliance/whitepaper2020

big data with cloud

+---+authors: ["yujunwang"]+company: ["腾讯"]+reviewers: [""]+---++### 大数据云原生需求+++  大数据技术,起源于Google,发展于Hadoop。随着Hadoop生态的日益成熟,大数据领域及应用逐渐成长起来。然而,伴随着大数据生态的发展和技术的变革,越来越多的问题也逐渐显露出来。在大数据领域,部署大数据应用遇到的最大挑战之一,是如何应对生产环境中呈指数级增长的在、离线数据量,同时,资源利用率的低下,存算耦合带来的性能瓶颈和扩展问题、居高不下成本问题、任务之间的底层资源依赖问题,随着云原生理念的萌生和优秀实践的落地,越来越成为各大企业关注的重点。++​  借助云原生理念及其生态优势,以上存在的问题将会得以解决。++​  **提高资源利用率。** 通过统一调度平台,将原来分散在各个集群中的业务统一在一个集群中,充分利用长短任务及不同业务的削峰填谷,同时支持在、离线混部,很大程度上提升了集群资源的利用率。++​  **加强应用之间的隔离性。** 云原生提倡容器平台托管应用,借助容器,不仅完美的满足了CPU,内存,网络IO等资源的隔离性要求,还支持一次构建随处运行、易于自动化部署运维等特性,同时解耦了大数据应用和底层平台软件依赖,从而提高了大数据应用的部署效率、降低了运维成本。

借助容器,不仅完美的满足了CPU,内存,网络IO等资源的隔离性要求

容器提供的资源隔离性,并不好,这个措辞是否需要改改?

kinderyj

comment created time in 25 days

Pull request review commentCloudNativeIndustryAlliance/whitepaper2020

云原生网络部分更新

 ----authors: [""]-company: ["华为"]-reviewers: [""]+authors: ["赵华、方佳伟"]+company: ["华为、谐云"]+reviewers: ["刘如明"] --- -云原生网络的基本目标是满足云原生服务的网络端点(容器)和服务间的互通性、安全性和负载均衡要求。随着云原生的普及,服务端点(容器)的规模快速增长(十万甚至百万),互访场景越来越丰富,比如:跨集群、跨VPC、混合云互访等,这要求容器端点具有与宿主节点(虚机)相同的互通能力,VPC-Native的容器网络已经成为趋势,容器成为VPC中的一等公民,容器(POD)和服务(ClusterIP)具有独立VPC的 子网地址,甚至具有独立的直通网口(如:ENI),这样在获得更高转发性能、更低损耗的同时,具有了更好的隔离性,通过在容器挂接的网口配置安全组规则,能够实现容器级别的微分段network policy。当然,这给vpc网络的支持的网口规模(10w+)和发放速度(秒级)提出了的挑战。另外,以GKE为代表的厂商,推出container-native的分布式负载均衡,将云原生业务的东西向负载均衡能力下沉到VPC网络中,消除了原来节点内iptables/ipvs占用的内存和计算开销,具有更好的资源效率,相信这也会成为未来的趋势。\ No newline at end of file+云原生网络的基本目标是满足云原生服务的网络端点(容器)和服务间的互通性、安全性和负载均衡要求。Kubernetes已经成为容器编排的事实标准,容器网络也需与Kubernetes的调度机制相匹配。容器网络接口CNI(Conteinre Network Interface)是现行的网络接口标准, CNI接口只实现创建、删除容器时的调用方法,其他所有的网络能力都交给网络厂商去增值。这在一定程度上加速了网络方案的繁荣,但是给用户的方案选型造成了较大困扰。大部分的用户场景都是基于网络的通讯协议进行方案选择,根据网络协议的不同,可将网络方案分为路由模式、Overlay和L2方案三种。++null|路由模式|Overlay模式|L2模式+:-:|:-|:-|:-+优势|*网络性能高<br>*支持Kubernetes原生负载均衡和网络策略机制<br>*符合传统网络的监管要求|*物理网络无侵入<br>*支持Kubernetes原生负载均衡和网络策略机制|*网络性能高<br>*可直接月IaaS层网络通信,易于迁移<br>*符合传统的监管需求+缺点|*大规模应用场景需要交换机与BGP打通|*存在封装影响性能<br>*排查问题难,需引入额外排查工具<br>*无法与传统的网络监管模式兼容|*网络管理依赖于物理网络<br>*大部分方案无法复用Kubernetes的网络优势求+可选方案|*Calico BGP<br>*Flannel Host Gateway<br>*Kube-router<br>*Contiv BGP|*Calico IPIP,VXLAN<br>*Flannel VXLAN, UDP<br>*WEAVE<br>*Canal<br>*SDN方案|*Lunix Bridge<br>*Macvlan<br>*SRIOV<br>*OVS Bridge<br>*Contiv Vlan<br>*Ovn-kubernetes++自CNI标准发布到2020年,云原生网络已经演进近6年时间。也积累了大量的用户落地案例和大规模的实践案例。未来对于云原生网络的演进,依旧会在用户落地场景方向上深度演进。总结起来主要是以下几个趋势:+- **互访场景需求加速容器网络与主机网络互通**。+随着云原生的普及,服务端点(容器)的规模快速增长(十万甚至百万),互访场景越来越丰富,比如:跨集群、跨VPC、混合云互访等,这要求容器端点具有与宿主节点(虚机)相同的互通能力,VPC-Native的容器网络已经成为趋势,容器成为VPC中的一等公民,容器(POD)和服务(ClusterIP)具有独立VPC的子网地址,甚至具有独立的直通网口(如:ENI),这样在获得更高转发性能、更低损耗的同时,具有了更好的隔离性,通过在容器挂接的网口配置安全组规则,能够实现容器级别的微分段network policy。当然,这给vpc网络的支持的网口规模(10w+)和发放速度(秒级)提出了的挑战。另外,以GKE为代表的厂商,推出container-native的分布式负载均衡,将云原生业务的东西向负载均衡能力下沉到VPC网络中,消除了原来节点内iptables/ipvs占用的内存和计算开销,具有更好的资源效率,相信这也会成为未来的趋势。++- **云原生网络方案将聚焦解决特定场景的问题**。+平台的安全问题在所有的平台演进和建设过程中一直扮演着非常重要,但是不十分紧急的角色。因此,在容器安全建设上,大部分组织都是采取防守和被动姿态。但是本身在近几年陆续爆出大量的基于容器平台的安全隐患以及在工信部和网信办联合组织的“护网行动”的大背景之下,容器安全已经成为云原生底座无法绕开的一个问题。 容器网络安全则在整个底座安全里面扮演了非常重要的角色,因此也将成为之后的CNI网络演进的方向和趋势。++- **网络安全将成为云原生技术底座的重要组成部分**。+平台的安全问题在所有的平台演进和建设过程中一直扮演着非常重要,但是不十分紧急的角色。因此,在容器安全建设上,大部分组织都是采取防守和被动姿态。但是本身在近几年陆续爆出大量的基于容器平台的安全隐患以及在工信部和网信办联合组织的“护网行动”的大背景之下,容器安全已经成为云原生底座无法绕开的一个问题。 容器网络安全则在整个底座安全里面扮演了非常重要的角色,因此也将成为之后的CNI网络演进的方向和趋势。

和上面小节的内容重复

torresvskaka

comment created time in 25 days

Pull request review commentCloudNativeIndustryAlliance/whitepaper2020

云原生网络部分更新

 ----authors: [""]-company: ["华为"]-reviewers: [""]+authors: ["赵华、方佳伟"]+company: ["华为、谐云"]+reviewers: ["刘如明"] --- -云原生网络的基本目标是满足云原生服务的网络端点(容器)和服务间的互通性、安全性和负载均衡要求。随着云原生的普及,服务端点(容器)的规模快速增长(十万甚至百万),互访场景越来越丰富,比如:跨集群、跨VPC、混合云互访等,这要求容器端点具有与宿主节点(虚机)相同的互通能力,VPC-Native的容器网络已经成为趋势,容器成为VPC中的一等公民,容器(POD)和服务(ClusterIP)具有独立VPC的 子网地址,甚至具有独立的直通网口(如:ENI),这样在获得更高转发性能、更低损耗的同时,具有了更好的隔离性,通过在容器挂接的网口配置安全组规则,能够实现容器级别的微分段network policy。当然,这给vpc网络的支持的网口规模(10w+)和发放速度(秒级)提出了的挑战。另外,以GKE为代表的厂商,推出container-native的分布式负载均衡,将云原生业务的东西向负载均衡能力下沉到VPC网络中,消除了原来节点内iptables/ipvs占用的内存和计算开销,具有更好的资源效率,相信这也会成为未来的趋势。\ No newline at end of file+云原生网络的基本目标是满足云原生服务的网络端点(容器)和服务间的互通性、安全性和负载均衡要求。Kubernetes已经成为容器编排的事实标准,容器网络也需与Kubernetes的调度机制相匹配。容器网络接口CNI(Conteinre Network Interface)是现行的网络接口标准, CNI接口只实现创建、删除容器时的调用方法,其他所有的网络能力都交给网络厂商去增值。这在一定程度上加速了网络方案的繁荣,但是给用户的方案选型造成了较大困扰。大部分的用户场景都是基于网络的通讯协议进行方案选择,根据网络协议的不同,可将网络方案分为路由模式、Overlay和L2方案三种。++null|路由模式|Overlay模式|L2模式+:-:|:-|:-|:-+优势|*网络性能高<br>*支持Kubernetes原生负载均衡和网络策略机制<br>*符合传统网络的监管要求|*物理网络无侵入<br>*支持Kubernetes原生负载均衡和网络策略机制|*网络性能高<br>*可直接月IaaS层网络通信,易于迁移<br>*符合传统的监管需求+缺点|*大规模应用场景需要交换机与BGP打通|*存在封装影响性能<br>*排查问题难,需引入额外排查工具<br>*无法与传统的网络监管模式兼容|*网络管理依赖于物理网络<br>*大部分方案无法复用Kubernetes的网络优势求+可选方案|*Calico BGP<br>*Flannel Host Gateway<br>*Kube-router<br>*Contiv BGP|*Calico IPIP,VXLAN<br>*Flannel VXLAN, UDP<br>*WEAVE<br>*Canal<br>*SDN方案|*Lunix Bridge<br>*Macvlan<br>*SRIOV<br>*OVS Bridge<br>*Contiv Vlan<br>*Ovn-kubernetes

是不是有更多的方案? 例如multus

torresvskaka

comment created time in 25 days

Pull request review commentCloudNativeIndustryAlliance/whitepaper2020

云原生网络部分更新

 ----authors: [""]-company: ["华为"]-reviewers: [""]+authors: ["赵华、方佳伟"]+company: ["华为、谐云"]+reviewers: ["刘如明"] --- -云原生网络的基本目标是满足云原生服务的网络端点(容器)和服务间的互通性、安全性和负载均衡要求。随着云原生的普及,服务端点(容器)的规模快速增长(十万甚至百万),互访场景越来越丰富,比如:跨集群、跨VPC、混合云互访等,这要求容器端点具有与宿主节点(虚机)相同的互通能力,VPC-Native的容器网络已经成为趋势,容器成为VPC中的一等公民,容器(POD)和服务(ClusterIP)具有独立VPC的 子网地址,甚至具有独立的直通网口(如:ENI),这样在获得更高转发性能、更低损耗的同时,具有了更好的隔离性,通过在容器挂接的网口配置安全组规则,能够实现容器级别的微分段network policy。当然,这给vpc网络的支持的网口规模(10w+)和发放速度(秒级)提出了的挑战。另外,以GKE为代表的厂商,推出container-native的分布式负载均衡,将云原生业务的东西向负载均衡能力下沉到VPC网络中,消除了原来节点内iptables/ipvs占用的内存和计算开销,具有更好的资源效率,相信这也会成为未来的趋势。\ No newline at end of file+云原生网络的基本目标是满足云原生服务的网络端点(容器)和服务间的互通性、安全性和负载均衡要求。Kubernetes已经成为容器编排的事实标准,容器网络也需与Kubernetes的调度机制相匹配。容器网络接口CNI(Conteinre Network Interface)是现行的网络接口标准, CNI接口只实现创建、删除容器时的调用方法,其他所有的网络能力都交给网络厂商去增值。这在一定程度上加速了网络方案的繁荣,但是给用户的方案选型造成了较大困扰。大部分的用户场景都是基于网络的通讯协议进行方案选择,根据网络协议的不同,可将网络方案分为路由模式、Overlay和L2方案三种。++null|路由模式|Overlay模式|L2模式+:-:|:-|:-|:-+优势|*网络性能高<br>*支持Kubernetes原生负载均衡和网络策略机制<br>*符合传统网络的监管要求|*物理网络无侵入<br>*支持Kubernetes原生负载均衡和网络策略机制|*网络性能高<br>*可直接月IaaS层网络通信,易于迁移<br>*符合传统的监管需求

可直接月IaaS层网络通信,易于迁移

“月“字是笔误吧?

torresvskaka

comment created time in 25 days

Pull request review commentCloudNativeIndustryAlliance/whitepaper2020

云原生网络部分更新

 ----authors: [""]-company: ["华为"]-reviewers: [""]+authors: ["赵华、方佳伟"]+company: ["华为、谐云"]+reviewers: ["刘如明"] --- -云原生网络的基本目标是满足云原生服务的网络端点(容器)和服务间的互通性、安全性和负载均衡要求。随着云原生的普及,服务端点(容器)的规模快速增长(十万甚至百万),互访场景越来越丰富,比如:跨集群、跨VPC、混合云互访等,这要求容器端点具有与宿主节点(虚机)相同的互通能力,VPC-Native的容器网络已经成为趋势,容器成为VPC中的一等公民,容器(POD)和服务(ClusterIP)具有独立VPC的 子网地址,甚至具有独立的直通网口(如:ENI),这样在获得更高转发性能、更低损耗的同时,具有了更好的隔离性,通过在容器挂接的网口配置安全组规则,能够实现容器级别的微分段network policy。当然,这给vpc网络的支持的网口规模(10w+)和发放速度(秒级)提出了的挑战。另外,以GKE为代表的厂商,推出container-native的分布式负载均衡,将云原生业务的东西向负载均衡能力下沉到VPC网络中,消除了原来节点内iptables/ipvs占用的内存和计算开销,具有更好的资源效率,相信这也会成为未来的趋势。\ No newline at end of file+云原生网络的基本目标是满足云原生服务的网络端点(容器)和服务间的互通性、安全性和负载均衡要求。Kubernetes已经成为容器编排的事实标准,容器网络也需与Kubernetes的调度机制相匹配。容器网络接口CNI(Conteinre Network Interface)是现行的网络接口标准, CNI接口只实现创建、删除容器时的调用方法,其他所有的网络能力都交给网络厂商去增值。这在一定程度上加速了网络方案的繁荣,但是给用户的方案选型造成了较大困扰。大部分的用户场景都是基于网络的通讯协议进行方案选择,根据网络协议的不同,可将网络方案分为路由模式、Overlay和L2方案三种。++null|路由模式|Overlay模式|L2模式+:-:|:-|:-|:-+优势|*网络性能高<br>*支持Kubernetes原生负载均衡和网络策略机制<br>*符合传统网络的监管要求|*物理网络无侵入<br>*支持Kubernetes原生负载均衡和网络策略机制|*网络性能高<br>*可直接月IaaS层网络通信,易于迁移<br>*符合传统的监管需求+缺点|*大规模应用场景需要交换机与BGP打通|*存在封装影响性能<br>*排查问题难,需引入额外排查工具<br>*无法与传统的网络监管模式兼容|*网络管理依赖于物理网络<br>*大部分方案无法复用Kubernetes的网络优势求+可选方案|*Calico BGP<br>*Flannel Host Gateway<br>*Kube-router<br>*Contiv BGP|*Calico IPIP,VXLAN<br>*Flannel VXLAN, UDP<br>*WEAVE<br>*Canal<br>*SDN方案|*Lunix Bridge<br>*Macvlan<br>*SRIOV<br>*OVS Bridge<br>*Contiv Vlan<br>*Ovn-kubernetes++自CNI标准发布到2020年,云原生网络已经演进近6年时间。也积累了大量的用户落地案例和大规模的实践案例。未来对于云原生网络的演进,依旧会在用户落地场景方向上深度演进。总结起来主要是以下几个趋势:+- **互访场景需求加速容器网络与主机网络互通**。+随着云原生的普及,服务端点(容器)的规模快速增长(十万甚至百万),互访场景越来越丰富,比如:跨集群、跨VPC、混合云互访等,这要求容器端点具有与宿主节点(虚机)相同的互通能力,VPC-Native的容器网络已经成为趋势,容器成为VPC中的一等公民,容器(POD)和服务(ClusterIP)具有独立VPC的子网地址,甚至具有独立的直通网口(如:ENI),这样在获得更高转发性能、更低损耗的同时,具有了更好的隔离性,通过在容器挂接的网口配置安全组规则,能够实现容器级别的微分段network policy。当然,这给vpc网络的支持的网口规模(10w+)和发放速度(秒级)提出了的挑战。另外,以GKE为代表的厂商,推出container-native的分布式负载均衡,将云原生业务的东西向负载均衡能力下沉到VPC网络中,消除了原来节点内iptables/ipvs占用的内存和计算开销,具有更好的资源效率,相信这也会成为未来的趋势。

VPC-Native的容器网络已经成为趋势 这一点是否需要提供论据再论证一下? 或者先不提?

torresvskaka

comment created time in 25 days

Pull request review commentCloudNativeIndustryAlliance/whitepaper2020

云原生网络部分更新

 ----authors: [""]-company: ["华为"]-reviewers: [""]+authors: ["赵华、方佳伟"]+company: ["华为、谐云"]+reviewers: ["刘如明"] --- -云原生网络的基本目标是满足云原生服务的网络端点(容器)和服务间的互通性、安全性和负载均衡要求。随着云原生的普及,服务端点(容器)的规模快速增长(十万甚至百万),互访场景越来越丰富,比如:跨集群、跨VPC、混合云互访等,这要求容器端点具有与宿主节点(虚机)相同的互通能力,VPC-Native的容器网络已经成为趋势,容器成为VPC中的一等公民,容器(POD)和服务(ClusterIP)具有独立VPC的 子网地址,甚至具有独立的直通网口(如:ENI),这样在获得更高转发性能、更低损耗的同时,具有了更好的隔离性,通过在容器挂接的网口配置安全组规则,能够实现容器级别的微分段network policy。当然,这给vpc网络的支持的网口规模(10w+)和发放速度(秒级)提出了的挑战。另外,以GKE为代表的厂商,推出container-native的分布式负载均衡,将云原生业务的东西向负载均衡能力下沉到VPC网络中,消除了原来节点内iptables/ipvs占用的内存和计算开销,具有更好的资源效率,相信这也会成为未来的趋势。\ No newline at end of file+云原生网络的基本目标是满足云原生服务的网络端点(容器)和服务间的互通性、安全性和负载均衡要求。Kubernetes已经成为容器编排的事实标准,容器网络也需与Kubernetes的调度机制相匹配。容器网络接口CNI(Conteinre Network Interface)是现行的网络接口标准, CNI接口只实现创建、删除容器时的调用方法,其他所有的网络能力都交给网络厂商去增值。这在一定程度上加速了网络方案的繁荣,但是给用户的方案选型造成了较大困扰。大部分的用户场景都是基于网络的通讯协议进行方案选择,根据网络协议的不同,可将网络方案分为路由模式、Overlay和L2方案三种。++null|路由模式|Overlay模式|L2模式+:-:|:-|:-|:-+优势|*网络性能高<br>*支持Kubernetes原生负载均衡和网络策略机制<br>*符合传统网络的监管要求|*物理网络无侵入<br>*支持Kubernetes原生负载均衡和网络策略机制|*网络性能高<br>*可直接月IaaS层网络通信,易于迁移<br>*符合传统的监管需求+缺点|*大规模应用场景需要交换机与BGP打通|*存在封装影响性能<br>*排查问题难,需引入额外排查工具<br>*无法与传统的网络监管模式兼容|*网络管理依赖于物理网络<br>*大部分方案无法复用Kubernetes的网络优势求

“求“字是笔误吧?

torresvskaka

comment created time in 25 days

fork YuPengZTE/whitepaper2020

中国信息通信研究院(CAICT)云原生产业白皮书(2020)编写

fork in a month

issue openedcntt-n/CNTT

[RA-2] Remove containerised in RA-2

It is better to replace "containerised" with "cloud native" in RA-2?

created time in 2 months

startedmindspore-ai/mindspore

started time in 3 months

startedkubeflow/arena

started time in 3 months

startedmindspore-ai/ms-operator

started time in 3 months

Pull request review commentcntt-n/CNTT

[RM Ch07]: Change NFVI to cloud infra

 <a name="7.1"></a> ## 7.1 Introduction -This document includes process flow, logistics, and requirements which must be satisfied to ensure Virtualized Network Functions (VNFs) meet the design, feature, and capability expectations of VNF consumers to deliver NFV promoting the use and scalability of SDN capabilities. This chapter captures the core fundamentals and steps needed to certify VNFs on target NFVi frameworks and architectures which drives more work into the community, resulting in pre-certified VNFs on core capabilities ultimately reducing the amount of time and cost it takes each operator to on-board and maintain vendor provided VNFs.+This document includes process flow, logistics, and requirements which must be satisfied to ensure workloads meet the design, feature, and capability expectations of workload consumers to deliver cloud promoting the use and scalability of SDN capabilities. This chapter captures the core fundamentals and steps needed to conformance test workloads on target Cloud Infrastructure frameworks and architectures which drives more work into the community, resulting in pre-certified workloads on core capabilities ultimately reducing the amount of time and cost it takes each operator to on-board and maintain vendor provided workloads.  <p align="center"><img src="../figures/ch10_ref_model_lfn.png" alt="scope" title="Scope" width="100%"/></p> <p align="center"><b>Figure 8-1:</b> CNTT relation to LFN OVP</p>

Figure 8-1 -> Figure 7-1

CsatariGergely

comment created time in 3 months

more