首先

这篇文章是由Cisco Systems合同公司员工志愿举办的2019年圣诞日历活动中的12/12（星期四）的文章。
请参考以下链接了解2019年其他的文章：
https://qiita.com/advent-calendar/2019/cisco

同时，上述信息基于2019年12月的数据。

Cisco ACI 是指思科的应用中心基础设施。

由于Cisco应用中心架构（ACI）的解释无法以一个简短句子来描述，因此请参阅以下有关ACI的信息：
– ACI如何操作指南（收集了ACI相关参考资料的日语版本）
– ACI官方指南（文档、发布说明、可扩展性等）

在下面的内容中，我们假设您已经对ACI的基本原理和术语有了基本的理解，并进行说明。

ACI 终端

在利用ACI的过程中，能够了解个别的计算资源非常重要。只要能够将它们作为独立的终端识别和区分出来，无论是物理服务器、虚拟机还是容器，ACI都能够进行适当的控制。通过使用ACI CNI来协作，ACI可以将由Kubernetes管理的独立Pod识别为独立的终端。

如果在连接到ACI的计算资源上使用与ACI不进行协作的基于主机的覆盖层解决方案，则ACI只能将其视为主机之间的通信。在这种情况下，ACI端的功能将将端点的识别单位设置为主机，并且在其上运行的VM等将无法被识别。

ACI和Kubernetes节点的协同连接形式

ACI提供网络给各种计算资源，即使使用ACI CNI进行协同的情况下，Kubernetes节点也支持使用物理服务器和虚拟机两种配置。对于物理服务器，ACI会将Kubernetes节点连接到ACI Leaf下，对于虚拟机，可以将其作为Kubernetes节点连接到vSphere环境的分布式虚拟交换机。在使用虚拟机配置Kubernetes节点时，需要在虚拟机端使用Tag VLAN，因此需要Trunk配置的端口组，但这个配置也会在ACI协同中自动创建。

在进行Kubernetes节点与VXLAN通信时，需要对“启用基础设施VLAN”进行勾选的原因是，使用的VLAN是基础设施VLAN。

ACI和Kubernetes的协作运行概述

为了理解ACI和Kubernetes的协作，需要将其拆分为两个方面：管理协作和通信控制。

管理合作

ACI和Kubernetes的管理协作是基于API通信，在ACI的控制器APIC（Application Policy Infrastructure Controller）和Kubernetes的Master Node之间进行的协作操作。ACI-Kubernetes协作通常是通过CNI作为Kubernetes背后的机制来实现的，即“由Kubernetes控制ACI”的方向。但是，APIC也可以利用从Kubernetes的Master Node获取的信息来识别并了解ACI一侧的每个Pod的状态。

通信控制

在一方面，OpFlex Agent将在Kubernetes的所有节点上运行，它不仅控制各节点上运行的Open vSwitch (OVS)，还管理VXLAN通信的关联。OpFlex Agent在内部使用OpenFlow控制OVS，并通过作为OpFlex代理的ACI的Leaf交换机与APIC进行协作，同时传递诸如“哪个Worker节点运行哪个Pod”等信息。

您可以直接使用提供的标准OVS，无需进行任何特殊修改或使用定制版本。通过OpFlex代理将ACI端的EPG反映到VXLAN的ID（即VNID），从而将Pod通信的VNID与ACI相关联，以识别并关联来自Pod的通信作为EPG。

使用ACI CNI带来的好处

尽管Flannel和Calico等是为Kubernetes设计的著名容器网络接口（CNI），但思科也为数据中心网络提供了VXLAN Fabric和SDN/Policy的融合技术，名为Cisco ACI。Cisco ACI也提供了经过Kubernetes认证的CNI。

请参考以下URL中的”ACI虚拟化兼容矩阵”，以了解支持的Kubernetes和各种基于容器的解决方案（如OpenShift，Docker EE等）。截至2019/12/12，Kubernetes支持版本为1.16，OpenShift支持版本为3.11，Docker EE 2.1（UCP 3.1）等也得到支持。

不使用特别的机制，价值在于

将ACI作为Kubernetes的CNI的最大优势是，相反地，它不使用任何“特殊机制”来处理容器网络。ACI是由Nexus 9000系列交换机构建的VXLAN Fabric，并由APIC进行集中管理的解决方案，因此可以使用通用机制实现对各种计算资源的策略控制。无论是物理服务器、虚拟机还是容器，都可以应用策略作为通用规则，而不是使用“针对特定目标优化”的机制，从而使得无论是组合使用各种计算资源，还是在未来可能使用时，都能保持环境简单而不复杂。

在Kubernetes中支持ACI CNI的意义。

此外，通过遵循CNI规范，使用ACI与Kubernetes或OpenShift等进行结合，无需对任何功能进行限制，这是一个优点。对于使用Kubernetes开发微服务应用程序的管理员来说，无需意识到ACI的存在。同时，通过使用ACI CNI，基础设施管理员可以为容器提供与物理网络通信控制相同的可靠性、稳定性和性能。通过APIC与Kubernetes的主节点和API的协作，ACI可以根据Kubernetes中的逻辑管理分区（例如Pod/Deployment/Service/Namespace）来理解通信对象，而非仅仅依靠MAC地址或IP地址，从而大大提高对容器的可见性。

使用ACI（Application Centric Infrastructure）和CNI（Container Network Interface）进行通信控制。

容器管理员和网络管理员

在应用程序开发人员管理容器的情况下，网络管理由网络基础设施负责人进行管理。在Kubernetes中，网络边界很难明确。如果能够区分不同集群并在命名空间之下进行安全性方面的考虑，那会很好。但如果基础设施管理员试图应用公司策略来反映安全性，对于物理服务器或虚拟机，可以通过交换机上的ACL或边界防火墙等措施来解决，但对于容器来说，必须采用与传统完全不同的机制来处理，对管理员来说是一种困难的情况。通过使用ACI CNI，可以在容器上应用用于物理服务器或虚拟机的ACI安全管理机制中的EPG和Contract，从而实现对Kubernetes环境的统一管理性和策略应用。

对于网络安全和通信范围的控制作为一个网络的功能之一。

在使用ACI CNI进行协作时，可以通过将EPG与Cluster / Namespace / Deployment等灵活的单元相关联来构建网络策略。在Kubernetes中，Pod的部署和数量是动态变化的目标，但如果配置了ACI CNI协作，就能够自动适应这种容器端的动态变化，并能够控制在物理层面上的安全性和通信范围。

要将Kubernetes的命名空间和部署与ACI的EPG相关联，可以利用Kubernetes的Annotation机制。虽然也可以使用kubectl annotate命令进行配置，但为了简化与ACI集成的操作，ACI的容器插件将提供acikubectl命令，您可以使用该命令以更简单的语法进行配置。

以下是使用acikubectl命令配置将Annotation规则绑定到Namespace “gb”下的EPG “gb”的示例，该EPG位于ACI的Tenant “k8s_demo2″的Application Profile “kubernetes”下。Annotations行是为acikubectl命令配置的EPG绑定设置的值。

root@k8sv1:~# acikubectl set default-eg namespace gb -t k8s_demo2 -a kubernetes -g gb
Setting default endpoint group:
Endpoint Group:
  Tenant: k8s_demo2
  App profile: kubernetes
  Endpoint group: gb
root@k8sv1:~#
root@k8sv1:~# kubectl describe namespace gb
Name:         gb
Labels:       <none>
Annotations:  opflex.cisco.com/endpoint-group: {"tenant":"k8s_demo2","app-profile":"kubernetes","name":"gb"}
Status:       Active

No resource quota.

No resource limits.
root@k8sv1:~#

执行上述操作后，属于”gb”命名空间的Pod将全部与ACI中的”gb” EPG相关联。此外，由于我们定义了命名空间级别的EPG关联，因此在此配置之后，部署在该命名空间中的新Pod或进行副本数量调整等操作，所创建的Pod也将自动与EPG相关联，从而应用相同的安全策略。

这个系统不会妨碍Kubernetes中作为网络策略的通信控制。网络策略是在yaml定义文件中应用于主机级别的有状态安全性，您可以根据需要将其与ACI端的EPG映射结合使用。与ACI端的EPG的连接可以用作网络方面的通信范围、安全强制和政策标准化的机制。

使用ACI CNI进行对外IP的负载均衡处理。

在使用ACI CNI Plugin的环境中，可以在Kubernetes中配置和使用type: LoadBalancer来实现对外部连接IP地址的负载平衡。虽然在ACI CNI中可以使用某种负载均衡器（如F5）来实现这个功能，但如果只需要简单地对多个Pod进行负载均衡处理，那么只使用ACI的功能就足够了。

利用ACI的服务图+ PBR功能

在ACI CNI中，为实现负载平衡处理，ACI巧妙地利用了一种称为Service Graph的机制来实现L4-L7协同。Service Graph与Contract关联，并将符合该Contract条件的通信通过某些L4-L7设备进行传递。关于Service Graph的一般使用方法，请参考ACI How To和白皮书等资料。

• Service Graph Design with Cisco Application Centric Infrastructure White Paper

 

Cisco Application Centric Infrastructure Policy-Based Redirect Service Graph Design White Paper

在ACI CNI中，用作Service Graph路由目标的是构成Kubernetes的节点本身。Service Graph具有将通信路由到Active/Standby结构的L4-L7设备的功能，当然也可以通过将集群配置和非Active/Standby结构的具有相同角色的多台L4-L7设备进行集中注册来实现。此功能还可以用于对Kubernetes节点进行负载均衡。

root@k8sv1:~# kubectl get svc -n gb
NAME           TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)        AGE
frontend       LoadBalancer   10.151.202.87    192.168.51.5   80:32559/TCP   16d
redis-master   ClusterIP      10.151.84.56     <none>         6379/TCP       16d
redis-slave    ClusterIP      10.151.126.126   <none>         6379/TCP       16d
root@k8sv1:~#

在ACI中，一个Kubernetes集群被配置为一个VRF，并且与外部的通信都通过L3out作为外部连接进行处理。ACI在L3out下配置了两个External EPG，并通过自动配置的Service Graph将它们之间的Contract应用于负载均衡处理。

从外部到达L3out的通信将根据External IP在主机路由中指定的External EPG进行LPM分配，作为静态路由，然后通过Contract流向具有Static Route和0.0.0.0/0的另一个External EPG。在此过程中，根据Service Graph的定义，将处理分配到基于Kubernetes节点注册的服务模式。针对外部IP的通信将直接路由到各个节点，但在每个节点的OVS中，外部IP将被转换为Pod的IP地址。Pod的回复将再次通过Worker Node上的OVS将External IP进行NAT转换，然后通过具有0.0.0.0/0路由的External EPG，通过L3out与外部通信以确立连接。

在这种情况下，只要是通常的L4-L7设备，无论转发到Service Graph中的哪个节点，都可以进行类似的处理，所以没有问题。但在Kubernetes中，与该服务关联的部署所构成的Pod的数量和运行在哪个Worker节点上会动态变化。为了解决这个问题，ACI根据与Kubernetes的API协作，动态地将该部署操作的Worker节点注册和修改为Service Graph中用于通信转发的PBR（基于策略的重定向）处理的目标。

在下面的示例中，指定了具有前端角色的Pod数量为1，并且其实际运行在名为 “k8sv2” 的工作节点上，因此仅有这一台工作节点被配置为PBR的目标。

root@k8sv1:~# kubectl get deployment -n gb
NAME           READY   UP-TO-DATE   AVAILABLE   AGE
frontend       1/1     1            1           17d
redis-master   1/1     1            1           17d
redis-slave    2/2     2            2           17d
root@k8sv1:~#

在这里，我们将使用kubectl命令动态地将副本数从1更改为2。然后，与Deployment相关联的Pod将被自动添加，同时，ACI CNI会在ACI上添加PBR分配目的地，新添加的Pod将被注册为名为”k8sv3″的Worker Node。

root@k8sv1:~# kubectl scale deployment frontend -n gb --replicas 2
deployment.extensions/frontend scaled
root@k8sv1:~# kubectl get deployment -n gb
NAME           READY   UP-TO-DATE   AVAILABLE   AGE
frontend       2/2     2            2           17d
redis-master   1/1     1            1           17d
redis-slave    2/2     2            2           17d
root@k8sv1:~#

这个行为被动态地配置，因此在减少副本数量或重新生成Pod等情况下，它会自动根据Pod的部署和变化来进行协作。

以此方式，使用ACI CNI与Kubernetes集成，提供了实现Kubernetes的实际应用所需的网络功能，包括安全性和负载均衡等。如果在ACI环境中使用Kubernetes，我们强烈推荐您使用ACI CNI，因为它提供了非常方便且易于使用的实用容器网络。

关于省略了的配置步骤等，请参考以下的安装指南。
– Cisco ACI和Kubernetes的集成。

免责条款

本网站及其相应评论中表达的意见仅代表发布者本人的个人观点，而不代表思科的观点。本网站的内容仅供提供信息目的而展示，并不意味着思科或其他相关方的推荐或表态。每一位用户在发布、链接或以其他方式上传的所有信息内容都要对其承担全责，并同意免除思科对使用本网站产生的任何责任。