kubernates(K8s) resources Overview with examples with complete explanation-

Category : Kubernetes | Sub Category : Kubernetes With Java | By Prasad Bonam Last updated: 2023-11-17 09:33:47 Viewed : 221

Pod:

The YAML snippet you provided is a Kubernetes manifest for creating a Pod. Lets break it down:

yamlCopy code
apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
    - name: nginx-container
      image: nginx

• apiVersion: v1: This field specifies the Kubernetes API version you are using. In this case, its "v1," which is the stable API version for basic objects like Pods.

• kind: Pod: The "kind" field defines the type of Kubernetes resource you want to create. Here, its a Pod.

• metadata: This section contains metadata about the Pod, including its name.

  • name: example-pod: This sets the name of the Pod to "example-pod."

• spec: The "spec" section describes the desired state of the Pod, including its containers.

  • containers: This is an array where you define the containers running inside the Pod.

    • name: nginx-container: Specifies the name of the container within the Pod, in this case, "nginx-container."

    • image: nginx: Specifies the container image to use for the "nginx-container." In this example, its using the official Nginx image from Docker Hub.

So, in summary, this YAML manifest is instructing Kubernetes to create a Pod named "example-pod" with a single container named "nginx-container" running the Nginx image. Once applied to a Kubernetes cluster using the kubectl apply -f filename.yaml command, Kubernetes will work to ensure that the described state is achieved, and the specified Pod with the Nginx container is running in the cluster.

Service:

YAML snippet is a Kubernetes manifest for creating a Service. Lets break it down:

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

• apiVersion: v1: This field specifies the Kubernetes API version you are using. In this case, its "v1," which is the stable API version for basic objects like Services.

• kind: Service: The "kind" field defines the type of Kubernetes resource you want to create. Here, its a Service.

• metadata: This section contains metadata about the Service, including its name.

  • name: example-service: This sets the name of the Service to "example-service."

• spec: The "spec" section describes the desired state of the Service.

  • selector: This field is used to select the set of Pods that the Service will route traffic to. In this example, it selects Pods based on the label "app: example-app."

  • ports: This field specifies how the Service will expose the selected Pods.

    • protocol: TCP: Specifies the protocol to be used (in this case, TCP).

    • port: 80: Specifies the port on which the Service will be exposed externally.

    • targetPort: 8080: Specifies the port to which the traffic will be forwarded inside the selected Pods.

So, in summary, this YAML manifest is instructing Kubernetes to create a Service named "example-service" that selects Pods with the label "app: example-app" and forwards external traffic from port 80 to port 8080 on those selected Pods. The Service provides a stable endpoint for applications to communicate with the Pods, abstracting away the complexity of Pod IP addresses and allowing for easy service discovery and load balancing.

Namespace

YAML snippet is a Kubernetes manifest for creating a Namespace. Lets break it down:

yamlCopy code
apiVersion: v1
kind: Namespace
metadata:
  name: example-namespace

• apiVersion: v1: This field specifies the Kubernetes API version you are using. In this case, its "v1," which is the stable API version for basic objects like Namespaces.

• kind: Namespace: The "kind" field defines the type of Kubernetes resource you want to create. Here, its a Namespace.

• metadata: This section contains metadata about the Namespace, including its name.

  • name: example-namespace: This sets the name of the Namespace to "example-namespace."

  • • So, in summary, this YAML manifest is instructing Kubernetes to create a Namespace named "example-namespace." Namespaces provide a way to divide cluster resources between multiple users or teams. They are a way to create virtual clusters within the same physical cluster, allowing for better organization and isolation of resources. Resources created within a namespace are bound to that namespace, and the same resource names can exist in different namespaces without conflict. This helps in managing and organizing resources in a large and shared Kubernetes environment.

Namespaces in Kubernetes provide a way to divide cluster resources between multiple users or teams. They are a way to create virtual clusters within the same physical cluster. Here is why you might use Namespaces:

1. Isolation: Namespaces provide a scope for names. You can have resources with the same name in different namespaces, providing isolation.

2. Resource Quotas: You can set resource quotas on a per-namespace basis, restricting the amount of CPU, memory, and other resources that can be used.

3. Access Control: Namespaces can be used to control access to resources. You can define Role-Based Access Control (RBAC) rules specific to a namespace.

4. Organization: For large and complex applications or multi-tenant clusters, using namespaces helps organize and manage resources more effectively.

In this example, the YAML manifest is creating a Namespace named "example-namespace." Once applied to a Kubernetes cluster using the kubectl apply -f filename.yaml command, the namespace will be created, and you can start deploying resources within that namespace to keep them logically separated from resources in other namespaces.

Deployment:

YAML snippet is a Kubernetes manifest for creating a Deployment. Lets break it down:

yamlCopy code
apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: example-app
  template:
    metadata:
      labels:
        app: example-app
    spec:
      containers:
        - name: nginx-container
          image: nginx

• apiVersion: apps/v1: This field specifies the Kubernetes API version you are using. In this case, its "apps/v1," which is the API version for Deployment objects.

• kind: Deployment: The "kind" field defines the type of Kubernetes resource you want to create. Here, its a Deployment.

• metadata: This section contains metadata about the Deployment, including its name.

  • name: example-deployment: This sets the name of the Deployment to "example-deployment."

• spec: The "spec" section describes the desired state of the Deployment.

  • replicas: 3: This specifies that the Deployment should ensure there are three replicas (copies) of the application running.

  • selector: This field is used to match the Pods controlled by this Deployment.

    • matchLabels: This specifies the labels that Pods must have to be managed by this Deployment. In this example, Pods must have the label "app: example-app."

  • template: This is the template for creating new Pods.

    • metadata: This section allows you to set labels for the Pods.

      • labels: This sets the label "app: example-app" for the Pods created by this Deployment.

    • spec: This section defines the specification for the Pods.

      • containers: This is an array where you define the containers running inside the Pods.

        • name: nginx-container: Specifies the name of the container within the Pod, in this case, "nginx-container."

        • image: nginx: Specifies the container image to use for the "nginx-container." In this example, its using the official Nginx image from Docker Hub.

So, in summary, this YAML manifest is instructing Kubernetes to create a Deployment named "example-deployment" with three replicas of Pods. Each Pod runs a container named "nginx-container" using the Nginx image. The Deployment ensures that the specified number of replicas is always running, making it easier to scale applications up or down and manage updates and rollbacks.

this YAML manifest is instructing Kubernetes to create a Deployment named "example-deployment" that ensures there are three replicas of Pods, each running the Nginx container. The label "app: example-app" is used to manage and select these Pods. Deployments are a higher-level abstraction that allows for declarative updates to applications, making it easy to scale the number of replicas, roll out updates, and manage the lifecycle of application instances.

ReplicaSet:

YAML snippet is a Kubernetes manifest for creating a ReplicaSet. Lets break it down:

yamlCopy code
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: example-replicaset
spec:
  replicas: 2
  selector:
    matchLabels:
      app: example-app
  template:
    metadata:
      labels:
        app: example-app
    spec:
      containers:
        - name: nginx-container
          image: nginx

• apiVersion: apps/v1: This field specifies the Kubernetes API version you are using. In this case, its "apps/v1," which is the API version for higher-level application-related objects like ReplicaSets.

• kind: ReplicaSet: The "kind" field defines the type of Kubernetes resource you want to create. Here, its a ReplicaSet.

• metadata: This section contains metadata about the ReplicaSet, including its name.

  • name: example-replicaset: This sets the name of the ReplicaSet to "example-replicaset."

• spec: The "spec" section describes the desired state of the ReplicaSet.

  • replicas: 2: Specifies the desired number of replicas (Pod instances) to run. In this example, its set to 2.

  • selector: This field is used to select which Pods the ReplicaSet should manage. In this case, it selects Pods based on the label "app: example-app."

  • template: Describes the Pod template used to create new Pods.

    • metadata: Contains labels for Pods created by this template.

      • labels: The label "app: example-app" is applied to Pods created by this template.

    • spec: Describes the specification of the Pods created by this template.

      • containers: Describes the containers that should run in each Pod.

        • name: nginx-container: Specifies the name of the container within the Pod, in this case, "nginx-container."

        • image: nginx: Specifies the container image to use for the "nginx-container." In this example, its using the official Nginx image from Docker Hub.

So, in summary, this YAML manifest is instructing Kubernetes to create a ReplicaSet named "example-replicaset" that ensures there are two replicas of Pods, each running the Nginx container. The label "app: example-app" is used to manage and select these Pods. ReplicaSets are a lower-level abstraction compared to Deployments, and they are mainly used when fine-grained control over the Pod lifecycle is necessary.

ConfigMap:

YAML snippet is a Kubernetes manifest for creating a ConfigMap. Lets break it down:

yamlCopy code
apiVersion: v1
kind: ConfigMap
metadata:
  name: example-configmap
data:
  key1: value1
  key2: value2

• apiVersion: v1: This field specifies the Kubernetes API version you are using. In this case, its "v1," which is the API version for basic objects like ConfigMaps.

• kind: ConfigMap: The "kind" field defines the type of Kubernetes resource you want to create. Here, its a ConfigMap.

• metadata: This section contains metadata about the ConfigMap, including its name.

  • name: example-configmap: This sets the name of the ConfigMap to "example-configmap."

• data: This section contains the key-value pairs that constitute the data in the ConfigMap.

  • key1: value1: This defines a key "key1" with the corresponding value "value1" in the ConfigMap.

  • key2: value2: This defines a key "key2" with the corresponding value "value2" in the ConfigMap.

ConfigMaps in Kubernetes are used to decouple configuration artifacts from container images, allowing you to modify configuration data without changing the container itself. The data stored in a ConfigMap can be consumed by Pods in various ways, such as environment variables, command-line arguments, or as configuration files mounted into containers.

In this example, the ConfigMap "example-configmap" is created with two key-value pairs: "key1: value1" and "key2: value2." Once applied to a Kubernetes cluster using the kubectl apply -f filename.yaml command, this ConfigMap can be referenced by other Kubernetes resources, and the data it contains can be used by Pods or other components within the cluster.

Secrets :

YAML snippet is a Kubernetes manifest for creating a Secret. Lets break it down:

yamlCopy code
apiVersion: v1
kind: Secret
metadata:
  name: example-secret
type: Opaque
data:
  username: <base64-encoded-username>
  password: <base64-encoded-password>

• apiVersion: v1: This field specifies the Kubernetes API version you are using. In this case, its "v1," which is the API version for basic objects like Secrets.

• kind: Secret: The "kind" field defines the type of Kubernetes resource you want to create. Here, its a Secret.

• metadata: This section contains metadata about the Secret, including its name.

  • name: example-secret: This sets the name of the Secret to "example-secret."

• type: Opaque: This field specifies the type of the Secret. "Opaque" is a generic type for arbitrary data. It means that the content of the Secret is not interpreted or processed by Kubernetes.

• data: This section contains the actual secret data, which is base64-encoded.

  • username: <base64-encoded-username>: This is an example of a key-value pair within the Secret. The key is "username," and the value is base64-encoded. When using this Secret, the application needs to decode the base64 value to get the original data.

  • password: <base64-encoded-password>: Another key-value pair for a password in the Secret, also base64-encoded.

Secrets in Kubernetes are used to store and manage sensitive information, such as usernames, passwords, API keys, and TLS certificates. The data in a Secret is encoded in base64 format to obfuscate it, although its important to note that base64 encoding is not a secure encryption method; its simply a representation to make the data readable within a YAML file.

Once applied to a Kubernetes cluster using the kubectl apply -f filename.yaml command, the Secret can be referenced by other Kubernetes resources, and the data it contains can be used by Pods or other components within the cluster.

ManiFest:

YAML snippet is a Kubernetes manifest for creating a Pod with a volume. Lets break it down:

yamlCopy code
apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
    - name: nginx-container
      image: nginx
      volumeMounts:
        - name: example-volume
          mountPath: /usr/share/nginx/html
  volumes:
    - name: example-volume
      emptyDir: {}

• apiVersion: v1: This field specifies the Kubernetes API version you are using. In this case, its "v1," which is the stable API version for basic objects like Pods.

• kind: Pod: The "kind" field defines the type of Kubernetes resource you want to create. Here, its a Pod.

• metadata: This section contains metadata about the Pod, including its name.

  • name: example-pod: This sets the name of the Pod to "example-pod."

• spec: The "spec" section describes the desired state of the Pod.

  • containers: This is an array where you define the containers running inside the Pod.

    • name: nginx-container: Specifies the name of the container within the Pod, in this case, "nginx-container."

    • image: nginx: Specifies the container image to use for the "nginx-container." In this example, its using the official Nginx image from Docker Hub.

    • volumeMounts: Describes how volumes are mounted into the container.

      • name: example-volume: Specifies the name of the volume. This name corresponds to the volume defined in the "volumes" section.

      • mountPath: /usr/share/nginx/html: Specifies the path within the container where the volume should be mounted.

  • volumes: Describes the volumes to be used by the Pod.

    • name: example-volume: Specifies the name of the volume, which must match the name used in the "volumeMounts" section.

    • emptyDir: {}: Defines an emptyDir volume type. An emptyDir volume is initially empty and is created when a Pod is assigned to a node. It exists as long as that Pod is running on that node.

This Pod configuration creates an Nginx container and mounts an emptyDir volume named "example-volume" at the path "/usr/share/nginx/html" within the container. The emptyDir volume is created when the Pod is scheduled to a node and is accessible to the container for the duration of the Pods lifecycle on that node. Any data written to this volume is ephemeral and will be lost if the Pod is rescheduled or deleted.

Ingress:

YAML snippet is a Kubernetes manifest for creating an Ingress resource. Lets break it down:

yamlCopy code
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: example-service
                port:
                  number: 80

• apiVersion: networking.k8s.io/v1: This field specifies the Kubernetes API version you are using. In this case, its "networking.k8s.io/v1," which is the API version for Ingress resources.

• kind: Ingress: The "kind" field defines the type of Kubernetes resource you want to create. Here, its an Ingress.

• metadata: This section contains metadata about the Ingress, including its name.

  • name: example-ingress: This sets the name of the Ingress to "example-ingress."

• spec: The "spec" section describes the desired state of the Ingress.

  • rules: Describes the rules for routing incoming requests.

    • host: example.com: Specifies the host for which the Ingress rules should apply. In this case, its "example.com."

    • http: Describes the HTTP configuration for the specified host.

      • paths: Describes the path-based routing configuration.

        • path: /: Specifies that requests with a path of "/" should match this rule.

        • pathType: Prefix: Specifies the type of path matching. "Prefix" means that requests with paths that match the specified prefix ("/") should be routed.

        • backend: Specifies the backend service to which requests should be forwarded.

          • service:
            • name: example-service: Specifies the name of the backend service, in this case, "example-service."
            • port: number: 80: Specifies the port number on the backend service to which requests should be forwarded.

This Ingress configuration is defining a rule for the host "example.com" such that requests with the path "/" (or any path starting with "/") will be routed to the backend service named "example-service" on port 80. Ingress resources are commonly used for exposing HTTP and HTTPS routes to services within a Kubernetes cluster.