mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-26 04:58:07 +00:00
Merge branch 'master' into staging
This commit is contained in:
Denise
@@ -4,4 +4,4 @@ shortTitle: RKE
|
||||
weight: 1
|
||||
---
|
||||
|
||||
Rancher Kubernetes Engine (RKE) is a light-weight Kubernetes installer that supports installation on bare-metal and virtualized servers. RKE solves a common issue in the Kubernetes community: installation complexity. With RKE, Kubernetes installation is simplified, regardless of what operating systems and platforms you're running.
|
||||
Rancher Kubernetes Engine (RKE) is a CNCF-certified Kubernetes distribution that runs entirely within Docker containers. It works on bare-metal and virtualized servers. RKE solves the problem of installation complexity, a common issue in the Kubernetes community. With RKE, the installation and operation of Kubernetes is both simplified and easily automated, and it's entirely independent of the operating system and platform you're running. As long as you can run a supported version of Docker, you can deploy and run Kubernetes with RKE.
|
||||
|
||||
@@ -67,6 +67,11 @@ kubernetes_version: "v1.11.6-rancher1-1"
|
||||
|
||||
In case both `kubernetes_version` and [system images]({{< baseurl >}}/rke/latest/en/config-options/system-images/) are defined, the system images configuration will take precedence over `kubernetes_version`.
|
||||
|
||||
> **Note:** In RKE, `kubernetes_version` is used to map the version of Kubernetes to the default services, parameters, and options:
|
||||
|
||||
> - For RKE v0.3.0+, the service defaults are located [here](https://github.com/rancher/kontainer-driver-metadata/blob/master/rke/k8s_service_options.go).
|
||||
> - For RKE prior to v0.3.0, the service defaults are located [here](https://github.com/rancher/types/blob/release/v2.2/apis/management.cattle.io/v3/k8s_defaults.go). Note: The version in the path of the service defaults file corresponds to a Rancher version. Therefore, for Rancher v2.1.x, [this file](https://github.com/rancher/types/blob/release/v2.1/apis/management.cattle.io/v3/k8s_defaults.go) should be used.
|
||||
|
||||
#### Listing Supported Kubernetes Versions
|
||||
|
||||
Please refer to the [release notes](https://github.com/rancher/rke/releases) of the RKE version that you are running, to find the list of supported Kubernetes versions as well as the default Kubernetes version.
|
||||
|
||||
@@ -3,23 +3,20 @@ title: Add-Ons
|
||||
weight: 260
|
||||
---
|
||||
|
||||
RKE supports pluggable add-ons. Add-ons are used to deploy several cluster components including:
|
||||
RKE supports configuring pluggable add-ons in the cluster YML. Add-ons are used to deploy several cluster components including:
|
||||
|
||||
* [Network plug-ins]({{< baseurl >}}/rke/latest/en/config-options/add-ons/network-plugins/)
|
||||
* [Ingress controller]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/)
|
||||
* [DNS provider]({{< baseurl >}}/rke/latest/en/config-options/add-ons/dns/)
|
||||
* [Metrics Server]({{< baseurl >}}/rke/latest/en/config-options/add-ons/metrics-server/)
|
||||
|
||||
The images used for these add-ons under the [`system_images` directive]({{< baseurl >}}/rke/latest/en/config-options/system-images/). For each Kubernetes version, there are default images associated with each add-on, but these can be overridden by changing the image tag in `system_images`.
|
||||
These add-ons require images that can be found under the [`system_images` directive]({{< baseurl >}}/rke/latest/en/config-options/system-images/). For each Kubernetes version, there are default images associated with each add-on, but these can be overridden by changing the image tag in `system_images`.
|
||||
|
||||
In addition to these pluggable add-ons, you can specify an add-on that you want deployed after the cluster deployment is complete.
|
||||
|
||||
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 using `kubectl edit`.
|
||||
There are a few things worth noting:
|
||||
|
||||
* In addition to these pluggable add-ons, you can specify an add-on that you want deployed after the cluster deployment is complete.
|
||||
* 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 using `kubectl edit`.
|
||||
|
||||
## Critical and Non-Critical Add-ons
|
||||
|
||||
|
||||
@@ -16,6 +16,8 @@ RKE provides the following DNS providers that can be deployed as add-ons:
|
||||
|
||||
CoreDNS was made the default in RKE v0.2.5 when using Kubernetes 1.14 and higher. If you are using an RKE version lower than v0.2.5, kube-dns will be deployed by default.
|
||||
|
||||
> **Note:** If you switch from one DNS provider to another, the existing DNS provider will be removed before the new one is deployed.
|
||||
|
||||
# CoreDNS
|
||||
|
||||
_Available as of v0.2.5_
|
||||
|
||||
@@ -10,6 +10,8 @@ RKE provides the following network plug-ins that are deployed as add-ons:
|
||||
- Canal
|
||||
- Weave
|
||||
|
||||
> **Note:** After you launch the cluster, you cannot change your network provider. Therefore, choose which network provider you want to use carefully, as Kubernetes doesn’t allow switching between network providers. Once a cluster is created with a network provider, changing network providers would require you tear down the entire cluster and all its applications.
|
||||
|
||||
By default, the network plug-in is `canal`. If you want to use another network plug-in, you need to specify which network plug-in to enable at the cluster level in the `cluster.yml`.
|
||||
|
||||
```yaml
|
||||
@@ -20,7 +22,7 @@ network:
|
||||
|
||||
The images used for network plug-ins are under the [`system_images` directive]({{< baseurl >}}/rke/latest/en/config-options/system-images/). For each Kubernetes version, there are default images associated with each network plug-in, but these can be overridden by changing the image tag in `system_images`.
|
||||
|
||||
## Disabling deployment of a network plug-in
|
||||
# Disabling Deployment of a Network Plug-in
|
||||
|
||||
You can disable deploying a network plug-in by specifying `none` to the network `plugin` directive in the cluster configuration.
|
||||
|
||||
@@ -29,11 +31,11 @@ network:
|
||||
plugin: none
|
||||
```
|
||||
|
||||
## Network Plug-in Options
|
||||
# Network Plug-in Options
|
||||
|
||||
Besides the different images that could be used to deploy network plug-ins, certain network plug-ins support additional options that can be used to customize the network plug-in.
|
||||
|
||||
### Canal Network Plug-in Options
|
||||
## Canal Network Plug-in Options
|
||||
|
||||
```yaml
|
||||
network:
|
||||
@@ -48,7 +50,7 @@ network:
|
||||
By setting the `canal_iface`, you can configure the interface to use for inter-host communication.
|
||||
The `canal_flannel_backend_type` option allows you to specify the type of [flannel backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md) to use. By default the `vxlan` backend is used.
|
||||
|
||||
### Flannel Network Plug-in Options
|
||||
## Flannel Network Plug-in Options
|
||||
|
||||
```yaml
|
||||
network:
|
||||
@@ -63,7 +65,7 @@ network:
|
||||
By setting the `flannel_iface`, you can configure the interface to use for inter-host communication.
|
||||
The `flannel_backend_type` option allows you to specify the type of [flannel backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md) to use. By default the `vxlan` backend is used.
|
||||
|
||||
### Calico Network Plug-in Options
|
||||
## Calico Network Plug-in Options
|
||||
|
||||
```yaml
|
||||
network:
|
||||
@@ -80,7 +82,7 @@ Calico currently only supports 2 cloud providers, AWS or GCE, which can be set u
|
||||
- `aws`
|
||||
- `gce`
|
||||
|
||||
### Weave Network Plug-in Options
|
||||
## Weave Network Plug-in Options
|
||||
|
||||
```yaml
|
||||
network:
|
||||
@@ -92,3 +94,8 @@ network:
|
||||
#### Weave encryption
|
||||
|
||||
Weave encryption can be enabled by passing a string password to the network provider config.
|
||||
|
||||
|
||||
## Custom Network Plug-ins
|
||||
|
||||
It is possible to add a custom network plug-in by using the [user-defined add-on functionality]({{<baseurl>}}/rke/latest/en/config-options/add-ons/user-defined-add-ons/) of RKE. In the `addons` field, you can add the add-on manifest of a cluster that has the network plugin-that you want, as shown in [this example.]({{<baseurl>}}/rke/latest/en/config-options/add-ons/network-plugins/custom-network-plugin-example)
|
||||
|
||||
+207
@@ -0,0 +1,207 @@
|
||||
---
|
||||
title: Custom Network Plug-in Example
|
||||
weight: 1
|
||||
---
|
||||
|
||||
The below example shows how to configure a custom network plug-in with an in-line add-on to the `cluster.yml`.
|
||||
|
||||
First, to edit the network plug-ins, change the `network` section of the YAML from:
|
||||
|
||||
```
|
||||
network:
|
||||
options:
|
||||
flannel_backend_type: "vxlan"
|
||||
plugin: "canal"
|
||||
```
|
||||
to:
|
||||
```
|
||||
network:
|
||||
plugin: none
|
||||
```
|
||||
|
||||
Then, in the `addons` section of the `cluster.yml`, you can add the add-on manifest of a cluster that has the network plugin-that you want. In the below example, we are replacing the Canal plugin with a Flannel plugin by adding the add-on manifest for the cluster through the `addons` field:
|
||||
|
||||
```
|
||||
addons: |-
|
||||
---
|
||||
kind: ClusterRoleBinding
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
metadata:
|
||||
name: flannel
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: flannel
|
||||
subjects:
|
||||
- kind: ServiceAccount
|
||||
name: flannel
|
||||
namespace: kube-system
|
||||
---
|
||||
kind: ClusterRole
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
metadata:
|
||||
name: flannel
|
||||
rules:
|
||||
- apiGroups:
|
||||
- ""
|
||||
resources:
|
||||
- pods
|
||||
verbs:
|
||||
- get
|
||||
- apiGroups:
|
||||
- ""
|
||||
resources:
|
||||
- nodes
|
||||
verbs:
|
||||
- list
|
||||
- watch
|
||||
- apiGroups:
|
||||
- ""
|
||||
resources:
|
||||
- nodes/status
|
||||
verbs:
|
||||
- patch
|
||||
---
|
||||
kind: ConfigMap
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: kube-flannel-cfg
|
||||
namespace: "kube-system"
|
||||
labels:
|
||||
tier: node
|
||||
app: flannel
|
||||
data:
|
||||
cni-conf.json: |
|
||||
{
|
||||
"name":"cbr0",
|
||||
"cniVersion":"0.3.1",
|
||||
"plugins":[
|
||||
{
|
||||
"type":"flannel",
|
||||
"delegate":{
|
||||
"forceAddress":true,
|
||||
"isDefaultGateway":true
|
||||
}
|
||||
},
|
||||
{
|
||||
"type":"portmap",
|
||||
"capabilities":{
|
||||
"portMappings":true
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
net-conf.json: |
|
||||
{
|
||||
"Network": "10.42.0.0/16",
|
||||
"Backend": {
|
||||
"Type": "vxlan"
|
||||
}
|
||||
}
|
||||
---
|
||||
apiVersion: extensions/v1beta1
|
||||
kind: DaemonSet
|
||||
metadata:
|
||||
name: kube-flannel
|
||||
namespace: "kube-system"
|
||||
labels:
|
||||
tier: node
|
||||
k8s-app: flannel
|
||||
spec:
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
tier: node
|
||||
k8s-app: flannel
|
||||
spec:
|
||||
affinity:
|
||||
nodeAffinity:
|
||||
requiredDuringSchedulingIgnoredDuringExecution:
|
||||
nodeSelectorTerms:
|
||||
- matchExpressions:
|
||||
- key: beta.kubernetes.io/os
|
||||
operator: NotIn
|
||||
values:
|
||||
- windows
|
||||
serviceAccountName: flannel
|
||||
containers:
|
||||
- name: kube-flannel
|
||||
image: rancher/coreos-flannel:v0.10.0-rancher1
|
||||
imagePullPolicy: IfNotPresent
|
||||
resources:
|
||||
limits:
|
||||
cpu: 300m
|
||||
memory: 500M
|
||||
requests:
|
||||
cpu: 150m
|
||||
memory: 64M
|
||||
command: ["/opt/bin/flanneld","--ip-masq","--kube-subnet-mgr"]
|
||||
securityContext:
|
||||
privileged: true
|
||||
env:
|
||||
- name: POD_NAME
|
||||
valueFrom:
|
||||
fieldRef:
|
||||
fieldPath: metadata.name
|
||||
- name: POD_NAMESPACE
|
||||
valueFrom:
|
||||
fieldRef:
|
||||
fieldPath: metadata.namespace
|
||||
volumeMounts:
|
||||
- name: run
|
||||
mountPath: /run
|
||||
- name: cni
|
||||
mountPath: /etc/cni/net.d
|
||||
- name: flannel-cfg
|
||||
mountPath: /etc/kube-flannel/
|
||||
- name: install-cni
|
||||
image: rancher/flannel-cni:v0.3.0-rancher1
|
||||
command: ["/install-cni.sh"]
|
||||
env:
|
||||
# The CNI network config to install on each node.
|
||||
- name: CNI_NETWORK_CONFIG
|
||||
valueFrom:
|
||||
configMapKeyRef:
|
||||
name: kube-flannel-cfg
|
||||
key: cni-conf.json
|
||||
- name: CNI_CONF_NAME
|
||||
value: "10-flannel.conflist"
|
||||
volumeMounts:
|
||||
- name: cni
|
||||
mountPath: /host/etc/cni/net.d
|
||||
- name: host-cni-bin
|
||||
mountPath: /host/opt/cni/bin/
|
||||
hostNetwork: true
|
||||
tolerations:
|
||||
- operator: Exists
|
||||
effect: NoSchedule
|
||||
- operator: Exists
|
||||
effect: NoExecute
|
||||
- key: node.kubernetes.io/not-ready
|
||||
effect: NoSchedule
|
||||
operator: Exists
|
||||
volumes:
|
||||
- name: run
|
||||
hostPath:
|
||||
path: /run
|
||||
- name: cni
|
||||
hostPath:
|
||||
path: /etc/cni/net.d
|
||||
- name: flannel-cfg
|
||||
configMap:
|
||||
name: kube-flannel-cfg
|
||||
- name: host-cni-bin
|
||||
hostPath:
|
||||
path: /opt/cni/bin
|
||||
updateStrategy:
|
||||
rollingUpdate:
|
||||
maxUnavailable: 20%
|
||||
type: RollingUpdate
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: flannel
|
||||
namespace: kube-system
|
||||
```
|
||||
**Result:** The cluster is up with the custom network plug-in.
|
||||
@@ -5,7 +5,7 @@ weight: 240
|
||||
|
||||
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/).
|
||||
|
||||
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`.
|
||||
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` in your `cluster.yml`.
|
||||
|
||||
```yaml
|
||||
authorization:
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Bastion/Jump Host Configuration
|
||||
weight: 220
|
||||
---
|
||||
|
||||
Since RKE uses `ssh` to connect to [nodes]({{< baseurl >}}/rke/latest/en/config-options/nodes/), you can configure to use a bastion host. Keep in mind that the [port requirements]({{< baseurl >}}/rke/latest/en/os/#ports) for the RKE node move to the configured bastion host.
|
||||
Since RKE uses `ssh` to connect to [nodes]({{< baseurl >}}/rke/latest/en/config-options/nodes/), you can configure the `cluster.yml` so RKE will use a bastion host. Keep in mind that the [port requirements]({{< baseurl >}}/rke/latest/en/os/#ports) for the RKE node move to the configured bastion host. our private SSH key(s) only needs to reside on the host running RKE. You do not need to copy your private SSH key(s) to the bastion host.
|
||||
|
||||
```yaml
|
||||
bastion_host:
|
||||
|
||||
@@ -3,7 +3,7 @@ title: AWS Cloud Provider
|
||||
weight: 251
|
||||
---
|
||||
|
||||
To enable the AWS cloud provider, there are no configuration options. You only need to set the name as `aws`. In order to use the AWS cloud provider, all cluster nodes must have already been configured with an [appropriate IAM role](#iam-requirements) and your AWS resources must be [tagged with a cluster ID](#tagging-amazon-resources).
|
||||
To enable the AWS cloud provider, there are no RKE configuration options. You only need to set the name as `aws`. In order to use the AWS cloud provider, all cluster nodes must have already been configured with an [appropriate IAM role](#iam-requirements) and your AWS resources must be [tagged with a cluster ID](#tagging-amazon-resources).
|
||||
|
||||
```yaml
|
||||
cloud_provider:
|
||||
|
||||
@@ -5,9 +5,33 @@ weight: 210
|
||||
|
||||
The `nodes` directive is the only required section in the `cluster.yml` file. It's used by RKE to specify cluster node(s), ssh credentials used to access the node(s) and which roles these nodes will be in the Kubernetes cluster.
|
||||
|
||||
This section covers the following topics:
|
||||
|
||||
- [Node configuration example](#node-configuration-example)
|
||||
- [Kubernetes roles](#kubernetes-roles)
|
||||
- [etcd](#etcd)
|
||||
- [Controlplane](#controlplane)
|
||||
- [Worker](#worker)
|
||||
- [Node options](#node-options)
|
||||
- [Address](#address)
|
||||
- [Internal address](#internal-address)
|
||||
- [Overriding the hostname](#overriding-the-hostname)
|
||||
- [SSH port](#ssh-port)
|
||||
- [SSH users](#ssh-users)
|
||||
- [SSH key path](#ssh-key-path)
|
||||
- [SSH key](#ssh-key)
|
||||
- [SSH certificate path](#ssh-certificate-path)
|
||||
- [SSH certificate](#ssh-certificate)
|
||||
- [Docker socket](#docker-socket)
|
||||
- [Labels](#labels)
|
||||
- [Taints](#taints)
|
||||
|
||||
# Node Configuration Example
|
||||
|
||||
The following example shows node configuration in an example `cluster.yml`:
|
||||
|
||||
```yaml
|
||||
nodes:
|
||||
nodes:
|
||||
- address: 1.1.1.1
|
||||
user: ubuntu
|
||||
role:
|
||||
@@ -50,7 +74,33 @@ nodes:
|
||||
app: ingress
|
||||
```
|
||||
|
||||
## Node Options
|
||||
# Kubernetes Roles
|
||||
|
||||
You can specify the list of roles that you want the node to be as part of the Kubernetes cluster. Three roles are supported: `controlplane`, `etcd` and `worker`. Node roles are not mutually exclusive. It's possible to assign any combination of roles to any node. It's also possible to change a node's role using the upgrade process.
|
||||
|
||||
> **Note:** Prior to v0.1.8, workloads/pods might have run on any nodes with `worker` or `controlplane` roles, but as of v0.1.8, they will only be deployed to any `worker` nodes.
|
||||
|
||||
### etcd
|
||||
|
||||
With this role, the `etcd` container will be run on these nodes. Etcd keeps the state of your cluster and is the most important component in your cluster, single source of truth of your cluster. Although you can run etcd on just one node, it typically takes 3, 5 or more nodes to create an HA configuration. Etcd is a distributed reliable key-value store which stores all Kubernetes state. [Taint set on nodes](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) with the **etcd** role is shown below:
|
||||
|
||||
Taint Key | Taint Value | Taint Effect
|
||||
---------------------------------------|--------------|--------------
|
||||
`node-role.kubernetes.io/etcd` | `true` | `NoExecute`
|
||||
|
||||
### Controlplane
|
||||
|
||||
With this role, the stateless components that are used to deploy Kubernetes will run on these nodes. These components are used to run the API server, scheduler, and controllers. [Taint set on nodes](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) with the **controlplane** role is shown below:
|
||||
|
||||
Taint Key | Taint Value | Taint Effect
|
||||
---------------------------------------|--------------|--------------
|
||||
`node-role.kubernetes.io/controlplane` | `true` | `NoSchedule`
|
||||
|
||||
### Worker
|
||||
|
||||
With this role, any workloads or pods that are deployed will land on these nodes.
|
||||
|
||||
# Node Options
|
||||
|
||||
Within each node, there are multiple directives that can be used.
|
||||
|
||||
@@ -94,32 +144,6 @@ For each node, you can specify the path, i.e. `ssh_cert_path`, for the signed SS
|
||||
|
||||
Instead of setting the path to the signed SSH certificate, you can alternatively specify the actual certificate, i.e. `ssh_cert`, to be used to connect to the node.
|
||||
|
||||
### Kubernetes Roles
|
||||
|
||||
You can specify the list of roles that you want the node to be as part of the Kubernetes cluster. Three roles are supported: `controlplane`, `etcd` and `worker`. Node roles are not mutually exclusive. It's possible to assign any combination of roles to any node. It's also possible to change a node's role using the upgrade process.
|
||||
|
||||
> **Note:** Prior to v0.1.8, workloads/pods might have run on any nodes with `worker` or `controlplane` roles, but as of v0.1.8, they will only be deployed to any `worker` nodes.
|
||||
|
||||
* **etcd**
|
||||
|
||||
With this role, the `etcd` container will be run on these nodes. Etcd keeps the state of your cluster and is the most important component in your cluster, single source of truth of your cluster. Although you can run etcd on just one node, it typically takes 3, 5 or more nodes to create an HA configuration. Etcd is a distributed reliable key-value store which stores all Kubernetes state. [Taint set on nodes](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) with the **etcd** role is shown below:
|
||||
|
||||
Taint Key | Taint Value | Taint Effect
|
||||
---------------------------------------|--------------|--------------
|
||||
`node-role.kubernetes.io/etcd` | `true` | `NoExecute`
|
||||
|
||||
* **controlplane**
|
||||
|
||||
With this role, the stateless components that are used to deploy Kubernetes will run on these nodes. These components are used to run the API server, scheduler, and controllers. [Taint set on nodes](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) with the **controlplane** role is shown below:
|
||||
|
||||
Taint Key | Taint Value | Taint Effect
|
||||
---------------------------------------|--------------|--------------
|
||||
`node-role.kubernetes.io/controlplane` | `true` | `NoSchedule`
|
||||
|
||||
* **worker**
|
||||
|
||||
With this role, any workloads or pods that are deployed will land on these nodes.
|
||||
|
||||
### Docker Socket
|
||||
|
||||
If the Docker socket is different than the default, you can set the `docker_socket`. The default is `/var/run/docker.sock`
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Private Registries
|
||||
weight: 215
|
||||
---
|
||||
|
||||
RKE supports the ability to configure multiple private Docker registries. By passing in your registry and credentials, it allows the nodes to pull images from these private registries.
|
||||
RKE supports the ability to configure multiple private Docker registries in the `cluster.yml`. By passing in your registry and credentials, it allows the nodes to pull images from these private registries.
|
||||
|
||||
```yaml
|
||||
private_registries:
|
||||
|
||||
@@ -9,10 +9,16 @@ RKE supports additional service arguments, volume binds and environment variable
|
||||
|
||||
For any of the Kubernetes services, you can update the `extra_args` to change the existing defaults.
|
||||
|
||||
As of `v0.1.3`, using `extra_args` will add new arguments and **override** any existing defaults. For example, if you need to modify the default admission controllers list, you need to include the default list and edit it with your changes so all changes are included.
|
||||
As of `v0.1.3`, using `extra_args` will add new arguments and **override** any existing defaults. For example, if you need to modify the default admission plugins list, you need to include the default list and edit it with your changes so all changes are included.
|
||||
|
||||
Prior to `v0.1.3`, using `extra_args` would only add new arguments to the list and there was no ability to change the default list.
|
||||
|
||||
All service defaults and parameters are defined per [`kubernetes_version`]({{<baseurl>}}/rke/latest/en/config-options/#kubernetes-version):
|
||||
|
||||
- For RKE v0.3.0+, the service defaults and parameters are defined per [`kubernetes_version`]({{<baseurl>}}/rke/latest/en/config-options/#kubernetes-version). The service defaults are located [here](https://github.com/rancher/kontainer-driver-metadata/blob/master/rke/k8s_service_options.go). The default list of admissions plugins is the same for all Kubernetes versions and is located [here](https://github.com/rancher/kontainer-driver-metadata/blob/master/rke/k8s_service_options.go#L11).
|
||||
|
||||
- For RKE prior to v0.3.0, the service defaults and admission plugins are defined per [`kubernetes_version`]({{<baseurl>}}/rke/latest/en/config-options/#kubernetes-version) and located [here](https://github.com/rancher/types/blob/release/v2.2/apis/management.cattle.io/v3/k8s_defaults.go).
|
||||
|
||||
```yaml
|
||||
services:
|
||||
kube-controller:
|
||||
|
||||
@@ -6,7 +6,7 @@ When RKE is deploying Kubernetes, there are several images that are pulled. Thes
|
||||
|
||||
As of `v0.1.6`, the functionality of a couple of the system images were consolidated into a single `rancher/rke-tools` image to simplify and speed the deployment process.
|
||||
|
||||
You can configure the [network plug-ins]({{<baseurl>}}/rke/latest/en/config-options/add-ons/network-plugins/), [ingress controller]({{<baseurl>}}/rke/latest/en/config-options/add-ons/ingress-controllers/) and [dns provider]({{<baseurl>}}/rke/latest/en/config-options/add-ons/dns/) as well as the options for these add-ons separately.
|
||||
You can configure the [network plug-ins]({{<baseurl>}}/rke/latest/en/config-options/add-ons/network-plugins/), [ingress controller]({{<baseurl>}}/rke/latest/en/config-options/add-ons/ingress-controllers/) and [dns provider]({{<baseurl>}}/rke/latest/en/config-options/add-ons/dns/) as well as the options for these add-ons separately in the `cluster.yml`.
|
||||
|
||||
Below is an example of the list of system images used to deploy Kubernetes through RKE. The default versions of Kubernetes are tied to specific versions of system images.
|
||||
|
||||
|
||||
@@ -38,14 +38,13 @@ time="2018-05-04T18:43:16Z" level=info msg="Created backup" name="2018-05-04T18:
|
||||
|**secret_key** |S3 secret key with permission to access the backup bucket.| * |
|
||||
|**region** |S3 region for the backup bucket. This is optional.| * |
|
||||
|**endpoint** |S3 regions endpoint for the backup bucket.| * |
|
||||
| **endpoint-ca** | Custom CA certificate to connect to custom S3 endpoint. Provided as a multi-line string. _Available as of v0.2.5_ | *|
|
||||
|**custom_ca** |Custom certificate authority to use when connecting to the endpoint. Only required for private S3 compatible storage solutions. Available for RKE v0.2.5+.| * |
|
||||
|
||||
The `--access-key` and `--secret-key` options are not required if the `etcd` nodes are AWS EC2 instances that have been configured with a suitable IAM instance profile.
|
||||
|
||||
##### Using a custom CA certificate for S3
|
||||
|
||||
The backup snapshot can be stored on a custom `S3` backup like [minio](https://min.io/). If the S3 backend uses a self-signed or custom certificate, provide a custom certificate using the option `endpoint-ca` to connect to the S3 backend.
|
||||
The backup snapshot can be stored on a custom `S3` backup like [minio](https://min.io/). If the S3 backend uses a self-signed or custom certificate, provide a custom certificate using the option `custom_ca` to connect to the S3 backend.
|
||||
|
||||
### IAM Support for Storing Snapshots in S3
|
||||
|
||||
@@ -53,7 +52,7 @@ In addition to API access keys, RKE supports using IAM roles for S3 authenticati
|
||||
|
||||
Below is an [example IAM policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_s3_rw-bucket.html) that would allow nodes to store and retrieve backups from S3:
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
|
||||
@@ -8,7 +8,9 @@ The details of restoring your cluster from backup are different depending on you
|
||||
{{% tabs %}}
|
||||
{{% tab "RKE v0.2.0+"%}}
|
||||
|
||||
If there is a disaster with your Kubernetes cluster, you can use `rke etcd snapshot-restore` to recover your etcd. This command reverts the etcd to a specific snapshot. The following actions are included in the command:
|
||||
If there is a disaster with your Kubernetes cluster, you can use `rke etcd snapshot-restore` to recover your etcd. This command reverts etcd to a specific snapshot and should be run on an etcd node of the the specific cluster that has suffered the disaster.
|
||||
|
||||
The following actions will be performed when you run the command:
|
||||
|
||||
- Syncs the snapshot or downloads the snapshot from S3, if necessary.
|
||||
- Checks snapshot checksum across etcd nodes to make sure they are identical.
|
||||
@@ -71,9 +73,9 @@ $ rke etcd snapshot-restore \
|
||||
{{% /tab %}}
|
||||
{{% tab "RKE prior to v0.2.0"%}}
|
||||
|
||||
If there is a disaster with your Kubernetes cluster, you can use `rke etcd snapshot-restore` to recover your etcd. This command reverts etcd to a specific snapshot.
|
||||
If there is a disaster with your Kubernetes cluster, you can use `rke etcd snapshot-restore` to recover your etcd. This command reverts etcd to a specific snapshot and should be run on an etcd node of the the specific cluster that has suffered the disaster.
|
||||
|
||||
The following actions are included in `rke etcd snapshot-restore`:
|
||||
The following actions will be performed when you run the command:
|
||||
|
||||
- Removes the old etcd cluster
|
||||
- Rebuilds the etcd cluster using the local snapshot
|
||||
|
||||
@@ -38,6 +38,8 @@ RKE runs on almost any Linux OS with Docker installed. Most of the development a
|
||||
```
|
||||
usermod -aG docker <user_name>
|
||||
```
|
||||
|
||||
> **Note:** Users added to the `docker` group are granted effective root permissions on the host by means of the Docker API. Only choose a user that is intended for this purpose and has its credentials and access properly secured.
|
||||
|
||||
See [Manage Docker as a non-root user](https://docs.docker.com/install/linux/linux-postinstall/#manage-docker-as-a-non-root-user) to see how you can configure access to Docker without using the `root` user.
|
||||
|
||||
@@ -164,13 +166,21 @@ By default, Atomic hosts do not come with a Docker group. You can update the own
|
||||
|
||||
## Software
|
||||
|
||||
- Docker - Each Kubernetes version supports different Docker versions.
|
||||
This section describes the requirements for Docker, Kubernetes, and SSH.
|
||||
|
||||
Kubernetes Version | Supported Docker version(s) |
|
||||
----|----|
|
||||
v1.13.x | RHEL Docker 1.13, 17.03.2, 18.06.2, 18.09.2 |
|
||||
v1.12.x | RHEL Docker 1.13, 17.03.2, 18.06.2, 18.09.2 |
|
||||
v1.11.x | RHEL Docker 1.13, 17.03.2, 18.06.2, 18.09.2 |
|
||||
### OpenSSH
|
||||
|
||||
In order to SSH into each node, OpenSSH 7.0+ must be installed on each node.
|
||||
|
||||
### Kubernetes
|
||||
|
||||
Refer to the [RKE release notes](https://github.com/rancher/rke/releases) for the supported versions of Kubernetes.
|
||||
|
||||
### Docker
|
||||
|
||||
Each Kubernetes version supports different Docker versions. The Kubernetes release notes contain the [current list](https://kubernetes.io/docs/setup/release/notes/#dependencies) of validated Docker versions.
|
||||
|
||||
### Installing Docker
|
||||
|
||||
You can either follow the [Docker installation](https://docs.docker.com/install/) instructions or use one of Rancher's [install scripts](https://github.com/rancher/install-docker) to install Docker. For RHEL, please see [How to install Docker on Red Hat Enterprise Linux 7](https://access.redhat.com/solutions/3727511).
|
||||
|
||||
@@ -180,6 +190,8 @@ Docker Version | Install Script |
|
||||
18.06.2 | <code>curl https://releases.rancher.com/install-docker/18.06.2.sh | sh</code> |
|
||||
17.03.2 | <code>curl https://releases.rancher.com/install-docker/17.03.2.sh | sh</code> |
|
||||
|
||||
### Checking the Installed Docker Version
|
||||
|
||||
Confirm that a Kubernetes supported version of Docker is installed on your machine, by running `docker version --format '{{.Server.Version}}'`.
|
||||
|
||||
```
|
||||
@@ -187,10 +199,7 @@ docker version --format '{{.Server.Version}}'
|
||||
17.03.2-ce
|
||||
```
|
||||
|
||||
- OpenSSH 7.0+ - In order to SSH into each node, OpenSSH must be installed on each node.
|
||||
|
||||
## Ports
|
||||
|
||||
{{< ports-rke-nodes >}}
|
||||
{{< requirements_ports_rke >}}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user