Link: VMworld 2018: Pivotal Container Service and the Long Road to NoOps

[Swisscom’s] Massalt polled the audience, asking how many of them had experience with updating their Kubernetes clusters. No one, in a reasonably full ballroom, raised a hand.

“There’s a reason for this: because it’s a painful process,” he said. It’s why Swisscom had already adopted BOSH as an automated deployment tool for replacing old versions and updating the underlying platform, thus taking care of a large chunk of Day-2 operations.
Original source: VMworld 2018: Pivotal Container Service and the Long Road to NoOps

Link: VMworld 2018: VMware Wants to Re-Architect Your Containers for NSX – The New Stack

“The developer shouldn’t have to know how to program NSX, or know what the security isolation boundaries are,” continued Fazzone. “But they should know that their organization has taken steps to unify the networking approach between the containerized applications and the traditional applications running in VMs, and take advantage of that ‘service’ offered by IT to extend the NSX-T support up into their container platform, versus just defaulting to the Layer 2 default that’s available in the open source community — so that their organization can realize that complete connectivity model in a consistent way.”
Original source: VMworld 2018: VMware Wants to Re-Architect Your Containers for NSX – The New Stack

Link: Using VMware’s Harbor with PKS (and Why Kubernetes Needs a Container Registry)

“A container registry is the repository for all your container images. Since your core business applications are packaged into containers (built out of container images), you must protect these images just as you would any other important enterprise IT system. That’s where the image registry comes into play.”
Original source: Using VMware’s Harbor with PKS (and Why Kubernetes Needs a Container Registry)

Stateless apps in one, stateful apps in the other

It happens to be the case that CF — because it’s an app platform and wants to let the user focus on their code — provides a way to convert code in to containers inside the platform without having to start messing around with Dockerfiles and the like. And this functionality even does some cool things for you like keeping your container OS automatically patched so you don’t have to build CI pipelines to monitor your base images and rebuild stuff.

That’s why I love Cloud Foundry’s Application Runtime. Of course, because of these constraints — the constraints that are why I love it — the App Runtime can’t possibly work for complex stateful services: the whole point is for it not to. And that’s why it’s fantastic that there’s now a Container Runtime (which I wish we’d called a Stateful Services Runtime because that’s how I think of it).

Source: CF vs Kube: Is the difference who creates the container?

Bloomberg on kubernetes in Cloud Foundry

On overview of how Bloomberg is looking at the likes of Pivotal Container Services:

“Many Kubernetes distributions are good on day one, when they’re first deployed,” said Andrey Rybka, technical architect in the office of the CTO at Bloomberg, the global finance, media and tech company based in New York. “But what happens on day two, when something fails? Kubernetes doesn’t [automatically] address things like failures at the physical node level.”

And:

The roadmap for Cloud Foundry Container Runtime includes support for stateful applications based on the StatefulSets feature that became available with Kubernetes 1.7 in June. The foundation also plans to integrate the Istio project, founded by IBM, Google and Lyft in May, which helps to manage network communications between microservices

Also, see coverage of the general announcement in TechCrunch, the related press release, and our discussion in this week’s podcast.

Source: Cloud Foundry Container Runtime eases Kubernetes ops