Concepts

Detailed explanations of Kubernetes system concepts and abstractions.

Documentation for Kubernetes v1.8 is no longer actively maintained. The version you are currently viewing is a static snapshot. For up-to-date documentation, see the latest version.

Edit This Page

Cloud Providers

This page explains how to manage Kubernetes running on a specific cloud provider.

AWS

This section describes all the possible configurations which can be used when running Kubernetes on Amazon Web Services.

Load Balancers

You can setup external load balancers to use specific features in AWS by configuring the annotations as shown below.

apiVersion: v1
kind: Service
metadata:
  name: example
  namespace: kube-system
  labels:
    run: example
  annotations:
     service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:xx-xxxx-x:xxxxxxxxx:xxxxxxx/xxxxx-xxxx-xxxx-xxxx-xxxxxxxxx #replace this value
     service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
spec:
  type: LoadBalancer
  ports:
  - port: 443
    targetPort: 5556
    protocol: TCP
  selector:
    app: example

Different settings can be applied to a load balancer service in AWS using annotations. The following describes the annotations supported on AWS ELBs:

The information for the annotations for AWS is taken from the comments on aws.go

OpenStack

This section describes all the possible configurations which can be used when using OpenStack with Kubernetes. The OpenStack cloud provider implementation for Kubernetes supports the use of these OpenStack services from the underlying cloud, where available:

Service API Version(s) Required
Block Storage (Cinder) V1†, V2 No
Compute (Nova) V2 No
Identity (Keystone) V2‡, V3 Yes
Load Balancing (Neutron) V1§, V2 No

† Block Storage V1 API support is deprecated, support for Block Storage V3 will be added in the future.

‡ Identity V2 API support is deprecated and will be removed from the provider in a future release. As of the “Queens” release, OpenStack will no longer expose the Identity V2 API.

§ Load Balancing V1 API support is deprecated and will be removed from the provider in a future release.

Service discovery is achieved by listing the service catalog managed by OpenStack Identity (Keystone) using the auth-url provided in the provider configuration. The provider will gracefully degrade in functionality when OpenStack services other than Keystone are not available and simply disclaim support for impacted features. Certain features are also enabled or disabled based on the list of extensions published by Neutron in the underlying cloud.

cloud.conf

Kubernetes knows how to interact with OpenStack via the file cloud.conf. It is the file that will provide Kubernetes with credentials and location for the OpenStack auth endpoint. You can create a cloud.conf file by specifying the following details in it

Typical configuration

This is an example of a typical configuration that touches the values that most often need to be set. It points the provider at the OpenStack cloud’s Keystone endpoint, provides details for how to authenticate with it, and configures the load balancer:

[Global]
username=user
password=pass
auth-url=https://<keystone_ip>/identity/v3
tenant-id=c869168a828847f39f7f06edd7305637
domain-id=2a73b8f597c04551a0fdc8e95544be8a

[LoadBalancer]
subnet-id=6937f8fa-858d-4bc9-a3a5-18d2c957166a

Global

These configuration options for the OpenStack provider pertain to its global configuration and should appear in the [Global] section of the cloud.conf file:

When using Keystone V3 - which changes tenant to project - the tenant-id value is automatically mapped to the project construct in the API.

Load Balancer

These configuration options for the OpenStack provider pertain to the load balancer and should appear in the [LoadBalancer] section of the cloud.conf file:

Block Storage

These configuration options for the OpenStack provider pertain to block storage and should appear in the [BlockStorage] section of the cloud.conf file:

If deploying Kubernetes versions <= 1.8 on an OpenStack deployment that uses paths rather than ports to differentiate between endpoints it may be necessary to explicitly set the bs-version parameter. A path based endpoint is of the form http://foo.bar/volume while a port based endpoint is of the form http://foo.bar:xxx.

In environments that use path based endpoints and Kubernetes is using the older auto-detection logic a BS API version autodetection failed. error will be returned on attempting volume detachment. To workaround this issue it is possible to force the use of Cinder API version 2 by adding this to the cloud provider configuration:

[BlockStorage]
bs-version=v2

Metadata

These configuration options for the OpenStack provider pertain to metadata and should appear in the [Metadata] section of the cloud.conf file:

Router

These configuration options for the OpenStack provider pertain to the kubenet Kubernetes network plugin and should appear in the [Router] section of the cloud.conf file:

Analytics

Create an Issue Edit this Page