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

Container-Optimized OS

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

Контейнер — це ізольоване середовище для запуску застосунку разом із його залежностями.; Типові security-ідеї:

Це цікаво, бо COS показує одну з важливих ідей сучасної інфраструктури: серверна ОС не обов’язково має бути “повноцінним робочим середовищем”.; * виявлення проблем вузла;

  • kernel issues;
  • container runtime problems;
  • filesystem problems;
  • system health monitoring;
  • Kubernetes node diagnostics;
  • alerting;
  • observability;
  • зменшення часу пошуку причин інцидентів.; * Google Cloud documentation about creating and configuring COS instances.; Container-Optimized OS

актуалізація важливі для:

  • COS базується на ChromiumOS project, але розроблена для cloud container workloads, а не для користувацьких ноутбуків.; docker run -d \

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

!; Сценарії: Команда має web service у Docker image й запускає його на COS VM без повного Kubernetes.; Container-Optimized OS

Fluent Bit

Джерела

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

Коли COS має змогу бути невдалим вибором

Container-Optimized OS не є собою універсальною серверною ОС на кшталт Ubuntu Server, Debian або Rocky Linux.; Container-Optimized OS підтримує роботу сценарії захисту контейнерів через AppArmor.; * ML inference у контейнері;

  • video processing;
  • batch compute;
  • rendering;
  • GPU-enabled workloads;
  • containerized AI services;
  • data processing.; !; Push image to registry

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

Головна перевага: COS зменшує кількість речей, які адміністратор має змогу випадково встановити, забути оновити або неправильно налаштувати.; * Google Cloud documentation about running containers on COS.; Якщо workload має інформаційні дані, потрібні persistent storage, backup і перевірений restore.; Без правильного log forwarding контейнер має змогу “зникнути” разом зі своїми слідами.; Потрібно планувати image updates і перевіряти release notes.; * тимчасового debug;

  • запуску додаткових утиліт;
  • мережевої діагностики;
  • перевірки файлової системи;
  • аналізу процесів;
  • тестування;
  • адміністративних задач без зміни host OS.; Create or update instance template

!; Практична порада: COS варто обирати, коли застосунок уже контейнеризований і вся логіка deployment побудована навколо container image.; У документації Google Cloud є собою окремий how-to про configuring the host firewall for Container-Optimized OS.;

COS підтримує роботу керовані актуалізація образу й життєвий цикл релізів.; Основні переважні аспекти COS: істотно: тег `latest` зручний для прикладу, але в production краще використовувати конкретну версію або image digest.; :contentReference [oaicite:11]{index=11} Практична роль: COS варто розглядати не окремо від Google Cloud, а як частину екосистеми Compute Engine і GKE.;== Цікаві факти про Container-Optimized OS ==

Цікавий факт

Google Cloud має how-to про monitoring system health with Node Problem Detector на COS.; :contentReference [oaicite:20]{index=20}

  • COS застосовується як default node OS image у GKE, з цієї причини багато Kubernetes-користувачів працюють із нею непрямо.; Ubuntu Server

GPU accelerators

Locked-down kernel

Container-Optimized OS має релізи й milestones, які публікуються в Google Cloud release notes.; Головна перевага: COS робить container host простішим і передбачуванішим: менше зайвого в ОС, більше уваги до контейнера.; :contentReference [oaicite:1]{index=1}

Container-Optimized OS часто застосовують.; * Документація Google Kubernetes Engine щодо node images і Kubernetes nodes.;

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

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

  • security patches;
  • container runtime fixes;
  • kernel fixes;
  • logging agent changes;
  • Kubernetes node compatibility;
  • GPU support;
  • bug fixes;
  • Google Cloud guest environment;
  • production stability.; :contentReference [oaicite:14]{index=14}

Одна з головних особливостей COS — відсутність звичайного package manager.; Окремо варто відзначити коли потрібно як node OS у Google Kubernetes Engine.; Це означає:

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

COS і Debian

AppArmor має змогу допомагати:

Правило: Google Cloud firewall і host firewall потрібно проєктувати разом, а не як два випадкові незалежні набори правил.;

переважні аспекти Container-Optimized OS

Висновок: COS краще для чистих container workloads у Google Cloud, а Ubuntu Server — для випадків, де потрібна повноцінна Linux-система з пакетами й ручною кастомізацією.; Практична роль: Node Problem Detector сприяє не без ускладнень бачити, що контейнер упав, а помічати, що проблема має змогу бути на рівні вузла.; :contentReference [oaicite:12]{index=12} 

gcr.io/example-project/example-app:latest

Immutable infrastructure

  • 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:8]{index=8}

Коли варто використовувати COS

У production зазвичай краще використовувати instance templates, metadata, startup scripts, health checks, logging і pinned image tags або digests.; істотно: COS не є собою ChromeOS для серверів.; Її головна роль — бути надійним, компактним і керованим хостом для контейнерів.; :contentReference [oaicite:6]{index=6}

COS має обмеження.; * У container-first світі host OS стає менш помітною, але від неї все одно залежить kernel security, logging, networking і runtime.; Release notes Google Cloud містять актуальні milestones, changelogs, kernel, Kubernetes і Docker/container-related компоненти для конкретних COS image.; :contentReference [oaicite:2]{index=2}

Практична роль: у COS застосунок має жити в контейнері, а не “розмазуватися” по файловій системі сервера.;

Хороші практики COS

Compute Engine

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

  • Kubernetes nodes;
  • kubelet;
  • container runtime;
  • node security;
  • node upgrades;
  • verified node images;
  • managed Kubernetes operations;
  • GKE release integration;
  • predictable node behavior;
  • container-first infrastructure.; COS інтегрується з:

Stateless workloads

Перевага: COS зменшує кількість ручної роботи з сервером: замість встановлення Docker, конфігурація пакетів і hardening адміністратор отримує готовий container-focused образ.; !; :contentReference [oaicite:18]{index=18}

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

; :contentReference [oaicite:17]{index=17}

Managed Instance Group

Bottlerocket — container-focused OS від AWS.; Практична роль: Docker у COS — це центральний шлях запуску застосунку, а не додаткова опція поверх класичного сервера.; У release notes COS згадується перехід до нового logging agent fluent-bit: milestone 105 ввів fluent-bit як optional logging agent, який мав стати default logging agent у майбутніх milestones.;

Automatic updates

Build container image

; Вона оптимізована для Docker-контейнерів, має мінімалістичний підхід, посилені security defaults, автоматизовані актуалізація й тісну інтеграцію з Google Cloud.; Якщо VM шкода видалити, технічна архітектура, ймовірно, занадто mutable.;

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

  • застосунок не контейнеризований;
  • потрібні custom kernel modules;
  • потрібні нестандартні драйвери;
  • сервер має багато ручних служб;
  • потрібен класичний Linux admin workflow;
  • workload сильно stateful без продуманого storage;
  • потрібна повна свобода дистрибутива;
  • команда не готова до immutable/container-first підходу;
  • інфраструктура не в Google Cloud.; Container-Optimized OS

ChromiumOS-основа

  • pulling container images;
  • запуску контейнерів;
  • керування container lifecycle;
  • логування контейнерів;
  • networking;
  • volume mounts;
  • інтеграції з startup scripts;
  • локального тестування container behavior на VM.; Вона підтримується Google, базується на ChromiumOS project, оптимізована для Docker-контейнерів, має small footprint, security hardening, locked-down kernel, інтеграцію з Google Cloud і не має звичного package manager.; COS підтримує роботу конфігурація host firewall.;
Container-Optimized OS базується на open source ChromiumOS project.;

COS і Flatcar Container Linux

Сервіс запускається на кількох COS VM через instance template, health checks і autoscaling.; * Google Cloud documentation about Node Problem Detector.;== Toolbox == Практична роль: COS на Compute Engine добре підходить, коли Kubernetes зайвий, але контейнерний спосіб доставки застосунку вже зручний.; Debian

Висновок: Debian краще для класичного Linux-сервера, а COS — для спеціального container host у Google Cloud.; :contentReference [oaicite:15]{index=15} COS найкраще підходить для container-first архітектури: stateless services, managed instance groups, GKE nodes, batch workers і workloads, де VM є собою відтворюваним container host.; COS застосовується для:

Загальний характеристика

Вендор Google AWS
Основне середовище Google Cloud, GKE, Compute Engine AWS, EKS, ECS
Фокус Container workloads на GCP Container workloads на AWS
Підхід Мінімальний hardened image Мінімальна container OS з API-driven management

Export logs to Cloud Logging

Правило: якщо програма не контейнеризована й потребує класичної інсталяції в ОС, краще обрати інший Linux image.; це спеціалізована операційна платформа Google; додатково реалізовано насамперед на Compute Engine і в Google Kubernetes Engine виступає ключовою рисою запуску контейнерів на Google Cloud забезпечується через Container-Optimized OS або COS.; Можливі проблеми:

Критично: якщо workload потребує custom kernel module, нестандартного драйвера або глибокої зміни kernel, Container-Optimized OS не підходить.; Рекомендовано: COS добре вписується в підхід immutable infrastructure.; :contentReference [oaicite:7]{index=7}

Container-Optimized OS є собою продуктом Google Cloud і найкраще розкривається саме в Google Cloud-середовищі.; Висновок: COS — природний вибір у Google Cloud, Bottlerocket — в AWS-середовищах.; :contentReference [oaicite:19]{index=19}

  • COS не має звичного package manager — це не випадковість, а спосіб зробити host більш контрольованим.; У Google Cloud документації є собою окремий how-to розділ про securing containers with AppArmor.; * Container-Optimized OS overview.;== Host firewall ==

У GKE COS важлива для:

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

  • один контейнер на 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.; :contentReference [oaicite:3]{index=3}

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

Для production істотно контролювати:
  • застосунки мають бути в контейнерах;
  • не потрібно встановлювати app напряму на host;
  • системні зміни мають бути мінімальними;
  • host OS не застосовується як звичайний Linux server;
  • dependency management переноситься в container image.; У release notes є собою таблиці доступних COS releases для Compute Engine.; Google Cloud прямо зазначає, що Container-Optimized OS does not support execution of non-containerized applications.; :contentReference [oaicite:21]{index=21}
  • У COS debugging часто робиться через toolbox-контейнер, а не через встановлення пакетів у host OS.; Monitor health checks
;
</div>

Основна ідея: Container-Optimized OS — це не “Linux для всього”, а спеціальний хмарний образ для запуску контейнерів із мінімальним зайвим навантаженням.;=== GKE node ===

COS має змогу інтегруватися з Cloud Logging для експорту системних і container logs.; Bottlerocket

Контейнери корисні для:

Release channels і milestones

  • створити VM з COS image;
  • вказати container image;
  • налаштувати startup script;
  • підключити service account;
  • відкрити потрібні firewall rules;
  • експортувати логи;
  • додати VM до managed instance group;
  • масштабувати через instance template;
  • оновлювати образи через rolling update.;
Проста аналогія: звичайна Linux VM — це майстерня з купою інструментів.; Immutable server — це надрукований аркуш: якщо потрібна зміна, друкують нову версію.; * Google Cloud documentation about GPU accelerators on COS.;

Типові сценарії:

COS і Bottlerocket

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

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

істотно: GPU на COS потрібно налаштовувати за документацією Google Cloud, бо драйвери й runtime мають відповідати образу, GPU і container workload.;== Типові помилки початківців ==

COS має locked-down kernel.; --name app \

Див.; додатково

  • мінімальна платформа;
  • locked-down kernel;
  • відсутність package manager;
  • контрольований образ;
  • container isolation;
  • AppArmor;
  • інтеграційні функціональні можливості з Google Cloud IAM;
  • автоматичні актуалізація;
  • менше фонових сервісів;
  • зменшена attack surface;
  • read-only системні частини;
  • кероване логування.; * однакового запуску в різних середовищах;
  • швидкого deployment;
  • dependency isolation;
  • immutable application packaging;
  • microservices;
  • CI/CD;
  • rollback;
  • scaling;
  • Kubernetes;
  • cloud-native архітектури.; Google Cloud має окремий how-to про використання Cloud Logging із Container-Optimized OS.; Критерій
Тип Спеціалізований cloud container OS image Універсальний Linux-дистрибутив
Адміністрування Мінімальне host management Повне адміністрування ОС
Пакети Немає package manager apt/dpkg
Безпека Hardened для контейнерів Залежить від конфігурації
Сценарій Запуск контейнера як основна задача Сервери, застосунки, бази, services

Небезпека: контейнерна інфраструктура часто ламається не через сам контейнер, а через неправильні IAM-права, логи, storage, firewall або update strategy.; :contentReference [oaicite:9]{index=9}

</syntaxhighlight>

ML inference service запускається в контейнері на COS VM з GPU accelerator у підтримуваному Google Cloud-сценарії.; 
-p 80:8080 \
Container-Optimized OS історично оптимізована для запуску Docker-контейнерів на Compute Engine.;

Критично: контейнер не є собою backup.;=== Batch worker ===

Rollback if needed

  • немає 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.; Офіційна документація Google Cloud зазначає, що COS є собою default node OS image in Kubernetes Engine і інших Kubernetes deployments на Google Cloud Platform.; COS — це спеціальна платформа, де центральний інструмент уже один: запуск контейнера.; Критично: навіть container host потрібно оновлювати.; Практична роль: COS добре функціонує, коли deployment pipeline оновлює образи й VM, а не змінює сервери вручну.; Перевага: у GKE адміністратор часто не думає про COS напряму, але саме node OS впливає на безпеку, актуалізація й стабільність Kubernetes-вузлів.; * Google Cloud documentation about AppArmor on COS.;== Cloud Logging ==

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

COS найкраще підходить для stateless або добре спроєктованих stateful-сценаріїв.;
  • менше mutable state;
  • менше випадкових змін;
  • менше attack surface;
  • простіший образ;
  • краще відтворення середовища;
  • застосунок має бути в контейнері;
  • host не перетворюється на “сніжинку”.;

Підказка: якщо весь deployment можна описати як “запусти цей container image із цими env vars і цими volumes”, COS має змогу бути дуже доречною.; :contentReference [oaicite:5]{index=5}

Roll out new COS VMs

Зв’язок із Google Cloud

 ;== Node Problem Detector ==

Container-Optimized OS добре підходить, якщо потрібно: Головне правило: COS-хост має бути одноразовим і відтворюваним.; * centralized logs;

  • container logs;
  • system logs;
  • troubleshooting;
  • audit;
  • monitoring;
  • alerting;
  • incident response;
  • fleet visibility;
  • debugging autoscaled workloads.; Помилка: обирати COS, а потім намагатися поводитися з нею як із Ubuntu Server: ставити пакети, змінювати host, запускати неконтейнерні служби й вручну “лікувати” VM.; !; Вона лише базується на ChromiumOS-проєкті й адаптована Google для container workloads у Google Cloud.; Документація Google Cloud згадує CoreOS toolbox як спосіб встановлювати й запускати debugging/admin tools в ізольованому контейнері.;

Проста аналогія: mutable server — це зошит із виправленнями ручкою.; Потрібно продумати: COS не призначена для запуску non-containerized applications.;=== Один контейнер на Compute Engine ===

Container-Optimized OS — це спеціалізована операційна платформа Google Cloud для запуску контейнерів на Compute Engine і в Kubernetes/GKE-сценаріях.; Flatcar Container Linux

  • не налаштовувати сервер вручну;
  • не встановлювати пакети на live VM;
  • зберігати застосунок у container image;
  • оновлювати через новий image;
  • пересоздавати VM замість ручного ремонту;
  • використовувати instance templates;
  • робити rolling updates;
  • не тримати важливий state на host.; * легкого збору логів;
  • container logs;
  • forwarding;
  • cloud logging;
  • менших ресурсів;
  • observability;
  • node-level logging.;== Контейнери ==

Firewall важливий для:

  • persistent disks;
  • backups;
  • filesystem consistency;
  • graceful shutdown;
  • container volumes;
  • data migration;
  • recovery;
  • snapshot policy;
  • monitoring;
  • update strategy;
  • disaster recovery.; * Google Cloud documentation about Cloud Logging with COS.; --restart=always \

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

  • передбачуваності;
  • стабільності;
  • керованих оновлень;
  • зменшення kernel attack surface;
  • зниження ризику несумісних драйверів;
  • стандартизованого cloud image.; * Container-Optimized OS release notes.; Найлюдяніший факт: COS — це ОС, яка ніби каже адміністратору: “Не прикрашай мене, не встановлюй зайвого, без ускладнень дай мені контейнер і нормальну конфігурацію”.; GPU-сценарії:
 ; Практична роль: COS найкраще функціонує, коли VM можна видалити й створити заново без втрати бізнес-даних.; Головна думка: Container-Optimized OS — це ОС для епохи контейнерів: менше ручного адміністрування host, більше дисципліни в container image, deployment pipeline, logging, security і оновленнях.;

Google Cloud рекомендує COS, якщо потрібна ОС із small footprint і security hardened for containers.; :contentReference [oaicite:13]{index=13}

Cloud Logging корисний для:

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

<syntaxhighlight lang="text">

Source code

  • обмежувати доступ контейнерів;
  • зменшувати наслідки compromise;
  • описувати security profiles;
  • контролювати файлові й системні операції;
  • робити defense-in-depth;
  • посилювати container isolation.;
 ;
істотно: не варто прив’язувати production до випадкового старого COS image.;

Stateful workloads на COS можливі, але потребують обережності.;== Обмеження Container-Optimized OS == Це означає: істотно: якщо потрібно постійно встановлювати пакети через apt або yum, COS майже напевно не той вибір.; * COS добре показує ідею “pets vs cattle”: VM не потрібно лікувати вручну, її краще пересоздати з правильного image.; :contentReference [oaicite:10]{index=10}

Stateful workloads

COS має security-focused підхід для container host.; Тобто в неї є собою спільне коріння з технологічною основою ChromeOS, але призначення зовсім інше: не ноутбук для користувача, а хмарна VM для контейнерів.; Критерій

  • шукати 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.;
  • Google Cloud Container-Optimized OS documentation.; COS підтримує роботу запуск інстансів із GPU accelerators у відповідних сценаріях.; Офіційна документація зазначає, що користувач системи не має змогу встановлювати third-party kernel modules або drivers.; * обмеження inbound traffic;
  • захисту host;
  • контролю доступу до container ports;
  • defense-in-depth;
  • локальних правил;
  • segmentation;
  • додаткового захисту поверх Google Cloud firewall rules.;

Docker

Flatcar Container Linux — ще одна container-focused Linux-система, яка продовжує ідеї CoreOS Container Linux.; Google описує COS як спосіб оперативно, результативно й безпечно запускати Docker-контейнери на Google Cloud Platform.; Google Cloud має окремий how-to про running instances with GPU accelerators на COS.; Іноді найкраща ОС — це та, яку майже не чіпають руками, а без ускладнень запускають на ній контейнер.;
  • оптимізація для контейнерів;
  • супровід Google;
  • інтеграційні функціональні можливості з Compute Engine;
  • інтеграційні функціональні можливості з 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.; Критерій

Non-containerized applications

  • тримати застосунок у 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.;

Офіційні how-to матеріали Google Cloud для COS включають створення інстансів, запуск контейнерів, AppArmor, Cloud Logging, Node Problem Detector, host firewall, GPU accelerators і user-defined guest policies.;== Приклад container-first підходу ==

AppArmor

  • не зберігає важливі інформаційні дані на локальному диску;
  • має змогу бути пересозданий;
  • масштабується горизонтально;
  • бере конфігурацію з metadata, env або secret manager;
  • пише логи назовні;
  • зберігає інформаційні дані в managed database, object storage або persistent volume.;
; COS оптимізована саме для контейнерів, з цієї причини застосунок зазвичай доставляється як container image, а не встановлюється пакетами в систему.; Офіційна документація описує COS як ОС image, optimized for running Docker containers.; Критерій

Stateless workload:

COS має змогу бути не найкращим вибором, якщо:

  • 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.; Container-Optimized OS

Security hardening

Container-Optimized OS — це образ операційної системи для Google Compute Engine VM, оптимізований для запуску контейнерів.;=== GPU inference container === Спрощена ідея запуску контейнера на COS VM:

Найцікавіше: Container-Optimized OS схожа на службовий ліфт у датацентрі: вона не розроблена для краси, але оперативно й надійно доставляє контейнер туди, де він має працювати.;

COS можна використовувати напряму на Compute Engine VM.; AppArmor, least privilege, non-root containers і правильні IAM-права все одно потрібні.; Це дає системі низку ідей, характерних для appliance-like ОС:

{{SEO


Kubernetes cluster використовує COS як node OS, а користувач системи керує переважно pods, deployments і services.; Цікавий момент: у container host логування — це не дрібниця, а частина архітектури.; * COS — хороший приклад того, як хмарна ОС має змогу бути спеціалізованою, а не універсальною.; Критично: контейнер — це не абсолютна межа безпеки.; :contentReference [oaicite:16]{index=16}

Висновок

  • запускати 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.; :contentReference [oaicite:4]{index=4}
Container-Optimized OS базується на open source ChromiumOS project.;

Практична роль: toolbox — це як тимчасовий рюкзак із інструментами: взяв для діагностики, використав, але не перетворив host на звичайний mutable server.; Водночас COS не підходить для класичних серверів із ручним встановленням пакетів, non-containerized apps, custom kernel modules або legacy workloads.; COS і Bottlerocket схожі ідеєю: мінімальна ОС для контейнерів у хмарі.; Офіційна документація прямо зазначає, що Container-Optimized OS does not include a package manager, з цієї причини не можна встановлювати software packages безпосередньо на instance.;== COS і Ubuntu Server ==

Toolbox корисний для:

Kubernetes і GKE

  • запуску 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, де не потрібна повна серверна ОС.; Це істотно для:

Оскільки COS не має package manager, для debugging і адміністративних інструментів можна використовувати toolbox-підхід.; Контейнери не скасовують security patches для kernel і host OS.; COS корисна там, де сервер існує не для того, щоб на ньому “жили” вручну встановлені програми, а для запуску контейнера.; * Container-Optimized OS

Отримано з https://wiki.corp2.eu/index.php?title=Container-Optimized_OS&oldid=1339