Kubernetes Setup for Web Application Orchestration

When a web application grows to dozens of microservices, manual server management turns into hell. Containers crash, load spikes, deployments fail. Kubernetes is the standard for production environments, automating container management: restart, scaling, rolling updates. Our team has set up Kubernetes for 30+ projects — from startups to enterprise. We guarantee stable operation under any load.

How to Set Up Kubernetes for Web Application Orchestration?

Managed Kubernetes (Yandex Managed Service for Kubernetes, Selectel VK Cloud) eliminates the headache of master nodes, etcd, and updates. You pay only for worker nodes. We recommend using it for production to focus on the application rather than infrastructure. Comparison: a managed cluster pays off with 5+ nodes compared to self-deployment, and administration costs drop by up to 40%.

Minimal Set of Manifests

To get started, five resources are enough: Namespace, Deployment, Service, Ingress, HPA. Below is a working template with explanations.

# namespace.yaml apiVersion: v1 kind: Namespace metadata: name: myapp --- # deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: myapp-web namespace: myapp spec: replicas: 3 selector: matchLabels: { app: myapp-web } template: metadata: labels: { app: myapp-web } spec: containers: - name: web image: registry.example.com/myapp:v1.0.0 ports: - containerPort: 8080 envFrom: - configMapRef: { name: myapp-config } - secretRef: { name: myapp-secrets } resources: requests: cpu: "100m" memory: "256Mi" limits: cpu: "500m" memory: "512Mi" readinessProbe: httpGet: { path: /health/ready, port: 8080 } initialDelaySeconds: 10 periodSeconds: 5 livenessProbe: httpGet: { path: /health/live, port: 8080 } initialDelaySeconds: 30 periodSeconds: 30 --- # service.yaml apiVersion: v1 kind: Service metadata: name: myapp-web namespace: myapp spec: selector: { app: myapp-web } ports: - port: 80 targetPort: 8080 --- # ingress.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: myapp-ingress namespace: myapp annotations: cert-manager.io/cluster-issuer: letsencrypt-prod nginx.ingress.kubernetes.io/rate-limit: "100" nginx.ingress.kubernetes.io/proxy-body-size: "50m" spec: ingressClassName: nginx tls: - hosts: [example.com] secretName: myapp-tls rules: - host: example.com http: paths: - path: / pathType: Prefix backend: service: name: myapp-web port: { number: 80 } 

We combined the manifests into one block for brevity. ConfigMap and Secret are described in the text — their structure is trivial. Important: secrets are base64-encoded; do not store them in a repository, use SealedSecrets or an external secret store (Hashicorp Vault, AWS Secrets Manager).

Horizontal Scaling and Autoscaling

HPA (HorizontalPodAutoscaler)

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: myapp-hpa namespace: myapp spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: myapp-web minReplicas: 2 maxReplicas: 20 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 - type: Resource resource: name: memory target: type: Utilization averageUtilization: 80 

HPA automatically adds replicas when CPU or memory thresholds are exceeded. This is cheaper than keeping 20 pods all the time: at low load it runs 2, at peak up to 20. We saw this save projects during ad campaigns, reducing infrastructure costs by 30-50%.

Periodic Tasks: CronJob

For background tasks (file cleanup, report sending), we use CronJob.

apiVersion: batch/v1 kind: CronJob metadata: name: cleanup-old-files namespace: myapp spec: schedule: "0 2 * * *" concurrencyPolicy: Forbid jobTemplate: spec: template: spec: restartPolicy: OnFailure containers: - name: cleanup image: registry.example.com/myapp:latest command: ["php", "artisan", "files:cleanup"] envFrom: - secretRef: { name: myapp-secrets } 

Work Process: From Analysis to Deployment

• Analysis — We study the application architecture, SLA requirements, and current issues.
• Design — We design the cluster: number of nodes, storage class, network, ingress controller.
• Implementation — We write manifests, set up CI/CD (GitLab CI, GitHub Actions), integrate monitoring (Prometheus + Grafana).
• Testing — Load testing, fault tolerance verification (chaos engineering).
• Deployment — Deploy to staging and production, train the team.

What's Included in the Result

• Kubernetes manifests: Deployment, Service, Ingress, HPA, CronJob, ConfigMap, Secret.
• CI/CD pipeline: automatic image builds, deployment via Helm or Kustomize.
• Monitoring and alerts: Grafana dashboards, alerts to Telegram/Slack.
• Documentation: architecture diagram, developer instructions.
• Team training: 2-3 sessions on cluster operations.
• 2 weeks of post-launch support — bug fixes, Q&A.

Timeline

Cost is calculated individually based on project complexity. Request a free consultation — we'll evaluate your project.

Comparison with Docker Compose

Docker Compose is good for local development, but in production it cannot handle high load. Kubernetes offers built-in scaling, self-healing, service discovery, and rolling updates. For example, at 1000 RPS, Kubernetes survives a node failure without losing requests, while Docker Compose does not.

Why Is Correct Container Resource Configuration Important?

Incorrect requests and limits lead to OOM kills or cluster underutilization. We use Vertical Pod Autoscaler based on historical data to pick optimal values. This reduces infrastructure costs by up to 40% and increases stability. Learn more about resources in the Kubernetes documentation.

Typical Mistakes in Kubernetes Setup

• Missing readiness and liveness probes: the pod is considered healthy but does not respond to requests.
• Too large limits overload the cluster and degrade neighboring pod performance.
• Storing secrets in plain text creates a leak risk.
• Ignoring resource quotas allows one pod to consume all resources.

We help avoid these pitfalls. Contact us for a detailed consultation.

Case Study: E-Commerce Platform

A client with a high-load e-commerce platform (800 RPS average, 5000 RPS peak on Black Friday) was using Docker Compose in production. Servers crashed monthly, scaling took 30 minutes manually. We migrated to a Kubernetes cluster on Yandex Managed Kubernetes with HPA and rolling updates. Result: deployment time dropped from 30 minutes to 2 minutes, infrastructure costs reduced by 35% due to right-sizing and autoscaling. During peak load, the system scaled from 5 to 25 pods automatically without any downtime.

Conclusion

Kubernetes is a powerful but complex tool. Proper setup requires experience. Our team has 10+ years in DevOps and over 50 implementations. We guarantee stability and speed. Get a free consultation — let's discuss your project and propose the best solution.