安全是企业上云的核心关切之一。云原生的敏捷性和动态性给企业安全带来新的挑战。由于云上安全是责任共担模型，需要企业理解与云服务商之间的责任边界，更要思考如何通过工具化、自动化的流程固化安全最佳实践。此外，传统安全架构通过防火墙保护边界，而内部的任何用户或服务受到完全的信任。2020 突发的新冠疫情，大量的企业需要员工和客户远程办公与协同，企业应用需要在 IDC 和云上部署和交互。在物理安全边界消失之后，云安全正在迎来一场深刻的变革。
此外，新冠疫情进一步让企业更加关注IT成本优化。云原生的一个重要优势是充分利用云的弹性能力，来按需提供业务所需计算资源，避免资源浪费，实现成本优化的目标。但是，与传统成本预算审核制度不同，云原生的动态性、和高密度应用部署，让 IT 成本管理更加复杂。
为此，云原生理念和技术也在发展，帮助用户持续降低潜在风险和系统复杂性。下面我们将介绍在云原生应用交付与运维领域的一些新趋势。
===============================================================================================
Kubernetes 这个单词来自于希腊语，含义是舵手或领航员，是 “控制论”英文 “cybernetic” 的词根。Kubernetes 成为在容器编排的事实标准，不只得益于 Google 的光环和 CNCF（云原生计算基金会）的努力运作。背后是 Google 在 Borg 大规模分布式资源调度和自动化运维领域的沉淀和系统化思考，认真理解 Kubernetes 架构设计，有助于思考在分布式系统系统调度、管理的一些本质问题。
Kubernetes 架构的核心就是控制器循环，也是一个典型的"负反馈"控制系统。当控制器观察到期望状态与当前状态存在不一致，就会持续调整资源，让当前状态趋近于期望状态。比如，根据应用副本数变化进行扩缩容，节点宕机后自动迁移应用等。
K8s 的成功离不开 3 个重要的架构选择：
-
声明式（Declarative）的 API：在 Kubernetes 之上，开发者只需定义抽象资源的目标状态，而由控制器来具体实现如何达成。比如 Deployment、StatefulSet、 Job 等不同类型工作负载资源的抽象。让开发者可以关注于应用自身，而非系统执行细节。声明式API是云原生重要的设计理念，这样的架构方式有助于将整体运维复杂性下沉，交给基础设施实现和持续优化。此外由于分布式系统的内生稳定性挑战，基于声明式的，面向终态的 “level-triggered” 实现比基于命令式 API、事件驱动的 “edge-triggered” 方式可以提供更加健壮的分布式系统实现。
-
屏蔽底层实现：K8s 通过一系列抽象如 Loadbalance Service、Ingress、CNI、CSI，帮助业务应用可以更好通过业务语义使用基础设施，无需关注底层实现差异。
-
可扩展性架构：所有 K8s 组件都是基于一致的、开放的 API 进行实现和交互。三方开发者也可通过 CRD（Custom Resource Definition）/ Operator 等方法提供领域相关的扩展实现，极大扩展了 K8s 的应用场景。
正因如此，Kubernetes 管理的资源和基础设施范围已经远超容器应用。下面是几个例子：
-
基础架构管理：与开源的 Terraform 或者云供应商自身提供的 Infrastructure as Code(IaC)工具如阿里云 ROS、AWS CloudFormation 不同，Crossplane（https://crossplane.io/）和 AWS Controllers for Kubernetes 在 Kubernetes 基础之上扩展了对基础设施的管理和抽象。这样可以采用一致的方式进行管理和变更 K8s 应用和云基础设施。
-
虚拟机管理：K8s 通过 KubeVirt 可以实现对虚拟机和容器的统一调度与管理，可以利用虚拟化弥补容器技术的一些局限性，比如在 CI/CD 场景中，可以结合 Windows 虚拟机进行自动化测试。
-
IoT 设备管理：KubeEdge 和 OpenYurt 等边缘容器技术都提供了对海量边缘设备的管理能力。
-
K8s 集群管理：阿里云容器服务 ACK 的节点池管理，集群管理等完全都是采用 Kubernetes 方式进行自动化管理与运维的。ACK Infra 支撑了部署在全球各地数万个 Kubernetes 集群，基于 K8s 完成自动化了扩缩容、故障发现/自愈等能力。
K8s 控制器 “把复杂留给自己，把简单交给别人”的理想非常美好，然而实现一个高效、健壮的控制器却充满技术挑战。
-
由于 K8s 内置工作负载的局限性，一些需求无法满足企业应用迁移的需求，通过Operator framework 进行扩展成为了常见的解决方案。但是一方面对重复的需求重复造轮子，会造成了资源的浪费；也会导致技术的碎片化，降低可移植性。
-
随着越来越多的企业 IT 架构，从 on Kubernetes 到 in Kubernetes，大量的 CRD、自定义 Controller 给 Kubernetes 的稳定性和性能带来大量的挑战。面向终态的自动化是一把 “双刃剑”，它既为应用带来了声明式的部署能力，同时也潜在地会将一些误操作行为被终态化放大。在发生操作故障时副本数维持、版本一致性、级联删除等机制反而很可能导致爆炸半径扩大。
OpenKruise 是阿里云开源的云原生应用自动化管理引擎，也是当前托管在 Cloud Native Computing Foundation (CNCF) 下的 Sandbox 项目。它来自阿里巴巴多年来容器化、云原生的技术沉淀，是阿里内部生产环境大规模应用的基于 Kubernetes 之上的标准扩展组件，一套紧贴上游社区标准、适应互联网规模化场景的技术理念与最佳实践。以开源项目 OpenKruise 方式与社区开放、共建。一方面帮助企业客户在云原生的探索的过程中，少走弯路，减少技术碎片，提升稳定性；一方面推动上游技术社区，逐渐完善和丰富 Kubernetes的应用周期自动化能力。
更多信息可以参考：《OpenKruise 2021 规划曝光：More than workloads》
云原生技术出现也带来了企业 IT 组织结构的变化。为了更好应对业务敏捷性的需要，微服务应用架构催生了 “双比萨团队”（Two-pizza teams) 。较小的、独立的、自包含的开发团队可以更好达成共识，加速业务创新。SRE 团队成为了水平支撑团队，支撑上层研发效率提升和系统稳定性。而随着 Kubernetes 的发展，让 SRE 团队可以基于 K8s 构建自己企业的应用平台，推进标准化和自动化，让上层应用开发团队通过自服务的方式进行资源管理和应用生命周期管理。我们看到组织方式进一步发生了变化，新的平台工程团队开始浮现。
参考：https://blog.getambassador.io/the-rise-of-cloud-native-engineering-organizations-1a244581bda5
这也与 K8s 自身定位是非常相契合的。Kubernetes 的技术定位面向应用运维的基础设施和 Platform for Platform，并不是面向开发者的一体化应用平台。越来越多的企业会由平台工程团队基于 Kubernetes 构建自己的 PaaS 平台，提升研发效率和运维效率。
类似 Cloud Foundry 的经典 PaaS 实现会建立一套独立概念模型、技术实现和扩展机制，这种方式可以提供简化用户体验，但是也引入了一些缺陷。无法和快速发展的 Kubernetes 体系相结合，无法充分组合使用多种新的技术实现，比如 Serverless 编程模型，支持 AI/数据分析等新计算业务。但是基于 K8s 的 PaaS 平台缺乏统一的架构设计和实现规划，会出现很多碎片化的技术实现，并不利于可持续的发展。
Open Application Model（OAM）开放应用模型，以及它的 Kubernetes 实现 KubeVela 项目，正是阿里云联合微软和云原生社区，共同推出的云原生应用交付与管理领域的标准模型与框架项目。其中，OAM 的设计思想是为包括 Kubernetes 在内的任何云端基础设施提供一个统一、面向最终用户的应用定义模型；而 KubeVela，则是这个统一模型在 Kubernetes 上的 PaaS 参考实现。
KubeVela/OAM 提供了面向 Kubernetes 的服务抽象和服务组装能力，可以将不同实现的工作负载和运维特征进行统一抽象和描述，并提供插件式的注册与发现机制，进行动态组装。平台工程团队可以采用一致的方式进行新功能扩展，并且保持与 Kubernetes 上新的应用框架良好的互操作性。对于应用开发和运维团队，实现了关注点分离（Separation of Concerns），可以将应用定义、运维能力与基础设施实现解构，让应用交付过程变得更加高效、可靠和自动化。
在云原生应用模型定义领域，业界也在不同方向进行探索。比如 AWS 新发布的 Proton 是面向云原生应用交付的服务，通过 Proton，可以降低容器和 Serverless 部署、运维复杂性，并且可以和 GitOps 结合起来，提升整个应用交付流程的自动化和可管理性。
阿里云 Serverless K8s 支持的 Knative 可以同时支持 Serverless 容器和函数来实现事件驱动的应用，让开发者使用一个编程模型，可以高效选择底层不同 Serverless 化算力进行优化执行等。
======================================================================================
敏捷开发与可编程云基础设施结合在一起，大大提升了企业应用的交付效率。然而在这个过程中，如果忽视了安全风险控制，有可能造成巨大的损失。Gartner 论断，到 2025年，云上基础设施 99% 的安全渗透问题是由于用户错误的配置和管理造成的。
在传统软件开发流程中，在系统设计开发完成后和发布交付前，安全人员才开始介入进行安全审核。这种流程无法满足业务快速迭代的诉求。”Shifting left on security“ (安全性左移)”开始得到更多的关注，这将应用程序设计、开发人员尽早与安全团队协作，并无缝地嵌入安全实践。通过左移安全性，不仅可以降低安全风险，还可以降低修复成本。IBM 的研究人员发现，解决设计中的安全问题比代码开发期间能节省 6 倍左右的成本，比测试期间能节省 15 倍左右的成本。
DevOps 研发协作流程也随之扩展成为 DevSecOps。它首先是理念文化的变化，安全成为每个人的责任，而非专注安全团队的责任；其次尽早解决安全问题，将安全左移到软件设计阶段，降低整体安全治理成本；最后是通过自动化工具链而非人治方式，实现风险预防、持续监测和及时响应能力。
DevSecOps 落地的技术前提是实现可验证的、可复现的构建和部署流程，这样可以保障我们在测试、预发、生产等不同环境对架构安全性进行持续验证和改进。我们可以利用云原生技术中的 immutable infrastructure （不可变基础设施） 和声明式的策略管理 Policy as Code 结合在一起实现 DevSecOps 的落地实践。下图是一个最简化的容器应用 DevSecOps 流水线。
当代码提交之后，可以通过阿里云镜像服务 ACR 主动扫描应用，并对镜像进行签名，当容器服务 K8s 集群开始部署应用时，安全策略可以对镜像进行验签，可以拒绝未通过验签的应用镜像。同理，如果我们利用 Infrastructure as Code 的方式对基础设施进行变更，我们可以通过扫描引擎在变更之前就进行风险扫描，如果发现相关的安全风险可以终止并告警。
此外，当应用部署到生产环境之后，任何变更都需通过上述自动化流程。这样的方式最小化了人为的错误配置引发的安全风险。Gartner 预测，到 2025年 60% 的企业会采纳 DevSecOps 和不可变基础设施实践，与 2020 年相比降低 70% 安全事件。
分布式微服务应用不但部署和管理复杂性提升，其安全攻击面也被放大。在传统的三层架构中，安全防护主要在南北向流量，而在微服务架构中，东西向流量防护会有更大的挑战。在传统的边界防护方式下，如果一个应用因为安全缺陷被攻陷，缺乏安全控制机制来阻止内部威胁“横向移动”。
https://www.nist.gov/blogs/taking-measure/zero-trust-cybersecurity-never-trust-always-verify
“零信任”最早由 Forrester 在 2010 年左右提出，简单地说，零信任就是假定所有威胁都可能发生，不信任网络内部和外部的任何人/设备/应用，需要基于认证和授权重构访问控制的信任基础，引导安全体系架构从“网络中心化”走向“身份中心化”；不信任传统网络边界保护，而代之以微边界保护。
Google 在大力推动云原生安全和零信任架构，比如 BeyondProd 方法论。阿里和蚂蚁集团上云过程中，也开始引入零信任架构理念和实践。其中的关键是：
-
统一身份标识体系：为微服务架构中每一个服务组件都提供一个独立的身份标识。
-
统一访问的授权模型：服务间调用需要通过身份进行鉴权。
-
统一访问控制策略：所有服务的访问控制通过标准化方向进行集中管理和统一控制。
安全架构是一种 cross-cutting concern，贯穿在整个 IT 架构与所有组件相关的关注点。如果它与具体微服务框架实现耦合，任何安全架构调整都可能对每个应用服务进行重新编译和部署，此外微服务的实现者可以绕开安全体系。而服务网格可以提供独立于应用实现的，松耦合、分布式的零信任安全架构。
下图是 Istio 服务网格的安全架构：
其中：
-
既可以利用现有身份服务提供身份标识，也支持 SPIFFE 格式的身份标识。身份标识可以通过 X.509 证书或者 JWT 格式进行传递。
-
通过服务网格控制平面 API 来统一管理，认证、授权、服务命名等安全策略。
-
通过 Envoy Sidecar 或者边界代理服务器作为策略执行点（PEP）来执行安全策略，可以为东西向和南北向的服务访问提供安全访问控制。而且 Sidecar 为每个微服务提供了应用级别的防火墙，网络微分段最小化了安全攻击面。
服务网格让网络安全架构与应用实现解耦，可以独立演进，独立管理，提升安全合规保障。此外利用其对服务调用的遥测能力，可以进一步通过数据化、智能化方法对服务间通信流量进行风险分析、自动化防御。云原生零信任安全还在早期，我们期待未来更多的安全能力下沉到基础设施之中。
==================================================================================
1. 从 Infrastructure as Code 到 Everything as Code
基础架构即代码（Infrastructure-as-Code， IaC）是一种典型的声明式 API，它改变了云上企业IT架构的管理、配置和协同方式。利用 IaC 工具，我们可以将云服务器、网络和数据库等云端资源，进而实现完全自动化的创建、配置和组装。
我们可以将 IaC 概念进行延伸，可以覆盖整个云原生软件的交付、运维流程，即 Everything as Code。下图中涉及了应用环境中各种模型，从基础设施到应用模型定义到全局性的交付方式和安全体系，我们都可以通过声明式方式对应用配置进行创建、管理和变更。
通过这种方式，我们可以为分布式的云原生应用提供灵活、健壮、自动化的全生命周期管理能力：
-
所有配置可被版本管理，可追溯，可审计。
-
所有配置可维护、可测试、可理解、可协作。
-
所有配置可以进行静态分析、保障变更的可预期性。
-
所有配置可以在不同环境重现，所有环境差异也需要进行显示声明，提升一致性。
先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前在阿里
深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年最新Linux运维全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上运维知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
hPJ-1714503982807)]
[外链图片转存中…(img-GV7w9YwD-1714503982808)]
[外链图片转存中…(img-5g5QCKh3-1714503982809)]
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上运维知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
810
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
