在上篇介绍基于 CNCF 下的 GitOps 工具 FluxCD v2 实现了管理多账户的 Kubernetes 集群的共享组件，Secrets 使用的最佳实践， GitOps 流水线事件同 IM(Slack) 的集成，以及对 GitOps 代码的 CI 流程。 本文将围绕如何使用 Flux 的多租户管理最佳实践，打造基于 GitOps 工作流程的共享服务平台， 实现租户(业务/应用团队)可自助的持续部署。 一、基于 GitOps 的共享服务平台设定 Kubernetes 提供了命名空间作为一种机制将同一集群中的资源划分为相互隔离的组。 同一个集群中多租户多团队的应用管理将沿用 Kubernetes 内置的各种机制来为不同的租户、团 …

在前文介绍了 GitOps 的概念，Kubernetes 上 GitOps 最佳实践以及对比了 CNCF 基金会下 云原生的 GitOps 工具（ArgoCD 和 Flux）。本篇将带你按照 Flux 的最佳实践在跨VPC跨账户的 Kubernetes 上实践 GitOps 的持续集成，轻松管理数十数百乃至更多的集群及部署在上面的应用。 0. 必备条件 假设业务对稳定性的需求，使用3个 Kubernetes 集群分别对应 DEV, STAGING 和 PRODUCT 环境。这些集群环境根据企业的需求 可能会分布在不同的云账户和VPC网络中。读者可根据实际企业情况创建一个或多个集群。本文以 Amazon EKS 为例，EKS集群的创建 …

今天 Kuberentes 已经成为IT基础设施的重要玩家，容器编排领域的事实标准。写于3年前的文章不要自建 Kuberentes 的观点已经被绝大多数的企业所认可和接受。 然而同众多企业接触中发现，企业有很高的意愿采用 Kuberentes 管理工作负载，并且已有大量的企业已经将 Kuberentes 用于生产环境。 但如何对多套不同阶段的 Kuberentes 集群来做持续部署，做到高安全性、权限分离、可审计、保证业务团队的敏捷等需求感到困惑。 目前客户实现方式非常多样，并没有很好的遵循业界的最佳实践。 GitOps 是目前最佳的一种方法来实现基于 Kuberentes 集群的持续部署，且同时满足安全性、权限分离等企业级需求。 …

As a builder in cloud, you might feel confused about which resources cost mostly in your account. In AWS, you can quickly find out which services even functionality cost a lot via AWS Billing or AWS Cost Explorer. However sometimes it sucks on finding out which functions cost mostly if you have hundreds of Lambda …

近期在一个 Webinar 分享了如何在 AWS 上服务去中心化研发团队构建共享服务平台，核心观点总结如下， 这里的去中心化团队是同理想的完全化的 DevOps 团队(负责设计、开发、测试、运维以及运营等所有环节)相对立的。 在较大型的组织中，账户管理、网络规划、服务审计等模块会由平台，基础设施或安全团队所负责， 多个研发团队会负责各个业务系统的开发、测试、运维等。 如今组织的健康运营对安全性合规性要求越来越高，通常基础设施团队外加安全团队负责承担安全、合规需求的整体策略规划及实施。 但是满足安全、合规需求通常是同业务交付速度期望是相悖的。一方面，平台、安全团队要为应用上线或变更进行安全性与合规性审查， 而研发团队需要投入更多的资源 …

AWS架构的完善(AWS Well-Architected)框架涉及了五大支柱， 其中可靠性支柱要求侧重于确保工作负载在预期的时间内正确、一致地执行其预期功能。 这要求应用程序系统具备弹性设计，可从故障中快速恢复，以便满足业务和客户需求。 然而设计、开发、且验证具备弹性设计的应用程序，对经验和实践能力都有很高的要求。 利用成熟的经验和良好的工具将加快构建符合预期的弹性应用程序。 Application Resilience Workshop是一套课程和动手实践学习如何进行实验来观察系统的行为， 例如，极端系统负载和网络中断情况下，使用不同的软件模式来减轻这些实验对系统稳态的影响。 整个实验也是分为假设、方法、观测和缓解等步骤，同混沌 …

混沌工程是一种帮助系统满足弹性需求的技术，它起源于Netflix的工程实践，著名的猴子军团。 AWS一直提倡架构的完善(AWS Well-Architected)，混沌工程正是卓越运营和可靠性支柱的实践。 因此在 re:Invent 2020 AWS发布了Fault Injection Simulator服务来简化开发者在AWS上的混动工程实践。 AWS FIS作为AWS上原生的混沌工程服务，目前已同EC2，ECS，EKS，RDS，CloudWatch，甚至是IAM Role API集成，可以触发这些服务中资源的变更来假设故障， 例如，重启或终止EC2实例，重启RDS实例等。 Chaos Engineering on AWS是一份非 …

Amazon Neptune is a managed Graph database on AWS, whose compute and storage is decoupled like Amazon Aurora. Neptune leverages popular open-source APIs such as Gremlin and SPARQL, and easily migrate existing applications. After exploring Neptune few months in solution, I have below few learnings, Bulk loading Always …

Last year I shared the production-ready, cloud native solution to deploy Sonatype Nexus Repository OSS on AWS. The solution has an update with below notable changes, support specifying EKS version, v1.20, v1.19, and v1.18 are supported versions support provisioning to existing VPC support provisioning to existing …

本方案的起因是，一个源代码托管在Github上的项目fix一个重要的bug后，在AWS上的持续部署流水线一直失败。分析日志后，发现流水线中的数个步骤需要克隆源代码，但是访问Github的网络非常不稳定，这数个流水线任务持续因连接超时，连接拒绝等网络错误而失败。而流水线任务大量使用了CodeBuild, Lambda等AWS托管服务，无法为执行环境配置可靠的网络连接。 本方案思路如下， 在 VPC public subnets 中创建 NAT instance 即 EC2 虚拟机， 配置 NAT instance，使用 tunnel 网络访问 github， 修改 private subnets 的路由表，添加 github …