Kubernetes guide
Originally designed by Google, Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications.
While Release dramatically simplifies operating Kubernetes for our users, it is important to have at least a basic understanding of some of its key concepts and terms as they relate to Release.
- Pod: One or more containers that run with shared storage and networking.
- Node: The cloud computing instances that run your Pods (for example, an AWS EC2 instance).
- Cluster: Manages Pods and related resources across a set of Nodes.
- Ingress: Routes HTTP and HTTPS traffic from outside the cluster to services within it.
Release manages the creation and administration of Kubernetes clusters within your cloud account. Configuration of your cluster, such as Node instance types, autoscaling of Nodes, Kubernetes version upgrades, and deployment of resources into your cluster, are all managed within the Release platform.
To ensure best performance and to keep your cloud costs in check, it’s important to size the Nodes within your Kubernetes cluster appropriately for the applications they’ll be running. This involves selecting a cloud instance type that fits the needs of your workloads.
Some factors to consider include:
- How much memory does your application need, under your expected usage?
- Does your application tend to be more memory- or CPU-bound?
- Does your application need access to high-performance local storage?
- How sensitive are the environments within this cluster to variance in performance?
- What are the minimum and maximum number of environments that will be running at a time?
Overlaying these considerations onto your budget will help you choose an appropriate instance type for your Nodes. This is also something that can and should be tuned as your needs or usage patterns change.
For more information on Node sizing, see the AWS EKS documentation. This third-party EC2 instance comparison tool may also be helpful, particularly with regards to pricing.
At a high level, there are two major categories of autoscaling to consider within a Kubernetes cluster:
- Node autoscaling
- Pod autoscaling
Release manages Node autoscaling on your behalf. If the Kubernetes cluster does not have sufficient resources available to run a workload, then new Nodes will be automatically provisioned and added to the cluster, up to a set maximum. Likewise, Nodes will be automatically terminated and removed from the cluster, down to a set minimum, as environments are removed.
You can set a comfortable minimum and maximum number of Nodes and adjust it over time.
Pod autoscaling is a little more complicated, because of the many application-specific factors that need to be taken into account. To give a few examples:
- How can we tell that the system is in a state that it needs more or fewer Pods?
- Which types of Pods do we need more or fewer of to respond to the changing load?
- How can we avoid overwhelming limited resources (for example, DB connections)?
Release can support most popular Pod autoscaling solutions that exist in the Kubernetes ecosystem, but they are configured at the Kubernetes layer and require additional effort and expertise to effectively integrate them into your application. If you’d like more information on Pod autoscaling, contact us.
Typically, Pod autoscaling is something that most end users will not worry about or even consider until they deploy to production environments. Some customers may also want to configure and test a production-like environment for performance testing and tuning. These are the most common use cases for Pod autoscaling.
Kubernetes provides capabilities to ensure that, when an application environment is created, its services are run on Nodes that have sufficient memory and CPU available. Kubernetes generally refers to this type of configuration as a resource request. It is also possible to monitor ongoing resource usage and restart Pods if they exceed the configured limit. Requests are can be thought of as a minimum set of guaranteed resources, while limits are can be thought of as the maximum advisable values.
Tuning resource requests and limits is key to efficiently managing your cluster’s resources and maintaining the stability and performance of your applications. Since resource configuration is heavily dependent on your application’s unique needs, this is something that should be carefully considered and adjusted over time. For more information on service resource tuning, refer to our documentation on managing service resources.
Last modified 3mo ago