Kubeconfig, Services, and Deployments Files

Kubeconfig Files

● Purpose: Kubeconfig files are used for cluster access and authentication. Kubeconfig defines how ‘kubectl’ or any other Kubernetes clients interact with the Kubernetes cluster.
● Contents: The Kubeconfig file contains information about the cluster, user credentials, certificates, and context.
● Usage: Kubeconfig files are used by Administrators, developers, or CI/CD systems to
authenticate the Kubernetes cluster. They decide who can access and how to access the cluster.
Kubeconfig files can be stored in the user’s home directory (~/.kube/config) or specified
using the KUBECONFIG environment variable.

Kubeconfig file explained

apiVersion: v1
kind: Config
clusters:
- name: my-cluster
cluster:
server: https://api.example.com
certificate-authority-data: <ca-data>
users:
- name: my-user
user:
client-certificate-data: <client-cert-data>
client-key-data: <client-key-data>
contexts:
- name: my-context
context:
cluster: my-cluster
user: my-user
namespace: my-namespace
current-context: my-context

In this example,
● apiVersion and kind define the resource type.
● clusters specifies the clusters with its server and URL and Certificate Authority(CA)
data. Here we have to define the server link or Kubernetes API Server of the Kubernetes
cluster. So, when we run any command using kubectl then kubectl interacts with the
given link or Kubernetes API Server of the Kubernetes cluster.
● users specify the users with their client certificate and client key name. So, only
authorized users can access the Kubernetes cluster.
● contexts specify the cluster, user, and namespace information that has been defined
above. You can create multiple contexts and switch between any different clusters at any
time.
● current-context specifies that on which cluster the command should run. If you set the
current-context one time then you won’t have to specify again and again while running
the commands.

Service File
**Purpose: Service files contain all information about networking. The service file defines
how networking will be handled on the cluster. Also, the Service file enabled the load
balancing option for the applications which is a premium feature of Kubernetes.
Contents: The service file specifies the service’s name, type(ClusterIP, NodePort, LoadBalancer, etc[Discuss in Upcoming Blogs]), and selectors to route traffic to pods.

Usage: Service files are used by developers and administrators to expose and connect applications within the Kubernetes cluster.

Note: Services can also be used for internal communication between Pods within the cluster,
not just for exposing applications externally.

Service file explained

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

In this example,
● apiVersion and kind specify the resource type
● metadata specify the name of the service
● spec specify the desired state of the Service
● selector specifies on which pod the configurations will be invoked. If the pod label
matches by app value then it will apply the configuration on that pod
● In the ports section, protocol specifies the network protocol such as TCP, UDP, etc.
● ports specifies on which port the service listens for the incoming traffic from the external
sources.
● targetports specify on which port the pod is listening.

**Deployment files

Purpose: Deployment files contain all information about the application and define how
the application or microservices will be deployed on the Kubernetes cluster. In
deployment files, we can define the desired state, pod replicas, update strategies, and
pod templates.
Contents: Deployment files define the desired state of a deployment, pod replicas,
container images, and resource limits.
Usage: Deployment files are mainly used by developers and administrators to manage
the application lifecycle within Kubernetes. They enable declarative application management, scaling, and rolling updates.

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

In this example,
● apiVersion and kind define the resource type
● metadata specify the details of deployment such as the name of the deployment, and
labels.
● spec defines the desired state of the Deployment.
● replicas specify the desired number of pods to maintain.
● The selector specifies on which pod the replica configuration should be applied with the
help of the label of the pod.
● template describes the pod template and how deployment will use it to create new pods.
● containers will list the containers to run within the pod.
● name specifies the name of the container
● image specifies the name that will be used to run the container. The image will be a
Docker Image.
● containerport specifies the port at which the container will listen for incoming traffic.