# OpenShift

OpenShift — это платформа управления контейнерами, разработанная компанией Red Hat. Она предназначена для автоматизации развёртывания, управления и масштабирования приложений, используя контейнеризацию. Основой OpenShift является Kubernetes, мощная система оркестрации контейнеров с открытым исходным кодом.

OpenShift – феррари в мире виртуализации, круто, быстро и дорого

OpenShift это надстройка над Kubernetes, предлагающая дополнительные функции 
Он сразу же готов к использованию, его не надо долго и мучительно настраивать, можно немедленно пускать в продакшн.
Смотрите сколько всяких иконок, над Kubernetes. И каждая из них делает свои крутые штуки.





Интегрированное решение OpenShift [ServiceMesh](./4.3.6.4%20ServiceMash.md) (Istio, Kiali, Jaeger) пригодится при разработке микросервисов



Мониторинг и логирование%
Используйте встроенные инструменты OpenShift для мониторинга (Prometheus) и логирования (ELK stack, EFK stack). Это поможет оперативно выявлять и устранять проблемы.

Можно открыть Grafana, она читает метрики Prometheus и отрисовывает все дашборды: всю инфу по нодам, по подам, по приложениям, по сетевому траффику

## Интерфейс Openshift:

![DashboardSubtype](/pictures/Common/Orchestration/DashboardSubtype.png?raw=true)

<details>
<summary><strong>Раздел Home</strong></summary>
<p>

Список проектов (неймспейсы в кубернетесе)

Api Explorer - все объекте в кластере.

Events в рамках всего кластера: warnings, information, errors. Хранятся всего 2 часа, потом они недоступны.

ApiExplorer: все объекты, которые существуют внутри кластер


</p>
</details>

---

<details>
<summary><strong>Раздел Operators</strong></summary>
<p>

</p>
</details>

------


<details>
<summary><strong>Раздел Workloads</strong></summary>
<p>

Все основные объекты с которыми взаимодействуем

#### Pods

Здесь отображается список подов нашего проекта, можем выбрать какой-то из них и посмотреть метрики по нему (тк Openshift по дефолту поднимает Prometheus)
Events внутри под показывают только Event самого пода.

Создавать или изменять поды можно из веб интерфейса, где опеншифт сразу сгенерирует шаблон с минимально необходимыми шаблонами:

![CreatePod](/pictures/Common/Orchestration/CreatePod.png?raw=true)

#### Deployments

Deployments используется для **Stateless-приложение** (приложение без состояния), которое не помнит ничего между запросами. Каждый запрос обрабатывается независимо. Перезапустить его, ничего страшного не случится. Примеры: веб-серверы Nginx, бэкенд-API на Node.js/Python/Go, которые хранят состояние во внешней базе данных.

Обеспечивает декларативные (declarative) обновления для Pods и ReplicaSets и разворачивания приложений:

![DeploymentsSubtype](/pictures/Common/Orchestration/DeploymentsSubtype.png?raw=true)

Можно из интерфейса менять количество реплик (количество подов), что эквивалентно команды `kubctl scale replicas deployment <deploymentName>`

![PodsInDeployment](/pictures/Common/Orchestration/PodsInDeployment.png?raw=true)

#### DeploymentConfig 

Расширенная сущность Deployment`а

#### StatefulSets

Что делать с БД (с Reddis, Postgress, Kafka) или теми stateful-приложениями которым нужно сохранять какое-то состояние (их нельзя просто развернуть/перезапустить на другой ноде и оно будет работать - нет)?

Для таких случаев используется StatefulSets: 
 * У каждого пода свое стабильное DNS-имя  
 * Детерминированные, по порядку (app-0, app-1)

Примеры **Stateful-приложений**:
 * Базы данных: MySQL, PostgreSQL, MongoDB, Cassandra, Elasticsearch.
 * Системы обмена сообщениями: Kafka, RabbitMQ.
 * Ключ-значение хранилища: Redis, Etcd.

#### DaemonSet

Гарантирует, что определенный под будет запущен на всех (или некоторых) воркер-нодах;

Когда нода добавляется в кластер, для узла также добавляется новый под. При удалении DaemonSet все созданные им поды будут удалены.

Типичные сценарии применения DaemonSet:

* На каждой ноде можно запустить daemon кластерного хранилища, например glusterd или Ceph;

* На каждой ноде можно запустить daemon сбора логов или журналирования: EFK (Elasticsearch, FluentD максимум фичей или FluentBit - минимализм, а также Kibana);

* На каждой ноде можно запустить daemon мониторинга, такой как Prometheus Node Exporter, collectd, Datadog agent, агент New Relic или Ganglia (gmond).

#### Deployments vs StatefulSets vs DaemonSet


![k8sDeploymentsDaemonSetsStatefulSets](/pictures/Common/Orchestration/k8sDeploymentsDaemonSetsStatefulSets.png)

#### Secrets 

Используются для хранения конфиденциальной информации (пароли, токены, ssh-ключи).

Существует 5 видов секретов: key/value, image pull, source, webhook, from YAML

![SecretsSubtype](/pictures/Common/Orchestration/SecretsSubtype.png?raw=true)

### ConfigMaps

Позволяет переопределить конфигурацию запускаемых подов;

### Jobs (в том числе CronJob)

Cоздает один (или несколько) подов и гарантирует, что после выполнения команды они будут успешно завершены (terminated);

### ReplicaSets (ранее Replication Controller) 

Гарантирует, что в определенный момент времени будет запущено нужно кол-во контейнеров;

</p>
</details>




---------




<details>
<summary><strong>Раздел Networking</strong></summary>
<p>

![ServicesSubtype](/pictures/Common/Orchestration/ServicesSubtype.png?raw=true)

### Services

Абстракция, которая определяет логический набор подов и политику доступа к ним;

</p>
</details>

------

<details>
<summary><strong>Раздел Storage</strong></summary>
<p>

![StorageType](/pictures/Common/Orchestration/StorageType.png?raw=true)

</p>
</details>





---------





<details>
<summary><strong>Раздел Builds</strong></summary>
<p>

Раздел Builds - здесь представлены сущности, которых нет в [k8s](./4.3.6.2%20Kubernetes(k8s).md). 

#### BuildConfig 

Сущность из данного подраздела нужна для работы с DeploymentConfig (расширенная сущность Deployment`а).

![BuildConfigsSubtype](/pictures/Common/Orchestration/BuildConfigsSubtype.png?raw=true)

#### Builds

Видим собирающийся билд. К примеру, у нас есть гит репозиторий с докурфайлом и мы можем указать в BuildConfig, чтобы он триггерился на изменения в гите и в качестве таргета отслеживания будет докерфайл. Сам Опеншифт подключается к гиту и отслеживает состояния новых коммитов и запускает билд, пересобирает этот образ.

![BuildSubtype](/pictures/Common/Orchestration/BuildSubtype.png?raw=true)

</p>
</details>




------




<details>
<summary><strong>Раздел Observe</strong></summary>
<p>

</p>
</details>




------




<details>
<summary><strong>Раздел Compute</strong></summary>
<p>

Раздел Compute - служебная информация уровня всего кластера (в том числе информация по мастер нодам и воркер нодам): количество нод, живые ли они, сколько ядер и cpu используется на кажлой ноде, состояние ControlPlane

Пример: воркер нода для кубера - 8 [Ядер CPU](/2%20ComputerScience/2.0%20Linux/2.0.2%20Processor(CPU).md) и 16г [Озу/Ram](/3%20Memory%20and%20Concurrency/3.1%20Memory/3.1.2%20RandomAccessMemory/3.1.2.1%20RAM.md) 114 [Жесткой памяти диска](/3%20Memory%20and%20Concurrency/3.1%20Memory/3.1.1%20AboutMemory/3.1.1.1%20Memory.md)

</p>
</details>




------




<details>
<summary><strong>Раздел User Management</strong></summary>
<p>

Влияют на отображение разделов, в Openshift:

![Roles](/pictures/Common/Orchestration/Roles.png?raw=true)

Можно создавать новых пользователей, привязывать пользователей к ролям, к группам.

![UserManagemenrType](/pictures/Common/Orchestration/UserManagemenrType.png?raw=trueagemenrType)

#### ServiceAccounts

ServiceAccounts - это служебные учетные записи для технических целей: деплоя, выкачка образов и тп

![ServiceAccountsSubtype](/pictures/Common/Orchestration/ServiceAccountsSubtype.png?raw=true)

При создании нового project в Openshift создаются новые ServiceAccount: Deploy

</p>
</details>





------





<details>
<summary><strong>Раздел Administration</strong></summary>
<p>

![LimitRangeSubtype](/pictures/Common/Orchestration/LimitRangeSubtype.png?raw=true)

#### LimitRange

Какому-то неймспейсу можно выделять LimitRange (лимит квоты), те больше или меньше ресурсов([Ядер CPU](/2%20ComputerScience/2.0%20Linux/2.0.2%20Processor(CPU).md), [Озу/Ram](/3%20Memory%20and%20Concurrency/3.1%20Memory/3.1.2%20RandomAccessMemory/3.1.2.1%20RAM.md), [Жесткой памяти диска](/3%20Memory%20and%20Concurrency/3.1%20Memory/3.1.1%20AboutMemory/3.1.1.1%20Memory.md). Это нужно, чтобы задавать ограничения: проект маленький, а ресурсов может съедать много, чтобы не было такого приходится ограничивать.

</p>
</details>



------

[4.3.6.2 Kubernetes (k8s) Theme](./4.3.6.2%20Kubernetes(k8s).md) | [Back To iTWiki Contents](https://github.com/eldaroid/iTWiki) | [4.3.6.4 Service Mash Theme](./4.3.6.4%20ServiceMash.md)