Table of contents
Command lines used in Kubernetes
- Use configuration file:
kubectl apply -f pod-priority.yaml - Delte all pods :
kubectl delete pods --all - Show Labels in pods:
kubectl get pods --show-labels - Label deployment with multiple labels:
kubectl label deployments bandicoot-prod env=prod color=red - Create a deployment with replicas:
kubectl create deployment bandicoot-prod --image=gcr.io/kuar-demo/kuard-amd64:green --replicas=2 --port=8080 - Show deployments labels:
kubectl get deployments --show-labels - Check how a kubernetes object changes over time for a specific service:
kubectl get endpoints <service-name> --watch
Why expose the deployment to service
kubectl expose deployment is a Kubernetes command that creates a new Kubernetes Service to expose an existing Deployment. It essentially makes your application, managed by the Deployment, accessible from outside the Kubernetes cluster or within the cluster via a stable endpoint. Here’s a breakdown:
Deployment:
A Kubernetes Deployment manages a set of identical Pods (replicas) and handles updates, rollouts, and scaling of those pods.
Service:
A Kubernetes Service provides a stable IP address and DNS name for accessing a set of Pods, even as those Pods are created and destroyed.
kubectl expose:
This command takes an existing Deployment and creates a Service that routes traffic to the Pods managed by that Deployment.
Why use it?
Without a Service, accessing your application would require knowing the IP addresses of individual Pods, which are ephemeral and can change. The Service provides a consistent way to reach your application.
How it works:
The kubectl expose command automatically creates a Service object with selectors that match the labels of the Deployment. This ensures that the Service routes traffic to the correct Pods. In simpler terms: Imagine you have a web application running on multiple servers (represented by Pods in Kubernetes). kubectl expose deployment lets you create a “front door” (the Service) that users can use to access your application, even if the underlying servers (Pods) are restarted or replaced.
Example:
To expose a Deployment named “my-app” on port 80, you would use the command:
kubectl expose deployment my-app --port=80 --target-port=8080
This command creates a Service that listens on port 80 and forwards traffic to the Pods in the “my-app” Deployment on port 8080 (where your application is likely listening).
What is the difference between a pod and a deployment?
From the link and show one anwser:
Kubernetes has three Object Types you should know about:
- Pods - runs one or more closely related containers
- Services - sets up networking in a Kubernetes cluster
- Deployment - Maintains a set of identical pods, ensuring that they have the correct config and that the right number of them exist.
-
Pods:
- Runs a single set of containers
- Good for one-off dev purposes
- Rarely used directly in production
Deployment:
- Runs a set of identical pods
- Monitors the state of each pod, updating as necessary
- Good for dev
- Good for production
And I would agree with other answers, forget about Pods and just use Deployment. Why? Look at the second bullet point, it monitors the state of each pod, updating as necessary.
So, instead of struggling with error messages such as this one:
Forbidden: pod updates may not change fields other than spec.containers[*].image
So just refactor or completely recreate your Pod into a Deployment that creates a pod to do what you need done. With Deployment you can change any piece of configuration you want to and you need not worry about seeing that error message.
Use a web browser to connect to the app via the Service
curl http://<public-node-ip>:<node-port>