Dev / Test / Ops – Gain More Horsepower and Reduce Costs by Sharing Kubernetes Clusters
•Download as PPTX, PDF•
0 likes•185 views
Containerization coupled with DevOps is revolutionizing application development and deployment, but organizations are creating silos of clusters that limit the operational efficiencies that can be gained by sharing hardware, software and systems administrators. This talk will cover how improved cluster management and consolidation at the orchestration, network and storage layers can yield great returns for developers, DevOps and IT management. (Slides from a presentation and demo at the Toronto Kubernetes Meetup on April 26, 2017.)
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Dev / Test / Ops – Gain More Horsepower and Reduce Costs by Sharing Kubernetes Clusters
Similar to Dev / Test / Ops – Gain More Horsepower and Reduce Costs by Sharing Kubernetes Clusters (20)
More from Ian Lumb
More from Ian Lumb (12)
Recently uploaded
Recently uploaded (20)
Dev / Test / Ops – Gain More Horsepower and Reduce Costs by Sharing Kubernetes Clusters
- 2. Univa Confidential www.univa.com 2 Who is Univa? Univa is the leading innovator of workload orchestration and container optimization solutions • Global reach – based in Chicago with offices in Canada and Germany • Fast growing enterprise software company • Support some of the largest clusters in global Fortune 500 companies
- 3. Univa Confidential Cloud Native Computing Foundation Mission: To create and drive the adoption of a new computing paradigm that is optimized for modern distributed systems environments. The participants believe that systems architected will be: • Container packaged • Dynamically managed • Micro-services oriented
- 4. Univa Confidential Brown Field versus Green Field • Complex • Political • High risk • Clean slate • Perfect for micro-services
- 5. Univa Confidential The Enterprise is brown field!
- 6. Univa Confidential www.univa.com 6 Mixed Workloads on OpenShift via Grid Engine Containerized Service Containerized Application Univa Grid Engine as a Pod Execd Execd Execd Execd • Grid Engine and execd’s run as pods and are managed and scaled based on Kubernetes and Command • All batch workloads are submitted thru Grid Engine • Labels tell Kubernetes where GPU nodes are for execd’s to run • Support for multiple GPUs Execd Execd
- 7. Univa Confidential Enterprise Container Adoption – Challenges • Storage – Containers are generally ephemeral . . . and so is the storage – Enterprise solutions not always performant in the cloud (i.e., NFS) • Networking – Early days for container networking. Still evolving. • Security – Isolation not at robust as virtual machines – Potential for threats in public container repositories – Security issues not as well understood as other more mature areas of IT . . . not hardened through widespread use – Container Breakouts, DoS attacks, Kernel Exploits, Compromised Secrets • Business Processes – Complex business process, policies, multiple user groups . . . all create complexity and challenges when architecting and orchestrating containerized workloads – Running container with non-container workloads can be tricky
- 8. Univa Confidential Navigating the Enterprise • A bridge from the brown fields – Orchestration • Univa Grid Engine – Container Edition, Apache Mesos – Storage • NFS, Gluster, Ceph, Flocker – Networking • Virtual switches • Options include Flannel, Weave, Docker Networking, Calico, Open Vswitch, OpenContrail – Configuration Management • Ansible, Puppet, Salt, • Or simplify with an immutable operating systems (CoreOS, Atomic . . . )
- 9. Univa Confidential 9 CloudOn Premises Servers / VMs After (60+% Utilization) “The next step is large scale orchestration and scale”. 451 Research Before (12% Utilization) Containers and other workloads need resources • Run containers at scale • Blend containers with other workloads • Maximize resources / use of cloud
- 12. Univa Confidential Command runs on any distribution! 12 Single Kubernetes Pluggable Scheduling API Native Support for numerous Kubernetes Distributions
- 13. Univa Confidential Navops Command Architecture 13 End User Admin Kubectl Web UI CLI REST API Bridge Container App Management Container Etcd Container Kubernetes API Server etcd Backend App Launcher REST Svc API Master Process Scheduler Thread Assign pods to nodes Kubernetes Objects Navops Command Pod
- 14. Univa Confidential Demo Environment 14Copyright © Univa Corporation, 2017. All Rights Reserved navops.io
- 16. Univa Confidential 16 Navops Command Delivers Before: <20% Utilization After: >50% Utilization Cluster A MicroServices Cluster B MicroServices Cluster C Batch MicroServices & Batch Workloads Virtual multi-tenancy Share clusters across teams and applications Mixed Workloads Allow batch and microservice applications to run on shared resources Management of Resource Scarcity Allow application loads to take advantage of non peak times for other workloads Faster Results / Higher Utilization / Lower Cost / Less Admin Effort Copyright © Univa Corporation, 2017. All Rights Reserved navops.io
- 17. Univa Confidential Thank you! Navops Command is free to up to 5 worker nodes DOWNLOAD NOW Ian Lumb ilumb@univa.com
Editor's Notes
- The first thing I would like to cover since all of you probably aren’t members of the CNCF is the definition of a Cloud Native Applications. First and foremost cloud native applications are designed to leverage the strengths of cloud providers delivering dynamic scalability, high availability, and robust security while remaining agnostic to the given features of any one cloud provider. The key here is that cloud native applications should be portable, easy to manage, and easy to upgrade. With these objectives its easy to see how decomposing an application into single task components or micro services, encapsulating an application in a Docker container to remove host operating system dependencies and networking specifics, and abstracting persistent storage are great architectural principles when creating cloud native applications.
- Which brings us to the next slide. Across our customer base we see both brown and green field environments. Sometimes there is an existing solution in place that we have to integrate with or replace. In these brownfield environments the operating system are already in place, the network architecture is complete and implemented and our software must work with the existing applications already running in the environment. At other sites we encounter new purpose built clusters where we can influence the choice of operating system and software stack. We can suggest a specific networking architecture to best suit our solution and their new applications. In these environments a clean solution can be designed and implemented from the ground up. These green field environments can fairly easily embrace the paradigm shift to cloud native.
- Unfortunately, or fortunately depending on how you look at it, the large enterprise is almost all brownfield. A cloud native infrastructure will need to integrate with the existing environment. It will need to integrate with existing solutions and most importantly it will need to integrate with the existing processes that the business has adopted for running their applications. Not all companies have the same application needs or run their applications the same way. These large organizations often have multiple environments and datacenters in multiple locations. These datacenters may be physical or virtual. They are complicated and different from one environment to the next.
- While some organizations have begun to move workloads to containers and adopt a cloud native paradigm in general there is still a long way to go before general adoption can occur at the enterprise. There are a lot of challenges in the enterprise. Storage must be thought of in a fundamentally different way with a complete decouple of stateful storage from the application. Once the applications are restructured they will have to integrate with the existing enterprise storage solutions. Networking of containerized applications usually requires an SDN with overlay networks or dynamic route distribution with service discovery. Integrating a container compatible networking infrastructure into an existing enterprise is not trivial. From a security perspective work still needs to be done to provide the isolation requirements many organizations need. Work also needs to be done to improve the trust level of images run on the platform. Last but not least applying existing business policy regarding access controls, workload prioritization, and auditing must be met when running both containerized and non container based applications.
- Fortunately there are other companies and organizations like Univa that are working on solutions and technologies to help bridge the gap between traditional enterprise environments and the the cloud native paradigm. With Univa Grid Engine Container Edition we have already seen how some organizations were able to run traditional as well as more cloud native applications on a single environment. In the storage space there are many exciting technologies helping organizations create on premise cloud native storage solutions and allow for general storage location abstraction. Software definite networking and networking overlay solutions are currently experiencing a boom in innovation and capability, Configuration management solutions are becoming more functional and container aware. Additionally several organizations have been developing immutable operating systems with the goal of greatly simplifying operating system deployment and configuration while providing ease of update and improved security patterns.
- The next product we plan to release in the Navops suite is navops command. Navops command adds the scheduling engine from Univa Grid engine to your kubernetes cluster. Command will allow kubernetes environment to leverage the rich policy, prioritization, scalability and resource sharing features we have developed over years of experience with our enterprise customers.