Marty Hernandez Avedon
6ccd0b7b6c
* Syncing sidebar labels with page titles Deploying Rancher Server: Update sidebar label to match title * Installing/Upgrading Rancher: Update title to match sidebar This is a reference/hub page for install guides with no step-by-step instructions, so we're breaking the -ing rule to match other reference pages as well as the current sidebar label * Cluster Access: Update title to match sidebar * Kubernetes Persistent Storage: Volumes and Storage Classes - Update title to match sidebar * Don't have a Kubernetes cluster? Try one of these tutorials: Update title to match sidebar and make old title intro to page * Don't have infrastructure for your Kubernetes cluster? Try one of these tutorials: Update title to match sidebar and make old title intro to page * versioning Deploying Rancher Server update to other sidebars * Setting Up Kubernetes Clusters in Rancher: Update sidebars to match title and other sidebar labels * capitalization * Creating a vSphere Cluster: Update sidebar to match title and other labels * Creating a Nutanix AOS Cluster: Update sidebar to match title and other labels * Kubernetes Clusters in Rancher Setup across the board for title and sidebar, to match convention in sidebar * Kubernetes Resources: Updated title to match sidebar and distinguish from identically-titled page in troubleshooting section * The Horizontal Pod Autoscaler: Updated title to match sidebar * Backups and Disaster Recovery: Update title to match sidebar * typo fix * revert to Installation and Upgrade of Rancher fix typo in title: Create Kubernetes Persistent files * fix typo in Persistent Storage files * Configuration: Update title to match sidebar item Monitoring V2 Configuration Guides * Setup Guide: Make both sidebar + title Istio Setup guides to match other sidebar labels * Best Practices: Update both to Best Practice Guides * Architecture: Update to match sidebar Rancher Architecture. Note that there are multiple pages with identical titles, one is on Fleet and another on some other subject * Architecture: Retitle logging-architecture.md files Logging Architecture * Architecture: Retitle fleet/architecture.md files Fleet Architecture * GKE Cluster Configuration: Update sidebar to match title and other labels in same section * Security: Update both to Rancher Security Guides * RKE Hardening Guide: Update to match sidebar * typo * RKE2 Hardening Guide: Update to match sidebar * K3s Hardening Guide: Update to match sidebar * various FAQ pages: Add FAQ to title to disambiguate content * Cloud Native Storage with Longhorn: Versioning so older pages match current title * rm international pages for now * typo in metadata killed build * updated sidebar: plural Istio Setup Guides * updating Monitoring Config Guides title/label and distinguishing from similar section under References * monitoring V2 config examples: rm 'V2' * Kubernetes Cluster Setup > Setting up a Kubernetes Cluster for Rancher Server
4.5 KiB
title
| title |
|---|
| Kubernetes Resources Setup |
You can view and manipulate all of the custom resources and CRDs in a Kubernetes cluster from the Rancher UI.
Workloads
Deploy applications to your cluster nodes using workloads, which are objects that contain pods that run your apps, along with metadata that set rules for the deployment's behavior. Workloads can be deployed within the scope of the entire clusters or within a namespace.
When deploying a workload, you can deploy from any image. There are a variety of workload types to choose from which determine how your application should run.
Following a workload deployment, you can continue working with it. You can:
- Upgrade the workload to a newer version of the application it's running.
- Roll back a workload to a previous version, if an issue occurs during upgrade.
- Add a sidecar, which is a workload that supports a primary workload.
Load Balancing and Ingress
Load Balancers
After you launch an application, it's only available within the cluster. It can't be reached externally.
If you want your applications to be externally accessible, you must add a load balancer to your cluster. Load balancers create a gateway for external connections to access your cluster, provided that the user knows the load balancer's IP address and the application's port number.
Rancher supports two types of load balancers:
For more information, see load balancers.
Ingress
Load Balancers can only handle one IP address per service, which means if you run multiple services in your cluster, you must have a load balancer for each service. Running multiples load balancers can be expensive. You can get around this issue by using an ingress.
Ingress is a set of rules that act as a load balancer. Ingress works in conjunction with one or more ingress controllers to dynamically route service requests. When the ingress receives a request, the ingress controller(s) in your cluster program the load balancer to direct the request to the correct service based on service subdomains or path rules that you've configured.
For more information, see Ingress.
When using ingresses in a project, you can program the ingress hostname to an external DNS by setting up a Global DNS entry.
Service Discovery
After you expose your cluster to external requests using a load balancer and/or ingress, it's only available by IP address. To create a resolveable hostname, you must create a service record, which is a record that maps an IP address, external hostname, DNS record alias, workload(s), or labelled pods to a specific hostname.
For more information, see Service Discovery.
Applications
Besides launching individual components of an application, you can use the Rancher catalog to start launching applications, which are Helm charts.
Kubernetes Resources
Within the context of a Rancher project or namespace, resources are files and data that support operation of your pods. Within Rancher, certificates, registries, and secrets are all considered resources. However, Kubernetes classifies resources as different types of secrets. Therefore, within a single project or namespace, individual resources must have unique names to avoid conflicts. Although resources are primarily used to carry sensitive information, they have other uses as well.
Resources include:
- Certificates: Files used to encrypt/decrypt data entering or leaving the cluster.
- ConfigMaps: Files that store general configuration information, such as a group of config files.
- Secrets: Files that store sensitive data like passwords, tokens, or keys.
- Registries: Files that carry credentials used to authenticate with private registries.