குபெர்னெட்டஸில் முதல் பயன்பாட்டைப் பயன்படுத்தும்போது ஐந்து தவறுகள்

அரிஸ் ட்ரீமரின் தோல்வி

விண்ணப்பத்தை குபெர்னெட்டஸுக்கு (ஹெல்ம் அல்லது கைமுறையாக) மாற்றினால் போதும் என்று பலர் நினைக்கிறார்கள் - மேலும் மகிழ்ச்சி இருக்கும். ஆனால் எல்லாம் அவ்வளவு எளிதல்ல.

அணி Mail.ru கிளவுட் தீர்வுகள் DevOps பொறியாளர் ஜூலியன் கிண்டியின் கட்டுரையை மொழிபெயர்த்தார். அதே ரேக்கில் நீங்கள் காலடி எடுத்து வைக்காதபடி, இடம்பெயர்வுச் செயல்பாட்டின் போது தனது நிறுவனம் என்னென்ன ஆபத்துக்களை எதிர்கொண்டது என்பதை அவர் கூறுகிறார்.

படி ஒன்று: பாட் கோரிக்கைகள் மற்றும் வரம்புகளை அமைக்கவும்

நமது காய்கள் இயங்கும் சுத்தமான சூழலை அமைப்பதன் மூலம் தொடங்குவோம். குபெர்னெட்டஸ் பாட் திட்டமிடல் மற்றும் தோல்வியில் சிறந்தவர். ஆனால் அது வெற்றிகரமாக வேலை செய்ய எத்தனை வளங்கள் தேவை என்பதை மதிப்பிடுவது கடினமாக இருந்தால், திட்டமிடுபவர் சில நேரங்களில் ஒரு பாட் வைக்க முடியாது என்று மாறியது. இங்குதான் வளங்கள் மற்றும் வரம்புகளுக்கான கோரிக்கைகள் தோன்றும். கோரிக்கைகள் மற்றும் வரம்புகளை அமைப்பதற்கான சிறந்த அணுகுமுறை பற்றி நிறைய விவாதங்கள் உள்ளன. சில நேரங்களில் இது ஒரு அறிவியலை விட ஒரு கலை என்று தோன்றுகிறது. இங்கே எங்கள் அணுகுமுறை உள்ளது.

பாட் கோரிக்கைகள் பாட்களை உகந்ததாக வைக்க திட்டமிடுபவர் பயன்படுத்தும் முக்கிய மதிப்பு.

Из குபெர்னெட்ஸ் ஆவணங்கள்: வடிகட்டி படியானது ஒரு Pod திட்டமிடக்கூடிய முனைகளின் தொகுப்பை வரையறுக்கிறது. எடுத்துக்காட்டாக, PodFitsResources வடிப்பானானது, ஒரு முனையிடமிருந்து குறிப்பிட்ட ஆதாரக் கோரிக்கைகளைப் பூர்த்தி செய்ய ஒரு முனையில் போதுமான ஆதாரங்கள் உள்ளதா என்பதைப் பார்க்கிறது.

எத்தனை ஆதாரங்களை மதிப்பிடும் வகையில் பயன்பாட்டுக் கோரிக்கைகளைப் பயன்படுத்துகிறோம் உண்மையில் பயன்பாட்டிற்கு அது சரியாகச் செயல்பட வேண்டும். இந்த வழியில் திட்டமிடுபவர் முனைகளை யதார்த்தமாக வைக்க முடியும். ஆரம்பத்தில், ஒவ்வொரு Podக்கும் போதுமான ஆதாரங்களை உறுதிப்படுத்த கோரிக்கைகளை அதிகமாக திட்டமிட விரும்பினோம், ஆனால் திட்டமிடல் நேரம் கணிசமாக அதிகரித்திருப்பதையும், சில Pods முழுமையாக திட்டமிடப்படவில்லை என்பதையும் கவனித்தோம்.

இந்த வழக்கில், திட்டமிடுபவர் அடிக்கடி காய்களை "கசக்கிவிடுவார்" மேலும் அவற்றை மறுஅட்டவணை செய்ய முடியாது, ஏனெனில் பயன்பாட்டிற்கு எவ்வளவு ஆதாரங்கள் தேவை என்று கட்டுப்பாட்டு விமானத்திற்கு தெரியாது, இது திட்டமிடல் அல்காரிதத்தின் முக்கிய அங்கமாகும்.

பாட் வரம்புகள் ஒரு நெற்றுக்கான தெளிவான வரம்பு. கொத்து கொள்கலனுக்கு ஒதுக்கும் வளங்களின் அதிகபட்ச அளவை இது குறிக்கிறது.

மீண்டும், இருந்து அதிகாரப்பூர்வ ஆவணங்கள்: ஒரு கொள்கலனில் 4 GiB நினைவக வரம்பு இருந்தால், குபெலெட் (மற்றும் கொள்கலன் இயக்க நேரம்) அதைச் செயல்படுத்தும். குறிப்பிட்ட ஆதார வரம்பை விட அதிகமாக பயன்படுத்துவதிலிருந்து கன்டெய்னரை இயக்க நேரம் தடுக்கிறது. எடுத்துக்காட்டாக, ஒரு கொள்கலனில் உள்ள செயல்முறை அனுமதிக்கப்பட்ட நினைவகத்தை விட அதிகமாக பயன்படுத்த முயற்சிக்கும் போது, ​​கணினி கர்னல் "நினைவகத்திற்கு வெளியே" (OOM) பிழையுடன் செயல்முறையை நிறுத்துகிறது.

ஒரு கொள்கலன் எப்போதுமே ஆதாரக் கோரிக்கை குறிப்பிடுவதை விட அதிகமான ஆதாரங்களைப் பயன்படுத்த முடியும், ஆனால் அது வரம்பிற்கு மேல் பயன்படுத்த முடியாது. இந்த மதிப்பை சரியாக அமைப்பது கடினம், ஆனால் இது மிகவும் முக்கியமானது.

சிறந்த முறையில், கணினியில் உள்ள மற்ற செயல்முறைகளில் குறுக்கிடாமல் ஒரு செயல்முறையின் வாழ்க்கைச் சுழற்சியின் போது ஒரு பாட்டின் ஆதாரத் தேவைகள் மாற வேண்டும் என்று நாங்கள் விரும்புகிறோம் - இது வரம்புகளை அமைப்பதன் நோக்கமாகும்.

துரதிர்ஷ்டவசமாக, என்ன மதிப்புகளை அமைக்க வேண்டும் என்பதற்கான குறிப்பிட்ட வழிமுறைகளை என்னால் கொடுக்க முடியாது, ஆனால் பின்வரும் விதிகளை நாமே கடைபிடிக்கிறோம்:

1. சுமை சோதனைக் கருவியைப் பயன்படுத்தி, போக்குவரத்தின் அடிப்படை அளவை உருவகப்படுத்துகிறோம் மற்றும் பாட் வளங்களின் (நினைவக மற்றும் செயலி) பயன்பாட்டைக் கவனிக்கிறோம்.
2. பாட் கோரிக்கைகளை தன்னிச்சையாக குறைந்த மதிப்பிற்கு (கோரிக்கை மதிப்பை விட 5 மடங்கு வள வரம்புடன்) அமைத்து கவனிக்கவும். கோரிக்கைகள் மிகக் குறைந்த மட்டத்தில் இருக்கும்போது, ​​செயல்முறையைத் தொடங்க முடியாது, பெரும்பாலும் ரகசிய Go இயக்க நேரப் பிழைகளை ஏற்படுத்தும்.

அதிக வள வரம்புகள் திட்டமிடலை மிகவும் கடினமாக்குகின்றன என்பதை நான் கவனிக்கிறேன், ஏனெனில் பாட்க்கு போதுமான ஆதாரங்களுடன் ஒரு இலக்கு முனை தேவைப்படுகிறது.

4 ஜிபி நினைவகம் போன்ற மிக உயர்ந்த ஆதார வரம்பைக் கொண்ட இலகுரக வலை சேவையகத்தை நீங்கள் வைத்திருக்கும் சூழ்நிலையை கற்பனை செய்து பாருங்கள். இந்த செயல்முறையானது கிடைமட்டமாக அளவிடப்பட வேண்டும், மேலும் ஒவ்வொரு புதிய பாட் குறைந்தபட்சம் 4 GB கிடைக்கக்கூடிய நினைவகத்துடன் ஒரு முனையில் திட்டமிடப்பட வேண்டும். அத்தகைய முனை இல்லை எனில், இந்த பாட் செயல்படுத்துவதற்கு கிளஸ்டர் ஒரு புதிய முனையை அறிமுகப்படுத்த வேண்டும், இதற்கு சிறிது நேரம் ஆகலாம். விரைவான மற்றும் மென்மையான அளவிடுதலை உறுதிசெய்ய, ஆதார கோரிக்கைகள் மற்றும் வரம்புகளுக்கு இடையே குறைந்தபட்ச வேறுபாட்டை அடைவது முக்கியம்.

படி இரண்டு: உயிரோட்டம் மற்றும் தயார்நிலை சோதனைகளை அமைக்கவும்

இது குபர்னெட்ஸ் சமூகத்தில் அடிக்கடி விவாதிக்கப்படும் மற்றொரு நுட்பமான தலைப்பு. மென்பொருளின் நிலையான செயல்பாட்டிற்கான ஒரு பொறிமுறையை வழங்கும் மற்றும் வேலையில்லா நேரத்தைக் குறைப்பதால், லைவ்னெஸ் மற்றும் ரெடினெஸ் சோதனைகளைப் பற்றி நல்ல புரிதல் இருப்பது முக்கியம். இருப்பினும், சரியாக உள்ளமைக்கப்படாவிட்டால், அவை உங்கள் பயன்பாட்டின் செயல்திறனைப் பாதிக்கலாம். இரண்டு மாதிரிகள் என்ன என்பதன் சுருக்கம் கீழே உள்ளது.

வாழ்வாதாரம் கொள்கலன் இயங்குகிறதா என்பதைக் காட்டுகிறது. அது தோல்வியுற்றால், குபெலெட் கொள்கலனைக் கொன்றுவிடும், அதற்கு மறுதொடக்கம் கொள்கை இயக்கப்படும். கன்டெய்னரில் லைவ்னஸ் ப்ரோப் பொருத்தப்படவில்லை என்றால், இயல்பு நிலை வெற்றி பெறும் - இல் கூறப்பட்டுள்ளது குபெர்னெட்ஸ் ஆவணங்கள்.

லைவ்னஸ் ப்ரோப்கள் மலிவானதாக இருக்க வேண்டும், அதாவது நிறைய வளங்களை உட்கொள்ளக்கூடாது, ஏனெனில் அவை அடிக்கடி இயங்கும் மற்றும் பயன்பாடு இயங்குகிறது என்பதை குபர்னெட்டஸுக்கு தெரிவிக்க வேண்டும்.

ஒவ்வொரு நொடியும் இயங்கும் விருப்பத்தை நீங்கள் அமைத்தால், இது ஒரு வினாடிக்கு 1 கோரிக்கையைச் சேர்க்கும், எனவே இந்த டிராஃபிக்கைச் செயல்படுத்த கூடுதல் ஆதாரங்கள் தேவைப்படும் என்பதை நினைவில் கொள்ளவும்.

எங்கள் நிறுவனத்தில், லைவ்னெஸ் சோதனைகள், தரவு (உதாரணமாக, தொலைநிலை தரவுத்தளம் அல்லது தற்காலிக சேமிப்பில் இருந்து) முழுமையாக கிடைக்காவிட்டாலும், பயன்பாட்டின் முக்கிய கூறுகளை சோதிக்கிறது.

பயன்பாடுகளில் 200 மறுமொழிக் குறியீட்டை வழங்கும் "உடல்நலம்" இறுதிப்புள்ளியை அமைத்துள்ளோம். இது செயல்முறை இயங்குகிறது மற்றும் கோரிக்கைகளைக் கையாளும் திறன் கொண்டது என்பதற்கான அறிகுறியாகும் (ஆனால் இன்னும் போக்குவரத்து இல்லை).

முயற்சி தயார்நிலை கோரிக்கைகளை வழங்க கொள்கலன் தயாராக உள்ளதா என்பதைக் குறிக்கிறது. தயார்நிலை ஆய்வு தோல்வியுற்றால், எண்ட்பாயிண்ட் கன்ட்ரோலர் பாட்டின் ஐபி முகவரியை பாட் உடன் பொருந்தும் அனைத்து சேவைகளின் இறுதிப்புள்ளிகளிலிருந்தும் அகற்றும். இது குபர்னெட்டஸ் ஆவணத்திலும் கூறப்பட்டுள்ளது.

ஆயத்த ஆய்வுகள் அதிக ஆதாரங்களைப் பயன்படுத்துகின்றன, ஏனெனில் விண்ணப்பம் கோரிக்கைகளை ஏற்கத் தயாராக உள்ளது என்பதைக் காண்பிக்கும் வகையில் அவை பின்தளத்தைத் தாக்க வேண்டும்.

தரவுத்தளத்தை நேரடியாக அணுகலாமா என்பது குறித்து சமூகத்தில் நிறைய விவாதங்கள் உள்ளன. மேல்நிலையைக் கருத்தில் கொண்டு (காசோலைகள் அடிக்கடி நிகழ்கின்றன, ஆனால் அவற்றைக் கட்டுப்படுத்தலாம்), சில பயன்பாடுகளுக்கு, தரவுத்தளத்திலிருந்து பதிவுகள் திரும்பப் பெறப்பட்டதா என்பதைச் சரிபார்த்த பின்னரே, போக்குவரத்து சேவைக்கான தயார்நிலை கணக்கிடப்படும் என்று முடிவு செய்தோம். நன்கு வடிவமைக்கப்பட்ட தயார்நிலை சோதனைகள் அதிக அளவு கிடைப்பதை உறுதிசெய்தது மற்றும் வரிசைப்படுத்தலின் போது வேலையில்லா நேரத்தை நீக்கியது.

உங்கள் பயன்பாட்டின் தயார்நிலையைச் சோதிக்க தரவுத்தளத்தை வினவ முடிவு செய்தால், அது முடிந்தவரை மலிவானது என்பதை உறுதிப்படுத்தவும். இந்தக் கேள்வியை எடுத்துக் கொள்வோம்:

SELECT small_item FROM table LIMIT 1

குபெர்னெட்ஸில் இந்த இரண்டு மதிப்புகளை எவ்வாறு கட்டமைக்கிறோம் என்பதற்கான எடுத்துக்காட்டு இங்கே:

livenessProbe: 
 httpGet:   
   path: /api/liveness    
   port: http 
readinessProbe:  
 httpGet:    
   path: /api/readiness    
   port: http  periodSeconds: 2

நீங்கள் சில கூடுதல் உள்ளமைவு விருப்பங்களைச் சேர்க்கலாம்:

• initialDelaySeconds - கொள்கலனின் ஏவுதலுக்கும் ஆய்வுகளின் தொடக்கத்திற்கும் இடையில் எத்தனை வினாடிகள் கடக்கும்.
• periodSeconds - மாதிரி ரன்களுக்கு இடையில் காத்திருக்கும் இடைவெளி.
• timeoutSeconds - நெற்று அவசரநிலையாகக் கருதப்படும் வினாடிகளின் எண்ணிக்கை. சாதாரண காலக்கெடு.
• failureThreshold மறுதொடக்கம் சமிக்ஞை பாட்க்கு அனுப்பப்படும் முன் சோதனை தோல்விகளின் எண்ணிக்கை.
• successThreshold பாட் தயார் நிலைக்கு மாறுவதற்கு முன் வெற்றிகரமான சோதனைகளின் எண்ணிக்கை (பாட் தொடங்கும் போது அல்லது மீட்டெடுக்கும் போது தோல்வியடைந்த பிறகு).

படி மூன்று: Pod இன் இயல்புநிலை நெட்வொர்க் கொள்கைகளை அமைத்தல்

குபெர்னெட்டஸ் ஒரு "பிளாட்" நெட்வொர்க் நிலப்பரப்பைக் கொண்டுள்ளது, முன்னிருப்பாக அனைத்து காய்களும் ஒருவருக்கொருவர் நேரடியாக தொடர்பு கொள்கின்றன. சில சந்தர்ப்பங்களில் இது விரும்பத்தகாதது.

ஒரு சாத்தியமான பாதுகாப்புச் சிக்கல் என்னவென்றால், நெட்வொர்க்கில் உள்ள அனைத்து பாட்களுக்கும் ட்ராஃபிக்கை அனுப்ப, தாக்குபவர் ஒரு பாதிக்கப்படக்கூடிய பயன்பாட்டைப் பயன்படுத்தலாம். பாதுகாப்பின் பல பகுதிகளைப் போலவே, குறைந்தபட்ச சலுகையின் கொள்கை இங்கேயும் பொருந்தும். சிறந்த முறையில், நெட்ஒர்க் கொள்கைகள் காய்களுக்கு இடையே எந்த இணைப்புகள் அனுமதிக்கப்படுகின்றன மற்றும் எது இல்லை என்பதை வெளிப்படையாகக் குறிப்பிட வேண்டும்.

எடுத்துக்காட்டாக, பின்வருபவை ஒரு குறிப்பிட்ட பெயர்வெளிக்கான அனைத்து உள்வரும் போக்குவரத்தையும் மறுக்கும் எளிய கொள்கையாகும்:

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:  
 name: default-deny-ingress
spec:  
 podSelector: {}  
 policyTypes:  
   - Ingress

இந்த கட்டமைப்பின் காட்சிப்படுத்தல்:

(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
மேலும் விவரங்களுக்கு இங்கே.

படி நான்கு: கொக்கிகள் மற்றும் Init கொள்கலன்களுடன் தனிப்பயன் நடத்தை

டெவலப்பர்களுக்கு வேலையில்லா நேரம் இல்லாமல் குபெர்னெட்ஸில் வரிசைப்படுத்தல்களை வழங்குவதே எங்கள் முக்கிய குறிக்கோள்களில் ஒன்றாகும். பயன்பாடுகளை மூடுவதற்கும் பயன்படுத்தப்பட்ட ஆதாரங்களை வெளியிடுவதற்கும் பல விருப்பங்கள் இருப்பதால் இது கடினம்.

குறிப்பாக சிரமங்கள் எழுந்தன nginx. இந்த பாட்களை வரிசையாகப் பயன்படுத்தும்போது, ​​வெற்றிகரமாக முடிப்பதற்கு முன் செயலில் உள்ள இணைப்புகள் தடைபட்டதை நாங்கள் கவனித்தோம்.

இணையத்தில் விரிவான ஆராய்ச்சிக்குப் பிறகு, குபெர்னெட்ஸ் Nginx இணைப்புகளை நிறுத்துவதற்கு முன் காத்திருக்கவில்லை என்பது தெரியவந்தது. ப்ரீ-ஸ்டாப் ஹூக்கின் உதவியுடன், நாங்கள் பின்வரும் செயல்பாட்டைச் செயல்படுத்தி, வேலையில்லா நேரத்தை முற்றிலுமாக அகற்றினோம்:

lifecycle: 
 preStop:
   exec:
     command: ["/usr/local/bin/nginx-killer.sh"]

இங்கு nginx-killer.sh:

#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
   echo "Waiting while shutting down nginx..."
   sleep 10
done

மற்றொரு மிகவும் பயனுள்ள முன்னுதாரணம், குறிப்பிட்ட பயன்பாடுகளின் துவக்கத்தைக் கையாள init கொள்கலன்களைப் பயன்படுத்துவதாகும். பயன்பாடு தொடங்கும் முன் இயக்கப்பட வேண்டிய வள-தீவிர தரவுத்தள இடம்பெயர்வு செயல்முறை உங்களிடம் இருந்தால் இது மிகவும் பயனுள்ளதாக இருக்கும். முக்கிய பயன்பாட்டிற்கு அத்தகைய வரம்பை அமைக்காமல், இந்த செயல்முறைக்கான அதிக ஆதார வரம்பை நீங்கள் குறிப்பிடலாம்.

மற்றொரு பொதுவான திட்டமானது init கொள்கலனில் உள்ள இரகசியங்களை அணுகுவது ஆகும், இது முக்கிய தொகுதிக்கு இந்த நற்சான்றிதழ்களை வழங்குகிறது, இது முக்கிய பயன்பாட்டு தொகுதியிலிருந்தே இரகசியங்களை அங்கீகரிக்கப்படாத அணுகலைத் தடுக்கிறது.

வழக்கம் போல், ஆவணத்தில் இருந்து ஒரு மேற்கோள்: init கன்டெய்னர்கள் பயனர் குறியீடு அல்லது பயன்பாடுகளை பாதுகாப்பாக இயக்குகின்றன, இல்லையெனில் பயன்பாட்டின் கொள்கலன் படத்தின் பாதுகாப்பை சமரசம் செய்யும். தேவையற்ற கருவிகளை தனித்தனியாக வைத்திருப்பதன் மூலம், பயன்பாட்டின் கண்டெய்னர் படத்தின் தாக்குதல் மேற்பரப்பைக் கட்டுப்படுத்துகிறீர்கள்.

படி ஐந்து: கர்னல் கட்டமைப்பு

இறுதியாக, இன்னும் மேம்பட்ட நுட்பத்தைப் பற்றி பேசலாம்.

குபெர்னெட்ஸ் என்பது மிகவும் நெகிழ்வான தளமாகும், இது நீங்கள் பொருத்தமாக இருந்தாலும் பணிச்சுமையை இயக்க அனுமதிக்கிறது. எங்களிடம் பல திறமையான பயன்பாடுகள் உள்ளன, அவை மிகவும் வளம் மிகுந்தவை. விரிவான சுமை சோதனையை மேற்கொண்ட பிறகு, இயல்புநிலை குபெர்னெட்டஸ் அமைப்புகள் நடைமுறையில் இருக்கும் போது, ​​எதிர்பார்க்கப்படும் ட்ராஃபிக்கைச் சுமையுடன் வைத்திருப்பதில் பயன்பாடுகளில் ஒன்று கடினமாக இருப்பதைக் கண்டறிந்தோம்.

இருப்பினும், குபெர்னெட்டஸ் ஒரு குறிப்பிட்ட பாட்க்கான கர்னல் அளவுருக்களை மட்டுமே மாற்றும் சலுகை பெற்ற கொள்கலனை இயக்க உங்களை அனுமதிக்கிறது. திறந்த இணைப்புகளின் அதிகபட்ச எண்ணிக்கையை மாற்ற நாங்கள் பயன்படுத்தியது இங்கே:

initContainers:
  - name: sysctl
     image: alpine:3.10
     securityContext:
         privileged: true
      command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]

இது மிகவும் மேம்பட்ட நுட்பமாகும், இது பெரும்பாலும் தேவையில்லை. ஆனால் உங்கள் பயன்பாடு அதிக சுமையைச் சமாளிக்க சிரமப்பட்டால், இந்த அமைப்புகளில் சிலவற்றை மாற்ற முயற்சி செய்யலாம். இந்த செயல்முறை மற்றும் வெவ்வேறு மதிப்புகளை அமைப்பது பற்றிய கூடுதல் தகவல்கள் - எப்போதும் போல அதிகாரப்பூர்வ ஆவணத்தில்.

முடிவில்

குபெர்னெட்ஸ் ஒரு அவுட்-ஆஃப்-பாக்ஸ் தீர்வாகத் தோன்றினாலும், பயன்பாடுகள் சீராக இயங்குவதற்கு சில முக்கிய படிகள் எடுக்கப்பட வேண்டும்.

குபெர்னெட்டஸுக்கு இடம்பெயர்வு முழுவதும், “சுமை சோதனை சுழற்சியை” பின்பற்றுவது முக்கியம்: பயன்பாட்டை இயக்கவும், அதை சுமையின் கீழ் சோதிக்கவும், அளவீடுகள் மற்றும் அளவிடுதல் நடத்தையை கவனிக்கவும், இந்தத் தரவின் அடிப்படையில் உள்ளமைவைச் சரிசெய்து, பின்னர் இந்த சுழற்சியை மீண்டும் செய்யவும்.

எதிர்பார்க்கப்படும் போக்குவரத்தைப் பற்றி யதார்த்தமாக இருங்கள் மற்றும் எந்த கூறுகள் முதலில் உடைகின்றன என்பதைப் பார்க்க அதைத் தாண்டிச் செல்ல முயற்சிக்கவும். இந்த முறையான அணுகுமுறையுடன், பட்டியலிடப்பட்ட சில பரிந்துரைகள் மட்டுமே வெற்றியை அடைய போதுமானதாக இருக்கும். அல்லது இன்னும் ஆழமான தனிப்பயனாக்கம் தேவைப்படலாம்.

இந்த கேள்விகளை எப்போதும் உங்களை நீங்களே கேட்டுக்கொள்ளுங்கள்:

1. பயன்பாடுகள் எத்தனை ஆதாரங்களைப் பயன்படுத்துகின்றன, இந்தத் தொகை எப்படி மாறும்?
2. உண்மையான அளவிடுதல் தேவைகள் என்ன? ஆப்ஸ் சராசரியாக எவ்வளவு டிராஃபிக்கைக் கையாளும்? உச்ச போக்குவரத்து பற்றி என்ன?
3. சேவையை எவ்வளவு அடிக்கடி அளவிட வேண்டும்? ட்ராஃபிக்கைப் பெற புதிய காய்கள் எவ்வளவு விரைவாக இயங்க வேண்டும்?
4. காய்கள் எவ்வளவு அழகாக மூடப்படுகின்றன? இது தேவையா? வேலையில்லா நேரம் இல்லாமல் வரிசைப்படுத்தலை அடைய முடியுமா?
5. பாதுகாப்பு அபாயங்களைக் குறைப்பது மற்றும் சமரசம் செய்யப்பட்ட காய்களிலிருந்து சேதத்தை எவ்வாறு கட்டுப்படுத்துவது? ஏதேனும் சேவைகளுக்குத் தேவையில்லாத அனுமதிகள் அல்லது அணுகல்கள் உள்ளதா?

ஒரு கிளஸ்டரில் ஆயிரக்கணக்கான சேவைகளை வரிசைப்படுத்த சிறந்த நடைமுறைகளைப் பயன்படுத்த உங்களை அனுமதிக்கும் நம்பமுடியாத தளத்தை Kubernetes வழங்குகிறது. இருப்பினும், எல்லா பயன்பாடுகளும் வேறுபட்டவை. சில நேரங்களில் செயல்படுத்த இன்னும் கொஞ்சம் வேலை தேவைப்படுகிறது.

அதிர்ஷ்டவசமாக, அனைத்து தொழில்நுட்ப இலக்குகளையும் அடைய தேவையான அமைப்புகளை Kubernetes வழங்குகிறது. ஆதார கோரிக்கைகள் மற்றும் வரம்புகள், லைவ்னெஸ் மற்றும் ரெடினெஸ் ஆய்வுகள், init கொள்கலன்கள், நெட்வொர்க் கொள்கைகள் மற்றும் தனிப்பயன் கர்னல் ட்யூனிங் ஆகியவற்றின் கலவையைப் பயன்படுத்துவதன் மூலம், தவறு சகிப்புத்தன்மை மற்றும் விரைவான அளவிடுதல் ஆகியவற்றுடன் உயர் செயல்திறனை அடையலாம்.

வேறு என்ன படிக்க வேண்டும்:

1. உற்பத்திச் சூழல்களில் கொள்கலன்கள் மற்றும் குபெர்னெட்களை இயக்குவதற்கான சிறந்த நடைமுறைகள் மற்றும் சிறந்த நடைமுறைகள்.
2. 90+ குபெர்னெட்களுக்கான பயனுள்ள கருவிகள்: வரிசைப்படுத்தல், மேலாண்மை, கண்காணிப்பு, பாதுகாப்பு மற்றும் பல.
3. Telegram இல் Kubernetes சுற்றி எங்கள் சேனல்.

ஆதாரம்: www.habr.com