mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 04:28:15 +00:00
* canonicized horizontal-pod-autoscaler * canonicized load-balancer-and-ingress-controller * canonicized workloads-and-pods * canonicized kubernetes-resource-setup
This commit is contained in:
Marty Hernandez Avedon
@@ -2,6 +2,10 @@
|
||||
title: ConfigMaps
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/configmaps"/>
|
||||
</head>
|
||||
|
||||
While most types of Kubernetes secrets store sensitive information, [ConfigMaps](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/) store general configuration information, such as a group of config files. Because ConfigMaps don't store sensitive information, they can be updated automatically, and therefore don't require their containers to be restarted following update (unlike most secret types, which require manual updates and a container restart to take effect).
|
||||
|
||||
ConfigMaps accept key value pairs in common string formats, like config files or JSON blobs. After you upload a config map, any workload can reference it as either an environment variable or a volume mount.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Services
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/create-services"/>
|
||||
</head>
|
||||
|
||||
Pod configuration is managed by Deployments, StatefulSets and Daemonsets, whereas services direct traffic to pods using selectors.
|
||||
|
||||
For every workload (with at least one port configured) created, a complementing Service Discovery entry is created. This Service Discovery entry enables DNS resolution for the workload's pods using the following naming convention:
|
||||
|
||||
+4
@@ -3,6 +3,10 @@ title: Encrypting HTTP Communication
|
||||
description: Learn how to add an SSL (Secure Sockets Layer) certificate or TLS (Transport Layer Security) certificate
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/encrypt-http-communication"/>
|
||||
</head>
|
||||
|
||||
When you create an ingress within Rancher/Kubernetes, you must provide it with a secret that includes a TLS private key and certificate, which are used to encrypt and decrypt communications that come through the ingress. You can make certificates available for ingress use by adding the certificate to the ingress deployment.
|
||||
|
||||
:::note Prerequisite:
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Background Information on HPAs
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/horizontal-pod-autoscaler/about-hpas"/>
|
||||
</head>
|
||||
|
||||
The [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) (HPA) is a Kubernetes feature that allows you to configure your cluster to automatically scale the services it's running up or down. This section provides explanation on how HPA works with Kubernetes.
|
||||
|
||||
## Why Use Horizontal Pod Autoscaler?
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Managing HPAs with kubectl
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/horizontal-pod-autoscaler/manage-hpas-with-kubectl"/>
|
||||
</head>
|
||||
|
||||
This section describes HPA management with `kubectl`. This document has instructions for how to:
|
||||
|
||||
- Create an HPA
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Managing HPAs with the Rancher UI
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/horizontal-pod-autoscaler/manage-hpas-with-ui"/>
|
||||
</head>
|
||||
|
||||
The Rancher UI supports creating, managing, and deleting HPAs. You can configure CPU or memory usage as the metric that the HPA uses to scale.
|
||||
|
||||
If you want to create HPAs that scale based on other metrics than CPU and memory, refer to [Configuring HPA to Scale Using Custom Metrics with Prometheus](./manage-hpas-with-kubectl.md#configuring-hpa-to-scale-using-custom-metrics-with-prometheus).
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Testing HPAs with kubectl
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/horizontal-pod-autoscaler/test-hpas-with-kubectl"/>
|
||||
</head>
|
||||
|
||||
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.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Kubernetes Registry and Container Image Registry
|
||||
description: Learn about the container image registry and Kubernetes registry, their use cases, and how to use a private registry with the Rancher UI
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/kubernetes-and-docker-registries"/>
|
||||
</head>
|
||||
Registries are Kubernetes secrets containing credentials used to authenticate with [private container registries](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/).
|
||||
|
||||
The word "registry" can mean two things, depending on whether it is used to refer to a container or Kubernetes registry:
|
||||
|
||||
+4
@@ -3,6 +3,10 @@ title: Adding Ingresses
|
||||
description: Ingresses can be added for workloads to provide load balancing, SSL termination and host/path-based routing. Learn how to add Rancher ingress
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/add-ingresses"/>
|
||||
</head>
|
||||
|
||||
Ingresses can be added for workloads to provide load balancing, SSL termination and host/path based routing. When using ingresses in a project, you can program the ingress hostname to an external DNS by setting up a Global DNS entry.
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
|
||||
+4
@@ -3,6 +3,10 @@ title: Ingress Configuration
|
||||
description: Ingress configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/ingress-configuration"/>
|
||||
</head>
|
||||
|
||||
:::note
|
||||
|
||||
For Kubernetes v1.21 and up, the NGINX Ingress controller no longer runs in hostNetwork by default. It instead uses hostPorts for port 80 and port 443, so you can configure the admission webhook to be accessible only through the ClusterIP. This ensures that the webhook is only accessible from within the cluster.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: "Layer 4 and Layer 7 Load Balancing"
|
||||
description: "Kubernetes supports load balancing in two ways: Layer-4 Load Balancing and Layer-7 Load Balancing. Learn about the support for each way in different deployments"
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/layer-4-and-layer-7-load-balancing"/>
|
||||
</head>
|
||||
Kubernetes supports load balancing in two ways: Layer-4 Load Balancing and Layer-7 Load Balancing.
|
||||
|
||||
## Layer-4 Load Balancer
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Secrets
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/secrets"/>
|
||||
</head>
|
||||
|
||||
[Secrets](https://kubernetes.io/docs/concepts/configuration/secret/#overview-of-secrets) store sensitive data like passwords, tokens, or keys. They may contain one or more key value pairs.
|
||||
|
||||
:::note
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Adding a Sidecar
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/add-a-sidecar"/>
|
||||
</head>
|
||||
|
||||
A _sidecar_ is a container that extends or enhances the main container in a pod. The main container and the sidecar share a pod, and therefore share the same network space and storage. You can add sidecars to existing workloads by using the **Add a Sidecar** option.
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
|
||||
+4
@@ -3,6 +3,10 @@ title: Deploying Workloads
|
||||
description: Read this step by step guide for deploying workloads. Deploy a workload to run an application in one or more containers.
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/deploy-workloads"/>
|
||||
</head>
|
||||
|
||||
Deploy a workload to run an application in one or more containers.
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Rolling Back Workloads
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/roll-back-workloads"/>
|
||||
</head>
|
||||
|
||||
Sometimes there is a need to rollback to the previous version of the application, either for debugging purposes or because an upgrade did not go as planned.
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Upgrading Workloads
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/upgrade-workloads"/>
|
||||
</head>
|
||||
|
||||
When a new version of an application image is released on Docker Hub, you can upgrade any workloads running a previous version of the application to the new one.
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: ConfigMaps
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/configmaps"/>
|
||||
</head>
|
||||
|
||||
While most types of Kubernetes secrets store sensitive information, [ConfigMaps](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/) store general configuration information, such as a group of config files. Because ConfigMaps don't store sensitive information, they can be updated automatically, and therefore don't require their containers to be restarted following update (unlike most secret types, which require manual updates and a container restart to take effect).
|
||||
|
||||
ConfigMaps accept key value pairs in common string formats, like config files or JSON blobs. After you upload a config map, any workload can reference it as either an environment variable or a volume mount.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Service Discovery
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/create-services"/>
|
||||
</head>
|
||||
|
||||
For every workload created, a complementing Service Discovery entry is created. This Service Discovery entry enables DNS resolution for the workload's pods using the following naming convention:
|
||||
`<workload>.<namespace>.svc.cluster.local`.
|
||||
|
||||
|
||||
+4
@@ -3,6 +3,10 @@ title: Encrypting HTTP Communication
|
||||
description: Learn how to add an SSL (Secure Sockets Layer) certificate or TLS (Transport Layer Security) certificate to either a project, a namespace, or both, so that you can add it to deployments
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/encrypt-http-communication"/>
|
||||
</head>
|
||||
|
||||
When you create an ingress within Rancher/Kubernetes, you must provide it with a secret that includes a TLS private key and certificate, which are used to encrypt and decrypt communications that come through the ingress. You can make certificates available for ingress use by navigating to its project or namespace, and then uploading the certificate. You can then add the certificate to the ingress deployment.
|
||||
|
||||
Add SSL certificates to either projects, namespaces, or both. A project scoped certificate will be available in all its namespaces.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Background Information on HPAs
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/horizontal-pod-autoscaler/about-hpas"/>
|
||||
</head>
|
||||
|
||||
The [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) (HPA) is a Kubernetes feature that allows you to configure your cluster to automatically scale the services it's running up or down. This section provides explanation on how HPA works with Kubernetes.
|
||||
|
||||
## Why Use Horizontal Pod Autoscaler?
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Managing HPAs with kubectl
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/horizontal-pod-autoscaler/manage-hpas-with-kubectl"/>
|
||||
</head>
|
||||
|
||||
This section describes HPA management with `kubectl`. This document has instructions for how to:
|
||||
|
||||
- Create an HPA
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Managing HPAs with the Rancher UI
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/horizontal-pod-autoscaler/manage-hpas-with-ui"/>
|
||||
</head>
|
||||
|
||||
_Available as of v2.3.0_
|
||||
|
||||
The Rancher UI supports creating, managing, and deleting HPAs. You can configure CPU or memory usage as the metric that the HPA uses to scale.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Testing HPAs with kubectl
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/horizontal-pod-autoscaler/test-hpas-with-kubectl"/>
|
||||
</head>
|
||||
|
||||
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.
|
||||
|
||||
+4
@@ -3,6 +3,10 @@ title: Kubernetes Registry and Docker Registry
|
||||
description: Learn about the Docker registry and Kubernetes registry, their use cases and how to use a private registry with the Rancher UI
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/kubernetes-and-docker-registries"/>
|
||||
</head>
|
||||
|
||||
Registries are Kubernetes secrets containing credentials used to authenticate with [private Docker registries](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/).
|
||||
|
||||
The word "registry" can mean two things, depending on whether it is used to refer to a Docker or Kubernetes registry:
|
||||
|
||||
+4
@@ -3,6 +3,10 @@ title: Adding Ingresses to Your Project
|
||||
description: Ingresses can be added for workloads to provide load balancing, SSL termination and host/path-based routing. Learn how to add Rancher ingress to your project
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/add-ingresses"/>
|
||||
</head>
|
||||
|
||||
Ingress can be added for workloads to provide load balancing, SSL termination and host/path based routing. When using ingresses in a project, you can program the ingress hostname to an external DNS by setting up a [Global DNS entry](../../helm-charts-in-rancher/globaldns.md).
|
||||
|
||||
1. From the **Global** view, open the project that you want to add ingress to.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: "Layer 4 and Layer 7 Load Balancing"
|
||||
description: "Kubernetes supports load balancing in two ways: Layer-4 Load Balancing and Layer-7 Load Balancing. Learn about the support for each way in different deployments"
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/layer-4-and-layer-7-load-balancing"/>
|
||||
</head>
|
||||
Kubernetes supports load balancing in two ways: Layer-4 Load Balancing and Layer-7 Load Balancing.
|
||||
|
||||
## Layer-4 Load Balancer
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Secrets
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/secrets"/>
|
||||
</head>
|
||||
|
||||
[Secrets](https://kubernetes.io/docs/concepts/configuration/secret/#overview-of-secrets) store sensitive data like passwords, tokens, or keys. They may contain one or more key value pairs.
|
||||
|
||||
> This page is about secrets in general. For details on setting up a private registry, refer to the section on [registries.](kubernetes-and-docker-registries.md)
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Adding a Sidecar
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/add-a-sidecar"/>
|
||||
</head>
|
||||
|
||||
A _sidecar_ is a container that extends or enhances the main container in a pod. The main container and the sidecar share a pod, and therefore share the same network space and storage. You can add sidecars to existing workloads by using the **Add a Sidecar** option.
|
||||
|
||||
1. From the **Global** view, open the project running the workload you want to add a sidecar to.
|
||||
|
||||
+4
@@ -3,6 +3,10 @@ title: Deploying Workloads
|
||||
description: Read this step by step guide for deploying workloads. Deploy a workload to run an application in one or more containers.
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/deploy-workloads"/>
|
||||
</head>
|
||||
|
||||
Deploy a workload to run an application in one or more containers.
|
||||
|
||||
1. From the **Global** view, open the project that you want to deploy a workload to.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Rolling Back Workloads
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/roll-back-workloads"/>
|
||||
</head>
|
||||
|
||||
Sometimes there is a need to rollback to the previous version of the application, either for debugging purposes or because an upgrade did not go as planned.
|
||||
|
||||
1. From the **Global** view, open the project running the workload you want to rollback.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Upgrading Workloads
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/upgrade-workloads"/>
|
||||
</head>
|
||||
|
||||
When a new version of an application image is released on Docker Hub, you can upgrade any workloads running a previous version of the application to the new one.
|
||||
|
||||
1. From the **Global** view, open the project running the workload you want to upgrade.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: ConfigMaps
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/configmaps"/>
|
||||
</head>
|
||||
|
||||
While most types of Kubernetes secrets store sensitive information, [ConfigMaps](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/) store general configuration information, such as a group of config files. Because ConfigMaps don't store sensitive information, they can be updated automatically, and therefore don't require their containers to be restarted following update (unlike most secret types, which require manual updates and a container restart to take effect).
|
||||
|
||||
ConfigMaps accept key value pairs in common string formats, like config files or JSON blobs. After you upload a config map, any workload can reference it as either an environment variable or a volume mount.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Service Discovery
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/create-services"/>
|
||||
</head>
|
||||
|
||||
For every workload created, a complementing Service Discovery entry is created. This Service Discovery entry enables DNS resolution for the workload's pods using the following naming convention:
|
||||
`<workload>.<namespace>.svc.cluster.local`.
|
||||
|
||||
|
||||
+4
@@ -3,6 +3,10 @@ title: Encrypting HTTP Communication
|
||||
description: Learn how to add an SSL (Secure Sockets Layer) certificate or TLS (Transport Layer Security) certificate to either a project, a namespace, or both, so that you can add it to deployments
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/encrypt-http-communication"/>
|
||||
</head>
|
||||
|
||||
When you create an ingress within Rancher/Kubernetes, you must provide it with a secret that includes a TLS private key and certificate, which are used to encrypt and decrypt communications that come through the ingress. You can make certificates available for ingress use by navigating to its project or namespace, and then uploading the certificate. You can then add the certificate to the ingress deployment.
|
||||
|
||||
Add SSL certificates to either projects, namespaces, or both. A project scoped certificate will be available in all its namespaces.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Background Information on HPAs
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/horizontal-pod-autoscaler/about-hpas"/>
|
||||
</head>
|
||||
|
||||
The [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) (HPA) is a Kubernetes feature that allows you to configure your cluster to automatically scale the services it's running up or down. This section provides explanation on how HPA works with Kubernetes.
|
||||
|
||||
## Why Use Horizontal Pod Autoscaler?
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Managing HPAs with kubectl
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/horizontal-pod-autoscaler/manage-hpas-with-kubectl"/>
|
||||
</head>
|
||||
|
||||
This section describes HPA management with `kubectl`. This document has instructions for how to:
|
||||
|
||||
- Create an HPA
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Managing HPAs with the Rancher UI
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/horizontal-pod-autoscaler/manage-hpas-with-ui"/>
|
||||
</head>
|
||||
|
||||
The Rancher UI supports creating, managing, and deleting HPAs. You can configure CPU or memory usage as the metric that the HPA uses to scale.
|
||||
|
||||
If you want to create HPAs that scale based on other metrics than CPU and memory, refer to [Configuring HPA to Scale Using Custom Metrics with Prometheus](manage-hpas-with-kubectl.md#configuring-hpa-to-scale-using-custom-metrics-with-prometheus).
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Testing HPAs with kubectl
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/horizontal-pod-autoscaler/test-hpas-with-kubectl"/>
|
||||
</head>
|
||||
|
||||
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.
|
||||
|
||||
+4
@@ -3,6 +3,10 @@ title: Kubernetes Registry and Docker Registry
|
||||
description: Learn about the Docker registry and Kubernetes registry, their use cases and how to use a private registry with the Rancher UI
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/kubernetes-and-docker-registries"/>
|
||||
</head>
|
||||
|
||||
Registries are Kubernetes secrets containing credentials used to authenticate with [private Docker registries](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/).
|
||||
|
||||
The word "registry" can mean two things, depending on whether it is used to refer to a Docker or Kubernetes registry:
|
||||
|
||||
+4
@@ -3,6 +3,10 @@ title: Adding Ingresses to Your Project
|
||||
description: Ingresses can be added for workloads to provide load balancing, SSL termination and host/path-based routing. Learn how to add Rancher ingress to your project
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/add-ingresses"/>
|
||||
</head>
|
||||
|
||||
Ingress can be added for workloads to provide load balancing, SSL termination and host/path based routing. When using ingresses in a project, you can program the ingress hostname to an external DNS by setting up a Global DNS entry.
|
||||
|
||||
1. From the **Global** view, open the project that you want to add ingress to.
|
||||
|
||||
+4
@@ -3,6 +3,10 @@ title: "Layer 4 and Layer 7 Load Balancing"
|
||||
description: "Kubernetes supports load balancing in two ways: Layer-4 Load Balancing and Layer-7 Load Balancing. Learn about the support for each way in different deployments"
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/layer-4-and-layer-7-load-balancing"/>
|
||||
</head>
|
||||
|
||||
Kubernetes supports load balancing in two ways: Layer-4 Load Balancing and Layer-7 Load Balancing.
|
||||
|
||||
## Layer-4 Load Balancer
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Secrets
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/secrets"/>
|
||||
</head>
|
||||
|
||||
[Secrets](https://kubernetes.io/docs/concepts/configuration/secret/#overview-of-secrets) store sensitive data like passwords, tokens, or keys. They may contain one or more key value pairs.
|
||||
|
||||
> This page is about secrets in general. For details on setting up a private registry, refer to the section on [registries.](kubernetes-and-docker-registries.md)
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Adding a Sidecar
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/add-a-sidecar"/>
|
||||
</head>
|
||||
|
||||
A _sidecar_ is a container that extends or enhances the main container in a pod. The main container and the sidecar share a pod, and therefore share the same network space and storage. You can add sidecars to existing workloads by using the **Add a Sidecar** option.
|
||||
|
||||
1. From the **Global** view, open the project running the workload you want to add a sidecar to.
|
||||
|
||||
+4
@@ -3,6 +3,10 @@ title: Deploying Workloads
|
||||
description: Read this step by step guide for deploying workloads. Deploy a workload to run an application in one or more containers.
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/deploy-workloads"/>
|
||||
</head>
|
||||
|
||||
Deploy a workload to run an application in one or more containers.
|
||||
|
||||
1. From the **Global** view, open the project that you want to deploy a workload to.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Rolling Back Workloads
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/roll-back-workloads"/>
|
||||
</head>
|
||||
|
||||
Sometimes there is a need to rollback to the previous version of the application, either for debugging purposes or because an upgrade did not go as planned.
|
||||
|
||||
1. From the **Global** view, open the project running the workload you want to rollback.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Upgrading Workloads
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/upgrade-workloads"/>
|
||||
</head>
|
||||
|
||||
When a new version of an application image is released on Docker Hub, you can upgrade any workloads running a previous version of the application to the new one.
|
||||
|
||||
1. From the **Global** view, open the project running the workload you want to upgrade.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: ConfigMaps
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/configmaps"/>
|
||||
</head>
|
||||
|
||||
While most types of Kubernetes secrets store sensitive information, [ConfigMaps](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/) store general configuration information, such as a group of config files. Because ConfigMaps don't store sensitive information, they can be updated automatically, and therefore don't require their containers to be restarted following update (unlike most secret types, which require manual updates and a container restart to take effect).
|
||||
|
||||
ConfigMaps accept key value pairs in common string formats, like config files or JSON blobs. After you upload a config map, any workload can reference it as either an environment variable or a volume mount.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Services
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/create-services"/>
|
||||
</head>
|
||||
|
||||
Pod configuration is managed by Deployments, StatefulSets and Daemonsets, whereas services direct traffic to pods using selectors.
|
||||
|
||||
For every workload (with at least one port configured) created, a complementing Service Discovery entry is created. This Service Discovery entry enables DNS resolution for the workload's pods using the following naming convention:
|
||||
|
||||
+4
@@ -3,6 +3,10 @@ title: Encrypting HTTP Communication
|
||||
description: Learn how to add an SSL (Secure Sockets Layer) certificate or TLS (Transport Layer Security) certificate
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/encrypt-http-communication"/>
|
||||
</head>
|
||||
|
||||
When you create an ingress within Rancher/Kubernetes, you must provide it with a secret that includes a TLS private key and certificate, which are used to encrypt and decrypt communications that come through the ingress. You can make certificates available for ingress use by adding the certificate to the ingress deployment.
|
||||
|
||||
:::note Prerequisite:
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Background Information on HPAs
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/horizontal-pod-autoscaler/about-hpas"/>
|
||||
</head>
|
||||
|
||||
The [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) (HPA) is a Kubernetes feature that allows you to configure your cluster to automatically scale the services it's running up or down. This section provides explanation on how HPA works with Kubernetes.
|
||||
|
||||
## Why Use Horizontal Pod Autoscaler?
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Managing HPAs with kubectl
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/horizontal-pod-autoscaler/manage-hpas-with-kubectl"/>
|
||||
</head>
|
||||
|
||||
This section describes HPA management with `kubectl`. This document has instructions for how to:
|
||||
|
||||
- Create an HPA
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Managing HPAs with the Rancher UI
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/horizontal-pod-autoscaler/manage-hpas-with-ui"/>
|
||||
</head>
|
||||
|
||||
The Rancher UI supports creating, managing, and deleting HPAs. You can configure CPU or memory usage as the metric that the HPA uses to scale.
|
||||
|
||||
If you want to create HPAs that scale based on other metrics than CPU and memory, refer to [Configuring HPA to Scale Using Custom Metrics with Prometheus](./manage-hpas-with-kubectl.md#configuring-hpa-to-scale-using-custom-metrics-with-prometheus).
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Testing HPAs with kubectl
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/horizontal-pod-autoscaler/test-hpas-with-kubectl"/>
|
||||
</head>
|
||||
|
||||
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.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Kubernetes Registry and Docker Registry
|
||||
description: Learn about the Docker registry and Kubernetes registry, their use cases and how to use a private registry with the Rancher UI
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/kubernetes-and-docker-registries"/>
|
||||
</head>
|
||||
Registries are Kubernetes secrets containing credentials used to authenticate with [private Docker registries](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/).
|
||||
|
||||
The word "registry" can mean two things, depending on whether it is used to refer to a Docker or Kubernetes registry:
|
||||
|
||||
+4
@@ -3,6 +3,10 @@ title: Adding Ingresses
|
||||
description: Ingresses can be added for workloads to provide load balancing, SSL termination and host/path-based routing. Learn how to add Rancher ingress
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/add-ingresses"/>
|
||||
</head>
|
||||
|
||||
Ingresses can be added for workloads to provide load balancing, SSL termination and host/path based routing. When using ingresses in a project, you can program the ingress hostname to an external DNS by setting up a Global DNS entry.
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
|
||||
+4
@@ -3,6 +3,10 @@ title: Ingress Configuration
|
||||
description: Ingress configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/ingress-configuration"/>
|
||||
</head>
|
||||
|
||||
:::note
|
||||
|
||||
For Kubernetes v1.21 and up, the NGINX Ingress controller no longer runs in hostNetwork by default. It instead uses hostPorts for port 80 and port 443, so you can configure the admission webhook to be accessible only through the ClusterIP. This ensures that the webhook is only accessible from within the cluster.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: "Layer 4 and Layer 7 Load Balancing"
|
||||
description: "Kubernetes supports load balancing in two ways: Layer-4 Load Balancing and Layer-7 Load Balancing. Learn about the support for each way in different deployments"
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/layer-4-and-layer-7-load-balancing"/>
|
||||
</head>
|
||||
Kubernetes supports load balancing in two ways: Layer-4 Load Balancing and Layer-7 Load Balancing.
|
||||
|
||||
## Layer-4 Load Balancer
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Secrets
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/secrets"/>
|
||||
</head>
|
||||
|
||||
[Secrets](https://kubernetes.io/docs/concepts/configuration/secret/#overview-of-secrets) store sensitive data like passwords, tokens, or keys. They may contain one or more key value pairs.
|
||||
|
||||
:::note
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Adding a Sidecar
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/add-a-sidecar"/>
|
||||
</head>
|
||||
|
||||
A _sidecar_ is a container that extends or enhances the main container in a pod. The main container and the sidecar share a pod, and therefore share the same network space and storage. You can add sidecars to existing workloads by using the **Add a Sidecar** option.
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
|
||||
+4
@@ -3,6 +3,10 @@ title: Deploying Workloads
|
||||
description: Read this step by step guide for deploying workloads. Deploy a workload to run an application in one or more containers.
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/deploy-workloads"/>
|
||||
</head>
|
||||
|
||||
Deploy a workload to run an application in one or more containers.
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Rolling Back Workloads
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/roll-back-workloads"/>
|
||||
</head>
|
||||
|
||||
Sometimes there is a need to rollback to the previous version of the application, either for debugging purposes or because an upgrade did not go as planned.
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Upgrading Workloads
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/upgrade-workloads"/>
|
||||
</head>
|
||||
|
||||
When a new version of an application image is released on Docker Hub, you can upgrade any workloads running a previous version of the application to the new one.
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: ConfigMaps
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/configmaps"/>
|
||||
</head>
|
||||
|
||||
While most types of Kubernetes secrets store sensitive information, [ConfigMaps](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/) store general configuration information, such as a group of config files. Because ConfigMaps don't store sensitive information, they can be updated automatically, and therefore don't require their containers to be restarted following update (unlike most secret types, which require manual updates and a container restart to take effect).
|
||||
|
||||
ConfigMaps accept key value pairs in common string formats, like config files or JSON blobs. After you upload a config map, any workload can reference it as either an environment variable or a volume mount.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Services
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/create-services"/>
|
||||
</head>
|
||||
|
||||
Pod configuration is managed by Deployments, StatefulSets and Daemonsets, whereas services direct traffic to pods using selectors.
|
||||
|
||||
For every workload (with at least one port configured) created, a complementing Service Discovery entry is created. This Service Discovery entry enables DNS resolution for the workload's pods using the following naming convention:
|
||||
|
||||
+4
@@ -3,6 +3,10 @@ title: Encrypting HTTP Communication
|
||||
description: Learn how to add an SSL (Secure Sockets Layer) certificate or TLS (Transport Layer Security) certificate
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/encrypt-http-communication"/>
|
||||
</head>
|
||||
|
||||
When you create an ingress within Rancher/Kubernetes, you must provide it with a secret that includes a TLS private key and certificate, which are used to encrypt and decrypt communications that come through the ingress. You can make certificates available for ingress use by adding the certificate to the ingress deployment.
|
||||
|
||||
:::note Prerequisite:
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Background Information on HPAs
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/horizontal-pod-autoscaler/about-hpas"/>
|
||||
</head>
|
||||
|
||||
The [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) (HPA) is a Kubernetes feature that allows you to configure your cluster to automatically scale the services it's running up or down. This section provides explanation on how HPA works with Kubernetes.
|
||||
|
||||
## Why Use Horizontal Pod Autoscaler?
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Managing HPAs with kubectl
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/horizontal-pod-autoscaler/manage-hpas-with-kubectl"/>
|
||||
</head>
|
||||
|
||||
This section describes HPA management with `kubectl`. This document has instructions for how to:
|
||||
|
||||
- Create an HPA
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Managing HPAs with the Rancher UI
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/horizontal-pod-autoscaler/manage-hpas-with-ui"/>
|
||||
</head>
|
||||
|
||||
The Rancher UI supports creating, managing, and deleting HPAs. You can configure CPU or memory usage as the metric that the HPA uses to scale.
|
||||
|
||||
If you want to create HPAs that scale based on other metrics than CPU and memory, refer to [Configuring HPA to Scale Using Custom Metrics with Prometheus](./manage-hpas-with-kubectl.md#configuring-hpa-to-scale-using-custom-metrics-with-prometheus).
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Testing HPAs with kubectl
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/horizontal-pod-autoscaler/test-hpas-with-kubectl"/>
|
||||
</head>
|
||||
|
||||
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.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Kubernetes Registry and Container Image Registry
|
||||
description: Learn about the container image registry and Kubernetes registry, their use cases, and how to use a private registry with the Rancher UI
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/kubernetes-and-docker-registries"/>
|
||||
</head>
|
||||
Registries are Kubernetes secrets containing credentials used to authenticate with [private container registries](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/).
|
||||
|
||||
The word "registry" can mean two things, depending on whether it is used to refer to a container or Kubernetes registry:
|
||||
|
||||
+4
@@ -3,6 +3,10 @@ title: Adding Ingresses
|
||||
description: Ingresses can be added for workloads to provide load balancing, SSL termination and host/path-based routing. Learn how to add Rancher ingress
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/add-ingresses"/>
|
||||
</head>
|
||||
|
||||
Ingresses can be added for workloads to provide load balancing, SSL termination and host/path based routing. When using ingresses in a project, you can program the ingress hostname to an external DNS by setting up a Global DNS entry.
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
|
||||
+4
@@ -3,6 +3,10 @@ title: Ingress Configuration
|
||||
description: Ingress configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/ingress-configuration"/>
|
||||
</head>
|
||||
|
||||
:::note
|
||||
|
||||
For Kubernetes v1.21 and up, the NGINX Ingress controller no longer runs in hostNetwork by default. It instead uses hostPorts for port 80 and port 443, so you can configure the admission webhook to be accessible only through the ClusterIP. This ensures that the webhook is only accessible from within the cluster.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: "Layer 4 and Layer 7 Load Balancing"
|
||||
description: "Kubernetes supports load balancing in two ways: Layer-4 Load Balancing and Layer-7 Load Balancing. Learn about the support for each way in different deployments"
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/layer-4-and-layer-7-load-balancing"/>
|
||||
</head>
|
||||
Kubernetes supports load balancing in two ways: Layer-4 Load Balancing and Layer-7 Load Balancing.
|
||||
|
||||
## Layer-4 Load Balancer
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Secrets
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/secrets"/>
|
||||
</head>
|
||||
|
||||
[Secrets](https://kubernetes.io/docs/concepts/configuration/secret/#overview-of-secrets) store sensitive data like passwords, tokens, or keys. They may contain one or more key value pairs.
|
||||
|
||||
:::note
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Adding a Sidecar
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/add-a-sidecar"/>
|
||||
</head>
|
||||
|
||||
A _sidecar_ is a container that extends or enhances the main container in a pod. The main container and the sidecar share a pod, and therefore share the same network space and storage. You can add sidecars to existing workloads by using the **Add a Sidecar** option.
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
|
||||
+4
@@ -3,6 +3,10 @@ title: Deploying Workloads
|
||||
description: Read this step by step guide for deploying workloads. Deploy a workload to run an application in one or more containers.
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/deploy-workloads"/>
|
||||
</head>
|
||||
|
||||
Deploy a workload to run an application in one or more containers.
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Rolling Back Workloads
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/roll-back-workloads"/>
|
||||
</head>
|
||||
|
||||
Sometimes there is a need to rollback to the previous version of the application, either for debugging purposes or because an upgrade did not go as planned.
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Upgrading Workloads
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/upgrade-workloads"/>
|
||||
</head>
|
||||
|
||||
When a new version of an application image is released on Docker Hub, you can upgrade any workloads running a previous version of the application to the new one.
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
|
||||
Reference in New Issue
Block a user