Skip to content

Commit

Permalink
Improvements to kubernetes-basics/expose-intro.html (kubernetes#3103)
Browse files Browse the repository at this point in the history 
* Massive updates to expose-intro.html

Updates to the non-interactive tutorial on exposing apps via services

* more updates to expose-intro

* fixed broken link

* fixed some wording

* removed extra space

* sub backticks for code and newline

* added small legend to fist svg

* fixed svg scaling

* removed extra div
  • Loading branch information
@mkorejo @gyliu513
mkorejo authored and gyliu513 committed Apr 26, 2017
1 parent ede6676 commit b2112c0
Show file tree
Hide file tree
Showing 2 changed files with 335 additions and 521 deletions.
213 changes: 93 additions & 120 deletions docs/tutorials/kubernetes-basics/expose-intro.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -12,126 +12,99 @@

<div class="layout" id="top">

<main class="content">

<div class="row">

<div class="col-md-8">
<h3>Objectives</h3>
<ul>
<li>Learn about Kubernetes Services.</li>
<li>Learn about Kubernetes Labels.</li>
<li>Expose an application outside Kubernetes.</li>
</ul>
</div>

<div class="col-md-8">
<h3>Kubernetes Services</h3>

<p>While Pods do have their own unique IP across the cluster, those IPs are not exposed outside Kubernetes. Taking into account that over time Pods may be terminated, deleted or replaced by other Pods, we need a way to let other Pods and applications automatically discover each other. Kubernetes addresses this by grouping Pods in Services. A Kubernetes <b>Service</b> is an abstraction layer which defines a logical set of Pods and enables external traffic exposure, load balancing and service discovery for those Pods.</p>

<p>This abstraction will allow us to expose Pods to traffic originating from outside the cluster. Services have their own unique cluster-private IP address and expose a port to receive traffic. If you choose to expose the service outside the cluster, the options are:</p>
<ul>
<li>LoadBalancer - provides a public IP address (what you would typically use when you run Kubernetes on GCP or AWS)</li>
<li>NodePort - exposes the Service on the same port on each Node of the cluster using NAT (available on all Kubernetes clusters, and in Minikube)</li>
</ul>
</div>
<div class="col-md-4">
<div class="content__box content__box_lined">
<h3>Summary:</h3>
<ul>
<li>Exposing Pods to external traffic</li>
<li>Load balancing traffic across multiple Pods</li>
<li>Using labels</li>
</ul>
</div>
<div class="content__box content__box_fill">
<p><i>
A Kubernetes Service is an abstraction layer which defines a logical set of Pods and enables external traffic exposure, load balancing and service discovery for those Pods.
</i></p>
</div>
</div>
</div>
<br>

<div class="row">
<div class="col-md-8">
<h2 style="color: #3771e3;">Services overview</h2>
</div>
</div>

<div class="row">
<div class="col-md-8">
<p><img src="/docs/tutorials/kubernetes-basics/public/images/module_04_services.svg"></p>
</div>
</div>
<br>

<div class="row">
<div class="col-md-8">

<p>A Service provides load balancing of traffic across the contained set of Pods. This is useful when a service is created to group all Pods from a specific Deployment (our application will make use of this in the next module, when we'll have multiple instances running).</p>

<p>Services are also responsible for service-discovery within the cluster (covered in <a href="/docs/user-guide/connecting-applications/#accessing-the-service">Accessing the Service</a>). This will for example allow a frontend service (like a web server) to send traffic to a backend service (like a database) without worrying about Pods.</p>

<p>Services match a set of Pods using Label Selectors, a grouping primitive that allows logical operation on Labels.</p>

</div>
<div class="col-md-4">
<div class="content__box content__box_fill">
<p><i> You can create a Service when you start a Deployment by adding --expose as a parameter for the kubectl run command </i></p>
</div>
</div>
</div>

<br>

<div class="row">
<div class="col-md-8">
<p><b>Labels</b> are key/value pairs that are attached to objects, such as Pods and you can think of them as hashtags from social media. They are used to organize related objects in a way meaningful to the users like:</p>
<ul>
<li>Production environment (production, test, dev)</li>
<li>Application version (beta, v1.3)</li>
<li>Type of service/server (frontend, backend, database)</li>
</ul>
</div>
<div class="col-md-4">
<div class="content__box content__box_fill">
<p><i> Labels are key/value pairs that are attached to objects </i></p>
</div>
</div>
</div>
<br>
<div class="row">
<div class="col-md-8">
<h2 style="color: #3771e3;">Labels</h2>
</div>
</div>

<div class="row">
<div class="col-md-8">
<p><img src="/docs/tutorials/kubernetes-basics/public/images/module_04_labels.svg"></p>
</div>
</div>
<br>
<div class="row">
<div class="col-md-8">

<p>Labels can be attached to objects at the creation time or later and can be modified at any time.
The kubectl run command sets some default Labels/Label Selectors on the new Pods/ Deployment. The link between Labels and Label Selectors defines the relationship between the Deployment and the Pods it creates.</p>

<p>Now let's expose our application with the help of a Service, and apply some new Labels.</p>
</div>
</div>
<br>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/expose-interactive/" role="button">Start Interactive Tutorial <span class="btn__next">›</span></a>
</div>
</div>

</main>

<main class="content">

<div class="row">
<div class="col-md-8">
<h3>Objectives</h3>
<ul>
<li>Learn about a Service in Kubernetes</li>
<li>Understand how labels and LabelSelector objects relate to a Service</li>
<li>Expose an application outside a Kubernetes cluster using a Service</li>
</ul>
</div>

<div class="col-md-8">
<h3>Overview of Kubernetes Services</h3>

<p>Kubernetes <a href="/docs/concepts/workloads/pods/pod-overview/">Pods</a> are mortal. Pods in fact have a <a href="/docs/concepts/workloads/pods/pod-lifecycle/">lifecycle</a>. When a worker node dies, the Pods running on the Node are also lost. A <a href="/docs/user-guide/replication-controller/#what-is-a-replicationcontroller">ReplicationController</a> might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are fungible; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function. Enter <i>Services</i>. A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. Services enable a loose coupling between dependent Pods. A Service is defined using YAML <a href="/docs/concepts/configuration/overview/#general-config-tips">(preferred)</a> or JSON, like all Kubernetes objects. The set of Pods targeted by a Service is usually determined by a <i>LabelSelector</i> (see below for why you might want a Service without including <code>selector</code> in the spec).</p>

<p>Although Pods each have a unique IP address, those IPs are not exposed outside the cluster without a Service. Services allow your applications to receive traffic. Services can be exposed in different ways by specifying a <code>type</code> in the ServiceSpec:</p>
<ul>
<li><i>ClusterIP</i> (default) - Exposes the Service on an internal IP in the cluster. This type makes the Service only reachable from within the cluster.</li>
<li><i>NodePort</i> - Exposes the Service on the same port of each selected Node in the cluster using NAT. Makes a Service accessible from outside the cluster using <code><NodeIP>:<NodePort></code>. Superset of ClusterIP.</li>
<li><i>LoadBalancer</i> - Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP to the Service. Superset of NodePort.</li>
<li><i>ExternalName</i> - Exposes the Service using an arbitrary name (specified by <code>externalName</code> in the spec) by returning a CNAME record with the name. No proxy is used. This type requires v1.7 or higher of <code>kube-dns</code>.</li>
</ul>
<p>More information about the different types of Services can be found in the <a href="/docs/tutorials/services/source-ip/">Using Source IP</a> tutorial. Also see <a href="/docs/concepts/services-networking/connect-applications-service">Connecting Applications with Services</a>.</p>
<p>Additionally, note that there are some use cases with Services that involve not defining <code>selector</code> in the spec. A Service created without <code>selector</code> will also not create the corresponding Endpoints object. This allows users to manually map a Service to specific endpoints. Another possibility why there may be no selector is you are strictly using <code>type: ExternalName</code>.</p>
</div>
<div class="col-md-4">
<div class="content__box content__box_lined">
<h3>Summary</h3>
<ul>
<li>Exposing Pods to external traffic</li>
<li>Load balancing traffic across multiple Pods</li>
<li>Using labels</li>
</ul>
</div>
<div class="content__box content__box_fill">
<p><i>A Kubernetes Service is an abstraction layer which defines a logical set of Pods and enables external traffic exposure, load balancing and service discovery for those Pods.</i></p>
</div>
</div>
</div>
<br>

<div class="row">
<div class="col-md-8">
<h3>Services and Labels</h3>
</div>
</div>

<div class="row">
<div class="col-md-8">
<p><img src="/docs/tutorials/kubernetes-basics/public/images/module_04_services.svg" width="150%" height="150%"></p>
</div>
</div>

<div class="row">
<div class="col-md-8">
<p>A Service routes traffic across a set of Pods. Services are the abstraction that allow pods to die and replicate in Kubernetes without impacting your application. Discovery and routing among dependent Pods (such as the frontend and backend components in an application) is handled by Kubernetes Services.</p>
<p>Services match a set of Pods using <a href="/docs/concepts/overview/working-with-objects/labels">labels and selectors</a>, a grouping primitive that allows logical operation on objects in Kubernetes. Labels are key/value pairs attached to objects and can be used in any number of ways:</p>
<ul>
<li>Designate objects for development, test, and production</li>
<li>Embed version tags</li>
<li>Classify an object using tags</li>
</ul>

</div>
<div class="col-md-4">
<div class="content__box content__box_fill">
<p><i>You can create a Service at the same time you create a Deployment by using<br><code>--expose</code> in kubectl.</i></p>
</div>
</div>
</div>

<br>

<div class="row">
<div class="col-md-8">
<p><img src="/docs/tutorials/kubernetes-basics/public/images/module_04_labels.svg"></p>
</div>
</div>
<br>
<div class="row">
<div class="col-md-8">
<p>Labels can be attached to objects at creation time or later on. They can be modified at any time. Let's expose our application now using a Service and apply some labels.</p>
</div>
</div>
<br>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/expose-interactive/" role="button">Start Interactive Tutorial<span class="btn__next">›</span></a>
</div>
</div>
</main>
</div>

</body>
Expand Down
Loading

0 comments on commit b2112c0

Please sign in to comment.