Shivang Goswami
Kubernetes Prow Robot
parent
c15fd708ab
commit
649c3d3f3b
|
|
@ -1,120 +0,0 @@
|
|||
---
|
||||
reviewers:
|
||||
- chenopis
|
||||
layout: docsportal
|
||||
css: /css/style_user_journeys.css
|
||||
js: https://use.fontawesome.com/4bcc658a89.js, https://cdnjs.cloudflare.com/ajax/libs/prefixfree/1.0.7/prefixfree.min.js
|
||||
title: Advanced Topics
|
||||
track: "USERS › APPLICATION DEVELOPER › ADVANCED"
|
||||
content_template: templates/user-journey-content
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< note >}}
|
||||
This page assumes that you're familiar with core Kubernetes concepts, and are comfortable deploying your own apps. If not, you should review the {{< link text="Intermediate App Developer" url="/docs/user-journeys/users/application-developer/intermediate/" >}} topics first.
|
||||
{{< /note >}}
|
||||
After checking out the current page and its linked sections, you should have a better understanding of the following:
|
||||
* Advanced features that you can leverage in your application
|
||||
* The various ways of extending the Kubernetes API
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Deploy an application with advanced features
|
||||
|
||||
Now you know the set of API objects that Kubernetes provides. Understanding the difference between a {{< glossary_tooltip term_id="daemonset" >}} and a {{< glossary_tooltip term_id="deployment" >}} is oftentimes sufficient for app deployment. That being said, it's also worth familiarizing yourself with Kubernetes's lesser known features. They can be quite powerful when applied to the right use cases.
|
||||
|
||||
#### Container-level features
|
||||
|
||||
As you may know, it's an antipattern to migrate an entire app (e.g. containerized Rails app, MySQL database, and all) into a single Pod. That being said, there are some very useful patterns that go beyond a 1:1 correspondence between a container and its Pod:
|
||||
|
||||
* **Sidecar container**: Although your Pod should still have a single main container, you can add a secondary container that acts as a helper (see a {{< link text="logging example" url="/docs/concepts/cluster-administration/logging/#sidecar-container-with-a-logging-agent" >}}). Two containers within a single Pod can communicate {{< link text="via a shared volume" url="/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/" >}}.
|
||||
* **Init containers**: *Init containers* run before any of a Pod's *app containers* (such as main and sidecar containers). {{< link text="Read more" url="/docs/concepts/workloads/pods/init-containers/" >}}, see an {{< link text="nginx server example" url="/docs/tasks/configure-pod-container/configure-pod-initialization/" >}}, and {{< link text="learn how to debug these containers" url="/docs/tasks/debug-application-cluster/debug-init-containers/" >}}.
|
||||
|
||||
#### Pod configuration
|
||||
|
||||
Usually, you use {{< glossary_tooltip text="labels" term_id="label" >}} and {{< glossary_tooltip text="annotations" term_id="annotation" >}} to attach metadata to your resources. To inject data into your resources, you'd likely create {{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}} (for nonconfidential data) or {{< glossary_tooltip text="Secrets" term_id="secret" >}} (for confidential data).
|
||||
|
||||
Below are some other, lesser-known ways of configuring your resources' Pods:
|
||||
|
||||
* **Taints and Tolerations** - These provide a way for nodes to "attract" or "repel" your Pods. They are often used when an application needs to be deployed onto specific hardware, such as GPUs for scientific computing. {{< link text="Read more" url="/docs/concepts/configuration/taint-and-toleration/" >}}.
|
||||
* **Downward API** - This allows your containers to consume information about themselves or the cluster, without being overly coupled to the Kubernetes API server. This can be achieved with {{< link text="environment variables" url="/docs/tasks/inject-data-application/environment-variable-expose-pod-information/" >}} or {{< link text="DownwardAPIVolumeFiles" url="/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/" >}}.
|
||||
* **Pod Presets** - Normally, to mount runtime requirements (such as environmental variables, ConfigMaps, and Secrets) into a resource, you specify them in the resource's configuration file. {{< link text="PodPresets" url="/docs/concepts/workloads/pods/podpreset/" >}} allow you to dynamically inject these requirements instead, when the resource is created. For instance, this allows team A to mount any number of new Secrets into the resources created by teams B and C, without requiring action from B and C. {{< link text="See an example" url="/docs/tasks/inject-data-application/podpreset/" >}}.
|
||||
|
||||
#### Additional API Objects
|
||||
|
||||
{{< note >}}
|
||||
Before setting up the following resources, check to see if they are the responsibility of your organization's {{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}}.
|
||||
{{< /note >}}
|
||||
* **{{< glossary_tooltip text="Horizontal Pod Autoscaler (HPA)" term_id="horizontal-pod-autoscaler" >}}** - These resources are a great way to automate the process of scaling your application when CPU usage or other {{< link text="custom metrics" url="https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md" >}} spike. {{< link text="See an example" url="/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/" >}} to understand how HPAs are set up.
|
||||
|
||||
* **Federated cluster objects** - If you are running an application on multiple Kubernetes clusters using *federation*, you need to deploy the federated version of the standard Kubernetes API objects. For reference, check out the guides for setting up {{< link text="Federated ConfigMaps" url="/docs/tasks/administer-federation/configmap/" >}} and {{< link text="Federated Deployments" url="/docs/tasks/administer-federation/deployment/" >}}.
|
||||
|
||||
## Extend the Kubernetes API
|
||||
|
||||
Kubernetes is designed with extensibility in mind. If the API resources and features mentioned above are not enough for your needs, there are ways to customize its behavior without having to modify core Kubernetes code.
|
||||
|
||||
#### Understand Kubernetes's default behavior
|
||||
|
||||
Before making any customizations, it's important that you understand the general abstraction behind Kubernetes API objects. Although Deployments and Secrets may seem quite different, the following concepts are true for *any* object:
|
||||
|
||||
* **Kubernetes objects are a way of storing structured data about your cluster.**
|
||||
In the case of Deployments, this data represents desired state (such as "How many replicas should be running?"), but it can also be general metadata (such as database credentials).
|
||||
* **Kubernetes objects are modified via the {{< glossary_tooltip text="Kubernetes API" term_id="kubernetes-api" >}}**.
|
||||
In other words, you can make `GET` and `POST` requests to a specific resource path (such as `<api-server-url>/api/v1/namespaces/default/deployments`) to read and write the corresponding object type.
|
||||
* **By leveraging the {{< link text="Controller pattern" url="/docs/concepts/api-extension/custom-resources/#custom-controllers" >}}, Kubernetes objects can be used to enforce desired state**. For simplicity, you can think of the Controller pattern as the following continuous loop:
|
||||
|
||||
<div class="emphasize-box" markdown="1">
|
||||
1. Check current state (number of replicas, container image, etc)
|
||||
2. Compare current state to desired state
|
||||
3. Update if there's a mismatch
|
||||
</div>
|
||||
|
||||
These states are obtained from the Kubernetes API.
|
||||
|
||||
{{< note >}}
|
||||
Not all Kubernetes objects need to have a Controller. Though Deployments trigger the cluster to make state changes, ConfigMaps act purely as storage.
|
||||
{{< /note >}}
|
||||
#### Create Custom Resources
|
||||
|
||||
Based on the ideas above, you can define a new {{< link text="Custom Resource" url="/docs/concepts/api-extension/custom-resources/#custom-resources" >}} that is just as legitimate as a Deployment. For example, you might want to define a `Backup` object for periodic backups, if `CronJobs` don't provide all the functionality you need.
|
||||
|
||||
There are two main ways of setting up custom resources:
|
||||
1. **Custom Resource Definitions (CRDs)** - This method requires the least amount of implementation work. See {{< link text="an example" url="/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/" >}}.
|
||||
2. **API aggregation** - This method requires some {{< link text="pre-configuration" url="/docs/tasks/access-kubernetes-api/configure-aggregation-layer/" >}} before you actually {{< link text="set up a separate, extension API server" url="/docs/tasks/access-kubernetes-api/setup-extension-api-server/" >}}.
|
||||
|
||||
Note that unlike standard Kubernetes objects, which rely on the built-in {{< link text="`kube-controller-manager`" url="/docs/reference/generated/kube-controller-manager/" >}}, you'll need to write and run your own {{< link text="custom controllers" url="https://github.com/kubernetes/sample-controller" >}}.
|
||||
|
||||
You may also find the following info helpful:
|
||||
* {{< link text="How to know if custom resources are right for your use case" url="/docs/concepts/api-extension/custom-resources/#should-i-use-a-configmap-or-a-custom-resource" >}}
|
||||
* {{< link text="How to decide between CRDs and API aggregation" url="/docs/concepts/api-extension/custom-resources/#choosing-a-method-for-adding-custom-resources" >}}
|
||||
|
||||
#### Service Catalog
|
||||
|
||||
If you want to consume or provide complete services (rather than individual resources), **{{< glossary_tooltip text="Service Catalog" term_id="service-catalog" >}}** provides a {{< link text="specification" url="https://github.com/openservicebrokerapi/servicebroker" >}} for doing so. These services are registered using {{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}} (see {{< link text="some examples" url="https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#example-service-brokers" >}}).
|
||||
|
||||
If you do not have a {{< glossary_tooltip text="cluster operator" term_id="cluster-operator" >}} to manage the installation of Service Catalog, you can do so using {{< link text="Helm" url="/docs/tasks/service-catalog/install-service-catalog-using-helm/" >}} or an {{< link text="installer binary" url="/docs/tasks/service-catalog/install-service-catalog-using-sc/" >}}.
|
||||
|
||||
|
||||
## Explore additional resources
|
||||
|
||||
#### References
|
||||
|
||||
The following topics are also useful for building more complex applications:
|
||||
|
||||
* {{< link text="Other points of extensibility within Kubernetes" url="/docs/concepts/overview/extending/" >}} - A conceptual overview of where you can hook into the Kubernetes architecture.
|
||||
* {{< link text="Kubernetes Client Libraries" url="/docs/reference/using-api/client-libraries/" >}} - Useful for building apps that need to interact heavily with the Kubernetes API.
|
||||
|
||||
#### What's next
|
||||
Congrats on completing the Application Developer user journey! You've covered the majority of features that Kubernetes has to offer. What now?
|
||||
|
||||
* If you'd like to suggest new features or keep up with the latest developments around Kubernetes app development, consider joining a {{< glossary_tooltip term_id="sig" >}} such as {{< link text="SIG Apps" url="https://github.com/kubernetes/community/tree/master/sig-apps" >}}.
|
||||
|
||||
* If you are interested in learning more about the inner workings of Kubernetes (e.g. networking), consider checking out the {{< link text="Cluster Operator journey" url="/docs/user-journeys/users/cluster-operator/foundational/" >}}.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
|
@ -1,260 +0,0 @@
|
|||
---
|
||||
reviewers:
|
||||
- chenopis
|
||||
layout: docsportal
|
||||
css: /css/style_user_journeys.css
|
||||
js: https://use.fontawesome.com/4bcc658a89.js, https://cdnjs.cloudflare.com/ajax/libs/prefixfree/1.0.7/prefixfree.min.js
|
||||
title: Foundational
|
||||
track: "USERS › APPLICATION DEVELOPER › FOUNDATIONAL"
|
||||
content_template: templates/user-journey-content
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
If you're a developer looking to run applications on Kubernetes, this page and its linked topics can help you get started with the fundamentals. Though this page primarily describes development workflows, {{< link text="the subsequent page in the series" url="/docs/home/?path=users&persona=app-developer&level=intermediate" >}} covers more advanced, production setups.
|
||||
|
||||
{{< note >}}
|
||||
**A quick note**<br>This app developer "user journey" is *not* a comprehensive overview of Kubernetes. It focuses more on *what* you develop, test, and deploy to Kubernetes, rather than *how* the underlying infrastructure works.<br><br>Though it's possible for a single person to manage both, in many organizations, it’s common to assign the latter to a dedicated {{< glossary_tooltip text="cluster operator" term_id="cluster-operator" >}}.
|
||||
{{< /note >}}
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
## Get started with a cluster
|
||||
|
||||
#### Web-based environment
|
||||
|
||||
If you're brand new to Kubernetes and simply want to experiment without setting up a full development environment, *web-based environments* are a good place to start:
|
||||
|
||||
* {{< link text="Kubernetes Basics" url="/docs/tutorials/kubernetes-basics/#basics-modules" >}} - Introduces you to six common Kubernetes workflows. Each section walks you through browser-based, interactive exercises complete with their own Kubernetes environment.
|
||||
|
||||
* {{< link text="Katacoda" url="https://www.katacoda.com/courses/kubernetes/playground" >}} - The playground equivalent of the environment used in *Kubernetes Basics* above. Katacoda also provides {{< link text="more advanced tutorials" url="https://www.katacoda.com/courses/kubernetes/" >}}, such as "Liveness and Readiness Healthchecks".
|
||||
|
||||
|
||||
* {{< link text="Play with Kubernetes" url="http://labs.play-with-k8s.com/" >}} - A less structured environment than the *Katacoda* playground, for those who are more comfortable with Kubernetes concepts and want to explore further. It supports the ability to spin up multiple nodes.
|
||||
|
||||
|
||||
#### Minikube (recommended)
|
||||
|
||||
Web-based environments are easy to access, but are not persistent. If you want to continue exploring Kubernetes in a workspace that you can come back to and change, *Minikube* is a good option.
|
||||
|
||||
Minikube can be installed locally, and runs a simple, single-node Kubernetes cluster inside a virtual machine (VM). This cluster is fully functioning and contains all core Kubernetes components. Many developers have found this sufficient for local application development.
|
||||
|
||||
* {{< link text="Install Minikube" url="/docs/tasks/tools/install-minikube/" >}}.
|
||||
|
||||
* {{< link text="Install kubectl" url="/docs/tasks/tools/install-kubectl/" >}}. ({{< glossary_tooltip text="What is kubectl?" term_id="kubectl" >}})
|
||||
|
||||
* *(Optional)* {{< link text="Install Docker" url="/docs/setup/production-environment/container-runtimes/#docker" >}} if you plan to run your Minikube cluster as part of a local development environment.
|
||||
|
||||
Minikube includes a Docker daemon, but if you're developing applications locally, you'll want an independent Docker instance to support your workflow. This allows you to create {{< glossary_tooltip text="containers" term_id="container" >}} and push them to a container registry.
|
||||
|
||||
{{< note >}}
|
||||
Version 1.12 is recommended for full compatibility with Kubernetes, but a few other versions are tested and known to work.
|
||||
{{< /note >}}
|
||||
|
||||
You can get basic information about your cluster with the commands `kubectl cluster-info` and `kubectl get nodes`. However, to get a good idea of what's really going on, you need to deploy an application to your cluster. This is covered in the next section.
|
||||
|
||||
#### MicroK8s
|
||||
|
||||
On Linux, *MicroK8s* is a good alternative to Minikube for a local
|
||||
install of Kubernetes:
|
||||
|
||||
* Runs on the native OS, so there is no overhead from running a virtual machine.
|
||||
* Always provides the latest stable version of Kubernetes, using built-in auto-upgrade functionality.
|
||||
* Installs in less than a minute.
|
||||
|
||||
* {{< link text="Install microk8s" url="https://microk8s.io/" >}}.
|
||||
|
||||
After you install MicroK8s, you can use its tab-completion
|
||||
functionality. All MicroK8s commands start with `microk8s.`. Type
|
||||
`microk8s.` (with the period) and then use the tab key to see a list
|
||||
of available commands.
|
||||
|
||||
It also includes commands to enable Kubernetes subsystems. For example:
|
||||
|
||||
* the Kubernetes Dashboard
|
||||
* the DNS service
|
||||
* GPU passthrough (for NVIDIA)
|
||||
* Ingress
|
||||
* Istio
|
||||
* Metrics server
|
||||
* Registry
|
||||
* Storage
|
||||
|
||||
## Deploy an application
|
||||
|
||||
#### Basic workloads
|
||||
|
||||
The following examples demonstrate the fundamentals of deploying Kubernetes apps:
|
||||
|
||||
* **Stateless apps**: {{< link text="Deploy a simple nginx server" url="/docs/tasks/run-application/run-stateless-application-deployment/" >}}.
|
||||
|
||||
* **Stateful apps**: {{< link text="Deploy a MySQL database" url="/docs/tasks/run-application/run-single-instance-stateful-application/" >}}.
|
||||
|
||||
Through these deployment tasks, you'll gain familiarity with the following:
|
||||
|
||||
* General concepts
|
||||
|
||||
* **Configuration files** - Written in YAML or JSON, these files describe the desired state of your application in terms of Kubernetes API objects. A file can include one or more API object descriptions (*manifests*). (See [the example YAML](/docs/tasks/run-application/run-stateless-application-deployment/#creating-and-exploring-an-nginx-deployment) from the stateless app).
|
||||
|
||||
* **{{< glossary_tooltip text="Pods" term_id="pod" >}}** - This is the basic unit for all of the workloads you run on Kubernetes. These workloads, such as *Deployments* and *Jobs*, are composed of one or more Pods. To learn more, check out {{< link text="this explanation of Pods and Nodes" url="/docs/tutorials/kubernetes-basics/explore-intro/" >}}.
|
||||
|
||||
* Common workload objects
|
||||
* **{{< glossary_tooltip text="Deployment" term_id="deployment" >}}** - The most common way of running *X* copies (Pods) of your application. Supports rolling updates to your container images.
|
||||
|
||||
* **{{< glossary_tooltip text="Service" term_id="service" >}}** - By itself, a Deployment can't receive traffic. Setting up a Service is one of the simplest ways to configure a Deployment to receive and loadbalance requests. Depending on the `type` of Service used, these requests can come from external client apps or be limited to apps within the same cluster. A Service is tied to a specific Deployment using {{< glossary_tooltip text="label" term_id="label" >}} selection.
|
||||
|
||||
The subsequent topics are also useful to know for basic application deployment.
|
||||
|
||||
#### Metadata
|
||||
|
||||
You can also specify custom information about your Kubernetes API objects by attaching key/value fields. Kubernetes provides two ways of doing this:
|
||||
|
||||
* **{{< glossary_tooltip text="Labels" term_id="label" >}}** - Identifying metadata that you can use to sort and select sets of API objects. Labels have many applications, including the following:
|
||||
|
||||
* *To keep the right number of replicas (Pods) running in a Deployment.* The specified label (`app: nginx` in the {{< link text="stateless app example" url="/docs/tasks/run-application/run-stateless-application-deployment/#creating-and-exploring-an-nginx-deployment" >}}) is used to stamp the Deployment's newly created Pods (as the value of the `spec.template.labels` configuration field), and to query which Pods it already manages (as the value of `spec.selector.matchLabels`).
|
||||
|
||||
* *To tie a Service to a Deployment* using the `selector` field, which is demonstrated in the {{< link text="stateful app example" url="/docs/tasks/run-application/run-single-instance-stateful-application/#deploy-mysql" >}}.
|
||||
|
||||
* *To look for specific subset of Kubernetes objects, when you are using {{< glossary_tooltip text="kubectl" term_id="kubectl" >}}.* For instance, the command `kubectl get deployments --selector=app=nginx` only displays Deployments from the nginx app.
|
||||
|
||||
* **{{< glossary_tooltip text="Annotations" term_id="annotation" >}}** - Nonidentifying metadata that you can attach to API objects, usually if you don't intend to use them for sorting purposes. These often serve as supplementary data about an app's deployment, such as Git SHAs, PR numbers, or URL pointers to observability dashboards.
|
||||
|
||||
|
||||
#### Storage
|
||||
|
||||
You'll also want to think about storage. Kubernetes provides different types of storage API objects for different storage needs:
|
||||
|
||||
* **{{< glossary_tooltip text="Volumes" term_id="volume" >}}** - Let you define storage for your cluster that is tied to the lifecycle of a Pod. It is therefore more persistent than container storage. Learn {{< link text="how to configure volume storage" url="/docs/tasks/configure-pod-container/configure-volume-storage/" >}}, or {{< link text="read more about volume storage" url="/docs/concepts/storage/volumes/" >}}.
|
||||
|
||||
* **{{< glossary_tooltip text="PersistentVolumes" term_id="persistent-volume" >}}** and **{{< glossary_tooltip text="PersistentVolumeClaims" term_id="persistent-volume-claim" >}}** - Let you define storage at the cluster level. Typically a cluster operator defines the PersistentVolume objects for the cluster, and cluster users (application developers, you) define the PersistentVolumeClaim objects that your application requires. Learn {{< link text="how to set up persistent storage for your cluster" url="/docs/tasks/configure-pod-container/configure-persistent-volume-storage/" >}} or {{< link text="read more about persistent volumes" url="/docs/concepts/storage/persistent-volumes/" >}}.
|
||||
|
||||
#### Configuration
|
||||
|
||||
To avoid having to unnecessarily rebuild your container images, you should decouple your application's *configuration data* from the code required to run it. There are a couple ways of doing this, which you should choose according to your use case:
|
||||
|
||||
<!-- Using HTML tables because the glossary_tooltip isn't compatible with the Markdown approach -->
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Approach</th>
|
||||
<th>Type of Data</th>
|
||||
<th>How it's mounted</th>
|
||||
<th>Example</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tr>
|
||||
<td><a href="/docs/tasks/inject-data-application/define-environment-variable-container/">Using a manifest's container definition</a></td>
|
||||
<td>Non-confidential</td>
|
||||
<td>Environment variable</td>
|
||||
<td>Command-line flag</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Using <b>{{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}}</b></td>
|
||||
<td>Non-confidential</td>
|
||||
<td>Environment variable OR local file</td>
|
||||
<td>nginx configuration</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Using <b>{{< glossary_tooltip text="Secrets" term_id="secret" >}}</b></td>
|
||||
<td>Confidential</td>
|
||||
<td>Environment variable OR local file</td>
|
||||
<td>Database credentials</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
{{< note >}}
|
||||
If you have any data that you want to keep private, you should be using a Secret. Otherwise there is nothing stopping that data from being exposed to malicious users.
|
||||
{{< /note >}}
|
||||
|
||||
## Understand basic Kubernetes architecture
|
||||
|
||||
As an app developer, you don't need to know everything about the inner workings of Kubernetes, but you may find it helpful to understand it at a high level.
|
||||
|
||||
#### What Kubernetes offers
|
||||
|
||||
Say that your team is deploying an ordinary Rails application. You've run some calculations and determined that you need five instances of your app running at any given time, in order to handle external traffic.
|
||||
|
||||
If you're not running Kubernetes or a similar automated system, you might find the following scenario familiar:
|
||||
|
||||
{{< note >}}
|
||||
1. One instance of your app (a complete machine instance or just a container) goes down.</li>
|
||||
|
||||
1. Because your team has monitoring set up, this pages the person on call.</li>
|
||||
|
||||
1. The on-call person has to go in, investigate, and manually spin up a new instance.</li>
|
||||
|
||||
1. Depending how your team handles DNS/networking, the on-call person may also need to also update the service discovery mechanism to point at the IP of the new Rails instance rather than the old.</li>
|
||||
{{< /note >}}
|
||||
|
||||
This process can be tedious and also inconvenient, especially if (2) happens in the early hours of the morning!
|
||||
|
||||
**If you have Kubernetes set up, however, manual intervention is not as necessary.** The Kubernetes {{< link text="control plane" url="/docs/concepts/overview/components/#master-components" >}}, which runs on your cluster's master node, gracefully handles (3) and (4) on your behalf. As a result, Kubernetes is often referred to as a *self-healing* system.
|
||||
|
||||
There are two key parts of the control plane that facilitate this behavior: the *Kubernetes API server* and the *Controllers*.
|
||||
|
||||
#### Kubernetes API server
|
||||
|
||||
For Kubernetes to be useful, it needs to know *what* sort of cluster state you want it to maintain. Your YAML or JSON *configuration files* declare this desired state in terms of one or more API objects, such as {{< glossary_tooltip text="Deployments" term_id="deployment" >}}. To make updates to your cluster's state, you submit these files to the {{< glossary_tooltip text="Kubernetes API" term_id="kubernetes-api" >}} server (`kube-apiserver`).
|
||||
|
||||
Examples of state include but are not limited to the following:
|
||||
|
||||
* The applications or other workloads to run
|
||||
* The container images for your applications and workloads
|
||||
* Allocation of network and disk resources
|
||||
|
||||
Note that the API server is just the gateway, and that object data is actually stored in a highly available datastore called {{< link text="*etcd*" url="https://github.com/coreos/etcd" >}}. For most intents and purposes, though, you can focus on the API server. Most reads and writes to cluster state take place as API requests.
|
||||
|
||||
For more information, see {{< link text="Understanding Kubernetes Objects" url="/docs/concepts/overview/working-with-objects/kubernetes-objects/" >}}.
|
||||
|
||||
#### Controllers
|
||||
|
||||
Once you’ve declared your desired state through the Kubernetes API, the *controllers* work to make the cluster’s current state match this desired state.
|
||||
|
||||
The standard controller processes are {{< link text="`kube-controller-manager`" url="/docs/reference/generated/kube-controller-manager/" >}} and {{< link text="`cloud-controller-manager`" url="/docs/concepts/overview/components/#cloud-controller-manager" >}}, but you can also write your own controllers as well.
|
||||
|
||||
All of these controllers implement a *control loop*. For simplicity, you can think of this as the following:
|
||||
|
||||
{{< note >}}
|
||||
1. What is the current state of the cluster (X)?
|
||||
|
||||
1. What is the desired state of the cluster (Y)?
|
||||
|
||||
1. X == Y ?
|
||||
|
||||
* `true` - Do nothing.
|
||||
* `false` - Perform tasks to get to Y, such as starting or restarting containers,
|
||||
or scaling the number of replicas of a given application. Return to 1.
|
||||
{{< /note >}}
|
||||
|
||||
By continuously looping, these controllers ensure the cluster can pick up new updates and avoid drifting from the desired state. These ideas are covered in more detail {{< link text="here" url="/docs/concepts/" >}}.
|
||||
|
||||
## Additional resources
|
||||
|
||||
The Kubernetes documentation is rich in detail. Here's a curated list of resources to help you start digging deeper.
|
||||
|
||||
### Basic concepts
|
||||
|
||||
* {{< link text="More about the components that run Kubernetes" url="/docs/concepts/overview/components/" >}}
|
||||
|
||||
* {{< link text="Understanding Kubernetes objects" url="/docs/concepts/overview/working-with-objects/kubernetes-objects/" >}}
|
||||
|
||||
* {{< link text="More about Node objects" url="/docs/concepts/architecture/nodes/" >}}
|
||||
|
||||
* {{< link text="More about Pod objects" url="/docs/concepts/workloads/pods/pod-overview/" >}}
|
||||
|
||||
### Tutorials
|
||||
|
||||
* {{< link text="Kubernetes Basics" url="/docs/tutorials/kubernetes-basics/" >}}
|
||||
|
||||
* {{< link text="Hello Minikube" url="/docs/tutorials/stateless-application/hello-minikube/" >}} *(Runs on Mac only)*
|
||||
|
||||
* {{< link text="Kubernetes object management" url="/docs/tutorials/object-management-kubectl/object-management/" >}}
|
||||
|
||||
### What's next
|
||||
|
||||
If you feel fairly comfortable with the topics on this page and want to learn more, check out the following user journeys:
|
||||
|
||||
* {{< link text="Intermediate App Developer" url="/docs/user-journeys/users/application-developer/intermediate/" >}} - Dive deeper, with the next level of this journey.
|
||||
* {{< link text="Foundational Cluster Operator" url="/docs/user-journeys/users/cluster-operator/foundational/" >}} - Build breadth, by exploring other journeys.
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
@ -1,166 +0,0 @@
|
|||
---
|
||||
reviewers:
|
||||
- chenopis
|
||||
layout: docsportal
|
||||
css: /css/style_user_journeys.css
|
||||
js: https://use.fontawesome.com/4bcc658a89.js, https://cdnjs.cloudflare.com/ajax/libs/prefixfree/1.0.7/prefixfree.min.js
|
||||
title: Intermediate
|
||||
track: "USERS › APPLICATION DEVELOPER › INTERMEDIATE"
|
||||
content_template: templates/user-journey-content
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< note >}}
|
||||
This page assumes that you've experimented with Kubernetes before. At this point, you should have basic experience interacting with a Kubernetes cluster (locally with Minikube, or elsewhere), and using API objects like Deployments to run your applications.<br><br>If not, you should review the {{< link text="Beginner App Developer" url="/docs/user-journeys/users/application-developer/foundational/" >}} topics first.
|
||||
{{< /note >}}
|
||||
After checking out the current page and its linked sections, you should have a better understanding of the following:
|
||||
|
||||
* Additional Kubernetes workload patterns, beyond Deployments
|
||||
* What it takes to make a Kubernetes application production-ready
|
||||
* Community tools that can improve your development workflow
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Learn additional workload patterns
|
||||
|
||||
As your Kubernetes use cases become more complex, you may find it helpful to familiarize yourself with more of the toolkit that Kubernetes provides. {{< link text="Basic workload" url="/docs/user-journeys/users/application-developer/foundational/#section-2" >}} objects like {{< glossary_tooltip text="Deployments" term_id="deployment" >}} make it straightforward to run, update, and scale applications, but they are not ideal for every scenario.
|
||||
|
||||
The following API objects provide functionality for additional workload types, whether they are *persistent* or *terminating*.
|
||||
|
||||
#### Persistent workloads
|
||||
|
||||
Like Deployments, these API objects run indefinitely on a cluster until they are manually terminated. They are best for long-running applications.
|
||||
|
||||
* **{{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}}** - Like Deployments, StatefulSets allow you to specify that a
|
||||
certain number of replicas should be running for your application.
|
||||
|
||||
{{< note >}} It's misleading to say that Deployments can't handle stateful workloads. Using {{< glossary_tooltip text="PersistentVolumes" term_id="persistent-volume" >}}, you can persist data beyond the lifecycle of any individual Pod in your Deployment.
|
||||
{{< /note >}}
|
||||
|
||||
However, StatefulSets can provide stronger guarantees about "recovery" behavior than Deployments. StatefulSets maintain a sticky, stable identity for their Pods. The following table provides some concrete examples of what this might look like:
|
||||
|
||||
| | Deployment | StatefulSet |
|
||||
|---|---|---|
|
||||
| **Example Pod name** | `example-b1c4` | `example-0` |
|
||||
| **When a Pod dies** | Reschedule on *any* node, with new name `example-a51z` | Reschedule on same node, as `example-0` |
|
||||
| **When a node becomes unreachable** | Pod(s) are scheduled onto new node, with new names | Pod(s) are marked as "Unknown", and aren't rescheduled unless the Node object is forcefully deleted |
|
||||
|
||||
In practice, this means that StatefulSets are best suited for scenarios where replicas (Pods) need to coordinate their workloads in a strongly consistent manner. Guaranteeing an identity for each Pod helps avoid {{< link text="split-brain" url="https://en.wikipedia.org/wiki/Split-brain_(computing)" >}} side effects in the case when a node becomes unreachable ({{< link text="network partition" url="https://en.wikipedia.org/wiki/Network_partition" >}}). This makes StatefulSets a great fit for distributed datastores like Cassandra or Elasticsearch.
|
||||
|
||||
|
||||
* **{{< glossary_tooltip text="DaemonSets" term_id="daemonset" >}}** - DaemonSets run continuously on every node in your cluster, even as nodes are added or swapped in. This guarantee is particularly useful for setting up global behavior across your cluster, such as:
|
||||
|
||||
* Logging and monitoring, from applications like `fluentd`
|
||||
* Network proxy or {{< link text="service mesh" url="https://www.linux.com/news/whats-service-mesh-and-why-do-i-need-one" >}}
|
||||
|
||||
|
||||
#### Terminating workloads
|
||||
|
||||
In contrast to Deployments, these API objects are finite. They stop once the specified number of Pods have completed successfully.
|
||||
|
||||
* **{{< glossary_tooltip text="Jobs" term_id="job" >}}** - You can use these for one-off tasks like running a script or setting up a work queue. These tasks can be executed sequentially or in parallel. These tasks should be relatively independent, as Jobs do not support closely communicating parallel processes. {{< link text="Read more about Job patterns" url="/docs/concepts/workloads/controllers/jobs-run-to-completion/#job-patterns" >}}.
|
||||
|
||||
* **{{< glossary_tooltip text="CronJobs" term_id="cronjob" >}}** - These are similar to Jobs, but allow you to schedule their execution for a specific time or for periodic recurrence. You might use CronJobs to send reminder emails or to run backup jobs. They are set up with a similar syntax as *crontab*.
|
||||
|
||||
#### Other resources
|
||||
|
||||
For more info, you can check out {{< link text="a list of additional Kubernetes resource types" url="/docs/reference/kubectl/overview/#resource-types" >}} as well as the {{< link text="API reference docs" url="{{ reference_docs_url }}" >}}.
|
||||
|
||||
There may be additional features not mentioned here that you may find useful, which are covered in the {{< link text="full Kubernetes documentation" url="/docs/home/?path=browse" >}}.
|
||||
|
||||
## Deploy a production-ready workload
|
||||
|
||||
The beginner tutorials on this site, such as the {{< link text="Guestbook app" url="/docs/tutorials/stateless-application/guestbook/" >}}, are geared towards getting workloads up and running on your cluster. This prototyping is great for building your intuition around Kubernetes! However, in order to reliably and securely promote your workloads to production, you need to follow some additional best practices.
|
||||
|
||||
#### Declarative configuration
|
||||
|
||||
You are likely interacting with your Kubernetes cluster via {{< glossary_tooltip text="kubectl" term_id="kubectl" >}}. kubectl can be used to debug the current state of your cluster (such as checking the number of nodes), or to modify live Kubernetes objects (such as updating a workload's replica count with `kubectl scale`).
|
||||
|
||||
When using kubectl to update your Kubernetes objects, it's important to be aware that different commands correspond to different approaches:
|
||||
|
||||
* {{< link text="Purely imperative" url="/docs/tutorials/object-management-kubectl/imperative-object-management-command/" >}}
|
||||
* {{< link text="Imperative with local configuration files" url="/docs/tutorials/object-management-kubectl/imperative-object-management-configuration/" >}} (typically YAML)
|
||||
* {{< link text="Declarative with local configuration files" url="/docs/tutorials/object-management-kubectl/declarative-object-management-configuration/" >}} (typically YAML)
|
||||
|
||||
There are pros and cons to each approach, though the declarative approach (such as `kubectl apply -f`) may be most helpful in production. With this approach, you rely on local YAML files as the source of truth about your desired state. This enables you to version control your configuration, which is helpful for code reviews and audit tracking.
|
||||
|
||||
For additional configuration best practices, familiarize yourself with {{< link text="this guide" url="/docs/concepts/configuration/overview/" >}}.
|
||||
|
||||
#### Security
|
||||
|
||||
You may be familiar with the *principle of least privilege*---if you are too generous with permissions when writing or using software, the negative effects of a compromise can escalate out of control. Would you be cautious handing out `sudo` privileges to software on your OS? If so, you should be just as careful when granting your workload permissions to the {{< glossary_tooltip text="Kubernetes API" term_id="kubernetes-api" >}} server! The API server is the gateway for your cluster's source of truth; it provides endpoints to read or modify cluster state.
|
||||
|
||||
You (or your {{< glossary_tooltip text="cluster operator" term_id="cluster-operator" >}}) can lock down API access with the following:
|
||||
|
||||
* **{{< glossary_tooltip text="ServiceAccounts" term_id="service-account" >}}** - An "identity" that your Pods can be tied to
|
||||
* **{{< glossary_tooltip text="RBAC" term_id="rbac" >}}** - One way of granting your ServiceAccount explicit permissions
|
||||
|
||||
For even more comprehensive reading about security best practices, consider checking out the following topics:
|
||||
|
||||
* {{< link text="Authentication" url="/docs/reference/access-authn-authz/authentication/" >}} (Is the user who they say they are?)
|
||||
* {{< link text="Authorization" url="/docs/admin/authorization/" >}} (Does the user actually have permissions to do what they're asking?)
|
||||
|
||||
#### Resource isolation and management
|
||||
|
||||
If your workloads are operating in a *multi-tenant* environment with multiple teams or projects, your container(s) are not necessarily running alone on their node(s). They are sharing node resources with other containers which you do not own.
|
||||
|
||||
Even if your cluster operator is managing the cluster on your behalf, it is helpful to be aware of the following:
|
||||
|
||||
* **{{< glossary_tooltip text="Namespaces" term_id="namespace" >}}**, used for isolation
|
||||
* **{{< link text="Resource quotas" url="/docs/concepts/policy/resource-quotas/" >}}**, which affect what your team's workloads can use
|
||||
* **{{< link text="Memory" url="/docs/tasks/configure-pod-container/assign-memory-resource/" >}} and {{< link text="CPU" url="/docs/tasks/configure-pod-container/assign-cpu-resource/" >}} requests**, for a given Pod or container
|
||||
* **{{< link text="Monitoring" url="/docs/tasks/debug-application-cluster/resource-usage-monitoring/" >}}**, both on the cluster level and the app level
|
||||
|
||||
This list may not be completely comprehensive, but many teams have existing processes that take care of all this. If this is not the case, you'll find the Kubernetes documentation fairly rich in detail.
|
||||
|
||||
## Improve your dev workflow with tooling
|
||||
|
||||
As an app developer, you'll likely encounter the following tools in your workflow.
|
||||
|
||||
#### kubectl
|
||||
|
||||
`kubectl` is a command-line tool that allows you to easily read or modify your Kubernetes cluster. It provides convenient, short commands for common operations like scaling app instances and getting node info. How does kubectl do this? It's basically just a user-friendly wrapper for making API requests. It's written using {{< link text="client-go" url="https://github.com/kubernetes/client-go/#client-go" >}}, the Go library for the Kubernetes API.
|
||||
|
||||
To learn about the most commonly used kubectl commands, check out the {{< link text="kubectl cheatsheet" url="/docs/reference/kubectl/cheatsheet/" >}}. It explains topics such as the following:
|
||||
|
||||
* {{< link text="kubeconfig files" url="/docs/tasks/access-application-cluster/configure-access-multiple-clusters/" >}} - Your kubeconfig file tells kubectl what cluster to talk to, and can reference multiple clusters (such as dev and prod).
|
||||
* {{< link text="The various output formats available" url="/docs/reference/kubectl/cheatsheet/#formatting-output" >}} - This is useful to know when you are using `kubectl get` to list information about certain API objects.
|
||||
|
||||
* {{< link text="The JSONPath output format" url="/docs/reference/kubectl/jsonpath/" >}} - This is related to the output formats above. JSONPath is especially useful for parsing specific subfields out of `kubectl get` output (such as the URL of a {{< glossary_tooltip text="Service" term_id="service" >}}).
|
||||
|
||||
* {{< link text="`kubectl run` vs `kubectl apply`" url="/docs/reference/kubectl/conventions/" >}} - This ties into the [declarative configuration](#declarative-configuration) discussion in the previous section.
|
||||
|
||||
For the full list of kubectl commands and their options, check out {{< link text="the reference guide" url="/docs/reference/generated/kubectl/kubectl-commands" >}}.
|
||||
|
||||
#### Helm
|
||||
|
||||
To leverage pre-packaged configurations from the community, you can use **{{< glossary_tooltip text="Helm charts" term_id="helm-chart" >}}**.
|
||||
|
||||
Helm charts package up YAML configurations for specific apps like Jenkins and Postgres. You can then install and run these apps on your cluster with minimal extra configuration. This approach makes the most sense for "off-the-shelf" components which do not require much custom implementation logic.
|
||||
|
||||
For writing your own Kubernetes app configurations, there is a {{< link text="thriving ecosystem of tools" url="https://docs.google.com/a/heptio.com/spreadsheets/d/1FCgqz1Ci7_VCz_wdh8vBitZ3giBtac_H8SBw4uxnrsE/edit?usp=drive_web" >}} that you may find useful.
|
||||
|
||||
## Explore additional resources
|
||||
|
||||
#### References
|
||||
Now that you're fairly familiar with Kubernetes, you may find it useful to browse the following reference pages. Doing so provides a high level view of what other features may exist:
|
||||
|
||||
* {{< link text="Commonly used `kubectl` commands" url="/docs/reference/kubectl/cheatsheet/" >}}
|
||||
* {{< link text="Kubernetes API reference" url="{{ reference_docs_url }}" >}}
|
||||
* {{< link text="Standardized Glossary" url="/docs/reference/glossary/" >}}
|
||||
|
||||
In addition, {{< link text="the Kubernetes Blog" url="https://kubernetes.io/blog/" >}} often has helpful posts on Kubernetes design patterns and case studies.
|
||||
|
||||
#### What's next
|
||||
If you feel fairly comfortable with the topics on this page and want to learn more, check out the following user journeys:
|
||||
|
||||
* {{< link text="Advanced App Developer" url="/docs/user-journeys/users/application-developer/advanced/" >}} - Dive deeper, with the next level of this journey.
|
||||
* {{< link text="Foundational Cluster Operator" url="/docs/user-journeys/users/cluster-operator/foundational/" >}} - Build breadth, by exploring other journeys.
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
|
@ -1,96 +0,0 @@
|
|||
---
|
||||
reviewers:
|
||||
- chenopis
|
||||
layout: docsportal
|
||||
css: /css/style_user_journeys.css
|
||||
js: https://use.fontawesome.com/4bcc658a89.js, https://cdnjs.cloudflare.com/ajax/libs/prefixfree/1.0.7/prefixfree.min.js
|
||||
title: Foundational
|
||||
track: "USERS › CLUSTER OPERATOR › FOUNDATIONAL"
|
||||
content_template: templates/user-journey-content
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
If you want to learn how to get started managing and operating a Kubernetes cluster, this page and the linked topics introduce you to the foundational concepts and tasks.
|
||||
This page introduces you to a Kubernetes cluster and key concepts to understand and manage it. The content focuses primarily on the cluster itself rather than the software running within the cluster.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
<!-- Foundational
|
||||
Nodes, Pods, Networks, Deployments, Services, ConfigMaps, Secrets
|
||||
Labels, Selectors, Annotations
|
||||
Metrics
|
||||
-->
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Get an overview of Kubernetes
|
||||
|
||||
If you have not already done so, start your understanding by reading through [What is Kubernetes?](/docs/concepts/overview/what-is-kubernetes/), which introduces a number of basic concepts and terms.
|
||||
|
||||
Kubernetes is quite flexible, and a cluster can be run in a wide variety of places. You can interact with Kubernetes entirely on your own laptop or local development machine with it running within a virtual machine. Kubernetes can also run on virtual machines hosted either locally or in a cloud provider, and you can run a Kubernetes cluster on bare metal.
|
||||
|
||||
A cluster is made up of one or more [Nodes](/docs/concepts/architecture/nodes/); where a node is a physical or virtual machine.
|
||||
If there is more than one node in your cluster then the nodes are connected with a [cluster network](/docs/concepts/cluster-administration/networking/).
|
||||
Regardless of how many nodes, all Kubernetes clusters generally have the same components, which are described in [Kubernetes Components](/docs/concepts/overview/components).
|
||||
|
||||
|
||||
## Learn about Kubernetes basics
|
||||
|
||||
A good way to become familiar with how to manage and operate a Kubernetes cluster is by setting one up.
|
||||
One of the most compact ways to experiment with a cluster is [Installing and using Minikube](/docs/tasks/tools/install-minikube/).
|
||||
Minikube is a command line tool for setting up and running a single-node cluster within a virtual machine on your local laptop or development computer. Minikube is even available through your browser at the [Katacoda Kubernetes Playground](https://www.katacoda.com/courses/kubernetes/playground).
|
||||
Katacoda provides a browser-based connection to a single-node cluster, using minikube behind the scenes, to support a number of tutorials to explore Kubernetes. You can also leverage the web-based [Play with Kubernetes](http://labs.play-with-k8s.com/) to the same ends - a temporary cluster to play with on the web.
|
||||
|
||||
You interact with Kubernetes either through a dashboard, an API, or using a command-line tool (such as `kubectl`) that interacts with the Kubernetes API.
|
||||
Be familiar with [Organizing Cluster Access](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) by using configuration files.
|
||||
The Kubernetes API exposes a number of resources that provide the building blocks and abstractions that are used to run software on Kubernetes.
|
||||
Learn more about these resources at [Understanding Kubernetes Objects](/docs/concepts/overview/working-with-objects/kubernetes-objects).
|
||||
These resources are covered in a number of articles within the Kubernetes documentation.
|
||||
|
||||
* [Pod Overview](/docs/concepts/workloads/pods/pod-overview/)
|
||||
* [Pods](/docs/concepts/workloads/pods/pod/)
|
||||
* [ReplicaSets](/docs/concepts/workloads/controllers/replicaset/)
|
||||
* [Deployments](/docs/concepts/workloads/controllers/deployment/)
|
||||
* [Garbage Collection](/docs/concepts/workloads/controllers/garbage-collection/)
|
||||
* [Container Images](/docs/concepts/containers/images/)
|
||||
* [Container Environment Variables](/docs/concepts/containers/container-environment-variables/)
|
||||
* [Labels and Selectors](/docs/concepts/overview/working-with-objects/labels/)
|
||||
* [Namespaces](/docs/concepts/overview/working-with-objects/namespaces/)
|
||||
* [Namespaces Walkthrough](/docs/tasks/administer-cluster/namespaces-walkthrough/)
|
||||
* [Services](/docs/concepts/services-networking/service/)
|
||||
* [Annotations](/docs/concepts/overview/working-with-objects/annotations/)
|
||||
* [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)
|
||||
* [Secrets](/docs/concepts/configuration/secret/)
|
||||
|
||||
As a cluster operator you may not need to use all these resources, although you should be familiar with them to understand how the cluster is being used.
|
||||
There are a number of additional resources that you should be aware of, some listed under [Intermediate Resources](/docs/user-journeys/users/cluster-operator/intermediate#section-1).
|
||||
You should also be familiar with [how to manage kubernetes resources](/docs/concepts/cluster-administration/manage-deployment/)
|
||||
and [supported versions and version skew between cluster components](/docs/setup/release/version-skew-policy/).
|
||||
|
||||
## Get information about your cluster
|
||||
|
||||
You can [access clusters using the Kubernetes API](/docs/tasks/administer-cluster/access-cluster-api/).
|
||||
If you are not already familiar with how to do this, you can review the [introductory tutorial](/docs/tutorials/kubernetes-basics/explore-intro/).
|
||||
Using `kubectl`, you can retrieve information about your Kubernetes cluster very quickly.
|
||||
To get basic information about the nodes in your cluster run the command `kubectl get nodes`.
|
||||
You can get more detailed information for the same nodes with the command `kubectl describe nodes`.
|
||||
You can see the status of the core of kubernetes with the command `kubectl get componentstatuses`.
|
||||
|
||||
Some additional resources for getting information about your cluster and how it is operating include:
|
||||
|
||||
* [Tools for Monitoring Compute, Storage, and Network Resources](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
|
||||
* [Resource metrics pipeline](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/)
|
||||
* [Metrics](/docs/concepts/cluster-administration/controller-metrics/)
|
||||
|
||||
## Explore additional resources
|
||||
|
||||
### Tutorials
|
||||
|
||||
* [Kubernetes Basics](/docs/tutorials/kubernetes-basics/)
|
||||
* [Configuring Redis with a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/)
|
||||
* Stateless Applications
|
||||
* [Deploying PHP Guestbook with Redis](/docs/tutorials/stateless-application/guestbook/)
|
||||
* [Expose an External IP address to access an application](/docs/tutorials/stateless-application/expose-external-ip-address/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
@ -1,109 +0,0 @@
|
|||
---
|
||||
reviewers:
|
||||
- chenopis
|
||||
layout: docsportal
|
||||
css: /css/style_user_journeys.css
|
||||
js: https://use.fontawesome.com/4bcc658a89.js, https://cdnjs.cloudflare.com/ajax/libs/prefixfree/1.0.7/prefixfree.min.js
|
||||
title: Intermediate
|
||||
track: "USERS > CLUSTER OPERATOR > INTERMEDIATE"
|
||||
content_template: templates/user-journey-content
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
If you are a cluster operator looking to expand your grasp of Kubernetes, this page and its linked topics extend the information provided on the [foundational cluster operator page](/docs/user-journeys/users/cluster-operator/foundational). From this page you can get information on key Kubernetes tasks needed to manage a complete production cluster.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Work with ingress, networking, storage, and workloads
|
||||
|
||||
Introductions to Kubernetes typically discuss simple stateless applications. As you move into more complex development, testing, and production environments, you need to consider more complex cases:
|
||||
|
||||
Communication: Ingress and Networking
|
||||
|
||||
* [Ingress](/docs/concepts/services-networking/ingress/)
|
||||
|
||||
Storage: Volumes and PersistentVolumes
|
||||
|
||||
* [Volumes](/docs/concepts/storage/volumes/)
|
||||
* [Persistent Volumes](/docs/concepts/storage/persistent-volumes/)
|
||||
|
||||
Workloads
|
||||
|
||||
* [DaemonSets](/docs/concepts/workloads/controllers/daemonset/)
|
||||
* [Stateful Sets](/docs/concepts/workloads/controllers/statefulset/)
|
||||
* [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/)
|
||||
* [CronJobs](/docs/concepts/workloads/controllers/cron-jobs/)
|
||||
|
||||
Pods
|
||||
|
||||
* [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/)
|
||||
* [Init Containers](/docs/concepts/workloads/pods/init-containers/)
|
||||
* [Pod Presets](/docs/concepts/workloads/pods/podpreset/)
|
||||
* [Container Lifecycle Hooks](/docs/concepts/containers/container-lifecycle-hooks/)
|
||||
|
||||
And how Pods work with scheduling, priority, disruptions:
|
||||
|
||||
* [Taints and Tolerations](/docs/concepts/configuration/taint-and-toleration/)
|
||||
* [Pods and Priority](/docs/concepts/configuration/pod-priority-preemption/)
|
||||
* [Disruptions](/docs/concepts/workloads/pods/disruptions/)
|
||||
* [Assigning Pods to Nodes](/docs/concepts/configuration/assign-pod-node/)
|
||||
* [Managing Compute Resources for Containers](/docs/concepts/configuration/manage-compute-resources-container/)
|
||||
* [Configuration Best Practices](/docs/concepts/configuration/overview/)
|
||||
|
||||
## Implement security best practices
|
||||
|
||||
Securing your cluster includes work beyond the scope of Kubernetes itself.
|
||||
|
||||
In Kubernetes, you configure access control:
|
||||
|
||||
* [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/)
|
||||
* [Authenticating](/docs/reference/access-authn-authz/authentication/)
|
||||
* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/)
|
||||
|
||||
You also configure authorization. That is, you determine not just how users and services authenticate to the API server, or whether they have access, but also what resources they have access to. Role-based access control (RBAC) is the recommended mechanism for controlling authorization to Kubernetes resources. Other authorization modes are available for more specific use cases.
|
||||
|
||||
* [Authorization Overview](/docs/reference/access-authn-authz/authorization/)
|
||||
* [Using RBAC Authorization](/docs/reference/access-authn-authz/rbac/)
|
||||
|
||||
You should create Secrets to hold sensitive data such as passwords, tokens, or keys. Be aware, however, that there are limitations to the protections that a Secret can provide. See [the Risks section of the Secrets documentation](/docs/concepts/configuration/secret/#risks).
|
||||
|
||||
<!-- TODO: Other security content? -->
|
||||
|
||||
## Implement custom logging and monitoring
|
||||
|
||||
Monitoring the health and state of your cluster is important. Collecting metrics, logging, and providing access to that information are common needs. Kubernetes provides some basic logging structure, and you may want to use additional tools to help aggregate and analyze log data.
|
||||
|
||||
Start with the [basics on Kubernetes logging](/docs/concepts/cluster-administration/logging/) to understand how containers do logging and common patterns. Cluster operators often want to add something to gather and aggregate those logs. See the following topics:
|
||||
|
||||
* [Logging Using Elasticsearch and Kibana](/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/)
|
||||
* [Logging Using Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/)
|
||||
|
||||
Like log aggregation, many clusters utilize additional software to help capture metrics and display them. There is an overview of tools at [Tools for Monitoring Compute, Storage, and Network Resources](/docs/tasks/debug-application-cluster/resource-usage-monitoring/).
|
||||
Kubernetes also supports a [resource metrics pipeline](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/) which can be used by Horizontal Pod Autoscaler with custom metrics.
|
||||
|
||||
[Prometheus](https://prometheus.io/), another {{< glossary_tooltip text="CNCF" term_id="cncf" >}} project, is a common choice to support capture and temporary collection of metrics. There are several options for installing Prometheus, including using the [stable/prometheus](https://github.com/kubernetes/charts/tree/master/stable/prometheus) [helm](https://helm.sh/) chart, and CoreOS provides a [prometheus operator](https://github.com/coreos/prometheus-operator) and [kube-prometheus](https://github.com/coreos/prometheus-operator/tree/master/contrib/kube-prometheus), which adds on Grafana dashboards and common configurations.
|
||||
|
||||
A common configuration on [Minikube](https://github.com/kubernetes/minikube) and some Kubernetes clusters uses [Heapster](https://github.com/kubernetes/heapster)
|
||||
[along with InfluxDB and Grafana](https://github.com/kubernetes/heapster/blob/master/docs/influxdb.md).
|
||||
There is a [walkthrough of how to install this configuration in your cluster](https://blog.kublr.com/how-to-utilize-the-heapster-influxdb-grafana-stack-in-kubernetes-for-monitoring-pods-4a553f4d36c9).
|
||||
As of Kubernetes 1.11, Heapster is deprecated, as per [sig-instrumentation](https://github.com/kubernetes/community/tree/master/sig-instrumentation). See [Prometheus vs. Heapster vs. Kubernetes Metrics APIs](https://brancz.com/2018/01/05/prometheus-vs-heapster-vs-kubernetes-metrics-apis/) for more information alternatives.
|
||||
|
||||
Hosted monitoring, APM, or data analytics services such as [Datadog](https://docs.datadoghq.com/integrations/kubernetes/) or [Instana](https://www.instana.com/supported-integrations/kubernetes-monitoring/) also offer Kubernetes integration.
|
||||
|
||||
## Additional resources
|
||||
|
||||
Cluster Administration:
|
||||
|
||||
* [Troubleshoot Clusters](/docs/tasks/debug-application-cluster/debug-cluster/)
|
||||
* [Debug Pods and Replication Controllers](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/)
|
||||
* [Debug Init Containers](/docs/tasks/debug-application-cluster/debug-init-containers/)
|
||||
* [Debug Stateful Sets](/docs/tasks/debug-application-cluster/debug-stateful-set/)
|
||||
* [Debug Applications](/docs/tasks/debug-application-cluster/debug-application/)
|
||||
* [Using explorer to investigate your cluster](https://github.com/kubernetes/examples/blob/master/staging/explorer/README.md)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
Loading…
Reference in New Issue