Magnum/Networking - Revision history

Danehans: /* Magnum Networking Details */

2015-12-10T17:56:55Z

‎Magnum Networking Details

Danehans: /* Magnum Networking Details */

2015-12-10T17:33:35Z

‎Magnum Networking Details

Danehans: /* Magnum Networking Details */

2015-12-09T22:24:41Z

‎Magnum Networking Details

Danehans: /* Magnum Networking Details */

2015-12-09T21:35:37Z

‎Magnum Networking Details

Danehans: /* Magnum Networking Details */

2015-12-09T21:35:19Z

‎Magnum Networking Details

Danehans: /* Magnum Networking Details */

2015-12-09T21:34:36Z

‎Magnum Networking Details

Danehans: /* Magnum Networking Workflow */

2015-12-09T20:42:02Z

‎Magnum Networking Workflow

Danehans: /* References */

2015-12-09T20:41:46Z

‎References

Danehans: /* Magnum Networking Details */

2015-12-09T20:41:16Z

‎Magnum Networking Details

Show changes

Danehans: /* Magnum Networking Overview */

2015-12-09T19:51:13Z

‎Magnum Networking Overview

@@ Line 11: / Line 11: @@
 == Magnum Networking Details ==
-As previously mentioned, Magnum masters/nodes host necessary services such as docker, kube-api, kubelet, etc. required to run containers. Nodes are connected to a Neutron network, which is connected to a Neutron router. The Neutron router provides connectivity between the node network and a pre-existing Neutron external network. The ''external-network-id'' attribute is used to specify the Neutron external network during a Magnum baymodel-create:
+As previously mentioned, Magnum masters/nodes host necessary services such as docker, kube-api, kubelet, etc. required to run containers. Nodes are connected to a Neutron network, which is connected to a Neutron router. The Neutron router provides connectivity between the node network and a pre-existing Neutron external network. The ''external-network-id'' attribute is used to specify the Neutron external network during a Magnum baymodel-create. As previously mentioned, Magnum supports multiple COE's. This guide will use the Kubernetes COE for all examples:
 <pre>
 magnum baymodel-create --name k8sbaymodel \
@@ Line 20: / Line 19: @@
                         --coe kubernetes
 </pre>
 Floating-ip's are automatically assigned from the external network to the masters and nodes during a bay-create and are used for externally accessing the nodes (e.g. SSH management). The baymodel is referenced during a ''bay-create'' to specify attributes such as the Neutron ''external-network-id'':
 <pre>
 $ magnum bay-create --name k8sbay --baymodel k8sbaymodel --node-count 1
 </pre>
-Let's break down how the [https://github.com/openstack/magnum/tree/master/magnum/templates/kubernetes Kubernetes Heat templates] that are responsible for orchestrating the bay, including the master, node and container networking. Since our example uses a baymodel with the [http://www.projectatomic.io/ Atomic] image, we will focus on the [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubecluster.yaml kubecluster], [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubemaster.yaml kubemaster] and [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubeminion.yaml kubeminion] templates. Kubecluster is the top-level template, where cluster-wide resources and parameters are defined. Masters and nodes are implemented within kubecluster as resource groups. For more information on Heat resource groups, read Steve Hardy's [http://hardysteven.blogspot.com/2014/09/using-heat-resourcegroup-resources.html blog post].
+=== Magnum Heat Template Workflow ===
 [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubecluster.yaml kubecluster] creates a Neutron private network and subnet:
@@ Line 104: / Line 103: @@
 </pre>
-The Neutron LBaaS service is implemented for the Kubernetes API and [https://github.com/coreos/etcd Etcd] services. This provides high availability and allows us to scale-out control plane services :
+The Neutron LBaaS service is implemented for the Kubernetes API and [https://github.com/coreos/etcd Etcd] services. This provides high availability and allows scale-out of control plane services :
 <pre>
    api_monitor:
@@ Line 154: / Line 153: @@
 </pre>
-The [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubecluster.yaml kubecluster] template then moves to the [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubecluster.yaml#L387-L427 kube_master resource group] to orchestrate Kubernetes Master-specific resources. The [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubemaster.yaml kubemaster template] creates a Neutron port, floating-ip and associates the port to the Kubernetes API and Etcd load-balancing pools.
+The [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubecluster.yaml kubecluster] template then moves to the [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubecluster.yaml#L387-L427 kube_master resource group] to orchestrate Kubernetes master-specific resources. The [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubemaster.yaml kubemaster template] creates a Neutron port, floating-ip and associates the port to the Kubernetes API and Etcd load-balancing pools.
 <pre>
    kube_master_eth0:
@@ Line 212: / Line 211: @@
 Each get_resource is a Heat SoftwareConfig resource. Review Steve Hardy's [http://hardysteven.blogspot.com/2015/05/heat-softwareconfig-resources.html blog post] for more details on SoftwareConfig resources. In general, the SoftwareConfig resources within Magnum are a series of cloud-config files or scripts to further configure the master/node. The Kubernetes SoftwareConfig files can be viewed [https://github.com/openstack/magnum/tree/master/magnum/templates/kubernetes/fragments here].
-Let's take a closer look at the three resource groups responsible for configuring container networking, [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/write-network-config.sh write_network_config], [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/network-config-service.sh network_config_service] and [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/network-service.sh network_service] SoftwareConfig resources.
+=== Container Networking Resource Groups ===
-The [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/write-network-config.sh write_network_config] resource is responsible for managing the Flannel configuration files.
+Let's take a closer look at the three resource groups responsible for configuring container networking, [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/write-network-config.sh write_network_config], [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/network-config-service.sh network_config_service] and [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/network-service.sh network_service] SoftwareConfig resources. The [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/write-network-config.sh write_network_config] resource is responsible for managing the Flannel configuration files. The [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/network-config-service.sh network_config_service] resource is responsible for managing the Flannel configuration service binary, systemd unit file and starts the service. The [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/network-service.sh network_service] resource is responsible for exposing the flannel service to the Docker daemon.
-The [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/network-config-service.sh network_config_service] resource is responsible for managing the Flannel configuration service binary, systemd unit file and starts the service.
+=== What About the Nodes? ===
-The [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/network-service.sh network_service] resource is responsible for exposing the flannel service to the Docker daemon.
+Magnum nodes are also known as Minions within the Kubernetes COE. '''Note:''' The Kubernetes project has completed the naming convention change from minion to node, but this change has not been implemented in Magnum yet. Magnum nodes follow a similar workflow as the masters. Similar to the master template, the kubeminion template creates resources for a [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubeminion.yaml#L321-L357 Neutron port, floating-ip and Nova virtual machine]. The template also uses resource groups to further configure the node. The node uses only one resource , called [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubeminion.yaml#L316 network_service] to configure container networking. This is because the Flannel configuration service only runs on masters. Nodes simply configure the Flannel daemon, start the daemon which reads the required configuration from etcd.

← Older revision		Revision as of 17:33, 10 December 2015
Line 22:		Line 22:


−	Floating-ip's are automatically assigned from the external network to the masters and nodes during a bay-create and are used for externally accessing the nodes (e.g. SSH management). ~~When~~ a bay ~~is created, baymodel~~ attributes such as the ''external-network-id'' ~~are used to specify required and optional settings~~:	+	Floating-ip's are automatically assigned from the external network to the masters and nodes during a bay-create and are used for externally accessing the nodes (e.g. SSH management). The baymodel is referenced during a ''bay-create'' to specify attributes such as the Neutron ''external-network-id'':

	<pre>		<pre>

@@ Line 28: / Line 28: @@
 </pre>
-Let's break down how the [https://github.com/openstack/magnum/tree/master/magnum/templates/kubernetes Kubernetes Heat templates] orchestrate networking. Since our example uses a baymodel with the [http://www.projectatomic.io/ Atomic] image, we will focus on the [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubecluster.yaml kubecluster], [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubemaster.yaml kubemaster] and [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubeminion.yaml kubeminion] templates. Kubecluster is the top-level template, where cluster-wide resources and parameters are defined and masters/nodes are implemented as resource groups. For more information on Heat resource groups, read Steve Hardy's [http://hardysteven.blogspot.com/2014/09/using-heat-resourcegroup-resources.html blog post].
+Let's break down how the [https://github.com/openstack/magnum/tree/master/magnum/templates/kubernetes Kubernetes Heat templates] that are responsible for orchestrating the bay, including the master, node and container networking. Since our example uses a baymodel with the [http://www.projectatomic.io/ Atomic] image, we will focus on the [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubecluster.yaml kubecluster], [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubemaster.yaml kubemaster] and [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubeminion.yaml kubeminion] templates. Kubecluster is the top-level template, where cluster-wide resources and parameters are defined. Masters and nodes are implemented within kubecluster as resource groups. For more information on Heat resource groups, read Steve Hardy's [http://hardysteven.blogspot.com/2014/09/using-heat-resourcegroup-resources.html blog post].
 [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubecluster.yaml kubecluster] creates a Neutron private network and subnet:
@@ Line 154: / Line 154: @@
 </pre>
-The [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubecluster.yaml kubecluster] template then moves to the [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubecluster.yaml#L387-L427 kube_master resource group] to orchestrate Kubernetes Master-specific resources. The https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubemaster.yaml kubemaster template] creates a Neutron port, floating-ip and associates the port to the Kubernetes API and Etcd load-balancing pools.
+The [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubecluster.yaml kubecluster] template then moves to the [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubecluster.yaml#L387-L427 kube_master resource group] to orchestrate Kubernetes Master-specific resources. The [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubemaster.yaml kubemaster template] creates a Neutron port, floating-ip and associates the port to the Kubernetes API and Etcd load-balancing pools.
 <pre>
    kube_master_eth0:
@@ Line 190: / Line 189: @@
 Heat then goes through a series of steps to configure the Kubernetes master:
 <pre>
    kube_master_init:
@@ Line 214: / Line 212: @@
 Each get_resource is a Heat SoftwareConfig resource. Review Steve Hardy's [http://hardysteven.blogspot.com/2015/05/heat-softwareconfig-resources.html blog post] for more details on SoftwareConfig resources. In general, the SoftwareConfig resources within Magnum are a series of cloud-config files or scripts to further configure the master/node. The Kubernetes SoftwareConfig files can be viewed [https://github.com/openstack/magnum/tree/master/magnum/templates/kubernetes/fragments here].
-Let's take a closer look at the [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/write-network-config.sh write_network_config], [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/network-config-service.sh network_config_service] and [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/network-service.sh network_service] SoftwareConfig resources.
+Let's take a closer look at the three resource groups responsible for configuring container networking, [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/write-network-config.sh write_network_config], [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/network-config-service.sh network_config_service] and [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/network-service.sh network_service] SoftwareConfig resources.

@@ Line 18: / Line 18: @@
                         --keypair-id testkey \
                         --external-network-id public \
                         --coe kubernetes
 </pre>

@@ Line 14: / Line 14: @@
 <pre>
-$ magnum baymodel-create --name k8sbaymodel --image-id fedora-21-atomic-5 --keypair-id testkey --external-network-id public --coe kubernetes
+magnum baymodel-create --name k8sbaymodel \
 </pre>
 Floating-ip's are automatically assigned from the external network to the masters and nodes during a bay-create and are used for externally accessing the nodes (e.g. SSH management). When a bay is created, baymodel attributes such as the ''external-network-id'' are used to specify required and optional settings:

← Older revision		Revision as of 20:42, 9 December 2015
Line 218:		Line 218:

	Let's take a closer look at the [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/write-network-config.sh write_network_config], [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/network-config-service.sh network_config_service] and [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/network-service.sh network_service] SoftwareConfig resources.		Let's take a closer look at the [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/write-network-config.sh write_network_config], [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/network-config-service.sh network_config_service] and [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/network-service.sh network_service] SoftwareConfig resources.
−
−	~~== Magnum Networking Workflow ==~~

← Older revision		Revision as of 20:41, 9 December 2015
Line 218:		Line 218:

	Let's take a closer look at the [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/write-network-config.sh write_network_config], [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/network-config-service.sh network_config_service] and [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/network-service.sh network_service] SoftwareConfig resources.		Let's take a closer look at the [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/write-network-config.sh write_network_config], [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/network-config-service.sh network_config_service] and [https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/fragments/network-service.sh network_service] SoftwareConfig resources.
−
−	~~== References ==~~
−
−
−
−
−	~~[https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubecluster.yaml#L253-L284 networking]~~
−	~~[https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubecluster.yaml#L286-L330 secgroups]~~
−	~~[https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubemaster.yaml#L319-L334 master port and float]~~
−	~~[https://github.com/openstack/magnum/blob/master/magnum/templates/kubernetes/kubeminion.yaml#L343-L357 Minion port and float]~~

	== Magnum Networking Workflow ==		== Magnum Networking Workflow ==

@@ Line 1: / Line 1: @@
 == Magnum Networking Overview ==
-Networking within Magnum is separated into two parts, node/master networking and container networking. Magnum nodes/masters are implemented as Nova virtual machines, bare-metal machines will be supported at a future date with [https://blueprints.launchpad.net/magnum/+spec/magnum-baremetal-full-support this blueprint]. Magnum leverages [https://github.com/openstack/magnum/tree/master/magnum/templates Heat templates] to orchestrate required resources to instantiate a bay (e.g. clustered container environment). For example, Neutron ports are created, nodes/masters Nova instances are spawned and attached to Neutron ports, Kubernetes services and associated configuration files are managed, etc.. Masters run control plane services such as kube-api, kube-scheduler, etc., while nodes run worker services such as the kubelet. The exact services running on a master/node are specific to the ''coe'' (Container Orchestration Engine) baymodel attribute.
+Networking within Magnum is separated into two parts, node/master networking and container networking. Magnum nodes/masters are implemented as Nova virtual machines, bare-metal machines will be supported at a future date with [https://blueprints.launchpad.net/magnum/+spec/magnum-baremetal-full-support this blueprint]. Magnum leverages [https://github.com/openstack/magnum/tree/master/magnum/templates Heat templates] to orchestrate required resources to instantiate a bay. For example, Neutron ports are created, nodes/masters Nova instances are spawned and attached to Neutron ports, Kubernetes services and associated configuration files are managed, etc.. Masters run control plane services such as kube-api, kube-scheduler, etc., while nodes run worker services such as the kubelet. The exact services running on a master/node are specific to the ''coe'' (Container Orchestration Engine) baymodel attribute.
 Magnum nodes communicate over a Neutron network. This allows, for example, the kubelet service running on a node to communicate with the kube-api service running on a master. In addition to node networking, container networking is used to interconnect containers running on Magnum nodes. The details for providing this connectivity depends on the container networking implementation used by the COE. Container networking follows the Magnum Container Networking Model [https://review.openstack.org/#/c/204686/ spec]. In general, each COE has a default container networking driver that allows Magnum users to instantiate bays without the need to specify any container networking information.