Download to read offline
Uploaded byPROIDEA
PLNOG19 - Emil Gągała - Przewodnik nowoczesnego sieciowca po pasjonującym, Nowym Świecie kontenerów i chmury
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
![[PLCUG] Hyper converged - Atlantis USX (PL)](https://cdn.slidesharecdn.com/ss_thumbnails/hyper-converged-atlantisusx-151020221915-lva1-app6892-thumbnail.jpg?width=640&height=640&fit=bounds)
![[PLCUG] Hyper converged - overview (PL)](https://cdn.slidesharecdn.com/ss_thumbnails/hyper-converged-overview-151020221731-lva1-app6891-thumbnail.jpg?width=640&height=640&fit=bounds)
PLNOG19 - Emil Gągała - Przewodnik nowoczesnego sieciowca po pasjonującym, Nowym Świecie kontenerów i chmury
- 1. Przewodnik nowoczesnego sieciowca wpasjonują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żebyć niebezpieczna • Pełna niespodzianek i zasadzek • Po co ryzykować? A może lepiej zostać? Luki_SL, Skyscrapercity
- 4. Dokąd jedziemy? Serwerownia DataCenter Cloud Cloudless ??? Serwer Virtual Machine Container Serverless PC AI Jak? Gdzie?
- 5.
- 6. Kontenery a MaszynyWirtualne 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 WROZWOJU Kontenery W PRODUKCJI
- 12. Środowisko kontenerów zlotu 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 K8smaster 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 routedtopology • 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 ContainerInterface (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.
- 21. Chmura – zakresodpowiedzialnoś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 przytym 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 wchmurze hybrydowej • Skalowanie i konsolidacja infrastruktury prywatnej i publicznej • Rozproszona ochrona przed atakami DDOS • Zaawansowana analiza informacji dotyczących bezpieczeństwa
- 27. Sieć i bezpieczeństwomię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órewarto 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.