KubeSphere（ v3.4.1）学习记录

• KubeSphere（ v3.4.1）基础问答
• • KubeSphere 中都有哪些组件或服务？
  • Kubernetes 中的 Deployment、StatefulSet、DaemonSet、Job、CronJob、Secret、ConfigMap 是做什么的？
  • 在 KubeSphere 中部署一个 MySQL 服务，都要哪几步？
  • • 准备工作
    • 动手实验
  • Kubernetes 中的 Ingress、Ingress Controller 是做什么的？应用如何对集群外提供服务？
  • 镜像仓库是什么？应用商店是什么？他们有什么关系？
  • 多租户之间如何隔离网络？
• END

KubeSphere（ v3.4.1）基础问答

KubeSphere 中都有哪些组件或服务？

前后端分离
KubeSphere 将 前端 与 后端 分开，实现了面向云原生的设计，后端的各个功能组件可通过 REST API 对接外部系统。 可参考 API文档。下图是系统架构图。

KubeSphere 无底层的基础设施依赖，可以运行在任何 Kubernetes、私有云、公有云、VM 或物理环境（BM）之上。 此外，它可以部署在任何 Kubernetes 发行版上。
KubeSphere 是一个基于 Kubernetes 的企业级多租户容器平台，它提供了丰富的功能和服务来简化 Kubernetes 的使用，并增强了云原生应用的开发、部署和管理流程。KubeSphere 的组件和服务大致可以分为以下几类：

• 组件列表：
  
  
• 服务组件：
  • KubeSphere 应用商店：基于 Helm 的应用商店，用于应用生命周期管理。
  • KubeSphere DevOps：基于 Jenkins 的 KubeSphere DevOps 系统是专为 Kubernetes 中的 CI/CD 工作流设计的，它提供了一站式的解决方案，帮助开发和运维团队用非常简单的方式构建、测试和发布应用到 Kubernetes。
  • KubeSphere 日志系统：KubeSphere 为日志收集、查询和管理提供了一个强大的、全面的、易于使用的日志系统。它涵盖了不同层级的日志，包括租户、基础设施资源和应用。
  • KubeSphere 事件系统：使用户能够跟踪集群内部发生的事件，例如节点调度状态和镜像拉取结果。这些事件会被准确记录下来，并在 Web 控制台中显示具体的原因、状态和信息。
  • KubeSphere 告警系统：告警系统与其主动式故障通知 (Proactive Failure Notification) 系统相结合，使用户可以基于告警策略了解感兴趣的活动。当达到某个指标的预定义阈值时，会向预先配置的收件人发出告警。可以帮助用户迅速发现并提前解决潜在问题，避免业务受影响。
  • KubeSphere 审计日志：提供了一套与安全相关并按时间顺序排列的记录，按顺序记录了与单个用户、管理人员或系统其他组件相关的活动。对 KubeSphere 的每个请求都会生成一个事件，然后写入 Webhook，并根据一定的规则进行处理。
  • KubeSphere 服务网格：基于 Istio，将微服务治理和流量管理可视化。它拥有强大的工具包，包括熔断机制、蓝绿部署、金丝雀发布、流量镜像、链路追踪、可观测性和流量控制等。
  • 网络策略：网络策略是一种以应用为中心的结构，使能够指定如何允许容器组通过网络与各种网络实体进行通信。通过网络策略，用户可以在同一集群内实现网络隔离，这意味着可以在某些实例（容器组）之间设置防火墙。
  • Metrics Server：KubeSphere 支持用于部署的容器组（Pod）弹性伸缩程序 (HPA)。在 KubeSphere 中，Metrics Server 控制着 HPA 是否启用。您可以根据不同类型的指标（例如 CPU 和内存使用率，以及最小和最大副本数），使用 HPA 对象对部署 (Deployment) 自动伸缩。
  • 服务拓扑图：可以启用服务拓扑图以集成 Weave Scope（Docker 和 Kubernetes 的可视化和监控工具）。Weave Scope 使用既定的 API 收集信息，为应用和容器构建拓扑图。服务拓扑图显示在您的项目中，将服务之间的连接关系可视化。
  • 容器组 IP 池：容器组 IP 池用于规划容器组网络地址空间，每个容器组 IP 池之间的地址空间不能重叠。创建工作负载时，可选择特定的容器组 IP 池，这样创建出的容器组将从该容器组 IP 池中分配 IP 地址。
  • KubeEdge：KubeEdge 是一个开源系统，用于将容器化应用程序编排功能扩展到边缘的主机。KubeEdge 支持多个边缘协议，旨在对部署于云端和边端的应用程序与资源等进行统一管理。

Kubernetes 中的 Deployment、StatefulSet、DaemonSet、Job、CronJob、Secret、ConfigMap 是做什么的？

在 Kubernetes 中，各种资源对象（Resources）被设计用来描述和管理应用程序的运行状态。以下是一些关键资源对象的功能介绍：

1. Deployment
   Deployment 是用于声明式更新应用程序副本的控制器。它管理 ReplicaSet，并向 Pod 提供声明式的更新以及许多其他有用的功能。它确保任何时候都有指定数量的实例（Pods）正在运行，并且能够平滑地更新应用版本。当 Pod 出现故障时，Deployment 会自动重启 Pod。它是 Kubernetes 中最常用的应用程序部署方式之一。
   ReplicaSet：目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合。 因此，它通常用来保证给定数量的、完全相同的 Pod 的可用性。

2. StatefulSet

   • StatefulSet 是用来管理有状态应用的工作负载 API 对象。
   • StatefulSet 用来管理某 Pod 集合的部署和扩缩， 并为这些 Pod 提供持久存储和持久标识符。

   和 Deployment 类似， StatefulSet 管理基于相同容器规约的一组 Pod。但和 Deployment 不同的是， StatefulSet 为它们的每个 Pod 维护了一个有粘性的 ID。这些 Pod 是基于相同的规约来创建的， 但是不能相互替换：无论怎么调度，每个 Pod 都有一个永久不变的 ID。
   如果希望使用存储卷为工作负载提供持久存储，可以使用 StatefulSet 作为解决方案的一部分。 尽管 StatefulSet 中的单个 Pod 仍可能出现故障， 但持久的 Pod 标识符使得将现有卷与替换已失败 Pod 的新 Pod 相匹配变得更加容易。

3. DaemonSet

   • DaemonSet 确保所有（或某些）节点上运行一个 Pod 的副本。例如，你可能希望在集群中的每个节点上运行一个日志代理或监控代理。
   • DaemonSet 保证即使节点增加或减少，每个节点上的 Pod 副本数也会保持一致。
   • 删除 DaemonSet 将会删除它创建的所有 Pod。

4. Job

   • Job 会创建一个或者多个 Pod，并将继续重试 Pod 的执行，直到指定数量的 Pod 成功终止。 随着 Pod 成功结束，Job 跟踪记录成功完成的 Pod 个数。 当数量达到指定的成功个数阈值时，任务（即 Job）结束。
   • 删除 Job 的操作会清除所创建的全部 Pod。
   • 挂起 Job 的操作会删除 Job 的所有活跃 Pod，直到 Job 被再次恢复执行。

5. CronJob

   • CronJob 创建基于时隔重复调度的 Job。
   • CronJob 用于执行排期操作，例如备份、生成报告等。 一个 CronJob 对象就像 Unix 系统上的 crontab（cron table）文件中的一行。 它用 Cron 格式进行编写， 并周期性地在给定的调度时间执行 Job。
   • CronJob 有所限制，也比较特殊。 例如在某些情况下，单个 CronJob 可以创建多个并发任务。

6. Secret

   • Secret 是一种包含少量敏感信息例如密码、令牌或密钥的对象。 这样的信息可能会被放在 Pod 规约中或者镜像中。 使用 Secret 意味着你不需要在应用程序代码中包含机密数据。
   • 由于创建 Secret 可以独立于使用它们的 Pod， 因此在创建、查看和编辑 Pod 的工作流程中暴露 Secret（及其数据）的风险较小。 Kubernetes 和在集群中运行的应用程序也可以对 Secret 采取额外的预防措施， 例如避免将敏感数据写入非易失性存储。
   • Secret 类似于 ConfigMap 但专门用于保存机密数据。

7. ConfigMap

   • ConfigMap 是一种 API 对象，用来将非机密性的数据保存到键值对中。使用时， Pod 可以将其用作环境变量、命令行参数或者存储卷中的配置文件。
   • ConfigMap 将你的环境配置信息和容器镜像解耦，便于应用配置的修改。

在 KubeSphere 中部署一个 MySQL 服务，都要哪几步？

在 KubeSphere 中部署 MySQL 服务通常需要遵循以下步骤：

准备工作

• 需要启用 OpenPitrix 系统。
• 需要创建一个企业空间、一个项目和一个用户帐户 (project-regular)。该用户必须是已邀请至项目的平台普通用户，并且在项目中的角色为 operator。在本教程中，需要以 project-regular 用户登录，并在 demo-workspace 企业空间的 demo-project 项目中进行操作。有关更多信息，请参见创建企业空间、项目、用户和角色。

动手实验

• 步骤 1：从应用商店部署 MySQL
  1. 在 demo-project 的概览页面，点击左上角的应用商店。
  2. 找到 MySQL，在应用信息页面点击安装。
  3. 设置应用名称和版本，确保 MySQL 部署在 demo-project 项目中，然后点击下一步。
  4. 在应用设置页面，取消对 mysqlRootPassword 字段的注释并设置密码，然后点击安装。
  5. 等待 MySQL 创建完成并开始运行。
• 步骤 2：访问 MySQL 终端
  1. 打开工作负载页面并点击 MySQL 的工作负载名称。
  2. 在容器组区域，展开容器详情，点击终端图标。
  3. 在终端窗口中，执行 mysql -uroot -ptesting 命令以 root 用户登录 MySQL。
• 步骤 3：从集群外访问 MySQL 数据库
  要从集群外访问 MySQL，您需要先用 NodePort 暴露该应用。
  1. 打开服务页面并点击 MySQL 的服务名称。
  2. 点击更多操作，在下拉菜单中选择编辑外部访问。
  3. 将访问模式设置为 NodePort 并点击确定。有关更多信息，请参见项目网关。
  4. 可以在端口区域查看暴露的端口。该端口号和公网 IP 地址将在下一步用于访问 MySQL 数据库。
  5. 需要使用 MySQL Client 或第三方应用（例如 SQLPro Studio）才能访问 MySQL 数据库。以下演示如何使用 SQLPro Studio 访问 MySQL 数据库。
     
     
     （备注：取决于您的 Kubernetes 集群的部署位置，您可能需要在安全组中放行端口并配置相关的端口转发规则。）
  6. 有关 MySQL 的更多信息，请参考 MySQL 官方文档。

Kubernetes 中的 Ingress、Ingress Controller 是做什么的？应用如何对集群外提供服务？

在 Kubernetes 中，Ingress 和 Ingress Controller 是用于管理和配置集群外部对集群内部服务的访问的关键组件。实际上，Ingress 相当于一个 7 层的负载均衡器，是Kubernetes 对反向代理的一个抽象，他的工作原理类似于 Nginx。下面是对它们的详细解释：

Ingress

• Ingress 提供从集群外部到集群内服务的 HTTP 和 HTTPS 路由。 流量路由由 Ingress 资源所定义的规则来控制。
• 通过配置，Ingress 可为 Service 提供外部可访问的 URL、对其流量作负载均衡、 终止 SSL/TLS，以及基于名称的虚拟托管等能力。
• Ingress 控制器 负责完成 Ingress 的工作，具体实现上通常会使用某个负载均衡器， 不过也可以配置边缘路由器或其他前端来帮助处理流量。

Ingress 的工作原理（以 Nginx 为例）如下：

1. 用户编写 Ingress 规则，说明哪个域名对应 Kubernetes 集群中的哪个 Service；
2. Ingress 控制器动态感知 Ingress 服务规则的变化，然后生成一段对应的 Nginx 反向代理配置；
3. Ingress 控制器会将生成的 Nginx 配置写入到一个运行着的 Nginx 服务中，并动态更新；
4. 到此为止，其实真正在工作的就是一个 Nginx 了，内部配置了用户定义的请求转发规则。

（说明：入口（Ingress）目前已停止更新。新的功能正在集成至网关 API 中）

Ingress Controller
Ingress Controller 是 Kubernetes 集群中运行的一个组件，它实现了 Ingress 资源的规则。Ingress Controller 监听 Kubernetes API Server 中的 Ingress 对象变化，并根据这些规则配置相应的负载均衡器或反向代理服务器。常见的 Ingress Controller 包括：

• Nginx Ingress Controller
• Traefik Kubernetes Ingress 提供程序
• Apache HTTP Server (mod_proxy_ajp)
• HAProxy Ingress

Ingress Controller 通常运行在 Pod 内，并且通常绑定到集群的边缘节点，如 LoadBalancer 类型的服务或 NodePort 服务，从而能够接收外部流量。

如何对外提供服务？

要让 Kubernetes 集群内部的服务对集群外部提供服务，你可以采取以下步骤：

1. 创建 Service：
   首先，为你的应用创建一个 Service。Service 定义了如何访问应用的逻辑集合，可以使用 ClusterIP、NodePort 或 LoadBalancer 类型。
2. 创建 Ingress：
   接着，创建一个 Ingress 对象，其中包含将外部请求路由到内部 Service 的规则。
3. 部署 Ingress Controller：
   如果你的集群中尚未部署 Ingress Controller，则需要部署一个。这通常涉及到安装和配置 Ingress Controller 的部署配置。
4. 配置域名和证书：
   如果需要，可以配置 Ingress 来使用自定义域名，并通过 Ingress Controller 管理 SSL/TLS 证书。
5. 验证外部访问：
   最后，通过浏览器或其他工具尝试访问你的应用，确保 Ingress Controller 正确地将外部请求路由到了集群内部的服务。

Ingress 和 Ingress Controller 提供了一个灵活且强大的机制来管理集群内外部的网络流量，这对于在生产环境中运行的多服务架构尤其重要。它们不仅简化了服务发现和负载均衡，还提供了 SSL/TLS 终止、URL 路由等高级功能。

镜像仓库是什么？应用商店是什么？他们有什么关系？

在 KubeSphere 中，镜像仓库和应用商店都是重要的组成部分，服务于不同的目的，但它们之间存在一定的关联。让我们逐一了解它们的作用及其相互关系：

镜像仓库 (Image Registry)
镜像仓库可用于存储和分发 Docker 镜像。在 Kubernetes 或 KubeSphere 环境中，容器的运行依赖于预先构建的镜像，而这些镜像需要从镜像仓库拉取。镜像仓库可以是公共的，如 Docker Hub，也可以是私有的，如 Harbor、Quay.io 或者其他自建的仓库。

在 KubeSphere 中，镜像仓库的集成意味着用户可以轻松地从预配置的仓库中拉取镜像来部署应用，无需每次手动指定仓库地址。这提高了部署效率和安全性，尤其是对于大型组织而言，使用私有镜像仓库可以控制镜像来源，减少网络延迟，并保护知识产权。

应用商店 (Application Store)
KubeSphere 集成了 OpenPitrix（一个跨云管理应用程序的开源平台）来构建应用商店，管理应用程序的整个生命周期。应用商店支持两种应用程序部署方式：

• 应用模板：这种方式让开发者和独立软件供应商 (ISV) 能够与企业空间中的用户共享应用程序。也可以在企业空间中导入第三方应用仓库。
• 自制应用：这种方式帮助用户使用多个微服务来快速构建一个完整的应用程序。KubeSphere 让用户可以选择现有服务或者创建新的服务，用于在一站式控制台上创建自制应用。

应用商店是 KubeSphere 的一个特色功能，它提供了一个基于 Helm 的界面，允许用户一键部署云原生应用。Helm 是 Kubernetes 的包管理器，它使用模板化的配置文件（称为 Charts）来描述应用的部署结构，包括镜像、配置、服务等。通过应用商店，用户可以从一个中心位置找到、部署和管理各种应用，无需深入了解底层的 Kubernetes 配置。

应用商店通常包含了一系列预先审核和打包的 Helm Charts，这些 Charts 可以是 KubeSphere 自带的，也可以是由第三方开发者或 ISV（独立软件供应商）提供的。用户可以通过应用商店搜索、预览、部署和更新应用，简化了应用的生命周期管理。

关系
镜像仓库和应用商店之间的关系在于，应用商店中的应用通常是基于 Helm Charts 构建的，而这些 Charts 可能引用了存储在镜像仓库中的 Docker 镜像。当用户从应用商店部署应用时，KubeSphere 会从指定的镜像仓库拉取应用所需的镜像，然后根据 Helm Chart 的配置进行部署。

因此，镜像仓库提供了应用部署的基础资源，而应用商店则是面向用户的前端接口，它封装了部署过程，使其更加用户友好和自动化。两者结合，使得在 KubeSphere 中部署和管理复杂应用变得更加简便和高效。

多租户之间如何隔离网络？

KubeSphere 提供了基于 Kubernetes 的多租户管理方案。

在 KubeSphere 中企业空间是最小的租户单元，企业空间提供了跨集群、跨项目（即 Kubernetes 中的命名空间）共享资源的能力。企业空间中的成员可以在授权集群中创建项目，并通过邀请授权的方式参与项目协同。

用户是 KubeSphere 的帐户实例，可以被设置为平台层面的管理员参与集群的管理，也可以被添加到企业空间中参与项目协同。

多级的权限控制和资源配额限制是 KubeSphere 中资源隔离的基础，奠定了多租户最基本的形态。

逻辑隔离
与 Kubernetes 相同，KubeSphere 通过 RBAC 对用户的权限加以控制，实现逻辑层面的资源隔离。

KubeSphere 中的权限控制分为平台、企业空间、项目三个层级，通过角色来控制用户在不同层级的资源访问权限。

• 平台角色：主要控制用户对平台资源的访问权限，如集群的管理、企业空间的管理、平台用户的管理等。
• 企业空间角色：主要控制企业空间成员在企业空间下的资源访问权限，如企业空间下项目、DevOps 项目的管理等。
• 项目角色：主要控制项目下资源的访问权限，如工作负载的管理、流水线的管理等。

网络策略（Network Policies）
网络策略是一种以应用为中心的结构，使能够指定如何允许容器组通过网络与各种网络实体进行通信。通过网络策略，用户可以在同一集群内实现网络隔离，这意味着可以在某些实例（容器组）之间设置防火墙。NetworkPolicy 适用于一端或两端与 Pod 的连接，与其他连接无关。
Pod 可以与之通信的实体是通过如下三个标识符的组合来辩识的：

• 其他被允许的 Pod（例外：Pod 无法阻塞对自身的访问）
• 被允许的名字空间
• IP 组块（例外：与 Pod 运行所在的节点的通信总是被允许的， 无论 Pod 或节点的 IP 地址）

在定义基于 Pod 或名字空间的 NetworkPolicy 时， 你会使用选择算符来设定哪些流量可以进入或离开与该算符匹配的 Pod。

另外，当创建基于 IP 的 NetworkPolicy 时，我们基于 IP 组块（CIDR 范围）来定义策略。

Kubernetes Network Policies 允许管理员定义精细的网络访问规则，限制 Pod 之间的通信。通过在特定的 Namespace 中应用 Network Policies，可以控制一个 Namespace 下的 Pod 是否可以与其他 Namespace 下的 Pod 通信。例如，可以设置策略只允许特定的 Service 或 Pod 访问其他 Namespace 的资源。

利用网络插件
KubeSphere 可以使用多种网络插件，如 Flannel、Calico、Cilium 等，这些插件提供了比标准的 Kubernetes Network Policies 更加丰富的网络隔离和安全功能。例如，Calico 支持更复杂的网络策略，包括 L7 层的策略，允许基于应用标签或协议来过滤流量。

集成第三方工具
除了内置的网络插件之外，KubeSphere 还可以集成如 Istio 这样的服务网格技术，进一步增强网络隔离和安全。Istio 提供了更细粒度的流量管理和安全策略，包括基于身份的认证、授权和加密通信。

总结
在 KubeSphere 中，多租户网络隔离的实现通常包括以下几个层面：

1. 逻辑隔离：KubeSphere 通过 RBAC 对用户的权限加以控制，实现逻辑层面的资源隔离。
2. 访问控制：能够指定如何允许容器组通过网络与各种网络实体进行通信。
3. 增强网络功能：利用网络插件和第三方工具提供更复杂的网络策略和安全功能。

通过这些机制，KubeSphere 能够在多租户环境下提供安全且可控的网络环境，确保每个租户的网络流量和资源访问都被有效地隔离和管理。

END

• Kubernetes 官方文档
• KubeSphere 官方文档

KubeSphere（ v3.4.1）学习记录

• KubeSphere（ v3.4.1）基础问答
• • KubeSphere 中都有哪些组件或服务？
  • Kubernetes 中的 Deployment、StatefulSet、DaemonSet、Job、CronJob、Secret、ConfigMap 是做什么的？
  • 在 KubeSphere 中部署一个 MySQL 服务，都要哪几步？
  • • 准备工作
    • 动手实验
  • Kubernetes 中的 Ingress、Ingress Controller 是做什么的？应用如何对集群外提供服务？
  • 镜像仓库是什么？应用商店是什么？他们有什么关系？
  • 多租户之间如何隔离网络？
• END

KubeSphere（ v3.4.1）基础问答

KubeSphere 中都有哪些组件或服务？

前后端分离
KubeSphere 将 前端 与 后端 分开，实现了面向云原生的设计，后端的各个功能组件可通过 REST API 对接外部系统。 可参考 API文档。下图是系统架构图。

KubeSphere 无底层的基础设施依赖，可以运行在任何 Kubernetes、私有云、公有云、VM 或物理环境（BM）之上。 此外，它可以部署在任何 Kubernetes 发行版上。
KubeSphere 是一个基于 Kubernetes 的企业级多租户容器平台，它提供了丰富的功能和服务来简化 Kubernetes 的使用，并增强了云原生应用的开发、部署和管理流程。KubeSphere 的组件和服务大致可以分为以下几类：

• 组件列表：
  
  
• 服务组件：
  • KubeSphere 应用商店：基于 Helm 的应用商店，用于应用生命周期管理。
  • KubeSphere DevOps：基于 Jenkins 的 KubeSphere DevOps 系统是专为 Kubernetes 中的 CI/CD 工作流设计的，它提供了一站式的解决方案，帮助开发和运维团队用非常简单的方式构建、测试和发布应用到 Kubernetes。
  • KubeSphere 日志系统：KubeSphere 为日志收集、查询和管理提供了一个强大的、全面的、易于使用的日志系统。它涵盖了不同层级的日志，包括租户、基础设施资源和应用。
  • KubeSphere 事件系统：使用户能够跟踪集群内部发生的事件，例如节点调度状态和镜像拉取结果。这些事件会被准确记录下来，并在 Web 控制台中显示具体的原因、状态和信息。
  • KubeSphere 告警系统：告警系统与其主动式故障通知 (Proactive Failure Notification) 系统相结合，使用户可以基于告警策略了解感兴趣的活动。当达到某个指标的预定义阈值时，会向预先配置的收件人发出告警。可以帮助用户迅速发现并提前解决潜在问题，避免业务受影响。
  • KubeSphere 审计日志：提供了一套与安全相关并按时间顺序排列的记录，按顺序记录了与单个用户、管理人员或系统其他组件相关的活动。对 KubeSphere 的每个请求都会生成一个事件，然后写入 Webhook，并根据一定的规则进行处理。
  • KubeSphere 服务网格：基于 Istio，将微服务治理和流量管理可视化。它拥有强大的工具包，包括熔断机制、蓝绿部署、金丝雀发布、流量镜像、链路追踪、可观测性和流量控制等。
  • 网络策略：网络策略是一种以应用为中心的结构，使能够指定如何允许容器组通过网络与各种网络实体进行通信。通过网络策略，用户可以在同一集群内实现网络隔离，这意味着可以在某些实例（容器组）之间设置防火墙。
  • Metrics Server：KubeSphere 支持用于部署的容器组（Pod）弹性伸缩程序 (HPA)。在 KubeSphere 中，Metrics Server 控制着 HPA 是否启用。您可以根据不同类型的指标（例如 CPU 和内存使用率，以及最小和最大副本数），使用 HPA 对象对部署 (Deployment) 自动伸缩。
  • 服务拓扑图：可以启用服务拓扑图以集成 Weave Scope（Docker 和 Kubernetes 的可视化和监控工具）。Weave Scope 使用既定的 API 收集信息，为应用和容器构建拓扑图。服务拓扑图显示在您的项目中，将服务之间的连接关系可视化。
  • 容器组 IP 池：容器组 IP 池用于规划容器组网络地址空间，每个容器组 IP 池之间的地址空间不能重叠。创建工作负载时，可选择特定的容器组 IP 池，这样创建出的容器组将从该容器组 IP 池中分配 IP 地址。
  • KubeEdge：KubeEdge 是一个开源系统，用于将容器化应用程序编排功能扩展到边缘的主机。KubeEdge 支持多个边缘协议，旨在对部署于云端和边端的应用程序与资源等进行统一管理。

Kubernetes 中的 Deployment、StatefulSet、DaemonSet、Job、CronJob、Secret、ConfigMap 是做什么的？

在 Kubernetes 中，各种资源对象（Resources）被设计用来描述和管理应用程序的运行状态。以下是一些关键资源对象的功能介绍：

1. Deployment
   Deployment 是用于声明式更新应用程序副本的控制器。它管理 ReplicaSet，并向 Pod 提供声明式的更新以及许多其他有用的功能。它确保任何时候都有指定数量的实例（Pods）正在运行，并且能够平滑地更新应用版本。当 Pod 出现故障时，Deployment 会自动重启 Pod。它是 Kubernetes 中最常用的应用程序部署方式之一。
   ReplicaSet：目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合。 因此，它通常用来保证给定数量的、完全相同的 Pod 的可用性。

2. StatefulSet

   • StatefulSet 是用来管理有状态应用的工作负载 API 对象。
   • StatefulSet 用来管理某 Pod 集合的部署和扩缩， 并为这些 Pod 提供持久存储和持久标识符。

   和 Deployment 类似， StatefulSet 管理基于相同容器规约的一组 Pod。但和 Deployment 不同的是， StatefulSet 为它们的每个 Pod 维护了一个有粘性的 ID。这些 Pod 是基于相同的规约来创建的， 但是不能相互替换：无论怎么调度，每个 Pod 都有一个永久不变的 ID。
   如果希望使用存储卷为工作负载提供持久存储，可以使用 StatefulSet 作为解决方案的一部分。 尽管 StatefulSet 中的单个 Pod 仍可能出现故障， 但持久的 Pod 标识符使得将现有卷与替换已失败 Pod 的新 Pod 相匹配变得更加容易。

3. DaemonSet

   • DaemonSet 确保所有（或某些）节点上运行一个 Pod 的副本。例如，你可能希望在集群中的每个节点上运行一个日志代理或监控代理。
   • DaemonSet 保证即使节点增加或减少，每个节点上的 Pod 副本数也会保持一致。
   • 删除 DaemonSet 将会删除它创建的所有 Pod。

4. Job

   • Job 会创建一个或者多个 Pod，并将继续重试 Pod 的执行，直到指定数量的 Pod 成功终止。 随着 Pod 成功结束，Job 跟踪记录成功完成的 Pod 个数。 当数量达到指定的成功个数阈值时，任务（即 Job）结束。
   • 删除 Job 的操作会清除所创建的全部 Pod。
   • 挂起 Job 的操作会删除 Job 的所有活跃 Pod，直到 Job 被再次恢复执行。

5. CronJob

   • CronJob 创建基于时隔重复调度的 Job。
   • CronJob 用于执行排期操作，例如备份、生成报告等。 一个 CronJob 对象就像 Unix 系统上的 crontab（cron table）文件中的一行。 它用 Cron 格式进行编写， 并周期性地在给定的调度时间执行 Job。
   • CronJob 有所限制，也比较特殊。 例如在某些情况下，单个 CronJob 可以创建多个并发任务。

6. Secret

   • Secret 是一种包含少量敏感信息例如密码、令牌或密钥的对象。 这样的信息可能会被放在 Pod 规约中或者镜像中。 使用 Secret 意味着你不需要在应用程序代码中包含机密数据。
   • 由于创建 Secret 可以独立于使用它们的 Pod， 因此在创建、查看和编辑 Pod 的工作流程中暴露 Secret（及其数据）的风险较小。 Kubernetes 和在集群中运行的应用程序也可以对 Secret 采取额外的预防措施， 例如避免将敏感数据写入非易失性存储。
   • Secret 类似于 ConfigMap 但专门用于保存机密数据。

7. ConfigMap

   • ConfigMap 是一种 API 对象，用来将非机密性的数据保存到键值对中。使用时， Pod 可以将其用作环境变量、命令行参数或者存储卷中的配置文件。
   • ConfigMap 将你的环境配置信息和容器镜像解耦，便于应用配置的修改。

在 KubeSphere 中部署一个 MySQL 服务，都要哪几步？

在 KubeSphere 中部署 MySQL 服务通常需要遵循以下步骤：

准备工作

• 需要启用 OpenPitrix 系统。
• 需要创建一个企业空间、一个项目和一个用户帐户 (project-regular)。该用户必须是已邀请至项目的平台普通用户，并且在项目中的角色为 operator。在本教程中，需要以 project-regular 用户登录，并在 demo-workspace 企业空间的 demo-project 项目中进行操作。有关更多信息，请参见创建企业空间、项目、用户和角色。

动手实验

• 步骤 1：从应用商店部署 MySQL
  1. 在 demo-project 的概览页面，点击左上角的应用商店。
  2. 找到 MySQL，在应用信息页面点击安装。
  3. 设置应用名称和版本，确保 MySQL 部署在 demo-project 项目中，然后点击下一步。
  4. 在应用设置页面，取消对 mysqlRootPassword 字段的注释并设置密码，然后点击安装。
  5. 等待 MySQL 创建完成并开始运行。
• 步骤 2：访问 MySQL 终端
  1. 打开工作负载页面并点击 MySQL 的工作负载名称。
  2. 在容器组区域，展开容器详情，点击终端图标。
  3. 在终端窗口中，执行 mysql -uroot -ptesting 命令以 root 用户登录 MySQL。
• 步骤 3：从集群外访问 MySQL 数据库
  要从集群外访问 MySQL，您需要先用 NodePort 暴露该应用。
  1. 打开服务页面并点击 MySQL 的服务名称。
  2. 点击更多操作，在下拉菜单中选择编辑外部访问。
  3. 将访问模式设置为 NodePort 并点击确定。有关更多信息，请参见项目网关。
  4. 可以在端口区域查看暴露的端口。该端口号和公网 IP 地址将在下一步用于访问 MySQL 数据库。
  5. 需要使用 MySQL Client 或第三方应用（例如 SQLPro Studio）才能访问 MySQL 数据库。以下演示如何使用 SQLPro Studio 访问 MySQL 数据库。
     
     
     （备注：取决于您的 Kubernetes 集群的部署位置，您可能需要在安全组中放行端口并配置相关的端口转发规则。）
  6. 有关 MySQL 的更多信息，请参考 MySQL 官方文档。

Kubernetes 中的 Ingress、Ingress Controller 是做什么的？应用如何对集群外提供服务？

在 Kubernetes 中，Ingress 和 Ingress Controller 是用于管理和配置集群外部对集群内部服务的访问的关键组件。实际上，Ingress 相当于一个 7 层的负载均衡器，是Kubernetes 对反向代理的一个抽象，他的工作原理类似于 Nginx。下面是对它们的详细解释：

Ingress

• Ingress 提供从集群外部到集群内服务的 HTTP 和 HTTPS 路由。 流量路由由 Ingress 资源所定义的规则来控制。
• 通过配置，Ingress 可为 Service 提供外部可访问的 URL、对其流量作负载均衡、 终止 SSL/TLS，以及基于名称的虚拟托管等能力。
• Ingress 控制器 负责完成 Ingress 的工作，具体实现上通常会使用某个负载均衡器， 不过也可以配置边缘路由器或其他前端来帮助处理流量。

Ingress 的工作原理（以 Nginx 为例）如下：

1. 用户编写 Ingress 规则，说明哪个域名对应 Kubernetes 集群中的哪个 Service；
2. Ingress 控制器动态感知 Ingress 服务规则的变化，然后生成一段对应的 Nginx 反向代理配置；
3. Ingress 控制器会将生成的 Nginx 配置写入到一个运行着的 Nginx 服务中，并动态更新；
4. 到此为止，其实真正在工作的就是一个 Nginx 了，内部配置了用户定义的请求转发规则。

（说明：入口（Ingress）目前已停止更新。新的功能正在集成至网关 API 中）

Ingress Controller
Ingress Controller 是 Kubernetes 集群中运行的一个组件，它实现了 Ingress 资源的规则。Ingress Controller 监听 Kubernetes API Server 中的 Ingress 对象变化，并根据这些规则配置相应的负载均衡器或反向代理服务器。常见的 Ingress Controller 包括：

• Nginx Ingress Controller
• Traefik Kubernetes Ingress 提供程序
• Apache HTTP Server (mod_proxy_ajp)
• HAProxy Ingress

Ingress Controller 通常运行在 Pod 内，并且通常绑定到集群的边缘节点，如 LoadBalancer 类型的服务或 NodePort 服务，从而能够接收外部流量。

如何对外提供服务？

要让 Kubernetes 集群内部的服务对集群外部提供服务，你可以采取以下步骤：

1. 创建 Service：
   首先，为你的应用创建一个 Service。Service 定义了如何访问应用的逻辑集合，可以使用 ClusterIP、NodePort 或 LoadBalancer 类型。
2. 创建 Ingress：
   接着，创建一个 Ingress 对象，其中包含将外部请求路由到内部 Service 的规则。
3. 部署 Ingress Controller：
   如果你的集群中尚未部署 Ingress Controller，则需要部署一个。这通常涉及到安装和配置 Ingress Controller 的部署配置。
4. 配置域名和证书：
   如果需要，可以配置 Ingress 来使用自定义域名，并通过 Ingress Controller 管理 SSL/TLS 证书。
5. 验证外部访问：
   最后，通过浏览器或其他工具尝试访问你的应用，确保 Ingress Controller 正确地将外部请求路由到了集群内部的服务。

Ingress 和 Ingress Controller 提供了一个灵活且强大的机制来管理集群内外部的网络流量，这对于在生产环境中运行的多服务架构尤其重要。它们不仅简化了服务发现和负载均衡，还提供了 SSL/TLS 终止、URL 路由等高级功能。

镜像仓库是什么？应用商店是什么？他们有什么关系？

在 KubeSphere 中，镜像仓库和应用商店都是重要的组成部分，服务于不同的目的，但它们之间存在一定的关联。让我们逐一了解它们的作用及其相互关系：

镜像仓库 (Image Registry)
镜像仓库可用于存储和分发 Docker 镜像。在 Kubernetes 或 KubeSphere 环境中，容器的运行依赖于预先构建的镜像，而这些镜像需要从镜像仓库拉取。镜像仓库可以是公共的，如 Docker Hub，也可以是私有的，如 Harbor、Quay.io 或者其他自建的仓库。

在 KubeSphere 中，镜像仓库的集成意味着用户可以轻松地从预配置的仓库中拉取镜像来部署应用，无需每次手动指定仓库地址。这提高了部署效率和安全性，尤其是对于大型组织而言，使用私有镜像仓库可以控制镜像来源，减少网络延迟，并保护知识产权。

应用商店 (Application Store)
KubeSphere 集成了 OpenPitrix（一个跨云管理应用程序的开源平台）来构建应用商店，管理应用程序的整个生命周期。应用商店支持两种应用程序部署方式：

• 应用模板：这种方式让开发者和独立软件供应商 (ISV) 能够与企业空间中的用户共享应用程序。也可以在企业空间中导入第三方应用仓库。
• 自制应用：这种方式帮助用户使用多个微服务来快速构建一个完整的应用程序。KubeSphere 让用户可以选择现有服务或者创建新的服务，用于在一站式控制台上创建自制应用。

应用商店是 KubeSphere 的一个特色功能，它提供了一个基于 Helm 的界面，允许用户一键部署云原生应用。Helm 是 Kubernetes 的包管理器，它使用模板化的配置文件（称为 Charts）来描述应用的部署结构，包括镜像、配置、服务等。通过应用商店，用户可以从一个中心位置找到、部署和管理各种应用，无需深入了解底层的 Kubernetes 配置。

应用商店通常包含了一系列预先审核和打包的 Helm Charts，这些 Charts 可以是 KubeSphere 自带的，也可以是由第三方开发者或 ISV（独立软件供应商）提供的。用户可以通过应用商店搜索、预览、部署和更新应用，简化了应用的生命周期管理。

关系
镜像仓库和应用商店之间的关系在于，应用商店中的应用通常是基于 Helm Charts 构建的，而这些 Charts 可能引用了存储在镜像仓库中的 Docker 镜像。当用户从应用商店部署应用时，KubeSphere 会从指定的镜像仓库拉取应用所需的镜像，然后根据 Helm Chart 的配置进行部署。

因此，镜像仓库提供了应用部署的基础资源，而应用商店则是面向用户的前端接口，它封装了部署过程，使其更加用户友好和自动化。两者结合，使得在 KubeSphere 中部署和管理复杂应用变得更加简便和高效。

多租户之间如何隔离网络？

KubeSphere 提供了基于 Kubernetes 的多租户管理方案。

在 KubeSphere 中企业空间是最小的租户单元，企业空间提供了跨集群、跨项目（即 Kubernetes 中的命名空间）共享资源的能力。企业空间中的成员可以在授权集群中创建项目，并通过邀请授权的方式参与项目协同。

用户是 KubeSphere 的帐户实例，可以被设置为平台层面的管理员参与集群的管理，也可以被添加到企业空间中参与项目协同。

多级的权限控制和资源配额限制是 KubeSphere 中资源隔离的基础，奠定了多租户最基本的形态。

逻辑隔离
与 Kubernetes 相同，KubeSphere 通过 RBAC 对用户的权限加以控制，实现逻辑层面的资源隔离。

KubeSphere 中的权限控制分为平台、企业空间、项目三个层级，通过角色来控制用户在不同层级的资源访问权限。

• 平台角色：主要控制用户对平台资源的访问权限，如集群的管理、企业空间的管理、平台用户的管理等。
• 企业空间角色：主要控制企业空间成员在企业空间下的资源访问权限，如企业空间下项目、DevOps 项目的管理等。
• 项目角色：主要控制项目下资源的访问权限，如工作负载的管理、流水线的管理等。

网络策略（Network Policies）
网络策略是一种以应用为中心的结构，使能够指定如何允许容器组通过网络与各种网络实体进行通信。通过网络策略，用户可以在同一集群内实现网络隔离，这意味着可以在某些实例（容器组）之间设置防火墙。NetworkPolicy 适用于一端或两端与 Pod 的连接，与其他连接无关。
Pod 可以与之通信的实体是通过如下三个标识符的组合来辩识的：

• 其他被允许的 Pod（例外：Pod 无法阻塞对自身的访问）
• 被允许的名字空间
• IP 组块（例外：与 Pod 运行所在的节点的通信总是被允许的， 无论 Pod 或节点的 IP 地址）

在定义基于 Pod 或名字空间的 NetworkPolicy 时， 你会使用选择算符来设定哪些流量可以进入或离开与该算符匹配的 Pod。

另外，当创建基于 IP 的 NetworkPolicy 时，我们基于 IP 组块（CIDR 范围）来定义策略。

Kubernetes Network Policies 允许管理员定义精细的网络访问规则，限制 Pod 之间的通信。通过在特定的 Namespace 中应用 Network Policies，可以控制一个 Namespace 下的 Pod 是否可以与其他 Namespace 下的 Pod 通信。例如，可以设置策略只允许特定的 Service 或 Pod 访问其他 Namespace 的资源。

利用网络插件
KubeSphere 可以使用多种网络插件，如 Flannel、Calico、Cilium 等，这些插件提供了比标准的 Kubernetes Network Policies 更加丰富的网络隔离和安全功能。例如，Calico 支持更复杂的网络策略，包括 L7 层的策略，允许基于应用标签或协议来过滤流量。

集成第三方工具
除了内置的网络插件之外，KubeSphere 还可以集成如 Istio 这样的服务网格技术，进一步增强网络隔离和安全。Istio 提供了更细粒度的流量管理和安全策略，包括基于身份的认证、授权和加密通信。

总结
在 KubeSphere 中，多租户网络隔离的实现通常包括以下几个层面：

1. 逻辑隔离：KubeSphere 通过 RBAC 对用户的权限加以控制，实现逻辑层面的资源隔离。
2. 访问控制：能够指定如何允许容器组通过网络与各种网络实体进行通信。
3. 增强网络功能：利用网络插件和第三方工具提供更复杂的网络策略和安全功能。

通过这些机制，KubeSphere 能够在多租户环境下提供安全且可控的网络环境，确保每个租户的网络流量和资源访问都被有效地隔离和管理。

END

• Kubernetes 官方文档
• KubeSphere 官方文档