Третье интервью в Yandex Cloud: Python и траблшутинг
После двух успешных раундов интервью в Yandex Cloud, пришло время для третьего, и вот что мне удалось пройти.
Python задача: поиск подотрезков
Интервью началось с классической задачи по Python. Мне дали массив, состоящий из нулей и единиц, и нужно было найти максимальную длину подотрезка, состоящего из единиц, при условии удаления одного элемента. Пример:
Я быстро нашел решение с использованием скользящего окна. Сначала определяем переменные для подсчета нулей и длины подотрезка. Алгоритм проходил по массиву, и если встречался второй ноль, левая граница окна сдвигалась вправо.
Усложнение: удаление произвольного числа нулей
Далее задача усложнилась: теперь можно было удалить произвольное количество нулей. В это раннее утро, найти решение для этого усложнения было намного сложнее. Я попробовал сделать что-то подобное, но по итогу это оказалось не до конца правильным
Разбор алгоритмов
Мы обсудили временную сложность обоих решений и, что неожиданно для меня, заговорили о Big O для памяти vs процессора. Я предположил, что первое решение использует O(1) памяти, так как мы обрабатываем элементы на месте, а второе — O(n), где n — длина массива. Про сложность по процессору я не помню что ответил, но интервьюер одобрительно покачал головой.
Траблшутинг бинарников
Дальше перешли к траблшутингу, что, честно говоря, было для меня более привычно.
1. Бинарник app1 не запускается
Начал с проверки exit code с помощью
2. Проблема с app2 (EADDRINUSE)
Программа app2 не запускалась из-за того, что порт 8080 уже был занят. Команда
3. Ошибка “Too many open files” в app3
Лимит на количество открытых файлов в системе оказался 4097, а программа пыталась открыть 4098 файлов. С помощью
Финальная задача: очистка файлов
Последняя задача состояла в том что в папке есть почти несчетное кол-во файлов и нужно было удалить только те, что размер имеют от 2 до 4 кб. Загвоздка была в том что размеры эти были включительные, то есть я не мог указать 2K / 4K и дропнуть их. Я воспользовался
Файлы были успешно удалены.
После этого меня попросили удалить оставшиеся файлы в несколько потоков, для чего я использовал xargs:
Итоги
Это было одно из самых насыщенных интервью по задачам и траблшутингу. Приятно, что интервьюер не просто проверял мои знания, но и подсказывал, как справиться с заданиями, что делает процесс гораздо более обучающим.
Теперь жду приглашения на следующий раунд!
После двух успешных раундов интервью в Yandex Cloud, пришло время для третьего, и вот что мне удалось пройти.
Python задача: поиск подотрезков
Интервью началось с классической задачи по Python. Мне дали массив, состоящий из нулей и единиц, и нужно было найти максимальную длину подотрезка, состоящего из единиц, при условии удаления одного элемента. Пример:
assert maxOnes([1, 1, 0, 1]) == 3
assert maxOnes([1, 1, 0, 0, 1]) == 2
Я быстро нашел решение с использованием скользящего окна. Сначала определяем переменные для подсчета нулей и длины подотрезка. Алгоритм проходил по массиву, и если встречался второй ноль, левая граница окна сдвигалась вправо.
def maxOnes(arr):
n = len(arr)
max_len = 0
zero_count = 0
left = 0
for right in range(n):
if arr[right] == 0:
zero_count += 1
while zero_count > 1:
if arr[left] == 0:
zero_count -= 1
left += 1
max_len = max(max_len, right - left)
return max_len
Усложнение: удаление произвольного числа нулей
Далее задача усложнилась: теперь можно было удалить произвольное количество нулей. В это раннее утро, найти решение для этого усложнения было намного сложнее. Я попробовал сделать что-то подобное, но по итогу это оказалось не до конца правильным
def maxOnesWithKDeletions(arr, k):
n = len(arr)
max_len = 0
zero_count = 0
left = 0
for right in range(n):
if arr[right] == 0:
zero_count += 1
while zero_count > k:
if arr[left] == 0:
zero_count -= 1
left += 1
max_len = max(max_len, right - left + 1)
return max_len
Разбор алгоритмов
Мы обсудили временную сложность обоих решений и, что неожиданно для меня, заговорили о Big O для памяти vs процессора. Я предположил, что первое решение использует O(1) памяти, так как мы обрабатываем элементы на месте, а второе — O(n), где n — длина массива. Про сложность по процессору я не помню что ответил, но интервьюер одобрительно покачал головой.
Траблшутинг бинарников
Дальше перешли к траблшутингу, что, честно говоря, было для меня более привычно.
1. Бинарник app1 не запускается
Начал с проверки exit code с помощью
echo $? — код возврата был 1, что говорит о какой-то ошибке. Далее применил strace для отслеживания системных вызовов программы. Оказалось, что бинарник пытался записать данные в файл app1.txt, но по ошибке был создан файл app11.txt. После создания правильного файла бинарник запустился.2. Проблема с app2 (EADDRINUSE)
Программа app2 не запускалась из-за того, что порт 8080 уже был занят. Команда
ss -tuln :8080 помогла найти процесс, который занимал этот порт — это оказался Nginx. Я завершил процесс с помощью sudo kill -9.3. Ошибка “Too many open files” в app3
Лимит на количество открытых файлов в системе оказался 4097, а программа пыталась открыть 4098 файлов. С помощью
ulimit -n я увеличил этот лимит до 10000, и программа успешно запустилась.Финальная задача: очистка файлов
Последняя задача состояла в том что в папке есть почти несчетное кол-во файлов и нужно было удалить только те, что размер имеют от 2 до 4 кб. Загвоздка была в том что размеры эти были включительные, то есть я не мог указать 2K / 4K и дропнуть их. Я воспользовался
man find и с подсказкой интервьюера, обнаружил что там есть флаг (который по сути больше как суффикс) с - который используется для более точного контроля над размером файлов. Я перевел 2 и 4 КБ в байты и исполнил такую командуfind /path/to/garbage -type f -size +2047c -size -3073c -deleteФайлы были успешно удалены.
После этого меня попросили удалить оставшиеся файлы в несколько потоков, для чего я использовал xargs:
ls | xargs -0 -P 4 rm -fИтоги
Это было одно из самых насыщенных интервью по задачам и траблшутингу. Приятно, что интервьюер не просто проверял мои знания, но и подсказывал, как справиться с заданиями, что делает процесс гораздо более обучающим.
Теперь жду приглашения на следующий раунд!
😍2
Для быстрого тестирования подключения приложения в Kubernetes часто бывает полезно запустить отдельный под, созданный исключительно для проверки соединения. Одним из популярных инструментов для этого является curl, который можно использовать в одноразовом поде.
Почему?
Тестирование сетевого подключения с помощью curl в одноразовом поде полезно, когда нужно проверить доступность других подов. Например, если приложение не может достучаться до другого сервиса, или подозреваете проблемы с сетевыми правилами. Даже если сеть работает корректно, всегда стоит проверить доступность напрямую.
Пример команды
Чтобы создать под с curl для одноразовой проверки подключения, используйте следующую команду:
Эта команда создаёт под, запускает в нем curl, проверяет соединение с сервисом по IP и порту, а затем удаляет под. Это полезно тем, что под создается только для выполнения теста и сразу удаляется, не занимая ресурсы кластера.
Кейсы использования
1. Тестирование доступа между подами. Когда приложение пытается подключиться к другому сервису, но соединение по какой-то причине не проходит. Например, после настройки NetworkPolicy, нужно убедиться, что поды действительно могут общаться друг с другом. В таких случаях удобно запустить одноразовый под с curl и проверить доступность.
2. Отладка сетевых проблем. В случае, если сервис не доступен, используя одноразовый под, можно быстро проверить, проблема ли в приложении или в сетевой инфраструктуре (например, проблемный ingress, firewall, или ошибки в конфигурации сервисов).
Одноразовые поды — это простой способ проверить сетевые соединения в Kubernetes, curl в таком оказывается очень полезным на практике.
Почему?
Тестирование сетевого подключения с помощью curl в одноразовом поде полезно, когда нужно проверить доступность других подов. Например, если приложение не может достучаться до другого сервиса, или подозреваете проблемы с сетевыми правилами. Даже если сеть работает корректно, всегда стоит проверить доступность напрямую.
Пример команды
Чтобы создать под с curl для одноразовой проверки подключения, используйте следующую команду:
kubectl run --image=curlimages/curl -it --restart=Never --rm client-pod curl 10.244.2.4:8080Эта команда создаёт под, запускает в нем curl, проверяет соединение с сервисом по IP и порту, а затем удаляет под. Это полезно тем, что под создается только для выполнения теста и сразу удаляется, не занимая ресурсы кластера.
Кейсы использования
1. Тестирование доступа между подами. Когда приложение пытается подключиться к другому сервису, но соединение по какой-то причине не проходит. Например, после настройки NetworkPolicy, нужно убедиться, что поды действительно могут общаться друг с другом. В таких случаях удобно запустить одноразовый под с curl и проверить доступность.
2. Отладка сетевых проблем. В случае, если сервис не доступен, используя одноразовый под, можно быстро проверить, проблема ли в приложении или в сетевой инфраструктуре (например, проблемный ingress, firewall, или ошибки в конфигурации сервисов).
Одноразовые поды — это простой способ проверить сетевые соединения в Kubernetes, curl в таком оказывается очень полезным на практике.
This media is not supported in your browser
VIEW IN TELEGRAM
Product Manager разруливает спринтовые таски
🤣2
Иногда приходится забрать файл из контейнера или закинуть туда что-то свое, и тут на помощь приходит команда kubectl cp. В продакшене, конечно, так особо не поиграешь, но в разработке — вполне себе полезный трюк.
Как это работает
Представьте, вы нашли баг в своем HTML-файле, который под обслуживает. Вроде бы и мелочь, но пересобирать образ лень. Вместо этого вы просто вытаскиваете файл:
Правите его локально, возвращаете обратно:
И обновляете страницу.
Когда пригодится?
1. Экономия на пересборке образа: Все мы знаем, как это бывает: нашел проблему в конфигурации или статику обновить надо, а Dockerfile уже видит, как его пересобирают в десятый раз за день. Не беда! Просто скопируйте файл, поправьте его, и без лишних танцев с образами верните обратно в контейнер.
2. Лог-файлы — это золото: Логи — это как черный ящик самолета, если что-то пошло не так. Но зачем ломать голову над тем, как их достать, если можно просто взять и скачать их на локальную машину с помощью kubectl cp. Это как будто на минуточку заглянули в контейнер, чтобы забрать нужные документы.
И только один нюанс: контейнер должен дружить с tar. Если вдруг нет — что ж, будет повод его подружить!
Как это работает
Представьте, вы нашли баг в своем HTML-файле, который под обслуживает. Вроде бы и мелочь, но пересобирать образ лень. Вместо этого вы просто вытаскиваете файл:
kubectl cp service:/html/index.html /tmp/index.htmlПравите его локально, возвращаете обратно:
kubectl cp /tmp/index.html service:/html/И обновляете страницу.
Когда пригодится?
1. Экономия на пересборке образа: Все мы знаем, как это бывает: нашел проблему в конфигурации или статику обновить надо, а Dockerfile уже видит, как его пересобирают в десятый раз за день. Не беда! Просто скопируйте файл, поправьте его, и без лишних танцев с образами верните обратно в контейнер.
2. Лог-файлы — это золото: Логи — это как черный ящик самолета, если что-то пошло не так. Но зачем ломать голову над тем, как их достать, если можно просто взять и скачать их на локальную машину с помощью kubectl cp. Это как будто на минуточку заглянули в контейнер, чтобы забрать нужные документы.
И только один нюанс: контейнер должен дружить с tar. Если вдруг нет — что ж, будет повод его подружить!
⏰ Интересный концепт для прокрастинаторов (точно не про меня)
Наткнулся на пару полезных инструментов, которые могут облегчить жизнь тем, кто часто застревает на YouTube, теряя часы в бесполезных видео. В основе обоих решений, кажется, лежит искусственный интеллект, который помогает фильтровать ненужный контент и оставлять только то, что имеет ценность. Делюсь двумя расширениями:
1. YouTube Addiction Rehab
Это расширение для Chrome фильтрует ваши интересы и отсеивает мусорные рекомендации. Цель — оставить в ленте только полезные видео и избавить от «тёмных кроличьих нор», куда YouTube любит затягивать. Отлично подходит для тех, кто хочет осознанно управлять своим временем и не поддаваться на алгоритмические соблазны.
2. BlockTube
Более продвинутое решение для тех, кто хочет вручную настроить свой YouTube. BlockTube даёт возможность:
• Блокировать видео и каналы по названию
• Исключать комментарии на основе ключевых слов или имени автора
• Убирать YouTube Shorts и фильмы
• Прятать просмотренные видео из рекомендаций
• Настраивать фильтры по длительности роликов
• И даже отключать раздражающие всплывающие окна «Видео приостановлено, продолжить просмотр?»
Для правильных пацанов есть поддержка regex📜 и возможность интегрировать JavaScript-функции для кастомной блокировки.
Ссылки на расширения:
• YouTube Addiction Rehab
• BlockTube
В итоге, если YouTube всё-таки затягивает, эти инструменты могут стать отличным решением.
Наткнулся на пару полезных инструментов, которые могут облегчить жизнь тем, кто часто застревает на YouTube, теряя часы в бесполезных видео. В основе обоих решений, кажется, лежит искусственный интеллект, который помогает фильтровать ненужный контент и оставлять только то, что имеет ценность. Делюсь двумя расширениями:
1. YouTube Addiction Rehab
Это расширение для Chrome фильтрует ваши интересы и отсеивает мусорные рекомендации. Цель — оставить в ленте только полезные видео и избавить от «тёмных кроличьих нор», куда YouTube любит затягивать. Отлично подходит для тех, кто хочет осознанно управлять своим временем и не поддаваться на алгоритмические соблазны.
2. BlockTube
Более продвинутое решение для тех, кто хочет вручную настроить свой YouTube. BlockTube даёт возможность:
• Блокировать видео и каналы по названию
• Исключать комментарии на основе ключевых слов или имени автора
• Убирать YouTube Shorts и фильмы
• Прятать просмотренные видео из рекомендаций
• Настраивать фильтры по длительности роликов
• И даже отключать раздражающие всплывающие окна «Видео приостановлено, продолжить просмотр?»
Для правильных пацанов есть поддержка regex📜 и возможность интегрировать JavaScript-функции для кастомной блокировки.
Ссылки на расширения:
• YouTube Addiction Rehab
• BlockTube
В итоге, если YouTube всё-таки затягивает, эти инструменты могут стать отличным решением.
Google
Youtube Addiction Rehab - Chrome Web Store
AI powered smart blocker and filter to improve YouTube addiction.
👀1
Phase vs Status подов в Kubernetes
При работе с Kubernetes важно понимать, как следить за состоянием и фазами подов. Сегодня разберем, как Kubernetes управляет фазами Pod’ов и состояниями контейнеров - эта инфа точно пригодится для менеджмента нод, ну или просто пройти интервью.
Фазы подов - что происходит от создания до завершения
Каждый под на протяжении своего жизненного цикла проходит несколько фаз. Эти фазы помогают быстро понять, что происходит с подом в данный момент.
• Pending – под создан, но еще не запущен. Он ожидает, пока его назначат на ноду и загрузят все образы контейнеров.
• Running – Хотя бы один из контейнеров пода успешно запущен.
• Succeeded – Контейнеры выполнили свои задачи и завершились корректно.
• Failed – По крайней мере один контейнер завершился с ошибкой, или под был неправильно сконфигурирован.
• Unknown – Состояние неизвестно, так как нода перестала отвечать API-серверу.
Чтобы посмотреть, в какой фазе находится под:
Или старым дескрайбом
Состояния подов - что происходит внутри
Фазы показывают общий статус пода, но более точная информация содержится в состояниях. Подобно состояниям нод (например, MemoryPressure и DiskPressure), поды имеют собственные статусы.
• PodScheduled – назначен на ноду.
• Initialized – Все init-контейнеры успешно завершили выполнение.
• ContainersReady – Все контейнеры внутри пода готовы.
• Ready – готов обслуживать запросы клиентов.
Каждое из этих состояний может иметь значение True или False в зависимости от текущего статуса пода. Например, если хотя бы один контейнер не готов, состояние ContainersReady будет False. Это позволяет более точно отслеживать проблемы и устранять их.
Пример
Запустим под с помощью манифеста:
После этого проверим его статус:
Если вы видите, что контейнеры не готовы или под не стартует, используйте вывод команды describe для диагностики. Например, состояние Initialized: False может указывать на проблемы с init-контейнером.
Понимание фаз и состояний подов помогает не только отслеживать работу, но и траблшутить проблемы. Используйте команды kubectl describe и kubectl get и помните: диагностика – ключ к стабильной инфраструктуре.
При работе с Kubernetes важно понимать, как следить за состоянием и фазами подов. Сегодня разберем, как Kubernetes управляет фазами Pod’ов и состояниями контейнеров - эта инфа точно пригодится для менеджмента нод, ну или просто пройти интервью.
Фазы подов - что происходит от создания до завершения
Каждый под на протяжении своего жизненного цикла проходит несколько фаз. Эти фазы помогают быстро понять, что происходит с подом в данный момент.
• Pending – под создан, но еще не запущен. Он ожидает, пока его назначат на ноду и загрузят все образы контейнеров.
• Running – Хотя бы один из контейнеров пода успешно запущен.
• Succeeded – Контейнеры выполнили свои задачи и завершились корректно.
• Failed – По крайней мере один контейнер завершился с ошибкой, или под был неправильно сконфигурирован.
• Unknown – Состояние неизвестно, так как нода перестала отвечать API-серверу.
Чтобы посмотреть, в какой фазе находится под:
$ kubectl get po pod -o yaml | grep phaseИли старым дескрайбом
$ kubectl describe po podСостояния подов - что происходит внутри
Фазы показывают общий статус пода, но более точная информация содержится в состояниях. Подобно состояниям нод (например, MemoryPressure и DiskPressure), поды имеют собственные статусы.
• PodScheduled – назначен на ноду.
• Initialized – Все init-контейнеры успешно завершили выполнение.
• ContainersReady – Все контейнеры внутри пода готовы.
• Ready – готов обслуживать запросы клиентов.
Каждое из этих состояний может иметь значение True или False в зависимости от текущего статуса пода. Например, если хотя бы один контейнер не готов, состояние ContainersReady будет False. Это позволяет более точно отслеживать проблемы и устранять их.
Пример
Запустим под с помощью манифеста:
$ kubectl apply -f pod.pod.yamlПосле этого проверим его статус:
$ kubectl describe po podЕсли вы видите, что контейнеры не готовы или под не стартует, используйте вывод команды describe для диагностики. Например, состояние Initialized: False может указывать на проблемы с init-контейнером.
Понимание фаз и состояний подов помогает не только отслеживать работу, но и траблшутить проблемы. Используйте команды kubectl describe и kubectl get и помните: диагностика – ключ к стабильной инфраструктуре.
🔧 Траблшутинг Kubernetes: как не потеряться в лабиринте
Решение проблем в Kubernetes для меня всегда напоминает блуждание по лабиринту. С его распределённой архитектурой и множеством компонентов, найти и устранить проблему требует целого набора инструментов и методик. Это не просто — но с опытом приходит понимание, как делать это эффективно.
В этом посте я собрал несколько техник и инструментов для траблшутинга Kubernetes. Неважно, опытный ли вы пользователь Kubernetes или только начинаете — этот гайд подскажет, как сделать процесс отладки эффективным.
Хотя я стараюсь собрать советы из собственного опыта, не забывайте, что официальная документация Kubernetes остаётся основным и самым достоверным источником информации. 📜
🔄 Анализ жизненного цикла подов
Понимание того, как проходит жизненный цикл подов — главный момент в суппорте приложений. Каждый под проходит несколько этапов — от создания до завершения — и анализ этих событий помогает выявлять проблемы.
Этапы жизненного цикла пода
Про фазы пода я писал в предыдущем посте. Напомню просто, чтобы проанализировать состояние подов, используйте команды
✨Евенты пода
Секция “Events” в выводе команды kubectl describe предоставляет хронологический журнал всех событий которые случились с подом. Это помогает понять, что привело к проблеме и как её устранить. Вот несколько типичных случаев, с которыми я сталкиваюсь:
- "Неназначение" на ноду:: возможно, нехватка ресурсов на Node или проблемы с планировщиком.
- Ошибки при загрузке образов: чаще всего указывают на сетевые проблемы или недоступность контейнерного реестра.
- Сбои контейнера: повторяющиеся падения контейнера можно диагностировать, изучив события перед сбоем.
📝 События и аудит-логи в Kubernetes
Kubernetes генерирует события на уровне кластера, которые дают краткий обзор происходящего. Аудит-логи, с другой стороны, полезны для обеспечения безопасности и соответствия требованиям. Они фиксируют попытки входа в систему, эскалации привилегий и многое другое.
🔍 Просмотр событий
Аудит-логи Kubernetes
Аудит-логи записывают все API-запросы, поступающие в Kubernetes API-сервер, включая информацию о пользователе, выполненное действие и его результат. Широко используется в компаниях которым важна безопасность кластера. Пример записи в аудит-логе:
Решение проблем в Kubernetes для меня всегда напоминает блуждание по лабиринту. С его распределённой архитектурой и множеством компонентов, найти и устранить проблему требует целого набора инструментов и методик. Это не просто — но с опытом приходит понимание, как делать это эффективно.
В этом посте я собрал несколько техник и инструментов для траблшутинга Kubernetes. Неважно, опытный ли вы пользователь Kubernetes или только начинаете — этот гайд подскажет, как сделать процесс отладки эффективным.
Хотя я стараюсь собрать советы из собственного опыта, не забывайте, что официальная документация Kubernetes остаётся основным и самым достоверным источником информации. 📜
🔄 Анализ жизненного цикла подов
Понимание того, как проходит жизненный цикл подов — главный момент в суппорте приложений. Каждый под проходит несколько этапов — от создания до завершения — и анализ этих событий помогает выявлять проблемы.
Этапы жизненного цикла пода
Про фазы пода я писал в предыдущем посте. Напомню просто, чтобы проанализировать состояние подов, используйте команды
kubectl get и kubectl describe.✨Евенты пода
Секция “Events” в выводе команды kubectl describe предоставляет хронологический журнал всех событий которые случились с подом. Это помогает понять, что привело к проблеме и как её устранить. Вот несколько типичных случаев, с которыми я сталкиваюсь:
- "Неназначение" на ноду:: возможно, нехватка ресурсов на Node или проблемы с планировщиком.
- Ошибки при загрузке образов: чаще всего указывают на сетевые проблемы или недоступность контейнерного реестра.
- Сбои контейнера: повторяющиеся падения контейнера можно диагностировать, изучив события перед сбоем.
📝 События и аудит-логи в Kubernetes
Kubernetes генерирует события на уровне кластера, которые дают краткий обзор происходящего. Аудит-логи, с другой стороны, полезны для обеспечения безопасности и соответствия требованиям. Они фиксируют попытки входа в систему, эскалации привилегий и многое другое.
🔍 Просмотр событий
kubectl get events чтобы просмотреть события в кластере. Вот пример:LAST SEEN TYPE REASON OBJECT MESSAGE
12s Normal Scheduled pod/web-server-pod Successfully assigned default/web-server-pod to node-1
10s Normal Pulling pod/web-server-pod Pulling image "nginx:latest"
8s Normal Created pod/web-server-pod Created container web-container
7s Normal Started pod/web-server-pod Started container web-container
5s Warning BackOff pod/db-server-pod
Аудит-логи Kubernetes
Аудит-логи записывают все API-запросы, поступающие в Kubernetes API-сервер, включая информацию о пользователе, выполненное действие и его результат. Широко используется в компаниях которым важна безопасность кластера. Пример записи в аудит-логе:
{
"kind": "Event",
"apiVersion": "audit.k8s.io/v1",
"level": "Metadata",
"auditID": "12345",
"stage": "ResponseComplete",
"requestURI": "/api/v1/namespaces/default/pods",
"verb": "create",
"user": {
"username": "admin",
"groups": ["system:masters"]
},
"sourceIPs": ["192.168.1.1"],
"objectRef": {
"resource": "pods",
"namespace": "default",
"name": "web-server-pod"
},
"responseStatus": {
"metadata": {},
"code": 201
},
"requestReceivedTimestamp": "2024-01-01T12:00:00Z",
"stageTimestamp": "2024-01-01T12:00:01Z"
}📊 Дашборды
Когда работаю с кластером, пользуюсь инструментом для мониторинга - Lens. Это удобный GUI для Kubernetes, который помогает отслеживать состояние кластеров, управлять ресурсами и проводить диагностику.
Lens — это кросс-платформенное приложение с открытым исходным кодом, которое позволяет подключаться к Kubernetes-кластерам и управлять ими через визуальный интерфейс. По сути, Lens — это дашборд, который упрощает взаимодействие с Kubernetes, предлагая все возможности kubectl, но с визуализацией и множеством дополнительных функций для удобства. Загрузить приложение можно с официального сайта.
Траблшутинг Kubernetes требует понимания его компонентов и внимательного анализа событий. Используя инструменты, такие как kubectl get, kubectl describe, события, аудит-логи и дашборды можно эффективно находить и решать проблемы. 😵💫
Когда работаю с кластером, пользуюсь инструментом для мониторинга - Lens. Это удобный GUI для Kubernetes, который помогает отслеживать состояние кластеров, управлять ресурсами и проводить диагностику.
Lens — это кросс-платформенное приложение с открытым исходным кодом, которое позволяет подключаться к Kubernetes-кластерам и управлять ими через визуальный интерфейс. По сути, Lens — это дашборд, который упрощает взаимодействие с Kubernetes, предлагая все возможности kubectl, но с визуализацией и множеством дополнительных функций для удобства. Загрузить приложение можно с официального сайта.
Траблшутинг Kubernetes требует понимания его компонентов и внимательного анализа событий. Используя инструменты, такие как kubectl get, kubectl describe, события, аудит-логи и дашборды можно эффективно находить и решать проблемы. 😵💫
lenshq.io
Power Tools for Kubernetes and LLM observability. With over 1 million users, Lens is the new standard for Kubernetes and LLM application developers.
System Design интервью: проектировал Instagram📸
Недавно на system design интервью (https://yandex.ru/jobs/pages/devops_cloud) мне выпало задание спроектировать сервис для обмена фотографиями, чем-то напоминающий Instagram. Конечно, я уже где-то такое видел (но, честно говоря, мало что запомнил), и мне почти профессионально удалось проговорить все ключевые моменты дизайна. Потом я поработал над архитектурой, которую можно увидеть на скриншоте — тут уже не так “профессионально”, но всё равно сносно. Давайте погрузимся в детали проектирования и самого интервью.
Основные функции
Начал я с разбора основных сервисов и их функций. Вот ключевые моменты:
- 📤 Загрузка фотографий.
- 🔔Подписки и фолловеры.
- 📜Построение персонализированных лент новостей.
Также важно было учесть масштаб:
- 500M DAU (ежедневно активных пользователей).
- 1B MAU (ежемесячных активных пользователей).
- 2.5B общих пользователей.
- 50B фотографий в системе.
- 50M фотографий загружается каждый день, каждая размером 100 KB.
1. Как грузить фотки?
Начали с самого главного — как же юзеры будут загружать фотографии? Первый вопрос был: как эффективно хранить и обрабатывать такие объёмы, учитывая их стремительный рост? Мой выбор пал на облачные хранилища типа AWS S3 — оно отлично масштабируется и помогает справляться с такими объёмами данных.
Каждая загруженная фотка попадает в основное хранилище, а для ускорения доступа — кешируется через Redis. Система простая: Redis сидит между базой данных, где хранятся фотографии, и API-шлюзом. Когда пользователь запрашивает фотку, сперва проверяется кеш. Если там её нет — идём в базу данных. Конечно, всё работает на хешах, потому что гонять блобы через сеть в таком объёме — задача почти фантастическая.
Дальше добавил механизмы репликации данных для отказоустойчивости, чтобы, если что-то где-то упало, фотки не исчезли в цифровой бездне.
2. Как организовать шардирование? 🪨
С такими данными игнорировать шардирование просто непрвильно. Поэтому следующий вопрос — как распределить пользователей по шардам? Я использовал хеширование по userId для обычных пользователей, чтобы их данные равномерно распределялись. Это не только облегчает масштабирование, но и позволяет системе дышать спокойно. VIP-пользователи 👑 которые генерируют кучу трафика, были выделены в отдельные шарды. Это не только изолировало их от остальных пользователей, но и снизило нагрузку на общую систему.
3. Лента новостей (Feed)
Теперь самый важный момент — как обеспечить низкую задержку при генерации ленты новостей? Используем асинхронную обработку: при публикации новых фотографий от VIP пользователей фоны ленты не должны тормозить. Для этого была введена система обработки данных с использованием очередей (типа Kafka) которая позволила фоново обновлять ленты пользователей. Кроме того, все непрямые задачи (статистика и маркетинг) тоже вынес в асинхронные процессы, чтобы основной канал оставался чистым, а пользователь всегда получал контент с приоритетом. Аналитические данные мы собираем в фоновом режиме, так что цифры у нас есть, а пользователи счастливы.
4. Fault tolerance и балансировка нагрузки 🤹
Для обеспечения доступности сервиса 24/7 логично было использовать load balancer на входе. Я также предусмотрел развёртывание нескольких дата-центров с асинхронной репликацией данных и добавил CDN. Теперь пользователи из Канады не ждут свои фотки из России как-будто они грузятся по почте.
5. Безопасность и масштабируемость 🔒
Система хранения метаданных (комментарии, лайки, подписки) была спроектирована с использованием PostgreSQL с мастер-слейв репликацией для отказоустойчивости. Кеширование в Redis также ускоряет доступ к часто запрашиваемым данным.
Итоги
Вот ключевые решения, которые я принял:
- Шардирование пользователей с выделением VIP в отдельные шарды.
- Использование CDN для ускорения доставки фотографий.
- Кеширование данных и асинхронная генерация ленты новостей.
- Репликация данных для повышения отказоустойчивости.
Все эти меры помогли создать систему, способную выдерживать огромные нагрузки, масштабироваться и минимизировать задержки.
Недавно на system design интервью (https://yandex.ru/jobs/pages/devops_cloud) мне выпало задание спроектировать сервис для обмена фотографиями, чем-то напоминающий Instagram. Конечно, я уже где-то такое видел (но, честно говоря, мало что запомнил), и мне почти профессионально удалось проговорить все ключевые моменты дизайна. Потом я поработал над архитектурой, которую можно увидеть на скриншоте — тут уже не так “профессионально”, но всё равно сносно. Давайте погрузимся в детали проектирования и самого интервью.
Основные функции
Начал я с разбора основных сервисов и их функций. Вот ключевые моменты:
- 📤 Загрузка фотографий.
- 🔔Подписки и фолловеры.
- 📜Построение персонализированных лент новостей.
Также важно было учесть масштаб:
- 500M DAU (ежедневно активных пользователей).
- 1B MAU (ежемесячных активных пользователей).
- 2.5B общих пользователей.
- 50B фотографий в системе.
- 50M фотографий загружается каждый день, каждая размером 100 KB.
1. Как грузить фотки?
Начали с самого главного — как же юзеры будут загружать фотографии? Первый вопрос был: как эффективно хранить и обрабатывать такие объёмы, учитывая их стремительный рост? Мой выбор пал на облачные хранилища типа AWS S3 — оно отлично масштабируется и помогает справляться с такими объёмами данных.
Каждая загруженная фотка попадает в основное хранилище, а для ускорения доступа — кешируется через Redis. Система простая: Redis сидит между базой данных, где хранятся фотографии, и API-шлюзом. Когда пользователь запрашивает фотку, сперва проверяется кеш. Если там её нет — идём в базу данных. Конечно, всё работает на хешах, потому что гонять блобы через сеть в таком объёме — задача почти фантастическая.
Дальше добавил механизмы репликации данных для отказоустойчивости, чтобы, если что-то где-то упало, фотки не исчезли в цифровой бездне.
2. Как организовать шардирование? 🪨
С такими данными игнорировать шардирование просто непрвильно. Поэтому следующий вопрос — как распределить пользователей по шардам? Я использовал хеширование по userId для обычных пользователей, чтобы их данные равномерно распределялись. Это не только облегчает масштабирование, но и позволяет системе дышать спокойно. VIP-пользователи 👑 которые генерируют кучу трафика, были выделены в отдельные шарды. Это не только изолировало их от остальных пользователей, но и снизило нагрузку на общую систему.
3. Лента новостей (Feed)
Теперь самый важный момент — как обеспечить низкую задержку при генерации ленты новостей? Используем асинхронную обработку: при публикации новых фотографий от VIP пользователей фоны ленты не должны тормозить. Для этого была введена система обработки данных с использованием очередей (типа Kafka) которая позволила фоново обновлять ленты пользователей. Кроме того, все непрямые задачи (статистика и маркетинг) тоже вынес в асинхронные процессы, чтобы основной канал оставался чистым, а пользователь всегда получал контент с приоритетом. Аналитические данные мы собираем в фоновом режиме, так что цифры у нас есть, а пользователи счастливы.
4. Fault tolerance и балансировка нагрузки 🤹
Для обеспечения доступности сервиса 24/7 логично было использовать load balancer на входе. Я также предусмотрел развёртывание нескольких дата-центров с асинхронной репликацией данных и добавил CDN. Теперь пользователи из Канады не ждут свои фотки из России как-будто они грузятся по почте.
5. Безопасность и масштабируемость 🔒
Система хранения метаданных (комментарии, лайки, подписки) была спроектирована с использованием PostgreSQL с мастер-слейв репликацией для отказоустойчивости. Кеширование в Redis также ускоряет доступ к часто запрашиваемым данным.
Итоги
Вот ключевые решения, которые я принял:
- Шардирование пользователей с выделением VIP в отдельные шарды.
- Использование CDN для ускорения доставки фотографий.
- Кеширование данных и асинхронная генерация ленты новостей.
- Репликация данных для повышения отказоустойчивости.
Все эти меры помогли создать систему, способную выдерживать огромные нагрузки, масштабироваться и минимизировать задержки.
Как мы нанимаем DevOps-инженеров
Подробное описание этапов, полезные ссылки и материалы.
Как выбирать визы и контракты для работы в США?
Недавно получил письмо от HR, который набирает специалистов из разных областей на контракты в США.
Are you looking for Next opportunity in U.S.A?
Hiring Talent specialized from most of the Technologies like Java,.Net,Devop?s,AWS,Azure,Sharepoint,Mulesoft,Salesforce,Python,BI,MS CRM,RPA,ML etc..
Exclusively working on E3 Visa /TN Visa/E3 Transfer /TN transfer/H1B Transfers/EAD?s/OPT?s/C2C/GC process along with the Project in USA.
Разные визы, условия найма, бесконечные термины и аббревиатуры — кажется, проще стать DevOps, чем разобраться в этих визах. Попробуем прояснить, какие существуют визы и контракты для работы в США, и кому какие могут подойти.
Визы: типы и особенности
1. E-3 Visa 🇦🇺 для граждан Австралии.
Кому подходит: специалистам из Австралии, желающим поработать в США по своей специальности.
Длительность: сначала дается на два года, с возможностью неограниченного продления по два года.
Пример: австралийский инженер или DevOps специалист, работающий в крупной компании, может легко продлевать визу без необходимости возвращения домой.
2. TN Visa 🇲🇽 🇨🇦 для граждан Канады и Мексики.
Кому подходит: подходит для определенных профессий, перечисленных в NAFTA USMCA, и доступна гражданам Канады и Мексики.
Длительность: выдается на три года, с возможностью продления.
Пример: канадский Data Scientist, работающий над крупными аналитическими проектами, может получить TN визу и продлевать ее на протяжении нескольких лет.
3. H-1B Visa 🫅для высококвалифицированных специалистов.
Кому подходит: специалистам в области требующих специальных навыков (смотреть ниже ⬇️︎).
Длительность: обычно действует три года, с возможностью продления до шести лет.
Пример: DevOps инженер из Индии может получить H-1B визу, работая на американскую компанию, с перспективой продления до шести лет.
4. EAD 💼 (Employment Authorization Document) для всех подряд.
Кому подходит: этот документ предоставляет право на работу многим категориям, включая супругов H-1B держателей и участников программы DACA.
Пример: супруг специалиста с H-1B визой может работать в США благодаря EAD, что позволяет семье получать два дохода.
5. OPT 🧑🎓 (Optional Practical Training) для студентов.
Кому подходит: выпускникам американских университетов по F-1 визе для получения практического опыта.
Длительность: до 12 месяцев, с возможностью продления на 24 месяца для STEM специальностей.
Пример: выпускник по специальности Data Engineering может работать в США по OPT, а затем попытаться получить H-1B визу.
Типы контрактов: C2C и Green Card Process
1. C2C 🤝 (Corp-to-Corp) контракт между компаниями (смотреть следующий пост об этом виде контракта ⬇️︎).
Кому подходит: подходит для специалистов, работающих на себя и желающих быть гибкими в выборе проектов.
Пример: опытный DevOps специалист (я) с собственным LLC (не я) может заключить контракт C2C с американской компанией, выбирая проекты по своему вкусу.
2. GC Process 🟩 (Green Card Sponsorship) путь к ПМЖ.
Кому подходит: подходит тем, кто планирует оставаться в США на долгий срок.
Пример: специалист, работающий на крупную корпорацию, может пройти процесс получения грин-карты через спонсорство компании и стать постоянным жителем США.
—
Дальше будет про H-1B.
Недавно получил письмо от HR, который набирает специалистов из разных областей на контракты в США.
Are you looking for Next opportunity in U.S.A?
Hiring Talent specialized from most of the Technologies like Java,.Net,Devop?s,AWS,Azure,Sharepoint,Mulesoft,Salesforce,Python,BI,MS CRM,RPA,ML etc..
Exclusively working on E3 Visa /TN Visa/E3 Transfer /TN transfer/H1B Transfers/EAD?s/OPT?s/C2C/GC process along with the Project in USA.
Разные визы, условия найма, бесконечные термины и аббревиатуры — кажется, проще стать DevOps, чем разобраться в этих визах. Попробуем прояснить, какие существуют визы и контракты для работы в США, и кому какие могут подойти.
Визы: типы и особенности
1. E-3 Visa 🇦🇺 для граждан Австралии.
Кому подходит: специалистам из Австралии, желающим поработать в США по своей специальности.
Длительность: сначала дается на два года, с возможностью неограниченного продления по два года.
Пример: австралийский инженер или DevOps специалист, работающий в крупной компании, может легко продлевать визу без необходимости возвращения домой.
2. TN Visa 🇲🇽 🇨🇦 для граждан Канады и Мексики.
Кому подходит: подходит для определенных профессий, перечисленных в NAFTA USMCA, и доступна гражданам Канады и Мексики.
Длительность: выдается на три года, с возможностью продления.
Пример: канадский Data Scientist, работающий над крупными аналитическими проектами, может получить TN визу и продлевать ее на протяжении нескольких лет.
3. H-1B Visa 🫅для высококвалифицированных специалистов.
Кому подходит: специалистам в области требующих специальных навыков (смотреть ниже ⬇️︎).
Длительность: обычно действует три года, с возможностью продления до шести лет.
Пример: DevOps инженер из Индии может получить H-1B визу, работая на американскую компанию, с перспективой продления до шести лет.
4. EAD 💼 (Employment Authorization Document) для всех подряд.
Кому подходит: этот документ предоставляет право на работу многим категориям, включая супругов H-1B держателей и участников программы DACA.
Пример: супруг специалиста с H-1B визой может работать в США благодаря EAD, что позволяет семье получать два дохода.
5. OPT 🧑🎓 (Optional Practical Training) для студентов.
Кому подходит: выпускникам американских университетов по F-1 визе для получения практического опыта.
Длительность: до 12 месяцев, с возможностью продления на 24 месяца для STEM специальностей.
Пример: выпускник по специальности Data Engineering может работать в США по OPT, а затем попытаться получить H-1B визу.
Типы контрактов: C2C и Green Card Process
1. C2C 🤝 (Corp-to-Corp) контракт между компаниями (смотреть следующий пост об этом виде контракта ⬇️︎).
Кому подходит: подходит для специалистов, работающих на себя и желающих быть гибкими в выборе проектов.
Пример: опытный DevOps специалист (я) с собственным LLC (не я) может заключить контракт C2C с американской компанией, выбирая проекты по своему вкусу.
2. GC Process 🟩 (Green Card Sponsorship) путь к ПМЖ.
Кому подходит: подходит тем, кто планирует оставаться в США на долгий срок.
Пример: специалист, работающий на крупную корпорацию, может пройти процесс получения грин-карты через спонсорство компании и стать постоянным жителем США.
—
Дальше будет про H-1B.
H-1B Visa: а я обладаю "специальными" навыками ❓
Справедливый вопрос: какие навыки считаются “специальными” для IT?
В контексте H-1B, под специальными навыками понимаются те, которые сложно заменить без специальных знаний и обучения. Далее несколько направлений, которые подходят под H-1B, но "уникальность" таких знаний для меня под вопросом.
1. Программирование и разработка ПО — владение языками программирования, такими как Java, Python, C++, JavaScript, Go и другие, часто требуется для разработчиков ПО, мобильных приложений, веб-разработчиков и архитекторов систем. Ну ок.
2. Работа с облачными технологиями — навыки работы с AWS, Microsoft Azure, Google Cloud и другими облачными платформами востребованы для инженеров DevOps, архитекторов облачных решений, специалистов по виртуализации и автоматизации инфраструктуры. Ну да, каждый день я уникален.
3. Инженерия данных и аналитика — включает умения работать с Big Data платформами (например, Hadoop, Apache Spark), а также знание языков SQL, R и Python. Эти навыки требуются для data engineers, data scientists, аналитиков больших данных и специалистов по BI (бизнес-аналитика). Ну таких тоже пруд-пруди.
4. Кибербезопасность — специалисты по информационной безопасности должны обладать знанием сетевой безопасности, управлением рисками, и часто сертификациями, такими как CISSP или CEH, чтобы защищать корпоративные данные и инфраструктуру. Тут могу согласиться, стек серьезный.
5. Машинное обучение и искусственный интеллект — знание алгоритмов, математических методов и таких технологий, как TensorFlow, PyTorch, применяется в роли ML-инженеров, специалистов по ИИ и data scientists. Навык хороший, довольно уникален.
6. Разработка и администрирование баз данных — опыт работы с реляционными и NoSQL базами данных, такими как Oracle, MySQL, MongoDB, востребован для администраторов баз данных и backend-разработчиков. Это спрашивают на базовых джуниор интервью.
Так, H-1B в IT-сфере - в чем подвох?
Для получения H-1B визы, работодатель должен подтвердить ☑️, что должность требует специфических технических знаний. На практике это означает, что компания должна обосновать, что вакансия предназначена для высококвалифицированного специалиста с конкретными навыками. Например, позиции DevOps, разработчиков на Java или аналитиков данных должны попадать под эту категорию, так как их функции требуют детальных технических знаний, понимания инструментов и платформ, а также опыта работы с конкретными языками программирования или технологиями.
Каждый из этих вариантов найма и виз предлагает свою степень гибкости, сроков и условий. Например, если вы хотите на долгий срок обосноваться в США, стоит задуматься о процессе получения грин-карты. Если же вам важна свобода выбора проектов, то C2C — отличное решение, но требует финансовой самостоятельности (или грамотного бухгалтера).
—
Дальше будет про C2C.
Справедливый вопрос: какие навыки считаются “специальными” для IT?
В контексте H-1B, под специальными навыками понимаются те, которые сложно заменить без специальных знаний и обучения. Далее несколько направлений, которые подходят под H-1B, но "уникальность" таких знаний для меня под вопросом.
1. Программирование и разработка ПО — владение языками программирования, такими как Java, Python, C++, JavaScript, Go и другие, часто требуется для разработчиков ПО, мобильных приложений, веб-разработчиков и архитекторов систем. Ну ок.
2. Работа с облачными технологиями — навыки работы с AWS, Microsoft Azure, Google Cloud и другими облачными платформами востребованы для инженеров DevOps, архитекторов облачных решений, специалистов по виртуализации и автоматизации инфраструктуры. Ну да, каждый день я уникален.
3. Инженерия данных и аналитика — включает умения работать с Big Data платформами (например, Hadoop, Apache Spark), а также знание языков SQL, R и Python. Эти навыки требуются для data engineers, data scientists, аналитиков больших данных и специалистов по BI (бизнес-аналитика). Ну таких тоже пруд-пруди.
4. Кибербезопасность — специалисты по информационной безопасности должны обладать знанием сетевой безопасности, управлением рисками, и часто сертификациями, такими как CISSP или CEH, чтобы защищать корпоративные данные и инфраструктуру. Тут могу согласиться, стек серьезный.
5. Машинное обучение и искусственный интеллект — знание алгоритмов, математических методов и таких технологий, как TensorFlow, PyTorch, применяется в роли ML-инженеров, специалистов по ИИ и data scientists. Навык хороший, довольно уникален.
6. Разработка и администрирование баз данных — опыт работы с реляционными и NoSQL базами данных, такими как Oracle, MySQL, MongoDB, востребован для администраторов баз данных и backend-разработчиков. Это спрашивают на базовых джуниор интервью.
Так, H-1B в IT-сфере - в чем подвох?
Для получения H-1B визы, работодатель должен подтвердить ☑️, что должность требует специфических технических знаний. На практике это означает, что компания должна обосновать, что вакансия предназначена для высококвалифицированного специалиста с конкретными навыками. Например, позиции DevOps, разработчиков на Java или аналитиков данных должны попадать под эту категорию, так как их функции требуют детальных технических знаний, понимания инструментов и платформ, а также опыта работы с конкретными языками программирования или технологиями.
Каждый из этих вариантов найма и виз предлагает свою степень гибкости, сроков и условий. Например, если вы хотите на долгий срок обосноваться в США, стоит задуматься о процессе получения грин-карты. Если же вам важна свобода выбора проектов, то C2C — отличное решение, но требует финансовой самостоятельности (или грамотного бухгалтера).
—
Дальше будет про C2C.
Работать по Corp-to-Corp (C2C) в США 👔
Интересный вариант, как мнеи другим cold-plunger'ам показался. Выглядит как реальный и гибкий вариант для IT-специалистов, особенно если вы планируете работать как независимый консультант или фрилансер на проекты.
C2C контракт заключается между двумя юридическими лицами. Обычно это означает, что у вас есть зарегистрированная компания (например, LLC в Канаде), и вы заключаете договор с американской компанией на выполнение услуг через ваше юридическое лицо, а не как индивидуальный подрядчик.
Основные преимущества C2C
1. Финансовая гибкость 💸: можно получать более высокий доход, так как у вас нет налогов на заработную плату, и вы сами управляете налоговыми обязательствами своей компании.
2. Контроль над проектами и графиком 🛂: C2C контракты предполагают большую независимость в проектной деятельности, и вы можете работать одновременно с несколькими клиентами.
3. Простота доступа к проектам в США 🗽: Поскольку в C2C вы работаете как компания, а не как физическое лицо, американские компании нередко охотнее заключают такие контракты с международными специалистами.
Как подготовиться к работе по C2C
1. Зарегистрировать компанию (LLC) как отдельное юридическое лицо. Это может быть простая корпорация или LLC в Канаде, которая будет выступать стороной договора с клиентом из США. Регистрация корпорации в Канаде достаточно проста и можно ее сделать онлайн.
2. Открыть банковский счет для бизнеса (после регистрации LLC) - это корпоративный счет в банке, чтобы принимать платежи по контракту, избегая смешивания личных и деловых финансов.
3. Оформить договор с американской компанией: После выбора проекта американская компания оформляет контракт с вашей корпорацией. В контракте указываются все условия, включая сроки проекта, оплату и конкретные обязанности вашей компании.
4. Рассмотрите необходимость рабочей визы или поездок в США: Если проект требует регулярных поездок в США, может понадобиться виза TN или B-1 (Business Visitor). Однако, если работа полностью удаленная, виза может не потребоваться, поскольку все операции осуществляются через вашу канадскую компанию.
C2C налоги и финансовые аспекты
- Налоговые обязательства в Канаде 🏦: Вы платите налоги как канадское юридическое лицо и можете вычитать бизнес-расходы (оборудование, программное обеспечение, аренда офиса и т.д.).
- Отчеты для IRS (США) 📝: Так как вы будете eработать с американскими клиентами, возможно, вам потребуется оформить форму W-8BEN-E для подтверждения статуса иностранного юридического лица. Эта форма помогает избежать двойного налогообложения в США, так как Канада и США имеют налоговое соглашение.
Пример
Представим, что вы DevOps инженер в Канаде с собственной компанией. Американская компания предлагает вам контракт на разработку и поддержку CI/CD процессов в своих проектах. Вы заключаете C2C контракт через свою LLC, работаете удаленно, самостоятельно выписываете инвойсы, получаете оплату на корпоративный счет и оплачиваете налоги по канадскому законодательству.
—-
Подытожим
Каждый из этих вариантов найма и виз предлагает свою степень гибкости, сроков и условий. Например, если вы хотите на долгий срок обосноваться в США, стоит задуматься о процессе получения грин-карты. Если же вам важна свобода выбора проектов, то C2C — отличное решение, но требует финансовой самостоятельности.
Интересный вариант, как мне
C2C контракт заключается между двумя юридическими лицами. Обычно это означает, что у вас есть зарегистрированная компания (например, LLC в Канаде), и вы заключаете договор с американской компанией на выполнение услуг через ваше юридическое лицо, а не как индивидуальный подрядчик.
Основные преимущества C2C
1. Финансовая гибкость 💸: можно получать более высокий доход, так как у вас нет налогов на заработную плату, и вы сами управляете налоговыми обязательствами своей компании.
2. Контроль над проектами и графиком 🛂: C2C контракты предполагают большую независимость в проектной деятельности, и вы можете работать одновременно с несколькими клиентами.
3. Простота доступа к проектам в США 🗽: Поскольку в C2C вы работаете как компания, а не как физическое лицо, американские компании нередко охотнее заключают такие контракты с международными специалистами.
Как подготовиться к работе по C2C
1. Зарегистрировать компанию (LLC) как отдельное юридическое лицо. Это может быть простая корпорация или LLC в Канаде, которая будет выступать стороной договора с клиентом из США. Регистрация корпорации в Канаде достаточно проста и можно ее сделать онлайн.
2. Открыть банковский счет для бизнеса (после регистрации LLC) - это корпоративный счет в банке, чтобы принимать платежи по контракту, избегая смешивания личных и деловых финансов.
3. Оформить договор с американской компанией: После выбора проекта американская компания оформляет контракт с вашей корпорацией. В контракте указываются все условия, включая сроки проекта, оплату и конкретные обязанности вашей компании.
4. Рассмотрите необходимость рабочей визы или поездок в США: Если проект требует регулярных поездок в США, может понадобиться виза TN или B-1 (Business Visitor). Однако, если работа полностью удаленная, виза может не потребоваться, поскольку все операции осуществляются через вашу канадскую компанию.
C2C налоги и финансовые аспекты
- Налоговые обязательства в Канаде 🏦: Вы платите налоги как канадское юридическое лицо и можете вычитать бизнес-расходы (оборудование, программное обеспечение, аренда офиса и т.д.).
- Отчеты для IRS (США) 📝: Так как вы будете eработать с американскими клиентами, возможно, вам потребуется оформить форму W-8BEN-E для подтверждения статуса иностранного юридического лица. Эта форма помогает избежать двойного налогообложения в США, так как Канада и США имеют налоговое соглашение.
Пример
Представим, что вы DevOps инженер в Канаде с собственной компанией. Американская компания предлагает вам контракт на разработку и поддержку CI/CD процессов в своих проектах. Вы заключаете C2C контракт через свою LLC, работаете удаленно, самостоятельно выписываете инвойсы, получаете оплату на корпоративный счет и оплачиваете налоги по канадскому законодательству.
—-
Подытожим
Каждый из этих вариантов найма и виз предлагает свою степень гибкости, сроков и условий. Например, если вы хотите на долгий срок обосноваться в США, стоит задуматься о процессе получения грин-карты. Если же вам важна свобода выбора проектов, то C2C — отличное решение, но требует финансовой самостоятельности.
Persistent Volumes и Persistent Volume Claims в Kubernetes: что к чему? 📦
Начиная работать с Kubernetes нечасто сразу начинаешь думать о storage layer. В продакшене же, работа с датой да еще и в ключе чтобы она "выживала" после рестарта пода — одна из важнейших задач. Сами контейнеры считаются эфемерными: они могут внезапно удаляться и пересоздаваться, и как только это происходит, данные пропадают. Сейчас расскажу про Persistent Volumes (PV) и Persistent Volume Claims (PVC): чем они отличаются и как использовать их эффективно.
Persistent Volume (PV): Хранилище на уровне кластера
PV — это абстракция в Kubernetes, представляющая собой выделенный участок памяти на уровне кластера, который может быть доступен для вашихhello-worldприложений. Чтобы лучше понять, представьте PV как выделенный диск на сервере. Это не просто “пространство”, а управляемый ресурс, который может существовать независимо от подов. PV описываем в манифесте и он может находиться на локальных или внешних хранилищах, таких как NFS, AWS EBS (или любой другой аналог из соседних облаков💭), или даже сетевые диски.
PV — это, по сути, глобально доступный storage, который можно подключать к подам, когда это нужно. Он может быть read-only (чтобы например хранить шаблоны HTML для веб-приложения или ML-модель которая используется разными подами для инференса) или read-write (тут примеры не нужны).
Persistent Volume Claim (PVC): Запрос на хранение данных
Теперь представьте, что ваше приложение — это под, который хочет получить доступ к данным. Вот тут и нужен PVC. Это запрос, который создается на уровне приложения и связывается с PV, если тот соответствует требованиям (размеру, доступности и т.д.). PVC работает как “запрос на доступ к данным” и позволяет подам подключаться к PV, получая таким образом нужное пространство.
PVC как бы говорит: «Эй, Kubernetes, мне нужно столько-то гигабайт пространства, чтобы хранить мои данные, и вот мои требования к доступу». Kubernetes затем связывает этот запрос с подходящим PV, если таковой доступен.
Как это работает вместе? 🤝
Когда приложение нуждается в persistent хранилище, оно создает PVC, а Kubernetes автоматически подбирает подходящий PV или создаёт новый (если используется Dynamic Provisioning). К примеру, если у вас есть Postgres или MySQL под, которому требуется хранение для баз данных, вы создаете PVC на нужное количество гигабайт, и Kubernetes позаботится о том, чтобы связать его с PV, который соответствует запросу. Это делает систему более гибкой - не нужно вручную добавлять диски для каждого нового пода. PVC позволяет разделять заботы об инфраструктуре (создание PV) и приложения (использование PVC).
Вот пример того, как выглядят PV и PVC в Kubernetes YAML-файлах:
В этом примере мы сначала создаём PV на 10ГБ и указываем, что его можно использовать только с одним подом (ReadWriteOnce). Далее создается PVC, который «просит» доступ к 10ГБ с такими же параметрами доступа, и Kubernetes связывает их автоматически.
Начиная работать с Kubernetes нечасто сразу начинаешь думать о storage layer. В продакшене же, работа с датой да еще и в ключе чтобы она "выживала" после рестарта пода — одна из важнейших задач. Сами контейнеры считаются эфемерными: они могут внезапно удаляться и пересоздаваться, и как только это происходит, данные пропадают. Сейчас расскажу про Persistent Volumes (PV) и Persistent Volume Claims (PVC): чем они отличаются и как использовать их эффективно.
Persistent Volume (PV): Хранилище на уровне кластера
PV — это абстракция в Kubernetes, представляющая собой выделенный участок памяти на уровне кластера, который может быть доступен для ваших
PV — это, по сути, глобально доступный storage, который можно подключать к подам, когда это нужно. Он может быть read-only (чтобы например хранить шаблоны HTML для веб-приложения или ML-модель которая используется разными подами для инференса) или read-write (тут примеры не нужны).
Persistent Volume Claim (PVC): Запрос на хранение данных
Теперь представьте, что ваше приложение — это под, который хочет получить доступ к данным. Вот тут и нужен PVC. Это запрос, который создается на уровне приложения и связывается с PV, если тот соответствует требованиям (размеру, доступности и т.д.). PVC работает как “запрос на доступ к данным” и позволяет подам подключаться к PV, получая таким образом нужное пространство.
PVC как бы говорит: «Эй, Kubernetes, мне нужно столько-то гигабайт пространства, чтобы хранить мои данные, и вот мои требования к доступу». Kubernetes затем связывает этот запрос с подходящим PV, если таковой доступен.
Как это работает вместе? 🤝
Когда приложение нуждается в persistent хранилище, оно создает PVC, а Kubernetes автоматически подбирает подходящий PV или создаёт новый (если используется Dynamic Provisioning). К примеру, если у вас есть Postgres или MySQL под, которому требуется хранение для баз данных, вы создаете PVC на нужное количество гигабайт, и Kubernetes позаботится о том, чтобы связать его с PV, который соответствует запросу. Это делает систему более гибкой - не нужно вручную добавлять диски для каждого нового пода. PVC позволяет разделять заботы об инфраструктуре (создание PV) и приложения (использование PVC).
Вот пример того, как выглядят PV и PVC в Kubernetes YAML-файлах:
# Persistent Volume
apiVersion: v1
kind: PersistentVolume
metadata:
name: example-pv
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/data/example-pv"
# Persistent Volume Claim
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: example-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
В этом примере мы сначала создаём PV на 10ГБ и указываем, что его можно использовать только с одним подом (ReadWriteOnce). Далее создается PVC, который «просит» доступ к 10ГБ с такими же параметрами доступа, и Kubernetes связывает их автоматически.
Зачем надо понимать низкоуровневые детали хранения данных в Kubernetes?
Некоторыетаксистыспрашивают зачем нужно разбираться в таких вещах, как Persistent Volumes и их конфигурация. Неужели вам, как разработчику, нужно понимать все нюансы инфраструктуры, чтобы просто создать pod, или же это можно оставить на усмотрение DevOps/infrastructure engineer? 🔧
На первый взгляд, кажется, что концепция Kubernetes противоречит самой себе, типа Kubernetes стремится абстрагировать инфраструктуру и предоставить единый интерфейс для разработки и управления приложениями. Но в реальности, многие детали инфраструктуры, такие как NFS-сервер, параметры PV, и тому подобные вещи, приходится указывать прямо в манифесте пода. Это делает под зависимым от конкретной инфраструктуры и снижает его переносимость 🤸. Например, если указать в манифесте пода hostname NFS-сервера, этот под не сможет быть развернут без изменений в другом кластере с другой конфигурацией.
К счастью, Kubernetes предлагает способ, который позволяет разделить ответственность за настройку и использование внешних хранилищ между администраторами и разработчиками. Существуют два ключевых уровня:
1. Низкоуровневая настройка хранилища ▿ это область ответственности администраторов кластера. Они настраивают и управляют конкретными PV, решая, как и где будет храниться информация. В этом случае администраторы создают PV и указывают все необходимые параметры (например, конкретный NFS-сервер или параметры для динамического выделения места).
2. Высокоуровневое определение требований △ то, что делают разработчики. Они не указывают точные настройки хранилища, а лишь описывают, какой объем данных требуется их приложению, и какие условия доступа необходимы. С помощью PVC разработчик может просто запросить хранилище нужного размера, с необходимыми правами доступа, а Kubernetes самостоятельно выберет подходящий PV, связав запрос с доступным ресурсом.
Таким образом, разработчику нет необходимости напрямую взаимодействовать с низкоуровневыми аспектами хранения. Он может просто создать PVC, описав свои нужды, а Kubernetes обеспечит, чтобы хранилище было предоставлено согласно требованиям. Вместо указания конкретных параметров хранилища в каждом манифесте, разработчик задает общие требования в PVC. Это позволяет легко перенести приложение между кластерами, так как манифест не содержит привязок к конкретной инфраструктуре.
Kubernetes таким образом действительно абстрагирует инфраструктуру, но в то же время предоставляет гибкость, необходимую для настройки сложных, устойчивых к отказам приложений.
Подытожим
• PV — это физическое или виртуальное хранилище на уровне кластера, созданное администратором.
• PVC — это запрос на доступ к хранилищу от приложений.
• Автоматизация: благодаря Dynamic Provisioning Kubernetes может автоматически создавать PV на основе PVC, что сильно упрощает управление хранилищем в масштабах.
Некоторые
На первый взгляд, кажется, что концепция Kubernetes противоречит самой себе, типа Kubernetes стремится абстрагировать инфраструктуру и предоставить единый интерфейс для разработки и управления приложениями. Но в реальности, многие детали инфраструктуры, такие как NFS-сервер, параметры PV, и тому подобные вещи, приходится указывать прямо в манифесте пода. Это делает под зависимым от конкретной инфраструктуры и снижает его переносимость 🤸. Например, если указать в манифесте пода hostname NFS-сервера, этот под не сможет быть развернут без изменений в другом кластере с другой конфигурацией.
...
volumes:
- name: remote-data
nfs:
server: 1.2.3.4
path: /some/path
...
К счастью, Kubernetes предлагает способ, который позволяет разделить ответственность за настройку и использование внешних хранилищ между администраторами и разработчиками. Существуют два ключевых уровня:
1. Низкоуровневая настройка хранилища ▿ это область ответственности администраторов кластера. Они настраивают и управляют конкретными PV, решая, как и где будет храниться информация. В этом случае администраторы создают PV и указывают все необходимые параметры (например, конкретный NFS-сервер или параметры для динамического выделения места).
2. Высокоуровневое определение требований △ то, что делают разработчики. Они не указывают точные настройки хранилища, а лишь описывают, какой объем данных требуется их приложению, и какие условия доступа необходимы. С помощью PVC разработчик может просто запросить хранилище нужного размера, с необходимыми правами доступа, а Kubernetes самостоятельно выберет подходящий PV, связав запрос с доступным ресурсом.
Таким образом, разработчику нет необходимости напрямую взаимодействовать с низкоуровневыми аспектами хранения. Он может просто создать PVC, описав свои нужды, а Kubernetes обеспечит, чтобы хранилище было предоставлено согласно требованиям. Вместо указания конкретных параметров хранилища в каждом манифесте, разработчик задает общие требования в PVC. Это позволяет легко перенести приложение между кластерами, так как манифест не содержит привязок к конкретной инфраструктуре.
Kubernetes таким образом действительно абстрагирует инфраструктуру, но в то же время предоставляет гибкость, необходимую для настройки сложных, устойчивых к отказам приложений.
Подытожим
• PV — это физическое или виртуальное хранилище на уровне кластера, созданное администратором.
• PVC — это запрос на доступ к хранилищу от приложений.
• Автоматизация: благодаря Dynamic Provisioning Kubernetes может автоматически создавать PV на основе PVC, что сильно упрощает управление хранилищем в масштабах.
GitHub репозиторий: Project Based Learning
👾 Сегодня наткнулся на отличный GitHub репозиторий - Project Based Learning. Это целая куча учебных материалов, ориентированных на изучение программирования через проекты. Как по мне, это самый продуктивный подход: сразу работать над реальными задачами и не застревать на скучной теории (которая забывается с вероятностью 101% если ее не подкреплять практикой).
В этом репозитории есть проекты для самых разных языков программирования, и раздел для Python меня особенно зацепил. Для всех, кто хочет прокачать свои навыки в Python, тут найдется масса интересных и полезных проектов — от парсинга данных и создания веб-приложений до сложных задач по машинному обучению и работе с нейронными сетями.
Вот несколько разделов и проектов, которые мне показались интересными:
- Web Scraping 🔧: от простых парсеров сайтов с BeautifulSoup до продвинутых решений с Selenium и Scrapy.
- Web Applications 🌐: проекты по созданию блогов и чатов с Flask и Django, а также микросервисов и API.
- Data Science и Machine Learning 🤖: тут можно погрузиться в анализ данных, написать линейную регрессию с нуля или построить рекомендации.
- OpenCV 👀: для тех, кто хочет освоить обработку изображений, есть проекты для сканирования документов, распознавания лиц и даже детектирования фальшивых новостей.
- Deep Learning 🧠: много примеров работы с нейронными сетями — от построения простых CNN до детекторов объектов и масок.
- Miscellaneous 🔮: тут тоже очень много интересного, например, создание интерпретатора, игры «Жизнь», терминальных игр типа «Змейка», и даже построение блокчейна!
Особо хочу выделить проект для начинающих, который сразу привлек мое внимание: Programming Projects for Advanced Beginners #3a: Tic-Tac-Toe AI (ссылка). Это пошаговое руководство по созданию ИИ для крестиков-ноликов, где объясняется не только код, но и логика создания базового ИИ. Прекрасный проект для прокачки навыков и понимания того, как работает алгоритм принятия решений.
Этот репозиторий — просто находка для тех, кто хочет учиться через практику. Советую всем взглянуть, если хотите прокачать навыки программирования! 🚀
👾 Сегодня наткнулся на отличный GitHub репозиторий - Project Based Learning. Это целая куча учебных материалов, ориентированных на изучение программирования через проекты. Как по мне, это самый продуктивный подход: сразу работать над реальными задачами и не застревать на скучной теории (которая забывается с вероятностью 101% если ее не подкреплять практикой).
В этом репозитории есть проекты для самых разных языков программирования, и раздел для Python меня особенно зацепил. Для всех, кто хочет прокачать свои навыки в Python, тут найдется масса интересных и полезных проектов — от парсинга данных и создания веб-приложений до сложных задач по машинному обучению и работе с нейронными сетями.
Вот несколько разделов и проектов, которые мне показались интересными:
- Web Scraping 🔧: от простых парсеров сайтов с BeautifulSoup до продвинутых решений с Selenium и Scrapy.
- Web Applications 🌐: проекты по созданию блогов и чатов с Flask и Django, а также микросервисов и API.
- Data Science и Machine Learning 🤖: тут можно погрузиться в анализ данных, написать линейную регрессию с нуля или построить рекомендации.
- OpenCV 👀: для тех, кто хочет освоить обработку изображений, есть проекты для сканирования документов, распознавания лиц и даже детектирования фальшивых новостей.
- Deep Learning 🧠: много примеров работы с нейронными сетями — от построения простых CNN до детекторов объектов и масок.
- Miscellaneous 🔮: тут тоже очень много интересного, например, создание интерпретатора, игры «Жизнь», терминальных игр типа «Змейка», и даже построение блокчейна!
Особо хочу выделить проект для начинающих, который сразу привлек мое внимание: Programming Projects for Advanced Beginners #3a: Tic-Tac-Toe AI (ссылка). Это пошаговое руководство по созданию ИИ для крестиков-ноликов, где объясняется не только код, но и логика создания базового ИИ. Прекрасный проект для прокачки навыков и понимания того, как работает алгоритм принятия решений.
Этот репозиторий — просто находка для тех, кто хочет учиться через практику. Советую всем взглянуть, если хотите прокачать навыки программирования! 🚀
GitHub
GitHub - practical-tutorials/project-based-learning: Curated list of project-based tutorials
Curated list of project-based tutorials. Contribute to practical-tutorials/project-based-learning development by creating an account on GitHub.
Основные новинки GitHub с конференции Universe 2024: что полезно для DevOps.
GitHub Copilot X выходит на новый уровень 🆙
Те, кто уже поработал с GitHub Copilot, могут ждать нечто большее, чем просто автодополнение. Новые функции Copilot X делают его настоящим «умным помощником». Он теперь поддерживает ChatGPT-стиль общения, может анализировать кодовые базы, отвечать на вопросы по репозиторию и даже генерировать pull request’ы. Теперь не нужно прыгать между документацией и кодом, Copilot X может подсказать решения и поможет разобраться с сложными участками кода. Ускоряем разработку и уменьшаем когнитивную нагрузку (trends).
GitHub Code Search — быстрая навигация по коду 🔎
Новая система поиска в коде на GitHub значительно улучшена, позволяя быстрее находить и ключевые файлы, и определенные функции или методы. Code Search теперь может использовать AI-поддержку для выдачи более релевантных результатов, и это облегчает поиск нужных частей в огромных кодовых базах. Для DevOps это означает ускорение работы с многослойными проектами и, конечно, уменьшение времени на понимание кода.
Actions Importer — миграция на GitHub Actions становится проще 📥
Представили инструмент Actions Importer, который упрощает процесс миграции на GitHub Actions. В одном из сових проектов мы используем GitHub Actions, хорошо что переезжать никуда не надо (полгода назад кстати мигрировали из жиры). Теперь, если у вас были пайплайны на других CI/CD системах, вы можете импортировать их в GitHub практически без боли и адаптации. Actions Importer анализирует конфигурации и предлагает оптимизированные варианты миграции. Ок.
Private Repositories для GitHub Pages📄
Добавили возможность использовать приватные репозитории для GitHub Pages. Это даст возможность командам и организациям размещать документацию, ресурсы и прочий контент только для внутреннего пользования. Я сам лично не пользовался этой фичой но знаю кто плотно на ней сидит. Теперь можно создавать и тестировать конфиденциальные проекты, не опасаясь, что информация станет общедоступной. Отличная новость для тех, кто хочет поддерживать свою внутреннюю документацию и ресурсы в безопасности.
GitHub Enterprise расширяет возможности командной работы 🏦
GitHub Enterprise получил несколько обновлений, направленных на улучшение командной работы. Улучшены инструменты аналитики, безопасности и управления пользователями. Нам не сильно важно.
GitHub в 2024 году продолжает развиваться в сторону умного и автоматизированного инструмента, который понимает разработчика и помогает ему на всех этапах работы с кодом. С такими улучшениями работа становится не только эффективнее, но и, как минимум, интереснее.
GitHub Copilot X выходит на новый уровень 🆙
Те, кто уже поработал с GitHub Copilot, могут ждать нечто большее, чем просто автодополнение. Новые функции Copilot X делают его настоящим «умным помощником». Он теперь поддерживает ChatGPT-стиль общения, может анализировать кодовые базы, отвечать на вопросы по репозиторию и даже генерировать pull request’ы. Теперь не нужно прыгать между документацией и кодом, Copilot X может подсказать решения и поможет разобраться с сложными участками кода. Ускоряем разработку и уменьшаем когнитивную нагрузку (trends).
GitHub Code Search — быстрая навигация по коду 🔎
Новая система поиска в коде на GitHub значительно улучшена, позволяя быстрее находить и ключевые файлы, и определенные функции или методы. Code Search теперь может использовать AI-поддержку для выдачи более релевантных результатов, и это облегчает поиск нужных частей в огромных кодовых базах. Для DevOps это означает ускорение работы с многослойными проектами и, конечно, уменьшение времени на понимание кода.
Actions Importer — миграция на GitHub Actions становится проще 📥
Представили инструмент Actions Importer, который упрощает процесс миграции на GitHub Actions. В одном из сових проектов мы используем GitHub Actions, хорошо что переезжать никуда не надо (полгода назад кстати мигрировали из жиры). Теперь, если у вас были пайплайны на других CI/CD системах, вы можете импортировать их в GitHub практически без боли и адаптации. Actions Importer анализирует конфигурации и предлагает оптимизированные варианты миграции. Ок.
Private Repositories для GitHub Pages📄
Добавили возможность использовать приватные репозитории для GitHub Pages. Это даст возможность командам и организациям размещать документацию, ресурсы и прочий контент только для внутреннего пользования. Я сам лично не пользовался этой фичой но знаю кто плотно на ней сидит. Теперь можно создавать и тестировать конфиденциальные проекты, не опасаясь, что информация станет общедоступной. Отличная новость для тех, кто хочет поддерживать свою внутреннюю документацию и ресурсы в безопасности.
GitHub Enterprise расширяет возможности командной работы 🏦
GitHub Enterprise получил несколько обновлений, направленных на улучшение командной работы. Улучшены инструменты аналитики, безопасности и управления пользователями. Нам не сильно важно.
GitHub в 2024 году продолжает развиваться в сторону умного и автоматизированного инструмента, который понимает разработчика и помогает ему на всех этапах работы с кодом. С такими улучшениями работа становится не только эффективнее, но и, как минимум, интереснее.
Деплоил Grafana через Helm: история о том, как yaml формат почти победил меня (но нет) 🛠
Задача была задеплоить Grafana в Kubernetes с использованием Helm. Казалось бы, задача простая: есть готовый чарт, пара строк в values.yaml, и всё должно взлететь. Но сложности начались сразу после того, как я открыл документацию. Давайте погрузимся в моё путешествие от полного хаоса (несколько дней упорного пересобирания образов и чартов) к долгожданному успеху.
Первая попытка: «Сейчас я с корешом GPT все за 5 минут сделаю»
Начал я уверенно: создал values.yaml, прописал ключевые параметры — админские креды, persistence, ingress и так далее:
🚀 helm install, и я уже готов был праздновать победу. Но не тут-то было. В логах kubectl я вижу
Оказывается, Grafana даже не успела нормально стартовать, а логин с admin:admin_password просто не работал.
Разбор полётов: где мои ENV?
Посмотрев на ENV переменные, я понял, что мои adminUser и adminPassword вообще не применились:
WTF?! Почему вместо моего пароля используется какой-то рандомный? 🙃
Вторая попытка: давайте всёначнем сначала исправим
Решил пересмотреть документацию. Скопировал пример values.yaml, добавил existingSecret:
Создал секрет:
Снова helm upgrade, снова фиаско. Grafana всё ещё брала дефолтный секрет, а мои изменения не применялись. Оказалось, что Helm генерирует свой секрет при деплое, и даже с existingSecret он продолжал перезаписывать мои ENV.
Третья попытка: битва с values.yaml
После долгих часов дебага (и нескольких перезапусков контейнера) я наконец понял корень проблемы: параметры не должны были быть в секции grafana:, их нужно было выносить в корень values.yaml. Вот правильная структура:
Финал: всё заработало! 🎉
После правки структуры и ещё одного перезапуска с корректным values.yaml Grafana наконец-то зажила. Логин заработал, readiness-пробы прошли успешно, а я почувствовал себя настоящим победителем.
Выводы:
1. Внимательно следи за структурой values.yaml! Если параметры не в том месте — Helm их просто игнорирует.
2. Доверяй, но проверяй: после каждого деплоя проверяйте ENV и манифесты.
3. Helm — мощный инструмент, но с ним легко запутаться.
Если бы я сразу всё сделал правильно, сэкономил бы часы на деплой. Но зато теперь у меня есть история, как я поборол Helm и Grafana, а также ещё один кейс для блога 😅
Задача была задеплоить Grafana в Kubernetes с использованием Helm. Казалось бы, задача простая: есть готовый чарт, пара строк в values.yaml, и всё должно взлететь. Но сложности начались сразу после того, как я открыл документацию. Давайте погрузимся в моё путешествие от полного хаоса (несколько дней упорного пересобирания образов и чартов) к долгожданному успеху.
Первая попытка: «Сейчас я с корешом GPT все за 5 минут сделаю»
Начал я уверенно: создал values.yaml, прописал ключевые параметры — админские креды, persistence, ingress и так далее:
grafana:
enabled: true
adminUser: admin
adminPassword: admin_password
ingress:
enabled: true
hosts:
- grafana.example.com
🚀 helm install, и я уже готов был праздновать победу. Но не тут-то было. В логах kubectl я вижу
• Readiness probe failed: connection refused
• Invalid username or password
Оказывается, Grafana даже не успела нормально стартовать, а логин с admin:admin_password просто не работал.
Разбор полётов: где мои ENV?
Посмотрев на ENV переменные, я понял, что мои adminUser и adminPassword вообще не применились:
kubectl exec -it <grafana-pod> -- env | grep GF_SECURITY_ADMIN
GF_SECURITY_ADMIN_USER=admin
GF_SECURITY_ADMIN_PASSWORD=random_generated_password
WTF?! Почему вместо моего пароля используется какой-то рандомный? 🙃
Вторая попытка: давайте всё
Решил пересмотреть документацию. Скопировал пример values.yaml, добавил existingSecret:
grafana:
admin:
existingSecret: grafana-admin
userKey: admin-user
passwordKey: admin-password
Создал секрет:
kubectl create secret generic grafana-admin \
--from-literal=admin-user=admin \
--from-literal=admin-password=admin_password
Снова helm upgrade, снова фиаско. Grafana всё ещё брала дефолтный секрет, а мои изменения не применялись. Оказалось, что Helm генерирует свой секрет при деплое, и даже с existingSecret он продолжал перезаписывать мои ENV.
Третья попытка: битва с values.yaml
После долгих часов дебага (и нескольких перезапусков контейнера) я наконец понял корень проблемы: параметры не должны были быть в секции grafana:, их нужно было выносить в корень values.yaml. Вот правильная структура:
enabled: true
adminUser: admin
adminPassword: admin_password
persistence:
enabled: true
size: 10Gi
ingress:
enabled: true
hosts:
- grafana.example.com
Финал: всё заработало! 🎉
После правки структуры и ещё одного перезапуска с корректным values.yaml Grafana наконец-то зажила. Логин заработал, readiness-пробы прошли успешно, а я почувствовал себя настоящим победителем.
Выводы:
1. Внимательно следи за структурой values.yaml! Если параметры не в том месте — Helm их просто игнорирует.
2. Доверяй, но проверяй: после каждого деплоя проверяйте ENV и манифесты.
3. Helm — мощный инструмент, но с ним легко запутаться.
Если бы я сразу всё сделал правильно, сэкономил бы часы на деплой. Но зато теперь у меня есть история, как я поборол Helm и Grafana, а также ещё один кейс для блога 😅
👍1
ConfigMaps: как отвязать конфигурацию от подов
В Kubernetes одна из ключевых практик — это отделение конфигурации от приложений. Представьте, что у вас есть под, который нужно деплоить в разных окружениях: dev, staging и production. Если в каждой манифесте прописывать уникальные переменные, это превращается в настоящий кошмар. В таких случаях на помощь приходит ConfigMap.
Что такое ConfigMap?
ConfigMap — это объект API Kubernetes, который позволяет хранить пары ключ/значение. Сюда можно поместить строки, файлы или даже целые блоки конфигурации. Поды могут ссылаться на ConfigMap и получать значения переменных, что позволяет одному и тому же поду работать с разными конфигурациями.
Зачем это нужно?
Вы можете использовать один и тот же манифест пода во всех окружениях, подключая к нему разные ConfigMaps. Так конфигурация остается гибкой и централизованной. Подключить ConfigMap можно двумя способами:
• Через переменные окружения, которые подхватывает контейнер.
• Через volume, когда данные из ConfigMap монтируются как файлы.
Создание ConfigMap
ConfigMap можно создать несколькими способами:
1. Из манифеста YAML:
Применяем файл:
2. Через команду kubectl:
3. С использованием файлов:
Если у вас есть конфигурационный файл myconfig.txt, его можно подключить с помощью --from-file:
Команды для работы с ConfigMap
Чтобы посмотреть список всех ConfigMaps, достаточно выполнить:
А чтобы увидеть содержимое конкретного ConfigMap в формате YAML:
Совет: Если нужно вывести только данные, используйте jq:
Применение ConfigMap в разных окружениях
Суть в том, что ConfigMap позволяет избежать копипаста манифестов. Вы можете использовать один под-манифест и разные ConfigMaps в dev, staging и production окружениях. Под подключается к конфигурации по имени ConfigMap, и на каждом этапе окружение получает свои уникальные значения.
Итог: меньше ошибок, больше контроля над конфигурацией и чистые манифесты. А главное — DevOps становится чуть более удобным!
В Kubernetes одна из ключевых практик — это отделение конфигурации от приложений. Представьте, что у вас есть под, который нужно деплоить в разных окружениях: dev, staging и production. Если в каждой манифесте прописывать уникальные переменные, это превращается в настоящий кошмар. В таких случаях на помощь приходит ConfigMap.
Что такое ConfigMap?
ConfigMap — это объект API Kubernetes, который позволяет хранить пары ключ/значение. Сюда можно поместить строки, файлы или даже целые блоки конфигурации. Поды могут ссылаться на ConfigMap и получать значения переменных, что позволяет одному и тому же поду работать с разными конфигурациями.
Зачем это нужно?
Вы можете использовать один и тот же манифест пода во всех окружениях, подключая к нему разные ConfigMaps. Так конфигурация остается гибкой и централизованной. Подключить ConfigMap можно двумя способами:
• Через переменные окружения, которые подхватывает контейнер.
• Через volume, когда данные из ConfigMap монтируются как файлы.
Создание ConfigMap
ConfigMap можно создать несколькими способами:
1. Из манифеста YAML:
apiVersion: v1
kind: ConfigMap
metadata:
name: kiada-config
data:
status-message: This status message is set in the kiada-config config map Применяем файл:
kubectl apply -f cm.kiada-config.yaml2. Через команду kubectl:
kubectl create configmap kiada-config --from-literal=status-message="This status message is set in the kiada-config config map"3. С использованием файлов:
Если у вас есть конфигурационный файл myconfig.txt, его можно подключить с помощью --from-file:
kubectl create configmap my-config --from-file=myconfig.txtКоманды для работы с ConfigMap
Чтобы посмотреть список всех ConfigMaps, достаточно выполнить:
kubectl get cmА чтобы увидеть содержимое конкретного ConfigMap в формате YAML:
kubectl get cm kiada-config -o yamlСовет: Если нужно вывести только данные, используйте jq:
kubectl get cm kiada-config -o json | jq .dataПрименение ConfigMap в разных окружениях
Суть в том, что ConfigMap позволяет избежать копипаста манифестов. Вы можете использовать один под-манифест и разные ConfigMaps в dev, staging и production окружениях. Под подключается к конфигурации по имени ConfigMap, и на каждом этапе окружение получает свои уникальные значения.
Итог: меньше ошибок, больше контроля над конфигурацией и чистые манифесты. А главное — DevOps становится чуть более удобным!
👍1
Azure Data Studio: Инструмент для работы с данными в стиле DevOps 🤖
В работе с данными на backend кластерах Kusto и SQL для меня было важно выбрать инструмент, который не только позволяет эффективно взаимодействовать с удалёнными серверами, но и упрощает визуализацию и анализ. Для этого я использую Azure Data Studio — и сегодня хочу рассказать, чем он хорош и где его приходится терпеть.
Что нравится? 👍
1. Jupyter-подобные ноутбуки 🪐
Люблю ноутбуки в стиле Jupyter, и Azure Data Studio в этом плане не разочаровывает. Можно удобно комбинировать код, результаты запросов и визуализацию прямо в одном документе. Это особенно полезно, когда нужно быстро протестировать гипотезы или поделиться результатами с командой. Смотрим скриншоты в коментах.
2. Визуализация данных 💡
Иногда сухие цифры говорят меньше, чем хорошо построенный график. ADS предлагает встроенные инструменты визуализации, что позволяет быстро преобразовывать результаты запросов в наглядные диаграммы. Не надо прыгать в Excel или какие-то внешние тулзы.
3. Подключение к удалённым серверам 🌍
Azure Data Studio отлично работает с удалёнными Kusto и SQL серверами. Настроил соединение — и работай без необходимости вручную переключаться между разными инструментами. Это особенно ценно, если вы в DevOps контексте, где оперативный доступ к данным играет ключевую роль.
Что раздражает? 😠
1. Работа с файлами 📁
Вот тут всё довольно странно. Workflow с файлами в ADS оставляет желать лучшего: сохранение и организация документов кажутся неудобными и недостаточно гибкими. У меня каждый раз ощущение, что это могло быть проще, но почему-то приходится мириться с этим “специфическим” подходом.
2. Интеграция с системой контроля версий (CSV) 🔄
Версии и отслеживание изменений в данных — основа современной разработки. ADS поддерживает интеграцию с Git, но всё это реализовано не самым удобным образом. Например, отсутствуют многие привычные мелочи, которые можно встретить в более зрелых IDE. Это замедляет работу, особенно если приходится часто переключаться между ветками или разбираться с конфликтами.
Итог 📝
Несмотря на мелкие недочёты, Azure Data Studio остаётся одним из моих любимых инструментов для работы с данными. Он делает много вещей правильно: от поддержки ноутбуков до удобного подключения к удалённым серверам. Если вы работаете с большими данными в DevOps или просто хотите упростить анализ информации, рекомендую попробовать. А что вы думаете об Azure Data Studio?
В работе с данными на backend кластерах Kusto и SQL для меня было важно выбрать инструмент, который не только позволяет эффективно взаимодействовать с удалёнными серверами, но и упрощает визуализацию и анализ. Для этого я использую Azure Data Studio — и сегодня хочу рассказать, чем он хорош и где его приходится терпеть.
Что нравится? 👍
1. Jupyter-подобные ноутбуки 🪐
Люблю ноутбуки в стиле Jupyter, и Azure Data Studio в этом плане не разочаровывает. Можно удобно комбинировать код, результаты запросов и визуализацию прямо в одном документе. Это особенно полезно, когда нужно быстро протестировать гипотезы или поделиться результатами с командой. Смотрим скриншоты в коментах.
2. Визуализация данных 💡
Иногда сухие цифры говорят меньше, чем хорошо построенный график. ADS предлагает встроенные инструменты визуализации, что позволяет быстро преобразовывать результаты запросов в наглядные диаграммы. Не надо прыгать в Excel или какие-то внешние тулзы.
3. Подключение к удалённым серверам 🌍
Azure Data Studio отлично работает с удалёнными Kusto и SQL серверами. Настроил соединение — и работай без необходимости вручную переключаться между разными инструментами. Это особенно ценно, если вы в DevOps контексте, где оперативный доступ к данным играет ключевую роль.
Что раздражает? 😠
1. Работа с файлами 📁
Вот тут всё довольно странно. Workflow с файлами в ADS оставляет желать лучшего: сохранение и организация документов кажутся неудобными и недостаточно гибкими. У меня каждый раз ощущение, что это могло быть проще, но почему-то приходится мириться с этим “специфическим” подходом.
2. Интеграция с системой контроля версий (CSV) 🔄
Версии и отслеживание изменений в данных — основа современной разработки. ADS поддерживает интеграцию с Git, но всё это реализовано не самым удобным образом. Например, отсутствуют многие привычные мелочи, которые можно встретить в более зрелых IDE. Это замедляет работу, особенно если приходится часто переключаться между ветками или разбираться с конфликтами.
Итог 📝
Несмотря на мелкие недочёты, Azure Data Studio остаётся одним из моих любимых инструментов для работы с данными. Он делает много вещей правильно: от поддержки ноутбуков до удобного подключения к удалённым серверам. Если вы работаете с большими данными в DevOps или просто хотите упростить анализ информации, рекомендую попробовать. А что вы думаете об Azure Data Studio?
❤🔥1
Secrets vs ConfigMaps в Kubernetes: когда что использовать?
В мире Kubernetes, где каждый элемент кластера нацелен на безопасность и масштабируемость, хранение чувствительных данных — отдельный челлендж. Сейчас разберёмся в различиях между ConfigMap и Secret, а также когда лучше использовать каждый из них.
Общие черты ConfigMap и Secret
На первый взгляд, ConfigMap и Secret кажутся схожими: оба ресурса Kubernetes хранят пары ключ-значение, которые можно монтировать в контейнеры или использовать как переменные окружения. Тем не менее, они имеют разные цели и особенности.
Основные различия
• ConfigMap используется для хранения некритичной конфигурации, например, параметров приложения или переменных окружения.
• Secret предназначен для хранения чувствительных данных: паролей, токенов и сертификатов. Эти данные кодируются в формате Base64, что помогает минимизировать риски случайно слить этот секрет.
Ключевые различия можно представить так:
Свойство ConfigMap Secret
data Строковые данные Base64-данные
stringData Нет Есть
immutable Поддерживается Поддерживается
type Нет Может быть указан (например, Opaque)
Типы Secret
Secrets поддерживают несколько встроенных типов, которые оптимизированы под определённые задачи:
• Opaque — универсальный тип для любых данных.
• bootstrap.kubernetes.io/token — токены для начальной настройки кластера.
• kubernetes.io/tls — хранение TLS-сертификатов.
• kubernetes.io/service-account-token — токены для сервисных аккаунтов.
Эти типы помогают Kubernetes понимать, как именно использовать секрет.
Когда что использовать?
• Используйте ConfigMap для конфигурационных данных, которые не содержат критичной информации. Например файл .ENV где хранятся параметры вашего питон аппа.
• Используйте Secret для любого чувствительного контента. Даже если данные кажутся безобидными, лучше перестраховаться и хранить их в Secret.
Как всегда, «простые решения для сложных задач» — ваш путь к мастерству в DevOps!
В мире Kubernetes, где каждый элемент кластера нацелен на безопасность и масштабируемость, хранение чувствительных данных — отдельный челлендж. Сейчас разберёмся в различиях между ConfigMap и Secret, а также когда лучше использовать каждый из них.
Общие черты ConfigMap и Secret
На первый взгляд, ConfigMap и Secret кажутся схожими: оба ресурса Kubernetes хранят пары ключ-значение, которые можно монтировать в контейнеры или использовать как переменные окружения. Тем не менее, они имеют разные цели и особенности.
Основные различия
• ConfigMap используется для хранения некритичной конфигурации, например, параметров приложения или переменных окружения.
• Secret предназначен для хранения чувствительных данных: паролей, токенов и сертификатов. Эти данные кодируются в формате Base64, что помогает минимизировать риски случайно слить этот секрет.
Ключевые различия можно представить так:
Свойство ConfigMap Secret
data Строковые данные Base64-данные
stringData Нет Есть
immutable Поддерживается Поддерживается
type Нет Может быть указан (например, Opaque)
Типы Secret
Secrets поддерживают несколько встроенных типов, которые оптимизированы под определённые задачи:
• Opaque — универсальный тип для любых данных.
• bootstrap.kubernetes.io/token — токены для начальной настройки кластера.
• kubernetes.io/tls — хранение TLS-сертификатов.
• kubernetes.io/service-account-token — токены для сервисных аккаунтов.
Эти типы помогают Kubernetes понимать, как именно использовать секрет.
Когда что использовать?
• Используйте ConfigMap для конфигурационных данных, которые не содержат критичной информации. Например файл .ENV где хранятся параметры вашего питон аппа.
• Используйте Secret для любого чувствительного контента. Даже если данные кажутся безобидными, лучше перестраховаться и хранить их в Secret.
Как всегда, «простые решения для сложных задач» — ваш путь к мастерству в DevOps!
👏2
Зарплаты IT-директоров: сколько стоит управлять технологиями? 💸
На днях наткнулся на исследование о зарплатах московских IT-директоров, и цифры, мягко говоря, впечатляют. Говорим о цифрах от 800 тысяч до 2 миллионов рублей в месяц. Да, в месяц. Для сравнения, средний DevOps-инженер получает 200–400 тысяч рублей, а тут уровень космоса. Разбираемся, почему так дорого.
Почему IT-директора получают миллионы? 🍋
1. Ответственность уровня C-level. 🔑
IT-директор — это не просто технарь с навыками управления. Это стратег, который определяет, куда пойдут технологии компании. Один неверный шаг — и ваш бизнес может отстать на годы. От них требуют не только знания Kubernetes и облаков, но и понимание финансов, маркетинга и корпоративных процессов.
2. Конкуренция за таланты. 🎭
Сегодня IT-директоры нужны всем: от банков до ретейла. Те, кто может одновременно держать в голове стратегию цифровой трансформации, управлять командой и понимать, что такое финтех, стоят на вес золота.
3. Рост технологической сложности. 💻
Управлять IT-инфраструктурой в 2024 году — это уже не про «сервер работает, всё в порядке». Компании переходят на гибридные облака, внедряют AI, работают с миллионами запросов в секунду. И кто-то должен этим всем руководить.
Какие навыки ценят? 🤹
В топе требований:
• Технологическая экспертиза. Микросервисы, облака, безопасность, DevSecOps — всё это обязательно.
• Управление командой. Найти подход к каждому, не забывая про дедлайны и бюджеты.
• Бизнес-ориентированность. IT-директор должен говорить с генеральным директором на одном языке.
Куда катится рынок? 💹
Миллионные зарплаты IT-директоров — это индикатор роста важности технологий в бизнесе. Если раньше IT был вспомогательной функцией, то теперь он — двигатель бизнеса. Без грамотного IT-руководства компания теряет не только деньги, но и место на рынке.
Вывод? Растите навыки и смотрите в сторону менеджмента, если хотите войти в этот элитный клуб. А пока — продолжайте изучать Kubernetes и Terraform. Кто знает, возможно, в будущем кто-то из нас станет тем самым IT-директором с зарплатой в 2 миллиона.
Что думаете? Сильно ли нас переоценили или, наоборот, заслужили? Делитесь мыслями в комментариях! 💬
На днях наткнулся на исследование о зарплатах московских IT-директоров, и цифры, мягко говоря, впечатляют. Говорим о цифрах от 800 тысяч до 2 миллионов рублей в месяц. Да, в месяц. Для сравнения, средний DevOps-инженер получает 200–400 тысяч рублей, а тут уровень космоса. Разбираемся, почему так дорого.
Почему IT-директора получают миллионы? 🍋
1. Ответственность уровня C-level. 🔑
IT-директор — это не просто технарь с навыками управления. Это стратег, который определяет, куда пойдут технологии компании. Один неверный шаг — и ваш бизнес может отстать на годы. От них требуют не только знания Kubernetes и облаков, но и понимание финансов, маркетинга и корпоративных процессов.
2. Конкуренция за таланты. 🎭
Сегодня IT-директоры нужны всем: от банков до ретейла. Те, кто может одновременно держать в голове стратегию цифровой трансформации, управлять командой и понимать, что такое финтех, стоят на вес золота.
3. Рост технологической сложности. 💻
Управлять IT-инфраструктурой в 2024 году — это уже не про «сервер работает, всё в порядке». Компании переходят на гибридные облака, внедряют AI, работают с миллионами запросов в секунду. И кто-то должен этим всем руководить.
Какие навыки ценят? 🤹
В топе требований:
• Технологическая экспертиза. Микросервисы, облака, безопасность, DevSecOps — всё это обязательно.
• Управление командой. Найти подход к каждому, не забывая про дедлайны и бюджеты.
• Бизнес-ориентированность. IT-директор должен говорить с генеральным директором на одном языке.
Куда катится рынок? 💹
Миллионные зарплаты IT-директоров — это индикатор роста важности технологий в бизнесе. Если раньше IT был вспомогательной функцией, то теперь он — двигатель бизнеса. Без грамотного IT-руководства компания теряет не только деньги, но и место на рынке.
Вывод? Растите навыки и смотрите в сторону менеджмента, если хотите войти в этот элитный клуб. А пока — продолжайте изучать Kubernetes и Terraform. Кто знает, возможно, в будущем кто-то из нас станет тем самым IT-директором с зарплатой в 2 миллиона.
Что думаете? Сильно ли нас переоценили или, наоборот, заслужили? Делитесь мыслями в комментариях! 💬
👍1