copyright | lastupdated | ||
---|---|---|---|
|
2018-03-16 |
{:new_window: target="_blank"} {:shortdesc: .shortdesc} {:screen: .screen} {:pre: .pre} {:table: .aria-labeledby="caption"} {:codeblock: .codeblock} {:tip: .tip} {:download: .download}
{: #subnets}
Change the pool of available portable public or private IP addresses by adding subnets to your Kubernetes cluster in {{site.data.keyword.containerlong}}. {:shortdesc}
In {{site.data.keyword.containershort_notm}}, you can add stable, portable IPs for Kubernetes services by adding network subnets to the cluster. In this case, subnets are not being used with netmasking to create connectivity across one or more clusters. Instead, the subnets are used to provide permanent fixed IPs for a service from a cluster that can be used to access that service.
When you create a standard cluster, {{site.data.keyword.containershort_notm}} automatically provisions a portable public subnet with 5 public IP addresses and a portable private subnet with 5 private IP addresses. Portable public and private IP addresses are static and do not change when a worker node, or even the cluster, is removed. For each subnet, one of the portable public and one of the portable private IP addresses are used for application load balancers that you can use to expose multiple apps in your cluster. The remaining four portable public and four portable private IP addresses can be used to expose single apps to the public by creating a load balancer service.
Note: Portable public IP addresses are charged monthly. If you choose to remove portable public IP addresses after your cluster is provisioned, you still have to pay the monthly charge, even if you used them only for a short amount of time.
{: #request}
You can add stable, portable public or private IPs to the cluster by assigning subnets to the cluster. {:shortdesc}
Note: When you make a subnet available to a cluster, IP addresses of this subnet are used for cluster networking purposes. To avoid IP address conflicts, make sure that you use a subnet with one cluster only. Do not use a subnet for multiple clusters or for other purposes outside of {{site.data.keyword.containershort_notm}} at the same time.
Before you begin, target your CLI to your cluster.
To create a subnet in an IBM Cloud infrastructure (SoftLayer) account and make it available to a specified cluster:
-
Provision a new subnet.
bx cs cluster-subnet-create <cluster_name_or_id> <subnet_size> <VLAN_ID>
{: pre}
Understanding this command's components -
Verify that the subnet was successfully created and added to your cluster. The subnet CIDR is listed in the VLANs section.
bx cs cluster-get --showResources <cluster name or id>
{: pre}
{: #custom}
You can add existing portable public or private subnets to your Kubernetes cluster. {:shortdesc}
Before you begin, target your CLI to your cluster.
To use an existing subnet in your IBM Cloud infrastructure (SoftLayer) portfolio with custom firewall rules or available IP addresses:
-
Identify the subnet to use. Note the ID of the subnet and the VLAN ID. In this example, the subnet ID is 807861 and the VLAN ID is 1901230.
bx cs subnets
{: pre}
Getting subnet list... OK ID Network Gateway VLAN ID Type Bound Cluster 553242 203.0.113.0/24 10.87.15.00 1565280 private 807861 192.0.2.0/24 10.121.167.180 1901230 public
{: screen}
-
Confirm the location that the VLAN is located. In this example, the location is dal10.
bx cs vlans dal10
{: pre}
Getting VLAN list... OK ID Name Number Type Router 1900403 vlan 1391 private bcr01a.dal10 1901230 vlan 1180 public fcr02a.dal10
{: screen}
-
Create a cluster by using the location and VLAN ID that you identified. Include the
--no-subnet
flag to prevent a new portable public IP subnet and a new portable private IP subnet from being created automatically.bx cs cluster-create --location dal10 --machine-type u2c.2x4 --no-subnet --public-vlan 1901230 --private-vlan 1900403 --workers 3 --name my_cluster
{: pre}
-
Verify that the creation of the cluster was requested.
bx cs clusters
{: pre}
Note: It can take up to 15 minutes for the worker node machines to be ordered, and for the cluster to be set up and provisioned in your account.
When the provisioning of your cluster is completed, the status of your cluster changes to deployed.
Name ID State Created Workers Location Version my_cluster paf97e8843e29941b49c598f516de72101 deployed 20170201162433 3 dal10 1.8.8
{: screen}
-
Check the status of the worker nodes.
bx cs workers <cluster>
{: pre}
When the worker nodes are ready, the state changes to normal and the status is Ready. When the node status is Ready, you can then access the cluster.
ID Public IP Private IP Machine Type State Status Location Version prod-dal10-pa8dfcc5223804439c87489886dbbc9c07-w1 169.47.223.113 10.171.42.93 free normal Ready dal10 1.8.8
{: screen}
-
Add the subnet to your cluster by specifying the subnet ID. When you make a subnet available to a cluster, a Kubernetes configmap is created for you that includes all available portable public IP addresses that you can use. If no application load balancers exist for your cluster, one portable public and one portable private IP address is automatically used to create the public and private application load balancers. All other portable public and private IP addresses can be used to create load balancer services for your apps.
bx cs cluster-subnet-add mycluster 807861
{: pre}
{: #user_managed}
Provide a subnet from an on-premises network that you want {{site.data.keyword.containershort_notm}} to access. Then, you can add private IP addresses from that subnet to load balancer services in your Kubernetes cluster. {:shortdesc}
Requirements:
- User-managed subnets can be added to private VLANs only.
- The subnet prefix length limit is /24 to /30. For example,
203.0.113.0/24
specifies 253 usable private IP addresses, while203.0.113.0/30
specifies 1 usable private IP address. - The first IP address in the subnet must be used as the gateway for the subnet.
Before you begin:
- Configure the routing of network traffic into and out of the external subnet.
- Confirm that you have VPN connectivity between the on-premises data center gateway device and either the private network Vyatta in your IBM Cloud infrastructure (SoftLayer) portfolio or the strongSwan VPN service that is running in your cluster. For more information, see Setting up VPN connectivity.
To add a subnet from an on-premises network:
-
View the ID of your cluster's Private VLAN. Locate the VLANs section. In the field User-managed, identify the VLAN ID with false.
bx cs cluster-get --showResources <cluster_name>
{: pre}
VLANs VLAN ID Subnet CIDR Public User-managed 1555503 192.0.2.0/24 true false 1555505 198.51.100.0/24 false false
{: screen}
-
Add the external subnet to your private VLAN. The portable private IP addresses are added to the cluster's configmap.
bx cs cluster-user-subnet-add <cluster_name> <subnet_CIDR> <VLAN_ID>
{: pre}
Example:
bx cs cluster-user-subnet-add my_cluster 203.0.113.0/24 1555505
{: pre}
-
Verify that the user-provided subnet is added. The field User-managed is true.
bx cs cluster-get --showResources <cluster_name>
{: pre}
VLANs VLAN ID Subnet CIDR Public User-managed 1555503 192.0.2.0/24 true false 1555505 198.51.100.0/24 false false 1555505 203.0.113.0/24 false true
{: screen}
-
Add a private load balancer service or a private Ingress application load balancer to access your app over the private network. To use a private IP address from the subnet that you added, you must specify an IP address. Otherwise, an IP address is chosen at random from the IBM Cloud infrastructure (SoftLayer) subnets or user-provided subnets on the private VLAN. For more information, see Configuring access to an app by using the load balancer service type or Enabling the private application load balancer.
{: #manage}
Review the following options for listing available public IP addresses, freeing up used IP addresses, and routing between multiple subnets on the same VLAN. {:shortdesc}
{: #review_ip}
To list all of the IP addresses in your cluster, both used and available, you can run:
kubectl get cm ibm-cloud-provider-vlan-ip-config -n kube-system -o yaml
{: pre}
To list only available public IP addresses for your cluster, you can use the following steps:
Before you begin, set the context for the cluster you want to use.
-
Create a Kubernetes service configuration file that is named
myservice.yaml
and define a service of typeLoadBalancer
with a dummy load balancer IP address. The following example uses the IP address 1.1.1.1 as the load balancer IP address.apiVersion: v1 kind: Service metadata: labels: run: myservice name: myservice namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: myservice sessionAffinity: None type: LoadBalancer loadBalancerIP: 1.1.1.1
{: codeblock}
-
Create the service in your cluster.
kubectl apply -f myservice.yaml
{: pre}
-
Inspect the service.
kubectl describe service myservice
{: pre}
Note: The creation of this service fails because the Kubernetes master cannot find the specified load balancer IP address in the Kubernetes configmap. When you run this command, you can see the error message and the list of available public IP addresses for the cluster.
Error on cloud load balancer a8bfa26552e8511e7bee4324285f6a4a for service default/myservice with UID 8bfa2655-2e85-11e7-bee4-324285f6a4af: Requested cloud provider IP 1.1.1.1 is not available. The following cloud provider IPs are available: <list_of_IP_addresses>
{: screen}
{: #free}
You can free up a used portable IP address by deleting the load balancer service that is using the portable IP address. {:shortdesc}
Before you begin, set the context for the cluster you want to use.
-
List available services in your cluster.
kubectl get services
{: pre}
-
Remove the load balancer service that uses a public or private IP address.
kubectl delete service <myservice>
{: pre}
{: #vlan-spanning}
When you create a cluster, a subnet that ends in /26
is provisioned in the same VLAN that the cluster is on. This primary subnet can hold up to 62 worker nodes.
{:shortdesc}
This 62 worker node limit might be exceeded by a large cluster or by several smaller clusters in a single region that are on the same VLAN. When the 62 worker node limit is reached, a second primary subnet in the same VLAN is ordered.
To route between subnets on the same VLAN, you must turn on VLAN spanning. For instructions, see Enable or disable VLAN spanning.