可以在 IBM Cloud Kubernetes Service 中运行哪种应用程序？

无状态应用程序

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

有状态应用程序

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

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

查看 十二因素应用程序，这是一种与语言无关的方法，用于考虑如何跨 12 个因素开发应用程序，总结如下。

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

无服务器应用程序如何?

您可以通过 IBM Cloud Code Engine 服务运行无服务器应用程序和作业。Code Engine 还可以为您构建映像。Code Engine 旨在使您无需与它所构建的底层技术进行交互。 但是，如果您有基于 Kubernetes 或 Knative 的现有工具，那么仍可以将其与 Code Engine配合使用。 有关更多信息，请参阅 使用 Kubernetes 与应用程序交互。

我已有应用程序。 如何将其迁移到 IBM Cloud Kubernetes Service？

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

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

我以为自己需要把应用程序放入容器中。 现在，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 文件中，可以使用 Kubernetes ConfigMap 或 Secret 对象。

要使用配置映射或私钥，您需要将其安装到 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 反亲缘关系：首选或必需。 更多信息，请参阅 Kubernetes 关于 将 Pod 分配给节点的文档。

有关应用程序部署中的亲缘关系的示例，请参阅创建应用程序部署 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 进行重新均衡。 如果希望在区域恢复后重新平衡各区域的 pod，请配置 Kubernetes descheduler。 在多区群集中，应尽量将每个区的工作节点容量保持在 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:
  ...
  

• 可以使用 kubectl apply -f 命令来应用于整个目录，而不仅仅是单个文件。
• 请试用 kustomize 项目，此项目可用于帮助编写、定制和复用 Kubernetes 资源 YAML 配置。

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

标签

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

• 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）至关重要。 要管理金丝雀部署，可以 安装受管 Istio 附加服务网格， 为集群设置 Monitoring，然后按照 本博文所述使用 Istio 服务网格进行 A/B 测试。

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

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

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

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

打包应用程序配置文件

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

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

要创建 YAML 文件模板吗? 有些人使用 Helm 来做这件事，您也可以尝试使用其他社区工具，如 ytt.

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

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

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

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

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

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

• 标准集群：可以使用 NodePort、LoadBalancer 或 Ingress 服务来公开应用程序。
• 使用 Calico 变为专用的集群：可以使用 NodePort、LoadBalancer 或 Ingress 服务来公开应用程序。 您还必须使用 Calico DNAT 前网络策略来阻止公共节点端口。
• 仅专用 VLAN 标准集群：可以使用 NodePort、LoadBalancer 或 Ingress 服务 来公开应用程序。 您还必须在防火墙中打开用于该服务的专用 IP 地址的端口。

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

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

帐户和集群管理员可以在许多不同级别控制访问权：集群、Kubernetes 名称空间、pod 和容器。

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

要控制 pod 级别的访问，可以配置 pod 安全策略 (PSP)。

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

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

您可以为集群设置 IBM Cloud 日志记录和监视。 此外，还可以选择与第三方日志记录或监视服务集成。