Про­ве­ря­ем поды:

Обнов­ля­ем label на version: "2.0", пере­де­п­ло­и­ва­ем, про­ве­ря­ем снова:

Оба пода уби­ва­ют­ся, и затем созда­ют­ся новые:

Rolling Update

С RollingUpdate всё немно­го инте­рес­нее: тут Kubernetes запус­ка­ет новые поды парал­лель­но с запу­щен­ны­ми ста­ры­ми, а затем уби­ва­ет ста­рые, и остав­ля­ет толь­ко новые. Таким обра­зом, в про­цес­се деп­лоя неко­то­рое вре­мя одно­вре­мен­но рабо­та­ют две вер­сии при­ло­же­ния — и ста­рое, и новое. Явля­ет­ся типом по-умолчанию.

При таком под­хо­де полу­ча­ем zero downtime, так как в про­цес­се обнов­ле­ния часть подов со ста­рой вер­си­ей оста­ёт­ся жива.

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

При­мер тако­го деплоймента:

Тут мы изме­ни­ли strategy.type: Recreate на type: RollingUpdate, и доба­ви­ли два опци­о­наль­ных поля, кото­рые опре­де­ля­ют пове­де­ние Деп­лой­мен­та во вре­мя выпол­не­ния обновления:

• maxUnavailable: как мно­го подов из replicas могут быть уни­что­же­ны для запус­ка новых. Может быть зада­но явно в коли­че­стве или в процентах.
• maxSurge: как мно­го подов может быть созда­но сверх зна­че­ния, задан­но­го в replicas. Может быть зада­но явно в коли­че­стве или в процентах.

В при­ме­ре выше мы зада­ли 0 в maxUnavailable, т.е. не оста­на­ли­вать запу­щен­ные поды, пока не будут созда­ны новые, и maxSurge ука­за­ли в 1, т.е. во вре­мя обнов­ле­ния дол­жен быть создан один допол­ни­тель­ный новый под, и толь­ко после того, как он перей­дёт в ста­тус Running — будет оста­нов­лен один из ста­рых подов.

Деп­ло­им с вер­си­ей 1.0:

Обнов­ля­ем вер­сию на 2.0, деп­ло­им ещё раз, и проверяем:

Полу­чи­ли один под сверх задан­но­го replicas на вре­мя обновления.

Kubernetes Canary Deployment

Тип Canary под­ра­зу­ме­ва­ет запуск новых подов одно­вре­мен­но с запу­щен­ны­ми ста­ры­ми, по ана­ло­гии с RollingUpdate, но даёт боль­ше кон­тро­ля над про­цес­сом обновления.

После запус­ка новой вер­сии при­ло­же­ния — часть запро­сов пере­клю­ча­ет­ся на неё, а часть про­дол­жа­ет исполь­зо­вать ста­рую версию.

Если с новой вер­си­ей всё хоро­шо — то остав­ши­е­ся поль­зо­ва­те­ли тоже пере­клю­ча­ют­ся на новую вер­сию, а ста­рая удаляется.

Canary тип не вклю­чён в .spec.strategy.type, но его мож­но реа­ли­зо­вать без допол­ни­тель­ных кон­трол­ле­ров меха­низ­ма­ми само­го Kubernetes.

При этом, реше­ние полу­ча­ет­ся доста­точ­но при­ми­тив­ным и слож­ным в реа­ли­за­ции и управлении.

Для того, что бы реа­ли­зо­вать Canary потре­бу­ет­ся два Deployment, в кото­рых мы зада­дим раз­ные вер­сии при­ло­же­ния, но в Service, кото­рый направ­ля­ет тра­фик к подам, исполь­зу­ем один и тот же набор labels в его selector.

Созда­ём два Deployment и Service с типом LoadBalancer.

В Deployment-1 ука­зы­ва­ем replicas=2, а для Deployment-2 — 0:

С помо­щью postStart пере­за­пи­шем зна­че­ние индекс­но­го фай­ла, что бы потом иметь воз­мож­ность уви­деть, к како­му имен­но поду мы обращаемся.

Деп­ло­им:

Про­ве­ря­ем поды:

Сей­час Service отправ­ля­ет весь тра­фик на поды из пер­во­го деплоймента:

Теперь можем обно­вить Deployment-2, задав ему replicas: 1:

Полу­ча­ем три пода с оди­на­ко­вой label app=hello-pod:

После про­вер­ки version 2.0 — мож­но уда­лить ста­рый деп­лой­мент, а новый заскей­лить до 2 подов.

Kubernetes Blue/Green Deployment

Исполь­зуя этот же меха­низм — можем реа­ли­зо­вать и ана­лог blue-green деп­лой­мен­та, когда у нас одно­вре­мен­но рабо­та­ет и ста­рая (green), и новая (blue) вер­сия, но весь тра­фик направ­ля­ет на новую, а если с ней воз­ни­ка­ют про­бле­мы — то мож­но пере­клю­чить­ся обрат­но на первую.

Для это­го в .spec.selector Сер­ви­са доба­вим выбор­ку подов пер­во­го, «green», деп­лой­мен­та , исполь­зуя label version:

Меня­ем selector на version: 2 — пере­клю­ча­ем тра­фик на blue-версию:

После того, как всё зара­бо­та­ло — уда­ля­ет­ся ста­рая вер­сия, а blue-при­ло­же­ние ста­но­вит­ся green.

При исполь­зо­ва­нии и Canary, и Blue-Green по схе­мам, опи­сан­ным выше, мы полу­ча­ем целую пач­ку про­блем — и необ­хо­ди­мость самим менеджить раз­ные Deployments, и отсле­жи­вать ста­тус новых вер­сий, ана­ли­зи­ро­вать тра­фик к новым сер­ви­сам на пред­мет оши­бок, и т.д.