openstack kubernetes hypercontainer
play

OPENSTACK + KUBERNETES + HYPERCONTAINER The Container Platform for - PowerPoint PPT Presentation

OPENSTACK + KUBERNETES + HYPERCONTAINER The Container Platform for NFV ABOUT ME Harry Zhang ID: @resouer Coder, Author, Speaker Member of Hyper Feature Maintainer & Project Manager of Kubernetes sig-scheduling,


  1. OPENSTACK + KUBERNETES + HYPERCONTAINER The Container Platform for NFV

  2. ABOUT ME ➤ Harry Zhang ➤ ID: @resouer ➤ Coder, Author, Speaker … ➤ Member of Hyper ➤ Feature Maintainer & Project Manager of Kubernetes ➤ sig-scheduling, sig-node ➤ Also maintain: kubernetes/frakti (hypervisor runtime for k8s)

  3. NFV Network Functions Virtualization: why, and how?

  4. TRENDS OF TELECOM OPERATORS ➤ Traditional businesses rarely grow ➤ Non-traditional businesses climb to 8.1% of the whole revenue, even 15%~20% in some operators ➤ The new four business models: ➤ Entertainment & Media ➤ M2M ➤ Cloud computing ➤ IT service Source: The Gartner Scenario for Communications Service Providers

  5. WHAT’S WRONG? ➤ Pain of telecom network ➤ Specific equipments & devices Long deploy time cost Complex operation processes ➤ Strict protocol Multiple hardware devices co-exists ➤ Reliability & performance Close ecosystem ➤ High operation cost New business model requires new network functioning

  6. NFV ➤ Replacing hardware network elements with ➤ software running on COTS computers ➤ that may be hosed in datacenter ➤ Functionalities should be able to: ➤ locate anywhere most e ff ective or inexpensive ➤ speedily combined, deployed, relocated, and upgraded Speedup TTM Save TCO Encourage innovation

  7. USE CASE ➤ Project Clearwater ➤ Open source implementation of IMS (IP Multimedia Subsystem) for NFV deployment NFV Devices (physical equipments) VNF (software)

  8. SHIP VNF TO CLOUD Physical Equipments ->VNFs -> Cloud

  9. VNF cloud disk image ➤ Wait, what kind of cloud? ➤ Q: VM, or container? VNF VNF VNF ➤ A: 6 dimensions analysis container image ➤ Service agility VNF VNF VNF ➤ Network performance ➤ Resource footprint & density ➤ Portability & Resilience ➤ Configurability ➤ Security & Isolation

  10. SERVICE AGILITY ➤ Provision VM Container KVM ➤ hypervisor configuration 30 ➤ guest OS spin-up 25 Start up time in seconds ➤ align guest OS with VNFs 22.5 ➤ process mgmt service, startup scripts etc 15 ➤ Provision container ➤ start process in right namespaces and 7.5 cgroups ➤ no other overhead 0.38 0 Average Startup Time (Seconds) Over Five Measurements Data source: Intel white paper

  11. NETWORK PERFORMANCE Host Container KVM ➤ Throughput 30 ➤ “the resulting packets/sec that the VNF is able to push through the system is stable and similar in all 22.5 three runtimes” Millions 15 7.5 Packets per Second That a VNF Can Process in Different Environments Data source: Intel white paper 0 direct fwd L2 fwd L3 fwd

  12. NETWORK PERFORMANCE ➤ Latency ➤ Direct forwarding ➤ no big di ff erence ➤ VM show unstable caused by hypervisor time to process regular ➤ interrupts ➤ L2 forwarding ➤ no big di ff erence ➤ container even shows extra latency Data source: Intel white paper extra kernel code execution in cgroups ➤ ➤ VM show unstable cased by same reason above ➤

  13. RESOURCE FOOTPRINT & DENSITY ➤ VM 140 ➤ KVM 256MB(without —mem-prealloc) using about 125MB when booted 125 ➤ Container 105 Memory footprint ➤ only 17MB 70 ➤ amount of code loaded into memory is significantly less ➤ Deployment density 35 ➤ is limited by incompressible resource 17 0 ➤ Memory & Disk, while container does not container KVM 256MB need disk provision

  14. PORTABILITY & RESILIENCE ➤ VM disk image ➤ a provisioned disk with full operating system ➤ the final disk image size is often counted by OS Flavor Disk Size Container Image Size GB > 619MB > 188.3MB Ubuntu 14.04 ➤ extra processes for porting VM > 680MB > 229.6MB CentOS 7 ➤ hypervisor re-configuration — > 5 MB Alpine ➤ process mgmt service ➤ Container image — >2MB Busybox ➤ share host kernel = smaller image size Data source: Intel white paper ➤ can even be: “app binary size + 2~5MB” for deploy ➤ docker multi-stage build (NEW FEATURE)

  15. CONFIGURABILITY ➤ VM ➤ no obvious method to pass configuration to application ➤ alternative methods: ➤ share folder, port mapping, ENV … no easy or user friendly tool to help us ➤ ➤ Container ➤ user friendly container control tool (dockerd etc) ➤ volume ➤ ENV ➤ …

  16. SECURITY & ISOLATION ➤ VM ➤ hardware level virtualization ➤ independent guest kernel ➤ Container ➤ weak isolation level ➤ share kernel of host machine No cloud provider allow user to run containers without ➤ reinforcement ➤ Capabilities wrapping them inside full blown VM! ➤ libseccomp ➤ SELinux/APPArmor ➤ while non of them can be easily applied e.g. what CAP is needed/unneeded for a specific container? ➤

  17. “ Cloud Native vs Security?

  18. Hyper Let's make life easier

  19. HYPERCONTAINER ➤ Secure, while keep Cloud Native ➤ Make container more like VM ➤ Make VM more like container

  20. REVISIT CONTAINER FROM busybox ADD temp.txt / VOLUME /data CMD [“echo hello"] /bin /dev /etc /home /lib / lib64 /media /mnt /opt /proc / root /run /sbin /sys /tmp / read-write layer usr /var /data /temp.txt “echo hello” ➤ Container Runtime init layer Read-Write Layer & /data ➤ The dynamic view and boundary of your running process /etc/hosts /etc/hostname /etc/resolv.conf n o s j ➤ Container Image CMD [“echo hello"] n read-only layer o ➤ The static view of your program, data, dependencies, s j files and directories t x VOLUME /data t . p m e t / ADD temp.txt / FROM busybox e.g. Docker Container

  21. HYPERCONTAINER ➤ Container runtime: hypervisor ➤ RunV ➤ https://github.com/hyperhq/runv ➤ The OCI compatible hypervisor based runtime implementation ➤ Control daemon ➤ hyperd: https://github.com/hyperhq/hyperd ➤ Init service (PID=1) ➤ hyperstart: https://github.com/hyperhq/hyperstart/ ➤ Container image: ➤ Docker image ➤ OCI Image Spec

  22. STRENGTHS ➤ Service agility ➤ startup time: sub-second (e.g. 500~ms) ➤ Network performance ➤ same with VM & container ➤ Resource footprint ➤ small (e.g. 30MB) ➤ Portability & Resilience ➤ use Docker image (i.e. MB) ➤ Configurability ➤ same as Docker ➤ Security & Isolation Want to see a demo? ➤ hardware virtualization & independent kernel

  23. DEMO ➤ hyperctl run -d ubuntu:trusty sleep 1000 ➤ small memory footprint ➤ hyperctl exec -t $POD /bin/bash ➤ fork bomb ➤ Do not test this in Docker (without ulimit set) ➤ unless you want to lose your host machine :)

  24. WHERE TO RUN YOUR VNF? Container VM HyperContainer No Yes Yes Kernel features 380ms 25s 500ms Startup time Small Large Small Portable Image Small Large Small Memory footprint Flexible Complex Flexible Configurability of app Good Good Good Network Performance Yes (bring your own kernel) Backward Compatibility No Yes Weak Strong Strong Security/Isolation

  25. HYPERNETES the cloud platform for NFV

  26. HYPERNETES ➤ Hypernetes, also known as h8s is: ➤ Kubernetes + HyperContainer ➤ HyperContainer is now an o ffi cial container runtime in k8s 1.6 ➤ integration is achieved thru kubernetes/frakti project ➤ + OpenStack ➤ Multi-tenant network and persistent volumes ➤ standalone Keystone + Neutron + Cinder

  27. 1. CONTAINER RUNTIME

  28. POD ➤ Why? ➤ Fix some bad practices: ➤ use supervised manage multi-apps in one container Pod ➤ try to ensure container order by hacky scripts ➤ try to copy files from one container to another log app ➤ try to connect to peer container across whole network stack infra ➤ So Pod is init container container ➤ The group of super-a ffi nity containers ➤ The atomic scheduling unit volume ➤ The “process group” in container cloud ➤ Also how HyperContainer match to Kubernetes philosophy

  29. HYPERCONTAINER IN KUBERNETES Pod foo ➤ The standard CRI workflow container container ➤ see: 1.6.0 release note A B 1. RunPodSandbox(foo) NODE 2. CreatContainer(A) VM foo 3. StartContainert(A) 4. CreatContainer(B) A B 5. StartContainer(B) A B foo Container Runtime Interface (CRI) docker runtime hyper runtime

  30. 2. MULTI-TENANT NETWORK

  31. MULTI-TENANT NETWORK ➤ Goal: ➤ leveraging tenant-aware Neutron network for Kubernetes ➤ following the k8s network plugin workflow ➤ Non-goal: ➤ break k8s network model

  32. KUBERNETES NETWORK MODEL ➤ Pod reach Pod ➤ all Pods can communicate with all other Pods without NAT ➤ Node reach Pod ➤ all nodes can communicate with all Pods (and vice-versa) without NAT ➤ IP addressing ➤ Pod in cluster can be addressed by its IP

  33. DEFINE NETWORK ➤ Network ➤ a top level API object ➤ Network: Namespace = 1: N ➤ each tenant (created by Keystone) has its own Network ➤ Network Controller is responsible for lifecycle of Network object ➤ a control loop to create/delete Neutron “net” based on API object change

  34. ASSIGN POD TO NETWORK ➤ Pods belonging to the same Network can reach each other directly through IP ➤ a Pod’s network mapping to Neutron “port” ➤ kubelet is responsible for Pod network setup ➤ let’s see how kubelet works

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend