public/rancher-docs
1
0
Fork 0
mirror of https://github.com/rancher/rancher-docs.git synced 2026-09-25 04:28:15 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #4209 from btat/encoding-misc

Browse Source 
Encoding/HTML misc
This commit is contained in:
Billy Tat
2022-07-19 14:33:50 -07:00
committed by GitHub
parent 2deeb51d5e 97f8fd1c09
commit 4da946734a
116 changed files with 3172 additions and 2777 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/en/backups/docker-installs/docker-backups/docker-backups.md
+3 -2
View File
@@ -18,7 +18,8 @@ In this command, `<DATE>` is a placeholder for the date that the data container
Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the [procedure below](#creating-a-backup).
<sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;RANCHER_CONTAINER_TAG&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>
![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
| Placeholder | Example | Description |
@@ -49,7 +50,7 @@ This procedure creates a backup that you can restore if Rancher encounters a dis
docker create --volumes-from <RANCHER_CONTAINER_NAME> --name rancher-data-<DATE> rancher/rancher:<RANCHER_CONTAINER_TAG>
```
1. <a id="tarball"></a>From the data container that you just created (`rancher-data-<DATE>`), create a backup tarball (`rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz`). Use the following command, replacing each placeholder:
1. <a id="tarball"></a>From the data container that you just created (<code>rancher-data-&lt;DATE&gt;</code>), create a backup tarball (<code>rancher-data-backup-&lt;RANCHER_VERSION&gt;-&lt;DATE&gt;.tar.gz</code>). Use the following command, replacing each placeholder:
```
docker run --volumes-from rancher-data-<DATE> -v $PWD:/backup:z busybox tar pzcvf /backup/rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz /var/lib/rancher
docs/en/backups/docker-installs/docker-restores/docker-restores.md
+3 -2
View File
@@ -20,7 +20,8 @@ In this command, `<RANCHER_CONTAINER_NAME>` and `<RANCHER_VERSION>-<DATE>` are e
Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the procedure below.
<sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;RANCHER_CONTAINER_TAG&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>
![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
| Placeholder | Example | Description |
@@ -51,7 +52,7 @@ Using a [backup]({{<baseurl>}}/rancher/v2.6/en/backups/docker-installs/docker-ba
1. Enter the following command to delete your current state data and replace it with your backup data, replacing the placeholders. Don't forget to close the quotes.
:::danger
This command deletes all current state data from your Rancher Server container. Any changes saved after your backup tarball was created will be lost.
:::
docs/en/backups/migrating-rancher/migrating-rancher.md
+4 -4
View File
@@ -30,7 +30,7 @@ helm repo update
helm install rancher-backup-crd rancher-charts/rancher-backup-crd -n cattle-resources-system --create-namespace --version $CHART_VERSION
helm install rancher-backup rancher-charts/rancher-backup -n cattle-resources-system --version $CHART_VERSION
```
</br>
<br/>
For an **air-gapped environment**, use the option below to pull the `backup-restore-operator` image from your private registry when installing the rancher-backup-crd helm chart.
```
--set image.repository $REGISTRY/rancher/backup-restore-operator
@@ -70,7 +70,7 @@ data:
This secret can be created in any namespace; with the above example, it will get created in the default namespace.
In the Restore custom resource, `prune` must be set to false.
In the Restore custom resource, `prune` must be set to false.
Create a Restore custom resource like the example below:
@@ -96,11 +96,11 @@ spec:
:::note Important:
The field `encryptionConfigSecretName` must be set only if your backup was created with encryption enabled. Provide the name of the Secret containing the encryption config file. If you only have the encryption config file, but don't have a secret created with it in this cluster, use the following steps to create the secret:
The field `encryptionConfigSecretName` must be set only if your backup was created with encryption enabled. Provide the name of the Secret containing the encryption config file. If you only have the encryption config file, but don't have a secret created with it in this cluster, use the following steps to create the secret:
:::
1. The encryption configuration file must be named `encryption-provider-config.yaml`, and the `--from-file` flag must be used to create this secret. So save your `EncryptionConfiguration` in a file called `encryption-provider-config.yaml` and run this command:
1. The encryption configuration file must be named `encryption-provider-config.yaml`, and the `--from-file` flag must be used to create this secret. So save your `EncryptionConfiguration` in a file called `encryption-provider-config.yaml` and run this command:
```
kubectl create secret generic encryptionconfig \
--from-file=./encryption-provider-config.yaml \
docs/en/cluster-admin/cluster-autoscaler/amazon/amazon.md
+11 -11
View File
@@ -5,7 +5,7 @@ weight: 1
This guide will show you how to install and use [Kubernetes cluster-autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/) on Rancher custom clusters using AWS EC2 Auto Scaling Groups.
We are going to install a Rancher RKE custom cluster with a fixed number of nodes with the etcd and controlplane roles, and a variable nodes with the worker role, managed by `cluster-autoscaler`.
We are going to install a Rancher RKE custom cluster with a fixed number of nodes with the etcd and controlplane roles, and a variable nodes with the worker role, managed by `cluster-autoscaler`.
- [Prerequisites](#prerequisites)
- [1. Create a Custom Cluster](#1-create-a-custom-cluster)
@@ -68,7 +68,7 @@ On AWS EC2, we should create a few objects to configure our system. We've define
}
```
2. Master group: Nodes that will be part of the Kubernetes etcd and/or control planes. This will be out of the ASG.
2. Master group: Nodes that will be part of the Kubernetes etcd and/or control planes. This will be out of the ASG.
* IAM profile: Required by the Kubernetes cloud_provider integration. Optionally, `AWS_ACCESS_KEY` and `AWS_SECRET_KEY` can be used instead [using-aws-credentials.](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#using-aws-credentials) This profile is called `K8sMasterProfile`.
```json
@@ -211,7 +211,7 @@ On AWS EC2, we should create a few objects to configure our system. We've define
* `kubernetes.io/cluster/<clusterID>: owned`
* `k8s.io/cluster-autoscaler/<clusterName>: true`
* `k8s.io/cluster-autoscaler/enabled: true`
* User data: `K8sWorkerUserData` Ubuntu 18.04(ami-0e11cbb34015ff725), installs docker and add worker node to the k8s cluster
* User data: `K8sWorkerUserData` Ubuntu 18.04(ami-0e11cbb34015ff725), installs docker and add worker node to the k8s cluster
```sh
#!/bin/bash -x
@@ -246,7 +246,7 @@ Once we've configured AWS, let's create VMs to bootstrap our cluster:
* master (etcd+controlplane): Depending your needs, deploy three master instances with proper size. More info is at [the recommendations for production-ready clusters.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/production/)
* IAM role: `K8sMasterRole`
* Security group: `K8sMasterSg`
* Tags:
* Tags:
* `kubernetes.io/cluster/<clusterID>: owned`
* User data: `K8sMasterUserData`
@@ -254,7 +254,7 @@ Once we've configured AWS, let's create VMs to bootstrap our cluster:
* Name: `K8sWorkerAsg`
* IAM role: `K8sWorkerRole`
* Security group: `K8sWorkerSg`
* Tags:
* Tags:
* `kubernetes.io/cluster/<clusterID>: owned`
* `k8s.io/cluster-autoscaler/<clusterName>: true`
* `k8s.io/cluster-autoscaler/enabled: true`
@@ -268,7 +268,7 @@ Once the VMs are deployed, you should have a Rancher custom cluster up and runni
### 4. Install Cluster-autoscaler
At this point, we should have rancher cluster up and running. We are going to install cluster-autoscaler on master nodes and `kube-system` namespace, following cluster-autoscaler recommendation.
At this point, we should have rancher cluster up and running. We are going to install cluster-autoscaler on master nodes and `kube-system` namespace, following cluster-autoscaler recommendation.
#### Parameters
@@ -296,9 +296,9 @@ This table shows cluster-autoscaler parameters for fine tuning:
|node-deletion-delay-timeout|"2m"|Maximum time CA waits for removing delay-deletion.cluster-autoscaler.kubernetes.io/ annotations before deleting the node|
|scan-interval|"10s"|How often cluster is reevaluated for scale up or down|
|max-nodes-total|0|Maximum number of nodes in all node groups. Cluster autoscaler will not grow the cluster beyond this number|
|cores-total|"0:320000"|Minimum and maximum number of cores in cluster, in the format <min>:<max>. Cluster autoscaler will not scale the cluster beyond these numbers|
|memory-total|"0:6400000"|Minimum and maximum number of gigabytes of memory in cluster, in the format <min>:<max>. Cluster autoscaler will not scale the cluster beyond these numbers|
cloud-provider|-|Cloud provider type|
|cores-total|"0:320000"|Minimum and maximum number of cores in cluster, in the format `<min>:<max>.` Cluster autoscaler will not scale the cluster beyond these numbers|
|memory-total|"0:6400000"|Minimum and maximum number of gigabytes of memory in cluster, in the format `<min>:<max>.` Cluster autoscaler will not scale the cluster beyond these numbers|
cloud-provider|-|Cloud provider type|
|max-bulk-soft-taint-count|10|Maximum number of nodes that can be tainted/untainted PreferNoSchedule at the same time. Set to 0 to turn off such tainting|
|max-bulk-soft-taint-time|"3s"|Maximum duration of tainting/untainting nodes as PreferNoSchedule at the same time|
|max-empty-bulk-delete|10|Maximum number of empty nodes that can be deleted at the same time|
@@ -307,7 +307,7 @@ cloud-provider|-|Cloud provider type|
|ok-total-unready-count|3|Number of allowed unready nodes, irrespective of max-total-unready-percentage|
|scale-up-from-zero|true|Should CA scale up when there 0 ready nodes|
|max-node-provision-time|"15m"|Maximum time CA waits for node to be provisioned|
|nodes|-|sets min,max size and other configuration data for a node group in a format accepted by cloud provider. Can be used multiple times. Format: <min>:<max>:<other...>|
|nodes|-|sets min,max size and other configuration data for a node group in a format accepted by cloud provider. Can be used multiple times. Format: `<min>:<max>:<other...>`|
|node-group-auto-discovery|-|One or more definition(s) of node group auto-discovery. A definition is expressed `<name of discoverer>:[<key>[=<value>]]`|
|estimator|-|"binpacking"|Type of resource estimator to be used in scale up. Available values: ["binpacking"]|
|expander|"random"|Type of node group expander to be used in scale up. Available values: `["random","most-pods","least-waste","price","priority"]`|
@@ -524,7 +524,7 @@ Cluster-autoscaler deployment can also be set up using [manual configuration](ht
# Testing
At this point, we should have a cluster-scaler up and running in our Rancher custom cluster. Cluster-scale should manage `K8sWorkerAsg` ASG to scale up and down between 2 and 10 nodes, when one of the following conditions is true:
At this point, we should have a cluster-scaler up and running in our Rancher custom cluster. Cluster-scale should manage `K8sWorkerAsg` ASG to scale up and down between 2 and 10 nodes, when one of the following conditions is true:
* There are pods that failed to run in the cluster due to insufficient resources. In this case, the cluster is scaled up.
* There are nodes in the cluster that have been underutilized for an extended period of time and their pods can be placed on other existing nodes. In this case, the cluster is scaled down.
docs/en/cluster-admin/editing-clusters/rke-config-reference/rke-config-references.md
+8 -7
View File
@@ -83,7 +83,7 @@ Some advanced configuration options are not exposed in the Rancher UI forms, but
:::
### Kubernetes Version
### Kubernetes Version
The version of Kubernetes installed on your cluster nodes. Rancher packages its own version of Kubernetes based on [hyperkube](https://github.com/rancher/hyperkube).
@@ -114,7 +114,7 @@ When Weave is selected as network provider, Rancher will automatically enable en
### Project Network Isolation
If your network provider allows project network isolation, you can choose whether to enable or disable inter-project communication.
If your network provider allows project network isolation, you can choose whether to enable or disable inter-project communication.
Project network isolation is available if you are using any RKE network plugin that supports the enforcement of Kubernetes network policies, such as Canal or the Cisco ACI plugin.
@@ -141,7 +141,7 @@ The private registry configuration option tells Rancher where to pull the [syste
- **System images** are components needed to maintain the Kubernetes cluster.
- **Add-ons** are used to deploy several cluster components, including network plug-ins, the ingress controller, the DNS provider, or the metrics server.
For more information on setting up a private registry for components applied during the provisioning of the cluster, see the [RKE documentation on private registries]({{<baseurl>}}/rke/latest/en/config-options/private-registries/).
For more information on setting up a private registry for components applied during the provisioning of the cluster, see the [RKE documentation on private registries]({{<baseurl>}}/rke/latest/en/config-options/private-registries/).
Rancher v2.6 introduced the ability to configure [ECR registries for RKE clusters]({{<baseurl>}}/rke/latest/en/config-options/private-registries/#amazon-elastic-container-registry-ecr-private-registry-setup).
@@ -169,7 +169,7 @@ For information on using the Rancher UI to set up node pools in an RKE cluster,
If you want to publish your applications in a high-availability configuration, and you're hosting your nodes with a cloud-provider that doesn't have a native load-balancing feature, enable this option to use NGINX Ingress within the cluster.
### Metrics Server Monitoring
### Metrics Server Monitoring
Option to enable or disable [Metrics Server]({{<baseurl>}}/rke/latest/en/config-options/add-ons/metrics-server/).
@@ -183,7 +183,7 @@ You must have an existing Pod Security Policy configured before you can use this
### Docker Version on Nodes
Configures whether nodes are allowed to run versions of Docker that Rancher doesn't officially support.
Configures whether nodes are allowed to run versions of Docker that Rancher doesn't officially support.
If you choose to require a supported Docker version, Rancher will stop pods from running on nodes that don't have a supported Docker version installed.
@@ -227,7 +227,8 @@ For the complete reference for configurable options for RKE Kubernetes clusters
RKE (Rancher Kubernetes Engine) is the tool that Rancher uses to provision Kubernetes clusters. Rancher's cluster config files used to have the same structure as [RKE config files,]({{<baseurl>}}/rke/latest/en/example-yamls/) but the structure changed so that in Rancher, RKE cluster config items are separated from non-RKE config items. Therefore, configuration for your cluster needs to be nested under the `rancher_kubernetes_engine_config` directive in the cluster config file. Cluster config files created with earlier versions of Rancher will need to be updated for this format. An example cluster config file is included below.
{{% accordion id="v2.3.0-cluster-config-file" label="Example Cluster Config File" %}}
<details id="v2.3.0-cluster-config-file">
<summary>Example Cluster Config File</summary>
```yaml
#
@@ -319,7 +320,7 @@ rancher_kubernetes_engine_config: # Your RKE template config goes here.
ssh_agent_auth: false
windows_prefered_cluster: false
```
{{% /accordion %}}
</details>
### Default DNS provider
docs/en/cluster-provisioning/rke-clusters/cloud-providers/azure/azure.md
+29 -27
View File
@@ -31,7 +31,7 @@ Visit [Azure portal](https://portal.azure.com), login and go to **Azure Active D
If you want to use the Azure CLI, you can run the command `az account show` to get the information.
### 2. Set up the Azure Client ID and Azure Client Secret
### 2. Set up the Azure Client ID and Azure Client Secret
Visit [Azure portal](https://portal.azure.com), login and follow the steps below to create an **App Registration** and the corresponding **Azure Client ID** (aadClientId) and **Azure Client Secret** (aadClientSecret).
@@ -75,36 +75,38 @@ Only hosts expected to be load balancer back ends need to be in this group.
1. Choose "Azure" from the Cloud Provider drop-down in the Cluster Configuration section.
1. * Supply the Cloud Provider Configuration. Note that Rancher will automatically create a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you will need to specify them before creating the cluster.
1. * Supply the Cloud Provider Configuration. Note that Rancher will automatically create a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you will need to specify them before creating the cluster.
* You can click on "Show Advanced" to see more of these automatically generated names and update them if
necessary. Your Cloud Provider Configuration **must** match the fields in the Machine Pools section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group.
necessary. Your Cloud Provider Configuration **must** match the fields in the Machine Pools section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group.
* An example is provided below. You will modify it as needed.
{{% accordion id="v2.6.0-cloud-provider-config-file" label="Example Cloud Provider Config" %}}
<details id="v2.6.0-cloud-provider-config-file">
<summary>Example Cloud Provider Config</summary>
```yaml
{
"cloud":"AzurePublicCloud",
"tenantId": "YOUR TENANTID HERE",
"aadClientId": "YOUR AADCLIENTID HERE",
"aadClientSecret": "YOUR AADCLIENTSECRET HERE",
"subscriptionId": "YOUR SUBSCRIPTIONID HERE",
"resourceGroup": "docker-machine",
"location": "westus",
"subnetName": "docker-machine",
"securityGroupName": "rancher-managed-KA4jV9V2",
"securityGroupResourceGroup": "docker-machine",
"vnetName": "docker-machine-vnet",
"vnetResourceGroup": "docker-machine",
"primaryAvailabilitySetName": "docker-machine",
"routeTableResourceGroup": "docker-machine",
"cloudProviderBackoff": false,
"useManagedIdentityExtension": false,
"useInstanceMetadata": true
}
```
</details>
```yaml
{
"cloud":"AzurePublicCloud",
"tenantId": "YOUR TENANTID HERE",
"aadClientId": "YOUR AADCLIENTID HERE",
"aadClientSecret": "YOUR AADCLIENTSECRET HERE",
"subscriptionId": "YOUR SUBSCRIPTIONID HERE",
"resourceGroup": "docker-machine",
"location": "westus",
"subnetName": "docker-machine",
"securityGroupName": "rancher-managed-KA4jV9V2",
"securityGroupResourceGroup": "docker-machine",
"vnetName": "docker-machine-vnet",
"vnetResourceGroup": "docker-machine",
"primaryAvailabilitySetName": "docker-machine",
"routeTableResourceGroup": "docker-machine",
"cloudProviderBackoff": false,
"useManagedIdentityExtension": false,
"useInstanceMetadata": true
}
```
{{% /accordion %}}
1. Under the **Cluster Configuration > Advanced** section, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`
1. Click the **Create** button to submit the form and create the cluster.
docs/en/deploy-across-clusters/fleet/fleet.md
+6 -6
View File
@@ -30,12 +30,12 @@ Follow the steps below to access Continuous Delivery in the Rancher UI:
1. Click **☰ > Continuous Delivery**.
1. Select your namespace at the top of the menu, noting the following:
- By default,`fleet-default` is selected which includes all downstream clusters that are registered through Rancher.
- You may switch to `fleet-local`, which only contains the `local` cluster, or you may create your own workspace to which you may assign and move clusters.
1. Select your namespace at the top of the menu, noting the following:
- By default,`fleet-default` is selected which includes all downstream clusters that are registered through Rancher.
- You may switch to `fleet-local`, which only contains the `local` cluster, or you may create your own workspace to which you may assign and move clusters.
- You can then manage clusters by clicking on **Clusters** on the left navigation bar.
1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace.
1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace.
1. Select your [git repository](https://fleet.rancher.io/gitrepo-add/) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-structure/). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar.
@@ -64,9 +64,9 @@ The Helm chart in the git repository must include its dependencies in the charts
# Troubleshooting
---
* **Known Issue:** clientSecretName and helmSecretName secrets for Fleet gitrepos are not included in the backup nor restore created by the [backup-restore-operator]({{<baseurl>}}/rancher/v2.6/en/backups/back-up-rancher/#1-install-the-rancher-backups-operator). We will update the community once a permanent solution is in place.
* **Known Issue:** clientSecretName and helmSecretName secrets for Fleet gitrepos are not included in the backup nor restore created by the [backup-restore-operator]({{<baseurl>}}/rancher/v2.6/en/backups/back-up-rancher/#1-install-the-rancher-backups-operator). We will update the community once a permanent solution is in place.
* **Temporary Workaround:** </br>
* **Temporary Workaround:** <br/>
By default, user-defined secrets are not backed up in Fleet. It is necessary to recreate secrets if performing a disaster recovery restore or migration of Rancher into a fresh cluster. To modify resourceSet to include extra resources you want to backup, refer to docs [here](https://github.com/rancher/backup-restore-operator#user-flow).
---
docs/en/installation/install-rancher-on-k8s/install-rancher-on-k8s.md
+3 -2
View File
@@ -129,7 +129,8 @@ New in v2.6.4, cert-manager versions 1.6.2 and 1.7.1 are compatible. We recommen
This step is only required to use certificates issued by Rancher's generated CA (`ingress.tls.source=rancher`) or to request Let's Encrypt issued certificates (`ingress.tls.source=letsEncrypt`).
{{% accordion id="cert-manager" label="Click to Expand" %}}
<details id="cert-manager">
<summary>Click to Expand</summary>
:::note Important:
@@ -167,7 +168,7 @@ cert-manager-cainjector-577f6d9fd7-tr77l 1/1 Running 0 2m
cert-manager-webhook-787858fcdb-nlzsq 1/1 Running 0 2m
```
{{% /accordion %}}
</details>
### 5. Install Rancher with Helm and Your Chosen Certificate Option
docs/en/installation/other-installation-methods/air-gap/install-rancher/docker-install-commands/docker-install-commands.md
+11 -8
View File
@@ -3,9 +3,9 @@ title: Docker Install Commands
weight: 1
---
The Docker installation is for Rancher users who want to test out Rancher.
The Docker installation is for Rancher users who want to test out Rancher.
Instead of running on a Kubernetes cluster, you install the Rancher server component on a single node using a `docker run` command. Since there is only one node and a single Docker container, if the node goes down, there is no copy of the etcd data available on other nodes and you will lose all the data of your Rancher server.
Instead of running on a Kubernetes cluster, you install the Rancher server component on a single node using a `docker run` command. Since there is only one node and a single Docker container, if the node goes down, there is no copy of the etcd data available on other nodes and you will lose all the data of your Rancher server.
The backup application can be used to migrate the Rancher server from a Docker install to a Kubernetes install using [these steps.]({{<baseurl>}}/rancher/v2.6/en/backups/migrating-rancher)
@@ -27,7 +27,8 @@ Choose from the following options:
### Option A: Default Self-Signed Certificate
{{% accordion id="option-a" label="Click to expand" %}}
<details id="option-a">
<summary>Click to expand</summary>
If you are installing Rancher in a development or testing environment where identity verification isn't a concern, install Rancher using the self-signed certificate that it generates. This installation option omits the hassle of generating a certificate yourself.
@@ -49,11 +50,12 @@ docker run -d --restart=unless-stopped \
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
```
{{% /accordion %}}
</details>
### Option B: Bring Your Own Certificate: Self-Signed
{{% accordion id="option-b" label="Click to expand" %}}
<details id="option-b">
<summary>Click to expand</summary>
In development or testing environments where your team will access your Rancher server, create a self-signed certificate for use with your install so that your team can verify they're connecting to your instance of Rancher.
@@ -91,11 +93,12 @@ docker run -d --restart=unless-stopped \
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
```
{{% /accordion %}}
</details>
### Option C: Bring Your Own Certificate: Signed by Recognized CA
{{% accordion id="option-c" label="Click to expand" %}}
<details id="option-c">
<summary>Click to expand</summary>
In development or testing environments where you're exposing an app publicly, use a certificate signed by a recognized CA so that your user base doesn't encounter security warnings.
@@ -135,7 +138,7 @@ docker run -d --restart=unless-stopped \
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
```
{{% /accordion %}}
</details>
docs/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
+4 -3
View File
@@ -69,7 +69,7 @@ When setting up the Rancher Helm template, there are several options in the Helm
| Chart Option | Chart Value | Description |
| ----------------------- | -------------------------------- | ---- |
| `certmanager.version` | "<version>" | Configure proper Rancher TLS issuer depending of running cert-manager version. |
| `certmanager.version` | `<version>` | Configure proper Rancher TLS issuer depending of running cert-manager version. |
| `systemDefaultRegistry` | `<REGISTRY.YOURDOMAIN.COM:PORT>` | Configure Rancher server to always pull from your private registry when provisioning clusters. |
| `useBundledSystemChart` | `true` | Configure Rancher server to use the packaged copy of Helm system charts. The [system charts](https://github.com/rancher/system-charts) repository contains all the catalog items required for features such as monitoring, logging, alerting and global DNS. These [Helm charts](https://github.com/rancher/system-charts) are located in GitHub, but since you are in an air gapped environment, using the charts that are bundled within Rancher is much easier than setting up a Git mirror. |
@@ -212,7 +212,8 @@ If you choose to use self-signed certificates in [B. Choose your SSL Configurati
### For Self-Signed Certificate Installs, Install Cert-manager
{{% accordion id="install-cert-manager" label="Click to expand" %}}
<details id="install-cert-manager">
<summary>Click to expand</summary>
If you are using self-signed certificates, install cert-manager:
@@ -237,7 +238,7 @@ kubectl apply -f cert-manager/cert-manager-crd.yaml
kubectl apply -R -f ./cert-manager
```
{{% /accordion %}}
</details>
### Install Rancher with kubectl
docs/en/installation/other-installation-methods/single-node-docker/single-node-rollbacks/single-node-rollbacks.md
+3 -4
View File
@@ -20,8 +20,7 @@ In this command, `<PRIOR_RANCHER_VERSION>` is the version of Rancher you were ru
Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the procedure below.
<sup>Terminal `docker ps` Command, Displaying Where to Find `<PRIOR_RANCHER_VERSION>` and `<RANCHER_CONTAINER_NAME>`</sup>
![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref-2.png)
<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;PRIOR_RANCHER_VERSION&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref-2.png)
| Placeholder | Example | Description |
| -------------------------- | -------------------------- | ------------------------------------------------------- |
@@ -81,9 +80,9 @@ Rolling back to a previous version of Rancher destroys any changes made to Ranch
rancher/rancher:<PRIOR_RANCHER_VERSION>
```
Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher)
:::danger
**_Do not_** stop the rollback after initiating it, even if the rollback process seems longer than expected. Stopping the rollback may result in database issues during future upgrades.
:::
docs/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
+24 -16
View File
@@ -41,7 +41,8 @@ docker ps
Write down or copy this information before starting the upgrade.
<sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;RANCHER_CONTAINER_TAG&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>
![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
| Placeholder | Example | Description |
@@ -83,7 +84,7 @@ During upgrade, you create a copy of the data from your current Rancher containe
# 2. Create a backup tarball
1. <a id="tarball"></a>From the data container that you just created (`rancher-data`), create a backup tarball (`rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz`).
1. <a id="tarball"></a>From the data container that you just created (<code>rancher-data</code>), create a backup tarball (<code>rancher-data-backup-&lt;RANCHER_VERSION&gt;-&lt;DATE&gt;.tar.gz</code>).
This tarball will serve as a rollback point if something goes wrong during upgrade. Use the following command, replacing each placeholder.
@@ -143,7 +144,8 @@ Select which option you had installed Rancher server
### Option A: Default Self-Signed Certificate
{{% accordion id="option-a" label="Click to expand" %}}
<details id="option-a">
<summary>Click to expand</summary>
If you have selected to use the Rancher generated self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container.
@@ -161,11 +163,12 @@ docker run -d --volumes-from rancher-data \
Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher)
{{% /accordion %}}
</details>
### Option B: Bring Your Own Certificate: Self-Signed
{{% accordion id="option-b" label="Click to expand" %}}
<details id="option-b">
<summary>Click to expand</summary>
If you have selected to bring your own self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificate that you had originally installed with.
@@ -196,11 +199,12 @@ docker run -d --volumes-from rancher-data \
Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher)
{{% /accordion %}}
</details>
### Option C: Bring Your Own Certificate: Signed by Recognized CA
{{% accordion id="option-c" label="Click to expand" %}}
<details id="option-c">
<summary>Click to expand</summary>
If you have selected to use a certificate signed by a recognized CA, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificates that you had originally installed with. Remember to include `--no-cacerts` as an argument to the container to disable the default CA certificate generated by Rancher.
@@ -229,11 +233,12 @@ docker run -d --volumes-from rancher-data \
```
Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher)
{{% /accordion %}}
</details>
### Option D: Let's Encrypt Certificate
{{% accordion id="option-d" label="Click to expand" %}}
<details id="option-d">
<summary>Click to expand</summary>
:::caution
@@ -266,7 +271,7 @@ docker run -d --volumes-from rancher-data \
Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher)
{{% /accordion %}}
</details>
</TabItem>
<TabItem value="Docker Air Gap Upgrade">
@@ -277,7 +282,8 @@ When starting the new Rancher server container, choose from the following option
### Option A: Default Self-Signed Certificate
{{% accordion id="option-a" label="Click to expand" %}}
<details id="option-a">
<summary>Click to expand</summary>
If you have selected to use the Rancher generated self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container.
@@ -297,11 +303,12 @@ Placeholder | Description
```
Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher)
{{% /accordion %}}
</details>
### Option B: Bring Your Own Certificate: Self-Signed
{{% accordion id="option-b" label="Click to expand" %}}
<details id="option-b">
<summary>Click to expand</summary>
If you have selected to bring your own self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificate that you had originally installed with.
@@ -332,11 +339,12 @@ docker run -d --restart=unless-stopped \
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
```
Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher)
{{% /accordion %}}
</details>
### Option C: Bring Your Own Certificate: Signed by Recognized CA
{{% accordion id="option-c" label="Click to expand" %}}
<details id="option-c">
<summary>Click to expand</summary>
If you have selected to use a certificate signed by a recognized CA, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificates that you had originally installed with.
@@ -373,7 +381,7 @@ docker run -d --volumes-from rancher-data \
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
```
privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher)
{{% /accordion %}}
</details>
</TabItem>
</Tabs>
docs/en/installation/requirements/ports/ports.md
+24 -16
View File
@@ -44,7 +44,8 @@ Rancher can be installed on any Kubernetes cluster. For Rancher installs on a K3
### Ports for Rancher Server Nodes on K3s
{{% accordion label="Click to expand" %}}
<details>
<summary>Click to expand</summary>
The K3s server needs port 6443 to be accessible by the nodes.
@@ -79,11 +80,12 @@ The following tables break down the port requirements for inbound and outbound t
| TCP | 2376 | Any node IP from a node created using Node driver | Docker daemon TLS port used by Docker Machine |
| TCP | 6443 | Hosted/Imported Kubernetes API | Kubernetes API server |
{{% /accordion %}}
</details>
### Ports for Rancher Server Nodes on RKE
{{% accordion label="Click to expand" %}}
<details>
<summary>Click to expand</summary>
Typically Rancher is installed on three RKE nodes that all have the etcd, control plane and worker roles.
@@ -124,11 +126,12 @@ The following tables break down the port requirements for inbound and outbound t
| TCP | 6443 | Hosted/Imported Kubernetes API | Kubernetes API server |
| TCP | Provider dependent | Port of the Kubernetes API endpoint in hosted cluster | Kubernetes API |
{{% /accordion %}}
</details>
### Ports for Rancher Server Nodes on RKE2
{{% accordion label="Click to expand" %}}
<details>
<summary>Click to expand</summary>
The RKE2 server needs port 6443 and 9345 to be accessible by other nodes in the cluster.
@@ -158,11 +161,12 @@ The VXLAN port on nodes should not be exposed to the world as it opens up your c
| HTTPS | 8443 | <ul><li>hosted/registered Kubernetes</li><li>any source that needs to be able to use the Rancher UI or API</li></ul> | Rancher agent, Rancher UI/API, kubectl. Not needed if you have LB doing TLS termination. |
Typically all outbound traffic is allowed.
{{% /accordion %}}
</details>
### Ports for Rancher Server in Docker
{{% accordion label="Click to expand" %}}
<details>
<summary>Click to expand</summary>
The following tables break down the port requirements for Rancher nodes, for inbound and outbound traffic:
@@ -182,7 +186,7 @@ The following tables break down the port requirements for Rancher nodes, for inb
| TCP | 2376 | Any node IP from a node created using a node driver | Docker daemon TLS port used by Docker Machine |
| TCP | 6443 | Hosted/Imported Kubernetes API | Kubernetes API server |
{{% /accordion %}}
</details>
# Downstream Kubernetes Cluster Nodes
@@ -204,7 +208,8 @@ If security isn't a large concern and you're okay with opening a few additional
### Ports for Rancher Launched Kubernetes Clusters using Node Pools
{{% accordion label="Click to expand" %}}
<details>
<summary>Click to expand</summary>
The following table depicts the port requirements for [Rancher Launched Kubernetes]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/) with nodes created in an [Infrastructure Provider]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/).
@@ -216,27 +221,29 @@ The required ports are automatically opened by Rancher during creation of cluste
{{< ports-iaas-nodes >}}
{{% /accordion %}}
</details>
### Ports for Rancher Launched Kubernetes Clusters using Custom Nodes
{{% accordion label="Click to expand" %}}
<details>
<summary>Click to expand</summary>
The following table depicts the port requirements for [Rancher Launched Kubernetes]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/) with [Custom Nodes]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/custom-nodes/).
{{< ports-custom-nodes >}}
{{% /accordion %}}
</details>
### Ports for Hosted Kubernetes Clusters
{{% accordion label="Click to expand" %}}
<details>
<summary>Click to expand</summary>
The following table depicts the port requirements for [hosted clusters]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/hosted-kubernetes-clusters).
{{< ports-imported-hosted >}}
{{% /accordion %}}
</details>
### Ports for Registered Clusters
@@ -246,13 +253,14 @@ Registered clusters were called imported clusters before Rancher v2.5.
:::
{{% accordion label="Click to expand" %}}
<details>
<summary>Click to expand</summary>
The following table depicts the port requirements for [registered clusters]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/registered-clusters/).
{{< ports-imported-hosted >}}
{{% /accordion %}}
</details>
# Other Port Considerations
docs/en/installation/resources/advanced/single-node-install-external-lb/single-node-install-external-lb.md
+9 -5
View File
@@ -42,7 +42,9 @@ See [Advanced Options](#advanced-options) below before continuing.
Choose from the following options:
{{% accordion id="option-a" label="Option A-Bring Your Own Certificate: Self-Signed" %}}
<details id="option-a">
<summary>Option A-Bring Your Own Certificate: Self-Signed</summary>
If you elect to use a self-signed certificate to encrypt communication, you must install the certificate on your load balancer (which you'll do later) and your Rancher container. Run the Docker command to deploy Rancher, pointing it toward your certificate.
:::note Prerequisites:
@@ -64,8 +66,10 @@ Create a self-signed certificate.
rancher/rancher:latest
```
{{% /accordion %}}
{{% accordion id="option-b" label="Option B-Bring Your Own Certificate: Signed by Recognized CA" %}}
</details>
<details id="option-b">
<summary>Option B-Bring Your Own Certificate: Signed by Recognized CA</summary>
If your cluster is public facing, it's best to use a certificate signed by a recognized CA.
:::note Prerequisites:
@@ -86,7 +90,7 @@ If you use a certificate signed by a recognized CA, installing your certificate
rancher/rancher:latest --no-cacerts
```
{{% /accordion %}}
</details>
## 3. Configure Load Balancer
@@ -216,7 +220,7 @@ As of Rancher v2.5, privileged access is [required.]({{<baseurl>}}/rancher/v2.6/
This layer 7 NGINX configuration is tested on NGINX version 1.13 (mainline) and 1.14 (stable).
:::note
:::note
This NGINX configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - TCP and UDP Load Balancer](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/).
docs/en/installation/resources/upgrading-cert-manager/upgrading-cert-manager.md
+10 -6
View File
@@ -28,7 +28,9 @@ In order to upgrade cert-manager, follow these instructions:
### Option A: Upgrade cert-manager with Internet Access
{{% accordion id="normal" label="Click to expand" %}}
<details id="normal">
<summary>Click to expand</summary>
1. [Back up existing resources](https://cert-manager.io/docs/tutorials/backup/) as a precaution
```plain
@@ -101,11 +103,12 @@ In order to upgrade cert-manager, follow these instructions:
kubectl apply -f cert-manager-backup.yaml
```
{{% /accordion %}}
</details>
### Option B: Upgrade cert-manager in an Air-Gapped Environment
{{% accordion id="airgap" label="Click to expand" %}}
<details id="airgap">
<summary>Click to expand</summary>
### Prerequisites
@@ -214,11 +217,12 @@ Before you can perform the upgrade, you must prepare your air gapped environment
kubectl apply -f cert-manager-backup.yaml
```
{{% /accordion %}}
</details>
### Option C: Upgrade cert-manager from Versions 1.5 and Below
{{% accordion id="normal" label="Click to expand" %}}
<details id="normal">
<summary>Click to expand</summary>
Previously, in order to upgrade cert-manager from an older version, an uninstall and reinstall of Rancher was recommended. Using the method below, you may upgrade cert-manager without those additional steps in order to better preserve your production environment:
@@ -239,7 +243,7 @@ Previously, in order to upgrade cert-manager from an older version, an uninstall
1. Upgrade Rancher normally with `helm upgrade`.
{{% /accordion %}}
</details>
### Verify the Deployment
docs/en/k8s-in-rancher/horizontal-pod-autoscaler/manage-hpa-with-kubectl/manage-hpa-with-kubectl.md
+17 -8
View File
@@ -64,7 +64,7 @@ spec:
```
Directive | Description
Directive | Description
---------|----------|
`apiVersion: autoscaling/v2beta1` | The version of the Kubernetes `autoscaling` API group in use. This example manifest uses the beta version, so scaling by CPU and memory is enabled. |
`name: hello-world` | Indicates that HPA is performing autoscaling for the `hello-word` deployment. |
@@ -76,7 +76,7 @@ Directive | Description
##### Configuring HPA to Scale Using Resource Metrics (CPU and Memory)
Clusters created in Rancher v2.0.7 and higher have all the requirements needed (metrics-server and Kubernetes cluster configuration) to use Horizontal Pod Autoscaler.
Clusters created in Rancher v2.0.7 and higher have all the requirements needed (metrics-server and Kubernetes cluster configuration) to use Horizontal Pod Autoscaler.
Run the following commands to check if metrics are available in your installation:
@@ -158,7 +158,10 @@ For HPA to use custom metrics from Prometheus, package [k8s-prometheus-adapter](
# kubectl logs prometheus-adapter-prometheus-adapter-568674d97f-hbzfx -n kube-system
```
Then review the log output to confirm the service is running.
{{% accordion id="prometheus-logs" label="Prometheus Adaptor Logs" %}}
<details id="prometheus-logs">
<summary>Prometheus Adaptor Logs</summary>
...
I0724 10:18:45.696679 1 round_trippers.go:436] GET https://10.43.0.1:443/api/v1/namespaces/default/pods?labelSelector=app%3Dhello-world 200 OK in 2 milliseconds
I0724 10:18:45.696695 1 round_trippers.go:442] Response Headers:
@@ -171,7 +174,7 @@ For HPA to use custom metrics from Prometheus, package [k8s-prometheus-adapter](
I0724 10:18:45.699939 1 wrap.go:42] GET /apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pods/%2A/fs_read?labelSelector=app%3Dhello-world: (12.431262ms) 200 [[kube-controller-manager/v1.10.1 (linux/amd64) kubernetes/d4ab475/system:serviceaccount:kube-system:horizontal-pod-autoscaler] 10.42.0.0:24268]
I0724 10:18:51.727845 1 request.go:836] Request Body: {"kind":"SubjectAccessReview","apiVersion":"authorization.k8s.io/v1beta1","metadata":{"creationTimestamp":null},"spec":{"nonResourceAttributes":{"path":"/","verb":"get"},"user":"system:anonymous","group":["system:unauthenticated"]},"status":{"allowed":false}}
...
{{% /accordion %}}
</details>
@@ -182,15 +185,21 @@ For HPA to use custom metrics from Prometheus, package [k8s-prometheus-adapter](
# kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1
```
If the API is accessible, you should receive output that's similar to what follows.
{{% accordion id="custom-metrics-api-response" label="API Response" %}}
<details id="custom-metrics-api-response">
<summary>API Response</summary>
{"kind":"APIResourceList","apiVersion":"v1","groupVersion":"custom.metrics.k8s.io/v1beta1","resources":[{"name":"pods/fs_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_rss","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_period","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_read","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_user","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/last_seen","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/tasks_state","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_quota","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/start_time_seconds","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_write","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_cache","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_working_set_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_udp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes_free","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time_weighted","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failures","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_swap","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_shares","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_swap_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_current","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failcnt","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_tcp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_max_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_reservation_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_load_average_10s","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_system","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]}]}
{{% /accordion %}}
</details>
- If you are accessing the cluster through Rancher, enter your Server URL in the kubectl config in the following format: `https://<RANCHER_URL>/k8s/clusters/<CLUSTER_ID>`. Add the suffix `/k8s/clusters/<CLUSTER_ID>` to API path.
```
# kubectl get --raw /k8s/clusters/<CLUSTER_ID>/apis/custom.metrics.k8s.io/v1beta1
```
If the API is accessible, you should receive output that's similar to what follows.
{{% accordion id="custom-metrics-api-response-rancher" label="API Response" %}}
<details id="custom-metrics-api-response-rancher">
<summary>API Response</summary>
{"kind":"APIResourceList","apiVersion":"v1","groupVersion":"custom.metrics.k8s.io/v1beta1","resources":[{"name":"pods/fs_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_rss","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_period","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_read","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_user","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/last_seen","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/tasks_state","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_quota","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/start_time_seconds","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_write","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_cache","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_working_set_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_udp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes_free","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time_weighted","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failures","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_swap","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_shares","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_swap_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_current","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failcnt","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_tcp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_max_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_reservation_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_load_average_10s","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_system","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]}]}
{{% /accordion %}}
</details>
docs/en/k8s-in-rancher/horizontal-pod-autoscaler/testing-hpa/testing-hpa.md
+498 -458
View File
@@ -9,58 +9,62 @@ For HPA to work correctly, service deployments should have resources request def
1. Configure `kubectl` to connect to your Kubernetes cluster.
2. Copy the `hello-world` deployment manifest below.
{{% accordion id="hello-world" label="Hello World Manifest" %}}
```
apiVersion: apps/v1beta2
kind: Deployment
metadata:
labels:
app: hello-world
name: hello-world
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: hello-world
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
type: RollingUpdate
template:
metadata:
labels:
app: hello-world
spec:
containers:
- image: rancher/hello-world
imagePullPolicy: Always
name: hello-world
resources:
requests:
cpu: 500m
memory: 64Mi
ports:
- containerPort: 80
protocol: TCP
restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
name: hello-world
namespace: default
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: hello-world
```
{{% /accordion %}}
1. Copy the `hello-world` deployment manifest below.
<details id="hello-world">
<summary>Hello World Manifest</summary>
```
apiVersion: apps/v1beta2
kind: Deployment
metadata:
labels:
app: hello-world
name: hello-world
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: hello-world
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
type: RollingUpdate
template:
metadata:
labels:
app: hello-world
spec:
containers:
- image: rancher/hello-world
imagePullPolicy: Always
name: hello-world
resources:
requests:
cpu: 500m
memory: 64Mi
ports:
- containerPort: 80
protocol: TCP
restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
name: hello-world
namespace: default
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: hello-world
```
</details>
1. Deploy it to your cluster.
@@ -69,423 +73,459 @@ spec:
```
1. Copy one of the HPAs below based on the metric type you're using:
{{% accordion id="service-deployment-resource-metrics" label="Hello World HPA: Resource Metrics" %}}
```
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
name: hello-world
namespace: default
spec:
scaleTargetRef:
apiVersion: extensions/v1beta1
kind: Deployment
name: hello-world
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
targetAverageUtilization: 50
- type: Resource
resource:
name: memory
targetAverageValue: 1000Mi
```
{{% /accordion %}}
{{% accordion id="service-deployment-custom-metrics" label="Hello World HPA: Custom Metrics" %}}
```
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
name: hello-world
namespace: default
spec:
scaleTargetRef:
apiVersion: extensions/v1beta1
kind: Deployment
name: hello-world
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
targetAverageUtilization: 50
- type: Resource
resource:
name: memory
targetAverageValue: 100Mi
- type: Pods
pods:
metricName: cpu_system
targetAverageValue: 20m
```
{{% /accordion %}}
<details id="service-deployment-resource-metrics">
<summary>Hello World HPA: Resource Metrics</summary>
```
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
name: hello-world
namespace: default
spec:
scaleTargetRef:
apiVersion: extensions/v1beta1
kind: Deployment
name: hello-world
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
targetAverageUtilization: 50
- type: Resource
resource:
name: memory
targetAverageValue: 1000Mi
```
</details>
<details id="service-deployment-custom-metrics">
<summary>Hello World HPA: Custom Metrics</summary>
```
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
name: hello-world
namespace: default
spec:
scaleTargetRef:
apiVersion: extensions/v1beta1
kind: Deployment
name: hello-world
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
targetAverageUtilization: 50
- type: Resource
resource:
name: memory
targetAverageValue: 100Mi
- type: Pods
pods:
metricName: cpu_system
targetAverageValue: 20m
```
</details>
1. View the HPA info and description. Confirm that metric data is shown.
{{% accordion id="hpa-info-resource-metrics" label="Resource Metrics" %}}
1. Enter the following commands.
```
# kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
hello-world Deployment/hello-world 1253376 / 100Mi, 0% / 50% 1 10 1 6m
# kubectl describe hpa
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Mon, 23 Jul 2018 20:21:16 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 1253376 / 100Mi
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True ReadyForNewScale the last scale time was sufficiently old as to warrant a new scale
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events: <none>
```
{{% /accordion %}}
{{% accordion id="hpa-info-custom-metrics" label="Custom Metrics" %}}
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive the output that follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:36:28 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 3514368 / 100Mi
"cpu_system" on pods: 0 / 20m
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True ReadyForNewScale the last scale time was sufficiently old as to warrant a new scale
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events: <none>
```
{{% /accordion %}}
<details id="hpa-info-resource-metrics">
<summary>Resource Metrics</summary>
1. Enter the following commands.
```
# kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
hello-world Deployment/hello-world 1253376 / 100Mi, 0% / 50% 1 10 1 6m
# kubectl describe hpa
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Mon, 23 Jul 2018 20:21:16 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 1253376 / 100Mi
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True ReadyForNewScale the last scale time was sufficiently old as to warrant a new scale
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events: <none>
```
</details>
<details id="hpa-info-custom-metrics">
<summary>Custom Metrics</summary>
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive the output that follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:36:28 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 3514368 / 100Mi
"cpu_system" on pods: 0 / 20m
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True ReadyForNewScale the last scale time was sufficiently old as to warrant a new scale
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events: <none>
```
</details>
1. Generate a load for the service to test that your pods autoscale as intended. You can use any load-testing tool (Hey, Gatling, etc.), but we're using [Hey](https://github.com/rakyll/hey).
1. Test that pod autoscaling works as intended.<br/><br/>
**To Test Autoscaling Using Resource Metrics:**
{{% accordion id="observe-upscale-2-pods-cpu" label="Upscale to 2 Pods: CPU Usage Up to Target" %}}
Use your load testing tool to scale up to two pods based on CPU Usage.
**To Test Autoscaling Using Resource Metrics:**
1. View your HPA.
```
# kubectl describe hpa
```
You should receive output similar to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Mon, 23 Jul 2018 22:22:04 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 10928128 / 100Mi
resource cpu on pods (as a percentage of request): 56% (280m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 2
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 13s horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
```
1. Enter the following command to confirm you've scaled to two pods.
```
# kubectl get pods
```
You should receive output similar to what follows:
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-k8ph2 1/1 Running 0 1m
hello-world-54764dfbf8-q6l4v 1/1 Running 0 3h
```
{{% /accordion %}}
{{% accordion id="observe-upscale-3-pods-cpu-cooldown" label="Upscale to 3 pods: CPU Usage Up to Target" %}}
Use your load testing tool to upscale to 3 pods based on CPU usage with `horizontal-pod-autoscaler-upscale-delay` set to 3 minutes.
<details id="observe-upscale-2-pods-cpu">
<summary>Upscale to 2 Pods: CPU Usage Up to Target</summary>
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Mon, 23 Jul 2018 22:22:04 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 9424896 / 100Mi
resource cpu on pods (as a percentage of request): 66% (333m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 3
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 4m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 16s horizontal-pod-autoscaler New size: 3; reason: cpu resource utilization (percentage of request) above target
```
2. Enter the following command to confirm three pods are running.
```
# kubectl get pods
```
You should receive output similar to what follows.
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-f46kh 0/1 Running 0 1m
hello-world-54764dfbf8-k8ph2 1/1 Running 0 5m
hello-world-54764dfbf8-q6l4v 1/1 Running 0 3h
```
{{% /accordion %}}
{{% accordion id="observe-downscale-1-pod" label="Downscale to 1 Pod: All Metrics Below Target" %}}
Use your load testing to scale down to 1 pod when all metrics are below target for `horizontal-pod-autoscaler-downscale-delay` (5 minutes by default).
Use your load testing tool to scale up to two pods based on CPU Usage.
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Mon, 23 Jul 2018 22:22:04 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 10070016 / 100Mi
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 1
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 10m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 6m horizontal-pod-autoscaler New size: 3; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 1s horizontal-pod-autoscaler New size: 1; reason: All metrics below target
```
{{% /accordion %}}
<br/>
**To Test Autoscaling Using Custom Metrics:**
{{% accordion id="custom-observe-upscale-2-pods-cpu" label="Upscale to 2 Pods: CPU Usage Up to Target" %}}
Use your load testing tool to upscale two pods based on CPU usage.
1. View your HPA.
```
# kubectl describe hpa
```
You should receive output similar to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Mon, 23 Jul 2018 22:22:04 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 10928128 / 100Mi
resource cpu on pods (as a percentage of request): 56% (280m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 2
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 13s horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
```
1. Enter the following command to confirm you've scaled to two pods.
```
# kubectl get pods
```
You should receive output similar to what follows:
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-k8ph2 1/1 Running 0 1m
hello-world-54764dfbf8-q6l4v 1/1 Running 0 3h
```
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 8159232 / 100Mi
"cpu_system" on pods: 7m / 20m
resource cpu on pods (as a percentage of request): 64% (321m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 2
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 16s horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
```
1. Enter the following command to confirm two pods are running.
```
# kubectl get pods
```
You should receive output similar to what follows.
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-5pfdr 1/1 Running 0 3s
hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
```
{{% /accordion %}}
{{% accordion id="observe-upscale-3-pods-cpu-cooldown-2" label="Upscale to 3 Pods: CPU Usage Up to Target" %}}
Use your load testing tool to scale up to three pods when the cpu_system usage limit is up to target.
</details>
<details id="observe-upscale-3-pods-cpu-cooldown">
<summary>Upscale to 3 pods: CPU Usage Up to Target</summary>
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows:
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 8374272 / 100Mi
"cpu_system" on pods: 27m / 20m
resource cpu on pods (as a percentage of request): 71% (357m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 3
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 3m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 3s horizontal-pod-autoscaler New size: 3; reason: pods metric cpu_system above target
```
1. Enter the following command to confirm three pods are running.
```
# kubectl get pods
```
You should receive output similar to what follows:
```
# kubectl get pods
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-5pfdr 1/1 Running 0 3m
hello-world-54764dfbf8-m2hrl 1/1 Running 0 1s
hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
```
{{% /accordion %}}
{{% accordion id="observe-upscale-4-pods" label="Upscale to 4 Pods: CPU Usage Up to Target" %}}
Use your load testing tool to upscale to four pods based on CPU usage. `horizontal-pod-autoscaler-upscale-delay` is set to three minutes by default.
Use your load testing tool to upscale to 3 pods based on CPU usage with `horizontal-pod-autoscaler-upscale-delay` set to 3 minutes.
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 8374272 / 100Mi
"cpu_system" on pods: 27m / 20m
resource cpu on pods (as a percentage of request): 71% (357m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 3
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 5m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 3m horizontal-pod-autoscaler New size: 3; reason: pods metric cpu_system above target
Normal SuccessfulRescale 4s horizontal-pod-autoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target
```
1. Enter the following command to confirm four pods are running.
```
# kubectl get pods
```
You should receive output similar to what follows.
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-2p9xb 1/1 Running 0 5m
hello-world-54764dfbf8-5pfdr 1/1 Running 0 2m
hello-world-54764dfbf8-m2hrl 1/1 Running 0 1s
hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
```
{{% /accordion %}}
{{% accordion id="custom-metrics-observe-downscale-1-pod" label="Downscale to 1 Pod: All Metrics Below Target" %}}
Use your load testing tool to scale down to one pod when all metrics below target for `horizontal-pod-autoscaler-downscale-delay`.
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive similar output to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 8101888 / 100Mi
"cpu_system" on pods: 8m / 20m
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 1
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 10m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 8m horizontal-pod-autoscaler New size: 3; reason: pods metric cpu_system above target
Normal SuccessfulRescale 5m horizontal-pod-autoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 13s horizontal-pod-autoscaler New size: 1; reason: All metrics below target
```
1. Enter the following command to confirm a single pods is running.
```
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Mon, 23 Jul 2018 22:22:04 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 9424896 / 100Mi
resource cpu on pods (as a percentage of request): 66% (333m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 3
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 4m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 16s horizontal-pod-autoscaler New size: 3; reason: cpu resource utilization (percentage of request) above target
```
2. Enter the following command to confirm three pods are running.
```
# kubectl get pods
```
You should receive output similar to what follows.
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
```
{{% /accordion %}}
```
You should receive output similar to what follows.
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-f46kh 0/1 Running 0 1m
hello-world-54764dfbf8-k8ph2 1/1 Running 0 5m
hello-world-54764dfbf8-q6l4v 1/1 Running 0 3h
```
</details>
<details id="observe-downscale-1-pod">
<summary>Downscale to 1 Pod: All Metrics Below Target</summary>
Use your load testing to scale down to 1 pod when all metrics are below target for `horizontal-pod-autoscaler-downscale-delay` (5 minutes by default).
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Mon, 23 Jul 2018 22:22:04 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 10070016 / 100Mi
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 1
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 10m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 6m horizontal-pod-autoscaler New size: 3; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 1s horizontal-pod-autoscaler New size: 1; reason: All metrics below target
```
</details>
**To Test Autoscaling Using Custom Metrics:**
<details id="custom-observe-upscale-2-pods-cpu">
<summary>Upscale to 2 Pods: CPU Usage Up to Target</summary>
Use your load testing tool to upscale two pods based on CPU usage.
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 8159232 / 100Mi
"cpu_system" on pods: 7m / 20m
resource cpu on pods (as a percentage of request): 64% (321m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 2
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 16s horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
```
1. Enter the following command to confirm two pods are running.
```
# kubectl get pods
```
You should receive output similar to what follows.
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-5pfdr 1/1 Running 0 3s
hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
```
</details>
<details id="observe-upscale-3-pods-cpu-cooldown-2">
<summary>Upscale to 3 Pods: CPU Usage Up to Target</summary>
Use your load testing tool to scale up to three pods when the cpu_system usage limit is up to target.
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows:
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 8374272 / 100Mi
"cpu_system" on pods: 27m / 20m
resource cpu on pods (as a percentage of request): 71% (357m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 3
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 3m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 3s horizontal-pod-autoscaler New size: 3; reason: pods metric cpu_system above target
```
1. Enter the following command to confirm three pods are running.
```
# kubectl get pods
```
You should receive output similar to what follows:
```
# kubectl get pods
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-5pfdr 1/1 Running 0 3m
hello-world-54764dfbf8-m2hrl 1/1 Running 0 1s
hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
```
</details>
<details id="observe-upscale-4-pods">
<summary>Upscale to 4 Pods: CPU Usage Up to Target</summary>
Use your load testing tool to upscale to four pods based on CPU usage. `horizontal-pod-autoscaler-upscale-delay` is set to three minutes by default.
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 8374272 / 100Mi
"cpu_system" on pods: 27m / 20m
resource cpu on pods (as a percentage of request): 71% (357m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 3
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 5m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 3m horizontal-pod-autoscaler New size: 3; reason: pods metric cpu_system above target
Normal SuccessfulRescale 4s horizontal-pod-autoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target
```
1. Enter the following command to confirm four pods are running.
```
# kubectl get pods
```
You should receive output similar to what follows.
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-2p9xb 1/1 Running 0 5m
hello-world-54764dfbf8-5pfdr 1/1 Running 0 2m
hello-world-54764dfbf8-m2hrl 1/1 Running 0 1s
hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
```
</details>
<details id="custom-metrics-observe-downscale-1-pod">
<summary>Downscale to 1 Pod: All Metrics Below Target</summary>
Use your load testing tool to scale down to one pod when all metrics below target for `horizontal-pod-autoscaler-downscale-delay`.
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive similar output to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 8101888 / 100Mi
"cpu_system" on pods: 8m / 20m
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 1
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 10m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 8m horizontal-pod-autoscaler New size: 3; reason: pods metric cpu_system above target
Normal SuccessfulRescale 5m horizontal-pod-autoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 13s horizontal-pod-autoscaler New size: 1; reason: All metrics below target
```
1. Enter the following command to confirm a single pods is running.
```
# kubectl get pods
```
You should receive output similar to what follows.
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
```
</details>
docs/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/load-balancers.md
+1 -1
View File
@@ -59,7 +59,7 @@ Some cloud-managed layer-7 load balancers (such as the ALB ingress controller on
Other layer-7 load balancers, such as the Google Load Balancer or Nginx Ingress Controller, directly expose one or more IP addresses. Google Load Balancer provides a single routable IP address. Nginx Ingress Controller exposes the external IP of all nodes that run the Nginx Ingress Controller. You can do either of the following:
1. Configure your own DNS to map (via A records) your domain name to the IP addresses exposes by the Layer-7 load balancer.
2. Ask Rancher to generate an xip.io host name for your ingress rule. Rancher will take one of your exposed IPs, say a.b.c.d, and generate a host name <ingressname>.<namespace>.a.b.c.d.xip.io.
2. Ask Rancher to generate an xip.io host name for your ingress rule. Rancher will take one of your exposed IPs, say `a.b.c.d`, and generate a host name `<ingressname>.<namespace>.a.b.c.d.xip.io`.
The benefit of using xip.io is that you obtain a working entrypoint URL immediately after you create the ingress rule. Setting up your own domain name, on the other hand, requires you to configure DNS servers and wait for DNS to propagate.
docs/en/monitoring-alerting/expression/expression.md
+8 -8
View File
@@ -111,15 +111,15 @@ For more information about querying the Prometheus time series database, refer t
| Catalog | Expression |
| --- | --- |
| Detail | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr></table> |
| Summary | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr></table> |
| Detail | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr></table> |
| Summary | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr></table> |
### Cluster Network I/O
| Catalog | Expression |
| --- | --- |
| Detail | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr></table> |
| Summary | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr></table> |
| Detail | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr></table> |
| Summary | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr></table> |
# Node Metrics
@@ -162,15 +162,15 @@ For more information about querying the Prometheus time series database, refer t
| Catalog | Expression |
| --- | --- |
| Detail | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr></table> |
| Summary | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr></table> |
| Detail | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr></table> |
| Summary | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr></table> |
### Node Network I/O
| Catalog | Expression |
| --- | --- |
| Detail | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr></table> |
| Summary | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr></table> |
| Detail | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr></table> |
| Summary | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr></table> |
# Etcd Metrics
docs/en/monitoring-alerting/how-monitoring-works/how-monitoring-works.md
+6 -6
View File
@@ -32,18 +32,18 @@ ServiceMonitors and PodMonitors declaratively specify targets, such as Services
- Certain internal Kubernetes components are scraped via a proxy deployed as part of Monitoring V2 called **PushProx**. The Kubernetes components that expose metrics to Prometheus through PushProx are the following:
`kube-controller-manager`, `kube-scheduler`, `etcd`, and `kube-proxy`.
- For each PushProx exporter, we deploy one PushProx client onto all target nodes. For example, a PushProx client is deployed onto all controlplane nodes for kube-controller-manager, all etcd nodes for kube-etcd, and all nodes for kubelet.
- For each PushProx exporter, we deploy one PushProx client onto all target nodes. For example, a PushProx client is deployed onto all controlplane nodes for kube-controller-manager, all etcd nodes for kube-etcd, and all nodes for kubelet.
- We deploy exactly one PushProx proxy per exporter. The process for exporting metrics is as follows:
1. The PushProx Client establishes an outbound connection with the PushProx Proxy.
1. The PushProx Client establishes an outbound connection with the PushProx Proxy.
1. The client then polls the proxy for scrape requests that have come into the proxy.
1. When the proxy receives a scrape request from Prometheus, the client sees it as a result of the poll.
1. The client scrapes the internal component.
1. The internal component responds by pushing metrics back to the proxy.
<figcaption><br>Process for Exporting Metrics with PushProx:</br></figcaption>
<figcaption><br/>Process for Exporting Metrics with PushProx:<br/></figcaption>
![Process for Exporting Metrics with PushProx]({{<baseurl>}}/img/rancher/pushprox-process.svg)
@@ -126,7 +126,7 @@ The Alertmanager handles alerts sent by client applications such as the Promethe
### Alerts Forwarded by alertingDrivers
When alertingDrivers are installed, this creates a `Service` that can be used as the receiver's URL for Teams or SMS, based on the alertingDriver's configuration. The URL in the Receiver points to the alertingDrivers; so the Alertmanager sends alert first to alertingDriver, then alertingDriver forwards or sends alert to the proper destination.
### Routing Alerts to Receivers
Alertmanager coordinates where alerts are sent. It allows you to group alerts based on labels and fire them based on whether certain labels are matched. One top-level route accepts all alerts. From there, Alertmanager continues routing alerts to receivers based on whether they match the conditions of the next route.
docs/en/security/hardening-guides/rke-1.6-benchmark-2.6/rke-1.6-benchmark-2.6.md
+23 -23
View File
@@ -562,7 +562,7 @@ root 121142 121120 7 12:27 ? 00:06:27 kube-apiserver --audit-log-maxsize=100 --e
**Remediation:**
Follow the documentation and configure alternate mechanisms for authentication. Then,
edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
on the master node and remove the --basic-auth-file=<filename> parameter.
on the master node and remove the `--basic-auth-file=<filename>` parameter.
**Audit:**
@@ -590,7 +590,7 @@ root 121142 121120 7 12:27 ? 00:06:27 kube-apiserver --audit-log-maxsize=100 --e
**Remediation:**
Follow the documentation and configure alternate mechanisms for authentication. Then,
edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
on the master node and remove the --token-auth-file=<filename> parameter.
on the master node and remove the `--token-auth-file=<filename>` parameter.
**Audit:**
@@ -677,8 +677,8 @@ root 121142 121120 7 12:27 ? 00:06:27 kube-apiserver --audit-log-maxsize=100 --e
Follow the Kubernetes documentation and setup the TLS connection between
the apiserver and kubelets. Then, edit the API server pod specification file
/etc/kubernetes/manifests/kube-apiserver.yaml on the master node and set the
--kubelet-certificate-authority parameter to the path to the cert file for the certificate authority.
--kubelet-certificate-authority=<ca-string>
`--kubelet-certificate-authority` parameter to the path to the cert file for the certificate authority.
`--kubelet-certificate-authority=<ca-string>`
**Audit:**
@@ -1288,7 +1288,7 @@ root 121142 121120 7 12:27 ? 00:06:28 kube-apiserver --audit-log-maxsize=100 --e
Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
on the master node and set the --service-account-key-file parameter
to the public key file for service accounts:
--service-account-key-file=<filename>
`--service-account-key-file=<filename>`
**Audit:**
@@ -1317,8 +1317,8 @@ root 121142 121120 7 12:27 ? 00:06:28 kube-apiserver --audit-log-maxsize=100 --e
Follow the Kubernetes documentation and set up the TLS connection between the apiserver and etcd.
Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
on the master node and set the etcd certificate and key file parameters.
--etcd-certfile=<path/to/client-certificate-file>
--etcd-keyfile=<path/to/client-key-file>
`--etcd-certfile=<path/to/client-certificate-file>`
`--etcd-keyfile=<path/to/client-key-file>`
**Audit:**
@@ -1347,8 +1347,8 @@ root 121142 121120 7 12:27 ? 00:06:28 kube-apiserver --audit-log-maxsize=100 --e
Follow the Kubernetes documentation and set up the TLS connection on the apiserver.
Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
on the master node and set the TLS certificate and private key file parameters.
--tls-cert-file=<path/to/tls-certificate-file>
--tls-private-key-file=<path/to/tls-key-file>
`--tls-cert-file=<path/to/tls-certificate-file>`
`--tls-private-key-file=<path/to/tls-key-file>`
**Audit:**
@@ -1377,7 +1377,7 @@ root 121142 121120 7 12:27 ? 00:06:28 kube-apiserver --audit-log-maxsize=100 --e
Follow the Kubernetes documentation and set up the TLS connection on the apiserver.
Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
on the master node and set the client certificate authority file.
--client-ca-file=<path/to/client-ca-file>
`--client-ca-file=<path/to/client-ca-file>`
**Audit:**
@@ -1406,7 +1406,7 @@ root 121142 121120 7 12:27 ? 00:06:28 kube-apiserver --audit-log-maxsize=100 --e
Follow the Kubernetes documentation and set up the TLS connection between the apiserver and etcd.
Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
on the master node and set the etcd certificate authority file parameter.
--etcd-cafile=<path/to/ca-file>
`--etcd-cafile=<path/to/ca-file>`
**Audit:**
@@ -1626,7 +1626,7 @@ root 121366 121346 1 12:27 ? 00:01:13 kube-controller-manager --cluster-cidr=10.
Edit the Controller Manager pod specification file /etc/kubernetes/manifests/kube-controller-manager.yaml
on the master node and set the --service-account-private-key-file parameter
to the private key file for service accounts.
--service-account-private-key-file=<filename>
`--service-account-private-key-file=<filename>`
**Audit:**
@@ -1654,7 +1654,7 @@ root 121366 121346 1 12:27 ? 00:01:13 kube-controller-manager --cluster-cidr=10.
**Remediation:**
Edit the Controller Manager pod specification file /etc/kubernetes/manifests/kube-controller-manager.yaml
on the master node and set the --root-ca-file parameter to the certificate bundle file`.
--root-ca-file=<path/to/file>
`--root-ca-file=<path/to/file>`
**Audit:**
@@ -1779,8 +1779,8 @@ root 121587 121567 0 12:27 ? 00:00:12 kube-scheduler --kubeconfig=/etc/kubernete
Follow the etcd service documentation and configure TLS encryption.
Then, edit the etcd pod specification file /etc/kubernetes/manifests/etcd.yaml
on the master node and set the below parameters.
--cert-file=</path/to/ca-file>
--key-file=</path/to/key-file>
`--cert-file=</path/to/ca-file>`
`--key-file=</path/to/key-file>`
**Audit:**
@@ -1866,8 +1866,8 @@ Follow the etcd service documentation and configure peer TLS encryption as appro
for your etcd cluster.
Then, edit the etcd pod specification file /etc/kubernetes/manifests/etcd.yaml on the
master node and set the below parameters.
--peer-client-file=</path/to/peer-cert-file>
--peer-key-file=</path/to/peer-key-file>
`--peer-client-file=</path/to/peer-cert-file>`
`--peer-key-file=</path/to/peer-key-file>`
**Audit:**
@@ -1954,7 +1954,7 @@ Follow the etcd documentation and create a dedicated certificate authority setup
etcd service.
Then, edit the etcd pod specification file /etc/kubernetes/manifests/etcd.yaml on the
master node and set the below parameter.
--trusted-ca-file=</path/to/ca-file>
`--trusted-ca-file=</path/to/ca-file>`
**Audit:**
@@ -2145,7 +2145,7 @@ root:root
**Remediation:**
Run the following command to modify the file permissions of the
--client-ca-file chmod 644 <filename>
`--client-ca-file chmod 644 <filename>`
**Audit Script:** `check_cafile_permissions.sh`
@@ -2177,7 +2177,7 @@ if test -e $CAFILE; then stat -c permissions=%a $CAFILE; fi
**Remediation:**
Run the following command to modify the ownership of the --client-ca-file.
chown root:root <filename>
`chown root:root <filename>`
**Audit Script:** `check_cafile_ownership.sh`
@@ -2305,7 +2305,7 @@ the location of the client CA file.
If using command line arguments, edit the kubelet service file
/etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
set the below parameter in KUBELET_AUTHZ_ARGS variable.
--client-ca-file=<path/to/client-ca-file>
`--client-ca-file=<path/to/client-ca-file>`
Based on your system, restart the kubelet service. For example:
systemctl daemon-reload
systemctl restart kubelet.service
@@ -2526,8 +2526,8 @@ to the location of the corresponding private key file.
If using command line arguments, edit the kubelet service file
/etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
set the below parameters in KUBELET_CERTIFICATE_ARGS variable.
--tls-cert-file=<path/to/tls-certificate-file>
--tls-private-key-file=<path/to/tls-key-file>
`--tls-cert-file=<path/to/tls-certificate-file>`
`--tls-private-key-file=<path/to/tls-key-file>`
Based on your system, restart the kubelet service. For example:
systemctl daemon-reload
systemctl restart kubelet.service
docs/en/security/hardening-guides/rke2-1.6-benchmark-2.6/rke2-1.6-benchmark-2.6.md
+25 -25
View File
@@ -754,7 +754,7 @@ on the master node and set the below parameter.
**Remediation:**
Follow the documentation and configure alternate mechanisms for authentication. Then,
edit the API server pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
on the master node and remove the --basic-auth-file=<filename> parameter.
on the master node and remove the `--basic-auth-file=<filename>` parameter.
**Audit:**
@@ -782,7 +782,7 @@ root 5275 5222 15 14:58 ? 00:01:26 kube-apiserver --audit-policy-file=/etc/ranch
**Remediation:**
Follow the documentation and configure alternate mechanisms for authentication. Then,
edit the API server pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
on the master node and remove the --token-auth-file=<filename> parameter.
on the master node and remove the `--token-auth-file=<filename>` parameter.
**Audit:**
@@ -869,8 +869,8 @@ root 5275 5222 15 14:58 ? 00:01:26 kube-apiserver --audit-policy-file=/etc/ranch
Follow the Kubernetes documentation and setup the TLS connection between
the apiserver and kubelets. Then, edit the API server pod specification file
/var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml on the master node and set the
--kubelet-certificate-authority parameter to the path to the cert file for the certificate authority.
--kubelet-certificate-authority=<ca-string>
`--kubelet-certificate-authority` parameter to the path to the cert file for the certificate authority.
`--kubelet-certificate-authority=<ca-string>`
**Audit:**
@@ -1468,7 +1468,7 @@ root 5275 5222 15 14:58 ? 00:01:26 kube-apiserver --audit-policy-file=/etc/ranch
Edit the API server pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
on the master node and set the --service-account-key-file parameter
to the public key file for service accounts:
--service-account-key-file=<filename>
`--service-account-key-file=<filename>`
**Audit:**
@@ -1497,8 +1497,8 @@ root 5275 5222 15 14:58 ? 00:01:26 kube-apiserver --audit-policy-file=/etc/ranch
Follow the Kubernetes documentation and set up the TLS connection between the apiserver and etcd.
Then, edit the API server pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
on the master node and set the etcd certificate and key file parameters.
--etcd-certfile=<path/to/client-certificate-file>
--etcd-keyfile=<path/to/client-key-file>
`--etcd-certfile=<path/to/client-certificate-file>`
`--etcd-keyfile=<path/to/client-key-file>`
**Audit:**
@@ -1527,8 +1527,8 @@ root 5275 5222 15 14:58 ? 00:01:26 kube-apiserver --audit-policy-file=/etc/ranch
Follow the Kubernetes documentation and set up the TLS connection on the apiserver.
Then, edit the API server pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
on the master node and set the TLS certificate and private key file parameters.
--tls-cert-file=<path/to/tls-certificate-file>
--tls-private-key-file=<path/to/tls-key-file>
`--tls-cert-file=<path/to/tls-certificate-file>`
`--tls-private-key-file=<path/to/tls-key-file>`
**Audit:**
@@ -1557,7 +1557,7 @@ root 5275 5222 15 14:58 ? 00:01:26 kube-apiserver --audit-policy-file=/etc/ranch
Follow the Kubernetes documentation and set up the TLS connection on the apiserver.
Then, edit the API server pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
on the master node and set the client certificate authority file.
--client-ca-file=<path/to/client-ca-file>
`--client-ca-file=<path/to/client-ca-file>`
**Audit:**
@@ -1586,7 +1586,7 @@ root 5275 5222 15 14:58 ? 00:01:26 kube-apiserver --audit-policy-file=/etc/ranch
Follow the Kubernetes documentation and set up the TLS connection between the apiserver and etcd.
Then, edit the API server pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
on the master node and set the etcd certificate authority file parameter.
--etcd-cafile=<path/to/ca-file>
`--etcd-cafile=<path/to/ca-file>`
**Audit:**
@@ -1787,7 +1787,7 @@ root 5522 5416 3 14:58 ? 00:00:16 kube-controller-manager --flex-volume-plugin-d
Edit the Controller Manager pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-controller-manager.yaml
on the master node and set the --service-account-private-key-file parameter
to the private key file for service accounts.
--service-account-private-key-file=<filename>
`--service-account-private-key-file=<filename>`
**Audit:**
@@ -1815,7 +1815,7 @@ root 5522 5416 3 14:58 ? 00:00:16 kube-controller-manager --flex-volume-plugin-d
**Remediation:**
Edit the Controller Manager pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-controller-manager.yaml
on the master node and set the --root-ca-file parameter to the certificate bundle file`.
--root-ca-file=<path/to/file>
`--root-ca-file=<path/to/file>`
**Audit:**
@@ -1938,8 +1938,8 @@ root 5533 5414 0 14:58 ? 00:00:02 kube-scheduler --permit-port-sharing=true --ad
Follow the etcd service documentation and configure TLS encryption.
Then, edit the etcd pod specification file /etc/kubernetes/manifests/etcd.yaml
on the master node and set the below parameters.
--cert-file=</path/to/ca-file>
--key-file=</path/to/key-file>
`--cert-file=</path/to/ca-file>`
`--key-file=</path/to/key-file>`
### 2.2 Ensure that the --client-cert-auth argument is set to true (Automated)
@@ -1989,8 +1989,8 @@ Follow the etcd service documentation and configure peer TLS encryption as appro
for your etcd cluster.
Then, edit the etcd pod specification file /var/lib/rancher/rke2/agent/pod-manifests/etcd.yaml on the
master node and set the below parameters.
--peer-client-file=</path/to/peer-cert-file>
--peer-key-file=</path/to/peer-key-file>
`--peer-client-file=</path/to/peer-cert-file>`
`--peer-key-file=</path/to/peer-key-file>`
### 2.5 Ensure that the --peer-client-cert-auth argument is set to true (Automated)
@@ -2041,7 +2041,7 @@ Follow the etcd documentation and create a dedicated certificate authority setup
etcd service.
Then, edit the etcd pod specification file /var/lib/rancher/rke2/agent/pod-manifests/etcd.yaml on the
master node and set the below parameter.
--trusted-ca-file=</path/to/ca-file>
`--trusted-ca-file=</path/to/ca-file>`
**Audit:**
@@ -2258,7 +2258,7 @@ root:root
**Remediation:**
Run the following command to modify the file permissions of the
--client-ca-file chmod 644 <filename>
`--client-ca-file chmod 644 <filename>`
**Audit:**
@@ -2273,7 +2273,7 @@ stat -c %a /var/lib/rancher/rke2/server/tls/server-ca.crt
**Remediation:**
Run the following command to modify the ownership of the --client-ca-file.
chown root:roset: trueot <filename>
`chown root:roset: trueot <filename>`
**Audit:**
@@ -2438,7 +2438,7 @@ the location of the client CA file.
If using command line arguments, edit the kubelet service file
/etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
set the below parameter in KUBELET_AUTHZ_ARGS variable.
--client-ca-file=<path/to/client-ca-file>
`--client-ca-file=<path/to/client-ca-file>`
Based on your system, restart the kubelet service. For example:
systemctl daemon-reload
systemctl restart kubelet.service
@@ -2693,8 +2693,8 @@ to the location of the corresponding private key file.
If using command line arguments, edit the kubelet service file
/etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
set the below parameters in KUBELET_CERTIFICATE_ARGS variable.
--tls-cert-file=<path/to/tls-certificate-file>
--tls-private-key-file=<path/to/tls-key-file>
`--tls-cert-file=<path/to/tls-certificate-file>`
`--tls-private-key-file=<path/to/tls-key-file>`
Based on your system, restart the kubelet service. For example:
systemctl daemon-reload
systemctl restart kubelet.service
@@ -2929,7 +2929,7 @@ echo "true"
**Audit Execution:**
```bash
./check_for_default_sa.sh
./check_for_default_sa.sh
```
**Expected Result**:
@@ -3228,7 +3228,7 @@ echo "true"
**Audit Execution:**
```bash
./check_for_rke2_network_policies.sh
./check_for_rke2_network_policies.sh
```
**Expected Result**:
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/cluster-project-roles.md
+10 -4
View File
@@ -164,14 +164,20 @@ You can change the cluster or project role(s) that are automatically assigned to
1. Find the custom or individual role that you want to use as default. Then edit the role by selecting **&#8942; > Edit**.
1. Enable the role as default.
{{% accordion id="cluster" label="For Clusters" %}}
<details id="cluster">
<summary>For Clusters</summary>
1. From **Cluster Creator Default**, choose **Yes: Default role for new cluster creation**.
1. Click **Save**.
{{% /accordion %}}
{{% accordion id="project" label="For Projects" %}}
</details>
<details id="project">
<summary>For Projects</summary>
1. From **Project Creator Default**, choose **Yes: Default role for new project creation**.
1. Click **Save**.
{{% /accordion %}}
</details>
1. If you want to remove a default role, edit the permission and select **No** from the default roles option.
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/backups/backup/docker-backups/docker-backups.md
+3 -2
View File
@@ -37,7 +37,8 @@ docker ps
Write down or copy this information before starting the [procedure below](#creating-a-backup).
<sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;RANCHER_CONTAINER_TAG&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>
![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
| Placeholder | Example | Description |
@@ -68,7 +69,7 @@ This procedure creates a backup that you can restore if Rancher encounters a dis
docker create --volumes-from <RANCHER_CONTAINER_NAME> --name rancher-data-<DATE> rancher/rancher:<RANCHER_CONTAINER_TAG>
```
1. <a id="tarball"></a>From the data container that you just created (`rancher-data-<DATE>`), create a backup tarball (`rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz`). Use the following command, replacing each placeholder.
1. <a id="tarball"></a>From the data container that you just created (<code>rancher-data-&lt;DATE&gt;</code>), create a backup tarball (<code>rancher-data-backup-&lt;RANCHER_VERSION&gt;-&lt;DATE&gt;.tar.gz</code>). Use the following command, replacing each placeholder.
```
docker run --volumes-from rancher-data-<DATE> -v $PWD:/backup:z busybox tar pzcvf /backup/rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz /var/lib/rancher
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/backups/restore/docker-restores/docker-restores.md
+2 -1
View File
@@ -25,7 +25,8 @@ In this command, `<RANCHER_CONTAINER_NAME>` and `<RANCHER_VERSION>-<DATE>` are e
Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the procedure below.
<sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;RANCHER_CONTAINER_TAG&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>
![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
| Placeholder | Example | Description |
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-admin/cluster-admin.md
+2 -2
View File
@@ -21,9 +21,9 @@ Alternatively, you can switch between projects and clusters directly in the navi
## Managing Clusters in Rancher
After clusters have been [provisioned into Rancher]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/), [cluster owners]({{<baseurl>}}/rancher/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) will need to manage these clusters. There are many different options of how to manage your cluster.
After clusters have been [provisioned into Rancher]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/), [cluster owners]({{<baseurl>}}/rancher/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) will need to manage these clusters. There are many different options of how to manage your cluster.
{{% include file="/rancher/v2.0-v2.4/en/cluster-provisioning/cluster-capabilities-table" %}}
{{% include file="/rancher/v2.0-v2.4/en/cluster-provisioning/cluster-capabilities-table</summary>
## Configuring Tools
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-admin/cluster-autoscaler/amazon/amazon.md
+11 -11
View File
@@ -5,7 +5,7 @@ weight: 1
This guide will show you how to install and use [Kubernetes cluster-autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/) on Rancher custom clusters using AWS EC2 Auto Scaling Groups.
We are going to install a Rancher RKE custom cluster with a fixed number of nodes with the etcd and controlplane roles, and a variable nodes with the worker role, managed by `cluster-autoscaler`.
We are going to install a Rancher RKE custom cluster with a fixed number of nodes with the etcd and controlplane roles, and a variable nodes with the worker role, managed by `cluster-autoscaler`.
- [Prerequisites](#prerequisites)
- [1. Create a Custom Cluster](#1-create-a-custom-cluster)
@@ -68,7 +68,7 @@ On AWS EC2, we should create a few objects to configure our system. We've define
}
```
2. Master group: Nodes that will be part of the Kubernetes etcd and/or control planes. This will be out of the ASG.
2. Master group: Nodes that will be part of the Kubernetes etcd and/or control planes. This will be out of the ASG.
* IAM profile: Required by the Kubernetes cloud_provider integration. Optionally, `AWS_ACCESS_KEY` and `AWS_SECRET_KEY` can be used instead [using-aws-credentials.](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#using-aws-credentials) This profile is called `K8sMasterProfile`.
```json
@@ -211,7 +211,7 @@ On AWS EC2, we should create a few objects to configure our system. We've define
* `kubernetes.io/cluster/<clusterID>: owned`
* `k8s.io/cluster-autoscaler/<clusterName>: true`
* `k8s.io/cluster-autoscaler/enabled: true`
* User data: `K8sWorkerUserData` Ubuntu 18.04(ami-0e11cbb34015ff725), installs docker and add worker node to the k8s cluster
* User data: `K8sWorkerUserData` Ubuntu 18.04(ami-0e11cbb34015ff725), installs docker and add worker node to the k8s cluster
```sh
#!/bin/bash -x
@@ -246,7 +246,7 @@ Once we've configured AWS, let's create VMs to bootstrap our cluster:
* master (etcd+controlplane): Depending your needs, deploy three master instances with proper size. More info is at [the recommendations for production-ready clusters.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/production/)
* IAM role: `K8sMasterRole`
* Security group: `K8sMasterSg`
* Tags:
* Tags:
* `kubernetes.io/cluster/<clusterID>: owned`
* User data: `K8sMasterUserData`
@@ -254,7 +254,7 @@ Once we've configured AWS, let's create VMs to bootstrap our cluster:
* Name: `K8sWorkerAsg`
* IAM role: `K8sWorkerRole`
* Security group: `K8sWorkerSg`
* Tags:
* Tags:
* `kubernetes.io/cluster/<clusterID>: owned`
* `k8s.io/cluster-autoscaler/<clusterName>: true`
* `k8s.io/cluster-autoscaler/enabled: true`
@@ -268,7 +268,7 @@ Once the VMs are deployed, you should have a Rancher custom cluster up and runni
### 4. Install Cluster-autoscaler
At this point, we should have rancher cluster up and running. We are going to install cluster-autoscaler on master nodes and `kube-system` namespace, following cluster-autoscaler recommendation.
At this point, we should have rancher cluster up and running. We are going to install cluster-autoscaler on master nodes and `kube-system` namespace, following cluster-autoscaler recommendation.
#### Parameters
@@ -296,9 +296,9 @@ This table shows cluster-autoscaler parameters for fine tuning:
|node-deletion-delay-timeout|"2m"|Maximum time CA waits for removing delay-deletion.cluster-autoscaler.kubernetes.io/ annotations before deleting the node|
|scan-interval|"10s"|How often cluster is reevaluated for scale up or down|
|max-nodes-total|0|Maximum number of nodes in all node groups. Cluster autoscaler will not grow the cluster beyond this number|
|cores-total|"0:320000"|Minimum and maximum number of cores in cluster, in the format <min>:<max>. Cluster autoscaler will not scale the cluster beyond these numbers|
|memory-total|"0:6400000"|Minimum and maximum number of gigabytes of memory in cluster, in the format <min>:<max>. Cluster autoscaler will not scale the cluster beyond these numbers|
cloud-provider|-|Cloud provider type|
|cores-total|"0:320000"|Minimum and maximum number of cores in cluster, in the format `<min>:<max>.` Cluster autoscaler will not scale the cluster beyond these numbers|
|memory-total|"0:6400000"|Minimum and maximum number of gigabytes of memory in cluster, in the format `<min>:<max>.` Cluster autoscaler will not scale the cluster beyond these numbers|
cloud-provider|-|Cloud provider type|
|max-bulk-soft-taint-count|10|Maximum number of nodes that can be tainted/untainted PreferNoSchedule at the same time. Set to 0 to turn off such tainting|
|max-bulk-soft-taint-time|"3s"|Maximum duration of tainting/untainting nodes as PreferNoSchedule at the same time|
|max-empty-bulk-delete|10|Maximum number of empty nodes that can be deleted at the same time|
@@ -307,7 +307,7 @@ cloud-provider|-|Cloud provider type|
|ok-total-unready-count|3|Number of allowed unready nodes, irrespective of max-total-unready-percentage|
|scale-up-from-zero|true|Should CA scale up when there 0 ready nodes|
|max-node-provision-time|"15m"|Maximum time CA waits for node to be provisioned|
|nodes|-|sets min,max size and other configuration data for a node group in a format accepted by cloud provider. Can be used multiple times. Format: <min>:<max>:<other...>|
|nodes|-|sets min,max size and other configuration data for a node group in a format accepted by cloud provider. Can be used multiple times. Format: `<min>:<max>:<other...>`|
|node-group-auto-discovery|-|One or more definition(s) of node group auto-discovery. A definition is expressed `<name of discoverer>:[<key>[=<value>]]`|
|estimator|-|"binpacking"|Type of resource estimator to be used in scale up. Available values: ["binpacking"]|
|expander|"random"|Type of node group expander to be used in scale up. Available values: `["random","most-pods","least-waste","price","priority"]`|
@@ -520,7 +520,7 @@ kubectl -n kube-system apply -f cluster-autoscaler-deployment.yaml
# Testing
At this point, we should have a cluster-scaler up and running in our Rancher custom cluster. Cluster-scale should manage `K8sWorkerAsg` ASG to scale up and down between 2 and 10 nodes, when one of the following conditions is true:
At this point, we should have a cluster-scaler up and running in our Rancher custom cluster. Cluster-scale should manage `K8sWorkerAsg` ASG to scale up and down between 2 and 10 nodes, when one of the following conditions is true:
* There are pods that failed to run in the cluster due to insufficient resources. In this case, the cluster is scaled up.
* There are nodes in the cluster that have been underutilized for an extended period of time and their pods can be placed on other existing nodes. In this case, the cluster is scaled down.
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-admin/editing-clusters/editing-clusters.md
+1 -1
View File
@@ -18,7 +18,7 @@ The options and settings available for an existing cluster change based on the m
The following table summarizes the options and settings available for each cluster type:
{{% include file="/rancher/v2.0-v2.4/en/cluster-provisioning/cluster-capabilities-table" %}}
{{% include file="/rancher/v2.0-v2.4/en/cluster-provisioning/cluster-capabilities-table</summary>
### Editing Clusters in the Rancher UI
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/cluster-provisioning.md
+1 -1
View File
@@ -28,7 +28,7 @@ This section covers the following topics:
The following table summarizes the options and settings available for each cluster type:
{{% include file="/rancher/v2.0-v2.4/en/cluster-provisioning/cluster-capabilities-table" %}}
{{% include file="/rancher/v2.0-v2.4/en/cluster-provisioning/cluster-capabilities-table</summary>
# Setting up Clusters in a Hosted Kubernetes Provider
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/hosted-kubernetes-clusters/eks/eks.md
+12 -8
View File
@@ -68,17 +68,17 @@ Use Rancher to set up and configure your Kubernetes cluster.
1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
1. Fill out the rest of the form. For help, refer to the [configuration reference.](#eks-cluster-configuration-reference)
1. Fill out the rest of the form. For help, refer to the [configuration reference.](#eks-cluster-configuration-reference)
1. Click **Create**.
**Result:**
**Result:**
Your cluster is created and assigned a state of **Provisioning.** Rancher is standing up your cluster.
You can access your cluster after its state is updated to **Active.**
**Active** clusters are assigned two Projects:
**Active** clusters are assigned two Projects:
- `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
@@ -139,7 +139,8 @@ Option | Description
If you choose to assign a public IP address to your cluster's worker nodes, you have the option of choosing between a VPC that's automatically generated by Rancher (i.e., **Standard: Rancher generated VPC and Subnet**), or a VPC that you've already created with AWS (i.e., **Custom: Choose from your existing VPC and Subnets**). Choose the option that best fits your use case.
{{% accordion id="yes" label="Click to expand" %}}
<details id="yes">
<summary>Click to expand</summary>
If you're using **Custom: Choose from your existing VPC and Subnets**:
@@ -152,10 +153,13 @@ If you're using **Custom: Choose from your existing VPC and Subnets**:
1. Click **Next: Select Subnets**. Then choose one of the **Subnets** that displays.
1. Click **Next: Select Security Group**.
{{% /accordion %}}
</details>
If your worker nodes have Private IPs only, you must also choose a **VPC & Subnet** that allow your instances to access the internet. This access is required so that your worker nodes can connect to the Kubernetes control plane.
{{% accordion id="no" label="Click to expand" %}}
<details id="no">
<summary>Click to expand</summary>
Follow the steps below.
>**Tip:** When using only private IP addresses, you can provide your nodes internet access by creating a VPC constructed with two subnets, a private set and a public set. The private set should have its route tables configured to point toward a NAT in the public set. For more information on routing traffic from private subnets, please see the [official AWS documentation](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html).
@@ -164,7 +168,7 @@ Follow the steps below.
1. Click **Next: Select Subnets**. Then choose one of the **Subnets** that displays.
{{% /accordion %}}
</details>
### Security Group
@@ -215,7 +219,7 @@ This [tutorial](https://aws.amazon.com/blogs/opensource/managing-eks-clusters-ra
Documented here is a minimum set of permissions necessary to use all functionality of the EKS driver in Rancher. Additional permissions are required for Rancher to provision the `Service Role` and `VPC` resources. Optionally these resources can be created **before** the cluster creation and will be selectable when defining the cluster configuration.
Resource | Description
Resource | Description
---------|------------
Service Role | The service role provides Kubernetes the permissions it requires to manage resources on your behalf. Rancher can create the service role with the following [Service Role Permissions]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/hosted-kubernetes-clusters/eks/#service-role-permissions).
VPC | Provides isolated network resources utilised by EKS and worker nodes. Rancher can create the VPC resources with the following [VPC Permissions]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/hosted-kubernetes-clusters/eks/#vpc-permissions).
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/vsphere/creating-credentials/creating-credentials.md
+3 -3
View File
@@ -11,10 +11,10 @@ The following table lists the permissions required for the vSphere user account:
| Privilege Group | Operations |
|:----------------------|:-----------------------------------------------------------------------|
| Datastore | AllocateSpace </br> Browse </br> FileManagement (Low level file operations) </br> UpdateVirtualMachineFiles </br> UpdateVirtualMachineMetadata |
| Datastore | AllocateSpace <br/> Browse <br/> FileManagement (Low level file operations) <br/> UpdateVirtualMachineFiles <br/> UpdateVirtualMachineMetadata |
| Network | Assign |
| Resource | AssignVMToPool |
| Virtual Machine | Config (All) </br> GuestOperations (All) </br> Interact (All) </br> Inventory (All) </br> Provisioning (All) |
| Virtual Machine | Config (All) <br/> GuestOperations (All) <br/> Interact (All) <br/> Inventory (All) <br/> Provisioning (All) |
The following steps create a role with the required privileges and then assign it to a new user in the vSphere console:
@@ -37,7 +37,7 @@ The following steps create a role with the required privileges and then assign i
7. Create a new Global Permission. Add the user you created earlier and assign it the role you created earlier. Click **OK**.
{{< img "/img/rancher/globalpermissionuser.png" "image" >}}
{{< img "/img/rancher/globalpermissionrole.png" "image" >}}
**Result:** You now have credentials that Rancher can use to manipulate vSphere resources.
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/rke-clusters/options/options.md
+8 -5
View File
@@ -59,7 +59,7 @@ Out of the box, Rancher is compatible with the following network providers:
- [Weave](https://github.com/weaveworks/weave) (Available as of v2.2.0)
**Notes on Canal:**
In v2.0.0 - v2.0.4 and v2.0.6, this was the default option for these clusters was Canal with network isolation. With the network isolation automatically enabled, it prevented any pod communication between [projects]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/projects-and-namespaces/).
As of v2.0.7, if you use Canal, you also have the option of using **Project Network Isolation**, which will enable or disable communication between pods in different [projects]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/projects-and-namespaces/).
@@ -169,7 +169,8 @@ The structure of the config file is different depending on your version of Ranch
RKE (Rancher Kubernetes Engine) is the tool that Rancher uses to provision Kubernetes clusters. Rancher's cluster config files used to have the same structure as [RKE config files,]({{<baseurl>}}/rke/latest/en/example-yamls/) but the structure changed so that in Rancher, RKE cluster config items are separated from non-RKE config items. Therefore, configuration for your cluster needs to be nested under the `rancher_kubernetes_engine_config` directive in the cluster config file. Cluster config files created with earlier versions of Rancher will need to be updated for this format. An example cluster config file is included below.
{{% accordion id="v2.3.0-cluster-config-file" label="Example Cluster Config File for Rancher v2.3.0+" %}}
<details id="v2.3.0-cluster-config-file">
<summary>Example Cluster Config File for Rancher v2.3.0+</summary>
```yaml
#
@@ -261,13 +262,15 @@ rancher_kubernetes_engine_config: # Your RKE template config goes here.
ssh_agent_auth: false
windows_prefered_cluster: false
```
{{% /accordion %}}
</details>
### Config File Structure in Rancher v2.0.0-v2.2.x
An example cluster config file is included below.
{{% accordion id="before-v2.3.0-cluster-config-file" label="Example Cluster Config File for Rancher v2.0.0-v2.2.x" %}}
<details id="before-v2.3.0-cluster-config-file">
<summary>Example Cluster Config File for Rancher v2.0.0-v2.2.x</summary>
```yaml
addon_job_timeout: 30
authentication:
@@ -344,7 +347,7 @@ services:
service_node_port_range: 30000-32767
ssh_agent_auth: false
```
{{% /accordion %}}
</details>
### Default DNS provider
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/faq/upgrades-to-2x/upgrades-to-2x.md
+10 -10
View File
@@ -13,25 +13,25 @@ This page contains frequently asked questions about the changes between Rancher
Rancher v2.x is a complete container management platform built 100% on Kubernetes leveraging its Custom Resource and Controller framework. All features are written as a CustomResourceDefinition (CRD) which extends the existing Kubernetes API and can leverage native features such as RBAC.
<br>
<br/>
**Do you plan to implement upstream Kubernetes, or continue to work on your own fork?**
We're still going to provide our distribution when you select the default option of having us create your Kubernetes cluster, but it will be very close to upstream.
<br>
<br/>
**Does this release mean that we need to re-train our support staff in Kubernetes?**
Yes. Rancher will offer the native Kubernetes functionality via `kubectl` but will also offer our own UI dashboard to allow you to deploy Kubernetes workload without having to understand the full complexity of Kubernetes. However, to fully leverage Kubernetes, we do recommend understanding Kubernetes. We do plan on improving our UX with subsequent releases to make Kubernetes easier to use.
<br>
<br/>
**Is a Rancher compose going to make a Kubernetes pod? Do we have to learn both now? We usually use the filesystem layer of files, not the UI.**
No. Unfortunately, the differences were enough such that we cannot support Rancher compose anymore in 2.x. We will be providing both a tool and guides to help with this migration.
<br>
<br/>
**If we use Kubernetes native YAML files for creating resources, should we expect that to work as expected, or do we need to use Rancher/Docker compose files to deploy infrastructure?**
@@ -43,7 +43,7 @@ Absolutely.
Cattle will not supported in v2.x as Rancher has been re-architected to be based on Kubernetes. You can, however, expect majority of Cattle features you use will exist and function similarly on Kubernetes. We will develop migration tools in Rancher v2.1 to help you transform your existing Rancher Compose files into Kubernetes YAML files.
<br>
<br/>
**Can I migrate existing Cattle workloads into Kubernetes?**
@@ -55,19 +55,19 @@ Yes. In the upcoming Rancher v2.1 release we will provide a tool to help transla
Yes. You can manage Kubernetes storage, networking, and its vast ecosystem of add-ons.
<br>
<br/>
**Are there changes to default roles available now or going forward? Will the Kubernetes alignment impact plans for roles/RBAC?**
The default roles will be expanded to accommodate the new Rancher 2.x features, and will also take advantage of the Kubernetes RBAC (Role-Based Access Control) capabilities to give you more flexibility.
<br>
<br/>
**Will there be any functions like network policies to separate a front-end container from a back-end container through some kind of firewall in v2.x?**
Yes. You can do so by leveraging Kubernetes' network policies.
<br>
<br/>
**What about the CLI? Will that work the same way with the same features?**
@@ -81,7 +81,7 @@ Starting with 2.0, the concept of an environment has now been changed to a Kuber
Kubernetes RKE Templates is on our roadmap for 2.x. Please refer to our Release Notes and documentation for all the features that we currently support.
<br>
<br/>
**Can you still add an existing host to an environment? (i.e. not provisioned directly from Rancher)**
@@ -93,7 +93,7 @@ Yes. We still provide you with the same way of executing our Rancher agents dire
Due to the technical difficulty in transforming a Docker container into a pod running Kubernetes, upgrading will require users to "replay" those workloads from v1.x into new v2.x environments. We plan to ship with a tool in v2.1 to translate existing Rancher Compose files into Kubernetes YAML files. You will then be able to deploy those workloads on the v2.x platform.
<br>
<br/>
**Is it possible to upgrade from Rancher v1.x to v2.x without any disruption to Cattle and Kubernetes clusters?**
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/helm-charts/creating-apps/creating-apps.md
+1 -1
View File
@@ -117,7 +117,7 @@ This reference contains variables that you can use in `questions.yml` nested und
| max_length | int | false | Max character length.|
| min | int | false | Min integer length. |
| max | int | false | Max integer length. |
| options | []string | false | Specify the options when the variable type is `enum`, for example: options:<br> - "ClusterIP" <br> - "NodePort" <br> - "LoadBalancer"|
| options | []string | false | Specify the options when the variable type is `enum`, for example: options:<br/> - "ClusterIP" <br/> - "NodePort" <br/> - "LoadBalancer"|
| valid_chars | string | false | Regular expression for input chars validation. |
| invalid_chars | string | false | Regular expression for invalid input chars validation.|
| subquestions | []subquestion | false| Add an array of subquestions.|
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/install-rancher-on-k8s/install-rancher-on-k8s.md
+3 -2
View File
@@ -103,7 +103,8 @@ There are three recommended options for the source of the certificate used for T
This step is only required to use certificates issued by Rancher's generated CA (`ingress.tls.source=rancher`) or to request Let's Encrypt issued certificates (`ingress.tls.source=letsEncrypt`).
{{% accordion id="cert-manager" label="Click to Expand" %}}
<details id="cert-manager">
<summary>Click to Expand</summary>
> **Important:** Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.11.0, please see our [upgrade documentation]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/options/upgrading-cert-manager/).
@@ -150,7 +151,7 @@ cert-manager-cainjector-577f6d9fd7-tr77l 1/1 Running 0 2m
cert-manager-webhook-787858fcdb-nlzsq 1/1 Running 0 2m
```
{{% /accordion %}}
</details>
### 6. Install Rancher with Helm and Your Chosen Certificate Option
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/helm2/helm2.md
+12 -8
View File
@@ -102,7 +102,8 @@ hostname: rancher.my.org
If you are also upgrading cert-manager to the latest version from a version older than 0.11.0, follow `Option B: Reinstalling Rancher`. Otherwise, follow `Option A: Upgrading Rancher`.
{{% accordion label="Option A: Upgrading Rancher" %}}
<details>
<summary>Option A: Upgrading Rancher</summary>
Upgrade Rancher to the latest version with all your settings.
@@ -113,9 +114,10 @@ helm upgrade --install rancher rancher-<CHART_REPO>/rancher \
--namespace cattle-system \
--set hostname=rancher.my.org
```
{{% /accordion %}}
</details>
{{% accordion label="Option B: Reinstalling Rancher chart" %}}
<details>
<summary>Option B: Reinstalling Rancher chart</summary>
If you are currently running the cert-manager whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, then you need to reinstall both Rancher and cert-manager due to the API change in cert-manager v0.11.
@@ -137,7 +139,7 @@ If you are currently running the cert-manager whose version is older than v0.11,
--set hostname=rancher.my.org
```
{{% /accordion %}}
</details>
</TabItem>
<TabItem value="Kubernetes Air Gap Upgrade">
@@ -153,7 +155,8 @@ If you are currently running the cert-manager whose version is older than v0.11,
`<REGISTRY.YOURDOMAIN.COM:PORT>` | The DNS name for your private registry.
`<CERTMANAGER_VERSION>` | Cert-manager version running on k8s cluster.
{{% accordion id="self-signed" label="Option A-Default Self-Signed Certificate" %}}
<details id="self-signed">
<summary>Option A-Default Self-Signed Certificate</summary>
```plain
helm template ./rancher-<VERSION>.tgz --output-dir . \
@@ -166,8 +169,9 @@ helm template ./rancher-<VERSION>.tgz --output-dir . \
--set useBundledSystemChart=true # Available as of v2.3.0, use the packaged Rancher system charts
```
{{% /accordion %}}
{{% accordion id="secret" label="Option B: Certificates From Files using Kubernetes Secrets" %}}
</details>
<details id="secret">
<summary>Option B: Certificates From Files using Kubernetes Secrets</summary>
```plain
helm template ./rancher-<VERSION>.tgz --output-dir . \
@@ -194,7 +198,7 @@ helm template ./rancher-<VERSION>.tgz --output-dir . \
--set useBundledSystemChart=true # Available as of v2.3.0, use the packaged Rancher system charts
```
{{% /accordion %}}
</details>
2. Copy the rendered manifest directories to a system with access to the Rancher server cluster and apply the rendered templates.
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
+19 -13
View File
@@ -68,7 +68,7 @@ When setting up the Rancher Helm template, there are several options in the Helm
| Chart Option | Chart Value | Description |
| ----------------------- | -------------------------------- | ---- |
| `certmanager.version` | "<version>" | Configure proper Rancher TLS issuer depending of running cert-manager version. |
| `certmanager.version` | `<version>` | Configure proper Rancher TLS issuer depending of running cert-manager version. |
| `systemDefaultRegistry` | `<REGISTRY.YOURDOMAIN.COM:PORT>` | Configure Rancher server to always pull from your private registry when provisioning clusters. |
| `useBundledSystemChart` | `true` | Configure Rancher server to use the packaged copy of Helm system charts. The [system charts](https://github.com/rancher/system-charts) repository contains all the catalog items required for features such as monitoring, logging, alerting and global DNS. These [Helm charts](https://github.com/rancher/system-charts) are located in GitHub, but since you are in an air gapped environment, using the charts that are bundled within Rancher is much easier than setting up a Git mirror. _Available as of v2.3.0_ |
@@ -76,7 +76,8 @@ Based on the choice your made in [B. Choose your SSL Configuration](#b-choose-yo
### Option A: Default Self-Signed Certificate
{{% accordion id="k8s-1" label="Click to expand" %}}
<details id="k8s-1">
<summary>Click to expand</summary>
By default, Rancher generates a CA and uses cert-manager to issue the certificate for access to the Rancher server interface.
@@ -131,11 +132,12 @@ By default, Rancher generates a CA and uses cert-manager to issue the certificat
**Optional**: To install a specific Rancher version, set the `rancherImageTag` value, example: `--set rancherImageTag=v2.3.6`
{{% /accordion %}}
</details>
### Option B: Certificates From Files using Kubernetes Secrets
{{% accordion id="k8s-2" label="Click to expand" %}}
<details id="k8s-2">
<summary>Click to expand</summary>
Create Kubernetes secrets from your own certificates for Rancher to use. The common name for the cert will need to match the `hostname` option in the command below, or the ingress controller will fail to provision the site for Rancher.
@@ -174,7 +176,7 @@ If you are using a Private CA signed cert, add `--set privateCA=true` following
Then refer to [Adding TLS Secrets]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/resources/encryption/tls-secrets/) to publish the certificate files so Rancher and the ingress controller can use them.
{{% /accordion %}}
</details>
# 4. Install Rancher
@@ -186,7 +188,8 @@ If you choose to use self-signed certificates in [B. Choose your SSL Configurati
### For Self-Signed Certificate Installs, Install Cert-manager
{{% accordion id="install-cert-manager" label="Click to expand" %}}
<details id="install-cert-manager">
<summary>Click to expand</summary>
If you are using self-signed certificates, install cert-manager:
@@ -208,7 +211,7 @@ kubectl apply -f cert-manager/cert-manager-crd.yaml
kubectl apply -R -f ./cert-manager
```
{{% /accordion %}}
</details>
### Install Rancher with kubectl
@@ -259,7 +262,8 @@ Choose from the following options:
### Option A: Default Self-Signed Certificate
{{% accordion id="option-a" label="Click to expand" %}}
<details id="option-a">
<summary>Click to expand</summary>
If you are installing Rancher in a development or testing environment where identity verification isn't a concern, install Rancher using the self-signed certificate that it generates. This installation option omits the hassle of generating a certificate yourself.
@@ -278,11 +282,12 @@ docker run -d --restart=unless-stopped \
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
```
{{% /accordion %}}
</details>
### Option B: Bring Your Own Certificate: Self-Signed
{{% accordion id="option-b" label="Click to expand" %}}
<details id="option-b">
<summary>Click to expand</summary>
In development or testing environments where your team will access your Rancher server, create a self-signed certificate for use with your install so that your team can verify they're connecting to your instance of Rancher.
@@ -316,11 +321,12 @@ docker run -d --restart=unless-stopped \
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
```
{{% /accordion %}}
</details>
### Option C: Bring Your Own Certificate: Signed by Recognized CA
{{% accordion id="option-c" label="Click to expand" %}}
<details id="option-c">
<summary>Click to expand</summary>
In development or testing environments where you're exposing an app publicly, use a certificate signed by a recognized CA so that your user base doesn't encounter security warnings.
@@ -349,7 +355,7 @@ docker run -d --restart=unless-stopped \
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
```
{{% /accordion %}}
</details>
If you are installing Rancher v2.3.0+, the installation is complete.
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-rollbacks/single-node-rollbacks.md
+2 -3
View File
@@ -23,8 +23,7 @@ In this command, `<PRIOR_RANCHER_VERSION>` is the version of Rancher you were ru
Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the procedure below.
<sup>Terminal `docker ps` Command, Displaying Where to Find `<PRIOR_RANCHER_VERSION>` and `<RANCHER_CONTAINER_NAME>`</sup>
![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref-2.png)
<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;PRIOR_RANCHER_VERSION&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref-2.png)
| Placeholder | Example | Description |
| -------------------------- | -------------------------- | ------------------------------------------------------- |
@@ -78,7 +77,7 @@ If you have issues upgrading Rancher, roll it back to its latest known healthy s
-p 80:80 -p 443:443 \
rancher/rancher:<PRIOR_RANCHER_VERSION>
```
>**Note:** _Do not_ stop the rollback after initiating it, even if the rollback process seems longer than expected. Stopping the rollback may result in database issues during future upgrades.
1. Wait a few moments and then open Rancher in a web browser. Confirm that the rollback succeeded and that your data is restored.
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
+24 -16
View File
@@ -41,7 +41,8 @@ docker ps
Write down or copy this information before starting the upgrade.
<sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;RANCHER_CONTAINER_TAG&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>
![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
| Placeholder | Example | Description |
@@ -83,7 +84,7 @@ During upgrade, you create a copy of the data from your current Rancher containe
# 2. Create a backup tarball
1. <a id="tarball"></a>From the data container that you just created (`rancher-data`), create a backup tarball (`rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz`).
1. <a id="tarball"></a>From the data container that you just created (<code>rancher-data</code>), create a backup tarball (<code>rancher-data-backup-&lt;RANCHER_VERSION&gt;-&lt;DATE&gt;.tar.gz</code>).
This tarball will serve as a rollback point if something goes wrong during upgrade. Use the following command, replacing each placeholder.
@@ -139,7 +140,8 @@ Select which option you had installed Rancher server
### Option A: Default Self-Signed Certificate
{{% accordion id="option-a" label="Click to expand" %}}
<details id="option-a">
<summary>Click to expand</summary>
If you have selected to use the Rancher generated self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container.
@@ -154,11 +156,12 @@ docker run -d --volumes-from rancher-data \
rancher/rancher:<RANCHER_VERSION_TAG>
```
{{% /accordion %}}
</details>
### Option B: Bring Your Own Certificate: Self-Signed
{{% accordion id="option-b" label="Click to expand" %}}
<details id="option-b">
<summary>Click to expand</summary>
If you have selected to bring your own self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificate that you had originally installed with.
@@ -183,11 +186,12 @@ docker run -d --volumes-from rancher-data \
```
{{% /accordion %}}
</details>
### Option C: Bring Your Own Certificate: Signed by Recognized CA
{{% accordion id="option-c" label="Click to expand" %}}
<details id="option-c">
<summary>Click to expand</summary>
If you have selected to use a certificate signed by a recognized CA, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificates that you had originally installed with. Remember to include `--no-cacerts` as an argument to the container to disable the default CA certificate generated by Rancher.
@@ -210,11 +214,12 @@ docker run -d --volumes-from rancher-data \
--no-cacerts
```
{{% /accordion %}}
</details>
### Option D: Let's Encrypt Certificate
{{% accordion id="option-d" label="Click to expand" %}}
<details id="option-d">
<summary>Click to expand</summary>
>**Remember:** Let's Encrypt provides rate limits for requesting new certificates. Therefore, limit how often you create or destroy the container. For more information, see [Let's Encrypt documentation on rate limits](https://letsencrypt.org/docs/rate-limits/).
@@ -238,7 +243,7 @@ docker run -d --volumes-from rancher-data \
--acme-domain <YOUR.DNS.NAME>
```
{{% /accordion %}}
</details>
</TabItem>
<TabItem value="Docker Air Gap Upgrade">
@@ -251,7 +256,8 @@ When starting the new Rancher server container, choose from the following option
### Option A: Default Self-Signed Certificate
{{% accordion id="option-a" label="Click to expand" %}}
<details id="option-a">
<summary>Click to expand</summary>
If you have selected to use the Rancher generated self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container.
@@ -269,11 +275,12 @@ Placeholder | Description
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
```
{{% /accordion %}}
</details>
### Option B: Bring Your Own Certificate: Self-Signed
{{% accordion id="option-b" label="Click to expand" %}}
<details id="option-b">
<summary>Click to expand</summary>
If you have selected to bring your own self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificate that you had originally installed with.
@@ -298,11 +305,12 @@ docker run -d --restart=unless-stopped \
-e CATTLE_SYSTEM_CATALOG=bundled \ #Available as of v2.3.0, use the packaged Rancher system charts
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
```
{{% /accordion %}}
</details>
### Option C: Bring Your Own Certificate: Signed by Recognized CA
{{% accordion id="option-c" label="Click to expand" %}}
<details id="option-c">
<summary>Click to expand</summary>
If you have selected to use a certificate signed by a recognized CA, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificates that you had originally installed with.
@@ -330,7 +338,7 @@ docker run -d --volumes-from rancher-data \
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
```
{{% /accordion %}}
</details>
</TabItem>
</Tabs>
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/requirements/ports/ports.md
+22 -15
View File
@@ -35,7 +35,8 @@ The port requirements differ based on the Rancher server architecture.
### Ports for Rancher Server Nodes on K3s
{{% accordion label="Click to expand" %}}
<details>
<summary>Click to expand</summary>
The K3s server needs port 6443 to be accessible by the nodes.
@@ -66,11 +67,12 @@ The following tables break down the port requirements for inbound and outbound t
| TCP | 2376 | Any node IP from a node created using Node driver | Docker daemon TLS port used by Docker Machine |
| TCP | 6443 | Hosted/Imported Kubernetes API | Kubernetes API server |
{{% /accordion %}}
</details>
### Ports for Rancher Server Nodes on RKE
{{% accordion label="Click to expand" %}}
<details>
<summary>Click to expand</summary>
Typically Rancher is installed on three RKE nodes that all have the etcd, control plane and worker roles.
@@ -110,11 +112,12 @@ The following tables break down the port requirements for inbound and outbound t
| TCP | 6443 | Hosted/Imported Kubernetes API | Kubernetes API server |
| TCP | Provider dependent | Port of the Kubernetes API endpoint in hosted cluster | Kubernetes API |
{{% /accordion %}}
</details>
### Ports for Rancher Server in Docker
{{% accordion label="Click to expand" %}}
<details>
<summary>Click to expand</summary>
The following tables break down the port requirements for Rancher nodes, for inbound and outbound traffic:
@@ -134,7 +137,7 @@ The following tables break down the port requirements for Rancher nodes, for inb
| TCP | 2376 | Any node IP from a node created using a node driver | Docker daemon TLS port used by Docker Machine |
| TCP | 6443 | Hosted/Imported Kubernetes API | Kubernetes API server |
{{% /accordion %}}
</details>
# Downstream Kubernetes Cluster Nodes
@@ -154,7 +157,8 @@ The following diagram depicts the ports that are opened for each [cluster type](
### Ports for Rancher Launched Kubernetes Clusters using Node Pools
{{% accordion label="Click to expand" %}}
<details>
<summary>Click to expand</summary>
The following table depicts the port requirements for [Rancher Launched Kubernetes]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/) with nodes created in an [Infrastructure Provider]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/).
@@ -163,38 +167,41 @@ The following table depicts the port requirements for [Rancher Launched Kubernet
{{< ports-iaas-nodes >}}
{{% /accordion %}}
</details>
### Ports for Rancher Launched Kubernetes Clusters using Custom Nodes
{{% accordion label="Click to expand" %}}
<details>
<summary>Click to expand</summary>
The following table depicts the port requirements for [Rancher Launched Kubernetes]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/) with [Custom Nodes]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/custom-nodes/).
{{< ports-custom-nodes >}}
{{% /accordion %}}
</details>
### Ports for Hosted Kubernetes Clusters
{{% accordion label="Click to expand" %}}
<details>
<summary>Click to expand</summary>
The following table depicts the port requirements for [hosted clusters]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/hosted-kubernetes-clusters).
{{< ports-imported-hosted >}}
{{% /accordion %}}
</details>
### Ports for Imported Clusters
{{% accordion label="Click to expand" %}}
<details>
<summary>Click to expand</summary>
The following table depicts the port requirements for [imported clusters]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/imported-clusters/).
{{< ports-imported-hosted >}}
{{% /accordion %}}
</details>
# Other Port Considerations
@@ -203,7 +210,7 @@ The following table depicts the port requirements for [imported clusters]({{<bas
These ports are typically opened on your Kubernetes nodes, regardless of what type of cluster it is.
{{% include file="/rancher/v2.0-v2.4/en/installation/requirements/ports/common-ports-table" %}}
{{% include file="/rancher/v2.0-v2.4/en/installation/requirements/ports/common-ports-table</summary>
----
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/requirements/requirements.md
+4 -2
View File
@@ -116,7 +116,9 @@ These requirements apply to a host with a [single-node]({{<baseurl>}}/rancher/v2
### CPU and Memory for Rancher before v2.4.0
{{% accordion label="Click to expand" %}}
<details>
<summary>Click to expand</summary>
These requirements apply to installing Rancher on an RKE Kubernetes cluster before Rancher v2.4.0:
| Deployment Size | Clusters | Nodes | vCPUs | RAM |
@@ -126,7 +128,7 @@ These requirements apply to installing Rancher on an RKE Kubernetes cluster befo
| Large | Up to 50 | Up to 500 | 8 | 32 GB |
| X-Large | Up to 100 | Up to 1000 | 32 | 128 GB |
| XX-Large | 100+ | 1000+ | [Contact Rancher](https://rancher.com/contact/) | [Contact Rancher](https://rancher.com/contact/) |
{{% /accordion %}}
</details>
### Disks
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/install-rancher/install-rancher.md
+21 -15
View File
@@ -61,8 +61,8 @@ When Rancher is installed on an air gapped Kubernetes cluster, there are two rec
| Configuration | Chart option | Description | Requires cert-manager |
| ------------------------------------------ | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- |
| Rancher Generated Self-Signed Certificates | `ingress.tls.source=rancher` | Use certificates issued by Rancher's generated CA (self signed)<br> This is the **default** and does not need to be added when rendering the Helm template. | yes |
| Certificates from Files | `ingress.tls.source=secret` | Use your own certificate files by creating Kubernetes Secret(s). <br> This option must be passed when rendering the Rancher Helm template. | no |
| Rancher Generated Self-Signed Certificates | `ingress.tls.source=rancher` | Use certificates issued by Rancher's generated CA (self signed)<br/> This is the **default** and does not need to be added when rendering the Helm template. | yes |
| Certificates from Files | `ingress.tls.source=secret` | Use your own certificate files by creating Kubernetes Secret(s). <br/> This option must be passed when rendering the Rancher Helm template. | no |
### C. Render the Rancher Helm Template
@@ -70,13 +70,14 @@ When setting up the Rancher Helm template, there are several options in the Helm
| Chart Option | Chart Value | Description |
| ----------------------- | -------------------------------- | ---- |
| `certmanager.version` | "<version>" | Configure proper Rancher TLS issuer depending of running cert-manager version. |
| `certmanager.version` | `<version>` | Configure proper Rancher TLS issuer depending of running cert-manager version. |
| `systemDefaultRegistry` | `<REGISTRY.YOURDOMAIN.COM:PORT>` | Configure Rancher server to always pull from your private registry when provisioning clusters. |
| `useBundledSystemChart` | `true` | Configure Rancher server to use the packaged copy of Helm system charts. The [system charts](https://github.com/rancher/system-charts) repository contains all the catalog items required for features such as monitoring, logging, alerting and global DNS. These [Helm charts](https://github.com/rancher/system-charts) are located in GitHub, but since you are in an air gapped environment, using the charts that are bundled within Rancher is much easier than setting up a Git mirror. _Available as of v2.3.0_ |
Based on the choice your made in [B. Choose your SSL Configuration](#b-choose-your-ssl-configuration), complete one of the procedures below.
{{% accordion id="self-signed" label="Option A-Default Self-Signed Certificate" %}}
<details id="self-signed">
<summary>Option A-Default Self-Signed Certificate</summary>
By default, Rancher generates a CA and uses cert-manager to issue the certificate for access to the Rancher server interface.
@@ -129,9 +130,10 @@ By default, Rancher generates a CA and uses cert-manager to issue the certificat
--set useBundledSystemChart=true # Available as of v2.3.0, use the packaged Rancher system charts
```
{{% /accordion %}}
</details>
{{% accordion id="secret" label="Option B: Certificates From Files using Kubernetes Secrets" %}}
<details id="secret">
<summary>Option B: Certificates From Files using Kubernetes Secrets</summary>
Create Kubernetes secrets from your own certificates for Rancher to use. The common name for the cert will need to match the `hostname` option in the command below, or the ingress controller will fail to provision the site for Rancher.
@@ -170,7 +172,7 @@ If you are using a Private CA signed cert, add `--set privateCA=true` following
Then refer to [Adding TLS Secrets]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/resources/tls-secrets/) to publish the certificate files so Rancher and the ingress controller can use them.
{{% /accordion %}}
</details>
### D. Install Rancher
@@ -180,7 +182,8 @@ Use `kubectl` to create namespaces and apply the rendered manifests.
If you choose to use self-signed certificates in [B. Choose your SSL Configuration](#b-choose-your-ssl-configuration), install cert-manager.
{{% accordion id="install-cert-manager" label="Self-Signed Certificate Installs - Install Cert-manager" %}}
<details id="install-cert-manager">
<summary>Self-Signed Certificate Installs - Install Cert-manager</summary>
If you are using self-signed certificates, install cert-manager:
@@ -202,7 +205,7 @@ kubectl apply -f cert-manager/cert-manager-crd.yaml
kubectl apply -R -f ./cert-manager
```
{{% /accordion %}}
</details>
Install Rancher:
@@ -246,7 +249,8 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher
Choose from the following options:
{{% accordion id="option-a" label="Option A-Default Self-Signed Certificate" %}}
<details id="option-a">
<summary>Option A-Default Self-Signed Certificate</summary>
If you are installing Rancher in a development or testing environment where identity verification isn't a concern, install Rancher using the self-signed certificate that it generates. This installation option omits the hassle of generating a certificate yourself.
@@ -265,8 +269,9 @@ docker run -d --restart=unless-stopped \
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
```
{{% /accordion %}}
{{% accordion id="option-b" label="Option B-Bring Your Own Certificate: Self-Signed" %}}
</details>
<details id="option-b">
<summary>Option B-Bring Your Own Certificate: Self-Signed</summary>
In development or testing environments where your team will access your Rancher server, create a self-signed certificate for use with your install so that your team can verify they're connecting to your instance of Rancher.
@@ -298,8 +303,9 @@ docker run -d --restart=unless-stopped \
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
```
{{% /accordion %}}
{{% accordion id="option-c" label="Option C-Bring Your Own Certificate: Signed by Recognized CA" %}}
</details>
<details id="option-c">
<summary>Option C-Bring Your Own Certificate: Signed by Recognized CA</summary>
In development or testing environments where you're exposing an app publicly, use a certificate signed by a recognized CA so that your user base doesn't encounter security warnings.
@@ -328,7 +334,7 @@ docker run -d --restart=unless-stopped \
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
```
{{% /accordion %}}
</details>
If you are installing Rancher v2.3.0+, the installation is complete.
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/populate-private-registry/populate-private-registry.md
+15 -13
View File
@@ -29,9 +29,9 @@ By default, we provide the steps of how to populate your private registry assumi
For Rancher servers that will only provision Linux clusters, these are the steps to populate your private registry.
A. Find the required assets for your Rancher version <br>
B. Collect all the required images <br>
C. Save the images to your workstation <br>
A. Find the required assets for your Rancher version <br/>
B. Collect all the required images <br/>
C. Save the images to your workstation <br/>
D. Populate the private registry
### Prerequisites
@@ -115,12 +115,13 @@ For Rancher servers that will provision Linux and Windows clusters, there are di
The Windows images need to be collected and pushed from a Windows server workstation.
A. Find the required assets for your Rancher version <br>
B. Save the images to your Windows Server workstation <br>
C. Prepare the Docker daemon <br>
A. Find the required assets for your Rancher version <br/>
B. Save the images to your Windows Server workstation <br/>
C. Prepare the Docker daemon <br/>
D. Populate the private registry
{{% accordion label="Collecting and Populating Windows Images into the Private Registry"%}}
<details>
<summary>Collecting and Populating Windows Images into the Private Registry"%}}
### Prerequisites
@@ -183,18 +184,19 @@ Move the images in the `rancher-windows-images.tar.gz` to your private registry
./rancher-load-images.ps1 --registry <REGISTRY.YOURDOMAIN.COM:PORT>
```
{{% /accordion %}}
</details>
### Linux Steps
The Linux images needs to be collected and pushed from a Linux host, but _must be done after_ populating the Windows images into the private registry. These step are different from the Linux only steps as the Linux images that are pushed will actually manifests that support Windows and Linux images.
A. Find the required assets for your Rancher version <br>
B. Collect all the required images <br>
C. Save the images to your Linux workstation <br>
A. Find the required assets for your Rancher version <br/>
B. Collect all the required images <br/>
C. Save the images to your Linux workstation <br/>
D. Populate the private registry
{{% accordion label="Collecting and Populating Linux Images into the Private Registry" %}}
<details>
<summary>Collecting and Populating Linux Images into the Private Registry</summary>
### Prerequisites
@@ -270,7 +272,7 @@ Move the images in the `rancher-images.tar.gz` to your private registry using th
--registry <REGISTRY.YOURDOMAIN.COM:PORT>
```
{{% /accordion %}}
</details>
</TabItem>
</Tabs>
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/helm2/rke-add-on/layer-4-lb/layer-4-lb.md
+6 -4
View File
@@ -220,7 +220,8 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher
Choose from the following options:
{{% accordion id="option-a" label="Option A—Bring Your Own Certificate: Self-Signed" %}}
<details id="option-a">
<summary>Option A—Bring Your Own Certificate: Self-Signed</summary>
>**Prerequisites:**
>Create a self-signed certificate.
@@ -272,9 +273,10 @@ Choose from the following options:
cacerts.pem: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNvRENDQVlnQ0NRRHVVWjZuMEZWeU16QU5CZ2txaGtpRzl3MEJBUXNGQURBU01SQXdEZ1lEVlFRRERBZDAKWlhOMExXTmhNQjRYRFRFNE1EVXdOakl4TURRd09Wb1hEVEU0TURjd05USXhNRFF3T1Zvd0VqRVFNQTRHQTFVRQpBd3dIZEdWemRDMWpZVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFNQmpBS3dQCndhRUhwQTdaRW1iWWczaTNYNlppVmtGZFJGckJlTmFYTHFPL2R0RUdmWktqYUF0Wm45R1VsckQxZUlUS3UzVHgKOWlGVlV4Mmo1Z0tyWmpwWitCUnFiZ1BNbk5hS1hocmRTdDRtUUN0VFFZdGRYMVFZS0pUbWF5NU45N3FoNTZtWQprMllKRkpOWVhHWlJabkdMUXJQNk04VHZramF0ZnZOdmJ0WmtkY2orYlY3aWhXanp2d2theHRUVjZlUGxuM2p5CnJUeXBBTDliYnlVcHlad3E2MWQvb0Q4VUtwZ2lZM1dOWmN1YnNvSjhxWlRsTnN6UjVadEFJV0tjSE5ZbE93d2oKaG41RE1tSFpwZ0ZGNW14TU52akxPRUc0S0ZRU3laYlV2QzlZRUhLZTUxbGVxa1lmQmtBZWpPY002TnlWQUh1dApuay9DMHpXcGdENkIwbkVDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFHTCtaNkRzK2R4WTZsU2VBClZHSkMvdzE1bHJ2ZXdia1YxN3hvcmlyNEMxVURJSXB6YXdCdFJRSGdSWXVtblVqOGo4T0hFWUFDUEthR3BTVUsKRDVuVWdzV0pMUUV0TDA2eTh6M3A0MDBrSlZFZW9xZlVnYjQrK1JLRVJrWmowWXR3NEN0WHhwOVMzVkd4NmNOQQozZVlqRnRQd2hoYWVEQmdma1hXQWtISXFDcEsrN3RYem9pRGpXbi8walI2VDcrSGlaNEZjZ1AzYnd3K3NjUDIyCjlDQVZ1ZFg4TWpEQ1hTcll0Y0ZINllBanlCSTJjbDhoSkJqa2E3aERpVC9DaFlEZlFFVFZDM3crQjBDYjF1NWcKdE03Z2NGcUw4OVdhMnp5UzdNdXk5bEthUDBvTXl1Ty82Tm1wNjNsVnRHeEZKSFh4WTN6M0lycGxlbTNZQThpTwpmbmlYZXc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
```
{{% /accordion %}}
</details>
{{% accordion id="option-b" label="Option B—Bring Your Own Certificate: Signed by Recognized CA" %}}
<details id="option-b">
<summary>Option B—Bring Your Own Certificate: Signed by Recognized CA</summary>
If you are using a Certificate Signed By A Recognized Certificate Authority, you will need to generate a base64 encoded string for the Certificate file and the Certificate Key file. Make sure that your certificate file includes all the intermediate certificates in the chain, the order of certificates in this case is first your own certificate, followed by the intermediates. Please refer to the documentation of your CSP (Certificate Service Provider) to see what intermediate certificate(s) need to be included.
@@ -301,7 +303,7 @@ data:
tls.key: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBdEY3WEN6TVZHaDF1aU5oWTBJZW50RVlpSVFmUUlLQkMvYUFzU3gxQUlsOWI0OUQ5ClhmanEzdWI3c3RCNnRsYTlqV09keDZkZzBnZDBCSVNCSWFlcHJWdkZNZzRTRXpjRE51aW0xZnh3aVkwZCtFRlUKTXVCc3NYZEV6V0k3ZEVvdUFjcVJjamZWL0J5WTZ4ZDdTRWhjSE5PZVdEZWI5TDFiK3hLd2k2M21uZ0lKQjdBeQpLSmRlYzhnbWlaNk4wcTV3ZXFEWDJ6QVgrbDVPTldTcG1mWUVhVHBDSnFMVTNtZFpCWWx5cnhMTytvemx0MGdLCktLbG81cGgzc05CcDFMUG5LOUMxc3MvbWZRek9EMDNzck1Xa21oTDcwQ0IxZmIydCtOWnRITW5BYmYwYkJETnoKTlNRcXU4T2cwaUxnOUVhd3l1dEF4U3BGdmhHUGMvd0dHMExWaXdJREFRQUJBb0lCQUJKYUErOHp4MVhjNEw0egpwUFd5bDdHVDRTMFRLbTNuWUdtRnZudjJBZXg5WDFBU2wzVFVPckZyTnZpK2xYMnYzYUZoSFZDUEN4N1RlMDVxClhPa2JzZnZkZG5iZFQ2RjgyMnJleVByRXNINk9TUnBWSzBmeDVaMDQwVnRFUDJCWm04eTYyNG1QZk1vbDdya2MKcm9Kd09rOEVpUHZZekpsZUd0bTAwUm1sRysyL2c0aWJsOTVmQXpyc1MvcGUyS3ZoN2NBVEtIcVh6MjlpUmZpbApiTGhBamQwcEVSMjNYU0hHR1ZqRmF3amNJK1c2L2RtbDZURDhrSzFGaUtldmJKTlREeVNXQnpPbXRTYUp1K01JCm9iUnVWWG4yZVNoamVGM1BYcHZRMWRhNXdBa0dJQWxOWjRHTG5QU2ZwVmJyU0plU3RrTGNzdEJheVlJS3BWZVgKSVVTTHM0RUNnWUVBMmNnZUE2WHh0TXdFNU5QWlNWdGhzbXRiYi9YYmtsSTdrWHlsdk5zZjFPdXRYVzkybVJneQpHcEhUQ0VubDB0Z1p3T081T1FLNjdFT3JUdDBRWStxMDJzZndwcmgwNFZEVGZhcW5QNTBxa3BmZEJLQWpmanEyCjFoZDZMd2hLeDRxSm9aelp2VkowV0lvR1ZLcjhJSjJOWGRTUVlUanZUZHhGczRTamdqNFFiaEVDZ1lFQTFBWUUKSEo3eVlza2EvS2V2OVVYbmVrSTRvMm5aYjJ1UVZXazRXSHlaY2NRN3VMQVhGY3lJcW5SZnoxczVzN3RMTzJCagozTFZNUVBzazFNY25oTTl4WE4vQ3ZDTys5b2t0RnNaMGJqWFh6NEJ5V2lFNHJPS1lhVEFwcDVsWlpUT3ZVMWNyCm05R3NwMWJoVDVZb2RaZ3IwUHQyYzR4U2krUVlEWnNFb2lFdzNkc0NnWUVBcVJLYWNweWZKSXlMZEJjZ0JycGkKQTRFalVLMWZsSjR3enNjbGFKUDVoM1NjZUFCejQzRU1YT0kvSXAwMFJsY3N6em83N3cyMmpud09mOEJSM0RBMwp6ZTRSWDIydWw4b0hGdldvdUZOTTNOZjNaNExuYXpVc0F0UGhNS2hRWGMrcEFBWGthUDJkZzZ0TU5PazFxaUNHCndvU212a1BVVE84b1ViRTB1NFZ4ZmZFQ2dZQUpPdDNROVNadUlIMFpSSitIV095enlOQTRaUEkvUkhwN0RXS1QKajVFS2Y5VnR1OVMxY1RyOTJLVVhITXlOUTNrSjg2OUZPMnMvWk85OGg5THptQ2hDTjhkOWN6enI5SnJPNUFMTApqWEtBcVFIUlpLTFgrK0ZRcXZVVlE3cTlpaHQyMEZPb3E5OE5SZDMzSGYxUzZUWDNHZ3RWQ21YSml6dDAxQ3ZHCmR4VnVnd0tCZ0M2Mlp0b0RLb3JyT2hvdTBPelprK2YwQS9rNDJBOENiL29VMGpwSzZtdmxEWmNYdUF1QVZTVXIKNXJCZjRVYmdVYndqa1ZWSFR6LzdDb1BWSjUvVUxJWk1Db1RUNFprNTZXWDk4ZE93Q3VTVFpZYnlBbDZNS1BBZApTZEpuVVIraEpnSVFDVGJ4K1dzYnh2d0FkbWErWUhtaVlPRzZhSklXMXdSd1VGOURLUEhHCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==
```
{{% /accordion %}}
</details>
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/helm2/rke-add-on/layer-7-lb/layer-7-lb.md
+8 -4
View File
@@ -169,7 +169,9 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher
Choose from the following options:
{{% accordion id="option-a" label="Option A—Bring Your Own Certificate: Self-Signed" %}}
<details id="option-a">
<summary>Option A—Bring Your Own Certificate: Self-Signed</summary>
>**Prerequisites:**
>Create a self-signed certificate.
>
@@ -193,10 +195,12 @@ After replacing the values, the file should look like the example below (the bas
data:
cacerts.pem: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNvRENDQVlnQ0NRRHVVWjZuMEZWeU16QU5CZ2txaGtpRzl3MEJBUXNGQURBU01SQXdEZ1lEVlFRRERBZDAKWlhOMExXTmhNQjRYRFRFNE1EVXdOakl4TURRd09Wb1hEVEU0TURjd05USXhNRFF3T1Zvd0VqRVFNQTRHQTFVRQpBd3dIZEdWemRDMWpZVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFNQmpBS3dQCndhRUhwQTdaRW1iWWczaTNYNlppVmtGZFJGckJlTmFYTHFPL2R0RUdmWktqYUF0Wm45R1VsckQxZUlUS3UzVHgKOWlGVlV4Mmo1Z0tyWmpwWitCUnFiZ1BNbk5hS1hocmRTdDRtUUN0VFFZdGRYMVFZS0pUbWF5NU45N3FoNTZtWQprMllKRkpOWVhHWlJabkdMUXJQNk04VHZramF0ZnZOdmJ0WmtkY2orYlY3aWhXanp2d2theHRUVjZlUGxuM2p5CnJUeXBBTDliYnlVcHlad3E2MWQvb0Q4VUtwZ2lZM1dOWmN1YnNvSjhxWlRsTnN6UjVadEFJV0tjSE5ZbE93d2oKaG41RE1tSFpwZ0ZGNW14TU52akxPRUc0S0ZRU3laYlV2QzlZRUhLZTUxbGVxa1lmQmtBZWpPY002TnlWQUh1dApuay9DMHpXcGdENkIwbkVDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFHTCtaNkRzK2R4WTZsU2VBClZHSkMvdzE1bHJ2ZXdia1YxN3hvcmlyNEMxVURJSXB6YXdCdFJRSGdSWXVtblVqOGo4T0hFWUFDUEthR3BTVUsKRDVuVWdzV0pMUUV0TDA2eTh6M3A0MDBrSlZFZW9xZlVnYjQrK1JLRVJrWmowWXR3NEN0WHhwOVMzVkd4NmNOQQozZVlqRnRQd2hoYWVEQmdma1hXQWtISXFDcEsrN3RYem9pRGpXbi8walI2VDcrSGlaNEZjZ1AzYnd3K3NjUDIyCjlDQVZ1ZFg4TWpEQ1hTcll0Y0ZINllBanlCSTJjbDhoSkJqa2E3aERpVC9DaFlEZlFFVFZDM3crQjBDYjF1NWcKdE03Z2NGcUw4OVdhMnp5UzdNdXk5bEthUDBvTXl1Ty82Tm1wNjNsVnRHeEZKSFh4WTN6M0lycGxlbTNZQThpTwpmbmlYZXc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
{{% /accordion %}}
{{% accordion id="option-b" label="Option B—Bring Your Own Certificate: Signed by Recognized CA" %}}
</details>
<details id="option-b">
<summary>Option B—Bring Your Own Certificate: Signed by Recognized CA</summary>
If you are using a Certificate Signed By A Recognized Certificate Authority, you don't need to perform any step in this part.
{{% /accordion %}}
</details>
## 8. Configure FQDN
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/rke-add-on/layer-4-lb/layer-4-lb.md
+6 -4
View File
@@ -218,7 +218,8 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher
Choose from the following options:
{{% accordion id="option-a" label="Option A—Bring Your Own Certificate: Self-Signed" %}}
<details id="option-a">
<summary>Option A—Bring Your Own Certificate: Self-Signed</summary>
>**Prerequisites:**
>Create a self-signed certificate.
@@ -270,9 +271,10 @@ Choose from the following options:
cacerts.pem: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNvRENDQVlnQ0NRRHVVWjZuMEZWeU16QU5CZ2txaGtpRzl3MEJBUXNGQURBU01SQXdEZ1lEVlFRRERBZDAKWlhOMExXTmhNQjRYRFRFNE1EVXdOakl4TURRd09Wb1hEVEU0TURjd05USXhNRFF3T1Zvd0VqRVFNQTRHQTFVRQpBd3dIZEdWemRDMWpZVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFNQmpBS3dQCndhRUhwQTdaRW1iWWczaTNYNlppVmtGZFJGckJlTmFYTHFPL2R0RUdmWktqYUF0Wm45R1VsckQxZUlUS3UzVHgKOWlGVlV4Mmo1Z0tyWmpwWitCUnFiZ1BNbk5hS1hocmRTdDRtUUN0VFFZdGRYMVFZS0pUbWF5NU45N3FoNTZtWQprMllKRkpOWVhHWlJabkdMUXJQNk04VHZramF0ZnZOdmJ0WmtkY2orYlY3aWhXanp2d2theHRUVjZlUGxuM2p5CnJUeXBBTDliYnlVcHlad3E2MWQvb0Q4VUtwZ2lZM1dOWmN1YnNvSjhxWlRsTnN6UjVadEFJV0tjSE5ZbE93d2oKaG41RE1tSFpwZ0ZGNW14TU52akxPRUc0S0ZRU3laYlV2QzlZRUhLZTUxbGVxa1lmQmtBZWpPY002TnlWQUh1dApuay9DMHpXcGdENkIwbkVDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFHTCtaNkRzK2R4WTZsU2VBClZHSkMvdzE1bHJ2ZXdia1YxN3hvcmlyNEMxVURJSXB6YXdCdFJRSGdSWXVtblVqOGo4T0hFWUFDUEthR3BTVUsKRDVuVWdzV0pMUUV0TDA2eTh6M3A0MDBrSlZFZW9xZlVnYjQrK1JLRVJrWmowWXR3NEN0WHhwOVMzVkd4NmNOQQozZVlqRnRQd2hoYWVEQmdma1hXQWtISXFDcEsrN3RYem9pRGpXbi8walI2VDcrSGlaNEZjZ1AzYnd3K3NjUDIyCjlDQVZ1ZFg4TWpEQ1hTcll0Y0ZINllBanlCSTJjbDhoSkJqa2E3aERpVC9DaFlEZlFFVFZDM3crQjBDYjF1NWcKdE03Z2NGcUw4OVdhMnp5UzdNdXk5bEthUDBvTXl1Ty82Tm1wNjNsVnRHeEZKSFh4WTN6M0lycGxlbTNZQThpTwpmbmlYZXc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
```
{{% /accordion %}}
</details>
{{% accordion id="option-b" label="Option B—Bring Your Own Certificate: Signed by Recognized CA" %}}
<details id="option-b">
<summary>Option B—Bring Your Own Certificate: Signed by Recognized CA</summary>
If you are using a Certificate Signed By A Recognized Certificate Authority, you will need to generate a base64 encoded string for the Certificate file and the Certificate Key file. Make sure that your certificate file includes all the intermediate certificates in the chain, the order of certificates in this case is first your own certificate, followed by the intermediates. Please refer to the documentation of your CSP (Certificate Service Provider) to see what intermediate certificate(s) need to be included.
@@ -299,7 +301,7 @@ data:
tls.key: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBdEY3WEN6TVZHaDF1aU5oWTBJZW50RVlpSVFmUUlLQkMvYUFzU3gxQUlsOWI0OUQ5ClhmanEzdWI3c3RCNnRsYTlqV09keDZkZzBnZDBCSVNCSWFlcHJWdkZNZzRTRXpjRE51aW0xZnh3aVkwZCtFRlUKTXVCc3NYZEV6V0k3ZEVvdUFjcVJjamZWL0J5WTZ4ZDdTRWhjSE5PZVdEZWI5TDFiK3hLd2k2M21uZ0lKQjdBeQpLSmRlYzhnbWlaNk4wcTV3ZXFEWDJ6QVgrbDVPTldTcG1mWUVhVHBDSnFMVTNtZFpCWWx5cnhMTytvemx0MGdLCktLbG81cGgzc05CcDFMUG5LOUMxc3MvbWZRek9EMDNzck1Xa21oTDcwQ0IxZmIydCtOWnRITW5BYmYwYkJETnoKTlNRcXU4T2cwaUxnOUVhd3l1dEF4U3BGdmhHUGMvd0dHMExWaXdJREFRQUJBb0lCQUJKYUErOHp4MVhjNEw0egpwUFd5bDdHVDRTMFRLbTNuWUdtRnZudjJBZXg5WDFBU2wzVFVPckZyTnZpK2xYMnYzYUZoSFZDUEN4N1RlMDVxClhPa2JzZnZkZG5iZFQ2RjgyMnJleVByRXNINk9TUnBWSzBmeDVaMDQwVnRFUDJCWm04eTYyNG1QZk1vbDdya2MKcm9Kd09rOEVpUHZZekpsZUd0bTAwUm1sRysyL2c0aWJsOTVmQXpyc1MvcGUyS3ZoN2NBVEtIcVh6MjlpUmZpbApiTGhBamQwcEVSMjNYU0hHR1ZqRmF3amNJK1c2L2RtbDZURDhrSzFGaUtldmJKTlREeVNXQnpPbXRTYUp1K01JCm9iUnVWWG4yZVNoamVGM1BYcHZRMWRhNXdBa0dJQWxOWjRHTG5QU2ZwVmJyU0plU3RrTGNzdEJheVlJS3BWZVgKSVVTTHM0RUNnWUVBMmNnZUE2WHh0TXdFNU5QWlNWdGhzbXRiYi9YYmtsSTdrWHlsdk5zZjFPdXRYVzkybVJneQpHcEhUQ0VubDB0Z1p3T081T1FLNjdFT3JUdDBRWStxMDJzZndwcmgwNFZEVGZhcW5QNTBxa3BmZEJLQWpmanEyCjFoZDZMd2hLeDRxSm9aelp2VkowV0lvR1ZLcjhJSjJOWGRTUVlUanZUZHhGczRTamdqNFFiaEVDZ1lFQTFBWUUKSEo3eVlza2EvS2V2OVVYbmVrSTRvMm5aYjJ1UVZXazRXSHlaY2NRN3VMQVhGY3lJcW5SZnoxczVzN3RMTzJCagozTFZNUVBzazFNY25oTTl4WE4vQ3ZDTys5b2t0RnNaMGJqWFh6NEJ5V2lFNHJPS1lhVEFwcDVsWlpUT3ZVMWNyCm05R3NwMWJoVDVZb2RaZ3IwUHQyYzR4U2krUVlEWnNFb2lFdzNkc0NnWUVBcVJLYWNweWZKSXlMZEJjZ0JycGkKQTRFalVLMWZsSjR3enNjbGFKUDVoM1NjZUFCejQzRU1YT0kvSXAwMFJsY3N6em83N3cyMmpud09mOEJSM0RBMwp6ZTRSWDIydWw4b0hGdldvdUZOTTNOZjNaNExuYXpVc0F0UGhNS2hRWGMrcEFBWGthUDJkZzZ0TU5PazFxaUNHCndvU212a1BVVE84b1ViRTB1NFZ4ZmZFQ2dZQUpPdDNROVNadUlIMFpSSitIV095enlOQTRaUEkvUkhwN0RXS1QKajVFS2Y5VnR1OVMxY1RyOTJLVVhITXlOUTNrSjg2OUZPMnMvWk85OGg5THptQ2hDTjhkOWN6enI5SnJPNUFMTApqWEtBcVFIUlpLTFgrK0ZRcXZVVlE3cTlpaHQyMEZPb3E5OE5SZDMzSGYxUzZUWDNHZ3RWQ21YSml6dDAxQ3ZHCmR4VnVnd0tCZ0M2Mlp0b0RLb3JyT2hvdTBPelprK2YwQS9rNDJBOENiL29VMGpwSzZtdmxEWmNYdUF1QVZTVXIKNXJCZjRVYmdVYndqa1ZWSFR6LzdDb1BWSjUvVUxJWk1Db1RUNFprNTZXWDk4ZE93Q3VTVFpZYnlBbDZNS1BBZApTZEpuVVIraEpnSVFDVGJ4K1dzYnh2d0FkbWErWUhtaVlPRzZhSklXMXdSd1VGOURLUEhHCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==
```
{{% /accordion %}}
</details>
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/rke-add-on/layer-7-lb/layer-7-lb.md
+9 -4
View File
@@ -166,7 +166,9 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher
Choose from the following options:
{{% accordion id="option-a" label="Option A—Bring Your Own Certificate: Self-Signed" %}}
<details id="option-a">
<summary>Option A—Bring Your Own Certificate: Self-Signed</summary>
>**Prerequisites:**
>Create a self-signed certificate.
>
@@ -190,10 +192,13 @@ After replacing the values, the file should look like the example below (the bas
data:
cacerts.pem: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNvRENDQVlnQ0NRRHVVWjZuMEZWeU16QU5CZ2txaGtpRzl3MEJBUXNGQURBU01SQXdEZ1lEVlFRRERBZDAKWlhOMExXTmhNQjRYRFRFNE1EVXdOakl4TURRd09Wb1hEVEU0TURjd05USXhNRFF3T1Zvd0VqRVFNQTRHQTFVRQpBd3dIZEdWemRDMWpZVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFNQmpBS3dQCndhRUhwQTdaRW1iWWczaTNYNlppVmtGZFJGckJlTmFYTHFPL2R0RUdmWktqYUF0Wm45R1VsckQxZUlUS3UzVHgKOWlGVlV4Mmo1Z0tyWmpwWitCUnFiZ1BNbk5hS1hocmRTdDRtUUN0VFFZdGRYMVFZS0pUbWF5NU45N3FoNTZtWQprMllKRkpOWVhHWlJabkdMUXJQNk04VHZramF0ZnZOdmJ0WmtkY2orYlY3aWhXanp2d2theHRUVjZlUGxuM2p5CnJUeXBBTDliYnlVcHlad3E2MWQvb0Q4VUtwZ2lZM1dOWmN1YnNvSjhxWlRsTnN6UjVadEFJV0tjSE5ZbE93d2oKaG41RE1tSFpwZ0ZGNW14TU52akxPRUc0S0ZRU3laYlV2QzlZRUhLZTUxbGVxa1lmQmtBZWpPY002TnlWQUh1dApuay9DMHpXcGdENkIwbkVDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFHTCtaNkRzK2R4WTZsU2VBClZHSkMvdzE1bHJ2ZXdia1YxN3hvcmlyNEMxVURJSXB6YXdCdFJRSGdSWXVtblVqOGo4T0hFWUFDUEthR3BTVUsKRDVuVWdzV0pMUUV0TDA2eTh6M3A0MDBrSlZFZW9xZlVnYjQrK1JLRVJrWmowWXR3NEN0WHhwOVMzVkd4NmNOQQozZVlqRnRQd2hoYWVEQmdma1hXQWtISXFDcEsrN3RYem9pRGpXbi8walI2VDcrSGlaNEZjZ1AzYnd3K3NjUDIyCjlDQVZ1ZFg4TWpEQ1hTcll0Y0ZINllBanlCSTJjbDhoSkJqa2E3aERpVC9DaFlEZlFFVFZDM3crQjBDYjF1NWcKdE03Z2NGcUw4OVdhMnp5UzdNdXk5bEthUDBvTXl1Ty82Tm1wNjNsVnRHeEZKSFh4WTN6M0lycGxlbTNZQThpTwpmbmlYZXc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
{{% /accordion %}}
{{% accordion id="option-b" label="Option B—Bring Your Own Certificate: Signed by Recognized CA" %}}
</details>
<details id="option-b">
<summary>Option B—Bring Your Own Certificate: Signed by Recognized CA</summary>
If you are using a Certificate Signed By A Recognized Certificate Authority, you don't need to perform any step in this part.
{{% /accordion %}}
</details>
## 8. Configure FQDN
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/single-node-install-external-lb/single-node-install-external-lb.md
+7 -4
View File
@@ -48,7 +48,9 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher
Choose from the following options:
{{% accordion id="option-a" label="Option A-Bring Your Own Certificate: Self-Signed" %}}
<details id="option-a">
<summary>Option A-Bring Your Own Certificate: Self-Signed</summary>
If you elect to use a self-signed certificate to encrypt communication, you must install the certificate on your load balancer (which you'll do later) and your Rancher container. Run the Docker command to deploy Rancher, pointing it toward your certificate.
> **Prerequisites:**
@@ -67,8 +69,9 @@ If you elect to use a self-signed certificate to encrypt communication, you must
rancher/rancher:latest
```
{{% /accordion %}}
{{% accordion id="option-b" label="Option B-Bring Your Own Certificate: Signed by Recognized CA" %}}
</details>
<details id="option-b">
<summary>Option B-Bring Your Own Certificate: Signed by Recognized CA</summary>
If your cluster is public facing, it's best to use a certificate signed by a recognized CA.
> **Prerequisites:**
@@ -87,7 +90,7 @@ If you use a certificate signed by a recognized CA, installing your certificate
rancher/rancher:latest --no-cacerts
```
{{% /accordion %}}
</details>
## 3. Configure Load Balancer
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/upgrading-cert-manager/helm-2-instructions/helm-2-instructions.md
+11 -8
View File
@@ -23,22 +23,23 @@ To address these changes, this guide will do two things:
> 1. Take a one-time snapshot of your Kubernetes cluster running Rancher server
> 2. Uninstall Rancher, cert-manager, and the CustomResourceDefinition for cert-manager
> 3. Install the newer version of Rancher and cert-manager
> 3. Install the newer version of Rancher and cert-manager
> The reason is that when Helm upgrades Rancher, it will reject the upgrade and show error messages if the running Rancher app does not match the chart template used to install it. Because cert-manager changed its API group and we cannot modify released charts for Rancher, there will always be a mismatch on the cert-manager's API version, therefore the upgrade will be rejected.
> For reinstalling Rancher with Helm, please check [Option B: Reinstalling Rancher Chart]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/upgrades-rollbacks/upgrades/ha/) under the upgrade Rancher section.
> For reinstalling Rancher with Helm, please check [Option B: Reinstalling Rancher Chart]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/upgrades-rollbacks/upgrades/ha/) under the upgrade Rancher section.
## Upgrade Cert-Manager Only
## Upgrade Cert-Manager Only
> **Note:**
> These instructions are applied if you have no plan to upgrade Rancher.
> These instructions are applied if you have no plan to upgrade Rancher.
The namespace used in these instructions depends on the namespace cert-manager is currently installed in. If it is in kube-system use that in the instructions below. You can verify by running `kubectl get pods --all-namespaces` and checking which namespace the cert-manager-\* pods are listed in. Do not change the namespace cert-manager is running in or this can cause issues.
In order to upgrade cert-manager, follow these instructions:
{{% accordion id="normal" label="Upgrading cert-manager with Internet access" %}}
<details id="normal">
<summary>Upgrading cert-manager with Internet access</summary>
1. Back up existing resources as a precaution
```plain
@@ -74,9 +75,11 @@ In order to upgrade cert-manager, follow these instructions:
```plain
helm install --version 0.12.0 --name cert-manager --namespace kube-system jetstack/cert-manager
```
{{% /accordion %}}
</details>
<details id="airgap">
<summary>Upgrading cert-manager in an airgapped environment</summary>
{{% accordion id="airgap" label="Upgrading cert-manager in an airgapped environment" %}}
### Prerequisites
Before you can perform the upgrade, you must prepare your air gapped environment by adding the necessary container images to your private registry and downloading or rendering the required Kubernetes manifest files.
@@ -138,7 +141,7 @@ Before you can perform the upgrade, you must prepare your air gapped environment
```plain
kubectl -n kube-system apply -R -f ./cert-manager
```
{{% /accordion %}}
</details>
Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the kube-system namespace for running pods:
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/upgrading-cert-manager/upgrading-cert-manager.md
+10 -8
View File
@@ -23,11 +23,11 @@ To address these changes, this guide will do two things:
> 1. Take a one-time snapshot of your Kubernetes cluster running Rancher server
> 2. Uninstall Rancher, cert-manager, and the CustomResourceDefinition for cert-manager
> 3. Install the newer version of Rancher and cert-manager
> 3. Install the newer version of Rancher and cert-manager
> The reason is that when Helm upgrades Rancher, it will reject the upgrade and show error messages if the running Rancher app does not match the chart template used to install it. Because cert-manager changed its API group and we cannot modify released charts for Rancher, there will always be a mismatch on the cert-manager's API version, therefore the upgrade will be rejected.
> For reinstalling Rancher with Helm, please check [Option B: Reinstalling Rancher Chart]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/upgrades-rollbacks/upgrades/ha/) under the upgrade Rancher section.
> For reinstalling Rancher with Helm, please check [Option B: Reinstalling Rancher Chart]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/upgrades-rollbacks/upgrades/ha/) under the upgrade Rancher section.
# Upgrade Cert-Manager
@@ -39,7 +39,8 @@ In order to upgrade cert-manager, follow these instructions:
### Option A: Upgrade cert-manager with Internet Access
{{% accordion id="normal" label="Click to expand" %}}
<details id="normal">
<summary>Click to expand</summary>
1. [Back up existing resources](https://cert-manager.io/docs/tutorials/backup/) as a precaution
```plain
@@ -95,7 +96,7 @@ In order to upgrade cert-manager, follow these instructions:
helm install \
cert-manager jetstack/cert-manager \
--namespace cert-manager \
--version v0.12.0
--version v0.12.0
```
1. [Restore back up resources](https://cert-manager.io/docs/tutorials/backup/#restoring-resources)
@@ -104,11 +105,12 @@ In order to upgrade cert-manager, follow these instructions:
kubectl apply -f cert-manager-backup.yaml
```
{{% /accordion %}}
</details>
### Option B: Upgrade cert-manager in an Air Gap Environment
{{% accordion id="airgap" label="Click to expand" %}}
<details id="airgap">
<summary>Click to expand</summary>
### Prerequisites
@@ -211,9 +213,9 @@ Before you can perform the upgrade, you must prepare your air gapped environment
kubectl apply -f cert-manager-backup.yaml
```
{{% /accordion %}}
</details>
### Verify the Deployment
### Verify the Deployment
Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the kube-system namespace for running pods:
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/k8s-in-rancher/horitzontal-pod-autoscaler/hpa-for-rancher-before-2_0_7/hpa-for-rancher-before-2_0_7.md
+13 -6
View File
@@ -80,7 +80,10 @@ To create HPA resources based on resource metrics such as CPU and memory use, yo
# kubectl -n kube-system logs metrics-server-6fbfb84cdd-t2fk9
```
Then review the log to confirm that the `metrics-server` package is running.
{{% accordion id="metrics-server-run-check" label="Metrics Server Log Output" %}}
<details id="metrics-server-run-check">
<summary>Metrics Server Log Output</summary>
I0723 08:09:56.193136 1 heapster.go:71] /metrics-server --source=kubernetes.summary_api:''
I0723 08:09:56.193574 1 heapster.go:72] Metrics Server version v0.2.1
I0723 08:09:56.194480 1 configs.go:61] Using Kubernetes client with master "https://10.43.0.1:443" and version
@@ -91,7 +94,7 @@ To create HPA resources based on resource metrics such as CPU and memory use, yo
[restful] 2018/07/23 08:09:57 log.go:33: [restful/swagger] listing is available at https:///swaggerapi
[restful] 2018/07/23 08:09:57 log.go:33: [restful/swagger] https:///swaggerui/ is mapped to folder /swagger-ui/
I0723 08:09:57.394080 1 serve.go:85] Serving securely on 0.0.0.0:443
{{% /accordion %}}
</details>
1. Check that the metrics api is accessible from `kubectl`.
@@ -124,7 +127,10 @@ To do it, follow these steps:
1. Configure `kubectl` to connect to your cluster.
1. Copy the ClusterRole and ClusterRoleBinding manifest for the type of metrics you're using for your HPA.
{{% accordion id="cluster-role-resource-metrics" label="Resource Metrics: ApiGroups resource.metrics.k8s.io" %}}
<details id="cluster-role-resource-metrics">
<summary>Resource Metrics: ApiGroups resource.metrics.k8s.io</summary>
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
@@ -152,8 +158,9 @@ To do it, follow these steps:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: system:anonymous
{{% /accordion %}}
{{% accordion id="cluster-role-custom-resources" label="Custom Metrics: ApiGroups custom.metrics.k8s.io" %}}
</details>
<details id="cluster-role-custom-resources">
<summary>Custom Metrics: ApiGroups custom.metrics.k8s.io</summary>
```
apiVersion: rbac.authorization.k8s.io/v1
@@ -183,7 +190,7 @@ To do it, follow these steps:
kind: User
name: system:anonymous
```
{{% /accordion %}}
</details>
1. Create them in your cluster using one of the follow commands, depending on the metrics you're using.
```
# kubectl create -f <RESOURCE_METRICS_MANIFEST>
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/k8s-in-rancher/horitzontal-pod-autoscaler/manage-hpa-with-kubectl/manage-hpa-with-kubectl.md
+15 -6
View File
@@ -164,7 +164,10 @@ For HPA to use custom metrics from Prometheus, package [k8s-prometheus-adapter](
# kubectl logs prometheus-adapter-prometheus-adapter-568674d97f-hbzfx -n kube-system
```
Then review the log output to confirm the service is running.
{{% accordion id="prometheus-logs" label="Prometheus Adaptor Logs" %}}
<details id="prometheus-logs">
<summary>Prometheus Adaptor Logs</summary>
...
I0724 10:18:45.696679 1 round_trippers.go:436] GET https://10.43.0.1:443/api/v1/namespaces/default/pods?labelSelector=app%3Dhello-world 200 OK in 2 milliseconds
I0724 10:18:45.696695 1 round_trippers.go:442] Response Headers:
@@ -177,7 +180,7 @@ For HPA to use custom metrics from Prometheus, package [k8s-prometheus-adapter](
I0724 10:18:45.699939 1 wrap.go:42] GET /apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pods/%2A/fs_read?labelSelector=app%3Dhello-world: (12.431262ms) 200 [[kube-controller-manager/v1.10.1 (linux/amd64) kubernetes/d4ab475/system:serviceaccount:kube-system:horizontal-pod-autoscaler] 10.42.0.0:24268]
I0724 10:18:51.727845 1 request.go:836] Request Body: {"kind":"SubjectAccessReview","apiVersion":"authorization.k8s.io/v1beta1","metadata":{"creationTimestamp":null},"spec":{"nonResourceAttributes":{"path":"/","verb":"get"},"user":"system:anonymous","group":["system:unauthenticated"]},"status":{"allowed":false}}
...
{{% /accordion %}}
</details>
@@ -188,15 +191,21 @@ For HPA to use custom metrics from Prometheus, package [k8s-prometheus-adapter](
# kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1
```
If the API is accessible, you should receive output that's similar to what follows.
{{% accordion id="custom-metrics-api-response" label="API Response" %}}
<details id="custom-metrics-api-response">
<summary>API Response</summary>
{"kind":"APIResourceList","apiVersion":"v1","groupVersion":"custom.metrics.k8s.io/v1beta1","resources":[{"name":"pods/fs_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_rss","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_period","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_read","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_user","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/last_seen","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/tasks_state","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_quota","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/start_time_seconds","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_write","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_cache","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_working_set_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_udp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes_free","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time_weighted","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failures","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_swap","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_shares","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_swap_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_current","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failcnt","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_tcp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_max_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_reservation_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_load_average_10s","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_system","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]}]}
{{% /accordion %}}
</details>
- If you are accessing the cluster through Rancher, enter your Server URL in the kubectl config in the following format: `https://<RANCHER_URL>/k8s/clusters/<CLUSTER_ID>`. Add the suffix `/k8s/clusters/<CLUSTER_ID>` to API path.
```
# kubectl get --raw /k8s/clusters/<CLUSTER_ID>/apis/custom.metrics.k8s.io/v1beta1
```
If the API is accessible, you should receive output that's similar to what follows.
{{% accordion id="custom-metrics-api-response-rancher" label="API Response" %}}
<details id="custom-metrics-api-response-rancher">
<summary>API Response</summary>
{"kind":"APIResourceList","apiVersion":"v1","groupVersion":"custom.metrics.k8s.io/v1beta1","resources":[{"name":"pods/fs_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_rss","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_period","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_read","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_user","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/last_seen","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/tasks_state","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_quota","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/start_time_seconds","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_write","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_cache","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_working_set_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_udp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes_free","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time_weighted","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failures","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_swap","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_shares","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_swap_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_current","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failcnt","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_tcp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_max_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_reservation_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_load_average_10s","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_system","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]}]}
{{% /accordion %}}
</details>
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md
+496 -458
View File
@@ -12,58 +12,62 @@ For HPA to work correctly, service deployments should have resources request def
1. Configure `kubectl` to connect to your Kubernetes cluster.
2. Copy the `hello-world` deployment manifest below.
{{% accordion id="hello-world" label="Hello World Manifest" %}}
```
apiVersion: apps/v1beta2
kind: Deployment
metadata:
labels:
app: hello-world
name: hello-world
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: hello-world
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
type: RollingUpdate
template:
metadata:
labels:
app: hello-world
spec:
containers:
- image: rancher/hello-world
imagePullPolicy: Always
name: hello-world
resources:
requests:
cpu: 500m
memory: 64Mi
ports:
- containerPort: 80
protocol: TCP
restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
name: hello-world
namespace: default
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: hello-world
```
{{% /accordion %}}
1. Copy the `hello-world` deployment manifest below.
<details id="hello-world">
<summary>Hello World Manifest</summary>
```
apiVersion: apps/v1beta2
kind: Deployment
metadata:
labels:
app: hello-world
name: hello-world
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: hello-world
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
type: RollingUpdate
template:
metadata:
labels:
app: hello-world
spec:
containers:
- image: rancher/hello-world
imagePullPolicy: Always
name: hello-world
resources:
requests:
cpu: 500m
memory: 64Mi
ports:
- containerPort: 80
protocol: TCP
restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
name: hello-world
namespace: default
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: hello-world
```
</details>
1. Deploy it to your cluster.
@@ -72,423 +76,457 @@ spec:
```
1. Copy one of the HPAs below based on the metric type you're using:
{{% accordion id="service-deployment-resource-metrics" label="Hello World HPA: Resource Metrics" %}}
```
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
name: hello-world
namespace: default
spec:
scaleTargetRef:
apiVersion: extensions/v1beta1
kind: Deployment
name: hello-world
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
targetAverageUtilization: 50
- type: Resource
resource:
name: memory
targetAverageValue: 1000Mi
```
{{% /accordion %}}
{{% accordion id="service-deployment-custom-metrics" label="Hello World HPA: Custom Metrics" %}}
```
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
name: hello-world
namespace: default
spec:
scaleTargetRef:
apiVersion: extensions/v1beta1
kind: Deployment
name: hello-world
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
targetAverageUtilization: 50
- type: Resource
resource:
name: memory
targetAverageValue: 100Mi
- type: Pods
pods:
metricName: cpu_system
targetAverageValue: 20m
```
{{% /accordion %}}
<details id="service-deployment-resource-metrics">
<summary>Hello World HPA: Resource Metrics</summary>
```
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
name: hello-world
namespace: default
spec:
scaleTargetRef:
apiVersion: extensions/v1beta1
kind: Deployment
name: hello-world
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
targetAverageUtilization: 50
- type: Resource
resource:
name: memory
targetAverageValue: 1000Mi
```
</details>
<details id="service-deployment-custom-metrics">
<summary>Hello World HPA: Custom Metrics</summary>
```
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
name: hello-world
namespace: default
spec:
scaleTargetRef:
apiVersion: extensions/v1beta1
kind: Deployment
name: hello-world
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
targetAverageUtilization: 50
- type: Resource
resource:
name: memory
targetAverageValue: 100Mi
- type: Pods
pods:
metricName: cpu_system
targetAverageValue: 20m
```
</details>
1. View the HPA info and description. Confirm that metric data is shown.
{{% accordion id="hpa-info-resource-metrics" label="Resource Metrics" %}}
1. Enter the following commands.
```
# kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
hello-world Deployment/hello-world 1253376 / 100Mi, 0% / 50% 1 10 1 6m
# kubectl describe hpa
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Mon, 23 Jul 2018 20:21:16 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 1253376 / 100Mi
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True ReadyForNewScale the last scale time was sufficiently old as to warrant a new scale
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events: <none>
```
{{% /accordion %}}
{{% accordion id="hpa-info-custom-metrics" label="Custom Metrics" %}}
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive the output that follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:36:28 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 3514368 / 100Mi
"cpu_system" on pods: 0 / 20m
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True ReadyForNewScale the last scale time was sufficiently old as to warrant a new scale
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events: <none>
```
{{% /accordion %}}
<details id="hpa-info-resource-metrics">
<summary>Resource Metrics</summary>
1. Enter the following commands.
```
# kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
hello-world Deployment/hello-world 1253376 / 100Mi, 0% / 50% 1 10 1 6m
# kubectl describe hpa
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Mon, 23 Jul 2018 20:21:16 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 1253376 / 100Mi
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True ReadyForNewScale the last scale time was sufficiently old as to warrant a new scale
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events: <none>
```
</details>
<details id="hpa-info-custom-metrics">
<summary>Custom Metrics</summary>
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive the output that follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:36:28 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 3514368 / 100Mi
"cpu_system" on pods: 0 / 20m
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True ReadyForNewScale the last scale time was sufficiently old as to warrant a new scale
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events: <none>
```
</details>
1. Generate a load for the service to test that your pods autoscale as intended. You can use any load-testing tool (Hey, Gatling, etc.), but we're using [Hey](https://github.com/rakyll/hey).
1. Test that pod autoscaling works as intended.<br/></br>
1. Test that pod autoscaling works as intended.<br/><br/>
**To Test Autoscaling Using Resource Metrics:**
{{% accordion id="observe-upscale-2-pods-cpu" label="Upscale to 2 Pods: CPU Usage Up to Target" %}}
Use your load testing tool to scale up to two pods based on CPU Usage.
1. View your HPA.
```
# kubectl describe hpa
```
You should receive output similar to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Mon, 23 Jul 2018 22:22:04 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 10928128 / 100Mi
resource cpu on pods (as a percentage of request): 56% (280m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 2
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 13s horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
```
1. Enter the following command to confirm you've scaled to two pods.
```
# kubectl get pods
```
You should receive output similar to what follows:
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-k8ph2 1/1 Running 0 1m
hello-world-54764dfbf8-q6l4v 1/1 Running 0 3h
```
{{% /accordion %}}
{{% accordion id="observe-upscale-3-pods-cpu-cooldown" label="Upscale to 3 pods: CPU Usage Up to Target" %}}
Use your load testing tool to upscale to 3 pods based on CPU usage with `horizontal-pod-autoscaler-upscale-delay` set to 3 minutes.
<details id="observe-upscale-2-pods-cpu">
<summary>Upscale to 2 Pods: CPU Usage Up to Target</summary>
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Mon, 23 Jul 2018 22:22:04 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 9424896 / 100Mi
resource cpu on pods (as a percentage of request): 66% (333m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 3
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 4m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 16s horizontal-pod-autoscaler New size: 3; reason: cpu resource utilization (percentage of request) above target
```
2. Enter the following command to confirm three pods are running.
```
# kubectl get pods
```
You should receive output similar to what follows.
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-f46kh 0/1 Running 0 1m
hello-world-54764dfbf8-k8ph2 1/1 Running 0 5m
hello-world-54764dfbf8-q6l4v 1/1 Running 0 3h
```
{{% /accordion %}}
{{% accordion id="observe-downscale-1-pod" label="Downscale to 1 Pod: All Metrics Below Target" %}}
Use your load testing to scale down to 1 pod when all metrics are below target for `horizontal-pod-autoscaler-downscale-delay` (5 minutes by default).
Use your load testing tool to scale up to two pods based on CPU Usage.
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Mon, 23 Jul 2018 22:22:04 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 10070016 / 100Mi
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 1
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 10m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 6m horizontal-pod-autoscaler New size: 3; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 1s horizontal-pod-autoscaler New size: 1; reason: All metrics below target
```
{{% /accordion %}}
<br/>
**To Test Autoscaling Using Custom Metrics:**
{{% accordion id="custom-observe-upscale-2-pods-cpu" label="Upscale to 2 Pods: CPU Usage Up to Target" %}}
Use your load testing tool to upscale two pods based on CPU usage.
1. View your HPA.
```
# kubectl describe hpa
```
You should receive output similar to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Mon, 23 Jul 2018 22:22:04 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 10928128 / 100Mi
resource cpu on pods (as a percentage of request): 56% (280m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 2
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 13s horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
```
1. Enter the following command to confirm you've scaled to two pods.
```
# kubectl get pods
```
You should receive output similar to what follows:
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-k8ph2 1/1 Running 0 1m
hello-world-54764dfbf8-q6l4v 1/1 Running 0 3h
```
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 8159232 / 100Mi
"cpu_system" on pods: 7m / 20m
resource cpu on pods (as a percentage of request): 64% (321m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 2
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 16s horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
```
1. Enter the following command to confirm two pods are running.
```
# kubectl get pods
```
You should receive output similar to what follows.
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-5pfdr 1/1 Running 0 3s
hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
```
{{% /accordion %}}
{{% accordion id="observe-upscale-3-pods-cpu-cooldown-2" label="Upscale to 3 Pods: CPU Usage Up to Target" %}}
Use your load testing tool to scale up to three pods when the cpu_system usage limit is up to target.
</details>
<details id="observe-upscale-3-pods-cpu-cooldown">
<summary>Upscale to 3 pods: CPU Usage Up to Target</summary>
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows:
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 8374272 / 100Mi
"cpu_system" on pods: 27m / 20m
resource cpu on pods (as a percentage of request): 71% (357m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 3
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 3m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 3s horizontal-pod-autoscaler New size: 3; reason: pods metric cpu_system above target
```
1. Enter the following command to confirm three pods are running.
```
# kubectl get pods
```
You should receive output similar to what follows:
```
# kubectl get pods
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-5pfdr 1/1 Running 0 3m
hello-world-54764dfbf8-m2hrl 1/1 Running 0 1s
hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
```
{{% /accordion %}}
{{% accordion id="observe-upscale-4-pods" label="Upscale to 4 Pods: CPU Usage Up to Target" %}}
Use your load testing tool to upscale to four pods based on CPU usage. `horizontal-pod-autoscaler-upscale-delay` is set to three minutes by default.
Use your load testing tool to upscale to 3 pods based on CPU usage with `horizontal-pod-autoscaler-upscale-delay` set to 3 minutes.
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 8374272 / 100Mi
"cpu_system" on pods: 27m / 20m
resource cpu on pods (as a percentage of request): 71% (357m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 3
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 5m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 3m horizontal-pod-autoscaler New size: 3; reason: pods metric cpu_system above target
Normal SuccessfulRescale 4s horizontal-pod-autoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target
```
1. Enter the following command to confirm four pods are running.
```
# kubectl get pods
```
You should receive output similar to what follows.
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-2p9xb 1/1 Running 0 5m
hello-world-54764dfbf8-5pfdr 1/1 Running 0 2m
hello-world-54764dfbf8-m2hrl 1/1 Running 0 1s
hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
```
{{% /accordion %}}
{{% accordion id="custom-metrics-observe-downscale-1-pod" label="Downscale to 1 Pod: All Metrics Below Target" %}}
Use your load testing tool to scale down to one pod when all metrics below target for `horizontal-pod-autoscaler-downscale-delay`.
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive similar output to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 8101888 / 100Mi
"cpu_system" on pods: 8m / 20m
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 1
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 10m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 8m horizontal-pod-autoscaler New size: 3; reason: pods metric cpu_system above target
Normal SuccessfulRescale 5m horizontal-pod-autoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 13s horizontal-pod-autoscaler New size: 1; reason: All metrics below target
```
1. Enter the following command to confirm a single pods is running.
```
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Mon, 23 Jul 2018 22:22:04 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 9424896 / 100Mi
resource cpu on pods (as a percentage of request): 66% (333m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 3
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 4m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 16s horizontal-pod-autoscaler New size: 3; reason: cpu resource utilization (percentage of request) above target
```
2. Enter the following command to confirm three pods are running.
```
# kubectl get pods
```
You should receive output similar to what follows.
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
```
{{% /accordion %}}
```
You should receive output similar to what follows.
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-f46kh 0/1 Running 0 1m
hello-world-54764dfbf8-k8ph2 1/1 Running 0 5m
hello-world-54764dfbf8-q6l4v 1/1 Running 0 3h
```
</details>
<details id="observe-downscale-1-pod">
<summary>Downscale to 1 Pod: All Metrics Below Target</summary>
Use your load testing to scale down to 1 pod when all metrics are below target for `horizontal-pod-autoscaler-downscale-delay` (5 minutes by default).
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Mon, 23 Jul 2018 22:22:04 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 10070016 / 100Mi
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 1
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 10m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 6m horizontal-pod-autoscaler New size: 3; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 1s horizontal-pod-autoscaler New size: 1; reason: All metrics below target
```
</details>
**To Test Autoscaling Using Custom Metrics:**
<details id="custom-observe-upscale-2-pods-cpu">
<summary>Upscale to 2 Pods: CPU Usage Up to Target</summary>
Use your load testing tool to upscale two pods based on CPU usage.
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 8159232 / 100Mi
"cpu_system" on pods: 7m / 20m
resource cpu on pods (as a percentage of request): 64% (321m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 2
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 16s horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
```
1. Enter the following command to confirm two pods are running.
```
# kubectl get pods
```
You should receive output similar to what follows.
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-5pfdr 1/1 Running 0 3s
hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
```
</details>
<details id="observe-upscale-3-pods-cpu-cooldown-2">
<summary>Upscale to 3 Pods: CPU Usage Up to Target</summary>
Use your load testing tool to scale up to three pods when the cpu_system usage limit is up to target.
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows:
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 8374272 / 100Mi
"cpu_system" on pods: 27m / 20m
resource cpu on pods (as a percentage of request): 71% (357m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 3
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 3m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 3s horizontal-pod-autoscaler New size: 3; reason: pods metric cpu_system above target
```
1. Enter the following command to confirm three pods are running.
```
# kubectl get pods
```
You should receive output similar to what follows:
```
# kubectl get pods
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-5pfdr 1/1 Running 0 3m
hello-world-54764dfbf8-m2hrl 1/1 Running 0 1s
hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
```
</details>
<details id="observe-upscale-4-pods">
<summary>Upscale to 4 Pods: CPU Usage Up to Target</summary>
Use your load testing tool to upscale to four pods based on CPU usage. `horizontal-pod-autoscaler-upscale-delay` is set to three minutes by default.
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 8374272 / 100Mi
"cpu_system" on pods: 27m / 20m
resource cpu on pods (as a percentage of request): 71% (357m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 3
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 5m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 3m horizontal-pod-autoscaler New size: 3; reason: pods metric cpu_system above target
Normal SuccessfulRescale 4s horizontal-pod-autoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target
```
1. Enter the following command to confirm four pods are running.
```
# kubectl get pods
```
You should receive output similar to what follows.
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-2p9xb 1/1 Running 0 5m
hello-world-54764dfbf8-5pfdr 1/1 Running 0 2m
hello-world-54764dfbf8-m2hrl 1/1 Running 0 1s
hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
```
</details>
<details id="custom-metrics-observe-downscale-1-pod">
<summary>Downscale to 1 Pod: All Metrics Below Target</summary>
Use your load testing tool to scale down to one pod when all metrics below target for `horizontal-pod-autoscaler-downscale-delay`.
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive similar output to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 8101888 / 100Mi
"cpu_system" on pods: 8m / 20m
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 1
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 10m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 8m horizontal-pod-autoscaler New size: 3; reason: pods metric cpu_system above target
Normal SuccessfulRescale 5m horizontal-pod-autoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 13s horizontal-pod-autoscaler New size: 1; reason: All metrics below target
```
1. Enter the following command to confirm a single pods is running.
```
# kubectl get pods
```
You should receive output similar to what follows.
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
```
</details>
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/overview/overview.md
+2 -2
View File
@@ -49,7 +49,7 @@ The Rancher API server is built on top of an embedded Kubernetes API server and
### Cluster Visibility
- **Logging:** Rancher can integrate with a variety of popular logging services and tools that exist outside of your Kubernetes clusters.
- **Monitoring:** Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with Prometheus, a leading open-source monitoring solution.
- **Monitoring:** Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with Prometheus, a leading open-source monitoring solution.
- **Alerting:** To keep your clusters and applications healthy and driving your organizational productivity forward, you need to stay informed of events occurring in your clusters and projects, both planned and unplanned.
# Editing Downstream Clusters with Rancher
@@ -60,4 +60,4 @@ After a cluster is created with Rancher, a cluster administrator can manage clus
The following table summarizes the options and settings available for each cluster type:
{{% include file="/rancher/v2.0-v2.4/en/cluster-provisioning/cluster-capabilities-table" %}}
{{% include file="/rancher/v2.0-v2.4/en/cluster-provisioning/cluster-capabilities-table</summary>
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/security/rancher-2.3.x/rancher-v2.3.3/hardening-2.3.3/hardening-2.3.3.md
+98 -92
View File
@@ -172,7 +172,7 @@ etcd is a highly-available key-value store used by Kubernetes deployments for pe
On a etcd server node, get the etcd data directory, passed as an argument `--data-dir`, from the below command:
``` bash
``` bash
ps -ef | grep etcd
```
@@ -1271,7 +1271,8 @@ runcmd:
Before apply, replace `rancher_kubernetes_engine_config.services.etcd.gid` and `rancher_kubernetes_engine_config.services.etcd.uid` with the proper etcd group and user ids that were created on etcd nodes.
{{% accordion id="cluster-1.14" label="RKE yaml for k8s 1.14" %}}
<details id="cluster-1.14">
<summary>RKE yaml for k8s 1.14</summary>
``` yaml
nodes:
@@ -1295,48 +1296,48 @@ bastion_host:
ssh_agent_auth: false
cloud_provider: {}
ignore_docker_version: true
#
#
# # 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:
# provider: nginx
# node_selector:
# app: ingress
#
#
ingress:
provider: nginx
kubernetes_version: v1.14.9-rancher1-1
monitoring:
provider: metrics-server
#
#
# If you are using calico on AWS
#
#
# network:
# plugin: calico
# calico_network_provider:
# cloud_provider: aws
#
#
# # To specify flannel interface
#
#
# network:
# plugin: flannel
# flannel_network_provider:
# iface: eth1
#
#
# # To specify flannel interface for canal plugin
#
#
# network:
# plugin: canal
# canal_network_provider:
# iface: eth1
#
#
network:
options:
flannel_backend_type: vxlan
plugin: canal
restore:
restore: false
#
#
# services:
# kube-api:
# service_cluster_ip_range: 10.43.0.0/16
@@ -1346,7 +1347,7 @@ restore:
# kubelet:
# cluster_domain: cluster.local
# cluster_dns_server: 10.43.0.10
#
#
services:
etcd:
backup_config:
@@ -1401,9 +1402,10 @@ services:
ssh_agent_auth: false
```
{{% /accordion %}}
</details>
{{% accordion id="cluster-1.15" label="RKE yaml for k8s 1.15" %}}
<details id="cluster-1.15">
<summary>RKE yaml for k8s 1.15</summary>
``` yaml
nodes:
@@ -1423,46 +1425,46 @@ addon_job_timeout: 30
authentication:
strategy: x509
ignore_docker_version: true
#
#
# # 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:
# provider: nginx
# node_selector:
# app: ingress
#
#
ingress:
provider: nginx
kubernetes_version: v1.15.6-rancher1-2
monitoring:
provider: metrics-server
#
#
# If you are using calico on AWS
#
#
# network:
# plugin: calico
# calico_network_provider:
# cloud_provider: aws
#
#
# # To specify flannel interface
#
#
# network:
# plugin: flannel
# flannel_network_provider:
# iface: eth1
#
#
# # To specify flannel interface for canal plugin
#
#
# network:
# plugin: canal
# canal_network_provider:
# iface: eth1
#
#
network:
options:
flannel_backend_type: vxlan
plugin: canal
#
#
# services:
# kube-api:
# service_cluster_ip_range: 10.43.0.0/16
@@ -1472,7 +1474,7 @@ network:
# kubelet:
# cluster_domain: cluster.local
# cluster_dns_server: 10.43.0.10
#
#
services:
etcd:
backup_config:
@@ -1525,9 +1527,10 @@ services:
ssh_agent_auth: false
```
{{% /accordion %}}
</details>
{{% accordion id="cluster-1.16" label="RKE yaml for k8s 1.16" %}}
<details id="cluster-1.16">
<summary>RKE yaml for k8s 1.16</summary>
``` yaml
nodes:
@@ -1547,46 +1550,46 @@ addon_job_timeout: 30
authentication:
strategy: x509
ignore_docker_version: true
#
#
# # 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:
# provider: nginx
# node_selector:
# app: ingress
#
#
ingress:
provider: nginx
kubernetes_version: v1.16.3-rancher1-1
monitoring:
provider: metrics-server
#
#
# If you are using calico on AWS
#
#
# network:
# plugin: calico
# calico_network_provider:
# cloud_provider: aws
#
#
# # To specify flannel interface
#
#
# network:
# plugin: flannel
# flannel_network_provider:
# iface: eth1
#
#
# # To specify flannel interface for canal plugin
#
#
# network:
# plugin: canal
# canal_network_provider:
# iface: eth1
#
#
network:
options:
flannel_backend_type: vxlan
plugin: canal
#
#
# services:
# kube-api:
# service_cluster_ip_range: 10.43.0.0/16
@@ -1596,7 +1599,7 @@ network:
# kubelet:
# cluster_domain: cluster.local
# cluster_dns_server: 10.43.0.10
#
#
services:
etcd:
backup_config:
@@ -1649,19 +1652,20 @@ services:
ssh_agent_auth: false
```
{{% /accordion %}}
</details>
## Appendix C - Complete RKE Template Example
Before apply, replace `rancher_kubernetes_engine_config.services.etcd.gid` and `rancher_kubernetes_engine_config.services.etcd.uid` with the proper etcd group and user ids that were created on etcd nodes.
Before apply, replace `rancher_kubernetes_engine_config.services.etcd.gid` and `rancher_kubernetes_engine_config.services.etcd.uid` with the proper etcd group and user ids that were created on etcd nodes.
{{% accordion id="k8s-1.14" label="RKE template for k8s 1.14" %}}
<details id="k8s-1.14">
<summary>RKE template for k8s 1.14</summary>
``` yaml
#
#
# Cluster Config
#
#
answers: {}
default_pod_security_policy_template_id: restricted
docker_root_dir: /var/lib/docker
@@ -1671,9 +1675,9 @@ enable_network_policy: false
local_cluster_auth_endpoint:
enabled: false
name: test-35378
#
#
# Rancher Config
#
#
rancher_kubernetes_engine_config:
addon_job_timeout: 30
authentication:
@@ -1683,48 +1687,48 @@ rancher_kubernetes_engine_config:
ssh_agent_auth: false
cloud_provider: {}
ignore_docker_version: true
#
#
# # 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:
# provider: nginx
# node_selector:
# app: ingress
#
#
ingress:
provider: nginx
kubernetes_version: v1.14.9-rancher1-1
monitoring:
provider: metrics-server
#
#
# If you are using calico on AWS
#
#
# network:
# plugin: calico
# calico_network_provider:
# cloud_provider: aws
#
#
# # To specify flannel interface
#
#
# network:
# plugin: flannel
# flannel_network_provider:
# iface: eth1
#
#
# # To specify flannel interface for canal plugin
#
#
# network:
# plugin: canal
# canal_network_provider:
# iface: eth1
#
#
network:
options:
flannel_backend_type: vxlan
plugin: canal
restore:
restore: false
#
#
# services:
# kube-api:
# service_cluster_ip_range: 10.43.0.0/16
@@ -1734,7 +1738,7 @@ rancher_kubernetes_engine_config:
# kubelet:
# cluster_domain: cluster.local
# cluster_dns_server: 10.43.0.10
#
#
services:
etcd:
backup_config:
@@ -1790,14 +1794,15 @@ rancher_kubernetes_engine_config:
windows_prefered_cluster: false
```
{{% /accordion %}}
</details>
{{% accordion id="k8s-1.15" label="RKE template for k8s 1.15" %}}
<details id="k8s-1.15">
<summary>RKE template for k8s 1.15</summary>
``` yaml
#
#
# Cluster Config
#
#
default_pod_security_policy_template_id: restricted
docker_root_dir: /var/lib/docker
enable_cluster_alerting: false
@@ -1805,54 +1810,54 @@ enable_cluster_monitoring: false
enable_network_policy: false
local_cluster_auth_endpoint:
enabled: true
#
#
# Rancher Config
#
#
rancher_kubernetes_engine_config:
addon_job_timeout: 30
authentication:
strategy: x509
ignore_docker_version: true
#
#
# # 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:
# provider: nginx
# node_selector:
# app: ingress
#
#
ingress:
provider: nginx
kubernetes_version: v1.15.6-rancher1-2
monitoring:
provider: metrics-server
#
#
# If you are using calico on AWS
#
#
# network:
# plugin: calico
# calico_network_provider:
# cloud_provider: aws
#
#
# # To specify flannel interface
#
#
# network:
# plugin: flannel
# flannel_network_provider:
# iface: eth1
#
#
# # To specify flannel interface for canal plugin
#
#
# network:
# plugin: canal
# canal_network_provider:
# iface: eth1
#
#
network:
options:
flannel_backend_type: vxlan
plugin: canal
#
#
# services:
# kube-api:
# service_cluster_ip_range: 10.43.0.0/16
@@ -1862,7 +1867,7 @@ rancher_kubernetes_engine_config:
# kubelet:
# cluster_domain: cluster.local
# cluster_dns_server: 10.43.0.10
#
#
services:
etcd:
backup_config:
@@ -1916,14 +1921,15 @@ rancher_kubernetes_engine_config:
windows_prefered_cluster: false
```
{{% /accordion %}}
</details>
{{% accordion id="k8s-1.16" label="RKE template for k8s 1.16" %}}
<details id="k8s-1.16">
<summary>RKE template for k8s 1.16</summary>
``` yaml
#
#
# Cluster Config
#
#
default_pod_security_policy_template_id: restricted
docker_root_dir: /var/lib/docker
enable_cluster_alerting: false
@@ -1931,54 +1937,54 @@ enable_cluster_monitoring: false
enable_network_policy: false
local_cluster_auth_endpoint:
enabled: true
#
#
# Rancher Config
#
#
rancher_kubernetes_engine_config:
addon_job_timeout: 30
authentication:
strategy: x509
ignore_docker_version: true
#
#
# # 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:
# provider: nginx
# node_selector:
# app: ingress
#
#
ingress:
provider: nginx
kubernetes_version: v1.16.3-rancher1-1
monitoring:
provider: metrics-server
#
#
# If you are using calico on AWS
#
#
# network:
# plugin: calico
# calico_network_provider:
# cloud_provider: aws
#
#
# # To specify flannel interface
#
#
# network:
# plugin: flannel
# flannel_network_provider:
# iface: eth1
#
#
# # To specify flannel interface for canal plugin
#
#
# network:
# plugin: canal
# canal_network_provider:
# iface: eth1
#
#
network:
options:
flannel_backend_type: vxlan
plugin: canal
#
#
# services:
# kube-api:
# service_cluster_ip_range: 10.43.0.0/16
@@ -1988,7 +1994,7 @@ rancher_kubernetes_engine_config:
# kubelet:
# cluster_domain: cluster.local
# cluster_dns_server: 10.43.0.10
#
#
services:
etcd:
backup_config:
@@ -2042,4 +2048,4 @@ rancher_kubernetes_engine_config:
windows_prefered_cluster: false
```
{{% /accordion %}}
</details>
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/security/rancher-2.3.x/rancher-v2.3.5/benchmark-2.3.5/benchmark-2.3.5.md
+35 -35
View File
@@ -39,7 +39,7 @@ When performing the tests, you will need access to the Docker command line on th
---
## 1 Master Node Security Configuration
### 1.1 Master Node Configuration Files
### 1.1 Master Node Configuration Files
#### 1.1.1 Ensure that the API server pod specification file permissions are set to `644` or more restrictive (Scored)
@@ -155,7 +155,7 @@ Run the below command (based on the etcd data directory found above).
For example,
``` bash
chown etcd:etcd /var/lib/etcd
```
```
**Audit Script:** 1.1.12.sh
@@ -189,7 +189,7 @@ docker inspect etcd | jq -r '.[].HostConfig.Binds[]' | grep "${test_dir}" | cut
RKE does not store the kubernetes default kubeconfig credentials file on the nodes. It’s presented to user where RKE is run.
We recommend that this `kube_config_cluster.yml` file be kept in secure store.
#### 1.1.14 Ensure that the admin.conf file ownership is set to `root:root` (Scored)
#### 1.1.14 Ensure that the admin.conf file ownership is set to `root:root` (Scored)
**Result:** Not Applicable
@@ -249,7 +249,7 @@ stat -c %U:%G /etc/kubernetes/ssl
'root:root' is present
```
#### 1.1.20 Ensure that the Kubernetes PKI certificate file permissions are set to `644` or more restrictive (Scored)
#### 1.1.20 Ensure that the Kubernetes PKI certificate file permissions are set to `644` or more restrictive (Scored)
**Result:** PASS
@@ -732,7 +732,7 @@ on the master node and set the below parameter.
'0' is equal to '0'
```
#### 1.2.20 Ensure that the `--secure-port` argument is not set to `0` (Scored)
#### 1.2.20 Ensure that the `--secure-port` argument is not set to `0` (Scored)
**Result:** PASS
@@ -938,7 +938,7 @@ on the master node and set the `--service-account-key-file` parameter
to the public key file for service accounts:
``` bash
--service-account-key-file=<filename>
`--service-account-key-file=<filename>`
```
**Audit:**
@@ -953,7 +953,7 @@ to the public key file for service accounts:
'--service-account-key-file' is present
```
#### 1.2.29 Ensure that the `--etcd-certfile` and `--etcd-keyfile` arguments are set as appropriate (Scored)
#### 1.2.29 Ensure that the `--etcd-certfile` and `--etcd-keyfile` arguments are set as appropriate (Scored)
**Result:** PASS
@@ -963,8 +963,8 @@ Then, edit the API server pod specification file `/etc/kubernetes/manifests/kube
on the master node and set the **etcd** certificate and **key** file parameters.
``` bash
--etcd-certfile=<path/to/client-certificate-file>
--etcd-keyfile=<path/to/client-key-file>
`--etcd-certfile=<path/to/client-certificate-file>`
`--etcd-keyfile=<path/to/client-key-file>`
```
**Audit:**
@@ -989,8 +989,8 @@ Then, edit the API server pod specification file `/etc/kubernetes/manifests/kube
on the master node and set the TLS certificate and private key file parameters.
``` bash
--tls-cert-file=<path/to/tls-certificate-file>
--tls-private-key-file=<path/to/tls-key-file>
`--tls-cert-file=<path/to/tls-certificate-file>`
`--tls-private-key-file=<path/to/tls-key-file>`
```
**Audit:**
@@ -1015,7 +1015,7 @@ Then, edit the API server pod specification file `/etc/kubernetes/manifests/kube
on the master node and set the client certificate authority file.
``` bash
--client-ca-file=<path/to/client-ca-file>
`--client-ca-file=<path/to/client-ca-file>`
```
**Audit:**
@@ -1040,7 +1040,7 @@ Then, edit the API server pod specification file `/etc/kubernetes/manifests/kube
on the master node and set the etcd certificate authority file parameter.
``` bash
--etcd-cafile=<path/to/ca-file>
`--etcd-cafile=<path/to/ca-file>`
```
**Audit:**
@@ -1202,7 +1202,7 @@ on the master node and set the `--service-account-private-key-file` parameter
to the private key file for service accounts.
``` bash
--service-account-private-key-file=<filename>
`--service-account-private-key-file=<filename>`
```
**Audit:**
@@ -1226,7 +1226,7 @@ Edit the Controller Manager pod specification file `/etc/kubernetes/manifests/ku
on the master node and set the `--root-ca-file` parameter to the certificate bundle file`.
``` bash
--root-ca-file=<path/to/file>
`--root-ca-file=<path/to/file>`
```
**Audit:**
@@ -1311,7 +1311,7 @@ on the master node and set the below parameter.
'false' is equal to 'false'
```
#### 1.4.2 Ensure that the `--bind-address` argument is set to `127.0.0.1` (Scored)
#### 1.4.2 Ensure that the `--bind-address` argument is set to `127.0.0.1` (Scored)
**Result:** PASS
@@ -1344,8 +1344,8 @@ Then, edit the etcd pod specification file `/etc/kubernetes/manifests/etcd.yaml`
on the master node and set the below parameters.
``` bash
--cert-file=</path/to/ca-file>
--key-file=</path/to/key-file>
`--cert-file=</path/to/ca-file>`
`--key-file=</path/to/key-file>`
```
**Audit:**
@@ -1418,8 +1418,8 @@ for your etcd cluster. Then, edit the etcd pod specification file `/etc/kubernet
master node and set the below parameters.
``` bash
--peer-client-file=</path/to/peer-cert-file>
--peer-key-file=</path/to/peer-key-file>
`--peer-client-file=</path/to/peer-cert-file>`
`--peer-key-file=</path/to/peer-key-file>`
```
**Audit:**
@@ -1485,7 +1485,7 @@ node and either remove the `--peer-auto-tls` parameter or set it to `false`.
## 3 Control Plane Configuration
### 3.2 Logging
#### 3.2.1 Ensure that a minimal audit policy is created (Scored)
#### 3.2.1 Ensure that a minimal audit policy is created (Scored)
**Result:** PASS
@@ -1546,7 +1546,7 @@ chmod 644 /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml
**Audit:**
```
/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; then stat -c %a /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; fi'
/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; then stat -c %a /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; fi'
```
**Expected result**:
@@ -1561,7 +1561,7 @@ chmod 644 /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml
**Remediation:**
Run the below command (based on the file location on your system) on the each worker node.
For example,
For example,
``` bash
chown root:root /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml
@@ -1570,7 +1570,7 @@ chown root:root /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml
**Audit:**
```
/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; then stat -c %U:%G /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; fi'
/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; then stat -c %U:%G /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; fi'
```
**Expected result**:
@@ -1594,7 +1594,7 @@ chmod 644 /etc/kubernetes/ssl/kubecfg-kube-node.yaml
**Audit:**
```
/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-node.yaml; then stat -c %a /etc/kubernetes/ssl/kubecfg-kube-node.yaml; fi'
/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-node.yaml; then stat -c %a /etc/kubernetes/ssl/kubecfg-kube-node.yaml; fi'
```
**Expected result**:
@@ -1618,7 +1618,7 @@ chown root:root /etc/kubernetes/ssl/kubecfg-kube-node.yaml
**Audit:**
```
/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-node.yaml; then stat -c %U:%G /etc/kubernetes/ssl/kubecfg-kube-node.yaml; fi'
/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-node.yaml; then stat -c %U:%G /etc/kubernetes/ssl/kubecfg-kube-node.yaml; fi'
```
**Expected result**:
@@ -1635,7 +1635,7 @@ chown root:root /etc/kubernetes/ssl/kubecfg-kube-node.yaml
Run the following command to modify the file permissions of the
``` bash
--client-ca-file chmod 644 <filename>
`--client-ca-file chmod 644 <filename>`
```
**Audit:**
@@ -1664,7 +1664,7 @@ chown root:root <filename>
**Audit:**
```
/bin/sh -c 'if test -e /etc/kubernetes/ssl/kube-ca.pem; then stat -c %U:%G /etc/kubernetes/ssl/kube-ca.pem; fi'
/bin/sh -c 'if test -e /etc/kubernetes/ssl/kube-ca.pem; then stat -c %U:%G /etc/kubernetes/ssl/kube-ca.pem; fi'
```
**Expected result**:
@@ -1703,7 +1703,7 @@ set the below parameter in `KUBELET_SYSTEM_PODS_ARGS` variable.
``` bash
--anonymous-auth=false
```
Based on your system, restart the kubelet service. For example:
``` bash
@@ -1780,7 +1780,7 @@ If using command line arguments, edit the kubelet service file
set the below parameter in `KUBELET_AUTHZ_ARGS` variable.
``` bash
--client-ca-file=<path/to/client-ca-file>
`--client-ca-file=<path/to/client-ca-file>`
```
Based on your system, restart the kubelet service. For example:
@@ -1926,7 +1926,7 @@ systemctl restart kubelet.service
'true' is equal to 'true'
```
#### 4.2.7 Ensure that the `--make-iptables-util-chains` argument is set to `true` (Scored)
#### 4.2.7 Ensure that the `--make-iptables-util-chains` argument is set to `true` (Scored)
**Result:** PASS
@@ -1938,7 +1938,7 @@ remove the `--make-iptables-util-chains` argument from the
`KUBELET_SYSTEM_PODS_ARGS` variable.
Based on your system, restart the kubelet service. For example:
```bash
```bash
systemctl daemon-reload
systemctl restart kubelet.service
```
@@ -2091,7 +2091,7 @@ exit 0
**Audit Execution:**
```
./5.1.5.sh
./5.1.5.sh
```
**Expected result**:
@@ -2218,7 +2218,7 @@ echo "pass"
**Audit Execution:**
```
./5.3.2.sh
./5.3.2.sh
```
**Expected result**:
@@ -2258,7 +2258,7 @@ echo "--count=${default_resources}"
**Audit Execution:**
```
./5.6.4.sh
./5.6.4.sh
```
**Expected result**:
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/security/rancher-2.4/benchmark-2.4/benchmark-2.4.md
+35 -35
View File
@@ -39,7 +39,7 @@ When performing the tests, you will need access to the Docker command line on th
---
## 1 Master Node Security Configuration
### 1.1 Master Node Configuration Files
### 1.1 Master Node Configuration Files
#### 1.1.1 Ensure that the API server pod specification file permissions are set to `644` or more restrictive (Scored)
@@ -155,7 +155,7 @@ Run the below command (based on the etcd data directory found above).
For example,
``` bash
chown etcd:etcd /var/lib/etcd
```
```
**Audit Script:** 1.1.12.sh
@@ -189,7 +189,7 @@ docker inspect etcd | jq -r '.[].HostConfig.Binds[]' | grep "${test_dir}" | cut
RKE does not store the kubernetes default kubeconfig credentials file on the nodes. It’s presented to user where RKE is run.
We recommend that this `kube_config_cluster.yml` file be kept in secure store.
#### 1.1.14 Ensure that the admin.conf file ownership is set to `root:root` (Scored)
#### 1.1.14 Ensure that the admin.conf file ownership is set to `root:root` (Scored)
**Result:** Not Applicable
@@ -249,7 +249,7 @@ stat -c %U:%G /etc/kubernetes/ssl
'root:root' is present
```
#### 1.1.20 Ensure that the Kubernetes PKI certificate file permissions are set to `644` or more restrictive (Scored)
#### 1.1.20 Ensure that the Kubernetes PKI certificate file permissions are set to `644` or more restrictive (Scored)
**Result:** PASS
@@ -732,7 +732,7 @@ on the master node and set the below parameter.
'0' is equal to '0'
```
#### 1.2.20 Ensure that the `--secure-port` argument is not set to `0` (Scored)
#### 1.2.20 Ensure that the `--secure-port` argument is not set to `0` (Scored)
**Result:** PASS
@@ -938,7 +938,7 @@ on the master node and set the `--service-account-key-file` parameter
to the public key file for service accounts:
``` bash
--service-account-key-file=<filename>
`--service-account-key-file=<filename>`
```
**Audit:**
@@ -953,7 +953,7 @@ to the public key file for service accounts:
'--service-account-key-file' is present
```
#### 1.2.29 Ensure that the `--etcd-certfile` and `--etcd-keyfile` arguments are set as appropriate (Scored)
#### 1.2.29 Ensure that the `--etcd-certfile` and `--etcd-keyfile` arguments are set as appropriate (Scored)
**Result:** PASS
@@ -963,8 +963,8 @@ Then, edit the API server pod specification file `/etc/kubernetes/manifests/kube
on the master node and set the **etcd** certificate and **key** file parameters.
``` bash
--etcd-certfile=<path/to/client-certificate-file>
--etcd-keyfile=<path/to/client-key-file>
`--etcd-certfile=<path/to/client-certificate-file>`
`--etcd-keyfile=<path/to/client-key-file>`
```
**Audit:**
@@ -989,8 +989,8 @@ Then, edit the API server pod specification file `/etc/kubernetes/manifests/kube
on the master node and set the TLS certificate and private key file parameters.
``` bash
--tls-cert-file=<path/to/tls-certificate-file>
--tls-private-key-file=<path/to/tls-key-file>
`--tls-cert-file=<path/to/tls-certificate-file>`
`--tls-private-key-file=<path/to/tls-key-file>`
```
**Audit:**
@@ -1015,7 +1015,7 @@ Then, edit the API server pod specification file `/etc/kubernetes/manifests/kube
on the master node and set the client certificate authority file.
``` bash
--client-ca-file=<path/to/client-ca-file>
`--client-ca-file=<path/to/client-ca-file>`
```
**Audit:**
@@ -1040,7 +1040,7 @@ Then, edit the API server pod specification file `/etc/kubernetes/manifests/kube
on the master node and set the etcd certificate authority file parameter.
``` bash
--etcd-cafile=<path/to/ca-file>
`--etcd-cafile=<path/to/ca-file>`
```
**Audit:**
@@ -1202,7 +1202,7 @@ on the master node and set the `--service-account-private-key-file` parameter
to the private key file for service accounts.
``` bash
--service-account-private-key-file=<filename>
`--service-account-private-key-file=<filename>`
```
**Audit:**
@@ -1226,7 +1226,7 @@ Edit the Controller Manager pod specification file `/etc/kubernetes/manifests/ku
on the master node and set the `--root-ca-file` parameter to the certificate bundle file`.
``` bash
--root-ca-file=<path/to/file>
`--root-ca-file=<path/to/file>`
```
**Audit:**
@@ -1311,7 +1311,7 @@ on the master node and set the below parameter.
'false' is equal to 'false'
```
#### 1.4.2 Ensure that the `--bind-address` argument is set to `127.0.0.1` (Scored)
#### 1.4.2 Ensure that the `--bind-address` argument is set to `127.0.0.1` (Scored)
**Result:** PASS
@@ -1344,8 +1344,8 @@ Then, edit the etcd pod specification file `/etc/kubernetes/manifests/etcd.yaml`
on the master node and set the below parameters.
``` bash
--cert-file=</path/to/ca-file>
--key-file=</path/to/key-file>
`--cert-file=</path/to/ca-file>`
`--key-file=</path/to/key-file>`
```
**Audit:**
@@ -1418,8 +1418,8 @@ for your etcd cluster. Then, edit the etcd pod specification file `/etc/kubernet
master node and set the below parameters.
``` bash
--peer-client-file=</path/to/peer-cert-file>
--peer-key-file=</path/to/peer-key-file>
`--peer-client-file=</path/to/peer-cert-file>`
`--peer-key-file=</path/to/peer-key-file>`
```
**Audit:**
@@ -1485,7 +1485,7 @@ node and either remove the `--peer-auto-tls` parameter or set it to `false`.
## 3 Control Plane Configuration
### 3.2 Logging
#### 3.2.1 Ensure that a minimal audit policy is created (Scored)
#### 3.2.1 Ensure that a minimal audit policy is created (Scored)
**Result:** PASS
@@ -1546,7 +1546,7 @@ chmod 644 /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml
**Audit:**
```
/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; then stat -c %a /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; fi'
/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; then stat -c %a /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; fi'
```
**Expected result**:
@@ -1561,7 +1561,7 @@ chmod 644 /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml
**Remediation:**
Run the below command (based on the file location on your system) on the each worker node.
For example,
For example,
``` bash
chown root:root /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml
@@ -1570,7 +1570,7 @@ chown root:root /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml
**Audit:**
```
/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; then stat -c %U:%G /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; fi'
/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; then stat -c %U:%G /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; fi'
```
**Expected result**:
@@ -1594,7 +1594,7 @@ chmod 644 /etc/kubernetes/ssl/kubecfg-kube-node.yaml
**Audit:**
```
/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-node.yaml; then stat -c %a /etc/kubernetes/ssl/kubecfg-kube-node.yaml; fi'
/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-node.yaml; then stat -c %a /etc/kubernetes/ssl/kubecfg-kube-node.yaml; fi'
```
**Expected result**:
@@ -1618,7 +1618,7 @@ chown root:root /etc/kubernetes/ssl/kubecfg-kube-node.yaml
**Audit:**
```
/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-node.yaml; then stat -c %U:%G /etc/kubernetes/ssl/kubecfg-kube-node.yaml; fi'
/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-node.yaml; then stat -c %U:%G /etc/kubernetes/ssl/kubecfg-kube-node.yaml; fi'
```
**Expected result**:
@@ -1635,7 +1635,7 @@ chown root:root /etc/kubernetes/ssl/kubecfg-kube-node.yaml
Run the following command to modify the file permissions of the
``` bash
--client-ca-file chmod 644 <filename>
`--client-ca-file chmod 644 <filename>`
```
**Audit:**
@@ -1664,7 +1664,7 @@ chown root:root <filename>
**Audit:**
```
/bin/sh -c 'if test -e /etc/kubernetes/ssl/kube-ca.pem; then stat -c %U:%G /etc/kubernetes/ssl/kube-ca.pem; fi'
/bin/sh -c 'if test -e /etc/kubernetes/ssl/kube-ca.pem; then stat -c %U:%G /etc/kubernetes/ssl/kube-ca.pem; fi'
```
**Expected result**:
@@ -1703,7 +1703,7 @@ set the below parameter in `KUBELET_SYSTEM_PODS_ARGS` variable.
``` bash
--anonymous-auth=false
```
Based on your system, restart the kubelet service. For example:
``` bash
@@ -1780,7 +1780,7 @@ If using command line arguments, edit the kubelet service file
set the below parameter in `KUBELET_AUTHZ_ARGS` variable.
``` bash
--client-ca-file=<path/to/client-ca-file>
`--client-ca-file=<path/to/client-ca-file>`
```
Based on your system, restart the kubelet service. For example:
@@ -1926,7 +1926,7 @@ systemctl restart kubelet.service
'true' is equal to 'true'
```
#### 4.2.7 Ensure that the `--make-iptables-util-chains` argument is set to `true` (Scored)
#### 4.2.7 Ensure that the `--make-iptables-util-chains` argument is set to `true` (Scored)
**Result:** PASS
@@ -1938,7 +1938,7 @@ remove the `--make-iptables-util-chains` argument from the
`KUBELET_SYSTEM_PODS_ARGS` variable.
Based on your system, restart the kubelet service. For example:
```bash
```bash
systemctl daemon-reload
systemctl restart kubelet.service
```
@@ -2091,7 +2091,7 @@ exit 0
**Audit Execution:**
```
./5.1.5.sh
./5.1.5.sh
```
**Expected result**:
@@ -2218,7 +2218,7 @@ echo "pass"
**Audit Execution:**
```
./5.3.2.sh
./5.3.2.sh
```
**Expected result**:
@@ -2258,7 +2258,7 @@ echo "--count=${default_resources}"
**Audit Execution:**
```
./5.6.4.sh
./5.6.4.sh
```
**Expected result**:
versioned_docs/version-2.5/v2.5/en/admin-settings/rbac/cluster-project-roles/cluster-project-roles.md
+11 -4
View File
@@ -165,14 +165,21 @@ You can change the cluster or project role(s) that are automatically assigned to
1. Find the custom or individual role that you want to use as default. Then edit the role by selecting **&#8942; > Edit**.
1. Enable the role as default.
{{% accordion id="cluster" label="For Clusters" %}}
<details id="cluster">
<summary>For Clusters</summary>
1. From **Cluster Creator Default**, choose **Yes: Default role for new cluster creation**.
1. Click **Save**.
{{% /accordion %}}
{{% accordion id="project" label="For Projects" %}}
</details>
<details id="project">
<summary>For Projects</summary>
1. From **Project Creator Default**, choose **Yes: Default role for new project creation**.
1. Click **Save**.
{{% /accordion %}}
</details>
1. If you want to remove a default role, edit the permission and select **No** from the default roles option.
versioned_docs/version-2.5/v2.5/en/backups/docker-installs/docker-backups/docker-backups.md
+3 -2
View File
@@ -26,7 +26,8 @@ In this command, `<DATE>` is a placeholder for the date that the data container
Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the [procedure below](#creating-a-backup).
<sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;RANCHER_CONTAINER_TAG&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>
![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
| Placeholder | Example | Description |
@@ -57,7 +58,7 @@ This procedure creates a backup that you can restore if Rancher encounters a dis
docker create --volumes-from <RANCHER_CONTAINER_NAME> --name rancher-data-<DATE> rancher/rancher:<RANCHER_CONTAINER_TAG>
```
1. <a id="tarball"></a>From the data container that you just created (`rancher-data-<DATE>`), create a backup tarball (`rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz`). Use the following command, replacing each placeholder:
1. <a id="tarball"></a>From the data container that you just created (<code>rancher-data-&lt;DATE&gt;</code>), create a backup tarball (<code>rancher-data-backup-&lt;RANCHER_VERSION&gt;-&lt;DATE&gt;.tar.gz</code>). Use the following command, replacing each placeholder:
```
docker run --volumes-from rancher-data-<DATE> -v $PWD:/backup:z busybox tar pzcvf /backup/rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz /var/lib/rancher
versioned_docs/version-2.5/v2.5/en/backups/docker-installs/docker-restores/docker-restores.md
+2 -1
View File
@@ -25,7 +25,8 @@ In this command, `<RANCHER_CONTAINER_NAME>` and `<RANCHER_VERSION>-<DATE>` are e
Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the procedure below.
<sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;RANCHER_CONTAINER_TAG&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>
![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
| Placeholder | Example | Description |
versioned_docs/version-2.5/v2.5/en/backups/migrating-rancher/migrating-rancher.md
+7 -7
View File
@@ -29,11 +29,11 @@ helm repo update
helm install rancher-backup-crd rancher-charts/rancher-backup-crd -n cattle-resources-system --create-namespace --version $CHART_VERSION
helm install rancher-backup rancher-charts/rancher-backup -n cattle-resources-system --version $CHART_VERSION
```
</br>
<br/>
For an **air-gapped environment**, use the option below to pull the `backup-restore-operator` image from your private registry when installing the rancher-backup-crd helm chart.
```
--set image.repository $REGISTRY/rancher/backup-restore-operator
```
```
### 2. Restore from backup using a Restore custom resource
@@ -52,7 +52,7 @@ stringData:
This secret can be created in any namespace, with the above example it will get created in the default namespace
In the Restore custom resource, `prune` must be set to false.
In the Restore custom resource, `prune` must be set to false.
Create a Restore custom resource like the example below:
@@ -76,18 +76,18 @@ spec:
endpoint: s3.us-west-2.amazonaws.com
```
>**Important:** The field `encryptionConfigSecretName` must be set only if your backup was created with encryption enabled. Provide the name of the Secret containing the encryption config file. If you only have the encryption config file, but don't have a secret created with it in this cluster, use the following steps to create the secret:
>**Important:** The field `encryptionConfigSecretName` must be set only if your backup was created with encryption enabled. Provide the name of the Secret containing the encryption config file. If you only have the encryption config file, but don't have a secret created with it in this cluster, use the following steps to create the secret:
1. The encryption configuration file must be named `encryption-provider-config.yaml`, and the `--from-file` flag must be used to create this secret. So save your `EncryptionConfiguration` in a file called `encryption-provider-config.yaml` and run this command:
1. The encryption configuration file must be named `encryption-provider-config.yaml`, and the `--from-file` flag must be used to create this secret. So save your `EncryptionConfiguration` in a file called `encryption-provider-config.yaml` and run this command:
```
kubectl create secret generic encryptionconfig \
--from-file=./encryption-provider-config.yaml \
-n cattle-resources-system
```
1. Then apply the resource:
```
kubectl apply -f migrationResource.yaml
kubectl apply -f migrationResource.yaml
```
### 3. Install cert-manager
versioned_docs/version-2.5/v2.5/en/cluster-admin/cluster-admin.md
+2 -2
View File
@@ -23,9 +23,9 @@ Alternatively, you can switch between projects and clusters directly in the navi
## Managing Clusters in Rancher
After clusters have been [provisioned into Rancher]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/), [cluster owners]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) will need to manage these clusters. There are many different options of how to manage your cluster.
After clusters have been [provisioned into Rancher]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/), [cluster owners]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) will need to manage these clusters. There are many different options of how to manage your cluster.
{{% include file="/rancher/v2.5/en/cluster-provisioning/cluster-capabilities-table" %}}
{{% include file="/rancher/v2.5/en/cluster-provisioning/cluster-capabilities-table</summary>
## Configuring Tools
versioned_docs/version-2.5/v2.5/en/cluster-admin/cluster-autoscaler/amazon/amazon.md
+11 -11
View File
@@ -7,7 +7,7 @@ aliases:
This guide will show you how to install and use [Kubernetes cluster-autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/) on Rancher custom clusters using AWS EC2 Auto Scaling Groups.
We are going to install a Rancher RKE custom cluster with a fixed number of nodes with the etcd and controlplane roles, and a variable nodes with the worker role, managed by `cluster-autoscaler`.
We are going to install a Rancher RKE custom cluster with a fixed number of nodes with the etcd and controlplane roles, and a variable nodes with the worker role, managed by `cluster-autoscaler`.
- [Prerequisites](#prerequisites)
- [1. Create a Custom Cluster](#1-create-a-custom-cluster)
@@ -70,7 +70,7 @@ On AWS EC2, we should create a few objects to configure our system. We've define
}
```
2. Master group: Nodes that will be part of the Kubernetes etcd and/or control planes. This will be out of the ASG.
2. Master group: Nodes that will be part of the Kubernetes etcd and/or control planes. This will be out of the ASG.
* IAM profile: Required by the Kubernetes cloud_provider integration. Optionally, `AWS_ACCESS_KEY` and `AWS_SECRET_KEY` can be used instead [using-aws-credentials.](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#using-aws-credentials) This profile is called `K8sMasterProfile`.
```json
@@ -213,7 +213,7 @@ On AWS EC2, we should create a few objects to configure our system. We've define
* `kubernetes.io/cluster/<clusterID>: owned`
* `k8s.io/cluster-autoscaler/<clusterName>: true`
* `k8s.io/cluster-autoscaler/enabled: true`
* User data: `K8sWorkerUserData` Ubuntu 18.04(ami-0e11cbb34015ff725), installs docker and add worker node to the k8s cluster
* User data: `K8sWorkerUserData` Ubuntu 18.04(ami-0e11cbb34015ff725), installs docker and add worker node to the k8s cluster
```sh
#!/bin/bash -x
@@ -248,7 +248,7 @@ Once we've configured AWS, let's create VMs to bootstrap our cluster:
* master (etcd+controlplane): Depending your needs, deploy three master instances with proper size. More info is at [the recommendations for production-ready clusters.]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/production/)
* IAM role: `K8sMasterRole`
* Security group: `K8sMasterSg`
* Tags:
* Tags:
* `kubernetes.io/cluster/<clusterID>: owned`
* User data: `K8sMasterUserData`
@@ -256,7 +256,7 @@ Once we've configured AWS, let's create VMs to bootstrap our cluster:
* Name: `K8sWorkerAsg`
* IAM role: `K8sWorkerRole`
* Security group: `K8sWorkerSg`
* Tags:
* Tags:
* `kubernetes.io/cluster/<clusterID>: owned`
* `k8s.io/cluster-autoscaler/<clusterName>: true`
* `k8s.io/cluster-autoscaler/enabled: true`
@@ -270,7 +270,7 @@ Once the VMs are deployed, you should have a Rancher custom cluster up and runni
### 4. Install Cluster-autoscaler
At this point, we should have rancher cluster up and running. We are going to install cluster-autoscaler on master nodes and `kube-system` namespace, following cluster-autoscaler recommendation.
At this point, we should have rancher cluster up and running. We are going to install cluster-autoscaler on master nodes and `kube-system` namespace, following cluster-autoscaler recommendation.
#### Parameters
@@ -298,9 +298,9 @@ This table shows cluster-autoscaler parameters for fine tuning:
|node-deletion-delay-timeout|"2m"|Maximum time CA waits for removing delay-deletion.cluster-autoscaler.kubernetes.io/ annotations before deleting the node|
|scan-interval|"10s"|How often cluster is reevaluated for scale up or down|
|max-nodes-total|0|Maximum number of nodes in all node groups. Cluster autoscaler will not grow the cluster beyond this number|
|cores-total|"0:320000"|Minimum and maximum number of cores in cluster, in the format <min>:<max>. Cluster autoscaler will not scale the cluster beyond these numbers|
|memory-total|"0:6400000"|Minimum and maximum number of gigabytes of memory in cluster, in the format <min>:<max>. Cluster autoscaler will not scale the cluster beyond these numbers|
cloud-provider|-|Cloud provider type|
|cores-total|"0:320000"|Minimum and maximum number of cores in cluster, in the format `<min>:<max>.` Cluster autoscaler will not scale the cluster beyond these numbers|
|memory-total|"0:6400000"|Minimum and maximum number of gigabytes of memory in cluster, in the format `<min>:<max>.` Cluster autoscaler will not scale the cluster beyond these numbers|
cloud-provider|-|Cloud provider type|
|max-bulk-soft-taint-count|10|Maximum number of nodes that can be tainted/untainted PreferNoSchedule at the same time. Set to 0 to turn off such tainting|
|max-bulk-soft-taint-time|"3s"|Maximum duration of tainting/untainting nodes as PreferNoSchedule at the same time|
|max-empty-bulk-delete|10|Maximum number of empty nodes that can be deleted at the same time|
@@ -309,7 +309,7 @@ cloud-provider|-|Cloud provider type|
|ok-total-unready-count|3|Number of allowed unready nodes, irrespective of max-total-unready-percentage|
|scale-up-from-zero|true|Should CA scale up when there 0 ready nodes|
|max-node-provision-time|"15m"|Maximum time CA waits for node to be provisioned|
|nodes|-|sets min,max size and other configuration data for a node group in a format accepted by cloud provider. Can be used multiple times. Format: <min>:<max>:<other...>|
|nodes|-|sets min,max size and other configuration data for a node group in a format accepted by cloud provider. Can be used multiple times. Format: `<min>:<max>:<other...>`|
|node-group-auto-discovery|-|One or more definition(s) of node group auto-discovery. A definition is expressed `<name of discoverer>:[<key>[=<value>]]`|
|estimator|-|"binpacking"|Type of resource estimator to be used in scale up. Available values: ["binpacking"]|
|expander|"random"|Type of node group expander to be used in scale up. Available values: `["random","most-pods","least-waste","price","priority"]`|
@@ -522,7 +522,7 @@ kubectl -n kube-system apply -f cluster-autoscaler-deployment.yaml
# Testing
At this point, we should have a cluster-scaler up and running in our Rancher custom cluster. Cluster-scale should manage `K8sWorkerAsg` ASG to scale up and down between 2 and 10 nodes, when one of the following conditions is true:
At this point, we should have a cluster-scaler up and running in our Rancher custom cluster. Cluster-scale should manage `K8sWorkerAsg` ASG to scale up and down between 2 and 10 nodes, when one of the following conditions is true:
* There are pods that failed to run in the cluster due to insufficient resources. In this case, the cluster is scaled up.
* There are nodes in the cluster that have been underutilized for an extended period of time and their pods can be placed on other existing nodes. In this case, the cluster is scaled down.
versioned_docs/version-2.5/v2.5/en/cluster-admin/editing-clusters/editing-clusters.md
+1 -1
View File
@@ -24,5 +24,5 @@ The options and settings available for an existing cluster change based on the m
The following table summarizes the options and settings available for each cluster type:
{{% include file="/rancher/v2.5/en/cluster-provisioning/cluster-capabilities-table" %}}
{{% include file="/rancher/v2.5/en/cluster-provisioning/cluster-capabilities-table</summary>
versioned_docs/version-2.5/v2.5/en/cluster-admin/editing-clusters/eks-config-reference/eks-config-reference.md
+8 -4
View File
@@ -341,7 +341,8 @@ Option | Description
If you choose to assign a public IP address to your cluster's worker nodes, you have the option of choosing between a VPC that's automatically generated by Rancher (i.e., **Standard: Rancher generated VPC and Subnet**), or a VPC that you've already created with AWS (i.e., **Custom: Choose from your existing VPC and Subnets**). Choose the option that best fits your use case.
{{% accordion id="yes" label="Click to expand" %}}
<details id="yes">
<summary>Click to expand</summary>
If you're using **Custom: Choose from your existing VPC and Subnets**:
@@ -354,10 +355,13 @@ If you're using **Custom: Choose from your existing VPC and Subnets**:
1. Click **Next: Select Subnets**. Then choose one of the **Subnets** that displays.
1. Click **Next: Select Security Group**.
{{% /accordion %}}
</details>
If your worker nodes have Private IPs only, you must also choose a **VPC & Subnet** that allow your instances to access the internet. This access is required so that your worker nodes can connect to the Kubernetes control plane.
{{% accordion id="no" label="Click to expand" %}}
<details id="no">
<summary>Click to expand</summary>
Follow the steps below.
>**Tip:** When using only private IP addresses, you can provide your nodes internet access by creating a VPC constructed with two subnets, a private set and a public set. The private set should have its route tables configured to point toward a NAT in the public set. For more information on routing traffic from private subnets, please see the [official AWS documentation](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html).
@@ -366,7 +370,7 @@ Follow the steps below.
1. Click **Next: Select Subnets**. Then choose one of the **Subnets** that displays.
{{% /accordion %}}
</details>
### Security Group
versioned_docs/version-2.5/v2.5/en/cluster-admin/volumes-and-storage/iscsi-volumes/iscsi-volumes.md
+3 -3
View File
@@ -20,9 +20,9 @@ If you encounter this issue, you can work around it by installing the initiator
After installing the initiator tool on your nodes, edit the YAML for your cluster, editing the kubelet configuration to mount the iSCSI binary and configuration, as shown in the sample below.
>**Notes:**
>
>- Before updating your Kubernetes YAML to mount the iSCSI binary and configuration, make sure either the `open-iscsi` (deb) or `iscsi-initiator-utils` (yum) package is installed on your cluster nodes. If this package isn't installed _before_ the bind mounts are created in your Kubernetes YAML, Docker will automatically create the directories and files on each node and will not allow the package install to succeed.</br>
></br>
>
>- Before updating your Kubernetes YAML to mount the iSCSI binary and configuration, make sure either the `open-iscsi` (deb) or `iscsi-initiator-utils` (yum) package is installed on your cluster nodes. If this package isn't installed _before_ the bind mounts are created in your Kubernetes YAML, Docker will automatically create the directories and files on each node and will not allow the package install to succeed.<br/>
><br/>
>
>- The example YAML below does not apply to K3s, but only to RKE clusters. Since the K3s kubelet does not run in a container, adding extra binds is not necessary. However, all iSCSI tools must still be installed on your K3s nodes.
versioned_docs/version-2.5/v2.5/en/cluster-provisioning/cluster-provisioning.md
+1 -1
View File
@@ -32,7 +32,7 @@ This section covers the following topics:
The following table summarizes the options and settings available for each cluster type:
{{% include file="/rancher/v2.5/en/cluster-provisioning/cluster-capabilities-table" %}}
{{% include file="/rancher/v2.5/en/cluster-provisioning/cluster-capabilities-table</summary>
# Setting up Clusters in a Hosted Kubernetes Provider
versioned_docs/version-2.5/v2.5/en/cluster-provisioning/rke-clusters/cloud-providers/azure/azure.md
+1 -1
View File
@@ -31,7 +31,7 @@ Visit [Azure portal](https://portal.azure.com), login and go to **Azure Active D
If you want to use the Azure CLI, you can run the command `az account show` to get the information.
### 2. Set up the Azure Client ID and Azure Client Secret
### 2. Set up the Azure Client ID and Azure Client Secret
Visit [Azure portal](https://portal.azure.com), login and follow the steps below to create an **App Registration** and the corresponding **Azure Client ID** (aadClientId) and **Azure Client Secret** (aadClientSecret).
versioned_docs/version-2.5/v2.5/en/cluster-provisioning/rke-clusters/options/options.md
+3 -2
View File
@@ -177,7 +177,8 @@ Instead of using the Rancher UI to choose Kubernetes options for the cluster, ad
RKE (Rancher Kubernetes Engine) is the tool that Rancher uses to provision Kubernetes clusters. Rancher's cluster config files used to have the same structure as [RKE config files,]({{<baseurl>}}/rke/latest/en/example-yamls/) but the structure changed so that in Rancher, RKE cluster config items are separated from non-RKE config items. Therefore, configuration for your cluster needs to be nested under the `rancher_kubernetes_engine_config` directive in the cluster config file. Cluster config files created with earlier versions of Rancher will need to be updated for this format. An example cluster config file is included below.
{{% accordion id="v2.3.0-cluster-config-file" label="Example Cluster Config File" %}}
<details id="v2.3.0-cluster-config-file">
<summary>Example Cluster Config File</summary>
```yaml
#
@@ -269,7 +270,7 @@ rancher_kubernetes_engine_config: # Your RKE template config goes here.
ssh_agent_auth: false
windows_prefered_cluster: false
```
{{% /accordion %}}
</details>
### Default DNS provider
versioned_docs/version-2.5/v2.5/en/installation/install-rancher-on-k8s/install-rancher-on-k8s.md
+3 -2
View File
@@ -120,7 +120,8 @@ There are three recommended options for the source of the certificate used for T
This step is only required to use certificates issued by Rancher's generated CA (`ingress.tls.source=rancher`) or to request Let's Encrypt issued certificates (`ingress.tls.source=letsEncrypt`).
{{% accordion id="cert-manager" label="Click to Expand" %}}
<details id="cert-manager">
<summary>Click to Expand</summary>
> **Important:** Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.11.0, please see our [upgrade documentation]({{<baseurl>}}/rancher/v2.5/en/installation/options/upgrading-cert-manager/).
@@ -154,7 +155,7 @@ cert-manager-cainjector-577f6d9fd7-tr77l 1/1 Running 0 2m
cert-manager-webhook-787858fcdb-nlzsq 1/1 Running 0 2m
```
{{% /accordion %}}
</details>
### 5. Install Rancher with Helm and Your Chosen Certificate Option
versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/air-gap/install-rancher/docker-install-commands/docker-install-commands.md
+11 -8
View File
@@ -3,9 +3,9 @@ title: Docker Install Commands
weight: 1
---
The Docker installation is for Rancher users who want to test out Rancher.
The Docker installation is for Rancher users who want to test out Rancher.
Instead of running on a Kubernetes cluster, you install the Rancher server component on a single node using a `docker run` command. Since there is only one node and a single Docker container, if the node goes down, there is no copy of the etcd data available on other nodes and you will lose all the data of your Rancher server.
Instead of running on a Kubernetes cluster, you install the Rancher server component on a single node using a `docker run` command. Since there is only one node and a single Docker container, if the node goes down, there is no copy of the etcd data available on other nodes and you will lose all the data of your Rancher server.
For Rancher v2.5+, the backup application can be used to migrate the Rancher server from a Docker install to a Kubernetes install using [these steps.]({{<baseurl>}}/rancher/v2.5/en/backups/migrating-rancher)
@@ -25,7 +25,8 @@ Choose from the following options:
### Option A: Default Self-Signed Certificate
{{% accordion id="option-a" label="Click to expand" %}}
<details id="option-a">
<summary>Click to expand</summary>
If you are installing Rancher in a development or testing environment where identity verification isn't a concern, install Rancher using the self-signed certificate that it generates. This installation option omits the hassle of generating a certificate yourself.
@@ -47,11 +48,12 @@ docker run -d --restart=unless-stopped \
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
```
{{% /accordion %}}
</details>
### Option B: Bring Your Own Certificate: Self-Signed
{{% accordion id="option-b" label="Click to expand" %}}
<details id="option-b">
<summary>Click to expand</summary>
In development or testing environments where your team will access your Rancher server, create a self-signed certificate for use with your install so that your team can verify they're connecting to your instance of Rancher.
@@ -86,11 +88,12 @@ docker run -d --restart=unless-stopped \
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
```
{{% /accordion %}}
</details>
### Option C: Bring Your Own Certificate: Signed by Recognized CA
{{% accordion id="option-c" label="Click to expand" %}}
<details id="option-c">
<summary>Click to expand</summary>
In development or testing environments where you're exposing an app publicly, use a certificate signed by a recognized CA so that your user base doesn't encounter security warnings.
@@ -122,7 +125,7 @@ docker run -d --restart=unless-stopped \
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
```
{{% /accordion %}}
</details>
versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
+4 -3
View File
@@ -76,7 +76,7 @@ When setting up the Rancher Helm template, there are several options in the Helm
| Chart Option | Chart Value | Description |
| ----------------------- | -------------------------------- | ---- |
| `certmanager.version` | "<version>" | Configure proper Rancher TLS issuer depending of running cert-manager version. |
| `certmanager.version` | `<version>` | Configure proper Rancher TLS issuer depending of running cert-manager version. |
| `systemDefaultRegistry` | `<REGISTRY.YOURDOMAIN.COM:PORT>` | Configure Rancher server to always pull from your private registry when provisioning clusters. |
| `useBundledSystemChart` | `true` | Configure Rancher server to use the packaged copy of Helm system charts. The [system charts](https://github.com/rancher/system-charts) repository contains all the catalog items required for features such as monitoring, logging, alerting and global DNS. These [Helm charts](https://github.com/rancher/system-charts) are located in GitHub, but since you are in an air gapped environment, using the charts that are bundled within Rancher is much easier than setting up a Git mirror. |
@@ -272,7 +272,8 @@ If you choose to use self-signed certificates in [B. Choose your SSL Configurati
### For Self-Signed Certificate Installs, Install Cert-manager
{{% accordion id="install-cert-manager" label="Click to expand" %}}
<details id="install-cert-manager">
<summary>Click to expand</summary>
If you are using self-signed certificates, install cert-manager:
@@ -294,7 +295,7 @@ kubectl apply -f cert-manager/cert-manager-crd.yaml
kubectl apply -R -f ./cert-manager
```
{{% /accordion %}}
</details>
### Install Rancher with kubectl
versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-rollbacks/single-node-rollbacks.md
+2 -3
View File
@@ -24,8 +24,7 @@ In this command, `<PRIOR_RANCHER_VERSION>` is the version of Rancher you were ru
Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the procedure below.
<sup>Terminal `docker ps` Command, Displaying Where to Find `<PRIOR_RANCHER_VERSION>` and `<RANCHER_CONTAINER_NAME>`</sup>
![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref-2.png)
<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;PRIOR_RANCHER_VERSION&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref-2.png)
| Placeholder | Example | Description |
| -------------------------- | -------------------------- | ------------------------------------------------------- |
@@ -81,7 +80,7 @@ If you have issues upgrading Rancher, roll it back to its latest known healthy s
rancher/rancher:<PRIOR_RANCHER_VERSION>
```
As of Rancher v2.5, privileged access is [required.]({{<baseurl>}}/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher-v2-5)
>**Note:** _Do not_ stop the rollback after initiating it, even if the rollback process seems longer than expected. Stopping the rollback may result in database issues during future upgrades.
1. Wait a few moments and then open Rancher in a web browser. Confirm that the rollback succeeded and that your data is restored.
versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
+24 -16
View File
@@ -42,7 +42,8 @@ docker ps
Write down or copy this information before starting the upgrade.
<sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;RANCHER_CONTAINER_TAG&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>
![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
| Placeholder | Example | Description |
@@ -84,7 +85,7 @@ During upgrade, you create a copy of the data from your current Rancher containe
# 2. Create a backup tarball
1. <a id="tarball"></a>From the data container that you just created (`rancher-data`), create a backup tarball (`rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz`).
1. <a id="tarball"></a>From the data container that you just created (<code>rancher-data</code>), create a backup tarball (<code>rancher-data-backup-&lt;RANCHER_VERSION&gt;-&lt;DATE&gt;.tar.gz</code>).
This tarball will serve as a rollback point if something goes wrong during upgrade. Use the following command, replacing each placeholder.
@@ -140,7 +141,8 @@ Select which option you had installed Rancher server
### Option A: Default Self-Signed Certificate
{{% accordion id="option-a" label="Click to expand" %}}
<details id="option-a">
<summary>Click to expand</summary>
If you have selected to use the Rancher generated self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container.
@@ -158,11 +160,12 @@ docker run -d --volumes-from rancher-data \
As of Rancher v2.5, privileged access is [required.]({{<baseurl>}}/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher-v2-5)
{{% /accordion %}}
</details>
### Option B: Bring Your Own Certificate: Self-Signed
{{% accordion id="option-b" label="Click to expand" %}}
<details id="option-b">
<summary>Click to expand</summary>
If you have selected to bring your own self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificate that you had originally installed with.
@@ -189,11 +192,12 @@ docker run -d --volumes-from rancher-data \
As of Rancher v2.5, privileged access is [required.]({{<baseurl>}}/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher-v2-5)
{{% /accordion %}}
</details>
### Option C: Bring Your Own Certificate: Signed by Recognized CA
{{% accordion id="option-c" label="Click to expand" %}}
<details id="option-c">
<summary>Click to expand</summary>
If you have selected to use a certificate signed by a recognized CA, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificates that you had originally installed with. Remember to include `--no-cacerts` as an argument to the container to disable the default CA certificate generated by Rancher.
@@ -218,11 +222,12 @@ docker run -d --volumes-from rancher-data \
```
As of Rancher v2.5, privileged access is [required.]({{<baseurl>}}/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher-v2-5)
{{% /accordion %}}
</details>
### Option D: Let's Encrypt Certificate
{{% accordion id="option-d" label="Click to expand" %}}
<details id="option-d">
<summary>Click to expand</summary>
>**Remember:** Let's Encrypt provides rate limits for requesting new certificates. Therefore, limit how often you create or destroy the container. For more information, see [Let's Encrypt documentation on rate limits](https://letsencrypt.org/docs/rate-limits/).
@@ -249,7 +254,7 @@ docker run -d --volumes-from rancher-data \
As of Rancher v2.5, privileged access is [required.]({{<baseurl>}}/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher-v2-5)
{{% /accordion %}}
</details>
</TabItem>
<TabItem value="Docker Air Gap Upgrade">
@@ -260,7 +265,8 @@ When starting the new Rancher server container, choose from the following option
### Option A: Default Self-Signed Certificate
{{% accordion id="option-a" label="Click to expand" %}}
<details id="option-a">
<summary>Click to expand</summary>
If you have selected to use the Rancher generated self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container.
@@ -280,11 +286,12 @@ Placeholder | Description
```
As of Rancher v2.5, privileged access is [required.]({{<baseurl>}}/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher-v2-5)
{{% /accordion %}}
</details>
### Option B: Bring Your Own Certificate: Self-Signed
{{% accordion id="option-b" label="Click to expand" %}}
<details id="option-b">
<summary>Click to expand</summary>
If you have selected to bring your own self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificate that you had originally installed with.
@@ -311,11 +318,12 @@ docker run -d --restart=unless-stopped \
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
```
As of Rancher v2.5, privileged access is [required.]({{<baseurl>}}/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher-v2-5)
{{% /accordion %}}
</details>
### Option C: Bring Your Own Certificate: Signed by Recognized CA
{{% accordion id="option-c" label="Click to expand" %}}
<details id="option-c">
<summary>Click to expand</summary>
If you have selected to use a certificate signed by a recognized CA, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificates that you had originally installed with.
@@ -344,7 +352,7 @@ docker run -d --volumes-from rancher-data \
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
```
As of Rancher v2.5, privileged access is [required.]({{<baseurl>}}/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher-v2-5)
{{% /accordion %}}
</details>
</TabItem>
</Tabs>
versioned_docs/version-2.5/v2.5/en/installation/requirements/ports/ports.md
+25 -17
View File
@@ -43,7 +43,8 @@ As of Rancher v2.5, Rancher can be installed on any Kubernetes cluster. For Ranc
### Ports for Rancher Server Nodes on K3s
{{% accordion label="Click to expand" %}}
<details>
<summary>Click to expand</summary>
The K3s server needs port 6443 to be accessible by the nodes.
@@ -74,11 +75,12 @@ The following tables break down the port requirements for inbound and outbound t
| TCP | 2376 | Any node IP from a node created using Node driver | Docker daemon TLS port used by Docker Machine |
| TCP | 6443 | Hosted/Imported Kubernetes API | Kubernetes API server |
{{% /accordion %}}
</details>
### Ports for Rancher Server Nodes on RKE
{{% accordion label="Click to expand" %}}
<details>
<summary>Click to expand</summary>
Typically Rancher is installed on three RKE nodes that all have the etcd, control plane and worker roles.
@@ -118,13 +120,14 @@ The following tables break down the port requirements for inbound and outbound t
| TCP | 6443 | Hosted/Imported Kubernetes API | Kubernetes API server |
| TCP | Provider dependent | Port of the Kubernetes API endpoint in hosted cluster | Kubernetes API |
{{% /accordion %}}
</details>
### Ports for Rancher Server Nodes on RancherD or RKE2
> **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.
{{% accordion label="Click to expand" %}}
<details>
<summary>Click to expand</summary>
The RancherD (or RKE2) server needs port 6443 and 9345 to be accessible by other nodes in the cluster.
@@ -149,11 +152,12 @@ If you wish to utilize the metrics server, you will need to open port 10250 on e
| HTTPS | 8443 | <ul><li>hosted/registered Kubernetes</li><li>any source that needs to be able to use the Rancher UI or API</li></ul> | Rancher agent, Rancher UI/API, kubectl. Not needed if you have LB doing TLS termination. |
Typically all outbound traffic is allowed.
{{% /accordion %}}
</details>
### Ports for Rancher Server in Docker
{{% accordion label="Click to expand" %}}
<details>
<summary>Click to expand</summary>
The following tables break down the port requirements for Rancher nodes, for inbound and outbound traffic:
@@ -173,7 +177,7 @@ The following tables break down the port requirements for Rancher nodes, for inb
| TCP | 2376 | Any node IP from a node created using a node driver | Docker daemon TLS port used by Docker Machine |
| TCP | 6443 | Hosted/Imported Kubernetes API | Kubernetes API server |
{{% /accordion %}}
</details>
# Downstream Kubernetes Cluster Nodes
@@ -193,7 +197,8 @@ The following diagram depicts the ports that are opened for each [cluster type](
### Ports for Rancher Launched Kubernetes Clusters using Node Pools
{{% accordion label="Click to expand" %}}
<details>
<summary>Click to expand</summary>
The following table depicts the port requirements for [Rancher Launched Kubernetes]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/) with nodes created in an [Infrastructure Provider]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/node-pools/).
@@ -202,39 +207,42 @@ The following table depicts the port requirements for [Rancher Launched Kubernet
{{< ports-iaas-nodes >}}
{{% /accordion %}}
</details>
### Ports for Rancher Launched Kubernetes Clusters using Custom Nodes
{{% accordion label="Click to expand" %}}
<details>
<summary>Click to expand</summary>
The following table depicts the port requirements for [Rancher Launched Kubernetes]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/) with [Custom Nodes]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/custom-nodes/).
{{< ports-custom-nodes >}}
{{% /accordion %}}
</details>
### Ports for Hosted Kubernetes Clusters
{{% accordion label="Click to expand" %}}
<details>
<summary>Click to expand</summary>
The following table depicts the port requirements for [hosted clusters]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/hosted-kubernetes-clusters).
{{< ports-imported-hosted >}}
{{% /accordion %}}
</details>
### Ports for Registered Clusters
Note: Registered clusters were called imported clusters before Rancher v2.5.
{{% accordion label="Click to expand" %}}
<details>
<summary>Click to expand</summary>
The following table depicts the port requirements for [registered clusters]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/registered-clusters/).
{{< ports-imported-hosted >}}
{{% /accordion %}}
</details>
# Other Port Considerations
@@ -243,7 +251,7 @@ The following table depicts the port requirements for [registered clusters]({{<b
These ports are typically opened on your Kubernetes nodes, regardless of what type of cluster it is.
{{% include file="/rancher/v2.5/en/installation/requirements/ports/common-ports-table" %}}
{{% include file="/rancher/v2.5/en/installation/requirements/ports/common-ports-table</summary>
----
versioned_docs/version-2.5/v2.5/en/installation/resources/advanced/single-node-install-external-lb/single-node-install-external-lb.md
+8 -4
View File
@@ -49,7 +49,9 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher
Choose from the following options:
{{% accordion id="option-a" label="Option A-Bring Your Own Certificate: Self-Signed" %}}
<details id="option-a">
<summary>Option A-Bring Your Own Certificate: Self-Signed</summary>
If you elect to use a self-signed certificate to encrypt communication, you must install the certificate on your load balancer (which you'll do later) and your Rancher container. Run the Docker command to deploy Rancher, pointing it toward your certificate.
> **Prerequisites:**
@@ -68,8 +70,10 @@ If you elect to use a self-signed certificate to encrypt communication, you must
rancher/rancher:latest
```
{{% /accordion %}}
{{% accordion id="option-b" label="Option B-Bring Your Own Certificate: Signed by Recognized CA" %}}
</details>
<details id="option-b">
<summary>Option B-Bring Your Own Certificate: Signed by Recognized CA</summary>
If your cluster is public facing, it's best to use a certificate signed by a recognized CA.
> **Prerequisites:**
@@ -88,7 +92,7 @@ If you use a certificate signed by a recognized CA, installing your certificate
rancher/rancher:latest --no-cacerts
```
{{% /accordion %}}
</details>
## 3. Configure Load Balancer
versioned_docs/version-2.5/v2.5/en/installation/resources/upgrading-cert-manager/helm-2-instructions/helm-2-instructions.md
+12 -8
View File
@@ -22,22 +22,24 @@ To address these changes, this guide will do two things:
> 1. Take a one-time snapshot of your Kubernetes cluster running Rancher server
> 2. Uninstall Rancher, cert-manager, and the CustomResourceDefinition for cert-manager
> 3. Install the newer version of Rancher and cert-manager
> 3. Install the newer version of Rancher and cert-manager
> The reason is that when Helm upgrades Rancher, it will reject the upgrade and show error messages if the running Rancher app does not match the chart template used to install it. Because cert-manager changed its API group and we cannot modify released charts for Rancher, there will always be a mismatch on the cert-manager's API version, therefore the upgrade will be rejected.
> For reinstalling Rancher with Helm, please check [Option B: Reinstalling Rancher Chart]({{<baseurl>}}/rancher/v2.5/en/installation/upgrades-rollbacks/upgrades/ha/) under the upgrade Rancher section.
> For reinstalling Rancher with Helm, please check [Option B: Reinstalling Rancher Chart]({{<baseurl>}}/rancher/v2.5/en/installation/upgrades-rollbacks/upgrades/ha/) under the upgrade Rancher section.
## Upgrade Cert-Manager Only
## Upgrade Cert-Manager Only
> **Note:**
> These instructions are applied if you have no plan to upgrade Rancher.
> These instructions are applied if you have no plan to upgrade Rancher.
The namespace used in these instructions depends on the namespace cert-manager is currently installed in. If it is in kube-system use that in the instructions below. You can verify by running `kubectl get pods --all-namespaces` and checking which namespace the cert-manager-\* pods are listed in. Do not change the namespace cert-manager is running in or this can cause issues.
In order to upgrade cert-manager, follow these instructions:
{{% accordion id="normal" label="Upgrading cert-manager with Internet access" %}}
<details id="normal">
<summary>Upgrading cert-manager with Internet access</summary>
1. Back up existing resources as a precaution
```plain
@@ -73,9 +75,11 @@ In order to upgrade cert-manager, follow these instructions:
```plain
helm install --version 0.12.0 --name cert-manager --namespace kube-system jetstack/cert-manager
```
{{% /accordion %}}
</details>
<details id="airgap">
<summary>Upgrading cert-manager in an airgapped environment</summary>
{{% accordion id="airgap" label="Upgrading cert-manager in an airgapped environment" %}}
### Prerequisites
Before you can perform the upgrade, you must prepare your air gapped environment by adding the necessary container images to your private registry and downloading or rendering the required Kubernetes manifest files.
@@ -137,7 +141,7 @@ Before you can perform the upgrade, you must prepare your air gapped environment
```plain
kubectl -n kube-system apply -R -f ./cert-manager
```
{{% /accordion %}}
</details>
Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the kube-system namespace for running pods:
versioned_docs/version-2.5/v2.5/en/installation/resources/upgrading-cert-manager/upgrading-cert-manager.md
+11 -8
View File
@@ -24,11 +24,11 @@ To address these changes, this guide will do two things:
> 1. Take a one-time snapshot of your Kubernetes cluster running Rancher server
> 2. Uninstall Rancher, cert-manager, and the CustomResourceDefinition for cert-manager
> 3. Install the newer version of Rancher and cert-manager
> 3. Install the newer version of Rancher and cert-manager
> The reason is that when Helm upgrades Rancher, it will reject the upgrade and show error messages if the running Rancher app does not match the chart template used to install it. Because cert-manager changed its API group and we cannot modify released charts for Rancher, there will always be a mismatch on the cert-manager's API version, therefore the upgrade will be rejected.
> For reinstalling Rancher with Helm, please check [Option B: Reinstalling Rancher Chart]({{<baseurl>}}/rancher/v2.5/en/installation/upgrades-rollbacks/upgrades/ha/) under the upgrade Rancher section.
> For reinstalling Rancher with Helm, please check [Option B: Reinstalling Rancher Chart]({{<baseurl>}}/rancher/v2.5/en/installation/upgrades-rollbacks/upgrades/ha/) under the upgrade Rancher section.
# Upgrade Cert-Manager
@@ -40,7 +40,9 @@ In order to upgrade cert-manager, follow these instructions:
### Option A: Upgrade cert-manager with Internet Access
{{% accordion id="normal" label="Click to expand" %}}
<details id="normal">
<summary>Click to expand</summary>
1. [Back up existing resources](https://cert-manager.io/docs/tutorials/backup/) as a precaution
```plain
@@ -96,7 +98,7 @@ In order to upgrade cert-manager, follow these instructions:
helm install \
cert-manager jetstack/cert-manager \
--namespace cert-manager \
--version v0.12.0
--version v0.12.0
```
1. [Restore back up resources](https://cert-manager.io/docs/tutorials/backup/#restoring-resources)
@@ -105,11 +107,12 @@ In order to upgrade cert-manager, follow these instructions:
kubectl apply -f cert-manager-backup.yaml
```
{{% /accordion %}}
</details>
### Option B: Upgrade cert-manager in an Air Gap Environment
{{% accordion id="airgap" label="Click to expand" %}}
<details id="airgap">
<summary>Click to expand</summary>
### Prerequisites
@@ -212,9 +215,9 @@ Before you can perform the upgrade, you must prepare your air gapped environment
kubectl apply -f cert-manager-backup.yaml
```
{{% /accordion %}}
</details>
### Verify the Deployment
### Verify the Deployment
Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the kube-system namespace for running pods:
versioned_docs/version-2.5/v2.5/en/k8s-in-rancher/horitzontal-pod-autoscaler/manage-hpa-with-kubectl/manage-hpa-with-kubectl.md
+15 -6
View File
@@ -161,7 +161,10 @@ For HPA to use custom metrics from Prometheus, package [k8s-prometheus-adapter](
# kubectl logs prometheus-adapter-prometheus-adapter-568674d97f-hbzfx -n kube-system
```
Then review the log output to confirm the service is running.
{{% accordion id="prometheus-logs" label="Prometheus Adaptor Logs" %}}
<details id="prometheus-logs">
<summary>Prometheus Adaptor Logs</summary>
...
I0724 10:18:45.696679 1 round_trippers.go:436] GET https://10.43.0.1:443/api/v1/namespaces/default/pods?labelSelector=app%3Dhello-world 200 OK in 2 milliseconds
I0724 10:18:45.696695 1 round_trippers.go:442] Response Headers:
@@ -174,7 +177,7 @@ For HPA to use custom metrics from Prometheus, package [k8s-prometheus-adapter](
I0724 10:18:45.699939 1 wrap.go:42] GET /apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pods/%2A/fs_read?labelSelector=app%3Dhello-world: (12.431262ms) 200 [[kube-controller-manager/v1.10.1 (linux/amd64) kubernetes/d4ab475/system:serviceaccount:kube-system:horizontal-pod-autoscaler] 10.42.0.0:24268]
I0724 10:18:51.727845 1 request.go:836] Request Body: {"kind":"SubjectAccessReview","apiVersion":"authorization.k8s.io/v1beta1","metadata":{"creationTimestamp":null},"spec":{"nonResourceAttributes":{"path":"/","verb":"get"},"user":"system:anonymous","group":["system:unauthenticated"]},"status":{"allowed":false}}
...
{{% /accordion %}}
</details>
@@ -185,15 +188,21 @@ For HPA to use custom metrics from Prometheus, package [k8s-prometheus-adapter](
# kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1
```
If the API is accessible, you should receive output that's similar to what follows.
{{% accordion id="custom-metrics-api-response" label="API Response" %}}
<details id="custom-metrics-api-response">
<summary>API Response</summary>
{"kind":"APIResourceList","apiVersion":"v1","groupVersion":"custom.metrics.k8s.io/v1beta1","resources":[{"name":"pods/fs_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_rss","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_period","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_read","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_user","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/last_seen","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/tasks_state","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_quota","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/start_time_seconds","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_write","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_cache","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_working_set_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_udp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes_free","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time_weighted","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failures","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_swap","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_shares","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_swap_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_current","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failcnt","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_tcp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_max_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_reservation_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_load_average_10s","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_system","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]}]}
{{% /accordion %}}
</details>
- If you are accessing the cluster through Rancher, enter your Server URL in the kubectl config in the following format: `https://<RANCHER_URL>/k8s/clusters/<CLUSTER_ID>`. Add the suffix `/k8s/clusters/<CLUSTER_ID>` to API path.
```
# kubectl get --raw /k8s/clusters/<CLUSTER_ID>/apis/custom.metrics.k8s.io/v1beta1
```
If the API is accessible, you should receive output that's similar to what follows.
{{% accordion id="custom-metrics-api-response-rancher" label="API Response" %}}
<details id="custom-metrics-api-response-rancher">
<summary>API Response</summary>
{"kind":"APIResourceList","apiVersion":"v1","groupVersion":"custom.metrics.k8s.io/v1beta1","resources":[{"name":"pods/fs_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_rss","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_period","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_read","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_user","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/last_seen","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/tasks_state","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_quota","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/start_time_seconds","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_write","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_cache","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_working_set_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_udp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes_free","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time_weighted","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failures","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_swap","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_shares","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_swap_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_current","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failcnt","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_tcp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_max_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_reservation_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_load_average_10s","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_system","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]}]}
{{% /accordion %}}
</details>
versioned_docs/version-2.5/v2.5/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md
+498 -458
View File
@@ -12,58 +12,62 @@ For HPA to work correctly, service deployments should have resources request def
1. Configure `kubectl` to connect to your Kubernetes cluster.
2. Copy the `hello-world` deployment manifest below.
{{% accordion id="hello-world" label="Hello World Manifest" %}}
```
apiVersion: apps/v1beta2
kind: Deployment
metadata:
labels:
app: hello-world
name: hello-world
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: hello-world
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
type: RollingUpdate
template:
metadata:
labels:
app: hello-world
spec:
containers:
- image: rancher/hello-world
imagePullPolicy: Always
name: hello-world
resources:
requests:
cpu: 500m
memory: 64Mi
ports:
- containerPort: 80
protocol: TCP
restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
name: hello-world
namespace: default
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: hello-world
```
{{% /accordion %}}
1. Copy the `hello-world` deployment manifest below.
<details id="hello-world">
<summary>Hello World Manifest</summary>
```
apiVersion: apps/v1beta2
kind: Deployment
metadata:
labels:
app: hello-world
name: hello-world
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: hello-world
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
type: RollingUpdate
template:
metadata:
labels:
app: hello-world
spec:
containers:
- image: rancher/hello-world
imagePullPolicy: Always
name: hello-world
resources:
requests:
cpu: 500m
memory: 64Mi
ports:
- containerPort: 80
protocol: TCP
restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
name: hello-world
namespace: default
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: hello-world
```
</details>
1. Deploy it to your cluster.
@@ -72,423 +76,459 @@ spec:
```
1. Copy one of the HPAs below based on the metric type you're using:
{{% accordion id="service-deployment-resource-metrics" label="Hello World HPA: Resource Metrics" %}}
```
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
name: hello-world
namespace: default
spec:
scaleTargetRef:
apiVersion: extensions/v1beta1
kind: Deployment
name: hello-world
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
targetAverageUtilization: 50
- type: Resource
resource:
name: memory
targetAverageValue: 1000Mi
```
{{% /accordion %}}
{{% accordion id="service-deployment-custom-metrics" label="Hello World HPA: Custom Metrics" %}}
```
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
name: hello-world
namespace: default
spec:
scaleTargetRef:
apiVersion: extensions/v1beta1
kind: Deployment
name: hello-world
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
targetAverageUtilization: 50
- type: Resource
resource:
name: memory
targetAverageValue: 100Mi
- type: Pods
pods:
metricName: cpu_system
targetAverageValue: 20m
```
{{% /accordion %}}
<details id="service-deployment-resource-metrics">
<summary>Hello World HPA: Resource Metrics</summary>
```
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
name: hello-world
namespace: default
spec:
scaleTargetRef:
apiVersion: extensions/v1beta1
kind: Deployment
name: hello-world
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
targetAverageUtilization: 50
- type: Resource
resource:
name: memory
targetAverageValue: 1000Mi
```
</details>
<details id="service-deployment-custom-metrics">
<summary>Hello World HPA: Custom Metrics</summary>
```
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
name: hello-world
namespace: default
spec:
scaleTargetRef:
apiVersion: extensions/v1beta1
kind: Deployment
name: hello-world
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
targetAverageUtilization: 50
- type: Resource
resource:
name: memory
targetAverageValue: 100Mi
- type: Pods
pods:
metricName: cpu_system
targetAverageValue: 20m
```
</details>
1. View the HPA info and description. Confirm that metric data is shown.
{{% accordion id="hpa-info-resource-metrics" label="Resource Metrics" %}}
1. Enter the following commands.
```
# kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
hello-world Deployment/hello-world 1253376 / 100Mi, 0% / 50% 1 10 1 6m
# kubectl describe hpa
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Mon, 23 Jul 2018 20:21:16 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 1253376 / 100Mi
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True ReadyForNewScale the last scale time was sufficiently old as to warrant a new scale
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events: <none>
```
{{% /accordion %}}
{{% accordion id="hpa-info-custom-metrics" label="Custom Metrics" %}}
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive the output that follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:36:28 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 3514368 / 100Mi
"cpu_system" on pods: 0 / 20m
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True ReadyForNewScale the last scale time was sufficiently old as to warrant a new scale
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events: <none>
```
{{% /accordion %}}
<details id="hpa-info-resource-metrics">
<summary>Resource Metrics</summary>
1. Enter the following commands.
```
# kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
hello-world Deployment/hello-world 1253376 / 100Mi, 0% / 50% 1 10 1 6m
# kubectl describe hpa
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Mon, 23 Jul 2018 20:21:16 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 1253376 / 100Mi
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True ReadyForNewScale the last scale time was sufficiently old as to warrant a new scale
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events: <none>
```
</details>
<details id="hpa-info-custom-metrics">
<summary>Custom Metrics</summary>
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive the output that follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:36:28 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 3514368 / 100Mi
"cpu_system" on pods: 0 / 20m
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True ReadyForNewScale the last scale time was sufficiently old as to warrant a new scale
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events: <none>
```
</details>
1. Generate a load for the service to test that your pods autoscale as intended. You can use any load-testing tool (Hey, Gatling, etc.), but we're using [Hey](https://github.com/rakyll/hey).
1. Test that pod autoscaling works as intended.<br/></br>
1. Test that pod autoscaling works as intended.<br/><br/>
**To Test Autoscaling Using Resource Metrics:**
{{% accordion id="observe-upscale-2-pods-cpu" label="Upscale to 2 Pods: CPU Usage Up to Target" %}}
Use your load testing tool to scale up to two pods based on CPU Usage.
1. View your HPA.
```
# kubectl describe hpa
```
You should receive output similar to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Mon, 23 Jul 2018 22:22:04 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 10928128 / 100Mi
resource cpu on pods (as a percentage of request): 56% (280m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 2
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 13s horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
```
1. Enter the following command to confirm you've scaled to two pods.
```
# kubectl get pods
```
You should receive output similar to what follows:
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-k8ph2 1/1 Running 0 1m
hello-world-54764dfbf8-q6l4v 1/1 Running 0 3h
```
{{% /accordion %}}
{{% accordion id="observe-upscale-3-pods-cpu-cooldown" label="Upscale to 3 pods: CPU Usage Up to Target" %}}
Use your load testing tool to upscale to 3 pods based on CPU usage with `horizontal-pod-autoscaler-upscale-delay` set to 3 minutes.
<details id="observe-upscale-2-pods-cpu">
<summary>Upscale to 2 Pods: CPU Usage Up to Target</summary>
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Mon, 23 Jul 2018 22:22:04 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 9424896 / 100Mi
resource cpu on pods (as a percentage of request): 66% (333m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 3
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 4m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 16s horizontal-pod-autoscaler New size: 3; reason: cpu resource utilization (percentage of request) above target
```
2. Enter the following command to confirm three pods are running.
```
# kubectl get pods
```
You should receive output similar to what follows.
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-f46kh 0/1 Running 0 1m
hello-world-54764dfbf8-k8ph2 1/1 Running 0 5m
hello-world-54764dfbf8-q6l4v 1/1 Running 0 3h
```
{{% /accordion %}}
{{% accordion id="observe-downscale-1-pod" label="Downscale to 1 Pod: All Metrics Below Target" %}}
Use your load testing to scale down to 1 pod when all metrics are below target for `horizontal-pod-autoscaler-downscale-delay` (5 minutes by default).
Use your load testing tool to scale up to two pods based on CPU Usage.
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Mon, 23 Jul 2018 22:22:04 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 10070016 / 100Mi
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 1
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 10m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 6m horizontal-pod-autoscaler New size: 3; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 1s horizontal-pod-autoscaler New size: 1; reason: All metrics below target
```
{{% /accordion %}}
<br/>
**To Test Autoscaling Using Custom Metrics:**
{{% accordion id="custom-observe-upscale-2-pods-cpu" label="Upscale to 2 Pods: CPU Usage Up to Target" %}}
Use your load testing tool to upscale two pods based on CPU usage.
1. View your HPA.
```
# kubectl describe hpa
```
You should receive output similar to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Mon, 23 Jul 2018 22:22:04 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 10928128 / 100Mi
resource cpu on pods (as a percentage of request): 56% (280m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 2
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 13s horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
```
1. Enter the following command to confirm you've scaled to two pods.
```
# kubectl get pods
```
You should receive output similar to what follows:
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-k8ph2 1/1 Running 0 1m
hello-world-54764dfbf8-q6l4v 1/1 Running 0 3h
```
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 8159232 / 100Mi
"cpu_system" on pods: 7m / 20m
resource cpu on pods (as a percentage of request): 64% (321m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 2
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 16s horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
```
1. Enter the following command to confirm two pods are running.
```
# kubectl get pods
```
You should receive output similar to what follows.
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-5pfdr 1/1 Running 0 3s
hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
```
{{% /accordion %}}
{{% accordion id="observe-upscale-3-pods-cpu-cooldown-2" label="Upscale to 3 Pods: CPU Usage Up to Target" %}}
Use your load testing tool to scale up to three pods when the cpu_system usage limit is up to target.
</details>
<details id="observe-upscale-3-pods-cpu-cooldown">
<summary>Upscale to 3 pods: CPU Usage Up to Target</summary>
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows:
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 8374272 / 100Mi
"cpu_system" on pods: 27m / 20m
resource cpu on pods (as a percentage of request): 71% (357m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 3
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 3m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 3s horizontal-pod-autoscaler New size: 3; reason: pods metric cpu_system above target
```
1. Enter the following command to confirm three pods are running.
```
# kubectl get pods
```
You should receive output similar to what follows:
```
# kubectl get pods
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-5pfdr 1/1 Running 0 3m
hello-world-54764dfbf8-m2hrl 1/1 Running 0 1s
hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
```
{{% /accordion %}}
{{% accordion id="observe-upscale-4-pods" label="Upscale to 4 Pods: CPU Usage Up to Target" %}}
Use your load testing tool to upscale to four pods based on CPU usage. `horizontal-pod-autoscaler-upscale-delay` is set to three minutes by default.
Use your load testing tool to upscale to 3 pods based on CPU usage with `horizontal-pod-autoscaler-upscale-delay` set to 3 minutes.
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 8374272 / 100Mi
"cpu_system" on pods: 27m / 20m
resource cpu on pods (as a percentage of request): 71% (357m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 3
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 5m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 3m horizontal-pod-autoscaler New size: 3; reason: pods metric cpu_system above target
Normal SuccessfulRescale 4s horizontal-pod-autoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target
```
1. Enter the following command to confirm four pods are running.
```
# kubectl get pods
```
You should receive output similar to what follows.
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-2p9xb 1/1 Running 0 5m
hello-world-54764dfbf8-5pfdr 1/1 Running 0 2m
hello-world-54764dfbf8-m2hrl 1/1 Running 0 1s
hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
```
{{% /accordion %}}
{{% accordion id="custom-metrics-observe-downscale-1-pod" label="Downscale to 1 Pod: All Metrics Below Target" %}}
Use your load testing tool to scale down to one pod when all metrics below target for `horizontal-pod-autoscaler-downscale-delay`.
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive similar output to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 8101888 / 100Mi
"cpu_system" on pods: 8m / 20m
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 1
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 10m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 8m horizontal-pod-autoscaler New size: 3; reason: pods metric cpu_system above target
Normal SuccessfulRescale 5m horizontal-pod-autoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 13s horizontal-pod-autoscaler New size: 1; reason: All metrics below target
```
1. Enter the following command to confirm a single pods is running.
```
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Mon, 23 Jul 2018 22:22:04 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 9424896 / 100Mi
resource cpu on pods (as a percentage of request): 66% (333m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 3
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 4m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 16s horizontal-pod-autoscaler New size: 3; reason: cpu resource utilization (percentage of request) above target
```
2. Enter the following command to confirm three pods are running.
```
# kubectl get pods
```
You should receive output similar to what follows.
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
```
{{% /accordion %}}
```
You should receive output similar to what follows.
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-f46kh 0/1 Running 0 1m
hello-world-54764dfbf8-k8ph2 1/1 Running 0 5m
hello-world-54764dfbf8-q6l4v 1/1 Running 0 3h
```
</details>
<details id="observe-downscale-1-pod">
<summary>Downscale to 1 Pod: All Metrics Below Target</summary>
Use your load testing to scale down to 1 pod when all metrics are below target for `horizontal-pod-autoscaler-downscale-delay` (5 minutes by default).
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Mon, 23 Jul 2018 22:22:04 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 10070016 / 100Mi
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 1
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 10m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 6m horizontal-pod-autoscaler New size: 3; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 1s horizontal-pod-autoscaler New size: 1; reason: All metrics below target
```
</details>
**To Test Autoscaling Using Custom Metrics:**
<details id="custom-observe-upscale-2-pods-cpu">
<summary>Upscale to 2 Pods: CPU Usage Up to Target</summary>
Use your load testing tool to upscale two pods based on CPU usage.
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 8159232 / 100Mi
"cpu_system" on pods: 7m / 20m
resource cpu on pods (as a percentage of request): 64% (321m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 2
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 16s horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
```
1. Enter the following command to confirm two pods are running.
```
# kubectl get pods
```
You should receive output similar to what follows.
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-5pfdr 1/1 Running 0 3s
hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
```
</details>
<details id="observe-upscale-3-pods-cpu-cooldown-2">
<summary>Upscale to 3 Pods: CPU Usage Up to Target</summary>
Use your load testing tool to scale up to three pods when the cpu_system usage limit is up to target.
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows:
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 8374272 / 100Mi
"cpu_system" on pods: 27m / 20m
resource cpu on pods (as a percentage of request): 71% (357m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 3
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 3m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 3s horizontal-pod-autoscaler New size: 3; reason: pods metric cpu_system above target
```
1. Enter the following command to confirm three pods are running.
```
# kubectl get pods
```
You should receive output similar to what follows:
```
# kubectl get pods
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-5pfdr 1/1 Running 0 3m
hello-world-54764dfbf8-m2hrl 1/1 Running 0 1s
hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
```
</details>
<details id="observe-upscale-4-pods">
<summary>Upscale to 4 Pods: CPU Usage Up to Target</summary>
Use your load testing tool to upscale to four pods based on CPU usage. `horizontal-pod-autoscaler-upscale-delay` is set to three minutes by default.
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive output similar to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 8374272 / 100Mi
"cpu_system" on pods: 27m / 20m
resource cpu on pods (as a percentage of request): 71% (357m) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 3
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 5m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 3m horizontal-pod-autoscaler New size: 3; reason: pods metric cpu_system above target
Normal SuccessfulRescale 4s horizontal-pod-autoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target
```
1. Enter the following command to confirm four pods are running.
```
# kubectl get pods
```
You should receive output similar to what follows.
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-2p9xb 1/1 Running 0 5m
hello-world-54764dfbf8-5pfdr 1/1 Running 0 2m
hello-world-54764dfbf8-m2hrl 1/1 Running 0 1s
hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
```
</details>
<details id="custom-metrics-observe-downscale-1-pod">
<summary>Downscale to 1 Pod: All Metrics Below Target</summary>
Use your load testing tool to scale down to one pod when all metrics below target for `horizontal-pod-autoscaler-downscale-delay`.
1. Enter the following command.
```
# kubectl describe hpa
```
You should receive similar output to what follows.
```
Name: hello-world
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
Reference: Deployment/hello-world
Metrics: ( current / target )
resource memory on pods: 8101888 / 100Mi
"cpu_system" on pods: 8m / 20m
resource cpu on pods (as a percentage of request): 0% (0) / 50%
Min replicas: 1
Max replicas: 10
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 1
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulRescale 10m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 8m horizontal-pod-autoscaler New size: 3; reason: pods metric cpu_system above target
Normal SuccessfulRescale 5m horizontal-pod-autoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 13s horizontal-pod-autoscaler New size: 1; reason: All metrics below target
```
1. Enter the following command to confirm a single pods is running.
```
# kubectl get pods
```
You should receive output similar to what follows.
```
NAME READY STATUS RESTARTS AGE
hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
```
</details>
versioned_docs/version-2.5/v2.5/en/monitoring-alerting/expression/expression.md
+8 -8
View File
@@ -118,15 +118,15 @@ For more information about querying the Prometheus time series database, refer t
| Catalog | Expression |
| --- | --- |
| Detail | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr></table> |
| Summary | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr></table> |
| Detail | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr></table> |
| Summary | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr></table> |
### Cluster Network I/O
| Catalog | Expression |
| --- | --- |
| Detail | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr></table> |
| Summary | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr></table> |
| Detail | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr></table> |
| Summary | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr></table> |
# Node Metrics
@@ -169,15 +169,15 @@ For more information about querying the Prometheus time series database, refer t
| Catalog | Expression |
| --- | --- |
| Detail | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr></table> |
| Summary | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr></table> |
| Detail | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr></table> |
| Summary | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr></table> |
### Node Network I/O
| Catalog | Expression |
| --- | --- |
| Detail | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr></table> |
| Summary | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr></table> |
| Detail | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr></table> |
| Summary | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr></table> |
# Etcd Metrics
versioned_docs/version-2.5/v2.5/en/monitoring-alerting/how-monitoring-works/how-monitoring-works.md
+6 -6
View File
@@ -32,18 +32,18 @@ ServiceMonitors and PodMonitors declaratively specify targets, such as Services
- Certain internal Kubernetes components are scraped via a proxy deployed as part of Monitoring V2 called **PushProx**. The Kubernetes components that expose metrics to Prometheus through PushProx are the following:
`kube-controller-manager`, `kube-scheduler`, `etcd`, and `kube-proxy`.
- For each PushProx exporter, we deploy one PushProx client onto all target nodes. For example, a PushProx client is deployed onto all controlplane nodes for kube-controller-manager, all etcd nodes for kube-etcd, and all nodes for kubelet.
- For each PushProx exporter, we deploy one PushProx client onto all target nodes. For example, a PushProx client is deployed onto all controlplane nodes for kube-controller-manager, all etcd nodes for kube-etcd, and all nodes for kubelet.
- We deploy exactly one PushProx proxy per exporter. The process for exporting metrics is as follows:
1. The PushProx Client establishes an outbound connection with the PushProx Proxy.
1. The PushProx Client establishes an outbound connection with the PushProx Proxy.
1. The client then polls the proxy for scrape requests that have come into the proxy.
1. When the proxy receives a scrape request from Prometheus, the client sees it as a result of the poll.
1. The client scrapes the internal component.
1. The internal component responds by pushing metrics back to the proxy.
<figcaption><br>Process for Exporting Metrics with PushProx:</br></figcaption>
<figcaption><br/>Process for Exporting Metrics with PushProx:<br/></figcaption>
![Process for Exporting Metrics with PushProx]({{<baseurl>}}/img/rancher/pushprox-process.svg)
@@ -126,7 +126,7 @@ The Alertmanager handles alerts sent by client applications such as the Promethe
### Alerts Forwarded by alertingDrivers
When alertingDrivers are installed, this creates a `Service` that can be used as the receiver's URL for Teams or SMS, based on the alertingDriver's configuration. The URL in the Receiver points to the alertingDrivers; so the Alertmanager sends alert first to alertingDriver, then alertingDriver forwards or sends alert to the proper destination.
### Routing Alerts to Receivers
Alertmanager coordinates where alerts are sent. It allows you to group alerts based on labels and fire them based on whether certain labels are matched. One top-level route accepts all alerts. From there, Alertmanager continues routing alerts to receivers based on whether they match the conditions of the next route.
versioned_docs/version-2.5/v2.5/en/overview/overview.md
+2 -2
View File
@@ -51,7 +51,7 @@ The Rancher API server is built on top of an embedded Kubernetes API server and
### Cluster Visibility
- **Logging:** Rancher can integrate with a variety of popular logging services and tools that exist outside of your Kubernetes clusters.
- **Monitoring:** Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with Prometheus, a leading open-source monitoring solution.
- **Monitoring:** Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with Prometheus, a leading open-source monitoring solution.
- **Alerting:** To keep your clusters and applications healthy and driving your organizational productivity forward, you need to stay informed of events occurring in your clusters and projects, both planned and unplanned.
# Editing Downstream Clusters with Rancher
@@ -62,4 +62,4 @@ After a cluster is created with Rancher, a cluster administrator can manage clus
The following table summarizes the options and settings available for each cluster type:
{{% include file="/rancher/v2.5/en/cluster-provisioning/cluster-capabilities-table" %}}
{{% include file="/rancher/v2.5/en/cluster-provisioning/cluster-capabilities-table</summary>
versioned_docs/version-2.5/v2.5/en/security/rancher-2.5/1.5-benchmark-2.5/1.5-benchmark-2.5.md
+15 -15
View File
@@ -937,7 +937,7 @@ on the master node and set the `--service-account-key-file` parameter
to the public key file for service accounts:
``` bash
--service-account-key-file=<filename>
`--service-account-key-file=<filename>`
```
**Audit:**
@@ -962,8 +962,8 @@ Then, edit the API server pod specification file `/etc/kubernetes/manifests/kube
on the master node and set the **etcd** certificate and **key** file parameters.
``` bash
--etcd-certfile=<path/to/client-certificate-file>
--etcd-keyfile=<path/to/client-key-file>
`--etcd-certfile=<path/to/client-certificate-file>`
`--etcd-keyfile=<path/to/client-key-file>`
```
**Audit:**
@@ -988,8 +988,8 @@ Then, edit the API server pod specification file `/etc/kubernetes/manifests/kube
on the master node and set the TLS certificate and private key file parameters.
``` bash
--tls-cert-file=<path/to/tls-certificate-file>
--tls-private-key-file=<path/to/tls-key-file>
`--tls-cert-file=<path/to/tls-certificate-file>`
`--tls-private-key-file=<path/to/tls-key-file>`
```
**Audit:**
@@ -1014,7 +1014,7 @@ Then, edit the API server pod specification file `/etc/kubernetes/manifests/kube
on the master node and set the client certificate authority file.
``` bash
--client-ca-file=<path/to/client-ca-file>
`--client-ca-file=<path/to/client-ca-file>`
```
**Audit:**
@@ -1039,7 +1039,7 @@ Then, edit the API server pod specification file `/etc/kubernetes/manifests/kube
on the master node and set the etcd certificate authority file parameter.
``` bash
--etcd-cafile=<path/to/ca-file>
`--etcd-cafile=<path/to/ca-file>`
```
**Audit:**
@@ -1201,7 +1201,7 @@ on the master node and set the `--service-account-private-key-file` parameter
to the private key file for service accounts.
``` bash
--service-account-private-key-file=<filename>
`--service-account-private-key-file=<filename>`
```
**Audit:**
@@ -1225,7 +1225,7 @@ Edit the Controller Manager pod specification file `/etc/kubernetes/manifests/ku
on the master node and set the `--root-ca-file` parameter to the certificate bundle file`.
``` bash
--root-ca-file=<path/to/file>
`--root-ca-file=<path/to/file>`
```
**Audit:**
@@ -1343,8 +1343,8 @@ Then, edit the etcd pod specification file `/etc/kubernetes/manifests/etcd.yaml`
on the master node and set the below parameters.
``` bash
--cert-file=</path/to/ca-file>
--key-file=</path/to/key-file>
`--cert-file=</path/to/ca-file>`
`--key-file=</path/to/key-file>`
```
**Audit:**
@@ -1417,8 +1417,8 @@ for your etcd cluster. Then, edit the etcd pod specification file `/etc/kubernet
master node and set the below parameters.
``` bash
--peer-client-file=</path/to/peer-cert-file>
--peer-key-file=</path/to/peer-key-file>
`--peer-client-file=</path/to/peer-cert-file>`
`--peer-key-file=</path/to/peer-key-file>`
```
**Audit:**
@@ -1634,7 +1634,7 @@ chown root:root /etc/kubernetes/ssl/kubecfg-kube-node.yaml
Run the following command to modify the file permissions of the
``` bash
--client-ca-file chmod 644 <filename>
`--client-ca-file chmod 644 <filename>`
```
**Audit:**
@@ -1779,7 +1779,7 @@ If using command line arguments, edit the kubelet service file
set the below parameter in `KUBELET_AUTHZ_ARGS` variable.
``` bash
--client-ca-file=<path/to/client-ca-file>
`--client-ca-file=<path/to/client-ca-file>`
```
Based on your system, restart the kubelet service. For example:
versioned_docs/version-2.5/v2.5/en/security/rancher-2.5/1.6-benchmark-2.5/1.6-benchmark-2.5.md
+33 -33
View File
@@ -173,7 +173,7 @@ exit
true
```
### 1.1.20 Ensure that the Kubernetes PKI certificate file permissions are set to 644 or more restrictive (Automated)
### 1.1.20 Ensure that the Kubernetes PKI certificate file permissions are set to 644 or more restrictive (Automated)
**Result:** pass
@@ -651,7 +651,7 @@ root 4643 4626 22 16:15 ? 00:00:46 kube-apiserver --etcd-keyfil
**Remediation:**
Follow the documentation and configure alternate mechanisms for authentication. Then,
edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
on the master node and remove the --basic-auth-file=<filename> parameter.
on the master node and remove the `--basic-auth-file=<filename>` parameter.
**Audit:**
@@ -679,7 +679,7 @@ root 4643 4626 22 16:15 ? 00:00:46 kube-apiserver --etcd-keyfil
**Remediation:**
Follow the documentation and configure alternate mechanisms for authentication. Then,
edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
on the master node and remove the --token-auth-file=<filename> parameter.
on the master node and remove the `--token-auth-file=<filename>` parameter.
**Audit:**
@@ -766,8 +766,8 @@ root 4643 4626 22 16:15 ? 00:00:46 kube-apiserver --etcd-keyfil
Follow the Kubernetes documentation and setup the TLS connection between
the apiserver and kubelets. Then, edit the API server pod specification file
/etc/kubernetes/manifests/kube-apiserver.yaml on the master node and set the
--kubelet-certificate-authority parameter to the path to the cert file for the certificate authority.
--kubelet-certificate-authority=<ca-string>
`--kubelet-certificate-authority` parameter to the path to the cert file for the certificate authority.
`--kubelet-certificate-authority=<ca-string>`
**Audit:**
@@ -1379,7 +1379,7 @@ root 4643 4626 22 16:15 ? 00:00:46 kube-apiserver --etcd-keyfil
Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
on the master node and set the --service-account-key-file parameter
to the public key file for service accounts:
--service-account-key-file=<filename>
`--service-account-key-file=<filename>`
**Audit:**
@@ -1408,8 +1408,8 @@ root 4643 4626 22 16:15 ? 00:00:46 kube-apiserver --etcd-keyfil
Follow the Kubernetes documentation and set up the TLS connection between the apiserver and etcd.
Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
on the master node and set the etcd certificate and key file parameters.
--etcd-certfile=<path/to/client-certificate-file>
--etcd-keyfile=<path/to/client-key-file>
`--etcd-certfile=<path/to/client-certificate-file>`
`--etcd-keyfile=<path/to/client-key-file>`
**Audit:**
@@ -1438,8 +1438,8 @@ root 4643 4626 22 16:15 ? 00:00:46 kube-apiserver --etcd-keyfil
Follow the Kubernetes documentation and set up the TLS connection on the apiserver.
Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
on the master node and set the TLS certificate and private key file parameters.
--tls-cert-file=<path/to/tls-certificate-file>
--tls-private-key-file=<path/to/tls-key-file>
`--tls-cert-file=<path/to/tls-certificate-file>`
`--tls-private-key-file=<path/to/tls-key-file>`
**Audit:**
@@ -1468,7 +1468,7 @@ root 4643 4626 22 16:15 ? 00:00:46 kube-apiserver --etcd-keyfil
Follow the Kubernetes documentation and set up the TLS connection on the apiserver.
Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
on the master node and set the client certificate authority file.
--client-ca-file=<path/to/client-ca-file>
`--client-ca-file=<path/to/client-ca-file>`
**Audit:**
@@ -1497,7 +1497,7 @@ root 4643 4626 22 16:15 ? 00:00:46 kube-apiserver --etcd-keyfil
Follow the Kubernetes documentation and set up the TLS connection between the apiserver and etcd.
Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
on the master node and set the etcd certificate authority file parameter.
--etcd-cafile=<path/to/ca-file>
`--etcd-cafile=<path/to/ca-file>`
**Audit:**
@@ -1717,7 +1717,7 @@ root 4788 4773 4 16:16 ? 00:00:09 kube-controller-manager --co
Edit the Controller Manager pod specification file /etc/kubernetes/manifests/kube-controller-manager.yaml
on the master node and set the --service-account-private-key-file parameter
to the private key file for service accounts.
--service-account-private-key-file=<filename>
`--service-account-private-key-file=<filename>`
**Audit:**
@@ -1745,7 +1745,7 @@ root 4788 4773 4 16:16 ? 00:00:09 kube-controller-manager --co
**Remediation:**
Edit the Controller Manager pod specification file /etc/kubernetes/manifests/kube-controller-manager.yaml
on the master node and set the --root-ca-file parameter to the certificate bundle file`.
--root-ca-file=<path/to/file>
`--root-ca-file=<path/to/file>`
**Audit:**
@@ -1877,8 +1877,8 @@ root 4947 4930 1 16:16 ? 00:00:02 kube-scheduler --kubeconfig=
Follow the etcd service documentation and configure TLS encryption.
Then, edit the etcd pod specification file /etc/kubernetes/manifests/etcd.yaml
on the master node and set the below parameters.
--cert-file=</path/to/ca-file>
--key-file=</path/to/key-file>
`--cert-file=</path/to/ca-file>`
`--key-file=</path/to/key-file>`
**Audit:**
@@ -1973,8 +1973,8 @@ Follow the etcd service documentation and configure peer TLS encryption as appro
for your etcd cluster.
Then, edit the etcd pod specification file /etc/kubernetes/manifests/etcd.yaml on the
master node and set the below parameters.
--peer-client-file=</path/to/peer-cert-file>
--peer-key-file=</path/to/peer-key-file>
`--peer-client-file=</path/to/peer-cert-file>`
`--peer-key-file=</path/to/peer-key-file>`
**Audit:**
@@ -2070,7 +2070,7 @@ Follow the etcd documentation and create a dedicated certificate authority setup
etcd service.
Then, edit the etcd pod specification file /etc/kubernetes/manifests/etcd.yaml on the
master node and set the below parameter.
--trusted-ca-file=</path/to/ca-file>
`--trusted-ca-file=</path/to/ca-file>`
**Audit:**
@@ -2167,7 +2167,7 @@ All configuration is passed in as arguments at container run time.
**Audit:**
```bash
/bin/sh -c 'if test -e /etc/systemd/system/kubelet.service.d/10-kubeadm.conf; then stat -c permissions=%a /etc/systemd/system/kubelet.service.d/10-kubeadm.conf; fi'
/bin/sh -c 'if test -e /etc/systemd/system/kubelet.service.d/10-kubeadm.conf; then stat -c permissions=%a /etc/systemd/system/kubelet.service.d/10-kubeadm.conf; fi'
```
@@ -2183,7 +2183,7 @@ All configuration is passed in as arguments at container run time.
**Audit:**
```bash
/bin/sh -c 'if test -e /etc/systemd/system/kubelet.service.d/10-kubeadm.conf; then stat -c %U:%G /etc/systemd/system/kubelet.service.d/10-kubeadm.conf; fi'
/bin/sh -c 'if test -e /etc/systemd/system/kubelet.service.d/10-kubeadm.conf; then stat -c %U:%G /etc/systemd/system/kubelet.service.d/10-kubeadm.conf; fi'
```
@@ -2200,7 +2200,7 @@ chmod 644 $proykubeconfig
**Audit:**
```bash
/bin/sh -c 'if test -e /node/etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; then stat -c %a /node/etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; fi'
/bin/sh -c 'if test -e /node/etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; then stat -c %a /node/etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; fi'
```
**Expected Result**:
@@ -2227,7 +2227,7 @@ For example, chown root:root /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml
**Audit:**
```bash
/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; then stat -c %U:%G /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; fi'
/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; then stat -c %U:%G /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; fi'
```
**Expected Result**:
@@ -2249,7 +2249,7 @@ chmod 644 /etc/kubernetes/ssl/kubecfg-kube-node.yaml
**Audit:**
```bash
/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-node.yaml; then stat -c permissions=%a /etc/kubernetes/ssl/kubecfg-kube-node.yaml; fi'
/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-node.yaml; then stat -c permissions=%a /etc/kubernetes/ssl/kubecfg-kube-node.yaml; fi'
```
**Expected Result**:
@@ -2271,7 +2271,7 @@ chown root:root /etc/kubernetes/ssl/kubecfg-kube-node.yaml
**Audit:**
```bash
/bin/sh -c 'if test -e /node/etc/kubernetes/ssl/kubecfg-kube-node.yaml; then stat -c %U:%G /node/etc/kubernetes/ssl/kubecfg-kube-node.yaml; fi'
/bin/sh -c 'if test -e /node/etc/kubernetes/ssl/kubecfg-kube-node.yaml; then stat -c %U:%G /node/etc/kubernetes/ssl/kubecfg-kube-node.yaml; fi'
```
**Expected Result**:
@@ -2292,7 +2292,7 @@ root:root
**Remediation:**
Run the following command to modify the file permissions of the
--client-ca-file chmod 644 <filename>
`--client-ca-file chmod 644 <filename>`
**Audit:**
@@ -2322,7 +2322,7 @@ if test -e $CAFILE; then stat -c permissions=%a $CAFILE; fi
**Remediation:**
Run the following command to modify the ownership of the --client-ca-file.
chown root:root <filename>
`chown root:root <filename>`
**Audit:**
@@ -2361,7 +2361,7 @@ All configuration is passed in as arguments at container run time.
**Audit:**
```bash
/bin/sh -c 'if test -e /var/lib/kubelet/config.yaml; then stat -c permissions=%a /var/lib/kubelet/config.yaml; fi'
/bin/sh -c 'if test -e /var/lib/kubelet/config.yaml; then stat -c permissions=%a /var/lib/kubelet/config.yaml; fi'
```
@@ -2380,7 +2380,7 @@ All configuration is passed in as arguments at container run time.
**Audit:**
```bash
/bin/sh -c 'if test -e /var/lib/kubelet/config.yaml; then stat -c %U:%G /var/lib/kubelet/config.yaml; fi'
/bin/sh -c 'if test -e /var/lib/kubelet/config.yaml; then stat -c %U:%G /var/lib/kubelet/config.yaml; fi'
```
@@ -2450,7 +2450,7 @@ the location of the client CA file.
If using command line arguments, edit the kubelet service file
/etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
set the below parameter in KUBELET_AUTHZ_ARGS variable.
--client-ca-file=<path/to/client-ca-file>
`--client-ca-file=<path/to/client-ca-file>`
Based on your system, restart the kubelet service. For example:
systemctl daemon-reload
systemctl restart kubelet.service
@@ -2602,7 +2602,7 @@ Clusters provisioned by RKE set the --hostname-override to avoid any hostname co
**Audit:**
```bash
/bin/ps -fC kubelet
/bin/ps -fC kubelet
```
@@ -2643,8 +2643,8 @@ to the location of the corresponding private key file.
If using command line arguments, edit the kubelet service file
/etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
set the below parameters in KUBELET_CERTIFICATE_ARGS variable.
--tls-cert-file=<path/to/tls-certificate-file>
--tls-private-key-file=<path/to/tls-key-file>
`--tls-cert-file=<path/to/tls-certificate-file>`
`--tls-private-key-file=<path/to/tls-key-file>`
Based on your system, restart the kubelet service. For example:
systemctl daemon-reload
systemctl restart kubelet.service
versioned_docs/version-2.6/v2.6/en/backups/docker-installs/docker-backups/docker-backups.md
+3 -2
View File
@@ -18,7 +18,8 @@ In this command, `<DATE>` is a placeholder for the date that the data container
Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the [procedure below](#creating-a-backup).
<sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;RANCHER_CONTAINER_TAG&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>
![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
| Placeholder | Example | Description |
@@ -49,7 +50,7 @@ This procedure creates a backup that you can restore if Rancher encounters a dis
docker create --volumes-from <RANCHER_CONTAINER_NAME> --name rancher-data-<DATE> rancher/rancher:<RANCHER_CONTAINER_TAG>
```
1. <a id="tarball"></a>From the data container that you just created (`rancher-data-<DATE>`), create a backup tarball (`rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz`). Use the following command, replacing each placeholder:
1. <a id="tarball"></a>From the data container that you just created (<code>rancher-data-&lt;DATE&gt;</code>), create a backup tarball (<code>rancher-data-backup-&lt;RANCHER_VERSION&gt;-&lt;DATE&gt;.tar.gz</code>). Use the following command, replacing each placeholder:
```
docker run --volumes-from rancher-data-<DATE> -v $PWD:/backup:z busybox tar pzcvf /backup/rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz /var/lib/rancher
versioned_docs/version-2.6/v2.6/en/backups/docker-installs/docker-restores/docker-restores.md
+2 -1
View File
@@ -20,7 +20,8 @@ In this command, `<RANCHER_CONTAINER_NAME>` and `<RANCHER_VERSION>-<DATE>` are e
Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the procedure below.
<sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;RANCHER_CONTAINER_TAG&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>
![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
| Placeholder | Example | Description |
versioned_docs/version-2.6/v2.6/en/cluster-admin/cluster-admin.md
+2 -2
View File
@@ -15,9 +15,9 @@ This page covers the following topics:
## Managing Clusters in Rancher
After clusters have been [provisioned into Rancher]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/), [cluster owners]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) will need to manage these clusters. There are many different options of how to manage your cluster.
After clusters have been [provisioned into Rancher]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/), [cluster owners]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) will need to manage these clusters. There are many different options of how to manage your cluster.
{{% include file="/rancher/v2.6/en/cluster-provisioning/cluster-capabilities-table" %}}
{{% include file="/rancher/v2.6/en/cluster-provisioning/cluster-capabilities-table</summary>
## Configuring Tools
versioned_docs/version-2.6/v2.6/en/cluster-admin/cluster-autoscaler/amazon/amazon.md
+11 -11
View File
@@ -5,7 +5,7 @@ weight: 1
This guide will show you how to install and use [Kubernetes cluster-autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/) on Rancher custom clusters using AWS EC2 Auto Scaling Groups.
We are going to install a Rancher RKE custom cluster with a fixed number of nodes with the etcd and controlplane roles, and a variable nodes with the worker role, managed by `cluster-autoscaler`.
We are going to install a Rancher RKE custom cluster with a fixed number of nodes with the etcd and controlplane roles, and a variable nodes with the worker role, managed by `cluster-autoscaler`.
- [Prerequisites](#prerequisites)
- [1. Create a Custom Cluster](#1-create-a-custom-cluster)
@@ -68,7 +68,7 @@ On AWS EC2, we should create a few objects to configure our system. We've define
}
```
2. Master group: Nodes that will be part of the Kubernetes etcd and/or control planes. This will be out of the ASG.
2. Master group: Nodes that will be part of the Kubernetes etcd and/or control planes. This will be out of the ASG.
* IAM profile: Required by the Kubernetes cloud_provider integration. Optionally, `AWS_ACCESS_KEY` and `AWS_SECRET_KEY` can be used instead [using-aws-credentials.](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#using-aws-credentials) This profile is called `K8sMasterProfile`.
```json
@@ -211,7 +211,7 @@ On AWS EC2, we should create a few objects to configure our system. We've define
* `kubernetes.io/cluster/<clusterID>: owned`
* `k8s.io/cluster-autoscaler/<clusterName>: true`
* `k8s.io/cluster-autoscaler/enabled: true`
* User data: `K8sWorkerUserData` Ubuntu 18.04(ami-0e11cbb34015ff725), installs docker and add worker node to the k8s cluster
* User data: `K8sWorkerUserData` Ubuntu 18.04(ami-0e11cbb34015ff725), installs docker and add worker node to the k8s cluster
```sh
#!/bin/bash -x
@@ -246,7 +246,7 @@ Once we've configured AWS, let's create VMs to bootstrap our cluster:
* master (etcd+controlplane): Depending your needs, deploy three master instances with proper size. More info is at [the recommendations for production-ready clusters.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/production/)
* IAM role: `K8sMasterRole`
* Security group: `K8sMasterSg`
* Tags:
* Tags:
* `kubernetes.io/cluster/<clusterID>: owned`
* User data: `K8sMasterUserData`
@@ -254,7 +254,7 @@ Once we've configured AWS, let's create VMs to bootstrap our cluster:
* Name: `K8sWorkerAsg`
* IAM role: `K8sWorkerRole`
* Security group: `K8sWorkerSg`
* Tags:
* Tags:
* `kubernetes.io/cluster/<clusterID>: owned`
* `k8s.io/cluster-autoscaler/<clusterName>: true`
* `k8s.io/cluster-autoscaler/enabled: true`
@@ -268,7 +268,7 @@ Once the VMs are deployed, you should have a Rancher custom cluster up and runni
### 4. Install Cluster-autoscaler
At this point, we should have rancher cluster up and running. We are going to install cluster-autoscaler on master nodes and `kube-system` namespace, following cluster-autoscaler recommendation.
At this point, we should have rancher cluster up and running. We are going to install cluster-autoscaler on master nodes and `kube-system` namespace, following cluster-autoscaler recommendation.
#### Parameters
@@ -296,9 +296,9 @@ This table shows cluster-autoscaler parameters for fine tuning:
|node-deletion-delay-timeout|"2m"|Maximum time CA waits for removing delay-deletion.cluster-autoscaler.kubernetes.io/ annotations before deleting the node|
|scan-interval|"10s"|How often cluster is reevaluated for scale up or down|
|max-nodes-total|0|Maximum number of nodes in all node groups. Cluster autoscaler will not grow the cluster beyond this number|
|cores-total|"0:320000"|Minimum and maximum number of cores in cluster, in the format <min>:<max>. Cluster autoscaler will not scale the cluster beyond these numbers|
|memory-total|"0:6400000"|Minimum and maximum number of gigabytes of memory in cluster, in the format <min>:<max>. Cluster autoscaler will not scale the cluster beyond these numbers|
cloud-provider|-|Cloud provider type|
|cores-total|"0:320000"|Minimum and maximum number of cores in cluster, in the format `<min>:<max>.` Cluster autoscaler will not scale the cluster beyond these numbers|
|memory-total|"0:6400000"|Minimum and maximum number of gigabytes of memory in cluster, in the format `<min>:<max>.` Cluster autoscaler will not scale the cluster beyond these numbers|
cloud-provider|-|Cloud provider type|
|max-bulk-soft-taint-count|10|Maximum number of nodes that can be tainted/untainted PreferNoSchedule at the same time. Set to 0 to turn off such tainting|
|max-bulk-soft-taint-time|"3s"|Maximum duration of tainting/untainting nodes as PreferNoSchedule at the same time|
|max-empty-bulk-delete|10|Maximum number of empty nodes that can be deleted at the same time|
@@ -307,7 +307,7 @@ cloud-provider|-|Cloud provider type|
|ok-total-unready-count|3|Number of allowed unready nodes, irrespective of max-total-unready-percentage|
|scale-up-from-zero|true|Should CA scale up when there 0 ready nodes|
|max-node-provision-time|"15m"|Maximum time CA waits for node to be provisioned|
|nodes|-|sets min,max size and other configuration data for a node group in a format accepted by cloud provider. Can be used multiple times. Format: <min>:<max>:<other...>|
|nodes|-|sets min,max size and other configuration data for a node group in a format accepted by cloud provider. Can be used multiple times. Format: `<min>:<max>:<other...>`|
|node-group-auto-discovery|-|One or more definition(s) of node group auto-discovery. A definition is expressed `<name of discoverer>:[<key>[=<value>]]`|
|estimator|-|"binpacking"|Type of resource estimator to be used in scale up. Available values: ["binpacking"]|
|expander|"random"|Type of node group expander to be used in scale up. Available values: `["random","most-pods","least-waste","price","priority"]`|
@@ -520,7 +520,7 @@ kubectl -n kube-system apply -f cluster-autoscaler-deployment.yaml
# Testing
At this point, we should have a cluster-scaler up and running in our Rancher custom cluster. Cluster-scale should manage `K8sWorkerAsg` ASG to scale up and down between 2 and 10 nodes, when one of the following conditions is true:
At this point, we should have a cluster-scaler up and running in our Rancher custom cluster. Cluster-scale should manage `K8sWorkerAsg` ASG to scale up and down between 2 and 10 nodes, when one of the following conditions is true:
* There are pods that failed to run in the cluster due to insufficient resources. In this case, the cluster is scaled up.
* There are nodes in the cluster that have been underutilized for an extended period of time and their pods can be placed on other existing nodes. In this case, the cluster is scaled down.
versioned_docs/version-2.6/v2.6/en/cluster-admin/editing-clusters/editing-clusters.md
+1 -1
View File
@@ -24,5 +24,5 @@ The options and settings available for an existing cluster change based on the m
The following table summarizes the options and settings available for each cluster type:
{{% include file="/rancher/v2.6/en/cluster-provisioning/cluster-capabilities-table" %}}
{{% include file="/rancher/v2.6/en/cluster-provisioning/cluster-capabilities-table</summary>
versioned_docs/version-2.6/v2.6/en/cluster-admin/editing-clusters/rke-config-reference/rke-config-reference.md
+8 -7
View File
@@ -79,7 +79,7 @@ To edit an RKE config file directly from the Rancher UI,
> Some advanced configuration options are not exposed in the Rancher UI forms, but they can be enabled by editing the RKE cluster configuration file in YAML. For the complete reference of configurable options for RKE Kubernetes clusters in YAML, see the [RKE documentation.]({{<baseurl>}}/rke/latest/en/config-options/)
### Kubernetes Version
### Kubernetes Version
The version of Kubernetes installed on your cluster nodes. Rancher packages its own version of Kubernetes based on [hyperkube](https://github.com/rancher/hyperkube).
@@ -104,7 +104,7 @@ When Weave is selected as network provider, Rancher will automatically enable en
### Project Network Isolation
If your network provider allows project network isolation, you can choose whether to enable or disable inter-project communication.
If your network provider allows project network isolation, you can choose whether to enable or disable inter-project communication.
Project network isolation is available if you are using any RKE network plugin that supports the enforcement of Kubernetes network policies, such as Canal or the Cisco ACI plugin.
@@ -127,7 +127,7 @@ The private registry configuration option tells Rancher where to pull the [syste
- **System images** are components needed to maintain the Kubernetes cluster.
- **Add-ons** are used to deploy several cluster components, including network plug-ins, the ingress controller, the DNS provider, or the metrics server.
For more information on setting up a private registry for components applied during the provisioning of the cluster, see the [RKE documentation on private registries]({{<baseurl>}}/rke/latest/en/config-options/private-registries/).
For more information on setting up a private registry for components applied during the provisioning of the cluster, see the [RKE documentation on private registries]({{<baseurl>}}/rke/latest/en/config-options/private-registries/).
Rancher v2.6 introduced the ability to configure [ECR registries for RKE clusters]({{<baseurl>}}/rke/latest/en/config-options/private-registries/#amazon-elastic-container-registry-ecr-private-registry-setup).
@@ -151,7 +151,7 @@ For information on using the Rancher UI to set up node pools in an RKE cluster,
If you want to publish your applications in a high-availability configuration, and you're hosting your nodes with a cloud-provider that doesn't have a native load-balancing feature, enable this option to use NGINX Ingress within the cluster.
### Metrics Server Monitoring
### Metrics Server Monitoring
Option to enable or disable [Metrics Server]({{<baseurl>}}/rke/latest/en/config-options/add-ons/metrics-server/).
@@ -165,7 +165,7 @@ You must have an existing Pod Security Policy configured before you can use this
### Docker Version on Nodes
Configures whether nodes are allowed to run versions of Docker that Rancher doesn't officially support.
Configures whether nodes are allowed to run versions of Docker that Rancher doesn't officially support.
If you choose to require a supported Docker version, Rancher will stop pods from running on nodes that don't have a supported Docker version installed.
@@ -209,7 +209,8 @@ For the complete reference for configurable options for RKE Kubernetes clusters
RKE (Rancher Kubernetes Engine) is the tool that Rancher uses to provision Kubernetes clusters. Rancher's cluster config files used to have the same structure as [RKE config files,]({{<baseurl>}}/rke/latest/en/example-yamls/) but the structure changed so that in Rancher, RKE cluster config items are separated from non-RKE config items. Therefore, configuration for your cluster needs to be nested under the `rancher_kubernetes_engine_config` directive in the cluster config file. Cluster config files created with earlier versions of Rancher will need to be updated for this format. An example cluster config file is included below.
{{% accordion id="v2.3.0-cluster-config-file" label="Example Cluster Config File" %}}
<details id="v2.3.0-cluster-config-file">
<summary>Example Cluster Config File</summary>
```yaml
#
@@ -301,7 +302,7 @@ rancher_kubernetes_engine_config: # Your RKE template config goes here.
ssh_agent_auth: false
windows_prefered_cluster: false
```
{{% /accordion %}}
</details>
### Default DNS provider
versioned_docs/version-2.6/v2.6/en/cluster-provisioning/cluster-provisioning.md
+1 -1
View File
@@ -28,7 +28,7 @@ This section covers the following topics:
The following table summarizes the options and settings available for each cluster type:
{{% include file="/rancher/v2.6/en/cluster-provisioning/cluster-capabilities-table" %}}
{{% include file="/rancher/v2.6/en/cluster-provisioning/cluster-capabilities-table</summary>
# Setting up Clusters in a Hosted Kubernetes Provider
versioned_docs/version-2.6/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers/azure/azure.md
+29 -27
View File
@@ -31,7 +31,7 @@ Visit [Azure portal](https://portal.azure.com), login and go to **Azure Active D
If you want to use the Azure CLI, you can run the command `az account show` to get the information.
### 2. Set up the Azure Client ID and Azure Client Secret
### 2. Set up the Azure Client ID and Azure Client Secret
Visit [Azure portal](https://portal.azure.com), login and follow the steps below to create an **App Registration** and the corresponding **Azure Client ID** (aadClientId) and **Azure Client Secret** (aadClientSecret).
@@ -75,36 +75,38 @@ Only hosts expected to be load balancer back ends need to be in this group.
1. Choose "Azure" from the Cloud Provider drop-down in the Cluster Configuration section.
1. * Supply the Cloud Provider Configuration. Note that Rancher will automatically create a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you will need to specify them before creating the cluster.
1. * Supply the Cloud Provider Configuration. Note that Rancher will automatically create a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you will need to specify them before creating the cluster.
* You can click on "Show Advanced" to see more of these automatically generated names and update them if
necessary. Your Cloud Provider Configuration **must** match the fields in the Machine Pools section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group.
necessary. Your Cloud Provider Configuration **must** match the fields in the Machine Pools section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group.
* An example is provided below. You will modify it as needed.
{{% accordion id="v2.6.0-cloud-provider-config-file" label="Example Cloud Provider Config" %}}
<details id="v2.6.0-cloud-provider-config-file">
<summary>Example Cloud Provider Config</summary>
```yaml
{
"cloud":"AzurePublicCloud",
"tenantId": "YOUR TENANTID HERE",
"aadClientId": "YOUR AADCLIENTID HERE",
"aadClientSecret": "YOUR AADCLIENTSECRET HERE",
"subscriptionId": "YOUR SUBSCRIPTIONID HERE",
"resourceGroup": "docker-machine",
"location": "westus",
"subnetName": "docker-machine",
"securityGroupName": "rancher-managed-KA4jV9V2",
"securityGroupResourceGroup": "docker-machine",
"vnetName": "docker-machine-vnet",
"vnetResourceGroup": "docker-machine",
"primaryAvailabilitySetName": "docker-machine",
"routeTableResourceGroup": "docker-machine",
"cloudProviderBackoff": false,
"useManagedIdentityExtension": false,
"useInstanceMetadata": true
}
```
</details>
```yaml
{
"cloud":"AzurePublicCloud",
"tenantId": "YOUR TENANTID HERE",
"aadClientId": "YOUR AADCLIENTID HERE",
"aadClientSecret": "YOUR AADCLIENTSECRET HERE",
"subscriptionId": "YOUR SUBSCRIPTIONID HERE",
"resourceGroup": "docker-machine",
"location": "westus",
"subnetName": "docker-machine",
"securityGroupName": "rancher-managed-KA4jV9V2",
"securityGroupResourceGroup": "docker-machine",
"vnetName": "docker-machine-vnet",
"vnetResourceGroup": "docker-machine",
"primaryAvailabilitySetName": "docker-machine",
"routeTableResourceGroup": "docker-machine",
"cloudProviderBackoff": false,
"useManagedIdentityExtension": false,
"useInstanceMetadata": true
}
```
{{% /accordion %}}
1. Under the **Cluster Configuration > Advanced** section, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`
1. Click the **Create** button to submit the form and create the cluster.
versioned_docs/version-2.6/v2.6/en/deploy-across-clusters/fleet/fleet.md
+6 -6
View File
@@ -30,12 +30,12 @@ Follow the steps below to access Continuous Delivery in the Rancher UI:
1. Click **☰ > Continuous Delivery**.
1. Select your namespace at the top of the menu, noting the following:
- By default,`fleet-default` is selected which includes all downstream clusters that are registered through Rancher.
- You may switch to `fleet-local`, which only contains the `local` cluster, or you may create your own workspace to which you may assign and move clusters.
1. Select your namespace at the top of the menu, noting the following:
- By default,`fleet-default` is selected which includes all downstream clusters that are registered through Rancher.
- You may switch to `fleet-local`, which only contains the `local` cluster, or you may create your own workspace to which you may assign and move clusters.
- You can then manage clusters by clicking on **Clusters** on the left navigation bar.
1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace.
1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace.
1. Select your [git repository](https://fleet.rancher.io/gitrepo-add/) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-structure/). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar.
@@ -64,9 +64,9 @@ The Helm chart in the git repository must include its dependencies in the charts
# Troubleshooting
---
* **Known Issue:** clientSecretName and helmSecretName secrets for Fleet gitrepos are not included in the backup nor restore created by the [backup-restore-operator]({{<baseurl>}}/rancher/v2.6/en/backups/back-up-rancher/#1-install-the-rancher-backups-operator). We will update the community once a permanent solution is in place.
* **Known Issue:** clientSecretName and helmSecretName secrets for Fleet gitrepos are not included in the backup nor restore created by the [backup-restore-operator]({{<baseurl>}}/rancher/v2.6/en/backups/back-up-rancher/#1-install-the-rancher-backups-operator). We will update the community once a permanent solution is in place.
* **Temporary Workaround:** </br>
* **Temporary Workaround:** <br/>
By default, user-defined secrets are not backed up in Fleet. It is necessary to recreate secrets if performing a disaster recovery restore or migration of Rancher into a fresh cluster. To modify resourceSet to include extra resources you want to backup, refer to docs [here](https://github.com/rancher/backup-restore-operator#user-flow).
---
versioned_docs/version-2.6/v2.6/en/faq/dockershim/dockershim.md
+10 -10
View File
@@ -17,30 +17,30 @@ For users looking to use another container runtime, Rancher has the edge-focused
### FAQ
<br>
<br/>
Q. Do I have to upgrade Rancher to get Rancher’s support of the upstream Dockershim?
Q. Do I have to upgrade Rancher to get Rancher’s support of the upstream Dockershim?
The upstream support of Dockershim begins for RKE in Kubernetes 1.21. You will need to be on Rancher 2.6 or above to have support for RKE with Kubernetes 1.21. See our [support matrix](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.6.0/) for details.
<br>
<br/>
Q. I am currently on RKE with Kubernetes 1.20. Do I need to upgrade to RKE with Kubernetes 1.21 sooner to avoid being out of support for Dockershim?
Q. I am currently on RKE with Kubernetes 1.20. Do I need to upgrade to RKE with Kubernetes 1.21 sooner to avoid being out of support for Dockershim?
A. The version of Dockershim in RKE with Kubernetes 1.20 will continue to work and is not scheduled for removal upstream until Kubernetes 1.24. It will only emit a warning of its future deprecation, which Rancher has mitigated in RKE with Kubernetes 1.21. You can plan your upgrade to Kubernetes 1.21 as you would normally, but should consider enabling the external Dockershim by Kubernetes 1.22. The external Dockershim will need to be enabled before upgrading to Kubernetes 1.24, at which point the existing implementation will be removed.
For more information on the deprecation and its timeline, see the [Kubernetes Dockershim Deprecation FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed).
<br>
<br/>
Q: What are my other options if I don’t want to depend on the Dockershim?
Q: What are my other options if I don’t want to depend on the Dockershim?
A: You can use a runtime like containerd with Kubernetes that does not require Dockershim support. RKE2 or K3s are two options for doing this.
<br>
<br/>
Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options?
Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options?
A: Rancher is exploring the possibility of an in-place upgrade path. Alternatively you can always migrate workloads from one cluster to another using kubectl.
A: Rancher is exploring the possibility of an in-place upgrade path. Alternatively you can always migrate workloads from one cluster to another using kubectl.
<br>
<br/>
versioned_docs/version-2.6/v2.6/en/faq/faq.md
+11 -11
View File
@@ -7,25 +7,25 @@ This FAQ is a work in progress designed to answers the questions our users most
See [Technical FAQ]({{<baseurl>}}/rancher/v2.6/en/faq/technical/), for frequently asked technical questions.
<br>
<br/>
**Does Rancher v2.x support Docker Swarm and Mesos as environment types?**
When creating an environment in Rancher v2.x, Swarm and Mesos will no longer be standard options you can select. However, both Swarm and Mesos will continue to be available as Catalog applications you can deploy. It was a tough decision to make but, in the end, it came down to adoption. For example, out of more than 15,000 clusters, only about 200 or so are running Swarm.
<br>
<br/>
**Is it possible to manage Azure Kubernetes Services with Rancher v2.x?**
Yes.
<br>
<br/>
**Does Rancher support Windows?**
As of Rancher 2.3.0, we support Windows Server 1809 containers. For details on how to set up a cluster with Windows worker nodes, refer to the section on [configuring custom clusters for Windows.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/)
<br>
<br/>
**Does Rancher support Istio?**
@@ -33,37 +33,37 @@ As of Rancher 2.3.0, we support [Istio.]({{<baseurl>}}/rancher/v2.6/en/istio/)
Furthermore, Istio is implemented in our micro-PaaS "Rio", which works on Rancher 2.x along with any CNCF compliant Kubernetes cluster. You can read more about it [here](https://rio.io/)
<br>
<br/>
**Will Rancher v2.x support Hashicorp's Vault for storing secrets?**
Secrets management is on our roadmap but we haven't assigned it to a specific release yet.
Secrets management is on our roadmap but we haven't assigned it to a specific release yet.
<br>
<br/>
**Does Rancher v2.x support RKT containers as well?**
At this time, we only support Docker.
<br>
<br/>
**Does Rancher v2.x support Calico, Contiv, Contrail, Flannel, Weave net, etc., for embedded and registered Kubernetes?**
Out-of-the-box, Rancher provides the following CNI network providers for Kubernetes clusters: Canal, Flannel, Calico and Weave. Always refer to the [Rancher Support Matrix](https://rancher.com/support-maintenance-terms/) for details about what is officially supported.
<br>
<br/>
**Are you planning on supporting Traefik for existing setups?**
We don't currently plan on providing embedded Traefik support, but we're still exploring load-balancing approaches.
<br>
<br/>
**Can I import OpenShift Kubernetes clusters into v2.x?**
Our goal is to run any upstream Kubernetes clusters. Therefore, Rancher v2.x should work with OpenShift, but we haven't tested it yet.
<br>
<br/>
**Are you going to integrate Longhorn?**
versioned_docs/version-2.6/v2.6/en/faq/networking/cni-providers/cni-providers.md
+6 -6
View File
@@ -46,7 +46,7 @@ CNI network providers using this network model include Calico and Cilium. Cilium
### RKE Kubernetes clusters
Out-of-the-box, Rancher provides the following CNI network providers for RKE Kubernetes clusters: Canal, Flannel, and Weave.
Out-of-the-box, Rancher provides the following CNI network providers for RKE Kubernetes clusters: Canal, Flannel, and Weave.
You can choose your CNI network provider when you create new Kubernetes clusters from Rancher.
@@ -95,7 +95,7 @@ For more information, see the following pages:
### RKE2 Kubernetes clusters
Out-of-the-box, Rancher provides the following CNI network providers for RKE2 Kubernetes clusters: [Canal](#canal) (see above section), Calico, and Cilium.
Out-of-the-box, Rancher provides the following CNI network providers for RKE2 Kubernetes clusters: [Canal](#canal) (see above section), Calico, and Cilium.
You can choose your CNI network provider when you create new Kubernetes clusters from Rancher.
@@ -111,7 +111,7 @@ Kubernetes workers should open TCP port `179` if using BGP or UDP port `4789` if
>**Important:** In Rancher v2.6.3, Calico probes fail on Windows nodes upon RKE2 installation. <b>Note that this issue is resolved in v2.6.4.<b>
>
>- To work around this issue, first navigate to `https://<rancherserverurl>/v3/settings/windows-rke2-install-script`.
>- To work around this issue, first navigate to `https://<rancherserverurl>/v3/settings/windows-rke2-install-script`.
>
>- There, change the current setting: `https://raw.githubusercontent.com/rancher/wins/v0.1.3/install.ps1` to this new setting: `https://raw.githubusercontent.com/rancher/rke2/master/windows/rke2-install.ps1`.
@@ -126,12 +126,12 @@ For more information, see the following pages:
![Cilium Logo]({{<baseurl>}}/img/rancher/cilium-logo.png)
Cilium enables networking and network policies (L3, L4, and L7) in Kubernetes. By default, Cilium uses eBPF technologies to route packets inside the node and VXLAN to send packets to other nodes. Unencapsulated techniques can also be configured.
Cilium enables networking and network policies (L3, L4, and L7) in Kubernetes. By default, Cilium uses eBPF technologies to route packets inside the node and VXLAN to send packets to other nodes. Unencapsulated techniques can also be configured.
Cilium recommends kernel versions greater than 5.2 to be able to leverage the full potential of eBPF. Kubernetes workers should open TCP port `8472` for VXLAN and TCP port `4240` for health checks. In addition, ICMP 8/0 must be enabled for health checks. For more information, check [Cilium System Requirements](https://docs.cilium.io/en/latest/operations/system_requirements/#firewall-requirements).
##### Ingress Routing Across Nodes in Cilium
<br>
<br/>
By default, Cilium does not allow pods to contact pods on other nodes. To work around this, enable the ingress controller to route requests across nodes with a `CiliumNetworkPolicy`.
After selecting the Cilium CNI and enabling Project Network Isolation for your new cluster, configure as follows:
@@ -143,7 +143,7 @@ metadata:
name: hn-nodes
namespace: default
spec:
endpointSelector: {}
endpointSelector: {}
ingress:
- fromEntities:
- remote-node
versioned_docs/version-2.6/v2.6/en/faq/security/security.md
+1 -1
View File
@@ -8,7 +8,7 @@ weight: 8007
The Hardening Guide is now located in the main [Security]({{<baseurl>}}/rancher/v2.6/en/security/) section.
<br>
<br/>
**What are the results of Rancher's Kubernetes cluster when it is CIS benchmarked?**
versioned_docs/version-2.6/v2.6/en/helm-charts/creating-apps/creating-apps.md
+2 -2
View File
@@ -68,7 +68,7 @@ Before you create your own custom catalog, you should have a basic understanding
<figcaption>Rancher Chart with <code>questions.yml</code> (top) vs. Helm Chart without (bottom)</figcaption>
![questions.yml]({{<baseurl>}}/img/rancher/rancher-app-2.6.png)
![questions.yml]({{<baseurl>}}/img/rancher/rancher-app-2.6.png)
![values.yaml]({{<baseurl>}}/img/rancher/helm-app-2.6.png)
@@ -118,7 +118,7 @@ This reference contains variables that you can use in `questions.yml` nested und
| max_length | int | false | Max character length.|
| min | int | false | Min integer length. |
| max | int | false | Max integer length. |
| options | []string | false | Specify the options when the variable type is `enum`, for example: options:<br> - "ClusterIP" <br> - "NodePort" <br> - "LoadBalancer"|
| options | []string | false | Specify the options when the variable type is `enum`, for example: options:<br/> - "ClusterIP" <br/> - "NodePort" <br/> - "LoadBalancer"|
| valid_chars | string | false | Regular expression for input chars validation. |
| invalid_chars | string | false | Regular expression for invalid input chars validation.|
| subquestions | []subquestion | false| Add an array of subquestions.|
versioned_docs/version-2.6/v2.6/en/installation/install-rancher-on-k8s/install-rancher-on-k8s.md
+3 -2
View File
@@ -113,7 +113,8 @@ There are three recommended options for the source of the certificate used for T
This step is only required to use certificates issued by Rancher's generated CA (`ingress.tls.source=rancher`) or to request Let's Encrypt issued certificates (`ingress.tls.source=letsEncrypt`).
{{% accordion id="cert-manager" label="Click to Expand" %}}
<details id="cert-manager">
<summary>Click to Expand</summary>
> **Important:** Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.11.0, please see our [upgrade documentation]({{<baseurl>}}/rancher/v2.6/en/installation/resources/upgrading-cert-manager/).
@@ -147,7 +148,7 @@ cert-manager-cainjector-577f6d9fd7-tr77l 1/1 Running 0 2m
cert-manager-webhook-787858fcdb-nlzsq 1/1 Running 0 2m
```
{{% /accordion %}}
</details>
### 5. Install Rancher with Helm and Your Chosen Certificate Option

Some files were not shown because too many files have changed in this diff Show More