1. Cf-Dev
  2. Topics

After Summit questions

ross.kovelman@...
 

Hi all,
After the first day of the summit, while very interesting, it left me and my teammates with a question. With no Bosh, since Bosh is for VMs, how will patching be done, especially when you use CF on a service like Fargate?

Thanks in advance for any answers you might have.
Krannich, Bernd
 

Hi Ross,

 

I haven’t tried Fargate myself (and I don’t know if this has been tried/is supported for CF on Kubernetes), but running CF on top of Kubernetes, “patching” might refer to two separate layers:

 

  1. Patching the Cloud Foundry “software” itself: Similar to cf-deployment, what you’ll get with both kubecf and cf-for-k8s is new versions of Cloud Foundry. Primarily, these are container images containing the “new bits” (plus some declarative way [like plain YAML files, Helm templates, kapp templates, depending on your distro] describing to Kubernetes how these container images will be run exactly). These “new bits” are essentially the combination of what used to be the BOSH stemcell and the BOSH releases packaged on top. In order to either update the OS distribution CF is using in its container images or to update the version of components, new container images will need to be built/provided and rolled out to your Kubernetes cluster (both kubecf as well as cf-for-k8s provide ways to do this with kubecf being more close to what people are used to from the BOSH world).
  2. Patching the host OS the Kubernetes nodes are running on: If you are using a managed Kubernetes offering, your Kubernetes provider will have some means to ensure that your Kubernetes node host OS can be kept up-to-date (I believe in Fargate this process is even more hidden from you because AFAIK Fargate doesn’t even make the concept of separate hosts visible to users, but I might be wrong here). Likewise, if you deploy and manage the Kubernetes cluster yourself, you’ll need to ensure that the OS your Kubernetes nodes (and the Kubernetes control plane which in managed offerings is something your provider takes care of) are running on is kept up-to-date. This type of patching is outside the realm of Cloud Foundry itself (whereas in a BOSH world where CF jobs were running on the VM itself, as opposed to “inside containers on a VM”, BOSH did indeed take care of that part [but then also there wasn’t the task to keep the container OS distro up-to-date – see #1]).

 

Hope this helps more than it creates confusion. I realize things have gotten more complex on this front and probably what I wrote can be explained in a more accessible way (my bad). 😉

 

Regards,

Bernd

 

From: <cf-dev@...> on behalf of "ross.kovelman via lists.cloudfoundry.org" <ross.kovelman=merck.com@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Thursday, 25. June 2020 at 03:45
To: "cf-dev@..." <cf-dev@...>
Subject: [cf-dev] After Summit questions

 

Hi all,
After the first day of the summit, while very interesting, it left me and my teammates with a question. With no Bosh, since Bosh is for VMs, how will patching be done, especially when you use CF on a service like Fargate?

Thanks in advance for any answers you might have.
Stephen Levine <slevine@...>
 

>  in a BOSH world where CF jobs were running on the VM itself, as opposed to “inside containers on a VM”, BOSH did indeed take care of that part [but then also there wasn’t the task to keep the container OS distro up-to-date – see #1]

In a way, BOSH did handle patching the container base images. When deploying a new CF rootfs (e.g., cflinuxfs3), rolling the BOSH VMs would update the container base images for every app with security patches. New cell VMs would come up with a patched version of cflinuxfs3, then old ones would go down.

For CF4K8s, this will be handled by kpack, which uses CNB (buildpacks.io) image rebasing functionality to swap the bottom OS layers of the deployed container images directly on the registry.
This results in the new container base images being distributed to each K8s node exactly once per base image update, after the first rebased image is deployed.
Then all the other images deployed on the node will "snap around" to point at the newly available base.
(This is a safe operation, because ABI compatibility is preserved when security patches are applied to the new base images -- just like in the CF model.)

From: cf-dev@... <cf-dev@...> on behalf of Krannich, Bernd <bernd.krannich@...>
Sent: Thursday, June 25, 2020 2:57 AM
To: cf-dev@... <cf-dev@...>
Subject: Re: [cf-dev] After Summit questions
 

Hi Ross,

 

I haven’t tried Fargate myself (and I don’t know if this has been tried/is supported for CF on Kubernetes), but running CF on top of Kubernetes, “patching” might refer to two separate layers:

 

  1. Patching the Cloud Foundry “software” itself: Similar to cf-deployment, what you’ll get with both kubecf and cf-for-k8s is new versions of Cloud Foundry. Primarily, these are container images containing the “new bits” (plus some declarative way [like plain YAML files, Helm templates, kapp templates, depending on your distro] describing to Kubernetes how these container images will be run exactly). These “new bits” are essentially the combination of what used to be the BOSH stemcell and the BOSH releases packaged on top. In order to either update the OS distribution CF is using in its container images or to update the version of components, new container images will need to be built/provided and rolled out to your Kubernetes cluster (both kubecf as well as cf-for-k8s provide ways to do this with kubecf being more close to what people are used to from the BOSH world).
  2. Patching the host OS the Kubernetes nodes are running on: If you are using a managed Kubernetes offering, your Kubernetes provider will have some means to ensure that your Kubernetes node host OS can be kept up-to-date (I believe in Fargate this process is even more hidden from you because AFAIK Fargate doesn’t even make the concept of separate hosts visible to users, but I might be wrong here). Likewise, if you deploy and manage the Kubernetes cluster yourself, you’ll need to ensure that the OS your Kubernetes nodes (and the Kubernetes control plane which in managed offerings is something your provider takes care of) are running on is kept up-to-date. This type of patching is outside the realm of Cloud Foundry itself (whereas in a BOSH world where CF jobs were running on the VM itself, as opposed to “inside containers on a VM”, BOSH did indeed take care of that part [but then also there wasn’t the task to keep the container OS distro up-to-date – see #1]).

 

Hope this helps more than it creates confusion. I realize things have gotten more complex on this front and probably what I wrote can be explained in a more accessible way (my bad). 😉

 

Regards,

Bernd

 

From: <cf-dev@...> on behalf of "ross.kovelman via lists.cloudfoundry.org" <ross.kovelman=merck.com@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Thursday, 25. June 2020 at 03:45
To: "cf-dev@..." <cf-dev@...>
Subject: [cf-dev] After Summit questions

 

Hi all,
After the first day of the summit, while very interesting, it left me and my teammates with a question. With no Bosh, since Bosh is for VMs, how will patching be done, especially when you use CF on a service like Fargate?

Thanks in advance for any answers you might have.

1 - 3 of 3