Kubernetes Workloads and Pods
You can build any complex containerized application in Kubernetes using two basic constructs: pods and workloads. Once you build an application, you can expose it for access either within the same cluster or on the Internet using a third construct: services.
Pods
Pods are one or more containers that share network namespaces and storage volumes. Most pods have only one container. Therefore when we discuss pods, the term is often synonymous with containers. You scale pods the same way you scale containers—by having multiple instances of the same pod that implement a service. Usually pods get scaled and managed by the workload.
Workloads
Workloads are objects that set deployment rules for pods. Based on these rules, Kubernetes performs the deployment and updates the workload with the current state of the application. Workloads let you define the rules for application scheduling, scaling, and upgrade.
Workload Types
Kubernetes divides workloads into different types. The most popular types supported by Kubernetes are:
Deployments are best used for stateless applications (i.e., when you don't have to maintain the workload's state). Pods managed by deployment workloads are treated as independent and disposable. If a pod encounters disruption, Kubernetes removes it and then recreates it. An example application would be an Nginx web server.
StatefulSets, in contrast to deployments, are best used when your application needs to maintain its identity and store data. An application would be something like Zookeeper—an application that requires a database for storage.
Daemonsets ensures that every node in the cluster runs a copy of pod. For use cases where you're collecting logs or monitoring node performance, this daemon-like workload works best.
Jobs launch one or more pods and ensure that a specified number of them successfully terminate. Jobs are best used to run a finite task to completion as opposed to managing an ongoing desired application state.
CronJobs are similar to jobs. CronJobs, however, runs to completion on a cron-based schedule.
Services
In many use cases, a workload has to be either:
- Accessed by other workloads in the cluster.
- Exposed to the outside world.
You can achieve these goals by creating a Service. Services are mapped to the underlying workload's pods using a selector/label approach (view the code samples). Rancher UI simplifies this mapping process by automatically creating a service along with the workload, using the service port and type that you select.
Service Types
There are several types of services available in Rancher. The descriptions below are sourced from the Kubernetes Documentation.
ClusterIP
Exposes the service on a cluster-internal IP. Choosing this value makes the service only reachable from within the cluster. This is the default
ServiceType
.NodePort
Exposes the service on each Node’s IP at a static port (the
NodePort
). AClusterIP
service, to which theNodePort
service will route, is automatically created. You’ll be able to contact theNodePort
service, from outside the cluster, by requesting<NodeIP>:<NodePort>
.LoadBalancer
Exposes the service externally using a cloud provider’s load balancer.
NodePort
andClusterIP
services, to which the external load balancer will route, are automatically created.
Workload Options
This section of the documentation contains instructions for deploying workloads and using workload options.