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

Document Helm 2.1 upgrade process with tls.generate=true

    XMLWordPrintable

Details

    • Page
    • Status: Closed
    • Major
    • Resolution: Fixed
    • None
    • 2.2.0
    • documentation, helm
    • None
    • 16: Autoscaling/PE/Docs
    • 1

    Description

      From the values.yaml for Helm we have the following:

        # TLS Certs that will be used to encrypt traffic between operator and couchbase
        tls:
          # enable to auto create certs
          generate: false
          # Expiry time of CA in days for generated certs
          expiration: 365
      
      

      We need to explain this bit better, when customer set this to true, the Operator will actually go through the process of creating the certs (https://docs.couchbase.com/operator/current/tutorial-tls.html#creating-a-client-certificate) and then create and config the secrets (https://docs.couchbase.com/operator/current/howto-tls.html) for the cluster.

      This causes an issue with upgrade as noted in https://issues.couchbase.com/browse/K8S-1900 because with Operator 2.1 requires an extra SAN

      ```
      DNS:host.${cluster}.${namespace}.svc.cluster.local
      ```

      Without this, when upgrading the Operator will report this error:

      {"level":"error","ts":1611102051.5212724,"logger":"cluster","msg":"Reconciliation failed","cluster":"default/demo","error":"certificate cannot be verified for zone: x509: certificate is valid for localhost, *.demo-couchbase-cluster.default.svc, *.demo-couchbase-cluster.default, *.demo-couchbase-cluster, *.demo-couchbase-cluster-srv.default.svc, *.demo-couchbase-cluster-srv.default, *.demo-couchbase-cluster-srv, demo-couchbase-cluster-srv.default.svc, demo-couchbase-cluster-srv.default, demo-couchbase-cluster-srv, *.demo-couchbase-cluster-srv.default.svc.cluster.local, host.demo-couchbase-cluster.default.svc.cluster.local, not host.demo
      

      We need to document the workaround, which is to regenerate the secrets using the values.yaml with the 2.1 chart

      ```
      helm template demo --values values.yaml couchbase/couchbase-operator > secretsdemo.yaml
      ```

      Then replace the secrets, after this we can then proceed to upgrade the Operator.

      Draft Documentation

      Manage. Helm. Helm Deployment

      Attachments

        Issue Links

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

          Activity

            tin.tran Tin Tran created issue -
            tin.tran Tin Tran made changes -
            Field Original Value New Value
            Description From the values.yaml for Helm we have the following:

              # TLS Certs that will be used to encrypt traffic between operator and couchbase
              tls:
                # enable to auto create certs
                generate: false
                # Expiry time of CA in days for generated certs
                expiration: 365


            We need to explain this bit better, when customer set this to true, the Operator will actually go through the process of creating the certs (https://docs.couchbase.com/operator/current/tutorial-tls.html#creating-a-client-certificate) and then create and config the secrets (https://docs.couchbase.com/operator/current/howto-tls.html) for the cluster.

            This causes an issue with upgrade as noted in https://issues.couchbase.com/browse/K8S-1900 because with Operator 2.1 requires an extra SAN

            ```
            DNS:host.${cluster}.${namespace}.svc.cluster.local
            ```

            Without this, when upgrading the Operator will report this error:


            {noformat}
            {"level":"error","ts":1611102051.5212724,"logger":"cluster","msg":"Reconciliation failed","cluster":"default/demo","error":"certificate cannot be verified for zone: x509: certificate is valid for localhost, *.demo-couchbase-cluster.default.svc, *.demo-couchbase-cluster.default, *.demo-couchbase-cluster, *.demo-couchbase-cluster-srv.default.svc, *.demo-couchbase-cluster-srv.default, *.demo-couchbase-cluster-srv, demo-couchbase-cluster-srv.default.svc, demo-couchbase-cluster-srv.default, demo-couchbase-cluster-srv, *.demo-couchbase-cluster-srv.default.svc.cluster.local, host.demo-couchbase-cluster.default.svc.cluster.local, not host.demo
            {noformat}


            We need to document the workaround, which is to regenerate the secrets using the values.yaml with the 2.1 chart

            ```
            helm template demo --values values.yaml couchbase/couchbase-operator > secretsdemo.yaml
            ```

            Then replace the secrets, after this we can then proceed to upgrade the Operator.
            From the values.yaml for Helm we have the following:

            {noformat}

              # TLS Certs that will be used to encrypt traffic between operator and couchbase
              tls:
                # enable to auto create certs
                generate: false
                # Expiry time of CA in days for generated certs
                expiration: 365

            {noformat}


            We need to explain this bit better, when customer set this to true, the Operator will actually go through the process of creating the certs (https://docs.couchbase.com/operator/current/tutorial-tls.html#creating-a-client-certificate) and then create and config the secrets (https://docs.couchbase.com/operator/current/howto-tls.html) for the cluster.

            This causes an issue with upgrade as noted in https://issues.couchbase.com/browse/K8S-1900 because with Operator 2.1 requires an extra SAN

            ```
            DNS:host.${cluster}.${namespace}.svc.cluster.local
            ```

            Without this, when upgrading the Operator will report this error:


            {noformat}
            {"level":"error","ts":1611102051.5212724,"logger":"cluster","msg":"Reconciliation failed","cluster":"default/demo","error":"certificate cannot be verified for zone: x509: certificate is valid for localhost, *.demo-couchbase-cluster.default.svc, *.demo-couchbase-cluster.default, *.demo-couchbase-cluster, *.demo-couchbase-cluster-srv.default.svc, *.demo-couchbase-cluster-srv.default, *.demo-couchbase-cluster-srv, demo-couchbase-cluster-srv.default.svc, demo-couchbase-cluster-srv.default, demo-couchbase-cluster-srv, *.demo-couchbase-cluster-srv.default.svc.cluster.local, host.demo-couchbase-cluster.default.svc.cluster.local, not host.demo
            {noformat}


            We need to document the workaround, which is to regenerate the secrets using the values.yaml with the 2.1 chart

            ```
            helm template demo --values values.yaml couchbase/couchbase-operator > secretsdemo.yaml
            ```

            Then replace the secrets, after this we can then proceed to upgrade the Operator.
            simon.murray Simon Murray made changes -
            Rank Ranked higher
            simon.murray Simon Murray made changes -
            Rank Ranked higher
            eric.schneider Eric Schneider (Inactive) made changes -
            Link This issue relates to K8S-2033 [ K8S-2033 ]
            eric.schneider Eric Schneider (Inactive) made changes -
            Component/s helm [ 15332 ]
            Assignee Simon Murray [ simon.murray ] Tommie McAfee [ tommie ]
            Labels candidate-for-cao-2.2
            eric.schneider Eric Schneider (Inactive) made changes -
            Fix Version/s 2.2.0 [ 17035 ]
            Labels candidate-for-cao-2.2
            simon.murray Simon Murray made changes -
            Rank Ranked higher
            ingenthr Matt Ingenthron made changes -
            Sprint 16: Documentation [ 1503 ]
            ingenthr Matt Ingenthron made changes -
            Rank Ranked higher
            ingenthr Matt Ingenthron made changes -
            Assignee Tommie McAfee [ tommie ] Patrick Stephens [ JIRAUSER25332 ]
            patrick.stephens Patrick Stephens (Inactive) made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            eric.schneider Eric Schneider (Inactive) made changes -
            Link This issue relates to K8S-1900 [ K8S-1900 ]
            patrick.stephens Patrick Stephens (Inactive) made changes -
            Resolution Fixed [ 1 ]
            Status In Progress [ 3 ] Resolved [ 5 ]
            eric.schneider Eric Schneider (Inactive) made changes -
            Assignee Patrick Stephens [ JIRAUSER25332 ] Arunkumar Senthilnathan [ arunkumar ]
            Description From the values.yaml for Helm we have the following:

            {noformat}

              # TLS Certs that will be used to encrypt traffic between operator and couchbase
              tls:
                # enable to auto create certs
                generate: false
                # Expiry time of CA in days for generated certs
                expiration: 365

            {noformat}


            We need to explain this bit better, when customer set this to true, the Operator will actually go through the process of creating the certs (https://docs.couchbase.com/operator/current/tutorial-tls.html#creating-a-client-certificate) and then create and config the secrets (https://docs.couchbase.com/operator/current/howto-tls.html) for the cluster.

            This causes an issue with upgrade as noted in https://issues.couchbase.com/browse/K8S-1900 because with Operator 2.1 requires an extra SAN

            ```
            DNS:host.${cluster}.${namespace}.svc.cluster.local
            ```

            Without this, when upgrading the Operator will report this error:


            {noformat}
            {"level":"error","ts":1611102051.5212724,"logger":"cluster","msg":"Reconciliation failed","cluster":"default/demo","error":"certificate cannot be verified for zone: x509: certificate is valid for localhost, *.demo-couchbase-cluster.default.svc, *.demo-couchbase-cluster.default, *.demo-couchbase-cluster, *.demo-couchbase-cluster-srv.default.svc, *.demo-couchbase-cluster-srv.default, *.demo-couchbase-cluster-srv, demo-couchbase-cluster-srv.default.svc, demo-couchbase-cluster-srv.default, demo-couchbase-cluster-srv, *.demo-couchbase-cluster-srv.default.svc.cluster.local, host.demo-couchbase-cluster.default.svc.cluster.local, not host.demo
            {noformat}


            We need to document the workaround, which is to regenerate the secrets using the values.yaml with the 2.1 chart

            ```
            helm template demo --values values.yaml couchbase/couchbase-operator > secretsdemo.yaml
            ```

            Then replace the secrets, after this we can then proceed to upgrade the Operator.
            From the values.yaml for Helm we have the following:
            {noformat} # TLS Certs that will be used to encrypt traffic between operator and couchbase
              tls:
                # enable to auto create certs
                generate: false
                # Expiry time of CA in days for generated certs
                expiration: 365

            {noformat}
            We need to explain this bit better, when customer set this to true, the Operator will actually go through the process of creating the certs ([https://docs.couchbase.com/operator/current/tutorial-tls.html#creating-a-client-certificate]) and then create and config the secrets ([https://docs.couchbase.com/operator/current/howto-tls.html]) for the cluster.

            This causes an issue with upgrade as noted in https://issues.couchbase.com/browse/K8S-1900 because with Operator 2.1 requires an extra SAN

            ```
             DNS:host.${cluster}.${namespace}.svc.cluster.local
             ```

            Without this, when upgrading the Operator will report this error:
            {noformat}{"level":"error","ts":1611102051.5212724,"logger":"cluster","msg":"Reconciliation failed","cluster":"default/demo","error":"certificate cannot be verified for zone: x509: certificate is valid for localhost, *.demo-couchbase-cluster.default.svc, *.demo-couchbase-cluster.default, *.demo-couchbase-cluster, *.demo-couchbase-cluster-srv.default.svc, *.demo-couchbase-cluster-srv.default, *.demo-couchbase-cluster-srv, demo-couchbase-cluster-srv.default.svc, demo-couchbase-cluster-srv.default, demo-couchbase-cluster-srv, *.demo-couchbase-cluster-srv.default.svc.cluster.local, host.demo-couchbase-cluster.default.svc.cluster.local, not host.demo
            {noformat}
            We need to document the workaround, which is to regenerate the secrets using the values.yaml with the 2.1 chart

            ```
             helm template demo --values values.yaml couchbase/couchbase-operator > secretsdemo.yaml
             ```

            Then replace the secrets, after this we can then proceed to upgrade the Operator.
            h1. Draft Documentation

            [*Manage. Helm.* *_Helm Deployment_*|https://docs-staging.couchbase.com/operator/current/helm-setup-guide.html]
             * Added [Auto-Generated Certificates|https://docs-staging.couchbase.com/operator/current/helm-setup-guide.html#auto-generated-certificates] section that describes the workaround in K8S-1900 / K8S-1955.
            eric.schneider Eric Schneider (Inactive) made changes -
            Remote Link This issue links to "Page (Couchbase, Inc. Wiki)" [ 22103 ]
            arunkumar Arunkumar Senthilnathan made changes -
            Status Resolved [ 5 ] Closed [ 6 ]
            lynn.straus Lynn Straus made changes -
            Remote Link This issue links to "Page (Couchbase, Inc. Wiki)" [ 22706 ]
            lynn.straus Lynn Straus made changes -
            Remote Link This issue links to "Page (Couchbase, Inc. Wiki)" [ 22103 ]

            People

              arunkumar Arunkumar Senthilnathan
              tin.tran Tin Tran
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes

                  PagerDuty