[MUSIC PLAYING]
DUSTIN KIRKLAND: Hi, I'm Dustin Kirkland
and I'm here with Saad Ali, tech lead
at Google for storage in Kubernetes.
And we're going to talk a bit about, maybe,
your views on some of the big problems left
to solve in the Kubernetes technical arena.
SAAD ALI: Sure.
So SIG storage has been dealing with a bunch
of different issues, most recently
around making Kubernetes storage more extensible.
So we authored the container storage interface project
with the goal of making volume plug-ins
external to Kubernetes.
The challenge so far has been--
Kubernetes, we've developed a very powerful volume subsystem,
but in order to add new volume plug-ins,
you have to actually check code into the Kubernetes core
codebase.
And that's extremely painful for us as Kubernetes developers,
because we have to maintain and test code that we don't write,
and we don't necessarily have all the external dependencies
to be able to test it properly.
And it's painful for storage vendors,
because they have to align themselves with the Kubernetes
release and they have to open source code that they may not
be comfortable open sourcing.
DUSTIN KIRKLAND: So this should accelerate
a bit of the portability of the storage layer for Kubernetes.
SAAD ALI: Exactly, exactly.
DUSTIN KIRKLAND: And what about ensuring--
can it do that while still ensuring API compatibility?
SAAD ALI: That is the goal.
So one of the reasons we didn't want
to come up with an interface early on
was, it's very difficult to predict what the usage patterns
are going to look like.
And so initially, we built everything in-tree.
We could iterate on it very quickly.
If we broke a volume plug-in because we
wanted to modify the API, we could go ahead and update
those volume plug-ins.
They were all in-tree.
Now we've gotten to a point where we understand what
the interface should look like.
And we've gotten to a point where we can actually
go ahead and create an interface, an API, that
is going to fulfill our needs.
DUSTIN KIRKLAND: So the API is separate, of course,
from the implementation, but the API, you feel like,
is pretty well set at this point?
SAAD ALI: It's still evolving.
So we haven't gone to 1.0 yet.
And the reason for that is because we
want to give ourselves the ability
to continue to evolve it until we're confident in it.
So with Kubernetes, we went beta last quarter.
And next quarter, where we're going to keep it in beta,
and then the quarter after that we plan to move it into GA.
When we move into GA, we want to move the interface to 1.0.
DUSTIN KIRKLAND: Is this a problem
that you look to make some progress on, perhaps this week,
at the contributor summiit, or over the course
of the conference?
SAAD ALI: Yeah, absolutely.
It'll be interesting to talk to developers, especially
in the storage arena, who are actually writing volume
plug-ins, and get their feedback on the interface
as it exists today.
DUSTIN KIRKLAND: And this interface is--
so far in your experience, it's been portable across clouds
and on prem as well?
SAAD ALI: Yes.
The idea with the volume plugin is that
no matter what kind of storage system,
whether it is a cloud storage system,
could be GCE persistent disks, Amazon EBS disks,
or on prem if you're running something like NFS, iSCSI, or--
DUSTIN KIRKLAND: CEF?
SAAD ALI: CEF.
You can write a volume plug-in and it'll just work.
And as far as your end users of Kubernetes are concerned,
it's abstracted away from them, so they
don't have to worry about the actual storage that's
fulfilling their workload's storage needs.
DUSTIN KIRKLAND: Do you have a perspective, perhaps,
on maybe some of the ways that Kubernetes
is helping with storage at scale, large scale?
SAAD ALI: Yeah, so I think one of the challenges in the past
has been that storage requires the end user to be intimately
aware of the type of storage system that they're using.
And with Kubernetes, one of the cool things it's done
is it has abstracted away things like compute memory,
but also storage.
At least for file and block, an end user no longer
has to worry about the specific implementations
of their storage, where it comes from, how it's going to scale.
They can just assume that it exists.
And Kubernetes will make sure that it's available
wherever their workload is scheduled
and move around with it wherever their workload is scheduled.
DUSTIN KIRKLAND: And then what about the cross section
of the hard problems around storage and networking?
Much of the storage is network attached,
so you've clearly got to have a tight correlation with--
the storage SIG and the network SIG
have to be pretty tightly correlated, right?
SAAD ALI: Yes.
A lot of the magic that comes from being
able to move your workloads around with your storage
is due to the fact that the storage is actually
network attached.
That does come at a cost.
If your storage is going over your network,
and you're network constrained, it can cause issues.
Unfortunately, in Kubernetes, we don't
do a great job of being able to partition out your network I/O.
DUSTIN KIRKLAND: So Saad, you've mentioned
SIG storage a couple of times now,
and it sounds like you're in a leadership
position around the SIGs and have been around that.
Maybe tell us a little bit about how the special interest
groups work in the CNCF, and around Kubernetes,
and maybe some best practices you've
learned in working with that.
SAAD ALI: Yeah, so the special interest groups and Kubernetes
are designed to kind of break this very, very large project
into more manageable chunks.
Trying to manage a project the size of Kubernetes,
an open source project where you don't have hierarchy,
you don't have folks who are in charge of large groups,
is very difficult. And so with the special interest groups,
what we've tried to do is create areas of interest
where you can have developers focused
on a specific area of Kubernetes.
So for example, I work with SIG storage,
and we're responsible for the volume subsystem of Kubernetes.
DUSTIN KIRKLAND: And if someone wanted
to get involved in your SIG another SIG, what's
that process look like?
SAAD ALI: So we hold biweekly meetings,
at least in the storage SIG side,
and all the other SIGs also have meetings
that they hold regularly.
And the schedules are published on the website.
And we know that folks all over the world
can't necessarily attend.
No matter what time you're going to pick,
there's going to be a time zone that
isn't going to work for people.
So we encourage all SIGs to actually record and publish
these meetings, so that if you're in a time zone that
can't attend or for whatever reason you can't attend,
you can catch up on what's going on with the SIG.
DUSTIN KIRKLAND: Good, good.
That's great.
Yeah, so, it's a really interesting community,
this Kubernetes community.
I'm curious if you have any thoughts
on particular community members that maybe you
want to give a shout out to people that have helped you
or inspired you in the last few months.
SAAD ALI: So I guess one of the really awesome developers I've
been working with recently is Vladimir Vivien.
He used to be with the Dell EMC code team.
He's now with VMware, still working
on Kubernetes, specifically the container storage interface
project.
I'm super impressed with his knowledge of the Go language,
gRPC, and just how personable he is.
He works remotely from Florida, but he's
always available to answer questions
and willing to help fix bugs and gnarly design issues.
DUSTIN KIRKLAND: Part of that globally distributed community
that we're all part of.
SAAD ALI: Exactly.
DUSTIN KIRKLAND: Well, thanks, Saad.
SAAD ALI: Cool.
Thank you very much.
DUSTIN KIRKLAND: Thank you.
[MUSIC PLAYING]