Pods
These are the smallest deployable units of computing that you can create and manage in Kubernetes.
A Pod is a group of one or more containers, with shared storage and network resources, and a specification for how to run the containers.Within a Pod's context, the individual applications may have further sub-isolations applied.
A Pod is similar to a set of containers with shared namespaces and shared filesystem volumes.
Pods in a Kubernetes cluster are used in two main ways:
Pods that run a single container.
Pods that run multiple containers that need to work together.
#Example of an nginx Pod with nginx container.
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
You can also create pod like :
kubectl run nginxpod --image=nginx --dry-run=client -o yaml > file.yaml
Static Pods
These are managed directly by the kubelet daemon on a specific node, without the API server observing them. Whereas most Pods are managed by the control plane (for example, a Deployment), for static Pods, the kubelet directly supervises each static Pod (and restarts it if it fails).
Replica Sets
A ReplicaSet's purpose is to maintain a stable set of replica Pods running at any given time. As such, it is often used to guarantee the availability of a specified number of identical Pods.
A ReplicaSet is configured with several key fields: a selector that helps it identify which Pods it can manage, a desired number of replicas that indicates how many Pods should be running, and a pod template that outlines the specifications for any new Pods that need to be created. The ReplicaSet ensures that the desired number of Pods is always running by either creating new Pods or removing existing ones as necessary. When it needs to generate new Pods, it uses the provided pod template as a blueprint.
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: frontend
labels:
app: guestbook
tier: frontend
spec:
# modify replicas according to your case
replicas: 3
selector:
matchLabels:
tier: frontend
template:
metadata:
labels:
tier: frontend
spec:
containers:
- name: php-redis
image: us-docker.pkg.dev/google-samples/containers/gke/gb-frontend:v5
You can then get the current ReplicaSets deployed:
kubectl get rs
Deployments
You describe a desired state in a Deployment, and the Deployment Controller changes actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
Typical use cases for Deployments :
Use the status of the Deployment as an indicator that a rollout has stuck.
To get the deployments running in your cluster you can use the command :-
kubectl get deployments --all-namespaces
#for the default namespace
kubectl get deployment
#for a perticular namespace
kubectl get deployment -n namespace
Services
Service is an abstraction that defines a logical set of Pods and a policy by which to access them. Services enable communication between different components of an application or with the outside world, without requiring the components to know about the underlying Pods' details, like their IP addresses, which can change over time.
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
The Service API, part of Kubernetes, is an abstraction to help you expose groups of Pods over a network. Each Service object defines a logical set of endpoints (usually these endpoints are Pods) along with a policy about how to make those pods accessible.
The available type values and their behaviors are:
Cluster IP :
Exposes the Service on a cluster-internal IP. Choosing this value makes the Service only reachable from within the cluster.
NodePort :
Exposes the Service on each Node's IP at a static port.
LoadBalancer :
Exposes the Service externally using an external load balancer.
ExternalName :
The mapping configures your cluster's DNS server to return a
CNAMErecord with that external hostname value. No proxying of any kind is set up.
To get the running services in your cluster you can run the command :-
kubectl get service --all-namespaces
Namespaces
It provide a mechanism for isolating groups of resources within a single cluster. Names of resources need to be unique within a namespace, but not across namespaces. Namespace-based scoping is applicable only for namespaced objects Like:- Deployments, Services, etc. and not for cluster-wide objects Like:- StorageClass, Nodes, PersistentVolumes, etc.
Namespaces are intended for use in environments with many users spread across multiple teams, or projects. For clusters with a few to tens of users, you should not need to create or think about namespaces at all. Start using namespaces when you need the features they provide.
Most Kubernetes resources (e.g. pods, services, replication controllers, and others) are in some namespaces. However namespace resources are not themselves in a namespace. And low-level resources, such as nodes and persistentVolumes, are not in any namespace.
Viewing namespaces
kubectl get namespace
#Setting the namespace for a request
kubectl run nginx --image=nginx --namespace=<insert-namespace-name-here>
kubectl get pods --namespace=<insert-namespace-name-here>