Tad 技术杂货铺

引言

在降本增效的行业大环境下，原有业务要面对改造迁移上云的过程。 但云上环境的高动态性、可伸缩性、零信任性，某种程度上物理共享等特点，又给原应用改造适配带来重重困难。

难点主要有三方面：数据管理；应用通信机制的设计；云上部署与构建。

具体来看：

• 数据管理：需要考虑的问题，比如数据存储在哪？怎么存储最经济？数据的访问模式是什么样的？如何保证数据的一致性？如何应对数据的增长？多源异构的数据如何分别选型？
• 云上部署与构建：需要考虑的问题，如何拆分功能到不同的组件中？如何保持部署的一致性、连贯性、简化管理开发的可维护性？如何保证环境的安全，异常攻击的防范？
• 应用通信机制的设计：大型应用往往包含多个组件，多组件之间的通信一般依赖消息机制来进行解耦，以最大化云上的可伸缩性。异步消息投送机制也会带来许多挑战，如消息排序、幂等行和有害消息处理等。

那么，有没有指导性建议可以帮助构建出可靠且可伸缩的安全云原生应用呢？答案自然是有 —— 云原生设计模式。把云原生设计模式来开发和设计应用，不仅可以降低云上应用设计和开发的难度，而且能够使得构建出的应用更加适合云上环境，实现较优投入产出比。

本文参考了多家云厂商提供的最佳实践文档，对一些常见云原生设计模式谈一谈个人的理解和经验。

引言

这里记录了笔者看过的，比较高质量的技术博客网站。本人能力有限，这里所说高质量是基于个人认知，如有偏颇欢迎批评指正。

引言

Sidecar 是 Istio 提供的一种 CRD 资源, 用于对注入到业务 pod 中的流量劫持 sidecar 进行自定义的配置。

默认情况下，Istio 有全局统一的配置。
使用 Sidecar CRD 可以用于对 Namespace 内的 sidecar 组件进行更精细的配置, 包括指定ingress, egress 监听的 端口、协议，已经转发到的后端等。

本文主要参考 Istio 社区官方文档sidecar的内容。鉴于本人水平有限，如有错误和不准确的地方，欢迎批评指正，感谢。

下面，本文将分别从 Spec 配置项说明、基本应用场景、sidecar iptables 流量劫持原理、配置下发源码分析四个方面，对 Istio Sidecar 做一个比较全面的介绍。

译者序

最近，我们为了增加一个功能，在运维 K8s 集群资源更新时，触发了 cilium 大量并发更新 endpoint 的 identity 资源，导致 API-Server 内存暴涨，请求无法响应。

事后，我们在思考如何落地对 API-Server 限流，偶然中检索到了一篇外文博客，里面介绍了和我非常类似的故障情景，因此翻译整理出来留作参考。

本文来自 2023 年 palark 的博客 Kubernetes API and flow control: Managing request quantity and queuing procedure。 翻译了其中感兴趣的部分。

译者水平有限，不免存在遗漏或错误之处。如有疑问，敬请查阅原文。

以下是译文：

引言

最近在做 CRD Operatior 开发时一直有个疑问：k8s 中各种 Controller 在List-Watch或GEt索引对象时，广泛使用了 Selector 机制，如 Label、Node、Field Selector 等。他们是如何做索引？查询逻辑是怎么实现的？查询过滤是在 Api-Server 还是在 etcd 中？

粗略翻看了下 etcd 接口文档，也没有提供类似的检索能力。合理推测，相关逻辑应该在 Api-Server 中处理的。那么，在中大规模的集群中，有数以千计的 kubelets 和各种资源的 controller, 作为 client 向 API-Server 发起海量请求。面对这么多 QPS 的带 Selector 条件查询，k8s 是如何实现的呢？

带着这些疑问，打开了 Github 中的 k8s Api-Server 源码。

下面是正文：

引言

如果遇到救护场景，可能最先想得如何施救，怎么救人。但实际上，红十字现场救护的第一原则，却是：确保自身安全。

施救前首先，需要确保周围环境安全，施救过程中做好防护防止感染，施救时做好沟通防止事后纠纷等。

别看是初级救护员的简单培训，所学知识足以应对日常会遇到的场景。特别是面对突发心脏骤停、气道阻塞两种常见极危重患者时，黄金4分钟内救护操作，往往决定了生与死。

本文总结下最近参加红十字培训所学的知识。

引言

Numquam ponenda est pluralitas sine necessitate. 
如无必要，勿增实体。—— William of Ockham

之前，我们探讨了 Kubernetes 中最常见的几类典型应用场景和如何优雅地解决两地三中心部署的问题。一直关注我们这个系列文章的读者，想必此时心中或多或少有个这么个疑问：会写 K8s 的各种 Yaml，能把应用容器化部署在 K8s 上，我的应用就是云原生了么？怎么样才是“云原生”？

小编才疏学浅，对这些疑问暂时无法直接解答。不过，后面几期我们将从不同视角介绍一些“云原生”中的新潮概念。相信读完之后，你也许会对“云原生“有不一样的理解。

本期，我们先来聊一聊“云原生圈”里的顶流之一 —— Serverless。

在工业界，2012 年 Iron.io 公司率先提出了“无服务”，2014 年 AWS 发布了 Lambda 商业化产品。自 2014 年以来，Serverless 的热度急剧飙升，远超”云原生”、“Service Mesh”等概念。因此说Serverless 是云原生中的”当红明星“，一点不为过。

引言

对于虚拟化一直以来都认为是高攀不起的领域，不过最近项目上要用到 openstack 做虚拟化集群，”无奈”从0学起，本文是最近入门虚拟化的个人笔记，才疏学浅，必有纰漏，后续不断补充改正，欢迎批评指正.

引言

celery 是 Python 下最流行的基于分布式消息的异步任务库。也支持定时任务。优点：配置方便，集成快速，文档齐全。比较适合 python web 项目中的异步任务开发需求

libprocess 是 mesos 主要使用基础库，mesos许多逻辑架构在此之上。本文记录最近阅读源码的收获，文中有纰漏之处，欢迎批评指正。