Uncovering the Good Stuff: Why DevOps Is Awesome

 

Uncovering the Good Stuff: Why DevOps Is Awesome

DevOps has revolutionized the way companies deliver software, blending development and operations into a seamless workflow that empowers teams, improves efficiency, and accelerates innovation. But what exactly makes DevOps so awesome? Let's dig into the benefits and see why organizations around the world are embracing it.

1. Faster Delivery and Innovation

One of the most exciting aspects of DevOps is its ability to speed up software delivery. By automating processes, improving communication between teams, and enabling continuous integration and continuous delivery (CI/CD), DevOps lets companies ship code faster without sacrificing quality. Here’s why:

• Shorter Development Cycles: DevOps eliminates bottlenecks between development and operations, allowing for quicker iterations. Teams can continuously build, test, and deploy, bringing new features to market faster.

• Continuous Feedback: With rapid deployments, user feedback is received sooner, allowing teams to make real-time improvements and adapt to changing customer needs.

• Increased Agility: By embracing automation and agile methodologies, teams can quickly respond to market trends, technological shifts, or customer demands. This leads to quicker releases and a competitive edge in the market.

2. Higher Quality Products

Speed is great, but only if it doesn’t compromise quality—and that’s where DevOps truly shines. Automation, testing, and monitoring ensure that teams can move fast while maintaining product integrity.

• Automated Testing: With DevOps, testing happens early and often through CI pipelines, catching bugs and issues before they reach production. This leads to more reliable, bug-free releases.

• Continuous Monitoring: Tools like Prometheus, Grafana, and ELK (Elasticsearch, Logstash, Kibana) continuously monitor applications for issues. This proactive monitoring allows teams to catch and fix problems before users are affected.

• Better Collaboration: Since DevOps brings teams together, there’s less finger-pointing and more focus on delivering high-quality products. Shared responsibility leads to improved testing, better code reviews, and ultimately more stable software.

3. Automation: The Secret Sauce

If there’s one thing that makes DevOps awesome, it’s automation. Repetitive, manual tasks can slow teams down and introduce errors. Automating these tasks ensures consistency, frees up valuable time, and allows teams to focus on innovation.

• CI/CD Pipelines: Continuous integration ensures that every change to the code is automatically tested, while continuous delivery means that tested code can be deployed to production anytime. This allows for "push-button" releases and fewer surprises in production.

• Infrastructure as Code (IaC): Tools like Terraform and AWS CloudFormation allow infrastructure to be treated like software. By automating the provisioning of servers, databases, and networks, teams can scale applications quickly and with minimal manual intervention.

• Automated Security: Security checks can be automated as part of the DevOps pipeline, making it easier to spot vulnerabilities early. Tools like Snyk and HashiCorp Vault ensure security is embedded in the development process, not an afterthought.

4. Collaboration and Teamwork

DevOps isn’t just about tools—it’s about creating a culture where collaboration thrives. In traditional settings, development and operations teams worked in silos, which often led to inefficiencies and miscommunication. DevOps flips this model by encouraging cross-team collaboration.

• Shared Responsibility: DevOps teams are responsible for the entire lifecycle of a product, from development to deployment and beyond. This shared accountability fosters a sense of ownership and ensures that teams are invested in delivering high-quality products.

• Cross-functional Teams: DevOps encourages forming cross-functional teams where developers, operations, security, and quality assurance work closely together. This reduces handoff delays, enhances knowledge sharing, and accelerates problem-solving.

• Better Communication: DevOps uses collaboration tools like Slack, Zoom, and Jira to keep everyone on the same page. Frequent check-ins, standups, and retrospectives help teams stay aligned and focused on common goals.

5. Increased Stability and Reliability

DevOps makes it possible to release faster, but it also improves the stability of systems through constant monitoring, automated rollback mechanisms, and thorough testing. This means fewer outages and smoother deployments.

• Version Control and Rollbacks: Version control ensures every change can be tracked, and if something goes wrong in production, automated rollback processes can restore the system to a previous, stable state.

• Frequent, Smaller Releases: Instead of pushing large updates all at once, DevOps encourages small, frequent releases, which are easier to manage and monitor. If something goes wrong, it’s easier to pinpoint and fix the issue quickly.

• Resilience Through Automation: Automated backups, failover systems, and containerization (like Docker and Kubernetes) ensure that applications can recover quickly from failures. This minimizes downtime and ensures higher availability.

6. Cost Efficiency

While DevOps does require investment in tools and training, it saves money in the long run by reducing inefficiencies, lowering downtime, and allowing teams to do more with less.

• Less Manual Work: Automation reduces the need for manual intervention, freeing up your teams to focus on high-impact work rather than repetitive tasks.

• Fewer Downtimes: With real-time monitoring, automated testing, and fast rollbacks, issues are caught and resolved early, preventing costly outages.

• Optimized Resources: DevOps tools enable dynamic resource management, where infrastructure can automatically scale based on demand. This helps organizations avoid over-provisioning and underutilizing resources.

7. Happier Teams

Finally, DevOps creates a more enjoyable working environment. With fewer bottlenecks, less repetitive work, and more autonomy, teams are generally happier and more productive.

• Less Burnout: Automation takes care of many mundane tasks, so teams can focus on solving problems and building new features rather than fighting fires.

• Empowerment: DevOps empowers teams to take full control over the development lifecycle, fostering creativity and innovation.

• Continuous Learning: DevOps promotes a learning culture, encouraging teams to experiment, fail fast, and learn from mistakes. This keeps things exciting and helps build a mindset of growth and improvement.

Conclusion

DevOps is awesome because it transforms how teams work, delivering faster releases, higher quality products, and a more collaborative culture. By embracing automation, breaking down silos, and focusing on continuous improvement, companies can achieve faster innovation, better customer satisfaction, and more resilient systems—all while keeping teams motivated and engaged.

How to Setup Self-Hosted Linux Docker Build Agent in Azure DevOps | How to configure Self-Hosted Linux Docker Agents in Azure Pipelines | Create Custom Build Agents in Azure DevOps

 Setting up a self-hosted Linux Docker build agent in Azure DevOps involves several steps. You’ll be configuring a Linux machine to run Docker containers that act as build agents for Azure Pipelines. Here’s a comprehensive guide to help you through the process:

1. Prepare Your Linux Machine

1. Install Docker:

   • Update the package index:

     
     sudo apt-get update
     

   • Install Docker:

     
     sudo apt-get install -y docker.io
     

   • Start and enable Docker service:

     
     sudo systemctl start docker
     sudo systemctl enable docker
     

   • Verify Docker installation:

     
     docker --version
     

2. Install Docker Compose (Optional):

   • Download Docker Compose:

     
     sudo curl -L "https://github.com/docker/compose/releases/download/$(curl -s https://api.github.com/repos/docker/compose/releases/latest | grep tag_name | cut -d '"' -f 4)/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
     

   • Apply for executable permissions:

     
     sudo chmod +x /usr/local/bin/docker-compose
     

   • Verify Docker Compose installation:

     
     docker-compose --version
     

2. Set Up Azure DevOps Self-Hosted Agent

1. Create a Personal Access Token (PAT):

   • Go to your Azure DevOps organization in your browser.
   • Navigate to User Settings > Personal Access Tokens.
   • Click on New Token and create a token with the appropriate scopes, typically including "Agent Pools (read, manage)".

2. Download and Configure the Agent:

   • Go to Project Settings in your Azure DevOps project.
   • Navigate to Agent Pools and create a new pool if needed.
   • Click on the pool, then click New Agent.
   • Select Linux as the agent type.
   • Download the agent package:

     
     mkdir myagent && cd myagent
     curl -O https://vstsagentpackage.azureedge.net/agent/2.206.0/vsts-agent-linux-x64-2.206.0.tar.gz
     

   • 

   • Extract the agent package:

     tar zxvf vsts-agent-linux-x64-2.206.0.tar.gz
     

   • 

   • Configure the agent:

     ./config.sh
     

     • Provide your Azure DevOps URL and PAT when prompted.
     • Choose the agent pool you created.
     • Set the agent name.
     • Confirm the agent configuration.

3. Run the Agent:

   • Start the agent:

     ./run.sh

   • Optionally, configure the agent as a service to start automatically:

     sudo ./svc.sh install
     sudo ./svc.sh start
     

3. Set Up Docker-Based Builds

1. Create a Dockerfile for the Build Agent:

   • Example Dockerfile:

     
     FROM mcr.microsoft.com/dotnet/sdk:7.0 AS build
     
     # Install necessary tools (example: git, curl, etc.)
     RUN apt-get update && \
         apt-get install -y git curl
     
     # Create a non-root user
     RUN useradd -m builduser
     USER builduser
     
     # Set up the working directory
     WORKDIR /build
     
     # Set up any necessary environment variables
     ENV PATH="/build:${PATH}"
     

2. Build and Push the Docker Image:

   • Build the Docker image:

     
     docker build -t my-build-agent:latest .
     

   • Push the image to a Docker registry (e.g., Docker Hub or Azure Container Registry):

     
     docker tag my-build-agent:latest <your-registry>/my-build-agent:latest
     docker push <your-registry>/my-build-agent:latest
     

3. Configure the Build Pipeline:

   • In Azure DevOps, create or edit a pipeline.
   • Use the Docker image in the pipeline configuration:

     
     pool:
       vmImage: 'ubuntu-latest'
     
     containers:
       - container: mybuild
         image: <your-registry>/my-build-agent:latest
     
     steps:
       - script: echo "Running in container"
         displayName: 'Run a one-line script'
     

4. Test Your Setup

• Create a sample pipeline to test if your self-hosted agent is correctly picking up and running jobs.
• Verify that builds are successfully executed and that your Docker-based agent is functioning as expected.

By following these steps, you'll have a self-hosted Linux Docker build agent running in Azure DevOps, which can help you manage and scale your build infrastructure effectively.

DevOps Culture, Teamwork, and Automation

Getting Friendly with DevOps Culture, Teamwork, and Automation

In today's fast-paced technology landscape, businesses need to deliver software quickly, reliably, and at scale. DevOps is the key to achieving this goal, blending development (Dev) and operations (Ops) through culture, teamwork, and automation. Let's dive into how organizations can embrace DevOps by focusing on these core elements.

1. DevOps Culture: The Foundation

DevOps is not just about tools and processes—it's about a cultural shift. The traditional divide between development and operations teams leads to delays, miscommunication, and a slower release cycle. DevOps culture eliminates this by fostering collaboration and shared ownership. Some key cultural principles include:

• Collaboration: Developers, operations, and other stakeholders (like QA and security) work closely together from the planning phase to deployment. Open communication ensures that everyone is on the same page.

• Shared Responsibility: Instead of blaming other teams when issues arise, a DevOps culture encourages teams to take collective responsibility for both the code and the infrastructure it runs on.

• Continuous Learning: DevOps thrives on constant improvement. Regular feedback loops, post-mortems, and retrospectives help teams learn from failures and innovate.

• Blameless Environment: In a DevOps setting, when things go wrong, the focus is on learning from mistakes, not blaming individuals. This helps build trust and encourages teams to experiment.

2. Teamwork: Breaking Down Silos

Teamwork is at the heart of DevOps. It breaks down the "silos" that have traditionally separated development, operations, and other departments. Here's how teamwork thrives in a DevOps setup:

• Cross-functional Teams: DevOps teams are often cross-functional, meaning they include developers, testers, operations staff, and sometimes even product managers. This reduces bottlenecks and ensures a seamless flow from development to deployment.

• Agile and Scrum Practices: Many DevOps teams adopt agile methodologies like Scrum or Kanban. This allows for quick iterations and adjustments, keeping teams aligned and adaptive to changes in the software lifecycle.

• Communication Tools: Tools like Slack, Microsoft Teams, and project management platforms (Jira, Trello) make communication and coordination smoother. Continuous integration tools like Jenkins and CI/CD pipelines allow everyone to track progress.

• Empowerment: DevOps empowers teams to take ownership of their projects, from development to deployment. Developers aren’t just responsible for coding; they also monitor and support the systems in production.

3. Automation: Streamlining Processes

Automation is one of the cornerstones of DevOps. It reduces human error, speeds up processes, and ensures consistent and reliable software releases. Key areas of automation include:

• Continuous Integration (CI): CI is the practice of merging code changes into a shared repository frequently. Automated testing runs with each code change, catching errors early and ensuring that code is always in a deployable state.

• Continuous Delivery (CD): Continuous delivery takes CI a step further. With CD, code is automatically tested and prepared for release to production. This allows teams to deploy new features and fixes more rapidly.

• Infrastructure as Code (IaC): IaC allows infrastructure (e.g., servers, networks, databases) to be managed with code. Tools like Terraform, AWS CloudFormation, or Ansible automate the creation, management, and scaling of infrastructure, eliminating manual configuration.

• Monitoring and Alerting: DevOps relies on automation not just in the deployment process but also in monitoring and alerting. Tools like Prometheus, Grafana, and Datadog ensure that systems are constantly monitored, with alerts generated for any abnormal behavior.

Benefits of Embracing DevOps Culture, Teamwork, and Automation

• Faster Time to Market: DevOps practices shorten the software development lifecycle, allowing for quicker releases and updates.

• Increased Collaboration: Teams work together rather than in isolation, which reduces miscommunication and bottlenecks.

• Higher Quality Releases: Automated testing and CI/CD pipelines ensure that issues are caught earlier, leading to more stable and reliable releases.

• Better Customer Satisfaction: With faster, more reliable releases, companies can respond to customer needs quickly and effectively.

Conclusion

DevOps is a transformative approach that brings together culture, teamwork, and automation to streamline software delivery and improve collaboration between development and operations. By embracing these principles, organizations can achieve faster delivery cycles, reduce errors, and foster a culture of shared responsibility and continuous improvement.

Kubernetes objects with practical examples

 

1. Pod

• Example: Suppose you have a simple web application with a single container.

• Definition: A Pod could be defined as follows:

  
  apiVersion: v1
  kind: Pod
  metadata:
    name: my-web-app
  spec:
    containers:
      - name: web-container
        image: nginx:latest
        ports:
          - containerPort: 80
  

• Explanation: This Pod definition runs an Nginx container, exposing port 80.

2. Service

• Example: To expose the my-web-app Pod so it can be accessed from other Pods or externally.

• Definition: A Service could be defined as follows:

  
  apiVersion: v1
  kind: Service
  metadata:
    name: my-web-service
  spec:
    selector:
      app: my-web-app
    ports:
      - protocol: TCP
        port: 80
        targetPort: 80
    type: LoadBalancer
  

• Explanation: This Service targets Pods with the label app: my-web-app and exposes port 80. The LoadBalancer type will provision an external IP address (if supported by the cloud provider).

3. Deployment

• Example: To deploy multiple replicas of your my-web-app Pod and manage updates.

• Definition: A Deployment could be defined as follows:

  
  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: my-web-deployment
  spec:
    replicas: 3
    selector:
      matchLabels:
        app: my-web-app
    template:
      metadata:
        labels:
          app: my-web-app
      spec:
        containers:
          - name: web-container
            image: nginx:latest
            ports:
              - containerPort: 80
  

• Explanation: This Deployment manages three replicas of my-web-app, ensuring high availability and managing updates seamlessly.

4. ReplicaSet

• Example: The ReplicaSet is usually managed by a Deployment, but you can define it directly as follows:

  
  apiVersion: apps/v1
  kind: ReplicaSet
  metadata:
    name: my-web-replicaset
  spec:
    replicas: 3
    selector:
      matchLabels:
        app: my-web-app
    template:
      metadata:
        labels:
          app: my-web-app
      spec:
        containers:
          - name: web-container
            image: nginx:latest
            ports:
              - containerPort: 80
  

• Explanation: This ReplicaSet ensures that three Pods with the label app: my-web-app are running at all times.

5. StatefulSet

• Example: For a database application where each instance needs a stable identity and persistent storage.

• Definition: A StatefulSet could be defined as follows:

  
  apiVersion: apps/v1
  kind: StatefulSet
  metadata:
    name: my-db-statefulset
  spec:
    serviceName: "my-db-service"
    replicas: 3
    selector:
      matchLabels:
        app: my-database
    template:
      metadata:
        labels:
          app: my-database
      spec:
        containers:
          - name: db-container
            image: postgres:latest
            ports:
              - containerPort: 5432
            volumeMounts:
              - name: db-storage
                mountPath: /var/lib/postgresql/data
    volumeClaimTemplates:
      - metadata:
          name: db-storage
        spec:
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 1Gi
  

• Explanation: This StatefulSet manages three instances of a PostgreSQL database, each with its own persistent storage.

6. DaemonSet

• Example: To ensure a logging agent runs on every node.

• Definition: A DaemonSet could be defined as follows:

  
  apiVersion: apps/v1
  kind: DaemonSet
  metadata:
    name: log-collector
  spec:
    selector:
      matchLabels:
        app: log-collector
    template:
      metadata:
        labels:
          app: log-collector
      spec:
        containers:
          - name: log-agent
            image: fluentd:latest
            volumeMounts:
              - name: varlog
                mountPath: /var/log
        volumes:
          - name: varlog
            hostPath:
              path: /var/log
  

• Explanation: This DaemonSet ensures that the log-agent container runs on every node, collecting logs from /var/log.

7. Job

• Example: To run a database migration task that needs to complete successfully.

• Definition: A Job could be defined as follows:

  
  apiVersion: batch/v1
  kind: Job
  metadata:
    name: db-migration-job
  spec:
    template:
      spec:
        containers:
          - name: migration
            image: my-migration-tool:latest
            command: ["./migrate.sh"]
        restartPolicy: OnFailure
  

• Explanation: This Job runs a migration script to completion, restarting only if it fails.

8. CronJob

• Example: To schedule a task to back up a database every day at midnight.

• Definition: A CronJob could be defined as follows:

  
  apiVersion: batch/v1
  kind: CronJob
  metadata:
    name: daily-db-backup
  spec:
    schedule: "0 0 * * *"
    jobTemplate:
      spec:
        template:
          spec:
            containers:
              - name: backup
                image: my-backup-tool:latest
                command: ["./backup.sh"]
            restartPolicy: OnFailure
  

• Explanation: This CronJob schedules a backup job to run every day at midnight.

9. ConfigMap

• Example: To provide configuration settings for your application.

• Definition: A ConfigMap could be defined as follows:

  
  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: app-config
  data:
    APP_MODE: "production"
    LOG_LEVEL: "info"
  

• Explanation: This ConfigMap provides configuration data that can be consumed by Pods.

10. Secret

• Example: To store sensitive information like a database password.

• Definition: A Secret could be defined as follows:

  
  apiVersion: v1
  kind: Secret
  metadata:
    name: db-secret
  type: Opaque
  data:
    db-password: c2VjcmV0cGFzc3dvcmQ=  # Base64 encoded 'secretpassword'
  

• Explanation: This Secret stores a base64-encoded password that can be used by Pods.

11. Namespace

• Example: To create an isolated environment for different teams.

• Definition: A Namespace could be defined as follows:

  
  apiVersion: v1
  kind: Namespace
  metadata:
    name: dev-environment
  

• Explanation: This Namespace isolates resources for a development environment.

12. PersistentVolume (PV) and PersistentVolumeClaim (PVC)

• Example: To manage persistent storage for your application.

• PersistentVolume Definition:

  
  apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: pv-example
  spec:
    capacity:
      storage: 5Gi
    accessModes:
      - ReadWriteOnce
    hostPath:
      path: /mnt/data
  

• PersistentVolumeClaim Definition:

  
  apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    name: pvc-example
  spec:
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 5Gi
  

• Explanation: The PV provides storage, and the PVC requests that storage. When bound, Pods can use the PVC to access the PV.

13. Ingress

• Example: To route traffic to different services based on the URL.

• Definition: An Ingress could be defined as follows:

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

• Explanation: This Ingress routes requests to different services based on the path (/api to api-service, and / to web-service).

Each of these objects helps in managing different aspects of a Kubernetes deployment, making it easier to handle complex containerized applications and services.

Kubernetes objects - Roles

 Kubernetes is a powerful container orchestration platform that helps manage and automate the deployment, scaling, and operation of application containers. It uses several key objects to achieve this, each serving a specific purpose. Here’s a rundown of some of the most important Kubernetes objects and their roles:

1. Pod

• Definition: The smallest and simplest Kubernetes object. A Pod represents a single instance of a running process in your cluster.
• Details: A Pod can contain one or more containers that share the same network namespace and storage volumes. Containers within a Pod can communicate with each other using localhost.

2. Service

• Definition: A Service is an abstraction that defines a logical set of Pods and a policy by which to access them.
• Details: Services enable communication between different parts of your application or with external applications. They provide load balancing and service discovery by assigning a stable IP address and DNS name to the set of Pods.

3. Deployment

• Definition: A Deployment is a higher-level abstraction that manages a ReplicaSet and provides declarative updates to Pods and ReplicaSets.
• Details: Deployments ensure that a specified number of Pods are running at any given time. They manage rolling updates, rollbacks, and scaling.

4. ReplicaSet

• Definition: A ReplicaSet ensures that a specified number of Pod replicas are running at any given time.
• Details: ReplicaSets are often used by Deployments to manage scaling and self-healing of Pods. If a Pod fails, the ReplicaSet will create a new Pod to replace it.

5. StatefulSet

• Definition: StatefulSets are used for applications that require stable, unique network identifiers and stable storage.
• Details: StatefulSets are ideal for applications like databases where each instance needs to maintain its own identity and state. They provide unique, stable network identities and persistent storage.

6. DaemonSet

• Definition: A DaemonSet ensures that a copy of a Pod runs on all (or some) nodes in the cluster.
• Details: DaemonSets are typically used for system-level or node-level applications such as log collection or monitoring agents.

7. Job

• Definition: A Job creates one or more Pods and ensures that a specified number of them successfully terminate.
• Details: Jobs are used for batch processing or short-lived tasks that need to complete successfully. Once the Job completes its task, the Pods it created are terminated.

8. CronJob

• Definition: A CronJob creates Jobs on a scheduled time-based pattern, similar to cron jobs in Unix-like systems.
• Details: CronJobs are useful for running tasks periodically, like backups or data processing, on a schedule.

9. ConfigMap

• Definition: A ConfigMap provides a way to inject configuration data into Pods.
• Details: ConfigMaps allow you to separate configuration from application code and manage it independently. Configuration data can be injected into Pods as environment variables, command-line arguments, or configuration files.

10. Secret

• Definition: Secrets are used to store sensitive data such as passwords, OAuth tokens, or SSH keys.
• Details: Secrets help keep sensitive information secure by encoding it in base64 and managing it through Kubernetes' API. They can be used in Pods similarly to ConfigMaps but with additional security.

11. Namespace

• Definition: A Namespace is a virtual cluster within a Kubernetes cluster that provides a scope for names.
• Details: Namespaces are useful for dividing resources between multiple users or teams, providing isolation and resource management.

12. PersistentVolume (PV) and PersistentVolumeClaim (PVC)

• Definition: PVs and PVCs are used to manage storage in Kubernetes.
• Details:
  • PersistentVolume (PV): Represents a piece of storage in the cluster.
  • PersistentVolumeClaim (PVC): Represents a request for storage by a user. PVCs are bound to PVs that meet their requirements.

13. Ingress

• Definition: An Ingress provides HTTP and HTTPS routing to services within the cluster.
• Details: It manages access to services based on URL paths or hostnames and is often used for load balancing and SSL termination.

Each of these objects plays a critical role in the functioning of a Kubernetes cluster, helping to manage various aspects of containerized applications and services.

Kubernetes object

 Kubernetes is a powerful container orchestration platform that uses various objects to manage the deployment, scaling, and operation of application containers. Here’s a step-by-step guide to some of the key Kubernetes objects with examples:

1. Pod

A Pod is the smallest and simplest Kubernetes object. It represents a single instance of a running process in your cluster.

Example:

Create a file named pod-example.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx:latest
    ports:
    - containerPort: 80

Commands:

kubectl apply -f pod-example.yaml
kubectl get pods
kubectl describe pod my-pod

2. Service

A Service is an abstraction that defines a logical set of Pods and a policy by which to access them. This can be used to expose your application.

Example:

Create a file named service-example.yaml:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

Commands:

kubectl apply -f service-example.yaml
kubectl get services
kubectl describe service my-service

3. Deployment

A Deployment provides declarative updates to Pods and ReplicaSets. It manages the deployment of Pods and ensures the desired state is maintained.

Example:

Create a file named deployment-example.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: nginx:latest
        ports:
        - containerPort: 80

Commands:

kubectl apply -f deployment-example.yaml
kubectl get deployments
kubectl describe deployment my-deployment

4. ReplicaSet

A ReplicaSet ensures that a specified number of pod replicas are running at any given time. Deployments manage ReplicaSets and Pods.

Example:

Create a file named replicaset-example.yaml:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-replicaset
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: nginx:latest
        ports:
        - containerPort: 80

Commands:

kubectl apply -f replicaset-example.yaml
kubectl get replicasets
kubectl describe replicaset my-replicaset

5. StatefulSet

A StatefulSet is used for managing stateful applications. It provides guarantees about the ordering and uniqueness of Pods.

Example:

Create a file named statefulset-example.yaml:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: my-statefulset
spec:
  serviceName: "my-service"
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: nginx:latest
        ports:
        - containerPort: 80

Commands:

kubectl apply -f statefulset-example.yaml
kubectl get statefulsets
kubectl describe statefulset my-statefulset

6. ConfigMap

A ConfigMap allows you to separate configuration artifacts from image content to keep containerized applications portable.

Example:

Create a file named configmap-example.yaml:

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-configmap
data:
  my-key: my-value

Commands:

kubectl apply -f configmap-example.yaml
kubectl get configmaps
kubectl describe configmap my-configmap

7. Secret

A Secret is used to store and manage sensitive information, such as passwords, OAuth tokens, and ssh keys.

Example:

Create a file named secret-example.yaml:

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  my-key: bXktdmFsdWU= # base64 encoded value of "my-value"

Commands:

kubectl apply -f secret-example.yaml
kubectl get secrets
kubectl describe secret my-secret

8. Namespace

A Namespace provides a mechanism for isolating groups of resources within a single cluster.

Example:

Create a file named namespace-example.yaml:

apiVersion: v1
kind: Namespace
metadata:
  name: my-namespace

Commands:

kubectl apply -f namespace-example.yaml
kubectl get namespaces
kubectl describe namespace my-namespace

9. Ingress

An Ingress manages external access to services, typically HTTP. It provides load balancing, SSL termination, and name-based virtual hosting.

Example:

Create a file named ingress-example.yaml:

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

Commands:

kubectl apply -f ingress-example.yaml
kubectl get ingress
kubectl describe ingress my-ingress

10. Job

A Job creates one or more Pods and ensures that a specified number of them successfully terminate.

Example:

Create a file named job-example.yaml:

apiVersion: batch/v1
kind: Job
metadata:
  name: my-job
spec:
  template:
    spec:
      containers:
      - name: my-container
        image: busybox
        command: ["sh", "-c", "echo Hello Kubernetes! && sleep 30"]
      restartPolicy: OnFailure

Commands:

kubectl apply -f job-example.yaml
kubectl get jobs
kubectl describe job my-job

11. CronJob

A CronJob creates Jobs on a scheduled time, similar to cron in Linux.

Example:

Create a file named cronjob-example.yaml:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: my-cronjob
spec:
  schedule: "*/5 * * * *" # every 5 minutes
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: my-container
            image: busybox
            command: ["sh", "-c", "echo Hello Kubernetes! && sleep 30"]
          restartPolicy: OnFailure

Commands:

kubectl apply -f cronjob-example.yaml
kubectl get cronjobs
kubectl describe cronjob my-cronjob