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

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

Component	Function
kube-apiserver	API entry point, all operations go through here
etcd	Distributed key-value store, stores cluster state
kube-scheduler	Decides which node Pods should run on
kube-controller-manager	Executes control loops, maintains desired state

Worker Node

Component	Function
kubelet	Manages Pods on the node
kube-proxy	Handles network rules and load balancing
Container Runtime	Runs containers (containerd, CRI-O)

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

Aspect	Self-Managed (kubeadm)	Managed (EKS/GKE/AKS)
Control Plane Management	Self-responsible	Cloud provider responsible
Upgrade Complexity	High	Low
Cost	Lower (but requires personnel)	Higher (but saves personnel)
Customization	High	Medium

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

Aspect	Virtual Machines	Containers
Startup time	Minutes	Seconds
Resource usage	GB level	MB level
Isolation level	Complete OS	Process level
Image size	Several GB	Tens to hundreds of MB

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

Aspect	Dockerfile	Buildpacks
Required knowledge	Understand base images, layer optimization	Just know how to code
Security updates	Manually update base images	Automatic rebase
Build caching	Manual layer order optimization	Handled automatically
Multi-language support	Different Dockerfile for each language	Auto-detect language

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

Language	Buildpack
Java	Paketo Java Buildpack
Node.js	Paketo Node.js Buildpack
Go	Paketo Go Buildpack
Python	Paketo Python Buildpack
.NET	Paketo .NET Core Buildpack

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

Option	Size	Security	Use Case
Alpine	Smallest	Watch for musl compatibility	Simple applications
Distroless	Small	High (no shell)	Production environments
Official	Medium	Medium	Development and testing

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

Aspect	Ingress Controller	API Gateway
L7 Routing	Basic support	Advanced support
Authentication/Authorization	Limited	Complete
Rate Limiting	Limited	Complete
Plugin ecosystem	Fewer	Rich
Positioning	K8s entry point	API management

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

Requirement	Recommendation
Enterprise features, maturity	Kong
K8s native, Envoy ecosystem	Emissary-Ingress
High performance, rich plugins	APISIX
Simple, auto-discovery	Traefik

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

Solution	Complexity	Features	Performance	Scale
Rook-Ceph	High	Most complete	High	Large
Longhorn	Low	Medium	Medium	Small-Medium
OpenEBS	Medium	Flexible	Medium-High	General

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