public/rancher-docs
1
0
Fork 0
mirror of https://github.com/rancher/rancher-docs.git synced 2026-09-25 04:28:15 +00:00
Code Issues Packages Projects Releases Wiki Activity

workload and service concept

Browse Source
This commit is contained in:
Mark Bishop
2018-06-18 20:23:35 -07:00
committed by Mark Bishop
parent 6e811a6d02
commit c74718183a
1 changed files with 36 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/rancher/v2.x/en/concepts/workloads/_index.md
+36 -24
View File
@@ -3,50 +3,62 @@ title: Workloads
weight: 2175
draft: true
---
You can build any complex containerized application in Kubernetes using two basic constructs: pods and workloads. Once application is built, it can be exposed for access either within the same cluster, or to the outside, using third construct - a service.
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
A [_pod_](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/) is 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.
[_Pods_](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/) 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
Workload is the entity that describes deployment rules for Kubernetes pods. Based on these rules, underlying Kubernetes controller will do the actual deployment, and update the workload object with the current application state.
Workload lets define the rules for application scheduling, scaling and upgrade.
_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 lets you define the rules for application scheduling, scaling, and upgrade.
Here are the most popular workload types supported by Kubernetes:
#### Workload Types
Kubernetes divides workloads into different types. The most popular types supported by Kubernetes are:
- [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)
_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](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)
_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](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)
_Daemonsets_ ensures that every node in the cluster runs a copy of pod. For use cases where where you're collecting logs or monitoring node performance, this daemon-like workload works best.
- [Jobs](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/)
_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](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/)
_CronJobs_ are similar to jobs. CronJobs, however, runs to completion on a cron-based schedule.
Choose **Deployment** when your application is stateless, meaning you don't have to keep the state in your workload. Pods managed by this workload, are treated as independent and disposable - if one pod goes bad, it will be removed and recreated. Example of deployment application would be an nginx webserver.
### Services
And the opposite, go with the **StatefulSet** when your application needs to store the data, where an every pod has a sticky identity. Distributed stateful workload like Zookeeper, and database application like mysql would make a perfect candidate for a statefulset.
In many use cases, a workload has to be either:
A **Daemonset** workload ensures that every node in the cluster would get a copy of the pod. For use cases where you have to do log collecting or node performance monitoring, this daemon-like workload is what works the best.
- 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)](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#service-and-replicationcontroller). Rancher UI simplifies this mapping process by automatically creating a service along with the workload, using the service port and type that you select.
Sometimes you need to run a finite task to completion as opposed to managing an ongoing desired application state. You can do it with **Job** workload, which will launch one or more pods and ensure that a specified number of them successfully terminate.
#### Service Types
**CronJob** is similar to job, only it runs to completion on a cron job based schedule.
There are several types of services available in Rancher. The descriptions below are sourced from the [Kubernetes Documentation](https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types).
- **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`.
## Services
- **NodePort**
In many cases, workload has to be accessed by other workloads in the cluster, or be exposed to the outside world. The most popular way to achieve that in Kubernetes is by creating a separate object called *Service*. Service gets mapped to the underlying workload's pods using [selector/label approach](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#service-and-replicationcontroller). Rancher UI simplifies it by automatically creating a service along with the workload, using service port and type specified by the user.
>Exposes the service on each Node’s IP at a static port (the `NodePort`). A `ClusterIP` service, to which the `NodePort` service will route, is automatically created. You’ll be able to contact the `NodePort` service, from outside the cluster, by requesting `<NodeIP>:<NodePort>`.
There are several types of services:
- **LoadBalancer**
* [ClusterIP](https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service)
* [NodePort](https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport)
* [LoadBalancer](https://kubernetes.io/docs/concepts/services-networking/service/#type-loadbalancer)
**ClusterIP** service enabled internal access to the application by programming clusterIP that proxies traffic to the underlying pods.
If the application needs to be accessed from the outside, it needs its port to be published on Kubernetes node. **NodePort** service is the most easy way to achieve that. Enabling NodePort service access for the workload, results in the port from 30000–32767 (configurable) range to be published on every node in Kubernetes cluster.
**LoadBalancer** service is another way to expose the service to the internet. It has to be backed up by Cloud Provider Load Balancer, so option is available on Kubernetes clusters like GKE, EKS, AKS and EC2 (with CloudProvider option explicitly set to Amazon in Rancher UI).
>Exposes the service externally using a cloud provider’s load balancer. `NodePort` and `ClusterIP` services, to which the external load balancer will route, are automatically created.