OpenShift Big

Pavel Mamontov, SA
pmamonto@redhat.com
5/08/2019
GENERAL DISTRIBUTION
ПРОБЛЕМА
Приложения требуют
сложной установки и
интеграции при каждом
развертывании
РЕШЕНИЕ
Принятие стратегии
контейнеризации
приложений позволяет
легко доставлять и
развертывать
приложения
ЧТО ТАКОЕ КОНТЕЙНЕРЫ?
INFRASTRUCTURE APPLICATIONS
● Процессы приложений работают ● Приложение и все его зависимости

изолированно на общем ядре ОС Linux упакованы в контейнер
● Проще, легче, выше плотность ● Развертывание в любую среду за

размещения чем у виртуальных машин считанные секунды, CI / CD
● Легкий доступ к контейнерам, легко
● Портативный, работают одинаково, организовать совместное
независимо от среды использование
4 GENERAL DISTRIBUTION
ВИРТУАЛЬНЫЕ МАШИНЫ И КОНТЕЙНЕРЫ
Виртуальная машина изолирует Контейнер изолирует процесс

оборудование
ВИРТУАЛЬНЫЕ МАШИНЫ И КОНТЕЙНЕРЫ
+ Изоляция VM + Изоляция контейнера

- Операционная система целиком + Совместное использование ядра Linux
- Статическая вычислительная мощность + Динамическая вычислительная мощность
- Статическая объем памяти + Динамический объем памяти
- Высокое потребление ресурсов + Низкое потребление ресурсов
ПРОБЛЕМА
DEVELOPERS I.T. OPERATIONS
РЕШЕНИЕ
Контейнеры
Практики
DevOps
DEVELOPERS I.T. OPERATIONS
РЕШЕНИЕ
Container
Зона
App ответственности
Dev
Operating System
Зона Virtual Machine

ответственности
IT Ops
Hardware
physical
DEVOPS
virtual
private cloud
public cloud
Как развернуть на несколько серверов,
центров обработки данных?
?
Как контейнеры поставляются в вашу инфраструктуру?
Как и где хранить образы контейнеров, чтобы они были доступны всем хостам?
Какой контейнер должен быть развернут на каком хосте?
У какого хоста больше аппаратных возможностей?
Как контролировать состояние здоровья контейнеров? Что делать, если они отказывают?
Как их масштабировать?
Как развернуть сложное приложение
на несколько серверов, центров обработки данных?
?
Какие контейнеры должны быть развернуты вместе?
Какие контейнеры могут обращаться друг к другу?
Как ограничить доступ к определенным контейнерам?
Как управлять тем, что работает внутри контейнера? Как бороться с уязвимостями?
Как контейнеры будут находить и видеть друг друга?
Как масштабировать контейнер: отдельные хосты, ЦОДы, регионы?
Что делать с постоянным хранилищем, если это stateful контейнер, база данных, например?
НАМ НУЖНО БОЛЬШЕ, ЧЕМ ПРОСТО
КОНТЕЙНЕРЫ
Scheduling Security
Где развернуть контейнеры Назначать кто что может сделать и
обеспечить безопасность в целом
Lifecycle and health Scaling

Поддерживать заданный масштаб Масштабировать в любую сторону
контейнеров, несмотря на отказы и ошибки
Discovery Persistence
Сетевое обнаружение контейнеров Сохранность данных, независимо от жизни
контейнера
Monitoring Aggregation
Прозрачность происходящего Собирать сложные приложения из множества
контейнеров
Kubernetes - это система с
открытым исходным кодом для
автоматизации развертывания,
взаимодействия и
масштабирования
контейнеризованных
приложений на множестве хостов
kubernetes
kubernetes
НЕДОСТАТОЧНО, НУЖНО БОЛЬШЕ!
Multi-tenancy Teams and Collaboration
Routing & Load Balancing Quota Management
CI/CD Pipelines Image Build Automation
Role-based Authorization Container Isolation
Capacity Management Vulnerability Scanning
Infrastructure Visibility Chargeback
ПЛАТФОРМА OPENSHIFT
Платформа для сборки,
развертывания и
эксплуатации
контейнерезированных
приложений, основанная на
Kubernetes, решающая
задачи CI/CD любых
масштабов
OPENSHIFT - ЭТО KUBERNETES
ГОТОВЫЙ ДЛЯ ПРОМЫШЛЕННОГО ИСПОЛЬЗОВАНИЯ
Kubernetes OpenShift
Release 1-3 месяца Release
исправлений и улучшений
Исправления безопасности
Сотни патчей и фиксов
200+ проверенных интеграций
Интеграции с промежуточным ПО
(container images, storage, networking, cloud services, etc)
Девятилетний жизненный цикл поддержки
Сертифицированный Kubernetes
РЕФЕРЕНСНАЯ АРХИТЕКТУРА
KUBERNETES ДЛЯ ИСПОЛЬЗОВАНИЯ НА ПРЕДПРИЯТИИ
Application Cluster Developer

Services Services Services
Middleware, Service Mesh, Functions, ISV Metrics, Chargeback, Registry, Logging Dev Tools, Automated Builds, CI/CD, IDE
Automated Operations*
Kubernetes
Red Hat Enterprise Linux or Red Hat CoreOS

Best IT Ops Experience CaaS PaaS Best Developer Experience
*coming soon
General Distribution
ТЕХНОЛОГИЧЕСКИЙ СТЕК
RED HAT OPENSHIFT
Container Container Container Container Container
Self-service
Service Catalog (Language Runtimes, Middleware, Databases, …)
Build Automation Deployment Automation
Application Lifecycle Management (CI / CD)
Container Orchestration & Cluster Management
Logs &
Networking Storage Registry Security
Metrics
Container Runtime & Packaging
Linux
Physical Virtual Private Public
КАК OPENSHIFT ПОМОГАЕТ
РАЗРАБОТЧИКАМ БЫТЬ ЭФФЕКТИВНЕЙ
BUILD TEST DEPLOY
Self-service Consistent Automated CI/CD Configuration App logs &

Provisioning environments build & deploy pipelines management metrics
CODE REVIEW MONITOR
SPRING & JAVA EE MICROSERVICES FUNCTIONS
LANGUAGES DATABASES APPLICATION SERVICES
LINUX WINDOWS*
* coming soon
АВТОМАТИЗИРОВАННАЯ КОНТЕЙНЕРНАЯ
ИНФРАСТРУКТУРА
INSTALL DEPLOY HARDEN OPERATE
AUTOMATED OPERATIONS
Infra provisioning Full-stack deployment Secure defaults Multi-cluster aware
Embedded OS On-premises and cloud Network isolation Monitoring and alerts
Unified experience Audit and logs Full-stack patch & upgrade
Signing and policies Zero downtime upgrades
Vulnerability scanning
НАДЕЖНАЯ ПЛАТФОРМА ДЛЯ
КОНТЕЙНЕРЕЗИРОВАННЫХ ПРИЛОЖЕНИЙ
Automated Secure by Network Over-the-air Monitoring Pluggable

Multi-tenant
operations default traffic control updates & chargeback architecture
BARE METAL, VSPHERE, RHV, OPENSTACK, AWS, AZURE, GOOGLE
КОНТЕЙНЕРНАЯ БЕЗОПАСНОСТЬ
CONTROL Container Content CI/CD Pipeline

Application
Container Registry Deployment Policies
Security
Container Platform Container Host Multi-tenancy

DEFEND
Network Isolation Storage
Infrastructure
Audit & Logging API Management
EXTEND Security Ecosystem
OPENSHIFT: ОСНОВЫ
контейнер - это самая маленькая
вычислительная единица
CONTAINER
27 OPENSHIFT TECHNICAL OVERVIEW

контейнер создается из
образа контейнера
CONTAINER
CONTAINER
IMAGE
BINARY RUNTIME

образы контейнеров хранятся в
реестре образов (registry)
IMAGE REGISTRY
CONTAINER CONTAINER CONTAINER

IMAGE IMAGE IMAGE
CONTAINER

IMAGE IMAGE IMAGE

репозиторий образов (image stream)
содержит все версии образов в реестре
образов (registry)
IMAGE REGISTRY
myregistry/frontend myregistry/mongo
frontend:latest mongo:latest
frontend:2.0 mongo:3.7
frontend:1.1 CONTAINER mongo:3.6 CONTAINER
frontend:1.0 IMAGE
mongo:3.4 IMAGE

контейнеры обернуты в поды (pods),
которые являются единицами
развертывания и управления
POD POD
IP: 10.1.0.11 IP: 10.1.0.55

конфигурация подов определена
в конфигурациях развертывания
(deployment config)
POD POD POD

image name
replicas
labels
cpu CONTAINER CONTAINER CONTAINER
memory
storage
DEPLOYMENT

сервисы (services) обеспечивают внутреннюю
балансировку нагрузки и службу обнаружения
(service discovery) между подами
BACKEND SERVICE
172.30.170.110
role: backend
POD POD POD POD
CONTAINER CONTAINER CONTAINER CONTAINER
10.140.4.44 10.110.1.11 10.120.2.22 10.130.3.33
role: frontend role: backend role: backend role: backend

приложения могут общаться друг с другом
через сервисы (services)
Invoke
Backend API BACKEND SERVICE
172.30.170.110
role: backend
POD POD POD POD
CONTAINER CONTAINER CONTAINER CONTAINER
10.140.4.44 10.110.1.11 10.120.2.22 10.130.3.33
role: frontend role: backend role: backend role: backend

маршрутезаторы (routers) добавляют сервисы к
внешним балансировщикам и предоставляют
читаемые URL для приложения
ROUTE
app-prod.mycompany.com
> curl http://app-prod.mycompany.com
BACKEND SERVICE
POD POD POD

проекты (projects) изолируют приложения
между средами, командами, группами и
департаментами
PAYMENT DEV CATALOG
POD POD POD POD POD POD

❌
C C C C C C
PAYMENT PROD INVENTORY
POD POD POD POD POD POD

❌ ❌
C C C C C C

АРХИТЕКТУРА OPENSHIFT
ВАШ ВЫБОР ИНФРАСТРУКТУРЫ
PHYSICAL VIRTUAL PRIVATE PUBLIC HYBRID

НОДЫ (nodes) - УЗЛЫ КЛАСТЕРА, ГДЕ
РАЗВЕРТЫВАЮТСЯ ПРИЛОЖЕНИЯ
NODE NODE NODE
RHEL RHEL RHEL
NODE NODE NODE
RHEL RHEL RHEL

ПРИЛОЖЕНИЯ ЗАПУСКАЮТСЯ В
КОНТЕЙНЕРАХ
NODE NODE NODE
Container
C Cc
Image
C C C
RHEL RHEL RHEL

Container
NODE NODE NODE
C C C C
Pod C
RHEL RHEL RHEL

ПОДЫ (pods) - ЕДИНИЦА ОРКЕСТРАЦИИ
NODE NODE NODE
C C
c
C C C
RHEL RHEL RHEL
NODE NODE NODE
C C C C
RHEL RHEL RHEL

МАСТЕРА (masters) - УЗЛЫ КЛАСТЕРА,
ОСУЩЕСТВЛЯЮЩИЕ УПРАВЛЕНИЕ
NODE NODE NODE

MASTER
RHEL RHEL RHEL
NODE NODE NODE
RED HAT
ENTERPRISE LINUX
RHEL RHEL RHEL

API И АУТЕНТИФИКАЦИЯ
NODE NODE NODE

MASTER
API/AUTHENTICATION
RHEL RHEL RHEL
NODE NODE NODE
RED HAT
ENTERPRISE LINUX
RHEL RHEL RHEL

ЖЕЛАЕМОЕ И ТЕКУЩЕЕ СОСТОЯНИЕ
NODE NODE NODE

MASTER
API/AUTHENTICATION
DATA STORE
RHEL RHEL RHEL
NODE NODE NODE
RED HAT
ENTERPRISE LINUX
RHEL RHEL RHEL
PHYSICAL
PHYSICAL
VIRTUALVIRTUAL
PRIVATEPRIVATEPUBLIC PUBLICHYBRID HYBRID

ИНТЕГРИРОВАННЫЙ РЕЕСТР ОБРАЗОВ
NODE NODE NODE

MASTER
API/AUTHENTICATION
DATA STORE
RHEL RHEL RHEL
NODE NODE NODE REGISTRY
RED HAT
ENTERPRISE LINUX
RHEL RHEL RHEL

ОРКЕСТРАЦИЯ И ПЛАНИРОВАНИЕ
NODE NODE NODE

MASTER
API/AUTHENTICATION
DATA STORE
RHEL RHEL RHEL
SCHEDULER NODE NODE NODE REGISTRY
RED HAT
ENTERPRISE LINUX
RHEL RHEL RHEL

РАЗМЕЩЕНИЕ СОГЛАСНО ПОЛИТИКАМ
NODE NODE NODE

MASTER
C Cc
API/AUTHENTICATION
C C
DATA STORE
RHEL RHEL RHEL
RED HAT
ENTERPRISE LINUX
RHEL RHEL RHEL

АВТОМАТИЧЕСКОЕ МАСШТАБИРОВАНИЕ
ПОДОВ
NODE NODE NODE

MASTER
C Cc
API/AUTHENTICATION
C C
DATA STORE
RHEL RHEL RHEL
HEALTH/SCALING
RED HAT
ENTERPRISE LINUX
RHEL RHEL RHEL

СЛУЖБА ОБНАРУЖЕНИЯ (service discovery)
SERVICE LAYER
NODE NODE NODE

MASTER
C Cc
API/AUTHENTICATION
C C C
DATA STORE
RHEL RHEL RHEL
HEALTH/SCALING C C C C
C
RED HAT
ENTERPRISE LINUX
RHEL RHEL RHEL

ОБЕСПЕЧЕНИЕ ПОДОВ ПЕРСИСТЕНТНЫМ
ХРАНИЛИЩЕМ
SERVICE LAYER
NODE NODE NODE PERSISTENT

MASTER STORAGE
C Cc
API/AUTHENTICATION
C C C
DATA STORE
RHEL RHEL RHEL
C
RED HAT
ENTERPRISE LINUX
RHEL RHEL RHEL

МАРШРУТИЗАЦИЯ И БАЛАНСИРОВКА
НАГРУЗКИ
ROUTING LAYER
SERVICE LAYER

MASTER STORAGE
C Cc
API/AUTHENTICATION
C C C
DATA STORE
RHEL RHEL RHEL
C
RED HAT
ENTERPRISE LINUX
RHEL RHEL RHEL

ДОСТУП ЧЕРЕЗ WEB, CLI, IDE И API
ROUTING LAYER
SERVICE LAYER

SCM
MASTER STORAGE
(GIT)
C Cc
API/AUTHENTICATION
C C C
CI/CD DATA STORE
RHEL RHEL RHEL
EXISTING C C C C
HEALTH/SCALING
AUTOMATION
TOOLSETS
C
RED HAT
ENTERPRISE LINUX
RHEL RHEL RHEL

ИНСТАЛЛЯЦИЯ OPENSHIFT
PROOF-OF-CONCEPT АРХИТЕКТУРА
Инфраструктурный узел (infra node) - это узел кластера, который
предназначен для таких модулей инфраструктуры, как
маршрутизатор, реестр образов, метрики и логирование.
MASTER INFRA
Dev and Ops Application
User Traffic
NODE NODE

АРХИТЕКТУРА ДЛЯ ОБЕСПЕЧЕНИЯ
ОТКАЗОУСТОЙЧИВОСТИ НА УРОВНЕ
ПРИЛОЖЕНИЙ (APP HA)
ENTERPRISE
LOAD-BALANCER
Application
Traffic
MASTER INFRA INFRA

Dev and Ops
User
NODE NODE NODE NODE

ПОЛНОСТЬЮ ОТКАЗОУСТОЙЧИВАЯ
АРХИТЕКТУРА
ENTERPRISE LOAD-BALANCER
Application
Dev and Ops Traffic
User
MASTER MASTER MASTER INFRA INFRA INFRA
NODE NODE NODE NODE NODE NODE NODE

TECHNICAL DEEP DIVE
MONITORING
APPLICATION HEALTH
AUTO-HEALING FAILED PODS
NODE NODE NODE
MASTER
API/AUTHENTICATION
C C C
DATA STORE
RHEL RHEL RHEL
SCHEDULER NODE NODE NODE
C C
HEALTH/SCALING c
RED HAT
ENTERPRISE LINUX RHEL RHEL RHEL

AUTO-HEALING FAILED CONTAINERS
NODE NODE NODE
MASTER
API/AUTHENTICATION
C C C
DATA STORE
RHEL RHEL RHEL
C C
HEALTH/SCALING c
RED HAT

NODE NODE NODE
MASTER
API/AUTHENTICATION
C C C
DATA STORE
RHEL RHEL RHEL
C C
HEALTH/SCALING c
RED HAT

NODE NODE NODE
MASTER
API/AUTHENTICATION
C C C
DATA STORE
RHEL RHEL RHEL
C C
HEALTH/SCALING c
RED HAT

NODE NODE NODE
MASTER
c c
API/AUTHENTICATION
C C C
DATA STORE
RHEL RHEL RHEL
SCHEDULER NODE NODE
C C
HEALTH/SCALING
RED HAT
ENTERPRISE LINUX RHEL RHEL

NETWORKING
BUILT-IN SERVICE DISCOVERY
INTERNAL LOAD-BALANCING
SERVICE Name: payroll-frontend

IP: 172.10.1.23
app=payroll role=frontend Port: 8080
POD POD POD

app=payroll app=payroll
role=frontend role=frontend app=payroll
version=1.0 version=1.0 role=backend

BUILT-IN SERVICE DISCOVERY
INTERNAL LOAD-BALANCING
SERVICE Name: payroll-frontend

IP: 172.10.1.23
app=payroll role=frontend Port: 8080
POD POD POD POD

app=payroll app=payroll app=payroll
role=frontend role=frontend role=frontend app=payroll
version=2.0 version=1.0 version=1.0 role=backend

ROUTE EXPOSES SERVICES EXTERNALLY
EXTERNAL TRAFFIC
ROUTER
INTERNAL TRAFFIC
SERVICE
POD POD POD

ROUTING AND EXTERNAL LOAD-BALANCING
● Pluggable routing architecture
○ HAProxy Router
○ F5 Router
● Multiple-routers with traffic sharding

● Router supported protocols
○ HTTP/HTTPS
○ WebSockets
○ TLS with SNI
● Non-standard ports via cloud load-balancers,

external IP, and NodePort

ROUTE SPLIT TRAFFIC
Split Traffic Between ROUTE
Multiple Services For A/B 90% traffic 10% traffic
Testing, Blue/Green and

SERVICE A SERVICE B
Canary Deployments
App A App A App B App B

EXTERNAL TRAFFIC TO A SERVICE
ON A RANDOM PORT WITH NODEPORT
● NodePort binds a service to a CLIENT
unique port on all the nodes connect

192.10.0.10:31421
192.10.0.11:31421
● Traffic received on any node 192.10.0.12:31421
redirects to a node with the SERVICE

running service INT IP: 172.1.0.20:90
● Ports in 30K-60K range which

usually differs from the service
POD POD POD
● Firewall rules must allow traffic to 10.1.0.1:90 10.1.0.2:90 10.1.0.3:90
all nodes on the specific port

NODE NODE NODE
192.10.0.10 192.10.0.11 192.10.0.12

EXTERNAL TRAFFIC TO A SERVICE
ON ANY PORT WITH INGRESS
● Access a service with an external CLIENT
IP on any TCP/UDP port, such as connect

200.1.0.10:90
○ Databases
○ Message Brokers SERVICE
EXT IP: 200.1.0.10:90

● Automatic IP allocation from a INT IP: 172.1.0.20:90
predefined pool using Ingress IP

Self-Service
POD POD POD
● IP failover pods provide high
10.1.0.1:90 10.1.0.2:90 10.1.0.3:90
availability for the IP pool
NODE NODE NODE
192.10.0.10 192.10.0.11 192.10.0.12

CONTROLLING EGRESS TRAFFIC
Default Kubernetes Behaviour
PROJECT B
POD
✓
NODE 1
IP 1
EXTERNAL
POD SERVICE
Whitelist: IP1
NODE 2
POD
IP 2
PROJECT A

Egress Router
PROJECT B
NODE 1
POD
IP 1 *
EGRESS
✓
EGRESS
POD SERVICE ROUTER
INT-IP IP 3 EXTERNAL
NODE 2 SERVICE
IP 2
Whitelist: IP 3
POD
**
PROJECT A
* Blocked by multi-tenant network plugin

** Blocked by external service

Egress Router
PROJECT B PROJECT A
Failover to
NODE 1 EGRESS standby
POD ROUTER egress
IP 1 * IP 3 router
EGRESS
✓
EGRESS
ROUTER
POD SERVICE
INT-IP IP1 EXTERNAL
NODE 2 SERVICE
IP 2
Whitelist: IP 3
POD
**
PROJECT A
* Blocked by multi-tenant network plugin

** Blocked by external service

Egress IP High Availability (multiple IPs)
PROJECT B
NODE 1 IP 1
POD
IP 1
POD EXTERNAL
HANDLER
EGRESS
SERVICE
✓
NODE 2 IP 4
IP 4
IP 2
Whitelist:
POD IP 4, IP 5
PROJECT A
Egress IP:
IP 4 (Node 2)
IP 5 (Node 3)
HANDLER
NODE 3
IP 3
POD
✓ EGRESS
IP 5

Egress IP High Availability (multiple IPs)
PROJECT B
NODE 1 IP 1
POD
IP 1
POD EXTERNAL
HANDLER
EGRESS
NODE 2 SERVICE
IP 4
IP 2
IP 4 Whitelist:
POD failed! IP 4, IP 5
PROJECT A
Egress IP:
IP 4 (Node 2)
IP 5 (Node 3)
HANDLER
✓ EGRESS
✓
NODE 3 IP 5
IP 5
POD
IP 3

Egress IP High Availability (single IP)*
PROJECT B
NODE 1 IP 1
POD
IP 1
POD EXTERNAL
HANDLER
EGRESS
NODE 2 SERVICE
IP 2
POD
✓ IP 4
failed!
Whitelist:
IP 4
PROJECT A
Egress IP:
IP 4 (Node 2)
IP 5 (Node 3)
HANDLER
✓ EGRESS
✓
NODE 3 IP 4
POD
IP 3
* coming soon

OPENSHIFT NETWORKING
● Built-in internal DNS to reach services by name
● Split DNS is supported via SkyDNS

○ Master answers DNS queries for internal services
○ Other name servers serve the rest of the queries
● Software Defined Networking (SDN) for a unified cluster

network to enable pod-to-pod communication
● OpenShift follows the Kubernetes

Container Networking Interface (CNI) plug-in model

OPENSHIFT NETWORK PLUGINS
OPENSHIFT
KUBERNETES CNI
OpenShift OpenShift Open

Tigera Cisco
SDN SDN Juniper VMware kuryr- Daylight
Flannel** Nuage Calico & Contiv & Big Switch kubernetes
(OVS) (OVN*) Contrail NSX-T (CNI &
CNX Contiv-ACI
DEFAULT Kuryr)
Fully Supported Validated In-Progress

RH-OSP
Neutron
Plugin
* Coming as default in OCP 4.1

** Flannel is minimally verified and is supported only and exactly as deployed in the OpenShift on OpenStack reference architecture

OPENSHIFT NETWORKING
POD POD VxLAN Overlay POD POD

10.1.2.2 10.1.2.4 10.1.4.2 10.1.4.4
Network
NODE NODE
172.16.1.10 172.16.1.20
IP Network

OPENSHIFT SDN
FLAT NETWORK (Default)

● All pods can communicate with PROJECT A PROJECT B PROJECT C
each other across projects DEFAULT NAMESPACE
MULTI-TENANT NETWORK
NODE NODE
●
●
Project-level network isolation
Multicast support
POD POD
✓ POD POD
● Egress network policies POD POD POD POD
NETWORK POLICY
● Granular policy-based isolation Multi-Tenant Network

OPENSHIFT SDN - NETWORK POLICY
PROJECT A PROJECT B Example Policies

● Allow all traffic inside the project
● Allow traffic from green to gray
POD
8080
✓ POD ● Allow traffic to purple on 8080
5432
POD POD apiVersion: extensions/v1beta1

kind: NetworkPolicy
✓ metadata:
name: allow-to-purple-on-8080
POD POD spec:
podSelector:
✓ ✓ matchLabels:
color: purple
POD POD ingress:
- ports:
- protocol: tcp
port: 8080

OPENSHIFT SDN - OVS PACKET FLOW
Container to Container on the Same Host
NODE
veth0
POD 1
10.1.15.2/24
br0
vxlan0 eth0
10.1.15.1/24
192.168.0.100
veth1
POD 2
10.1.15.3/24

Container to Container on the Different Hosts
NODE 1
veth0 br0 eth0

POD 1 vxlan0
10.1.15.2/24 10.1.15.1/24
192.168.0.100
NODE 2
veth0 br0
POD 2 vxlan0 eth0
10.1.20.2/24 10.1.20.1/24
192.168.0.200

Container Connects to External Host
Container
NODE 1 to Container on Different Hosts
POD 1
veth0 br0
tun0 eth0
External
10.1.15.2/24 10.1.15.1/24 Host
192.168.0.100

OPENSHIFT SDN WITH
FLANNEL FOR OPENSTACK
NODE 1
veth0 docker0 Routing

POD 1 eth0
10.1.15.2/24 10.1.15.1/24 Table
192.168.0.100
flanneld
etcd
NODE 2 flanneld
veth0 docker0 Routing

POD 2 eth0
10.1.20.2/24 10.1.20.1/24 Table
192.168.0.200
Flannel is minimally verified and is supported only and exactly as deployed in the OpenShift on
OpenStack reference architecture https://access.redhat.com/articles/2743631

LOGGING & METRICS
CENTRAL LOG MANAGEMENT WITH EFK
● EFK stack to aggregate logs for hosts and applications
○ Elasticsearch: a search and analytics engine to store logs
○ Fluentd: gathers logs and sends to Elasticsearch.
○ Kibana: A web UI for Elasticsearch.
● Access control
○ Cluster administrators can view all logs
○ Users can only view logs for their projects
● Ability to send logs elsewhere

○ External elasticsearch, Splunk, etc

CENTRAL LOG MANAGEMENT WITH EFK
NODE
POD POD OPERATION LOGS

FLUENTD
NODE
ELASTIC ELASTIC
POD POD ELASTIC ELASTIC
ELASTICSEARCH KIBANA
POD POD
FLUENTD
ADMIN
NODE
RHEL
POD POD APPLICATION LOGS
POD POD
FLUENTD
ELASTIC ELASTIC
ELASTIC ELASTIC
RHEL ELASTICSEARCH KIBANA
POD POD
USER
RHEL

CONTAINER METRICS

CONTAINER METRICS
NODE
RED HAT
POD POD CLOUDFORMS
CONTAINER METRICS
FLUENTD
NODE
POD POD API OPENSHIFT
HEAPSTER HAWKULAR
WEB CONSOLE
POD POD
FLUENTD
NODE
RHEL USER
POD POD CUSTOM
DASHBOARDS
POD POD ELASTIC
CADVISOR
ELASTIC
CASSANDRA
RHEL
POD POD
RHEL

SECURITY
AUTOMATED & INTEGRATED SECURITY
Container Content CI/CD Pipeline
CONTROL
Application Security
Container Registry Deployment Policies
Container Platform Container Host Multi-tenancy
DEFEND Network Isolation Storage

Infrastructure
Audit & Logging API Management
EXTEND Security Ecosystem

SECRET MANAGEMENT
● Secure mechanism for holding sensitive data e.g.
MASTER
○ Passwords and credentials
○ SSH Keys
Distributed Store
○ Certificates
● Secrets are made available as

○ Environment variables
○ Volume mounts
○ Interaction with external systems NODE
Container Container
● Encrypted in transit and at rest
● Never rest on the nodes

CERTIFICATE MANAGEMENT
● Certificates are used to provide secure

✓ MASTER
connections to
✓ NODES
○ master and nodes Check
Expiry
Ansible
○ router and registry Playbook ✓ ROUTER
Redeploy
○ etcd Certs
✓ REGISTRY
● Ansible playbooks to automate redeployment
✓ ETCD
● Redeploy all at once or specific components
● Certificate expiry report generator

CERTIFICATE EXPIRY REPORT
CERTIFICATE CHECKS
● master and nodes
● router and registry service

certificates from etcd secrets
● master, node, router,

registry, and kubeconfig files
for cluster-admin users
● etcd certificates

PERSISTENT STORAGE
PERSISTENT STORAGE
● Persistent Volume (PV) is tied to a piece of network storage
● Provisioned by an administrator (static or dynamically)
● Allows admins to describe storage and users to request storage
● Assigned to pods based on the requested size, access mode, labels and type
NFS OpenStack Cinder iSCSI Azure Disk AWS EBS FlexVolume
GCE Persistent VMWare

GlusterFS Ceph RBD Fiber Channel Azure File
Disk vSphere VMDK
Container Storage
NetApp Trident*
Interface (CSI)**
* Shipped and supported by NetApp via TSANet
** Tech Preview

PERSISTENT STORAGE
POOL OF PERSISTENT VOLUMES
register PV Ceph
iSCSI GlusterFS NFSP NFSP NFSP
RBD
PV PV V V V
PV
Admin
PROJECT Pod Pod Pod
create claim
claim claim claim

User

DYNAMIC VOLUME PROVISIONING
Slow Azure
Azure-Disk Provisioner
define StorageClass AWS

Fast
AWS-SSD Provisioner
provision
Admin Fastest NetApp
PV
NetApp-Flash Provisioner
Pod
create claim: Fastest OpenShift

PV Controller
bound
claim
User

OPENSHIFT CONTAINER STORAGE
● Containerized Red Hat Gluster Storage
● Native integration with OpenShift
● Unified Orchestration using Kubernetes for
applications and storage APPLICATION APPLICATION APPLICATION
● Greater control & ease of use for developers
STORAGE STORAGE STORAGE
● Lower TCO through convergence CONTAINER CONTAINER CONTAINER
● Single vendor Support DISTRIBUTED, SECURE, SCALE-OUT STORAGE

CLUSTER

OPENSHIFT CONTAINER STORAGE
MASTER
NODE NODE NODE NODE
RHGS RHGS POD POD RHGS POD POD POD POD POD
POD POD POD
POD POD POD

SERVICE BROKER
WHY A SERVICE BROKER?
☑ Open ticket
☑ Wait for allocation
☑ Receive credentials
☑ Add to app
☑ Deploy app
SERVICE SERVICE
CONSUMER PROVIDER
Manual, Time-consuming and Inconsistent

A multi-vendor project to
standardize how services
are consumed on
cloud-native platforms
across service providers

WHAT IS A SERVICE BROKER?
SERVICE SERVICE SERVICE SERVICE

CONSUMER CATALOG BROKER PROVIDER
Automated, Standard and Consistent

OPENSHIFT SERVICE CATALOG
OpenShift OPENSHIFT OpenShift
Template Templates
Broker
OpenShift ANSIBLE Ansible

Automation Playbook
Broker Bundles
AWS AWS
Service AWS
Broker Services
Other OTHER COMPATIBLE SERVICES

Other
Service
Services
Brokers
OPENSHIFT SERVICE CATALOG

SERVICE BROKER CONCEPTS
SERVICE: an offering that can be used by an app e.g. database
PLAN: a specific flavor of a service e.g. Gold Tier
SERVICE INSTANCE: an instance of the offering

SERVICE SERVICE SERVICE SERVICE
CONSUMER CATALOG BROKER PROVIDER
PROVISION: creating a service instance
BIND: associate a service instance and its credentials to an app

HOW TO ADD A SERVICE BROKER
● Deploy service broker on or off OpenShift
● Register the broker referring to the deployed broker
apiVersion: servicecatalog.k8s.io/v1alpha1
kind: Broker
metadata:
name: asb-broker
spec:
url: https://asb-1338-ansible-service-broker.10.2.2.15.nip.io
● Register the broker services by creating ServiceClass resources

(the service broker might automatically perform this step)

TEMPLATE SERVICE BROKER
● Exposes Templates and Instant Apps in the Service Catalog
● Pulled from openshift namespace by default
● Multiple namespaces can be configured for template discovery

TEMPLATE SERVER BROKER
PROVISIONING
openshift Service Broker creates a

namespace
the objects from the
nodejs-template
template
OpenShift
Service Catalog
Template Service Node.js

Broker Container

TEMPLATE SERVICE BROKER
BINDING
Service Broker creates a
binding and secret for
openshift
namespace any credentials (config
nodejs-template map, secret, etc) created
OpenShift by the template
Service Catalog
Template Service Node.js

Broker Container
create binding

OPENSHIFT ANSIBLE BROKER
● Use Ansible on OpenShift
○ Deploy containerized applications

○ Provision external services (e.g. Oracle database)
○ Provision cloud services (e.g. AWS RDS)
○ Orchestrate multi-service solutions
○ Conditional logic for control on deployments (e.g. database is initialized)
● Leverage existing Ansible playbooks
● Anything you can do with Ansible, you can do with OAB

ANSIBLE PLAYBOOK BUNDLES (APB)
● Lightweight application definition
● Packaged as a container image ├─ roles

├─ playbooks
│ ├─ provision.yaml
● Embedded Ansible runtime │ ├─ unprovision.yaml
│ ├─ bind.yaml
● Metadata for parameters │ └─ unbind.yaml
└─ apb.yaml
● Named playbooks for actions
Ansible Runtime
● Leverage existing Ansible playbooks
Ansible Playbook Bundle
● Registry is queried to discover APBs (Container Image)

PROVISIONING
OpenShift Registry
Docker Hub
Red Hat
Container Catalog
mediawiki-apb
postgresql-apb
Discover and list
OpenShift
APBs from the
Service Catalog configured image
registries
OpenShift
Ansible Broker

PROVISIONING
Pull APB image and
OpenShift Registry
Docker Hub
Red Hat
Container Catalog
run it with the broker
mediawiki-apb
action as a parameter
postgresql-apb
OpenShift
Service Catalog
APB
OpenShift
Container
Ansible Broker (postgresql)
oc run postgresql-apb provision $vars

PROVISIONING
APB container runs
OpenShift Registry
Docker Hub
Red Hat
Container Catalog
provision.yaml
mediawiki-apb
playbook to create a
postgresql-apb
PostgreSQL container
OpenShift
Service Catalog
APB Postgre
OpenShift
Ansible SQL
Container
Service Broker
Ansible (postgresql) Container
oc run postgresql-apb provision $vars ansible-playbook provision.yaml $vars

BINDING
APB container runs
OpenShift Registry
Docker Hub
Red Hat
Container Catalog
bind.yaml
mediawiki-apb
playbook to create
postgresql-apb
database user
OpenShift
Service Catalog
APB Postgre
OpenShift SQL
Container
Ansible Broker (postgresql) Container
oc run postgresql-apb bind $vars ansible-playbook bind.yaml $vars
MediaWiki
Container

BINDING
Service Catalog creates
OpenShift Registry
Docker Hub
Red Hat
Container Catalog
a secret for the binding,
mediawiki-apb
containing the database
postgresql-apb
credentials
OpenShift
Service Catalog
Postgre
OpenShift SQL
Ansible Broker Container
MediaWiki
Container
mount binding secret

BINDING
APB container goes
OpenShift Registry
Docker Hub
Red Hat
Container Catalog
away and Service Broker
mediawiki-apb
creates a binding for
postgresql-apb
the PostgreSQL service
OpenShift
Service Catalog
Postgre
OpenShift SQL
MediaWiki
create binding Container

BINDING
MediaWiki container
OpenShift Registry
Docker Hub
Red Hat
Container Catalog
uses the credentials in
mediawiki-apb
the secret to connect
postgresql-apb
to the PostgreSQL
OpenShift
Service Catalog
database
Postgre
OpenShift SQL
MediaWiki
Container
mount binding secret

REFERENCE
ARCHITECTURES
REFERENCE ARCHITECTURES
OpenShift on VMware vCenter Application Release Strategies with OpenShift
OpenShift on Red Hat OpenStack Platform Building Polyglot Microservices on OpenShift
OpenShift on Amazon Web Services Building JBoss EAP 6 Microservices on OpenShift
OpenShift on Google Cloud Platform Building JBoss EAP 7 Microservices on OpenShift
OpenShift on Microsoft Azure Business Process Management with JBoss BPMS on OpenShift
OpenShift on Red Hat Virtualization Build and Deployment of Java Applications on OpenShift
OpenShift on HPE Servers with Ansible Tower Building Microservices on OpenShift with Fuse Integration...
OpenShift on VMware vCenter 6 with Gluster JFrog Artifactory on OpenShift Container Platform
Deploying an OpenShift Distributed Architecture Spring Boot Microservices on Red Hat OpenShift
OpenShift Architecture and Deployment Guide API Management with Red Hat 3scale on OpenShift
OpenShift Scaling, Performance, and Capacity Planning App CI/CD on OCP with Jenkins

BUILD AND DEPLOY
CONTAINER IMAGES
BUILD AND DEPLOY CONTAINER IMAGES
DEPLOY YOUR DEPLOY YOUR DEPLOY YOUR

SOURCE CODE APP BINARY CONTAINER IMAGE

DEPLOY SOURCE CODE WITH
SOURCE-TO-IMAGE (S2I)
Git code
BUILD APP Repository
(OpenShift)
Developer
Source-to-Image
BUILD IMAGE (S2I)
(OpenShift) Builder Image

Image Registry
DEPLOY Application
Container
deploy
(OpenShift)
User/Tool Does OpenShift Does

DEPLOY APP BINARY WITH
SOURCE-TO-IMAGE (S2I)
Application build
Binary
BUILD APP (e.g. WAR)
(Build Infra) Existing Build

Process
Source-to-Image
BUILD IMAGE (S2I)
(OpenShift) Builder Image

Image Registry
DEPLOY Application
Container
deploy
(OpenShift)

DEPLOY DOCKER IMAGE
build
Application
BUILD IMAGE Image
(Build Infra) Existing Image

Build Process
Image
PUSH Registry
(Build Infra)
DEPLOY Application
Container
deploy
(Openshift)

BUILD IMAGES IN MULTIPLE STAGES
BUILD STAGE 1
BUILD STAGE 3
BUILD STAGE 2

EXAMPLE: USE ANY RUNTIME IMAGE WITH
SOURCE-TO-IMAGE BUILDS
Use Source-to-Image to build app binaries and deploy on lean vanilla runtimes
WILDFLY S2I BUILD app.war DOCKER BUILD
WildFly S2I WildFly

Builder Runtime
Image Image
read more on https://blog.openshift.com/chaining-builds/

EXAMPLE: USE ANY BUILD TOOL WITH
OFFICIAL RUNTIME IMAGES
Use your choice of build tool like Gradle and deploy to official images like the JDK image
CUSTOM GRADLE BUILD app.war DOCKER BUILD
Custom Red Hat

Gradle S2I OpenJDK
Builder Image Image

EXAMPLE: SMALL LEAN RUNTIMES
Build the app binary and deploy on small scratch images
CUSTOM GO BUILD app DOCKER BUILD
Custom
Scratch
Go S2I
Image
Builder Image

CONTINUOUS INTEGRATION (CI)
CONTINUOUS DELIVERY (CD)
CI/CD WITH BUILD AND DEPLOYMENTS
BUILDS
● Webhook triggers: build the app image whenever the code changes
● Image trigger: build the app image whenever the base language or app runtime changes
● Build hooks: test the app image before pushing it to an image registry
DEPLOYMENTS
● Deployment triggers: redeploy app containers whenever configuration changes or the
image changes in the OpenShift integrated registry or upstream registries

CONTINUOUS DELIVERY WITH CONTAINERS
physical
virtual
private cloud
dev source CI/CD container
repository engine
public cloud

OPENSHIFT LOVES CI/CD
JENKINS-AS-A SERVICE HYBRID JENKINS INFRA EXISTING CI/CD

ON OPENSHIFT WITH OPENSHIFT DEPLOY TO OPENSHIFT

JENKINS-AS-A-SERVICE ON OPENSHIFT
● Certified Jenkins images with pre-configured plugins Plugins
Jobs
○ Provided out-of-the-box Configuration
○ Follows Jenkins 1.x and 2.x LTS versions
● Jenkins S2I Builder for customizing the image

○ Install Plugins Jenkins
○ Configure Jenkins (S2I)
○ Configure Build Jobs

Jenkins
Image
● OpenShift plugins to integrate authentication with
OpenShift and also CI/CD pipelines
Custom
Jenkins
● Dynamically deploys Jenkins agent containers Image

HYBRID JENKINS INFRA WITH OPENSHIFT
● Scale existing Jenkins infrastructure by dynamically provisioning Jenkins agents on OpenShift
● Use Kubernetes plug-in on existing Jenkin servers
JENKINS JENKINS build

AGENT AGENT
run job JENKINS
APP APP
Run Job Run Job deploy
MASTER
OPENSHIFT

EXISTING CI/CD DEPLOY TO OPENSHIFT
● Existing CI/CD infrastructure outside OpenShift performs operations against OpenShift

○ OpenShift Pipeline Jenkins Plugin for Jenkins
○ OpenShift CLI for integrating other CI Engines with OpenShift
● Without disrupting existing processes, can be combined with previous alternative
EXISTING
S2I
run job CI/CD INFRA build Build
APP APP
Jenkins, Bamboo, deploy

TeamCity, etc
OPENSHIFT

OPENSHIFT PIPELINES
● OpenShift Pipelines allow defining a apiVersion: v1

CI/CD workflow via a Jenkins pipeline kind: BuildConfig
metadata: Provision a
which can be started, monitored, and name: app-pipeline
Jenkins agent for
spec:
managed similar to other builds strategy: running Maven
type: JenkinsPipeline
jenkinsPipelineStrategy:
● Dynamic provisioning of Jenkins agents jenkinsfile: |-
node('maven') {
stage('build app') {
● Auto-provisioning of Jenkins server git url: 'https://git/app.git'
sh "mvn package"
● OpenShift Pipeline strategies }
stage('build image') {
○ Embedded Jenkinsfile sh "oc start-build app --from-file=target/app.jar
}
○ Jenkinsfile from a Git repository stage('deploy') {
openshiftDeploy deploymentConfig: 'app'
}
}

OpenShift
Pipelines in
Web Console

CONTINUOUS DELIVERY PIPELINE
ARTIFACT
DEV TEAM GIT SERVER
REPOSITORY
● S2I build from source code

JENKINS
IMAGE BUILD ● S2I build from app binary
● Existing docker container image
build process
APPLICATION
IMAGE

DEVELOPER GIT SERVER ARTIFACT REPOSITORY
OPENSHIFT
CI/CD PIPELINE
(JENKINS)
IMAGE BUILD
& DEPLOY
OPENSHIFT OPENSHIFT
IMAGE IMAGE
REGISTRY REGISTRY
OPENSHIFT OPENSHIFT
CLUSTER CLUSTER
NON-PROD DEV PROD

OPENSHIFT
CI/CD PIPELINE
(JENKINS)
IMAGE BUILD PROMOTE
& DEPLOY TO TEST
OPENSHIFT OPENSHIFT
IMAGE IMAGE
REGISTRY REGISTRY
OPENSHIFT OPENSHIFT
CLUSTER CLUSTER
NON-PROD DEV TEST PROD

OPENSHIFT
CI/CD PIPELINE
(JENKINS)
IMAGE BUILD PROMOTE PROMOTE
& DEPLOY TO TEST TO UAT
OPENSHIFT OPENSHIFT
IMAGE IMAGE
REGISTRY REGISTRY
OPENSHIFT OPENSHIFT
CLUSTER CLUSTER
NON-PROD DEV TEST UAT PROD

ServiceNow
DEVELOPER GIT SERVER ARTIFACT REPOSITORY RELEASE MANAGER
JIRA Service Desk
GO Zendesk
LIVE? BMC Remedy
☒
OPENSHIFT
CI/CD PIPELINE
(JENKINS)
☑
IMAGE BUILD PROMOTE PROMOTE
& DEPLOY TO TEST TO UAT
OPENSHIFT OPENSHIFT
IMAGE IMAGE
REGISTRY REGISTRY
OPENSHIFT OPENSHIFT
CLUSTER CLUSTER

DEVELOPER GIT SERVER ARTIFACT REPOSITORY RELEASE MANAGER
GO
LIVE?
☒
OPENSHIFT
☑
CI/CD PIPELINE
(JENKINS)
IMAGE BUILD PROMOTE PROMOTE PROMOTE
& DEPLOY TO TEST TO UAT TO PROD
OPENSHIFT OPENSHIFT
IMAGE IMAGE
REGISTRY REGISTRY
OPENSHIFT OPENSHIFT
CLUSTER CLUSTER

BUT…
SOME TEAMS ALREADY HAVE AUTOMATED
DELIVERY PIPELINES

WHAT IF THERE ARE EXISTING DELIVERY
PROCESSES?
BUILD APP RUN PROMOTE APP BUILD CONTAINER RUN PROMOTE CONTAINER
BINARY TESTS BINARY IMAGE TESTS IMAGE
SOURCE
VERSION
CONTROL
ENTERPRISE ENTERPRISE
BINARY REPO IMAGE REGISTRY

WHAT IF THERE ARE EXISTING DELIVERY
PROCESSES?
BUILD APP RUN PROMOTE APP BUILD CONTAINER RUN PROMOTE CONTAINER
BINARY TESTS BINARY IMAGE TESTS IMAGE
SOURCE
VERSION
CONTROL
ENTERPRISE ENTERPRISE
BINARY REPO IMAGE REGISTRY
AWS ECR

ENRICHING EXISTING DELIVERY PROCESSES
WITH OPENSHIFT
EXISTING
DELIVERY
PROCESS
DEPLOY DEPLOY DEPLOY
OPENSHIFT
CLUSTER

ENRICHING EXISTING DELIVERY PROCESSES
WITH OPENSHIFT
EXISTING
DELIVERY
PROCESS
ENTERPRISE
IMAGE
REGISTRY
OPENSHIFT OPENSHIFT
IMAGE IMAGE
REGISTRY REGISTRY
OPENSHIFT OPENSHIFT
CLUSTER CLUSTER

HYBRID APPLICATION AUTOMATION
WITH OPENSHIFT AND ANSIBLE

HYBRID APPLICATION AUTOMATION
WITH OPENSHIFT AND ANSIBLE
CONTINUOUS
DELIVERY
PIPELINE
DEV PROD - REGION A PROD - REGION B
VIRTUAL VIRTUAL
MACHINE MACHINE
Hyper V VMware RHEV OpenStack AWS Azure Google Cloud

DEVELOPER WORKFLOW
LOCAL DEVELOPMENT WORKFLOW
Local
Bootstrap Develop Verify Git Push Pipeline
Deploy

Local
Deploy
BOOTSTRAP
● Pick your programming language and application runtime of choice
● Create the project skeleton from scratch or use a generator such as
○ Maven archetypes
○ Quickstarts and Templates
○ OpenShift Generator
○ Spring Initializr

Local
Deploy
DEVELOP
● Pick your framework of choice such as Java EE, Spring, Ruby on Rails, Django, Express, ...
● Develop your application code using your editor or IDE of choice
● Build and test your application code locally using your build tools
● Create or generate OpenShift templates or Kubernetes objects

Local
Deploy
LOCAL DEPLOY
● Deploy your code on a local OpenShift cluster
○ Red Hat Container Development Kit (CDK), minishift and oc cluster
● Red Hat CDK provides a standard RHEL-based development environment
● Use binary deploy, maven or CLI rsync to push code or app binary directly into
containers

Local
Deploy
VERIFY
● Verify your code is working as expected
● Run any type of tests that are required with or without other components (database, etc)
● Based on the test results, change code, deploy, verify and repeat

Local
Deploy
GIT PUSH
● Push the code and configuration to the Git repository
● If using Fork & Pull Request workflow, create a Pull Request
● If using code review workflow, participate in code review discussions

Local
Deploy
PIPELINE
● Pushing code to the Git repository triggers one or multiple deployment pipelines
● Design your pipelines based on your development workflow e.g. test the pull request
● Failure in the pipeline? Go back to the code and start again

APPLICATION SERVICES
A PLATFORM THAT GROWS WITH YOUR BUSINESS
Web Data Intelligent Micro

Application Virtualization Process services
API Single Java EE

Mobile
Management Sign-On Application
Real Time
Integration Messaging Data Grid
Decision

TRUE POLYGLOT PLATFORM
Third-party
.NET
LANGUAGES Java NodeJS Python PHP Perl Ruby Language
Core Runtimes
DATABASES MySQL PostgreSQL MongoDB Redis ...and virtually Third-party

Databases
CrunchyData
any docker GitLab

Iron.io
Apache
image Third-party
Phusion Couchbase
WEB SERVERS HTTP
Server
nginx Varnish Passenger Tomcat
out there! App
Runtimes Sonatype
EnterpriseDB
JBoss NuoDB
Spring Wildfly JBoss JBoss JBoss Third-party
Vert.x Web Middleware
Boot Swarm EAP A-MQ Fuse
Server Fujitsu
MIDDLEWARE and many more
3SCALE JBoss JBoss JBoss JBoss RH Third-party

RH SSO Middleware
API mgmt BRMS BPMS Data Virt Data Grid Mobile

LAUNCH
SUPPORTED RUNTIMES
Eclipse Vert.x WildFly Swarm Node.js Spring Boot JBoss EAP
OPENSHIFT
Modern, Cloud-Native Application Runtimes and

an Opinionated Developer Experience

MICROSERVICES
INFRASTRUCTURE:
ISTIO SERVICE MESH
REFER TO OFFICIAL
ISTIO PRESENTATION

OPENSHIFT 4
IMMUTABLE INFRASTRUCTURE
WITH RED HAT COREOS
● Minimal Linux distribution

● Optimized for running containers
● Decreased attack surface
● Over-the-air automated updates
● Immutable foundation for OpenShift
● Bare-metal and cloud host configuration

Fully automated day-1 and day-2 operations for Kubernetes
INSTALL DEPLOY HARDEN OPERATE
Infra provisioning Full-stack deployment Secure defaults Multi-cluster aware
Embedded OS On-premises and cloud Network isolation Monitoring and alerts
Unified experience Audit and logs Full-stack patch & upgrade
Signing and policies Zero downtime upgrades
Vulnerability scanning

OPERATOR AND DEVELOPER CONSOLES

OPERATOR CONSOLE

OPERATOR CONSOLE

INFRASTRUCTURE MONITORING

LINKS
http://learn.openshift.com
https://docs.openshift.com
https://blog.openshift.com
https://www.redhat.com/en/services/training/learning-subscription
THANK YOU
plus.google.com/+RedHat facebook.com/redhatinc
linkedin.com/company/red-hat twitter.com/RedHatNews
youtube.com/user/RedHatVideos
MICROSERVICES
INFRASTRUCTURE:
ISTIO SERVICE MESH
WHAT DO YOU NEED FOR MICROSERVICES?
Visibility & Reporting
Resilience & Fault Tolerance
Routing & Traffic Control
Identity & Security
Policy Enforcement

WHAT YOU NEED FOR MICROSERVICES?
Microservice
Visibility & Reporting Business Logic
Service Discovery Load Balancing
Resilience & Fault Tolerance Circuit Breaker Traffic Control
Monitoring Tracing

Netflix OSS
Config Server Security Policies
Identity & Security Service Registry Traffic Control
Monitoring Tracing
Policy Enforcement API Magenement Smart Routing
Infrastructure

MICROSERVICES EVOLUTION
Microservice
Business Logic
Microservice
Netflix OSS
Business Logic
Netflix OSS Container Platform
Platform

WHAT YOU NEED FOR MICROSERVICES?
Visibility & Reporting
Resilience & Fault Tolerance
Identity & Security

Istio
Policy Enforcement

WHAT IS ISTIO?
a service mesh to connect, manage, and secure microservices
Control Pilot Mixer Auth

Plane
Envoy Envoy Envoy Envoy
Data
Plane
App App App App
Pod Pod Pod Pod
TECH PREVIEW OCP 3.10

NETFLIX OSS VS ISTIO
Microservice
Business Logic
Service Discovery Load Balancing
Circuit Breaker Traffic Control
Monitoring Tracing
Microservices Microservice Microservices
App Business Logic App
Netflix OSS
Config Server Security Policies
OpenShift + Istio
Service Registry Traffic Control
Config Server Load Balancing
Monitoring Tracing
Service Registry Traffic Control
API Magenement Smart Routing
Monitoring Tracing
API Magenement Smart Routing

Platform

CONTROL OUTGOING TRAFFIC
SOURCE IP WITH EGRESS ROUTER
POD
EGRESS
EXTERNAL
POD EGRESS SERVICE ROUTER SERVICE
INTERNAL-IP:8080
POD
IP1 Whitelist: IP1
NODE
IP1
POD

Язык

OpenShift Big

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

OpenShift Big

Оригинальное название:

Загружено:

Авторское право:

Pavel Mamontov, SA

● Процессы приложений работают ● Приложение и все его зависимости

● Проще, легче, выше плотность ● Развертывание в любую среду за

Виртуальная машина изолирует Контейнер изолирует процесс

+ Изоляция VM + Изоляция контейнера

DEVELOPERS I.T. OPERATIONS

DEVELOPERS I.T. OPERATIONS

Зона Virtual Machine

Lifecycle and health Scaling

Routing & Load Balancing Quota Management

CI/CD Pipelines Image Build Automation

Role-based Authorization Container Isolation

Capacity Management Vulnerability Scanning

Infrastructure Visibility Chargeback

Application Cluster Developer

Red Hat Enterprise Linux or Red Hat CoreOS

Service Catalog (Language Runtimes, Middleware, Databases, …)

Build Automation Deployment Automation

Application Lifecycle Management (CI / CD)

Container Orchestration & Cluster Management

Container Runtime & Packaging

Physical Virtual Private Public

Self-service Consistent Automated CI/CD Conﬁguration App logs &

CODE REVIEW MONITOR

SPRING & JAVA EE MICROSERVICES FUNCTIONS

LANGUAGES DATABASES APPLICATION SERVICES

INSTALL DEPLOY HARDEN OPERATE

Embedded OS On-premises and cloud Network isolation Monitoring and alerts

Uniﬁed experience Audit and logs Full-stack patch & upgrade

Signing and policies Zero downtime upgrades

Automated Secure by Network Over-the-air Monitoring Pluggable

BARE METAL, VSPHERE, RHV, OPENSTACK, AWS, AZURE, GOOGLE

CONTROL Container Content CI/CD Pipeline

Container Platform Container Host Multi-tenancy

EXTEND Security Ecosystem

27 OPENSHIFT TECHNICAL OVERVIEW

28 OPENSHIFT TECHNICAL OVERVIEW

CONTAINER CONTAINER CONTAINER

CONTAINER CONTAINER CONTAINER

29 OPENSHIFT TECHNICAL OVERVIEW

30 OPENSHIFT TECHNICAL OVERVIEW

CONTAINER CONTAINER CONTAINER

IP: 10.1.0.11 IP: 10.1.0.55

31 OPENSHIFT TECHNICAL OVERVIEW

POD POD POD

32 OPENSHIFT TECHNICAL OVERVIEW

POD POD POD POD

CONTAINER CONTAINER CONTAINER CONTAINER

10.140.4.44 10.110.1.11 10.120.2.22 10.130.3.33

role: frontend role: backend role: backend role: backend

33 OPENSHIFT TECHNICAL OVERVIEW

POD POD POD POD

CONTAINER CONTAINER CONTAINER CONTAINER

10.140.4.44 10.110.1.11 10.120.2.22 10.130.3.33

role: frontend role: backend role: backend role: backend

34 OPENSHIFT TECHNICAL OVERVIEW

POD POD POD

CONTAINER CONTAINER CONTAINER

35 OPENSHIFT TECHNICAL OVERVIEW

POD POD POD POD POD POD

PAYMENT PROD INVENTORY

POD POD POD POD POD POD

36 OPENSHIFT TECHNICAL OVERVIEW

PHYSICAL VIRTUAL PRIVATE PUBLIC HYBRID