- PVSM.RU - https://www.pvsm.ru -
Здравствуйте, уважаемые участники ИТ сообщества. Данный материал является незапланированным продолжением серии статей (первая статья [1], вторая статья [2], третья статья [3]), которые посвящены тестированию ПО в Openshift Origin [3]. В данной статье будут рассмотрены аспекты интеграции контейнеров и виртуальных машин посредством Openshift и Openstack [4].
Какие цели я преследовал интегрируя Openshift с Openstack:
Примечание: в данной статье не пойдет речи об автоматическом масштабировании кластера и предоставлении хранилищ данных.
Своими словами о программном обеспечении, которое способствовало достижению поставленных целей:
Openstack — операционная система для создания облачных сервисов. Мощный конструктор, который собрал под своё начало множество проектов и вендоров. По моему личному мнению конкурентов Openstack на рынке private cloud [9] просто нет. Инсталяции Openstack могут быть очень гибкими и многоэлементными, с поддержкой различных гипервизоров и сервисов. Доступны плагины Jenkins[1] [10][2] [11]. Поддерживается оркестрация [12], workflow [13], multi tenancy [14], zoning [15] и т.д.
Openshift Origin — standalone решение от Red Hat (в противовес Openshift Online и Openshift Dedicated [16]) предназаченное для оркестрации контейнеров. Решение построено на базе Kubernetes [17], но обладает рядом преимуществ/дополнений, которые обеспечивают удобство и эффективность работы.
1. Кластер Openshift размещен в облаке Openstack
Схема интеграции, когда все элементы расположены в облаке Openstack, весьма привлекательна и удобна, но главный минус данной схемы заключается в том, что контейнеры запускаются в виртуальных машинах и все преимущества в скорости сводятся на нет.
При данной схеме интеграции рабочим узлам Openshift назначается TRUNK [29] порт, который содержит некоторое количество SUBPORT. Каждый SUBPORT содержит индетификатор VLAN [30]. Если TRUNK порт находится в одной сети, то SUBPORT находится в другой. SUBPORT стоит рассматривать как мост между двумя сетями. При поступлении Ethernet кадра в TRUNK c меткой VLAN (которая соотвествует некому SUBPORT), то такой кадр будет направлен в соотвествующий SUBPORT. Из всего этого следует, что на рабочем узле Openshift создается обычный VLAN, который помещается в network namespace [31] контейнера.
2. Рабочие ноды Openshift кластера являются физическими серверами, master размещен в облаке Openstack
Схема интеграции, когда контейнеры запущены на выделенных серверах, не сложнее схемы со всеми элементами расположенными в облаке Openstack. VXLAN [32] позволяет организовать виртуальные сети без необходимости сегментирования сети предприятия.
При данной схеме интеграции на рабочих узлах Openshift работает Open vSwitch Agent [33], который интегрирован c Neutron. Запущенному контейнеру назначается VETH [34] устройство, которое работает напрямую с мостом Open vSwitch, то есть контейнер интегрируется в сеть Neutron напрямую. В последующем Open vSwitch Agent инициирует VXLAN соединение с Neutron Router для последущей маршрутизации пакетов.
Роль Kuryr во всех вариантах сводится к:
В самом простом варианте участники разработки имеют машрутизируемый доступ в сеть контейнеров и виртуальных мышин посредством Neutron Router, для этого достаточно прописать на рабочих станциях адрес шлюза для нужной подсети. Данную возможность трудно переоценить с точки зрения тестирования, так как стандартные механизмы (hostNetwork, hostPort, NodePort, LoadBalancer, Ingress [35]) Openshift/Kubernetes явно ограничены в возможностях, равно как и LBaaS [36] в Openstack.
Особенно трудно переоценить возможность разворачивать и иметь доступ к нужным приложениям, каталог которых доступен через веб-интерфейс Openshift (если такие проекты как Monocular [37] начали появляться сравнительно недавно, то в Openshift данный функционал присутствует с первых версий). Любой участник разработки может развернуть доступное приложение не тратя времени на изучение Docker [38], Kubernetes, самого приложения.
В случае с контейнерами всё очень просто, для каждого опубликованного сервиса создается FQDN запись во внутреннем DNS сервере по следующей схеме:
<service>.<pod_namespace>.svc.cluster.local
В случае с виртуальными машинами используется расширение dns [39] для ml2 [40] плагина:
extension_drivers = port_security,dns
При создании порта в Neutron задается аттрибут dns_name, которой и формирует FQDN:
[root@openstack ~]# openstack port create --dns-name hello --network openshift-pod hello
+-----------------------+---------------------------------------------------------------------------+
| Field | Value |
+-----------------------+---------------------------------------------------------------------------+
| admin_state_up | UP |
| allowed_address_pairs | |
| binding_host_id | |
| binding_profile | |
| binding_vif_details | |
| binding_vif_type | unbound |
| binding_vnic_type | normal |
| created_at | 2017-10-04T15:25:21Z |
| description | |
| device_id | |
| device_owner | |
| dns_assignment | fqdn='hello.openstack.local.', hostname='hello', ip_address='10.42.0.15' |
| dns_name | hello |
| extra_dhcp_opts | |
| fixed_ips | ip_address='10.42.0.15', subnet_id='4e82d6fb-9613-4606-a3ae-79ed8de42eea' |
| id | adfa0aab-82c6-4d1e-bec3-5d2338a48205 |
| ip_address | None |
| mac_address | fa:16:3e:8a:94:38 |
| name | hello |
| network_id | 050a8277-e4b3-4927-9762-d74274d9c8ff |
| option_name | None |
| option_value | None |
| port_security_enabled | True |
| project_id | 2823b3394572439c804d56186cc82abb |
| qos_policy_id | None |
| revision_number | 6 |
| security_groups | 3d354277-2aec-4bfb-91ac-d320bfb6c90f |
| status | DOWN |
| subnet_id | None |
| updated_at | 2017-10-04T15:25:21Z |
+-----------------------+---------------------------------------------------------------------------+
FQDN для виртуальной машины может быть разрешен с помощью DNS сервера, который обслуживает DHCP [41] для данной сети.
Остается лишь разместить на Openshift master (или в любом другом месте) DNS resolver, который будет разрешать *.cluster.local
с помощью SkyDNS Openshift [42], а *.openstack.local
с помощью DNS сервера сети Neutron.
Автор: livelace
Источник [45]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/testirovanie/265028
Ссылки в тексте:
[1] первая статья: https://habrahabr.ru/post/332994/
[2] вторая статья: https://habrahabr.ru/post/333012/
[3] третья статья: https://habrahabr.ru/post/333014/
[4] Openstack: http://openstack.org/
[5] L2: https://en.wikipedia.org/wiki/OSI_model
[6] FQDN: https://en.wikipedia.org/wiki/Fully_qualified_domain_name
[7] CI: https://en.wikipedia.org/wiki/Continuous_integration
[8] CD: https://en.wikipedia.org/wiki/Continuous_delivery#Relationship_to_continuous_deployment
[9] private cloud: https://en.wikipedia.org/wiki/Cloud_computing#Private_cloud
[10] [1]: https://wiki.jenkins.io/display/JENKINS/Openstack+Cloud+Plugin
[11] [2]: https://wiki.jenkins.io/display/JENKINS/Openstack+Heat+Plugin
[12] оркестрация: https://wiki.openstack.org/wiki/Heat
[13] workflow: https://wiki.openstack.org/wiki/Mistral
[14] multi tenancy: https://wiki.openstack.org/wiki/HierarchicalMultitenancy
[15] zoning: https://www.mirantis.com/blog/the-first-and-final-word-on-openstack-availability-zones/
[16] Openshift Online и Openshift Dedicated: https://en.wikipedia.org/wiki/OpenShift
[17] Kubernetes: https://en.wikipedia.org/wiki/Kubernetes
[18] Kuryr: https://wiki.openstack.org/wiki/Kuryr
[19] Neutron: https://wiki.openstack.org/wiki/Neutron
[20] NFV: https://en.wikipedia.org/wiki/Network_function_virtualization
[21] SDN: https://en.wikipedia.org/wiki/Software-defined_networking
[22] OpenContrail: http://www.opencontrail.org/
[23] MidoNet: https://www.midonet.org/
[24] Calico: https://www.projectcalico.org/
[25] Contiv: https://contiv.github.io/
[26] Weave: https://www.weave.works/
[27] CNI: https://github.com/containernetworking/cni
[28] OVS: http://openvswitch.org/
[29] TRUNK: https://wiki.openstack.org/wiki/Neutron/TrunkPort
[30] VLAN: https://en.wikipedia.org/wiki/Virtual_LAN
[31] network namespace: https://en.wikipedia.org/wiki/Linux_namespaces
[32] VXLAN: https://en.wikipedia.org/wiki/Virtual_Extensible_LAN
[33] Open vSwitch Agent: https://docs.openstack.org/liberty/networking-guide/scenario-classic-ovs.html
[34] VETH: https://lwn.net/Articles/232688/
[35] hostNetwork, hostPort, NodePort, LoadBalancer, Ingress: http://alesnosek.com/blog/2017/02/14/accessing-kubernetes-pods-from-outside-of-the-cluster/
[36] LBaaS: https://wiki.openstack.org/wiki/Neutron/LBaaS
[37] Monocular: https://github.com/kubernetes-helm/monocular
[38] Docker: http://docker.io/
[39] dns: https://docs.openstack.org/mitaka/networking-guide/config-dns-int.html
[40] ml2: https://wiki.openstack.org/wiki/Neutron/ML2
[41] DHCP: https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
[42] SkyDNS Openshift: https://docs.openshift.org/latest/architecture/networking/networking.html
[43] Openshift и Windows Containers: https://www.youtube.com/watch?v=B0qqnnmcb9w
[44] CRI-O поддерживает Clear Containers: http://cri-o.io/
[45] Источник: https://habrahabr.ru/post/339474/
Нажмите здесь для печати.