🔵 🛕 👩🏿‍🔬 कुबेरनेट्स [और उनके समाधान] के संचालन में 6 मनोरंजक प्रणाली कीड़े 🧝🏾 🏇 ✅

उत्पादन में कुबेरनेट्स के संचालन के वर्षों में, हमने कई दिलचस्प कहानियों को संचित किया है, क्योंकि विभिन्न सिस्टम घटकों में कीड़े से अप्रिय और / या असंगत परिणाम होते हैं जो कंटेनरों और फली के संचालन को प्रभावित करते हैं। इस लेख में, हमने कुछ सबसे अक्सर या दिलचस्प लोगों का चयन किया है। यहां तक कि अगर आप ऐसी परिस्थितियों का सामना करने के लिए पर्याप्त भाग्यशाली नहीं हैं, तो ऐसे संक्षिप्त जासूसों के बारे में पढ़ना - सभी अधिक, पहले-हाथ - हमेशा मनोरंजक है, है ना?

इतिहास 1. सुपर क्रोनिक और ठंड डॉकर

क्लस्टर में से एक पर, हमें समय-समय पर एक "जमे हुए" डॉकर मिले, जो क्लस्टर के सामान्य कामकाज में हस्तक्षेप करता था। इसी समय, डॉकर लॉग में निम्नलिखित देखा गया

level=error msg="containerd: start init process" error="exit status 2: \"runtime/cgo: pthread_create failed: No space left on device SIGABRT: abort PC=0x7f31b811a428 m=0 goroutine 0 [idle]: goroutine 1 [running]: runtime.systemstack_switch() /usr/local/go/src/runtime/asm_amd64.s:252 fp=0xc420026768 sp=0xc420026760 runtime.main() /usr/local/go/src/runtime/proc.go:127 +0x6c fp=0xc4200267c0 sp=0xc420026768 runtime.goexit() /usr/local/go/src/runtime/asm_amd64.s:2086 +0x1 fp=0xc4200267c8 sp=0xc4200267c0 goroutine 17 [syscall, locked to thread]: runtime.goexit() /usr/local/go/src/runtime/asm_amd64.s:2086 +0x1 …

इस त्रुटि में, हम संदेश में सबसे अधिक रुचि रखते हैं: pthread_create failed: No space left on device । प्रलेखन के एक त्वरित अध्ययन ने समझाया कि डॉकर प्रक्रिया को कांटा नहीं कर सकता है, जिससे यह समय-समय पर "फ्रीज" हो जाता है।

मॉनिटरिंग में क्या हो रहा है, निम्न चित्र मेल खाती है:

इसी तरह की स्थिति अन्य नोड्स पर देखी जाती है:

उसी नोड्स पर हम देखते हैं:

 root@kube-node-1 ~ # ps auxfww | grep curl -c 19782 root@kube-node-1 ~ # ps auxfww | grep curl | head root 16688 0.0 0.0 0 0 ? Z Feb06 0:00 | \_ [curl] <defunct> root 17398 0.0 0.0 0 0 ? Z Feb06 0:00 | \_ [curl] <defunct> root 16852 0.0 0.0 0 0 ? Z Feb06 0:00 | \_ [curl] <defunct> root 9473 0.0 0.0 0 0 ? Z Feb06 0:00 | \_ [curl] <defunct> root 4664 0.0 0.0 0 0 ? Z Feb06 0:00 | \_ [curl] <defunct> root 30571 0.0 0.0 0 0 ? Z Feb06 0:00 | \_ [curl] <defunct> root 24113 0.0 0.0 0 0 ? Z Feb06 0:00 | \_ [curl] <defunct> root 16475 0.0 0.0 0 0 ? Z Feb06 0:00 | \_ [curl] <defunct> root 7176 0.0 0.0 0 0 ? Z Feb06 0:00 | \_ [curl] <defunct> root 1090 0.0 0.0 0 0 ? Z Feb06 0:00 | \_ [curl] <defunct>

यह पता चला कि यह व्यवहार सुपर क्रॉनिक के साथ पॉड के काम का एक परिणाम है (गो पर उपयोगिता जो हम पॉड्स में क्रोन कार्यों को चलाने के लिए उपयोग करते हैं):

  \_ docker-containerd-shim 833b60bb9ff4c669bb413b898a5fd142a57a21695e5dc42684235df907825567 /var/run/docker/libcontainerd/833b60bb9ff4c669bb413b898a5fd142a57a21695e5dc42684235df907825567 docker-runc | \_ /usr/local/bin/supercronic -json /crontabs/cron | \_ /usr/bin/newrelic-daemon --agent --pidfile /var/run/newrelic-daemon.pid --logfile /dev/stderr --port /run/newrelic.sock --tls --define utilization.detect_aws=true --define utilization.detect_azure=true --define utilization.detect_gcp=true --define utilization.detect_pcf=true --define utilization.detect_docker=true | | \_ /usr/bin/newrelic-daemon --agent --pidfile /var/run/newrelic-daemon.pid --logfile /dev/stderr --port /run/newrelic.sock --tls --define utilization.detect_aws=true --define utilization.detect_azure=true --define utilization.detect_gcp=true --define utilization.detect_pcf=true --define utilization.detect_docker=true -no-pidfile | \_ [newrelic-daemon] <defunct> | \_ [curl] <defunct> | \_ [curl] <defunct> | \_ [curl] <defunct> … / var / रन / डोकर / libcontainerd / 833b60bb9ff4c669bb413b898a5fd142a57a21695e5dc42684235df907825567 डोकर-runc  \_ docker-containerd-shim 833b60bb9ff4c669bb413b898a5fd142a57a21695e5dc42684235df907825567 /var/run/docker/libcontainerd/833b60bb9ff4c669bb413b898a5fd142a57a21695e5dc42684235df907825567 docker-runc | \_ /usr/local/bin/supercronic -json /crontabs/cron | \_ /usr/bin/newrelic-daemon --agent --pidfile /var/run/newrelic-daemon.pid --logfile /dev/stderr --port /run/newrelic.sock --tls --define utilization.detect_aws=true --define utilization.detect_azure=true --define utilization.detect_gcp=true --define utilization.detect_pcf=true --define utilization.detect_docker=true | | \_ /usr/bin/newrelic-daemon --agent --pidfile /var/run/newrelic-daemon.pid --logfile /dev/stderr --port /run/newrelic.sock --tls --define utilization.detect_aws=true --define utilization.detect_azure=true --define utilization.detect_gcp=true --define utilization.detect_pcf=true --define utilization.detect_docker=true -no-pidfile | \_ [newrelic-daemon] <defunct> | \_ [curl] <defunct> | \_ [curl] <defunct> | \_ [curl] <defunct> …

समस्या यह है: जब कोई कार्य सुपर क्रोनिक में शुरू होता है, तो इसके द्वारा उत्पन्न प्रक्रिया सही ढंग से समाप्त नहीं हो सकती है , एक ज़ोंबी में बदल जाती है।

नोट : अधिक सटीक होने के लिए, क्रोन-कार्यों द्वारा प्रक्रियाएं उत्पन्न की जाती हैं, हालांकि, सुपरक्रोनिक एक init-system नहीं है और उन प्रक्रियाओं को "नहीं" अपना सकता है जो उसके बच्चों ने पैदा की। जब SIGHUP या SIGTERM सिग्नल होते हैं, तो वे स्पान्ड प्रक्रियाओं को प्रेषित नहीं होते हैं, जिसके परिणामस्वरूप बच्चे की प्रक्रिया समाप्त नहीं होती है, ज़ोंबी स्थिति में शेष रहती है। आप इस सब के बारे में अधिक पढ़ सकते हैं, उदाहरण के लिए, ऐसे लेख में ।

समस्याओं को हल करने के कुछ तरीके हैं:

अस्थायी वर्कअराउंड के रूप में - एक समय में सिस्टम में PID की संख्या बढ़ाएँ:

  /proc/sys/kernel/pid_max (since Linux 2.5.34) This file specifies the value at which PIDs wrap around (ie, the value in this file is one greater than the maximum PID). PIDs greater than this value are not allo‐ cated; thus, the value in this file also acts as a system-wide limit on the total number of processes and threads. The default value for this file, 32768, results in the same range of PIDs as on earlier kernels

या, सुपरक्रॉनिक में कार्यों का शुभारंभ सीधे नहीं, बल्कि उसी टिनी की मदद से करें, जो प्रक्रियाओं को सही ढंग से पूरा करने में सक्षम है और एक ज़ोंबी उत्पन्न नहीं करता है।

इतिहास 2. "लाश" जब cgroup को हटा रहा है

क्यूबलेट ने सीपीयू की बहुत अधिक खपत शुरू कर दी:

किसी को यह पसंद नहीं है, इसलिए हमने खुद को पूर्णता के साथ सशस्त्र किया और समस्या से निपटना शुरू किया। जांच के परिणाम इस प्रकार थे:

क्यूबलेट एक तिहाई से अधिक सीपीयू समय बिताता है जो सभी डेटा समूहों से मेमोरी डेटा खींचता है:
कर्नेल डेवलपर्स मेलिंग सूची में आप समस्या की चर्चा पा सकते हैं। संक्षेप में, लब्बोलुआब यह है कि अलग-अलग tmpfs फाइलें और अन्य समान चीजें सिस्टम से पूरी तरह से नहीं हटाई जाती हैं जब cgroup हटा दिया जाता है - तथाकथित मेम ज़ोंबी । जल्दी या बाद में, वे अभी भी पेज कैश से हटा दिए जाएंगे, लेकिन सर्वर पर मेमोरी बहुत अधिक है और कर्नेल समय बर्बाद करने की बात नहीं देखता है। इसलिए, वे जमा करना जारी रखते हैं। ऐसा क्यों हो रहा है? यह क्रोन नौकरियों वाला एक सर्वर है जो लगातार नई नौकरियों का निर्माण करता है, और उनके साथ नई पॉड्स। इस प्रकार, उन में कंटेनरों के लिए नए cgroups बनाए जाते हैं, जिन्हें जल्द ही हटा दिया जाएगा।
क्यूबलेट में cAdvisor इतना समय क्यों देता है? यह आसानी से time cat /sys/fs/cgroup/memory/memory.stat के सरलतम निष्पादन द्वारा देखा जाता है। यदि ऑपरेशन एक स्वस्थ मशीन पर 0.01 सेकंड लेता है, तो समस्याग्रस्त cron02 पर 1.2 सेकंड। बात यह है कि cAdvisor, जो sysfs के डेटा को बहुत धीरे-धीरे पढ़ता है, साथ ही ज़ोंबी cgroups में प्रयुक्त मेमोरी को ध्यान में रखने की कोशिश करता है।
लाश को जबरदस्ती हटाने के लिए, हमने कैश को साफ करने की कोशिश की, जैसा कि एलकेएमएल में सिफारिश की गई थी: sync; echo 3 > /proc/sys/vm/drop_caches sync; echo 3 > /proc/sys/vm/drop_caches , लेकिन कर्नेल अधिक जटिल निकला और मशीन को लटका दिया।

क्या करें? 4.11 संस्करण के लिए लिनक्स कर्नेल को अद्यतन करके समस्या को ठीक किया गया है ( कमिट और विवरण देखें)।

इतिहास 3. सिस्टमड और उसका आरोह

फिर से, क्यूबलेट कुछ नोड्स पर बहुत अधिक संसाधनों की खपत करता है, लेकिन इस बार यह पहले से ही स्मृति है:

यह पता चला कि उबंटू 16.04 में उपयोग subPath जाने वाले सिस्टमड में एक समस्या है, और यह तब होता है जब subPath को कॉन्फिगरैप्स या रहस्यों से जोड़ने के लिए बनाई गई माउंट को नियंत्रित करता है। फली पूरी होने के बाद, सिस्टमड सर्विस और इसकी सर्विस माउंट सिस्टम पर बनी रहती है। समय के साथ, वे एक बड़ी राशि जमा करते हैं। इस विषय पर और भी मुद्दे हैं:

... जिनमें से अंतिम में PR को systemd: # 7811 (systemd में अंक # 7798 ) बताया गया है।

समस्या अब उबंटू 18.04 में नहीं है, लेकिन यदि आप उबंटू 16.04 का उपयोग करना जारी रखना चाहते हैं, तो इस विषय पर हमारा काम आसान हो सकता है।

तो, हमने निम्नलिखित DaemonSet बनाया:

 --- apiVersion: extensions/v1beta1 kind: DaemonSet metadata: labels: app: systemd-slices-cleaner name: systemd-slices-cleaner namespace: kube-system spec: updateStrategy: type: RollingUpdate selector: matchLabels: app: systemd-slices-cleaner template: metadata: labels: app: systemd-slices-cleaner spec: containers: - command: - /usr/local/bin/supercronic - -json - /app/crontab Image: private-registry.org/systemd-slices-cleaner/systemd-slices-cleaner:v0.1.0 imagePullPolicy: Always name: systemd-slices-cleaner resources: {} securityContext: privileged: true volumeMounts: - name: systemd mountPath: /run/systemd/private - name: docker mountPath: /run/docker.sock - name: systemd-etc mountPath: /etc/systemd - name: systemd-run mountPath: /run/systemd/system/ - name: lsb-release mountPath: /etc/lsb-release-host imagePullSecrets: - name: antiopa-registry priorityClassName: cluster-low tolerations: - operator: Exists volumes: - name: systemd hostPath: path: /run/systemd/private - name: docker hostPath: path: /run/docker.sock - name: systemd-etc hostPath: path: /etc/systemd - name: systemd-run hostPath: path: /run/systemd/system/ - name: lsb-release hostPath: path: /etc/lsb-release

... और यह निम्नलिखित स्क्रिप्ट का उपयोग करता है:

 #!/bin/bash # we will work only on xenial hostrelease="/etc/lsb-release-host" test -f ${hostrelease} && grep xenial ${hostrelease} > /dev/null || exit 0 # sleeping max 30 minutes to dispense load on kube-nodes sleep $((RANDOM % 1800)) stoppedCount=0 # counting actual subpath units in systemd countBefore=$(systemctl list-units | grep subpath | grep "run-" | wc -l) # let's go check each unit for unit in $(systemctl list-units | grep subpath | grep "run-" | awk '{print $1}'); do # finding description file for unit (to find out docker container, who born this unit) DropFile=$(systemctl status ${unit} | grep Drop | awk -F': ' '{print $2}') # reading uuid for docker container from description file DockerContainerId=$(cat ${DropFile}/50-Description.conf | awk '{print $5}' | cut -d/ -f6) # checking container status (running or not) checkFlag=$(docker ps | grep -c ${DockerContainerId}) # if container not running, we will stop unit if [[ ${checkFlag} -eq 0 ]]; then echo "Stopping unit ${unit}" # stoping unit in action systemctl stop $unit # just counter for logs ((stoppedCount++)) # logging current progress echo "Stopped ${stoppedCount} systemd units out of ${countBefore}" fi done

... और यह हर 5 मिनट में शुरू होने वाले सुपर क्रोनिक के साथ शुरू होता है। उनकी डॉकरीफाइल इस तरह दिखती है:

 FROM ubuntu:16.04 COPY rootfs / WORKDIR /app RUN apt-get update && \ apt-get upgrade -y && \ apt-get install -y gnupg curl apt-transport-https software-properties-common wget RUN add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu xenial stable" && \ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - && \ apt-get update && \ apt-get install -y docker-ce=17.03.0* RUN wget https://github.com/aptible/supercronic/releases/download/v0.1.6/supercronic-linux-amd64 -O \ /usr/local/bin/supercronic && chmod +x /usr/local/bin/supercronic ENTRYPOINT ["/bin/bash", "-c", "/usr/local/bin/supercronic -json /app/crontab"]

इतिहास 4. योजना फली में प्रतिस्पर्धा

यह नोट किया गया था: यदि एक नोड को हमारे नोड पर रखा जाता है और इसकी छवि को बहुत लंबे समय के लिए बाहर पंप किया जाता है, तो उसी नोड के लिए "मिला" दूसरी पॉड बस नई पॉड की छवि को खींचना शुरू नहीं करता है । इसके बजाय, वह पिछली पॉड की छवि को खींचने के लिए इंतजार करता है। नतीजतन, एक फली जो पहले से ही योजना बनाई गई है और जिसकी छवि को केवल एक मिनट में डाउनलोड किया जा सकता है, एक लंबे समय के लिए containerCreating स्थिति में समाप्त हो जाएगी।

घटनाओं में, इस तरह से कुछ होगा:

 Normal Pulling 8m kubelet, ip-10-241-44-128.ap-northeast-1.compute.internal pulling image "registry.example.com/infra/openvpn/openvpn:master"

यह पता चला है कि धीमी रजिस्ट्री से एक भी छवि तैनाती को नोड पर रोक सकती है।

दुर्भाग्य से, स्थिति से बाहर इतने सारे तरीके नहीं हैं:

अपने डॉकर रजिस्ट्री को सीधे क्लस्टर में या सीधे क्लस्टर के साथ उपयोग करने का प्रयास करें (उदाहरण के लिए, गेटलैब रजिस्ट्री, नेक्सस, आदि);
क्रैकेन जैसी उपयोगिताओं का उपयोग करें।

इतिहास 5. स्मृति से बाहर निकलना

विभिन्न अनुप्रयोगों के संचालन के दौरान, हमें ऐसी स्थिति भी मिली जहां नोड पूरी तरह से सुलभ होना बंद हो जाता है: एसएसएच जवाब नहीं देता है, सभी निगरानी डेमॉन गिर जाते हैं, और फिर लॉग में कुछ भी (या लगभग कुछ भी) असामान्य नहीं है।

मैं आपको चित्रों में एक नोड के उदाहरण पर बताऊंगा जहां MongoDB कार्य करता है।

यह दुर्घटना से पहले कैसे दिखता है:

और इसलिए - दुर्घटना के बाद :

निगरानी में भी, एक तेज कूद है जिसमें नोड सुलभ होना बंद हो जाता है:

इस प्रकार, स्क्रीनशॉट दिखाते हैं कि:

मशीन पर रैम अंत के पास है;
रैम की खपत में तेज उछाल देखा जाता है, जिसके बाद पूरी मशीन तक पहुंच तेजी से अक्षम हो जाती है;
मानगो में एक बड़ा कार्य आता है, जो DBMS प्रक्रिया को अधिक मेमोरी का उपयोग करने और डिस्क से सक्रिय रूप से पढ़ने के लिए मजबूर करता है।

यह पता चला है कि यदि लिनक्स मुफ्त मेमोरी (मेमोरी प्रेशर) होता है और स्वैप नहीं होता है, तो OOM किलर के आने से पहले पेज कैश में पेज फेंकने और डिस्क पर वापस लिखने के बीच एक संतुलन हो सकता है। यह kswapd द्वारा किया जाता है, जो साहसपूर्वक बाद के वितरण के लिए स्मृति के कई पृष्ठों को मुक्त करता है।

दुर्भाग्य से, I / O के एक बड़े भार के साथ, थोड़ी मात्रा में मुफ्त मेमोरी के साथ युग्मित, kswapd पूरे सिस्टम की अड़चन बन जाता है , क्योंकि सिस्टम में मेमोरी पेजों के सभी पृष्ठ दोष इसके साथ बंधे होते हैं। यह बहुत लंबे समय तक चल सकता है यदि प्रक्रियाएं अब मेमोरी का उपयोग नहीं करना चाहती हैं, लेकिन ओओएम किलर रसातल के बहुत किनारे पर तय की गई हैं।

तार्किक सवाल यह है: OOM हत्यारा इतनी देर से क्यों आता है? वर्तमान ओओएम पुनरावृत्ति में, हत्यारा बेहद बेवकूफ है: यह केवल प्रक्रिया को मार देगा जब एक मेमोरी पेज आवंटित करने का प्रयास विफल हो जाता है, अर्थात। यदि पृष्ठ दोष विफल रहता है। यह लंबे समय तक नहीं होता है, क्योंकि kswapd साहसपूर्वक पेज कैश (सिस्टम में सभी डिस्क I / O, वास्तव में) डिस्क पर वापस फ्लश करके मेमोरी के पृष्ठों को मुक्त करता है। अधिक विस्तार से, कर्नेल में ऐसी समस्याओं को खत्म करने के लिए आवश्यक चरणों के विवरण के साथ, आप यहां पढ़ सकते हैं।

लिनक्स 4.6+ कर्नेल के साथ इस व्यवहार में सुधार होना चाहिए ।

कहानी 6. पॉड्स लंबित हैं

कुछ समूहों में, जिनमें वास्तव में बहुत सारी फली होती हैं, हमने ध्यान देना शुरू किया कि उनमें से अधिकांश Pending अवस्था में बहुत समय से लटके हुए थे, हालाँकि डॉकटर कंटेनर खुद पहले से ही नोड्स पर चल रहे थे और आप स्वयं उनके साथ काम कर सकते थे।

describe में कुछ भी गलत नहीं है:

  Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 1m default-scheduler Successfully assigned sphinx-0 to ss-dev-kub07 Normal SuccessfulAttachVolume 1m attachdetach-controller AttachVolume.Attach succeeded for volume "pvc-6aaad34f-ad10-11e8-a44c-52540035a73b" Normal SuccessfulMountVolume 1m kubelet, ss-dev-kub07 MountVolume.SetUp succeeded for volume "sphinx-config" Normal SuccessfulMountVolume 1m kubelet, ss-dev-kub07 MountVolume.SetUp succeeded for volume "default-token-fzcsf" Normal SuccessfulMountVolume 49s (x2 over 51s) kubelet, ss-dev-kub07 MountVolume.SetUp succeeded for volume "pvc-6aaad34f-ad10-11e8-a44c-52540035a73b" Normal Pulled 43s kubelet, ss-dev-kub07 Container image "registry.example.com/infra/sphinx-exporter/sphinx-indexer:v1" already present on machine Normal Created 43s kubelet, ss-dev-kub07 Created container Normal Started 43s kubelet, ss-dev-kub07 Started container Normal Pulled 43s kubelet, ss-dev-kub07 Container image "registry.example.com/infra/sphinx/sphinx:v1" already present on machine Normal Created 42s kubelet, ss-dev-kub07 Created container Normal Started 42s kubelet, ss-dev-kub07 Started container

चारों ओर खुदाई करने के बाद, हमने यह धारणा बनाई कि क्यूबलेट में केवल एपीआई सर्वर को पॉड्स, लिनन / तत्परता नमूनों की स्थिति के बारे में सभी जानकारी भेजने का समय नहीं है।

और अध्ययन में मदद करने के बाद, हमें निम्नलिखित पैरामीटर मिले:

 --kube-api-qps - QPS to use while talking with kubernetes apiserver (default 5) --kube-api-burst - Burst to use while talking with kubernetes apiserver (default 10) --event-qps - If > 0, limit event creations per second to this value. If 0, unlimited. (default 5) --event-burst - Maximum size of a bursty event records, temporarily allows event records to burst to this number, while still not exceeding event-qps. Only used if --event-qps > 0 (default 10) --registry-qps - If > 0, limit registry pull QPS to this value. --registry-burst - Maximum size of bursty pulls, temporarily allows pulls to burst to this number, while still not exceeding registry-qps. Only used if --registry-qps > 0 (default 10)

जैसा कि आप देख सकते हैं, डिफ़ॉल्ट मान काफी छोटे हैं , और 90% में वे सभी जरूरतों को कवर करते हैं ... हालांकि, हमारे मामले में यह पर्याप्त नहीं था। इसलिए, हम इन मूल्यों को निर्धारित करते हैं:

 --event-qps=30 --event-burst=40 --kube-api-burst=40 --kube-api-qps=30 --registry-qps=30 --registry-burst=40

... और क्यूबलेट्स को फिर से शुरू किया, जिसके बाद उन्होंने एपीआई सर्वर तक पहुंचने के ग्राफ पर निम्न चित्र देखा:

... और हाँ, सब कुछ उड़ने लगा!

पुनश्च

बग को इकट्ठा करने और लेख तैयार करने में मदद के लिए, मैं अपनी कंपनी के कई इंजीनियरों और विशेष रूप से आंद्रेई क्लेमेंटयेव (हमारे आर एंड डी टीम के सहकर्मी) ( ज़ूज़स ) के प्रति अपनी गहरी कृतज्ञता व्यक्त करता हूं।

पी पी एस

हमारे ब्लॉग में भी पढ़ें:

" कुबेरनेट्स पॉड्स में डिबगिंग के लिए कुबेटेल-डिबग प्लगइन ";
" निगरानी और कुबेरनेट्स (समीक्षा और वीडियो रिपोर्ट) ";
कुबेरनेट्स युक्तियाँ और चालें चक्र:

कुबेरनेट्स [और उनके समाधान] के संचालन में 6 मनोरंजक प्रणाली कीड़े