From 1cc972d397ddb8f5f71f4f29a305f7f0cc6f6055 Mon Sep 17 00:00:00 2001 From: Billy Tat Date: Thu, 18 Aug 2022 10:03:17 -0700 Subject: [PATCH] Validation errors --- .../openldap/openldap-config/openldap-config.md | 12 ++++++------ .../testing-hpa/testing-hpa.md | 2 +- .../load-balancers/load-balancers.md | 2 +- .../openldap/openldap-config/openldap-config.md | 12 ++++++------ .../eks-config-reference/eks-config-reference.md | 12 ++++++------ .../testing-hpa/testing-hpa.md | 6 +++--- .../load-balancers/load-balancers.md | 2 +- 7 files changed, 24 insertions(+), 24 deletions(-) diff --git a/versioned_docs/version-2.0-2.4/admin-settings/authentication/openldap/openldap-config/openldap-config.md b/versioned_docs/version-2.0-2.4/admin-settings/authentication/openldap/openldap-config/openldap-config.md index 74be173fe1e..2e28c77e456 100644 --- a/versioned_docs/version-2.0-2.4/admin-settings/authentication/openldap/openldap-config/openldap-config.md +++ b/versioned_docs/version-2.0-2.4/admin-settings/authentication/openldap/openldap-config/openldap-config.md @@ -15,11 +15,11 @@ For further details on configuring OpenLDAP, refer to the [official documentatio - [User schema configuration](#user-schema-configuration) - [Group schema configuration](#group-schema-configuration) -## Background: OpenLDAP Authentication Flow - -1. When a user attempts to login with his LDAP credentials, Rancher creates an initial bind to the LDAP server using a service account with permissions to search the directory and read user/group attributes. -2. Rancher then searches the directory for the user by using a search filter based on the provided username and configured attribute mappings. -3. Once the user has been found, he is authenticated with another LDAP bind request using the user's DN and provided password. +## Background: OpenLDAP Authentication Flow + +1. When a user attempts to login with his LDAP credentials, Rancher creates an initial bind to the LDAP server using a service account with permissions to search the directory and read user/group attributes. +2. Rancher then searches the directory for the user by using a search filter based on the provided username and configured attribute mappings. +3. Once the user has been found, he is authenticated with another LDAP bind request using the user's DN and provided password. 4. Once authentication succeeded, Rancher then resolves the group memberships both from the membership attribute in the user's object and by performing a group search based on the configured user mapping attribute. # OpenLDAP Server Configuration @@ -73,7 +73,7 @@ The table below details the parameters for the user schema configuration. The table below details the parameters for the group schema configuration. -
Group Schema Configuration Parameters
+
Group Schema Configuration Parameters
| Parameter | Description | |:--|:--| diff --git a/versioned_docs/version-2.0-2.4/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md b/versioned_docs/version-2.0-2.4/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md index 9e488b4ffc8..e80771520d1 100644 --- a/versioned_docs/version-2.0-2.4/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md +++ b/versioned_docs/version-2.0-2.4/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md @@ -205,7 +205,7 @@ For HPA to work correctly, service deployments should have resources request def 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.

- **To Test Autoscaling Using Resource Metrics:** + **To Test Autoscaling Using Resource Metrics:**
Upscale to 2 Pods: CPU Usage Up to Target diff --git a/versioned_docs/version-2.0-2.4/k8s-in-rancher/load-balancers-and-ingress/load-balancers/load-balancers.md b/versioned_docs/version-2.0-2.4/k8s-in-rancher/load-balancers-and-ingress/load-balancers/load-balancers.md index c3b39f63b54..21c83f40898 100644 --- a/versioned_docs/version-2.0-2.4/k8s-in-rancher/load-balancers-and-ingress/load-balancers/load-balancers.md +++ b/versioned_docs/version-2.0-2.4/k8s-in-rancher/load-balancers-and-ingress/load-balancers/load-balancers.md @@ -58,7 +58,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 sslip.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 ..a.b.c.d.sslip.io. +2. Ask Rancher to generate an sslip.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 `..a.b.c.d.sslip.io`. The benefit of using sslip.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. diff --git a/versioned_docs/version-2.5/admin-settings/authentication/openldap/openldap-config/openldap-config.md b/versioned_docs/version-2.5/admin-settings/authentication/openldap/openldap-config/openldap-config.md index 5a12e5f78c3..9aa44586a08 100644 --- a/versioned_docs/version-2.5/admin-settings/authentication/openldap/openldap-config/openldap-config.md +++ b/versioned_docs/version-2.5/admin-settings/authentication/openldap/openldap-config/openldap-config.md @@ -17,11 +17,11 @@ For further details on configuring OpenLDAP, refer to the [official documentatio - [User schema configuration](#user-schema-configuration) - [Group schema configuration](#group-schema-configuration) -## Background: OpenLDAP Authentication Flow - -1. When a user attempts to login with his LDAP credentials, Rancher creates an initial bind to the LDAP server using a service account with permissions to search the directory and read user/group attributes. -2. Rancher then searches the directory for the user by using a search filter based on the provided username and configured attribute mappings. -3. Once the user has been found, he is authenticated with another LDAP bind request using the user's DN and provided password. +## Background: OpenLDAP Authentication Flow + +1. When a user attempts to login with his LDAP credentials, Rancher creates an initial bind to the LDAP server using a service account with permissions to search the directory and read user/group attributes. +2. Rancher then searches the directory for the user by using a search filter based on the provided username and configured attribute mappings. +3. Once the user has been found, he is authenticated with another LDAP bind request using the user's DN and provided password. 4. Once authentication succeeded, Rancher then resolves the group memberships both from the membership attribute in the user's object and by performing a group search based on the configured user mapping attribute. # OpenLDAP Server Configuration @@ -75,7 +75,7 @@ The table below details the parameters for the user schema configuration. The table below details the parameters for the group schema configuration. -
Group Schema Configuration Parameters
+
Group Schema Configuration Parameters
| Parameter | Description | |:--|:--| diff --git a/versioned_docs/version-2.5/cluster-admin/editing-clusters/eks-config-reference/eks-config-reference.md b/versioned_docs/version-2.5/cluster-admin/editing-clusters/eks-config-reference/eks-config-reference.md index fd1ee175704..aab16f4b6ea 100644 --- a/versioned_docs/version-2.5/cluster-admin/editing-clusters/eks-config-reference/eks-config-reference.md +++ b/versioned_docs/version-2.5/cluster-admin/editing-clusters/eks-config-reference/eks-config-reference.md @@ -344,17 +344,17 @@ If you choose to assign a public IP address to your cluster's worker nodes, you
Click to expand -If you're using **Custom: Choose from your existing VPC and Subnets**: + If you're using **Custom: Choose from your existing VPC and Subnets**: -(If you're using **Standard**, skip to the [instance options.)](#select-instance-options-2-4) + (If you're using **Standard**, skip to the [instance options.)](#select-instance-options-2-4) -1. Make sure **Custom: Choose from your existing VPC and Subnets** is selected. + 1. Make sure **Custom: Choose from your existing VPC and Subnets** is selected. -1. From the drop-down that displays, choose a VPC. + 1. From the drop-down that displays, choose a VPC. -1. Click **Next: Select Subnets**. Then choose one of the **Subnets** that displays. + 1. Click **Next: Select Subnets**. Then choose one of the **Subnets** that displays. -1. Click **Next: Select Security Group**. + 1. Click **Next: Select Security Group**.
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. diff --git a/versioned_docs/version-2.5/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md b/versioned_docs/version-2.5/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md index 2169b69812e..3188cf97d66 100644 --- a/versioned_docs/version-2.5/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md +++ b/versioned_docs/version-2.5/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md @@ -6,7 +6,7 @@ aliases: - /rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/ --- -This document describes how to check the status of your HPAs after scaling them up or down with your load testing tool. For information on how to check the status from the Rancher UI (at least version 2.3.x), refer to [Managing HPAs with the Rancher UI]({{}}/rancher/v2.5/en/k8s-in-rancher/horitzontal-pod-autoscaler/manage-hpa-with-kubectl/). +This document describes how to check the status of your HPAs after scaling them up or down with your load testing tool. For information on how to check the status from the Rancher UI (at least version 2.3.x), refer to [Managing HPAs with the Rancher UI](manage-hpas-with-kubectl.md). For HPA to work correctly, service deployments should have resources request definitions for containers. Follow this hello-world example to test if HPA is working correctly. @@ -67,7 +67,7 @@ For HPA to work correctly, service deployments should have resources request def app: hello-world ``` -
+ 1. Deploy it to your cluster. @@ -205,7 +205,7 @@ For HPA to work correctly, service deployments should have resources request def 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.

- **To Test Autoscaling Using Resource Metrics:** + **To Test Autoscaling Using Resource Metrics:**
Upscale to 2 Pods: CPU Usage Up to Target diff --git a/versioned_docs/version-2.5/k8s-in-rancher/load-balancers-and-ingress/load-balancers/load-balancers.md b/versioned_docs/version-2.5/k8s-in-rancher/load-balancers-and-ingress/load-balancers/load-balancers.md index d30335a67f1..8da2331f9ed 100644 --- a/versioned_docs/version-2.5/k8s-in-rancher/load-balancers-and-ingress/load-balancers/load-balancers.md +++ b/versioned_docs/version-2.5/k8s-in-rancher/load-balancers-and-ingress/load-balancers/load-balancers.md @@ -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 sslip.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 ..a.b.c.d.sslip.io. +2. Ask Rancher to generate an sslip.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 `..a.b.c.d.sslip.io`. The benefit of using sslip.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.