Hello cloud gurus. I'm Nigel Poulton and welcome to Kubernetes This Month
and here's how we'll slice this.
We'll do our usual round-up of the major news and events from the past month.
We'll pick a couple of those and dive deeper and we'll finish up with a chance
for you to win a goody bag through our guru of the month quiz.
So make yourself comfortable and get ready to enjoy.
First stop on a non-technical note CubeCon EU scheduled for the end of March in
Amsterdam has been postponed in the interest of everyone's health and safety.
The current word from the CNCF is that they're looking to reschedule around July
or August time and yeah,
this is bang in the middle of holiday season for a lot of the world.
We know what pulling something together like this is no mean fete. Now,
Encore Kubernetes betas or betas for 1.18 have hit the wild.
Now beta or beta means it's obviously early.
And of course we'll do a full inspection when it eventually goes GA.
But looking through the enhancements tracker,
end point slices might be in there as GA and there's work going on around
finally getting ingress into GA, though that might not arrive until 1.19. Now
sliding over to hosted Kubernetes GKS giving everyone more and more control over
the hosted aspects of a GKE cluster.
So surge upgrades gives you control over how nodes are upgraded and node
locations let you decide which zones in a region you nodes get deployed to.
Now looking at the bigger picture here, right,
we're seeing a genuine or a gradual trend of GKE,
giving us more and more control over our hosted control plane.
If you'll excuse the pun, sticking with GKE,
Google's brought back an old feature of sorts, right?
And it's not a popular one.
So after putting a smile on all of our faces a couple of years ago when they
eliminated the control plane management fee... Well it's back.
So as of June this year,
a control plane management fee of 10 cent per cluster per hour will come into
play.
And I guess that means it's time for me to get a bit more experience with other
hosted platforms.
Though Amazon already charges 10 cents per EKS cluster switching focus to
service meshes, there was more discussion again this month over Google,
still not donating STO to a foundation.
Now this story has been going on for a while now,
but it came up again last month.
Now Google effectively owns six of the 10 seats on the STO steering committee
and is supposedly blocking moves to donate. So the question is,
will this impact adoption of Istio in the long run?
And is it a sign of turbulent times ahead for the open source community?
As large companies look for ways to make a profit sticking with service mesh.
And on a slightly more positive note, Linkerd released version 2.7
where they strong security focus,
automatic rotation of TLS certs and integration of the TLS infrastructure with
external PKI providers. Top the bill of features,
cillium released version 1.7 with a load of features,
right at least one of which we'll be talking about in the deeper dive section.
CubeFlow announced a 1.7 release of the project that's dedicated to bringing the
cloud to machine learning or at least enabling machine learning engineers and
applications to leverage cloud resources.
The Docker index shows us some crazy stats for container adoption and we'll talk
about that as well in the deep dive section along with some findings from the
latest StackRox container and Kubernete's security report.
Now also on the topic of security,
hats off to Jeremy Gamblin for his hard work and his sleepless nights potting
together scan.vulnerablecontainers.org as the name suggests,
it scans containers for known vulnerabilities.
Right now there's a couple of API end points, but more coming in the future,
so thank you Jeremy. And last but not least,
Coreos Container Linux will officially go end of life at the end of March,
meaning it won't be patched or otherwise updated.
Now red hat are suggesting users migrate to fedora,
CoreOS but I'd just like to place on record a sincere thanks to CoreOS Linux for
pioneering lightweight Linux distros aimed at containerized apps. You know what?
It was massively influential and it can go to rest having accomplished some
great work and that wraps on news and events catch up.
Okay. In this month deeper dive section,
we'll look a bit closer at Cillium 1.7 And the replacement of cube proxy and
also some amazing stats from Docker tempered by some of the findings in the
StackRoxs security report. Okay. First off,
Cillium 1.7 Now the announcement of this release seems to have a ton in it.
I mean there's updates to the Hubble UI which helps you visualize and
troubleshoot, which also they've opened sourced.
There's cluster wide network policies that let you apply baseline network
policies to the entire cluster.
So crossing namespaces and everything sounds cool.
And then there's replacing cube proxy.
So cube proxy is a fundamental Kubernetes service that runs on every cluster
node. It's mainly responsible for the networking magic, right?
That gets traffic from a services cluster IP to pods behind the service.
Now, for context, right?
It's recently had an overhaul replacing IP table stuff with IPVs think faster
and more functionality. Anyway, that's not enough for everyone,
including cillium,
who've got their own thing based on E BPF think even faster.
Again, now look, don't get me wrong.
Networking is at the heart of most things,
especially in a cloud native micro services world. I mean,
there will never be a situation where you've got too much performance and
they'll never be an end to the fine tuning you need to do. So. Okay,
why wouldn't we want the best possible solution?
It's just that cube proxy for me, right?
Feels so core and so fundamental that switching it out for something more vendor
specific, even if it is better, I don't know.
It's scares me as well as that though.
They've got this direct server return thing that gets around some of the
limitations of normal Kubernetes services where for example, okay,
unnecessary network hops are sometimes incurred and we sometimes lose the
original source IP. Again,
it sounds pretty amazing what they're doing with this direct server return,
but I don't know, right.
Bringing nonstandard behavior even if it is better behavior kind of scares me
again. You know what, maybe I'm just not brave enough and I will say this.
It is cool stuff that they're doing. Okay.
Then Docker released some stats recently showing,
well just mind blowing numbers. So Docker hub is special.
The most popular container registry out there and docket inc of mind.
Some anonymized stats showing the rate of container usage.
So some headline numbers include over 130 billion with a B all time container
image, pulls, and that's just from Docker hub, right?
And it's ratcheting up at a current rate of 8 billion a month and growing.
There are 5 million hub users and around two and a half million installations of
Docker desktop, which if you don't know, okay,
we'll run a local Kubernetes cluster on your laptop for you now?
Okay. This is fabulous and all and it really is,
but apparently it could be even more. You see,
according to the latest StackRoxs container and Kubernetes survey security
concerns over containers have caused just under half of survey respondents to
delay deploying into production.
94% of respondents okay have experienced a security related incident in their
container environments in the last year. Now look,
I don't want to be spreading fear here.
I imagine a lot of them have also experienced security incidents in their non
container environments as well though of the security incidents and question
over 60% were apparently due to misconfigurations rather than code
vulnerabilities. Sounds like they need to train their people up.
I wonder where they could do that anyway. Oh yeah.
Over 60% also cited a skills gap or a steep learning curve as a major inhibitor
to deploying containers.
Sounds like they could do with some Kubernete's video training courses,
but you know what?
I think this wraps up our deep dive loads of container adoption. Right?
But it could be even more if we had more skills and more security.
Okay. Guru of the month.
Last month I asked which container runtime was based on the core container
runtime from the Docker project and the correct answer was container D.
now let me tell you, okay, every answer that we got was excellent.
No joke. In fact, I couldn't choose a winner,
so I flipped some coins and the coins said, Kartik Kumar,
you are our winner this month.
Kartik is a Dev Ops engineer from Bangalore in India. Congratulations.
We'll be sending you a goodie bag now. Like I said, right.
Massive thanks to everybody else. Your,
answers were immense and I could have picked any of them. Anyway,
thanks for getting involved.
This month's question is in the forum link below and as always I'll see you
again next month. Same cube time, same cube place.