This one-week, accelerated online class equips students to containerize workloads in Docker containers, deploy them to Kubernetes clusters provided by Google Kubernetes Engine, and scale those workloads to handle increased traffic. Students also learn how to continuously deploy new code in a Kubernetes cluster to provide application updates. At the end of the course, you will be able to: • Understand container basics • Containerize an existing application • Understand Kubernetes concepts and principles • Deploy applications to Kubernetes using the CLI • Set up a continuous delivery pipeline using Jenkins • Locate more documentation and training. To get the most of out of this course, learners should have basic proficiency with command-line tools and Linux operating system environments, as well as Web server technologies such as Nginx. We also recommend systems operations experience, including deploying and managing applications, either on-premises or in a public cloud environment. >>> By enrolling in this course you agree to the Qwiklabs Terms of Service as set out in the FAQ and located at: https://qwiklabs.com/terms_of_service <<<
Services, Labels, and Selectors
Loading...
Google Cloud의 강좌에서
Getting Started with Google Kubernetes Engine
1856개의 평가
수업에서
Kubernetes Basics
Deploy an application with microservices in a Kubernetes cluster.
강사 만나기
Google Cloud Training
Kubernetes basics.
Talking about services, labels, and selectors.
All right, so a service is assigned to a fixed IP to your pod and
then it replicates and allows other pods and other services to communicate with them.
Services really act like a way of communication between the pods, okay?
Number one, the cluster has an IP,
an internal IP, and the port nodes also have awareness of that access to that IP.
It also uses a load balancer as a bounds
for that browsing that traffic that comes into the nodes themselves.
You're going to have multiple services with
different configurations and features running.
Usually, the front end is either a web server,
application server, some kind of server,
back ends are usually the nodes and maybe a database server.
They run with usually a load balancer,
Google Cloud load balancer,
which will let you detailed what GCP API you use.
Again, a definition in YAML file will tell you the resources,
the pods you'll be using,
and then the pod selector,
and then the type of load balancer you'll be applying to this.
Labels are metadata that you can assign to any API object and represent an identity.
They are used for grouping, mechanisms, searching,
but not only that,
they're using pre-filtering, finding something.
Pods could contain a lot of entities and containers that could be in many,
many containers in your environment.
By labeling them logically,
you'll be able to quickly find them and not only that,
per mechanisms inside the pods to quickly identify them.
In this example, you have four pods and three labels,
so my application, my application,
my application, my application,
but notice the labels,
one is prod, one is test,
there's another for tests,
there's another prod, and then you have different roles underneath each.
That way, not only is it a way of segregating for reporting,
but it's also a way of mechanizing and orchestrating the container environment itself.
You could query, you could find labels, like I said,
when you need to find something in 9,000 containers,
it's going to be very handy to have a label.
And you could also use it to map the entire application to that label itself.
So, app label equals all my applications.
So an easy way to again group all your applications.
Or narrow your search, like I said.
Trying to find a needle in the haystack
of a thousand containers could be very challenging.
With tags and labels,
it could be made very, very easy.
You'll be able to similarly apply labels for your back end services also.
This is my BE server,
this is my back end server, my database, whatever.
Or, your applications test phase.
Call it test. Here you go.
Both of them are test,
you could group them together,
and you could have a red and blue or green, yellow application.
We'll talk about those later on.
But it's a way again of testing your application in
an environment without disrupting anything in production again.
And then on your production release,
like I said, make the same changes.
You could label these,
and understand that labeling is just an example right here that we're showing you,
but it's really an example and it's really a logical way of managing Kubernetes.
Kubernetes also checks whether your pod is alive or healthy.
If it gets a negative response,
or no reply, it's unhealthy.
In other words, if I'm knocking on your door and you don't open that door,
I'm going to call the police, have not come on in and probably maybe rescue,
because I know there's something wrong.
Kubernetes has that unhealthy environment already built in.
I call it, a.k.a. Doctor in a can.
Kubernetes then automatically restarts the pod if it needs restarts to see that,
if everything comes up bright.
And if everything is good,
it goes back into a healthy state.
Doctors not needed any longer, pod is up and running.
Coursera 카탈로그 살펴보기
무료로 참여해 맞춤화된 추천, 업데이트 및 제안을 받아보세요.
Coursera는 세계 최고의 교육에 대한 보편적인 접근 기회를 제공하며,
최고의 대학 및 기관들과 제휴하여 온라인 강좌를 제공합니다.
© 2019 Coursera Inc. All rights reserved.
