Интернетте көптөгөн маалымдама адабияттар бар, бирок кээде эң жөнөкөй кеңеш эң баалуу болуп саналат. Команда которулду , Макаланын автору Кубернетес менен бир жыл иштегенден кийин чогулткан. Кеңештер маанилүүлүгү боюнча иргелбейт, бирок ар бир адам өзү үчүн пайдалуу нерсе табат деп ойлойбуз.
Kubernetes менен иштөө үчүн эң жөнөкөй буйрук
Баштоо үчүн, Kubernetes менен иштөөдөгү эң жөнөкөй жана пайдалуу иш. Төмөнкү буйрук буйрукту аяктоого мүмкүндүк берет kubectl bash кабыгында:
echo "source <(kubectl completion bash)" >> ~/.bashrc
Автотолтуруу kubectl .bashrc файлына жазылат жана кабык башталган сайын автоматтык түрдө иштетилет. Бул сыяктуу узун буйруктарды жана параметрлерди терүүнү тездетет all-namespaces. Кененирээк бөлүмдөн окуңуз .
Аттар мейкиндигинде демейки эстутум жана CPU чектөөлөрү
Эгерде тиркеме туура эмес жазылган болсо, мисалы, ал ар бир секунд сайын маалымат базасына жаңы туташууну ачат, бирок аны эч качан жаппайт, анда кластерде эс тутумдун агып кетиши бар. Ал эми колдонууда орнотуу учурунда эстутум чеги жок болсо, бул түйүн иштебей калышына алып келиши мүмкүн.
Мунун алдын алуу үчүн, Kubernetes ар бир ат мейкиндигинде демейки чектөөлөрдү коюуга мүмкүндүк берет. Алар белгилүү бир аттар мейкиндиги үчүн yaml файлында жазылган. Мына ушундай файлдын мисалы:
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256Mi
type: Container
Мындай ямл түзүп, каалаган аттар мейкиндигине колдонуңуз. Мисалы, аттар мейкиндигине limit-example. Эми бул аталыш мейкиндигинде жайгаштырылган ар бир контейнерде 512Mi чеги болот, эгерде бул контейнер үчүн кошумча башка жеке чек коюлбаса.
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 жана андан кийинки версияларда бул желек демейки боюнча коюлган. Бирок, мурунку версиялар инод чегин көзөмөлдөбөйт.
Minikube... кичинекей, бирок күчтүү жергиликтүү Kubernetes
Minikube жергиликтүү Kubernetes кластерин иштетүүнүн эң оңой жолу. Ал жөнөкөй буйрук менен ишке киргизилет:
minikube start
Бул буйрукту иштетүү сиздин машинаңызда чыныгы Kubernetes кластерине алып келет.
Колдонмону кантип түзүү жана аны ошол кластерде локалдык түрдө иштетүү амалы. Атайын көрсөтмө берилбесе, Docker сүрөтү кластерде эмес, компьютериңизде түзүлөт.
Докерди сүрөттү жергиликтүү Kubernetes кластерине түртүүгө мажбурлоо үчүн, докер машинасына төмөнкү буйрук берилет:
eval $(minikube docker-env)
Эми биз жергиликтүү Kubernetes кластеринде тиркемелерди кура алабыз.
kubectl'ге баарына мүмкүнчүлүк бербеңиз
Бул ачык көрүнөт, бирок бир нече командалар өздөрүнүн тиркемелери үчүн бир кластерди колдонушса (Кубернетес эмне үчүн түзүлгөн), сиз баарына эле бербешиңиз керек. kubectl. Буйруктарды бөлүү, алардын ар бирине өзүнүн аталыш мейкиндигин дайындоо жана RBAC саясатын колдонуу менен кирүү мүмкүнчүлүгүн чектөө жакшыраак.
Ар бир поддон үчүн кирүү, окуу, түзүү, жок кылуу жана башка операцияларга укуктарды берүү менен чаташтырсаңыз болот. Бирок эң негизгиси, сырларга кирүү мүмкүнчүлүгүн чектөө, ага администраторлорго гана уруксат берүү. Ушундай жол менен биз кластерди башкара алгандар менен ага жөн эле жайгаштыра алгандарды айырмалайбыз.
Под бюджеттерин башкаруу
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, анда бул PDB биринчисине гана колдонулат.
параметр minAvailable түйүндү бошотууда (тазалоодо) эске алынат. Мисалы, биздин мисалда, бошотуу учурунда бардык инстанциялар чыгарылат app: app-a, экиден башка.
Бул каалаган убакта колдонмонун канча нускасы иштеши керектигин көзөмөлдөөгө мүмкүндүк берет.
Колдонмонун ден соолугуна мониторинг
Мындай мониторинг эки жол менен мүмкүн: Даярдык же Жашоо тесттерин колдонуу.
Биринчи зонд (даярдык) контейнердин трафикти кабыл алууга даярдыгын аныктайт.
Экинчиси (жануулугу) контейнердин ден соолугун же кайра иштетүү керектигин көрсөтөт.
Тиешелүү конфигурациялар жайылтуу үчүн ямлга жөн гана кошулат. Ал жерден сиз тайм-ауттарды, кечигүү убакыттарын жана кайра сыноолордун санын көрсөтө аласыз. Алар жөнүндө көбүрөөк маалымат караңыз .
Тегдер бардык жерде
Энбелгилер Кубернетестеги негизги түшүнүктөрдүн бири. Алар объекттердин бири-бири менен эркин баарлашуусуна, ошондой эле энбелгилердин негизинде суроо-талаптарды түзүүгө мүмкүндүк берет. Kubernetesте сиз кардарга барып, белгилүү бир тегдер үчүн окуяларды көрө аласыз.
Тегдер менен дээрлик бардыгын жасай аласыз, бирок бир эле кластерде программаларды иштетүү үчүн бир нече чөйрөнү түзүү жакшы мисал болот.
Сиз ошол эле кластерди колдоносуз дейли dev и qa. Бул сизде колдонмо болушу мүмкүн дегенди билдирет app-a, бир эле учурда эки чөйрөдө иштешет qa и dev. Бул учурда, биз тиешелүү параметрди көрсөтүү менен белгилүү бир чөйрөдө колдонмо инстанциясына өзүнчө кире алабыз environment. Мисалы, app: app-a и environment: dev бир чөйрө үчүн, жана app: app-a и environment: qa экинчиси үчүн.
Бул колдонмонун эки инстанциясына кирүү мүмкүнчүлүгүн берет, мисалы, бир эле учурда тестирлөө жүргүзүү.
Нерселерди иретке келтирүү
Kubernetes абдан күчтүү система, бирок ар кандай система акыры өтө көп процесстерге батып калышы мүмкүн. Kubelet сиз көрсөткөн бардык процесстерди жана текшерүүлөрдү жүргүзөт, ошондой эле өзүнүн.
Албетте, бир жетим кызмат системаны жайлата албайт жана Kubernetes башынан масштабга ылайыкталган. Бирок бир кызматтын ордуна миллион пайда болсо, кубелет мууна баштайт.
Эгер кандайдыр бир себептерден улам сиз жайгаштырууну жок кылсаңыз (контейнер, сүрөт, эмнеси болсо да), жөн гана толук тазалоону унутпаңыз.
Go
Негизги кеңешти акыркыга сактап койдук. Go программалоо тилин үйрөнүңүз.
Kubernetes Go'до иштелип чыккан, бардык кеңейтүүлөр Go'до жазылган жана клиент-go кардарлар китепканасы да расмий түрдө колдоого алынат.
Бул ар кандай жана кызыктуу нерселер үчүн колдонулушу мүмкүн. Мисалы, Kubernetes системасын сиздин табитиңизге жараша кеңейтүү. Ошентип, маалыматтарды чогултуу, тиркемелерди жайылтуу же жөн гана контейнерлерди тазалоо үчүн өз программаларыңызды колдоно аласыз.
Go программалоо тилин үйрөнүү жана Client-go-ну өздөштүрүү - бул Kubernetesтин жаңы колдонуучуларына бере турган эң маанилүү кеңеш.
Дагы эмне окуш керек:
- .
- ?
- .
Source: www.habr.com