阿里云边缘容器服务ACK@Edge 通过33项测评，拿到“2021云边协同能力认证”
基于 ACK@Edge 实现的申通快递 IoT 云边端架构，入选“2021 分布式云与云边协同十佳实践案例”。
埃森哲携手阿里云，采用K8s容器云服务为客户提供无限弹性
埃森哲作为全球领先的专业服务公司，在数字化、云计算等领域拥有全球领先的能力，我们在多年的实际客户项目中，找到并沉淀出了适合企业数字化转型的方法论，积累了丰富的落地经验。
Flagger on ASM——基于Mixerless Telemetry实现渐进式灰度发布系列 3 渐进式灰度发布
作为CNCF[成员](https://landscape.cncf.io/card-mode?category=continuous-integration-delivery&grouping=category&selected=weave-flagger)，[Weave Flagger](flagger.app)提供了持续集成和持续交付的各项能力。Flagger将渐进式发布总结为3类： - **灰度发布/金丝雀发布(Canary)**：用于渐进式切流到灰度版本(progressive traffic shifting) - **A/B测试(A/B Testing)**：用于根据请求信息将
Flagger on ASM·基于Mixerless Telemetry实现渐进式灰度发布系列 1 遥测数据
服务网格ASM的Mixerless Telemetry技术，为业务容器提供了无侵入式的遥测数据。遥测数据一方面作为监控指标被ARMPS/prometheus采集，用于服务网格可观测性；另一方面被HPA和flaggers使用，成为应用级扩缩容和渐进式灰度发布的基石。 本系列聚焦于遥测数据在应用级扩缩容和渐进式灰度发布上的实践，将分三篇介绍遥测数据(监控指标)、应用级扩缩容，和渐进式灰度发布。
自建Kubernetes集群如何使用弹性容器实例ECI
虚拟节点（Virtual Node）实现了Kubernetes与弹性容器实例ECI的无缝连接，让Kubernetes集群轻松获得极大的弹性能力，而不必受限于集群的节点计算容量。您可以灵活动态的按需创建ECI Pod，免去集群容量规划的麻烦。本文主要介绍虚拟节点和ECI，通过ack-virtual-node组件如何部署虚拟节点及如何创建ECI Pod。
Knative 多容器支持介绍
微服务和容器化带来了将应用程序分解成可重复使用的小型单元的诉求，这些单元通常作为单独的进程运行，或者在单独的容器运行。 Kubernetes的Pod模型允许用户创建一个部署单元，该单元可以打包多个容器作为应用程序的单个实例。 Knative 用户当前同样存在将多个容器部署到一个Pod中对诉求。支持多个容器的能力将有利于把更广泛的工作负载部署到Knative Serving模型中。因此 Knative 从 0.16.0 版本开始提供多个容器的能力。
Knative基于Header进行流量灰度验证
在 Knative 可以基于流量比例进行灰度发布，但有时候我们需要将确切的请求灰度到指定的版本上进行验证，在 Knative 0.18 版本并结合Kourier网关可以实现基于Header的灰度验证。
基于WASM的无侵入式全链路A/B Test实践
我们都知道，服务网格(ServiceMesh)可以为运行其上的微服务提供无侵入式的流量治理能力。通过配置VirtualService和DestinationRule，即可实现流量管理、超时重试、流量复制、限流、熔断等功能，而无需修改微服务代码。 本文所述的实践是根据请求Header实现全链路A/B测试。
Knative: 基于流量的灰度发布和自动弹性实践
作为 Severless Framework 就离不开按需分配资源的能力，Knative 提供了基于流量的自动扩缩容能力，可以根据应用的请求量在高峰时期自动扩容实例数，当请求量减少以后自动缩容实例数，做到自动化的帮助您节省成本。此外 Knative 还提供了基于流量的灰度发布能力，可以根据流量百分比进行灰度发布。
自定义Deployment粒度的链路追踪标签
本文将介绍使用[阿里云服务网格(ASM)](http://servicemesh.console.aliyun.com/)和[阿里云链路追踪(Tracing)](https://tracing.console.aliyun.com/)，以业务无侵入的方式，实现POD粒度的自定义链路追踪标签。示例代码为[asm-best-practises](https://github.com/feuyeux/asm-best-practises/)
通过ASM入口网关实现HTTP请求网格内GRPC服务
本文将介绍[ASM](http://servicemesh.console.aliyun.com/)入口网关(ingressgateway)支持协议转码的能力，使用户及其客户端可以使用HTTP/JSON访问服务网格内的gRPC服务。
阿里云ACK联合云效助力上海博卡DevOps转型
SaaS公司要在竞争中拔得头筹，就需要快速影响客户需求，同时保持较高的稳定性。同时要快速占领市场，就需要不断推出新产品不断创新，这个时候开发的交付效率以及低成本试错就尤为重要。
解读：云原生下的可观察性发展方向
非常有幸参加了云原生社区Meetup北京站，有机会和众多业内的大牛一起讨论云原生相关的技术和应用，本次Meetup上我和大家分享了关于云原生下的可观察性相关的议题，本篇文章主要是视频的文字性总结，欢迎大家留言讨论。
阿里云容器服务弹性伸缩发布EIP支持助力在线视频与游戏场景
## 背景 疫情期间，在线会议等音视频应用面临大量流量冲击，为了获得更好的网路吞吐性能，常常会选择使用Host网络模型。采用Host网络模型的容器可以直接使用宿主机的IP地址与外界进行通信，若宿主机具有[弹性公网IP](https://help.aliyun.com/document_detail/32321.html)，容器也能使用这个弹性公网IP进行通信。同时容器内服务的端口也可以使用宿
罗辑思维跨年演讲护航案例
在不到三个月的时间内，我们和阿里云PTS团队、阿里云服务团队一共进行了大大小小约七百次的单链路压测、十六轮完整形态全链路压测，压测所耗费的资源相当于一百多万用户一同测试两个多小时，有效保障了跨年活动和日常核心服务的稳定性和健壮性。
从资源管理角度认识 K8S
笔者认为应用开发者为了适应云原生趋势，需要掌握必要的K8S基础知识点，详细介绍在《从应用开发角度认识K8S》： https://developer.aliyun.com/article/778441。
我对云原生软件架构的观察与思考
云原生应用架构的目标是构建松耦合、具备弹性、韧性的分布式应用软件架构，可以更好地应对业务需求的变化和发展，保障系统稳定性。本文将分享我在这个领域的观察和思考。
众安保险云原生之旅：贯通行业数字化转型“快车道”
研发一体化解决方案基于云原生设计，100%兼容其他云原生方案的产品，实现自主可控。应用交付模型基于gitops设计，通过git管理应用声明性配置，将git作为交付流水线核心，使交付模型具备安全，快速，稳定，合规的特性。
SpringCloud 应用在 Kubernetes 上的最佳实践 — 高可用（容量评估）
本篇是《SpringCloud 应用在 Kubernetes 上的最佳实践 》系列内容的第十一篇。
玩转容器持久化存储第七讲 | 实践：Windows 容器环境最佳实践
玩转容器持久化存储第七讲 | 实践：Windows 容器环境最佳实践。操作演示 Windows 容器环境最佳实践，Windows 操作系统也可以使用容器进行快速部署和扩容缩容。NAS SMB 支持 ACK Windows 容器进行持久化共享存储，完美承载Windows 生态各类型容器应用。
再次升级-Kubernetes Ingress监控进入智能时代
Ingress日志记录了Kubernetes集群所有的外部请求信息，是进行集群服务质量监控的最佳方式。目前Ingress日志分析与监控的方案已经发布2年左右，已经有上万的实例使用了该方案。为了适应新时代的DevOps节奏，我们对方案进行整体的升级，提供更加简单、更快速、更普惠、更智能的Ingress日志监控方案
服务网格GRPC协议多种编程语言实践-5.GRPC协议Headers网格实践
在服务网格的流量管理和可观测性实现上，Headers发挥着非常关键的作用。相比而言，HTTP协议的Headers实现较为容易，因为HTTP是同步阻塞式的请求响应模式，可以很容易在GET/POST/UPDATE/DELETE方法中定义和使用读写Header的API。GRPC协议的Headers则要复杂一些，各种编程语言在4种不同通信模型中，读写Header的形式的差异化很大，同时还要考虑流式和异步的编程实现。 本篇首先介绍4种编程语言的Headers编程实践，然后讲述在服务网格实践中，GRPC协议Headers的两个重要实践：流量管理和可观测性。
服务网格GRPC协议多种编程语言实践-4.GRPC协议示例的网格实践
上一篇容器实践的结果是，4个client容器可以访问到服务`grpc-server-svc.grpc-best.svc.cluster.local`，且该服务按负载均衡路由到4个版本的server容器。本篇将以此为基础，进行2个流量管理的实践。
服务网格GRPC协议多种编程语言实践.3.GRPC协议示例的容器实践
本篇使用上一篇分发的镜像，在阿里云容器服务(ACK)上部署。 4个版本的client通过调用变量`GRPC_SERVER`定义的服务`grpc-server-svc.grpc-best.svc.cluster.local`，均匀地路由到4个版本的server上。与此同时，我们通过配置`istio-ingressgateway`的`Gateway`可以将外部请求按负载均衡策略路由到4个版本的grpc server上。
非容器应用与K8s工作负载的服务网格化实践-7 基于ASM的POD和VM可观测性实践
服务网格的可观测性能力是通过Sidecar实现的，对于业务服务源代码来说是近零侵入的。可观测性包括数据采集、数据存储、数据展示和聚合分析。主要有三个维度：Metrics、Logging、Tracing，分别用于可聚合数据、离散事件、请求链路的可观测性。相应地，阿里云生态下，ASM打通了ARMS(https://www.aliyun.com/product/arms)、Log Service(https://www.aliyun.com/product/sls)、TracingAnalysis(https://www.aliyun.com/product/xtrace)，供用户使用服务网格的可观
非容器应用与K8s工作负载的服务网格化实践-6 基于ASM的VM应用动态落迁实践
在完成了POD和VM之间互访验证后，本篇将进入VM中，重点关注两个常用的流量管理能力： - 应用通过标签进行分组 - 每个分组的多个副本可以动态落组和迁出
非容器应用与K8s工作负载的服务网格化实践-5 基于ASM的POD和VM混合流量转移实践
本系列的第一篇展示了WorkloadEntry带来的VM与POD同等负载能力。第二、三篇展示了ASM VM PROXY带来的VM流量转移能力。本篇将结合这两种能力，完整地展示ASM支持非容器应用网格化的流量管理能力。由于篇幅所限，安全相关能力不做展示，但网格化后VM中的应用间、及与POD互访都具备了请求认证和来源认证的能力，再结合RBAC可以完整实现认证和授权。
非容器应用与K8s工作负载的服务网格化实践-4 基于ASM的POD和VM互访实践-GRPC协议篇
为了实现高可用，非容器应用通常有一套服务注册和发现的机制。相对而言，kubernetes容器服务为POD提供了统一的基于dns的注册和发现机制。对于http协议的非容器应用的迁移，因为都是基于dns机制，切换成本交底。而对于使用非http协议的非容器应用，服务注册和发现这个技术点为迁移带来了额外的困难。 如何从非容器的注册和发现大脑最终迁移到kubernetes的注册和发现大脑，目前尚没有广泛认可的方案。目前常见的讨论是双脑方案，就是让非容器应用在启动时同时向两套大脑注册，并从两套中发现依赖服务，然后逐步实现向kubernetes大脑过度。这套方案的优点是可以通过随时摆动来保证可用性。
非容器应用与K8s工作负载的服务网格化实践-3 基于ASM的POD和VM互访实践-HTTP协议篇
非容器应用的网格化需要前一篇讲述的WorkloadEntry配置，同时需要本篇讲述的sidecar配置。前者让kubernetes容器内的POD可以找到VM中的应用，后者让VM中的应用可以找到POD。
非容器应用与K8s工作负载的服务网格化实践-2 基于ASM的Workload Entry实践
Istio从1.6版本开始在流量管理中引入了新的资源类型Workload Entry，用以将虚拟机(VM)或者裸金属(bare metal)进行抽象，使其在网格化后作为与Kubernetes中的POD同等重要的负载，具备流量管理、安全管理、可视化等能力。通过WorkloadEntry可以简化虚拟机/裸金属的网格化配置过程。
C++的顺序容器比较
容器就是特定类型对象的集合，顺序容器（Sequential Container）是一种提供了元素顺序存储访问的数据结构，顺序存储意味着在存储方式上仅仅依赖于先后加入容器的顺序。在 `C++` 的 `STL` 中，提供了 `vector, deque, list, forward_list, array` 这几种容器，当然还有 `string` 也可以视为一种容器，只不过只能存储 `char` 类型的数据。
