Kubernetes Managed Service Architecture Overview
Key Points
- Sai Venom, an IBM developer advocate, introduces a high‑level reference architecture for managed Kubernetes services and explains how to deploy micro‑services onto the platform.
- The architecture centers on the Kubernetes master (primarily the API server) that receives workload definitions, and on each worker node a kubelet that schedules pods and monitors their health.
- Kubernetes is presented as the solution for scaling cloud‑native, micro‑service applications (e.g., a front‑end and back‑end) by describing resources in YAML manifests sent to the API server.
- A simple YAML example is shown that defines a pod with a Docker Hub image, assigns a version tag, and adds an “app=frontend” label to enable identification and selection.
- The deployment process is completed using `kubectl` (the client) to submit the manifest, after which the kubelet on a worker node creates and runs the pod.
Full Transcript
# Kubernetes Managed Service Architecture Overview **Source:** [https://www.youtube.com/watch?v=aSrqRSk43lY](https://www.youtube.com/watch?v=aSrqRSk43lY) **Duration:** 00:10:58 ## Summary - Sai Venom, an IBM developer advocate, introduces a high‑level reference architecture for managed Kubernetes services and explains how to deploy micro‑services onto the platform. - The architecture centers on the Kubernetes master (primarily the API server) that receives workload definitions, and on each worker node a kubelet that schedules pods and monitors their health. - Kubernetes is presented as the solution for scaling cloud‑native, micro‑service applications (e.g., a front‑end and back‑end) by describing resources in YAML manifests sent to the API server. - A simple YAML example is shown that defines a pod with a Docker Hub image, assigns a version tag, and adds an “app=frontend” label to enable identification and selection. - The deployment process is completed using `kubectl` (the client) to submit the manifest, after which the kubelet on a worker node creates and runs the pod. ## Sections - [00:00:00](https://www.youtube.com/watch?v=aSrqRSk43lY&t=0s) **Kubernetes Master and Worker Overview** - The speaker outlines a high‑level reference architecture of managed Kubernetes, highlighting the role of the API server on the master and the kubelet on each worker node in orchestrating container workloads. ## Full Transcript
hi everyone my name is sai venom and I'm
a developer advocate with IBM today I'm
back with another video where I'm gonna
be talking about all things kubernetes
kubernetes is an orchestration tool
allowing you to run and manage your
container based workloads today I want
to take a high-level look at a reference
architecture of managed kubernetes
services and dive a little bit deeper
about how you would do a deployment of
your micro services let's get started
here so we've got here sketched out kind
of two sides of the puzzle here on on
the left side here we've got the cloud
side and what we've got here is a very
important component it's gonna be the
kubernetes master the kubernetes master
has a lot of important components in it
but the most important piece that we
want to talk about today is going to be
the API server the kubernetes api server
running on the master is integral to
running all of your workloads and
exposes a set of capabilities allowing
us to define exactly how we want to run
our workloads on the right side here on
the customer manage side we've got our
worker nodes which are all also
kubernetes based there's one major
component that I want to point out
running on every single kubernetes
worker node and that's gonna be the
cubelet the cubelet essentially is
responsible for scheduling and making
sure our apps are healthy and running
within our worker nodes so you can
imagine that the master and the cubelet
are gonna be working together quite
often let's take a step back why would
someone want to start using kubernetes
well maybe they have some micro services
make up a cloud native application you
know as we all know micro services are
talking to each other over the network
to really simplify this example let's
say we've got a front end and a back end
and those are the two components that we
want to scale out and deploy to the
cluster today so kubernetes uses yamo to
kind of define the resources that are
sent to the api server which end up
creating the actual application so let's
get started with that by sketching out
what a simple yeah Mille for deploying a
pod a really small logical unit allowing
you to run a simple can
and a worker note so we'll start with
that we'll say we've got a pod and what
we need with that is an image that's
associated with it let's say that you
know it's a container we've already
pushed it up to dr. hub and we'll use my
mic right my registry for this one and
very simply let's say the name of the
application is just F for front-end
version one and one more thing that we
want to add here let's just say we've
got labels so labels are very important
and we'll talk about why in a second
here but allow us to define exactly what
type of artifact we've got here is so
for the labels we'll just say the app is
F for front-end all right so we've got
that created and what we want to do is
push it through our process to get it
into a worker node we've got here is
cube CTL cube cuddle I've heard
different ways of pronouncing that but
using that we're going to be able to
deploy the simple manifest we've got and
have it in our one of our worker nodes
so we'll push the manifest through cube
CTL it hits the API running on the
kubernetes master that in turn is going
to go and talk to one of the cubelets
because we just want to deploy one of
these pods and start it up so taking a
look let's say that it starts it up in
our first worker node here with the
label that we've given it app is front
end and one thing to note here it
actually does get an IP address as well
so let's say we get an internal IP
address that ends in a dot one so at
this point I could SSH into any of the
worker nodes and use that IP address to
hit that application so that's great for
deploying a simple application let's
take it a step further kubernetes has an
abstraction called deployments allowing
us to do something and create something
called a desired state so we can define
the number of replicas we want for that
pod and if something were to happen to
that pot and it dies it would create a
new one for us
so we've got that pod
as you know app is front-end and we want
to say that we wanted to create maybe
three replicas of that so going back to
our manifest here one thing we need to
do is tell kubernetes that we don't want
a pod we want a template for a pod right
so we'll scratch that out and we'll
create a say that this is a template for
a pod on top of that we've got a few
other things that we want right so the
number of replicas let's say we want
three we've got a selector right so we
want to tell this deployment to manage
any application deployed with that kind
of name here so we'll say Maj that
selector here again this is not entirely
valid Djamel just want to give you an
idea of the kind of artifacts that
kubernetes is looking for and the last
thing that we've got here is what kind
of artifact is this and this is going to
be a deployment all right so we've
scratched out that pod and we've got a
new manifest here what it's gonna do
we're gonna push it through cube CTL it
hits the API server now it's no it's not
an ephemeral kind of object kubernetes
needs to manage the desired State so
what it's gonna do is it's gonna manage
that deployment for as long as we have
that deployment and we don't delete it
it's going to manage that here so we'll
say that creates a deployment and since
we've got it three replicas it's always
going to ensure that we've got three
running so as soon as we got that
deployment created to realize a
something's wrong we've only got one we
need two more it's what its gonna do
it's gonna schedule out deploying that
application wherever it has resources so
we've got a lot of resources still most
of these worker nodes are empty so
decides to put one in each of the
different nodes so we've got the
deployment created and let's just say we
do the same thing for our back end here
so we'll say we'll create another
application deployment application is
back-end and for this one let's just
scale it out two times so we'll go here
application is back end and all right
everyone's happy now we need to start
thinking about communication between
these services right we talked about how
every pot has an IP address but we also
mentioned some of these pods might die
maybe you'll have to update them at some
point when when a pod goes away and
comes back it actually has a different
IP address so if we want to access one
of those pods from the back end or even
external users we need an IP address
that we can rely on and this is the
problem that's been around for a while
and service registry and service
discovery capabilities were created to
solve exactly that that comes built in
into kubernetes so what we're going to
do now is create a service to actually
create a more stable IP address so we
can access our pods as a singular kind
of app rather than individual different
services so to do that I'm going to take
a step back here and we're gonna create
a service definition around those three
pods to do that we're gonna need some
more manifests gamal so again so we'll
go back here create a new section in our
file this time we've got a kind service
and we're going to need a selector on
that and again that's gonna match the
label that we've got here and the last
thing that we need here is a type so how
do we want to actually expose this but
we'll get to that in a second by default
that type is gonna be cluster IP meaning
our services can be accessed from inside
the cluster so deploying that through
you know cube CTL hits our master goes
over here and creates that abstraction
we talked about and we can say it
created recurred another one for the
backend as well so what we get now is a
cluster IP let's just say CL IP
IP say ends in five and then another
cluster IP for our other service here
and will say that has in ends in 8.6 so
now we have a IP that we can use to
reliably do communications between these
services in addition the cube dns
service which is usually running by
default will make it even easier for
these services to access each other
they can just use their names so they
could hit each other using the name
front-end back-end or F or B for short
and so we've got that and we've talked
about how now these services could talk
to each other you know by using these
cluster IPs so communication within the
cluster is kind of solved how about when
we want to start exposing our front-end
to our end users to do that what we'll
need to do is define a type of this
service and what we want is a load
balancer there's actually other ways to
expose like node ports as well but a
load balancer essentially what it's
going to do where theses internal
internal to the actual kubernetes worker
nodes we can create an external IP now
so say external and this is this might
be you know let's say a 169 address and
now what we can do is actually expose
that directly to end-users so that they
can access that front-end by directly
using that service we talked about three
major components here today we've got
pods pods which are then deployed and
managed by deployments and then
facilitating access to those pods
created by those deployments using
services well sort of three major
components working together with the
kubernetes master and all the worker
nodes to allow you to really redefine
your DevOps workflow for deploying your
applications into a managed kubernetes
service I know we talked about a lot
today but we want to get into more
in-depth topics in our future light
boarding videos I mean for example
something like deployments so feel free
to drop a comment below leave us any
feedback definitely subscribe and stay
tuned for more light bording videos in
the future and thank you so much for
joining me today