Thank you for reading this post, don't forget to subscribe!

Kubernetes — это пред­на­зна­чен­ный для кон­тей­нер­ной оркест­ров­ки фрейм­ворк с откры­тым исход­ным кодом. Он был создан с уче­том бога­тей­ше­го опы­та Google в обла­сти созда­ния сред управ­ле­ния кон­тей­не­ра­ми и поз­во­ля­ет выпол­нять кон­тей­не­ри­зо­ван­ные при­ло­же­ния в гото­вом к про­мыш­лен­ной экс­плу­а­та­ции кластере.

Раз­ра­бо­тан­ный на тех же прин­ци­пах, что поз­во­ля­ет Google запус­кать мил­ли­ар­ды кон­тей­не­ров в неде­лю, Kubernetes может мас­шта­би­ро­вать­ся без уве­ли­че­ния вашей коман­ды ops.

Неза­ви­си­мо от того, тести­ру­е­те ли вы локаль­но или рабо­та­ет с PROD, гиб­кость Kubernetes рас­тет с вами, что­бы обес­пе­чить бес­пе­ре­бой­ную достав­ку ваших при­ло­же­ний неза­ви­си­мо от слож­но­сти вашей потребностей.

Kubernetes — предо­став­ля­ет вам сво­бо­ду исполь­зо­вать инфра­струк­ту­ру на местах, гибрид­ную или обще­ствен­ную облач­ную инфра­струк­ту­ру, поз­во­ляя вам лег­ко пере­ме­щать рабо­чие нагруз­ки туда, где это важно.

 

Концепции Kubernetes

• Nodes (node.md): Нода это маши­на в кла­сте­ре Kubernetes.
• Pods (pods.md): Pod это груп­па кон­тей­не­ров с общи­ми раз­де­ла­ми, запус­ка­е­мых как еди­ное целое.
• Replication Controllers (replication-controller.md): replication controller гаран­ти­ру­ет, что опре­де­лен­ное коли­че­ство «реплик» pod’ы будут запу­ще­ны в любой момент времени.
• Services (services.md): Сер­вис в Kubernetes это абстрак­ция кото­рая опре­де­ля­ет логи­че­ский объ­еди­нён­ный набор pod и поли­ти­ку досту­па к ним.
• Volumes (volumes.md): Volume(раздел) это дирек­то­рия, воз­мож­но, с дан­ны­ми в ней, кото­рая доступ­на в контейнере.
• Labels (labels.md): Label’ы это пары ключ/значение кото­рые при­креп­ля­ют­ся к объ­ек­там, напри­мер pod’ам. Label’ы могут быть исполь­зо­ва­ны для созда­ния и выбо­ра набо­ров объектов.
• Kubectl Command Line Interface (kubectl.md): kubectl интер­фейс команд­ной стро­ки для управ­ле­ния Kubernetes.

 

Архитектура Kubernetes

Рабо­та­ю­щий кла­стер Kubernetes вклю­ча­ет в себя аген­та, запу­щен­но­го на нодах (kubelet) и ком­по­нен­ты масте­ра (APIs, scheduler, etc), поверх реше­ния с рас­пре­де­лён­ным хра­ни­ли­щем. При­ве­дён­ная схе­ма пока­зы­ва­ет жела­е­мое, в конеч­ном ито­ге, состо­я­ние, хотя все ещё ведёт­ся рабо­та над неко­то­ры­ми веща­ми, напри­мер: как сде­лать так, что­бы kubelet (все ком­по­нен­ты, на самом деле) само­сто­я­тель­но запус­кал­ся в кон­тей­не­ре, что сде­ла­ет пла­ни­ров­щик на 100% подключаемым.

Нода Kubernetes

При взгля­де на архи­тек­ту­ру систе­мы мы можем раз­бить его на сер­ви­сы, кото­рые рабо­та­ют на каж­дой ноде и сер­ви­сы уров­ня управ­ле­ния кла­сте­ра. На каж­дой ноде Kubernetes запус­ка­ют­ся сер­ви­сы, необ­хо­ди­мые для управ­ле­ния нодой со сто­ро­ны масте­ра и для запус­ка при­ло­же­ний. Конеч­но, на каж­дой ноде запус­ка­ет­ся Docker. Docker обес­пе­чи­ва­ет загруз­ку обра­зов и запуск контейнеров.

Kubelet

Kubelet управ­ля­ет pod’ами их кон­тей­не­ра­ми, обра­за­ми, раз­де­ла­ми, etc.

Kube-Proxy

Так­же на каж­дой ноде запус­ка­ет­ся про­стой proxy-балан­си­ров­щик. Этот сер­вис запус­ка­ет­ся на каж­дой ноде и настра­и­ва­ет­ся в Kubernetes API. Kube-Proxy может выпол­нять про­стей­шее пере­на­прав­ле­ние пото­ков TCP и UDP (round robin) меж­ду набо­ром бэкендов.

Ком­по­нен­ты управ­ле­ния Kubernetes

Систе­ма управ­ле­ния Kubernetes раз­де­ле­на на несколь­ко ком­по­нен­тов. В дан­ный момент все они запус­ка­ют­ся на мастер-ноде, но в ско­ром вре­ме­ни это будет изме­не­но для воз­мож­но­сти созда­ния отка­зо­устой­чи­во­го кла­сте­ра. Эти ком­по­нен­ты рабо­та­ют вме­сте, что­бы обес­пе­чить еди­ное пред­став­ле­ние кластера.

etcd

Состо­я­ние масте­ра хра­нит­ся в экзем­пля­ре etcd. Это обес­пе­чи­ва­ет надёж­ное хра­не­ние кон­фи­гу­ра­ци­он­ных дан­ных и свое­вре­мен­ное опо­ве­ще­ние про­чих ком­по­нен­тов об изме­не­нии состояния.

Kubernetes API Server

Kubernetes API обес­пе­чи­ва­ет рабо­ту api-сер­ве­ра. Он пред­на­зна­чен для того, что­бы быть CRUD сер­ве­ром со встро­ен­ной биз­нес-логи­кой, реа­ли­зо­ван­ной в отдель­ных ком­по­нен­тах или в пла­ги­нах. Он, в основ­ном, обра­ба­ты­ва­ет REST опе­ра­ции, про­ве­ряя их и обнов­ляя соот­вет­ству­ю­щие объ­ек­ты в etcd (и собы­тий­но в дру­гих хранилищах).

Scheduler

Scheduler при­вя­зы­ва­ет неза­пу­щен­ные pod’ы к нодам через вызов /binding API. Scheduler под­клю­ча­ем; пла­ни­ру­ет­ся под­держ­ка мно­же­ствен­ных scheduler’ов и поль­зо­ва­тель­ских scheduler’ов.

Kubernetes Controller Manager Server

Все осталь­ные функ­ции уров­ня кла­сте­ра пред­став­ле­ны в Controller Manager. Напри­мер, ноды обна­ру­жи­ва­ют­ся, управ­ля­ют­ся и кон­тро­ли­ру­ют­ся сред­ства­ми node controller. Эта сущ­ность в ито­ге может быть раз­де­ле­на на отдель­ные ком­по­нен­ты, что­бы сде­лать их неза­ви­си­мо подключаемыми.

ReplicationController — это меха­низм, осно­вы­ва­ю­щий­ся на pod API. В конеч­ном сче­те пла­ни­ру­ет­ся пере­ве­сти её на общий меха­низм plug-in, когда он будет реализован.

 

Сеть в kubernetes

Flannel — сете­вой овер­лей, кото­рый поз­во­лит кон­тей­не­рам свя­зы­вать­ся через несколь­ко хостов.

Calico — это систе­ма с откры­тым исход­ным кодом, обес­пе­чи­ва­ю­щая вза­и­мо­дей­ствие с облач­ны­ми при­ло­же­ни­я­ми и политикой.

Canal — это ини­ци­а­ти­ва, осно­ван­ная на сооб­ще­ствах, кото­рая поз­во­ля­ет поль­зо­ва­те­лям лег­ко раз­вер­ты­вать сети Calico и flannel вме­сте (как еди­ное сете­вое реше­ние), соче­та­ю­щее в себе веду­щие в отрас­ли сете­вые поли­ти­ки Calico с бога­тым набо­ром опций Calico и флан­це­во­го нало­же­ния и опци­я­ми без под­клю­че­ния к сети.

Kube-route — постро­ен вокруг кон­цеп­ции наблю­да­те­лей и кон­трол­ле­ров. Наблю­да­те­ли исполь­зу­ют API-интер­фейс Kubernetes для полу­че­ния уве­дом­ле­ний о собы­ти­ях, свя­зан­ных с созда­ни­ем, обнов­ле­ни­ем и уда­ле­ни­ем объ­ек­тов Kubernetes. Каж­дый наблю­да­тель полу­ча­ет уве­дом­ле­ние, отно­ся­ще­е­ся к опре­де­лен­но­му объ­ек­ту API. При полу­че­нии собы­тия от сер­ве­ра API наблю­да­тель пере­да­ет собы­тия. Кон­трол­лер реги­стри­ру­ет­ся, что­бы полу­чать обнов­ле­ния от наблю­да­те­лей и дей­ство­вать на события.

Romana — это реше­ние для авто­ма­ти­за­ции сетей и без­опас­но­сти для облач­ных при­ло­же­ний. Romana авто­ма­ти­зи­ру­ет созда­ние изо­ли­ро­ван­ных облач­ных сетей, защи­ща­ет при­ло­же­ния, исполь­зу­ю­щие мик­ро­сег­мен­та­цию, и при­ме­ня­ет поли­ти­ки кон­тро­ля досту­па на всех конеч­ных точ­ках, где бы они ни запускались.

Weave Net — еще одно реше­ние для реа­ли­за­ции сети в Kubernetes с под­держ­кой CNI.

 

Kubernetes мож­но уста­но­вить и раз­вер­нуть, исполь­зуя сле­ду­ю­щие методы:

• Minikube (это еди­нич­ный кла­стер — single node kubernetes cluster).
• Kops (настрой­ка несколь­ких сер­ве­ров (Multi node kubernetes) в AWS)
• Kubeadm (кла­стер Multi Node в наших соб­ствен­ных помещениях)

 

Терминология

• Pods - мини­маль­ная сущ­ность (юнит) для раз­вер­ты­ва­ния в кластере;
• ReplicaSets (ранее Replication Controller) - гаран­ти­ру­ет, что в опре­де­лен­ный момент вре­ме­ни будет запу­ще­но нуж­но кол-во контейнеров;
• Deployments - обес­пе­чи­ва­ет декла­ра­тив­ные (declarative) обнов­ле­ния для Pods и ReplicaSets;
• StatefulSets - исполь­зу­ет­ся для управ­ле­ния при­ло­же­ни­я­ми с сохра­не­ни­ем состояния;
• DaemonSet - гаран­ти­ру­ет, что опре­де­лен­ный под будет запу­щен на всех (или неко­то­рых) нодах;
• Jobs (в том чис­ле CronJob) - созда­ет один (или несколь­ко) подов и гаран­ти­ру­ет, что после выпол­не­ния коман­ды они будут успеш­но завер­ше­ны (terminated);
• Labels and Selectors - пары ключ/значение, кото­рые при­сва­и­ва­ют­ся объ­ек­там (напри­мер, подам). С помо­щью селек­то­ров поль­зо­ва­тель может иден­ти­фи­ци­ро­вать объект;
• Namespaces - вир­ту­аль­ные кла­сте­ры раз­ме­щен­ные поверх физического;
• Services - абстрак­ция, кото­рая опре­де­ля­ет логи­че­ский набор подов и поли­ти­ку досту­па к ним;
• Annotations - добав­ле­ние про­из­воль­ных неиден­ти­фи­ци­ру­ю­щих мета­дан­ных к объектам;
• ConfigMaps - поз­во­ля­ет пере­опре­де­лить кон­фи­гу­ра­цию запус­ка­е­мых подов;
• Secrets - исполь­зу­ют­ся для хра­не­ния кон­фи­ден­ци­аль­ной инфор­ма­ции (паро­ли, токе­ны, ssh-ключи).