Комментарии 8
В настоящий момент мы ставим на новые кластера 1.11 и обновляем все существующие тоже до 1.11. На глаз: примерно половина на 1.11 и вторая половина на 1.10 и 1.9. С одной стороны – все норм и все работает, поэтому не форсируем, с другой стороны – есть очень большая пачка расширенных фич, которые мы не можем использовать и это нас очень расстраивает (например, ipvs и kubelet dynamic config мы до сих пор не можем использовать, ну и куча еще всего).
Однако, мы решили форсировать этот вопрос и прямо сейчас готовим обновление 1.11 -> 1.13 (за одну операцию через две версии, там есть нюансы, но в целом так можно), должны закончить на этой неделе. И на следующей будем делать обновление 1.13 -> 1.15. Под "делать обновление" в нашем случае подразумевается проработка на тестовых стендах и подготовка инструкций для наших DevOps-команд. Сейчас мы поддерживаем три способа инсталляции: kubeadm (bare metal и все виды простых VM), kops (AWS, GCE) и aks (Azure).
В целом, буквально через несколько недель, планируем выйти на следующую политику:
- Не позднее чем через месяц после релиза мы должны:
- ставить новые кластера уже на эту версию,
- иметь возможность обновить любой из существующих кластеров на эту версию.
- Мы поддерживаем кластера не более чем трех последних версий (с выходом 1.15 это будут 1.12, 1.13 и 1.14) и если кластер старше – мы форсируем обновление (даже если фичи не нужны – все равно требуется обновление).
Плюс, скорей всего придем к тому, что для нечетных версий будем готовить обновление через одну версию, чтобы там, где не нужны фичи можно было обновляться в два раза реже.
ExecutionHookController, я так понимаю он похож по функционалу на ваш AddonOperator?
Kubernetes 1.15: обзор основных новшеств