 Okay, better Hi everyone, welcome to the March event for Kubernetes we have An interesting lineup tonight, which I hope everyone will enjoy. My name is Hunter if you don't know who I am I'm one of the CNCF ambassadors here, so We run this event, you know once a month a few familiar faces I've seen around but You know welcome to all the people who haven't been here usually when we kick it off We'd like to get a bit of a poll about who knows About Kubernetes who's actually using Kubernetes in their day-to-day work Okay, more hands going up. It's nice to see this thing growing who's who's Completely unfamiliar with Kubernetes Okay, too. That's good We usually like to run a Kubernetes 101 every now and then so we might try and organize something coming up in the future For people who are wanting to get familiar with it, but Tonight we've got a really good Set of talks We're really quite fortunate to have Rimas here who is one of the creators of Helm The package manager for for Kubernetes. He also works at Mesosphere and is going to give a bit of a rundown about how Kubernetes integrates with Mesosphere and all the interesting stuff there So just a quick Actually, maybe I'll come back and talk about it later about the other things that have been coming up So let's get into the interesting stuff first and See you all later Hi, my name is Rimas. I work a solution the architect for Mesphere Was lucky to invent that helm as well with my ex-colleagues from death So who's familiar with Helm? Wow, that's a good place to start so Let's Explain what helm is That's about me. I was running crazy Docker adoption in 2014 wrote my pass in Bash What it is to mature? so so you have Kubernetes right and You need the easy story to get our applications to run so we have templates Services manifests all those with Kubernetes anyway not easy to manage That's okay for her. So they're not easy to manage so Helm brings the nice story it packs your Manifest files Kubernetes files as a package called a chart Which easy to distribute between your team upgrade them do new releases and so on so as said chart describe your software and Dependencies in one thing basically like looking to Using up Yum installing applications are basically the same thing you do for Kubernetes with the helm charts So I'm going to explain the Helm basics and in my second talk I will use a demo as well how using how to install applications with a helm How it's all helm and how to install applications all with the helm so so what is helm so so You need to manage your complexity for applications so Chim chart describes even most complex apps though, which can be repeatable and serve a single point of authority and chart can have sub charts so like You could see like WordPress and having a sub chart like my sequel and even one click you can install both and You need to un-upgrade You just can specify the tag you need to a docker image to be upgraded and That will change only that place if your chart gets changed that you can apply that change as well But the rest stays intact. So helm knows where upgrade goes to so charts are easy to version share and You can cause on a public or a private repositories You can have them on github like Code or we recommend using helm repositories. So which are packed versions of your helm charts, which are versions So every time you release a chart you bump a version and You want to always can go downgrade them Things happen better lease that chart release So we can always roll back as well So easy updates. So I mentioned most of times what you do with and upgrades Docker image tag that's most used case so we can use githash for your or somewhere or wherever you up to every and helm upgrade Specify that githash tag or somewhere you upgrade and Underneath is still Kubernetes running doing collect could control kind of issue helmet talks to the API server You need to do your all back use home or all that command roll back to a previous version by default Or you can specify the version very similar to keep control So home components So we have components like home client basically sits on your laptop or your in your CI CD pipeline as a helm client which knows How to connect your API server? Sorry to tiller. So the client is responsible for Following things like local chart development. You develop a chart You all prefer to do locally on laptop not pushing everything upstream to a server to GitHub and CI CD pop up at first because you have to test it. So and Interactive with a tiller tiller is server side of helm which Interacts with API. So home client connects to a tiller and tiller connects to a connector I use as API Kubernetes API server. So Yeah, we already ex went for too quick. So So basically tiller server is Listening for a quest for my helm client. That's it. There's nothing else sit and sleep till you ask to do a job very simple on the resources and so on so three big components of Concepts of a helm chart. So chart is a home package. So For example, we have a Jenkins chart It contains all our sources search definitions necessary to run your application tool or service inside of Kubernetes cluster so Jenkins yes, I Don't go much due to Jenkins But like I experienced like homebrew formula up get or yum RPM file basically exactly what the chart is and You have repository. It's not get a positive a helm chart repository where you host with your simple web server Even GCS S3 bucket can be useful cell as well to hold your chart repositories and you use helm client to pack your home charts and After you have to sync them to your helm repository that allows easy very easy to share between your team between your CI CD pipelines between servers between clusters You might have developed and staging production cluster Because first you may maybe try to assume charts the new chart in Dev cluster you can try that first So one place to share where helm charts is the helm repository and all they packed as a small tariff files Every time you release it gets the new version. So Going there via get you don't have that option so You always have to go back here pull requests and comments and so on So the release of a chart So the helm release is basically you install the chart. It's called a release the releases stored stored as config maps or if you need more security can store as secrets Kubernetes secrets and you can store the same chart as many times as you want But you have to provide the release name or if you don't provide the name where random name will be picked up as well but most cases I think you prepare prefer to have a release name so you know what you Which kind of release you have or because random names just don't give you anything So with all that in concept in mind we now can explain how helm assemble as this So Helm installs charts into Kubernetes Clinic and you release for each installation and releases are stored as Taylor config maps or secrets depends on but if I was confident about if you need more sick prior Security use secrets. It's easy easy change changeable So what is a helm chart? Yeah, so I spent right so share allows you to share applications as Kubernetes shares in your organization create irreproducible reproducible build builds of your Kubernetes applications Manage your Kubernetes manifest and all of files manage releases of Kubernetes packages. So and Chart has very simple structure basically. So my chart is basically here it's a chart name and Chart Yamal just has information about your chart owners and Most cases you use have to specify in a chart the version every time you release a chart update a chart You have to bump a version there. So License is optional but up to read me Read me it's recommended to have so every knows how to install especially Just in case but it's not Really needed. So values file. That's very interesting thing So with values files You specify which values you want to pass your templates? like most cases docker image tag So docker values file has a docker image tag you specify by default and afterwards if every release you can updated that and You have two options as well use every time you can have a value file updated the new chart so with a new tag and Maybe it's more recommended way and maybe Just store that in GitHub or get get get repo like get ops So you always have a state of your cluster when you store that way so charts By default you don't need that till you need the sub charts like Like for example WordPress needs where my sequel so you can store sub chart where yourself or you just have dependencies using some external chart of my sequel but templates folder is your Deployments ingress services Demon says where you store your templates Notes it's optional. It's nice to have to ball for humans So when you install the chart it spits up some information how to use a chart if You have fully automated CI CD pipeline not really needed, but sometimes Developers ops guys still need to check check the thing. So it's nice to have it and maybe recommend it so Some if you're looking for some sample chat sample chart, so that's a good good things to start from like Hubcubeapps.com So it's basically the same thing like here, but you get the dashboard and UI Basically you can Click it here front and so you can see the visual way all the charts J frog Basically trees there read me file presents in a nice way and how to install And you can run that based on monocular so you can earn yourself in your internal cluster the cube apps as well You can start as a home chart so Very handy for different for local developers if you want them to go that way But I only recommend developers to learn a lot of helm stuff because they should code and nothing else You'd be doing nothing else because way too much complexity, but helm takes a bit away from complexity from Kubernetes Especially if ops guys prepare a helm charts for you for developers. So you get instructions like these Very easy to go start from So if you go here, so it's exactly the same charts we saw before but Now it's in github So we have to pick anything traffic from example and you see the read me file as well which with cube apps How it gets translated in more human readable way? so Helm is easy really easy to use so first you need to Have Kubernetes cluster, of course Cube control has to talk to your Kubernetes cluster. You do helm in it which initializes your Local home repository the local directory for helm and knows how to connect to Kubernetes cluster Next you have to add helm repository This case we're using helm repository as incubator because we have incubator and stable for Helm charts up to the home charts. So you are there Your helm repository So that is scriptable for your CI CD pipelines Basically, you can do helm in it dash dash client Afterwards you add your private public Helm repository over here This is one comment and you do helm repository updates so that fetches all the Charts so I will go and demo all that in my next talk and we have all Kubernetes in helm part That's basically easy. So so install a chart. Yeah, you do helm install stable redis Yeah, because I'm telling name Release name will be redis. So I tell him name space Specifying name space redis as well So I want to disable persistence. Basically that has to be of course in your values file and specifying the Token image as well that installs Installs a helm chart and afterwards you can list them come list list all your releases Upgrading as well. It's so easy as that. So help upgrade redis with your release name stable reuse values is really cool feature so If you don't use reuse values, you can get overwritten by default formula values file have changed made more changes So in this case, we specify chest the docker image wanna see changing the version or you can have a dash F and values overwrite file and That values file have only one thing not that big values file. Maybe I'll show you Let's maybe go back a couple of charts You see to explain more values well so values follow have a Replicate account how many replicas you need image so repository tag cool policy and The app related Agent token, whatever it needs to be done private and Resources it's a common thing as well you pass resources to your application specify that So having your values file you can uncomment all those things. So you don't have to So you can have a copy of your that values file uncomment change things you need and store that values file Maybe with your app code only so Chuck is separate. You can repository. You should have a hell separate repo get repository for helm charts and And values follow with your app. So And you could just overwrite No, select it specify you just basically normal Kubernetes. So if you want to put on the particular nodes, it has some selector your application So chart can look at quickly as well. So It has an API version description name This is basically you have to change all the time you do the chart upgrade change, sorry, so So you have a versions properly the application version and I can just what's about so It's nice to have whose keyboard keywords as well. So when you search in your helm repository, you can search by these will be easier to find a Source and who maintain off my chart So templates So like for example notes You specify what you're okay? like build kite agent token wasn't specified you get the error but and Nothing will be installed and instructions what to do. So it's nice to have it deployment As well checks for agent token. There is no agent token deployment one been stalled so and Like image you see values image repository values image tag. So Before Helm you used to be setting you said or maybe Bush script which has a template file inside your place Whose things now with the values file and Helm we can easily replace So they have to touch that template files directly Yeah Test okay, so yeah I just wanted to like as you were talking about What you could do without Helm like it the way we started at Honest v was we we used Kubernetes manifest We just first use a Jinja Python templates and then you you write some first we use said then we use Python templates Then we put us a flask Server that basically renders a template so we have a webhook to deploy and at that point We just basically said we're building Helm. So why don't we just use Helm? So basically that's yeah, what I wanted to highlight Yeah, that takes all complexity away. So we don't have to build us stuff. Just use it. And it's really big commuter Behind it. So big companies supporting that. So why not? because I Went to Helm summit a couple weeks ago We heard so many different interesting new story stories. So this is story. So all videos available. So you should check it out and Even Helm v3 will bring loads of new features Which community wants? So it's a normal template file from Kubernetes, but you have always go templates. So it's get replaced in place One value is filed by Helm. So we don't have to do anything yourself. Yeah, so we have secrets the same way Service account is needed and you see every it has special labels. So the app label basically gets the name from a release chart chart version and This is why it's good to have a chart version so every time you release a new chart version You do get a new release So it's that will be stored here as a label. Every release has name as well. So we store here as well So we always go back and check and upgrades work really nicely there. So All the labels I don't as we also because the chart becomes like a standard way of deploying the application every Chart can be linted can be you can enforce which labels are you know mandatory before your Developers can or before your team deploys any application if you use Kubernetes monitoring automatically all those labels are available for you to chart to make a very detailed graphics So I just wanted to highlight that that all of this is built in in Helm and allows your team to to provide very deep inspection of how much CPU each Individual container is using on your Kubernetes cluster if you want that information So the cube metrics automatically X these things and we were using data doc. So in our case Our the way that the data dog integrations crepes the metrics from the Kubernetes cluster every single metric is tagged by the Labels attached to the to the containers. I didn't have to do anything. I just defined them make them default Yeah Plus you you're free to add your labels It's not a problem doll. Basically when you use a good example, maybe using like traffic or Engine ingress So you have to have to slave use labels in your deployments have to sorry in your ingresses so the ingress gets picked up by particular traffic or Engine ingress where I'm on now with guys See now it's totally different. So we have service type all balancer load load on therapy Debug node selector affinity tolerations SSL so You put your values file which are any your app needs but sometimes you see it gets very complex So imagine having that all about helm We'll be unmanageable totally So much basically building where our flasker will be one be easy. Oh That's big improvement on traffic now Yeah, so that's a good example basically of values file. It's crazy but you can have a default and You have a second Values file which you specify with F as well as overwrite and you just can put You pick anything you need is most of a changeable and you have basically, okay, the best example With a tag or a whatever you okay, we can tell low balancer type in your values file and You can specify two values file default one and the new one as well. So there The last one overwrite the default one. So basically very flexible. Okay. Do you have any questions? Shall we go back something or Explain something more now. It's a real question So in the values as you saw there's a couple of them show like a private key Some like yeah some some secrets basically right so how Can we split the secrets from the values from a helm release example? I usually have secrets separately totally. I even use secret for secrets to use home charts But I have separate I don't mix anymore secrets. So in this case, you don't really have to worry about secrets Especially developers doing changes releasing something even it's not a production, but having secrets separately. It makes more sense so separate helm chart which could be particularly see ICD pipeline which deploys that and so kind of issue and Loads of cases secrets are shared between your apps So having a separate secret makes more sense and If up has Whatever five different microservices you usually prefer to put into the same namespace. So Deploying this secret in the same namespace from a separate same helm chart makes total sense and And honestly, we actually also don't put any secrets inside the value files We use something called vault controller to fetch the secrets and create a secret completely separate from the release Yeah, totally and because it's the the value really defines what is deployed in your cluster So you have to be able to commit it and do infrastructure as code over it so you need to be able to collaborate on it and iterate over it and Control the changes to the values files. They are very important part of how your clusters are being deployed So you really need to source control them and yeah Especially when you saw that traffic values file, that's a really complex one And you have a secrets mixed together It's not so easy to manage anything else or Shall we have a short break or shall continue to my next topic with demos and everything?