merge master to 1.10, with fixes (#7682)

This commit is contained in:
Jennifer Rondeau
2018-03-08 14:03:55 -05:00
committed by zacharysarah
parent 7f40782850
commit 3d79703d23
60 changed files with 26896 additions and 762 deletions
+7
View File
@@ -1,6 +1,13 @@
<<<<<<< HEAD
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> For 1.11 Features: set Milestone to 1.11 and Base Branch to release-1.11
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
||||||| merged common ancestors
=======
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> For 1.10 Features: set Milestone to 1.10 and Base Branch to release-1.10
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>>>> merge master to 1.10, with fixes (#7682)
> NOTE: After opening the PR, please *un-check and re-check* the ["Allow edits from maintainers"](https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork/) box so that maintainers can work on your patch and speed up the review process. This is a temporary workaround to address a known issue with GitHub.>
>
> Please delete this note before submitting the pull request.
+5
View File
@@ -90,8 +90,13 @@ aliases:
- bradamant3
- steveperry-53
- zacharysarah
<<<<<<< HEAD
- bradtopol
- heckj
||||||| merged common ancestors
=======
- bradtopol
>>>>>>> merge master to 1.10, with fixes (#7682)
sig-federation: #Team: Federation; e.g. Federated Clusters
- csbell
sig-gcp: #Google Cloud Platform; GH: sig-gcp-pr-reviews
+5
View File
@@ -13,11 +13,16 @@ incremental: true
safe: false
lsi: false
<<<<<<< HEAD
latest: "v1.10"
paginate: 7
paginate_path: "/blog/page:num/"
||||||| merged common ancestors
=======
latest: "v1.9"
>>>>>>> merge master to 1.10, with fixes (#7682)
defaults:
-
scope:
+5
View File
@@ -18,8 +18,13 @@ toc:
- docs/home/contribute/review-issues.md
- docs/home/contribute/style-guide.md
- docs/home/contribute/includes.md
<<<<<<< HEAD
- docs/home/contribute/localization.md
- docs/home/contribute/blog-post.md
||||||| merged common ancestors
=======
- docs/home/contribute/localization.md
>>>>>>> merge master to 1.10, with fixes (#7682)
- title: Updating Automatically Generated Reference Pages
section:
+5
View File
@@ -32,7 +32,12 @@ toc:
- docs/reference/workloads-18-19.md
- title: API Reference
<<<<<<< HEAD
landing_page: /docs/reference/generated/kubernetes-api/v1.10/
||||||| merged common ancestors
=======
landing_page: /docs/api-reference/v1.8/
>>>>>>> merge master to 1.10, with fixes (#7682)
section:
- title: v1.10
path: /docs/reference/generated/kubernetes-api/v1.10/
+13
View File
@@ -32,8 +32,14 @@ toc:
- docs/getting-started-guides/alternatives.md
- title: Hosted Solutions
<<<<<<< HEAD
landing_page: /docs/setup/pick-right-solution/#hosted-solutions
||||||| merged common ancestors
=======
landing_page: /docs/setup/hosted-solutions/overview/
>>>>>>> merge master to 1.10, with fixes (#7682)
section:
- docs/setup/hosted-solutions/overview.md
- title: Running Kubernetes on Google Kubernetes Engine
path: https://cloud.google.com/kubernetes-engine/docs/before-you-begin/
- title: Running Kubernetes on Azure Container Service
@@ -75,6 +81,13 @@ toc:
- title: Bare Metal
section:
<<<<<<< HEAD
||||||| merged common ancestors
- docs/getting-started-guides/coreos/bare_metal_offline.md
- docs/getting-started-guides/fedora/fedora_ansible_config.md
=======
- docs/getting-started-guides/coreos/bare_metal_offline.md
>>>>>>> merge master to 1.10, with fixes (#7682)
- docs/getting-started-guides/fedora/fedora_manual_config.md
- docs/getting-started-guides/fedora/flannel_multi_node_cluster.md
- docs/getting-started-guides/coreos/index.md
+6
View File
@@ -186,6 +186,7 @@ toc:
- docs/tasks/administer-cluster/configure-multiple-schedulers.md
- docs/tasks/administer-cluster/ip-masq-agent.md
- docs/tasks/administer-cluster/dns-custom-nameservers.md
<<<<<<< HEAD
<<<<<<< HEAD
- docs/tasks/administer-cluster/dns-debugging-resolution.md
- docs/tasks/administer-cluster/pvc-protection.md
@@ -193,6 +194,11 @@ toc:
||||||| merged common ancestors
- docs/tasks/administer-cluster/pvc-protection.md
=======
||||||| merged common ancestors
=======
- docs/tasks/administer-cluster/dns-debugging-resolution.md
- docs/tasks/administer-cluster/pvc-protection.md
>>>>>>> merge master to 1.10, with fixes (#7682)
- docs/tasks/administer-cluster/storage-object-in-use-protection.md
>>>>>>> add pv protection description (#7620)
+18
View File
@@ -4,8 +4,16 @@
<link rel="shortcut icon" type="image/png" href="/images/favicon.png">
<link rel="stylesheet" type="text/css" href="/css/base_fonts.css">
{% if page.case_study_styles %}<link rel="stylesheet" type="text/css" href="/css/case_study_styles.css"><!-- custom case_study_styles on -->{% else %}<link rel="stylesheet" type="text/css" href="/css/styles.css"><!-- default styles.css on -->{% endif %}
<<<<<<< HEAD
<link rel="stylesheet" type="text/css" href="https://code.jquery.com/ui/1.12.1/themes/smoothness/jquery-ui.css">
<link rel="stylesheet" type="text/css" href="https://cdnjs.cloudflare.com/ajax/libs/sweetalert/1.1.3/sweetalert.min.css">
||||||| merged common ancestors
<link rel="stylesheet" type="text/css" href="/css/jquery-ui.min.css">
<link rel="stylesheet" type="text/css" href="/css/sweetalert.css">
=======
<link rel="stylesheet" type="text/css" href="https://ajax.googleapis.com/ajax/libs/jqueryui/1.12.1/themes/smoothness/jquery-ui.css">
<link rel="stylesheet" type="text/css" href="https://cdnjs.cloudflare.com/ajax/libs/sweetalert/1.1.3/sweetalert.min.css">
>>>>>>> merge master to 1.10, with fixes (#7682)
<link rel="stylesheet" type="text/css" href="/css/callouts.css">
<link rel="stylesheet" type="text/css" href="/css/custom-jekyll/tags.css">
{% if page.deprecated %}<link rel="stylesheet" type="text/css" href="/css/deprecation-warning.css">{% endif %}
@@ -19,6 +27,7 @@
<meta name="description" content="{{ page.title }}" />
{% endif %}
<<<<<<< HEAD
<script
src="https://code.jquery.com/jquery-3.2.1.min.js"
integrity="sha256-hwg4gsxgFZhOsEEamdOYGBf13FyQuiTwlAQgxVSNgt4="
@@ -29,6 +38,15 @@
crossorigin="anonymous"></script>
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/sweetalert/1.1.3/sweetalert.min.js"></script>
||||||| merged common ancestors
<script src="/js/jquery-2.2.0.min.js"></script>
<script src="/js/jquery-ui.min.js"></script>
=======
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js"></script>
<script src="https://ajax.googleapis.com/ajax/libs/jqueryui/1.12.1/jquery-ui.min.js"></script>
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/sweetalert/1.1.3/sweetalert.min.js"></script>
>>>>>>> merge master to 1.10, with fixes (#7682)
<script src="/js/script.js"></script>
<script src="/js/custom-jekyll/tags.js"></script>
{% if page.js %}{% assign jslist = page.js | split: ',' | compact %}{% for jsurl in jslist %}<script src="{{ jsurl | strip }}"></script>
+172
View File
@@ -1206,6 +1206,7 @@
},
{
type: 0,
<<<<<<< HEAD
name: 'CloudBourne',
logo: 'cloudbourne',
link: 'https://cloudbourne.com/',
@@ -1458,6 +1459,177 @@
},
{
type: 0,
||||||| merged common ancestors
=======
name: 'CloudBourne',
logo: 'cloudbourne',
link: 'https://cloudbourne.com/',
blurb: 'Our AppZ Hybrid Cloud Platform can help you achieve your digital transformation goals using the powerful Kubernetes.'
},
{
type: 3,
name: 'BoCloud',
logo: 'bocloud',
link: 'http://www.bocloud.com.cn/en/index.html',
blurb: 'BoCloud - BeyondcentContainer'
},
{
type: 2,
name: 'Naitways',
logo: 'naitways',
link: 'https://www.naitways.com/',
blurb: 'Naitways is an Operator (AS57119), Integrator and Cloud Services Provider (our own !). We aim to provide value-added services through our mastering of the whole value chain (Infrastructure, Network, Human skills). Private and Public Cloud is available through Kubernetes managed or unmanaged.'
},
{
type: 2,
name: 'Kinvolk',
logo: 'kinvolk',
link: 'https://kinvolk.io/kubernetes/',
blurb: 'Kinvolk offers Kubernetes engineering & operations support from cluster to kernel. Leading cloud-native organizations turn to Kinvolk for deep-stack Linux expertise.'
},
{
type: 1,
name: 'Cascadeo Corporation',
logo: 'cascadeo',
link: 'http://www.cascadeo.com/',
blurb: 'Cascadeo designs, implements, and manages containerized workloads with Kubernetes, for both existing applications and greenfield development projects.'
},
{
type: 1,
name: 'Elastisys AB',
logo: 'elastisys',
link: 'https://elastisys.com/services/#kubernetes',
blurb: 'We design, build, and operate Kubernetes clusters. We are experts in highly available and self-optimizing Kubernetes infrastructures'
},
{
type: 1,
name: 'Greenfield Guild',
logo: 'greenfield',
link: 'http://greenfieldguild.com/',
blurb: 'The Greenfield Guild builds quality open source solutions on, and offers training and support for, Kubernetes in any environment.'
},
{
type: 1,
name: 'PolarSeven',
logo: 'polarseven',
link: 'https://polarseven.com/what-we-do/kubernetes/',
blurb: 'To get started up and running with Kubernetes (K8s) our PolarSeven consultants can help you with creating a fully functional dockerized environment to run and deploy your applications.'
},
{
type: 1,
name: 'Kloia',
logo: 'kloia',
link: 'https://devops-as-a-service.kloia.com/',
blurb: 'Kloia is DevOps and Microservices Consultancy company that helps its customers to migrate their environment to cloud platforms for enabling more scalable and secure environments. We use Kubernetes to provide our customers all-in-one solutions in an cloud-agnostic way.'
},
{
type: 0,
name: 'Bluefyre',
logo: 'bluefyre',
link: 'https://www.bluefyre.io',
blurb: 'Bluefyre offers a developer-first security platform that is native to Kubernetes. Bluefyre helps your development team ship secure code on Kubernetes faster!'
},
{
type: 0,
name: 'Harness',
logo: 'harness',
link: 'https://harness.io/harness-continuous-delivery/secret-sauce/smart-automation/',
blurb: 'Harness offers Continuous Delivery As-A-Service will full support for containerized apps and Kubernetes clusters.'
},
{
type: 0,
name: 'VMware - Wavefront',
logo: 'wavefront',
link: 'https://www.wavefront.com/solutions/container-monitoring/',
blurb: 'The Wavefront platform provides metrics-driven analytics and monitoring for Kubernetes and container dashboards for DevOps and developer teams delivering visibility into high-level services as well as granular container metrics.'
},
{
type: 0,
name: 'Bloombase, Inc.',
logo: 'bloombase',
link: 'https://www.bloombase.com/go/kubernetes',
blurb: 'Bloombase provides high bandwidth, defense-in-depth data-at-rest encryption to lock down Kubernetes crown-jewels at scale.'
},
{
type: 0,
name: 'Kloia',
logo: 'kloia',
link: 'https://docs.codefresh.io/docs/codefresh-kubernetes-integration-beta',
blurb: 'Kloia is DevOps and Microservices Consultancy company that helps its customers to migrate their environment to cloud platforms for enabling more scalable and secure environments. We use Kubernetes to provide our customers all-in-one solutions in an cloud-agnostic way.'
},
{
type: 0,
name: 'Kasten',
logo: 'kasten',
link: 'https://kasten.io/product/',
blurb: 'Kasten provides enterprise solutions specifically built to address the operational complexity of data management in cloud-native environments.'
},
{
type: 0,
name: 'Humio',
logo: 'humio',
link: 'https://humio.com',
blurb: 'Humio is a log aggregation database. We offer a Kubernetes integration that will give you insights to your logs across apps and instances.'
},
{
type: 0,
name: 'Outcold Solutions LLC',
logo: 'outcold',
link: 'https://www.outcoldsolutions.com/#monitoring-kubernetes',
blurb: 'Powerful Certified Splunk applications for Monitoring OpenShift, Kubernetes and Docker.'
},
{
type: 0,
name: 'SysEleven GmbH',
logo: 'syseleven',
link: 'http://www.syseleven.de/',
blurb: 'Enterprise Customers who are in need of bulletproof operations (High Performance E-Commerce and Enterprise Portals)'
},
{
type: 0,
name: 'Landoop',
logo: 'landoop',
link: 'http://lenses.stream',
blurb: 'Lenses for Apache Kafka, to deploy, manage and operate with confidence data streaming pipelines and topologies at scale with confidence and native Kubernetes integration.'
},
{
type: 0,
name: 'Redis Labs',
logo: 'redis',
link: 'https://redislabs.com/blog/getting-started-with-kubernetes-and-redis-using-redis-enterprise/',
blurb: 'Redis Enterprise extends open source Redis and delivers stable high performance and linear scaling required for building microservices on the Kubernetes platform.'
},
{
type: 3,
name: 'Diamanti',
logo: 'diamanti',
link: 'https://diamanti.com/',
blurb: 'Diamanti - Diamanti-D10'
},
{
type: 3,
name: 'Eking',
logo: 'eking',
link: 'http://www.eking-tech.com/',
blurb: 'Hainan eKing Technology Co. - eKing Cloud Container Platform'
},
{
type: 3,
name: 'Harmony Cloud',
logo: 'harmony',
link: 'http://harmonycloud.cn/products/rongqiyun/',
blurb: 'Harmonycloud - Harmonycloud Container Platform'
},
{
type: 3,
name: 'ZTE',
logo: 'zte',
link: 'https://sdnfv.zte.com.cn/zh-CN/home',
blurb: 'ZTE - TECS OpenPalette'
},
{
type: 0,
>>>>>>> merge master to 1.10, with fixes (#7682)
name: 'Logdna',
logo: 'logdna',
link: 'https://logdna.com/kubernetes',
+70
View File
@@ -1,3 +1,4 @@
<<<<<<< HEAD
<!Doctype html>
<html id="docs" class="{{ toc.bigheader }}">
@@ -64,3 +65,72 @@
</body>
</html>
||||||| merged common ancestors
=======
<!Doctype html>
<html id="docs" class="{{ toc.bigheader }}">
{% include head.html %}
<body>
{% include header.html %}
<!-- HERO -->
<section id="hero" class="light-text">
<h1>{{ toc.bigheader }}</h1>
<h5>{{ toc.abstract }}</h5>
<div id="vendorStrip" class="light-text">
<ul>
<li><a href="/docs/home/" {% if toc.bigheader == "Kubernetes Documentation" %}class="YAH"{% endif %}>HOME</a></li>
<li><a href="/docs/setup/" {% if toc.bigheader == "Setup" %}class="YAH"{% endif %}>SETUP</a></li>
<li><a href="/docs/concepts/" {% if toc.bigheader == "Concepts" %}class="YAH"{% endif %}>CONCEPTS</a></li>
<li><a href="/docs/tasks/" {% if toc.bigheader == "Tasks" %}class="YAH"{% endif %}>TASKS</a></li>
<li><a href="/docs/tutorials/" {% if toc.bigheader == "Tutorials" %}class="YAH"{% endif %}>TUTORIALS</a></li>
<li><a href="/docs/reference/" {% if toc.bigheader == "Reference Documentation" %}class="YAH"{% endif %}>REFERENCE</a></li>
</ul>
<div id="searchBox">
<input type="text" id="search" placeholder="Search" onkeydown="if (event.keyCode==13) window.location.replace('/docs/search/?q=' + this.value)" autofocus="autofocus">
</div>
</div>
</section>
{% include deprecation-warning.html %}
<section id="encyclopedia">
<div id="docsToc" style="display:none;"></div>
<div id="content">
{{ content }}
<div class="issue-button-container">
<p><a href=""><img src="https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/{{ page.path }}?pixel" alt="Analytics" /></a></p>
{% if page.url != "/404.html" and page.url != "/docs/search/" %}
{% unless page.no_issue %}
<script type="text/javascript">
PDRTJS_settings_8345992 = {
"id" : "8345992",
"unique_id" : "{{ page.url }}",
"title" : "{{ page.title }}",
"permalink" : "https://kubernetes.io{{ page.url }}"
};
(function(d,c,j){if(!document.getElementById(j)){var pd=d.createElement(c),s;pd.id=j;pd.src=('https:'==document.location.protocol)?'https://polldaddy.com/js/rating/rating.js':'http://i0.poll.fm/js/rating/rating.js';s=document.getElementsByTagName(c)[0];s.parentNode.insertBefore(pd,s);}}(document,'script','pd-rating-js'));
</script>
<a href="" onclick="window.open('https://github.com/kubernetes/website/issues/new?title=Issue%20with%20' +
'k8s.io'+window.location.pathname)" class="button issue">Create an Issue</a>
{% endunless %}
{% unless page.noedit %}
<a href="/editdocs#{{ page.path }}" class="button issue">Edit this Page</a>
{% endunless %}
{% endif %}
</div>
</div>
</section>
{% include_cached footer.html %}
{% include footer-scripts.html %}
</body>
</html>
>>>>>>> merge master to 1.10, with fixes (#7682)
+28
View File
@@ -25,9 +25,19 @@ This renders the definition of the glossary term inside a `<div>`, preserving Ma
| Name | Default | Description |
| --- | --- | --- |
<<<<<<< HEAD
| `term_id` | Not Applicable (Required) | The `id` of the glossary term whose definition will be used. (This `id` is the same as the filename of the term, i.e. `_data/glossary/<ID>.yml`.) |
| `length` | "short" | Specifies which term definition should be used ("short" for the `short-description`, "long" for `long-description`, "all" when both should be included). |
| `prepend` | "Service Catalog is" | A prefix which can be attached in front of a term's short description (which is one or more sentence fragments). |
||||||| merged common ancestors
| `term_id` | N/A (Required) | The `id` of the glossary term whose definition will be used. (This `id` is the same as the filename of the term, i.e. `_data/glossary/<ID>.yml`.) |
| `length` | "short" | Specifies which term definition should be used ("short" for the `short-definition`, "long" for `long-description`, "all" when both should be included). |
| `prepend` | "Service Catalog is" | A prefix which can be attached in front of a term's short definition (which is one or more sentence fragments). |
=======
| `term_id` | Not Applicable (Required) | The `id` of the glossary term whose definition will be used. (This `id` is the same as the filename of the term, i.e. `_data/glossary/<ID>.yml`.) |
| `length` | "short" | Specifies which term definition should be used ("short" for the `short-definition`, "long" for `long-description`, "all" when both should be included). |
| `prepend` | "Service Catalog is" | A prefix which can be attached in front of a term's short definition (which is one or more sentence fragments). |
>>>>>>> merge master to 1.10, with fixes (#7682)
#### (2) `glossary_tooltip` tag
@@ -48,8 +58,16 @@ This renders the following:
| Name | Default | Description |
| --- | --- | --- |
<<<<<<< HEAD
| `text` | the `name` of the glossary term | The text that the user will hover over to display the glossary definition. **You should include this if using the tooltip inside of a glossary term's YAML short-description.** |
| `term_id` | Not Applicable (Required) | The `id` of the associated glossary term. (This `id` is the same as the filename of the term, i.e. `_data/glossary/<ID>.yml`.) |
||||||| merged common ancestors
| `text` | the `name` of the glossary term | The text that the user will hover over to display the glossary definition. **You should include this if using the tooltip inside of a glossary term's YAML short-definition.** |
| `term_id` | N/A (Required) | The `id` of the associated glossary term. (This `id` is the same as the filename of the term, i.e. `_data/glossary/<ID>.yml`.) |
=======
| `text` | the `name` of the glossary term | The text that the user will hover over to display the glossary definition. **You should include this if using the tooltip inside of a glossary term's YAML short-definition.** |
| `term_id` | Not Applicable (Required) | The `id` of the associated glossary term. (This `id` is the same as the filename of the term, i.e. `_data/glossary/<ID>.yml`.) |
>>>>>>> merge master to 1.10, with fixes (#7682)
#### (3) `glossary_injector` tag
@@ -73,6 +91,16 @@ This renders the following:
| Name | Default | Description |
| --- | --- | --- |
| `text` | the `name` of the glossary term | The text that the user will hover over to display the glossary definition. |
<<<<<<< HEAD
| `term_id` | Not Applicable (Required) | The `id` of the glossary term whose definition will be used. (This `id` is the same as the filename of the term, i.e. `_data/glossary/<ID>.yml`.) |
| `placeholder_id` | Not Applicable (Required) | The `id` of the HTML element whose contents will be populated with the definition of `term_id` |
| `length` | "short" | Specifies which term definition should be used ("short" for the `short-description`, "long" for `long-description`, "all" when both should be included). |
||||||| merged common ancestors
| `term_id` | N/A (Required) | The `id` of the glossary term whose definition will be used. (This `id` is the same as the filename of the term, i.e. `_data/glossary/<ID>.yml`.) |
| `placeholder_id` | N/A (Required) | The `id` of the HTML element whose contents will be populated with the definition of `term_id` |
| `length` | "short" | Specifies which term definition should be used ("short" for the `short-definition`, "long" for `long-description`, "all" when both should be included). |
=======
| `term_id` | Not Applicable (Required) | The `id` of the glossary term whose definition will be used. (This `id` is the same as the filename of the term, i.e. `_data/glossary/<ID>.yml`.) |
| `placeholder_id` | Not Applicable (Required) | The `id` of the HTML element whose contents will be populated with the definition of `term_id` |
| `length` | "short" | Specifies which term definition should be used ("short" for the `short-definition`, "long" for `long-description`, "all" when both should be included). |
>>>>>>> merge master to 1.10, with fixes (#7682)
+39
View File
@@ -30,8 +30,15 @@
/docs/admin/garbage-collection/ /docs/concepts/cluster-administration/kubelet-garbage-collection/ 301
/docs/admin/ha-master-gce/ /docs/tasks/administer-cluster/highly-available-master/ 301
/docs/admin/ha-master-gce.md/ /docs/tasks/administer-cluster/highly-available-master/ 301
<<<<<<< HEAD
/docs/admin/high-availability/ /docs/admin/high-availability/building/ 301
/docs/admin/kubeadm-upgrade-1-7/ /docs/tasks/administer-cluster/upgrade-downgrade/kubeadm-upgrade-1-7/ 301
||||||| merged common ancestors
/docs/admin/kubeadm-upgrade-1-7/ /docs/tasks/administer-cluster/kubeadm-upgrade-1-7/ 301
=======
/docs/admin/high-availability/ /docs/admin/high-availability/building/ 301
/docs/admin/kubeadm-upgrade-1-7/ /docs/tasks/administer-cluster/kubeadm-upgrade-1-7/ 301
>>>>>>> merge master to 1.10, with fixes (#7682)
/docs/admin/limitrange/ /docs/tasks/administer-cluster/cpu-memory-limit/ 301
/docs/admin/limitrange/Limits/ /docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage/ 301
/docs/admin/master-node-communication/ /docs/concepts/architecture/master-node-communication/ 301
@@ -59,13 +66,38 @@
/docs/api/ /docs/concepts/overview/kubernetes-api/ 301
/docs/api-reference/labels-annotations-taints/ /docs/reference/labels-annotations-taints/ 301
<<<<<<< HEAD
||||||| merged common ancestors
/docs/api-reference/policy/v1alpha1/definitions/ https://v1-4.docs.kubernetes.io/docs/api-reference/policy/v1alpha1/definitions/ 301
/docs/api-reference/policy/v1beta1/definitions/ https://v1-4.docs.kubernetes.io/docs/api-reference/policy/v1beta1/definitions/ 301
/docs/api-reference/README/ https://v1-4.docs.kubernetes.io/docs/api-reference/README/ 301
/docs/api-reference/storage.k8s.io/v1beta1/operations/ https://v1-4.docs.kubernetes.io/docs/api-reference/storage.k8s.io/v1beta1/operations/ 301
/docs/api-reference/v1.4/* https://v1-4.docs.kubernetes.io/docs/reference/ 301
/docs/api-reference/1_5/* https://v1-5.docs.kubernetes.io/docs/reference/ 301
/docs/api-reference/v1.5/* https://v1-5.docs.kubernetes.io/docs/reference/ 301
=======
/docs/api-reference/policy/v1alpha1/definitions/ https://v1-4.docs.kubernetes.io/docs/api-reference/policy/v1alpha1/definitions/ 301
/docs/api-reference/policy/v1beta1/definitions/ https://v1-4.docs.kubernetes.io/docs/api-reference/policy/v1beta1/definitions/ 301
/docs/api-reference/README/ https://v1-4.docs.kubernetes.io/docs/api-reference/README/ 301
/docs/api-reference/storage.k8s.io/v1beta1/operations/ https://v1-4.docs.kubernetes.io/docs/api-reference/storage.k8s.io/v1beta1/operations/ 301
>>>>>>> merge master to 1.10, with fixes (#7682)
/docs/api-reference/v1.6/* https://v1-6.docs.kubernetes.io/docs/reference/ 301
/docs/api-reference/v1.7/* https://v1-7.docs.kubernetes.io/docs/reference/ 301
/docs/api-reference/v1.8/* https://v1-8.docs.kubernetes.io/docs/api-reference/v1.8/:splat 301
<<<<<<< HEAD
/docs/api-reference/v1.9/ https://v1-9.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.9/ 301
/docs/api-reference/v1/definitions/ /docs/reference/generated/kubernetes-api/v1.10/ 301
/docs/api-reference/v1/definitions.html /docs/reference/generated/kubernetes-api/v1.10/ 301
/docs/api-reference/v1/operations/ /docs/reference/generated/kubernetes-api/v1.10/ 301
||||||| merged common ancestors
/docs/api-reference/v1/definitions/ /docs/api-reference/v1.9/ 301
/docs/api-reference/v1/operations/ /docs/api-reference/v1.9/ 301
=======
/docs/api-reference/v1.9/ /docs/reference/generated/kubernetes-api/v1.9/ 301
/docs/api-reference/v1/definitions/ /docs/api-reference/v1.9/ 301
/docs/api-reference/v1/operations/ /docs/api-reference/v1.9/ 301
/docs/api-reference/v1.9/ /docs/reference/generated/kubernetes-api/v1.9/ 301
>>>>>>> merge master to 1.10, with fixes (#7682)
/docs/concepts/abstractions/controllers/garbage-collection/ /docs/concepts/workloads/controllers/garbage-collection/ 301
/docs/concepts/abstractions/controllers/statefulsets/ /docs/concepts/workloads/controllers/statefulset/ 301
@@ -337,7 +369,14 @@
/docs/user-guide/kubectl/v1.9/* https://v1-9.docs.kubernetes.io/docs/reference/generated/kubectl/kubectl-commands/:splat 301
/docs/user-guide/kubectl/v1.10/* /docs/reference/generated/kubectl/kubectl-commands/:splat 301
/docs/user-guide/kubectl-conventions/ /docs/reference/kubectl/conventions/
<<<<<<< HEAD
/docs/user-guide/kubectl-cheatsheet/ /docs/reference/kubectl/cheatsheet/
||||||| merged common ancestors
/docs/user-guide/kubectl-cheatsheet/ /docs/reference/kubectl/cheatsheet/
/docs/user-guide/kubectl/1_5/* https://v1-5.docs.kubernetes.io/docs/user-guide/kubectl/v1.5/ 301
=======
/docs/user-guide/kubectl-cheatsheet/ /docs/reference/kubectl/cheatsheet/
>>>>>>> merge master to 1.10, with fixes (#7682)
/docs/user-guide/kubectl/kubectl_*/ /docs/reference/generated/kubectl/kubectl-commands#:splat 301
/docs/user-guide/kubectl/v1.6/node_modules/* https://v1-6.docs.kubernetes.io/docs/user-guide/kubectl/v1.6/ 301
/docs/user-guide/labels/ /docs/concepts/overview/working-with-objects/labels/ 301
+929
View File
@@ -1,3 +1,4 @@
<<<<<<< HEAD
@font-face {
font-family: 'Material Icons';
font-style: normal;
@@ -958,3 +959,931 @@ padding:5%;
}
||||||| merged common ancestors
=======
body {
margin:0 auto;
}
.infobarWrapper a {
color:#303030;
}
#encyclopedia {
padding: 0px !important;
}
span .editthispage {
display: -webkit-inline-box !important;
}
.editthispage {
display: -webkit-inline-box !important;
}
h1 {
padding-top: 3% !important;
padding-bottom: 1.5% !important;
padding-left: 3% !important;
padding-right: 3% !important;
text-align: center !important;
font-size: 22pt !important;
font-weight:normal;
color:#303030;
}
.container {
width:80%;
}
.issue-button-container {
width: 75%;
margin-left: 15%;
padding-left: 1.5%;
padding-bottom: 2%;
}
.anchor {
display: block;
position: relative;
top: -50px;
visibility: hidden;
}
.pages a {
font-family: 'roboto';
font-size:11pt;
text-decoration:none !important;
letter-spacing:0.03em;
color:#606060;
}
.pages a:hover{
color:black;
}
.docstitle a{
font-family: 'roboto';
font-size:16pt;
margin-bottom:50px !important;
color:#3371e3 !important;
text-decoration:none !important;
}
.docstitle {
margin-bottom:10px !important;
}
.emphasize-box {
background-color: #dde1e4;
margin: 2% 10%;
padding-top: 20px;
padding-bottom: 5px;
}
.emphasize-box li {
font-size: 14px !important;
}
.browsedocs {
font-family: 'roboto' !important;
width:75%;
margin-top:2%;
margin-bottom:5%;
margin-left:15%;
line-height:2em;
}
.browsecolumn {
float:left;
width: 33%;
}
.browsesection {
float:left;
display:block;
width:100%;
margin:2%;
}
.pages {
width:100%;
color:#606060 !important;
}
.browseheader {
font-family: 'roboto';
text-align:center;
padding:1%;
color:white !important;
font-weight:100;
font-size:18px;
text-transform:uppercase;
font-weight:400;
background-color:#303030;
letter-spacing:0.08em;
background-repeat:repeat;
background-size:contain;
background-position:center;
}
.browseheader a{
color:white !important;
}
.topheader {
background-color: white !important;
color:#303030;
font-family: 'roboto';
text-align:center;
padding:3%;
font-weight:300;
font-size:24pt;
letter-spacing:0.06em;
}
.docssectionheaders {
background-color: #eeeeee !important;
color:#3371e3;
font-family: 'roboto';
text-align:center;
padding: 3%;
margin: 6% 0% 2% 0%;
font-weight:300;
font-size:18pt;
letter-spacing:0.06em;
}
.docscols {
width:100%;
float:left;
}
.section1 {
width:100%;
float:left;
}
.docscol1 {
background-color:#eeeeee;
padding:2%;
margin-right:2%;
width:28% !important;
display:inline-block;
float:left;
}
.docscol2 {
background-color:#ffffff;
border:1px solid #aaaaaa;
padding:2%;
width:27% !important;
float:left;
margin-right:2%;
display:inline-block;
}
.docscol3 {
background-color:#ffffff;
padding:1.5%;
width:27% !important;
display:inline-block;
float:right;
border:1px solid blue;
}
.docscoltitle {
float:left;
padding-top:%;
margin-right:2%;
padding-bottom:3%;
font-size:16pt;
line-height:20pt;
font-weight:400;
color:#3371e3;
}
.docsfullcol1 {
width:95%;
padding:2%;
margin:3%;
}
.docsfullcol2 {
width:95%;
padding:2%;
background-color:#eeeeee;
margin:3%;
}
.docsfullcol3 {
background-color:#ffffff;
padding:2%;
width:95%;
display:inline-block;
border:1px solid blue;
margin:3%;
}
.docsfullcol1icon {
width:5%;
padding:2%;
}
.docstitle2 {
padding:0%;
padding-bottom:3%;
font-size:16pt;
text-align:center;
font-weight:400;
padding-top:2%;
color:#3371e3;
}
.docsButton {
background-color:#3371e3;
color:white;
border: 2px solid #ffffff;
-moz-border-radius: 5px;
-webkit-border-radius: 5px;
border-radius: 5px; /* future proofing */
-khtml-border-radius: 5px; /* for old Konqueror browsers */
border: 2px solid #ffffff;
padding:1%;
text-decoration:none;
margin:%;
}
}
.material-icons {
font-size:50pt !important;
color:#3371e3;
}
.paths {
padding:1%;
background-color:#3371e3;
text-align:center;
}
.display-bar {
padding:1%;
background-color:#303030;
text-align:center;
font-size:18px;
font-family: 'roboto';
text-transform:uppercase;
text-align:center;
letter-spacing:0.1em;
color:#ffffff;
}
.cards {
padding:0% 3% 3%;
width:80%;
margin-left:10%;
background-color:#ffffff;
text-align:center;
font-family: 'roboto';
text-transform:uppercase;
text-align:center;
letter-spacing:0.1em;
}
.cards > div {
display: none;
}
button {
-moz-border-radius: 5px;
-webkit-border-radius: 5px;
border-radius: 5px; /* future proofing */
-khtml-border-radius: 5px; /* for old Konqueror browsers */
border: 2px solid #ffffff;
padding:1%;
margin:1%;
color:#ffffff;
font-family: 'roboto';
text-transform:uppercase;
text-align:center;
letter-spacing:0.1em;
display: inline-block;
}
.navButton {
white-space:nowrap;
-moz-border-radius: 5px;
-webkit-border-radius: 5px;
border-radius: 5px; /* future proofing */
-khtml-border-radius: 5px; /* for old Konqueror browsers */
border: 2px solid #ffffff;
padding:1%;
margin:1%;
color:#3371e3;
background-color:white;
font-family: 'roboto';
text-transform:uppercase;
text-align:center;
letter-spacing:0.1em;
display: inline-block;
cursor: pointer;
}
.navButton:active {
background-color:#3371e3;
color:white;
border: 2px solid #ffffff;
}
.navButton:visited {
background-color:#3371e3;
color:white;
border: 2px solid #ffffff;
}
.navButton:focus {
background-color:#3371e3 !important</div>;
color:white;
border: 2px solid #ffffff;
}
.navButton:hover, .keepShow {
background-color:#3371e3;
color:white;
border: 2px solid #ffffff;
}
.buttons {
background-color:#3371e3;
white-space:nowrap;
cursor:pointer;
-moz-border-radius: 5px;
-webkit-border-radius: 5px;
border-radius: 5px; /* future proofing */
-khtml-border-radius: 5px; /* for old Konqueror browsers */
border: 2px solid #ffffff;
padding:2%;
margin:1%;
color:#ffffff;
font-family: 'roboto';
text-transform:uppercase;
text-align:center;
letter-spacing:0.1em;
display: inline-block;
width:250px;
vertical-align:middle;
line-height:1.3em;
}
.buttonoption1 {
background-color:#3371e3;
-moz-border-radius: 5px;
-webkit-border-radius: 5px;
border-radius: 5px; /* future proofing */
-khtml-border-radius: 5px; /* for old Konqueror browsers */
border: 2px solid #ffffff;
padding:2%;
margin:1%;
color:#ffffff;
font-family: 'roboto';
text-transform:uppercase;
text-align:center;
letter-spacing:0.1em;
display: inline-block;
width:250px;
vertical-align:middle;
}
.buttons:active .active{
background-color:white;
color:#3371e3;
border: 2px solid #3371e3;
}
.buttons:hover {
background-color:white;
color:#3371e3;
border: 2px solid #3371e3;
cursor: pointer;
}
.buttons:target {
background-color:white;
color:#3371e3;
border: 2px solid #3371e3;
}
.buttons:visited {
background-color:white;
color:#3371e3;
border: 2px solid #3371e3;
}
.buttons.selected {
background-color:white;
color:#3371e3;
border: 2px solid #3371e3;
}
/*.keepShow {
background-color:white;
color:#3371e3;
border: 2px solid white;
}*/
.level {
background-color:#ffffff;
-moz-border-radius: 5px;
-webkit-border-radius: 5px;
border-radius: 5px; /* future proofing */
-khtml-border-radius: 5px; /* for old Konqueror browsers */
border: 2px solid #303030;
padding:0%;
padding-top:3%;
margin:1%;
margin-top:4%;
color:#303030;
font-family: 'roboto';
font-weight:100;
text-transform:none;
text-align:center;
letter-spacing:0.1em;
display: inline-block;
width:250px; cursor: pointer;
cursor: pointer;
}
.level:hover, .level.selected {
background-color:#dddddd;
-moz-border-radius: 5px;
-webkit-border-radius: 5px;
border-radius: 5px; /* future proofing */
-khtml-border-radius: 5px; /* for old Konqueror browsers */
border: 2px solid #303030;
cursor: pointer;
}
.tab1text{
padding:5%;
color:#303030;
font-size:15px;
line-height:22px;
}
.tabbottom {
background-color:#303030;
color:#ffffff;;
font-family:'roboto';
width:100%;
margin:0px;
font-size:34 !important;
}
i {
font-size:44px !important;
text-align:center;
color:#000066;
}
.infobarWrapper {
visibility: hidden;
margin-bottom:5%;
}
.infobar {
padding:0%;
background-color:#3371e3;
text-align:center;
-moz-border-radius: 5px;
-webkit-border-radius: 5px;
border-radius: 5px; /* future proofing */
-khtml-border-radius: 5px; /* for old Konqueror browsers */
border: 2px solid #ffffff;
padding:2%;
font-size:22px;
line-height:30px;
letter-spacing:0.07em;
text-transform:uppercase;
margin:3%;
font-weight:bold;
color:#ffffff;
font-family: 'roboto';
width:70%;
margin-left:15%;
margin-bottom:3%;
}
.whitebar {
-moz-border-radius: 5px;
-webkit-border-radius: 5px;
border-radius: 5px; /* future proofing */
-khtml-border-radius: 5px; /* for old Konqueror browsers */
background-color:#ffffff;
text-transform:none;
padding:3%;
letter-spacing:0.6pt;
font-size:15px;
z-index:99;
font-weight:400;
line-height:18pt;
color:#606060;
margin:1%;
text-align:left;
}
.whitebararrow{
float:right
padding:3%;
font-size:15px;
z-index:99;
font-weight:100;
line-height:18pt;
color:#606060;
margin:1%;
text-align:right;
}
.hide {
float:left;
font-size:16px;
padding-left:2%;
padding-bottom:5%;
}
.fa {
line-height:0.7em !important;
}
.infoicon {
float:left;
padding-bottom:2%;
padding-right:2%;
margin-bottom:10%:
color:#3371e3 !important;
}
.numberCircle {
display:inline-block;
line-height:0px;
border-radius:5px;
border:2px solid;
font-weight:300;
font-size:24px;
}
.numberCircle span {
display:inline-block;
padding-top:50%; padding-bottom:50%;
margin-left:12px;
margin-right:12px;
}
.docButton {
-moz-border-radius: 5px;
-webkit-border-radius: 5px;
border-radius: 5px; /* future proofing */
-khtml-border-radius: 5px; /* for old Konqueror browsers */
border: 1.5px solid #3371e3;
padding:1%;
background-color:#eeeeee;
font-size:13px;
margin:.5%;
color:#3371e3;
font-family: 'roboto';
text-transform:uppercase;
text-align:center;
letter-spacing:0.1em;
display: inline-block;
}
.docButton:hover {
border: 1.5px solid #3371e3;
background-color:#3371e3;
font-size:13px;
color:#eeeeee;
}
.tablebar {
text-align:center;
background-color:#eeeeee;
padding:1.5%;
}
.aboutsection {
background-color:white;
font-family: 'roboto';
font-weight:300 !important;
font-size:14px;
letter-spacing:0.05em;
line-height:22px;
width:70%;
margin-left:15%;
padding-bottom:5%;
}
.aboutsection p {
font-size: 16px;
text-align:center;
font-weight:300;
line-height: 1.75em;
letter-spacing: 0.1px;
margin-bottom: 0.75em;
}
.aboutsection a {
text-decoration: underline;
color:#3371e3;
font-weight:400;
}
.aboutcolumn {
float:left;
width: 50%;
text-align: center;
}
.docsection1 {
background-color:white;
font-family: 'roboto';
padding-top:3%;
padding-left:3%;
padding-right:3%;
font-weight:300 !important;
font-size:14px;
letter-spacing:0.05em;
line-height:22px;
width:65%;
margin-left:17%;
}
.cards .docsection1 {
display: block !important;
padding: 3% 3% 1%;
text-transform: none;
}
#persona-definition {
visibility: hidden;
}
.about-k8s-content {
width: 100%;
float: right;
}
.docsection1 a {
text-decoration: underline;
}
.docsection1 p {
font-size: 16px;
font-weight:300;
line-height: 1.75em;
letter-spacing: 0.1px;
margin-bottom: 0.75em;
}
.docsection1 li {
margin-bottom: 0.75em;
margin-left: 3em;
font-size: 16px;
font-weight:300;
line-height: 1.75em;
letter-spacing: 0.1px;
}
.docsection1 ol li {
list-style: decimal;
}
.docsection1 ul li {
list-style: disc;
}
.docsection1 code {
font-family: Menlo, Monaco, Consolas, 'Courier New', monospace;
font-size: 90%;
padding: 2px 4px;
color: #c7254e;
border-radius: 4px;
background-color: #f9f2f4;
}
.intro {
background-color:white;
font-family: 'roboto';
padding:3%;
font-weight:100;
font-size:14px;
letter-spacing:0.05em;
line-height:22px;
width:100%;
margin-left:10%;
}
.introtext {
float:right;
background-color:white;
font-family: 'roboto';
padding:3%;
font-weight:100;
font-size:14px;
letter-spacing:0.05em;
line-height:22px;
width:50%;
margin-left:10%;
}
.track {
background-color:#3371e3;
font-family: 'roboto';
padding:1%;
color:white;
font-weight:500;
text-align:center;
text-transform:uppercase;
font-size:16px;
letter-spacing:0.05em;
line-height:22px;
width:100%;
}
.sections {
background-color:#303030;
font-family: 'roboto';
padding:1%;
color:white;
font-weight:500;
text-align:center;
text-transform:uppercase;
font-size:18px;
letter-spacing:0.05em;
line-height:22px;
width:100%;
}
.quotedocs {
line-height:26pt;
font-size:16pt;
}
table {
width: 100%;
border: 1px solid #ccc;
border-spacing: 0;
margin-top: 30px;
margin-bottom: 30px;
}
thead, tr:nth-child(even) {
background-color: $light-grey;
}
thead {
background-color: #555;
color: white;
}
th, td {
padding: 8px;
text-align: left;
margin: 0;
border: 1px solid #ccc;
}
th {
font-weight: normal;
}
@media screen and (max-width: 640px) {
.browsecolumn {
width: 95%;
}
.paths {
margin-top : 10%;
padding:4%;
}
.navButton {
padding:2%;
}
.buttons {
padding:4%;
}
.whitebar {
padding:5%;
}
}
>>>>>>> merge master to 1.10, with fixes (#7682)
@@ -147,9 +147,16 @@ For examples of device plugin implementations, see:
* The official [NVIDIA GPU device plugin](https://github.com/NVIDIA/k8s-device-plugin)
* it requires using [nvidia-docker 2.0](https://github.com/NVIDIA/nvidia-docker) which allows you to run GPU enabled docker containers
* The [NVIDIA GPU device plugin for COS base OS](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu).
<<<<<<< HEAD
* The [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin)
* The [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin)
* The [AMD GPU device plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin)
||||||| merged common ancestors
=======
* The [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin)
>>>>>>> merge master to 1.10, with fixes (#7682)
{% endcapture %}
{% include templates/concept.md %}
@@ -1,5 +1,13 @@
---
<<<<<<< HEAD
reviewers:
||||||| merged common ancestors
approvers:
- crassirostris
=======
reviewers:
- crassirostris
>>>>>>> merge master to 1.10, with fixes (#7682)
- piosz
- x13n
title: Logging Architecture
@@ -55,7 +55,13 @@ deployment "nginx-deployment" created
Resource creation isn't the only operation that `kubectl` can perform in bulk. It can also extract resource names from configuration files in order to perform other operations, in particular to delete the same resources you created:
```shell
<<<<<<< HEAD
$ kubectl delete -f https://k8s.io/docs/concepts/cluster-administration/nginx-app.yaml
||||||| merged common ancestors
$ kubectl delete -f docs/user-guide/nginx/
=======
$ kubectl delete -f https://k8s.io/docs/concepts/cluster-administration/nginx/
>>>>>>> merge master to 1.10, with fixes (#7682)
deployment "my-nginx" deleted
service "my-nginx-svc" deleted
```
@@ -0,0 +1,19 @@
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
@@ -0,0 +1,19 @@
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
spec:
selector:
matchLabels:
app: nginx
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
+23
View File
@@ -59,6 +59,7 @@ The following controllers have cloud provider dependencies:
* Service Controller: For creating, updating and deleting cloud provider load balancers
* Volume Controller: For creating, attaching, and mounting volumes, and interacting with the cloud provider to orchestrate volumes
<<<<<<< HEAD
## Node Components
Node components run on every node, maintaining running pods and providing the Kubernetes runtime environment.
@@ -77,6 +78,28 @@ network rules on the host and performing connection forwarding.
The container runtime is the software that is responsible for running containers. Kubernetes supports several runtimes: [Docker](http://www.docker.com), [rkt](https://coreos.com/rkt/), [runc](https://github.com/opencontainers/runc) and any OCI [runtime-spec](https://github.com/opencontainers/runtime-spec) implementation.
## Addons
||||||| merged common ancestors
### addons
=======
## Node Components
Node components run on every node, maintaining running pods and providing the Kubernetes runtime environment.
### kubelet
{% glossary_definition term_id="kubelet" length="all" %}
### kube-proxy
[kube-proxy](/docs/admin/kube-proxy/) enables the Kubernetes service abstraction by maintaining
network rules on the host and performing connection forwarding.
### Container Runtime
The container runtime is the software that is responsible for running containers. Kubernetes supports two runtimes: [Docker](http://www.docker.com) and [rkt](https://coreos.com/rkt/).
## Addons
>>>>>>> merge master to 1.10, with fixes (#7682)
Addons are pods and services that implement cluster features. The pods may be managed
by Deployments, ReplicationControllers, and so on. Namespaced addon objects are created in
+44
View File
@@ -25,8 +25,16 @@ Resource quotas work like this:
status code `403 FORBIDDEN` with a message explaining the constraint that would have been violated.
- If quota is enabled in a namespace for compute resources like `cpu` and `memory`, users must specify
requests or limits for those values; otherwise, the quota system may reject pod creation. Hint: Use
<<<<<<< HEAD
the `LimitRanger` admission controller to force defaults for pods that make no compute resource requirements.
See the [walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) for an example of how to avoid this problem.
||||||| merged common ancestors
the LimitRange admission controller to force defaults for pods that make no compute resource requirements.
See the [walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) for an example to avoid this problem.
=======
the LimitRange admission controller to force defaults for pods that make no compute resource requirements.
See the [walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) for an example of how to avoid this problem.
>>>>>>> merge master to 1.10, with fixes (#7682)
Examples of policies that could be created using namespaces and quotas are:
@@ -42,8 +50,16 @@ Neither contention nor changes to quota will affect already created resources.
## Enabling Resource Quota
<<<<<<< HEAD
Resource Quota support is enabled by default for many Kubernetes distributions. It is
enabled when the apiserver `--enable-admission-plugins=` flag has `ResourceQuota` as
||||||| merged common ancestors
Resource Quota support is enabled by default for many Kubernetes distributions. It is
enabled when the apiserver `--admission-control=` flag has `ResourceQuota` as
=======
Resource quota support is enabled by default for many Kubernetes distributions. It is
enabled when the apiserver `--admission-control=` flag has `ResourceQuota` as
>>>>>>> merge master to 1.10, with fixes (#7682)
one of its arguments.
A resource quota is enforced in a particular namespace when there is a
@@ -235,6 +251,7 @@ NAME AGE
compute-resources 30s
object-counts 32s
<<<<<<< HEAD
kubectl describe quota compute-resources --namespace=myspace
Name: compute-resources
Namespace: myspace
@@ -249,6 +266,33 @@ requests.nvidia.com/gpu 0 4
kubectl describe quota object-counts --namespace=myspace
||||||| merged common ancestors
$ kubectl describe quota compute-resources --namespace=myspace
Name: compute-resources
Namespace: myspace
Resource Used Hard
-------- ---- ----
limits.cpu 0 2
limits.memory 0 2Gi
pods 0 4
requests.cpu 0 1
requests.memory 0 1Gi
$ kubectl describe quota object-counts --namespace=myspace
=======
kubectl describe quota compute-resources --namespace=myspace
Name: compute-resources
Namespace: myspace
Resource Used Hard
-------- ---- ----
limits.cpu 0 2
limits.memory 0 2Gi
pods 0 4
requests.cpu 0 1
requests.memory 0 1Gi
kubectl describe quota object-counts --namespace=myspace
>>>>>>> merge master to 1.10, with fixes (#7682)
Name: object-counts
Namespace: myspace
Resource Used Hard
@@ -175,8 +175,26 @@ The `Retain` reclaim policy allows for manual reclamation of the resource. When
1. Manually clean up the data on the associated storage asset accordingly.
1. Manually delete the associated storage asset, or if you want to reuse the same storage asset, create a new `PersistentVolume` with the storage asset definition.
<<<<<<< HEAD
#### Delete
For volume plugins that support the `Delete` reclaim policy, deletion removes both the `PersistentVolume` object from Kubernetes, as well as the associated storage asset in the external infrastructure, such as an AWS EBS, GCE PD, Azure Disk, or Cinder volume. Volumes that were dynamically provisioned inherit the [reclaim policy of their `StorageClass`](#reclaim-policy), which defaults to `Delete`. The administrator should configure the `StorageClass` according to users' expectations, otherwise the PV must be edited or patched after it is created. See [Change the Reclaim Policy of a PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/).
||||||| merged common ancestors
#### Recycling
=======
#### Delete
>>>>>>> merge master to 1.10, with fixes (#7682)
<<<<<<< HEAD
#### Recycle
**Warning:** The `Recycle` reclaim policy is deprecated. Instead, the recommended approach is to use dynamic provisioning.
{: .warning}
If supported by the underlying volume plugin, the `Recycle` reclaim policy performs a basic scrub (`rm -rf /thevolume/*`) on the volume and makes it available again for a new claim.
||||||| merged common ancestors
If supported by appropriate volume plugin, recycling performs a basic scrub (`rm -rf /thevolume/*`) on the volume and makes it available again for a new claim.
=======
For volume plugins that support the `Delete` reclaim policy, deletion removes both the `PersistentVolume` object from Kubernetes, as well as the associated storage asset in the external infrastructure, such as an AWS EBS, GCE PD, Azure Disk, or Cinder volume. Volumes that were dynamically provisioned inherit the [reclaim policy of their `StorageClass`](#reclaim-policy), which defaults to `Delete`. The administrator should configure the `StorageClass` according to users' expectations, otherwise the PV must be edited or patched after it is created. See [Change the Reclaim Policy of a PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/).
#### Recycle
@@ -185,6 +203,7 @@ For volume plugins that support the `Delete` reclaim policy, deletion removes bo
{: .warning}
If supported by the underlying volume plugin, the `Recycle` reclaim policy performs a basic scrub (`rm -rf /thevolume/*`) on the volume and makes it available again for a new claim.
>>>>>>> merge master to 1.10, with fixes (#7682)
However, an administrator can configure a custom recycler pod template using the Kubernetes controller manager command line arguments as described [here](/docs/admin/kube-controller-manager/). The custom recycler pod template must contain a `volumes` specification, as shown in the example below:
@@ -242,8 +261,16 @@ parameters:
allowVolumeExpansion: true
```
<<<<<<< HEAD
Once both feature gate and the aforementioned admission plug-in are turned on, a user can request larger volume for their `PersistentVolumeClaim`
by simply editing the claim and requesting a larger size. This in turn will trigger expansion of the volume that is backing the underlying `PersistentVolume`.
||||||| merged common ancestors
Once both feature gate and aforementioned admission plug-in are turned on, an user can request larger volume for their `PersistentVolumeClaim`
by simply editing the claim and requesting bigger size. This in turn will trigger expansion of volume that is backing underlying `PersistentVolume`.
=======
Once both feature gate and the aforementioned admission plug-in are turned on, an user can request larger volume for their `PersistentVolumeClaim`
by simply editing the claim and requesting a larger size. This in turn will trigger expansion of the volume that is backing the underlying `PersistentVolume`.
>>>>>>> merge master to 1.10, with fixes (#7682)
Under no circumstances will a new `PersistentVolume` be created to satisfy the claim. Kubernetes will instead attempt to resize the existing volume.
+100
View File
@@ -211,12 +211,50 @@ its `log_level` entry are mounted into the Pod at path "`/etc/config/log_level`"
Note that this path is derived from the volume's `mountPath` and the `path`
keyed with `log_level`.
<<<<<<< HEAD
**Important:** You must create a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) before you can use it.
{: .caution}
**Note:** A container using a ConfigMap as a [subPath](#using-subpath) volume mount will not
receive ConfigMap updates.
{: .note}
||||||| merged common ancestors
### csi
CSI stands for [Container Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md),
a specification attempting to establish an industry standard interface that
Container Orchestration Systems (COs) can use to expose arbitrary storage systems
to their container workloads.
For more information about the details, please check the
[design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md).
<!-- TODO: add link to the kubernetes extension section -->
The `csi` volume type is an in-tree CSI volume plugin for Pods to interact
with external CSI volume drivers running on the same node.
After having deployed a CSI compatible volume driver, users can use `csi` as the
volume type to mount the storage provided by the driver.
CSI persistent volume support is introduced in Kubernetes v1.9 as an alpha feature
which has to be explicitly enabled by the cluster administrator. In other words,
the cluster administrator needs to add "`CSIPersistentVolume=true`" to the
"`--feature-gates=`" flag for the apiserver, the controller-manager and the kubelet
components.
A CSI persistent volume has the following fields for users to specify:
- `driver`: A string value that specifies the name of the volume driver to use.
It has to be less than 63 characters and starts with a character. The driver
name can have '`.`', '`-`', '`_`' or digits in it.
- `volumeHandle`: A string value that uniquely identify the volume name returned
from the CSI volume plugin's `CreateVolume` call. The volume handle is then
used in all subsequent calls to the the volume driver for referencing the volume.
- `readOnly`: An optional boolean value indicating whether the volume is to be
published as read only. Default is false.
=======
**Note:** A container using a ConfigMap as a [subPath](#using-subpath) volume mount will not
receive ConfigMap updates.
{: .note}
>>>>>>> merge master to 1.10, with fixes (#7682)
### downwardAPI
@@ -1020,15 +1058,72 @@ specification, and to select the type of media to use, for clusters that have
several media types.
## Out-of-Tree Volume Plugins
<<<<<<< HEAD
The Out-of-tree volume plugins include the Container Storage Interface (`CSI`)
and `FlexVolume`. They enable storage vendors to create custom storage plugins
without adding them to the Kubernetes repository.
||||||| merged common ancestors
In addition to the previously listed volume types, storage vendors may create
custom plugins without adding it to the Kubernetes repository. This can be
achieved by using the `FlexVolume` plugin.
=======
In addition to the previously listed volume types, storage vendors may create
custom plugins without adding it to the Kubernetes repository. This can be
achieved by using either the `CSI` plugin or the `FlexVolume` plugin.
For storage vendors looking to create an out-of-tree volume plugin, [please refer to this FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md) for choosing between the plugin options.
### CSI
>>>>>>> merge master to 1.10, with fixes (#7682)
<<<<<<< HEAD
Before the introduction of `CSI` and `FlexVolume`, all volume plugins (like
volume types listed above) were "in-tree" meaning they were built, linked,
compiled, and shipped with the core Kubernetes binaries and extend the core
Kubernetes API. This meant that adding a new storage system to Kubernetes (a
volume plugin) required checking code into the core Kubernetes code repository.
||||||| merged common ancestors
`FlexVolume` enables users to mount vendor volumes into a pod. The vendor plugin
is implemented using a driver, an executable supporting a list of volume commands
defined by the `FlexVolume` API. Drivers must be installed in a pre-defined
volume plugin path on each node.
=======
CSI stands for [Container Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md),
a specification attempting to establish an industry standard interface that
container orchestration systems can use to expose arbitrary storage systems
to their container workloads.
Please read
[CSI design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md) for further information.
<!-- TODO: add link to the kubernetes extension section -->
The `csi` volume type is an in-tree CSI volume plugin for Pods to interact
with external CSI volume drivers running on the same node.
After having deployed a CSI compatible volume driver, users can use `csi` as the
volume type to mount the storage provided by the driver.
CSI persistent volume support is an alpha feature in Kubernetes v1.9 and requires a
cluster administrator to enable it. To enable CSI persistent volume support, the
cluster administrator adds `CSIPersistentVolume=true` to the `--feature-gates` flag
for apiserver, controller-manager, and kubelet.
The following fields are available to storage administrators to configure a CSI
persistent volume:
- `driver`: A string value that specifies the name of the volume driver to use.
It has to be less than 63 characters and starts with a character. The driver
name can have '`.`', '`-`', '`_`' or digits in it.
- `volumeHandle`: A string value that uniquely identify the volume name returned
from the CSI volume plugin's `CreateVolume` call. The volume handle is then
used in all subsequent calls to the volume driver for referencing the volume.
- `readOnly`: An optional boolean value indicating whether the volume is to be
published as read only. Default is false.
### FlexVolume
`FlexVolume` enables users to mount vendor volumes into a pod. The vendor plugin
is implemented using a driver, an executable supporting a list of volume commands
defined by the `FlexVolume` API. Drivers must be installed in a pre-defined
volume plugin path on each node. Pods interact with FlexVolume drivers through the `flexVolume` in-tree plugin.
>>>>>>> merge master to 1.10, with fixes (#7682)
Both `CSI` and `FlexVolume` allow volume plugins to be developed independent of
the Kubernetes code base, and deployed (installed) on Kubernetes clusters as
@@ -1047,6 +1142,7 @@ Kubernetes) to expose arbitrary storage systems to their container workloads.
Please read the [CSI design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md) for more information.
<<<<<<< HEAD
CSI support was introduced as alpha in Kubernetes v1.9 and moved to beta in
Kubernets v1.10.
@@ -1114,6 +1210,10 @@ plugin path on each node (and in some cases master).
Pods interact with FlexVolume drivers through the `flexVolume` in-tree plugin.
More details can be found [here](https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md).
||||||| merged common ancestors
=======
>>>>>>> merge master to 1.10, with fixes (#7682)
## Mount propagation
{% assign for_k8s_version="v1.10" %}{% include feature-state-beta.md %}
@@ -0,0 +1,688 @@
---
reviewers:
- erictune
- thockin
title: Offline
---
Deploy a CoreOS running Kubernetes environment. This particular guide is made to help those in an OFFLINE system, whether for testing a POC before the real deal, or you are restricted to be totally offline for your applications.
* TOC
{:toc}
## Prerequisites
1. Installed *CentOS 6* for PXE server
2. At least two bare metal nodes to work with
## High Level Design
1. Manage the tftp directory
* /tftpboot/(coreos)(centos)(RHEL)
* /tftpboot/pxelinux.0/(MAC) -> linked to Linux image config file
2. Update per install the link for pxelinux
3. Update the DHCP config to reflect the host needing deployment
4. Setup nodes to deploy CoreOS creating an etcd cluster.
5. Have no access to the public [etcd discovery tool](https://discovery.etcd.io/).
6. Installing the CoreOS slaves to become Kubernetes nodes.
## This Guides variables
| Node Description | MAC | IP |
| :---------------------------- | :---------------: | :---------: |
| CoreOS/etcd/Kubernetes Master | d0:00:67:13:0d:00 | 10.20.30.40 |
| CoreOS Slave 1 | d0:00:67:13:0d:01 | 10.20.30.41 |
| CoreOS Slave 2 | d0:00:67:13:0d:02 | 10.20.30.42 |
## Setup PXELINUX CentOS
To setup CentOS PXELINUX environment there is a complete [guide here](http://docs.fedoraproject.org/en-US/Fedora/7/html/Installation_Guide/ap-pxe-server.html). This section is the abbreviated version.
1. Install packages needed on CentOS
sudo yum install tftp-server dhcp syslinux
2. `vi /etc/xinetd.d/tftp` to enable tftp service and change disable to 'no'
-disable = no
3. Copy over the syslinux images we will need.
su -
mkdir -p /tftpboot
cd /tftpboot
cp /usr/share/syslinux/pxelinux.0 /tftpboot
cp /usr/share/syslinux/menu.c32 /tftpboot
cp /usr/share/syslinux/memdisk /tftpboot
cp /usr/share/syslinux/mboot.c32 /tftpboot
cp /usr/share/syslinux/chain.c32 /tftpboot
/sbin/service dhcpd start
/sbin/service xinetd start
/sbin/chkconfig tftp on
4. Setup default boot menu
mkdir /tftpboot/pxelinux.cfg
touch /tftpboot/pxelinux.cfg/default
5. Edit the menu `vi /tftpboot/pxelinux.cfg/default`
default menu.c32
prompt 0
timeout 15
ONTIMEOUT local
display boot.msg
MENU TITLE Main Menu
LABEL local
MENU LABEL Boot local hard drive
LOCALBOOT 0
Now you should have a working PXELINUX setup to image CoreOS nodes. You can verify the services by using VirtualBox locally or with bare metal servers.
## Adding CoreOS to PXE
This section describes how to setup the CoreOS images to live alongside a pre-existing PXELINUX environment.
1. Find or create the TFTP root directory that everything will be based on.
- For this document we will assume `/tftpboot/` is our root directory.
2. Once we know and have our tftp root directory we will create a new directory structure for our CoreOS images.
3. Download the CoreOS PXE files provided by the CoreOS team.
MY_TFTPROOT_DIR=/tftpboot
mkdir -p $MY_TFTPROOT_DIR/images/coreos/
cd $MY_TFTPROOT_DIR/images/coreos/
wget http://stable.release.core-os.net/amd64-usr/current/coreos_production_pxe.vmlinuz
wget http://stable.release.core-os.net/amd64-usr/current/coreos_production_pxe.vmlinuz.sig
wget http://stable.release.core-os.net/amd64-usr/current/coreos_production_pxe_image.cpio.gz
wget http://stable.release.core-os.net/amd64-usr/current/coreos_production_pxe_image.cpio.gz.sig
gpg --verify coreos_production_pxe.vmlinuz.sig
gpg --verify coreos_production_pxe_image.cpio.gz.sig
4. Edit the menu `vi /tftpboot/pxelinux.cfg/default` again
default menu.c32
prompt 0
timeout 300
ONTIMEOUT local
display boot.msg
MENU TITLE Main Menu
LABEL local
MENU LABEL Boot local hard drive
LOCALBOOT 0
MENU BEGIN CoreOS Menu
LABEL coreos-master
MENU LABEL CoreOS Master
KERNEL images/coreos/coreos_production_pxe.vmlinuz
APPEND initrd=images/coreos/coreos_production_pxe_image.cpio.gz cloud-config-url=http://<xxx.xxx.xxx.xxx>/pxe-cloud-config-single-master.yml
LABEL coreos-slave
MENU LABEL CoreOS Slave
KERNEL images/coreos/coreos_production_pxe.vmlinuz
APPEND initrd=images/coreos/coreos_production_pxe_image.cpio.gz cloud-config-url=http://<xxx.xxx.xxx.xxx>/pxe-cloud-config-slave.yml
MENU END
This configuration file will now boot from local drive but have the option to PXE image CoreOS.
## DHCP configuration
This section covers configuring the DHCP server to hand out our new images. In this case we are assuming that there are other servers that will boot alongside other images.
1. Add the `filename` to the _host_ or _subnet_ sections.
filename "/tftpboot/pxelinux.0";
2. At this point we want to make pxelinux configuration files that will be the templates for the different CoreOS deployments.
subnet 10.20.30.0 netmask 255.255.255.0 {
next-server 10.20.30.242;
option broadcast-address 10.20.30.255;
filename "<other default image>";
...
# http://www.syslinux.org/wiki/index.php/PXELINUX
host core_os_master {
hardware ethernet d0:00:67:13:0d:00;
option routers 10.20.30.1;
fixed-address 10.20.30.40;
option domain-name-servers 10.20.30.242;
filename "/pxelinux.0";
}
host core_os_slave {
hardware ethernet d0:00:67:13:0d:01;
option routers 10.20.30.1;
fixed-address 10.20.30.41;
option domain-name-servers 10.20.30.242;
filename "/pxelinux.0";
}
host core_os_slave2 {
hardware ethernet d0:00:67:13:0d:02;
option routers 10.20.30.1;
fixed-address 10.20.30.42;
option domain-name-servers 10.20.30.242;
filename "/pxelinux.0";
}
...
}
We will be specifying the node configuration later in the guide.
## Kubernetes
To deploy our configuration we need to create an `etcd` master. To do so we want to pxe CoreOS with a specific cloud-config.yml. There are two options we have here.
1. Is to template the cloud config file and programmatically create new static configs for different cluster setups.
2. Have a service discovery protocol running in our stack to do auto discovery.
This demo we just make a static single `etcd` server to host our Kubernetes and `etcd` master servers.
Since we are OFFLINE here most of the helping processes in CoreOS and Kubernetes are then limited. To do our setup we will then have to download and serve up our binaries for Kubernetes in our local environment.
An easy solution is to host a small web server on the DHCP/TFTP host for all our binaries to make them available to the local CoreOS PXE machines.
To get this up and running we are going to setup a simple `apache` server to serve our binaries needed to bootstrap Kubernetes.
This is on the PXE server from the previous section:
```shell
rm /etc/httpd/conf.d/welcome.conf
cd /var/www/html/
wget -O kube-register https://github.com/kelseyhightower/kube-register/releases/download/v0.0.2/kube-register-0.0.2-linux-amd64
wget -O setup-network-environment https://github.com/kelseyhightower/setup-network-environment/releases/download/v1.0.0/setup-network-environment
wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kubernetes
wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kube-apiserver
wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kube-controller-manager
wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kube-scheduler
wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kubectl
wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kubecfg
wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kubelet
wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kube-proxy
wget -O flanneld https://storage.googleapis.com/k8s/flanneld
```
This sets up our binaries we need to run Kubernetes. This would need to be enhanced to download from the Internet for updates in the future.
Now for the good stuff!
## Cloud Configs
The following config files are tailored for the OFFLINE version of a Kubernetes deployment.
These are based on the work found here: [master.yml](/docs/getting-started-guides/coreos/cloud-configs/master.yaml), [node.yml](/docs/getting-started-guides/coreos/cloud-configs/node.yaml)
To make the setup work, you need to replace a few placeholders:
- Replace `<PXE_SERVER_IP>` with your PXE server ip address (e.g. 10.20.30.242)
- Replace `<MASTER_SERVER_IP>` with the Kubernetes master ip address (e.g. 10.20.30.40)
- If you run a private docker registry, replace `rdocker.example.com` with your docker registry dns name.
- If you use a proxy, replace `rproxy.example.com` with your proxy server (and port)
- Add your own SSH public key(s) to the cloud config at the end
### master.yml
On the PXE server make and fill in the variables `vi /var/www/html/coreos/pxe-cloud-config-master.yml`.
```yaml
#cloud-config
---
write_files:
- path: /opt/bin/waiter.sh
owner: root
content: |
#! /usr/bin/bash
until curl http://127.0.0.1:4001/v2/machines; do sleep 2; done
- path: /opt/bin/kubernetes-download.sh
owner: root
permissions: 0755
content: |
#! /usr/bin/bash
/usr/bin/wget -N -P "/opt/bin" "http://<PXE_SERVER_IP>/kubectl"
/usr/bin/wget -N -P "/opt/bin" "http://<PXE_SERVER_IP>/kubernetes"
/usr/bin/wget -N -P "/opt/bin" "http://<PXE_SERVER_IP>/kubecfg"
chmod +x /opt/bin/*
- path: /etc/profile.d/opt-path.sh
owner: root
permissions: 0755
content: |
#! /usr/bin/bash
PATH=$PATH/opt/bin
coreos:
units:
- name: 10-eno1.network
runtime: true
content: |
[Match]
Name=eno1
[Network]
DHCP=yes
- name: 20-nodhcp.network
runtime: true
content: |
[Match]
Name=en*
[Network]
DHCP=none
- name: get-kube-tools.service
runtime: true
command: start
content: |
[Service]
ExecStartPre=-/usr/bin/mkdir -p /opt/bin
ExecStart=/opt/bin/kubernetes-download.sh
RemainAfterExit=yes
Type=oneshot
- name: setup-network-environment.service
command: start
content: |
[Unit]
Description=Setup Network Environment
Documentation=https://github.com/kelseyhightower/setup-network-environment
Requires=network-online.target
After=network-online.target
[Service]
ExecStartPre=-/usr/bin/mkdir -p /opt/bin
ExecStartPre=/usr/bin/wget -N -P /opt/bin http://<PXE_SERVER_IP>/setup-network-environment
ExecStartPre=/usr/bin/chmod +x /opt/bin/setup-network-environment
ExecStart=/opt/bin/setup-network-environment
RemainAfterExit=yes
Type=oneshot
- name: etcd.service
command: start
content: |
[Unit]
Description=etcd
Requires=setup-network-environment.service
After=setup-network-environment.service
[Service]
EnvironmentFile=/etc/network-environment
User=etcd
PermissionsStartOnly=true
ExecStart=/usr/bin/etcd \
--name ${DEFAULT_IPV4} \
--addr ${DEFAULT_IPV4}:4001 \
--bind-addr 0.0.0.0 \
--cluster-active-size 1 \
--data-dir /var/lib/etcd \
--http-read-timeout 86400 \
--peer-addr ${DEFAULT_IPV4}:7001 \
--snapshot true
Restart=always
RestartSec=10s
- name: fleet.socket
command: start
content: |
[Socket]
ListenStream=/var/run/fleet.sock
- name: fleet.service
command: start
content: |
[Unit]
Description=fleet daemon
Wants=etcd.service
After=etcd.service
Wants=fleet.socket
After=fleet.socket
[Service]
Environment="FLEET_ETCD_SERVERS=http://127.0.0.1:4001"
Environment="FLEET_METADATA=role=master"
ExecStart=/usr/bin/fleetd
Restart=always
RestartSec=10s
- name: etcd-waiter.service
command: start
content: |
[Unit]
Description=etcd waiter
Wants=network-online.target
Wants=etcd.service
After=etcd.service
After=network-online.target
Before=flannel.service
Before=setup-network-environment.service
[Service]
ExecStartPre=/usr/bin/chmod +x /opt/bin/waiter.sh
ExecStart=/usr/bin/bash /opt/bin/waiter.sh
RemainAfterExit=true
Type=oneshot
- name: flannel.service
command: start
content: |
[Unit]
Wants=etcd-waiter.service
After=etcd-waiter.service
Requires=etcd.service
After=etcd.service
After=network-online.target
Wants=network-online.target
Description=flannel is an etcd backed overlay network for containers
[Service]
Type=notify
ExecStartPre=-/usr/bin/mkdir -p /opt/bin
ExecStartPre=/usr/bin/wget -N -P /opt/bin http://<PXE_SERVER_IP>/flanneld
ExecStartPre=/usr/bin/chmod +x /opt/bin/flanneld
ExecStartPre=-/usr/bin/etcdctl mk /coreos.com/network/config '{"Network":"10.100.0.0/16", "Backend": {"Type": "vxlan"}}'
ExecStart=/opt/bin/flanneld
- name: kube-apiserver.service
command: start
content: |
[Unit]
Description=Kubernetes API Server
Documentation=https://github.com/kubernetes/kubernetes
Requires=etcd.service
After=etcd.service
[Service]
ExecStartPre=-/usr/bin/mkdir -p /opt/bin
ExecStartPre=/usr/bin/wget -N -P /opt/bin http://<PXE_SERVER_IP>/kube-apiserver
ExecStartPre=/usr/bin/chmod +x /opt/bin/kube-apiserver
ExecStart=/opt/bin/kube-apiserver \
--address=0.0.0.0 \
--port=8080 \
--service-cluster-ip-range=10.100.0.0/16 \
--etcd-servers=http://127.0.0.1:4001 \
--logtostderr=true
Restart=always
RestartSec=10
- name: kube-controller-manager.service
command: start
content: |
[Unit]
Description=Kubernetes Controller Manager
Documentation=https://github.com/kubernetes/kubernetes
Requires=kube-apiserver.service
After=kube-apiserver.service
[Service]
ExecStartPre=/usr/bin/wget -N -P /opt/bin http://<PXE_SERVER_IP>/kube-controller-manager
ExecStartPre=/usr/bin/chmod +x /opt/bin/kube-controller-manager
ExecStart=/opt/bin/kube-controller-manager \
--master=127.0.0.1:8080 \
--logtostderr=true
Restart=always
RestartSec=10
- name: kube-scheduler.service
command: start
content: |
[Unit]
Description=Kubernetes Scheduler
Documentation=https://github.com/kubernetes/kubernetes
Requires=kube-apiserver.service
After=kube-apiserver.service
[Service]
ExecStartPre=/usr/bin/wget -N -P /opt/bin http://<PXE_SERVER_IP>/kube-scheduler
ExecStartPre=/usr/bin/chmod +x /opt/bin/kube-scheduler
ExecStart=/opt/bin/kube-scheduler --master=127.0.0.1:8080
Restart=always
RestartSec=10
- name: kube-register.service
command: start
content: |
[Unit]
Description=Kubernetes Registration Service
Documentation=https://github.com/kelseyhightower/kube-register
Requires=kube-apiserver.service
After=kube-apiserver.service
Requires=fleet.service
After=fleet.service
[Service]
ExecStartPre=/usr/bin/wget -N -P /opt/bin http://<PXE_SERVER_IP>/kube-register
ExecStartPre=/usr/bin/chmod +x /opt/bin/kube-register
ExecStart=/opt/bin/kube-register \
--metadata=role=node \
--fleet-endpoint=unix:///var/run/fleet.sock \
--healthz-port=10248 \
--api-endpoint=http://127.0.0.1:8080
Restart=always
RestartSec=10
update:
group: stable
reboot-strategy: off
ssh_authorized_keys:
- ssh-rsa AAAAB3NzaC1yc2EAAAAD...
```
### node.yml
On the PXE server make and fill in the variables `vi /var/www/html/coreos/pxe-cloud-config-slave.yml`.
```yaml
#cloud-config
---
write_files:
- path: /etc/default/docker
content: |
DOCKER_EXTRA_OPTS='--insecure-registry="rdocker.example.com:5000"'
coreos:
units:
- name: 10-eno1.network
runtime: true
content: |
[Match]
Name=eno1
[Network]
DHCP=yes
- name: 20-nodhcp.network
runtime: true
content: |
[Match]
Name=en*
[Network]
DHCP=none
- name: etcd.service
mask: true
- name: docker.service
drop-ins:
- name: 50-insecure-registry.conf
content: |
[Service]
Environment="HTTP_PROXY=http://rproxy.example.com:3128/" "NO_PROXY=localhost,127.0.0.0/8,rdocker.example.com"
- name: fleet.service
command: start
content: |
[Unit]
Description=fleet daemon
Wants=fleet.socket
After=fleet.socket
[Service]
Environment="FLEET_ETCD_SERVERS=http://<MASTER_SERVER_IP>:4001"
Environment="FLEET_METADATA=role=node"
ExecStart=/usr/bin/fleetd
Restart=always
RestartSec=10s
- name: flannel.service
command: start
content: |
[Unit]
After=network-online.target
Wants=network-online.target
Description=flannel is an etcd backed overlay network for containers
[Service]
Type=notify
ExecStartPre=-/usr/bin/mkdir -p /opt/bin
ExecStartPre=/usr/bin/wget -N -P /opt/bin http://<PXE_SERVER_IP>/flanneld
ExecStartPre=/usr/bin/chmod +x /opt/bin/flanneld
ExecStart=/opt/bin/flanneld -etcd-endpoints http://<MASTER_SERVER_IP>:4001
- name: docker.service
command: start
content: |
[Unit]
After=flannel.service
Wants=flannel.service
Description=Docker Application Container Engine
Documentation=http://docs.docker.io
[Service]
EnvironmentFile=-/etc/default/docker
EnvironmentFile=/run/flannel/subnet.env
ExecStartPre=/bin/mount --make-rprivate /
ExecStart=/usr/bin/docker -d --bip=${FLANNEL_SUBNET} --mtu=${FLANNEL_MTU} -s=overlay -H fd:// ${DOCKER_EXTRA_OPTS}
[Install]
WantedBy=multi-user.target
- name: setup-network-environment.service
command: start
content: |
[Unit]
Description=Setup Network Environment
Documentation=https://github.com/kelseyhightower/setup-network-environment
Requires=network-online.target
After=network-online.target
[Service]
ExecStartPre=-/usr/bin/mkdir -p /opt/bin
ExecStartPre=/usr/bin/wget -N -P /opt/bin http://<PXE_SERVER_IP>/setup-network-environment
ExecStartPre=/usr/bin/chmod +x /opt/bin/setup-network-environment
ExecStart=/opt/bin/setup-network-environment
RemainAfterExit=yes
Type=oneshot
- name: kube-proxy.service
command: start
content: |
[Unit]
Description=Kubernetes Proxy
Documentation=https://github.com/kubernetes/kubernetes
Requires=setup-network-environment.service
After=setup-network-environment.service
[Service]
ExecStartPre=/usr/bin/wget -N -P /opt/bin http://<PXE_SERVER_IP>/kube-proxy
ExecStartPre=/usr/bin/chmod +x /opt/bin/kube-proxy
ExecStart=/opt/bin/kube-proxy \
--etcd-servers=http://<MASTER_SERVER_IP>:4001 \
--logtostderr=true
Restart=always
RestartSec=10
- name: kube-kubelet.service
command: start
content: |
[Unit]
Description=Kubernetes Kubelet
Documentation=https://github.com/kubernetes/kubernetes
Requires=setup-network-environment.service
After=setup-network-environment.service
[Service]
EnvironmentFile=/etc/network-environment
ExecStartPre=/usr/bin/wget -N -P /opt/bin http://<PXE_SERVER_IP>/kubelet
ExecStartPre=/usr/bin/chmod +x /opt/bin/kubelet
ExecStart=/opt/bin/kubelet \
--address=0.0.0.0 \
--port=10250 \
--hostname-override=${DEFAULT_IPV4} \
--api-servers=<MASTER_SERVER_IP>:8080 \
--healthz-bind-address=0.0.0.0 \
--healthz-port=10248 \
--logtostderr=true
Restart=always
RestartSec=10
update:
group: stable
reboot-strategy: off
ssh_authorized_keys:
- ssh-rsa AAAAB3NzaC1yc2EAAAAD...
```
## New pxelinux.cfg file
Create a pxelinux target file for a _slave_ node: `vi /tftpboot/pxelinux.cfg/coreos-node-slave`
```conf
default coreos
prompt 1
timeout 15
display boot.msg
label coreos
menu default
kernel images/coreos/coreos_production_pxe.vmlinuz
append initrd=images/coreos/coreos_production_pxe_image.cpio.gz cloud-config-url=http://<pxe-host-ip>/coreos/pxe-cloud-config-slave.yml console=tty0 console=ttyS0 coreos.autologin=tty1 coreos.autologin=ttyS0
```
And one for the _master_ node: `vi /tftpboot/pxelinux.cfg/coreos-node-master`
```conf
default coreos
prompt 1
timeout 15
display boot.msg
label coreos
menu default
kernel images/coreos/coreos_production_pxe.vmlinuz
append initrd=images/coreos/coreos_production_pxe_image.cpio.gz cloud-config-url=http://<pxe-host-ip>/coreos/pxe-cloud-config-master.yml console=tty0 console=ttyS0 coreos.autologin=tty1 coreos.autologin=ttyS0
```
## Specify the pxelinux targets
Now that we have our new targets setup for master and slave we want to configure the specific hosts to those targets. We will do this by using the pxelinux mechanism of setting a specific MAC addresses to a specific pxelinux.cfg file.
Refer to the MAC address table in the beginning of this guide. Documentation for more details can be found [here](http://www.syslinux.org/wiki/index.php/PXELINUX).
```shell
cd /tftpboot/pxelinux.cfg
ln -s coreos-node-master 01-d0-00-67-13-0d-00
ln -s coreos-node-slave 01-d0-00-67-13-0d-01
ln -s coreos-node-slave 01-d0-00-67-13-0d-02
```
Reboot these servers to get the images PXEd and ready for running containers!
## Creating test pod
Now that the CoreOS with Kubernetes installed is up and running lets spin up some Kubernetes pods to demonstrate the system.
See [a simple nginx example](/docs/user-guide/simple-nginx/) to try out your new cluster.
For more complete applications, please look in the [examples directory](https://github.com/kubernetes/examples/tree/{{page.githubbranch}}/).
## Helping commands for debugging
List all keys in etcd:
```shell
etcdctl ls --recursive
```
List fleet machines
```shell
fleetctl list-machines
```
Check system status of services on master:
```shell
systemctl status kube-apiserver
systemctl status kube-controller-manager
systemctl status kube-scheduler
systemctl status kube-register
```
Check system status of services on a node:
```shell
systemctl status kube-kubelet
systemctl status docker.service
```
List Kubernetes
```shell
kubectl get pods
kubectl get nodes
```
Kill all pods:
```shell
for i in `kubectl get pods | awk '{print $1}'`; do kubectl delete pod $i; done
```
## Support Level
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
Bare-metal (Offline) | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/coreos/bare_metal_offline/) | | Community ([@jeffbean](https://github.com/jeffbean))
For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions/) chart.
+6
View File
@@ -10,7 +10,13 @@ Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [in
* a highly available cluster
* composable attributes
<<<<<<< HEAD
* support for most popular Linux distributions (CoreOS, Debian Jessie, Ubuntu 16.04, CentOS/RHEL 7, Fedora/CentOS Atomic)
||||||| merged common ancestors
* support for most popular Linux distributions
=======
* support for most popular Linux distributions (CoreOS, Debian Jessie, Ubuntu 16.04, CentOS/RHEL 7)
>>>>>>> merge master to 1.10, with fixes (#7682)
* continuous integration tests
To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](../kops).
@@ -105,16 +105,34 @@ juju bootstrap aws/us-east-2
or, another example, this time on Azure:
```
<<<<<<< HEAD
juju bootstrap azure/westus2
```
If you receive this error, it is likely that the default Azure VM size (Standard D1 v2 [1 vcpu, 3.5 GB memory]) is not available in the Azure location:
||||||| merged common ancestors
juju bootstrap azure/centralus
=======
juju bootstrap azure/westus2
>>>>>>> merge master to 1.10, with fixes (#7682)
```
ERROR failed to bootstrap model: instance provisioning failed (Failed)
```
<<<<<<< HEAD
You will need a controller node for each cloud or region you are deploying to. See the [controller documentation](https://jujucharms.com/docs/2.3/controllers) for more information.
||||||| merged common ancestors
You will need a controller node for each cloud or region you are deploying to. See the [controller documentation](https://jujucharms.com/docs/2.2/controllers) for more information.
=======
If you receive this error, it is likely that the default Azure VM size (Standard D1 v2 [1 vcpu, 3.5 GB memory]) is not available in the Azure location:
```
ERROR failed to bootstrap model: instance provisioning failed (Failed)
```
You will need a controller node for each cloud or region you are deploying to. See the [controller documentation](https://jujucharms.com/docs/2.3/controllers) for more information.
You will need a controller node for each cloud or region you are deploying to. See the [controller documentation](https://jujucharms.com/docs/2.2/controllers) for more information.
>>>>>>> merge master to 1.10, with fixes (#7682)
Note that each controller can host multiple Kubernetes clusters in a given cloud or region.
@@ -1,3 +1,4 @@
<<<<<<< HEAD
---
title: Rancher Integration with Ubuntu Kubernetes
---
@@ -359,3 +360,366 @@ You can remove Rancher from your cluster using kubectl. Deleting constructs in K
{% endcapture %}
{% include templates/task.md %}
||||||| merged common ancestors
=======
---
title: Rancher Integration with Ubuntu Kubernetes
---
{% capture overview %}
This repository explains how to deploy Rancher 2.0alpha on Canonical Kubernetes.
These steps are currently in alpha/testing phase and will most likely change.
The original documentation for this integration can be found at [https://github.com/CalvinHartwell/canonical-kubernetes-rancher/](https://github.com/CalvinHartwell/canonical-kubernetes-rancher/).
{% endcapture %}
{% capture prerequisites %}
To use this guide, you must have a working kubernetes cluster that was deployed using Canonical's juju.
The full instructions for deploying Kubernetes with juju can be found at [https://kubernetes.io/docs/getting-started-guides/ubuntu/installation/](https://kubernetes.io/docs/getting-started-guides/ubuntu/installation/).
{% endcapture %}
{% capture steps %}
## Deploying Rancher
To deploy Rancher, we just need to run the Rancher container workload on-top of Kubernetes. Rancher provides their containers through dockerhub ([https://hub.docker.com/r/rancher/server/tags/](https://hub.docker.com/r/rancher/server/tags/)) and can be downloaded freely from the internet.
If you're running your own registry or have an offline deployment, the container should be downloaded and pushed to a private registry before proceeding.
### Deploying Rancher with a nodeport
First create a yaml file which defines how to deploy Rancher on kubernetes. Save the file as cdk-rancher-nodeport.yaml:
```
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: cluster-admin
subjects:
- kind: ServiceAccount
name: default
namespace: default
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-admin
rules:
- apiGroups:
- '*'
resources:
- '*'
verbs:
- '*'
- nonResourceURLs:
- '*'
verbs:
- '*'
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
creationTimestamp: null
labels:
app: rancher
name: rancher
spec:
replicas: 1
selector:
matchLabels:
app: rancher
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: rancher
ima: pod
spec:
containers:
- image: rancher/server:preview
imagePullPolicy: Always
name: rancher
ports:
- containerPort: 80
- containerPort: 443
livenessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
timeoutSeconds: 30
resources: {}
restartPolicy: Always
serviceAccountName: ""
status: {}
---
apiVersion: v1
kind: Service
metadata:
name: rancher
labels:
app: rancher
spec:
ports:
- port: 443
protocol: TCP
targetPort: 443
selector:
app: rancher
---
apiVersion: v1
kind: Service
metadata:
name: rancher-nodeport
spec:
type: NodePort
selector:
app: rancher
ports:
- name: rancher-api
protocol: TCP
nodePort: 30443
port: 443
targetPort: 443
```
Once kubectl is running and working, run the following command to deploy Rancher:
```
kubectl apply -f cdk-rancher-nodeport.yaml
```
Now we need to open this nodeport so we can access it. For that, we can use juju. We need to run the open-port command for each of the worker nodes in our cluster. Inside the cdk-rancher-nodeport.yaml file, the nodeport has been set to 30443. Below shows how to open the port on each of the worker nodes:
```
# repeat this for each kubernetes worker in the cluster.
juju run --unit kubernetes-worker/0 "open-port 30443"
juju run --unit kubernetes-worker/1 "open-port 30443"
juju run --unit kubernetes-worker/2 "open-port 30443"
```
Rancher can now be accessed on this port through a worker IP or DNS entries if you have created them. It is generally recommended that you create a DNS entry for each of the worker nodes in your cluster. For example, if you have three worker nodes and you own the domain example.com, you could create three A records, one for each worker in the cluster.
As creating DNS entries is outside of the scope of this document, we will use the freely available xip.io service which can return A records for an IP address which is part of the domain name. For example, if you have the domain rancher.35.178.130.245.xip.io, the xip.io service will automatically return the IP address 35.178.130.245 as an A record which is useful for testing purposes. For your deployment, the IP address 35.178.130.245 should be replaced with one of your worker IP address, which can be found using Juju or AWS:
```
calvinh@ubuntu-ws:~/Source/cdk-rancher$ juju status
# ... output omitted.
Unit Workload Agent Machine Public address Ports Message
easyrsa/0* active idle 0 35.178.118.232 Certificate Authority connected.
etcd/0* active idle 1 35.178.49.31 2379/tcp Healthy with 3 known peers
etcd/1 active idle 2 35.177.99.171 2379/tcp Healthy with 3 known peers
etcd/2 active idle 3 35.178.125.161 2379/tcp Healthy with 3 known peers
kubeapi-load-balancer/0* active idle 4 35.178.37.87 443/tcp Loadbalancer ready.
kubernetes-master/0* active idle 5 35.177.239.237 6443/tcp Kubernetes master running.
flannel/0* active idle 35.177.239.237 Flannel subnet 10.1.27.1/24
kubernetes-worker/0* active idle 6 35.178.130.245 80/tcp,443/tcp,30443/tcp Kubernetes worker running.
flannel/2 active idle 35.178.130.245 Flannel subnet 10.1.82.1/24
kubernetes-worker/1 active idle 7 35.178.121.29 80/tcp,443/tcp,30443/tcp Kubernetes worker running.
flannel/3 active idle 35.178.121.29 Flannel subnet 10.1.66.1/24
kubernetes-worker/2 active idle 8 35.177.144.76 80/tcp,443/tcp,30443/tcp Kubernetes worker running.
flannel/1 active idle 35.177.144.76
# Note the IP addresses for the kubernetes-workers in the example above. You should pick one of the public addresses.
```
Try opening up Rancher in your browser using the nodeport and the domain name or ip address:
```
# replace the IP address with one of your Kubernetes worker, find this from juju status command.
wget https://35.178.130.245.xip.io:30443 --no-check-certificate
# this should also work
wget https://35.178.130.245:30443 --no-check-certificate
```
If you need to make any changes to the kubernetes configuration file, edit the yaml file and then just use apply again:
```
kubectl apply -f cdk-rancher-nodeport.yaml
```
### Deploying Rancher with an ingress rule
It is also possible to deploy Rancher using an ingress rule. This has the added benefit of not requiring additional ports to be opened up on the Kubernetes cluster. First create a yaml file to describe the deployment called cdk-rancher-ingress.yaml which should contain the following:
```
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: cluster-admin
subjects:
- kind: ServiceAccount
name: default
namespace: default
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-admin
rules:
- apiGroups:
- '*'
resources:
- '*'
verbs:
- '*'
- nonResourceURLs:
- '*'
verbs:
- '*'
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
creationTimestamp: null
labels:
app: rancher
name: rancher
spec:
replicas: 1
selector:
matchLabels:
app: rancher
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: rancher
spec:
containers:
- image: rancher/server:preview
imagePullPolicy: Always
name: rancher
ports:
- containerPort: 443
livenessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
timeoutSeconds: 30
resources: {}
restartPolicy: Always
serviceAccountName: ""
status: {}
---
apiVersion: v1
kind: Service
metadata:
name: rancher
labels:
app: rancher
spec:
ports:
- port: 443
targetPort: 443
protocol: TCP
selector:
app: rancher
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: rancher
annotations:
kubernetes.io/tls-acme: "true"
ingress.kubernetes.io/secure-backends: "true"
spec:
tls:
- hosts:
- rancher.34.244.118.135.xip.io
rules:
- host: rancher.34.244.118.135.xip.io
http:
paths:
- path: /
backend:
serviceName: rancher
servicePort: 443
```
It is generally recommended that you create a DNS entry for each of the worker nodes in your cluster. For example, if you have three worker nodes and you own the domain example.com, you could create three A records, one for each worker in the cluster.
As creating DNS entries is outside of the scope of this tutorial, we will use the freely available xip.io service which can return A records for an IP address which is part of the domain name. For example, if you have the domain rancher.35.178.130.245.xip.io, the xip.io service will automatically return the IP address 35.178.130.245 as an A record which is useful for testing purposes.
For your deployment, the IP address 35.178.130.245 should be replaced with one of your worker IP address, which can be found using Juju or AWS:
```
calvinh@ubuntu-ws:~/Source/cdk-rancher$ juju status
# ... output omitted.
Unit Workload Agent Machine Public address Ports Message
easyrsa/0* active idle 0 35.178.118.232 Certificate Authority connected.
etcd/0* active idle 1 35.178.49.31 2379/tcp Healthy with 3 known peers
etcd/1 active idle 2 35.177.99.171 2379/tcp Healthy with 3 known peers
etcd/2 active idle 3 35.178.125.161 2379/tcp Healthy with 3 known peers
kubeapi-load-balancer/0* active idle 4 35.178.37.87 443/tcp Loadbalancer ready.
kubernetes-master/0* active idle 5 35.177.239.237 6443/tcp Kubernetes master running.
flannel/0* active idle 35.177.239.237 Flannel subnet 10.1.27.1/24
kubernetes-worker/0* active idle 6 35.178.130.245 80/tcp,443/tcp,30443/tcp Kubernetes worker running.
flannel/2 active idle 35.178.130.245 Flannel subnet 10.1.82.1/24
kubernetes-worker/1 active idle 7 35.178.121.29 80/tcp,443/tcp,30443/tcp Kubernetes worker running.
flannel/3 active idle 35.178.121.29 Flannel subnet 10.1.66.1/24
kubernetes-worker/2 active idle 8 35.177.144.76 80/tcp,443/tcp,30443/tcp Kubernetes worker running.
flannel/1 active idle 35.177.144.76
# Note the IP addresses for the kubernetes-workers in the example above. You should pick one of the public addresses.
```
Looking at the output from the juju status above, the Public Address (35.178.130.245) can be used to create a xip.io DNS entry (rancher.35.178.130.245.xip.io) which should be placed into the cdk-rancher-ingress.yaml file. You could also create your own DNS entry as long as it resolves to each of the worker nodes or one of them it will work fine:
```
# The xip.io domain should appear in two places in the file, change both entries.
cat cdk-rancher-ingress.yaml | grep xip.io
- host: rancher.35.178.130.245.xip.io
```
Once you've edited the ingress rule to reflect your DNS entries, run the kubectl apply -f cdk-rancher-ingress.yaml to deploy Kubernetes:
```
kubectl apply -f cdk-rancher-ingress.yaml
```
Rancher can now be accessed on the regular 443 through a worker IP or DNS entries if you have created them. Try opening it up in your browser:
```
# replace the IP address with one of your Kubernetes worker, find this from juju status command.
wget https://35.178.130.245.xip.io:443 --no-check-certificate
```
If you need to make any changes to the kubernetes configuration file, edit the yaml file and then just use apply again:
```
kubectl apply -f cdk-rancher-ingress.yaml
```
### Removing Rancher
You can remove Rancher from your cluster using kubectl. Deleting constructs in Kubernetes is as simple as creating them:
```
# If you used the nodeport example change the yaml filename if you used the ingress example.
kubectl delete -f cdk-rancher-nodeport.yaml
```
{% endcapture %}
{% include templates/task.md %}
>>>>>>> merge master to 1.10, with fixes (#7682)
@@ -46,6 +46,7 @@ After the snapshot, upgrade the etcd service with:
juju upgrade-charm etcd
<<<<<<< HEAD
This will handle upgrades between minor versions of etcd. Instructions on how to upgrade from 2.x to 3.x can be found [here](https://github.com/juju-solutions/bundle-canonical-kubernetes/wiki/Etcd-2.3-to-3.x-upgrade) in the juju-solutions wiki.
### Upgrade kubeapi-load-balancer
@@ -55,6 +56,12 @@ The Kubernetes Charms are generally all updated and released at the same time. A
To upgrade the charm run:
juju upgrade-charm kubeapi-load-balancer
||||||| merged common ancestors
This will handle upgrades between minor versions of etcd. Major upgrades from
etcd 2.x to 3.x are currently unsupported. Instead, data will be run in etcdv2 stores over the etcdv3 api.
=======
This will handle upgrades between minor versions of etcd. Instructions on how to upgrade from 2.x to 3.x can be found [here](https://github.com/juju-solutions/bundle-canonical-kubernetes/wiki/Etcd-2.3-to-3.x-upgrade) in the juju-solutions wiki.
>>>>>>> merge master to 1.10, with fixes (#7682)
### Upgrade Kubernetes
@@ -16,8 +16,16 @@ The Kubernetes control plane (API Server, Scheduler, Controller Manager, etc) co
**Note:** Windows Server Containers on Kubernetes is a Beta feature in Kubernetes v1.9
{: .note}
<<<<<<< HEAD
## Get Windows Binaries
We recommend using the release binaries that can be found at [https://github.com/kubernetes/kubernetes/releases/latest](https://github.com/kubernetes/kubernetes/releases/latest). Under the CHANGELOG you can find the Node Binaries link for Windows-amd64, which will include kubeadm, kubectl, kubelet and kube-proxy.
||||||| merged common ancestors
## Build
We recommend using the release binaries that can be found at [https://github.com/kubernetes/kubernetes/releases](https://github.com/kubernetes/kubernetes/releases). Look for the Node Binaries section by visiting the binary downloads link.
=======
## Get Windows Binaries
We recommend using the release binaries that can be found at [https://github.com/kubernetes/kubernetes/releases/latest](https://github.com/kubernetes/kubernetes/releases/latest). Under the CHANGELOG you can find the Node Binaries link for Windows-amd64, which will include kubeadm, kubectl, kubelet and kube-proxy.
>>>>>>> merge master to 1.10, with fixes (#7682)
If you wish to build the code yourself, please refer to detailed build instructions [here](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/compiling-kubernetes-binaries).
@@ -92,8 +100,16 @@ To run Windows Server Containers on Kubernetes, you'll need to set up both your
More detailed instructions can be found [here](https://github.com/MicrosoftDocs/Virtualization-Documentation/blob/live/virtualization/windowscontainers/kubernetes/getting-started-kubernetes-windows.md).
<<<<<<< HEAD
**Windows CNI Config Example**
Today, Windows CNI plugin is based on wincni.exe code with the following example, configuration file. This is based on the ToR example diagram shown above, specifying the configuration to apply to Windows node-1. Of special interest is Windows node-1 pod CIDR (10.10.187.64/26) and the associated gateway of cbr0 (10.10.187.66). The exception list is specifying the Service CIDR (11.0.0.0/8), Cluster CIDR (10.10.0.0/16), and Management (or Host) CIDR (10.127.132.128/25).
||||||| merged common ancestors
**Windows CNI Config Example**
Today, Windows CNI plugin is based on wincni.exe code with the following example, configuration file.
=======
**Windows CNI Config Example**
Today, Windows CNI plugin is based on wincni.exe code with the following example, configuration file. This is based on the ToR example diagram shown above, specifying the configuration to apply to Windows node-1. Of special interest is Windows node-1 pod CIDR (10.10.187.64/26) and the associated gateway of cbr0 (10.10.187.66). The exception list is specifying the Service CIDR (11.0.0.0/8), Cluster CIDR (10.10.0.0/16), and Management (or Host) CIDR (10.127.132.128/25).
>>>>>>> merge master to 1.10, with fixes (#7682)
Note: this file assumes that a user previous created 'l2bridge' host networks on each Windows node using `<Verb>-HNSNetwork` cmdlets as shown in the `start-kubelet.ps1` and `start-kubeproxy.ps1` scripts linked above
@@ -227,6 +243,7 @@ To start your cluster, you'll need to start both the Linux-based Kubernetes cont
## Starting the Linux-based Control Plane
Use your preferred method to start Kubernetes cluster on Linux. Please note that Cluster CIDR might need to be updated.
<<<<<<< HEAD
## Support for kubeadm join
If your cluster has been created by [kubeadm](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/),
@@ -244,6 +261,28 @@ The examples listed below assume running Windows nodes on Windows Server 1709. I
### Scheduling Pods on Windows
Because your cluster has both Linux and Windows nodes, you must explicitly set the `nodeSelector` constraint to be able to schedule pods to Windows nodes. You must set nodeSelector with the label `beta.kubernetes.io/os` to the value `windows`; see the following example:
||||||| merged common ancestors
## Scheduling Pods on Windows
Because your cluster has both Linux and Windows nodes, you must explicitly set the nodeSelector constraint to be able to schedule pods to Windows nodes. You must set nodeSelector with the label beta.kubernetes.io/os to the value windows; see the following example:
=======
## Support for kubeadm join
If your cluster has been created by [kubeadm](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/),
and your networking is setup correctly using one of the methods listed above (networking is setup outside of kubeadm), you can use kubeadm to add a Windows node to your cluster. At a high level, you first have to initialize the master with kubeadm (Linux), then set up the CNI based networking (outside of kubeadm), and finally start joining Windows or Linux worker nodes to the cluster. For additional documentation and reference material, visit the kubeadm link above.
The kubeadm binary can be found at [Kubernetes Releases](https://github.com/kubernetes/kubernetes/releases), inside the node binaries archive. Adding a Windows node is not any different than adding a Linux node:
`kubeadm.exe join --token <token> <master-ip>:<master-port> --discovery-token-ca-cert-hash sha256:<hash>`
See [joining-your-nodes](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/#44-joining-your-nodes) for more details.
## Supported Features
The examples listed below assume running Windows nodes on Windows Server 1709. If you are running Windows Server 2016, the examples will need the image updated to specify `image: microsoft/windowsservercore:ltsc2016`. This is due to the requirement for container images to match the host operating system version when using process isolation. Not specifying a tag will implicitly use the `:latest` tag which can lead to surprising behaviors. Please consult with [https://hub.docker.com/r/microsoft/windowsservercore/](https://hub.docker.com/r/microsoft/windowsservercore/) for additional information on Windows Server Core image tagging.
### Scheduling Pods on Windows
Because your cluster has both Linux and Windows nodes, you must explicitly set the `nodeSelector` constraint to be able to schedule pods to Windows nodes. You must set nodeSelector with the label `beta.kubernetes.io/os` to the value `windows`; see the following example:
>>>>>>> merge master to 1.10, with fixes (#7682)
```yaml
{
@@ -432,6 +471,7 @@ spec:
### Metrics
<<<<<<< HEAD
Windows Stats use a hybrid model: pod and container level stats come from CRI (via dockershim), while node level stats come from the "winstats" package that exports cadvisor like data structures using windows specific perf counters from the node.
### Container Resources
@@ -485,15 +525,28 @@ spec:
ports:
- containerPort: 80
```
||||||| merged common ancestors
Windows Stats use a hybrid model: pod and container level stats come from CRI (via dockershim), while node level stats come from the "winstats" package that exports cadvisor like datastructures using windows specific perf counters from the node.
=======
Windows Stats use a hybrid model: pod and container level stats come from CRI (via dockershim), while node level stats come from the "winstats" package that exports cadvisor like data structures using windows specific perf counters from the node.
>>>>>>> merge master to 1.10, with fixes (#7682)
## Known Limitations for Windows Server Containers with v1.9
Some of these limitations will be addressed by the community in future releases of Kubernetes
- Shared network namespace (compartment) with multiple Windows Server containers (shared kernel) per pod is only supported on Windows Server 1709 or later
<<<<<<< HEAD
- Using Secrets and ConfigMaps as volume mounts is not supported
- Mount propagation is not supported on Windows
||||||| merged common ancestors
- Using Secrets and ConfigMaps as volume mounts is not supported
=======
- Using Secrets and ConfigMaps as volume mounts is not supported
- Mount propagation is not supported on Windows
>>>>>>> merge master to 1.10, with fixes (#7682)
- The StatefulSet functionality for stateful applications is not supported
- Horizontal Pod Autoscaling for Windows Server Container pods has not been verified to work end-to-end
<<<<<<< HEAD
<<<<<<< HEAD
- Hyper-V isolated containers are not supported.
- Windows container OS must match the Host OS. If it does not, the pod will get stuck in a crash loop.
- Under the networking models of L3 or Host GW, Kubernetes Services are inaccessible to Windows nodes due to a Windows issue. This is not an issue if using OVN/OVS for networking.
@@ -504,11 +557,21 @@ Some of these limitations will be addressed by the community in future releases
- Hyper-V Containers are not supported
=======
- Hyper-V Containers are not supported
||||||| merged common ancestors
- Hyper-V Containers are not supported
=======
- Hyper-V isolated containers are not supported.
- Windows container OS must match the Host OS. If it does not, the pod will get stuck in a crash loop.
- Under the networking models of L3 or Host GW, Kubernetes Services are inaccessible to Windows nodes due to a Windows issue. This is not an issue if using OVN/OVS for networking.
- Windows kubelet.exe may fail to start when running on Windows Server under VMware Fusion [issue 57110](https://github.com/kubernetes/kubernetes/pull/57124)
- Flannel and Weavenet are not yet supported
>>>>>>> merge master to 1.10, with fixes (#7682)
- Some .Net Core applications expect environment variables with a colon (`:`) in the name. Kubernetes currently does not allow this. Replace colon (`:`) with double underscore (`__`) as documented [here](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?tabs=basicconfiguration#configuration-by-environment).
>>>>>>> Added the inability to use colon ':' character as environment variable names and described workaround (#7657)
## Next steps and resources
<<<<<<< HEAD
<<<<<<< HEAD
- Support for Windows is in Beta as of v1.9 and your feedback is welcome. For information on getting involved, please head to [SIG-Windows](https://github.com/kubernetes/community/blob/master/sig-windows/README.md)
- Troubleshooting and Common Problems: [Link](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/common-problems)
@@ -517,3 +580,9 @@ Some of these limitations will be addressed by the community in future releases
=======
> As of this writing, the Kube-proxy binary requires a pending Kubernetes [pull request](https://github.com/kubernetes/kubernetes/pull/56529) to work properly. You may need to [build](#build) the binaries manually to work around this.
>>>>>>> Added the inability to use colon ':' character as environment variable names and described workaround (#7657)
||||||| merged common ancestors
> As of this writing, the Kube-proxy binary requires a pending Kubernetes [pull request](https://github.com/kubernetes/kubernetes/pull/56529) to work properly. You may need to [build](#build) the binaries manually to work around this.
=======
- Support for Windows is in Beta as of v1.9 and your feedback is welcome. For information on getting involved, please head to [SIG-Windows](https://github.com/kubernetes/community/blob/master/sig-windows/README.md)
- Troubleshooting and Common Problems: [Link](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/common-problems)
>>>>>>> merge master to 1.10, with fixes (#7682)
+19
View File
@@ -60,6 +60,7 @@ changed by setting the <code>for_k8s_version</code> variable.
{{ "{% include feature-state-deprecated.md " }}%}
````
<<<<<<< HEAD
## Glossary
You can reference glossary terms with an inclusion that will automatically update and replace content with the relevant links from [our glossary](/docs/reference/glossary/). When the term is moused-over by someone
@@ -75,6 +76,24 @@ For example, the following include within the markdown will render to {% glossar
{{ "{% glossary_tooltip text=" }}"cluster" term_id="cluster" %}
````
||||||| merged common ancestors
=======
## Glossary
You can reference glossary terms with an inclusion that will automatically update and replace content with the relevant links from [our glossary](docs/reference/glossary/). When the term is moused-over by someone
using the online documentation, the glossary entry will display a tooltip.
The raw data for glossary terms is stored at [https://github.com/kubernetes/website/tree/master/_data/glossary](https://github.com/kubernetes/website/tree/master/_data/glossary), with a YAML file for each glossary term.
### Glossary Demo
For example, the following include within the markdown will render to {% glossary_tooltip text="cluster" term_id="cluster" %} with a tooltip:
````liquid
{{ "{% glossary_tooltip text=" }}"cluster" term_id="cluster" %}
````
>>>>>>> merge master to 1.10, with fixes (#7682)
## Tabs
In a markdown page (`.md` file) on this site, you can add a tab set to display multiple flavors of a given solution.
+113
View File
@@ -1,3 +1,4 @@
<<<<<<< HEAD
---
title: Participating in SIG-DOCS
---
@@ -107,3 +108,115 @@ For more information about contributing to the Kubernetes documentation, see:
{% endcapture %}
{% include templates/concept.md %}
||||||| merged common ancestors
=======
---
title: Participating in SIG-DOCS
---
{% capture overview %}
SIG-DOCS is one of the [special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md) within the Kubernetes project, focused on writing, updating, and maintaining the documentation for Kubernetes as a whole.
{% endcapture %}
{% capture body %}
SIG Docs welcomes content and reviews from all contributors. Anyone can open a pull request (PR), and anyone is welcome to comment on content or pull requests in progress.
Within the Kubernetes project, you may also become a member, reviewer, or approver.
These roles confer additional privileges and responsibilities when it comes to approving and committing changes.
See [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md) for more information on how membership works within the Kubernetes community.
## Roles and Responsibilities
The automation reads `/hold`, `/lgtm`, and `/approve` comments and sets labels on the pull request.
When a pull request has the `lgtm` and `approve` labels without any `hold` labels, the pull request merges automatically.
Kubernetes org members, and reviewers and approvers for SIG Docs can add comments to control the merge automation.
- Members
Any member of the [Kubernetes organization](https://github.com/kubernetes) can review a pull request, and SIG Docs team members frequently request reviews from members of other SIGs for technical accuracy.
SIG Docs also welcomes reviews and feedback regardless of Kubernetes org membership.
You can indicate your approval by adding a comment of `/lgtm` to a pull request.
- Reviewers
Reviewers are individuals who review documentation pull requests.
Automation assigns reviewers to pull requests, and contributors can request a review with a comment on the pull request: `/assign [@_github_handle]`.
To indicate that a pull request requires no further changes, a reviewer should add comment to the pull request `/lgtm`.
A reviewer indicates technical accuracy with a `lgtm` comment.
Reviewers can add a `/hold` comment to prevent the pull request from being merged.
Another reviewer or approver can remove a hold with the comment: `/hold cancel`.
When a reviewer is assigned a pull request to review it is not a sole responsibility, and any other reviewer may also offer their opinions on the pull request.
If a reviewer is requested, it is generally expected that the PR will be left to that reviewer to do their editorial pass on the content.
If a PR author or SIG Docs maintainer requests a review, refrain from merging or closing the PR until the requested reviewer completes their review.
- Approvers
Approvers have the ability to merge a PR.
Approvers can indicate their approval with a comment to the pull request: `/approve`.
An approver is indicating editorial approval with the an `/approve` comment.
Approvers can add a `/hold` comment to prevent the pull request from being merged.
Another reviewer or approver can remove a hold with the comment: `/hold cancel`.
Approvers may skip further reviews for small pull requests if the proposed changes appear trivial and/or well-understood.
An approver can indicate `/lgtm` or `/approve` in a PR comment to have a pull request merged, and all pull requests require at least one approver to provide their vote in order for the PR to be merged.
**Note:** There is a special case when an approver uses the comment: `/lgtm`. In these cases, the automation will add both `lgtm` and `approve` tags, skipping any further review.
+{: .note }
For PRs that require no review (typos or otherwise trivial changes), approvers can enter an `lgtm` comment, indicating no need for further review and flagging the PR with approval to merge.
### Teams and groups within SIG Docs
You can get an overview of [SIG Docs from the community github repo](https://github.com/kubernetes/community/tree/master/sig-docs).
The SIG Docs group defines two teams on Github:
- [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
- [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews)
These groups maintain the [Kubernetes website repository](https://github.com/kubernetes/website), which houses the content hosted at this site.
Both can be referenced with their `@name` in github comments to communicate with everyone in that group.
These teams overlap, but do not exactly match, the groups used by the automation tooling.
For assignment of issues, pull requests, and to support PR approvals, the automation uses information from the OWNERS file.
To volunteer as a reviewer or approver, make a pull request and add your Github handle to the relevant section in the [OWNERS file](https://github.com/kubernetes/community/blob/master/contributors/devel/owners.md).
**Note:** Reviewers and approvers must meet requirements for participation.
For more information, see the [Kubernetes community](https://github.com/kubernetes/community/blob/master/community-membership.md#membership) repository.
{: .note }
Documentation for the [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/devel/owners.md) explains how to maintain OWNERS for each repository that enables it.
The [Kubernetes website repository](https://github.com/kubernetes/website) has two automation (prow) [plugins enabled](https://github.com/kubernetes/test-infra/blob/master/prow/plugins.yaml#L210):
- blunderbuss
- approve
These two plugins use the [OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) and [OWNERS_ALIAS](https://github.com/kubernetes/website/blob/master/OWNERS_ALIAS) files in our repo for configuration.
{% endcapture %}
{% capture whatsnext %}
For more information about contributing to the Kubernetes documentation, see:
* Review the SIG Docs [Style Guide](/docs/home/contribute/style-guide/).
* Learn how to [stage your documentation changes](/docs/home/contribute/stage-documentation-changes/).
* Learn about [writing a new topic](/docs/home/contribute/write-new-topic/).
* Learn about [using page templates](/docs/home/contribute/page-templates/).
* Learn about [staging your changes](/docs/home/contribute/stage-documentation-changes/).
* Learn about [creating a pull request](/docs/home/contribute/create-pull-request/).
* How to generate documentation:
* Learn how to [generate Reference Documentation for Kubernetes Federation API](/docs/home/contribute/generated-reference/federation-api/)
* Learn how to [generate Reference Documentation for kubectl Commands](/docs/home/contribute/generated-reference/kubectl/)
* Learn how to [generate Reference Documentation for the Kubernetes API](/docs/home/contribute/generated-reference/kubernetes-api/)
* Learn how to [generate Reference Pages for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/)
{% endcapture %}
{% include templates/concept.md %}
>>>>>>> merge master to 1.10, with fixes (#7682)
+50
View File
@@ -142,6 +142,23 @@ The output is similar to this:
NAME READY STATUS RESTARTS AGE IP NODE
nginx 1/1 Running 0 13s 10.200.0.4 worker0
<<<<<<< HEAD
### Versioning Kubernetes examples
Code examples and configuration examples that include version information should be consistent with the accompanying text. Identify the Kubernetes version in the **Before you begin** section.
To specify the Kubernetes version for a task or tutorial page:
- Include `min-kubernetes-server-version` in the front matter of the page.
- In the **Before you begin** section, use `{{ "{% include tasks-tutorial-prereqs.md "}} %}`.
If the example YAML is in a standalone file, find and review the topics that include it as a reference.
Verify that any topics using the standalone YAML have the appropriate version information defined.
If a stand-alone YAML file is not referenced from any topics, consider deleting it instead of updating it.
For example, if you are writing a tutorial that is relevant to Kubernetes version 1.8, the front-matter of your markdown file should look something like:
||||||| merged common ancestors
=======
### Versioning Kubernetes examples
Code examples and configuration examples that include version information should be consistent with the accompanying text. Identify the Kubernetes version in the **Before you begin** section.
@@ -167,6 +184,24 @@ min-kubernetes-server-version: v1.8
In code and configuration examples, do not include comments about alternative versions.
Be careful to not include incorrect statements in your examples as comments, such as:
```yaml
apiVersion: v1 # earlier versions use...
kind: Pod
...
```
>>>>>>> merge master to 1.10, with fixes (#7682)
<<<<<<< HEAD
```yaml
---
title: <your tutorial title here>
min-kubernetes-server-version: v1.8
---
```
In code and configuration examples, do not include comments about alternative versions.
Be careful to not include incorrect statements in your examples as comments, such as:
```yaml
apiVersion: v1 # earlier versions use...
kind: Pod
@@ -174,12 +209,18 @@ kind: Pod
```
## Kubernetes.io word list
||||||| merged common ancestors
{% comment %}## Kubernetes.io word list
=======
## Kubernetes.io word list
>>>>>>> merge master to 1.10, with fixes (#7682)
A list of Kubernetes-specific terms and words to be used consistently across the site.
<table>
<<<<<<< HEAD
<tr><th>Term</th><th>Usage</th></tr>
<<<<<<< HEAD
<tr><td>Kubernetes</td><td>Kubernetes should always be capitalized.</td></tr>
<tr><td>Docker</td><td>Docker should always be capitalized.</td></tr>
<tr><td>SIG Docs</td><td>SIG Docs rather than SIG-DOCS or other variations.</td></tr>
@@ -193,6 +234,15 @@ A list of Kubernetes-specific terms and words to be used consistently across the
<tr><td>TBD</td><td>TBD</td></tr>
</table>{% endcomment %}
>>>>>>> fix description about contribute style guide (#7592)
||||||| merged common ancestors
<tr><td>TBD</td><td>TBD</td></tr>
</table>{% endcomment %}
=======
<tr><td>Kubernetes</td><td>Kubernetes should always be capitalized.</td></tr>
<tr><td>Docker</td><td>Docker should always be capitalized.</td></tr>
<tr><td>SIG Docs</td><td>SIG Docs rather than SIG-DOCS or other variations.</td></tr>
</table>
>>>>>>> merge master to 1.10, with fixes (#7682)
## Callout Formatting
Callouts help create different rhetorical appeal levels. Our documentation supports three different callouts: **Note:** {: .note}, **Caution:** {: .caution}, and **Warning:** {: .warning}.
File diff suppressed because it is too large Load Diff
+1 -1
View File
@@ -187,7 +187,7 @@ $(document).ready(function() {
var scrollPosition = $(window).scrollTop();
scrollActions(scrollPosition);
checkActiveElement(flatToc, scrollPosition);
// TODO: prevent scroll on sidebar from propogating to window
// TODO: prevent scroll on sidebar from propagating to window
$(window).on('scroll', function(event) {
var scrollPosition = $(window).scrollTop();
var activeSectionTokens = scrollActions(scrollPosition);
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
@@ -0,0 +1,196 @@
$(document).ready(function() {
/**
* TODO: Refactor with intent toward pure functions. Mutation of state can lead to bugs and difficult debugging.
*/
var toc = navData.toc;
var flatToc = navData.flatToc.reverse();
function collectNodes(tocMap) {
var tocNodes = {};
tocMap.map(function(node, index) {
var sectionNode = $('#' + node.section);
var tocSubsections = {};
tocItem = {section: sectionNode};
var subsectionNodes;
if (node.subsections) {
subsectionNodes = (collectNodes(node.subsections));
tocItem.subsections = subsectionNodes;
}
tocNodes[node.section] = tocItem;
});
return tocNodes;
}
var tocItems = collectNodes(toc);
function collectNodesFlat(tocMap, obj) {
var collect = obj || {};
tocMap.map(function(node, index) {
var sectionNode = $('#' + node.section);
tocItem = {section: sectionNode};
if (node.subsections) {
subsectionNodes = (collectNodesFlat(node.subsections, collect));
}
collect[node.section] = sectionNode;
});
return collect;
}
var tocFlat = collectNodesFlat(toc);
var prevSectionToken;
var prevSubsectionToken;
var activeTokensObj = {};
function scrollActions(scrollPosition) {
var activeSection = checkNodePositions(toc, tocFlat, scrollPosition);
var activeSubSection,
prevL1Nav,
currL1Nav,
prevL2Nav,
currL2Nav;
// No active section - return existing activeTokensObj (may be empty)
if (!activeSection) {
return activeTokensObj;
}
/**
* This block deals with L1Nav sections
*/
// If no previous token, set previous to current active and show L1Nav
if (!prevSectionToken) {
prevSectionToken = activeSection.token;
currL1Nav = getNavNode(activeSection.token);
currL1Nav.show('fast');
}
// If active active is not the same as previous, hide previous L1Nav and show current L1Nav; set previous to current
else if (activeSection.token !== prevSectionToken) {
prevL1Nav = getNavNode(prevSectionToken);
currL1Nav = getNavNode(activeSection.token);
prevL1Nav.hide('fast');
currL1Nav.show('fast');
prevSectionToken = activeSection.token;
}
/**
* This block deals with L2Nav subsections
*/
// If there is a subsections array and it has a non-zero length, set active subsection
if (activeSection.subsections && activeSection.subsections.length !== 0) {
activeSubSection = checkNodePositions(activeSection.subsections, tocFlat, scrollPosition);
if (activeSubSection) {
if (!prevSubsectionToken) {
prevSubsectionToken = activeSubSection.token;
currL2Nav = getNavNode(activeSubSection.token);
currL2Nav.show('fast');
} else if (activeSubSection.token !== prevSubsectionToken) {
prevL2Nav = getNavNode(prevSubsectionToken);
currL2Nav = getNavNode(activeSubSection.token);
prevL2Nav.hide('fast');
currL2Nav.show('fast');
prevSubsectionToken = activeSubSection.token;
}
} else {
prevL2Nav = getNavNode(prevSubsectionToken);
prevL2Nav.hide('fast');
prevSubsectionToken = null;
}
}
activeTokensObj.L1 = prevSectionToken;
activeTokensObj.L2 = prevSubsectionToken;
return activeTokensObj;
}
/**
* Checks for active elements by scroll position
*/
var prevElemToken;
var activeElemToken;
function checkActiveElement(items, scrollPosition) {
var offset = 50;
var offsetScroll = scrollPosition + offset;
var visibleNode;
for (var i = 0; i < items.length; i++) {
var token = items[i];
var node = getHeadingNode(token);
if (offsetScroll >= node.offset().top) {
activeElemToken = token;
}
}
if (!prevElemToken) {
getNavElemNode(activeElemToken).addClass('selected');
prevElemToken = activeElemToken;
return;
}
if (activeElemToken !== prevElemToken) {
getNavElemNode(prevElemToken).removeClass('selected');
getNavElemNode(activeElemToken).addClass('selected');
prevElemToken = activeElemToken;
}
return activeElemToken;
}
function getHeadingNode(token) {
return $('#' + token);
}
function getNavNode(token) {
return $('#' + token + '-nav');
}
function getNavElemNode(token) {
return $('#sidebar-wrapper > ul a[href="#' + token + '"]');
}
function checkNodePositions(nodes, flatNodeMap, scrollPosition) {
var activeNode;
for (var i = 0; i < nodes.length; i++) {
var item = nodes[i];
var node = flatNodeMap[item.section];
var nodeTop = node.offset().top - 50;
if (scrollPosition >= nodeTop) {
activeNode = {token: item.section, node: node};
if (item.subsections) {
activeNode.subsections = item.subsections;
}
break;
}
}
return activeNode;
}
function scrollToNav(token) {
setTimeout(function() {
var scrollPosition = $(window).scrollTop();
var activeSectionTokens = scrollActions(scrollPosition);
var activeElemToken = checkActiveElement(flatToc, scrollPosition);
var navNode = $('#sidebar-wrapper > ul a[href="#' + token + '"]');
$('#sidebar-wrapper').scrollTo(navNode, {duration: 'fast', axis: 'y'});
}, 200);
}
$(window).on('hashchange', function(event) {
var scrollPosition = $(window).scrollTop();
var activeSectionTokens = scrollActions(scrollPosition);
var activeElemToken = checkActiveElement(flatToc, scrollPosition);
var scrollToken = activeSectionTokens.L2 ? activeSectionTokens.L2 : activeSectionTokens.L1;
scrollToNav(scrollToken);
var token = location.hash.slice(1);
});
var scrollPosition = $(window).scrollTop();
scrollActions(scrollPosition);
checkActiveElement(flatToc, scrollPosition);
// TODO: prevent scroll on sidebar from propagating to window
$(window).on('scroll', function(event) {
var scrollPosition = $(window).scrollTop();
var activeSectionTokens = scrollActions(scrollPosition);
var activeElemToken = checkActiveElement(flatToc, scrollPosition);
});
});
+6
View File
@@ -23,12 +23,18 @@ client libraries:
- [Kubernetes Go client library](https://github.com/kubernetes/client-go/)
<<<<<<< HEAD
<<<<<<< HEAD
- [Kubernetes Python client library](https://github.com/kubernetes-client/python)
||||||| merged common ancestors
- [Kubernetes Python client libary](https://github.com/kubernetes-incubator/client-python)
=======
- [Kubernetes Python client library](https://github.com/kubernetes-incubator/client-python)
>>>>>>> fix description about client library (#7634)
||||||| merged common ancestors
- [Kubernetes Python client library](https://github.com/kubernetes-incubator/client-python)
=======
- [Kubernetes Python client library](https://github.com/kubernetes-client/python)
>>>>>>> merge master to 1.10, with fixes (#7682)
## CLI Reference
@@ -21,9 +21,15 @@ Please check these documents out for more detailed how-to-upgrade guidance:
* [1.7.x to 1.7.y upgrades](/docs/tasks/administer-cluster/kubeadm-upgrade-1-8/)
* [1.7 to 1.8 upgrades](/docs/tasks/administer-cluster/kubeadm-upgrade-1-8/)
* [1.8.x to 1.8.y upgrades](/docs/tasks/administer-cluster/kubeadm-upgrade-1-8/)
<<<<<<< HEAD
* [1.8.x to 1.9.x upgrades](/docs/tasks/administer-cluster/kubeadm-upgrade-1-9/)
* [1.9.x to 1.9.y upgrades](/docs/tasks/administer-cluster/kubeadm-upgrade-1-9/)
* [1.9.x to 1.9.y HA cluster upgrades](/docs/tasks/administer-cluster/kubeadm-upgrade-ha/)
||||||| merged common ancestors
=======
* [1.8.x to 1.9.x upgrades](/docs/tasks/administer-cluster/kubeadm-upgrade-1-9/)
* [1.9.x to 1.9.y upgrades](/docs/tasks/administer-cluster/kubeadm-upgrade-1-9/)
>>>>>>> merge master to 1.10, with fixes (#7682)
## kubeadm upgrade plan {#cmd-upgrade-plan}
{% include_relative generated/kubeadm_upgrade_plan.md %}
+20
View File
@@ -0,0 +1,20 @@
---
title: Hosted Kubernetes Solutions
---
{% capture overview %}
TODO
{% endcapture %}
{% capture body %}
TODO
{% endcapture %}
{% include templates/concept.md %}
+382 -1
View File
@@ -243,6 +243,7 @@ Please select one of the tabs to see installation instructions for the respectiv
1. Now copy the systemd unit file like so:
<<<<<<< HEAD
```shell
cat >/etc/systemd/system/etcd.service <<EOF
[Unit]
@@ -283,6 +284,89 @@ Please select one of the tabs to see installation instructions for the respectiv
```
Make sure you replace `<etcd0-ip-address>`, `<etcd1-ip-address>` and `<etcd2-ip-address>` with the appropriate IPv4 addresses. Also, make sure that you replace `<etcd0>`, `<etcd1>` and `<etcd2>` with real hostnames of each machine. These machines must be able to reach every other using DNS or make sure that records are added to `/etc/hosts`.
||||||| merged common ancestors
```shell
cat >/etc/systemd/system/etcd.service <<EOL
[Unit]
Description=etcd
Documentation=https://github.com/coreos/etcd
Conflicts=etcd.service
Conflicts=etcd2.service
[Service]
EnvironmentFile=/etc/etcd.env
Type=notify
Restart=always
RestartSec=5s
LimitNOFILE=40000
TimeoutStartSec=0
ExecStart=/usr/local/bin/etcd --name ${PEER_NAME} \
--data-dir /var/lib/etcd \
--listen-client-urls https://${PRIVATE_IP}:2379 \
--advertise-client-urls https://${PRIVATE_IP}:2379 \
--listen-peer-urls https://${PRIVATE_IP}:2380 \
--initial-advertise-peer-urls https://${PRIVATE_IP}:2380 \
--cert-file=/etc/kubernetes/pki/etcd/server.pem \
--key-file=/etc/kubernetes/pki/etcd/server-key.pem \
--client-cert-auth \
--trusted-ca-file=/etc/kubernetes/pki/etcd/ca.pem \
--peer-cert-file=/etc/kubernetes/pki/etcd/peer.pem \
--peer-key-file=/etc/kubernetes/pki/etcd/peer-key.pem \
--peer-client-cert-auth \
--peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.pem \
--initial-cluster etcd0=https://<etcd0-ip-address>:2380,etcd1=https://<etcd1-ip-address>:2380,etcd2=https://<etcd2-ip-address>:2380 \
--initial-cluster-token my-etcd-token \
--initial-cluster-state new
[Install]
WantedBy=multi-user.target
EOL
```
Make sure you replace `<etcd0-ip-address>`, `<etcd1-ip-address>` and `<etcd2-ip-address>` with the appropriate IPv4 addresses.
=======
```shell
cat >/etc/systemd/system/etcd.service <<EOF
[Unit]
Description=etcd
Documentation=https://github.com/coreos/etcd
Conflicts=etcd.service
Conflicts=etcd2.service
[Service]
EnvironmentFile=/etc/etcd.env
Type=notify
Restart=always
RestartSec=5s
LimitNOFILE=40000
TimeoutStartSec=0
ExecStart=/usr/local/bin/etcd --name ${PEER_NAME} \
--data-dir /var/lib/etcd \
--listen-client-urls https://${PRIVATE_IP}:2379 \
--advertise-client-urls https://${PRIVATE_IP}:2379 \
--listen-peer-urls https://${PRIVATE_IP}:2380 \
--initial-advertise-peer-urls https://${PRIVATE_IP}:2380 \
--cert-file=/etc/kubernetes/pki/etcd/server.pem \
--key-file=/etc/kubernetes/pki/etcd/server-key.pem \
--client-cert-auth \
--trusted-ca-file=/etc/kubernetes/pki/etcd/ca.pem \
--peer-cert-file=/etc/kubernetes/pki/etcd/peer.pem \
--peer-key-file=/etc/kubernetes/pki/etcd/peer-key.pem \
--peer-client-cert-auth \
--peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.pem \
--initial-cluster etcd0=https://<etcd0-ip-address>:2380,etcd1=https://<etcd1-ip-address>:2380,etcd2=https://<etcd2-ip-address>:2380 \
--initial-cluster-token my-etcd-token \
--initial-cluster-state new
[Install]
WantedBy=multi-user.target
EOF
```
Make sure you replace `<etcd0-ip-address>`, `<etcd1-ip-address>` and `<etcd2-ip-address>` with the appropriate IPv4 addresses.
>>>>>>> merge master to 1.10, with fixes (#7682)
1. Finally, launch etcd like so:
@@ -304,6 +388,7 @@ Please select one of the tabs to see installation instructions for the respectiv
1. The first step is to run the following to generate the manifest file:
<<<<<<< HEAD
```shell
cat >/etc/kubernetes/manifests/etcd.yaml <<EOF
apiVersion: v1
@@ -376,6 +461,153 @@ Please select one of the tabs to see installation instructions for the respectiv
Make sure you replace:
* `<podname>` with the name of the node you're running on (e.g. `etcd0`, `etcd1` or `etcd2`)
* `<etcd0-ip-address>`, `<etcd1-ip-address>` and `<etcd2-ip-address>` with the public IPv4s of the other machines that host etcd.
||||||| merged common ancestors
```shell
cat >/etc/kubernetes/manifests/etcd.yaml <<EOL
apiVersion: v1
kind: Pod
metadata:
labels:
component: etcd
tier: control-plane
name: <podname>
namespace: kube-system
spec:
containers:
- command:
- etcd --name ${PEER_NAME} \
- --data-dir /var/lib/etcd \
- --listen-client-urls https://${PRIVATE_IP}:2379 \
- --advertise-client-urls https://${PRIVATE_IP}:2379 \
- --listen-peer-urls https://${PRIVATE_IP}:2380 \
- --initial-advertise-peer-urls https://${PRIVATE_IP}:2380 \
- --cert-file=/certs/server.pem \
- --key-file=/certs/server-key.pem \
- --client-cert-auth \
- --trusted-ca-file=/certs/ca.pem \
- --peer-cert-file=/certs/peer.pem \
- --peer-key-file=/certs/peer-key.pem \
- --peer-client-cert-auth \
- --peer-trusted-ca-file=/certs/ca.pem \
- --initial-cluster etcd0=https://<etcd0-ip-address>:2380,etcd1=https://<etcd1-ip-address>:2380,etcd1=https://<etcd2-ip-address>:2380 \
- --initial-cluster-token my-etcd-token \
- --initial-cluster-state new
image: gcr.io/google_containers/etcd-amd64:3.1.0
livenessProbe:
httpGet:
path: /health
port: 2379
scheme: HTTP
initialDelaySeconds: 15
timeoutSeconds: 15
name: etcd
env:
- name: PUBLIC_IP
valueFrom:
fieldRef:
fieldPath: status.hostIP
- name: PRIVATE_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
- name: PEER_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
volumeMounts:
- mountPath: /var/lib/etcd
name: etcd
- mountPath: /certs
name: certs
hostNetwork: true
volumes:
- hostPath:
path: /var/lib/etcd
type: DirectoryOrCreate
name: etcd
- hostPath:
path: /etc/kubernetes/pki/etcd
name: certs
EOL
```
Make sure you replace:
* `<podname>` with the name of the node you're running on (e.g. `etcd0`, `etcd1` or `etcd2`)
* `<etcd0-ip-address>`, `<etcd1-ip-address>` and `<etcd2-ip-address>` with the public IPv4s of the other machines that host etcd.
=======
```shell
cat >/etc/kubernetes/manifests/etcd.yaml <<EOF
apiVersion: v1
kind: Pod
metadata:
labels:
component: etcd
tier: control-plane
name: <podname>
namespace: kube-system
spec:
containers:
- command:
- etcd --name ${PEER_NAME} \
- --data-dir /var/lib/etcd \
- --listen-client-urls https://${PRIVATE_IP}:2379 \
- --advertise-client-urls https://${PRIVATE_IP}:2379 \
- --listen-peer-urls https://${PRIVATE_IP}:2380 \
- --initial-advertise-peer-urls https://${PRIVATE_IP}:2380 \
- --cert-file=/certs/server.pem \
- --key-file=/certs/server-key.pem \
- --client-cert-auth \
- --trusted-ca-file=/certs/ca.pem \
- --peer-cert-file=/certs/peer.pem \
- --peer-key-file=/certs/peer-key.pem \
- --peer-client-cert-auth \
- --peer-trusted-ca-file=/certs/ca.pem \
- --initial-cluster etcd0=https://<etcd0-ip-address>:2380,etcd1=https://<etcd1-ip-address>:2380,etcd2=https://<etcd2-ip-address>:2380 \
- --initial-cluster-token my-etcd-token \
- --initial-cluster-state new
image: gcr.io/google_containers/etcd-amd64:3.1.0
livenessProbe:
httpGet:
path: /health
port: 2379
scheme: HTTP
initialDelaySeconds: 15
timeoutSeconds: 15
name: etcd
env:
- name: PUBLIC_IP
valueFrom:
fieldRef:
fieldPath: status.hostIP
- name: PRIVATE_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
- name: PEER_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
volumeMounts:
- mountPath: /var/lib/etcd
name: etcd
- mountPath: /certs
name: certs
hostNetwork: true
volumes:
- hostPath:
path: /var/lib/etcd
type: DirectoryOrCreate
name: etcd
- hostPath:
path: /etc/kubernetes/pki/etcd
name: certs
EOF
```
Make sure you replace:
* `<podname>` with the name of the node you're running on (e.g. `etcd0`, `etcd1` or `etcd2`)
* `<etcd0-ip-address>`, `<etcd1-ip-address>` and `<etcd2-ip-address>` with the public IPv4s of the other machines that host etcd.
>>>>>>> merge master to 1.10, with fixes (#7682)
{% endcapture %}
@@ -408,13 +640,20 @@ If possible, use a smart load balancing algorithm like "least connections", and
{% capture onsite %}
In an on-site environment there may not be a physical load balancer available. Instead, a virtual IP pointing to a healthy master node can be used. There are a number of solutions for this including keepalived, Pacemaker and probably many others, some with and some without load balancing.
<<<<<<< HEAD
As an example we outline a simple setup based on keepalived. Depending on environment and requirements people may prefer different solutions. The configuration shown here provides an _active/passive_ failover without load balancing. If required, load balancing can by added quite easily by setting up HAProxy, NGINX or similar on the master nodes (not covered in this guide).
||||||| merged common ancestors
Only follow this step if your etcd is hosted on dedicated nodes (**Option 1**). If you are hosting etcd on the masters (**Option 2**), you can skip this step since you've already generated the etcd certificates on the masters.
=======
As an example we outline a simple setup based on keepalived. Depending on environment and requirements people may prefer different solutions. The configuration shown here provides an _active/passive_ failover without load balancing. If required, load balancing can by added quite easily by setting up HAProxy, NGINX or similar on the master nodes (not covered in this guide).
>>>>>>> merge master to 1.10, with fixes (#7682)
1. Install keepalived, e.g. using your distribution's package manager. The configuration shown here works with version `1.3.5` but is expected to work with may other versions. Make sure to have it enabled (chkconfig, systemd, ...) so that it starts automatically when the respective node comes up.
2. Create the following configuration file _/etc/keepalived/keepalived.conf_ on all master nodes:
```shell
<<<<<<< HEAD
! Configuration File for keepalived
global_defs {
router_id LVS_DEVEL
@@ -444,6 +683,42 @@ As an example we outline a simple setup based on keepalived. Depending on enviro
check_apiserver
}
}
||||||| merged common ancestors
mkdir -p /etc/kubernetes/pki/etcd
scp root@<etcd0-ip-address>:/etc/kubernetes/pki/etcd/ca.pem /etc/kubernetes/pki/etcd
scp root@<etcd0-ip-address>:/etc/kubernetes/pki/etcd/client.pem /etc/kubernetes/pki/etcd
scp root@<etcd0-ip-address>:/etc/kubernetes/pki/etcd/client-key.pem /etc/kubernetes/pki/etcd
=======
! Configuration File for keepalived
global_defs {
router_id LVS_DEVEL
}
vrrp_script check_apiserver {
script "/etc/keepalived/check_apiserver.sh"
interval 3
weight -2
fall 10
rise 2
}
vrrp_instance VI_1 {
state <STATE>
interface <INTERFACE>
virtual_router_id 51
priority <PRIORITY>
authentication {
auth_type PASS
auth_pass 4be37dc3b4c90194d1600c483e10ad1d
}
virtual_ipaddress {
<VIRTUAL-IP>
}
track_script {
check_apiserver
}
}
>>>>>>> merge master to 1.10, with fixes (#7682)
```
In the section `vrrp_instance VI_1`, change few lines depending on your setup:
@@ -469,11 +744,28 @@ As an example we outline a simple setup based on keepalived. Depending on enviro
curl --silent --max-time 2 --insecure https://<VIRTUAL-IP>:6443/ -o /dev/null || errorExit "Error GET https://<VIRTUAL-IP>:6443/"
fi
```
Replace the `<VIRTUAL-IP>` by your chosen virtual IP.
<<<<<<< HEAD
Replace the `<VIRTUAL-IP>` by your chosen virtual IP.
||||||| merged common ancestors
Ensure that the following placeholders are replaced:
=======
4. Restart keepalived. While no Kubernetes services are up yet it will log health check fails on all master nodes. This will stop as soon as the first master node has been bootstrapped.
>>>>>>> merge master to 1.10, with fixes (#7682)
<<<<<<< HEAD
4. Restart keepalived. While no Kubernetes services are up yet it will log health check fails on all master nodes. This will stop as soon as the first master node has been bootstrapped.
||||||| merged common ancestors
- `<private-ip>` with the private IPv4 of the master server.
- `<etcd0-ip>`, `<etcd1-ip>` and `<etcd2-ip>` with the IP addresses of your three etcd nodes
- `<podCIDR>` with your Pod CIDR. Please read the [CNI network section](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/#pod-network) of the docs for more information. Some CNI providers do not require a value to be set.
=======
{% endcapture %}
>>>>>>> merge master to 1.10, with fixes (#7682)
<<<<<<< HEAD
{% endcapture %}
{% assign tab_set_name = "lb_mode" %}
@@ -531,6 +823,65 @@ Only follow this step if your etcd is hosted on dedicated nodes (**Option 1**).
- `<podCIDR>` with your Pod CIDR. Please read the [CNI network section](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/#pod-network) of the docs for more information. Some CNI providers do not require a value to be set.
**Note:** If you are using Kubernetes 1.9+, you can replace the `apiserver-count: 3` extra argument with `endpoint-reconciler-type: lease`. For more information, see [the documentation](https://kubernetes.io/docs/admin/high-availability/#endpoint-reconciler).
||||||| merged common ancestors
**Note:** If you are using Kubernetes 1.9+, you can replace the `apiserver-count: 3` extra argument with `endpoint-reconciler-type=lease`. For more information, see [the documentation](https://kubernetes.io/docs/admin/high-availability/#endpoint-reconciler).
=======
{% assign tab_set_name = "lb_mode" %}
{% assign tab_names = "Choose one...,Cloud,On-Site" | split: ',' | compact %}
{% assign tab_contents = site.emptyArray | push: choose | push: cloud | push: onsite %}
{% include tabs.md %}
## Acquire etcd certs
Only follow this step if your etcd is hosted on dedicated nodes (**Option 1**). If you are hosting etcd on the masters (**Option 2**), you can skip this step since you've already generated the etcd certificates on the masters.
1. Generate SSH keys for each of the master nodes by following the steps in the [create ssh access](#create-ssh-access) section. After doing this, each master will have an SSH key in `~/.ssh/id_rsa.pub` and an entry in `etcd0`'s `~/.ssh/authorized_keys` file.
1. Run the following:
```shell
mkdir -p /etc/kubernetes/pki/etcd
scp root@<etcd0-ip-address>:/etc/kubernetes/pki/etcd/ca.pem /etc/kubernetes/pki/etcd
scp root@<etcd0-ip-address>:/etc/kubernetes/pki/etcd/client.pem /etc/kubernetes/pki/etcd
scp root@<etcd0-ip-address>:/etc/kubernetes/pki/etcd/client-key.pem /etc/kubernetes/pki/etcd
```
## Run `kubeadm init` on `master0` {#kubeadm-init-master0}
1. In order for kubeadm to run, you first need to write a configuration file:
```shell
cat >config.yaml <<EOF
apiVersion: kubeadm.k8s.io/v1alpha1
kind: MasterConfiguration
api:
advertiseAddress: <private-ip>
etcd:
endpoints:
- https://<etcd0-ip-address>:2379
- https://<etcd1-ip-address>:2379
- https://<etcd2-ip-address>:2379
caFile: /etc/kubernetes/pki/etcd/ca.pem
certFile: /etc/kubernetes/pki/etcd/client.pem
keyFile: /etc/kubernetes/pki/etcd/client-key.pem
networking:
podSubnet: <podCIDR>
apiServerCertSANs:
- <load-balancer-ip>
apiServerExtraArgs:
apiserver-count: "3"
EOF
```
Ensure that the following placeholders are replaced:
- `<private-ip>` with the private IPv4 of the master server.
- `<etcd0-ip>`, `<etcd1-ip>` and `<etcd2-ip>` with the IP addresses of your three etcd nodes
- `<podCIDR>` with your Pod CIDR. Please read the [CNI network section](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/#pod-network) of the docs for more information. Some CNI providers do not require a value to be set.
**Note:** If you are using Kubernetes 1.9+, you can replace the `apiserver-count: 3` extra argument with `endpoint-reconciler-type: lease`. For more information, see [the documentation](https://kubernetes.io/docs/admin/high-availability/#endpoint-reconciler).
>>>>>>> merge master to 1.10, with fixes (#7682)
1. When this is done, run kubeadm like so:
@@ -547,10 +898,22 @@ Before running kubeadm on the other masters, you need to first copy the K8s CA c
1. Follow the steps in the [create ssh access](#create-ssh-access) section, but instead of adding to `etcd0`'s `authorized_keys` file, add them to `master0`.
1. Once you've done this, run:
<<<<<<< HEAD
```shell
scp root@<master0-ip-address>:/etc/kubernetes/pki/* /etc/kubernetes/pki
rm apiserver.*
```
||||||| merged common ancestors
```shell
scp root@<master0-ip-address>:/etc/kubernetes/pki/* /etc/kubernetes/pki
rm apiserver.crt
```
=======
```shell
scp root@<master0-ip-address>:/etc/kubernetes/pki/* /etc/kubernetes/pki
rm apiserver.crt
```
>>>>>>> merge master to 1.10, with fixes (#7682)
#### Option 2: Copy paste
@@ -576,6 +939,7 @@ Next provision and set up the worker nodes. To do this, you will need to provisi
1. Reconfigure kube-proxy to access kube-apiserver via the load balancer:
<<<<<<< HEAD
```shell
kubectl get configmap -n kube-system kube-proxy -o yaml > kube-proxy-cm.yaml
sed -i 's#server:.*#server: https://<masterLoadBalancerFQDN>:6443#g' kube-proxy-cm.yaml
@@ -583,6 +947,23 @@ Next provision and set up the worker nodes. To do this, you will need to provisi
# restart all kube-proxy pods to ensure that they load the new configmap
kubectl delete pod -n kube-system -l k8s-app=kube-proxy
```
||||||| merged common ancestors
```shell
kubectl get configmap -n kube-system kube-proxy -o yaml > kube-proxy.yaml
sudo sed -i 's#server:.*#server: https://<masterLoadBalancerFQDN>:6443#g' kube-proxy.cm
kubectl apply -f kube-proxy.cm --force
# restart all kube-proxy pods to ensure that they load the new configmap
kubectl delete pod -n kube-system -l k8s-app=kube-proxy
```
=======
```shell
kubectl get configmap -n kube-system kube-proxy -o yaml > kube-proxy-сm.yaml
sed -i 's#server:.*#server: https://<masterLoadBalancerFQDN>:6443#g' kube-proxy-cm.yaml
kubectl apply -f kube-proxy-cm.yaml --force
# restart all kube-proxy pods to ensure that they load the new configmap
kubectl delete pod -n kube-system -l k8s-app=kube-proxy
```
>>>>>>> merge master to 1.10, with fixes (#7682)
1. Reconfigure the kubelet to access kube-apiserver via the load balancer:
+18
View File
@@ -139,6 +139,7 @@ systemctl enable docker && systemctl start docker
{% endcapture %}
<<<<<<< HEAD
<<<<<<< HEAD
||||||| merged common ancestors
**Note**: Make sure that the cgroup driver used by kubelet is the same as the one used by
@@ -171,6 +172,23 @@ and restart Docker. Or ensure the `--cgroup-driver` kubelet flag is set to the s
as Docker (e.g. `cgroupfs`).
>>>>>>> fix description about kubeadm (#7594)
||||||| merged common ancestors
**Note**: Make sure that the cgroup driver used by kubelet is the same as the one used by
Docker. To ensure compatibility you can either update Docker, like so:
```bash
cat << EOF > /etc/docker/daemon.json
{
"exec-opts": ["native.cgroupdriver=systemd"]
}
EOF
```
and restart Docker. Or ensure the `--cgroup-driver` kubelet flag is set to the same value
as Docker (e.g. `cgroupfs`).
=======
>>>>>>> merge master to 1.10, with fixes (#7682)
{% assign tab_set_name = "docker_install" %}
{% assign tab_names = "Ubuntu, Debian or HypriotOS;CentOS, RHEL or Fedora; Container Linux" | split: ';' | compact %}
{% assign tab_contents = site.emptyArray | push: docker_ubuntu | push: docker_centos | push: docker_coreos %}
+31
View File
@@ -33,9 +33,15 @@ a Kubernetes cluster from scratch.
* [Ubuntu on LXD](/docs/getting-started-guides/ubuntu/local/) supports a nine-instance deployment on localhost.
<<<<<<< HEAD
* [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) can use VirtualBox on your machine to deploy Kubernetes to one or more VMs for development and test scenarios. Scales to full multi-node cluster.
* [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers) is a Terraform/Packer/BASH based Infrastructure as Code (IaC) scripts to create a seven node (1 Boot, 1 Master, 1 Management, 1 Proxy and 3 Workers) LXD cluster on Linux Host.
||||||| merged common ancestors
* [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) can use VirtualBox on your machine to deploy Kubernetes to one or more VMs for development and test scenarios. Scales to full multi-node cluster.
=======
* [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) can use VirtualBox on your machine to deploy Kubernetes to one or more VMs for development and test scenarios. Scales to full multi-node cluster.
>>>>>>> merge master to 1.10, with fixes (#7682)
# Hosted Solutions
@@ -61,10 +67,18 @@ a Kubernetes cluster from scratch.
* [Giant Swarm](https://giantswarm.io/product/) offers managed Kubernetes clusters in their own datacenter, on-premises, or on public clouds.
<<<<<<< HEAD
* [Kubermatic](https://www.loodse.com) provides managed Kubernetes clusters for various public clouds, including AWS and Digital Ocean, as well as on-premises with OpenStack integration.
* [Pivotal Container Service](https://pivotal.io/platform/pivotal-container-service) provides enterprise-grade Kubernetes for both on-premises and public clouds. PKS enables on-demand provisioning of Kubernetes clusters, multi-tenancy and fully automated day-2 operations.
||||||| merged common ancestors
* [Kubermatic](https://kubermatic.io) provides managed Kubernetes clusters for various public clouds, including AWS and Digital Ocean, as well as on-premises with OpenStack integration.
=======
* [Kubermatic](https://www.loodse.com) provides managed Kubernetes clusters for various public clouds, including AWS and Digital Ocean, as well as on-premises with OpenStack integration.
>>>>>>> merge master to 1.10, with fixes (#7682)
* [Pivotal Container Service](https://pivotal.io/platform/pivotal-container-service) provides enterprise-grade Kubernetes for both on-premises and public clouds. PKS enables on-demand provisioning of Kubernetes clusters, multi-tenancy and fully automated day-2 operations.
`
# Turnkey Cloud Solutions
These solutions allow you to create Kubernetes clusters on a range of Cloud IaaS providers with only a
@@ -127,6 +141,13 @@ These solutions are combinations of cloud providers and operating systems not co
## Bare Metal
<<<<<<< HEAD
||||||| merged common ancestors
* [Offline](/docs/getting-started-guides/coreos/bare_metal_offline/) (no internet required. Uses CoreOS and Flannel)
* [Fedora via Ansible](/docs/getting-started-guides/fedora/fedora_ansible_config/)
=======
* [Offline](/docs/getting-started-guides/coreos/bare_metal_offline/) (no internet required. Uses CoreOS and Flannel)
>>>>>>> merge master to 1.10, with fixes (#7682)
* [Fedora (Single Node)](/docs/getting-started-guides/fedora/fedora_manual_config/)
* [Fedora (Multi Node)](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/)
* [Kubernetes on Ubuntu](/docs/getting-started-guides/ubuntu/)
@@ -166,8 +187,18 @@ AWS | CoreOS | CoreOS | flannel | [docs](/docs/gettin
GCE | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/coreos/) | Community ([@pires](https://github.com/pires))
Vagrant | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/coreos/) | Community ([@pires](https://github.com/pires), [@AntonioMeireles](https://github.com/AntonioMeireles))
CloudStack | Ansible | CoreOS | flannel | [docs](/docs/getting-started-guides/cloudstack/) | Community ([@sebgoa](https://github.com/sebgoa))
<<<<<<< HEAD
VMware vSphere | any | multi-support | multi-support | [docs](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/) | [Community](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/contactus.html)
||||||| merged common ancestors
Vmware vSphere | Saltstack | Debian | OVS | [docs](/docs/getting-started-guides/vsphere/) | Community ([@imkin](https://github.com/imkin))
=======
<<<<<<< HEAD
VMware vSphere | any | multi-support | multi-support | [docs](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/) | [Community](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/contactus.html)
=======
Vmware vSphere | Saltstack | Debian | OVS | [docs](/docs/getting-started-guides/vsphere/) | Community ([@imkin](https://github.com/imkin))
>>>>>>> merge master to 1.10, with fixes (#7682)
Bare-metal | custom | CentOS | flannel | [docs](/docs/getting-started-guides/centos/centos_manual_config/) | Community ([@coolsvap](https://github.com/coolsvap))
>>>>>>> bb8c59a640337f352e57a094ddac20bd6bbd4715
lxd | Juju | Ubuntu | flannel/canal | [docs](/docs/getting-started-guides/ubuntu/local/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
AWS | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
Azure | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
@@ -0,0 +1,144 @@
---
reviewers:
- msau42
- jsafrane
title: Persistent Volume Claim Protection
---
{% capture overview %}
{% assign for_k8s_version="v1.9" %}{% include feature-state-alpha.md %}
As of Kubernetes 1.9, persistent volume claims (PVCs) that are in active use by a pod can be protected from pre-mature removal.
{% endcapture %}
{% capture prerequisites %}
- A v1.9 or higher Kubernetes must be installed.
- As PVC Protection is a Kubernetes v1.9 alpha feature it must be enabled:
1. [Admission controller](/docs/admin/admission-controllers/) must be started with the [PVC Protection plugin](/docs/admin/admission-controllers/#persistent-volume-claim-protection-alpha).
2. All Kubernetes components must be started with the `PVCProtection` alpha features enabled.
{% endcapture %}
{% capture steps %}
## PVC Protection Verification
The example below uses a GCE PD `StorageClass`, however, similar steps can be performed for any volume type.
Create a `StorageClass` for convenient storage provisioning:
```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: slow
provisioner: kubernetes.io/gce-pd
parameters:
type: pd-standard
```
There are two scenarios: a PVC deleted by a user is either in active use or not in active use by a pod.
### Scenario 1: The PVC is not in active use by a pod
- Create a PVC:
```yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: slzc
spec:
accessModes:
- ReadWriteOnce
storageClassName: slow
resources:
requests:
storage: 3.7Gi
```
- Check that the PVC has the finalizer `kubernetes.io/pvc-protection` set:
```shell
$ kubectl describe pvc slzc
Name: slzc
Namespace: default
StorageClass: slow
Status: Bound
Volume: pvc-bee8c30a-d6a3-11e7-9af0-42010a800002
Labels: <none>
Annotations: pv.kubernetes.io/bind-completed=yes
pv.kubernetes.io/bound-by-controller=yes
volume.beta.kubernetes.io/storage-provisioner=kubernetes.io/gce-pd
Finalizers: [kubernetes.io/pvc-protection]
Capacity: 4Gi
Access Modes: RWO
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ProvisioningSucceeded 2m persistentvolume-controller Successfully provisioned volume pvc-bee8c30a-d6a3-11e7-9af0-42010a800002 using kubernetes.io/gce-pd
```
- Delete the PVC and check that the PVC (not in active use by a pod) was removed successfully.
### Scenario 2: The PVC is in active use by a pod
- Again, create the same PVC.
- Create a pod that uses the PVC:
```yaml
kind: Pod
apiVersion: v1
metadata:
name: app1
spec:
containers:
- name: test-pod
image: k8s.gcr.io/busybox:1.24
command:
- "/bin/sh"
args:
- "-c"
- "date > /mnt/app1.txt; sleep 60 && exit 0 || exit 1"
volumeMounts:
- name: path-pvc
mountPath: "/mnt"
restartPolicy: "Never"
volumes:
- name: path-pvc
persistentVolumeClaim:
claimName: slzc
```
- Wait until the pod status is `Running`, i.e. the PVC becomes in active use.
- Delete the PVC that is now in active use by a pod and verify that the PVC is not removed but its status is `Terminating`:
```shell
Name: slzc
Namespace: default
StorageClass: slow
Status: Terminating (since Fri, 01 Dec 2017 14:47:55 +0000)
Volume: pvc-803a1f4d-d6a6-11e7-9af0-42010a800002
Labels: <none>
Annotations: pv.kubernetes.io/bind-completed=yes
pv.kubernetes.io/bound-by-controller=yes
volume.beta.kubernetes.io/storage-provisioner=kubernetes.io/gce-pd
Finalizers: [kubernetes.io/pvc-protection]
Capacity: 4Gi
Access Modes: RWO
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ProvisioningSucceeded 52s persistentvolume-controller Successfully provisioned volume pvc-803a1f4d-d6a6-11e7-9af0-42010a800002 using kubernetes.io/gce-pd
```
- Wait until the pod status is `Terminated` (either delete the pod or wait until it finishes). Afterwards, check that the PVC is removed.
{% endcapture %}
{% capture discussion %}
{% endcapture %}
{% include templates/task.md %}
@@ -1,4 +1,12 @@
---
<<<<<<< HEAD:docs/tasks/administer-cluster/sysctl-cluster.md
||||||| merged common ancestors
approvers:
- sttts
=======
reviewers:
- sttts
>>>>>>> merge master to 1.10, with fixes (#7682):docs/concepts/cluster-administration/sysctl-cluster.md
title: Using Sysctls in a Kubernetes Cluster
reviewers:
- sttts
@@ -139,6 +147,7 @@ is recommended to use
[_taints and toleration_ feature](/docs/user-guide/kubectl/{{page.version}}/#taint) or
[taints on nodes](/docs/concepts/configuration/taint-and-toleration/)
to schedule those pods onto the right nodes.
<<<<<<< HEAD:docs/tasks/administer-cluster/sysctl-cluster.md
## PodSecurityPolicy Annotations
@@ -164,3 +173,25 @@ spec:
{% endcapture %}
{% include templates/task.md %}
||||||| merged common ancestors
=======
## PodSecurityPolicy Annotations
The use of sysctl in pods can be controlled via annotations on the PodSecurityPolicy.
Here is an example, it authorizes binding user creating pod with corresponding
_safe_ and _unsafe_ sysctls.
```yaml
apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
name: sysctl-psp
annotations:
security.alpha.kubernetes.io/sysctls: 'kernel.shm_rmid_forced'
security.alpha.kubernetes.io/unsafe-sysctls: 'net.ipv4.route.*,kernel.msg*'
spec:
...
```
>>>>>>> merge master to 1.10, with fixes (#7682):docs/concepts/cluster-administration/sysctl-cluster.md
@@ -62,13 +62,34 @@ where:
* `<your-pword>` is your Docker password.
* `<your-email>` is your Docker email.
<<<<<<< HEAD
You have successfully set your Docker credentials in the cluster as a Secret called `regcred`.
## Inspecting the Secret `regcred`
||||||| merged common ancestors
## Understanding your Secret
=======
You have successfully set your Docker credentials in the cluster as a Secret called `regcred`.
>>>>>>> merge master to 1.10, with fixes (#7682)
<<<<<<< HEAD
To understand the contents of the `regcred` Secret you just created, start by viewing the Secret in YAML format:
||||||| merged common ancestors
To understand what's in the Secret you just created, start by viewing the
Secret in YAML format:
=======
## Inspecting the Secret `regcred`
>>>>>>> merge master to 1.10, with fixes (#7682)
<<<<<<< HEAD
kubectl get secret regcred --output=yaml
||||||| merged common ancestors
kubectl get secret regsecret --output=yaml
=======
To understand the contents of the `regcred` Secret you just created, start by viewing the Secret in YAML format:
kubectl get secret regcred --output=yaml
>>>>>>> merge master to 1.10, with fixes (#7682)
The output is similar to this:
@@ -80,21 +101,50 @@ The output is similar to this:
...
name: regcred
...
<<<<<<< HEAD
type: kubernetes.io/dockerconfigjson
The value of the `.dockerconfigjson` field is a base64 representation of your Docker credentials.
||||||| merged common ancestors
type: kubernetes.io/dockercfg
The value of the `.dockercfg` field is a base64 representation of your secret data.
=======
type: kubernetes.io/dockerconfigjson
>>>>>>> merge master to 1.10, with fixes (#7682)
<<<<<<< HEAD
To understand what is in the `.dockerconfigjson` field, convert the secret data to a
||||||| merged common ancestors
Copy the base64 representation of the secret data into a file named `secret64`.
**Important**: Make sure there are no line breaks in your `secret64` file.
To understand what is in the `.dockercfg` field, convert the secret data to a
=======
The value of the `.dockerconfigjson` field is a base64 representation of your Docker credentials.
To understand what is in the `.dockerconfigjson` field, convert the secret data to a
>>>>>>> merge master to 1.10, with fixes (#7682)
readable format:
kubectl get secret regcred --output="jsonpath={.data.\.dockerconfigjson}" | base64 -d
The output is similar to this:
<<<<<<< HEAD
{"auths":{"yourprivateregistry.com":{"username":"janedoe","password":"xxxxxxxxxxx","email":"jdoe@example.com","auth":"c3R...zE2"}}}
To understand what is in the `auth` field, convert the base64-encoded data to a readable format:
||||||| merged common ancestors
{"yourprivateregistry.com":{"username":"janedoe","password":"xxxxxxxxxxx","email":"jdoe@example.com","auth":"c3R...zE2"}}
=======
{"auths":{"yourprivateregistry.com":{"username":"janedoe","password":"xxxxxxxxxxx","email":"jdoe@example.com","auth":"c3R...zE2"}}}
Notice that the Secret data contains the authorization token similar to your local `~/.docker/config.json` file.
>>>>>>> merge master to 1.10, with fixes (#7682)
<<<<<<< HEAD
echo "c3R...zE2" | base64 -d
The output, username and password concatenated with a `:`, is similar to this:
@@ -104,6 +154,12 @@ The output, username and password concatenated with a `:`, is similar to this:
Notice that the Secret data contains the authorization token similar to your local `~/.docker/config.json` file.
You have successfully set your Docker credentials as a Secret called `regcred` in the cluster.
||||||| merged common ancestors
Notice that the secret data contains the authorization token from your
`config.json` file.
=======
You have successfully set your Docker credentials as a Secret called `regcred` in the cluster.
>>>>>>> merge master to 1.10, with fixes (#7682)
## Create a Pod that uses your Secret
@@ -134,8 +190,17 @@ Create a Pod that uses your Secret, and verify that the Pod is running:
* Learn more about [Secrets](/docs/concepts/configuration/secret/).
* Learn more about [using a private registry](/docs/concepts/containers/images/#using-a-private-registry).
* See [kubectl create secret docker-registry](/docs/user-guide/kubectl/{{page.version}}/#-em-secret-docker-registry-em-).
<<<<<<< HEAD
* See [Secret](/docs/reference/generated/kubernetes-api/{{page.version}}/#secret-v1-core).
* See the `imagePullSecrets` field of [PodSpec](/docs/reference/generated/kubernetes-api/{{page.version}}/#podspec-v1-core).
||||||| merged common ancestors
* See [Secret](/docs/api-reference/{{page.version}}/#secret-v1-core)
* See the `imagePullSecrets` field of
[PodSpec](/docs/api-reference/{{page.version}}/#podspec-v1-core).
=======
* See [Secret](/docs/api-reference/{{page.version}}/#secret-v1-core).
* See the `imagePullSecrets` field of [PodSpec](/docs/api-reference/{{page.version}}/#podspec-v1-core).
>>>>>>> merge master to 1.10, with fixes (#7682)
{% endcapture %}
@@ -1,5 +1,13 @@
---
<<<<<<< HEAD
reviewers:
||||||| merged common ancestors
approvers:
- crassirostris
=======
reviewers:
- crassirostris
>>>>>>> merge master to 1.10, with fixes (#7682)
- piosz
- x13n
title: Events in Stackdriver
@@ -1,5 +1,13 @@
---
<<<<<<< HEAD
reviewers:
||||||| merged common ancestors
approvers:
- crassirostris
=======
reviewers:
- crassirostris
>>>>>>> merge master to 1.10, with fixes (#7682)
- piosz
- x13n
title: Logging Using Elasticsearch and Kibana
@@ -1,5 +1,13 @@
---
<<<<<<< HEAD
reviewers:
||||||| merged common ancestors
approvers:
- crassirostris
=======
reviewers:
- crassirostris
>>>>>>> merge master to 1.10, with fixes (#7682)
- piosz
- x13n
title: Logging Using Stackdriver
@@ -127,6 +127,7 @@ containers:
### Notes on the strategic merge patch
The patch you did in the preceding exercise is called a *strategic merge patch*.
<<<<<<< HEAD
Notice that the patch did not replace the `containers` list. Instead it added a new
Container to the list. In other words, the list in the patch was merged with the
existing list. This is not always what happens when you use a strategic merge patch on a list.
@@ -202,6 +203,88 @@ type PodSpec struct {
...
Tolerations []Toleration `json:"tolerations,omitempty" protobuf:"bytes,22,opt,name=tolerations"`
```
||||||| merged common ancestors
With a strategic merge patch, you can update a list by specifying only the elements
that you want to add to the list. The existing list elements remain, and the new elements
are merged with the existing elements. In the preceding exercise, the resulting `containers`
list has both the original nginx Container and the new redis Container.
=======
Notice that the patch did not replace the `containers` list. Instead it added a new
Container to the list. In other words, the list in the patch was merged with the
existing list. This is not always what happens when you use a strategic merge patch on a list.
In some cases, the list is replaced, not merged.
With a strategic merge patch, a list is either replaced or merged depending on its
patch strategy. The patch strategy is specified by the value of the `patchStrategy` key
in a field tag in the Kubernetes source code. For example, the `Containers` field of `PodSpec`
struct has a `patchStrategy` of `merge`:
```go
type PodSpec struct {
...
Containers []Container `json:"containers" patchStrategy:"merge" patchMergeKey:"name" ...`
```
You can also see the patch strategy in the
[OpenApi spec](https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json):
```json
"io.k8s.api.core.v1.PodSpec": {
...
"containers": {
"description": "List of containers belonging to the pod. ...
},
"x-kubernetes-patch-merge-key": "name",
"x-kubernetes-patch-strategy": "merge"
},
```
And you can see the patch strategy in the
[Kubernetes API documentation](/docs/reference/generated/kubernetes-api/v1.9/#podspec-v1-core).
Create a file named `patch-file-tolerations.yaml` that has this content:
```yaml
spec:
template:
spec:
tolerations:
- effect: NoSchedule
key: disktype
value: ssd
```
Patch your Deployment:
```shell
kubectl patch deployment patch-demo --patch "$(cat patch-file-tolerations.yaml)"
```
View the patched Deployment:
```shell
kubectl get deployment patch-demo --output yaml
```
The output shows that the PodSpec in the Deployment has only one Toleration:
```shell
tolerations:
- effect: NoSchedule
key: disktype
value: ssd
```
Notice that the `tolerations` list in the PodSpec was replaced, not merged. This is because
the Tolerations field of PodSpec does not have a `patchStrategy` key in its field tag. So the
strategic merge patch uses the default patch strategy, which is `replace`.
```go
type PodSpec struct {
...
Tolerations []Toleration `json:"tolerations,omitempty" protobuf:"bytes,22,opt,name=tolerations"`
```
>>>>>>> merge master to 1.10, with fixes (#7682)
## Use a JSON merge patch to update a Deployment
+128
View File
@@ -184,6 +184,126 @@ kubectl can be installed as part of the Google Cloud SDK.
{% include tabs.md %}
<<<<<<< HEAD
||||||| merged common ancestors
## Download as part of the Google Cloud SDK
kubectl can be installed as part of the Google Cloud SDK.
1. Install the [Google Cloud SDK](https://cloud.google.com/sdk/).
2. Run the following command to install `kubectl`:
gcloud components install kubectl
3. Run `kubectl version` to verify that the version you've installed is sufficiently up-to-date.
## Install with snap on Ubuntu
kubectl is available as a [snap](https://snapcraft.io/) application.
1. If you are on Ubuntu or one of other Linux distributions that support [snap](https://snapcraft.io/docs/core/install) package manager, you can install with:
sudo snap install kubectl --classic
2. Run `kubectl version` to verify that the version you've installed is sufficiently up-to-date.
## Install with Homebrew on macOS
1. If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you can install with:
brew install kubectl
2. Run `kubectl version` to verify that the version you've installed is sufficiently up-to-date.
## Install with Powershell from PSGallery
1. If you are on Windows and using [Powershell Gallery](https://www.powershellgallery.com/) package manager, you can install and update with:
Install-Script -Name install-kubectl -Scope CurrentUser -Force
install-kubectl.ps1 [-DownloadLocation <path>]
If no Downloadlocation is specified, kubectl will be installed in users temp Directory
2. The installer creates $HOME/.kube and instucts to create a config file
3. Updating
re-run Install-Script to update the installer
re-run install-kubectl.ps1 to install latest binaries
## Install with Chocolatey on Windows
1. If you are on Windows and using [Chocolatey](https://chocolatey.org) package manager, you can install with:
choco install kubernetes-cli
2. Run `kubectl version` to verify that the version you've installed is sufficiently up-to-date.
3. Configure kubectl to use a remote Kubernetes cluster:
cd C:\users\yourusername (Or wherever your %HOME% directory is)
mkdir .kube
cd .kube
touch config
Edit the config file with a text editor of your choice, such as Notepad for example.
=======
## Download as part of the Google Cloud SDK
kubectl can be installed as part of the Google Cloud SDK.
1. Install the [Google Cloud SDK](https://cloud.google.com/sdk/).
2. Run the following command to install `kubectl`:
gcloud components install kubectl
3. Run `kubectl version` to verify that the version you've installed is sufficiently up-to-date.
## Install with snap on Ubuntu
kubectl is available as a [snap](https://snapcraft.io/) application.
1. If you are on Ubuntu or one of other Linux distributions that support [snap](https://snapcraft.io/docs/core/install) package manager, you can install with:
sudo snap install kubectl --classic
2. Run `kubectl version` to verify that the version you've installed is sufficiently up-to-date.
## Install with Homebrew on macOS
1. If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you can install with:
brew install kubectl
2. Run `kubectl version` to verify that the version you've installed is sufficiently up-to-date.
## Install with Powershell from PSGallery
1. If you are on Windows and using [Powershell Gallery](https://www.powershellgallery.com/) package manager, you can install and update with:
Install-Script -Name install-kubectl -Scope CurrentUser -Force
install-kubectl.ps1 [-DownloadLocation <path>]
If no Downloadlocation is specified, kubectl will be installed in users temp Directory
2. The installer creates $HOME/.kube and instructs it to create a config file
3. Updating
re-run Install-Script to update the installer
re-run install-kubectl.ps1 to install latest binaries
## Install with Chocolatey on Windows
1. If you are on Windows and using [Chocolatey](https://chocolatey.org) package manager, you can install with:
choco install kubernetes-cli
2. Run `kubectl version` to verify that the version you've installed is sufficiently up-to-date.
3. Configure kubectl to use a remote Kubernetes cluster:
cd C:\users\yourusername (Or wherever your %HOME% directory is)
mkdir .kube
cd .kube
New-Item config -type file
Edit the config file with a text editor of your choice, such as Notepad for example.
>>>>>>> merge master to 1.10, with fixes (#7682)
## Configure kubectl
In order for kubectl to find and access a Kubernetes cluster, it needs a [kubeconfig file](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/), which is created automatically when you create a cluster using kube-up.sh or successfully deploy a Minikube cluster. See the [getting started guides](/docs/setup/) for more about creating clusters. If you need access to a cluster you didn't create, see the [Sharing Cluster Access document](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
@@ -202,9 +322,17 @@ If you see a message similar to the following, kubectl is not correctly configur
```shell
The connection to the server <server-name:port> was refused - did you specify the right host or port?
```
<<<<<<< HEAD
For example, if you are intending to run a Kubernetes cluster on your laptop (locally), you will need a tool like minikube to be installed first and then re-run the commands stated above.
||||||| merged common ancestors
=======
For example, if you are intending to run a Kubernetes cluster on your laptop (locally), you will need a tool like minikube to be installed first and then re-run the commands stated above.
>>>>>>> merge master to 1.10, with fixes (#7682)
If kubectl cluster-info returns the url response but you can't access your cluster, to check whether it is configured properly, use:
```shell
@@ -502,6 +502,7 @@ As noted in the [Facilitating Leader Election](#facilitating-leader-election) an
ZooKeeper ensemble require consistent configuration in order to elect a leader
and form a quorum. They also require consistent configuration of the Zab protocol
<<<<<<< HEAD
<<<<<<< HEAD
in order for the protocol to work correctly over a network. In our example we
achieve consistent configuration by embedding the configuration directly into
||||||| merged common ancestors
@@ -511,6 +512,13 @@ achive consistent configuration by embedding the configuration directly into
in order for the protocol to work correctly over a network. In our example we
achieve consistent configuration by embedding the configuration directly into
>>>>>>> fix description about zookeeper (#7598)
||||||| merged common ancestors
in order for the protocol to work correctly over a network. In our example we
achieve consistent configuration by embedding the configuration directly into
=======
in order for the protocol to work correctly over a network. In our example we
achieve consistent configuration by embedding the configuration directly into
>>>>>>> merge master to 1.10, with fixes (#7682)
the manifest.
Get the `zk` StatefulSet.
@@ -63,7 +63,7 @@ spec:
- key: "app"
operator: In
values:
- zk
- zk-hs
topologyKey: "kubernetes.io/hostname"
containers:
- name: kubernetes-zookeeper
@@ -1,3 +1,4 @@
<<<<<<< HEAD
---
reviewers:
- chenopis
@@ -115,3 +116,123 @@ Congrats on completing the Application Developer user journey! You've covered th
{% endcapture %}
{% include templates/user-journey-content.md %}
||||||| merged common ancestors
=======
---
reviewers:
- chenopis
layout: docsportal
css: /css/style_user_journeys.css, https://fonts.googleapis.com/icon?family=Material+Icons
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"
---
{% 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 [Intermediate App Developer](/docs/user-journeys/users/application-developer/intermediate/){:target="_blank"} topics first.
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
{% endcapture %}
{% 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 [logging example](/docs/concepts/cluster-administration/logging/#sidecar-container-with-a-logging-agent){:target="_blank"}). Two containers within a single Pod can communicate [via a shared volume](/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/){:target="_blank"}.
* **Init containers**: *Init containers* run before any of a Pod's *app containers* (such as main and sidecar containers). [Read more](/docs/concepts/workloads/pods/init-containers/){:target="_blank"}, see an [nginx server example](/docs/tasks/configure-pod-container/configure-pod-initialization/){:target="_blank"}, and [learn how to debug these containers](/docs/tasks/debug-application-cluster/debug-init-containers/){:target="_blank"}.
#### 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. [Read more](/docs/concepts/configuration/taint-and-toleration/){:target="_blank"}.
* **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 [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/){:target="_blank"} or [DownwardAPIVolumeFiles](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/){:target="_blank"}.
* **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. [PodPresets](/docs/concepts/workloads/pods/podpreset/){:target="_blank"} 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. [See an example](/docs/tasks/inject-data-application/podpreset/){:target="_blank"}.
#### 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" %}.
* **{% 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 [custom metrics](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md){:target="_blank"} spike. [See an example](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/){:target="_blank"} 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 [Federated ConfigMaps](/docs/tasks/administer-federation/configmap/){:target="_blank"} and [Federated Deployments](/docs/tasks/administer-federation/deployment/){:target="_blank"}.
## 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 [Controller pattern](/docs/concepts/api-extension/custom-resources/#custom-controllers){:target="_blank"}, 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.
#### Create Custom Resources
Based on the ideas above, you can define a new [Custom Resource](/docs/concepts/api-extension/custom-resources/#custom-resources){:target="_blank"} 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 [an example](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/){:target="_blank"}.
2. **API aggregation** - This method requires some [pre-configuration](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/){:target="_blank"} before you actually [set up a separate, extension API server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/){:target="_blank"}.
Note that unlike standard Kubernetes objects, which rely on the built-in [`kube-controller-manager`](/docs/reference/generated/kube-controller-manager/){:target="_blank"}, you'll need to write and run your own [custom controllers](https://github.com/kubernetes/sample-controller){:target="_blank"}.
You may also find the following info helpful:
* [How to know if custom resources are right for your use case](/docs/concepts/api-extension/custom-resources/#should-i-use-a-configmap-or-a-custom-resource){:target="_blank"}
* [How to decide between CRDs and API aggregation](/docs/concepts/api-extension/custom-resources/#choosing-a-method-for-adding-custom-resources){:target="_blank"}
#### 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 [specification](https://github.com/openservicebrokerapi/servicebroker){:target="_blank"} for doing so. These services are registered using {% glossary_tooltip text="Service Brokers" term_id="service-broker" %} (see [some examples](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#example-service-brokers){:target="_blank"}).
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 [Helm](/docs/tasks/service-catalog/install-service-catalog-using-helm/){:target="_blank"} or an [installer binary](/docs/tasks/service-catalog/install-service-catalog-using-sc/){:target="_blank"}.
## Explore additional resources
#### References
The following topics are also useful for building more complex applications:
* [Other points of extensibility within Kubernetes](/docs/concepts/overview/extending/){:target="_blank"} - A conceptual overview of where you can hook into the Kubernetes architecture.
* [Kubernetes Client Libraries](/docs/reference/client-libraries/){:target="_blank"} - 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 [SIG Apps](https://github.com/kubernetes/community/tree/master/sig-apps){:target="_blank"}.
* If you are interested in learning more about the inner workings of Kubernetes (e.g. networking), consider checking out the [Cluster Operator journey](/docs/user-journeys/users/cluster-operator/foundational/){:target="_blank"}.
{% endcapture %}
{% include templates/user-journey-content.md %}
>>>>>>> merge master to 1.10, with fixes (#7682)
@@ -1,3 +1,4 @@
<<<<<<< HEAD
---
reviewers:
- chenopis
@@ -230,3 +231,238 @@ If you feel fairly comfortable with the topics on this page and want to learn mo
{% include templates/user-journey-content.md %}
||||||| merged common ancestors
=======
---
reviewers:
- chenopis
layout: docsportal
css: /css/style_user_journeys.css, https://fonts.googleapis.com/icon?family=Material+Icons
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"
---
{% 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, [the subsequent page in the series](/docs/home/?path=users&persona=app-developer&level=intermediate){:target="_blank"} 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, its common to assign the latter to a dedicated {% glossary_tooltip text="cluster operator" term_id="cluster-operator" %}.
{% endcapture %}
{% 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:
* [Kubernetes Basics](/docs/tutorials/kubernetes-basics/#basics-modules){:target="_blank"} - Introduces you to six common Kubernetes workflows. Each section walks you through browser-based, interactive exercises complete with their own Kubernetes environment.
* [Katacoda](https://www.katacoda.com/courses/kubernetes/playground){:target="_blank"} - The playground equivalent of the environment used in *Kubernetes Basics* above. Katacoda also provides [more advanced tutorials](https://www.katacoda.com/courses/kubernetes/){:target="_blank"}, such as "Liveness and Readiness Healthchecks".
* [Play with Kubernetes](http://labs.play-with-k8s.com/){:target="_blank"} - 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.
* [Install Minikube](/docs/tasks/tools/install-minikube/){:target="_blank"}.
* [Install kubectl](/docs/tasks/tools/install-kubectl/){:target="_blank"}. ({% glossary_tooltip text="What is kubectl?" term_id="kubectl" %})
* *(Optional)* [Install Docker](/docs/setup/independent/install-kubeadm/#installing-docker){:target="_blank"} 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.
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.
## Deploy an application
#### Basic workloads
The following examples demonstrate the fundamentals of deploying Kubernetes apps:
* **Stateless apps**: [Deploy a simple nginx server](/docs/tasks/run-application/run-stateless-application-deployment/){:target="_blank"}.
* **Stateful apps**: [Deploy a MySQL database](/docs/tasks/run-application/run-single-instance-stateful-application/){:target="_blank"}.
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 [this explanation of Pods and Nodes](/docs/tutorials/kubernetes-basics/explore-intro/){:target="_blank"}.
* 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="deployment" %}** - 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 [stateless app example](/docs/tasks/run-application/run-stateless-application-deployment/#creating-and-exploring-an-nginx-deployment){:target="_blank"}) 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 [stateful app example](/docs/tasks/run-application/run-single-instance-stateful-application/#deploy-mysql){:target="_blank"}.
* *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 [how to configure volume storage](/docs/tasks/configure-pod-container/configure-volume-storage/){:target="_blank"}, or [read more about volume storage](/docs/concepts/storage/volumes/){:target="_blank"}.
* **{% 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 [how to set up persistent storage for your cluster](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/){:target="_blank"} or [read more about persistent volumes](/docs/concepts/storage/persistent-volumes/){:target="_blank"}.
#### 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.
## 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:
<div class="emphasize-box" markdown="1">
1. One instance of your app (a complete machine instance or just a container) goes down.
2. Because your team has monitoring set up, this pages the person on call.
3. The on-call person has to go in, investigate, and manually spin up a new instance.
4. 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.
</div>
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 [control plane](/docs/concepts/overview/components/#master-components){:target="_blank"}, 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 [*etcd*](https://github.com/coreos/etcd){:target="_blank"}. 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.
You can read more about the Kubernetes API [here](/docs/concepts/overview/working-with-objects/kubernetes-objects/){:target="_blank"}.
#### Controllers
Once youve declared your desired state through the Kubernetes API, the *controllers* work to make the clusters current state match this desired state.
The standard controller processes are [`kube-controller-manager`](/docs/reference/generated/kube-controller-manager/){:target="_blank"} and [`cloud-controller-manager`](/docs/concepts/overview/components/#cloud-controller-manager){:target="_blank"}, 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:
<div class="emphasize-box" markdown="1">
1. What is the current state of the cluster (X)?
2. What is the desired state of the cluster (Y)?
3. 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).<br>
*(Return to 1)*
</div>
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 [here](https://kubernetes.io/docs/concepts/){:target="_blank"}.
## Additional resources
The Kubernetes documentation is rich in detail. Here's a curated list of resources to help you start digging deeper.
### Basic concepts
* [More about the components that run Kubernetes](/docs/concepts/overview/components/){:target="_blank"}
* [Understanding Kubernetes objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/){:target="_blank"}
* [More about Node objects](/docs/concepts/architecture/nodes/){:target="_blank"}
* [More about Pod objects](/docs/concepts/workloads/pods/pod-overview/){:target="_blank"}
### Tutorials
* [Kubernetes Basics](/docs/tutorials/kubernetes-basics/){:target="_blank"}
* [Hello Minikube](/docs/tutorials/stateless-application/hello-minikube/){:target="_blank"} *(Runs on Mac only)*
* [Kubernetes 101](/docs/user-guide/walkthrough/){:target="_blank"}
* [Kubernetes 201](/docs/user-guide/walkthrough/k8s201/){:target="_blank"}
* [Kubernetes object management](/docs/tutorials/object-management-kubectl/object-management/){:target="_blank"}
### 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:
* [Intermediate App Developer](/docs/user-journeys/users/application-developer/intermediate/){:target="_blank"} - Dive deeper, with the next level of this journey.
* [Foundational Cluster Operator](/docs/user-journeys/users/cluster-operator/foundational/){:target="_blank"} - Build breadth, by exploring other journeys.
{% endcapture %}
{% include templates/user-journey-content.md %}
>>>>>>> merge master to 1.10, with fixes (#7682)
@@ -1,3 +1,4 @@
<<<<<<< HEAD
---
reviewers:
- chenopis
@@ -155,3 +156,163 @@ If you feel fairly comfortable with the topics on this page and want to learn mo
{% endcapture %}
{% include templates/user-journey-content.md %}
||||||| merged common ancestors
=======
---
reviewers:
- chenopis
layout: docsportal
css: /css/style_user_journeys.css, https://fonts.googleapis.com/icon?family=Material+Icons
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"
---
{% assign reference_docs_url = '/docs/reference/generated/kubernetes-api/' | append: site.latest %}
{% 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 [Beginner App Developer](/docs/user-journeys/users/application-developer/foundational/){:target="_blank"} topics first.
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
{% endcapture %}
{% 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. [Basic workload](/docs/user-journeys/users/application-developer/foundational/#section-2){:target="_blank"} 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.
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 [split-brain](https://en.wikipedia.org/wiki/Split-brain_(computing)){:target="_blank"} side effects in the case when a node becomes unreachable ([network partition](https://en.wikipedia.org/wiki/Network_partition){:target="_blank"}). 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 [service mesh](https://www.linux.com/news/whats-service-mesh-and-why-do-i-need-one){:target="_blank"}
#### 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. [Read more about Job patterns](/docs/concepts/workloads/controllers/jobs-run-to-completion/#job-patterns){:target="_blank"}.
* **{% 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 [a list of additional Kubernetes resource types](/docs/reference/kubectl/overview/#resource-types){:target="_blank"} as well as the [API reference docs]({{ reference_docs_url }}){:target="_blank"}.
There may be additional features not mentioned here that you may find useful, which are covered in the [full Kubernetes documentation](/docs/home/?path=browse){:target="_blank"}.
## Deploy a production-ready workload
The beginner tutorials on this site, such as the [Guestbook app](/docs/tutorials/stateless-application/guestbook/){:target="_blank"}, 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:
* [Purely imperative](/docs/tutorials/object-management-kubectl/imperative-object-management-command/){:target="_blank"}
* [Imperative with local configuration files](/docs/tutorials/object-management-kubectl/imperative-object-management-configuration/){:target="_blank"} (typically YAML)
* [Declarative with local configuration files](/docs/tutorials/object-management-kubectl/declarative-object-management-configuration/){:target="_blank"} (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 [this guide](/docs/concepts/configuration/overview/){:target="_blank"}.
#### 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:
* [Authentication](/docs/admin/authentication/){:target="_blank"} (Is the user who they say they are?)
* [Authorization](/docs/admin/authorization/){:target="_blank"} (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
* **[Resource quotas](/docs/concepts/policy/resource-quotas/){:target="_blank"}**, which affect what your team's workloads can use
* **[Memory](/docs/tasks/configure-pod-container/assign-memory-resource/){:target="_blank"} and [CPU](/docs/tasks/configure-pod-container/assign-cpu-resource/){:target="_blank"} requests**, for a given Pod or container
* **[Monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/){:target="_blank"}**, 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 [client-go](https://github.com/kubernetes/client-go/#client-go){:target="_blank"}, the Go library for the Kubernetes API.
To learn about the most commonly used kubectl commands, check out the [kubectl cheatsheet](/docs/reference/kubectl/cheatsheet/){:target="_blank"}. It explains topics such as the following:
* [kubeconfig files](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/){:target="_blank"} - Your kubeconfig file tells kubectl what cluster to talk to, and can reference multiple clusters (such as dev and prod).
* [The various output formats available](/docs/reference/kubectl/cheatsheet/#formatting-output){:target="_blank"} - This is useful to know when you are using `kubectl get` to list information about certain API objects.
* [The JSONPath output format](/docs/reference/kubectl/jsonpath/){:target="_blank"} - 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" %}).
* [`kubectl run` vs `kubectl apply`](/docs/reference/kubectl/conventions/){:target="_blank"} - 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 [the reference guide](/docs/reference/generated/kubectl/kubectl-commands){:target="_blank"}.
#### 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 [thriving ecosystem of tools](https://docs.google.com/a/heptio.com/spreadsheets/d/1FCgqz1Ci7_VCz_wdh8vBitZ3giBtac_H8SBw4uxnrsE/edit?usp=drive_web){:target="_blank"} 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:
* [Commonly used `kubectl` commands](/docs/reference/kubectl/cheatsheet/){:target="_blank"}
* [Kubernetes API reference]({{ reference_docs_url }}){:target="_blank"}
* [Standardized Glossary](/docs/reference/glossary/){:target="_blank"}
In addition, [the Kubernetes blog](http://blog.kubernetes.io/){:target="_blank"} 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:
* [Advanced App Developer](/docs/user-journeys/users/application-developer/advanced/){:target="_blank"} - Dive deeper, with the next level of this journey.
* [Foundational Cluster Operator](/docs/user-journeys/users/cluster-operator/foundational/){:target="_blank"} - Build breadth, by exploring other journeys.
{% endcapture %}
{% include templates/user-journey-content.md %}
>>>>>>> merge master to 1.10, with fixes (#7682)
@@ -1,3 +1,4 @@
<<<<<<< HEAD
---
reviewers:
- chenopis
@@ -82,3 +83,90 @@ Aenean suscipit arcu ac leo tincidunt tempus. Donec maximus tellus libero, ac ul
{% endcapture %}
{% include templates/user-journey-content.md %}
||||||| merged common ancestors
=======
---
reviewers:
- chenopis
layout: docsportal
css: /css/style_user_journeys.css, https://fonts.googleapis.com/icon?family=Material+Icons
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 > CLUSTER OPERATOR > ADVANCED"
---
{% capture overview %}
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean id felis non enim faucibus lacinia. Aliquam massa mauris, interdum a ex ut, sagittis rutrum nulla. In pellentesque est at molestie fringilla. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec eu mi at velit lacinia venenatis ac nec sem. In volutpat pellentesque dui ut commodo. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Duis sollicitudin eleifend felis non facilisis. Pellentesque leo urna, congue id auctor non, varius a nunc. Duis ultrices, odio ut hendrerit suscipit, nisi mauris dignissim mauris, nec bibendum ante neque ut augue. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nam condimentum libero sit amet rutrum fermentum. Proin posuere condimentum odio. Aenean volutpat, ex vel tincidunt tincidunt, massa odio condimentum lectus, vel iaculis libero dolor in nisi.
{% endcapture %}
<!--
Advanced
Federated clusters
Multi-cluster access
Custom controllers, custom resource definitions
Network-level service management (ISTIO)
-->
{% capture body %}
## Setup federated clusters
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean id felis non enim faucibus lacinia. Aliquam massa mauris, interdum a ex ut, sagittis rutrum nulla. In pellentesque est at molestie fringilla. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec eu mi at velit lacinia venenatis ac nec sem. In volutpat pellentesque dui ut commodo. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Duis sollicitudin eleifend felis non facilisis. Pellentesque leo urna, congue id auctor non, varius a nunc. Duis ultrices, odio ut hendrerit suscipit, nisi mauris dignissim mauris, nec bibendum ante neque ut augue. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nam condimentum libero sit amet rutrum fermentum. Proin posuere condimentum odio. Aenean volutpat, ex vel tincidunt tincidunt, massa odio condimentum lectus, vel iaculis libero dolor in nisi.
Curabitur bibendum tempor mi, vel lacinia nisi vulputate ac. Nulla dignissim consectetur nisl nec tincidunt. Etiam pharetra facilisis sapien, non gravida velit fermentum sed. Ut ac ultrices nunc, in vestibulum urna. Suspendisse accumsan euismod felis, sit amet rhoncus neque volutpat luctus. Aliquam tincidunt pellentesque mauris, sed tempus diam. Mauris in elit eget justo tempor suscipit.
Aenean suscipit arcu ac leo tincidunt tempus. Donec maximus tellus libero, ac ullamcorper magna lobortis ac. Integer mollis nisl vitae magna gravida, nec ornare ex consectetur. Sed mattis tincidunt nisi, at consequat tellus malesuada non. Integer vel semper nisi, ut fringilla velit. Nam felis ex, congue non dui vitae, sollicitudin convallis turpis. Phasellus porttitor maximus turpis, in varius nibh fermentum aliquam. Cras finibus lacus non diam porttitor porttitor. Nulla fringilla sagittis nibh nec condimentum. Duis egestas mauris nec dolor hendrerit ullamcorper sit amet in mi. Phasellus sollicitudin justo diam.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean id felis non enim faucibus lacinia. Aliquam massa mauris, interdum a ex ut, sagittis rutrum nulla. In pellentesque est at molestie fringilla. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec eu mi at velit lacinia venenatis ac nec sem. In volutpat pellentesque dui ut commodo. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Duis sollicitudin eleifend felis non facilisis. Pellentesque leo urna, congue id auctor non, varius a nunc. Duis ultrices, odio ut hendrerit suscipit, nisi mauris dignissim mauris, nec bibendum ante neque ut augue. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nam condimentum libero sit amet rutrum fermentum. Proin posuere condimentum odio. Aenean volutpat, ex vel tincidunt tincidunt, massa odio condimentum lectus, vel iaculis libero dolor in nisi.
Curabitur bibendum tempor mi, vel lacinia nisi vulputate ac. Nulla dignissim consectetur nisl nec tincidunt. Etiam pharetra facilisis sapien, non gravida velit fermentum sed. Ut ac ultrices nunc, in vestibulum urna. Suspendisse accumsan euismod felis, sit amet rhoncus neque volutpat luctus. Aliquam tincidunt pellentesque mauris, sed tempus diam. Mauris in elit eget justo tempor suscipit.
Aenean suscipit arcu ac leo tincidunt tempus. Donec maximus tellus libero, ac ullamcorper magna lobortis ac. Integer mollis nisl vitae magna gravida, nec ornare ex consectetur. Sed mattis tincidunt nisi, at consequat tellus malesuada non. Integer vel semper nisi, ut fringilla velit. Nam felis ex, congue non dui vitae, sollicitudin convallis turpis. Phasellus porttitor maximus turpis, in varius nibh fermentum aliquam. Cras finibus lacus non diam porttitor porttitor. Nulla fringilla sagittis nibh nec condimentum. Duis egestas mauris nec dolor hendrerit ullamcorper sit amet in mi. Phasellus sollicitudin justo diam.
## Deploy an application with advanced features
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean id felis non enim faucibus lacinia. Aliquam massa mauris, interdum a ex ut, sagittis rutrum nulla. In pellentesque est at molestie fringilla. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec eu mi at velit lacinia venenatis ac nec sem. In volutpat pellentesque dui ut commodo. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Duis sollicitudin eleifend felis non facilisis. Pellentesque leo urna, congue id auctor non, varius a nunc. Duis ultrices, odio ut hendrerit suscipit, nisi mauris dignissim mauris, nec bibendum ante neque ut augue. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nam condimentum libero sit amet rutrum fermentum. Proin posuere condimentum odio. Aenean volutpat, ex vel tincidunt tincidunt, massa odio condimentum lectus, vel iaculis libero dolor in nisi.
Curabitur bibendum tempor mi, vel lacinia nisi vulputate ac. Nulla dignissim consectetur nisl nec tincidunt. Etiam pharetra facilisis sapien, non gravida velit fermentum sed. Ut ac ultrices nunc, in vestibulum urna. Suspendisse accumsan euismod felis, sit amet rhoncus neque volutpat luctus. Aliquam tincidunt pellentesque mauris, sed tempus diam. Mauris in elit eget justo tempor suscipit.
Aenean suscipit arcu ac leo tincidunt tempus. Donec maximus tellus libero, ac ullamcorper magna lobortis ac. Integer mollis nisl vitae magna gravida, nec ornare ex consectetur. Sed mattis tincidunt nisi, at consequat tellus malesuada non. Integer vel semper nisi, ut fringilla velit. Nam felis ex, congue non dui vitae, sollicitudin convallis turpis. Phasellus porttitor maximus turpis, in varius nibh fermentum aliquam. Cras finibus lacus non diam porttitor porttitor. Nulla fringilla sagittis nibh nec condimentum. Duis egestas mauris nec dolor hendrerit ullamcorper sit amet in mi. Phasellus sollicitudin justo diam.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean id felis non enim faucibus lacinia. Aliquam massa mauris, interdum a ex ut, sagittis rutrum nulla. In pellentesque est at molestie fringilla. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec eu mi at velit lacinia venenatis ac nec sem. In volutpat pellentesque dui ut commodo. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Duis sollicitudin eleifend felis non facilisis. Pellentesque leo urna, congue id auctor non, varius a nunc. Duis ultrices, odio ut hendrerit suscipit, nisi mauris dignissim mauris, nec bibendum ante neque ut augue. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nam condimentum libero sit amet rutrum fermentum. Proin posuere condimentum odio. Aenean volutpat, ex vel tincidunt tincidunt, massa odio condimentum lectus, vel iaculis libero dolor in nisi.
Curabitur bibendum tempor mi, vel lacinia nisi vulputate ac. Nulla dignissim consectetur nisl nec tincidunt. Etiam pharetra facilisis sapien, non gravida velit fermentum sed. Ut ac ultrices nunc, in vestibulum urna. Suspendisse accumsan euismod felis, sit amet rhoncus neque volutpat luctus. Aliquam tincidunt pellentesque mauris, sed tempus diam. Mauris in elit eget justo tempor suscipit.
Aenean suscipit arcu ac leo tincidunt tempus. Donec maximus tellus libero, ac ullamcorper magna lobortis ac. Integer mollis nisl vitae magna gravida, nec ornare ex consectetur. Sed mattis tincidunt nisi, at consequat tellus malesuada non. Integer vel semper nisi, ut fringilla velit. Nam felis ex, congue non dui vitae, sollicitudin convallis turpis. Phasellus porttitor maximus turpis, in varius nibh fermentum aliquam. Cras finibus lacus non diam porttitor porttitor. Nulla fringilla sagittis nibh nec condimentum. Duis egestas mauris nec dolor hendrerit ullamcorper sit amet in mi. Phasellus sollicitudin justo diam.
## Explore advanced topics
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean id felis non enim faucibus lacinia. Aliquam massa mauris, interdum a ex ut, sagittis rutrum nulla. In pellentesque est at molestie fringilla. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec eu mi at velit lacinia venenatis ac nec sem. In volutpat pellentesque dui ut commodo. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Duis sollicitudin eleifend felis non facilisis. Pellentesque leo urna, congue id auctor non, varius a nunc. Duis ultrices, odio ut hendrerit suscipit, nisi mauris dignissim mauris, nec bibendum ante neque ut augue. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nam condimentum libero sit amet rutrum fermentum. Proin posuere condimentum odio. Aenean volutpat, ex vel tincidunt tincidunt, massa odio condimentum lectus, vel iaculis libero dolor in nisi.
Curabitur bibendum tempor mi, vel lacinia nisi vulputate ac. Nulla dignissim consectetur nisl nec tincidunt. Etiam pharetra facilisis sapien, non gravida velit fermentum sed. Ut ac ultrices nunc, in vestibulum urna. Suspendisse accumsan euismod felis, sit amet rhoncus neque volutpat luctus. Aliquam tincidunt pellentesque mauris, sed tempus diam. Mauris in elit eget justo tempor suscipit.
Aenean suscipit arcu ac leo tincidunt tempus. Donec maximus tellus libero, ac ullamcorper magna lobortis ac. Integer mollis nisl vitae magna gravida, nec ornare ex consectetur. Sed mattis tincidunt nisi, at consequat tellus malesuada non. Integer vel semper nisi, ut fringilla velit. Nam felis ex, congue non dui vitae, sollicitudin convallis turpis. Phasellus porttitor maximus turpis, in varius nibh fermentum aliquam. Cras finibus lacus non diam porttitor porttitor. Nulla fringilla sagittis nibh nec condimentum. Duis egestas mauris nec dolor hendrerit ullamcorper sit amet in mi. Phasellus sollicitudin justo diam.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean id felis non enim faucibus lacinia. Aliquam massa mauris, interdum a ex ut, sagittis rutrum nulla. In pellentesque est at molestie fringilla. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec eu mi at velit lacinia venenatis ac nec sem. In volutpat pellentesque dui ut commodo. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Duis sollicitudin eleifend felis non facilisis. Pellentesque leo urna, congue id auctor non, varius a nunc. Duis ultrices, odio ut hendrerit suscipit, nisi mauris dignissim mauris, nec bibendum ante neque ut augue. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nam condimentum libero sit amet rutrum fermentum. Proin posuere condimentum odio. Aenean volutpat, ex vel tincidunt tincidunt, massa odio condimentum lectus, vel iaculis libero dolor in nisi.
Curabitur bibendum tempor mi, vel lacinia nisi vulputate ac. Nulla dignissim consectetur nisl nec tincidunt. Etiam pharetra facilisis sapien, non gravida velit fermentum sed. Ut ac ultrices nunc, in vestibulum urna. Suspendisse accumsan euismod felis, sit amet rhoncus neque volutpat luctus. Aliquam tincidunt pellentesque mauris, sed tempus diam. Mauris in elit eget justo tempor suscipit.
Aenean suscipit arcu ac leo tincidunt tempus. Donec maximus tellus libero, ac ullamcorper magna lobortis ac. Integer mollis nisl vitae magna gravida, nec ornare ex consectetur. Sed mattis tincidunt nisi, at consequat tellus malesuada non. Integer vel semper nisi, ut fringilla velit. Nam felis ex, congue non dui vitae, sollicitudin convallis turpis. Phasellus porttitor maximus turpis, in varius nibh fermentum aliquam. Cras finibus lacus non diam porttitor porttitor. Nulla fringilla sagittis nibh nec condimentum. Duis egestas mauris nec dolor hendrerit ullamcorper sit amet in mi. Phasellus sollicitudin justo diam.
## Additional resources
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean id felis non enim faucibus lacinia. Aliquam massa mauris, interdum a ex ut, sagittis rutrum nulla. In pellentesque est at molestie fringilla. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec eu mi at velit lacinia venenatis ac nec sem. In volutpat pellentesque dui ut commodo. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Duis sollicitudin eleifend felis non facilisis. Pellentesque leo urna, congue id auctor non, varius a nunc. Duis ultrices, odio ut hendrerit suscipit, nisi mauris dignissim mauris, nec bibendum ante neque ut augue. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nam condimentum libero sit amet rutrum fermentum. Proin posuere condimentum odio. Aenean volutpat, ex vel tincidunt tincidunt, massa odio condimentum lectus, vel iaculis libero dolor in nisi.
Curabitur bibendum tempor mi, vel lacinia nisi vulputate ac. Nulla dignissim consectetur nisl nec tincidunt. Etiam pharetra facilisis sapien, non gravida velit fermentum sed. Ut ac ultrices nunc, in vestibulum urna. Suspendisse accumsan euismod felis, sit amet rhoncus neque volutpat luctus. Aliquam tincidunt pellentesque mauris, sed tempus diam. Mauris in elit eget justo tempor suscipit.
Aenean suscipit arcu ac leo tincidunt tempus. Donec maximus tellus libero, ac ullamcorper magna lobortis ac. Integer mollis nisl vitae magna gravida, nec ornare ex consectetur. Sed mattis tincidunt nisi, at consequat tellus malesuada non. Integer vel semper nisi, ut fringilla velit. Nam felis ex, congue non dui vitae, sollicitudin convallis turpis. Phasellus porttitor maximus turpis, in varius nibh fermentum aliquam. Cras finibus lacus non diam porttitor porttitor. Nulla fringilla sagittis nibh nec condimentum. Duis egestas mauris nec dolor hendrerit ullamcorper sit amet in mi. Phasellus sollicitudin justo diam.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean id felis non enim faucibus lacinia. Aliquam massa mauris, interdum a ex ut, sagittis rutrum nulla. In pellentesque est at molestie fringilla. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec eu mi at velit lacinia venenatis ac nec sem. In volutpat pellentesque dui ut commodo. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Duis sollicitudin eleifend felis non facilisis. Pellentesque leo urna, congue id auctor non, varius a nunc. Duis ultrices, odio ut hendrerit suscipit, nisi mauris dignissim mauris, nec bibendum ante neque ut augue. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nam condimentum libero sit amet rutrum fermentum. Proin posuere condimentum odio. Aenean volutpat, ex vel tincidunt tincidunt, massa odio condimentum lectus, vel iaculis libero dolor in nisi.
Curabitur bibendum tempor mi, vel lacinia nisi vulputate ac. Nulla dignissim consectetur nisl nec tincidunt. Etiam pharetra facilisis sapien, non gravida velit fermentum sed. Ut ac ultrices nunc, in vestibulum urna. Suspendisse accumsan euismod felis, sit amet rhoncus neque volutpat luctus. Aliquam tincidunt pellentesque mauris, sed tempus diam. Mauris in elit eget justo tempor suscipit.
Aenean suscipit arcu ac leo tincidunt tempus. Donec maximus tellus libero, ac ullamcorper magna lobortis ac. Integer mollis nisl vitae magna gravida, nec ornare ex consectetur. Sed mattis tincidunt nisi, at consequat tellus malesuada non. Integer vel semper nisi, ut fringilla velit. Nam felis ex, congue non dui vitae, sollicitudin convallis turpis. Phasellus porttitor maximus turpis, in varius nibh fermentum aliquam. Cras finibus lacus non diam porttitor porttitor. Nulla fringilla sagittis nibh nec condimentum. Duis egestas mauris nec dolor hendrerit ullamcorper sit amet in mi. Phasellus sollicitudin justo diam.
{% endcapture %}
{% include templates/user-journey-content.md %}
>>>>>>> merge master to 1.10, with fixes (#7682)
@@ -1,3 +1,4 @@
<<<<<<< HEAD
---
reviewers:
- chenopis
@@ -96,3 +97,104 @@ Some additional resources for getting information about your cluster and how it
{% endcapture %}
{% include templates/user-journey-content.md %}
||||||| merged common ancestors
=======
---
reviewers:
- chenopis
layout: docsportal
css: /css/style_user_journeys.css, https://fonts.googleapis.com/icon?family=Material+Icons
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"
---
{% 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.
{% endcapture %}
<!-- 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/).
## 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/)
* [Core metrics pipeline](/docs/tasks/debug-application-cluster/core-metrics-pipeline/)
* [Metrics](/docs/concepts/cluster-administration/controller-metrics/)
## Explore additional resources
### Tutorials
* [Kubernetes Basics](/docs/tutorials/kubernetes-basics/)
* [Kubernetes 101](/docs/user-guide/walkthrough/) - kubectl command line interface and Pods
* [Kubernetes 201](/docs/user-guide/walkthrough/k8s201/) - labels, deployments, services, and health checking
* [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/)
{% endcapture %}
{% include templates/user-journey-content.md %}
>>>>>>> merge master to 1.10, with fixes (#7682)
@@ -1,3 +1,4 @@
<<<<<<< HEAD
---
reviewers:
- chenopis
@@ -106,3 +107,114 @@ Cluster Administration:
{% endcapture %}
{% include templates/user-journey-content.md %}
||||||| merged common ancestors
=======
---
reviewers:
- chenopis
layout: docsportal
css: /css/style_user_journeys.css, https://fonts.googleapis.com/icon?family=Material+Icons
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"
---
{% 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.
{% endcapture %}
{% 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/admin/accessing-the-api/)
* [Authenticating](/docs/admin/authentication/)
* [Using Admission Controllers](/docs/admin/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/admin/authorization/)
* [Using RBAC Authorization](/docs/admin/authorization/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 [core metrics pipeline](/docs/tasks/debug-application-cluster/core-metrics-pipeline/) which can be used by Horizontal Pod Autoscaler with custom metrics.
[Prometheus](https://prometheus.io/), which is another 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.9, the [sig-instrumentation](https://github.com/kubernetes/community/tree/master/sig-instrumentation) team is shifting away from an all-inclusive monitoring pattern with heapster, described in [Prometheus vs. Heapster vs. Kubernetes Metrics APIs](https://brancz.com/2018/01/05/prometheus-vs-heapster-vs-kubernetes-metrics-apis/).
Hosted data analytics services such as [Datadog](https://docs.datadoghq.com/integrations/kubernetes/) 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)
{% endcapture %}
{% include templates/user-journey-content.md %}
>>>>>>> merge master to 1.10, with fixes (#7682)