Declarative Kubernetes Manifests

Kubernetes is widely known for its imperative and declarative management techniques. In the previous exercise, you have deployed the following resources using the imperative approach. Now deploy them using the declarative approach.

• a namespace

• • name: default
• • label: tier: test

• a deployment:

• • image: buinhattruong/techtrends:v1.0.0
• • name: techtrends
• • namespace: default
• • replicas: 3
• • labels: app: techtrends, tag: techtrends

• a service:

• • expose the above deployment on port 8111
• • namespace: default

• a configmap:

• • name: techtrends
• • containing key-value pair: version=techtrends
• • namespace: default

Deployment YAML manifest

In addition to the required sections of a YAML manifest, a Deployment resource covers the configuration of ReplicaSet, RollingOut strategy, and containers. Bellow is a full manifest of a Deployment explaining each parameter:

## Set the API endpoint used to create the Deployment resource.
apiVersion: apps/v1
## Define the type of the resource.
kind: Deployment
## Set the parameters that make the object identifiable, such as its name, namespace, and labels.
metadata:
  annotations:
  labels:
    app: techtrends
  name: techtrends
  namespace: default
## Define the desired configuration for the Deployment resource.
spec:
  ## Set the number of replicas.
  ## This will create a ReplicaSet that will manage 3 pods of the techtrends application.
  replicas: 3
  ## Identify the pods managed by this Deployment using the following selectors.
  ## In this case, all pods with the label `techtrends`.
  selector:
    matchLabels:
      app: techtrends
  ## Set the RollingOut strategy for the Deployment.
  ## For example, roll out only 25% of the new pods at a time.
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  ## Set the configuration for the pods.
  template:
    ## Define the identifiable metadata for the pods.
    ## For example, all pods should have the label `techtrends`
    metadata:
      labels:
        app: techtrends
    ## Define the desired state of the pod configuration.
    spec:
      containers:
        ## Set the image to be executed inside the container and image pull policy
        ## In this case, run the `techtrends` application in version v1.0.0 and
        ## only pull the image if it's not available on the current host.
      - image: buinhattruong/techtrends:v1.0.0
        imagePullPolicy: IfNotPresent
        name: techtrends
        ## Expose the port the container is listening on.
        ## For example, exposing the application port 6112 via TCP.
        ports:
        - containerPort: 6112
          protocol: TCP
        ## Define the rules for the liveness probes.
        ## For example, verify the application on the main route `/`,
        ## on application port 6112. If the application is not responsive, then the pod will be restarted automatically. 
        livenessProbe:
           httpGet:
             path: /
             port: 6112
        ## Define the rules for the readiness probes.
        ## For example, verify the application on the main route `/`,
        ## on application port 6112. If the application is responsive, then traffic will be sent to this pod.
        readinessProbe:
           httpGet:
             path: /
             port: 6112
        ## Set the resource requests and limits for an application.
        resources:
        ## The resource requests guarantees that the desired amount 
        ## CPU and memory is allocated for a pod. In this example, 
        ## the pod will be allocated with 64 Mebibytes and 250 miliCPUs.
          requests:
            memory: "64Mi"
            cpu: "250m"
        ## The resource limits ensure that the application is not consuming 
        ## more than the specified CPU and memory values. In this example, 
        ## the pod will not surpass 128 Mebibytes and 500 miliCPUs.
          limits:
            memory: "128Mi"
            cpu: "500m"

Service YAML manifest

In addition to the required sections of a YAML manifest, a Service resource covers the configuration of service type and ports the service should configure. Bellow is a full manifest of a Service explaining each parameter:

## Set the API endpoint used to create the Service resource.
apiVersion: v1
## Define the type of the resource.
kind: Service
## Set the parameters that make the object identifiable, such as its name, namespace, and labels.
metadata:
  labels:
    app: techtrends
  name: techtrends
  namespace: default
## Define the desired configuration for the Service resource.
spec:
  ## Define the ports that the service should serve on. 
  ## For example, the service is exposed on port 8111, and
  ## directs the traffic to the pods on port 6112, using TCP.
  ports:
  - port: 8111
    protocol: TCP
    targetPort: 6112
  ## Identify the pods managed by this Service using the following selectors.
  ## In this case, all pods with the label `techtrends`.
  selector:
    app: techtrends
  ## Define the Service type, here set to ClusterIP.
  type: ClusterIP

Solution: Declarative Kubernetes Manifests

Declarative Approach

The declarative approach consists of using a full YAML definition of resources. As well, with this approach, you can perform directory level operations.

Examine the manifests for all of the resources in the techtrends/manifests.

To create the resources, use the following command:

kubectl apply -f techtrends/manifests/

To inspect all the resources within the namespace, use the following command:

kubectl get all -n default