Introduction

Kubernetes' kubectl run command, once a versatile tool for creating and managing pods, deployments, and other resources, is now deprecated for certain use cases. This article will explore why some functionalities of kubectl run are deprecated, provide alternatives, and guide you through making these changes seamlessly in your Kubernetes workflows.

Deprecation of kubectl run

kubectl run was initially designed to cover a variety of use cases, from running simple pods to more complex deployments. Over time, the Kubernetes community recognized that having a single command that served multiple purposes could lead to ambiguity and misuse. As Kubernetes evolved, finer-grained resources like kubectl create and specific API objects for deployments, jobs, and cronjobs were introduced, leading to a more declarative and resource-specific approach.

Why was kubectl run deprecated?

1. Ambiguity and Overhead:
   • kubectl run attempted to manage both initial pod creation and rolling updates of deployments, leading to confusion. The overload of options made it cumbersome and less user-friendly.
2. Declarative Model Preference:
   • Kubernetes promotes a declarative model, where resources are described in manifests. kubectl run leaned more on the imperative style, misaligning with best practices.
3. Better API Coverage:
   • As Kubernetes developed more specific API objects like Deployment, Job, and CronJob, relying on these specific resources has become the norm.

How kubectl run Still Functions

While some functions of kubectl run are deprecated, especially those related to complex resource creation (like deployments), it stills retains usage for those looking to:

• Quickly spin up a temporary pod, primarily for testing or debugging.

Example:

kubectl run my-pod --image=nginx

However, for creating and managing more extensive setups like deployments, alternatives exist that align better with Kubernetes' practices.

Recommended Alternatives

kubectl create

For a more declarative and flexible approach, kubectl create covers the need for different resources. For instance, to create a deployment:

kubectl create deployment my-deployment --image=nginx

Here, kubectl create is used to specify the exact type of resource you intend to create, ensuring the intention is clear and aligned with Kubernetes' API resource types.

YAML Manifests

Defining resources in YAML manifests is a Kubernetes best practice. This method allows for a more controlled and versionable approach to application deployment.

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: my-deployment
5spec:
6  replicas: 3
7  selector:
8    matchLabels:
9      app: nginx
10  template:
11    metadata:
12      labels:
13        app: nginx
14    spec:
15      containers:
16      - name: nginx
17        image: nginx

To apply this manifest:

kubectl apply -f my-deployment.yaml

Additional Tools and Techniques

1. Helm:
   • A package manager for Kubernetes, Helm, simplifies the management of Kubernetes applications using charts – pre-configured templates for Kubernetes resources.
2. Kustomize:
   • Allows customizing Kubernetes resource configurations free from template restrictions.
3. Operators:
   • Application-specific controllers that extend Kubernetes' functionality, managing complex and domain-specific processes within a cluster.

Key Points Summary

Conclusion

While kubectl run remains a useful tool for specific cases, its limitations make it essential for Kubernetes practitioners to pivot towards more suitable alternatives. Embracing kubectl create, YAML manifests, and complementary tools like Helm, ensures robust, transparent, and aligned deployments with Kubernetes' ecosystem, harnessing the platform's full potential for scalable and resilient applications.