Kubernetes News, Entwicklungen, Updates, HowTos - Seite 159 von 181

MetLife, the global provider of insurance, annuities, and employee benefit programs, will be celebrating it’s 150th birthday next year. Survival and success in their space depends on being agile and able to respond to changing market requirements. During the Day 2 General Session at DockerCon 2017, MetLife shared how they’re inspiring new innovation in their organization with Docker Enterprise Edition (EE).
Information Management is Core to MetLife
MetLife offers auto, home, dental, life, disability, vision, and health insurance to over 100 million customers across 50 countries. Their business relies on information – about policyholders, risk assessments, financial and market data, etc. Aaron Ades, AVP of Solutions Engineering at MetLife offers that they’ve been in the information management business for 150 years and have accumulated over 400 systems of record – some apps are over 30 years old.
The challenge for MetLife is that they still have a lot of legacy technology that they must work with. Aaron shared that there is still code running today that was first written in 1982, but they still need to deliver a modern experience on top of those legacy systems.
To hear more about how MetLife is staying ahead of their competition using Docker, watch Aaron’s presentation from the Day 2 general session.

Wrapping Legacy Apps with Docker EE
A key realization for MetLife was that wrapping containerized microservices around a legacy app would make them more easy to adapt and improve. As Aaron shared about breaking up the business logic into smaller pieces, “it makes you more nimble…it makes your systems of record much easier to deal with.” For MetLife, that also means the application becomes more portable. Once containerized, MetLife has the flexibility to host the services in their own datacenter or in the cloud.
With Docker EE, MetLife found a secure container platform that could deliver both objectives around containerization and management across a hybrid cloud. Docker provided them a commercially backed end-to-end container management solution. It was easy for the DevOps team to install and manage and it allowed them to go from concept to production in only 5 months.
Results and Benefits
With Docker in place, MetLife has shipped a new modern UI that allows customers and agents to have a holistic view of their relationship with the company. It can be viewed on a phone, laptop or other mobile device, but it taps into data written in different decades in different languages, running on different systems, successfully integrating the old with the new.

Aaron and his team have also seen significant operational improvements including:

The ability to scale quickly by leveraging Microsoft Azure to handle the 25x increase in traffic during annual open enrollment periods
Increased resource utilization with up to 70% consolidation of their VMs
More automation through orchestration allowing them to easily scale up a service or deal with VM/hardware failures

Adopting Docker EE has, more importantly, sparked a new wave of innovation at MetLife. As Aaron closed out his presentation, he recognized the “Mod Squad”, the team that led the Docker project and was credited with “changing the culture of the company” as “antibodies to the status quo”. He believes Docker has been transformative for his company and has ignited a spark across multiple businesses at MetLife. In the end, he believes this will allow them to be more agile and more nimble which is a core competitive advantage.
Watch Tim Tyler’s presentation below to learn more about how Metlife uses Docker Enterprise Edition.

Next Steps

Watch the entire Day 2 General Session from DockerCon 2017
View all the recorded sessions from DockerCon 2017
Learn more about Docker Enterprise Edition

The post Docker Enterprise Edition Lights a New Spark of Innovation within MetLife appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

2. Mai 2017

da Agency

Introducing Docker’s new CEO

Docker has celebrated a number of important milestones lately. March 20th was the fourth anniversary of the launch of the Docker project at PyCon in 2013. April 10th was the fourth anniversary of the day that I joined Solomon and a team of 14 other believers to help build this remarkable company. And, on April 18th, we brought the community, customers, and partners together in Austin for the fourth US-based DockerCon.

March 20th, 2013

Docker Team in 2013
DockerCon was a great opportunity to reflect on the progress we’ve seen in the past four years. Docker the company has grown from 15 to over 330 talented individuals. The number of contributors to Docker has grown from 10 to over 3300. Docker is used by millions of developers and is running on millions of servers. There are now over 900k dockerized apps that have been downloaded over 13 billion times. Docker is being used to cure diseases, keep planes in the air, to keep soldiers safe from landmines, to power the world’s largest financial networks and institutions, to process billions in transactions, to help create new companies, and to help revitalize existing companies. Docker has rapidly scaled revenues, building a sustainable and exciting subscription business in conjunction with tens of thousands of small and mid sized businesses and over 400 G2000 customers like ADP, the Department of Defense, GE, Goldman Sachs, Merck, MetLife, and Visa. And, we’ve created enduring partnerships with the likes of Accenture, Alibaba, Avanade, AWS, Booz Allen, Cisco, Google, HPE, IBM, Microsoft, Oracle, and more. We’ve built the foundations for a lasting and sustainable business.

I am incredibly humbled and honored to have been a part of this journey. So, it is naturally with some mixed emotions that I share the news that Steve Singh will become Docker’s new CEO (he is currently chairman of the board), and that I will be moving to a role on the board of directors. While there is always some uncertainty about changing roles, I am 100% certain that Steve is the right person for Docker.

He is an incredible individual and leader, with a broad base of experience that includes founding and growing one of the most successful enterprise companies, Concur. Over the course of two decades, Steve took Concur from startup to public company, successfully navigated the shift from software to SaaS, and built a world class team, customer base, and business model, forging an organization of lasting value. More recently, he has demonstrated his considerable expertise as a member of the SAP Executive Board Member, serving as President of SAP Business Networks and running SAP’s largest cloud businesses. As I worked with Steve– first as Docker’s chairman, and then as we worked together on the transition– I also saw his incredible qualities as a human being, and heard from the many people who have had the pleasure to work with Steve at Concur and SAP. (the average tenure at Concur was over twelve years). Docker has the potential to become not only one of the most enduring technology companies, but also a transformational platform, technology, and movement; I can’t think of a better or more qualified individual to lead us to that future than Steve.
I’d like to end this note with a few personal thoughts.

My first “Silicon Valley” Job, c. 1982
I started my “career” in Silicon Valley cutting apricots in an orchard a stone’s throw from what was to become Apple headquarters. Since then, I’ve had the privilege of working for six startups—three as CEO. Two went public (Avid and Verisign), two became part of larger companies (Gluster and Plaxo) and one was unceremoniously shut down by government officials. (A “business school” in Uzbekistan ). I think Docker has the potential to far exceed all of them.

Of the Six Startups I’ve worked at/led, Docker stands out (and certainly has the best logo!)
But, all of my startup experiences have been remarkable, and have taught me that my heart lies in startups. I’ve also learned that great companies are bigger than any individual person, and that a person’s life is defined by much more than any one company. Finally, I’ve seen that different leaders with different skills are needed at different stages in a company’s history. Steve is the right leader for Docker now, and I am confident that his leadership will enable Docker to fulfill its incredible potential.
I’d like to end by thanking a number of people. I’d like to thank Solomon for his vision, passion, brilliance, and willingness to share this journey with me. I’d like to thank our board and investors, our many partners, and especially Docker’s customers for their faith in–and support of–a young company and team with outsized dreams. I’d like to thank the incredibly creative and talented people who are using Docker for everything from finding cures for cancer to searching for earth-like planets to developing new sources of clean energy. Your enthusiasm and passion has made the past four years not only fun, but deeply meaningful. I’d like to thank my incredible family, my wife, and and three amazing sons for your support, love, patience, and encouragement through the long days, nights, and weekends.
Finally , I’d like to thank the incredible team at Docker. I’d like to thank the early employees ( like Sam Alba, Eric Bardin, Victor Vieux, Yannis Peyret, Ken Cochrane, and Jerome Petazzoni–who met me on my first day) and people like Nick Stinemates and Michael Crosby, who were among the first people I helped to bring into the company, and who have all continued to contribute so much to Docker. I’d like to thank entrepreneurs like Aanand, Anil, Ben, Daniel, Diogo, Evan, Jeff Julien, Madhu, Nathan, and Patrick who were willing to join their dreams and companies with ours. I’d like to thank the incredible members of the Docker executive team who I haven’t already mentioned: the irrepressible Roger Egan, the multi-talented Marianna Tessel, the hard-driving Scott Johnston, the passionate customer advocate Iain Gray, the wildly creative and insightful David Messina, and the unflappable Mike Gupta. Thank you for not only joining us at Docker, but for attracting and building such amazing teams of your own. And, thank you all for persevering through the difficult times. Thank you to Faith Kinyua for keeping me sane and organized. I could probably go on for at least another 300 names. But, to all of you: you are one of the most passionate, skilled, diverse, and amazing groups I’ve ever known. You have done such inspiring and impossible things already, and I will be cheering from the sidelines as you take Docker to even greater heights.

Docker Team Today
The post Introducing Docker’s new CEO appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

28. April 201728. April 2017

da Agency

Visa Inc. Gains Speed and Operational Efficiency with Docker Enterprise Edition

#DockerCon 2017 was an opportunity to hear from customers across multiple industries and segments on how they are leveraging #Docker technology to accelerate their business. In the keynote on Day 2 and also a breakout session that afternoon, Visa shared how Docker Enterprise Edition is empowering them on their mission is to make global economies safer by digitizing currency and making electronic payments available to everyone, everywhere.

Visa is the world’s largest retail electronic payment network that handles 130 billion transactions a year, processing $5.8 trillion annually. Swamy Kocherlakota, Global Head of Infrastructure and Operations, shared that Visa got here by expanding their global footprint which has put pressure on his organization which has remained mostly flat in headcount during that time. Since going into production with their Docker Containers-as-a-Service architecture 6 months ago, Mr. Kocherlakota has seen a 10x increase in scalability, ensuring that his organization will be able to support their overall mission and growth objectives well into the future.
Global Growth Fuels Need for A New Operating Model
In aligning his organization to the company mission, Swamy decided to focus on two primary metrics: Speed and Efficiency.

Speed is tied to developer on boarding and developer productivity. Visa wants new developers to be able to deploy code on their first day. That means giving them tools they are familiar with and getting out of their way. It also means providing developers access to infrastructure whenever and wherever they need it.

Efficiency is tied to Visa’s ability to maximize utilization of their existing datacenter footprint while also reducing the time the team spends on patching and refreshing hardware. Optimizing their efficiency also frees up both headcount and datacenter resources to support their global growth initiatives.

While considering how they could support these objectives, Visa also has to meet the high bar on security and availability that underpins everything they do. Some of the core systems at Visa have had zero downtime over a span of 20 years!
Modernizing with Docker Enterprise Edition
After investigating different technologies and vendors who could help them achieve both speed and efficiency objectives, Visa chose Docker Enterprise Edition (Docker EE) to help them move towards a microservices application model while also modernizing their data center operations.
Visa was looking for an enterprise-ready solution and appreciated the integrated approach of the Docker EE stack which includes scheduling, service registry, service discovery, container networking, and a centralized management control plane. Docker EE allows them to manage multiple development, QA, and staging environments, gain visibility across their container environment, and retain full control over role-based access.
Visa chose two key applications to begin their Docker journey – a core transaction processing application and a risk decision system. These were legacy monolithic applications which they began to containerize into services. Those two applications are now running in production on Docker EE across multiple regions and handling 100,000 transactions per day. They consist of 100 separate containers and have the ability to instantly scale to 800 when transactions peak.
To learn more about Visa’s application architecture, watch the breakout Docker Networking in Production at Visa below:

Results and Benefits

With Docker EE now in production, Visa is seeing improvements in a number of ways:

Provisioning time: Visa can now provision in seconds rather than days even while more application teams join the effort. They can also deliver just-in-time infrastructure across multiple datacenters around the world with a standardized format that works across their diverse set of applications.
Patching & maintenance: With Docker, Visa can simply redeploy an application with a new image. This also allows Visa to respond quickly to new threats as they can deploy patches across their entire environment at one time.
Tech Refresh: Once applications are containerized with Docker, developers do not have to worry about the underlying infrastructure; the infrastructure is invisible.
Multi-tenancy: Docker containers provides both space and time division multiplexing by allowing Visa to provision and deprovision microservices quickly as needed. This allows them to strategically place new services into the available infrastructure which has allowed the team to support 10x the scale they could previously.

To hear more about how Visa was able to gain 10x scalability for their application with Docker, watch Swamy’s presentation from the Day 2 general session below:

Docker Enterprise Edition (EE) is designed for enterprise development and IT teams who build, ship and run business critical applications in production at scale. Docker EE is integrated, certified and supported to provide enterprises like Visa with the most secure container platform in the industry to modernize all applications.
Next Steps

Watch the entire Day 2 General Session from DockerCon 2017
View all the recorded sessions from DockerCon 2017
Learn more about Docker Enterprise Edition

Docker Enterprise Edition and Docker Networking in production at @visa dockercon #DockerEE Click To Tweet

The post Visa Inc. Gains Speed and Operational Efficiency with Docker Enterprise Edition appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

28. April 201728. April 2017

da Agency

Visa Inc. Gains Speed and Operational Efficiency with Docker Enterprise Edition

Results and Benefits

With Docker EE now in production, Visa is seeing improvements in a number of ways:

To hear more about how Visa was able to gain 10x scalability for their application with Docker, watch Swamy’s presentation from the Day 2 general session below:

Watch the entire Day 2 General Session from DockerCon 2017
View all the recorded sessions from DockerCon 2017
Learn more about Docker Enterprise Edition

Docker Enterprise Edition and Docker Networking in production at @visa dockercon #DockerEE Click To Tweet

The post Visa Inc. Gains Speed and Operational Efficiency with Docker Enterprise Edition appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

26. April 201726. April 2017

da Agency

DockerCon 2017 Day 2 Highlights

Following the general session highlights from #DockerCon Day 1, we’re happy to share with you the video recording from general session day 2. All the slides will soon be published on our slideshare account and all the breakout session video recordings available on our DockerCon 2017 youtube playlist.

Here’s what we covered during the day 2 general session:

14:00 Docker Enterprise Edition at Visa
30:00 Securing the Software supply chain
65:00 Oracle applications now available on Docker Store
75:00 Modernize your Traditional Apps Program with Docker

Docker Enterprise Edition at Visa
Ben started off his DockerCon Day 1 keynote with key facts and figures around Docker Commercial Adoption. To illustrate his points Ben invited on stage Swamy Kochelakota, Global Head of Infrastructure and Operations at Visa to talk about their journey adopting Docker Enterprise Edition to run their critical applications at scale in a very diverse environment.
Securing the Software supply chain
During the day 2 keynote, Lily and Vivek and reprise their 2016 roles of dedicated burners, finally returning from Burning Man to get back to their jobs of enterprise dev and ops. Ben returns as clueless business guy, and decides to add value by hiring a contractor, who also went to Burning Man and pushed code from there. Company policy says that developers push code to dev repos, and if they pass certain criteria they are promoted to prod repos, and they can be deployed. The code written from Burning Man was laden with vulnerabilities and failed the promotion step. Luckily, Lily was able to clean up the image and pass it through promotions. Vivek then deployed the full stack, which consisted of an linux frontend and MS SQL DB on Windows. Using docker, he was able to deploy this stack on a hybrid Linux Windows cluster with just 1 click, bringing up the Enterprise Art Store and showing off some great enterprise art.
Oracle applications now available on Docker Store
Ben later asks Lily and Vivek to deploy the software from a 90s ecommerce company he acquired within an hour, and to do it in the container thingies. The app consists of a LAMP stack VM and Oracle DB. Vivek is skeptical that this can be containerized within an hour, but Lily is convinced Docker’s tools can handle it, so they make a bet of $20. Lily uses image2docker to convert the LAMP stack VM into a container without any code change. And as it turns out, Oracle has recently collaborated with Docker to containerize many of their apps, including OracleDB! The database is now an official product on the Docker Store, and can be found here. Using the converted VM and OracleDB from the store, Vivek was able to deploy the 90s app within the 1 hour time limit. Read more about Oracle database and developer tools now available on Docker Store.
Modernize your Traditional Apps Program with Docker
Finally, Ben announced the Modernize Traditional Applications (#MTA) Program to help enterprises make their existing legacy apps more secure, more efficient and portable to hybrid cloud infrastructure. Collaboratively developed and brought to market with partners Avanade, Cisco, HPE, and Microsoft, the MTA Program consists of consulting services, Docker Enterprise Edition, and hybrid cloud infrastructure from partners to modernize existing .NET Windows or Java Linux applications in five days or less. Designed for IT operations teams, the MTA Program modernizes existing legacy applications without modifying source code or re-architecting the application. Read more about the Modernize Traditional Apps Program.

Watch the dockercon general session videos from day 2! #DockerStore #DockerEE MTA Click To Tweet

Learn More about the general sessions announcements:

Learn more about the Modernize Traditional Apps Program
Sign up for the Modernize Traditional Apps Kit
Sign up for the DockerCon 2017 Recap Online Meetup
Register for DockerCon Europe 2017

The post DockerCon 2017 Day 2 Highlights appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

25. April 201725. April 2017

da Agency

DockerCon 2017 Day 1 Highlights

What an incredible #DockerCon 2017 we had last week. Big thank you to all of the 150+ confirmed speakers, 100+ sponsors and over 5,500 attendees for contributing to the success of these amazing 3 days in Austin. You’ll find below the videos and slides from general session day 1.All the slides will soon be published on our slideshare account and all the breakout session video recordings available on our DockerCon 2017 youtube playlist.

Here’s what we covered during the day 1 general session:

17:00 Developer Workflow improvements and demo
37:00 Secure Orchestration and demo
59:00 Introducing #LinuxKit: a toolkit for building secure, lean and portable linux subsystems
1:15 Introducing the Moby Project: a new open source project to advance the software containerization movement

Development workflow Improvements
Solomon’s keynote started by introducing new Docker features to improve the development workflows of Docker users: multi-stage builds and desktop-to-cloud integration. With multi-stage builds you can now easily separate your build-time and runtime container images, allowing development teams to ship minimal and efficient images. It’s time to say goodbye to those custom and non-portable build scripts! With desktop-to-cloud you can easily connect to a remote swarm cluster using your Docker ID for authentication, without having to worry about maintaining a complex public key infrastructure, nor requiring developers to get ssh access to the hosts themselves. Desktop-to-cloud is the fastest way for development teams to collaborate on shared pre-production environments.
Secure orchestration
In his presentation, Diogo Monica talks about SwarmKit and how to take the security of orchestration to the next level with secure node introduction, cryptographic node identify, MTLS between all nodes, cluster segmentation, encrypted networks and secure secret distribution. Watch the video to see a demo of this secure orchestration layer in action within an enterprise.
LinuxKit
Solomon then introduced a new component bringing Linux container functionality to new and varied platforms, from IoT to mainframes. This component called LinuxKit includes the tooling to allow building custom Linux subsystems that only include exactly the components the runtime platform requires. All system services are containers that can be replaced, and everything that is not required can be removed. All components can be substituted with ones that match specific needs. It is a kit, very much in the Docker philosophy of batteries included but swappable. Read more about LinuxKit.

Moby Project
Finally, Solomon announced the Moby Project, a new open-source project to advance the software containerization movement and help the ecosystem take containers mainstream. It provides a library of components, a framework for assembling them into custom container-based systems and a place for all container enthusiasts to experiment and exchange ideas. Read more about the Moby Project.
Docker users, please refer to Moby and Docker to clarify the relationship between the projects. Docker maintainers and contributors, please check out Transitioning to Moby for more details.

Watch the dockercon general session videos! Introducing linuxKit and @mobyClick To Tweet

Learn More about the general sessions announcements:

Read more about LinuxKit.
Read more about the Moby Project
Sign up for the DockerCon 2017 Recap Online Meetup
Register for DockerCon Europe 2017

The post DockerCon 2017 Day 1 Highlights appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

24. April 201724. April 2017

da Agency

Join Us for the Docker Federal Summit on May 2nd 2017

Docker is excited to announce that we are returning to the Newseum in Washington DC on May 2nd to host the second annual Docker Federal Summit event. A one day event packed with breakout sessions, discussions, hands on labs and technology deep dives from Docker and our ecosystem partners.

This event is designed for federal agency developers and IT ops personnel looking to learn more about how to approach Docker containers, cloud and devops to accelerate agency IT initiatives to support critical civilian and defense missions.

Government agency registration: Complimentary
Industry and ecosystem partner registration is $100

Register to save your seat.
Featured Speakers and Sessions
Technology leaders from agencies like GSA, USCIS and JIDO will share their experiences in deploying containers to production and provide pragmatic guidance in how to approach this change from technology to process and culture.

View the full agenda here.
Featured Breakout Sessions: A wide variety of breakout sessions feature technical deep dives, demonstrations and discussions around compliance and security.

Accelerating app development in the cloud
The latest initiatives around compliance for IT projects
How to scale and secure applications requiring FIPS
Docker technology deep dive from orchestration, security, management and more
Demos and deep dives from Sysdig, ETA, Cloudera and IBM

Learning Lab: Get hands on experience with Docker technology in the Learning Lab. Bring your own laptop with SSH and RDP installed to access the tutorials. Featured sessions include Docker Orchestration, Deploying and managing apps with Docker Enterprise Edition and Modernizing .NET Apps.
Technology Mall: The expo floor features event sponsors including technology and systems integrator partners that extend the Docker platform and accelerate the time to market to establish a Containers as a Service framework in your agency. A special thank you to our sponsors including: Booz Allen Hamilton, HPE, Microsoft, Cloudera, ETA, IBM, Sysdig, Aqua Security, Boxboat, IntegrityOne Partners, Twistlock and Immix Group.
See you in Washington DC for an exciting day of sharing, learning and connecting next week.
Register and See You Next Week:

Learn More about the Federal Summit agenda and register.
Learn more about Docker in Government
Try Docker Enterprise Edition for free

The post Join Us for the Docker Federal Summit on May 2nd 2017 appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

22. April 201722. April 2017

da Agency

How Bitmovin is Doing Multi-Stage Canary Deployments with Kubernetes in the Cloud and On-Prem

Editor’s Note: Today’s post is by Daniel Hoelbling-Inzko, Infrastructure Architect at Bitmovin, a company that provides services that transcode digital video and audio to streaming formats, sharing insights about their use of Kubernetes.Running a large scale video encoding infrastructure on multiple public clouds is tough. At Bitmovin, we have been doing it successfully for the last few years, but from an engineering perspective, it’s neither been enjoyable nor particularly fun. So obviously, one of the main things that really sold us on using Kubernetes, was it’s common abstraction from the different supported cloud providers and the well thought out programming interface it provides. More importantly, the Kubernetes project did not settle for the lowest common denominator approach. Instead, they added the necessary abstract concepts that are required and useful to run containerized workloads in a cloud and then did all the hard work to map these concepts to the different cloud providers and their offerings.The great stability, speed and operational reliability we saw in our early tests in mid-2016 made the migration to Kubernetes a no-brainer.And, it didn’t hurt that the vision for scale the Kubernetes project has been pursuing is closely aligned with our own goals as a company. Aiming for >1,000 node clusters might be a lofty goal, but for a fast growing video company like ours, having your infrastructure aim to support future growth is essential. Also, after initial brainstorming for our new infrastructure, we immediately knew that we would be running a huge number of containers and having a system, with the expressed goal of working at global scale, was the perfect fit for us. Now with the recent Kubernetes 1.6 release and its support for 5,000 node clusters, we feel even more validated in our choice of a container orchestration system.During the testing and migration phase of getting our infrastructure running on Kubernetes, we got quite familiar with the Kubernetes API and the whole ecosystem around it. So when we were looking at expanding our cloud video encoding offering for customers to use in their own datacenters or cloud environments, we quickly decided to leverage Kubernetes as our ubiquitous cloud operating system to base the solution on.Just a few months later this effort has become our newest service offering: Bitmovin Managed On-Premise encoding. Since all Kubernetes clusters share the same API, adapting our cloud encoding service to also run on Kubernetes enabled us to deploy into our customer’s datacenter, regardless of the hardware infrastructure running underneath. With great tools from the community, like kube-up and turnkey solutions, like Google Container Engine, anyone can easily provision a new Kubernetes cluster, either within their own infrastructure or in their own cloud accounts. To give us the maximum flexibility for customers that deploy to bare metal and might not have any custom cloud integrations for Kubernetes yet, we decided to base our solution solely on facilities that are available in any Kubernetes install and don’t require any integration into the surrounding infrastructure (it will even run inside Minikube!). We don’t rely on Services of type LoadBalancer, primarily because enterprise IT is usually reluctant to open up ports to the open internet – and not every bare metal Kubernetes install supports externally provisioned load balancers out of the box. To avoid these issues, we deploy a BitmovinAgent that runs inside the Cluster and polls our API for new encoding jobs without requiring any network setup. This agent then uses the locally available Kubernetes credentials to start up new deployments that run the encoders on the available hardware through the Kubernetes API.Even without having a full cloud integration available, the consistent scheduling, health checking and monitoring we get from using the Kubernetes API really enabled us to focus on making the encoder work inside a container rather than spending precious engineering resources on integrating a bunch of different hypervisors, machine provisioners and monitoring systems. Multi-Stage Canary DeploymentsOur first encounters with the Kubernetes API were not for the On-Premise encoding product. Building our containerized encoding workflow on Kubernetes was rather a decision we made after seeing how incredibly easy and powerful the Kubernetes platform proved during development and rollout of our Bitmovin API infrastructure. We migrated to Kubernetes around four months ago and it has enabled us to provide rapid development iterations to our service while meeting our requirements of downtime-free deployments and a stable development to production pipeline. To achieve this we came up with an architecture that runs almost a thousand containers and meets the following requirements we had laid out on day one:Zero downtime deployments for our customersContinuous deployment to production on each git mainline pushHigh stability of deployed services for customersObviously #2 and #3 are at odds with each other, if each merged feature gets deployed to production right away – how can we ensure these releases are bug-free and don’t have adverse side effects for our customers?To overcome this oxymoron, we came up with a four-stage canary pipeline for each microservice where we simultaneously deploy to production and keep changes away from customers until the new build has proven to work reliably and correctly in the production environment.Once a new build is pushed, we deploy it to an internal stage that’s only accessible for our internal tests and the integration test suite. Once the internal test suite passes, QA reports no issues, and we don’t detect any abnormal behavior, we push the new build to our free stage. This means that 5% of our free users would get randomly assigned to this new build. After some time in this stage the build gets promoted to the next stage that gets 5% of our paid users routed to it. Only once the build has successfully passed all 3 of these hurdles, does it get deployed to the production tier, where it will receive all traffic from our remaining users as well as our enterprise customers, which are not part of the paid bucket and never see their traffic routed to a canary track.This setup makes us a pretty big Kubernetes installation by default, since all of our canary tiers are available at a minimum replication of 2. Since we are currently deploying around 30 microservices (and growing) to our clusters, it adds up to a minimum of 10 pods per service (8 application pods + minimum 2 HAProxy pods that do the canary routing). Although, in reality our preferred standard configuration is usually running 2 internal, 4 free, 4 others and 10 production pods alongside 4 HAProxy pods – totalling around 700 pods in total. This also means that we are running at least 150 services that provide a static ClusterIP to their underlying microservice canary tier.A typical deployment looks like this:Services (ClusterIP)Deployments##Podsaccount-serviceaccount-service-haproxy4account-service-internalaccount-service-internal-v1.18.02account-service-canaryaccount-service-canary-v1.17.04account-service-paidaccount-service-paid-v1.15.04account-service-productionaccount-service-production-v1.15.010An example service definition the production track will have the following label selectors:apiVersion: v1kind: Servicemetadata: name: account-service-production labels: app: account-service-production tier: service lb: privatespec: ports: – port: 8080 name: http targetPort: 8080 protocol: TCP selector: app: account-service tier: service track: productionIn front of the Kubernetes services, load balancing the different canary versions of the service, lives a small cluster of HAProxy pods that get their haproxy.conf from the Kubernetes ConfigMaps that looks something like this:frontend http-in bind *:80 log 127.0.0.1 local2 debug acl traffic_internal hdr(X-Traffic-Group) -m str -i INTERNAL acl traffic_free hdr(X-Traffic-Group) -m str -i FREE acl traffic_enterprise hdr(X-Traffic-Group) -m str -i ENTERPRISE use_backend internal if traffic_internal use_backend canary if traffic_free use_backend enterprise if traffic_enterprise default_backend paidbackend internal balance roundrobin server internal-lb user-resource-service-internal:8080 resolvers dns check inter 2000backend canary balance roundrobin server canary-lb user-resource-service-canary:8080 resolvers dns check inter 2000 weight 5 server production-lb user-resource-service-production:8080 resolvers dns check inter 2000 weight 95backend paid balance roundrobin server canary-paid-lb user-resource-service-paid:8080 resolvers dns check inter 2000 weight 5 server production-lb user-resource-service-production:8080 resolvers dns check inter 2000 weight 95backend enterprise balance roundrobin server production-lb user-resource-service-production:8080 resolvers dns check inter 2000 weight 100Each HAProxy will inspect a header that gets assigned by our API-Gateway called X-Traffic-Group that determines which bucket of customers this request belongs to. Based on that, a decision is made to hit either a canary deployment or the production deployment.Obviously, at this scale, kubectl (while still our main day-to-day tool to work on the cluster) doesn’t really give us a good overview of whether everything is actually running as it’s supposed to and what is maybe over or under replicated.Since we do blue/green deployments, we sometimes forget to shut down the old version after the new one comes up, so some services might be running over replicated and finding these issues in a soup of 25 deployments listed in kubectl is not trivial, to say the least.So, having a container orchestrator like Kubernetes, that’s very API driven, was really a godsend for us, as it allowed us to write tools that take care of that.We built tools that either run directly off kubectl (eg bash-scripts) or interact directly with the API and understand our special architecture to give us a quick overview of the system. These tools were mostly built in Go using the client-go library.One of these tools is worth highlighting, as it’s basically our only way to really see service health at a glance. It goes through all our Kubernetes services that have the tier: service selector and checks if the accompanying HAProxy deployment is available and all pods are running with 4 replicas. It also checks if the 4 services behind the HAProxys (internal, free, others and production) have at least 2 endpoints running. If any of these conditions are not met, we immediately get a notification in Slack and by email.Managing this many pods with our previous orchestrator proved very unreliable and the overlay network frequently caused issues. Not so with Kubernetes – even doubling our current workload for test purposes worked flawlessly and in general, the cluster has been working like clockwork ever since we installed it.Another advantage of switching over to Kubernetes was the availability of the kubernetes resource specifications, in addition to the API (which we used to write some internal tools for deployment). This enabled us to have a Git repo with all our Kubernetes specifications, where each track is generated off a common template and only contains placeholders for variable things like the canary track and the names.All changes to the cluster have to go through tools that modify these resource specifications and get checked into git automatically so, whenever we see issues, we can debug what changes the infrastructure went through over time!To summarize this post – by migrating our infrastructure to Kubernetes, Bitmovin is able to have:Zero downtime deployments, allowing our customers to encode 24/7 without interruptionFast development to production cycles, enabling us to ship new features fasterMultiple levels of quality assurance and high confidence in production deploymentsUbiquitous abstractions across cloud architectures and on-premise deploymentsStable and reliable health-checking and scheduling of servicesCustom tooling around our infrastructure to check and validate the systemHistory of deployments (resource specifications in git + custom tooling)We want to thank the Kubernetes community for the incredible job they have done with the project. The velocity at which the project moves is just breathtaking! Maintaining such a high level of quality and robustness in such a diverse environment is really astonishing. –Daniel Hoelbling-Inzko, Infrastructure Architect, BitmovinPost questions (or answer questions) on Stack OverflowJoin the community portal for advocates on K8sPortGet involved with the Kubernetes project on GitHubFollow us on Twitter @Kubernetesio for latest updatesConnect with the community on SlackDownload Kubernetes
Quelle: kubernetes