Назовите главные компоненты архитектуры Kubernetes.
Master-ноды (master node, control plane) координируют все операции кластера: управляют распределением и резервированием ресурсов, контролируют состояние контейнеров, управляют масштабированием и выполняют обновления. Компоненты мастер-нод включают:
kube-apiserver — точка доступа к панели управления мастер-ноды, обеспечивает взаимодействие между мастер- и рабочими узлами, отслеживает состояние рабочих узлов и информирует мастер о важных изменениях;
kube-scheduler — отвечает за распределение нагрузки на рабочие узлы, постоянно мониторит доступные ресурсы и используемые ресурсы на каждом узле, принимает решение о запуске нового Pod;
Controller Manager — управляет работой контроллеров, таких как Deployment, ReplicaSet, StatefulSets, DaemonSet, Jobs, CronJob;
ETCD — хранит информацию о настройках и состоянии кластера, его метаданные, представляет собой распределенную базу данных в формате ключ-значение.
Nodes (рабочие узлы) — на них запускаются поды с контейнерами. На каждой worker ноде Kubernetes работают:
kubelet — процесс, который управляет запуском, удалением и обновлением подов с контейнерами;
kube-proxy — настраивает сетевые правила на рабочих узлах.
Как в Kubernetes устроена работа с хранилищами?
Kubernetes имеет различные типы хранилищ, включая встроенный emtyDir. Некоторые из них являются stateless, что означает, что они существуют только во время работы пода. Данные, которые хранятся там, также имеют такой же срок жизни.
Для statefull-приложений используются постоянные хранилища, называемые Persistent Volumes (PV). PV — это запас хранилища, выделенный администратором кластера Kubernetes. Это могут быть локальные диски, СХД или внешние диски. Они не зависят от жизненного цикла подов.
Persistent Volume Claim (PVC) — это запрос на выделение PV с определенными характеристиками, такими как тип хранилища, объем и тип доступа. Для описания доступных PV используются Storage Classes.
В процессе работы под отправляет запрос PVC, который затем обращается к PV и передает его поду.
#devops #девопс
Подпишись 👉@i_DevOps
Master-ноды (master node, control plane) координируют все операции кластера: управляют распределением и резервированием ресурсов, контролируют состояние контейнеров, управляют масштабированием и выполняют обновления. Компоненты мастер-нод включают:
kube-apiserver — точка доступа к панели управления мастер-ноды, обеспечивает взаимодействие между мастер- и рабочими узлами, отслеживает состояние рабочих узлов и информирует мастер о важных изменениях;
kube-scheduler — отвечает за распределение нагрузки на рабочие узлы, постоянно мониторит доступные ресурсы и используемые ресурсы на каждом узле, принимает решение о запуске нового Pod;
Controller Manager — управляет работой контроллеров, таких как Deployment, ReplicaSet, StatefulSets, DaemonSet, Jobs, CronJob;
ETCD — хранит информацию о настройках и состоянии кластера, его метаданные, представляет собой распределенную базу данных в формате ключ-значение.
Nodes (рабочие узлы) — на них запускаются поды с контейнерами. На каждой worker ноде Kubernetes работают:
kubelet — процесс, который управляет запуском, удалением и обновлением подов с контейнерами;
kube-proxy — настраивает сетевые правила на рабочих узлах.
Как в Kubernetes устроена работа с хранилищами?
Kubernetes имеет различные типы хранилищ, включая встроенный emtyDir. Некоторые из них являются stateless, что означает, что они существуют только во время работы пода. Данные, которые хранятся там, также имеют такой же срок жизни.
Для statefull-приложений используются постоянные хранилища, называемые Persistent Volumes (PV). PV — это запас хранилища, выделенный администратором кластера Kubernetes. Это могут быть локальные диски, СХД или внешние диски. Они не зависят от жизненного цикла подов.
Persistent Volume Claim (PVC) — это запрос на выделение PV с определенными характеристиками, такими как тип хранилища, объем и тип доступа. Для описания доступных PV используются Storage Classes.
В процессе работы под отправляет запрос PVC, который затем обращается к PV и передает его поду.
#devops #девопс
Подпишись 👉@i_DevOps
👍13
Подходы к наблюдаемости от Т-Банка
Всем привет. Меня зовут Дима, в Т-Банке я руковожу Центром надежности информационных систем. Мы проводим консультирование, обучаем и внедряем SRE-практики, нанимаем и аттестуем инженеров. В общем, делаем все, чтобы помочь командам Т-Банка — а их уже более 2500 — разрабатывать надежные сервисы для всех категорий пользователей и при этом крепко спать по ночам.
Мониторинг ИТ-систем — важнейшая составляющая надежности. Расскажу о том, какие подходы мы использовали, как и почему пришли к нынешнему состоянию и как планируем развиваться дальше.
https://habr.com/ru/companies/tbank/articles/827470/
#devops #девопс
Подпишись 👉 @i_DevOps
Всем привет. Меня зовут Дима, в Т-Банке я руковожу Центром надежности информационных систем. Мы проводим консультирование, обучаем и внедряем SRE-практики, нанимаем и аттестуем инженеров. В общем, делаем все, чтобы помочь командам Т-Банка — а их уже более 2500 — разрабатывать надежные сервисы для всех категорий пользователей и при этом крепко спать по ночам.
Мониторинг ИТ-систем — важнейшая составляющая надежности. Расскажу о том, какие подходы мы использовали, как и почему пришли к нынешнему состоянию и как планируем развиваться дальше.
https://habr.com/ru/companies/tbank/articles/827470/
#devops #девопс
Подпишись 👉 @i_DevOps
👍5❤1
Media is too big
VIEW IN TELEGRAM
Docker с 0 до 100%. Всё, что нужно знать.
00:00:00 | Intro
00:01:35 | Основы Docker.
00:19:30 | Установка Docker в Linux и Windows.
00:25:40 | Основные команды.
00:54:55 | Управление портами: Port Mapping.
01:08:55 | Переменные в Docker: Environment Variables.
01:20:20 | Постоянные данные: Docker Volumes.
01:48:41 | Сети в Docker. Network.
02:30:11 | Создание своих контейнеров. Dockerfile.
03:40:59 | Docker Compose. Применение.
04:32:28 | Portainer – Web UI для управления Docker.
источник
#devops #девопс
Подпишись 👉@i_DevOps
00:00:00 | Intro
00:01:35 | Основы Docker.
00:19:30 | Установка Docker в Linux и Windows.
00:25:40 | Основные команды.
00:54:55 | Управление портами: Port Mapping.
01:08:55 | Переменные в Docker: Environment Variables.
01:20:20 | Постоянные данные: Docker Volumes.
01:48:41 | Сети в Docker. Network.
02:30:11 | Создание своих контейнеров. Dockerfile.
03:40:59 | Docker Compose. Применение.
04:32:28 | Portainer – Web UI для управления Docker.
источник
#devops #девопс
Подпишись 👉@i_DevOps
👍5
Контейнеризация
От Docker до Kubernetes: историческая ретроспектива
Введение в Docker
Введение в Kubernetes. Часть 1. Установка кластера
Введение в Kubernetes. Часть 2. Поды и сервисы
Введение в Kubernetes. Часть 3. Горизонтальное маштабирование.
Введение в Kubernetes. Часть 4. Отказоустойчивость для клиентов
Введение в Kubernetes. Часть 5. Интеграция с NFS
Что такое операторы в Kubernetes?
источник
#devops #девопс
Подпишись 👉@i_DevOps
От Docker до Kubernetes: историческая ретроспектива
Введение в Docker
Введение в Kubernetes. Часть 1. Установка кластера
Введение в Kubernetes. Часть 2. Поды и сервисы
Введение в Kubernetes. Часть 3. Горизонтальное маштабирование.
Введение в Kubernetes. Часть 4. Отказоустойчивость для клиентов
Введение в Kubernetes. Часть 5. Интеграция с NFS
Что такое операторы в Kubernetes?
источник
#devops #девопс
Подпишись 👉@i_DevOps
👍4
Расскажите, как вы будете запускать приложение в Kubernetes, если из инструментов у вас только kubectl?
Общий процесс запуска приложения в Kubernetes выглядит следующим образом:
1. Сначала необходимо упаковать приложение в контейнер.
2. Далее запускаем контейнер в виде реплик с использованием Deployment.
3. Для доступности приложения в интернете и возможности подключения к нему настраиваем сервис LoadBalancer, который присваивает публичный IP-адрес и позволяет подключаться к кластеру извне.
4. Для маршрутизации трафика через балансировщик создаем Ingress в кластере, описывающий правила маршрутизации, и запускаем Ingress-контроллер.
Все эти шаги можно выполнить с помощью kubectl, используя командную строку. Это императивный способ управления Kubernetes, когда мы явно указываем, что нужно сделать.
В промышленной эксплуатации часто используется декларативный подход, при котором мы описываем желаемое состояние в манифестах, и Kubernetes самостоятельно принимает решения о необходимых действиях. Затем мы применяем эти манифесты с помощью команды kubectl apply.
Terraform Backend. Какой лучше?
AWS S3 — Standard (с блокировкой через DynamoDB). Сохраняет состояние в виде заданного ключа в заданном сегменте на Amazon S3. Этот бэкэнд также поддерживает блокировку состояния и проверку согласованности через DynamoDB.
terraform enterprise — Standard (без блокировки).
etcd — Standard (без блокировки). Сохраняет состояние в etcd 2.x по заданному пути.
etcdv3 — Standard (с блокировкой). Сохраняет состояние в хранилище etcd в виде K/V с заданным префиксом.
gcs — Standard (с блокировкой). Сохраняет состояние как объект в настраиваемом префиксе в заданном сегменте в Google Cloud Storage (GCS). Этот бэкэнд также поддерживает блокировку состояния.
Gitlab Terraform state (с блокировкой). Хранит состояние в Gitlab Terraform state хранилище, используя HTTP протокол и права Gitlab для доступа.
Существуют также и другие Backend для Terraform.
#devops #девопс
Подпишись 👉@i_DevOps
Общий процесс запуска приложения в Kubernetes выглядит следующим образом:
1. Сначала необходимо упаковать приложение в контейнер.
2. Далее запускаем контейнер в виде реплик с использованием Deployment.
3. Для доступности приложения в интернете и возможности подключения к нему настраиваем сервис LoadBalancer, который присваивает публичный IP-адрес и позволяет подключаться к кластеру извне.
4. Для маршрутизации трафика через балансировщик создаем Ingress в кластере, описывающий правила маршрутизации, и запускаем Ingress-контроллер.
Все эти шаги можно выполнить с помощью kubectl, используя командную строку. Это императивный способ управления Kubernetes, когда мы явно указываем, что нужно сделать.
В промышленной эксплуатации часто используется декларативный подход, при котором мы описываем желаемое состояние в манифестах, и Kubernetes самостоятельно принимает решения о необходимых действиях. Затем мы применяем эти манифесты с помощью команды kubectl apply.
Terraform Backend. Какой лучше?
AWS S3 — Standard (с блокировкой через DynamoDB). Сохраняет состояние в виде заданного ключа в заданном сегменте на Amazon S3. Этот бэкэнд также поддерживает блокировку состояния и проверку согласованности через DynamoDB.
terraform enterprise — Standard (без блокировки).
etcd — Standard (без блокировки). Сохраняет состояние в etcd 2.x по заданному пути.
etcdv3 — Standard (с блокировкой). Сохраняет состояние в хранилище etcd в виде K/V с заданным префиксом.
gcs — Standard (с блокировкой). Сохраняет состояние как объект в настраиваемом префиксе в заданном сегменте в Google Cloud Storage (GCS). Этот бэкэнд также поддерживает блокировку состояния.
Gitlab Terraform state (с блокировкой). Хранит состояние в Gitlab Terraform state хранилище, используя HTTP протокол и права Gitlab для доступа.
Существуют также и другие Backend для Terraform.
#devops #девопс
Подпишись 👉@i_DevOps
👍4
Who are you, Platform Engineering: разбираемся с одним из главных технологических трендов. Часть 1
Platform Engineering — один из главных технологических трендов 2024 года. По оценке Gartner, к 2026 году 80% компаний, занимающихся разработкой, будут иметь внутренние платформенные сервисы и команды для повышения эффективности разработки.
Мы в VK Cloud предлагаем Dev Platform — платформу для разработки, которой смогут пользоваться другие компании. В серии статей о методологии Platform Engineering и создании Internal Development Platform (IDP), мы поделимся своим подходом построения платформенных решений, расскажем о сложностях и о том, почему даже правильный подбор компонентов и архитектурных решений для IDP — не панацея.
В первом материале серии начнем с базы — остановимся на трудностях повышения эффективности команд разработки, разберем, что такое Platform Engineering и Internal Development Platform, что дает внедрение комплексных платформ и какие могут быть сложности.
https://habr.com/ru/companies/vk/articles/792368/
#devops #девопс
Подпишись 👉@i_DevOps
Platform Engineering — один из главных технологических трендов 2024 года. По оценке Gartner, к 2026 году 80% компаний, занимающихся разработкой, будут иметь внутренние платформенные сервисы и команды для повышения эффективности разработки.
Мы в VK Cloud предлагаем Dev Platform — платформу для разработки, которой смогут пользоваться другие компании. В серии статей о методологии Platform Engineering и создании Internal Development Platform (IDP), мы поделимся своим подходом построения платформенных решений, расскажем о сложностях и о том, почему даже правильный подбор компонентов и архитектурных решений для IDP — не панацея.
В первом материале серии начнем с базы — остановимся на трудностях повышения эффективности команд разработки, разберем, что такое Platform Engineering и Internal Development Platform, что дает внедрение комплексных платформ и какие могут быть сложности.
https://habr.com/ru/companies/vk/articles/792368/
#devops #девопс
Подпишись 👉@i_DevOps
👍1
Who are you, Platform Engineering. Часть 2: типовая архитектура, варианты и примеры реализации IDP
В докладе Gartner методология Platform Engineering определена в качестве одного из стратегических технологических трендов на 2024 год, что свидетельствует о дальнейшем эволюционном развитии подходов DevOps. Несмотря на это, для многих компаний Platform Engineering и Internal Development Platform (IDP) как один из примеров реализации прохода до сих остается «черным ящиком».
Мы в VK Cloud создаем Dev Platform — платформу разработки, которую могут использовать другие компании. В рамках серии статей мы рассказываем о методологии Platform Engineering и подходах к созданию платформ. В первом материале мы рассказали о том, зачем строить IDP, а в этом перейдем от базовой теории к более прикладным вещам и разберем типовую архитектуру IDP: из чего она состоит и как ее компоненты взаимодействуют между собой. Также рассмотрим, какие продукты могут выступить основой для построения IDP.
https://habr.com/ru/companies/vk/articles/809447/
#devops #девопс
Подпишись 👉@i_DevOps
В докладе Gartner методология Platform Engineering определена в качестве одного из стратегических технологических трендов на 2024 год, что свидетельствует о дальнейшем эволюционном развитии подходов DevOps. Несмотря на это, для многих компаний Platform Engineering и Internal Development Platform (IDP) как один из примеров реализации прохода до сих остается «черным ящиком».
Мы в VK Cloud создаем Dev Platform — платформу разработки, которую могут использовать другие компании. В рамках серии статей мы рассказываем о методологии Platform Engineering и подходах к созданию платформ. В первом материале мы рассказали о том, зачем строить IDP, а в этом перейдем от базовой теории к более прикладным вещам и разберем типовую архитектуру IDP: из чего она состоит и как ее компоненты взаимодействуют между собой. Также рассмотрим, какие продукты могут выступить основой для построения IDP.
https://habr.com/ru/companies/vk/articles/809447/
#devops #девопс
Подпишись 👉@i_DevOps
👍2
Рабочие процессы Арго - паттерны, проверенные на продакшене
Argo Workflows представляет собой отличную платформу для автоматизации инфраструктуры и заменил Jenkins в качестве основного инструмента для выполнения запланированных или управляемых событиями задач автоматизации.
За время работы с Argo Workflows мне приходилось убивать кластеры, ломать рабочие процессы и вообще вносить беспорядок в работу. Я также создал множество рабочих процессов, которые нуждались в рефакторинге, поскольку их стало сложно поддерживать.
Цель этой статьи - поделиться некоторыми уроками, которые я извлек, и некоторыми паттернами, которые я разработал, чтобы помочь вам избежать тех же ошибок, которые совершил я.
https://hodgkins.io/argo-workflow-proven-patterns-from-production
#devops #девопс
Подпишись 👉@i_DevOps
Argo Workflows представляет собой отличную платформу для автоматизации инфраструктуры и заменил Jenkins в качестве основного инструмента для выполнения запланированных или управляемых событиями задач автоматизации.
За время работы с Argo Workflows мне приходилось убивать кластеры, ломать рабочие процессы и вообще вносить беспорядок в работу. Я также создал множество рабочих процессов, которые нуждались в рефакторинге, поскольку их стало сложно поддерживать.
Цель этой статьи - поделиться некоторыми уроками, которые я извлек, и некоторыми паттернами, которые я разработал, чтобы помочь вам избежать тех же ошибок, которые совершил я.
https://hodgkins.io/argo-workflow-proven-patterns-from-production
#devops #девопс
Подпишись 👉@i_DevOps
👍3
Who are you, Platform Engineering. Часть 3: знакомство с Dev Platform
Внутренние платформы разработки (Internal Development Platform, IDP), как один из артефактов реализации платформенного подхода (Platform Engineering), становятся важной точкой роста для многих компаний, занимающихся разработкой: помогают унифицировать стек, снизить нецелевую нагрузку на команды, сократить time-to-market. Поэтому многие компании начинают двигаться в сторону создания своих IDP.
Мы продолжаем серию статей о Platform Engineering и Internal Development Platform (IDP). В первом и втором материалах цикла мы уже рассмотрели базовую теорию, познакомились с типовой архитектурой IDP и вариантами реализации. А в этой статье остановимся на обзоре Dev Platform, разрабатываемой командой VK Cloud.
https://habr.com/ru/companies/vk/articles/827022/
#devops #девопс
Подпишись 👉@i_DevOps
Внутренние платформы разработки (Internal Development Platform, IDP), как один из артефактов реализации платформенного подхода (Platform Engineering), становятся важной точкой роста для многих компаний, занимающихся разработкой: помогают унифицировать стек, снизить нецелевую нагрузку на команды, сократить time-to-market. Поэтому многие компании начинают двигаться в сторону создания своих IDP.
Мы продолжаем серию статей о Platform Engineering и Internal Development Platform (IDP). В первом и втором материалах цикла мы уже рассмотрели базовую теорию, познакомились с типовой архитектурой IDP и вариантами реализации. А в этой статье остановимся на обзоре Dev Platform, разрабатываемой командой VK Cloud.
https://habr.com/ru/companies/vk/articles/827022/
#devops #девопс
Подпишись 👉@i_DevOps
❤2👍2
В чем разница между Registry и Repository?
Registry — это сервис хранения и распространения образов, также DockerHub — это Registry по умолчанию. Repository — это набор связанных образов. У них одно и то же имя, но разные метки.
Расскажите об образах Docker, DockerHub, Dockerfile
Образы: файлы, содержащие несколько слоев, используемые для выполнения кода внутри контейнера. Они собираются по инструкциям для получения исполняемой версии приложения. Образы могут ускорить сборку в Docker с помощью кэширования каждого этапа.
DockerHub: сервис для поиска и совместного использования образов контейнеров. Вы можете выгружать туда свои образы, скачивать их оттуда, работать с частными репозиториями образов контейнеров, собирать автоматически образы с помощью GitHub (Bitbucket), а затем закачивать их в DockerHub. Этот сервис предоставляет компания Docker.
Dockerfile: текстовый файл, используемый для сборки образа. Он содержит инструкции и команды по сборке образа. Docker читает их и автоматически собирает образ.
#devops #девопс
Подпишись 👉@i_DevOps
Registry — это сервис хранения и распространения образов, также DockerHub — это Registry по умолчанию. Repository — это набор связанных образов. У них одно и то же имя, но разные метки.
Расскажите об образах Docker, DockerHub, Dockerfile
Образы: файлы, содержащие несколько слоев, используемые для выполнения кода внутри контейнера. Они собираются по инструкциям для получения исполняемой версии приложения. Образы могут ускорить сборку в Docker с помощью кэширования каждого этапа.
DockerHub: сервис для поиска и совместного использования образов контейнеров. Вы можете выгружать туда свои образы, скачивать их оттуда, работать с частными репозиториями образов контейнеров, собирать автоматически образы с помощью GitHub (Bitbucket), а затем закачивать их в DockerHub. Этот сервис предоставляет компания Docker.
Dockerfile: текстовый файл, используемый для сборки образа. Он содержит инструкции и команды по сборке образа. Docker читает их и автоматически собирает образ.
#devops #девопс
Подпишись 👉@i_DevOps
👍4❤3
Вопросы с собеседования
df сообщает о наличии 20 Гб занятого пространства, подсчёт занятого файлами места при помощи du даёт результат в 20 Мб. При каких обстоятельствах может возникнуть описанная ситуация?
Когда файл удален т. к. файловый дескриптор «держит» его.
Ищем файл через:
При удалении файла, который в этот момент был «занят» процессом — его имя удаляется, но inode — остаётся в файловой системе до тех пор, пока не завершится процесс, который «держит» этот файл.
Соответственно, что бы «освободить» уже удалённые файлы — необходимо перезапустить процесс, который этот файл держит.
#devops #девопс
Подпишись 👉@i_DevOps
df сообщает о наличии 20 Гб занятого пространства, подсчёт занятого файлами места при помощи du даёт результат в 20 Мб. При каких обстоятельствах может возникнуть описанная ситуация?
Когда файл удален т. к. файловый дескриптор «держит» его.
Ищем файл через:
lsof -a +L1 | grep var | grep httpdПри удалении файла, который в этот момент был «занят» процессом — его имя удаляется, но inode — остаётся в файловой системе до тех пор, пока не завершится процесс, который «держит» этот файл.
Соответственно, что бы «освободить» уже удалённые файлы — необходимо перезапустить процесс, который этот файл держит.
#devops #девопс
Подпишись 👉@i_DevOps
👍16
Топ-10 распространенных проблем с линтингом Dockerfile
Мы добавили возможность линтинга Docker-файлов по требованию в Depot. В этом посте мы рассмотрим 10 наиболее распространенных проблем с линтингом Dockerfile, которые мы наблюдали в Depot.
https://depot.dev/blog/dockerfile-linting-issues
#devops #девопс
Подпишись 👉@i_DevOps
Мы добавили возможность линтинга Docker-файлов по требованию в Depot. В этом посте мы рассмотрим 10 наиболее распространенных проблем с линтингом Dockerfile, которые мы наблюдали в Depot.
https://depot.dev/blog/dockerfile-linting-issues
#devops #девопс
Подпишись 👉@i_DevOps
Depot
Top 10 common Dockerfile linting issues
We've added the ability to lint Dockerfiles on demand in Depot. This post covers the top 10 most common Dockerfile linting issues we've seen flowing through Depot.
👍3
Обучение у команды Google SRE
Недавно команда Google Site Reliability Engineering опубликовала в своем блоге пост под названием «Уроки, извлеченные за двадцать лет работы над надежностью сайтов». В нем рассказывается об уроках, которые доказали свою ценность с течением времени и в условиях трудностей; они получены в результате инцидентов, затронувших некоторые из основных систем и продуктов Google, таких как Youtube и Google Calendar.
В этом блоге мы хотим рассказать о первых 5 уроках, которыми поделилась команда инженеров по надежности сайтов Google, и рассмотреть примеры их практического применения. Наша цель - показать, как вы можете применить эти уроки для обеспечения надежности и работоспособности ваших систем. Опираясь на реальные сценарии, мы надеемся обеспечить более глубокое понимание этих идей, что позволит вам усовершенствовать свои стратегии по поддержанию работоспособности систем и общей эффективности работы. Кроме того, мы стремимся преодолеть разрыв между теорией и практикой, способствуя более обоснованному подходу к решению проблем в мире SRE.
Часть 1 https://www.codereliant.io/20-sre-lessons-from-google-part1/
Часть 2 https://www.codereliant.io/learning-from-google-sre-team-part-2/
#devops #девопс
Подпишись 👉@i_DevOps
Недавно команда Google Site Reliability Engineering опубликовала в своем блоге пост под названием «Уроки, извлеченные за двадцать лет работы над надежностью сайтов». В нем рассказывается об уроках, которые доказали свою ценность с течением времени и в условиях трудностей; они получены в результате инцидентов, затронувших некоторые из основных систем и продуктов Google, таких как Youtube и Google Calendar.
В этом блоге мы хотим рассказать о первых 5 уроках, которыми поделилась команда инженеров по надежности сайтов Google, и рассмотреть примеры их практического применения. Наша цель - показать, как вы можете применить эти уроки для обеспечения надежности и работоспособности ваших систем. Опираясь на реальные сценарии, мы надеемся обеспечить более глубокое понимание этих идей, что позволит вам усовершенствовать свои стратегии по поддержанию работоспособности систем и общей эффективности работы. Кроме того, мы стремимся преодолеть разрыв между теорией и практикой, способствуя более обоснованному подходу к решению проблем в мире SRE.
Часть 1 https://www.codereliant.io/20-sre-lessons-from-google-part1/
Часть 2 https://www.codereliant.io/learning-from-google-sre-team-part-2/
#devops #девопс
Подпишись 👉@i_DevOps
👍4
Глубокое погружение в сетевые технологии Kubernetes
На вебинаре описывается сетевая модель Kubernetes (узлы, поды, сервисы), ее преобразование в сетевые конструкции Linux, интеграция с физической сетью и оркестровка виртуальных сетевых устройств, таких как маршрутизаторы, балансировщики нагрузки и NAT-шлюзы.
https://my.ipspace.net/bin/list?id=Kubernetes#INTRO
#devops #девопс
Подпишись 👉@i_DevOps
На вебинаре описывается сетевая модель Kubernetes (узлы, поды, сервисы), ее преобразование в сетевые конструкции Linux, интеграция с физической сетью и оркестровка виртуальных сетевых устройств, таких как маршрутизаторы, балансировщики нагрузки и NAT-шлюзы.
https://my.ipspace.net/bin/list?id=Kubernetes#INTRO
#devops #девопс
Подпишись 👉@i_DevOps
👍4