K8s-config-connector: Upgrade to operator stuck at pod terminating

Created on 10 Nov 2020 · 6Comments · Source: GoogleCloudPlatform/k8s-config-connector

Describe the bug

I upgraded from 1.27.2 manifest install to 1.29.0 operator install by:

install 1.29.0 operator
add a configconnector instance

apiVersion: core.cnrm.cloud.google.com/v1beta1
kind: ConfigConnector
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"core.cnrm.cloud.google.com/v1beta1","kind":"ConfigConnector","metadata":{"annotations":{},"name":"configconnector.core.cnrm.cloud.google.com"},"spec":{"googleServiceAccount":"[email protected]","mode":"cluster"}}
  creationTimestamp: "2020-11-09T14:37:13Z"
  finalizers:
  - configconnector.cnrm.cloud.google.com/finalizer
  generation: 3
  managedFields:
  - apiVersion: core.cnrm.cloud.google.com/v1beta1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          .: {}
          f:kubectl.kubernetes.io/last-applied-configuration: {}
      f:spec:
        .: {}
        f:googleServiceAccount: {}
        f:mode: {}
    manager: kubectl-client-side-apply
    operation: Update
    time: "2020-11-09T14:37:13Z"
  - apiVersion: core.cnrm.cloud.google.com/v1beta1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:finalizers:
          .: {}
          v:"configconnector.cnrm.cloud.google.com/finalizer": {}
      f:status:
        .: {}
        f:healthy: {}
    manager: manager
    operation: Update
    time: "2020-11-09T14:37:40Z"
  name: configconnector.core.cnrm.cloud.google.com
  resourceVersion: "122683995"
  selfLink: /apis/core.cnrm.cloud.google.com/v1beta1/configconnectors/configconnector.core.cnrm.cloud.google.com
  uid: 33e156e7-1e14-4edc-9d56-ec3f4c5f898c
spec:
  googleServiceAccount: [email protected]
  mode: cluster
status:
  healthy: true

However, after installing operator and the config connector instance, I noticed my old config connector pods are stuck in terminating state. Therefore, the new instance isn't working properly though it's said to be healthy.

$ kubectl get pod
NAME                                            READY   STATUS        RESTARTS   AGE
cnrm-controller-manager-0                       0/1     Running       0          5d13h
cnrm-deletiondefender-0                         0/1     Terminating   0          11d
cnrm-resource-stats-recorder-69479b975b-2gh9v   0/1     Terminating   0          5d13h
cnrm-resource-stats-recorder-69479b975b-t4v6t   0/1     Terminating   0          3d2h
cnrm-resource-stats-recorder-796c45bbfc-d9mwr   2/2     Running       0          11h
cnrm-webhook-manager-5878784cb6-bvlcc           1/1     Running       0          11h
cnrm-webhook-manager-5878784cb6-ng5c6           1/1     Running       0          11h
cnrm-webhook-manager-b5545fcb5-7xtfm            0/1     Terminating   0          11d
cnrm-webhook-manager-b5545fcb5-brwnd            0/1     Terminating   0          11d
cnrm-webhook-manager-b5545fcb5-mh6zn            0/1     Terminating   0          3d2h
$ kubectl get pod cnrm-resource-stats-recorder-69479b975b-2gh9v -o yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    cnrm.cloud.google.com/version: 1.27.2
  creationTimestamp: "2020-11-04T12:47:58Z"
  deletionGracePeriodSeconds: 10
  deletionTimestamp: "2020-11-07T00:20:17Z"
  generateName: cnrm-resource-stats-recorder-69479b975b-
  labels:
    cnrm.cloud.google.com/component: cnrm-resource-stats-recorder
    cnrm.cloud.google.com/system: "true"
    pod-template-hash: 69479b975b
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          .: {}
          f:cnrm.cloud.google.com/version: {}
        f:generateName: {}
        f:labels:
          .: {}
          f:cnrm.cloud.google.com/component: {}
          f:cnrm.cloud.google.com/system: {}
          f:pod-template-hash: {}
        f:ownerReferences:
          .: {}
          k:{"uid":"c714d5cb-4f2a-4ccf-8d6e-bc4a7504c581"}:
            .: {}
            f:apiVersion: {}
            f:blockOwnerDeletion: {}
            f:controller: {}
            f:kind: {}
            f:name: {}
            f:uid: {}
      f:spec:
        f:containers:
          k:{"name":"recorder"}:
            .: {}
            f:args: {}
            f:command: {}
            f:env:
              .: {}
              k:{"name":"CONFIG_CONNECTOR_VERSION"}:
                .: {}
                f:name: {}
                f:value: {}
            f:image: {}
            f:imagePullPolicy: {}
            f:name: {}
            f:readinessProbe:
              .: {}
              f:exec:
                .: {}
                f:command: {}
              f:failureThreshold: {}
              f:initialDelaySeconds: {}
              f:periodSeconds: {}
              f:successThreshold: {}
              f:timeoutSeconds: {}
            f:resources:
              .: {}
              f:limits:
                .: {}
                f:cpu: {}
                f:memory: {}
              f:requests:
                .: {}
                f:cpu: {}
                f:memory: {}
            f:securityContext:
              .: {}
              f:privileged: {}
              f:runAsNonRoot: {}
              f:runAsUser: {}
            f:terminationMessagePath: {}
            f:terminationMessagePolicy: {}
        f:dnsPolicy: {}
        f:enableServiceLinks: {}
        f:restartPolicy: {}
        f:schedulerName: {}
        f:securityContext: {}
        f:serviceAccount: {}
        f:serviceAccountName: {}
        f:terminationGracePeriodSeconds: {}
      f:status:
        f:conditions:
          k:{"type":"Ready"}:
            f:lastTransitionTime: {}
            f:status: {}
    manager: kube-controller-manager
    operation: Update
    time: "2020-11-07T00:15:02Z"
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:status:
        f:conditions:
          k:{"type":"ContainersReady"}:
            .: {}
            f:lastProbeTime: {}
            f:lastTransitionTime: {}
            f:message: {}
            f:reason: {}
            f:status: {}
            f:type: {}
          k:{"type":"Initialized"}:
            .: {}
            f:lastProbeTime: {}
            f:lastTransitionTime: {}
            f:status: {}
            f:type: {}
          k:{"type":"Ready"}:
            .: {}
            f:lastProbeTime: {}
            f:message: {}
            f:reason: {}
            f:type: {}
        f:containerStatuses: {}
        f:hostIP: {}
        f:phase: {}
        f:podIP: {}
        f:podIPs:
          .: {}
          k:{"ip":"10.20.0.12"}:
            .: {}
            f:ip: {}
        f:startTime: {}
    manager: kubelet
    operation: Update
    time: "2020-11-07T00:27:41Z"
  name: cnrm-resource-stats-recorder-69479b975b-2gh9v
  namespace: cnrm-system
  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: ReplicaSet
    name: cnrm-resource-stats-recorder-69479b975b
    uid: c714d5cb-4f2a-4ccf-8d6e-bc4a7504c581
  resourceVersion: "121196415"
  selfLink: /api/v1/namespaces/cnrm-system/pods/cnrm-resource-stats-recorder-69479b975b-2gh9v
  uid: db83b400-efca-42bf-aa25-d89ca2ca8d86
spec:
  containers:
  - args:
    - --prometheus-scrape-endpoint=:8888
    - --metric-interval=60
    command:
    - /configconnector/recorder
    env:
    - name: CONFIG_CONNECTOR_VERSION
      value: 1.27.2
    image: gcr.io/cnrm-eap/recorder:1c8c589
    imagePullPolicy: Always
    name: recorder
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/ready
      failureThreshold: 3
      initialDelaySeconds: 3
      periodSeconds: 3
      successThreshold: 1
      timeoutSeconds: 1
    resources:
      limits:
        cpu: 40m
        memory: 64Mi
      requests:
        cpu: 20m
        memory: 32Mi
    securityContext:
      privileged: false
      runAsNonRoot: true
      runAsUser: 1000
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: cnrm-resource-stats-recorder-token-l6c2d
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  nodeName: gke-kf-ci-management-kf-ci-management-734f804a-z4eu
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: cnrm-resource-stats-recorder
  serviceAccountName: cnrm-resource-stats-recorder
  terminationGracePeriodSeconds: 10
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - name: cnrm-resource-stats-recorder-token-l6c2d
    secret:
      defaultMode: 420
      secretName: cnrm-resource-stats-recorder-token-l6c2d
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2020-11-04T12:47:58Z"
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: "2020-11-07T00:15:02Z"
    message: 'containers with unready status: [recorder]'
    reason: ContainersNotReady
    status: "False"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: "2020-11-07T00:27:30Z"
    message: 'containers with unready status: [recorder]'
    reason: ContainersNotReady
    status: "False"
    type: ContainersReady
  - lastProbeTime: null
    lastTransitionTime: "2020-11-04T12:47:58Z"
    status: "True"
    type: PodScheduled
  containerStatuses:
  - containerID: docker://fe7dcae8202e96847904d7cb4b8f670e566058fdd6c4373cafcc626b366d47cd
    image: gcr.io/cnrm-eap/recorder:1c8c589
    imageID: docker-pullable://gcr.io/cnrm-eap/recorder@sha256:418404e798de7d8917e6b9b40c9cc0a2a2d2c9123435732d806e192e34b6b340
    lastState: {}
    name: recorder
    ready: false
    restartCount: 0
    started: true
    state:
      running:
        startedAt: "2020-11-04T12:48:06Z"
  hostIP: 10.128.0.47
  phase: Running
  podIP: 10.20.0.12
  podIPs:
  - ip: 10.20.0.12
  qosClass: Burstable
  startTime: "2020-11-04T12:47:58Z"

ConfigConnector Version
Run the following command to get the current ConfigConnector version

kubectl get ns cnrm-system -o jsonpath='{.metadata.annotations.cnrm\.cloud\.google\.com/version}'

1.27.2 to 1.29.0

To Reproduce
Steps to reproduce the behavior:

YAML snippets:

apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
kind: PubSubTopic
metadata:
  labels:
    label-one: "value-one"
  name: pubsubtopic-sample

bug

Source

Bobgy

Most helpful comment

Discussed internally. Thanks @Bobgy for working with us on this issue!

For posterity:

The safest way to migrate from a manual installation of KCC to an operator-based one is to uninstall and reinstall KCC.

However, if you want to retain the KCC resources in your cluster, you could try removing all KCC system components except the CRDs, and then install the operator.

You can remove all KCC system components other than the CRDs by running the following commands:

kubectl delete sts,deploy,po,svc,roles,clusterroles,clusterrolebindings --all-namespaces -l cnrm.cloud.google.com/system=true --wait=true
kubectl delete validatingwebhookconfiguration abandon-on-uninstall.cnrm.cloud.google.com --ignore-not-found --wait=true
kubectl delete validatingwebhookconfiguration validating-webhook.cnrm.cloud.google.com --ignore-not-found --wait=true
kubectl delete mutatingwebhookconfiguration mutating-webhook.cnrm.cloud.google.com --ignore-not-found --wait=true

These instructions are from our old upgade docs for manual installations that have unfortunately been removed when we overhauled our installation docs to be operator-centric. We'll look into resurrecting them back as migration instructions in the future when we get the chance.

@Bobgy assuming you're also no longer facing any stuck-at-Terminating and OOMKilled issues, I'll go ahead and close this issue. Feel free to re-open if you are facing any other issues.

jcanseco on 13 Nov 2020

👍2

All 6 comments

Is there any documentation for upgrading from pre-operator installation to operator installation?

Bobgy on 10 Nov 2020

I tried
kubectl delete pod --force <pods-stuck-at-terminating>

Then, most new workloads start up properly, however I'm seeing https://github.com/GoogleCloudPlatform/k8s-config-connector/issues/282 and the KCC installation still does not function.

Bobgy on 10 Nov 2020

I tried the following things to recover my config connector instance, and finally fixed by KCC installation.

I deleted the configconnector instance
I removed finalizer on configconnector instance, because it was still stuck.

configconnector instance successfully deleted

apply configconnector instance again

initiating the new instance stucks on cnrm-system namespace terminating (just found out at 3. the namespace hasn't terminated)

I kubectl delete pod --force for all stucked pods in cnrm-system

cnrm-system namespace successfully terminated

configconnector coming up healthy, but still not reconciling successfully

I found some iam permission issues and fixed them

configconnector coming back live again

Bobgy on 10 Nov 2020

Hi @Bobgy, I am glad to hear you seem to have resolved your issue. Can you confirm that your configconnector-operator-0 pod is no longer being OOMKilled?

jcanseco on 10 Nov 2020

@jcanseco, ohh sorry, I meant to say cnrm-deletiondefender-0 was OOMKilled in crash loop.
The operator was always working well with me.

Today: all seems to be working, but the pods stuck at terminating issue persists.

$ k get pod -n cnrm-system
NAME READY STATUS RESTARTS AGE
cnrm-controller-manager-0 2/2 Running 0 26h
cnrm-deletiondefender-0 1/1 Running 0 26h
cnrm-resource-stats-recorder-796c45bbfc-s9f9h 2/2 Running 0 26h
cnrm-webhook-manager-5878784cb6-6dm27 1/1 Running 0 26h
cnrm-webhook-manager-5878784cb6-7npd5 0/1 Terminating 0 26h
cnrm-webhook-manager-5878784cb6-cs7s7 0/1 Terminating 0 26h
cnrm-webhook-manager-5878784cb6-dzgrh 0/1 Terminating 0 26h
cnrm-webhook-manager-5878784cb6-hnnmq 0/1 Terminating 0 26h
cnrm-webhook-manager-5878784cb6-s7q58 0/1 Terminating 0 26h
cnrm-webhook-manager-5878784cb6-tmbqb 1/1 Running 0 26h
cnrm-webhook-manager-5878784cb6-xhlh7 0/1 Terminating 0 26h
cnrm-webhook-manager-5878784cb6-zpgln 0/1 Terminating 0 26h

Is there any further information I can provide to help troubleshoot the problem?

Bobgy on 11 Nov 2020

Discussed internally. Thanks @Bobgy for working with us on this issue!

For posterity:

The safest way to migrate from a manual installation of KCC to an operator-based one is to uninstall and reinstall KCC.

However, if you want to retain the KCC resources in your cluster, you could try removing all KCC system components except the CRDs, and then install the operator.

You can remove all KCC system components other than the CRDs by running the following commands:

kubectl delete sts,deploy,po,svc,roles,clusterroles,clusterrolebindings --all-namespaces -l cnrm.cloud.google.com/system=true --wait=true kubectl delete validatingwebhookconfiguration abandon-on-uninstall.cnrm.cloud.google.com --ignore-not-found --wait=true kubectl delete validatingwebhookconfiguration validating-webhook.cnrm.cloud.google.com --ignore-not-found --wait=true kubectl delete mutatingwebhookconfiguration mutating-webhook.cnrm.cloud.google.com --ignore-not-found --wait=true

These instructions are from our old upgade docs for manual installations that have unfortunately been removed when we overhauled our installation docs to be operator-centric. We'll look into resurrecting them back as migration instructions in the future when we get the chance.

@Bobgy assuming you're also no longer facing any stuck-at-Terminating and OOMKilled issues, I'll go ahead and close this issue. Feel free to re-open if you are facing any other issues.

jcanseco on 13 Nov 2020

👍2

Was this page helpful?

0 / 5 - 0 ratings

Related issues

Error to create service account that has been recently deleted

jonnylangefeld · 4Comments

configconnector-operator-0 keeps getting OOMKilled, Error during reconciliation: error applying manifest: error from running kubectl apply: signal: killed

mrsimo · 6Comments

Can not refer to managed cert in ComputeSSLCertificate

jlpettersson · 6Comments

validating webhook annotation-defaulter timeout

RoryShively · 4Comments

[Lack of idempotency] ComputeInstance zero-delta updates returns: Cannot make changes on immutable fields: [networkInterface]

tonybenchsci · 6Comments