规划应用程序部署

可以在 Red Hat OpenShift on IBM Cloud 中运行哪种应用程序？

无状态应用程序

对于云本机环境（如 Kubernetes），首选无状态应用程序。 这种应用程序的迁移和缩放都很简单，因为它们声明依赖项，将配置与代码分开存储，并将后备服务（例如，数据库）视为连接的资源，而不是耦合到应用程序。 应用程序 Pod 无需持久化数据存储或稳定的网络 IP 地址，因此可根据工作负载需求随时终止、重新调度和扩展。 应用程序使用数据库即服务来持久存储数据，使用 NodePort、LoadBalancer 或 Ingress 服务在稳定的 IP 地址上公开工作负载。

有状态应用程序

相比无状态应用程序，有状态应用程序的设置、管理和缩放都更加复杂，因为 pod 需要持久数据和稳定的网络身份。 有状态应用程序通常是数据库或其他分布式数据密集型工作负载，在这些工作负载中，处理的效率更接近数据本身。 如果要部署有状态应用程序，那么需要设置持久存储器，并将持久卷安装到由 StatefulSet 对象控制的 pod。 可以选择将文件存储器、 块存储器或对象存储器添加为有状态集的持久存储器。 您还可以在裸机工作节点上 Portworx 安装，并将其 Portworx 作为高可用性软件定义存储解决方案，用于管理状态化应用程序的持久化存储。 有关状态化集合的工作原理的更多信息，请参阅 文档 Kubernetes。

开发无状态云本机应用程序的一些准则是什么？

了解十二要素应用，这是一种语言中立的方法论，用于从十二个要素考量应用开发，具体如下：

1. 代码库: 在版本控制系统中对部署使用单个代码库。 拉取用于容器部署的映像时，指定已测试映像标记，而不是使用 latest。
2. 依赖项：显式声明和隔离外部依赖项。
3. 配置：在环境变量中（而不是在代码中）存储特定于部署的配置。
4. 后备服务：将后备服务（例如，数据存储或消息队列）视为已连接或可替换的资源。
5. 应用程序阶段：在不同的阶段（例如，build、release 和 run）中进行构建，并严格分离各个阶段。
6. 进程：作为不共享任何内容的一个或多个无状态进程运行，并使用持久存储器来保存数据。
7. 端口绑定：端口绑定是自包含的，并且在定义明确的主机和端口上提供服务端点。
8. 并行：通过进程实例（例如，副本和水平缩放）来管理和缩放应用程序。 为部署设置资源请求和限制。 请注意，Calico 网络策略无法限制带宽。
9. 一次性：将应用程序设计为一次性的，启动工作极少，可正常关闭，并能容忍进程突然终止。 请记住，容器、pod 甚至工作程序节点都应该是一次性的，因此请相应地规划应用程序。
10. 开发环境与生产环境一致性：为应用程序建立持续集成和持续交付管道，确保开发环境中的应用程序与生产环境中的应用程序之间差异最小。
11. 日志：将日志视为事件流：外部或托管环境会处理和路由日志文件。 重要信息：在 Red Hat OpenShift on IBM Cloud 中，缺省情况下不会开启日志。 要启用，请参阅配置日志转发。
12. 管理进程：将任何一次性管理脚本与应用程序一同保存，并作为 作业 Kubernetes 对象运行，以确保管理脚本在与应用程序本身相同的环境中执行。 若需在集群 Kubernetes 中运行大型软件包，建议使用包管理器（如 Helm ）进行编排。

无服务器应用程序如何?

您可以通过该 IBM Cloud Code Engine 服务运行无服务器应用和任务。Code Engine 该服务还能为您构建镜像。

我已有应用程序。 如何将其迁移到 Red Hat OpenShift on IBM Cloud？

您可以执行一些常规步骤来对应用程序进行容器化，如下所示。

1. 将十二要素应用作为指南，用于隔离依赖关系、将进程拆分为独立服务，并尽可能降低应用的状态依赖性。
2. 查找要使用的相应基本映像。 您可以使用 Hub Docker 中的公开图像、公共 IBM 图像，或在私有存储中构建和管理 IBM Cloud Container Registry 自己的图像。
3. 仅将运行应用程序所必需的内容添加到 Docker 映像。
4. 查看 常见应用程序修改方案。
5. 不要依赖本地存储器，而是改为计划使用持久存储器或云数据库即服务解决方案来备份应用程序的数据。
6. 随着时间的推移，将应用程序进程重构为微服务。

授予部署特权访问权的示例步骤

若您的应用程序以root权限运行，则必须修改部署方案，使其符合集群 Red Hat OpenShift 设置 的安全上下文约束。 例如，您可以通过服务账户设置项目来控制特权访问，然后修改部署配置以使用该服务账户。

开始之前: 访问 Red Hat OpenShift 集群。

1. 以集群管理员身份创建项目。

   oc adm new-project <project_name>
   

2. 将该项目设定为目标，以便后续创建的资源位于该项目名称空间中。

   oc project <project_name>
   

3. 为项目创建服务帐户。

   oc create serviceaccount <sa_name>
   

4. 将特权安全上下文约束添加到项目的服务帐户。 若需查看 SCC privileged 中包含哪些策略，请运行 oc describe scc privileged. 有关SCCs的更多信息，请参阅 文档 Red Hat OpenShift。

   oc adm policy add-scc-to-user privileged -n <project_name> -z <sa_name>
   

5. 在部署配置文件中，引用特权服务帐户，并将安全上下文设置为 privileged。

   • 在 spec.template.spec 中，添加 serviceAccount: <sa_name>。
   • 在 spec.template.spec.containers 中，添加 securityContext: privileged: true。

   示例

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: myapp_deployment
     labels:
       app: myapp
   spec:
     ...
     template:
       ...
       spec:
         serviceAccount: <sa_name>
         containers:
         - securityContext:
             privileged: true
         ...
   

6. 部署应用程序配置文件。

   oc apply -f <filepath/deployment.yaml>
   

7. 检查 pod 是否处于 Running 状态。 如果 pod 显示错误状态或长时间卡在某个状态，请描述该 pod 并查看 Events 部分以开始对部署进行故障诊断。

   oc get pods
   

我以为自己需要把应用程序放入容器中。 现在，pod 中都有哪些相关内容？

一个 pod 是可 Kubernetes 管理的最小部署单元。 将容器（或一组容器）放入 pod 中，并使用 pod 配置文件来指示 pod 如何运行容器以及与其他 pod 共享资源。 您放入 pod 中的所有容器都在共享环境中运行，这意味着它们共享同一台虚拟机或物理机。

要放入容器中的内容

在考虑应用程序的组件时，请评估它们在CPU和内存等资源需求方面是否存在显著差异。 对于以最佳性能运行的某些组件，在将资源转移到其他区域期间，可以接受这些组件停止运行一小会儿吗？ 是否有面向客户的其他组件，使其保持运行至关重要？ 如果有这类组件，请将其拆分放入不同的容器中。 您始终可以将这些组件部署到同一 pod，使其同步运行。

要放入 pod 中的内容

应用程序的容器不必始终位于同一 pod 中。 事实上，如果有一个有状态且难以缩放的组件（例如，数据库服务），请将其放入其他 pod 中，然后可以将该 pod 安排在使用更多资源来处理工作负载的工作程序节点上。 如果在不同工作程序节点上运行的容器可以正常工作，请使用多个 pod。 如果容器需要位于同一机器上并一起缩放，请将容器分组到同一 pod 中。

既然我可以使用一个 Pod，为什么还需要这么多不同类型的对象呢？

创建 pod YAML 文件非常简单。 您可以编写只包含下面几行的 pod YAML 文件。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

但是，您并不希望就此止步。 如果运行 pod 所在的节点停止运行，那么 pod 会随之停止运行，并且不会重新安排该 pod。 相反，应使用部署来支持 Pod 重调度、副本集和滚动更新。 创建基本部署几乎与创建 pod 一样容易。 但是，不要在 spec 中定义容器本身，请改为在部署 replicas 中指定 template 和 spec。 对于模板中的容器，模板具有自己的 spec，如下所示。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

可以持续添加功能，例如 pod 反亲缘关系或资源限制，所有这些都在同一 YAML 文件中添加。

有关可添加到部署中的不同功能的详细说明，请参阅 《创建应用部署 YAML 文件》。

我可以为自己的应用程序创建什么类型的 Kubernetes 对象？

准备应用程序 YAML 文件时，您有许多选项可用于提高应用程序的可用性、性能和安全性。 例如，您可以不使用单个 pod，而改为使用 Kubernetes 控制器对象来管理工作负载（例如，副本集、作业或守护程序集）。 有关 Pod 和控制器更多信息，请参阅 文档 Kubernetes。 用于管理 pod 副本集的部署是应用程序的常见用例。

例如，要部署应用程序 pod，kind: Deployment 对象是一个不错的选择，因为使用该对象，可以指定副本集，从而提高 pod 的可用性。

下表描述了您可能会创建不同类型 Kubernetes 工作负载对象的原因。

如果我想让我的应用程序配置使用变量怎么办？ 如何将这些变量添加到YAML中？

要在部署中添加可变信息，而非将数据硬编码到 YAML 文件中，您可以使用 或 Secret KubernetesConfigMap 对象。

要使用配置映射或私钥，您需要将其安装到 pod。 就在运行 pod 之前，配置映射或私钥会与 pod 组合在一起。 您可以跨许多应用程序复用部署规范和映像，但要交换出定制的配置映射和私钥。 尤其是私钥可能会在本地节点上占用大量存储空间，因此请相应地进行规划。

这两个资源都会定义键/值对，但这些对将用于不同的情境。

配置映射

为部署中指定的工作负载提供非敏感配置信息。 您可以通过三种主要方式来使用配置映射。

• 文件系统：您可以将整个文件或一组变量挂载到 Pod 上。 系统将根据文件中设置为该值的键名内容为每个条目创建一个文件。
• 环境变量：为容器规范动态设置环境变量。
• 命令行选项：设置在容器规范中使用的命令行选项。

私钥

为工作负载提供敏感信息，例如以下信息。 请注意，集群的其他用户可能有权访问私钥，因此请确保您确定可以与这些用户共享私钥信息。

• 个人身份信息（PII）：将电子邮件地址等敏感信息，或公司合规要求及政府法规所需的其他类型信息保密存储。
• 凭证：将密码、密钥和令牌等凭证存入密钥库，以降低意外泄露的风险。 例如，绑定服务到集群时，凭证会存储在私钥中。

想要使私钥更安全吗？ 请求集群管理员在集群中 启用密钥管理服务提供者 以加密新密钥和现有密钥。

如何确保我的应用程序拥有正确的资源？

在指定应用程序的 YAML 文件 时，您可以为应用程序配置添加 Kubernetes 功能，这些功能有助于应用程序获取正确的资源。 特别地，为YAML文件中定义的每个容器 设置资源限制和请求。

此外，集群管理员可能会设置可影响应用程序部署的资源控制，例如以下各项。

• 资源配额
• pod 优先级

如何为我的应用程序配置添加功能？

请参阅在 YAML 文件中指定应用程序需求，以获取有关部署中可包含的内容的描述。 此示例包含以下选项。

• 副本集
• 标签
• 亲缘关系
• 映像策略
• 端口
• 资源请求和限制
• 活性和就绪性探测器
• 用于在端口上暴露应用程序服务的 服务。
• Configmaps 用于设置容器环境变量。
• 私钥，用于设置容器环境变量。
• 安装到容器以进行存储的 持久卷。

如何向我的应用添加 IBM 服务，例如 Watson？

请参阅向应用程序添加服务。

如何提高应用程序的可用性?

请考虑以下选项以提高应用程序的可用性。

使用部署和副本集来部署应用程序及其依赖项

部署是一个 Kubernetes 资源，可用于声明应用程序的所有组件及其依赖项。 借助部署功能，您无需手动记录所有步骤，而是可以专注于应用程序本身。 当您部署多个 Pod 时，系统会自动为部署创建副本集，该副本集负责监控 Pod 并确保指定数量的 Pod 处于运行状态。 pod 发生故障时，副本集会将无响应的 pod 替换为新的 pod。 您可以使用部署来定义应用程序的更新策略，包括在滚动更新期间要添加的 pod 数，以及允许同时不可用的 pod 数。 执行滚动更新时，部署系统会检查修订版本是否正常运行，一旦检测到故障就会停止发布。 通过部署功能，您可以同时部署多个具有不同选项的修订版本。 例如，您可以先测试部署，然后再决定是否将其推送到生产环境。 通过使用部署，可以跟踪任何已部署的修订版。 如果遇到更新无法按预期运行的情况，可以使用此历史记录回滚到上一个版本。

包含足够多的副本用于应用程序的工作负载，在此基础上再额外增加两个副本

要使应用程序具有更高可用性且在出现故障时能够更快恢复，请考虑在处理预期工作负载所需最低要求的副本数基础上，再包含额外的副本。 在某个 pod 崩溃且副本集尚未恢复已崩溃 pod 的情况下，额外的副本可处理工作负载。 要针对同时发生两个故障的情况进行防护，请包含两个额外的副本。 此设置是 N+2 模式，其中 N 是处理入局工作负载的副本数，+2 是额外两个副本。 只要集群具有足够的空间，就可以拥有任意数量的 pod。

跨多个节点分布 pod（反亲缘关系）

创建部署时，各个 pod 可部署到同一工作程序节点。 这被称为亲和性，或称同位。 为保护应用免受工作节点故障的影响，您可以在标准集群中使用 选项 podAntiAffinity 配置部署，将 Pod 分布到多个工作节点上。 可以定义两种类型的 pod 反亲缘关系：首选或必需。 有关更多信息，请参阅《 将 Pod 分配Kubernetes 到节点》文档。

有关应用程序部署中的亲缘关系的示例，请参阅创建应用程序部署 YAML 文件。

跨多个专区或区域分布 pod

要保护应用程序不受专区故障的影响，可以在不同专区中创建多个集群，或者向多专区集群的工作程序池添加专区。 多专区集群仅在某些 经典 或 VPC 多专区 (例如达拉斯) 中可用。 如果在不同专区中创建多个集群，那么必须 设置全局负载均衡器。 使用副本集并指定 pod 反亲缘关系时，Kubernetes 会跨节点分布应用程序 pod。 如果节点位于多个专区中，那么 pod 会跨这些专区分布，从而提高应用程序的可用性。 如果要限制应用程序仅在一个专区中运行，您可以配置 pod 亲缘关系，或者在一个专区中创建并标记工作程序池。

在多区域集群部署中，我的应用程序Pod是否均匀分布在各个节点上？

pod 会跨专区均匀分布，但不一定会跨节点均匀分布。 例如，如果有一个集群在 3 个专区中分别有 1 个节点，并且部署了包含 6 个 pod 的副本集，那么每个节点会获得 2 个 pod。 但是，如果集群在 3 个专区中分别有 2 个节点，并且部署了包含 6 个 pod 的副本集，那么每个专区会安排 2 个 pod，这 2 个 pod 可能会每个节点安排 1 个，也可能 2 个 pod 都安排在一个节点上。 若需更精细地控制调度，可 设置 Pod 亲和性。

如果某个区域发生故障，如何将Pod重新调度到其他区域中剩余的节点上？

这取决于您在部署中使用的安排策略。 若您启用了 节点特定的Pod亲和性，则Pod不会被重新调度。 如果未包含此策略，那么会在其他专区中的可用工作程序节点上创建 pod，但可能不会对这些 pod 进行均衡。 例如，这 2 个 pod 可能分布在 2 个可用节点上，也可能都安排到 1 个具有可用容量的节点上。 与此类似，当不可用专区恢复时，不会自动删除 pod 并跨节点对这些 pod 进行重新均衡。 若需在区域恢复后重新平衡各区域的负载，请配置 调度 Kubernetes 器。 在多区域集群中，请尽量将每个区域的工作节点容量保持在50%，以确保保留足够的容量来保护集群免受区域故障的影响。

如果我想将我的应用程序扩展到多个地区呢？

为保护应用免受区域故障影响，请在另一区域创建第二个 集群，设置全局负载均衡器连接两个集群，并使用部署YAML文件为应用部署具有 Pod反亲和性的副本集副本。

如果我的应用程序需要持久化存储怎么办？

使用云服务，例如 IBM Cloudant 或 IBM Cloud Object Storage。

如何扩展我的应用程序？

如果要动态添加和除去应用程序以响应工作负载使用情况，请参阅 缩放应用程序 以获取用于启用水平 pod 自动缩放的步骤。

如何组织部署以使其更容易更新和管理？

既然您已清楚地了解要在部署中包含哪些内容，您可能会想知道如何管理所有这些不同的 YAML 文件？ 当然还包括这些文件在 Kubernetes 环境中创建的对象！

以下提示可帮助您组织部署 YAML 文件。

• 使用版本控制系统，例如 Git。
• 将紧密相关的 Kubernetes 对象分组在单个 YAML 文件中。 例如，如果要创建 deployment，那么还可以将 service 文件添加到 YAML。 使用 --- 分隔对象，如以下示例中所示。

  apiVersion: apps/v1
  kind: Deployment
  metadata:
  ...
  ---
  apiVersion: v1
  kind: Service
  metadata:
  ...
  

• 您可以使用该 oc apply -f 命令对整个目录进行操作，而不仅限于单个文件。
• 请试用 kustomize 项目，此项目可用于帮助编写、定制和复用 Kubernetes 资源 YAML 配置。

在 YAML 文件中，可以使用标签或注释作为元数据来管理部署。

标签

标签是可附加到 Kubernetes 对象（如Pod key:value 和部署）上的键值对。 标签可以是您所需的任何内容，并且在根据标签信息选择对象时非常有用。 标签是对对象分组的基础。 请参阅以下示例以了解有关标签的构想。

• app: nginx
• version: v1
• env: dev

注释

注释与标签相似，它们同样是 key:value 键值对。 注释更适用于工具或库可以利用的非标识信息，例如保存有关对象来源的额外信息、如何使用对象的信息、指向相关跟踪存储库的指针或有关对象的策略。 您不可基于注释来选择对象。

可以使用哪些应用程序更新策略？

要更新应用程序，可以从各种策略中进行选择，例如以下策略。 在执行更复杂的金丝雀部署之前，您可能要首先执行滚动部署或即时切换。

滚动部署

可以使用 Kubernetes 本机功能来创建 v2 部署，并逐渐替换先前的 v1 部署。 此方法要求应用程序与早期版本兼容，确保使用该 v2 应用程序版本的用户不会遇到任何破坏性变更。 有关更多信息，请参阅管理滚动部署来更新应用程序。

即时切换

即时切换也称为蓝绿部署，这种方法需要将计算资源加倍，以同时运行两个版本的应用程序。 通过此方法，可以近乎实时地将用户切换到更高版本。 请确保使用服务标签选择器（例如 version: green 和 version: blue）来确保请求被发送到正确的应用程序版本。 可以创建新的 version: green 部署，等待它准备就绪，然后删除 version: blue 部署。 或者，您可以执行 滚动更新，但需将 maxUnavailable 参数设置为 0%，并将 maxSurge 参数设置为 100%。

金丝雀或 A/B 部署

金丝雀部署是更复杂的更新策略，使用此方法时，要求您选取用户百分比（例如，5%），然后将这一比例的用户发送到新的应用程序版本。 可以在日志记录和监视工具中收集有关新应用程序版本执行情况的度量值，执行 A/B 测试，然后将更新应用到更多用户。 与所有部署一样，标注应用程序（例如，version: stable 和 version: canary）至关重要。

如何自动执行应用程序部署？

如果要在多个集群中、公共和专用环境中，或者甚至在多个云提供者中运行应用程序，那么您可能会想知道如何使部署策略在所有这些环境中都有效。 借助 IBM Cloud 和其他开放式源代码工具，您可以打包应用程序以帮助自动执行部署。

设置持续集成和交付 (CI/CD) 管道

通过在源代码控制管理系统（如 Git）中组织的应用程序配置文件，可以构建管道来测试代码，并将代码部署到不同的环境，例如 test 和 prod。 与集群管理员一起 设置持续集成和交付。

打包应用程序配置文件

使用诸如 Kustomize 或 Helm之类的工具来打包应用程序。

• 通过 kustomize 项目，您可以编写，定制和复用 Kubernetes 资源 YAML 配置。
• 使用 包 HelmKubernetes 管理器，您可以在 图表 Helm 中指定应用所需的所有 Kubernetes 资源。 然后，可以使用 Helm 来创建 YAML 配置文件，并在集群中部署这些文件。 您还可以 集成 IBM Cloud-provided Helm 图表来扩展集群的功能，例如使用块存储插件。

要创建 YAML 文件模板吗? 有些人使用 Helm 来实现这个目的，或者你可以尝试其他社区工具，例如 ytt。

如何确保我的服务已连接到正确的部署并准备就绪？

对于大多数服务，请将选择器添加到服务 .yaml 文件，以便它应用于通过该标签运行应用程序的 pod。 很多时候，当应用首次启动时，你并不希望它立即处理请求。 向部署添加就绪性探测器，以便将流量仅发送到被视为准备就绪的 pod。 要查看使用标签并设置就绪探针的服务部署示例，请参阅此 NGINX YAML 文件。

有时，您不希望服务使用标签。 例如，您可能有外部数据库，或者希望将服务指向集群内其他名称空间中的其他服务。 发生这种情况时，您必须手动添加端点对象，并将其链接到服务。

如何在因特网上公开服务？

可以为外部联网创建三种类型的服务：NodePort、LoadBalancer 和 Ingress。

您可根据集群类型选择不同的方案。 有关更多信息，请参阅规划联网服务。

• 标准集群：可以使用 NodePort、LoadBalancer 或 Ingress 服务来公开应用程序。
• 使用 Calico 变为专用的集群：可以使用 NodePort、LoadBalancer 或 Ingress 服务来公开应用程序。 您还必须使用 Calico DNAT 前网络策略来阻止公共节点端口。

在规划集群中需要多少Service对象时，请记住，Kubernetes 是使用 iptables 来处理联网和端口转发规则。 若在集群中运行大量服务（例如5000个），性能可能会受到影响。

如何控制谁有权访问我的应用程序部署？

账户和集群管理员可以在多个不同层级上控制访问权限：集群、Red Hat OpenShift 项目、Pod 和容器。

通过 IBM Cloud IAM，可以在集群实例级别为各个用户、组或服务帐户分配许可权。 您可以通过将用户限制为只能访问集群内的特定名称空间，从而进一步缩小集群访问范围。 有关更多信息，请参阅分配集群访问权。

要在 pod 级别控制访问，您可以配置 安全上下文约束(SCC)。

在应用程序部署 YAML 中，可以为 pod 或容器设置安全上下文。 如需了解更多信息，请查阅 文档 Kubernetes。

部署应用程序后，如何监视其运行状况？

您可以为集群设置 IBM Cloud 日志记录和监视。