Kubernetes (and thus Minikube) manages containers by wrapping them in Pods and managing those Pods through higher-level objects like Deployments and Services.
[mahesh@devopsvm01 ~]$ minikube status
minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured
minikube kubectl -- create deployment nginx-web --image=nginx creates a Deployment named nginx-web in your local minikube cluster, and this Deployment manages a set of identical Nginx application Pods.| Part of Command | Purpose |
minikube | This is the primary command-line tool for interacting with your local Kubernetes cluster running inside minikube. |
kubectl | This is the command-line tool for controlling a Kubernetes cluster. When used after minikube, it tells minikube to execute the kubectl command inside the minikube environment. |
-- | This is an optional but often useful separator. It signals to the minikube command that all subsequent arguments should be treated as arguments for the subcommand (kubectl) and not for minikube itself. |
create deployment | This is the kubectl instruction to create a new Kubernetes Deployment resource. A Deployment is a high-level controller that provides declarative updates for Pods and ReplicaSets. |
nginx-web | This specifies the name of the Deployment resource being created. |
--image=nginx | This crucial flag tells the Deployment what container image to use for the Pods it will manage. In this case, it instructs Kubernetes to pull and run the official Nginx web server image from Docker Hub. |
📦 What happens internally
When you run this command, Kubernetes will:
-
Create a Deployment named
nginx-web -
Deployment will create a ReplicaSet
-
ReplicaSet will create 1 Pod
-
That Pod runs a container from the image nginx
Accessing the Webpage
Now that Nginx is running inside a Pod, you need a Service to expose it to the outside world (your host VM).
Expose the Deployment with a NodePort Service
A Service acts as a stable IP address and load balancer for your Pods. A NodePort Service exposes the application on a specific port on the Kubernetes node (which is your minikube container).
[mahesh@devopsvm01 ~]$ minikube kubectl -- expose deployment nginx-web --type=NodePort --port=80
service/nginx-web exposed
[mahesh@devopsvm01 ~]$Part of Command Purpose expose deploymentThis is the kubectl instruction to create a new Service object for the specified resource (nginx-web). nginx-webThis specifies the Deployment that the new Service will target. The Service will automatically find and route traffic to the Pods managed by this Deployment. --type=NodePortThis is the crucial part that defines how the Service will be exposed. A NodePort Service opens a specific port on every Node (in your case, the single minikube VM/container) in the cluster, making the application accessible from outside the cluster network. --port=80This specifies the internal port on the Service itself. Traffic hitting the Service will be forwarded to the target Pods on their exposed port (which is port 80 for the Nginx image).
🌐 Resulting Service and Access
When this command is executed, a new Service resource named
nginx-webis created with the following properties:
Internal Access: Any Pod inside the cluster can now reach the Nginx application using the Service's ClusterIP and port 80.
External Access (The NodePort):
Kubernetes automatically picks a random, high-numbered port (typically between 30000 and 32767)—for example, $31404$ as seen in your previous output. This is the NodePort.
The Nginx application is now accessible using the IP address of your minikube Node and the assigned NodePort.
[mahesh@devopsvm01 ~]$ minikube kubectl -- get service nginx-web
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-web NodePort 10.104.42.136 <none> 80:31404/TCP 103m
[mahesh@devopsvm01 ~]$
Get the Access URL
Minikube provides a simple command to figure out the exact URL and port assigned to your service:
minikube service nginx-web --url
We will use kubectl exec to run a command inside the container that deliberately stops the main Nginx process. Because the main process exits, the container will terminate (crash).
NOTE: Nginx is often PID 1 in the container. Running kill 1 inside a container is a common way to simulate an abrupt shutdown.
No comments:
Post a Comment