Namespaces in k8s
In Kubernetes (k8s), namespaces are a way to divide cluster resources between multiple users, teams, or projects. They provide a scope for names. Names of resources need to be unique within a namespace, but not necessarily across namespaces. This is useful in scenarios where you want to isolate resources and avoid naming conflicts.
Here are some key points about Kubernetes namespaces:
Isolation: Namespaces provide a level of isolation for resources within a Kubernetes cluster. Resources such as pods, services, and replication controllers can be associated with a particular namespace.
Default Namespace: When you create resources without specifying a namespace, they are created in the default namespace. It's important to be mindful of the namespace you are working in to avoid unintentional conflicts.
Multiple Namespaces: You can create and use multiple namespaces within a Kubernetes cluster. This is useful for multi-tenancy or when different teams or projects are using the same cluster.
Viewing and Switching: You can view the existing namespaces in a cluster using the
kubectl get namespaces
command. To switch to a different namespace, you can usekubectl config set-context --current --namespace=<namespace>
.Resource Quotas: Namespaces can be used in conjunction with resource quotas to limit the amount of CPU, memory, and other resources that can be consumed within a namespace.
Here's an example of creating a namespace in Kubernetes:
yamlCopy codeapiVersion: v1
kind: Namespace
metadata:
name: mynamespace
Services in k8s:-
In Kubernetes, a service is an abstraction that defines a logical set of pods and a policy by which to access them. Services enable communication between various microservices or applications running in a Kubernetes cluster. They provide a stable IP address and DNS name for a set of pods, allowing other applications to reliably discover and communicate with them.
Here are some key points about services in Kubernetes:
Types of Services:
ClusterIP: This is the default service type. It exposes the service on a cluster-internal IP, which makes it reachable only from within the cluster.
NodePort: This type exposes the service on a specific port on each node in the cluster. It makes the service accessible externally, outside the cluster, by using the node's IP address and the specified port.
LoadBalancer: This type provisions an external load balancer in cloud providers (e.g., AWS, GCP, Azure) and assigns a stable external IP. It can distribute incoming traffic across multiple pods.
ExternalName: This type maps the service to the contents of the
externalName
field (e.g.,foo.example.com
), and no proxying of any kind is set up.
Service Discovery:
- Services in Kubernetes are assigned a DNS name based on the service name and the namespace it belongs to. This makes it easy for applications within the cluster to discover and communicate with each other using the service name.
Selectors:
- A service selects pods based on labels. Pods that match the label selector specified in the service definition are part of the service.
Labels and Selectors:
- Labels are key-value pairs attached to objects, such as pods. Services use label selectors to determine which pods to include. For example, if a service selects pods with the label
app=web
, all pods with that label become part of the service.
- Labels are key-value pairs attached to objects, such as pods. Services use label selectors to determine which pods to include. For example, if a service selects pods with the label
Internal Communication:
- Services are often used for internal communication between microservices. For example, if you have a set of backend pods providing a service, front-end pods can communicate with them through a service without needing to know the IP addresses of the individual backend pods.
Load Balancing:
- Services with multiple pods distribute incoming traffic among the pods. This load balancing helps in distributing workloads and ensures high availability.
Here's an example of a simple ClusterIP service:
yamlCopy codeapiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 8080
Day 33 of #90daysofDevOps
Thanks for reading
Follow me for more about DevOps♾️........
________________________________________________________________________________
#90daysHardChallenge
#Cloudcomputing
#DevOps
#Python
#TrainWithShubham