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

CRAIG BOX: And I'm Craig Box.

[MUSIC PLAYING]

ADAM GLICK: This week I have continued to learn that Seattleites are voracious readers. I've mentioned the little free library box that we built and put books into occasionally and occasionally pull books out of. And it appears that no one ever takes just one. It's like Lay's potato chips.

They come in blocks. And we'll just watch like-- six books will disappear all at once. And then a few days later, a block of five books appears. And just everything moves in chunks. No one reads just one book, which is not what I expected of the library, but just kind of one of those neat things to see happen, as you see the kind of gift economy of the little free library run.

CRAIG BOX: Do you have a webcam pointed at it, or do you have to go out and check to see the situation every day?

ADAM GLICK: I did set up a camera that has a motion sensor, so I do see when things go in and out of there. But it is not in the box, per se. It's just in the house pointing at it.

CRAIG BOX: Has anyone left a book that you've wanted to read yourself?

ADAM GLICK: Someone left "The Metamorphosis" by Franz Kafka this week, actually.

CRAIG BOX: Ooh. Are they trying to make a point?

ADAM GLICK: [LAUGHS] That might be one that I pluck up for myself and read through before sticking back in the box.

CRAIG BOX: Well, heck of the week this week, a performance artist, a German guy called Simon Weckert in Berlin, has been walking around with a little pull cart, like you might remember Linus tugging around from the Peanuts cartoons. It's full of cell phones.

He's got all these cell phones logged in to Google Maps. And it turns out, if you've got a cell phone that's moving very, very slowly, it assumes that you're in a car navigating. And he's able to cause traffic jams live on Google Maps--

ADAM GLICK: [LAUGHS]

CRAIG BOX: --these 100 cars, all very, very slowly moving down the street. You can see in his little video that the street just turns red. And you could just imagine people thinking, well, I'm going to pay that guy to walk down my street. And then people will choose not to drive down it, because they think it's bad. And they'll have a much nicer day.

ADAM GLICK: That is an interesting way to play with the games of technology.

CRAIG BOX: I'm sure Google will get around to patching that soon. But apparently it's called a Sybil attack, which is-- think of sock puppetry on the internet, people inventing fake pseudonyms and going around doing things. But that is a fun way to look at the intersection of liberal arts and technology, as our friend Steve used to like to say.

ADAM GLICK: Do you know where the name Sybil comes from? I wonder if it comes from the famous case of multiple personalities.

CRAIG BOX: It does indeed, and named after the subject of a book, which one day hopefully will end up in your little free library?

ADAM GLICK: Shall we get to the news?

CRAIG BOX: Let's get to the news.

[MUSIC PLAYING]

ADAM GLICK: The CNCF has announced the five newly elected members of the Technical Oversight Committee. The three members elected by the governing board were Saad Ali from Google, Sheng Liang from Rancher, and returning member Liz Rice from Aqua Security.

Justin Cormack from Docker was elected by the Maintainer community. And the End User community elected Katie Gamanji from American Express, who was, until recently, at Condé Nast. Congratulations to the new and returning TOC members.

CRAIG BOX: Celebration is also due at cloud native identity company Scytale, which has just been acquired by HP Enterprise. Co-founder Andrew Jessup was our guest on episode 45. HPE state that they are fully committed to continuing Scytale's stewardship and contributions to SPIFFE and SPIRE, and that these projects will play a fundamental role in HPE's future cloud plans.

ADAM GLICK: The schedule for KubeCon EU has been posted, with over 240 sessions selected from over 1,500 submissions. Keynotes announced so far include Shopify talking about runtime security and Pinterest talking about building a control plane for Envoy proxies. If this sounds like you, remember you can get 15% off tickets using our special discount code KCEUGKP15, which you don't have to remember, because it's in the show notes.

CRAIG BOX: Following up on last year's Alpha, Google Cloud has announced the public beta of Windows server containers on Anthos GKE. They can be found in the rapid channel. And you can learn more about Windows Server containers and Kubernetes in episode 70 with Patrick Lang from Microsoft.

Google also announced two new certifications-- the Certified Fellow, for jolly good technical leadership, especially in the area of hybrid cloud, and the professional cloud DevOps engineer.

ADAM GLICK: At their Cisco Live event in Barcelona, Cisco announced the HyperFlex application platform for containers. HyperFlex is Cisco's hyper-converged hyper-architecture. The new application platform deploys Kubernetes on top of the open source KVM hypervisor, providing clustered application hyper-management without requiring a commercial virtualization solution. The product is due to be available in Q2, and Cisco have said that they are evaluating the demand for running directly on bare metal. If you prefer your Kubernetes managed by Google, the two companies also announced that Anthos is now generally available on Cisco HyperFlex hardware.

CRAIG BOX: Azure Kubernetes service has added new features this week, including bring your own key support for encrypting disks, increasing the maximum number of node pools from 8 to 10, allowing clusters up to 1,000 nodes, and adding support for Kubernetes 1.16 and 1.17 in preview.

ADAM GLICK: AWS has published the results of a 2019 container security survey, which shows their users are primarily running hosted AWS products. Most are using the scanning features in the Container Registry, but not scanning at runtime, and fewer signing images, or otherwise managing their digital supply chain. Pod security policies are a step too far for most users, but network policies are popular and mostly implemented with Calico, the AWS default, with service mesh in second place.

CRAIG BOX: Two of the founders of Kitematic, a Canadian startup that was acquired by Docker and became part of Docker's desktop experience, are at it again. Infra is a desktop app for managing multiple Kubernetes clusters. It's being developed in Electron, so it will be cross-platform, at the expense of eating all of your RAM. Private beta testing has started, on the Mac only for now. Given the pedigree of its founders. This may be one to watch.

ADAM GLICK: Want to try to Istio on your desktop? London cloud native consultant and OpenFaaS founder Alex Ellis had a chat with my co-located co-host last week. Craig was shown two of Alex's tools-- Inlets and "Ketchup." That's spelled K-3-S-U-P. The tool can be used to get Istio running on Docker desktop. K3sup installs Istio with a single command, running in a kind cluster.

And Inlets is used to proxy the microservices to a public IP. Alex shared the steps, as well as an explanation of the schedule of British meals in a blog post entitled, "A bit of Istio before tea-time." Other recent posts from Alex include, "How to build containers without Docker," "How to proxy A Cloud IP to your minikube cluster," and "How to build a Linux desktop for cloud native computing."

CRAIG BOX: The etcd project commissioned the database testing company Jepsen to test its consistency and documentation, and both teams have written up their findings. Jepsen first tested etcd in June 2014, a simpler time, when people might have picked up the oblique pop reference in the project name.

Since then, etcd has increased its consistency guarantees, adopting linearizability as a default in 3.0. The major finding in this report is that the way etcd documented the use of distributed locks was misleading. Updates are under way to help users understand where locks can be used and where they cannot provide solid guarantees.

ADAM GLICK: Have you ever wondered how Kubernetes collects all of its log data? If so, help is available. And that help comes in the form of a blog post from Brady Zuo. Brady was working on putting Fluentd data into his company's Zebrium log monitoring tool. He does a nice job of breaking down what data comes from where, and provides links to examples in GitHub.

CRAIG BOX: Kubernetes is designed to allow you to run multiple containers on a single host, and has provisions to kill containers that use too much memory or CPU. The standard case is well known. If you exceed your individual container memory limit, it will be terminated.

But there are many other aggregate cases. And CPU and memory overcommit work in very different ways to each other. Carlos Arilla covers the things you need to know in a post on the Sysdig blog. Configure your quotas carefully, because sharing is caring.

ADAM GLICK: There's a meme in the networking community that says, it's always DNS. Sometimes it is. And if you want to know when it is for Kubernetes and what 'ndots:5' means, then check out a post from Karan Sharma, who summarizes the situation. His post helps you understand how DNS works for Kubernetes services and how a name resolution happens.

CRAIG BOX: Justin Cormack from Docker has posted this week about the upcoming plans for Notary version 2. Notary is a project designed to protect the supply chain of containers, from registry to cluster. The project has broad support from most makers of container registries.

Ideas for version 2 include placing the signature of a container into the registry, and simplifying the process of signing containers, managing the keys, and verifying those signatures. The team has met recently and will meet again at KubeCon EU to continue development.

ADAM GLICK: The CNCF has posted an update about their Speakers Bureau, which is the place you can go if you are running a conference or meetup and would like one of the CNCF's ambassadors to present. It lets you filter by criteria, such as region. And you can even send out a message to multiple speakers at once. It's now easier than ever to get a high quality speaker about cloud native technologies to come to your event.

CRAIG BOX: Finally, congratulations to MayaData, our guest on episode 56, as they have just raised an additional $26 million in the financing round that included AME cloud partners, data core software, and insight to partners. MayaData is the company behind OpenEBS, a CNCF Sandbox project. And they stated that downloads of the project grew 500% during 2019.

ADAM GLICK: And that's the news.

[MUSIC PLAYING]

CRAIG BOX: Marin Jankovski is employee number 1 of, and an engineering manager at, GitLab; a DevOps application available in open source, enterprise, and SaaS versions. Welcome to the show, Marin.

MARIN JANKOVSKI: Thanks, Craig. Thanks for having me.

ADAM GLICK: What was the origin of GitLab? Where'd it come from?

MARIN JANKOVSKI: The project actually started in 2011. The first commit was in October 2011, created by Dmitriy Zaporozhets from Ukraine. And I joined the company at its conception back in 2012, when the current CEO saw the open source project and thought, this is the future. This is what we need to do. And yeah, once I joined, my first task was get GitLab running on gitlab.com in AWS. So that was my first two weeks of working, trying to automate installation of GitLab and its latest versions.

CRAIG BOX: All running on VMs at the time?

MARIN JANKOVSKI: All VMs at the time, and all installation from source, no automation whatsoever. You clone, and then you try to set up Redis, try to set up Nginx and all of that from scratch.

CRAIG BOX: What technology did you use to do that first automation?

MARIN JANKOVSKI: I used Chef, because I was, at that time, very much familiar with it. So it actually stuck with us for-- well, up until last year basically, we were using Chef to deploy a lot of our stuff. So it's one of those things where that was the most convenient. And I knew it at the time, and that worked the best for me.

ADAM GLICK: Do you now use your own tools for it?

MARIN JANKOVSKI: Right now, we have a combination of our own tools plus some Ansible. So that is the gist, basically.

CRAIG BOX: GitLab started out as source code hosting, but has evolved to include so much more. What are some of the features that are in GitLab today?

MARIN JANKOVSKI: In addition to source code management, we also have CI, CD package features, meaning various package hosting options. We also have security features, so security scanning, dependency scanning, licensing management. More recently, we added items like monitoring, logging, and so on. So we are covering everything from the moment you push your code to the moment you deploy and need to debug or run and so on.

CRAIG BOX: How do you decide which pieces to add to the platform?

MARIN JANKOVSKI: It really depends on the needs of our users. So given that we are a completely transparent company, our direction, future development is completely out in the open. We actually do listen to our wider community. And we get a lot of questions on, hey, it would be cool to get this feature in, because it's useful to have it in this one tool. So I think a lot of direction comes from our users and from our customers.

ADAM GLICK: You mentioned that you're a transparent company. I also understand you're a completely decentralized company.

MARIN JANKOVSKI: Correct. We currently have almost 1,100 employees. And we are fully distributed across the world. And I think last time I checked, we had people in 50 locations, not a single office, and day to day, always through laptop-- so very exciting stuff, actually.

ADAM GLICK: When you say you're a completely transparent company, what drove that decision, and what challenges does that create for you?

MARIN JANKOVSKI: I'm not the best person to answer what drove the decision. But I was there when some of those decisions were made. I'll use the example of our database incident, when we deleted a database by accident. By actually having us debugging and trying to restore the backup out in public, live on YouTube, we actually gathered a lot of support.

But not even support, actually. We also got a lot of folks recommending what we could try to make this faster, to make the restore faster. And the community kind of rallied around us to help us out. And I think we saw that very early on as a superpower, in my opinion. I know that when I was trying to recover database when we were much, much smaller, back in 2013 or something, at 4:00 AM in the morning, publishing a document that folks saw when they woke up, actually it gave me a lot of directions on where to investigate next.

So I didn't know much about databases at that time, so folks submitting their suggestions actually helped me out, get the database back. So I think that is one of the superpowers of being transparent.

One of the challenges is, not everyone likes what they read. Everyone has an opinion, as well. But not everyone has all the background that is provided. So that is one of the challenges, for sure.

CRAIG BOX: You have a very similarly named competitor in GitHub. How would you describe the difference between their platform and yours?

MARIN JANKOVSKI: I personally would say we have a fundamental difference in how we view workflows. So while we did start as a GitHub clone, and then a competitor, we did expand by adding our CI, CD offer, which enabled completely different workflows. GitHub only recently added CI tools. We have had them for a while now. And by having those extra tools inside of the source code management, we enabled folks to shift faster, but not only do social coding that GitHub offered at that time.

ADAM GLICK: You mentioned that you're a single application. Why is being a single application important?

MARIN JANKOVSKI: I think that also comes from the early days, when I spent enormous amounts of time integrating a number of services that GitLab consisted of. So we also saw that companies invest a lot of time and money into integrating the tools they need to use for their work.

And if we offer the integrated single application for them so they don't have to take care of a bunch of tools that they have, they can actually focus on shipping their own stuff. So they save the money and the effort in maintaining the tool, and they can focus on actually delivering value for their company. I think, when we realized that we can also control how we ship things-- meaning, if we want to change how the interaction between different items works between different components.

This came from the moment when we integrated CI into GitLab. We realized that that also allows us to ship way faster to our customers and change features, add new features way quicker, enabling our customers to be able to use those tools way quicker. Because they don't have to think about different sorts of versionings, how are they going to transition. We are handling all of that for them. And they can only focus on using the actual tool.

CRAIG BOX: GitLab has an open source edition, and then there are enterprise editions and hosted versions available. How do you decide which features go into the open source platform versus the commercial platforms?

MARIN JANKOVSKI: This comes from workflow item that I mentioned earlier. We want to enable all the basic workflows that a vast majority of users need. And we want to make sure that only very advanced features that larger companies-- that multiple users in a company need is actually a part of enterprise editions. So that means that we want to ensure that whoever uses source code management can also use CI and deploy whatever they are doing very quickly.

But when they need additional controls, when they need to make sure that they have additional approvals, for example, all of those items are very much a requirement of a developed company. So this is where we decided those additional features need to be in our paid versions. And actually more often than not, depending on how much interest there is to open source certain features, we do push items back into open source, as well. We made a promise very early on as stewards of GitLab, open source community that we will not do the other way around. Like, we are not going to make something that is open source bait.

ADAM GLICK: GitLab started before containerization and Kubernetes took off. What made you decide that you wanted to pivot what you were doing and start to adopt that kind of architecture?

MARIN JANKOVSKI: First of all, I think this came from us observing that Kubernetes is on its way up. So the first time I actually heard about Kubernetes is when it was open-sourced. And again, I heard it from the CEO. He read about it somewhere, and said, this is amazing. This is going to change the game for a lot of folks. We need to focus on this.

And we started following Kubernetes, the project. But when we realized that we are growing, our gitlab.com SaaS offering is growing way faster than we can hire people to manage the growth, we realized that we also need to change how we operate GitLab. So the primary driver of us migrating to Kubernetes on gitlab.com is the need to be able to react quicker, ship quicker, scale faster with the demand that we have.

CRAIG BOX: Did you first implement support into the product for deploying to Kubernetes, or did you first move the product to running on Kubernetes itself?

MARIN JANKOVSKI: We did both in parallel. So all of the development in actually deploying GitHub on Kubernetes was happening at the same time when we were developing features for our users to be able to deploy to Kubernetes.

CRAIG BOX: Did you make different choices as someone who is not only making a service that you run yourself, but you offer to customers to run in their environment, versus if you were only running the SaaS platform?

MARIN JANKOVSKI: We had to make different choices. This comes from the fact that we use the same platform that we ship to our customers. And in order for us to be able to support our customers, we need to know what we are running. So the complexity of the whole platform needs to be reduced as much as possible, because we want our customers to be able to run it themselves, as well. So think of it this way. Gitlab.com is the largest GitLab installation in the world. But we want to ensure that any customer that wants to become the biggest installation in the world can just leverage the same path that we already took, so that they can take the tried and tested setup.

CRAIG BOX: What was the actual process of transferring the code, which, as you said before, was runbooks and Chef and so on, to containers and Kubernetes?

MARIN JANKOVSKI: We needed to ensure that we have no downtime. That is a very simple requirement, but a very complex one, as well. So what we ended up looking is, how can we make sure that whatever we do in the background does not affect our customers, and that we direct traffic to the new setup as we have it ready tried and tested.

So what we ended up doing is, for a long time-- and we still actually are-- running a hybrid between VMs and Kubernetes clusters. So depending on which workload you hit on gitlab.com, you will either be serving or receiving your traffic from a VM or from a Kubernetes cluster. So we ensured that the change behind the lines is not observed by our customers, and that we can, part by part, replace our traffic from old VMs to new Kubernetes workloads.

CRAIG BOX: Are there any things that caught you along the way that you would offer as advice to someone else making this transition?

MARIN JANKOVSKI: Yeah, there was a lot of surprises, actually. And one of the biggest surprises was, how do we do a hands-free deployment on Kubernetes? You always see kubectl here and there and everywhere. But we are in automation business.

So one of the tasks I gave to my team was, how will you ensure that, when a developer merges something into their master branch, you, as an SRE engineer, don't have to do anything? And it is surprisingly complex, actually, to connect multiple services and ensure that they're working correctly, and then also that you don't have to do any work. So I would definitely recommend anyone who's migrating their workloads right now to look into what can they do to make sure that they don't actually have to do anything anymore once their items are running. So KubeCTL commands are nice. But how do you put that in your CI or your CD platform to ensure that everything is hands-free?

CRAIG BOX: And is it fair to say that I can make GitLab do all that for me?

MARIN JANKOVSKI: We are using GitLab to deploy GitLab, so yes.

ADAM GLICK: Would you consider yourself a monolithic or a microservices-based architecture?

MARIN JANKOVSKI: I would definitely consider GitLab a monolithic architecture, for sure.

ADAM GLICK: A lot of the trend we're seeing these days is focused on microservices and people breaking up monoliths. You are following a different trend there. What made you decide to move towards more of a monolithic design?

MARIN JANKOVSKI: Not necessarily move-- we are staying with it still. What we are seeing is that, even at large scale, there is a benefit of running items in a monolithic architecture. The benefits are mostly related to how quickly can you turn around the feature, how quickly can you ship, how quickly can your developers do their job.

What we also saw is that, only when we start seeing some bottlenecks, it makes sense for us to start transitioning certain parts of the monolithic structure into a microservice component. We've done that multiple times in the past. So GitLab now has a couple of satellite repositories, as we call them.

But they are actually the microservice part of our stack. So I originally said we are more of a monolith, for sure. But we are a hybrid when it comes to the architecture of GitLab.

ADAM GLICK: What parts of your infrastructure don't run on Kubernetes and why?

MARIN JANKOVSKI: On gitlab.com, we run our databases and our Git storage outside of Kubernetes. I think the primary reason for that is, these are the hardest things to get right, in at least my opinion, in Kubernetes. And we are growing too fast to be able to experiment with moving that over to Kubernetes, as well. So we are still very much learning in, how do we run our application at scale, even with only stateless part of our stack.

CRAIG BOX: Given that GitLab has continuous delivery components, you will be able to know through support volume or what people are saying, in terms of customer demand and the targets, the places that they want to deploy to. Do you see a huge shift in people who are now deploying-- for example, they used to deploy on VMs, and they're now moving to Kubernetes as a target?

MARIN JANKOVSKI: I absolutely can say that we see that. Recently, we had an issue with one of our features on gitlab.com that enables customers to use Kubernetes. And to my surprise, within the hour of us seeing the first errors, we saw a lot of support pressure to ensure that we fix the problem really, really quickly. And with each hour that passed-- a total of, I think, six-- the support workload was quite high, which meant that a lot of people were depending on their deployments to Kubernetes from inside of GitLab.

ADAM GLICK: What we've seen recently, at the most recent KubeCon in about the year leading up to it, is a real shift towards people viewing Kubernetes as the environment that they want to use for hybrid and multi-cloud deployments. What do you see is the demand with your customers, in terms of using GitLab in that kind of design?

MARIN JANKOVSKI: Our customers run on various clouds. Our customers run various workloads on various different platforms. We are no different. We also run on different cloud providers. And the fact that it takes a lot of effort to migrate from one provider to another, or migrate your workloads from one provider to another, is actually encouraging this new path, I would say, where we are no longer seeing that one cloud is going to win them all. It's more that the collaboration between different clouds is going to enable customers to ship their products faster.

ADAM GLICK: You offer both an on-premises version in open source, as well as a commercial version and a SaaS version. Do you see people using GitLab where they're actually using it in multiple locations at the same time?

MARIN JANKOVSKI: Yes. We also have a combination of customers using our own SaaS platform and using their own self-managed instances, and also distributed across different platforms. We have features inside of GitLab that allow geographical distribution of our application. And that kind of shows that you cannot have one size prescribed for all of your customers. They have different needs for various reasons-- compliance or their own internal requirements. And they will use whatever is easiest for them. And if you, as a tool, enable them to use what they need, you can do a lot.

ADAM GLICK: What has been your experience taking your SaaS platform, as you've moved it to multiple clouds where it's been, and as you expand it further?

MARIN JANKOVSKI: One of the biggest challenges was whenever you need to transfer a lot of data. A lot of data also means creating a lot of load on your platforms. And it was not simple at all to migrate different workloads to different clouds.

So with the rise of multi-cloud, it is becoming imperative that the software we are using to deploy directly to different stacks is robust enough that you can just do a lift and shift to another provider, without needing to take a lot of downtime.

CRAIG BOX: A number of your developers will be looking to not worry about the infrastructure they deploy on, and there has been a rise, especially in the last 18 months, in serverless platforms, functions-as-a-service, and so on. GitLab have adopted Knative and built a serverless product, as well. Do you see that developers are looking to run functions-as-a-service more?

MARIN JANKOVSKI: Yes. There is a real need for that. For very simple workflows, you get a lot of bang for your buck in iteration, meaning, how quickly can you get your product to market? And if you don't have to think about the infrastructure behind it, then the story that I mentioned earlier about how you can focus on your product becomes even more interesting. So absolutely.

CRAIG BOX: Do you think that is the logical end goal for enterprise software, for example?

MARIN JANKOVSKI: I think so. As long as you don't have to deal with complex data structures, the serverless seems to me to be a clear winner there. And if you consider that a lot of applications that you see online don't have a complex data structure, there is no reason why enterprises wouldn't be able to adopt the same thing. After all, people working in the enterprises are also folks who are contributing a lot of items to the open source and have their own startups and so on.

ADAM GLICK: GitLab has a very unique logo. It's a tanuki, sometimes referred to Japanese raccoon dog. How did that become a GitLab thing?

MARIN JANKOVSKI: That is a very interesting story, in my opinion. The original logo that was created and contributed by an open source contributor was around with us since 2011. The logo was looking pretty angry for a lot of folks. We actually even received a bunch of tweets telling us that our logo is giving folks nightmares.

So when we graduated from Y Combinator, one of the items that we were talking about is, how do we look less threatening? And we reached out to the creator of the original logo, who-- it just kind of shows how small the world is-- turned out to be very close to us at that point in time. We were in Mountain View, and we met him there by sheer accident.

And he gave us a contact of a person who created our current logo. And one thing that we wanted to make sure is that we are not mistaken for another fox-related company. So we also didn't want to be a raccoon. And this is where a tanuki, a combo, basically, came from. And it always is an interesting question that we get from folks, whether you are a fox or something else.

CRAIG BOX: What's coming next? What are you excited about that's perhaps on your roadmap?

MARIN JANKOVSKI: The story of multi-clouds that was mentioned multiple times is something that is definitely high on my list. We have a long-running partnership with Upbound for integration with Crossplane project. And in the latest version of GitLab, we are releasing that integration for anyone who connects their Kubernetes cluster to a GitLab project. So with one click, you can install Crossplane inside of your cluster. And that will allow you to create workloads in any of the clouds that Crossplane supports. So if you need an S3 bucket, you can select whichever account you want to run it on and all of that with a single click or a single command, which is, I think, very impressive and, I think, the future for us.

Another thing that I'm actually excited about is similarly to how we have GKE integration for GitLab projects, we are releasing the same integration for EKS Amazon clusters. So it's going to be simpler for folks running in Amazon Tools to deploy their projects to their clusters. So with a couple of configuration options, they'll be able to provision a new cluster with a single click.

ADAM GLICK: Marin, it was wonderful having you on the show.

MARIN JANKOVSKI: Thank you, Adam.

ADAM GLICK: You can find Marin Jankovski at gitlab.com/marin.

[MUSIC PLAYING]

ADAM GLICK: Thanks for listening. As always, if you've enjoyed the show, please help us spread the word and tell a friend. 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 check out our website at kubernetespodcast.com, where you will find transcripts and show notes. Until next time, take care.

ADAM GLICK: Catch you next week.

[MUSIC PLAYING]