Re-add missing diagrams

2026-09-24 20:18:18 +00:00 · 2019-10-15 08:29:36 -07:00
parent e0ebe84dcd
commit 59c5e85a43
59 changed files with 136 additions and 0 deletions
@@ -7,6 +7,10 @@ Service discovery is one of the core functionalities of any container-based envi

 This document will also show you how to link the workloads and services that you migrated into Rancher v2.x. When you parsed your services from v1.6 using migration-tools CLI, it output two files for each service: one deployment manifest and one service manifest. You'll have to link these two files together before the deployment works correctly in v2.x.

+<figcaption>Resolve the <code>output.txt</code> Link Directive</figcaption>
+
+![Resolve Link Directive]({{< baseurl >}}/img/rancher/resolve-links.png)
+
 ## In This Document

 <!-- TOC -->
@@ -58,6 +62,11 @@ When you migrate v1.6 services to v2.x, Rancher does not automatically create a

 In the image below, the `web-deployment.yml` and `web-service.yml` files [created after parsing]({{< baseurl >}}/rancher/v2.x/en/v1.6-migration/run-migration-tool/#migration-example-file-output) our [migration example services]({{< baseurl >}}/rancher/v2.x/en/v1.6-migration/#migration-example-files) are linked together.

+<figcaption>Linked Workload and Kubernetes Service</figcaption>
+
+![Linked Workload and Kubernetes Service]({{< baseurl >}}/img/rancher/linked-service-workload.png)
+
+
 ### Service Name Alias Creation

 Just as you can create an alias for Rancher v1.6 services, you can do the same for Rancher v2.x workloads. Similarly, you can also create DNS records pointing to services running externally, using either their hostname or IP address. These DNS records are Kubernetes service objects.
@@ -66,6 +75,9 @@ Using the v2.x UI, use the context menu to navigate to the `Project` view. Then

 Click **Add Record** to create new DNS records. Then view the various options supported to link to external services or to create aliases for another workload, DNS record, or set of pods.

+<figcaption>Add Service Discovery Record</figcaption>
+![Add Service Discovery Record]({{< baseurl >}}/img/rancher/add-record.png)
+
 The following table indicates which alias options are implemented natively by Kubernetes and which options are implemented by Rancher leveraging Kubernetes.

 Option | Kubernetes-implemented? | Rancher-implemented?
@@ -40,6 +40,10 @@ After provisioning your node(s), install Rancher:

 After your Rancher v2.x Server is installed, we recommend configuring external authentication (like Active Directory or GitHub) so that users can log into Rancher using their single sign-on. For a full list of supported authentication providers and instructions on how to configure them, see [Authentication]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication).

+<figcaption>Rancher v2.x Authentication</figcaption>
+
+![Rancher v2.x Authentication]({{< baseurl >}}/img/rancher/auth-providers.svg)
+
 ### Local Users

 Although we recommend using an external authentication provider, Rancher v1.6 and v2.x both offer support for users local to Rancher. However, these users cannot be migrated from Rancher v1.6 to v2.x. If you used local users in Rancher v1.6 and want to continue this practice in v2.x, you'll need to [manually recreate these user accounts]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/) and assign them access rights.
@@ -9,6 +9,10 @@ As outlined in [its documentation]({{< baseurl >}}/rancher/v1.6/en/cattle/adding

 If you encounter the `output.txt` text below after parsing your v1.6 Compose files to Kubernetes manifests, you'll have to resolve it by manually creating a load balancer in v2.x.

+<figcaption><code>output.txt</code> Load Balancer Directive</figcaption>
+
+![Resolve Load Balancer Directive]({{< baseurl >}}/img/rancher/resolve-load-balancer.png)
+
 ## In This Document

 <!-- TOC -->
@@ -49,8 +53,16 @@ In Rancher v1.6 you could deploy a scalable load balancer service within your st

 <!-- add comparison table-->

+<figcaption>Rancher v1.6 Load Balancing Architecture</figcaption>
+
+![Rancher v1.6 Load Balancing]({{< baseurl >}}/img/rancher/cattle-load-balancer.svg)
+
 The Rancher v2.x Ingress Controller is a DaemonSet, it is globally deployed on all schedulable nodes to serve your entire Kubernetes Cluster. Therefore, when you program the Ingress rules, you must use a unique hostname and path to point to your workloads, as the load balancer node IP addresses and ports 80 and 443 are common access points for all workloads.

+<figcaption>Rancher v2.x Load Balancing Architecture</figcaption>
+
+![Rancher v2.x Load Balancing]({{< baseurl >}}/img/rancher/kubernetes-load-balancer.svg)
+
 ## Ingress Caveats

 Although Rancher v2.x supports HTTP and HTTPS hostname and path-based load balancing, you must use unique host names and paths when configuring your workloads. This limitation derives from:
@@ -67,8 +79,14 @@ You can launch a new load balancer to replace your load balancer from v1.6. Usin
 >**Prerequisite:** Before deploying Ingress, you must have a workload deployed that's running a scale of two or more pods.
 >

+![Workload Scale]({{< baseurl >}}/img/rancher/workload-scale.png)
+
 For balancing between these two pods, you must create a Kubernetes Ingress rule. To create this rule, navigate to your cluster and project, and click **Resources > Workloads > Load Balancing.** (In versions prior to v2.3.0, click **Workloads > Load Balancing.**) Then click **Add Ingress**. This GIF below depicts how to add Ingress to one of your projects.

+<figcaption>Browsing to Load Balancer Tab and Adding Ingress</figcaption>
+
+![Adding Ingress]({{< baseurl >}}/img/rancher/add-ingress.gif)
+
 Similar to a service/port rules in Rancher v1.6, here you can specify rules targeting your workload's container port. The sections below demonstrate how to create Ingress rules.

 ### Configuring Host- and Path-Based Routing
@@ -77,8 +95,16 @@ Using Rancher v2.x, you can add Ingress rules that are based on host names or a

 For example, let's say you have multiple workloads deployed to a single namespace. You can add an Ingress to route traffic to these two workloads using the same hostname but different paths, as depicted in the image below. URL requests to `foo.com/name.html` will direct users to the `web` workload, and URL requests to `foo.com/login` will direct users to the `chat` workload.

+<figcaption>Ingress: Path-Based Routing Configuration</figcaption>
+
+![Ingress: Path-Based Routing Configuration]({{< baseurl >}}/img/rancher/add-ingress-form.png)
+
 Rancher v2.x also places a convenient link to the workloads on the Ingress record. If you configure an external DNS to program the DNS records, this hostname can be mapped to the Kubernetes Ingress address.

+<figcaption>Workload Links</figcaption>
+
+![Load Balancer Links to Workloads]({{< baseurl >}}/img/rancher/load-balancer-links.png)
+
 The Ingress address is the IP address in your cluster that the Ingress Controller allocates for your workload. You can reach your workload by browsing to this IP address. Use `kubectl` command below to see the Ingress address assigned by the controller:

 ```
@@ -92,6 +118,10 @@ Rancher v2.x Ingress functionality supports the HTTPS protocol, but if you want
 - We recommend [uploading a certificate]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/certificates/) from a known certificate authority (you'll have to do this before configuring Ingress). Then, while configuring your load balancer, use the **Choose a certificate** option and select the uploaded certificate that you want to use.
 - If you have configured [NGINX default certificate]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/#configuring-an-nginx-default-certificate), you can select **Use default ingress controller certificate**.

+<figcaption>Load Balancer Configuration: SSL/TLS Certificate Section</figcaption>
+
+![SSL/TLS Certificates Section]({{< baseurl >}}/img/rancher/load-balancer-ssl-certs.png)
+
 ### TCP Load Balancing Options

 #### Layer-4 Load Balancer
@@ -100,6 +130,10 @@ For the TCP protocol, Rancher v2.x supports configuring a Layer 4 load balancer

 For example, if we create a deployment named `myapp` and specify a Layer 4 load balancer in the **Port Mapping** section, Rancher will automatically add an entry to the **Load Balancer** tab named `myapp-loadbalancer`.

+<figcaption>Workload Deployment: Layer 4 Load Balancer Creation</figcaption>
+
+![Deploy Layer-4 Load Balancer]({{< baseurl >}}/img/rancher/deploy-workload-load-balancer.png)
+
 Once configuration of the load balancer succeeds, the Rancher UI provides a link to your workload's public endpoint.

 #### NGINX Ingress Controller TCP Support by ConfigMaps
@@ -110,6 +144,8 @@ However, there is a workaround to use NGINX's TCP balancing by creating a Kubern

 To configure NGINX to expose your services via TCP, you can add the ConfigMap `tcp-services` that should exist in the `ingress-nginx` namespace. This namespace also contains the NGINX Ingress Controller pods.

+![Layer-4 Load Balancer: ConfigMap Workaround]({{< baseurl >}}/img/rancher/layer-4-lb-config-map.png)
+
 The key in the ConfigMap entry should be the TCP port that you want to expose for public access: `<namespace/service name>:<service port>`. As shown above, two workloads are listed in the `Default` namespace. For example, the first entry in the ConfigMap above instructs NGINX to expose the `myapp` workload (the one in the `default` namespace that's listening on private port 80) over external port `6790`. Adding these entries to the ConfigMap automatically updates the NGINX pods to configure these workloads for TCP balancing. The workloads exposed should be available at `<NodeIP>:<TCP Port>`. If they are not accessible, you might have to expose the TCP port explicitly using a NodePort service.

 ## Rancher v2.x Load Balancing Limitations
@@ -11,6 +11,10 @@ Use this document to correct Rancher v2.x workloads and services that list `heal

 For example, for the image below, we would configure liveness probes for the `web` and `weblb` workloads (i.e., the Kubernetes manifests output by migration-tools CLI).

+<figcaption>Resolve <code>health_check</code> for the <code>web</code> and <code>webLB</code> Workloads</figcaption>
+
+![Resolve health_check]({{< baseurl >}}/img/rancher/resolve-health-checks.png)
+
 ## In This Document

 <!-- TOC -->
@@ -37,6 +41,8 @@ The health check microservice features two types of health checks, which have a

 The following diagram displays the health check microservice evaluating a container running Nginx. Notice that the microservice is making its check across nodes.

+![Rancher v1.6 Health Checks]({{<baseurl>}}/img/rancher/healthcheck.svg)
+
 ## Rancher v2.x Health Checks

 In Rancher v2.x, the health check microservice is replaced with Kubernete's native health check mechanisms, called _probes_. These probes, similar to the Rancher v1.6 health check microservice, monitor the health of pods over TCP and HTTP.
@@ -63,6 +69,8 @@ Kubernetes includes two different _types_ of probes: liveness checks and readine

 The following diagram displays kubelets running probes on containers they are monitoring ([kubelets](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) are the primary "agent" running on each node). The node on the left is running a liveness probe, while the one of the right is running a readiness check. Notice that the kubelet is scanning containers on its host node rather than across nodes, as in Rancher v1.6.

+![Rancher v2.x Probes]({{<baseurl>}}/img/rancher/probes.svg)
+
 ## Configuring Probes in Rancher v2.x

 The [migration-tool CLI]({{< baseurl >}}/rancher/v2.x/en/v1.6-migration/run-migration-tool/) cannot parse health checks from Compose files to Kubernetes manifest. Therefore, if want you to add health checks to your Rancher v2.x workloads, you'll have to add them manually.
@@ -73,6 +81,10 @@ If the probe fails, the container is restarted per the restartPolicy defined in

 Configure probes by using the **Health Check** section while editing deployments called out in `output.txt`.

+<figcaption>Edit Deployment: Health Check Section</figcaption>
+
+![Health Check Section]({{< baseurl >}}/img/rancher/health-check-section.png)
+
 ### Configuring Checks

 While you create a workload using Rancher v2.x, we recommend configuring a check that monitors the health of the deployment's pods.
@@ -85,6 +97,8 @@ TCP checks monitor your deployment's health by attempting to open a connection t

 You can configure the probe along with values for specifying its behavior by selecting the **TCP connection opens successfully** option in the **Health Check** section. For more information, see [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/). For help setting probe timeout and threshold values, see [Health Check Parameter Mappings](#health-check-parameter-mappings).

+![TCP Check]({{<baseurl>}}/img/rancher/readiness-check-tcp.png)
+
 When you configure a readiness check using Rancher v2.x, the `readinessProbe` directive and the values you've set are added to the deployment's Kubernetes manifest. Configuring a readiness check also automatically adds a liveness check (`livenessProbe`) to the deployment.

 <!--
@@ -121,6 +135,8 @@ HTTP checks monitor your deployment's health by sending an HTTP GET request to a

 You can configure the probe along with values for specifying its behavior by selecting the **HTTP returns successful status** or **HTTPS returns successful status**. For more information, see [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/).  For help setting probe timeout and threshold values, see [Health Check Parameter Mappings](#healthcheck-parameter-mappings).

+![HTTP Check]({{<baseurl>}}/img/rancher/readiness-check-http.png)
+
 When you configure a readiness check using Rancher v2.x, the `readinessProbe` directive and the values you've set are added to the deployment's Kubernetes manifest. Configuring a readiness check also automatically adds a liveness check (`livenessProbe`) to the deployment.

 {{% /tab %}}
@@ -131,12 +147,16 @@ When you configure a readiness check using Rancher v2.x, the `readinessProbe` di

 While configuring a readiness check for either the TCP or HTTP protocol, you can configure a separate liveness check by clicking the **Define a separate liveness check**. For help setting probe timeout and threshold values, see [Health Check Parameter Mappings](#health-check-parameter-mappings).

+![Separate Liveness Check]({{<baseurl>}}/img/rancher/separate-check.png)
+
 ### Additional Probing Options

 Rancher v2.x, like v1.6, lets you perform health checks using the TCP and HTTP protocols. However, Rancher v2.x also lets you check the health of a pod by running a command inside of it. If the container exits with a code of `0` after running the command, the pod is considered healthy.

 You can configure a liveness or readiness check that executes a command that you specify by selecting the `Command run inside the container exits with status 0` option from **Health Checks** while [deploying a workload]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/).

+![Healthcheck Execute Command]({{<baseurl>}}/img/rancher/healthcheck-cmd-exec.png)
+
 #### Health Check Parameter Mappings

 While configuring readiness checks and liveness checks, Rancher prompts you to fill in various timeout and threshold values that determine whether the probe is a success or failure. The reference table below shows you the equivalent health check values from Rancher v1.6.
@@ -242,6 +242,10 @@ You can deploy the Kubernetes manifests created by migration-tools by importing
 >
 >Delete the YAML directive listed in the error message. These are YAML directives from your v1.6 services that Kubernetes can't read.

+<figcaption>Deploy Services: Import Kubernetes Manifest</figcaption>
+
+![Deploy Services]({{< baseurl >}}/img/rancher/deploy-service.gif)
+
 {{% /tab %}}
 {{% tab "Rancher CLI" %}}

@@ -261,14 +265,26 @@ Use the following Rancher CLI commands to deploy your application using Rancher

 Following importation, you can view your v1.6 services in the v2.x UI as Kubernetes manifests by using the context menu to select `<CLUSTER> > <PROJECT>` that contains your services. The imported manifests will display on the **Resources > Workloads** and on the tab at **Resources > Workloads > Service Discovery.** (In Rancher v2.x prior to v2.3.0, these are on the **Workloads** and **Service Discovery** tabs in the top navigation bar.)

+<figcaption>Imported Services</figcaption>
+
+![Imported Services]({{< baseurl >}}/img/rancher/imported-workloads.png)
+
 ## What Now?

 Although the migration-tool CLI parses your Rancher v1.6 Compose files to Kubernetes manifests, there are discrepancies between v1.6 and v2.x that you must address by manually editing your parsed [Kubernetes manifests](#output). In other words, you need to edit each workload and service imported into Rancher v2.x, as displayed below.

+<figcaption>Edit Migrated Services</figcaption>
+
+![Edit Migrated Workload]({{< baseurl >}}/img/rancher/edit-migration-workload.gif)
+
 As mentioned in [Migration Tools CLI Output](#migration-tools-cli-output), the `output.txt` files generated during parsing lists the manual steps you must make for each deployment. Review the upcoming topics for more information on manually editing your Kubernetes specs.

 Open your `output.txt` file and take a look at its contents. When you parsed your Compose files into Kubernetes manifests, migration-tools CLI output a manifest for each workload that it creates for Kubernetes. For example, our when our [Migration Example Files]({{< baseurl >}}/rancher/v2.x/en/v1.6-migration/#migration-example-files) are parsed into Kubernetes manifests, `output.txt` lists each resultant parsed [Kubernetes manifest file](#migration-example-file-output) (i.e., workloads). Each workload features a list of action items to restore operations for the workload in v2.x.

+<figcaption>Output.txt Example</figcaption>
+
+![output.txt]({{< baseurl >}}/img/rancher/output-dot-text.png)
+
 The following table lists possible directives that may appear in `output.txt`, what they mean, and links on how to resolve them.

 Directive | Instructions
@@ -13,6 +13,7 @@ You can schedule your migrated v1.6 services while editing a deployment. Schedul

 <figcaption>Editing Workloads: Workload Type and Node Scheduling Sections</figcaption>

+![Workload Type and Node Scheduling Sections]({{< baseurl >}}/img/rancher/migrate-schedule-workloads.png)

 ## In This Document

@@ -38,6 +39,7 @@ Rancher v2.x retains _all_ methods available in v1.6 for scheduling your service

 In v1.6, you would schedule a service to a host while adding a service to a Stack. In Rancher v2.x., the equivalent action is to schedule a workload for deployment. The following composite image shows a comparison of the UI used for scheduling in Rancher v2.x versus v1.6.

+![Node Scheduling: Rancher v2.x vs v1.6]({{< baseurl >}}/img/rancher/node-scheduling.png)

 ## Node Scheduling Options

@@ -62,8 +64,14 @@ Option | v1.6 Feature | v2.x Feature

 In v1.6, you could control the number of container replicas deployed for a service. You can schedule pods the same way in v2.x, but you'll have to set the scale manually while editing a workload.

+![Resolve Scale]({{< baseurl >}}/img/rancher/resolve-scale.png)
+
 During migration, you can resolve `scale` entries in `output.txt` by setting a value for the **Workload Type** option **Scalable deployment** depicted below.

+<figcaption>Scalable Deployment Option</figcaption>
+
+![Workload Scale]({{< baseurl >}}/img/rancher/workload-type-option.png)
+
 ### Scheduling Pods to a Specific Node

 Just as you could schedule containers to a single host in Rancher v1.6, you can schedule pods to single node in Rancher v2.x
@@ -71,12 +79,18 @@ Just as you could schedule containers to a single host in Rancher v1.6, you can
 As you deploy a workload, use the **Node Scheduling** section to choose a node to run your pods on. The workload below is being scheduled to deploy an Nginx image with a scale of two pods on a specific node.
 <!-- Question: What would be a good use case for use of a scheduling pods on the same node?-->

+<figcaption>Rancher v2.x: Workload Deployment</figcaption>
+
+![Workload Tab and Group by Node Icon]({{< baseurl >}}/img/rancher/schedule-specific-node.png)
+
 Rancher schedules pods to the node you select if 1) there are compute resource available for the node and 2) you've configured port mapping to use the HostPort option, that there are no port conflicts.

 If you expose the workload using a NodePort that conflicts with another workload, the deployment gets created successfully, but no NodePort service is created. Therefore, the workload isn't exposed outside of the cluster.

 After the workload is created, you can confirm that the pods are scheduled to your chosen node. From the project view, click **Resources > Workloads.** (In versions prior to v2.3.0, click the **Workloads** tab.) Click the **Group by Node** icon to sort your workloads by node. Note that both Nginx pods are scheduled to the same node.

+![Pods Scheduled to Same Node]({{< baseurl >}}/img/rancher/scheduled-nodes.png)
+
 <!--

 If you export the workload's manifest for Rancher v2.x, you can see in the pod spec that the workload is scheduled to the node that you selected (`nodeName: mark-do1`).
@@ -141,6 +155,10 @@ To apply labels to pods, make additions to the **Labels and Annotations** sectio

 Some of the most-used scheduling features in v1.6 were affinity and anti-affinity rules.

+<figcaption><code>output.txt</code> Affinity Label</figcaption>
+
+![Affinity Label]({{< baseurl >}}/img/rancher/resolve-affinity.png)
+
 - **Affinity**

    Any pods that share the same label are scheduled to the same node. Affinity can be configured in one of two ways:
@@ -152,6 +170,9 @@ Some of the most-used scheduling features in v1.6 were affinity and anti-affinit

    <br/>

+<figcaption>Affinity Rules: Hard and Soft</figcaption>
+
+    ![Affinity Rules]({{< baseurl >}}/img/rancher/node-scheduling-affinity.png)

 - **AntiAffinity**

@@ -161,7 +182,9 @@ Some of the most-used scheduling features in v1.6 were affinity and anti-affinit

    For anti-affinity rules, we recommend using labels with phrases like `NotIn` and `DoesNotExist`, as these terms are more intuitive when users are applying anti-affinity rules.

+    <figcaption>AntiAffinity Operators</figcaption>

+    ![AntiAffinity ]({{< baseurl >}}/img/rancher/node-schedule-antiaffinity.png)

 Detailed documentation for affinity/anti-affinity is available in the [Kubernetes Documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity).

@@ -174,6 +197,9 @@ In Rancher v1.6 setups, you could prevent services from being scheduled to speci

 In Rancher v2.x, you can prevent pods from being scheduled to specific nodes by applying _taints_ to a node. Pods will not be scheduled to a tainted node unless it has special permission, called a _toleration_. A toleration is a special label that allows a pod to be deployed to a tainted node. While editing a workload, you can apply tolerations using the **Node Scheduling** section. Click **Show advanced options**.

+<figcaption>Applying Tolerations</figcaption>
+
+![Tolerations]({{< baseurl >}}/img/rancher/node-schedule-advanced-options.png)

 For more information, see the Kubernetes documentation on [taints and tolerations](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/).

@@ -181,10 +207,18 @@ For more information, see the Kubernetes documentation on [taints and toleration

 Rancher v1.6 included the ability to deploy [global services]({{< baseurl >}}/rancher/v1.6/en/cattle/scheduling/#global-service), which are services that deploy duplicate containers to each host in the environment (i.e.,  nodes in your cluster using Rancher v2.x terms). If a service has the `io.rancher.scheduler.global: 'true'` label declared, then Rancher v1.6 schedules a service container on each host in the environment.

+<figcaption><code>output.txt</code> Global Service Label</figcaption>
+
+![Global Service Label]({{< baseurl >}}/img/rancher/resolve-global.png)
+
 In Rancher v2.x, you can schedule a pod to each node using a [Kubernetes DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/), which is a specific type of workload <!-- link -->). A _DaemonSet_ functions exactly like a Rancher v1.6 global service. The Kubernetes scheduler deploys a pod on each node of the cluster, and as new nodes are added, the scheduler will start new pods on them provided they match the scheduling requirements of the workload. Additionally, in v2.x, you can also limit a DaemonSet to be deployed to nodes that have a specific label.

 To create a daemonset while configuring a workload, choose **Run one pod on each node** from the **Workload Type** options.

+<figcaption>Workload Configuration: Choose run one pod on each node to configure daemonset</figcaption>
+
+![choose Run one pod on each node]({{< baseurl >}}/img/rancher/workload-type.png)
+
 ### Scheduling Pods Using Resource Constraints

 While creating a service in the Rancher v1.6 UI, you could schedule its containers to hosts based on hardware requirements that you choose. The containers are then scheduled to hosts based on which ones have bandwidth, memory, and CPU capacity.
@@ -204,6 +238,10 @@ To declare resource constraints, edit your migrated workloads, editing the **Sec
    - Memory Limit
    - CPU Limit

+<figcaption>Scheduling: Resource Constraint Settings</figcaption>
+
+![Resource Constraint Settings]({{< baseurl >}}/img/rancher/resource-constraint-settings.png)
+
 You can find more detail about these specs and how to use them in the [Kubernetes Documentation](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container).

 ### [Next: Service Discovery]({{< baseurl >}}/rancher/v2.x/en/v1.6-migration/discover-services/)