kubernetes
/
kops
mirror of https://github.com/kubernetes/kops.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update the openstack getting started docs

This commit is contained in:
Ole Markus With 2020-08-22 08:33:45 +02:00
parent 10405bc4d3
commit a63a8464db
1 changed files with 55 additions and 51 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

106
docs/getting_started/openstack.md
View File

@ -1,31 +1,46 @@
# Getting Started with kops on OpenStack
**WARNING**: OpenStack support on kops is currently **beta**, which means that OpenStack support is in good shape. However, always some small things might change before we can really say that it is production ready.
The tutorial shown on this page works with `kops` v1.12 and above.
OpenStack support on kops is currently **beta**, which means that OpenStack support is in good shape and could be used for production. However, it is not as rigorously tested as the stable cloud providers and there are some features not supported. In particular, kops tries to support a wide variety of OpenStack setups and not all of them are equally well tested.
## OpenStack requirements
In order to deploy a kops-managed clustr on OpenStack, you need the following OpenStack servces:
* Nova (compute)
* Neutron (networking)
* Glance (image)
* Cinder (block storage)
In addition, kops can make use of the following services:
* Swift (object store)
* Dvelve (dns)
* Octavia (loadbalancer)
The OpenStack version should be Ocata or newer.
## Source your openstack RC
The Cloud Config used by the kubernetes API server and kubelet will be constructed from environment variables in the openstack RC file. The openrc.sh file is usually located under `API access`.
The Cloud Config used by the kubernetes API server and kubelet will be constructed from environment variables in the openstack RC file.
```bash
source openstack.rc
```
If you are authenticating by username, `OS_DOMAIN_NAME` or `OS_DOMAIN_ID` must manually be set.
```bash
export OS_DOMAIN_NAME=<USER_DOMAIN_NAME>
```
We recommend using [Application Credentials](https://docs.openstack.org/keystone/queens/user/application_credentials.html) when authenticating to OpenStack.
**Note** The authentication used locally will be exported to your cluster and used by the kubernetes controller components. You must avoid using personal credentials used for other systems,
## Environment Variables
It is important to set the following environment variables:
kops stores its configuration in a state store. Before creating a cluster, we need to export the path to the state store:
```bash
export KOPS_STATE_STORE=swift://<bucket-name> # where <bucket-name> is the name of the Swift container to use for kops state
```
If your OpenStack does not have Swift you can use any other VFS store, such as S3.
If your OpenStack does not have Swift you can use any other VFS store, such as S3. See the [state store documentation](../state.md) for alternatives.
## Creating a Cluster
@ -60,30 +75,29 @@ kops update cluster my-cluster.k8s.local --state ${KOPS_STATE_STORE} --yes
kops delete cluster my-cluster.k8s.local --yes
```
#### Optional flags
## Optional flags
* `--os-kubelet-ignore-az=true` Nova and Cinder have different availability zones, more information [Kubernetes docs](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#block-storage)
* `--os-octavia=true` If Octavia Loadbalancer api should be used instead of old lbaas v2 api.
* `--os-dns-servers=8.8.8.8,8.8.4.4` You can define dns servers to be used in your cluster if your openstack setup does not have working dnssetup by default
# Compute and volume zone names does not match
## Compute and volume zone names does not match
Some of the openstack users do not have compute zones named exactly the same than volume zones. Good example is that there are several compute zones for instance `zone-1`, `zone-2` and `zone-3`. Then there is only one volumezone which is usually called `nova`. By default this is problem in kops, because kops assumes that if you are deploying things to `zone-1` there should be compute and volume zone called `zone-1`.
However, you can still get kops working in your openstack by doing following:
**Create cluster using your compute zones**
Create cluster using your compute zones:
```
```bash
kops create cluster \
...
--zones zone-1,zone-2,zone-3 \
...
```
**After you have initialized the configuration you need to edit configuration**
After you have initialized the configuration you need to edit configuration
```
```bash
kops edit cluster my-cluster.k8s.local
```
@ -91,20 +105,18 @@ Edit `ignore-volume-az` to `true` and `override-volume-az` according to your cin
Example (volume zone is called `nova`):
```
```yaml
spec:
...
cloudConfig:
openstack:
blockStorage:
ignore-volume-az: true
override-volume-az: nova
...
```
**Finally execute update cluster**
```
```bash
kops update cluster my-cluster.k8s.local --state ${KOPS_STATE_STORE} --yes
```
@ -113,66 +125,63 @@ Kops should create instances to all three zones, but provision volumes from the
# Using external cloud controller manager
If you want use [External CCM](https://github.com/kubernetes/cloud-provider-openstack) in your installation, this section contains instructions what you should do to get it up and running.
Enable featureflag:
```
export KOPS_FEATURE_FLAGS=EnableExternalCloudController
```
Create cluster without `--yes` flag (or modify existing cluster):
```
```bash
kops edit cluster <cluster>
```
Add following to clusterspec:
```
```yaml
spec:
cloudControllerManager: {}
```
Finally
```
```bash
kops update cluster --name <cluster> --yes
```
# Using OpenStack without lbaas
Some OpenStack installations does not include installation of lbaas component. That is why we have added very-experimental support of installing OpenStack kops without lbaas. You can install it using:
```
Some OpenStack installations does not include installation of lbaas component. To launch a cluster without a loadbalancer, run:
```bash
kops create cluster \
--cloud openstack \
... (like usually)
--api-loadbalancer-type=""
```
The biggest problem currently when installing without loadbalancer is that kubectl requests outside cluster is always going to first master. External loadbalancer is one option which can solve this issue.
In clusters without loadbalancer, the address of a single random master will be added to your kube config.
# Using existing OpenStack network
**Warning!** This feature is **experimental** use only if you know what you are doing.
By default KOPS will always create new network to your OpenStack project which name matches to your clustername. However, there is experimental feature to use existing network in OpenStack project. When you create new cluster you can specify flag `--os-network <network id>` and it will then use existing network.
You can have kops reuse existing network components instead of provisioning one per cluster. As OpenStack support is still beta, we recommend you take extra care when deleting clusters and ensure that kops do not try to remove any resources not belonging to the cluster.
Using yaml this can be specified to yaml:
## Let kops provision new subnets within an existing network
Use an existing network by using `--network <network id>`.
If you are provisioning the cluster from a spec file, add the network ID as follows:
```yaml
spec:
...
networkID: <network id>
...
```
**Warning!** when deleting cluster, you need to be really careful that you do not break another dependencies under same network. Run `kops delete cluster` without `--yes` flag and go through the list. Otherwise you might see situation that you broke something else.
# Using existing OpenStack subnets
**Warning!** This feature is **experimental** use only if you know what you are doing.
## Use existing networks
By default KOPS will always create new network and subnet to your OpenStack project. However, there is experimental feature to use existing network and subnets in OpenStack project. When you create new cluster you can specify flag `--subnets <commaseparated list of subnetids>` and it will then use existing subnet. There is similar flag for utility subnets `--utility-subnets <commaseparated list of subnetids>`.
Instead of kops creating new subnets for the cluster, you can reuse an existing subnet.
Example:
When you create a new cluster, you can specify subnets using the `--subnets` and `--utility-subnets` flags.
```
## Example
```bash
kops create cluster \
--cloud openstack \
--name sharedsub2.k8s.local \
@ -196,19 +205,14 @@ kops create cluster \
--os-octavia=true --yes
```
**Warning!** when deleting cluster, you need to be really careful that you do not break another dependencies under same network & subnet. Run `kops delete cluster` without `--yes` flag and go through the list. Otherwise you might see situation that you broke something else.
# Using with self-signed certificates in OpenStack
Kops can be configured to use insecure mode towards OpenStack. However, this is **NOT** recommended as OpenStack cloudprovider in kubernetes does not support it.
If you use insecure flag in kops - it might be that the cluster does not work correctly.
Kops can be configured to use insecure mode towards OpenStack. However, this is not recommended as OpenStack cloudprovider in kubernetes does not support it.
If you use insecure flag in kops it might be that the cluster does not work correctly.
```
```yaml
spec:
...
cloudConfig:
openstack:
insecureSkipVerify: true
...
```