kubernetes. Различия в Replication Controller, Replica Set и Deployments - теория

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

Kubernetes преду­смат­ри­ва­ет управ­ле­ние несколь­ки­ми экзем­пля­ра­ми (репли­ка­ми) кон­тей­не­ров. На сего­дняш­ний день суще­ству­ет несколь­ко спо­со­бов орга­ни­за­ции репли­ка­ции - в дан­ной ста­тье мы рас­смот­рим три вари­ан­та: Replication ControllersReplica Sets и Deployments.

Преж­де все­го, нуж­но знать зачем нуж­на репли­ка­ция кон­тей­не­ров в кла­сте­ре Kubernetes. Чаще все­го, это нуж­но для:

  • надеж­но­сти. C несколь­ки­ми экзем­пля­ра­ми при­ло­же­ния вы избав­ля­е­тесь от про­блем в слу­чае отка­за одно­го (или несколь­ких) из них;
  • балан­си­ров­ки. Нали­чие несколь­ких экзем­пля­ров при­ло­же­ния поз­во­ля­ет рас­пре­де­лять траф­фик меж­ду ними, предот­вра­щая пере­груз­ку одно­го инстан­са (под / кон­тей­нер) или ноды;
  • мас­шта­би­ро­ва­ния. При воз­рас­та­ю­щей нагруз­ке на уже суще­ству­ю­щие экзем­пля­ры при­ло­же­ния Kubernetes поз­во­ля­ет лег­ко уве­ли­чи­вать коли­че­ство реплик по необходимости.

Репли­ка­ция так­же хоро­шо под­хо­дит в слу­чае рабо­ты с мик­ро­сер­ви­са­ми, облач­ны­ми (cloud-native) и мобиль­ны­ми приложениями.

Replication Controller - тра­ди­ци­он­ный (изна­чаль­ный) спо­соб орга­ни­за­ции репли­ка­ции в кла­сте­ре Kubernetes. В дан­ный момент он заме­ня­ет­ся более “све­жим” вари­ан­том - Replica Sets, но не будет лиш­ним понять, что это и как работает.

С помо­щью объ­ек­та Replication Controller мож­но создать несколь­ко экзем­пля­ров подов и отсле­жи­вать их состо­я­ние. Если один (или несколь­ко) подов завер­ша­ют­ся с ошиб­кой, то кон­трол­лер создаст и запу­стит новый экзем­пляр (что­бы коли­че­ство подов все­гда соот­вет­ство­ва­ло жела­е­мо­му). Кро­ме того, Replication Controller предо­став­ля­ет воз­мож­ность мас­шта­би­ро­ва­ния подов.

Созда­дим файл rc.yaml сле­ду­ю­ще­го содержания:

Далее созда­дим объ­ект Replication Controller в кла­сте­ре на осно­ве опи­са­ния выше:

Полу­чим деталь­ное опи­са­ние создан­но­го объекта:

Как вид­но, все три репли­ки запу­ще­ны (ожи­да­е­мо). Уви­деть состо­я­ние подов мож­но с помо­щью команды:

Перед рас­смот­ре­ни­ем Replica Sets “уби­ра­ем” за собой:

Как мы уже ранее гово­ри­ли, Replica Sets - это более совре­мен­ная вер­сия все того же Replication Controller, кото­рая отли­ча­ет­ся под­держ­кой мно­же­ствен­но­го выбо­ра в селек­то­ре. Созда­дим файл rs.yaml с таким содержимым:

Здесь все прак­ти­че­ски то же самое, что и в опи­са­нии Replication Controller, за исклю­че­ни­ем того, что мы исполь­зу­ем matchLabels. Но мож­но пой­ти даль­ше и заме­нить сек­цию matchLabels на такую:

Созда­ем объ­ект в кла­сте­ре командой:

Смот­рим описание:

Как видим, Replica Sets дей­стви­тель­но очень похо­жа не Replication Controller. Еще одно важ­ное отли­чие, о кото­ром мы не упо­мя­ну­ли - коман­да rolling-update будет рабо­тать для Replication Controller, но не для Replica Sets.

Уби­ра­ем” за собой:

Вари­ант репли­ка­ции подов с исполь­зо­ва­ни­ем объ­ек­та Deployment - еще более высо­кий уро­вень абстрак­ции. На самом деле, под капо­том, Deployment будет само­сто­я­тель­но созда­вать необ­хо­ди­мые Replica Sets (сле­до­ва­тель­но, предо­став­лять тот же функ­ци­о­нал, но с воз­мож­но­стью rolling-update/rollback).

Созда­дим файл deployment.yaml сле­ду­ю­ще­го содержания:

Запус­ка­ем объ­ект в кластере:

Про­смотр деталей: