-
Notifications
You must be signed in to change notification settings - Fork 81
/
ClusterNetwork.yaml
124 lines (124 loc) · 10.2 KB
/
ClusterNetwork.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
### K8s CRD ClusterNetwork API schema description ###
apiVersion: danm.io/v1
# A ClusterNetwork object represents a physical network together with its resources and configuration.
# ClusterNetworks are cluster-wide usable, non-namespaced objects and are an abstraction for external networks reachable by multiple tenant, or in K8s terminology, namespace users.
# This results in the following characteristics:
# - ClusterNetworks are expected to be provisioned purely, and strictly by the cluster's network administrators; and should not be writable by tenant users, or even tenant network administrators.
# - Cluster specific networking attributes (VLAN ID, VxLAN ID, name of host NICs, backend associated CNI config files) can be freely configured via the ClusterNetwork API.
# DANM can connect Pods of any tenant to a ClusterNetwork if the cluster administrator allows it.
kind: ClusterNetwork
metadata:
# Name of the K8s ClusterNetwork object this file represents
# MANDATORY - STRING
name: ## ClusterNetwork_NAME ##
spec:
# This parameter provides a second identifier for ClusterNetworks, and can be used to control a number of API features.
# For static delegates, the parameter configures which CNI configuration file is to be used if NetworkType points to a static-level CNI backend.
# VxLAN host interfaces are suffixed, while VLAN host interfaces are prefixed with the NetworkID.
# This allows deployment administrators to separate their own interfaces from others' in a multi-tenant environment, i.e. by setting NetworkID to "name_namespace" value.
# OPTIONAL - STRING, MAXIMUM 10 CHARACTERS
NetworkID: ## NETWORK_ID ##
# This parameter, denotes which backend is used to provision the container interface connected to this network.
# Currently supported values with dynamic integration level are IPVLAN (default), SRIOV, or MACVLAN.
# - IPVLAN option results in an IPVLAN sub-interface provisioned in L2 mode, and connected to the designated host device
# - SRIOV option pushes a pre-allocated Virtual Function of the configured host device to the container's netns
# - MACVLAN option results in a MACVLAN sub-interface provisioned in bridge mode, and connected to the designated host device
# Setting this option to another value results in delegating the network provisioning operation to the named backend with static configuration (i.e. coming from a standard CNI config file).
# The default IPVLAN backend is used when this parameter is not specified.
# OPTIONAL - ONE OF {ipvlan,sriov,macvlan,<NAME_OF_ANY_STATIC_LEVEL_CNI_COMPLIANT_BINARY>}
# DEFAULT VALUE: ipvlan
NetworkType: ## BACKEND_TYPE ##
# Even though ClusterNetwork is a cluster scoped API, operators can still control which tenants have access to these networks via the AllowedTenants attribute.
# AllowedTenants is a whitelist of K8s namespaces. Pods belonging to at least one of the listed namespaces are allowed to connect to the particular ClusterNetwork.
# If AllowedTenants is not defined, it is interpreted as "all". This means all Pods of every K8s namespace can connect to a ClusterNetwork by default.
# OPTIONAL - LIST OF STRINGS
# DEFAULT VALUE: EMPTY - NO RESTRICTIONS TO TENANTS
AllowedTenants:
# - K8S_NAMESPACE1
# - K8S_NAMESPACE2
# Specific extra configuration options can be passed to the network provisioning backends.
# Most of the parameters are generally supported for all network types.
# Options only supported for dynamic level backends, such as IPVLAN, MACVLAN, and SRIOV are explicitly noted.
Options:
# Name of the parent host device (i.e. physical host NIC).
# Sub-interfaces are connected to this NIC in case NetworkType is set to IPVLAN, or MACVLAN.
# Only has an effect with dynamically integrated backends. Ignored for other NetworkTypes.
# Also ignored for SR-IOV, as the pre-allocated Virtual Functions belonging to the configured Kubernetes Device pool are pushed into the connecting Pod's network namespace, regardless which Physical Funtion they belong to.
# OPTIONAL - STRING
host_device: ## PARENT_DEVICE_NAME ##
# Name of a network Device Plugin resource pool
# The device_pool parameter generally represents the base resource name of the Kubernetes Devices connected to this network.
# This option is mandatory for ClusterNetworks with "NetworkType: sriov", and it represents the K8s Virtual Function Device pool connecting Pods are getting their VFs from.
# OPTIONAL - STRING
device_pool: ## DEVICE_PLUGIN_RESOURCE_POOL_MAME ##
# The IPv4 CIDR notation of the subnet associated with the network.
# Pods connecting to this network will get their IPv4 addresses from this subnet, if defined.
# OPTIONAL - IPv4 CIDR FORMAT (e.g. "10.0.0.0/24")
cidr: ## SUBNET_CIDR ##
# IPv4 address allocation will be done according to the narrowed down allocation pool parameter, if defined.
# Allocation pool must be provided together with "cidr", and shall be included in the subnet range.
# If CIDR is provided without defining an allocation pool, it is automatically calculated for the whole netmask (minus the first, and the last IP).
# The gateway IPs of all the configured IP routes are also automatically reserved in the allocation pool when it is generated.
# When the network administrator manually sets the allocation pool, DANM assumes the non-usable IPs (e.g. broadcast IP, gateway IPs etc.) were already discounted.
allocation_pool:
start: ## FIRST_ASSIGNABLE_IP ##
end: ## LAST_ASSIGNABLE_IP ##
# The IPv6 CIDR notation of the subnet associated with the network.
# Pods connecting to this network will get their IPv6s from this subnet, if defined.
# OPTIONAL - IPv6 CIDR FORMAT (e.g. "2001:db8::/45").
net6: ## SUBNET_CIDR ##
# IPv6 address allocation will be done according to the narrowed down allocation pool parameter, if defined.
# V6 allocation pool must be provided together with "net6", and shall be included in the subnet range.
# The gateway IPs of all the configured IPv6 routes are also automatically reserved in the V6 allocation pool when it is generated.
# When the network administrator manually sets the allocation pool, DANM assumes the non-usable IPs (e.g. broadcast IP, gateway IPs etc.) were already discounted.
allocation_pool_v6:
# A narrower V6 subnet CIDR from which IPv6 addresses can be dynamically allocated.
# Maximum usable subnet prefix is /106.
# If Net6 is provided without manually defining a V6 allocation pool CIDR, it is automatically defaulted to the first /106 subnet of the Net6 (minus the first, and the last IP).
# The same defaulting also takes place when a V6 IP address is allocated from a network not yet containing allocation_pool_v6.
# OPTIONAL - IPv6 CIDR FORMAT (e.g. "2a00:8a00:a000:1193::3e:1010/106").
cidr: ## SUBNET_CIDR ##
start: ## FIRST_ASSIGNABLE_IP ##
end: ## LAST_ASSIGNABLE_IP ##
# Interfaces connected to this network are renamed inside the Pod's network namespace to a string starting with "container_prefix".
# If not provided, DANM uses "eth" as the prefix.
# In both cases DANM dynamically suffixes the interface names in Pod instantiation time with a unique integer number, corresponding to the sequence number of the interface during the specific network creation operation.
# Thus it becomes guaranteed no network interfaces will ever receive the same name, even if more than one belongs to the same ClusterNetwork.
# Generally supported parameter, works with all NetworkTypes (except where the CNI backend itself is not following the CNI standard, such is the case with Flannel).
# OPTIONAL - STRING
# NOTE: DANM ignores this parameter if the respective interface is the first in the connecting Pod's network namespace. That interface will be named "eth0".
container_prefix: ## INTERNAL_IF_NAME ##
# Policy-based IP routes belonging to this network are installed into this routing table, when a user defines them in her Pod's interfaces annotation.
# Generally supported parameter, works with all NetworkTypes.
# OPTIONAL - INTEGER (e.g. 201)
rt_tables: ## HOST_UNIQUE_ROUTING_TABLE_NUMBER ##
# IPv4 routes to be installed into the default routing table of all Pods connected to this network.
# Generally supported parameter, works with all NetworkTypes.
# NOTE: some CNI backends, like Flannel might provision IP routes into the default routing table of a Pod on their own.
# Beware of clashes.
# OPTIONAL - LIST OF DESTINATION_IPV4_CIDR:IPV4_GW ENTRIES (e.g. "10.20.0.0/24: 10.0.0.1")
routes:
## IP_ROUTE_1 ##
## IP_ROUTE_2 ##
# IPv6 routes to be installed into the default routing table of all Pods connected to this network.
# Generally supported parameter, works with all NetworkTypes.
# NOTE: some CNI backends might provision IP routes into the default routing table of a Pod on their own.
# Beware of clashes.
# OPTIONAL - LIST OF DESTINATION_IPV6_CIDR:IPV6_GW ENTRIES
routes6:
## IP_ROUTE_1 ##
## IP_ROUTE_2 ##
# When this parameter is present, traffic flowing through the connected network interfaces is VxLAN tagged with the provided virtual ID.
# The VxLAN tag shall be unique on the level of the underlying host.
# Management of the VxLAN interface is handled automatically by DANM. Provisioning is generally supported for all NetworkTypes.
# Only IPVLAN, and MACVLAN interfaces are automatically connected to the provisioned VxLAN VTEP though.
# VLAN and VxLAN paramaters are mutually exclusive! Defining both in the same ClusterNetwork will result in a validation error!
# OPTIONAL - INTEGER (e.g. 50)
vxlan: ## VXLAN_TAG ##
# When this parameter is present, traffic flowing through the connected network interfaces is VLAN tagged with the provided identifier.
# The VLAN ID shall be unique on the level of the underlying host.
# Management of the VLAN interface is handled automatically by DANM. Provisioning is generally supported for all NetworkTypes.
# Only dynamically supported NetworkType interfaces are automatically VLAN tagged though.
# VLAN and VxLAN paramaters are mutually exclusive! Defining both in the same ClusterNetwork will result in a validation error!
# OPTIONAL - INTEGER (e.g. 4000)
vlan: ## VLAN_TAG ##