Ինտերնետում շատ տեղեկատու գրականություն կա, բայց երբեմն ամենապարզ խորհուրդն ամենաարժեքավորն է։ Թիմ թարգմանված , որը հոդվածի հեղինակը հավաքել է Kubernetes-ի հետ մեկ տարի աշխատելուց հետո։ Խորհուրդները դասավորված չեն ըստ կարևորության, բայց կարծում ենք, որ յուրաքանչյուրն իր համար օգտակար բան կգտնի։
Kubernetes-ի հետ աշխատելու ամենապարզ հրամանը
Սկսելու համար, թերևս ամենապարզ և օգտակար գործողությունը Kubernetes-ի հետ աշխատելիս: Հետևյալ հրամանը հնարավորություն է տալիս հրամանի ավարտը kubectl bash shell-ում:
echo "source <(kubectl completion bash)" >> ~/.bashrc
Ինքնալրացում kubectl կգրվի .bashrc ֆայլում և ավտոմատ կերպով կակտիվանա ամեն անգամ, երբ shell-ը գործարկվի: Սա արագացնում է երկար հրամանների և պարամետրերի մուտքագրումը, ինչպիսիք են all-namespaces. Կարդալ ավելին .
Լռելյայն հիշողության և պրոցեսորի սահմանափակումները անունների տարածքում
Եթե հավելվածը սխալ է գրված, օրինակ, ամեն վայրկյան նոր կապ է բացում տվյալների բազայի հետ, բայց երբեք չի փակում այն, ապա կլաստերը հիշողության արտահոսք ունի։ Եվ եթե հավելվածը տեղակայման ժամանակ չունի հիշողության սահմանաչափ, դա կարող է հանգեցնել հանգույցի ձախողման:
Դա կանխելու համար Kubernetes-ը թույլ է տալիս սահմանել լռելյայն սահմանափակումներ՝ ըստ անվանական տարածքի: Դրանք գրված են yaml ֆայլում որոշակի անվանատարածքի համար: Ահա այսպիսի ֆայլի օրինակ.
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256Mi
type: Container
Ստեղծեք այդպիսի yaml և կիրառեք ցանկացած անվանական տարածք: Օրինակ՝ դեպի անվանատարածք limit-example. Այժմ այս անվանատարածքում տեղակայված ցանկացած կոնտեյներ կունենա 512 Mi-ի սահմանաչափ, եթե այս կոնտեյների համար լրացուցիչ սահմանված չէ մեկ այլ անհատական սահման:
Աղբահանություն Kubernetes-ի հին տարբերակներում
Kubelet-ը լռելյայն սկսում է աղբահանությունը, երբ var/lib/docker զբաղեցնում է սկավառակի հասանելի տարածության 90%-ը: Սա հիանալի է, սակայն, մինչև Kubernetes 1.7-ը, չկար օգտագործված ինոդների քանակի լռելյայն սահմանափակում, որոնք համապատասխանում են ֆայլային համակարգի ֆայլերի քանակին:
Հնարավոր է ձեր կոնտեյները var/lib/docker կարող է օգտագործել սկավառակի տարածության միայն 50%-ը, բայց կարող է սպառվել ինոդների, ինչը խնդիրներ կառաջացնի աշխատողների համար:
Kubelet-ի հին տարբերակներում 1.4-ից 1.6-ը դուք պետք է ավելացնեք այս դրոշը.
--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%
1.7 և ավելի ուշ տարբերակներում այս դրոշը սահմանված է լռելյայն: Այնուամենայնիվ, նախորդ տարբերակները չեն վերահսկում inode-ի սահմանաչափը:
Minikube... փոքր, բայց հզոր տեղական Kubernetes
Minikube-ն տեղական Kubernetes կլաստերը գործարկելու ամենադյուրին ճանապարհն է: Այն գործարկվում է պարզ հրամանով.
minikube start
Այս հրամանի գործարկումը հանգեցնում է իրական Kubernetes կլաստերի, որն աշխատում է ձեր համակարգչում:
Հնարքն այն է, թե ինչպես կարելի է ստեղծել հավելվածը և գործարկել այն լոկալ այդ կլաստերի վրա: Եթե հատուկ հրահանգ չկա, Docker պատկերը կկառուցվի ձեր համակարգչում, այլ ոչ թե կլաստերի վրա:
Docker-ին ստիպելու համար պատկերը մղել տեղական Kubernetes կլաստերին, դոկերի մեքենային տրվում է հետևյալ հրամանը.
eval $(minikube docker-env)
Այժմ մենք կարող ենք հավելվածներ ստեղծել տեղական Kubernetes կլաստերի վրա:
Kubectl-ին հասանելիություն մի տվեք բոլորին
Սա ակնհայտ է թվում, բայց եթե մի քանի թիմեր օգտագործում են նույն կլաստերը իրենց հավելվածների համար (ինչի համար ստեղծվել է Kubernetes-ը), դուք չպետք է պարզապես բոլորին տալ kubectl. Ավելի լավ է բաժանել հրամանները՝ դրանցից յուրաքանչյուրին հատկացնելով իր սեփական անվանատարածքը և սահմանափակելով մուտքը՝ օգտագործելով RBAC քաղաքականությունը:
Դուք կարող եք շփոթվել՝ յուրաքանչյուր pod-ի համար մուտք գործելու, կարդալու, ստեղծելու, ջնջելու և այլ գործողություններ վերագրելով: Բայց գլխավորը գաղտնիքների հասանելիությունը սահմանափակելն է՝ դա թույլ տալով միայն ադմինիստրատորներին: Այս կերպ մենք կտարբերակենք նրանց, ովքեր կարող են կառավարել կլաստերը և նրանց, ովքեր կարող են պարզապես տեղակայվել դրան:
Կառավարեք Pod-ի բյուջեները
Ինչպե՞ս ապահովել Kubernetes կլաստերի հավելվածի համար ոչ մի ընդհատում: PodDisruptionBudget և կրկին PodDisruptionBudget:
Կլաստերները պարբերաբար թարմացվում են, իսկ հանգույցները դատարկվում են: Ոչինչ կանգուն չէ, սա է իրականությունը։ Մեկից ավելի օրինակներով յուրաքանչյուր տեղակայում պետք է ներառի PDB (PodDisruptionBudget): Այն ստեղծվում է պարզ yaml ֆայլում, որը կիրառվում է կլաստերի վրա: Որոշակի PDB-ի ծածկույթի տարածքը որոշվում է պիտակների ընտրիչներով:
Նշում: ՊԱԾ բյուջեն հաշվի է առնվում միայն այն դեպքում, երբ բյուջեի խախտումը շրջելի է () Սարքավորումների խափանումների նման իրավիճակներում PDB-ն չի աշխատի:
Օրինակ PDB:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: app-a-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: app-a
Երկու հիմնական պարամետրերն են matchLabels и minAvailable. Առաջին պարամետրը սահմանում է, թե որ ծրագրերին է վերաբերում բյուջեն: Օրինակ, եթե ես տեղակայումներ ունեմ պիտակներով app: app-a и app: app-b, ապա այս ՊՏԲ-ն կկիրառվի միայն առաջինի վրա:
Parameter minAvailable հաշվի է առնվում հանգույցը դատարկելիս (մաքրելիս): Օրինակ մեր օրինակում դատարկման ժամանակ բոլոր ատյանները վտարվում են app: app-a, բացառությամբ երկուսի.
Սա թույլ է տալիս վերահսկել, թե հավելվածի քանի օրինակ պետք է գործարկվի տվյալ պահին:
Դիմումի առողջության մոնիտորինգ
Նման մոնիտորինգը հնարավոր է երկու եղանակով՝ օգտագործելով պատրաստակամություն կամ աշխուժություն:
Առաջին զոնդը (պատրաստվածությունը) որոշում է բեռնարկղի պատրաստակամությունը տրաֆիկ ընդունելու համար:
Երկրորդը (աշխուժությունը) ցույց է տալիս, թե արդյոք կոնտեյները առողջ է, թե պետք է վերագործարկվի:
Համապատասխան կոնֆիգուրացիաները պարզապես ավելացվում են yaml-ին՝ տեղակայման համար: Այնտեղ կարող եք նշել ժամկետների, հետաձգման ժամանակների և կրկնակի փորձարկումների քանակը: Տեսեք նրանց մասին ավելի մանրամասն .
Պիտակներն ամենուր են
Պիտակները Kubernetes-ի հիմնարար հասկացություններից են: Նրանք թույլ են տալիս օբյեկտներին ազատորեն շփվել միմյանց հետ, ինչպես նաև ստեղծել հարցումներ՝ հիմնված պիտակների վրա: Kubernetes-ում դուք նույնիսկ կարող եք գնալ հաճախորդի մոտ և դիտել իրադարձություններ հատուկ պիտակների համար:
Դուք կարող եք գրեթե ամեն ինչ անել պիտակներով, բայց լավ օրինակ կարող է լինել մի քանի միջավայրերի ստեղծում՝ նույն կլաստերի վրա ծրագրեր գործարկելու համար:
Ենթադրենք, դուք օգտագործում եք նույն կլաստերը dev и qa. Սա նշանակում է, որ դուք կարող եք ունենալ դիմում app-a, միաժամանակ աշխատելով երկու միջավայրերում qa и dev. Այս դեպքում մենք կարող ենք առանձին մուտք գործել հավելվածի օրինակ կոնկրետ միջավայրում՝ նշելով համապատասխան պարամետրը environment. Օրինակ, app: app-a и environment: dev մեկ միջավայրի համար, և app: app-a и environment: qa երկրորդի համար։
Սա թույլ է տալիս մուտք գործել հավելվածի երկու օրինակ, օրինակ՝ միաժամանակ թեստավորում անցկացնելու համար:
Կազմակերպվեք
Kubernetes-ը շատ հզոր համակարգ է, բայց ցանկացած համակարգ, ի վերջո, կարող է խճճվել չափազանց շատ գործընթացներով: Kubelet-ն իրականացնում է ձեր նշած բոլոր գործընթացները և ստուգումները, ինչպես նաև իր սեփականը:
Իհարկե, մեկ ծնողազուրկ ծառայությունը չի դանդաղեցնի համակարգը, և Kubernetes-ը նախագծված է ի սկզբանե մեծացնելու համար: Բայց եթե մեկ ծառայության փոխարեն հայտնվի միլիոնը, կուբելեթը սկսում է խեղդվել։
Եթե ինչ-ինչ պատճառներով ջնջեք տեղակայումը (կոնտեյներ, պատկեր, ինչ էլ որ լինի), պարզապես համոզվեք, որ կատարեք ամբողջական մաքրում:
Հանդիպեք Գոյին
Հիմնական խորհուրդը պահեցինք վերջում։ Սովորեք Go ծրագրավորման լեզուն:
Kubernetes-ը մշակված է Go-ում, բոլոր ընդլայնումները գրված են Go-ում, և հաճախորդ-go հաճախորդների գրադարանը նույնպես պաշտոնապես աջակցվում է:
Այն կարող է օգտագործվել տարբեր և հետաքրքիր բաների համար։ Օրինակ՝ ընդլայնել Kubernetes համակարգը ձեր ճաշակով։ Այսպիսով, դուք կարող եք օգտագործել ձեր սեփական ծրագրերը՝ տվյալներ հավաքելու, հավելվածներ տեղակայելու կամ պարզապես բեռնարկղերը մաքրելու համար:
Go ծրագրավորման լեզուն սովորելը և client-go-ի յուրացումը թերևս ամենակարևոր խորհուրդն է, որը կարող եք տալ Kubernetes-ի նոր օգտատերերին:
Էլ ի՞նչ կարդալ:
- .
- ?
- .
Source: www.habr.com