1.ingressԴ?码部벿??
2.基于 Zadig + Ingress 实现单应用灰度发布最佳实践
3.什么是K8S？

ingressԴ?벿??

       Acorn 是一个用于 Kubernetes 的轻量级、可移植的码部 PaaS 框架，其设计旨在简化开发和部署基于 Kubernetes 的码部应用程序的流程。作为 K3s 的码部缔造者 Darren Shepherd 及其团队的成果，Acorn 强调了开源、码部简洁、码部cocostudio 源码轻量化和可移植性，码部使其成为在 Kubernetes 环境下构建和扩展微服务的码部理想选择。

       Acorn 的码部核心目标是提供一个无需深入了解 Kubernetes 细节即可运行应用程序的平台。通过使用自己的码部类 JSON 领域特定语言（DSL），它抽象了 Kubernetes 的码部复杂性，使开发者能够轻松地描述基于微服务设计模式的码部现代应用程序。与 Cloud Foundry 类似，码部Acorn 专注于接受源代码或容器镜像并发布端点的码部工作流程，它在后台与 Kubernetes API 协商，码部创建资源并建立所需的管道。

       在公有云环境下，AWS App Runner、Azure Container Apps 和 Google Cloud Run 等服务提供了类似 PaaS 的体验，但它们局限于特定的云平台，不可移植至其他环境。相比之下，Acorn 是一种能够从开发人员笔记本电脑上的 Kind 集群无缝扩展到多节点集群的框架之一，体现了其可移植性。

       本文将详细分析 Acorn 的架构，并展示 Acorn 部署如何转换为 Kubernetes 对象，以及如何通过一系列步骤在 Minikube 中设置环境并部署应用程序。以下是设置和部署过程的关键步骤：

       在 Mac 上安装 Minikube，并在其中启用 Nginx Ingress，以支持 Acorn 的功能。

       使用 Homebrew 安装 Acorn CLI，map.entryset源码并检查其版本，确保已正确安装。

       通过运行 `acorn init` 命令配置 Minikube，以准备安装 Acorn。

       安装 Acorn 后，会在 Kubernetes 集群中创建一组资源，用于处理应用程序的构建时间和运行时要求。这包括 `namespaces`，其中 `acorn-system` 用于 API 和控制器组件，而 `acorn` 用于应用程序资源。

       安装程序会创建一个自定义资源定义（CRD），即 `AppInstance.internal.acorn.io`，用于映射集群内的 Acorn 应用程序。

       Acorn API 服务器与 Kubernetes API 服务器关联，通过聚合机制与集群 API 对话。Acorn CLI 只需要与 API 组相关的 RBAC 权限。

       API 服务器将入站请求转发给 Acorn 控制器，控制器将应用程序定义转换为 Kubernetes 资源，如 Deployments、ConfigMaps、Secrets 和 Volumes，负责管理和维护应用程序的生命周期。

       部署 Acorn 应用程序的流程包括创建一个简单的基于 Nginx 镜像的 Web 服务器实例。在本地目录中创建一个 `Acornfile`，定义容器和端口配置。运行 `acorn run` 命令后，Acorn 会将 OCI 清单推送到集群内的内部注册表服务，并生成访问应用程序的 URL。

       测试应用程序后，可以检查 Kubernetes 集群中生成的wordpress防采集源码资源，如 Deployment、Pod 和服务。使用 Ingress 实现对外暴露，确保应用程序可访问。

       通过将应用程序部署到生产集群，Acorn 实现了真正的可移植性，无需修改集群配置或部署额外资源。它支持 Docker 影响下的通用模式，为多容器应用程序提供运行环境，并与现有服务（如数据库和缓存）集成。

       Acorn 的简单性和便携性使其成为开发者和运维人员的首选，它简化了 Kubernetes 应用程序的部署和管理过程。随着 Acorn 支持直接从 Git 存储库部署的能力，DevOps 团队将能够轻松地管理基于微服务的应用程序，从而实现高效、灵活的开发和运维流程。

基于 Zadig + Ingress 实现单应用灰度发布最佳实践

       在软件开发竞争激烈的环境下，工程师们需面对如何确保发布过程中的稳定性、可靠性与高效性。企业通常会根据业务架构和应用场景选择适用的发布策略。在先前的文章「基于 Istio + Zadig，零负担实现云原生全链路灰度发布」中，Zadig 提供了微服务架构下的全链路灰度发布方案。然而，对于处于单体架构或单应用发布阶段的业务，需要更加针对性的安全保障方案。为此，结合 Zadig 与 Ingress 实现单应用灰度发布的最佳实践被提出。

       本文将深入探讨如何利用 Zadig 和 Ingress 实现生产稳定发布的基本原理，并通过实际案例展示 Zadig 中的数字货币导航源码详细操作步骤。实现过程基于以下核心原理：

       1. **部署蓝环境**：复制当前的 workload，设置新镜像，并创建一个指向该新镜像的 blue service。

       2. **切换部分生产流量**：在原有 ingress 基础上创建一个与生产环境相同的 Host，并将 service 指向 blue service。启用 nginx.ingress.kubernetes.io... "true"，同时调整权重配置为 nginx.ingress.kubernetes.io...：。

       3. **执行蓝绿发布**：更新生产使用的 workload 镜像为新镜像。

       4. **切断蓝环境流量**：修改 ingress 配置，禁用 nginx.ingress.kubernetes.io... "false"。

       5. **蓝绿清理**：在工作流执行完成后，无论最终结果如何，删除 blue service 和 blue workload。

       接下来，我们将详细说明如何在 Zadig 中结合 Ingress 实现这一生产发布流程。

       首先，**项目准备**：创建项目并配置生产服务 a、b、c。参考项目源码和服务 YAML 配置文件。在服务 a 的 YAML 配置中添加 ingress 配置。

       接着，**配置环境**：创建生产环境 prod，管理服务并添加 a、b、c。添加 ingress-blue 以准备生产发布。

       配置工作流：创建工作流并选择「蓝绿发布」模板，配置工作流步骤包括部署蓝绿环境、导流量、gps平台系统源码检查新版本、人工审批和生产升级等。

       执行**生产发布**：按照配置执行工作流，包含部署蓝环境、导入 % 流量到新版本、自动化测试新版本、人工审批、生产升级并切断流量。在待审批状态时验证流量走向。

       最后，**效果验证**：在发布过程中，通过服务日志查看流量分配结果。在人工审批通过后，工作流自动更新生产环境镜像并切回生产，清理临时资源。至此，完整的生产发布流程完成。实际应用中，根据监控数据在人工审批阶段控制新版本上线时间，确保在低峰时段进行发布，减少对用户的影响。

       Zadig 为工程师提供了稳定、高效且灵活的发布解决方案，让工程师能够更加专注于创新。通过结合 Zadig 和 Ingress，实现了单应用灰度发布的最佳实践，为企业提供了更加安全、可控的发布流程。

什么是K8S？

       ‍

       k8s是什么?

       Kubernetes 是一个可移植的，可扩展的开源容器编排平台，用于管理容器化的工作负载和服务，方便了声明式配置和自动化。它拥有一个庞大且快速增长的生态系统。Kubernetes 的服务，支持和工具广泛可用。

       为什么现在流行使用容器?

       早期: 在物理服务器上面部署应用程序存在资源分配问题,因为其不能在物理服务器中的应用程序定义资源边界,导致应用程序资源利用不足而无法扩展.

       后来: 为了解决该问题,引入了虚拟化技术, 虚拟化技术是指允许你在单个物理服务器的 CPU 上运行多个虚拟机,可以让多个应用程序在虚拟机之间进行隔离,具有一定的安全性, 每一个虚拟机就是一台完整的计算机, 在虚拟化硬件之上运行所有组件.

       现在: 多数在物理服务器上面部署应用程序都是采kubectl用容器的方式,容器类似于虚拟机,它们都具有自己的文件系统、CPU、内存、进程空间等, 且由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植。基于此特点被企业大范围使用.

       为什么需要使用k8s容器?

       若出现这样一个环境: 在生产环境中如果一个容器发生故障,则我们需要手动去启动另外一个容器,这样的操作是对我们的管理员来说是不太方便的, 若一个容器出现故障,另一个容器可以自动启动容器接管故障的容器,这样是最好的.

       k8s就可以实现该效果,Kubernetes 提供了一个可弹性运行分布式系统的框架。 Kubernetes 会满足你的扩展要求、故障转移、部署模式等。

       k8s功能: 服务发现和负载均衡, 存储编排, 自动部署和回滚, 自动完成装箱计算, 自我修复, 密钥与配置管理

       名词解释

       secret

       Secret有三种类型：

Service Account：用来访问Kubernetes API，由Kubernetes自动创建，并且会自动挂载到Pod的目录中；/run/secrets/kubernetes.io/serviceaccountOpaque：base编码格式的Secret，用来存储密码、密钥等；kubernetes.io/dockerconfigjson：用来存储私有docker registry的认证信息。

       k8s的组成

       k8s是由组件,API,对象等组成.

       包含所有相互关联组件的 Kubernetes 集群图如下:

       组件

控制平面组件kube-apiserver: 为k8s的api服务器,公开了所有Kubernetes API, 其他所有组件都必须通过它提供的API来操作资源数据.保证集群状态访问的安全隔离集群状态访问的方式和后端存储实现的方式：API Server是状态访问的方式，不会因为后端存储技术etcd的改变而改变。etcd: 为k8s的键值数据库,保存了k8s所有集群数据的后台数据库。kube-scheduler: 收集和分析当前Kubernetes集群中所有Node节点的资源(内存、CPU)负载情况，然后依此分发新建的Pod到Kubernetes集群中可用的节点。 kube-controller-manager: 在主节点上运行 控制器 的组件。cloud-controller-manager: 云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件Node 组件kubelet: 一个在集群中每个节点（node）上运行的代理。 它保证容器（containers）都 运行在 Pod 中。kube-proxy: kube-proxy是集群中每个节点上运行的网络代理,维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。容器运行时: 负责运行容器的软件。插件(Addons)DNS: 集群 DNS 是一个 DNS 服务器，和环境中的其他 DNS 服务器一起工作，它为 Kubernetes 服务提供 DNS 记录。Web 界面（仪表盘）: Dashboard 是Kubernetes 集群的通用的、基于 Web 的用户界面。容器资源监控: 容器资源监控 将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供用于浏览这些数据的界面。集群层面日志: 集群层面日志 机制负责将容器的日志数据 保存到一个集中的日志存储中，该存储能够提供搜索和浏览接口。

       API

       Kubernetes 控制面 的核心是 API 服务器。 API 服务器负责提供 HTTP API，以供用户、集群中的不同部分和集群外部组件相互通信。

       对象

       Kubernetes对象是Kubernetes系统中的持久实体。Kubernetes使用这些实体来表示集群的状态.

       具体来说，他们可以描述：

容器化应用正在运行(以及在哪些节点上)这些应用可用的资源关于这些应用如何运行的策略，如重新策略，升级和容错

       Kubernetes 架构

       Kubernetes 架构由节点,控制面到节点通信, 控制器, 云控制器管理器组成.

       master 流程图

Kubecfg将特定的请求，比如创建Pod，发送给Kubernetes Client。Kubernetes Client将请求发送给API server。API Server根据请求的类型，比如创建Pod时storage类型是pods，然后依此选择何种REST Storage API对请求作出处理。REST Storage API对的请求作相应的处理。将处理的结果存入高可用键值存储系统Etcd中。在API Server响应Kubecfg的请求后，Scheduler会根据Kubernetes Client获取集群中运行Pod及Minion/Node信息。依据从Kubernetes Client获取的信息，Scheduler将未分发的Pod分发到可用的Minion/Node节点上。

       节点

       节点可以是一个虚拟机或者物理机器，取决于所在的集群配置。 每个节点包含运行 Pods 所需的服务， 这些 Pods 由 控制面 负责管理.

       节点上的组件包括 kubelet、 容器运行时以及 kube-proxy。

节点状态

       可以使用 kubectl 来查看节点状态和其他细节信息：

       kubectl describe node <�节点名称>

       一个节点包含以下信息:

地址HostName：由节点的内核设置。可以通过 kubelet 的 —hostname-override 参数覆盖。ExternalIP：通常是节点的可外部路由（从集群外可访问）的 IP 地址。InternalIP：通常是节点的仅可在集群内部路由的 IP 地址。状况(conditions 字段描述了所有 Running 节点的状态)Ready 如节点是健康的并已经准备好接收 Pod 则为 True；False 表示节点不健康而且不能接收 Pod；Unknown 表示节点控制器在最近 node-monitor-grace-period 期间（默认 秒）没有收到节点的消息DiskPressure为True则表示节点的空闲空间不足以用于添加新 Pod, 否则为 FalseMemoryPressure为True则表示节点存在内存压力，即节点内存可用量低，否则为 FalsePIDPressure为True则表示节点存在进程压力，即节点上进程过多；否则为 FalseNetworkUnavailable为True则表示节点网络配置不正确；否则为 False容量与可分配描述节点上的可用资源：CPU、内存和可以调度到节点上的 Pod 的个数上限。信息关于节点的一般性信息，例如内核版本、Kubernetes 版本（kubelet 和 kube-proxy 版本）、 Docker 版本（如果使用了）和操作系统名称。这些信息由 kubelet 从节点上搜集而来。

       控制面到节点通信

节点到控制面apiserver在安全的 HTTPS 端口（）上监听远程连接请求以客户端证书的形式将客户端凭据提供给 kubelet控制面到节点API 服务器到 kubelet连接用于获取 Pod 日志挂接（通过 kubectl）到运行中的 Pod提供 kubelet 的端口转发功能。(注: 在连接状态下, 默认apiserver 不检查 kubelet 的服务证书。容易受到中间人攻击，不安全.)apiserver 到节点、Pod 和服务SSH 隧道(目前已经废弃)产生原因: 若无服务证书, 又要求避免在非受信网络或公共网络上进行连接,则可以在apiserver 和 kubelet 之间使用ssh隧道.Kubernetes 支持使用 SSH 隧道来保护从控制面到节点的通信路径。Konnectivity 服务为ssh隧道的替代品, Konnectivity 服务提供 TCP 层的代理，以便支持从控制面到集群的通信。

       控制器

       在 Kubernetes 中，控制器通过监控集群 的公共状态，并致力于将当前状态转变为期望的状态。

       举个例子: 当前室内温度为度, 我们通过调节遥控器,使其温度上升至度, 这度到度的变化即为让其从当前状态接近期望状态。

       控制器模式分为直接控制和通过API服务器来控制.

       云控制器管理器

       云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件。 云控制器管理器允许您链接聚合到云提供商的应用编程接口中， 并分离出相互作用的组件与您的集群交互的组件。

       云控制器管理器中的控制器包括：

节点控制器节点控制器负责在云基础设施中创建了新服务器时为之 创建 节点（Node）对象。 节点控制器从云提供商获取当前租户中主机的信息。执行功能:针对控制器通过云平台驱动的 API 所发现的每个服务器初始化一个 Node 对象利用特定云平台的信息为 Node 对象添加注解和标签获取节点的网络地址和主机名检查节点的健康状况。路由控制器Route 控制器负责适当地配置云平台中的路由，以便 Kubernetes 集群中不同节点上的 容器之间可以相互通信。服务控制器服务（Service）与受控的负载均衡器、 IP 地址、网络包过滤、目标健康检查等云基础设施组件集成。 服务控制器与云驱动的 API 交互，以配置负载均衡器和其他基础设施组件。

       Kubernetes 安全性

       云原生安全

       云原生安全4个C: 云(Cloud)、集群(Cluster)、容器(Container)和代码(Code)

       云原生安全模型的每一层都是基于下一个最外层，代码层受益于强大的基础安全层（云、集群、容器）。我们无法通过在代码层解决安全问题来为基础层中糟糕的安全标准提供保护。

基础设施安全

       Kubetnetes 基础架构关注领域

       建议

       通过网络访问 API 服务（控制平面)

       所有对 Kubernetes 控制平面的访问不允许在 Internet 上公开，同时应由网络访问控制列表控制，该列表包含管理集群所需的 IP 地址集。

       通过网络访问 Node（节点)

       节点应配置为 仅能 从控制平面上通过指定端口来接受（通过网络访问控制列表）连接，以及接受 NodePort 和 LoadBalancer 类型的 Kubernetes 服务连接。如果可能的话，这些节点不应完全暴露在公共互联网上。

       Kubernetes 云访问提供商的 API

       每个云提供商都需要向 Kubernetes 控制平面和节点授予不同的权限集。为集群提供云提供商访问权限时，最好遵循对需要管理的资源的最小特权原则。Kops 文档提供有关 IAM 策略和角色的信息。

       访问 etcd

       对 etcd（Kubernetes 的数据存储）的访问应仅限于控制平面。根据配置情况，你应该尝试通过 TLS 来使用 etcd。更多信息可以在 etcd 文档中找到。

       etcd 加密

       在所有可能的情况下，最好对所有驱动器进行静态数据加密，但是由于 etcd 拥有整个集群的状态（包括机密信息），因此其磁盘更应该进行静态数据加密。

集群组件安全

运行的应用程序的安全性关注领域访问控制授权(访问 Kubernetes API)认证方式应用程序 Secret 管理 (并在 etcd 中对其进行静态数据加密)Pod 安全策略服务质量（和集群资源管理）网络策略Kubernetes Ingress 的 TLS 支持

容器安全

容器安全性关注领域容器搭建配置(配置不当,危险挂载, 特权用户)容器服务自身缺陷Linux内核漏洞镜像签名和执行

代码安全

代码安全关注领域仅通过 TLS 访问(流量加密)限制通信端口范围第三方依赖性安全静态代码分析动态探测攻击(黑盒)

       Kubernetes架构常见问题

       Kubernetes ATTACK 矩阵

       信息泄露

云账号AK泄露

       API凭证（即阿里云AccessKey）是用户访问内部资源最重要的身份凭证。用户调用API时的通信加密和身份认证会使用API凭证.

       API凭证是云上用户调用云服务API、访问云上资源的唯一身份凭证。

       API凭证相当于登录密码，用于程序方式调用云服务API.

k8s configfile泄露

       kubeconfig文件所在的位置:

       $HOME/.kube/config

       Kubeconfig文件包含有关Kubernetes集群的详细信息，包括它们的位置和凭据。

       云厂商会给用户提供该文件,以便于用户可以通过kubectl对集群进行管理. 如果攻击者能够访问到此文件（如办公网员工机器入侵、泄露到Github的代码等），就可以直接通过API Server接管K8s集群，带来风险隐患。

Master节点SSH登录泄露

       常见的容器集群管理方式是通过登录Master节点或运维跳板机，然后再通过kubectl命令工具来控制k8s。

       云服务器提供了通过ssh登陆的形式进行登陆master节点.

       若Master节点SSH连接地址泄露,攻击者可对ssh登陆进行爆破,从而登陆上ssh,控制集群.

       容器组件未鉴权服务

       Kubernetes架构下常见的开放服务指纹如下:

kube-apiserver: , kubectl proxy: , kubelet: , , dashboard: docker api: etcd: , kube-controller-manager: kube-proxy: , kube-scheduler: weave: , , kubeflow-dashboard:

       注:前六个重点关注: 一旦被控制可以直接获取相应容器、相应节点、集群权限的服务

了解各个组件被攻击时所造成的影响

       组件分工图:

       假如用户想在集群里面新建一个容器集合单元, 流程如下:

用户与 kubectl进行交互,提出需求(例: kubectl create -f pod.yaml)kubectl 会读取 ~/.kube/config 配置，并与 apiserver 进行交互，协议：/service-account

       /cloud-native-academy/cloud-native-applications/cloud-native-infrastructure/

       https://www.cdxy.me/?p=