Większość z nas lubi podróżować. Zapraszam na egzotyczną “sieciową” podróż, gdzie poznamy nowe nieznane cywilizacje, odkryjemy na nowo koło z plemionami z github.com: Calico, Flannel, Canal, Weave, ale również spojrzymy z kosmosu na chmury, żeby zobaczyć, co oferują nam giganci stratosfery. Opowiem jak przygotować się do takiej wyprawy i jakie narzędzia się nam przydadzą. Na pewno w podróż warto wziąć słownik nowoczesnego sieciowca, żeby zrozumieć jak inni nazywają to, co my już dobrze znamy: subnet, load balancer, firewall. Jako, że jesteśmy przyjaźnie nastawieni na koniec zbudujemy mosty między naszą tradycyjną cywilizacją: „bare” i „virtual” metalu a Nowym Światem kontenerów i chmury. http://plnog.pl https://www.facebook.com/PLNOG/ https://twitter.com/PLNOG

1. Przewodnik nowoczesnego
sieciowca w pasjonującym
Nowym Świecie
kontenerów i chmury
Emil Gągała
Network & Security Architect
VMware

2. • Cel
• Mapa
• Słownik
• Prowiant
• Przewodnik
• Ubezpieczenie
Zanim wyruszymy w podróż

3. • Podróż może być niebezpieczna
• Pełna niespodzianek i zasadzek
• Po co ryzykować?
A może lepiej zostać?
Luki_SL, Skyscrapercity

4. Dokąd jedziemy?
Serwerownia Data Center Cloud
Cloudless
???
Serwer
Virtual
Machine
Container Serverless
PC AI
Jak?
Gdzie?

5. W końcu wyruszamy

6. Kontenery a Maszyny Wirtualne
App
A
Hypervisor (Type 2)
Host OS
Server
Guest
OS
Bins/
Libs
App
A’
Guest
OS
Bins/
Libs
App
B
Guest
OS
Bins/
Libs
AppA’
Docker
Host OS
Server
Bins/Libs
AppA
Bins/Libs
AppB
AppB’
AppB’
AppB’
VM
Container
Kontenery są izolowane,
ale dzielą OS oraz, w zależności
od aplikacji, binaria/biblioteki
Guest
OS
Guest
OS
Prostsze, małe, przenośne
• Szybszy rozwój aplikacji
• Mniejsze wymagania na zasoby
• Łatwiejsza migracja

7. Rozproszone aplikacje
Microservices
Kontenery != Mikro-usługi

8. Docker networking - domyślnie
Docker Host (VM)
int
eth0
192.168.178.0/24
192.168.178.100
int
docker 0
172.17.42.1/16
Iptables
Firewall
Linux Kernel
Routing
Linux
Bridge
‘docker0’
Iptables
Firewall
Iptables
Firewall
int
veth0f00eed
int
veth27e6b05
container
container
172.17.0.1/16
172.17.0.2/16
•Domyślna konfiguracja sieciowa
Dockera:
--bip=172.17.42.1/16
--ip-forward=true
--iptables=true
--icc=true
--ip-masq=true
--mtu=1500
•Domyślnie Docker przypisuje
adres IP dla każdego kontenera
z sieci --bip

9. Docker networking – ruch wychodzący
Docker Host (VM)
int
eth0
192.168.178.0/24
192.168.178.100
int
docker 0
172.17.42.1/16
Iptables
Firewall
Linux Kernel
Routing
Iptables
Firewall
Iptables
Firewall
int
veth0f00eed
int
veth27e6b05
container
container
172.17.0.1/16
172.17.0.2/16
• Ruch wychodzący z kontenera poprzez
interjest veth jest jest otrzymywany na
bridge ‘docker0’
• Ruch poddany jest inspekcji przez
iptables przed wysłaniem do bridge’a
• Domyślnie (if --icc=true), ruch z/do
kontenerów jest dozwolony na
dowolnym porcie
• Domyślnie (--ip-forward=true) Docker
umożliwia routing IPv4 w kernelu
• Na wyjściu, dla ruchu z kontenera
dokonywany jest Source NAT do
adresu IP Docker Hosta zgodnie z
iptables
Linux
Bridge
‘docker0’

10. Docker networking – ruch przychodzący
Docker Host (VM)
int
eth0
192.168.178.0/24
192.168.178.100
int
docker 0
172.17.42.1/16
Iptables
Firewall
Linux Kernel
Routing
Iptables
Firewall
Iptables
Firewall
int
veth0f00eed
int
veth27e6b05
container
container
172.17.0.1/16
172.17.0.2/16
• Ruch przychodzący jest przetwarzany
przez Docker host iptables
• Wpis DNAT jest tworzony dla każdego
kontenera, który był wystartowany z
opcją ‘docker run -p
<src_port:dst_port>’ lub –P
• Np. ‘docker run –p 8080:80’ tworzy
wpis DNAT:
z <docker_host_ip>:8080 do
<container_ip>:80
• Ruch DNAT jest routowany przez
kernel do docelowego kontenera na
bridge’u
• Ruch przychodzi do kontenera z
zmienionym dst_port/dst_ip i
niezmienionym src_ip
Linux
Bridge
‘docker0’

11. Rozwój a utrzymanie
Kontenery
W ROZWOJU
Kontenery
W PRODUKCJI

12. Środowisko kontenerów z lotu ptaka
IaaS Orchestration Layer
Hypervisor
Hypervisor
OSOS
Container
Container
Container
Container
Docker, Rocket,
LXD, …etc
Some Linux (REL/Ubuntu/…),
CoreOS, Photon OSOSOS
Container
Container
Container
Container
VM VM VM VM
Cluster /
mgmt
Cluster /
mgmt
Cluster /
mgmt
Cluster /
mgmt
etcd / zookeeper / doozerd
+
Fleet / Kubernetes / Mesos
OpenStack,
AWS, GCP, vRA,
Just plain vSphere,
Mesos …
Cluster deployment and
scale-up and down
OpenStack Heat,
vRA, Config
Management,
Shell scripts, … etc.
C
A
A
S

13. Sieć każdy może, trochę lepiej albo trochę gorzej
CNI – Container Network Interface
• Niezależny projekt Cloud Native Computing Foundation zawierający specyfikacje i
biblioteki dla pluginów sieciowych w środowisku kontenerów
• Używany m.in. przez Kubernetes, OpenShift, Cloud Foundry and Mesos
• Rozwiązanie alternatywne do Dockers Libnetwork Container Network Model
(CNM)
https://github.com/containernetworking/cni

14. Znajdź swoją sieć na github.com
• Calico
• Canal
• Cilium
• Contiv
• Flannel
• Nuage
• OpenContrail
• VMware NSX-T
• Weave

15. Kubernetes – słownik
K8s master
K8s master
Controller
Manager
K8s API
Server
Key-Value
Store
dashboard
Scheduler
K8s node
K8s node
K8s node
K8s node
K8s Nodes
kubelet c runtime
Kube-proxy
> _ Kubectl
CLI
K8s Master
Active / Standby
• Master: Centralny „control plane” i API serwer
• Node (‚Minion‘): Container host z usługami K8S
• POD: Grupa powiązanych kontenerów (np.
Web-Server i Log collector)
• Replication controller: zapewnia działanie
zdefiniowanej liczby replik POD’ów
• Service: Logiczny punkt dostępu do grupy
POD’ów. Wykorzystywany dla load balancingu
ruchu east-west
• Service Discovery: Z wykorzystaniem zmiennych
środowisk lub SkyDNS
• Ingress: opisuje load balancer N/S. Ingress
Controller konfgiruje ścieżkę danych load
balancera
• Namespace: wirtualny klaster. Zapewnia
logiczną sepację: unikalność nazwy, przydział
zasobów, RBAC, multi-tenancy

16. Kubernetes POD
Pod
pause container
(‘owns’ the IP stack)
10.24.0.0/16
10.24.0.2
nginx
tcp/80
mgmt
tcp/22
logging
udp/514
IPC
External IP Traffic
• POD: Grupa jednego lub więcej kontenerów
• Motywacja: Pod’y modelują wzorzec usługi kilku
współpracujących procesów tworzących razem
mikro aplikację
• Networking: Kontenery w ramach Pod’a
współdzielą adres IP i przestrzeń portów i mogą
odnaleźć siebie przez localhost. Komunikują się
między sobą przez standardową komunikację
IPC (inter-process communications)
• Storage: Kontenery w ramach Pod’a dzielą
również ten sam wolumen danych

17. K8S Flat routed topology
• Node routing: Każdy węzeł (K8S Node) jest
routerem odpowiedzialnym za przypisaną
podsieć IP
• Pods: Każdy Pod dostaje adres IP z podsieci
przypisanej do węzła
• IaaS Network: Sieć transportowa IaaS jest
odpowiedzialna za routing między węzłami K8S.
Może to wymagać ręcznej konfiguracji
• Wady :
• Konfiguracja routingu może być złożona
operacyjnie i wymagać współpracy różnych
zespołów
• K8s Namespace nie pokrywa się logicznie z
adresacją sieciową wezłów K8S.
• Zalety:
• Bezpośredni routing z/do Pod’ow ułatwia
integrację z istniejącymi aplikacjami na VM
i/lub BMS
Nodeint
eth0
10.240.0.4
int
cbr0
10.24.2.1/24
10.24.2.2 10.24.2.3 10.24.2.4
ip route 10.24.1.0/24 10.240.0.3
ip route 10.24.2.0/24 10.240.0.4
Nodeint
eth0
10.240.0.3
int
cbr0
10.24.1.1/24
10.24.1.2 10.24.1.3 10.24.1.4
net.ipv4.ip_forward=1
net.ipv4.ip_forward=1

18. K8S Node-to-node overlay • Node: Każdy węzeł K8S ma globalny widok
podsieci wszystkich węzłów, zwykle
implementowanych jako baza „key value store”
np. etcd
• Enkapsulacja: Ruch między węzłami jes
enkapsulowany. Podsieć każdego węzła jest
wskazana przez adres IP końcówki tunelu
nauczonego przez centralną bazę „key value
store”
• Wady:
• Routing do/z sieci nakładkowej jest trudny i
dotyczy jednego bądź wielu węzłów‘on-
ramp’ lub używania usług typu ‘NodePort’
• You might end up with an ‘overlay in
overlay’ situation
• Zalety:
• Bardzo łatwe na początku, brak potrzeby
interakcji z routingiem w infrastrukturze
• Implementacje: Sieci nakładkowe są używane
przez Flannel, Weave i OpenShift OVS networking
Nodeint
eth0
10.240.0.4
int
cbr0
10.24.2.1/24
10.24.2.2 10.24.2.3 10.24.2.4
Nodeint
eth0
10.240.0.3
int
cbr0
10.24.1.1/24
10.24.1.2 10.24.1.3 10.24.1.4
net.ipv4.ip_forward=1
net.ipv4.ip_forward=1
Overlay
Key-Value
Store

19. VMware NSX-T Container Interface (CIF)
• K8s Node VMs: Większość zastosowań K8S wykorzystuje
dziś VM do uruchamiania węzłów K8S
• Rozszerzona wirtualizacja sieci: Zamiast terminowania
sieci nakładkowej na poziomie portu węzła K8S (Node
VM), sieć z wirtualizatora jest rozciągana do wewnątrz
Node VM z wykorzystaniem wewnętrznego tagowania
VLAN. Wewnątrz Node VM jest zaimplementowany
niezależny vSwitch (OVS), który jest programowany
tylko przez NSX CNI Plugin
• Korzyści:
• Lepsze bezpieczeństwo dzięki rozdzieleniu ruch
zarządzania i aplikacyjnego
• Możliwość realizacji mikro-segmentacji na
poziomie POD

20. Odlatujemy

21. Chmura – zakres odpowiedzialności – przykład AWS
AWS Foundation Services
Compute Storage Database Networking
AWS Global
Infrastructure Regions
Availability Zones
Edge Locations
Client-side Data
Encryption
Server-side Data
Encryption
Network Traffic
Protection
Platform, Applications, Identity & Access Management
Operating System, Network & Firewall Configuration
Customer content
• Culture of security and
improvement
• Ongoing audit and assurance
program
• Protection of large-scale AWS
service endpoints
• Customers configure AWS
security features
• Get access to a mature vendor
marketplace
• Can implement and manage
their own controls
• Gain additional assurance above
AWS controls

22. Kupić czy wynająć - X as a Service
Albert Barron, IBM
Pamiętajmy o
Container as a Service !

23. Hybrydy są atrakcyjne, ...
Scenariusz 1:
Utrzymuj i rozszerzaj
RozszerzajUtrzymuj
Dodatkowa
pojemność
DR i
Backup
Scenariusz 2:
Konsoliduj and Migruj
MigrujKonsoliduj
Konsolidacja
Data Center
Migracja
Aplikacji
Scenariusz 3:
Pełna elastyczność
Dev, Test, Lab &
Training
Cykliczna
pojemność
Pełna elastyczność

24. ..., ale wymagające, ...
• Wiele formatów VM
• Różne podejście do sieci
• Inny model operacyjny
• Umiejętności i narzędzia
• Monitorowanie i zarządzenie
Dodatkowy koszt

25. ... a przy tym mogą być modne i wygodne
vRealize Suite, PowerCLI
VMware Cloud on AWS
AWS Global InfrastructureCustomer data center
Management
(vCenter
Server)
vCenter Server
Single pane of glass and API across on-premises and cloud
Access to all AWS services
Amazon
EC2
Amazon
S3
Amazon
RDS
AWS Direct
Connect
IAMAmazon
Redshift
…
…
…
…
AWS CloudFormation, AWS CLI, AWS SDK
AWS Global Infrastructure

26. Przykładowa aplikacja w chmurze hybrydowej
• Skalowanie i konsolidacja infrastruktury prywatnej i publicznej
• Rozproszona ochrona przed atakami DDOS
• Zaawansowana analiza informacji dotyczących bezpieczeństwa

27. Sieć i bezpieczeństwo między chmurami
VPC
AppWeb DB AppWeb DB
VNET
ConsistencyVisibility Security Networking
AppWeb DB
VPC
AppWeb DB
vCenter
ON PREMISES DATA CENTER
• Jednolita polityka bezpieczeństwa i sieci
• Widoczność ruchu
• Spójne narzędzia operacyjne między chmurami

28. 3 rzeczy, które warto zapamiętać
• Nie bać się podróży w nieznane
• CLI ≈ API
• Warto się dobrze przygotować
• Edukacja
• Sieć, to sieć
• W kontenerach i chmurze tylko trochę inna ;-)

29. Emil Gągała
egagala@vmware.com