Mongodb no Kubernetes Timeouts ao inserir uma grande quantidade de dados

Question

Temos uma API em execução que recebe uma vez por dia vários lotes de dados grandes que são inseridos em um mongodb. Usamos o cvallance/mongo-k8s-sidecar para a configuração do conjunto de replicação

Isso funciona perfeitamente em uma mongodatabase local.

também não há tráfego de produção no banco de dados que possa aumentar as condições de aumento ou mais.

Agora o implantamos em um mecanismo de contêiner do Google. Lá a importação funciona em geral também. Mas, de vez em quando, temos momentos como esse:

Cannot run replSetReconfig because the node is currently updating its configuration

ou

MongoDB.Driver.MongoCommandException: Command insert failed: BSONObj size: 16793637 (0x1004025) is invalid. Size must be between 0 and 16793600(16MB) First element: insert: "LandingPageConnectionSet_Stage".

ou

Error in workloop { MongoError: connection 0 to 127.0.0.1:27017 timed out at Function.MongoError.create (/opt/cvallance/mongo-k8s-sidecar/node_modules/mongodb-core/lib/error.js:29:11) at Socket. (/opt/cvallance/mongo-k8s-sidecar/node_modules/mongodb-core/lib/connection/connection.js:198:20) at Object.onceWrapper (events.js:254:19) at Socket.emit (events.js:159:13) at Socket._onTimeout (net.js:411:8) at ontimeout (timers.js:478:11) at tryOnTimeout (timers.js:302:5) at Timer.listOnTimeout (timers.js:262:5)

Eu posso ver que a CPU parece não estar em seus limites.

Configuração do Kubernetes para o mongodb

---
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: fast
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssd
---
apiVersion: v1
kind: Service
metadata:
  name: mongo
  labels:
    name: mongo
spec:
  ports:
  - port: 27017
    targetPort: 27017
  clusterIP: None
  selector:
    role: mongo
---
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: mongo
spec:
  serviceName: "mongo"
  replicas: 3
  template:
    metadata:
      labels:
        role: mongo
        environment: test
    spec:
      terminationGracePeriodSeconds: 10
      containers:
        - name: mongo
          image: mongo:3.6
          command:
            - mongod
            - "--replSet"
            - rs0
            - "--bind_ip"
            - 0.0.0.0
            - "--smallfiles"
            - "--noprealloc"
          ports:
            - containerPort: 27017
          volumeMounts:
            - name: mongo-persistent-storage
              mountPath: /data/db
        - name: mongo-sidecar
          image: cvallance/mongo-k8s-sidecar
          env:
            - name: MONGO_SIDECAR_POD_LABELS
              value: "role=mongo,environment=test"
  volumeClaimTemplates:
  - metadata:
      name: mongo-persistent-storage
      annotations:
        volume.beta.kubernetes.io/storage-class: "fast"
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 32Gi

nós também pouco mudamos a configuração limitando o cachesize do wiretiger e removendo as opções do smallfile para que a parte na configuração fosse assim:

   - mongod
    - "--replSet"
    - rs0
    - "--bind_ip"
    - 0.0.0.0
    - "--noprealloc"
    - "--wiredTigerCacheSizeGB"
    - "1.5"

    

Answer 1

I checked the logs and the kubernetes Dashboard with Boas Enkler.

No painel do Kubernetes em relação ao status dos PODs, havia as seguintes dicas:

Pod Name: kube-lego-*****-***     
Status: Evicted 
Reason: The node was low on resource: memory.

Você poderia ter recuperado as mesmas informações por meio de kubectl describe pod [podname]

Observe que citando a documentação : "Se o kubelet não conseguir recuperar recursos suficientes no nó, o kubelet começa a remover os Pods. "

Portanto, eu acreditava que o erro com o Mongodb, uma vez que estava trabalhando no local sem qualquer problema, para verificar novamente, nós passamos pelos logs do Kernel mostrados pela saída serial do console e encontramos:

Memory cgroup out of memory: Kill process 4**7 (mongod) score 1494 or sacrifice child
...
Memory cgroup out of memory: Kill process 1**8 (mongod) score 1538 or sacrifice child

Notamos também que não havia campo de solicitação de memória no arquivo YAML da implantação. Isso é um problema, pois pode acontecer que, mesmo que haja três nós sem carga de trabalho, todos os PODs sejam iniciados no mesmo nó, já que teoricamente se encaixam.

Para atenuar esse comportamento, há algumas soluções possíveis:

• Dimensione verticalmente o cluster e introduza valores de solicitação de memória

• Instrua o processo do mongodb consumir uma quantidade de memória menor que a Solicitada.

• A introdução do limite de memória é essencial se você tiver mais contêiner em execução no mesmo nó e quiser evitar que eles sejam mortos por ele. Considere que desta forma ele será morto algumas vezes, mesmo que ainda haja memória disponível no nó.