Uploaded image for project: 'Couchbase Kubernetes'
  1. Couchbase Kubernetes
  2. K8S-2183

Add option to install sync-gateway as stateful

    XMLWordPrintable

Details

    • Task
    • Status: Closed
    • Major
    • Resolution: Fixed
    • None
    • not-targeted
    • helm
    • None
    • 1

    Description

      Currently sync-gateway is installed as a kubernetes Deployment type.  For users wanting wanting persistence, we can also deploy it as a StatefulSet by adding options for volume mounts.

      Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

          Anuj Sahni I recommend Patrick's approach of streaming the logs.  But just to follow up here, the fix for this already exists in 2.2.1 chart 

          # syncGateway configuration
          syncGateway: 
              kind: Deployment # -- suppports (Deployment | Statefulset) 

          tommie Tommie McAfee added a comment - Anuj Sahni  I recommend Patrick's approach of streaming the logs.  But just to follow up here, the fix for this already exists in 2.2.1 chart  # syncGateway configuration syncGateway: kind: Deployment # -- suppports (Deployment | Statefulset)

          If it's just logs then it makes more sense to follow standard approaches and ensure the containers send their logs to standard output to integrate with both the standard Container Runtime and Kubernetes logging architectures, or forward them with something like our existing Fluent Bit solution. 

          Adding a whole persistence approach just for the sake of getting to logs seems the wrong way to approach the problem. It introduces extra complexity to the overall solution as we have to manage an extra combination of supported platforms with or without persistence. 

          Now we have the logs in a PV but then we need to go get them out of it using another bespoke approach rather than just deploying one of the many logging solutions that will pick them up from the CRI. I imagine a customer would prefer logs all work with the same tooling and it would also prevent losing information due to log rotation.

          patrick.stephens Patrick Stephens (Inactive) added a comment - If it's just logs then it makes more sense to follow standard approaches and ensure the containers send their logs to standard output to integrate with both the standard Container Runtime and Kubernetes logging architectures, or forward them with something like our existing Fluent Bit solution.  Adding a whole persistence approach just for the sake of getting to logs seems the wrong way to approach the problem. It introduces extra complexity to the overall solution as we have to manage an extra combination of supported platforms with or without persistence.  Now we have the logs in a PV but then we need to go get them out of it using another bespoke approach rather than just deploying one of the many logging solutions that will pick them up from the CRI. I imagine a customer would prefer logs all work with the same tooling and it would also prevent losing information due to log rotation.
          anuj.sahni Anuj Sahni added a comment - - edited

          Mostly the use-case is persistent volumes used to persist logs even after pod crashed. I am attaching current version of YAML file where you can see that customer is distributing pods across AZs and writing logs to PV:

           

          apiVersion: apps/v1
          kind: StatefulSet
          metadata:
          name: sync-gateway
          namespace: cb
          spec:
          replicas: 3
          serviceName: sync-gateway
          selector:
          matchLabels:
          app: sync-gateway
          template:
          metadata:
          labels:
          app: sync-gateway
          spec:
          affinity:
          nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:

          • matchExpressions:
          • key: topology.kubernetes.io/zone
            operator: In
            values:
          • us-west-2a
          • us-west-2b
          • us-west-2c
            preferredDuringSchedulingIgnoredDuringExecution:
          • weight: 5
            preference:
            matchExpressions:
          • key: topology.kubernetes.io/hostname
            operator: Exists
            containers:
          • name: sync-gateway
            image: couchbase/sync-gateway:2.8.0-enterprise
            args: [ "/sync-gateway-config/sgw-config.json" ]
            volumeMounts:
          • name: sgw-config-volume
            mountPath: /sync-gateway-config
            readOnly: true
          • name: sgw-pv-home
            mountPath: "/home"
            env:
          • name: GOMAXPROCS
            value: "6"
            resources:
            requests:
            cpu: "6"
            memory: 50Gi
            #sync gateway exporter sidecar container- for metrics collection
          • name: exporter
            image: couchbasesamples/sync-gateway-prometheus-exporter:latest
            args: ["--log.level=info"]
            ports:
          • name: metrics
            containerPort: 9421
            resources:
            requests:
            cpu: 100m
            limits:
            cpu: 100m
            volumes:
          • name: sgw-config-volume
            secret:
            secretName: sgw-config
            volumeClaimTemplates:
          • metadata:
            name: sgw-pv-home
            spec:
            storageClassName: gp2-multi-data
            accessModes:
          • ReadWriteOnce
            resources:
            requests:
            storage: 128Gi

           

          anuj.sahni Anuj Sahni added a comment - - edited Mostly the use-case is persistent volumes used to persist logs even after pod crashed. I am attaching current version of YAML file where you can see that customer is distributing pods across AZs and writing logs to PV:   apiVersion: apps/v1 kind: StatefulSet metadata: name: sync-gateway namespace: cb spec: replicas: 3 serviceName: sync-gateway selector: matchLabels: app: sync-gateway template: metadata: labels: app: sync-gateway spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: matchExpressions: key: topology.kubernetes.io/zone operator: In values: us-west-2a us-west-2b us-west-2c preferredDuringSchedulingIgnoredDuringExecution: weight: 5 preference: matchExpressions: key: topology.kubernetes.io/hostname operator: Exists containers: name: sync-gateway image: couchbase/sync-gateway:2.8.0-enterprise args: [ "/sync-gateway-config/sgw-config.json" ] volumeMounts: name: sgw-config-volume mountPath: /sync-gateway-config readOnly: true name: sgw-pv-home mountPath: "/home" env: name: GOMAXPROCS value: "6" resources: requests: cpu: "6" memory: 50Gi #sync gateway exporter sidecar container- for metrics collection name: exporter image: couchbasesamples/sync-gateway-prometheus-exporter:latest args: ["--log.level=info"] ports: name: metrics containerPort: 9421 resources: requests: cpu: 100m limits: cpu: 100m volumes: name: sgw-config-volume secret: secretName: sgw-config volumeClaimTemplates: metadata: name: sgw-pv-home spec: storageClassName: gp2-multi-data accessModes: ReadWriteOnce resources: requests: storage: 128Gi  
          tommie Tommie McAfee added a comment - - edited

          Anuj Sahni, this change is staged for 2.2 https://github.com/couchbase-partners/helm-charts/commit/31aeb6699d0640aaf30896dcbfb8e4ede4fab21a

          Before merging I wanted a clear understanding of the use-case.  As I tested this I couldn't think of a path that needed to be persisted since sync gateway is completely stateless.  What path is the customer looking to mount with persistent volumes?

          Also does it have to be a Statefulset? Because a regular deployment type can still have persistent volumeMounts.

          tommie Tommie McAfee added a comment - - edited Anuj Sahni , this change is staged for 2.2 https://github.com/couchbase-partners/helm-charts/commit/31aeb6699d0640aaf30896dcbfb8e4ede4fab21a Before merging I wanted a clear understanding of the use-case.  As I tested this I couldn't think of a path that needed to be persisted since sync gateway is completely stateless.  What path is the customer looking to mount with persistent volumes? Also does it have to be a Statefulset? Because a regular deployment type can still have persistent volumeMounts.

          People

            tommie Tommie McAfee
            tommie Tommie McAfee
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Gerrit Reviews

                There are no open Gerrit changes

                PagerDuty