Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Cisco Connect 2018 Indonesia - Building container ready infrastructure
Similar to Cisco Connect 2018 Indonesia - Building container ready infrastructure (20)
More from NetworkCollaborators
More from NetworkCollaborators (20)
Recently uploaded
Recently uploaded (20)
Cisco Connect 2018 Indonesia - Building container ready infrastructure
- 1. © 2018 Cisco and/or its affiliates. All rights reserved. Building a Container-Ready Infrastructure PrastowoYuliarso DCTechnical Solution Architect
- 2. © 2018 Cisco and/or its affiliates. All rights reserved. Breaking systems into independently changeable agents From Monolithic to Microservices Architectures • Breaking complex enterprise systems traditionally built as monolith into discrete functional parts. • Allows for development and upgrades to happen modularly. • Allows for the different parts to be distributed across multiple machines for scale and availability. • Better utilization of physical resources by executing only the code and processes that provide an application service as opposed to an entire operating system. • Containers are the atomic unit of Microservices.
- 3. © 2018 Cisco and/or its affiliates. All rights reserved. Abstraction of resources at an OS and not a hardware level Comparing and Contrasting VMs to Containers Server Hypervisor App A App A App B Server Hypervisor Container Engine (Linux) App A App A App B App B Guest OS Guest OS Guest OS App B VM Container
- 4. © 2018 Cisco and/or its affiliates. All rights reserved. CISCO CONNECT 2018 . IT’S ALL YOU • Containers share the host kernel • Containers use the kernel ability to group processes for resource control • Containers ensure isolation through namespaces • Containers feel like lightweight VMs (lower footprint, faster), but are not Virtual Machines! Server Hypervisor Container Engine (Linux) App A App A App B App B App BContainer A more detailed look into Containers
- 5. © 2018 Cisco and/or its affiliates. All rights reserved. Containers are Linux • Containers are isolated processes • Containers ensure isolation through namespaces • Containers do NOT run on Docker. The Docker daemon uses user space tools that talk to the kernel to set up containers Server Hypervisor Container Engine (Linux) App A App A App B App B App BContainer BRKACI-1024 6
- 6. © 2018 Cisco and/or its affiliates. All rights reserved. CISCO CONNECT 2018 . IT’S ALL YOU • Kernel control groups (cgroups) • Limit, account for, and isolate the resource usage (CPU, memory, disk I/O, network, etc.) of a collection of processes • Namespaces • Provide isolation for different types of resources How are containers built? Key features used by containers Cgroups cpu cpuset memory device Namespaces PID MNT IPC UTC NET
- 7. © 2018 Cisco and/or its affiliates. All rights reserved. For development, it may be ok to run containers on a single host to develop and test an application. However, for production environments the following requirements need to be met: • Are fault-tolerant • Can scale, and do this on-demand • Use resources optimally • Can discover other applications automatically, and communicate with each other • Are accessible from the external world • Can update/rollback without any downtime. Container Orchestrators are the tools which group hosts together to form a cluster, while meeting the above requirements. Container Orchestration
- 8. © 2018 Cisco and/or its affiliates. All rights reserved. Container-based architecture Common elements Infrastructure Runtime Orchestration Kubernetes Container Platforms Nomad
- 9. © 2018 Cisco and/or its affiliates. All rights reserved. ACI + Kubenetes Benefits Visibility: Live statistics in APIC per container and health metrics Unified networking: Containers, VMs, and baremetal Micro-services load balancing integrated in fabric for HA / performance Secure multi tenancy and separation of concerns Seamless integration of Kubernetes network policies and ACI policies
- 10. © 2018 Cisco and/or its affiliates. All rights reserved. CISCO CONNECT 2018 . IT’S ALL YOU Solution Highlights: ACI and Kubernetes 1. Flexible mapping of Kubernetes policies to APIC policies • Simple developer driven workflow • Network team + developer workflow 2. Fabric load balancing • Symmetric PBR for north south traffic • Host datapath distributed internal load balancer 3. APIC GUI integration for Kubernetes • Stats per pod, deployment, service • Physical + virtual correlation Docker Host (Linux) OVS Key Capabilities APIC Kubernetes Plugins OpFlex Agent OpFlex Proxy Kubernetes Master CNI Plugin
- 11. © 2018 Cisco and/or its affiliates. All rights reserved. DEMO
- 12. © 2018 Cisco and/or its affiliates. All rights reserved.
Editor's Notes
- The services themselves are very simple, focussing on doing one thing well; Each service can be built using the best and most appropriate tool for the job; Systems built in this way are inherently loosely coupled; Multiple developers and teams can deliver relatively independently of each other under this model; Containers are the atomic unit. They are a great enabler for continuous delivery, allowing frequent releases whilst keeping the rest of the system available and stable.
- A container is a binary executable, packaged with dependencies and intended for execution in a private namespace with optional resource constraints.
- A container is a binary executable, packaged with dependencies and intended for execution in a private namespace with optional resource constraints.
- The Open Container Initiative (OCI) is a lightweight, open governance structure (project), formed under the auspices of the Linux Foundation, for the express purpose of creating open industry standards around container formats and runtime. The OCI was launched on June 22nd 2015 by Docker, CoreOS and other leaders in the container industry The OCI currently contains two specifications: the Runtime Specification (runtime-spec) and the Image Specification (image-spec). The Runtime Specification outlines how to run a “filesystem bundle” that is unpacked on disk. At a high-level an OCI implementation would download an OCI Image then unpack that image into an OCI Runtime filesystem bundle. At this point the OCI Runtime Bundle would be run by an OCI Runtime. This entire workflow should support the UX that users have come to expect from container engines like Docker and rkt: primarily, the ability to run an image with no additional arguments: docker run example.com/org/app:v1.0.0 rkt run example.com/org/app,version=v1.0.0 o support this UX the OCI Image Format contains sufficient information to launch the application on the target platform (e.g. command, arguments, environment variables, etc). This specification defines how to create an OCI Image, which will generally be done by a build system, and output an image manifest, a filesystem serialization, and an image configuration. At a high level the image manifest contains metadata about the contents and dependencies of the image including the content-addressable identity of one or more filesystem serialization archives that will be unpacked to make up the final runnable filesystem. The image configuration includes information such as application arguments, environments, etc. The combination of the image manifest, image configuration, and one or more filesystem serializations is called the OCI Image. Docker is donating its container format and runtime, runC, to the OCI to serve as the cornerstone of this new effort Some differences between Docker and Rkt can be provided here (Rkt biased): https://coreos.com/rkt/