适用于 Red Hat OpenShift 3.11 的 Citrix Cloud Native Networking 的经过验证的参考设计

Citrix ADC 堆栈满足应用程序可用性功能 (ADC)、安全功能隔离 (WAF)、敏捷应用程序拓扑（SSL 和 GSLB）的扩展以及主动可观察性（服务图）的基本要求，使其成为高度编排的云原生时代环境。

数字化转型推动了将现代应用程序部署转移到基于微服务的架构的需求。这些云原生架构利用应用程序容器、微服务和 Kubernetes。

面向现代应用程序的云原生方法还改变了开发生命周期，包括敏捷工作流、自动化部署工具集以及开发语言和平台。

现代应用程序部署的新时代也改变了传统的数据中心业务模式规范，包括每月和每年的软件发布和合同、孤岛计算资源和预算，以及供应商消费模式。

尽管所有这些现代化都在生态系统中进行，但对于应用程序可用性功能（ADC）、安全功能隔离（WAF）、敏捷应用程序拓扑（SSL和GSLB）的扩展以及主动可观察性（Service Graph）到高度协调的系统仍存在基本要求环境。

为什么选择 Citrix 实现现代应用程序交付

Citrix 软件部署现代应用程序的方法要求在组织内的多个团队中采用敏捷的工作流程。敏捷应用程序开发和交付的优势之一是称为 CI/CD 的框架。

CI/CD 是为现代应用程序生命周期提供速度、安全性和可靠性的一种方式。

持续集成 (CI) 允许使用通用代码库，该代码库每天可以实时更新几次，并集成到自动构建平台中。 持续集成的三个阶段是“推送”、“测试”和“修复”。

持续交付 (CD) 将部署管道直接集成到 CI 开发流程中，从而优化和改进现代应用程序的软件交付模型。

Citrix ADC 通过实施自动化金丝雀分析渐进式部署与持续交付流程相关联。

面向所有利益相关者的解决方案

Citrix 创建了一个基于软件的专用解决方案，该解决方案可满足部署现代应用程序时的跨职能需求，并集成了可观察性堆栈、安全框架和 CI/CD 基础架构的各个组件。

采用 CI/CD 技术部署现代应用程序的传统组织已经认识到需要为参与 CI/CD 的所有成员提供一个通用的交付和可用性框架，这些资源通常被定义为业务部门“利益相关者”，而每个利益相关者都是投资于组织的整体成功，每个利益相关者通常都有不同的要求和差异。

现代交付活动中利益相关者的一些常见例子包括：

• 平台团队—部署数据中心基础架构，例如 IaaS、PaaS、SDN、ADC、WAF
• DevOps 和工程团队-开发和维护统一的代码存储库、自动化工具、软件架构
• 服务可靠性工程 (SRE) 团队—减少组织孤岛、错误管理、部署自动化和测量
• 安全运营团队 — 主动安全策略、事件管理、补丁程序部署、产品组合强化

Citrix 软件堆栈解释

单一代码库-您的代码完全相同 - 本地部署、公有云部署、私有云部署、GOV Cloud 部署

• 平台选择-要满足任何敏捷需求，请选择任何 Citrix ADC 型号

  • CPX — Citrix ADC CPX 是作为容器交付的 Citrix ADC
  • VPX — Citrix ADC VPX 产品是一种虚拟设备，可以托管在各种虚拟化和云平台上，性能从 10 Mb/s 到 100 Gb/s 不等。
  • MPX — Citrix ADC MPX 是一款基于硬件的应用程序交付设备，其性能从 500 MB/s 到 200 GB/s 不等。
  • SDX — Citrix ADC SDX 设备是一个多租户平台，您可以在其中预置和管理多个虚拟 Citrix ADC 计算机（实例）。
  • BLX — Citrix ADC BLX 设备是 Citrix ADC 的软件外形规格。它旨在在商用现成服务器 (COTS) 上的裸机 Linux 上本机运行 容器化环境-创建叠加层并自动配置您的 Citrix ADC -Citri x Ingress Contro ller-围绕 Kubernetes Ingress 构建，并根据入口资源配置自动配置一个或多个 Citrix AD C -Citrix Node控制器 — 在 Kubernetes 节点和 Ingress Citrix ADC （Citrix IPAM 控制器）之间创建基于 VXLAN 的覆盖网络 Citrix IPAM 控制器 自动分配具有 IP 地址（虚拟 IP 地址或 VIP） 池容量的 Citrix ADC 上的负载平衡虚拟服务器许可 — 一个全球许可证 — 无处不在的全球许可证池将平台和许可证分离，从而实现设计和性能的完全灵活性 应用程序交付管理器 — 单一 管理平台 — 管理队列、协调策略和 应用程序、实时监视和故障排除
    灵活的拓扑结构 — 传统数据中心或现代云 — 单层、两层和服务网格精简版

Citrix ADC 的价值

• Kubernetes 和 CNCF 开源工具集成
• Perfect Proxy — 适用于现代应用程序的久经考验的第 7 层应用程序交付控制器
  • Pod 或 Sidecar 部署中的高性能 ADC 容器
  • 使用多个选项低延迟访问 Kubernetes 集群
• 功能丰富的 API — 轻松实施和编排安全功能，不受限制
• 针对 CI/CD 的高级流量控制和 Canary 部署
• 通过 TLS/SSL、WAF、DoS 和 API 保护实现成熟的安全性
• 丰富的第 7 层功能
• 传统和现代应用程序部署的集成监视
• 切实可行的见解和可见性的服务图

Citrix ADC 的好处

• 无需重写旧版应用程序即可移动它们
• 开发人员可以使用 Kubernetes API 通过 Citrix ADC 策略保护应用程序（使用 CRD — 开发人员友好）
• 为南北和服务网格部署高性能微服务
• 对所有微服务使用一个应用服务图
• 通过 TCP、UDP、HTTP/S、SSL 更快地解决微服务问题
• 保护 API 并使用 Kubernetes API 进行配置
• 增强金丝雀部署的 CICD 流程

架构组件

Citrix ADC 套件的优势

Citrix 是选择。 无论您是使用传统数据中心和组件，还是已启动新的云原生现代应用程序，Citrix ADC 都可以无缝集成到您可能具有的任何平台要求中。我们为基于订阅的云平台和工具提供云原生 ADC 功能，允许通过简单的 Ingress Controller 编排将流量引导和编排到本地的 Kubernetes 集群，并解决从简单到复杂的服务网格架构。

Citrix 已通过验证。 通过验证的设计模板和示例应用程序，可以轻松参考所需的状态和业务需求，从而快速、完整地得到满足。我们已在一个中心位置记录和发布了配置示例，以便于 DevOps、SecOps 和平台团队参考。

Citrix 既敏捷又现代。 创建基础架构，让客户使用其现有的 ADC 和新模块（CNC、IPAM 等）使用 Citrix Cloud Native Stack 的新功能

Citrix 已开放。 帮助客户了解我们与合作伙伴生态系统的集成。在本文档中，我们同时使用了 OpenSource CNCF 工具和 Citrix 企业级产品。

合作伙伴生态系统

本主题详细介绍了云原生部署（包括 Citrix ADC 和 Citrix Ingress Controller）中支持的各种 Kubernetes 平台、部署拓扑、功能和 CNI。

以下平台支持 Citrix Ingress Controller：

• Kubernetes v1.10 在裸机上运行，或者在 AWS、GCP 或 Azure 等公有云上自行托管。
• Google Kubernetes Engine (GKE)
• Elastic Kubernetes Service (EKS)
• Azure Kubernetes Service (AKS)
• Red Hat OpenShift 版本 3.11 及更高版本
• Pivotal Container Service (PKS)
• Diamanti Enterprise Kubernetes Platform

我们的合作伙伴生态系统还包括以下内容：

• Prometheus — 指标、警报和见解的监视工具
• Grafana — 用于分析和监视的平台
• Spinnaker-用于多云持续交付和金丝雀的工具- 分析
• Elasticsearch — 应用程序或网站搜索服务
• Kibana — 弹性搜索数据的可视化工具和弹性堆栈导航工具
• Fluentd — 一种数据收集器工具

下一节的重点是使用 OpenShift 进行设计/架构。

OpenShift 概述

Red Hat OpenShift 是一款用于部署的 Kubernetes 平台，专注于使用微服务和容器来更快地构建和扩展应用程序。通过自动化、安装、升级和管理容器堆栈，OpenShift 简化了 Kubernetes 并简化了日常开发运营任务。

• 开发人员为应用程序提供访问经验证的解决方案和合作伙伴的权限，这些解决方案将通过简化的工作流程推送到生产环境。
• 操作可以使用 Web 控制台和内置的日志记录和监视来管理和扩展环境。

图 1-6：OpenShift 高级架构。

OpenShift 的更多优势和组件包括：

• 基础架构的选择
• 主节点和工作节点
• 镜像注册表
• 路由和服务层
• 开发人员操作（已引入，但不在本文档的范围内）

将Red Hat OpenShift 与 Citrix 原生堆栈集成的用例包括：

• 传统应用程序支持
• 作为 API 部署的重写/响应程序策略
• 微服务疑难解答
• 使用安全补丁和功能增强功能进行日常运营

在本文档中，我们将介绍Citric ADC如何提供可靠的路由/服务层集成。

OpenShift 项目

OpenShift 添加的第一个新概念是 project，它有效地封装了一个命名空间，并通过项目控制对命名空间的访问。访问通过基于用户和组的身份验证和授权模型进行控制。因此，OpenShift 中的项目在命名空间之间提供隔离墙，确保用户或应用程序只能看到和访问允许他们访问的内容。

OpenShift 命名空间

在 Kubernetes 中，主要的分组概念是命名空间。命名空间也是在多种用途之间划分集群资源的一种方式。话虽如此，Kubernetes 中的命名空间之间没有安全性。如果您是 Kubernetes 集群中的“用户”，则可以看到所有不同的命名空间以及其中定义的资源。

OpenShift 软件定义网络 (SDN)

OpenShift Container Platform 使用软件定义的网络连接 (SDN) 方法提供统一的群集网络，以便在 OpenShift Container Platform 群集之间实现通信。这个 pod 网络由 OpenShift SDN 建立和维护，后者使用 Open vSwitch (OVS) 配置覆盖网络。

OpenShift SDN 提供了三个 SDN 插件用于配置 pod 网络：

• ovs-subnet 插件是最初的插件，它提供了一个“扁平”的 pod 网络，每个容器都可以与其他每个 pod 和服务进行通信。
• ovs-multitenant 插件为 Pod 和服务提供了项目级隔离。每个项目都会收到一个唯一的虚拟网络 ID (VNID)，用于标识分配给该项目的 Pod 的流量。来自不同项目的 Pod 无法向不同项目的 Pod 和服务发送数据包，也无法从中接收数据包。
• 但是，接收 VNID 0 的项目更有特权，因为它们可以与所有其他 Pod 通信，并且所有其他 Pod 都可以与它们通信。在 OpenShift 容器平台集群中，默认项目具有 VNID 0。这有助于某些服务（例如负载均衡器）与集群中的所有其他 Pod 通信，反之亦然。
• ovs-networkpolicy 插件允许项目管理员使用 NetworkPolicy 对象配置自己的隔离策略。

OpenShift 路由和插件

OpenShift 管理员可以在 OpenShift 集群中[部署路由器](https://docs.openshift.com/enterprise/3.0/install_config/install/deploy_router.html)，这使开发人员创建的路由可供外部客户端使用。 OpenShift 中的路由层是可插拔的，默认情况下提供并支持两个可用的路由器插件。

OpenShift 路由器通过将区分信息直接传递给路由器的协议为服务提供外部主机名映射和负载平衡；协议中必须存在主机名，路由器才能确定将其发送到何处。

路由器插件假定它们可以绑定到主机端口 80 和 443。这是为了允许外部流量路由到主机，然后再通过路由器。路由器还假定网络配置为可以访问集群中的所有 pod。

OpenShift路由器是发往 OpenShift 安装中服务的所有外部流量的入口点。OpenShift 提供并支持以下路由器插件：

• HAProxy 模板路由器是默认插件。它使用 openshift3/ose-haproxy-routerimage 在 OpenShift 上的容器内部与模板路由器插件一起运行 HAProxy 实例。它目前支持 HTTP (S) 流量和通过 SNI 启用 TLS 的流量。与大多数只监听专用 IP 的容器不同，路由器的容器在主机网络接口上侦听。路由器将外部路由名称请求代理到由与路由关联的服务标识的实际 pod 的 IP。
• Citrix Ingress Controller 可以作为路由器插件部署在 OpenShift 集群中，以便与在您的环境中部署的 Citrix ADC 集成。通过 Citrix Ingress Controller，您可以将 Citrix ADC 的高级负载平衡和流量管理功能与 OpenShift 群集配合使用。请参阅 在 OpenShift 群集中将 Citrix Ingress Controller 部署为路由器插件。

OpenShift 路由和入口方法

在 OpenShift 集群中，外部客户端需要一种方法来访问 Pods 提供的服务。OpenShift 提供了两种资源来与集群中运行的服务进行通信：路由和入口。

路由

在 OpenShift 集群中，路由公开给定域名上的服务或将域名与服务相关联。OpenShift 路由器根据路由中指定的规则将外部请求路由到 OpenShift 集群内的服务。使用 OpenShift 路由器时，还必须配置外部 DNS 以确保流量落在路由器上。

Citrix Ingress Controller 可以作为路由器插件部署在 OpenShift 集群中，以便与在您的环境中部署的 Citrix ADC 集成。通过 Citrix Ingress Controller，您可以将 Citrix ADC 的高级负载平衡和流量管理功能与 OpenShift 群集配合使用。 OpenShift 路线可以是安全的，也可以是不安全的。安全路由指定路由的 TLS 终止。

Citrix Ingress Controller 支持以下 OpenShift 路由：

• 不安全的路由：对于不安全的路由，HTTP 流量不会加密。
• 边缘终止：对于边缘终止，TLS 在路由器处终止。通过内部网络从路由器到端点的流量未加密。
• 直通终止：通过直通终止，路由器不参与 TLS 卸载，加密流量将直接发送到目的地。
• 重新加密终止：在重新加密终止时，路由器会终止 TLS 连接，但随后与终端建立另一个 TLS 连接。

根据您想如何使用 Citrix ADC，有两种方法可以将 Citrix Ingress Controller 部署为 OpenShift 集群中的路由器插件：作为集群内的 Citrix ADC CPX 或作为集群外的 Citrix ADC MPX/VPX 部署。

在 OpenShift 群集中将 Citrix ADC CPX 部署为路由器

Citrix Ingress 控制器作为边车与 Citrix ADC CPX 容器一起部署在同一个容器中。在此模式下，Citrix Ingress Controller 配置 Citrix ADC CPX。请参阅 在 OpenShift 群集中将 Citrix ADC CPX 部署为路由器。

将 Citrix ADC MPX/VPX 部署为 OpenShift 群集之外的路由器

Citrix Ingress Controller 作为独立容器进行部署，允许您从 OpenShift 群集外部控制 Citrix ADC MPX 或 VPX 装置。请参阅 将 Citrix ADC MPX/VPX 部署为 OpenShift 群集之外的路由器。

进入

KubernetesIngress 为您提供了一种基于请求主机或路径将请求路由到服务的方法，将多个服务集中到一个入口点。

Citrix Ingress Controller 围绕 Kubernetes 入口构建，根据入口资源自动配置一个或多个 Citrix ADC 设备。

使用 Ingress 的路由可以通过以下方式完成：

• 基于主机名的路由
• 基于路径的路由
• 基于通配符的路由
• 精确路径匹配
• 非主机名路由
• 默认后端

有关示例和更多信息，请参阅 Ingress 配置 。

将 Citrix Ingress Controller 部署为 OpenShift 路由器插件

根据您想如何使用 Citrix ADC，有两种方法可以在 OpenShift 集群中将 Citrix Ingress Controller 器部署为路由器插件：

• 作为同一窗格中 Citrix ADC CPX 旁边的侧车容器：在此模式下，Citrix Ingress Controller 配置 Citrix ADC CPX。请参阅 在 OpenShift 群集中将 Citrix ADC CPX 部署为路由器。
• 作为 OpenShift 群集中的独立容器：在此模式下，您可以控制部署在群集之外的 Citrix ADC MPX 或 VPX 设备。请参阅 将 Citrix ADC MPX/VPX 部署为 OpenShift 群集之外的路由器。

推荐架构

我们建议客户在设计其微服务架构时使用以下架构：

• Citrix Unified Ingress
• Citrix 2 层入口
• Citrix 服务网格精简版

图 1-2：架构范围从相对简单到更复杂和功能丰富不等。

Citrix Unified Ingress

在统一入口部署中，Citrix ADC MPX 或 VPX 设备将客户端的南北流量代理到作为微服务部署在群集内的企业级应用程序。Citrix Ingress Controller 作为 Pod 或 sidecar 部署在 Kubernetes 集群中，以根据微服务或 Ingress 资源的更改自动配置 Citrix ADC 设备（MPX 或 VPX）。

当您的应用程序还是一个整体时，您就可以开始实施统一入口模型。只需将 Citrix ADC 定位为应用程序服务器前面的反向代理，然后实现稍后介绍的功能即可。这样，您就可以将应用程序转换为微服务了。

微服务之间的通信通过您选择的机制（kube-proxy、IPVS 等）来处理。

在不同类别中提供的功能

统一入口架构的功能分为三组。

第一组中的功能优化了性能：

• 负载平衡
• 低延迟连接
• 高可用性

第二组中的功能提高了安全性并简化了应用程序管理：

• 速率限制
• SSL/TLS 终止
• HTTP/2 支持
• 运行状况检查

最后一组中的功能特定于微服务：

• 服务中央通信点
• API 网关功能

摘要

Unified Ingress 模型的功能包括强大的服务负载平衡、中央通信点、动态服务发现、低延迟连接、高可用性、速率限制、SSL/TLS 终止、HTTP/2 等。

Unified Ingress 模型使管理流量、负载均衡请求以及动态响应后端微服务应用程序中的更改变得更加容易。

优势包括：

• 南北流量具有良好的可扩展性，可用于观察和监视，并可通过 Spinnaker 和 Citrix ADM 等工具提供持续交付
• 单层统一了管理网络和平台服务的基础设施团队，减少了跳数以降低延迟
• 适用于不需要 Web App Firewall 和 SSL 卸载但可以稍后添加的内部应用程序

缺点包括：

• kube-proxy 没有东西方安全性，但可以为 L4 分段添加印花布
• Kube-Proxy 的可扩展性未知
• 由于 kube-proxy 不提供可见性、控制权或日志，因此东西方流量的可见性受到限制甚至不可见，从而减轻了开放工具集成和持续交付的影响
• 平台团队还必须精通网络

Citrix 2 层入口

2 层 Ingress 架构模型是云原生新手的绝佳解决方案。在此模型中，第 1 层的 Citrix ADC 管理传入流量，但会将请求发送到由开发人员管理的 2 层 ADC，而不是直接发送到服务实例。Tier-2 Ingress 模型仅将平台和开发人员团队编写的策略应用于入站流量，并支持云扩展和多租户。

图 1-4：带有第 1 级 Citrix ADC VPX/MPX 和第 2 层 Citrix ADC CPX 容器的 Citrix 2 层入口模型示意图。

Tier-1 提供的功能

第一层 ADC 由传统网络团队管理，提供 L4 负载平衡、Citrix Web App Firewall、SSL 卸载和反向代理服务。第 1 层中的 Citrix ADC MPX 或 VPX 设备将从客户端的流量（南北）代理到第 2 层中的 Citrix ADC CPX。

默认情况下，Citrix Ingress Controller 将在 Tier-1 上对以下配置进行编程：

• 向用户反向代理应用程序：
• 内容交换虚拟服务器
• 虚拟服务器（前端，面向用户）
• 服务组
• SSL 卸载
• NetScaler 日志记录/调试
• 服务的运行状况监视

Tier-2 提供的功能

第一层 ADC 提供反向代理服务，而由平台团队管理的第二层 ADC 充当微服务的通信点，提供：

• 动态服务发现
• 负载平衡
• 可见性和丰富的指标

然后，Tier-2 Citrix ADC CPX 将流量路由到 Kubernetes 集群中的微服务。作为独立容器部署的 Citrix Ingress Controller 用于配置 Tier-1 设备。而且，一个或多个 Citrix ADC CPX 窗格中的边车控制器会在同一个容器中配置关联的 Citrix ADC CPX。

摘要

2 层模型中微服务的网络架构使用两个为不同角色配置的 ADC。一级 ADC 充当面向用户的代理服务器，二级 ADC 充当微服务的代理。

在两个不同的层之间拆分不同类型的功能可以提高速度、控制力并有机会进行安全优化。在第二层中，负载平衡快速、强大且可配置。

使用此模型，ADC 管理员和开发人员之间有明确的区别。这是开发人员的 BYOL。

优势包括：

• 南北流量具有良好的可扩展性，可用于观察和监视，并可通过 Spinnaker 和 Citrix ADM 等工具提供持续交付
• 面向云原生新手的最简单、更快速的部署，网络和平台团队的新学习有限

缺点包括：

• kube-proxy 没有东西方安全性，但可以为 L4 分段添加印花布
• Kube-Proxy 的可扩展性未知
• 由于 kube-proxy 不提供可见性、控制权或日志，因此东西方流量的可见性受到限制甚至不可见，从而减轻了开放工具集成和持续交付的影响。

Citrix 服务网格精简版

服务网格精简版是这三种型号中最丰富的功能。它在内部安全、快速、高效且具有弹性，可用于强制执行入站和容器间流量的策略。

服务网格精简版模型适用于多种用例，其中包括：

• 健康和金融应用程序 — 监管和用户要求要求金融和健康应用程序必须兼顾安全性和速度，这关系到数十亿美元的财务和声誉价值。
• 电子商务应用程序-用户信任对于电子商务来说是一个巨大的问题，而速度是关键的竞争差异化因素。因此，将速度和安全性结合起来至关重要。

摘要

优势包括：

• 一种更强大的联网方法，使用负载均衡器 CPX 将策略应用于入站和容器间流量，部署完整的 L7 策略
• 为南北和东西向流量提供更丰富的可观测性、分析能力、持续交付和安全性
• 带有嵌入式 Citrix ADC 的每个容器的 Canary
• 单层统一了管理网络和平台服务的基础设施团队，减少了跳数以降低延迟

缺点包括：

• 要部署的模型更为复杂
• 平台团队必须精通网络

架构选择摘要

Citrix Unified Ingress

• 南北 (NS) 应用程序流量 - 一个 Citrix ADC 负责 K8s 群集之外的第 4 层和 L7 NS 流量、安全性和外部负载平衡。

• 东西部 (EW) 应用程序流量 - kube 代理负责 L4 EW 流量。

• 安全 - ADC 负责保护 NS 流量和对用户进行身份验证。Kube-Proxy 负责四级电子战流量。

• 可扩展性和性能 - NS 流量具有良好的可扩展性，群集是一种选项。ew 流量和 kube-proxy 可扩展性未知。

• 可观察性 - ADC 为 NS 流量提供了出色的可观察性，但对 EW 流量没有可观察性。

Citrix 2 层入口

• 南北 (NS) 应用程序流量 - 第 1 级 ADC 负责 SSL 卸载、Web App Firewall 和 L4 NS 流量。它既用于整体，也可用于氯化萘应用。第 2 层 CPX 管理 k8s 和 L7 NS 流量的快速变化。

• 东西部 (EW) 应用程序流量 - kube 代理负责 L4 EW 流量。

• 安全 - 第 1 层 ADC 负责保护 NS 流量。可以在任一 ADC 上进行身份验证。Kube-proxy.Add Calico 用于 L4 分段无法保护电子战流量。

• 可扩展性和性能 - NS 流量具有良好的可扩展性，群集是一种选项。ew 流量和 kube-proxy 可扩展性未知。

• 可观察性 - Tier-1 ADC 为 NS 流量提供了出色的可观察性，但电子战流量没有可观察性。

Citrix 服务网格精简版

• 南北 (NS) 应用程序流量 - 第 1 级 ADC 负责 SSL 卸载、Web App Firewall 和 L4 NS 流量。它既用于整体，也可用于氯化萘应用。第 2 层 CPX 管理 k8s 和 L7 NS 流量的快速变化。

• 东西方 (EW) 应用程序流量 - 第 2 级 CPX 或任何开源代理负责 L4 EW 流量。客户可以选择哪些应用程序使用 CPX，哪些应用程序使用 kube-proxy。

• 安全 - 第 1 层 ADC 负责保护 NS 流量。可以在任一 ADC 上进行身份验证。Citrix CPX 负责身份验证、SSL 卸载和保护 EW 流量。可以在应用程序级别应用加密。

• 可扩展性和性能 - NS 和 EW 流量具有良好的可扩展性，但它增加了 1 个线内跃点。

• 可观察性 - 第 1 级 ADC 提供优异的 NS 流量可观测性。Tier-2 中的 CPX 提供电子战流量的可观察性，但可以将其禁用以减少 CPX 内存或 CPU 占用空间。

如何部署

Citrix Unified Ingress

要使用 OpenShift 验证 Citrix Unified Ingress 部署，请使用带有 Citrix ADC VPX 或 MPX 的“hello-world”应用程序示例。OpenShift 的默认命名空间“默认”用于此部署。

1. Citrix ADC 实例是手工构建并使用 NSIP/SNIP 进行配置的。可以 在这里找到在 XenServer 上安装 Citrix ADC。

2. 将以下 YAML 文件示例复制到 OpenShift 目录中，并将其命名为 application.yaml。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: hello-world
   spec:
     selector:
       matchLabels:
         run: load-balancer-example
     replicas: 2
     template:
       metadata:
         labels:
           run: load-balancer-example
       spec:
         containers:
           -  name: hello-world
             image: gcr.io/google-samples/node-hello:1.0
             ports:
               -  containerPort: 8080
                 protocol: TCP
   <!--NeedCopy-->
   

3. 部署应用程序。 oc apply -f application.yaml

4. 确保 pod 正在运行。 oc get pods

5. 将以下 YAML 文件示例复制到 OpenShift 目录中，然后将其命名为 service.yaml。

   apiVersion: v1
   kind: Service
   metadata:
     name: hello-world-service
   spec:
     type: NodePort
     ports:
     -  port: 80
       targetPort: 8080
     selector:
       run: load-balancer-example
   <!--NeedCopy-->
   

6. 使用服务通过 NodePort 公开应用程序。 oc apply -f service.yaml

7. 验证服务是否已创建。 oc get service

8. 将以下 YAML 文件示例复制到 OpenShift 目录中并将其命名为 ingress.yaml。您必须将注释“ingress.citrix.com/frontend-ip”更改为免费 IP 地址才能成为 Citrix ADC 上的 VIP。

   apiVersion: extensions/v1beta1
   kind: Ingress
   metadata:
     name: hello-world-ingress
     annotations:
      kubernetes.io/ingress.class: "vpx"
      ingress.citrix.com/insecure-termination: "redirect"
      ingress.citrix.com/frontend-ip: "10.217.101.183"
   spec:
     rules:
     -  host:  helloworld.com
       http:
         paths:
         -  path:
           backend:
             serviceName: hello-world-service
             servicePort: 80
   <!--NeedCopy-->
   

9. 部署入口 YAML 文件。 oc apply -f ingress.yaml

10. 现在有一些我们使用服务公开的应用程序 pod，并且可以使用 Ingress 将流量路由到它们。安装 Citrix Ingress Controller (CIC) 以将这些配置推送到我们的第 1 层 ADC VPX。在部署 CIC 之前，部署一个 RBAC 文件，为 CIC 提供正确的运行权限。

    注意：

    rbac yaml 文件指定了命名空间，必须对其进行更改，待使用哪个命名空间。

    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: cpx
    rules:
      -  apiGroups: [""]
        resources: ["services", "endpoints", "ingresses", "pods", "secrets", "nodes", "routes", "routes/status", "tokenreviews", "subjectaccessreviews"]
        verbs: ["\*"]
      -  apiGroups: ["extensions"]
        resources: ["ingresses", "ingresses/status"]
        verbs: ["\*"]
      -  apiGroups: ["citrix.com"]
        resources: ["rewritepolicies"]
        verbs: ["\*"]
      -  apiGroups: ["apps"]
        resources: ["deployments"]
        verbs: ["\*"]
    
    <!--NeedCopy-->
    

    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: cpx
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: cpx
    subjects:
    -  kind: ServiceAccount
      name: cpx
      namespace: default
    
    <!--NeedCopy-->
    

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: cpx
      namespace: default
    <!--NeedCopy-->
    

11. 部署 RBAC 文件。 oc apply -f rbac.yaml

12. 在部署 CIC 之前，请编辑 YAML 文件。根据规范，只要在第 1 级 ADC 的 SNIP 上启用了管理，就可以添加 NSIP 或 SNIP。请注意，参数“入口类”与 Ingress YAML 文件中指定的入口类注释相同。

    apiVersion: v1
    kind: Pod
    metadata:
      name: hello-world-cic
      labels:
        app: hello-world-cic
    spec:
      serviceAccountName: cpx
      containers:
      -  name: hello-world-cic
        image: "quay.io/citrix/citrix-k8s-ingress-controller:1.1.3"
        env:
         # Set NetScaler NSIP/SNIP, SNIP in case of HA (mgmt has to be enabled)
         -  name: "NS_IP"
           value: "10.217.101.193"
         # Set username for Nitro
         # Set log level
         -  name: "NS_ENABLE_MONITORING"
           value: "NO"
         -  name: "NS_USER"
           value: "nsroot"
         -  name: "NS_PASSWORD"
           value: "nsroot"
         -  name: "EULA"
           value: "yes"
         -  name: "LOGLEVEL"
           value: "DEBUG"
        args:
          -  --ingress-classes
            vpx
          -  --feature-node-watch
            false
        imagePullPolicy: IfNotPresent
    <!--NeedCopy-->
    

13. 部署 CIC。 oc apply -f cic.yaml

14. 验证所有 Pod 都在运行。 oc get pods

15. 使用 helloworld.com 的条目和 Ingress YAML 文件中指定的 Citrix ADC 上的 VIP 编辑本地计算机上的主机文件。

16. 在浏览器中导航到 helloworld.com。“Hello Kubernetes!“应出现。

注意： 以下是删除命令

• oc delete pods (pod name) -n (namespace name)
• oc delete deployment (deployment name) -n (namespace name)
• oc delete service (service name) -n (namespace name)
• oc delete ingress (ingress name) -n (namespace name)
• oc delete serviceaccounts (serviceaccounts name) -n (namespace name)

Citrix 2 层入口

要使用 OpenShift 验证 Citrix 2 层 Ingress 部署，请使用带有 Citrix ADC VPX 或 MPX 的“您好世界”应用程序示例。此部署使用默认命名空间“tier-2-adc”。**注意：部署 Pod、服务和 Ingress 时，必须使用参数“-n（命名空间名称）”指定命名空间。

1. Citrix ADC 实例是使用 NSIP/SNIP 手工构建和配置的。在 XenServer 上安装 Citrix ADC 可以在这里找到。如果已配置实例，请清除负载平衡或内容交换中推送到 ADC 的所有虚拟服务器，使其不再将 hello-world 部署为统一入口。

2. 创建一个名为“tier-2-adc”的命名空间。 oc create namespace tier-2-adc

3. 将以下 YAML 文件示例复制到 OpenShift 目录中并将其命名为 application-2t.yaml。

   
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: hello-world
   spec:
     selector:
       matchLabels:
         run: load-balancer-example
     replicas: 2
     template:
       metadata:
         labels:
           run: load-balancer-example
       spec:
         containers:
           -  name: hello-world
             image: gcr.io/google-samples/node-hello:1.0
             ports:
               -  containerPort: 8080
                 protocol: TCP
   
   <!--NeedCopy-->
   

4. 在命名空间中部署应用程序。 oc apply -f application-2t.yaml -n tier-2-adc

5. 确保 pod 正在运行。 oc get pods

6. 将以下 YAML 文件示例复制到 OpenShift 目录中并将其命名为 service-2t.yaml。

   
   apiVersion: v1
   kind: Service
   metadata:
     name: hello-world-service-2
   spec:
     type: NodePort
     ports:
   
     -port: 80
       targetPort: 8080
     selector:
       run: load-balancer-example
   
   <!--NeedCopy-->
   

7. 使用服务通过 NodePort 公开应用程序。 oc apply -f service-2t.yaml -n tier-2-adc

8. 验证服务是否已创建。 oc get service -n tier-2-adc

9. 将以下 YAML 文件示例复制到 OpenShift 目录中并将其命名为 ingress-2t.yaml。

   
       apiVersion: extensions/v1beta1
       kind: Ingress
       metadata:
         name: hello-world-ingress-2
         annotations:
          kubernetes.io/ingress.class: "cpx"
       spec:
         backend:
           serviceName: hello-world-service-2
           servicePort: 80
   
   <!--NeedCopy-->
   

10. 部署入口 YAML 文件。 oc apply -f ingress-2t.yaml -n tier-2-adc

11. 部署一个 RBAC 文件，为 CIC 和 CPX 提供正确的运行权限。

    注意：

    rbac yaml 文件指定了命名空间，并且必须对其进行更改，等待使用哪个命名空间。

    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: cpx
    rules:
      -apiGroups: [""]
        resources: ["services", "endpoints", "ingresses", "pods", "secrets", "nodes", "routes", "routes/status", "tokenreviews", "subjectaccessreviews"]
        verbs: ["\*"]
      -apiGroups: ["extensions"]
        resources: ["ingresses", "ingresses/status"]
        verbs: ["\*"]
      -apiGroups: ["citrix.com"]
        resources: ["rewritepolicies"]
        verbs: ["\*"]
      -apiGroups: ["apps"]
        resources: ["deployments"]
        verbs: ["\*"]
    ---
    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: cpx
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: cpx
    subjects:
    -  kind: ServiceAccount
      name: cpx
      namespace: tier-2-adc
    ---
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: cpx
      namespace: tier-2-adc
    <!--NeedCopy-->
    

12. 部署 RBAC 文件。 oc apply -f rbac-2t.yaml

13. 服务帐号需要提升权限才能创建 CPX。 oc adm policy add-scc-to-user privileged system:serviceaccount:tier-2-adc:cpx

14. 编辑 CPX YAML 文件并将其命名为 cpx-2t.yaml。这将部署 CPX 和公开它的服务。请注意 Ingress Class 的参数与 ingress-2t.yaml 文件中的注解相匹配。

        apiVersion: extensions/v1beta1
        kind: Deployment
        metadata:
          name: hello-world-cpx-2
        spec:
          replicas: 1
          template:
            metadata:
              name: hello-world-cpx-2
              labels:
                app: hello-world-cpx-2
                app1: exporter
              annotations:
                NETSCALER_AS_APP: "True"
            spec:
              serviceAccountName: cpx
              containers:
                -  name: hello-world-cpx-2
                  image: "quay.io/citrix/citrix-k8s-cpx-ingress:13.0-36.28"
                  securityContext:
                     privileged: true
                  env:
                  -  name: "EULA"
                  value: "yes"
                  -  name: "KUBERNETES_TASK_ID"
                    value: ""
                  imagePullPolicy: Always
            # Add cic as a sidecar
                -  name: cic
                  image: "quay.io/citrix/citrix-k8s-ingress-controller:1.1.3"
                  env:
                  -  name: "EULA"
                    value: "yes"
                  -  name: "NS_IP"
                    value: "127.0.0.1"
                  -  name: "NS_PROTOCOL"
                    value: "HTTP"
                  -  name: "NS_PORT"
                    value: "80"
                  -  name: "NS_DEPLOYMENT_MODE"
                    value: "SIDECAR"
                  -  name: "NS_ENABLE_MONITORING"
                    value: "YES"
                  -  name: POD_NAME
                    valueFrom:
                      fieldRef:
                        apiVersion: v1
                        fieldPath: metadata.name
                  -  name: POD_NAMESPACE
                    valueFrom:
                      fieldRef:
                        apiVersion: v1
                        fieldPath: metadata.namespace
                  args:
                    -  --ingress-classes
                      cpx
                  imagePullPolicy: Always
            apiVersion: v1
            kind: Service
            metadata:
              name: lb-service-cpx
              labels:
                app: lb-service-cpx
            spec:
              type: NodePort
              ports:
              -  port: 80
                protocol: TCP
                name: http
                targetPort: 80
              selector:
                app: hello-world-cpx-2
    
    <!--NeedCopy-->
    

15. 部署 CPX。 oc apply -f cpx-2t.yaml -n tier-2-adc

16. 验证 Pod 是否正在运行以及服务是否已创建。 oc get pods -n tier-2-adc oc get service -n tier-2-adc

17. 创建一个入口以从 VPX 路由到 CPX。前端 IP 应该是 ADC 上的空闲 IP。给文件起个名字： ingress-cpx-2t.yaml。

    
    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: hello-world-ingress-vpx-2
      annotations:
       kubernetes.io/ingress.class: "helloworld"
       ingress.citrix.com/insecure-termination: "redirect"
       ingress.citrix.com/frontend-ip: "10.217.101.183"
    spec:
      rules:
        -  host:  helloworld.com
    
        http:
          paths:
          -  path:
            backend:
              serviceName: lb-service-cpx
              servicePort: 80
    <!--NeedCopy-->
    

18. 部署 Ingress。 oc apply -f ingress-cpx-2t.yaml -n tier-2-adc

19. 在部署 CIC 之前，请编辑 YAML 文件。根据规范，只要在第 1 级 ADC 的 SNIP 上启用了管理，就可以添加 NSIP 或 SNIP。

    apiVersion: v1
    kind: Pod
    metadata:
      name: hello-world-cic
      labels:
        app: hello-world-cic
    spec:
          serviceAccountName: cpx
          containers:
          -  name: hello-world-cic
            image: "quay.io/citrix/citrix-k8s-ingress-controller:1.1.3"
            env:
             # Set NetScaler NSIP/SNIP, SNIP in case of HA (mgmt has to be enabled)
             -  name: "NS_IP"
           value: "10.217.101.176"
         # Set username for Nitro
         # Set log level
         -  name: "NS_ENABLE_MONITORING"
           value: "NO"
         -  name: "NS_USER"
           value: "nsroot"
         -  name: "NS_PASSWORD"
           value: "nsroot"
         -  name: "EULA"
           value: "yes"
         -  name: "LOGLEVEL"
           value: "DEBUG"
        args:
          -  --ingress-classes
            helloworld
          -  --feature-node-watch
            false
        imagePullPolicy: IfNotPresent
    <!--NeedCopy-->
    

20. 部署 CIC。 oc apply -f cic-2t.yaml -n tier-2-adc

21. 验证所有 Pod 都在运行。 oc get pods -n tier-2-adc

22. 使用 helloworld.com 的条目和从 VPX 路由到 CPX 的 Ingress YAML 文件中指定的 Citrix ADC 上的 VIP 编辑本地计算机上的主机文件。

23. 在浏览器中导航到 helloworld.com。“Hello Kubernetes!“应出现。

Citrix 服务网格精简版

Service Mesh Lite 允许引入 CPX（或其他 Citrix ADC 设备）作为内置 HAProxy 功能的替代品。这使我们能够在 Kubernetes 中扩展 N/S 功能，同时提供 E/W 流量负载均衡、路由和可观察性。 Citrix ADC（MPX、VPX 或 CPX）可以为 E-W 流量提供此类好处，例如：

• 双向 TLS 或 SSL 卸载
• 基于内容的路由，允许或阻止基于 HTTP 或 HTTPS 标头参数的流量
• 高级负载平衡算法（例如，最少连接、最短响应时间等）。
• 通过测量黄金信号（错误、延迟、饱和度或流量）来观察东西向流量。Citrix ADM 的 Service Graph 是一种用于监视和调试微服务的可观察性解决方案。
• 在此部署场景中，我们部署 Bookinfo 应用程序并观察其默认运行方式。然后我们继续翻录并替换默认的 Kubernetes 服务，然后使用 CPX 和 VPX 来代理我们的 E/W 流量。

带 CPX 的 Citrix 服务网格精简版

要使用 OpenShift 验证 Citrix Unified Ingress 部署，请使用带有 Citrix ADC VPX 或 MPX 的“hello-world”应用程序示例。OpenShift 的默认命名空间“默认”用于此部署。

1. Citrix ADC 实例是手工构建并使用 NSIP/SNIP 进行配置的。可以 在这里找到在 XenServer 上安装 Citrix ADC。

2. 为此部署创建命名空间。在本示例中，使用了 sml。 oc create namespace sml

3. 复制以下 YAML 以创建 Bookinfo 的部署和服务。把它命名为 bookinfo.yaml。

 ##################################################################################################
 # Details service
 ##################################################################################################
 apiVersion: v1
 kind: Service
 metadata:
   name: details
   labels:
     app: details
     service: details
 spec:
   ports:
   -  port: 9080
     name: http
   selector:
     app: details
 ---
 apiVersion: extensions/v1beta1
 kind: Deployment
 metadata:
   name: details-v1
   labels:
     app: details
     version: v1
 spec:
   replicas: 1
   template:
     metadata:
       annotations:
         sidecar.istio.io/inject: "false"
       labels:
         app: details
         version: v1
     spec:
       containers:
       -  name: details
         image: docker.io/maistra/examples-bookinfo-details-v1:0.12.0
         imagePullPolicy: IfNotPresent
         ports:
         -  containerPort: 9080
 ---
 ##################################################################################################
 # Ratings service
 ##################################################################################################
 apiVersion: v1
 kind: Service
 metadata:
   name: ratings
   labels:
     app: ratings
     service: ratings
 spec:
   ports:
   -  port: 9080
     name: http
   selector:
     app: ratings
 ---
 apiVersion: extensions/v1beta1
 kind: Deployment
 metadata:
   name: ratings-v1
   labels:
     app: ratings
     version: v1
 spec:
   replicas: 1
   template:
     metadata:
       annotations:
         sidecar.istio.io/inject: "false"
       labels:
         app: ratings
         version: v1
     spec:
       containers:
       -  name: ratings
         image: docker.io/maistra/examples-bookinfo-ratings-v1:0.12.0
         imagePullPolicy: IfNotPresent
         ports:
         -  containerPort: 9080
 ---
 ##################################################################################################
 # Reviews service
 ##################################################################################################
 apiVersion: v1
 kind: Service
 metadata:
   name: reviews
   labels:
     app: reviews
     service: reviews
 spec:
   ports:
   -  port: 9080
     name: http
   selector:
     app: reviews
 ---
 apiVersion: extensions/v1beta1
 kind: Deployment
 metadata:
   name: reviews-v1
   labels:
     app: reviews
     version: v1
 spec:
   replicas: 1
   template:
     metadata:
       annotations:
         sidecar.istio.io/inject: "false"
       labels:
         app: reviews
         version: v1
     spec:
       containers:
       -  name: reviews
         image: docker.io/maistra/examples-bookinfo-reviews-v1:0.12.0
         imagePullPolicy: IfNotPresent
         ports:
         -  containerPort: 9080
 ---
    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      name: reviews-v2
      labels:
        app: reviews
        version: v2
    spec:
      replicas: 1
      template:
        metadata:
          annotations:
            sidecar.istio.io/inject: "false"
          labels:
            app: reviews
            version: v2
        spec:
          containers:
          -  name: reviews
            image: docker.io/maistra/examples-bookinfo-reviews-v2:0.12.0
            imagePullPolicy: IfNotPresent
            ports:
            -  containerPort: 9080
 ---
    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      name: reviews-v3
      labels:
        app: reviews
        version: v3
    spec:
      replicas: 1
      template:
        metadata:
          annotations:
            sidecar.istio.io/inject: "false"
          labels:
            app: reviews
            version: v3
        spec:
          containers:
          -  name: reviews
            image: docker.io/maistra/examples-bookinfo-reviews-v3:0.12.0
            imagePullPolicy: IfNotPresent
            ports:
            -  containerPort: 9080
    ---
    ##################################################################################################
    # Productpage services
    ##################################################################################################
    apiVersion: v1
    kind: Service
    metadata:
      name: productpage-service
    spec:
      type: NodePort
      ports:
      -  port: 80
        targetPort: 9080
      selector:
        app: productpage
    ---
    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      name: productpage-v1
      labels:
        app: productpage
        version: v1
    spec:
      replicas: 1
      template:
        metadata:
          annotations:
            sidecar.istio.io/inject: "false"
          labels:
            app: productpage
            version: v1
        spec:
          containers:
          -  name: productpage
            image: docker.io/maistra/examples-bookinfo-productpage-v1:0.12.0
            imagePullPolicy: IfNotPresent
            ports:
            -  containerPort: 9080
    ---
<!--NeedCopy-->

1. 在 sml 命名空间中部署 bookinfo.yaml。 oc apply -f bookinfo.yaml -n sml

2. 复制并部署映射到产品页面服务的 Ingress 文件。这个文件可以命名为 ingress-productpage.yaml。前端 IP 应该是 Citrix ADC VPX/MPX 上的免费 VIP。

   apiVersion: extensions/v1beta1
   kind: Ingress
   metadata:
     name: productpage-ingress
     annotations:
      kubernetes.io/ingress.class: "bookinfo"
      ingress.citrix.com/insecure-termination: "redirect"
      ingress.citrix.com/frontend-ip: "10.217.101.182"
   spec:
     rules:
     -  host: bookinfo.com
       http:
         paths:
         -  path:
           backend:
             serviceName: productpage-service
             servicePort: 80
   <!--NeedCopy-->
   

oc apply -f ingress-productpage.yaml -n sml

1. 在 sml 命名空间中复制 RBAC 文件的以下 YAML 并进行部署。在产品页面微服务前将文件 rbac-cic-pp.yaml 命名为用于 CIC 的文件。

   kind: ClusterRole
   apiVersion: rbac.authorization.k8s.io/v1beta1
   metadata:
     name: cpx
   rules:
     -  apiGroups: [""]
       resources: ["services", "endpoints", "ingresses", "pods", "secrets", "routes", "routes/status", "nodes", "namespaces"]
       verbs: ["\*"]
     -  apiGroups: ["extensions"]
       resources: ["ingresses", "ingresses/status"]
       verbs: ["\*"]
     -  apiGroups: ["citrix.com"]
       resources: ["rewritepolicies", "vips"]
       verbs: ["\*"]
     -  apiGroups: ["apps"]
       resources: ["deployments"]
       verbs: ["\*"]
     -  apiGroups: ["apiextensions.k8s.io"]
       resources: ["customresourcedefinitions"]
       verbs: ["get", "list", "watch"]
   ---
   kind: ClusterRoleBinding
   apiVersion: rbac.authorization.k8s.io/v1beta1
   metadata:
     name: cpx
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: cpx
   subjects:
   -  kind: ServiceAccount
     name: cpx
     namespace: sml
   apiVersion: rbac.authorization.k8s.io/v1
   ---
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: cpx
     namespace: sml
   <!--NeedCopy-->
   

oc apply -f rbac-cic-pp.yaml -n sml

1. 提升服务帐号权限以部署 CIC 和 CPX。 oc adm policy add-scc-to-user privileged system:serviceaccount:sml:cpx

2. 在本地计算机上编辑主机文件，将 bookinfo.com 映射到中指定的前端 IP ingress-productpage.yaml。

3. 使用 CIC 复制和部署产品页面。命名文件 cic-productpage.yaml。NS_IP 应该是第 1 层 ADC 的 NS_IP。

   apiVersion: v1
   kind: Pod
   metadata:
     name: productpage-cic
     labels:
       app: productpage-cic
   spec:
         serviceAccountName: cpx
         containers:
         -  name: productpage-cic
           image: "quay.io/citrix/citrix-k8s-ingress-controller:1.1.3"
           env:
            # Set NetScaler NSIP/SNIP, SNIP in case of HA (mgmt has to be enabled)
            -  name: "NS_IP"
              value: "10.217.101.176"
            # Set username for Nitro
            # Set log level
            -  name: "NS_ENABLE_MONITORING"
              value: "NO"
            -  name: "NS_USER"
              value: "nsroot"
            -  name: "NS_PASSWORD"
              value: "nsroot"
            -  name: "EULA"
              value: "yes"
            -  name: "LOGLEVEL"
              value: "DEBUG"
            -  name: "NS_APPS_NAME_PREFIX"
              value: "BI-"
           args:
             -  --ingress-classes
               bookinfo
             -  --feature-node-watch
               false
           imagePullPolicy: IfNotPresent
   <!--NeedCopy-->
   

oc apply -f cic-productpage.yaml -n sml

1. 导航到 bookinfo.com，然后点击普通用户。产品页面应提取其他微服务的详细信息、评论和评分。HAProxy 负责在微服务（东西方）之间路由流量。

2. 在详细信息前面删除服务。刷新 Bookinfo 网页，注意产品页面无法拉取微服务以获取详细信息。 oc delete service details -n sml

3. 复制并部署无头服务，以便从产品页面到详细信息的流量通过 CPX。称这个文件为 detailsheadless.yaml。

   apiVersion: v1
   kind: Service
   metadata:
     name: details
   spec:
     ports:
     -  port: 9080
       name: http
     selector:
       app: cpx
   <!--NeedCopy-->
   

oc apply -f detailsheadless.yaml -n sml

1. 复制并部署一个新的详细信息服务，该服务应命名为 detailsservice.yaml，放在细节微服务前。

   apiVersion: v1
   kind: Service
   metadata:
     name: details-service
     labels:
       app: details-service
       service: details-service
   spec:
     clusterIP: None
     ports:
     -  port: 9080
       name: http
     selector:
       app: details
   <!--NeedCopy-->
   

oc apply -f detailsservice.yaml -n sml

1. 使用入口公开详细信息服务并进行部署。把这个文件叫做 detailsingress.yaml。

   apiVersion: extensions/v1beta1
   kind: Ingress
   metadata:
     name: details-ingress
     annotations:
      kubernetes.io/ingress.class: "cpx"
      ingress.citrix.com/insecure-port: "9080"
   spec:
     rules:
     -  host: details
       http:
         paths:
         -  path:
           backend:
             serviceName: details-service
             servicePort: 9080
   <!--NeedCopy-->
   

oc apply -f detailsingress.yaml -n sml

1. 复制并部署 CPXEastWest.yaml 文件。

   apiVersion: extensions/v1beta1
   kind: Deployment
   metadata:
     name: cpx
     labels:
       app: cpx
       service: cpx
   spec:
     replicas: 1
     template:
       metadata:
         name: cpx
         labels:
           app: cpx
           service: cpx
         annotations:
           NETSCALER_AS_APP: "True"
       spec:
         serviceAccountName: cpx
         containers:
           -  name: reviews-cpx
             image: "quay.io/citrix/citrix-k8s-cpx-ingress:13.0-36.28"
             securityContext:
                privileged: true
             env:
             -  name: "EULA"
               value: "yes"
             -  name: "KUBERNETES_TASK_ID"
               value: ""
             -  name: "MGMT_HTTP_PORT"
               value: "9081"
             ports:
             -  name: http
               containerPort: 9080
             -  name: https
               containerPort: 443
             -  name: nitro-http
               containerPort: 9081
             -  name: nitro-https
               containerPort: 9443
             imagePullPolicy: Always
           # Add cic as a sidecar
           -  name: cic
             image: "quay.io/citrix/citrix-k8s-ingress-controller:1.2.0"
             env:
             -  name: "EULA"
               value: "yes"
             -  name: "NS_IP"
               value: "127.0.0.1"
             -  name: "NS_PROTOCOL"
               value: "HTTP"
             -  name: "NS_PORT"
               value: "80"
             -  name: "NS_DEPLOYMENT_MODE"
               value: "SIDECAR"
             -  name: "NS_ENABLE_MONITORING"
               value: "YES"
             -  name: POD_NAME
               valueFrom:
                 fieldRef:
                   apiVersion: v1
                   fieldPath: metadata.name
             -  name: POD_NAMESPACE
               valueFrom:
                 fieldRef:
                   apiVersion: v1
                   fieldPath: metadata.namespace
             args:
               -  --ingress-classes
                 cpx
             imagePullPolicy: Always
   <!--NeedCopy-->
   

oc apply -f CPXEastWest.yaml -n sml

1. 刷新 bookinfo.com，详细信息应从微服务的详细信息中提取。CPX 已成功部署到代理 EW 流量。

带 VPX/MPX 的 Citrix 服务网格精简版

1. 运行以下命令删除用作 EW 代理的 CPX。部署新文件以将 VPX 配置为产品页面和详细信息微服务之间的 EW 代理。 oc delete -f detailsheadless.yaml -n sml oc delete -f detailsservice.yaml -n sml oc delete -f detailsingress.yaml -n sml oc delete -f CPXEastWest.yaml -n sml

2. 复制并部署服务，将文件命名为 detailstoVPX.yaml，将来自产品页面的流量发送回 VPX。IP 参数应该是 Citrix ADC VPX/MPX 上的免费 VIP。

   ---
   kind: "Service"
   apiVersion: "v1"
   metadata:
     name: "details"
   spec:
     ports:
       -
         name: "details"
         protocol: "TCP"
         port: 9080
   ---
   kind: "Endpoints"
   apiVersion: "v1"
   metadata:
     name: "details"
   subsets:
     -
       addresses:
         -
           ip: "10.217.101.182" # Ingress IP in MPX
       ports:
         -
           port: 9080
           name: "details"
   <!--NeedCopy-->
   

oc apply -f detailstoVPX.yaml -n sml

1. 在细节微服务前重新部署 detailsservice.yaml。 oc apply -f detailsservice.yaml -n sml

2. 复制并部署 Ingress，向 VPX 公开微服务的详细信息。这被命名为 detailsVPXingress.yaml。前端 IP 应与第 1 层 ADC 上的 VIP 相匹配。

   apiVersion: extensions/v1beta1
   kind: Ingress
   metadata:
     name: details-ingress
     annotations:
      kubernetes.io/ingress.class: "vpx"
      ingress.citrix.com/insecure-port: "9080"
      ingress.citrix.com/frontend-ip: "10.217.101.182"
   spec:
     rules:
     -  host: details
       http:
         paths:
         -  path:
           backend:
             serviceName: details-service
             servicePort: 9080
   <!--NeedCopy-->
   

oc apply -f detailsVPXingress.yaml

1. 刷新 bookinfo.com，详细信息应从 details 微服务中提取。VPX 已成功部署到代理 EW 流量。

在 Openshift 中使用路由或入口类将服务迁移到 Citrix ADC

使用路由分片进行服务迁移

Citrix Ingress Controller (CIC) 充当路由器，并将流量重定向到各种容器，以便在各种可用容器之间分配传入流量。

此迁移过程也可以是集群升级过程的一部分，从传统的 OpenShift 拓扑到使用 Citrix CNC、CIC 和 CPX 组件进行集群迁移和升级程序的自动部署。

这个解决方案可以通过两种方法来实现：

• 按插件划分的 CIC 路由器 (Pod)
• Openshift 里面的 CPX 路由器 (Sidecar)

下面将介绍这两种方法以及迁移示例。

静态路由（默认） -通过静态路由将 Openshift HostSubnet 映射到外部 ADC。

静态路由在使用 HAProxy 的传统 Openshift 部署中很常见。在将服务从一个服务代理迁移到另一个服务代理时，静态路由可以与 Citrix CNC、CIC 和 CPX 在 parralell 中使用，而不会中断正在运行的群集中部署的命名空间。

Citrix ADC 的静态路由配置示例：

oc get hostsubnet (Openshift Cluster) snippet
    oc311-master.example.com 10.x.x.x 10.128.0.0/23
    oc311-node1.example.com 10.x.x.x 10.130.0.0/23
    oc311-node2.example.com 10.x.x.x 10.129.0.0/23

show route (external Citrix VPX) snippet
    10.128.0.0 255.255.254.0 10.x.x.x STATIC
    10.129.0.0 255.255.254.0 10.x.x.x STATIC
    10.130.0.0 255.255.254.0 10.x.x.x STATIC

自动路由 -使用 CNC（Citrix 节点控制器）自动执行到已定义路由分片的外部路由。

您可以通过两种方式将 Citrix ADC 与 OpenShift 集成，两种方式都支持 OpenShift 路由器分片。

路线类型

• 不安全-连接到 CIC 路由器的外部负载均衡器，HTTP 流量未加密。
• secured-Edge-外部负载平衡器到终止 TLS 的 CIC 路由器。
• 安全直通-外部负载均衡器到终止 TLS 的目标
• 安全重新加密-外部负载平衡器到终止 TLS 的 CIC 路由器。使用 TLS 加密目的地的 CIC 路由器。

部署示例 #1: 作为 OpenShift 路由器插件部署的 CIC

对于 Routes，我们使用路径分片概念。在这里，CIC 充当路由器，将流量重定向到各个 pod，以便在各种可用 pod 之间分配传入流量。CIC 作为部署在群集之外的 Citrix ADC MPX 或 VPX 的路由器插件安装。

Citrix 组件：

• VPX-向 DNS 提供群集服务的入口 ADC。
• CIC-通过 CNC 路由向外部 Citrix ADC 提供 ROUTE_LABELS 和 NAMESPACE_LABELS。

路由分片的 YAML 文件参数示例：

Citrix Openshift 源文件位于 Github 这里

1. 添加以下环境变量 ROUTE_LABELS 和 NAMESPACE_LABELS，其值采用 kubernetes 标签格式。CIC 中的路由分片表达式 NAMESPACE_LABELS 是一个可选字段。如果使用，则它必须与 route.yaml 文件中提到的命名空间标签匹配。

   env:
    - name: "ROUTE_LABELS"
      value: "name=apache-web"
    - name: "NAMESPACE_LABELS"
      value: "app=hellogalaxy"
   

2. 通过 route.yaml 创建的路由将具有与 CIC 中的路由分片表达式匹配的标签。

   metadata:
       name: apache-route
       namespace: hellogalaxy
       labels:
           name: apache-web
   

3. 使用 service.yaml 公开该服务。

   metadata:
       name: apache-service
   spec:
   type: NodePort
   #type=LoadBalancer
   ports:
       - port: 80
   targetPort: 80
   selector:
       app: apache
   

4. 部署一个简单的 Web 应用程序，其选择器标签与 service.yaml 中的选择器标签相匹配。

部署示例 #2: 作为 OpenShift 路由器部署的 Citrix ADC CPX

Citrix ADC CPX 可以与群集内的 Citrix Ingress Controller 一起部署为 OpenShift 路由器。有关在群集中将 CPX 或 CIC 部署为路由器的更多步骤，请参阅 使用 Citrix ADC 启用 OpenShift 路由分片支持。

Citrix 组件：

• VPX-向 DNS 提供群集服务的入口 ADC。
• CIC-向外部 Citrix ADC 提供 ROUTE_LABELS 和 NAMESPACE_LABELS 以定义路由分片。
• CNC-提供分片到外部负载均衡器的自动路由配置。
• CPX-在 Openshift 集群中提供 Openshift 路由。

使用入口类注解进行服务迁移

入口类注解使用入口类注解概念，我们使用入口类信息向 Ingress 添加注释，这将有助于将流量从外部 ADC 重定向到特定 pod /节点。

入口类的 YAML 文件参数示例：**

Citrix 入口源文件位于 Github 这里

env:
    args:
      - --ingress-classes
        vpx

Ingress 配置文件在元数据中还应该有一个 kubernetes.io/ingress.class 注解字段，该字段将在创建时与 CIC 入口类参数字段匹配。

使用“ingress.classes”示例进行入口 VPX 部署示例**

    kind: Ingress
        metadata:
            name: ingress-vpx
            annotations:
                kubernetes.io/ingress.class: "vpx"

Citrix 指标导出器

您可以使用 Citrix ADC 指标导出器和 Prometheus-Operator 来监视 Citrix ADC VPX 或 CPX 入口设备和 Citrix ADC CPX（东西）设备。请参阅 查看使用普罗米修斯和Grafana 的 Citrix ADC 的指标。