Pages Navigation Menu

The blog of DataDiggers

Categories Navigation Menu

Google takes a step back from running the Kubernetes development infrastructure

Posted by on Aug 29, 2018 in alibaba, Cloud, cncf, computing, Developer, dns, Enterprise, Google, IBM, Kubernetes, Microsoft, oracle, sap, TC, vmware | 0 comments

Google today announced that it is providing the Cloud Native Computing Foundation (CNCF) with $9 million in Google Cloud credits to help further its work on the Kubernetes container orchestrator and that it is handing over operational control of the project to the community. These credits will be split over three years and are meant to cover the infrastructure costs of building, testing and distributing the Kubernetes software.

Why does this matter? Until now, Google hosted virtually all the cloud resources that supported the project, like its CI/CD testing infrastructure, container downloads and DNS services on its cloud. But Google is now taking a step back. With the Kubernetes community reaching a state of maturity, Google is transferring all of this to the community.

Between the testing infrastructure and hosting container downloads, the Kubernetes project regularly runs more than 150,000 containers on 5,000 virtual machines, so the cost of running these systems quickly adds up. The Kubernetes container registry has served almost 130 million downloads since the launch of the project.

It’s also worth noting that the CNCF now includes a wide range of members that typically compete with each other. We’re talking Alibaba Cloud, AWS, Microsoft Azure, Google Cloud, IBM Cloud, Oracle, SAP and VMware, for example. All of these profit from the work of the CNCF and the Kubernetes community. Google doesn’t say so outright, but it’s fair to assume that it wanted others to shoulder some of the burdens of running the Kubernetes infrastructure, too. Similarly, some of the members of the community surely didn’t want to be so closely tied to Google’s infrastructure, either.

“By sharing the operational responsibilities for Kubernetes with contributors to the project, we look forward to seeing the new ideas and efficiencies that all Kubernetes contributors bring to the project operations,” Google Kubernetes Engine product manager William Deniss writes in today’s announcement. He also notes that a number of Google’s will still be involved in running the Kubernetes infrastructure.

“Google’s significant financial donation to the Kubernetes community will help ensure that the project’s constant pace of innovation and broad adoption continue unabated,” said Dan Kohn, the executive director of the CNCF. “We’re thrilled to see Google Cloud transfer management of the Kubernetes testing and infrastructure projects into contributors’ hands — making the project not just open source, but openly managed, by an open community.”

It’s unclear whether the project plans to take some of the Google-hosted infrastructure and move it to another cloud, but it could definitely do so — and other cloud providers could step up and offer similar credits, too.


Source: The Tech Crunch

Read More

Docker aims to federate container management across clouds

Posted by on Jun 13, 2018 in Cloud, containers, devops, Docker, Enterprise, Kubernetes | 0 comments

When Docker burst on the scene in 2013, it brought the idea of containers to a broad audience. Since then Kubernetes has emerged as a way to orchestrate the delivery of those containerized apps, but Docker saw a gap that wasn’t being addressed beyond pure container deployment that they are trying to address with the next release of Docker Enterprise Edition. Docker made the announcement today at DockerCon in San Francisco.

Scott Johnston, chief product officer at Docker says that Docker Enterprise Edition’s new federated application management feature helps operations manage multiple clusters, whether those clusters are on premise, in the cloud or across different public cloud providers. This allows federated management of application wherever they live and supports managed Kubernetes tools from the big three public cloud providers including Azure AKS, AWS EKS and Google GKE.

Johnston says that deploying the containers is just the first part of the problem. There is a whole set of issues to deal with outside of Kubernetes (and other orchestration tools) once your application begins being deployed. “So, you know, you get portability of containers with the Docker format and the Kubernetes or Compose description files, but once you land on an environment, that environment has deployment scripts, security models, user management and [so forth]. So while the app is portable, the management of these applications is not,” he explained.

He says that can lead to a set of separate deployment tools creating a new level of complexity that using containers was supposed to eliminate. This is especially true when deploying across multiple clouds (and on prem sometimes too). If you need load balancing, security, testing and so forth — the kinds of tasks the operations team has to undertake — and you want to apply these in a consistent way regardless of the environment, Johnston says that Docker EE should help by creating a single place to manage across environments and achieve that cloud native goal of managing all your applications and data and infrastructure in a unified way.

In addition to the federated management component, Docker also announced Windows Server containers on Kubernetes for Docker Enterprise Edition. It had previously announced support for Linux containers last year.

Finally, the company is introducing a template-based approach to Docker deployment to enable people in the organization with a bit less technical sophistication to deploy from a guided graphical process instead of a command line interface.

The federated application management is available in Beta starting the second half of this year, support for Windows Server Containers will be included in the next release of Docker Enterprise Edition later this year and Templates will be available in Docker Desktop in Beta later this year.


Source: The Tech Crunch

Read More

Helm moves out of Kubernetes’ shadow to become stand-alone project

Posted by on Jun 1, 2018 in cloud native computing foundation, Developer, Enterprise, Kubernetes, open source | 0 comments

Helm is an open source project that enables developers to create packages of containerized apps to make installation much simpler. Up until now, it was a sub-project of Kubernetes, the popular container orchestration tool, but as of today it is a stand-alone project.

Both Kubernetes and Helm are projects managed by the Cloud Native Computing Foundation (CNCF). The CNCF’s Technical Oversight Committee approved the project earlier this week. Dan Kohn, executive director at the CNCF says the two projects are closely aligned so it made sense for Helm to be a sub-project up until now.

“What’s nice about Helm is that it’s just an application on top of Kubernetes. Kubernetes is an API and Helm accesses that API. If you want you to install this [package], you access the Kubernetes API, and it pulls this many containers and pods and [it handles] all of the steps involved to do that,” Kohn explained.

This ability to package up a set of requirements allows you to repeat the installation process in a consistent way. “Helm addresses a common user need of deploying applications to Kubernetes by making their configurations reusable,” Brian Grant, principal engineer at Google and Kubernetes (and a member of the TOC) explained in a statement.

Packages are known as “charts,” which consist one or more containers. Kohn says for example, you might want to deploy a chart that includes WordPress and MariaDB in a single container. By creating a chart, it defines the installation process and which pieces need to go in which order to install correctly across a cluster.

Kohn said they decided to pull it out as a separate program because it doesn’t always follow the Kubernetes release schedule, and as such they wanted to make it stand-alone so it wouldn’t necessarily have to be linked to every Kubernetes release.

It also allows developers to benefit from the community, who could build Charts for common installation scenarios. “By joining CNCF, we’ll benefit from the input and participation of the community, and conversely Kubernetes will benefit when a community of developers provides a vast repository of ready-made charts for running workloads on Kubernetes,” Matt Butcher, co-creator of Helm and principal engineer at Microsoft said in a statement.

Besides Microsoft and Google, other project sponsors include Codefresh, Bitnami, Ticketmaster and Codecentric. The project website states there are currently 250 developers contributing to this project. By becoming part of CNCF that will very likely increase soon.


Source: The Tech Crunch

Read More

Red Hat acquires CoreOS for $250 million in Kubernetes expansion

Posted by on Jan 30, 2018 in Cloud, cloud native, containers, coreos, Enterprise, Fundings & Exits, hybrid cloud, Kubernetes, M&A, open source, red hat, TC | 0 comments

 Red Hat, a company best known for its enterprise Linux products, has been making a big play for Kubernetes and containerization in recent years with its OpenShift Kubernetes product. Today the company decided to expand on that by acquiring CoreOS, a container management startup, for $250 million. Read More
Source: The Tech Crunch

Read More