vSphere Kubernetes Service for Platform Engineers – What You Didn’t Know with VMware by Broadcom

So we'll get into a little bit in three parts about what makes the VCF stack a great place for Kubernetes. Um, first we're gonna go into our Kubernetes service, and I'll cover that here in the following presentation, especially if you're watching us on YouTube. We're gonna review applications being deployed into our environment.

And then the following section, we're gonna talk about how our cloud model, and it best enables your workloads and Kubernetes workloads in our stack here. And so, yes, we are at KubeCon. So what we are doing today is we are focusing on the VCF Cloud and how the VCF Cloud actually delivers Kubernetes.

I want to get a few things out of the way here. First of all, for all things Kubernetes, when you're dealing with VMware by Broadcom for all things Kubernetes, those things all live now in the VCF division, right? And what I mean by that is the way you would deploy Kubernetes clusters, the way you would manage Kubernetes clusters at scale and the way you're gonna operate, those are all a part of our VCF Cloud, right?

When we're thinking about VCF Cloud, what we're talking about doing is we're thinking about delivering a cloud in your data center for your, for our end users. Now, delivering a cloud in your data center has a couple of different changes when you compare, like what's gonna happen, uh, in your environment versus what you do when you go to hyperscaler, right? And really that's because there are a couple different personas in that, in that are playing out here.

There's that persona who's in charge of building and managing the cloud, and then they're the actual users, the people who want to use your cloud, right? And so we have to think about all of those things. Now, luckily, we have a really good head start being VMware.

We've got a great bit of networking, a great bit of storage, and our industry standard virtualization platform that make up that base layer of our stack. Now, we can deploy this in many different areas, including throughout our partners, um, and at the edge, uh, in telco spaces and in your on-prem data centers, right? And functionally, we take that compute, storage and networking and via constructs in our stack, which we'll get into here in a little bit.

We'll take those things and we'll actually leverage the underlying VMware infrastructure, the underlying VCF infrastructure to provide these additional services. So up top, you're gonna see Kubernetes virtual machines. We have a container service that I'm sure Jeremy's gonna talk about in session three today.

And we have many other services that actually help you deliver your applications here. Networking services, storage services, those sorts of things. So let's talk a little bit more about how the cloud admin enables the platform engineer to deliver Kubernetes and what VKS actually is.

So, VKS is fully conformant certified Kubernetes delivered in your data center. And I wanna pause there and, and, and think about what we mean when we say fully conformant certified Kubernetes. Okay?

What this means is we're delivering you in your data center the ability to deploy Kubernetes clusters that will functionally equip you to run any application that's suitable for Kubernetes. Why is that important? Well, that's important because you may have applications that are running in other, in other clouds somewhere else, right?

You wanna take that application, you wanna make sure that application will run in your data center. So by, so by delivering you fully conformant certified Kubernetes, you can be assured that if your app is running in maybe a public cloud provider somewhere, or maybe in other, in some other Kubernetes distribution, that it will run on VKS in your stack. Now, you'll notice in this, in this eye chart here, I've got a couple of Kubernetes clusters here, and that's great.

What we actually get the ability to do with a couple of Kubernetes clusters here, right, is we're showing you that it's not just one Kubernetes cluster in your environment. This is a Kubernetes service. We deliver multiple Kubernetes clusters.

When a user requests a Kubernetes cluster, they can get one out of your VCF infrastructure, right? These are all deeply integrated into the VCF substrate. And what I mean by that is, like all of the Cs that usually go into Kubernetes cluster, C-S-I-C-N-I-C-P-I, those sorts of things, those are all covered and integrated deeply within our stack.

So that when it comes to maybe a user kicking off an upgrade of their Kubernetes cluster, that the dependencies are just managed for you, right? You're not worried about, oh, is this version of that applicable with that part of my infrastructure? No, this is just managed for you as part of your VCF, uh, deployment, and we seamlessly integrate with GPU storage and the rest of our compute stack.

You'll see that we rapidly deliver vSphere Kubernetes releases VKR or vSphere. Kubernetes release is our way of conceptualizing what might be an operating system for a Kubernetes node and a version of a Kubernetes minor, right? We release vks typically within two months of when the upstream community drops a new version of Kubernetes, right?

5, and I think that's right, about two months after the Kubernetes community launched this. Now, the reason why, yeah, go ahead. Um, Go.

I'm my, uh, guy Courier Futureum group. My mind is like, like maybe unhelpfully focused on service. Mm-hmm.

Because, um, we got a lot of Ks that are ps and here we got a K that's an S. So you have the blank KP and the blank Ks, that that's a service versus platform uhhuh, right? So Nutanix has their NKP.

It used to be called NKS used to, before that it was called DKS um, Y service. I have an answer in my head that I like, but, but why call it a service instead of a platform, or, Well, this is a Kubernetes service that runs on our cloud, and our cloud has all kinds of things built into it. That might actually be the things that you would consider that make up a platform.

Examples in the VCF Cloud, you can run, we, we have the ability to do network isolation. We have the ability to provide you, uh, coming in a, in a future release here, um, object storage for your, for your, for your use cases. We have the ability to bring you data services, manage databases in our cloud.

We have the ability to simply run a container in our cloud as a service, right? We have the ability to provide you virtual machines. Obviously, if we're not doing that, we're not doing well.

But we have the ability to provide you virtual machines in your cloud as a service as well. These are some of the base level components that we feel that you're gonna have to add onto with other things to really build a platform experience. Now, here's the thing about platform.

What we've found and what we think, what we think is happening here is we're, we feel that, like when people are using our VKS service, what they've told us is they said, Hey, you know, it would be great if you just had a Kubernetes substrate that my apps can run on. We have big opinions about the CI part of our process, and in a lot of cases, people have told us we have big opinions about CD in our stack as well, right? And so our goal is to provide a platform that can interact best with those sorts of capabilities.

And so when we say service, I want you to think of something that is based on industry standard technology that enables you to leverage that capability. And then the second part that I want you to understand is that when we're thinking about actually leveraging this service, you can bring different components to bear on that stack, and we will manage that service for you through its lifecycle, both bringing new versions of Kubernetes and helping you upgrade your app, as well as managing dependencies of things running in those Kubernetes, uh, in that Kubernetes infrastructure. So is your view that there's a broad platform engineering paradigm, or there's a broad, uh, operational paradigm?

I think VMware used to call it SDDC or something along those lines. And this is a, uh, an element, maybe a critical element mm-hmm. In that overall infrastructure capability that you are, I I would, that you would reserve for the platform name?

Yeah. Yeah, I would say so. And good.

I think we break that up into a couple of key services, maybe like core services. Let's think of it this way. One is our VM service.

You can build on top of that. Yeah. The other is our container service.

Um, we have a, we have this thing called vSphere pods that will just allow you to run a container. And then we have our Kubernetes service. We feel that most applications can be platformed in one way or another on those things, right?

And we may work with partners on each of these areas to platform those applications accordingly. That's how we're thinking about this. But with regards to the service, we're going to manage the lifecycle of those.

We're gonna help you operate those, and we're gonna have, we're gonna help you deploy those at scale across the globe in your VCF deployments. And that's our view of why we wanna call it a service. And is the VCF component, um, the VCS, does VCF only offer as a cloud now As a cloud?

Yeah. 'cause you said that the VKS is a service that runs on VCF Cloud. So on the VCF Cloud, VCF is a cloud, it's in your data center.

Yep. So we're looking to be, we, we are looking to be in your data center, helping you where your workloads are in those data centers. Now, we certainly also leverage, uh, partners like right?

We have this vast network of, uh, cloud service providers that will help you run VCF as well. So if you're looking for an experience across multiple areas with the same Kubernetes experience, because that's built into the box, you can leverage, you can leverage your relationships with your, with our CSP partners to do that. I just wanted to be clear.

So VCF cloud is just V is VCF, it's, uh, yeah, it's VMware Cloud Foundation. Uh, and it's, it's, it's the cloud in your data center. This might be a Net, and I'm not sure if it's a smart question or not, but the word conformance came up mm-hmm.

With ai. So when you say conformant, are you talking about CNCF conformance for Kubernetes? We are Or certified?

Yeah. We are certified Kubernetes. And certified Kubernetes means that we pass the upstream Kubernetes conformance tests.

Okay. Alright. Okay.

Yeah. Got it. And, and so like most vendors will tell you, we are certified Kubernetes.

We heard that you talked about the AI thing a little bit earlier today. The new AI conformance, uh, thing that the CNCF has brought forward that the community has brought forward, we're happy to be a part of that. We're one of the launch partners for that.

Okay. So like, so again, we want this to be a Kubernetes stack that supports your workloads. We don't necessarily have an opinion about what workloads should run there, but we wanna make sure that this is aligned with what the community is delivering so that you can, so that these workloads are successful on our cloud.

So Is, I'm trying to grok this. So the VCM VMware Cloud Foundation, is that the underpinning for everything that VMware offers? Is it built on Cloud Foundry?

Is it VMware Cloud tan, Zu related Tan? It's unrelated to tan. Zu Tansu is something that could run on top of PCF VMware Cloud Foundation or VCF is, is a set of a, a set of previously built components mm-hmm.

That we have now put together one offering and one thing that we can deploy to give you cloud services, right? And that includes the VCF includes our hypervisor, it includes our networking solution, it includes our storage solution. It includes all of all of the things that you would historically think about leveraging to automate and operate those things at scale.

And it, and most importantly, it ties all of those things together in one common lifecycle experience. So previously, these were separate components. And the reason we're starting to talk about this as VCF is because we've put a lot of effort into making it one seamless experience to install everything that you need to get SDN to get your software defined storage, to get your, to get your hypervisor layer, to get all those things so that we can now have the conversation about leveraging services.

And those services are the VKS service, our container service, our, our VM service, our, our private AI services that we received. So Where would you draw the line for the platform? Or does it, does it move?

I, I mean, I think it depends on, you're Talking about platform engineering and what operations is gonna be focusing on to, to maintain and to orchestrate. Let's the, yeah, let's talk, let's talk a little bit about that. I think it, it can kind of move.

And the reason why it can kind of move, it really depends on what you mean by platform, I believe. Yeah. You mean by platform?

Yes. I know there's a set of our, there's a set of his, there's a set of engineers that are in charge of building the cloud substrate. These people are defining storage, policy, networking, VLANs like, uh, like the design of the compute infrastructure and taking those things and putting them into server cabinets or, uh, procuring that from a third party, right?

Those sorts of people when, or like, could be considered platform operators in some organizations because they may have that extra duty with, with managing Kubernetes infrastructure. In fact, that's what we found. We found that some organizations put the onus of maintaining the infrastructure or would like to put the onus of maintaining the infrastructure on the infrastructure team where they also have platform teams, right?

And so here's where it gets a little bit muddy. We need to build a system that allows platform teams to manage the sets of services that compose their applications, right? So there's a, there is a team that's responsible for building the cloud that ultimately gives you the spot where you're going to deploy your workloads in the cloud, But you're not building, uh, VCF 'cause it comes for you, right?

You're, you're deploying VCF right in your data center, right? And once it's deployed, you can then consume. And at that point, I would say there's a platform team that's responsible for helping you manage your Kubernetes infrastructure, uh, the VMs, the load balancers, the networking that makes up your applications, right?

Um, now that platform team probably only has access to a certain section of your infrastructure, or maybe you have separate platform teams for separate business units. What we've had to do is we've had to build a model that allows people to consume and manage our infrastructure in ways across those separate teams. And so, as you said, Tanzi would sit on top of this as would VKS and Tanzi would sit on top of this.

In fact, what, what Tansu does, if you're leveraging the, uh, if you're leveraging the tansu platform, it's leveraging Bosch to deploy VMs. And those VMs deployed on top of VCF. Um, if you're looking to deploy Kubernetes, our Kubernetes infrastructure, our VKS service deploys Kubernetes.

And that's all built on virtual machines just like any other cloud does, right? And, and that's all deployed on VCF, it's all isolated with our networking constructs. It can be stored using our SDN, uh, software defined storage, sorry.

Mm-hmm. Uh, vsan in our stack. Um, and from there, uh, and from there we have the ability to consume those things.

Okay. Uh, let's talk just a little bit more about, uh, the VKS stack specifically. 5, we shipped Kubernetes one point 34, and we did that within two months of the upstream community launching that, right?

Um, that's important because if you're, look, if you're leveraging another cloud provider out there, you're gonna have workloads that may need that version that's available in that cloud. We're launching around about with the same velocity that you're seeing from these other public cloud vendors out there. And so this aligns the VCF infrastructure to have that exact same sort of capability, uh, that exact same sort of Kubernetes capability.

34 in our stack will also come with 24 months of support, which is pretty nice. Uh, the Kubernetes community has a more limited support timeframe for a version of, for a version of Kubernetes. And so what we're doing is we're giving the applications that are running in your enterprise additional leeway on a version of, on a version of Kubernetes.

We've been told by our customers that upgrading, uh, is, is, is tricky enough in Kubernetes, and we need a certain amount of time on a, on a version of Kubernetes for our workloads. So we support now version one point 34 with 24 months of support, but it doesn't stop there. With this release, we're saying that every Kubernetes minor that ships in our stack will have 24 months of support moving forward.

So it's, so we'll give you the ability to make sure that your applications can appropriately be life cycled with that 24 month support period. Now, we also integrated Kubernetes multi cluster management directly into VCF in the stack. 5 timeline.

1 release. So if you're deploying a version of VCF, now, you will outta the box have, have Kubernetes enabled for you. You will outta the box have Kubernetes multi cluster management enabled for you to leverage as well.

5 a unified and our management, uh, system. Uh, you also heard about our Kubernetes AI conformance, uh, AI conformance, uh, news, uh, to at today's keynote, I believe. Um, and this is where our stack is in, in alignment and now certified for the new AI conformance requirements that, uh, that, that the Kubernetes community has Passed along.

And that includes the DRA. What does that include? The DA it, it does include DRA.

So D-R-A-D-R-A is supported, is supportable in our environment. Okay. And we're doing, we're doing further work.

Yeah. You have a other, you have a whole other implementation. We your manager, right?

Yeah, yeah, yeah. But now you support that as Well. Yes, we support, yes, we can support DRA as the Kubernetes stack.

Yep. Alright. So you mentioned we're rapidly delivering new Kubernetes versions.

This is kind of an eye chart, but the thing that I wanna point out for you is that we ship versions of VKS, okay? And every version of VKS is going to at least support n minus two versions of Kubernetes. Okay?

The thing that I want you to take away from this chart though, is that as you think about the version of Kubernetes you're going to run, there are things that need to be life cycled in the background, or there are things that platform administrators may lifecycle on your behalf in the background, right? So a platform administrator might update the version of VKS for you. You should know as a user of the VKS stack, you'll have 24 months of support on that version of Kubernetes that you're running.

Uh, past that, you may need to upgrade the version of Kubernetes that your application's running on. All of this is delivered via our content delivery system in our stack. Um, and all of this can be upgraded independently of the rest of the vSphere stack.

The rest of the VCF stack, I bring that up because you do not have to log in as a VMware administrator somewhere in your stack to update vCenter or something like that to get a new version of Kubernetes. We ship the, we ship the VKS versions independently of the VKS stack. And really the goal of doing this was to quickly deliver this new version of Kubernetes for everybody.

Alright? So we have a comprehensive set of packages that can be installed in VKS. We've got two sets.

We've got core packages, and those are at the bottom here. And the way I want you to think about core packages, these are the things that you functionally kind of need for a Kubernetes cluster to exist. You'll notice the networking stuff's in there, right?

Like you've got a, you've gotta have a networking plugin installed for a Kubernetes to be useful. You'll note that I've got some off stuff in there. You'll note that we've got things, uh, we've got things related to storage in our stack there.

These things are gonna be included and pre-installed and preen enabled on all of your, on all of your VKS releases. Okay? Then above that, we've got a set of standard packages.

Now, these are optional things that you could add to a VKS cluster to give you abilities. And you're gonna look through this list and you're gonna see a lot of things that you're like, oh, I recognize these CNCF things, right? And really, these are things that we feel that you need to add to a cluster to maybe gain additive value.

In many cases here, we've been asked by customers to say, Hey, you know, would you support a service mesh for us? Can you, can you give us a service message you support outta the box? So we said, sure, you know, as long as you're running VCF, you can run STO and you can run, you run that on our stack and we'll support it.

We'll support it down to the networking components in the stack. So your workloads have a service mesh to live, live with. Same, can you run VK VKS without VCF?

Can you run, uh, VKS without VCF? It is available in VVF, but there are some, there are, there, there are. It's, it's lesser.

And what I mean by that is you don't get multi cluster management. You don't get, for example, the Istio support in, in that stack. You get a very basic Kubernetes.

So if you have VVF, which is our lower, lower tiered skew, you get access to Kubernetes and you can leverage it, but you miss out on multi cluster management, you miss out on some of these packages and you miss out on what Jeremy's gonna talk about a little bit later, which is that cloud experience. Okay? So let's talk just a little bit about multi cluster management in our stack.

1, we've bundled in multi cluster management, and I think we're gonna actually get a peek at that in our next session. So if you actually like a demo of that, uh, jump over to that YouTube video. But when we think about the multi cluster management capabilities, we're thinking about fleet wide for the things that you have access to.

Now remember, I'm telling you that we're leveraging VKS in our cloud as a service, which means we give users access to leverage our cloud, and they can ven Kubernetes clusters or virtual machines or containers, networks, load balancers, whatever they need to deliver their application from our infrastructure set. The multi cluster management capability allows those users to manage the Kubernetes clusters that they have access to, right? So, so it allows folks to ultimately manage and, and, and lifecycle these compo, these clusters.

It allows them to manage and, and introspect the workloads running on these clusters. It allows them to manage security and compliance policy within these clusters. Leveraging open policy agent as a part of this.

Uh, it also allows, it also allows you to protect your data. And so we're using Valero under the covers today as a set of APIs for Kubernetes cluster data protection. And, uh, we are actually, uh, if you actually, if you run by the booth, you can catch a demo of what's coming in a future release, which is actually us backing up our clusters to our own object storage.

So Valera supports any object store on the backend. Um, we in a future release have announced that we're shipping, we're going to ship an object store. We have the ability to natively plug this up and, and give you a full end-to-end solution for data protection for your Kubernetes clusters.

That's really in alignment with, with what the community expects here. Is this is Calvin Hendricks. Parker, is this a standard part of VCF?

If you buy V-C-F-V-K-S comes as part of this package Comes with it, so does the multi cluster management. So does the 2024 month support for each of those versions of Kubernetes. So does basically all of these things that we've been talking about, these just bundled in to VCF also, those other things that I were talking about that make up the cloud, and Jeremy's gonna talk about this in in session three.

If you're watching the stream, you know, these are all components that make up the, uh, that will make up the cloud. So the, you know, the, the VM service, the, uh, vSphere pod service that allow you to run containers, the VKS service, the networking service, the load balancing service, this, the volume service, all of those things, they're all just included as a part of VCF. It's a big difference between a virtualization platform and a self-service cloud platform, which gives you access to all of these sorts of things.

And that's really the shift that we've made. We're, we're still relying on that vSphere infrastructure to provide world class best in class virtualization of all the things, your storage, your networking and compute. But what we're giving you on top of that is this set of services that we've never really provided before in a consumable fashion for your end users.

So do you get tan zu with it as Well? Tan zu is a different thing. And, and the reason why I, the reason why I had the disclaimer at the beginning, I'll go back to that.

All the Kubernetes stuff is a part of VCF Tan Zu has, tan Zu is about developers and delivering actual code, uh, to production. And they do that using a, a platform that's based on Cloud Foundry today. And but Doesn't it sit on top of VCF?

It can, it can totally sit on top of VCF, but It doesn't Have to. It does, it doesn't necessarily have to, right? We, we of course want it to sit on top of VCF as, as the VCF division, right?

Uh, and, and we're happy to, we're happy to run those workloads. Um, but you know that, that is not, uh, something that is included as a part of VCF out of the gates. Cool.

Alright. And then we have some simplified, uh, Kubernetes operations with integrated monitoring. We have the ability to show you what's running in your Kubernetes clusters, as well as how things are performing as a part of the stack.

And we wanna give you the ability to do those exact same things with your VKS clusters. And so we're gonna give you details into how workloads are performing, how control planes are performing, how, uh, how, um, how many, how many objects exist in the state of those objects all available in operations. Uh, then we have workflows for configuring these, uh, should your end users wanna get to these?

Now, that said, you might have said, but Timmy, I saw Prometheus and those sorts of thing things on an earlier slide. This isn't just an opinion of something that comes with our cloud out of the box. You get this, if you have a different set of tools for logging, for monitoring that are a part of your stack, you know, we're, we're not opinionated.

Bring your tools. Feel free to leverage your tools on our stack. Again, we're, uh, CNCF certified Kubernetes, right?

Which means any workload designed for Kubernetes is gonna run there. And with that, I'm almost out of time. Um, Can I get sneak a quick question in there?

You can, while I get my demo practice. Perfect. I just wanna show you, so If Tan Zus really targeted toward developers getting applications into production, what am I getting into production on BKS?

Well, so the time, well, they're targeted for delivering applications on, into production on top of Cloud Foundry, right? Like, and so there's, they're not coming From developers. Well, I mean, they could be for Yeah, sure, they could be from developers.

Yeah, but the, but the fact of the matter is there's workloads, they're just designed for Kubernetes today. They're developers that have their own sets of tools, right? Maybe they're running like their own development, their own development tooling.

They're leveraging something like harness to deliver things, right? Maybe talking more like something like, uh, if I want min io deployed with a helm chart, like this is a good, good place to do this If you want. Yeah.

You can absolutely deploy any helm chart on our, on our, on our clusters. We're no limits there. Yeah.

Okay. Or, or if your developer simply has a Kubernetes centric workflow, which many do for delivering their applications and they've already built that framework, we can host that for you here. And I just wanna give you a quick view of our, of our creation flow.

Here's our self-service portal that you're seeing access, and this is the quick way of doing it. You see that I have the services on the left and here I'm clicking create a new VKS cluster. This is the default configuration flow and functionally what we're getting, we're getting access and provisioning clusters to our project that we've been given access to.

You'll see I already have a Kubernetes cluster deployed here, and I just created a new one. 34. And that's really the standard flow for creating things.

We also have a flow that allows you to create workloads in a, in a, in a more custom way. And really that's what we're gonna show here. And the thing that I want you to take away from this is we can configure just about everything about our clusters under the scenes, under the covers here, we're leveraging upstream cluster, API.

And here we're defining a cluster class that cluster API, uh, can leverage. We're also defining what version of Kubernetes we ultimately wanna run. And as this goes along, I just wanna call your attention to the thing on the right hand side, which is Kubernetes Resource yaml.

Every object created in the VCF cloud is, is leveraging our API, which is declarative in nature. We'll get into that in session three a little bit more, but I want you to note that we're actually building that YAML that defines this cluster that we're building here as we click through this. So if you're someone who does not want to use a ui, you are someone you want to check in code to get repo somewhere that defines your Kubernetes cluster, you can do that and you can use Argo cd, which we provide to track that and actually manage your, your infrastructure's, code deployments, right?

Are there Terraform providers to do this too? So we're using Kubernetes custom resources. We absolutely have Terraform providers, but Terraform has a great Kubernetes yeah.

Provider. And as such, and I point that out, I answer the question this way because the point is like, just about everything understands how to deal with a Kubernetes custom resource. And everything in the VCF cloud is defined as a Kubernetes custom resource.

More in session three on that. Perfect. Right?

And so, uh, what you'll actually be able to see here, we're creating a node pool here. These are the worker nodes that we run in our environment. 04.

Shout out to Canonical, who's our new partner here. Uh, canonical is helping us deliver, uh, you know, the number one cloud operating system as the node OS is a part of our stack here, you'll see we're defining details about our node pool, including storage volumes. We're including labels, taints the basic things that you would, uh, leverage for Kubernetes.

Uh, and this is all done via, via the UI for you here. You click finished, you, we look at the node pools here, and we click next, which allows us to review and confirm and we finish. And the deployment goes again.

We can introspect the YAML on the right hand side. Uh, this YA ml's been updated with all of our selections. We click, uh, we click next and it deploys the cluster for you.

When I say deploys the cluster for you, what I mean is it deploys that cluster assuming you have a set of resources that your overall cloud admin has given you access to, right? So we are a user of the cloud and we have access to a set of resources there, and we'll get into that more a, a little bit later in the session.