{"slug":"building-microservices-kubernetes","meta":{"published":true,"featured":false,"slug":"building-microservices-kubernetes","title":"Building Production-Ready Microservices with Kubernetes - A Complete Guide","description":"Learn how to architect, deploy, and manage scalable microservices on Kubernetes. From service mesh implementation to monitoring strategies, discover the proven patterns we use for enterprise clients.","created_at":"2021/08/22 14:15","modified_at":"2021/08/22 14:15","canonical_url":"https://upgo.ca/blog/building-microservices-kubernetes","domain":"https://upgo.ca","tabs":[],"tags":[],"keywords":"","readMin":12},"code":"\nThe Journey to Cloud-Native: Why Microservices and Kubernetes Matter\n

Three years ago, Up Go Corp embarked on a mission to help enterprise clients modernize their legacy applications through microservices architecture and Kubernetes orchestration. What we discovered was that while the promise of scalability, resilience, and developer productivity is real, the path to production-ready microservices requires careful planning, robust tooling, and battle-tested patterns.

This comprehensive guide shares the practical lessons we’ve learned from deploying over 40 microservices architectures for clients ranging from fintech startups to multinational corporations. We’ll cover everything from initial architecture decisions to production monitoring strategies.

\nUnderstanding the Microservices Landscape\nThe Monolith to Microservices Evolution\n

Before diving into Kubernetes specifics, it’s crucial to understand when and why microservices make sense. We’ve seen many organizations rush into microservices without proper justification, only to discover they’ve traded the complexity of a large codebase for the complexity of distributed systems.

When Microservices Are the Right Choice:

Teams are growing beyond 8-10 developers per service
Different parts of the application have different scaling requirements
Technology diversity is needed (different languages, databases)
Independent deployment cycles are critical for business agility
Clear domain boundaries exist within the application

When to Stick with Monoliths:

Small teams (under 10 developers total)
Simple applications with limited complexity
Tight coupling between business domains
Limited operational maturity for managing distributed systems

The Kubernetes Advantage

Kubernetes has emerged as the de facto standard for container orchestration, and for good reason:

Declarative Configuration: Infrastructure as code through YAML manifests
Self-Healing: Automatic restart of failed containers and rescheduling
Horizontal Scaling: Built-in horizontal pod autoscaling
Service Discovery: Native DNS-based service discovery
Load Balancing: Integrated load balancing and traffic distribution
Rolling Updates: Zero-downtime deployments with rollback capabilities

\nDesigning Microservices Architecture\n

Domain-Driven Design Principles

Successful microservices start with proper domain modeling. We use Domain-Driven Design (DDD) to identify service boundaries:

# Example: E-commerce Platform Service Breakdown\nservices:\n  user-service:\n    domain: User Management\n    responsibilities:\n      - User registration and authentication\n      - Profile management\n      - Preferences and settings\n    data: User profiles, credentials, preferences\n\n  catalog-service:\n    domain: Product Catalog\n    responsibilities:\n      - Product information management\n      - Inventory tracking\n      - Search and filtering\n    data: Products, categories, inventory levels\n\n  order-service:\n    domain: Order Management\n    responsibilities:\n      - Order processing\n      - Order history\n      - Order status tracking\n    data: Orders, order items, order status\n\n  payment-service:\n    domain: Payment Processing\n    responsibilities:\n      - Payment processing\n      - Payment method management\n      - Transaction history\n    data: Payment transactions, payment methods\n\n  notification-service:\n    domain: Communications\n    responsibilities:\n      - Email notifications\n      - SMS alerts\n      - Push notifications\n    data: Notification templates, delivery logs

Communication Patterns

Synchronous Communication (REST/gRPC):

# Service-to-service REST communication\napiVersion: v1\nkind: Service\nmetadata:\n  name: catalog-service\n  labels:\n    app: catalog\nspec:\n  selector:\n    app: catalog\n  ports:\n    - name: http\n      port: 80\n      targetPort: 8080\n    - name: grpc\n      port: 9090\n      targetPort: 9090

Asynchronous Communication (Message Queues):

# Event-driven architecture with Kafka\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: kafka\nspec:\n  replicas: 3\n  selector:\n    matchLabels:\n      app: kafka\n  template:\n    metadata:\n      labels:\n        app: kafka\n    spec:\n      containers:\n        - name: kafka\n          image: confluentinc/cp-kafka:7.0.0\n          env:\n            - name: KAFKA_BROKER_ID\n              value: '1'\n            - name: KAFKA_ZOOKEEPER_CONNECT\n              value: 'zookeeper:2181'\n            - name: KAFKA_ADVERTISED_LISTENERS\n              value: 'PLAINTEXT://kafka:9092'

Kubernetes Deployment Strategies

Container Best Practices

Before deploying to Kubernetes, ensure your containers follow these principles:

# Optimized Node.js microservice Dockerfile\nFROM node:18-alpine AS builder\n\nWORKDIR /app\nCOPY package*.json ./\nRUN npm ci --only=production && npm cache clean --force\n\nFROM node:18-alpine AS runtime\n\n# Create non-root user\nRUN addgroup -g 1001 -S nodejs && \\\n    adduser -S nodejs -u 1001\n\nWORKDIR /app\n\n# Copy built application\nCOPY --from=builder /app/node_modules ./node_modules\nCOPY --chown=nodejs:nodejs . .\n\n# Security: Run as non-root user\nUSER nodejs\n\n# Health check\nHEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \\\n  CMD node healthcheck.js\n\nEXPOSE 3000\n\nCMD [\"node\", \"server.js\"]

Deployment Manifests

Basic Deployment with Health Checks:

apiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: user-service\n  labels:\n    app: user-service\n    version: v1\nspec:\n  replicas: 3\n  selector:\n    matchLabels:\n      app: user-service\n  template:\n    metadata:\n      labels:\n        app: user-service\n        version: v1\n    spec:\n      containers:\n        - name: user-service\n          image: user-service:1.2.0\n          ports:\n            - containerPort: 3000\n          env:\n            - name: DATABASE_URL\n              valueFrom:\n                secretKeyRef:\n                  name: user-service-secrets\n                  key: database-url\n            - name: JWT_SECRET\n              valueFrom:\n                secretKeyRef:\n                  name: user-service-secrets\n                  key: jwt-secret\n          resources:\n            requests:\n              memory: '128Mi'\n              cpu: '100m'\n            limits:\n              memory: '256Mi'\n              cpu: '200m'\n          livenessProbe:\n            httpGet:\n              path: /health\n              port: 3000\n            initialDelaySeconds: 30\n            periodSeconds: 10\n            timeoutSeconds: 5\n            failureThreshold: 3\n          readinessProbe:\n            httpGet:\n              path: /ready\n              port: 3000\n            initialDelaySeconds: 5\n            periodSeconds: 5\n            timeoutSeconds: 3\n            failureThreshold: 3\n          securityContext:\n            runAsNonRoot: true\n            runAsUser: 1001\n            allowPrivilegeEscalation: false\n            readOnlyRootFilesystem: true\n            capabilities:\n              drop:\n                - ALL

Configuration Management

Using ConfigMaps and Secrets:

# ConfigMap for application configuration\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: user-service-config\ndata:\n  app.properties: |\n    server.port=3000\n    logging.level=info\n    cache.ttl=3600\n    rate.limit.requests=1000\n    rate.limit.window=60\n\n---\n# Secret for sensitive data\napiVersion: v1\nkind: Secret\nmetadata:\n  name: user-service-secrets\ntype: Opaque\ndata:\n  database-url: <base64-encoded-database-url>\n  jwt-secret: <base64-encoded-jwt-secret>\n  redis-password: <base64-encoded-redis-password>

\nService Mesh Implementation with Istio\n

Why Service Mesh?

As microservices architectures grow, managing service-to-service communication becomes complex. Service mesh provides:

Traffic Management: Advanced routing, load balancing, and failover
Security: Mutual TLS, authentication, and authorization
Observability: Distributed tracing, metrics, and logging
Policy Enforcement: Rate limiting, circuit breaking, and retries

\nIstio Installation and Configuration\n

# Install Istio\ncurl -L https://istio.io/downloadIstio | sh -\ncd istio-1.15.0\nexport PATH=$PWD/bin:$PATH\n\n# Install Istio with configuration profile\nistioctl install --set values.defaultRevision=default

Enable Automatic Sidecar Injection:

apiVersion: v1\nkind: Namespace\nmetadata:\n  name: microservices\n  labels:\n    istio-injection: enabled

Traffic Management Example:

# Virtual Service for canary deployments\napiVersion: networking.istio.io/v1beta1\nkind: VirtualService\nmetadata:\n  name: user-service\nspec:\n  hosts:\n    - user-service\n  http:\n    - match:\n        - headers:\n            canary:\n              exact: 'true'\n      route:\n        - destination:\n            host: user-service\n            subset: v2\n          weight: 100\n    - route:\n        - destination:\n            host: user-service\n            subset: v1\n          weight: 90\n        - destination:\n            host: user-service\n            subset: v2\n          weight: 10\n\n---\n# Destination Rule for version-based routing\napiVersion: networking.istio.io/v1beta1\nkind: DestinationRule\nmetadata:\n  name: user-service\nspec:\n  host: user-service\n  trafficPolicy:\n    circuitBreaker:\n      consecutiveErrors: 3\n      interval: 30s\n      baseEjectionTime: 30s\n      maxEjectionPercent: 50\n  subsets:\n    - name: v1\n      labels:\n        version: v1\n    - name: v2\n      labels:\n        version: v2

Security with Mutual TLS

# Enable strict mTLS for the namespace\napiVersion: security.istio.io/v1beta1\nkind: PeerAuthentication\nmetadata:\n  name: default\n  namespace: microservices\nspec:\n  mtls:\n    mode: STRICT\n\n---\n# Authorization policy\napiVersion: security.istio.io/v1beta1\nkind: AuthorizationPolicy\nmetadata:\n  name: user-service-authz\n  namespace: microservices\nspec:\n  selector:\n    matchLabels:\n      app: user-service\n  rules:\n    - from:\n        - source:\n            principals: ['cluster.local/ns/microservices/sa/order-service']\n      to:\n        - operation:\n            methods: ['GET', 'POST']\n      when:\n        - key: request.headers[authorization]\n          values: ['Bearer *']

Monitoring and Observability

The Three Pillars of Observability

1. Metrics with Prometheus and Grafana:

# Prometheus configuration\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: prometheus-config\ndata:\n  prometheus.yml: |\n    global:\n      scrape_interval: 15s\n\n    scrape_configs:\n    - job_name: 'kubernetes-pods'\n      kubernetes_sd_configs:\n      - role: pod\n      relabel_configs:\n      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]\n        action: keep\n        regex: true\n      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]\n        action: replace\n        target_label: __metrics_path__\n        regex: (.+)

2. Logging with ELK Stack:

# Fluentd DaemonSet for log collection\napiVersion: apps/v1\nkind: DaemonSet\nmetadata:\n  name: fluentd\nspec:\n  selector:\n    matchLabels:\n      name: fluentd\n  template:\n    metadata:\n      labels:\n        name: fluentd\n    spec:\n      containers:\n        - name: fluentd\n          image: fluentd:v1.14-debian-1\n          env:\n            - name: FLUENT_ELASTICSEARCH_HOST\n              value: 'elasticsearch'\n            - name: FLUENT_ELASTICSEARCH_PORT\n              value: '9200'\n          volumeMounts:\n            - name: varlog\n              mountPath: /var/log\n            - name: varlibdockercontainers\n              mountPath: /var/lib/docker/containers\n              readOnly: true\n      volumes:\n        - name: varlog\n          hostPath:\n            path: /var/log\n        - name: varlibdockercontainers\n          hostPath:\n            path: /var/lib/docker/containers

3. Distributed Tracing with Jaeger:

# Jaeger Operator deployment\napiVersion: jaegertracing.io/v1\nkind: Jaeger\nmetadata:\n  name: jaeger\nspec:\n  strategy: production\n  storage:\n    type: elasticsearch\n    elasticsearch:\n      nodeCount: 3\n      storage:\n        size: 10Gi\n      redundancyPolicy: SingleRedundancy

Application-Level Monitoring

Node.js Service with Prometheus Metrics:

// metrics.js\nconst promClient = require('prom-client');\n\n// Create a Registry to register the metrics\nconst register = new promClient.Registry();\n\n// Add default metrics\npromClient.collectDefaultMetrics({\n  app: 'user-service',\n  timeout: 10000,\n  gcDurationBuckets: [0.001, 0.01, 0.1, 1, 2, 5],\n  register\n});\n\n// Custom business metrics\nconst httpRequestsTotal = new promClient.Counter({\n  name: 'http_requests_total',\n  help: 'Total number of HTTP requests',\n  labelNames: ['method', 'route', 'status_code'],\n  registers: [register]\n});\n\nconst httpRequestDuration = new promClient.Histogram({\n  name: 'http_request_duration_seconds',\n  help: 'Duration of HTTP requests in seconds',\n  labelNames: ['method', 'route', 'status_code'],\n  buckets: [0.1, 0.5, 1, 2, 5, 10],\n  registers: [register]\n});\n\nconst activeConnections = new promClient.Gauge({\n  name: 'active_connections',\n  help: 'Number of active connections',\n  registers: [register]\n});\n\n// Database connection pool metrics\nconst dbConnectionsActive = new promClient.Gauge({\n  name: 'db_connections_active',\n  help: 'Number of active database connections',\n  registers: [register]\n});\n\nconst dbConnectionsIdle = new promClient.Gauge({\n  name: 'db_connections_idle',\n  help: 'Number of idle database connections',\n  registers: [register]\n});\n\n// Business logic metrics\nconst userRegistrations = new promClient.Counter({\n  name: 'user_registrations_total',\n  help: 'Total number of user registrations',\n  labelNames: ['source'],\n  registers: [register]\n});\n\nconst userLogins = new promClient.Counter({\n  name: 'user_logins_total',\n  help: 'Total number of user logins',\n  labelNames: ['method'],\n  registers: [register]\n});\n\nmodule.exports = {\n  register,\n  httpRequestsTotal,\n  httpRequestDuration,\n  activeConnections,\n  dbConnectionsActive,\n  dbConnectionsIdle,\n  userRegistrations,\n  userLogins\n};

Production Deployment Patterns

Blue-Green Deployments

# Blue deployment (current production)\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: user-service-blue\n  labels:\n    app: user-service\n    version: blue\nspec:\n  replicas: 3\n  selector:\n    matchLabels:\n      app: user-service\n      version: blue\n  template:\n    metadata:\n      labels:\n        app: user-service\n        version: blue\n    spec:\n      containers:\n        - name: user-service\n          image: user-service:1.2.0\n          # ... container spec\n\n---\n# Green deployment (new version)\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: user-service-green\n  labels:\n    app: user-service\n    version: green\nspec:\n  replicas: 3\n  selector:\n    matchLabels:\n      app: user-service\n      version: green\n  template:\n    metadata:\n      labels:\n        app: user-service\n        version: green\n    spec:\n      containers:\n        - name: user-service\n          image: user-service:1.3.0\n          # ... container spec\n\n---\n# Service switching between blue and green\napiVersion: v1\nkind: Service\nmetadata:\n  name: user-service\nspec:\n  selector:\n    app: user-service\n    version: blue # Switch to 'green' for deployment\n  ports:\n    - port: 80\n      targetPort: 3000

Canary Deployments with Flagger

# Flagger Canary resource\napiVersion: flagger.app/v1beta1\nkind: Canary\nmetadata:\n  name: user-service\n  namespace: microservices\nspec:\n  targetRef:\n    apiVersion: apps/v1\n    kind: Deployment\n    name: user-service\n  progressDeadlineSeconds: 60\n  service:\n    port: 80\n    targetPort: 3000\n    gateways:\n      - public-gateway\n    hosts:\n      - user-service.example.com\n  analysis:\n    interval: 1m\n    threshold: 5\n    maxWeight: 50\n    stepWeight: 10\n    metrics:\n      - name: request-success-rate\n        thresholdRange:\n          min: 99\n        interval: 1m\n      - name: request-duration\n        thresholdRange:\n          max: 500\n        interval: 30s\n    webhooks:\n      - name: acceptance-test\n        type: pre-rollout\n        url: http://flagger-loadtester.test/\n        timeout: 30s\n        metadata:\n          type: bash\n          cmd: \"curl -sd 'test' http://user-service-canary/api/health | grep OK\"\n      - name: load-test\n        url: http://flagger-loadtester.test/\n        timeout: 5s\n        metadata:\n          cmd: 'hey -z 1m -q 10 -c 2 http://user-service-canary.microservices/'

Security Best Practices

Pod Security Standards

# Pod Security Policy\napiVersion: policy/v1beta1\nkind: PodSecurityPolicy\nmetadata:\n  name: microservices-psp\nspec:\n  privileged: false\n  allowPrivilegeEscalation: false\n  requiredDropCapabilities:\n    - ALL\n  volumes:\n    - 'configMap'\n    - 'emptyDir'\n    - 'projected'\n    - 'secret'\n    - 'downwardAPI'\n    - 'persistentVolumeClaim'\n  runAsUser:\n    rule: 'MustRunAsNonRoot'\n  seLinux:\n    rule: 'RunAsAny'\n  fsGroup:\n    rule: 'RunAsAny'

Network Policies

# Network policy for user service\napiVersion: networking.k8s.io/v1\nkind: NetworkPolicy\nmetadata:\n  name: user-service-netpol\n  namespace: microservices\nspec:\n  podSelector:\n    matchLabels:\n      app: user-service\n  policyTypes:\n    - Ingress\n    - Egress\n  ingress:\n    - from:\n        - namespaceSelector:\n            matchLabels:\n              name: api-gateway\n        - podSelector:\n            matchLabels:\n              app: order-service\n      ports:\n        - protocol: TCP\n          port: 3000\n  egress:\n    - to:\n        - namespaceSelector:\n            matchLabels:\n              name: database\n      ports:\n        - protocol: TCP\n          port: 5432\n    - to: []\n      ports:\n        - protocol: TCP\n          port: 53\n        - protocol: UDP\n          port: 53

Scaling Strategies

Horizontal Pod Autoscaler

apiVersion: autoscaling/v2\nkind: HorizontalPodAutoscaler\nmetadata:\n  name: user-service-hpa\nspec:\n  scaleTargetRef:\n    apiVersion: apps/v1\n    kind: Deployment\n    name: user-service\n  minReplicas: 3\n  maxReplicas: 20\n  metrics:\n    - type: Resource\n      resource:\n        name: cpu\n        target:\n          type: Utilization\n          averageUtilization: 70\n    - type: Resource\n      resource:\n        name: memory\n        target:\n          type: Utilization\n          averageUtilization: 80\n    - type: Pods\n      pods:\n        metric:\n          name: http_requests_per_second\n        target:\n          type: AverageValue\n          averageValue: '100'

Vertical Pod Autoscaler

apiVersion: autoscaling.k8s.io/v1\nkind: VerticalPodAutoscaler\nmetadata:\n  name: user-service-vpa\nspec:\n  targetRef:\n    apiVersion: apps/v1\n    kind: Deployment\n    name: user-service\n  updatePolicy:\n    updateMode: 'Auto'\n  resourcePolicy:\n    containerPolicies:\n      - containerName: user-service\n        maxAllowed:\n          cpu: 1\n          memory: 2Gi\n        minAllowed:\n          cpu: 100m\n          memory: 128Mi\n        mode: Auto

Lessons Learned from Production

Common Pitfalls and Solutions

1. Resource Limits and Requests

Problem: Services getting OOMKilled or CPU throttled
Solution: Proper resource profiling and gradual limit adjustment
Monitoring: Track resource usage patterns over time

2. Health Check Configuration

Problem: Premature pod termination during startup
Solution: Separate liveness and readiness probes with appropriate delays
Best Practice: Include dependency checks in readiness probes

3. Service Discovery Issues

Problem: Services unable to find dependencies during scaling events
Solution: Use Kubernetes DNS with proper service naming conventions
Monitoring: Track DNS resolution metrics

4. Database Connection Management

Problem: Connection pool exhaustion during traffic spikes
Solution: Implement connection pooling with proper limits and monitoring
Pattern: Use pgbouncer or similar connection poolers

Performance Optimization Strategies

1. JVM Tuning for Java Services:

env:\n  - name: JAVA_OPTS\n    value: >-\n      -XX:+UseG1GC\n      -XX:MaxRAMPercentage=75.0\n      -XX:+UseStringDeduplication\n      -XX:+PrintGCDetails\n      -XX:+PrintGCTimeStamps\n      -Dspring.jpa.hibernate.ddl-auto=none\n      -Dlogging.level.com.zaxxer.hikari=DEBUG

2. Node.js Optimization:

env:\n  - name: NODE_OPTIONS\n    value: '--max-old-space-size=1024 --enable-source-maps'\n  - name: UV_THREADPOOL_SIZE\n    value: '16'

3. Redis Configuration for Caching:

apiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: redis-config\ndata:\n  redis.conf: |\n    maxmemory 256mb\n    maxmemory-policy allkeys-lru\n    timeout 0\n    tcp-keepalive 60\n    save \"\"

Conclusion

Building production-ready microservices on Kubernetes is a journey that requires careful planning, robust tooling, and continuous learning. At Up Go Corp, we’ve found that success comes from:

Starting with proper domain modeling using DDD principles
Implementing comprehensive observability from day one
Prioritizing security throughout the development lifecycle
Embracing automation for deployment and scaling
Learning from failures and building resilient systems

The patterns and practices outlined in this guide have been battle-tested across dozens of client implementations. However, remember that every organization’s needs are unique, and these patterns should be adapted to fit your specific requirements.

The future of microservices lies in continued simplification and standardization. Projects like Istio, Linkerd, and the CNCF ecosystem are making it easier to implement sophisticated patterns without reinventing the wheel. As the tooling matures, we expect to see even more organizations successfully adopting microservices architectures.

At Up Go Corp, we specialize in helping organizations navigate their cloud-native transformation journey. If you’re considering microservices architecture or need help optimizing your existing Kubernetes deployments, we’d love to help. Contact us for a consultation.

\n","toc":{"id":"toc","data":[{"level":2,"text":"The Journey to Cloud-Native: Why Microservices and Kubernetes Matter","id":"the-journey-to-cloud-native-why-microservices-and-kubernetes-matter"},{"level":2,"text":"Understanding the Microservices Landscape","id":"understanding-the-microservices-landscape"},{"level":3,"text":"The Monolith to Microservices Evolution","id":"the-monolith-to-microservices-evolution"},{"level":3,"text":"The Kubernetes Advantage","id":"the-kubernetes-advantage"},{"level":2,"text":"Designing Microservices Architecture","id":"designing-microservices-architecture"},{"level":3,"text":"Domain-Driven Design Principles","id":"domain-driven-design-principles"},{"level":1,"text":"Example: E-commerce Platform Service Breakdown","id":"example-e-commerce-platform-service-breakdown"},{"level":3,"text":"Communication Patterns","id":"communication-patterns"},{"level":1,"text":"Service-to-service REST communication","id":"service-to-service-rest-communication"},{"level":1,"text":"Event-driven architecture with Kafka","id":"event-driven-architecture-with-kafka"},{"level":2,"text":"Kubernetes Deployment Strategies","id":"kubernetes-deployment-strategies"},{"level":3,"text":"Container Best Practices","id":"container-best-practices"},{"level":1,"text":"Optimized Node.js microservice Dockerfile","id":"optimized-nodejs-microservice-dockerfile"},{"level":1,"text":"Create non-root user","id":"create-non-root-user"},{"level":1,"text":"Copy built application","id":"copy-built-application"},{"level":1,"text":"Security: Run as non-root user","id":"security-run-as-non-root-user"},{"level":1,"text":"Health check","id":"health-check"},{"level":3,"text":"Deployment Manifests","id":"deployment-manifests"},{"level":3,"text":"Configuration Management","id":"configuration-management"},{"level":1,"text":"ConfigMap for application configuration","id":"configmap-for-application-configuration"},{"level":1,"text":"Secret for sensitive data","id":"secret-for-sensitive-data"},{"level":2,"text":"Service Mesh Implementation with Istio","id":"service-mesh-implementation-with-istio"},{"level":3,"text":"Why Service Mesh?","id":"why-service-mesh"},{"level":3,"text":"Istio Installation and Configuration","id":"istio-installation-and-configuration"},{"level":1,"text":"Install Istio","id":"install-istio"},{"level":1,"text":"Install Istio with configuration profile","id":"install-istio-with-configuration-profile"},{"level":1,"text":"Virtual Service for canary deployments","id":"virtual-service-for-canary-deployments"},{"level":1,"text":"Destination Rule for version-based routing","id":"destination-rule-for-version-based-routing"},{"level":3,"text":"Security with Mutual TLS","id":"security-with-mutual-tls"},{"level":1,"text":"Enable strict mTLS for the namespace","id":"enable-strict-mtls-for-the-namespace"},{"level":1,"text":"Authorization policy","id":"authorization-policy"},{"level":2,"text":"Monitoring and Observability","id":"monitoring-and-observability"},{"level":3,"text":"The Three Pillars of Observability","id":"the-three-pillars-of-observability"},{"level":1,"text":"Prometheus configuration","id":"prometheus-configuration"},{"level":1,"text":"Fluentd DaemonSet for log collection","id":"fluentd-daemonset-for-log-collection"},{"level":1,"text":"Jaeger Operator deployment","id":"jaeger-operator-deployment"},{"level":3,"text":"Application-Level Monitoring","id":"application-level-monitoring"},{"level":2,"text":"Production Deployment Patterns","id":"production-deployment-patterns"},{"level":3,"text":"Blue-Green Deployments","id":"blue-green-deployments"},{"level":1,"text":"Blue deployment (current production)","id":"blue-deployment-current-production"},{"level":1,"text":"Green deployment (new version)","id":"green-deployment-new-version"},{"level":1,"text":"Service switching between blue and green","id":"service-switching-between-blue-and-green"},{"level":3,"text":"Canary Deployments with Flagger","id":"canary-deployments-with-flagger"},{"level":1,"text":"Flagger Canary resource","id":"flagger-canary-resource"},{"level":2,"text":"Security Best Practices","id":"security-best-practices"},{"level":3,"text":"Pod Security Standards","id":"pod-security-standards"},{"level":1,"text":"Pod Security Policy","id":"pod-security-policy"},{"level":3,"text":"Network Policies","id":"network-policies"},{"level":1,"text":"Network policy for user service","id":"network-policy-for-user-service"},{"level":2,"text":"Scaling Strategies","id":"scaling-strategies"},{"level":3,"text":"Horizontal Pod Autoscaler","id":"horizontal-pod-autoscaler"},{"level":3,"text":"Vertical Pod Autoscaler","id":"vertical-pod-autoscaler"},{"level":2,"text":"Lessons Learned from Production","id":"lessons-learned-from-production"},{"level":3,"text":"Common Pitfalls and Solutions","id":"common-pitfalls-and-solutions"},{"level":3,"text":"Performance Optimization Strategies","id":"performance-optimization-strategies"},{"level":2,"text":"Conclusion","id":"conclusion"}]}}