EKB - AWS EKS (सेवाएँ और अवसंरचना) गाइड

यह दस्तावेज़ EKB सेवाओं की अवसंरचना के लिए AWS वास्तुकला का एक व्यापक अवलोकन प्रदान करता है। वास्तुकला AWS प्रबंधित सेवाओं, Kubernetes ऑर्केस्ट्रेशन और स्वचालित स्केलिंग के साथ क्लाउड-नेटिव पैटर्न का अनुसरण करती है।

AWS वास्तुकला अवलोकन

वास्तुकला AWS प्रबंधित सेवाओं, Kubernetes ऑर्केस्ट्रेशन और स्वचालित स्केलिंग के साथ क्लाउड-नेटिव पैटर्न का अनुसरण करती है।

वास्तुकला आरेख

flowchart TD
    INTERNET["🌐 INTERNET"]
 
    DNS["DNS Provider
(Route 53 / Cloudflare / etc.)
──────────────────────────────
• app.your-domain — Web Frontend
• api.your-domain — FastAPI Backend
• automations.your-domain — Automator
• supabase.your-domain — Supabase Kong
• signoz.your-domain — SigNoz"]
 
    ALB["APPLICATION LOAD BALANCER
──────────────────────────────
• SSL Termination via ACM
• HTTP → HTTPS Redirect
• Health Checks & Target Groups
• Routing by hostname/path"]
 
    subgraph VPC["VPC"]
        subgraph PUB["Public Subnets (3 AZs)"]
            NAT["NAT Gateway × 3"]
        end
        subgraph PRIV["Private Subnets (3 AZs)"]
            NODES["EKS Worker Nodes"]
        end
    end
 
    subgraph EKS["EKS CLUSTER"]
        KARPENTER["KARPENTER — Dynamic Node Provisioning
──────────────────────────────
• Spot prioritisation & consolidation
• Interruption handling via SQS
• Node classes: general, compute-intensive, database"]
        KEDA["KEDA — Event-driven Pod Autoscaling
──────────────────────────────
• CPU / Memory threshold scaling
• Fast scale-down stabilisation"]
        PODS["APPLICATION PODS
──────────────────────────────
• Web Frontend (port 3000)
• FastAPI Backend (port 8001)
• Celery Workers
• Automator (port 80)
• Supabase services (Kong, Auth, Storage…)
• PostgreSQL Automator (port 5432)"]
        SIGNOZ["OBSERVABILITY — SigNoz (optional)
──────────────────────────────
• Distributed tracing, metrics, logs
• k8s-infra agent for cluster metrics"]
    end
 
    subgraph DATA["DATA LAYER"]
        REDIS["ELASTICACHE
(Redis)
──────────
• Encryption
• Multi-AZ
• Port 6379"]
        MQ["AMAZON MQ
(RabbitMQ)
──────────
• Async queue
• AMQP/SSL
• Port 5671"]
        SUPABASE["SUPABASE
(DB / Auth)
──────────
Option A: Cloud
Option B: Self-hosted
via CNPG HA on EKS"]
    end
 
    INTERNET --> DNS
    DNS --> ALB
    ALB --> VPC
    PUB --> PRIV
    PRIV --> EKS
    EKS --> DATA

जानकारी

सेल्फ़-होस्टेड Supabase CloudNativePG-प्रबंधित HA PostgreSQL क्लस्टर (ha-supabase-db) का उपयोग करता है जिसमें PgBouncer pooling, MinIO ऑब्जेक्ट स्टोरेज के लिए, और helm-deployment/supabase-kubernetes-ha के माध्यम से तैनात पूर्ण Supabase एप्लिकेशन स्टैक शामिल है। यदि सेल्फ़-होस्टिंग की आवश्यकता नहीं है तो Supabase Cloud एक विकल्प है।

मुख्य घटक

1. नेटवर्किंग लेयर

DNS Provider

उद्देश्य: डोमेन नाम रिज़ॉल्यूशन; किसी भी प्रदाता के साथ काम करता है (Route 53, Cloudflare, आदि)
डोमेन (अपना स्वयं का डोमेन उपयोग करें, जैसे example.com):
- app.example.com — वेब फ़्रंटएंड
- api.example.com — FastAPI बैकएंड
- automations.example.com — Automator सेवा
- supabase.example.com — Supabase Kong (केवल सेल्फ़-होस्टेड)
- signoz.example.com — SigNoz अवलोकन (वैकल्पिक)
SSL सत्यापन: ACM DNS सत्यापन के लिए CNAME रिकॉर्ड्स आवश्यक

Application Load Balancer (ALB)

उद्देश्य: SSL termination, लोड बैलेंसिंग और hostname-आधारित रूटिंग
विशेषताएँ:
- ACM प्रमाणपत्रों का उपयोग करके SSL/TLS termination (वाइल्डकार्ड या प्रति-सेवा)
- HTTP → HTTPS रीडायरेक्ट
- सभी लक्ष्य समूहों के लिए हेल्थ चेक्स
द्वारा प्रबंधित: AWS Load Balancer Controller (helm-deployment/infrastructure में Helm chart)

VPC

CIDR: वातावरण-विशिष्ट (जैसे 10.x.0.0/16)
उपलब्धता क्षेत्र: चयनित क्षेत्र में 3 AZs
सबनेट्स: 3 पब्लिक (NAT Gateways) + 3 प्राइवेट (EKS नोड्स)
आउटबाउंड: नोड ईग्रेस के लिए प्रति AZ NAT Gateway

2. कम्प्यूट लेयर

EKS क्लस्टर

संस्करण: Kubernetes 1.33
सिस्टम Node Group: Karpenter कंट्रोलर चलाने वाला प्रबंधित node group (AWS बेस्ट प्रैक्टिस के अनुसार, Karpenter-प्रबंधित नोड्स पर नहीं)
ऐड-ऑन्स: EBS CSI Driver, AWS Load Balancer Controller, CoreDNS, kube-proxy

Karpenter — गतिशील Node प्रोविज़निंग

उद्देश्य: जस्ट-इन-टाइम node प्रोविज़निंग और लागत अनुकूलन
Node Classes:
- जनरल पर्पस: अधिकांश वर्कलोड के लिए Spot instances
- कम्प्यूट इंटेंसिव: CPU-बाउंड टास्क के लिए हाई-CPU instances
- मेमोरी इंटेंसिव: बड़े डेटासेट के लिए मेमोरी-अनुकूलित instances
- डेटाबेस: स्टेटफुल/डेटाबेस वर्कलोड के लिए On-Demand instances
- GPU: AI/ML वर्कलोड के लिए GPU instances (वैकल्पिक)
विशेषताएँ: Spot प्राथमिकता, स्वचालित समेकन, SQS-आधारित interruption handling

KEDA — Kubernetes Event-Driven Autoscaling

उद्देश्य: संसाधन मेट्रिक्स के आधार पर हॉरिज़ॉन्टल pod autoscaling
लक्ष्य:

सेवा	रेप्लिकास	CPU सीमा	मेमोरी सीमा
वेब फ़्रंटएंड	2–8	60%	80%
FastAPI बैकएंड	2–10	70%	80%
Celery Workers	2–8	70%	80%
Automator	2–8	70%	80%

स्केल-डाउन: तेज़ प्रतिक्रिया के लिए 30s स्थिरता विंडो

3. एप्लिकेशन सेवाएँ

वेब फ़्रंटएंड

पोर्ट: 3000
रेप्लिकास: 2–8 (KEDA-प्रबंधित)
उद्देश्य: उपयोगकर्ता इंटरफ़ेस प्रदान करने वाला React एप्लिकेशन

FastAPI बैकएंड

पोर्ट: 8001
रेप्लिकास: 2–10 (KEDA-प्रबंधित)
उद्देश्य: बिज़नेस लॉजिक और डेटा पहुँच को संभालने वाला REST API सर्वर

Celery Workers

रेप्लिकास: 2–8 (KEDA-प्रबंधित)
उद्देश्य: पृष्ठभूमि टास्क प्रोसेसिंग (RabbitMQ के माध्यम से क्यू किया गया)

Automator सेवा

पोर्ट: 80
रेप्लिकास: 2–8 (KEDA-प्रबंधित)
उद्देश्य: वर्कफ़्लो स्वचालन और ऑर्केस्ट्रेशन

Supabase Kong

पोर्ट: 8000 (आंतरिक क्लस्टर सेवा)
उद्देश्य: सभी Supabase सेवाओं के लिए API gateway
रूटिंग: बाहरी ट्रैफ़िक odin-services/main-ingress.yaml में परिभाषित ALB ingress के माध्यम से Kong तक पहुँचता है

SigNoz (वैकल्पिक)

Namespace: monitoring
घटक: SigNoz प्लेटफ़ॉर्म + k8s-infra DaemonSet agent
उद्देश्य: वितरित tracing, मेट्रिक्स एकत्रीकरण, लॉग प्रबंधन
सक्षम: ENABLE_SIGNOZ=true

4. डेटा लेयर

ElastiCache Redis

उद्देश्य: कैशिंग, सत्र स्टोरेज, और Celery broker/result backend
कॉन्फ़िगरेशन:
- Node प्रकार: कॉन्फ़िगर करने योग्य (जैसे cache.t3.micro)
- पोर्ट: 6379
- रेस्ट और ट्रांज़िट में एन्क्रिप्शन
- उच्च उपलब्धता के लिए Multi-AZ
सक्षम: ENABLE_AWS_SERVICES=true

Amazon MQ (RabbitMQ)

उद्देश्य: अतुल्यकालिक टास्क प्रोसेसिंग के लिए मैसेज क्यूइंग
कॉन्फ़िगरेशन:
- Engine: RabbitMQ
- पोर्ट्स: 5671 (AMQP/SSL), 15671 (Management/SSL)
- तैनाती मोड: सिंगल-इंस्टैंस या active/standby
सक्षम: ENABLE_AWS_SERVICES=true

Supabase — विकल्प A: क्लाउड (प्रबंधित)

उद्देश्य: बाहरी प्रबंधित PostgreSQL, Auth, Storage और Realtime
कनेक्शन: values/odin-services.yaml में कॉन्फ़िगर किया गया Supabase प्रोजेक्ट URL और service role key

Supabase — विकल्प B: EKS पर सेल्फ़-होस्टेड

उद्देश्य: क्लस्टर के अंदर चलने वाला पूर्ण Supabase स्टैक
घटक:
- CloudNativePG operator (cnpg-system) — Postgres क्लस्टर जीवनचक्र प्रबंधित करता है
- HA Supabase DB (ha-supabase-db) — PgBouncer pooler के साथ CloudNativePG Cluster रिसोर्स
- Supabase एप्लिकेशन (supabase namespace) — Kong, Auth, Storage (MinIO), Meta, Rest, Realtime, Studio
तैनाती क्रम: CloudNativePG → HA Supabase DB → Supabase ऐप
सक्षम: ENABLE_CNPG=true, ENABLE_HA_SUPABASE_DB=true, ENABLE_SUPABASE=true

PostgreSQL Automator

उद्देश्य: Automator सेवा के लिए स्थानीय PostgreSQL डेटाबेस
पोर्ट: 5432
स्टोरेज: EBS स्थायी volume
Node affinity: डेटाबेस-समर्पित नोड्स

5. सुरक्षा और IAM

IAM भूमिकाएँ

भूमिका	उद्देश्य
EKS Cluster Role	क्लस्टर-स्तरीय API अनुमतियाँ
Node Group Role	EC2 नोड अनुमतियाँ (ECR, SSM, नेटवर्किंग)
Karpenter Controller Role	EC2 प्रोविज़निंग, SQS interruption क्यू
AWS Load Balancer Controller Role	ELBv2 और EC2 प्रबंधन
EBS CSI Driver Role	EBS volume जीवनचक्र प्रबंधन

भूमिका नाम <env-name>-<component> पैटर्न का पालन करते हैं और EKS Terraform मॉड्यूल द्वारा बनाए जाते हैं।

सुरक्षा समूह

ALB: AWS Load Balancer Controller द्वारा स्वतः बनाया गया (80/443 इनबाउंड)
EKS Cluster: नोड-से-नोड और pod संचार
Redis: केवल VPC CIDR से पोर्ट 6379
RabbitMQ: केवल VPC CIDR से पोर्ट्स 5671, 15671

SSL/TLS

Termination: ALB स्तर (pods आंतरिक रूप से प्लेन HTTP देखते हैं)
प्रमाणपत्र: ACM प्रमाणपत्र — या तो प्रति-सेवा या एकल वाइल्डकार्ड
सत्यापन: आपके DNS provider के माध्यम से DNS CNAME सत्यापन
न्यूनतम प्रोटोकॉल: TLS 1.2

6. Infrastructure as Code

Terraform मॉड्यूल्स

modules/eks: EKS क्लस्टर, VPC, node groups, Karpenter, IAM, Helm releases
स्टेट: S3 bucket वर्शनिंग के साथ, DynamoDB lock table

Terragrunt

वातावरण अलगाव: terragrunt/environments/ के अंतर्गत प्रति वातावरण एक निर्देशिका
टेम्पलेट: env-template-folder — नया वातावरण बनाने के लिए कॉपी करें और placeholders भरें
DRY कॉन्फ़िगरेशन: प्रति-वातावरण overrides के साथ साझा root.hcl
सक्षम/अक्षम फ़्लैग्स: वातावरण चरों (ENABLE_*) के माध्यम से सेवाएँ टॉगल की जाती हैं

Helm Charts

Chart	Namespace	विवरण
`infrastructure`	`infrastructure`	ALB Controller
`odin-services`	`default`	Web, API, Workers, Automator, Ingress
`aws-ebs-csi-driver`	`kube-system`	EBS volume प्रोविज़निंग
`keda`	`keda`	Pod autoscaling
`cloudnative-pg`	`cnpg-system`	PostgreSQL operator
`ha-supabase-db`	`ha-supabase-db`	HA Postgres क्लस्टर + PgBouncer
`supabase-kubernetes-ha`	`supabase`	पूर्ण Supabase स्टैक
`signoz`	`monitoring`	अवलोकन प्लेटफ़ॉर्म
`k8s-infra`	`monitoring`	क्लस्टर मेट्रिक्स agent

डेटा प्रवाह

1. उपयोगकर्ता अनुरोध प्रवाह

उपयोगकर्ता → DNS → ALB (SSL termination) → EKS Pod (वेब फ़्रंटएंड)
                                   → EKS Pod (FastAPI बैकएंड)
                                   → EKS Pod (Supabase Kong)

उपयोगकर्ता app.example.com तक पहुँचता है
DNS ALB को रिज़ॉल्व करता है
ALB SSL को terminate करता है और hostname द्वारा सही लक्ष्य समूह में रूट करता है
वेब फ़्रंटएंड React ऐप प्रदान करता है और api.example.com पर API कॉल करता है
FastAPI बैकएंड अनुरोधों को प्रोसेस करता है और डेटा सेवाओं से पढ़ता/लिखता है

2. API अनुरोध प्रवाह

Client → ALB → FastAPI बैकएंड → Redis (कैश) / RabbitMQ (क्यू) / Supabase (DB)

Client api.example.com पर कॉल करता है
ALB FastAPI pod में रूट करता है
बैकएंड Redis कैश जाँचता है; मिस होने पर, Supabase डेटाबेस को क्वेरी करता है
अतुल्यकालिक टास्क RabbitMQ में क्यू किए जाते हैं और Celery Workers द्वारा प्रोसेस किए जाते हैं

3. पृष्ठभूमि प्रोसेसिंग प्रवाह

FastAPI → RabbitMQ → Celery Worker → Supabase DB

FastAPI RabbitMQ में एक टास्क क्यू करता है
Celery Worker टास्क को डीक्यू और प्रोसेस करता है
परिणाम Supabase डेटाबेस में वापस लिखे जाते हैं

4. Automator वर्कफ़्लो

Automator → PostgreSQL (स्थानीय) → Redis → बाहरी APIs

Automator एक वर्कफ़्लो अनुरोध प्राप्त करता है
वर्कफ़्लो स्टेट स्थानीय PostgreSQL instance में संग्रहीत होता है
Redis मध्यवर्ती परिणामों को कैश करता है
स्वचालन के भाग के रूप में बाहरी APIs कॉल की जाती हैं

5. स्केलिंग प्रवाह

मेट्रिक्स → KEDA → Pod स्केलिंग → Karpenter → Node प्रोविज़निंग

KEDA CPU/Memory मेट्रिक्स को कॉन्फ़िगर की गई सीमाओं के विरुद्ध मूल्यांकन करता है
Pods कॉन्फ़िगर की गई रेप्लिका रेंज के भीतर हॉरिज़ॉन्टली स्केल किए जाते हैं
यदि क्लस्टर क्षमता अपर्याप्त है, तो Karpenter नए EC2 नोड्स प्रोविज़न करता है (Spot को प्राथमिकता)
जब लोड कम होता है, KEDA pods को स्केल-डाउन करता है; Karpenter निष्क्रिय नोड्स को समेकित और समाप्त करता है

6. सुरक्षा प्रवाह

इंटरनेट → ALB (TLS 1.2+, ACM) → सुरक्षा समूह → Pods → IAM IRSA भूमिकाएँ → AWS APIs

सभी बाहरी ट्रैफ़िक ALB पर TLS को terminate करता है
सुरक्षा समूह न्यूनतम-विशेषाधिकार नेटवर्क पहुँच लागू करते हैं
Pods IRSA (IAM Roles for Service Accounts) के माध्यम से AWS सेवाओं के साथ संवाद करते हैं

उच्च उपलब्धता सारांश

विशेषता	कार्यान्वयन
Multi-AZ तैनाती	EKS नोड्स, Redis, सबनेट्स के लिए 3 AZs
लोड बैलेंसिंग	कई लक्ष्य समूहों के साथ ALB
Pod रिडंडेंसी	प्रति सेवा न्यूनतम 2 रेप्लिकास
डेटाबेस HA	PgBouncer के साथ CloudNativePG क्लस्टर (सेल्फ़-होस्टेड) या Supabase Cloud
कैश रिडंडेंसी	ElastiCache Multi-AZ
Node autoscaling	Spot + On-Demand मिश्रण के साथ Karpenter
Pod autoscaling	KEDA CPU/Memory-आधारित
अवलोकन	SigNoz (वैकल्पिक)
स्टेट प्रबंधन	S3 वर्शनिंग + DynamoDB lock

लागत अनुकूलन

Spot Instances: Karpenter गैर-डेटाबेस वर्कलोड के लिए Spot को प्राथमिकता देता है
Node समेकन: Karpenter स्वचालित रूप से कम उपयोग वाले नोड्स को पुनः प्राप्त करता है
Pod राइट-साइज़िंग: KEDA शांत अवधि के दौरान pods को स्केल-डाउन करता है
केवल जहाँ आवश्यक On-Demand: डेटाबेस node class स्थिरता के लिए On-Demand का उपयोग करता है

रखरखाव और संचालन

तैनाती प्रक्रिया

cd terragrunt/environments/<your-env-name>
# आवश्यक ENABLE_* और domain/certificate वातावरण चर सेट करें
terragrunt apply
# रोलिंग अपडेट: image tags या values files अपडेट करने के बाद पुनः लागू करें

पूर्ण तैनाती क्रम के लिए Terragrunt तैनाती गाइड देखें।

बैकअप रणनीति

EBS Snapshots: स्थायी volumes (Automator DB, Supabase MinIO) के लिए स्वचालित snapshots
CloudNativePG: लगातार WAL archiving + अनुसूचित base backups (यदि कॉन्फ़िगर किया गया)
Supabase Cloud: प्रबंधित दैनिक बैकअप (क्लाउड विकल्प)
IaC स्टेट: S3 वर्शन्ड bucket

आपदा वसूली

Multi-AZ: सभी स्टेटफुल सेवाएँ कई उपलब्धता क्षेत्रों में फैली हुई हैं
CloudNativePG HA: Postgres primary और replicas के बीच स्वचालित failover
Supabase Cloud: क्रॉस-क्षेत्र रिडंडेंसी (क्लाउड विकल्प)
Terraform स्टेट: S3 वर्शनिंग किसी भी पिछली स्थिति में वापस जाने की अनुमति देता है

AWS वास्तुकला अवलोकन

वास्तुकला आरेख​

मुख्य घटक​

1. नेटवर्किंग लेयर​

DNS Provider​

Application Load Balancer (ALB)​

VPC​

2. कम्प्यूट लेयर​

EKS क्लस्टर​

Karpenter — गतिशील Node प्रोविज़निंग​

KEDA — Kubernetes Event-Driven Autoscaling​

3. एप्लिकेशन सेवाएँ​

वेब फ़्रंटएंड​

FastAPI बैकएंड​

Celery Workers​

Automator सेवा​

Supabase Kong​

SigNoz (वैकल्पिक)​

4. डेटा लेयर​

ElastiCache Redis​

Amazon MQ (RabbitMQ)​

Supabase — विकल्प A: क्लाउड (प्रबंधित)​

Supabase — विकल्प B: EKS पर सेल्फ़-होस्टेड​

PostgreSQL Automator​

5. सुरक्षा और IAM​

IAM भूमिकाएँ​

सुरक्षा समूह​

SSL/TLS​

6. Infrastructure as Code​

Terraform मॉड्यूल्स​

Terragrunt​

Helm Charts​

डेटा प्रवाह​

1. उपयोगकर्ता अनुरोध प्रवाह​

2. API अनुरोध प्रवाह​

3. पृष्ठभूमि प्रोसेसिंग प्रवाह​

4. Automator वर्कफ़्लो​

5. स्केलिंग प्रवाह​

6. सुरक्षा प्रवाह​

उच्च उपलब्धता सारांश​

लागत अनुकूलन​

रखरखाव और संचालन​

तैनाती प्रक्रिया​

बैकअप रणनीति​

आपदा वसूली​

अतिरिक्त संसाधन​