everythingpossible - Fotolia
4 trends for Kubernetes cloud-native teams to watch in 2020
Today's software architectural landscape seems to change like the weather. Stay ahead of the curve with these cloud-related trends, including GitOps and service meshes.
In the world of software development, there are notable movements around the use of Kubernetes, diligent version control, communication through service mesh and cloud security.
Let's take a closer look at each of these four Kubernetes cloud-native trends.
1. Kubernetes and GitOps
Containers are now used as standard units of deployment, and Kubernetes has become a de facto container orchestrator thanks to its ability to abstract infrastructure. Kubernetes also contributed to the rise of GitOps in which software teams manage infrastructure the same way that they manage application code. GitOps provides an environment-management approach that uses version control for infrastructure configurations and manages hosting environment changes as new versions.
When infrastructure is written and managed as code, developers can focus on that code while the infrastructure falls into place. This is perfectly suited to microservices and containers, as well as any kind of complex environment that spans multiple development trees and versions of software. By shifting concerns away from servers and VMs, developers can focus on higher-level concerns, such as feature additions and delivery processes. Infrastructure for environments such as test, staging and production can each exist as code in the application's repository.
2. Repositories and version control
Version control, the driving technology behind GitOps, enables developers to keep track of all changes made to code in a special repository to avoid conflicting code. GitHub is a popular example of this kind of version control repository management. A version control system keeps track of who made what changes when, and the intent behind those changes. It also lets software teams roll back to earlier versions of code so troubleshooting tasks don't disrupt other team members. This is especially useful in distributed projects where different developers simultaneously work on their own services and features.
Using version control to manage Kubernetes configuration files is based on the declarative nature of Kubernetes. As opposed to taking a step-by-step approach to achieve a certain configuration for a cluster, Kubernetes only concerns itself with a cluster's desired end state. It's also important to maintain a single source of truth using repository-based change management that can handle complex application environments.
3. Service mesh technology
While Kubernetes orchestrates containers, the user needs to manage communications between those containers. An enterprise software architecture could include hundreds or thousands of containers, all set to communicate with each other by default. The short lifespan of containers and their dynamic nature makes it difficult to maintain uniformity during runtime. This is the problem that the service mesh technology, such as Istio and Linkerd, aims to solve.
Service meshes are infrastructure-agnostic and enable users to monitor and control traffic across an assortment of services and resources. Most service meshes, such as Istio and Linkerd, are built on the sidecar proxy design, which works alongside application containers to mimic their behavior and facilitate configuration and logging processes independently of the application. In addition to traffic management, security and observability capabilities, service meshes often include built-in functionalities for service discovery and load balancing.
4. Security concerns
Security is a top concern for organizations undergoing a cloud migration, especially with the growing complexity of Kubernetes cloud-native environments. While Kubernetes proved that it's possible to manage a distributed environment with declarative policies, the security implications are another matter altogether. For example, in 2019, the orchestrator was exposed to the runC vulnerability, CVE-2019-11247 that failed to restrict permissions and others.
Kubernetes cloud-native application teams must understand their own responsibility for security related to cloud vendors. The AWS shared responsibility model shows that cloud providers cannot be solely responsible for security. This means users must manage application vulnerabilities, configurations and other security concerns diligently on their own. Teams that rely on container orchestration via Kubernetes should absolutely focus on centralized security and how to mitigate any potential vulnerability the orchestrator might impose.
