 Her company and From admin control from admin control give it up for Christina, please Thank you. Thank you. All right. Hello, everyone Cool to see that you found the time and to join me today on day One of Kubernetes community days Amsterdam I'm gonna talk about day zero of adopting a managed Kubernetes service and for those who may not know what a managed Kubernetes service is this is basically a offering of creating Kubernetes clusters in cloud for example in GCP or Asher or AWS and what considerations you may need to take when you decide to adopt such managed Kubernetes service offering a Few words about me. So as I was nicely presented My name is Cristina de vodka. I'm based in Oslo, Norway and Working as a software architect and have been working with Kubernetes for more than a four years now I am also a Microsoft Azure MVP and apart from my full-time job. I find it really Giving and fun to contribute back to the tech community. That's why I am here today but if we get back to Why we are here This session came to life because I have been working in the projects That where we have been adopting a managed Kubernetes service and one of the projects where I was involved we actually At some point I had to postpone the production rollout of our workloads Hosted on managed Kubernetes service and in that case that was AKS Which is Azure Kubernetes service and offering from Microsoft and we had to get back to the table and do adjustments in order to make that production rollout Really of high quality and efficient and this was also based on discussions with other teams in other organizations that we've had and The things they wish they knew During the initial phase the adoption phase of managed Kubernetes service Which made this session came to life to raise a bit more awareness about this and you can see some of the questions here that many organizations and teams may be having that could also be related to the Existing misconceptions and expectations that we may have to cloud service providers and you may think that if a Kubernetes service offering is managed then a lot may be pre-configured and hardened and Secured in a good way so you might not need to do and Invest as much effort and time and resources as you would guess But reality is a bit harsher than that and I forgot to say that I like cats So you may see quite a few cat pictures here. So bear with me But the answer to many of these questions is actually no you will need to do quite some effort in order to ensure that The managed service the managed Kubernetes service is actually of enterprise scale and production ready When you deploy your workloads on it and to set the scene I guess the most important Misconception that is important to clarify is if managed Kubernetes service is a platform as a service offering And the fact is that it isn't if you for example go to the official documentation from Microsoft for AKS There it is stated straightforwardly that the that AKS is not a pass offering Even though cloud service providers do manage And secure control plane of the Kubernetes clusters we create for us We still have a high level of responsibility in terms of Keeping up to date secure properly configured the worker nodes where our applications will be running And we will also be responsible for updating those nodes those clusters Including the control plane because cloud service provider will not do that for us So we end up in that important concept when it comes to using cloud solutions, which is shared responsibility model The cloud provider does have a high level of responsibility But so do we and this is also applicable for managed Kubernetes service And in order to be able to execute upon that responsibility We need to understand how Kubernetes works and how components in the Kubernetes ecosystem Hang together and which tools can help us do it in a good and agile way And that's when another question that raises a lot of discussions these days pops up if Kubernetes is hard and I could say that from my experience and the experience of the teams I was working with I could say that this isn't Kubernetes is not necessarily hard, but the learning curve is quite steep and You need to ensure that you are not the only one Having that competence and knowledge in how to maintain Kubernetes and workloads running on those clusters so that others can step in in case things go wrong and that's when they zero phase comes into picture because We do talk a lot about day two operations and what will happen when we have our workloads up and running on Our Kubernetes clusters and they are in production and our customers and users start using it But I do believe that it's equally important to raise awareness about day zero Phase which is that design the architecture and planning phase of adopting Kubernetes and manage Kubernetes service as well and there is a saying that Rome was not built in a day But they were laying brick by brick every hour I guess that's more or less the quote and that is applicable in case of adopting Kubernetes as well You cannot implement everything at once in a day and the approach will be layered Where you work brick by brick and build That mature technical platform based on Kubernetes, which will be which will be production ready But if we get more concrete, I have only half an hour Normally, I do have at least an hour to go more in depth and maybe even show some demos But it will be highlights of the highlights So what should you think about before going all in with a managed Kubernetes service? And I want to start with maybe the most important piece the piece The first brick that you would start with that is very important And that is the readiness of the applications that you want to migrate to Kubernetes and We do hear quite a lot of success stories about companies that have migrated to Kubernetes To manage kubernetes service in cloud and kubernetes can be a good candidate for lifting and shifting your legacy applications But if we deep dig down a bit into those success stories We get to see that they were able to succeed because they are systems their legacy applications were already Relatively distributed and they had a collection of lightweight Microservices which from before had all the necessary prerequisites to be able to just migrate them to kubernetes and Get that quick and fast scaling fast time to market more or less Out of the box, but if you have a legacy application that is heavier that is Potentially more monolithic that takes some time to warm up then Lifting and shifting to kubernetes may not resolve those challenges for you And here is an example if you think about the image size if you decide to containerize Your application you need to think about the container image size in the end it would contain Include the base image the security patches and updates that the owner of the base image pushes out Continuously and the size of the application code itself So if you have a monolithic legacy application that is running on dotnet framework 4.8 For example, it's five to six gigs in size just the base image And then you have the updates a few gigs in size on top of that And then you have the application code with a few gigs size on top of that so you may end up in a Container image of size 10 to 11 gigs and if you put warm up time on top of that And then you put that in a kubernetes cluster and try to scale you can imagine that you will Definitely not be able to to get that in an efficient manner So you would need during the planning stage evaluate how your Current application architecture is can you move Things out and if there is any refactoring that needs to be done And another important point is the technology strategy that you have long term Are you gonna be working with a single cloud? Will you have multi cloud approach or will you have a hybrid cloud where you have also parts of your workloads running on premises and This will also define which kind of tools you will be choosing going forward that may need to be cloud agnostic for instance And kubernetes may not always be the answer for you or at least the managed kubernetes service So if you have a single instance of a monolithic application, for example kubernetes will definitely be an overkill So or if you have just a small amount of microservices one or two Just maintaining and operating those clusters those worker nodes would be an overkill So you could consider something like serverless kubernetes offering where cloud providers do also Manage the worker nodes for you It is more of a black box solution and you may have limitations like you don't get access to a Kubernetes API server direct access to it But this may be enough for your case what the serverless kubernetes offering can can get you so this is important to look into and See what would be the most the most optimal choice for your for your use case and how much time you may need to prepare Your applications before eventually migrating to a managed kubernetes service and from application readiness We move more to a people question. We move move more to an alignment in the organization and another important equally important Consideration you need to work on is organization readiness and See my awesome design skills. I made this animation just for you today the quote that Some organizations maybe the leadership can often fall into is that we should do kubernetes because Spotify does it or because so many other organizations Do it and succeed with it and because this is hot. This is what everyone is talking about But using that as the guidance is The wrong reasoning for why you should be adopting that and this is important to talk about and align And I think that kubernetes has a really good quote about it that kubernetes management requires making cultural shifts on steroids and that is true because this is not only you who will Who may need to work with those kubernetes clusters and maintain them? In in the long term you would need to ensure that the developers also understand how this will affect their daily work You also need to understand that you may not see Cost optimizations from the beginning or likes the that it will be cheaper than it used to be from the beginning It may be a long-term investment What we have seen in one of the projects is that we had applications that were offered both in cloud and For our own premises customers and when we decided to adopt Managed kubernetes service we had to do changes in the application and the way we deploy which affected on premises customers Directly and we assumed that the changes are of no significance. I mean they can just fix it They can set up what's needed in the infrastructure to adopt for those changes But when our customer success teams and sales teams came into picture We realized that alignment was missing there And we used much more time to ensure that those customers are properly prepared and Negotiated with them in order to ensure that they were also okay with these changes If we did it from the start if we ensure that the sales and customer success teams also understood how these changes Technical changes will affect them. We would have used much less time. So it is important to during the planning to think about will adopting and changing to Managed kubernetes service bring value to us in our daily work and to our customers or would it just create more complexity and frustration and Also align it across departments and collaborate from the start and during the whole journey and the important part of the organization are our dear developers and They may be affected and it's important to ensure that you also have a dialogue with the developers And also remember about making it easier for them. So the Thing to have in the back of our heads when we are planning for doing such a shift is that we should still Aim for reducing the cognitive load on our developers and not introducing more complexity and if we Deliver the responsibility to our developers do not create tools that can make it easier for them To understand how they can containerize the application in a good way and prepare it for kubernetes This is what happens. It is blurred, but it does not matter here So what you can see here are two applications to microservices That's did not have any resource and request limits set at all and They sneaked their way in into the cluster Fortunately, this cluster was not a production cluster But what you can see here are lots of pods in the evicted terminating crash loop back of state this caused quite some chaos and almost a cardiac arrest for some of our operations resources and This is not the developers fault. They made there are so many components and things you need to think about And if you haven't worked with Containerization or orchestration before and are just a developer you cannot possibly remember all of those points So creating making it easier for the developers creating Tools that could make some of this configuration out of the box can really make their life Easier so during the planning phase. It is worth looking into how you can Abstract that complexity away from the developers and we have seen also that Just providing the links to the documentation or to tutorials was not enough But when we had those hands-on workshops with concrete scenarios, okay, we're gonna containerize this application now Let's do it together and you are doing it live together with them we have seen this giving the most value out and this is definitely something worth considering and also having the Automated checks that could ensure that such sneaky applications with missing resource and request limits will never be deployed To a cluster and will be gated automatically is definitely worth looking into from the start And we have also seen that having production like Clusters could really help to ensure that you are also testing Your applications with the same level of configuration as it is in production And this has proven to be really useful for operations resources as well and lastly We do hear a lot about github's these days This is kind of the golden standard of deployment to Kubernetes where you have your source repository as a single source of truth And you have that model where the cluster pools changes every time the Ryan it changes being merged But I think it's also important Like Shakespeare potentially said to github's or not to github's that is the question It's important to say that github's will not resolve the bottlenecks You may have in the organization currently So if you don't have in a high enough level of automation to ensure that you have the Automated tests the automated security checks and gates in place from before That github's will not help you resolve it. It may create more more challenges So the point is that you should know that you can always start without github's from the start with the starting with the bare Minimum and building that maturity over time as you evolve and get more skills with Operating kubernetes Another important point that we have heard about today also during the keynote is the cost and how to ensure that the cost is actually under control and This is interesting because I find that CNCF had a Survey last year and it was discovered that 68% of respondents Reported a kubernetes cost increase and more than 20% have said that the cost increased during the last year and with the Disturbing times that we are in now with a high focus on cost It is important also to plan for the necessary tools and Investigate the capabilities that are there in in the cluster or in the in the cloud from the cloud service provider that can make you create a Manage the kubernetes clusters in a cost efficient manner from the start and here are some Some opportunities that that you can see here and we had also a session about cube green earlier today Which is also a relatively new tool that can help you Sleep and Create more and decrease the amount of pods in the cluster based on a specific schedule This will also optimize your costs and what is a great consequence out of that when you have Focus on building efficient and cost optimized platform You also utilize resources to their max potential and end up in building and more Sustainable and greener solution and having policies that can again have Help you control that daily budget can control sudden increase in cost could also be extremely Beneficial and also see the trend With cost management tools like cube cost for instance and again one of the examples we had just last week There was an issue on the cloud service provider side which costs some of our installations of the extensions or add-ons Ending up in a hanged state and we were using private endpoints for communication and what this ended up with is 24 7 10 instances we're sending this Failing requests through the private endpoint which takes money for the amount of inbound and outbound traffic And if we didn't have alerting we might not have discovered this straight away. We might not start Doing the remediation and we may have ended up in Going long over the budget and having that budget limit that also alerts you if you keep doing like this You will end up so so much over budget Having that could really help you and make your leadership happy as well Call savings is always cute and Here is also one of the examples that I took from Asher that is also worth keeping in the back of your head Here you can choose the The nodes for your Kubernetes cluster for AKS in this case with either Windows or Linux operating system And you can see if we take a look at the first row here This is the type of the virtual machine which is D2S V3 if you choose with Linux You will need to pay seventy eight dollars But if you choose with Windows you get almost double you will need to pay double as much and this is also worth thinking about When you are deciding which OS you need to use and what type of workloads you have Another example is the region here is a comparison of North Europe versus West Europe and versus Norway East And these are Norwegian Croners But if we convert it to two euros if you choose a B2S, which I highlighted there, which is also a virtual machine You if you choose North Europe you would need to pay two hundred eighty Croners versus 300 or 339 for Norway East if you can use a region that is potentially cheaper not to violating any Laws privacy laws and compliance frameworks. That's worth considering And now Getting trying to cover it quickly. Can we cover it quickly? We can't so let's talk a few minutes about security and The trap here is that Kubernetes is not built with security by default What do you think these numbers represent? And his ideas What what? CVEs. Oh, you are right on top there This is the amount of exposed Kubernetes clusters worldwide that as you can see In June 2022 cyborg research lab did a scanning worldwide on the most known endpoints that can Kubernetes clusters expose and this is not that far from a million clusters worldwide. This is insane and In some cases if you think again as I've been Mainly working with AKS. So I know most about it by default its API server is Searchable by default so you can you can reach it you get an Unauthenticated response back, but you still have that attack surface that attackers can check and work towards so having that in mind starting with these most crucial steps like Limiting access to your cluster following the least privilege principle Ensuring that you have our role-based access control in place. He is important and also running containers as root We know that this is a no-no, but it is not always easy. Here is an example of a dotnet core sp.net core base image that actually does not provide possibility to run with as Non-root by default so you would need to make some changes in order to accommodate for that and Implementing security checks should happen continuously During the whole development lifecycle process and fortunately some frameworks out there could help us achieve that and It's worth looking into those frameworks from the start because customers will keep running and some of them are really curious and they Would need proof that your new solution is compliant with those frameworks And what is good is that some of them do provide concrete examples on how you can mitigate and implement this and that security control Lastly quickly quickly in two minutes. I'll I'll do that I'll still try to sneak in a data operations here and the fact that things will fail And this is also something that is worth thinking about and planning for from the start This is an example of an outage in one of the regions of AWS that happened both in December 2021 and July 2022 where multiple big services were experienced downtime This is an example of a faulty update that Azure has rolled out to their Linux virtual machines that also caused quite a few outages and especially a chaos being Affected a lot by that. So having that disaster recovery and important things like Observability multi-region deployment even chaos engineering which could help you simulate these situations would really help and Don't rely on cloud vendors and having operations team that will take that responsibility work with it from the start would Really be worse the effort in the long term than them figuring it out once you are up and running in production And this is how you deploy a container on Kubernetes in 30 minutes. That was my session session today So summing it up now. We're getting close Do the change for the right reasons do? Adopt Kubernetes and manage Kubernetes service if it brings value to you and your customers Do not underestimate the day zero the planning stage to ensure that you don't need to get back and do a lot of rework afterwards do invest time in that Start small and expand building brick by brick with everyone who needs to be involved by to build that mature platform Have that common ownership so that you will not be the only one Operating kubernetes because then you can't be sick or go on vacation you would need to have others understand kubernetes understand how Everything works in that ecosystem so that they can step in shift left not only on security on everything and Prepare for the things will fail and my hearty recommendation to not forget the resource and request limits If you don't want if you want to take care about your kubernetes administrators And once you have done all that you are good to go. You have a full operational Kubernetes clusters running in cloud or elsewhere You get all the resources in this github repo if you want to Find more about it and do reach out to me and if you have any questions I'll be happy to help you out either here or after afterwards. So Thank you Thank you Christina is is absolutely true. Rome was not built in a day and was built brick by brick, but it was broken down Does anyone have questions for We have 15 minutes switch time that means that you can go downstairs or you can stay here where it's Nicer and nicer people We are going to have Jack from check from CERN Speaking to us in 15 minutes that will be a 15 passport. Thank you Can we test can we test one laptop, please?