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:
- 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).
- 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.
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:
- 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).
- 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.