Комментарии 25
Однако запрет на отвод глаз и разминка висков или лба это конечно сильно…
Зависит от проктора. Я всё собираюсь написать про сдачу LFCS, там схожие требования. Я просто закрывал глаза и втыкал их тогда в потолок «на подумать». Вообще проктор, если вы несколько раз смотрите в одну и ту же сторону просто попросит вас показать камерой что там у вас. Каких-то проблем с «прикрыть глаза и помассировать их руками недолго» я тоже не замечал. Я вообще с проктором столкнулся только на этапе «похлопайте в ладоши», потому как немного видимо занизил звук на камере, чтобы не мешал фоновый шум за окном.
Всё по типу Red Hat из архитекторской линейки. Весьма годная тенденция проведения экзамена — почти face2face, хотя и весьма дорогая из-за этого. Сам готовлюсь к Ansible (EX470) и скоро узнаю все прелести «не закрывай лицо» и «в туалет только по разрешению». Судя по отзывам это будет присутствовать.
Половина вещей в статусе альф-бета (немного утрирую конечно), но сертификация уже есть. Я к тому, что поменятся могут даже достаточно основные функции.
Конечно, утрируете… и с какой целью? Kubernetes — система, готовая для использования в production. Да, она молода и развивается сильно активнее (=меняется чаще и больше), чем, скажем, какой-нибудь Linux-дистрибутив enterprise-класса. Однако можно подумать, что в новых крупных релизах RHEL никогда не меняются даже основные функции и поэтому по нему тоже нельзя сертифицировать.
Ок, все конечно субьективно. Я смотрел на оригинальный Ингресс в начале этого года (январь 2018), мне нужно было изменять анотации github.com/kubernetes/ingress-nginx/blob/nginx-0.9.0/docs/user-guide/annotations.md и была только бета-ветка. Потом, (июнь-июль) я увидел уже другую доку по иному адресу github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md, где анотации уже другие: старые не работают, но и очевидных проблем к8с не показывает при применении старых yaml-ов. Да, они прямо писали, что Ингресс не полностью зрелый и все может измениться. Но блин, эта тема стоит в списке сертификации.
> Однако можно подумать, что в новых крупных релизах RHEL никогда не меняются даже основные функции и поэтому по нему тоже нельзя сертифицировать.
Да, но как часто выходят новые релизы RHEL? Например RHEL 6 сапортится с 2011 до ~2025, что демонстрирует зрелость продукта. А Куберентис релизят раз в квартал, часто переписывают/кардинально изменяют подсистемы (CoreDNS, CRI, IPVS т.д.). Не уверен, что в сертификации для него вообще есть большой смысл. Разве что шилдик для сотрудников компании, которые предоставляют услуги на К8с (и это не значит, что это плохо).
> Однако можно подумать, что в новых крупных релизах RHEL никогда не меняются даже основные функции и поэтому по нему тоже нельзя сертифицировать.
Да, но как часто выходят новые релизы RHEL? Например RHEL 6 сапортится с 2011 до ~2025, что демонстрирует зрелость продукта. А Куберентис релизят раз в квартал, часто переписывают/кардинально изменяют подсистемы (CoreDNS, CRI, IPVS т.д.). Не уверен, что в сертификации для него вообще есть большой смысл. Разве что шилдик для сотрудников компании, которые предоставляют услуги на К8с (и это не значит, что это плохо).
Смущает новый префикс? Нас тоже, потому что много внутренних обвязок на старый были завязаны. Нам помогла CLI опция : --annotations-prefix ingress.kubernetes.io
А какой срок действия сертификата? Есть ли что то подобное как у RedHat, например, если получил CentOS5, то с выходом 7ки твой сертификат уже не действителен?
На данный момент у CKA написано (упомянутый agreement, пункт «3.2 Certification Period») вот так:
Certifications expire 24 months from the date that the Program certification requirements are met by a candidate. Candidates must meet Certification renewal requirements prior to the expiration date of their certification in order to maintain active certification. If Certification renewal requirements are not met before the expiration date, Certification will be deemed revoked without further action by The Linux Foundation and this Agreement shall terminate effective as of the expiration date, subject to the provisions of Section 12.3.
«суммарно потратил 8 часов.» Всегда удивлялся способностям таких людей. Это уникумы!!! У меня на подготовку к подобному экзамену ушло бы минимум полгода. К примеру, к RHCE (ex300) я готовился около года, и то кое-как получилось сдать со 2-й попытки, первая попытка была «разведка боем». Отсутствие технологий в моём продакшне + сложность экзаменов дает о себе знать (((((. Спасает только упорство и желание развиваться.
«Отсутствие технологий в моём продакшне» — да, это явный ключ. В нашем случае сдавали люди с реальным опытом работы с Kubernetes. Впрочем, и другой вариант у нас тоже приведен:
«В сети нам попался радикально другой пример специалиста, который купил курс подготовки к экзамену от The Linux Foundation и потратил на всё это около 4-5 недель».
Подскажите, если, допустим у меня практический опыт в том же самом Kubernetes нулевой, но экзамен сдан (опять же благодаря упёртости и энтузиазму) — может ли это быть плюсом в поиске работы в DevOps? Или же всё индивидуально?
… К предыдущему моему комментарию — если взять Вас, как работодателя — рассматривали бы Вы такого кандидата?
Во многом всё индивидуально, т.к. к нам регулярно приходят люди без опыта в Kubernetes, а уже внутри мы их «прокачиваем». Если мы ищем с каким-то конкретным навыком (например, Kubernetes), то реальный опыт важнее сертификатов. Но если такое требование не является обязательным, то и сертификат без опыта, конечно, тоже будет плюсом.
Растолкуйте, пожалуйста, почему вокруг такое большое внимание к Kubernetes, и такое маленькое к OpenShift? (Под вниманием понимаю количество статей, конференций, описаний опыта получения сертификатов и т. п.)
Основной ответ на этот вопрос на поверхности: сравните объём внимания к Linux и конкретно к RHEL… Потому что Kubernetes — это основа и как бы umbrella для всех появляющихся вендорских дистрибутивов. Поэтому всё общее внимание (включая мероприятия, статьи и т.п.) поддерживаются и Red Hat, и Google, и всеми другими вендорами (да ещё и сторонними энтузиастами-компаниями, которые за upstream). А вся движуха вокруг OpenShift может быть только от Red Hat (ну, и некоторых её партнёров — только не самых крупных, а таких, у которых ещё нет собственных дистрибутивов).
И дополнительный ответ уже больше с «личной» стороны: мы не любим vendor lock-in и клиентам такое предлагать по умолчанию не будем (хотя и можем взяться за обслуживание, если у них есть собственные основания делать именно и только так).
И дополнительный ответ уже больше с «личной» стороны: мы не любим vendor lock-in и клиентам такое предлагать по умолчанию не будем (хотя и можем взяться за обслуживание, если у них есть собственные основания делать именно и только так).
> мы не любим vendor lock-in и клиентам такое предлагать по умолчанию не будем
Я бы не сказал, что OpenShift — это vendor lock-in. Он ведь тоже опенсорс, есть комьюнити версия, ну и опять же можно мигрировать на plain Kubernetes. И к тому же он представляет более solid решение. Это как RHEL считать vendor lock.
Я бы не сказал, что OpenShift — это vendor lock-in. Он ведь тоже опенсорс, есть комьюнити версия, ну и опять же можно мигрировать на plain Kubernetes. И к тому же он представляет более solid решение. Это как RHEL считать vendor lock.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы сдавали экзамен Certified Kubernetes Administrator