Moving beyond the terminal to master Blue/Green and Canary deployments in a Cloud-Native world.

The “Black Box” Problem​

In the world of Kubernetes, Service Meshes like Istio are often treated as “magic.” We apply a VirtualService YAML, change a weight from 0 to 10, and trust that traffic is moving correctly behind the scenes.

But for many engineers, this remains a black box. When a Canary rollout fails or a Blue/Green switch causes a spike in 500 errors, the lack of visual intuition can lead to slow incident response times.

As the founder of Kubelancer, I’ve seen teams struggle with the “conceptual gap” of traffic shifting. Understanding the theory is one thing; seeing a packet hit a VirtualService and get routed to a specific pod version is another.

That’s why I decided to build Kubelancer Labs — a zero-setup, interactive playground to simulate Istio traffic logic.

What can you do in the lab?​

You can visualize the traffic management

Blue/Green: Switch traffic instantly and practice emergency rollbacks.

Canary Rollouts: Incrementally shift traffic (10% → 50% → 100%) and watch the pods react.

Fault Simulation: Trigger “500 Errors” to see how Istio protects the user experience.

No terminal. No YAML. Just pure logic and visualization.

Check it out live here:​

👉 https://bala-kubelancer.github.io/kubelancer-labs-simulations/​

👉 Originally published on Medium: Read more

Ensuring Business Continuity in a Crisis. In today’s digital-first world, High Availability (HA) and Fault Tolerance (FT) are designed to keep applications up and running. But what if an entire region goes down due to a flood or a power grid outage, or other reasons?

This is where a Disaster Recovery (DR) strategy becomes critical for ensuring business continuity. A well-designed DR plan ensures sufficient resources are available in entirely different regions, countries, or even continents.

RTO and RPO: The Foundation of DR Planning​

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

When planning DR, two key metrics must be defined:
============================================
1. Recovery Time Objective (RTO): How much downtime a business can sustain without significant impact.

2. Recovery Point Objective (RPO): How much data loss a business can tolerate.

The design of RTO and RPO depends on business criticality.

For example:
A stock trading platform, railway system, or airline booking system cannot afford to lose a single data point.

DR Approaches:​

=============

— Backup & Restore:

The least costly option with maximum RTO and RPO.
Application machine images and database snapshots should be stored in the DR site.
In the event of DR, systems are restored from backups.

— Warm Standby:

All application servers and databases exist in the DR site with low capacity.
Data is continuously synced from the primary.
In case of DR, services can be scaled up at the DR site.
Offers lower RTO and RPO compared to backup & restore.

— Multi-Site (Active-Active):

Most advanced and resilient DR strategy.
Provides zero RTO and RPO.
Equal capacity is maintained at both sites.
Traffic is distributed across regions.
In case of failure, all traffic is routed locally without downtime.

Final Thoughts:
============
A robust Disaster Recovery plan is not just about technology — it’s about protecting your business, customers, and reputation. The choice between Backup & Restore, Warm Standby, and Multi-Site depends on business needs, compliance, and cost.

Ask yourself:
============
How much downtime can your business afford? (RTO)
How much data loss can your business tolerate? (RPO)

:) Happy Computing​

👉 Originally published on Medium: Read more

Short answer up front:​

* Use ALB (AWS Application Load Balancer) at the edge for almost all HTTP/HTTPS microservices workloads. It gives host/path routing, TLS offload, WebACL/WAF, and better request-level features that microservices typically need.

* Use NLB only when you need true L4 passthrough, extremely low latency very high connection scale, UDP/TCP workloads, or when preserving source IP is critical and simpler setup is preferred.

* Hybrid (ALB at edge + internal NLB) is a great compromise when you need ALB features at the edge but want NLB performance for specific internal high-throughput services.

Why microservices usually favour ALB ?​

Microservices architectures typically expose many small HTTP/HTTPS services, use host- and path-based routing (e.g., api.example.com/users, api.example.com/payments), use TLS, and often require features like:

— per-host routing (virtual hosts)
 — path-based routing and rewriting
 — TLS termination with ACM and easy certificate management
 — Web Application Firewall (WAF) protections at the edge
 — HTTP features: websockets, HTTP/2, header manipulation, redirect rules
easy integration with Gateway API for Kubernetes-native routing
ALB provides all of these natively.

When to pick NLB instead?​

Pick NLB when one of the following is true:

— Your services are TCP/UDP (non-HTTP) or need pure L4 passthrough. Examples: raw TCP proxies, some legacy protocols, high-volume TCP streaming.

— You need lowest possible latency and the highest concurrent connection scale (NLB is optimized for L4).

— You want simple Service annotation deployment without installing AWS Load Balancer Controller (fast setup).

— You want to preserve source client IP easily and reliably for backend services.

NLB is simpler for L4 and usually cheaper for pure throughput scenarios, but it lacks L7 routing and WAF.

👉 Originally published on Medium: Read more

Over the decades of working as a Cloud and DevOps Architect, I’ve realized that this role is not just about technology — it’s about building reliable, scalable, and secure systems that truly support business goals.

Today, organizations expect Cloud plus DevOps architects like us to balance innovation with practicality, design with delivery, and speed with stability.

Every design choice impacts how well a system performs, scales, and recovers — and how safe it keeps business data.

Some of the key habits I lean in every day professional life

Try to understand the Business Problem, how to suit the right technology and tools​

Before choosing a tool or platform, I first try to understand the why.

Every technical decision — from infrastructure to automation — must align with business needs such as cost, scalability, and timelines.

As a Cloud Architect, my job is to provide solutions that solve real business problems while handling constraints like budget, compliance, and delivery schedules.

Address Project Non-Functional Needs​

Beyond functionality, I always design for what’s not visible but critical:

• Scalability — Can it grow seamlessly when demand spikes?
• High availability — Will it stay up if something fails?
• Performance — Does it respond fast under pressure?
• Security — Is data safe at every layer?
• Maintainability — Can teams manage it easily later?

These non-functional aspects often define whether a system succeeds in the long run.

Use Prototypes and Proofs of Concept (POCs)​

Before going full scale, I generally build prototypes to validate the design approach.

This helps me and my team identify risks early, test assumptions, and ensure we are choosing the right strategy before major investments are made.

Don’t Just Build Systems, Also Mentor Teams​

Technology evolves fast, and so should the people behind it.

I work closely with developers, operations, and security engineers to ensure everyone understands the “why” behind design decisions & how to maintain those systems post-launch.

Balance Strategy and Operations​

Being an architect means thinking both long-term and day-to-day.

• Strategic View: Create solutions that remain relevant as technology and business evolve.
• Operational View: Ensure today’s workloads run smoothly and handle current business challenges without issues.

It’s this balance that turns architecture into value.

Design with Compliance and Global Reach in Mind​

When deploying globally, every region comes with its own laws and compliance requirements.

Whether it’s PCI DSS for finance, HIPAA for healthcare, or ISO standards for manufacturing …many more, compliance has to be baked into design — not added later.

Plan for:

• Data locality and residency laws
• Encryption (in transit and at rest)
• Identity and access management (IAM)
• Secure audit logging and traceability

Compliance isn’t paperwork — it’s part of security architecture.

Tighten the Security at Every Layer of infra​

Security is a continuous process, not a one-time setup.

I design with the principle of least privilege, and integrate security into every phase of development and operation.

Key practices I rely on:

• Enforce IAM roles and fine-grained permissions
• Use secret managers and encrypted storage
• Automate patching and vulnerability scanning
• Implement Web Application Firewalls (WAF) and security groups
• Enable audit logging, SIEM integration, and intrusion detection
• Adopt shift-left security — embedding security checks in CI/CD

Security must evolve with the application — not lag behind it.

Automate Everything as much as Possible​

Automation is at the heart of both Cloud and DevOps practices.

Automation applies everywhere — infrastructure provisioning, deployments, testing, patching, and even security checks.

As a DevOps Architect, I ensure:

• Infrastructure as Code (IaC) manages resources predictably.
• CI/CD pipelines are robust and reliable.
• Automated security scans and policy enforcement
• Automated rollback and self-healing mechanisms
• Monitoring and alerts automatically notify teams about issues or failures.

It helps reduce human error, increase speed, and maintain consistency.

Ensure End-to-End Monitoring and Observability​

A system you can’t see is a system you can’t trust.

I make sure every deployment includes:

• Centralized logging (application + infrastructure)
• Metrics collection (CPU, memory, latency, request rate)
• Alerting and dashboards using tools like Prometheus, Grafana, and New Relic
• Distributed tracing for performance bottlenecks
• Synthetic monitoring for uptime and user experience

Monitoring is the backbone of reliability — it helps teams act before customers notice issues.

Keep an eye regularly on Cloud Cost Page​

Every solution has a cost — both upfront (CapEx) and ongoing (OpEx).

As part of my process, I provide clear cost estimations, help plan budgets, and continuously optimize infrastructure to reduce waste and improve efficiency.

Design for Resilience and Disaster Recovery​

Downtime is never an option. From day one, I plan for failure.

Systems should recover automatically or gracefully during incidents.

I define:

• RPO (Recovery Point Objective): How much data can we afford to lose?
• RTO (Recovery Time Objective): How fast can we recover?
• Backup and failover strategies across regions
• Testing DR drills regularly to validate recovery plans

Because resilience isn’t proven in design — it’s proven in a disaster.

So plan for both RPO (Recovery Point Objective) and RTO (Recovery Time Objective) from day one.

That means preparing for data recovery, failover systems, and having tested backup strategies — ensuring the business stays operational even during outages.

Continuously Optimize and Evolve​

Cloud technology changes daily.

I make it a habit to continuously explore new features from AWS, Azure, and GCP

— applying what fits best to improve cost, performance, and reliability.

— Continuous improvement isn’t just a technical habit — it’s a mindset.

Good architecture is invisible when it works, but invaluable when it fails.

Happy Cloud Computing :)​

Thanks for reading!

Follow me on [LinkedIn] https://www.linkedin.com/in/bala-kubelancer/

👉 Originally published on Medium: Read more

Error: failed to create kubernetes rest client for read of resource: Get “https://xxxxxxx.gr7.us-east-1.eks.amazonaws.com/api?timeout=32s": getting credentials: exec: executable aws failed with exit code 255

Most Terraform users might have seen this 255 error. Suddenly, for some reason, Terraform will surprise us specifically in AWS.

Let’s break down exactly what’s happening:

The problem is mostly with Terraform; try using your local kubeconfig to connect to EKS.

What happened generally?

kubernetes/kubectl/helm provider execute aws eks get-token to get a short-lived authentication token, but it can’t get it due to a few reasons

No Kubernetes REST client could be created

1. could be an issue on AWS credentials
2. If CI/CD, credential env not set correctly/wrongly
3. Your ~/.aws/config or ~/.aws/credentials is missing or invalid.

Let’s Troubleshoot

Try this in your shell:

aws eks get-token --cluster-name your-cluster-name

If this fails, you’ll get a clearer error.

In my case, it worked. Next, I did If you’re using profiles, set:

export_ AWS\_PROFILE=your-profile

export_ AWS_PROFILE=kubelancer-dev

which solved.

then try

terraform plan  
terraform apply

👉 Originally published on Medium: Read more

As Kubernetes adoption grows, so does the complexity of managing clusters efficiently. One common challenge is choosing the right EC2 instance types that balance performance, cost, and availability. Enter Karpenter, AWS’s open-source cluster autoscaler, designed to simplify and optimize Kubernetes infrastructure provisioning.

In this blog post, How Kubelancer, we implemented hybrid instance strategy using Karpenter on AWS EKS Cluster for our esteemed client, ton maximize performance while minimizing costs in production, if non-prod can think about spot fleet.

Generally, Karpenter addresses these challenges:

1. Rapid provisioning: Instantly launching nodes when needed.

2. Cost optimization: Choosing the most cost-effective instance types.

3. Workload-aware scaling: Allocating resources based on real-time workload requirements.

4. Support for Spot Instances: Reducing costs further by leveraging EC2 Spot Instances.

But how can we unlock its full potential? Hybrid instance strategies hold the key.

The Challenge: Cost vs. Performance in Kubernetes​

Kubernetes workloads vary in their resource requirements. Some applications are CPU-intensive, requiring high compute power, while others are memory-heavy, needing more RAM to function efficiently. If you stick to a single instance type, you may either:

1. Over-provision of resources, leading to wasted costs.
2. Under-provision resources, resulting in performance issues.

Let us Understanding Hybrid Instance Strategies​

A hybrid instance strategy involves mixing different EC2 instance families based on workload needs. For example:

• Compute-optimized instances (c7i.large): Ideal for CPU-heavy applications.
• General-purpose instances (m7i.large): Perfect for balanced workloads requiring a blend of CPU and memory.

By blending these instances, you avoid over-provisioning and ensure that each workload gets precisely the resources it needs.

Our Workload Analysis: (example 3 microservices)​

Imagine managing three critical microservices in an EKS cluster:

1. service-order

CPU Usage: High (1819m per pod)

Memory Usage: Low (~1.3 GiB per pod)

Best Fit: c7i.large for compute efficiency.

2. service-user

CPU Usage: Moderate (1830m per pod)

Memory Usage: Moderate (~2.4 GiB per pod)

Best Fit: c7i.large to optimize for CPU-bound processes.

3. service-search

CPU Usage: High (1805m per pod)

Memory Usage: Moderate (~3.7 GiB per pod)

Best Fit: m7i.large for a balanced approach.

Why did Kubelancer, chose the Hybrid Approach Works?​

By mixing c7i.large and m7i.large instances, we will:

1. Reduce Costs: Compute-optimized instances are cheaper for CPU-heavy tasks.
2. Right-Size Resources: Memory-heavy applications get more memory-rich instances without wasting CPU capacity.
3. Ensure High Availability: Multiple instance types provide fault tolerance and flexibility during provisioning.

Performance & Cost Results​

After we implemented this hybrid strategy:

• Resource Efficiency: Workloads are provisioned based on exact resource needs.
• Cost Savings: Reduced over-provisioning leads to lower monthly bills.
• Performance Gains: High CPU workloads get dedicated compute-optimized nodes.
• Flexibility: Karpenter’s dynamic scaling ensures adaptability to traffic spikes.

Karpenter, Every DevOps Engineer Infra Game Changer:​

After we implemented the Hybrid Instance Strategy for AWS EKS powered by Karpenter, it is a game-changer for our microservices cloud-native applications. we achieved cost savings, better resource utilisation, and enhanced performance.

N‍ext Blog, Let us see how to implement….

👉 Originally published on Medium: Read more

Simple fanout / Path Based Ingress - Demo​

Expose multiple services by using single IP address.

Create three deployment and services.​

vi simplesite-deployment-services.yaml

apiVersion: apps/v1  
kind: Deployment  
metadata:  
  name: home-deployment  
spec:  
  replicas: 1  
  selector:  
    matchLabels:  
      app: home  
  template:  
    metadata:  
      labels:  
        app: home  
    spec:  
      containers:  
        - name: home-container  
          image: kubelancer/simplehome:v1.0.0  
          ports:  
            - containerPort: 8080  
          env:                    
            - name: HOME\_SERVICE\_URL  
              value: "http://home-service:8080"  
            - name: BLOG\_SERVICE\_URL  
              value: "http://blog-service:8081"  
            - name: SERVICES\_SERVICE\_URL  
              value: "http://services-service:8082"  
\---  
apiVersion: v1  
kind: Service  
metadata:  
  name: home-service  
spec:  
  selector:  
    app: home  
  ports:  
    - protocol: TCP  
      port: 8080  
      targetPort: 8080  
  type: ClusterIP  
\---  
apiVersion: apps/v1  
kind: Deployment  
metadata:  
  name: blog-deployment  
spec:  
  replicas: 1  
  selector:  
    matchLabels:  
      app: blog  
  template:  
    metadata:  
      labels:  
        app: blog  
    spec:  
      containers:  
        - name: blog-container  
          image: kubelancer/simpleblog:v1.0.0  
          ports:  
            - containerPort: 8081  
          env:  
            - name: HOME\_SERVICE\_URL  
              value: "http://home-service:8080"  
            - name: BLOG\_SERVICE\_URL  
              value: "http://blog-service:8081"  
            - name: SERVICES\_SERVICE\_URL  
              value: "http://services-service:8082"  
\---  
apiVersion: v1  
kind: Service  
metadata:  
  name: blog-service  
spec:  
  selector:  
    app: blog  
  ports:  
    - protocol: TCP  
      port: 8081  
      targetPort: 8081  
  type: ClusterIP  
\---  
apiVersion: apps/v1  
kind: Deployment  
metadata:  
  name: services-deployment  
spec:  
  replicas: 1  
  selector:  
    matchLabels:  
      app: services  
  template:  
    metadata:  
      labels:  
        app: services  
    spec:  
      containers:  
        - name: services-container  
          image: kubelancer/simpleservices:v1.0.0  
          ports:  
            - containerPort: 8082  
          env:  
            - name: HOME\_SERVICE\_URL  
              value: "http://home-service:8080"  
            - name: BLOG\_SERVICE\_URL  
              value: "http://blog-service:8081"  
            - name: SERVICES\_SERVICE\_URL  
              value: "http://services-service:8082"  
\---  
apiVersion: v1  
kind: Service  
metadata:  
  name: services-service  
spec:  
  selector:  
    app: services  
  ports:  
    - protocol: TCP  
      port: 8082  
      targetPort: 8082  
  type: ClusterIP

• Apply the deployment and services

kubectl apply -f simplesite-deployment-services.yaml

• List deployment,pods,svc

kubectl get deployment,pod,svc -o wide

Output​

Create ingress (path-based)​

vi ingress-pathbased.yaml

\---  
apiVersion: networking.k8s.io/v1  
kind: Ingress  
metadata:  
  name: ingress-pathbased  
  namespace: default  
spec:  
  ingressClassName: nginx  
  rules:  
  - host: tify.kubelancer.com  
    http:  
      paths:  
      - path: /  
        pathType: Prefix  
        backend:  
          service:  
            name: home-service  
            port:  
              number: 8080  
      - path: /blog  
        pathType: Prefix  
        backend:  
          service:  
            name: blog-service  
            port:  
              number: 8081  
      - path: /services  
        pathType: Prefix  
        backend:  
          service:  
            name: services-service  
            port:  
              number: 8082

• Apply the ingress

kubectl apply -f ingress-pathbased.yaml

• Get ingress

kubectl get ingress

Output​

Validate​

Home Page

curl -i  --resolve tify.kubelancer.com:80:192.168.10.0 tify.kubelancer.com

Blog Page

curl -i  --resolve tify.kubelancer.com:80:192.168.10.0 tify.kubelancer.com/blog

Services Page

curl -i  --resolve tify.kubelancer.com:80:192.168.10.0 tify.kubelancer.com/services

Output​

Home

Blog

Service

Happy Computing :)​

👉 Originally published on Medium: Read more

Create AWS EKS Cluster — eksctl​

Creating Kubenetes cluster in AWS have multiple options like using AWS SDK, Terraform, Cloudformation and easy and quick for new learner using AWS Console. In this blog we going see another well know method of creating AWS EKS cluster using “eksctl” command by using as YAML configuration in default VPC. ( Same can be create by CLI command).

Let’s get start​

Prerequisites:​

Let install these binary one by one

1. AWS CLI
2. eksctl CLI
3. kubectl

Step 1. Install AWS CLI (Mac OS)​

Download AWS CLI binary​

curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"

Install AWS CLI​

sudo installer -pkg ./AWSCLIV2.pkg -target /

Verify the installation​

which aws  
aws --version

Step 2. Configure AWS CLI​

Step 2.1. Login to AWS console as root user​

Step 2.2. Create IAM user​

username: kubedeveloper

No AWS console access, Only programmatic access

Provide Username

Permission as per User Type

Create Access and SecretAccessKey​

Step 2.3 Select the IAM user “kubedeveloper”​

Step 2.4 Navigate to Security Credentials​

Step 2.5. Click Create access key​

Step 2.6 Select Use case :​

Command Line Interface (CLI) & check the Confirmation

Step 2.7. Set description tag — optional and Click create​

Now we got AccessKey and SecretAccessKey,

Next, Let configure AWS CLI on Mac OS command line​

Note: if multiple aws account configured, use — profile

$ aws configure

Validate AWS CLI Access​

Run any aws command to list resources

Here eg: To list s3 buckets on my AWS account

bala@kubelancer Downloads % aws s3 ls

Getting output, which denoted AWS access has been configured correctly​

bala@kubelancer Downloads % aws s3 ls  
2022-12-13 21:36:02 firehose-backup-05bf6840

Install eksctl on Mac OS​

To download the latest release, run on Mac OS (arm64 architecture):​

curl -sLO "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl\_Darwin\_arm64.tar.gz"  
tar -xzvf eksctl\_Darwin\_arm64.tar.gz  
sudo mv ./eksctl /usr/local/bin

Ref: https://www.weave.works/oss/eksctl/

Step 3: Creating an AWS EKS Kubernetes Cluster using eksctl tool​

3.1. Create Cluster configuration yaml file​

$ vi cluster-config.yaml

apiVersion: eksctl.io/v1alpha5  
kind: ClusterConfig  
  
metadata:  
  name: kubelancer-cluster-1  
  region: us-east-1  
  
nodeGroups:  
  - name: ng-1  
    instanceType: t4g.medium  
    desiredCapacity: 2  
    volumeSize: 20  
    ssh:  
      allow: false

3.2 Let’s create eks cluster on aws using eksctl command​

$ eksctl create cluster -f cluster-config.yaml

Cluster created successfully

Note: if multiple aws account configured, use — profile

Get the cluster name by using eksctl command​

eksctl interact with AWS API and get the required details from AWS cloud

$ eksctl get cluster --profile kubedev

Use the following command to get update kube-config.​

$ aws eks update-kubeconfig --name=kubelancer-cluster-1 --region=us-east-1

Verify the Cluster​

kubectl get nodes

Cluster Node Status

Delete Cluster​

$ kubectl get poddisruptionbudget -A  
$ kubectl delete poddisruptionbudget coredns -n kube-system  
$ eksctl delete cluster -f cluster-config.yaml --profile kubedev

Happy Computing :)​

👉 Originally published on Medium: Read more

Step 1: Create an AWS EKS Cluster​

kubectl get node

Step 2: Enable Kubecost add-on using AWS CLI​

aws eks create-addon --addon-name kubecost\_kubecost --cluster-name kube-cluster-3 --region us-east-1

Step 3: Deploying Kubecost on an Amazon EKS cluster using Helm​

Step 3.1: Install Prerequisites

eksctl create iamserviceaccount   \\  
    --name ebs-csi-controller-sa   \\  
    --namespace kube-system   \\  
    --cluster kube-cluster-3  \\  
    --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy  \\  
    --approve \\  
    --role-only \\  
    --role-name AmazonEKS\_EBS\_CSI\_DriverRole  
      
export_ SERVICE\_ACCOUNT\_ROLE\_ARN=$(aws iam get-role --role-name AmazonEKS\_EBS\_CSI\_DriverRole --output json | jq -r '.Role.Arn')

Step 3.2: Install the Amazon EBS CSI add-on for EKS using the AmazonEKS_EBS_CSI_DriverRole

eksctl create addon --name aws-ebs-csi-driver --cluster kube-cluster-3 \\  
    --service-account-role-arn $SERVICE\_ACCOUNT\_ROLE\_ARN --force

Step 3.3: Install Kubecost on your Amazon EKS cluster

helm upgrade -i kubecost \\  
oci://public.ecr.aws/kubecost/cost-analyzer --version "1.104.4" \\  
\--namespace kubecost --create-namespace \\  
\-f https://raw.githubusercontent.com/kubecost/cost-analyzer-helm-chart/develop/cost-analyzer/values-eks-cost-monitoring.yaml

Step 4: Generate Kubecost dashboard endpoint using port-forward​

kubectl port-forward --namespace kubecost deployment/kubecost-cost-analyzer 9090

Step 5: Access Monitoring dashboards​

http://localhost:9090

Happy computing :)​

👉 Originally published on Medium: Read more

This guide provides a step-by-step tutorial on setting up TLS with Nginx Ingress on AWS EKS clusters using Let’s-Encrypt

Expose a Kubernetes service with TLS using NGINX Ingress on AWS EKS

Step 1: Create an AWS EKS Cluster​

AWS EKS Kubernetes Cluster using “eksctl” Command​

1: Install AWS CLI (Mac OS)

Download the AWS CLI binary

curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"

2: Install

sudo installer -pkg ./AWSCLIV2.pkg -target /

3: Verify the installation

which aws  
  
aws --version

4: Configure AWS CLI

Login to AWS console as root / Admin privileged IAM user

Create IAM user

username: kubedeveloper

No AWS console access, only programmatic access

Username

User permission

Create user

5: Create Access and Secret Access Key

Select the IAM user kubedeveloper

Navigate to Security Credentials

Create Security Credentials

Click Create Access Key

Access Key

Select Use case: Command Line Interface (CLI) & check the Confirmation

Use Case for Security Credentials

Set description tag — optional and Click Create

Download Credentials

6: Configure AWS CLI on Mac OS command line

aws configure

7: Install eksctl on Mac OS

To download the latest release, run on Mac OS (arm64 architecture):

curl -sLO "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl\_Darwin\_arm64.tar.gz"  
  
tar -xzvf eksctl\_Darwin\_arm64.tar.gz  
  
sudo mv ./eksctl /usr/local/bin

Ref: https://www.weave.works/oss/eksctl/

8: Creating an AWS EKS Kubernetes Cluster using eksctl

Create Cluster configuration YAML file

vi cluster-config.yaml

apiVersion: eksctl.io/v1alpha5  
kind: ClusterConfig  
  
metadata:  
  name: kubelancer-cluster-2  
  region: us-east-1  
  
nodeGroups:  
  - name: ng-1  
    instanceType: t4g.small  
    desiredCapacity: 2  
    volumeSize: 10  
    ssh:  
      allow: false

Let’s create an EKS Cluster on AWS using eksctl command

eksctl create cluster -f cluster-config.yaml

Use the following command to get kube-config context

aws eks update-kubeconfig --name=kubelancer-cluster-2 --region=us-east-1

kubectl get node

Step 2: Deploy the NGINX Ingress Controller​

1. Create Name space and deploy

kubectl create namespace ingress-nginx

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.2/deploy/static/provider/cloud/deploy.yaml

Pre-flight check

kubectl get pods -n ingress-nginx

Output

List Service

kubectl get svc --namespace=ingress-nginx

Output

Step 3: Deploy a sample application​

1. Deploy sample app on dev namespace

kubectl create ns dev

vi kubewebserver.yaml  

apiVersion: apps/v1  
kind: Deployment  
metadata:  
  name: kubewebserver  
  namespace: dev  
  labels:  
    app: kubewebserver  
spec:  
  replicas: 1  
  selector:  
    matchLabels:  
      app: kubewebserver  
  template:  
    metadata:  
      labels:  
        app: kubewebserver  
    spec:  
      containers:  
      - name: kubewebserver  
        image: kubelancer/hello-kubelancer:v1  
        ports:  
        - containerPort: 80  
\---  
apiVersion: v1  
kind: Service  
metadata:  
  name: kubewebserver-service  
  namespace: dev  
  labels:  
    app: kubewebserver-service  
spec:  
  type: ClusterIP  
  ports:  
  - port: 80  
    targetPort: 80  
    protocol: TCP  
  selector:  
    app: kubewebserver

kubectl apply -f kubewebserver.yaml

Output

kubectl get deploy,svc -n dev

Step 4: Create ingress without TLS​

vi ingress-with-host.yaml

apiVersion: networking.k8s.io/v1  
kind: Ingress  
metadata:  
  name: ingress-with-host-02  
  namespace: dev  
  annotations:  
    nginx.ingress.kubernetes.io/rewrite-target: /  
spec:  
  ingressClassName: nginx  
  rules:  
  - host: webtest.kubelancer.in  
    http:  
      paths:  
      - path: /  
        pathType: Prefix  
        backend:  
          service:  
            name: kubewebserver-service  
            port:  
              number: 80

kubectl apply -f ingress-with-host.yaml

Output

kubectl get ingress -n dev

Note: Create CNAME record on your DNS for name resolution

Output​

curl http://webtest.kubelancer.in

curl http://webtest.kubelancer.in  
Hello Kubelancer

Let we perform below steps to access same website using https://

To config SSL, we are going to use Cert-Manager and Let’s Encrypt in this Lab​

In simple:

Cert Manager​

cert-manager creates TLS certificates for workloads in your Kubernetes, also helps to renew the certificate.

cert-manager obtain certificates from a Let’s Encrypt.

Let’s Encrypt​

To enable HTTPS for website, we need to purchase SSL certificate from Certificate Authority, which is costable. For demo or development environment, we have a choice to use free Certificate Authority (CA), that guy is Let’s Encrypt.

Step 5: Deploy cert-manager​

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.4/cert-manager.yaml

Output

kubectl get pods --namespace cert-manager

Step 6: Configure a Let’s Encrypt Issuer​

apiVersion: cert-manager.io/v1  
kind: Issuer  
metadata:  
  name: letsencrypt-prod  
  namespace: dev  
spec:  
  acme:  
    server: https://acme-v02.api.letsencrypt.org/directory  
    email: noreply@gmail.com   
    privateKeySecretRef:  
      name: letsencrypt-prod  
    solvers:  
      - http01:  
          ingress:  
            ingressClassName: nginx

kubectl create -f issuer.yaml

kubectl get issuer -n dev

Note: Ensure the issuer is in Ready State

Step 7: Add TLS snippet on YAML and deploy Ingress Resource​

vi ingress-with-host.yaml

apiVersion: networking.k8s.io/v1  
kind: Ingress  
metadata:  
  name: ingress-with-host-02  
  namespace: dev  
  annotations:  
    nginx.ingress.kubernetes.io/rewrite-target: /  
    cert-manager.io/issuer: "letsencrypt-prod"  
spec:  
  ingressClassName: nginx  
  tls:  
  - hosts:  
    - webtest.kubelancer.in  
    secretName: kubewebserver-tls  
  rules:  
  - host: webtest.kubelancer.in  
    http:  
      paths:  
      - path: /  
        pathType: Prefix  
        backend:  
          service:  
            name: kubewebserver-service  
            port:  
              number: 80

kubectl apply -f ingress-with-host.yaml

kubectl get secret -n dev

Step 8: Output​

Open in browser

Now the website has secure connection

Now the website has a secure encrypted connection using SSL​

Happy Computing :)​

👉 Originally published on Medium: Read more