
mongodb에 삽입되는 대규모 데이터의 여러 배치를 하루에 한 번 수신하는 API가 실행 중입니다. 우리는 cvallance/mongo-k8s-sidecar
복제 세트 구성에 사용합니다 .
이것은 로컬 mongodatabase에서 완벽하게 작동합니다.
또한 데이터베이스에는 상황을 올릴 수 있는 프로덕션 트래픽이 없습니다.
이제 Google 컨테이너 엔진에 배포했습니다. 일반적으로 가져오기도 작동합니다. 그러나 때때로 다음과 같은 시간 초과 예외가 발생했습니다.
노드가 현재 구성을 업데이트 중이므로 replSetReconfig를 실행할 수 없습니다.
또는
MongoDB.Driver.MongoCommandException: 명령 삽입 실패: BSONObj 크기: 16793637(0x1004025)이 잘못되었습니다. 크기는 0에서 16793600(16MB) 사이여야 합니다. 첫 번째 요소: 삽입: "LandingPageConnectionSet_Stage".
또는
작업 루프 오류 { MongoError: Function.MongoError.create(/opt/cvallance/mongo-k8s-sidecar/node_modules/mongodb-core/lib/error.js:29:11)에서 0~127.0.0.1:27017 연결 시간이 초과되었습니다. 소켓에서. (/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)
CPU가 한계에 도달하지 않은 것 같습니다.
mongodb용 Kubernetes 구성
---
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
또한 wiretiger 캐시 크기를 제한하고 smallfiles 옵션을 제거하여 구성을 거의 변경하지 않았으므로 구성의 일부는 다음과 같습니다.
- mongod
- "--replSet"
- rs0
- "--bind_ip"
- 0.0.0.0
- "--noprealloc"
- "--wiredTigerCacheSizeGB"
- "1.5"
답변1
Boas Enkler와 함께 로그와 kubernetes 대시보드를 확인했습니다.
POD 상태에 관한 Kubernetes 대시보드에는 다음과 같은 힌트가 있습니다.
Pod Name: kube-lego-*****-***
Status: Evicted
Reason: The node was low on resource: memory.
다음을 통해 동일한 정보를 검색할 수 있었습니다.kubectl describe pod [podname]
를 인용한다는 점에 유의하세요.선적 서류 비치: "kubelet이 노드에서 충분한 리소스를 회수할 수 없는 경우 kubelet은 포드 제거를 시작합니다."
따라서 Mongodb가 아무런 문제 없이 전제에서 작동했기 때문에 오류가 발생했다고 믿었습니다. 다시 확인하기 위해 콘솔 직렬 출력에 표시된 커널 로그를 살펴보고 다음을 발견했습니다.
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
또한 배포의 YAML 파일에 메모리 요청 필드가 없다는 것도 확인했습니다. 이는 워크로드가 없는 3개의 노드가 있더라도 이론적으로 적합하기 때문에 모든 POD가 동일한 노드에서 시작되는 일이 발생할 수 있기 때문에 문제가 됩니다.
이 동작을 완화하기 위해 몇 가지 가능한 해결 방법이 있습니다.
클러스터를 수직으로 확장하고 메모리 요청 값을 도입합니다.
지시하다mongodb 프로세스는 요청한 것보다 적은 양의 메모리를 소비합니다.
동일한 노드에서 더 많은 컨테이너를 실행하고 이로 인해 해당 컨테이너가 종료되는 것을 방지하려면 메모리 제한을 도입하는 것이 필수적입니다. 이런 방식으로 노드에 아직 사용 가능한 메모리가 있어도 가끔 종료된다는 점을 고려하세요.