mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-08-28 13:02:17 +00:00
transferring RKE readme content to docs
This commit is contained in:
Denise Schannon
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: Config Options
|
||||
weight: 3000
|
||||
draft: true
|
||||
---
|
||||
|
||||
When setting up your cluster.yml for RKE, there are a lot of different options that can be configured.
|
||||
|
||||
|
||||
## Using RKE to generate a cluster.ml
|
||||
|
||||
RKE supports command `rke config` which generates a cluster config template for the user, to start using this command just write:
|
||||
|
||||
```bash
|
||||
rke config --name mycluster.yml
|
||||
```
|
||||
|
||||
RKE will ask some questions around the cluster file like number of the hosts, ips, ssh users, etc, `--empty` option will generate an empty cluster.yml file, also if you just want to print on the screen and not save it in a file you can use `--print`.
|
||||
|
||||
## Cluster Yaml Links
|
||||
|
||||
## Naming your Cluster
|
||||
|
||||
```
|
||||
# If set, this is the cluster name that will be used in the kube config file
|
||||
# Default value is "local"
|
||||
cluster_name: mycluster
|
||||
|
||||
```
|
||||
|
||||
## Docker Version check
|
||||
|
||||
```
|
||||
# If set to true, rke won't fail when unsupported Docker version is found
|
||||
ignore_docker_version: false
|
||||
```
|
||||
|
||||
## Kubernetes authorization (RBAC)
|
||||
|
||||
```
|
||||
# Kubernetes authorization mode
|
||||
# Use `mode: rbac` to enable RBAC
|
||||
# Use `mode: none` to disable authorization
|
||||
authorization:
|
||||
mode: rbac
|
||||
```
|
||||
|
||||
## SSH Key path
|
||||
|
||||
```
|
||||
ssh_key_path: ~/.ssh/test
|
||||
```
|
||||
|
||||
|
||||
<!--add in sections for each option with high level description and link-->
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: Add-Ons
|
||||
weight: 3000
|
||||
draft: true
|
||||
---
|
||||
|
||||
|
||||
RKE supports pluggable addons. Addons are used to deploy several cluster components including:
|
||||
- Network plugin
|
||||
- KubeDNS
|
||||
- Ingress controller
|
||||
|
||||
In addition, a user can specify the addon yaml in the cluster.yml file, and when running
|
||||
|
||||
```yaml
|
||||
rke up --config cluster.yml
|
||||
```
|
||||
|
||||
RKE will deploy the addons yaml after the cluster starts, RKE first uploads this yaml file as a configmap in kubernetes cluster and then run a kubernetes job that mounts this config map and deploy the addons.
|
||||
|
||||
> Note that RKE doesn't support yet removal or update of the addons, so once they are deployed the first time you can't change them using rke
|
||||
|
||||
To start using addons use `addons:` option in the `cluster.yml` file for example:
|
||||
|
||||
```yaml
|
||||
addons: |-
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: my-nginx
|
||||
namespace: default
|
||||
spec:
|
||||
containers:
|
||||
- name: my-nginx
|
||||
image: nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
```
|
||||
|
||||
Note that we are using `|-` because the addons option is a multi line string option, where you can specify multiple yaml files and separate them with `---`
|
||||
|
||||
For `addons_include:` you may pass either http/https urls or file paths, for example:
|
||||
```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 addons. In some cases, addons deployment takes longer than expected. Starting with version `0.1.7-rc1`, RKE provides an option to controle the job check timeout in seconds:
|
||||
```yaml
|
||||
addon_job_timeout: 30
|
||||
```
|
||||
|
||||
#### Critical and noncritical addons
|
||||
As of version `0.1.7-rc1`, addons are split into two categories: critical and noncritical.
|
||||
|
||||
Critical addons will cause RKE to error out if they fail to deploy for any reason. While noncritical addons will just log a warning and continue with the deployment. Currently only the network plugin is considered critical.
|
||||
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: Authentication
|
||||
weight: 3000
|
||||
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.
|
||||
|
||||
```yaml
|
||||
authentication:
|
||||
strategy: x509
|
||||
sans:
|
||||
- "10.18.160.10"
|
||||
- "my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com"
|
||||
```
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: Bastion/Jump Host Configuration
|
||||
weight: 3000
|
||||
draft: true
|
||||
---
|
||||
|
||||
```
|
||||
|
||||
# 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-----
|
||||
```
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
title: Cloud Providers
|
||||
weight: 3000
|
||||
draft: true
|
||||
---
|
||||
|
||||
Starting from v0.1.3 rke supports cloud providers.
|
||||
|
||||
### AWS Cloud Provider
|
||||
|
||||
To enable AWS cloud provider, you can set the following in the cluster configuration file:
|
||||
```
|
||||
cloud_provider:
|
||||
name: aws
|
||||
```
|
||||
|
||||
AWS cloud provider has to be enabled on ec2 instances with the right IAM role.
|
||||
|
||||
### Azure Cloud provider
|
||||
|
||||
Azure cloud provider can be enabled by passing `azure` as the cloud provider name and set of options to the configuration file:
|
||||
```
|
||||
cloud_provider:
|
||||
name: azure
|
||||
cloud_config:
|
||||
aadClientId: xxxxxxxxxxxx
|
||||
aadClientSecret: xxxxxxxxxxx
|
||||
location: westus
|
||||
resourceGroup: rke-rg
|
||||
subnetName: rke-subnet
|
||||
subscriptionId: xxxxxxxxxxx
|
||||
vnetName: rke-vnet
|
||||
tenantId: xxxxxxxxxx
|
||||
securityGroupName: rke-nsg
|
||||
```
|
||||
|
||||
You also have to make sure that the Azure node name must match the kubernetes node name, you can do that by changing the value of hostname_override in the config file:
|
||||
```
|
||||
nodes:
|
||||
- address: x.x.x.x
|
||||
hostname_override: azure-rke1
|
||||
user: ubuntu
|
||||
role:
|
||||
- controlplane
|
||||
- etcd
|
||||
- worker
|
||||
```
|
||||
@@ -0,0 +1,81 @@
|
||||
|
||||
title: Default Services and images
|
||||
weight: 3000
|
||||
draft: true
|
||||
---
|
||||
|
||||
## Default services
|
||||
|
||||
<!--Talk about the default services launched and options around them-->
|
||||
|
||||
```
|
||||
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:
|
||||
|
||||
```
|
||||
|
||||
## System Images
|
||||
|
||||
Prior to version `0.1.6`, RKE used the following list of images for deployment and cluster configuration:
|
||||
```
|
||||
system_images:
|
||||
etcd: rancher/etcd:v3.0.17
|
||||
kubernetes: rancher/k8s:v1.8.9-rancher1-1
|
||||
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
|
||||
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
|
||||
```
|
||||
As of version `0.1.6`, we consolidated several of those images into a single image to simplify and speed the deployment process.
|
||||
|
||||
The following images are no longer required, and can be replaced by `rancher/rke-tools:v0.1.4`:
|
||||
- alpine:latest
|
||||
- rancher/rke-nginx-proxy:v0.1.1
|
||||
- rancher/rke-cert-deployer:v0.1.1
|
||||
- rancher/rke-service-sidekick:v0.1.0
|
||||
@@ -0,0 +1,230 @@
|
||||
---
|
||||
title: Example Cluster.ymls
|
||||
weight: 3000
|
||||
draft: true
|
||||
---
|
||||
|
||||
|
||||
### Minimal `cluster.yml` example
|
||||
|
||||
```
|
||||
# default k8s version: v1.8.10-rancher1-1
|
||||
# default network plugin: canal
|
||||
nodes:
|
||||
- address: 1.2.3.4
|
||||
user: ubuntu
|
||||
role: [controlplane,worker,etcd]
|
||||
```
|
||||
|
||||
### 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-----
|
||||
|
||||
-----END RSA PRIVATE KEY-----
|
||||
- address: example.com
|
||||
user: ubuntu
|
||||
role:
|
||||
- role
|
||||
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:
|
||||
|
||||
# supported plugins are:
|
||||
# flannel
|
||||
# calico
|
||||
# canal
|
||||
# weave
|
||||
#
|
||||
# If you are using calico on AWS or GCE, use the network plugin config option:
|
||||
# 'calico_cloud_provider: aws'
|
||||
# or
|
||||
# 'calico_cloud_provider: gce'
|
||||
# network:
|
||||
# plugin: calico
|
||||
# options:
|
||||
# calico_cloud_provider: aws
|
||||
#
|
||||
# To specify flannel interface, you can use the 'flannel_iface' option:
|
||||
# network:
|
||||
# plugin: flannel
|
||||
# options:
|
||||
# flannel_iface: eth1
|
||||
# To specify flannel interface for canal plugin, you can use the 'canal_iface' option:
|
||||
# network:
|
||||
# plugin: canal
|
||||
# options:
|
||||
# canal_iface: eth1
|
||||
|
||||
|
||||
network:
|
||||
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"
|
||||
|
||||
# all addon manifests MUST specify a namespace
|
||||
addons: |-
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: my-nginx
|
||||
namespace: default
|
||||
spec:
|
||||
containers:
|
||||
- name: my-nginx
|
||||
image: nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
|
||||
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
|
||||
- /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
|
||||
|
||||
|
||||
ssh_key_path: ~/.ssh/test
|
||||
|
||||
# Kubernetes authorization mode
|
||||
# Use `mode: rbac` to enable RBAC
|
||||
# Use `mode: none` to disable authorization
|
||||
authorization:
|
||||
mode: rbac
|
||||
|
||||
# If set to true, rke won't fail when unsupported Docker version is found
|
||||
ignore_docker_version: false
|
||||
# The kubernetes version used. For now, this should match the version defined in rancher/types defaults map: https://github.com/rancher/types/blob/master/apis/management.cattle.io/v3/k8s_defaults.go#L14
|
||||
kubernetes_version: v1.10.1-rancher1
|
||||
|
||||
# addons are deployed using kubernetes jobs. RKE will give up on trying to get the job status after this timeout in seconds..
|
||||
addon_job_timeout: 30
|
||||
# If set, this is the cluster name that will be used in the kube config file
|
||||
# Default value is "local"
|
||||
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
|
||||
|
||||
# Currently only nginx ingress provider is supported.
|
||||
# To disable ingress controller, set `provider: none`
|
||||
# To enable ingress on specific nodes, use the node_selector, eg:
|
||||
# nodes:
|
||||
# - address: example.com
|
||||
# user: ubuntu
|
||||
# role:
|
||||
# - role
|
||||
# hostname_override: node3
|
||||
# internal_address: 192.168.1.6
|
||||
# labels:
|
||||
# app: ingress
|
||||
#
|
||||
# ingress:
|
||||
# provider: nginx
|
||||
# node_selector:
|
||||
# app: ingress
|
||||
# extra_args:
|
||||
# enable-ssl-passthrough: ""
|
||||
|
||||
ingress:
|
||||
provider: nginx
|
||||
|
||||
cloud_provider:
|
||||
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-----
|
||||
```
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: External etcd
|
||||
weight: 3000
|
||||
draft: true
|
||||
---
|
||||
|
||||
|
||||
RKE supports using external etcd instead of deploying etcd servers, to enable external etcd the following parameters should be populated:
|
||||
|
||||
```
|
||||
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-----
|
||||
```
|
||||
|
||||
Note that RKE only supports connecting to TLS enabled etcd setup, user can enable multiple endpoints in the `external_urls` field. RKE will not accept having external urls and nodes with `etcd` role at the same time, user should only specify either etcd role for servers or external etcd but not both.
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: Extra Args and Binds
|
||||
weight: 3000
|
||||
draft: true
|
||||
---
|
||||
|
||||
|
||||
RKE supports additional service arguments.
|
||||
|
||||
```yaml
|
||||
services:
|
||||
# ...
|
||||
kube-controller:
|
||||
extra_args:
|
||||
cluster-name: "mycluster"
|
||||
```
|
||||
This will add/append `--cluster-name=mycluster` to the container list of arguments.
|
||||
|
||||
As of `v0.1.3-rc2` using `extra_args` will add new arguments and **override** existing defaults. For example, if you need to modify the default admission controllers list, you need to change the default list and add apply it using `extra_args`.
|
||||
|
||||
RKE also supports additional volume binds:
|
||||
|
||||
```yaml
|
||||
services:
|
||||
# ...
|
||||
kubelet:
|
||||
extra_binds:
|
||||
- "/host/dev:/dev"
|
||||
- "/usr/libexec/kubernetes/kubelet-plugins:/usr/libexec/kubernetes/kubelet-plugins:z"
|
||||
```
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
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.
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: Kubernetes Versions
|
||||
weight: 3000
|
||||
draft: true
|
||||
---
|
||||
|
||||
<!--where to find default for rke
|
||||
how is default version determined
|
||||
how to change it using configuration Options-->
|
||||
|
||||
The current default kubernetes version used by RKE is `v1.10.1-rancher1`.
|
||||
|
||||
There are two ways to select a kubernetes version:
|
||||
|
||||
- Using the kubernetes image defined in [System Images](#rke-system-images)
|
||||
- Using the configuration option `kubernetes_version`
|
||||
|
||||
In case both are defined, the system images configuration will take precedence over `kubernetes_version`. Since the `kubernetes_version` options was added mainly to be used by Rancher v2.0, it has a limited number of supported tags that can be found [here](https://github.com/rancher/types/blob/master/apis/management.cattle.io/v3/k8s_defaults.go#L14).
|
||||
|
||||
If a version is defined in `kubernetes_version` and is not found in this map, the default is used.
|
||||
@@ -0,0 +1,48 @@
|
||||
---
|
||||
title: Network Plug-ins
|
||||
weight: 3000
|
||||
draft: true
|
||||
---
|
||||
|
||||
RKE supports the following network plugins that are deployed as addons:
|
||||
|
||||
- Flannel
|
||||
- Calico
|
||||
- Canal
|
||||
- Weave
|
||||
|
||||
To use specific network plugin configure `cluster.yml` to include:
|
||||
|
||||
```yaml
|
||||
network:
|
||||
plugin: flannel
|
||||
```
|
||||
|
||||
### Network Options
|
||||
|
||||
There are extra options that can be specified for each network plugin:
|
||||
|
||||
#### Flannel
|
||||
|
||||
- **flannel_image**: Flannel daemon Docker image
|
||||
- **flannel_cni_image**: Flannel CNI binary installer Docker image
|
||||
- **flannel_iface**: Interface to use for inter-host communication
|
||||
|
||||
#### Calico
|
||||
|
||||
- **calico_node_image**: Calico Daemon Docker image
|
||||
- **calico_cni_image**: Calico CNI binary installer Docker image
|
||||
- **calico_controllers_image**: Calico Controller Docker image
|
||||
- **calicoctl_image**: Calicoctl tool Docker image
|
||||
- **calico_cloud_provider**: Cloud provider where Calico will operate, currently supported values are: `aws`, `gce`
|
||||
|
||||
#### Canal
|
||||
|
||||
- **canal_node_image**: Canal Node Docker image
|
||||
- **canal_cni_image**: Canal CNI binary installer Docker image
|
||||
- **canal_flannel_image**: Canal Flannel Docker image
|
||||
|
||||
#### Weave
|
||||
|
||||
- **weave_node_image**: Weave Node Docker image
|
||||
- **weave_cni_image**: Weave CNI binary installer Docker image
|
||||
@@ -0,0 +1,7 @@
|
||||
---
|
||||
title: Nodes
|
||||
weight: 3000
|
||||
draft: true
|
||||
---
|
||||
|
||||
<!-- explain how to set up nodes in yaml with examples and what is required-->
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: Private Registries
|
||||
weight: 3000
|
||||
draft: true
|
||||
---
|
||||
|
||||
```
|
||||
# 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
|
||||
```
|
||||
@@ -4,5 +4,191 @@ weight: 50
|
||||
draft: true
|
||||
---
|
||||
|
||||
<!-- Mohamed: Refer to the blog to see how this could be better written-->
|
||||
|
||||
take quickstart guide and expand more
|
||||
## 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.
|
||||
|
||||
### Download the rke binary
|
||||
|
||||
Browse to the [latest release](https://github.com/rancher/rke/releases/latest) and download `rke_darwin-amd64` for MacOS and `rke_linux-amd64` if you use a Linux machine.
|
||||
|
||||
When you have downloaded the binary, you can make it executable by running `chmod +x rke_darwin-amd64` or `chmod +x rke_linux-amd64`.
|
||||
|
||||
After, you can test if it's executable by running `./rke_darwin-amd64 -version` or `./rke_linux-amd64 -version`.
|
||||
|
||||
```bash
|
||||
$ chmod +x rke_darwin-amd64
|
||||
$ ./rke_darwin-amd64 -version
|
||||
rke version v0.1.5
|
||||
```
|
||||
|
||||
### Preparing Linux machines to be used in the cluster
|
||||
|
||||
The Kubernetes cluster components are launched using Docker on a Linux machine. You can use any Linux you want, as long as you can install Docker on it. The most commonly used OS is the current Ubuntu LTS release, 16.04. Kubernetes runs integration tests on the following Docker versions: `1.11.2` to `1.13.1`, and `17.03.x`. We follow these tested Docker versions by marking them as supported. To make installing Docker easy, we've created `install-docker` scripts. Pick the version you want to install and run the command in the `Install Script` column to install it.
|
||||
|
||||
Version | Supported? | Install Script |
|
||||
----------|------------|------------------
|
||||
`1.11.2` | Yes | <code>curl https://releases.rancher.com/install-docker/1.11.sh | sh</code> |
|
||||
`1.12.6` | Yes | <code>curl https://releases.rancher.com/install-docker/1.12.sh | sh</code> |
|
||||
`1.13.1` | Yes | <code>curl https://releases.rancher.com/install-docker/1.13.sh | sh</code> |
|
||||
`17.03.2` | Yes | <code>curl https://releases.rancher.com/install-docker/17.03.sh | sh</code> |
|
||||
|
||||
You can test if Docker is installed correctly by running `docker version`, it should show the client and server version.
|
||||
|
||||
```bash
|
||||
$ docker version
|
||||
Client:
|
||||
Version: 17.03.2-ce
|
||||
API version: 1.27
|
||||
Go version: go1.7.5
|
||||
Git commit: f5ec1e2
|
||||
Built: Tue Jun 27 03:35:14 2017
|
||||
OS/Arch: linux/amd64
|
||||
|
||||
Server:
|
||||
Version: 17.03.2-ce
|
||||
API version: 1.27 (minimum version 1.12)
|
||||
Go version: go1.7.5
|
||||
Git commit: f5ec1e2
|
||||
Built: Tue Jun 27 03:35:14 2017
|
||||
OS/Arch: linux/amd64
|
||||
Experimental: false
|
||||
```
|
||||
|
||||
To connect to the Kubernetes cluster, port `TCP/6443` needs to be opened to the machine. If you are using an external firewall, make sure you have this opened between the machine you are using to run `rke` and the machine you are going to use in the cluster. If you are using `iptables` or `firewalld`, you can use the following commands:
|
||||
|
||||
Example opening port TCP/6443 using `iptables`
|
||||
|
||||
```bash
|
||||
# Open TCP/6443 for all
|
||||
iptables -A INPUT -p tcp --dport 6443 -j ACCEPT
|
||||
|
||||
# Open TCP/6443 for one specific IP
|
||||
iptables -A INPUT -p tcp -s your_ip_here --dport 6443 -j ACCEPT
|
||||
```
|
||||
|
||||
Example opening port TCP/6443 using `firewalld`
|
||||
|
||||
```bash
|
||||
# Open TCP/6443 for all
|
||||
firewall-cmd --zone=public --add-port=6443/tcp --permanent
|
||||
firewall-cmd --reload
|
||||
|
||||
# Open TCP/6443 for one specific IP
|
||||
firewall-cmd --permanent --zone=public --add-rich-rule='
|
||||
rule family="ipv4"
|
||||
source address="your_ip_here/32"
|
||||
port protocol="tcp" port="6443" accept'
|
||||
firewall-cmd --reload
|
||||
```
|
||||
|
||||
### Creating `cluster.yml` and Kubernetes cluster
|
||||
|
||||
For this quick start, we will be configuring one machine. There are 3 roles you can define on a machine:
|
||||
|
||||
Role | Description |
|
||||
----------|----------|
|
||||
etcd | Keeps the state of your cluster and is the most important component in your cluster, single source of truth of your cluster. |
|
||||
controlplane | Responsible of running all the master components of your cluster, like the `kube-apiserver`, `controller-manager` and the `scheduler`. |
|
||||
worker | Workers will run the actual workloads. |
|
||||
|
||||
<br>
|
||||
|
||||
To create the `cluster.yml`, you can run `./rke_darwin-amd64 config` or `./rke_linux-amd64 config`. It will query you for all the information needed to build your cluster.
|
||||
|
||||
```bash
|
||||
./rke_darwin-amd64 config
|
||||
# SSH private key location to use
|
||||
[+] Cluster Level SSH Private Key Path [~/.ssh/id_rsa]: ~/.ssh/your_rsa_key
|
||||
# For this example we'll be using one host
|
||||
[+] Number of Hosts [1]:
|
||||
# Address where the host is reachable over SSH
|
||||
[+] SSH Address of host (1) [none]: 10.0.0.1
|
||||
# SSH Port to use
|
||||
[+] SSH Port of host (1) [22]:
|
||||
# You can configure SSH keys per configured host, not needed in this example
|
||||
[+] SSH Private Key Path of host (10.0.0.1) [none]:
|
||||
[-] You have entered empty SSH key path, trying fetch from SSH key parameter
|
||||
[+] SSH Private Key of host (10.0.0.1) [none]:
|
||||
[-] You have entered empty SSH key, defaulting to cluster level SSH key: ~/.ssh/your_rsa_key
|
||||
# Username to use for the SSH connection
|
||||
[+] SSH User of host (10.0.0.1) [ubuntu]: root
|
||||
# We'll be configuring all three roles onto this single host
|
||||
[+] Is host (10.0.0.1) a control host (y/n)? [y]: y
|
||||
[+] Is host (10.0.0.1) a worker host (y/n)? [n]: y
|
||||
[+] Is host (10.0.0.1) an Etcd host (y/n)? [n]: y
|
||||
# If you want to override the hostname for this host, you can specify that here
|
||||
[+] Override Hostname of host (10.0.0.1) [none]:
|
||||
# If the host has multiple network connections, you can specify a private network connection here
|
||||
[+] Internal IP of host (10.0.0.1) [none]:
|
||||
# The location of the Docker socket
|
||||
[+] Docker socket path on host (10.0.0.1) [/var/run/docker.sock]:
|
||||
# Network plugin to use for your cluster
|
||||
[+] Network Plugin Type (flannel, calico, weave, canal) [flannel]:
|
||||
# We will be using certificates as authentication strategy
|
||||
[+] Authentication Strategy [x509]:
|
||||
# RBAC will be turned on
|
||||
[+] Authorization Mode (rbac, none) [rbac]:
|
||||
# Images to use for your cluster
|
||||
[+] Etcd Docker Image [rancher/coreos-etcd:v3.0.17]:
|
||||
[+] Kubernetes Docker image [rancher/k8s:v1.8.9-rancher1-1]:
|
||||
# Internal cluster domain to be used
|
||||
[+] Cluster domain [cluster.local]:
|
||||
# IP ranges to be used by the clusters
|
||||
[+] Service Cluster IP Range [10.233.0.0/18]:
|
||||
# If we want to use PodSecurityPolicy
|
||||
[+] Enable PodSecurityPolicy [n]:
|
||||
[+] Cluster Network CIDR [10.233.64.0/18]:
|
||||
[+] Cluster DNS Service IP [10.233.0.3]:
|
||||
# The container image to be used by Kubernetes pods
|
||||
[+] Infra Container image [rancher/pause-amd64:3.0]:
|
||||
```
|
||||
|
||||
There should be a `cluster.yml` created in the directory where you launched the rke command. If you have to correct anything, you can do that directly in the `cluster.yml` file.
|
||||
|
||||
If you are satisfied with the configuration, you can start building your cluster by using `./rke_darwin-amd64 up` or `./rke_linux-amd64 up`.
|
||||
|
||||
### Using RKE
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
$ ./rke_darwin-amd64 up
|
||||
INFO[0000] Building Kubernetes cluster
|
||||
INFO[0000] [dialer] Setup tunnel for host [10.0.0.1]
|
||||
INFO[0000] [network] Deploying port listener containers
|
||||
INFO[0000] [network] Pulling image [alpine:latest] on host [10.0.0.1]
|
||||
...
|
||||
INFO[0101] Finished building Kubernetes cluster successfully
|
||||
```
|
||||
|
||||
The last line should read `Finished building Kubernetes cluster successfully` to indicate that your cluster is ready to use. A kubeconfig file has been written to `kube_config_cluster.yml` to be used to interact with your cluster.
|
||||
|
||||
### Interacting with your cluster
|
||||
|
||||
The way you interact with your cluster is by the use of a binary called `kubectl`. Before we can issue commands to our cluster, we need to download the `kubectl` binary. Please follow [the intructions](https://kubernetes.io/docs/tasks/tools/install-kubectl/) on the Kubernetes documentation page to install `kubectl`. You can verify the installation of `kubectl` and the connection to the cluster using `kubectl --kubeconfig kube_config_cluster.yml version`.
|
||||
|
||||
```bash
|
||||
$ kubectl --kubeconfig kube_config_cluster.yml version
|
||||
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.0", GitCommit:"fc32d2f3698e36b93322a3465f63a14e9f0eaead", GitTreeState:"clean", BuildDate:"2018-03-27T00:13:02Z", GoVersion:"go1.9.4", Compiler:"gc", Platform:"darwin/amd64"}
|
||||
Server Version: version.Info{Major:"1", Minor:"8+", GitVersion:"v1.8.9-rancher1", GitCommit:"68595e18f25e24125244e9966b1e5468a98c1cd4", GitTreeState:"clean", BuildDate:"2018-03-13T04:37:53Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
|
||||
```
|
||||
|
||||
The client and server version are reported, indicating that you have a local `kubectl` client and are able to request the server version from the newly built cluster. Now you can issue any command to your cluster, like requesting the nodes that are in the cluster using `kubectl --kubeconfig kube_config_cluster.yml get nodes`
|
||||
|
||||
```bash
|
||||
$ kubectl --kubeconfig kube_config_cluster.yml get nodes
|
||||
NAME STATUS ROLES AGE VERSION
|
||||
10.0.0.1 Ready controlplane,etcd,worker 35m v1.8.9-rancher1
|
||||
```
|
||||
|
||||
@@ -1,5 +1,220 @@
|
||||
---
|
||||
title: Etcd Snapshots
|
||||
title: Backups and Disaster Recovery
|
||||
weight: 3000
|
||||
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.
|
||||
|
||||
### 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
|
||||
|
||||
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
|
||||
INFO[0000] [dialer] Setup tunnel for host [x.x.x.x]
|
||||
INFO[0001] [dialer] Setup tunnel for host [y.y.y.y]
|
||||
INFO[0002] [dialer] Setup tunnel for host [z.z.z.z]
|
||||
INFO[0003] [etcd] Saving snapshot [rke_etcd_snapshot_2018-05-17T23:32:08+02:00] on host [x.x.x.x]
|
||||
INFO[0004] [etcd] Successfully started [etcd-snapshot-once] container on host [x.x.x.x]
|
||||
INFO[0004] [etcd] Saving snapshot [rke_etcd_snapshot_2018-05-17T23:32:08+02:00] on host [y.y.y.y]
|
||||
INFO[0005] [etcd] Successfully started [etcd-snapshot-once] container on host [y.y.y.y]
|
||||
INFO[0005] [etcd] Saving snapshot [rke_etcd_snapshot_2018-05-17T23:32:08+02:00] on host [z.z.z.z]
|
||||
INFO[0006] [etcd] Successfully started [etcd-snapshot-once] container on host [z.z.z.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.
|
||||
|
||||
### 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 enable `etcd-snapshot` in RKE CLI, configure the following three variables:
|
||||
|
||||
```
|
||||
services:
|
||||
etcd:
|
||||
snapshot: true
|
||||
creation: 5m0s
|
||||
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.
|
||||
|
||||
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
|
||||
|
||||
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
|
||||
time="2018-05-04T18:41:16Z" level=info msg="Created backup" name="2018-05-04T18:41:16Z_etcd" runtime=92.880112ms
|
||||
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.
|
||||
|
||||
|
||||
### Etcd Disaster recovery
|
||||
|
||||
`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.
|
||||
|
||||
>**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.
|
||||
|
||||
```
|
||||
./rke etcd snapshot-restore --name snapshot --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]
|
||||
INFO[0005] [dialer] Setup tunnel for host [z.z.z.z]
|
||||
INFO[0007] [hosts] Cleaning up host [x.x.x.x]
|
||||
INFO[0007] [hosts] Running cleaner container on host [x.x.x.x]
|
||||
INFO[0008] [kube-cleaner] Successfully started [kube-cleaner] container on host [x.x.x.x]
|
||||
INFO[0008] [hosts] Removing cleaner container on host [x.x.x.x]
|
||||
INFO[0008] [hosts] Successfully cleaned up host [x.x.x.x]
|
||||
INFO[0009] [hosts] Cleaning up host [y.y.y.y]
|
||||
INFO[0009] [hosts] Running cleaner container on host [y.y.y.y]
|
||||
INFO[0010] [kube-cleaner] Successfully started [kube-cleaner] container on host [y.y.y.y]
|
||||
INFO[0010] [hosts] Removing cleaner container on host [y.y.y.y]
|
||||
INFO[0010] [hosts] Successfully cleaned up host [y.y.y.y]
|
||||
INFO[0011] [hosts] Cleaning up host [z.z.z.z]
|
||||
INFO[0011] [hosts] Running cleaner container on host [z.z.z.z]
|
||||
INFO[0012] [kube-cleaner] Successfully started [kube-cleaner] container on host [z.z.z.z]
|
||||
INFO[0012] [hosts] Removing cleaner container on host [z.z.z.z]
|
||||
INFO[0012] [hosts] Successfully cleaned up host [z.z.z.z]
|
||||
INFO[0012] [etcd] Restoring [snapshot] snapshot on etcd host [x.x.x.x]
|
||||
INFO[0013] [etcd] Successfully started [etcd-restore] container on host [x.x.x.x]
|
||||
INFO[0014] [etcd] Restoring [snapshot] snapshot on etcd host [y.y.y.y]
|
||||
INFO[0015] [etcd] Successfully started [etcd-restore] container on host [y.y.y.y]
|
||||
INFO[0015] [etcd] Restoring [snapshot] snapshot on etcd host [z.z.z.z]
|
||||
INFO[0016] [etcd] Successfully started [etcd-restore] container on host [z.z.z.z]
|
||||
INFO[0017] [etcd] Building up etcd plane..
|
||||
INFO[0018] [etcd] Successfully started [etcd] container on host [x.x.x.x]
|
||||
INFO[0020] [etcd] Successfully started [rke-log-linker] container on host [x.x.x.x]
|
||||
INFO[0021] [remove/rke-log-linker] Successfully removed container on host [x.x.x.x]
|
||||
INFO[0022] [etcd] Successfully started [etcd] container on host [y.y.y.y]
|
||||
INFO[0023] [etcd] Successfully started [rke-log-linker] container on host [y.y.y.y]
|
||||
INFO[0025] [remove/rke-log-linker] Successfully removed container on host [y.y.y.y]
|
||||
INFO[0025] [etcd] Successfully started [etcd] container on host [z.z.z.z]
|
||||
INFO[0027] [etcd] Successfully started [rke-log-linker] container on host [z.z.z.z]
|
||||
INFO[0027] [remove/rke-log-linker] Successfully removed container on host [z.z.z.z]
|
||||
INFO[0027] [etcd] Successfully started etcd plane..
|
||||
INFO[0027] Finished restoring on all etcd hosts
|
||||
```
|
||||
|
||||
## Example
|
||||
|
||||
In this example we will assume that you started RKE on two 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:
|
||||
|
||||
```
|
||||
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]
|
||||
```
|
||||
|
||||
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
|
||||
```
|
||||
|
||||
|
||||
|
||||
### 3. Store 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:
|
||||
|
||||
```
|
||||
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
|
||||
|
||||
To simulate the failure lets powerdown node2 completely:
|
||||
|
||||
```
|
||||
root@node2:~# poweroff
|
||||
```
|
||||
|
||||
Now its time to pull the backup saved on s3 on a new node:
|
||||
|
||||
| Name | IP | Role |
|
||||
|:-----:|:--------:|:----------------------:|
|
||||
| node1 | 10.0.0.1 | [controlplane, worker] |
|
||||
| ~~node2~~ | ~~10.0.0.2~~ | ~~[etcd]~~ |
|
||||
| node3 | 10.0.0.3 | [etcd] |
|
||||
| | | |
|
||||
```
|
||||
root@node3:~# mkdir -p /opt/rke/etcdbackup
|
||||
root@node3:~# s3cmd get s3://rke-etcd-backup/snapshot.db /opt/rke/etcdbackup/snapshot.db
|
||||
```
|
||||
|
||||
### 5. Restore etcd on 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
|
||||
hostname_override: node1
|
||||
user: ubuntu
|
||||
role: [controlplane,worker]
|
||||
# - address: 10.0.0.2
|
||||
# hostname_override: node2
|
||||
# user: ubuntu
|
||||
# role: [etcd]
|
||||
- address: 10.0.0.3
|
||||
hostname_override: node3
|
||||
user: ubuntu
|
||||
role: [etcd]
|
||||
```
|
||||
and then run `rke etcd restore`:
|
||||
```
|
||||
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:
|
||||
```
|
||||
> kubectl get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
nginx-65899c769f-kcdpr 1/1 Running 0 17s
|
||||
nginx-65899c769f-pc45c 1/1 Running 0 17s
|
||||
nginx-65899c769f-qkhml 1/1 Running 0 17s
|
||||
```
|
||||
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: Managing RKE Clusters
|
||||
weight: 51
|
||||
draft: true
|
||||
---
|
||||
|
||||
## 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.
|
||||
|
||||
To remove nodes just remove them from the hosts list in the cluster configuration file `cluster.yml`, and re run `rke up` command.
|
||||
|
||||
## Cluster Remove
|
||||
|
||||
RKE supports `rke remove` command, the command does the following:
|
||||
|
||||
- Connect to each host and 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.
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: Operating System Notes
|
||||
weight: 60
|
||||
draft: true
|
||||
---
|
||||
|
||||
<!-- Add some information about requirements on most operating systems
|
||||
Add in notes of which OS are currently used-->
|
||||
|
||||
|
||||
### Atomic OS
|
||||
|
||||
- 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:
|
||||
```
|
||||
# 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:
|
||||
```
|
||||
# chown <user> /var/run/docker.sock
|
||||
```
|
||||
@@ -3,3 +3,35 @@ title: Upgrades
|
||||
weight: 1000
|
||||
draft: true
|
||||
---
|
||||
|
||||
You can upgrade your Kubernetes cluster or upgrade any of the service arguments.
|
||||
|
||||
## Cluster Upgrade
|
||||
|
||||
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:
|
||||
|
||||
```yaml
|
||||
image: rancher/hyperkube:v1.9.7
|
||||
```
|
||||
|
||||
TO
|
||||
|
||||
```yaml
|
||||
image: rancher/hyperkube:v1.10.1
|
||||
```
|
||||
|
||||
And then run:
|
||||
|
||||
```bash
|
||||
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.
|
||||
|
||||
> Note that rollback isn't supported in RKE and may lead to unxpected results
|
||||
|
||||
## Service Upgrade
|
||||
|
||||
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.
|
||||
|
||||
> 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.
|
||||
|
||||
@@ -1,13 +0,0 @@
|
||||
---
|
||||
title: Options
|
||||
weight: 3000
|
||||
draft: true
|
||||
---
|
||||
|
||||
## Kubernetes Versions
|
||||
|
||||
where to find default for rke
|
||||
how is default version determined
|
||||
how to change it using configuration Options
|
||||
|
||||
## System Images
|
||||
@@ -1,5 +0,0 @@
|
||||
---
|
||||
title: Add-Ons
|
||||
weight: 3000
|
||||
draft: true
|
||||
---
|
||||
@@ -1,5 +0,0 @@
|
||||
---
|
||||
title: Authentication
|
||||
weight: 3000
|
||||
draft: true
|
||||
---
|
||||
@@ -1,5 +0,0 @@
|
||||
---
|
||||
title: Cloud Providers
|
||||
weight: 3000
|
||||
draft: true
|
||||
---
|
||||
@@ -1,5 +0,0 @@
|
||||
---
|
||||
title: Example Cluster.ymls
|
||||
weight: 3000
|
||||
draft: true
|
||||
---
|
||||
@@ -1,5 +0,0 @@
|
||||
---
|
||||
title: External etcd
|
||||
weight: 3000
|
||||
draft: true
|
||||
---
|
||||
@@ -1,5 +0,0 @@
|
||||
---
|
||||
title: Extra Args and Binds
|
||||
weight: 3000
|
||||
draft: true
|
||||
---
|
||||
@@ -1,5 +0,0 @@
|
||||
---
|
||||
title: Ingress Controller
|
||||
weight: 3000
|
||||
draft: true
|
||||
---
|
||||
@@ -1,5 +0,0 @@
|
||||
---
|
||||
title: Network Plug-ins
|
||||
weight: 3000
|
||||
draft: true
|
||||
---
|
||||
Reference in New Issue
Block a user