tutorial-module-11

Tutorial: Hello Minikube

1. Compare the application logs before and after you exposed it as a Service. Try to open the app several times while the proxy into the Service is running. What do you see in the logs? Does the number of logs increase each time you open the app?

   Before exposing the application as a service, we might have primarily seen logs related to the application itself running within the Docker container. These logs could include startup messages, any errors or warnings encountered during execution, and any other relevant information generated by the application.

   After exposing the application as a service and accessing it through a proxy running in Minikube via kubectl, the logs would likely show additional activity related to network communication and requests being handled by the service. Each time the app is opened through the proxy, there would be an increase in the number of logs reflecting incoming requests, the processing of those requests by the service, and any responses sent back to the client.

   The number of logs would indeed increase each time we open the app, as each interaction triggers logging activity in response to incoming requests and their processing by the service. This increase in logs provides a clear indication of the service's activity and its responsiveness to client requests.

2. Notice that there are two versions of kubectl get invocation during this tutorial section.The first does not have any option, while the latter has -n option with value set to kube-system. What is the purpose of the -n option and why did the output not list the pods/services that you explicitly created?

   The -n option in kubectl get is used to specify the namespace in which to list resources. A Kubernetes namespace provides a way to logically partition cluster resources and allows multiple users or teams to share the same cluster without interfering with each other. When there is no namespace specified, kubectl typically defaults to the default namespace.

   In the tutorial, the first kubectl get invocation did not include the -n option, so it listed resources from the default namespace, which may not have included the resources we explicitly created if we created them in a different namespace.

   The second kubectl get invocation included the -n option with the value set to kube-system, so it listed resources specifically from the kube-system namespace. This namespace typically contains Kubernetes system components and infrastructure-related resources.

   If we explicitly created pods and services in a different namespace, we would need to specify that namespace using the -n option in kubectl get to see those resources listed in the output. For example:

   kubectl get pods,services -n <namespace>
   

   Replace <namespace> with the name of the namespace where we created the resources. This will list pods and services specifically from that namespace. If we created resources in the default namespace and want to see them, we can simply omit the -n option, as resources from the default namespace are listed by default.

Tutorial: Rolling Update Deployment

1. What is the difference between Rolling Update and Recreate deployment strategy?

   Rolling Update and Recreate are two different deployment strategies in Kubernetes, each with its own characteristics and use cases:

   • Rolling Update:

     • Strategy: Rolling Update performs a rolling update of the pods in a deployment. It gradually replaces old pods with new ones, ensuring that there is no downtime during the update process.
     • Process: Rolling Update deploys new pods incrementally while gradually scaling down the old pods. It monitors the health of the new pods before scaling down the old ones, ensuring that the application remains available and responsive throughout the update.
     • Benefits:
       • Zero downtime: Rolling Update ensures that the application remains available to users throughout the update process.
       • Controlled deployment: Updates are applied gradually, allowing for monitoring and validation of the new pods before fully transitioning to the new version.
     • Drawbacks:
       • Longer deployment time: Rolling Update may take longer to complete compared to Recreate, especially for large deployments, as it deploys updates gradually.

   • Recreate:

     • Strategy: Recreate simply terminates all existing pods and creates new ones with the updated configuration. It effectively stops the old version of the application and starts the new version all at once.
     • Process: Recreate terminates all existing pods in the deployment before creating new ones with the updated configuration. This results in a brief period of downtime during the update process.
     • Benefits:
       • Simplicity: Recreate is a straightforward deployment strategy that stops the old version and starts the new version, making it easy to understand and implement.
       • Predictable behavior: Recreate ensures that the application is fully updated once the deployment process completes.
     • Drawbacks:
       • Downtime: Recreate results in a brief period of downtime during the update process, as all existing pods are terminated before new ones are created.
       • Potential impact on users: Depending on the application's requirements, downtime during updates may not be acceptable for some users or applications.

   In summary, Rolling Update is preferred for deployments that require zero downtime and gradual updates, while Recreate may be suitable for simpler deployments where a brief period of downtime is acceptable or when updates need to be applied quickly and predictably.

2. Try deploying the Spring Petclinic REST using Recreate deployment strategy and document your attempt.

   Here are the detailed steps to deploy the Spring Petclinic REST application on Minikube using the Recreate deployment strategy:

   1. Start Minikube: Start Minikube with the following command:

      minikube start

      This command will start a local Kubernetes cluster using Minikube.

   2. Enable Metrics Server: Enable the Metrics Server addon to allow monitoring of resource usage:

      minikube addons enable metrics-server

      This command installs the Metrics Server addon, which collects resource metrics from pods and nodes in the cluster.

   3. Apply recreate-deployment-before.yaml: Apply recreate-deployment-before.yaml to create a Deployment with the following command

      kubectl apply -f recreate-deployment-before.yaml

   4. Apply service.yaml: Apply service.yaml to create a Service that exposes the Deployment created previously with the following command

      kubectl apply -f service.yaml

   5. Update the Deployment: Update the Deployment to use the latest version of spring-petclinic-rest using the Recreate Deployment method by deploying a similar file as recreate-deployment-before.yaml but the image tag is changed to the latest.

      kubectl apply -f recreate-deployment-after.yaml

3. Prepare different manifest files for executing Recreate deployment strategy.

   Here are the manifest files for deploying the Spring Petclinic REST application using the Recreate deployment strategy:

   1. recreate-deployment-before.yaml:

      apiVersion: apps/v1
      kind: Deployment
      metadata:
          labels:
              app: spring-petclinic-rest
          name: spring-petclinic-rest
      spec:
          replicas: 4
          selector:
              matchLabels:
                  app: spring-petclinic-rest
          strategy:
              type: Recreate
          template:
              metadata:
                  labels:
                      app: spring-petclinic-rest
              spec:
                  containers:
                  - image: docker.io/springcommunity/spring-petclinic-rest:3.0.2
                      name: spring-petclinic-rest

   2. service.yaml:

      apiVersion: v1
      kind: Service
      metadata:
      creationTimestamp: "2024-05-11T14:52:39Z"
      labels:
          app: spring-petclinic-rest
      name: spring-petclinic-rest
      namespace: default
      resourceVersion: "3920"
      uid: 45e9aa85-76a3-46a8-869f-9ae953930f82
      spec:
      allocateLoadBalancerNodePorts: true
      clusterIP: 10.102.156.230
      clusterIPs:
      - 10.102.156.230
      externalTrafficPolicy: Cluster
      internalTrafficPolicy: Cluster
      ipFamilies:
      - IPv4
      ipFamilyPolicy: SingleStack
      ports:
      - nodePort: 32697
          port: 9966
          protocol: TCP
          targetPort: 9966
      selector:
          app: spring-petclinic-rest
      sessionAffinity: None
      type: LoadBalancer
      status:
      loadBalancer: {}

   3. recreate-deployment-after.yaml:

      apiVersion: apps/v1
      kind: Deployment
      metadata:
          labels:
              app: spring-petclinic-rest
          name: spring-petclinic-rest
      spec:
          replicas: 4
          selector:
              matchLabels:
                  app: spring-petclinic-rest
          strategy:
              type: Recreate
          template:
              metadata:
                  labels:
                      app: spring-petclinic-rest
              spec:
                  containers:
                  - image: docker.io/springcommunity/spring-petclinic-rest:latest
                      name: spring-petclinic-rest

   These manifest files define a Deployment resource with the name spring-petclinic-rest and a Service resource with the same name. The Deployment resource specifies the Recreate deployment strategy, which recreates all pods when updates are applied. The Service resource exposes the application on port 9966 using a LoadBalancer type service.

   These files can be applied using kubectl apply -f <filename.yaml> command. Adjust the image version or other parameters as needed for specific setup.

4. What do you think are the benefits of using Kubernetes manifest files? Recall your experience in deploying the app manually and compare it to your experience when deploying the same app by applying the manifest files (i.e., invoking kubectl apply -f command) to the cluster.

   Using Kubernetes manifest files provides several benefits:

   1. Infrastructure as Code (IaC): Manifest files allow us to define the application's infrastructure in a declarative manner using code. This makes it easy to version control, track changes, and manage infrastructure configurations alongside application code.

   2. Reproducibility: Manifest files ensure that the deployments are consistent across environments. By defining the desired state of the application in code, we can easily reproduce deployments in different environments, reducing the risk of configuration drift.

   3. Automation: Kubernetes manifest files can be automated using continuous integration and continuous deployment (CI/CD) pipelines. This enables automation of the deployment process, reducing manual intervention and potential errors.

   4. Visibility and Transparency: Manifest files provide a clear and transparent view of the application's configuration. We can easily see the desired state of the application and track changes over time.

   5. Idempotent Operations: Applying manifest files using kubectl apply -f command ensures idempotent operations. Kubernetes reconciles the desired state defined in the manifest files with the current state of the cluster, ensuring that only necessary changes are applied.

   Comparing the experience of deploying an application manually versus using manifest files, deploying with manifest files offers:

   • Consistency: With manifest files, deployments are consistent and reproducible across environments. Manual deployments may lead to discrepancies between environments due to human error or differences in execution.

   • Efficiency: Using manifest files streamlines the deployment process, as we can define all configurations in code and apply them to the cluster with a single command. This reduces the time and effort required for deployment compared to manual steps.

   • Version Control: Manifest files can be version controlled using Git or other version control systems. This allows us to track changes, revert to previous configurations if needed, and collaborate with team members more effectively.

   Overall, using Kubernetes manifest files enhances the deployment process by providing a standardized, automated, and version-controlled approach to managing application infrastructure.