mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 04:28:15 +00:00
lots of udpates
This commit is contained in:
Denise Schannon
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Config Options
|
||||
weight: 3000
|
||||
weight: 200
|
||||
draft: true
|
||||
---
|
||||
|
||||
@@ -23,13 +23,14 @@ There are several options that can be configured in cluster configuration option
|
||||
* [Services]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/)
|
||||
* [External Etcd]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/external-etcd/)
|
||||
* [Extra Args and Binds]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/extra-args-and-binds/)
|
||||
* [Add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/)
|
||||
* [Add-ons Jobs Timeout](#add-ons-jobs-timeout)
|
||||
* [Authentication]({{< baseurl >}}/rke/v0.1.x/en/config-options/authentication/)
|
||||
* [Authorization]({{< baseurl >}}/rke/v0.1.x/en/config-options/authorization/)
|
||||
* [Cloud Providers]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/)
|
||||
* [Network Plugins]({{< baseurl >}}/rke/v0.1.x/en/config-options/network-plugins/)
|
||||
* [Ingress Controller]({{< baseurl >}}/rke/v0.1.x/en/config-options/ingress-controller/)
|
||||
* Add-ons
|
||||
* [Network Plugins]({{< baseurl >}}/rke/v0.1.x/en/config-options/network-plugins/)
|
||||
* [Ingress Controller]({{< baseurl >}}/rke/v0.1.x/en/config-options/ingress-controllers/)
|
||||
* [User-Defined-Add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/user-defined-add-ons/)
|
||||
* [Add-ons Jobs Timeout](#add-ons-jobs-timeout)
|
||||
|
||||
## Cluster Level Options
|
||||
|
||||
|
||||
@@ -1,74 +1,36 @@
|
||||
---
|
||||
title: Add-Ons
|
||||
weight: 3000
|
||||
weight: 250
|
||||
draft: true
|
||||
---
|
||||
|
||||
RKE supports pluggable add-ons. Add-ons are used to deploy several cluster components including:
|
||||
|
||||
RKE supports pluggable add-ons. Addons are used to deploy several cluster components including:
|
||||
- Network plugin
|
||||
- KubeDNS
|
||||
- Ingress controller
|
||||
* [Network plugin]({{< baseurl >}}/rke/v0.1.x/en/config-options/network-plugins/)
|
||||
* [Ingress controller]({{< baseurl >}}/rke/v0.1.x/en/config-options/ingress-controllers/)
|
||||
* KubeDNS
|
||||
|
||||
In addition, a user can specify an addon yaml manifests in the cluster.yml file. RKE will deploy the user-defined add-ons after the cluster deployment is complete.
|
||||
In addition to these pluggable add-ons, you can specify an add-on that you want deployed after the cluster deployment is complete.
|
||||
|
||||
RKE first uploads the yaml manifest as a configmap to the Kubernetes cluster. Next, it will run a kubernetes job that mounts this configmap and deploy the addon by running `kubectl apply -f`.
|
||||
RKE only adds additional add-ons when using `rke up` multiple times. RKE does **not** support removing of cluster add-ons when doing `rke up` with a different list of add-ons.
|
||||
|
||||
> **Note: RKE doesn't support removal or update of cluster add-ons when doing `rke up` with a different list of add-ons. Please update the add-ons by using `kubectl edit`.**
|
||||
As of v0.1.8, RKE will update an add-on if it is the same name.
|
||||
|
||||
Prior to v0.1.8, update any add-ons by by using `kubectl edit`.
|
||||
|
||||
## Critical and Non-Critical Add-ons
|
||||
|
||||
#### Critical and non-critical add-ons
|
||||
As of version `0.1.7`, add-ons are split into two categories:
|
||||
As of version v0.1.7, add-ons are split into two categories:
|
||||
|
||||
- **Critical add-ons:** If these add-ons fail to deploy for any reason, RKE will error out.
|
||||
- **Non-critical add-ons:** If these add-ons fail to deploy, RKE will only log a warning and continue deploying other add-ons.
|
||||
- **Non-critical add-ons:** If these add-ons fail to deploy, RKE will only log a warning and continue deploying any other add-ons.
|
||||
|
||||
Currently, only the [network plug-in]({{< baseurl >}}/rke/v0.1.x/en/config-options/network-plugins/) is considered critical. KubeDNS, [ingress controllers]({{< baseurl >}}/rke/v0.1.x/en/config-options/ingress-controllers/) and [user-defined add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/user-defined-add-ons/) are considered non-critical.
|
||||
|
||||
Currently, only the network plugin is considered critical. KubeDNS, Ingress and user-defined add-ons are considered non-critical.
|
||||
## Add-on deployment jobs
|
||||
|
||||
## Defining User Addons
|
||||
RKE uses Kubernetes jobs to deploy add-ons. In some cases, add-ons deployment takes longer than expected. As of with version v0.1.7, RKE provides an option to control the job check timeout in seconds. This timeout is set at the cluster level.
|
||||
|
||||
User defined add-ons can be added by either defining the yaml directly in the RKE config or pointing to a file. Adding a yaml directly into the file uses the `addons` directive, while pointing to a file uses the `addons_include:` directive.
|
||||
|
||||
> **Note**: When using user-defined add-ons, you *must* define a namespace for *all* your resources, otherwise they will end up in the `kube-system` namespace.
|
||||
|
||||
##### In-line Addons
|
||||
To define an add-on directly in the yaml file, make sure to use the yaml's block indicator `|-` as the `addons` directive is a multi-line string option. It's possible to specify multiple yaml resource definitions by separating them using the `---` directive.
|
||||
|
||||
```yaml
|
||||
addons: |-
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: my-nginx
|
||||
namespace: default
|
||||
spec:
|
||||
containers:
|
||||
- name: my-nginx
|
||||
image: nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
```
|
||||
|
||||
|
||||
#### Referencing files for Add-ons
|
||||
|
||||
User defined add-ons support referencing a local file or a URL.
|
||||
|
||||
```yaml
|
||||
addons_include:
|
||||
- https://raw.githubusercontent.com/rook/rook/master/cluster/examples/kubernetes/rook-operator.yaml
|
||||
- https://raw.githubusercontent.com/rook/rook/master/cluster/examples/kubernetes/rook-cluster.yaml
|
||||
- /opt/manifests/example.yaml
|
||||
- ./nginx.yaml
|
||||
```
|
||||
|
||||
|
||||
#### Addon deployment jobs
|
||||
|
||||
RKE uses kubernetes Jobs to deploy add-ons. In some cases, add-ons deployment takes longer than expected. Starting with version `0.1.7-rc1`, RKE provides an option to control the job check timeout in seconds:
|
||||
```yaml
|
||||
addon_job_timeout: 30
|
||||
```
|
||||
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: Ingress Controllers
|
||||
weight: 252
|
||||
draft: true
|
||||
---
|
||||
|
||||
By default, RKE deploys the nginx ingress controller on all schedulable nodes.
|
||||
|
||||
> **Note:** As of v0.1.8, only workers are considered schedulable nodes, but prior to v0.1.8, worker and controlplane nodes were considered schedulable nodes.
|
||||
|
||||
RKE will deploy the ingress controller as a DaemonSet with `hostnetwork: true`, so ports `80`, and `443` will be opened on each node where the controller is deployed.
|
||||
|
||||
## Scheduling Ingress Controllers
|
||||
|
||||
If you only wanted ingress controllers to be deployed on specific nodes, you can set a `node_selector` for the ingress. The label in the `node_selector` would need to match the label on the nodes for the ingress controller to be deployed.
|
||||
|
||||
```yaml
|
||||
nodes:
|
||||
- address: 1.1.1.1
|
||||
role: [controlplane,worker,etcd]
|
||||
user: root
|
||||
labels:
|
||||
app: ingress
|
||||
|
||||
ingress:
|
||||
provider: nginx
|
||||
node_selector:
|
||||
app: ingress
|
||||
```
|
||||
|
||||
## Disabling the Default Ingress Controller
|
||||
|
||||
You can disable the default controller by specifying `none` to the ingress `provider` directive in the cluster configuration.
|
||||
|
||||
```yaml
|
||||
ingress:
|
||||
provider: none
|
||||
```
|
||||
## Nginx Ingress Controller
|
||||
|
||||
For the configuration of nginx, there are some configuration options. There are a [list of options](https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/configmap.md) for the nginx config map and [command line extra_args](https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/cli-arguments.md).
|
||||
|
||||
```
|
||||
ingress:
|
||||
provider: nginx
|
||||
options:
|
||||
map-hash-bucket-size: "128"
|
||||
ssl-protocols: SSLv2
|
||||
extra_args:
|
||||
enable-ssl-passthrough: ""
|
||||
```
|
||||
+1
-1
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Network Plug-ins
|
||||
weight: 3000
|
||||
weight: 251
|
||||
draft: true
|
||||
---
|
||||
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: User-Defined Add-Ons
|
||||
weight: 253
|
||||
draft: true
|
||||
---
|
||||
|
||||
Besides the [network plug-in]({{< baseurl >}}/rke/v0.1.x/en/config-options/network-plugins/) and [ingress controllers]({{< baseurl >}}/rke/v0.1.x/en/config-options/ingress-controllers/), you can define any add-on that you want deployed after the Kubernetes cluster is deployed.
|
||||
|
||||
There are two ways that you can specify an add-on.
|
||||
|
||||
- [In-line Add-ons](#inline-add-ons)
|
||||
- [Referencing YAML Files for Add-ons](#referencing-yaml-files-for-add-ons)
|
||||
|
||||
> **Note:** When using user-defined add-ons, you *must* define a namespace for *all* your resources, otherwise they will end up in the `kube-system` namespace.
|
||||
|
||||
RKE uploads the YAML manifest as a configmap to the Kubernetes cluster. Then, it runs a Kubernetes job that mounts the configmap and deploys the add-on using `kubectl apply -f`.
|
||||
|
||||
RKE only adds additional add-ons when using `rke up` multiple times. RKE does **not** support removing of cluster add-ons when doing `rke up` with a different list of add-ons.
|
||||
|
||||
As of v0.1.8, RKE will update an add-on if it is the same name.
|
||||
|
||||
Prior to v0.1.8, update any add-ons by by using `kubectl edit`.
|
||||
|
||||
## In-line Addons
|
||||
To define an add-on directly in the YAML file, make sure to use the YAML's block indicator `|-` as the `addons` directive is a multi-line string option. It's possible to specify multiple YAML resource definitions by separating them using the `---` directive.
|
||||
|
||||
```yaml
|
||||
addons: |-
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: my-nginx
|
||||
namespace: default
|
||||
spec:
|
||||
containers:
|
||||
- name: my-nginx
|
||||
image: nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
```
|
||||
|
||||
## Referencing YAML files for Add-ons
|
||||
Use the `addons_include` directive to reference a local file or a URL for any user-defined add-ons.
|
||||
|
||||
```yaml
|
||||
addons_include:
|
||||
- https://raw.githubusercontent.com/rook/rook/master/cluster/examples/kubernetes/rook-operator.yaml
|
||||
- https://raw.githubusercontent.com/rook/rook/master/cluster/examples/kubernetes/rook-cluster.yaml
|
||||
- /opt/manifests/example.yaml
|
||||
- ./nginx.yaml
|
||||
```
|
||||
@@ -1,15 +1,15 @@
|
||||
---
|
||||
title: Authentication
|
||||
weight: 3000
|
||||
weight: 235
|
||||
draft: true
|
||||
---
|
||||
|
||||
RKE supports x509 authentication strategy. You can additionally define a list of SANs (Subject Alternative Names) to add to the Kubernetes API Server PKI certificates. This allows you to connect to your Kubernetes cluster API Server through a load balancer, for example, rather than a single node.
|
||||
RKE supports x509 authentication strategy. You can additionally define a list of SANs (Subject Alternative Names) to add to the Kubernetes API Server PKI certificates. As an example, this allows you to connect to your Kubernetes cluster API Server through a load balancer instead of a single node.
|
||||
|
||||
```yaml
|
||||
authentication:
|
||||
strategy: x509
|
||||
sans:
|
||||
- "10.18.160.10"
|
||||
- "my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com"
|
||||
strategy: x509
|
||||
sans:
|
||||
- "10.18.160.10"
|
||||
- "my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com"
|
||||
```
|
||||
|
||||
@@ -1,16 +1,15 @@
|
||||
---
|
||||
title: Authorization
|
||||
weight: 3000
|
||||
weight: 240
|
||||
draft: true
|
||||
---
|
||||
|
||||
Kubernetes supports multiple [Authorization Modules](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#authorization-modules). Currently, RKE provides support for the [RBAC module](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) only.
|
||||
Kubernetes supports multiple [Authorization Modules](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#authorization-modules). Currently, RKE only supports the [RBAC module](https://kubernetes.io/docs/reference/access-authn-authz/rbac/).
|
||||
|
||||
RBAC is enabled by default in RKE. It's possible to disable authorization support by seeting the authorization mode to `none`
|
||||
By default, RBAC is already enabled. If you wanted to turn off RBAC support, **which isn't recommended**, you set the authorization mode to `none`.
|
||||
|
||||
```yaml
|
||||
# Use `mode: none` to disable authorization
|
||||
authorization:
|
||||
mode: rbac
|
||||
# Use `mode: none` to disable authorization
|
||||
mode: rbac
|
||||
```
|
||||
<!-- explain cluster authorization configuration-->
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Bastion/Jump Host Configuration
|
||||
weight: 3015
|
||||
weight: 220
|
||||
draft: true
|
||||
---
|
||||
|
||||
@@ -8,15 +8,15 @@ Since RKE uses `ssh` to connect to [nodes]({{< baseurl >}}/rke/v0.1.x/en/config-
|
||||
|
||||
```yaml
|
||||
bastion_host:
|
||||
address: x.x.x.x
|
||||
user: ubuntu
|
||||
port: 22
|
||||
ssh_key_path: /home/user/.ssh/bastion_rsa
|
||||
# or
|
||||
# ssh_key: |-
|
||||
# -----BEGIN RSA PRIVATE KEY-----
|
||||
#
|
||||
# -----END RSA PRIVATE KEY-----
|
||||
address: x.x.x.x
|
||||
user: ubuntu
|
||||
port: 22
|
||||
ssh_key_path: /home/user/.ssh/bastion_rsa
|
||||
# or
|
||||
# ssh_key: |-
|
||||
# -----BEGIN RSA PRIVATE KEY-----
|
||||
#
|
||||
# -----END RSA PRIVATE KEY-----
|
||||
```
|
||||
|
||||
## Bastion Host Options
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Cloud Providers
|
||||
weight: 3000
|
||||
weight: 245
|
||||
draft: true
|
||||
---
|
||||
|
||||
@@ -21,7 +21,7 @@ To enable the AWS cloud provider, there are no configuration options. You only n
|
||||
|
||||
```yaml
|
||||
cloud_provider:
|
||||
name: aws
|
||||
name: aws
|
||||
```
|
||||
|
||||
#### IAM Requirements
|
||||
@@ -74,17 +74,17 @@ To enable the Azure cloud provider, besides setting the name as `azure`, there a
|
||||
|
||||
```yaml
|
||||
cloud_provider:
|
||||
name: azure
|
||||
azureCloudProvider:
|
||||
aadClientId: xxxxxxxxx
|
||||
aadClientSecret: xxxxxxxxx
|
||||
location: xxxxxxxxx
|
||||
resourceGroup: xxxxxxxxx
|
||||
subnetName: xxxxxxxxx
|
||||
subscriptionId: xxxxxxxxx
|
||||
vnetName: xxxxxxxxx
|
||||
tenantId: xxxxxxxxx
|
||||
securityGroupName: xxxxxxxxx
|
||||
name: azure
|
||||
azureCloudProvider:
|
||||
aadClientId: xxxxxxxxx
|
||||
aadClientSecret: xxxxxxxxx
|
||||
location: xxxxxxxxx
|
||||
resourceGroup: xxxxxxxxx
|
||||
subnetName: xxxxxxxxx
|
||||
subscriptionId: xxxxxxxxx
|
||||
vnetName: xxxxxxxxx
|
||||
tenantId: xxxxxxxxx
|
||||
securityGroupName: xxxxxxxxx
|
||||
```
|
||||
|
||||
#### Overriding the hostname
|
||||
@@ -93,13 +93,13 @@ Since the Azure node name must match the Kubernetes node name, you override the
|
||||
|
||||
```yaml
|
||||
nodes:
|
||||
- address: x.x.x.x
|
||||
hostname_override: azure-rke1
|
||||
user: ubuntu
|
||||
role:
|
||||
- controlplane
|
||||
- etcd
|
||||
- worker
|
||||
- address: x.x.x.x
|
||||
hostname_override: azure-rke1
|
||||
user: ubuntu
|
||||
role:
|
||||
- controlplane
|
||||
- etcd
|
||||
- worker
|
||||
```
|
||||
|
||||
#### Azure Configuration Options
|
||||
@@ -143,22 +143,22 @@ To enable the Openstack cloud provider, besides setting the name as `openstack`,
|
||||
|
||||
```yaml
|
||||
cloud_provider:
|
||||
name: openstack
|
||||
openstackCloudProvider:
|
||||
global:
|
||||
username: xxxxxxxxxxxxxx
|
||||
password: xxxxxxxxxxxxxx
|
||||
auth-url: https://1.2.3.4/identity/v3
|
||||
tenant-id: xxxxxxxxxxxxxx
|
||||
domain-id: xxxxxxxxxxxxxx
|
||||
load_balancer:
|
||||
subnet-id: xxxxxxxxxxxxxx
|
||||
block_storage:
|
||||
ignore-volume-az: true
|
||||
route:
|
||||
router-id: xxxxxxxxxxxxxx
|
||||
metadata:
|
||||
search-order: xxxxxxxxxxxxxx
|
||||
name: openstack
|
||||
openstackCloudProvider:
|
||||
global:
|
||||
username: xxxxxxxxxxxxxx
|
||||
password: xxxxxxxxxxxxxx
|
||||
auth-url: https://1.2.3.4/identity/v3
|
||||
tenant-id: xxxxxxxxxxxxxx
|
||||
domain-id: xxxxxxxxxxxxxx
|
||||
load_balancer:
|
||||
subnet-id: xxxxxxxxxxxxxx
|
||||
block_storage:
|
||||
ignore-volume-az: true
|
||||
route:
|
||||
router-id: xxxxxxxxxxxxxx
|
||||
metadata:
|
||||
search-order: xxxxxxxxxxxxxx
|
||||
```
|
||||
|
||||
#### Overriding the hostname
|
||||
@@ -247,32 +247,32 @@ To enable the vSphere cloud provider, besides setting the name as `vsphere`, the
|
||||
|
||||
```yaml
|
||||
cloud_provider:
|
||||
name: vsphere
|
||||
vsphereCloudProvider:
|
||||
global:
|
||||
user: user
|
||||
password: pass
|
||||
server: 1.2.3.4
|
||||
port: 22
|
||||
virtual_center:
|
||||
1.2.3.4:
|
||||
user: test
|
||||
password: test
|
||||
port: test
|
||||
5.6.7.8:
|
||||
user: test
|
||||
password: test
|
||||
port: test
|
||||
workspace:
|
||||
server: test.test.com
|
||||
datacenter: test
|
||||
folder: test
|
||||
default-datastore: test
|
||||
resourcepool-path: test
|
||||
network:
|
||||
public-network: xxxxxxxxxxxxxx
|
||||
disk:
|
||||
scsicontrollertype: xxxxxxxxxxxxxx
|
||||
name: vsphere
|
||||
vsphereCloudProvider:
|
||||
global:
|
||||
user: user
|
||||
password: pass
|
||||
server: 1.2.3.4
|
||||
port: 22
|
||||
virtual_center:
|
||||
1.2.3.4:
|
||||
user: test
|
||||
password: test
|
||||
port: test
|
||||
5.6.7.8:
|
||||
user: test
|
||||
password: test
|
||||
port: test
|
||||
workspace:
|
||||
server: test.test.com
|
||||
datacenter: test
|
||||
folder: test
|
||||
default-datastore: test
|
||||
resourcepool-path: test
|
||||
network:
|
||||
public-network: xxxxxxxxxxxxxx
|
||||
disk:
|
||||
scsicontrollertype: xxxxxxxxxxxxxx
|
||||
```
|
||||
|
||||
#### vSphere Configuration Options
|
||||
@@ -311,14 +311,14 @@ These are the options that are available under `virtual_center`, which is a dict
|
||||
|
||||
```yaml
|
||||
virtual_center:
|
||||
<vcenter1-ip>:
|
||||
user: test
|
||||
password: test
|
||||
port: test
|
||||
<vcenter2-ip>:
|
||||
user: test
|
||||
password: test
|
||||
port: test
|
||||
<vcenter1-ip>:
|
||||
user: test
|
||||
password: test
|
||||
port: test
|
||||
<vcenter2-ip>:
|
||||
user: test
|
||||
password: test
|
||||
port: test
|
||||
```
|
||||
|
||||
For each `virtual_center`, these are the available configuration options to be used under the each virtual center. The virtual center's are separated from each other based on their IP.
|
||||
@@ -376,11 +376,11 @@ To add this cloud config file to RKE, the `cloud_provider` would be need to be s
|
||||
|
||||
```yaml
|
||||
cloud_provider:
|
||||
name: ovirt
|
||||
# Note the pipe as this is what indicates a multiline string
|
||||
customCloudProvider: |-
|
||||
[connection]
|
||||
uri = https://localhost:8443/ovirt-engine/api
|
||||
username = admin@internal
|
||||
password = admin
|
||||
name: ovirt
|
||||
# Note the pipe as this is what indicates a multiline string
|
||||
customCloudProvider: |-
|
||||
[connection]
|
||||
uri = https://localhost:8443/ovirt-engine/api
|
||||
username = admin@internal
|
||||
password = admin
|
||||
```
|
||||
|
||||
@@ -1,92 +1,96 @@
|
||||
---
|
||||
title: Example Cluster.ymls
|
||||
weight: 3000
|
||||
weight: 205
|
||||
draft: true
|
||||
---
|
||||
|
||||
There are lots of different config options that can be set in the cluster configuration file for RKE. Here are some examples of files:
|
||||
|
||||
### Minimal `cluster.yml` example
|
||||
## Minimal `cluster.yml` example
|
||||
|
||||
```
|
||||
# default k8s version: v1.8.10-rancher1-1
|
||||
# default network plugin: canal
|
||||
```yaml
|
||||
nodes:
|
||||
- address: 1.2.3.4
|
||||
user: ubuntu
|
||||
role: [controlplane,worker,etcd]
|
||||
- address: 1.2.3.4
|
||||
user: ubuntu
|
||||
role:
|
||||
- controlplane
|
||||
- etcd
|
||||
- worker
|
||||
ssh_key_path: /home/user/.ssh/id_rsa
|
||||
port: 22
|
||||
```
|
||||
|
||||
### Full `cluster.yml` example
|
||||
## Full `cluster.yml` example
|
||||
|
||||
```yaml
|
||||
---
|
||||
nodes:
|
||||
- address: 1.1.1.1
|
||||
user: ubuntu
|
||||
role:
|
||||
- controlplane
|
||||
- etcd
|
||||
ssh_key_path: /home/user/.ssh/id_rsa
|
||||
port: 2222
|
||||
- address: 2.2.2.2
|
||||
user: ubuntu
|
||||
role:
|
||||
- worker
|
||||
ssh_key: |-
|
||||
-----BEGIN RSA PRIVATE KEY-----
|
||||
- address: 1.1.1.1
|
||||
user: ubuntu
|
||||
role:
|
||||
- controlplane
|
||||
- etcd
|
||||
ssh_key_path: /home/user/.ssh/id_rsa
|
||||
port: 2222
|
||||
- address: 2.2.2.2
|
||||
user: ubuntu
|
||||
role:
|
||||
- worker
|
||||
ssh_key: |-
|
||||
-----BEGIN RSA PRIVATE KEY-----
|
||||
|
||||
-----END RSA PRIVATE KEY-----
|
||||
- address: example.com
|
||||
user: ubuntu
|
||||
role:
|
||||
- role
|
||||
hostname_override: node3
|
||||
internal_address: 192.168.1.6
|
||||
labels:
|
||||
app: ingress
|
||||
-----END RSA PRIVATE KEY-----
|
||||
- address: example.com
|
||||
user: ubuntu
|
||||
role:
|
||||
- worker
|
||||
hostname_override: node3
|
||||
internal_address: 192.168.1.6
|
||||
labels:
|
||||
app: ingress
|
||||
|
||||
services:
|
||||
etcd:
|
||||
# if external etcd is used
|
||||
# path: /etcdcluster
|
||||
# external_urls:
|
||||
# - https://etcd-example.com:2379
|
||||
# ca_cert: |-
|
||||
# -----BEGIN CERTIFICATE-----
|
||||
# xxxxxxxxxx
|
||||
# -----END CERTIFICATE-----
|
||||
# cert: |-
|
||||
# -----BEGIN CERTIFICATE-----
|
||||
# xxxxxxxxxx
|
||||
# -----END CERTIFICATE-----
|
||||
# key: |-
|
||||
# -----BEGIN PRIVATE KEY-----
|
||||
# xxxxxxxxxx
|
||||
# -----END PRIVATE KEY-----
|
||||
kube-api:
|
||||
service_cluster_ip_range: 10.43.0.0/16
|
||||
pod_security_policy: false
|
||||
# add additional arguments to the kubernetes component
|
||||
# Note that this WILL OVERRIDE existing defaults
|
||||
extra_args:
|
||||
# Enable audit log to stdout
|
||||
audit-log-path: "-"
|
||||
# Increase number of delete workers
|
||||
delete-collection-workers: 3
|
||||
# Set the level of log output to debug-level
|
||||
v: 4
|
||||
kube-controller:
|
||||
cluster_cidr: 10.42.0.0/16
|
||||
service_cluster_ip_range: 10.43.0.0/16
|
||||
scheduler:
|
||||
kubelet:
|
||||
cluster_domain: cluster.local
|
||||
cluster_dns_server: 10.43.0.10
|
||||
infra_container_image: gcr.io/google_containers/pause-amd64:3.0
|
||||
# Optionally define additional volume binds to a service
|
||||
extra_binds:
|
||||
- "/usr/libexec/kubernetes/kubelet-plugins:/usr/libexec/kubernetes/kubelet-plugins"
|
||||
kubeproxy:
|
||||
etcd:
|
||||
# if external etcd is used
|
||||
# path: /etcdcluster
|
||||
# external_urls:
|
||||
# - https://etcd-example.com:2379
|
||||
# ca_cert: |-
|
||||
# -----BEGIN CERTIFICATE-----
|
||||
# xxxxxxxxxx
|
||||
# -----END CERTIFICATE-----
|
||||
# cert: |-
|
||||
# -----BEGIN CERTIFICATE-----
|
||||
# xxxxxxxxxx
|
||||
# -----END CERTIFICATE-----
|
||||
# key: |-
|
||||
# -----BEGIN PRIVATE KEY-----
|
||||
# xxxxxxxxxx
|
||||
# -----END PRIVATE KEY-----
|
||||
kube-api:
|
||||
service_cluster_ip_range: 10.43.0.0/16
|
||||
pod_security_policy: false
|
||||
# add additional arguments to the kubernetes component
|
||||
# Note that this WILL OVERRIDE existing defaults
|
||||
extra_args:
|
||||
# Enable audit log to stdout
|
||||
audit-log-path: "-"
|
||||
# Increase number of delete workers
|
||||
delete-collection-workers: 3
|
||||
# Set the level of log output to debug-level
|
||||
v: 4
|
||||
kube-controller:
|
||||
cluster_cidr: 10.42.0.0/16
|
||||
service_cluster_ip_range: 10.43.0.0/16
|
||||
scheduler:
|
||||
kubelet:
|
||||
cluster_domain: cluster.local
|
||||
cluster_dns_server: 10.43.0.10
|
||||
infra_container_image: gcr.io/google_containers/pause-amd64:3.0
|
||||
# Optionally define additional volume binds to a service
|
||||
extra_binds:
|
||||
- "/usr/libexec/kubernetes/kubelet-plugins:/usr/libexec/kubernetes/kubelet-plugins"
|
||||
kubeproxy:
|
||||
|
||||
# supported plugins are:
|
||||
# flannel
|
||||
@@ -116,18 +120,18 @@ services:
|
||||
|
||||
|
||||
network:
|
||||
plugin: flannel
|
||||
options:
|
||||
plugin: flannel
|
||||
options:
|
||||
|
||||
# At the moment, the only authentication strategy supported is x509.
|
||||
# You can optionally create additional SANs (hostnames or IPs) to add to
|
||||
# the API server PKI certificate. This is useful if you want to use a load balancer
|
||||
# for the control plane servers, for example.
|
||||
authentication:
|
||||
strategy: x509
|
||||
sans:
|
||||
- "10.18.160.10"
|
||||
- "my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com"
|
||||
strategy: x509
|
||||
sans:
|
||||
- "10.18.160.10"
|
||||
- "my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com"
|
||||
|
||||
# all addon manifests MUST specify a namespace
|
||||
addons: |-
|
||||
@@ -150,18 +154,18 @@ addons_include:
|
||||
- /path/to/manifest
|
||||
|
||||
system_images:
|
||||
etcd: rancher/etcd:v3.0.17
|
||||
kubernetes: rancher/hyperkube:v1.10.1
|
||||
alpine: rancher/rke-tools:v0.1.4
|
||||
nginx_proxy: rancher/rke-tools:v0.1.4
|
||||
cert_downloader: rancher/rke-tools:v0.1.4
|
||||
kubernetes_services_sidecar: rancher/rke-tools:v0.1.4
|
||||
kubedns: rancher/k8s-dns-kube-dns-amd64:1.14.5
|
||||
dnsmasq: rancher/k8s-dns-dnsmasq-nanny-amd64:1.14.5
|
||||
kubedns_sidecar: rancher/k8s-dns-sidecar-amd64:1.14.5
|
||||
kubedns_autoscaler: rancher/cluster-proportional-autoscaler-amd64:1.0.0
|
||||
flannel: rancher/coreos-flannel:v0.9.1
|
||||
flannel_cni: rancher/coreos-flannel-cni:v0.2.0
|
||||
etcd: rancher/etcd:v3.0.17
|
||||
kubernetes: rancher/hyperkube:v1.10.1
|
||||
alpine: rancher/rke-tools:v0.1.4
|
||||
nginx_proxy: rancher/rke-tools:v0.1.4
|
||||
cert_downloader: rancher/rke-tools:v0.1.4
|
||||
kubernetes_services_sidecar: rancher/rke-tools:v0.1.4
|
||||
kubedns: rancher/k8s-dns-kube-dns-amd64:1.14.5
|
||||
dnsmasq: rancher/k8s-dns-dnsmasq-nanny-amd64:1.14.5
|
||||
kubedns_sidecar: rancher/k8s-dns-sidecar-amd64:1.14.5
|
||||
kubedns_autoscaler: rancher/cluster-proportional-autoscaler-amd64:1.0.0
|
||||
flannel: rancher/coreos-flannel:v0.9.1
|
||||
flannel_cni: rancher/coreos-flannel-cni:v0.2.0
|
||||
|
||||
|
||||
ssh_key_path: ~/.ssh/test
|
||||
@@ -170,7 +174,7 @@ ssh_key_path: ~/.ssh/test
|
||||
# Use `mode: rbac` to enable RBAC
|
||||
# Use `mode: none` to disable authorization
|
||||
authorization:
|
||||
mode: rbac
|
||||
mode: rbac
|
||||
|
||||
# If set to true, rke won't fail when unsupported Docker version is found
|
||||
ignore_docker_version: false
|
||||
@@ -186,9 +190,9 @@ cluster_name: mycluster
|
||||
# List of registry credentials, if you are using a Docker Hub registry,
|
||||
# you can omit the `url` or set it to `docker.io`
|
||||
private_registries:
|
||||
- url: registry.com
|
||||
user: Username
|
||||
password: password
|
||||
- url: registry.com
|
||||
user: Username
|
||||
password: password
|
||||
|
||||
# Currently only nginx ingress provider is supported.
|
||||
# To disable ingress controller, set `provider: none`
|
||||
@@ -211,20 +215,20 @@ private_registries:
|
||||
# enable-ssl-passthrough: ""
|
||||
|
||||
ingress:
|
||||
provider: nginx
|
||||
provider: nginx
|
||||
|
||||
cloud_provider:
|
||||
name: aws
|
||||
name: aws
|
||||
|
||||
# Bastion/Jump host configuration
|
||||
bastion_host:
|
||||
address: x.x.x.x
|
||||
user: ubuntu
|
||||
port: 22
|
||||
ssh_key_path: /home/user/.ssh/bastion_rsa
|
||||
# or
|
||||
# ssh_key: |-
|
||||
# -----BEGIN RSA PRIVATE KEY-----
|
||||
#
|
||||
# -----END RSA PRIVATE KEY-----
|
||||
address: x.x.x.x
|
||||
user: ubuntu
|
||||
port: 22
|
||||
ssh_key_path: /home/user/.ssh/bastion_rsa
|
||||
# or
|
||||
# ssh_key: |-
|
||||
# -----BEGIN RSA PRIVATE KEY-----
|
||||
#
|
||||
# -----END RSA PRIVATE KEY-----
|
||||
```
|
||||
|
||||
@@ -1,33 +0,0 @@
|
||||
---
|
||||
title: Ingress Controller
|
||||
weight: 3000
|
||||
draft: true
|
||||
---
|
||||
|
||||
|
||||
RKE will deploy Nginx controller by default, user can disable this by specifying `none` to ingress `provider` option in the cluster configuration, user also can specify list of options for nginx config map listed in this [doc](https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/configmap.md), and command line extra_args listed in this [doc](https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/cli-arguments.md), for example:
|
||||
```
|
||||
ingress:
|
||||
provider: nginx
|
||||
options:
|
||||
map-hash-bucket-size: "128"
|
||||
ssl-protocols: SSLv2
|
||||
extra_args:
|
||||
enable-ssl-passthrough: ""
|
||||
```
|
||||
By default, RKE will deploy ingress controller on all schedulable nodes (controlplane and workers), to specify only certain nodes for ingress controller to be deployed, user has to specify `node_selector` for the ingress and the right label on the node, for example:
|
||||
```
|
||||
nodes:
|
||||
- address: 1.1.1.1
|
||||
role: [controlplane,worker,etcd]
|
||||
user: root
|
||||
labels:
|
||||
app: ingress
|
||||
|
||||
ingress:
|
||||
provider: nginx
|
||||
node_selector:
|
||||
app: ingress
|
||||
```
|
||||
|
||||
RKE will deploy Nginx Ingress controller as a DaemonSet with `hostnetwork: true`, so ports `80`, and `443` will be opened on each node where the controller is deployed.
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Nodes
|
||||
weight: 3005
|
||||
weight: 210
|
||||
draft: true
|
||||
---
|
||||
|
||||
@@ -8,30 +8,30 @@ The `nodes` directive is the only required section in the `cluster.yml` file. It
|
||||
|
||||
```yaml
|
||||
nodes:
|
||||
nodes:
|
||||
- address: 1.1.1.1
|
||||
user: ubuntu
|
||||
role:
|
||||
- controlplane
|
||||
- etcd
|
||||
ssh_key_path: /home/user/.ssh/id_rsa
|
||||
port: 2222
|
||||
- address: 2.2.2.2
|
||||
user: ubuntu
|
||||
role:
|
||||
- worker
|
||||
ssh_key: |-
|
||||
-----BEGIN RSA PRIVATE KEY-----
|
||||
nodes:
|
||||
- address: 1.1.1.1
|
||||
user: ubuntu
|
||||
role:
|
||||
- controlplane
|
||||
- etcd
|
||||
ssh_key_path: /home/user/.ssh/id_rsa
|
||||
port: 2222
|
||||
- address: 2.2.2.2
|
||||
user: ubuntu
|
||||
role:
|
||||
- worker
|
||||
ssh_key: |-
|
||||
-----BEGIN RSA PRIVATE KEY-----
|
||||
|
||||
-----END RSA PRIVATE KEY-----
|
||||
- address: example.com
|
||||
user: ubuntu
|
||||
role:
|
||||
- role
|
||||
hostname_override: node3
|
||||
internal_address: 192.168.1.6
|
||||
labels:
|
||||
app: ingress
|
||||
-----END RSA PRIVATE KEY-----
|
||||
- address: example.com
|
||||
user: ubuntu
|
||||
role:
|
||||
- worker
|
||||
hostname_override: node3
|
||||
internal_address: 192.168.1.6
|
||||
labels:
|
||||
app: ingress
|
||||
```
|
||||
|
||||
## Node Options
|
||||
@@ -94,7 +94,7 @@ If the Docker socket is different than the default, you can set the `docker_sock
|
||||
|
||||
### Labels
|
||||
|
||||
You have the ability to add an arbitrary map of labels for each node. It can be used when using the [ingress controller's]({{< baseurl >}}/rke/v0.1.x/en/config-options/ingress-controller/) `node_selector` option.
|
||||
You have the ability to add an arbitrary map of labels for each node. It can be used when using the [ingress controller's]({{< baseurl >}}/rke/v0.1.x/en/config-options/ingress-controllers/) `node_selector` option.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Private Registries
|
||||
weight: 3010
|
||||
weight: 215
|
||||
draft: true
|
||||
---
|
||||
|
||||
@@ -8,12 +8,12 @@ RKE supports the ability to configure multiple private Docker registries. By pas
|
||||
|
||||
```yaml
|
||||
private_registries:
|
||||
- url: registry.com
|
||||
user: Username
|
||||
password: password
|
||||
- url: myregistry.com
|
||||
user: myuser
|
||||
password: mypassword
|
||||
- url: registry.com
|
||||
user: Username
|
||||
password: password
|
||||
- url: myregistry.com
|
||||
user: myuser
|
||||
password: mypassword
|
||||
```
|
||||
|
||||
### Air-gapped Setups
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Kubernetes Services
|
||||
weight: 3025
|
||||
weight: 230
|
||||
draft: true
|
||||
---
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: External etcd
|
||||
weight: 3027
|
||||
weight: 232
|
||||
draft: true
|
||||
---
|
||||
|
||||
@@ -8,24 +8,24 @@ By default, RKE will launch etcd servers, but RKE also supports being able to us
|
||||
|
||||
> **Note:** RKE will not accept having external etcd servers in conjunction with [nodes]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/) with the `etcd` role.
|
||||
|
||||
```
|
||||
```yaml
|
||||
services:
|
||||
etcd:
|
||||
path: /etcdcluster
|
||||
external_urls:
|
||||
- https://etcd-example.com:2379
|
||||
ca_cert: |-
|
||||
-----BEGIN CERTIFICATE-----
|
||||
xxxxxxxxxx
|
||||
-----END CERTIFICATE-----
|
||||
cert: |-
|
||||
-----BEGIN CERTIFICATE-----
|
||||
xxxxxxxxxx
|
||||
-----END CERTIFICATE-----
|
||||
key: |-
|
||||
-----BEGIN PRIVATE KEY-----
|
||||
xxxxxxxxxx
|
||||
-----END PRIVATE KEY-----
|
||||
etcd:
|
||||
path: /etcdcluster
|
||||
external_urls:
|
||||
- https://etcd-example.com:2379
|
||||
ca_cert: |-
|
||||
-----BEGIN CERTIFICATE-----
|
||||
xxxxxxxxxx
|
||||
-----END CERTIFICATE-----
|
||||
cert: |-
|
||||
-----BEGIN CERTIFICATE-----
|
||||
xxxxxxxxxx
|
||||
-----END CERTIFICATE-----
|
||||
key: |-
|
||||
-----BEGIN PRIVATE KEY-----
|
||||
xxxxxxxxxx
|
||||
-----END PRIVATE KEY-----
|
||||
```
|
||||
|
||||
## External etcd Options
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Extra Args and Binds
|
||||
weight: 3026
|
||||
weight: 231
|
||||
draft: true
|
||||
---
|
||||
|
||||
@@ -16,10 +16,9 @@ Prior to `v0.1.3`, using `extra_args` would only add new arguments to the list a
|
||||
|
||||
```yaml
|
||||
services:
|
||||
# ...
|
||||
kube-controller:
|
||||
extra_args:
|
||||
cluster-name: "mycluster"
|
||||
kube-controller:
|
||||
extra_args:
|
||||
cluster-name: "mycluster"
|
||||
```
|
||||
|
||||
## Extra Binds
|
||||
@@ -28,9 +27,8 @@ Additional volume binds can be made to services using the `extra_binds` argument
|
||||
|
||||
```yaml
|
||||
services:
|
||||
# ...
|
||||
kubelet:
|
||||
extra_binds:
|
||||
- "/host/dev:/dev"
|
||||
- "/usr/libexec/kubernetes/kubelet-plugins:/usr/libexec/kubernetes/kubelet-plugins:z"
|
||||
kubelet:
|
||||
extra_binds:
|
||||
- "/host/dev:/dev"
|
||||
- "/usr/libexec/kubernetes/kubelet-plugins:/usr/libexec/kubernetes/kubelet-plugins:z"
|
||||
```
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: System Images
|
||||
weight: 3020
|
||||
weight: 225
|
||||
draft: true
|
||||
---
|
||||
When RKE is deploying Kubernetes, there are several images that are pulled. These images are used as Kubernetes system components as well as helping to deploy these system components.
|
||||
@@ -13,43 +13,43 @@ This is the example of the full list of system images used to deploy Kubernetes
|
||||
|
||||
```yaml
|
||||
system_images:
|
||||
kubernetes: rancher/hyperkube:v1.10.3-rancher2
|
||||
etcd: rancher/coreos-etcd:v3.1.12
|
||||
alpine: rancher/rke-tools:v0.1.9
|
||||
nginx_proxy: rancher/rke-tools:v0.1.9
|
||||
cert_downloader: rancher/rke-tools:v0.1.9
|
||||
kubernetes_services_sidecar: rancher/rke-tools:v0.1.9
|
||||
kubedns: rancher/k8s-dns-kube-dns-amd64:1.14.8
|
||||
dnsmasq: rancher/k8s-dns-dnsmasq-nanny-amd64:1.14.8
|
||||
kubedns_sidecar: rancher/k8s-dns-sidecar-amd64:1.14.8
|
||||
kubedns_autoscaler: rancher/cluster-proportional-autoscaler-amd64:1.0.0
|
||||
pod_infra_container: rancher/pause-amd64:3.1
|
||||
kubernetes: rancher/hyperkube:v1.10.3-rancher2
|
||||
etcd: rancher/coreos-etcd:v3.1.12
|
||||
alpine: rancher/rke-tools:v0.1.9
|
||||
nginx_proxy: rancher/rke-tools:v0.1.9
|
||||
cert_downloader: rancher/rke-tools:v0.1.9
|
||||
kubernetes_services_sidecar: rancher/rke-tools:v0.1.9
|
||||
kubedns: rancher/k8s-dns-kube-dns-amd64:1.14.8
|
||||
dnsmasq: rancher/k8s-dns-dnsmasq-nanny-amd64:1.14.8
|
||||
kubedns_sidecar: rancher/k8s-dns-sidecar-amd64:1.14.8
|
||||
kubedns_autoscaler: rancher/cluster-proportional-autoscaler-amd64:1.0.0
|
||||
pod_infra_container: rancher/pause-amd64:3.1
|
||||
|
||||
# Networking Options
|
||||
flannel: rancher/coreos-flannel:v0.9.1
|
||||
flannel_cni: rancher/coreos-flannel-cni:v0.2.0
|
||||
calico_node: rancher/calico-node:v3.1.1
|
||||
calico_cni: rancher/calico-cni:v3.1.1
|
||||
calico_ctl: rancher/calico-ctl:v2.0.0
|
||||
canal_node: rancher/calico-node:v3.1.1
|
||||
canal_cni: rancher/calico-cni:v3.1.1
|
||||
canal_flannel: rancher/coreos-flannel:v0.9.1
|
||||
weave_node: weaveworks/weave-kube:2.1.2
|
||||
weave_cni: weaveworks/weave-npc:2.1.2
|
||||
# Networking Options
|
||||
flannel: rancher/coreos-flannel:v0.9.1
|
||||
flannel_cni: rancher/coreos-flannel-cni:v0.2.0
|
||||
calico_node: rancher/calico-node:v3.1.1
|
||||
calico_cni: rancher/calico-cni:v3.1.1
|
||||
calico_ctl: rancher/calico-ctl:v2.0.0
|
||||
canal_node: rancher/calico-node:v3.1.1
|
||||
canal_cni: rancher/calico-cni:v3.1.1
|
||||
canal_flannel: rancher/coreos-flannel:v0.9.1
|
||||
weave_node: weaveworks/weave-kube:2.1.2
|
||||
weave_cni: weaveworks/weave-npc:2.1.2
|
||||
|
||||
# Ingress OPTIONS
|
||||
ingress: rancher/nginx-ingress-controller:0.10.2-rancher3
|
||||
ingressBackend: rancher/nginx-ingress-controller-defaultbackend:1.4
|
||||
# Ingress Options
|
||||
ingress: rancher/nginx-ingress-controller:0.10.2-rancher3
|
||||
ingressBackend: rancher/nginx-ingress-controller-defaultbackend:1.4
|
||||
```
|
||||
|
||||
Prior to `v0.1.6`, instead of using the `rancher/rke-tools` image, we used the following images:
|
||||
|
||||
```yaml
|
||||
system_images:
|
||||
alpine: alpine:latest
|
||||
nginx_proxy: rancher/rke-nginx-proxy:v0.1.1
|
||||
cert_downloader: rancher/rke-cert-deployer:v0.1.1
|
||||
kubernetes_services_sidecar: rancher/rke-service-sidekick:v0.1.0
|
||||
alpine: alpine:latest
|
||||
nginx_proxy: rancher/rke-nginx-proxy:v0.1.1
|
||||
cert_downloader: rancher/rke-cert-deployer:v0.1.1
|
||||
kubernetes_services_sidecar: rancher/rke-service-sidekick:v0.1.0
|
||||
```
|
||||
|
||||
### Air-gapped Setups
|
||||
|
||||
@@ -4,25 +4,7 @@ weight: 50
|
||||
draft: true
|
||||
---
|
||||
|
||||
## Requirements
|
||||
|
||||
- Docker versions `1.11.2` up to `1.13.1` and `17.03.x` are validated for Kubernetes versions 1.8, 1.9 and 1.10
|
||||
- OpenSSH 7.0+ must be installed on each node for stream local forwarding to work.
|
||||
- The SSH user used for node access must be a member of the `docker` group:
|
||||
|
||||
```bash
|
||||
usermod -aG docker <user_name>
|
||||
```
|
||||
|
||||
- Ports 6443, 2379, and 2380 should be opened between cluster nodes.
|
||||
- Swap disabled on worker nodes.
|
||||
|
||||
---
|
||||
title: Quick Start Guide
|
||||
short title: Quick Start
|
||||
weight: 25
|
||||
draft: true
|
||||
---
|
||||
|
||||
RKE is a fast, versatile Kubernetes installer that you can use to install Kubernetes on your Linux hosts. You can get started in a couple of quick and easy steps:
|
||||
|
||||
@@ -32,6 +14,19 @@ RKE is a fast, versatile Kubernetes installer that you can use to install Kubern
|
||||
4. [Deploying Kubernetes with RKE](#deploying-kubernetes-with-rke)
|
||||
5. [Interacting with your Kubernetes Cluster](#interacting-with-your-kubernetes-cluster)
|
||||
|
||||
## Requirements
|
||||
|
||||
- For Kubernetes versions 1.8, 1.9 and 1.10, Docker versions `1.11.2` up to `1.13.1` and `17.03.x` are validated
|
||||
- OpenSSH 7.0+ must be installed on each node for stream local forwarding to work
|
||||
- The SSH user used for node access must be a member of the `docker` group on the node:
|
||||
|
||||
```bash
|
||||
usermod -aG docker <user_name>
|
||||
```
|
||||
|
||||
- Ports 6443, 2379, and 2380 should be opened between cluster nodes.
|
||||
- Swap should be disabled on any worker nodes
|
||||
|
||||
## Download the RKE binary
|
||||
|
||||
1. From your workstation, open a web browser and navigate to our [RKE Releases](https://github.com/rancher/rke/releases/latest) page. Download the latest RKE installer applicable to your Operating System:
|
||||
|
||||
@@ -1,16 +1,17 @@
|
||||
---
|
||||
title: Backups and Disaster Recovery
|
||||
weight: 3000
|
||||
weight: 65
|
||||
draft: true
|
||||
---
|
||||
|
||||
You can configure a Rancher Kubernetes Engine (RKE) cluster to automatically take snapshots of etcd. In a disaster scenario, you can restore these snapshots, which are stored on other cluster nodes.
|
||||
You can configure a RKE cluster to automatically take snapshots of etcd. In a disaster scenario, you can restore these snapshots, which are stored on other nodes in the cluster.
|
||||
|
||||
### One-Time Snapshots
|
||||
## One-Time Snapshots
|
||||
|
||||
RKE introduce a new command that can take a snapshot of a running etcd node in rke cluster, the snapshot will be automatically saved in `/opt/rke/etcd-snapshots`, the commands works as following:
|
||||
```
|
||||
./rke etcd snapshot-save --config cluster.yml
|
||||
RKE can take a one-time snapshot of a running etcd node in a RKE cluster. The snapshot is automatically saved in `/opt/rke/etcd-snapshots`.
|
||||
|
||||
```bash
|
||||
$ rke etcd snapshot-save --config cluster.yml
|
||||
|
||||
WARN[0000] Name of the snapshot is not specified using [rke_etcd_snapshot_2018-05-17T23:32:08+02:00]
|
||||
INFO[0000] Starting saving snapshot on etcd hosts
|
||||
@@ -26,15 +27,16 @@ INFO[0006] [etcd] Successfully started [etcd-snapshot-once] container on host [z
|
||||
INFO[0006] Finished saving snapshot [rke_etcd_snapshot_2018-05-17T23:32:08+02:00] on all etcd hosts
|
||||
```
|
||||
|
||||
The command will save a snapshot of etcd from each etcd node in the cluster config file and will save it in `/opt/rke/etcd-snapshots`. This command also creates a container for taking the snapshot. When the process completes, the container is automatically removed.
|
||||
The command will save a snapshot of etcd from each etcd node in the cluster config file and will save it in `/opt/rke/etcd-snapshots`. When running the command, an additional container is created to take the snapshot. When the snapshot is completed, the container is automatically removed.
|
||||
|
||||
### Etcd Recurring Snapshots
|
||||
## Etcd Recurring Snapshots
|
||||
|
||||
To schedule a recurring automatic etcd snapshot save, enable the `etcd-snapshot` service. `etcd-snapshot` runs in a service container alongside the `etcd` container. `etcd-snapshot` automatically takes a snapshot of etcd and stores them to its local disk in `/opt/rke/etcd-snapshots`.
|
||||
To schedule a recurring automatic etcd snapshot save, you can enable the `etcd-snapshot` service. `etcd-snapshot` runs in a service container alongside the `etcd` container. `etcd-snapshot` automatically takes a snapshot of etcd and stores them to its local disk in `/opt/rke/etcd-snapshots`.
|
||||
|
||||
To enable `etcd-snapshot` in RKE CLI, configure the following three variables:
|
||||
|
||||
```
|
||||
In the `cluster.yml`, you need to turn enable `snapshot` as part of the `etcd service`. Additionally, you want to specify `creation` and `retention` for the snapshot service.
|
||||
|
||||
```yaml
|
||||
services:
|
||||
etcd:
|
||||
snapshot: true
|
||||
@@ -42,20 +44,11 @@ services:
|
||||
retention: 24h
|
||||
```
|
||||
|
||||
- `snapshot`: Enables/disables etcd snapshot recurring service in the RKE cluster.
|
||||
|
||||
Default value: `false`.
|
||||
- `creation`: Time period in which `etcd-sanpshot` take snapshots.
|
||||
When a cluster is launched with the etcd snapshot service enabled, you can view the `etcd-snapshot` logs to confirm backups are being created automatically.
|
||||
|
||||
Default value: `5m0s`
|
||||
|
||||
- `retention`: Time period before before an etcd snapshot expires. Expired snapshots are purged.
|
||||
|
||||
Default value: `24h`
|
||||
|
||||
After RKE runs, view the `etcd-snapshot` logs to confirm backups are being created automatically:
|
||||
```
|
||||
# docker logs etcd-snapshot
|
||||
$ docker logs etcd-snapshot
|
||||
|
||||
time="2018-05-04T18:39:16Z" level=info msg="Initializing Rolling Backups" creation=1m0s retention=24h0m0s
|
||||
time="2018-05-04T18:40:16Z" level=info msg="Created backup" name="2018-05-04T18:40:16Z_etcd" runtime=108.332814ms
|
||||
@@ -63,17 +56,31 @@ time="2018-05-04T18:41:16Z" level=info msg="Created backup" name="2018-05-04T18:
|
||||
time="2018-05-04T18:42:16Z" level=info msg="Created backup" name="2018-05-04T18:42:16Z_etcd" runtime=83.67642ms
|
||||
time="2018-05-04T18:43:16Z" level=info msg="Created backup" name="2018-05-04T18:43:16Z_etcd" runtime=86.298499ms
|
||||
```
|
||||
Backups are saved to the following directory: `/opt/rke/etcd-snapshots/`. Backups are created on each node that runs etcd.
|
||||
|
||||
For every node that has the `etcd` role, these `backups` are saved to `/opt/rke/etcd-snapshots/`.
|
||||
|
||||
### Etcd Disaster recovery
|
||||
### Snapshot Options
|
||||
|
||||
`etcd snapshot-restore` is used for etcd Disaster recovery, it reverts to any snapshot stored in `/opt/rke/etcd-snapshots` that you explicitly define. When you run `etcd snapshot-restore`, RKE removes the old etcd container if it still exists. To restore operations, RKE creates a new etcd cluster using the snapshot you choose.
|
||||
**Snapshot**
|
||||
|
||||
>**Warning:** Restoring an etcd snapshot deletes your current etcd cluster and replaces it with a new one. Before you run the `etcd snapshot-restore` command, backup any important data in your current cluster.
|
||||
By default, the recurring snapshot service is disabled. To enable the service, you need to define it as part of `etcd` and set it to `true`.
|
||||
|
||||
```
|
||||
./rke etcd snapshot-restore --name snapshot --config cluster.yml
|
||||
**Creation**
|
||||
|
||||
By default, the snapshot service will take snapshots every 5 minutes (`5m0s`). You can change the time between snapshots as part of the `creation` directive for the `etcd` service.
|
||||
|
||||
**Retention**
|
||||
|
||||
By default, all snapshots are saved for 24 hours (`24h`) before being deleted and purged. You can change how long to store a snapshot as part of the `retention` directive for the `etcd` service.
|
||||
|
||||
## Etcd Disaster recovery
|
||||
|
||||
If there is a disaster with your Kubernetes cluster, you can use `rke etcd snapshot-restore` to recover your etcd. This command will revert to a specific snapshot stored in `/opt/rke/etcd-snapshots` that you explicitly define. During the restore process, RKE also removes the old `etcd` container before creating a new `etcd` cluster using the snapshot that you have chosen.
|
||||
|
||||
>**Warning:** Restoring an etcd snapshot deletes your current etcd cluster and replaces it with a new one. Before you run the `rke etcd snapshot-restore` command, you should back up any important data in your cluster.
|
||||
|
||||
```bash
|
||||
$ rke etcd snapshot-restore --name mysnapshot --config cluster.yml
|
||||
INFO[0000] Starting restore on etcd hosts
|
||||
INFO[0000] [dialer] Setup tunnel for host [x.x.x.x]
|
||||
INFO[0002] [dialer] Setup tunnel for host [y.y.y.y]
|
||||
@@ -115,62 +122,43 @@ INFO[0027] Finished restoring on all etcd hosts
|
||||
|
||||
## Example
|
||||
|
||||
In this example we will assume that you started RKE on two nodes:
|
||||
In this example, the Kubernetes cluster was deployed on two AWS nodes.
|
||||
|
||||
| Name | IP | Role |
|
||||
|:-----:|:--------:|:----------------------:|
|
||||
| node1 | 10.0.0.1 | [controlplane, worker] |
|
||||
| node2 | 10.0.0.2 | [etcd] |
|
||||
|
||||
### 1. Setting up rke cluster
|
||||
A minimal cluster configuration file for running k8s on these nodes should look something like the following:
|
||||
### Back up the `etcd` cluster
|
||||
|
||||
```
|
||||
nodes:
|
||||
- address: 10.0.0.1
|
||||
hostname_override: node1
|
||||
user: ubuntu
|
||||
role: [controlplane,worker]
|
||||
- address: 10.0.0.2
|
||||
hostname_override: node2
|
||||
user: ubuntu
|
||||
role: [etcd]
|
||||
```
|
||||
Take a snapshot of the Kubernetes cluster.
|
||||
|
||||
After running `rke up` you should be able to have a two node cluster, the next step is to run few pods on node1:
|
||||
|
||||
```
|
||||
kubectl --kubeconfig=kube_config_cluster.yml run nginx --image=nginx --replicas=3
|
||||
```
|
||||
|
||||
### 2. Backup etcd cluster
|
||||
|
||||
Now lets take a snapshot using RKE:
|
||||
|
||||
```
|
||||
rke etcd snapshot-save --name snapshot.db --config cluster.yml
|
||||
```bash
|
||||
$ rke etcd snapshot-save --name snapshot.db --config cluster.yml
|
||||
```
|
||||
|
||||
|
||||
|
||||
### 3. Store snapshot externally
|
||||
### Store the snapshot externally
|
||||
|
||||
After taking the etcd backup on node2 we should be able to save this backup in a persistence place, one of the options to do that is to save the backup taken on a s3 bucket or tape backup, for example:
|
||||
After taking the etcd snapshot on `node2`, we recommend saving this backup in a persistence place. One of the options is to save the backup on a S3 bucket or tape backup.
|
||||
|
||||
```
|
||||
```bash
|
||||
# If you're using an AWS host and have the ability to connect to S3
|
||||
root@node2:~# s3cmd mb s3://rke-etcd-backup
|
||||
root@node2:~# s3cmd /opt/rke/etcdbackup/snapshot.db s3://rke-etcd-backup/
|
||||
```
|
||||
|
||||
### 4. Pull the backup on a new node
|
||||
### Place the backup on a new node
|
||||
|
||||
To simulate the failure lets powerdown node2 completely:
|
||||
To simulate the failure, let's power down `node2`.
|
||||
|
||||
```
|
||||
```bash
|
||||
root@node2:~# poweroff
|
||||
```
|
||||
|
||||
Now its time to pull the backup saved on s3 on a new node:
|
||||
Before restoring etcd and running `rancher up`, we need to retrieve the backup saved on S3 to a new node, e.g. `node3`.
|
||||
|
||||
|
||||
| Name | IP | Role |
|
||||
|:-----:|:--------:|:----------------------:|
|
||||
@@ -178,14 +166,18 @@ Now its time to pull the backup saved on s3 on a new node:
|
||||
| ~~node2~~ | ~~10.0.0.2~~ | ~~[etcd]~~ |
|
||||
| node3 | 10.0.0.3 | [etcd] |
|
||||
| | | |
|
||||
```
|
||||
|
||||
```bash
|
||||
# Make a Directory
|
||||
root@node3:~# mkdir -p /opt/rke/etcdbackup
|
||||
$ Get the Backup from S3
|
||||
root@node3:~# s3cmd get s3://rke-etcd-backup/snapshot.db /opt/rke/etcdbackup/snapshot.db
|
||||
```
|
||||
|
||||
### 5. Restore etcd on the new node
|
||||
### Restore `etcd` on the new node from the backup
|
||||
|
||||
Before updating and restoring etcd, you will need to add the new node into the Kubernetes cluster with the `etcd` role. In the `cluster.yml`, comment out the old node and add in the new node. `
|
||||
|
||||
Now lets do a restore to restore and run etcd on the third node, in order to do that you have first to add the third node to the cluster configuration file:
|
||||
```
|
||||
nodes:
|
||||
- address: 10.0.0.1
|
||||
@@ -201,17 +193,22 @@ nodes:
|
||||
user: ubuntu
|
||||
role: [etcd]
|
||||
```
|
||||
and then run `rke etcd restore`:
|
||||
```
|
||||
rke etcd snapshot-restore --name snapshot.db --config cluster.yml
|
||||
|
||||
After the new node is added to the `cluster.yml`, run `rke etcd snapshot-restore` to launch `etcd` from the backup. ]
|
||||
|
||||
```bash
|
||||
$ rke etcd snapshot-restore --name snapshot.db --config cluster.yml
|
||||
```
|
||||
|
||||
The previous command will restore the etcd data dir from the snapshot and run etcd container on this node, the final step is to restore the operations on the cluster by making the k8s api to point to the new etcd, to do that we run `rke up` again on the new cluster.yml file:
|
||||
```
|
||||
rke up --config cluster.yml
|
||||
```
|
||||
You can make sure that operations have been restored by checking the nginx deployment we created earlier:
|
||||
Finally, we need to restore the operations on the cluster by making the Kubernetes API point to the new `etcd` by running `rke up` again using the new `cluster.yml`.
|
||||
|
||||
```bash
|
||||
$ rke up --config cluster.yml
|
||||
```
|
||||
|
||||
Confirm that your Kubernetes cluster is functional by checking the pods on your cluster.
|
||||
|
||||
```bash
|
||||
> kubectl get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
nginx-65899c769f-kcdpr 1/1 Running 0 17s
|
||||
|
||||
@@ -1,25 +1,34 @@
|
||||
---
|
||||
title: Managing RKE Clusters
|
||||
weight: 51
|
||||
weight: 60
|
||||
draft: true
|
||||
---
|
||||
|
||||
## Adding/Removing Nodes
|
||||
### Adding/Removing Nodes
|
||||
|
||||
RKE supports adding/removing nodes for worker and controlplane hosts, in order to add additional nodes you will only need to update the `cluster.yml` file with additional nodes and run `rke up` with the same file.
|
||||
RKE supports adding/removing [nodes]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/) for worker and controlplane hosts.
|
||||
|
||||
To remove nodes just remove them from the hosts list in the cluster configuration file `cluster.yml`, and re run `rke up` command.
|
||||
In order to add additional nodes, you update the original `cluster.yml` file with any additional nodes and specify their role in the Kubernetes cluster.
|
||||
|
||||
## Cluster Remove
|
||||
In order to remove nodes, remove the node information from the nodes list in the original `cluster.yml`.
|
||||
|
||||
RKE supports `rke remove` command, the command does the following:
|
||||
After you've made changes to add/remove nodes, run `rke up` with the updated `cluster.yml`.
|
||||
|
||||
- Connect to each host and remove the kubernetes services deployed on it.
|
||||
### Removing Kubernetes Clusters from Nodes
|
||||
|
||||
In order to remove the Kubernetes components from nodes, you use the `rke remove` command.
|
||||
|
||||
> **Note:** This command is irreversible and will destroy the Kubernetes cluster.
|
||||
|
||||
This command does the following to each node in the `cluster.yml`:
|
||||
|
||||
|
||||
- Remove the Kubernetes services deployed on it
|
||||
- Clean each host from the directories left by the services:
|
||||
```
|
||||
- /etc/kubernetes/ssl
|
||||
- /var/lib/etcd
|
||||
- /etc/cni
|
||||
- /opt/cni
|
||||
- /var/run/calico
|
||||
|
||||
Note that this command is irreversible and will destroy the kubernetes cluster entirely.
|
||||
```
|
||||
|
||||
@@ -1,26 +1,50 @@
|
||||
---
|
||||
title: Operating System Notes
|
||||
weight: 60
|
||||
weight: 55
|
||||
draft: true
|
||||
---
|
||||
|
||||
<!-- Add some information about requirements on most operating systems
|
||||
Add in notes of which OS are currently used-->
|
||||
|
||||
### OS Requirements
|
||||
|
||||
### Atomic OS
|
||||
- For Kubernetes versions 1.8, 1.9 and 1.10, Docker versions `1.11.2` up to `1.13.1` and `17.03.x` are validated
|
||||
- OpenSSH 7.0+ must be installed on each node for stream local forwarding to work
|
||||
- The SSH user used for node access must be a member of the `docker` group on the node:
|
||||
|
||||
- Container volumes may have some issues in Atomic OS due to SELinux, most of volumes are mounted in rke with option `z`, however user still need to run the following commands before running rke:
|
||||
```
|
||||
```bash
|
||||
usermod -aG docker <user_name>
|
||||
```
|
||||
|
||||
- Ports 6443, 2379, and 2380 should be opened between cluster nodes.
|
||||
- Swap should be disabled on any worker nodes
|
||||
|
||||
|
||||
## Atomic Hosts
|
||||
|
||||
Before trying to use RKE with Atomic hosts, there are a couple of updates to the OS that need to occur in order to get RKE working.
|
||||
|
||||
### Container Volumes
|
||||
|
||||
In RKE, most of the volumes are mounted with option `z`, but there are some container volumes that may have some issues in Atomic due to SELinux.
|
||||
|
||||
Before running RKE, users will need to run the following commands to make some additional directories:
|
||||
|
||||
```bash
|
||||
# mkdir /opt/cni /etc/cni
|
||||
# chcon -Rt svirt_sandbox_file_t /etc/cni
|
||||
# chcon -Rt svirt_sandbox_file_t /opt/cni
|
||||
```
|
||||
- OpenSSH 6.4 shipped by default on Atomic CentOS which doesn't support SSH tunneling and therefore breaks rke, upgrading OpenSSH to the latest version supported by Atomic host will solve this problem:
|
||||
```
|
||||
# atomic host upgrade
|
||||
```
|
||||
- Atomic host doesn't come with docker group by default, you can change ownership of docker.sock to enable specific user to run rke:
|
||||
```
|
||||
|
||||
### OpenSSH version
|
||||
|
||||
By default, Atomic hosts ship with OpenSSH 6.4, which doesn't support SSH tunneling, which is a core RKE requirement. If you upgrade to the latest version of OpenSSH supported by Atomic, it will correct the SSH issue.
|
||||
|
||||
### Creating a Docker Group
|
||||
|
||||
By default, Atomic hosts do not come with a Docker group. You can update the ownership of the Docker socket by enabling the specific user in order to launch RKE.
|
||||
|
||||
```bash
|
||||
# chown <user> /var/run/docker.sock
|
||||
```
|
||||
|
||||
@@ -1,37 +1,49 @@
|
||||
---
|
||||
title: Upgrades
|
||||
weight: 1000
|
||||
weight: 70
|
||||
draft: true
|
||||
---
|
||||
|
||||
You can upgrade your Kubernetes cluster or upgrade any of the service arguments.
|
||||
After RKE has deployed Kubernetes, you can upgrade the versions of the components in your Kubernetes cluster, [definition of the Kubernetes services]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/) or [add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/).
|
||||
|
||||
## Cluster Upgrade
|
||||
## Version Upgrades
|
||||
|
||||
RKE supports kubernetes cluster upgrade through changing the image version of services, in order to do that change the image option for each services, for example:
|
||||
RKE supports version upgrades by changing the image tags of the [system-images]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/).
|
||||
|
||||
For example, to change the deployed Kubernetes version, you update the `rancher/hyperkube` tag from `v1.9.7` to `v1.10.3` in the `cluster.yml` that was originally used to deploy your Kubernetes cluster.
|
||||
|
||||
Original YAML
|
||||
|
||||
```yaml
|
||||
image: rancher/hyperkube:v1.9.7
|
||||
system-images:
|
||||
kubernetes: rancher/hyperkube:v1.9.7
|
||||
```
|
||||
|
||||
TO
|
||||
Updated YAML
|
||||
|
||||
```yaml
|
||||
image: rancher/hyperkube:v1.10.1
|
||||
system-images:
|
||||
kubernetes: rancherhyperkube:v1.10.3
|
||||
```
|
||||
|
||||
And then run:
|
||||
After updating your `cluster.yml` with the required changes, all you need to do is run `rke up` to upgrade Kubernetes.
|
||||
|
||||
```bash
|
||||
rke up --config cluster.yml
|
||||
$ rke up --config cluster.yml
|
||||
```
|
||||
|
||||
RKE will first look for the local `kube_config_cluster.yml` and then tries to upgrade each service to the latest image.
|
||||
First, RKE will use the local `kube_config_cluster.yml` to confirm the versions of the existing components in the Kubernetes cluster before upgrading to the latest image.
|
||||
|
||||
> Note that rollback isn't supported in RKE and may lead to unxpected results
|
||||
> **Note:** RKE does not support rollback to previous versions.
|
||||
|
||||
## Service Upgrade
|
||||
## Service Upgrades
|
||||
|
||||
Service can also be upgraded by changing any of the services arguments or extra args and run `rke up` again with the updated configuration file.
|
||||
[Services]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/) can be upgraded by changing any of the services arguments or `extra_args` and running `rke up` again with the updated configuration file.
|
||||
|
||||
> Please note that changing the following arguments: `service_cluster_ip_range` or `cluster_cidr` will result in a broken cluster, because currently the network pods will not be automatically upgraded.
|
||||
> **Note:** The following arguments, `service_cluster_ip_range` or `cluster_cidr`, cannot be changed as any changes to these arguments will result in a broken cluster. Currently, network pods will not be automatically upgraded.
|
||||
|
||||
## Add-Ons Upgrades
|
||||
|
||||
As of v0.1.8, upgrades to add-ons are supported.
|
||||
|
||||
[Add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/) can also be upgraded by changing any of the add-ons and running `rke up` again with the updated configuration file.
|
||||
|
||||
Reference in New Issue
Block a user