DEV Community: Ravindra Singh

Cross-Account Amazon ECR Image Access from EC2: A Secure IAM-Based Approach

Ravindra Singh — Thu, 04 Dec 2025 12:21:52 +0000

Introduction
In many real-world AWS environments, applications and workloads often run in one AWS account while container images are stored in another. This pattern is common in multi-account setups, enterprises, managed service providers, and vendor-hosted solutions.

A typical example:

Account A (Consumer): Runs EC2 instances or applications
Account B (Source): Hosts container images in Amazon ECR

The challenge:
EC2 instances in Account A cannot directly pull Docker images from ECR in Account B.

👉 To solve this, AWS supports secure cross-account ECR access using IAM Roles + ECR Repository Policies.

Architecture Overview

EC2 instance in Account A assumes an IAM Role
IAM Role has permission to authenticate with ECR
ECR Repository in Account B trusts this IAM role
EC2 logs in → pulls the container image

Step 1: Create IAM Role for EC2 in Account A

You need an IAM Role that your EC2 instance will use.

1.1 Choose EC2 as the trusted entity

During IAM role creation:

Trusted Entity: EC2
“Allows EC2 instances to call AWS services on your behalf”

1.2 Attach the policy below:
🔐 IAM Policy: Allow EC2 to Pull Images from Account B

(This goes into Account A, attached to the EC2 IAM Role)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "GetAuthToken",
            "Effect": "Allow",
            "Action": "ecr:GetAuthorizationToken",
            "Resource": "*"
        },
        {
            "Sid": "PullImages",
            "Effect": "Allow",
            "Action": [
                "ecr:BatchGetImage",
                "ecr:GetDownloadUrlForLayer",
                "ecr:BatchCheckLayerAvailability"
            ],
            "Resource": "arn:aws:ecr:us-east-1:<ACCOUNT_B_ID>:repository/<REPO_NAME>"
        }
    ]
}

Why "Resource": "*" on GetAuthorizationToken?

Because AWS does not support resource-level restrictions for this API.
This is required and safe.

Step 2: Attach the IAM Role to the EC2 instance

EC2 → Instance → Actions → Security → Modify IAM Role → Select your role

Your EC2 is now authorized to pull images — but ECR in Account B must still trust it.

🔐 ECR Repository Policy (Account B → Allows Account A to Pull)

This explicitly tells the ECR repo that the IAM role from Account A is allowed to pull images.

👉 We need to update the ECR repository permissions in Account B.

Step 4: Install Docker & AWS CLI on EC2

If you haven't installed Docker:

For Amazon Linux 3:

sudo yum update -y
sudo yum install -y docker
sudo service docker start
sudo usermod -aG docker ec2-user

Step 5: Authenticate Docker to the Account B ECR

aws ecr get-login-password --region us-east-1 \
| docker login --username AWS \
  --password-stdin <ACCOUNT_B_ID>.dkr.ecr.us-east-1.amazonaws.com

Step 6: Pull the Image

docker pull <ACCOUNT_B_ID>.dkr.ecr.us-east-1.amazonaws.com/<REPO_NAME>:latest

Troubleshooting Checklist
❌ Error: no basic auth credentials

docker login not executed
IAM role missing pull permissions
ECR repo does not trust Account A

❌ Error: access denied

ECR repo policy missing Account A IAM role

❌ Error: repository not found

wrong region
wrong repo name

❌ Error: docker not found

Best Practices

✔ Always use IAM Roles, never access keys
✔ Always restrict pull access using ECR repository policy
✔ Never use wildcard "" for image pull actions
✔ Use "" only for GetAuthorizationToken (required by AWS)
✔ Consider using Lifecycle Policies for cleaning old images
✔ Consider enabling ECR scan-on-push for security

Securely Connect GitHub Actions to AWS Using IAM Roles and OIDC

Ravindra Singh — Fri, 25 Jul 2025 17:24:24 +0000

Introduction

Traditional CI/CD pipelines often rely on long-lived AWS access keys stored as GitHub secrets, which introduces risks such as secret exposure and poor traceability. With GitHub Actions' support for OpenID Connect (OIDC), you can authenticate securely to AWS without static credentials.

Source Code link: https://github.com/ravindrasinghh/github-actions-s3-workshop/blob/master/.github/workflows/deploy-to-s3.yml

we will walk through setting up an automated deployment pipeline that takes your static website from GitHub repository to live S3 hosting with just a git push.

The Problem with Traditional Approaches

Security Challenges with Access Keys:

Long-lived credentials stored in GitHub secrets
Risk of credential exposure if secrets are compromised
Manual rotation required for security compliance
Broad permissions often granted for simplicity
No audit trail of which specific workflow used credentials

The OIDC Solution:

No stored credentials in GitHub
Temporary tokens with automatic expiration
Fine-grained permissions per repository/branch
Complete audit trail of all AWS actions
Principle of least privilege enforcement

How OIDC Works with GitHub Actions and AWS

Authentication Flow:

GitHub Actions requests an OIDC token from GitHub's OIDC provider
Token contains claims about the repository, branch, and workflow
AWS STS validates the token against the configured trust policy
Temporary credentials are issued for the specified IAM role
GitHub Actions uses these credentials to access AWS services

Step-by-Step Implementation

Step 1: Create an OIDC Identity Provider in AWS

1.Open the IAM console in your AWS account.

In the left-hand navigation, click Identity providers.
Choose Add provider.
For Provider type, select OpenID Connect.
For Provider URL, enter: https://token.actions.githubusercontent.com
For Audience, enter: sts.amazonaws.com

Step 2: Assign a Role

Once the OIDC provider is created, click "Assign role" or "Create new role" to configure access.

Click Next to proceed.

Step 3: Configure Web Identity Trust

On the Trusted entity type page, choose Web identity.
For Identity provider, select the one you just created.

Fill in:

GitHub Organization/Username (e.g., ravindrasinghh)
Repository name (e.g., github-actions-s3-workshop)
Branch name (e.g., master)

Click Next.

Step 4: Attach Permissions to the Role

Choose either a Managed policy or create a Custom policy.
For demonstration purposes, can use AmazonS3FullAccess.

⚠️ In production, use least privilege policies instead of full access.

Click Next.

Step 5: Name and Create the Role

Provide a Role name (e.g., GitHubOIDCRole)
Add an optional description for future reference.
Review the trust policy and click Create Role.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::434605749312:oidc-provider/token.actions.githubusercontent.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
                },
                "StringLike": {
                    "token.actions.githubusercontent.com:sub": "repo:ravindrasinghh/github-actions-s3-workshop:ref:refs/heads/master"
                }
            }
        }
    ]
}

This policy ensures:

Only workflows from the ravindrasinghh/argocd repository on the master branch can assume the role.
Only tokens with audience sts.amazonaws.com are accepted.

Key Security Features:

aud condition ensures tokens are intended for AWS STS
sub condition restricts access to specific repository and branch
StringLike allows for flexible branch matching if needed

Step 4: Update GitHub Actions Workflow for OIDC
Update .github/workflows/deploy-to-s3.yml with:

name: Deploy Static Website to S3

on:
  push:
    branches: [ main ]
  workflow_dispatch:  # Allows manual triggering

# OIDC permissions for keyless authentication
permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout repository
      uses: actions/checkout@v3

    # No build step needed for this simple static website
    # Just update the deployment timestamp in the JavaScript file
    - name: Update deployment timestamp
      run: |
        echo "// Updating timestamp for deployment on $(date)" >> js/script.js
        echo "// Deployment ID: ${{ github.run_id }}" >> js/script.js

    # # Configure AWS credentials
    # - name: Configure AWS credentials
    #   uses: aws-actions/configure-aws-credentials@v1
    #   with:
    #     aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
    #     aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
    #     aws-region: "ap-south-1"

    # OIDC/IRSA Authentication - No more access keys!
    - name: Configure AWS credentials via OIDC
      uses: aws-actions/configure-aws-credentials@v4
      with:
        role-to-assume: "arn:aws:iam::434605749312:role/GitHubOIDCRole"
        role-session-name: GitHubActions-Backend-${{ github.run_id }}
        aws-region: "ap-south-1"

    # Deploy to S3 bucket - directly sync the repository contents
    - name: Deploy to S3
      run: |
        aws s3 sync ./ s3://${{ secrets.S3_BUCKET_NAME }}/ \
          --delete \
          --exclude ".git/*" \
          --exclude ".github/*" \
          --exclude "README.md"

Troubleshooting Common Issues

1. "Incorrect token audience" Error

Cause: Trust policy audience mismatch
Solution: Ensure audience is exactly sts.amazonaws.com (no trailing dots)

2. "No permission to assume role" Error

Cause: Trust policy subject condition too restrictive
Solution: Verify repository name and branch in trust policy

3. "OIDC provider not found" Error

Cause: OIDC provider not created or incorrect ARN
Solution: Verify OIDC provider exists and ARN is correct

4. Workflow permissions Error

Cause: Missing OIDC permissions in workflow
Solution: Add id-token: write and contents: read permissions

By using OIDC with IAM roles, you enhance the security posture of your GitHub Actions workflows. This is the modern, recommended way to connect GitHub to AWS — eliminating the risks of leaked secrets and manual credential management.

Automating Static Website Deployment with GitHub Actions and AWS S3

Ravindra Singh — Wed, 23 Jul 2025 05:42:18 +0000

Introduction

In today's fast-paced development environment, automating your deployment process is no longer a luxury—it's a necessity. Continuous Integration and Continuous Deployment (CI/CD) has become the industry standard for delivering software efficiently and reliably. In this blog post, I'll walk you through setting up a complete CI/CD pipeline using GitHub Actions to automatically deploy a static website to Amazon S3.

Why CI/CD Matters

Before diving into the technical details, let's understand why CI/CD is so important:

Faster Delivery: Automate repetitive tasks to release features more quickly
Higher Quality: Catch bugs early through automated testing
Reduced Risk: Small, incremental changes are easier to troubleshoot
Consistency: Every deployment follows the same process
Developer Focus: Less time on operations means more time for coding

For static websites specifically, a CI/CD pipeline ensures that every change you push to your repository is automatically tested and deployed, eliminating manual FTP uploads or console interactions.

The Architecture

Our CI/CD pipeline follows this simple flow:

Developer pushes code to GitHub repository
GitHub Actions detects the change and triggers a workflow
The workflow builds and tests the website
If successful, the workflow deploys the site to AWS S3
The website is immediately available to visitors

This architecture provides several benefits:

Scalability: S3 can handle virtually unlimited traffic
Cost-Effective: Pay only for what you use
Reliable: AWS's infrastructure ensures high availability
Secure: Access controls and encryption protect your content

Source Git Link: https://github.com/ravindrasinghh/github-actions-s3-workshop/tree/master

Prerequisites

To follow along with this tutorial, you'll need:

A GitHub account
An AWS account
Basic understanding of HTML, CSS, and JavaScript
Familiarity with Git commands

Step 1: Setting Up Your S3 Bucket

First, we need to create an S3 bucket configured for static website hosting:

Log in to the AWS Management Console and navigate to S3
Click "Create bucket"
Enter a globally unique name for your bucket
Choose your preferred region
Uncheck "Block all public access" (since this is a public website)
Enable "Static website hosting" under the Properties tab
Set "index.html" as both the index and error document
Add a bucket policy to allow public read access:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::your-bucket-name/*"
        }
    ]
}

Step 2: Creating IAM Credentials

For GitHub Actions to access your S3 bucket, you'll need IAM credentials:

Navigate to IAM in the AWS Console
Create a new policy with the following permissions:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucket",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::your-bucket-name",
                "arn:aws:s3:::your-bucket-name/*"
            ]
        }
    ]
}

Create a new IAM user with programmatic access
Attach the policy you just created
Save the Access Key ID and Secret Access Key securely

Step 3: Setting Up Your GitHub Repository

Create a new repository or use an existing one
Add your static website files to the repository
Navigate to Settings > Secrets and variables > Actions
Add the following secrets:
- AWS_ACCESS_KEY_ID: Your IAM user's access key
- AWS_SECRET_ACCESS_KEY: Your IAM user's secret key
- S3_BUCKET_NAME: Your S3 bucket name

Step 4: Creating the GitHub Actions Workflow

The heart of our CI/CD pipeline is the GitHub Actions workflow file. Create a new file at .github/workflows/deploy-to-s3.yml with the following content:

name: Deploy Static Website to S3

on:
  push:
    branches: [ main ]
  workflow_dispatch:  # Allows manual triggering

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout repository
      uses: actions/checkout@v3

    # No build step needed for this simple static website
    # Just update the deployment timestamp in the JavaScript file
    - name: Update deployment timestamp
      run: |
        echo "// Updating timestamp for deployment on $(date)" >> js/script.js
        echo "// Deployment ID: ${{ github.run_id }}" >> js/script.js

    # Configure AWS credentials
    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: "ap-south-1"

    # Deploy to S3 bucket - directly sync the repository contents
    - name: Deploy to S3
      run: |
        aws s3 sync ./ s3://${{ secrets.S3_BUCKET_NAME }}/ \
          --delete \
          --exclude ".git/*" \
          --exclude ".github/*" \
          --exclude "README.md"

Let's break down what this workflow does:

Triggers: The workflow runs whenever code is pushed to the main branch or when manually triggered
Checkout: Fetches the latest code from your repository
Timestamp: Adds a deployment timestamp to your JavaScript file
AWS Credentials: Configures AWS credentials using your GitHub secrets
Deployment: Syncs your website files to the S3 bucket, excluding unnecessary files
Confirmation: Outputs the URL where your website can be accessed

Step 5: Testing the Pipeline

Now it's time to see your CI/CD pipeline in action:

Commit and push your changes to the main branch
Go to the "Actions" tab in your GitHub repository
Watch as your workflow runs automatically
Once completed, click on the workflow run to see the details
Visit your website URL to confirm the deployment was successful

Understanding the Workflow

Let's dive deeper into some key aspects of our GitHub Actions workflow:

The Trigger

on:
  push:
    branches: [ main ]
  workflow_dispatch:

This section defines when the workflow should run. In our case, it runs on pushes to the main branch and can also be triggered manually using the "workflow_dispatch" event.

AWS Credentials

- name: Configure AWS credentials
  uses: aws-actions/configure-aws-credentials@v1
  with:
    aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
    aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
    aws-region: 'us-east-1'

This step uses the official AWS GitHub Action to configure credentials. The credentials are stored securely as GitHub secrets and are never exposed in logs.

S3 Sync

- name: Deploy to S3
  run: |
    aws s3 sync ./ s3://${{ secrets.S3_BUCKET_NAME }}/ \
      --delete \
      --exclude ".git/*" \
      --exclude ".github/*" \
      --exclude "README.md" \
      --exclude "*.md" \
      --exclude ".vscode/*"

The aws s3 sync command efficiently uploads only the files that have changed. The --delete flag removes files from the bucket that don't exist in your repository, ensuring your website is always in sync with your code.

Common Issues and Troubleshooting

Here are some common issues you might encounter and how to fix them:

Access Denied Errors

If you see "Access Denied" errors in your workflow:

Double-check your IAM permissions
Verify that your bucket policy allows the necessary actions
Ensure your GitHub secrets are correctly set

Files Not Updating

If your website isn't reflecting the latest changes:

Check that you're pushing to the correct branch
Look for errors in the GitHub Actions logs
Try clearing your browser cache

Workflow Not Triggering

If your workflow isn't running:

Verify that the workflow file is in the correct location (.github/workflows/)
Check that the trigger conditions match your push event
Ensure the workflow file has valid YAML syntax

Conclusion

Setting up a CI/CD pipeline with GitHub Actions and AWS S3 is a powerful way to streamline your website deployment process. By automating these tasks, you can focus on what matters most—building great websites.

I hope this guide helps you implement your own automated deployment pipeline. Happy coding!

Automated Kubernetes Governance with Kyverno and Slack Alerts

Ravindra Singh — Sun, 13 Jul 2025 17:19:41 +0000

✨ Introduction

As Kubernetes adoption increases in production environments, enforcing security, compliance, and operational consistency becomes crucial. Developers move fast, but clusters need guardrails. This is where Kyverno and Policy Reporter come in.

🏗️ Kyverno Architecture (Explained Simply)
Kyverno works as an Admission Controller inside your Kubernetes cluster.

Whenever you run a command like:

kubectl apply -f deployment.yaml

The Kubernetes API server first checks:

✅ Is the YAML valid?
✅ Is the user authorized?
✅ Are there any policies that should be applied?

This is where Kyverno steps in.

🔁 How it Works (Step-by-Step):

The API server sends the resource to Kyverno via an admission webhook.
Kyverno checks if any policy applies to that resource It checks the resource against all policies stored in its Policy Cache.
Depending on the policy type, Kyverno can:

1. Validate → Block if not compliant 2. Mutate → Auto-correct the YAML (e.g., add a label) 3. Generate → Create supporting resources (like NetworkPolicy)

Kyverno sends a response back to the API server (allow or deny).
Kyverno also creates a Policy Report and can send an alert via Slack if integrated with Policy Reporter.

In this blog, we will deploy following resources:

Deploy Kyverno and Policy Reporter
Write a real policy to protect critical resources
Trigger a violation and send a Slack alert

📌 Why Kyverno?
Kyverno is a Kubernetes-native policy engine, which means:

No need to learn a new DSL — policies are written in YAML
Designed for DevOps and platform engineers, not security specialists only
Supports validation (deny non-compliant resources), mutation (auto-fix), generation (auto-create resources), and cleanup (delete resources)

🚨 Why Do You Need Kyverno in Your Kubernetes Cluster?
As organizations scale their Kubernetes usage, maintaining consistency, security, and compliance across teams and environments becomes a serious challenge.

Source Git Link: [https://github.com/ravindrasinghh/Kubernetes-Playlist/tree/master/Lesson6]

🚀 Step 1: Install Kyverno with Helm
Install Kyverno’s admission controllers into your Kubernetes cluster:
Install it using Helm:

helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update
helm install kyverno kyverno/kyverno --create-namespace -n kyverno -f kyverno-values.yaml

📊 Step 2: Install Policy Reporter with Slack Integration
Install it using Helm:
Install the Policy Reporter UI to visualize Kyverno policies and send alerts to Slack:

helm repo add policy-reporter https://kyverno.github.io/policy-reporter
helm repo update
helm install policy-reporter policy-reporter/policy-reporter --create-namespace -n policy-reporter -f kyverno-ui.yaml

🔧 Step 3: Install Pre-defned kyverno-policies
Install a set of baseline and restricted policies provided by Kyverno:

Install it using Helm:

helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update
helm install kyverno-policies --create-namespace -n kyverno kyverno/kyverno-policies

For more details on the predefined policy sets, visit:
https://github.com/kyverno/kyverno/tree/main/charts/kyverno-policies#kyverno-policies

✨ Examples of Kyverno in Action
✅ 1. Validate Policy — Block containers running as root

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: validate-run-as-non-root
spec:
  validationFailureAction: Enforce
  rules:
    - name: block-root-containers
      match:
        resources:
          kinds:
            - Pod
      validate:
        message: "Running as root is not allowed."
        pattern:
          spec:
            containers:
              - securityContext:
                  runAsNonRoot: true

🧠 Use Case: Prevents insecure containers from being deployed.

✏️ 2. Mutate Policy — Automatically add a label to all Pods

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-default-label
spec:
  rules:
    - name: inject-env-label
      match:
        resources:
          kinds:
            - Pod
      mutate:
        patchStrategicMerge:
          metadata:
            labels:
              env: default

🧠 Use Case: Ensures every Pod has a required label (e.g., for monitoring, billing, or cost allocation).

⚙️ 3. Generate Policy — Auto-create a NetworkPolicy in New Namespaces

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: generate-default-network-policy
spec:
  rules:
    - name: auto-create-network-policy
      match:
        resources:
          kinds:
            - Namespace
      generate:
        kind: NetworkPolicy
        apiVersion: networking.k8s.io/v1
        name: default-deny
        namespace: "{{request.object.metadata.name}}"
        data:
          spec:
            podSelector: {}
            policyTypes:
              - Ingress
              - Egress

🧠 Use Case: Ensure every new namespace starts with a default NetworkPolicy to deny all traffic unless explicitly allowed.

🔐 4. Preventing Accidental Deletion of Critical Resources (Validate Policy)

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: prevent-critical-resource-deletion
spec:
  validationFailureAction: Enforce
  rules:
    - name: block-delete-critical-resources
      match:
        resources:
          kinds:
            - ConfigMap
            - Secret
            - Deployment
            - Service
            - Ingress
            - PersistentVolumeClaim
          namespaces:
            - production
      preconditions:
        all:
          - key: "{{request.operation}}"
            operator: Equals
            value: DELETE
      validate:
        message: "⛔️ Deletion of critical resources is not allowed in production namespace."
        deny: {}

🚀 Let’s Start Implementing These Policies in Our Cluster

Now that we’ve seen practical examples of how Kyverno can validate, mutate, and generate Kubernetes resources, it’s time to apply them in our own environment.

✅ Step 1: Apply the Policies One by One
Use kubectl apply or GitOps practices (e.g., ArgoCD, Flux) to safely introduce each policy into your cluster:

kubectl apply -f validate-run-as-non-root.yaml
kubectl apply -f add-default-label.yaml
kubectl apply -f generate-default-network-policy.yaml
kubectl apply -f prevent-critical-resource-deletion.yaml

💡 Tip: Apply them in a dev/staging cluster first and set validationFailureAction: Audit to test without enforcement.

Let's use kyverno CLI and see , how many current pods or other rsources are passing or failing.

kubectl get policyreports -A

-Now let’s test each Kyverno policy to see how it behaves in real-world scenarios.

1.validate-run-as-non-root**
kubectl apply -f pod-root.yaml

apiVersion: v1
kind: Pod
metadata:
  name: root-pod
spec:
  containers:
    - name: nginx
      image: nginx
      # No securityContext, so will run as root by default

📛 As expected, Kyverno blocks this Pod because it violates the policy that enforces runAsNonRoot: true.

2.pod-no-label.yaml
kubectl apply -f pod-no-label.yaml

apiVersion: v1
kind: Pod
metadata:
  name: test-pod-no-label
spec:
  containers:
    - name: nginx
      image: nginx:latest
      securityContext:
        runAsNonRoot: true

🔄 Thanks to the mutate policy, Kyverno automatically injects the label env: default.

3. Auto-create a NetworkPolicy in New Namespaces
📦 Kyverno detects the new namespace and creates a default NetworkPolicy in it automatically.

kubectl create namespace test-np

4. Preventing Accidental Deletion of Critical Resources
Here comes an important one! Let’s try deleting a critical resource (like a Deployment or Service) in the production namespace:

🔍 Step 2: Monitor Policy Behavior, View Policy Reports and Slack Alerts
Once your Kyverno policies are active, it's important to monitor how they behave and ensure violations don’t go unnoticed. Here's how to track everything using Policy Reporter UI and Slack integration.

📊 1. Access the Policy Reporter Dashboard
Policy Reporter provides a user-friendly dashboard to visualize all Kyverno policy results.

📌 To access it via port-forwarding:

kubectl port-forward service/policy-reporter-ui 8080:8080 -n policy-reporter

🔍 2. Investigate Non-Compliant Workloads
One of the key benefits of using Kyverno with Policy Reporter is the ability to detect and respond to policy violations in real time. Whether it's missing labels, insecure configurations, or critical resource changes—Kyverno helps you enforce best practices, while Policy Reporter ensures you're notified when something goes wrong.

In this section, let’s create a simple policy that requires every Pod to have an app label, and then test what happens when this rule is violated.

🛡️ Example: Require a Label on All Pods
Let’s create a ClusterPolicy that audits Pod missing the app label.**

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-label
spec:
  rules:
    - name: check-label
      match:
        resources:
          kinds:
            - Pod
      validate:
        failureAction: Audit
        message: "Labels 'app' is required on every Pod."
        pattern:
          metadata:
            labels:
              app: "?*"

🔧 Apply the policy using:

kubectl apply -f require-label.yaml

🚨 Trigger a Violation to Test the Policy and Alerts
Now, let’s create a Pod that intentionally violates the policy by omitting the app label:

cat <<EOF | kubectl apply -n test -f -
apiVersion: v1
kind: Pod
metadata:
  name: violate-pod
spec:
  containers:
    - name: nginx
      image: nginx:latest
EOF

📣 Make sure this policy name is included in your Slack channel filter in values.yaml:

policies:
  include: ["prevent-critical-resource-deletion", "require-label"]

🔐 Policy applied → Violation triggered → PolicyReport generated → Slack alert sent

✅ Success! The Pod was created without the required app label, Kyverno generated a PolicyReport, and the Slack alert was triggered as expected.

✅ Want to generate a report right now?
Click the button and generate a Policy Report and view detailed results—all in a single page, broken down by namespace, policy name, and resource.

💬 Thanks for reading!
If you found this helpful or face any issues while setting it up, feel free to reach out. I’d be happy to help!

👉 Drop a comment, connect on LinkedIn, or open an issue on GitHub if you’re using the same setup.

Building a Tetris Game with Python and Pygame

Ravindra Singh — Sun, 01 Jun 2025 10:50:35 +0000

Tetris, the timeless puzzle game, has captivated players for decades with its simple yet challenging gameplay. Inspired by this classic, I embarked on a journey to recreate Tetris using Python and Pygame, enhancing it with modern features and visuals.

🎮 Project Overview
This project is a modern implementation of Tetris, developed in Python using the Pygame library. It offers:

3D-style block rendering: Blocks are displayed with light and shadow effects, giving a pseudo-3D appearance.

Ghost piece preview: A translucent piece shows where the current block will land, aiding strategic placement.

Smooth animations: Line clearing and piece movements are animated for a polished experience.

Score tracking and level progression: Players earn points and advance through levels as they clear lines.

User-friendly interface: Includes start, pause, and game over screens with clear instructions.

You can explore the project on GitHub: https://github.com/ravindrasinghh/tetris-game-amazonq

🛠️ Key Features
Classic Gameplay with Modern Enhancements
While preserving the core mechanics of Tetris, this version introduces visual and functional improvements:

Next piece preview: Displays the upcoming block, allowing players to plan ahead.

Responsive controls: Smooth and intuitive controls for seamless gameplay.

Intuitive Controls
The game utilizes keyboard inputs for control:

**S:** Start the game

**Left Arrow:** Move piece left

**Right Arrow: **Move piece right

**Down Arrow:** Soft drop (move piece down faster)

**Up Arrow:** Rotate piece

**Spacebar:** Hard drop (instantly drop piece to the bottom)

Game features:

3D-style blocks: Blocks are rendered with shading to create a 3D effect.

Ghost pieces: A semi-transparent piece indicates where the current block will land.

Animated transitions: Smooth animations for line clears and piece movements enhance the visual appeal.

🚀 Getting Started
To run the game locally:

Clone the repository:

git clone https://github.com/ravindrasinghh/tetris-game-amazonq.git
cd tetris-game-amazonq

Install dependencies:

Ensure you have Python installed. Then, install Pygame:

pip install pygame

Run the game:

python tetris.py

Enjoy the game and challenge yourself to achieve high scores!

📚 Learnings and Takeaways
Developing this Tetris game provided insights into:

Game development fundamentals: Understanding game loops, event handling, and rendering.

User interface design: Creating intuitive and visually appealing interfaces.

Python and Pygame proficiency: Enhancing skills in Python programming and using the Pygame library.

🔗 Explore the Project
Feel free to explore, fork, and contribute to the project on GitHub: ravindrasinghh/tetris-game-amazonq.

Happy coding and gaming!

Install .NET SDK and Runtime on Ubuntu 24.04.2 LTS

Ravindra Singh — Wed, 23 Apr 2025 08:37:12 +0000

If you’re a developer working on a .NET application **or planning to host one on Ubuntu, you’ll need to install the .NET SDK** and ASP.NET Core Runtime.

This guide is specially written for Ubuntu 24.04.2 LTS users — with every step explained in plain language so even beginners can follow easily.

💡 Why Do We Need to Install This?
.NET SDK is needed if you want to build or develop .NET applications.
ASP.NET Core Runtime is required if you only want to run web applications built with ASP.NET Core (for example, hosting on a Linux VM).

🖥️ OS Requirement
This guide is tested on:
OS: Ubuntu 24.04.2 LTS

To check your OS version:
$ lsb_release -a

🧩 Step 1: Update Your Package List
Before installing anything, always update your system’s package list:

sudo apt update

👉 Why?
This command makes sure Ubuntu is aware of the latest available software versions. Think of it as refreshing the app store before installing something new.

📦 Step 2: Install the .NET SDK 8.0
Run this command:

sudo apt install -y dotnet-sdk-8.0

👉 Why?
This installs the .NET Software Development Kit (SDK), which includes everything you need to build and run .NET 8 apps from the command line.

The -y flag auto-confirms the installation to save time.

🌐 Step 3: Install ASP.NET Core Runtime 8.0

sudo apt install -y aspnetcore-runtime-8.0

👉 Why?
This installs only the runtime environment for ASP.NET Core web applications. Useful if you’re hosting a web app, not developing it.

You can install both SDK and Runtime — no issues. The SDK includes a runtime too, but adding aspnetcore-runtime ensures full compatibility for web apps.

✅ Step 4: Verify the Installation
Let’s make sure everything is installed correctly.

Check the installed .NET version:

dotnet --version

This shows the version of the SDK currently active.

Check where the dotnet CLI is installed:

which dotnet

This confirms the dotnet command is available in your system's PATH.

List all installed .NET-related packages:

dpkg -l | grep dotnet

This shows all installed .NET packages using Ubuntu’s package system.

🎉 You’re Ready to Build!
You now have the full setup ready to build and run .NET 8.0 and ASP.NET Core apps on Ubuntu 24.04.2 LTS.

You can now create your first app:


dotnet new console -o HelloApp
cd HelloApp
dotnet run

💬 Questions?
If you run into any issues or have questions, feel free to reach out in the comments. Happy coding! 🚀

Install and Use Amazon Q AI Assistant on Mac

Ravindra Singh — Wed, 02 Apr 2025 09:23:41 +0000

Amazon Q is a generative AI-powered assistant by AWS designed to help developers boost productivity. It can answer questions, write and review code, debug issues, and even generate documentation.

Developers should care because it integrates directly into your IDE, understands your codebase, and provides real-time assistance—saving hours of manual effort.

This blog is a quick guide on how to install and use Amazon Q Developer on macOS.

Prerequisites

macOS system
AWS account with Builder ID or IAM identity
Internet connection 😄

Installing Amazon Q on macOS

Go to the official download page:

https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/command-line-installing.html

Download the Mac installer (typically a .dmg file):
Click the download link for macOS under the Amazon Q Developer section.
Open the .dmg file once downloaded.
Drag the Amazon Q app into your Applications folder.

Enable shell integrations with Amazon Q

Grant accessibility permissions so Amazon Q can interact with windows and perform actions

After clicking 'Enable', you'll be prompted to activate Amazon Q.

Open the app and follow the sign-in process using your AWS Builder ID or IAM identity.

Click on 'Allow Access' to grant Amazon Q command line access.

After successful installation, you'll be greeted with the Getting Started page.

Now that Amazon Q is installed, let’s make sure everything’s working.

To disable Amazon Q from the command line, run the following command:

 q inline disable

🛠️ Troubleshooting

Issue: Terminal not detecting q command
Fix: Restart your terminal or manually source the shell config file.
Issue: Accessibility permissions not showing
Fix: Go to System Settings → Privacy & Security → Accessibility and manually enable it.

💡 Tip: If you’re a developer, also try the Amazon Q extension in your IDE:
For VS Code:

Open Visual Studio Code.
Go to Extensions.
Search for Amazon Q.
Click Install.

Supercharge Your Development with Amazon Q Developer

🚀 Now it’s your turn!

Try it out in your favorite IDE or via the desktop app—and let Amazon Q help you build faster and smarter.

Prefer video tutorials? Check out my step-by-step walkthrough on how to build a Node.js app using Amazon Q CLI!

If you found this guide helpful, feel free to share it with your developer community or drop your feedback in the comments!

ECS FinHacks: Scaling Microservices with AWS ECS Fargate and RDS

Ravindra Singh — Mon, 17 Feb 2025 02:59:59 +0000

If you've ever struggled with questions like:

How do I securely deploy my containerized application on AWS?
How do I integrate ECS, Fargate, PostgreSQL, and AWS security services?
How can I ensure high availability while keeping costs under control?

Then this blog is for you.

In this blog post, we will explore how to deploy a Node Js Microservice in AWS ECS Fargate with connectivity to Amazon RDS (PostgreSQL). This architecture ensures high availability, security, and scalability while leveraging fully managed AWS services.

Git Link: https://github.com/ravindrasinghh/ECS-FinHacks-Scaling-Microservices-with-AWS-ECS-Fargate-and-RDS

Why Use AWS ECS?

Fully Managed: Eliminates the need to manage EC2 instances.
Scalability: Supports automatic scaling based on demand.
Security: Integrates with AWS IAM, Security Groups, and VPC.
Cost Efficiency: Pay only for the resources used.
Integration: Works seamlessly with AWS services like RDS, S3, and CloudWatch.

Advanced Architecture Benefits:

ECS Circuit Breaker
ECS Capacity Provider(ECS Fargate SPOT + ECS Fargate)
VPC Endpoint
Route 53 Health check
AWS Config

1. Architecture Overview
The architecture follows AWS best practices by leveraging containerized workloads on ECS (Fargate), a multi-AZ database layer (PostgreSQL), and various AWS security and monitoring services.

ECS Fargate: Fully managed container orchestration.
Amazon RDS (PostgreSQL): Managed relational database service.
AWS ALB (Application Load Balancer): Distributes traffic among ECS tasks.
AWS Secrets Manager: Stores database credentials securely.
AWS CloudWatch: Monitors logs and metrics.
AWS Route 53: Domain Name System (DNS) for routing traffic.
AWS WAF (Web Application Firewall): Protects against common web threats. AWS Config: Tracks and records AWS configuration changes.
AWS CloudTrail: Logs all API requests for auditing.
AWS CloudWatch Alarms: Triggers notifications based on metrics.
VPC Endpoint: Enables secure, private connectivity to AWS services.
KMS (Key Management Service): Encrypts data at rest and in transit.
ENI (Elastic Network Interface): Provides network connectivity for ECS tasks.
Health Check & Route 53 Health Check: Ensures high availability by monitoring service health.

2. Step-by-Step Breakdown of the AWS Architecture
Let's dive deeper into how each AWS service fits into the architecture.

2.1 Networking & Security
VPC (Virtual Private Cloud):

A private and secure network for hosting all resources. Contains public and private subnets for better isolation.

AWS WAF (Web Application Firewall):

Protects against common attacks like SQL injection and XSS.

AWS GuardDuty:

Detects and alerts on security threats.

AWS KMS (Key Management Service):

Encrypts sensitive data, database records, and API secrets.

2.2 Load Balancing & Traffic Routing
Amazon Route 53:

Provides global DNS resolution and failover routing.

Application Load Balancer (ALB):

Distributes traffic to ECS containers.
Performs health checks and ensures high availability.

2.3 Compute & Containers
Amazon ECS (Elastic Container Service):

Manages containerized workloads with Fargate & Spot instances.

Fargate (On-demand & Spot):

Serverless compute for containers, reducing management overhead. Spot pricing optimizes costs by using spare AWS capacity.

Task Definitions & IAM Roles:

Defines how containers run within ECS.
IAM Roles ensure secure communication between services.

2.4 Database Layer
Amazon RDS (PostgreSQL Multi-AZ):

High availability using a Master-Replica setup.
KMS encryption ensures data security.

2.5 Monitoring & Logging
Amazon CloudWatch:

Logs container performance, database health, and API requests. AWS Config & CloudTrail:
Tracks infrastructure changes and compliance.

3. Scalability & High Availability
This architecture ensures scalability at multiple levels:
✅ ECS Auto-scaling: Dynamically adjusts the number of running containers based on load.
✅ Database Auto-scaling: Supports read replicas for handling increased query loads.
✅ Multi-AZ Deployment: Ensures uptime even if one availability zone fails.
✅ ALB Health Checks: Automatically reroutes traffic in case of failure.
This combination allows applications to handle traffic spikes without downtime.

4. Security Best Practices
Security is a top priority, and this architecture follows best practices:
🔐 IAM Roles & Policies: Grant the least privilege access to services.
🔐 WAF & GuardDuty: Blocks malicious requests and detects threats.
🔐 KMS Encryption: Protects database and sensitive data.
🔐 Secrets Manager: Manages database credentials securely.
By implementing these security layers, the architecture remains resilient against cyber threats.

5. Cost Optimisation Strategies
AWS provides multiple ways to reduce costs while maintaining performance.
💰 Fargate Spot: Uses AWS's spare capacity for containerized workloads, reducing costs by up to 70%.
💰 Reserved Instances for PostgreSQL: Locks in lower pricing for predictable workloads.
💰 Auto-scaling Policies: Ensures you only pay for what you use.
💰 EFS Infrequent Access Storage: Saves money on unused storage.
By leveraging these strategies, you can run a cost-efficient architecture without sacrificing performance.

6. Troubleshooting Tips
👉🏻 To resolve below error.

If you are using a VPC endpoint for ECR, please enable private DNS in the VPC endpoint.

Use the following command to create the ECR repositories.

aws ecr create-repository --repository-name nodejs-api --endpoint-url https://api.ecr.ap-south-1.amazonaws.com

👉🏻 endpoint url will get from https://api.ecr.ap-south-1.amazonaws.com

Navigate to VPC Endpoints and select the API URL.

👉🏻 Amazon ECS tasks hosted on Fargate using platform version 1.4.0 or later require both Amazon ECR VPC endpoints and the Amazon S3 gateway endpoints.

7. Conclusion
Building a scalable, secure, and cost-effective AWS architecture doesn't have to be complicated. By integrating ECS, Fargate, PostgreSQL, and AWS security services, you can:
✅ Achieve high availability and fault tolerance
✅ Protect your workloads with advanced security measures
✅ Optimize cloud costs using AWS best practices
This architecture provides a blueprint for running production-grade applications in AWS. Whether you're scaling a startup or managing enterprise workloads, these principles will help you build a robust cloud infrastructure.

Reference:
If you prefer a video tutorial to help guide you through the setup of Scaling Microservices with AWS ECS Fargate and RDS

EKS & NGINX Load Balancer Monitor with Prometheus, Grafana, and Alerts

Ravindra Singh — Sat, 14 Dec 2024 08:55:13 +0000

Introduction:

With the growing use of Kubernetes (EKS) and microservices architecture, monitoring your infrastructure has become crucial to ensure that everything runs smoothly.

In this blog, we'll walk through setting up monitoring for NGINX running on an Amazon EKS cluster, utilizing Prometheus and Grafana for monitoring and visualization, and implementing alerting mechanisms to keep you informed about your system's health.

Why Monitor EKS and NGINX Load Balancers?

Early Issue Detection: Proactive monitoring allows you to identify potential problems before they impact your users, ensuring a seamless experience.
Performance Optimization: Monitoring key metrics helps you understand how your EKS cluster and NGINX load balancer are performing, allowing you to fine-tune your configuration for optimal efficiency.
Troubleshooting: When issues arise, having detailed metrics and logs readily available makes troubleshooting faster and more effective.
Capacity Planning: Analyzing historical data helps you predict future resource needs, ensuring your infrastructure scales seamlessly with your application.

EKS Cluster Metrics

EKS Cluster
Node resource utilization (CPU, memory, disk)
Pod health and status
Control plane health

NGINX Ingress Controller Metrics

Request rate and latency
Error rate
Upstream server health
Connection counts

Example Alerting Scenarios

High NGINX Error Rate: Alert when the NGINX error rate exceeds a certain threshold, indicating potential issues with upstream servers or configuration.
Node Resource Exhaustion: Alert when CPU or memory utilization on any node approaches critical levels, allowing you to proactively scale your cluster.
Pod Failures: Alert when pods repeatedly fail to start or crash, signaling potential application or configuration problems.

Let's Begin😎

🚀 Step-by-Step Guide to install the promethus , grafana and alert manager
1️⃣ A running Kubernetes cluster: This can be a self-managed cluster or a managed service like Amazon EKS.

Refer below video to create the EKS Cluster in AWS

2️⃣ NGINX Ingress on AWS EKS and Deploying Sample Applications

Refer below video to setup in AWS

3️⃣ Clone the Repository

🧑🏻‍💻git clone https://github.com/ravindrasinghh/Kubernetes-Playlist.git
👨🏻‍💻cd Kubernetes-Playlist/Lesson1/

4️⃣ Please add the below file to install Prometheus, Grafana, and Alertmanager using Helm
👉🏻 prometheus.tf

resource "helm_release" "kube-prometheus-stack" {
  name             = "kube-prometheus-stack"
  repository       = "https://prometheus-community.github.io/helm-charts"
  chart            = "kube-prometheus-stack"
  version          = "56.21.3"
  namespace        = "monitoring"
  create_namespace = true

  values = [
    file("./prometheus.yaml")
  ]
}

👉🏻 prometheus.yaml

alertmanager:
  enabled: true
  alertmanagerSpec:
    retention: 24h #This setting specifies the time duration for which Alertmanager will retain alert data. 
    replicas: 1
    resources:
      limits:
        cpu: 600m
        memory: 1024Mi
      requests:
        cpu: 200m
        memory: 356Mi
  config:
    global:
      resolve_timeout: 1s # In this case, it's set to 5 minutes. If an alert is not explicitly resolved by the alert source within 5 minutes, it will be automatically marked as resolved by Alertmanager.
    route:
      group_wait: 20s
      group_interval: 1m
      repeat_interval: 30m
      receiver: "null"
      routes:
      - match:
          alertname: Watchdog
        receiver: "null"
      - match:
          severity: warning
        receiver: "slack-alerts"
        continue: true
      - match:
          severity: critical
        receiver: "slack-alerts"
        continue: true
    receivers:
      - name: "null"
      - name: "slack-alerts"
        slack_configs:
        - api_url: 'https://hooks.slack.com/services/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'
          channel: '#prometheus-alerts'
          send_resolved: true
          title: '[{{ .Status | toUpper }}{{ if eq .Status "firing" }}:{{ .Alerts.Firing | len }}{{ end }}] Production Monitoring Event Notification'
          text: >-
            {{ range .Alerts }}
              *Alert:* {{ .Annotations.summary }} - `{{ .Labels.severity }}`
              *Description:* {{ .Annotations.description }}
              *Details:*
              {{ range .Labels.SortedPairs }} • *{{ .Name }}:* `{{ .Value }}`
              {{ end }}
            {{ end }}
    templates:
    - "/etc/alertmanager/config/*.tmpl"
additionalPrometheusRulesMap:
 custom-rules:
  groups:
  - name: NginxIngressController
    rules:
    - alert: NginxHighHttp4xxErrorRate
      annotations:
        summary: "High rate of HTTP 4xx errors (instance {{ $labels.ingress }})"
        description: "Too many HTTP requests with status 4xx (> 20 per second) in the last 5 minutes\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"
      expr: nginx_ingress_controller_requests{status="404", ingress="photoapp"} > 5
      for: 5m
      labels:
        severity: critical      
  - name: Nodes
    rules:
    - alert: KubernetesNodeReady
      expr: sum(kube_node_status_condition{condition="Ready", status="false"}) by (node) > 0
      for: 1m
      labels:
        severity: critical
      annotations:
        summary: Kubernetes Node ready (instance {{ $labels.instance }})
        description: "Node {{ $labels.node }} has been unready for a long time\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"         
      # New alert for node deletion
    - alert: InstanceDown
      expr: up == 0
      labels:
        severity: critical
      annotations:
        summary: Kubernetes Node Deleted (instance {{ $labels.instance }})
        description: "Node {{ $labels.node }} has been unready for a long time\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"     
  - name: Pods 
    rules: 
      - alert: Container restarted 
        annotations: 
          summary: Container named {{$labels.container}} in {{$labels.pod}} in {{$labels.namespace}} was restarted 
          description: "\nCluster Name: {{$externalLabels.cluster}}\nNamespace: {{$labels.namespace}}\nPod name: {{$labels.pod}}\nContainer name: {{$labels.container}}\n" 
        expr: | 
          sum(increase(kube_pod_container_status_restarts_total{namespace!="kube-system",pod_template_hash=""}[1m])) by (pod,namespace,container) > 0 
        for: 0m 
        labels: 
          severity: critical            
prometheus:
  enabled: true
  ingress:
    enabled: true
    ingressClassName: nginx
    hosts:
      - prometheus.codedevops.cloud
    paths:  
      - /
  prometheusSpec:
    retention: 48h
    replicas: 2
    resources:
      limits:
        cpu: 800m
        memory: 2000Mi
      requests:
        cpu: 100m
        memory: 200Mi
grafana:
  enabled: true
  adminPassword: admin@123
  replicas: 1
  ingress:
    enabled: true
    ingressClassName: nginx
    hosts:
      - grafana.codedevops.cloud
    path: /

You can also check the logs of the Prometheus, Grafana, and Alertmanager pods to verify that the setup has been successfully installed.
👉🏻 kubectl get pods -n monitoring

👉🏻 Let's create a record in Route 53 to access prometheus and grafana via a custom domain.

Go to the Route 53 service, select the hosted zone, and click Create Record.
Choose Alias, then select the region and the Load Balancer ARN, and click Create.

👉🏻 once the Ingress is configured, you can access the promethues web interface by navigating to https://prometheus.codedevops.cloud.

👉🏻 once the Ingress is configured, you can access the grafana web interface by navigating to https://grafana.codedevops.cloud

To log in:

Get the initial password for the admin user:

kubectl get secret kube-prometheus-stack-grafana -n monitoring -o jsonpath="{.data.admin-password}" | base64 --decode

🚀 Step-by-Step Guide to integrate slack with prometheus alerts
Step 1: Create a Slack Incoming Webhook
Go to Slack Apps: (Open your Slack workspace and visit the Slack API Apps page.)

👉🏻Click on Add Apps located at the bottom.

👉🏻 It will open this page, where you need to select Incoming Webhook.

👉🏻 click on it and then click on configuration

👉🏻 click on Add to slack

👉🏻 Choose a channel or an existing channel, then click on Add Incoming Webhooks Integration.After that, copy the Webhook URL and configure it in your Prometheus Helm chart values.yaml file.

👉🏻 click on save buttons and test the configuration.

🚀 Step-by-Step Guide to monitor NGINX ingress Load balancer

👉🏻Here is the NGINX Ingress YAML file. You can refer to lesson 2 or the previous video for more details.
https://github.com/ravindrasinghh/Kubernetes-Playlist/blob/master/Lesson2/nginx.yaml

controller:
  replicaCount: 2
  minAvailable: 1
  resources:
    limits:
      cpu: 500m
      memory: 512Mi
    requests:
      cpu: 100m
      memory: 256Mi
  autoscaling:
    enabled: true
    annotations: {}
    minReplicas: 2
    maxReplicas: 6
    targetCPUUtilizationPercentage: 70
    targetMemoryUtilizationPercentage: 80
    behavior:
      scaleDown:
        stabilizationWindowSeconds: 60
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
  metrics:
    port: 10254
    enabled: true
    serviceMonitor:
      enabled: true
      additionalLabels:
        release: "kube-prometheus-stack"
    service:
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "10254"
  service:
    annotations:
      service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp
      service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: 'true'
      service.beta.kubernetes.io/aws-load-balancer-type: nlb
      service.beta.kubernetes.io/aws-load-balancer-ssl-ports: https
      service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy: 'ELBSecurityPolicy-TLS13-1-2-2021-06'
      service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*"
    targetPorts:
      http: http
      https: http

In simpler terms:
This configuration tells the Ingress Controller to:

Expose its internal metrics on port 10254.
Create a ServiceMonitor object so that Prometheus can automatically find this metrics endpoint.
Add annotations to the Ingress Controller's Service so Prometheus knows to scrape it.

Annotations:

prometheus.io/scrape: "true": This annotation tells Prometheus that it should scrape the metrics from this service.
prometheus.io/port: "10254":Specifies the port that Prometheus should use to scrape metrics from this service, matching the metrics.port setting above.

🚀 Step-by-Step Guide to setup alert in NGINX ingress Load balancer
👉🏻add below configuration inside the additionalPrometheusRulesMap:

additionalPrometheusRulesMap:
 custom-rules:
  groups:
  - name: NginxIngressController
    rules:
    - alert: NginxHighHttp4xxErrorRate
      annotations:
        summary: "High rate of HTTP 4xx errors (instance {{ $labels.ingress }})"
        description: "Too many HTTP requests with status 4xx (> 20 per second) in the last 5 minutes\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"
      expr: nginx_ingress_controller_requests{status="404", ingress="photoapp"} > 5
      for: 5m
      labels:
        severity: critical

👉🏻 Here is the correct url :
https://myapp.codedevops.cloud/ping.
👁️‍🗨️Try accessing the incorrect URL https://myapp.codedevops.cloud/pingtesting. You will see two alerts in the firing state, and the alerts will also appear in Slack.

👉🏻erorr notification in slack

👉🏻Resolved notification in slack

🚀 Step-by-Step Guide to monitor Kubernetes cluster, nodes and pods

The metrics-server is required to collect resource metrics like CPU and memory usage for Kubernetes nodes and pods. It provides data for kubectl top commands and enables the cluster's auto-scaling.

Please add the below file to install metrics server using helm.
👉🏻 metrics-server.tf

resource "helm_release" "metrics_server" {
  name       = "metrics-server"
  repository = "https://kubernetes-sigs.github.io/metrics-server/"
  chart      = "metrics-server"
  version    = "3.12.0"
  namespace  = "kube-system"
}

🚀 Step-by-Step Guide to setup alert in Nodes and pods.
node is terminating

additionalPrometheusRulesMap:
 custom-rules:
  groups:  
  - name: Nodes
    rules:
    - alert: KubernetesNodeReady
      expr: sum(kube_node_status_condition{condition="Ready", status="false"}) by (node) > 0
      for: 1m
      labels:
        severity: critical
      annotations:
        summary: Kubernetes Node ready (instance {{ $labels.instance }})
        description: "Node {{ $labels.node }} has been unready for a long time\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"         
      # New alert for node deletion
    - alert: InstanceDown
      expr: up == 0
      labels:
        severity: critical
      annotations:
        summary: Kubernetes Node Deleted (instance {{ $labels.instance }})
        description: "Node {{ $labels.node }} has been unready for a long time\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}" 
pod is restarting 
additionalPrometheusRulesMap:
 custom-rules:
  groups:
  - name: Pods 
    rules: 
    - alert: Container restarted 
      annotations: 
        summary: Container named {{$labels.container}} in {{$labels.pod}} in {{$labels.namespace}} was restarted 
        description: "\nCluster Name: {{$externalLabels.cluster}}\nNamespace: {{$labels.namespace}}\nPod name: {{$labels.pod}}\nContainer name: {{$labels.container}}\n" 
      expr: | 
        sum(increase(kube_pod_container_status_restarts_total{namespace!="kube-system",pod_template_hash=""}[1m])) by (pod,namespace,container) > 0 
      for: 0m 
      labels: 
       severity: critical

👉🏻erorr notification in slack

👉🏻Resolved notification in slack

🚀 Step-by-Step Guide to setup Dashboard in Grafana.
Cluster Monitoring: https://github.com/ravindrasinghh/Kubernetes-Playlist/blob/master/Lesson5/cluster_disk_monitoring.json

Prometheus Alert: https://github.com/ravindrasinghh/Kubernetes-Playlist/blob/master/Lesson5/promethues_alert.json

Troubleshooting
If you encounter any issues, refer to the Prometheus documentation or raise an issue in this repository.
🏴‍☠️ source link: https://github.com/ravindrasinghh/Kubernetes-Playlist/tree/master/Lesson5

If you prefer a video tutorial to help guide you to setup EKS & NGINX Load Balancer Monitor with Prometheus, Grafana, and Alerts

Installing ArgoCD and Securing Access Using Amazon Cognito

Ravindra Singh — Fri, 27 Sep 2024 11:59:23 +0000

Introduction:
In this blog, we will walk through the steps to install ArgoCD, a powerful GitOps continuous delivery tool, using Helm. We'll also configure access to ArgoCD via an Ingress controller, making it easy to manage Kubernetes deployments from a web interface.

GIT LINK: https://github.com/ravindrasinghh/Kubernetes-Playlist

Let's Begin 😎

Application Controller: Manages the state of applications in ArgoCD by continuously monitoring Git repositories and syncing changes to Kubernetes clusters.
Repo Server: Handles interactions with Git repositories, fetching application manifests and generating Kubernetes manifests in ArgoCD.
ArgoCD Server: The web interface and API service for interacting with ArgoCD, where users can view, manage, and control their application deployments.
Redis: A fast, in-memory key-value store used by ArgoCD for caching and state management.
Dex Server: An OpenID Connect (OIDC) identity provider used in ArgoCD for integrating with external authentication services (e.g., LDAP, GitHub, etc.).

Let's Begin😎

🚀 Step-by-Step Guide

1️⃣ A running Kubernetes cluster: This can be a self-managed cluster or a managed service like Amazon EKS.

Refer below video to create the EKS Cluster in AWS

2️⃣ NGINX Ingress on AWS EKS and Deploying Sample Applications
Refer below video to setup in AWS

3️⃣ Clone the Repository

🧑🏻‍💻git clone https://github.com/ravindrasinghh/Kubernetes-Playlist.git
👨🏻‍💻cd Kubernetes-Playlist/Lesson1/

4️⃣ Please add the below file to install the ArgoCD
👉🏻 argocd.tf

resource "helm_release" "argocd" {
  name             = "argocd"
  repository       = "https://argoproj.github.io/argo-helm"
  chart            = "argo-cd"
  namespace        = "argocd"
  create_namespace = true
  version          = "4.0.0"
  values           = [file("./argo.yaml")]
}

👉🏻 argocd.yaml

global:
  domain: https://argo.codedevops.cloud
repoServer:
  resources:
    requests:
      cpu: 100m
      memory: 128Mi            
server:
  resources:
    requests:
      cpu: 100m
      memory: 128Mi
  config:
    url: "https://argo.codedevops.cloud" 
  extraArgs:
    - --insecure    
  ingress:
    enabled: true
    ingressClassName: nginx
    annotations:
      nginx.ingress.kubernetes.io/backend-protocol: "HTTP"
      nginx.ingress.kubernetes.io/cors-expose-headers: "*, X-CustomResponseHeader"
      nlb.ingress.kubernetes.io/scheme: internet-facing
      nlb.ingress.kubernetes.io/target-type: instance
      nlb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
      nlb.ingress.kubernetes.io/certificate-arn: "arn:aws:acm:ap-south-1:434605749312:certificate/50eeb484-0d88-4617-bdf6-1d339f2f3b48"
    hosts:
      - argo.codedevops.cloud

You can also view the logs of the ArgoCD pod to verify that ArgoCD has been installed successfully.

👉🏻 kubectl get pods -n argocd

👉🏻 Let's create a record in Route 53 to access ArgoCD via a custom domain.

Go to the Route 53 service, select the hosted zone, and click Create Record.
Choose Alias, then select the region and the Load Balancer ARN, and click Create.

👉🏻 once the Ingress is configured, you can access the ArgoCD web interface by navigating to https://argo.codedevops.cloud.

👉🏻 To log in:
Get the initial password for the admin user:

kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath="{.data.password}" | base64 --decode

👉🏻 We can see that we have successfully logged in using the username 'admin' and the password mentioned above.

🚀 Step-by-Step Guide to access via AWS Cognito
1️⃣ Navigate to the AWS Cognito console, click on 'Create User Pool,' select 'Username,' and then click 'Next.' You can add additional parameters based on your requirements.

2️⃣ Set up a password policy to specify the required length and complexity for user passwords, or use the default settings.

I selected 'No MFA,' but you can enable it if needed, and then click 'Next.'

3️⃣ For the 'Configure Sign-Up Experience' section, click 'Next' and proceed with the default settings.

4️⃣ Let's use Cognito's default email address temporarily for development to handle emails for sign-up, sign-in, MFA, and account recovery workflows.

5️⃣ Let's integrate with our app and provide the following information:
User Pool Name: ARGOCD
Use the Cognito Hosted UI: Check the box
Use a Cognito Domain: https://argocodedevops

Set the App Client Name to argo-app-client and click on 'Generate a Client Secret.' For the Allowed Callback URLs, enter https://argo.codedevops.cloud/auth/callback, and then click 'Next.'

Review the settings, and then click 'Create.'

👉🏻 Navigate to users in the userpool and click on Create user.
· Creation of user and adding to the Group
· Click on the userpool which has been created
· Navigate to the User tab and click on the create user.

You will also receive the user details in your email.

👉🏻 Navigate to group in the userpool and click on Create group.
Add the user to this group, and you can assign them a specific IAM role. Let's keep it as the default.
click on create group.

Click on the group name and add the newly created user to the group.

click on add.

Let's update the Ingress configuration to enable login to ArgoCD via AWS Cognito, and ensure that the correct values are entered for the OIDC configuration.

👉🏻 name: ADMIN # can be anything
👉🏻 issuer: https://cognito-idp.ap-south-1.amazonaws.com/ap-south-1_i2BlvxmV2 # Replace with your AWS SSO Issuer URL
👉🏻 clientID: 2ulo6uvu1r4o2eesgq9tifiqjq # Replace with your AWS SSO Client ID
👉🏻 clientSecret: 9530gfivef6aoi21e0cj93p41gt7e2gja4b7u0e1ui93pvpv5pu # Replace with your AWS SSO Client Secret
👉🏻 redirectUrI: https://argo.codedevops.cloud/api/dex/callback # Replace with your ArgoCD URL
👉🏻 requestedScopes: ["email", "openid", "phone"]
👉🏻 requestedIDTokenClaims: {"groups": {"essential": true}}

You can retrieve the values from AWS Cognito. Click on 'App Integration,' navigate to the 'App Client List' section, select argo-app-client, and copy all the client-related information.

Please update the Ingress configuration with AWS Cognito service details to enable login via Cognito.

global:
  domain: https://argo.codedevops.cloud
configs:
  params:
    "server.insecure": true
  cm:
    create: true        
  rbac:
    create: true
    policy.default: ''
    policy.csv: |
        g, argocd-readonly, role:readonly
        g, argocd-admin, role:admin
    scopes: '[groups]'   
repoServer:
  resources:
    requests:
      cpu: 100m
      memory: 128Mi            
server:
  config:
    url: "https://argo.codedevops.cloud"   
    oidc.config: |
        name: admin
        issuer: https://cognito-idp.ap-south-1.amazonaws.com/ap-south-1_YEwPaQA4Q  # Replace with your AWS SSO Issuer URL
        clientID: 3f8r6j111qidd2c2ft9rmh4vu    # Replace with your AWS SSO Client ID
        clientSecret: 1gpls5t1pm3gjg3rfltsja6b # Replace with your AWS SSO Client Secret
        redirectUrI: https://argo.codedevops.cloud/api/dex/callback
        requestedScopes: ["email", "openid", "phone"]
        requestedIDTokenClaims: {"groups": {"essential": true}}      
  extraArgs:
    - --insecure  
  ingress:
    enabled: true
    ingressClassName: nginx
    annotations:
      nginx.ingress.kubernetes.io/backend-protocol: "HTTP"
      nginx.ingress.kubernetes.io/cors-expose-headers: "*, X-CustomResponseHeader"
      nlb.ingress.kubernetes.io/scheme: internet-facing
      nlb.ingress.kubernetes.io/target-type: instance
      nlb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
      nlb.ingress.kubernetes.io/certificate-arn: "arn:aws:acm:ap-south-1:434605749312:certificate/50eeb484-0d88-4617-bdf6-1d339f2f3b48"
    hosts:
      - argo.codedevops.cloud

👉🏻 Run terraform plan to preview the changes, and then use terraform apply to apply them.
👁️‍🗨️Let's try logging in by accessing the URL(https://argo.codedevops.cloud) again and signing in through AWS Cognito.

Enter the username and passsword.

Troubleshooting

If you encounter any issues, refer to the AWS documentation or raise an issue in this repository.

🏴‍☠️ source link: https://github.com/ravindrasinghh/Kubernetes-Playlist/tree/master
If you prefer a video tutorial to help guide you to Install and Secure ArgoCD access with Amazon Cognito.

Integrate API Gateway with AWS EKS NLB

Ravindra Singh — Sun, 15 Sep 2024 09:45:58 +0000

What is API Gateway
API Gateway is a fully managed service and it provides an entry point to your microservices. It helps you innovate faster by handling common functions such as API throttling, request caching, authorization and access control, monitoring, version management, and security.

AWS PrivateLink is a service that allows you to securely access services hosted on AWS in a highly secure and private manner, without exposing your data to the public internet. It enables private connectivity between Virtual Private Clouds (VPCs), AWS services, and on-premises networks, using private IP addresses within your network.

Why Integrate API Gateway with EKS via NLB?

For Microservices Architectures: When you have multiple microservices in your EKS cluster, and you need a unified API endpoint for client applications.
Security: API Gateway offers fine-grained access control and supports authentication and authorization mechanisms, such as AWS IAM and Lambda Authorizers.
Scalability and High Availability: Combining API Gateway with NLB ensures high availability and automatic scaling of microservices running on your EKS cluster.
Performance: NLB offers low latency and can handle millions of requests per second, making it suitable for high-performance applications.
Ease of Management: With API Gateway, you can easily manage and expose APIs, track usage, and monitor performance.

By combining API Gateway with an Ingress Load Balancer, you achieve a robust, scalable, and secure architecture for managing API traffic to your backend services in Amazon EKS

GIT LINK: https://github.com/ravindrasinghh/Kubernetes-Playlist

Let's Begin😎

🚀 Step-by-Step Guide

1️⃣ A running Kubernetes cluster: This can be a self-managed cluster or a managed service like Amazon EKS.

Refer below video to create the EKS Cluster in AWS

2️⃣ NGINX Ingress on AWS EKS and Deploying Sample Applications
Refer below video to setup in AWS

3️⃣ Create a VPC Link for a REST API and Integrate it with the EKS Network Load Balancer (NLB).

4️⃣ Creating a VPC private link can take approximately 10 minutes to complete.

5️⃣ Create a Private HTTP API using API Gateway with HTTP integrations.

6️⃣ HTTP integration, API Gateway sends the request to the URL that you specify and returns the response from the URL.

{proxy}: Single Path Segment Placeholder
{proxy} is a single path segment placeholder.
It matches exactly one path segment in the URL
For example, if your path is /users/{proxy}, it will match:
/users/123
/users/abc

7️⃣ {proxy+}: Multi-Segment Path Placeholder

{proxy+} is a multi-segment path placeholder (wildcard).
It matches one or more path segments in the URL.
For example, if your path is /users/{proxy+}, it will match:
/users/123
/users/123/details
/users/abc/extra/path

8️⃣ Stages are configurable to enable the deployment of your API.

9️⃣ Review the settings and click the "Create" button.

🔟 Once everything is created, you will see a route defined as {proxy+} with the GET method.

1️⃣ 1️⃣ Click on "Stages" on the left side, and select the desired stage. Since auto-deploy is enabled, there is no need to deploy again. Simply copy the URL and make a request to it.

Invoke the API URL with the Ingress endpoints.
👉🏻 /

👉🏻/ping

👉🏻/metrics

👉🏻/erorr

👁️‍🗨️ You can use both NLB and ALB with API Gateway HTTP APIs, API Gateway REST APIs whereas only support private integrations using a NLB. If you use NLB, you'll use API Gateway routes to route traffic to distinct services. If you choose to use an ALB to expose your services, you'll use ALB to route traffic to distinct services.

Configuring a Custom Domain for Your AWS API Gateway
Custom domain names are simpler and more intuitive URLs that you can provide to your API users.

After deploying your API, you (and your customers) can invoke the API using the default base URL of the following format:

https://api-id.execute-api.region.amazonaws.com/stage

where api-id is generated by API Gateway, region is the AWS Region, and stage is specified by you when deploying the API.

The hostname portion of the URL, api-id.execute-api.region.amazonaws.com refers to an API endpoint. The default API endpoint name is randomly generated, difficult to recall, and not user-friendly.

With custom domain names, you can set up your API's hostname, and choose a base path (for example, myservice) to map the alternative URL to your API. For example, a more user-friendly API base URL can become:

https://dev.codedevops.cloud/

🚀 Step-by-Step Guide
1️⃣ Click on "Custom Domain" and then click the "Create" button.

2️⃣ Enter the domain name you want to use (e.g., dev.codedevops.cloud), select the appropriate ACM certificate, and click "Create Domain."

3️⃣ Click on "Configure API Mapping," select the desired API and stage, and then click "Save."

4️⃣ Go to Route 53 and configure the domain api.codedevops.cloud accordingly.

Invoke the creation of a custom domain name with the Ingress endpoints.

👉🏻 /

👉🏻/metrics

👉🏻/error

Troubleshooting
If you encounter any issues, refer to the AWS documentation or raise an issue in this repository.

🏴‍☠️ source link: https://github.com/ravindrasinghh/Kubernetes-Playlist/tree/master

If you prefer a video tutorial to help guide you to Integrate API Gateway with AWS EKS NLB

Install NGINX Ingress Controller in AWS EKS

Ravindra Singh — Sat, 14 Sep 2024 09:38:13 +0000

This lesson covers the steps to install and configure an NGINX Ingress Controller in your EKS cluster, enabling you to manage external access to your Kubernetes services.

What is an Ingress Controller?
An Ingress is an API object that defines rules for routing external HTTP and HTTPS traffic to services within your cluster. An Ingress Controller is a software component that implements those rules, acting as a reverse proxy and load balancer for your applications.

GIT LINK: https://github.com/ravindrasinghh/Kubernetes-Playlist

How nginx ingress controller works ?

Ingress Resource Creation: You create an Ingress resource in your Kubernetes cluster, specifying how you want to expose your applications to external traffic. This includes details like the hostnames to match, paths to route, and the services to direct traffic to.
Controller Monitoring: The Nginx Ingress Controller continuously monitors the Kubernetes API server for changes to Ingress resources.
Configuration Generation: When it detects new or updated Ingress resources, the controller generates an Nginx configuration file based on the specified rules.
Configuration Update: The controller updates the running Nginx pods with the new configuration file.
Traffic Routing: Nginx acts as a reverse proxy, receiving incoming traffic and routing it to the appropriate backend services based on the Ingress rules.
Load Balancing: Nginx load balances traffic across multiple pods of the same service, ensuring efficient resource utilization and high availability.

Key points about the Nginx Ingress Controller's operation:

Constant Monitoring: The controller continuously monitors the Kubernetes API server for changes to Ingress resources, ensuring Nginx's configuration stays up-to-date with your desired state.
Dynamic Configuration: Nginx configuration is generated dynamically based on Ingress rules, allowing for flexible traffic routing and load balancing

Use an ALB when:

You need advanced HTTP/HTTPS routing: ALBs operate at Layer 7 (Application Layer), allowing you to route traffic based on various HTTP/HTTPS attributes like host headers, path patterns, query parameters, and even HTTP methods. This makes them ideal for microservices architectures where different services may need to be exposed on the same IP address but with distinct paths or hostnames.
You need features like WebSockets, HTTP/2, or gRPC: ALBs fully support these protocols, making them suitable for applications requiring these advanced features.

Use an NLB when:

You need high-performance TCP/UDP load balancing: They are a great fit for applications requiring extreme throughput and responsiveness, like gaming servers, streaming services, or real-time communication platforms.
You need to preserve client source IP addresses: NLBs preserve the original client IP address, which can be crucial for applications that need to identify and track individual clients.

Let's Begin😎

🚀** Prerequisites :**

Terraform: Install Terraform by following the official installation guide.
AWS CLI: Install and configure the AWS CLI by following the AWS CLI installation guide.
kubectl: Install kubectl for interacting with your EKS cluster by following the kubectl installation guide.
A running Kubernetes cluster: This can be a self-managed cluster or a managed service like Amazon EKS.

Refer below video to create the EKS Cluster in AWS

Step1: Clone the Repository

🧑🏻‍💻git clone https://github.com/ravindrasinghh/Kubernetes-Playlist.git
👨🏻‍💻cd Kubernetes-Playlist/Lesson1/

Step 2: Please add the below file to NGINX Ingress Controller

👉🏻 nginx.tf

resource "helm_release" "ingress-nginx" {
  name             = "ingress-nginx"
  repository       = "https://kubernetes.github.io/ingress-nginx"
  chart            = "ingress-nginx"
  namespace        = "ingress-nginx"
  create_namespace = true
  version          = "4.10.0"
  values           = [file("./nginx.yaml")]
  set {
    name  = "controller.service.annotations.service\\.beta\\.kubernetes\\.io/aws-load-balancer-ssl-cert"
    value = module.acm_backend.acm_certificate_arn
    type  = "string"
  }
}

👉🏻 nginx.yaml

controller:
  replicaCount: 2
  minAvailable: 1
  resources:
    limits:
      cpu: 500m
      memory: 512Mi
    requests:
      cpu: 100m
      memory: 256Mi
  autoscaling:
    enabled: true
    annotations: {}
    minReplicas: 2
    maxReplicas: 6
    targetCPUUtilizationPercentage: 70
    targetMemoryUtilizationPercentage: 80
    behavior:
     scaleDown:
       stabilizationWindowSeconds: 60
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
  service:
    annotations:
      service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp
      service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: 'true'
      service.beta.kubernetes.io/aws-load-balancer-type: nlb
      service.beta.kubernetes.io/aws-load-balancer-ssl-ports: https
      service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy: 'ELBSecurityPolicy-TLS13-1-2-2021-06'
      service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*"
    targetPorts:
      http: http
      https: http

Step 3: Initialize Terraform

terraform init
terraform plan

terraform apply

Step 4: Verifying the Installation

After installation, verify that the Nginx Ingress Controller is running correctly.

kubectl get pods -n ingress-nginx:

kubectl logs ingress-nginx-controller-74fb489d8f-jpvgs -n ingress-nginx:

kubectl get svc -n ingress-nginx:

Access the Load Balancer IP, and if you receive a '404 Not Found' message, that's the expected outcome.

Step5: Creating an Ingress YAML File

Let's create a basic Ingress resource to expose a service named photoap on the hostname photoapp.codedevops.cloud:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  selector:
    matchLabels:
      app: myapp
  replicas: 1
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - image: ravindrasingh6969/nodeapp:latest
        name: myapp
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  ports:
  - port: 80 #service port  #kubeproxy will open port on worker node to which can route traffic to alb
    targetPort: 8080 #container port
    protocol: TCP
  type: ClusterIP
  selector:
    app: myapp
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp
  annotations:
    # Ingress class to use the NGINX Ingress Controlle
    # AWS-specific annotations for SSL and the load balancer
    alb.ingress.kubernetes.io/scheme: "internet-facing"
    alb.ingress.kubernetes.io/target-type: "ip"
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
    alb.ingress.kubernetes.io/certificate-arn: "arn:aws:acm:ap-south-1:434605749312:certificate/0245c0a5-0867-4372-8206-4a5e4ceda0bd"
    alb.ingress.kubernetes.io/ssl-redirect: '443'
spec:
  ingressClassName: nginx
  rules:
    - host: myapp.codedevops.cloud
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: myapp
                port:
                  number: 80

Additional Paths: I added /health, /status, and /api/v1 as additional paths to route traffic to the myapp service on port 80.
Single Host: The configuration uses a single host
(myapp.ravindra.tech) to handle multiple paths.
Uniform Backend Service: All paths are routed to the same backend service (myapp), which listens on port 80.

This setup will handle requests for the specified paths (/, /ping, /metrics, /health, /status, /api/v1) and route them to the myapp service on port 80, providing flexibility for different endpoints within your application.

Creating Records in Route 53

To make your application accessible via the hostname specified in the Ingress, you'll need to create a DNS record in Route 53, Amazon's managed DNS service.

Create a Hosted Zone: If you don't have one already, create a hosted zone for your domain (e.g., codedevops.cloud) in Route 53.
Create an A Record: Create an A record within your hosted zone, pointing the hostname (myapp.codedevops.cloud) to the external IP address of the Nginx Ingress Controller's Service. You can obtain this IP/ARN using kubectl get service -n ingress-nginx.

Hit Public Domain for the verification

https://myapp.codedevops.cloud/ping:

https://myapp.codedevops.cloud/metrics:

https://myapp.codedevops.cloud/error:

Troubleshooting

If you encounter any issues, refer to the Nginx ingress documentation or raise an issue in this repository.

🏴‍☠️ source link: https://github.com/ravindrasinghh/Kubernetes-Playlist/tree/master

If you prefer a video tutorial to help guide you Install NGINX Ingress Controller in AWS EKS