Cloud Native Tech Stack Introduction: Kubernetes, Containerization, and API Gateway (2025)

You've decided to adopt Cloud Native architecture, but facing terms like Kubernetes, Buildpacks, API Gateway, and Storage, you don't know where to start. This article will help you understand the core components of the Cloud Native tech stack, so you know each component's role and selection considerations.

The Cloud Native tech stack isn't just randomly assembled tools. Each component has its position, working together to maximize effectiveness. After reading this, you'll have a complete understanding of the entire tech stack.

Cloud Native Tech Stack Overview

💡 Key Takeaway: A complete Cloud Native tech stack typically includes the following layers:

┌─────────────────────────────────────────────────────┐
│  Application Layer                                   │
│  ├─ Microservices                                   │
│  └─ API Gateway                                     │
├─────────────────────────────────────────────────────┤
│  Orchestration Layer                                │
│  └─ Kubernetes                                      │
├─────────────────────────────────────────────────────┤
│  Container Layer                                     │
│  ├─ Container Runtime (containerd)                  │
│  └─ Container Image (OCI)                           │
├─────────────────────────────────────────────────────┤
│  Infrastructure Layer                                │
│  ├─ Storage                                         │
│  ├─ Network                                         │
│  └─ Compute                                         │
└─────────────────────────────────────────────────────┘

Each layer has corresponding technology options. Let's introduce the core components one by one.

Want to understand Cloud Native basic concepts? Please first read Cloud Native Complete Guide.

Kubernetes Core Concepts

What Is K8s? Why Has It Become the Standard?

Kubernetes (K8s) is a container orchestration platform open-sourced by Google in 2014. Its design was inspired by Borg, a system Google used internally for over 15 years.

Why Has Kubernetes Become the De Facto Standard?

1. Google Backing: Architecture validated by large-scale production environments
2. CNCF Stewardship: Neutral governance, not locked to any single vendor
3. Complete Ecosystem: 1,000+ related tools and plugins
4. Cloud Support: AWS, GCP, Azure all provide managed services

Currently Kubernetes has over 80% market share in the container orchestration market.

K8s Architecture Components

A Kubernetes cluster consists of two types of nodes:

Control Plane

Worker Node

K8s Core Objects

Pod

Pod is K8s's smallest deployment unit. A Pod can contain one or more containers, sharing network and storage.

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    image: my-app:v1.0.0
    ports:
    - containerPort: 8080

Deployment

Deployment manages Pod replica counts and update strategies.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3  # Maintain 3 replicas
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: my-app:v1.0.0

Service

Service provides stable network endpoints, allowing other services to access Pods.

apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 8080
  type: ClusterIP

ConfigMap and Secret

ConfigMap stores configuration data, Secret stores sensitive information. Both can be injected into Pods.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: "info"
  API_ENDPOINT: "https://api.example.com"

This approach follows the 12 Factor Config principle: separating configuration from code.

K8s Deployment Modes

Self-Managed Cluster vs Managed Service

Recommendations:

• Small-medium teams: Use managed services, focus on application development
• Large enterprises: Can consider self-managed, but need dedicated SRE team

K8s is powerful, but misconfiguration burns money. Schedule architecture consultation and let experts help you evaluate the most suitable deployment method.

Containerization and Cloud Native Buildpacks

Containerization Basics

Containerization is the foundation of Cloud Native. Containers package applications and dependencies together, ensuring consistent execution in any environment.

Containers vs Virtual Machines

OCI Standard

OCI (Open Container Initiative) defines standards for container images and runtimes. OCI-compliant images can run on any compatible runtime (Docker, containerd, CRI-O).

Cloud Native Buildpacks Introduction

Cloud Native Buildpacks (CNB) is a CNCF project that can automatically convert code into container images without writing Dockerfiles.

Traditional Approach vs Buildpacks

Usage Example

# Install pack CLI
brew install buildpacks/tap/pack

# Build image (auto-detect language)
pack build my-app --builder paketobuildpacks/builder:base

# Done! No Dockerfile needed
docker run -p 8080:8080 my-app

How Buildpacks Work

1. Detect: Buildpack inspects code, determines if applicable
2. Build: Executes relevant build steps (install dependencies, compile, etc.)
3. Export: Outputs OCI-compliant container image

Common Buildpacks

Container Image Best Practices

1. Use Multi-Stage Builds

# Build stage
FROM node:20 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Runtime stage
FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/index.js"]

2. Choose Appropriate Base Images

3. Scan for Security Vulnerabilities

# Use Trivy to scan images
trivy image my-app:v1.0.0

API Gateway's Role in Cloud Native

What Is a Cloud Native API Gateway?

API Gateway is the unified entry point in microservices architecture. All external requests go through the API Gateway first, then are distributed to backend services.

API Gateway Responsibilities:

• Routing: Distribute requests based on URL paths
• Authentication/Authorization: Verify JWT, API Keys
• Rate Limiting: Protect backend services from overload
• Monitoring: Collect request metrics
• Transformation: Request/response format conversion

API Gateway vs Ingress Controller

Mainstream API Gateway Comparison

Kong

• Based on OpenResty (Nginx + Lua)
• Most mature open-source API Gateway
• Rich plugin ecosystem
• Has enterprise and open-source versions

# Kong Ingress Controller Example
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-api
  annotations:
    konghq.com/strip-path: "true"
    konghq.com/plugins: rate-limiting
spec:
  ingressClassName: kong
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /users
        pathType: Prefix
        backend:
          service:
            name: user-service
            port:
              number: 80

Ambassador / Emissary-Ingress

• Based on Envoy
• Kubernetes native design
• Uses CRD for configuration
• Suitable for K8s environments

Apache APISIX

• High performance (based on Nginx)
• Dynamic configuration (no restart needed)
• Rich plugins
• Developed by Chinese team, documentation available in Chinese

Traefik

• Automatic service discovery
• Simple configuration
• Suitable for small-medium projects
• Built-in Let's Encrypt integration

API Gateway Selection Recommendations

Selection Considerations:

1. Team Familiarity: Choose tools the team can maintain
2. Performance Requirements: High traffic choose APISIX or Kong
3. Feature Requirements: Need OAuth, rate limiting, and other advanced features?
4. Ecosystem Integration: Integration with existing monitoring, logging systems

Cloud Native Storage Solutions

K8s Storage Concepts

Kubernetes storage abstraction layer:

Volume

Volume is Pod-level storage, lifecycle bound to Pod.

Persistent Volume (PV)

PV is cluster-level storage resource, exists independently of Pods.

Persistent Volume Claim (PVC)

PVC is a user's request for storage, K8s automatically matches suitable PVs.

Storage Class

Storage Class defines storage types and parameters, supports dynamic provisioning.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-storage
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  iops: "10000"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

Cloud Native Storage Solution Comparison

Rook-Ceph

• Based on Ceph distributed storage
• Supports block, file, object storage
• Most complete features, but high complexity
• Suitable for large-scale deployments

Longhorn

• Lightweight storage solution developed by Rancher
• Simple installation, friendly UI
• Supports backup and disaster recovery
• Suitable for small-medium clusters

OpenEBS

• Container-native storage
• Multiple storage engine options
• Balance of performance and reliability
• Suitable for general scenarios

Comparison Summary

Storage Selection Recommendations

Choose Cloud Managed Storage When:

• Using managed K8s (EKS, GKE, AKS)
• Don't want to manage storage infrastructure
• Need high availability and backups

Choose Self-Managed Storage When:

• On-premises deployment
• Need to avoid cloud lock-in
• Have special performance or feature requirements

Want to learn about cloud native databases? Please refer to Cloud Native Database Selection Guide.

Tech Stack Integration Architecture Diagram

A typical Cloud Native tech stack integration architecture:

┌────────────────────┐
                        │   Load Balancer    │
                        │   (Cloud LB)       │
                        └─────────┬──────────┘
                                  │
                        ┌─────────▼──────────┐
                        │   API Gateway      │
                        │   (Kong/APISIX)    │
                        └─────────┬──────────┘
                                  │
        ┌─────────────────────────┼─────────────────────────┐
        │                         │                         │
┌───────▼───────┐       ┌────────▼────────┐       ┌────────▼────────┐
│ User Service  │       │ Order Service   │       │ Payment Service │
│ (Deployment)  │       │ (Deployment)    │       │ (Deployment)    │
└───────┬───────┘       └────────┬────────┘       └────────┬────────┘
        │                        │                         │
        │               ┌────────▼────────┐               │
        │               │  Message Queue  │               │
        │               │  (NATS/Kafka)   │               │
        │               └─────────────────┘               │
        │                                                  │
┌───────▼───────┐                                 ┌───────▼───────┐
│   PostgreSQL  │                                 │     Redis     │
│   (PVC)       │                                 │   (PVC)       │
└───────────────┘                                 └───────────────┘

Traffic Path:

1. External requests reach Load Balancer
2. API Gateway handles authentication, routing, rate limiting
3. Requests distributed to corresponding microservices
4. Microservices communicate asynchronously through Message Queue
5. Data stored in database, cache stored in Redis

AI workflows on K8s? Please refer to Cloud Native AI to learn about MLOps and Kubeflow.

FAQ

Q1: Should I learn Docker before learning Kubernetes?

Recommended. Docker helps you understand basic container concepts (images, containers, Dockerfile). These concepts are all used in Kubernetes.

Q2: What's the difference between API Gateway and Service Mesh?

API Gateway handles "north-south" traffic (external to internal), Service Mesh handles "east-west" traffic (inter-service communication). Both can coexist.

Q3: Must I use Cloud Native Storage?

Not necessarily. If you use cloud-managed Kubernetes, you can directly use cloud storage services (EBS, Persistent Disk). Self-managed storage is mainly for on-premises deployment or avoiding cloud lock-in.

Q4: Can Buildpacks replace Dockerfile?

For standard applications, Buildpacks can completely replace Dockerfile and are easier to maintain. But if you have special requirements (custom base images, complex build steps), you may still need Dockerfile.

Q5: Is this entire tech stack suitable for small teams?

You don't need to use everything. You can start with Docker + managed Kubernetes, use cloud services for API Gateway (API Gateway, Cloud Endpoints), use cloud services for storage. Add more as needs grow.

Next Steps

There are many components in the Cloud Native tech stack—you don't need to learn everything at once. Recommendations:

1. First master Kubernetes core concepts
2. Learn to containerize your applications
3. Choose API Gateway based on requirements
4. Finally consider storage and other advanced components

Further reading:

• Back to Core Concepts: Cloud Native Complete Guide
• Learn Architecture Principles: 12 Factor App Complete Analysis
• Understand Security Topics: Cloud Native Security Complete Guide
• Explore Cloud Native Databases: Cloud Native Database Selection Guide

Does the Cloud Native tech stack seem complex? Schedule a free consultation and let us help you plan technology selection suitable for your team.

References

• Kubernetes Documentation
• Cloud Native Buildpacks
• CNCF Landscape - API Gateway
• CNCF Landscape - Storage
• Kong Documentation
• Longhorn Documentation

Need Professional Cloud Advice?

Whether you're evaluating cloud platforms, optimizing existing architecture, or looking for cost-saving solutions, we can help

Book Free Consultation