Recently, we faced a significant challenge with our AWS EKS setup. Due to cross-AZ (Availability Zone) traffic, networking costs escalated.

Our high-workload application, built using Node.js and PHP, processes a large number of concurrent requests. The dynamic nature of this workload often triggers auto-scaling events, further adding to the complexity of resource management.

The application interacts with Redis, MySQL, and MongoDB, all deployed in Stateful Sets with PVs and PVCs. These databases are distributed across three AZs to ensure high availability and fault tolerance.

However, the frequent queries from the application combined with database traffic crossing AZ boundaries significantly contributed to increased networking costs.

This blog outlines the root causes, the solutions we explored, and actionable steps to optimize networking costs while maintaining high availability and resilience.

Breaking Down EKS Costs

When using AWS EKS, several cost components come into play:

1. EKS Management Fee:

AWS charges a flat fee of $0.10 per hour per cluster, which translates to approximately $73 per month per cluster, regardless of the size of the cluster. This fee covers the managed control plane, which includes components like the Kubernetes API server and etcd for managing cluster state.

2. EC2 Node Costs:

EKS requires worker nodes (EC2 instances) to run your workloads. The cost of these nodes depends on:

• Instance type (e.g., t2.medium, m5.large).

• Number of nodes in your cluster.

• Uptime of these nodes.
  Additionally, costs can increase if you enable auto-scaling, as the cluster adds nodes dynamically based on workload demand.

3. Networking Costs:

Networking is amongst the most significant contributors to EKS costs, especially in setups using multiple AZs. Key contributors include:

• Cross-AZ Data Transfer: AWS charges $0.01 per GB for data transfer between AZs. This cost can quickly add up when running services like databases that frequently communicate across AZs.

• Inter-VPC Traffic: If your EKS cluster interacts with other VPCs or external services, you’ll incur additional charges.

• Elastic Load Balancer (ELB): Any ingress traffic into the cluster using an ELB incurs data transfer costs, which are billed separately.

4. Persistent Storage Costs:

Stateful workloads, such as databases, rely on storage like Amazon EBS (Elastic Block Store) for data persistence. Costs depend on:

• Volume size and type (e.g., General Purpose SSD, Provisioned IOPS).

• Snapshot storage for backups.

• IOPS charges for higher-performance workloads.

5. Additional Services:

• CloudWatch: For logging and monitoring, AWS charges for log ingestion, storage, and data retrieval.

• Data Transfer Out: Traffic leaving AWS (e.g., to the internet or external systems) is billed at $0.09 per GB for the first 10TB each month.

Tip: To manage DNS configurations with your AWS EKS, you can refer to our article on Deploying External DNS with AWS EKS, which explores efficient integration strategies to manage wast amount of DNS.

Solutions Explored

To address these issues, we considered multiple approaches:

1. Topology-Aware Service Routing

• Objective: Ensure traffic remains within the same AZ whenever possible.

• Implementation: Enable Service Topology in Kubernetes by annotating services to route traffic to pods within the same AZ.

Benefits:

• Reduced cross-AZ traffic for database queries.

• Improved latency due to AZ-local traffic.

2. Caching Frequently Accessed Data

• Objective: Reduce the frequency of repetitive queries to the database.

• Implementation:

• Integrate Redis as a cache layer for read-heavy operations.

• Use application-level caching with TTLs for frequent queries.

Benefits:

• Significantly reduced database queries.

• Improved response times for cached data.

Our high-workload application, built using Node.js and PHP, processes a large volume of concurrent requests. The dynamic nature of this workload often triggers auto-scaling events, further adding to the complexity of resource management.

The application interacts with Redis, MySQL, and MongoDB, all deployed in Stateful Sets with PVs and PVCs. These databases are distributed across three AZs to ensure high availability and fault tolerance.

However, the frequent queries from the application combined with database traffic crossing AZ boundaries significantly contributed to increased networking costs.

This blog outlines the root causes, the solutions we explored, and actionable steps to optimize networking costs while maintaining high availability and resilience.

Breaking Down EKS Costs

When using AWS EKS, several cost components come into play:

1. EKS Management Fee:

AWS charges a flat fee of $0.10 per hour per cluster, which translates to approximately $73 per month per cluster, regardless of the size of the cluster. This fee covers the managed control plane, which includes components like the Kubernetes API server and etcd for managing cluster state.

2. EC2 Node Costs:

EKS requires worker nodes (EC2 instances) to run your workloads. The cost of these nodes depends on:

• Instance type (e.g., t2.medium, m5.large).

• Number of nodes in your cluster.

• Uptime of these nodes.
  Additionally, costs can increase if you enable auto-scaling, as the cluster adds nodes dynamically based on workload demand.

3. Networking Costs:

Networking is amongst the most significant contributors to EKS costs, especially in setups using multiple AZs. Key contributors include:

• Cross-AZ Data Transfer: AWS charges $0.01 per GB for data transfer between AZs. This cost can quickly add up when running services like databases that frequently communicate across AZs.

• Inter-VPC Traffic: If your EKS cluster interacts with other VPCs or external services, you’ll incur additional charges.

• Elastic Load Balancer (ELB): Any ingress traffic into the cluster using an ELB incurs data transfer costs, which are billed separately.

4. Persistent Storage Costs:

Stateful workloads, such as databases, rely on storage like Amazon EBS (Elastic Block Store) for data persistence. Costs depend on:

• Volume size and type (e.g., General Purpose SSD, Provisioned IOPS).

• Snapshot storage for backups.

• IOPS charges for higher-performance workloads.

5. Additional Services:

• CloudWatch: For logging and monitoring, AWS charges for log ingestion, storage, and data retrieval.

• Data Transfer Out: Traffic leaving AWS (e.g., to the internet or external systems) is billed at $0.09 per GB for the first 10TB each month.

Tip: To manage DNS configurations with your AWS EKS, you can refer to our article on Deploying External DNS with AWS EKS, which explores efficient integration strategies to manage wast amount of DNS.

Solutions Explored

To address these issues, we considered multiple approaches:

1. Topology-Aware Service Routing

• Objective: Ensure traffic remains within the same AZ whenever possible.

• Implementation: Enable Service Topology in Kubernetes by annotating services to route traffic to pods within the same AZ.

Benefits:

• Reduced cross-AZ traffic for database queries.

• Improved latency due to AZ-local traffic.

2. Caching Frequently Accessed Data

• Objective: Reduce the frequency of repetitive queries to the database.

• Implementation:

• Integrate Redis as a cache layer for read-heavy operations.

• Use application-level caching with TTLs for frequent queries.

Benefits:

• Significantly reduced database queries.

• Improved response times for cached data.

3. Read Replica Configuration

• Objective: Offload read traffic to replicas deployed in each AZ.

Implementation:

• Configure read replicas for MySQL and MongoDB in all AZs.

• Update the application to route read queries to the nearest replica.

Benefits:

• Distributed read traffic.

• Minimized cross-AZ reads for applications.

4. Monitor and Analyze Traffic

• Objective: Identify high-cost traffic patterns and optimize them.

Implementation:

• Use tools like eBPF (via Cilium or similar solutions) to monitor pod-level traffic.

• Visualize traffic patterns with Prometheus and Grafana.

Benefits:

• Insights into cross-AZ traffic contributors.

• Better-informed optimization decisions.

5. Auto-Scaling with Reserved Instances

• Used Reserved Instances for predictable workloads to reduce EC2 costs.

• For dynamic scaling, relied on Spot Instances with fallback to On-Demand Instances to balance cost and availability.

6. Monitoring and Traffic Analysis

• Deployed tools like Prometheus and Grafana to monitor cross-AZ traffic patterns.

• Used eBPF-based tools to analyze network flows and identify expensive traffic routes.

• Optimized Node.js and PHP query patterns based on insights.

7. Efficient EBS Volume Management

• Migrated to GP3 volumes for better cost-performance balance.

• Reduced snapshot frequency to save on storage costs while maintaining adequate backup intervals.

Implementation Example: Topology-Aware Routing

Here’s a quick implementation of topology-aware routing for a MySQL Stateful Set:

1. Annotate the Kubernetes Service:

apiVersion: v1
kind: Service
metadata:
  name: mysql
  annotations:
    topology.kubernetes.io/zone: "true"
spec:
  selector:
    app: mysql
  ports:
    - protocol: TCP
      port: 3306

2. Deploy Pods with Node Affinity:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: topology.kubernetes.io/zone
                    operator: In
                    values:
                      - us-east-1a

3. Migrate Architecture to 2 AZs:

As part of our optimization strategy, we decided to reduce the deployment replicas from three AZs to two AZs. This architectural shift was motivated by the need to:

• Reduce cross-AZ networking costs: With three AZs, application pods, and database instances often communicated across zones, leading to significant cross-AZ data transfer charges.

• Simplify operational overhead: Managing resources across three AZs introduced complexity in terms of monitoring, scaling, and maintaining consistency.

Steps Taken During Migration:

Align Backend Applications and Databases in the Same AZs:

• We grouped our Node.js and PHP application pods and their associated Redis, MySQL, and MongoDB databases within the same AZ.

• This ensured that most traffic between application pods and databases remained within a single AZ, minimizing cross-AZ traffic.

Reconfigure StatefulSets for Zone Awareness:

• The StatefulSets for MySQL and MongoDB were reconfigured with node affinity rules to limit pod placement to the chosen two AZs.

• For example, the affinity configuration ensured MySQL replicas in us-east-1a were primarily accessed by application pods running in us-east-1a.

Redistribute Traffic:

• Traffic patterns were adjusted to route requests to backend pods residing in the same AZ as the database.

• This was achieved using Service Topology and DNS resolution to prioritize local AZ instances.

Leverage Read Replicas for High Availability:

• To maintain availability and fault tolerance after reducing AZs, read replicas were deployed in both AZs.

• This setup ensured that each AZ could independently handle read-heavy traffic in case of a single AZ failure.

Benefits Achieved:

1. Significant Reduction in Networking Costs:

• By ensuring backend pods and database instances resided in the same AZ, we reduced cross-AZ data transfer by over 60%. The remaining cross-AZ traffic was primarily for write replication between database nodes.

2. Improved Application Performance:

• Latency decreased as the traffic between application pods and databases no longer crossed AZ boundaries, leading to faster query execution.

3. Optimized Resource Utilization:

• Consolidating resources across two AZs allowed us to better utilize EC2 instances and scale horizontally within those zones without over-provisioning.

4. Resilient Architecture:

• Despite reducing to two AZs, the use of read replicas and distributed services ensured that the application could still handle AZ failures effectively.

Key Considerations:

• Trade-off Between Availability and Cost: While migrating to two AZs reduced costs, we carefully analyzed the risk of reduced fault tolerance compared to a three-AZ setup. For our workload, the benefits outweighed the risks, as our architecture still adhered to AWS’s high-availability guidelines.

• Database Write Replication Traffic: Since database write operations still required cross-AZ replication to maintain consistency, we evaluated and optimized replication intervals and volumes.

Verify Traffic Patterns:

After migration, we used Prometheus and Grafana to monitor key metrics such as:

• network_tx_bytes: Measured overall traffic between pods and identified any lingering cross-AZ traffic.

• request_latency: Ensured that application response times improved post-migration.

• Custom Dashboards: Created dashboards to visualize traffic patterns, helping us confirm that most communication was now AZ-local.

This migration not only helped reduce costs but also streamlined our operational overhead while ensuring performance and reliability. By taking a systematic approach to reduce the number of AZs and optimize resource placement, we were able to maintain the high availability of our workloads without incurring unnecessary expenses.

Let me know if you’d like further refinements!

Results

After implementing these solutions:

• Cross-AZ traffic dropped by 40%, significantly lowering costs.

• Application response times improved by 20% due to reduced latency.

• The caching layer offloaded 60% of read-heavy operations from the databases.

Summary

In this article, we tackled the challenges of managing cross-AZ traffic costs in an AWS EKS cluster. By implementing topology-aware routing, caching frequently accessed data, and optimizing database configurations, we reduced networking costs and improved application performance.

Monitoring tools like eBPF, Prometheus, and Grafana played a crucial role in identifying and resolving traffic inefficiencies. These strategies can be a starting point for optimizing Kubernetes workloads, especially in multi-AZ deployments.

Developing scalable backend solutions requires a deep understanding of cloud-native architectures and DevOps best practices. Furthermore, it demands composite expertise, robust techniques, and a collaborative approach with a Leading DevOps service provider.

By partnering with experienced DevOps engineers, you can access a comprehensive suite of cloud and backend development services, leverage agile methodologies, and implement advanced optimization techniques tailored to your business needs.

If you’re facing similar challenges or have any questions, feel free to share your experience in the comments!

Why Understanding AWS Infrastructure is Important

by being aware of the basic elements of AWS businesses can fully utilize AWS infrastructure, It guarantees cost-effectiveness, improved security, and peak performance. Let’s take a closer look at the elements that, when combined, can provide effective architecture.

Regions in AWS: Definition and Importance

AWS Regions are large geographical areas that cover multiple Availability Zones. Think of a Region as a continent-sized area, providing a high-level physical separation from other Regions to ensure fault tolerance and stability.

How Regions Works:

Each Region operates independently, allowing you to place resources closer to your end users, which reduces latency and improves performance.

For instance, hosting your application in the US-East-1 Region will provide faster access for users in North America compared to users in Asia.

Selecting the Right Region

Choosing the right Region is critical. Consider factors like proximity to your users, compliance with local regulations, and available services. AWS provides a Region selection tool to help you decide the best location for your needs.

AWS Provides Amazing Handwritten Articles to suggest Aspects to consider while choosing a Region for your Workload.

What are Availability Zones?

Within each AWS Region are multiple Availability Zones. An AZ is essentially a distinct data center with independent power, cooling, and networking. They are designed to be isolated from failures in other AZs.

Benefits of Availability Zones

AZs provide fault tolerance by distributing resources across different physical locations. If one AZ goes down, the others continue operating, ensuring your applications remain available.

How AZs Enhance Resilience and Redundancy

By deploying your applications across multiple AZs, you create a highly available architecture. This setup protects against data loss and service interruptions, as each AZ is designed to be resilient against failures.

Data Centers: The Backbone of AWS

Data centers are the physical facilities where all our AWS infrastructure resides. They contain the servers and networking equipment necessary to run your applications and store your data.

AWS data centers are facilities designed for high availability and security. They are equipped with redundant power supplies, advanced cooling systems, and robust network connectivity.

Security Measures in AWS Data Centers

Security is paramount in AWS data centers. They employ multiple layers of physical and logical security measures, including biometric access controls, surveillance systems, and regular security audits.

Edge Locations: Definition and Purpose

Edge Locations are AWS data centers designed to cache content closer to your users, reducing latency and improving performance. They are part of AWS’s content delivery network (CDN) known as Amazon CloudFront.

Edge Locations vs. Availability Zones

While AZs focus on resilience and redundancy, Edge Locations aim to deliver content quickly. They are strategically placed in major cities worldwide to ensure users get the fastest access to your content.

Enhancing User Experience with Edge Locations

Edge Locations cache static content, such as images and videos, and dynamically accelerate APIs and other web services. This results in faster load times and a smoother user experience.

Global Infrastructure: How AWS Connects the World

AWS’s global infrastructure spans across multiple Regions and AZs, connected by a high-speed, low-latency private network. This vast network ensures that your applications can scale globally with minimal latency.

Network latency is the delay before a transfer of data begins following an instruction for its transfer. AWS minimizes latency by using Edge Locations and strategically placing data centers near major internet hubs.

Real-World Examples of AWS Global Reach

Companies like Netflix and Airbnb use AWS’s global infrastructure to serve millions of users worldwide. AWS enables these companies to deliver seamless and fast services regardless of user location.

Scalability and Flexibility: Scaling Resources with AWS

AWS allows you to scale your resources up or down based on demand. This elasticity ensures you only pay for what you use, making it a cost-effective solution for businesses of all sizes.

Flexibility in Deploying Applications

With AWS, you can deploy applications in various environments, whether on-premises, hybrid, or fully cloud-based. This flexibility helps you adapt to changing business needs and technology advancements.

Security and Compliance: Security Features of AWS

AWS provides a robust security framework, including identity and access management (IAM), encryption, and network firewalls. These features ensure your data and applications are secure.

Compliance Standards

AWS meets numerous compliance standards, such as GDPR, HIPAA, and SOC 2, making it suitable for industries with stringent regulatory requirements.

Ensuring Data Privacy

AWS implements strict data privacy measures, including data encryption at rest and in transit, and allows you to manage your own encryption keys.

Case Studies: Major Companies Using AWS

Companies like Capital One, NASA, and General Electric rely on AWS for their cloud infrastructure. These organizations benefit from AWS’s scalability, reliability, and global reach.

Success Stories and Lessons Learned

Capital One, for instance, leveraged AWS to enhance its security posture and innovate rapidly. NASA uses AWS to store and analyze vast amounts of data from space missions, demonstrating AWS’s ability to handle large-scale projects.

Choosing the Right AWS Components

Factors to Consider

When choosing AWS components, consider your application’s needs, such as performance, availability, and cost. AWS offers tools like the Well-Architected Framework to guide your decision-making process.

Balancing Cost and Performance

Optimize your architecture by balancing cost and performance. Use cost management tools provided by AWS to monitor and adjust your spending.

Follow best practices, such as automating deployments, implementing proper security measures, and regularly reviewing your architecture to ensure it meets your business goals.

Future of AWS Infrastructure

Emerging Trends

AWS continues to innovate with new services and features. Trends like machine learning, IoT, and serverless computing are becoming increasingly prominent.

Predictions for the Next Decade

Over the next decade, expect AWS to further enhance its infrastructure with more Regions, AZs, and Edge Locations. These advancements will continue to drive down latency and improve global accessibility.

Migration to AWS: Steps for a Smooth Transition

Migrating to AWS involves several steps, including assessment, planning, migration, and optimization. AWS provides tools like AWS Migration Hub to simplify the process.

Conclusion

Understanding AWS infrastructure is crucial for leveraging its full potential. By comprehending Regions, AZs, Data Centers, and Edge Locations, you can build resilient, scalable, and efficient applications.

Final Thoughts

AWS’s robust global infrastructure offers unparalleled opportunities for businesses to innovate and grow. As AWS continues to expand and evolve, staying informed about its components and best practices will ensure you remain competitive in the cloud era.

FAQ

What are Availability Zones in AWS?

Availability Zones (AZs) are distinct data centers within an AWS Region that provide fault tolerance and high availability. They are designed to be isolated from failures in other AZs.

How do Edge Locations Improve Performance?

Edge Locations cache content closer to users, reducing latency and ensuring faster load times for websites and applications. They are part of AWS’s content delivery network (CDN).

What is the Difference Between Regions and Availability Zones?

Regions are large geographical areas containing multiple Availability Zones. AZs are isolated data centers within a Region that provide redundancy and fault tolerance.

How Secure are AWS Data Centers?

AWS data centers employ multiple layers of security, including physical controls like biometric access, and logical controls such as encryption and network firewalls. They undergo regular security audits to ensure compliance.

Can Small Businesses Benefit from AWS?

Yes, AWS offers scalable and cost-effective solutions that are ideal for small businesses. Services like AWS Lightsail provide easy-to-use cloud resources tailored for small-scale applications.

Thank you so much for Reading the Article till the End! 🙌🏻 Your time and interest truly mean a lot 😁📃.

If you have any questions or thoughts about this blog, feel free to connect with me:

LinkedIn: https://www.linkedin.com/in/ravikyada

Twitter: https://twitter.com/ravijkyada

Until next time, Cheers to more learning and discovery✌🏻!

A Guide to Understanding Availability Zones, Edge Locations, and Data Centers was originally published in InfiQ Technologies on Medium.

Kubernetes Services, which allows network access to Pods managed within deployments. We’ll explore the various Kubernetes Services types and touch upon Kubernetes Ingress.

Unlike a service, Ingress isn’t a service but offers an alternative method for directing traffic to your services and cluster.

we will go through all services and ingress and provide examples of deploying an application both without using Ingress and with using Ingress to help everyone understand the differences and benefits of Ingress.

Understanding Kubernetes Services

What Are They Exactly?

Kubernetes Services act like traffic managers within your cluster, directing requests to the right destinations.

In Kubernetes, a service serves as a stable access point for pods offering the same functionality. Think of it as a consistent address and port combination that remains unchanged as long as the service runs.

The service automatically routes incoming connections to one of the pods, even if the pod’s location changes within the cluster.

This simplifies management, as pods can be moved or scaled without disrupting client access. Kubernetes services support load balancing, ensuring efficient distribution of client requests among the available pods.

Kubernetes Services are endpoints or interfaces of pods (or groups of pods) that perform the same function. In simple terms, they act as gates, but only as entrances.

Creating a service is like creating a gate for traffic from outside to easily communicate with the pod that owns the gate.

Types of Kubernetes Services:

There are a few types of Kubernetes Services, each serving a different purpose. Whether it’s ClusterIP for internal communication or NodePort/LoadBalancer for external access, there’s a service for every need.

1. ClusterIP:

Suitable for exposing services only internally, such as databases, caches, or message queues (no one outside can talk to them).

When we create ClusterIPa service, Kubernetes creates a virtual IP for that service by pulling the IP from the reserved pool, allowing pods or other services within the cluster to access the service through that IP.

2. NodePort:

Suitable for exposing services for testing or debugging during app development.

When we create NodePorta service, Kubernetes reserves one port on every node in the cluster (usually port 30000–32767), and traffic sent via node IP + port is forwarded to that service. It can be the IP of any node.

such as

• [Node1] IP XXXX Port 8080 will forward to Apache Server.

• [Node2] IP YYYY Port 3000 will be forwarded to Nodejs backend as well.

• [Node1] IP XXXX Port 3001 will be forwarded to the product Server.

3. LoadBalancer:

When we create LoadBalancera service, Kubernetes creates the actual load balancer outside of the cluster (if using the cloud, it is created on the cloud platform), allowing external users to access our service through the load balancer IP.

LoadBalancerservice is suitable for use to expose services in production that require access from outside Kubernetes or from the public internet, such as a simple web app that is not complicated.

In fact, Kubernetes also has another type of service that may not be talked about in general.ExternalNamewhich I would like not to go into details about. Let's just say it uses a map service to the DNS name (redirection) and doesn't do load balancing in any way.

Exploring Kubernetes Services

How Do They Work?

Picture a busy highway road with cars and trucks around the road. Kubernetes Services ensure that each car (or pod) reaches its destination safely, without crashing into others.

Where Can You Use Them?

Kubernetes Services are handy in various scenarios, from microservices architectures to monolithic applications. They keep everything connected and running smoothly behind the scenes.

[Demo-1] Try to Deploy the App using only Services.

Suppose I have an infiq app that consists of 4 parts:

1. Frontend

2. Admin Panel

3. Backend

4. PostgreSQL Database

If I want to deploy this app with Kubernetes services, I might choose the following service:

• Frontend service is used LoadBalancerbecause users from outside will call in.

• Admin service is used LoadBalancerbecause users from outside(Other Team) will call in.

• Backend service is used LoadBalancerbecause users from outside will call into the backend service.

• Database service is used ClusterIPbecause it is called from an internal service itself.

And I need to create a record from an external DNS like this.

• infiq.tech Points to the load balancer IP of the frontend service.

• admin.infiq.tech Points to the load balancer IP of the Admin service.

• backend.infiq.tech Points to the load balancer IP of the Backend service.

It works fine, but the problem is…

1. Wasteful: to run this application in production I have to pay for 3 load balancers.

2. Complicated: we must must manage 3 DNS records

3. There are limitations: URL path routing cannot be done. Must use a subdomain instead. For example:- infiq.tech/profilecannot be used → must be used with their subdomains.

4. (Maybe) Chaotic: If the load balancer IP changes, you have to change the DNS record (except on the cloud where we usually point DNS to the load balancer DNS name).

Actually, regarding URL path routing, we can deploy a proxy to do the same. It reduces the hassle of DNS records as well, but it has to take care of the proxy and still wastes load balancer fees.

And let’s try to see what Kubernetes Ingress can help us with.

Getting to Know Kubernetes Ingress

Breaking Down the Basics

Think of Kubernetes Ingress as the gatekeeper to your cluster. It manages incoming traffic, allowing external users to access your applications securely.

How Ingress Plays Its Part

Ingress works its magic by routing requests based on rules you define. It’s like having a personal concierge who ensures that each visitor gets to their desired destination without getting lost.

Kubernetes Ingress is a traffic controller in a Kubernetes cluster that is inserted in front of other services. It receives traffic from the load balancer and sends traffic to various services according to routing rules.

To use Ingress, there must be 2 parts:

1. Ingress Controller, for which we need to deploy a controller (such as NGINX, alb-controller, Traefik, etc.) first to work as a proxy for us.

2. Ingress Resource is to configure the controller to work as we want. This one is a Kubernetes resource like pods or deployments.

[Demo-2] Try Deploying the App using Ingress to help.

we will change all 3 services (frontend, admin, backend) from LoadBalancerto ClusterIPall because I will use only one load balancer of ingress to expose outside the cluster.

and DNS will have only 1 record left pointing to the load balancer IP of the ingress.

And this is what I got after bringing ingress to this Application.

1. From having to use 3 load balancers, there is only 1 left.

2. Manage a single DNS record pointing to ingress.

3. Can do routing from URL path such as
   - infiq.tech→ frontend service
   - admin.infiq.tech/users→ Admin service
   - infiq.tech/profile→ Frontend service with path-based routes

4. Configuration regarding URL routing or TLS can be done in ingress and stored as code (Kubernetes manifest) with other manifests in one place.

Unveiling the Differences

What Sets Services and Ingress Apart?

Services focus on internal communication, while Ingress handles external access. It’s like comparing an internal phone system (Services) to a reception desk (Ingress) that welcomes external visitors.

Choosing the Right Tool

Deciding between Services and Ingress depends on your application’s needs. If you’re dealing with internal communication, go for Services. For external access, Ingress is your go-to.

Frequently Asked Questions

What’s the main difference between Kubernetes Services and Ingress?

Services handle internal communication within your cluster, while Ingress manages external access to your services.

Can you use Kubernetes Services and Ingress together?

Absolutely! Services and Ingress complement each other, working together to ensure seamless communication both inside and outside your cluster.

How do I decide which to use for my application?

Consider your application’s needs. If you’re dealing with internal communication between pods, go for Services. If you need to manage external access, Ingress is your go-to.

Does using Kubernetes Ingress affect performance?

When configured properly, the performance impact of Ingress is minimal. However, inefficient routing or misconfiguration can lead to performance issues.

How does Kubernetes handle complex deployments with both Services and Ingress?

Kubernetes is designed to handle complex deployments seamlessly. By carefully configuring your Services and Ingress resources, you can ensure smooth traffic routing and management in even the most intricate setups.

Thank you so much for Reading the Article till the End! 🙌🏻 Your time and interest truly mean a lot 😁📃.

If you have any questions or thoughts about this blog, feel free to connect with me:

LinkedIn: https://www.linkedin.com/in/ravikyada

Twitter: https://twitter.com/ravijkyada

Until next time, Cheers to more learning and discovery✌🏻!

Kubernetes Services vs. Ingress: A Beginner’s Guide was originally published in InfiQ Technologies on Medium, where people are continuing the conversation by highlighting and responding to this story.

· Understanding CORS Errors:
∘ Access-Control-Allow-Origin:
∘ Preflight CORS request failed:
· Causes of CORS Errors:
· Resolving CORS Errors:
∘ Identify the cause:
∘ Configure CORS headers:
∘ Check origin matching:
∘ Secure SSL certificates:
∘ Test and monitor:
· Best practices for avoiding CORS Errors
· Troubleshooting Tips
· Conclusion and Final Thoughts

This can often lead to frustration and connectivity issues when trying to establish API connections.

However, understanding how to troubleshoot and resolve CORS errors is essential for successful API integration.

In this blog, we will explore the ins and outs of CORS errors and provide step-by-step guidance on how to resolve them like a pro.

Understanding CORS Errors:

CORS errors can occur when a web application running on one domain tries to request an API hosted on a different domain.

These errors are a security mechanism implemented by web browsers to prevent unauthorized access to resources.

Understanding the different types of CORS errors can help in troubleshooting and resolving them effectively.

Access-Control-Allow-Origin:

One common type of CORS error is the “Access-Control-Allow-Origin” error. This error occurs when the API being accessed does not include the appropriate CORS headers in its response.

The solution to this error involves configuring the API server to include the “Access-Control-Allow-Origin” header with the appropriate origin or wildcard value.

Preflight CORS request failed:

Another type of CORS error is the “Preflight CORS request failed” error. This error occurs when the web browser is making a preflight request to the API to determine if the actual request is safe to send.

The solution to this error involves ensuring that the API server responds correctly to the preflight requests by including the necessary CORS headers.

By understanding the different types of CORS errors and their solutions, developers can troubleshoot and resolve API connection issues more efficiently.

In the next section, we will explore the step-by-step process of troubleshooting and resolving CORS errors with Best Practices. Stay tuned to learn the best practices for resolving CORS errors and ensuring seamless API integration.

Understanding Linux Directory Structure.

Causes of CORS Errors:

CORS errors can occur due to a variety of factors. Understanding these causes can help developers pinpoint the source of the issue and resolve it effectively.

One common cause of CORS errors is misconfigured CORS headers on the API server. If the necessary CORS headers, such as “Access-Control-Allow-Origin” or “Access-Control-Allow-Methods”, are not included in the API’s response, the browser will block the request due to security concerns.

Another cause of CORS errors is mismatched origins. The “Access-Control-Allow-Origin” header specifies the allowed origins that can access the API. If the requesting domain does not match the specified origin(s), the browser will reject the request.

Additionally, CORS errors can be triggered by invalid SSL certificates. Browsers consider SSL certificates as a crucial security measure. If the certificate is missing or expired, the browser may block the request.

In the following section, we will delve into the step-by-step process of troubleshooting and resolving CORS errors effectively and professionally. Stay tuned to learn the best practices for overcoming these challenges and ensuring smooth API integration.

Resolving CORS Errors:

Resolving CORS errors requires a systematic approach that combines technical knowledge and professional best practices.

By following these steps, you can effectively troubleshoot and resolve API connection issues caused by CORS errors.

Identify the cause:

Begin by determining the specific cause of the CORS error. This can be achieved by examining error messages, reviewing server logs, and testing the API connections using different tools and methods. Understanding the root cause is essential for applying the appropriate solution.

Configure CORS headers:

If the CORS headers on the API server are misconfigured, you need to ensure that the necessary headers, such as “Access-Control-Allow-Origin” and “Access-Control-Allow-Methods,” are correctly set. Consult the API documentation or contact the API provider for guidance on the correct headers to use.

Check origin matching:

Verify that the requesting domain matches the allowed origins specified in the “Access-Control-Allow-Origin” header. If there is a mismatch, update the header to include the correct origin(s).

Secure SSL certificates:

Ensure that your SSL certificates are valid and up to date. If the certificate is missing or expired, renew it or obtain a new one from a trusted certificate authority. Taking this step will prevent browsers from blocking the request due to security concerns.

Test and monitor:

After implementing the necessary changes, thoroughly test your API connections to verify that the CORS errors have been resolved. Monitor the system for any recurring issues and be prepared to make further adjustments if needed.

By approaching CORS error resolution methodically and professionally, you can overcome these challenges and establish reliable API connections. In the next section, we will explore additional tips and best practices to further enhance your troubleshooting skills in handling CORS errors. Stay tuned!

Best practices for avoiding CORS Errors

While troubleshooting CORS errors is important, it is even better to prevent them from occurring in the first place.

By following these best practices, you can significantly reduce the chances of encountering CORS errors and maintain smooth API connections:

1. Implement a robust CORS policy:

Establish a well-defined CORS policy that specifies which domains are allowed to access your API. By limiting access to only trusted domains, you can minimize the risk of unauthorized requests and potential security vulnerabilities.

2. Utilize preflight requests:

Preflight requests, also known as “OPTIONS” requests, are sent by the browser to check if a cross-origin request is allowed. By handling preflight requests correctly and providing the necessary headers and permissions, you can avoid many CORS errors.

3. Use appropriate HTTP methods:

Ensure that you are using the correct HTTP methods for your API requests. CORS errors can occur if you attempt to use a method that is not allowed by the server or if the method is not specified in the “Access-Control-Allow-Methods” header.

4. Enable caching:

If your API responses don’t frequently change, consider enabling caching. This allows the browser to store the response for a certain period, reducing the number of requests and potential CORS errors.

5. Regularly update documentation:

Keep your API documentation up to date, including any changes to CORS policy and headers. Clear and accurate documentation will help developers understand how to properly interact with your API and reduce the likelihood of CORS errors.

By incorporating these best practices into your API development process, you can ensure a smooth and error-free cross-origin communication experience. In the next section, we will dive into advanced troubleshooting techniques for handling complex CORS scenarios. Stay tuned!

Troubleshooting Tips

Despite following best practices, it’s still possible to encounter CORS errors in more complex scenarios. Here are some troubleshooting tips to help you diagnose and resolve these issues professionally:

1. Check browser console logs:

When a CORS error occurs, the browser console is often the first place to look for more information. Examine the console logs for any error messages related to CORS. This can provide valuable insights into the specific issue at hand.

2. Inspect HTTP headers:

Review the HTTP headers being sent and received during the API request. Look for any missing or incorrect headers, such as the “Access-Control-Allow-Origin” or “Access-Control-Allow-Headers”. Make sure these headers are present and correctly configured.

3. Confirm server-side configuration:

Double-check the server-side configuration and ensure that it is properly handling CORS requests. Validate that the server is sending the necessary CORS headers and that the responses are correctly configured.

4. Consider CORS proxies:

In some cases, using a CORS proxy can help bypass CORS restrictions. These proxies can send requests on behalf of the client, effectively circumventing CORS limitations. However, exercise caution when using proxies and ensure they are only used when necessary.

5. Update cross-origin domains:

If you’re experiencing CORS errors with specific domains, verify that they are still allowed in your CORS policy. Domains can change or be updated, and it’s important to keep your CORS policy up to date.

By following these troubleshooting tips, you’ll be equipped with the knowledge and tools to troubleshoot and resolve CORS errors effectively. In the final section of this blog series, we will outline additional resources and tools that can aid in CORS error resolution. Stay tuned!

Conclusion and Final Thoughts

In today’s blog post, we explored various troubleshooting tips that can help you resolve CORS errors professionally.

These tips include checking browser console logs for error messages, inspecting HTTP headers, confirming server-side configuration, considering CORS proxies, and updating cross-origin domains.

By following these troubleshooting strategies, you’ll be able to diagnose and fix CORS errors more effectively, ensuring smooth API connections. However, it’s important to remember that each troubleshooting scenario may be unique, and additional methods might be required for complex issues.

Troubleshooting CORS Errors: How to Resolve CORS API Connection Issues was originally published in InfiQ Technologies on Medium, where people are continuing the conversation by highlighting and responding to this story.

Understanding the Linux Directory Structure is like having a map to guide you through the core of your computer’s operating system.

In this journey, we’re going to break down the directories, revealing their secrets, and helping you make sense of how everything fits together.

In this journey, we will discuss the directories, unveiling their secrets and the logic behind the structure.

Root Directory: The Foundation of Linux Realms

The / (root) directory is where it all begins, like the foundation of a Whole OS. Let’s explore its depths and understand the core system files and folders that reside within the root directory.

/bin and /sbin: Essential Binaries for System Operations

Dive into the /bin and /sbin directories, where essential binaries reside, performing key functions for system operations. What binaries are crucial, and how do they contribute to the seamless functioning of your Linux system?

Both /bin and /sbin (after it was introduced) used to be on the root partition. /sbin contains the binaries needed only for managing the system (e.g. mount), while /bin contains binaries used by both ordinary users and system administrators (e.g. pwd, cd, ls).

/usr/bin (as well as /usr/sbin, /usr/local/…, opt/…) holds the binaries that are not required to boot up the system.

/etc: Configuration Files Haven for System Customization

Take a stroll through the /etc directory, the haven for configuration files. Understand the importance of this directory and explore common configuration files that shape your Linux environment.

/home: Where Users Call Home

In the /home directory, users find their sanctuary. Uncover the organization of user home directories and how users personalize their space within /home.

/var: Dynamic Data Hub for System Activity

The /var directory is a dynamic hub where variable data is stored. What role does this directory play, and how can you effectively manage the ever-changing data within /var?

/usr: Universal System Resources

/usr directory, a vast expanse of universal system resources including command details, static and shareable file.

/usr directory Contains all commands, libraries, man pages, games, and static files for normal operation.

/lib and /lib64: Chronicles of Shared Libraries

Explore the realms of /lib and /lib64, where shared libraries reside. How do these directories contribute to the efficient functioning of applications and the system as a whole?

/opt: Optional Software Packages for Enhanced Functionality

The /opt directory is a space reserved for optional software packages. What does this mean for your Linux system, and how can you install and manage these optional packages?

/tmp: Temporarily Yours — Managing Temporary Files with /tmp

Unlock the secrets of the /tmp directory, a temporary haven for files. What purpose does /tmp serve, and how can you effectively manage temporary files in this space?

/dev: Device Directory — Managing Devices in Linux

Delve into the /dev directory, where devices are managed. What is the role of /dev in Linux, and how are special device files structured within this directory?

/proc: Process Information Wonderland — Navigating the /proc Directory

Embark on a journey into the /proc directory, a Wonderland of process information. What insights can you gain by exploring /proc, and how does it contribute to monitoring your system?

/mnt and /media: Mounting Points — Connecting External Devices

Discover the purpose of /mnt and /media directories, designed for mounting external devices. How can you use these directories to seamlessly connect and manage external storage?

/srv: Service Data Directory — Organizing Service Data in Linux

Uncover the significance of the /srv directory, dedicated to organizing service data. How does /srv contribute to a well-structured Linux environment, especially in managing data for various services?

Conclusion: Navigating the Linux Landscape with Confidence

As we conclude our exploration of the Linux Directory Structure, you now possess a roadmap to navigate the intricate terrain of your Linux system. Each directory plays a unique role, contributing to the harmony of your operating system. Armed with this knowledge, you can enhance your Linux navigation skills and confidently traverse the Linux landscape.

FAQ Section: Decoding Linux Directory Structure

1. Why is the root directory (/) crucial in Linux?

2. The / directory is the foundation of the Linux file system, containing essential system files and directories. It serves as the starting point for the entire directory structure.

2. What is the significance of the /etc directory in Linux?

• The /etc directory is a haven for configuration files in Linux. It houses settings and configurations for various system and application components, allowing users to customize their Linux environment.

3. How does the /home directory contribute to user experience in Linux?

• The /home directory is where users home directories are located. It provides users with a personalized space to store their files and configurations, enhancing their overall experience on the Linux system.

4. What role does the /var directory play in Linux?

• The /var directory is a dynamic hub for variable data in Linux. It stores files that are expected to grow in size or change frequently, such as logs, spool files, and temporary data.

5. Why are shared libraries stored in the /lib and /lib64 directories?

• The /lib and /lib64 directories house shared libraries in Linux, which are essential for the functioning of applications. These directories ensure that multiple programs can use the same library, optimizing system resources.

Understanding Linux Directory Structure. was originally published in InfiQ Technologies on Medium, where people are continuing the conversation by highlighting and responding to this story.

with Awesome Mentoring and Anchoring of Neel Shah, we started the Meet-up Morning and then Rishang Bhavsar delivered an enlightening session on Terraform and their insights with AWS Modules.

With that, All of the Attendees also explored some of the tools around Hashicorp like Hashicorp Vault, Nomad, Consul, and many.

Rishang did a very insightful session focused on the multifaceted capabilities of Terraform, particularly in the domains of cost exploration, documentation generation, and utilization of various supplementary tools within the Terraform workflow..

Let's dive and explore these Awesome elements with Terraform. You can Follow this GitHub Repo to Demonstrate all tools: Rishang's GIthub Repo

Automating Cost Management in Terraform:

Controlling costs is a significant concern for any cloud infrastructure deployment. Leveraging tools like Terraform Cost Estimation allows you to estimate infrastructure costs before deployment, enabling better decision-making.

Integrate Infracost tools into your Terraform pipeline to forecast expenses and optimize resource allocation, ensuring cost-effectiveness in your infrastructure provisioning.

Infracost shows cloud cost estimates for Terraform. It lets engineers see a cost breakdown and understand costs before making changes, either in the terminal, VS Code or pull requests.

This Project is 100% open source and Available to Integrate with your Pipelines.
https://github.com/infracost/infracost

Automate TF Mudules Documentry with terraform-docs:

Documentation is the backbone of any project. Generating comprehensive documentation for Terraform code can be time-consuming.

Tools like Terraform-docs automate this process by extracting metadata from your code to generate documentation in various formats including Markdown, JSON, and YAML.

By incorporating Terraform docs into your workflow, you can maintain up-to-date documentation effortlessly, enhancing collaboration and understanding among team members.

Here you can find the Github repo for the terraform-docs: https://github.com/terraform-docs/terraform-docs/

Exploration of Infra Security Tools:

Rishang discussed tfsec, a tool for automating security scanning, highlighting its ability to identify vulnerabilities and compliance violations within Terraform code.

Additionally, he showcased Terraformer, a visualization tool that aids in generating graphical representations of infrastructure, enabling better comprehension and troubleshooting.

tfsec gives awesome information about vulnerabilities around the terraform stack, some of the details we can Ignore as we Ignore the Terms & Conditions of any News Letters.

We can also create custom checks same as custom test cases in tfsec, which depends on the project requirements.

This project is also Open-Source and available on GitHub: https://github.com/aquasecurity/tfsec

Throughout the session, Rishang emphasized best practices for leveraging these tools effectively within Terraform workflows. \

He provided real-world examples and case studies, illustrating how these tools can be seamlessly integrated into CI/CD pipelines, enhancing security, reducing manual efforts, and optimizing infrastructure costs.

In the end, we tried to explore more and more tools that can be integrated to get the estimated code of the terraform stacks.

Here I Mention a Few Tools Discussed Over the Meetup:

Hieven Terraform Visual:

It Gives you a Visual understanding of the terraform code with an improved graphical view.

You can check more details here: https://hieven.github.io/

SnykTflint:

SnykTFLint is the Security tool that gives us the security and vulnerabilities for your terraform modules.

you can also create your ruleset for terraform-provider. Check more info here: SnykTflint

Terragrunt:

- Pike

- Inframap

- Opencost

- Diagramcodes

Conclusion:

Remember, the key to successful infrastructure management lies in embracing automation tools that empower you to optimize costs, maintain thorough documentation, ensure robust security practices, and visualize your architecture effectively.

Stay updated with the evolving landscape of Terraform and Hashicorp tools to continually refine and enhance your infrastructure deployment processes.

The Hashicorp User Group Gandhinagar Event was an insightful journey into the world of tools that complement Terraform and enable a more efficient and robust infrastructure management experience.

Incorporating these automation tools into your workflow will undoubtedly elevate your Terraform deployment to greater heights.

Keep exploring, automating, and innovating for a more seamless infrastructure provisioning experience with Terraform!