How to establish a Kubernetes governance strategy

Implement Kubernetes governance

Kubernetes governance applies policies for cluster allocation, deployment, redeployment and scaling. These policies can be set in response to external regulations, through company policies, or by designing an efficient resource pool and ensuring high application availability and experience quality.

When Kubernetes governance involves an IT budget justification, these policies can also enforce the conditions set in the budget justification to ensure the business case is met.

The 3 elements of a Kubernetes governance strategy

Three elements are involved in a Kubernetes governance implementation strategy: targets, scope and policy directives.

1. Targets are the specific policy goals the strategy must meet. Direct targets, governance objectives and derived targets represent internal steps that IT teams must take to ensure the organization meets those defined targets. The operations team usually sets these targets as the first step of creating a governance framework.
2. Scope is the set of elements to which policies should be applied to address the targets and must address all Kubernetes-visible components. Many organizations derive technical scope from the top, starting with organizational and facility divisions.
3. Policy directives use Kubernetes capabilities to address governance policies across the specified scopes to the direct and derived targets. As the ultimate outcome of a Kubernetes governance framework, policy directives are the final step in establishing Kubernetes governance and are the primary focus of governance projects.

Types of Kubernetes governance targets

Organizations can divide Kubernetes governance targets into the following categories:

• security
• container image controls
• network controls and configurations
• application deployment, redeployment and scaling

Teams assign a scope for the targets within each category. IT admins use the combinations of targets and scope to create specific policy directives.

Security governance for Kubernetes is normally enforced using third-party tools, such as Open Policy Agent, KubeLinter, kube-bench and kube-hunter. Service meshes like Istio can also be used for containerized microservices. Select tools carefully, as some security tools can also enforce policies in other target categories. As a general rule, the fewer tools in use, the better.

Container image controls relate to the development and testing process, and the practices needed to graduate software from testing to production. Governance here is enforced via associated tools, and through the overall development and testing processes.

Most organizations enforce more granular constraints on development and testing than would normally be considered as part of governance. Start with specific governance requirements -- for example, specific testing flows and numbers of warnings -- and refine them with additional development policies to create a framework that works for governance as well as development and software quality control.

The virtual network tool selected is the main provider of network control in Kubernetes. Kubernetes presumes that a cluster's nodes are mutually addressable from within the cluster address space, but anything addressed from the outside must be exposed explicitly.

The question of what to expose lies in application design. Don't expose any more than is necessary to enhance application security. Controlling addressability within a cluster is possible using virtual network features, but this can cause confusion in cluster maintenance and must be documented carefully.

Configuration policies limit which cluster resources organizations or individuals can allocate in the cloud when there is an incremental cost to consider. They can also prevent organizations from seizing more data center resources than they are entitled to use. This type of control is accessed directly through Kubernetes management features.

Kubernetes features

Application deployment, redeployment and scaling are the most familiar of all Kubernetes policy categories. These policies manage the fundamental issue of orchestration: how pods are allocated to nodes and how those allocations change over time.

Four Kubernetes features are typically involved in pod allocation:

• Affinities, which describe attractors, pull pods to particular nodes. This specifies which related application components to keep together for performance reasons.
• Taints -- in contrast to affinities -- repel pods from nodes. This is useful when local regulations on data and content types make it undesirable to host information at a particular node or to prevent low-priority applications from using resources needed for higher-priority ones.
• Tolerations enable granular control of pod allocations to nodes. Pods with a toleration for a particular taint are the only ones that can be scheduled at the tainted node. This allows for a graduated application of taints, rather than a strict yes-or-no decision.
• Horizontal pod autoscaling is a Kubernetes feature that controls a given pod's response to demand. Under load, a given pod might scale "out" by assigning more nodes to pod replicas or scale "back" by removing replica assignments. This controls whether a given application incurs variable costs to match work to resources, which can easily lead to massive cost overruns.

When working with any of these policy categories, IT teams should consider all their governance goals together to avoid creating policies that are redundant or conflicting. Consistency is critical to the success of any governance strategy and to Kubernetes overall.