BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Presentations Simplify and Accelerate Kubernetes Adoption

Simplify and Accelerate Kubernetes Adoption

Bookmarks
45:17

Summary

The panelists explain how to avoid underperforming deployments and prevent excessive cost, providing concrete advice on how to overcome game-stopping barriers such as Kubernetes skill gaps.

Bio

Lukonde Mwila is Principal Technical Evangelist @SUSE. Rosemary Wang is Developer Advocate @HashiCorp. Alexander Matyushentsev is Co-founder and Chief Architect @Akuity. Eric Goode is Certified Kubernetes Application Developer and Administrator @D2IQ. Renato Losio is Principal Cloud Architect @funambol (moderator).

About the conference

InfoQ Live is a virtual event designed for you, the modern software practitioner. Take part in facilitated sessions with world-class practitioners. Hear from software leaders at our optional InfoQ Roundtables.

Transcript

Losio: In this session, we are going to be chatting about how to simplify and accelerate the adoption of Kubernetes.

Let's clarify a couple of words, what we mean by simplify and accelerate Kubernetes adoption. Basically, Kubernetes deployment might suffer different operational challenges, including security, stability, governance, whatever you want, and how we're going to address them, how we can make that simple. Today's panel will explain how to avoid basically underperforming deployments, prevent excessive cost, and give advice on how to overcome barriers such as low skill gaps, for example.

Background, and Journey to the Cloud and to Kubernetes

My name is Renato Losio. I'm an editor here at InfoQ. I'm a cloud architect. We are joined by four industry experts, coming from very different background and experience, but all very much on Kubernetes. I would like to give each of them the opportunity to introduce themselves and share about their own journey to the cloud and to Kubernetes specifically.

Goode: My name is Eric Goode. I am a Principal Architect on D2IQ's professional services team. I come from more of a enterprise software background. I was a developer for about 17 years. I've been with D2IQ about four years now. I've been working to help people decompose their monoliths and get them into Kubernetes.

Matyushentsev: My name is Alexander Matyushentsev. I used to be principal software engineer, and now I'm a Chief Software Architect at Akuity. I'm a co-founder of the company. I've been doing social engineering for like 15 years. I got into infrastructure maybe seven, six years ago. My focus from the beginning was Kubernetes. I am one of the co-creators of an open source project called Argo, which we created in a startup company called Applatix. Then me and my team, we joined a bigger company, Intuit, where we helped to drive Kubernetes adoption, and Argo adoption as well. Most recently, we started our own company where we pretty much do the same, but now we're helping not one but many companies. I've been in this domain for quite a long time.

Mwila: My name is Lukonde Mwila, or you can also call me Luke. I'm a Principal Technical Evangelist at SUSE. Started off in application development years ago, and then transitioned into more of the DevOps and solution architecture space, specifically in the cloud environment. Did that for a couple of years. That's also where I had the opportunity to lead teams that were focused on building out Kubernetes clusters and administering them, as well as running different training initiatives for the banking sector, as well as consulting firms. Then eventually moved over into developer advocacy with a specific focus on the cloud native world. Yes, just to try to simplify the process of Kubernetes adoption for a number of developers in the community, operators as well, as well as just evangelizing some of SUSE's container management tech stack.

Wang: I actually did the reverse path. I came from a systems administration network engineering background actually, and got into private cloud. That's how I ended up learning about cloud technologies early on. I was working with container technologies, wanted to get more into open source, and decided I should learn development. I can tell you, I'm like a development dabbler. I'm not really the best software engineer. Since then I've done a lot of work with Kubernetes. A lot of it is content oriented, ran into production for a while. Then I decided, I could learn a little bit more. Now I'm a developer advocate at HashiCorp. I primarily cover Consul, which is a service mesh vault, a secrets management offering, as well as how they run on Kubernetes and how you use them on Kubernetes. I also work a little bit in infrastructure as code too. End to end, I get to see everything from Kubernetes and the infrastructure supporting Kubernetes, to developers who are deploying Kubernetes.

Speeding Up the Adoption of Kubernetes

Losio: Let's say my team has started working with Kubernetes, but you still don't have it in production, you have it somewhere. You have some environment running it. It is like, what should be the main worry? How can I speed up the adoption, and do the final mile or whatever?

Mwila: The first time I worked with Kubernetes, I did have a good understanding of container orchestration, because of working with ECS prior to that Kubernetes project, but there were a lot of people in the team that were brand new to Kubernetes as a whole. I actually think one of the first things you have to start off with is considering the makeup of your team. What's the level of proficiency around Kubernetes? That could definitely determine how you're going to go to production. In our case, we ended up going with a hosted cluster, because that would essentially take away the responsibility of managing the control plane and administering that as well as the data plane. That simplified the process for us in many ways, especially the other people on the team. Then as maturity grows, you can then move in a direction where you take on some of those responsibilities if you want to move away from a hosted cluster.

I think another barrier that you need to be very careful of would be the temptation to import someone else's solution into yours. I think everyone here on the panel would attest that there's so many tools and add-ons in the cloud native space. If you see a lot of shiny things in someone else's solution, and you just want to import those into your context, you're going to run into issues, because you've probably got a lot of discrepancies in terms of your use cases. Work from your own problem definition, and build out from there, and pick tools to support the solutions for your problem definition as opposed to seeing what someone else is doing and trying to import that into your context.

Goode: I agree with that. I think one of the biggest hurdles that a lot of enterprise groups find is getting to production is that they try to get the whole big bang go, and they try to get the whole thing done into microservices and get it in all at once. When if you really take a look at how Kubernetes is structured and use some of the tools that are there, you can do it incrementally and get into production incrementally and bring it in little by little instead of trying to wait for everything to be perfect.

Advice on Containerization, and When to Move from Monolith to Microservices

Losio: When do you start with container, and when not to, and when should we break monolithic towards distributed architecture? If you have any concrete advice or main guidelines will be really appreciated.

Wang: I think with monoliths, as an industry, we think about monoliths being bad, but they may not be bad. You may not have a choice but to run it. In which case if your monolith is an application that it's really difficult to decouple, you're not planning to make an additional financial investment to necessarily replatform it, refactor it, then probably not a good idea to try to containerize it. I think the joke was someone told me I want to containerize my COBOL application. My question was like, are you planning to refactor and replatform or you just want to take it and lift and shift it into a container? What is the benefit you get from that? What is the benefit you get from repurposing or replatforming an application that is a monolith, maybe you're not using all that often. Versus a monolith you're using all the time, you're making lots of changes, and you can't make changes without affecting someone else anymore. There's almost a cost of the time and effort to maintaining the application to a point where it's no good as a monolith anymore. In which case, maybe you start thinking about breaking it down into a distributed architecture.

The question to containerize, when to and when not to, tends to be, it's easier to containerize when you're moving toward a distributed architecture, when you're breaking down all of that code, and you're able to replatform it and rethink the way that you've written it in the first place. If your application isn't going to be used that often, and quite frankly, it's going to be running there, what is the point?

Losio: Basically what you're saying is the answer to this question is, even this question should come before simplify and accelerate the adoption. It should be, do I need to go that step? That's the very first.

Goode: I think it's more of an art form than a science, though. It's like determining where your trouble spots are, and what can you pull out?

Losio: There's not one single answer that fits.

Matyushentsev: I feel like I wanted to address the question as when to start using Kubernetes, and if you decide to start, what to look for. I really like to promote the idea that you have to define your goals first. Basically, I started myself playing with Kubernetes because it was a new shiny tool, and I just wanted to give it a try. Then only a few years later, I think I realized what the whole purpose of it was. In my opinion, it's the tool that let application developers to manage infrastructure without creating tickets. It was really eye opening for me. If you have a problem in your company that your engineers could be more productive by changing YAML files, as opposed to creating tickets, then Kubernetes is a good tool, and you would have to containerize to use Kubernetes. I think it's a good enough reason, if it improves velocity, and teams can deliver more frequently, and quicker, then maybe it is worth to consider containerizing.

The Skills Gap in Kubernetes Mastery

Losio: One topic that I see recurring over is the topic of skill gaps, and the fact that not many people know Kubernetes. It's something that people should learn more. Companies complain that there's not enough knowledge. My first feeling is, is that really a topic? Actually, does anyone in the development team need to know Kubernetes or care about Kubernetes? Sometimes I feel like I'm a developer, I want to build my application, and should almost abstract myself from that. I was wondering if anyone has any feeling about that.

Goode: I teach one of our CKAD preparation classes. I always get that question right at the very beginning from the developers, why do I need to know Kubernetes if all I'm going to do is check stuff into Git, and it's going to get built by a CI/CD system? I'm never going to actually log in or see Kubernetes. The answer to that is understanding what Kubernetes brings to you, things like service discovery, and config injection, and networking, and load balancing. All these things that you get for free with Kubernetes are things that we had to code for in the past. I come from a pretty heavy Java background and we used a lot of the Netflix stack, and we were using things like Eureka, and Ribbon, and all this to accomplish things that Kubernetes gives us for free and we don't have to put that in our code anymore. We can simplify our code. We can just bring our containers and we can run it and take advantage of those things. I think understanding as a developer how Kubernetes works and what things as a developer you can take advantage of that you don't have to code for is very important.

Mwila: Just to piggyback off what Eric was saying, I think contextual understanding of what Kubernetes brings to the table is a big part too that plays a role for developers. On the other hand, I do think, it's more contextual than technical. Something that I've been seeing happening a lot to the frustration of application developers is they're becoming cross functional in their roles within themselves. They're feeling like why is it that Ops is now being forced on our plate as well. I think that teams and companies just need to manage that well to make sure you develop a good workflow. Some of it might stem from a misunderstanding of what DevOps should actually be. Because application development, and that's something that I've done, it's a beast in and of itself. It's very involving. You just need to make sure you understand what responsibilities are being put on the developer's plate when it comes to the Kubernetes world. I think more of it should be contextual than technical. I think other operators and DevOps engineers can be involved on the technical side of things there.

Getting Hands-On with Kubernetes

Losio: Let's say I'm a developer that knows Kubernetes there, but I want to get really into it. I want to start to get my hands dirty, and I want to play with it, and I haven't paid much attention on the operational side. Until now, I just know the idea behind how it works, but I don't know tools. I haven't used it myself. What should be the very first step? How can I start that?

Wang: Your security team may not like this very much. If it's within your organization, explore what you understand in the namespace that's provided to you. If you're a developer, you're probably going to be constrained to a namespace. Understand what's running in that namespace. Ask your Ops teams questions about, how do certificates work? How does load balancing work? Is there something special with some of the tools you're using? The other way to get hands-on with it is start from scratch. It's fantastic in Kubernetes where you can spin things up locally and try things out. It may not be representative of your application or your enterprise or organization situation, but it's a good way to get hands-on and go from ground up. This is how you understand Kubernetes and networking. How you understand how it's handling security, whether it be certain segmentation, role based access control. There are a lot of tutorials now that go at it from the hard way, and that's the first way to just get into Kubernetes and learning all the ins and outs.

Matyushentsev: Kubernetes is meant to empower engineers. Basically, platform team has tools to put boundaries in place, and basically they protect you from shooting yourself in the foot. That's why if you get access to Kubernetes, I think you're free to experiment, unless you already run the application in production, you can just do whatever you want. If something is not allowed, you will get a 401 error, basically. You get way more freedom to experiment as opposed to if you have access to AWS account, for example. My advice would be to try to continue to apply something, see what happens, and play with and get your work experience.

Learning Kubernetes, for New Developers

Losio: I was wondering about that. That's something that bothers me as someone that is familiar with Kubernetes, but I don't use it on a daily basis. Even as you just mentioned now one cloud provider, I was thinking even if you limit yourself to one cloud provider, you want to try something. There are basically now so many ways to write Kubernetes, I'm thinking about AWS, but Google, Azure that you almost don't know where to start, how to choose. Which one is the, not easy, but maybe a starting way for a new developer?

Mwila: I think you pretty much got about three different options in a cloud environment, four if it's AWS's case. You have a hosted cluster, so that takes away control plane and data plane, and then you're responsible for the worker plane, or you can go fully serverless where you're just focused on your application, all of that is taken away. Then you can provision a cluster yourself, just take on the compute resources in a specific cloud environment and then provision it. The fourth one, obviously, in the case of AWS is EKS Anywhere, where you can have cloud and on-prem. Just based on those different models that exist, and you're just starting out, make your life a little bit easier and go with the fully serverless approach. Because that way you get to test out just deploying an application and what's involved in deploying an application while you're still learning the architecture from a theoretical perspective. Then as you start to get a better understanding of the nuts and bolts of the architecture, you can take on additional responsibilities like the control plane and data plane, and then go all the way and provision a custom cluster by yourself and break things and run into issues. Just work on the easy way, upwards. Of course, if you want to do it the other way around, no one's stopping you.

Goode: I think it really just depends on how you learn as yourself. I know I'm a very much a learn-by-example type person. I can go out to YouTube and watch some videos and pick this stuff up, and then launch Docker Desktop, or Kind on my local laptop and just run things. Those are good options if you don't have access to a cloud platform. A lot of people don't. Signing up for one of the free trials with the cloud platforms is also a really good way to go. Taking a class, like there's a lot of great online classes through different providers like Udemy, and things like that, are a great approach. Or you can take an in-person class. We offer monthly in-person classes they can sign up for, and you get me as an instructor, and you get to go through and have somebody that you can interact with and ask questions. It really just depends on how you've learned, picking the right approach for you, because otherwise, it's not going to stick. You're not going to continue with it.

A Platform Team, and a Tool's Cognitive Load

Losio: I tried to do my container, I containerized a project and I ended up learning so many things that is good, but at the same time it is pretty not bad. The question is just to try to understand how much cognitive load is good in the name of using any tool. I think we're back to the problem, it's like, I need to gain something out of it. Yes, I'm not going to adopt Kubernetes, actually, it's valid for any tool just for the sake of it, hopefully. Should I have a specific team to handle it? Any advice or any comment on it?

Wang: Despite coming from some networking experience, I wouldn't say that I'm an expert in it. I rely on a number of better network engineers than myself. I think functionally we have to strive for good enough knowledge. We don't know what knowledge we need to use. For example, you could be debugging something on Kubernetes and it could be legitimately a networking issue and you wouldn't know, and you wouldn't have the deep knowledge to do that. I think that it is advisable to have a platform team or some specialist who has a little bit more knowledge in Linux networking security, to give you advice and to help you understand that. We should all be empowering each other, just as much as a security team needs to understand how a developer is using that platform. What are the common patterns? We don't want to be blocking people from deploying, but we do want to be secure. Each group has to learn from each other. I think that's the most difficult part of it. Yes, it does help to have a platform team with specialization.

Matyushentsev: I feel like it's inevitable, you would have to have a platform team. The reason is, even if you use a managed Kubernetes, it's not 100% managed, you still have to make a set of choices to figure out how you're going to manage load balancers. Maybe you need to provision certificates, and even lower basic things like how networking is going. Someone would have to run those projects, and that's usually a platform team. More of these, I think, maybe taking care of big cloud providers, but we're not there yet. I would recommend to focus just on learning what you would have to learn anyway. The whole idea is that engineers actually use Kubernetes directly, not through some abstractions that abstract Kubernetes away. Kubernetes is abstraction itself and the basic primitives of Kubernetes such as Pods, ReplicaSets, Deployments, I think we will have to understand like all of us. Even if your focus is building applications, it's inevitable that in the future you will have to deal with these basic Kubernetes primitives and you will get a lot of advantage if you understand it.

The Role of Tools in the Adoption of Kubernetes

Losio: We keep talking about Kubernetes, and then we talk about adoption and how to accelerate adoption usually different tools, different vendors and different option come to mind. Of course, it gets more complicated, because if you have no knowledge, you don't know. Which tool, or do tools help? How do I choose a tool? One of the benefits of Kubernetes has been to see as well almost no vendor lock-in. I can move from one provider. Will tools help or is that a risk?

Goode: I come from the software engineering side, the enterprise side. Yes, that's one of the big questions that's always asked on that side of the table, what's my risk of vendor lock-in? Am I going to get locked into a tool that I can't get rid of two years from now when something else comes along? I think the important thing is when you're picking your distribution, when you're picking your tools, pick stuff that's standard open source. You're not dependent on a particular vendor's documentation, you can go out and ask the wider community. You can go back and open pull requests, if you want to make a change or do something different. It's really important to stick with a distribution that sticks as close to the open as possible. Find a vendor that its tools are mostly additive on top of the open source versus putting their own container network interface in place or putting their own storage behind the scenes. That way, you don't get locked into those kinds of things. Then when the new great thing after Kubernetes comes along, then you pick your containers up and you move to the next thing.

The Future of Kubernetes

Losio: I liked the last comment you made because actually it was one of my feelings about that as well, is like, yes, now we are all into Kubernetes after actually many years. It is like, are we still going to talk about Kubernetes in 5 years' time, or in 10 years' time? Or it will become some standard, or it will be entirely replaced by something else.

Matyushentsev: I don't think Kubernetes is going away very soon. I hope at some point we stop talking about it because it became a boring topic. Then that would mean it became stable, finally. The ecosystem is not changing that rapidly. I think it will be a good thing. In regards to choosing the tools that you run on top of Kubernetes, I agree 100%, that you should choose open source. An open source tool that solves a real pain, it has a very high chance of survival, because if one company steps away, then someone else pick up and you still have a whole community around it, and it's not going to just disappear. If you choose a very nice tool that is run by a small startup, and it's not open source, the startup can get acquired by a company and you lose your tool. Take a look at CNCF landscape, it will be overwhelming, but you will be looking from a very good set of tools.

Losio: Do you agree as well that it's going to be boring in a few years or do you have a different view?

Mwila: I think right now, one of the reasons why it's being spoken about so much is obviously the excitement and the buzz. I can attest that, in my context, specifically, there's a lot of excitement. I would argue we're probably on the tail end compared to adoption in other parts of the world because of a skills issue. The excitement might take longer to wear out on my side of the world compared to other parts. Another thing is, I've seen how there's more attention being given towards best practices now, which is a good thing. Now there's a lot of talk around security around Kubernetes and containers. I think that that is also what's going to have the discussion last a little longer, because it's going to catch up with the excitement, which is what you want. Then there'll be more talk around the best ways to implement Kubernetes, because I think right now, what's leading the race is still let's adopt Kubernetes, and best practices is still far behind, so you want best practices to catch up to that, if not overtake it.

The Kubernetes Adoption Curve

Losio: You're basically saying we are still in the, not early phase, but still in the phase where it matters to run Kubernetes. The how and the best practice are still lagging a bit behind. Being this on a roundtable from InfoQ, there's one common concept that we use is the adoption curve to see, at the moment, do you consider Kubernetes something for early adopters still, or early majority, or is that, everyone is using it? Because I have to say on a personal level if I go to a conference, I had a feeling, everyone is using Kubernetes. There's not anyone left that is not using. Then when I dig through a specific company, you have the feeling that, maybe it's not really the truth behind. There's something maybe there, but we are not there yet. Do you have a feeling where we are, or what do you think?

Wang: At least in my impression I get is early majority. I think part of it is also regional as well. Depending on how you've developed all of your technical architecture up to this point, you may or may not choose to adopt Kubernetes. For some folks, they've moved off of Kubernetes already, or they've evaluated Kubernetes, then they've said, this just really doesn't work for our particular use case. At least in my experience, it's mostly early majority. There are some folks who are using it really proficiently, and for very advanced production workloads. For even the long tail folks who have gone even further in the Kubernetes journey, they've actually moved off of it, and some have just started to adopt. That's why we categorize it there.

Goode: A vast majority of people are using Kubernetes. It seems like there's not a huge number that are actually in production for their frontend type applications. Where I'm seeing a lot more adoption and a lot more what I would call production type applications, is in things like software factories, and AI/ML, and things like that, where you're still using it as a development tool. You still treat those systems like a production system, your CI/CD system as your developer's production system. That software factory and running all those things internally is a really good first step to learning Kubernetes, learning how to operate in production, and learning how to secure it, and then take that to your customer driven apps or your customer facing apps.

Losio: I was wondering, with Luke's experience as a developer advocate as well, if you see anything different internally or externally, in terms of adoption.

Mwila: Yes, not necessarily. I think, pretty much just echoing what Rosemary and Eric have said as well. I think I implied to this earlier, in part it's a contextual thing. In some parts of the world, I think there's a lot of adoption. There are some great use cases, you can even find them online from CNCF events, teams that are running I think, well over 500 clusters. That's fantastic. That's a testament to a high level of proficiency. At the same time, you have a number of examples of teams that probably shouldn't even have adopted Kubernetes to begin with. I would argue that it's probably early majority, as well. Just goes back to what I said earlier as well, lots of excitement. Some people, unfortunately, are leaping before they looked. They even say, 'everyone' is using Kubernetes, but they actually haven't worked from the problem definition. Does this actually solve our issue? I love using the example of, in many cases, if you have an event driven architecture, maybe you could have just used Cloud Functions to solve your problem, as opposed to going with something as robust as Kubernetes. I think time will trim things as well, in terms of the number of people who have adopted it as well.

Losio: Very interesting point as well about the pattern that might actually advise against using Kubernetes.

Matyushentsev: I think I'm a little bit more optimistic about Kubernetes. Kubernetes is not a product, it's a platform that you can use to do anything. Then, if you are lucky enough and your use case already is implemented by some tool on top of Kubernetes, then it's really easy to use it now. New tools get created and more use cases get unlocked. I believe in the future, we will see more tools that focuses on a particular use case. Hopefully, we will finally get a shiny CI tool that is built on top of Kubernetes, and it's like, it will be at GitHub Actions, and Jenkins, and then finally, people will move and use Kubernetes for CI. Then, there are more examples of such use cases. I agree that ML and data processing use cases also, because basically you need an orchestrator that updates and delegates compute resources. Kubernetes can do a lot, basically. It's a generic orchestrator that can orchestrate all kinds of things. I believe we will see more adoption, and it's just beginning.

Common Mistakes to Avoid When Deploying Kubernetes

Losio: I like to go back a bit to the topic that Luke raised before about best practice or whatever it is. I'm thinking, if I have a running Kubernetes, if I think one or two common mistakes that people do that they should fix, action item they could do to usually simplify their deployment, improve their deployment. I know that best practices vary according to industry, according to size or whatever. In your experience, what are common mistakes or things that people should take care of?

Goode: One of the things that we see a lot, is a lot of the tools out there are very imperative. You go out, you run a command line interface, you launch your cluster, everything's great. This leads you to the whole Snowflake server problem, like all over again. Martin Fowler has a great article out there called The Snowflake Server, where any time somebody touches a server separately, you got to remember to make that change everywhere else. There's a newer product out there, or open source project out there called Cluster API, which is the basis for our distribution that allows you to make that more declarative. Everything's just objects, you can store it all in GitOps. We have a customer right now that does all of their clusters through GitOps style. It's just a check in, in Git. Flux picks it up, moves everything over. All the Cluster API objects launch, and everything goes. Then you get the whole safeguard of if things are checked into Git, if somebody makes a change, I can go in and look at that Git history. I can look at that commit history and see what changed, instead of somebody running a command line interface, or jumping on a server and making a change. One of the best practices that we're really starting to see come out is to make these clusters themselves declarative and make them clusters as code and using GitOps to do that.

Wang: When you first start operating Kubernetes, and you're focused quite a bit on production delivery, you omit a number of security practices. It's hard to justify slowing down your delivery pace in order to focus on these delivery practices. For example, deploy in a secure network, if you can, in a private network, if you can. Apply role based access control, if possible. There's a balance between the two, but identify what's the minimum from a security perspective that you need. It's really hard to go back and lock some of these things down after the fact, after you've started running in production. Sometimes you take more time and possibly incur downtime to applications running on the cluster, because you've gone back and you've locked something down, and you haven't fully tested it end-to-end from a security perspective. There's a number of minimum lists that you have from a Kubernetes perspective, from a cloud security perspective. We're not saying go for industry benchmark level, like CIS level 2, which is the U.S. security benchmark. Start with a minimum list, and start earlier than later, and it will help you accelerate your adoption without necessarily compromising that much on security practices.

Losio: I was wondering if you have some advice or do you agree.

Mwila: Yes, 100%. A big one, again, just what I'm seeing is there's a lot of attention being given to what are the security best practices around this because there is excitement to adopt it, which is great. I love trying to evangelize security best practices as much as I can to teams, and companies can accelerate that adoption process. Just recently, I was presenting to different companies, and one of the people in that room asked, "How will Kubernetes and containers strengthen our security posture?" I chuckled to myself, and I said, "It won't." People's faces fell, I'm like, "It's insecure by default." I just went on to elaborate. I'm like, these are its strengths. I know everyone's looking for that tool that does absolutely everything, but these are its strengths. We don't throw the baby out with the bathwater. We just put the relevant defensive measures around it. Especially in my context, that's something where there are companies who are really concerned and so they typically have red tape. For example, financial services sector. They're reluctant to take on open source software, but we don't want that to be the case. The open source ecosystem is highly innovative, just look at the tools and technologies we're talking about right now. Sometimes what can strengthen the argument is to have good security best practices around things like that.

Security in Kubernetes

Losio: I was wondering, as everyone is mentioning security, do you see security in Kubernetes something like easier, harder? I don't expect that is out of the box, or a magic solution that Kubernetes is going to fix everything, but is doing security in Kubernetes easier?

Matyushentsev: I think Kubernetes helps you with security simply because you get a database that has information about pretty much everything, all the infrastructure that you manage. I think security teams should be happy because they can query the database and get real time information. Plus, they have a choice to inject security measures. A simple example, you can just say, no, we do not run privileged containers ever. That's it. You improved your security, and you can do it centrally for everyone. You have a chance to do it afterwards. Once adoption happens, you can discover that maybe you missed something in the beginning and you want to tighten that security. You don't have to chase teams, you still have a single control plane where you can put those things in place. I do feel like Kubernetes helps with security. You get a little bit increased maybe attack surface. For example, before you would naturally separate your tenants of your cloud, and everyone runs in a separate machine. In Kubernetes, most likely they're going to be neighbors, and we'll be running containers on the same machine. You do have options to make even that secure.

Losio: Do you agree with Alexander, or do you see differently in terms of security in Kubernetes?

Goode: I actually agree with both Alexander and Luke on this one. It's a matter of picking the correct tool for the job. Kubernetes is not super difficult to secure. It almost comes clear back around to what we said earlier with developer training and making sure developers understand that you don't want to use NodePorts unless you have to. You should have a single point of ingress using an ingress controller. You should do things like don't use host paths, because they can be inherently dangerous. You need to put Gatekeeper policies in place to make sure that people are setting their users correctly. There's a lot of best practices that are out there. Like Luke said, it's open by default to increase adoption, and then it's up to you to lock everything down. Learning those best practices is a really big step towards securing it.

The First Action Item on Starting the Kubernetes Journey

Losio: I attended this roundtable. I'm a developer. I'm very happy of what I learned. I want to start tomorrow, my very first step. I want something that I can do really tomorrow, a couple of hours, or whatever, how can I help my team start this journey? What should be the very first action item? Do you have any action item that I can really do immediately until I have the enthusiasm?

Wang: I think one of the things is start looking at what interests you in the Kubernetes community. There's a lot of use cases out there. Kubernetes supports a lot of different workstreams and working groups as well. Find one that's really interesting to you. It could be something creative. It may not be your day to day. It might be something like Cluster API. It could be something like Open Policy Agent and Gatekeeper because you want to improve your security posture. Just look at it, examine it, and find out ways that the community is innovating on something that you're really interested in.

Mwila: Just jump right in. If you can download, whether it's Docker Desktop, minikube, Rancher Desktop, you name it. A lot of developers are usually tinkering, and they probably have some example application, figure out how you can get that running on Kubernetes.

 

See more presentations with transcripts

 

Recorded at:

Sep 08, 2022

BT