Skip to content

Kubernetes

InteSys provides managed Kubernetes clusters and expert consulting for container orchestration. We handle cluster lifecycle, scaling, security, and upgrades so your team can focus on deploying applications.

Managed Kubernetes

Our managed Kubernetes service runs on InteSys Tier 3 infrastructure with:

  • High availability — Multi-master control plane across availability zones
  • Automatic upgrades — Kubernetes version upgrades with zero-downtime rolling updates
  • Integrated monitoring — Prometheus and Grafana pre-configured for cluster metrics
  • Private networking — Cluster nodes on isolated VLANs with controlled ingress

Supported Versions

We maintain the latest three minor versions of Kubernetes. Current supported versions:

Version Status End of Support
1.31 Current Active
1.30 Supported Active
1.29 Supported 2026-06

Deployment Strategies

Deployments and Rolling Updates

The standard Kubernetes Deployment object manages rolling updates automatically:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: registry.intesys.io/myapp:v1.2.0
          ports:
            - containerPort: 8000
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 512Mi

Always Set Resource Requests and Limits

Resource requests ensure your pod gets scheduled on a node with sufficient capacity. Limits prevent a misbehaving pod from consuming all node resources and affecting other workloads.

Health Probes

Kubernetes uses probes to determine pod health. Properly configured probes are critical for reliable deployments.

Liveness Probe

Detects if a pod is stuck and needs to be restarted:

livenessProbe:
  httpGet:
    path: /health
    port: 8000
  initialDelaySeconds: 10
  periodSeconds: 15
  failureThreshold: 3

Readiness Probe

Determines if a pod is ready to receive traffic:

readinessProbe:
  httpGet:
    path: /ready
    port: 8000
  initialDelaySeconds: 5
  periodSeconds: 10
  failureThreshold: 2

Startup Probe

For applications with slow initialization:

startupProbe:
  httpGet:
    path: /health
    port: 8000
  initialDelaySeconds: 0
  periodSeconds: 5
  failureThreshold: 30

Liveness vs Readiness

A liveness probe failure restarts the pod. A readiness probe failure removes it from the service but keeps it running. Use readiness for dependencies (database connectivity) and liveness for deadlock detection.

Horizontal Pod Autoscaler (HPA)

Automatically scale pods based on CPU, memory, or custom metrics:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  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

Scaling Best Practices

  • Set minReplicas to at least 2 for high availability
  • Use PodDisruptionBudget to ensure minimum availability during scaling events
  • Configure appropriate cooldown periods to prevent flapping
  • Monitor HPA behavior with kubectl get hpa and Grafana dashboards

Ingress and TLS

Expose services externally with managed ingress and automatic TLS:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  tls:
    - hosts:
        - app.example.com
      secretName: app-tls
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: myapp
                port:
                  number: 80

Security Best Practices

Practice Implementation
Run as non-root securityContext.runAsNonRoot: true
Read-only filesystem securityContext.readOnlyRootFilesystem: true
Drop capabilities securityContext.capabilities.drop: ["ALL"]
Network policies Restrict pod-to-pod communication
Image scanning Scan images in CI before deployment
RBAC Least-privilege service accounts

Next Steps