12 Kube Configs with KPT

Adam Anderson
GitOps Essentials
Published in
6 min readNov 9, 2023

Introduction

There isn’t a direct metric or listing to determine the “most commonly used Kubernetes configs” as popularity can be quite transient and context-dependent. However, based on common Kubernetes practices, the following configurations are often used in various environments, ordered by what might be considered a general level of complexity or scope (ascending):

  1. Namespace Configs: For creating isolated environments within a Kubernetes cluster.
  2. ResourceQuota Configs: For managing the consumption of resources within a namespace.
  3. LimitRange Configs: For setting default resource usage limits for pods and containers.
  4. ConfigMaps: For non-confidential data in key-value pairs, used to configure applications.
  5. Secrets: For storing sensitive data, such as passwords or tokens.
  6. Service Accounts: For providing an identity for processes that run in a Pod.
  7. PersistentVolume (PV) and PersistentVolumeClaim (PVC): For managing storage resources.
  8. Deployments: For deploying stateless applications and managing the desired state of pods.
  9. StatefulSets: For deploying stateful applications that require stable identifiers and storage.
  10. Services: For defining a logical set of Pods and a policy by which to access them, often with a fixed IP address.
  11. Ingress: For managing external access to the services in a cluster, typically HTTP.
  12. Network Policies: For defining how groups of pods are allowed to communicate with each other and other network endpoints.

Please note that the popularity and commonality of certain Kubernetes configurations can be influenced by trends in microservices architecture, cloud-native technologies, and container orchestration best practices. For the most current information, you would need real-time data from Kubernetes package management and repository activity, which might be provided by cloud service providers or through analysis of public repository usage statistics.

To find the most commonly used Kubernetes configurations with kpt, you would typically look at public repositories where Kubernetes configurations are shared, such as the Google Cloud Platform's kpt package catalog or GitHub repositories that serve a similar purpose.

Photo by Mark Autumns on Unsplash

Config Management

As businesses continue to embrace Kubernetes, the complexity of managing configurations can become overwhelming. Kubernetes configurations are the scaffolding of your cluster, defining everything from the allocated resources to the rules governing your applications’ interactions. But fear not, as KPT is here to streamline your Kubernetes configuration management. In this article, we will explore the top 12 most commonly used Kubernetes configurations managed by KPT, from the simplest to the more complex, providing examples to guide you through each one.

Before diving in, if you’re looking for a comprehensive understanding of how KPT works, I highly recommend checking out my other article, “Unraveling Kubernetes KPT: The Next-Level Configuration Management”, which provides a deep dive into KPT’s inner workings.

Namespace Configurations

Namespaces are fundamental to structuring your Kubernetes cluster. They allow you to partition the cluster into sub-clusters, each with its own set of resources. This is especially useful in environments where multiple teams or projects share the cluster.

apiVersion: v1
kind: Namespace
metadata:
name: my-namespace

With KPT, you can easily pull and push namespace configurations to ensure each team’s environment is correctly set up and isolated from others.

ResourceQuota Configs

As your organization grows, managing resources efficiently becomes critical. Kubernetes’ ResourceQuota objects enable administrators to allocate and limit resources like CPU and memory.

apiVersion: v1
kind: ResourceQuota
metadata:
name: my-resource-quota
namespace: my-namespace
spec:
hard:
requests.cpu: "10"
requests.memory: 20Gi
limits.cpu: "20"
limits.memory: 40Gi

KPT can manage these configurations across various environments, making sure that no single namespace can overconsume resources at the expense of others.

LimitRange Configs

LimitRanges are crucial for setting default consumption limits for resources, providing constraints to prevent overutilization of cluster resources at the container or pod level.

apiVersion: v1
kind: LimitRange
metadata:
name: my-limit-range
namespace: my-namespace
spec:
limits:
- default:
memory: 512Mi
cpu: "1"
defaultRequest:
memory: 256Mi
cpu: "0.5"
type: Container

Through KPT, these configurations can be consistently applied, ensuring that defaults are in place to maintain the health of your services.

ConfigMaps

ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable.

apiVersion: v1
kind: ConfigMap
metadata:
name: my-configmap
namespace: my-namespace
data:
my-key: my-value

Using KPT, developers can effortlessly update and deploy ConfigMaps, promoting consistency and reducing the risk of configuration drift.

Secrets

Managing sensitive information such as passwords or API keys is where Secrets come into play.

apiVersion: v1
kind: Secret
metadata:
name: my-secret
namespace: my-namespace
type: Opaque
data:
password: cGFzc3dvcmQ=

With KPT’s ability to manage Secrets, you can securely update and synchronize sensitive data across your clusters.

Service Accounts

Service Accounts provide an identity for processes that run in a Pod, allowing your applications to interact with the Kubernetes API securely.

apiVersion: v1
kind: ServiceAccount
metadata:
name: my-service-account
namespace: my-namespace

KPT facilitates the creation and distribution of Service Accounts, ensuring that your applications have the right permissions to operate effectively.

PersistentVolumes and Claims

PersistentVolume (PV) and PersistentVolumeClaim (PVC) configurations are central to managing stateful data in Kubernetes.

apiVersion: v1
kind: PersistentVolume
metadata:
name: my-pv
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: standard
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi

KPT can help manage PVs and PVCs across different environments, making sure your storage configurations are consistent and persistent data is appropriately handled.

Deployments

Deployments are key to maintaining the desired state and updating pods in a controlled way for stateless applications.

apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-container
image: nginx:1.17.1

With KPT, you can handle complex Deployment updates and rollbacks, simplifying application management.

StatefulSets

For applications that require stable storage and unique identifiers, StatefulSets are the answer.

apiVersion: apps/v1
kind: StatefulSet
metadata:
name: my-statefulset
spec:
serviceName: "my-service"
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: main
image: nginx:1.17.1

Using KPT to manage StatefulSets, you ensure that your stateful applications are consistent and robust against disruptions.

Services

Services abstract the way you expose your applications, providing a consistent IP address and DNS name to access them.

apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 9376

KPT makes managing these Service configurations seamless across different namespaces and environments.

Ingress

Ingress manages external access to your services, often adding features like SSL termination or name-based virtual hosting.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
spec:
rules:
- http:
paths:
- path: /testpath
pathType: Prefix
backend:
service:
name: my-service
port:
number: 80

With KPT, Ingress configurations are easier to distribute and manage, ensuring reliable access to your services.

Network Policies

Network Policies specify how groups of pods are allowed to communicate with each other and other network endpoints.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: my-network-policy
spec:
podSelector:
matchLabels:
role: db
policyTypes:
- Ingress
ingress:
- from:
- ipBlock:
cidr: 172.17.0.0/16

By leveraging KPT, you can ensure your network policies are in place to secure communication within your Kubernetes environment.

In conclusion, KPT brings order and simplicity to Kubernetes configurations. From setting up basic Namespaces to managing complex Ingress rules, KPT empowers developers and administrators to maintain consistency, security, and efficiency in their Kubernetes environments. Remember to read my in-depth exploration of KPT in the article linked above for a thorough understanding of how KPT can transform your Kubernetes experience.

About the Author

Adam Anderson is a passionate software engineer with more than 10 years of experience in C/C++, Java, and Python application development. He has a strong interest in build automation, DevOps practices, and project management. When not diving into code and configuration files, Adam enjoys hiking in the great outdoors and exploring new technology trends. You can reach out to Adam Anderson via email at xsizxenjin@gmail.com for more insights on software development and project management.

Your support is appreciated!!

Thank you!!

Miscellaneous Selected Articles:

1. Unleashing the Power of `awk`: Advanced Text Processing Techniques
2. Mastering Data Processing with jq: Advanced Techniques for MongoDB
3. Maven Packaging: ZIP vs. WAR — A Comprehensive Comparison
4. Enhancing Java Application Security: A Deep Dive into the Maven Dependency Plugin’s Top 20 Vulnerability Finds
5. 20 Advanced Pipelining Tips and Tricks Using AWS CLI

--

--

Adam Anderson
GitOps Essentials

Detail oriented reader, lifelong learner, and technologist driving change one cause at a time