Original subtitles

hey everyone I'm a nationís car and I'm

introducing everyone to this IBM

developer Tech Talk series today we'll

be going over kubernetes so this is

titled learn the history and

fundamentals of kubernetes our presenter

today is Edie she and he'll introduce

himself cool so yeah hey everyone I'm

Edie I'm a developer advocate and

working for IBM cloud with a focus on

cloud deployment so you know can

containers serverless virtual machines

that those kind of those are kind of

like the key features of what I focus on

but also I do a fair amount of machine

learning and artificial intelligence as

well so ok so throughout this talk I'll

be monitoring the YouTube chat for

comments and questions and in the

YouTube chat in the description box

there's a link to the event page and in

this event page you'll have a replay of

this video and getting started resources

that will help you take the next steps

in learning kubernetes along with a link

with how to sign up with IBM cloud so ed

we'll begin now cool yeah so what I will

do just before I start just check all my

all my slides up on the screen so that

you're ready to go

ok great yeah so try to try and not like

boy you guys too much with too many

slides what I'm gonna do in this talk is

I'm gonna take you through some basics

of you know containers and Kuban at ease

and where it came from

and just a few of the important things

you'll need to know and then I'm gonna

do live demonstration because I think

it's the best way to learn is to see how

it's actually done and and you can see

it live and this is actually also

available as a workshop if you want to

do it I'll share the link with everyone

afterwards

okay so let me just share my screen cool

and Anisha could you just confirm you

can see that you should be able to see

the intro okay great so just just to

reiterate what Anisha said if you're on

this event page anyway there are

resources you can go to you can find all

sorts of things around Cuba Nettie's and

so on and the the workshop that I

mentioned some of which is covered in

this talk if you go to Cuba Nettie's 101

on the left and if you're interested in

signing up for a free IP em cloud

account go to this link on the right

hand side and from there you can start

playing with all sorts of resources and

services on IBM crowd great so the

agenda for today I'm going to loosely

cover a container architecture and this

talk kind of assumes that you have a

basic understanding or at least familiar

with containers as a concept you don't

necessarily have to have had hands-on

experience talk about the advantages of

them then talk about docker and how that

kind of revolutionized that container

ecosystem and then some of the stuff

around Cuba Nettie's you know why I came

about where it came from and the basics

of Cuban ESI's and how it works

and then some key concepts of Cuba

Nettie's they don't do this demo I

talked about and then finally I'll just

come back to the slides just to wrap

everything up at the end so to start

with just for those who aren't

necessarily familiar containers

essentially have taken what was you know

the virtual machine operating model

where you have a hypervisor and in each

of those you have an you know an

isolated segment of compute and that can

run into an operating system the

difference with a container is that they

share a host operating system so you're

still you still work in an isolated

environment both in terms of compute

memory processors etc but there

actually all on the same Lennox host

operating system and so what this allows

containers to do is to be incredibly

more incredibly like lightweight and way

more portable than a virtual machine is

and I'd like for those who've you've had

experience in this trying to share

virtual machines with each other when

you're sharing images they're often you

know tens or hundreds of gigabytes

containers tend to be you know in the

range of like megabytes tens of

megabytes hundreds of megabytes as

they're very big but it's normally the

stuff you put inside it that makes it

big it's not the base image itself

whereas an operating system already by

default it's taking out gigabytes of

space right and so they're much less

portable yeah the other thing is they

don't have the boot up time of an

operating system so containers can start

in milliseconds where um virtual

machines were starting in you know

seconds if they're really fast but

mostly minutes um to show you how this

this kind of makes it more flexible in

terms of how you run your compute the

other thing with a virtual machine is

that they they are constrained from when

they start in terms of their resources

so if I have this example on the left

hand side I've got a virtual machine but

hardware known as got four apps on it

I've provisioned those into that machine

but I have reserved a quarter of it for

each of those apps and actually none of

them are using the fully allocated

resources that I've given them with

containers you don't have to constrain

them you can constrain them with

kubernetes and you your common to see

this later but it also allows you to get

more utilization out of the hardware you

have underneath because typically

they're smaller lighter weight and they

have fewer resource requirements in the

first place but they also don't

necessarily need to be constrained so if

one app needs more compute than another

it can take it and so then bringing onto

docker right so docker tick containers

which actually been around for a long

long time there was since the 80s but

they weren't very popular because it

would

very difficult deployment technique to

use what daca did was took the container

system and made them developer friendly

so they built a nice experience a user

experience around containers and the way

they did this was they they defined some

key components like on the left hand

side you see it the registry right

inside a registry it's essentially a

store of built containers and and what

gets stored in there or container images

so what you can see in the middle just

under where it says docker engine an

image is the same as a virtual machine

image it's it's like a blueprint of a

built container that contains all the

code and dependencies required to run

your application right those images then

get run and they're instantiated into a

container and that's what actually the

container is is it's a running version

of the image that you've built and those

are built through a set of instructions

called a docker file right which you can

see on the right hand side and so talk

about this very simple ecosystem but it

actually made it really easy to reuse

other people's assets so you know I

could I could take one of your images

from the registry I could add a use my

own docker file and just build my own

application information into the image

that you've already created and then I

can run them as containers when I have a

run in container if I also want to

capture the changes I've made in that I

can commit that and it creates a new

image from the the base image that was

used but so docker kind of made this

really nice and running containers was

then sort of a much easier problem than

it was before but docker has a lot of

limitations when it comes to running

things in production and so if you read

this problem statement at the top I have

multiple applications that I wish to run

across multiple servers with high

availability docker is great but it's

not that smart

so some of the limitations of docker so

docker is only aware of the containers

running on the machine it runs on right

and that's the biggest one here is

the docker engine runs on a single

machine and it has no awareness of the

fact that you might have multiple

machines with multiple applications

running on them so it's also inherently

not aware of its own state right so

actually if your machine totally dies

your doctor engine dies with it

so docker doesn't even know that your

containers underneath are now no longer

running horizontal scaling in docker

doesn't exist so yes you can run you

know you can say here's a container run

it and then run it again and run it and

you can keep running the same container

but it doesn't have it built in by

default right in the way that with

kubernetes you can scale things easily

and independently docker also doesn't

repair applications which become

unhealthy and so with a docker container

if I deploy my application in there and

it's running on an engine in a single

machine and then it crashes and a docker

can report back the status saying this

application has crashed but it doesn't

automatically understand you know why is

my not necessary why my applications

crashed but that the application has

crashed rather than necessarily just

exited because it's finished running a

process and it also doesn't know that

actually I want that thing to be

restarted I still want to always have

one of those running so it doesn't have

this kind of understanding of the

desired state of your application

landscape which is again as we come to

Cuba Nettie's you'll see that that gets

managed very well so just to explain

where where Cuba Nessie's fits in and

this is a kind of very abridged version

of different sort of container stacks so

right down at the bottom you can see

visual physical infrastructure right

which was I guess how you know

traditionally all computing was done and

you buy your own physical machines on

top of that you have virtual

infrastructure things like VMware or ec2

from AWS operating systems again these

are now abstracting even more you know

inside your virtual machine your

extracting stuff through an operating

system inside those who might run a

container engine right which which then

isolates that operating system and then

like a sort of even higher abstraction

to that is this kind of orchestration

scheduling service model right which

basically takes multiples of those

layers that we've talked about beneath

so in this case container engines for

cuba Nettie's right and handles the

deployment and scheduling of workloads

across those and the final one just to

mention at the top there is more of a

like developer focused orientation to

that so if you look at things like open

share or Heroku or Cloud Foundry

typically what's referred to as powers

or platform-as-a-service

and these tend to take a much more that

they're more opinionated but they will

take a more developer centric approach

where actually it's I don't really care

how my application gets deployed and

where and so on I just want it to run

and here's my code so it's like a code

first approach um so just before I talk

about some cuba Nettie's capabilities

let's talk about sort of where it came

from so originally came out of a project

in inside an internal project at Google

called Borg which was their workload

scheduler which would allow their

developers basically to spin up their

own environments super easily and

quickly and it was built using

containers it then became its own open

source project has been you know it's

been backed by huge corporates you know

IBM being one of them Google are still

heavily behind it you see brent hat even

even amazon who traditionally have been

pretty anti open-source ever have caved

in and now back in cuba Nettie's as a

container Orchestrator and it's it's its

own now through the cloud native compute

foundation has become its own foundation

which is great it was the first

project to fully graduate from the cloud

native compute foundation if you're not

aware of what that is Google it because

it has some great tools and utilities in

there that allow you to run distributed

workloads at scale on the cloud using

best practices another fun fact right

kubernetes comes from the ancient Greek

it means helmsman or captain of a ship

and as you start to see some of the

capabilities that cuba's brings to your

container deployments you'll see why

it's named as such so one of those is

intelligent scheduling cuban entities

will take your containers and it's

automatically placing those based on the

required resources so if I have let's

say I have three machines right and and

one of them's running almost at capacity

and the one's kind of half full and the

other ones pre empty right Cuba Nettie's

is aware of that and it knows okay the

best place to deploy that extra

container you know all that run is in

the already the pretty empty one there's

loads of resource there for them to run

and it also you know supports mixed

workloads you draw if I tell Cuba

Nettie's I want three and one want my

application deployed three times for

high availability right in fact I don't

even need to tell I need high

availability it assumes as much it will

take your containers and it will run

them across as many different worker

nodes as it can in order to increase the

availability of your application

another thing Cuba Nessie's does is it

self heals so it has a concept of a

health check and it understands and you

can define what it is that it's checking

on your application but it will restate

restart containers that fail those

health checks and it will replace and

reschedule containers if a whole node

dies so so a node is a think of it as

like a

like a compute pool I guess right or a a

physical worker that is running your

containers if that entire machine goes

out cuban SES is aware of that and it

will then replace and reschedule those

containers on to other machines to make

sure you always have as many as you need

it also will kill containers that don't

respond to your health checks if you

define those cuba Nettie's is fantastic

at horizontal scaling there's a simple

command I'll show you this in my demo um

but you you can say ok that container

I'm running I actually know on 15 of it

and it just immediately scales those up

you can also do automated scaling based

on the usage of those so you know my

application is under heavy load I might

want it to automatically scale up and

add new containers but you know also in

a scenario where it's now nighttime and

few people using my service it can scale

those down as well

one of the other problems you have when

when you're running containers in a

distributed way is how to route traffic

from from those containers to each other

so and if I give you an example right

let's say I build a little micro service

that goes and fetches customer details

from a database it does some sort of

manipulation on that returns them to you

and you know as a team we want to reuse

that micro service quite a lot we need

it in you know a front end we need it in

a bunch of other services that depending

on the industry right you might be doing

all sorts of things

how if if that's running in multiple

containers

how do allow other services to connect

to that even more difficult right in a

kind of old-school deployment is if I'm

now scaling that so now I've gone from

having three versions of it or three

containers

I now have 15 containers how does it

know that that where those new you know

the other twelve containers are and how

to connect to those so Kuban entities

has a concept of service

is and and service discovery so when

your service comes online it registers

with the Cuba Nettie's service broker

and other workloads that are running in

there can then connect to the service

broker and say oh hey where's that

service that Ed built that retrieves

customer details for me and the broker

will say okay here's your connections

string you connect to that and it

automatically then does law load

balancing across all of the running

containers and to make sure that your

request is always served right

regardless of where the stuff is because

ultimately the containers underneath a

ephemeral they are they should be

stateless right a lot of people don't

want stateless workloads and Cuba

Nettie's but it means that they may be

in a totally different place to where

they were last time you connected and it

also has automated rollouts of rollbacks

I'll show you this in the demo

essentially you know you can roll out a

new version of your application if

things don't go correctly or you're

failing health checks or you're

monitoring it and something goes wrong

you can immediately roll that back with

a single command

another thing cube does is it handles

secret and configuration management so

if I have a let's say there's an

external API I want to connect to and

obviously I you know I should know

better than to write the API key in my

in in my code right we shouldn't be

storing it there but you know maybe I

think well I want to put it in

environment variables and so on you

don't even need to do that there's a

within Cuba Nessie's it can it has an

encrypted key store that can securely

store all of those application

credentials you might need and then that

application when granted access can

retrieve those and then use that to to

connect to in this case my external API

that I wanted to speak to so just very

quickly before we dive in a couple of

concepts in terms of like naming that

are important

so actually just before we do that this

is a very very simplified kind of

architecture of how kubernetes works and

and if you look right in the middle

there's this database at CD right and

that essentially right is at the heart

of everything cuban SE studs what what

goes in there is as a user I tell

kubernetes here is what I want my

application landscape to look like so it

might be you know I want this service

deployed and I want five versions of it

and I want you know each of those

versions to have three different

containers running across as many

machines as possible and then I might

have another service and I say you know

I just want to run fifteen containers of

that right that all gets stored as a

what is called the desired state and

then these controllers that you see in

the top right hand side these are

continuously monitoring your application

your actual deployed state right and

checking against all those machines okay

what are you running

what's your resource utilization app

haven't you know have any of those apps

return to exit codes that they crashed

and it takes those and it checks them

against the database and essentially

it's just doing a diff in those two

states and so if I have if I've said I

want three containers to be running and

there are only two in the in my actual

landscape kubernetes the lot less this

is where all the like logic within Cuba

Nettie's automatically takes takes care

of that for you so it will say oh we'll

only have two and the desired stays

three so I need to schedule another one

of those containers right and that's

where the intelligent shelling comes in

and will say here's the best know to put

it on I'm not going to put it on one

there the other two already exist etc

and the final piece in that is that you

see the API server above that with this

and this like handles all the requests

that you you do to it as a user the

controller's talk to it essentially it

just handles the database acts

and then in terms of terminology there's

a master node the master node is the bit

that runs all the kind of cuba Nettie's

magic right underneath so it controls

manages the cluster it's what you

communicate with from the cube CTL

command line has a REST API for

communication with workers and I guess

any external tooling you might use and

it handles all the scheduling and the

replication logic the worker nodes

within you know within kubernetes are

these are essentially your like compute

resources the these are the ones that

actually do the work for you and hence

worker node right they host the Kuban SE

services that you deploy they do have a

few other little things on them so they

have Kuebler which accept commands from

the master and and actions those on the

on the host has proxy which as you would

expect properties the traffic to and

from those containers inside the worker

to understand you know when i mentioned

the fact that it has a service discovery

and load balancing the queue proxy

handles that peacefully so you don't

need to and of course it it actually

runs a complete container engine inside

so in this example it runs docker engine

one of the interesting things about Kiba

Nessie's is it actually it doesn't run

any of your containers it requires you

to bring your own container on time and

actually in the vast majority of cases

this tends to be darker but it doesn't

have to be and that's one of the cool

things about the kubernetes design is

that as other container runtimes develop

you can swap them in and out so if you

eventually want it to run like I know

there's a lot of work going on with

windows containers being able to isolate

the window windows operating system you

know if you have very specific like Net

Applications that have to run on a

Windows host right

you should be able to do that whilst

using cuba Nettie's to orchestrate those

and there's also you know I

contribute heavily to a container

runtime called container D which is

essentially trying to take out so

Dockers Dockers great but I mentioned

all the user experience it gives when

you're using Cuban air variants because

gin in there doesn't do any of their

scheduling and checking of the

containers right cube is doing all that

for you so all the engine needs to do

really is literally run the containers

and it's quite using Dockers is probably

overkill for most of the scenarios so

what container container D does is like

strips this down to the really

lightweight and fast container runtime

that really just does the basics of

executing and running those containers

and then kubernetes does all the the

fancy scheduling stuff over the top and

another thing you'll need to knows pods

right a pod is essentially you could you

can try to think of it as a like a

container it's not a container because

they can contain multiple containers but

it's the smallest deployment unit in

cuba Nettie's so everything every

application you deploy it will be in

pods it the reason I mentioned it can be

a collection of containers is that on on

their own like you generally shouldn't

put multiple containers in a pod like

let's say my application has like a

front-end back-end a database like I

should the last thing I should do is

pull all of those in a pod and because

then I can't scale them separately

everything in the pod also you know

shares a namespace network and hostname

so again they may have processes that

conflict with each other

the the only like in general keep things

in separate pods the things that do make

sense to put in a pod alongside your

application container are things what

they call the sidecar model so let's say

you have like a logging agent right that

takes all of the logs coming out of your

containers

pipes them all to some central

repository or to a third-party service

or something right that's something you

want to deploy alongside every

application that you do and actually

deploying it inside a pod next to the

other container is a good deployment

technique because you know it again it

shares these the common processes the

name space network and hostname and it's

not actually affecting the running of

the container itself also they tend to

be incredibly lightweight right and you

should you would need to scale one to

one with each of the application

containers as you scale them labels are

that that simply just metadata right

there just key value pairs but they're

Cuba Nettie's has a really good way of

filtering and searching on these like in

a super fast way so so try to write

labels for your resources as much as

possible initially when you start

playing with kubernetes it might matter

because you only be deploying you know a

small application or a couple of

applications but when you get into you

know huge scale deployments where people

are running hundreds of thousands of

containers and often thousands or tens

of thousands of applications being able

to debug which of those containers and

which worker node in which application

gets very very difficult if you don't

have labels because the IDS give you

very little name on very little

information on right and then services

these these are essentially a way of

describing your like what your

application or you might prefer this

looks like within Cuba Nettie's so it's

as said here you know a collection of

pods exposed and as an endpoint it's

it's essentially saying these three

containers that I've just deployed I

want those to be described as my I might

get customer details service because

then other cuban at ease applications

can connect to that and use them here's

a super quick example of just how this

like the logic within Cuba work so if

you look on the right hand side

you can see we've got three different

workers so those are our compute poles

as I said and then on the left-hand side

I've specified this is my like desired

stay a very simplified one it says okay

I want one pod containing image a and B

and I want three versions of that right

so you can see humilities is

automatically put a B on each of the

three worker nodes on the right hand

side and then pod two is container image

C and I want replicas to right so it's

also put one pod with C in it and it's

put it on those top two worker nodes on

the right hand side um if like this

middle worker where to died my cube

knows well I still need three versions

of three instances of pod one which

contains a be running and I know I no

longer have that so it's automatically

scaled it and put two of them onto the

worker node at the bottom and and it's

also moved see down there as well so

that like we're always maintaining that

desired state the same thing could

happen with scaling so in this example

this is back where we were where we've

got a B on each of them and see on the

top two well what if I want a third

version of C well again it knows like

again this is this worker is

underutilized compared to the others it

also doesn't contain the same pod

already so it makes sense for us to

deploy a new container C onto the third

worker in the bottom right um there's

also the cube CTL right cube CTL is the

command you type on the the Kalon line

and the it's a it's generally it's a

very powerful and easy to use CLI and

it's the general like as you'd expect

right way it works is a cube CTL and

then action and then noun and then any

other flags you've got afterwards so

keep CTL create and then configuration

file or cube CTL get pods described pod

which gives you more details and I'm

going to spend time on this because I'm

going to show you

live now so I jump in and do hello

right so in fact before I do I'll just

to explain in this way I'll show you um

the cube cube Annette C's cluster I'm

running I've deployed this on IBM cloud

the great thing about running on an IBM

cloud is that they managed and take care

of all the master nodes for you so the

bit like that actually runs the clever

kubernetes logic and so on and that you

communicate with through the API and the

CLI and that bit you don't you don't

have to run at all yourself and all it

all that you're in charge of I like

those worker nodes that you provision

and the worker nodes are just your

computers so it's no no it's not really

any different - like provisioning your

own virtual machines except that now you

get all the power of cuba Nettie's on

top of it and all the headache of like

you know upgrading when cuba Nettie's

come out with new versions or new

features are checking whether you know

it's supported with your underlying

operating system and they're not grading

it and doing it or like all of that

taking care care of by IBM so like for

me this is super easy and so I've

created this cluster here it's called my

cluster and just to connect to that

right I need I need to tell my cube CTL

CLI like how it can communicate with

that so I'm just gonna do IBM cloud

kubernetes Service clusters right and so

that was only the cost as I have and you

can see that that my cluster one I just

showed it's running there so the thing I

need to do now is IBM cloud chess

cluster that config my cluster and this

will give me the configuration that

kubernetes needs in order to connect to

that cluster and right so this is going

to export a cube config variable right

and now if I did cube CTL get nodes

should like that one I'll connect to

that cluster and it will say okay return

all the

we'll work our notes on that so you can

see this cluster only has one worker

node down here you'd have expected that

anyway because look if you look at that

cluster it's being created with only one

worker node so this is a very simple

small cluster but it will do for what

we're demonstrating here today um what

I'm gonna do now is I'm just going to

show you like the quickest way to deploy

a container straight away to cuba

Nettie's so if I take you CTL run and

then this is the name of my deployment

guestbook and image equals I be v1 right

so what I've done there as I've said

when you run something it's call it

guestbook and here's the image right and

if I give it an image this is actually a

docker hub image so if you're not

familiar with docker hub it's kind of

like github but for container images and

it's gonna go and get the IBM comm

guestbook image with the tag version one

right because there may be multiple

versions of it and you can see it's

created a deployment for me all right so

now if I go to cube CTL get pods right

and remember pods are like the smallest

deployment unit we could create and you

can see in here there is one pot in

there called guestbook there's one of

them and it's already running okay

that's great that was pretty quick

access that pod and check them my

application is running I need to expose

that as a service so the way it can be

that is I can go you see a look this

type up expose deployment yes and then

there are different ways you can expose

your deployments in cuba Nettie's this

the simplest of these right is just to

use a node port which is essentially

saying like I just want you to map one

poor on that host machine to the

container inside so that I can access it

right so in this case I'm saying 3000 so

what I can

I'm doing is saying to Cuba Nettie's my

container that runs in there wants to

listen on port 3000

can you please expose that somewhere on

the host right so if I do that and then

it creates a service and I can go and

let's look at that service quickly so we

go get service yes but you can see that

what it's done here is it Maps port 3000

inside the container to 30,000 208 on

the the actual host machine all right so

let's remember that because I was going

to access this from a web browser in a

second but the most important thing is

that I need the public IP of the actual

worker right or of my cluster that I

created on IBM cloud so I can get that

from the IBM cloud CLI I can go OKs

workers my cluster and this would just

list the worker nodes that are relatable

in that cluster and you can see this

public IP here so I'm gonna take that

public IP and then just remember it's

30,000 208 so let's go okay so hopefully

this will show my guestbook deployed

yeah there we go so we can see that this

application is very simple it's it's

like kind of like a to-do list it's a

guestbook you can just leave your notes

you say I write so you know simple cron

pipe application and let's jump jump

back here again so now let's say I don't

know my guest books up and running

people are loving it it needs to scale

well I can do that super easily with one

come on so I can go scale replicas was

10 employment yes but right and I'm

saying I'm basically saying take that

deployment but this time run 10 replicas

of it and if I'm fast with this one

right I can view the rollout status of

that deployment so you can see it's

saying waiting for rollout to finish one

of 10 updated replicas are available now

2 of 10 updated replicas 3 or 10 so what

it's doing behind the scenes is starting

new containers on my machine just

through that scale command and you'll

see we now you know we have 5 or 10 and

it says minimum required is 9 so when

it's it's gonna get most of the way

there before it'll let you successfully

complete the deployment sorry though

this the wrong Val nearly that cool so

it now says we've successfully rolled

that out now if I do cube CT I'll get

pods or to my deployment units remember

I can now see that I've got 10 of these

in here and if you look at the top here

you know that was the first one I

deployed which was 4 minutes ago but the

other nine of them have all happened

just now in the last minute so I've now

got 10 containers all serving that same

application but but because I've exposed

that as a service if I go back to my web

page and refresh it right I could be in

any one of those instances each time and

right let's so now let's say I want to

let's let's say I want to deploy a

different version of my application how

would I do that

so I can be cube CTL set image

deployment yes but so I'd sent you one

doing and here is changing that

container image I've given it and said I

want to just deploy IBM comms guestbook

v2 this time right and you'll see my

deployment guestbook image updated so

keepers understood that and now if I go

back to the browser and I force refresh

this I may have to go incognito

because it caches stuff sometimes

updated I tied that all correct odds oh

ok still it's it was still updating so I

was too fast there cubes pretty quick

but because I've also I've got a really

small cluster with a tiny machine on it

and I'm trying to run 10 rep I'm trying

to create 10 new replicas and it wasn't

quite as quick as I was in this case so

maybe if I forced refresher in a second

we'll get there there we go so now we've

moved could guess what version to you

can see that color change that we now so

this version to up here and I can type

some new stuff and you'll notice that

the state was lost right we'll come back

to that in a minute so and you can see

from these pods here that some of them

were terminating in creating new

containers what actually happens when

you roll out to a new version is that

kubernetes by default will do a

Bluegreen deployment so it creates in

this case it will create ten new

containers with version two running then

when they're healthy it will start to

terminate the version one months so we

always have the application accessible

and ready and but let me see I don't

know type some more staff oh oh what's

happened here right I've got an error

I'm not really sure what this is but I

guess I should probably roll back my

deployment here well the good thing is I

can be that super easy with kubernetes

as well so if I do roll out undo

deployment expert that will literally

take the last roll out I did or the last

change and just roll it back right and

if I'm again if I'm quick here

and they look at the rollout status you

can see essentially by telling it to

rollback or like an undo a rollout

it's now going oh okay I better deploy

ten versions of ten in containers of

version one again and then when they're

all healthy start to terminate the

others from the diversion - and actually

I what I'll try and do is Australia

while this is running here's a good

example of Cuba CTL get replica sets so

the way Cube manages these is it

actually calls each of these things of

replicas set and and I can you also use

a label here so you can see what's going

on by using the - el flag and then key

value pair essentially I'm using those

labels and it's searching to match those

and you can see there are two replica

sets in there one of which will be my

version one of the app and one of which

is version - and if I rerun that command

they should have fewer of each now so

now yeah you can see that version one's

back up and running and version two it's

nearly finished killing all of those

okay

what I'm going to do now is I'm just

going to quickly delete this and then

show you another way of deploying

applications if I could type to delete

that would be helpful

cool so we ended meet the deployment and

then delete service guestbook as well so

we delete the service and now if I do

cube CTL get pods just check there's

nothing running okay there are a couple

of the three left that are still

terminating they've probably gone by the

next time I run it which they have okay

cool so let's clear this and what you'll

you'll find from that right that's a

really simple way of doing it but I've

deployed those with a prebuilt image and

I haven't given it much information I

basically just said like here's an image

run it

ultimately what happens is when you run

kubernetes deployments you end up

writing a lot of these manifests in yam

all right so here we go let's get this

one open so if you have a look here this

is a simple deployment for example and

I'm saying with with each of these

manifest files that kubernetes will

accept there's you would have to specify

the API version that you're

communicating with and the kind of

object you're creating and then you can

put as much metadata as you like right

these can be all these labels and so on

to be able to filter on them later

but the the bit that kubernetes needs in

order to actually deploy stuff is your

spec in here so in the spec you can see

I'm defining replicas ten let's change

that actually let's say like seven so

that we can tell it's not the point the

same thing as last time we've got a

thing here we're saying match labels

where the app equals guestbook the

template here in here we've now got

again some more metadata around the

container or the pod and then the

containers itself so here I'm specifying

the name is guestbook but I want that

IBM comm guestbook v1 right and then

also I need to expose that pour on 3000

and you can start to store all sorts of

information in here and the way I deploy

that right is I just do keep CTL create

guestbook deployment yam all right so

keep city I'll create minus F it's

basically like here's a file deploy it

right and it knows that this is the

deployment because I specified that in

the spec here I said kind deployment and

it's created the deployment it's named a

guestbook be one because again at the

name here guess that'd be one it will

use the containers image I've specified

etc and this becomes a much easier way

of being able to employ things and also

store the configuration and like like

not have you can also use it to automate

things which is much easier but also

like avoid human error you can you can

do you could do all of that from the

command line but it said a lot of

commands or a lot of flags and you could

easily type some wrong and whereas when

you're storing it in a manifest it's

much easier to handle the other thing I

then need to do is I need to go and

create a service and finally let's check

this is deployed first so get pods okay

cool yeah so my seven pods are up and

running

I could equally have done L thing to

filter in this case I should get a mob

because all of they have running from

that guestbook app to be a little bit

slow responding but there we go yet we

get the same result and then let me just

show you how I can actually that

deployment I showed you I can edit that

deployment from straight from cuba

Nettie's right so what this does is it

downloads a version of them deployment

and you'll notice as I scroll through

this that there's way more information

in here then was in the deployment

manifest I gave to Cuba Nettie's right

and that's because this is a copy of

what's being stored in the database and

this contains all sorts of information

about like you can see the status here

for available replicas as the conditions

so the last time it was updated you know

the minimum availability message on

there and so on all that so but

essentially like it's this is all the

stuff that Cuban if he's is added to it

before it's stored it so let's just quit

that and then what I won't do is me like

you could equally I could have made

taken that guestbook deployment and then

apply to change but let's just deploy a

service now instead so let's do let's

have a look at that first service and

you'll see this service let's go back

again looks much like the deployment

does it's long but simpler this one it's

basically saying you know deploy a

service

match the selector here is looking for

app equals guestbook so all of the pods

where the label app equals guestbook and

then I want you to load balance over

there

and I want you to expose port 3000 right

so there's my simple service

let's do QT TL create guestbook service

and that should now be deployed

so it says service guestbook created and

and then if I do once once more I go to

my let me get this the called hopefully

guess but yeah so I just need to check

that port again right so that because

this time I've created a new node port

on there and I need to update that

unlike browser so we can go and check

the route still running Oh in fact it's

the same port still so we're good um and

you can see my applications now up and

running this time I've deployed the same

thing but I used manifests rather than

specifying the image myself and then

writing commands in to do it so and then

I can do the usual like it will take

state the only thing is right all of

these haven't had a way to actually

store the information I put into my

guestbook so very quickly what I'm gonna

do is I'm going to deploy a Redis cache

so that this application when it takes

information in here

it still stores it because if i refresh

this again i force a refresh because i

have seven instances right you'll see

sometimes they get the response i typed

in but a lot of the time i'm getting

blank right because it depends which one

I'm connecting to that's not

particularly good behavior for my

application so let's deploy a backing

service to this so a cube CTO or grave -

F

redis last time and you can see this is

much easier when I have these deployment

manifests written off already so now I'm

creating a new deployment called Redis

master and you can see if I do let's do

the this time my selectors actually do

something because I have multiple

deployments so I'm saying match the

labels where at people's Redis role

equals master and still return the pods

and you can see I have one of those

running this Redis master they're going

to copy that quickly because another

cool thing you can do in cube is you can

do queue TTL exactly right and this will

back into the container is like SSH is

in and runs a command for you so in this

case I'm gonna give it so that's the

name of the pod I want to connect to and

the command I want to run it Redis CLI

so if we jump in there we can just check

the Redis Eli's running and you know we

can go like ping and it responds okay

great so that's fine

let's just jump out of there and then we

also need to create a service for that

one that ServiceNow will match that

deployment we created so that it's

exposed and just in order to so the

thing I need to do now is the

application has the code that's written

for it is automatically going to try and

connect to Redis if it's available but

because it's already up and running it's

now using in-memory database instead we

need to restart it so there's no real

real concept of like a restart in Cuba

Nettie's and because all your containers

are supposed to be stateless in

ephemeral and so the way we do that is

we do a cube CTL elite deploy guess

Burke v1 so I'm basically deleting my

deployment I created and then I'm just

gonna create it again

and they'd like I could equally I could

have scaled the replicas to zero and

scaled them back up again that would

also have achieved the same like same

goal and now if I jump over to my

application refresh it quickly enough

it's finished

if those pods of finish creating so

they're still saying container creating

two of them are finished so we might get

a response now there we go right and now

if I type something in and I say you

know how about world if I fall to

refresh this regardless of which of the

instances I connect to and I can see

that state because it's being stored in

my Redis service and we can also like

let's confirm that for sure by going

into the let's exec pending on what do

they call that pod again I'd find it's

that exact into the Redis pod again all

right so we're now using the Redis CLI

again inside that container that we're

storing the cache and let's do just see

what this one's called okay it's called

guestbook in here let's just get like

the return the phone

essentially I'm saying to it return the

first ten rows of whatever stored in

this cache on the guestbook key and you

can see it's stored inside there is

hello world so my cache is working and

it's replicating across all the

containers um fantastic so I've now

deployed like a very simple but pretty

powerful scalable deployment the final

thing that I was going to show you but I

won't do and I'll talk about instead is

if I jump back to my slides and what I

was hoping to have time to do was to say

now I've deployed a Redis master how do

we keep that scalable well one of the

ways we could have done that would be to

deploy slave nodes to that Redis much

and what those slaves do is is they

replicate the data that gets stored in

the Redis master across them so we can

have multiple instances of the database

as well and then the way the application

behaves is it takes reads from those

slaves and any rights go to the master

and then they get synced across and at

that point right very quickly you know

with in under an hour whilst explaining

it we have like a three-tier application

that's fully scalable highly available

on cloud deployed with kubernetes and

kubernetes is now constantly monitoring

that to make sure it's always up and

running which is it's a pretty cool and

powerful way to have your application

running and again like thanks to cuba

Nettie's so I'm gonna open up very

quickly to questions and nisha identif

you mentioned you were going to monitor

if there were any I don't know if you

want to let me know if we have any at

this stage oh yeah people asked about um

advantages of using kubernetes on IBM

cloud specifically if you have anything

to share about that or yeah sure um so

yeah there's essentially right there's

like two ways of running communities and

you can either like run it and host it

all yourself either on your own

infrastructure or in cloud

infrastructure like a lot of a lot of

cloud providers will will spin up Kuban

entities for you in a load of virtual

machines and go like here it is like now

it's your problem

and the problem with that is is you have

to manage and maintain all of the master

nodes you have to handle a lot of the

networking that goes on underneath

you then have to stay up-to-date with

kubernetes upgrades or you have to

delete your entire later if you if you

want to get efforts from provider and

the other way of doing it is is like a

managed kubernetes environment which is

what IDM provide it's what do you get if

you you know if you go to Google cloud

as well I think there are some others

who do it now to essentially the benefit

with that right is in this case IBM

masternodes they look after all of the

kubernetes type upgrades for you and

they there is still like a an option you

have as to when you want to upgrade but

the other thing they'll be doing is

they'll be providing things like when

your worker nodes like fall out of day

or there's a security vulnerability

within them IBM will notify you and tell

you like here all you have to do is run

this command and we can upgrade them for

you but you've just got to be aware that

you're working like you know what your

stuff is you you've deployed on there

and whether it might be affected so it

takes a lot of a headache of running

kubernetes away from you and lets you

focus more on just deploying your

applications and being an end-user

rather than operations manager of a cube

cluster great answer um someone else

asked where are the logs to the commands

and service stored so we're the lost of

the commands and service perhaps or

maybe I'm gonna hey I think I thought I

know what they mean by that I'm gonna

assume they mean like if I run so when

I'm running cube CTL like create service

etc or something like that

right I'm telling Cuban Eddie's to do a

bunch of things is there like an audit

trail about that because you know one of

my other developers might tell cube to

do lots of stuff um yes that's that's

it's all stored in the side the API

server that I mentioned earlier like

keeps an audit trail of that I don't

know how accessible that is like so you

can see it I know when you run cube

yourself right you can see that whether

through IBM cloud because it's like a

managed service you may have to if you

had that request you may have to open a

support ticket and just request could we

see all the audit trail for our commands

and that but ultimately like you you

want to get away from in a you know in a

multi-person environment you want to get

away from running as many commands as

possible and you want all of this to be

handled by automated tooling

that you know in reality you write your

code you check it into your get

repository and that triggers some sort

of delivery pipeline that you know

builds your code into a container it

deploys it off to kubernetes it asks for

certain number of replicas etc and the

only thing that the developers kind of

in charge of is maybe like changing a

few bits in the configuration that they

then have to check in with their code

anyway so you then have a full audit

trail from that side and that's probably

a better way to handle it you know like

you know multi-user scenario and any

other questions Anisha we as as do we

have any more questions or is that all

should I wrap up that uh yeah I think

that's all for questions so anyway thank

you to add and as I said before for for

more information in the description box

of the video there's an event page and

there you'll have links to more

resources on how to get started along

with a link to how to sign up for IBM

cloud so thank you everyone and that's

our Tech Talk go