mirror of https://github.com/rancher/rke1-docs.git
Remove invalid front matter
This commit is contained in:
parent
e2025b029e
commit
69d37e33d5
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Certificate Management
|
||||
weight: 150
|
||||
---
|
||||
|
||||
_Available as of v0.2.0_
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Add-Ons
|
||||
weight: 260
|
||||
---
|
||||
|
||||
RKE supports configuring pluggable add-ons in the cluster YML. Add-ons are used to deploy several cluster components including:
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: DNS providers
|
||||
weight: 262
|
||||
---
|
||||
|
||||
# Available DNS Providers
|
||||
|
|
|
|||
|
|
@ -1,7 +1,6 @@
|
|||
---
|
||||
title: K8s Ingress Controllers
|
||||
description: By default, RKE deploys the NGINX ingress controller. Learn how to schedule and disable default k8s ingress controllers, and how to configure NGINX controller
|
||||
weight: 262
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Metrics Server
|
||||
weight: 263
|
||||
---
|
||||
|
||||
By default, RKE deploys [Metrics Server](https://github.com/kubernetes-incubator/metrics-server) to provide metrics on resources in your cluster.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
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`.
|
||||
|
|
@ -8,8 +7,8 @@ The below example shows how to configure a custom network plug-in with an in-lin
|
|||
First, to edit the network plug-ins, change the `network` section of the YAML from:
|
||||
|
||||
```
|
||||
network:
|
||||
options:
|
||||
network:
|
||||
options:
|
||||
flannel_backend_type: "vxlan"
|
||||
plugin: "canal"
|
||||
```
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Network Plug-ins
|
||||
weight: 261
|
||||
---
|
||||
|
||||
RKE provides the following network plug-ins that are deployed as add-ons:
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: User-Defined Add-Ons
|
||||
weight: 263
|
||||
---
|
||||
|
||||
Besides the [network plug-in](config-options/add-ons/network-plugins) and [ingress controllers](config-options/add-ons/ingress-controllers/), you can define any add-on that you want deployed after the Kubernetes cluster is deployed.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Audit Log
|
||||
weight: 251
|
||||
---
|
||||
|
||||
Kubernetes auditing provides a security-relevant chronological set of records about a cluster. Kube-apiserver performs auditing. Each request on each stage of its execution generates an event, which is then pre-processed according to a certain policy and written to a backend. The policy determines what’s recorded and the backends persist the records.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Authentication
|
||||
weight: 235
|
||||
---
|
||||
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Authorization
|
||||
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/).
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Bastion/Jump Host Configuration
|
||||
weight: 220
|
||||
---
|
||||
|
||||
Since RKE uses `ssh` to connect to [nodes](config-options/nodes/), you can configure the `cluster.yml` so RKE will use a bastion host. Keep in mind that the [port requirements](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.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: AWS Cloud Provider
|
||||
weight: 251
|
||||
---
|
||||
|
||||
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-aws-resources).
|
||||
|
|
@ -119,7 +118,7 @@ The AWS cloud provider uses tagging to discover and manage resources, the follow
|
|||
|
||||
- **VPC**: The VPC used by the cluster
|
||||
- **Subnet**: The subnets used by the cluster
|
||||
- **EC2 instances**: All nodes launched for the cluster
|
||||
- **EC2 instances**: All nodes launched for the cluster
|
||||
- **Security Groups**: The security group(s) used by nodes in the cluster
|
||||
|
||||
>**Note:** If creating a `LoadBalancer` service and there is more than one security group attached to nodes, you must tag only one of the security groups as `owned` so that Kubernetes knows which group to add and remove rules. A single untagged security group is allowed, however, sharing this between clusters is not recommended.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Azure Cloud Provider
|
||||
weight: 252
|
||||
---
|
||||
|
||||
To enable the Azure cloud provider, besides setting the name as `azure`, there are specific configuration options that must be set. Additionally, the Azure node name must also match the Kubernetes node name.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Cloud Providers
|
||||
weight: 250
|
||||
---
|
||||
|
||||
RKE supports the ability to set your specific cloud provider for your Kubernetes cluster. There are specific cloud configurations for these cloud providers.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Custom Cloud Provider
|
||||
weight: 255
|
||||
---
|
||||
|
||||
If you want to enable a different cloud provider, RKE allows for custom cloud provider options. A name must be provided and the custom Cloud Provider options can be passed in as a multiline string in `customCloudProvider`.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: OpenStack Cloud Provider
|
||||
weight: 253
|
||||
---
|
||||
|
||||
To enable the OpenStack cloud provider, besides setting the name as `openstack`, there are specific configuration options that must be set. The OpenStack configuration options are grouped into different sections.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: vSphere Configuration Reference
|
||||
weight: 3
|
||||
---
|
||||
|
||||
This section shows an example of how to configure the vSphere cloud provider.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Enabling Disk UUIDs for vSphere VMs
|
||||
weight: 2
|
||||
---
|
||||
|
||||
In order to provision nodes with RKE, all nodes must be configured with disk UUIDs. This is required so that attached VMDKs present a consistent UUID to the VM, allowing the disk to be mounted properly.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Troubleshooting vSphere Clusters
|
||||
weight: 4
|
||||
---
|
||||
|
||||
If you are experiencing issues while provisioning a cluster with enabled vSphere Cloud Provider or while creating vSphere volumes for your workloads, you should inspect the logs of the following K8s services:
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: vSphere Cloud Provider
|
||||
weight: 254
|
||||
---
|
||||
|
||||
This section describes how to enable the vSphere cloud provider. You will need to use the `cloud_provider` directive in the cluster YAML file.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,6 @@
|
|||
---
|
||||
title: Kubernetes Configuration Options
|
||||
description: There are a lot of different Kubernetes Configuration options you can choose from when setting up your cluster.yml for RKE
|
||||
weight: 200
|
||||
---
|
||||
|
||||
When setting up your `cluster.yml` for RKE, there are a lot of different options that can be configured to control the behavior of how RKE launches Kubernetes.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Dual-stack
|
||||
weight: 255
|
||||
---
|
||||
|
||||
As of RKE `v1.3.0`, [dual-stack](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) networking support has been added, which allows allocating both IPv4 and IPv6 addresses to pods and services.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Nodes
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Private Registries
|
||||
weight: 215
|
||||
---
|
||||
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Rate Limiting
|
||||
weight: 241
|
||||
---
|
||||
|
||||
Using the `EventRateLimit` admission control enforces a limit on the number of events that the API Server will accept in a given time period. In a large multi-tenant cluster, there might be a small percentage of tenants that flood the server with event requests, which could have a significant impact on the performance of the cluster overall. Therefore, it is recommended to limit the rate of events that the API server will accept.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Encrypting Secret Data at Rest
|
||||
weight: 230
|
||||
---
|
||||
|
||||
As of version `v0.3.1` RKE adds the support for managing secret data encryption at rest, which is [supported by Kubernetes](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#before-you-begin) since version `v1.13`.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: External etcd
|
||||
weight: 232
|
||||
---
|
||||
|
||||
By default, RKE will launch etcd servers, but RKE also supports being able to use an external etcd. RKE only supports connecting to a TLS enabled etcd setup.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Extra Args, Extra Binds, and Extra Environment Variables
|
||||
weight: 231
|
||||
---
|
||||
|
||||
RKE supports additional service arguments, volume binds and environment variables.
|
||||
|
|
@ -17,7 +16,7 @@ All service defaults and parameters are defined per [`kubernetes_version`](confi
|
|||
|
||||
- For RKE v0.3.0+, the service defaults and parameters are defined per [`kubernetes_version`](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 before v0.3.0, the service defaults and admission plugins are defined per [`kubernetes_version`](config-options/#kubernetes-version) and located [here](https://github.com/rancher/types/blob/release/v2.2/apis/management.cattle.io/v3/k8s_defaults.go).
|
||||
- For RKE before v0.3.0, the service defaults and admission plugins are defined per [`kubernetes_version`](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:
|
||||
|
|
|
|||
|
|
@ -1,7 +1,6 @@
|
|||
---
|
||||
title: Default Kubernetes Services
|
||||
description: To deploy Kubernetes, RKE deploys several default Kubernetes services. Read about etcd, kube-api server, kubelet, kube-proxy and more
|
||||
weight: 230
|
||||
---
|
||||
|
||||
To deploy Kubernetes, RKE deploys several core components or services in Docker containers on the nodes. Based on the roles of the node, the containers deployed may be different.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: System Images
|
||||
weight: 225
|
||||
---
|
||||
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.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +1,5 @@
|
|||
---
|
||||
title: Backups and Disaster Recovery
|
||||
weight: 150
|
||||
aliases:
|
||||
- /rke/latest/en/installation/etcd-snapshots/
|
||||
---
|
||||
|
||||
_Available as of v0.1.7_
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Example Scenarios
|
||||
weight: 4
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: One-time Snapshots
|
||||
weight: 1
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Recurring Snapshots
|
||||
weight: 2
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Restoring from Backup
|
||||
weight: 3
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Troubleshooting
|
||||
weight: 5
|
||||
---
|
||||
|
||||
As of **v0.1.9**, the **rke-bundle-cert** container is removed on both success and failure of a restore. To debug any issues, you will need to look at the **logs** generated from rke.
|
||||
|
|
|
|||
|
|
@ -1,8 +1,5 @@
|
|||
---
|
||||
title: Example Cluster.ymls
|
||||
weight: 300
|
||||
aliases:
|
||||
- /rke/latest/en/config-options/example-yamls/
|
||||
---
|
||||
|
||||
There are lots of different [configuration options](config-options/) that can be set in the cluster configuration file for RKE. Here are some examples of files:
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Custom Certificates
|
||||
weight: 150
|
||||
---
|
||||
|
||||
_Available as of v0.2.0_
|
||||
|
|
@ -53,13 +52,13 @@ If you want to create and sign the certificates by a real Certificate Authority
|
|||
2. Run `rke cert generate-csr` to generate certificates for the node(s) in the `cluster.yml`. By default, the CSRs and keys will be saved in `./cluster_certs`. To have them saved in a different directory, use `--cert-dir` to define what directory to have them saved in.
|
||||
|
||||
```
|
||||
$ rke cert generate-csr
|
||||
$ rke cert generate-csr
|
||||
INFO[0000] Generating Kubernetes cluster CSR certificates
|
||||
INFO[0000] [certificates] Generating Kubernetes API server csr
|
||||
INFO[0000] [certificates] Generating Kube Controller csr
|
||||
INFO[0000] [certificates] Generating Kube Scheduler csr
|
||||
INFO[0000] [certificates] Generating Kube Proxy csr
|
||||
INFO[0001] [certificates] Generating Node csr and key
|
||||
INFO[0000] [certificates] Generating Kube Proxy csr
|
||||
INFO[0001] [certificates] Generating Node csr and key
|
||||
INFO[0001] [certificates] Generating admin csr and kubeconfig
|
||||
INFO[0001] [certificates] Generating Kubernetes API server proxy client csr
|
||||
INFO[0001] [certificates] Generating etcd-x.x.x.x csr and key
|
||||
|
|
|
|||
|
|
@ -1,7 +1,6 @@
|
|||
---
|
||||
title: RKE Kubernetes Installation
|
||||
description: RKE is a fast, versatile Kubernetes installer you can use to install Kubernetes on your Linux hosts. Learn the simple steps for an RKE Kubernetes installation
|
||||
weight: 50
|
||||
---
|
||||
|
||||
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
|
||||
|
|
|
|||
|
|
@ -1,9 +1,7 @@
|
|||
---
|
||||
slug: /
|
||||
title: Overview of RKE
|
||||
shortTitle: RKE
|
||||
description: RKE solves Kubernetes installation complexity. With RKE, Kubernetes installation is simplified, regardless of what OSs and platforms you’re running.
|
||||
weight: 1
|
||||
---
|
||||
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Kubeconfig File
|
||||
weight: 145
|
||||
---
|
||||
|
||||
In order to start interacting with your Kubernetes cluster, you will use a different binary called `kubectl`. You will need to [install kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) on your local machine.
|
||||
|
|
|
|||
|
|
@ -1,9 +1,6 @@
|
|||
---
|
||||
title: Adding and Removing Nodes
|
||||
description: RKE supports adding/removing nodes for worker and controlplane hosts. Learn about the changes you need to make to the cluster.yml in order to add/remove nodes
|
||||
weight: 175
|
||||
aliases:
|
||||
- /rke/latest/en/installation/managing-clusters/
|
||||
---
|
||||
|
||||
### Adding/Removing Nodes
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Requirements
|
||||
weight: 5
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Provisioning Errors
|
||||
weight: 200
|
||||
---
|
||||
|
||||
### Failed to get job complete status
|
||||
|
|
|
|||
|
|
@ -1,9 +1,5 @@
|
|||
---
|
||||
title: SSH Connectivity Errors
|
||||
weight: 100
|
||||
aliases:
|
||||
- /rancher/v2.x/en/installation/ha/rke-add-on/troubleshooting/ssh-tunneling/
|
||||
|
||||
---
|
||||
|
||||
### Failed to set up SSH tunneling for host [xxx.xxx.xxx.xxx]: Can't retrieve Docker Info
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Troubleshooting
|
||||
weight: 400
|
||||
---
|
||||
|
||||
* [SSH Connectivity Errors](troubleshooting/ssh-connectivity-errors/)
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Configuring the Upgrade Strategy
|
||||
weight: 2
|
||||
---
|
||||
|
||||
In this section, you'll learn how to configure the maximum number of unavailable controlplane and worker nodes, how to drain nodes before upgrading them, and how to configure the replicas for addons such as Ingress.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: How Upgrades Work
|
||||
weight: 1
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: Maintaining Availability for Applications During Upgrades
|
||||
weight: 1
|
||||
---
|
||||
|
||||
_Available as of v1.1.0_
|
||||
|
||||
In this section, you'll learn the requirements to prevent downtime for your applications when you upgrade the cluster using `rke up`.
|
||||
|
|
@ -20,7 +20,7 @@ To avoid downtime for your applications during an upgrade, you will need to conf
|
|||
|
||||
### 1. Kubernetes Version Requirement
|
||||
|
||||
When upgrading to a newer Kubernetes version, the upgrade must be from a minor release to the next minor version, or to within the same patch release series.
|
||||
When upgrading to a newer Kubernetes version, the upgrade must be from a minor release to the next minor version, or to within the same patch release series.
|
||||
|
||||
### 2. Cluster Requirements
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
title: Upgrades
|
||||
weight: 100
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
|
|
|
|||
Loading…
Reference in New Issue