🥇குபர்னெட்டஸைப் பயன்படுத்தும் போது 10 பொதுவான தவறுகள்

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

Kubernetes ஐப் பயன்படுத்திய ஆண்டுகளில், நாங்கள் அதிக எண்ணிக்கையிலான கிளஸ்டர்களுடன் (நிர்வகிக்கப்பட்ட மற்றும் நிர்வகிக்கப்படாத - GCP, AWS மற்றும் Azure இல்) பணியாற்றியுள்ளோம். காலப்போக்கில், சில தவறுகள் தொடர்ந்து மீண்டும் செய்யப்படுவதை நாங்கள் கவனிக்க ஆரம்பித்தோம். இருப்பினும், இதில் எந்த அவமானமும் இல்லை: அவற்றில் பெரும்பாலானவற்றை நாமே செய்துள்ளோம்!

கட்டுரையில் மிகவும் பொதுவான பிழைகள் உள்ளன மற்றும் அவற்றை எவ்வாறு சரிசெய்வது என்பதையும் குறிப்பிடுகிறது.

1. வளங்கள்: கோரிக்கைகள் மற்றும் வரம்புகள்

இந்த உருப்படி நிச்சயமாக மிக நெருக்கமான கவனத்திற்கும் பட்டியலில் முதல் இடத்திற்கும் தகுதியானது.

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

சிறந்த முயற்சி (மிகவும் இல்லை பரிந்துரைக்கப்படுகிறது):

resources: {}

மிகக் குறைந்த CPU கோரிக்கை (மிகவும் இல்லை பரிந்துரைக்கப்படுகிறது):

   resources:
      Requests:
        cpu: "1m"

மறுபுறம், ஒரு CPU வரம்பு இருப்பதால், கணு செயலி முழுமையாக ஏற்றப்படாவிட்டாலும், கடிகார சுழற்சிகளை காய்களால் நியாயமற்ற முறையில் தவிர்க்கலாம். மீண்டும், இது அதிக தாமதத்திற்கு வழிவகுக்கும். அளவுருவைச் சுற்றி சர்ச்சை தொடர்கிறது CPU CFS ஒதுக்கீடு Linux kernel மற்றும் CPU த்ரோட்டில் செட் வரம்புகளைப் பொறுத்து, அதே போல் CFS ஒதுக்கீட்டை முடக்குகிறது... ஐயோ, CPU வரம்புகள் தீர்க்கக்கூடியதை விட அதிகமான சிக்கல்களை ஏற்படுத்தலாம். இது பற்றிய கூடுதல் தகவல்களை கீழே உள்ள இணைப்பில் காணலாம்.

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

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

வெடிக்கக்கூடியது (OOMkilled பெறுவதற்கான அதிக வாய்ப்பு):

   resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

உத்தரவாதம்:

   resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

ஆதாரங்களை அமைக்கும் போது என்ன உதவியாக இருக்கும்?

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

kubectl top pods
kubectl top pods --containers
kubectl top nodes

இருப்பினும், அவை தற்போதைய பயன்பாட்டை மட்டுமே காட்டுகின்றன. இது அளவின் வரிசையைப் பற்றிய தோராயமான யோசனையை உங்களுக்கு வழங்க முடியும், ஆனால் இறுதியில் உங்களுக்கு இது தேவைப்படும் காலப்போக்கில் அளவீடுகளில் ஏற்பட்ட மாற்றங்களின் வரலாறு (இது போன்ற கேள்விகளுக்கு பதிலளிக்க: "உச்ச CPU சுமை என்ன?", "நேற்று காலை ஏற்றம் என்ன?", முதலியன). இதற்கு நீங்கள் பயன்படுத்தலாம் பிரமீதீயஸ், டேட்டா டாக் மற்றும் பிற கருவிகள். அவர்கள் மெட்ரிக்ஸ்-சர்வரில் இருந்து அளவீடுகளைப் பெற்று அவற்றைச் சேமிக்கிறார்கள், மேலும் பயனர் அவற்றை வினவலாம் மற்றும் அதற்கேற்ப அவற்றைத் திட்டமிடலாம்.

செங்குத்துPodAutoscaler அது அனுமதிக்கிறது தானியங்கு இந்த செயல்முறை. இது CPU மற்றும் நினைவக பயன்பாட்டு வரலாற்றைக் கண்காணிக்கிறது மற்றும் இந்தத் தகவலின் அடிப்படையில் புதிய கோரிக்கைகள் மற்றும் வரம்புகளை அமைக்கிறது.

கணினி சக்தியை திறமையாக பயன்படுத்துவது எளிதான காரியம் அல்ல. எல்லா நேரத்திலும் டெட்ரிஸ் விளையாடுவது போன்றது. குறைந்த சராசரி நுகர்வு (~10% என்று சொல்லுங்கள்) கொண்ட கம்ப்யூட் பவர்க்கு நீங்கள் அதிக கட்டணம் செலுத்தினால், AWS Fargate அல்லது Virtual Kubelet அடிப்படையில் தயாரிப்புகளைப் பார்க்க பரிந்துரைக்கிறோம். அவை சர்வர்லெஸ்/பயனுக்கான கட்டணம் செலுத்தும் பில்லிங் மாதிரியில் கட்டமைக்கப்பட்டுள்ளன, இது போன்ற நிலைமைகளில் இது மலிவானதாக மாறும்.

2. உயிரோட்டம் மற்றும் தயார்நிலை ஆய்வுகள்

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

ஆனால் ஒரு அபாயகரமான பிழை ஏற்பட்டால் சேவையை மறுதொடக்கம் செய்வதை வேறு எப்படி தொடங்கலாம்? ஒரு பாட் போக்குவரத்தை ஏற்கத் தயாராக உள்ளது என்பதை சுமை சமநிலையாளருக்கு எப்படித் தெரியும்? அல்லது அதிக போக்குவரத்தை கையாள முடியுமா?

இந்த சோதனைகள் பெரும்பாலும் ஒருவருக்கொருவர் குழப்பமடைகின்றன:

வாழ்வாதாரம் - "உயிர்வாழ்வு" சரிபார்ப்பு, அது தோல்வியுற்றால் அதை மீண்டும் தொடங்கும்;
தயார்நிலை - தயார்நிலை சரிபார்ப்பு, அது தோல்வியுற்றால், அது குபெர்னெட்ஸ் சேவையிலிருந்து பாட் துண்டிக்கப்படும் (இதைப் பயன்படுத்தி சரிபார்க்கலாம் kubectl get endpoints) மற்றும் அடுத்த சோதனை வெற்றிகரமாக முடியும் வரை போக்குவரத்து வராது.

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

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

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

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

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

3. ஒவ்வொரு HTTP சேவைக்கும் LoadBalancer

பெரும்பாலும், நீங்கள் வெளி உலகிற்கு அனுப்ப விரும்பும் HTTP சேவைகளை உங்கள் கிளஸ்டரில் வைத்திருக்கலாம்.

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

இந்த வழக்கில், ஒரு வெளிப்புற சுமை சமநிலையைப் பயன்படுத்துவது மிகவும் தர்க்கரீதியானது, சேவைகளைத் திறக்கிறது type: NodePort. அல்லது இன்னும் சிறப்பாக, எதையாவது விரிவாக்குங்கள் nginx-ingress-controller (அல்லது traefik), யார் மட்டும் இருப்பார்கள் நோட்போர்ட் வெளிப்புற சுமை சமநிலையுடன் தொடர்புடைய இறுதிப்புள்ளி மற்றும் பயன்படுத்தி கிளஸ்டரில் போக்குவரத்தை வழிநடத்தும் உட்செல்வதை-குபெர்னெட்ஸ் வளங்கள்.

ஒருவருக்கொருவர் தொடர்பு கொள்ளும் பிற உள்-கிளஸ்டர் (மைக்ரோ) சேவைகள் போன்ற சேவைகளைப் பயன்படுத்தி "தொடர்பு கொள்ள" முடியும் ClusterIP மற்றும் DNS வழியாக உள்ளமைக்கப்பட்ட சேவை கண்டுபிடிப்பு பொறிமுறை. அவர்களின் பொது DNS/IP ஐப் பயன்படுத்த வேண்டாம், ஏனெனில் இது தாமதத்தை பாதிக்கும் மற்றும் கிளவுட் சேவைகளின் விலையை அதிகரிக்கும்.

4. ஒரு கிளஸ்டரின் அம்சங்களை கணக்கில் எடுத்துக் கொள்ளாமல் ஆட்டோஸ்கேலிங்

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

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

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

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

5. IAM/RBAC திறன்களை புறக்கணித்தல்

IAM பயனர்களை தொடர்ந்து ரகசியங்களுடன் பயன்படுத்துவதில் ஜாக்கிரதை இயந்திரங்கள் மற்றும் பயன்பாடுகள். பாத்திரங்கள் மற்றும் சேவை கணக்குகளைப் பயன்படுத்தி தற்காலிக அணுகலை ஒழுங்கமைக்கவும் (சேவை கணக்குகள்).

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

kube2iam பற்றி மறந்துவிட்டு, சேவைக் கணக்குகளுக்கான IAM பாத்திரங்களுக்கு நேராகச் செல்லவும் (இதில் விவரிக்கப்பட்டுள்ளபடி அதே பெயரின் குறிப்பு ஸ்டிபன் வ்ரானி):

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
  name: my-serviceaccount
  namespace: default

ஒரு சிறுகுறிப்பு. அவ்வளவு கடினமாக இல்லை, இல்லையா?

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

6. காய்களுக்கு தானியங்கு எதிர்ப்புத் தன்மையை நம்ப வேண்டாம்

ஒரு முனையில் சில வரிசைப்படுத்தலின் மூன்று பிரதிகள் உங்களிடம் இருப்பதாக கற்பனை செய்து பாருங்கள். முனை விழுகிறது, அதனுடன் அனைத்து பிரதிகளும். விரும்பத்தகாத சூழ்நிலை, இல்லையா? ஆனால் ஏன் அனைத்து பிரதிகளும் ஒரே முனையில் இருந்தன? குபெர்னெட்ஸ் அதிக கிடைக்கும் தன்மையை (HA) வழங்க வேண்டும் அல்லவா?!

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

// опущено для краткости
      labels:
        app: zk
// опущено для краткости
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

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

இங்கே நாம் பேசுகிறோம் podAntiAffinity வெவ்வேறு முனைகளில்: topologyKey: "kubernetes.io/hostname", - மற்றும் வெவ்வேறு கிடைக்கும் மண்டலங்களைப் பற்றி அல்ல. முழு அளவிலான HA ஐ செயல்படுத்த, நீங்கள் இந்த தலைப்பில் ஆழமாக தோண்ட வேண்டும்.

7. PodDisruptionBudgets ஐ புறக்கணித்தல்

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

முனைகள் இல்லாததால் ஏற்படும் சேவை குறுக்கீடுகளைத் தவிர்க்க PDB உங்களை அனுமதிக்கிறது:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

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

இதைப் பற்றி மேலும் படிக்கலாம் இங்கே.

8. ஒரு பொதுவான கிளஸ்டரில் பல பயனர்கள் அல்லது சூழல்கள்

குபெர்னெட்டஸ் பெயர்வெளிகள் (பெயர்வெளிகள்) வலுவான காப்பு வழங்க வேண்டாம்.

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

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

9. வெளிப்புற போக்குவரத்துக் கொள்கை: கிளஸ்டர்

க்ளஸ்டருக்குள் இருக்கும் அனைத்து ட்ராஃபிக்கும் NodePort போன்ற ஒரு சேவையின் மூலம் வருவதை நாங்கள் அடிக்கடி கவனிக்கிறோம், இதற்காக இயல்புநிலை கொள்கை அமைக்கப்பட்டுள்ளது. externalTrafficPolicy: Cluster... அதற்கு அர்த்தம் நோட்போர்ட் கிளஸ்டரில் உள்ள ஒவ்வொரு முனையிலும் திறந்திருக்கும், மேலும் நீங்கள் விரும்பும் சேவையுடன் (காய்களின் தொகுப்பு) தொடர்பு கொள்ள அவற்றில் ஏதேனும் ஒன்றைப் பயன்படுத்தலாம்.

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

மறுபுறம், ஒரு குறிப்பிட்ட குபெர்னெட்ஸ் சேவையில் கொள்கைத் தொகுப்பு இருந்தால் externalTrafficPolicy: Local, பின்னர் தேவையான காய்கள் உண்மையில் இயங்கும் முனைகளில் மட்டுமே NodePort திறக்கும். மாநிலத்தை சரிபார்க்கும் வெளிப்புற சுமை சமநிலையைப் பயன்படுத்தும் போது (சுகாதார சோதனை) இறுதிப்புள்ளிகள் (அது எப்படி செய்கிறது AWS ELB), அவர் தேவையான முனைகளுக்கு மட்டுமே போக்குவரத்தை அனுப்பும், இது தாமதங்கள், கம்ப்யூட்டிங் தேவைகள், வெளியேற்ற பில்கள் (மற்றும் பொது அறிவு அதையே கட்டளையிடுகிறது) ஆகியவற்றில் நன்மை பயக்கும்.

நீங்கள் ஏற்கனவே இதுபோன்ற ஒன்றைப் பயன்படுத்துவதற்கு அதிக வாய்ப்பு உள்ளது traefik அல்லது nginx-ingress-controller ஒரு NodePort எண்ட்பாயிண்ட் (அல்லது LoadBalancer, இது NodePort ஐப் பயன்படுத்துகிறது) HTTP இன்க்ரஸ் டிராஃபிக்கை வழிநடத்துகிறது, மேலும் இந்த விருப்பத்தை அமைப்பது அத்தகைய கோரிக்கைகளுக்கான தாமதத்தை கணிசமாகக் குறைக்கும்.

В இந்த வெளியீடு வெளிப்புற போக்குவரத்துக் கொள்கை, அதன் நன்மைகள் மற்றும் தீமைகள் பற்றி மேலும் அறியலாம்.

10. கொத்துகளுடன் பிணைக்காதீர்கள் மற்றும் கட்டுப்பாட்டு விமானத்தை தவறாகப் பயன்படுத்தாதீர்கள்

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

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

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

மறுபுறம், அதைக் கையாளுவதில் நீங்கள் ஏமாற்றமடையக்கூடாது. நேரத்துடன் கட்டுப்பாட்டு அடுக்கு மெதுவாக இருக்கலாம். பெரும்பாலும், அதிக எண்ணிக்கையிலான பொருட்களைச் சுழற்றாமல் உருவாக்குவதே இதற்குக் காரணம் (இயல்புநிலை அமைப்புகளுடன் ஹெல்மைப் பயன்படுத்தும் போது ஒரு பொதுவான சூழ்நிலை, அதனால்தான் கட்டமைப்பு/ரகசியங்களில் அதன் நிலை புதுப்பிக்கப்படவில்லை - இதன் விளைவாக, ஆயிரக்கணக்கான பொருள்கள் குவிகின்றன. கட்டுப்பாட்டு அடுக்கு) அல்லது kube-api பொருள்களின் நிலையான திருத்தத்துடன் (தானியங்கு அளவிடுதல், CI/CD, கண்காணிப்பு, நிகழ்வு பதிவுகள், கட்டுப்படுத்திகள் போன்றவை).

கூடுதலாக, நிர்வகிக்கப்படும் குபெர்னெட்ஸ் வழங்குநருடனான SLA/SLO ஒப்பந்தங்களைச் சரிபார்த்து உத்தரவாதங்களுக்கு கவனம் செலுத்துமாறு பரிந்துரைக்கிறோம். விற்பனையாளர் உத்தரவாதம் அளிக்க முடியும் கட்டுப்பாட்டு அடுக்கு கிடைக்கும் (அல்லது அதன் துணைக் கூறுகள்), ஆனால் நீங்கள் அனுப்பும் கோரிக்கைகளின் p99 தாமதம் அல்ல. வேறு வார்த்தைகளில் கூறுவதானால், நீங்கள் நுழையலாம் kubectl get nodes, மற்றும் 10 நிமிடங்களுக்குப் பிறகு மட்டுமே பதிலைப் பெறுங்கள், மேலும் இது சேவை ஒப்பந்தத்தின் விதிமுறைகளை மீறுவதாக இருக்காது.

11. போனஸ்: சமீபத்திய குறிச்சொல்லைப் பயன்படுத்துதல்

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

ECR படக் குறிச்சொற்களின் மாறாத தன்மையைப் பராமரிக்கிறது; இந்த குறிப்பிடத்தக்க அம்சத்தை நீங்கள் நன்கு அறிந்திருக்குமாறு நாங்கள் பரிந்துரைக்கிறோம்.

சுருக்கம்

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

பல்வேறு அணிகளின் தோல்வி அனுபவங்களை நீங்கள் அறிந்து கொள்ளலாம் இந்த கதைகளின் தொகுப்பு ஹென்னிங் ஜேக்கப்ஸ் மூலம்.

இந்த கட்டுரையில் கொடுக்கப்பட்டுள்ள பிழைகளின் பட்டியலில் சேர்க்க விரும்புவோர் எங்களை Twitter இல் தொடர்பு கொள்ளலாம் (@மரேக்பார்டிக், @MstrsObserver).

மொழிபெயர்ப்பாளரிடமிருந்து பி.எஸ்

எங்கள் வலைப்பதிவிலும் படிக்கவும்:

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

குபெர்னெட்ஸைப் பயன்படுத்தும் போது 10 பொதுவான தவறுகள்