According to a 2020 international survey from the Cloud Native Computing Foundation (CNCF), the use of containers and Kubernetes in production has increased to 92% and 83%, respectively, in accordance to respondents that participated in the survey.
As the use of containers and Kubernetes in production becomes mainstream, organisations are looking for guardrails to put in place earlier than going live to ensure such environments are dependable and that they follow governance, compliance and security first-rate practices.
To reap the benefits of containers and avoid ending up in a chaotic situation, companies must carefully layout and prepare before going live. Eventually, as you build more environments and migrate applications, this is going to become simpler and will eventually be a non-event.
Production readiness is a methodical process that takes time and offers predictable structure and consistency to your work. Throughout this process, you want to interact your teams to work together and align the commercial enterprise and technical goals of the platform.
While each organization’s street to production is different, there are common key areas to center of attention on including the platform itself, resource management, operations, safety and governance.
The Platform
Kubernetes is the central component of the platform, but it’s now not everything. Integrated components such as storage and container runtime or systems such as CI/CD are additionally crucial. Taking a product mindset helps to iterate through the extraordinary features of the platform instead of focusing on a one-time effort.
- Regardless of whether or not
- you’re using a managed service on a public cloud
- or constructing your own cluster,
- the platform should be constructed for resiliency and to protect against failure from the outset.
One way to enhance the resiliency of the platform is to formulate and implement an effective catastrophe recovery plan (DRP). An advantageous DRP is paramount to be able to restore the platform shortly in case of an outage and maintain any service stage agreements (SLAs) in place for the platform or any mission-critical applications.
Another important issue to consider is sizing the cluster properly. You want to cautiously consider the types of workloads predicted (stateful versus stateless, high-performance versus general-purpose, etc.), the number of containers and average every day requests to the Kubernetes API server. It’s better to start with a small range of worker nodes and scale up or out later. To Read More: Kubernetes security best practices
Resource Management
Divide and conquer your workloads by using placing them in separate namespaces. This has many benefits. First, it makes access manipulate much easier due to the fact you can isolate workloads for different teams, projects or environments and assign permissions for this reason using role-based access manipulate (RBAC).
Second,
- you will be able to assign resources
- at the namespace stage which can
- be controlled later on using a policy.
Going stay with the default parameters in Kubernetes might lead to unknown situations. You want to make certain to use limits for almost everything together with but not constrained to number of requests handled with the aid of the API server, number of pods on a worker node and the top or lower bounds for pods memory and CPU usage. By default, there are no limits on person pods; this means a pod can consume all the assets on any worker node it’s scheduled to run on.
You choose to make sure to monitor the overall performance of the underlying infrastructure of the platform to better understand your utilization patterns over time and scale up or out accordingly.
Operations
Using health checks (readiness and liveness probes) in your software manifests as well as affinity rules to unfold pods across data facilities or availability zones can increase the overall reliability and availability of your applications.
It’s really useful to use deployments instead of individual pod manifests. This is to make sure applications can survive platform restarts or disasters and to easily manage software rollouts in the future.
Ops teams should have an operations playbook that defines the roles and obligations of each member of the team. This will help to swiftly triage and resolve issues.
Automation goes hand-in-hand with Kubernetes environments. Failure is almost inevitable in disbursed systems.
Effective observability is vital in Kubernetes manufacturing environments to monitor and measure the user experience, applications, platform, overall performance and quickly respond to incidents.
This can be carried out using a mix of whitebox and blackbox monitoring, software performance monitoring (APM), centralized logging and tracing. To Read More: Cloud container security
Security
There are plenty of matters involved in securing Kubernetes applications and platforms. Since cloud-native environments are very dynamic in nature, it’s higher to approach security for such environments from special angles (hence, the four pillars of cloud-native security).
At the code level, you want to make positive to minimize severe and high-risk vulnerabilities that you would possibly have in your codebase due to legacy code or open source libraries. Static code analysis can assist detect such vulnerabilities early on during the improvement process and throughout.
For example,
- many DevOps teams have been scrambling
- last year due to the crucial Log4j vulnerability
- that could have been detected with static analysis.
When it comes to containers, always make positive to reduce the attack floor by minimizing the container image file size. The large the file, the more likely it has vulnerabilities. Also, except otherwise needed, run rootless containers. This is of paramount importance.
In the Kubernetes cluster, make sure to make use of RBAC and provide the least amount of person privileges possible. This ensures that neither users nor applications attain access that they shouldn’t have. Also, restrict site visitors between the different namespaces or pods, as this is open by default.
Your application, platform and code possibly reside in a private, public or hybrid cloud. It’s very important to impenetrable that layer by following the security fine practices provided by your cloud provider, to observe the principle of least privilege and to continuously reveal for any suspicious activities.
Governance
Some industries operate under precise regulations, such as health care and financial services, and have to have certain policies in place, enforced and confirmed when it comes to Kubernetes environments. For example, having all data encrypted in transit and in flight.
Also, other open supply tools such as Polaris and Trivy can be easily built-in into your CI/CD pipeline to make sure workload configurations are following best practices and scan snap shots for vulnerabilities.
This is not an exhaustive checklist, but as a substitute a reminder and an opportunity to take the time and space to put together to go live. While checklists and automation can save you time, money and effort in your preparations, the cause of this exercise is to work with your teams to discover out what’s important to you, your end-users and your organization.
For example, a team in a economic services organization would possibly consider performance trying out a key area to focus on when you consider that they work with high-frequency trading apps and even a slight trade in latency can make a big difference.
The idea right here is to learn as much as you can all through this exercise, document your learnings and repeat in the future to better construct and operate Kubernetes clusters for production environments.
For more informative articles keep visiting Emu Article.
