容器集群网络规划

在创建云容器引擎集群时，您需要指定专有网络VPC、Pod网络CIDR/Pod子网（地址段）和Service CIDR（地址段）。因此建议您提前规划ECS地址、Kubernetes Pod地址和Service地址。本文将介绍天翼云专有网络VPC环境下Kubernetes集群里各种地址的作用，以及地址段该如何规划。

专有网络VPC网段和Kubernetes网段关系

专有网络VPC（下文简称为VPC或专有网络）的网段规划包含VPC自身网段和子网网段，Kubernetes网段规划包含Pod地址段和Service地址段。支持Cubecni和Calico两种网络模式。

Cubecni网络模式：

配置Cubecni模式网络时，需要设置的参数及参数网段配置的注意事项如下：

专有网络：您在创建VPC时需要选择网段，建议从10.0.0.0/16-20、172.16.0.0/16-20、192.168.0.0/16-20三者中选择一个。

Pod子网：Pod地址从该子网分配，用于Pod网络通信。Pod是Kubernetes内的概念，每个Pod具有一个IP地址。在VPC里创建子网时指定的网段，必须是当前VPC网段的子集。配置网段时，请注意：Cubecni网络模式下，Pod分配的Pod IP就是从这个子网网段内获取的。该地址段不能和Service CIDR网段重叠。

Service CIDR：Service地址段。Service是Kubernetes内的概念，对应的是Service类型为ClusterIP时Service使用的地址，每个Service有自己的地址。配置网段时，请注意：Service地址只在Kubernetes集群内使用，不能在集群外使用。Service地址段不能和Pod子网地址段重叠。

Calico网络模式：

配置Calico模式网络时，需要设置的参数及参数网段配置的注意事项如下：

专有网络：您在创建VPC时需要选择网段，建议从10.0.0.0/16-20、172.16.0.0/16-20、192.168.0.0/16-20三者中选择一个。

Pod网络CIDR：Pod网络CIDR，Pod地址从该地址段分配，用于Pod网络通信。Pod是Kubernetes内的概念，每个Pod具有一个IP地址。配置网段时，请注意：非VPC子网，为虚拟网段。该地址段不能和Service CIDR网段重叠。

例如，VPC网段用的是172.16.0.0/12，Kubernetes的Pod地址段就不能使用172.16.0.0/16、172.17.0.0/16等，因为这些地址都包含在172.16.0.0/12里。

Service CIDR：Service地址段。Service是Kubernetes内的概念，对应的是Service类型为ClusterIP时Service使用的地址，每个Service有自己的地址。配置网段时，请注意：Service地址只在Kubernetes集群内使用，不能在集群外使用。Service地址段不能和Pod网络CIDR地址段重叠。

网络规划

在天翼云环境下使用支持的Kubernetes集群，首先需要根据业务场景、集群规模进行网络规划。您可以按下表规格进行规划（未包含场景，请根据实际需要自行调整）。

VPC网络规划：

集群节点规模	目的	VPC规划	可用区
小于100个节点	一般性业务	单VPC	1个
任意	需要多可用区	单VPC	3个及以上
任意	对可靠性有极致要求、需要多地域	多VPC	3个及以上

容器网络规划：

本文针对Cubecni和Calico网络场景，规划容器网络：Cubecni配置示例：Cubecni Pod IPVlan模式

专有网络网段	Pod CIDR网段	Service CIDR网段	最大可分配Pod地址数
192.168.0.0/16	192.168.0.0/20	10.96.0.0/16	4090

Calico配置示例

专有网络网段	Pod CIDR网段	Service CIDR网段	最大可分配Pod地址数
192.168.0.0/16	172.16.0.0/16	10.96.0.0/16	65536

如何选择地址段？

场景1：单VPC+单Kubernetes集群

这是最简单的情形。VPC地址在创建VPC的时候就已经确定，创建Kubernetes集群时，选择的Pod及Service地址网段和当前VPC不一样的地址段即可。

场景2：单VPC+多Kubernetes集群

一个VPC下创建多个Kubernetes集群。VPC地址是在创建VPC时已经确定。创建Kubernetes集群时，每个集群内的VPC地址段、Service地址段和Pod地址段彼此间不能重叠。所有Kubernetes集群之间的Pod地址段（Cubecni模式下）不能重叠，但Service地址段可以重叠。

场景3：VPC互联

两个VPC网络互联的情况下，可以通过对等连接使VPC互联。

在这种情况下，VPC A和VPC B里创建的Kubernetes集群有以下限制：不能和VPC A的地址段重叠，不能和VPC B的地址段重叠，不能和其他集群的地址段重叠，不能和Pod的地址段重叠，不能和Service的地址段重叠。

使用Cubecni网络插件

Cubecni是天翼云开源的基于专有网络VPC的容器网络接口CNI（Container Network Interface）插件，支持基于Kubernetes标准的网络策略来定义容器间的访问策略。您可以通过使用Cubecni网络插件实现Kubernetes集群内部的网络互通。本文介绍如何使用天翼云容器引擎集群的Cubecni网络插件。

背景信息

Cubecni网络插件是自研的网络插件，将原生的弹性网卡及子网IP分配给Pod实现Pod网络，支持基于Kubernetes标准的网络策略（Network Policy）来定义容器间的访问策略。

在Cubecni网络插件中，每个Pod都拥有自己网络栈和IP地址。同一台ECS内的Pod之间通信，直接通过机器内部的转发，跨ECS的Pod通信、报文通过VPC的弹性网卡直接转发。由于不需要使用VxLAN等的隧道技术封装报文，因此Cubecni模式网络具有较高的通信性能。

Cubecni与Calico对比：在创建集群时提供Cubecni和Calico两种网络插件。

Cubecni：是天翼云自研的网络插件。云容器引擎将天翼云的弹性网卡和子网IP分配给容器，支持基于Kubernetes标准的网络策略来定义容器间的访问策略。Cubecni拥有更为灵活的IPAM（容器地址分配）策略，避免地址浪费。如果您不需要使用实现容器与虚机互访，可以选择calico，其他情况建议选择Cubecni。

Calico：使用社区Calico CNI插件的IP IP模式。

Cubecni与Calico对比

对比项	Cubecni	Calico
性能	性能接近弹性网卡	IP IP解封包损耗
安全	支持使用网络策略Network Policy	支持使用网络策略Network Policy
地址管理	无需按节点分配地址段，随用随分配，地址无浪费。支持配置安全组	每个节点提前分配虚拟地址段
ELB	ELB后端不能直接对接Pod，需要通过NodePort转发	ELB后端不能直接对接Pod，需要通过NodePort转发

配置

步骤一：规划和准备集群网络：在创建 Kubernetes集群时，您需要指定专有网络VPC、Pod子网（地址段）和Service CIDR（地址段）。

您可以使用以下网段配置，以快速搭建Cubecni网络。

专有网络网段	Pod子网	Service CIDR
192.168.0.0/16	192.168.0.0/20	172.21.0.0/20

本文使用上述推荐网段，说明如何创建一个专有网络和Pod子网。

登录专有网络管理控制台。在顶部菜单栏处，选择专有网络的地域，然后单击创建专有网络。在创建专有网络页面，设置名称为vpc_192_168_0_0_16，在IPv4网段文本框中，输入192.168.0.0/16。单击+添加，设置第二个交换机名称为pod_switch_192_168_32_0_19，选择可用区，设置IPv4网段为192.168.32.0/20。单击确定。

步骤二：配置Cubecni网络：为Cubecni网络插件配置集群网络的关键参数配置

虚拟私有云：选择步骤一：规划和准备集群网络中创建的专有网络。网络插件：选择Cubecni。Pod子网：选择步骤一：规划和准备集群网络中创建的Pod子网。Service CIDR：保留默认值。

Cubecni IPVlan模式

在创建集群时，如果选择Cubecni网络插件，则使用Cubecni IPvlan模式。Cubecni IPvlan模式采用IPvlan虚拟化实现高性能的Pod和Service网络：不同于默认的Terway的网络模式，IPvlan模式主要在Pod网络、Service、网络策略（NetworkPolicy）做了性能的优化：Pod的网络直接通过ENI网卡的IPvlan L2的子接口实现，大大简化了网络在宿主机上的转发流程，让Pod的网络性能几乎与宿主机的性能无异，延迟相对传统模式降低30%。Pod的网络策略（NetworkPolicy）采用eBPF替换掉原有的iptables的实现，不需要在宿主机上产生大量的iptables规则，降低网络策略对网络性能的影响。

通过注解配置负载均衡

通过Service YAML文件中的Annotation（注解），可以实现丰富的负载均衡功能。本文从ELB、监听和后端服务器组三种资源维度介绍通过注解可以对ELB进行的常见配置操作。

注解使用说明

注解的内容是区分大小写。annotations字段格式 service.beta.kubernetes.io/xxx

ELB

ELB的典型操作：指定负载均衡的规格

apiVersion: v1 kind: Service metadata:  annotations:  service.beta.kubernetes.io/ctyun-loadbalancer-spec: "${负载均衡的规格ID}"  name: nginx  namespace: default spec:  ports:  - port: 443  protocol: TCP  targetPort: 443  selector:  name: nginx  type: LoadBalancer

使用一个已有的负载均衡

apiVersion: v1 kind: Service metadata:  annotations:  service.beta.kubernetes.io/ctyun-loadbalancer-id: "${负载均衡ID}"  name: nginx  namespace: default spec:  ports:  - port: 443  protocol: TCP  targetPort: 443  selector:  name: nginx  type: LoadBalancer

常用注解

注解	类型	描述	默认值	支持的CCM版本
service.beta.kubernetes.io/ctyun-loadbalancer-address-type	String	创建公网类型或者私网类型的ELB，取值可以是internet或者intranet	intranet	v1.0.0及以上
service.beta.kubernetes.io/ctyun-loadbalancer-id	String	指定已有负载均衡实例的ID。 删除service时该 ELB不会被删除。	无	v1.0.0及以上
service.beta.kubernetes.io/ctyun-loadbalancer-spec	String	负载均衡的规格	无	v1.0.0及以上
service.beta.kubernetes.io/ctyun-loadbalancer-resource-pack-id	String	开通ELB所使用的资源包ID	无	v1.0.0及以上

基于DNS的服务发现

DNS为Kubernetes集群内的工作负载提供域名解析服务。本文主要介绍Kubernetes集群中DNS域名解析原理和容器集群中默认内置的DNS服务器CoreDNS。

Kubernetes集群中DNS域名解析原理

容器集群中kubelet的config.yaml有clusterDNS和clusterDomain，这两个参数分别被用来设置集群DNS服务器的IP地址和主域名后缀。

容器集群默认部署了一套CoreDNS工作负载，并通过kube-dns的服务名暴露DNS服务。CoreDNS工作负载后端是两个名为coredns的Pod，集群会根据Pod内的配置，将域名请求发往集群DNS服务器获取结果。Pod内的DNS域名解析配置文件为/etc/resolv.conf，文件内容如下。

nameserver 10.xx.x.xx search kube-system.svc.cluster.local svc.cluster.local cluster.local options ndots:5

序号	描述
1	业务Pod（Pod Client）试图访问Nginx服务（Service Nginx）时，先会请求本地DNS配置文件（/etc/resolv.conf）中指向的DNS服务器（nameserver 10.96.0.10，即Service kube-dns）获取服务IP地址，得到解析结果为10.96.1.2的IP地址
2	业务Pod（Pod Client）再直接发起往该IP地址的请求，请求最终经过Nginx服务（Service Nginx）转发到达后端的Nginx容器（Pod Nginx-1和Pod Nginx-2）上

CoreDNS介绍

CoreDNS是Kubernetes集群中负责DNS解析的组件，能够支持解析集群内部自定义服务域名和集群外部域名。CoreDNS具备丰富的插件集，在集群层面支持自建DNS、自定义hosts、CNAME、rewrite等需求。与Kubernetes一样，CoreDNS项目由 CNCF托管。关于CoreDNS的更多信息，请参见CoreDNS: DNS and Service Discovery。容器集群使用CoreDNS负责集群的服务发现，您可以根据不同使用场景配置CoreDNS及使用CoreDNS提升集群DNS QPS性能。