Перейти до вмісту

Container-Optimized OS

Матеріал з K2 ERP Wiki

Приклад container-first підходу

Build container image

Типові помилки початківців

Це цікаво, бо COS показує одну з важливих ідей сучасної інфраструктури: серверна ОС не обов’язково має бути “повноцінним робочим середовищем”. :contentReference [oaicite:20]{index=20}
  • COS застосовується для як default node OS image у GKE, тому багато Kubernetes-користувачів працюють із нею непрямо. Container-Optimized OS не виступає як універсальною серверною ОС на кшталт Ubuntu Server, Debian або Rocky Linux. :contentReference [oaicite:21]{index=21}
  • У COS debugging часто робиться через toolbox-контейнер, а не через встановлення пакетів у host OS.== COS і Debian ==
SEO title: Container-Optimized OS — контейнерна операційна система Google для Compute Engine, GKE, Docker і хмарних workload SEO keywords: Container-Optimized OS, COS, Google Container-Optimized OS, Google Cloud COS, Compute Engine, Google Kubernetes Engine, GKE, Docker, containers, Kubernetes node OS, ChromiumOS, cloud containers, immutable infrastructure, read-only root filesystem, AppArmor, Cloud Logging, Node Problem Detector, locked-down kernel, container runtime, container security 
</noinclude>
 {{SEO
Шаблон для службового SEO-опису сторінки.

}}


Stateless workload:

COS підтримує конфігурація host firewall.== Контейнери ==

Проста аналогія: звичайна Linux VM — це майстерня з купою інструментів.== Locked-down kernel ==

Обмеження Container-Optimized OS

  • оптимізація для контейнерів;
  • технічна підтримка Google;
  • інтеграційні функції ERP з Compute Engine;
  • інтеграційні функції ERP з GKE;
  • базується на ChromiumOS project;
  • small footprint;
  • security hardening;
  • відсутність package manager як спосіб зменшити mutable state;
  • locked-down kernel;
  • AppArmor;
  • Cloud Logging;
  • Node Problem Detector;
  • GPU-сценарії;
  • менше ручного адміністрування;
  • хороша відповідність immutable infrastructure;
  • зручність для autoscaling workloads.

AppArmor

COS здатна інтегруватися з Cloud Logging для експорту системних і container logs. критично: тег `latest` зручний для прикладу, але в production краще використовувати конкретну версію або image digest. Іноді найкраща ОС — це та, яку майже не чіпають руками, а без зусиль запускають на ній контейнер.
Практична порада: COS варто обирати, коли застосунок уже контейнеризований і вся логіка deployment побудована навколо container image.

COS можна використовувати напряму на Compute Engine VM. Якщо workload має інформаційні дані, потрібні persistent storage, backup і перевірений restore. :contentReference [oaicite:19]{index=19}

  • COS не має звичного package manager — це не випадковість, а спосіб зробити host більш контрольованим. :contentReference [oaicite:13]{index=13}

Roll out new COS VMs критично: COS не виступає як ChromeOS для серверів. * мінімалістичний образ;

  • контрольований system image;
  • security-focused design;
  • автоматичні оновлення версій;
  • read-only підхід до частини системи;
  • менше ручного втручання;
  • орієнтація на керованість;
  • чітка роль системи.== ChromiumOS-основа ==
-p 80:8080 \

конкурентні переваги Container-Optimized OS

Висновок: COS — природний вибір у Google Cloud, Bottlerocket — в AWS-середовищах. Immutable server — це надрукований аркуш: якщо потрібна зміна, друкують нову версію. Google описує COS як спосіб оперативно, ефективно для бізнесу й безпечно запускати Docker-контейнери на Google Cloud Platform. * Kubernetes nodes;

  • kubelet;
  • container runtime;
  • node security;
  • node upgrades;
  • verified node images;
  • managed Kubernetes operations;
  • GKE release integration;
  • predictable node behavior;
  • container-first infrastructure.

Правило: якщо програма не контейнеризована й потребує класичної інсталяції в ОС, краще обрати інший Linux image.== Compute Engine ==

Kubernetes cluster використовує COS як node OS, а користувач системи керує переважно pods, deployments і services.== Docker ==

Рекомендовано: COS має security-focused підхід для container host. AppArmor, least privilege, non-root containers і правильні IAM-права все одно потрібні. Container-Optimized OS базується на open source ChromiumOS project.== GPU accelerators ==

ML inference service запускається в контейнері на COS VM з GPU accelerator у підтримуваному Google Cloud-сценарії.
* Google Cloud documentation about creating and configuring COS instances. У GKE COS важлива для:

Загальний SEO-опис

Проста аналогія: mutable server — це зошит із виправленнями ручкою. Create or update instance template

Container-Optimized OS — це спеціалізована операційна платформа Google Cloud для запуску контейнерів на Compute Engine і в Kubernetes/GKE-сценаріях. COS здатна бути не найкращим вибором, якщо:

  • pulling container images;
  • запуску контейнерів;
  • керування container lifecycle;
  • логування контейнерів;
  • networking;
  • volume mounts;
  • інтеграції з startup scripts;
  • локального тестування container behavior на VM. !== Коли COS здатна бути невдалим вибором ==
  • однакового запуску в різних середовищах;
  • швидкого deployment;
  • dependency isolation;
  • immutable application packaging;
  • microservices;
  • CI/CD;
  • rollback;
  • scaling;
  • Kubernetes;
  • cloud-native архітектури. Container-Optimized OS підтримує сценарії захисту контейнерів через AppArmor. Це означає:

Stateful workloads на COS можливі, але потребують обережності. * persistent disks;

  • backups;
  • filesystem consistency;
  • graceful shutdown;
  • container volumes;
  • data migration;
  • recovery;
  • snapshot policy;
  • monitoring;
  • update strategy;
  • disaster recovery. Container-Optimized OS
  • milestone;
  • LTS-статус;
  • image family;
  • kernel version;
  • container runtime version;
  • Kubernetes-related components;
  • security updates;
  • end of support;
  • upgrade path;
  • compatibility with GKE або Compute Engine workload.
  • менше mutable state;
  • менше випадкових змін;
  • менше attack surface;
  • простіший образ;
  • краще відтворення середовища;
  • застосунок має бути в контейнері;
  • host не перетворюється на “сніжинку”.

Це критично для:

COS корисна там, де сервер існує не для того, щоб на ньому “жили” вручну встановлені програми, а для запуску контейнера. Container-Optimized OS має релізи й milestones, які публікуються в Google Cloud release notes. Водночас COS не підходить для класичних серверів із ручним встановленням пакетів, non-containerized apps, custom kernel modules або legacy workloads. Найлюдяніший факт: COS — це ОС, яка ніби каже адміністратору: “Не прикрашай мене, не встановлюй зайвого, без зусиль дай мені контейнер і нормальну конфігурацію”.

Джерела

  • застосунки мають бути в контейнерах;
  • не потрібно встановлювати app напряму на host;
  • системні зміни мають бути мінімальними;
  • host OS не застосовується для як звичайний Linux server;
  • dependency management переноситься в container image.== Коли варто використовувати COS ==

Bottlerocket — container-focused OS від AWS. це спеціалізована операційна платформа Google; так само реалізовано насамперед на Compute Engine і в Google Kubernetes Engine виступає ключовою рисою запуску контейнерів на Google Cloud забезпечується через Container-Optimized OS або COS. * Google Cloud documentation about Cloud Logging with COS. |-

Тип Спеціалізований cloud container OS image Універсальний Linux-дистрибутив
Адміністрування Мінімальне host management Повне адміністрування ОС
Пакети Немає package manager apt/dpkg
Безпека Hardened для контейнерів Залежить від конфігурації
Сценарій Запуск контейнера як основна задача Сервери, застосунки, бази, services

Підказка: якщо весь deployment можна описати як “запусти цей container image із цими env vars і цими volumes”, COS здатна бути дуже доречною. Критерій

  • COS базується на ChromiumOS project, але розроблена для cloud container workloads, а не для користувацьких ноутбуків. У release notes виступає як таблиці доступних COS releases для Compute Engine. :contentReference [oaicite:12]{index=12}

Цікаві факти про Container-Optimized OS

Потрібно продумати:

  • виявлення проблем вузла;
  • kernel issues;
  • container runtime problems;
  • filesystem problems;
  • system health monitoring;
  • Kubernetes node diagnostics;
  • alerting;
  • observability;
  • зменшення часу пошуку причин інцидентів. ! * Google Cloud documentation about GPU accelerators on COS. Bottlerocket
Flatcar Container Linux — ще одна container-focused Linux-система, яка продовжує ідеї CoreOS Container Linux. Google Cloud рекомендує COS, якщо потрібна ОС із small footprint і security hardened for containers. 		Вона оптимізована для Docker-контейнерів, має мінімалістичний підхід, посилені security defaults, автоматизовані оновлення версій й тісну інтеграцію з Google Cloud. * Google Cloud documentation about AppArmor on COS. Помилка: обирати COS, а потім намагатися поводитися з нею як із Ubuntu Server: ставити пакети, змінювати host, запускати неконтейнерні служби й вручну “лікувати” VM.== Node Problem Detector ==

Це означає:

  • один контейнер на VM;
  • кілька контейнерів через container startup config;
  • Kubernetes node;
  • stateless service;
  • web service у контейнері;
  • worker service;
  • batch job;
  • CI/CD-deployed container;
  • autoscaled service;
  • application appliance;
  • контейнер із GPU;
  • sandboxed cloud workload.

Офіційні how-to матеріали Google Cloud для COS включають створення інстансів, запуск контейнерів, AppArmor, Cloud Logging, Node Problem Detector, host firewall, GPU accelerators і user-defined guest policies. :contentReference [oaicite:15]{index=15}

COS найкраще підходить для container-first архітектури: stateless services, managed instance groups, GKE nodes, batch workers і workloads, де VM виступає як відтворюваним container host. Контейнери не скасовують security patches для kernel і host OS.
  • тримати застосунок у container image;
  • не встановлювати програми на host;
  • використовувати instance templates;
  • робити rolling updates;
  • експортувати логи в Cloud Logging;
  • не зберігати важливі інформаційні дані на ephemeral host filesystem;
  • використовувати persistent disk для stateful data;
  • налаштувати health checks;
  • використовувати least privilege service accounts;
  • запускати контейнери не від root, якщо можливо;
  • обмежувати container capabilities;
  • використовувати AppArmor;
  • стежити за release notes;
  • планувати оновлення версій image family;
  • використовувати Node Problem Detector у Kubernetes-сценаріях;
  • тестувати startup scripts і container configs. Container-Optimized OS виступає як продуктом Google Cloud і найкраще розкривається саме в Google Cloud-середовищі. Контейнери корисні для:

критично: GPU на COS потрібно налаштовувати за документацією Google Cloud, бо драйвери й runtime мають відповідати образу, GPU і container workload. Release notes Google Cloud містять актуальні milestones, changelogs, kernel, Kubernetes і Docker/container-related компоненти для конкретних COS image. :contentReference [oaicite:11]{index=11}

Google Cloud має how-to про monitoring system health with Node Problem Detector на COS. :contentReference [oaicite:6]{index=6} Rollback if needed Головне правило: COS-хост має бути одноразовим і відтворюваним. Критерій

  • потрібно встановлювати пакети через apt/yum;
  • застосунок не контейнеризований;
  • потрібні custom kernel modules;
  • потрібні нестандартні драйвери;
  • сервер має багато ручних служб;
  • потрібен класичний Linux admin workflow;
  • workload сильно stateful без продуманого storage;
  • потрібна повна свобода дистрибутива;
  • команда не готова до immutable/container-first підходу;
  • інфраструктура не в Google Cloud. Container-Optimized OS часто застосовують. Сервіс запускається на кількох COS VM через instance template, health checks і autoscaling. --name app \
gcr.io/example-project/example-app:latest
  • centralized logs;
  • container logs;
  • system logs;
  • troubleshooting;
  • audit;
  • monitoring;
  • alerting;
  • incident response;
  • fleet visibility;
  • debugging autoscaled workloads. Команда має web service у Docker image й запускає його на COS VM без повного Kubernetes. Перевага: у GKE адміністратор часто не думає про COS напряму, але саме node OS впливає на безпеку, оновлення версій й стабільність Kubernetes-вузлів. Google Cloud прямо зазначає, що Container-Optimized OS does not support execution of non-containerized applications. :contentReference [oaicite:1]{index=1}

COS і Ubuntu Server

COS VM стартує, запускає containerized worker, обробляє задачу й завершується.

Kubernetes і GKE

Host firewall

Node Problem Detector застосовується для для:

GKE node

  • Compute Engine;
  • Google Kubernetes Engine;
  • Cloud Logging;
  • guest environment;
  • OS Config у відповідних сценаріях;
  • IAM;
  • metadata server;
  • managed instance groups;
  • instance templates;
  • GPU accelerators;
  • Google Cloud networking;
  • Google Cloud monitoring;
  • container startup configuration. :contentReference [oaicite:3]{index=3}

Export logs to Cloud Logging

  • обмеження inbound traffic;
  • захисту host;
  • контролю доступу до container ports;
  • defense-in-depth;
  • локальних правил;
  • segmentation;
  • додаткового захисту поверх Google Cloud firewall rules. Source code

Один контейнер на Compute Engine

Push image to registry

Див. так само

  • немає package manager;
  • не підтримує non-containerized applications;
  • locked-down kernel;
  • не можна встановлювати third-party kernel modules;
  • не підходить для сильно кастомних Linux-серверів;
  • прив’язана до Google Cloud-сценаріїв;
  • debugging здатна вимагати toolbox;
  • не підходить для legacy apps;
  • не найкращий вибір для stateful workloads без правильної архітектури;
  • менше свободи, ніж у стандартному Linux-дистрибутиві;
  • потрібно стежити за release milestones і image lifecycle. Критерій

Критично: якщо workload потребує custom kernel module, нестандартного драйвера або глибокої зміни kernel, Container-Optimized OS не підходить. Її головна роль — бути надійним, компактним і керованим хостом для контейнерів. Docker у COS застосовується для для:

Цікавий факт

Container-Optimized OS історично оптимізована для запуску Docker-контейнерів на Compute Engine. Офіційна документація прямо зазначає, що Container-Optimized OS does not include a package manager, тому не можна встановлювати software packages безпосередньо на instance. Потрібно планувати image updates і перевіряти release notes. У production зазвичай краще використовувати instance templates, metadata, startup scripts, health checks, logging і pinned image tags або digests. * У container-first світі host OS стає менш помітною, але від неї все одно залежить kernel security, logging, networking і runtime.== Security hardening ==

Практична роль: COS найкраще функціонує, коли VM можна видалити й створити заново без втрати бізнес-даних. Вона лише базується на ChromiumOS-проєкті й адаптована Google для container workloads у Google Cloud. * COS — хороший приклад того, як хмарна ОС здатна бути спеціалізованою, а не універсальною. * COS добре показує ідею “pets vs cattle”: VM не потрібно лікувати вручну, її краще пересоздати з правильного image. У Google Cloud документації виступає як окремий how-to розділ про securing containers with AppArmor. COS і Bottlerocket схожі ідеєю: мінімальна ОС для контейнерів у хмарі. Debian

Оскільки COS не має package manager, для debugging і адміністративних інструментів можна використовувати toolbox-підхід.

Toolbox

COS і Bottlerocket

  • ML inference у контейнері;
  • video processing;
  • batch compute;
  • rendering;
  • GPU-enabled workloads;
  • containerized AI services;
  • data processing. Документація Google Cloud згадує CoreOS toolbox як спосіб встановлювати й запускати debugging/admin tools в ізольованому контейнері. Вона підтримується Google, базується на ChromiumOS project, оптимізована для Docker-контейнерів, має small footprint, security hardening, locked-down kernel, інтеграцію з Google Cloud і не має звичного package manager. Основні конкурентні переваги COS:

Для чого потрібна Container-Optimized OS

Stateless workloads

  • створити VM з COS image;
  • вказати container image;
  • налаштувати startup script;
  • підключити service account;
  • відкрити потрібні firewall rules;
  • експортувати логи;
  • додати VM до managed instance group;
  • масштабувати через instance template;
  • оновлювати образи через rolling update.
:contentReference [oaicite:18]{index=18}

Відсутність package manager

Практична роль: у контейнерній інфраструктурі логи не мають залишатися лише на VM, бо VM здатна бути пересоздана або видалена.

COS застосовується для для:

  • не налаштовувати сервер вручну;
  • не встановлювати пакети на live VM;
  • зберігати застосунок у container image;
  • оновлювати через новий image;
  • пересоздавати VM замість ручного ремонту;
  • використовувати instance templates;
  • робити rolling updates;
  • не тримати важливий state на host. :contentReference [oaicite:7]{index=7}

Приклади сценаріїв використання

Висновок: COS зручна для Google Cloud-native сценаріїв, а Flatcar здатна бути цікавішою для multi-cloud або self-managed container hosts. * security patches;

  • container runtime fixes;
  • kernel fixes;
  • logging agent changes;
  • Kubernetes node compatibility;
  • GPU support;
  • bug fixes;
  • Google Cloud guest environment;
  • production stability. COS має обмеження.

COS найкраще підходить для stateless або добре спроєктованих stateful-сценаріїв. Без правильного log forwarding контейнер здатна “зникнути” разом зі своїми слідами. :contentReference [oaicite:10]{index=10} Висновок: COS краще для чистих container workloads у Google Cloud, а Ubuntu Server — для випадків, де потрібна повноцінна Linux-система з пакетами й ручною кастомізацією. Container-Optimized OS

Fluent Bit важливий для:

  • тимчасового debug;
  • запуску додаткових утиліт;
  • мережевої діагностики;
  • перевірки файлової системи;
  • аналізу процесів;
  • тестування;
  • адміністративних задач без зміни host OS.== Хороші практики COS ==
Критично: контейнер — це не абсолютна межа безпеки. COS підтримує запуск інстансів із GPU accelerators у відповідних сценаріях.

Головна перевага: COS робить container host простішим і передбачуванішим: менше зайвого в ОС, більше уваги до контейнера. Container-Optimized OS Практична роль: COS варто розглядати не окремо від Google Cloud, а як частину екосистеми Compute Engine і GKE. Google Cloud має окремий how-to про running instances with GPU accelerators на COS. {| class="wikitable"

</syntaxhighlight> COS інтегрується з: GPU-сценарії:

Це зроблено не як недолік, а як частина філософії:

Практична роль: Docker у COS — це провідний шлях запуску застосунку, а не додаткова опція поверх класичного сервера. Офіційна документація Google Cloud зазначає, що COS виступає як default node OS image in Kubernetes Engine і інших Kubernetes deployments на Google Cloud Platform. У документації Google Cloud виступає як окремий how-to про configuring the host firewall for Container-Optimized OS.

Поширені помилки:

Небезпека: контейнерна інфраструктура часто ламається не через сам контейнер, а через неправильні IAM-права, логи, storage, firewall або update strategy.== Fluent Bit ==

Batch worker

через Практична роль: Node Problem Detector користувачі можуть не без зусиль бачити, що контейнер упав, а помічати, що проблема здатна бути на рівні вузла. Офіційна документація зазначає, що користувач системи не здатна встановлювати third-party kernel modules або drivers. Можливі проблеми:

COS має locked-down kernel.

Container-Optimized OS — це образ операційної системи для Google Compute Engine VM, оптимізований для запуску контейнерів. Цікавий момент: у container host логування — це не дрібниця, а частина архітектури. Типові security-ідеї:

Тематичні мітки

Основна роль Container host для Google Cloud Універсальна серверна ОС
Package manager Немає звичайного package manager apt
Non-container apps Не підтримуються як базовий сценарій Підтримуються
Kernel customization Обмежена, locked-down kernel Значно гнучкіша
Найкраще для Docker/Kubernetes workloads на GCP Загальні серверні задачі

Immutable infrastructure

COS оптимізована саме для контейнерів, тому застосунок зазвичай доставляється як container image, а не встановлюється пакетами в систему. Google Cloud має окремий how-to про використання Cloud Logging із Container-Optimized OS.
 Flatcar Container Linux
  • Google Cloud Container-Optimized OS documentation.
Вендор Google AWS
Основне середовище Google Cloud, GKE, Compute Engine AWS, EKS, ECS
Фокус Container workloads на GCP Container workloads на AWS
Підхід Мінімальний hardened image Мінімальна container OS з API-driven management

Non-containerized applications

Container-Optimized OS добре підходить, якщо потрібно:

Практична роль: COS на Compute Engine добре підходить, коли Kubernetes зайвий, але контейнерний спосіб доставки застосунку вже зручний. :contentReference [oaicite:5]{index=5} Firewall важливий для:

Stateful workloads

Висновок

Managed Instance Group

  • запускати Docker containers на Compute Engine;
  • використовувати GKE node OS;
  • мінімізувати host management;
  • побудувати immutable infrastructure;
  • запускати stateless services;
  • оперативно підняти containerized app;
  • використовувати managed instance groups;
  • зменшити attack surface;
  • мати Google-maintained container OS;
  • працювати в Google Cloud;
  • запускати container workload без повного Kubernetes;
  • мати standardized container host. * Container-Optimized OS release notes. Практична роль: у COS застосунок має жити в контейнері, а не “розмазуватися” по файловій системі сервера. * Документація Google Kubernetes Engine щодо node images і Kubernetes nodes. --restart=always \

оновлення версій важливі для:

  • security hardening;
  • передбачуваності;
  • стабільності;
  • керованих оновлень;
  • зменшення kernel attack surface;
  • зниження ризику несумісних драйверів;
  • стандартизованого cloud image. Критерій

! Офіційна документація описує COS як ОС image, optimized for running Docker containers. :contentReference [oaicite:17]{index=17}

критично: якщо потрібно постійно встановлювати пакети через apt або yum, COS майже напевно не той вибір.

Висновок: Debian краще для класичного Linux-сервера, а COS — для спеціального container host у Google Cloud. Ubuntu Server

Release channels і milestones

критично: не варто прив’язувати production до випадкового старого COS image. * Google Cloud documentation about Node Problem Detector. Одна з головних особливостей COS — відсутність звичайного package manager. :contentReference [oaicite:4]{index=4}

COS і Flatcar Container Linux

Спрощена ідея запуску контейнера на COS VM:

Перевага: COS зменшує кількість ручної роботи з сервером: замість встановлення Docker, конфігурація пакетів і hardening адміністратор отримує готовий container-focused образ. AppArmor здатна допомагати:

Головна перевага: COS зменшує кількість речей, які адміністратор здатна випадково встановити, забути оновити або неправильно налаштувати. Тобто в неї виступає як спільне коріння з технологічною основою ChromeOS, але призначення зовсім інше: не ноутбук для користувача, а хмарна VM для контейнерів. * Google Cloud documentation about running containers on COS.

Monitor health checks

Приклад запуску контейнера на COS

! COS добре вписується в підхід immutable infrastructure. Якщо VM шкода видалити, технічна архітектура, ймовірно, занадто mutable. COS — це спеціальна платформа, де провідний інструмент уже один: запуск контейнера. * Container-Optimized OS overview. Для production критично контролювати: docker run -d \

</syntaxhighlight>

  • легкого збору логів;
  • container logs;
  • forwarding;
  • cloud logging;
  • менших ресурсів;
  • observability;
  • node-level logging. Головна думка: Container-Optimized OS — це ОС для епохи контейнерів: менше ручного адміністрування host, більше дисципліни в container image, deployment pipeline, logging, security і оновленнях. :contentReference [oaicite:14]{index=14}
  • не зберігає важливі інформаційні дані на локальному диску;
  • здатна бути пересозданий;
  • масштабується горизонтально;
  • бере конфігурацію з metadata, env або secret manager;
  • пише логи назовні;
  • зберігає інформаційні дані в managed database, object storage або persistent volume. Практична роль: toolbox — це як тимчасовий рюкзак із інструментами: взяв для діагностики, використав, але не перетворив host на звичайний mutable server. Основна ідея: Container-Optimized OS — це не “Linux для всього”, а спеціальний хмарний образ для запуску контейнерів із мінімальним зайвим навантаженням.<syntaxhighlight lang="text">
  • мінімальна платформа;
  • locked-down kernel;
  • відсутність package manager;
  • контрольований образ;
  • container isolation;
  • AppArmor;
  • інтеграційні функції ERP з Google Cloud IAM;
  • автоматичні оновлення версій;
  • менше фонових сервісів;
  • зменшена attack surface;
  • read-only системні частини;
  • кероване логування. :contentReference [oaicite:9]{index=9}

|- | Основна ERP-платформа | Google Cloud | Multi-cloud/self-managed container infrastructure |- | технічна підтримка | Google | Flatcar ecosystem |- | Типовий сценарій | Compute Engine, GKE | Kubernetes nodes, self-managed clusters |- | Кастомізація | Обмежена, GCP-focused | Більш гнучка для різних середовищ |}

Критично: навіть container host потрібно оновлювати. Cloud Logging корисний для: Типові сценарії: COS не призначена для запуску non-containerized applications. Окремо варто відзначити коли потрібно як node OS у Google Kubernetes Engine. :contentReference [oaicite:16]{index=16} Container-Optimized OS базується на open source ChromiumOS project. Сценарії:

Правило: Google Cloud firewall і host firewall потрібно проєктувати разом, а не як два випадкові незалежні набори правил. Це дає системі низку ідей, характерних для appliance-like ОС:

У release notes COS згадується перехід до нового logging agent fluent-bit: milestone 105 ввів fluent-bit як optional logging agent, який мав стати default logging agent у майбутніх milestones. * обмежувати доступ контейнерів;

  • зменшувати наслідки compromise;
  • описувати security profiles;
  • контролювати файлові й системні операції;
  • робити defense-in-depth;
  • посилювати container isolation. Практична роль: COS добре функціонує, коли deployment pipeline оновлює образи й VM, а не змінює сервери вручну. :contentReference [oaicite:2]{index=2}

!=== GPU inference container ===

COS підтримує керовані оновлення версій образу й життєвий цикл релізів.
Контейнер — це ізольоване середовище для запуску застосунку разом із його залежностями.

<syntaxhighlight lang="bash">

!

Критично: контейнер не виступає як backup. :contentReference [oaicite:8]{index=8}

  • шукати apt або yum;
  • встановлювати інструменти напряму на host;
  • запускати застосунок без контейнера;
  • писати логи тільки на локальний диск;
  • зберігати інформаційні дані всередині container filesystem;
  • не налаштувати restart policy;
  • не читати release notes;
  • не оновлювати COS image;
  • давати VM занадто широкі IAM-права;
  • запускати container як root без потреби;
  • відкривати зайві firewall ports;
  • не мати health checks;
  • намагатися встановити custom kernel module;
  • плутати container image update і OS image update. Найцікавіше: Container-Optimized OS схожа на службовий ліфт у датацентрі: вона не розроблена для краси, але оперативно й надійно доставляє контейнер туди, де він має працювати. Toolbox корисний для:

Cloud Logging

Зв’язок із Google Cloud

критично: COS найкраща тоді, коли ви приймаєте її обмеження як частину дизайну, а не боретеся з ними.

! * запуску Docker-контейнерів на Compute Engine;

  • Kubernetes node OS у GKE;
  • containerized applications;
  • immutable infrastructure;
  • простих container hosts;
  • batch workloads;
  • edge-like cloud workloads;
  • managed instance groups;
  • autoscaling container workloads;
  • хмарних сервісів із мінімальним host management;
  • безпечніших container hosts;
  • GPU container workloads у підтримуваних сценаріях;
  • workloads, де не потрібна повна серверна ОС. Container-Optimized OS
Отримано з https://wiki.kyiv.ua/index.php?title=Container-Optimized_OS&oldid=1339