Using AWS EKS with CloudFront and WAF

Introduction

In previous articles, I guided you through using AWS EKS to create Kubernetes resources in the traditional way using yaml files or using KubernetesManifest directly via AWS CDK. The result is that we access the application directly through the LoadBalancer Address, but this is only an HTTP connection. To enhance security, in this article, we will explore how to use it alongside CloudFront for HTTPS connections and WAF.

AWS WAF (Web Application Firewall) is a firewall service that protects web applications (delivered via CloudFront, ALB, or API Gateway) from common security vulnerabilities. Instead of just basic IP blocking, WAF deeply analyzes HTTP/HTTPS content to make decisions to allow or block requests.

Advantages

Protection against automated attacks: Effectively prevents common types of attacks such as SQL Injection, Cross-Site Scripting (XSS), and vulnerabilities in the OWASP Top 10.

Bot and DDoS Blocking: Uses AWS Managed Rules to block malicious bots from scraping data and application-layer (Layer 7) DDoS attacks.

Flexible Customization (Rate Limiting): Limits the number of requests from a single IP (e.g., maximum 100 req/5 minutes) to prevent Brute-force on login pages.

Rapid Deployment: No software installation required on the Server; it can be activated immediately on existing CloudFront or Load Balancers.


Prerequisites

This article is developed from my previous posts; you should review them to grasp information about S3, NestJS, building docker images, and pushing to ECR.

In the NestJS project, we will continue by creating the origin-auth.middleware.ts file with the following content:

import {Injectable, NestMiddleware, ForbiddenException} from '@nestjs/common'
import {ConfigService} from '@nestjs/config'

@Injectable()
export class OriginAuthMiddleware implements NestMiddleware {
  verifySecret: string

  constructor(private readonly configService: ConfigService) {
    this.verifySecret = this.configService.get<string>('VERIFY_SECRET') || ''
  }

  use(req: any, res: any, next: () => void) {
    const secret = req.headers['x-origin-verify']
    if (secret !== this.verifySecret) {
      throw new ForbiddenException(
        'Access denied: Direct access is not allowed'
      )
    }
    next()
  }
}

As you can see, I use middleware here to check if the request header field x-origin-verify matches the VERIFY_SECRET value. The VERIFY_SECRET will be sent from CloudFront, which I will create immediately below.


Next, add it to app.module.ts:

import {
  MiddlewareConsumer,
  Module,
  NestModule,
} from '@nestjs/common'
import {ConfigModule} from '@nestjs/config'
import {S3Controller} from './controller/s3.controller'
import {S3Service} from './service/s3.service'
import {OriginAuthMiddleware} from './middleware/origin-auth.middleware'

@Module({
  imports: [
    ConfigModule.forRoot({
      isGlobal: true,
      envFilePath: '.env',
    }),
  ],
  controllers: [S3Controller],
  providers: [S3Service],
})
export class AppModule implements NestModule {
  configure(consumer: MiddlewareConsumer) {
    consumer
      .apply(OriginAuthMiddleware)
      .forRoutes('*')
  }
}


Then, build the docker image and push it to AWS ECR.

Detail

First, create a .env file with the following information:

  • CDK_DEFAULT_REGION: replace with your desired region
  • CDK_US_REGION: must be us-east-1; this is the fixed region used to create WAF
  • Your BUCKET and IMAGE
  • VERIFY_SECRET: any string you want to use

CDK_DEFAULT_REGION = ap-southeast-1
CDK_US_REGION = us-east-1
BUCKET = <BUCKET>
IMAGE = <IMAGE URI>
VERIFY_SECRET = <VERIFY_SECRET>


Continuing with AWS CDK, create the file lib/eks-manifest-stack.ts:

import { KubectlV34Layer } from "@aws-cdk/lambda-layer-kubectl-v34"
import * as cdk from "aws-cdk-lib"
import * as ec2 from "aws-cdk-lib/aws-ec2"
import * as eks from "aws-cdk-lib/aws-eks"
import * as iam from "aws-cdk-lib/aws-iam"
import * as cr from "aws-cdk-lib/custom-resources"
import { Construct } from "constructs"

export class EksManifestStack extends cdk.Stack {
  readonly lbAddress: string

  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props)

    const vpc = new ec2.Vpc(this, "EksVpc", {
      maxAzs: 2,
      natGateways: 0,
      subnetConfiguration: [
        { name: "PublicSubnet", subnetType: ec2.SubnetType.PUBLIC },
      ],
    })

    const cluster = new eks.Cluster(this, "MyEksCluster", {
      vpc,
      vpcSubnets: [{ subnetType: ec2.SubnetType.PUBLIC }],
      defaultCapacity: 0,
      version: eks.KubernetesVersion.V1_34,
      kubectlLayer: new KubectlV34Layer(this, "KubectlLayer"),
      authenticationMode: eks.AuthenticationMode.API_AND_CONFIG_MAP,
      bootstrapClusterCreatorAdminPermissions: true,
    })

    const nodeGroup = cluster.addNodegroupCapacity("PublicNodeGroup", {
      instanceTypes: [new ec2.InstanceType("t3.small")],
      minSize: 1,
      maxSize: 2,
      subnets: { subnetType: ec2.SubnetType.PUBLIC },
      amiType: eks.NodegroupAmiType.AL2023_X86_64_STANDARD,
    })

    const s3Policy = new iam.PolicyStatement({
      actions: ["s3:PutObject", "s3:GetObject", "s3:ListBucket"],
      resources: ["*"],
    })

    const serviceAccount = cluster.addServiceAccount("NestJsServiceAccount", {
      name: "nestjs-s3-sa",
      namespace: "default",
    })
    serviceAccount.addToPrincipalPolicy(s3Policy)

    const nestJsAppResource = new eks.KubernetesManifest(
      this,
      "NestJsAppResources",
      {
        cluster,
        manifest: [
          {
            apiVersion: "apps/v1",
            kind: "Deployment",
            metadata: { name: "nestjs-app", namespace: "default" },
            spec: {
              replicas: 1,
              selector: { matchLabels: { app: "nestjs" } },
              template: {
                metadata: { labels: { app: "nestjs" } },
                spec: {
                  serviceAccountName: serviceAccount.serviceAccountName,
                  containers: [
                    {
                      name: "nestjs-container",
                      image: process.env.IMAGE,
                      ports: [{ containerPort: 3000 }],
                      env: [
                        {
                          name: "REGION",
                          value: process.env.CDK_DEFAULT_REGION,
                        },
                        { name: "BUCKET", value: process.env.BUCKET },
                        {
                          name: "VERIFY_SECRET",
                          value: process.env.VERIFY_SECRET || "",
                        },
                      ],
                    },
                  ],
                },
              },
            },
          },
          {
            apiVersion: "v1",
            kind: "Service",
            metadata: { name: "nestjs-service", namespace: "default" },
            spec: {
              type: "LoadBalancer",
              selector: { app: "nestjs" },
              ports: [{ protocol: "TCP", port: 80, targetPort: 3000 }],
            },
          },
        ],
      },
    )

    nestJsAppResource.node.addDependency(nodeGroup)

    this.lbAddress = cluster.getServiceLoadBalancerAddress("nestjs-service", {
      namespace: "default",
    })

    const getPrefixList = new cr.AwsCustomResource(this, "GetCFPrefixList", {
      onUpdate: {
        service: "EC2",
        action: "describeManagedPrefixLists",
        parameters: {
          Filters: [
            {
              Name: "prefix-list-name",
              Values: ["com.amazonaws.global.cloudfront.origin-facing"],
            },
          ],
        },
        region: this.region,
        physicalResourceId: cr.PhysicalResourceId.of("cf-prefix-list-lookup"),
      },
      policy: cr.AwsCustomResourcePolicy.fromSdkCalls({
        resources: cr.AwsCustomResourcePolicy.ANY_RESOURCE,
      }),
    })
    const cloudFrontPrefixListId = getPrefixList.getResponseField(
      "PrefixLists.0.PrefixListId",
    )
    cluster.clusterSecurityGroup.addIngressRule(
      ec2.Peer.prefixList(cloudFrontPrefixListId),
      ec2.Port.tcp(80),
      "Allow HTTP traffic from CloudFront only",
    )
  }
}

Explanation

  • Creating the vpc, cluster, nodeGroup, s3Policy, serviceAccount, KubernetesManifest, and the addDependency part for the nodeGroup is similar to what I mentioned in previous articles.
  • Note that in this article, lbAddress will be assigned to a variable of this stack instance because we will use this value to create the next stack.
  • AwsCustomResource: used to get the prefix list ID by region for CloudFront. You can understand CloudFront as a collection of edge locations around the world; fetching the prefix list ID by region is equivalent to getting the IP addresses of the edge locations in that region.
  • addIngressRule: adds this prefix list to the cluster to only allow these CloudFront edge locations to access our cluster.


You can use the AWS CLI to view the prefix ID as follows:

$ aws ec2 describe-managed-prefix-lists --filters Name=prefix-list-name,Values=com.amazonaws.global.cloudfront.origin-facing --region {-region} --query "PrefixLists[0].PrefixListId" --output text

# example
$ aws ec2 describe-managed-prefix-lists --filters Name=prefix-list-name,Values=com.amazonaws.global.cloudfront.origin-facing --region ap-southeast-1 --query "PrefixLists[0].PrefixListId" --output text
pl-31a34658


Next, create the file lib/waf-cloudfront-stack.ts:

import * as cdk from "aws-cdk-lib"
import * as cloudfront from "aws-cdk-lib/aws-cloudfront"
import * as origins from "aws-cdk-lib/aws-cloudfront-origins"
import * as eks from "aws-cdk-lib/aws-eks"
import * as wafv2 from "aws-cdk-lib/aws-wafv2"
import { Construct } from "constructs"

export class WafCloudfrontStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props: WafCloudfrontStackProps) {
    super(scope, id, props)

    const webAcl = new wafv2.CfnWebACL(this, "AppWaf", {
      defaultAction: { allow: {} },
      scope: "CLOUDFRONT",
      visibilityConfig: {
        cloudWatchMetricsEnabled: true,
        metricName: "WAFMetric",
        sampledRequestsEnabled: true,
      },
      rules: [
        {
          name: "AWS-AWSManagedRulesSQLiRuleSet",
          priority: 1,
          statement: {
            managedRuleGroupStatement: {
              vendorName: "AWS",
              name: "AWSManagedRulesSQLiRuleSet",
            },
          },
          overrideAction: { none: {} },
          visibilityConfig: {
            sampledRequestsEnabled: true,
            cloudWatchMetricsEnabled: true,
            metricName: "SQLiRule",
          },
        },
        {
          name: "AWS-AWSManagedRulesAmazonIpReputationList",
          priority: 2,
          statement: {
            managedRuleGroupStatement: {
              vendorName: "AWS",
              name: "AWSManagedRulesAmazonIpReputationList",
            },
          },
          overrideAction: { none: {} },
          visibilityConfig: {
            sampledRequestsEnabled: true,
            cloudWatchMetricsEnabled: true,
            metricName: "IPReputation",
          },
        },
        {
          name: "General-Rate-Limit",
          priority: 3,
          action: { block: {} },
          statement: {
            rateBasedStatement: {
              limit: 10,
              aggregateKeyType: "IP",
              // evaluationWindowSec: 60, // default 300s = 5m
            },
          },
          visibilityConfig: {
            sampledRequestsEnabled: true,
            cloudWatchMetricsEnabled: true,
            metricName: "GeneralRateLimit",
          },
        },
      ],
    })

    const originVerifySecret = process.env.VERIFY_SECRET || ""
    const cfDist = new cloudfront.Distribution(this, "AppDistribution", {
      defaultBehavior: {
        origin: new origins.HttpOrigin(props.lbAddress, {
          customHeaders: {
            "X-Origin-Verify": originVerifySecret,
          },
          protocolPolicy: cloudfront.OriginProtocolPolicy.HTTP_ONLY,
        }),
        allowedMethods: cloudfront.AllowedMethods.ALLOW_ALL,
        cachePolicy: cloudfront.CachePolicy.CACHING_DISABLED,
        originRequestPolicy:
          cloudfront.OriginRequestPolicy.ALL_VIEWER_EXCEPT_HOST_HEADER,
      },
      webAclId: webAcl.attrArn,
    })

    new cdk.CfnOutput(this, "CloudFrontDomain", {
      value: cfDist.distributionDomainName,
    })
  }
}

interface WafCloudfrontStackProps extends cdk.StackProps {
  readonly lbAddress: string
}

Explanation

  • This WAF will be attached to CloudFront, and I have defined 3 rules:
    • AWSManagedRulesSQLiRuleSet: This rule scans all components of an HTTP Request (Header, Query String, URI, Body). It uses pattern matching algorithms to find signatures of SQL commands such as:
      • Keywords: SELECT, INSERT, UPDATE, DELETE, DROP, UNION.
      • Special characters used to break statements: ' (single quote), -- (comment), ; (end of statement).
      • Logic that is always true: 1=1, 'a'='a'.
      • Strength: It doesn't just block raw code; it can perform transformations on encoded data (like URL-encoded or Hex) before checking, preventing attackers from intentionally "disguising" malicious code.
    • AWSManagedRulesAmazonIpReputationList (Anti-DDoS & Malicious Bots): This is a rule set based on the reputation of IP addresses. AWS owns a massive infrastructure network and collects data on bad IPs worldwide.
      • Blocking method: Instead of analyzing request content, this rule checks if the requesting IP is on Amazon's "blacklist."
      • DDoS Protection: By blocking IPs already identified as attack sources, it helps reduce the load on your system before these junk requests can reach the Backend.
    • General-Rate-Limit: used to block brute force, with limit: 10 being the number of requests per 5 minutes (default); you can change the corresponding time. Note that I only set it to 10 requests for testing purposes; in reality, depending on your product's scale, adjust it accordingly (common values are 500-1000 requests). Remember that employees in companies or organizations may use one or a few shared IP addresses to connect to the Internet; if the request limit you set is too low, when that IP is blocked, all employees there will also be unable to use your service.
  • Cloudfront.Distribution: creating CloudFront is similar to previous articles, just note the following points:
    • props.lbAddress: this is the Load Balancer Address received after successfully creating EksManifestStack.
    • protocolPolicy uses HTTP_ONLY because the Load Balancer is only HTTP.
    • webAclId: points to the ARN of the WAF created above.
    • customHeaders: this part is where the X-Origin-Verify request header is sent to your NestJS application. The reason is that if an attacker knows your Load Balancer address, they could create their own CloudFront to access it. Therefore, we create an additional verify secret to add a private layer of security; requests sent from CloudFront to the Load Balancer with incorrect header information will be denied access.


Next, create the file lib/eks-cloudfront-stack.ts:

import * as cdk from "aws-cdk-lib/core"
import { EksManifestStack } from "./eks-manifest-stack"
import { WafCloudfrontStack } from "./waf-cloudfront-stack"

export const EksCloudfrontStack = (app: cdk.App) => {
  const eksManifestStack = new EksManifestStack(app, "EksManifestStack", {
    env: { region: process.env.CDK_DEFAULT_REGION },
  })
  const wafCloudfrontStack = new WafCloudfrontStack(app, "WafCloudfrontStack", {
    env: { region: process.env.CDK_US_REGION },
    lbAddress: eksManifestStack.lbAddress,
    crossRegionReferences: true,
  })
  wafCloudfrontStack.addDependency(eksManifestStack)
}

  • You can see that it is split into 2 separate stacks in 2 different regions. First, create EksManifestStack in any region you want. Next, look at the addDependency part, which means EksManifestStack must be finished and reach CREATE_COMPLETE status before WafCloudfrontStack begins creation.
  • The reason WAF must be created in us-east-1 (N. Virginia) is that this is the Control Plane for CloudFront to store WAF configurations and push them to all Edge Locations. When a Rule in WAF is created or updated in us-east-1, it receives the change and then propagates that rule set to all CloudFront Edge Locations worldwide.


Update the file bin/aws-cdk.ts:

#!/usr/bin/env node
import 'dotenv/config';
import * as cdk from "aws-cdk-lib/core"
import { EksCloudfrontStack } from "../lib/eks/eks-cloudfront-stack"

const app = new cdk.App()
EksCloudfrontStack(app)


Before deploying, you need to run the bootstrap command because there are two regions that need to be initialized.

$ cdk bootstrap
 ⏳  Bootstrapping environment aws://347176525761/ap-southeast-1...
 ⏳  Bootstrapping environment aws://347176525761/us-east-1...
Trusted accounts for deployment: (none)
Trusted accounts for lookup: (none)
 ✅  Environment aws://347176525761/ap-southeast-1 bootstrapped (no changes).
Trusted accounts for deployment: (none)
Trusted accounts for lookup: (none)
 ✅  Environment aws://347176525761/us-east-1 bootstrapped (no changes).


After deployment, the result is as follows:

✅  WafCloudfrontStack
✨  Deployment time: 238.46s

Outputs:
WafCloudfrontStack.CloudFrontDomain = d2sgkl29hqxf17.cloudfront.net

✨  Total time: 331.33s


Resources created on the AWS Console:



Use Postman to test the API:


Now I will send 50 requests simultaneously to trigger the WAF rule.


AWS WAF checks traffic within a time window (default is 5 minutes or 300 seconds).

  • When blocked: AWS WAF calculates the total number of requests in the previous 5 minutes. If this number is greater than your limit, the IP is blacklisted.
  • When unblocked: Every 30 seconds, WAF recalculates the total requests in the last 5 minutes. As soon as this number drops below the threshold limit, the IP is automatically unblocked.

You can view details of each request to WAF on the console.

Happy coding!

See more articles here.

Comments

Post a Comment

Popular posts from this blog

All practice series

Image
Introduction This is a comprehensive page about the technologies I have shared in series format. You can view brief introductions and links to directly access each series you are interested in. In the field of software development, to deploy a product from the initial idea to its release, the standard process typically involves several stages as follows: Database : Designing and implementing the database according to business requirements, storing data during the system's operation. Backend : Handling the main logic of the system, communicating with the database and services. Frontend : Building the interface for users to interact with the system, which could be a desktop, mobile, or web application. This usually includes implementing UI/UX and integrating APIs from the backend. DevOps : Deploying the system for use, which can be done on a server or in the cloud. Testing : Applying testing methods to ensure the product meets the standards for release. Of course, these are just stan...
Read more

Deploying a NodeJS Server on Google Kubernetes Engine

Image
Introduction to GKE Google Kubernetes Engine (GKE) is a managed Kubernetes service provided by Google Cloud Platform , facilitating simple and efficient deployment of Docker images. We only need to provide some configuration for the number of nodes, machine types, and replicas to use. Some Concepts Cluster A Cluster is a collection of Nodes where Kubernetes can deploy applications. A cluster includes at least one Master Node and multiple Worker Nodes . The Master Node is used to manage the Worker Nodes . Node A Node is a server in the Kubernetes Cluster. Nodes can be physical servers or virtual machines. Each Node runs  Kubernetes , which is responsible for communication between the Master Node and Worker Node , as well as managing Pods and containers running on it. Pod A Pod is the smallest deployable unit in Kubernetes . Each Pod contains one or more containers, typically Docker containers. Containers in the same Pod share a network namespace, meaning they have the ...
Read more

Setting up Kubernetes Dashboard with Kind

Image
Introduction In a previous article, I guided you through using Helm to deploy on Google Kubernetes Engine . However, if you want to cut down costs by using Kubernetes in your local environment instead of relying on a cloud provider during development, then Kind is your go-to. There are several tools to help set up Kubernetes locally, such as MiniKube , Kind , K3S , KubeAdm , and more. Each tool has its own pros and cons. In this article, I'll walk you through using Kind to quickly set up a Kubernetes cluster on Docker . Kind stands out for its compactness, making Kubernetes start up quickly, being user-friendly, and supporting the latest Kubernetes versions. Working with Kind Firstly, follow the instructions here to install Kind according to your operating system. If you're using Ubuntu , execute the command: [ $( uname -m ) = x86_64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.23.0/kind-linux-amd64 chmod +x ./kind sudo mv ./kind /usr/local/bin/ki...
Read more

Using Kafka with Docker and NodeJS

Image
Introduction to Kafka Kafka is an open-source , distributed messaging system that functions on a publish/subscribe model. It is widely used by numerous large companies for high-performance , real-time data streaming. Developed by LinkedIn since 2011, Kafka has grown into the most popular distributed streaming platform. It can handle vast amounts of records with high efficiency. Advantages of Kafka Open-source : Freely available and continuously improved by a large community. High-throughput, high-frequency : Capable of processing large volumes of data across topics continuously. Automatic message storage : Allows for easy message retrieval and verification. Large user community : Offers extensive support and shared resources. Basic Concepts If you're new to Kafka and Message Queues, here are some key concepts to understand: Producer : Creates and sends data to the Kafka server, where data is sent as messages in byte array format. Consumer : One or more consumers subscribe to...
Read more

Monitoring with cAdvisor, Prometheus and Grafana on Docker

Image
Introduction Monitoring a system is crucial after deploying a product to a production environment. Keeping an eye on system metrics like logs , CPU , RAM , disks , etc, helps identify the system's status, performance issues, and provides timely solutions to ensure stable operations. While cloud providers like Google , Amazon , or Azure offer built-in monitoring systems, if your company needs to manage multiple applications/systems/containers and desires a centralized monitoring system for easier management, using cAdvisor , Prometheus , and Grafana is a sensible choice. These three popular open-source tools are widely used by DevOps teams, especially for monitoring container applications. cAdvisor Developed by Google , cAdvisor is an open-source project used to analyze resource usage, performance, and other metrics from container applications, providing an overview of all running containers. Find more details here Prometheus Prometheus is a toolkit for system monitoring and a...
Read more

Kubernetes Practice Series

Image
Introduction Kubernetes (often abbreviated as K8s ) is an open-source system designed to automate the deployment, scaling, and management of containerized applications. This page serves as a collection of articles related to Kubernetes (K8s) , including theoretical concepts and practical guides on using Kubernetes to set up essential tools for the software development process. I will continue to update this series with new articles as ideas come to mind, to ensure the series becomes more comprehensive. The articles are arranged in increasing order of difficulty to make it easier for you to follow. If you have time, it's recommended that you start from the beginning of the series to acquire the necessary knowledge and information that will prepare you for the subsequent articles. Key Topics Covered in This Series Basic Knowledge : Fundamental concepts, common commands, etc. Resources : Pod, Deployment, Service, StatefulSet, Ingress, etc. Pod Autoscaler : Horizontal and Vertical sc...
Read more

Kubernetes Deployment for Zero Downtime

Image
Introduction In Kubernetes (K8s) , a Pod is the smallest resource unit used to run one or more containers during deployment. There are several ways to create a Pod : you can create it directly, use a ReplicationController , or a ReplicaSet . However, the most commonly used resource for managing Pods is the Deployment . When you use a Deployment , it actually creates a ReplicaSet to manage the Pods but comes with many additional benefits that support the deployment process. Some Advantages of Deployment : Ensures Pod Availability : It guarantees that the specified number of Pods are always running according to the configuration, automatically deploying additional Pods if any failures occur. Supports Restart and Undo Deployment : Allows you to easily restart or roll back to previous versions of your Deployment . Zero Downtime Deployment : When updating configurations or scaling Deployments , zero downtime is crucial. This means that new Pods are created while the old Pods are stil...
Read more

Practicing with Google Cloud Platform - Google Kubernetes Engine to deploy nginx

Image
Introduction This article provides simple step-by-step instructions for those who are new to Google Cloud Platform (GCP) and Google Kubernetes Engine (GKE) . I'll guide you through using  GKE  to create clusters and deploy nginx . The instructions below will primarily use gcloud  and kubectl  to initialize the cluster, which is more convenient than manual management on the Google Cloud interface. Prerequisites First, you need to prepare the following: Have a GCP account with permission to use Cloud services. If you're new, you'll get a $300 free trial to use for 90 days . Create a new GCP project. Enable Compute Engine and Kubernetes Engine services. Install Google Cloud SDK and kubectl For this installation step, refer to the GCP documentation for instructions tailored to your operating system. Once installed, execute the following commands to check if gcloud  and kubectl  are installed: gcloud version kubectl version If you see the version resul...
Read more

NodeJS Practice Series

Image
Introduction NodeJS is an open-source and cross-platform JavaScript runtime environment . Here are some key points about NodeJS : V8 Engine : NodeJS runs on the V8 JavaScript engine , which is also the core of Google Chrome . This allows NodeJS to be highly performant. Asynchronous and Non-Blocking : NodeJS  uses an event-driven, non-blocking I/O model. It’s lightweight and efficient, making it ideal for data-intensive real-time applications. Single-Threaded : NodeJS  runs in a single process, handling multiple requests without creating new threads. It eliminates waiting and continues with the next request. Common Language : Frontend developers who write JavaScript for browsers can use the same language for server-side code in NodeJS . You can even use the latest ECMAScript standards without waiting for browser updates. This page is designed to compile articles related to NodeJS , including how to integrate it with various libraries and relevant tech stacks. I will cont...
Read more

Helm for beginer - Deploy nginx to Google Kubernetes Engine

Image
Introduction Helm is a package manager for Kubernetes , which simplifies the process of deploying and managing applications on Kubernetes clusters. Helm uses a packaging format called charts , which are collections of files that describe a related set of Kubernetes resources. Key Components of Helm Charts : Helm packages are called charts. A chart is a collection of files that describe a related set of Kubernetes resources. A single chart might be used to deploy something simple, like a memcached pod, or something complex, like a full web app stack with HTTP servers , databases, caches, and so on. Values : Charts can be customized with values, which are configuration settings that specify how the chart should be installed on the cluster. These values can be set in a ` values.yaml ` file or passed on the command line. Releases : When you install a chart, a new release is created. This means that one chart can be installed multiple times into the same cluster, and each can be indep...
Read more