#39 February 5, 2019

Minikube, with Dan Lorenc

Hosts: Craig Box, Adam Glick

Minikube is a tool that makes it easy to run Kubernetes locally, by running a single-node Kubernetes cluster inside a VM on your desktop or laptop. Craig and Adam talk to author and maintainer Dan Lorenc from Google Cloud, and in the wake of the Super Bowl, discuss how “football” means something different to each of them.

Do you have something cool to share? Some questions? Let us know:

Chatter of the week

News of the week

ADAM GLICK: Hi, and welcome to the Kubernetes Podcast from Google. I'm Adam Glick.

CRAIG BOX: And I'm Craig Box.


ADAM GLICK: Did you watch any football this week?

CRAIG BOX: I did, actually. I watched a small amount of the France versus Wales game. And it just seemed such a lost cause at halftime. And then there was a turnaround in the second half. And I hear the Super Bowl might have been similar.

ADAM GLICK: Yes, yes. For those who think football is something the rest of the world might call American football.

CRAIG BOX: I like to call it "hand egg".


ADAM GLICK: Well, for the rest of folks who may not know exactly what that is, that did go on this past weekend. It was an interesting game where actually most of the points, as far as I know, for the first time, were actually scored by kicking the ball as opposed to throwing or catching the ball. So chalk that up to another one of the interesting tidbits in what, otherwise, was a fairly low-scoring and mostly defense-focused game.

CRAIG BOX: I might be surprised if it was a basketball game. Are you allowed points off the feet in basketball?

ADAM GLICK: I have no idea. I would guess, technically, yes.


ADAM GLICK: But I have no idea.

CRAIG BOX: No. I want to see Lebron try that. I want to see like knee-juggling, keepy-uppy.

ADAM GLICK: You know, I don't know that there's a rule against it. But I am also not the rules lawyer for the NBA.

CRAIG BOX: Well, the Super Bowl, I believe, was on the BBC, obviously, when I was asleep. But most people only watch it for the ads. And we probably didn't get any of those on the BBC. Were there any notable un-game-related moments?

ADAM GLICK: You know, people pay, I believe, it's around $5 million for a 30-second spot, so a tremendous amount of money gets paid. And there were certainly a lot of interesting ads. Yeah, everyone has their favorites.

CRAIG BOX: What were yours?

ADAM GLICK: Well, while I'll not chime in with my particular favorites. I thought that there were some really interesting ones. And it was clear that there's a lot of recognition this year around focus on equality, both in society, and in the game. And that was nice to see.

CRAIG BOX: But not a lot of recognition for SpongeBob SquarePants.

ADAM GLICK: Oh, you're going to bring that up. I see. Well, that's, you know--

CRAIG BOX: I'm well informed, my friend.

ADAM GLICK: As someone put it, at halftime, you had Maroon 5, but the Patriots 3. [MAKES DRUM STING SOUND] The ads are available online. I always usually go afterwards to see which ones were most interesting, just up on YouTube, flipping through them.

CRAIG BOX: But is there one everyone's talking about the next day?

ADAM GLICK: Given that we've had a snowstorm here in Seattle and actually everyone is snowed in, I don't know what ad people are talking about, at least, in the office.

CRAIG BOX: Do you get the newspaper? Do you still have someone pop by and throw a piece of parchment through your window?

ADAM GLICK: Dirty marks on shredded trees? I'm so beyond that. I do read online, of course. And there's lots of interesting pieces. But, yeah. One of our newspapers here, we had two close down a couple of years ago or so. And yeah, the other news bits are easier to get digitally.

CRAIG BOX: Isn't Jeff Bezos buying them all and saving them?

ADAM GLICK: Did you see his cameo during the game?

CRAIG BOX: I did not.

ADAM GLICK: He was, I think, unintentionally, on camera in one of the scenes-- that they had a shot of the NFL Commissioner who would eventually give away the Vince Lombardi trophy, which the team that wins the Super Bowl gets. And if you looked, the guy walking past him in front of him was Jeff Bezos. And you're like, oh.

CRAIG BOX: Are you sure it just wasn't a random bald man, and you just-- you think all random bald men look the same?

ADAM GLICK: You know, it is possible. But I'm pretty sure that was Jeff Bezos. I don't know.


ADAM GLICK: Someone on Twitter must have commented, right?

CRAIG BOX: This is the Adam checks Twitter break.

ADAM GLICK: Yeah, that's exactly-- wow, Jeff Bezos yanked a $20 million Super Bowl ad for Blue Origin.

CRAIG BOX: However, Jeff Bezos probably earns more than $20 million per five minutes or whatever the rate is for spending money on Super Bowl. Do we reckon Jeff Bezos earns money quicker than that?

ADAM GLICK: Oh, given that I think he is the wealthiest individual in the world at the moment, I think the answer is possibly. Here is one thing that I do-- when you talk about newspapers, one of the things I truly love is that England is not beyond the gossip newspaper in any way, shape, or form.

CRAIG BOX: Oh, not at all. They practically invented it.

ADAM GLICK: And so when I searched for this, where do I find it? Do I find it in a good, solid US publication? Do I find it in his own "Washington Post," crowing about their owner? No, no, no.

CRAIG BOX: It's going to be "The Daily Mail," isn't it?

ADAM GLICK: It is "The Daily Mail," indeed.

CRAIG BOX: We apologize on behalf of that it's not news.

ADAM GLICK: So yes, there is a link from "The Daily Mail" that has a screen capture. And indeed, that is Mr. Bezos hobnobbing with the league management.

CRAIG BOX: According to "Business Insider," which is, maybe one or two steps above "The Daily Mail"-- it's hard to tell exactly-- Jeff Bezos is making $231,000 per minute, which, unfortunately, means that he won't be able to afford to buy all of the ads in the Super Bowl with only the money that he makes during the time those ads air.

ADAM GLICK: We will all weep a small little tear and hope that next year maybe things will be different. Let's get to the news.

CRAIG BOX: Let's get to the news.


ADAM GLICK: Google Cloud has announced that a Kubernetes operator for Apache Spark is now available on beta. Spark is a popular data analytics engine. With the Spark operator, you can create a declarative specification that describes your spark applications and uses native Kubernetes tooling such as kubectl to manage your applications. The operator is a custom controller that offers fine-grained lifecycle management of Spark applications, including support for automatic restart using a configurable restart policy and for running Cron-based scheduled applications.

As a result, you now have a common control plane for container and batch applications on Kubernetes, simplifying management and improving your cluster's resource utilization. You can download the operator from GitHub and install it on your own cluster. Or it's available as a one-click install into a GKE cluster from the GCP Marketplace for Kubernetes. In related news, IBM has been retooling its cloud databases product on top of Kubernetes and has written a blog post on their experience with managing stateful distributed systems using the operator pattern.

CRAIG BOX: The CNCF has, this week, announced six new members into its technical oversight committee. The group is responsible for admitting projects into the CNCF as well as setting the foundation's technical vision. Selected members include the returning chair, Alexis Richardson from Weaveworks, and five new members; Kubernetes elders Brendan Burns and Joe Beda, now at Microsoft and VMware respectively; Envoy author Matt Klein from Lyft; Xiang Li from Alibaba; and Kelsey Hightower from Google.

Jeff Brewer from Intuit was selected as the end-user representative. The process has come under community criticism for vendor heaviness and producing an all-male roster. CNCF Chief Operating Officer, Chris Aniszczyk suggests the committee is aware of the issue and discussion is underway on how to rectify it when the next seat comes up for selection in March.

ADAM GLICK: Google Cloud launched a beta of their usage metering for Google Kubernetes engine. Usage metering allows you to see your project's resource usage broken down by Kubernetes name spaces and labels then attributes those to meaningful entities like department, customer, application, or environment.

This enables approximating cost breakdowns for teams that are sharing a cluster, understanding the usage patterns of individual applications, helping cluster admins triage spikes in usage, and providing better capacity planning and budgeting. SaaS providers can also use it to estimate the cost of serving each customer. Data is made available for querying in Google Cloud's BigQuery data warehouse or it can be exported to another tool of your choice.

CRAIG BOX: Part two of the "Istio" blog series from Google Cloud has developer programs engineer Megan O'Keefe talking application deployment and traffic management. The tutorial covers monitoring and metrics, tracing, and traffic routing, and comes with a sample to walk through on GitHub.

Between her blog posts on Istio, Megan has also found time to write up some of the command line tools that she uses to manage Kubernetes on her desktop. If you've heard of kubectx, Krew with a K, and Skaffold, but don't know how they fit together, Megan's post will serve as a welcome introduction.

ADAM GLICK: Ambassador, a Kubernetes-native, API gateway built on the Envoy Proxy has released a version they are calling both generally available and 0.5, which somewhat undercuts that implication. New features include SNI support for hosting multiple domains with a single Ambassador incidence, HMAC authentication, and dynamic rate limits.

If you want to pontificate on API gateways versus service meshes, you could do worse than to read Christian Posta's recent post on how API gateways are going through an identity crisis. We wish them well and hope they find out who they are soon.

CRAIG BOX: Love for the Kubernetes API resource model, but just can't go for go? Justin Cormack from Docker is interested in the second implementation of the Kubernetes API machinery and has suggested Rust as a practical language to do this in. If you get it done before KubeCon in Barcelona, you might even get a prize. Check out Justin's blog post to learn more.

ADAM GLICK: And that's the news.


Dan Lorenc is a software engineer with Google that helped create and maintains Minikube. He leads a team now that is responsible for other Kubernetes development tools like Skaffold, Kaniko, and Knative. Welcome to the show, Dan.

DAN LORENC: Thanks for having me, Adam.

CRAIG BOX: Let's start by talking about the history of Minikube. When was it created, and what was the state of the tooling at the time?

DAN LORENC: We started the Minikube project back in 2015. That was pretty early days for Kubernetes. And there was no easy or officially supported way to get a cluster running locally, which was making it hard for people to adopt. People were having trouble understanding the concepts and value of Kubernetes without an easy way to get it started on their laptops. With the existing tooling, like all good projects at the time, it was basically written in Bash.

It worked for the people that needed it to, but it was hard to debug, maintain, and extend. There were a few other groups that were starting to tackle this same problem. I want to give a big shout out to Redspread, as well, which helped us get Minikube started. They were later acquired by CoreOS. But they helped us with the initial versions of Minikube and helped us get an official project started in the Kubernetes organization so everybody looking at this problem could collaborate in one place.

CRAIG BOX: People who were looking to run Docker at the time, I guess, the state of the art then was boot2docker or something, command-line tooling.

DAN LORENC: Yeah. I think the new Docker desktop app was just starting to come out around that time. But I think most people, including myself, were still on the old boot2docker setup.

CRAIG BOX: And if you had wanted to run just on top of that, what would you have had to do instead?

DAN LORENC: Kubernetes had a pretty hard time running inside of Docker back then. It still does. Containers inside of other containers are fraught with problems. There are a few documented setups for that which had a long list of incompatibilities, things like volume mounting on the host didn't work-- basically, a long list of things we didn't know we didn't know at the time.

CRAIG BOX: What was the reaction when it was launched?

DAN LORENC: Really positive. People were super helpful, tried it out immediately. It really opened my eyes to how active, knowledgeable, and helpful the Kubernetes ecosystem was. This was my first real foray into working on Kubernetes, and it was an awesome experience.

ADAM GLICK: Had you worked on open-source projects before?

DAN LORENC: Small sending patches to things. But this is the first open-source project that I became a full-time maintainer on.

CRAIG BOX: How is Minikube implemented?

DAN LORENC: So one of the challenges to running Kubernetes on a laptop is that Kubernetes requires a pretty specific Linux distribution, a very recent kernel version, and a complex set of dependencies. Most people don't happen to have that on their desktop. So Minikube bundles a virtual machine and manages the life cycle of that so that everybody has the same exact set of dependencies that's been tested with each Kubernetes release.

ADAM GLICK: What VM environment do people need to be running in order to be able to take advantage of that?

DAN LORENC: This is a pluggable feature of Minikube. So across the different laptop environments like Windows, Mac, and Linux, we support a different set of these. The lowest common denominator, the one we support across all of them, is VirtualBox. So if you have that installed, Minikube will integrate.

Minikube also has some integrations for better platform-specific hypervisors if you happen to be on one of those platforms and can work with those. On Windows, we support Hyper-V. On Linux, there's a KVM integration. And on OSX, there's a HyperKit integration. Those provide a more native feel if you're on one of those environments.

CRAIG BOX: Does Minikube have a user interface aside from its command-line tooling?

DAN LORENC: No, it doesn't. There are a few products out there that provide one for starting and stopping the virtual machine. But this isn't bundled into the Minikube project itself.

ADAM GLICK: When you look at getting started with Kubernetes, obviously, there are a number of different ways that people can do it. Spin up a cloud cluster. Go through Kelsey Hightower's very interesting guide on Kubernetes the hard way, Minikube. Is this something you view as something for people to get started, for someone to use as a sandbox environment? How do you picture people using this? And how do you hear that people are using it?

DAN LORENC: Yeah. So early on, we used to go with Minikube for two main use cases and user journeys. Kubernetes was still really young at the time. So our first target was people trying to get started with Kubernetes. The easiest way to do this without Minikube at the time was to spin up a cluster on some cloud provider. But those all cost money and require a credit card. That's a big hurdle or commitment if you're not even sure you want to use Kubernetes.

The second big goal was for people that already were working on applications targeting Kubernetes. There weren't as many of them back then, but now that number is growing a lot. Fast iteration speed is key to local development. And a cluster on your laptop is one way to achieve that, particularly, if you're on some kind of slow network or working on a project that's large and has a whole bunch of bits that you have to push back and forth from the cloud. More recently, we do see people taking Minikube and using it in a whole bunch of other ways. But those are the main two that we focused on.

ADAM GLICK: What are the ways that you're seeing people starting to use it? You're hinting at something there.

DAN LORENC: Yeah. One of the big surprises that we've seen, and I think we do actually want to start to support and get better at, is people using Minikube inside of CI environments. So if you've got a Travis CI job or something, and you just want to validate that your YAMLs work and deploy or run some basic end-to-end tests, you run into those same container-in-container or VM-in-VM problems we talked about before. So people want to have an easy way to spin up a Kubernetes cluster, run some quick sanity checks to make sure their code works before it gets merged.

That wasn't something we really considered, but seems really useful in the spirit of the project. Some of the scary ones are people taking Minikube and trying to use it in production scenarios. It's a single-node cluster. There's no HA. We haven't really designed it to be terribly robust across crashes. So those things worry me a little bit.

CRAIG BOX: On that note, Minikube is, by default and by design, a single-node environment. Is it realistic to test your application for something which is inherently a distributed system on a single-node environment?

DAN LORENC: Yeah, I think so. It depends a little bit on what you're testing. But one of the great things about Kubernetes is that it abstracts away the nodes into one large resource pool. So unless you really, really need to make sure that you're spreading a load across different nodes, which I think is a pretty rare case, then you shouldn't really know if you have one node or a whole bunch of small nodes.

Kubernetes is designed to abstract that away. Some of the cases where you might want to worry about this is if you're running some kind of stateful application that you need to be robust to node failures, and you really want to see what happens if you take one of those nodes away. Minikube isn't great at that, but I think that's a pretty rare use case.

ADAM GLICK: Is Minikube still needed given the fact that there's multiple cloud providers? Many of them have free tiers or free trials that offer you the ability to spin up a full Kubernetes environment fairly quickly and at fairly low cost?

DAN LORENC: Yeah. I think it's a big matter of preference. If you're happy with using a cloud provider or somebody else is paying the bill or you're on a free trial, then you should go ahead and use that. I've been working on developer tools for close to ten years now. And it feels like every single year people say, this is going to be the year of development in the cloud.

CRAIG BOX: And Linux on the desktop.

DAN LORENC: Yeah, exactly. And it doesn't feel like we're quite there. Myself, personally, I do probably about half and half, development locally and development on the cloud. I don't think this is going to be the year where we can fully stop using our laptops for building and testing code, but you never know.

CRAIG BOX: What does the development process for Minikube look like?

DAN LORENC: Developing Minikube itself?

CRAIG BOX: Yeah. Do you use Minikube to develop Minikube?

DAN LORENC: Yeah. That's a great question. We've got a pretty good user guide for how to get up and running developing on Minikube. But yeah, we do use Minikube to develop itself. I personally do all the development on a MacBook, which is a little bit trickier than doing it on Linux. But it's not terrible.

ADAM GLICK: How does Minikube compare to some of the other environments that let you run a Kubernetes cluster locally?

DAN LORENC: Yeah. So I love that there are other options out there now for local development on Kubernetes. Two of the biggest ones that I've seen recently are MicroK8s and Docker for Desktop. They're both pretty similar to Minikube, but make some different trade-offs. Docker for Desktop takes a very practical approach rolling out new Kubernetes versions. They kind of pick one of the latest stable ones and stick to that, which makes it a really stable and easy-to-use environment, especially if you're also using Docker for other things.

MicroK8s is really exciting. That's based on some new features of recent Ubuntu distributions to let you run a Kubernetes environment in an isolated fashion without using a virtual machine. So if you happen to be on one of those Ubuntu distributions and can take advantage of those features, then I would definitely recommend MicroK8s.

CRAIG BOX: Do you see space for consolidation between some of these projects?

DAN LORENC: Maybe. So Minikube tries to provide a vanilla, officially-supported Kubernetes experience across all platforms that's somewhat consistent. So with the proliferation of different container runtime interfaces, container storage interfaces, and all these different things, Minikube tries to support all of those out of the box. In addition, trying to provide that consistent experience across Windows, Mac, and Linux simplifies documentation and getting started for Kubernetes.

But if you happen to be on a platform and there's a different tool out there that takes advantage of those specific features, it can definitely provide a more native feel for you. So I guess it's a trade off, like everything else.

CRAIG BOX: One of the things about Minikube in the early days is, because it wasn't replicating all the features of a cloud provider, there were some objects, ingresses for example, that were very hard to replicate. There's been a lot of work recently to make it possible to use them. Can you tell us a little bit about that work?

DAN LORENC: Sure. Yeah, early on, we had a goal of trying to support every Kubernetes feature that cloud providers were supporting on your desktop. There were a whole bunch of those that we just couldn't figure out how to rationalize when you're not on a cloud provider, public IP. Ingress is a big example there. And some of the work that we've done is around the Minikube tunnel command, which tries to provide a more user-friendly interface to ingress and getting connections into the VM itself.

So it works by tunneling all of the ports that you have services listening on inside of the cluster to local host. So it abstracts away the virtual machine a little bit more. Some of the other features that we added later on to help mimic cloud providers or things around persistent volume provisioning. If you're on a cloud provider, then you can just request a storage space, and the cloud provider will go ahead and spin that up for you.


DAN LORENC: That was also a little bit tricky to figure out how that would work locally. But I think we've got some pretty good features in there now for it.

CRAIG BOX: How are you handling that?

DAN LORENC: Yeah. So we wrote our own custom hostpath provisioner. These aren't really recommended in cloud for stability reasons. If a node goes down, you lose that data. But since Minikube is single-node anyway, we wouldn't really have another place to store it. So we kind of abstract away the hard drive of the VM itself and make that appear as a persistent volume like you would see in a cloud provider.

ADAM GLICK: What should people not use Minikube for?

DAN LORENC: Good question. We talked about a little bit of this earlier. But Minikube is, by design, a single-node cluster. So anything that you need reliability for, like anything you're going to use in production, you should not use Minikube for. You should use something that has at least two or three nodes so, if something crashes, you don't lose all of your data.

CRAIG BOX: Is there a use case for people who only want to run a single-node Kubernetes cluster? They have a single VM workload. They just want to use the API. HA is not in the question for this particular case. Is running Minikube-- I've heard of people doing that. Would you recommend that they do that? Or is there an alternative they should look at?

DAN LORENC: Yeah. So if you're 100% sure that you're never going to need more than a single node, and you don't care about HA, then Minikube might be an easy way to get started. If you think there's any chance whatsoever that you're going to need to expand the cluster to multiple nodes or use any of the disaster recovery features Kubernetes provides, then I'd probably start with kubeadm yourself.

Kubeadm didn't really exist when Minikube started, so we had to build a lot of that stuff ourselves. But now, kubeadm is a great way to get a single-node cluster setup that then makes it easy to add other nodes on to later.

CRAIG BOX: Have you considered options for integration with kubeadm now? Like, is there a kubeadm provision Minikube integration on the cards?

DAN LORENC: Yeah. So I think about a year or two ago Minikube did officially switch everything over to using kubeadm under the covers.


DAN LORENC: So it provides a pretty easy way to configure all of the advanced features that kubeadm provides.

ADAM GLICK: Does it have the same level of reliability in terms of the components, in terms of, is it the same software that's running underneath? Or is it actually a lower level of software in terms of connection to etcd and how it handles secrets or other pieces of information that might make it not production-ready?

DAN LORENC: So it's the same exact software you're running in a real production cluster. It's just all configured to be running on a single node. Kubernetes has about a million flags for every single one of the components in there. And so we have tuned a couple of them to provide better experiences locally, which might affect reliability-- things like how fast syncs to etcd happen, refresh periods on some of the polling controllers. We've turned down a bit to improve battery life, reduce CPU usage. But those come with other trade-offs around scalability and reliability.

CRAIG BOX: A lot of people will have their first interaction with Kubernetes through Minikube. They'll follow a tutorial. They'll download it, set it up, install some YAML files. It often seems like there's a big gap between that and "I have my own application, I want to deploy that and run that on my cluster." What do you recommend as the good next steps for someone who has gone through that 101 process?

DAN LORENC: So if you have an application that you're trying to get running on Kubernetes, the very first step you've got to do is figure out how to containerize it. I think Kelsey Hightower once said that the admission fee to getting into a Kubernetes cluster is building a container. So depending on where you are in that journey, first you're going to have to figure out how to containerize your application.

After that, copy-pasting and learning from reading the existing YAMLs or Helm Charts or some of the other things you played around with-- my personal method of learning about the new Kubernetes features. But that'll vary per user. I like to just find something that does work and start changing from there to get my application running.

CRAIG BOX: Do you recommend people should be using Minikube for that first step?

DAN LORENC: For the first step of containerization? You can use Minikube. And that makes a pretty quick edit-debug loop since you don't have to push your containers up to the cloud and then pull them back down. But whether you're using Minikube or Docker, that process is roughly equivalent.

ADAM GLICK: What's next for the Minikube project?

DAN LORENC: There's a lot of stuff going on this year, in 2019. There's a roadmap inside of the GitHub repository. But the high-level goals are basically to support the next wave of Kubernetes users. Early on, in the project, the early adopters of Kubernetes were all very technical, happy to debug API server issues. But now, as Kubernetes is rolling out to support the next billion users, the use cases are changing a little bit.

The team is working on supporting things like localization, better support for environments that have slower connectivity, partial offline mode for people that either have bad internet connections or behind some kind of firewall that makes accessing external resources difficult, and then reduce resource consumption. So you can run on laptops with lower hardware requirements. Those are all on the list for 2019.

CRAIG BOX: What kind of connectivity does Minikube need to the internet by default?

DAN LORENC: The biggest thing is just round container images. Not too many people know this if you haven't played with Kubernetes before. But a large part of Kubernetes actually runs in Kubernetes itself. So things like the master control plane is running as a container inside of Kubernetes. So once you start up a cluster, it's going to go and pull all those components from the internet. So starting up, checking for new versions of things require an internet connection, unless you have some other way of getting those containers to the environment you're in.

CRAIG BOX: But if I do like a Minikube download and get, effectively, an ISO file or something that's the default disk, does that contain all the pieces that I need? Or is the first thing a Minikube cluster does is go out and pull the rest of its pieces?

DAN LORENC: Yeah, correct. So if you just grab the Minikube ISO to reduce that initial download size, we don't bundle all of those images. Those images are also updated pretty frequently outside of the normal Kubernetes release process for security updates. So it's easier to just grab those from the cloud.


DAN LORENC: Minikube does have a couple different ways to build a bundle of all of those and store it somewhere on your hard drive so you can reload from there if you need to.

CRAIG BOX: What kind of contributions is the Minikube project looking for in order to help meet those goals and beyond?

DAN LORENC: Yeah. So that's a big list of features. And of course, I didn't even mention just keeping up with Kubernetes itself. And the velocity of Kubernetes just keeps increasing. And so we have to figure out ways to support all the new features and all of the new versions. There's definitely more than enough work for the team. So if you're interested in helping, hop on GitHub, look through the issue tracker, or attend some of the Minikube community meetings.

One of the areas we're specifically looking for help is around Windows environments. Some of the recent developer studies have shown that about 40% to 50% of developers out there are still on Windows. But the Minikube team itself doesn't have much expertise there. So if you're a Windows expert, we would love to hear from you.

ADAM GLICK: Minikube was the first of a number of projects that I know you've worked on in the open-source community. What are some of the things you're most excited about and looking forward to?

DAN LORENC: Yeah. Minikube is basically the first step in local development for Kubernetes. And it just kind of provides that cluster where you can run kubectl or any of the other tools. I'm excited about starting to move up the stack there to provide some better features for users. One of the other recent projects we started was called Skaffold. This kind of complements Minikube.

Skaffold watches your source code, automatically rebuilds it, and deploys it to a cluster. If you're using Minikube, then it's able to do a whole bunch of optimizations there to avoid pushing container images and building things on the fly, even syncing in static files directly to improve that loop time. If you do happen to be using a cloud provider, then Skaffold also works there. But the iteration times are going to be a little bit slower.

CRAIG BOX: And what has your work with the Knative project involved?

DAN LORENC: One of the other areas that's been challenging for Kubernetes so far is running CI/CD systems in Kubernetes itself. Building container images inside of containers is pretty tricky. And all of the old CI/CD systems aren't terribly cloud native and don't work super well with Kubernetes. So inside of the Knative project, we've been working on some low level primitives to make it easy to build applications inside of Kubernetes clusters and then stitch together full CI/CD pipelines that involve things like build, test, and deploy across multiple Kubernetes environments.

CRAIG BOX: And do you think that work will be useful for people who are just wanting to test applications that they have in their own containers versus the Knative model of source to container?

DAN LORENC: Correct. Yeah. So Knative serving provides a pretty good set of primitives for source to container. But the rest of the Knative project is really about standardizing building blocks to put together big application stacks. So the Knative build project is an extensible way of doing builds and tests inside of containers that produce containers, whether you're going to use that in a serverless environment or something else.

CRAIG BOX: Dan, thank you very much for joining us today.

DAN LORENC: Thanks for having me.

ADAM GLICK: Thanks, Dan. You can find Dan Lorenc on GitHub at github.com/dlorenc, that's D-L-O-R-E-N-C, or on the web at www.danlorenc.com.


Thanks for listening. As always, if you enjoyed the show, please help us spread the word and tell a friend. You can also give us a rating in your favorite podcatcher. If you have any feedback for us, you can find us on Twitter @kubernetespod or reach us by email at kubernetespodcast@google.com.

CRAIG BOX: You can also find our website with transcripts and fun banter at kubernetespodcast.com. Until next time, take care.

ADAM GLICK: Catch you next week.