diff --git a/.gitmodules b/.gitmodules new file mode 100644 index 0000000000..b76244d3b5 --- /dev/null +++ b/.gitmodules @@ -0,0 +1,3 @@ +[submodule "themes/docsy"] + path = themes/docsy + url = https://github.com/google/docsy.git diff --git a/Makefile b/Makefile index c7756208cc..be53b5eac9 100644 --- a/Makefile +++ b/Makefile @@ -1,9 +1,16 @@ -DOCKER = docker -HUGO_VERSION = $(shell grep ^HUGO_VERSION netlify.toml | tail -n 1 | cut -d '=' -f 2 | tr -d " \"\n") -DOCKER_IMAGE = kubernetes-hugo -DOCKER_RUN = $(DOCKER) run --rm --interactive --tty --volume $(CURDIR):/src -NODE_BIN = node_modules/.bin -NETLIFY_FUNC = $(NODE_BIN)/netlify-lambda +HUGO_VERSION = $(shell grep ^HUGO_VERSION netlify.toml | tail -n 1 | cut -d '=' -f 2 | tr -d " \"\n") +NODE_BIN = node_modules/.bin +NETLIFY_FUNC = $(NODE_BIN)/netlify-lambda + +# The CONTAINER_ENGINE variable is used for specifying the container engine. By default 'docker' is used +# but this can be overridden when calling make, e.g. +# CONTAINER_ENGINE=podman make container-image +CONTAINER_ENGINE ?= docker +CONTAINER_IMAGE = kubernetes-hugo +CONTAINER_RUN = $(CONTAINER_ENGINE) run --rm --interactive --tty --volume $(CURDIR):/src + +CCRED=\033[0;31m +CCEND=\033[0m .PHONY: all build build-preview help serve @@ -36,16 +43,28 @@ serve: ## Boot the development server. hugo server --buildFuture docker-image: - $(DOCKER) build . \ - --network=host \ - --tag $(DOCKER_IMAGE) \ - --build-arg HUGO_VERSION=$(HUGO_VERSION) + @echo -e "$(CCRED)**** The use of docker-image is deprecated. Use container-image instead. ****$(CCEND)" + $(MAKE) container-image docker-build: - $(DOCKER_RUN) $(DOCKER_IMAGE) hugo + @echo -e "$(CCRED)**** The use of docker-build is deprecated. Use container-build instead. ****$(CCEND)" + $(MAKE) container-build docker-serve: - $(DOCKER_RUN) --mount type=tmpfs,destination=/src/resources,tmpfs-mode=0755 -p 1313:1313 $(DOCKER_IMAGE) hugo server --buildFuture --bind 0.0.0.0 + @echo -e "$(CCRED)**** The use of docker-serve is deprecated. Use container-serve instead. ****$(CCEND)" + $(MAKE) container-serve + +container-image: + $(CONTAINER_ENGINE) build . \ + --network=host \ + --tag $(CONTAINER_IMAGE) \ + --build-arg HUGO_VERSION=$(HUGO_VERSION) + +container-build: + $(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo + +container-serve: + $(CONTAINER_RUN) --mount type=tmpfs,destination=/src/resources,tmpfs-mode=0755 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --bind 0.0.0.0 test-examples: scripts/test_examples.sh install @@ -53,8 +72,13 @@ test-examples: .PHONY: link-checker-setup link-checker-image-pull: - docker pull wjdp/htmltest + $(CONTAINER_ENGINE) pull wjdp/htmltest + +docker-internal-linkcheck: + @echo -e "$(CCRED)**** The use of docker-internal-linkcheck is deprecated. Use container-internal-linkcheck instead. ****$(CCEND)" + $(MAKE) container-internal-linkcheck + +container-internal-linkcheck: link-checker-image-pull + $(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo --config config.toml,linkcheck-config.toml --buildFuture + $(CONTAINER_ENGINE) run --mount type=bind,source=$(CURDIR),target=/test --rm wjdp/htmltest htmltest -docker-internal-linkcheck: link-checker-image-pull - $(DOCKER_RUN) $(DOCKER_IMAGE) hugo --config config.toml,linkcheck-config.toml --buildFuture - $(DOCKER) run --mount type=bind,source=$(CURDIR),target=/test --rm wjdp/htmltest htmltest \ No newline at end of file diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index 0de965afdc..c2b0751dbe 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -124,6 +124,7 @@ aliases: - girikuncoro - irvifa - wahyuoi + - phanama sig-docs-it-owners: # Admins for Italian content - fabriziopandini - mattiaperi @@ -133,15 +134,15 @@ aliases: - mattiaperi - micheleberardi sig-docs-ja-owners: # Admins for Japanese content - - cstoku + # cstoku - inductor - nasa9084 sig-docs-ja-reviews: # PR reviews for Japanese content - bells17 - - cstoku + # cstoku - inductor - makocchi-git - - MasayaAoyama + # MasayaAoyama - nasa9084 - oke-py sig-docs-ko-owners: # Admins for Korean content @@ -228,6 +229,7 @@ aliases: - MaxymVlasov sig-docs-uk-reviews: # PR reviews for Ukrainian content - anastyakulyk + - Arhell - butuzov - idvoretskyi - MaxymVlasov diff --git a/README.md b/README.md index d3ee35693b..7ef8f8d2dd 100644 --- a/README.md +++ b/README.md @@ -13,6 +13,7 @@ To run the website locally when you have Hugo installed: ```bash git clone https://github.com/kubernetes/website.git cd website +git submodule update --init --recursive hugo server --buildFuture ``` diff --git a/assets/images/nav_logo.svg b/assets/images/nav_logo.svg new file mode 100644 index 0000000000..982c04f4aa --- /dev/null +++ b/assets/images/nav_logo.svg @@ -0,0 +1,110 @@ + + + + +Kubernetes_Logo_Hrz_lockup_REV + + + + + + + + + + + + + + + + + + + + + + diff --git a/assets/images/nav_logo2.svg b/assets/images/nav_logo2.svg new file mode 100644 index 0000000000..92b8d19ac4 --- /dev/null +++ b/assets/images/nav_logo2.svg @@ -0,0 +1,108 @@ + + + + +Kubernetes_Logo_Hrz_lockup_POS + + + + + + + + + + + + + + + + + + + + + diff --git a/assets/js/search.js b/assets/js/search.js new file mode 100644 index 0000000000..3d6e9d9447 --- /dev/null +++ b/assets/js/search.js @@ -0,0 +1,36 @@ +/* +Copyright 2018 Google LLC +Licensed under the Apache License, Version 2.0 (the "License"); +you may not use this file except in compliance with the License. +You may obtain a copy of the License at + https://www.apache.org/licenses/LICENSE-2.0 +Unless required by applicable law or agreed to in writing, software +distributed under the License is distributed on an "AS IS" BASIS, +WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +See the License for the specific language governing permissions and +limitations under the License. +*/ + +(function ($) { + "use strict"; + + var Search = { + init: function () { + $(document).ready(function () { + $(document).on("keypress", ".td-search-input", function (e) { + if (e.keyCode !== 13) { + return; + } + + var query = $(this).val(); + var searchPage = "{{ "docs/search/" | absURL }}?q=" + query; + document.location = searchPage; + + return false; + }); + }); + }, + }; + + Search.init(); +})(jQuery); diff --git a/assets/scss/_base.scss b/assets/scss/_base.scss new file mode 100644 index 0000000000..ddfee42444 --- /dev/null +++ b/assets/scss/_base.scss @@ -0,0 +1,834 @@ +@import "reset"; + +// header +$full-width-paddingX: 20px; + +$main-width: 100%; +$main-max-width: 100%; + +$header-height: 80px; + +$logo-width: 180px; + +$nav-buttons-margin-left: 30px; + +$hamburger-size: 50px; + +// main nav +$main-nav-padding: 140px 0 30px; +$main-nav-h5-margin-bottom: 1em; +$main-nav-h3-margin-bottom: 0.6em; +$nav-box-width: 20%; +$nav-box-sibling-margin-left: calc(20% / 3); +$main-nav-main-sibling-margin-top: 60px; +$main-nav-left-button-size: 50px; +$main-nav-left-button-font-size: 18px; + +// hero +$hero-padding-top: 80px; +$headline-wrapper-margin-bottom: 40px; +$quickstart-button-padding: 0 50px; +$vendor-strip-height: 88px; +$vendor-strip-font-size: 16px; + +// video +$video-section-height: 200px; + +@import "size"; + +//////////////////////////////////////////////////////////////////////////////////////////////////// +//////////////////////////////////////////////////////////////////////////////////////////////////// +//////////////////////////////////////////////////////////////////////////////////////////////////// + +body { + background-color: white; +} + +section { + position: relative; + background-color: white; +} + +section, +header, +footer { + .main-section { + position: relative; + margin: auto; + } + + p { + font-size: 14px; + font-weight: 400; + } + + .button { + display: inline-block; + border-radius: 6px; + padding: 0 20px; + line-height: 40px; + color: white; + background-color: $blue; + text-decoration: none; + font-size: 1rem; + } + + #cellophane { + position: fixed; + top: 0; + left: 0; + width: 100%; + height: 100%; + display: none; + } +} + +// HEADER + +#hamburger { + display: inline-block; + position: relative; + margin-left: auto; + vertical-align: middle; + padding: 0; + border: 0; + background: none; + + div, + &:before, + &:after { + position: absolute; + left: 15%; + width: 70%; + height: 2px; + background-color: $blue; + transition: 0.3s; + content: ""; + } + + div { + top: calc(50% - 1px); + } + + &:before { + top: 24%; + } + + &:after { + bottom: 24%; + } + + &:hover { + div, + &:before, + &:after { + background-color: white; + } + } +} + +// HERO +.header-hero { + background-image: url(/images/texture.png); + background-color: $dark-grey; + text-align: center; + padding-left: 0; + padding-right: 0; + margin-bottom: 0; + position: relative; + + &.bot-bar:after { + display: block; + margin-bottom: -24px; + height: 8px; + width: 100%; + background-color: transparentize(white, 0.9); + content: ""; + } + + &.no-sub { + h5 { + display: none; + } + + h1 { + margin-bottom: 20px; + } + } +} + +.td-home .header-hero:after { + display: none; +} + +.header-hero { + background-color: $dark-grey; + + h5 { + margin: 20px 0; + line-height: 28px; + } +} + +#vendorStrip { + position: relative; + + ul { + float: left; + } + + li { + display: inline-block; + height: 100%; + } + + a { + display: block; + height: 100%; + color: white; + font-size: 0.75em; + font-weight: bold; + } + + li + li { + margin-left: 0; + } +} + +.pi-accordion { + & > .container:first-child > .item:first-child > .title:first-child { + padding-left: 0; + font-size: 1.5em; + font-weight: 700; + } + + & > .container:first-child > .item.yah:first-child > .title:first-child { + margin-left: -20px !important; + } + + .item { + overflow: hidden; + } + + .title { + color: $dark-grey; + position: relative; + padding: 7.5px 10px 7.5px 18px; + cursor: pointer; + transition: 0.3s; + + &:hover { + color: $blue; + } + } + + a.item > .title { + color: black; + + &:hover { + color: $blue; + } + } + + div.item > .title { + &:before { + content: ""; + position: absolute; + top: 12px; + left: 2px; + border-style: solid; + border-width: 5px 0 5px 8px; + border-color: transparent transparent transparent $blue; + transform: rotate(0deg); + transition: 0.3s; + } + } + + .wrapper { + position: relative; + width: 100%; + transition: height 0.3s; + } + + .content { + padding-left: 20px; + opacity: 0; + transition: 0.3s; + } + + .item.on { + & > .title:before { + transform: rotate(90deg); + } + + & > .wrapper > .content { + opacity: 1; + } + } +} + +dt { + margin-bottom: 8px; +} + +dd { + margin-bottom: 16px; +} + +.pi-pushmenu { + display: none; + position: fixed; + top: 0; + width: 100%; + height: 100%; + opacity: 0; + transition: opacity 0.3s; + + &.on { + opacity: 1; + } + + .overlay { + position: fixed; + top: 0; + left: 0; + width: 100%; + height: 100%; + background-color: rgba(0, 0, 0, 0.4); + } + + .sled { + position: absolute; + top: 0; + width: 0; + height: 100%; + background-color: white; + overflow: auto; + transition: 0.3s; + } + + &.on .sled { + width: 400px; + max-width: 100vw; + } + + .top-bar { + height: 0; + line-height: 60px; + background-color: #444; + } + + ul { + margin-top: 25px; + } + + li { + position: relative; + display: block; + width: 100%; + min-height: 45px; + padding: 0 60px 0 20px; + border-bottom: 1px solid #cccccc; + } + + a { + display: inline-block; + width: 100%; + height: 45px; + line-height: 45px; + font-family: "Roboto", sans-serif; + font-size: 20px; + color: $blue; + } + + .button { + background: none; + padding: 0; + } + + ul ul { + padding: 0 20px; + + li { + min-height: 40px; + } + + a { + height: 40px; + line-height: 40px; + font-size: 18px; + color: lighten(#222222, 20%); + } + } +} + +.push-menu-close-button { + position: absolute; + top: 0; + right: 0; + width: 50px; + height: 50px; + + &:before, + &:after { + content: ""; + position: absolute; + top: calc(50% - 1px); + left: 25%; + width: 50%; + height: 2px; + background-color: black; + } + + &:before { + transform: rotate(45deg); + } + + &:after { + transform: rotate(-45deg); + } +} + +// ocean nodes +$ocean-nodes-padding-Y: 60px; +$ocean-nodes-main-margin-bottom: 60px; +$ocean-nodes-h3-margin-bottom: 30px; + +// video +$video-section-height: 200px; + +// features +$features-h3-margin-bottom: 20px; +$feature-box-div-width: 100%; +$feature-box-margin-bottom: 0; +$feature-box-div-margin-bottom: 40px; + +// Home-specific + +.td-home { + &.flip-nav, + &.open-nav { + .logo { + background-image: url(/images/nav_logo2.svg); + } + } +} + +.header-hero { + margin-bottom: 0; + padding-bottom: 1px; + + .main-section { + padding: 0 10px; + margin-bottom: 30px; + } + + #vendorStrip { + display: none; + } +} + +// Add logo to CNCF section +section#cncf { + padding-top: 60px; + padding-bottom: 140px; + background-image: url(/images/cncf-color.svg); + background-position: center 100px; + background-repeat: no-repeat; + background-size: 300px; +} + +// OCEAN NODES +#oceanNodes { + padding-top: $ocean-nodes-padding-Y; + padding-bottom: $ocean-nodes-padding-Y; + + a { + color: $blue; + } + + .main-section { + margin-bottom: $ocean-nodes-padding-Y; + min-height: 160px; + } + + .image-wrapper { + max-width: 75%; + margin: 0 auto 20px; + text-align: center; + + img { + width: 100%; + max-width: 160px; + } + } + + .main-section:first-child { + .image-wrapper { + max-width: 100%; + + img { + max-width: 491px; + } + } + } + + h3 { + margin-bottom: $ocean-nodes-h3-margin-bottom; + } +} + +// Video thingy +#video { + height: $video-section-height; +} + +#video { + width: 100%; + position: relative; + background-position: center center; + background-size: cover; + + & > .light-text { + display: none; + // position: absolute; + // top: 50%; + // left: 75%; + width: 500px; + padding-top: 2rem; + // transform: translate(-50%, -50%); + color: white; + } + + h2 { + font-size: 32px; + line-height: 44px; + margin-bottom: 20px; + } + + p { + margin-bottom: 20px; + } + + #desktopKCButton { + position: relative; + font-size: 18px; + background-color: $dark-grey; + border-radius: 8px; + color: $white; + padding: 20px 10px 20px 10px; + } + + #desktopShowVideoButton { + position: relative; + font-size: 24px; + background-color: white; + border-radius: 8px; + color: $blue; + padding: 15px 30px 15px 80px; + margin-bottom: 15px; + + &:before { + content: ""; + position: absolute; + @include pureCenter(40px); + width: 0; + height: 0; + border-style: solid; + border-width: 10px 0 10px 20px; + border-color: transparent transparent transparent $blue; + } + } + + #mobileShowVideoButton { + @include pureCenter; + width: 80px; + height: 80px; + border-radius: 50%; + background-color: transparent; + border: 5px solid rgba(255, 255, 255, 0.2); + overflow: visible; + + &:after { + @include pureCenter; + left: 40px; + content: ""; + width: 0; + height: 0; + border-style: solid; + border-width: 20px 0 20px 30px; + border-color: transparent transparent transparent #ffffff; + } + } +} + +#videoPlayer { + @include fullScreen; + background-color: rgba(0, 0, 0, 0.9); + display: none; + + iframe { + @include pureCenter; + @include maintain-aspect-ratio; + } + + #closeButton { + position: absolute; + top: 20px; + right: 20px; + width: 50px; + height: 50px; + border: 2px solid transparent; + transition: 0.3s; + + &:before, + &:after { + content: ""; + position: absolute; + top: calc(50% - 1px); + left: 10%; + width: 80%; + height: 2px; + background-color: white; + } + + &:before { + transform: rotate(45deg); + } + + &:after { + transform: rotate(-45deg); + } + + &:hover { + border-color: white; + } + } +} + +// KubeWeekly +#kubeweekly { + background-color: $light-grey; + padding-top: 30px; + padding-bottom: 80px; + background-size: auto; + // font-family: "Roboto Mono", monospace !important; + font-size: 24px; + // font-weight: bold; + + h5 { + font-size: 20px; + } +} + +.subscribe-button { + border-radius: 6px; + padding: 0 20px; + line-height: 31px; + color: white; + background-color: blue; + text-decoration: none; + font-size: 14px; +} + +// Features +#features { + padding-top: 140px; + background-color: $light-grey; + background-image: url(/images/wheel.svg); + background-position: center 60px; + background-repeat: no-repeat; + background-size: 60px; +} + +.feature-box { + //padding: 50px 0 + width: 100%; + overflow: hidden; + clear: both; + + h4 { + line-height: normal; + margin-bottom: 15px; + } + + & > div:first-child { + float: left; + } + + & > div:last-child { + float: right; + } +} + +#features { + h3 { + margin-bottom: $features-h3-margin-bottom; + } + + .feature-box { + margin-bottom: $feature-box-margin-bottom; + + & > div { + width: $feature-box-div-width; + margin-bottom: $feature-box-div-margin-bottom; + } + } +} + +// Talk to us +#talkToUs { + h3, + h4 { + text-align: center; + } + + h3 { + margin-bottom: 15px; + } + + h4 { + line-height: normal; + margin-bottom: 50px; + + br { + display: none; + } + } + + #bigSocial { + overflow: hidden; + + div { + width: 100%; + float: left; + padding: 30px; + padding-top: 110px; + background-position: center top; + background-size: auto; + background-repeat: no-repeat; + } + + div:nth-child(1) { + background-image: url(/images/twitter_icon.png); + } + + div:nth-child(2) { + background-image: url(/images/github_icon.png); + } + + div:nth-child(3) { + background-image: url(/images/slack_icon.png); + } + + div:nth-child(4) { + background-image: url(/images/stackoverflow_icon.png); + } + + div + div { + margin-top: 20px; + margin-left: 0; + } + + a { + display: inline-block; + color: $blue; + font-size: 24px; + font-weight: 400; + text-decoration: none; + margin-bottom: 15px; + } + + a, + p { + text-align: center; + width: 100%; + } + } +} + +.td-home { + #talkToUs { + .main-section { + padding: 30px 0; + } + + h5 { + font-size: 20px; + } + } + + #caseStudiesWrapper { + position: relative; + text-align: center; + margin-bottom: 30px; + + img { + padding-bottom: 1rem; + } + + div { + position: relative; + display: inline-block; + vertical-align: top; + width: 100%; + min-height: 230px; + margin-bottom: 60px; + padding-right: 1rem; + background-position: top center; + } + + p { + font-size: 20px; + } + + a { + position: absolute; + bottom: -30px; + left: 50%; + transform: translateX(-50%); + color: $blue; + font-weight: 400; + } + } +} + +// Docs specific + +#editPageButton { + position: absolute; + top: 50px; + right: 25px; + width: 50px; + height: 50px; + line-height: 50px; + border-radius: 50%; + white-space: nowrap; + text-indent: 50px; + overflow: hidden; + background: $blue url(/images/icon-pencil.svg) no-repeat; + background-position: 12px 10px; + background-size: 29px 29px; +} + +.feedback--response__hidden { + display: none; +} + +// GitHub info/edit buttons +#pre-footer { + margin-top: 2rem; + + .button { + font-size: 1.1rem; + + &:first-of-type { + margin-right: 0.75rem; + } + } + + .lastedit { + margin-top: 1rem; + font-size: 1rem; + } +} diff --git a/assets/scss/_case-studies.scss b/assets/scss/_case-studies.scss new file mode 100644 index 0000000000..d61d24189c --- /dev/null +++ b/assets/scss/_case-studies.scss @@ -0,0 +1,142 @@ +// SASS for Case Studies pages go here: + +hr { + background-color: #999999; +} + +h2 { + margin-bottom: 15px !important; +} + +.subhead { + padding-bottom: 2% !important; + padding-top: 0% !important; +} + +.details { + margin-left: 1.9%; + padding-right: 5%; + font-size: 16px !important; + padding-bottom: 2% !important; +} + +.section1 { + margin-bottom: 3%; + + .cols { + width: 80% !important; + margin-left: 6.8%; + padding-top: 1.5%; + + .col1 { + width: 52% !important; + font-weight: 300 !important; + } + + .col2 { + width: 46% !important; + } + } +} + +.banner2text { + width: 63%; + padding-top: 10%; + padding-left: 0% !important; + float: initial !important; + text-align: center; + margin: 0 auto; + position: relative; +} + +.banner3text, +.banner4text, +.banner5text { + width: 63%; + padding-left: 0% !important; + float: initial !important; + text-align: center; + margin: 0 auto; + position: relative; +} + +.fullcol { + float: initial !important; +} + +body footer { + background-color: #585858 !important; +} + +.section1 { + float: left !important; +} + +.banner1 { + padding-left: 11.9% !important; +} + +.banner2 { + float: initial !important; + padding-bottom: 2% !important; +} + +footer { + padding: 0% 7%; +} + +.banner4, +.banner3, +.banner5 { + float: initial !important; +} + +@media screen and (max-width: 910px) { + .banner2text { + width: 47%; + padding-top: 45%; + } + + .details { + margin-left: 0%; + margin-bottom: 3%; + } + + .subhead { + padding-bottom: 0% !important; + padding-top: 0% !important; + } + + .banner3 { + width: 100% !important; + } +} + +@media screen and (max-width: 780px) { + .section1 .cols { + width: 100% !important; + margin-left: 0%; + padding-top: 5%; + + .col1, + .col2 { + width: 100% !important; + margin-left: 0% !important; + + .fullcol { + width: 90% !important; + margin-left: 5% !important; + + .banner1 { + padding-left: 10% !important; + margin-bottom: 6% !important; + + .banner2text { + padding-top: 60% !important; + padding-bottom: 2% !important; + } + } + } + } + } +} diff --git a/assets/scss/_custom.scss b/assets/scss/_custom.scss new file mode 100644 index 0000000000..52364b0a8a --- /dev/null +++ b/assets/scss/_custom.scss @@ -0,0 +1,386 @@ +/* GLOBAL */ +.td-main { + .row { + margin: 0; + } + + main { + img { + max-width: 100%; + } + + table { + margin-bottom: 1rem; + display: initial; + } + + @media only screen and (min-width: 768px) { + padding-top: 2rem !important; + } + } +} + +section { + .main-section { + @media only screen and (min-width: 1024px) { + max-width: 1200px; + } + } +} + +.td-outer { + padding: 0 !important; +} + +#desktopShowVideoButton { + border: none +} + +#videoPlayer { + #closeButton { + background: transparent; + } +} + +/* HEADER */ + +.td-navbar { + position: fixed !important; + width: 100%; + padding-bottom: 1rem !important; + background: transparent !important; + transition: 0.3s; + + .navbar-brand { + position: absolute; + width: 45px; + height: 44px; + background-repeat: no-repeat; + background-size: contain; + background-image: url("/images/favicon.png"); + } + + #hamburger { + &:focus { + outline: none; + } + } + + @media only screen and (min-width: 768px) { + .navbar-brand { + background-image: url("/images/nav_logo.svg"); + top: 1.5rem; + width: 180px; + margin-left: 1rem; + } + } +} + +.td-navbar-nav-scroll { + overflow: visible !important; + display: none; + + .navbar-nav { + overflow: visible !important; + position: relative; + display: flex; + flex-direction: row; + flex-wrap: wrap; + justify-content: space-evenly; + + .nav-item { + position: relative; + height: 10%; + + .active::after { + position: absolute; + width: 100%; + height: 2px; + content: ""; + bottom: -4px; + left: 0; + background: #fff; + } + + .dropdown-menu { + left: -80px; + } + + &.dropdown:hover { + color: $medium-grey; + } + } + } + + @media only screen and (min-width: 768px) { + display: block; + margin-top: 3.5rem !important; + } + + @media only screen and (min-width: 1075px) { + margin-top: 1.5rem !important; + } +} + +// Flip-Nav +.flip-nav .td-navbar { + background-color: white !important; + box-shadow: 0 1px 2px $medium-grey; + + .navbar-nav { + .nav-item { + &.show .nav-link, + .nav-link { + color: $dark-grey; + + &:hover { + color: $medium-grey; + } + } + + .dropdown { + &:hover { + color: $medium-grey; + } + } + } + } + + .navbar-nav .nav-item .active { + color: $dark-grey; + + &::after { + background: $dark-grey; + } + } + + #hamburger:hover { + div, + &:before, + &:after { + background-color: $dark-grey; + } + } + + @media only screen and (min-width: 768px) { + .navbar-brand { + background-image: url("/images/nav_logo2.svg"); + } + } +} + +/* FOOTER */ +footer { + background-color: #303030; + background-image: url("/images/texture.png"); + padding: 1rem !important; + min-height: initial !important; + + .footer__links { + width: 100%; + margin: auto; + padding-bottom: 1rem; + + nav a { + display: block; + text-align: center; + } + + @media only screen and (min-width: 768px) { + nav { + display: flex; + flex-direction: row; + justify-content: space-around; + } + } + } + + small { + color: $light-grey; + font-size: 0.64rem; + + a { + text-decoration: inherit; + color: inherit; + + &:hover { + color: inherit; + } + } + } +} + +/* SIDE-DRAWER MENU */ + +.pi-pushmenu .sled { + .content ul { + padding: 0; + + li { + &:first-child { + display: none; + } + + a.nav-link { + padding: 0; + } + } + } + .push-menu-close-button { + background: transparent; + border: none; + + &:focus { + outline: none; + } + } +} + +/* DOCS */ + +.launch-cards { + button { + cursor: pointer; + box-sizing: border-box; + background: none; + margin: 0; + border: 0; + } + + ul, + li { + list-style: none; + padding-left: 0; + } +} + +// table of contents +.td-toc { + padding-top: 1.5rem !important; + top: 5rem !important; + + #TableOfContents { + padding-top: 1rem; + } +} + +// blockquotes and callouts + +blockquote { + padding: 0.4rem 0.4rem 0.4rem 1rem !important; +} + +// callouts are contained in static CSS as well. these require override. + +.caution { + border-left-color: #f0ad4e !important; +} + +.note { + border-left-color: #428bca !important; +} + +.warning { + border-left-color: #d9534f !important; +} + +// search & sidebar +.td-sidebar { + @media only screen and (min-width: 768px) { + padding-top: 1.5rem !important; + + .td-sidebar__inner { + top: 8.5rem; + + @media only screen and (min-width: 1075px) { + top: 6.5rem; + } + } + } +} + +.td-sidebar__inner { + form.td-sidebar__search { + + button.td-sidebar__toggle { + &:hover { + color: $white; + } + + color: $blue; + } + } +} + +.no-underline { + text-decoration: none !important; +} + +.hide { + display: none !important; +} + +.td-sidebar-link__page { + &#m-docs-search { + display: none; + } + + &#m-docs-test { + display: none; + } +} + +//Tutorials +main.content { + position: inherit; +} + +/* BLOG */ + +.td-blog { + + .td-sidebar-nav { + max-height: calc(100vh - 8rem); + } + + .widget-link { + margin-bottom: 1rem; + + .svg-inline--fa { + width: 25px; + } + + span { + margin-left: 0.5rem; + } + } +} + +/* COMMUNITY */ + +.newcommunitywrapper { + .news { + margin-left: 0; + + @media screen and (min-width: 768px) { + margin-left: 10%; + } + } +} + +/* CASE-STUDIES */ + +// Many of the case studies have small variations in markup and styles; +// some issues cannot be addressed due to inlined !important rules. +#caseStudies { + section .cols { + margin-left: 11%; + + div { + width: initial !important; + h2 { + margin-top: 1rem; + } + } + } +} diff --git a/assets/scss/_desktop.scss b/assets/scss/_desktop.scss new file mode 100644 index 0000000000..abff764d2f --- /dev/null +++ b/assets/scss/_desktop.scss @@ -0,0 +1,99 @@ +$main-max-width: 1200px; +$vendor-strip-height: 44px; +$video-section-height: 550px; + +@media screen and (min-width: 1024px) { + + .td-home { + .header-hero { + #vendorStrip { + display: block; + } + } + } + + .td-home { + + section, + header, + footer { + .main-section { + max-width: 1000px; + } + } + } + + #oceanNodes { + .main-section { + position: relative; + + &:nth-child(1) { + max-width: 1000px; + padding-right: 475px; + + h3, + p { + text-align: left + } + + .image-wrapper { + position: absolute; + max-width: 48%; + transform: translateY(-50%); + } + + img { + width: 425px; + } + } + } + } + + #video { + height: $video-section-height; + position: relative; + background-position: center center; + background-size: cover; + + &>.light-text { + margin-right: 10%; + } + } + + + + #talkToUs { + h4 { + br { + display: block; + } + } + + #bigSocial { + div { + width: calc(25% - 18px); + } + + div+div { + margin-left: 20px; + } + } + + .td-home #bigSocial { + div { + width: calc(33% - 15px); + } + + div:nth-child(3) { + margin-top: inherit; + } + } + } + + .td-home #caseStudiesWrapper { + div { + width: 24%; + min-height: 260px; + } + } +} \ No newline at end of file diff --git a/assets/scss/_reset.scss b/assets/scss/_reset.scss new file mode 100755 index 0000000000..7e3c0bbd3a --- /dev/null +++ b/assets/scss/_reset.scss @@ -0,0 +1,49 @@ +// CONVENIENCE +.clear { + display: block; + clear: both; +} + +.light-text { + color: white; +} + +.right { + float: right; +} + +.left { + float: left; +} + +.center { + text-align: center; +} + +//mixins +@mixin fullScreen { + position: fixed; + top: 0; + left: 0; + width: 100vw; + height: 100vh; +} + +@mixin pureCenter($left: 50%, $top: 50%) { + position: absolute; + top: $top; + left: $left; + transform: translate(-50%, -50%); +} + +@mixin maintain-aspect-ratio( + $width-factor: 16, + $height-factor: 9, + $target-width: 80vw, + $target-height: 80vh +) { + width: $target-width; + height: $target-width * ($height-factor / $width-factor); + max-width: $target-height * ($width-factor / $height-factor); + max-height: $target-height; +} diff --git a/assets/scss/_size.scss b/assets/scss/_size.scss new file mode 100644 index 0000000000..9f0b7f655f --- /dev/null +++ b/assets/scss/_size.scss @@ -0,0 +1,20 @@ +section, +#vendorStrip { + padding-left: $full-width-paddingX; + padding-right: $full-width-paddingX; +} + +#hamburger { + width: $hamburger-size; + height: $hamburger-size; +} + +.header-hero { + padding-top: $hero-padding-top; +} + +#vendorStrip { + height: $vendor-strip-height; + line-height: $vendor-strip-height; + font-size: $vendor-strip-font-size; +} diff --git a/assets/scss/_skin.scss b/assets/scss/_skin.scss new file mode 100755 index 0000000000..32c94b9dc5 --- /dev/null +++ b/assets/scss/_skin.scss @@ -0,0 +1,5 @@ +$blue: #3371e3; +$light-grey: #f7f7f7; +$dark-grey: #303030; +$medium-grey: #4c4c4c; +$white: #ffffff; diff --git a/assets/scss/_tablet.scss b/assets/scss/_tablet.scss new file mode 100644 index 0000000000..54ead8319c --- /dev/null +++ b/assets/scss/_tablet.scss @@ -0,0 +1,211 @@ +// header +$full-width-paddingX: 20px; + +$main-width: 100%; +$main-max-width: 100%; + +$header-height: 80px; + +$logo-width: 180px; + +$nav-buttons-margin-left: 30px; + +$hamburger-size: 50px; + +// main nav +$main-nav-padding: 140px 0 30px; +$main-nav-h5-margin-bottom: 1em; +$main-nav-h3-margin-bottom: 0.6em; +$nav-box-width: 20%; +$nav-box-sibling-margin-left: calc(20% / 3); +$main-nav-main-sibling-margin-top: 60px; +$main-nav-left-button-size: 50px; +$main-nav-left-button-font-size: 18px; + +// hero +$hero-padding-top: 136px; +$headline-wrapper-margin-bottom: 40px; +$quickstart-button-padding: 0 50px; +$vendor-strip-font-size: 16px; + +//video +$video-section-height: 400px; + +//features +$features-h3-margin-bottom: 40px; +$feature-box-margin-bottom: 60px; +$feature-box-div-margin-bottom: 0; +$feature-box-div-width: 45%; + +//////////////////////////////////////////////////////////////////////////////////////////////////// +//////////////////////////////////////////////////////////////////////////////////////////////////// +//////////////////////////////////////////////////////////////////////////////////////////////////// + +@media screen and (min-width: 768px) { + @import "size"; + + #hamburger { + display: none; + } + + .td-home { + #viewDocs, + #tryKubernetes { + display: inline-block; + } + } + + #vendorStrip { + display: block; + text-align: center; + + img { + max-height: 24px; + vertical-align: middle; + margin: 0 30px; + } + } + + #oceanNodes { + h3 { + text-align: left; + margin-bottom: 18px; + } + + main, + .main-section { + position: relative; + clear: both; + display: table; + height: 160px; + + .content { + display: table-cell; + position: relative; + vertical-align: middle; + } + + .image-wrapper { + position: absolute; + top: 50%; + max-width: 25%; + max-height: 100%; + transform: translateY(-50%); + } + + &:nth-child(odd) { + padding-right: 210px; + + .image-wrapper { + right: 0; + } + } + + &:nth-child(even) { + padding-left: 210px; + + .image-wrapper { + left: 0; + } + } + + &:nth-child(1) { + padding-right: 0; + + h3, + p { + text-align: center; + } + + .image-wrapper { + position: relative; + display: block; + float: none; + max-width: 100%; + transform: none; + } + + .content { + display: block; + } + } + + img { + width: 100%; + } + } + } + + #video { + height: $video-section-height; + display: block; + height: 500px; + + & > .light-text { + display: block; + float: right; + text-align: left; + margin-right: 5%; + } + } + + #mobileShowVideoButton { + display: none; + } + + #features { + padding-bottom: 60px; + + .feature-box { + margin-bottom: 30px; + + &:last-child { + margin-bottom: 0; + } + } + + h3 { + margin-bottom: $features-h3-margin-bottom; + } + + .feature-box { + & > div { + width: $feature-box-div-width; + margin-bottom: $feature-box-div-margin-bottom; + } + } + } + + #talkToUs { + #bigSocial { + div { + width: calc(50% - 15px); + } + + div + div { + margin-top: 0; + } + + div:nth-child(2) { + margin-left: 20px; + } + + div:nth-child(4) { + margin-left: 20px; + } + + a { + display: inline-block; + color: $blue; + font-weight: 400; + text-decoration: none; + } + } + } + + .td-home #caseStudiesWrapper { + div { + width: 48%; + } + } +} diff --git a/assets/scss/_variables_project.scss b/assets/scss/_variables_project.scss new file mode 100644 index 0000000000..da42c07367 --- /dev/null +++ b/assets/scss/_variables_project.scss @@ -0,0 +1,13 @@ +/* This file is provided by Docsy as an entry point to styling. +Add styles or override variables from the theme here. */ + +@import "reset"; +@import "skin"; + +//K8S-Docsy integration +@import "custom"; + +//Media queries +@import "base"; +@import "tablet"; +@import "desktop"; diff --git a/config.toml b/config.toml index f829fec6c2..34aa9d756d 100644 --- a/config.toml +++ b/config.toml @@ -1,6 +1,11 @@ baseURL = "https://kubernetes.io" title = "Kubernetes" +# Hugo allows theme composition (and inheritance). The precedence is from left to right. +theme = ["docsy"] + +# Language settings +contentDir = "content/en" defaultContentLanguage = "en" defaultContentLanguageInSubdir = false enableRobotsTXT = true @@ -10,10 +15,17 @@ disableKinds = ["taxonomy", "taxonomyTerm"] ignoreFiles = [ "^OWNERS$", "README[-]+[a-z]*\\.md", "^node_modules$", "content/en/docs/doc-contributor-tools" ] -contentDir = "content/en" - timeout = 3000 +# Highlighting config. +pygmentsCodeFences = true +pygmentsUseClasses = false +# Use the new Chroma Go highlighter in Hugo. +pygmentsUseClassic = false +#pygmentsOptions = "linenos=table" +# See https://help.farbox.com/pygments.html +pygmentsStyle = "emacs" + # Enable Git variables like commit, lastmod enableGitInfo = true @@ -23,6 +35,14 @@ disableLanguages = ["hi", "no"] [markup] [markup.goldmark] + [markup.goldmark.extensions] + definitionList = true + table = true + typographer = false + [markup.goldmark.parser] + attribute = true + autoHeadingID = true + autoHeadingIDType = "blackfriday" [markup.goldmark.renderer] unsafe = true [markup.highlight] @@ -35,6 +55,10 @@ disableLanguages = ["hi", "no"] noClasses = true style = "emacs" tabWidth = 4 + [markup.tableOfContents] + endLevel = 3 + ordered = false + startLevel = 2 [frontmatter] date = ["date", ":filename", "publishDate", "lastmod"] @@ -64,7 +88,28 @@ baseName = "_headers" isPlainText = true notAlternative = true +# Image processing configuration. +[imaging] +resampleFilter = "CatmullRom" +quality = 75 +anchor = "smart" + +[services] +[services.googleAnalytics] +# Comment out the next line to disable GA tracking. Also disables the feature described in [params.ui.feedback]. +id = "UA-00000000-0" + [params] +copyright_k8s = "The Kubernetes Authors" +copyright_linux = "Copyright © 2020 The Linux Foundation ®." +# privacy_policy = "https://policies.google.com/privacy" + +# First one is picked as the Twitter card image if not set on page. +# images = ["images/project-illustration.png"] + +# Menu title if your navbar has a versions selector to access old versions of your site. +# This menu appears only if you have at least one [params.versions] set. +version_menu = "Versions" time_format_blog = "Monday, January 02, 2006" description = "Production-Grade Container Orchestration" @@ -82,14 +127,25 @@ nextUrl = "https://kubernetes-io-vnext-staging.netlify.com/" githubWebsiteRepo = "github.com/kubernetes/website" githubWebsiteRaw = "raw.githubusercontent.com/kubernetes/website" -# param for displaying an announcement block on every page; see PR #16210 +# param for displaying an announcement block on every page. +# See /i18n/en.toml for message text and title. announcement = true -# announcement_message is only displayed when announcement = true; update with your specific message -announcement_title = "Black lives matter." -announcement_message_full = "We stand in solidarity with the Black community.
Racism is unacceptable.
It conflicts with the [core values of the Kubernetes project](https://git.k8s.io/community/values.md) and our community does not tolerate it." #appears on homepage. Use md formatting for links and
for line breaks. -announcement_message_compact = "We stand in solidarity with the Black community.
Racism is unacceptable.
It conflicts with the [core values of the Kubernetes project](https://git.k8s.io/community/values.md) and our community does not tolerate it." #appears on subpages announcement_bg = "#000000" #choose a dark color – text is white +#Searching +k8s_search = true + +#The following search parameters are specific to Docsy's implementation. Kubernetes implementes its own search-related partials and scripts. + +# Google Custom Search Engine ID. Remove or comment out to disable search. +#gcs_engine_id = "011737558837375720776:fsdu1nryfng" + +# Enable Algolia DocSearch +algolia_docsearch = false + +# Enable Lunr.js offline search +offlineSearch = false + [params.pushAssets] css = [ "callouts", @@ -136,6 +192,81 @@ githubbranch = "v1.15.11" docsbranch = "release-1.15" url = "https://v1-15.docs.kubernetes.io" + +# User interface configuration +[params.ui] +# Enable to show the side bar menu in its compact state. +sidebar_menu_compact = false +# Set to true to disable breadcrumb navigation. +breadcrumb_disable = false +# Set to true to hide the sidebar search box (the top nav search box will still be displayed if search is enabled) +sidebar_search_disable = false +# Set to false if you don't want to display a logo (/assets/icons/logo.svg) in the top nav bar +navbar_logo = true +# Set to true to disable the About link in the site footer +footer_about_disable = false + +# Adds a H2 section titled "Feedback" to the bottom of each doc. The responses are sent to Google Analytics as events. +# This feature depends on [services.googleAnalytics] and will be disabled if "services.googleAnalytics.id" is not set. +# If you want this feature, but occasionally need to remove the "Feedback" section from a single page, +# add "hide_feedback: true" to the page's front matter. +[params.ui.feedback] +enable = true +# The responses that the user sees after clicking "yes" (the page was helpful) or "no" (the page was not helpful). +yes = 'Glad to hear it! Please tell us how we can improve.' +no = 'Sorry to hear that. Please tell us how we can improve.' + +[params.links] +# End user relevant links. These will show up on left side of footer and in the community page if you have one. +[[params.links.user]] + name = "User mailing list" + url = "https://discuss.kubernetes.io" + icon = "fa fa-envelope" + desc = "Discussion and help from your fellow users" + +[[params.links.user]] + name = "Twitter" + url = "https://twitter.com/kubernetesio" + icon = "fab fa-twitter" + desc = "Follow us on Twitter to get the latest news!" + +[[params.links.user]] + name = "Calendar" + url = "https://calendar.google.com/calendar/embed?src=nt2tcnbtbied3l6gi2h29slvc0%40group.calendar.google.com" + icon = "fas fa-calendar-alt" + desc = "Google Calendar for Kubernetes" + +[[params.links.user]] + name = "Youtube" + url = "https://youtbue.com/kubernetescommunity" + icon = "fab fa-youtube" + desc = "Youtube community videos" + +# Developer relevant links. These will show up on right side of footer and in the community page if you have one. +[[params.links.developer]] + name = "GitHub" + url = "https://github.com/kubernetes/kubernetes" + icon = "fab fa-github" + desc = "Development takes place here!" + +[[params.links.developer]] + name = "Slack" + url = "https://slack.k8s.io" + icon = "fab fa-slack" + desc = "Chat with other project developers" + +[[params.links.developer]] + name = "Contribute" + url = "https://git.k8s.io/community/contributors/guide" + icon = "fas fa-edit" + desc = "Contribute to the Kubernetes website" + +[[params.links.developer]] + name = "Stack Overflow" + url = "https://stackoverflow.com/questions/tagged/kubernetes" + icon = "fab fa-stack-overflow" + desc = "Practical questions and curated answers" + # Language definitions. [languages] diff --git a/content/de/docs/concepts/_index.md b/content/de/docs/concepts/_index.md index 82b5b0e5b0..43d273b432 100644 --- a/content/de/docs/concepts/_index.md +++ b/content/de/docs/concepts/_index.md @@ -1,17 +1,17 @@ --- title: Konzepte main_menu: true -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + Im Abschnitt Konzepte erfahren Sie mehr über die Bestandteile des Kubernetes-Systems und die Abstraktionen, die Kubernetes zur Verwaltung Ihres Clusters zur Verfügung stellt. Sie erhalten zudem ein tieferes Verständnis der Funktionsweise von Kubernetes. -{{% /capture %}} -{{% capture body %}} + + ## Überblick @@ -65,11 +65,12 @@ Die Nodes in einem Cluster sind die Maschinen (VMs, physische Server usw.), auf * [Anmerkungen](/docs/concepts/overview/working-with-objects/annotations/) -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + Wenn Sie eine Konzeptseite schreiben möchten, lesen Sie [Seitenvorlagen verwenden](/docs/home/contribute/page-templates/) für Informationen zum Konzeptseitentyp und zur Dokumentations Vorlage. -{{% /capture %}} + diff --git a/content/de/docs/concepts/architecture/cloud-controller.md b/content/de/docs/concepts/architecture/cloud-controller.md index 7e044119b8..21da96e612 100644 --- a/content/de/docs/concepts/architecture/cloud-controller.md +++ b/content/de/docs/concepts/architecture/cloud-controller.md @@ -1,10 +1,10 @@ --- title: Zugrunde liegende Konzepte des Cloud Controller Manager -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + Das Konzept des Cloud Controller Managers (CCM) (nicht zu verwechseln mit der Binärdatei) wurde ursprünglich entwickelt, um Cloud-spezifischen Anbieter Code und den Kubernetes Kern unabhängig voneinander entwickeln zu können. Der Cloud Controller Manager läuft zusammen mit anderen Master Komponenten wie dem Kubernetes Controller Manager, dem API-Server und dem Scheduler auf dem Host. Es kann auch als Kubernetes Addon gestartet werden, in diesem Fall läuft er auf Kubernetes. Das Design des Cloud Controller Managers basiert auf einem Plugin Mechanismus, der es neuen Cloud Anbietern ermöglicht, sich mit Kubernetes einfach über Plugins zu integrieren. Es gibt Pläne für die Einbindung neuer Cloud Anbieter auf Kubernetes und für die Migration von Cloud Anbietern vom alten Modell auf das neue CCM-Modell. @@ -15,10 +15,10 @@ Die Architektur eines Kubernetes Clusters ohne den Cloud Controller Manager sieh ![Pre CCM Kube Arch](/images/docs/pre-ccm-arch.png) -{{% /capture %}} -{{% capture body %}} + + ## Design @@ -235,4 +235,4 @@ Die folgenden Cloud Anbieter haben CCMs implementiert: Eine vollständige Anleitung zur Konfiguration und zum Betrieb des CCM findest du [hier](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager). -{{% /capture %}} + diff --git a/content/de/docs/concepts/architecture/master-node-communication.md b/content/de/docs/concepts/architecture/master-node-communication.md index e7903f2606..6874cdb687 100644 --- a/content/de/docs/concepts/architecture/master-node-communication.md +++ b/content/de/docs/concepts/architecture/master-node-communication.md @@ -1,18 +1,18 @@ --- title: Master-Node Kommunikation -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + Dieses Dokument katalogisiert die Kommunikationspfade zwischen dem Master (eigentlich dem Apiserver) und des Kubernetes-Clusters. Die Absicht besteht darin, Benutzern die Möglichkeit zu geben, ihre Installation so anzupassen, dass die Netzwerkkonfiguration so abgesichert wird, dass der Cluster in einem nicht vertrauenswürdigen Netzwerk (oder mit vollständig öffentlichen IP-Adressen eines Cloud-Providers) ausgeführt werden kann. -{{% /capture %}} -{{% capture body %}} + + ## Cluster zum Master @@ -69,4 +69,4 @@ Dieser Tunnel stellt sicher, dass der Datenverkehr nicht außerhalb des Netzwerk SSH-Tunnel werden zur Zeit nicht unterstützt. Sie sollten also nicht verwendet werden, sei denn, man weiß, was man tut. Ein Ersatz für diesen Kommunikationskanal wird entwickelt. -{{% /capture %}} + diff --git a/content/de/docs/concepts/architecture/nodes.md b/content/de/docs/concepts/architecture/nodes.md index 0f3d396968..8a2b8b7fde 100644 --- a/content/de/docs/concepts/architecture/nodes.md +++ b/content/de/docs/concepts/architecture/nodes.md @@ -1,10 +1,10 @@ --- title: Nodes -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + Ein Knoten (Node in Englisch) ist eine Arbeitsmaschine in Kubernetes, früher als `minion` bekannt. Ein Node kann je nach Cluster eine VM oder eine physische Maschine sein. Jeder Node enthält @@ -13,10 +13,10 @@ und wird von den Master-Komponenten verwaltet. Die Dienste auf einem Node umfassen die [Container Runtime](/docs/concepts/overview/components/#node-components), das Kubelet und den Kube-Proxy. Weitere Informationen finden Sie im Abschnitt Kubernetes Node in der Architekturdesign-Dokumentation. -{{% /capture %}} -{{% capture body %}} + + ## Node Status @@ -244,4 +244,4 @@ Wenn Sie Ressourcen explizit für Nicht-Pod-Prozesse reservieren möchten, folge Node ist eine Top-Level-Ressource in der Kubernetes-REST-API. Weitere Details zum API-Objekt finden Sie unter: [Node API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core). -{{% /capture %}} + diff --git a/content/de/docs/concepts/cluster-administration/addons.md b/content/de/docs/concepts/cluster-administration/addons.md index 4d26b57da8..f5eedeb59b 100644 --- a/content/de/docs/concepts/cluster-administration/addons.md +++ b/content/de/docs/concepts/cluster-administration/addons.md @@ -1,9 +1,9 @@ --- title: Addons Installieren -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + Add-Ons erweitern die Funktionalität von Kubernetes. @@ -12,10 +12,10 @@ Diese Seite gibt eine Übersicht über einige verfügbare Add-Ons und verweist a Die Add-Ons in den einzelnen Kategorien sind alphabetisch sortiert - Die Reihenfolge impliziert keine bevorzugung einzelner Projekte. -{{% /capture %}} -{{% capture body %}} + + ## Networking und Network Policy @@ -53,4 +53,4 @@ Es gibt einige weitere Add-Ons die in dem abgekündigten [cluster/addons](https: Add-Ons die ordentlich gewartet werden dürfen gerne hier aufgezählt werden. Wir freuen uns auf PRs! -{{% /capture %}} + diff --git a/content/de/docs/concepts/cluster-administration/controller-metrics.md b/content/de/docs/concepts/cluster-administration/controller-metrics.md index 4fd9b0d538..86cd0a1548 100644 --- a/content/de/docs/concepts/cluster-administration/controller-metrics.md +++ b/content/de/docs/concepts/cluster-administration/controller-metrics.md @@ -1,15 +1,15 @@ --- title: Controller Manager Metriken -content_template: templates/concept +content_type: concept weight: 100 --- -{{% capture overview %}} + Controller Manager Metriken liefern wichtige Erkenntnisse über die Leistung und den Zustand von den Controller Managern. -{{% /capture %}} -{{% capture body %}} + + ## Was sind Controller Manager Metriken Die Kennzahlen des Controller Managers liefert wichtige Erkenntnisse über die Leistung und den Zustand des Controller Managers. @@ -38,4 +38,3 @@ Die Metriken werden im [Prometheus Format](https://prometheus.io/docs/instrument In einer Produktionsumgebung können Sie Prometheus oder einen anderen Metrik Scraper konfigurieren, um diese Metriken regelmäßig zu sammeln und in einer Art Zeitreihen Datenbank verfügbar zu machen. -{{% /capture %}} \ No newline at end of file diff --git a/content/de/docs/concepts/cluster-administration/proxies.md b/content/de/docs/concepts/cluster-administration/proxies.md index 16d36ad518..a872dbad8d 100644 --- a/content/de/docs/concepts/cluster-administration/proxies.md +++ b/content/de/docs/concepts/cluster-administration/proxies.md @@ -1,14 +1,14 @@ --- title: Proxies in Kubernetes -content_template: templates/concept +content_type: concept weight: 90 --- -{{% capture overview %}} + Auf dieser Seite werden die im Kubernetes verwendeten Proxies erläutert. -{{% /capture %}} -{{% capture body %}} + + ## Proxies @@ -61,4 +61,3 @@ Kubernetes Benutzer müssen sich in der Regel um nichts anderes als die ersten b Proxies haben die Möglichkeit der Umleitung (redirect) ersetzt. Umleitungen sind veraltet. -{{% /capture %}} \ No newline at end of file diff --git a/content/de/docs/concepts/containers/images.md b/content/de/docs/concepts/containers/images.md index 03ec9b4a0e..d142405f06 100644 --- a/content/de/docs/concepts/containers/images.md +++ b/content/de/docs/concepts/containers/images.md @@ -1,18 +1,18 @@ --- title: Images -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + Sie erstellen ihr Docker Image und laden es in eine Registry hoch, bevor es in einem Kubernetes Pod referenziert werden kann. Die `image` Eigenschaft eines Containers unterstüzt die gleiche Syntax wie die des `docker` Kommandos, inklusive privater Registries und Tags. -{{% /capture %}} -{{% capture body %}} + + ## Aktualisieren von Images @@ -334,7 +334,7 @@ Es gibt eine Anzahl an Lösungen um eigene Registries zu konfigurieren, hier sin - Generieren die Registry - Zugriffsdaten für jeden Mandanten, abgelegt in einem Secret das in jedem Mandanten - Namespace vorhanden ist. - Der Mandant fügt dieses Sercret zu den imagePullSecrets in jedem seiner Namespace hinzu. -{{% /capture %}} + Falls die Zugriff auf mehrere Registries benötigen, können sie ein Secret für jede Registry erstellen, Kubelet wird jedwede `imagePullSecrets` in einer einzelnen `.docker/config.json` zusammenfassen. diff --git a/content/de/docs/concepts/example-concept-template.md b/content/de/docs/concepts/example-concept-template.md index 9f3a2bcfac..a7694cc54b 100644 --- a/content/de/docs/concepts/example-concept-template.md +++ b/content/de/docs/concepts/example-concept-template.md @@ -1,10 +1,10 @@ --- title: Konzept Dokumentations-Vorlage -content_template: templates/concept +content_type: concept toc_hide: true --- -{{% capture overview %}} + {{< note >}} Stellen Sie auch sicher [einen Eintrag im Inhaltsverzeichnis](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) für Ihr neues Dokument zu erstellen. @@ -12,9 +12,9 @@ Stellen Sie auch sicher [einen Eintrag im Inhaltsverzeichnis](/docs/home/contrib Diese Seite erklärt ... -{{% /capture %}} -{{% capture body %}} + + ## Verstehen ... @@ -24,15 +24,16 @@ Kubernetes bietet ... Benutzen Sie ... -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + **[Optionaler Bereich]** * Lernen Sie mehr über [ein neues Thema schreiben](/docs/home/contribute/write-new-topic/). * Besuchen Sie [Seitenvorlagen verwenden - Konzeptvorlage](/docs/home/contribute/page-templates/#concept_template) wie Sie diese Vorlage verwenden. -{{% /capture %}} + diff --git a/content/de/docs/concepts/overview/components.md b/content/de/docs/concepts/overview/components.md index 47560e0a68..af371e3b87 100644 --- a/content/de/docs/concepts/overview/components.md +++ b/content/de/docs/concepts/overview/components.md @@ -1,17 +1,17 @@ --- title: Kubernetes Komponenten -content_template: templates/concept +content_type: concept weight: 20 card: name: concepts weight: 20 --- -{{% capture overview %}} + In diesem Dokument werden die verschiedenen binären Komponenten beschrieben, die zur Bereitstellung eines funktionsfähigen Kubernetes-Clusters erforderlich sind. -{{% /capture %}} -{{% capture body %}} + + ## Master-Komponenten Master-Komponenten stellen die Steuerungsebene des Clusters bereit. Master-Komponenten treffen globale Entscheidungen über den Cluster (z. B. Zeitplanung) und das Erkennen und Reagieren auf Clusterereignisse (Starten eines neuen Pods, wenn das `replicas`-Feld eines Replikationscontrollers nicht zufriedenstellend ist). @@ -107,6 +107,6 @@ Von Kubernetes gestartete Container schließen diesen DNS-Server automatisch in Ein [Cluster-level logging](/docs/concepts/cluster-administration/logging/) Mechanismus ist für das Speichern von Containerprotokollen in einem zentralen Protokollspeicher mit Such- / Browsing-Schnittstelle verantwortlich. -{{% /capture %}} + diff --git a/content/de/docs/concepts/overview/what-is-kubernetes.md b/content/de/docs/concepts/overview/what-is-kubernetes.md index af7cfc614a..66b79d6928 100644 --- a/content/de/docs/concepts/overview/what-is-kubernetes.md +++ b/content/de/docs/concepts/overview/what-is-kubernetes.md @@ -1,17 +1,17 @@ --- title: Was ist Kubernetes? -content_template: templates/concept +content_type: concept weight: 10 card: name: concepts weight: 10 --- -{{% capture overview %}} + Diese Seite ist eine Übersicht über Kubernetes. -{{% /capture %}} -{{% capture body %}} + + Kubernetes ist eine portable, erweiterbare Open-Source-Plattform zur Verwaltung von containerisierten Arbeitslasten und Services, die sowohl die deklarative Konfiguration als auch die Automatisierung erleichtert. @@ -160,11 +160,12 @@ Der Name **Kubernetes** stammt aus dem Griechischen, bedeutet *Steuermann* oder [cybernetic](http://www.etymonline.com/index.php?term=cybernetics). *K8s* ist eine Abkürzung, die durch Ersetzen der 8 Buchstaben "ubernete" mit "8" abgeleitet wird. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [Bereit loszulegen](/docs/setup/)? * Weitere Einzelheiten finden Sie in der [Kubernetes Dokumentation](/docs/home/). -{{% /capture %}} + diff --git a/content/de/docs/contribute/_index.md b/content/de/docs/contribute/_index.md index 9853ef4e54..db7c6687ab 100644 --- a/content/de/docs/contribute/_index.md +++ b/content/de/docs/contribute/_index.md @@ -1,12 +1,12 @@ --- -content_template: templates/concept +content_type: concept title: Zur Kubernets-Dokumentation beitragen linktitle: Mitmachen main_menu: true weight: 80 --- -{{% capture overview %}} + Wenn Sie an der Dokumentation oder der Website von Kubernetes mitwirken möchten, freuen wir uns über Ihre Hilfe! Jeder kann seinen Beitrag leisten, unabhängig davon ob Sie neu im Projekt sind oder schon lange dabei sind, und ob Sie sich als @@ -15,7 +15,7 @@ Entwickler, Endbenutzer oder einfach jemanden, der es einfach nicht aushält, Ti Weitere Möglichkeiten, sich in der Kubernetes-Community zu engagieren oder mehr über uns zu erfahren, finden Sie auf der [Kubernetes-Community-Seite](/community/). Informationen zum Handbuch zur Dokumentation von Kubernetes finden Sie im [Gestaltungshandbuch](/docs/contribute/style/style-guide/). -{{% capture body %}} + ## Arten von Mitwirkenden @@ -59,4 +59,4 @@ Dies ist keine vollständige Liste von Möglichkeiten, wie Sie zur Kubernetes-Do - Verbesserungsvorschläge für Dokumentprüfungen vorschlagen - Vorschläge für Verbesserungen der Kubernetes-Website oder anderer Tools -{{% /capture %}} + diff --git a/content/de/docs/contribute/localization.md b/content/de/docs/contribute/localization.md index 79084cc0f2..031eeb8755 100644 --- a/content/de/docs/contribute/localization.md +++ b/content/de/docs/contribute/localization.md @@ -1,6 +1,6 @@ --- title: Lokalisierung der Kubernetes Dokumentation -content_template: templates/concept +content_type: concept weight: 50 card: name: mitarbeiten @@ -8,13 +8,13 @@ card: title: Übersetzen der Dokumentation --- -{{% capture overview %}} + Diese Seite zeigt dir wie die Dokumentation für verschiedene Sprachen [lokalisiert](https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/) wird. -{{% /capture %}} -{{% capture body %}} + + ## Erste Schritte @@ -277,13 +277,14 @@ SIG Docs begrüßt Upstream Beiträge, also auf das englische Original, und Korr Du kannst auch dazu beitragen, Inhalte zu einer bestehenden Lokalisierung hinzuzufügen oder zu verbessern. Trete dem [Slack-Kanal](https://kubernetes.slack.com/messages/C1J0BPD2M/) für die Lokalisierung bei und beginne mit der Eröffnung von PRs, um zu helfen. Bitte beschränke deine Pull-Anfragen auf eine einzige Lokalisierung, da Pull-Anfragen, die Inhalte in mehreren Lokalisierungen ändern, schwer zu überprüfen sein könnten. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + Sobald eine Lokalisierung die Anforderungen an den Arbeitsablauf und die Mindestausgabe erfüllt, wird SIG docs: - Die Sprachauswahl auf der Website aktivieren - Die Verfügbarkeit der Lokalisierung über die Kanäle der [Cloud Native Computing Foundation](https://www.cncf.io/about/) (CNCF), einschließlich des [Kubernetes Blogs](https://kubernetes.io/blog/) veröffentlichen. -{{% /capture %}} + diff --git a/content/de/docs/home/supported-doc-versions.md b/content/de/docs/home/supported-doc-versions.md index 8463d1bcd9..c1064b9730 100644 --- a/content/de/docs/home/supported-doc-versions.md +++ b/content/de/docs/home/supported-doc-versions.md @@ -1,20 +1,20 @@ --- title: Unterstützte Versionen der Kubernetes-Dokumentation -content_template: templates/concept +content_type: concept card: name: about weight: 10 title: Unterstützte Versionen der Dokumentation --- -{{% capture overview %}} + Diese Website enthält Dokumentation für die aktuelle Version von Kubernetes und die vier vorherigen Versionen von Kubernetes. -{{% /capture %}} -{{% capture body %}} + + ## Aktuelle Version @@ -25,6 +25,6 @@ Die aktuelle Version ist {{< versions-other >}} -{{% /capture %}} + diff --git a/content/de/docs/reference/_index.md b/content/de/docs/reference/_index.md index b57b2740cd..7ffa9c04c9 100644 --- a/content/de/docs/reference/_index.md +++ b/content/de/docs/reference/_index.md @@ -5,16 +5,16 @@ approvers: linkTitle: "Referenzen" main_menu: true weight: 70 -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + Dieser Abschnitt der Kubernetes-Dokumentation enthält Referenzinformationen. -{{% /capture %}} -{{% capture body %}} + + ## API-Referenz @@ -58,4 +58,4 @@ Offiziell unterstützte Clientbibliotheken: Ein Archiv der Designdokumente für Kubernetes-Funktionalität. Gute Ansatzpunkte sind [Kubernetes Architektur](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) und [Kubernetes Design Übersicht](https://git.k8s.io/community/contributors/design-proposals). -{{% /capture %}} + diff --git a/content/de/docs/reference/kubectl/cheatsheet.md b/content/de/docs/reference/kubectl/cheatsheet.md index c68fc183b5..15b8d0bda3 100644 --- a/content/de/docs/reference/kubectl/cheatsheet.md +++ b/content/de/docs/reference/kubectl/cheatsheet.md @@ -1,20 +1,20 @@ --- title: kubectl Spickzettel -content_template: templates/concept +content_type: concept card: name: reference weight: 30 --- -{{% capture overview %}} + Siehe auch: [Kubectl Überblick](/docs/reference/kubectl/overview/) und [JsonPath Dokumentation](/docs/reference/kubectl/jsonpath). Diese Seite ist eine Übersicht über den Befehl `kubectl`. -{{% /capture %}} -{{% capture body %}} + + # kubectl - Spickzettel @@ -335,9 +335,10 @@ Ausführlichkeit | Beschreibung `--v=8` | HTTP-Anforderungsinhalt anzeigen `--v=9` | HTTP-Anforderungsinhalt anzeigen, ohne den Inhalt zu kürzen. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Lernen Sie mehr im [Überblick auf kubectl](/docs/reference/kubectl/overview/). @@ -347,4 +348,4 @@ Ausführlichkeit | Beschreibung * Entdecken Sie mehr Community [kubectl Spickzettel](https://github.com/dennyzhang/cheatsheet-kubernetes-A4). -{{% /capture %}} + diff --git a/content/de/docs/reference/tools.md b/content/de/docs/reference/tools.md index 3daeda6efe..42bba64616 100644 --- a/content/de/docs/reference/tools.md +++ b/content/de/docs/reference/tools.md @@ -1,13 +1,13 @@ --- title: Tools -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + Kubernetes enthält mehrere integrierte Tools, die Ihnen bei der Arbeit mit dem Kubernetes System helfen. -{{% /capture %}} -{{% capture body %}} + + ## Kubectl [`kubectl`](/docs/tasks/tools/install-kubectl/) ist ein Kommandozeilenprogramm für Kubernetes. Es steuert den Kubernetes Clustermanager. @@ -49,4 +49,4 @@ Verwenden Sie Kompose um: * Ein Docker Compose Datei in Kubernetes Objekte zu übersetzen * Von Ihrer lokalen Docker Entwicklung auf eine Kubernetes verwaltete Entwicklung zu wechseln * v1 oder v2 Docker Compose `yaml` Dateien oder [Distributed Application Bundles](https://docs.docker.com/compose/bundles/) zu konvertieren -{{% /capture %}} + diff --git a/content/de/docs/setup/_index.md b/content/de/docs/setup/_index.md index 3ee12cbb7b..d7f074efb3 100644 --- a/content/de/docs/setup/_index.md +++ b/content/de/docs/setup/_index.md @@ -2,10 +2,10 @@ title: Setup main_menu: true weight: 30 -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + Diese Sektion umfasst verschiedene Optionen zum Einrichten und Betrieb von Kubernetes. @@ -15,9 +15,9 @@ Sie können einen Kubernetes-Cluster auf einer lokalen Maschine, Cloud, On-Prem Noch einfacher können Sie einen Kubernetes-Cluster in einer Lern- und Produktionsumgebung erstellen. -{{% /capture %}} -{{% capture body %}} + + ## Lernumgebung @@ -99,4 +99,4 @@ Die folgende Tabelle für Produktionsumgebungs-Lösungen listet Anbieter und der | [VMware](https://cloud.vmware.com/) | [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) |[VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) | |[VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) | [Z.A.R.V.I.S.](https://zarvis.ai/) | ✔ | | | | | | -{{% /capture %}} + diff --git a/content/de/docs/setup/minikube.md b/content/de/docs/setup/minikube.md index 06734bd28f..f0484a8447 100644 --- a/content/de/docs/setup/minikube.md +++ b/content/de/docs/setup/minikube.md @@ -1,15 +1,15 @@ --- title: Kubernetes lokal über Minikube betreiben -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + Minikube ist ein Tool, mit dem Kubernetes lokal einfach ausgeführt werden kann. Minikube führt einen Kubernetes-Cluster mit einem einzigen Node in einer VM auf Ihrem Laptop aus, damit Anwender Kubernetes ausprobieren oder täglich damit entwickeln können. -{{% /capture %}} -{{% capture body %}} + + ## Minikube-Funktionen @@ -34,10 +34,10 @@ Minikube unterstützt die folgenden Treiber: * virtualbox * vmwarefusion -* kvm2 ([Treiber installation](https://git.k8s.io/minikube/docs/drivers.md#kvm2-driver)) -* kvm ([Treiber installation](https://git.k8s.io/minikube/docs/drivers.md#kvm-driver)) -* hyperkit ([Treiber installation](https://git.k8s.io/minikube/docs/drivers.md#hyperkit-driver)) -* xhyve ([Treiber installation](https://git.k8s.io/minikube/docs/drivers.md#xhyve-driver)) (deprecated) +* kvm2 ([Treiber installation](https://minikube.sigs.k8s.io/docs/drivers/#kvm2-driver)) +* kvm ([Treiber installation](https://minikube.sigs.k8s.io/docs/drivers/#kvm-driver)) +* hyperkit ([Treiber installation](https://minikube.sigs.k8s.io/docs/drivers/#hyperkit-driver)) +* xhyve ([Treiber installation](https://minikube.sigs.k8s.io/docs/drivers/#xhyve-driver)) (deprecated) * hyperv ([Treiber installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver)) Beachten Sie, dass die unten angegebene IP-Adresse dynamisch ist und sich ändern kann. Sie kann mit `minikube ip` abgerufen werden. * none (Führt die Kubernetes-Komponenten auf dem Host und nicht in einer VM aus. Die Verwendung dieses Treibers erfordert Docker ([Docker installieren](https://docs.docker.com/install/linux/docker-ce/ubuntu/)) und eine Linux-Umgebung) @@ -201,7 +201,7 @@ Hierbei wird ein alternatives Minikube-ISO-Image verwendet, das sowohl rkt als a ### Treiber Plugins -Weitere Informationen zu unterstützten Treibern und zur Installation von Plugins finden Sie bei Bedarf unter [TREIBER](https://git.k8s.io/minikube/docs/drivers.md). +Weitere Informationen zu unterstützten Treibern und zur Installation von Plugins finden Sie bei Bedarf unter [TREIBER](https://minikube.sigs.k8s.io/docs/drivers/). ### Lokale Images durch erneute Verwendung des Docker-Daemon ausführen @@ -431,7 +431,7 @@ Weitere Informationen zu Minikube finden Sie im [Vorschlag](https://git.k8s.io/c * **Ziele und Nichtziele**: Die Ziele und Nichtziele des Minikube-Projekts finden Sie in unserer [Roadmap](https://git.k8s.io/minikube/docs/contributors/roadmap.md). * **Entwicklungshandbuch**: Lesen Sie [CONTRIBUTING.md](https://git.k8s.io/minikube/CONTRIBUTING.md) für einen Überblick über das Senden von Pull-Requests. * **Minikube bauen**: Anweisungen zum Erstellen/Testen von Minikube aus dem Quellcode finden Sie im [build Handbuch](https://git.k8s.io/minikube/docs/contributors/build_guide.md). -* **Neue Abhängigkeit hinzufügen**: Anweisungen zum Hinzufügen einer neuen Abhängigkeit zu Minikube finden Sie in der [Anleitung zum Hinzufügen von Abhängigkeiten](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md). +* **Neue Abhängigkeit hinzufügen**: Anweisungen zum Hinzufügen einer neuen Abhängigkeit zu Minikube finden Sie in der [Anleitung zum Hinzufügen von Abhängigkeiten](https://minikube.sigs.k8s.io/docs/drivers/). * **Neues Addon hinzufügen**: Anweisungen zum Hinzufügen eines neuen Addons für Minikube finden Sie im [Anleitung zum Hinzufügen eines Addons](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md). * **MicroK8s**: Linux-Benutzer, die die Ausführung einer virtuellen Maschine vermeiden möchten, sollten [MicroK8s](https://microk8s.io/) als Alternative in Betracht ziehen. @@ -439,4 +439,4 @@ Weitere Informationen zu Minikube finden Sie im [Vorschlag](https://git.k8s.io/c Beiträge, Fragen und Kommentare werden begrüßt und ermutigt! Minikube-Entwickler finden Sie in [Slack](https://kubernetes.slack.com) im #minikube Kanal (Erhalten Sie [hier](http://slack.kubernetes.io/) eine Einladung). Wir haben ausserdem die [kubernetes-dev Google Groups-Mailingliste](https://groups.google.com/forum/#!forum/kubernetes-dev). Wenn Sie in der Liste posten, fügen Sie Ihrem Betreff bitte "minikube:" voran. -{{% /capture %}} + diff --git a/content/de/docs/setup/release/building-from-source.md b/content/de/docs/setup/release/building-from-source.md index 55d324574f..76879df995 100644 --- a/content/de/docs/setup/release/building-from-source.md +++ b/content/de/docs/setup/release/building-from-source.md @@ -1,19 +1,19 @@ --- title: Release erstellen -content_template: templates/concept +content_type: concept card: name: download weight: 20 title: Release erstellen --- -{{% capture overview %}} + Sie können entweder eine Version aus dem Quellcode erstellen oder eine bereits kompilierte Version herunterladen. Wenn Sie nicht vorhaben, Kubernetes selbst zu entwickeln, empfehlen wir die Verwendung eines vorkompilierten Builds der aktuellen Version, die Sie in den [Versionshinweisen](/docs/setup/release/notes/) finden. Der Kubernetes-Quellcode kann aus dem [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) repo der heruntergeladen werden. -{{% /capture %}} -{{% capture body %}} + + ## Aus dem Quellcode kompilieren @@ -29,4 +29,4 @@ make release Mehr Informationen zum Release-Prozess finden Sie im kubernetes/kubernetes [`build`](http://releases.k8s.io/{{< param "githubbranch" >}}/build/) Verzeichnis. -{{% /capture %}} + diff --git a/content/de/docs/tasks/_index.md b/content/de/docs/tasks/_index.md index 1589a013e0..bfa2a73dba 100644 --- a/content/de/docs/tasks/_index.md +++ b/content/de/docs/tasks/_index.md @@ -2,19 +2,19 @@ title: Aufgaben main_menu: true weight: 50 -content_template: templates/concept +content_type: concept --- {{< toc >}} -{{% capture overview %}} + Dieser Abschnitt der Kubernetes-Dokumentation enthält Seiten, die zeigen, wie man einzelne Aufgaben erledigt. Eine Aufgabenseite zeigt, wie man eine einzelne Aufgabe ausführt, typischerweise durch eine kurze Abfolge von Schritten. -{{% /capture %}} -{{% capture body %}} + + ## Webbenutzeroberfläche (Dashboard) @@ -76,10 +76,11 @@ Konfigurieren und planen Sie NVIDIA-GPUs für die Verwendung durch Nodes in eine Konfigurieren und verwalten Sie `HugePages` als planbare Ressource in einem Cluster. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + Wenn Sie eine Aufgabenseite schreiben möchten, finden Sie weitere Informationen unter [Erstellen einer Pull-Anfrage für Dokumentation](/docs/home/contribute/create-pull-request/). -{{% /capture %}} + diff --git a/content/de/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/de/docs/tasks/run-application/horizontal-pod-autoscale.md index 03cbb787bb..cd120285f1 100644 --- a/content/de/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/de/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -5,11 +5,11 @@ feature: description: > Skaliere deine Anwendung mit einem einfachen Befehl, über die Benutzeroberfläche oder automatisch, basierend auf der CPU-Auslastung. -content_template: templates/concept +content_type: concept weight: 90 --- -{{% capture overview %}} + Der Horizontal Pod Autoscaler skaliert automatisch die Anzahl der Pods eines Replication Controller, Deployment oder Replikat Set basierend auf der beobachteten CPU-Auslastung (oder, mit Unterstützung von [benutzerdefinierter Metriken](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md), von der Anwendung bereitgestellten Metriken). Beachte, dass die horizontale Pod Autoskalierung nicht für Objekte gilt, die nicht skaliert werden können, z. B. DaemonSets. @@ -17,9 +17,9 @@ Der Horizontal Pod Autoscaler ist als Kubernetes API-Ressource und einem Control Die Ressource bestimmt das Verhalten des Controllers. Der Controller passt die Anzahl der Replikate eines Replication Controller oder Deployments regelmäßig an, um die beobachtete durchschnittliche CPU-Auslastung an das vom Benutzer angegebene Ziel anzupassen. -{{% /capture %}} -{{% capture body %}} + + ## Wie funktioniert der Horizontal Pod Autoscaler? @@ -161,12 +161,13 @@ Standardmäßig ruft der HorizontalPodAutoscaler Controller Metriken aus einer R * Das Flag `--horizontal-pod-autoscaler-use-rest-clients` ist auf `true` oder ungesetzt. Wird dies auf `false` gesetzt wird die Heapster basierte Autoskalierung aktiviert, welche veraltet ist. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Design Dokument [Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md). * kubectl autoscale Befehl: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale). * Verwenden des [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). -{{% /capture %}} + diff --git a/content/de/docs/tasks/tools/install-kubectl.md b/content/de/docs/tasks/tools/install-kubectl.md index dd9c68c2ca..d7fb7aa759 100644 --- a/content/de/docs/tasks/tools/install-kubectl.md +++ b/content/de/docs/tasks/tools/install-kubectl.md @@ -1,6 +1,6 @@ --- title: Installieren und konfigurieren von kubectl -content_template: templates/task +content_type: task weight: 10 card: name: tasks @@ -8,17 +8,18 @@ card: title: Kubectl installieren --- -{{% capture overview %}} + Verwenden Sie das Kubernetes Befehlszeilenprogramm, [kubectl](/docs/user-guide/kubectl/), um Anwendungen auf Kubernetes bereitzustellen und zu verwalten. Mit kubectl können Sie Clusterressourcen überprüfen, Komponenten erstellen, löschen und aktualisieren; Ihren neuen Cluster betrachten; und Beispielanwendungen aufrufen. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + Sie müssen eine kubectl-Version verwenden, die innerhalb eines geringfügigen Versionsunterschieds zur Version Ihres Clusters liegt. Ein v1.2-Client sollte beispielsweise mit einem v1.1, v1.2 und v1.3-Master arbeiten. Die Verwendung der neuesten Version von kubectl verhindert unvorhergesehene Probleme. -{{% /capture %}} -{{% capture steps %}} + + ## Kubectl installieren @@ -421,9 +422,10 @@ compinit {{% /tab %}} {{< /tabs >}} -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + [Erfahren Sie, wie Sie Ihre Anwendung starten und verfügbar machen.](/docs/tasks/access-application-cluster/service-access-application-cluster/) -{{% /capture %}} + diff --git a/content/de/docs/tasks/tools/install-minikube.md b/content/de/docs/tasks/tools/install-minikube.md index c3d08bac30..318fcf25aa 100644 --- a/content/de/docs/tasks/tools/install-minikube.md +++ b/content/de/docs/tasks/tools/install-minikube.md @@ -1,28 +1,29 @@ --- title: Installation von Minikube -content_template: templates/task +content_type: task weight: 20 card: name: tasks weight: 10 --- -{{% capture overview %}} + Diese Seite zeigt Ihnen, wie Sie [Minikube](/docs/tutorials/hello-minikube) installieren, ein Programm, das einen Kubernetes-Cluster mit einem einzigen Node in einer virtuellen Maschine auf Ihrem Laptop ausführt. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + Die VT-x- oder AMD-v-Virtualisierung muss im BIOS Ihres Computers aktiviert sein. Um dies unter Linux zu überprüfen, führen Sie Folgendes aus und vergewissern Sie sich, dass die Ausgabe nicht leer ist: ```shell egrep --color 'vmx|svm' /proc/cpuinfo ``` -{{% /capture %}} -{{% capture steps %}} + + ## Einen Hypervisor installieren @@ -106,13 +107,6 @@ Schließen Sie nach der Installation von Minikube die aktuelle CLI-Sitzung und s So installieren Sie Minikube manuell unter Windows mit [Windows Installer](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal), laden Sie die Datei [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest) und führen Sie den Installer aus. -{{% /capture %}} - -{{% capture whatsnext %}} - -* [Kubernetes lokal über Minikube ausführen](/docs/setup/minikube/) - -{{% /capture %}} ## Eine bestehende Installation bereinigen @@ -130,3 +124,8 @@ Müssen Sie die Konfigurationsdateien löschen: ```shell rm -rf ~/.minikube ``` + +## {{% heading "whatsnext" %}} + + +* [Kubernetes lokal über Minikube ausführen](/docs/setup/minikube/) diff --git a/content/de/docs/tutorials/_index.md b/content/de/docs/tutorials/_index.md index 4cb042c124..1dcbbd8a63 100644 --- a/content/de/docs/tutorials/_index.md +++ b/content/de/docs/tutorials/_index.md @@ -2,19 +2,19 @@ title: Tutorials main_menu: true weight: 60 -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + Dieser Abschnitt der Kubernetes-Dokumentation enthält Tutorials. Ein Tutorial zeigt, wie Sie ein Ziel erreichen, das größer ist als eine einzelne [Aufgabe](/docs/tasks/). Ein Tutorial besteht normalerweise aus mehreren Abschnitten, die jeweils eine Abfolge von Schritten haben. Bevor Sie die einzelnen Lernprogramme durchgehen, möchten Sie möglicherweise ein Lesezeichen zur Seite mit dem [Standardisierten Glossar](/docs/reference/glossary/) setzen um später Informationen nachzuschlagen. -{{% /capture %}} -{{% capture body %}} + + ## Grundlagen @@ -64,12 +64,13 @@ Bevor Sie die einzelnen Lernprogramme durchgehen, möchten Sie möglicherweise e * [Source IP verwenden](/docs/tutorials/services/source-ip/) -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + Wenn Sie ein Tutorial schreiben möchten, lesen Sie [Seitenvorlagen verwenden](/docs/home/contribute/page-templates/) für weitere Informationen zum Typ der Tutorial-Seite und zur Tutorial-Vorlage. -{{% /capture %}} + diff --git a/content/de/docs/tutorials/hello-minikube.md b/content/de/docs/tutorials/hello-minikube.md index 4d0bc7f0f6..a1bf6dd493 100644 --- a/content/de/docs/tutorials/hello-minikube.md +++ b/content/de/docs/tutorials/hello-minikube.md @@ -1,6 +1,6 @@ --- title: Hallo Minikube -content_template: templates/tutorial +content_type: tutorial weight: 5 menu: main: @@ -13,7 +13,7 @@ card: weight: 10 --- -{{% capture overview %}} + Dieses Tutorial zeigt Ihnen, wie Sie eine einfache "Hallo Welt" Node.js-Anwendung auf Kubernetes mit [Minikube](/docs/getting-started-guides/minikube) und Katacoda ausführen. Katacoda bietet eine kostenlose Kubernetes-Umgebung im Browser. @@ -22,17 +22,19 @@ Katacoda bietet eine kostenlose Kubernetes-Umgebung im Browser. Sie können dieses Tutorial auch verwenden, wenn Sie [Minikube lokal](/docs/tasks/tools/install-minikube/) installiert haben. {{< /note >}} -{{% /capture %}} -{{% capture objectives %}} + +## {{% heading "objectives" %}} + * Stellen Sie eine Hallo-Welt-Anwendung für Minikube bereit. * Führen Sie die App aus. * Betrachten Sie die Log Dateien. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + Dieses Lernprogramm enthält ein aus den folgenden Dateien erstelltes Container-Image: @@ -42,9 +44,9 @@ Dieses Lernprogramm enthält ein aus den folgenden Dateien erstelltes Container- Weitere Informationen zum `docker build` Befehl, lesen Sie die [Docker Dokumentation](https://docs.docker.com/engine/reference/commandline/build/). -{{% /capture %}} -{{% capture lessoncontent %}} + + ## Erstellen Sie einen Minikube-Cluster @@ -260,12 +262,13 @@ Löschen Sie optional die Minikube-VM: minikube delete ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Lernen Sie mehr über [Bereitstellungsobjekte](/docs/concepts/workloads/controllers/deployment/). * Lernen Sie mehr über [Anwendungen bereitstellen](/docs/user-guide/deploying-applications/). * Lernen Sie mehr über [Serviceobjekte](/docs/concepts/services-networking/service/). -{{% /capture %}} + diff --git a/content/en/_index.html b/content/en/_index.html index f389669d03..97e02aa259 100644 --- a/content/en/_index.html +++ b/content/en/_index.html @@ -3,7 +3,6 @@ title: "Production-Grade Container Orchestration" abstract: "Automated container deployment, scaling, and management" cid: home --- -{{< deprecationwarning >}} {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}} diff --git a/content/en/blog/_posts/2017-01-00-Running-Mongodb-On-Kubernetes-With-Statefulsets.md b/content/en/blog/_posts/2017-01-00-Running-Mongodb-On-Kubernetes-With-Statefulsets.md index f07860212a..6682d54df1 100644 --- a/content/en/blog/_posts/2017-01-00-Running-Mongodb-On-Kubernetes-With-Statefulsets.md +++ b/content/en/blog/_posts/2017-01-00-Running-Mongodb-On-Kubernetes-With-Statefulsets.md @@ -4,70 +4,49 @@ date: 2017-01-30 slug: running-mongodb-on-kubernetes-with-statefulsets url: /blog/2017/01/Running-Mongodb-On-Kubernetes-With-Statefulsets --- -_Editor's note: Today’s post is by Sandeep Dinesh, Developer Advocate, Google Cloud Platform, showing how to run a database in a container._ +_Editor's note: Today’s post is by Sandeep Dinesh, Developer Advocate, Google Cloud Platform, showing how to run a database in a container._ +{{% warning %}} +This post is several years old. The code examples need changes to work on a current Kubernetes cluster. +{{% /warning %}} -Conventional wisdom says you can’t run a database in a container. “Containers are stateless!” they say, and “databases are pointless without state!” +Conventional wisdom says you can’t run a database in a container. “Containers are stateless!” they say, and “databases are pointless without state!” Of course, this is not true at all. At Google, everything runs in a container, including databases. You just need the right tools. [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/) includes the new [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/) API object (in previous versions, StatefulSet was known as PetSet). With StatefulSets, Kubernetes makes it much easier to run stateful workloads such as databases. -If you’ve followed my previous posts, you know how to create a [MEAN Stack app with Docker](http://blog.sandeepdinesh.com/2015/07/running-mean-web-application-in-docker.html), then [migrate it to Kubernetes](https://medium.com/google-cloud/running-a-mean-stack-on-google-cloud-platform-with-kubernetes-149ca81c2b5d) to provide easier management and reliability, and [create a MongoDB replica set](https://medium.com/google-cloud/mongodb-replica-sets-with-kubernetes-d96606bd9474) to provide redundancy and high availability. +If you’ve followed my previous posts, you know how to create a [MEAN Stack app with Docker](http://blog.sandeepdinesh.com/2015/07/running-mean-web-application-in-docker.html), then [migrate it to Kubernetes](https://medium.com/google-cloud/running-a-mean-stack-on-google-cloud-platform-with-kubernetes-149ca81c2b5d) to provide easier management and reliability, and [create a MongoDB replica set](https://medium.com/google-cloud/mongodb-replica-sets-with-kubernetes-d96606bd9474) to provide redundancy and high availability. -While the replica set in my previous blog post worked, there were some annoying steps that you needed to follow. You had to manually create a disk, a ReplicationController, and a service for each replica. Scaling the set up and down meant managing all of these resources manually, which is an opportunity for error, and would put your stateful application at risk In the previous example, we created a Makefile to ease the management of these resources, but it would have been great if Kubernetes could just take care of all of this for us. - -With StatefulSets, these headaches finally go away. You can create and manage your MongoDB replica set natively in Kubernetes, without the need for scripts and Makefiles. Let’s take a look how. - -_Note: StatefulSets are currently a beta resource. The [sidecar container](https://github.com/cvallance/mongo-k8s-sidecar) used for auto-configuration is also unsupported._ +While the replica set in my previous blog post worked, there were some annoying steps that you needed to follow. You had to manually create a disk, a ReplicationController, and a service for each replica. Scaling the set up and down meant managing all of these resources manually, which is an opportunity for error, and would put your stateful application at risk In the previous example, we created a Makefile to ease the management of these resources, but it would have been great if Kubernetes could just take care of all of this for us. +With StatefulSets, these headaches finally go away. You can create and manage your MongoDB replica set natively in Kubernetes, without the need for scripts and Makefiles. Let’s take a look how. +_Note: StatefulSets are currently a beta resource. The [sidecar container](https://github.com/cvallance/mongo-k8s-sidecar) used for auto-configuration is also unsupported._ **Prerequisites and Setup** - - Before we get started, you’ll need a Kubernetes 1.5+ and the [Kubernetes command line tool](/docs/user-guide/prereqs/). If you want to follow along with this tutorial and use Google Cloud Platform, you also need the [Google Cloud SDK](http://cloud.google.com/sdk). - - Once you have a [Google Cloud project created](https://console.cloud.google.com/projectcreate) and have your Google Cloud SDK setup (hint: gcloud init), we can create our cluster. - - -To create a Kubernetes 1.5 cluster, run the following command: - +To create a Kubernetes 1.5 cluster, run the following command: ``` gcloud container clusters create "test-cluster" ``` - - -This will make a three node Kubernetes cluster. Feel free to [customize the command](https://cloud.google.com/sdk/gcloud/reference/container/clusters/create) as you see fit. +This will make a three node Kubernetes cluster. Feel free to [customize the command](https://cloud.google.com/sdk/gcloud/reference/container/clusters/create) as you see fit. Then, authenticate into the cluster: - - ``` gcloud container clusters get-credentials test-cluster ``` - - - - - - **Setting up the MongoDB replica set** - - To set up the MongoDB replica set, you need three things: A [StorageClass](/docs/user-guide/persistent-volumes/#storageclasses), a [Headless Service](/docs/user-guide/services/#headless-services), and a [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/). - - -I’ve created the configuration files for these already, and you can clone the example from GitHub: - +I’ve created the configuration files for these already, and you can clone the example from GitHub: ``` git clone https://github.com/thesandlord/mongo-k8s-sidecar.git @@ -75,10 +54,7 @@ git clone https://github.com/thesandlord/mongo-k8s-sidecar.git cd /mongo-k8s-sidecar/example/StatefulSet/ ``` - - -To create the MongoDB replica set, run these two commands: - +To create the MongoDB replica set, run these two commands: ``` kubectl apply -f googlecloud\_ssd.yaml @@ -86,341 +62,202 @@ kubectl apply -f googlecloud\_ssd.yaml kubectl apply -f mongo-statefulset.yaml ``` - - That's it! With these two commands, you have launched all the components required to run an highly available and redundant MongoDB replica set. - - At an high level, it looks something like this: - - ![](https://lh4.googleusercontent.com/ohALxLD4Ugj5FCwWqgqZ4xP9al4lTgrPDc9HsgPWYRZRz_buuYK6LKSC7A5n98DdOO-Po3Zq77Yt43-QhTWdIaXqltHI7PX0zMXAXbpiilYgdowGZapG0lJ9lgubwBj1CwNHHtXA) - - Let’s examine each piece in more detail. - - **StorageClass** - - The storage class tells Kubernetes what kind of storage to use for the database nodes. You can set up many different types of StorageClasses in a ton of different environments. For example, if you run Kubernetes in your own datacenter, you can use [GlusterFS](https://www.gluster.org/). On GCP, your [storage choices](https://cloud.google.com/compute/docs/disks/) are SSDs and hard disks. There are currently drivers for [AWS](/docs/user-guide/persistent-volumes/#aws), [Azure](/docs/user-guide/persistent-volumes/#azure-disk), [Google Cloud](/docs/user-guide/persistent-volumes/#gce), [GlusterFS](/docs/user-guide/persistent-volumes/#glusterfs), [OpenStack Cinder](/docs/user-guide/persistent-volumes/#openstack-cinder), [vSphere](/docs/user-guide/persistent-volumes/#vsphere), [Ceph RBD](/docs/user-guide/persistent-volumes/#ceph-rbd), and [Quobyte](/docs/user-guide/persistent-volumes/#quobyte). +The configuration for the StorageClass looks like this: - -The configuration for the StorageClass looks like this: - - -``` -kind: StorageClass -apiVersion: storage.k8s.io/v1beta1 -metadata: - name: fast -provisioner: kubernetes.io/gce-pd -parameters: +```yaml +kind: StorageClass +apiVersion: storage.k8s.io/v1beta1 +metadata: + name: fast +provisioner: kubernetes.io/gce-pd +parameters: type: pd-ssd ``` - - This configuration creates a new StorageClass called “fast” that is backed by SSD volumes. The StatefulSet can now request a volume, and the StorageClass will automatically create it! - - -Deploy this StorageClass: - +Deploy this StorageClass: ``` kubectl apply -f googlecloud\_ssd.yaml ``` - - **Headless Service** - - Now you have created the Storage Class, you need to make a Headless Service. These are just like normal Kubernetes Services, except they don’t do any load balancing for you. When combined with StatefulSets, they can give you unique DNS addresses that let you directly access the pods! This is perfect for creating MongoDB replica sets, because our app needs to connect to all of the MongoDB nodes individually. +The configuration for the Headless Service looks like this: - -The configuration for the Headless Service looks like this: - - -``` +```yaml apiVersion: v1 - kind: Service - metadata: - - name: mongo - - labels: - - name: mongo - + name: mongo + labels: + name: mongo spec: - - ports: - - - port: 27017 - - targetPort: 27017 - - clusterIP: None - - selector: - - role: mongo + ports: + - port: 27017 + targetPort: 27017 + clusterIP: None + selector: + role: mongo ``` - - You can tell this is a Headless Service because the clusterIP is set to “None.” Other than that, it looks exactly the same as any normal Kubernetes Service. - - **StatefulSet** - - The pièce de résistance. The StatefulSet actually runs MongoDB and orchestrates everything together. StatefulSets differ from Kubernetes [ReplicaSets](/docs/user-guide/replicasets/) (not to be confused with MongoDB replica sets!) in certain ways that makes them more suited for stateful applications. Unlike Kubernetes ReplicaSets, pods created under a StatefulSet have a few unique attributes. The name of the pod is not random, instead each pod gets an ordinal name. Combined with the Headless Service, this allows pods to have stable identification. In addition, pods are created one at a time instead of all at once, which can help when bootstrapping a stateful system. You can read more about StatefulSets in the [documentation](/docs/concepts/abstractions/controllers/statefulsets/). - - Just like before, [this “sidecar” container](https://github.com/cvallance/mongo-k8s-sidecar) will configure the MongoDB replica set automatically. A “sidecar” is a helper container which helps the main container do its work. +The configuration for the StatefulSet looks like this: - -The configuration for the StatefulSet looks like this: - - -``` +```yaml apiVersion: apps/v1beta1 - kind: StatefulSet - metadata: - - name: mongo - + name: mongo spec: - - serviceName: "mongo" - - replicas: 3 - - template: - - metadata: - - labels: - - role: mongo - - environment: test - - spec: - - terminationGracePeriodSeconds: 10 - - containers: - - - name: mongo - - image: mongo - - command: - - - mongod - - - "--replSet" - - - rs0 - - - "--smallfiles" - - - "--noprealloc" - - ports: - - - containerPort: 27017 - - volumeMounts: - - - name: mongo-persistent-storage - - mountPath: /data/db - - - name: mongo-sidecar - - image: cvallance/mongo-k8s-sidecar - - env: - - - name: MONGO\_SIDECAR\_POD\_LABELS - - value: "role=mongo,environment=test" - - volumeClaimTemplates: - - - metadata: - - name: mongo-persistent-storage - - annotations: - - volume.beta.kubernetes.io/storage-class: "fast" - - spec: - - accessModes: ["ReadWriteOnce"] - - resources: - - requests: - - storage: 100Gi + selector: + matchLabels: + role: mongo + environment: test + serviceName: "mongo" + replicas: 3 + template: + metadata: + labels: + role: mongo + environment: test + spec: + terminationGracePeriodSeconds: 10 + containers: + - name: mongo + image: mongo + command: + - mongod + - "--replSet" + - rs0 + - "--smallfiles" + - "--noprealloc" + ports: + - containerPort: 27017 + volumeMounts: + - name: mongo-persistent-storage + mountPath: /data/db + - name: mongo-sidecar + image: cvallance/mongo-k8s-sidecar + env: + - name: MONGO_SIDECAR_POD_LABELS + value: "role=mongo,environment=test" + volumeClaimTemplates: + - metadata: + name: mongo-persistent-storage + spec: + storageClassName: "fast" + accessModes: ["ReadWriteOnce"] + resources: + requests: + storage: 100Gi ``` - - It’s a little long, but fairly straightforward. - - The first second describes the StatefulSet object. Then, we move into the Metadata section, where you can specify labels and the number of replicas. +Next comes the pod spec. The terminationGracePeriodSeconds is used to gracefully shutdown the pod when you scale down the number of replicas, which is important for databases! Then the configurations for the two containers is shown. The first one runs MongoDB with command line flags that configure the replica set name. It also mounts the persistent storage volume to /data/db, the location where MongoDB saves its data. The second container runs the sidecar. - -Next comes the pod spec. The terminationGracePeriodSeconds is used to gracefully shutdown the pod when you scale down the number of replicas, which is important for databases! Then the configurations for the two containers is shown. The first one runs MongoDB with command line flags that configure the replica set name. It also mounts the persistent storage volume to /data/db, the location where MongoDB saves its data. The second container runs the sidecar. - - - -Finally, there is the volumeClaimTemplates. This is what talks to the StorageClass we created before to provision the volume. It will provision a 100 GB disk for each MongoDB replica. - - +Finally, there is the volumeClaimTemplates. This is what talks to the StorageClass we created before to provision the volume. It will provision a 100 GB disk for each MongoDB replica. **Using the MongoDB replica set** - - -At this point, you should have three pods created in your cluster. These correspond to the three nodes in your MongoDB replica set. You can see them with this command: - +At this point, you should have three pods created in your cluster. These correspond to the three nodes in your MongoDB replica set. You can see them with this command: ``` kubectl get pods NAME READY STATUS RESTARTS AGE - mongo-0 2/2 Running 0 3m - mongo-1 2/2 Running 0 3m - mongo-2 2/2 Running 0 3m ``` +Each pod in a StatefulSet backed by a Headless Service will have a stable DNS name. The template follows this format: \.\ - -Each pod in a StatefulSet backed by a Headless Service will have a stable DNS name. The template follows this format: \.\ - -This means the DNS names for the MongoDB replica set are: - - +This means the DNS names for the MongoDB replica set are: ``` mongo-0.mongo - mongo-1.mongo - mongo-2.mongo ``` +You can use these names directly in the [connection string URI](http://docs.mongodb.com/manual/reference/connection-string) of your app. - -You can use these names directly in the [connection string URI](http://docs.mongodb.com/manual/reference/connection-string) of your app. - -In this case, the connection string URI would be: - +In this case, the connection string URI would be: ``` -“mongodb://mongo-0.mongo,mongo-1.mongo,mongo-2.mongo:27017/dbname\_?” +mongodb://mongo-0.mongo,mongo-1.mongo,mongo-2.mongo:27017/dbname\_? ``` +That’s it! -That’s it! - -**Scaling the MongoDB replica set** - -A huge advantage of StatefulSets is that you can scale them just like Kubernetes ReplicaSets. If you want 5 MongoDB Nodes instead of 3, just run the scale command: - +**Scaling the MongoDB replica set** +A huge advantage of StatefulSets is that you can scale them just like Kubernetes ReplicaSets. If you want 5 MongoDB Nodes instead of 3, just run the scale command: ``` kubectl scale --replicas=5 statefulset mongo ``` +The sidecar container will automatically configure the new MongoDB nodes to join the replica set. -The sidecar container will automatically configure the new MongoDB nodes to join the replica set. +Include the two new nodes (mongo-3.mongo & mongo-4.mongo) in your connection string URI and you are good to go. Too easy! -Include the two new nodes (mongo-3.mongo & mongo-4.mongo) in your connection string URI and you are good to go. Too easy! +**Cleaning Up** -**Cleaning Up** - -To clean up the deployed resources, delete the StatefulSet, Headless Service, and the provisioned volumes. - -Delete the StatefulSet: +To clean up the deployed resources, delete the StatefulSet, Headless Service, and the provisioned volumes. +Delete the StatefulSet: ``` kubectl delete statefulset mongo ``` - - -Delete the Service: - +Delete the Service: ``` kubectl delete svc mongo ``` - - -Delete the Volumes: - - - +Delete the Volumes: ``` kubectl delete pvc -l role=mongo ``` - - - -Finally, you can delete the test cluster: - - - +Finally, you can delete the test cluster: ``` gcloud container clusters delete "test-cluster" ``` - - Happy Hacking! - - For more cool Kubernetes and Container blog posts, follow me on [Twitter](https://twitter.com/sandeepdinesh) and [Medium](https://medium.com/@SandeepDinesh). - - _--Sandeep Dinesh, Developer Advocate, Google Cloud Platform._ diff --git a/content/en/blog/_posts/2018-03-26-kubernetes-1-10-stabilizing-storage-security-networking.md b/content/en/blog/_posts/2018-03-26-kubernetes-1-10-stabilizing-storage-security-networking.md index 2a84097979..922ec9f706 100644 --- a/content/en/blog/_posts/2018-03-26-kubernetes-1-10-stabilizing-storage-security-networking.md +++ b/content/en/blog/_posts/2018-03-26-kubernetes-1-10-stabilizing-storage-security-networking.md @@ -76,7 +76,7 @@ Each Special Interest Group (SIG) within the community continues to deliver the most-requested enhancements, fixes, and functionality for their respective specialty areas. For a complete list of inclusions by SIG, please visit the [release -notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.10.md#110-release-notes). +notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.10.md#110-release-notes). ## Availability diff --git a/content/en/blog/_posts/2020-06-15-better-docs-ux-with-docsy.md b/content/en/blog/_posts/2020-06-15-better-docs-ux-with-docsy.md new file mode 100644 index 0000000000..6fe469927e --- /dev/null +++ b/content/en/blog/_posts/2020-06-15-better-docs-ux-with-docsy.md @@ -0,0 +1,25 @@ +--- +layout: blog +title: A Better Docs UX With Docsy +date: 2020-06-15 +slug: better-docs-ux-with-docsy +url: /blog/2020/06/better-docs-ux-with-docsy +--- + +**Author:** Zach Corleissen, Cloud Native Computing Foundation + +*Editor's note: Zach is one of the chairs for the Kubernetes documentation special interest group (SIG Docs).* + +I'm pleased to announce that the [Kubernetes website](https://kubernetes.io) now features the [Docsy Hugo theme](https://docsy.dev). + +The Docsy theme improves the site's organization and navigability, and opens a path to improved API references. After over 4 years with few meaningful UX improvements, Docsy implements some best practices for technical content. The theme makes the Kubernetes site easier to read and makes individual pages easier to navigate. It gives the site a much-needed facelift. + +For example: adding a right-hand rail for navigating topics on the page. No more scrolling up to navigate! + +The theme opens a path for future improvements to the website. The Docsy functionality I'm most excited about is the theme's [`swaggerui` shortcode](https://www.docsy.dev/docs/adding-content/shortcodes/#swaggerui), which provides native support for generating API references from an OpenAPI spec. The CNCF is partnering with [Google Season of Docs](https://developers.google.com/season-of-docs) (GSoD) for staffing to make better API references a reality in Q4 this year. We're hopeful to be chosen, and we're looking forward to Google's list of announced projects on August 16th. Better API references have been a personal goal since I first started working with SIG Docs in 2017. It's exciting to see the goal within reach. + +One of SIG Docs' tech leads, [Karen Bradshaw](https://github.com/kbhawkey) did a lot of heavy lifting to fix a wide range of site compatibility issues, including a fix to the last of our [legacy pieces](https://github.com/kubernetes/website/pull/21359) when we [migrated from Jekyll to Hugo](2018-05-05-hugo-migration/) in 2018. Our other tech leads, [Tim Bannister](https://github.com/sftim) and [Taylor Dolezal](https://github.com/onlydole) provided extensive reviews. + +Thanks also to [Björn-Erik Pedersen](https://bep.is/), who provided invaluable advice about how to navigate a Hugo upgrade beyond [version 0.60.0](https://gohugo.io/news/0.60.0-relnotes/). + +The CNCF contracted with [Gearbox](https://gearboxbuilt.com/) in Victoria, BC to apply the theme to the site. Thanks to Aidan, Troy, and the rest of the team for all their work! \ No newline at end of file diff --git a/content/en/community/_index.html b/content/en/community/_index.html index 0f6fb9bc04..e1ebb9e9cb 100644 --- a/content/en/community/_index.html +++ b/content/en/community/_index.html @@ -17,7 +17,7 @@ cid: community
-
+
Code of conduct       Videos      diff --git a/content/en/docs/concepts/_index.md b/content/en/docs/concepts/_index.md index 0cb970fd66..1a61e3b28f 100644 --- a/content/en/docs/concepts/_index.md +++ b/content/en/docs/concepts/_index.md @@ -1,17 +1,17 @@ --- title: Concepts main_menu: true -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + The Concepts section helps you learn about the parts of the Kubernetes system and the abstractions Kubernetes uses to represent your {{< glossary_tooltip text="cluster" term_id="cluster" length="all" >}}, and helps you obtain a deeper understanding of how Kubernetes works. -{{% /capture %}} -{{% capture body %}} + + ## Overview @@ -41,7 +41,7 @@ Kubernetes also contains higher-level abstractions that rely on [controllers](/d * [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) * [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) * [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) -* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) +* [Job](/docs/concepts/workloads/controllers/job/) ## Kubernetes Control Plane @@ -60,12 +60,13 @@ The Kubernetes master is responsible for maintaining the desired state for your The nodes in a cluster are the machines (VMs, physical servers, etc) that run your applications and cloud workflows. The Kubernetes master controls each node; you'll rarely interact with nodes directly. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + If you would like to write a concept page, see -[Using Page Templates](/docs/home/contribute/page-templates/) -for information about the concept page type and the concept template. +[Page Content Types](/docs/home/contribute/style/page-content-types/#concept) +for information about the concept page types. + -{{% /capture %}} diff --git a/content/en/docs/concepts/architecture/cloud-controller.md b/content/en/docs/concepts/architecture/cloud-controller.md index 31c0ad9d54..9a731b684a 100644 --- a/content/en/docs/concepts/architecture/cloud-controller.md +++ b/content/en/docs/concepts/architecture/cloud-controller.md @@ -1,10 +1,10 @@ --- title: Cloud Controller Manager -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + {{< feature-state state="beta" for_k8s_version="v1.11" >}} @@ -17,9 +17,9 @@ components. The cloud-controller-manager is structured using a plugin mechanism that allows different cloud providers to integrate their platforms with Kubernetes. -{{% /capture %}} -{{% capture body %}} + + ## Design @@ -200,8 +200,9 @@ rules: - update ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + [Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager) has instructions on running and managing the cloud controller manager. @@ -212,4 +213,3 @@ The cloud controller manager uses Go interfaces to allow implementations from an The implementation of the shared controllers highlighted in this document (Node, Route, and Service), and some scaffolding along with the shared cloudprovider interface, is part of the Kubernetes core. Implementations specific to cloud providers are outside the core of Kubernetes and implement the `CloudProvider` interface. For more information about developing plugins, see [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/). -{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/concepts/architecture/control-plane-node-communication.md b/content/en/docs/concepts/architecture/control-plane-node-communication.md index 5e85302c38..925f14d17a 100644 --- a/content/en/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/en/docs/concepts/architecture/control-plane-node-communication.md @@ -3,22 +3,22 @@ reviewers: - dchen1107 - liggitt title: Control Plane-Node Communication -content_template: templates/concept +content_type: concept weight: 20 aliases: - master-node-communication --- -{{% capture overview %}} + This document catalogs the communication paths between the control plane (really the apiserver) and the Kubernetes cluster. The intent is to allow users to customize their installation to harden the network configuration such that the cluster can be run on an untrusted network (or on fully public IPs on a cloud provider). -{{% /capture %}} -{{% capture body %}} + + ## Node to Control Plane -All communication paths from the nodes to the control plane terminate at the apiserver (none of the other master components are designed to expose remote services). In a typical deployment, the apiserver is configured to listen for remote connections on a secure HTTPS port (443) with one or more forms of client [authentication](/docs/reference/access-authn-authz/authentication/) enabled. +Kubernetes has a "hub-and-spoke" API pattern. All API usage from nodes (or the pods they run) terminate at the apiserver (none of the other control plane components are designed to expose remote services). The apiserver is configured to listen for remote connections on a secure HTTPS port (typically 443) with one or more forms of client [authentication](/docs/reference/access-authn-authz/authentication/) enabled. One or more forms of [authorization](/docs/reference/access-authn-authz/authorization/) should be enabled, especially if [anonymous requests](/docs/reference/access-authn-authz/authentication/#anonymous-requests) or [service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens) are allowed. Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. For example, on a default GKE deployment, the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates. @@ -31,9 +31,11 @@ The control plane components also communicate with the cluster apiserver over th As a result, the default operating mode for connections from the nodes and pods running on the nodes to the control plane is secured by default and can run over untrusted and/or public networks. ## Control Plane to node + There are two primary communication paths from the control plane (apiserver) to the nodes. The first is from the apiserver to the kubelet process which runs on each node in the cluster. The second is from the apiserver to any node, pod, or service through the apiserver's proxy functionality. ### apiserver to kubelet + The connections from the apiserver to the kubelet are used for: * Fetching logs for pods. @@ -61,9 +63,10 @@ This tunnel ensures that the traffic is not exposed outside of the network in wh SSH tunnels are currently deprecated so you shouldn't opt to use them unless you know what you are doing. The Konnectivity service is a replacement for this communication channel. ### Konnectivity service + {{< feature-state for_k8s_version="v1.18" state="beta" >}} -As a replacement to the SSH tunnels, the Konnectivity service provides TCP level proxy for the control plane to Cluster communication. The Konnectivity consists of two parts, the Konnectivity server and the Konnectivity agents, running in the control plane network and the nodes network respectively. The Konnectivity agents initiate connections to the Konnectivity server and maintain the connections. -All control plane to nodes traffic then goes through these connections. +As a replacement to the SSH tunnels, the Konnectivity service provides TCP level proxy for the control plane to cluster communication. The Konnectivity service consists of two parts: the Konnectivity server and the Konnectivity agents, running in the control plane network and the nodes network respectively. The Konnectivity agents initiate connections to the Konnectivity server and maintain the network connections. +After enabling the Konnectivity service, all control plane to nodes traffic goes through these connections. -See [Konnectivity Service Setup](/docs/tasks/setup-konnectivity/) on how to set it up in your cluster. +Follow the [Konnectivity service task](/docs/tasks/extend-kubernetes/setup-konnectivity/) to set up the Konnectivity service in your cluster. diff --git a/content/en/docs/concepts/architecture/controller.md b/content/en/docs/concepts/architecture/controller.md index 2872959bac..547a624a94 100644 --- a/content/en/docs/concepts/architecture/controller.md +++ b/content/en/docs/concepts/architecture/controller.md @@ -1,10 +1,10 @@ --- title: Controllers -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + In robotics and automation, a _control loop_ is a non-terminating loop that regulates the state of a system. @@ -18,10 +18,10 @@ closer to the desired state, by turning equipment on or off. {{< glossary_definition term_id="controller" length="short">}} -{{% /capture %}} -{{% capture body %}} + + ## Controller pattern @@ -150,11 +150,12 @@ You can run your own controller as a set of Pods, or externally to Kubernetes. What fits best will depend on what that particular controller does. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Read about the [Kubernetes control plane](/docs/concepts/#kubernetes-control-plane) * Discover some of the basic [Kubernetes objects](/docs/concepts/#kubernetes-objects) * Learn more about the [Kubernetes API](/docs/concepts/overview/kubernetes-api/) * If you want to write your own controller, see [Extension Patterns](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) in Extending Kubernetes. -{{% /capture %}} + diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md index 32274f5a3b..516e4eb6d9 100644 --- a/content/en/docs/concepts/architecture/nodes.md +++ b/content/en/docs/concepts/architecture/nodes.md @@ -3,11 +3,11 @@ reviewers: - caesarxuchao - dchen1107 title: Nodes -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + Kubernetes runs your workload by placing containers into Pods to run on _Nodes_. A node may be a virtual or physical machine, depending on the cluster. Each node @@ -23,9 +23,9 @@ The [components](/docs/concepts/overview/components/#node-components) on a node {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}, and the {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}. -{{% /capture %}} -{{% capture body %}} + + ## Management @@ -332,12 +332,13 @@ the kubelet can use topology hints when making resource assignment decisions. See [Control Topology Management Policies on a Node](/docs/tasks/administer-cluster/topology-manager/) for more information. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn about the [components](/docs/concepts/overview/components/#node-components) that make up a node. * Read the [API definition for Node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core). * Read the [Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) section of the architecture design document. * Read about [taints and tolerations](/docs/concepts/configuration/taint-and-toleration/). * Read about [cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling). -{{% /capture %}} + diff --git a/content/en/docs/concepts/cluster-administration/addons.md b/content/en/docs/concepts/cluster-administration/addons.md index 0347327f13..5b5110ec92 100644 --- a/content/en/docs/concepts/cluster-administration/addons.md +++ b/content/en/docs/concepts/cluster-administration/addons.md @@ -1,9 +1,9 @@ --- title: Installing Addons -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + Add-ons extend the functionality of Kubernetes. @@ -12,10 +12,10 @@ This page lists some of the available add-ons and links to their respective inst Add-ons in each section are sorted alphabetically - the ordering does not imply any preferential status. -{{% /capture %}} -{{% capture body %}} + + ## Networking and Network Policy @@ -55,4 +55,4 @@ There are several other add-ons documented in the deprecated [cluster/addons](ht Well-maintained ones should be linked to here. PRs welcome! -{{% /capture %}} + diff --git a/content/en/docs/concepts/cluster-administration/certificates.md b/content/en/docs/concepts/cluster-administration/certificates.md index 052e7b9aa5..8cc45252ec 100644 --- a/content/en/docs/concepts/cluster-administration/certificates.md +++ b/content/en/docs/concepts/cluster-administration/certificates.md @@ -1,19 +1,19 @@ --- title: Certificates -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + When using client certificate authentication, you can generate certificates manually through `easyrsa`, `openssl` or `cfssl`. -{{% /capture %}} -{{% capture body %}} + + ### easyrsa @@ -249,4 +249,4 @@ You can use the `certificates.k8s.io` API to provision x509 certificates to use for authentication as documented [here](/docs/tasks/tls/managing-tls-in-a-cluster). -{{% /capture %}} + diff --git a/content/en/docs/concepts/cluster-administration/cloud-providers.md b/content/en/docs/concepts/cluster-administration/cloud-providers.md index 7d2f2a0b66..4f49e7bc42 100644 --- a/content/en/docs/concepts/cluster-administration/cloud-providers.md +++ b/content/en/docs/concepts/cluster-administration/cloud-providers.md @@ -1,16 +1,16 @@ --- title: Cloud Providers -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + This page explains how to manage Kubernetes running on a specific cloud provider. -{{% /capture %}} -{{% capture body %}} + + ### kubeadm [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) is a popular option for creating kubernetes clusters. kubeadm has configuration options to specify configuration information for cloud providers. For example a typical @@ -363,7 +363,7 @@ Kubernetes network plugin and should appear in the `[Route]` section of the [kubenet]: /docs/concepts/cluster-administration/network-plugins/#kubenet -{{% /capture %}} + ## OVirt diff --git a/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md index 5ba0bb30d8..fc2f55fbcd 100644 --- a/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -3,16 +3,16 @@ reviewers: - davidopp - lavalamp title: Cluster Administration Overview -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + The cluster administration overview is for anyone creating or administering a Kubernetes cluster. It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/). -{{% /capture %}} -{{% capture body %}} + + ## Planning a cluster See the guides in [Setup](/docs/setup/) for examples of how to plan, set up, and configure Kubernetes clusters. The solutions listed in this article are called *distros*. @@ -68,6 +68,6 @@ Note: Not all distros are actively maintained. Choose distros which have been te * [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/) explains how logging in Kubernetes works and how to implement it. -{{% /capture %}} + diff --git a/content/en/docs/concepts/cluster-administration/flow-control.md b/content/en/docs/concepts/cluster-administration/flow-control.md index aa6b0c0467..26fc1194df 100644 --- a/content/en/docs/concepts/cluster-administration/flow-control.md +++ b/content/en/docs/concepts/cluster-administration/flow-control.md @@ -1,10 +1,10 @@ --- title: API Priority and Fairness -content_template: templates/concept +content_type: concept min-kubernetes-server-version: v1.18 --- -{{% capture overview %}} + {{< feature-state state="alpha" for_k8s_version="v1.18" >}} @@ -33,9 +33,9 @@ the `--max-requests-inflight` flag without the API Priority and Fairness feature enabled. {{< /caution >}} -{{% /capture %}} -{{% capture body %}} + + ## Enabling API Priority and Fairness @@ -366,13 +366,13 @@ poorly-behaved workloads that may be harming system health. request and the PriorityLevel to which it was assigned. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + For background information on design details for API priority and fairness, see the [enhancement proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190228-priority-and-fairness.md). You can make suggestions and feature requests via [SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery). -{{% /capture %}} diff --git a/content/en/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/en/docs/concepts/cluster-administration/kubelet-garbage-collection.md index eb41a01cfe..1590561cc9 100644 --- a/content/en/docs/concepts/cluster-administration/kubelet-garbage-collection.md +++ b/content/en/docs/concepts/cluster-administration/kubelet-garbage-collection.md @@ -1,20 +1,20 @@ --- reviewers: title: Configuring kubelet Garbage Collection -content_template: templates/concept +content_type: concept weight: 70 --- -{{% capture overview %}} + Garbage collection is a helpful function of kubelet that will clean up unused images and unused containers. Kubelet will perform garbage collection for containers every minute and garbage collection for images every five minutes. External garbage collection tools are not recommended as these tools can potentially break the behavior of kubelet by removing containers expected to exist. -{{% /capture %}} -{{% capture body %}} + + ## Image Collection @@ -77,10 +77,11 @@ Including: | `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | eviction generalizes disk thresholds to other resources | | `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | eviction generalizes disk pressure transition to other resources | -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + See [Configuring Out Of Resource Handling](/docs/tasks/administer-cluster/out-of-resource/) for more details. -{{% /capture %}} + diff --git a/content/en/docs/concepts/cluster-administration/logging.md b/content/en/docs/concepts/cluster-administration/logging.md index e464a2869e..399f8f16cc 100644 --- a/content/en/docs/concepts/cluster-administration/logging.md +++ b/content/en/docs/concepts/cluster-administration/logging.md @@ -3,20 +3,20 @@ reviewers: - piosz - x13n title: Logging Architecture -content_template: templates/concept +content_type: concept weight: 60 --- -{{% capture overview %}} + Application and systems logs can help you understand what is happening inside your cluster. The logs are particularly useful for debugging problems and monitoring cluster activity. Most modern applications have some kind of logging mechanism; as such, most container engines are likewise designed to support some kind of logging. The easiest and most embraced logging method for containerized applications is to write to the standard output and standard error streams. However, the native functionality provided by a container engine or runtime is usually not enough for a complete logging solution. For example, if a container crashes, a pod is evicted, or a node dies, you'll usually still want to access your application's logs. As such, logs should have a separate storage and lifecycle independent of nodes, pods, or containers. This concept is called _cluster-level-logging_. Cluster-level logging requires a separate backend to store, analyze, and query logs. Kubernetes provides no native storage solution for log data, but you can integrate many existing logging solutions into your Kubernetes cluster. -{{% /capture %}} -{{% capture body %}} + + Cluster-level logging architectures are described in assumption that a logging backend is present inside or outside of your cluster. If you're @@ -267,4 +267,4 @@ You can implement cluster-level logging by exposing or pushing logs directly fro every application; however, the implementation for such a logging mechanism is outside the scope of Kubernetes. -{{% /capture %}} + diff --git a/content/en/docs/concepts/cluster-administration/manage-deployment.md b/content/en/docs/concepts/cluster-administration/manage-deployment.md index 6b246ec3b6..b052dd3a15 100644 --- a/content/en/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/en/docs/concepts/cluster-administration/manage-deployment.md @@ -2,18 +2,18 @@ reviewers: - janetkuo title: Managing Resources -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + You've deployed your application and exposed it via a service. Now what? Kubernetes provides a number of tools to help you manage your application deployment, including scaling and updating. Among the features that we will discuss in more depth are [configuration files](/docs/concepts/configuration/overview/) and [labels](/docs/concepts/overview/working-with-objects/labels/). -{{% /capture %}} -{{% capture body %}} + + ## Organizing resource configurations @@ -449,11 +449,12 @@ kubectl edit deployment/my-nginx That's it! The Deployment will declaratively update the deployed nginx application progressively behind the scene. It ensures that only a certain number of old replicas may be down while they are being updated, and only a certain number of new replicas may be created above the desired number of pods. To learn more details about it, visit [Deployment page](/docs/concepts/workloads/controllers/deployment/). -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + - Learn about [how to use `kubectl` for application introspection and debugging](/docs/tasks/debug-application-cluster/debug-application-introspection/). - See [Configuration Best Practices and Tips](/docs/concepts/configuration/overview/). -{{% /capture %}} + diff --git a/content/en/docs/concepts/cluster-administration/monitoring.md b/content/en/docs/concepts/cluster-administration/monitoring.md index e02ac8231c..fbea5e69c1 100644 --- a/content/en/docs/concepts/cluster-administration/monitoring.md +++ b/content/en/docs/concepts/cluster-administration/monitoring.md @@ -4,21 +4,21 @@ reviewers: - brancz - logicalhan - RainbowMango -content_template: templates/concept +content_type: concept weight: 60 aliases: - controller-metrics.md --- -{{% capture overview %}} + System component metrics can give a better look into what is happening inside them. Metrics are particularly useful for building dashboards and alerts. Metrics in Kubernetes control plane are emitted in [prometheus format](https://prometheus.io/docs/instrumenting/exposition_formats/) and are human readable. -{{% /capture %}} -{{% capture body %}} + + ## Metrics in Kubernetes @@ -124,10 +124,11 @@ cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"} cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Read about the [Prometheus text format](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) for metrics * See the list of [stable Kubernetes metrics](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml) * Read about the [Kubernetes deprecation policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior ) -{{% /capture %}} + diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md index c260963d87..29044be250 100644 --- a/content/en/docs/concepts/cluster-administration/networking.md +++ b/content/en/docs/concepts/cluster-administration/networking.md @@ -2,11 +2,11 @@ reviewers: - thockin title: Cluster Networking -content_template: templates/concept +content_type: concept weight: 50 --- -{{% capture overview %}} + Networking is a central part of Kubernetes, but it can be challenging to understand exactly how it is expected to work. There are 4 distinct networking problems to address: @@ -17,10 +17,10 @@ problems to address: 3. Pod-to-Service communications: this is covered by [services](/docs/concepts/services-networking/service/). 4. External-to-Service communications: this is covered by [services](/docs/concepts/services-networking/service/). -{{% /capture %}} -{{% capture body %}} + + Kubernetes is all about sharing machines between applications. Typically, sharing machines requires ensuring that two applications do not try to use the @@ -312,12 +312,13 @@ Weave Net runs as a [CNI plug-in](https://www.weave.works/docs/net/latest/cni-pl or stand-alone. In either version, it doesn't require any configuration or extra code to run, and in both cases, the network provides one IP address per pod - as is standard for Kubernetes. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + The early design of the networking model and its rationale, and some future plans are described in more detail in the [networking design document](https://git.k8s.io/community/contributors/design-proposals/network/networking.md). -{{% /capture %}} + diff --git a/content/en/docs/concepts/cluster-administration/proxies.md b/content/en/docs/concepts/cluster-administration/proxies.md index 8e03334d12..9bf204bd9f 100644 --- a/content/en/docs/concepts/cluster-administration/proxies.md +++ b/content/en/docs/concepts/cluster-administration/proxies.md @@ -1,14 +1,14 @@ --- title: Proxies in Kubernetes -content_template: templates/concept +content_type: concept weight: 90 --- -{{% capture overview %}} + This page explains proxies used with Kubernetes. -{{% /capture %}} -{{% capture body %}} + + ## Proxies @@ -62,6 +62,6 @@ will typically ensure that the latter types are setup correctly. Proxies have replaced redirect capabilities. Redirects have been deprecated. -{{% /capture %}} + diff --git a/content/en/docs/concepts/configuration/configmap.md b/content/en/docs/concepts/configuration/configmap.md index 92348f36b7..c6dd70ee19 100644 --- a/content/en/docs/concepts/configuration/configmap.md +++ b/content/en/docs/concepts/configuration/configmap.md @@ -1,23 +1,23 @@ --- title: ConfigMaps -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + {{< glossary_definition term_id="configmap" prepend="A ConfigMap is" length="all" >}} {{< caution >}} -ConfigMap does not provide secrecy or encryption. +ConfigMap does not provide secrecy or encryption. If the data you want to store are confidential, use a {{< glossary_tooltip text="Secret" term_id="secret" >}} rather than a ConfigMap, or use additional (third party) tools to keep your data private. {{< /caution >}} -{{% /capture %}} -{{% capture body %}} + + ## Motivation Use a ConfigMap for setting configuration data separately from application code. @@ -85,9 +85,9 @@ These different methods lend themselves to different ways of modeling the data being consumed. For the first three methods, the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} uses the data from -the Secret when it launches container(s) for a Pod. +the ConfigMap when it launches container(s) for a Pod. -The fourth method means you have to write code to read the Secret and its data. +The fourth method means you have to write code to read the ConfigMap and its data. However, because you're using the Kubernetes API directly, your application can subscribe to get updates whenever the ConfigMap changes, and react when that happens. By accessing the Kubernetes API directly, this @@ -243,12 +243,13 @@ Existing Pods maintain a mount point to the deleted ConfigMap - it is recommende these pods. {{< /note >}} -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Read about [Secrets](/docs/concepts/configuration/secret/). * Read [Configure a Pod to Use a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/). * Read [The Twelve-Factor App](https://12factor.net/) to understand the motivation for separating code from configuration. -{{% /capture %}} + diff --git a/content/en/docs/concepts/configuration/manage-resources-containers.md b/content/en/docs/concepts/configuration/manage-resources-containers.md index 69ea4a255d..f8989c4a5d 100644 --- a/content/en/docs/concepts/configuration/manage-resources-containers.md +++ b/content/en/docs/concepts/configuration/manage-resources-containers.md @@ -1,6 +1,6 @@ --- title: Managing Resources for Containers -content_template: templates/concept +content_type: concept weight: 40 feature: title: Automatic bin packing @@ -8,7 +8,7 @@ feature: Automatically places containers based on their resource requirements and other constraints, while not sacrificing availability. Mix critical and best-effort workloads in order to drive up utilization and save even more resources. --- -{{% capture overview %}} + When you specify a {{< glossary_tooltip term_id="pod" >}}, you can optionally specify how much of each resource a {{< glossary_tooltip text="Container" term_id="container" >}} needs. @@ -21,10 +21,10 @@ allowed to use more of that resource than the limit you set. The kubelet also re at least the _request_ amount of that system resource specifically for that container to use. -{{% /capture %}} -{{% capture body %}} + + ## Requests and limits @@ -740,10 +740,11 @@ You can see that the Container was terminated because of `reason:OOM Killed`, wh -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Get hands-on experience [assigning Memory resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/). @@ -758,4 +759,4 @@ You can see that the Container was terminated because of `reason:OOM Killed`, wh * Read about [project quotas](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) in XFS -{{% /capture %}} + diff --git a/content/en/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/en/docs/concepts/configuration/organize-cluster-access-kubeconfig.md index 480b708018..df767bbc3e 100644 --- a/content/en/docs/concepts/configuration/organize-cluster-access-kubeconfig.md +++ b/content/en/docs/concepts/configuration/organize-cluster-access-kubeconfig.md @@ -1,10 +1,10 @@ --- title: Organizing Cluster Access Using kubeconfig Files -content_template: templates/concept +content_type: concept weight: 60 --- -{{% capture overview %}} + Use kubeconfig files to organize information about clusters, users, namespaces, and authentication mechanisms. The `kubectl` command-line tool uses kubeconfig files to @@ -25,10 +25,10 @@ variable or by setting the For step-by-step instructions on creating and specifying kubeconfig files, see [Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters). -{{% /capture %}} -{{% capture body %}} + + ## Supporting multiple clusters, users, and authentication mechanisms @@ -143,14 +143,15 @@ File references on the command line are relative to the current working director In `$HOME/.kube/config`, relative paths are stored relatively, and absolute paths are stored absolutely. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) * [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config) -{{% /capture %}} + diff --git a/content/en/docs/concepts/configuration/overview.md b/content/en/docs/concepts/configuration/overview.md index b7b7b829db..332bdebe28 100644 --- a/content/en/docs/concepts/configuration/overview.md +++ b/content/en/docs/concepts/configuration/overview.md @@ -2,17 +2,17 @@ reviewers: - mikedanese title: Configuration Best Practices -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + This document highlights and consolidates configuration best practices that are introduced throughout the user guide, Getting Started documentation, and examples. This is a living document. If you think of something that is not on this list but might be useful to others, please don't hesitate to file an issue or submit a PR. -{{% /capture %}} -{{% capture body %}} + + ## General Configuration Tips - When defining configurations, specify the latest stable API version. @@ -34,7 +34,7 @@ This is a living document. If you think of something that is not on this list bu - Don't use naked Pods (that is, Pods not bound to a [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) or [Deployment](/docs/concepts/workloads/controllers/deployment/)) if you can avoid it. Naked Pods will not be rescheduled in the event of a node failure. - A Deployment, which both creates a ReplicaSet to ensure that the desired number of Pods is always available, and specifies a strategy to replace Pods (such as [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), is almost always preferable to creating Pods directly, except for some explicit [`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) scenarios. A [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) may also be appropriate. + A Deployment, which both creates a ReplicaSet to ensure that the desired number of Pods is always available, and specifies a strategy to replace Pods (such as [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), is almost always preferable to creating Pods directly, except for some explicit [`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) scenarios. A [Job](/docs/concepts/workloads/controllers/job/) may also be appropriate. ## Services @@ -105,5 +105,5 @@ The caching semantics of the underlying image provider make even `imagePullPolic - Use `kubectl run` and `kubectl expose` to quickly create single-container Deployments and Services. See [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) for an example. -{{% /capture %}} + diff --git a/content/en/docs/concepts/configuration/pod-overhead.md b/content/en/docs/concepts/configuration/pod-overhead.md index 9661264820..7057383dac 100644 --- a/content/en/docs/concepts/configuration/pod-overhead.md +++ b/content/en/docs/concepts/configuration/pod-overhead.md @@ -4,11 +4,11 @@ reviewers: - egernst - tallclair title: Pod Overhead -content_template: templates/concept +content_type: concept weight: 50 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.18" state="beta" >}} @@ -19,10 +19,10 @@ _Pod Overhead_ is a feature for accounting for the resources consumed by the Pod on top of the container requests & limits. -{{% /capture %}} -{{% capture body %}} + + In Kubernetes, the Pod's overhead is set at [admission](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) @@ -188,11 +188,12 @@ running with a defined Overhead. This functionality is not available in the 1.9 kube-state-metrics, but is expected in a following release. Users will need to build kube-state-metrics from source in the meantime. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [RuntimeClass](/docs/concepts/containers/runtime-class/) * [PodOverhead Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) -{{% /capture %}} + diff --git a/content/en/docs/concepts/configuration/pod-priority-preemption.md b/content/en/docs/concepts/configuration/pod-priority-preemption.md index c9bddd7e3e..9bfc514257 100644 --- a/content/en/docs/concepts/configuration/pod-priority-preemption.md +++ b/content/en/docs/concepts/configuration/pod-priority-preemption.md @@ -3,11 +3,11 @@ reviewers: - davidopp - wojtek-t title: Pod Priority and Preemption -content_template: templates/concept +content_type: concept weight: 70 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.14" state="stable" >}} @@ -16,9 +16,9 @@ importance of a Pod relative to other Pods. If a Pod cannot be scheduled, the scheduler tries to preempt (evict) lower priority Pods to make scheduling of the pending Pod possible. -{{% /capture %}} -{{% capture body %}} + + {{< warning >}} @@ -407,7 +407,8 @@ usage does not exceed their requests. If a Pod with lower priority is not exceeding its requests, it won't be evicted. Another Pod with higher priority that exceeds its requests may be evicted. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Read about using ResourceQuotas in connection with PriorityClasses: [limit Priority Class consumption by default](/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default) -{{% /capture %}} + diff --git a/content/en/docs/concepts/configuration/resource-bin-packing.md b/content/en/docs/concepts/configuration/resource-bin-packing.md index 0d475791ce..08a99de201 100644 --- a/content/en/docs/concepts/configuration/resource-bin-packing.md +++ b/content/en/docs/concepts/configuration/resource-bin-packing.md @@ -4,19 +4,19 @@ reviewers: - k82cn - ahg-g title: Resource Bin Packing for Extended Resources -content_template: templates/concept +content_type: concept weight: 50 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.16" state="alpha" >}} The kube-scheduler can be configured to enable bin packing of resources along with extended resources using `RequestedToCapacityRatioResourceAllocation` priority function. Priority functions can be used to fine-tune the kube-scheduler as per custom needs. -{{% /capture %}} -{{% capture body %}} + + ## Enabling Bin Packing using RequestedToCapacityRatioResourceAllocation @@ -132,23 +132,23 @@ CPU: 1 Node Score: intel.com/foo = resourceScoringFunction((2+1),4) - = (100 - ((4-3)*100/4) - = (100 - 25) - = 75 - = rawScoringFunction(75) - = 7 + = (100 - ((4-3)*100/4) + = (100 - 25) + = 75 # requested + used = 75% * available + = rawScoringFunction(75) + = 7 # floor(75/10) Memory = resourceScoringFunction((256+256),1024) = (100 -((1024-512)*100/1024)) - = 50 + = 50 # requested + used = 50% * available = rawScoringFunction(50) - = 5 + = 5 # floor(50/10) CPU = resourceScoringFunction((2+1),8) = (100 -((8-3)*100/8)) - = 37.5 + = 37.5 # requested + used = 37.5% * available = rawScoringFunction(37.5) - = 3 + = 3 # floor(37.5/10) NodeScore = (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3) = 5 @@ -194,4 +194,4 @@ NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3) ``` -{{% /capture %}} + diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md index d6c898ae9c..5c553b5cc6 100644 --- a/content/en/docs/concepts/configuration/secret.md +++ b/content/en/docs/concepts/configuration/secret.md @@ -2,7 +2,7 @@ reviewers: - mikedanese title: Secrets -content_template: templates/concept +content_type: concept feature: title: Secret and configuration management description: > @@ -10,16 +10,16 @@ feature: weight: 30 --- -{{% capture overview %}} + Kubernetes Secrets let you store and manage sensitive information, such as passwords, OAuth tokens, and ssh keys. Storing confidential information in a Secret is safer and more flexible than putting it verbatim in a {{< glossary_tooltip term_id="pod" >}} definition or in a {{< glossary_tooltip text="container image" term_id="image" >}}. See [Secrets design document](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md) for more information. -{{% /capture %}} -{{% capture body %}} + + ## Overview of Secrets @@ -29,12 +29,13 @@ Pod specification or in an image. Users can create secrets and the system also creates some secrets. To use a secret, a Pod needs to reference the secret. -A secret can be used with a Pod in two ways: +A secret can be used with a Pod in three ways: -- As files in a +- As [files](#using-secrets-as-files-from-a-pod) in a {{< glossary_tooltip text="volume" term_id="volume" >}} mounted on one or more of its containers. -- By the kubelet when pulling images for the Pod. +- As [container environment variable](#using-secrets-as-environment-variables). +- By the [kubelet when pulling images](#using-imagepullsecrets) for the Pod. ### Built-in Secrets diff --git a/content/en/docs/concepts/containers/container-environment.md b/content/en/docs/concepts/containers/container-environment.md index 86b595661d..a57ac2181a 100644 --- a/content/en/docs/concepts/containers/container-environment.md +++ b/content/en/docs/concepts/containers/container-environment.md @@ -3,18 +3,18 @@ reviewers: - mikedanese - thockin title: Container Environment -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + This page describes the resources available to Containers in the Container environment. -{{% /capture %}} -{{% capture body %}} + + ## Container environment @@ -53,12 +53,13 @@ FOO_SERVICE_PORT= Services have dedicated IP addresses and are available to the Container via DNS, if [DNS addon](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/) is enabled.  -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/). * Get hands-on experience [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). -{{% /capture %}} + diff --git a/content/en/docs/concepts/containers/container-lifecycle-hooks.md b/content/en/docs/concepts/containers/container-lifecycle-hooks.md index fe810d23c5..386e4d00bb 100644 --- a/content/en/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/en/docs/concepts/containers/container-lifecycle-hooks.md @@ -3,19 +3,19 @@ reviewers: - mikedanese - thockin title: Container Lifecycle Hooks -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + This page describes how kubelet managed Containers can use the Container lifecycle hook framework to run code triggered by events during their management lifecycle. -{{% /capture %}} -{{% capture body %}} + + ## Overview @@ -112,12 +112,13 @@ Events: 1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about the [Container environment](/docs/concepts/containers/container-environment/). * Get hands-on experience [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). -{{% /capture %}} + diff --git a/content/en/docs/concepts/containers/images.md b/content/en/docs/concepts/containers/images.md index 3d27355e3a..b271c36d02 100644 --- a/content/en/docs/concepts/containers/images.md +++ b/content/en/docs/concepts/containers/images.md @@ -3,24 +3,56 @@ reviewers: - erictune - thockin title: Images -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + -You create your Docker image and push it to a registry before referring to it in a Kubernetes pod. +A container image represents binary data that encapsulates an application and all its +software depencies. Container images are executable software bundles that can run +standalone and that make very well defined assumptions about their runtime environment. -The `image` property of a container supports the same syntax as the `docker` command does, including private registries and tags. +You typically create a container image of your application and push it to a registry +before referring to it in a +{{< glossary_tooltip text="Pod" term_id="pod" >}} -{{% /capture %}} +This page provides an outline of the container image concept. -{{% capture body %}} + + + +## Image names + +Container images are usually given a name such as `pause`, `example/mycontainer`, or `kube-apiserver`. +Images can also include a registry hostname; for example: `fictional.registry.example/imagename`, +and possible a port number as well; for example: `fictional.registry.example:10443/imagename`. + +If you don't specify a registry hostname, Kubernetes assumes that you mean the Docker public registry. + +After the image name part you can add a _tag_ (as also using with commands such +as `docker` and `podman`). +Tags let you identify different versions of the same series of images. + +Image tags consist of lowercase and uppercase letters, digits, underscores (`_`), +periods (`.`), and dashes (`-`). +There are additional rules about where you can place the separator +characters (`_`, `-`, and `.`) inside an image tag. +If you don't specify a tag, Kubernetes assumes you mean the tag `latest`. + +{{< caution >}} +You should avoid using the `latest` tag when deploying containers in production, +as it is harder to track which version of the image is running and more difficult +to roll back to a working version. + +Instead, specify a meaningful tag such as `v1.42.0`. +{{< /caution >}} ## Updating Images -The default pull policy is `IfNotPresent` which causes the Kubelet to skip +The default pull policy is `IfNotPresent` which causes the +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} to skip pulling an image if it already exists. If you would like to always force a pull, you can do one of the following: @@ -29,45 +61,16 @@ you can do one of the following: - omit the `imagePullPolicy` and the tag for the image to use. - enable the [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) admission controller. -Note that you should avoid using `:latest` tag, see [Best Practices for Configuration](/docs/concepts/configuration/overview/#container-images) for more information. +## Multi-architecture Images with Manifests -## Building Multi-architecture Images with Manifests +As well as providing binary images, a container registry can also server a [container image manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md). A manifest can reference image manifests for architecture-specific versions of an container. The idea is that you can have a name for an image (for example: `pause`, `example/mycontainer`, `kube-apiserver`) and allow different systems to fetch the right binary image for the machine architecture they are using. -Docker CLI now supports the following command `docker manifest` with sub commands like `create`, `annotate` and `push`. These commands can be used to build and push the manifests. You can use `docker manifest inspect` to view the manifest. - -Please see docker documentation here: -https://docs.docker.com/edge/engine/reference/commandline/manifest/ - -See examples on how we use this in our build harness: -https://cs.k8s.io/?q=docker%20manifest%20(create%7Cpush%7Cannotate)&i=nope&files=&repos= - -These commands rely on and are implemented purely on the Docker CLI. You will need to either edit the `$HOME/.docker/config.json` and set `experimental` key to `enabled` or you can just set `DOCKER_CLI_EXPERIMENTAL` environment variable to `enabled` when you call the CLI commands. - -{{< note >}} -Please use Docker *18.06 or above*, versions below that either have bugs or do not support the experimental command line option. Example https://github.com/docker/cli/issues/1135 causes problems under containerd. -{{< /note >}} - -If you run into trouble with uploading stale manifests, just clean up the older manifests in `$HOME/.docker/manifests` to start fresh. - -For Kubernetes, we have typically used images with suffix `-$(ARCH)`. For backward compatibility, please generate the older images with suffixes. The idea is to generate say `pause` image which has the manifest for all the arch(es) and say `pause-amd64` which is backwards compatible for older configurations or YAML files which may have hard coded the images with suffixes. +Kubernetes itself typically names container images with a suffix `-$(ARCH)`. For backward compatibility, please generate the older images with suffixes. The idea is to generate say `pause` image which has the manifest for all the arch(es) and say `pause-amd64` which is backwards compatible for older configurations or YAML files which may have hard coded the images with suffixes. ## Using a Private Registry -Private registries may require keys to read images from them. +Private registries may require keys to read images from them. Credentials can be provided in several ways: - - - Using Google Container Registry - - Per-cluster - - automatically configured on Google Compute Engine or Google Kubernetes Engine - - all pods can read the project's private registry - - Using Amazon Elastic Container Registry (ECR) - - use IAM roles and policies to control access to ECR repositories - - automatically refreshes ECR login credentials - - Using Oracle Cloud Infrastructure Registry (OCIR) - - use IAM roles and policies to control access to OCIR repositories - - Using Azure Container Registry (ACR) - - Using IBM Cloud Container Registry - - use IAM roles and policies to grant access to IBM Cloud Container Registry - Configuring Nodes to Authenticate to a Private Registry - all pods can read any configured private registries - requires node configuration by cluster administrator @@ -76,135 +79,59 @@ Credentials can be provided in several ways: - requires root access to all nodes to setup - Specifying ImagePullSecrets on a Pod - only pods which provide own keys can access the private registry + - Vendor-specific or local extensions + - if you're using a custom node configuration, you (or your cloud + provider) can implement your mechanism for authenticating the node + to the container registry. -Each option is described in more detail below. +These options are explaind in more detail below. +### Configuring Nodes to authenticate to a Private Registry -### Using Google Container Registry +If you run Docker on your nodes, you can configure the Docker container +runtuime to authenticate to a private container registry. -Kubernetes has native support for the [Google Container -Registry (GCR)](https://cloud.google.com/tools/container-registry/), when running on Google Compute -Engine (GCE). If you are running your cluster on GCE or Google Kubernetes Engine, simply -use the full image name (e.g. gcr.io/my_project/image:tag). - -All pods in a cluster will have read access to images in this registry. - -The kubelet will authenticate to GCR using the instance's -Google service account. The service account on the instance -will have a `https://www.googleapis.com/auth/devstorage.read_only`, -so it can pull from the project's GCR, but not push. - -### Using Amazon Elastic Container Registry - -Kubernetes has native support for the [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/), when nodes are AWS EC2 instances. - -Simply use the full image name (e.g. `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`) -in the Pod definition. - -All users of the cluster who can create pods will be able to run pods that use any of the -images in the ECR registry. - -The kubelet will fetch and periodically refresh ECR credentials. It needs the following permissions to do this: - -- `ecr:GetAuthorizationToken` -- `ecr:BatchCheckLayerAvailability` -- `ecr:GetDownloadUrlForLayer` -- `ecr:GetRepositoryPolicy` -- `ecr:DescribeRepositories` -- `ecr:ListImages` -- `ecr:BatchGetImage` - -Requirements: - -- You must be using kubelet version `v1.2.0` or newer. (e.g. run `/usr/bin/kubelet --version=true`). -- If your nodes are in region A and your registry is in a different region B, you need version `v1.3.0` or newer. -- ECR must be offered in your region - -Troubleshooting: - -- Verify all requirements above. -- Get $REGION (e.g. `us-west-2`) credentials on your workstation. SSH into the host and run Docker manually with those creds. Does it work? -- Verify kubelet is running with `--cloud-provider=aws`. -- Increase kubelet log level verbosity to at least 3 and check kubelet logs (e.g. `journalctl -u kubelet`) for log lines like: - - `aws_credentials.go:109] unable to get ECR credentials from cache, checking ECR API` - - `aws_credentials.go:116] Got ECR credentials from ECR API for .dkr.ecr..amazonaws.com` - -### Using Azure Container Registry (ACR) -When using [Azure Container Registry](https://azure.microsoft.com/en-us/services/container-registry/) -you can authenticate using either an admin user or a service principal. -In either case, authentication is done via standard Docker authentication. These instructions assume the -[azure-cli](https://github.com/azure/azure-cli) command line tool. - -You first need to create a registry and generate credentials, complete documentation for this can be found in -the [Azure container registry documentation](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-get-started-azure-cli). - -Once you have created your container registry, you will use the following credentials to login: - - * `DOCKER_USER` : service principal, or admin username - * `DOCKER_PASSWORD`: service principal password, or admin user password - * `DOCKER_REGISTRY_SERVER`: `${some-registry-name}.azurecr.io` - * `DOCKER_EMAIL`: `${some-email-address}` - -Once you have those variables filled in you can -[configure a Kubernetes Secret and use it to deploy a Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). - -### Using IBM Cloud Container Registry -IBM Cloud Container Registry provides a multi-tenant private image registry that you can use to safely store and share your images. By default, images in your private registry are scanned by the integrated Vulnerability Advisor to detect security issues and potential vulnerabilities. Users in your IBM Cloud account can access your images, or you can use IAM roles and policies to grant access to IBM Cloud Container Registry namespaces. - -To install the IBM Cloud Container Registry CLI plug-in and create a namespace for your images, see [Getting started with IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-started). - -If you are using the same account and region, you can deploy images that are stored in IBM Cloud Container Registry into the default namespace of your IBM Cloud Kubernetes Service cluster without any additional configuration, see [Building containers from images](https://cloud.ibm.com/docs/containers?topic=containers-images). For other configuration options, see [Understanding how to authorize your cluster to pull images from a registry](https://cloud.ibm.com/docs/containers?topic=containers-registry#cluster_registry_auth). - -### Configuring Nodes to Authenticate to a Private Registry +This approach is suitable if you can control node configuration. {{< note >}} -If you are running on Google Kubernetes Engine, there will already be a `.dockercfg` on each node with credentials for Google Container Registry. You cannot use this approach. -{{< /note >}} - -{{< note >}} -If you are running on AWS EC2 and are using the EC2 Container Registry (ECR), the kubelet on each node will -manage and update the ECR login credentials. You cannot use this approach. -{{< /note >}} - -{{< note >}} -This approach is suitable if you can control node configuration. It -will not work reliably on GCE, and any other cloud provider that does automatic -node replacement. -{{< /note >}} - -{{< note >}} -Kubernetes as of now only supports the `auths` and `HttpHeaders` section of docker config. This means credential helpers (`credHelpers` or `credsStore`) are not supported. +Kubernetes as only supports the `auths` and `HttpHeaders` section in Docker configuration. +Docker credential helpers (`credHelpers` or `credsStore`) are not supported. {{< /note >}} Docker stores keys for private registries in the `$HOME/.dockercfg` or `$HOME/.docker/config.json` file. If you put the same file in the search paths list below, kubelet uses it as the credential provider when pulling images. -* `{--root-dir:-/var/lib/kubelet}/config.json` -* `{cwd of kubelet}/config.json` -* `${HOME}/.docker/config.json` -* `/.docker/config.json` -* `{--root-dir:-/var/lib/kubelet}/.dockercfg` -* `{cwd of kubelet}/.dockercfg` -* `${HOME}/.dockercfg` -* `/.dockercfg` +* `{--root-dir:-/var/lib/kubelet}/config.json` +* `{cwd of kubelet}/config.json` +* `${HOME}/.docker/config.json` +* `/.docker/config.json` +* `{--root-dir:-/var/lib/kubelet}/.dockercfg` +* `{cwd of kubelet}/.dockercfg` +* `${HOME}/.dockercfg` +* `/.dockercfg` {{< note >}} -You may have to set `HOME=/root` explicitly in your environment file for kubelet. +You may have to set `HOME=/root` explicitly in the environment of the kubelet process. {{< /note >}} Here are the recommended steps to configuring your nodes to use a private registry. In this example, run these on your desktop/laptop: - 1. Run `docker login [server]` for each set of credentials you want to use. This updates `$HOME/.docker/config.json`. + 1. Run `docker login [server]` for each set of credentials you want to use. This updates `$HOME/.docker/config.json` on your PC. 1. View `$HOME/.docker/config.json` in an editor to ensure it contains just the credentials you want to use. - 1. Get a list of your nodes, for example: - - if you want the names: `nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')` - - if you want to get the IPs: `nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')` + 1. Get a list of your nodes; for example: + - if you want the names: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )` + - if you want to get the IP addresses: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )` 1. Copy your local `.docker/config.json` to one of the search paths list above. - - for example: `for n in $nodes; do scp ~/.docker/config.json root@$n:/var/lib/kubelet/config.json; done` + - for example, to test this out: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done` -Verify by creating a pod that uses a private image, e.g.: +{{< note >}} +For production clusers, use a configuration management tool so that you can apply this +setting to all the nodes where you need it. +{{< /note >}} + +Verify by creating a Pod that uses a private image; for example: ```shell kubectl apply -f - <}} -If you are running on Google Kubernetes Engine, there will already be a `.dockercfg` on each node with credentials for Google Container Registry. You cannot use this approach. -{{< /note >}} - {{< note >}} This approach is suitable if you can control node configuration. It -will not work reliably on GCE, and any other cloud provider that does automatic -node replacement. +will not work reliably if your cloud provider manages nodes and replaces +them automatically. {{< /note >}} -By default, the kubelet will try to pull each image from the specified registry. +By default, the kubelet tries to pull each image from the specified registry. However, if the `imagePullPolicy` property of the container is set to `IfNotPresent` or `Never`, then a local image is used (preferentially or exclusively, respectively). @@ -277,11 +200,11 @@ All pods will have read access to any pre-pulled images. ### Specifying ImagePullSecrets on a Pod {{< note >}} -This approach is currently the recommended approach for Google Kubernetes Engine, GCE, and any cloud-providers -where node creation is automated. +This is the recommended approach to run containers based on images +in private registries. {{< /note >}} -Kubernetes supports specifying registry keys on a pod. +Kubernetes supports specifying container image registry keys on a Pod. #### Creating a Secret with a Docker Config @@ -292,11 +215,13 @@ kubectl create secret docker-registry --docker-server=DOCKER_REGISTRY_SER ``` If you already have a Docker credentials file then, rather than using the above -command, you can import the credentials file as a Kubernetes secret. +command, you can import the credentials file as a Kubernetes +{{< glossary_tooltip text="Secrets" term_id="secret" >}}. [Create a Secret based on existing Docker credentials](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) explains how to set this up. + This is particularly useful if you are using multiple private container -registries, as `kubectl create secret docker-registry` creates a Secret that will -only work with a single private registry. +registries, as `kubectl create secret docker-registry` creates a Secret that +only works with a single private registry. {{< note >}} Pods can only reference image pull secrets in their own namespace, @@ -306,7 +231,9 @@ so this process needs to be done one time per namespace. #### Referring to an imagePullSecrets on a Pod Now, you can create pods which reference that secret by adding an `imagePullSecrets` -section to a pod definition. +section to a Pod definition. + +For example: ```shell cat < pod.yaml @@ -332,13 +259,14 @@ EOF This needs to be done for each pod that is using a private registry. However, setting of this field can be automated by setting the imagePullSecrets -in a [serviceAccount](/docs/user-guide/service-accounts) resource. +in a [ServiceAccount](/docs/user-guide/service-accounts) resource. + Check [Add ImagePullSecrets to a Service Account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) for detailed instructions. You can use this in conjunction with a per-node `.docker/config.json`. The credentials -will be merged. This approach will work on Google Kubernetes Engine. +will be merged. -### Use Cases +## Use Cases There are a number of solutions for configuring private registries. Here are some common use cases and suggested solutions. @@ -346,7 +274,7 @@ common use cases and suggested solutions. 1. Cluster running only non-proprietary (e.g. open-source) images. No need to hide images. - Use public images on the Docker hub. - No configuration required. - - On GCE/Google Kubernetes Engine, a local mirror is automatically used for improved speed and availability. + - Some cloud providers automatically cache or mirror public images, which improves availability and reduces the time to pull images. 1. Cluster running some proprietary images which should be hidden to those outside the company, but visible to all cluster users. - Use a hosted private [Docker registry](https://docs.docker.com/registry/). @@ -354,7 +282,7 @@ common use cases and suggested solutions. - Manually configure .docker/config.json on each node as described above. - Or, run an internal private registry behind your firewall with open read access. - No Kubernetes configuration is required. - - Or, when on GCE/Google Kubernetes Engine, use the project's Google Container Registry. + - Use a hosted container image registry service that controls image access - It will work better with cluster autoscaling than manual node configuration. - Or, on a cluster where changing the node configuration is inconvenient, use `imagePullSecrets`. 1. Cluster with proprietary images, a few of which require stricter access control. @@ -370,4 +298,6 @@ common use cases and suggested solutions. If you need access to multiple registries, you can create one secret for each registry. Kubelet will merge any `imagePullSecrets` into a single virtual `.docker/config.json` -{{% /capture %}} +## {{% heading "whatsnext" %}} + +* Read the [OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/master/manifest.md) diff --git a/content/en/docs/concepts/containers/overview.md b/content/en/docs/concepts/containers/overview.md index 49162710d7..1d996b8b93 100644 --- a/content/en/docs/concepts/containers/overview.md +++ b/content/en/docs/concepts/containers/overview.md @@ -3,11 +3,11 @@ reviewers: - erictune - thockin title: Containers overview -content_template: templates/concept +content_type: concept weight: 1 --- -{{% capture overview %}} + Containers are a technology for packaging the (compiled) code for an application along with the dependencies it needs at run time. Each @@ -18,10 +18,10 @@ run it. Containers decouple applications from underlying host infrastructure. This makes deployment easier in different cloud or OS environments. -{{% /capture %}} -{{% capture body %}} + + ## Container images A [container image](/docs/concepts/containers/images/) is a ready-to-run @@ -38,8 +38,9 @@ the change, then recreate the container to start from the updated image. {{< glossary_definition term_id="container-runtime" length="all" >}} -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Read about [container images](/docs/concepts/containers/images/) * Read about [Pods](/docs/concepts/workloads/pods/) -{{% /capture %}} + diff --git a/content/en/docs/concepts/containers/runtime-class.md b/content/en/docs/concepts/containers/runtime-class.md index dca6f2d0a8..d1857f3807 100644 --- a/content/en/docs/concepts/containers/runtime-class.md +++ b/content/en/docs/concepts/containers/runtime-class.md @@ -3,11 +3,11 @@ reviewers: - tallclair - dchen1107 title: Runtime Class -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.14" state="beta" >}} @@ -16,10 +16,10 @@ This page describes the RuntimeClass resource and runtime selection mechanism. RuntimeClass is a feature for selecting the container runtime configuration. The container runtime configuration is used to run a Pod's containers. -{{% /capture %}} -{{% capture body %}} + + ## Motivation @@ -180,12 +180,13 @@ Pod overhead is defined in RuntimeClass through the `overhead` fields. Through t you can specify the overhead of running pods utilizing this RuntimeClass and ensure these overheads are accounted for in Kubernetes. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + - [RuntimeClass Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) - [RuntimeClass Scheduling Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md) - Read about the [Pod Overhead](/docs/concepts/configuration/pod-overhead/) concept - [PodOverhead Feature Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) -{{% /capture %}} + diff --git a/content/en/docs/concepts/example-concept-template.md b/content/en/docs/concepts/example-concept-template.md index 26ce263ef4..adf3741f90 100644 --- a/content/en/docs/concepts/example-concept-template.md +++ b/content/en/docs/concepts/example-concept-template.md @@ -2,11 +2,11 @@ title: Example Concept Template reviewers: - chenopis -content_template: templates/concept +content_type: concept toc_hide: true --- -{{% capture overview %}} + {{< note >}} Be sure to also [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) for your new document. @@ -14,9 +14,9 @@ Be sure to also [create an entry in the table of contents](/docs/home/contribute This page explains ... -{{% /capture %}} -{{% capture body %}} + + ## Understanding ... @@ -26,15 +26,16 @@ Kubernetes provides ... To use ... -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + **[Optional Section]** -* Learn more about [Writing a New Topic](/docs/home/contribute/write-new-topic/). -* See [Using Page Templates - Concept template](/docs/home/contribute/page-templates/#concept_template) for how to use this template. - -{{% /capture %}} +* Learn more about [Writing a New Topic](/docs/home/contribute/style/write-new-topic/). +* See [Page Content Types - Concept](/docs/home/contribute/style/page-concept-types/#concept). + + diff --git a/content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md index 8bc6e22861..1f47323301 100644 --- a/content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md +++ b/content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -4,20 +4,20 @@ reviewers: - lavalamp - cheftako - chenopis -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + The aggregation layer allows Kubernetes to be extended with additional APIs, beyond what is offered by the core Kubernetes APIs. The additional APIs can either be ready-made solutions such as [service-catalog](/docs/concepts/extend-kubernetes/service-catalog/), or APIs that you develop yourself. The aggregation layer is different from [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/), which are a way to make the {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} recognise new kinds of object. -{{% /capture %}} -{{% capture body %}} + + ## Aggregation layer @@ -34,13 +34,14 @@ If your extension API server cannot achieve that latency requirement, consider m `EnableAggregatedDiscoveryTimeout=false` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on the kube-apiserver to disable the timeout restriction. This deprecated feature gate will be removed in a future release. -{{% /capture %}} -{{% capture whatsnext %}} -* To get the aggregator working in your environment, [configure the aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/). -* Then, [setup an extension api-server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) to work with the aggregation layer. -* Also, learn how to [extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/). +## {{% heading "whatsnext" %}} + + +* To get the aggregator working in your environment, [configure the aggregation layer](/docs/tasks/extend-kubernetes/configure-aggregation-layer/). +* Then, [setup an extension api-server](/docs/tasks/extend-kubernetes/setup-extension-api-server/) to work with the aggregation layer. +* Also, learn how to [extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/). * Read the specification for [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io) -{{% /capture %}} + diff --git a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index b1ca7f610a..f2ca2e2435 100644 --- a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -3,19 +3,19 @@ title: Custom Resources reviewers: - enisoc - deads2k -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + *Custom resources* are extensions of the Kubernetes API. This page discusses when to add a custom resource to your Kubernetes cluster and when to use a standalone service. It describes the two methods for adding custom resources and how to choose between them. -{{% /capture %}} -{{% capture body %}} + + ## Custom resources A *resource* is an endpoint in the [Kubernetes API](/docs/reference/using-api/api-overview/) that stores a collection of @@ -128,7 +128,7 @@ Regardless of how they are installed, the new resources are referred to as Custo ## CustomResourceDefinitions -The [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/) +The [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) API resource allows you to define custom resources. Defining a CRD object creates a new custom resource with a name and schema that you specify. The Kubernetes API serves and handles the storage of your custom resource. @@ -178,17 +178,17 @@ Aggregated APIs offer more advanced API features and customization of other feat | Feature | Description | CRDs | Aggregated API | | ------- | ----------- | ---- | -------------- | -| Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Yes. Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation). Any other validations supported by addition of a [Validating Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9). | Yes, arbitrary validation checks | -| Defaulting | See above | Yes, either via [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting) `default` keyword (GA in 1.17), or via a [Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) (though this will not be run when reading from etcd for old objects). | Yes | -| Multi-versioning | Allows serving the same object through two API versions. Can help ease API changes like renaming fields. Less important if you control your client versions. | [Yes](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning) | Yes | +| Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Yes. Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/extend-api-custom-resource-definitions/#validation). Any other validations supported by addition of a [Validating Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9). | Yes, arbitrary validation checks | +| Defaulting | See above | Yes, either via [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting) `default` keyword (GA in 1.17), or via a [Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) (though this will not be run when reading from etcd for old objects). | Yes | +| Multi-versioning | Allows serving the same object through two API versions. Can help ease API changes like renaming fields. Less important if you control your client versions. | [Yes](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning) | Yes | | Custom Storage | If you need storage with a different performance mode (for example, a time-series database instead of key-value store) or isolation for security (for example, encryption of sensitive information, etc.) | No | Yes | | Custom Business Logic | Perform arbitrary checks or actions when creating, reading, updating or deleting an object | Yes, using [Webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks). | Yes | -| Scale Subresource | Allows systems like HorizontalPodAutoscaler and PodDisruptionBudget interact with your new resource | [Yes](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#scale-subresource) | Yes | -| Status Subresource | Allows fine-grained access control where user writes the spec section and the controller writes the status section. Allows incrementing object Generation on custom resource data mutation (requires separate spec and status sections in the resource) | [Yes](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | Yes | +| Scale Subresource | Allows systems like HorizontalPodAutoscaler and PodDisruptionBudget interact with your new resource | [Yes](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource) | Yes | +| Status Subresource | Allows fine-grained access control where user writes the spec section and the controller writes the status section. Allows incrementing object Generation on custom resource data mutation (requires separate spec and status sections in the resource) | [Yes](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#status-subresource) | Yes | | Other Subresources | Add operations other than CRUD, such as "logs" or "exec". | No | Yes | | strategic-merge-patch | The new endpoints support PATCH with `Content-Type: application/strategic-merge-patch+json`. Useful for updating objects that may be modified both locally, and by the server. For more information, see ["Update API Objects in Place Using kubectl patch"](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/) | No | Yes | | Protocol Buffers | The new resource supports clients that want to use Protocol Buffers | No | Yes | -| OpenAPI Schema | Is there an OpenAPI (swagger) schema for the types that can be dynamically fetched from the server? Is the user protected from misspelling field names by ensuring only allowed fields are set? Are types enforced (in other words, don't put an `int` in a `string` field?) | Yes, based on the [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) schema (GA in 1.16). | Yes | +| OpenAPI Schema | Is there an OpenAPI (swagger) schema for the types that can be dynamically fetched from the server? Is the user protected from misspelling field names by ensuring only allowed fields are set? Are types enforced (in other words, don't put an `int` in a `string` field?) | Yes, based on the [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) schema (GA in 1.16). | Yes | ### Common Features @@ -246,12 +246,13 @@ When you add a custom resource, you can access it using: - A REST client that you write. - A client generated using [Kubernetes client generation tools](https://github.com/kubernetes/code-generator) (generating one is an advanced undertaking, but some projects may provide a client along with the CRD or AA). -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn how to [Extend the Kubernetes API with the aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/). -* Learn how to [Extend the Kubernetes API with CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/). +* Learn how to [Extend the Kubernetes API with CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/). + -{{% /capture %}} diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index 23f64628b5..d27dddd384 100644 --- a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -2,11 +2,11 @@ reviewers: title: Device Plugins description: Use the Kubernetes device plugin framework to implement plugins for GPUs, NICs, FPGAs, InfiniBand, and similar resources that require vendor-specific setup. -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.10" state="beta" >}} Kubernetes provides a [device plugin framework](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md) @@ -19,9 +19,9 @@ The targeted devices include GPUs, high-performance NICs, FPGAs, InfiniBand adap and other similar computing resources that may require vendor specific initialization and setup. -{{% /capture %}} -{{% capture body %}} + + ## Device plugin registration @@ -225,12 +225,13 @@ Here are some examples of device plugin implementations: * The [SR-IOV Network device plugin](https://github.com/intel/sriov-network-device-plugin) * The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) for Xilinx FPGA devices -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn about [scheduling GPU resources](/docs/tasks/manage-gpus/scheduling-gpus/) using device plugins * Learn about [advertising extended resources](/docs/tasks/administer-cluster/extended-resource-node/) on a node * Read about using [hardware acceleration for TLS ingress](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) with Kubernetes * Learn about the [Topology Manager] (/docs/tasks/adminster-cluster/topology-manager/) -{{% /capture %}} + diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md index 2ff4ae2377..b32bce83dd 100644 --- a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md +++ b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md @@ -4,12 +4,12 @@ reviewers: - freehan - thockin title: Network Plugins -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + {{< feature-state state="alpha" >}} {{< caution >}}Alpha features can change rapidly. {{< /caution >}} @@ -19,9 +19,9 @@ Network plugins in Kubernetes come in a few flavors: * CNI plugins: adhere to the appc/CNI specification, designed for interoperability. * Kubenet plugin: implements basic `cbr0` using the `bridge` and `host-local` CNI plugins -{{% /capture %}} -{{% capture body %}} + + ## Installation @@ -166,8 +166,9 @@ This option is provided to the network-plugin; currently **only kubenet supports * `--network-plugin=kubenet` specifies that we use the `kubenet` network plugin with CNI `bridge` and `host-local` plugins placed in `/opt/cni/bin` or `cni-bin-dir`. * `--network-plugin-mtu=9001` specifies the MTU to use, currently only used by the `kubenet` network plugin. -{{% /capture %}} -{{% capture whatsnext %}} -{{% /capture %}} +## {{% heading "whatsnext" %}} + + + diff --git a/content/en/docs/concepts/extend-kubernetes/extend-cluster.md b/content/en/docs/concepts/extend-kubernetes/extend-cluster.md index 2b5aa1b676..7914b1cab5 100644 --- a/content/en/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/en/docs/concepts/extend-kubernetes/extend-cluster.md @@ -5,11 +5,11 @@ reviewers: - lavalamp - cheftako - chenopis -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + Kubernetes is highly configurable and extensible. As a result, there is rarely a need to fork or submit patches to the Kubernetes @@ -22,10 +22,10 @@ their work environment. Developers who are prospective {{< glossary_tooltip text useful as an introduction to what extension points and patterns exist, and their trade-offs and limitations. -{{% /capture %}} -{{% capture body %}} + + ## Overview @@ -194,10 +194,11 @@ The scheduler also supports a that permits a webhook backend (scheduler extension) to filter and prioritize the nodes chosen for a pod. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [Custom Resources](/docs/concepts/api-extension/custom-resources/) * Learn about [Dynamic admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/) @@ -207,4 +208,4 @@ the nodes chosen for a pod. * Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) * Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/) -{{% /capture %}} + diff --git a/content/en/docs/concepts/extend-kubernetes/operator.md b/content/en/docs/concepts/extend-kubernetes/operator.md index eb56d5475a..dda8f0020b 100644 --- a/content/en/docs/concepts/extend-kubernetes/operator.md +++ b/content/en/docs/concepts/extend-kubernetes/operator.md @@ -1,20 +1,20 @@ --- title: Operator pattern -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + Operators are software extensions to Kubernetes that make use of [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) to manage applications and their components. Operators follow Kubernetes principles, notably the [control loop](/docs/concepts/#kubernetes-control-plane). -{{% /capture %}} -{{% capture body %}} + + ## Motivation @@ -113,9 +113,10 @@ Operator. You also implement an Operator (that is, a Controller) using any language / runtime that can act as a [client for the Kubernetes API](/docs/reference/using-api/client-libraries/). -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) * Find ready-made operators on [OperatorHub.io](https://operatorhub.io/) to suit your use case @@ -129,4 +130,3 @@ that can act as a [client for the Kubernetes API](/docs/reference/using-api/clie * Read [CoreOS' original article](https://coreos.com/blog/introducing-operators.html) that introduced the Operator pattern * Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building Operators -{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md b/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md index 4c5ab12c03..7f81439c41 100644 --- a/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md +++ b/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md @@ -1,18 +1,18 @@ --- title: Poseidon-Firmament Scheduler -content_template: templates/concept +content_type: concept weight: 80 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.6" state="alpha" >}} The Poseidon-Firmament scheduler is an alternate scheduler that can be deployed alongside the default Kubernetes scheduler. -{{% /capture %}} -{{% capture body %}} + + ## Introduction @@ -102,10 +102,11 @@ Pod-by-pod schedulers, such as the Kubernetes default scheduler, process Pods in These downsides of pod-by-pod schedulers are addressed by batching or bulk scheduling in Poseidon-Firmament scheduler. Processing several pods in a batch allows the scheduler to jointly consider their placement, and thus to find the best trade-off for the whole batch instead of one pod. At the same time it amortizes work across pods resulting in much higher throughput. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * See [Poseidon-Firmament](https://github.com/kubernetes-sigs/poseidon#readme) on GitHub for more information. * See the [design document](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/design/README.md) for Poseidon. * Read [Firmament: Fast, Centralized Cluster Scheduling at Scale](https://www.usenix.org/system/files/conference/osdi16/osdi16-gog.pdf), the academic paper on the Firmament scheduling design. * If you'd like to contribute to Poseidon-Firmament, refer to the [developer setup instructions](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/devel/README.md). -{{% /capture %}} + diff --git a/content/en/docs/concepts/extend-kubernetes/service-catalog.md b/content/en/docs/concepts/extend-kubernetes/service-catalog.md index 35d181d998..b40ca7ee14 100644 --- a/content/en/docs/concepts/extend-kubernetes/service-catalog.md +++ b/content/en/docs/concepts/extend-kubernetes/service-catalog.md @@ -2,11 +2,11 @@ title: Service Catalog reviewers: - chenopis -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + {{< glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" >}} A service broker, as defined by the [Open service broker API spec](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md), is an endpoint for a set of managed services offered and maintained by a third-party, which could be a cloud provider such as AWS, GCP, or Azure. @@ -14,10 +14,10 @@ Some examples of managed services are Microsoft Azure Cloud Queue, Amazon Simple Using Service Catalog, a {{< glossary_tooltip text="cluster operator" term_id="cluster-operator" >}} can browse the list of managed services offered by a service broker, provision an instance of a managed service, and bind with it to make it available to an application in the Kubernetes cluster. -{{% /capture %}} -{{% capture body %}} + + ## Example use case An {{< glossary_tooltip text="application developer" term_id="application-developer" >}} wants to use message queuing as part of their application running in a Kubernetes cluster. @@ -222,16 +222,17 @@ The following example describes how to map secret values into application enviro key: topic ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * If you are familiar with {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}, [install Service Catalog using Helm](/docs/tasks/service-catalog/install-service-catalog-using-helm/) into your Kubernetes cluster. Alternatively, you can [install Service Catalog using the SC tool](/docs/tasks/service-catalog/install-service-catalog-using-sc/). * View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers). * Explore the [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) project. * View [svc-cat.io](https://svc-cat.io/docs/). -{{% /capture %}} + diff --git a/content/en/docs/concepts/overview/components.md b/content/en/docs/concepts/overview/components.md index 04c4bbe805..f83f00683e 100644 --- a/content/en/docs/concepts/overview/components.md +++ b/content/en/docs/concepts/overview/components.md @@ -2,14 +2,14 @@ reviewers: - lavalamp title: Kubernetes Components -content_template: templates/concept +content_type: concept weight: 20 card: name: concepts weight: 20 --- -{{% capture overview %}} + When you deploy Kubernetes, you get a cluster. {{< glossary_definition term_id="cluster" length="all" prepend="A Kubernetes cluster consists of">}} @@ -20,9 +20,9 @@ Here's the diagram of a Kubernetes cluster with all the components tied together ![Components of Kubernetes](/images/docs/components-of-kubernetes.png) -{{% /capture %}} -{{% capture body %}} + + ## Control Plane Components The control plane's components make global decisions about the cluster (for example, scheduling), as well as detecting and responding to cluster events (for example, starting up a new {{< glossary_tooltip text="pod" term_id="pod">}} when a deployment's `replicas` field is unsatisfied). @@ -122,10 +122,11 @@ about containers in a central database, and provides a UI for browsing that data A [cluster-level logging](/docs/concepts/cluster-administration/logging/) mechanism is responsible for saving container logs to a central log store with search/browsing interface. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn about [Nodes](/docs/concepts/architecture/nodes/) * Learn about [Controllers](/docs/concepts/architecture/controller/) * Learn about [kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/) * Read etcd's official [documentation](https://etcd.io/docs/) -{{% /capture %}} + diff --git a/content/en/docs/concepts/overview/kubernetes-api.md b/content/en/docs/concepts/overview/kubernetes-api.md index bbdef84958..dd69fb6ccb 100644 --- a/content/en/docs/concepts/overview/kubernetes-api.md +++ b/content/en/docs/concepts/overview/kubernetes-api.md @@ -2,14 +2,14 @@ reviewers: - chenopis title: The Kubernetes API -content_template: templates/concept +content_type: concept weight: 30 card: name: concepts weight: 30 --- -{{% capture overview %}} + The core of Kubernetes' {{< glossary_tooltip text="control plane" term_id="control-plane" >}} is the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}. The API server @@ -21,9 +21,10 @@ The Kubernetes API lets you query and manipulate the state of objects in the Kub API endpoints, resource types and samples are described in the [API Reference](/docs/reference/kubernetes-api/). -{{% /capture %}} -{{% capture body %}} + + + ## API changes @@ -135,10 +136,10 @@ There are several API groups in a cluster: There are two paths to extending the API with [custom resources](/docs/concepts/api-extension/custom-resources/): -1. [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/) +1. [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) lets you declaratively define how the API server should provide your chosen resource API. -1. You can also [implement your own extension API server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) - and use the [aggregator](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) +1. You can also [implement your own extension API server](/docs/tasks/extend-kubernetes/setup-extension-api-server/) + and use the [aggregator](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) to make it seamless for clients. ## Enabling or disabling API groups @@ -166,8 +167,9 @@ For example: to enable deployments and daemonsets, set Kubernetes stores its serialized state in terms of the API resources by writing them into {{< glossary_tooltip term_id="etcd" >}}. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + [Controlling API Access](/docs/reference/access-authn-authz/controlling-access/) describes how the cluster manages authentication and authorization for API access. @@ -176,5 +178,3 @@ Overall API conventions are described in the document. API endpoints, resource types and samples are described in the [API Reference](/docs/reference/kubernetes-api/). - -{{% /capture %}} diff --git a/content/en/docs/concepts/overview/what-is-kubernetes.md b/content/en/docs/concepts/overview/what-is-kubernetes.md index fbe74e4337..5b30c8e66e 100644 --- a/content/en/docs/concepts/overview/what-is-kubernetes.md +++ b/content/en/docs/concepts/overview/what-is-kubernetes.md @@ -5,18 +5,18 @@ reviewers: title: What is Kubernetes? description: > Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available. -content_template: templates/concept +content_type: concept weight: 10 card: name: concepts weight: 10 --- -{{% capture overview %}} + This page is an overview of Kubernetes. -{{% /capture %}} -{{% capture body %}} + + Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available. The name Kubernetes originates from Greek, meaning helmsman or pilot. Google open-sourced the Kubernetes project in 2014. Kubernetes combines [over 15 years of Google's experience](/blog/2015/04/borg-predecessor-to-kubernetes/) running production workloads at scale with best-of-breed ideas and practices from the community. @@ -86,9 +86,10 @@ Kubernetes: * Does not provide nor adopt any comprehensive machine configuration, maintenance, management, or self-healing systems. * Additionally, Kubernetes is not a mere orchestration system. In fact, it eliminates the need for orchestration. The technical definition of orchestration is execution of a defined workflow: first do A, then B, then C. In contrast, Kubernetes comprises a set of independent, composable control processes that continuously drive the current state towards the provided desired state. It shouldn’t matter how you get from A to C. Centralized control is also not required. This results in a system that is easier to use and more powerful, robust, resilient, and extensible. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Take a look at the [Kubernetes Components](/docs/concepts/overview/components/) * Ready to [Get Started](/docs/setup/)? -{{% /capture %}} + diff --git a/content/en/docs/concepts/overview/working-with-objects/annotations.md b/content/en/docs/concepts/overview/working-with-objects/annotations.md index f88c6a0003..d440d2965e 100644 --- a/content/en/docs/concepts/overview/working-with-objects/annotations.md +++ b/content/en/docs/concepts/overview/working-with-objects/annotations.md @@ -1,15 +1,15 @@ --- title: Annotations -content_template: templates/concept +content_type: concept weight: 50 --- -{{% capture overview %}} + You can use Kubernetes annotations to attach arbitrary non-identifying metadata to objects. Clients such as tools and libraries can retrieve this metadata. -{{% /capture %}} -{{% capture body %}} + + ## Attaching metadata to objects You can use either labels or annotations to attach metadata to Kubernetes @@ -88,10 +88,11 @@ spec: ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + Learn more about [Labels and Selectors](/docs/concepts/overview/working-with-objects/labels/). -{{% /capture %}} + diff --git a/content/en/docs/concepts/overview/working-with-objects/common-labels.md b/content/en/docs/concepts/overview/working-with-objects/common-labels.md index d360d7d284..11e8944c8a 100644 --- a/content/en/docs/concepts/overview/working-with-objects/common-labels.md +++ b/content/en/docs/concepts/overview/working-with-objects/common-labels.md @@ -1,18 +1,18 @@ --- title: Recommended Labels -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + You can visualize and manage Kubernetes objects with more tools than kubectl and the dashboard. A common set of labels allows tools to work interoperably, describing objects in a common manner that all tools can understand. In addition to supporting tooling, the recommended labels describe applications in a way that can be queried. -{{% /capture %}} -{{% capture body %}} + + The metadata is organized around the concept of an _application_. Kubernetes is not a platform as a service (PaaS) and doesn't have or enforce a formal notion of an application. Instead, applications are informal and described with metadata. The definition of @@ -170,4 +170,4 @@ metadata: With the MySQL `StatefulSet` and `Service` you'll notice information about both MySQL and Wordpress, the broader application, are included. -{{% /capture %}} + diff --git a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md index b9df009db7..1f4f4e7509 100644 --- a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -1,17 +1,17 @@ --- title: Understanding Kubernetes Objects -content_template: templates/concept +content_type: concept weight: 10 card: name: concepts weight: 40 --- -{{% capture overview %}} + This page explains how Kubernetes objects are represented in the Kubernetes API, and how you can express them in `.yaml` format. -{{% /capture %}} -{{% capture body %}} + + ## Understanding Kubernetes objects {#kubernetes-objects} *Kubernetes objects* are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Specifically, they can describe: @@ -87,12 +87,13 @@ For example, the `spec` format for a Pod can be found in and the `spec` format for a Deployment can be found in [DeploymentSpec v1 apps](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps). -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [Kubernetes API overview](/docs/reference/using-api/api-overview/) explains some more API concepts * Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/pod-overview/). * Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes -{{% /capture %}} + diff --git a/content/en/docs/concepts/overview/working-with-objects/labels.md b/content/en/docs/concepts/overview/working-with-objects/labels.md index f08daf323b..e995db10a5 100644 --- a/content/en/docs/concepts/overview/working-with-objects/labels.md +++ b/content/en/docs/concepts/overview/working-with-objects/labels.md @@ -2,11 +2,11 @@ reviewers: - mikedanese title: Labels and Selectors -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + _Labels_ are key/value pairs that are attached to objects, such as pods. Labels are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users, but do not directly imply semantics to the core system. @@ -24,10 +24,10 @@ Each object can have a set of key/value labels defined. Each Key must be unique Labels allow for efficient queries and watches and are ideal for use in UIs and CLIs. Non-identifying information should be recorded using [annotations](/docs/concepts/overview/working-with-objects/annotations/). -{{% /capture %}} -{{% capture body %}} + + ## Motivation @@ -228,4 +228,4 @@ selector: One use case for selecting over labels is to constrain the set of nodes onto which a pod can schedule. See the documentation on [node selection](/docs/concepts/scheduling-eviction/assign-pod-node/) for more information. -{{% /capture %}} + diff --git a/content/en/docs/concepts/overview/working-with-objects/names.md b/content/en/docs/concepts/overview/working-with-objects/names.md index 01bb53b56d..9831f7335c 100644 --- a/content/en/docs/concepts/overview/working-with-objects/names.md +++ b/content/en/docs/concepts/overview/working-with-objects/names.md @@ -3,11 +3,11 @@ reviewers: - mikedanese - thockin title: Object Names and IDs -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + Each object in your cluster has a [_Name_](#names) that is unique for that type of resource. Every Kubernetes object also has a [_UID_](#uids) that is unique across your whole cluster. @@ -16,9 +16,9 @@ For example, you can only have one Pod named `myapp-1234` within the same [names For non-unique user-provided attributes, Kubernetes provides [labels](/docs/concepts/overview/working-with-objects/labels/) and [annotations](/docs/concepts/overview/working-with-objects/annotations/). -{{% /capture %}} -{{% capture body %}} + + ## Names @@ -81,8 +81,9 @@ Some resource types have additional restrictions on their names. Kubernetes UIDs are universally unique identifiers (also known as UUIDs). UUIDs are standardized as ISO/IEC 9834-8 and as ITU-T X.667. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Read about [labels](/docs/concepts/overview/working-with-objects/labels/) in Kubernetes. * See the [Identifiers and Names in Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) design document. -{{% /capture %}} + diff --git a/content/en/docs/concepts/overview/working-with-objects/namespaces.md b/content/en/docs/concepts/overview/working-with-objects/namespaces.md index 8d6e907afd..5e3acc5123 100644 --- a/content/en/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/en/docs/concepts/overview/working-with-objects/namespaces.md @@ -4,19 +4,19 @@ reviewers: - mikedanese - thockin title: Namespaces -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called namespaces. -{{% /capture %}} -{{% capture body %}} + + ## When to Use Multiple Namespaces @@ -58,12 +58,13 @@ kube-public Active 1d kube-system Active 1d ``` -Kubernetes starts with three initial namespaces: +Kubernetes starts with four initial namespaces: * `default` The default namespace for objects with no other namespace * `kube-system` The namespace for objects created by the Kubernetes system * `kube-public` This namespace is created automatically and is readable by all users (including those not authenticated). This namespace is mostly reserved for cluster usage, in case that some resources should be visible and readable publicly throughout the whole cluster. The public aspect of this namespace is only a convention, not a requirement. - + * `kube-node-lease` This namespace for the lease objects associated with each node which improves the performance of the node heartbeats as the cluster scales. + ### Setting the namespace for a request To set the namespace for a current request, use the `--namespace` flag. @@ -112,11 +113,12 @@ kubectl api-resources --namespaced=true kubectl api-resources --namespaced=false ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [creating a new namespace](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace). * Learn more about [deleting a namespace](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace). -{{% /capture %}} + diff --git a/content/en/docs/concepts/overview/working-with-objects/object-management.md b/content/en/docs/concepts/overview/working-with-objects/object-management.md index 288be6a684..97f57ff275 100644 --- a/content/en/docs/concepts/overview/working-with-objects/object-management.md +++ b/content/en/docs/concepts/overview/working-with-objects/object-management.md @@ -1,17 +1,17 @@ --- title: Kubernetes Object Management -content_template: templates/concept +content_type: concept weight: 15 --- -{{% capture overview %}} + The `kubectl` command-line tool supports several different ways to create and manage Kubernetes objects. This document provides an overview of the different approaches. Read the [Kubectl book](https://kubectl.docs.kubernetes.io) for details of managing objects by Kubectl. -{{% /capture %}} -{{% capture body %}} + + ## Management techniques @@ -173,9 +173,10 @@ Disadvantages compared to imperative object configuration: - Declarative object configuration is harder to debug and understand results when they are unexpected. - Partial updates using diffs create complex merge and patch operations. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + - [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/) - [Managing Kubernetes Objects Using Object Configuration (Imperative)](/docs/tasks/manage-kubernetes-objects/imperative-config/) @@ -185,4 +186,4 @@ Disadvantages compared to imperative object configuration: - [Kubectl Book](https://kubectl.docs.kubernetes.io) - [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) -{{% /capture %}} + diff --git a/content/en/docs/concepts/policy/limit-range.md b/content/en/docs/concepts/policy/limit-range.md index 8bea6c88e7..5b670d38a0 100644 --- a/content/en/docs/concepts/policy/limit-range.md +++ b/content/en/docs/concepts/policy/limit-range.md @@ -2,20 +2,20 @@ reviewers: - nelvadas title: Limit Ranges -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + By default, containers run with unbounded [compute resources](/docs/user-guide/compute-resources) on a Kubernetes cluster. With resource quotas, cluster administrators can restrict resource consumption and creation on a {{< glossary_tooltip text="namespace" term_id="namespace" >}} basis. Within a namespace, a Pod or Container can consume as much CPU and memory as defined by the namespace's resource quota. There is a concern that one Pod or Container could monopolize all available resources. A LimitRange is a policy to constrain resource allocations (to Pods or Containers) in a namespace. -{{% /capture %}} -{{% capture body %}} + + A _LimitRange_ provides constraints that can: @@ -26,9 +26,7 @@ A _LimitRange_ provides constraints that can: ## Enabling LimitRange -LimitRange support is enabled by default for many Kubernetes distributions. It is -enabled when the apiserver `--enable-admission-plugins=` flag has `LimitRanger` admission controller as -one of its arguments. +LimitRange support has been enabled by default since Kubernetes 1.10. A LimitRange is enforced in a particular namespace when there is a LimitRange object in that namespace. @@ -56,9 +54,10 @@ there may be contention for resources. In this case, the Containers or Pods will Neither contention nor changes to a LimitRange will affect already created resources. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + Refer to the [LimitRanger design document](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) for more information. @@ -72,4 +71,4 @@ For examples on using limits, see: - a [detailed example on configuring quota per namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/). -{{% /capture %}} + diff --git a/content/en/docs/concepts/policy/pod-security-policy.md b/content/en/docs/concepts/policy/pod-security-policy.md index 52aa593e6f..5a5241c42e 100644 --- a/content/en/docs/concepts/policy/pod-security-policy.md +++ b/content/en/docs/concepts/policy/pod-security-policy.md @@ -3,21 +3,21 @@ reviewers: - pweil- - tallclair title: Pod Security Policies -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + {{< feature-state state="beta" >}} Pod Security Policies enable fine-grained authorization of pod creation and updates. -{{% /capture %}} -{{% capture body %}} + + ## What is a Pod Security Policy? @@ -34,7 +34,7 @@ administrator to control the following: | Usage of host networking and ports | [`hostNetwork`, `hostPorts`](#host-namespaces) | | Usage of volume types | [`volumes`](#volumes-and-file-systems) | | Usage of the host filesystem | [`allowedHostPaths`](#volumes-and-file-systems) | -| White list of FlexVolume drivers | [`allowedFlexVolumes`](#flexvolume-drivers) | +| Allow specific FlexVolume drivers | [`allowedFlexVolumes`](#flexvolume-drivers) | | Allocating an FSGroup that owns the pod's volumes | [`fsGroup`](#volumes-and-file-systems) | | Requiring the use of a read only root file system | [`readOnlyRootFilesystem`](#volumes-and-file-systems) | | The user and group IDs of the container | [`runAsUser`, `runAsGroup`, `supplementalGroups`](#users-and-groups) | @@ -401,13 +401,13 @@ namespace. Doing so gives the pod access to the loopback device, services listening on localhost, and could be used to snoop on network activity of other pods on the same node. -**HostPorts** - Provides a whitelist of ranges of allowable ports in the host +**HostPorts** - Provides a list of ranges of allowable ports in the host network namespace. Defined as a list of `HostPortRange`, with `min`(inclusive) and `max`(inclusive). Defaults to no allowed host ports. ### Volumes and file systems -**Volumes** - Provides a whitelist of allowed volume types. The allowable values +**Volumes** - Provides a list of allowed volume types. The allowable values correspond to the volume sources that are defined when creating a volume. For the complete list of volume types, see [Types of Volumes](/docs/concepts/storage/volumes/#types-of-volumes). Additionally, `*` @@ -438,7 +438,7 @@ minimum value of the first range as the default. Validates against all ranges. all ranges if `FSGroups` is set. - *RunAsAny* - No default provided. Allows any `fsGroup` ID to be specified. -**AllowedHostPaths** - This specifies a whitelist of host paths that are allowed +**AllowedHostPaths** - This specifies a list of host paths that are allowed to be used by hostPath volumes. An empty list means there is no restriction on host paths used. This is defined as a list of objects with a single `pathPrefix` field, which allows hostPath volumes to mount a path that begins with an @@ -469,7 +469,7 @@ root filesystem (i.e. no writable layer). ### FlexVolume drivers -This specifies a whitelist of FlexVolume drivers that are allowed to be used +This specifies a list of FlexVolume drivers that are allowed to be used by flexvolume. An empty list or nil means there is no restriction on the drivers. Please make sure [`volumes`](#volumes-and-file-systems) field contains the `flexVolume` volume type; no FlexVolume driver is allowed otherwise. @@ -555,7 +555,7 @@ the PodSecurityPolicy. For more details on Linux capabilities, see The following fields take a list of capabilities, specified as the capability name in ALL_CAPS without the `CAP_` prefix. -**AllowedCapabilities** - Provides a whitelist of capabilities that may be added +**AllowedCapabilities** - Provides a list of capabilities that are allowed to be added to a container. The default set of capabilities are implicitly allowed. The empty set means that no additional capabilities may be added beyond the default set. `*` can be used to allow all capabilities. @@ -579,7 +579,7 @@ specified. ### AllowedProcMountTypes -`allowedProcMountTypes` is a whitelist of allowed ProcMountTypes. +`allowedProcMountTypes` is a list of allowed ProcMountTypes. Empty or nil indicates that only the `DefaultProcMountType` may be used. `DefaultProcMount` uses the container runtime defaults for readonly and masked @@ -631,12 +631,13 @@ By default, all safe sysctls are allowed. Refer to the [Sysctl documentation]( /docs/concepts/cluster-administration/sysctl-cluster/#podsecuritypolicy). -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + See [Pod Security Standards](/docs/concepts/security/pod-security-standards/) for policy recommendations. Refer to [Pod Security Policy Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) for the api details. -{{% /capture %}} + diff --git a/content/en/docs/concepts/policy/resource-quotas.md b/content/en/docs/concepts/policy/resource-quotas.md index 2c5f954327..1d2aaca499 100644 --- a/content/en/docs/concepts/policy/resource-quotas.md +++ b/content/en/docs/concepts/policy/resource-quotas.md @@ -2,21 +2,21 @@ reviewers: - derekwaynecarr title: Resource Quotas -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + When several users or teams share a cluster with a fixed number of nodes, there is a concern that one team could use more than its fair share of resources. Resource quotas are a tool for administrators to address this concern. -{{% /capture %}} -{{% capture body %}} + + A resource quota, defined by a `ResourceQuota` object, provides constraints that limit aggregate resource consumption per namespace. It can limit the quantity of objects that can @@ -595,10 +595,11 @@ See [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765) and See a [detailed example for how to use resource quota](/docs/tasks/administer-cluster/quota-api-object/). -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + See [ResourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) for more information. -{{% /capture %}} + diff --git a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md index 79a9487c60..a30efc6ef6 100644 --- a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -4,12 +4,12 @@ reviewers: - kevin-wangzefeng - bsalamat title: Assigning Pods to Nodes -content_template: templates/concept +content_type: concept weight: 50 --- -{{% capture overview %}} + You can constrain a {{< glossary_tooltip text="Pod" term_id="pod" >}} to only be able to run on particular {{< glossary_tooltip text="Node(s)" term_id="node" >}}, or to prefer to run on particular nodes. @@ -21,9 +21,9 @@ but there are some circumstances where you may want more control on a node where that a pod ends up on a machine with an SSD attached to it, or to co-locate pods from two different services that communicate a lot into the same availability zone. -{{% /capture %}} -{{% capture body %}} + + ## nodeSelector @@ -213,10 +213,8 @@ as at least one already-running pod that has a label with key "security" and val on node N if node N has a label with key `failure-domain.beta.kubernetes.io/zone` and some value V such that there is at least one node in the cluster with key `failure-domain.beta.kubernetes.io/zone` and value V that is running a pod that has a label with key "security" and value "S1".) The pod anti-affinity -rule says that the pod prefers not to be scheduled onto a node if that node is already running a pod with label -having key "security" and value "S2". (If the `topologyKey` were `failure-domain.beta.kubernetes.io/zone` then -it would mean that the pod cannot be scheduled onto a node if that node is in the same zone as a pod with -label having key "security" and value "S2".) See the +rule says that the pod cannot be scheduled onto a node if that node is in the same zone as a pod with +label having key "security" and value "S2". See the [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) for many more examples of pod affinity and anti-affinity, both the `requiredDuringSchedulingIgnoredDuringExecution` flavor and the `preferredDuringSchedulingIgnoredDuringExecution` flavor. @@ -388,9 +386,10 @@ spec: The above pod will run on the node kube-01. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + [Taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) allow a Node to *repel* a set of Pods. @@ -402,4 +401,4 @@ Once a Pod is assigned to a Node, the kubelet runs the Pod and allocates node-lo The [topology manager](/docs/tasks/administer-cluster/topology-manager/) can take part in node-level resource allocation decisions. -{{% /capture %}} + diff --git a/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md index 2fea98bfb4..406c3f974b 100644 --- a/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -1,18 +1,18 @@ --- title: Kubernetes Scheduler -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + In Kubernetes, _scheduling_ refers to making sure that {{< glossary_tooltip text="Pods" term_id="pod" >}} are matched to {{< glossary_tooltip text="Nodes" term_id="node" >}} so that {{< glossary_tooltip term_id="kubelet" >}} can run them. -{{% /capture %}} -{{% capture body %}} + + ## Scheduling overview {#scheduling} @@ -86,12 +86,13 @@ of the scheduler: `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit`, and others. You can also configure the kube-scheduler to run different profiles. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Read about [scheduler performance tuning](/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) * Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/) * Read the [reference documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for kube-scheduler * Learn about [configuring multiple schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/) * Learn about [topology management policies](/docs/tasks/administer-cluster/topology-manager/) * Learn about [Pod Overhead](/docs/concepts/configuration/pod-overhead/) -{{% /capture %}} + diff --git a/content/en/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/en/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index e3d4b16861..06f535a574 100644 --- a/content/en/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md +++ b/content/en/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -2,11 +2,11 @@ reviewers: - bsalamat title: Scheduler Performance Tuning -content_template: templates/concept +content_type: concept weight: 70 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.14" state="beta" >}} @@ -24,9 +24,9 @@ in a process called _Binding_. This page explains performance tuning optimizations that are relevant for large Kubernetes clusters. -{{% /capture %}} -{{% capture body %}} + + In large clusters, you can tune the scheduler's behaviour balancing scheduling outcomes between latency (new Pods are placed quickly) and @@ -164,4 +164,4 @@ Node 1, Node 5, Node 2, Node 6, Node 3, Node 4 After going over all the Nodes, it goes back to Node 1. -{{% /capture %}} + diff --git a/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md b/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md index d1123b72e1..5798b0579f 100644 --- a/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md +++ b/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md @@ -2,11 +2,11 @@ reviewers: - ahg-g title: Scheduling Framework -content_template: templates/concept +content_type: concept weight: 60 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.15" state="alpha" >}} @@ -20,9 +20,9 @@ framework. [kep]: https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20180409-scheduling-framework.md -{{% /capture %}} -{{% capture body %}} + + # Framework workflow @@ -239,4 +239,3 @@ If you are using Kubernetes v1.18 or later, you can configure a set of plugins a a scheduler profile and then define multiple profiles to fit various kinds of workload. Learn more at [multiple profiles](/docs/reference/scheduling/profiles/#multiple-profiles). -{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md index c803676d3a..97a190a280 100644 --- a/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -4,12 +4,12 @@ reviewers: - kevin-wangzefeng - bsalamat title: Taints and Tolerations -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + [_Node affinity_](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity), is a property of {{< glossary_tooltip text="Pods" term_id="pod" >}} that *attracts* them to a set of {{< glossary_tooltip text="nodes" term_id="node" >}} (either as a preference or a @@ -22,9 +22,9 @@ Taints and tolerations work together to ensure that pods are not scheduled onto inappropriate nodes. One or more taints are applied to a node; this marks that the node should not accept any pods that do not tolerate the taints. -{{% /capture %}} -{{% capture body %}} + + ## Concepts @@ -250,7 +250,7 @@ tolerations: Kubernetes automatically adds a toleration for `node.kubernetes.io/not-ready` and `node.kubernetes.io/unreachable` with `tolerationSeconds=300`, -unless you, or a controller, set those tolerations explictly. +unless you, or a controller, set those tolerations explicitly. These automatically-added tolerations mean that Pods remain bound to Nodes for 5 minutes after one of these problems is detected. @@ -282,9 +282,10 @@ tolerations to all daemons, to prevent DaemonSets from breaking. Adding these tolerations ensures backward compatibility. You can also add arbitrary tolerations to DaemonSets. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Read about [out of resource handling](/docs/tasks/administer-cluster/out-of-resource/) and how you can configure it * Read about [pod priority](/docs/concepts/configuration/pod-priority-preemption/) -{{% /capture %}} + diff --git a/content/en/docs/concepts/security/overview.md b/content/en/docs/concepts/security/overview.md index 20ba255039..98776c7199 100644 --- a/content/en/docs/concepts/security/overview.md +++ b/content/en/docs/concepts/security/overview.md @@ -2,60 +2,54 @@ reviewers: - zparnold title: Overview of Cloud Native Security -content_template: templates/concept -weight: 1 +content_type: concept +weight: 10 --- -{{< toc >}} + -{{% capture overview %}} -Kubernetes Security (and security in general) is an immense topic that has many -highly interrelated parts. In today's era where open source software is -integrated into many of the systems that help web applications run, -there are some overarching concepts that can help guide your intuition about how you can -think about security holistically. This guide will define a mental model -for some general concepts surrounding Cloud Native Security. The mental model is completely arbitrary -and you should only use it if it helps you think about where to secure your software -stack. -{{% /capture %}} +This overview defines a model for thinking about Kubernetes security in the context of Cloud Native security. -{{% capture body %}} +{{< warning >}} +This container security model provides suggestions, not proven information security policies. +{{< /warning >}} + + + +## The 4C's of Cloud Native security + +You can think about security in layers. The 4C's of Cloud Native security are Cloud, +Clusters, Containers, and Code. -## The 4C's of Cloud Native Security -Let's start with a diagram that may help you understand how you can think about security in layers. {{< note >}} This layered approach augments the [defense in depth](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)) -approach to security, which is widely regarded as a best practice for securing -software systems. The 4C's are Cloud, Clusters, Containers, and Code. +computing approach to security, which is widely regarded as a best practice for securing +software systems. {{< /note >}} {{< figure src="/images/docs/4c.png" title="The 4C's of Cloud Native Security" >}} - -As you can see from the above figure, -each one of the 4C's depend on the security of the squares in which they fit. It -is nearly impossibly to safeguard against poor security standards in Cloud, Containers, and Code -by only addressing security at the code level. However, when these areas are dealt -with appropriately, then adding security to your code augments an already strong -base. These areas of concern will now be described in more detail below. +Each layer of the Cloud Native security model builds upon the next outermost layer. +The Code layer benefits from strong base (Cloud, Cluster, Container) security layers. +You cannot safeguard against poor security standards in the base layers by addressing +security at the Code level. ## Cloud In many ways, the Cloud (or co-located servers, or the corporate datacenter) is the [trusted computing base](https://en.wikipedia.org/wiki/Trusted_computing_base) -of a Kubernetes cluster. If these components themselves are vulnerable (or -configured in a vulnerable way) then there's no real way to guarantee the security -of any components built on top of this base. Each cloud provider has extensive -security recommendations they make to their customers on how to run workloads securely -in their environment. It is out of the scope of this guide to give recommendations -on cloud security since every cloud provider and workload is different. Here are some -links to some of the popular cloud providers' documentation -for security as well as give general guidance for securing the infrastructure that -makes up a Kubernetes cluster. +of a Kubernetes cluster. If the Cloud layer is vulnerable (or +configured in a vulnerable way) then there is no guarantee that the components built +on top of this base are secure. Each cloud provider makes security recommendations +for running workloads securely in their environment. -### Cloud Provider Security Table +### Cloud provider security +If you are running a Kubernetes cluster on your own hardware or a different cloud provider, +consult your documentation for security best practices. +Here are links to some of the popular cloud providers' security documentation: +{{< table caption="Cloud provider security" >}} IaaS Provider | Link | -------------------- | ------------ | @@ -66,46 +60,48 @@ IBM Cloud | https://www.ibm.com/cloud/security | Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security | VMWare VSphere | https://www.vmware.com/security/hardening-guides.html | +{{< /table >}} -If you are running on your own hardware or a different cloud provider you will need to -consult your documentation for security best practices. +### Infrastructure security {#infrastructure-security} -### General Infrastructure Guidance Table +Suggestions for securing your infrastructure in a Kubernetes cluster: + +{{< table caption="Infrastructure security" >}} Area of Concern for Kubernetes Infrastructure | Recommendation | ---------------------------------------------- | ------------ | -Network access to API Server (Masters) | Ideally all access to the Kubernetes Masters is not allowed publicly on the internet and is controlled by network access control lists restricted to the set of IP addresses needed to administer the cluster.| -Network access to Nodes (Worker Servers) | Nodes should be configured to _only_ accept connections (via network access control lists) from the masters on the specified ports, and accept connections for services in Kubernetes of type NodePort and LoadBalancer. If possible, these nodes should not be exposed on the public internet entirely. -Kubernetes access to Cloud Provider API | Each cloud provider will need to grant a different set of permissions to the Kubernetes Masters and Nodes, so this recommendation will be more generic. It is best to provide the cluster with cloud provider access that follows the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) for the resources it needs to administer. An example for Kops in AWS can be found here: https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles -Access to etcd | Access to etcd (the datastore of Kubernetes) should be limited to the masters only. Depending on your configuration, you should also attempt to use etcd over TLS. More info can be found here: https://github.com/etcd-io/etcd/tree/master/Documentation#security +--------------------------------------------- | -------------- | +Network access to API Server (Control plane) | All access to the Kubernetes control plane is not allowed publicly on the internet and is controlled by network access control lists restricted to the set of IP addresses needed to administer the cluster.| +Network access to Nodes (nodes) | Nodes should be configured to _only_ accept connections (via network access control lists)from the control plane on the specified ports, and accept connections for services in Kubernetes of type NodePort and LoadBalancer. If possible, these nodes should not be exposed on the public internet entirely. +Kubernetes access to Cloud Provider API | Each cloud provider needs to grant a different set of permissions to the Kubernetes control plane and nodes. It is best to provide the cluster with cloud provider access that follows the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) for the resources it needs to administer. The [Kops documentation](https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles) provides information about IAM policies and roles. +Access to etcd | Access to etcd (the datastore of Kubernetes) should be limited to the control plane only. Depending on your configuration, you should attempt to use etcd over TLS. More information can be found in the [etcd documentation](https://github.com/etcd-io/etcd/tree/master/Documentation). etcd Encryption | Wherever possible it's a good practice to encrypt all drives at rest, but since etcd holds the state of the entire cluster (including Secrets) its disk should especially be encrypted at rest. +{{< /table >}} + ## Cluster -This section will provide links for securing -workloads in Kubernetes. There are two areas of concern for securing -Kubernetes: +There are two areas of concern for securing Kubernetes: -* Securing the components that are configurable which make up the cluster -* Securing the components which run in the cluster +* Securing the cluster components that are configurable +* Securing the applications which run in the cluster +### Components of the Cluster {#cluster-components} -### Components _of_ the Cluster - -If you want to protect your cluster from accidental or malicious access, and adopt +If you want to protect your cluster from accidental or malicious access and adopt good information practices, read and follow the advice about [securing your cluster](/docs/tasks/administer-cluster/securing-a-cluster/). -### Components _in_ the Cluster (your application) +### Components in the cluster (your application) {#cluster-applications} + Depending on the attack surface of your application, you may want to focus on specific -aspects of security. For example, if you are running a service (Service A) that is critical +aspects of security. For example: If you are running a service (Service A) that is critical in a chain of other resources and a separate workload (Service B) which is -vulnerable to a resource exhaustion attack, by not putting resource limits on -Service B you run the risk of also compromising Service A. Below is a table of -links of things to consider when securing workloads running in Kubernetes. +vulnerable to a resource exhaustion attack then the risk of compromising Service A +is high if you do not limit the resources of Service B. The following table lists +areas of security concerns and recommendations for securing workloads running in Kubernetes: Area of Concern for Workload Security | Recommendation | ------------------------------- | ------------ | +------------------------------ | --------------------- | RBAC Authorization (Access to the Kubernetes API) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/ Authentication | https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/ Application secrets management (and encrypting them in etcd at rest) | https://kubernetes.io/docs/concepts/configuration/secret/
https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ @@ -114,51 +110,45 @@ Quality of Service (and Cluster resource management) | https://kubernetes.io/doc Network Policies | https://kubernetes.io/docs/concepts/services-networking/network-policies/ TLS For Kubernetes Ingress | https://kubernetes.io/docs/concepts/services-networking/ingress/#tls - - ## Container -In order to run software in Kubernetes, it must be in a container. Because of this, -there are certain security considerations that must be taken into account in order -to benefit from the workload security primitives of Kubernetes. Container security -is also outside the scope of this guide, but here is a table of general -recommendations and links for further exploration of this topic. +Container security is outside the scope of this guide. Here are general recommendations and +links to explore this topic: Area of Concern for Containers | Recommendation | ------------------------------- | ------------ | -Container Vulnerability Scanning and OS Dependency Security | As part of an image build step or on a regular basis you should scan your containers for known vulnerabilities with a tool such as [CoreOS's Clair](https://github.com/coreos/clair/) -Image Signing and Enforcement | Two other CNCF Projects (TUF and Notary) are useful tools for signing container images and maintaining a system of trust for the content of your containers. If you use Docker, it is built in to the Docker Engine as [Docker Content Trust](https://docs.docker.com/engine/security/trust/content_trust/). On the enforcement piece, [IBM's Portieris](https://github.com/IBM/portieris) project is a tool that runs as a Kubernetes Dynamic Admission Controller to ensure that images are properly signed via Notary before being admitted to the Cluster. +------------------------------ | -------------- | +Container Vulnerability Scanning and OS Dependency Security | As part of an image build step, you should scan your containers for known vulnerabilities. +Image Signing and Enforcement | Sign container images to maintain a system of trust for the content of your containers. Disallow privileged users | When constructing containers, consult your documentation for how to create users inside of the containers that have the least level of operating system privilege necessary in order to carry out the goal of the container. ## Code -Finally moving down into the application code level, this is one of the primary attack -surfaces over which you have the most control. This is also outside of the scope -of Kubernetes but here are a few recommendations: +Application code is one of the primary attack surfaces over which you have the most control. +While securing application code is outside of the Kubernetes security topic, here +are recommendations to protect application code: -### General Code Security Guidance Table +### Code security + +{{< table caption="Code security" >}} Area of Concern for Code | Recommendation | ---------------------------------------------- | ------------ | -Access over TLS only | If your code needs to communicate via TCP, ideally it would be performing a TLS handshake with the client ahead of time. With the exception of a few cases, the default behavior should be to encrypt everything in transit. Going one step further, even "behind the firewall" in our VPC's it's still a good idea to encrypt network traffic between services. This can be done through a process known as mutual or [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication) which performs a two sided verification of communication between two certificate holding services. There are numerous tools that can be used to accomplish this in Kubernetes such as [Linkerd](https://linkerd.io/) and [Istio](https://istio.io/). | +-------------------------| -------------- | +Access over TLS only | If your code needs to communicate by TCP, perform a TLS handshake with the client ahead of time. With the exception of a few cases, encrypt everything in transit. Going one step further, it's a good idea to encrypt network traffic between services. This can be done through a process known as mutual or [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication) which performs a two sided verification of communication between two certificate holding services. | Limiting port ranges of communication | This recommendation may be a bit self-explanatory, but wherever possible you should only expose the ports on your service that are absolutely essential for communication or metric gathering. | -3rd Party Dependency Security | Since our applications tend to have dependencies outside of our own codebases, it is a good practice to regularly scan the code's dependencies to ensure that they are still secure with no vulnerabilities currently filed against them. Each language has a tool for performing this check automatically. | -Static Code Analysis | Most languages provide a way for a snippet of code to be analyzed for any potentially unsafe coding practices. Whenever possible you should perform checks using automated tooling that can scan codebases for common security errors. Some of the tools can be found here: https://owasp.org/www-community/Source_Code_Analysis_Tools | -Dynamic probing attacks | There are a few automated tools that are able to be run against your service to try some of the well known attacks that commonly befall services. These include SQL injection, CSRF, and XSS. One of the most popular dynamic analysis tools is the OWASP Zed Attack proxy https://owasp.org/www-project-zap/ | +3rd Party Dependency Security | It is a good practice to regularly scan your application's third party libraries for known security vulnerabilities. Each programming language has a tool for performing this check automatically. | +Static Code Analysis | Most languages provide a way for a snippet of code to be analyzed for any potentially unsafe coding practices. Whenever possible you should perform checks using automated tooling that can scan codebases for common security errors. Some of the tools can be found at: https://owasp.org/www-community/Source_Code_Analysis_Tools | +Dynamic probing attacks | There are a few automated tools that you can run against your service to try some of the well known service attacks. These include SQL injection, CSRF, and XSS. One of the most popular dynamic analysis tools is the [OWASP Zed Attack proxy](https://owasp.org/www-project-zap/) tool. | +{{< /table >}} -## Robust automation +## {{% heading "whatsnext" %}} -Most of the above mentioned suggestions can actually be automated in your code -delivery pipeline as part of a series of checks in security. To learn about a -more "Continuous Hacking" approach to software delivery, [this article](https://thenewstack.io/beyond-ci-cd-how-continuous-hacking-of-docker-containers-and-pipeline-driven-security-keeps-ygrene-secure/) provides more detail. +Learn about related Kubernetes security topics: -{{% /capture %}} -{{% capture whatsnext %}} -* Read about [network policies for Pods](/docs/concepts/services-networking/network-policies/) -* Read about [securing your cluster](/docs/tasks/administer-cluster/securing-a-cluster/) -* Read about [API access control](/docs/reference/access-authn-authz/controlling-access/) -* Read about [data encryption in transit](/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane -* Read about [data encryption at rest](/docs/tasks/administer-cluster/encrypt-data/) -* Read about [Secrets in Kubernetes](/docs/concepts/configuration/secret/) -{{% /capture %}} +* [Pod security standards](/docs/concepts/security/pod-security-standards/) +* [Network policies for Pods](/docs/concepts/services-networking/network-policies/) +* [Securing your cluster](/docs/tasks/administer-cluster/securing-a-cluster/) +* [API access control](/docs/reference/access-authn-authz/controlling-access/) +* [Data encryption in transit](/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane +* [Data encryption at rest](/docs/tasks/administer-cluster/encrypt-data/) +* [Secrets in Kubernetes](/docs/concepts/configuration/secret/) diff --git a/content/en/docs/concepts/security/pod-security-standards.md b/content/en/docs/concepts/security/pod-security-standards.md index ffe1aa45f2..2afd6c7335 100644 --- a/content/en/docs/concepts/security/pod-security-standards.md +++ b/content/en/docs/concepts/security/pod-security-standards.md @@ -2,11 +2,11 @@ reviewers: - tallclair title: Pod Security Standards -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + Security settings for Pods are typically applied by using [security contexts](/docs/tasks/configure-pod-container/security-context/). Security Contexts allow for the @@ -21,9 +21,9 @@ However, numerous means of policy enforcement have arisen that augment or replac PodSecurityPolicy. The intent of this page is to detail recommended Pod security profiles, decoupled from any specific instantiation. -{{% /capture %}} -{{% capture body %}} + + ## Policy Types @@ -43,9 +43,9 @@ should range from highly restricted to highly flexible: The Privileged policy is purposely-open, and entirely unrestricted. This type of policy is typically aimed at system- and infrastructure-level workloads managed by privileged, trusted users. -The privileged policy is defined by an absence of restrictions. For blacklist-oriented enforcement +The privileged policy is defined by an absence of restrictions. For allow-by-default enforcement mechanisms (such as gatekeeper), the privileged profile may be an absence of applied constraints -rather than an instantiated policy. In contrast, for a whitelist oriented mechanism (such as Pod +rather than an instantiated policy. In contrast, for a deny-by-default mechanism (such as Pod Security Policy) the privileged policy should enable all controls (disable all restrictions). ### Baseline/Default @@ -90,7 +90,7 @@ enforced/disallowed:
Restricted Fields:
spec.containers[*].securityContext.capabilities.add
spec.initContainers[*].securityContext.capabilities.add
-
Allowed Values: empty (optionally whitelisted defaults)
+
Allowed Values: empty (or restricted to a known list)
@@ -105,17 +105,17 @@ enforced/disallowed: Host Ports - HostPorts should be disallowed, or at minimum restricted to a whitelist.
+ HostPorts should be disallowed, or at minimum restricted to a known list.

Restricted Fields:
spec.containers[*].ports[*].hostPort
spec.initContainers[*].ports[*].hostPort
-
Allowed Values: 0, undefined, (whitelisted)
+
Allowed Values: 0, undefined (or restricted to a known list)
AppArmor (optional) - On supported hosts, the 'runtime/default' AppArmor profile is applied by default. The default policy should prevent overriding or disabling the policy, or restrict overrides to a whitelisted set of profiles.
+ On supported hosts, the 'runtime/default' AppArmor profile is applied by default. The default policy should prevent overriding or disabling the policy, or restrict overrides to an allowed set of profiles.

Restricted Fields:
metadata.annotations['container.apparmor.security.beta.kubernetes.io/*']

Allowed Values: 'runtime/default', undefined
@@ -145,7 +145,7 @@ enforced/disallowed: Sysctls - Sysctls can disable security mechanisms or affect all containers on a host, and should be disallowed except for a whitelisted "safe" subset. + Sysctls can disable security mechanisms or affect all containers on a host, and should be disallowed except for an allowed "safe" subset. A sysctl is considered safe if it is namespaced in the container or the Pod, and it is isolated from other Pods or processes on the same Node.

Restricted Fields:
spec.securityContext.sysctls
@@ -249,7 +249,7 @@ well as lower-trust users.The following listed controls should be enforced/disal Seccomp - The 'runtime/default' seccomp profile must be required, or allow additional whitelisted values.
+ The 'runtime/default' seccomp profile must be required, or allow specific additional profiles.

Restricted Fields:
metadata.annotations['seccomp.security.alpha.kubernetes.io/pod']
metadata.annotations['container.seccomp.security.alpha.kubernetes.io/*']
@@ -322,4 +322,4 @@ kernel. This allows for workloads requiring heightened permissions to still be i Additionally, the protection of sandboxed workloads is highly dependent on the method of sandboxing. As such, no single ‘recommended’ policy is recommended for all sandboxed workloads. -{{% /capture %}} + diff --git a/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md b/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md index 6f931a8531..d4218f38f6 100644 --- a/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md +++ b/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md @@ -3,29 +3,30 @@ reviewers: - rickypai - thockin title: Adding entries to Pod /etc/hosts with HostAliases -content_template: templates/concept +content_type: concept weight: 60 +min-kubernetes-server-version: 1.7 --- -{{< toc >}} -{{% capture overview %}} -Adding entries to a Pod's /etc/hosts file provides Pod-level override of hostname resolution when DNS and other options are not applicable. In 1.7, users can add these custom entries with the HostAliases field in PodSpec. + -Modification not using HostAliases is not suggested because the file is managed by Kubelet and can be overwritten on during Pod creation/restart. -{{% /capture %}} +Adding entries to a Pod's `/etc/hosts` file provides Pod-level override of hostname resolution when DNS and other options are not applicable. You can add these custom entries with the HostAliases field in PodSpec. -{{% capture body %}} +Modification not using HostAliases is not suggested because the file is managed by the kubelet and can be overwritten on during Pod creation/restart. -## Default Hosts File Content -Let's start an Nginx Pod which is assigned a Pod IP: + + +## Default hosts file content + +Start an Nginx Pod which is assigned a Pod IP: ```shell kubectl run nginx --image nginx --generator=run-pod/v1 ``` -```shell +``` pod/nginx created ``` @@ -35,7 +36,7 @@ Examine a Pod IP: kubectl get pods --output=wide ``` -```shell +``` NAME READY STATUS RESTARTS AGE IP NODE nginx 1/1 Running 0 13s 10.200.0.4 worker0 ``` @@ -46,7 +47,7 @@ The hosts file content would look like this: kubectl exec nginx -- cat /etc/hosts ``` -```none +``` # Kubernetes-managed hosts file. 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback @@ -60,43 +61,44 @@ fe00::2 ip6-allrouters By default, the `hosts` file only includes IPv4 and IPv6 boilerplates like `localhost` and its own hostname. -## Adding Additional Entries with HostAliases +## Adding additional entries with hostAliases -In addition to the default boilerplate, we can add additional entries to the -`hosts` file to resolve `foo.local`, `bar.local` to `127.0.0.1` and `foo.remote`, -`bar.remote` to `10.1.2.3`, we can by adding HostAliases to the Pod under +In addition to the default boilerplate, you can add additional entries to the +`hosts` file. +For example: to resolve `foo.local`, `bar.local` to `127.0.0.1` and `foo.remote`, +`bar.remote` to `10.1.2.3`, you can configure HostAliases for a Pod under `.spec.hostAliases`: {{< codenew file="service/networking/hostaliases-pod.yaml" >}} -This Pod can be started with the following commands: +Yoyu can start a Pod with that configuration by running: ```shell -kubectl apply -f hostaliases-pod.yaml +kubectl apply -f https://k8s.io/examples/service/networking/hostaliases-pod.yaml ``` -```shell +``` pod/hostaliases-pod created ``` -Examine a Pod IP and status: +Examine a Pod's details to see its IPv4 address and its status: ```shell kubectl get pod --output=wide ``` -```shell +``` NAME READY STATUS RESTARTS AGE IP NODE hostaliases-pod 0/1 Completed 0 6s 10.200.0.5 worker0 ``` -The `hosts` file content would look like this: +The `hosts` file content looks like this: ```shell kubectl logs hostaliases-pod ``` -```none +``` # Kubernetes-managed hosts file. 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback @@ -111,19 +113,18 @@ fe00::2 ip6-allrouters 10.1.2.3 foo.remote bar.remote ``` -With the additional entries specified at the bottom. +with the additional entries specified at the bottom. -## Why Does Kubelet Manage the Hosts File? +## Why does the kubelet manage the hosts file? {#why-does-kubelet-manage-the-hosts-file} -Kubelet [manages](https://github.com/kubernetes/kubernetes/issues/14633) the +The kubelet [manages](https://github.com/kubernetes/kubernetes/issues/14633) the `hosts` file for each container of the Pod to prevent Docker from [modifying](https://github.com/moby/moby/issues/17190) the file after the containers have already been started. -Because of the managed-nature of the file, any user-written content will be -overwritten whenever the `hosts` file is remounted by Kubelet in the event of -a container restart or a Pod reschedule. Thus, it is not suggested to modify -the contents of the file. - -{{% /capture %}} +{{< caution >}} +Avoid making manual changes to the hosts file inside a container. +If you make manual changes to the hosts file, +those changes are lost when the container exits. +{{< /caution >}} diff --git a/content/en/docs/concepts/services-networking/connect-applications-service.md b/content/en/docs/concepts/services-networking/connect-applications-service.md index 50c012ffc6..79c6053301 100644 --- a/content/en/docs/concepts/services-networking/connect-applications-service.md +++ b/content/en/docs/concepts/services-networking/connect-applications-service.md @@ -4,12 +4,12 @@ reviewers: - lavalamp - thockin title: Connecting Applications with Services -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + ## The Kubernetes model for connecting containers @@ -21,9 +21,9 @@ Coordinating port allocations across multiple developers or teams that provide c This guide uses a simple nginx server to demonstrate proof of concept. -{{% /capture %}} -{{% capture body %}} + + ## Exposing pods to the cluster @@ -394,8 +394,8 @@ kubectl edit svc my-nginx kubectl get svc my-nginx ``` ``` -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -my-nginx ClusterIP 10.0.162.149 162.222.184.144 80/TCP,81/TCP,82/TCP 21s +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +my-nginx LoadBalancer 10.0.162.149 xx.xxx.xxx.xxx 8080:30163/TCP 21s ``` ``` curl https:// -k @@ -418,12 +418,13 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el ... ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [Using a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) * Learn more about [Connecting a Front End to a Back End Using a Service](/docs/tasks/access-application-cluster/connecting-frontend-backend/) * Learn more about [Creating an External Load Balancer](/docs/tasks/access-application-cluster/create-external-load-balancer/) -{{% /capture %}} + diff --git a/content/en/docs/concepts/services-networking/dns-pod-service.md b/content/en/docs/concepts/services-networking/dns-pod-service.md index 9cba184168..9d88019e3c 100644 --- a/content/en/docs/concepts/services-networking/dns-pod-service.md +++ b/content/en/docs/concepts/services-networking/dns-pod-service.md @@ -3,14 +3,14 @@ reviewers: - davidopp - thockin title: DNS for Services and Pods -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + This page provides an overview of DNS support by Kubernetes. -{{% /capture %}} -{{% capture body %}} + + ## Introduction @@ -66,6 +66,13 @@ of the form `auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example` ## Pods +### A/AAAA records + +Any pods created by a Deployment or DaemonSet have the following +DNS resolution available: + +`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example.` + ### Pod's hostname and subdomain fields Currently when a pod is created, its hostname is the Pod's `metadata.name` value. @@ -262,11 +269,11 @@ The availability of Pod DNS Config and DNS Policy "`None`" is shown as below. | 1.10 | Beta (on by default)| | 1.9 | Alpha | -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + For guidance on administering DNS configurations, check [Configure DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers/) -{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/concepts/services-networking/dual-stack.md b/content/en/docs/concepts/services-networking/dual-stack.md index c753c17cc1..aa249566b9 100644 --- a/content/en/docs/concepts/services-networking/dual-stack.md +++ b/content/en/docs/concepts/services-networking/dual-stack.md @@ -9,11 +9,11 @@ feature: description: > Allocation of IPv4 and IPv6 addresses to Pods and Services -content_template: templates/concept +content_type: concept weight: 70 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.16" state="alpha" >}} @@ -21,9 +21,9 @@ weight: 70 If you enable IPv4/IPv6 dual-stack networking for your Kubernetes cluster, the cluster will support the simultaneous assignment of both IPv4 and IPv6 addresses. -{{% /capture %}} -{{% capture body %}} + + ## Supported Features @@ -103,10 +103,11 @@ The use of publicly routable and non-publicly routable IPv6 address blocks is ac * Kubenet forces IPv4,IPv6 positional reporting of IPs (--cluster-cidr) -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [Validate IPv4/IPv6 dual-stack](/docs/tasks/network/validate-dual-stack) networking -{{% /capture %}} + diff --git a/content/en/docs/concepts/services-networking/endpoint-slices.md b/content/en/docs/concepts/services-networking/endpoint-slices.md index 940374ae52..7c66ce0072 100644 --- a/content/en/docs/concepts/services-networking/endpoint-slices.md +++ b/content/en/docs/concepts/services-networking/endpoint-slices.md @@ -2,12 +2,12 @@ reviewers: - freehan title: EndpointSlices -content_template: templates/concept +content_type: concept weight: 15 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.17" state="beta" >}} @@ -15,9 +15,9 @@ _EndpointSlices_ provide a simple way to track network endpoints within a Kubernetes cluster. They offer a more scalable and extensible alternative to Endpoints. -{{% /capture %}} -{{% capture body %}} + + ## Motivation @@ -175,11 +175,12 @@ necessary soon anyway. Rolling updates of Deployments also provide a natural repacking of EndpointSlices with all pods and their corresponding endpoints getting replaced. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [Enabling EndpointSlices](/docs/tasks/administer-cluster/enabling-endpointslices) * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) -{{% /capture %}} + diff --git a/content/en/docs/concepts/services-networking/ingress-controllers.md b/content/en/docs/concepts/services-networking/ingress-controllers.md index efeb327049..2c363ce7dc 100644 --- a/content/en/docs/concepts/services-networking/ingress-controllers.md +++ b/content/en/docs/concepts/services-networking/ingress-controllers.md @@ -1,11 +1,11 @@ --- title: Ingress Controllers reviewers: -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + In order for the Ingress resource to work, the cluster must have an ingress controller running. @@ -16,9 +16,9 @@ that best fits your cluster. Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.io/ingress-gce/README.md) and [nginx](https://git.k8s.io/ingress-nginx/README.md) controllers. -{{% /capture %}} -{{% capture body %}} + + ## Additional controllers @@ -64,11 +64,12 @@ controllers operate slightly differently. Make sure you review your ingress controller's documentation to understand the caveats of choosing it. {{< /note >}} -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [Ingress](/docs/concepts/services-networking/ingress/). * [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube). -{{% /capture %}} + diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md index 062dc14f66..430ee3c72d 100644 --- a/content/en/docs/concepts/services-networking/ingress.md +++ b/content/en/docs/concepts/services-networking/ingress.md @@ -2,16 +2,16 @@ reviewers: - bprashanth title: Ingress -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.1" state="beta" >}} {{< glossary_definition term_id="ingress" length="all" >}} -{{% /capture %}} -{{% capture body %}} + + ## Terminology @@ -542,10 +542,11 @@ You can expose a Service in multiple ways that don't directly involve the Ingres * Use [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer) * Use [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn about the [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io) * Learn about [Ingress Controllers](/docs/concepts/services-networking/ingress-controllers/) * [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube) -{{% /capture %}} + diff --git a/content/en/docs/concepts/services-networking/network-policies.md b/content/en/docs/concepts/services-networking/network-policies.md index 795969757d..4a01707ab2 100644 --- a/content/en/docs/concepts/services-networking/network-policies.md +++ b/content/en/docs/concepts/services-networking/network-policies.md @@ -4,20 +4,20 @@ reviewers: - caseydavenport - danwinship title: Network Policies -content_template: templates/concept +content_type: concept weight: 50 --- {{< toc >}} -{{% capture overview %}} + A network policy is a specification of how groups of {{< glossary_tooltip text="pods" term_id="pod">}} are allowed to communicate with each other and other network endpoints. NetworkPolicy resources use {{< glossary_tooltip text="labels" term_id="label">}} to select pods and define rules which specify what traffic is allowed to the selected pods. -{{% /capture %}} -{{% capture body %}} + + ## Prerequisites Network policies are implemented by the [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). To use network policies, you must be using a networking solution which supports NetworkPolicy. Creating a NetworkPolicy resource without a controller that implements it will have no effect. @@ -89,9 +89,9 @@ __podSelector__: Each NetworkPolicy includes a `podSelector` which selects the g __policyTypes__: Each NetworkPolicy includes a `policyTypes` list which may include either `Ingress`, `Egress`, or both. The `policyTypes` field indicates whether or not the given policy applies to ingress traffic to selected pod, egress traffic from selected pods, or both. If no `policyTypes` are specified on a NetworkPolicy then by default `Ingress` will always be set and `Egress` will be set if the NetworkPolicy has any egress rules. -__ingress__: Each NetworkPolicy may include a list of whitelist `ingress` rules. Each rule allows traffic which matches both the `from` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port, from one of three sources, the first specified via an `ipBlock`, the second via a `namespaceSelector` and the third via a `podSelector`. +__ingress__: Each NetworkPolicy may include a list of allowed `ingress` rules. Each rule allows traffic which matches both the `from` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port, from one of three sources, the first specified via an `ipBlock`, the second via a `namespaceSelector` and the third via a `podSelector`. -__egress__: Each NetworkPolicy may include a list of whitelist `egress` rules. Each rule allows traffic which matches both the `to` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port to any destination in `10.0.0.0/24`. +__egress__: Each NetworkPolicy may include a list of allowed `egress` rules. Each rule allows traffic which matches both the `to` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port to any destination in `10.0.0.0/24`. So, the example NetworkPolicy: @@ -215,12 +215,13 @@ You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin tha {{< /note >}} -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + - See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) walkthrough for further examples. - See more [recipes](https://github.com/ahmetb/kubernetes-network-policy-recipes) for common scenarios enabled by the NetworkPolicy resource. -{{% /capture %}} + diff --git a/content/en/docs/concepts/services-networking/service-topology.md b/content/en/docs/concepts/services-networking/service-topology.md index 7b3c58a84a..d36b76f55f 100644 --- a/content/en/docs/concepts/services-networking/service-topology.md +++ b/content/en/docs/concepts/services-networking/service-topology.md @@ -8,12 +8,12 @@ feature: description: > Routing of service traffic based upon cluster topology. -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.17" state="alpha" >}} @@ -22,9 +22,9 @@ topology of the cluster. For example, a service can specify that traffic be preferentially routed to endpoints that are on the same Node as the client, or in the same availability zone. -{{% /capture %}} -{{% capture body %}} + + ## Introduction @@ -192,11 +192,12 @@ spec: ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Read about [enabling Service Topology](/docs/tasks/administer-cluster/enabling-service-topology) * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) -{{% /capture %}} + diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index e97d80db21..2ae49ac270 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -7,12 +7,12 @@ feature: description: > No need to modify your application to use an unfamiliar service discovery mechanism. Kubernetes gives Pods their own IP addresses and a single DNS name for a set of Pods, and can load-balance across them. -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + {{< glossary_definition term_id="service" length="short" >}} @@ -20,9 +20,9 @@ With Kubernetes you don't need to modify your application to use an unfamiliar s Kubernetes gives Pods their own IP addresses and a single DNS name for a set of Pods, and can load-balance across them. -{{% /capture %}} -{{% capture body %}} + + ## Motivation @@ -1227,12 +1227,13 @@ SCTP is not supported on Windows based nodes. The kube-proxy does not support the management of SCTP associations when it is in userspace mode. {{< /warning >}} -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) * Read about [Ingress](/docs/concepts/services-networking/ingress/) * Read about [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) -{{% /capture %}} + diff --git a/content/en/docs/concepts/storage/dynamic-provisioning.md b/content/en/docs/concepts/storage/dynamic-provisioning.md index 77885981f7..dc82e5c2c8 100644 --- a/content/en/docs/concepts/storage/dynamic-provisioning.md +++ b/content/en/docs/concepts/storage/dynamic-provisioning.md @@ -5,11 +5,11 @@ reviewers: - thockin - msau42 title: Dynamic Volume Provisioning -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + Dynamic volume provisioning allows storage volumes to be created on-demand. Without dynamic provisioning, cluster administrators have to manually make @@ -19,10 +19,10 @@ to represent them in Kubernetes. The dynamic provisioning feature eliminates the need for cluster administrators to pre-provision storage. Instead, it automatically provisions storage when it is requested by users. -{{% /capture %}} -{{% capture body %}} + + ## Background @@ -133,4 +133,4 @@ Zones in a Region. Single-Zone storage backends should be provisioned in the Zon Pods are scheduled. This can be accomplished by setting the [Volume Binding Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode). -{{% /capture %}} + diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md index c365e02171..2c3140de83 100644 --- a/content/en/docs/concepts/storage/persistent-volumes.md +++ b/content/en/docs/concepts/storage/persistent-volumes.md @@ -11,18 +11,18 @@ feature: description: > Automatically mount the storage system of your choice, whether from local storage, a public cloud provider such as GCP or AWS, or a network storage system such as NFS, iSCSI, Gluster, Ceph, Cinder, or Flocker. -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + This document describes the current state of _persistent volumes_ in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested. -{{% /capture %}} -{{% capture body %}} + + ## Introduction @@ -746,8 +746,9 @@ and need persistent storage, it is recommended that you use the following patter dynamic storage support (in which case the user should create a matching PV) or the cluster has no storage system (in which case the user cannot deploy config requiring PVCs). -{{% /capture %}} - {{% capture whatsnext %}} + + ## {{% heading "whatsnext" %}} + * Learn more about [Creating a PersistentVolume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). * Learn more about [Creating a PersistentVolumeClaim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim). @@ -759,4 +760,3 @@ and need persistent storage, it is recommended that you use the following patter * [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core) * [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core) * [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core) -{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/concepts/storage/storage-classes.md b/content/en/docs/concepts/storage/storage-classes.md index 1ea7c236d9..d6b3a9e332 100644 --- a/content/en/docs/concepts/storage/storage-classes.md +++ b/content/en/docs/concepts/storage/storage-classes.md @@ -5,19 +5,19 @@ reviewers: - thockin - msau42 title: Storage Classes -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + This document describes the concept of a StorageClass in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) and [persistent volumes](/docs/concepts/storage/persistent-volumes) is suggested. -{{% /capture %}} -{{% capture body %}} + + ## Introduction @@ -821,4 +821,4 @@ Delaying volume binding allows the scheduler to consider all of a Pod's scheduling constraints when choosing an appropriate PersistentVolume for a PersistentVolumeClaim. -{{% /capture %}} + diff --git a/content/en/docs/concepts/storage/storage-limits.md b/content/en/docs/concepts/storage/storage-limits.md index 295ed467a2..fb6cffed9c 100644 --- a/content/en/docs/concepts/storage/storage-limits.md +++ b/content/en/docs/concepts/storage/storage-limits.md @@ -5,10 +5,10 @@ reviewers: - thockin - msau42 title: Node-specific Volume Limits -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + This page describes the maximum number of volumes that can be attached to a Node for various cloud providers. @@ -18,9 +18,9 @@ how many volumes can be attached to a Node. It is important for Kubernetes to respect those limits. Otherwise, Pods scheduled on a Node could get stuck waiting for volumes to attach. -{{% /capture %}} -{{% capture body %}} + + ## Kubernetes default limits @@ -78,4 +78,4 @@ Refer to the [CSI specifications](https://github.com/container-storage-interface * For volumes managed by in-tree plugins that have been migrated to a CSI driver, the maximum number of volumes will be the one reported by the CSI driver. -{{% /capture %}} + diff --git a/content/en/docs/concepts/storage/volume-pvc-datasource.md b/content/en/docs/concepts/storage/volume-pvc-datasource.md index 2f29fb9bb9..ac8d16041d 100644 --- a/content/en/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/en/docs/concepts/storage/volume-pvc-datasource.md @@ -5,18 +5,18 @@ reviewers: - thockin - msau42 title: CSI Volume Cloning -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + This document describes the concept of cloning existing CSI Volumes in Kubernetes. Familiarity with [Volumes](/docs/concepts/storage/volumes) is suggested. -{{% /capture %}} -{{% capture body %}} + + ## Introduction @@ -70,4 +70,4 @@ The result is a new PVC with the name `clone-of-pvc-1` that has the exact same c Upon availability of the new PVC, the cloned PVC is consumed the same as other PVC. It's also expected at this point that the newly created PVC is an independent object. It can be consumed, cloned, snapshotted, or deleted independently and without consideration for it's original dataSource PVC. This also implies that the source is not linked in any way to the newly created clone, it may also be modified or deleted without affecting the newly created clone. -{{% /capture %}} + diff --git a/content/en/docs/concepts/storage/volume-snapshot-classes.md b/content/en/docs/concepts/storage/volume-snapshot-classes.md index dcb9516519..f50db19520 100644 --- a/content/en/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/en/docs/concepts/storage/volume-snapshot-classes.md @@ -7,20 +7,20 @@ reviewers: - xing-yang - yuxiangqian title: Volume Snapshot Classes -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + This document describes the concept of `VolumeSnapshotClass` in Kubernetes. Familiarity with [volume snapshots](/docs/concepts/storage/volume-snapshots/) and [storage classes](/docs/concepts/storage/storage-classes) is suggested. -{{% /capture %}} -{{% capture body %}} + + ## Introduction @@ -69,4 +69,4 @@ Volume snapshot classes have parameters that describe volume snapshots belonging the volume snapshot class. Different parameters may be accepted depending on the `driver`. -{{% /capture %}} + diff --git a/content/en/docs/concepts/storage/volume-snapshots.md b/content/en/docs/concepts/storage/volume-snapshots.md index 0ad66e75ae..a6cc122086 100644 --- a/content/en/docs/concepts/storage/volume-snapshots.md +++ b/content/en/docs/concepts/storage/volume-snapshots.md @@ -7,19 +7,19 @@ reviewers: - xing-yang - yuxiangqian title: Volume Snapshots -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.17" state="beta" >}} In Kubernetes, a _VolumeSnapshot_ represents a snapshot of a volume on a storage system. This document assumes that you are already familiar with Kubernetes [persistent volumes](/docs/concepts/storage/persistent-volumes/). -{{% /capture %}} -{{% capture body %}} + + ## Introduction @@ -154,4 +154,4 @@ the *dataSource* field in the `PersistentVolumeClaim` object. For more details, see [Volume Snapshot and Restore Volume from Snapshot](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support). -{{% /capture %}} + diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md index 4249391e54..b7bcb370ad 100644 --- a/content/en/docs/concepts/storage/volumes.md +++ b/content/en/docs/concepts/storage/volumes.md @@ -5,11 +5,11 @@ reviewers: - thockin - msau42 title: Volumes -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + On-disk files in a Container are ephemeral, which presents some problems for non-trivial applications when running in Containers. First, when a Container @@ -20,15 +20,15 @@ Kubernetes `Volume` abstraction solves both of these problems. Familiarity with [Pods](/docs/user-guide/pods) is suggested. -{{% /capture %}} -{{% capture body %}} + + ## Background Docker also has a concept of -[volumes](https://docs.docker.com/engine/admin/volumes/), though it is +[volumes](https://docs.docker.com/storage/), though it is somewhat looser and less managed. In Docker, a volume is simply a directory on disk or in another Container. Lifetimes are not managed and until very recently there were only local-disk-backed volumes. Docker now provides volume @@ -1480,6 +1480,7 @@ sudo systemctl restart docker -{{% capture whatsnext %}} +## {{% heading "whatsnext" %}} + * Follow an example of [deploying WordPress and MySQL with Persistent Volumes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/). -{{% /capture %}} + diff --git a/content/en/docs/concepts/workloads/controllers/cron-jobs.md b/content/en/docs/concepts/workloads/controllers/cron-jobs.md index 233e0ca661..af12bcba25 100644 --- a/content/en/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/en/docs/concepts/workloads/controllers/cron-jobs.md @@ -4,11 +4,11 @@ reviewers: - soltysh - janetkuo title: CronJob -content_template: templates/concept +content_type: concept weight: 80 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.8" state="beta" >}} @@ -33,8 +33,8 @@ append 11 characters to the job name provided and there is a constraint that the maximum length of a Job name is no more than 63 characters. -{{% /capture %}} -{{% capture body %}} + + ## CronJob @@ -82,12 +82,13 @@ be down for the same period as the previous example (`08:29:00` to `10:21:00`,) The CronJob is only responsible for creating Jobs that match its schedule, and the Job in turn is responsible for the management of the Pods it represents. -{{% /capture %}} -{{% capture whatsnext %}} -[Cron expression format](https://pkg.go.dev/github.com/robfig/cron?tab=doc#hdr-CRON_Expression_Format) + +## {{% heading "whatsnext" %}} + +[Cron expression format](https://en.wikipedia.org/wiki/Cron) documents the format of CronJob `schedule` fields. For instructions on creating and working with cron jobs, and for an example of CronJob manifest, see [Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs). -{{% /capture %}} + diff --git a/content/en/docs/concepts/workloads/controllers/daemonset.md b/content/en/docs/concepts/workloads/controllers/daemonset.md index e7ac6139f8..7f1b5c4630 100644 --- a/content/en/docs/concepts/workloads/controllers/daemonset.md +++ b/content/en/docs/concepts/workloads/controllers/daemonset.md @@ -6,11 +6,11 @@ reviewers: - janetkuo - kow3ns title: DaemonSet -content_template: templates/concept +content_type: concept weight: 50 --- -{{% capture overview %}} + A _DaemonSet_ ensures that all (or some) Nodes run a copy of a Pod. As nodes are added to the cluster, Pods are added to them. As nodes are removed from the cluster, those Pods are garbage @@ -26,10 +26,10 @@ In a simple case, one DaemonSet, covering all nodes, would be used for each type A more complex setup might use multiple DaemonSets for a single type of daemon, but with different flags and/or different memory and cpu requests for different hardware types. -{{% /capture %}} -{{% capture body %}} + + ## Writing a DaemonSet Spec @@ -229,4 +229,4 @@ number of replicas and rolling out updates are more important than controlling e the Pod runs on. Use a DaemonSet when it is important that a copy of a Pod always run on all or certain hosts, and when it needs to start before other Pods. -{{% /capture %}} + diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md index 2610380641..6287c0d98e 100644 --- a/content/en/docs/concepts/workloads/controllers/deployment.md +++ b/content/en/docs/concepts/workloads/controllers/deployment.md @@ -7,11 +7,11 @@ feature: description: > Kubernetes progressively rolls out changes to your application or its configuration, while monitoring application health to ensure it doesn't kill all your instances at the same time. If something goes wrong, Kubernetes will rollback the change for you. Take advantage of a growing ecosystem of deployment solutions. -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + A _Deployment_ provides declarative updates for [Pods](/docs/concepts/workloads/pods/pod/) and [ReplicaSets](/docs/concepts/workloads/controllers/replicaset/). @@ -22,10 +22,10 @@ You describe a _desired state_ in a Deployment, and the Deployment {{< glossary_ Do not manage ReplicaSets owned by a Deployment. Consider opening an issue in the main Kubernetes repository if your use case is not covered below. {{< /note >}} -{{% /capture %}} -{{% capture body %}} + + ## Use Case @@ -1166,4 +1166,4 @@ a paused Deployment and one that is not paused, is that any changes into the Pod Deployment will not trigger new rollouts as long as it is paused. A Deployment is not paused by default when it is created. -{{% /capture %}} + diff --git a/content/en/docs/concepts/workloads/controllers/garbage-collection.md b/content/en/docs/concepts/workloads/controllers/garbage-collection.md index 45303b66e8..a20951a35e 100644 --- a/content/en/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/en/docs/concepts/workloads/controllers/garbage-collection.md @@ -1,18 +1,16 @@ --- title: Garbage Collection -content_template: templates/concept -weight: 60 +content_type: concept +weight: 70 --- -{{% capture overview %}} + The role of the Kubernetes garbage collector is to delete certain objects that once had an owner, but no longer have an owner. -{{% /capture %}} - -{{% capture body %}} + ## Owners and dependents @@ -168,16 +166,11 @@ See [kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment Tracked at [#26120](https://github.com/kubernetes/kubernetes/issues/26120) -{{% /capture %}} -{{% capture whatsnext %}} +## {{% heading "whatsnext" %}} + [Design Doc 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md) [Design Doc 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md) - -{{% /capture %}} - - - diff --git a/content/en/docs/concepts/workloads/controllers/jobs-run-to-completion.md b/content/en/docs/concepts/workloads/controllers/job.md similarity index 97% rename from content/en/docs/concepts/workloads/controllers/jobs-run-to-completion.md rename to content/en/docs/concepts/workloads/controllers/job.md index aef6b556a3..45fa66bd3d 100644 --- a/content/en/docs/concepts/workloads/controllers/jobs-run-to-completion.md +++ b/content/en/docs/concepts/workloads/controllers/job.md @@ -2,16 +2,16 @@ reviewers: - erictune - soltysh -title: Jobs - Run to Completion -content_template: templates/concept +title: Jobs +content_type: concept feature: title: Batch execution description: > In addition to services, Kubernetes can manage your batch and CI workloads, replacing containers that fail, if desired. -weight: 70 +weight: 60 --- -{{% capture overview %}} + A Job creates one or more Pods and ensures that a specified number of them successfully terminate. As pods successfully complete, the Job tracks the successful completions. When a specified number @@ -24,10 +24,10 @@ due to a node hardware failure or a node reboot). You can also use a Job to run multiple Pods in parallel. -{{% /capture %}} -{{% capture body %}} + + ## Running an example Job @@ -111,7 +111,7 @@ The output is similar to this: 3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901 ``` -## Writing a Job Spec +## Writing a Job spec As with all other Kubernetes config, a Job needs `apiVersion`, `kind`, and `metadata` fields. Its name must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). @@ -129,13 +129,13 @@ labels (see [pod selector](#pod-selector)) and an appropriate restart policy. Only a [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) equal to `Never` or `OnFailure` is allowed. -### Pod Selector +### Pod selector The `.spec.selector` field is optional. In almost all cases you should not specify it. See section [specifying your own pod selector](#specifying-your-own-pod-selector). -### Parallel Jobs +### Parallel execution for Jobs {#parallel-jobs} There are three main types of task suitable to run as a Job: @@ -166,7 +166,7 @@ a non-negative integer. For more information about how to make use of the different types of job, see the [job patterns](#job-patterns) section. -#### Controlling Parallelism +#### Controlling parallelism The requested parallelism (`.spec.parallelism`) can be set to any non-negative value. If it is unspecified, it defaults to 1. @@ -184,7 +184,7 @@ parallelism, for a variety of reasons: - The Job controller may throttle new Pod creation due to excessive previous pod failures in the same Job. - When a Pod is gracefully shut down, it takes time to stop. -## Handling Pod and Container Failures +## Handling Pod and container failures A container in a Pod may fail for a number of reasons, such as because the process in it exited with a non-zero exit code, or the container was killed for exceeding a memory limit, etc. If this @@ -228,7 +228,7 @@ will be terminated once the job backoff limit has been reached. This can make de from failed Jobs is not lost inadvertently. {{< /note >}} -## Job Termination and Cleanup +## Job termination and cleanup When a Job completes, no more Pods are created, but the Pods are not deleted either. Keeping them around allows you to still view the logs of completed pods to check for errors, warnings, or other diagnostic output. @@ -269,7 +269,7 @@ Note that both the Job spec and the [Pod template spec](/docs/concepts/workloads Keep in mind that the `restartPolicy` applies to the Pod, and not to the Job itself: there is no automatic Job restart once the Job status is `type: Failed`. That is, the Job termination mechanisms activated with `.spec.activeDeadlineSeconds` and `.spec.backoffLimit` result in a permanent Job failure that requires manual intervention to resolve. -## Clean Up Finished Jobs Automatically +## Clean up finished jobs automatically Finished Jobs are usually no longer needed in the system. Keeping them around in the system will put pressure on the API server. If the Jobs are managed directly @@ -277,7 +277,7 @@ by a higher level controller, such as [CronJobs](/docs/concepts/workloads/controllers/cron-jobs/), the Jobs can be cleaned up by CronJobs based on the specified capacity-based cleanup policy. -### TTL Mechanism for Finished Jobs +### TTL mechanism for finished Jobs {{< feature-state for_k8s_version="v1.12" state="alpha" >}} @@ -322,7 +322,7 @@ more information, see the documentation for [TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) for finished resources. -## Job Patterns +## Job patterns The Job object can be used to support reliable parallel execution of Pods. The Job object is not designed to support closely-communicating parallel processes, as commonly found in scientific @@ -374,9 +374,9 @@ Here, `W` is the number of work items. | Single Job with Static Work Assignment | W | any | -## Advanced Usage +## Advanced usage -### Specifying your own pod selector +### Specifying your own Pod selector Normally, when you create a Job object, you do not specify `.spec.selector`. The system defaulting logic adds this field when the Job is created. @@ -461,7 +461,7 @@ As discussed in [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/), ` for pods with `RestartPolicy` equal to `OnFailure` or `Never`. (Note: If `RestartPolicy` is not set, the default value is `Always`.) -### Single Job starts Controller Pod +### Single Job starts controller Pod Another pattern is for a single Job to create a Pod which then creates other Pods, acting as a sort of custom controller for those Pods. This allows the most flexibility, but may be somewhat @@ -478,4 +478,3 @@ object, but maintains complete control over what Pods are created and how work i You can use a [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) to create a Job that will run at specified times/dates, similar to the Unix tool `cron`. -{{% /capture %}} diff --git a/content/en/docs/concepts/workloads/controllers/replicaset.md b/content/en/docs/concepts/workloads/controllers/replicaset.md index 92cbe60a33..ef2a069ca1 100644 --- a/content/en/docs/concepts/workloads/controllers/replicaset.md +++ b/content/en/docs/concepts/workloads/controllers/replicaset.md @@ -4,19 +4,19 @@ reviewers: - bprashanth - madhusudancs title: ReplicaSet -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + A ReplicaSet's purpose is to maintain a stable set of replica Pods running at any given time. As such, it is often used to guarantee the availability of a specified number of identical Pods. -{{% /capture %}} -{{% capture body %}} + + ## How a ReplicaSet works @@ -366,4 +366,4 @@ The two serve the same purpose, and behave similarly, except that a ReplicationC selector requirements as described in the [labels user guide](/docs/concepts/overview/working-with-objects/labels/#label-selectors). As such, ReplicaSets are preferred over ReplicationControllers -{{% /capture %}} + diff --git a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md index fe20980ce6..2cc8284940 100644 --- a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md @@ -9,11 +9,11 @@ feature: description: > Restarts containers that fail, replaces and reschedules containers when nodes die, kills containers that don't respond to your user-defined health check, and doesn't advertise them to clients until they are ready to serve. -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + {{< note >}} A [`Deployment`](/docs/concepts/workloads/controllers/deployment/) that configures a [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) is now the recommended way to set up replication. @@ -23,10 +23,10 @@ A _ReplicationController_ ensures that a specified number of pod replicas are ru time. In other words, a ReplicationController makes sure that a pod or a homogeneous set of pods is always up and available. -{{% /capture %}} -{{% capture body %}} + + ## How a ReplicationController Works @@ -285,4 +285,4 @@ safe to terminate when the machine is otherwise ready to be rebooted/shutdown. Read [Run Stateless AP Replication Controller](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/). -{{% /capture %}} + diff --git a/content/en/docs/concepts/workloads/controllers/statefulset.md b/content/en/docs/concepts/workloads/controllers/statefulset.md index 661955cb48..4f8429d668 100644 --- a/content/en/docs/concepts/workloads/controllers/statefulset.md +++ b/content/en/docs/concepts/workloads/controllers/statefulset.md @@ -7,18 +7,18 @@ reviewers: - kow3ns - smarterclayton title: StatefulSets -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + StatefulSet is the workload API object used to manage stateful applications. {{< glossary_definition term_id="statefulset" length="all" >}} -{{% /capture %}} -{{% capture body %}} + + ## Using StatefulSets @@ -270,12 +270,13 @@ After reverting the template, you must also delete any Pods that StatefulSet had already attempted to run with the bad configuration. StatefulSet will then begin to recreate the Pods using the reverted template. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Follow an example of [deploying a stateful application](/docs/tutorials/stateful-application/basic-stateful-set/). * Follow an example of [deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/). * Follow an example of [running a replicated stateful application](/docs/tasks/run-application/run-replicated-stateful-application/). -{{% /capture %}} + diff --git a/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md index c5b88198f4..3a43d5e7b7 100644 --- a/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -2,18 +2,18 @@ reviewers: - janetkuo title: TTL Controller for Finished Resources -content_template: templates/concept -weight: 65 +content_type: concept +weight: 70 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.12" state="alpha" >}} The TTL controller provides a TTL (time to live) mechanism to limit the lifetime of resource objects that have finished execution. TTL controller only handles -[Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) for -now, and may be expanded to handle other resources that will finish execution, +{{< glossary_tooltip text="Jobs" term_id="job" >}} for now, +and may be expanded to handle other resources that will finish execution, such as Pods and custom resources. Alpha Disclaimer: this feature is currently alpha, and can be enabled with both kube-apiserver and kube-controller-manager @@ -21,19 +21,19 @@ Alpha Disclaimer: this feature is currently alpha, and can be enabled with both `TTLAfterFinished`. -{{% /capture %}} -{{% capture body %}} + + ## TTL Controller The TTL controller only supports Jobs for now. A cluster operator can use this feature to clean up finished Jobs (either `Complete` or `Failed`) automatically by specifying the `.spec.ttlSecondsAfterFinished` field of a Job, as in this -[example](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically). +[example](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically). The TTL controller will assume that a resource is eligible to be cleaned up TTL seconds after the resource has finished, in other words, when the TTL has expired. When the TTL controller cleans up a resource, it will delete it cascadingly, that is to say it will delete @@ -78,12 +78,13 @@ In Kubernetes, it's required to run NTP on all nodes to avoid time skew. Clocks aren't always correct, but the difference should be very small. Please be aware of this risk when setting a non-zero TTL. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + [Clean up Jobs automatically](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically) [Design doc](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) -{{% /capture %}} + diff --git a/content/en/docs/concepts/workloads/pods/disruptions.md b/content/en/docs/concepts/workloads/pods/disruptions.md index 9983a67fc8..589bde5668 100644 --- a/content/en/docs/concepts/workloads/pods/disruptions.md +++ b/content/en/docs/concepts/workloads/pods/disruptions.md @@ -4,11 +4,11 @@ reviewers: - foxish - davidopp title: Disruptions -content_template: templates/concept +content_type: concept weight: 60 --- -{{% capture overview %}} + This guide is for application owners who want to build highly available applications, and thus need to understand what types of Disruptions can happen to Pods. @@ -16,10 +16,10 @@ what types of Disruptions can happen to Pods. It is also for Cluster Administrators who want to perform automated cluster actions, like upgrading and autoscaling clusters. -{{% /capture %}} -{{% capture body %}} + + ## Voluntary and Involuntary Disruptions @@ -262,13 +262,14 @@ the nodes in your cluster, such as a node or system software upgrade, here are s disruptions largely overlaps with work to support autoscaling and tolerating involuntary disruptions. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Follow steps to protect your application by [configuring a Pod Disruption Budget](/docs/tasks/run-application/configure-pdb/). * Learn more about [draining nodes](/docs/tasks/administer-cluster/safely-drain-node/) -{{% /capture %}} + diff --git a/content/en/docs/concepts/workloads/pods/ephemeral-containers.md b/content/en/docs/concepts/workloads/pods/ephemeral-containers.md index c6506df69c..c1852df707 100644 --- a/content/en/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/en/docs/concepts/workloads/pods/ephemeral-containers.md @@ -3,11 +3,11 @@ reviewers: - verb - yujuhong title: Ephemeral Containers -content_template: templates/concept +content_type: concept weight: 80 --- -{{% capture overview %}} + {{< feature-state state="alpha" for_k8s_version="v1.16" >}} @@ -23,9 +23,9 @@ clusters. In accordance with the [Kubernetes Deprecation Policy]( significantly in the future or be removed entirely. {{< /warning >}} -{{% /capture %}} -{{% capture body %}} + + ## Understanding ephemeral containers @@ -192,4 +192,4 @@ example: kubectl attach -it example-pod -c debugger ``` -{{% /capture %}} + diff --git a/content/en/docs/concepts/workloads/pods/init-containers.md b/content/en/docs/concepts/workloads/pods/init-containers.md index 2cf2bf85b5..6e67a9e0ca 100644 --- a/content/en/docs/concepts/workloads/pods/init-containers.md +++ b/content/en/docs/concepts/workloads/pods/init-containers.md @@ -2,20 +2,20 @@ reviewers: - erictune title: Init Containers -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + This page provides an overview of init containers: specialized containers that run before app containers in a {{< glossary_tooltip text="Pod" term_id="pod" >}}. Init containers can contain utilities or setup scripts not present in an app image. You can specify init containers in the Pod specification alongside the `containers` array (which describes app containers). -{{% /capture %}} -{{% capture body %}} + + ## Understanding init containers @@ -317,12 +317,13 @@ reasons: forcing a restart, and the init container completion record has been lost due to garbage collection. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Read about [creating a Pod that has an init container](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container) * Learn how to [debug init containers](/docs/tasks/debug-application-cluster/debug-init-containers/) -{{% /capture %}} + diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md index 74031a3722..60973c46a8 100644 --- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md @@ -1,20 +1,20 @@ --- title: Pod Lifecycle -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + {{< comment >}}Updated: 4/14/2015{{< /comment >}} {{< comment >}}Edited and moved to Concepts section: 2/2/17{{< /comment >}} This page describes the lifecycle of a Pod. -{{% /capture %}} -{{% capture body %}} + + ## Pod phase @@ -216,7 +216,7 @@ a list of additional conditions that the kubelet evaluates for Pod readiness. Readiness gates are determined by the current state of `status.condition` fields for the Pod. If Kubernetes cannot find such a condition in the `status.conditions` field of a Pod, the status of the condition -is defaulted to "`False`". Below is an example: +is defaulted to "`False`". Here is an example: @@ -390,10 +390,11 @@ spec: * Node controller sets Pod `phase` to Failed. * If running under a controller, Pod is recreated elsewhere. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Get hands-on experience [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). @@ -403,7 +404,7 @@ spec: * Learn more about [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/). -{{% /capture %}} + diff --git a/content/en/docs/concepts/workloads/pods/pod-overview.md b/content/en/docs/concepts/workloads/pods/pod-overview.md index 2bc2951259..e963b7ace6 100644 --- a/content/en/docs/concepts/workloads/pods/pod-overview.md +++ b/content/en/docs/concepts/workloads/pods/pod-overview.md @@ -2,19 +2,19 @@ reviewers: - erictune title: Pod Overview -content_template: templates/concept +content_type: concept weight: 10 card: name: concepts weight: 60 --- -{{% capture overview %}} + This page provides an overview of `Pod`, the smallest deployable object in the Kubernetes object model. -{{% /capture %}} -{{% capture body %}} + + ## Understanding Pods A *Pod* is the basic execution unit of a Kubernetes application--the smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod represents processes running on your {{< glossary_tooltip term_id="cluster" text="cluster" >}}. @@ -111,12 +111,13 @@ For example, a Deployment controller ensures that the running Pods match the cur On Nodes, the {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} does not directly observe or manage any of the details around pod templates and updates; those details are abstracted away. That abstraction and separation of concerns simplifies system semantics, and makes it feasible to extend the cluster's behavior without changing existing code. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [Pods](/docs/concepts/workloads/pods/pod/) * [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container * Learn more about Pod behavior: * [Pod Termination](/docs/concepts/workloads/pods/pod/#termination-of-pods) * [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/) -{{% /capture %}} + diff --git a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index 6e6f878449..2b16894e6b 100644 --- a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -1,18 +1,18 @@ --- title: Pod Topology Spread Constraints -content_template: templates/concept +content_type: concept weight: 50 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.18" state="beta" >}} You can use _topology spread constraints_ to control how {{< glossary_tooltip text="Pods" term_id="Pod" >}} are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization. -{{% /capture %}} -{{% capture body %}} + + ## Prerequisites @@ -236,8 +236,7 @@ scheduled - more packed or more scattered. The "EvenPodsSpread" feature provides flexible options to distribute Pods evenly across different topology domains - to achieve high availability or cost-saving. This can also help on rolling update -workloads and scaling out replicas smoothly. -See [Motivation](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-pod-topology-spread.md#motivation) for more details. +workloads and scaling out replicas smoothly. See [Motivation](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation) for more details. ## Known Limitations @@ -246,4 +245,4 @@ As of 1.18, at which this feature is Beta, there are some known limitations: - Scaling down a Deployment may result in imbalanced Pods distribution. - Pods matched on tainted nodes are respected. See [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921) -{{% /capture %}} + diff --git a/content/en/docs/concepts/workloads/pods/pod.md b/content/en/docs/concepts/workloads/pods/pod.md index d64227be48..d87dc92cb2 100644 --- a/content/en/docs/concepts/workloads/pods/pod.md +++ b/content/en/docs/concepts/workloads/pods/pod.md @@ -1,19 +1,19 @@ --- reviewers: title: Pods -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + _Pods_ are the smallest deployable units of computing that can be created and managed in Kubernetes. -{{% /capture %}} -{{% capture body %}} + + ## What is a Pod? @@ -206,4 +206,4 @@ describes the object in detail. When creating the manifest for a Pod object, make sure the name specified is a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). -{{% /capture %}} + diff --git a/content/en/docs/concepts/workloads/pods/podpreset.md b/content/en/docs/concepts/workloads/pods/podpreset.md index a1906c8b99..f77e34a3f9 100644 --- a/content/en/docs/concepts/workloads/pods/podpreset.md +++ b/content/en/docs/concepts/workloads/pods/podpreset.md @@ -2,20 +2,20 @@ reviewers: - jessfraz title: Pod Preset -content_template: templates/concept +content_type: concept weight: 50 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.6" state="alpha" >}} This page provides an overview of PodPresets, which are objects for injecting certain information into pods at creation time. The information can include secrets, volumes, volume mounts, and environment variables. -{{% /capture %}} -{{% capture body %}} + + ## Understanding Pod presets A PodPreset is an API resource for injecting additional runtime requirements @@ -82,12 +82,13 @@ There may be instances where you wish for a Pod to not be altered by any Pod Preset mutations. In these cases, you can add an annotation in the Pod Spec of the form: `podpreset.admission.kubernetes.io/exclude: "true"`. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + See [Injecting data into a Pod using PodPreset](/docs/tasks/inject-data-application/podpreset/) For more information about the background, see the [design proposal for PodPreset](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md). -{{% /capture %}} + diff --git a/content/en/docs/contribute/_index.md b/content/en/docs/contribute/_index.md index c6aa348125..2f93af4a35 100644 --- a/content/en/docs/contribute/_index.md +++ b/content/en/docs/contribute/_index.md @@ -1,5 +1,5 @@ --- -content_template: templates/concept +content_type: concept title: Contribute to Kubernetes docs linktitle: Contribute main_menu: true @@ -10,7 +10,7 @@ card: title: Start contributing --- -{{% capture overview %}} + This website is maintained by [Kubernetes SIG Docs](/docs/contribute/#get-involved-with-sig-docs). @@ -23,9 +23,9 @@ Kubernetes documentation contributors: Kubernetes documentation welcomes improvements from all contributors, new and experienced! -{{% /capture %}} -{{% capture body %}} + + ## Getting started @@ -48,7 +48,7 @@ roles and permissions. - [Open a pull request using GitHub](/docs/contribute/new-content/new-content/#changes-using-github) to existing documentation and learn more about filing issues in GitHub. - [Review pull requests](/docs/contribute/review/reviewing-prs/) from other Kubernetes community members for accuracy and language. - Read the Kubernetes [content](/docs/contribute/style/content-guide/) and [style guides](/docs/contribute/style/style-guide/) so you can leave informed comments. -- Learn how to [use page templates](/docs/contribute/style/page-templates/) and [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) to make bigger changes. +- Learn about [page content types](/docs/contribute/style/page-content-types/) and [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/). ## Next steps @@ -75,4 +75,4 @@ SIG Docs communicates with different methods: - Read the [contributor cheatsheet](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) to get involved with Kubernetes feature development. - Submit a [blog post or case study](/docs/contribute/new-content/blogs-case-studies/). -{{% /capture %}} + diff --git a/content/en/docs/contribute/advanced.md b/content/en/docs/contribute/advanced.md index 2ed3a4afd6..9cf6a65883 100644 --- a/content/en/docs/contribute/advanced.md +++ b/content/en/docs/contribute/advanced.md @@ -1,11 +1,11 @@ --- title: Advanced contributing slug: advanced -content_template: templates/concept +content_type: concept weight: 98 --- -{{% capture overview %}} + This page assumes that you understand how to [contribute to new content](/docs/contribute/new-content/overview) and @@ -13,9 +13,9 @@ This page assumes that you understand how to to learn about more ways to contribute. You need to use the Git command line client and other tools for some of these tasks. -{{% /capture %}} -{{% capture body %}} + + ## Be the PR Wrangler for a week @@ -245,4 +245,4 @@ When you’re ready to stop recording, click Stop. The video uploads automatically to YouTube. -{{% /capture %}} + diff --git a/content/en/docs/contribute/generate-ref-docs/contribute-upstream.md b/content/en/docs/contribute/generate-ref-docs/contribute-upstream.md index 6c4d93cd40..5f4edbcc77 100644 --- a/content/en/docs/contribute/generate-ref-docs/contribute-upstream.md +++ b/content/en/docs/contribute/generate-ref-docs/contribute-upstream.md @@ -1,10 +1,10 @@ --- title: Contributing to the Upstream Kubernetes Code -content_template: templates/task +content_type: task weight: 20 --- -{{% capture overview %}} + This page shows how to contribute to the upstream `kubernetes/kubernetes` project. You can fix bugs found in the Kubernetes API documentation or the content of @@ -16,9 +16,10 @@ API or the `kube-*` components from the upstream code, see the following instruc - [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/) - [Generating Reference Documentation for the Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/) -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + - You need to have these tools installed: @@ -35,9 +36,9 @@ API or the `kube-*` components from the upstream code, see the following instruc For more information, see [Creating a Pull Request](https://help.github.com/articles/creating-a-pull-request/) and [GitHub Standard Fork & Pull Request Workflow](https://gist.github.com/Chaser324/ce0505fbed06b947d962). -{{% /capture %}} -{{% capture steps %}} + + ## The big picture @@ -230,12 +231,13 @@ the API reference documentation. You are now ready to follow the [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/) guide to generate the [published Kubernetes API reference documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/). -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/) * [Generating Reference Docs for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/) * [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/) -{{% /capture %}} + diff --git a/content/en/docs/contribute/generate-ref-docs/kubectl.md b/content/en/docs/contribute/generate-ref-docs/kubectl.md index 5930a1f452..f057ce6800 100644 --- a/content/en/docs/contribute/generate-ref-docs/kubectl.md +++ b/content/en/docs/contribute/generate-ref-docs/kubectl.md @@ -1,10 +1,10 @@ --- title: Generating Reference Documentation for kubectl Commands -content_template: templates/task +content_type: task weight: 90 --- -{{% capture overview %}} + This page shows how to generate the `kubectl` command reference. @@ -21,15 +21,16 @@ reference page, see [Generating Reference Pages for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/). {{< /note >}} -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "prerequisites-ref-docs.md" >}} -{{% /capture %}} -{{% capture steps %}} + + ## Setting up the local repositories @@ -253,12 +254,13 @@ A few minutes after your pull request is merged, your updated reference topics will be visible in the [published documentation](/docs/home). -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/) * [Generating Reference Documentation for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/) * [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/) -{{% /capture %}} + diff --git a/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md b/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md index 5060d3b6e0..10482eda97 100644 --- a/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md +++ b/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md @@ -1,10 +1,10 @@ --- title: Generating Reference Documentation for the Kubernetes API -content_template: templates/task +content_type: task weight: 50 --- -{{% capture overview %}} + This page shows how to update the Kubernetes API reference documentation. @@ -18,15 +18,16 @@ If you find bugs in the generated documentation, you need to If you need only to regenerate the reference documentation from the [OpenAPI](https://github.com/OAI/OpenAPI-Specification) spec, continue reading this page. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "prerequisites-ref-docs.md" >}} -{{% /capture %}} -{{% capture steps %}} + + ## Setting up the local repositories @@ -194,12 +195,13 @@ Submit your changes as a Monitor your pull request, and respond to reviewer comments as needed. Continue to monitor your pull request until it has been merged. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/) * [Generating Reference Docs for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/) * [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/) -{{% /capture %}} + diff --git a/content/en/docs/contribute/generate-ref-docs/kubernetes-components.md b/content/en/docs/contribute/generate-ref-docs/kubernetes-components.md index f71db7afb1..be84beeb08 100644 --- a/content/en/docs/contribute/generate-ref-docs/kubernetes-components.md +++ b/content/en/docs/contribute/generate-ref-docs/kubernetes-components.md @@ -1,34 +1,36 @@ --- title: Generating Reference Pages for Kubernetes Components and Tools -content_template: templates/task +content_type: task weight: 120 --- -{{% capture overview %}} + This page shows how to build the Kubernetes component and tool reference pages. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + Start with the [Prerequisites section](/docs/contribute/generate-ref-docs/quickstart/#before-you-begin) in the Reference Documentation Quickstart guide. -{{% /capture %}} -{{% capture steps %}} + + Follow the [Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/) to generate the Kubernetes component and tool reference pages. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/) * [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/) * [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/) * [Contributing to the Upstream Kubernetes Project for Documentation](/docs/contribute/generate-ref-docs/contribute-upstream/) -{{% /capture %}} + diff --git a/content/en/docs/contribute/generate-ref-docs/quickstart.md b/content/en/docs/contribute/generate-ref-docs/quickstart.md index 9645c64170..df5cdbb95f 100644 --- a/content/en/docs/contribute/generate-ref-docs/quickstart.md +++ b/content/en/docs/contribute/generate-ref-docs/quickstart.md @@ -1,24 +1,25 @@ --- title: Quickstart -content_template: templates/task +content_type: task weight: 40 --- -{{% capture overview %}} + This page shows how to use the `update-imported-docs` script to generate the Kubernetes reference documentation. The script automates the build setup and generates the reference documentation for a release. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "prerequisites-ref-docs.md" >}} -{{% /capture %}} -{{% capture steps %}} + + ## Getting the docs repository @@ -246,9 +247,10 @@ A few minutes after your pull request is merged, your updated reference topics will be visible in the [published documentation](/docs/home/). -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + To generate the individual reference documentation by manually setting up the required build repositories and running the build targets, see the following guides: @@ -257,4 +259,4 @@ running the build targets, see the following guides: * [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/) * [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/) -{{% /capture %}} + diff --git a/content/en/docs/contribute/localization.md b/content/en/docs/contribute/localization.md index cb3cf03187..0c698305b9 100644 --- a/content/en/docs/contribute/localization.md +++ b/content/en/docs/contribute/localization.md @@ -1,6 +1,6 @@ --- title: Localizing Kubernetes documentation -content_template: templates/concept +content_type: concept approvers: - remyleone - rlenferink @@ -12,13 +12,13 @@ card: title: Translating the docs --- -{{% capture overview %}} + This page shows you how to [localize](https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/) the docs for a different language. -{{% /capture %}} -{{% capture body %}} + + ## Getting started @@ -279,13 +279,14 @@ SIG Docs welcomes upstream contributions and corrections to the English source. You can also help add or improve content to an existing localization. Join the [Slack channel](https://kubernetes.slack.com/messages/C1J0BPD2M/) for the localization, and start opening PRs to help. Please limit pull requests to a single localization since pull requests that change content in multiple localizations could be difficult to review. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + Once a localization meets requirements for workflow and minimum output, SIG docs will: - Enable language selection on the website - Publicize the localization's availability through [Cloud Native Computing Foundation](https://www.cncf.io/about/) (CNCF) channels, including the [Kubernetes blog](https://kubernetes.io/blog/). -{{% /capture %}} + diff --git a/content/en/docs/contribute/new-content/blogs-case-studies.md b/content/en/docs/contribute/new-content/blogs-case-studies.md index 90c50ae6e1..76acbd2d41 100644 --- a/content/en/docs/contribute/new-content/blogs-case-studies.md +++ b/content/en/docs/contribute/new-content/blogs-case-studies.md @@ -2,19 +2,19 @@ title: Submitting blog posts and case studies linktitle: Blogs and case studies slug: blogs-case-studies -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + Anyone can write a blog post and submit it for review. Case studies require extensive review before they're approved. -{{% /capture %}} -{{% capture body %}} + + ## Write a blog post @@ -52,8 +52,9 @@ Have a look at the source for the Refer to the [case study guidelines](https://github.com/cncf/foundation/blob/master/case-study-guidelines.md) and submit your request as outlined in the guidelines. -{{% /capture %}} -{{% capture whatsnext %}} -{{% /capture %}} +## {{% heading "whatsnext" %}} + + + diff --git a/content/en/docs/contribute/new-content/new-features.md b/content/en/docs/contribute/new-content/new-features.md index 68087a2a79..54db84da8f 100644 --- a/content/en/docs/contribute/new-content/new-features.md +++ b/content/en/docs/contribute/new-content/new-features.md @@ -1,7 +1,7 @@ --- title: Documenting a feature for a release linktitle: Documenting for a release -content_template: templates/concept +content_type: concept main_menu: true weight: 20 card: @@ -9,7 +9,7 @@ card: weight: 45 title: Documenting a feature for a release --- -{{% capture overview %}} + Each major Kubernetes release introduces new features that require documentation. New releases also bring updates to existing features and documentation (such as upgrading a feature from alpha to beta). @@ -19,9 +19,9 @@ feature as a pull request to the appropriate development branch of the editorial feedback or edits the draft directly. This section covers the branching conventions and process used during a release by both groups. -{{% /capture %}} -{{% capture body %}} + + ## For documentation contributors @@ -131,4 +131,3 @@ add it to [Alpha/Beta Feature gates](/docs/reference/command-line-tools-referenc as part of your pull request. If your feature is moving out of Alpha, make sure to remove it from that table. -{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/contribute/new-content/open-a-pr.md b/content/en/docs/contribute/new-content/open-a-pr.md index 4407568aff..05a576a74b 100644 --- a/content/en/docs/contribute/new-content/open-a-pr.md +++ b/content/en/docs/contribute/new-content/open-a-pr.md @@ -1,14 +1,14 @@ --- title: Opening a pull request slug: new-content -content_template: templates/concept +content_type: concept weight: 10 card: name: contribute weight: 40 --- -{{% capture overview %}} + {{< note >}} **Code developers**: If you are documenting a new feature for an @@ -22,9 +22,9 @@ If your change is small, or you're unfamiliar with git, read [Changes using GitH If your changes are large, read [Work from a local fork](#fork-the-repo) to learn how to make changes locally on your computer. -{{% /capture %}} -{{% capture body %}} + + ## Changes using GitHub @@ -475,10 +475,11 @@ Most repositories use issue and PR templates. Have a look through some open issues and PRs to get a feel for that team's processes. Make sure to fill out the templates with as much detail as possible when you file issues or PRs. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + - Read [Reviewing](/docs/contribute/reviewing/revewing-prs) to learn more about the review process. -{{% /capture %}} + diff --git a/content/en/docs/contribute/new-content/overview.md b/content/en/docs/contribute/new-content/overview.md index 11f4c067d7..e9ef332430 100644 --- a/content/en/docs/contribute/new-content/overview.md +++ b/content/en/docs/contribute/new-content/overview.md @@ -1,25 +1,25 @@ --- title: Contributing new content overview linktitle: Overview -content_template: templates/concept +content_type: concept main_menu: true weight: 5 --- -{{% capture overview %}} + This section contains information you should know before contributing new content. -{{% /capture %}} -{{% capture body %}} + + ## Contributing basics - Write Kubernetes documentation in Markdown and build the Kubernetes site using [Hugo](https://gohugo.io/). - The source is in [GitHub](https://github.com/kubernetes/website). You can find Kubernetes documentation at `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory. -- [Page templates](/docs/contribute/style/page-templates/) control the presentation of documentation content in Hugo. +- [Page content types](/docs/contribute/style/page-content-types/) describe the presentation of documentation content in Hugo. - In addition to the standard Hugo shortcodes, we use a number of [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our documentation to control the presentation of content. - Documentation source is available in multiple languages in `/content/`. Each language has its own folder with a two-letter code determined by the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For example, English documentation source is stored in `/content/en/docs/`. - For more information about contributing to documentation in multiple languages or starting a new translation, see [localization](/docs/contribute/localization). @@ -58,4 +58,4 @@ Limit pull requests to one language per PR. If you need to make an identical cha The [doc contributors tools](https://github.com/kubernetes/website/tree/master/content/en/docs/doc-contributor-tools) directory in the `kubernetes/website` repository contains tools to help your contribution journey go more smoothly. -{{% /capture %}} + diff --git a/content/en/docs/contribute/participating.md b/content/en/docs/contribute/participating.md index 3f491dc856..681c53f994 100644 --- a/content/en/docs/contribute/participating.md +++ b/content/en/docs/contribute/participating.md @@ -1,13 +1,13 @@ --- title: Participating in SIG Docs -content_template: templates/concept +content_type: concept weight: 60 card: name: contribute weight: 60 --- -{{% capture overview %}} + SIG Docs is one of the [special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md) @@ -30,9 +30,9 @@ The rest of this document outlines some unique ways these roles function within SIG Docs, which is responsible for maintaining one of the most public-facing aspects of Kubernetes -- the Kubernetes website and documentation. -{{% /capture %}} -{{% capture body %}} + + ## Roles and responsibilities @@ -302,9 +302,10 @@ SIG Docs approvers. Here's how it works. specific roles, such as [PR Wrangler](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) or [SIG Docs chairperson](#sig-docs-chairperson). -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + For more information about contributing to the Kubernetes documentation, see: @@ -312,4 +313,4 @@ For more information about contributing to the Kubernetes documentation, see: - [Reviewing content](/docs/contribute/review/reviewing-prs) - [Documentation style guide](/docs/contribute/style/) -{{% /capture %}} + diff --git a/content/en/docs/contribute/review/_index.md b/content/en/docs/contribute/review/_index.md index bc70e3c6f1..d2a1a5c906 100644 --- a/content/en/docs/contribute/review/_index.md +++ b/content/en/docs/contribute/review/_index.md @@ -3,12 +3,12 @@ title: Reviewing changes weight: 30 --- -{{% capture overview %}} + This section describes how to review content. -{{% /capture %}} -{{% capture body %}} -{{% /capture %}} + + + diff --git a/content/en/docs/contribute/review/for-approvers.md b/content/en/docs/contribute/review/for-approvers.md index dccc6cfe38..0cddbcba6a 100644 --- a/content/en/docs/contribute/review/for-approvers.md +++ b/content/en/docs/contribute/review/for-approvers.md @@ -2,11 +2,11 @@ title: Reviewing for approvers and reviewers linktitle: For approvers and reviewers slug: for-approvers -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + SIG Docs [Reviewers](/docs/contribute/participating/#reviewers) and [Approvers](/docs/contribute/participating/#approvers) do a few extra things when reviewing a change. @@ -19,10 +19,10 @@ requests (PRs) that are not already under active review. In addition to the rotation, a bot assigns reviewers and approvers for the PR based on the owners for the affected files. -{{% /capture %}} -{{% capture body %}} + + ## Reviewing a PR @@ -224,4 +224,3 @@ If this is a documentation issue, please re-open this issue. ``` -{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/contribute/review/reviewing-prs.md b/content/en/docs/contribute/review/reviewing-prs.md index cb432a97ba..3c271aa44f 100644 --- a/content/en/docs/contribute/review/reviewing-prs.md +++ b/content/en/docs/contribute/review/reviewing-prs.md @@ -1,11 +1,11 @@ --- title: Reviewing pull requests -content_template: templates/concept +content_type: concept main_menu: true weight: 10 --- -{{% capture overview %}} + Anyone can review a documentation pull request. Visit the [pull requests](https://github.com/kubernetes/website/pulls) section in the Kubernetes website repository to see open pull requests. @@ -19,9 +19,9 @@ Before reviewing, it's a good idea to: [style guide](/docs/contribute/style/style-guide/) so you can leave informed comments. - Understand the different [roles and responsibilities](/docs/contribute/participating/#roles-and-responsibilities) in the Kubernetes documentation community. -{{% /capture %}} -{{% capture body %}} + + ## Before you begin @@ -86,7 +86,7 @@ When reviewing, use the following as a starting point. - Did this PR change or remove a page title, slug/alias or anchor link? If so, are there broken links as a result of this PR? Is there another option, like changing the page title without changing the slug? - Does the PR introduce a new page? If so: - - Is the page using the right [page template](/docs/contribute/style/page-templates/) and associated Hugo shortcodes? + - Is the page using the right [page content type](/docs/contribute/style/page-content-types/) and associated Hugo shortcodes? - Does the page appear correctly in the section's side navigation (or at all)? - Should the page appear on the [Docs Home](/docs/home/) listing? - Do the changes show up in the Netlify preview? Be particularly vigilant about lists, code blocks, tables, notes and images. @@ -95,4 +95,3 @@ When reviewing, use the following as a starting point. For small issues with a PR, like typos or whitespace, prefix your comments with `nit:`. This lets the author know the issue is non-critical. -{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/contribute/style/content-guide.md b/content/en/docs/contribute/style/content-guide.md index b5d8ed5d02..2f367c9a81 100644 --- a/content/en/docs/contribute/style/content-guide.md +++ b/content/en/docs/contribute/style/content-guide.md @@ -1,11 +1,11 @@ --- title: Documentation Content Guide linktitle: Content guide -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + This page contains guidelines for Kubernetes documentation. @@ -17,9 +17,9 @@ You can register for Kubernetes Slack at http://slack.k8s.io/. For information on creating new content for the Kubernetes docs, follow the [style guide](/docs/contribute/style/style-guide). -{{% /capture %}} -{{% capture body %}} + + ## Overview @@ -69,10 +69,11 @@ ask for help in [#sig-docs on Kubernetes Slack](https://kubernetes.slack.com/mes If you have questions about allowed content, join the [Kubernetes Slack](http://slack.k8s.io/) #sig-docs channel and ask! -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Read the [Style guide](/docs/contribute/style/style-guide). -{{% /capture %}} + diff --git a/content/en/docs/contribute/style/content-organization.md b/content/en/docs/contribute/style/content-organization.md index e93cf8126e..249bebf0fb 100644 --- a/content/en/docs/contribute/style/content-organization.md +++ b/content/en/docs/contribute/style/content-organization.md @@ -1,17 +1,17 @@ --- title: Content organization -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + This site uses Hugo. In Hugo, [content organization](https://gohugo.io/content-management/organization/) is a core concept. -{{% /capture %}} -{{% capture body %}} + + {{% note %}} **Hugo Tip:** Start Hugo with `hugo server --navigateToChanged` for content edit-sessions. @@ -126,12 +126,13 @@ Some important notes to the files in the bundles: The [SASS](https://sass-lang.com/) source of the stylesheets for this site is stored in `assets/sass` and is automatically built by Hugo. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn about [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) * Learn about the [Style guide](/docs/contribute/style/style-guide) * Learn about the [Content guide](/docs/contribute/style/content-guide) -{{% /capture %}} + diff --git a/content/en/docs/contribute/style/hugo-shortcodes/index.md b/content/en/docs/contribute/style/hugo-shortcodes/index.md index 60479c7fec..12d00ae01a 100644 --- a/content/en/docs/contribute/style/hugo-shortcodes/index.md +++ b/content/en/docs/contribute/style/hugo-shortcodes/index.md @@ -2,16 +2,16 @@ approvers: - chenopis title: Custom Hugo Shortcodes -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + This page explains the custom Hugo shortcodes that can be used in Kubernetes markdown documentation. Read more about shortcodes in the [Hugo documentation](https://gohugo.io/content-management/shortcodes). -{{% /capture %}} -{{% capture body %}} + + ## Feature state @@ -235,12 +235,13 @@ Renders to: {{< tab name="JSON File" include="podtemplate" />}} {{< /tabs >}} -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn about [Hugo](https://gohugo.io/). -* Learn about [writing a new topic](/docs/home/contribute/write-new-topic/). -* Learn about [using page templates](/docs/home/contribute/page-templates/). +* Learn about [writing a new topic](/docs/home/contribute/style/write-new-topic/). +* Learn about [page content types](/docs/home/contribute/style/page-content-types/). * Learn about [staging your changes](/docs/home/contribute/stage-documentation-changes/) * Learn about [creating a pull request](/docs/home/contribute/create-pull-request/). -{{% /capture %}} + diff --git a/content/en/docs/contribute/style/page-content-types.md b/content/en/docs/contribute/style/page-content-types.md new file mode 100644 index 0000000000..2a3325d397 --- /dev/null +++ b/content/en/docs/contribute/style/page-content-types.md @@ -0,0 +1,221 @@ +--- +title: Page content types +content_type: concept +weight: 30 +card: + name: contribute + weight: 30 +--- + + + +The Kubernetes documentation follows several types of page content: + +- Concept +- Task +- Tutorial +- Reference + + + +## Content sections + +Each page content type contains a number of sections defined by +Markdown comments and HTML headings. You can add content headings to +your page with the `heading` shortcode. The comments and headings help +maintain the structure of the page content types. + +Examples of Markdown comments defining page content sections: + +```markdown + +``` + +```markdown + +``` + +To create common headings in your content pages, use the `heading` shortcode with +a heading string. + +Examples of heading strings: + +- whatsnext +- prerequisites +- objectives +- cleanup +- synopsis +- seealso +- options + +For example, to create a `whatsnext` heading, add the heading shortcode with the "whatsnext" string: + +```none +## {{%/* heading "whatsnext" */%}} +``` + +You can declare a `prerequisites` heading as follows: + +```none +## {{%/* heading "prerequisites" */%}} +``` + +The `heading` shortcode expects one string parameter. +The heading string parameter matches the prefix of a variable in the `i18n/.toml` files. +For example: + +`i18n/en.toml`: + +```toml +[whatsnext_heading] +other = "What's next" +``` + +`i18n/ko.toml`: + +```toml +[whatsnext_heading] +other = "다음 내용" +``` + +## Content types + +Each content type informally defines its expected page structure. +Create page content with the suggested page sections. + +### Concept + +A concept page explains some aspect of Kubernetes. For example, a concept +page might describe the Kubernetes Deployment object and explain the role it +plays as an application once it is deployed, scaled, and updated. Typically, concept +pages don't include sequences of steps, but instead provide links to tasks or +tutorials. + +To write a new concept page, create a Markdown file in a subdirectory of the +`/content/en/docs/concepts` directory, with the following characteristics: + +Concept pages are divided into three sections: + +| Page section | +|---------------| +| overview | +| body | +| whatsnext | + +The `overview` and `body` sections appear as comments in the concept page. +You can add the `whatsnext` section to your page with the `heading` shortcode. + +Fill each section with content. Follow these guidelines: + +- Organize content with H2 and H3 headings. +- For `overview`, set the topic's context with a single paragraph. +- For `body`, explain the concept. +- For `whatsnext`, provide a bulleted list of topics (5 maximum) to learn more about the concept. + +[Annotations](/docs/concepts/overview/working-with-objects/annotations/) is a published example of a concept page. + +### Task + +A task page shows how to do a single thing, typically by giving a short +sequence of steps. Task pages have minimal explanation, but often provide links +to conceptual topics that provide related background and knowledge. + +To write a new task page, create a Markdown file in a subdirectory of the +`/content/en/docs/tasks` directory, with the following characteristics: + +| Page section | +|---------------| +| overview | +| prerequisites | +| steps | +| discussion | +| whatsnext | + +The `overview`, `steps`, and `discussion` sections appear as comments in the task page. +You can add the `prerequisites` and `whatsnext` sections to your page +with the `heading` shortcode. + +Within each section, write your content. Use the following guidelines: + +- Use a minimum of H2 headings (with two leading `#` characters). The sections + themselves are titled automatically by the template. +- For `overview`, use a paragraph to set context for the entire topic. +- For `prerequisites`, use bullet lists when possible. Start adding additional + prerequisites below the `include`. The default prerequisites include a running Kubernetes cluster. +- For `steps`, use numbered lists. +- For discussion, use normal content to expand upon the information covered + in `steps`. +- For `whatsnext`, give a bullet list of up to 5 topics the reader might be + interested in reading next. + +An example of a published task topic is [Using an HTTP proxy to access the Kubernetes API](/docs/tasks/extend-kubernetes/http-proxy-access-api/). + +### Tutorial + +A tutorial page shows how to accomplish a goal that is larger than a single +task. Typically a tutorial page has several sections, each of which has a +sequence of steps. For example, a tutorial might provide a walkthrough of a +code sample that illustrates a certain feature of Kubernetes. Tutorials can +include surface-level explanations, but should link to related concept topics +for deep explanations. + +To write a new tutorial page, create a Markdown file in a subdirectory of the +`/content/en/docs/tutorials` directory, with the following characteristics: + +| Page section | +|---------------| +| overview | +| prerequisites | +| objectives | +| lessoncontent | +| cleanup | +| whatsnext | + +The `overview`, `objectives`, and `lessoncontent` sections appear as comments in the tutorial page. +You can add the `prerequisites`, `cleanup`, and `whatsnext` sections to your page +with the `heading` shortcode. + +Within each section, write your content. Use the following guidelines: + +- Use a minimum of H2 headings (with two leading `#` characters). The sections + themselves are titled automatically by the template. +- For `overview`, use a paragraph to set context for the entire topic. +- For `prerequisites`, use bullet lists when possible. Add additional + prerequisites below the ones included by default. +- For `objectives`, use bullet lists. +- For `lessoncontent`, use a mix of numbered lists and narrative content as + appropriate. +- For `cleanup`, use numbered lists to describe the steps to clean up the + state of the cluster after finishing the task. +- For `whatsnext`, give a bullet list of up to 5 topics the reader might be + interested in reading next. + +An example of a published tutorial topic is +[Running a Stateless Application Using a Deployment](/docs/tutorials/stateless-application/run-stateless-application-deployment/). + +### Reference + +A component tool reference page shows the description and flag options output for +a Kubernetes component tool. Each page generates from scripts using the component tool commands. + +A tool reference page has several possible sections: + +| Page section | +|------------------------------| +| synopsis | +| options | +| options from parent commands | +| examples | +| seealso | + +Examples of published tool reference pages are: + +- [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) +- [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) +- [kubectl](/docs/reference/kubectl/kubectl/) + +## {{% heading "whatsnext" %}} + +- Learn about the [Style guide](/docs/contribute/style/style-guide/) +- Learn about the [Content guide](/docs/contribute/style/content-guide/) +- Learn about [content organization](/docs/contribute/style/content-organization/) diff --git a/content/en/docs/contribute/style/page-templates.md b/content/en/docs/contribute/style/page-templates.md deleted file mode 100644 index 7521ee3ecb..0000000000 --- a/content/en/docs/contribute/style/page-templates.md +++ /dev/null @@ -1,222 +0,0 @@ ---- -title: Using Page Templates -content_template: templates/concept -weight: 30 -card: - name: contribute - weight: 30 ---- - -{{% capture overview %}} - -When contributing new topics, apply one of the following templates to them. -This standardizes the user experience of a given page. - -The page templates are in the -[`layouts/partials/templates`](https://git.k8s.io/website/layouts/partials/templates) -directory of the [`kubernetes/website`](https://github.com/kubernetes/website) -repository. - -{{< note >}} -Every new topic needs to use a template. If you are unsure which -template to use for a new topic, start with the -[concept template](#concept-template). -{{< /note >}} - - -{{% /capture %}} - - -{{% capture body %}} - -## Concept template - -A concept page explains some aspect of Kubernetes. For example, a concept -page might describe the Kubernetes Deployment object and explain the role it -plays as an application once it is deployed, scaled, and updated. Typically, concept -pages don't include sequences of steps, but instead provide links to tasks or -tutorials. - - -To write a new concept page, create a Markdown file in a subdirectory of the -`/content/en/docs/concepts` directory, with the following characteristics: - -- In the page's YAML front-matter, set `content_template: templates/concept`. -- In the page's body, set the required `capture` variables and any optional - ones you want to include: - - | Variable | Required? | - |---------------|-----------| - | overview | yes | - | body | yes | - | whatsnext | no | - - The page's body will look like this (remove any optional captures you don't - need): - - ``` - {{%/* capture overview */%}} - - {{%/* /capture */%}} - - {{%/* capture body */%}} - - {{%/* /capture */%}} - - {{%/* capture whatsnext */%}} - - {{%/* /capture */%}} - ``` - -- Fill each section with content. Follow these guidelines: - - Organize content with H2 and H3 headings. - - For `overview`, set the topic's context with a single paragraph. - - For `body`, explain the concept. - - For `whatsnext`, provide a bulleted list of topics (5 maximum) to learn more about the concept. - -[Annotations](/docs/concepts/overview/working-with-objects/annotations/) is a published example of the concept template. This page also uses the concept template. - -## Task template - -A task page shows how to do a single thing, typically by giving a short -sequence of steps. Task pages have minimal explanation, but often provide links -to conceptual topics that provide related background and knowledge. - -To write a new task page, create a Markdown file in a subdirectory of the -`/content/en/docs/tasks` directory, with the following characteristics: - -- In the page's YAML front-matter, set `content_template: templates/task`. -- In the page's body, set the required `capture` variables and any optional - ones you want to include: - - | Variable | Required? | - |---------------|-----------| - | overview | yes | - | prerequisites | yes | - | steps | no | - | discussion | no | - | whatsnext | no | - - The page's body will look like this (remove any optional captures you don't - need): - - ``` - {{%/* capture overview */%}} - - {{%/* /capture */%}} - - {{%/* capture prerequisites */%}} - - {{}} {{}} - - {{%/* /capture */%}} - - {{%/* capture steps */%}} - - {{%/* /capture */%}} - - {{%/* capture discussion */%}} - - {{%/* /capture */%}} - - {{%/* capture whatsnext */%}} - - {{%/* /capture */%}} - ``` - -- Within each section, write your content. Use the following guidelines: - - Use a minimum of H2 headings (with two leading `#` characters). The sections - themselves are titled automatically by the template. - - For `overview`, use a paragraph to set context for the entire topic. - - For `prerequisites`, use bullet lists when possible. Start adding additional - prerequisites below the `include`. The default prerequisites include a running Kubernetes cluster. - - For `steps`, use numbered lists. - - For discussion, use normal content to expand upon the information covered - in `steps`. - - For `whatsnext`, give a bullet list of up to 5 topics the reader might be - interested in reading next. - -An example of a published topic that uses the task template is [Using an HTTP proxy to access the Kubernetes API](/docs/tasks/access-kubernetes-api/http-proxy-access-api). - -## Tutorial template - -A tutorial page shows how to accomplish a goal that is larger than a single -task. Typically a tutorial page has several sections, each of which has a -sequence of steps. For example, a tutorial might provide a walkthrough of a -code sample that illustrates a certain feature of Kubernetes. Tutorials can -include surface-level explanations, but should link to related concept topics -for deep explanations. - -To write a new tutorial page, create a Markdown file in a subdirectory of the -`/content/en/docs/tutorials` directory, with the following characteristics: - -- In the page's YAML front-matter, set `content_template: templates/tutorial`. -- In the page's body, set the required `capture` variables and any optional - ones you want to include: - - | Variable | Required? | - |---------------|-----------| - | overview | yes | - | prerequisites | yes | - | objectives | yes | - | lessoncontent | yes | - | cleanup | no | - | whatsnext | no | - - The page's body will look like this (remove any optional captures you don't - need): - - ``` - {{%/* capture overview */%}} - - {{%/* /capture */%}} - - {{%/* capture prerequisites */%}} - - {{}} {{}} - - {{%/* /capture */%}} - - {{%/* capture objectives */%}} - - {{%/* /capture */%}} - - {{%/* capture lessoncontent */%}} - - {{%/* /capture */%}} - - {{%/* capture cleanup */%}} - - {{%/* /capture */%}} - - {{%/* capture whatsnext */%}} - - {{%/* /capture */%}} - ``` - -- Within each section, write your content. Use the following guidelines: - - Use a minimum of H2 headings (with two leading `#` characters). The sections - themselves are titled automatically by the template. - - For `overview`, use a paragraph to set context for the entire topic. - - For `prerequisites`, use bullet lists when possible. Add additional - prerequisites below the ones included by default. - - For `objectives`, use bullet lists. - - For `lessoncontent`, use a mix of numbered lists and narrative content as - appropriate. - - For `cleanup`, use numbered lists to describe the steps to clean up the - state of the cluster after finishing the task. - - For `whatsnext`, give a bullet list of up to 5 topics the reader might be - interested in reading next. - -An example of a published topic that uses the tutorial template is -[Running a Stateless Application Using a Deployment](/docs/tutorials/stateless-application/run-stateless-application-deployment/). - -{{% /capture %}} - -{{% capture whatsnext %}} - -- Learn about the [Style guide](/docs/contribute/style/style-guide/) -- Learn about the [Content guide](/docs/contribute/style/content-guide/) -- Learn about [content organization](/docs/contribute/style/content-organization/) - -{{% /capture %}} diff --git a/content/en/docs/contribute/style/style-guide.md b/content/en/docs/contribute/style/style-guide.md index 34dce6adac..78ddd4a787 100644 --- a/content/en/docs/contribute/style/style-guide.md +++ b/content/en/docs/contribute/style/style-guide.md @@ -1,26 +1,25 @@ --- title: Documentation Style Guide linktitle: Style guide -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + This page gives writing style guidelines for the Kubernetes documentation. These are guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request. For additional information on creating new content for the Kubernetes -documentation, read the [Documentation Content Guide](/docs/contribute/style/content-guide/) and follow the instructions on -[using page templates](/docs/contribute/style/page-templates/) and [creating a documentation pull request](/docs/contribute/new-content/open-a-pr). +documentation, read the [Documentation Content Guide](/docs/contribute/style/content-guide/). Changes to the style guide are made by SIG Docs as a group. To propose a change or addition, [add it to the agenda](https://docs.google.com/document/d/1ddHwLK3kUMX1wVFIwlksjTk0MsqitBnWPe1LRa1Rx5A/edit) for an upcoming SIG Docs meeting, and attend the meeting to participate in the discussion. -{{% /capture %}} -{{% capture body %}} + + {{< note >}} Kubernetes documentation uses [Blackfriday Markdown Renderer](https://github.com/russross/blackfriday) along with a few [Hugo Shortcodes](/docs/home/contribute/includes/) to support glossary entries, tabs, @@ -212,7 +211,7 @@ The output is similar to this: Code examples and configuration examples that include version information should be consistent with the accompanying text. -If the information is version specific, the Kubernetes version needs to be defined in the `prerequisites` section of the [Task template](/docs/contribute/style/page-templates/#task-template) or the [Tutorial template](/docs/contribute/style/page-templates/#tutorial-template). Once the page is saved, the `prerequisites` section is shown as **Before you begin**. +If the information is version specific, the Kubernetes version needs to be defined in the `prerequisites` section of the [Task template](/docs/contribute/style/page-content-types/#task) or the [Tutorial template](/docs/contribute/style/page-content-types/#tutorial). Once the page is saved, the `prerequisites` section is shown as **Before you begin**. To specify the Kubernetes version for a task or tutorial page, include `min-kubernetes-server-version` in the front matter of the page. @@ -585,13 +584,12 @@ The Federation feature provides ... | The new Federation feature provides ... {{< /table >}} -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn about [writing a new topic](/docs/contribute/style/write-new-topic/). -* Learn about [using page templates](/docs/contribute/style/page-templates/). +* Learn about [using page templates](/docs/contribute/style/page-content-types/). * Learn about [staging your changes](/docs/contribute/stage-documentation-changes/) -* Learn about [creating a pull request](/docs/contribute/start/#submit-a-pull-request/). - -{{% /capture %}} +* Learn about [creating a pull request](/docs/contribute/new-content/open-a-pr/). diff --git a/content/en/docs/contribute/style/write-new-topic.md b/content/en/docs/contribute/style/write-new-topic.md index 65dca22f1a..8bd4b8fbe2 100644 --- a/content/en/docs/contribute/style/write-new-topic.md +++ b/content/en/docs/contribute/style/write-new-topic.md @@ -1,19 +1,20 @@ --- title: Writing a new topic -content_template: templates/task +content_type: task weight: 20 --- -{{% capture overview %}} + This page shows how to create a new topic for the Kubernetes docs. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + Create a fork of the Kubernetes documentation repository as described in [Open a PR](/docs/new-content/open-a-pr/). -{{% /capture %}} -{{% capture steps %}} + + ## Choosing a page type @@ -27,9 +28,8 @@ Task | A task page shows how to do a single thing. The idea is to give readers a Tutorial | A tutorial page shows how to accomplish a goal that ties together several Kubernetes features. A tutorial might provide several sequences of steps that readers can actually do as they read the page. Or it might provide explanations of related pieces of code. For example, a tutorial could provide a walkthrough of a code sample. A tutorial can include brief explanations of the Kubernetes features that are being tied together, but should link to related concept topics for deep explanations of individual features. {{< /table >}} -Use a template for each new page. Each page type has a -[template](/docs/contribute/style/page-templates/) -that you can use as you write your topic. Using templates helps ensure +Use a [content type](/docs/contribute/style/page-content-types/) for each new page +that you write. Using page type helps ensure consistency among topics of a given type. ## Choosing a title and filename @@ -37,12 +37,12 @@ consistency among topics of a given type. Choose a title that has the keywords you want search engines to find. Create a filename that uses the words in your title separated by hyphens. For example, the topic with title -[Using an HTTP Proxy to Access the Kubernetes API](/docs/tasks/access-kubernetes-api/http-proxy-access-api/) +[Using an HTTP Proxy to Access the Kubernetes API](/docs/tasks/extend-kubernetes/http-proxy-access-api/) has filename `http-proxy-access-api.md`. You don't need to put "kubernetes" in the filename, because "kubernetes" is already in the URL for the topic, for example: - /docs/tasks/access-kubernetes-api/http-proxy-access-api/ + /docs/tasks/extend-kubernetes/http-proxy-access-api/ ## Adding the topic title to the front matter @@ -159,9 +159,10 @@ For an example of a topic that uses this technique, see Put image files in the `/images` directory. The preferred image format is SVG. -{{% /capture %}} -{{% capture whatsnext %}} -* Learn about [using page templates](/docs/contribute/page-templates/). + +## {{% heading "whatsnext" %}} + +* Learn about [using page content types](/docs/contribute/style/page-content-types/). * Learn about [creating a pull request](/docs/contribute/new-content/open-a-pr/). -{{% /capture %}} + diff --git a/content/en/docs/contribute/suggesting-improvements.md b/content/en/docs/contribute/suggesting-improvements.md index 19133f379b..e48c2915b9 100644 --- a/content/en/docs/contribute/suggesting-improvements.md +++ b/content/en/docs/contribute/suggesting-improvements.md @@ -1,14 +1,14 @@ --- title: Suggesting content improvements slug: suggest-improvements -content_template: templates/concept +content_type: concept weight: 10 card: name: contribute weight: 20 --- -{{% capture overview %}} + If you notice an issue with Kubernetes documentation, or have an idea for new content, then open an issue. All you need is a [GitHub account](https://github.com/join) and a web browser. @@ -16,9 +16,9 @@ In most cases, new work on Kubernetes documentation begins with an issue in GitH then review, categorize and tag issues as needed. Next, you or another member of the Kubernetes community open a pull request with changes to resolve the issue. -{{% /capture %}} -{{% capture body %}} + + ## Opening an issue @@ -62,4 +62,4 @@ Keep the following in mind when filing an issue: fellow contributors. For example, "The docs are terrible" is not helpful or polite feedback. -{{% /capture %}} + diff --git a/content/en/docs/home/_index.md b/content/en/docs/home/_index.md index 6b6e77c39a..b4f9a2ee66 100644 --- a/content/en/docs/home/_index.md +++ b/content/en/docs/home/_index.md @@ -56,8 +56,8 @@ cards: description: Anyone can contribute, whether you’re new to the project or you’ve been around a long time. button: Contribute to the docs button_path: /docs/contribute -- name: download - title: Download Kubernetes +- name: release-notes + title: Release Notes description: If you are installing Kubernetes or upgrading to the newest version, refer to the current release notes. - name: about title: About the documentation diff --git a/content/en/docs/home/supported-doc-versions.md b/content/en/docs/home/supported-doc-versions.md index 45a6012eaa..bd368b2b54 100644 --- a/content/en/docs/home/supported-doc-versions.md +++ b/content/en/docs/home/supported-doc-versions.md @@ -1,20 +1,20 @@ --- title: Supported Versions of the Kubernetes Documentation -content_template: templates/concept +content_type: concept card: name: about weight: 10 title: Supported Versions of the Documentation --- -{{% capture overview %}} + This website contains documentation for the current version of Kubernetes and the four previous versions of Kubernetes. -{{% /capture %}} -{{% capture body %}} + + ## Current version @@ -25,6 +25,6 @@ The current version is {{< versions-other >}} -{{% /capture %}} + diff --git a/content/en/docs/reference/_index.md b/content/en/docs/reference/_index.md index 8b0faf5e91..619430875e 100644 --- a/content/en/docs/reference/_index.md +++ b/content/en/docs/reference/_index.md @@ -5,16 +5,16 @@ approvers: linkTitle: "Reference" main_menu: true weight: 70 -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + This section of the Kubernetes documentation contains references. -{{% /capture %}} -{{% capture body %}} + + ## API Reference @@ -52,4 +52,4 @@ client libraries: An archive of the design docs for Kubernetes functionality. Good starting points are [Kubernetes Architecture](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) and [Kubernetes Design Overview](https://git.k8s.io/community/contributors/design-proposals). -{{% /capture %}} + diff --git a/content/en/docs/reference/access-authn-authz/abac.md b/content/en/docs/reference/access-authn-authz/abac.md index 40c56a985c..3810942660 100644 --- a/content/en/docs/reference/access-authn-authz/abac.md +++ b/content/en/docs/reference/access-authn-authz/abac.md @@ -5,15 +5,15 @@ reviewers: - deads2k - liggitt title: Using ABAC Authorization -content_template: templates/concept +content_type: concept weight: 80 --- -{{% capture overview %}} + Attribute-based access control (ABAC) defines an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together. -{{% /capture %}} -{{% capture body %}} + + ## Policy File Format To enable `ABAC` mode, specify `--authorization-policy-file=SOME_FILENAME` and `--authorization-mode=ABAC` on startup. @@ -152,5 +152,5 @@ privilege to the API using ABAC, you would add this line to your policy file: The apiserver will need to be restarted to pickup the new policy lines. -{{% /capture %}} + diff --git a/content/en/docs/reference/access-authn-authz/admission-controllers.md b/content/en/docs/reference/access-authn-authz/admission-controllers.md index a254e43a84..e0f5ea0f43 100644 --- a/content/en/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md @@ -7,15 +7,15 @@ reviewers: - janetkuo - thockin title: Using Admission Controllers -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + This page provides an overview of Admission Controllers. -{{% /capture %}} -{{% capture body %}} + + ## What are they? An admission controller is a piece of code that intercepts requests to the @@ -32,6 +32,8 @@ which are configured in the API. Admission controllers may be "validating", "mutating", or both. Mutating controllers may modify the objects they admit; validating controllers may not. +Admission controllers limit requests to create, delete, modify or connect to (proxy). They do not support read requests. + The admission control process proceeds in two phases. In the first phase, mutating admission controllers are run. In the second phase, validating admission controllers are run. Note again that some of the controllers are @@ -610,7 +612,7 @@ node selector. 2. If the namespace lacks such an annotation, use the `clusterDefaultNodeSelector` defined in the `PodNodeSelector` plugin configuration file as the node selector. 3. Evaluate the pod's node selector against the namespace node selector for conflicts. Conflicts result in rejection. -4. Evaluate the pod's node selector against the namespace-specific whitelist defined the plugin configuration file. +4. Evaluate the pod's node selector against the namespace-specific allowed selector defined the plugin configuration file. Conflicts result in rejection. {{< note >}} @@ -672,15 +674,15 @@ for more information. The PodTolerationRestriction admission controller verifies any conflict between tolerations of a pod and the tolerations of its namespace. It rejects the pod request if there is a conflict. It then merges the tolerations annotated on the namespace into the tolerations of the pod. -The resulting tolerations are checked against a whitelist of tolerations annotated to the namespace. +The resulting tolerations are checked against a list of allowed tolerations annotated to the namespace. If the check succeeds, the pod request is admitted otherwise it is rejected. -If the namespace of the pod does not have any associated default tolerations or a whitelist of -tolerations annotated, the cluster-level default tolerations or cluster-level whitelist of tolerations are used +If the namespace of the pod does not have any associated default tolerations or allowed +tolerations annotated, the cluster-level default tolerations or cluster-level list of allowed tolerations are used instead if they are specified. Tolerations to a namespace are assigned via the `scheduler.alpha.kubernetes.io/defaultTolerations` annotation key. -The whitelist can be added via the `scheduler.alpha.kubernetes.io/tolerationsWhitelist` annotation key. +The list of allowed tolerations can be added via the `scheduler.alpha.kubernetes.io/tolerationsWhitelist` annotation key. Example for namespace annotations: @@ -773,4 +775,4 @@ in the mutating phase. For earlier versions, there was no concept of validating versus mutating and the admission controllers ran in the exact order specified. -{{% /capture %}} + diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md index 8ab609a0cc..66119cf7b0 100644 --- a/content/en/docs/reference/access-authn-authz/authentication.md +++ b/content/en/docs/reference/access-authn-authz/authentication.md @@ -6,15 +6,15 @@ reviewers: - deads2k - liggitt title: Authenticating -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + This page provides an overview of authenticating. -{{% /capture %}} -{{% capture body %}} + + ## Users in Kubernetes All Kubernetes clusters have two categories of users: service accounts managed @@ -840,4 +840,4 @@ RFC3339 timestamp. Presence or absence of an expiry has the following impact: } } ``` -{{% /capture %}} + diff --git a/content/en/docs/reference/access-authn-authz/authorization.md b/content/en/docs/reference/access-authn-authz/authorization.md index 3a942266fc..74c433b8ee 100644 --- a/content/en/docs/reference/access-authn-authz/authorization.md +++ b/content/en/docs/reference/access-authn-authz/authorization.md @@ -5,16 +5,16 @@ reviewers: - deads2k - liggitt title: Authorization Overview -content_template: templates/concept +content_type: concept weight: 60 --- -{{% capture overview %}} + Learn more about Kubernetes authorization, including details about creating policies using the supported authorization modules. -{{% /capture %}} -{{% capture body %}} + + In Kubernetes, you must be authenticated (logged in) before your request can be authorized (granted permission to access). For information about authentication, see [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/). @@ -197,9 +197,10 @@ namespace can: read all secrets in the namespace; read all config maps in the namespace; and impersonate any service account in the namespace and take any action the account could take. This applies regardless of authorization mode. {{< /caution >}} -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * To learn more about Authentication, see **Authentication** in [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/). * To learn more about Admission Control, see [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/). -{{% /capture %}} + diff --git a/content/en/docs/reference/access-authn-authz/bootstrap-tokens.md b/content/en/docs/reference/access-authn-authz/bootstrap-tokens.md index c8c55c08d6..542b5267be 100644 --- a/content/en/docs/reference/access-authn-authz/bootstrap-tokens.md +++ b/content/en/docs/reference/access-authn-authz/bootstrap-tokens.md @@ -2,11 +2,11 @@ reviewers: - jbeda title: Authenticating with Bootstrap Tokens -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.18" state="stable" >}} @@ -16,9 +16,9 @@ to support [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), but can be u for users that wish to start clusters without `kubeadm`. It is also built to work, via RBAC policy, with the [Kubelet TLS Bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) system. -{{% /capture %}} -{{% capture body %}} + + ## Bootstrap Tokens Overview Bootstrap Tokens are defined with a specific type @@ -188,4 +188,4 @@ client relying on the signature to bootstrap TLS trust. Consult the [kubeadm implementation details](/docs/reference/setup-tools/kubeadm/implementation-details/) section for more information. -{{% /capture %}} + diff --git a/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md b/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md index 3e81215dd8..fea62e545e 100644 --- a/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md +++ b/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md @@ -4,11 +4,11 @@ reviewers: - mikedanese - munnerz title: Certificate Signing Requests -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.18" state="beta" >}} @@ -21,9 +21,9 @@ A CertificateSigningRequest (CSR) resource is used to request that a certificate by a denoted signer, after which the request may be approved or denied before finally being signed. -{{% /capture %}} -{{% capture body %}} + + ## Request signing process The _CertificateSigningRequest_ resource type allows a client to ask for an X.509 certificate @@ -317,9 +317,10 @@ subresource of the CSR to be signed. As part of this request, the `status.certificate` field should be set to contain the signed certificate. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Read [Manage TLS Certificates in a Cluster](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/) * View the source code for the kube-controller-manager built in [signer](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/signer/cfssl_signer.go) @@ -327,4 +328,4 @@ signed certificate. * For details of X.509 itself, refer to [RFC 5280](https://tools.ietf.org/html/rfc5280#section-3.1) section 3.1 * For information on the syntax of PKCS#10 certificate signing requests, refer to [RFC 2986](https://tools.ietf.org/html/rfc2986) -{{% /capture %}} + diff --git a/content/en/docs/reference/access-authn-authz/controlling-access.md b/content/en/docs/reference/access-authn-authz/controlling-access.md index 21c08447ff..e0273177aa 100644 --- a/content/en/docs/reference/access-authn-authz/controlling-access.md +++ b/content/en/docs/reference/access-authn-authz/controlling-access.md @@ -3,15 +3,15 @@ reviewers: - erictune - lavalamp title: Controlling Access to the Kubernetes API -content_template: templates/concept +content_type: concept weight: 5 --- -{{% capture overview %}} + This page provides an overview of controlling access to the Kubernetes API. -{{% /capture %}} -{{% capture body %}} + + Users [access the API](/docs/tasks/access-application-cluster/access-cluster/) using `kubectl`, client libraries, or by making REST requests. Both human users and [Kubernetes service accounts](/docs/tasks/configure-pod-container/configure-service-account/) can be @@ -23,7 +23,7 @@ following diagram: ## Transport Security -In a typical Kubernetes cluster, the API serves on port 6443. +In a typical Kubernetes cluster, the API serves on port 443. The API server presents a certificate. This certificate is often self-signed, so `$USER/.kube/config` on the user's machine typically contains the root certificate for the API server's certificate, which when specified @@ -63,9 +63,9 @@ users in its object store. ## Authorization -After the request is authenticated as coming from a specific user, the request must be authorized. This is shown as step **2** in the diagram. +After the request is authenticated as coming from a specific user, the request must be authorized. This is shown as step **2** in the diagram. -A request must include the username of the requester, the requested action, and the object affected by the action. The request is authorized if an existing policy declares that the user has permissions to complete the requested action. +A request must include the username of the requester, the requested action, and the object affected by the action. The request is authorized if an existing policy declares that the user has permissions to complete the requested action. For example, if Bob has the policy below, then he can read pods only in the namespace `projectCaribou`: @@ -97,7 +97,7 @@ If Bob makes the following request, the request is authorized because he is allo } } ``` -If Bob makes a request to write (`create` or `update`) to the objects in the `projectCaribou` namespace, his authorization is denied. If Bob makes a request to read (`get`) objects in a different namespace such as `projectFish`, then his authorization is denied. +If Bob makes a request to write (`create` or `update`) to the objects in the `projectCaribou` namespace, his authorization is denied. If Bob makes a request to read (`get`) objects in a different namespace such as `projectFish`, then his authorization is denied. Kubernetes authorization requires that you use common REST attributes to interact with existing organization-wide or cloud-provider-wide access control systems. It is important to use REST formatting because these control systems might interact with other APIs besides the Kubernetes API. @@ -110,10 +110,11 @@ To learn more about Kubernetes authorization, including details about creating p Admission Control Modules are software modules that can modify or reject requests. In addition to the attributes available to Authorization Modules, Admission -Control Modules can access the contents of the object that is being created or updated. -They act on objects being created, deleted, updated or connected (proxy), but not reads. +Control Modules can access the contents of the object that is being created or modified. -Multiple admission controllers can be configured. Each is called in order. +Admission controllers act on requests that create, modify, delete, or connect to (proxy) an object. +Admission controllers do not act on requests that merely read objects. +When multiple admission controllers are configured, they are called in order. This is shown as step **3** in the diagram. @@ -161,4 +162,4 @@ When the cluster is created by `kube-up.sh`, on Google Compute Engine (GCE), and on several other cloud providers, the API server serves on port 443. On GCE, a firewall rule is configured on the project to allow external HTTPS access to the API. Other cluster setup methods vary. -{{% /capture %}} + diff --git a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md index 40d00cddf4..718c9d1147 100644 --- a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md +++ b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md @@ -7,18 +7,17 @@ reviewers: - liggitt - jpbetz title: Dynamic Admission Control -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + In addition to [compiled-in admission plugins](/docs/reference/access-authn-authz/admission-controllers/), admission plugins can be developed as extensions and run as webhooks configured at runtime. This page describes how to build, configure, use, and monitor admission webhooks. -{{% /capture %}} -{{% capture body %}} + ## What are admission webhooks? Admission webhooks are HTTP callbacks that receive admission requests and do @@ -1589,4 +1588,4 @@ If your admission webhooks don't intend to modify the behavior of the Kubernetes plane, exclude the `kube-system` namespace from being intercepted using a [`namespaceSelector`](#matching-requests-namespaceselector). -{{% /capture %}} + diff --git a/content/en/docs/reference/access-authn-authz/node.md b/content/en/docs/reference/access-authn-authz/node.md index 6c0e2f3e99..439d97ff84 100644 --- a/content/en/docs/reference/access-authn-authz/node.md +++ b/content/en/docs/reference/access-authn-authz/node.md @@ -5,15 +5,15 @@ reviewers: - liggitt - ericchiang title: Using Node Authorization -content_template: templates/concept +content_type: concept weight: 90 --- -{{% capture overview %}} + Node authorization is a special-purpose authorization mode that specifically authorizes API requests made by kubelets. -{{% /capture %}} -{{% capture body %}} + + ## Overview The Node authorizer allows a kubelet to perform API operations. This includes: @@ -96,4 +96,4 @@ In 1.8, the binding will not be created at all. When using RBAC, the `system:node` cluster role will continue to be created, for compatibility with deployment methods that bind other users or groups to that role. -{{% /capture %}} + diff --git a/content/en/docs/reference/access-authn-authz/rbac.md b/content/en/docs/reference/access-authn-authz/rbac.md index 15a4347fea..20b1224e59 100644 --- a/content/en/docs/reference/access-authn-authz/rbac.md +++ b/content/en/docs/reference/access-authn-authz/rbac.md @@ -4,17 +4,17 @@ reviewers: - deads2k - liggitt title: Using RBAC Authorization -content_template: templates/concept +content_type: concept aliases: [/rbac/] weight: 70 --- -{{% capture overview %}} + Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within your organization. -{{% /capture %}} -{{% capture body %}} + + RBAC authorization uses the `rbac.authorization.k8s.io` {{< glossary_tooltip text="API group" term_id="api-group" >}} to drive authorization decisions, allowing you to dynamically configure policies through the Kubernetes API. @@ -1209,5 +1209,3 @@ kubectl create clusterrolebinding permissive-binding \ After you have transitioned to use RBAC, you should adjust the access controls for your cluster to ensure that these meet your information security needs. - -{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/reference/access-authn-authz/service-accounts-admin.md b/content/en/docs/reference/access-authn-authz/service-accounts-admin.md index 5c2dd3ddc5..6d2cf76573 100644 --- a/content/en/docs/reference/access-authn-authz/service-accounts-admin.md +++ b/content/en/docs/reference/access-authn-authz/service-accounts-admin.md @@ -5,19 +5,19 @@ reviewers: - lavalamp - liggitt title: Managing Service Accounts -content_template: templates/concept +content_type: concept weight: 50 --- -{{% capture overview %}} + This is a Cluster Administrator guide to service accounts. It assumes knowledge of the [User Guide to Service Accounts](/docs/user-guide/service-accounts). Support for authorization and user accounts is planned but incomplete. Sometimes incomplete features are referred to in order to better describe service accounts. -{{% /capture %}} -{{% capture body %}} + + ## User accounts versus service accounts Kubernetes distinguishes between the concept of a user account and a service account @@ -115,4 +115,4 @@ kubectl delete secret mysecretname Service Account Controller manages ServiceAccount inside namespaces, and ensures a ServiceAccount named "default" exists in every active namespace. -{{% /capture %}} + diff --git a/content/en/docs/reference/access-authn-authz/webhook.md b/content/en/docs/reference/access-authn-authz/webhook.md index 3f667fa5ef..69be02ff76 100644 --- a/content/en/docs/reference/access-authn-authz/webhook.md +++ b/content/en/docs/reference/access-authn-authz/webhook.md @@ -5,15 +5,15 @@ reviewers: - deads2k - liggitt title: Webhook Mode -content_template: templates/concept +content_type: concept weight: 95 --- -{{% capture overview %}} + A WebHook is an HTTP callback: an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST. A web application implementing WebHooks will POST a message to a URL when certain things happen. -{{% /capture %}} -{{% capture body %}} + + When specified, mode `Webhook` causes Kubernetes to query an outside REST service when determining user privileges. @@ -164,8 +164,8 @@ Access to non-resource paths are sent as: } ``` -Non-resource paths include: `/api`, `/apis`, `/metrics`, `/resetMetrics`, -`/logs`, `/debug`, `/healthz`, `/swagger-ui/`, `/swaggerapi/`, `/ui`, and +Non-resource paths include: `/api`, `/apis`, `/metrics`, +`/logs`, `/debug`, `/healthz`, `/livez`, `/openapi/v2`, `/readyz`, and `/version.` Clients require access to `/api`, `/api/*`, `/apis`, `/apis/*`, and `/version` to discover what resources and versions are present on the server. Access to other non-resource paths can be disallowed without restricting access @@ -174,6 +174,3 @@ to the REST api. For further documentation refer to the authorization.v1beta1 API objects and [webhook.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go). -{{% /capture %}} - - diff --git a/content/en/docs/reference/command-line-tools-reference/cloud-controller-manager.md b/content/en/docs/reference/command-line-tools-reference/cloud-controller-manager.md index ee8d7f1ed1..982eb0993e 100644 --- a/content/en/docs/reference/command-line-tools-reference/cloud-controller-manager.md +++ b/content/en/docs/reference/command-line-tools-reference/cloud-controller-manager.md @@ -1,10 +1,11 @@ --- title: cloud-controller-manager -content_template: templates/tool-reference +content_type: tool-reference weight: 30 --- -{{% capture synopsis %}} +## {{% heading "synopsis" %}} + The Cloud controller manager is a daemon that embeds @@ -14,9 +15,10 @@ the cloud specific control loops shipped with Kubernetes. cloud-controller-manager [flags] ``` -{{% /capture %}} -{{% capture options %}} + +## {{% heading "options" %}} + @@ -534,5 +536,5 @@ cloud-controller-manager [flags] -{{% /capture %}} + diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index aa8365ed90..82983b2282 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -1,17 +1,17 @@ --- weight: 10 title: Feature Gates -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + This page contains an overview of the various feature gates an administrator can specify on different Kubernetes components. See [feature stages](#feature-stages) for an explanation of the stages for a feature. -{{% /capture %}} -{{% capture body %}} + + ## Overview Feature gates are a set of key=value pairs that describe Kubernetes features. @@ -512,8 +512,9 @@ Each feature gate is designed for enabling/disabling a specific feature: - `WinDSR`: Allows kube-proxy to create DSR loadbalancers for Windows. - `WinOverlay`: Allows kube-proxy to run in overlay mode for Windows. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * The [deprecation policy](/docs/reference/using-api/deprecation-policy/) for Kubernetes explains the project's approach to removing features and components. -{{% /capture %}} + diff --git a/content/en/docs/reference/command-line-tools-reference/kube-apiserver.md b/content/en/docs/reference/command-line-tools-reference/kube-apiserver.md index 6e9454dc49..01cf6a87b8 100644 --- a/content/en/docs/reference/command-line-tools-reference/kube-apiserver.md +++ b/content/en/docs/reference/command-line-tools-reference/kube-apiserver.md @@ -1,10 +1,11 @@ --- title: kube-apiserver -content_template: templates/tool-reference +content_type: tool-reference weight: 30 --- -{{% capture synopsis %}} +## {{% heading "synopsis" %}} + The Kubernetes API server validates and configures data @@ -16,9 +17,10 @@ cluster's shared state through which all other components interact. kube-apiserver [flags] ``` -{{% /capture %}} -{{% capture options %}} + +## {{% heading "options" %}} +
@@ -1082,5 +1084,5 @@ kube-apiserver [flags] -{{% /capture %}} + diff --git a/content/en/docs/reference/command-line-tools-reference/kube-controller-manager.md b/content/en/docs/reference/command-line-tools-reference/kube-controller-manager.md index 69be42b17e..75fed787d0 100644 --- a/content/en/docs/reference/command-line-tools-reference/kube-controller-manager.md +++ b/content/en/docs/reference/command-line-tools-reference/kube-controller-manager.md @@ -1,10 +1,11 @@ --- title: kube-controller-manager -content_template: templates/tool-reference +content_type: tool-reference weight: 30 --- -{{% capture synopsis %}} +## {{% heading "synopsis" %}} + The Kubernetes controller manager is a daemon that embeds @@ -20,9 +21,10 @@ controller, and serviceaccounts controller. kube-controller-manager [flags] ``` -{{% /capture %}} -{{% capture options %}} + +## {{% heading "options" %}} +
@@ -897,5 +899,5 @@ kube-controller-manager [flags] -{{% /capture %}} + diff --git a/content/en/docs/reference/command-line-tools-reference/kube-proxy.md b/content/en/docs/reference/command-line-tools-reference/kube-proxy.md index 1ad3f6ee15..535bd81aa6 100644 --- a/content/en/docs/reference/command-line-tools-reference/kube-proxy.md +++ b/content/en/docs/reference/command-line-tools-reference/kube-proxy.md @@ -1,10 +1,11 @@ --- title: kube-proxy -content_template: templates/tool-reference +content_type: tool-reference weight: 30 --- -{{% capture synopsis %}} +## {{% heading "synopsis" %}} + The Kubernetes network proxy runs on each node. This @@ -19,9 +20,10 @@ with the apiserver API to configure the proxy. kube-proxy [flags] ``` -{{% /capture %}} -{{% capture options %}} + +## {{% heading "options" %}} +
@@ -336,5 +338,5 @@ kube-proxy [flags] -{{% /capture %}} + diff --git a/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md b/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md index f807c5d024..d510610140 100644 --- a/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md +++ b/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md @@ -1,10 +1,11 @@ --- title: kube-scheduler -content_template: templates/tool-reference +content_type: tool-reference weight: 30 --- -{{% capture synopsis %}} +## {{% heading "synopsis" %}} + The Kubernetes scheduler is a policy-rich, topology-aware, @@ -20,9 +21,10 @@ for more information about scheduling and the kube-scheduler component. kube-scheduler [flags] ``` -{{% /capture %}} -{{% capture options %}} + +## {{% heading "options" %}} +
@@ -512,5 +514,5 @@ kube-scheduler [flags] -{{% /capture %}} + diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md b/content/en/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md index 2e408ff18b..b2a99213ed 100644 --- a/content/en/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md +++ b/content/en/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md @@ -4,7 +4,6 @@ reviewers: title: Kubelet authentication/authorization --- -{{< toc >}} ## Overview diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md b/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md index 6269a3ec5a..0daa490276 100644 --- a/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md +++ b/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md @@ -5,28 +5,28 @@ reviewers: - smarterclayton - awly title: TLS bootstrapping -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + In a Kubernetes cluster, the components on the worker nodes - kubelet and kube-proxy - need to communicate with Kubernetes master components, specifically kube-apiserver. In order to ensure that communication is kept private, not interfered with, and ensure that each component of the cluster is talking to another trusted component, we strongly recommend using client TLS certificates on nodes. -The normal process of bootstrapping these components, especially worker nodes that need certificates so they can communicate safely with kube-apiserver, -can be a challenging process as it is often outside of the scope of Kubernetes and requires significant additional work. +The normal process of bootstrapping these components, especially worker nodes that need certificates so they can communicate safely with kube-apiserver, +can be a challenging process as it is often outside of the scope of Kubernetes and requires significant additional work. This in turn, can make it challenging to initialize or scale a cluster. In order to simplify the process, beginning in version 1.4, Kubernetes introduced a certificate request and signing API to simplify the process. The proposal can be found [here](https://github.com/kubernetes/kubernetes/pull/20439). This document describes the process of node initialization, how to set up TLS client certificate bootstrapping for -kubelets, and how it works. +kubelets, and how it works. -{{% /capture %}} -{{% capture body %}} + + ## Initialization Process When a worker node starts up, the kubelet does the following: @@ -90,7 +90,7 @@ In addition, you need your Kubernetes Certificate Authority (CA). As without bootstrapping, you will need a Certificate Authority (CA) key and certificate. As without bootstrapping, these will be used to sign the kubelet certificate. As before, it is your responsibility to distribute them to master nodes. -For the purposes of this document, we will assume these have been distributed to master nodes at `/var/lib/kubernetes/ca.pem` (certificate) and `/var/lib/kubernetes/ca-key.pem` (key). +For the purposes of this document, we will assume these have been distributed to master nodes at `/var/lib/kubernetes/ca.pem` (certificate) and `/var/lib/kubernetes/ca-key.pem` (key). We will refer to these as "Kubernetes CA certificate and key". All Kubernetes components that use these certificates - kubelet, kube-apiserver, kube-controller-manager - assume the key and certificate to be PEM-encoded. @@ -98,7 +98,7 @@ All Kubernetes components that use these certificates - kubelet, kube-apiserver, ## kube-apiserver configuration The kube-apiserver has several requirements to enable TLS bootstrapping: -* Recognizing CA that signs the client certificate +* Recognizing CA that signs the client certificate * Authenticating the bootstrapping kubelet to the `system:bootstrappers` group * Authorize the bootstrapping kubelet to create a certificate signing request (CSR) @@ -120,13 +120,13 @@ of provisioning. 1. [Bootstrap Tokens](#bootstrap-tokens) 2. [Token authentication file](#token-authentication-file) -Bootstrap tokens are a simpler and more easily managed method to authenticate kubelets, and do not require any additional flags when starting kube-apiserver. +Bootstrap tokens are a simpler and more easily managed method to authenticate kubelets, and do not require any additional flags when starting kube-apiserver. Using bootstrap tokens is currently __beta__ as of Kubernetes version 1.12. Whichever method you choose, the requirement is that the kubelet be able to authenticate as a user with the rights to: 1. create and retrieve CSRs -2. be automatically approved to request node client certificates, if automatic approval is enabled. +2. be automatically approved to request node client certificates, if automatic approval is enabled. A kubelet authenticating using bootstrap tokens is authenticated as a user in the group `system:bootstrappers`, which is the standard method to use. @@ -152,7 +152,7 @@ From the kube-apiserver's perspective, however, the bootstrap token is special. and grants anyone authenticating with that token special bootstrap rights, notably treating them as a member of the `system:bootstrappers` group. This fulfills a basic requirement for TLS bootstrapping. -The details for creating the secret are available [here](/docs/reference/access-authn-authz/bootstrap-tokens/). +The details for creating the secret are available [here](/docs/reference/access-authn-authz/bootstrap-tokens/). If you want to use bootstrap tokens, you must enable it on kube-apiserver with the flag: @@ -161,7 +161,7 @@ If you want to use bootstrap tokens, you must enable it on kube-apiserver with t ``` #### Token authentication file -kube-apiserver has an ability to accept tokens as authentication. +kube-apiserver has an ability to accept tokens as authentication. These tokens are arbitrary but should represent at least 128 bits of entropy derived from a secure random number generator (such as `/dev/urandom` on most modern Linux systems). There are multiple ways you can generate a token. For example: @@ -252,8 +252,8 @@ RBAC permissions to the correct group. There are two distinct sets of permissions: -* `nodeclient`: If a node is creating a new certificate for a node, then it does not have a certificate yet. It is authenticating using one of the tokens listed above, and thus is part of the group `system:bootstrappers`. -* `selfnodeclient`: If a node is renewing its certificate, then it already has a certificate (by definition), which it uses continuously to authenticate as part of the group `system:nodes`. +* `nodeclient`: If a node is creating a new certificate for a node, then it does not have a certificate yet. It is authenticating using one of the tokens listed above, and thus is part of the group `system:bootstrappers`. +* `selfnodeclient`: If a node is renewing its certificate, then it already has a certificate (by definition), which it uses continuously to authenticate as part of the group `system:nodes`. To enable the kubelet to request and receive a new certificate, create a `ClusterRoleBinding` that binds the group in which the bootstrapping node is a member `system:bootstrappers` to the `ClusterRole` that grants it permission, `system:certificates.k8s.io:certificatesigningrequests:nodeclient`: @@ -273,7 +273,7 @@ roleRef: apiGroup: rbac.authorization.k8s.io ``` -To enable the kubelet to renew its own client certificate, create a `ClusterRoleBinding` that binds the group in which the fully functioning node is a member `system:nodes` to the `ClusterRole` that +To enable the kubelet to renew its own client certificate, create a `ClusterRoleBinding` that binds the group in which the fully functioning node is a member `system:nodes` to the `ClusterRole` that grants it permission, `system:certificates.k8s.io:certificatesigningrequests:selfnodeclient`: ```yml @@ -382,7 +382,7 @@ To secure these, the kubelet can do one of: * request serving certificates from the cluster server, via the CSR API The client certificate provided by TLS bootstrapping is signed, by default, for `client auth` only, and thus cannot -be used as serving certificates, or `server auth`. +be used as serving certificates, or `server auth`. However, you _can_ enable its server certificate, at least partially, via certificate rotation. @@ -443,15 +443,3 @@ also manually approve certificate requests using kubectl. An administrator can list CSRs with `kubectl get csr` and describe one in detail with `kubectl describe csr `. An administrator can approve or deny a CSR with `kubectl certificate approve ` and `kubectl certificate deny `. - - -## Limits -Although Kubernetes supports running control plane master components like kube-apiserver and kube-controller-manager in containers, and even as `Pod`s in a kubelet, as of this writing, you cannot both TLS Bootstrap a kubelet and run master plane components on it. - -The reason for this limitation is that the kubelet attempts to bootstrap communication with kube-apiserver _before_ starting any pods, even static ones define on disk and referenced via the kubelet option `--pod-manifest-path=`. Trying to do both TLS Bootstrapping and master components in kubelet leads to a race condition: kubelet needs to communicate to kube-apiserver to request certificates, yet requires those certificates to be available to start kube-apiserver. - -An issue is open referencing this [here](https://github.com/kubernetes/kubernetes/issues/68686). - - - -{{% /capture %}} diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet.md b/content/en/docs/reference/command-line-tools-reference/kubelet.md index 595ef138fc..54dc1a84d9 100644 --- a/content/en/docs/reference/command-line-tools-reference/kubelet.md +++ b/content/en/docs/reference/command-line-tools-reference/kubelet.md @@ -1,10 +1,11 @@ --- title: kubelet -content_template: templates/tool-reference +content_type: tool-reference weight: 28 --- -{{% capture synopsis %}} +## {{% heading "synopsis" %}} + The kubelet is the primary "node agent" that runs on each node. It can register the node with the apiserver using one of: the hostname; a flag to override the hostname; or specific logic for a cloud provider. @@ -24,10 +25,11 @@ HTTP server: The kubelet can also listen for HTTP and respond to a simple API (u kubelet [flags] ``` -{{% /capture %}} -{{% capture options %}} + +## {{% heading "options" %}} +
@@ -1265,4 +1267,4 @@ kubelet [flags]
-{{% /capture %}} + diff --git a/content/en/docs/reference/glossary/aggregation-layer.md b/content/en/docs/reference/glossary/aggregation-layer.md index e5bafd9c06..620460429c 100644 --- a/content/en/docs/reference/glossary/aggregation-layer.md +++ b/content/en/docs/reference/glossary/aggregation-layer.md @@ -14,6 +14,6 @@ tags: --- The aggregation layer lets you install additional Kubernetes-style APIs in your cluster. - + -When you've configured the {{< glossary_tooltip text="Kubernetes API Server" term_id="kube-apiserver" >}} to [support additional APIs](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/), you can add `APIService` objects to "claim" a URL path in the Kubernetes API. +When you've configured the {{< glossary_tooltip text="Kubernetes API Server" term_id="kube-apiserver" >}} to [support additional APIs](/docs/tasks/extend-kubernetes/configure-aggregation-layer/), you can add `APIService` objects to "claim" a URL path in the Kubernetes API. diff --git a/content/en/docs/reference/glossary/cronjob.md b/content/en/docs/reference/glossary/cronjob.md index abfdfe3705..b795fd6d5c 100755 --- a/content/en/docs/reference/glossary/cronjob.md +++ b/content/en/docs/reference/glossary/cronjob.md @@ -11,7 +11,7 @@ tags: - core-object - workload --- - Manages a [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) that runs on a periodic schedule. + Manages a [Job](/docs/concepts/workloads/controllers/job/) that runs on a periodic schedule. diff --git a/content/en/docs/reference/glossary/customresourcedefinition.md b/content/en/docs/reference/glossary/customresourcedefinition.md index 16f4a69411..9e6ec9c7c5 100755 --- a/content/en/docs/reference/glossary/customresourcedefinition.md +++ b/content/en/docs/reference/glossary/customresourcedefinition.md @@ -2,7 +2,7 @@ title: CustomResourceDefinition id: CustomResourceDefinition date: 2018-04-12 -full_link: /docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/ +full_link: /docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/ short_description: > Custom code that defines a resource to add to your Kubernetes API server without building a complete custom server. @@ -14,7 +14,6 @@ tags: --- Custom code that defines a resource to add to your Kubernetes API server without building a complete custom server. - - -Custom Resource Definitions let you extend the Kubernetes API for your environment if the publicly supported API resources can't meet your needs. + +Custom Resource Definitions let you extend the Kubernetes API for your environment if the publicly supported API resources can't meet your needs. diff --git a/content/en/docs/reference/glossary/job.md b/content/en/docs/reference/glossary/job.md index af8cfa0c37..98a189e69e 100755 --- a/content/en/docs/reference/glossary/job.md +++ b/content/en/docs/reference/glossary/job.md @@ -2,7 +2,7 @@ title: Job id: job date: 2018-04-12 -full_link: /docs/concepts/workloads/controllers/jobs-run-to-completion +full_link: /docs/concepts/workloads/controllers/job/ short_description: > A finite or batch task that runs to completion. diff --git a/content/en/docs/reference/issues-security/security.md b/content/en/docs/reference/issues-security/security.md index d162e5c18c..b9b1ce7c37 100644 --- a/content/en/docs/reference/issues-security/security.md +++ b/content/en/docs/reference/issues-security/security.md @@ -6,15 +6,15 @@ reviewers: - erictune - philips - jessfraz -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + This page describes Kubernetes security and disclosure information. -{{% /capture %}} -{{% capture body %}} + + ## Security Announcements Join the [kubernetes-security-announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce) group for emails about security and major API announcements. @@ -56,4 +56,4 @@ As the security issue moves from triage, to identified fix, to release planning ## Public Disclosure Timing A public disclosure date is negotiated by the Kubernetes Product Security Committee and the bug submitter. We prefer to fully disclose the bug as soon as possible once a user mitigation is available. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested, or for vendor coordination. The timeframe for disclosure is from immediate (especially if it's already publicly known) to a few weeks. For a vulnerability with a straightforward mitigation, we expect report date to disclosure date to be on the order of 7 days. The Kubernetes Product Security Committee holds the final say when setting a disclosure date. -{{% /capture %}} + diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md index dbf0e2dc63..23d074456c 100644 --- a/content/en/docs/reference/kubectl/cheatsheet.md +++ b/content/en/docs/reference/kubectl/cheatsheet.md @@ -4,21 +4,21 @@ reviewers: - erictune - krousey - clove -content_template: templates/concept +content_type: concept card: name: reference weight: 30 --- -{{% capture overview %}} + See also: [Kubectl Overview](/docs/reference/kubectl/overview/) and [JsonPath Guide](/docs/reference/kubectl/jsonpath). This page is an overview of the `kubectl` command. -{{% /capture %}} -{{% capture body %}} + + # kubectl - Cheat Sheet @@ -382,9 +382,10 @@ Verbosity | Description `--v=8` | Display HTTP request contents. `--v=9` | Display HTTP request contents without truncation of contents. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [Overview of kubectl](/docs/reference/kubectl/overview/). @@ -394,4 +395,4 @@ Verbosity | Description * See more community [kubectl cheatsheets](https://github.com/dennyzhang/cheatsheet-kubernetes-A4). -{{% /capture %}} + diff --git a/content/en/docs/reference/kubectl/conventions.md b/content/en/docs/reference/kubectl/conventions.md index c4bdd59ec5..062847c485 100644 --- a/content/en/docs/reference/kubectl/conventions.md +++ b/content/en/docs/reference/kubectl/conventions.md @@ -2,14 +2,14 @@ title: kubectl Usage Conventions reviewers: - janetkuo -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + Recommended usage conventions for `kubectl`. -{{% /capture %}} -{{% capture body %}} + + ## Using `kubectl` in Reusable Scripts @@ -59,4 +59,4 @@ You can generate the following resources with a kubectl command, `kubectl create * You can use `kubectl apply` to create or update resources. For more information about using kubectl apply to update resources, see [Kubectl Book](https://kubectl.docs.kubernetes.io). -{{% /capture %}} + diff --git a/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md b/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md index 60b21a3170..513bd77def 100644 --- a/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md +++ b/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md @@ -1,16 +1,16 @@ --- title: kubectl for Docker Users -content_template: templates/concept +content_type: concept reviewers: - brendandburns - thockin --- -{{% capture overview %}} + You can use the Kubernetes command line tool kubectl to interact with the API Server. Using kubectl is straightforward if you are familiar with the Docker command line tool. However, there are a few differences between the docker commands and the kubectl commands. The following sections show a docker sub-command and describe the equivalent kubectl command. -{{% /capture %}} -{{% capture body %}} + + ## docker run To run an nginx Deployment and expose the Deployment, see [kubectl create deployment](/docs/reference/generated/kubectl/kubectl-commands#-em-deployment-em-). @@ -35,16 +35,22 @@ kubectl: ```shell # start the pod running nginx -kubectl create deployment --image=nginx nginx-app --port=80 -``` -``` -deployment.apps/nginx-app created +kubectl create deployment --image=nginx nginx-app ``` ```shell # add env to nginx-app kubectl set env deployment/nginx-app DOMAIN=cluster ``` +deployment.apps/nginx-app created +``` + +``` +# add env to nginx-app +kubectl set env deployment/nginx-app DOMAIN=cluster +``` +``` +deployment.apps/nginx-app env updated ``` deployment.apps/nginx-app env updated @@ -366,4 +372,4 @@ Grafana is running at https://203.0.113.141/api/v1/namespaces/kube-system/servic Heapster is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy InfluxDB is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy ``` -{{% /capture %}} + diff --git a/content/en/docs/reference/kubectl/jsonpath.md b/content/en/docs/reference/kubectl/jsonpath.md index 731af0004e..50c051c9f4 100644 --- a/content/en/docs/reference/kubectl/jsonpath.md +++ b/content/en/docs/reference/kubectl/jsonpath.md @@ -1,14 +1,14 @@ --- title: JSONPath Support -content_template: templates/concept +content_type: concept weight: 25 --- -{{% capture overview %}} + Kubectl supports JSONPath template. -{{% /capture %}} -{{% capture body %}} + + JSONPath template is composed of JSONPath expressions enclosed by curly braces {}. Kubectl uses JSONPath expressions to filter on specific fields in the JSON object and format the output. @@ -98,4 +98,4 @@ kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"}{.status. ``` {{< /note >}} -{{% /capture %}} + diff --git a/content/en/docs/reference/kubectl/kubectl.md b/content/en/docs/reference/kubectl/kubectl.md index 6342de0008..f734d32f99 100644 --- a/content/en/docs/reference/kubectl/kubectl.md +++ b/content/en/docs/reference/kubectl/kubectl.md @@ -1,10 +1,11 @@ --- title: kubectl -content_template: templates/tool-reference +content_type: tool-reference weight: 30 --- -{{% capture synopsis %}} +## {{% heading "synopsis" %}} + kubectl controls the Kubernetes cluster manager. @@ -15,9 +16,10 @@ kubectl controls the Kubernetes cluster manager. kubectl [flags] ``` -{{% /capture %}} -{{% capture options %}} + +## {{% heading "options" %}} + @@ -521,9 +523,10 @@ kubectl [flags] -{{% /capture %}} -{{% capture seealso %}} + +## {{% heading "seealso" %}} + * [kubectl alpha](/docs/reference/generated/kubectl/kubectl-commands#alpha) - Commands for features in alpha * [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands#annotate) - Update the annotations on a resource @@ -569,5 +572,5 @@ kubectl [flags] * [kubectl version](/docs/reference/generated/kubectl/kubectl-commands#version) - Print the client and server version information * [kubectl wait](/docs/reference/generated/kubectl/kubectl-commands#wait) - Experimental: Wait for a specific condition on one or many resources. -{{% /capture %}} + diff --git a/content/en/docs/reference/kubectl/overview.md b/content/en/docs/reference/kubectl/overview.md index 556842d4fd..66d63c4b93 100644 --- a/content/en/docs/reference/kubectl/overview.md +++ b/content/en/docs/reference/kubectl/overview.md @@ -2,21 +2,21 @@ reviewers: - hw-qiaolei title: Overview of kubectl -content_template: templates/concept +content_type: concept weight: 20 card: name: reference weight: 20 --- -{{% capture overview %}} -Kubectl is a command line tool for controlling Kubernetes clusters. `kubectl` looks for a file named config in the $HOME/.kube directory. You can specify other [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) files by setting the KUBECONFIG environment variable or by setting the [`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) flag. + +The kubectl command line tool lets you control Kubernetes clusters. For configuration, `kubectl` looks for a file named `config` in the `$HOME/.kube` directory. You can specify other [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) files by setting the KUBECONFIG environment variable or by setting the [`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) flag. This overview covers `kubectl` syntax, describes the command operations, and provides common examples. For details about each command, including all the supported flags and subcommands, see the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) reference documentation. For installation instructions see [installing kubectl](/docs/tasks/kubectl/install/). -{{% /capture %}} -{{% capture body %}} + + ## Syntax @@ -32,11 +32,11 @@ where `command`, `TYPE`, `NAME`, and `flags` are: * `TYPE`: Specifies the [resource type](#resource-types). Resource types are case-insensitive and you can specify the singular, plural, or abbreviated forms. For example, the following commands produce the same output: - ```shell - kubectl get pod pod1 - kubectl get pods pod1 - kubectl get po pod1 - ``` + ```shell + kubectl get pod pod1 + kubectl get pods pod1 + kubectl get po pod1 + ``` * `NAME`: Specifies the name of the resource. Names are case-sensitive. If the name is omitted, details for all resources are displayed, for example `kubectl get pods`. @@ -113,13 +113,13 @@ Operation | Syntax | Description `version` | `kubectl version [--client] [flags]` | Display the Kubernetes version running on the client and server. `wait` | kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options] | Experimental: Wait for a specific condition on one or many resources. -Remember: For more about command operations, see the [kubectl](/docs/user-guide/kubectl/) reference documentation. +To learn more about command operations, see the [kubectl](/docs/reference/kubectl/kubectl/) reference documentation. ## Resource types The following table includes a list of all the supported resource types and their abbreviated aliases. -(This output can be retrieved from `kubectl api-resources`, and is accurate as of Kubernetes 1.13.3.) +(This output can be retrieved from `kubectl api-resources`, and was accurate as of Kubernetes 1.13.3.) | Resource Name | Short Names | API Group | Namespaced | Resource Kind | |---|---|---|---|---| @@ -175,7 +175,7 @@ The following table includes a list of all the supported resource types and thei ## Output options -Use the following sections for information about how you can format or sort the output of certain commands. For details about which commands support the various output options, see the [kubectl](/docs/user-guide/kubectl/) reference documentation. +Use the following sections for information about how you can format or sort the output of certain commands. For details about which commands support the various output options, see the [kubectl](/docs/reference/kubectl/kubectl/) reference documentation. ### Formatting output @@ -234,9 +234,9 @@ where the `template.txt` file contains: NAME RSRC metadata.name metadata.resourceVersion ``` -The result of running either command is: +The result of running either command is similar to: -```shell +``` NAME RSRC submit-queue 610995 ``` @@ -247,7 +247,7 @@ submit-queue 610995 This means that for any given resource, the server will return columns and rows relevant to that resource, for the client to print. This allows for consistent human-readable output across clients used against the same cluster, by having the server encapsulate the details of printing. -This feature is enabled by default in `kubectl` 1.11 and higher. To disable it, add the +This feature is enabled by default. To disable it, add the `--server-print=false` flag to the `kubectl get` command. ##### Examples @@ -258,9 +258,9 @@ To print information about the status of a pod, use a command like the following kubectl get pods --server-print=false ``` -Output looks like this: +The output is similar to: -```shell +``` NAME AGE pod-name 1m ``` @@ -405,19 +405,23 @@ Use the following set of examples to help you familiarize yourself with writing # create a simple plugin in any language and name the resulting executable file # so that it begins with the prefix "kubectl-" cat ./kubectl-hello -#!/bin/bash +``` +```shell +#!/bin/sh # this plugin prints the words "hello world" echo "hello world" - -# with our plugin written, let's make it executable -sudo chmod +x ./kubectl-hello +``` +With a plugin written, let's make it executable: +```bash +chmod a+x ./kubectl-hello # and move it to a location in our PATH sudo mv ./kubectl-hello /usr/local/bin +sudo chown root:root /usr/local/bin -# we have now created and "installed" a kubectl plugin. -# we can begin using our plugin by invoking it from kubectl as if it were a regular command +# You have now created and "installed" a kubectl plugin. +# You can begin using this plugin by invoking it from kubectl as if it were a regular command kubectl hello ``` ``` @@ -425,16 +429,18 @@ hello world ``` ```shell -# we can "uninstall" a plugin, by simply removing it from our PATH +# You can "uninstall" a plugin, by removing it from the folder in your +# $PATH where you placed it sudo rm /usr/local/bin/kubectl-hello ``` -In order to view all of the plugins that are available to `kubectl`, we can use +In order to view all of the plugins that are available to `kubectl`, use the `kubectl plugin list` subcommand: ```shell kubectl plugin list ``` +The output is similar to: ``` The following kubectl-compatible plugins are available: @@ -442,11 +448,11 @@ The following kubectl-compatible plugins are available: /usr/local/bin/kubectl-foo /usr/local/bin/kubectl-bar ``` + +`kubectl plugin list` also warns you about plugins that are not +executable, or that are shadowed by other plugins; for example: ```shell -# this command can also warn us about plugins that are -# not executable, or that are overshadowed by other -# plugins, for example -sudo chmod -x /usr/local/bin/kubectl-foo +sudo chmod -x /usr/local/bin/kubectl-foo # remove execute permission kubectl plugin list ``` ``` @@ -460,11 +466,15 @@ The following kubectl-compatible plugins are available: error: one plugin warning was found ``` -We can think of plugins as a means to build more complex functionality on top +You can think of plugins as a means to build more complex functionality on top of the existing kubectl commands: ```shell cat ./kubectl-whoami +``` +The next few examples assume that you already made `kubectl-whoami` have +the following contents: +```shell #!/bin/bash # this plugin makes use of the `kubectl config` command in order to output @@ -472,26 +482,28 @@ cat ./kubectl-whoami kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}' ``` -Running the above plugin gives us an output containing the user for the currently selected -context in our KUBECONFIG file: +Running the above command gives you an output containing the user for the +current context in your KUBECONFIG file: ```shell # make the file executable sudo chmod +x ./kubectl-whoami -# and move it into our PATH +# and move it into your PATH sudo mv ./kubectl-whoami /usr/local/bin kubectl whoami Current user: plugins-user ``` -To find out more about plugins, take a look at the [example cli plugin](https://github.com/kubernetes/sample-cli-plugin). -{{% /capture %}} -{{% capture whatsnext %}} -Start using the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) commands. +## {{% heading "whatsnext" %}} + + +* Start using the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) commands. + +* To find out more about plugins, take a look at the [example cli plugin](https://github.com/kubernetes/sample-cli-plugin). + -{{% /capture %}} diff --git a/content/en/docs/reference/kubernetes-api/labels-annotations-taints.md b/content/en/docs/reference/kubernetes-api/labels-annotations-taints.md index e1f1e9a801..d1faa51a88 100644 --- a/content/en/docs/reference/kubernetes-api/labels-annotations-taints.md +++ b/content/en/docs/reference/kubernetes-api/labels-annotations-taints.md @@ -1,18 +1,18 @@ --- title: Well-Known Labels, Annotations and Taints -content_template: templates/concept +content_type: concept weight: 60 --- -{{% capture overview %}} + Kubernetes reserves all labels and annotations in the kubernetes.io namespace. This document serves both as a reference to the values and as a coordination point for assigning values. -{{% /capture %}} -{{% capture body %}} + + ## kubernetes.io/arch @@ -130,4 +130,4 @@ If `PersistentVolumeLabel` does not support automatic labeling of your Persisten adding the labels manually (or adding support for `PersistentVolumeLabel`). With `PersistentVolumeLabel`, the scheduler prevents Pods from mounting volumes in a different zone. If your infrastructure doesn't have this constraint, you don't need to add the zone labels to the volumes at all. -{{% /capture %}} + diff --git a/content/en/docs/reference/scheduling/policies.md b/content/en/docs/reference/scheduling/policies.md index 0bf6e030b0..67d34e59f7 100644 --- a/content/en/docs/reference/scheduling/policies.md +++ b/content/en/docs/reference/scheduling/policies.md @@ -1,10 +1,10 @@ --- title: Scheduling Policies -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + A scheduling Policy can be used to specify the *predicates* and *priorities* that the {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}} @@ -16,9 +16,9 @@ You can set a scheduling policy by running `kube-scheduler --policy-configmap ` and using the [Policy type](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1?tab=doc#Policy). -{{% /capture %}} -{{% capture body %}} + + ## Predicates @@ -117,9 +117,10 @@ The following *priorities* implement scoring: - `EvenPodsSpreadPriority`: Implements preferred [pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/). -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn about [scheduling](/docs/concepts/scheduling-eviction/kube-scheduler/) * Learn about [kube-scheduler profiles](/docs/reference/scheduling/profiles/) -{{% /capture %}} + diff --git a/content/en/docs/reference/scheduling/profiles.md b/content/en/docs/reference/scheduling/profiles.md index 48fa961b2e..fe28d10bd1 100644 --- a/content/en/docs/reference/scheduling/profiles.md +++ b/content/en/docs/reference/scheduling/profiles.md @@ -1,10 +1,10 @@ --- title: Scheduling Profiles -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.18" state="alpha" >}} @@ -20,9 +20,9 @@ or [`v1alpha2`](https://pkg.go.dev/k8s.io/kube-scheduler@{{< param "fullversion" The `v1alpha2` API allows you to configure kube-scheduler to run [multiple profiles](#multiple-profiles). -{{% /capture %}} -{{% capture body %}} + + ## Extension points @@ -174,8 +174,9 @@ the same configuration parameters (if applicable). This is because the scheduler only has one pending pods queue. {{< /note >}} -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn about [scheduling](/docs/concepts/scheduling-eviction/kube-scheduler/) -{{% /capture %}} + diff --git a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md index a0aa304217..cb42a34df9 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md +++ b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md @@ -3,10 +3,10 @@ reviewers: - luxas - jbeda title: Implementation details -content_template: templates/concept +content_type: concept weight: 100 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.10" state="stable" >}} @@ -14,9 +14,9 @@ weight: 100 However, it might not be obvious _how_ kubeadm does that. This document provides additional details on what happen under the hood, with the aim of sharing knowledge on Kubernetes cluster best practices. -{{% /capture %}} -{{% capture body %}} + + ## Core design principles The cluster that `kubeadm init` and `kubeadm join` set up should be: @@ -531,4 +531,4 @@ Please note that: 1. To make dynamic kubelet configuration work, flag `--dynamic-config-dir=/var/lib/kubelet/config/dynamic` should be specified in `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` -{{% /capture %}} + diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md index c918cd5580..a4b0e501d8 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md @@ -3,10 +3,10 @@ reviewers: - luxas - jbeda title: kubeadm config -content_template: templates/concept +content_type: concept weight: 50 --- -{{% capture overview %}} + During `kubeadm init`, kubeadm uploads the `ClusterConfiguration` object to your cluster in a ConfigMap called `kubeadm-config` in the `kube-system` namespace. This configuration is then read during `kubeadm join`, `kubeadm reset` and `kubeadm upgrade`. To view this ConfigMap call `kubeadm config view`. @@ -19,9 +19,9 @@ In Kubernetes v1.13.0 and later to list/pull kube-dns images instead of the Core the `--config` method described [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon) has to be used. -{{% /capture %}} -{{% capture body %}} + + ## kubeadm config view {#cmd-config-view} {{< include "generated/kubeadm_config_view.md" >}} @@ -40,8 +40,9 @@ has to be used. ## kubeadm config images pull {#cmd-config-images-pull} {{< include "generated/kubeadm_config_images_pull.md" >}} -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) to upgrade a Kubernetes cluster to a newer version -{{% /capture %}} + diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md index 7103b39d42..54729065c6 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md @@ -3,14 +3,14 @@ reviewers: - luxas - jbeda title: kubeadm init -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + This command initializes a Kubernetes control-plane node. -{{% /capture %}} -{{% capture body %}} + + {{< include "generated/kubeadm_init.md" >}} @@ -255,12 +255,13 @@ it does not allow the root CA hash to be validated with `--discovery-token-ca-cert-hash` (since it's not generated when the nodes are provisioned). For details, see the [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/). -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [kubeadm init phase](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/) to understand more about `kubeadm init` phases * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to bootstrap a Kubernetes worker node and join it to the cluster * [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) to upgrade a Kubernetes cluster to a newer version * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join` -{{% /capture %}} + diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md index 1e99d1682b..abceaf5f70 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md @@ -3,14 +3,14 @@ reviewers: - luxas - jbeda title: kubeadm join -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + This command initializes a Kubernetes worker node and joins it to the cluster. -{{% /capture %}} -{{% capture body %}} + + {{< include "generated/kubeadm_join.md" >}} ### The join workflow {#join-workflow} @@ -276,10 +276,11 @@ kubeadm config print join-defaults For details on individual fields in `JoinConfiguration` see [the godoc](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#JoinConfiguration). -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node * [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token/) to manage tokens for `kubeadm join` * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join` -{{% /capture %}} + diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md index 7185a51475..2664283daa 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md @@ -3,14 +3,14 @@ reviewers: - luxas - jbeda title: kubeadm reset -content_template: templates/concept +content_type: concept weight: 60 --- -{{% capture overview %}} + Performs a best effort revert of changes made by `kubeadm init` or `kubeadm join`. -{{% /capture %}} -{{% capture body %}} + + {{< include "generated/kubeadm_reset.md" >}} ### Reset workflow {#reset-workflow} @@ -35,9 +35,10 @@ etcdctl del "" --prefix ``` See the [etcd documentation](https://github.com/coreos/etcd/tree/master/etcdctl) for more information. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) to bootstrap a Kubernetes control-plane node * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to bootstrap a Kubernetes worker node and join it to the cluster -{{% /capture %}} + diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-token.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-token.md index a8e9c7cd99..92a187bb92 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-token.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-token.md @@ -3,10 +3,10 @@ reviewers: - luxas - jbeda title: kubeadm token -content_template: templates/concept +content_type: concept weight: 70 --- -{{% capture overview %}} + Bootstrap tokens are used for establishing bidirectional trust between a node joining the cluster and a control-plane node, as described in [authenticating with bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/). @@ -14,9 +14,9 @@ the cluster and a control-plane node, as described in [authenticating with boots `kubeadm init` creates an initial token with a 24-hour TTL. The following commands allow you to manage such a token and also to create and manage new ones. -{{% /capture %}} -{{% capture body %}} + + ## kubeadm token create {#cmd-token-create} {{< include "generated/kubeadm_token_create.md" >}} @@ -28,8 +28,9 @@ such a token and also to create and manage new ones. ## kubeadm token list {#cmd-token-list} {{< include "generated/kubeadm_token_list.md" >}} -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to bootstrap a Kubernetes worker node and join it to the cluster -{{% /capture %}} + diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md index 31c2f11d9c..71483aa1d6 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md @@ -3,15 +3,15 @@ reviewers: - luxas - jbeda title: kubeadm upgrade -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + `kubeadm upgrade` is a user-friendly command that wraps complex upgrading logic behind one command, with support for both planning an upgrade and actually performing it. -{{% /capture %}} -{{% capture body %}} + + ## kubeadm upgrade guidance @@ -46,8 +46,9 @@ reports of unexpected results. ## kubeadm upgrade node {#cmd-upgrade-node} {{< include "generated/kubeadm_upgrade_node.md" >}} -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config/) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade` -{{% /capture %}} + diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-version.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-version.md index 5da4209f3e..a4b57e796c 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-version.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-version.md @@ -3,13 +3,13 @@ reviewers: - luxas - jbeda title: kubeadm version -content_template: templates/concept +content_type: concept weight: 80 --- -{{% capture overview %}} + This command prints the version of kubeadm. -{{% /capture %}} -{{% capture body %}} + + {{< include "generated/kubeadm_version.md" >}} -{{% /capture %}} + diff --git a/content/en/docs/reference/tools.md b/content/en/docs/reference/tools.md index 349ce58f2c..ef210f2b07 100644 --- a/content/en/docs/reference/tools.md +++ b/content/en/docs/reference/tools.md @@ -2,14 +2,14 @@ reviewers: - janetkuo title: Tools -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + Kubernetes contains several built-in tools to help you work with the Kubernetes system. -{{% /capture %}} -{{% capture body %}} + + ## Kubectl [`kubectl`](/docs/tasks/tools/install-kubectl/) is the command line tool for Kubernetes. It controls the Kubernetes cluster manager. @@ -51,4 +51,4 @@ Use Kompose to: * Translate a Docker Compose file into Kubernetes objects * Go from local Docker development to managing your application via Kubernetes * Convert v1 or v2 Docker Compose `yaml` files or [Distributed Application Bundles](https://docs.docker.com/compose/bundles/) -{{% /capture %}} + diff --git a/content/en/docs/reference/using-api/api-concepts.md b/content/en/docs/reference/using-api/api-concepts.md index 0c3f1b2341..f83c43c00f 100644 --- a/content/en/docs/reference/using-api/api-concepts.md +++ b/content/en/docs/reference/using-api/api-concepts.md @@ -4,15 +4,15 @@ reviewers: - smarterclayton - lavalamp - liggitt -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + This page describes common concepts in the Kubernetes API. -{{% /capture %}} -{{% capture body %}} + + The Kubernetes API is a resource-based (RESTful) programmatic interface provided via HTTP. It supports retrieving, creating, updating, and deleting primary resources via the standard HTTP verbs (POST, PUT, PATCH, DELETE, GET), includes additional subresources for many objects that allow fine grained authorization (such as binding a pod to a node), and can accept and serve those resources in different representations for convenience or efficiency. It also supports efficient change notifications on resources via "watches" and consistent lists to allow other components to effectively cache and synchronize the state of resources. diff --git a/content/en/docs/reference/using-api/api-overview.md b/content/en/docs/reference/using-api/api-overview.md index 3820085e6b..25b7d46af9 100644 --- a/content/en/docs/reference/using-api/api-overview.md +++ b/content/en/docs/reference/using-api/api-overview.md @@ -4,7 +4,7 @@ reviewers: - erictune - lavalamp - jbeda -content_template: templates/concept +content_type: concept weight: 10 card: name: reference @@ -12,11 +12,11 @@ card: title: Overview of API --- -{{% capture overview %}} + This page provides an overview of the Kubernetes API. -{{% /capture %}} -{{% capture body %}} + + The REST API is the fundamental fabric of Kubernetes. All operations and communications between components, and external user commands are REST API calls that the API Server handles. Consequently, everything in the Kubernetes platform is treated as an API object and has a corresponding entry in the [API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/). @@ -86,7 +86,7 @@ Currently, there are several API groups in use: The two paths that support extending the API with [custom resources](/docs/concepts/api-extension/custom-resources/) are: - - [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/) + - [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) for basic CRUD needs. - [aggregator](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md) for a full set of Kubernetes API semantics to implement their own apiserver. diff --git a/content/en/docs/reference/using-api/client-libraries.md b/content/en/docs/reference/using-api/client-libraries.md index 0d8af9394d..1531b2c5df 100644 --- a/content/en/docs/reference/using-api/client-libraries.md +++ b/content/en/docs/reference/using-api/client-libraries.md @@ -2,16 +2,16 @@ title: Client Libraries reviewers: - ahmetb -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + This page contains an overview of the client libraries for using the Kubernetes API from various programming languages. -{{% /capture %}} -{{% capture body %}} + + To write applications using the [Kubernetes REST API](/docs/reference/using-api/api-overview/), you do not need to implement the API calls and request/response types yourself. You can use a client library for the programming language you are using. @@ -75,6 +75,6 @@ their authors, not the Kubernetes team. | DotNet (RestSharp) | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) | | Elixir | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) | | Elixir | [github.com/coryodaniel/k8s](https://github.com/coryodaniel/k8s) | -{{% /capture %}} + diff --git a/content/en/docs/reference/using-api/deprecation-policy.md b/content/en/docs/reference/using-api/deprecation-policy.md index f55438cd18..a21d0887ba 100644 --- a/content/en/docs/reference/using-api/deprecation-policy.md +++ b/content/en/docs/reference/using-api/deprecation-policy.md @@ -4,15 +4,15 @@ reviewers: - lavalamp - thockin title: Kubernetes Deprecation Policy -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + This document details the deprecation policy for various facets of the system. -{{% /capture %}} -{{% capture body %}} + + Kubernetes is a large system with many components and many contributors. As with any such software, the feature set naturally evolves over time, and sometimes a feature may need to be removed. This could include an API, a flag, @@ -425,4 +425,4 @@ leaders to find the best solutions for those specific cases, always bearing in mind that Kubernetes is committed to being a stable system that, as much as possible, never breaks users. Exceptions will always be announced in all relevant release notes. -{{% /capture %}} + diff --git a/content/en/docs/setup/_index.md b/content/en/docs/setup/_index.md index 16702b40f5..91b734953c 100644 --- a/content/en/docs/setup/_index.md +++ b/content/en/docs/setup/_index.md @@ -7,7 +7,7 @@ no_issue: true title: Getting started main_menu: true weight: 20 -content_template: templates/concept +content_type: concept card: name: setup weight: 20 @@ -18,7 +18,7 @@ card: title: Production environment --- -{{% capture overview %}} + This section covers different options to set up and run Kubernetes. @@ -28,9 +28,9 @@ You can deploy a Kubernetes cluster on a local machine, cloud, on-prem datacente More simply, you can create a Kubernetes cluster in learning and production environments. -{{% /capture %}} -{{% capture body %}} + + ## Learning environment @@ -51,4 +51,4 @@ When evaluating a solution for a production environment, consider which aspects [Kubernetes Partners](https://kubernetes.io/partners/#conformance) includes a list of [Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes) providers. -{{% /capture %}} + diff --git a/content/en/docs/setup/best-practices/certificates.md b/content/en/docs/setup/best-practices/certificates.md index 6169b3f872..a85d44e0f4 100644 --- a/content/en/docs/setup/best-practices/certificates.md +++ b/content/en/docs/setup/best-practices/certificates.md @@ -2,20 +2,20 @@ title: PKI certificates and requirements reviewers: - sig-cluster-lifecycle -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + Kubernetes requires PKI certificates for authentication over TLS. If you install Kubernetes with [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), the certificates that your cluster requires are automatically generated. You can also generate your own certificates -- for example, to keep your private keys more secure by not storing them on the API server. This page explains the certificates that your cluster requires. -{{% /capture %}} -{{% capture body %}} + + ## How certificates are used by your cluster @@ -31,7 +31,7 @@ Kubernetes requires PKI for the following operations: * Client and server certificates for the [front-proxy][proxy] {{< note >}} -`front-proxy` certificates are required only if you run kube-proxy to support [an extension API server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/). +`front-proxy` certificates are required only if you run kube-proxy to support [an extension API server](/docs/tasks/extend-kubernetes/setup-extension-api-server/). {{< /note >}} etcd also implements mutual TLS to authenticate clients and peers. @@ -162,6 +162,6 @@ These files are used as follows: [usage]: https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage [kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/ -[proxy]: /docs/tasks/access-kubernetes-api/configure-aggregation-layer/ +[proxy]: /docs/tasks/extend-kubernetes/configure-aggregation-layer/ + -{{% /capture %}} diff --git a/content/en/docs/setup/best-practices/cluster-large.md b/content/en/docs/setup/best-practices/cluster-large.md index b8b47b3add..c8692c8872 100644 --- a/content/en/docs/setup/best-practices/cluster-large.md +++ b/content/en/docs/setup/best-practices/cluster-large.md @@ -15,9 +15,6 @@ At {{< param "version" >}}, Kubernetes supports clusters with up to 5000 nodes. * No more than 300000 total containers * No more than 100 pods per node -
- -{{< toc >}} ## Setup diff --git a/content/en/docs/setup/best-practices/multiple-zones.md b/content/en/docs/setup/best-practices/multiple-zones.md index ba58df028f..ab61c839a9 100644 --- a/content/en/docs/setup/best-practices/multiple-zones.md +++ b/content/en/docs/setup/best-practices/multiple-zones.md @@ -5,16 +5,16 @@ reviewers: - quinton-hoole title: Running in multiple zones weight: 10 -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + This page describes how to run a cluster in multiple zones. -{{% /capture %}} -{{% capture body %}} + + ## Introduction @@ -401,4 +401,4 @@ KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b k KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh ``` -{{% /capture %}} + diff --git a/content/en/docs/setup/best-practices/node-conformance.md b/content/en/docs/setup/best-practices/node-conformance.md index 0adabe2c58..5e75959b18 100644 --- a/content/en/docs/setup/best-practices/node-conformance.md +++ b/content/en/docs/setup/best-practices/node-conformance.md @@ -5,7 +5,6 @@ title: Validate node setup weight: 30 --- -{{< toc >}} ## Node Conformance Test diff --git a/content/en/docs/setup/learning-environment/kind.md b/content/en/docs/setup/learning-environment/kind.md index e476d220d0..ac355bd157 100644 --- a/content/en/docs/setup/learning-environment/kind.md +++ b/content/en/docs/setup/learning-environment/kind.md @@ -1,22 +1,22 @@ --- title: Installing Kubernetes with Kind weight: 40 -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + Kind is a tool for running local Kubernetes clusters using Docker container "nodes". -{{% /capture %}} -{{% capture body %}} + + ## Installation See [Installing Kind](https://kind.sigs.k8s.io/docs/user/quick-start/). -{{% /capture %}} + diff --git a/content/en/docs/setup/learning-environment/minikube.md b/content/en/docs/setup/learning-environment/minikube.md index e314d56608..a794141f2d 100644 --- a/content/en/docs/setup/learning-environment/minikube.md +++ b/content/en/docs/setup/learning-environment/minikube.md @@ -5,16 +5,16 @@ reviewers: - aaron-prindle title: Installing Kubernetes with Minikube weight: 30 -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + Minikube is a tool that makes it easy to run Kubernetes locally. Minikube runs a single-node Kubernetes cluster inside a Virtual Machine (VM) on your laptop for users looking to try out Kubernetes or develop with it day-to-day. -{{% /capture %}} -{{% capture body %}} + + ## Minikube Features @@ -369,7 +369,12 @@ The `minikube delete` command can be used to delete your cluster. This command shuts down and deletes the Minikube Virtual Machine. No data or state is preserved. ### Upgrading Minikube -If you are using macOS, see [Upgrading Minikube](https://minikube.sigs.k8s.io/docs/start/macos/#upgrading-minikube) to upgrade your existing minikube installation. +If you are using macOS and [Brew Package Manager](https://brew.sh/) is installed run: + +```shell +brew update +brew upgrade minikube +``` ## Interacting with Your Cluster @@ -380,9 +385,11 @@ This context contains the configuration to communicate with your Minikube cluste Minikube sets this context to default automatically, but if you need to switch back to it in the future, run: -`kubectl config use-context minikube`, +`kubectl config use-context minikube` -Or pass the context on each command like this: `kubectl get pods --context=minikube`. +Or pass the context on each command like this: + +`kubectl get pods --context=minikube` ### Dashboard @@ -509,4 +516,4 @@ For more information about Minikube, see the [proposal](https://git.k8s.io/commu Contributions, questions, and comments are all welcomed and encouraged! Minikube developers hang out on [Slack](https://kubernetes.slack.com) in the #minikube channel (get an invitation [here](http://slack.kubernetes.io/)). We also have the [kubernetes-dev Google Groups mailing list](https://groups.google.com/forum/#!forum/kubernetes-dev). If you are posting to the list please prefix your subject with "minikube: ". -{{% /capture %}} + diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md index 7db25e022b..575ac4ba5e 100644 --- a/content/en/docs/setup/production-environment/container-runtimes.md +++ b/content/en/docs/setup/production-environment/container-runtimes.md @@ -3,17 +3,17 @@ reviewers: - vincepri - bart0sh title: Container runtimes -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.6" state="stable" >}} To run containers in Pods, Kubernetes uses a container runtime. Here are the installation instructions for various runtimes. -{{% /capture %}} -{{% capture body %}} + + {{< caution >}} @@ -64,13 +64,13 @@ is to drain the Node from its workloads, remove it from the cluster and re-join ## Docker On each of your machines, install Docker. -Version 19.03.8 is recommended, but 1.13.1, 17.03, 17.06, 17.09, 18.06 and 18.09 are known to work as well. +Version 19.03.11 is recommended, but 1.13.1, 17.03, 17.06, 17.09, 18.06 and 18.09 are known to work as well. Keep track of the latest verified Docker version in the Kubernetes release notes. Use the following commands to install Docker on your system: {{< tabs name="tab-cri-docker-installation" >}} -{{< tab name="Ubuntu 16.04+" >}} +{{% tab name="Ubuntu 16.04+" %}} ```shell # (Install Docker CE) @@ -96,9 +96,9 @@ add-apt-repository \ ```shell # Install Docker CE apt-get update && apt-get install -y \ - containerd.io=1.2.13-1 \ - docker-ce=5:19.03.8~3-0~ubuntu-$(lsb_release -cs) \ - docker-ce-cli=5:19.03.8~3-0~ubuntu-$(lsb_release -cs) + containerd.io=1.2.13-2 \ + docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \ + docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) ``` ```shell @@ -124,8 +124,8 @@ mkdir -p /etc/systemd/system/docker.service.d systemctl daemon-reload systemctl restart docker ``` -{{< /tab >}} -{{< tab name="CentOS/RHEL 7.4+" >}} +{{% /tab %}} +{{% tab name="CentOS/RHEL 7.4+" %}} ```shell # (Install Docker CE) @@ -144,8 +144,8 @@ yum-config-manager --add-repo \ # Install Docker CE yum update -y && yum install -y \ containerd.io-1.2.13 \ - docker-ce-19.03.8 \ - docker-ce-cli-19.03.8 + docker-ce-19.03.11 \ + docker-ce-cli-19.03.11 ``` ```shell @@ -179,9 +179,15 @@ mkdir -p /etc/systemd/system/docker.service.d systemctl daemon-reload systemctl restart docker ``` -{{< /tab >}} +{{% /tab %}} {{< /tabs >}} +If you want the docker service to start on boot, run the following command: + +```shell +sudo systemctl enable docker +``` + Refer to the [official Docker installation guides](https://docs.docker.com/engine/installation/) for more information. @@ -213,7 +219,7 @@ sysctl --system ``` {{< tabs name="tab-cri-cri-o-installation" >}} -{{< tab name="Debian" >}} +{{% tab name="Debian" %}} ```shell # Debian Unstable/Sid @@ -243,9 +249,9 @@ and then install CRI-O: ```shell sudo apt-get install cri-o-1.17 ``` -{{< /tab >}} +{{% /tab %}} -{{< tab name="Ubuntu 18.04, 19.04 and 19.10" >}} +{{% tab name="Ubuntu 18.04, 19.04 and 19.10" %}} ```shell # Configure package repository @@ -259,9 +265,9 @@ sudo apt-get update # Install CRI-O sudo apt-get install cri-o-1.17 ``` -{{< /tab >}} +{{% /tab %}} -{{< tab name="CentOS/RHEL 7.4+" >}} +{{% tab name="CentOS/RHEL 7.4+" %}} ```shell # Install prerequisites @@ -273,14 +279,14 @@ curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:{{< skew late # Install CRI-O yum install -y cri-o ``` -{{< /tab >}} +{{% /tab %}} -{{< tab name="openSUSE Tumbleweed" >}} +{{% tab name="openSUSE Tumbleweed" %}} ```shell sudo zypper install cri-o ``` -{{< /tab >}} +{{% /tab %}} {{< /tabs >}} ### Start CRI-O @@ -323,7 +329,7 @@ sysctl --system ### Install containerd {{< tabs name="tab-cri-containerd-installation" >}} -{{< tab name="Ubuntu 16.04" >}} +{{% tab name="Ubuntu 16.04" %}} ```shell # (Install containerd) @@ -360,8 +366,8 @@ containerd config default > /etc/containerd/config.toml # Restart containerd systemctl restart containerd ``` -{{< /tab >}} -{{< tab name="CentOS/RHEL 7.4+" >}} +{{% /tab %}} +{{% tab name="CentOS/RHEL 7.4+" %}} ```shell # (Install containerd) @@ -389,7 +395,7 @@ containerd config default > /etc/containerd/config.toml # Restart containerd systemctl restart containerd ``` -{{< /tab >}} +{{% /tab %}} {{< /tabs >}} ### systemd @@ -402,4 +408,4 @@ When using kubeadm, manually configure the Refer to the [Frakti QuickStart guide](https://github.com/kubernetes/frakti#quickstart) for more information. -{{% /capture %}} + diff --git a/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md b/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md index e85953dd86..1f7d1fd81f 100644 --- a/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md +++ b/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md @@ -2,10 +2,10 @@ reviewers: - thockin title: Cloudstack -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + [CloudStack](https://cloudstack.apache.org/) is a software to build public and private clouds based on hardware virtualization principles (traditional IaaS). To deploy Kubernetes on CloudStack there are several possibilities depending on the Cloud being used and what images are made available. CloudStack also has a vagrant plugin available, hence Vagrant could be used to deploy Kubernetes either using the existing shell provisioner or using new Salt based recipes. @@ -13,9 +13,9 @@ content_template: templates/concept This guide uses a single [Ansible playbook](https://github.com/apachecloudstack/k8s), which is completely automated and can deploy Kubernetes on a CloudStack based Cloud using CoreOS images. The playbook, creates an ssh key pair, creates a security group and associated rules and finally starts coreOS instances configured via cloud-init. -{{% /capture %}} -{{% capture body %}} + + ## Prerequisites @@ -118,4 +118,4 @@ IaaS Provider | Config. Mgmt | OS | Networking | Docs CloudStack | Ansible | CoreOS | flannel | [docs](/docs/setup/production-environment/on-premises-vm/cloudstack/) | | Community ([@Guiques](https://github.com/ltupin/)) -{{% /capture %}} + diff --git a/content/en/docs/setup/production-environment/on-premises-vm/dcos.md b/content/en/docs/setup/production-environment/on-premises-vm/dcos.md index 12e47948e2..e4b310902c 100644 --- a/content/en/docs/setup/production-environment/on-premises-vm/dcos.md +++ b/content/en/docs/setup/production-environment/on-premises-vm/dcos.md @@ -2,10 +2,10 @@ reviewers: - smugcloud title: Kubernetes on DC/OS -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + Mesosphere provides an easy option to provision Kubernetes onto [DC/OS](https://mesosphere.com/product/), offering: @@ -14,12 +14,12 @@ Mesosphere provides an easy option to provision Kubernetes onto [DC/OS](https:// * Highly available and secure by default * Kubernetes running alongside fast-data platforms (e.g. Akka, Cassandra, Kafka, Spark) -{{% /capture %}} -{{% capture body %}} + + ## Official Mesosphere Guide The canonical source of getting started on DC/OS is located in the [quickstart repo](https://github.com/mesosphere/dcos-kubernetes-quickstart). -{{% /capture %}} + diff --git a/content/en/docs/setup/production-environment/on-premises-vm/ovirt.md b/content/en/docs/setup/production-environment/on-premises-vm/ovirt.md index be6f3b8e77..1d57b6f7eb 100644 --- a/content/en/docs/setup/production-environment/on-premises-vm/ovirt.md +++ b/content/en/docs/setup/production-environment/on-premises-vm/ovirt.md @@ -3,16 +3,16 @@ reviewers: - caesarxuchao - erictune title: oVirt -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + oVirt is a virtual datacenter manager that delivers powerful management of multiple virtual machines on multiple hosts. Using KVM and libvirt, oVirt can be installed on Fedora, CentOS, or Red Hat Enterprise Linux hosts to set up and manage your virtual data center. -{{% /capture %}} -{{% capture body %}} + + ## oVirt Cloud Provider Deployment @@ -69,4 +69,4 @@ IaaS Provider | Config. Mgmt | OS | Networking | Docs oVirt | | | | [docs](/docs/setup/production-environment/on-premises-vm/ovirt/) | | Community ([@simon3z](https://github.com/simon3z)) -{{% /capture %}} + diff --git a/content/en/docs/setup/production-environment/tools/kops.md b/content/en/docs/setup/production-environment/tools/kops.md index 10ae6dfa65..338dbee0e5 100644 --- a/content/en/docs/setup/production-environment/tools/kops.md +++ b/content/en/docs/setup/production-environment/tools/kops.md @@ -1,10 +1,10 @@ --- title: Installing Kubernetes with kops -content_template: templates/task +content_type: task weight: 20 --- -{{% capture overview %}} + This quickstart shows you how to easily install a Kubernetes cluster on AWS. It uses a tool called [`kops`](https://github.com/kubernetes/kops). @@ -18,9 +18,10 @@ kops is an automated provisioning system: * High-Availability support - see the [high_availability.md](https://github.com/kubernetes/kops/blob/master/docs/operations/high_availability.md) * Can directly provision, or generate terraform manifests - see the [terraform.md](https://github.com/kubernetes/kops/blob/master/docs/terraform.md) -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * You must have [kubectl](/docs/tasks/tools/install-kubectl/) installed. @@ -28,9 +29,9 @@ kops is an automated provisioning system: * You must have an [AWS account](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html), generate [IAM keys](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys) and [configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration) them. -{{% /capture %}} -{{% capture steps %}} + + ## Creating a cluster @@ -225,13 +226,14 @@ See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to expl * To delete your cluster: `kops delete cluster useast1.dev.example.com --yes` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/). * Learn more about `kops` [advanced usage](https://kops.sigs.k8s.io/) for tutorials, best practices and advanced configuration options. * Follow `kops` community discussions on Slack: [community discussions](https://github.com/kubernetes/kops#other-ways-to-communicate-with-the-contributors) * Contribute to `kops` by addressing or raising an issue [GitHub Issues](https://github.com/kubernetes/kops/issues) -{{% /capture %}} + diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md b/content/en/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md index e2ae7267bc..1bcdad0092 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md @@ -2,11 +2,11 @@ reviewers: - sig-cluster-lifecycle title: Customizing control plane configuration with kubeadm -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.12" state="stable" >}} @@ -30,9 +30,9 @@ For more details on each field in the configuration you can navigate to our You can generate a `ClusterConfiguration` object with default values by running `kubeadm config print init-defaults` and saving the output to a file of your choice. {{< /note >}} -{{% /capture %}} -{{% capture body %}} + + ## APIServer flags @@ -83,4 +83,4 @@ scheduler: kubeconfig: /home/johndoe/kubeconfig.yaml ``` -{{% /capture %}} + diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md index 2d38666386..ace94edad2 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md @@ -2,11 +2,11 @@ reviewers: - sig-cluster-lifecycle title: Creating a single control-plane cluster with kubeadm -content_template: templates/task +content_type: task weight: 30 --- -{{% capture overview %}} + The `kubeadm` tool helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification). `kubeadm` also supports other cluster @@ -24,9 +24,10 @@ of cloud servers, a Raspberry Pi, and more. Whether you're deploying into the cloud or on-premises, you can integrate `kubeadm` into provisioning systems such as Ansible or Terraform. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + To follow this guide, you need: @@ -53,9 +54,9 @@ slightly as the tool evolves, but the overall implementation should be pretty st Any commands under `kubeadm alpha` are, by definition, supported on an alpha level. {{< /note >}} -{{% /capture %}} -{{% capture steps %}} + + ## Objectives @@ -312,12 +313,11 @@ kubectl apply -f https://docs.projectcalico.org/v3.14/manifests/calico.yaml {{% /tab %}} {{% tab name="Cilium" %}} -For Cilium to work correctly, you must pass `--pod-network-cidr=10.217.0.0/16` to `kubeadm init`. To deploy Cilium you just need to run: ```shell -kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.6/install/kubernetes/quick-install.yaml +kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml ``` Once all Cilium Pods are marked as `READY`, you start using your cluster. @@ -495,10 +495,10 @@ and `scp` using that other user instead. The `admin.conf` file gives the user _superuser_ privileges over the cluster. This file should be used sparingly. For normal users, it's recommended to -generate an unique credential to which you whitelist privileges. You can do +generate an unique credential to which you grant privileges. You can do this with the `kubeadm alpha kubeconfig user --client-name ` command. That command will print out a KubeConfig file to STDOUT which you -should save to a file and distribute to your user. After that, whitelist +should save to a file and distribute to your user. After that, grant privileges by using `kubectl create (cluster)rolebinding`. {{< /note >}} @@ -564,9 +564,9 @@ See the [`kubeadm reset`](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) reference documentation for more information about this subcommand and its options. -{{% /capture %}} -{{% capture discussion %}} + + ## What's next {#whats-next} @@ -641,4 +641,4 @@ supports your chosen platform. If you are running into difficulties with kubeadm, please consult our [troubleshooting docs](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/). -{{% /capture %}} + diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/ha-topology.md b/content/en/docs/setup/production-environment/tools/kubeadm/ha-topology.md index ec05ee12db..53b1f38024 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/ha-topology.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/ha-topology.md @@ -2,11 +2,11 @@ reviewers: - sig-cluster-lifecycle title: Options for Highly Available topology -content_template: templates/concept +content_type: concept weight: 50 --- -{{% capture overview %}} + This page explains the two options for configuring the topology of your highly available (HA) Kubernetes clusters. @@ -22,9 +22,9 @@ kubeadm bootstraps the etcd cluster statically. Read the etcd [Clustering Guide] for more details. {{< /note >}} -{{% /capture %}} -{{% capture body %}} + + ## Stacked etcd topology @@ -67,10 +67,11 @@ A minimum of three hosts for control plane nodes and three hosts for etcd nodes ![External etcd topology](/images/kubeadm/kubeadm-ha-topology-external-etcd.svg) -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + - [Set up a highly available cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/) -{{% /capture %}} + diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md index 162e60e175..5584309406 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md @@ -2,11 +2,11 @@ reviewers: - sig-cluster-lifecycle title: Creating Highly Available clusters with kubeadm -content_template: templates/task +content_type: task weight: 60 --- -{{% capture overview %}} + This page explains two different approaches to setting up a highly available Kubernetes cluster using kubeadm: @@ -30,9 +30,10 @@ environment, neither approach documented here works with Service objects of type LoadBalancer, or with dynamic PersistentVolumes. {{< /caution >}} -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + For both methods you need this infrastructure: @@ -50,9 +51,9 @@ For the external etcd cluster only, you also need: - Three additional machines for etcd members -{{% /capture %}} -{{% capture steps %}} + + ## First steps for both methods @@ -107,19 +108,20 @@ option. Your cluster requirements may need a different configuration. sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs ``` - - You can use the `--kubernetes-version` flag to set the Kubernetes version to use. - It is recommended that the versions of kubeadm, kubelet, kubectl and Kubernetes match. + It is recommended that the versions of kubeadm, kubelet, kubectl and Kubernetes match. - The `--control-plane-endpoint` flag should be set to the address or DNS and port of the load balancer. - The `--upload-certs` flag is used to upload the certificates that should be shared - across all the control-plane instances to the cluster. If instead, you prefer to copy certs across - control-plane nodes manually or using automation tools, please remove this flag and refer to [Manual - certificate distribution](#manual-certs) section below. + across all the control-plane instances to the cluster. If instead, you prefer to copy certs across + control-plane nodes manually or using automation tools, please remove this flag and refer to [Manual + certificate distribution](#manual-certs) section below. {{< note >}} The `kubeadm init` flags `--config` and `--certificate-key` cannot be mixed, therefore if you want - to use the [kubeadm configuration](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2) you must add the `certificateKey` field in the appropriate config locations (under `InitConfiguration` and `JoinConfiguration: controlPlane`). + to use the [kubeadm configuration](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2) + you must add the `certificateKey` field in the appropriate config locations + (under `InitConfiguration` and `JoinConfiguration: controlPlane`). {{< /note >}} {{< note >}} @@ -131,34 +133,34 @@ option. Your cluster requirements may need a different configuration. - The output looks similar to: -```sh -... -You can now join any number of control-plane node by running the following command on each as a root: - kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07 - -Please note that the certificate-key gives access to cluster sensitive data, keep it secret! -As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward. - -Then you can join any number of worker nodes by running the following on each as root: - kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 -``` + ```sh + ... + You can now join any number of control-plane node by running the following command on each as a root: + kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07 + + Please note that the certificate-key gives access to cluster sensitive data, keep it secret! + As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward. + + Then you can join any number of worker nodes by running the following on each as root: + kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 + ``` - Copy this output to a text file. You will need it later to join control plane and worker nodes to the cluster. - When `--upload-certs` is used with `kubeadm init`, the certificates of the primary control plane - are encrypted and uploaded in the `kubeadm-certs` Secret. + are encrypted and uploaded in the `kubeadm-certs` Secret. - To re-upload the certificates and generate a new decryption key, use the following command on a control plane node that is already joined to the cluster: - ```sh - sudo kubeadm init phase upload-certs --upload-certs - ``` + ```sh + sudo kubeadm init phase upload-certs --upload-certs + ``` - You can also specify a custom `--certificate-key` during `init` that can later be used by `join`. To generate such a key you can use the following command: - ```sh - kubeadm alpha certs certificate-key - ``` + ```sh + kubeadm alpha certs certificate-key + ``` {{< note >}} The `kubeadm-certs` Secret and decryption key expire after two hours. @@ -169,7 +171,8 @@ Then you can join any number of worker nodes by running the following on each as {{< /caution >}} 1. Apply the CNI plugin of your choice: - [Follow these instructions](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network) to install the CNI provider. Make sure the configuration corresponds to the Pod CIDR specified in the kubeadm configuration file if applicable. + [Follow these instructions](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network) + to install the CNI provider. Make sure the configuration corresponds to the Pod CIDR specified in the kubeadm configuration file if applicable. In this example we are using Weave Net: @@ -202,7 +205,7 @@ For each additional control plane node you should: - The `--control-plane` flag tells `kubeadm join` to create a new control plane. - The `--certificate-key ...` will cause the control plane certificates to be downloaded - from the `kubeadm-certs` Secret in the cluster and be decrypted using the given key. + from the `kubeadm-certs` Secret in the cluster and be decrypted using the given key. ## External etcd nodes @@ -373,4 +376,4 @@ SSH is required if you want to control all nodes from a single machine. # Quote this line if you are using external etcd mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key ``` -{{% /capture %}} + diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index 9438e86140..e06918d7b8 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -1,6 +1,6 @@ --- title: Installing kubeadm -content_template: templates/task +content_type: task weight: 10 card: name: setup @@ -8,14 +8,15 @@ card: title: Install the kubeadm setup tool --- -{{% capture overview %}} + This page shows how to install the `kubeadm` toolbox. For information how to create a cluster with kubeadm once you have performed this installation process, see the [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) page. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * One or more machines running one of: - Ubuntu 16.04+ @@ -32,9 +33,9 @@ For information how to create a cluster with kubeadm once you have performed thi * Certain ports are open on your machines. See [here](#check-required-ports) for more details. * Swap disabled. You **MUST** disable swap in order for the kubelet to work properly. -{{% /capture %}} -{{% capture steps %}} + + ## Verify the MAC address and product_uuid are unique for every node {#verify-mac-address} @@ -301,8 +302,8 @@ like CRI-O and containerd is work in progress. If you are running into difficulties with kubeadm, please consult our [troubleshooting docs](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/). -{{% capture whatsnext %}} +## {{% heading "whatsnext" %}} + * [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) -{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md b/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md index 070dbd7274..8dfcb250ce 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md @@ -2,11 +2,11 @@ reviewers: - sig-cluster-lifecycle title: Configuring each kubelet in your cluster using kubeadm -content_template: templates/concept +content_type: concept weight: 80 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.11" state="stable" >}} @@ -26,9 +26,9 @@ characteristics of a given machine (such as OS, storage, and networking). You ca of your kubelets manually, but kubeadm now provides a `KubeletConfiguration` API type for [managing your kubelet configurations centrally](#configure-kubelets-using-kubeadm). -{{% /capture %}} -{{% capture body %}} + + ## Kubelet configuration patterns @@ -203,4 +203,4 @@ The DEB and RPM packages shipped with the Kubernetes releases are: | `kubernetes-cni` | Installs the official CNI binaries into the `/opt/cni/bin` directory. | | `cri-tools` | Installs the `/usr/bin/crictl` binary from the [cri-tools git repository](https://github.com/kubernetes-incubator/cri-tools). | -{{% /capture %}} + diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md b/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md index 84c98ebe9c..334e2266f2 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md @@ -2,11 +2,11 @@ reviewers: - sig-cluster-lifecycle title: Configuring your kubernetes cluster to self-host the control plane -content_template: templates/concept +content_type: concept weight: 100 --- -{{% capture overview %}} + ### Self-hosting the Kubernetes control plane {#self-hosting} @@ -19,9 +19,9 @@ configured in the kubelet via static files. To create a self-hosted cluster see the [kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) command. -{{% /capture %}} -{{% capture body %}} + + #### Caveats @@ -67,4 +67,4 @@ In summary, `kubeadm alpha selfhosting` works as follows: 1. When the original static control plane stops, the new self-hosted control plane is able to bind to listening ports and become active. -{{% /capture %}} + diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md index 708e10569f..739b405d14 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md @@ -2,11 +2,11 @@ reviewers: - sig-cluster-lifecycle title: Set up a High Availability etcd cluster with kubeadm -content_template: templates/task +content_type: task weight: 70 --- -{{% capture overview %}} + {{< note >}} While kubeadm is being used as the management tool for external etcd nodes @@ -23,9 +23,10 @@ becoming unavailable. This task walks through the process of creating a high availability etcd cluster of three members that can be used as an external etcd when using kubeadm to set up a kubernetes cluster. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * Three hosts that can talk to each other over ports 2379 and 2380. This document assumes these default ports. However, they are configurable through @@ -36,9 +37,9 @@ when using kubeadm to set up a kubernetes cluster. [toolbox]: /docs/setup/production-environment/tools/kubeadm/install-kubeadm/ -{{% /capture %}} -{{% capture steps %}} + + ## Setting up the cluster @@ -264,12 +265,13 @@ this example. - Set `${ETCD_TAG}` to the version tag of your etcd image. For example `3.4.3-0`. To see the etcd image and tag that kubeadm uses execute `kubeadm config images list --kubernetes-version ${K8S_VERSION}`, where `${K8S_VERSION}` is for example `v1.17.0` - Set `${HOST0}`to the IP address of the host you are testing. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + Once you have a working 3 member etcd cluster, you can continue setting up a highly available control plane using the [external etcd method with kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/). -{{% /capture %}} + diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md index 054f4b28fb..a4d6d54cc2 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md @@ -1,10 +1,10 @@ --- title: Troubleshooting kubeadm -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + As with any program, you might run into an error installing or running kubeadm. This page lists some common failure scenarios and have provided steps that can help you understand and fix the problem. @@ -18,9 +18,9 @@ If your problem is not listed below, please follow the following steps: - If you are unsure about how kubeadm works, you can ask on [Slack](http://slack.k8s.io/) in #kubeadm, or open a question on [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Please include relevant tags like `#kubernetes` and `#kubeadm` so folks can help you. -{{% /capture %}} -{{% capture body %}} + + ## Not possible to join a v1.18 Node to a v1.17 cluster due to missing RBAC @@ -131,7 +131,7 @@ sudo kubeadm reset Inspecting the logs for docker may also be useful: ```sh -journalctl -ul docker +journalctl -u docker ``` ## Pods in `RunContainerError`, `CrashLoopBackOff` or `Error` state @@ -404,4 +404,4 @@ nodeRegistration: Alternatively, you can modify `/etc/fstab` to make the `/usr` mount writeable, but please be advised that this is modifying a design principle of the Linux distribution. -{{% /capture %}} + diff --git a/content/en/docs/setup/production-environment/tools/kubespray.md b/content/en/docs/setup/production-environment/tools/kubespray.md index ae323d38cf..07c0b3c574 100644 --- a/content/en/docs/setup/production-environment/tools/kubespray.md +++ b/content/en/docs/setup/production-environment/tools/kubespray.md @@ -1,10 +1,10 @@ --- title: Installing Kubernetes with Kubespray -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Packet (bare metal), Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-sigs/kubespray). @@ -23,9 +23,9 @@ Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [in To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/). -{{% /capture %}} -{{% capture body %}} + + ## Creating a cluster @@ -113,10 +113,10 @@ When running the reset playbook, be sure not to accidentally target your product * Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](http://slack.k8s.io/)) * [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues) -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md). -{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/setup/production-environment/turnkey/aws.md b/content/en/docs/setup/production-environment/turnkey/aws.md index 922f4a3eb9..92dd18075c 100644 --- a/content/en/docs/setup/production-environment/turnkey/aws.md +++ b/content/en/docs/setup/production-environment/turnkey/aws.md @@ -3,16 +3,17 @@ reviewers: - justinsb - clove title: Running Kubernetes on AWS EC2 -content_template: templates/task +content_type: task --- -{{% capture overview %}} + This page describes how to install a Kubernetes cluster on AWS. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + To create a Kubernetes cluster on AWS, you will need an Access Key ID and a Secret Access Key from AWS. @@ -28,9 +29,9 @@ To create a Kubernetes cluster on AWS, you will need an Access Key ID and a Secr * [KubeOne](https://github.com/kubermatic/kubeone) is an open source cluster lifecycle management tool that creates, upgrades and manages Kubernetes Highly-Available clusters. -{{% /capture %}} -{{% capture steps %}} + + ## Getting started with your cluster @@ -90,4 +91,4 @@ AWS | KubeOne | Ubuntu, CoreOS, CentOS | canal, weave Please see the [Kubernetes docs](/docs/) for more details on administering and using a Kubernetes cluster. -{{% /capture %}} + diff --git a/content/en/docs/setup/production-environment/turnkey/gce.md b/content/en/docs/setup/production-environment/turnkey/gce.md index 7ec902d10b..60c4e690d9 100644 --- a/content/en/docs/setup/production-environment/turnkey/gce.md +++ b/content/en/docs/setup/production-environment/turnkey/gce.md @@ -5,16 +5,17 @@ reviewers: - mikedanese - thockin title: Running Kubernetes on Google Compute Engine -content_template: templates/task +content_type: task --- -{{% capture overview %}} + The example below creates a Kubernetes cluster with 3 worker node Virtual Machines and a master Virtual Machine (i.e. 4 VMs in your cluster). This cluster is set up and controlled from your workstation (or wherever you find convenient). -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + If you want a simplified getting started experience and GUI for managing clusters, please consider trying [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) for hosted cluster installation and management. @@ -36,9 +37,9 @@ If you want to use custom binaries or pure open source Kubernetes, please contin 1. Make sure you can start up a GCE VM from the command line. At least make sure you can do the [Create an instance](https://cloud.google.com/compute/docs/instances/#startinstancegcloud) part of the GCE Quickstart. 1. Make sure you can SSH into the VM without interactive prompts. See the [Log in to the instance](https://cloud.google.com/compute/docs/instances/#sshing) part of the GCE Quickstart. -{{% /capture %}} -{{% capture steps %}} + + ## Starting a cluster @@ -225,4 +226,4 @@ GCE | Saltstack | Debian | GCE | [docs](/docs/setup/ Please see the [Kubernetes docs](/docs/) for more details on administering and using a Kubernetes cluster. -{{% /capture %}} + diff --git a/content/en/docs/setup/production-environment/turnkey/icp.md b/content/en/docs/setup/production-environment/turnkey/icp.md index 81375ad370..1ebb7a9267 100644 --- a/content/en/docs/setup/production-environment/turnkey/icp.md +++ b/content/en/docs/setup/production-environment/turnkey/icp.md @@ -27,13 +27,9 @@ The following modules are available where you can deploy IBM Cloud Private by us ## IBM Cloud Private on AWS -You can deploy an IBM Cloud Private cluster on Amazon Web Services (AWS) by using either AWS CloudFormation or Terraform. +You can deploy an IBM Cloud Private cluster on Amazon Web Services (AWS) using Terraform. -IBM Cloud Private has a Quick Start that automatically deploys IBM Cloud Private into a new virtual private cloud (VPC) on the AWS Cloud. A regular deployment takes about 60 minutes, and a high availability (HA) deployment takes about 75 minutes to complete. The Quick Start includes AWS CloudFormation templates and a deployment guide. - -This Quick Start is for users who want to explore application modernization and want to accelerate meeting their digital transformation goals, by using IBM Cloud Private and IBM tooling. The Quick Start helps users rapidly deploy a high availability (HA), production-grade, IBM Cloud Private reference architecture on AWS. For all of the details and the deployment guide, see the [IBM Cloud Private on AWS Quick Start](https://aws.amazon.com/quickstart/architecture/ibm-cloud-private/). - -IBM Cloud Private can also run on the AWS cloud platform by using Terraform. To deploy IBM Cloud Private in an AWS EC2 environment, see [Installing IBM Cloud Private on AWS](https://github.com/ibm-cloud-architecture/refarch-privatecloud/blob/master/Installing_ICp_on_aws.md). +IBM Cloud Private can also run on the AWS cloud platform by using Terraform. To deploy IBM Cloud Private in an AWS EC2 environment, see [Installing IBM Cloud Private on AWS](https://github.com/ibm-cloud-architecture/terraform-icp-aws). ## IBM Cloud Private on Azure diff --git a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md index 78e61d4588..09a74d1450 100644 --- a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md @@ -3,17 +3,17 @@ reviewers: - michmike - patricklang title: Intro to Windows support in Kubernetes -content_template: templates/concept +content_type: concept weight: 65 --- -{{% capture overview %}} + Windows applications constitute a large portion of the services and applications that run in many organizations. [Windows containers](https://aka.ms/windowscontainers) provide a modern way to encapsulate processes and package dependencies, making it easier to use DevOps practices and follow cloud native patterns for Windows applications. Kubernetes has become the defacto standard container orchestrator, and the release of Kubernetes 1.14 includes production support for scheduling Windows containers on Windows nodes in a Kubernetes cluster, enabling a vast ecosystem of Windows applications to leverage the power of Kubernetes. Organizations with investments in Windows-based applications and Linux-based applications don't have to look for separate orchestrators to manage their workloads, leading to increased operational efficiencies across their deployments, regardless of operating system. -{{% /capture %}} -{{% capture body %}} + + ## Windows containers in Kubernetes @@ -584,9 +584,10 @@ If filing a bug, please include detailed information about how to reproduce the * [Relevant logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs) * Tag the issue sig/windows by commenting on the issue with `/sig windows` to bring it to a SIG-Windows member's attention -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + We have a lot of features in our roadmap. An abbreviated high level list is included below, but we encourage you to view our [roadmap project](https://github.com/orgs/kubernetes/projects/8) and help us make Windows support better by [contributing](https://github.com/kubernetes/community/blob/master/sig-windows/). @@ -638,4 +639,4 @@ properly provisioned. * More CNIs * More Storage Plugins -{{% /capture %}} + diff --git a/content/en/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/en/docs/setup/production-environment/windows/user-guide-windows-containers.md index aa1c1f3783..e28afeb9f2 100644 --- a/content/en/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/en/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -3,17 +3,17 @@ reviewers: - michmike - patricklang title: Guide for scheduling Windows containers in Kubernetes -content_template: templates/concept +content_type: concept weight: 75 --- -{{% capture overview %}} + Windows applications constitute a large portion of the services and applications that run in many organizations. This guide walks you through the steps to configure and deploy a Windows container in Kubernetes. -{{% /capture %}} -{{% capture body %}} + + ## Objectives @@ -245,6 +245,6 @@ spec: ``` -{{% /capture %}} + [RuntimeClass]: https://kubernetes.io/docs/concepts/containers/runtime-class/ diff --git a/content/en/docs/setup/release/notes.md b/content/en/docs/setup/release/notes.md index a344a11fc0..d80d6c0ffd 100644 --- a/content/en/docs/setup/release/notes.md +++ b/content/en/docs/setup/release/notes.md @@ -2,7 +2,7 @@ title: v1.18 Release Notes weight: 10 card: - name: download + name: release-notes weight: 20 anchors: - anchor: "#" diff --git a/content/en/docs/setup/release/version-skew-policy.md b/content/en/docs/setup/release/version-skew-policy.md index dc411807c5..cc506352d3 100644 --- a/content/en/docs/setup/release/version-skew-policy.md +++ b/content/en/docs/setup/release/version-skew-policy.md @@ -7,16 +7,16 @@ reviewers: - sig-node - sig-release title: Kubernetes version and version skew support policy -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + This document describes the maximum version skew supported between various Kubernetes components. Specific cluster deployment tools may place additional restrictions on version skew. -{{% /capture %}} -{{% capture body %}} + + ## Supported versions @@ -27,11 +27,11 @@ For more information, see [Kubernetes Release Versioning](https://github.com/kub The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). Applicable fixes, including security fixes, may be backported to those three release branches, depending on severity and feasibility. -Patch releases are cut from those branches at a regular cadence, or as needed. -This decision is owned by the [patch release team](https://github.com/kubernetes/sig-release/blob/master/release-engineering/role-handbooks/patch-release-team.md#release-timing). -The patch release team is part of [release managers](https://github.com/kubernetes/sig-release/blob/master/release-managers.md). For more information, see [Kubernetes Patch releases](https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md). +Patch releases are cut from those branches at a [regular cadence](https://git.k8s.io/sig-release/releases/patch-releases.md#cadence), plus additional urgent releases, when required. -Minor releases occur approximately every 3 months, so each minor release branch is maintained for approximately 9 months. +The [Release Managers](https://git.k8s.io/sig-release/release-managers.md) group owns this decision. + +For more information, see the Kubernetes [patch releases](https://git.k8s.io/sig-release/releases/patch-releases.md) page. ## Supported version skew diff --git a/content/en/docs/tasks/_index.md b/content/en/docs/tasks/_index.md index 1dee1f38f1..552f17e48c 100644 --- a/content/en/docs/tasks/_index.md +++ b/content/en/docs/tasks/_index.md @@ -2,82 +2,18 @@ title: Tasks main_menu: true weight: 50 -content_template: templates/concept +content_type: concept --- -{{< toc >}} - -{{% capture overview %}} + This section of the Kubernetes documentation contains pages that show how to do individual tasks. A task page shows how to do a single thing, typically by giving a short sequence of steps. -{{% /capture %}} -{{% capture body %}} +## {{% heading "whatsnext" %}} -## Web UI (Dashboard) - -Deploy and access the Dashboard web user interface to help you manage and monitor containerized applications in a Kubernetes cluster. - -## Using the kubectl Command-line - -Install and setup the `kubectl` command-line tool used to directly manage Kubernetes clusters. - -## Configuring Pods and Containers - -Perform common configuration tasks for Pods and Containers. - -## Running Applications - -Perform common application management tasks, such as rolling updates, injecting information into pods, and horizontal Pod autoscaling. - -## Running Jobs - -Run Jobs using parallel processing. - -## Accessing Applications in a Cluster - -Configure load balancing, port forwarding, or setup firewall or DNS configurations to access applications in a cluster. - -## Monitoring, Logging, and Debugging - -Setup monitoring and logging to troubleshoot a cluster or debug a containerized application. - -## Accessing the Kubernetes API - -Learn various methods to directly access the Kubernetes API. - -## Using TLS - -Configure your application to trust and use the cluster root Certificate Authority (CA). - -## Administering a Cluster - -Learn common tasks for administering a cluster. - -## Managing Stateful Applications - -Perform common tasks for managing Stateful applications, including scaling, deleting, and debugging StatefulSets. - -## Cluster Daemons - -Perform common tasks for managing a DaemonSet, such as performing a rolling update. - -## Managing GPUs - -Configure and schedule NVIDIA GPUs for use as a resource by nodes in a cluster. - -## Managing HugePages - -Configure and schedule huge pages as a schedulable resource in a cluster. - -{{% /capture %}} - -{{% capture whatsnext %}} If you would like to write a task page, see [Creating a Documentation Pull Request](/docs/home/contribute/create-pull-request/). - -{{% /capture %}} diff --git a/content/en/docs/tasks/access-application-cluster/_index.md b/content/en/docs/tasks/access-application-cluster/_index.md index e829d22b29..4d7af48310 100755 --- a/content/en/docs/tasks/access-application-cluster/_index.md +++ b/content/en/docs/tasks/access-application-cluster/_index.md @@ -1,5 +1,6 @@ --- title: "Access Applications in a Cluster" +description: Configure load balancing, port forwarding, or setup firewall or DNS configurations to access applications in a cluster. weight: 60 --- diff --git a/content/en/docs/tasks/access-application-cluster/access-cluster.md b/content/en/docs/tasks/access-application-cluster/access-cluster.md index 05835f2b08..39ad8b4b7e 100644 --- a/content/en/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/en/docs/tasks/access-application-cluster/access-cluster.md @@ -1,17 +1,17 @@ --- title: Accessing Clusters weight: 20 -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + This topic discusses multiple ways to interact with clusters. -{{% /capture %}} -{{% capture body %}} + + ## Accessing for the first time with kubectl @@ -376,4 +376,3 @@ There are several different proxies you may encounter when using Kubernetes: Kubernetes users will typically not need to worry about anything other than the first two types. The cluster admin will typically ensure that the latter types are setup correctly. -{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md b/content/en/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md index 33547cdca6..1d00516d28 100644 --- a/content/en/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md +++ b/content/en/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md @@ -1,25 +1,26 @@ --- title: Communicate Between Containers in the Same Pod Using a Shared Volume -content_template: templates/task +content_type: task weight: 110 --- -{{% capture overview %}} + This page shows how to use a Volume to communicate between two Containers running in the same Pod. See also how to allow processes to communicate by [sharing process namespace](/docs/tasks/configure-pod-container/share-process-namespace/) between containers. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Creating a Pod that runs two Containers @@ -108,10 +109,10 @@ The output shows that nginx serves a web page written by the debian container: Hello from the debian container -{{% /capture %}} -{{% capture discussion %}} + + ## Discussion @@ -127,10 +128,11 @@ The Volume in this exercise provides a way for Containers to communicate during the life of the Pod. If the Pod is deleted and recreated, any data stored in the shared Volume is lost. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [patterns for composite containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns). @@ -147,7 +149,7 @@ the shared Volume is lost. * See [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core). -{{% /capture %}} + diff --git a/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index acd023548a..3f3100395c 100644 --- a/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -1,6 +1,6 @@ --- title: Configure Access to Multiple Clusters -content_template: templates/task +content_type: task weight: 30 card: name: tasks @@ -8,7 +8,7 @@ card: --- -{{% capture overview %}} + This page shows how to configure access to multiple clusters by using configuration files. After your clusters, users, and contexts are defined in @@ -21,15 +21,21 @@ a *kubeconfig file*. This is a generic way of referring to configuration files. It does not mean that there is a file named `kubeconfig`. {{< /note >}} -{{% /capture %}} -{{% capture prerequisites %}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +## {{% heading "prerequisites" %}} -{{% /capture %}} -{{% capture steps %}} +{{< include "task-tutorial-prereqs.md" >}} + +To check that {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} is installed, +run `kubectl version --client`. The kubectl version should be +[within one minor version](/docs/setup/release/version-skew-policy/#kubectl) of your +cluster's API server. + + + + ## Define clusters, users, and contexts @@ -369,14 +375,15 @@ export KUBECONFIG=$KUBECONFIG_SAVED $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [Organizing Cluster Access Using kubeconfig Files](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) * [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config) -{{% /capture %}} + diff --git a/content/en/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md b/content/en/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md deleted file mode 100644 index 0ab9428a36..0000000000 --- a/content/en/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md +++ /dev/null @@ -1,109 +0,0 @@ ---- -reviewers: -- bprashanth -- davidopp -title: Configure Your Cloud Provider's Firewalls -content_template: templates/task -weight: 90 ---- - -{{% capture overview %}} - -Many cloud providers (e.g. Google Compute Engine) define firewalls that help prevent inadvertent -exposure to the internet. When exposing a service to the external world, you may need to open up -one or more ports in these firewalls to serve traffic. This document describes this process, as -well as any provider specific details that may be necessary. - -{{% /capture %}} - - -{{% capture prerequisites %}} - -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - -{{% /capture %}} - -{{% capture steps %}} - -## Restrict Access For LoadBalancer Service - - When using a Service with `spec.type: LoadBalancer`, you can specify the IP ranges that are allowed to access the load balancer - by using `spec.loadBalancerSourceRanges`. This field takes a list of IP CIDR ranges, which Kubernetes will use to configure firewall exceptions. - This feature is currently supported on Google Compute Engine, Google Kubernetes Engine, AWS Elastic Kubernetes Service, Azure Kubernetes Service, and IBM Cloud Kubernetes Service. This field will be ignored if the cloud provider does not support the feature. - - Assuming 10.0.0.0/8 is the internal subnet. In the following example, a load balancer will be created that is only accessible to cluster internal IPs. - This will not allow clients from outside of your Kubernetes cluster to access the load balancer. - -```yaml -apiVersion: v1 -kind: Service -metadata: - name: myapp -spec: - ports: - - port: 8765 - targetPort: 9376 - selector: - app: example - type: LoadBalancer - loadBalancerSourceRanges: - - 10.0.0.0/8 -``` - - In the following example, a load balancer will be created that is only accessible to clients with IP addresses from 130.211.204.1 and 130.211.204.2. - -```yaml -apiVersion: v1 -kind: Service -metadata: - name: myapp -spec: - ports: - - port: 8765 - targetPort: 9376 - selector: - app: example - type: LoadBalancer - loadBalancerSourceRanges: - - 130.211.204.1/32 - - 130.211.204.2/32 -``` - -## Google Compute Engine - -When using a Service with `spec.type: LoadBalancer`, the firewall will be -opened automatically. When using `spec.type: NodePort`, however, the firewall -is *not* opened by default. - -Google Compute Engine firewalls are documented [elsewhere](https://cloud.google.com/compute/docs/networking#firewalls_1). - -You can add a firewall with the `gcloud` command line tool: - -```shell -gcloud compute firewall-rules create my-rule --allow=tcp: -``` - -{{< note >}} -GCE firewalls are defined per-vm, rather than per-ip address. This means that -when you open a firewall for a service's ports, anything that serves on that -port on that VM's host IP address may potentially serve traffic. Note that this -is not a problem for other Kubernetes services, as they listen on IP addresses -that are different than the host node's external IP address. - -Consider: - - * You create a Service with an external load balancer (IP Address 1.2.3.4) - and port 80 - * You open the firewall for port 80 for all nodes in your cluster, so that - the external Service actually can deliver packets to your Service - * You start an nginx server, running on port 80 on the host virtual machine - (IP Address 2.3.4.5). This nginx is also exposed to the internet on - the VM's external IP address. - -Consequently, please be careful when opening firewalls in Google Compute Engine -or Google Kubernetes Engine. You may accidentally be exposing other services to -the wilds of the internet. - -{{< /note >}} - -{{% /capture %}} diff --git a/content/en/docs/tasks/access-application-cluster/configure-dns-cluster.md b/content/en/docs/tasks/access-application-cluster/configure-dns-cluster.md index 4c17d3128d..3535fdb8bc 100644 --- a/content/en/docs/tasks/access-application-cluster/configure-dns-cluster.md +++ b/content/en/docs/tasks/access-application-cluster/configure-dns-cluster.md @@ -1,13 +1,13 @@ --- title: Configure DNS for a Cluster weight: 120 -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + Kubernetes offers a DNS cluster addon, which most of the supported environments enable by default. In Kubernetes version 1.11 and later, CoreDNS is recommended and is installed by default with kubeadm. -{{% /capture %}} -{{% capture body %}} + + For more information on how to configure CoreDNS for a Kubernetes cluster, see the [Customizing DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers/). An example demonstrating how to use Kubernetes DNS with kube-dns, see the [Kubernetes DNS sample plugin](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns). -{{% /capture %}} + diff --git a/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md b/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md index 264d930d5f..0ce827185c 100644 --- a/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md +++ b/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md @@ -1,30 +1,32 @@ --- title: Connect a Front End to a Back End Using a Service -content_template: templates/tutorial +content_type: tutorial weight: 70 --- -{{% capture overview %}} + This task shows how to create a frontend and a backend microservice. The backend microservice is a hello greeter. The frontend and backend are connected using a Kubernetes {{< glossary_tooltip term_id="service" >}} object. -{{% /capture %}} -{{% capture objectives %}} + +## {{% heading "objectives" %}} + * Create and run a microservice using a {{< glossary_tooltip term_id="deployment" >}} object. * Route traffic to the backend using a frontend. * Use a Service object to connect the frontend application to the backend application. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} @@ -34,10 +36,10 @@ frontend and backend are connected using a Kubernetes support this, you can use a Service of type [NodePort](/docs/concepts/services-networking/service/#nodeport) instead. -{{% /capture %}} -{{% capture lessoncontent %}} + + ## Creating the backend using a Deployment @@ -201,9 +203,10 @@ The output shows the message generated by the backend: {"message":"Hello"} ``` -{{% /capture %}} -{{% capture cleanup %}} + +## {{% heading "cleanup" %}} + To delete the Services, enter this command: @@ -213,13 +216,14 @@ To delete the Deployments, the ReplicaSets and the Pods that are running the bac kubectl delete deployment frontend hello -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [Services](/docs/concepts/services-networking/service/) * Learn more about [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) -{{% /capture %}} + diff --git a/content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md b/content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md index 720203d60d..7dcc613232 100644 --- a/content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md +++ b/content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md @@ -1,11 +1,11 @@ --- title: Create an External Load Balancer -content_template: templates/task +content_type: task weight: 80 --- -{{% capture overview %}} + This page shows how to create an External Load Balancer. @@ -24,15 +24,16 @@ services externally-reachable URLs, load balance the traffic, terminate SSL etc. please check the [Ingress](/docs/concepts/services-networking/ingress/) documentation. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Configuration file @@ -199,4 +200,4 @@ Once the external load balancers provide weights, this functionality can be adde Internal pod to pod traffic should behave similar to ClusterIP services, with equal probability across all pods. -{{% /capture %}} + diff --git a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md index 0a16c71064..9288ec3064 100644 --- a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md +++ b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md @@ -1,25 +1,26 @@ --- title: Set up Ingress on Minikube with the NGINX Ingress Controller -content_template: templates/task +content_type: task weight: 100 --- -{{% capture overview %}} + An [Ingress](/docs/concepts/services-networking/ingress/) is an API object that defines rules which allow external access to services in a cluster. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers/) fulfills the rules set in the Ingress. This page shows you how to set up a simple Ingress which routes requests to Service web or web2 depending on the HTTP URI. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Create a Minikube cluster @@ -275,13 +276,14 @@ The following file is an Ingress resource that sends traffic to your Service via {{< note >}}If you are running Minikube locally, you can visit hello-world.info and hello-world.info/v2 from your browser.{{< /note >}} -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Read more about [Ingress](/docs/concepts/services-networking/ingress/) * Read more about [Ingress Controllers](/docs/concepts/services-networking/ingress-controllers/) * Read more about [Services](/docs/concepts/services-networking/service/) -{{% /capture %}} + diff --git a/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md index b3fb886d11..d1e1ba1568 100644 --- a/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md +++ b/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -1,23 +1,24 @@ --- title: List All Container Images Running in a Cluster -content_template: templates/task +content_type: task weight: 100 --- -{{% capture overview %}} + This page shows how to use kubectl to list all of the Container images for Pods running in a cluster. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + In this exercise you will use kubectl to fetch all of the Pods running in a cluster, and format the output to pull out the list @@ -108,19 +109,20 @@ kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{r -{{% /capture %}} -{{% capture discussion %}} -{{% /capture %}} + + + + +## {{% heading "whatsnext" %}} -{{% capture whatsnext %}} ### Reference * [Jsonpath](/docs/user-guide/jsonpath/) reference guide * [Go template](https://golang.org/pkg/text/template/) reference guide -{{% /capture %}} + diff --git a/content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md b/content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md index fc24022d0c..a6c2e217a5 100644 --- a/content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md +++ b/content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md @@ -1,29 +1,30 @@ --- title: Use Port Forwarding to Access Applications in a Cluster -content_template: templates/task +content_type: task weight: 40 min-kubernetes-server-version: v1.10 --- -{{% capture overview %}} + This page shows how to use `kubectl port-forward` to connect to a Redis server running in a Kubernetes cluster. This type of connection can be useful for database debugging. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * Install [redis-cli](http://redis.io/topics/rediscli). -{{% /capture %}} -{{% capture steps %}} + + ## Creating Redis deployment and service @@ -179,10 +180,10 @@ for database debugging. PONG ``` -{{% /capture %}} -{{% capture discussion %}} + + ## Discussion @@ -196,9 +197,10 @@ The support for UDP protocol is tracked in [issue 47862](https://github.com/kubernetes/kubernetes/issues/47862). {{< /note >}} -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + Learn more about [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands/#port-forward). -{{% /capture %}} + diff --git a/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md index af5eb2db86..fe90981432 100644 --- a/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md +++ b/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md @@ -1,35 +1,37 @@ --- title: Use a Service to Access an Application in a Cluster -content_template: templates/tutorial +content_type: tutorial weight: 60 --- -{{% capture overview %}} + This page shows how to create a Kubernetes Service object that external clients can use to access an application running in a cluster. The Service provides load balancing for an application that has two running instances. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture objectives %}} + +## {{% heading "objectives" %}} + * Run two instances of a Hello World application. * Create a Service object that exposes a node port. * Use the Service object to access the running application. -{{% /capture %}} -{{% capture lessoncontent %}} + + ## Creating a service for an application running in two pods @@ -130,10 +132,11 @@ As an alternative to using `kubectl expose`, you can use a [service configuration file](/docs/concepts/services-networking/service/) to create a Service. -{{% /capture %}} -{{% capture cleanup %}} + +## {{% heading "cleanup" %}} + To delete the Service, enter this command: @@ -144,11 +147,12 @@ the Hello World application, enter this command: kubectl delete deployment hello-world -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + Learn more about [connecting applications with services](/docs/concepts/services-networking/connect-applications-service/). -{{% /capture %}} + diff --git a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md index 88132f5218..7a37fdc20b 100644 --- a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -4,7 +4,7 @@ reviewers: - mikedanese - rf232 title: Web UI (Dashboard) -content_template: templates/concept +content_type: concept weight: 10 card: name: tasks @@ -12,7 +12,7 @@ card: title: Use the Web UI Dashboard --- -{{% capture overview %}} + Dashboard is a web-based Kubernetes user interface. You can use Dashboard to deploy containerized applications to a Kubernetes cluster, troubleshoot your containerized application, and manage the cluster resources. You can use Dashboard to get an overview of applications running on your cluster, as well as for creating or modifying individual Kubernetes resources (such as Deployments, Jobs, DaemonSets, etc). For example, you can scale a Deployment, initiate a rolling update, restart a pod or deploy new applications using a deploy wizard. @@ -20,10 +20,10 @@ Dashboard also provides information on the state of Kubernetes resources in your ![Kubernetes Dashboard UI](/images/docs/ui-dashboard.png) -{{% /capture %}} -{{% capture body %}} + + ## Deploying the Dashboard UI @@ -83,7 +83,11 @@ The deploy wizard expects that you provide the following information: A [Deployment](/docs/concepts/workloads/controllers/deployment/) will be created to maintain the desired number of Pods across your cluster. -- **Service** (optional): For some parts of your application (e.g. frontends) you may want to expose a [Service](/docs/concepts/services-networking/service/) onto an external, maybe public IP address outside of your cluster (external Service). For external Services, you may need to open up one or more ports to do so. Find more details [here](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/). +- **Service** (optional): For some parts of your application (e.g. frontends) you may want to expose a [Service](/docs/concepts/services-networking/service/) onto an external, maybe public IP address outside of your cluster (external Service). + + {{< note >}} + For external Services, you may need to open up one or more ports to do so. + {{< /note >}} Other Services that are only visible from inside the cluster are called internal Services. @@ -162,11 +166,12 @@ Pod lists and detail pages link to a logs viewer that is built into Dashboard. T ![Logs viewer](/images/docs/ui-dashboard-logs-view.png) -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + For more information, see the [Kubernetes Dashboard project page](https://github.com/kubernetes/dashboard). -{{% /capture %}} + diff --git a/content/en/docs/tasks/access-kubernetes-api/_index.md b/content/en/docs/tasks/access-kubernetes-api/_index.md deleted file mode 100755 index f883cdee9d..0000000000 --- a/content/en/docs/tasks/access-kubernetes-api/_index.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: "Extend Kubernetes" -weight: 90 ---- - diff --git a/content/en/docs/tasks/administer-cluster/_index.md b/content/en/docs/tasks/administer-cluster/_index.md index 55154406fe..6d869da354 100755 --- a/content/en/docs/tasks/administer-cluster/_index.md +++ b/content/en/docs/tasks/administer-cluster/_index.md @@ -1,5 +1,6 @@ --- title: "Administer a Cluster" +description: Learn common tasks for administering a cluster. weight: 20 --- diff --git a/content/en/docs/tasks/administer-cluster/access-cluster-api.md b/content/en/docs/tasks/administer-cluster/access-cluster-api.md index 520dd949cd..659c8d777c 100644 --- a/content/en/docs/tasks/administer-cluster/access-cluster-api.md +++ b/content/en/docs/tasks/administer-cluster/access-cluster-api.md @@ -1,18 +1,19 @@ --- title: Access Clusters Using the Kubernetes API -content_template: templates/task +content_type: task --- -{{% capture overview %}} + This page shows how to access clusters using the Kubernetes API. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Accessing the Kubernetes API @@ -449,5 +450,5 @@ The output will be similar to this: } ``` -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/access-cluster-services.md b/content/en/docs/tasks/administer-cluster/access-cluster-services.md index 57cdc835de..979a75a162 100644 --- a/content/en/docs/tasks/administer-cluster/access-cluster-services.md +++ b/content/en/docs/tasks/administer-cluster/access-cluster-services.md @@ -1,18 +1,19 @@ --- title: Access Services Running on Clusters -content_template: templates/task +content_type: task --- -{{% capture overview %}} + This page shows how to connect to services running on the Kubernetes cluster. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Accessing services running on the cluster @@ -132,6 +133,6 @@ You may be able to put an apiserver proxy URL into the address bar of a browser. - Some web apps may not work, particularly those with client side javascript that construct URLs in a way that is unaware of the proxy path prefix. -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/change-default-storage-class.md b/content/en/docs/tasks/administer-cluster/change-default-storage-class.md index a2070bcfe3..453cfef221 100644 --- a/content/en/docs/tasks/administer-cluster/change-default-storage-class.md +++ b/content/en/docs/tasks/administer-cluster/change-default-storage-class.md @@ -1,21 +1,22 @@ --- title: Change the default StorageClass -content_template: templates/task +content_type: task --- -{{% capture overview %}} + This page shows how to change the default Storage Class that is used to provision volumes for PersistentVolumeClaims that have no special requirements. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Why change the default storage class? @@ -93,10 +94,11 @@ for details about addon manager and how to disable individual addons. gold (default) kubernetes.io/gce-pd 1d ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/). -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md index a7ac4d80c9..729c7bde4f 100644 --- a/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md +++ b/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md @@ -1,20 +1,21 @@ --- title: Change the Reclaim Policy of a PersistentVolume -content_template: templates/task +content_type: task --- -{{% capture overview %}} + This page shows how to change the reclaim policy of a Kubernetes PersistentVolume. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Why change reclaim policy of a PersistentVolume @@ -80,9 +81,10 @@ kubectl patch pv -p "{\"spec\":{\"persistentVolumeReclaimPolicy\" `default/claim3` has reclaim policy `Retain`. It will not be automatically deleted when a user deletes claim `default/claim3`. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/). * Learn more about [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims). @@ -91,6 +93,6 @@ kubectl patch pv -p "{\"spec\":{\"persistentVolumeReclaimPolicy\" * [PersistentVolume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core) * [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core) * See the `persistentVolumeReclaimPolicy` field of [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core). -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/cluster-management.md b/content/en/docs/tasks/administer-cluster/cluster-management.md index 65728ec4ee..7cbab3aa2c 100644 --- a/content/en/docs/tasks/administer-cluster/cluster-management.md +++ b/content/en/docs/tasks/administer-cluster/cluster-management.md @@ -3,20 +3,20 @@ reviewers: - lavalamp - thockin title: Cluster Management -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + This document describes several topics related to the lifecycle of a cluster: creating a new cluster, upgrading your cluster's master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a running cluster. -{{% /capture %}} -{{% capture body %}} + + ## Creating and configuring a Cluster @@ -224,4 +224,4 @@ kubectl convert -f pod.yaml --output-version v1 For more options, please refer to the usage of [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert) command. -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md b/content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md index 436584ad14..e4b58b70e3 100644 --- a/content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md +++ b/content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md @@ -3,10 +3,10 @@ reviewers: - davidopp - madhusudancs title: Configure Multiple Schedulers -content_template: templates/task +content_type: task --- -{{% capture overview %}} + Kubernetes ships with a default scheduler that is described [here](/docs/admin/kube-scheduler/). If the default scheduler does not suit your needs you can implement your own scheduler. @@ -19,16 +19,17 @@ document. Please refer to the kube-scheduler implementation in [pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/pkg/scheduler) in the Kubernetes source directory for a canonical example. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Package the scheduler @@ -219,9 +220,9 @@ kubectl create -f pod3.yaml kubectl get pods ``` -{{% /capture %}} -{{% capture discussion %}} + + ### Verifying that the pods were scheduled using the desired schedulers @@ -241,4 +242,4 @@ verify that the pods were scheduled by the desired schedulers. kubectl get events ``` -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md b/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md index 73cecd999b..91661d235f 100644 --- a/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md +++ b/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md @@ -3,23 +3,24 @@ reviewers: - mml - wojtek-t title: Operating etcd clusters for Kubernetes -content_template: templates/task +content_type: task --- -{{% capture overview %}} + {{< glossary_definition term_id="etcd" length="all" prepend="etcd is a ">}} -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Prerequisites @@ -238,4 +239,4 @@ To urgently fix this bug for Kubernetes 1.15 or earlier, build a custom kube-api See ["kube-apiserver 1.13.x refuses to work when first etcd-server is not available"](https://github.com/kubernetes/kubernetes/issues/72102). -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/coredns.md b/content/en/docs/tasks/administer-cluster/coredns.md index 2e50d54f06..32d4f7d7ec 100644 --- a/content/en/docs/tasks/administer-cluster/coredns.md +++ b/content/en/docs/tasks/administer-cluster/coredns.md @@ -3,18 +3,19 @@ reviewers: - johnbelamaric title: Using CoreDNS for Service Discovery min-kubernetes-server-version: v1.9 -content_template: templates/task +content_type: task --- -{{% capture overview %}} + This page describes the CoreDNS upgrade process and how to install CoreDNS instead of kube-dns. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## About CoreDNS @@ -89,14 +90,15 @@ There is a helpful [guideline and walkthrough](https://github.com/coredns/deploy When resource utilisation is a concern, it may be useful to tune the configuration of CoreDNS. For more details, check out the [documentation on scaling CoreDNS](https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md). -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + You can configure [CoreDNS](https://coredns.io) to support many more use cases than kube-dns by modifying the `Corefile`. For more information, see the [CoreDNS site](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/). -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/cpu-management-policies.md b/content/en/docs/tasks/administer-cluster/cpu-management-policies.md index 9568843e87..1b29abf17c 100644 --- a/content/en/docs/tasks/administer-cluster/cpu-management-policies.md +++ b/content/en/docs/tasks/administer-cluster/cpu-management-policies.md @@ -4,10 +4,10 @@ reviewers: - sjenning - ConnorDoyle - balajismaniam -content_template: templates/task +content_type: task --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.12" state="beta" >}} @@ -18,16 +18,17 @@ acceptably. The kubelet provides methods to enable more complex workload placement policies while keeping the abstraction free from explicit placement directives. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## CPU Management Policies @@ -211,4 +212,4 @@ and `requests` are set equal to `limits` when not explicitly specified. And the container's resource limit for the CPU resource is an integer greater than or equal to one. The `nginx` container is granted 2 exclusive CPUs. -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/declare-network-policy.md b/content/en/docs/tasks/administer-cluster/declare-network-policy.md index 1b6a706934..61add5312a 100644 --- a/content/en/docs/tasks/administer-cluster/declare-network-policy.md +++ b/content/en/docs/tasks/administer-cluster/declare-network-policy.md @@ -4,13 +4,14 @@ reviewers: - danwinship title: Declare Network Policy min-kubernetes-server-version: v1.8 -content_template: templates/task +content_type: task --- -{{% capture overview %}} + This document helps you get started using the Kubernetes [NetworkPolicy API](/docs/concepts/services-networking/network-policies/) to declare network policies that govern how pods communicate with each other. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} @@ -25,9 +26,9 @@ Make sure you've configured a network provider with network policy support. Ther {{< note >}} The above list is sorted alphabetically by product name, not by recommendation or preference. This example is valid for a Kubernetes cluster using any of these providers. {{< /note >}} -{{% /capture %}} -{{% capture steps %}} + + ## Create an `nginx` deployment and expose it via a service @@ -146,4 +147,4 @@ Connecting to nginx (10.100.0.16:80) remote file exists ``` -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/developing-cloud-controller-manager.md b/content/en/docs/tasks/administer-cluster/developing-cloud-controller-manager.md index 0e80a018c4..0f6579d915 100644 --- a/content/en/docs/tasks/administer-cluster/developing-cloud-controller-manager.md +++ b/content/en/docs/tasks/administer-cluster/developing-cloud-controller-manager.md @@ -4,18 +4,18 @@ reviewers: - thockin - wlan0 title: Developing Cloud Controller Manager -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.11" state="beta" >}} {{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="The cloud-controller-manager is">}} -{{% /capture %}} -{{% capture body %}} + + ## Background @@ -41,4 +41,4 @@ controller manager as your starting point. For in-tree cloud providers, you can run the in-tree cloud controller manager as a {{< glossary_tooltip term_id="daemonset" >}} in your cluster. See [Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/) for more details. -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md b/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md index f3101bf6c9..f436b641a0 100644 --- a/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md +++ b/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md @@ -3,49 +3,54 @@ reviewers: - bowei - zihongz title: Customizing DNS Service -content_template: templates/task +content_type: task +min-kubernetes-server-version: v1.12 --- -{{% capture overview %}} -This page explains how to configure your DNS Pod and customize the -DNS resolution process. In Kubernetes version 1.11 and later, CoreDNS is at GA -and is installed by default with kubeadm. See [CoreDNS ConfigMap options](#coredns-configmap-options) -and [Using CoreDNS for Service Discovery](/docs/tasks/administer-cluster/coredns/). -{{% /capture %}} + +This page explains how to configure your DNS +{{< glossary_tooltip text="Pod(s)" term_id="pod" >}} and customize the +DNS resolution process in your cluster. -{{% capture prerequisites %}} -* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -* Kubernetes version 1.6 or later. To work with CoreDNS, version 1.9 or later. -* The appropriate add-on: kube-dns or CoreDNS. To install with kubeadm, -see [the kubeadm reference documentation](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-phase-addon). -{{% /capture %}} +## {{% heading "prerequisites" %}} -{{% capture steps %}} +{{< include "task-tutorial-prereqs.md" >}} + +Your cluster must be running the CoreDNS add-on. +[Migrating to CoreDNS](https://kubernetes.io/docs/tasks/administer-cluster/coredns/#migrating-to-coredns) +explains how to use `kubeadm` to migrate from `kube-dns`. + +{{% version-check %}} + + ## Introduction DNS is a built-in Kubernetes service launched automatically -using the addon manager +using the _addon manager_ [cluster add-on](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md). -As of Kubernetes v1.12, CoreDNS is the recommended DNS Server, replacing kube-dns. However, kube-dns may still be installed by -default with certain Kubernetes installer tools. Refer to the documentation provided by your installer to know which DNS server is installed by default. +As of Kubernetes v1.12, CoreDNS is the recommended DNS Server, replacing kube-dns. If your cluster +originally used kube-dns, you may still have `kube-dns` deployed rather than CoreDNS. +{{< note >}} +Both the CoreDNS and kube-dns Service are named `kube-dns` in the `metadata.name` field. +This is so that there is greater interoperability with workloads that relied on the legacy `kube-dns` Service name to resolve addresses internal to the cluster. Using a Service named `kube-dns` abstracts away the implementation detail of which DNS provider is running behind that common name. +{{< /note >}} -The CoreDNS Deployment is exposed as a Kubernetes Service with a static IP. -Both the CoreDNS and kube-dns Service are named `kube-dns` in the `metadata.name` field. This is done so that there is greater interoperability with workloads that relied on the legacy `kube-dns` Service name to resolve addresses internal to the cluster. It abstracts away the implementation detail of which DNS provider is running behind that common endpoint. -The kubelet passes DNS to each container with the `--cluster-dns=` flag. +If you are running CoreDNS as a Deployment, it will typically be exposed as a Kubernetes Service with a static IP address. +The kubelet passes DNS resolver information to each container with the `--cluster-dns=` flag. DNS names also need domains. You configure the local domain in the kubelet with the flag `--cluster-domain=`. -The DNS server supports forward lookups (A records), port lookups (SRV records), reverse IP address lookups (PTR records), -and more. For more information see [DNS for Services and Pods] (/docs/concepts/services-networking/dns-pod-service/). +The DNS server supports forward lookups (A and AAAA records), port lookups (SRV records), reverse IP address lookups (PTR records), +and more. For more information, see [DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/). -If a Pod's `dnsPolicy` is set to "`default`", it inherits the name resolution +If a Pod's `dnsPolicy` is set to `default`, it inherits the name resolution configuration from the node that the Pod runs on. The Pod's DNS resolution should behave the same as the node. -But see [Known issues](/docs/tasks/administer-cluster/dns-debugging-resolution/#known-issues). +But see [Known issues](/docs/tasks/debug-application-cluster/dns-debugging-resolution/#known-issues). If you don't want this, or if you want a different DNS config for pods, you can use the kubelet's `--resolv-conf` flag. Set this flag to "" to prevent Pods from @@ -58,11 +63,13 @@ CoreDNS is a general-purpose authoritative DNS server that can serve as cluster ### CoreDNS ConfigMap options -CoreDNS is a DNS server that is modular and pluggable, and each plugin adds new functionality to CoreDNS. +CoreDNS is a DNS server that is modular and pluggable, and each plugin adds new functionality to CoreDNS. This can be configured by maintaining a [Corefile](https://coredns.io/2017/07/23/corefile-explained/), which is the CoreDNS -configuration file. A cluster administrator can modify the ConfigMap for the CoreDNS Corefile to change how service discovery works. +configuration file. As a cluster administrator, you can modify the +{{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} for the CoreDNS Corefile to change how DNS service discovery +behaves for that cluster. -In Kubernetes, CoreDNS is installed with the following default Corefile configuration. +In Kubernetes, CoreDNS is installed with the following default Corefile configuration: ```yaml apiVersion: v1 @@ -90,17 +97,16 @@ data: reload loadbalance } -``` +``` + The Corefile configuration includes the following [plugins](https://coredns.io/plugins/) of CoreDNS: * [errors](https://coredns.io/plugins/errors/): Errors are logged to stdout. -* [health](https://coredns.io/plugins/health/): Health of CoreDNS is reported to http://localhost:8080/health. In this extended syntax `lameduck` will make the process unhealthy then wait for 5 seconds before the process is shut down. +* [health](https://coredns.io/plugins/health/): Health of CoreDNS is reported to `http://localhost:8080/health`. In this extended syntax `lameduck` will make the process unhealthy then wait for 5 seconds before the process is shut down. * [ready](https://coredns.io/plugins/ready/): An HTTP endpoint on port 8181 will return 200 OK, when all plugins that are able to signal readiness have done so. -* [kubernetes](https://coredns.io/plugins/kubernetes/): CoreDNS will reply to DNS queries based on IP of the services and pods of Kubernetes. You can find more details [here](https://coredns.io/plugins/kubernetes/). `ttl` allows you to set a custom TTL for responses. The default is 5 seconds. The minimum TTL allowed is 0 seconds, and the maximum is capped at 3600 seconds. Setting TTL to 0 will prevent records from being cached. - -> The `pods insecure` option is provided for backward compatibility with kube-dns. You can use the `pods verified` option, which returns an A record only if there exists a pod in same namespace with matching IP. The `pods disabled` option can be used if you don't use pod records. - -* [prometheus](https://coredns.io/plugins/metrics/): Metrics of CoreDNS are available at http://localhost:9153/metrics in [Prometheus](https://prometheus.io/) format. +* [kubernetes](https://coredns.io/plugins/kubernetes/): CoreDNS will reply to DNS queries based on IP of the services and pods of Kubernetes. You can find [more details](https://coredns.io/plugins/kubernetes/) about that plugin on the CoreDNS website. `ttl` allows you to set a custom TTL for responses. The default is 5 seconds. The minimum TTL allowed is 0 seconds, and the maximum is capped at 3600 seconds. Setting TTL to 0 will prevent records from being cached. + The `pods insecure` option is provided for backward compatibility with _kube-dns_. You can use the `pods verified` option, which returns an A record only if there exists a pod in same namespace with matching IP. The `pods disabled` option can be used if you don't use pod records. +* [prometheus](https://coredns.io/plugins/metrics/): Metrics of CoreDNS are available at `http://localhost:9153/metrics` in [Prometheus](https://prometheus.io/) format (also known as OpenMetrics). * [forward](https://coredns.io/plugins/forward/): Any queries that are not within the cluster domain of Kubernetes will be forwarded to predefined resolvers (/etc/resolv.conf). * [cache](https://coredns.io/plugins/cache/): This enables a frontend cache. * [loop](https://coredns.io/plugins/loop/): Detects simple forwarding loops and halts the CoreDNS process if a loop is found. @@ -128,7 +134,7 @@ To explicitly force all non-cluster DNS lookups to go through a specific nameser ``` forward . 172.16.0.1 -``` +``` The final ConfigMap along with the default `Corefile` configuration looks like: @@ -160,149 +166,14 @@ data: forward . 10.150.0.1 } ``` -In Kubernetes version 1.10 and later, kubeadm supports automatic translation of the CoreDNS ConfigMap from the kube-dns ConfigMap. -***Note: While kube-dns accepts an FQDN for stubdomain and nameserver (eg: ns.foo.com), CoreDNS does not support this feature. -During translation, all FQDN nameservers will be omitted from the CoreDNS config.*** -## Kube-dns +The `kubeadm` tool supports automatic translation from the kube-dns ConfigMap +to the equivalent CoreDNS ConfigMap. -Kube-dns is now available as an optional DNS server since CoreDNS is now the default. -The running DNS Pod holds 3 containers: - -- "`kubedns`": watches the Kubernetes master for changes - in Services and Endpoints, and maintains in-memory lookup structures to serve - DNS requests. -- "`dnsmasq`": adds DNS caching to improve performance. -- "`sidecar`": provides a single health check endpoint - to perform healthchecks for `dnsmasq` and `kubedns`. - -### Configure stub-domain and upstream DNS servers - -Cluster administrators can specify custom stub domains and upstream nameservers -by providing a ConfigMap for kube-dns (`kube-system:kube-dns`). - -For example, the following ConfigMap sets up a DNS configuration with a single stub domain and two -upstream nameservers: - -```yaml -apiVersion: v1 -kind: ConfigMap -metadata: - name: kube-dns - namespace: kube-system -data: - stubDomains: | - {"acme.local": ["1.2.3.4"]} - upstreamNameservers: | - ["8.8.8.8", "8.8.4.4"] -``` - -DNS requests with the “.acme.local” suffix -are forwarded to a DNS listening at 1.2.3.4. Google Public DNS -serves the upstream queries. - -The table below describes how queries with certain domain names map to -their destination DNS servers: - -| Domain name | Server answering the query | -| ----------- | -------------------------- | -| kubernetes.default.svc.cluster.local| kube-dns | -| foo.acme.local| custom DNS (1.2.3.4) | -| widget.com | upstream DNS (one of 8.8.8.8, 8.8.4.4) | - -See [ConfigMap options](#configmap-options) for -details about the configuration option format. - -{{% /capture %}} - -{{% capture discussion %}} - -#### Effects on Pods - -Custom upstream nameservers and stub domains do not affect Pods with a -`dnsPolicy` set to "`Default`" or "`None`". - -If a Pod's `dnsPolicy` is set to "`ClusterFirst`", its name resolution is -handled differently, depending on whether stub-domain and upstream DNS servers -are configured. - -**Without custom configurations**: Any query that does not match the configured -cluster domain suffix, such as "www.kubernetes.io", is forwarded to the upstream -nameserver inherited from the node. - -**With custom configurations**: If stub domains and upstream DNS servers are -configured, -DNS queries are routed according to the following flow: - -1. The query is first sent to the DNS caching layer in kube-dns. - -1. From the caching layer, the suffix of the request is examined and then - forwarded to the appropriate DNS, based on the following cases: - - * *Names with the cluster suffix*, for example ".cluster.local": - The request is sent to kube-dns. - - * *Names with the stub domain suffix*, for example ".acme.local": - The request is sent to the configured custom DNS resolver, listening for example at 1.2.3.4. - - * *Names without a matching suffix*, for example "widget.com": - The request is forwarded to the upstream DNS, - for example Google public DNS servers at 8.8.8.8 and 8.8.4.4. - -![DNS lookup flow](/docs/tasks/administer-cluster/dns-custom-nameservers/dns.png) - -### ConfigMap options - -Options for the kube-dns `kube-system:kube-dns` ConfigMap: - -| Field | Format | Description | -| ----- | ------ | ----------- | -| `stubDomains` (optional) | A JSON map using a DNS suffix key such as “acme.local”, and a value consisting of a JSON array of DNS IPs. | The target nameserver can itself be a Kubernetes Service. For instance, you can run your own copy of dnsmasq to export custom DNS names into the ClusterDNS namespace. | -| `upstreamNameservers` (optional) | A JSON array of DNS IPs. | If specified, the values replace the nameservers taken by default from the node’s `/etc/resolv.conf`. Limits: a maximum of three upstream nameservers can be specified. | - -#### Examples - -##### Example: Stub domain - -In this example, the user has a Consul DNS service discovery system they want to -integrate with kube-dns. The consul domain server is located at 10.150.0.1, and -all consul names have the suffix `.consul.local`. To configure Kubernetes, the -cluster administrator creates the following ConfigMap: - -```yaml -apiVersion: v1 -kind: ConfigMap -metadata: - name: kube-dns - namespace: kube-system -data: - stubDomains: | - {"consul.local": ["10.150.0.1"]} -``` - -Note that the cluster administrator does not want to override the node’s -upstream nameservers, so they did not specify the optional -`upstreamNameservers` field. - -##### Example: Upstream nameserver - -In this example the cluster administrator wants to explicitly force all -non-cluster DNS lookups to go through their own nameserver at 172.16.0.1. -In this case, they create a ConfigMap with the -`upstreamNameservers` field specifying the desired nameserver: - -```yaml -apiVersion: v1 -kind: ConfigMap -metadata: - name: kube-dns - namespace: kube-system -data: - upstreamNameservers: | - ["172.16.0.1"] -``` - -{{% /capture %}} +{{< note >}} +While kube-dns accepts an FQDN for stubdomain and nameserver (eg: ns.foo.com), CoreDNS does not support this feature. +During translation, all FQDN nameservers will be omitted from the CoreDNS config. +{{< /note >}} ## CoreDNS configuration equivalent to kube-dns @@ -312,7 +183,7 @@ Similarly, the `Federations` plugin in kube-dns translates to the `federation` p ### Example -This example ConfigMap for kubedns specifies federations, stubdomains and upstreamnameservers: +This example ConfigMap for kube-dns specifies federations, stubdomains and upstreamnameservers: ```yaml apiVersion: v1 @@ -329,59 +200,65 @@ kind: ConfigMap The equivalent configuration in CoreDNS creates a Corefile: * For federations: -```yaml +``` federation cluster.local { - foo foo.feddomain.com - } + foo foo.feddomain.com +} ``` * For stubDomains: ```yaml abc.com:53 { - errors - cache 30 - forward . 1.2.3.4 - } - my.cluster.local:53 { - errors - cache 30 - forward . 2.3.4.5 - } + errors + cache 30 + forward . 1.2.3.4 +} +my.cluster.local:53 { + errors + cache 30 + forward . 2.3.4.5 +} ``` The complete Corefile with the default plugins: -```yaml +``` .:53 { - errors - health - kubernetes cluster.local in-addr.arpa ip6.arpa { - pods insecure - fallthrough in-addr.arpa ip6.arpa - } - federation cluster.local { - foo foo.feddomain.com - } - prometheus :9153 - forward . 8.8.8.8 8.8.4.4 - cache 30 + errors + health + kubernetes cluster.local in-addr.arpa ip6.arpa { + pods insecure + fallthrough in-addr.arpa ip6.arpa } - abc.com:53 { - errors - cache 30 - forward . 1.2.3.4 - } - my.cluster.local:53 { - errors - cache 30 - forward . 2.3.4.5 + federation cluster.local { + foo foo.feddomain.com } + prometheus :9153 + forward . 8.8.8.8 8.8.4.4 + cache 30 +} +abc.com:53 { + errors + cache 30 + forward . 1.2.3.4 +} +my.cluster.local:53 { + errors + cache 30 + forward . 2.3.4.5 +} ``` ## Migration to CoreDNS -To migrate from kube-dns to CoreDNS, [a detailed blog](https://coredns.io/2018/05/21/migration-from-kube-dns-to-coredns/) is available to help users adapt CoreDNS in place of kube-dns. -A cluster administrator can also migrate using [the deploy script](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh). +To migrate from kube-dns to CoreDNS, a detailed +[blog article](https://coredns.io/2018/05/21/migration-from-kube-dns-to-coredns/) +is available to help users adapt CoreDNS in place of kube-dns. -## What's next -- [Debugging DNS Resolution](/docs/tasks/administer-cluster/dns-debugging-resolution/). +You can also migrate using the offical CoreDNS +[deploy script](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh). + + +## {{% heading "whatsnext" %}} + +- Read [Debugging DNS Resolution](/docs/tasks/debug-application-cluster/dns-debugging-resolution/) diff --git a/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md b/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md index 5d5dc98ade..6fd887bd8f 100644 --- a/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md +++ b/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md @@ -1,14 +1,15 @@ --- title: Autoscale the DNS Service in a Cluster -content_template: templates/task +content_type: task --- -{{% capture overview %}} + This page shows how to enable and configure autoscaling of the DNS service in your Kubernetes cluster. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} @@ -16,9 +17,9 @@ your Kubernetes cluster. * Make sure [Kubernetes DNS](/docs/concepts/services-networking/dns-pod-service/) is enabled. -{{% /capture %}} -{{% capture steps %}} + + ## Determine whether DNS horizontal autoscaling is already enabled {#determining-whether-dns-horizontal-autoscaling-is-already-enabled} @@ -201,9 +202,9 @@ The common path for this dns-autoscaler is: After the manifest file is deleted, the Addon Manager will delete the dns-autoscaler Deployment. -{{% /capture %}} -{{% capture discussion %}} + + ## Understanding how DNS horizontal autoscaling works @@ -226,10 +227,11 @@ the autoscaler Pod. * The autoscaler provides a controller interface to support two control patterns: *linear* and *ladder*. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Read about [Guaranteed Scheduling For Critical Add-On Pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/). * Learn more about the [implementation of cluster-proportional-autoscaler](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler). -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/enabling-endpointslices.md b/content/en/docs/tasks/administer-cluster/enabling-endpointslices.md index b8e4cf900d..b9e389ead7 100644 --- a/content/en/docs/tasks/administer-cluster/enabling-endpointslices.md +++ b/content/en/docs/tasks/administer-cluster/enabling-endpointslices.md @@ -3,19 +3,20 @@ reviewers: - bowei - freehan title: Enabling EndpointSlices -content_template: templates/task +content_type: task --- -{{% capture overview %}} + This page provides an overview of enabling EndpointSlices in Kubernetes. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Introduction @@ -55,9 +56,10 @@ existing Endpoints functionality, EndpointSlices include new bits of information such as topology. They will allow for greater scalability and extensibility of network endpoints in your cluster. -{{% capture whatsnext %}} +## {{% heading "whatsnext" %}} + * Read about [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/enabling-service-topology.md b/content/en/docs/tasks/administer-cluster/enabling-service-topology.md index c39b9b366d..998bb8b2e5 100644 --- a/content/en/docs/tasks/administer-cluster/enabling-service-topology.md +++ b/content/en/docs/tasks/administer-cluster/enabling-service-topology.md @@ -4,19 +4,20 @@ reviewers: - johnbelamaric - imroc title: Enabling Service Topology -content_template: templates/task +content_type: task --- -{{% capture overview %}} + This page provides an overview of enabling Service Topology in Kubernetes. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Introduction @@ -45,10 +46,11 @@ To enable service topology, enable the `ServiceTopology` and `EndpointSlice` fea ``` -{{% capture whatsnext %}} +## {{% heading "whatsnext" %}} + * Read about the [Service Topology](/docs/concepts/services-networking/service-topology) concept * Read about [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices) * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/encrypt-data.md b/content/en/docs/tasks/administer-cluster/encrypt-data.md index b96f034963..8499855bb0 100644 --- a/content/en/docs/tasks/administer-cluster/encrypt-data.md +++ b/content/en/docs/tasks/administer-cluster/encrypt-data.md @@ -2,23 +2,24 @@ reviewers: - smarterclayton title: Encrypting Secret Data at Rest -content_template: templates/task +content_type: task min-kubernetes-server-version: 1.13 --- -{{% capture overview %}} + This page shows how to enable and configure encryption of secret data at rest. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * etcd v3.0 or later is required -{{% /capture %}} -{{% capture steps %}} + + ## Configuration and determining whether encryption at rest is already enabled @@ -215,4 +216,4 @@ kubectl get secrets --all-namespaces -o json | kubectl replace -f - ``` to force all secrets to be decrypted. -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/extended-resource-node.md b/content/en/docs/tasks/administer-cluster/extended-resource-node.md index 49e491d251..07d8fea616 100644 --- a/content/en/docs/tasks/administer-cluster/extended-resource-node.md +++ b/content/en/docs/tasks/administer-cluster/extended-resource-node.md @@ -1,26 +1,27 @@ --- title: Advertise Extended Resources for a Node -content_template: templates/task +content_type: task --- -{{% capture overview %}} + This page shows how to specify extended resources for a Node. Extended resources allow cluster administrators to advertise node-level resources that would otherwise be unknown to Kubernetes. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Get the names of your Nodes @@ -189,10 +190,11 @@ kubectl describe node | grep dongle (you should not see any output) -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + ### For application developers @@ -204,4 +206,4 @@ kubectl describe node | grep dongle * [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/) -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md b/content/en/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md index 0b00eed125..0d5b6d4ebe 100644 --- a/content/en/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md +++ b/content/en/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md @@ -4,10 +4,10 @@ reviewers: - filipg - piosz title: Guaranteed Scheduling For Critical Add-On Pods -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + In addition to Kubernetes core components like api-server, scheduler, controller-manager running on a master machine there are a number of add-ons which, for various reasons, must run on a regular cluster node (rather than the Kubernetes master). @@ -19,14 +19,14 @@ vacated by the evicted critical add-on pod or the amount of resources available Note that marking a pod as critical is not meant to prevent evictions entirely; it only prevents the pod from becoming permanently unavailable. For static pods, this means it can't be evicted, but for non-static pods, it just means they will always be rescheduled. -{{% /capture %}} -{{% capture body %}} + + ### Marking pod as critical To mark a Pod as critical, set priorityClassName for that Pod to `system-cluster-critical` or `system-node-critical`. `system-node-critical` is the highest available priority, even higher than `system-cluster-critical`. -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/highly-available-master.md b/content/en/docs/tasks/administer-cluster/highly-available-master.md index e5529da7c7..e2a582f8b2 100644 --- a/content/en/docs/tasks/administer-cluster/highly-available-master.md +++ b/content/en/docs/tasks/administer-cluster/highly-available-master.md @@ -2,26 +2,27 @@ reviewers: - jszczepkowski title: Set up High-Availability Kubernetes Masters -content_template: templates/task +content_type: task --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.5" state="alpha" >}} You can replicate Kubernetes masters in `kube-up` or `kube-down` scripts for Google Compute Engine. This document describes how to use kube-up/down scripts to manage highly available (HA) masters and how HA masters are implemented for use with GCE. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Starting an HA-compatible cluster @@ -118,9 +119,9 @@ If the cluster is large, it may take a long time to duplicate its state. This operation may be sped up by migrating etcd data directory, as described [here](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration) (we are considering adding support for etcd data dir migration in future). -{{% /capture %}} -{{% capture discussion %}} + + ## Implementation notes @@ -173,4 +174,4 @@ To make such deployment secure, communication between etcd instances is authoriz [Automated HA master deployment - design doc](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md) -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/ip-masq-agent.md b/content/en/docs/tasks/administer-cluster/ip-masq-agent.md index bdc871ddd9..9c2e1d3d5d 100644 --- a/content/en/docs/tasks/administer-cluster/ip-masq-agent.md +++ b/content/en/docs/tasks/administer-cluster/ip-masq-agent.md @@ -1,19 +1,20 @@ --- title: IP Masquerade Agent User Guide -content_template: templates/task +content_type: task --- -{{% capture overview %}} + This page shows how to configure and enable the ip-masq-agent. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture discussion %}} + + ## IP Masquerade Agent User Guide The ip-masq-agent configures iptables rules to hide a pod's IP address behind the cluster node's IP address. This is typically done when sending traffic to destinations outside the cluster's pod [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) range. @@ -53,9 +54,9 @@ MASQUERADE all -- anywhere anywhere /* ip-masq-agent: By default, in GCE/Google Kubernetes Engine starting with Kubernetes version 1.7.0, if network policy is enabled or you are using a cluster CIDR not in the 10.0.0.0/8 range, the ip-masq-agent will run in your cluster. If you are running in another environment, you can add the ip-masq-agent [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) to your cluster: -{{% /capture %}} -{{% capture steps %}} + + ## Create an ip-masq-agent To create an ip-masq-agent, run the following kubectl command: @@ -110,4 +111,4 @@ nonMasqueradeCIDRs: resyncInterval: 60s masqLinkLocal: true ``` -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/kms-provider.md b/content/en/docs/tasks/administer-cluster/kms-provider.md index d90ca853cf..34cc1d6b66 100644 --- a/content/en/docs/tasks/administer-cluster/kms-provider.md +++ b/content/en/docs/tasks/administer-cluster/kms-provider.md @@ -2,13 +2,14 @@ reviewers: - smarterclayton title: Using a KMS provider for data encryption -content_template: templates/task +content_type: task --- -{{% capture overview %}} + This page shows how to configure a Key Management Service (KMS) provider and plugin to enable secret data encryption. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} @@ -18,9 +19,9 @@ This page shows how to configure a Key Management Service (KMS) provider and plu {{< feature-state for_k8s_version="v1.12" state="beta" >}} -{{% /capture %}} -{{% capture steps %}} + + The KMS encryption provider uses an envelope encryption scheme to encrypt data in etcd. The data is encrypted using a data encryption key (DEK); a new DEK is generated for each encryption. The DEKs are encrypted with a key encryption key (KEK) that is stored and managed in a remote KMS. The KMS provider uses gRPC to communicate with a specific KMS plugin. The KMS plugin, which is implemented as a gRPC server and deployed on the same host(s) as the Kubernetes master(s), is responsible for all communication with the remote KMS. @@ -183,4 +184,4 @@ To disable encryption at rest: ``` kubectl get secrets --all-namespaces -o json | kubectl replace -f - ``` -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md index 28df69c13a..e82c53f3a6 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md @@ -4,20 +4,21 @@ reviewers: - patricklang title: Adding Windows nodes min-kubernetes-server-version: 1.17 -content_template: templates/tutorial +content_type: tutorial weight: 30 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.18" state="beta" >}} You can use Kubernetes to run a mixture of Linux and Windows nodes, so you can mix Pods that run on Linux on with Pods that run on Windows. This page shows how to register Windows nodes to your cluster. -{{% /capture %}} -{{% capture prerequisites %}} {{< version-check >}} + +## {{% heading "prerequisites" %}} + {{< version-check >}} * Obtain a [Windows Server 2019 license](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) (or higher) in order to configure the Windows node that hosts Windows containers. @@ -25,18 +26,19 @@ If you are using VXLAN/Overlay networking you must have also have [KB4489899](ht * A Linux-based Kubernetes kubeadm cluster in which you have access to the control plane (see [Creating a single control-plane cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)). -{{% /capture %}} -{{% capture objectives %}} + +## {{% heading "objectives" %}} + * Register a Windows node to the cluster * Configure networking so Pods and Services on Linux and Windows can communicate with each other -{{% /capture %}} -{{% capture lessoncontent %}} + + ## Getting Started: Adding a Windows Node to Your Cluster @@ -176,10 +178,11 @@ kubectl -n kube-system get pods -l app=flannel Once the flannel Pod is running, your node should enter the `Ready` state and then be available to handle workloads. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + - [Upgrading Windows kubeadm nodes](/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes) -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index 6329c4a395..461e45bda6 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -2,25 +2,26 @@ reviewers: - sig-cluster-lifecycle title: Certificate Management with kubeadm -content_template: templates/task +content_type: task weight: 10 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.15" state="stable" >}} Client certificates generated by [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) expire after 1 year. This page explains how to manage certificate renewals with kubeadm. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + You should be familiar with [PKI certificates and requirements in Kubernetes](/docs/setup/best-practices/certificates/). -{{% /capture %}} -{{% capture steps %}} + + ## Using custom certificates {#custom-certificates} @@ -242,4 +243,8 @@ After a certificate is signed using your preferred method, the certificate and t [cert-cas]: /docs/setup/best-practices/certificates/#single-root-ca [cert-table]: /docs/setup/best-practices/certificates/#all-certificates -{{% /capture %}} +## Certificate authority (CA) rotation {#certificate-authority-rotation} + +Kubeadm does not support rotation or replacement of CA certificates out of the box. + +For more information about manual rotation or replacement of CA, see [manual rotation of CA certificates](/docs/tasks/tls/manual-rotation-of-ca-certificates/). diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index f0368ecaf9..2c4c3d135e 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -2,12 +2,12 @@ reviewers: - sig-cluster-lifecycle title: Upgrading kubeadm clusters -content_template: templates/task +content_type: task weight: 20 min-kubernetes-server-version: 1.18 --- -{{% capture overview %}} + This page explains how to upgrade a Kubernetes cluster created with kubeadm from version 1.17.x to version 1.18.x, and from version 1.18.x to 1.18.y (where `y > x`). @@ -26,9 +26,10 @@ The upgrade workflow at high level is the following: 1. Upgrade additional control plane nodes. 1. Upgrade worker nodes. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + - You need to have a kubeadm Kubernetes cluster running version 1.17.0 or later. - [Swap must be disabled](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux). @@ -44,9 +45,9 @@ The upgrade workflow at high level is the following: or between PATCH versions of the same MINOR. That is, you cannot skip MINOR versions when you upgrade. For example, you can upgrade from 1.y to 1.y+1, but not from 1.y to 1.y+2. -{{% /capture %}} -{{% capture steps %}} + + ## Determine which version to upgrade to @@ -148,7 +149,7 @@ Find the latest stable 1.18 version: {{< note >}} `kubeadm upgrade` also automatically renews the certificates that it manages on this node. To opt-out of certificate renewal the flag `--certificate-renewal=false` can be used. -For more information see the [certificate management guide](/docs/tasks/administer-cluster/kubeadmkubeadm-certs). +For more information see the [certificate management guide](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs). {{}} - Choose a version to upgrade to, and run the appropriate command. For example: @@ -295,6 +296,7 @@ Upgrade the kubelet and kubectl on all control plane nodes: Restart the kubelet ```shell +sudo systemctl daemon-reload sudo systemctl restart kubelet ``` @@ -373,6 +375,7 @@ without compromising the minimum required capacity for running your workloads. - Restart the kubelet ```shell + sudo systemctl daemon-reload sudo systemctl restart kubelet ``` @@ -395,7 +398,7 @@ kubectl get nodes The `STATUS` column should show `Ready` for all your nodes, and the version number should be updated. -{{% /capture %}} + ## Recovering from a failure state @@ -441,4 +444,4 @@ and post-upgrade manifest file for a certain component, a backup file for it wil `kubeadm upgrade node` does the following on worker nodes: - Fetches the kubeadm `ClusterConfiguration` from the cluster. -- Upgrades the kubelet configuration for this node. \ No newline at end of file +- Upgrades the kubelet configuration for this node. diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md b/content/en/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md index a6c626a627..35857d09a0 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md @@ -1,29 +1,30 @@ --- title: Upgrading Windows nodes min-kubernetes-server-version: 1.17 -content_template: templates/task +content_type: task weight: 40 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.18" state="beta" >}} This page explains how to upgrade a Windows node [created with kubeadm](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes). -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * Familiarize yourself with [the process for upgrading the rest of your kubeadm cluster](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade). You will want to upgrade the control plane nodes before upgrading your Windows nodes. -{{% /capture %}} -{{% capture steps %}} + + ## Upgrading worker nodes @@ -90,4 +91,4 @@ again replacing {{< param "fullversion" >}} with your desired version: ``` -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/kubelet-config-file.md b/content/en/docs/tasks/administer-cluster/kubelet-config-file.md index 6ffe290a19..54cd837370 100644 --- a/content/en/docs/tasks/administer-cluster/kubelet-config-file.md +++ b/content/en/docs/tasks/administer-cluster/kubelet-config-file.md @@ -3,10 +3,10 @@ reviewers: - mtaufen - dawnchen title: Set Kubelet parameters via a config file -content_template: templates/task +content_type: task --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.10" state="beta" >}} A subset of the Kubelet's configuration parameters may be @@ -16,15 +16,16 @@ This functionality is considered beta in v1.10. Providing parameters via a config file is the recommended approach because it simplifies node deployment and configuration management. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + - A v1.10 or higher Kubelet binary must be installed for beta functionality. -{{% /capture %}} -{{% capture steps %}} + + ## Create the config file @@ -67,9 +68,9 @@ If `--config` is provided and the values are not specified via the command line, defaults for the `KubeletConfiguration` version apply. In the above example, this version is `kubelet.config.k8s.io/v1beta1`. -{{% /capture %}} -{{% capture discussion %}} + + ## Relationship to Dynamic Kubelet Config @@ -77,6 +78,6 @@ If you are using the [Dynamic Kubelet Configuration](/docs/tasks/administer-clus feature, the combination of configuration provided via `--config` and any flags which override these values is considered the default "last known good" configuration by the automatic rollback mechanism. -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/limit-storage-consumption.md b/content/en/docs/tasks/administer-cluster/limit-storage-consumption.md index 83ec069915..13dec384ea 100644 --- a/content/en/docs/tasks/administer-cluster/limit-storage-consumption.md +++ b/content/en/docs/tasks/administer-cluster/limit-storage-consumption.md @@ -1,9 +1,9 @@ --- title: Limit Storage Consumption -content_template: templates/task +content_type: task --- -{{% capture overview %}} + This example demonstrates an easy way to limit the amount of storage consumed in a namespace. @@ -11,15 +11,16 @@ The following resources are used in the demonstration: [ResourceQuota](/docs/con [LimitRange](/docs/tasks/administer-cluster/memory-default-namespace/), and [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/). -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Scenario: Limiting Storage Consumption The cluster-admin is operating a cluster on behalf of a user population and the admin wants to control @@ -77,9 +78,9 @@ spec: requests.storage: "5Gi" ``` -{{% /capture %}} -{{% capture discussion %}} + + ## Summary @@ -87,6 +88,6 @@ A limit range can put a ceiling on how much storage is requested while a resourc consumed by a namespace through claim counts and cumulative storage capacity. The allows a cluster-admin to plan their cluster's storage budget without risk of any one project going over their allotment. -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md index a1d4c786c6..d3d1541d27 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md @@ -1,11 +1,11 @@ --- title: Configure Minimum and Maximum CPU Constraints for a Namespace -content_template: templates/task +content_type: task weight: 40 --- -{{% capture overview %}} + This page shows how to set minimum and maximum values for the CPU resources used by Containers and Pods in a namespace. You specify minimum and maximum CPU values in a @@ -13,19 +13,20 @@ and Pods in a namespace. You specify minimum and maximum CPU values in a object. If a Pod does not meet the constraints imposed by the LimitRange, it cannot be created in the namespace. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} Your cluster must have at least 1 CPU available for use to run the task examples. -{{% /capture %}} -{{% capture steps %}} + + ## Create a namespace @@ -239,9 +240,10 @@ Delete your namespace: kubectl delete namespace constraints-cpu-example ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + ### For cluster administrators @@ -266,7 +268,7 @@ kubectl delete namespace constraints-cpu-example * [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/) -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md index 65a91a3538..d2e15c91da 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md @@ -1,10 +1,10 @@ --- title: Configure Default CPU Requests and Limits for a Namespace -content_template: templates/task +content_type: task weight: 20 --- -{{% capture overview %}} + This page shows how to configure default CPU requests and limits for a namespace. A Kubernetes cluster can be divided into namespaces. If a Container is created in a namespace @@ -12,14 +12,15 @@ that has a default CPU limit, and the Container does not specify its own CPU lim the Container is assigned the default CPU limit. Kubernetes assigns a default CPU request under certain conditions that are explained later in this topic. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Create a namespace @@ -163,9 +164,10 @@ Delete your namespace: kubectl delete namespace default-cpu-example ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + ### For cluster administrators @@ -189,6 +191,6 @@ kubectl delete namespace default-cpu-example * [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/) -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md index e6a6e1c2b0..a5ad383e78 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md @@ -1,11 +1,11 @@ --- title: Configure Minimum and Maximum Memory Constraints for a Namespace -content_template: templates/task +content_type: task weight: 30 --- -{{% capture overview %}} + This page shows how to set minimum and maximum values for memory used by Containers running in a namespace. You specify minimum and maximum memory values in a @@ -13,19 +13,20 @@ running in a namespace. You specify minimum and maximum memory values in a object. If a Pod does not meet the constraints imposed by the LimitRange, it cannot be created in the namespace. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} Each node in your cluster must have at least 1 GiB of memory. -{{% /capture %}} -{{% capture steps %}} + + ## Create a namespace @@ -239,9 +240,10 @@ Delete your namespace: kubectl delete namespace constraints-mem-example ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + ### For cluster administrators @@ -265,7 +267,7 @@ kubectl delete namespace constraints-mem-example * [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/) -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md index bb5070bc98..df7fce39f2 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md @@ -1,27 +1,28 @@ --- title: Configure Default Memory Requests and Limits for a Namespace -content_template: templates/task +content_type: task weight: 10 --- -{{% capture overview %}} + This page shows how to configure default memory requests and limits for a namespace. If a Container is created in a namespace that has a default memory limit, and the Container does not specify its own memory limit, then the Container is assigned the default memory limit. Kubernetes assigns a default memory request under certain conditions that are explained later in this topic. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} Each node in your cluster must have at least 2 GiB of memory. -{{% /capture %}} -{{% capture steps %}} + + ## Create a namespace @@ -170,9 +171,10 @@ Delete your namespace: kubectl delete namespace default-mem-example ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + ### For cluster administrators @@ -196,6 +198,6 @@ kubectl delete namespace default-mem-example * [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/) -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md index 9558766410..d69e3d29d6 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md @@ -1,30 +1,31 @@ --- title: Configure Memory and CPU Quotas for a Namespace -content_template: templates/task +content_type: task weight: 50 --- -{{% capture overview %}} + This page shows how to set quotas for the total amount memory and CPU that can be used by all Containers running in a namespace. You specify quotas in a [ResourceQuota](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core) object. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} Each node in your cluster must have at least 1 GiB of memory. -{{% /capture %}} -{{% capture steps %}} + + ## Create a namespace @@ -146,9 +147,10 @@ Delete your namespace: kubectl delete namespace quota-mem-cpu-example ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + ### For cluster administrators @@ -172,7 +174,7 @@ kubectl delete namespace quota-mem-cpu-example * [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/) -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md index 31cac82cf1..c44a07681f 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md @@ -1,28 +1,29 @@ --- title: Configure a Pod Quota for a Namespace -content_template: templates/task +content_type: task weight: 60 --- -{{% capture overview %}} + This page shows how to set a quota for the total number of Pods that can run in a namespace. You specify quotas in a [ResourceQuota](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core) object. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Create a namespace @@ -107,9 +108,10 @@ Delete your namespace: kubectl delete namespace quota-pod-example ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + ### For cluster administrators @@ -133,7 +135,7 @@ kubectl delete namespace quota-pod-example * [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/) -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md b/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md index 618b9bfaca..b4b7afd6de 100644 --- a/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md +++ b/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md @@ -3,10 +3,10 @@ reviewers: - derekwaynecarr - janetkuo title: Namespaces Walkthrough -content_template: templates/task +content_type: task --- -{{% capture overview %}} + Kubernetes {{< glossary_tooltip text="namespaces" term_id="namespace" >}} help different projects, teams, or customers to share a Kubernetes cluster. @@ -19,16 +19,17 @@ Use of multiple namespaces is optional. This example demonstrates how to use Kubernetes namespaces to subdivide your cluster. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Prerequisites @@ -242,7 +243,7 @@ snowflake 2/2 2 2 2m ``` ```shell -kubectl get pods -l run=snowflake +kubectl get pods -l app=snowflake ``` ``` NAME READY STATUS RESTARTS AGE @@ -278,7 +279,7 @@ cattle 5/5 5 5 10s ``` ```shell -kubectl get pods -l run=cattle +kubectl get pods -l app=cattle ``` ``` NAME READY STATUS RESTARTS AGE @@ -294,4 +295,4 @@ At this point, it should be clear that the resources users create in one namespa As the policy support in Kubernetes evolves, we will extend this scenario to show how you can provide different authorization rules for each namespace. -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/namespaces.md b/content/en/docs/tasks/administer-cluster/namespaces.md index 81ea6d7e37..a60bbb63a6 100644 --- a/content/en/docs/tasks/administer-cluster/namespaces.md +++ b/content/en/docs/tasks/administer-cluster/namespaces.md @@ -3,19 +3,20 @@ reviewers: - derekwaynecarr - janetkuo title: Share a Cluster with Namespaces -content_template: templates/task +content_type: task --- -{{% capture overview %}} + This page shows how to view, work in, and delete {{< glossary_tooltip text="namespaces" term_id="namespace" >}}. The page also shows how to use Kubernetes namespaces to subdivide your cluster. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * Have an [existing Kubernetes cluster](/docs/setup/). * Have a basic understanding of Kubernetes _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, and _[Deployments](/docs/concepts/workloads/controllers/deployment/)_. -{{% /capture %}} -{{% capture steps %}} + + ## Viewing namespaces @@ -201,7 +202,7 @@ This delete is asynchronous, so for a time you will see the namespace in the `Te snowflake 2/2 2 2 2m ``` ```shell - kubectl get pods -l run=snowflake -n=development + kubectl get pods -l app=snowflake -n=development ``` ``` NAME READY STATUS RESTARTS AGE @@ -223,7 +224,8 @@ This delete is asynchronous, so for a time you will see the namespace in the `Te Production likes to run cattle, so let's create some cattle pods. ```shell - kubectl run cattle --image=k8s.gcr.io/serve_hostname --replicas=5 -n=production + kubectl create deployment cattle --image=k8s.gcr.io/serve_hostname -n=production + kubectl scale deployment cattle --replicas=5 -n=production kubectl get deployment -n=production ``` @@ -233,7 +235,7 @@ This delete is asynchronous, so for a time you will see the namespace in the `Te ``` ```shell - kubectl get pods -l run=cattle -n=production + kubectl get pods -l app=cattle -n=production ``` ``` NAME READY STATUS RESTARTS AGE @@ -249,9 +251,9 @@ At this point, it should be clear that the resources users create in one namespa As the policy support in Kubernetes evolves, we will extend this scenario to show how you can provide different authorization rules for each namespace. -{{% /capture %}} -{{% capture discussion %}} + + ## Understanding the motivation for using namespaces @@ -301,12 +303,13 @@ is local to a namespace. This is useful for using the same configuration across multiple namespaces such as Development, Staging and Production. If you want to reach across namespaces, you need to use the fully qualified domain name (FQDN). -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [setting the namespace preference](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-preference). * Learn more about [setting the namespace for a request](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-for-a-request) * See [namespaces design](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/architecture/namespaces.md). -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md b/content/en/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md index 7046752a5f..9efdccfb6e 100644 --- a/content/en/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md +++ b/content/en/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md @@ -2,19 +2,20 @@ reviewers: - caseydavenport title: Use Calico for NetworkPolicy -content_template: templates/task +content_type: task weight: 10 --- -{{% capture overview %}} + This page shows a couple of quick ways to create a Calico cluster on Kubernetes. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + Decide whether you want to deploy a [cloud](#creating-a-calico-cluster-with-google-kubernetes-engine-gke) or [local](#creating-a-local-calico-cluster-with-kubeadm) cluster. -{{% /capture %}} -{{% capture steps %}} + + ## Creating a Calico cluster with Google Kubernetes Engine (GKE) **Prerequisite**: [gcloud](https://cloud.google.com/sdk/docs/quickstarts). @@ -44,10 +45,11 @@ Decide whether you want to deploy a [cloud](#creating-a-calico-cluster-with-goog To get a local single-host Calico cluster in fifteen minutes using kubeadm, refer to the [Calico Quickstart](https://docs.projectcalico.org/latest/getting-started/kubernetes/). -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + Once your cluster is running, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy. -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md b/content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md index cca685d395..83989b1f58 100644 --- a/content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md +++ b/content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md @@ -3,23 +3,24 @@ reviewers: - danwent - aanm title: Use Cilium for NetworkPolicy -content_template: templates/task +content_type: task weight: 20 --- -{{% capture overview %}} + This page shows how to use Cilium for NetworkPolicy. For background on Cilium, read the [Introduction to Cilium](https://docs.cilium.io/en/stable/intro). -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Deploying Cilium on Minikube for Basic Testing To get familiar with Cilium easily you can follow the @@ -50,7 +51,7 @@ For minikube you can deploy this simple ''all-in-one'' YAML file that includes DaemonSet configurations for Cilium as well as appropriate RBAC settings: ```shell -kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.6/install/kubernetes/quick-install.yaml +kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml ``` ``` configmap/cilium-config created @@ -75,9 +76,9 @@ For detailed instructions around deploying Cilium for production, see: This documentation includes detailed requirements, instructions and example production DaemonSet files. -{{% /capture %}} -{{% capture discussion %}} + + ## Understanding Cilium components Deploying a cluster with Cilium adds Pods to the `kube-system` namespace. To see @@ -98,14 +99,15 @@ cilium-6rxbd 1/1 Running 0 1m A `cilium` Pod runs on each node in your cluster and enforces network policy on the traffic to/from Pods on that node using Linux BPF. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + Once your cluster is running, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy with Cilium. Have fun, and if you have questions, contact us using the [Cilium Slack Channel](https://cilium.herokuapp.com/). -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md b/content/en/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md index 0111f6c21f..673118e312 100644 --- a/content/en/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md +++ b/content/en/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md @@ -2,25 +2,27 @@ reviewers: - murali-reddy title: Use Kube-router for NetworkPolicy -content_template: templates/task +content_type: task weight: 30 --- -{{% capture overview %}} + This page shows how to use [Kube-router](https://github.com/cloudnativelabs/kube-router) for NetworkPolicy. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + You need to have a Kubernetes cluster running. If you do not already have a cluster, you can create one by using any of the cluster installers like Kops, Bootkube, Kubeadm etc. -{{% /capture %}} -{{% capture steps %}} + + ## Installing Kube-router addon The Kube-router Addon comes with a Network Policy Controller that watches Kubernetes API server for any NetworkPolicy and pods updated and configures iptables rules and ipsets to allow or block traffic as directed by the policies. Please follow the [trying Kube-router with cluster installers](https://www.kube-router.io/docs/user-guide/#try-kube-router-with-cluster-installers) guide to install Kube-router addon. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + Once you have installed the Kube-router addon, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy. -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md b/content/en/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md index 42577dae85..df6adcd39f 100644 --- a/content/en/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md +++ b/content/en/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md @@ -2,23 +2,24 @@ reviewers: - chrismarino title: Romana for NetworkPolicy -content_template: templates/task +content_type: task weight: 40 --- -{{% capture overview %}} + This page shows how to use Romana for NetworkPolicy. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + Complete steps 1, 2, and 3 of the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/). -{{% /capture %}} -{{% capture steps %}} + + ## Installing Romana with kubeadm @@ -32,12 +33,13 @@ To apply network policies use one of the following: * [Example of Romana network policy](https://github.com/romana/core/blob/master/doc/policy.md). * The NetworkPolicy API. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + Once you have installed Romana, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy. -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md b/content/en/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md index 0fcb4ea107..a9d15f40a6 100644 --- a/content/en/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md +++ b/content/en/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md @@ -2,23 +2,24 @@ reviewers: - bboreham title: Weave Net for NetworkPolicy -content_template: templates/task +content_type: task weight: 50 --- -{{% capture overview %}} + This page shows how to use Weave Net for NetworkPolicy. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + You need to have a Kubernetes cluster. Follow the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/) to bootstrap one. -{{% /capture %}} -{{% capture steps %}} + + ## Install the Weave Net addon @@ -48,12 +49,13 @@ weave-net-pmw8w 2/2 Running 0 9d Each Node has a weave Pod, and all Pods are `Running` and `2/2 READY`. (`2/2` means that each Pod has `weave` and `weave-npc`.) -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + Once you have installed the Weave Net addon, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy. If you have any question, contact us at [#weave-community on Slack or Weave User Group](https://github.com/weaveworks/weave#getting-help). -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/nodelocaldns.md b/content/en/docs/tasks/administer-cluster/nodelocaldns.md index cb033f2925..8aa6b9249b 100644 --- a/content/en/docs/tasks/administer-cluster/nodelocaldns.md +++ b/content/en/docs/tasks/administer-cluster/nodelocaldns.md @@ -4,21 +4,22 @@ reviewers: - zihongz - sftim title: Using NodeLocal DNSCache in Kubernetes clusters -content_template: templates/task +content_type: task --- - -{{% capture overview %}} + + {{< feature-state for_k8s_version="v1.18" state="stable" >}} This page provides an overview of NodeLocal DNSCache feature in Kubernetes. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} - {{% capture steps %}} + + ## Introduction @@ -88,4 +89,4 @@ This feature can be enabled using the following steps: Once enabled, node-local-dns Pods will run in the kube-system namespace on each of the cluster nodes. This Pod runs [CoreDNS](https://github.com/coredns/coredns) in cache mode, so all CoreDNS metrics exposed by the different plugins will be available on a per-node basis. You can disable this feature by removing the DaemonSet, using `kubectl delete -f ` . You should also revert any changes you made to the kubelet configuration. - {{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/out-of-resource.md b/content/en/docs/tasks/administer-cluster/out-of-resource.md index c52415f4c6..a9d2ee3702 100644 --- a/content/en/docs/tasks/administer-cluster/out-of-resource.md +++ b/content/en/docs/tasks/administer-cluster/out-of-resource.md @@ -4,10 +4,10 @@ reviewers: - vishh - timstclair title: Configure Out of Resource Handling -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + This page explains how to configure out of resource handling with `kubelet`. @@ -16,10 +16,10 @@ are low. This is especially important when dealing with incompressible compute resources, such as memory or disk space. If such resources are exhausted, nodes become unstable. -{{% /capture %}} -{{% capture body %}} + + ## Eviction Policy @@ -372,4 +372,4 @@ to prevent system OOMs, and promote eviction of workloads so cluster state can r The Pod eviction may evict more Pods than needed due to stats collection timing gap. This can be mitigated by adding the ability to get root container stats on an on-demand basis [(https://github.com/google/cadvisor/issues/1247)](https://github.com/google/cadvisor/issues/1247) in the future. -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/quota-api-object.md b/content/en/docs/tasks/administer-cluster/quota-api-object.md index faf7210384..1fb48c7a2b 100644 --- a/content/en/docs/tasks/administer-cluster/quota-api-object.md +++ b/content/en/docs/tasks/administer-cluster/quota-api-object.md @@ -1,10 +1,10 @@ --- title: Configure Quotas for API Objects -content_template: templates/task +content_type: task --- -{{% capture overview %}} + This page shows how to configure quotas for API objects, including PersistentVolumeClaims and Services. A quota restricts the number of @@ -13,17 +13,18 @@ You specify quotas in a [ResourceQuota](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core) object. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Create a namespace @@ -140,9 +141,10 @@ Delete your namespace: kubectl delete namespace quota-object-example ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + ### For cluster administrators @@ -167,7 +169,7 @@ kubectl delete namespace quota-object-example * [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/) -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md b/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md index af5696d622..6218e8ce81 100644 --- a/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md +++ b/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md @@ -3,11 +3,11 @@ reviewers: - mtaufen - dawnchen title: Reconfigure a Node's Kubelet in a Live Cluster -content_template: templates/task +content_type: task min-kubernetes-server-version: v1.11 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.11" state="beta" >}} [Dynamic Kubelet Configuration](https://github.com/kubernetes/enhancements/issues/281) @@ -25,9 +25,10 @@ of nodes before rolling them out cluster-wide. Advice on configuring specific fields is available in the inline `KubeletConfiguration` [type documentation](https://github.com/kubernetes/kubernetes/blob/release-1.11/pkg/kubelet/apis/kubeletconfig/v1beta1/types.go). {{< /warning >}} -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + You need to have a Kubernetes cluster. You also need kubectl v1.11 or higher, configured to communicate with your cluster. {{< version-check >}} @@ -43,9 +44,9 @@ because there are manual alternatives. For each node that you're reconfiguring, you must set the kubelet `--dynamic-config-dir` flag to a writable directory. -{{% /capture %}} -{{% capture steps %}} + + ## Reconfiguring the kubelet on a running node in your cluster @@ -71,7 +72,7 @@ will receive default values appropriate to the configuration version (e.g. `kubelet.config.k8s.io/v1beta1`), unless overridden by flags. The status of the Node's kubelet configuration is reported via -`Node.Spec.Status.Config`. Once you have updated a Node to use the new +`Node.Status.Config`. Once you have updated a Node to use the new ConfigMap, you can observe this status to confirm that the Node is using the intended configuration. @@ -311,9 +312,9 @@ empty, since all config sources have been reset to `nil`, which indicates that the local default config is `assigned`, `active`, and `lastKnownGood`, and no error is reported. -{{% /capture %}} -{{% capture discussion %}} + + ## `kubectl patch` example You can change a Node's configSource using several different mechanisms. @@ -374,9 +375,9 @@ internal failure, see Kubelet log for details | The kubelet encountered some int {{< /table >}} -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + - For more information on configuring the kubelet via a configuration file, see [Set kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file). - See the reference documentation for [`NodeConfigSource`](https://kubernetes.io/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodeconfigsource-v1-core) -{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md b/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md index c78c9edb42..4f00675c37 100644 --- a/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md +++ b/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md @@ -4,11 +4,11 @@ reviewers: - derekwaynecarr - dashpole title: Reserve Compute Resources for System Daemons -content_template: templates/task +content_type: task min-kubernetes-server-version: 1.8 --- -{{% capture overview %}} + Kubernetes nodes can be scheduled to `Capacity`. Pods can consume all the available capacity on a node by default. This is an issue because nodes @@ -22,19 +22,20 @@ compute resources for system daemons. Kubernetes recommends cluster administrators to configure `Node Allocatable` based on their workload density on each node. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} Your Kubernetes server must be at or later than version 1.17 to use the kubelet command line option `--reserved-cpus` to set an [explicitly reserved CPU list](#explicitly-reserved-cpu-list). -{{% /capture %}} -{{% capture steps %}} + + ## Node Allocatable @@ -226,9 +227,9 @@ more features are added. Over time, kubernetes project will attempt to bring down utilization of node system daemons, but that is not a priority as of now. So expect a drop in `Allocatable` capacity in future releases. -{{% /capture %}} -{{% capture discussion %}} + + ## Example Scenario @@ -251,4 +252,3 @@ If `kube-reserved` and/or `system-reserved` is not enforced and system daemons exceed their reservation, `kubelet` evicts pods whenever the overall node memory usage is higher than `31.5Gi` or `storage` is greater than `90Gi` -{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/tasks/administer-cluster/running-cloud-controller.md b/content/en/docs/tasks/administer-cluster/running-cloud-controller.md index 71cc28ff40..aa01c902e4 100644 --- a/content/en/docs/tasks/administer-cluster/running-cloud-controller.md +++ b/content/en/docs/tasks/administer-cluster/running-cloud-controller.md @@ -4,10 +4,10 @@ reviewers: - thockin - wlan0 title: Cloud Controller Manager Administration -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + {{< feature-state state="beta" for_k8s_version="v1.11" >}} @@ -15,10 +15,10 @@ Since cloud providers develop and release at a different pace compared to the Ku The `cloud-controller-manager` can be linked to any cloud provider that satisfies [cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go). For backwards compatibility, the [cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager) provided in the core Kubernetes project uses the same cloud libraries as `kube-controller-manager`. Cloud providers already supported in Kubernetes core are expected to use the in-tree cloud-controller-manager to transition out of Kubernetes core. -{{% /capture %}} -{{% capture body %}} + + ## Administration @@ -82,9 +82,10 @@ A good example of this is the TLS bootstrapping feature in the Kubelet. TLS boot As this initiative evolves, changes will be made to address these issues in upcoming releases. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + To build and develop your own cloud controller manager, read [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/). -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/safely-drain-node.md b/content/en/docs/tasks/administer-cluster/safely-drain-node.md index 29006ff754..e18b2ed87d 100644 --- a/content/en/docs/tasks/administer-cluster/safely-drain-node.md +++ b/content/en/docs/tasks/administer-cluster/safely-drain-node.md @@ -5,14 +5,15 @@ reviewers: - foxish - kow3ns title: Safely Drain a Node while Respecting the PodDisruptionBudget -content_template: templates/task +content_type: task --- -{{% capture overview %}} + This page shows how to safely drain a node, respecting the PodDisruptionBudget you have defined. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + This task assumes that you have met the following prerequisites: @@ -24,9 +25,9 @@ This task assumes that you have met the following prerequisites: and [Configured PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/) for applications that need them. -{{% /capture %}} -{{% capture steps %}} + + ## Use `kubectl drain` to remove a node from service @@ -151,13 +152,14 @@ In this case, there are two potential solutions: Kubernetes does not specify what the behavior should be in this case; it is up to the application owners and cluster owners to establish an agreement on behavior in these cases. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Follow steps to protect your application by [configuring a Pod Disruption Budget](/docs/tasks/run-application/configure-pdb/). * Learn more about [maintenance on a node](/docs/tasks/administer-cluster/cluster-management/#maintenance-on-a-node). -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md b/content/en/docs/tasks/administer-cluster/securing-a-cluster.md index d2d58ae702..7e558fb48f 100644 --- a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md +++ b/content/en/docs/tasks/administer-cluster/securing-a-cluster.md @@ -5,23 +5,24 @@ reviewers: - ericchiang - destijl title: Securing a Cluster -content_template: templates/task +content_type: task --- -{{% capture overview %}} + This document covers topics related to protecting a cluster from accidental or malicious access and provides recommendations on overall security. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Controlling access to the Kubernetes API @@ -254,6 +255,6 @@ Join the [kubernetes-announce](https://groups.google.com/forum/#!forum/kubernete group for emails about security announcements. See the [security reporting](/security/) page for more on how to report vulnerabilities. -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/sysctl-cluster.md b/content/en/docs/tasks/administer-cluster/sysctl-cluster.md index f96c066dd5..d6aea240c1 100644 --- a/content/en/docs/tasks/administer-cluster/sysctl-cluster.md +++ b/content/en/docs/tasks/administer-cluster/sysctl-cluster.md @@ -2,25 +2,26 @@ title: Using sysctls in a Kubernetes Cluster reviewers: - sttts -content_template: templates/task +content_type: task --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.12" state="beta" >}} This document describes how to configure and use kernel parameters within a Kubernetes cluster using the {{< glossary_tooltip term_id="sysctl" >}} interface. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Listing all Sysctl Parameters @@ -140,9 +141,9 @@ spec: value: "65536" ... ``` -{{% /capture %}} -{{% capture discussion %}} + + {{< warning >}} Due to their nature of being _unsafe_, the use of _unsafe_ sysctls @@ -188,9 +189,9 @@ Do not configure these two fields such that there is overlap, meaning that a given sysctl is both allowed and forbidden. {{< warning >}} -If you whitelist unsafe sysctls via the `allowedUnsafeSysctls` field +If you allow unsafe sysctls via the `allowedUnsafeSysctls` field in a PodSecurityPolicy, any pod using such a sysctl will fail to start -if the sysctl is not whitelisted via the `--allowed-unsafe-sysctls` kubelet +if the sysctl is not allowed via the `--allowed-unsafe-sysctls` kubelet flag as well on that node. {{< /warning >}} @@ -210,4 +211,4 @@ spec: ... ``` -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/topology-manager.md b/content/en/docs/tasks/administer-cluster/topology-manager.md index 156146e1c2..8455bb0d8d 100644 --- a/content/en/docs/tasks/administer-cluster/topology-manager.md +++ b/content/en/docs/tasks/administer-cluster/topology-manager.md @@ -8,11 +8,11 @@ reviewers: - nolancon - bg-chun -content_template: templates/task +content_type: task min-kubernetes-server-version: v1.18 --- -{{% capture overview %}} + {{< feature-state state="beta" for_k8s_version="v1.18" >}} @@ -22,15 +22,16 @@ In order to extract the best performance, optimizations related to CPU isolation _Topology Manager_ is a Kubelet component that aims to co-ordinate the set of components that are responsible for these optimizations. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## How Topology Manager Works @@ -216,4 +217,4 @@ Using this information the Topology Manager calculates the optimal hint for the 3. The Device Manager and the CPU Manager are the only components to adopt the Topology Manager's HintProvider interface. This means that NUMA alignment can only be achieved for resources managed by the CPU Manager and the Device Manager. Memory or Hugepages are not considered by the Topology Manager for NUMA alignment. -{{% /capture %}} + diff --git a/content/en/docs/tasks/configure-pod-container/_index.md b/content/en/docs/tasks/configure-pod-container/_index.md index ea8d5a89d5..462b19e4e9 100755 --- a/content/en/docs/tasks/configure-pod-container/_index.md +++ b/content/en/docs/tasks/configure-pod-container/_index.md @@ -1,5 +1,6 @@ --- title: "Configure Pods and Containers" +description: Perform common configuration tasks for Pods and containers. weight: 20 --- diff --git a/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md index 181b92b8e1..5e79704cc4 100644 --- a/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md +++ b/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md @@ -1,20 +1,21 @@ --- title: Assign CPU Resources to Containers and Pods -content_template: templates/task +content_type: task weight: 20 --- -{{% capture overview %}} + This page shows how to assign a CPU *request* and a CPU *limit* to a container. Containers cannot use more CPU than the configured limit. Provided the system has CPU time free, a container is guaranteed to be allocated as much CPU as it requests. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} @@ -48,10 +49,10 @@ NAME v1beta1.metrics.k8s.io ``` -{{% /capture %}} -{{% capture steps %}} + + ## Create a namespace @@ -239,9 +240,10 @@ Delete your namespace: kubectl delete namespace cpu-example ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + ### For app developers @@ -266,4 +268,4 @@ kubectl delete namespace cpu-example * [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/) -{{% /capture %}} + diff --git a/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md index e8f7d8073a..394f435d12 100644 --- a/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md +++ b/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md @@ -1,19 +1,20 @@ --- title: Assign Memory Resources to Containers and Pods -content_template: templates/task +content_type: task weight: 10 --- -{{% capture overview %}} + This page shows how to assign a memory *request* and a memory *limit* to a Container. A Container is guaranteed to have as much memory as it requests, but is not allowed to use more memory than its limit. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} @@ -46,9 +47,9 @@ NAME v1beta1.metrics.k8s.io ``` -{{% /capture %}} -{{% capture steps %}} + + ## Create a namespace @@ -330,9 +331,10 @@ Delete your namespace. This deletes all the Pods that you created for this task: kubectl delete namespace mem-example ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + ### For app developers @@ -356,7 +358,7 @@ kubectl delete namespace mem-example * [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/) -{{% /capture %}} + diff --git a/content/en/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md b/content/en/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md index 16773cd215..8306724c1d 100644 --- a/content/en/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md +++ b/content/en/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md @@ -1,22 +1,23 @@ --- title: Assign Pods to Nodes using Node Affinity min-kubernetes-server-version: v1.10 -content_template: templates/task +content_type: task weight: 120 --- -{{% capture overview %}} + This page shows how to assign a Kubernetes Pod to a particular node using Node Affinity in a Kubernetes cluster. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Add a label to a node @@ -112,9 +113,10 @@ This means that the pod will prefer a node that has a `disktype=ssd` label. nginx 1/1 Running 0 13s 10.200.0.4 worker0 ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + Learn more about [Node Affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity). -{{% /capture %}} + diff --git a/content/en/docs/tasks/configure-pod-container/assign-pods-nodes.md b/content/en/docs/tasks/configure-pod-container/assign-pods-nodes.md index b5f6876e6b..f1e6e6e9ef 100644 --- a/content/en/docs/tasks/configure-pod-container/assign-pods-nodes.md +++ b/content/en/docs/tasks/configure-pod-container/assign-pods-nodes.md @@ -1,21 +1,22 @@ --- title: Assign Pods to Nodes -content_template: templates/task +content_type: task weight: 120 --- -{{% capture overview %}} + This page shows how to assign a Kubernetes Pod to a particular node in a Kubernetes cluster. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Add a label to a node @@ -94,10 +95,11 @@ You can also schedule a pod to one specific node via setting `nodeName`. Use the configuration file to create a pod that will get scheduled on `foo-node` only. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [labels and selectors](/docs/concepts/overview/working-with-objects/labels/). * Learn more about [nodes](/docs/concepts/architecture/nodes/). -{{% /capture %}} + diff --git a/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md b/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md index 57b5fad6c6..f5116e7691 100644 --- a/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md +++ b/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md @@ -1,27 +1,28 @@ --- title: Attach Handlers to Container Lifecycle Events -content_template: templates/task +content_type: task weight: 140 --- -{{% capture overview %}} + This page shows how to attach handlers to Container lifecycle events. Kubernetes supports the postStart and preStop events. Kubernetes sends the postStart event immediately after a Container is started, and it sends the preStop event immediately before the Container is terminated. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Define postStart and preStop handlers @@ -56,11 +57,11 @@ The output shows the text written by the postStart handler: Hello from the postStart handler -{{% /capture %}} -{{% capture discussion %}} + + ## Discussion @@ -82,10 +83,11 @@ This means that the preStop hook is not invoked when the Pod is *completed*. This limitation is tracked in [issue #55087](https://github.com/kubernetes/kubernetes/issues/55807). {{< /note >}} -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/). * Learn more about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/). @@ -97,6 +99,6 @@ This limitation is tracked in [issue #55087](https://github.com/kubernetes/kuber * [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) * See `terminationGracePeriodSeconds` in [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) -{{% /capture %}} + diff --git a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md index 8045ae9a02..a2b3f24628 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md +++ b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md @@ -1,10 +1,10 @@ --- title: Configure GMSA for Windows Pods and containers -content_template: templates/task +content_type: task weight: 20 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.18" state="stable" >}} @@ -12,14 +12,15 @@ This page shows how to configure [Group Managed Service Accounts](https://docs.m In Kubernetes, GMSA credential specs are configured at a Kubernetes cluster-wide scope as Custom Resources. Windows Pods, as well as individual containers within a Pod, can be configured to use a GMSA for domain based functions (e.g. Kerberos authentication) when interacting with other Windows services. As of v1.16, the Docker runtime supports GMSA for Windows workloads. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + You need to have a Kubernetes cluster and the `kubectl` command-line tool must be configured to communicate with your cluster. The cluster is expected to have Windows worker nodes. This section covers a set of initial steps required once for each cluster: ### Install the GMSACredentialSpec CRD -A [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)(CRD) for GMSA credential spec resources needs to be configured on the cluster to define the custom resource type `GMSACredentialSpec`. Download the GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml) and save it as gmsa-crd.yaml. +A [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)(CRD) for GMSA credential spec resources needs to be configured on the cluster to define the custom resource type `GMSACredentialSpec`. Download the GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml) and save it as gmsa-crd.yaml. Next, install the CRD with `kubectl apply -f gmsa-crd.yaml` ### Install webhooks to validate GMSA users @@ -43,9 +44,9 @@ A [script](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission The [YAML template](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-webhook.yml.tpl) used by the script may also be used to deploy the webhooks and associated objects manually (with appropriate substitutions for the parameters) -{{% /capture %}} -{{% capture steps %}} + + ## Configure GMSAs and Windows nodes in Active Directory Before Pods in Kubernetes can be configured to use GMSAs, the desired GMSAs need to be provisioned in Active Directory as described in the [Windows GMSA documentation](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1). Windows worker nodes (that are part of the Kubernetes cluster) need to be configured in Active Directory to access the secret credentials associated with the desired GMSA as described in the [Windows GMSA documentation](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#to-add-member-hosts-using-the-set-adserviceaccount-cmdlet) @@ -252,4 +253,4 @@ If the above command corrects the error, you can automate the step by adding the If you add the `lifecycle` section show above to your Pod spec, the Pod will execute the commands listed to restart the `netlogon` service until the `nltest.exe /query` command exits without error. -{{% /capture %}} + diff --git a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 19b077ab35..ed5aa24044 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -1,10 +1,10 @@ --- title: Configure Liveness, Readiness and Startup Probes -content_template: templates/task +content_type: task weight: 110 --- -{{% capture overview %}} + This page shows how to configure liveness, readiness and startup probes for containers. @@ -25,15 +25,16 @@ it succeeds, making sure those probes don't interfere with the application start This can be used to adopt liveness checks on slow starting containers, avoiding them getting killed by the kubelet before they are up and running. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Define a liveness command @@ -360,9 +361,10 @@ For a TCP probe, the kubelet makes the probe connection at the node, not in the means that you can not use a service name in the `host` parameter since the kubelet is unable to resolve it. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes). @@ -373,6 +375,6 @@ You can also read the API references for: * [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) * [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) -{{% /capture %}} + diff --git a/content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md b/content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md index 024e6929c7..6ff6c21530 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md +++ b/content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md @@ -1,10 +1,10 @@ --- title: Configure a Pod to Use a PersistentVolume for Storage -content_template: templates/task +content_type: task weight: 60 --- -{{% capture overview %}} + This page shows you how to configure a Pod to use a {{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}} @@ -20,9 +20,10 @@ PersistentVolume. 1. You create a Pod that uses the above PersistentVolumeClaim for storage. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * You need to have a Kubernetes cluster that has only one Node, and the {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} @@ -33,9 +34,9 @@ do not already have a single-node cluster, you can create one by using * Familiarize yourself with the material in [Persistent Volumes](/docs/concepts/storage/persistent-volumes/). -{{% /capture %}} -{{% capture steps %}} + + ## Create an index.html file on your Node @@ -237,10 +238,10 @@ sudo rmdir /mnt/data You can now close the shell to your Node. -{{% /capture %}} -{{% capture discussion %}} + + ## Access control @@ -270,10 +271,11 @@ When a Pod consumes a PersistentVolume, the GIDs associated with the PersistentVolume are not present on the Pod resource itself. {{< /note >}} -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/). * Read the [Persistent Storage design document](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md). @@ -285,6 +287,6 @@ PersistentVolume are not present on the Pod resource itself. * [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core) * [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core) -{{% /capture %}} + diff --git a/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md index c7f80b0fad..42eff59db0 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -1,24 +1,25 @@ --- title: Configure a Pod to Use a ConfigMap -content_template: templates/task +content_type: task weight: 150 card: name: tasks weight: 50 --- -{{% capture overview %}} + ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable. This page provides a series of usage examples demonstrating how to create ConfigMaps and configure Pods using data stored in ConfigMaps. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Create a ConfigMap @@ -628,9 +629,9 @@ When a ConfigMap already being consumed in a volume is updated, projected keys a A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes/#using-subpath) volume will not receive ConfigMap updates. {{< /note >}} -{{% /capture %}} -{{% capture discussion %}} + + ## Understanding ConfigMaps and Pods @@ -680,9 +681,10 @@ data: - You can't use ConfigMaps for {{< glossary_tooltip text="static pods" term_id="static-pod" >}}, because the Kubelet does not support this. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Follow a real world example of [Configuring Redis using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/). -{{% /capture %}} + diff --git a/content/en/docs/tasks/configure-pod-container/configure-pod-initialization.md b/content/en/docs/tasks/configure-pod-container/configure-pod-initialization.md index a418a8d7c0..9a8a33f655 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-pod-initialization.md +++ b/content/en/docs/tasks/configure-pod-container/configure-pod-initialization.md @@ -1,22 +1,23 @@ --- title: Configure Pod Initialization -content_template: templates/task +content_type: task weight: 130 --- -{{% capture overview %}} + This page shows how to use an Init Container to initialize a Pod before an application Container runs. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Create a Pod that has an Init Container @@ -78,9 +79,10 @@ The output shows that nginx is serving the web page that was written by the init

Kubernetes is open source giving you the freedom to take advantage ...

... -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [communicating between Containers running in the same Pod](/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/). @@ -88,6 +90,6 @@ The output shows that nginx is serving the web page that was written by the init * Learn more about [Volumes](/docs/concepts/storage/volumes/). * Learn more about [Debugging Init Containers](/docs/tasks/debug-application-cluster/debug-init-containers/) -{{% /capture %}} + diff --git a/content/en/docs/tasks/configure-pod-container/configure-projected-volume-storage.md b/content/en/docs/tasks/configure-pod-container/configure-projected-volume-storage.md index ec6f2d9528..ad99a05c27 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-projected-volume-storage.md +++ b/content/en/docs/tasks/configure-pod-container/configure-projected-volume-storage.md @@ -3,11 +3,11 @@ reviewers: - jpeeler - pmorie title: Configure a Pod to Use a Projected Volume for Storage -content_template: templates/task +content_type: task weight: 70 --- -{{% capture overview %}} + This page shows how to use a [`projected`](/docs/concepts/storage/volumes/#projected) Volume to mount several existing volume sources into the same directory. Currently, `secret`, `configMap`, `downwardAPI`, and `serviceAccountToken` volumes can be projected. @@ -15,13 +15,14 @@ and `serviceAccountToken` volumes can be projected. {{< note >}} `serviceAccountToken` is not a volume type. {{< /note >}} -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Configure a projected volume for a pod In this exercise, you create username and password {{< glossary_tooltip text="Secrets" term_id="secret" >}} from local files. You then create a Pod that runs one container, using a [`projected`](/docs/concepts/storage/volumes/#projected) Volume to mount the Secrets into the same shared directory. @@ -77,9 +78,10 @@ kubectl delete pod test-projected-volume kubectl delete secret user pass ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [`projected`](/docs/concepts/storage/volumes/#projected) volumes. * Read the [all-in-one volume](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md) design document. -{{% /capture %}} + diff --git a/content/en/docs/tasks/configure-pod-container/configure-runasusername.md b/content/en/docs/tasks/configure-pod-container/configure-runasusername.md index ac912327f3..12c10a9ddf 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-runasusername.md +++ b/content/en/docs/tasks/configure-pod-container/configure-runasusername.md @@ -1,24 +1,25 @@ --- title: Configure RunAsUserName for Windows pods and containers -content_template: templates/task +content_type: task weight: 20 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.18" state="stable" >}} This page shows how to use the `runAsUserName` setting for Pods and containers that will run on Windows nodes. This is roughly equivalent of the Linux-specific `runAsUser` setting, allowing you to run applications in a container as a different username than the default. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + You need to have a Kubernetes cluster and the kubectl command-line tool must be configured to communicate with your cluster. The cluster is expected to have Windows worker nodes where pods with containers running Windows workloads will get scheduled. -{{% /capture %}} -{{% capture steps %}} + + ## Set the Username for a Pod @@ -114,12 +115,12 @@ Examples of acceptable values for the `runAsUserName` field: `ContainerAdministr For more information about these limtations, check [here](https://support.microsoft.com/en-us/help/909264/naming-conventions-in-active-directory-for-computers-domains-sites-and) and [here](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.localaccounts/new-localuser?view=powershell-5.1). -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [Guide for scheduling Windows containers in Kubernetes](/docs/setup/production-environment/windows/user-guide-windows-containers/) * [Managing Workload Identity with Group Managed Service Accounts (GMSA)](/docs/setup/production-environment/windows/user-guide-windows-containers/#managing-workload-identity-with-group-managed-service-accounts) * [Configure GMSA for Windows pods and containers](/docs/tasks/configure-pod-container/configure-gmsa/) -{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/tasks/configure-pod-container/configure-service-account.md b/content/en/docs/tasks/configure-pod-container/configure-service-account.md index 021a8feb22..eaaabb9e94 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/en/docs/tasks/configure-pod-container/configure-service-account.md @@ -4,11 +4,11 @@ reviewers: - liggitt - thockin title: Configure Service Accounts for Pods -content_template: templates/task +content_type: task weight: 90 --- -{{% capture overview %}} + A service account provides an identity for processes that run in a Pod. {{< note >}} @@ -23,16 +23,17 @@ authenticated by the apiserver as a particular User Account (currently this is usually `admin`, unless your cluster administrator has customized your cluster). Processes in containers inside pods can also contact the apiserver. When they do, they are authenticated as a particular Service Account (for example, `default`). -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Use the Default Service Account to access the API server. @@ -370,9 +371,10 @@ override the `jwks_uri` in the OpenID Provider Configuration so that it points to the public endpoint, rather than the API server's address, by passing the `--service-account-jwks-uri` flag to the API server. Like the issuer URL, the JWKS URI is required to use the `https` scheme. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + See also: @@ -380,4 +382,4 @@ See also: - [Service Account Signing Key Retrieval KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/20190730-oidc-discovery.md) - [OIDC Discovery Spec](https://openid.net/specs/openid-connect-discovery-1_0.html) -{{% /capture %}} + diff --git a/content/en/docs/tasks/configure-pod-container/configure-volume-storage.md b/content/en/docs/tasks/configure-pod-container/configure-volume-storage.md index bec97a2975..69e665b42e 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-volume-storage.md +++ b/content/en/docs/tasks/configure-pod-container/configure-volume-storage.md @@ -1,10 +1,10 @@ --- title: Configure a Pod to Use a Volume for Storage -content_template: templates/task +content_type: task weight: 50 --- -{{% capture overview %}} + This page shows how to configure a Pod to use a Volume for storage. @@ -14,15 +14,16 @@ consistent storage that is independent of the Container, you can use a [Volume](/docs/concepts/storage/volumes/). This is especially important for stateful applications, such as key-value stores (such as Redis) and databases. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Configure a volume for a Pod @@ -126,9 +127,10 @@ of `Always`. kubectl delete pod redis ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * See [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core). @@ -140,6 +142,6 @@ GCE and EBS on EC2, which are preferred for critical data and will handle details such as mounting and unmounting the devices on the nodes. See [Volumes](/docs/concepts/storage/volumes/) for more details. -{{% /capture %}} + diff --git a/content/en/docs/tasks/configure-pod-container/extended-resource.md b/content/en/docs/tasks/configure-pod-container/extended-resource.md index 36d957ca01..25fa11b0d9 100644 --- a/content/en/docs/tasks/configure-pod-container/extended-resource.md +++ b/content/en/docs/tasks/configure-pod-container/extended-resource.md @@ -1,19 +1,20 @@ --- title: Assign Extended Resources to a Container -content_template: templates/task +content_type: task weight: 40 --- -{{% capture overview %}} + {{< feature-state state="stable" >}} This page shows how to assign extended resources to a Container. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} @@ -21,10 +22,10 @@ Before you do this exercise, do the exercise in [Advertise Extended Resources for a Node](/docs/tasks/administer-cluster/extended-resource-node/). That will configure one of your Nodes to advertise a dongle resource. -{{% /capture %}} -{{% capture steps %}} + + ## Assign an extended resource to a Pod @@ -127,9 +128,10 @@ kubectl delete pod extended-resource-demo kubectl delete pod extended-resource-demo-2 ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + ### For application developers @@ -140,4 +142,4 @@ kubectl delete pod extended-resource-demo-2 * [Advertise Extended Resources for a Node](/docs/tasks/administer-cluster/extended-resource-node/) -{{% /capture %}} + diff --git a/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md index 9184883003..ce0b5b3656 100644 --- a/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md +++ b/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -1,26 +1,27 @@ --- title: Pull an Image from a Private Registry -content_template: templates/task +content_type: task weight: 100 --- -{{% capture overview %}} + This page shows how to create a Pod that uses a Secret to pull an image from a private Docker registry or repository. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * To do this exercise, you need a [Docker ID](https://docs.docker.com/docker-id/) and password. -{{% /capture %}} -{{% capture steps %}} + + ## Log in to Docker @@ -200,9 +201,10 @@ kubectl apply -f my-private-reg-pod.yaml kubectl get pod private-reg ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [Secrets](/docs/concepts/configuration/secret/). * Learn more about [using a private registry](/docs/concepts/containers/images/#using-a-private-registry). @@ -211,5 +213,5 @@ kubectl get pod private-reg * See [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core). * See the `imagePullSecrets` field of [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core). -{{% /capture %}} + diff --git a/content/en/docs/tasks/configure-pod-container/quality-service-pod.md b/content/en/docs/tasks/configure-pod-container/quality-service-pod.md index cd9edd0410..dec9e8db91 100644 --- a/content/en/docs/tasks/configure-pod-container/quality-service-pod.md +++ b/content/en/docs/tasks/configure-pod-container/quality-service-pod.md @@ -1,27 +1,28 @@ --- title: Configure Quality of Service for Pods -content_template: templates/task +content_type: task weight: 30 --- -{{% capture overview %}} + This page shows how to configure Pods so that they will be assigned particular Quality of Service (QoS) classes. Kubernetes uses QoS classes to make decisions about scheduling and evicting Pods. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## QoS classes @@ -235,9 +236,10 @@ Delete your namespace: kubectl delete namespace qos-example ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + ### For app developers @@ -263,7 +265,7 @@ kubectl delete namespace qos-example * [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/) * [Control Topology Management policies on a node](/docs/tasks/administer-cluster/topology-manager/) -{{% /capture %}} + diff --git a/content/en/docs/tasks/configure-pod-container/security-context.md b/content/en/docs/tasks/configure-pod-container/security-context.md index 0c2bb05d0c..38662760b7 100644 --- a/content/en/docs/tasks/configure-pod-container/security-context.md +++ b/content/en/docs/tasks/configure-pod-container/security-context.md @@ -4,11 +4,11 @@ reviewers: - mikedanese - thockin title: Configure a Security Context for a Pod or Container -content_template: templates/task +content_type: task weight: 80 --- -{{% capture overview %}} + A security context defines privilege and access control settings for a Pod or Container. Security context settings include, but are not limited to: @@ -37,15 +37,16 @@ for a comprehensive list. For more information about security mechanisms in Linux, see [Overview of Linux Kernel Security Features](https://www.linux.com/learn/overview-linux-kernel-security-features) -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Set the security context for a Pod @@ -409,9 +410,10 @@ kubectl delete pod security-context-demo-3 kubectl delete pod security-context-demo-4 ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core) * [SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core) @@ -423,4 +425,4 @@ kubectl delete pod security-context-demo-4 document](https://git.k8s.io/community/contributors/design-proposals/auth/no-new-privs.md) -{{% /capture %}} + diff --git a/content/en/docs/tasks/configure-pod-container/share-process-namespace.md b/content/en/docs/tasks/configure-pod-container/share-process-namespace.md index ee227d3f9b..dfb8e40906 100644 --- a/content/en/docs/tasks/configure-pod-container/share-process-namespace.md +++ b/content/en/docs/tasks/configure-pod-container/share-process-namespace.md @@ -5,11 +5,11 @@ reviewers: - verb - yujuhong - dchen1107 -content_template: templates/task +content_type: task weight: 160 --- -{{% capture overview %}} + {{< feature-state state="stable" for_k8s_version="v1.17" >}} @@ -21,15 +21,16 @@ You can use this feature to configure cooperating containers, such as a log handler sidecar container, or to troubleshoot container images that don't include debugging utilities like a shell. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Configure a Pod @@ -93,9 +94,9 @@ events { worker_connections 1024; ``` -{{% /capture %}} -{{% capture discussion %}} + + ## Understanding Process Namespace Sharing @@ -117,6 +118,6 @@ containers, though, so it's important to understand these differences: `/proc/$pid/root` link.** This makes debugging easier, but it also means that filesystem secrets are protected only by filesystem permissions. -{{% /capture %}} + diff --git a/content/en/docs/tasks/configure-pod-container/static-pod.md b/content/en/docs/tasks/configure-pod-container/static-pod.md index fc31526348..5189fdb882 100644 --- a/content/en/docs/tasks/configure-pod-container/static-pod.md +++ b/content/en/docs/tasks/configure-pod-container/static-pod.md @@ -3,10 +3,10 @@ reviewers: - jsafrane title: Create static Pods weight: 170 -content_template: templates/task +content_type: task --- -{{% capture overview %}} + *Static Pods* are managed directly by the kubelet daemon on a specific node, @@ -30,9 +30,10 @@ Pods to run a Pod on every node, you should probably be using a instead. {{< /note >}} -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} @@ -41,10 +42,10 @@ and that your nodes are running the Fedora operating system. Instructions for other distributions or Kubernetes installations may vary. -{{% /capture %}} -{{% capture steps %}} + + ## Create a static pod {#static-pod-creation} @@ -236,4 +237,4 @@ CONTAINER ID IMAGE COMMAND CREATED ... e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago ``` -{{% /capture %}} + diff --git a/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md b/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md index 847d76f25c..4fadbb3f42 100644 --- a/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md +++ b/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md @@ -2,26 +2,27 @@ reviewers: - cdrage title: Translate a Docker Compose File to Kubernetes Resources -content_template: templates/task +content_type: task weight: 200 --- -{{% capture overview %}} + What's Kompose? It's a conversion tool for all things compose (namely Docker Compose) to container orchestrators (Kubernetes or OpenShift). More information can be found on the Kompose website at [http://kompose.io](http://kompose.io). -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Install Kompose @@ -200,9 +201,9 @@ you need is an existing `docker-compose.yml` file. $ curl http://192.0.2.89 ``` -{{% /capture %}} -{{% capture discussion %}} + + ## User Guide @@ -606,4 +607,4 @@ Kompose supports Docker Compose versions: 1, 2 and 3. We have limited support on A full list on compatibility between all three versions is listed in our [conversion document](https://github.com/kubernetes/kompose/blob/master/docs/conversion.md) including a list of all incompatible Docker Compose keys. -{{% /capture %}} + diff --git a/content/en/docs/tasks/debug-application-cluster/_index.md b/content/en/docs/tasks/debug-application-cluster/_index.md index edce58d23a..0aa5f76478 100755 --- a/content/en/docs/tasks/debug-application-cluster/_index.md +++ b/content/en/docs/tasks/debug-application-cluster/_index.md @@ -1,5 +1,6 @@ --- title: "Monitoring, Logging, and Debugging" +description: Set up monitoring and logging to troubleshoot a cluster, or debug a containerized application. weight: 80 --- diff --git a/content/en/docs/tasks/debug-application-cluster/audit.md b/content/en/docs/tasks/debug-application-cluster/audit.md index 5a57779b6c..600af51d00 100644 --- a/content/en/docs/tasks/debug-application-cluster/audit.md +++ b/content/en/docs/tasks/debug-application-cluster/audit.md @@ -3,11 +3,11 @@ reviewers: - soltysh - sttts - ericchiang -content_template: templates/concept +content_type: concept title: Auditing --- -{{% capture overview %}} + Kubernetes auditing provides a security-relevant chronological set of records documenting the sequence of activities that have affected system by individual users, administrators @@ -22,10 +22,10 @@ answer the following questions: - from where was it initiated? - to where was it going? -{{% /capture %}} -{{% capture body %}} + + [Kube-apiserver][kube-apiserver] performs auditing. Each request on each stage of its execution generates an event, which is then pre-processed according to @@ -245,7 +245,7 @@ Existing static backends that you configure with runtime flags are not affected The AuditSink policy differs from the legacy audit runtime policy. This is because the API object serves different use cases. The policy will continue to evolve to serve more use cases. -The `level` field applies the given audit level to all requests. The `stages` field is now a whitelist of stages to record. +The `level` field applies the given audit level to all requests. The `stages` field is now a list of allowed stages to record. #### Contacting the webhook @@ -503,12 +503,13 @@ plugin which supports full-text search and analytics. [logstash_install_doc]: https://www.elastic.co/guide/en/logstash/current/installing-logstash.html [kube-aggregator]: /docs/concepts/api-extension/apiserver-aggregation -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + Visit [Auditing with Falco](/docs/tasks/debug-application-cluster/falco). Learn about [Mutating webhook auditing annotations](/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations). -{{% /capture %}} + diff --git a/content/en/docs/tasks/debug-application-cluster/crictl.md b/content/en/docs/tasks/debug-application-cluster/crictl.md index f7bfec87ff..a047f194e9 100644 --- a/content/en/docs/tasks/debug-application-cluster/crictl.md +++ b/content/en/docs/tasks/debug-application-cluster/crictl.md @@ -4,11 +4,11 @@ reviewers: - feiskyer - mrunalp title: Debugging Kubernetes nodes with crictl -content_template: templates/task +content_type: task --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.11" state="stable" >}} @@ -17,15 +17,16 @@ You can use it to inspect and debug container runtimes and applications on a Kubernetes node. `crictl` and its source are hosted in the [cri-tools](https://github.com/kubernetes-incubator/cri-tools) repository. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + `crictl` requires a Linux operating system with a CRI runtime. -{{% /capture %}} -{{% capture steps %}} + + ## Installing crictl @@ -347,12 +348,12 @@ CONTAINER ID IMAGE CREATED STATE 3e025dd50a72d busybox About a minute ago Running busybox 0 ``` -{{% /capture %}} -{{% capture discussion %}} + + See [kubernetes-incubator/cri-tools](https://github.com/kubernetes-incubator/cri-tools) for more information. -{{% /capture %}} + diff --git a/content/en/docs/tasks/debug-application-cluster/debug-application-introspection.md b/content/en/docs/tasks/debug-application-cluster/debug-application-introspection.md index 2f5d6e7eda..730b9fb00c 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-application-introspection.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-application-introspection.md @@ -2,20 +2,20 @@ reviewers: - janetkuo - thockin -content_template: templates/concept +content_type: concept title: Application Introspection and Debugging --- -{{% capture overview %}} + Once your application is running, you'll inevitably need to debug problems with it. Earlier we described how you can use `kubectl get pods` to retrieve simple status information about your pods. But there are a number of ways to get even more information about your application. -{{% /capture %}} -{{% capture body %}} + + ## Using `kubectl describe pod` to fetch details about pods @@ -387,17 +387,18 @@ status: systemUUID: ABE5F6B4-D44B-108B-C46A-24CCE16C8B6E ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + Learn about additional debugging tools, including: * [Logging](/docs/concepts/cluster-administration/logging/) * [Monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) * [Getting into containers via `exec`](/docs/tasks/debug-application-cluster/get-shell-running-container/) -* [Connecting to containers via proxies](/docs/tasks/access-kubernetes-api/http-proxy-access-api/) +* [Connecting to containers via proxies](/docs/tasks/extend-kubernetes/http-proxy-access-api/) * [Connecting to containers via port forwarding](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) * [Inspect Kubernetes node with crictl](/docs/tasks/debug-application-cluster/crictl/) -{{% /capture %}} + diff --git a/content/en/docs/tasks/debug-application-cluster/debug-application.md b/content/en/docs/tasks/debug-application-cluster/debug-application.md index 08f0fad008..a5c37541c3 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-application.md @@ -3,19 +3,19 @@ reviewers: - mikedanese - thockin title: Troubleshoot Applications -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + This guide is to help users debug applications that are deployed into Kubernetes and not behaving correctly. This is *not* a guide for people who want to debug their cluster. For that you should check out [this guide](/docs/admin/cluster-troubleshooting). -{{% /capture %}} -{{% capture body %}} + + ## Diagnosing the problem @@ -161,12 +161,13 @@ check: * Can you connect to your pods directly? Get the IP address for the Pod, and try to connect directly to that IP. * Is your application serving on the port that you configured? Kubernetes doesn't do port remapping, so if your application serves on 8080, the `containerPort` field needs to be 8080. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + If none of the above solves your problem, follow the instructions in [Debugging Service document](/docs/user-guide/debugging-services) to make sure that your `Service` is running, has `Endpoints`, and your `Pods` are actually serving; you have DNS working, iptables rules installed, and kube-proxy does not seem to be misbehaving. You may also visit [troubleshooting document](/docs/troubleshooting/) for more information. -{{% /capture %}} + diff --git a/content/en/docs/tasks/debug-application-cluster/debug-cluster.md b/content/en/docs/tasks/debug-application-cluster/debug-cluster.md index 473f364361..0a66bed195 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-cluster.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-cluster.md @@ -2,20 +2,20 @@ reviewers: - davidopp title: Troubleshoot Clusters -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + This doc is about cluster troubleshooting; we assume you have already ruled out your application as the root cause of the problem you are experiencing. See the [application troubleshooting guide](/docs/tasks/debug-application-cluster/debug-application) for tips on application debugging. You may also visit [troubleshooting document](/docs/troubleshooting/) for more information. -{{% /capture %}} -{{% capture body %}} + + ## Listing your cluster @@ -124,4 +124,4 @@ This is an incomplete list of things that could go wrong, and how to adjust your - Mitigates: Node shutdown - Mitigates: Kubelet software fault -{{% /capture %}} + diff --git a/content/en/docs/tasks/debug-application-cluster/debug-init-containers.md b/content/en/docs/tasks/debug-application-cluster/debug-init-containers.md index 296f0a0648..a6a3a44d98 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-init-containers.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-init-containers.md @@ -8,19 +8,20 @@ reviewers: - kow3ns - smarterclayton title: Debug Init Containers -content_template: templates/task +content_type: task --- -{{% capture overview %}} + This page shows how to investigate problems related to the execution of Init Containers. The example command lines below refer to the Pod as `` and the Init Containers as `` and ``. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} @@ -28,9 +29,9 @@ Init Containers. The example command lines below refer to the Pod as [Init Containers](/docs/concepts/abstractions/init-containers/). * You should have [Configured an Init Container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/). -{{% /capture %}} -{{% capture steps %}} + + ## Checking the status of Init Containers @@ -113,9 +114,9 @@ Init Containers that run a shell script print commands as they're executed. For example, you can do this in Bash by running `set -x` at the beginning of the script. -{{% /capture %}} -{{% capture discussion %}} + + ## Understanding Pod status @@ -131,7 +132,7 @@ Status | Meaning `Pending` | The Pod has not yet begun executing Init Containers. `PodInitializing` or `Running` | The Pod has already finished executing Init Containers. -{{% /capture %}} + diff --git a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md index 28c9885e57..9793b472e0 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md @@ -2,25 +2,26 @@ reviewers: - bprashanth title: Debug Pods and ReplicationControllers -content_template: templates/task +content_type: task --- -{{% capture overview %}} + This page shows how to debug Pods and ReplicationControllers. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * You should be familiar with the basics of [Pods](/docs/concepts/workloads/pods/pod/) and [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/). -{{% /capture %}} -{{% capture steps %}} + + ## Debugging Pods @@ -106,4 +107,4 @@ or they can't. If they can't create pods, then please refer to the You can also use `kubectl describe rc ${CONTROLLER_NAME}` to inspect events related to the replication controller. -{{% /capture %}} + diff --git a/content/en/docs/tasks/debug-application-cluster/debug-running-pod.md b/content/en/docs/tasks/debug-application-cluster/debug-running-pod.md index a812640555..5e67585705 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-running-pod.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-running-pod.md @@ -3,16 +3,17 @@ reviewers: - verb - soltysh title: Debug Running Pods -content_template: templates/task +content_type: task --- -{{% capture overview %}} + This page explains how to debug Pods running (or crashing) on a Node. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * Your {{< glossary_tooltip text="Pod" term_id="pod" >}} should already be scheduled and running. If your Pod is not yet running, start with [Troubleshoot @@ -21,9 +22,9 @@ This page explains how to debug Pods running (or crashing) on a Node. Pod is running and have shell access to run commands on that Node. You don't need that access to run the standard debug steps that use `kubectl`. -{{% /capture %}} -{{% capture steps %}} + + ## Examining pod logs {#examine-pod-logs} @@ -187,4 +188,4 @@ given tools in the Kubernetes API. Therefore, if you find yourself needing to ssh into a machine, please file a feature request on GitHub describing your use case and why these tools are insufficient. -{{% /capture %}} + diff --git a/content/en/docs/tasks/debug-application-cluster/debug-service.md b/content/en/docs/tasks/debug-application-cluster/debug-service.md index 8656f3ae7e..c4e12042fb 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-service.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-service.md @@ -2,21 +2,21 @@ reviewers: - thockin - bowei -content_template: templates/concept +content_type: concept title: Debug Services --- -{{% capture overview %}} + An issue that comes up rather frequently for new installations of Kubernetes is that a Service is not working properly. You've run your Pods through a Deployment (or other workload controller) and created a Service, but you get no response when you try to access it. This document will hopefully help you to figure out what's going wrong. -{{% /capture %}} -{{% capture body %}} + + ## Running commands in a Pod @@ -728,10 +728,11 @@ Contact us on [Forum](https://discuss.kubernetes.io) or [GitHub](https://github.com/kubernetes/kubernetes). -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + Visit [troubleshooting document](/docs/troubleshooting/) for more information. -{{% /capture %}} + diff --git a/content/en/docs/tasks/debug-application-cluster/debug-stateful-set.md b/content/en/docs/tasks/debug-application-cluster/debug-stateful-set.md index 8bf56bb10c..755c9b725e 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-stateful-set.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-stateful-set.md @@ -8,23 +8,24 @@ reviewers: - kow3ns - smarterclayton title: Debug a StatefulSet -content_template: templates/task +content_type: task --- -{{% capture overview %}} + This task shows you how to debug a StatefulSet. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. * You should have a StatefulSet running that you want to investigate. -{{% /capture %}} -{{% capture steps %}} + + ## Debugging a StatefulSet @@ -41,12 +42,13 @@ instructions on how to deal with them. You can debug individual Pods in a StatefulSet using the [Debugging Pods](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/) guide. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + Learn more about [debugging an init-container](/docs/tasks/debug-application-cluster/debug-init-containers/). -{{% /capture %}} + diff --git a/content/en/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md b/content/en/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md index 6910b25ce0..44dcf0e909 100644 --- a/content/en/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md +++ b/content/en/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md @@ -1,9 +1,9 @@ --- title: Determine the Reason for Pod Failure -content_template: templates/task +content_type: task --- -{{% capture overview %}} + This page shows how to write and read a Container termination message. @@ -16,17 +16,18 @@ put in a termination message should also be written to the general [Kubernetes logs](/docs/concepts/cluster-administration/logging/). -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Writing and reading a termination message @@ -110,16 +111,17 @@ to use the last chunk of container log output if the termination message file is empty and the container exited with an error. The log output is limited to 2048 bytes or 80 lines, whichever is smaller. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * See the `terminationMessagePath` field in [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core). * Learn about [retrieving logs](/docs/concepts/cluster-administration/logging/). * Learn about [Go templates](https://golang.org/pkg/text/template/). -{{% /capture %}} + diff --git a/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md b/content/en/docs/tasks/debug-application-cluster/dns-debugging-resolution.md similarity index 65% rename from content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md rename to content/en/docs/tasks/debug-application-cluster/dns-debugging-resolution.md index 3a69bd84ec..e762258c88 100644 --- a/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md +++ b/content/en/docs/tasks/debug-application-cluster/dns-debugging-resolution.md @@ -3,43 +3,52 @@ reviewers: - bowei - zihongz title: Debugging DNS Resolution -content_template: templates/task +content_type: task +min-kubernetes-server-version: v1.6 --- -{{% capture overview %}} + This page provides hints on diagnosing DNS problems. -{{% /capture %}} -{{% capture prerequisites %}} -* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -* Kubernetes version 1.6 and above. -* The cluster must be configured to use the `coredns` (or `kube-dns`) addons. -{{% /capture %}} +## {{% heading "prerequisites" %}} -{{% capture steps %}} +{{< include "task-tutorial-prereqs.md" >}} +Your cluster must be configured to use the CoreDNS +{{< glossary_tooltip text="addon" term_id="addons" >}} or its precursor, +kube-dns. + +{{% version-check %}} + + ### Create a simple Pod to use as a test environment -Create a file named dnsutils.yaml with the following contents: - {{< codenew file="admin/dns/dnsutils.yaml" >}} -Then create a pod using this file and verify its status: +Use that manifest to create a Pod: ```shell kubectl apply -f https://k8s.io/examples/admin/dns/dnsutils.yaml +``` +``` pod/dnsutils created - +``` +…and verify its status: +```shell kubectl get pods dnsutils +``` +``` NAME READY STATUS RESTARTS AGE dnsutils 1/1 Running 0 ``` -Once that pod is running, you can exec `nslookup` in that environment. +Once that Pod is running, you can exec `nslookup` in that environment. If you see something like the following, DNS is working correctly. ```shell -kubectl exec -ti dnsutils -- nslookup kubernetes.default +kubectl exec -i -t dnsutils -- nslookup kubernetes.default +``` +``` Server: 10.0.0.10 Address 1: 10.0.0.10 @@ -68,11 +77,13 @@ nameserver 10.0.0.10 options ndots:5 ``` -Errors such as the following indicate a problem with the coredns/kube-dns add-on or -associated Services: +Errors such as the following indicate a problem with the CoreDNS (or kube-dns) +add-on or with associated Services: +```shell +kubectl exec -i -t dnsutils -- nslookup kubernetes.default +``` ``` -kubectl exec -ti dnsutils -- nslookup kubernetes.default Server: 10.0.0.10 Address 1: 10.0.0.10 @@ -81,8 +92,10 @@ nslookup: can't resolve 'kubernetes.default' or +```shell +kubectl exec -i -t dnsutils -- nslookup kubernetes.default +``` ``` -kubectl exec -ti dnsutils -- nslookup kubernetes.default Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local @@ -93,9 +106,10 @@ nslookup: can't resolve 'kubernetes.default' Use the `kubectl get pods` command to verify that the DNS pod is running. -For CoreDNS: ```shell kubectl get pods --namespace=kube-system -l k8s-app=kube-dns +``` +``` NAME READY STATUS RESTARTS AGE ... coredns-7b96bf9f76-5hsxb 1/1 Running 0 1h @@ -103,26 +117,22 @@ coredns-7b96bf9f76-mvmmt 1/1 Running 0 1h ... ``` -Or for kube-dns: -```shell -kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -NAME READY STATUS RESTARTS AGE -... -kube-dns-v19-ezo1y 3/3 Running 0 1h -... -``` +{{< note >}} +The value for label `k8s-app` is `kube-dns` for both CoreDNS and kube-dns deployments. +{{< /note >}} -If you see that no pod is running or that the pod has failed/completed, the DNS -add-on may not be deployed by default in your current environment and you will -have to deploy it manually. -### Check for Errors in the DNS pod +If you see that no CoreDNS Pod is running or that the Pod has failed/completed, +the DNS add-on may not be deployed by default in your current environment and you +will have to deploy it manually. -Use `kubectl logs` command to see logs for the DNS containers. +### Check for errors in the DNS pod + +Use the `kubectl logs` command to see logs for the DNS containers. For CoreDNS: ```shell -for p in $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name); do kubectl logs --namespace=kube-system $p; done +kubectl logs --namespace=kube-system -l k8s-app=kube-dns ``` Here is an example of a healthy CoreDNS log: @@ -136,21 +146,7 @@ linux/amd64, go1.10.3, 2e322f6 2018/08/15 14:37:17 [INFO] plugin/reload: Running configuration MD5 = 24e6c59e83ce706f07bcc82c31b1ea1c ``` - -For kube-dns, there are 3 sets of logs: -```shell -kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c kubedns - -kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c dnsmasq - -kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c sidecar -``` - -See if there are any suspicious error messages in the logs. In kube-dns, a '`W`', '`E`' or '`F`' at the beginning -of a line represents a Warning, Error or Failure. Please search for entries that have these -as the logging level and use -[kubernetes issues](https://github.com/kubernetes/kubernetes/issues) -to report unexpected errors. +See if there are any suspicious or unexpected messages in the logs. ### Is DNS service up? @@ -158,17 +154,23 @@ Verify that the DNS service is up by using the `kubectl get service` command. ```shell kubectl get svc --namespace=kube-system +``` +``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ... kube-dns ClusterIP 10.0.0.10 53/UDP,53/TCP 1h ... ``` +{{< note >}} +The service name is `kube-dns` for both CoreDNS and kube-dns deployments. +{{< /note >}} -Note that the service name will be "kube-dns" for both CoreDNS and kube-dns deployments. -If you have created the service or in the case it should be created by default -but it does not appear, see -[debugging services](/docs/tasks/debug-application-cluster/debug-service/) for + + +If you have created the Service or in the case it should be created by default +but it does not appear, see +[debugging Services](/docs/tasks/debug-application-cluster/debug-service/) for more information. ### Are DNS endpoints exposed? @@ -177,31 +179,32 @@ You can verify that DNS endpoints are exposed by using the `kubectl get endpoint command. ```shell -kubectl get ep kube-dns --namespace=kube-system +kubectl get endpoints kube-dns --namespace=kube-system +``` +``` NAME ENDPOINTS AGE kube-dns 10.180.3.17:53,10.180.3.17:53 1h ``` -If you do not see the endpoints, see endpoints section in the -[debugging services](/docs/tasks/debug-application-cluster/debug-service/) documentation. +If you do not see the endpoints, see the endpoints section in the +[debugging Services](/docs/tasks/debug-application-cluster/debug-service/) documentation. For additional Kubernetes DNS examples, see the [cluster-dns examples](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns) in the Kubernetes GitHub repository. - ### Are DNS queries being received/processed? You can verify if queries are being received by CoreDNS by adding the `log` plugin to the CoreDNS configuration (aka Corefile). -The CoreDNS Corefile is held in a ConfigMap named `coredns`. To edit it, use the command ... +The CoreDNS Corefile is held in a {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} named `coredns`. To edit it, use the command: ``` kubectl -n kube-system edit configmap coredns ``` -Then add `log` in the Corefile section per the example below. +Then add `log` in the Corefile section per the example below: -``` +```yaml apiVersion: v1 kind: ConfigMap metadata: @@ -225,14 +228,13 @@ data: reload loadbalance } - ``` After saving the changes, it may take up to minute or two for Kubernetes to propagate these changes to the CoreDNS pods. Next, make some queries and view the logs per the sections above in this document. If CoreDNS pods are receiving the queries, you should see them in the logs. -Here is an example of a query in the log. +Here is an example of a query in the log: ``` .:53 @@ -243,7 +245,6 @@ linux/amd64, go1.10.3, 2e322f6 2018/09/07 15:29:04 [INFO] plugin/reload: Running configuration MD5 = 162475cdf272d8aa601e6fe67a6ad42f 2018/09/07 15:29:04 [INFO] Reloading complete 172.17.0.18:41675 - [07/Sep/2018:15:29:11 +0000] 59925 "A IN kubernetes.default.svc.cluster.local. udp 54 false 512" NOERROR qr,aa,rd,ra 106 0.000066649s - ``` ## Known issues @@ -252,7 +253,7 @@ Some Linux distributions (e.g. Ubuntu) use a local DNS resolver by default (syst Systemd-resolved moves and replaces `/etc/resolv.conf` with a stub file that can cause a fatal forwarding loop when resolving names in upstream servers. This can be fixed manually by using kubelet's `--resolv-conf` flag to point to the correct `resolv.conf` (With `systemd-resolved`, this is `/run/systemd/resolve/resolv.conf`). -kubeadm (>= 1.11) automatically detects `systemd-resolved`, and adjusts the kubelet flags accordingly. +kubeadm automatically detects `systemd-resolved`, and adjusts the kubelet flags accordingly. Kubernetes installs do not configure the nodes' `resolv.conf` files to use the cluster DNS by default, because that process is inherently distribution-specific. @@ -262,16 +263,11 @@ Linux's libc (a.k.a. glibc) has a limit for the DNS `nameserver` records to 3 by If you are using Alpine version 3.3 or earlier as your base image, DNS may not work properly due to a known issue with Alpine. -Check [here](https://github.com/kubernetes/kubernetes/issues/30215) -for more information. +Kubernetes [issue 30215](https://github.com/kubernetes/kubernetes/issues/30215) +details more information on this. -## References +## {{% heading "whatsnext" %}} -- [DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/) -- [Docs for the kube-dns DNS cluster addon](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/README.md) - -## What's next -- [Autoscaling the DNS Service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/). - -{{% /capture %}} +- See [Autoscaling the DNS Service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/). +- Read [DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/) diff --git a/content/en/docs/tasks/debug-application-cluster/events-stackdriver.md b/content/en/docs/tasks/debug-application-cluster/events-stackdriver.md index d852ed3cf9..859c163307 100644 --- a/content/en/docs/tasks/debug-application-cluster/events-stackdriver.md +++ b/content/en/docs/tasks/debug-application-cluster/events-stackdriver.md @@ -2,11 +2,11 @@ reviewers: - piosz - x13n -content_template: templates/concept +content_type: concept title: Events in Stackdriver --- -{{% capture overview %}} + Kubernetes events are objects that provide insight into what is happening inside a cluster, such as what decisions were made by scheduler or why some @@ -34,10 +34,10 @@ of the potential inaccuracy. {{< /note >}} -{{% /capture %}} -{{% capture body %}} + + ## Deployment @@ -91,4 +91,4 @@ jsonPayload.involvedObject.name:"nginx-deployment" {{< figure src="/images/docs/stackdriver-event-exporter-filter.png" alt="Filtered events in the Stackdriver Logging interface" width="500" >}} -{{% /capture %}} + diff --git a/content/en/docs/tasks/debug-application-cluster/falco.md b/content/en/docs/tasks/debug-application-cluster/falco.md index 003b287602..f5f67406a9 100644 --- a/content/en/docs/tasks/debug-application-cluster/falco.md +++ b/content/en/docs/tasks/debug-application-cluster/falco.md @@ -3,19 +3,19 @@ reviewers: - soltysh - sttts - ericchiang -content_template: templates/concept +content_type: concept title: Auditing with Falco --- -{{% capture overview %}} + ### Use Falco to collect audit events [Falco](https://falco.org/) is an open source project for intrusion and abnormality detection for Cloud Native platforms. This section describes how to set up Falco, how to send audit events to the Kubernetes Audit endpoint exposed by Falco, and how Falco applies a set of rules to automatically detect suspicious behavior. -{{% /capture %}} -{{% capture body %}} + + #### Install Falco @@ -118,4 +118,4 @@ For further details, see [Kubernetes Audit Events][falco_ka_docs] in the Falco d [falco_installation]: https://falco.org/docs/installation [falco_helm_chart]: https://github.com/helm/charts/tree/master/stable/falco -{{% /capture %}} + diff --git a/content/en/docs/tasks/debug-application-cluster/get-shell-running-container.md b/content/en/docs/tasks/debug-application-cluster/get-shell-running-container.md index f3ff92c196..8535e9763c 100644 --- a/content/en/docs/tasks/debug-application-cluster/get-shell-running-container.md +++ b/content/en/docs/tasks/debug-application-cluster/get-shell-running-container.md @@ -3,29 +3,30 @@ reviewers: - caesarxuchao - mikedanese title: Get a Shell to a Running Container -content_template: templates/task +content_type: task --- -{{% capture overview %}} + This page shows how to use `kubectl exec` to get a shell to a -running Container. - -{{% /capture %}} +running container. -{{% capture prerequisites %}} - -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - -{{% /capture %}} -{{% capture steps %}} +## {{% heading "prerequisites" %}} -## Getting a shell to a Container -In this exercise, you create a Pod that has one Container. The Container +{{< include "task-tutorial-prereqs.md" >}} + + + + + + +## Getting a shell to a container + +In this exercise, you create a Pod that has one container. The container runs the nginx image. Here is the configuration file for the Pod: {{< codenew file="application/shell-demo.yaml" >}} @@ -36,116 +37,121 @@ Create the Pod: kubectl apply -f https://k8s.io/examples/application/shell-demo.yaml ``` -Verify that the Container is running: +Verify that the container is running: ```shell kubectl get pod shell-demo ``` -Get a shell to the running Container: +Get a shell to the running container: ```shell -kubectl exec -it shell-demo -- /bin/bash +kubectl exec --stdin --tty shell-demo -- /bin/bash ``` + {{< note >}} - -The double dash symbol "--" is used to separate the arguments you want to pass to the command from the kubectl arguments. - +The double dash (`--`) separates the arguments you want to pass to the command from the kubectl arguments. {{< /note >}} In your shell, list the root directory: ```shell -root@shell-demo:/# ls / +# Run this inside the container +ls / ``` In your shell, experiment with other commands. Here are some examples: ```shell -root@shell-demo:/# ls / -root@shell-demo:/# cat /proc/mounts -root@shell-demo:/# cat /proc/1/maps -root@shell-demo:/# apt-get update -root@shell-demo:/# apt-get install -y tcpdump -root@shell-demo:/# tcpdump -root@shell-demo:/# apt-get install -y lsof -root@shell-demo:/# lsof -root@shell-demo:/# apt-get install -y procps -root@shell-demo:/# ps aux -root@shell-demo:/# ps aux | grep nginx +# You can run these example commands inside the container +ls / +cat /proc/mounts +cat /proc/1/maps +apt-get update +apt-get install -y tcpdump +tcpdump +apt-get install -y lsof +lsof +apt-get install -y procps +ps aux +ps aux | grep nginx ``` ## Writing the root page for nginx Look again at the configuration file for your Pod. The Pod -has an `emptyDir` volume, and the Container mounts the volume +has an `emptyDir` volume, and the container mounts the volume at `/usr/share/nginx/html`. In your shell, create an `index.html` file in the `/usr/share/nginx/html` directory: ```shell -root@shell-demo:/# echo Hello shell demo > /usr/share/nginx/html/index.html +# Run this inside the container +echo 'Hello shell demo' > /usr/share/nginx/html/index.html ``` In your shell, send a GET request to the nginx server: ```shell -root@shell-demo:/# apt-get update -root@shell-demo:/# apt-get install curl -root@shell-demo:/# curl localhost +# Run this in the shell inside your container +apt-get update +apt-get install curl +curl http://localhost/ ``` The output shows the text that you wrote to the `index.html` file: -```shell +``` Hello shell demo ``` When you are finished with your shell, enter `exit`. -## Running individual commands in a Container +```shell +exit # To quit the shell in the container +``` + +## Running individual commands in a container In an ordinary command window, not your shell, list the environment -variables in the running Container: +variables in the running container: ```shell kubectl exec shell-demo env ``` -Experiment running other commands. Here are some examples: +Experiment with running other commands. Here are some examples: ```shell -kubectl exec shell-demo ps aux -kubectl exec shell-demo ls / -kubectl exec shell-demo cat /proc/1/mounts +kubectl exec shell-demo -- ps aux +kubectl exec shell-demo -- ls / +kubectl exec shell-demo -- cat /proc/1/mounts ``` -{{% /capture %}} -{{% capture discussion %}} -## Opening a shell when a Pod has more than one Container + -If a Pod has more than one Container, use `--container` or `-c` to -specify a Container in the `kubectl exec` command. For example, +## Opening a shell when a Pod has more than one container + +If a Pod has more than one container, use `--container` or `-c` to +specify a container in the `kubectl exec` command. For example, suppose you have a Pod named my-pod, and the Pod has two containers -named main-app and helper-app. The following command would open a -shell to the main-app Container. +named _main-app_ and _helper-app_. The following command would open a +shell to the _main-app_ container. ```shell -kubectl exec -it my-pod --container main-app -- /bin/bash +kubectl exec -i -t my-pod --container main-app -- /bin/bash ``` -{{% /capture %}} +{{< note >}} +The short options `-i` and `-t` are the same as the long options `--stdin` and `--tty` +{{< /note >}} -{{% capture whatsnext %}} - -* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec) - -{{% /capture %}} - +## {{% heading "whatsnext" %}} +* Read about [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec) diff --git a/content/en/docs/tasks/debug-application-cluster/local-debugging.md b/content/en/docs/tasks/debug-application-cluster/local-debugging.md index 9cfc216ee4..d00c1398eb 100644 --- a/content/en/docs/tasks/debug-application-cluster/local-debugging.md +++ b/content/en/docs/tasks/debug-application-cluster/local-debugging.md @@ -1,9 +1,9 @@ --- title: Developing and debugging services locally -content_template: templates/task +content_type: task --- -{{% capture overview %}} + Kubernetes applications usually consist of multiple, separate services, each running in its own container. Developing and debugging these services on a remote Kubernetes cluster can be cumbersome, requiring you to [get a shell on a running container](/docs/tasks/debug-application-cluster/get-shell-running-container/) and running your tools inside the remote shell. @@ -12,17 +12,18 @@ Kubernetes applications usually consist of multiple, separate services, each run This document describes using `telepresence` to develop and debug services running on a remote cluster locally. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * Kubernetes cluster is installed * `kubectl` is configured to communicate with the cluster * [Telepresence](https://www.telepresence.io/reference/install) is installed -{{% /capture %}} -{{% capture steps %}} + + ## Getting a shell on a remote cluster @@ -46,9 +47,10 @@ where $DEPLOYMENT_NAME is the name of your existing deployment. Running this command spawns a shell. In the shell, start your service. You can then make edits to the source code locally, save, and see the changes take effect immediately. You can also run your service in a debugger, or any other local development tool. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + If you're interested in a hands-on tutorial, check out [this tutorial](https://cloud.google.com/community/tutorials/developing-services-with-k8s) that walks through locally developing the Guestbook application on Google Kubernetes Engine. @@ -56,4 +58,4 @@ Telepresence has [numerous proxying options](https://www.telepresence.io/referen For further reading, visit the [Telepresence website](https://www.telepresence.io). -{{% /capture %}} + diff --git a/content/en/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md b/content/en/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md index 327bfdf925..c47b117391 100644 --- a/content/en/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md +++ b/content/en/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md @@ -2,11 +2,11 @@ reviewers: - piosz - x13n -content_template: templates/concept +content_type: concept title: Logging Using Elasticsearch and Kibana --- -{{% capture overview %}} + On the Google Compute Engine (GCE) platform, the default logging support targets [Stackdriver Logging](https://cloud.google.com/logging/), which is described in detail @@ -21,9 +21,9 @@ Stackdriver Logging when running on GCE. You cannot automatically deploy Elasticsearch and Kibana in the Kubernetes cluster hosted on Google Kubernetes Engine. You have to deploy them manually. {{< /note >}} -{{% /capture %}} -{{% capture body %}} + + To use Elasticsearch and Kibana for cluster logging, you should set the following environment variable as shown below when creating your cluster with @@ -114,11 +114,12 @@ Here is a typical view of ingested logs from the Kibana viewer: ![Kibana logs](/images/docs/kibana-logs.png) -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + Kibana opens up all sorts of powerful options for exploring your logs! For some ideas on how to dig into it, check out [Kibana's documentation](https://www.elastic.co/guide/en/kibana/current/discover.html). -{{% /capture %}} + diff --git a/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md b/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md index a60ceeedfb..be80133d34 100644 --- a/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md +++ b/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md @@ -3,10 +3,10 @@ reviewers: - piosz - x13n title: Logging Using Stackdriver -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + Before reading this page, it's highly recommended to familiarize yourself with the [overview of logging in Kubernetes](/docs/concepts/cluster-administration/logging). @@ -18,10 +18,10 @@ see the [sidecar approach](/docs/concepts/cluster-administration/logging#sidecar in the Kubernetes logging overview. {{< /note >}} -{{% /capture %}} -{{% capture body %}} + + ## Deploying @@ -368,4 +368,4 @@ with minor changes: Then run `make build push` from this directory. After updating `DaemonSet` to pick up the new image, you can use the plugin you installed in the fluentd configuration. -{{% /capture %}} + diff --git a/content/en/docs/tasks/debug-application-cluster/monitor-node-health.md b/content/en/docs/tasks/debug-application-cluster/monitor-node-health.md index f434adb17e..9ebeeeddad 100644 --- a/content/en/docs/tasks/debug-application-cluster/monitor-node-health.md +++ b/content/en/docs/tasks/debug-application-cluster/monitor-node-health.md @@ -2,11 +2,11 @@ reviewers: - Random-Liu - dchen1107 -content_template: templates/task +content_type: task title: Monitor Node Health --- -{{% capture overview %}} + *Node problem detector* is a [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) monitoring the node health. It collects node problems from various daemons and reports them @@ -23,15 +23,16 @@ introduced to deal with node problems. See more information [here](https://github.com/kubernetes/node-problem-detector). -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Limitations @@ -162,9 +163,9 @@ Kernel monitor uses [`Translator`](https://github.com/kubernetes/node-problem-de plugin to translate kernel log the internal data structure. It is easy to implement a new translator for a new log format. -{{% /capture %}} -{{% capture discussion %}} + + ## Caveats @@ -177,4 +178,4 @@ resource overhead on each node. Usually this is fine, because: * Even under high load, the resource usage is acceptable. (see [benchmark result](https://github.com/kubernetes/node-problem-detector/issues/2#issuecomment-220255629)) -{{% /capture %}} + diff --git a/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md b/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md index 547790e5b0..dbd4aa6cf4 100644 --- a/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md +++ b/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md @@ -3,20 +3,20 @@ reviewers: - fgrzadkowski - piosz title: Resource metrics pipeline -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + Resource usage metrics, such as container CPU and memory usage, are available in Kubernetes through the Metrics API. These metrics can be either accessed directly by user, for example by using `kubectl top` command, or used by a controller in the cluster, e.g. Horizontal Pod Autoscaler, to make decisions. -{{% /capture %}} -{{% capture body %}} + + ## The Metrics API @@ -61,4 +61,4 @@ Metrics Server is registered with the main API server through Learn more about the metrics server in [the design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md). -{{% /capture %}} + diff --git a/content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md b/content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md index de8c538118..6cb716da9c 100644 --- a/content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md +++ b/content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md @@ -1,11 +1,11 @@ --- reviewers: - mikedanese -content_template: templates/concept +content_type: concept title: Tools for Monitoring Resources --- -{{% capture overview %}} + To scale an application and provide a reliable service, you need to understand how the application behaves when it is deployed. You can examine @@ -16,9 +16,9 @@ information about an application's resource usage at each of these levels. This information allows you to evaluate your application's performance and where bottlenecks can be removed to improve overall performance. -{{% /capture %}} -{{% capture body %}} + + In Kubernetes, application monitoring does not depend on a single monitoring solution. On new clusters, you can use [resource metrics](#resource-metrics-pipeline) or [full metrics](#full-metrics-pipeline) pipelines to collect monitoring statistics. @@ -55,4 +55,4 @@ then exposes them to Kubernetes via an adapter by implementing either the [Prometheus](https://prometheus.io), a CNCF project, can natively monitor Kubernetes, nodes, and Prometheus itself. Full metrics pipeline projects that are not part of the CNCF are outside the scope of Kubernetes documentation. -{{% /capture %}} + diff --git a/content/en/docs/tasks/debug-application-cluster/troubleshooting.md b/content/en/docs/tasks/debug-application-cluster/troubleshooting.md index 1ed0f5aa5b..82301275ce 100644 --- a/content/en/docs/tasks/debug-application-cluster/troubleshooting.md +++ b/content/en/docs/tasks/debug-application-cluster/troubleshooting.md @@ -2,11 +2,11 @@ reviewers: - brendandburns - davidopp -content_template: templates/concept +content_type: concept title: Troubleshooting --- -{{% capture overview %}} + Sometimes things go wrong. This guide is aimed at making them right. It has two sections: @@ -17,10 +17,10 @@ two sections: You should also check the known issues for the [release](https://github.com/kubernetes/kubernetes/releases) you're using. -{{% /capture %}} -{{% capture body %}} + + ## Getting help @@ -104,4 +104,4 @@ problem, such as: * Cloud provider, OS distro, network configuration, and Docker version * Steps to reproduce the problem -{{% /capture %}} + diff --git a/content/en/docs/tasks/example-task-template.md b/content/en/docs/tasks/example-task-template.md index c723460fc0..90d14e98da 100644 --- a/content/en/docs/tasks/example-task-template.md +++ b/content/en/docs/tasks/example-task-template.md @@ -2,11 +2,11 @@ title: Example Task Template reviewers: - chenopis -content_template: templates/task +content_type: task toc_hide: true --- -{{% capture overview %}} + {{< note >}} Be sure to also [create an entry in the table of contents](/docs/contribute/style/write-new-topic/#placing-your-topic-in-the-table-of-contents) for your new document. @@ -14,39 +14,39 @@ Be sure to also [create an entry in the table of contents](/docs/contribute/styl This page shows how to ... -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * Do this. * Do this too. -{{% /capture %}} -{{% capture steps %}} + + ## Doing ... 1. Do this. 1. Do this next. Possibly read this [related explanation](#). -{{% /capture %}} -{{% capture discussion %}} + + ## Understanding ... **[Optional Section]** Here's an interesting thing to know about the steps you just did. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + **[Optional Section]** * Learn more about [Writing a New Topic](/docs/home/contribute/write-new-topic/). -* See [Using Page Templates - Task template](/docs/home/contribute/page-templates/#task_template) for how to use this template. - -{{% /capture %}} \ No newline at end of file +* Learn about [Page Content Types - Task](/docs/home/contribute/style/page-content-types/#task). diff --git a/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md b/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md index dcc315871b..6052bff9af 100644 --- a/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md +++ b/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md @@ -3,24 +3,25 @@ title: Extend kubectl with plugins reviewers: - juanvallejo - soltysh -description: With kubectl plugins, you can extend the functionality of the kubectl command by adding new subcommands. -content_template: templates/task +description: Extend kubectl by creating and installing kubectl plugins. +content_type: task --- -{{% capture overview %}} + This guide demonstrates how to install and write extensions for [kubectl](/docs/reference/kubectl/kubectl/). By thinking of core `kubectl` commands as essential building blocks for interacting with a Kubernetes cluster, a cluster administrator can think of plugins as a means of utilizing these building blocks to create more complex behavior. Plugins extend `kubectl` with new sub-commands, allowing for new and custom features not included in the main distribution of `kubectl`. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + You need to have a working `kubectl` binary installed. -{{% /capture %}} -{{% capture steps %}} + + ## Installing kubectl plugins @@ -375,9 +376,10 @@ set up a build environment (if it needs compiling), and deploy the plugin. If you also make compiled packages available, or use Krew, that will make installs easier. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Check the Sample CLI Plugin repository for a [detailed example](https://github.com/kubernetes/sample-cli-plugin) of a @@ -386,4 +388,4 @@ installs easier. [SIG CLI team](https://github.com/kubernetes/community/tree/master/sig-cli). * Read about [Krew](https://krew.dev/), a package manager for kubectl plugins. -{{% /capture %}} + diff --git a/content/en/docs/tasks/extend-kubernetes/_index.md b/content/en/docs/tasks/extend-kubernetes/_index.md new file mode 100644 index 0000000000..7109fddde0 --- /dev/null +++ b/content/en/docs/tasks/extend-kubernetes/_index.md @@ -0,0 +1,6 @@ +--- +title: "Extend Kubernetes" +description: Understand advanced ways to adapt your Kubernetes cluster to the needs of your work environment. +weight: 90 +--- + diff --git a/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md b/content/en/docs/tasks/extend-kubernetes/configure-aggregation-layer.md similarity index 95% rename from content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md rename to content/en/docs/tasks/extend-kubernetes/configure-aggregation-layer.md index 9a77378d5c..739a69d45a 100644 --- a/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md +++ b/content/en/docs/tasks/extend-kubernetes/configure-aggregation-layer.md @@ -4,31 +4,27 @@ reviewers: - lavalamp - cheftako - chenopis -content_template: templates/task +content_type: task weight: 10 --- -{{% capture overview %}} + -Configuring the [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs. +Configuring the [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs. -{{% /capture %}} - -{{% capture prerequisites %}} +## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} {{< note >}} -There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the master CA. +There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the master CA. +{{< /note >}} {{< caution >}} Reusing the same CA for different client types can negatively impact the cluster's ability to function. For more information, see [CA Reusage and Conflicts](#ca-reusage-and-conflicts). {{< /caution >}} -{{< /note >}} -{{% /capture %}} - -{{% capture steps %}} + ## Authentication Flow @@ -137,7 +133,10 @@ The Kubernetes apiserver connects to the extension apiserver over TLS, authentic The Kubernetes apiserver will use the files indicated by `--proxy-client-*-file` to authenticate to the extension apiserver. In order for the request to be considered valid by a compliant extension apiserver, the following conditions must be met: 1. The connection must be made using a client certificate that is signed by the CA whose certificate is in `--requestheader-client-ca-file`. -2. The connection must be made using a client certificate whose CN is one of those listed in `--requestheader-allowed-names`. **Note:** You can set this option to blank as `--requestheader-allowed-names=""`. This will indicate to an extension apiserver that _any_ CN is acceptable. +2. The connection must be made using a client certificate whose CN is one of those listed in `--requestheader-allowed-names`. + +{{< note >}}You can set this option to blank as `--requestheader-allowed-names=""`. This will indicate to an extension apiserver that _any_ CN is acceptable. +{{< /note >}} When started with these options, the Kubernetes apiserver will: @@ -222,7 +221,7 @@ If you are not running kube-proxy on a host running the API server, then you mus --enable-aggregator-routing=true -{{% /capture %}} + ### Register APIService objects @@ -275,11 +274,8 @@ spec: ... ``` -{{% capture whatsnext %}} - -* [Setup an extension api-server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) to work with the aggregation layer. -* For a high level overview, see [Extending the Kubernetes API with the aggregation layer](/docs/concepts/api-extension/apiserver-aggregation/). -* Learn how to [Extend the Kubernetes API Using Custom Resource Definitions](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/). - -{{% /capture %}} +## {{% heading "whatsnext" %}} +* [Setup an extension api-server](/docs/tasks/extend-kubernetes/setup-extension-api-server/) to work with the aggregation layer. +* For a high level overview, see [Extending the Kubernetes API with the aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/). +* Learn how to [Extend the Kubernetes API Using Custom Resource Definitions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/). diff --git a/content/en/docs/tasks/access-kubernetes-api/custom-resources/_index.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/_index.md similarity index 100% rename from content/en/docs/tasks/access-kubernetes-api/custom-resources/_index.md rename to content/en/docs/tasks/extend-kubernetes/custom-resources/_index.md diff --git a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md similarity index 99% rename from content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md rename to content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md index ec35dd88e8..6eaf0cdd3a 100644 --- a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md +++ b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md @@ -3,19 +3,20 @@ title: Versions in CustomResourceDefinitions reviewers: - sttts - liggitt -content_template: templates/task +content_type: task weight: 30 min-kubernetes-server-version: v1.16 --- -{{% capture overview %}} + This page explains how to add versioning information to [CustomResourceDefinitions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1beta1-apiextensions), to indicate the stability level of your CustomResourceDefinitions or advance your API to a new version with conversion between API representations. It also describes how to upgrade an object from one version to another. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} @@ -23,9 +24,9 @@ You should have a initial understanding of [custom resources](/docs/concepts/api {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Overview @@ -961,4 +962,4 @@ The following is an example procedure to upgrade from `v1beta1` to `v1`. storage version, which is `v1`. 2. Remove `v1beta1` from the CustomResourceDefinition `status.storedVersions` field. -{{% /capture %}} + diff --git a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md similarity index 95% rename from content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md rename to content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md index 4fcd389ba2..78b55b58dc 100644 --- a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md +++ b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md @@ -6,18 +6,19 @@ reviewers: - liggitt - roycaihw - sttts -content_template: templates/task +content_type: task weight: 20 --- -{{% capture overview %}} + This page shows how to install a [custom resource](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) into the Kubernetes API by creating a [CustomResourceDefinition](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1beta1-apiextensions). -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} @@ -25,9 +26,9 @@ into the Kubernetes API by creating a * Read about [custom resources](/docs/concepts/api-extension/custom-resources/). -{{% /capture %}} -{{% capture steps %}} + + ## Create a CustomResourceDefinition @@ -250,11 +251,11 @@ If you later recreate the same CustomResourceDefinition, it will start out empty {{< feature-state state="stable" for_k8s_version="v1.16" >}} -CustomResources traditionally store arbitrary JSON (next to `apiVersion`, `kind` and `metadata`, which is validated by the API server implicitly). With [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) a schema can be specified, which is validated during creation and updates, compare below for details and limits of such a schema. +CustomResources traditionally store arbitrary JSON (next to `apiVersion`, `kind` and `metadata`, which is validated by the API server implicitly). With [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) a schema can be specified, which is validated during creation and updates, compare below for details and limits of such a schema. With `apiextensions.k8s.io/v1` the definition of a structural schema is mandatory for CustomResourceDefinitions, while in `v1beta1` this is still optional. -A structural schema is an [OpenAPI v3.0 validation schema](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) which: +A structural schema is an [OpenAPI v3.0 validation schema](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) which: 1. specifies a non-empty type (via `type` in OpenAPI) for the root, for each specified field of an object node (via `properties` or `additionalProperties` in OpenAPI) and for each item in an array node (via `items` in OpenAPI), with the exception of: * a node with `x-kubernetes-int-or-string: true` @@ -363,15 +364,15 @@ Violations of the structural schema rules are reported in the `NonStructural` co Structural schemas are a requirement for `apiextensions.k8s.io/v1`, and disables the following features for `apiextensions.k8s.io/v1beta1`: -* [Validation Schema Publishing](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#publish-validation-schema-in-openapi-v2) -* [Webhook Conversion](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/#webhook-conversion) +* [Validation Schema Publishing](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#publish-validation-schema-in-openapi-v2) +* [Webhook Conversion](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/#webhook-conversion) * [Pruning](#preserving-unknown-fields) ### Pruning versus preserving unknown fields {#preserving-unknown-fields} {{< feature-state state="stable" for_k8s_version="v1.16" >}} -CustomResourceDefinitions traditionally store any (possibly validated) JSON as is in etcd. This means that unspecified fields (if there is a [OpenAPI v3.0 validation schema](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) at all) are persisted. This is in contrast to native Kubernetes resources such as a pod where unknown fields are dropped before being persisted to etcd. We call this "pruning" of unknown fields. +CustomResourceDefinitions traditionally store any (possibly validated) JSON as is in etcd. This means that unspecified fields (if there is a [OpenAPI v3.0 validation schema](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) at all) are persisted. This is in contrast to native Kubernetes resources such as a pod where unknown fields are dropped before being persisted to etcd. We call this "pruning" of unknown fields. {{< tabs name="CustomResourceDefinition_pruning" >}} {{% tab name="apiextensions.k8s.io/v1" %}} @@ -426,7 +427,7 @@ spec: The field `someRandomField` has been pruned. -Note that the `kubectl create` call uses `--validate=false` to skip client-side validation. Because the [OpenAPI validation schemas are also published](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#publish-validation-schema-in-openapi-v2) to kubectl, it will also check for unknown fields and reject those objects long before they are sent to the API server. +Note that the `kubectl create` call uses `--validate=false` to skip client-side validation. Because the [OpenAPI validation schemas are also published](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#publish-validation-schema-in-openapi-v2) to kubectl, it will also check for unknown fields and reject those objects long before they are sent to the API server. ### Controlling pruning @@ -532,7 +533,7 @@ allOf: With one of those specification, both an integer and a string validate. -In [Validation Schema Publishing](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#publish-validation-schema-in-openapi-v2), `x-kubernetes-int-or-string: true` is unfolded to one of the two patterns shown above. +In [Validation Schema Publishing](/docs/tasks/extend-kubernetes/custom-resources/extend-api-custom-resource-definitions/#publish-validation-schema-in-openapi-v2), `x-kubernetes-int-or-string: true` is unfolded to one of the two patterns shown above. ### RawExtension @@ -564,13 +565,13 @@ With `x-kubernetes-embedded-resource: true`, the `apiVersion`, `kind` and `metad ## Serving multiple versions of a CRD -See [Custom resource definition versioning](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/) +See [Custom resource definition versioning](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/) for more information about serving multiple versions of your CustomResourceDefinition and migrating your objects from one version to another. -{{% /capture %}} -{{% capture discussion %}} + + ## Advanced topics ### Finalizers @@ -633,7 +634,7 @@ Additionally, the following restrictions are applied to the schema: These fields can only be set with specific features enabled: -- `default`: can be set for `apiextensions.k8s.io/v1` CustomResourceDefinitions. Defaulting is in GA since 1.17 (beta since 1.16 with the `CustomResourceDefaulting` feature gate to be enabled, which is the case automatically for many clusters for beta features). Compare [Validation Schema Defaulting](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting). +- `default`: can be set for `apiextensions.k8s.io/v1` CustomResourceDefinitions. Defaulting is in GA since 1.17 (beta since 1.16 with the `CustomResourceDefaulting` feature gate to be enabled, which is the case automatically for many clusters for beta features). Compare [Validation Schema Defaulting](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting). {{< note >}} Compare with [structural schemas](#specifying-a-structural-schema) for further restriction required for certain CustomResourceDefinition features. @@ -1448,13 +1449,13 @@ NAME AGE crontabs/my-new-cron-object 3s ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * See [CustomResourceDefinition](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1-apiextensions-k8s-io). -* Serve [multiple versions](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/) of a +* Serve [multiple versions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/) of a CustomResourceDefinition. -{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/tasks/access-kubernetes-api/http-proxy-access-api.md b/content/en/docs/tasks/extend-kubernetes/http-proxy-access-api.md similarity index 90% rename from content/en/docs/tasks/access-kubernetes-api/http-proxy-access-api.md rename to content/en/docs/tasks/extend-kubernetes/http-proxy-access-api.md index be282a29c1..dd80c8c349 100644 --- a/content/en/docs/tasks/access-kubernetes-api/http-proxy-access-api.md +++ b/content/en/docs/tasks/extend-kubernetes/http-proxy-access-api.md @@ -1,14 +1,15 @@ --- title: Use an HTTP Proxy to Access the Kubernetes API -content_template: templates/task +content_type: task weight: 40 --- -{{% capture overview %}} + This page shows how to use an HTTP proxy to access the Kubernetes API. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} @@ -19,9 +20,7 @@ a Hello world application by entering this command: kubectl run node-hello --image=gcr.io/google-samples/node-hello:1.0 --port=8080 ``` -{{% /capture %}} - -{{% capture steps %}} + ## Using kubectl to start a proxy server @@ -81,10 +80,6 @@ The output should look similar to this: ... } -{{% /capture %}} +## {{% heading "whatsnext" %}} -{{% capture whatsnext %}} Learn more about [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands#proxy). -{{% /capture %}} - - diff --git a/content/en/docs/tasks/access-kubernetes-api/setup-extension-api-server.md b/content/en/docs/tasks/extend-kubernetes/setup-extension-api-server.md similarity index 70% rename from content/en/docs/tasks/access-kubernetes-api/setup-extension-api-server.md rename to content/en/docs/tasks/extend-kubernetes/setup-extension-api-server.md index 71c6059eec..626ddcab5c 100644 --- a/content/en/docs/tasks/access-kubernetes-api/setup-extension-api-server.md +++ b/content/en/docs/tasks/extend-kubernetes/setup-extension-api-server.md @@ -1,34 +1,35 @@ --- -title: Setup an Extension API Server +title: Set up an Extension API Server reviewers: - lavalamp - cheftako - chenopis -content_template: templates/task +content_type: task weight: 15 --- -{{% capture overview %}} + -Setting up an extension API server to work the aggregation layer allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs. +Setting up an extension API server to work with the aggregation layer allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -* You must [configure the aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) and enable the apiserver flags. +* You must [configure the aggregation layer](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) and enable the apiserver flags. -{{% /capture %}} -{{% capture steps %}} + + ## Setup an extension api-server to work with the aggregation layer The following steps describe how to set up an extension-apiserver *at a high level*. These steps apply regardless if you're using YAML configs or using APIs. An attempt is made to specifically identify any differences between the two. For a concrete example of how they can be implemented using YAML configs, you can look at the [sample-apiserver](https://github.com/kubernetes/sample-apiserver/blob/master/README.md) in the Kubernetes repo. -Alternatively, you can use an existing 3rd party solution, such as [apiserver-builder](https://github.com/Kubernetes-incubator/apiserver-builder/blob/master/README.md), which should generate a skeleton and automate all of the following steps for you. +Alternatively, you can use an existing 3rd party solution, such as [apiserver-builder](https://github.com/kubernetes-sigs/apiserver-builder-alpha/blob/master/README.md), which should generate a skeleton and automate all of the following steps for you. 1. Make sure the APIService API is enabled (check `--runtime-config`). It should be on by default, unless it's been deliberately turned off in your cluster. 1. You may need to make an RBAC rule allowing you to add APIService objects, or get your cluster administrator to make one. (Since API extensions affect the entire cluster, it is not recommended to do testing/development/debug of an API extension in a live cluster.) @@ -44,17 +45,13 @@ Alternatively, you can use an existing 3rd party solution, such as [apiserver-bu 1. Create a Kubernetes cluster role binding from the service account in your namespace to the `system:auth-delegator` cluster role to delegate auth decisions to the Kubernetes core API server. 1. Create a Kubernetes role binding from the service account in your namespace to the `extension-apiserver-authentication-reader` role. This allows your extension api-server to access the `extension-apiserver-authentication` configmap. 1. Create a Kubernetes apiservice. The CA cert above should be base64 encoded, stripped of new lines and used as the spec.caBundle in the apiservice. This should not be namespaced. If using the [kube-aggregator API](https://github.com/kubernetes/kube-aggregator/), only pass in the PEM encoded CA bundle because the base 64 encoding is done for you. -1. Use kubectl to get your resource. It should return "No resources found." Which means that everything worked but you currently have no objects of that resource type created yet. - -{{% /capture %}} - -{{% capture whatsnext %}} - -* If you haven't already, [configure the aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) and enable the apiserver flags. -* For a high level overview, see [Extending the Kubernetes API with the aggregation layer](/docs/concepts/api-extension/apiserver-aggregation). -* Learn how to [Extend the Kubernetes API Using Custom Resource Definitions](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/). - -{{% /capture %}} +1. Use kubectl to get your resource. When run, kubectl should return "No resources found.". This message +indicates that everything worked but you currently have no objects of that resource type created. +## {{% heading "whatsnext" %}} + +* Walk through the steps to [configure the API aggregation layer](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) and enable the apiserver flags. +* For a high level overview, see [Extending the Kubernetes API with the aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/). +* Learn how to [Extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/). diff --git a/content/en/docs/tasks/setup-konnectivity/setup-konnectivity.md b/content/en/docs/tasks/extend-kubernetes/setup-konnectivity.md similarity index 61% rename from content/en/docs/tasks/setup-konnectivity/setup-konnectivity.md rename to content/en/docs/tasks/extend-kubernetes/setup-konnectivity.md index b5dbd05215..da9dabb135 100644 --- a/content/en/docs/tasks/setup-konnectivity/setup-konnectivity.md +++ b/content/en/docs/tasks/extend-kubernetes/setup-konnectivity.md @@ -1,40 +1,39 @@ --- title: Set up Konnectivity service -content_template: templates/task +content_type: task weight: 70 --- -{{% capture overview %}} + -The Konnectivity service provides TCP level proxy for the Master → Cluster +The Konnectivity service provides a TCP level proxy for the control plane to cluster communication. -{{% /capture %}} - -{{% capture prerequisites %}} +## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} -{{% /capture %}} - -{{% capture steps %}} + ## Configure the Konnectivity service -First, you need to configure the API Server to use the Konnectivity service -to direct its network traffic to cluster nodes: - -1. Set the `--egress-selector-config-file` flag of the API Server, it is the -path to the API Server egress configuration file. -1. At the path, create a configuration file. For example, +The following steps require an egress configuration, for example: {{< codenew file="admin/konnectivity/egress-selector-configuration.yaml" >}} +You need to configure the API Server to use the Konnectivity service +and direct the network traffic to the cluster nodes: + +1. Create an egress configuration file such as `admin/konnectivity/egress-selector-configuration.yaml`. +1. Set the `--egress-selector-config-file` flag of the API Server to the path of +your API Server egress configuration file. + Next, you need to deploy the Konnectivity server and agents. [kubernetes-sigs/apiserver-network-proxy](https://github.com/kubernetes-sigs/apiserver-network-proxy) is a reference implementation. -Deploy the Konnectivity server on your master node. The provided yaml assumes +Deploy the Konnectivity server on your control plane node. The provided +`konnectivity-server.yaml` manifest assumes that the Kubernetes components are deployed as a {{< glossary_tooltip text="static Pod" term_id="static-pod" >}} in your cluster. If not, you can deploy the Konnectivity server as a DaemonSet. @@ -48,5 +47,3 @@ Then deploy the Konnectivity agents in your cluster: Last, if RBAC is enabled in your cluster, create the relevant RBAC rules: {{< codenew file="admin/konnectivity/konnectivity-rbac.yaml" >}} - -{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/tasks/inject-data-application/_index.md b/content/en/docs/tasks/inject-data-application/_index.md index f7f765f259..af98de866d 100755 --- a/content/en/docs/tasks/inject-data-application/_index.md +++ b/content/en/docs/tasks/inject-data-application/_index.md @@ -1,5 +1,6 @@ --- title: "Inject Data Into Applications" +description: Specify configuration and other data for the Pods that run your workload. weight: 30 --- diff --git a/content/en/docs/tasks/inject-data-application/define-command-argument-container.md b/content/en/docs/tasks/inject-data-application/define-command-argument-container.md index 66ebd69c13..faaffc52a2 100644 --- a/content/en/docs/tasks/inject-data-application/define-command-argument-container.md +++ b/content/en/docs/tasks/inject-data-application/define-command-argument-container.md @@ -1,25 +1,26 @@ --- title: Define a Command and Arguments for a Container -content_template: templates/task +content_type: task weight: 10 --- -{{% capture overview %}} + This page shows how to define commands and arguments when you run a container in a {{< glossary_tooltip term_id="pod" >}}. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Define a command and arguments when you create a Pod @@ -145,14 +146,15 @@ Here are some examples: | `[/ep-1]` | `[foo bar]` | `[/ep-2]` | `[zoo boo]` | `[ep-2 zoo boo]` | -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [configuring pods and containers](/docs/tasks/). * Learn more about [running commands in a container](/docs/tasks/debug-application-cluster/get-shell-running-container/). * See [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core). -{{% /capture %}} + diff --git a/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md index 5dd5aa92e0..d75d930c56 100644 --- a/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md +++ b/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md @@ -1,25 +1,26 @@ --- title: Define Environment Variables for a Container -content_template: templates/task +content_type: task weight: 20 --- -{{% capture overview %}} + This page shows how to define environment variables for a container in a Kubernetes Pod. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} -{{% /capture %}} -{{% capture steps %}} + + ## Define an environment variable for a container @@ -84,6 +85,11 @@ The environment variables set using the `env` or `envFrom` field override any environment variables specified in the container image. {{< /note >}} +{{< note >}} +The environment variables can reference each other, and cycles are possible, +pay attention to the order before using +{{< /note >}} + ## Using environment variables inside of your config Environment variables that you define in a Pod's configuration can be used @@ -117,12 +123,13 @@ spec: Upon creation, the command `echo Warm greetings to The Most Honorable Kubernetes` is run on the container. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/). * Learn about [using secrets as environment variables](/docs/user-guide/secrets/#using-secrets-as-environment-variables). * See [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core). -{{% /capture %}} + diff --git a/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md index 2fb15aa3b2..40e74d36b1 100644 --- a/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md +++ b/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -1,24 +1,21 @@ --- title: Distribute Credentials Securely Using Secrets -content_template: templates/task +content_type: task weight: 50 min-kubernetes-server-version: v1.6 --- -{{% capture overview %}} + This page shows how to securely inject sensitive data, such as passwords and encryption keys, into Pods. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} -{{% /capture %}} - -{{% capture steps %}} - -## Convert your secret data to a base-64 representation +### Convert your secret data to a base-64 representation Suppose you want to have two pieces of secret data: a username `my-app` and a password `39528$vdg7Jb`. First, use a base64 encoding tool to convert your username and password to a base64 representation. Here's an example using the commonly available base64 program: @@ -35,6 +32,8 @@ and the base-64 representation of your password is `Mzk1MjgkdmRnN0pi`. Use a local tool trusted by your OS to decrease the security risks of external tools. {{< /caution >}} + + ## Create a Secret Here is a configuration file you can use to create a Secret that holds your @@ -83,15 +82,19 @@ username and password: username: 7 bytes ``` -{{< note >}} -If you want to skip the Base64 encoding step, you can create a Secret -by using the `kubectl create secret` command: -{{< /note >}} +### Create a Secret directly with kubectl + +If you want to skip the Base64 encoding step, you can create the +same Secret using the `kubectl create secret` command. For example: ```shell -kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb' +kubectl create secret generic test-secret --from-literal='username=my-app' --from-literal='password=39528$vdg7Jb' ``` +This is more convenient. The detailed approach shown earlier runs +through each step explicitly to demonstrate what is happening. + + ## Create a Pod that has access to the secret data through a Volume Here is a configuration file you can use to create a Pod: @@ -100,52 +103,51 @@ Here is a configuration file you can use to create a Pod: 1. Create the Pod: - ```shell - kubectl apply -f https://k8s.io/examples/pods/inject/secret-pod.yaml - ``` + ```shell + kubectl apply -f https://k8s.io/examples/pods/inject/secret-pod.yaml + ``` 1. Verify that your Pod is running: - ```shell - kubectl get pod secret-test-pod - ``` + ```shell + kubectl get pod secret-test-pod + ``` - Output: - ```shell - NAME READY STATUS RESTARTS AGE - secret-test-pod 1/1 Running 0 42m - ``` + Output: + ``` + NAME READY STATUS RESTARTS AGE + secret-test-pod 1/1 Running 0 42m + ``` 1. Get a shell into the Container that is running in your Pod: - ```shell - kubectl exec -it secret-test-pod -- /bin/bash - ``` + ```shell + kubectl exec -i -t secret-test-pod -- /bin/bash + ``` 1. The secret data is exposed to the Container through a Volume mounted under -`/etc/secret-volume`. In your shell, go to the directory where the secret data -is exposed: - ```shell - root@secret-test-pod:/# cd /etc/secret-volume - ``` +`/etc/secret-volume`. -1. In your shell, list the files in the `/etc/secret-volume` directory: - ```shell - root@secret-test-pod:/etc/secret-volume# ls - ``` - The output shows two files, one for each piece of secret data: - ```shell - password username - ``` + In your shell, list the files in the `/etc/secret-volume` directory: + ```shell + # Run this in the shell inside the container + ls /etc/secret-volume + ``` + The output shows two files, one for each piece of secret data: + ``` + password username + ``` 1. In your shell, display the contents of the `username` and `password` files: - ```shell - root@secret-test-pod:/etc/secret-volume# cat username; echo; cat password; echo - ``` - The output is your username and password: - ```shell - my-app - 39528$vdg7Jb - ``` + ```shell + # Run this in the shell inside the container + echo "$( cat /etc/secret-volume/username )" + echo "$( cat /etc/secret-volume/password )" + ``` + The output is your username and password: + ``` + my-app + 39528$vdg7Jb + ``` ## Define container environment variables using Secret data @@ -170,13 +172,13 @@ is exposed: * In your shell, display the content of `SECRET_USERNAME` container environment variable ```shell - kubectl exec -it env-single-secret -- /bin/sh -c 'echo $SECRET_USERNAME' + kubectl exec -i -t env-single-secret -- /bin/sh -c 'echo $SECRET_USERNAME' ``` The output is - ```shell - backend-admin - ``` + ``` + backend-admin + ``` ### Define container environment variables with data from multiple Secrets @@ -200,10 +202,10 @@ is exposed: * In your shell, display the container environment variables ```shell - kubectl exec -it envvars-multiple-secrets -- /bin/sh -c 'env | grep _USERNAME' + kubectl exec -i -t envvars-multiple-secrets -- /bin/sh -c 'env | grep _USERNAME' ``` The output is - ```shell + ``` DB_USERNAME=db-admin BACKEND_USERNAME=backend-admin ``` @@ -233,28 +235,23 @@ This functionality is available in Kubernetes v1.6 and later. * In your shell, display `username` and `password` container environment variables - ````shell - kubectl exec -it envfrom-secret -- /bin/sh -c 'echo "username: $username\npassword: $password"' - ```` + ```shell + kubectl exec -i -t envfrom-secret -- /bin/sh -c 'echo "username: $username\npassword: $password\n"' + ``` The output is - ````shell + ``` username: my-app password: 39528$vdg7Jb - ```` + ``` -{{% /capture %}} - -{{% capture whatsnext %}} - -* Learn more about [Secrets](/docs/concepts/configuration/secret/). -* Learn about [Volumes](/docs/concepts/storage/volumes/). - -### Reference +### References * [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core) * [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core) * [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) -{{% /capture %}} +## {{% heading "whatsnext" %}} +* Learn more about [Secrets](/docs/concepts/configuration/secret/). +* Learn about [Volumes](/docs/concepts/storage/volumes/). diff --git a/content/en/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md b/content/en/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md index a24aba65b6..4ab41f2a23 100644 --- a/content/en/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md +++ b/content/en/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md @@ -1,25 +1,26 @@ --- title: Expose Pod Information to Containers Through Files -content_template: templates/task +content_type: task weight: 40 --- -{{% capture overview %}} + This page shows how a Pod can use a DownwardAPIVolumeFile to expose information about itself to Containers running in the Pod. A DownwardAPIVolumeFile can expose Pod fields and Container fields. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## The Downward API @@ -189,9 +190,9 @@ In your shell, view the `cpu_limit` file: You can use similar commands to view the `cpu_request`, `mem_limit` and `mem_request` files. -{{% /capture %}} -{{% capture discussion %}} + + ## Capabilities of the Downward API @@ -249,10 +250,11 @@ application, but that is tedious and error prone, and it violates the goal of lo coupling. A better option would be to use the Pod's name as an identifier, and inject the Pod's name into the well-known environment variable. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) * [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core) @@ -260,7 +262,7 @@ inject the Pod's name into the well-known environment variable. * [DownwardAPIVolumeFile](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core) * [ResourceFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core) -{{% /capture %}} + diff --git a/content/en/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md b/content/en/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md index c23b3ba75a..2b59921c6e 100644 --- a/content/en/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md +++ b/content/en/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md @@ -1,26 +1,27 @@ --- title: Expose Pod Information to Containers Through Environment Variables -content_template: templates/task +content_type: task weight: 30 --- -{{% capture overview %}} + This page shows how a Pod can use environment variables to expose information about itself to Containers running in the Pod. Environment variables can expose Pod fields and Container fields. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## The Downward API @@ -154,9 +155,10 @@ The output shows the values of selected environment variables: 67108864 ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [Defining Environment Variables for a Container](/docs/tasks/inject-data-application/define-environment-variable-container/) * [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) @@ -166,5 +168,5 @@ The output shows the values of selected environment variables: * [ObjectFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#objectfieldselector-v1-core) * [ResourceFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core) -{{% /capture %}} + diff --git a/content/en/docs/tasks/inject-data-application/podpreset.md b/content/en/docs/tasks/inject-data-application/podpreset.md index dcf159acf5..6533629ce4 100644 --- a/content/en/docs/tasks/inject-data-application/podpreset.md +++ b/content/en/docs/tasks/inject-data-application/podpreset.md @@ -3,26 +3,27 @@ reviewers: - jessfraz title: Inject Information into Pods Using a PodPreset min-kubernetes-server-version: v1.6 -content_template: templates/task +content_type: task weight: 60 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.6" state="alpha" >}} This page shows how to use PodPreset objects to inject information like {{< glossary_tooltip text="Secrets" term_id="secret" >}}, volume mounts, and {{< glossary_tooltip text="environment variables" term_id="container-env-variables" >}} into Pods at creation time. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one using [Minikube](/docs/setup/learning-environment/minikube/). Make sure that you have [enabled PodPreset](/docs/concepts/workloads/pods/podpreset/#enable-pod-preset) in your cluster. -{{% /capture %}} -{{% capture steps %}} + + ## Use Pod presets to inject environment variables and volumes @@ -321,4 +322,4 @@ The output shows that the PodPreset was deleted: podpreset "allow-database" deleted ``` -{{% /capture %}} + diff --git a/content/en/docs/tasks/job/_index.md b/content/en/docs/tasks/job/_index.md index 1948d33fc5..9e41e241c1 100644 --- a/content/en/docs/tasks/job/_index.md +++ b/content/en/docs/tasks/job/_index.md @@ -1,5 +1,6 @@ --- title: "Run Jobs" +description: Run Jobs using parallel processing. weight: 50 --- diff --git a/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md b/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md index ae5b6633ad..e5f0d3a6b7 100644 --- a/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md +++ b/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md @@ -3,11 +3,11 @@ title: Running Automated Tasks with a CronJob min-kubernetes-server-version: v1.8 reviewers: - chenopis -content_template: templates/task +content_type: task weight: 10 --- -{{% capture overview %}} + You can use a {{< glossary_tooltip text="CronJob" term_id="cronjob" >}} to run {{< glossary_tooltip text="Jobs" term_id="job" >}} on a time-based schedule. These automated jobs run like [Cron](https://en.wikipedia.org/wiki/Cron) tasks on a Linux or UNIX system. @@ -21,15 +21,16 @@ Therefore, jobs should be idempotent. For more limitations, see [CronJobs](/docs/concepts/workloads/controllers/cron-jobs). -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * {{< include "task-tutorial-prereqs.md" >}} -{{% /capture %}} -{{% capture steps %}} + + ## Creating a Cron Job @@ -157,8 +158,8 @@ A question mark (`?`) in the schedule has the same meaning as an asterisk `*`, t ### Job Template The `.spec.jobTemplate` is the template for the job, and it is required. -It has exactly the same schema as a [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/), except that it is nested and does not have an `apiVersion` or `kind`. -For information about writing a job `.spec`, see [Writing a Job Spec](/docs/concepts/workloads/controllers/jobs-run-to-completion/#writing-a-job-spec). +It has exactly the same schema as a [Job](/docs/concepts/workloads/controllers/job/), except that it is nested and does not have an `apiVersion` or `kind`. +For information about writing a job `.spec`, see [Writing a Job Spec](/docs/concepts/workloads/controllers/job/#writing-a-job-spec). ### Starting Deadline @@ -207,4 +208,4 @@ The `.spec.successfulJobsHistoryLimit` and `.spec.failedJobsHistoryLimit` fields These fields specify how many completed and failed jobs should be kept. By default, they are set to 3 and 1 respectively. Setting a limit to `0` corresponds to keeping none of the corresponding kind of jobs after they finish. -{{% /capture %}} + diff --git a/content/en/docs/tasks/job/coarse-parallel-processing-work-queue.md b/content/en/docs/tasks/job/coarse-parallel-processing-work-queue.md index 707c5b9850..346fbdda8d 100644 --- a/content/en/docs/tasks/job/coarse-parallel-processing-work-queue.md +++ b/content/en/docs/tasks/job/coarse-parallel-processing-work-queue.md @@ -1,12 +1,12 @@ --- title: Coarse Parallel Processing Using a Work Queue min-kubernetes-server-version: v1.8 -content_template: templates/task +content_type: task weight: 30 --- -{{% capture overview %}} + In this example, we will run a Kubernetes Job with multiple parallel worker processes. @@ -23,19 +23,20 @@ Here is an overview of the steps in this example: 1. **Start a Job that works on tasks from the queue**. The Job starts several pods. Each pod takes one task from the message queue, processes it, and repeats until the end of the queue is reached. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + Be familiar with the basic, non-parallel, use of [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/). {{< include "task-tutorial-prereqs.md" >}} -{{% /capture %}} -{{% capture steps %}} + + ## Starting a message queue service @@ -292,9 +293,9 @@ Events: All our pods succeeded. Yay. -{{% /capture %}} -{{% capture discussion %}} + + ## Alternatives @@ -331,4 +332,4 @@ exits with success, or if the node crashes before the kubelet is able to post th back to the api-server, then the Job will not appear to be complete, even though all items in the queue have been processed. -{{% /capture %}} + diff --git a/content/en/docs/tasks/job/fine-parallel-processing-work-queue.md b/content/en/docs/tasks/job/fine-parallel-processing-work-queue.md index 26fbbacaa7..f502113c8f 100644 --- a/content/en/docs/tasks/job/fine-parallel-processing-work-queue.md +++ b/content/en/docs/tasks/job/fine-parallel-processing-work-queue.md @@ -1,11 +1,11 @@ --- title: Fine Parallel Processing Using a Work Queue -content_template: templates/task +content_type: task min-kubernetes-server-version: v1.8 weight: 40 --- -{{% capture overview %}} + In this example, we will run a Kubernetes Job with multiple parallel worker processes in a given pod. @@ -25,23 +25,24 @@ Here is an overview of the steps in this example: 1. **Start a Job that works on tasks from the queue**. The Job starts several pods. Each pod takes one task from the message queue, processes it, and repeats until the end of the queue is reached. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} -{{% /capture %}} -{{% capture steps %}} + + Be familiar with the basic, non-parallel, use of [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/). -{{% /capture %}} -{{% capture steps %}} + + ## Starting Redis @@ -226,9 +227,9 @@ Working on lemon As you can see, one of our pods worked on several work units. -{{% /capture %}} -{{% capture discussion %}} + + ## Alternatives @@ -240,4 +241,4 @@ consider running your background workers with a `ReplicaSet` instead, and consider running a background processing library such as [https://github.com/resque/resque](https://github.com/resque/resque). -{{% /capture %}} + diff --git a/content/en/docs/tasks/job/parallel-processing-expansion.md b/content/en/docs/tasks/job/parallel-processing-expansion.md index e2d0975a70..3477be2650 100644 --- a/content/en/docs/tasks/job/parallel-processing-expansion.md +++ b/content/en/docs/tasks/job/parallel-processing-expansion.md @@ -1,11 +1,11 @@ --- title: Parallel Processing using Expansions -content_template: templates/task +content_type: task min-kubernetes-server-version: v1.8 weight: 20 --- -{{% capture overview %}} + This task demonstrates running multiple {{< glossary_tooltip text="Jobs" term_id="job" >}} based on a common template. You can use this approach to process batches of work in @@ -16,9 +16,10 @@ The sample Jobs process each item simply by printing a string then pausing. See [using Jobs in real workloads](#using-jobs-in-real-workloads) to learn about how this pattern fits more realistic use cases. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + You should be familiar with the basic, non-parallel, use of [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/). @@ -35,10 +36,10 @@ Once you have Python set up, you can install Jinja2 by running: ```shell pip install --user jinja2 ``` -{{% /capture %}} -{{% capture steps %}} + + ## Create Jobs based on a template @@ -252,8 +253,8 @@ Kubernetes accepts and runs the Jobs you created. kubectl delete job -l jobgroup=jobexample ``` -{{% /capture %}} -{{% capture discussion %}} + + ## Using Jobs in real workloads @@ -310,4 +311,4 @@ objects. You could also consider writing your own [controller](/docs/concepts/architecture/controller/) to manage Job objects automatically. -{{% /capture %}} + diff --git a/content/en/docs/tasks/manage-daemon/_index.md b/content/en/docs/tasks/manage-daemon/_index.md index 1cdbf06368..2b63e873ba 100755 --- a/content/en/docs/tasks/manage-daemon/_index.md +++ b/content/en/docs/tasks/manage-daemon/_index.md @@ -1,5 +1,6 @@ --- title: "Manage Cluster Daemons" +description: Perform common tasks for managing a DaemonSet, such as performing a rolling update. weight: 130 --- diff --git a/content/en/docs/tasks/manage-daemon/rollback-daemon-set.md b/content/en/docs/tasks/manage-daemon/rollback-daemon-set.md index 4b1d424066..05e8060cc9 100644 --- a/content/en/docs/tasks/manage-daemon/rollback-daemon-set.md +++ b/content/en/docs/tasks/manage-daemon/rollback-daemon-set.md @@ -2,30 +2,26 @@ reviewers: - janetkuo title: Perform a Rollback on a DaemonSet -content_template: templates/task +content_type: task weight: 20 +min-kubernetes-server-version: 1.7 --- -{{% capture overview %}} + -This page shows how to perform a rollback on a DaemonSet. - -{{% /capture %}} +This page shows how to perform a rollback on a {{< glossary_tooltip term_id="daemonset" >}}. -{{% capture prerequisites %}} +## {{% heading "prerequisites" %}} -* The DaemonSet rollout history and DaemonSet rollback features are only - supported in `kubectl` in Kubernetes version 1.7 or later. -* Make sure you know how to [perform a rolling update on a - DaemonSet](/docs/tasks/manage-daemon/update-daemon-set/). +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} +You should already know how to [perform a rolling update on a + DaemonSet](/docs/tasks/manage-daemon/update-daemon-set/). + -{{% capture steps %}} - -## Performing a Rollback on a DaemonSet +## Performing a rollback on a DaemonSet ### Step 1: Find the DaemonSet revision you want to roll back to @@ -39,7 +35,7 @@ kubectl rollout history daemonset This returns a list of DaemonSet revisions: -```shell +``` daemonsets "" REVISION CHANGE-CAUSE 1 ... @@ -59,17 +55,17 @@ kubectl rollout history daemonset --revision=1 This returns the details of that revision: -```shell +``` daemonsets "" with revision #1 Pod Template: Labels: foo=bar Containers: app: - Image: ... - Port: ... - Environment: ... - Mounts: ... -Volumes: ... + Image: ... + Port: ... + Environment: ... + Mounts: ... +Volumes: ... ``` ### Step 2: Roll back to a specific revision @@ -81,40 +77,39 @@ kubectl rollout undo daemonset --to-revision= If it succeeds, the command returns: -```shell +``` daemonset "" rolled back ``` -If `--to-revision` flag is not specified, the last revision will be picked. +{{< note >}} +If `--to-revision` flag is not specified, kubectl picks the most recent revision. +{{< /note >}} ### Step 3: Watch the progress of the DaemonSet rollback `kubectl rollout undo daemonset` tells the server to start rolling back the -DaemonSet. The real rollback is done asynchronously on the server side. +DaemonSet. The real rollback is done asynchronously inside the cluster +{{< glossary_tooltip term_id="control-plane" text="control plane" >}}. To watch the progress of the rollback: -```shell -kubectl rollout status ds/ +```shell +kubectl rollout status ds/ ``` -When the rollback is complete, the output is similar to this: +When the rollback is complete, the output is similar to: -```shell +``` daemonset "" successfully rolled out ``` -{{% /capture %}} + -{{% capture discussion %}} - -## Understanding DaemonSet Revisions +## Understanding DaemonSet revisions In the previous `kubectl rollout history` step, you got a list of DaemonSet -revisions. Each revision is stored in a resource named `ControllerRevision`. -`ControllerRevision` is a resource only available in Kubernetes release 1.7 or -later. +revisions. Each revision is stored in a resource named ControllerRevision. To see what is stored in each revision, find the DaemonSet revision raw resources: @@ -123,20 +118,19 @@ resources: kubectl get controllerrevision -l = ``` -This returns a list of `ControllerRevisions`: +This returns a list of ControllerRevisions: -```shell +``` NAME CONTROLLER REVISION AGE - DaemonSet/ 1 1h - DaemonSet/ 2 1h ``` -Each `ControllerRevision` stores the annotations and template of a DaemonSet -revision. The name of a ControllerRevision object must be a valid -[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). +Each ControllerRevision stores the annotations and template of a DaemonSet +revision. -`kubectl rollout undo` takes a specific `ControllerRevision` and replaces -DaemonSet template with the template stored in the `ControllerRevision`. +`kubectl rollout undo` takes a specific ControllerRevision and replaces +DaemonSet template with the template stored in the ControllerRevision. `kubectl rollout undo` is equivalent to updating DaemonSet template to a previous revision through other commands, such as `kubectl edit` or `kubectl apply`. @@ -144,16 +138,12 @@ apply`. {{< note >}} DaemonSet revisions only roll forward. That is to say, after a rollback completes, the revision number (`.revision` field) of the -`ControllerRevision` being rolled back to will advance. For example, if you +ControllerRevision being rolled back to will advance. For example, if you have revision 1 and 2 in the system, and roll back from revision 2 to revision -1, the `ControllerRevision` with `.revision: 1` will become `.revision: 3`. +1, the ControllerRevision with `.revision: 1` will become `.revision: 3`. {{< /note >}} ## Troubleshooting * See [troubleshooting DaemonSet rolling update](/docs/tasks/manage-daemon/update-daemon-set/#troubleshooting). - -{{% /capture %}} - - diff --git a/content/en/docs/tasks/manage-daemon/update-daemon-set.md b/content/en/docs/tasks/manage-daemon/update-daemon-set.md index 8e32763e01..b9168ed098 100644 --- a/content/en/docs/tasks/manage-daemon/update-daemon-set.md +++ b/content/en/docs/tasks/manage-daemon/update-daemon-set.md @@ -2,25 +2,26 @@ reviewers: - janetkuo title: Perform a Rolling Update on a DaemonSet -content_template: templates/task +content_type: task weight: 10 --- -{{% capture overview %}} + This page shows how to perform a rolling update on a DaemonSet. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * The DaemonSet rolling update feature is only supported in Kubernetes version 1.6 or later. -{{% /capture %}} -{{% capture steps %}} + + ## DaemonSet Update Strategy @@ -190,13 +191,14 @@ Delete DaemonSet from a namespace : kubectl delete ds fluentd-elasticsearch -n kube-system ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * See [Task: Performing a rollback on a DaemonSet](/docs/tasks/manage-daemon/rollback-daemon-set/) * See [Concepts: Creating a DaemonSet to adopt existing DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/) -{{% /capture %}} + diff --git a/content/en/docs/tasks/manage-gpus/scheduling-gpus.md b/content/en/docs/tasks/manage-gpus/scheduling-gpus.md index 4c0b9f9bc3..4f8fc434f9 100644 --- a/content/en/docs/tasks/manage-gpus/scheduling-gpus.md +++ b/content/en/docs/tasks/manage-gpus/scheduling-gpus.md @@ -1,11 +1,12 @@ --- reviewers: - vishh -content_template: templates/concept +content_type: concept title: Schedule GPUs +description: Configure and schedule GPUs for use as a resource by nodes in a cluster. --- -{{% capture overview %}} + {{< feature-state state="beta" for_k8s_version="v1.10" >}} @@ -15,10 +16,10 @@ Kubernetes includes **experimental** support for managing AMD and NVIDIA GPUs This page describes how users can consume GPUs across different Kubernetes versions and the current limitations. -{{% /capture %}} -{{% capture body %}} + + ## Using device plugins @@ -98,7 +99,7 @@ has the following requirements: - Kubelet must use Docker as its container runtime - `nvidia-container-runtime` must be configured as the [default runtime](https://github.com/NVIDIA/k8s-device-plugin#preparing-your-gpu-nodes) for Docker, instead of runc. -- The version of the NVIDIA drivers must match the constraint ~= 361.93 +- The version of the NVIDIA drivers must match the constraint ~= 384.81. To deploy the NVIDIA device plugin once your cluster is running and the above requirements are satisfied: @@ -216,4 +217,4 @@ spec: This will ensure that the Pod will be scheduled to a node that has the GPU type you specified. -{{% /capture %}} + diff --git a/content/en/docs/tasks/manage-hugepages/scheduling-hugepages.md b/content/en/docs/tasks/manage-hugepages/scheduling-hugepages.md index ad6b969c87..a349f123aa 100644 --- a/content/en/docs/tasks/manage-hugepages/scheduling-hugepages.md +++ b/content/en/docs/tasks/manage-hugepages/scheduling-hugepages.md @@ -2,19 +2,18 @@ reviewers: - derekwaynecarr title: Manage HugePages -content_template: templates/task +content_type: task +description: Configure and manage huge pages as a schedulable resource in a cluster. --- -{{% capture overview %}} + {{< feature-state state="stable" >}} Kubernetes supports the allocation and consumption of pre-allocated huge pages -by applications in a Pod as a **GA** feature. This page describes how users -can consume huge pages and the current limitations. +by applications in a Pod. This page describes how users can consume huge pages. -{{% /capture %}} +## {{% heading "prerequisites" %}} -{{% capture prerequisites %}} 1. Kubernetes nodes must pre-allocate huge pages in order for the node to report its huge page capacity. A node can pre-allocate huge pages for multiple @@ -23,9 +22,9 @@ can consume huge pages and the current limitations. The nodes will automatically discover and report all huge page resources as schedulable resources. -{{% /capture %}} -{{% capture steps %}} + + ## API @@ -119,11 +118,3 @@ gate](/docs/reference/command-line-tools-reference/feature-gates/) on the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} and {{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}} (`--feature-gates=HugePageStorageMediumSize=true`). - -## Future - -- NUMA locality guarantees as a feature of quality of service. -- LimitRange support. - -{{% /capture %}} - diff --git a/content/en/docs/tasks/manage-kubernetes-objects/_index.md b/content/en/docs/tasks/manage-kubernetes-objects/_index.md index b7bbecf75d..541ca58c0c 100644 --- a/content/en/docs/tasks/manage-kubernetes-objects/_index.md +++ b/content/en/docs/tasks/manage-kubernetes-objects/_index.md @@ -1,4 +1,5 @@ --- title: "Manage Kubernetes Objects" +description: Declarative and imperative paradigms for interacting with the Kubernetes API. weight: 25 --- \ No newline at end of file diff --git a/content/en/docs/tasks/manage-kubernetes-objects/declarative-config.md b/content/en/docs/tasks/manage-kubernetes-objects/declarative-config.md index f82e54d364..308a4cf9b8 100644 --- a/content/en/docs/tasks/manage-kubernetes-objects/declarative-config.md +++ b/content/en/docs/tasks/manage-kubernetes-objects/declarative-config.md @@ -1,27 +1,28 @@ --- title: Declarative Management of Kubernetes Objects Using Configuration Files -content_template: templates/task +content_type: task weight: 10 --- -{{% capture overview %}} + Kubernetes objects can be created, updated, and deleted by storing multiple object configuration files in a directory and using `kubectl apply` to recursively create and update those objects as needed. This method retains writes made to live objects without merging the changes back into the object configuration files. `kubectl diff` also gives you a preview of what changes `apply` will make. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + Install [`kubectl`](/docs/tasks/tools/install-kubectl/). {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Trade-offs @@ -999,11 +1000,12 @@ template: controller-selector: "apps/v1/deployment/nginx" ``` -{{% capture whatsnext %}} +## {{% heading "whatsnext" %}} + * [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/) * [Imperative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/imperative-config/) * [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/) * [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) -{{% /capture %}} + diff --git a/content/en/docs/tasks/manage-kubernetes-objects/imperative-command.md b/content/en/docs/tasks/manage-kubernetes-objects/imperative-command.md index 6b1357a133..dd8b6b0f53 100644 --- a/content/en/docs/tasks/manage-kubernetes-objects/imperative-command.md +++ b/content/en/docs/tasks/manage-kubernetes-objects/imperative-command.md @@ -1,23 +1,24 @@ --- title: Managing Kubernetes Objects Using Imperative Commands -content_template: templates/task +content_type: task weight: 30 --- -{{% capture overview %}} + Kubernetes objects can quickly be created, updated, and deleted directly using imperative commands built into the `kubectl` command-line tool. This document explains how those commands are organized and how to use them to manage live objects. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + Install [`kubectl`](/docs/tasks/tools/install-kubectl/). {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Trade-offs @@ -159,13 +160,14 @@ kubectl create --edit -f /tmp/srv.yaml 1. The `kubectl create service` command creates the configuration for the Service and saves it to `/tmp/srv.yaml`. 1. The `kubectl create --edit` command opens the configuration file for editing before it creates the object. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [Managing Kubernetes Objects Using Object Configuration (Imperative)](/docs/tasks/manage-kubernetes-objects/imperative-config/) * [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tasks/manage-kubernetes-objects/declarative-config/) * [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/) * [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) -{{% /capture %}} + diff --git a/content/en/docs/tasks/manage-kubernetes-objects/imperative-config.md b/content/en/docs/tasks/manage-kubernetes-objects/imperative-config.md index ec6057cd68..97b62e6f0f 100644 --- a/content/en/docs/tasks/manage-kubernetes-objects/imperative-config.md +++ b/content/en/docs/tasks/manage-kubernetes-objects/imperative-config.md @@ -1,24 +1,25 @@ --- title: Imperative Management of Kubernetes Objects Using Configuration Files -content_template: templates/task +content_type: task weight: 40 --- -{{% capture overview %}} + Kubernetes objects can be created, updated, and deleted by using the `kubectl` command-line tool along with an object configuration file written in YAML or JSON. This document explains how to define and manage objects using configuration files. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + Install [`kubectl`](/docs/tasks/tools/install-kubectl/). {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Trade-offs @@ -142,13 +143,14 @@ template: controller-selector: "apps/v1/deployment/nginx" ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/) * [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tasks/manage-kubernetes-objects/declarative-config/) * [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/) * [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) -{{% /capture %}} + diff --git a/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md index c74374a0dc..a7d887da3b 100644 --- a/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md +++ b/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md @@ -1,10 +1,10 @@ --- title: Declarative Management of Kubernetes Objects Using Kustomize -content_template: templates/task +content_type: task weight: 20 --- -{{% capture overview %}} + [Kustomize](https://github.com/kubernetes-sigs/kustomize) is a standalone tool to customize Kubernetes objects @@ -24,17 +24,18 @@ To apply those Resources, run `kubectl apply` with `--kustomize` or `-k` flag: kubectl apply -k ``` -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + Install [`kubectl`](/docs/tasks/tools/install-kubectl/). {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Overview of Kustomize @@ -824,13 +825,14 @@ deployment.apps "dev-my-nginx" deleted | configurations | []string | Each entry in this list should resolve to a file containing [Kustomize transformer configurations](https://github.com/kubernetes-sigs/kustomize/tree/master/examples/transformerconfigs) | | crds | []string | Each entry in this list should resolve to an OpenAPI definition file for Kubernetes types | -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [Kustomize](https://github.com/kubernetes-sigs/kustomize) * [Kubectl Book](https://kubectl.docs.kubernetes.io) * [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/) * [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) -{{% /capture %}} + diff --git a/content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md b/content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md index 84f86495ae..55d9128f20 100644 --- a/content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md +++ b/content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md @@ -1,25 +1,26 @@ --- title: Update API Objects in Place Using kubectl patch description: Use kubectl patch to update Kubernetes API objects in place. Do a strategic merge patch or a JSON merge patch. -content_template: templates/task +content_type: task weight: 50 --- -{{% capture overview %}} + This task shows how to use `kubectl patch` to update an API object in place. The exercises in this task demonstrate a strategic merge patch and a JSON merge patch. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Use a strategic merge patch to update a Deployment @@ -283,6 +284,119 @@ patch-demo-1307768864-69308 1/1 Running 0 1m patch-demo-1307768864-c86dc 1/1 Running 0 1m ``` +## Use strategic merge patch to update a Deployment using the retainKeys strategy + +Here's the configuration file for a Deployment that uses the `RollingUpdate` strategy: + +{{< codenew file="application/deployment-retainkeys.yaml" >}} + +Create the deployment: + +```shell +kubectl apply -f https://k8s.io/examples/application/deployment-retainkeys.yaml +``` + +At this point, the deployment is created and is using the `RollingUpdate` strategy. + +Create a file named `patch-file-no-retainkeys.yaml` that has this content: + +```yaml +spec: + strategy: + type: Recreate +``` + +Patch your Deployment: + +{{< tabs name="kubectl_retainkeys_example" >}} +{{{< tab name="Bash" codelang="bash" >}} +kubectl patch deployment retainkeys-demo --patch "$(cat patch-file-no-retainkeys.yaml)" +{{< /tab >}} +{{< tab name="PowerShell" codelang="posh" >}} +kubectl patch deployment retainkeys-demo --patch $(Get-Content patch-file-no-retainkeys.yaml -Raw) +{{< /tab >}}} +{{< /tabs >}} + +In the output, you can see that it is not possible to set `type` as `Recreate` when a value is defined for `spec.strategy.rollingUpdate`: + +```shell +The Deployment "retainkeys-demo" is invalid: spec.strategy.rollingUpdate: Forbidden: may not be specified when strategy `type` is 'Recreate' +``` + +The way to remove the value for `spec.strategy.rollingUpdate` when updating the value for `type` is to use the `retainKeys` strategy for the strategic merge. + +Create another file named `patch-file-retainkeys.yaml` that has this content: + +```yaml +spec: + strategy: + $retainKeys: + - type + type: Recreate +``` + +With this patch, we indicate that we want to retain only the `type` key of the `strategy` object. Thus, the `rollingUpdate` will be removed during the patch operation. + +Patch your Deployment again with this new patch: + +{{< tabs name="kubectl_retainkeys2_example" >}} +{{{< tab name="Bash" codelang="bash" >}} +kubectl patch deployment retainkeys-demo --patch "$(cat patch-file-retainkeys.yaml)" +{{< /tab >}} +{{< tab name="PowerShell" codelang="posh" >}} +kubectl patch deployment retainkeys-demo --patch $(Get-Content patch-file-retainkeys.yaml -Raw) +{{< /tab >}}} +{{< /tabs >}} + +Examine the content of the Deployment: + +```shell +kubectl get deployment retainkeys-demo --output yaml +``` + +The output shows that the strategy object in the Deployment does not contain the `rollingUpdate` key anymore: + +```shell +spec: + strategy: + type: Recreate + template: +``` + +### Notes on the strategic merge patch using the retainKeys strategy + +The patch you did in the preceding exercise is called a *strategic merge patch with retainKeys strategy*. This method introduces a new directive `$retainKeys` that has the following strategies: + +- It contains a list of strings. +- All fields needing to be preserved must be present in the `$retainKeys` list. +- The fields that are present will be merged with live object. +- All of the missing fields will be cleared when patching. +- All fields in the `$retainKeys` list must be a superset or the same as the fields present in the patch. + +The `retainKeys` strategy does not work for all objects. It only works when the value of the `patchStrategy` key in a field tag in the Kubernetes source code contains `retainKeys`. For example, the `Strategy` field of the `DeploymentSpec` struct has a `patchStrategy` of `retainKeys`: + +```go +type DeploymentSpec struct { + ... + // +patchStrategy=retainKeys + Strategy DeploymentStrategy `json:"strategy,omitempty" patchStrategy:"retainKeys" ...` +``` + +You can also see the `retainKeys` strategy in the [OpenApi spec](https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json): + +```json +"io.k8s.api.apps.v1.DeploymentSpec": { + ... + "strategy": { + "$ref": "#/definitions/io.k8s.api.apps.v1.DeploymentStrategy", + "description": "The deployment strategy to use to replace existing pods with new ones.", + "x-kubernetes-patch-strategy": "retainKeys" + }, +``` + +And you can see the `retainKeys` strategy in the +[Kubernetes API documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps). + ## Alternate forms of the kubectl patch command The `kubectl patch` command takes YAML or JSON. It can take the patch as a file or @@ -330,14 +444,15 @@ create the Deployment object. Other commands for updating API objects include and [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands/#apply). -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [Kubernetes Object Management](/docs/concepts/overview/working-with-objects/object-management/) * [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/) * [Imperative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/imperative-config/) * [Declarative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/declarative-config/) -{{% /capture %}} + diff --git a/content/en/docs/tasks/network/_index.md b/content/en/docs/tasks/network/_index.md index 86dbbc1284..0dad8191a0 100755 --- a/content/en/docs/tasks/network/_index.md +++ b/content/en/docs/tasks/network/_index.md @@ -1,5 +1,6 @@ --- -title: "Network" +title: "Networking" +description: Learn how to configure networking for your cluster. weight: 160 --- diff --git a/content/en/docs/tasks/network/validate-dual-stack.md b/content/en/docs/tasks/network/validate-dual-stack.md index 0e6d586bea..1e21af226d 100644 --- a/content/en/docs/tasks/network/validate-dual-stack.md +++ b/content/en/docs/tasks/network/validate-dual-stack.md @@ -4,14 +4,15 @@ reviewers: - khenidak min-kubernetes-server-version: v1.16 title: Validate IPv4/IPv6 dual-stack -content_template: templates/task +content_type: task --- -{{% capture overview %}} + This document shares how to validate IPv4/IPv6 dual-stack enabled Kubernetes clusters. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide Kubernetes nodes with routable IPv4/IPv6 network interfaces) * A [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) that supports dual-stack (such as Kubenet or Calico) @@ -20,9 +21,9 @@ This document shares how to validate IPv4/IPv6 dual-stack enabled Kubernetes clu {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Validate addressing @@ -158,4 +159,4 @@ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S my-service ClusterIP fe80:20d::d06b 2001:db8:f100:4002::9d37:c0d7 80:31868/TCP 30s ``` -{{% /capture %}} + diff --git a/content/en/docs/tasks/run-application/_index.md b/content/en/docs/tasks/run-application/_index.md index c9d64ac3fe..920df4098c 100755 --- a/content/en/docs/tasks/run-application/_index.md +++ b/content/en/docs/tasks/run-application/_index.md @@ -1,5 +1,6 @@ --- title: "Run Applications" +description: Run and manage both stateless and stateful applications. weight: 40 --- diff --git a/content/en/docs/tasks/run-application/configure-pdb.md b/content/en/docs/tasks/run-application/configure-pdb.md index d98538c262..8113e07128 100644 --- a/content/en/docs/tasks/run-application/configure-pdb.md +++ b/content/en/docs/tasks/run-application/configure-pdb.md @@ -1,10 +1,10 @@ --- title: Specifying a Disruption Budget for your Application -content_template: templates/task +content_type: task weight: 110 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.5" state="beta" >}} @@ -13,9 +13,10 @@ that your application experiences, allowing for higher availability while permitting the cluster administrator to manage the clusters nodes. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * You are the owner of an application running on a Kubernetes cluster that requires high availability. * You should know how to deploy [Replicated Stateless Applications](/docs/tasks/run-application/run-stateless-application-deployment/) @@ -23,9 +24,9 @@ nodes. * You should have read about [Pod Disruptions](/docs/concepts/workloads/pods/disruptions/). * You should confirm with your cluster owner or service provider that they respect Pod Disruption Budgets. -{{% /capture %}} -{{% capture steps %}} + + ## Protecting an Application with a PodDisruptionBudget @@ -34,9 +35,9 @@ nodes. 1. Create a PDB definition as a YAML file. 1. Create the PDB object from the YAML file. -{{% /capture %}} -{{% capture discussion %}} + + ## Identify an Application to Protect @@ -51,7 +52,7 @@ specified by one of the built-in Kubernetes controllers: In this case, make a note of the controller's `.spec.selector`; the same selector goes into the PDBs `.spec.selector`. -From version 1.15 PDBs support custom controllers where the [scale subresource](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#scale-subresource) is enabled. +From version 1.15 PDBs support custom controllers where the [scale subresource](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource) is enabled. You can also use PDBs with pods which are not controlled by one of the above controllers, or arbitrary groups of pods, but there are some restrictions, @@ -238,6 +239,6 @@ You can use a selector which selects a subset or superset of the pods belonging controller. However, when there are multiple PDBs in a namespace, you must be careful not to create PDBs whose selectors overlap. -{{% /capture %}} + diff --git a/content/en/docs/tasks/run-application/delete-stateful-set.md b/content/en/docs/tasks/run-application/delete-stateful-set.md index d37e3ba7a0..7a4a94fab4 100644 --- a/content/en/docs/tasks/run-application/delete-stateful-set.md +++ b/content/en/docs/tasks/run-application/delete-stateful-set.md @@ -6,23 +6,24 @@ reviewers: - janetkuo - smarterclayton title: Delete a StatefulSet -content_template: templates/task +content_type: task weight: 60 --- -{{% capture overview %}} + This task shows you how to delete a {{< glossary_tooltip term_id="StatefulSet" >}}. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * This task assumes you have an application running on your cluster represented by a StatefulSet. -{{% /capture %}} -{{% capture steps %}} + + ## Deleting a StatefulSet @@ -81,12 +82,13 @@ In the example above, the Pods have the label `app=myapp`; substitute your own l If you find that some pods in your StatefulSet are stuck in the 'Terminating' or 'Unknown' states for an extended period of time, you may need to manually intervene to forcefully delete the pods from the apiserver. This is a potentially dangerous task. Refer to [Force Delete StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/) for details. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + Learn more about [force deleting StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/). -{{% /capture %}} + diff --git a/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md index b2b364f5f9..48a61a260d 100644 --- a/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -5,22 +5,23 @@ reviewers: - foxish - smarterclayton title: Force Delete StatefulSet Pods -content_template: templates/task +content_type: task weight: 70 --- -{{% capture overview %}} + This page shows how to delete Pods which are part of a {{< glossary_tooltip text="stateful set" term_id="StatefulSet" >}}, and explains the considerations to keep in mind when doing so. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * This is a fairly advanced task and has the potential to violate some of the properties inherent to StatefulSet. * Before proceeding, make yourself familiar with the considerations enumerated below. -{{% /capture %}} -{{% capture steps %}} + + ## StatefulSet considerations @@ -74,10 +75,11 @@ kubectl patch pod -p '{"metadata":{"finalizers":null}}' Always perform force deletion of StatefulSet Pods carefully and with complete knowledge of the risks involved. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + Learn more about [debugging a StatefulSet](/docs/tasks/debug-application-cluster/debug-stateful-set/). -{{% /capture %}} + diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index cab3e0af7f..7f3b046b68 100644 --- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -5,11 +5,11 @@ reviewers: - justinsb - directxman12 title: Horizontal Pod Autoscaler Walkthrough -content_template: templates/task +content_type: task weight: 100 --- -{{% capture overview %}} + Horizontal Pod Autoscaler automatically scales the number of pods in a replication controller, deployment, replica set or stateful set based on observed CPU utilization @@ -17,11 +17,12 @@ in a replication controller, deployment, replica set or stateful set based on ob This document walks you through an example of enabling Horizontal Pod Autoscaler for the php-apache server. For more information on how Horizontal Pod Autoscaler behaves, see the [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/). -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + This example requires a running Kubernetes cluster and kubectl, version 1.2 or later. [metrics-server](https://github.com/kubernetes-incubator/metrics-server/) monitoring needs to be deployed in the cluster @@ -35,9 +36,9 @@ not related to any Kubernetes object you must have a Kubernetes cluster at versi you must be able to communicate with the API server that provides the external metrics API. See the [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) for more details. -{{% /capture %}} -{{% capture steps %}} + + ## Run & expose php-apache server @@ -181,9 +182,9 @@ Here CPU utilization dropped to 0, and so HPA autoscaled the number of replicas Autoscaling the replicas may take a few minutes. {{< /note >}} -{{% /capture %}} -{{% capture discussion %}} + + ## Autoscaling on multiple metrics and custom metrics @@ -483,4 +484,4 @@ kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml horizontalpodautoscaler.autoscaling/php-apache created ``` -{{% /capture %}} + diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md index f6852845ec..6dc61f8d4f 100644 --- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -9,11 +9,11 @@ feature: description: > Scale your application up and down with a simple command, with a UI, or automatically based on CPU usage. -content_template: templates/concept +content_type: concept weight: 90 --- -{{% capture overview %}} + The Horizontal Pod Autoscaler automatically scales the number of pods in a replication controller, deployment, replica set or stateful set based on observed CPU utilization (or, with @@ -26,10 +26,10 @@ The resource determines the behavior of the controller. The controller periodically adjusts the number of replicas in a replication controller or deployment to match the observed average CPU utilization to the target specified by user. -{{% /capture %}} -{{% capture body %}} + + ## How does the Horizontal Pod Autoscaler work? @@ -260,7 +260,7 @@ See [Support for metrics APIs](#support-for-metrics-apis) for the requirements. By default, the HorizontalPodAutoscaler controller retrieves metrics from a series of APIs. In order for it to access these APIs, cluster administrators must ensure that: -* The [API aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) is enabled. +* The [API aggregation layer](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) is enabled. * The corresponding APIs are registered: @@ -376,7 +376,7 @@ For scaling down the stabilization window is _300_ seconds(or the value of the for scaling down which allows a 100% of the currently running replicas to be removed which means the scaling target can be scaled down to the minimum allowed replicas. For scaling up there is no stabilization window. When the metrics indicate that the target should be -scaled up the target is scaled up immediately. There are 2 policies which. 4 pods or a 100% of the currently +scaled up the target is scaled up immediately. There are 2 policies where 4 pods or a 100% of the currently running replicas will be added every 15 seconds till the HPA reaches its steady state. ### Example: change downscale stabilization window @@ -431,12 +431,13 @@ behavior: selectPolicy: Disabled ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Design documentation: [Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md). * kubectl autoscale command: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale). * Usage example of [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). -{{% /capture %}} + diff --git a/content/en/docs/tasks/run-application/run-replicated-stateful-application.md b/content/en/docs/tasks/run-application/run-replicated-stateful-application.md index 7a85a74014..2a7d255c2b 100644 --- a/content/en/docs/tasks/run-application/run-replicated-stateful-application.md +++ b/content/en/docs/tasks/run-application/run-replicated-stateful-application.md @@ -7,11 +7,11 @@ reviewers: - kow3ns - smarterclayton title: Run a Replicated Stateful Application -content_template: templates/tutorial +content_type: tutorial weight: 30 --- -{{% capture overview %}} + This page shows how to run a replicated stateful application using a [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) controller. @@ -23,9 +23,10 @@ asynchronous replication. on general patterns for running stateful applications in Kubernetes. {{< /note >}} -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * {{< include "default-storage-class-prereqs.md" >}} @@ -38,18 +39,19 @@ on general patterns for running stateful applications in Kubernetes. * Some familiarity with MySQL helps, but this tutorial aims to present general patterns that should be useful for other systems. -{{% /capture %}} -{{% capture objectives %}} + +## {{% heading "objectives" %}} + * Deploy a replicated MySQL topology with a StatefulSet controller. * Send MySQL client traffic. * Observe resistance to downtime. * Scale the StatefulSet up and down. -{{% /capture %}} -{{% capture lessoncontent %}} + + ## Deploy MySQL @@ -479,9 +481,10 @@ kubectl delete pvc data-mysql-3 kubectl delete pvc data-mysql-4 ``` -{{% /capture %}} -{{% capture cleanup %}} + +## {{% heading "cleanup" %}} + 1. Cancel the `SELECT @@server_id` loop by pressing **Ctrl+C** in its terminal, or running the following from another terminal: @@ -522,9 +525,10 @@ kubectl delete pvc data-mysql-4 Some dynamic provisioners (such as those for EBS and PD) also release the underlying resources upon deleting the PersistentVolumes. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [scaling a StatefulSet](/docs/tasks/run-application/scale-stateful-set/). * Learn more about [debugging a StatefulSet](/docs/tasks/debug-application-cluster/debug-stateful-set/). * Learn more about [deleting a StatefulSet](/docs/tasks/run-application/delete-stateful-set/). @@ -532,7 +536,7 @@ kubectl delete pvc data-mysql-4 * Look in the [Helm Charts repository](https://github.com/kubernetes/charts) for other stateful application examples. -{{% /capture %}} + diff --git a/content/en/docs/tasks/run-application/run-single-instance-stateful-application.md b/content/en/docs/tasks/run-application/run-single-instance-stateful-application.md index 777265c68b..4c43948a21 100644 --- a/content/en/docs/tasks/run-application/run-single-instance-stateful-application.md +++ b/content/en/docs/tasks/run-application/run-single-instance-stateful-application.md @@ -1,37 +1,39 @@ --- title: Run a Single-Instance Stateful Application -content_template: templates/tutorial +content_type: tutorial weight: 20 --- -{{% capture overview %}} + This page shows you how to run a single-instance stateful application in Kubernetes using a PersistentVolume and a Deployment. The application is MySQL. -{{% /capture %}} -{{% capture objectives %}} + +## {{% heading "objectives" %}} + * Create a PersistentVolume referencing a disk in your environment. * Create a MySQL Deployment. * Expose MySQL to other pods in the cluster at a known DNS name. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * {{< include "default-storage-class-prereqs.md" >}} -{{% /capture %}} -{{% capture lessoncontent %}} + + ## Deploy MySQL @@ -180,10 +182,11 @@ PersistentVolume when it sees that you deleted the PersistentVolumeClaim. Some dynamic provisioners (such as those for EBS and PD) also release the underlying resource upon deleting the PersistentVolume. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [Deployment objects](/docs/concepts/workloads/controllers/deployment/). @@ -193,6 +196,6 @@ underlying resource upon deleting the PersistentVolume. * [Volumes](/docs/concepts/storage/volumes/) and [Persistent Volumes](/docs/concepts/storage/persistent-volumes/) -{{% /capture %}} + diff --git a/content/en/docs/tasks/run-application/run-stateless-application-deployment.md b/content/en/docs/tasks/run-application/run-stateless-application-deployment.md index 68d41b5a83..9e6ed4a25e 100644 --- a/content/en/docs/tasks/run-application/run-stateless-application-deployment.md +++ b/content/en/docs/tasks/run-application/run-stateless-application-deployment.md @@ -1,34 +1,36 @@ --- title: Run a Stateless Application Using a Deployment min-kubernetes-server-version: v1.9 -content_template: templates/tutorial +content_type: tutorial weight: 10 --- -{{% capture overview %}} + This page shows how to run an application using a Kubernetes Deployment object. -{{% /capture %}} -{{% capture objectives %}} + +## {{% heading "objectives" %}} + * Create an nginx deployment. * Use kubectl to list information about the deployment. * Update the deployment. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture lessoncontent %}} + + ## Creating and exploring an nginx deployment @@ -146,13 +148,14 @@ which in turn uses a ReplicaSet. Before the Deployment and ReplicaSet were added to Kubernetes, replicated applications were configured using a [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/). -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [Deployment objects](/docs/concepts/workloads/controllers/deployment/). -{{% /capture %}} + diff --git a/content/en/docs/tasks/run-application/scale-stateful-set.md b/content/en/docs/tasks/run-application/scale-stateful-set.md index 462025836d..6e34babf9d 100644 --- a/content/en/docs/tasks/run-application/scale-stateful-set.md +++ b/content/en/docs/tasks/run-application/scale-stateful-set.md @@ -8,15 +8,16 @@ reviewers: - kow3ns - smarterclayton title: Scale a StatefulSet -content_template: templates/task +content_type: task weight: 50 --- -{{% capture overview %}} + This task shows how to scale a StatefulSet. Scaling a StatefulSet refers to increasing or decreasing the number of replicas. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * StatefulSets are only available in Kubernetes version 1.5 or later. To check your version of Kubernetes, run `kubectl version`. @@ -26,9 +27,9 @@ This task shows how to scale a StatefulSet. Scaling a StatefulSet refers to incr * You should perform scaling only when you are confident that your stateful application cluster is completely healthy. -{{% /capture %}} -{{% capture steps %}} + + ## Scaling StatefulSets @@ -90,10 +91,11 @@ to reason about scaling operations at the application level in these cases, and perform scaling only when you are sure that your stateful application cluster is completely healthy. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [deleting a StatefulSet](/docs/tasks/run-application/delete-stateful-set/). -{{% /capture %}} + diff --git a/content/en/docs/tasks/service-catalog/_index.md b/content/en/docs/tasks/service-catalog/_index.md index 17bbaec3e9..77e5fa25e4 100755 --- a/content/en/docs/tasks/service-catalog/_index.md +++ b/content/en/docs/tasks/service-catalog/_index.md @@ -1,5 +1,6 @@ --- -title: "Install Service Catalog" +title: "Service Catalog" +description: Install the Service Catalog extension API. weight: 150 --- diff --git a/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md b/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md index 73268ff714..499bc1fa90 100644 --- a/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md +++ b/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md @@ -2,18 +2,19 @@ title: Install Service Catalog using Helm reviewers: - chenopis -content_template: templates/task +content_type: task --- -{{% capture overview %}} + {{< glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" >}} Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes cluster. Up to date information on this process can be found at the [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog/blob/master/docs/install.md) repo. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * Understand the key concepts of [Service Catalog](/docs/concepts/service-catalog/). * Service Catalog requires a Kubernetes cluster running version 1.7 or higher. * You must have a Kubernetes cluster with cluster DNS enabled. @@ -24,10 +25,10 @@ Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes clust * Follow the [Helm install instructions](https://helm.sh/docs/intro/install/). * If you already have an appropriate version of Helm installed, execute `helm init` to install Tiller, the server-side component of Helm. -{{% /capture %}} -{{% capture steps %}} + + ## Add the service-catalog Helm repository Once Helm is installed, add the *service-catalog* Helm repository to your local machine by executing the following command: @@ -105,11 +106,12 @@ helm install svc-cat/catalog --name catalog --namespace catalog ``` {{% /tab %}} {{< /tabs >}} -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers). * Explore the [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) project. -{{% /capture %}} + diff --git a/content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md b/content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md index 2a50ca2ff8..a45474e297 100644 --- a/content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md +++ b/content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md @@ -2,10 +2,10 @@ title: Install Service Catalog using SC reviewers: - chenopis -content_template: templates/task +content_type: task --- -{{% capture overview %}} + {{< glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" >}} You can use the GCP [Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation) @@ -14,10 +14,11 @@ Google Cloud projects. Service Catalog itself can work with any kind of managed service, not just Google Cloud. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * Understand the key concepts of [Service Catalog](/docs/concepts/service-catalog/). * Install [Go 1.6+](https://golang.org/dl/) and set the `GOPATH`. * Install the [cfssl](https://github.com/cloudflare/cfssl) tool needed for generating SSL artifacts. @@ -27,10 +28,10 @@ Service Catalog itself can work with any kind of managed service, not just Googl kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user= -{{% /capture %}} -{{% capture steps %}} + + ## Install `sc` in your local environment The installer runs on your local computer as a CLI tool named `sc`. @@ -71,11 +72,12 @@ If you would like to uninstall Service Catalog from your Kubernetes cluster usin sc uninstall ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers). * Explore the [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) project. -{{% /capture %}} + diff --git a/content/en/docs/tasks/setup-konnectivity/_index.md b/content/en/docs/tasks/setup-konnectivity/_index.md deleted file mode 100755 index 09f254eba0..0000000000 --- a/content/en/docs/tasks/setup-konnectivity/_index.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: "Setup Konnectivity Service" -weight: 20 ---- - diff --git a/content/en/docs/tasks/tls/_index.md b/content/en/docs/tasks/tls/_index.md index 8607aa28d2..6fb6923847 100755 --- a/content/en/docs/tasks/tls/_index.md +++ b/content/en/docs/tasks/tls/_index.md @@ -1,5 +1,6 @@ --- title: "TLS" weight: 100 +description: Understand how to protect traffic within your cluster using Transport Layer Security (TLS). --- diff --git a/content/en/docs/tasks/tls/certificate-rotation.md b/content/en/docs/tasks/tls/certificate-rotation.md index 3cf55db335..890621c19f 100644 --- a/content/en/docs/tasks/tls/certificate-rotation.md +++ b/content/en/docs/tasks/tls/certificate-rotation.md @@ -2,23 +2,24 @@ reviewers: - jcbsmpsn - mikedanese -title: Certificate Rotation -content_template: templates/task +title: Configure Certificate Rotation for the Kubelet +content_type: task --- -{{% capture overview %}} + This page shows how to enable and configure certificate rotation for the kubelet. -{{% /capture %}} + {{< feature-state for_k8s_version="v1.8" state="beta" >}} -{{% capture prerequisites %}} +## {{% heading "prerequisites" %}} + * Kubernetes version 1.8.0 or later is required -{{% /capture %}} -{{% capture steps %}} + + ## Overview @@ -77,6 +78,6 @@ kubelet will retrieve the new signed certificate from the Kubernetes API and write that to disk. Then it will update the connections it has to the Kubernetes API to reconnect using the new certificate. -{{% /capture %}} + diff --git a/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md b/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md index 7cd4cc8be5..5098d353d8 100644 --- a/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md +++ b/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md @@ -1,13 +1,13 @@ --- title: Manage TLS Certificates in a Cluster -content_template: templates/task +content_type: task reviewers: - mikedanese - beacham - liggit --- -{{% capture overview %}} + Kubernetes provides a `certificates.k8s.io` API, which lets you provision TLS certificates signed by a Certificate Authority (CA) that you control. These CA @@ -23,16 +23,17 @@ CA for this purpose, but you should never rely on this. Do not assume that these certificates will validate against the cluster root CA. {{< /note >}} -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## Trusting TLS in a Cluster @@ -222,4 +223,4 @@ enable it, pass the `--cluster-signing-cert-file` and `--cluster-signing-key-file` parameters to the controller manager with paths to your Certificate Authority's keypair. -{{% /capture %}} + diff --git a/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md b/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md new file mode 100644 index 0000000000..4146608760 --- /dev/null +++ b/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md @@ -0,0 +1,144 @@ +--- +title: Manual Rotation of CA Certificates +min-kubernetes-server-version: v1.13 +content_template: templates/task +--- + + + +This page shows how to manually rotate the certificate authority (CA) certificates. + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + +- For more information about authentication in Kubernetes, see [Authenticating](/docs/reference/access-authn-authz/authentication). +- For more information about best practices for CA certificates, see [Single root CA](docs/setup/best-practices/certificates/#single-root-ca). + + + +## Rotate the CA certificates manually + +{{< caution >}} + +Make sure to back up your certificate directory along with configuration files and any other necessary files. + +This approach assumes operation of the Kubernetes control plane in a HA configuration with multiple API servers. Graceful termination of the API server is also assumed so clients can cleanly disconnect from one API server and reconnect to another. + +Configurations with a single API server will experience unavailability while the API server is being restarted. + +{{< /caution >}} + +1. Distribute the new CA certificates and private keys (ex: `ca.crt`, `ca.key`, `front-proxy-ca.crt`, and `front-proxy-ca.key`) to all your control plane nodes in the Kubernetes certificates directory. + +1. Update *Kubernetes controller manager's* `--root-ca-file` to include both old and new CA and restart controller manager. + + Any service account created after this point will get secrets that include both old and new CAs. + + {{< note >}} + + Remove the flag `--client-ca-file` from the *Kubernetes controller manager* configuration. You can also replace the existing client CA file or change this configuration item to reference a new, updated CA. [Issue 1350](https://github.com/kubernetes/kubeadm/issues/1350) tracks an issue with *Kubernetes controller manager* being unable to accept a CA bundle. + + {{< /note >}} + +1. Update all service account tokens to include both old and new CA certificates. + + If any pods are started before new CA is used by API servers, they will get this update and trust both old and new CAs. + + ```shell + base64_encoded_ca="$(base64 )" + + for namespace in $(kubectl get ns --no-headers | awk '{print $1}'); do + for token in $(kubectl get secrets --namespace "$namespace" --field-selector type=kubernetes.io/service-account-token -o name); do + kubectl get $token --namespace "$namespace" -o yaml | \ + /bin/sed "s/\(ca.crt:\).*/\1 ${base64_encoded_ca}" | \ + kubectl apply -f - + done + done + ``` + +1. Restart all pods using in-cluster configs (ex: kube-proxy, coredns, etc) so they can use the updated certificate authority data from *ServiceAccount* secrets. + + * Make sure coredns, kube-proxy and other pods using in-cluster configs are working as expected. + +1. Append the both old and new CA to the file against `--client-ca-file` and `--kubelet-certificate-authority` flag in the `kube-apiserver` configuration. + +1. Append the both old and new CA to the file against `--client-ca-file` flag in the `kube-scheduler` configuration. + +1. Update certificates for user accounts by replacing the content of `client-certificate-data` and `client-key-data` respectively. + + For information about creating certificates for individual user accounts, see [Configure certificates for user accounts](/docs/setup/best-practices/certificates/#configure-certificates-for-user-accounts). + + Additionally, update the `certificate-authority-data` section in the kubeconfig files, respectively with Base64-encoded old and new certificate authority data + +1. Follow below steps in a rolling fashion. + + 1. Restart any other *[aggregated api servers](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)* or *webhook handlers* to trust the new CA certificates. + + 1. Restart the kubelet by update the file against `clientCAFile` in kubelet configuration and `certificate-authority-data` in kubelet.conf to use both the old and new CA on all nodes. + + If your kubelet is not using client certificate rotation update `client-certificate-data` and `client-key-data` in kubelet.conf on all nodes along with the kubelet client certificate file usually found in `/var/lib/kubelet/pki`. + + + 1. Restart API servers with the certificates (`apiserver.crt`, `apiserver-kubelet-client.crt` and `front-proxy-client.crt`) signed by new CA. You can use the existing private keys or new private keys. If you changed the private keys then update these in the Kubernetes certificates directory as well. + + Since the pod trusts both old and new CAs, there will be a momentarily disconnection after which the pod's kube client will reconnect to the new API server that uses the certificate signed by the new CA. + + * Restart Scheduler to use the new CAs. + + * Make sure control plane components logs no TLS errors. + + {{< note >}} + + To generate certificates and private keys for your cluster using the `openssl` command line tool, see [Certificates (`openssl`)](/docs/concepts/cluster-administration/certificates/#openssl). + You can also use [`cfssl`](/docs/concepts/cluster-administration/certificates/#cfssl). + + {{< /note >}} + + 1. Annotate any Daemonsets and Deployments to trigger pod replacement in a safer rolling fashion. + + Example: + + ```shell + for namespace in $(kubectl get namespace -o jsonpath='{.items[*].metadata.name}'); do + for name in $(kubectl get deployments -n $namespace -o jsonpath='{.items[*].metadata.name}'); do + kubectl patch deployment -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}'; + done + for name in $(kubectl get daemonset -n $namespace -o jsonpath='{.items[*].metadata.name}'); do + kubectl patch daemonset -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}'; + done + done + ``` + + {{< note >}} + + To limit the number of concurrent disruptions that your application experiences, see [configure pod disruption budget](docs/tasks/run-application/configure-pdb/). + + {{< /note >}} + +1. If your cluster is using bootstrap tokens to join nodes, update the ConfigMap `cluster-info` in the `kube-public` namespace with new CA. + + ```shell + base64_encoded_ca="$(base64 /etc/kubernetes/pki/ca.crt)" + + kubectl get cm/cluster-info --namespace kube-public -o yaml | \ + /bin/sed "s/\(certificate-authority-data:\).*/\1 ${base64_encoded_ca}" | \ + kubectl apply -f - + ``` + +1. Verify the cluster functionality. + + 1. Validate the logs from control plane components, along with the kubelet and the kube-proxy are not throwing any tls errors, see [looking at the logs](/docs/tasks/debug-application-cluster/debug-cluster/#looking-at-logs). + + 1. Validate logs from any aggregated api servers and pods using in-cluster config. + +1. Once the cluster functionality is successfully verified: + + 1. Update all service account tokens to include new CA certificate only. + + * All pods using an in-cluster kubeconfig will eventually need to be restarted to pick up the new SA secret for the old CA to be completely untrusted. + + 1. Restart the control plane components by removing the old CA from the kubeconfig files and the files against `--client-ca-file`, `--root-ca-file` flags resp. + + 1. Restart kubelet by removing the old CA from file against the `clientCAFile` flag and kubelet kubeconfig file. diff --git a/content/en/docs/tasks/tools/_index.md b/content/en/docs/tasks/tools/_index.md index 78a5ead6cd..cabf9a3c7b 100755 --- a/content/en/docs/tasks/tools/_index.md +++ b/content/en/docs/tasks/tools/_index.md @@ -1,5 +1,6 @@ --- title: "Install Tools" +description: Set up Kubernetes tools on your computer. weight: 10 --- diff --git a/content/en/docs/tasks/tools/install-kubectl.md b/content/en/docs/tasks/tools/install-kubectl.md index 131362109a..25b5cab9b5 100644 --- a/content/en/docs/tasks/tools/install-kubectl.md +++ b/content/en/docs/tasks/tools/install-kubectl.md @@ -2,7 +2,7 @@ reviewers: - mikedanese title: Install and Set Up kubectl -content_template: templates/task +content_type: task weight: 10 card: name: tasks @@ -10,15 +10,16 @@ card: title: Install kubectl --- -{{% capture overview %}} + The Kubernetes command-line tool, [kubectl](/docs/user-guide/kubectl/), allows you to run commands against Kubernetes clusters. You can use kubectl to deploy applications, inspect and manage cluster resources, and view logs. For a complete list of kubectl operations, see [Overview of kubectl](/docs/reference/kubectl/overview/). -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + You must use a kubectl version that is within one minor version difference of your cluster. For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master. Using the latest version of kubectl helps avoid unforeseen issues. -{{% /capture %}} -{{% capture steps %}} + + ## Install kubectl on Linux @@ -113,35 +114,35 @@ kubectl version --client 1. Download the latest release: - ``` - curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl" - ``` + ```bash + curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl" + ``` - To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version. + To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version. - For example, to download version {{< param "fullversion" >}} on macOS, type: - - ``` - curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl - ``` + For example, to download version {{< param "fullversion" >}} on macOS, type: -2. Make the kubectl binary executable. + ```bash + curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl + ``` - ``` - chmod +x ./kubectl - ``` + Make the kubectl binary executable. + + ```bash + chmod +x ./kubectl + ``` 3. Move the binary in to your PATH. - ``` - sudo mv ./kubectl /usr/local/bin/kubectl - ``` + ```bash + sudo mv ./kubectl /usr/local/bin/kubectl + ``` 4. Test to ensure the version you installed is up-to-date: - ``` - kubectl version --client - ``` + ```bash + kubectl version --client + ``` ### Install with Homebrew on macOS @@ -149,21 +150,21 @@ If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you 1. Run the installation command: - ``` - brew install kubectl - ``` + ```bash + brew install kubectl + ``` - or + or - ``` - brew install kubernetes-cli - ``` + ```bash + brew install kubernetes-cli + ``` 2. Test to ensure the version you installed is up-to-date: - ``` - kubectl version --client - ``` + ```bash + kubectl version --client + ``` ### Install with Macports on macOS @@ -171,16 +172,16 @@ If you are on macOS and using [Macports](https://macports.org/) package manager, 1. Run the installation command: - ``` - sudo port selfupdate - sudo port install kubectl - ``` - + ```bash + sudo port selfupdate + sudo port install kubectl + ``` + 2. Test to ensure the version you installed is up-to-date: - ``` - kubectl version --client - ``` + ```bash + kubectl version --client + ``` ## Install kubectl on Windows @@ -188,21 +189,21 @@ If you are on macOS and using [Macports](https://macports.org/) package manager, 1. Download the latest release {{< param "fullversion" >}} from [this link](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe). - Or if you have `curl` installed, use this command: + Or if you have `curl` installed, use this command: - ``` - curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe - ``` + ```bash + curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe + ``` - To find out the latest stable version (for example, for scripting), take a look at [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt). + To find out the latest stable version (for example, for scripting), take a look at [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt). 2. Add the binary in to your PATH. 3. Test to ensure the version of `kubectl` is the same as downloaded: - ``` - kubectl version --client - ``` + ```bash + kubectl version --client + ``` {{< note >}} [Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes) adds its own version of `kubectl` to PATH. @@ -215,21 +216,22 @@ If you are on Windows and using [Powershell Gallery](https://www.powershellgalle 1. Run the installation commands (making sure to specify a `DownloadLocation`): - ``` - Install-Script -Name install-kubectl -Scope CurrentUser -Force - install-kubectl.ps1 [-DownloadLocation ] + ```powershell + Install-Script -Name 'install-kubectl' -Scope CurrentUser -Force + install-kubectl.ps1 [-DownloadLocation ] ``` -{{< note >}}If you do not specify a `DownloadLocation`, `kubectl` will be installed in the user's temp Directory. -{{< /note >}} + {{< note >}} + If you do not specify a `DownloadLocation`, `kubectl` will be installed in the user's temp Directory. + {{< /note >}} The installer creates `$HOME/.kube` and instructs it to create a config file. 2. Test to ensure the version you installed is up-to-date: - ``` - kubectl version --client - ``` + ```powershell + kubectl version --client + ``` {{< note >}} Updating the installation is performed by rerunning the two commands listed in step 1. @@ -239,50 +241,54 @@ Updating the installation is performed by rerunning the two commands listed in s 1. To install kubectl on Windows you can use either [Chocolatey](https://chocolatey.org) package manager or [Scoop](https://scoop.sh) command-line installer. -{{< tabs name="kubectl_win_install" >}} -{{% tab name="choco" %}} - - choco install kubernetes-cli - -{{% /tab %}} -{{% tab name="scoop" %}} - - scoop install kubectl - -{{% /tab %}} -{{< /tabs >}} + {{< tabs name="kubectl_win_install" >}} + {{% tab name="choco" %}} + ```powershell + choco install kubernetes-cli + ``` + {{% /tab %}} + {{% tab name="scoop" %}} + ```powershell + scoop install kubectl + ``` + {{% /tab %}} + {{< /tabs >}} 2. Test to ensure the version you installed is up-to-date: - ``` - kubectl version --client - ``` + ```powershell + kubectl version --client + ``` 3. Navigate to your home directory: - ``` - cd %USERPROFILE% - ``` + ```powershell + # If you're using cmd.exe, run: cd %USERPROFILE% + cd ~ + ``` + 4. Create the `.kube` directory: - ``` - mkdir .kube - ``` + ```powershell + mkdir .kube + ``` 5. Change to the `.kube` directory you just created: - ``` - cd .kube - ``` + ```powershell + cd .kube + ``` 6. Configure kubectl to use a remote Kubernetes cluster: - ``` - New-Item config -type file - ``` - -{{< note >}}Edit the config file with a text editor of your choice, such as Notepad.{{< /note >}} + ```powershell + New-Item config -type file + ``` + +{{< note >}} +Edit the config file with a text editor of your choice, such as Notepad. +{{< /note >}} ## Download as part of the Google Cloud SDK @@ -292,17 +298,17 @@ You can install kubectl as part of the Google Cloud SDK. 2. Run the `kubectl` installation command: - ``` - gcloud components install kubectl - ``` - + ```shell + gcloud components install kubectl + ``` + 3. Test to ensure the version you installed is up-to-date: - ``` - kubectl version --client - ``` + ```shell + kubectl version --client + ``` -## Verifying kubectl configuration +## Verifying kubectl configuration 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](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh) or successfully deploy a Minikube cluster. By default, kubectl configuration is located at `~/.kube/config`. @@ -316,7 +322,7 @@ If you see a URL response, kubectl is correctly configured to access your cluste If you see a message similar to the following, kubectl is not configured correctly or is not able to connect to a Kubernetes cluster. -```shell +``` The connection to the server was refused - did you specify the right host or port? ``` @@ -354,7 +360,7 @@ The above commands create `/usr/share/bash-completion/bash_completion`, which is To find out, reload your shell and run `type _init_completion`. If the command succeeds, you're already set, otherwise add the following to your `~/.bashrc` file: -```shell +```bash source /usr/share/bash-completion/bash_completion ``` @@ -366,17 +372,17 @@ You now need to ensure that the kubectl completion script gets sourced in all yo - Source the completion script in your `~/.bashrc` file: - ```shell - echo 'source <(kubectl completion bash)' >>~/.bashrc - ``` + ```bash + echo 'source <(kubectl completion bash)' >>~/.bashrc + ``` - Add the completion script to the `/etc/bash_completion.d` directory: - ```shell - kubectl completion bash >/etc/bash_completion.d/kubectl - ``` + ```bash + kubectl completion bash >/etc/bash_completion.d/kubectl + ``` If you have an alias for kubectl, you can extend shell completion to work with that alias: -```shell +```bash echo 'alias k=kubectl' >>~/.bashrc echo 'complete -F __start_kubectl k' >>~/.bashrc ``` @@ -407,19 +413,19 @@ There are two versions of bash-completion, v1 and v2. V1 is for Bash 3.2 (which The instructions here assume you use Bash 4.1+. You can check your Bash's version by running: -```shell +```bash echo $BASH_VERSION ``` If it is too old, you can install/upgrade it using Homebrew: -```shell +```bash brew install bash ``` Reload your shell and verify that the desired version is being used: -```shell +```bash echo $BASH_VERSION $SHELL ``` @@ -433,13 +439,13 @@ As mentioned, these instructions assume you use Bash 4.1+, which means you will You can test if you have bash-completion v2 already installed with `type _init_completion`. If not, you can install it with Homebrew: -```shell +```bash brew install bash-completion@2 ``` As stated in the output of this command, add the following to your `~/.bash_profile` file: -```shell +```bash export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d" [[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh" ``` @@ -452,29 +458,29 @@ You now have to ensure that the kubectl completion script gets sourced in all yo - Source the completion script in your `~/.bash_profile` file: - ```shell + ```bash echo 'source <(kubectl completion bash)' >>~/.bash_profile ``` - Add the completion script to the `/usr/local/etc/bash_completion.d` directory: - ```shell + ```bash kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl ``` - If you have an alias for kubectl, you can extend shell completion to work with that alias: - ```shell + ```bash echo 'alias k=kubectl' >>~/.bash_profile echo 'complete -F __start_kubectl k' >>~/.bash_profile ``` - + - If you installed kubectl with Homebrew (as explained [above](#install-with-homebrew-on-macos)), then the kubectl completion script should already be in `/usr/local/etc/bash_completion.d/kubectl`. In that case, you don't need to do anything. - {{< note >}} - The Homebrew installation of bash-completion v2 sources all the files in the `BASH_COMPLETION_COMPAT_DIR` directory, that's why the latter two methods work. - {{< /note >}} + {{< note >}} + The Homebrew installation of bash-completion v2 sources all the files in the `BASH_COMPLETION_COMPAT_DIR` directory, that's why the latter two methods work. + {{< /note >}} In any case, after reloading your shell, kubectl completion should be working. {{% /tab %}} @@ -485,35 +491,32 @@ The kubectl completion script for Zsh can be generated with the command `kubectl To do so in all your shell sessions, add the following to your `~/.zshrc` file: -```shell +```zsh source <(kubectl completion zsh) ``` If you have an alias for kubectl, you can extend shell completion to work with that alias: -```shell +```zsh echo 'alias k=kubectl' >>~/.zshrc echo 'complete -F __start_kubectl k' >>~/.zshrc ``` - + After reloading your shell, kubectl autocompletion should be working. If you get an error like `complete:13: command not found: compdef`, then add the following to the beginning of your `~/.zshrc` file: -```shell +```zsh autoload -Uz compinit compinit ``` {{% /tab %}} {{< /tabs >}} +## {{% heading "whatsnext" %}} -{{% /capture %}} - -{{% capture whatsnext %}} * [Install Minikube](/docs/tasks/tools/install-minikube/) -* See the [getting started guides](/docs/setup/) for more about creating clusters. +* See the [getting started guides](/docs/setup/) for more about creating clusters. * [Learn how to launch and expose your application.](/docs/tasks/access-application-cluster/service-access-application-cluster/) * 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/). * Read the [kubectl reference docs](/docs/reference/kubectl/kubectl/) -{{% /capture %}} diff --git a/content/en/docs/tasks/tools/install-minikube.md b/content/en/docs/tasks/tools/install-minikube.md index 50e4436dec..f1f3788141 100644 --- a/content/en/docs/tasks/tools/install-minikube.md +++ b/content/en/docs/tasks/tools/install-minikube.md @@ -1,19 +1,20 @@ --- title: Install Minikube -content_template: templates/task +content_type: task weight: 20 card: name: tasks weight: 10 --- -{{% capture overview %}} + This page shows you how to install [Minikube](/docs/tutorials/hello-minikube), a tool that runs a single-node Kubernetes cluster in a virtual machine on your personal computer. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< tabs name="minikube_before_you_begin" >}} {{% tab name="Linux" %}} @@ -53,11 +54,11 @@ Hyper-V Requirements: A hypervisor has been detected. Features required for {{% /tab %}} {{< /tabs >}} -{{% /capture %}} -{{% capture steps %}} -# Installing minikube + + +## Installing minikube {{< tabs name="tab_with_md" >}} {{% tab name="Linux" %}} @@ -199,15 +200,6 @@ To install Minikube manually on Windows, download [`minikube-windows-amd64`](htt {{% /tab %}} {{< /tabs >}} - -{{% /capture %}} - -{{% capture whatsnext %}} - -* [Running Kubernetes Locally via Minikube](/docs/setup/learning-environment/minikube/) - -{{% /capture %}} - ## Confirm Installation To confirm successful installation of both a hypervisor and Minikube, you can run the following command to start up a local Kubernetes cluster: @@ -218,6 +210,10 @@ For setting the `--driver` with `minikube start`, enter the name of the hypervis {{< /note >}} +{{< caution >}} +When using KVM, note that libvirt's default QEMU URI under Debian and some other systems is `qemu:///session` whereas Minikube's default QEMU URI is `qemu:///system`. If this is the case for your system, you will need to pass `--kvm-qemu-uri qemu:///session` to `minikube start`. +{{< /caution >}} + ```shell minikube start --driver= ``` @@ -259,3 +255,8 @@ then you need to clear minikube's local state: ```shell minikube delete ``` + +## {{% heading "whatsnext" %}} + + +* [Running Kubernetes Locally via Minikube](/docs/setup/learning-environment/minikube/) diff --git a/content/en/docs/tutorials/_index.md b/content/en/docs/tutorials/_index.md index 9f8de2129e..5551e5a8ea 100644 --- a/content/en/docs/tutorials/_index.md +++ b/content/en/docs/tutorials/_index.md @@ -2,10 +2,10 @@ title: Tutorials main_menu: true weight: 60 -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + This section of the Kubernetes documentation contains tutorials. A tutorial shows how to accomplish a goal that is larger than a single @@ -14,9 +14,9 @@ each of which has a sequence of steps. Before walking through each tutorial, you may want to bookmark the [Standardized Glossary](/docs/reference/glossary/) page for later references. -{{% /capture %}} -{{% capture body %}} + + ## Basics @@ -64,12 +64,13 @@ Before walking through each tutorial, you may want to bookmark the * [Using Source IP](/docs/tutorials/services/source-ip/) -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + If you would like to write a tutorial, see -[Using Page Templates](/docs/home/contribute/page-templates/) -for information about the tutorial page type and the tutorial template. +[Content Page Types](/docs/home/contribute/style/page-content-types/) +for information about the tutorial page type. + -{{% /capture %}} diff --git a/content/en/docs/tutorials/clusters/apparmor.md b/content/en/docs/tutorials/clusters/apparmor.md index ae1de98ab2..ddad3d54c2 100644 --- a/content/en/docs/tutorials/clusters/apparmor.md +++ b/content/en/docs/tutorials/clusters/apparmor.md @@ -2,10 +2,10 @@ reviewers: - stclair title: AppArmor -content_template: templates/tutorial +content_type: tutorial --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.4" state="beta" >}} @@ -13,7 +13,7 @@ content_template: templates/tutorial AppArmor is a Linux kernel security module that supplements the standard Linux user and group based permissions to confine programs to a limited set of resources. AppArmor can be configured for any application to reduce its potential attack surface and provide greater in-depth defense. It is -configured through profiles tuned to whitelist the access needed by a specific program or container, +configured through profiles tuned to allow the access needed by a specific program or container, such as Linux capabilities, network access, file permissions, etc. Each profile can be run in either *enforcing* mode, which blocks access to disallowed resources, or *complain* mode, which only reports violations. @@ -24,9 +24,10 @@ that AppArmor is not a silver bullet and can only do so much to protect against application code. It is important to provide good, restrictive profiles, and harden your applications and cluster from other angles as well. -{{% /capture %}} -{{% capture objectives %}} + +## {{% heading "objectives" %}} + * See an example of how to load a profile on a node * Learn how to enforce the profile on a Pod @@ -34,9 +35,10 @@ applications and cluster from other angles as well. * See what happens when a profile is violated * See what happens when a profile cannot be loaded -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + Make sure: @@ -111,9 +113,9 @@ gke-test-default-pool-239f5d02-x1kf: kubelet is posting ready status. AppArmor e gke-test-default-pool-239f5d02-xwux: kubelet is posting ready status. AppArmor enabled ``` -{{% /capture %}} -{{% capture lessoncontent %}} + + ## Securing a Pod @@ -458,13 +460,14 @@ Specifying the list of profiles Pod containers is allowed to specify: - Although an escaped comma is a legal character in a profile name, it cannot be explicitly allowed here. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + Additional resources: * [Quick guide to the AppArmor profile language](https://gitlab.com/apparmor/apparmor/wikis/QuickProfileLanguage) * [AppArmor core policy reference](https://gitlab.com/apparmor/apparmor/wikis/Policy_Layout) -{{% /capture %}} + diff --git a/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md index 7ae7fb087b..37f6f9e014 100644 --- a/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md +++ b/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md @@ -3,16 +3,17 @@ reviewers: - eparis - pmorie title: Configuring Redis using a ConfigMap -content_template: templates/tutorial +content_type: tutorial --- -{{% capture overview %}} + This page provides a real world example of how to configure Redis using a ConfigMap and builds upon the [Configure Containers Using a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) task. -{{% /capture %}} -{{% capture objectives %}} + +## {{% heading "objectives" %}} + * Create a `kustomization.yaml` file containing: * a ConfigMap generator @@ -20,18 +21,19 @@ This page provides a real world example of how to configure Redis using a Config * Apply the directory by running `kubectl apply -k ./` * Verify that the configuration was correctly applied. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * The example shown on this page works with `kubectl` 1.14 and above. * Understand [Configure Containers Using a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/). -{{% /capture %}} -{{% capture lessoncontent %}} + + ## Real World Example: Configuring Redis using a ConfigMap @@ -105,12 +107,13 @@ Delete the created pod: kubectl delete pod redis ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/). -{{% /capture %}} + diff --git a/content/en/docs/tutorials/hello-minikube.md b/content/en/docs/tutorials/hello-minikube.md index de6875b582..9ba2de1abf 100644 --- a/content/en/docs/tutorials/hello-minikube.md +++ b/content/en/docs/tutorials/hello-minikube.md @@ -1,6 +1,6 @@ --- title: Hello Minikube -content_template: templates/tutorial +content_type: tutorial weight: 5 menu: main: @@ -13,7 +13,7 @@ card: weight: 10 --- -{{% capture overview %}} + This tutorial shows you how to run a sample app on Kubernetes using [Minikube](/docs/setup/learning-environment/minikube) and Katacoda. @@ -23,23 +23,25 @@ Katacoda provides a free, in-browser Kubernetes environment. You can also follow this tutorial if you've installed [Minikube locally](/docs/tasks/tools/install-minikube/). {{< /note >}} -{{% /capture %}} -{{% capture objectives %}} + +## {{% heading "objectives" %}} + * Deploy a sample application to Minikube. * Run the app. * View application logs. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + This tutorial provides a container image that uses NGINX to echo back all the requests. -{{% /capture %}} -{{% capture lessoncontent %}} + + ## Create a Minikube cluster @@ -272,12 +274,13 @@ Optionally, delete the Minikube VM: minikube delete ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [Deployment objects](/docs/concepts/workloads/controllers/deployment/). * Learn more about [Deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/). * Learn more about [Service objects](/docs/concepts/services-networking/service/). -{{% /capture %}} + diff --git a/content/en/docs/tutorials/kubernetes-basics/public/css/styles.css b/content/en/docs/tutorials/kubernetes-basics/public/css/styles.css index 3ee982aa11..8c743991d9 100644 --- a/content/en/docs/tutorials/kubernetes-basics/public/css/styles.css +++ b/content/en/docs/tutorials/kubernetes-basics/public/css/styles.css @@ -2605,7 +2605,7 @@ output color: #555; } -.form-control +/* .form-control { font-size: 14px; line-height: 1.42857; @@ -2671,7 +2671,7 @@ textarea.form-control input[type='search'] { -webkit-appearance: none; -} +} */ @media screen and (-webkit-min-device-pixel-ratio: 0) { @@ -8804,7 +8804,6 @@ button.close .content { position: relative; - z-index: 500; box-sizing: border-box; margin: 0 0 0 -200px; @@ -8813,7 +8812,7 @@ button.close -webkit-transition: .12s ease-out; transition: .12s ease-out; - background: #fff; + /* background: #fff; */ /*box-shadow: -6px 0 14px -4px rgba(0, 0, 0, .5);*/ -webkit-box-flex: 1; @@ -9736,12 +9735,12 @@ p a:hover content: '|'; } -.btn +/* .btn { font-family: Roboto Slab, Roboto, 'Helvetica Neue', Helvetica, 'Open Sans', Arial, sans-serif; border-radius: 0; -} +} */ .btn.btn-success { color: #273d6d; @@ -9914,11 +9913,11 @@ p a:hover padding-bottom: 0; } -.form-control +/* .form-control { border-radius: 0; background: #f8f8f8; -} +} */ .content.katacoda-content { padding: 0; diff --git a/content/en/docs/tutorials/services/source-ip.md b/content/en/docs/tutorials/services/source-ip.md index ca3a2bb409..03a9bb097c 100644 --- a/content/en/docs/tutorials/services/source-ip.md +++ b/content/en/docs/tutorials/services/source-ip.md @@ -1,19 +1,20 @@ --- title: Using Source IP -content_template: templates/tutorial +content_type: tutorial min-kubernetes-server-version: v1.5 --- -{{% capture overview %}} + Applications running in a Kubernetes cluster find and communicate with each other, and the outside world, through the Service abstraction. This document explains what happens to the source IP of packets sent to different types of Services, and how you can toggle this behavior according to your needs. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + ### Terminology @@ -54,18 +55,19 @@ The output is: deployment.apps/source-ip-app created ``` -{{% /capture %}} -{{% capture objectives %}} + +## {{% heading "objectives" %}} + * Expose a simple application through various types of Services * Understand how each Service type handles source IP NAT * Understand the tradeoffs involved in preserving source IP -{{% /capture %}} -{{% capture lessoncontent %}} + + ## Source IP for Services with `Type=ClusterIP` @@ -423,9 +425,10 @@ Load balancers in the second category can leverage the feature described above by creating an HTTP health check pointing at the port stored in the `service.spec.healthCheckNodePort` field on the Service. -{{% /capture %}} -{{% capture cleanup %}} + +## {{% heading "cleanup" %}} + Delete the Services: @@ -439,10 +442,11 @@ Delete the Deployment, ReplicaSet and Pod: kubectl delete deployment source-ip-app ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [connecting applications via services](/docs/concepts/services-networking/connect-applications-service/) * Read how to [Create an External Load Balancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/) -{{% /capture %}} + diff --git a/content/en/docs/tutorials/stateful-application/basic-stateful-set.md b/content/en/docs/tutorials/stateful-application/basic-stateful-set.md index e8f3156694..9c6edf784f 100644 --- a/content/en/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/en/docs/tutorials/stateful-application/basic-stateful-set.md @@ -7,19 +7,20 @@ reviewers: - kow3ns - smarterclayton title: StatefulSet Basics -content_template: templates/tutorial +content_type: tutorial weight: 10 --- -{{% capture overview %}} + This tutorial provides an introduction to managing applications with -[StatefulSets](/docs/concepts/workloads/controllers/statefulset/). It -demonstrates how to create, delete, scale, and update the Pods of StatefulSets. -{{% /capture %}} +{{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}}. +It demonstrates how to create, delete, scale, and update the Pods of StatefulSets. -{{% capture prerequisites %}} -Before you begin this tutorial, you should familiarize yourself with the -following Kubernetes concepts. + +## {{% heading "prerequisites" %}} + +Before you begin this tutorial, you should familiarize yourself with the +following Kubernetes concepts: * [Pods](/docs/concepts/workloads/pods/) * [Cluster DNS](/docs/concepts/services-networking/dns-pod-service/) @@ -27,19 +28,21 @@ following Kubernetes concepts. * [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) * [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) * [StatefulSets](/docs/concepts/workloads/controllers/statefulset/) -* [kubectl CLI](/docs/user-guide/kubectl/) +* The [kubectl](/docs/reference/kubectl/kubectl/) command line tool -This tutorial assumes that your cluster is configured to dynamically provision +{{< note >}} +This tutorial assumes that your cluster is configured to dynamically provision PersistentVolumes. If your cluster is not configured to do so, you -will have to manually provision two 1 GiB volumes prior to starting this +will have to manually provision two 1 GiB volumes prior to starting this tutorial. -{{% /capture %}} +{{< /note >}} -{{% capture objectives %}} -StatefulSets are intended to be used with stateful applications and distributed -systems. However, the administration of stateful applications and -distributed systems on Kubernetes is a broad, complex topic. In order to -demonstrate the basic features of a StatefulSet, and not to conflate the former +## {{% heading "objectives" %}} + +StatefulSets are intended to be used with stateful applications and distributed +systems. However, the administration of stateful applications and +distributed systems on Kubernetes is a broad, complex topic. In order to +demonstrate the basic features of a StatefulSet, and not to conflate the former topic with the latter, you will deploy a simple web application using a StatefulSet. After this tutorial, you will be familiar with the following. @@ -49,62 +52,70 @@ After this tutorial, you will be familiar with the following. * How to delete a StatefulSet * How to scale a StatefulSet * How to update a StatefulSet's Pods -{{% /capture %}} -{{% capture lessoncontent %}} -## Creating a StatefulSet + -Begin by creating a StatefulSet using the example below. It is similar to the +## Creating a StatefulSet + +Begin by creating a StatefulSet using the example below. It is similar to the example presented in the -[StatefulSets](/docs/concepts/workloads/controllers/statefulset/) concept. -It creates a [Headless Service](/docs/concepts/services-networking/service/#headless-services), -`nginx`, to publish the IP addresses of Pods in the StatefulSet, `web`. +[StatefulSets](/docs/concepts/workloads/controllers/statefulset/) concept. +It creates a [headless Service](/docs/concepts/services-networking/service/#headless-services), +`nginx`, to publish the IP addresses of Pods in the StatefulSet, `web`. {{< codenew file="application/web/web.yaml" >}} Download the example above, and save it to a file named `web.yaml` -You will need to use two terminal windows. In the first terminal, use -[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get) to watch the creation +You will need to use two terminal windows. In the first terminal, use +[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get) to watch the creation of the StatefulSet's Pods. ```shell kubectl get pods -w -l app=nginx ``` -In the second terminal, use +In the second terminal, use [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) to create the -Headless Service and StatefulSet defined in `web.yaml`. +headless Service and StatefulSet defined in `web.yaml`. ```shell kubectl apply -f web.yaml +``` +``` service/nginx created statefulset.apps/web created ``` -The command above creates two Pods, each running an -[NGINX](https://www.nginx.com) webserver. Get the `nginx` Service and the -`web` StatefulSet to verify that they were created successfully. - +The command above creates two Pods, each running an +[NGINX](https://www.nginx.com) webserver. Get the `nginx` Service... ```shell kubectl get service nginx +``` +``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx ClusterIP None 80/TCP 12s - +``` +...then get the `web` StatefulSet, to verify that both were created successfully: +```shell kubectl get statefulset web +``` +``` NAME DESIRED CURRENT AGE web 2 1 20s ``` ### Ordered Pod Creation -For a StatefulSet with N replicas, when Pods are being deployed, they are -created sequentially, in order from {0..N-1}. Examine the output of the -`kubectl get` command in the first terminal. Eventually, the output will +For a StatefulSet with _n_ replicas, when Pods are being deployed, they are +created sequentially, ordered from _{0..n-1}_. Examine the output of the +`kubectl get` command in the first terminal. Eventually, the output will look like the example below. ```shell kubectl get pods -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 0/1 Pending 0 0s web-0 0/1 Pending 0 0s @@ -116,8 +127,9 @@ web-1 0/1 ContainerCreating 0 0s web-1 1/1 Running 0 18s ``` -Notice that the `web-1` Pod is not launched until the `web-0` Pod is -[Running and Ready](/docs/user-guide/pod-states). +Notice that the `web-1` Pod is not launched until the `web-0` Pod is +_Running_ (see [Pod Phase](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)) +and _Ready_ (see `type` in [Pod Conditions](/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions)). ## Pods in a StatefulSet @@ -125,43 +137,53 @@ Pods in a StatefulSet have a unique ordinal index and a stable network identity. ### Examining the Pod's Ordinal Index -Get the StatefulSet's Pods. +Get the StatefulSet's Pods: ```shell kubectl get pods -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 1m web-1 1/1 Running 0 1m - ``` -As mentioned in the [StatefulSets](/docs/concepts/workloads/controllers/statefulset/) -concept, the Pods in a StatefulSet have a sticky, unique identity. This identity -is based on a unique ordinal index that is assigned to each Pod by the -StatefulSet controller. The Pods' names take the form -`-`. Since the `web` StatefulSet has two -replicas, it creates two Pods, `web-0` and `web-1`. +As mentioned in the [StatefulSets](/docs/concepts/workloads/controllers/statefulset/) +concept, the Pods in a StatefulSet have a sticky, unique identity. This identity +is based on a unique ordinal index that is assigned to each Pod by the +StatefulSet {{< glossary_tooltip term_id="controller" text="controller">}}. +The Pods' names take the form `-`. +Since the `web` StatefulSet has two replicas, it creates two Pods, `web-0` and `web-1`. ### Using Stable Network Identities Each Pod has a stable hostname based on its ordinal index. Use -[`kubectl exec`](/docs/reference/generated/kubectl/kubectl-commands/#exec) to execute the -`hostname` command in each Pod. +[`kubectl exec`](/docs/reference/generated/kubectl/kubectl-commands/#exec) to execute the +`hostname` command in each Pod: ```shell -for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done +for i in 0 1; do kubectl exec "web-$i" -- sh -c 'hostname'; done +``` +``` web-0 web-1 ``` -Use [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) to execute -a container that provides the `nslookup` command from the `dnsutils` package. -Using `nslookup` on the Pods' hostnames, you can examine their in-cluster DNS -addresses. +Use [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) to execute +a container that provides the `nslookup` command from the `dnsutils` package. +Using `nslookup` on the Pods' hostnames, you can examine their in-cluster DNS +addresses: ```shell -kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm +kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm +``` +which starts a new shell. In that new shell, run: +```shell +# Run this in the dns-test container shell nslookup web-0.nginx +``` +The output is similar to: +``` Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local @@ -176,30 +198,36 @@ Name: web-1.nginx Address 1: 10.244.2.6 ``` -The CNAME of the headless service points to SRV records (one for each Pod that -is Running and Ready). The SRV records point to A record entries that -contain the Pods' IP addresses. +(and now exit the container shell: `exit`) -In one terminal, watch the StatefulSet's Pods. +The CNAME of the headless service points to SRV records (one for each Pod that +is Running and Ready). The SRV records point to A record entries that +contain the Pods' IP addresses. + +In one terminal, watch the StatefulSet's Pods: ```shell kubectl get pod -w -l app=nginx ``` In a second terminal, use -[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) to delete all -the Pods in the StatefulSet. +[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) to delete all +the Pods in the StatefulSet: ```shell kubectl delete pod -l app=nginx +``` +``` pod "web-0" deleted pod "web-1" deleted ``` -Wait for the StatefulSet to restart them, and for both Pods to transition to -Running and Ready. +Wait for the StatefulSet to restart them, and for both Pods to transition to +Running and Ready: ```shell kubectl get pod -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 0/1 ContainerCreating 0 0s NAME READY STATUS RESTARTS AGE @@ -210,16 +238,28 @@ web-1 0/1 ContainerCreating 0 0s web-1 1/1 Running 0 34s ``` -Use `kubectl exec` and `kubectl run` to view the Pods hostnames and in-cluster -DNS entries. +Use `kubectl exec` and `kubectl run` to view the Pods' hostnames and in-cluster +DNS entries. First, view the Pods' hostnames: ```shell for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done +``` +``` web-0 web-1 - -kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm /bin/sh +``` +then, run: +``` +kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm /bin/sh +``` +which starts a new shell. +In that new shell, run: +```shell +# Run this in the dns-test container shell nslookup web-0.nginx +``` +The output is similar to: +``` Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local @@ -234,85 +274,100 @@ Name: web-1.nginx Address 1: 10.244.2.8 ``` -The Pods' ordinals, hostnames, SRV records, and A record names have not changed, -but the IP addresses associated with the Pods may have changed. In the cluster -used for this tutorial, they have. This is why it is important not to configure +(and now exit the container shell: `exit`) + +The Pods' ordinals, hostnames, SRV records, and A record names have not changed, +but the IP addresses associated with the Pods may have changed. In the cluster +used for this tutorial, they have. This is why it is important not to configure other applications to connect to Pods in a StatefulSet by IP address. -If you need to find and connect to the active members of a StatefulSet, you -should query the CNAME of the Headless Service -(`nginx.default.svc.cluster.local`). The SRV records associated with the -CNAME will contain only the Pods in the StatefulSet that are Running and +If you need to find and connect to the active members of a StatefulSet, you +should query the CNAME of the headless Service +(`nginx.default.svc.cluster.local`). The SRV records associated with the +CNAME will contain only the Pods in the StatefulSet that are Running and Ready. -If your application already implements connection logic that tests for -liveness and readiness, you can use the SRV records of the Pods ( +If your application already implements connection logic that tests for +liveness and readiness, you can use the SRV records of the Pods ( `web-0.nginx.default.svc.cluster.local`, -`web-1.nginx.default.svc.cluster.local`), as they are stable, and your -application will be able to discover the Pods' addresses when they transition +`web-1.nginx.default.svc.cluster.local`), as they are stable, and your +application will be able to discover the Pods' addresses when they transition to Running and Ready. ### Writing to Stable Storage -Get the PersistentVolumeClaims for `web-0` and `web-1`. +Get the PersistentVolumeClaims for `web-0` and `web-1`: ```shell kubectl get pvc -l app=nginx +``` +The output is similar to: +``` NAME STATUS VOLUME CAPACITY ACCESSMODES AGE www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 48s www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 48s ``` -The StatefulSet controller created two PersistentVolumeClaims that are -bound to two [PersistentVolumes](/docs/concepts/storage/persistent-volumes/). As the cluster used in this tutorial is configured to dynamically provision -PersistentVolumes, the PersistentVolumes were created and bound automatically. -The NGINX webservers, by default, will serve an index file at -`/usr/share/nginx/html/index.html`. The `volumeMounts` field in the -StatefulSets `spec` ensures that the `/usr/share/nginx/html` directory is +The StatefulSet controller created two +{{< glossary_tooltip text="PersistentVolumeClaims" term_id="persistent-volume-claim" >}} +that are bound to two +{{< glossary_tooltip text="PersistentVolumes" term_id="persistent-volume" >}}. + +As the cluster used in this tutorial is configured to dynamically provision PersistentVolumes, +the PersistentVolumes were created and bound automatically. + +The NGINX webserver, by default, serves an index file from +`/usr/share/nginx/html/index.html`. The `volumeMounts` field in the +StatefulSet's `spec` ensures that the `/usr/share/nginx/html` directory is backed by a PersistentVolume. -Write the Pods' hostnames to their `index.html` files and verify that the NGINX -webservers serve the hostnames. +Write the Pods' hostnames to their `index.html` files and verify that the NGINX +webservers serve the hostnames: ```shell -for i in 0 1; do kubectl exec web-$i -- sh -c 'echo $(hostname) > /usr/share/nginx/html/index.html'; done +for i in 0 1; do kubectl exec "web-$i" -- sh -c 'echo "$(hostname)" > /usr/share/nginx/html/index.html'; done -for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done +for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done +``` +``` web-0 web-1 ``` {{< note >}} -If you instead see 403 Forbidden responses for the above curl command, +If you instead see **403 Forbidden** responses for the above curl command, you will need to fix the permissions of the directory mounted by the `volumeMounts` -(due to a [bug when using hostPath volumes](https://github.com/kubernetes/kubernetes/issues/2630)) with: +(due to a [bug when using hostPath volumes](https://github.com/kubernetes/kubernetes/issues/2630)), +by running: -```shell -for i in 0 1; do kubectl exec web-$i -- chmod 755 /usr/share/nginx/html; done -``` +`for i in 0 1; do kubectl exec web-$i -- chmod 755 /usr/share/nginx/html; done` -before retrying the curl command above. +before retrying the `curl` command above. {{< /note >}} -In one terminal, watch the StatefulSet's Pods. +In one terminal, watch the StatefulSet's Pods: ```shell kubectl get pod -w -l app=nginx ``` -In a second terminal, delete all of the StatefulSet's Pods. +In a second terminal, delete all of the StatefulSet's Pods: ```shell kubectl delete pod -l app=nginx +``` +``` pod "web-0" deleted pod "web-1" deleted ``` -Examine the output of the `kubectl get` command in the first terminal, and wait +Examine the output of the `kubectl get` command in the first terminal, and wait for all of the Pods to transition to Running and Ready. ```shell kubectl get pod -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 0/1 ContainerCreating 0 0s NAME READY STATUS RESTARTS AGE @@ -323,47 +378,54 @@ web-1 0/1 ContainerCreating 0 0s web-1 1/1 Running 0 34s ``` -Verify the web servers continue to serve their hostnames. +Verify the web servers continue to serve their hostnames: ``` -for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done +for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done +``` +``` web-0 web-1 ``` -Even though `web-0` and `web-1` were rescheduled, they continue to serve their -hostnames because the PersistentVolumes associated with their -PersistentVolumeClaims are remounted to their `volumeMounts`. No matter what -node `web-0`and `web-1` are scheduled on, their PersistentVolumes will be +Even though `web-0` and `web-1` were rescheduled, they continue to serve their +hostnames because the PersistentVolumes associated with their +PersistentVolumeClaims are remounted to their `volumeMounts`. No matter what +node `web-0`and `web-1` are scheduled on, their PersistentVolumes will be mounted to the appropriate mount points. ## Scaling a StatefulSet -Scaling a StatefulSet refers to increasing or decreasing the number of replicas. + +Scaling a StatefulSet refers to increasing or decreasing the number of replicas. This is accomplished by updating the `replicas` field. You can use either [`kubectl scale`](/docs/reference/generated/kubectl/kubectl-commands/#scale) or [`kubectl patch`](/docs/reference/generated/kubectl/kubectl-commands/#patch) to scale a StatefulSet. ### Scaling Up -In one terminal window, watch the Pods in the StatefulSet. +In one terminal window, watch the Pods in the StatefulSet: ```shell kubectl get pods -w -l app=nginx ``` -In another terminal window, use `kubectl scale` to scale the number of replicas -to 5. +In another terminal window, use `kubectl scale` to scale the number of replicas +to 5: ```shell kubectl scale sts web --replicas=5 +``` +``` statefulset.apps/web scaled ``` -Examine the output of the `kubectl get` command in the first terminal, and wait +Examine the output of the `kubectl get` command in the first terminal, and wait for the three additional Pods to transition to Running and Ready. ```shell kubectl get pods -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 2h web-1 1/1 Running 0 2h @@ -384,30 +446,34 @@ web-4 1/1 Running 0 19s The StatefulSet controller scaled the number of replicas. As with [StatefulSet creation](#ordered-pod-creation), the StatefulSet controller -created each Pod sequentially with respect to its ordinal index, and it -waited for each Pod's predecessor to be Running and Ready before launching the +created each Pod sequentially with respect to its ordinal index, and it +waited for each Pod's predecessor to be Running and Ready before launching the subsequent Pod. ### Scaling Down -In one terminal, watch the StatefulSet's Pods. +In one terminal, watch the StatefulSet's Pods: ```shell kubectl get pods -w -l app=nginx ``` -In another terminal, use `kubectl patch` to scale the StatefulSet back down to -three replicas. +In another terminal, use `kubectl patch` to scale the StatefulSet back down to +three replicas: ```shell kubectl patch sts web -p '{"spec":{"replicas":3}}' +``` +``` statefulset.apps/web patched ``` Wait for `web-4` and `web-3` to transition to Terminating. -``` +```shell kubectl get pods -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 3h web-1 1/1 Running 0 3h @@ -424,14 +490,16 @@ web-3 1/1 Terminating 0 42s ### Ordered Pod Termination -The controller deleted one Pod at a time, in reverse order with respect to its -ordinal index, and it waited for each to be completely shutdown before +The controller deleted one Pod at a time, in reverse order with respect to its +ordinal index, and it waited for each to be completely shutdown before deleting the next. -Get the StatefulSet's PersistentVolumeClaims. +Get the StatefulSet's PersistentVolumeClaims: ```shell kubectl get pvc -l app=nginx +``` +``` NAME STATUS VOLUME CAPACITY ACCESSMODES AGE www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 13h www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 13h @@ -441,44 +509,51 @@ www-web-4 Bound pvc-e11bb5f8-b508-11e6-932f-42010a800002 1Gi RWO ``` -There are still five PersistentVolumeClaims and five PersistentVolumes. -When exploring a Pod's [stable storage](#writing-to-stable-storage), we saw that the PersistentVolumes mounted to the Pods of a StatefulSet are not deleted when the StatefulSet's Pods are deleted. This is still true when Pod deletion is caused by scaling the StatefulSet down. +There are still five PersistentVolumeClaims and five PersistentVolumes. +When exploring a Pod's [stable storage](#writing-to-stable-storage), we saw that the PersistentVolumes mounted to the Pods of a StatefulSet are not deleted when the StatefulSet's Pods are deleted. This is still true when Pod deletion is caused by scaling the StatefulSet down. ## Updating StatefulSets -In Kubernetes 1.7 and later, the StatefulSet controller supports automated updates. The -strategy used is determined by the `spec.updateStrategy` field of the -StatefulSet API Object. This feature can be used to upgrade the container -images, resource requests and/or limits, labels, and annotations of the Pods in a -StatefulSet. There are two valid update strategies, `RollingUpdate` and +In Kubernetes 1.7 and later, the StatefulSet controller supports automated updates. The +strategy used is determined by the `spec.updateStrategy` field of the +StatefulSet API Object. This feature can be used to upgrade the container +images, resource requests and/or limits, labels, and annotations of the Pods in a +StatefulSet. There are two valid update strategies, `RollingUpdate` and `OnDelete`. `RollingUpdate` update strategy is the default for StatefulSets. ### Rolling Update -The `RollingUpdate` update strategy will update all Pods in a StatefulSet, in +The `RollingUpdate` update strategy will update all Pods in a StatefulSet, in reverse ordinal order, while respecting the StatefulSet guarantees. -Patch the `web` StatefulSet to apply the `RollingUpdate` update strategy. +Patch the `web` StatefulSet to apply the `RollingUpdate` update strategy: ```shell kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate"}}}' +``` +``` statefulset.apps/web patched ``` -In one terminal window, patch the `web` StatefulSet to change the container -image again. +In one terminal window, patch the `web` StatefulSet to change the container +image again: ```shell kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"gcr.io/google_containers/nginx-slim:0.8"}]' +``` +``` statefulset.apps/web patched ``` -In another terminal, watch the Pods in the StatefulSet. +In another terminal, watch the Pods in the StatefulSet: ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w +``` +The output is simular to: +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 7m web-1 1/1 Running 0 7m @@ -513,21 +588,24 @@ web-0 0/1 ContainerCreating 0 0s web-0 1/1 Running 0 10s ``` -The Pods in the StatefulSet are updated in reverse ordinal order. The -StatefulSet controller terminates each Pod, and waits for it to transition to Running and -Ready prior to updating the next Pod. Note that, even though the StatefulSet -controller will not proceed to update the next Pod until its ordinal successor -is Running and Ready, it will restore any Pod that fails during the update to -its current version. Pods that have already received the update will be -restored to the updated version, and Pods that have not yet received the -update will be restored to the previous version. In this way, the controller -attempts to continue to keep the application healthy and the update consistent -in the presence of intermittent failures. +The Pods in the StatefulSet are updated in reverse ordinal order. The +StatefulSet controller terminates each Pod, and waits for it to transition to Running and +Ready prior to updating the next Pod. Note that, even though the StatefulSet +controller will not proceed to update the next Pod until its ordinal successor +is Running and Ready, it will restore any Pod that fails during the update to +its current version. -Get the Pods to view their container images. +Pods that have already received the update will be restored to the updated version, +and Pods that have not yet received the update will be restored to the previous +version. In this way, the controller attempts to continue to keep the application +healthy and the update consistent in the presence of intermittent failures. + +Get the Pods to view their container images: ```shell -for p in 0 1 2; do kubectl get po web-$p --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done +for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done +``` +``` k8s.gcr.io/nginx-slim:0.8 k8s.gcr.io/nginx-slim:0.8 k8s.gcr.io/nginx-slim:0.8 @@ -536,40 +614,51 @@ k8s.gcr.io/nginx-slim:0.8 All the Pods in the StatefulSet are now running the previous container image. -**Tip** You can also use `kubectl rollout status sts/` to view -the status of a rolling update. +{{< note >}} +You can also use `kubectl rollout status sts/` to view +the status of a rolling update to a StatefulSet +{{< /note >}} #### Staging an Update -You can stage an update to a StatefulSet by using the `partition` parameter of -the `RollingUpdate` update strategy. A staged update will keep all of the Pods -in the StatefulSet at the current version while allowing mutations to the + +You can stage an update to a StatefulSet by using the `partition` parameter of +the `RollingUpdate` update strategy. A staged update will keep all of the Pods +in the StatefulSet at the current version while allowing mutations to the StatefulSet's `.spec.template`. -Patch the `web` StatefulSet to add a partition to the `updateStrategy` field. +Patch the `web` StatefulSet to add a partition to the `updateStrategy` field: ```shell kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":3}}}}' +``` +``` statefulset.apps/web patched ``` -Patch the StatefulSet again to change the container's image. +Patch the StatefulSet again to change the container's image: ```shell kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"k8s.gcr.io/nginx-slim:0.7"}]' +``` +``` statefulset.apps/web patched ``` -Delete a Pod in the StatefulSet. +Delete a Pod in the StatefulSet: ```shell -kubectl delete po web-2 +kubectl delete pod web-2 +``` +``` pod "web-2" deleted ``` Wait for the Pod to be Running and Ready. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 4m web-1 1/1 Running 0 4m @@ -577,34 +666,40 @@ web-2 0/1 ContainerCreating 0 11s web-2 1/1 Running 0 18s ``` -Get the Pod's container. +Get the Pod's container image: ```shell -kubectl get po web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +``` +``` k8s.gcr.io/nginx-slim:0.8 - ``` -Notice that, even though the update strategy is `RollingUpdate` the StatefulSet -controller restored the Pod with its original container. This is because the -ordinal of the Pod is less than the `partition` specified by the +Notice that, even though the update strategy is `RollingUpdate` the StatefulSet +restored the Pod with its original container. This is because the +ordinal of the Pod is less than the `partition` specified by the `updateStrategy`. #### Rolling Out a Canary -You can roll out a canary to test a modification by decrementing the `partition` + +You can roll out a canary to test a modification by decrementing the `partition` you specified [above](#staging-an-update). -Patch the StatefulSet to decrement the partition. +Patch the StatefulSet to decrement the partition: ```shell kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":2}}}}' +``` +``` statefulset.apps/web patched ``` Wait for `web-2` to be Running and Ready. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 4m web-1 1/1 Running 0 4m @@ -612,29 +707,36 @@ web-2 0/1 ContainerCreating 0 11s web-2 1/1 Running 0 18s ``` -Get the Pod's container. +Get the Pod's container: ```shell -kubectl get po web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +``` +``` k8s.gcr.io/nginx-slim:0.7 ``` -When you changed the `partition`, the StatefulSet controller automatically -updated the `web-2` Pod because the Pod's ordinal was greater than or equal to +When you changed the `partition`, the StatefulSet controller automatically +updated the `web-2` Pod because the Pod's ordinal was greater than or equal to the `partition`. -Delete the `web-1` Pod. +Delete the `web-1` Pod: ```shell -kubectl delete po web-1 +kubectl delete pod web-1 +``` +``` pod "web-1" deleted ``` Wait for the `web-1` Pod to be Running and Ready. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w +``` +The output is similar to: +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 6m web-1 0/1 Terminating 0 6m @@ -648,38 +750,46 @@ web-1 0/1 ContainerCreating 0 0s web-1 1/1 Running 0 18s ``` -Get the `web-1` Pods container. +Get the `web-1` Pod's container image: ```shell -kubectl get po web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' -k8s.gcr.io/nginx-slim:0.8 - +kubectl get pod web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' ``` -`web-1` was restored to its original configuration because the Pod's ordinal -was less than the partition. When a partition is specified, all Pods with an -ordinal that is greater than or equal to the partition will be updated when the -StatefulSet's `.spec.template` is updated. If a Pod that has an ordinal less -than the partition is deleted or otherwise terminated, it will be restored to +``` +k8s.gcr.io/nginx-slim:0.8 +``` + +`web-1` was restored to its original configuration because the Pod's ordinal +was less than the partition. When a partition is specified, all Pods with an +ordinal that is greater than or equal to the partition will be updated when the +StatefulSet's `.spec.template` is updated. If a Pod that has an ordinal less +than the partition is deleted or otherwise terminated, it will be restored to its original configuration. #### Phased Roll Outs -You can perform a phased roll out (e.g. a linear, geometric, or exponential -roll out) using a partitioned rolling update in a similar manner to how you -rolled out a [canary](#rolling-out-a-canary). To perform a phased roll out, set -the `partition` to the ordinal at which you want the controller to pause the -update. -The partition is currently set to `2`. Set the partition to `0`. +You can perform a phased roll out (e.g. a linear, geometric, or exponential +roll out) using a partitioned rolling update in a similar manner to how you +rolled out a [canary](#rolling-out-a-canary). To perform a phased roll out, set +the `partition` to the ordinal at which you want the controller to pause the +update. + +The partition is currently set to `2`. Set the partition to `0`: ```shell kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":0}}}}' +``` +``` statefulset.apps/web patched ``` Wait for all of the Pods in the StatefulSet to become Running and Ready. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w +``` +The output is similar to: +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 3m web-1 0/1 ContainerCreating 0 11s @@ -697,32 +807,33 @@ web-0 0/1 ContainerCreating 0 0s web-0 1/1 Running 0 3s ``` -Get the Pod's containers. +Get the container image details for the Pods in the StatefulSet: ```shell -for p in 0 1 2; do kubectl get po web-$p --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done +for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done +``` +``` k8s.gcr.io/nginx-slim:0.7 k8s.gcr.io/nginx-slim:0.7 k8s.gcr.io/nginx-slim:0.7 - ``` -By moving the `partition` to `0`, you allowed the StatefulSet controller to +By moving the `partition` to `0`, you allowed the StatefulSet to continue the update process. ### On Delete -The `OnDelete` update strategy implements the legacy (1.6 and prior) behavior, -When you select this update strategy, the StatefulSet controller will not -automatically update Pods when a modification is made to the StatefulSet's -`.spec.template` field. This strategy can be selected by setting the +The `OnDelete` update strategy implements the legacy (1.6 and prior) behavior, +When you select this update strategy, the StatefulSet controller will not +automatically update Pods when a modification is made to the StatefulSet's +`.spec.template` field. This strategy can be selected by setting the `.spec.template.updateStrategy.type` to `OnDelete`. ## Deleting StatefulSets -StatefulSet supports both Non-Cascading and Cascading deletion. In a -Non-Cascading Delete, the StatefulSet's Pods are not deleted when the StatefulSet is deleted. In a Cascading Delete, both the StatefulSet and its Pods are +StatefulSet supports both Non-Cascading and Cascading deletion. In a +Non-Cascading Delete, the StatefulSet's Pods are not deleted when the StatefulSet is deleted. In a Cascading Delete, both the StatefulSet and its Pods are deleted. ### Non-Cascading Delete @@ -733,20 +844,24 @@ In one terminal window, watch the Pods in the StatefulSet. kubectl get pods -w -l app=nginx ``` -Use [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) to delete the -StatefulSet. Make sure to supply the `--cascade=false` parameter to the -command. This parameter tells Kubernetes to only delete the StatefulSet, and to +Use [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) to delete the +StatefulSet. Make sure to supply the `--cascade=false` parameter to the +command. This parameter tells Kubernetes to only delete the StatefulSet, and to not delete any of its Pods. ```shell kubectl delete statefulset web --cascade=false +``` +``` statefulset.apps "web" deleted ``` -Get the Pods to examine their status. +Get the Pods, to examine their status: ```shell kubectl get pods -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 6m web-1 1/1 Running 0 7m @@ -754,17 +869,21 @@ web-2 1/1 Running 0 5m ``` Even though `web` has been deleted, all of the Pods are still Running and Ready. -Delete `web-0`. +Delete `web-0`: ```shell kubectl delete pod web-0 +``` +``` pod "web-0" deleted ``` -Get the StatefulSet's Pods. +Get the StatefulSet's Pods: ```shell kubectl get pods -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-1 1/1 Running 0 10m web-2 1/1 Running 0 7m @@ -779,22 +898,26 @@ kubectl get pods -w -l app=nginx ``` In a second terminal, recreate the StatefulSet. Note that, unless -you deleted the `nginx` Service ( which you should not have ), you will see +you deleted the `nginx` Service (which you should not have), you will see an error indicating that the Service already exists. ```shell kubectl apply -f web.yaml +``` +``` statefulset.apps/web created service/nginx unchanged ``` -Ignore the error. It only indicates that an attempt was made to create the nginx -Headless Service even though that Service already exists. +Ignore the error. It only indicates that an attempt was made to create the _nginx_ +headless Service even though that Service already exists. Examine the output of the `kubectl get` command running in the first terminal. ```shell kubectl get pods -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-1 1/1 Running 0 16m web-2 1/1 Running 0 2m @@ -809,26 +932,28 @@ web-2 0/1 Terminating 0 3m web-2 0/1 Terminating 0 3m ``` -When the `web` StatefulSet was recreated, it first relaunched `web-0`. +When the `web` StatefulSet was recreated, it first relaunched `web-0`. Since `web-1` was already Running and Ready, when `web-0` transitioned to - Running and Ready, it simply adopted this Pod. Since you recreated the StatefulSet - with `replicas` equal to 2, once `web-0` had been recreated, and once - `web-1` had been determined to already be Running and Ready, `web-2` was - terminated. + Running and Ready, it simply adopted this Pod. Since you recreated the StatefulSet + with `replicas` equal to 2, once `web-0` had been recreated, and once + `web-1` had been determined to already be Running and Ready, `web-2` was + terminated. -Let's take another look at the contents of the `index.html` file served by the -Pods' webservers. +Let's take another look at the contents of the `index.html` file served by the +Pods' webservers: ```shell -for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done +for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done +``` +``` web-0 web-1 ``` -Even though you deleted both the StatefulSet and the `web-0` Pod, it still -serves the hostname originally entered into its `index.html` file. This is -because the StatefulSet never deletes the PersistentVolumes associated with a -Pod. When you recreated the StatefulSet and it relaunched `web-0`, its original +Even though you deleted both the StatefulSet and the `web-0` Pod, it still +serves the hostname originally entered into its `index.html` file. This is +because the StatefulSet never deletes the PersistentVolumes associated with a +Pod. When you recreated the StatefulSet and it relaunched `web-0`, its original PersistentVolume was remounted. ### Cascading Delete @@ -839,18 +964,22 @@ In one terminal window, watch the Pods in the StatefulSet. kubectl get pods -w -l app=nginx ``` -In another terminal, delete the StatefulSet again. This time, omit the +In another terminal, delete the StatefulSet again. This time, omit the `--cascade=false` parameter. ```shell kubectl delete statefulset web +``` +``` statefulset.apps "web" deleted ``` -Examine the output of the `kubectl get` command running in the first terminal, +Examine the output of the `kubectl get` command running in the first terminal, and wait for all of the Pods to transition to Terminating. ```shell kubectl get pods -w -l app=nginx +``` +``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 11m web-1 1/1 Running 0 27m @@ -866,88 +995,105 @@ web-1 0/1 Terminating 0 29m ``` -As you saw in the [Scaling Down](#scaling-down) section, the Pods -are terminated one at a time, with respect to the reverse order of their ordinal -indices. Before terminating a Pod, the StatefulSet controller waits for +As you saw in the [Scaling Down](#scaling-down) section, the Pods +are terminated one at a time, with respect to the reverse order of their ordinal +indices. Before terminating a Pod, the StatefulSet controller waits for the Pod's successor to be completely terminated. -Note that, while a cascading delete will delete the StatefulSet and its Pods, -it will not delete the Headless Service associated with the StatefulSet. You -must delete the `nginx` Service manually. +{{< note >}} +Although a cascading delete removes a StatefulSet together with its Pods, +the cascade does not delete the headless Service associated with the StatefulSet. +You must delete the `nginx` Service manually. +{{< /note >}} + ```shell kubectl delete service nginx +``` +``` service "nginx" deleted ``` -Recreate the StatefulSet and Headless Service one more time. +Recreate the StatefulSet and headless Service one more time: ```shell kubectl apply -f web.yaml +``` +``` service/nginx created statefulset.apps/web created ``` -When all of the StatefulSet's Pods transition to Running and Ready, retrieve -the contents of their `index.html` files. +When all of the StatefulSet's Pods transition to Running and Ready, retrieve +the contents of their `index.html` files: ```shell -for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done +for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done +``` +``` web-0 web-1 ``` -Even though you completely deleted the StatefulSet, and all of its Pods, the -Pods are recreated with their PersistentVolumes mounted, and `web-0` and -`web-1` will still serve their hostnames. +Even though you completely deleted the StatefulSet, and all of its Pods, the +Pods are recreated with their PersistentVolumes mounted, and `web-0` and +`web-1` continue to serve their hostnames. -Finally delete the `web` StatefulSet and the `nginx` service. +Finally, delete the `web` StatefulSet... ```shell kubectl delete service nginx +``` +``` service "nginx" deleted - +``` +...and the `nginx` Service: +```shell kubectl delete statefulset web +``` +``` statefulset "web" deleted ``` ## Pod Management Policy -For some distributed systems, the StatefulSet ordering guarantees are -unnecessary and/or undesirable. These systems require only uniqueness and -identity. To address this, in Kubernetes 1.7, we introduced -`.spec.podManagementPolicy` to the StatefulSet API Object. +For some distributed systems, the StatefulSet ordering guarantees are +unnecessary and/or undesirable. These systems require only uniqueness and +identity. To address this, in Kubernetes 1.7, we introduced +`.spec.podManagementPolicy` to the StatefulSet API Object. ### OrderedReady Pod Management -`OrderedReady` pod management is the default for StatefulSets. It tells the -StatefulSet controller to respect the ordering guarantees demonstrated +`OrderedReady` pod management is the default for StatefulSets. It tells the +StatefulSet controller to respect the ordering guarantees demonstrated above. ### Parallel Pod Management -`Parallel` pod management tells the StatefulSet controller to launch or -terminate all Pods in parallel, and not to wait for Pods to become Running -and Ready or completely terminated prior to launching or terminating another +`Parallel` pod management tells the StatefulSet controller to launch or +terminate all Pods in parallel, and not to wait for Pods to become Running +and Ready or completely terminated prior to launching or terminating another Pod. {{< codenew file="application/web/web-parallel.yaml" >}} Download the example above, and save it to a file named `web-parallel.yaml` -This manifest is identical to the one you downloaded above except that the `.spec.podManagementPolicy` +This manifest is identical to the one you downloaded above except that the `.spec.podManagementPolicy` of the `web` StatefulSet is set to `Parallel`. In one terminal, watch the Pods in the StatefulSet. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w ``` -In another terminal, create the StatefulSet and Service in the manifest. +In another terminal, create the StatefulSet and Service in the manifest: ```shell kubectl apply -f web-parallel.yaml +``` +``` service/nginx created statefulset.apps/web created ``` @@ -955,7 +1101,9 @@ statefulset.apps/web created Examine the output of the `kubectl get` command that you executed in the first terminal. ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w +``` +``` NAME READY STATUS RESTARTS AGE web-0 0/1 Pending 0 0s web-0 0/1 Pending 0 0s @@ -969,17 +1117,19 @@ web-1 1/1 Running 0 10s The StatefulSet controller launched both `web-0` and `web-1` at the same time. -Keep the second terminal open, and, in another terminal window scale the -StatefulSet. +Keep the second terminal open, and, in another terminal window scale the +StatefulSet: ```shell kubectl scale statefulset/web --replicas=4 +``` +``` statefulset.apps/web scaled ``` Examine the output of the terminal where the `kubectl get` command is running. -```shell +``` web-3 0/1 Pending 0 0s web-3 0/1 Pending 0 0s web-3 0/1 Pending 0 7s @@ -989,18 +1139,24 @@ web-3 1/1 Running 0 26s ``` -The StatefulSet controller launched two new Pods, and it did not wait for +The StatefulSet launched two new Pods, and it did not wait for the first to become Running and Ready prior to launching the second. -Keep this terminal open, and in another terminal delete the `web` StatefulSet. +## {{% heading "cleanup" %}} + +You should have two terminals open, ready for you to run `kubectl` commands as +part of cleanup. ```shell kubectl delete sts web +# sts is an abbreviation for statefulset ``` -Again, examine the output of the `kubectl get` command running in the other terminal. - +You can watch `kubectl get` to see those Pods being deleted. ```shell +kubectl get pod -l app=nginx -w +``` +``` web-3 1/1 Terminating 0 9m web-2 1/1 Terminating 0 9m web-3 1/1 Terminating 0 9m @@ -1026,22 +1182,22 @@ web-3 0/1 Terminating 0 9m web-3 0/1 Terminating 0 9m ``` -The StatefulSet controller deletes all Pods concurrently, it does not wait for +During deletion, a StatefulSet removes all Pods concurrently; it does not wait for a Pod's ordinal successor to terminate prior to deleting that Pod. -Close the terminal where the `kubectl get` command is running and delete the `nginx` -Service. +Close the terminal where the `kubectl get` command is running and delete the `nginx` +Service: ```shell kubectl delete svc nginx ``` -{{% /capture %}} - -{{% capture cleanup %}} -You will need to delete the persistent storage media for the PersistentVolumes -used in this tutorial. Follow the necessary steps, based on your environment, -storage configuration, and provisioning method, to ensure that all storage is -reclaimed. -{{% /capture %}} +{{< note >}} +You also need to delete the persistent storage media for the PersistentVolumes +used in this tutorial. + + +Follow the necessary steps, based on your environment, storage configuration, +and provisioning method, to ensure that all storage is reclaimed. +{{< /note >}} diff --git a/content/en/docs/tutorials/stateful-application/cassandra.md b/content/en/docs/tutorials/stateful-application/cassandra.md index f55a852abb..3fa56b26ea 100644 --- a/content/en/docs/tutorials/stateful-application/cassandra.md +++ b/content/en/docs/tutorials/stateful-application/cassandra.md @@ -2,11 +2,11 @@ title: "Example: Deploying Cassandra with a StatefulSet" reviewers: - ahmetb -content_template: templates/tutorial +content_type: tutorial weight: 30 --- -{{% capture overview %}} + This tutorial shows you how to run [Apache Cassandra](http://cassandra.apache.org/) on Kubernetes. Cassandra, a database, needs persistent storage to provide data durability (application _state_). In this example, a custom Cassandra seed provider lets the database discover new Cassandra instances as they join the Cassandra cluster. *StatefulSets* make it easier to deploy stateful applications into your Kubernetes cluster. For more information on the features used in this tutorial, see [StatefulSet](/docs/concepts/workloads/controllers/statefulset/). @@ -23,17 +23,19 @@ nodes in the ring. This tutorial deploys a custom Cassandra seed provider that lets the database discover new Cassandra Pods as they appear inside your Kubernetes cluster. {{< /note >}} -{{% /capture %}} -{{% capture objectives %}} + +## {{% heading "objectives" %}} + * Create and validate a Cassandra headless {{< glossary_tooltip text="Service" term_id="service" >}}. * Use a {{< glossary_tooltip term_id="StatefulSet" >}} to create a Cassandra ring. * Validate the StatefulSet. * Modify the StatefulSet. * Delete the StatefulSet and its {{< glossary_tooltip text="Pods" term_id="pod" >}}. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} To complete this tutorial, you should already have a basic familiarity with {{< glossary_tooltip text="Pods" term_id="pod" >}}, {{< glossary_tooltip text="Services" term_id="service" >}}, and {{< glossary_tooltip text="StatefulSets" term_id="StatefulSet" >}}. @@ -48,9 +50,9 @@ minikube start --memory 5120 --cpus=4 ``` {{< /caution >}} -{{% /capture %}} -{{% capture lessoncontent %}} + + ## Creating a headless Service for Cassandra {#creating-a-cassandra-headless-service} In Kubernetes, a {{< glossary_tooltip text="Service" term_id="service" >}} describes a set of {{< glossary_tooltip text="Pods" term_id="pod" >}} that perform the same task. @@ -219,9 +221,10 @@ Use `kubectl edit` to modify the size of a Cassandra StatefulSet. cassandra 4 4 36m ``` -{{% /capture %}} -{{% capture cleanup %}} + +## {{% heading "cleanup" %}} + Deleting or scaling a StatefulSet down does not delete the volumes associated with the StatefulSet. This setting is for your safety because your data is more valuable than automatically purging all related StatefulSet resources. {{< warning >}} @@ -261,12 +264,13 @@ By using environment variables you can change values that are inserted into `cas | `CASSANDRA_RPC_ADDRESS` | `0.0.0.0` | -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn how to [Scale a StatefulSet](/docs/tasks/run-application/scale-stateful-set/). * Learn more about the [*KubernetesSeedProvider*](https://github.com/kubernetes/examples/blob/master/cassandra/java/src/main/java/io/k8s/cassandra/KubernetesSeedProvider.java) * See more custom [Seed Provider Configurations](https://git.k8s.io/examples/cassandra/java/README.md) -{{% /capture %}} + diff --git a/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index 0f97c2160b..d43d9b736f 100644 --- a/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -2,7 +2,7 @@ title: "Example: Deploying WordPress and MySQL with Persistent Volumes" reviewers: - ahmetb -content_template: templates/tutorial +content_type: tutorial weight: 20 card: name: tutorials @@ -10,7 +10,7 @@ card: title: "Stateful Example: Wordpress with Persistent Volumes" --- -{{% capture overview %}} + This tutorial shows you how to deploy a WordPress site and a MySQL database using Minikube. Both applications use PersistentVolumes and PersistentVolumeClaims to store data. A [PersistentVolume](/docs/concepts/storage/persistent-volumes/) (PV) is a piece of storage in the cluster that has been manually provisioned by an administrator, or dynamically provisioned by Kubernetes using a [StorageClass](/docs/concepts/storage/storage-classes). A [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) (PVC) is a request for storage by a user that can be fulfilled by a PV. PersistentVolumes and PersistentVolumeClaims are independent from Pod lifecycles and preserve data through restarting, rescheduling, and even deleting Pods. @@ -23,9 +23,10 @@ This deployment is not suitable for production use cases, as it uses single inst The files provided in this tutorial are using GA Deployment APIs and are specific to kubernetes version 1.9 and later. If you wish to use this tutorial with an earlier version of Kubernetes, please update the API version appropriately, or reference earlier versions of this tutorial. {{< /note >}} -{{% /capture %}} -{{% capture objectives %}} + +## {{% heading "objectives" %}} + * Create PersistentVolumeClaims and PersistentVolumes * Create a `kustomization.yaml` with * a Secret generator @@ -34,9 +35,10 @@ The files provided in this tutorial are using GA Deployment APIs and are specifi * Apply the kustomization directory by `kubectl apply -k ./` * Clean up -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} The example shown on this page works with `kubectl` 1.14 and above. @@ -47,9 +49,9 @@ Download the following configuration files: 1. [wordpress-deployment.yaml](/examples/application/wordpress/wordpress-deployment.yaml) -{{% /capture %}} -{{% capture lessoncontent %}} + + ## Create PersistentVolumeClaims and PersistentVolumes @@ -218,9 +220,10 @@ Now you can verify that all objects exist. Do not leave your WordPress installation on this page. If another user finds it, they can set up a website on your instance and use it to serve malicious content.

Either install WordPress by creating a username and password or delete your instance. {{< /warning >}} -{{% /capture %}} -{{% capture cleanup %}} + +## {{% heading "cleanup" %}} + 1. Run the following command to delete your Secret, Deployments, Services and PersistentVolumeClaims: @@ -228,14 +231,15 @@ Do not leave your WordPress installation on this page. If another user finds it, kubectl delete -k ./ ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn more about [Introspection and Debugging](/docs/tasks/debug-application-cluster/debug-application-introspection/) -* Learn more about [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) +* Learn more about [Jobs](/docs/concepts/workloads/controllers/job/) * Learn more about [Port Forwarding](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) * Learn how to [Get a Shell to a Container](/docs/tasks/debug-application-cluster/get-shell-running-container/) -{{% /capture %}} + diff --git a/content/en/docs/tutorials/stateful-application/zookeeper.md b/content/en/docs/tutorials/stateful-application/zookeeper.md index ee58827f83..3bed3e059c 100644 --- a/content/en/docs/tutorials/stateful-application/zookeeper.md +++ b/content/en/docs/tutorials/stateful-application/zookeeper.md @@ -8,18 +8,19 @@ reviewers: - kow3ns - smarterclayton title: Running ZooKeeper, A Distributed System Coordinator -content_template: templates/tutorial +content_type: tutorial weight: 40 --- -{{% capture overview %}} + This tutorial demonstrates running [Apache Zookeeper](https://zookeeper.apache.org) on Kubernetes using [StatefulSets](/docs/concepts/workloads/controllers/statefulset/), [PodDisruptionBudgets](/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget), and [PodAntiAffinity](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature). -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + Before starting this tutorial, you should be familiar with the following Kubernetes concepts. @@ -40,18 +41,19 @@ This tutorial assumes that you have configured your cluster to dynamically provi PersistentVolumes. If your cluster is not configured to do so, you will have to manually provision three 20 GiB volumes before starting this tutorial. -{{% /capture %}} -{{% capture objectives %}} + +## {{% heading "objectives" %}} + After this tutorial, you will know the following. - How to deploy a ZooKeeper ensemble using StatefulSet. - How to consistently configure the ensemble using ConfigMaps. - How to spread the deployment of ZooKeeper servers in the ensemble. - How to use PodDisruptionBudgets to ensure service availability during planned maintenance. - {{% /capture %}} + -{{% capture lessoncontent %}} + ### ZooKeeper Basics @@ -1090,9 +1092,10 @@ node "kubernetes-node-ixsl" uncordoned You can use `kubectl drain` in conjunction with `PodDisruptionBudgets` to ensure that your services remain available during maintenance. If drain is used to cordon nodes and evict pods prior to taking the node offline for maintenance, services that express a disruption budget will have that budget respected. You should always allocate additional capacity for critical services so that their Pods can be immediately rescheduled. -{{% /capture %}} -{{% capture cleanup %}} + +## {{% heading "cleanup" %}} + - Use `kubectl uncordon` to uncordon all the nodes in your cluster. - You will need to delete the persistent storage media for the PersistentVolumes @@ -1100,5 +1103,5 @@ You can use `kubectl drain` in conjunction with `PodDisruptionBudgets` to ensure storage configuration, and provisioning method, to ensure that all storage is reclaimed. -{{% /capture %}} + diff --git a/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md index 4f4dbda986..2974c77c94 100644 --- a/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md +++ b/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md @@ -1,18 +1,19 @@ --- title: Exposing an External IP Address to Access an Application in a Cluster -content_template: templates/tutorial +content_type: tutorial weight: 10 --- -{{% capture overview %}} + This page shows how to create a Kubernetes Service object that exposes an external IP address. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * Install [kubectl](/docs/tasks/tools/install-kubectl/). @@ -24,19 +25,20 @@ external IP address. * Configure `kubectl` to communicate with your Kubernetes API server. For instructions, see the documentation for your cloud provider. -{{% /capture %}} -{{% capture objectives %}} + +## {{% heading "objectives" %}} + * Run five instances of a Hello World application. * Create a Service object that exposes an external IP address. * Use the Service object to access the running application. -{{% /capture %}} -{{% capture lessoncontent %}} + + ## Creating a service for an application running in five pods @@ -148,10 +150,11 @@ The preceding command creates a Hello Kubernetes! -{{% /capture %}} -{{% capture cleanup %}} + +## {{% heading "cleanup" %}} + To delete the Service, enter this command: @@ -162,11 +165,12 @@ the Hello World application, enter this command: kubectl delete deployment hello-world -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + Learn more about [connecting applications with services](/docs/concepts/services-networking/connect-applications-service/). -{{% /capture %}} + diff --git a/content/en/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md b/content/en/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md index bc991098d5..0c4964a17f 100644 --- a/content/en/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md +++ b/content/en/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md @@ -2,7 +2,7 @@ title: "Example: Add logging and metrics to the PHP / Redis Guestbook example" reviewers: - sftim -content_template: templates/tutorial +content_type: tutorial weight: 21 card: name: tutorials @@ -10,7 +10,7 @@ card: title: "Example: Add logging and metrics to the PHP / Redis Guestbook example" --- -{{% capture overview %}} + This tutorial builds upon the [PHP Guestbook with Redis](/docs/tutorials/stateless-application/guestbook) tutorial. Lightweight log, metric, and network data open source shippers, or *Beats*, from Elastic are deployed in the same Kubernetes cluster as the guestbook. The Beats collect, parse, and index the data into Elasticsearch so that you can view and analyze the resulting operational information in Kibana. This example consists of the following components: * A running instance of the [PHP Guestbook with Redis tutorial](/docs/tutorials/stateless-application/guestbook) @@ -19,17 +19,19 @@ This tutorial builds upon the [PHP Guestbook with Redis](/docs/tutorials/statele * Metricbeat * Packetbeat -{{% /capture %}} -{{% capture objectives %}} + +## {{% heading "objectives" %}} + * Start up the PHP Guestbook with Redis. * Install kube-state-metrics. * Create a Kubernetes secret. * Deploy the Beats. * View dashboards of your logs and metrics. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} @@ -40,9 +42,9 @@ Additionally you need: * A running Elasticsearch and Kibana deployment. You can use [Elasticsearch Service in Elastic Cloud](https://cloud.elastic.co), run the [download files](https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-elastic-stack.html) on your workstation or servers, or the [Elastic Helm Charts](https://github.com/elastic/helm-charts). -{{% /capture %}} -{{% capture lessoncontent %}} + + ## Start up the PHP Guestbook with Redis This tutorial builds on the [PHP Guestbook with Redis](/docs/tutorials/stateless-application/guestbook) tutorial. If you have the guestbook application running, then you can monitor that. If you do not have it running then follow the instructions to deploy the guestbook and do not perform the **Cleanup** steps. Come back to this page when you have the guestbook running. @@ -366,9 +368,10 @@ kubectl scale --replicas=3 deployment/frontend See the screenshot, add the indicated filters and then add the columns to the view. You can see the ScalingReplicaSet entry that is marked, following from there to the top of the list of events shows the image being pulled, the volumes mounted, the pod starting, etc. ![Kibana Discover](https://raw.githubusercontent.com/elastic/examples/master/beats-k8s-send-anywhere/scaling-up.png) -{{% /capture %}} -{{% capture cleanup %}} + +## {{% heading "cleanup" %}} + Deleting the Deployments and Services also deletes any running Pods. Use labels to delete multiple resources with one command. 1. Run the following commands to delete all Pods, Deployments, and Services. @@ -396,11 +399,11 @@ Deleting the Deployments and Services also deletes any running Pods. Use labels No resources found. ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Learn about [tools for monitoring resources](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) * Read more about [logging architecture](/docs/concepts/cluster-administration/logging/) * Read more about [application introspection and debugging](/docs/tasks/debug-application-cluster/) * Read more about [troubleshoot applications](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) -{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/tutorials/stateless-application/guestbook.md b/content/en/docs/tutorials/stateless-application/guestbook.md index e8c71bc613..f321d5391a 100644 --- a/content/en/docs/tutorials/stateless-application/guestbook.md +++ b/content/en/docs/tutorials/stateless-application/guestbook.md @@ -2,7 +2,7 @@ title: "Example: Deploying PHP Guestbook application with Redis" reviewers: - ahmetb -content_template: templates/tutorial +content_type: tutorial weight: 20 card: name: tutorials @@ -10,32 +10,34 @@ card: title: "Stateless Example: PHP Guestbook with Redis" --- -{{% capture overview %}} + This tutorial shows you how to build and deploy a simple, multi-tier web application using Kubernetes and [Docker](https://www.docker.com/). This example consists of the following components: * A single-instance [Redis](https://redis.io/) master to store guestbook entries * Multiple [replicated Redis](https://redis.io/topics/replication) instances to serve reads * Multiple web frontend instances -{{% /capture %}} -{{% capture objectives %}} + +## {{% heading "objectives" %}} + * Start up a Redis master. * Start up Redis slaves. * Start up the guestbook frontend. * Expose and view the Frontend Service. * Clean up. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture lessoncontent %}} + + ## Start up the Redis Master @@ -321,9 +323,10 @@ Scaling up or down is easy because your servers are defined as a Service that us redis-slave-2005841000-phfv9 1/1 Running 0 1h ``` -{{% /capture %}} -{{% capture cleanup %}} + +## {{% heading "cleanup" %}} + Deleting the Deployments and Services also deletes any running Pods. Use labels to delete multiple resources with one command. 1. Run the following commands to delete all Pods, Deployments, and Services. @@ -358,12 +361,13 @@ Deleting the Deployments and Services also deletes any running Pods. Use labels No resources found. ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Add [ELK logging and monitoring](../guestbook-logs-metrics-with-elk/) to your Guestbook application * Complete the [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) Interactive Tutorials * Use Kubernetes to create a blog using [Persistent Volumes for MySQL and Wordpress](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog) * Read more about [connecting applications](/docs/concepts/services-networking/connect-applications-service/) * Read more about [Managing Resources](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively) -{{% /capture %}} + diff --git a/content/en/examples/application/deployment-retainkeys.yaml b/content/en/examples/application/deployment-retainkeys.yaml new file mode 100644 index 0000000000..b5e04f0cc1 --- /dev/null +++ b/content/en/examples/application/deployment-retainkeys.yaml @@ -0,0 +1,19 @@ +apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +kind: Deployment +metadata: + name: retainkeys-demo +spec: + selector: + matchLabels: + app: nginx + strategy: + rollingUpdate: + maxSurge: 30% + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: retainkeys-demo-ctr + image: nginx diff --git a/content/en/partners/_index.html b/content/en/partners/_index.html index 3e76bffbc6..c652514ac4 100644 --- a/content/en/partners/_index.html +++ b/content/en/partners/_index.html @@ -7,79 +7,90 @@ cid: partners ---
-
-
Kubernetes works with partners to create a strong, vibrant codebase that supports a spectrum of complementary platforms.
-
-
-
-
- Kubernetes Certified Service Providers -
-
Vetted service providers with deep experience helping enterprises successfully adopt Kubernetes. -


- -

Interested in becoming a KCSP? -
-
-
-
-
- Certified Kubernetes Distributions, Hosted Platforms, and Installers -
Software conformance ensures that every vendor’s version of Kubernetes supports the required APIs. -


- -

Interested in becoming Kubernetes Certified? -
-
-
-
-
Kubernetes Training Partners
-
Vetted training providers who have deep experience in cloud native technology training. -



- -

Interested in becoming a KTP? -
-
-
- - + - -
- - -
- -
+ + +
+ + +
+ +
+ + diff --git a/content/ja/training/_index.html b/content/ja/training/_index.html new file mode 100644 index 0000000000..8c92ea7f22 --- /dev/null +++ b/content/ja/training/_index.html @@ -0,0 +1,118 @@ +--- +title: トレーニング +bigheader: Kubernetesのトレーニングと資格 +abstract: トレーニングプログラム、資格、及びパートナーについて。 +layout: basic +cid: training +class: training +--- + +
+
+
+
+ +
+
+ +
+
+

あなたのクラウドネイティブなキャリアを創る

+

Kubernetesはクラウドネイティブムーブメントの中核を担っています。Linux Foundation及びトレーニングパートナーのトレーニングを受け、認定資格を取得することで、キャリアに投資し、Kubernetesを学び、クラウドネイティブプロジェクトを成功に繋げます。

+
+
+
+
+ +
+
+
+

edXで無料コースを受講する

+
+
+
+
+
+ Kubernetes入門
  +
+

Kubernetesを学びたいですか？コンテナ化されたアプリケーションを管理するための強力なシステムに入門しましょう。

+
+ コースに行く +
+
+
+
+
+ クラウドインフラ技術入門 +
+

オープンソースのリーダーであるThe Linux Foundationから直接、クラウドテクノロジーの構築と管理の基本を学びます。

+
+ コースに行く +
+
+
+
+
+ Linux入門 +
+

Linuxを学ぶのは初めてですか？知識を更新したいですか？主要なLinuxディストリビューションでGUIとCLIの両方を使用し、Linuxの実用的な知識を深めます。

+
+ コースに行く +
+
+
+
+ +
+
+
+

Linux Foundationと共に学ぶ

+

Linux Foundationは、Kubernetesアプリケーションの開発と運用のライフサイクルのあらゆる側面について、インストラクター主導の自己学習コースを提供しています。

+

+ コースを見る +
+
+
+ +
+
+
+

Kubernetes認定資格を受験する

+
+
+
+
+
+ 認定Kubernetesアプリケーション開発者(Certified Kubernetes Application Developer, CKAD) +
+

認定Kubernetesアプリケーション開発者(CKAD)試験は、ユーザーがKubernetes向けにクラウドネイティブアプリケーションを設計、構築、構成、公開できることを証明します。

+
+ 試験を受ける +
+
+
+
+
+ 認定Kubernetes管理者(Certified Kubernetes Administrator, CKA) +
+

認定Kubernetes管理者(CKA)プログラムは、保有者がKubernetes管理者の責務を実行するためのスキル、知識、および能力を持っていることを保証します。

+
+ 試験を受ける +
+
+
+
+
+ +
+
+
+

Kubernetesトレーニングパートナー

+

Kubernetesトレーニングパートナーネットワークは、Kubernetesおよびクラウドネイティブプロジェクトのトレーニングサービスを提供します。

+
+
+
+ + +
+
diff --git a/content/ko/_index.html b/content/ko/_index.html index 1017b6093e..c8d9d593c1 100644 --- a/content/ko/_index.html +++ b/content/ko/_index.html @@ -3,9 +3,6 @@ title: "운영 수준의 컨테이너 오케스트레이션" abstract: "자동화된 컨테이너 배포, 스케일링과 관리" cid: home --- -{{< announcement >}} - -{{< deprecationwarning >}} {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}} diff --git a/content/ko/community/_index.html b/content/ko/community/_index.html index 015e1a0b44..39d17396ff 100644 --- a/content/ko/community/_index.html +++ b/content/ko/community/_index.html @@ -17,7 +17,7 @@ cid: community
-
+
행동 강령       비디오      diff --git a/content/ko/docs/concepts/_index.md b/content/ko/docs/concepts/_index.md index 03a1d64ddd..30424ead72 100644 --- a/content/ko/docs/concepts/_index.md +++ b/content/ko/docs/concepts/_index.md @@ -1,17 +1,17 @@ --- title: 개념 main_menu: true -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + 개념 섹션을 통해 쿠버네티스 시스템을 구성하는 요소와 {{< glossary_tooltip text="클러스터" term_id="cluster" length="all" >}}를 표현하는데 사용되는 추상 개념에 대해 배우고 쿠버네티스가 작동하는 방식에 대해 보다 깊이 이해할 수 있다. -{{% /capture %}} -{{% capture body %}} + + ## 개요 @@ -60,12 +60,13 @@ weight: 40 클러스터 내 노드는 애플리케이션과 클라우드 워크플로우를 구동시키는 머신(VM, 물리 서버 등)이다. 쿠버네티스 마스터는 각 노드를 관리한다. 직접 노드와 직접 상호 작용할 일은 거의 없을 것이다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + 개념 페이지를 작성하기를 원하면, 개념 페이지 유형과 개념 템플릿에 대한 정보가 있는 [페이지 템플릿 사용하기](/docs/home/contribute/page-templates/)를 참조한다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/architecture/cloud-controller.md b/content/ko/docs/concepts/architecture/cloud-controller.md index 83bc1d246c..12b1d714e8 100644 --- a/content/ko/docs/concepts/architecture/cloud-controller.md +++ b/content/ko/docs/concepts/architecture/cloud-controller.md @@ -1,10 +1,10 @@ --- title: 클라우드 컨트롤러 매니저 -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + {{< feature-state state="beta" for_k8s_version="v1.11" >}} @@ -17,10 +17,10 @@ weight: 40 클라우드 컨트롤러 매니저는 다양한 클라우드 공급자가 자신의 플랫폼에 쿠버네티스를 통합할 수 있도록 하는 플러그인 메커니즘을 사용해서 구성된다. -{{% /capture %}} -{{% capture body %}} + + ## 디자인 @@ -200,8 +200,9 @@ rules: - update ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + [클라우드 컨트롤러 매니저 관리](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)에는 클라우드 컨트롤러 매니저의 실행과 관리에 대한 지침이 있다. @@ -212,4 +213,4 @@ rules: 이 문서(노드, 라우트와 서비스)에서 강조된 공유 컨트롤러의 구현과 공유 cloudprovider 인터페이스와 함께 일부 스캐폴딩(scaffolding)은 쿠버네티스 핵심의 일부이다. 클라우드 공급자 전용 구현은 쿠버네티스의 핵심 바깥에 있으며 `CloudProvider` 인터페이스를 구현한다. 플러그인 개발에 대한 자세한 내용은 [클라우드 컨트롤러 매니저 개발하기](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)를 참조한다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/architecture/control-plane-node-communication.md b/content/ko/docs/concepts/architecture/control-plane-node-communication.md index a037452ef3..819ee0c384 100644 --- a/content/ko/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/ko/docs/concepts/architecture/control-plane-node-communication.md @@ -1,18 +1,18 @@ --- title: 컨트롤 플레인-노드 간 통신 -content_template: templates/concept +content_type: concept weight: 20 aliases: - master-node-communication --- -{{% capture overview %}} + 이 문서는 컨트롤 플레인(실제로는 API 서버)과 쿠버네티스 클러스터 사이에 대한 통신 경로의 목록을 작성한다. 이는 사용자가 신뢰할 수 없는 네트워크(또는 클라우드 공급자의 완전한 퍼블릭 IP)에서 클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다. -{{% /capture %}} -{{% capture body %}} + + ## 노드에서 컨트롤 플레인으로의 통신 노드에서 컨트롤 플레인까지의 모든 통신 경로는 API 서버에서 종료된다(다른 마스터 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다). 일반적인 배포에서 API 서버는 하나 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(443)에서 원격 연결을 수신하도록 구성된다. diff --git a/content/ko/docs/concepts/architecture/controller.md b/content/ko/docs/concepts/architecture/controller.md index b8c6556b2a..6688a969d7 100644 --- a/content/ko/docs/concepts/architecture/controller.md +++ b/content/ko/docs/concepts/architecture/controller.md @@ -1,10 +1,10 @@ --- title: 컨트롤러 -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + 로보틱스와 자동화에서 _컨트롤 루프_ 는 시스템 상태를 조절하는 종료되지 않는 루프이다. @@ -18,10 +18,10 @@ weight: 30 {{< glossary_definition term_id="controller" length="short">}} -{{% /capture %}} -{{% capture body %}} + + ## 컨트롤러 패턴 @@ -150,11 +150,12 @@ weight: 30 또는 쿠버네티스 외부에서 실행할 수 있다. 가장 적합한 것은 특정 컨트롤러의 기능에 따라 달라진다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [쿠버네티스 컨트롤 플레인](/ko/docs/concepts/#쿠버네티스-컨트롤-플레인)에 대해 읽기 * [쿠버네티스 오브젝트](/ko/docs/concepts/#쿠버네티스-오브젝트)의 몇 가지 기본 사항을 알아보자. * [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)에 대해 더 배워 보자. * 만약 자신만의 컨트롤러를 작성하기 원한다면, 쿠버네티스 확장하기의 [확장 패턴](/ko/docs/concepts/extend-kubernetes/extend-cluster/#익스텐션-패턴)을 본다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index 34690c7825..197ae71422 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -1,10 +1,10 @@ --- title: 노드 -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + 쿠버네티스는 컨테이너를 파드내에 배치하고 _노드_ 에서 실행함으로 워크로드를 구동한다. 노드는 클러스터에 따라 가상 또는 물리적 머신일 수 있다. 각 노드에는 @@ -20,9 +20,9 @@ weight: 10 {{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}} 그리고 {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}가 포함된다. -{{% /capture %}} -{{% capture body %}} + + ## 관리 @@ -322,12 +322,13 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 자세한 내용은 [노드의 컨트롤 토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)을 본다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * 노드를 구성하는 [컴포넌트](/ko/docs/concepts/overview/components/#노드-컴포넌트)에 대해 알아본다. * [노드에 대한 API 정의](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)를 읽어본다. * 아키텍처 디자인 문서의 [노드](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) 섹션을 읽어본다. * [테인트와 톨러레이션](/ko/docs/concepts/configuration/taint-and-toleration/)을 읽어본다. * [클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)을 읽어본다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/cluster-administration/addons.md b/content/ko/docs/concepts/cluster-administration/addons.md index ac66c7baa4..9e6f5ab7ec 100644 --- a/content/ko/docs/concepts/cluster-administration/addons.md +++ b/content/ko/docs/concepts/cluster-administration/addons.md @@ -1,9 +1,9 @@ --- title: 애드온 설치 -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + 애드온은 쿠버네티스의 기능을 확장한다. @@ -12,10 +12,10 @@ content_template: templates/concept 각 섹션의 애드온은 알파벳 순으로 정렬되어 있다. 순서는 우선 순위와는 상관없다. -{{% /capture %}} -{{% capture body %}} + + ## 네트워킹과 네트워크 폴리시 @@ -55,4 +55,4 @@ content_template: templates/concept 잘 관리된 것들이 여기에 연결되어 있어야 한다. PR을 환영한다! -{{% /capture %}} + diff --git a/content/ko/docs/concepts/cluster-administration/certificates.md b/content/ko/docs/concepts/cluster-administration/certificates.md index cadcef4b17..d7051e4145 100644 --- a/content/ko/docs/concepts/cluster-administration/certificates.md +++ b/content/ko/docs/concepts/cluster-administration/certificates.md @@ -1,19 +1,19 @@ --- title: 인증서 -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + 클라이언트 인증서로 인증을 사용하는 경우 `easyrsa`, `openssl` 또는 `cfssl` 을 통해 인증서를 수동으로 생성할 수 있다. -{{% /capture %}} -{{% capture body %}} + + ### easyrsa @@ -249,4 +249,4 @@ done. [여기](/docs/tasks/tls/managing-tls-in-a-cluster)에 설명된 대로 인증에 사용할 x509 인증서를 프로비전 할 수 있다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/cluster-administration/cloud-providers.md b/content/ko/docs/concepts/cluster-administration/cloud-providers.md index 702dc3a54c..30dc7b230e 100644 --- a/content/ko/docs/concepts/cluster-administration/cloud-providers.md +++ b/content/ko/docs/concepts/cluster-administration/cloud-providers.md @@ -1,16 +1,16 @@ --- title: 클라우드 제공자 -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + 이 페이지에서는 특정 클라우드 제공자에서 실행 중인 쿠버네티스를 관리하는 방법에 대해 설명한다. -{{% /capture %}} -{{% capture body %}} + + ### kubeadm [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)은 쿠버네티스 클러스터를 생성하는 데 많이 사용하는 옵션이다. kubeadm에는 클라우드 제공자에 대한 구성 정보를 지정하는 구성 옵션이 있다. 예를 들어 @@ -363,7 +363,7 @@ OpenStack 제공자에 대한 다음의 구성 옵션은 [kubenet] [kubenet]: /ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#kubenet -{{% /capture %}} + ## OVirt @@ -400,9 +400,9 @@ IBM 클라우드 쿠버네티스 서비스 제공자를 사용하면, 단일 영 쿠버네티스 노드 오브젝트의 이름은 IBM 클라우드 쿠버네티스 서비스 워커 노드 인스턴스의 프라이빗 IP 주소이다. ### 네트워킹 -IBM 클라우드 쿠버네티스 서비스 제공자는 노드의 네트워크 성능 품질과 네트워크 격리를 위한 VLAN을 제공한다. 사용자 정의 방화벽 및 Calico 네트워크 폴리시를 설정하여 클러스터에 추가적인 보안 계층을 추가하거나 VPN을 통해 온-프레미스 데이터센터에 클러스터를 연결할 수 있다. 자세한 내용은 [인-클러스터(in-cluster) 및 프라이빗 네트워킹 계획](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_cluster#cs_network_cluster)을 참고한다. +IBM 클라우드 쿠버네티스 서비스 제공자는 노드의 네트워크 성능 품질과 네트워크 격리를 위한 VLAN을 제공한다. 사용자 정의 방화벽 및 Calico 네트워크 폴리시를 설정하여 클러스터에 추가적인 보안 계층을 추가하거나 VPN을 통해 온-프레미스 데이터센터에 클러스터를 연결할 수 있다. 자세한 내용은 [클러스터 네트워킹 구성](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters)을 참고한다. -퍼블릭 또는 클러스터 내에서 앱을 노출하기 위해 노드포트(NodePort), 로드밸런서 또는 인그레스 서비스를 활용할 수 있다. 어노테이션을 사용하여 인그레스 애플리케이션 로드 밸런서를 커스터마이징 할 수도 있다. 자세한 내용은 [외부 네트워킹으로 앱 노출 계획](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning)을 참고한다. +퍼블릭 또는 클러스터 내에서 앱을 노출하기 위해 노드포트(NodePort), 로드밸런서 또는 인그레스 서비스를 활용할 수 있다. 어노테이션을 사용하여 인그레스 애플리케이션 로드 밸런서를 커스터마이징 할 수도 있다. 자세한 내용은 [앱을 노출할 서비스 선택하기](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning)을 참고한다. ### 스토리지 IBM 클라우드 쿠버네티스 서비스 제공자는 쿠버네티스-네이티브 퍼시스턴트 볼륨을 활용하여 사용자가 파일, 블록 및 클라우드 오브젝트 스토리지를 앱에 마운트할 수 있도록 한다. 데이터를 지속적으로 저장하기 위해 서비스로서의-데이터베이스(database-as-a-service)와 써드파티 애드온을 사용할 수도 있다. 자세한 정보는 [고가용성 퍼시스턴트 스토리지 계획](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning)을 참고한다. diff --git a/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md index 9a5aba856b..d454b85ca0 100644 --- a/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -1,15 +1,15 @@ --- title: 클러스터 관리 개요 -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + 클러스터 관리 개요는 쿠버네티스 클러스터를 만들거나 관리하는 모든 사람들을 위한 것이다. 여기서는 쿠버네티스의 핵심 [개념](/ko/docs/concepts/)에 대해 잘 알고 있다고 가정한다. -{{% /capture %}} -{{% capture body %}} + + ## 클러스터 계획 [올바른 솔루션 고르기](/ko/docs/setup/pick-right-solution/)에서 쿠버네티스 클러스터를 어떻게 계획하고, 셋업하고, 구성하는 지에 대한 예시를 참조하자. 이 글에 쓰여진 솔루션들은 *배포판* 이라고 부른다. @@ -65,4 +65,4 @@ weight: 10 * [클러스터 활동 로깅과 모니터링](/docs/concepts/cluster-administration/logging/)은 쿠버네티스 로깅이 로깅의 작동 방법과 로깅을 어떻게 구현하는지 설명한다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md index 348b3776f6..a6907ad44c 100644 --- a/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md +++ b/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md @@ -1,19 +1,19 @@ --- title: kubelet 가비지(Garbage) 수집 설정하기 -content_template: templates/concept +content_type: concept weight: 70 --- -{{% capture overview %}} + 가비지 수집은 사용되지 않는 이미지들과 컨테이너들을 정리하는 kubelet의 유용한 기능이다. Kubelet은 1분마다 컨테이너들에 대하여 가비지 수집을 수행하며, 5분마다 이미지들에 대하여 가비지 수집을 수행한다. 별도의 가비지 수집 도구들을 사용하는 것은, 이러한 도구들이 존재할 수도 있는 컨테이너들을 제거함으로써 kubelet 을 중단시킬 수도 있으므로 권장하지 않는다. -{{% /capture %}} -{{% capture body %}} + + ## 이미지 수집 @@ -77,10 +77,11 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대 | `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | 축출이 다른 리소스로의 디스크 압력전환을 일반화 함 | -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + 자세한 내용은 [리소스 부족 처리 구성](/docs/tasks/administer-cluster/out-of-resource/)를 본다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/cluster-administration/logging.md b/content/ko/docs/concepts/cluster-administration/logging.md index 51526e84cb..5c7ce6cd8d 100644 --- a/content/ko/docs/concepts/cluster-administration/logging.md +++ b/content/ko/docs/concepts/cluster-administration/logging.md @@ -1,19 +1,19 @@ --- title: 로깅 아키텍처 -content_template: templates/concept +content_type: concept weight: 60 --- -{{% capture overview %}} + 애플리케이션과 시스템 로그는 클러스터 내부에서 발생하는 상황을 이해하는 데 도움이 된다. 로그는 문제를 디버깅하고 클러스터 활동을 모니터링하는 데 특히 유용하다. 대부분의 최신 애플리케이션에는 일종의 로깅 메커니즘이 있다. 따라서, 대부분의 컨테이너 엔진은 일종의 로깅을 지원하도록 설계되었다. 컨테이너화된 애플리케이션에 가장 쉽고 가장 널리 사용되는 로깅 방법은 표준 출력과 표준 에러 스트림에 작성하는 것이다. 그러나, 일반적으로 컨테이너 엔진이나 런타임에서 제공하는 기본 기능은 완전한 로깅 솔루션으로 충분하지 않다. 예를 들어, 컨테이너가 크래시되거나, 파드가 축출되거나, 노드가 종료된 경우에도 여전히 애플리케이션의 로그에 접근하려고 한다. 따라서, 로그는 노드, 파드 또는 컨테이너와는 독립적으로 별도의 스토리지와 라이프사이클을 가져야 한다. 이 개념을 _클러스터-레벨-로깅_ 이라고 한다. 클러스터-레벨 로깅은 로그를 저장하고, 분석하고, 쿼리하기 위해 별도의 백엔드가 필요하다. 쿠버네티스는 로그 데이터를 위한 네이티브 스토리지 솔루션을 제공하지 않지만, 기존의 많은 로깅 솔루션을 쿠버네티스 클러스터에 통합할 수 있다. -{{% /capture %}} -{{% capture body %}} + + 클러스터-레벨 로깅 아키텍처는 로깅 백엔드가 클러스터 내부 또는 외부에 존재한다고 가정하여 설명한다. 클러스터-레벨 @@ -264,4 +264,4 @@ fluentd를 구성하는 것에 대한 자세한 내용은, 구현할 수 있다. 그러나, 이러한 로깅 메커니즘의 구현은 쿠버네티스의 범위를 벗어난다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/cluster-administration/manage-deployment.md b/content/ko/docs/concepts/cluster-administration/manage-deployment.md index ea5396350f..6bed969e90 100644 --- a/content/ko/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/ko/docs/concepts/cluster-administration/manage-deployment.md @@ -1,17 +1,17 @@ --- title: 리소스 관리 -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + 애플리케이션을 배포하고 서비스를 통해 노출했다. 이제 무엇을 해야 할까? 쿠버네티스는 확장과 업데이트를 포함하여, 애플리케이션 배포를 관리하는 데 도움이 되는 여러 도구를 제공한다. 더 자세히 설명할 기능 중에는 [구성 파일](/ko/docs/concepts/configuration/overview/)과 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)이 있다. -{{% /capture %}} -{{% capture body %}} + + ## 리소스 구성 구성하기 @@ -154,7 +154,7 @@ deployment.apps/my-deployment created persistentvolumeclaim/my-pvc created ``` -`kubectl` 에 대해 더 자세히 알고 싶다면, [kubectl 개요](/docs/reference/kubectl/overview/)를 참조한다. +`kubectl` 에 대해 더 자세히 알고 싶다면, [kubectl 개요](/ko/docs/reference/kubectl/overview/)를 참조한다. ## 효과적인 레이블 사용 @@ -447,11 +447,12 @@ kubectl edit deployment/my-nginx 이것으로 끝이다! 디플로이먼트는 배포된 nginx 애플리케이션을 배후에서 점차적으로 업데이트한다. 업데이트되는 동안 특정 수의 이전 레플리카만 중단될 수 있으며, 원하는 수의 파드 위에 특정 수의 새 레플리카만 생성될 수 있다. 이에 대한 더 자세한 내용을 보려면, [디플로이먼트 페이지](/ko/docs/concepts/workloads/controllers/deployment/)를 방문한다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + - [애플리케이션 검사 및 디버깅에 `kubectl` 을 사용하는 방법](/docs/tasks/debug-application-cluster/debug-application-introspection/)에 대해 알아본다. - [구성 모범 사례 및 팁](/ko/docs/concepts/configuration/overview/)을 참고한다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/cluster-administration/networking.md b/content/ko/docs/concepts/cluster-administration/networking.md index bdc0981f59..28508d58f2 100644 --- a/content/ko/docs/concepts/cluster-administration/networking.md +++ b/content/ko/docs/concepts/cluster-administration/networking.md @@ -1,10 +1,10 @@ --- title: 클러스터 네트워킹 -content_template: templates/concept +content_type: concept weight: 50 --- -{{% capture overview %}} + 네트워킹은 쿠버네티스의 중심적인 부분이지만, 어떻게 작동하는지 정확하게 이해하기가 어려울 수 있다. 쿠버네티스에는 4가지 대응해야 할 네트워킹 문제가 있다. @@ -15,10 +15,10 @@ weight: 50 3. 파드와 서비스 간 통신: 이 문제는 [서비스](/ko/docs/concepts/services-networking/service/)에서 다룬다. 4. 외부와 서비스 간 통신: 이 문제는 [서비스](/ko/docs/concepts/services-networking/service/)에서 다룬다. -{{% /capture %}} -{{% capture body %}} + + 쿠버네티스는 애플리케이션 간에 머신을 공유하는 것이다. 일반적으로, 머신을 공유하려면 두 애플리케이션이 동일한 포트를 사용하지 않도록 @@ -310,12 +310,13 @@ OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크 독립형으로 실행된다. 두 버전에서, 실행하기 위해 구성이나 추가 코드가 필요하지 않으며, 두 경우 모두, 쿠버네티스의 표준과 같이 네트워크에서 파드별로 하나의 IP 주소를 제공한다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + 네트워크 모델의 초기 설계와 그 근거 및 미래의 계획은 [네트워킹 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)에 자세히 설명되어 있다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/cluster-administration/proxies.md b/content/ko/docs/concepts/cluster-administration/proxies.md index 3b8b2d32a1..df43157578 100644 --- a/content/ko/docs/concepts/cluster-administration/proxies.md +++ b/content/ko/docs/concepts/cluster-administration/proxies.md @@ -1,14 +1,14 @@ --- title: 쿠버네티스에서 프락시(Proxy) -content_template: templates/concept +content_type: concept weight: 90 --- -{{% capture overview %}} + 이 페이지는 쿠버네티스에서 함께 사용되는 프락시(Proxy)를 설명한다. -{{% /capture %}} -{{% capture body %}} + + ## 프락시 @@ -62,6 +62,6 @@ weight: 90 프락시는 리다이렉트 기능을 대체했다. 리다이렉트는 더 이상 사용하지 않는다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/configuration/configmap.md b/content/ko/docs/concepts/configuration/configmap.md index 42beb83ed5..8e5eb3bed1 100644 --- a/content/ko/docs/concepts/configuration/configmap.md +++ b/content/ko/docs/concepts/configuration/configmap.md @@ -1,10 +1,10 @@ --- title: 컨피그맵(ConfigMap) -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + {{< glossary_definition term_id="configmap" prepend="컨피그맵은" length="all" >}} @@ -15,9 +15,9 @@ weight: 20 사용하여 데이터를 비공개로 유지하자. {{< /caution >}} -{{% /capture %}} -{{% capture body %}} + + ## 사용 동기 애플리케이션 코드와 별도로 구성 데이터를 설정하려면 컨피그맵을 사용하자. @@ -158,12 +158,13 @@ spec: {{< /note >}} -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [시크릿](/docs/concepts/configuration/secret/)에 대해 읽어본다. * [컨피그맵을 사용하도록 파드 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/)를 읽어본다. * 코드를 구성에서 분리하려는 동기를 이해하려면 [Twelve-Factor 앱](https://12factor.net/ko/)을 읽어본다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/configuration/manage-resources-containers.md b/content/ko/docs/concepts/configuration/manage-resources-containers.md index b54f12a48b..90991bc49e 100644 --- a/content/ko/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ko/docs/concepts/configuration/manage-resources-containers.md @@ -1,6 +1,6 @@ --- title: 컨테이너 리소스 관리 -content_template: templates/concept +content_type: concept weight: 40 feature: title: 자동 빈 패킹(bin packing) @@ -8,7 +8,7 @@ feature: 리소스 요구 사항과 기타 제약 조건에 따라 컨테이너를 자동으로 배치하지만, 가용성은 그대로 유지한다. 활용도를 높이고 더 많은 리소스를 절약하기 위해 중요한(critical) 워크로드와 최선의(best-effort) 워크로드를 혼합한다. --- -{{% capture overview %}} + {{< glossary_tooltip text="파드" term_id="pod" >}}를 지정할 때, {{< glossary_tooltip text="컨테이너" term_id="container" >}}에 필요한 각 리소스의 양을 선택적으로 지정할 수 있다. @@ -21,10 +21,10 @@ feature: 컨테이너가 사용할 수 있도록 해당 시스템 리소스의 최소 _요청_ 량을 예약한다. -{{% /capture %}} -{{% capture body %}} + + ## 요청 및 제한 @@ -740,10 +740,11 @@ LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-0 -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [컨테이너와 파드에 메모리 리소스를 할당](/ko/docs/tasks/configure-pod-container/assign-memory-resource/)하는 핸즈온 경험을 해보자. @@ -758,4 +759,4 @@ LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-0 * XFS의 [프로젝트 쿼터](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html)에 대해 읽어보기 -{{% /capture %}} + diff --git a/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md index d24d749d26..0e50a842bb 100644 --- a/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md +++ b/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md @@ -1,10 +1,10 @@ --- title: kubeconfig 파일을 사용하여 클러스터 접근 구성하기 -content_template: templates/concept +content_type: concept weight: 60 --- -{{% capture overview %}} + kubeconfig 파일들을 사용하여 클러스터, 사용자, 네임스페이스 및 인증 메커니즘에 대한 정보를 관리하자. `kubectl` 커맨드라인 툴은 kubeconfig 파일을 사용하여 @@ -25,10 +25,10 @@ kubeconfig 파일들을 사용하여 클러스터, 사용자, 네임스페이스 kubeconfig 파일을 생성하고 지정하는 단계별 지시사항은 [다중 클러스터로 접근 구성하기](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)를 참조한다. -{{% /capture %}} -{{% capture body %}} + + ## 다중 클러스터, 사용자와 인증 메커니즘 지원 @@ -143,14 +143,15 @@ kubeconfig 파일에서 파일과 경로 참조는 kubeconfig 파일의 위치 `$HOME/.kube/config`에서 상대 경로는 상대적으로, 절대 경로는 절대적으로 저장한다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [다중 클러스터 접근 구성하기](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) * [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config) -{{% /capture %}} + diff --git a/content/ko/docs/concepts/configuration/overview.md b/content/ko/docs/concepts/configuration/overview.md index 7611be8cb6..db45ca2d2c 100644 --- a/content/ko/docs/concepts/configuration/overview.md +++ b/content/ko/docs/concepts/configuration/overview.md @@ -1,16 +1,16 @@ --- title: 구성 모범 사례 -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + 이 문서는 사용자 가이드, 시작하기 문서 및 예제들에 걸쳐 소개된 구성 모범 사례를 강조하고 통합한다. 이 문서는 지속적으로 변경 가능하다. 이 목록에 없지만 다른 사람들에게 유용할 것 같은 무엇인가를 생각하고 있다면, 새로운 이슈를 생성하거나 풀 리퀘스트를 제출하는 것을 망설이지 말기를 바란다. -{{% /capture %}} -{{% capture body %}} + + ## 일반적인 구성 팁 - 구성을 정의할 때, 안정된 최신 API 버전을 명시한다. @@ -57,8 +57,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며 - `hostPort`와 같은 이유로, `hostNetwork`를 사용하는 것을 피한다. -- `kube-proxy` 로드 밸런싱이 필요하지 않을 때, 쉬운 서비스 발견을 위해 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless- -서비스)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다. +- `kube-proxy` 로드 밸런싱이 필요하지 않을 때, 쉬운 서비스 발견을 위해 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다. ## 레이블 사용하기 @@ -76,7 +75,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며 - `imagePullPolicy: IfNotPresent`: 이미지가 로컬에 이미 존재하지 않으면 이미지가 풀(Pull) 된다. -- `imagePullPolicy: Always`: 파드가 시작될 때마다 이미지가 풀(Pull) 된다. +- `imagePullPolicy: Always`: kubelet이 컨테이너를 시작할 때마다, kubelet은 컨테이너 이미지 레지스트리를 쿼리해서 이름을 이미지 다이제스트(digest)로 확인한다. kubelet에 정확한 다이제스트가 저장된 컨테이너 이미지가 로컬로 캐시된 경우, kubelet은 캐시된 이미지를 사용한다. 그렇지 않으면, kubelet은 확인한 다이제스트를 사용해서 이미지를 다운로드(pull)하고, 해당 이미지를 사용해서 컨테이너를 시작한다. - `imagePullPolicy`가 생략되어 있고, 이미지 태그가 `:latest` 이거나 생략되어 있다면 `Always`가 적용된다. @@ -104,4 +103,4 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며 - 단일 컨테이너로 구성된 디플로이먼트와 서비스를 빠르게 생성하기 위해 `kubectl run`와 `kubectl expose`를 사용한다. [클러스터 내부의 애플리케이션에 접근하기 위한 서비스 사용](/docs/tasks/access-application-cluster/service-access-application-cluster/)에서 예시를 확인할 수 있다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/configuration/pod-overhead.md b/content/ko/docs/concepts/configuration/pod-overhead.md index c5efc58c1e..cafd3a921d 100644 --- a/content/ko/docs/concepts/configuration/pod-overhead.md +++ b/content/ko/docs/concepts/configuration/pod-overhead.md @@ -1,10 +1,10 @@ --- title: 파드 오버헤드 -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.18" state="beta" >}} @@ -14,10 +14,10 @@ _파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파 소비되는 리소스를 계산하는 기능이다. -{{% /capture %}} -{{% capture body %}} + + 쿠버네티스에서 파드의 오버헤드는 파드의 [런타임클래스](/ko/docs/concepts/containers/runtime-class/) 와 관련된 오버헤드에 따라 @@ -183,11 +183,12 @@ sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath 이 기능은 kube-state-metrics 의 1.9 릴리스에서는 사용할 수 없지만, 다음 릴리스에서는 가능할 예정이다. 그 전까지는 소스로부터 kube-state-metric 을 빌드해야 한다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [런타임클래스](/ko/docs/concepts/containers/runtime-class/) * [파드오버헤드 디자인](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) -{{% /capture %}} + diff --git a/content/ko/docs/concepts/configuration/pod-priority-preemption.md b/content/ko/docs/concepts/configuration/pod-priority-preemption.md index 3a6b989c8e..ac39ed6c94 100644 --- a/content/ko/docs/concepts/configuration/pod-priority-preemption.md +++ b/content/ko/docs/concepts/configuration/pod-priority-preemption.md @@ -1,10 +1,10 @@ --- title: 파드 우선순위(priority)와 선점(preemption) -content_template: templates/concept +content_type: concept weight: 70 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.14" state="stable" >}} @@ -13,9 +13,9 @@ weight: 70 스케줄러는 우선순위가 낮은 파드를 선점(축출)하여 보류 중인 파드를 스케줄링할 수 있게 한다. -{{% /capture %}} -{{% capture body %}} + + {{< warning >}} @@ -404,7 +404,8 @@ kubelet 리소스 부족 축출은 사용량이 요청을 초과하지 않는 초과하지 않으면, 축출되지 않는다. 요청을 초과하는 우선순위가 더 높은 다른 파드가 축출될 수 있다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * 프라이어리티클래스와 관련하여 리소스쿼터 사용에 대해 [기본적으로 프라이어리티 클래스 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을 읽어보자. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/configuration/resource-bin-packing.md b/content/ko/docs/concepts/configuration/resource-bin-packing.md index 5b6af1c661..4a8a6b7f2f 100644 --- a/content/ko/docs/concepts/configuration/resource-bin-packing.md +++ b/content/ko/docs/concepts/configuration/resource-bin-packing.md @@ -1,18 +1,18 @@ --- title: 확장된 리소스를 위한 리소스 빈 패킹(bin packing) -content_template: templates/concept +content_type: concept weight: 50 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.16" state="alpha" >}} kube-scheduler는 `RequestedToCapacityRatioResourceAllocation` 우선 순위 기능을 사용해서 확장된 리소스와 함께 리소스의 빈 패킹이 가능하도록 구성할 수 있다. 우선 순위 기능을 사용해서 맞춤 요구에 따라 kube-scheduler를 미세 조정할 수 있다. -{{% /capture %}} -{{% capture body %}} + + ## RequestedToCapacityRatioResourceAllocation을 사용해서 빈 패킹 활성화하기 @@ -190,4 +190,4 @@ NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3) ``` -{{% /capture %}} + diff --git a/content/ko/docs/concepts/containers/container-environment.md b/content/ko/docs/concepts/containers/container-environment.md index b5cfaccbfc..95671af60d 100644 --- a/content/ko/docs/concepts/containers/container-environment.md +++ b/content/ko/docs/concepts/containers/container-environment.md @@ -1,17 +1,17 @@ --- title: 컨테이너 환경 변수 -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + 이 페이지는 컨테이너 환경에서 컨테이너에 가용한 리소스에 대해 설명한다. -{{% /capture %}} -{{% capture body %}} + + ## 컨테이너 환경 @@ -50,11 +50,12 @@ FOO_SERVICE_PORT=<서비스가 동작 중인 포트> 서비스에 지정된 IP 주소가 있고 [DNS 애드온](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [컨테이너 라이프사이클 훅(hooks)](/ko/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배워 보기. * [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) 실제 경험 얻기. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/containers/container-lifecycle-hooks.md b/content/ko/docs/concepts/containers/container-lifecycle-hooks.md index 6264621a24..ac29c19c1b 100644 --- a/content/ko/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/ko/docs/concepts/containers/container-lifecycle-hooks.md @@ -1,18 +1,18 @@ --- title: 컨테이너 라이프사이클 훅(Hook) -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + 이 페이지는 kubelet이 관리하는 컨테이너가 관리 라이프사이클 동안의 이벤트에 의해 발동되는 코드를 실행하기 위해서 컨테이너 라이프사이클 훅 프레임워크를 사용하는 방법에 대해서 설명한다. -{{% /capture %}} -{{% capture body %}} + + ## 개요 @@ -109,12 +109,13 @@ Events: 1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [컨테이너 환경](/ko/docs/concepts/containers/container-environment/)에 대해 더 배우기. * [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) 실습 경험하기. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index 4a84219ff6..afc9a3076a 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -1,19 +1,19 @@ --- title: 이미지 -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + 사용자 Docker 이미지를 생성하고 레지스트리에 푸시(push)하여 쿠버네티스 파드에서 참조되기 이전에 대비한다. 컨테이너의 `image` 속성은 `docker` 커맨드에서 지원하는 문법과 같은 문법을 지원한다. 이는 프라이빗 레지스트리와 태그를 포함한다. -{{% /capture %}} -{{% capture body %}} + + ## 이미지 업데이트 @@ -148,7 +148,7 @@ kubelet은 ECR 자격 증명을 가져오고 주기적으로 갱신할 것이다 ### IBM 클라우드 컨테이너 레지스트리 사용 IBM 클라우드 컨테이너 레지스트리는 멀티-테넌트 프라이빗 이미지 레지스트리를 제공하여 사용자가 이미지를 안전하게 저장하고 공유할 수 있도록 한다. 기본적으로, 프라이빗 레지스트리의 이미지는 통합된 취약점 조언기(Vulnerability Advisor)를 통해 조사되어 보안 이슈와 잠재적 취약성을 검출한다. IBM 클라우드 계정의 모든 사용자가 이미지에 접근할 수 있도록 하거나, IAM 역할과 정책으로 IBM 클라우드 컨테이너 레지스트리 네임스페이스의 접근 권한을 부여해서 사용할 수 있다. -IBM 클라우드 컨테이너 레지스트리 CLI 플러그인을 설치하고 사용자 이미지를 위한 네임스페이스를 생성하기 위해서는, [IBM 클라우드 컨테이너 레지스트리 시작하기](https://cloud.ibm.com/docs/Registry?topic=registry-getting-started)를 참고한다. +IBM 클라우드 컨테이너 레지스트리 CLI 플러그인을 설치하고 사용자 이미지를 위한 네임스페이스를 생성하기 위해서는, [IBM 클라우드 컨테이너 레지스트리 시작하기](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-started)를 참고한다. 다른 추가적인 구성이 없는 IBM 클라우드 쿠버네티스 서비스 클러스터의 IBM 클라우드 컨테이너 레지스트리 내 기본 네임스페이스에 저장되어 있는 배포된 이미지를 동일 계정과 동일 지역에서 사용하려면 [이미지로부터 컨테이너 빌드하기](https://cloud.ibm.com/docs/containers?topic=containers-images)를 본다. 다른 구성 옵션에 대한 것은 [레지스트리부터 클러스터에 이미지를 가져오도록 권한을 부여하는 방법 이해하기](https://cloud.ibm.com/docs/containers?topic=containers-registry#cluster_registry_auth)를 본다. @@ -367,4 +367,4 @@ imagePullSecrets을 셋팅하여 자동화할 수 있다. 다중 레지스트리에 접근해야 하는 경우, 각 레지스트리에 대해 하나의 시크릿을 생성할 수 있다. Kubelet은 모든`imagePullSecrets` 파일을 하나의 가상`.docker / config.json` 파일로 병합한다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/containers/overview.md b/content/ko/docs/concepts/containers/overview.md index 11d29a18ce..7ad30f5749 100644 --- a/content/ko/docs/concepts/containers/overview.md +++ b/content/ko/docs/concepts/containers/overview.md @@ -1,10 +1,10 @@ --- title: 컨테이너 개요 -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + 컨테이너는 런타임에 필요한 종속성과 애플리케이션의 컴파일 된 코드를 패키징 하는 기술이다. 실행되는 각각의 @@ -15,10 +15,10 @@ weight: 10 컨테이너는 기본 호스트 인프라 환경에서 애플리케이션의 실행환경을 분리한다. 따라서 다양한 클라우드 환경이나 운영체제에서 쉽게 배포 할 수 있다. -{{% /capture %}} -{{% capture body %}} + + ## 컨테이너 이미지 [컨테이너 이미지](/ko/docs/concepts/containers/images/) 는 즉시 실행할 수 있는 @@ -36,8 +36,9 @@ weight: 10 {{< glossary_definition term_id="container-runtime" length="all" >}} -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [컨테이너 이미지](/ko/docs/concepts/containers/images/)에 대해 읽어보기 * [파드](/ko/docs/concepts/workloads/pods/)에 대해 읽어보기 -{{% /capture %}} + diff --git a/content/ko/docs/concepts/containers/runtime-class.md b/content/ko/docs/concepts/containers/runtime-class.md index f1fd42cad6..8af3bda7a8 100644 --- a/content/ko/docs/concepts/containers/runtime-class.md +++ b/content/ko/docs/concepts/containers/runtime-class.md @@ -1,10 +1,10 @@ --- title: 런타임 클래스 -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.12" state="alpha" >}} @@ -13,10 +13,10 @@ weight: 20 런타임클래스는 컨테이너 런타임을 구성을 선택하는 기능이다. 컨테이너 런타임 구성은 파드의 컨테이너를 실행하는데 사용된다. -{{% /capture %}} -{{% capture body %}} + + ## 동기 @@ -176,12 +176,13 @@ PodOverhead를 사용하려면, PodOverhead [기능 게이트](/docs/reference/c 해당 런타임 클래스를 사용해서 구동 중인 파드의 오버헤드를 특정할 수 있고 이 오버헤드가 쿠버네티스 내에서 처리된다는 것을 보장할 수 있다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + - [런타임 클래스 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) - [런타임 클래스 스케줄링 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md) - [파드 오버헤드](/docs/concepts/configuration/pod-overhead/) 개념에 대해 읽기 - [파드 오버헤드 기능 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) -{{% /capture %}} + diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md index fe8af20904..3b0b42dfcc 100644 --- a/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md +++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -1,19 +1,19 @@ --- title: 애그리게이션 레이어(aggregation layer)로 쿠버네티스 API 확장하기 -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + 애그리게이션 레이어는 코어 쿠버네티스 API가 제공하는 기능 이외에 더 많은 기능을 제공할 수 있도록 추가 API를 더해 쿠버네티스를 확장할 수 있게 해준다. 추가 API는 [서비스-카탈로그](/docs/concepts/extend-kubernetes/service-catalog/)와 같이 미리 만들어진 솔루션이거나 사용자가 직접 개발한 API일 수 있다. 애그리게이션 레이어는 [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)와는 다르며, 애그리게이션 레이어는 {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} 가 새로운 종류의 오브젝트를 인식하도록 하는 방법이다. -{{% /capture %}} -{{% capture body %}} + + ## 애그리게이션 레이어 @@ -30,13 +30,14 @@ extention API server가 레이턴시 요구 사항을 달성할 수 없는 경 `EnableAggregatedDiscoveryTimeout=false` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 설정해서 타임아웃 제한을 비활성화 할 수 있다. 이 사용 중단(deprecated)된 기능 게이트는 향후 릴리스에서 제거될 예정이다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * 사용자의 환경에서 Aggregator를 동작시키려면, [애그리게이션 레이어를 설정한다](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/). * 다음에, [extension api-server를 구성해서](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) 애그리게이션 레이어와 연계한다. * 또한, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)를 배워본다. * [API 서비스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)의 사양을 읽어본다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index 84481bdec7..9e9f3e9e29 100644 --- a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -1,18 +1,18 @@ --- title: 커스텀 리소스 -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + *커스텀 리소스* 는 쿠버네티스 API의 익스텐션이다. 이 페이지에서는 쿠버네티스 클러스터에 커스텀 리소스를 추가할 시기와 독립형 서비스를 사용하는 시기에 대해 설명한다. 커스텀 리소스를 추가하는 두 가지 방법과 이들 중에서 선택하는 방법에 대해 설명한다. -{{% /capture %}} -{{% capture body %}} + + ## 커스텀 리소스 *리소스* 는 [쿠버네티스 API](/ko/docs/reference/using-api/api-overview/)에서 특정 종류의 @@ -243,12 +243,13 @@ CRD는 항상 API 서버의 빌트인 리소스와 동일한 인증, 권한 부 - 작성한 REST 클라이언트 - [쿠버네티스 클라이언트 생성 도구](https://github.com/kubernetes/code-generator)를 사용하여 생성된 클라이언트(하나를 생성하는 것은 고급 기능이지만, 일부 프로젝트는 CRD 또는 AA와 함께 클라이언트를 제공할 수 있다). -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [애그리게이션 레이어(aggregation layer)로 쿠버네티스 API 확장](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)하는 방법에 대해 배우기. * [커스텀리소스데피니션으로 쿠버네티스 API 확장](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)하는 방법에 대해 배우기. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index 0912bcdcde..d75601de9f 100644 --- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -1,11 +1,11 @@ --- title: 장치 플러그인 description: GPU, NIC, FPGA, InfiniBand 및 공급 업체별 설정이 필요한 유사한 리소스를 위한 플러그인을 구현하는데 쿠버네티스 장치 플러그인 프레임워크를 사용한다. -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.10" state="beta" >}} 쿠버네티스는 시스템 하드웨어 리소스를 {{< glossary_tooltip term_id="kubelet" >}}에 알리는 데 사용할 수 있는 @@ -18,9 +18,9 @@ weight: 20 및 공급 업체별 초기화 및 설정이 필요할 수 있는 기타 유사한 컴퓨팅 리소스가 포함된다. -{{% /capture %}} -{{% capture body %}} + + ## 장치 플러그인 등록 @@ -224,12 +224,13 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi. * [SR-IOV 네트워크 장치 플러그인](https://github.com/intel/sriov-network-device-plugin) * Xilinx FPGA 장치용 [Xilinx FPGA 장치 플러그인](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * 장치 플러그인을 사용한 [GPU 리소스 스케줄링](/docs/tasks/manage-gpus/scheduling-gpus/)에 대해 알아보기 * 노드에서의 [확장 리소스 알리기](/docs/tasks/administer-cluster/extended-resource-node/)에 대해 배우기 * 쿠버네티스에서 [TLS 수신에 하드웨어 가속](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) 사용에 대해 읽기 * [토폴로지 관리자](/docs/tasks/adminster-cluster/topology-manager/)에 대해 알아보기 -{{% /capture %}} + diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md index 137195e7e7..df26abccc5 100644 --- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md +++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md @@ -1,11 +1,11 @@ --- title: 네트워크 플러그인 -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + {{< feature-state state="alpha" >}} {{< caution >}}알파 기능은 빨리 변경될 수 있다. {{< /caution >}} @@ -15,9 +15,9 @@ weight: 10 * CNI 플러그인: 상호 운용성을 위해 설계된 appc/CNI 명세를 준수한다. * Kubenet 플러그인: `bridge` 와 `host-local` CNI 플러그인을 사용하여 기본 `cbr0` 구현한다. -{{% /capture %}} -{{% capture body %}} + + ## 설치 @@ -79,11 +79,13 @@ CNI 네트워킹 플러그인은 `hostPort` 를 지원한다. CNI 플러그인 #### 트래픽 셰이핑 지원 +**실험적인 기능입니다** + CNI 네트워킹 플러그인은 파드 수신 및 송신 트래픽 셰이핑도 지원한다. CNI 플러그인 팀에서 제공하는 공식 [대역폭(bandwidth)](https://github.com/containernetworking/plugins/tree/master/plugins/meta/bandwidth) 플러그인을 사용하거나 대역폭 제어 기능이 있는 자체 플러그인을 사용할 수 있다. 트래픽 셰이핑 지원을 활성화하려면, CNI 구성 파일 (기본값 `/etc/cni/net.d`)에 `bandwidth` 플러그인을 -추가해야 한다. +추가하고, 바이너리가 CNI 실행 파일 디렉터리(기본값: `/opt/cni/bin`)에 포함되어있는지 확인한다. ```json { @@ -160,8 +162,9 @@ AWS에서 `eth0` MTU는 일반적으로 9001이므로, `--network-plugin-mtu=900 * `--network-plugin=kubenet` 은 `/opt/cni/bin` 또는 `cni-bin-dir` 에 있는 CNI `bridge` 및 `host-local` 플러그인과 함께 kubenet 네트워크 플러그인을 사용하도록 지정한다. * 현재 kubenet 네트워크 플러그인에서만 사용하는 `--network-plugin-mtu=9001` 은 사용할 MTU를 지정한다. -{{% /capture %}} -{{% capture whatsnext %}} -{{% /capture %}} +## {{% heading "whatsnext" %}} + + + diff --git a/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md b/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md index 408ff70c22..ecf57f49fc 100644 --- a/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md @@ -1,10 +1,10 @@ --- title: 쿠버네티스 클러스터 확장 -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + 쿠버네티스는 매우 유연하게 구성할 수 있고 확장 가능하다. 결과적으로 쿠버네티스 프로젝트를 포크하거나 코드에 패치를 제출할 필요가 @@ -17,10 +17,10 @@ weight: 10 어떤 익스텐션 포인트와 패턴이 있는지, 그리고 그것들의 트레이드오프와 제약에 대한 소개 자료로 유용할 것이다. -{{% /capture %}} -{{% capture body %}} + + ## 개요 @@ -189,10 +189,11 @@ Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도 [웹훅](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)을 지원한다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에 대해 더 알아보기 * [동적 어드미션 컨트롤](/docs/reference/access-authn-authz/extensible-admission-controllers/)에 대해 알아보기 @@ -202,4 +203,4 @@ Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도 * [kubectl 플러그인](/docs/tasks/extend-kubectl/kubectl-plugins/)에 대해 알아보기 * [오퍼레이터 패턴](/docs/concepts/extend-kubernetes/operator/)에 대해 알아보기 -{{% /capture %}} + diff --git a/content/ko/docs/concepts/extend-kubernetes/operator.md b/content/ko/docs/concepts/extend-kubernetes/operator.md index 7d7854e05c..c663964e21 100644 --- a/content/ko/docs/concepts/extend-kubernetes/operator.md +++ b/content/ko/docs/concepts/extend-kubernetes/operator.md @@ -1,20 +1,20 @@ --- title: 오퍼레이터(operator) 패턴 -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + 오퍼레이터(Operator)는 [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)를 사용하여 애플리케이션 및 해당 컴포넌트를 관리하는 쿠버네티스의 소프트웨어 익스텐션이다. 오퍼레이터는 쿠버네티스 원칙, 특히 [컨트롤 루프](/ko/docs/concepts/#쿠버네티스-컨트롤-플레인)를 따른다. -{{% /capture %}} -{{% capture body %}} + + ## 동기 부여 @@ -113,9 +113,10 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하 또한 [쿠버네티스 API의 클라이언트](/ko/docs/reference/using-api/client-libraries/) 역할을 할 수 있는 모든 언어 / 런타임을 사용하여 오퍼레이터(즉, 컨트롤러)를 구현한다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에 대해 더 알아보기 * [OperatorHub.io](https://operatorhub.io/)에서 유스케이스에 맞는 이미 만들어진 오퍼레이터 찾기 @@ -129,5 +130,5 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하 * 오퍼레이터 패턴을 소개한 [CoreOS 원본 기사](https://coreos.com/blog/introducing-operators.html) 읽기 * 오퍼레이터 구축을 위한 모범 사례에 대한 구글 클라우드(Google Cloud)의 [기사](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) 읽기 -{{% /capture %}} + diff --git a/content/ko/docs/concepts/overview/components.md b/content/ko/docs/concepts/overview/components.md index 9db222e271..3d4a8b8370 100644 --- a/content/ko/docs/concepts/overview/components.md +++ b/content/ko/docs/concepts/overview/components.md @@ -1,13 +1,13 @@ --- title: 쿠버네티스 컴포넌트 -content_template: templates/concept +content_type: concept weight: 20 card: name: concepts weight: 20 --- -{{% capture overview %}} + 쿠버네티스를 배포하면 클러스터를 얻는다. {{< glossary_definition term_id="cluster" length="all" prepend="쿠버네티스 클러스터는">}} @@ -18,9 +18,9 @@ card: ![쿠버네티스의 컴포넌트](/images/docs/components-of-kubernetes.png) -{{% /capture %}} -{{% capture body %}} + + ## 컨트롤 플레인 컴포넌트 컨트롤 플레인 컴포넌트는 클러스터에 관한 전반적인 결정(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, 디플로이먼트의 `replicas` 필드에 대한 요구 조건이 충족되지 않을 경우 새로운 {{< glossary_tooltip text="파드" term_id="pod">}}를 구동시키는 것)를 감지하고 반응한다. @@ -118,10 +118,11 @@ kube-controller-manager와 마찬가지로 cloud-controller-manager는 논리적 [클러스터-레벨 로깅](/docs/concepts/cluster-administration/logging/) 메커니즘은 검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 진다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [노드](/ko/docs/concepts/architecture/nodes/)에 대해 더 배우기 * [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 더 배우기 * [kube-scheduler](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 더 배우기 * etcd의 공식 [문서](https://etcd.io/docs/) 읽기 -{{% /capture %}} + diff --git a/content/ko/docs/concepts/overview/kubernetes-api.md b/content/ko/docs/concepts/overview/kubernetes-api.md index ce0b55e113..aa5d4a043d 100644 --- a/content/ko/docs/concepts/overview/kubernetes-api.md +++ b/content/ko/docs/concepts/overview/kubernetes-api.md @@ -1,13 +1,13 @@ --- title: 쿠버네티스 API -content_template: templates/concept +content_type: concept weight: 30 card: name: concepts weight: 30 --- -{{% capture overview %}} + 전체 API 관례는 [API conventions doc](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)에 기술되어 있다. @@ -15,16 +15,16 @@ API 엔드포인트, 리소스 타입과 샘플은 [API Reference](/docs/referen API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/reference/access-authn-authz/controlling-access/)에서 논의되었다. -쿠버네티스 API는 시스템을 위한 선언적 설정 스키마를 위한 기초가 되기도 한다. [kubectl](/docs/reference/kubectl/overview/) 커맨드라인 툴을 사용해서 API 오브젝트를 생성, 업데이트, 삭제 및 조회할 수 있다. +쿠버네티스 API는 시스템을 위한 선언적 설정 스키마를 위한 기초가 되기도 한다. [kubectl](/ko/docs/reference/kubectl/overview/) 커맨드라인 툴을 사용해서 API 오브젝트를 생성, 업데이트, 삭제 및 조회할 수 있다. 쿠버네티스는 또한 API 리소스에 대해 직렬화된 상태를 (현재는 [etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)에) 저장한다. 쿠버네티스 자체는 여러 컴포넌트로 나뉘어져서 각각의 API를 통해 상호작용한다. -{{% /capture %}} -{{% capture body %}} + + ## API 변경 @@ -137,4 +137,4 @@ API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명 {{< note >}}개별 리소스의 활성화/비활성화는 레거시 문제로 `extensions/v1beta1` API 그룹에서만 지원된다. {{< /note >}} -{{% /capture %}} + diff --git a/content/ko/docs/concepts/overview/what-is-kubernetes.md b/content/ko/docs/concepts/overview/what-is-kubernetes.md index 1bbffa96cc..f94ab988a3 100644 --- a/content/ko/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ko/docs/concepts/overview/what-is-kubernetes.md @@ -2,18 +2,18 @@ title: 쿠버네티스란 무엇인가? description: > 쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식할 수 있고, 확장 가능한 오픈소스 플랫폼으로, 선언적 구성과 자동화를 모두 지원한다. 쿠버네티스는 크고 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 지원 그리고 도구들은 광범위하게 제공된다. -content_template: templates/concept +content_type: concept weight: 10 card: name: concepts weight: 10 --- -{{% capture overview %}} + 이 페이지에서는 쿠버네티스 개요를 설명한다. -{{% /capture %}} -{{% capture body %}} + + 쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다. 쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 프로덕션 워크로드를 대규모로 운영하는 [15년 이상의 구글 경험](/blog/2015/04/borg-predecessor-to-kubernetes/)과 커뮤니티의 최고의 아이디어와 적용 사례가 결합되어 있다. @@ -83,9 +83,10 @@ card: * 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다. * 추가로, 쿠버네티스는 단순한 오케스트레이션 시스템이 아니다. 사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도한 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [쿠버네티스 구성요소](/ko/docs/concepts/overview/components/) 살펴보기 * [시작하기](/ko/docs/setup/) 준비가 되었는가? -{{% /capture %}} + diff --git a/content/ko/docs/concepts/overview/working-with-objects/annotations.md b/content/ko/docs/concepts/overview/working-with-objects/annotations.md index 4b238bf313..aa9c29cb64 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/annotations.md +++ b/content/ko/docs/concepts/overview/working-with-objects/annotations.md @@ -1,15 +1,15 @@ --- title: 어노테이션 -content_template: templates/concept +content_type: concept weight: 50 --- -{{% capture overview %}} + 쿠버네티스 어노테이션을 사용하여 임의의 비-식별 메타데이터를 오브젝트에 첨부할 수 있다. 도구 및 라이브러리와 같은 클라이언트는 이 메타데이터를 검색할 수 있다. -{{% /capture %}} -{{% capture body %}} + + ## 오브젝트에 메타데이터 첨부 레이블이나 어노테이션을 사용하여 쿠버네티스 @@ -88,10 +88,11 @@ spec: ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + [레이블과 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)에 대해 알아본다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md index 450255c37c..be7db19bb5 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md @@ -1,17 +1,17 @@ --- title: 권장 레이블 -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + kubectl과 대시보드와 같은 많은 도구들로 쿠버네티스 오브젝트를 시각화 하고 관리할 수 있다. 공통 레이블 셋은 모든 도구들이 이해할 수 있는 공통의 방식으로 오브젝트를 식별하고 도구들이 상호 운용적으로 작동할 수 있도록 한다. 권장 레이블은 지원 도구 외에도 쿼리하는 방식으로 애플리케이션을 식별하게 한다. -{{% /capture %}} -{{% capture body %}} + + 메타데이터는 _애플리케이션_ 의 개념을 중심으로 정리된다. 쿠버네티스는 플랫폼 서비스(PaaS)가 아니며 애플리케이션에 대해 공식적인 개념이 없거나 강요하지 않는다. 대신 애플리케이션은 비공식적이며 메타데이터로 설명된다. @@ -166,4 +166,4 @@ metadata: MySQL `StatefulSet` 과 `Service` 로 MySQL과 WordPress가 더 큰 범위의 애플리케이션에 포함되어 있는 것을 알게 된다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 3028155e22..1fe7183c29 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -1,17 +1,17 @@ --- title: 쿠버네티스 오브젝트 이해하기 -content_template: templates/concept +content_type: concept weight: 10 card: name: concepts weight: 40 --- -{{% capture overview %}} + 이 페이지에서는 쿠버네티스 오브젝트가 쿠버네티스 API에서 어떻게 표현되고, 그 오브젝트를 어떻게 `.yaml` 형식으로 표현할 수 있는지에 대해 설명한다. -{{% /capture %}} -{{% capture body %}} + + ## 쿠버네티스 오브젝트 이해하기 {#kubernetes-objects} *쿠버네티스 오브젝트* 는 쿠버네티스 시스템에서 영속성을 가지는 개체이다. 쿠버네티스는 클러스터의 상태를 나타내기 위해 이 개체를 이용한다. 구체적으로 말하자면, 다음을 기술할 수 있다. @@ -86,10 +86,11 @@ deployment.apps/nginx-deployment created 에서 확인할 수 있고, 디플로이먼트에 대한 `spec` 포맷은 [DeploymentSpec v1 apps](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)에서 확인할 수 있다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * API 개념의 더 많은 설명은 [Kubernetes API 개요](/ko/docs/reference/using-api/api-overview/)를 본다. * [파드(Pod)](/ko/docs/concepts/workloads/pods/pod-overview/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다. * 쿠버네티스의 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 배운다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/overview/working-with-objects/labels.md b/content/ko/docs/concepts/overview/working-with-objects/labels.md index 6fa5790a83..fe8b0ce8fb 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md @@ -1,10 +1,10 @@ --- title: 레이블과 셀렉터 -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + _레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이다. 레이블은 오브젝트의 특성을 식별하는 데 사용되어 사용자에게 중요하지만, 코어 시스템에 직접적인 의미는 없다. @@ -22,10 +22,10 @@ _레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이 레이블은 UI와 CLI에서 효율적인 쿼리를 사용하고 검색에 사용하기에 적합하다. 식별되지 않는 정보는 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)으로 기록해야 한다. -{{% /capture %}} -{{% capture body %}} + + ## 사용 동기 @@ -225,4 +225,4 @@ selector: 레이블을 통해 선택하는 사용 사례 중 하나는 파드를 스케줄 할 수 있는 노드 셋을 제한하는 것이다. 자세한 내용은 [노드 선택](/ko/docs/concepts/scheduling-eviction/assign-pod-node/) 문서를 참조한다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/overview/working-with-objects/names.md b/content/ko/docs/concepts/overview/working-with-objects/names.md index 3841e76c1e..0cb3e7656a 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/names.md +++ b/content/ko/docs/concepts/overview/working-with-objects/names.md @@ -1,10 +1,10 @@ --- title: 오브젝트 이름과 ID -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + 클러스터의 각 오브젝트는 해당 유형의 리소스에 대하여 고유한 [_이름_](#names) 을 가지고 있다. 또한, 모든 쿠버네티스 오브젝트는 전체 클러스터에 걸쳐 고유한 [_UID_](#uids) 를 가지고 있다. @@ -13,10 +13,10 @@ weight: 20 유일하지 않은 사용자 제공 속성의 경우 쿠버네티스는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)과 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)을 제공한다. -{{% /capture %}} -{{% capture body %}} + + ## 이름 {#names} @@ -79,8 +79,9 @@ spec: 쿠버네티스 UID는 보편적으로 고유한 식별자이다(또는 UUID라고 한다). UUID는 ISO/IEC 9834-8 과 ITU-T X.667 로 표준화 되어 있다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * 쿠버네티스의 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)에 대해 읽기. * [쿠버네티스의 식별자와 이름](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) 디자인 문서 읽기. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md index 4707233f26..d5eb45f21c 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md @@ -1,18 +1,18 @@ --- title: 네임스페이스 -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + 쿠버네티스는 동일한 물리 클러스터를 기반으로 하는 여러 가상 클러스터를 지원한다. 이런 가상 클러스터를 네임스페이스라고 한다. -{{% /capture %}} -{{% capture body %}} + + ## 여러 개의 네임스페이스를 사용하는 경우 @@ -47,11 +47,11 @@ weight: 30 kubectl get namespace ``` ``` -NAME STATUS AGE -default Active 1d -kube-system Active 1d -kube-public Active 1d -kube-node-lease Active 1d +NAME STATUS AGE +default Active 1d +kube-node-lease Active 1d +kube-public Active 1d +kube-system Active 1d ``` 쿠버네티스는 처음에 세 개의 초기 네임스페이스를 갖는다. @@ -108,11 +108,12 @@ kubectl api-resources --namespaced=true kubectl api-resources --namespaced=false ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [신규 네임스페이스 생성](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)에 대해 더 배우기. * [네임스페이스 삭제](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)에 대해 더 배우기. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/overview/working-with-objects/object-management.md b/content/ko/docs/concepts/overview/working-with-objects/object-management.md index bdb5ac476d..550cbe951c 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/object-management.md +++ b/content/ko/docs/concepts/overview/working-with-objects/object-management.md @@ -1,17 +1,17 @@ --- title: 쿠버네티스 오브젝트 관리 -content_template: templates/concept +content_type: concept weight: 15 --- -{{% capture overview %}} + `kubectl` 커맨드라인 툴은 쿠버네티스 오브젝트를 생성하고 관리하기 위한 몇 가지 상이한 방법을 지원한다. 이 문서는 여러가지 접근법에 대한 개요을 제공한다. Kubectl로 오브젝트 관리하기에 대한 자세한 설명은 [Kubectl 서적](https://kubectl.docs.kubernetes.io)에서 확인한다. -{{% /capture %}} -{{% capture body %}} + + ## 관리 기법 @@ -174,9 +174,10 @@ kubectl apply -R -f configs/ - 선언형 오브젝트 구성은 예상치 못한 결과를 디버깅하고 이해하기가 더 어렵다. - diff를 사용한 부분 업데이트는 복잡한 병합 및 패치 작업을 일으킨다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + - [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/) - [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기(명령형)](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/) - [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/) @@ -187,4 +188,4 @@ kubectl apply -R -f configs/ {{< comment >}} {{< /comment >}} -{{% /capture %}} + diff --git a/content/ko/docs/concepts/policy/limit-range.md b/content/ko/docs/concepts/policy/limit-range.md index 11356ed3ee..e2bd0a10d3 100644 --- a/content/ko/docs/concepts/policy/limit-range.md +++ b/content/ko/docs/concepts/policy/limit-range.md @@ -1,19 +1,19 @@ --- title: 리밋 레인지(Limit Range) -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + 기본적으로 컨테이너는 쿠버네티스 클러스터에서 무제한 [컴퓨팅 리소스](/docs/user-guide/compute-resources)로 실행된다. 리소스 쿼터을 사용하면 클러스터 관리자는 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}별로 리소스 사용과 생성을 제한할 수 있다. 네임스페이스 내에서 파드나 컨테이너는 네임스페이스의 리소스 쿼터에 정의된 만큼의 CPU와 메모리를 사용할 수 있다. 하나의 파드 또는 컨테이너가 사용 가능한 모든 리소스를 독점할 수 있다는 우려가 있다. 리밋레인지는 네임스페이스에서 리소스 할당(파드 또는 컨테이너)을 제한하는 정책이다. -{{% /capture %}} -{{% capture body %}} + + _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다. @@ -49,9 +49,10 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다. 경합이나 리밋레인지 변경은 이미 생성된 리소스에 영향을 미치지 않는다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + 자세한 내용은 [LimitRanger 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)를 참조한다. @@ -65,4 +66,4 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다. - [네임스페이스당 할당량을 설정하는 자세한 예시](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/). -{{% /capture %}} + diff --git a/content/ko/docs/concepts/policy/pod-security-policy.md b/content/ko/docs/concepts/policy/pod-security-policy.md index 4e264da6f1..57a115fc69 100644 --- a/content/ko/docs/concepts/policy/pod-security-policy.md +++ b/content/ko/docs/concepts/policy/pod-security-policy.md @@ -1,20 +1,20 @@ --- title: 파드 시큐리티 폴리시 -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + {{< feature-state state="beta" >}} 파드 시큐리티 폴리시를 사용하면 파드 생성 및 업데이트에 대한 세분화된 권한을 부여할 수 있다. -{{% /capture %}} -{{% capture body %}} + + ## 파드 시큐리티 폴리시란? @@ -371,6 +371,8 @@ podsecuritypolicy "example" deleted {{< codenew file="policy/restricted-psp.yaml" >}} +더 많은 예제는 [파드 보안 표준](/docs/concepts/security/pod-security-standards/#policy-instantiation)을 본다. + ## 정책 레퍼런스 ### 특권을 가진 @@ -626,10 +628,13 @@ spec: [Sysctl 문서]( /docs/concepts/cluster-administration/sysctl-cluster/#podsecuritypolicy)를 참고하길 바란다. -{{% /capture %}} -{{% capture whatsnext %}} -API 세부 정보는 [파드 시큐리티 폴리시 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 참조 +## {{% heading "whatsnext" %}} + + +폴리시 권장 사항에 대해서는 [파드 보안 표준](/docs/concepts/security/pod-security-standards/)을 참조한다. + +API 세부 정보는 [파드 시큐리티 폴리시 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 참조한다. + -{{% /capture %}} diff --git a/content/ko/docs/concepts/policy/resource-quotas.md b/content/ko/docs/concepts/policy/resource-quotas.md index d13c6abbc2..4aec897572 100644 --- a/content/ko/docs/concepts/policy/resource-quotas.md +++ b/content/ko/docs/concepts/policy/resource-quotas.md @@ -1,20 +1,20 @@ --- title: 리소스 쿼터 -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + 여러 사용자나 팀이 정해진 수의 노드로 클러스터를 공유할 때 한 팀이 공정하게 분배된 리소스보다 많은 리소스를 사용할 수 있다는 우려가 있다. 리소스 쿼터는 관리자가 이 문제를 해결하기 위한 도구이다. -{{% /capture %}} -{{% capture body %}} + + `ResourceQuota` 오브젝트로 정의된 리소스 쿼터는 네임스페이스별 총 리소스 사용을 제한하는 제약 조건을 제공한다. 유형별로 네임스페이스에서 만들 수 있는 오브젝트 수와 @@ -592,10 +592,11 @@ plugins: [리소스 쿼터를 사용하는 방법에 대한 자세한 예](/docs/tasks/administer-cluster/quota-api-object/)를 참고하길 바란다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + 자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)를 참고하길 바란다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md index 6a5eaf68ec..a56dece692 100644 --- a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -1,11 +1,11 @@ --- title: 노드에 파드 할당하기 -content_template: templates/concept +content_type: concept weight: 50 --- -{{% capture overview %}} + {{< glossary_tooltip text="파드" term_id="pod" >}}를 특정한 {{< glossary_tooltip text="노드(들)" term_id="node" >}}에서만 동작하도록 하거나, 특정 노드들을 선호하도록 제한할 수 있다. @@ -17,9 +17,9 @@ weight: 50 예를 들어 SSD가 장착된 머신에 파드가 연결되도록 하거나 또는 동일한 가용성 영역(availability zone)에서 많은 것을 통신하는 두 개의 서로 다른 서비스의 파드를 같이 배치할 수 있다. -{{% /capture %}} -{{% capture body %}} + + ## 노드 셀렉터(nodeSelector) @@ -383,9 +383,10 @@ spec: 위 파드는 kube-01 노드에서 실행될 것이다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + [테인트](/docs/concepts/configuration/taint-and-toleration/)는 노드가 특정 파드들을 *쫓아내게* 할 수 있다. @@ -397,4 +398,4 @@ spec: [토폴로지 매니저](/docs/tasks/administer-cluster/topology-manager/)는 노드 수준의 리소스 할당 결정에 참여할 수 있다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md index 24754a5c88..54373e2e2c 100644 --- a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -1,18 +1,18 @@ --- title: 쿠버네티스 스케줄러 -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + 쿠버네티스에서 _스케줄링_ 은 {{< glossary_tooltip term_id="kubelet" >}}이 파드를 실행할 수 있도록 {{< glossary_tooltip text="파드" term_id="pod" >}}가 {{< glossary_tooltip text="노드" term_id="node" >}}에 적합한지 확인하는 것을 말한다. -{{% /capture %}} -{{% capture body %}} + + ## 스케줄링 개요 {#scheduling} @@ -86,12 +86,13 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순 다른 스케줄링 단계를 구현하는 플러그인을 구성할 수 있다. 다른 프로파일을 실행하도록 kube-scheduler를 구성할 수도 있다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling/scheduler-perf-tuning/)에 대해 읽기 * [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽기 * kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기 * [멀티 스케줄러 구성하기](/docs/tasks/administer-cluster/configure-multiple-schedulers/)에 대해 배우기 * [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기 * [파드 오버헤드](/docs/concepts/configuration/pod-overhead/)에 대해 배우기 -{{% /capture %}} + diff --git a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index 3387bdce43..52db313635 100644 --- a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md +++ b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -1,10 +1,10 @@ --- title: 스케줄러 성능 튜닝 -content_template: templates/concept +content_type: concept weight: 70 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="1.14" state="beta" >}} @@ -22,9 +22,9 @@ API 서버에 해당 결정을 통지한다. 본 페이지에서는 상대적으로 큰 규모의 쿠버네티스 클러스터에 대한 성능 튜닝 최적화에 대해 설명한다. -{{% /capture %}} -{{% capture body %}} + + 큰 규모의 클러스터에서는 스케줄러의 동작을 튜닝하여 응답 시간 (새 파드가 빠르게 배치됨)과 정확도(스케줄러가 배치 결정을 잘 못하는 경우가 드물게 됨) @@ -161,4 +161,4 @@ percentageOfNodesToScore: 50 모든 노드를 검토한 후, 노드 1로 돌아간다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md index ed59926d17..0d0a192ddd 100644 --- a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -1,11 +1,11 @@ --- title: 테인트(Taints)와 톨러레이션(Tolerations) -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + [여기](/ko/docs/concepts/configuration/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)에 설명된 노드 어피니티는 노드 셋을 *끌어들이는* (기본 설정 또는 어려운 요구 사항) *파드* 속성이다. 테인트는 그 반대로, *노드* 가 파드 셋을 @@ -17,9 +17,9 @@ weight: 40 톨러레이션은 파드에 적용되며, 파드를 일치하는 테인트가 있는 노드에 스케줄되게 하지만 필수는 아니다. -{{% /capture %}} -{{% capture body %}} + + ## 개요 @@ -72,21 +72,10 @@ tolerations: 두 가지 특별한 경우가 있다. -* operator `Exists` 가 있는 비어있는 `key` 는 모든 키, 값 및 이펙트와 일치하므로 +operator `Exists` 가 있는 비어있는 `key` 는 모든 키, 값 및 이펙트와 일치하므로 모든 것이 톨러레이션 된다. -```yaml -tolerations: -- operator: "Exists" -``` - -* 비어있는 `effect` 는 모든 이펙트를 키 `key` 와 일치시킨다. - -```yaml -tolerations: -- key: "key" - operator: "Exists" -``` +비어있는 `effect` 는 모든 이펙트를 키 `key` 와 일치시킨다. {{< /note >}} diff --git a/content/ko/docs/concepts/security/overview.md b/content/ko/docs/concepts/security/overview.md index 6dcbe57d58..f988d1d5d9 100644 --- a/content/ko/docs/concepts/security/overview.md +++ b/content/ko/docs/concepts/security/overview.md @@ -1,12 +1,12 @@ --- title: 클라우드 네이티브 보안 개요 -content_template: templates/concept +content_type: concept weight: 1 --- {{< toc >}} -{{% capture overview %}} + 쿠버네티스 보안(일반적인 보안)은 관련된 많은 부분이 상호작용하는 방대한 주제다. 오늘날에는 웹 애플리케이션의 실행을 돕는 수많은 시스템에 오픈소스 소프트웨어가 통합되어 있으며, @@ -15,9 +15,9 @@ weight: 1 몇 가지 일반적인 개념에 대한 멘탈 모델(mental model)을 정의한다. 멘탈 모델은 완전히 임의적이며 소프트웨어 스택을 보호할 위치를 생각하는데 도움이되는 경우에만 사용해야 한다. -{{% /capture %}} -{{% capture body %}} + + ## 클라우드 네이티브 보안의 4C 계층적인 보안에 대해서 어떻게 생각할 수 있는지 이해하는 데 도움이 될 수 있는 다이어그램부터 살펴보자. @@ -150,12 +150,13 @@ TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 클라이 전달하는 파이프라인에 의해 자동화 될 수 있다. 소프트웨어 전달을 위한 "지속적인 해킹(Continuous Hacking)"에 대한 접근 방식에 대해 알아 보려면, 자세한 설명을 제공하는 [이 기사](https://thenewstack.io/beyond-ci-cd-how-continuous-hacking-of-docker-containers-and-pipeline-driven-security-keeps-ygrene-secure/)를 참고한다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [파드에 대한 네트워크 정책](/ko/docs/concepts/services-networking/network-policies/) 알아보기 * [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/)에 대해 알아보기 * [API 접근 통제](/docs/reference/access-authn-authz/controlling-access/)에 대해 알아보기 * 컨트롤 플레인에 대한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/) 알아보기 * [Rest에서 데이터 암호화](/docs/tasks/administer-cluster/encrypt-data/) 알아보기 * [쿠버네티스 시크릿](/docs/concepts/configuration/secret/)에 대해 알아보기 -{{% /capture %}} + diff --git a/content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md b/content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md index b0cc6b1a93..bc5560b5ba 100644 --- a/content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md +++ b/content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md @@ -1,18 +1,18 @@ --- title: HostAliases로 파드의 /etc/hosts 항목 추가하기 -content_template: templates/concept +content_type: concept weight: 60 --- {{< toc >}} -{{% capture overview %}} + 파드의 /etc/hosts 파일에 항목을 추가하는 것은 DNS나 다른 방법들이 적용되지 않을 때 파드 수준의 호스트네임 해석을 제공한다. 1.7 버전에서는, 사용자들이 PodSpec의 HostAliases 항목을 사용하여 이러한 사용자 정의 항목들을 추가할 수 있다. HostAliases를 사용하지 않은 수정은 권장하지 않는데, 이는 호스트 파일이 Kubelet에 의해 관리되고, 파드 생성/재시작 중에 덮어쓰여질 수 있기 때문이다. -{{% /capture %}} -{{% capture body %}} + + ## 기본 호스트 파일 내용 @@ -123,4 +123,4 @@ fe00::2 ip6-allrouters 덮어쓰여진다. 따라서, 호스트 파일의 내용을 직접 바꾸는 것은 권장하지 않는다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/services-networking/connect-applications-service.md b/content/ko/docs/concepts/services-networking/connect-applications-service.md index ca2440a048..4649577399 100644 --- a/content/ko/docs/concepts/services-networking/connect-applications-service.md +++ b/content/ko/docs/concepts/services-networking/connect-applications-service.md @@ -1,11 +1,11 @@ --- title: 서비스와 애플리케이션 연결하기 -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + ## 컨테이너 연결을 위한 쿠버네티스 모델 @@ -15,11 +15,11 @@ weight: 30 컨테이너를 제공하는 여러 개발자 또는 팀에서 포트를 조정하는 것은 규모면에서 매우 어려우며, 사용자가 제어할 수 없는 클러스터 수준의 문제에 노출된다. 쿠버네티스는 파드가 배치된 호스트와는 무관하게 다른 파드와 통신할 수 있다고 가정한다. 쿠버네티스는 모든 파드에게 자체 클러스터-프라이빗 IP 주소를 제공하기 때문에 파드간에 명시적으로 링크를 만들거나 컨테이너 포트를 호스트 포트에 매핑 할 필요가 없다. 이것은 파드 내의 컨테이너는 모두 로컬호스트에서 서로의 포트에 도달할 수 있으며 클러스터의 모든 파드는 NAT 없이 서로를 볼 수 있다는 의미이다. 이 문서의 나머지 부분에서는 이러한 네트워킹 모델에서 신뢰할 수 있는 서비스를 실행하는 방법에 대해 자세히 설명할 것이다. -이 가이드는 간단한 nginx 서버를 사용해서 개념증명을 보여준다. 동일한 원칙이 보다 완전한 [Jenkins CI 애플리케이션](https://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes)에서 구현된다. +이 가이드는 간단한 nginx 서버를 사용해서 개념증명을 보여준다. -{{% /capture %}} -{{% capture body %}} + + ## 파드를 클러스터에 노출하기 @@ -414,12 +414,13 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el ... ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [서비스를 사용해서 클러스터 내 애플리케이션에 접근하기](/docs/tasks/access-application-cluster/service-access-application-cluster/)를 더 자세히 알아본다. * [서비스를 사용해서 프론트 엔드부터 백 엔드까지 연결하기](/docs/tasks/access-application-cluster/connecting-frontend-backend/)를 더 자세히 알아본다. * [외부 로드 밸런서를 생성하기](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 더 자세히 알아본다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md index cef017128f..7550473fc2 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -1,16 +1,16 @@ --- title: 서비스 및 파드용 DNS -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + 이 페이지는 쿠버네티스의 DNS 지원에 대한 개요를 설명한다. -{{% /capture %}} -{{% capture body %}} + + ## 소개 @@ -262,13 +262,14 @@ options ndots:5 | 1.10 | 베타 (기본)| | 1.9 | 알파 | -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + DNS 구성 관리에 대한 지침은 [DNS 서비스 구성](/docs/tasks/administer-cluster/dns-custom-nameservers/) 에서 확인 할 수 있다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/services-networking/dual-stack.md b/content/ko/docs/concepts/services-networking/dual-stack.md index f234bcbbc3..11390c04d5 100644 --- a/content/ko/docs/concepts/services-networking/dual-stack.md +++ b/content/ko/docs/concepts/services-networking/dual-stack.md @@ -5,11 +5,11 @@ feature: description: > 파드와 서비스에 IPv4와 IPv6 주소 할당 -content_template: templates/concept +content_type: concept weight: 70 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.16" state="alpha" >}} @@ -17,9 +17,9 @@ weight: 70 만약 쿠버네티스 클러스터에서 IPv4/IPv6 이중 스택 네트워킹을 활성화하면, 클러스터는 IPv4와 IPv6 주소의 동시 할당을 지원하게 된다. -{{% /capture %}} -{{% capture body %}} + + ## 지원되는 기능 @@ -99,10 +99,11 @@ IPv6가 활성화된 외부 로드 밸런서를 지원하는 클라우드 공급 * Kubenet은 IP의 IPv4,IPv6의 위치 보고를 강제로 수행한다. (--cluster-cidr) -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [IPv4/IPv6 이중 스택 확인](/docs/tasks/network/validate-dual-stack) 네트워킹 -{{% /capture %}} + diff --git a/content/ko/docs/concepts/services-networking/endpoint-slices.md b/content/ko/docs/concepts/services-networking/endpoint-slices.md index 635798f5a2..2a2ffc45bf 100644 --- a/content/ko/docs/concepts/services-networking/endpoint-slices.md +++ b/content/ko/docs/concepts/services-networking/endpoint-slices.md @@ -1,11 +1,11 @@ --- title: 엔드포인트슬라이스 -content_template: templates/concept +content_type: concept weight: 15 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.17" state="beta" >}} @@ -13,9 +13,9 @@ _엔드포인트슬라이스_ 는 쿠버네티스 클러스터 내의 네트워 추적하는 간단한 방법을 제공한다. 이것은 엔드포인트를 더 확장하고, 확장 가능한 대안을 제안한다. -{{% /capture %}} -{{% capture body %}} + + ## 사용동기 @@ -173,11 +173,12 @@ text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그 교체되는 엔드포인트에 대해서 엔드포인트슬라이스를 자연스럽게 재포장한다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [엔드포인트슬라이스 활성화하기](/docs/tasks/administer-cluster/enabling-endpointslices) * [애플리케이션을 서비스와 함께 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 를 읽는다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/services-networking/ingress-controllers.md b/content/ko/docs/concepts/services-networking/ingress-controllers.md index 92a2387f5d..4600c32bcf 100644 --- a/content/ko/docs/concepts/services-networking/ingress-controllers.md +++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md @@ -1,11 +1,11 @@ --- title: 인그레스 컨트롤러 reviewers: -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + 인그레스 리소스가 작동하려면, 클러스터는 실행 중인 인그레스 컨트롤러가 반드시 필요하다. @@ -15,9 +15,9 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 프로젝트로써 쿠버네티스는 현재 [GCE](https://git.k8s.io/ingress-gce/README.md) 와 [nginx](https://git.k8s.io/ingress-nginx/README.md) 컨트롤러를 지원하고 유지한다. -{{% /capture %}} -{{% capture body %}} + + ## 추가 컨트롤러 @@ -52,11 +52,12 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 인그레스 컨트롤러의 설명서를 검토하여 선택 시 주의 사항을 이해해야한다. {{< /note >}} -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 자세히 알아보기. * [NGINX 컨트롤러로 Minikube에서 Ingress를 설정하기](/docs/tasks/access-application-cluster/ingress-minikube). -{{% /capture %}} + diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index 28f964a4ca..968274bc1c 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -1,15 +1,15 @@ --- title: 인그레스 -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.1" state="beta" >}} {{< glossary_definition term_id="ingress" length="all" >}} -{{% /capture %}} -{{% capture body %}} + + ## 용어 @@ -541,10 +541,11 @@ Events: * [Service.Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer) 사용. * [Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 사용. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [인그레스] API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)에 대해 배우기 * [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기 * [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/docs/tasks/access-application-cluster/ingress-minikube) -{{% /capture %}} + diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md index c3f4ee193b..55fde3a3be 100644 --- a/content/ko/docs/concepts/services-networking/network-policies.md +++ b/content/ko/docs/concepts/services-networking/network-policies.md @@ -1,19 +1,19 @@ --- title: 네트워크 정책 -content_template: templates/concept +content_type: concept weight: 50 --- {{< toc >}} -{{% capture overview %}} + 네트워크 정책은 {{< glossary_tooltip text="파드" term_id="pod">}} 그룹이 서로 간에 또는 다른 네트워크 엔드포인트와 통신할 수 있도록 허용하는 방법에 대한 명세이다. `NetworkPolicy` 리소스는 {{< glossary_tooltip text="레이블" term_id="label">}}을 사용해서 파드를 선택하고 선택한 파드에 허용되는 트래픽을 지정하는 규칙을 정의한다. -{{% /capture %}} -{{% capture body %}} + + ## 전제 조건 네트워크 정책은 [네트워크 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)으로 구현된다. 네트워크 정책을 사용하려면 NetworkPolicy를 지원하는 네트워킹 솔루션을 사용해야만 한다. 이를 구현하는 컨트롤러 없이 NetworkPolicy 리소스를 생성해도 아무런 효과가 없기 때문이다. @@ -211,12 +211,13 @@ SCTP 프로토콜 NetworkPolicy을 지원하는 {{< glossary_tooltip text="CNI" {{< /note >}} -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + - 자세한 설명과 추가 예시는 [네트워크 정책 선언](/docs/tasks/administer-cluster/declare-network-policy/)을 본다. - NetworkPolicy 리소스에서 사용되는 일반적인 시나리오는 [레시피](https://github.com/ahmetb/kubernetes-network-policy-recipes)를 본다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/services-networking/service-topology.md b/content/ko/docs/concepts/services-networking/service-topology.md index 16f140e583..da419f76e4 100644 --- a/content/ko/docs/concepts/services-networking/service-topology.md +++ b/content/ko/docs/concepts/services-networking/service-topology.md @@ -5,12 +5,12 @@ feature: description: > 클러스터 토폴로지를 기반으로 서비스 트래픽 라우팅. -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.17" state="alpha" >}} @@ -19,9 +19,9 @@ _서비스 토폴로지_ 를 활성화 하면 서비스는 클러스터의 노 클라이언트와 동일한 노드이거나 동일한 가용성 영역에 있는 엔드포인트로 우선적으로 라우팅되도록 지정할 수 있다. -{{% /capture %}} -{{% capture body %}} + + ## 소개 @@ -189,11 +189,12 @@ spec: ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [서비스 토폴로지 활성화하기](/docs/tasks/administer-cluster/enabling-service-topology)를 읽는다. * [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽는다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index c81309709f..e1e0d28c7c 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -5,14 +5,14 @@ feature: description: > 쿠버네티스를 사용하면 익숙하지 않은 서비스 디스커버리 메커니즘을 사용하기 위해 애플리케이션을 수정할 필요가 없다. 쿠버네티스는 파드에게 고유한 IP 주소와 파드 집합에 대한 단일 DNS 명을 부여하고, 그것들 간에 로드-밸런스를 수행할 수 있다. -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + {{< glossary_definition term_id="service" length="short" >}} @@ -20,9 +20,9 @@ weight: 10 쿠버네티스는 파드에게 고유한 IP 주소와 파드 집합에 대한 단일 DNS 명을 부여하고, 그것들 간에 로드-밸런스를 수행할 수 있다. -{{% /capture %}} -{{% capture body %}} + + ## 동기 @@ -1226,12 +1226,13 @@ SCTP는 Windows 기반 노드를 지원하지 않는다. kube-proxy는 유저스페이스 모드에 있을 때 SCTP 연결 관리를 지원하지 않는다. {{< /warning >}} -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [서비스와 애플리케이션 연결](/ko/docs/concepts/services-networking/connect-applications-service/) 알아보기 * [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 알아보기 * [엔드포인트슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)에 대해 알아보기 -{{% /capture %}} + diff --git a/content/ko/docs/concepts/storage/dynamic-provisioning.md b/content/ko/docs/concepts/storage/dynamic-provisioning.md index 11564490ec..bf0b257dbf 100644 --- a/content/ko/docs/concepts/storage/dynamic-provisioning.md +++ b/content/ko/docs/concepts/storage/dynamic-provisioning.md @@ -1,10 +1,10 @@ --- title: 동적 볼륨 프로비저닝 -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + 동적 볼륨 프로비저닝을 통해 온-디맨드 방식으로 스토리지 볼륨을 생성할 수 있다. 동적 프로비저닝이 없으면 클러스터 관리자는 클라우드 또는 스토리지 @@ -14,10 +14,10 @@ weight: 40 스토리지를 사전 프로비저닝 할 필요가 없다. 대신 사용자가 스토리지를 요청하면 자동으로 프로비저닝 한다. -{{% /capture %}} -{{% capture body %}} + + ## 배경 @@ -128,4 +128,4 @@ spec: 프로비전 해야 한다. [볼륨 바인딩 모드](/docs/concepts/storage/storage-classes/#volume-binding-mode)를 설정해서 수행할 수 있다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index b24c284ba8..397041842b 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -5,18 +5,18 @@ feature: description: > 로컬 스토리지, GCP나 AWS와 같은 퍼블릭 클라우드 공급자 또는 NFS, iSCSI, Gluster, Ceph, Cinder나 Flocker와 같은 네트워크 스토리지 시스템에서 원하는 스토리지 시스템을 자동으로 마운트한다. -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + 이 페이지는 쿠버네티스의 _퍼시스턴트 볼륨_ 의 현재 상태를 설명한다. [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 익숙해지는 것을 추천한다. -{{% /capture %}} -{{% capture body %}} + + ## 소개 @@ -741,8 +741,9 @@ spec: 않거나(이 경우 사용자가 일치하는 PV를 생성해야 함), 클러스터에 스토리지 시스템이 없음을 나타낸다(이 경우 사용자는 PVC가 필요한 구성을 배포할 수 없음). -{{% /capture %}} - {{% capture whatsnext %}} + + ## {{% heading "whatsnext" %}} + * [퍼시스턴트볼륨 생성](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume)에 대해 자세히 알아보기 * [퍼시스턴트볼륨클레임 생성](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim)에 대해 자세히 알아보기 @@ -754,4 +755,4 @@ spec: * [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core) * [퍼시스턴트볼륨클레임](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core) * [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core) -{{% /capture %}} + diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index 0d7416e72a..e73d886ef7 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -1,18 +1,18 @@ --- title: 스토리지 클래스 -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + 이 문서는 쿠버네티스의 스토리지클래스의 개념을 설명한다. [볼륨](/ko/docs/concepts/storage/volumes/)과 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes)에 익숙해지는 것을 권장한다. -{{% /capture %}} -{{% capture body %}} + + ## 소개 @@ -816,4 +816,4 @@ volumeBindingMode: WaitForFirstConsumer 적절한 퍼시스턴트볼륨을 선택할 때 파드의 모든 스케줄링 제약 조건을 고려할 수 있다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/storage/volume-pvc-datasource.md b/content/ko/docs/concepts/storage/volume-pvc-datasource.md index b58b882d6d..8b8e1b484f 100644 --- a/content/ko/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/ko/docs/concepts/storage/volume-pvc-datasource.md @@ -1,18 +1,18 @@ --- title: CSI 볼륨 복제하기 -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + 이 문서에서는 쿠버네티스의 기존 CSI 볼륨 복제의 개념을 설명한다. [볼륨] (/ko/docs/concepts/storage/volumes)을 숙지하는 것을 추천한다. -{{% /capture %}} -{{% capture body %}} + + ## 소개 @@ -66,4 +66,4 @@ spec: 새 PVC를 사용할 수 있게 되면, 복제된 PVC는 다른 PVC와 동일하게 소비된다. 또한, 이 시점에서 새롭게 생성된 PVC는 독립된 오브젝트이다. 원본 dataSource PVC와는 무관하게 독립적으로 소비하고, 복제하고, 스냅샷의 생성 또는 삭제를 할 수 있다. 이는 소스가 새롭게 생성된 복제본에 어떤 방식으로든 연결되어 있지 않으며, 새롭게 생성된 복제본에 영향 없이 수정하거나, 삭제할 수도 있는 것을 의미한다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/storage/volume-snapshot-classes.md b/content/ko/docs/concepts/storage/volume-snapshot-classes.md index f4d2991238..801ff624bb 100644 --- a/content/ko/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/ko/docs/concepts/storage/volume-snapshot-classes.md @@ -1,19 +1,19 @@ --- title: 볼륨 스냅샷 클래스 -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + 이 문서는 쿠버네티스의 `VolumeSnapshotClass` 개요를 설명한다. [볼륨 스냅샷](/docs/concepts/storage/volume-snapshots/)과 [스토리지 클래스](/docs/concepts/storage/storage-classes)의 숙지를 추천한다. -{{% /capture %}} -{{% capture body %}} + + ## 소개 @@ -62,4 +62,4 @@ parameters: 설명하는 파라미터를 가지고 있다. `driver` 에 따라 다른 파라미터를 사용할 수 있다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/storage/volume-snapshots.md b/content/ko/docs/concepts/storage/volume-snapshots.md index 60ad22c7cc..d2d85909e1 100644 --- a/content/ko/docs/concepts/storage/volume-snapshots.md +++ b/content/ko/docs/concepts/storage/volume-snapshots.md @@ -1,18 +1,18 @@ --- title: 볼륨 스냅샷 -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.17" state="beta" >}} 쿠버네티스에서 스토리지 시스템 볼륨 스냅샷은 _VolumeSnapshot_ 을 나타낸다. 이 문서는 이미 쿠버네티스 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)에 대해 잘 알고 있다고 가정한다. -{{% /capture %}} -{{% capture body %}} + + ## 소개 @@ -148,4 +148,4 @@ spec: 보다 자세한 사항은 [볼륨 스냅샷 및 스냅샷에서 볼륨 복원](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support)에서 확인할 수 있다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index eb63215bb5..a5a3e8aa23 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -1,10 +1,10 @@ --- title: 볼륨 -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + 컨테이너 내의 디스크에 있는 파일은 임시적이며, 컨테이너에서 실행될 때 애플리케이션에 적지 않은 몇 가지 문제가 발생한다. 첫째, 컨테이너가 충돌되면, @@ -15,10 +15,10 @@ kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상 [파드](/ko/docs/concepts/workloads/pods/pod/)에 대해 익숙해지는 것을 추천한다. -{{% /capture %}} -{{% capture body %}} + + ## 배경 @@ -1470,6 +1470,7 @@ sudo systemctl restart docker -{{% capture whatsnext %}} +## {{% heading "whatsnext" %}} + * [퍼시스턴트 볼륨과 함께 워드프레스와 MySQL 배포하기](/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)의 예시를 따른다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index b06881c53f..fa005e77a1 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -1,10 +1,10 @@ --- title: 크론잡 -content_template: templates/concept +content_type: concept weight: 80 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.8" state="beta" >}} @@ -28,8 +28,8 @@ kube-controller-manager 컨테이너에 설정된 시간대는 크론잡 컨트 63자라는 제약 조건이 있기 때문이다. -{{% /capture %}} -{{% capture body %}} + + ## 크론잡 @@ -77,12 +77,13 @@ Cannot determine if job needs to be started. Too many missed start time (> 100). 크론 잡은 오직 그 일정에 맞는 잡 생성에 책임이 있고, 잡은 그 잡이 대표하는 파드 관리에 책임이 있다. -{{% /capture %}} -{{% capture whatsnext %}} -[크론 표현 포맷](https://pkg.go.dev/github.com/robfig/cron?tab=doc#hdr-CRON_Expression_Format)은 + +## {{% heading "whatsnext" %}} + +[크론 표현 포맷](https://ko.wikipedia.org/wiki/Cron)은 크론잡 `schedule` 필드의 포맷을 문서화 한다. 크론 잡 생성과 작업에 대한 지침과 크론잡 매니페스트의 예는 [크론 잡으로 자동화된 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs/)를 참조한다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md index 91fbeb8cf8..83f3c428a3 100644 --- a/content/ko/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md @@ -1,10 +1,10 @@ --- title: 데몬셋 -content_template: templates/concept +content_type: concept weight: 50 --- -{{% capture overview %}} + _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도록 한다. 노드가 클러스터에 추가되면 파드도 추가된다. 노드가 클러스터에서 제거되면 해당 파드는 가비지(garbage)로 @@ -20,10 +20,10 @@ _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도 더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만, 각기 다른 하드웨어 유형에 따라 서로 다른 플래그, 메모리, CPU 요구가 달라진다. -{{% /capture %}} -{{% capture body %}} + + ## 데몬셋 사양 작성 @@ -118,7 +118,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml `NodeAffinity` 용어를 추가해서 데몬셋 컨트롤러 대신 기본 스케줄러를 사용해서 데몬셋을 스케줄할 수 있다. 이후에 기본 스케줄러를 사용해서 대상 호스트에 파드를 바인딩 한다. 만약 데몬셋 파드에 -이미 노드 선호도가 존재한다면 교체한다. 데몬셋 컨트롤러는 +이미 노드 선호도가 존재한다면 교체한다(대상 호스트를 선택하기 전에 원래 노드의 어피니티가 고려된다). 데몬셋 컨트롤러는 데몬셋 파드를 만들거나 수정할 때만 이런 작업을 수행하며, 데몬셋의 `spec.template` 은 변경되지 않는다. @@ -226,4 +226,4 @@ Kubelet이 감시하는 특정 디렉토리에 파일을 작성하는 파드를 디플로이먼트를 사용한다. 파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요하고, 다른 파드의 실행 이전에 필요한 경우에는 데몬셋을 사용한다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md index ab730109d5..96f41dc186 100644 --- a/content/ko/docs/concepts/workloads/controllers/deployment.md +++ b/content/ko/docs/concepts/workloads/controllers/deployment.md @@ -5,11 +5,11 @@ feature: description: > 쿠버네티스는 애플리케이션 또는 애플리케이션의 설정 변경시 점진적으로 롤아웃하는 동시에 애플리케이션을 모니터링해서 모든 인스턴스가 동시에 종료되지 않도록 보장한다. 만약 어떤 문제가 발생하면 쿠버네티스는 변경 사항을 롤백한다. 성장하는 디플로이먼트 솔루션 생태계를 이용한다. -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 [레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/)에 대한 선언적 업데이트를 제공한다. @@ -20,10 +20,10 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 디플로이먼트가 소유하는 레플리카셋은 관리하지 말아야 한다. 사용자의 유스케이스가 다음에 포함되지 않는 경우 쿠버네티스 리포지터리에 이슈를 올릴 수 있다. {{< /note >}} -{{% /capture %}} -{{% capture body %}} + + ## 유스케이스 @@ -1165,4 +1165,4 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설 일시 중지된 디플로이먼트는 PodTemplateSpec에 대한 변경 사항이 일시중지 된 경우 새 롤아웃을 트리거 하지 않는다. 디플로이먼트는 생성시 기본적으로 일시 중지되지 않는다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md index 9ccc803dce..f819614a6c 100644 --- a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md @@ -1,18 +1,18 @@ --- title: 가비지(Garbage) 수집 -content_template: templates/concept +content_type: concept weight: 60 --- -{{% capture overview %}} + 쿠버네티스의 가비지 수집기는 한때 소유자가 있었지만, 더 이상 소유자가 없는 오브젝트들을 삭제하는 역할을 한다. -{{% /capture %}} -{{% capture body %}} + + ## 소유자(owner)와 종속(dependent) @@ -168,15 +168,16 @@ kubectl delete replicaset my-repset --cascade=false [#26120](https://github.com/kubernetes/kubernetes/issues/26120)을 추적한다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + [디자인 문서 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md) [디자인 문서 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md) -{{% /capture %}} + diff --git a/content/ko/docs/concepts/workloads/controllers/jobs-run-to-completion.md b/content/ko/docs/concepts/workloads/controllers/jobs-run-to-completion.md index 5aba53574b..4d6e93ded5 100644 --- a/content/ko/docs/concepts/workloads/controllers/jobs-run-to-completion.md +++ b/content/ko/docs/concepts/workloads/controllers/jobs-run-to-completion.md @@ -1,6 +1,6 @@ --- title: 잡 - 실행부터 완료까지 -content_template: templates/concept +content_type: concept feature: title: 배치 실행 description: > @@ -8,7 +8,7 @@ feature: weight: 70 --- -{{% capture overview %}} + 잡에서 하나 이상의 파드를 생성하고 지정된 수의 파드가 성공적으로 종료되도록 한다. 파드가 성공적으로 완료되면, 성공적으로 완료된 잡을 추적한다. 지정된 수의 @@ -21,10 +21,10 @@ weight: 70 잡을 사용하면 여러 파드를 병렬로 실행할 수도 있다. -{{% /capture %}} -{{% capture body %}} + + ## 예시 잡 실행하기 @@ -469,10 +469,10 @@ spec: 스파크 드라이버를 실행한 다음, 정리한다. 이 접근 방식의 장점은 전체 프로세스가 잡 오브젝트의 완료를 보장하면서도, -파드 생성과 작업 할당 방법을 완전히 제어할 수 있다는 점이다. +파드 생성과 작업 할당 방법을 완전히 제어하고 유지한다는 것이다. ## 크론 잡 {#cron-jobs} [`크론잡`](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 사용해서 Unix 도구인 `cron`과 유사하게 지정된 시간/일자에 실행되는 잡을 생성할 수 있다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/workloads/controllers/replicaset.md b/content/ko/docs/concepts/workloads/controllers/replicaset.md index 80bcf6052b..e99bb4f7c5 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ko/docs/concepts/workloads/controllers/replicaset.md @@ -1,18 +1,18 @@ --- title: 레플리카셋 -content_template: templates/concept +content_type: concept weight: 10 --- -{{% capture overview %}} + 레플리카셋의 목적은 레플리카 파드 집합의 실행을 항상 안정적으로 유지하는 것이다. 이처럼 레플리카셋은 보통 명시된 동일 파드 개수에 대한 가용성을 보증하는데 사용한다. -{{% /capture %}} -{{% capture body %}} + + ## 레플리카셋의 작동 방식 @@ -362,4 +362,4 @@ kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50 설명된 설정-기반의 셀렉터의 요건을 지원하지 않는다는 점을 제외하면 유사하다. 따라서 레플리카셋이 레플리케이션 컨트롤러보다 선호된다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md index 4551dc99b4..16146a45b6 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md @@ -6,11 +6,11 @@ feature: description: > 오류가 발생한 컨테이너를 재시작하고, 노드가 죽었을 때 컨테이너를 교체하기 위해 다시 스케줄하고, 사용자 정의 상태 체크에 응답하지 않는 컨테이너를 제거하며, 서비스를 제공할 준비가 될 때까지 클라이언트에 해당 컨테이너를 알리지 않는다. -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + {{< note >}} [`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/) 을 구성하는 [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/) 가 현재 권장되는 레플리케이션 설정 방법이다. @@ -20,10 +20,10 @@ _레플리케이션 컨트롤러_ 는 언제든지 지정된 수의 파드 레 실행 중임을 보장한다. 다시 말하면, 레플리케이션 컨트롤러는 파드 또는 동일 종류의 파드의 셋이 항상 기동되고 사용 가능한지 확인한다. -{{% /capture %}} -{{% capture body %}} + + ## 레플리케이션 컨트롤러의 동작방식 @@ -282,4 +282,4 @@ API 오브젝트에 대한 더 자세한 것은 [스테이트리스 애플리케이션 레플리케이션 컨트롤러 실행하기](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/) 를 참조하라. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md index e83c02b50d..1779ea4f92 100644 --- a/content/ko/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md @@ -1,17 +1,17 @@ --- title: 스테이트풀셋 -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + 스테이트풀셋은 애플리케이션의 스테이트풀을 관리하는데 사용하는 워크로드 API 오브젝트이다. {{< glossary_definition term_id="statefulset" length="all" >}} -{{% /capture %}} -{{% capture body %}} + + ## 스테이트풀셋 사용 @@ -262,12 +262,13 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가 실행하려고 시도한 모든 파드를 삭제해야 한다. 그러면 스테이트풀셋은 되돌린 템플릿을 사용해서 파드를 다시 생성하기 시작 한다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [스테이트풀 애플리케이션의 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/)의 예시를 따른다. * [카산드라와 스테이트풀셋 배포](/ko/docs/tutorials/stateful-application/cassandra/)의 예시를 따른다. * [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-replicated-stateful-application/)의 예시를 따른다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md index aefccc9243..c095dd31c5 100644 --- a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -1,10 +1,10 @@ --- title: 완료된 리소스를 위한 TTL 컨트롤러 -content_template: templates/concept +content_type: concept weight: 65 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.12" state="alpha" >}} @@ -18,12 +18,12 @@ TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을 [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 로 `TTLAfterFinished` 를 활성화 할 수 있다. -{{% /capture %}} -{{% capture body %}} + + ## TTL 컨트롤러 @@ -75,12 +75,13 @@ TTL 컨트롤러는 쿠버네티스 리소스에 에서 NTP를 실행해야 한다. 시계가 항상 정확한 것은 아니지만, 그 차이는 아주 작아야 한다. 0이 아닌 TTL을 설정할때는 이 위험에 대해 유의해야 한다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + [자동으로 잡 정리](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/#완료된-잡을-자동으로-정리) [디자인 문서](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) -{{% /capture %}} + diff --git a/content/ko/docs/concepts/workloads/pods/disruptions.md b/content/ko/docs/concepts/workloads/pods/disruptions.md index d2c91e3ecb..bd2f2023af 100644 --- a/content/ko/docs/concepts/workloads/pods/disruptions.md +++ b/content/ko/docs/concepts/workloads/pods/disruptions.md @@ -1,10 +1,10 @@ --- title: 중단(disruption) -content_template: templates/concept +content_type: concept weight: 60 --- -{{% capture overview %}} + 이 가이드는 고가용성 애플리케이션을 구성하려는 소유자와 파드에서 발생하는 장애 유형을 이해하기 원하는 애플리케이션 소유자를 위한 것이다. @@ -12,10 +12,10 @@ weight: 60 또한 클러스터의 업그레이드와 오토스케일링과 같은 클러스터의 자동화 작업을 하려는 관리자를 위한 것이다. -{{% /capture %}} -{{% capture body %}} + + ## 자발적 중단과 비자발적 중단 @@ -242,13 +242,14 @@ Pod Disruption Budgets를 사용할 필요가 없다. 자발적 중단를 허용하는 작업의 대부분은 오토스케일링과 비자발적 중단를 지원하는 작업과 겹친다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [Pod Disruption Budget 설정하기](/docs/tasks/run-application/configure-pdb/)의 단계를 따라서 애플리케이션을 보호한다. * [노드 비우기](/docs/tasks/administer-cluster/safely-drain-node/)에 대해 자세히 알아보기 -{{% /capture %}} + diff --git a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md index dd061e5130..721405614c 100644 --- a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md @@ -1,10 +1,10 @@ --- title: 임시(Ephemeral) 컨테이너 -content_template: templates/concept +content_type: concept weight: 80 --- -{{% capture overview %}} + {{< feature-state state="alpha" for_k8s_version="v1.16" >}} @@ -19,9 +19,9 @@ weight: 80 이 알파 기능은 향후 크게 변경되거나, 완전히 제거될 수 있다. {{< /warning >}} -{{% /capture %}} -{{% capture body %}} + + ## 임시 컨테이너 이해하기 @@ -188,4 +188,4 @@ Ephemeral Containers: kubectl attach -it example-pod -c debugger ``` -{{% /capture %}} + diff --git a/content/ko/docs/concepts/workloads/pods/init-containers.md b/content/ko/docs/concepts/workloads/pods/init-containers.md index c45d3cc838..0e1f614de3 100644 --- a/content/ko/docs/concepts/workloads/pods/init-containers.md +++ b/content/ko/docs/concepts/workloads/pods/init-containers.md @@ -1,19 +1,19 @@ --- title: 초기화 컨테이너 -content_template: templates/concept +content_type: concept weight: 40 --- -{{% capture overview %}} + 이 페이지는 초기화 컨테이너에 대한 개요를 제공한다. 초기화 컨테이너는 {{< glossary_tooltip text="파드" term_id="pod" >}}의 앱 컨테이너들이 실행되기 전에 실행되는 특수한 컨테이너이며, 앱 이미지에는 없는 유틸리티 또는 설정 스크립트 등을 포함할 수 있다. 초기화 컨테이너는 `containers` 배열(앱 컨테이너를 기술하는)과 나란히 파드 스펙에 명시할 수 있다. -{{% /capture %}} -{{% capture body %}} + + ## 초기화 컨테이너 이해하기 @@ -314,12 +314,13 @@ myapp-pod 1/1 Running 0 9m 동안 종료되었다. 그리고 초기화 컨테이너의 완료 기록이 가비지 수집 때문에 유실되었다. -{{% /capture %}} -{{% capture whatsnext %}} -* [초기화 컨테이너를 가진 파드 생성하기](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container) +## {{% heading "whatsnext" %}} + + +* [초기화 컨테이너를 가진 파드 생성하기](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container) * [초기화 컨테이너 디버깅](/docs/tasks/debug-application-cluster/debug-init-containers/) 알아보기 -{{% /capture %}} + diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index e29e358d97..e8e384a4ab 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -1,20 +1,20 @@ --- title: 파드 라이프사이클 -content_template: templates/concept +content_type: concept weight: 30 --- -{{% capture overview %}} + {{< comment >}}Updated: 4/14/2015{{< /comment >}} {{< comment >}}Edited and moved to Concepts section: 2/2/17{{< /comment >}} 이 페이지는 파드의 라이프사이클을 설명한다. -{{% /capture %}} -{{% capture body %}} + + ## 파드의 단계(phase) @@ -388,10 +388,11 @@ spec: * 노드 컨트롤러가 파드의 `phase`를 Failed로 설정한다. * 만약 컨트롤러로 실행되었다면, 파드는 어딘가에서 재생성된다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Hands-on 경험하기 [컨테이너 라이프사이클 이벤트에 핸들러 부착하기](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). @@ -401,6 +402,6 @@ spec: * [컨테이너 라이프사이클 후크(hook)](/ko/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배우기. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/workloads/pods/pod-overview.md b/content/ko/docs/concepts/workloads/pods/pod-overview.md index e1239a817e..5b2af22d73 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-overview.md +++ b/content/ko/docs/concepts/workloads/pods/pod-overview.md @@ -1,18 +1,18 @@ --- title: 파드(Pod) 개요 -content_template: templates/concept +content_type: concept weight: 10 card: name: concepts weight: 60 --- -{{% capture overview %}} + 이 페이지는 쿠버네티스 객체 모델 중 가장 작은 배포 가능한 객체인 `파드` 에 대한 개요를 제공한다. -{{% /capture %}} -{{% capture body %}} + + ## 파드에 대해 이해하기 *파드* 는 쿠버네티스 애플리케이션의 기본 실행 단위이다. 쿠버네티스 객체 모델 중 만들고 배포할 수 있는 가장 작고 간단한 단위이다. 파드는 {{< glossary_tooltip term_id="cluster" text="클러스터" >}} 에서의 Running 프로세스를 나타낸다. @@ -104,12 +104,13 @@ metadata: 노드에서 "kubelet"이 파드 템플릿과 업데이트에 관련된 세부 정보를 직접 관찰하거나 관리하지 않으며, 이러한 세부 정보는 추상화되지 않는다. 이러한 추상화와 분리는 시스템 시맨틱을 단순화하며, 기존 코드를 변경하지 않고 클러스터의 동작을 확장할 수 있도록 한다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [파드](/ko/docs/concepts/workloads/pods/pod/)에 대해 더 배워보자. * [분산 시스템 툴킷: 복합 컨테이너의 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)은 둘 이상의 컨테이너가 있는 파드의 공통 레이아웃에 대해 설명한다. * 파드의 동작에 대해 더 알아보자. * [파드 종료](/ko/docs/concepts/workloads/pods/pod/#파드의-종료) * [파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/) -{{% /capture %}} + diff --git a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index 040a228d70..d7cc7d545b 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -1,18 +1,18 @@ --- title: 파드 토폴로지 분배 제약 조건 -content_template: templates/concept +content_type: concept weight: 50 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.18" state="beta" >}} 사용자는 _토폴로지 분배 제약 조건_ 을 사용해서 지역, 영역, 노드 그리고 기타 사용자-정의 토폴로지 도메인과 같이 장애-도메인으로 설정된 클러스터에 걸쳐 파드가 분산되는 방식을 제어할 수 있다. 이를 통해 고가용성뿐만 아니라, 효율적인 리소스 활용의 목적을 이루는 데 도움이 된다. -{{% /capture %}} -{{% capture body %}} + + ## 필수 구성 요소 @@ -245,4 +245,4 @@ profiles: - 디플로이먼트를 스케일링 다운하면 그 결과로 파드의 분포가 불균형이 될 수 있다. - 파드와 일치하는 테인트(taint)가 된 노드가 존중된다. [이슈 80921](https://github.com/kubernetes/kubernetes/issues/80921)을 본다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/workloads/pods/pod.md b/content/ko/docs/concepts/workloads/pods/pod.md index b4c7e63fbe..9f7d06d091 100644 --- a/content/ko/docs/concepts/workloads/pods/pod.md +++ b/content/ko/docs/concepts/workloads/pods/pod.md @@ -1,15 +1,15 @@ --- title: 파드 -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + _파드_ 는 쿠버네티스에서 생성되고 관리될 수 있는 배포 가능한 최소 컴퓨팅 단위이다. -{{% /capture %}} -{{% capture body %}} + + ## 파드는 무엇인가? _파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로) 하나 이상의(도커 컨테이너 같은) 컨테이너 그룹이다. @@ -203,4 +203,4 @@ spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true' 파드 오브젝트에 대한 매니페스트를 생성할때는 지정된 이름이 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)인지 확인해야 한다. -{{% /capture %}} + diff --git a/content/ko/docs/concepts/workloads/pods/podpreset.md b/content/ko/docs/concepts/workloads/pods/podpreset.md index 97ed144f68..4b37e0c232 100644 --- a/content/ko/docs/concepts/workloads/pods/podpreset.md +++ b/content/ko/docs/concepts/workloads/pods/podpreset.md @@ -1,19 +1,19 @@ --- title: 파드 프리셋 -content_template: templates/concept +content_type: concept weight: 50 --- -{{% capture overview %}} + {{< feature-state for_k8s_version="v1.6" state="alpha" >}} 이 페이지는 파드프리셋(PodPreset)에 대한 개요를 제공한다. 파드프리셋은 파드 생성 시간에 파드에 특정 정보를 주입하기 위한 오브젝트이다. 해당 정보에는 시크릿, 볼륨, 볼륨 마운트, 환경 변수가 포함될 수 있다. -{{% /capture %}} -{{% capture body %}} + + ## 파드 프리셋 이해하기 파드프리셋은 파드 생성 시간에 파드에 추가적인 런타임 요구사항을 @@ -79,12 +79,13 @@ weight: 50 있을 것이다. 이 경우에는, 다음과 같은 양식으로 어노테이션을 파드 스펙에 추가한다. `podpreset.admission.kubernetes.io/exclude: "true"`. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + [파드프리셋을 사용하여 파드에 데이터 주입하기](/docs/tasks/inject-data-application/podpreset/)를 본다. 배경에 대한 자세한 정보를 위해서는, [파드프리셋을 위한 디자인 제안](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)을 본다. -{{% /capture %}} + diff --git a/content/ko/docs/contribute/_index.md b/content/ko/docs/contribute/_index.md index f059747769..9dd0b23cd3 100644 --- a/content/ko/docs/contribute/_index.md +++ b/content/ko/docs/contribute/_index.md @@ -1,5 +1,5 @@ --- -content_template: templates/concept +content_type: concept title: 쿠버네티스 문서에 기여하기 linktitle: 기여 main_menu: true @@ -10,7 +10,7 @@ card: title: 기여 시작하기 --- -{{% capture overview %}} + 이 웹사이트는 [쿠버네티스 SIG Docs](/docs/contribute/#get-involved-with-sig-docs)에 의해서 관리됩니다. @@ -23,9 +23,9 @@ card: 쿠버네티스 문서는 새롭고 경험이 풍부한 모든 기여자의 개선을 환영합니다! -{{% /capture %}} -{{% capture body %}} + + ## 시작하기 @@ -75,4 +75,4 @@ SIG Docs는 여러가지 방법으로 의견을 나누고 있습니다. - [기여자 치트시트](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet)를 읽고 쿠버네티스 기능 개발에 참여합니다. - [블로그 게시물 또는 사례 연구](/docs/contribute/new-content/blogs-case-studies/)를 제출합니다. -{{% /capture %}} + diff --git a/content/ko/docs/contribute/advanced.md b/content/ko/docs/contribute/advanced.md index de723b3353..3f30f6eff9 100644 --- a/content/ko/docs/contribute/advanced.md +++ b/content/ko/docs/contribute/advanced.md @@ -1,11 +1,11 @@ --- title: 고급 기여 slug: advanced -content_template: templates/concept +content_type: concept weight: 98 --- -{{% capture overview %}} + 이 페이지에서는 당신이 [새로운 콘텐츠에 기여](/ko/docs/contribute/new-content/overview)하고 @@ -13,9 +13,9 @@ weight: 98 이해한다고 가정한다. 또한 기여하기 위한 더 많은 방법에 대해 배울 준비가 되었다고 가정한다. 이러한 작업 중 일부에는 Git 커맨드 라인 클라이언트와 다른 도구를 사용해야 한다. -{{% /capture %}} -{{% capture body %}} + + ## 일주일 동안 PR 랭글러(Wrangler) 되기 @@ -245,4 +245,4 @@ SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 SIG Docs 비디오가 자동으로 유튜브에 업로드된다. -{{% /capture %}} + diff --git a/content/ko/docs/contribute/generate-ref-docs/_index.md b/content/ko/docs/contribute/generate-ref-docs/_index.md new file mode 100644 index 0000000000..756c509206 --- /dev/null +++ b/content/ko/docs/contribute/generate-ref-docs/_index.md @@ -0,0 +1,11 @@ +--- +title: 참조 문서 개요 +main_menu: true +weight: 80 +--- + +이 섹션은 쿠버네티스 참조 가이드를 생성하는 방법에 대해 설명한다. + +참조 문서화 시스템을 빌드하려면, 다음의 가이드를 참고한다. + +* [참조 문서 생성에 대한 퀵스타트 가이드](/docs/contribute/generate-ref-docs/quickstart/) \ No newline at end of file diff --git a/content/ko/docs/contribute/localization_ko.md b/content/ko/docs/contribute/localization_ko.md index af2465ac6a..72d6c7f3d7 100644 --- a/content/ko/docs/contribute/localization_ko.md +++ b/content/ko/docs/contribute/localization_ko.md @@ -1,16 +1,54 @@ --- title: 쿠버네티스 문서 한글화 가이드 -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + 쿠버네티스 문서 한글화를 위한 가이드 -{{% /capture %}} -{{% capture body %}} + + + +## 팀 마일스톤 관리 + +쿠버네티스 문서 한글화팀은 커뮤니티의 +[현지화 가이드](/docs/contribute/localization/#branching-strategy)에 따라 한글화를 +위한 팀 마일스톤과 개발 브랜치를 관리한다. 본 섹션은 한글화팀의 팀 마일스톤 관리에 특화된 +내용을 다룬다. + +한글화팀은 `master` 브랜치에서 분기한 개발 브랜치를 사용한다. 개발 브랜치 이름은 다음과 같은 +구조를 갖는다. + +`dev-<소스 버전>-ko.<팀 마일스톤>` + +개발 브랜치는 약 2주에서 3주 사이의 팀 마일스톤 기간 동안 공동의 작업을 위해 사용되며, 팀 +마일스톤이 종료될 때 원 브랜치로 병합(merge)된다. + +업스트림(upstream)의 릴리스 주기(약 3개월)에 따라 다음 버전으로 마일스톤을 변경하는 시점에는 +일시적으로 `release-<소스 버전>` 브랜치를 원 브랜치로 사용하는 개발 브랜치를 추가로 운영한다. + +[한글화팀의 정기 화상 회의 일정](https://github.com/kubernetes/community/tree/master/sig-docs#meetings)과 +팀 마일스톤 주기는 대체로 일치하며, 정기 회의를 통해 팀 마일스톤마다 PR 랭글러(wrangler)를 +지정한다. + +한글화팀의 PR 랭글러가 갖는 의무는 업스트림의 +[PR 랭글러](/ko/docs/contribute/advanced/#일주일-동안-pr-랭글러-wrangler-되기)가 갖는 +의무와 유사하다. 단, 업스트림의 PR 랭글러와는 달리 승인자가 아니어도 팀 마일스톤의 PR 랭글러가 +될 수 있다. 그래서, 보다 상위 권한이 필요한 업무가 발생한 경우, PR 랭글러는 해당 권한을 가진 +한글화팀 멤버에게 처리를 요청한다. + +업스트림의 [PR 랭글러에게 유용한 GitHub 쿼리](/ko/docs/contribute/advanced/#랭글러에게-유용한-github-쿼리)를 +기반으로 작성한, 한글화팀의 PR 랭글러에게 유용한 쿼리를 아래에 나열한다. + +- [CLA 서명 없음, 병합할 수 없음](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fko) +- [LGTM 필요](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fko+-label%3Algtm+) +- [LGTM 보유, 문서 승인 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fko+label%3Algtm) +- [퀵윈(Quick Wins)](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fko%22+) + +팀 마일스톤 일정과 PR 랭글러는 커뮤니티 슬랙 내 [#kubernetes-docs-ko 채널](https://kubernetes.slack.com/archives/CA1MMR86S)에 공지된다. ## 문체 가이드 @@ -67,7 +105,7 @@ content_template: templates/concept + + + title: 쿠버네티스 컴포넌트 -content_template: templates/concept +content_type: concept weight: 10 ``` @@ -124,7 +162,7 @@ PersistentVolumeClaimSpec | PersistentVolumeClaimSpec {{% note %}} 단, API 오브젝트 한글화 원칙에 예외가 있을 수 있으며, 이 경우에는 가능한 [한글화 용어집](#한글화-용어집)을 준용한다. (예를 들면, Horizontal Pod Autoscaler -는 API 오브젝트에 대해 외래어 표기법 적용하지 않고 원문 그대로 표기한다.) +는 API 오브젝트에 대해 외래어 표기법을 적용하지 않고 원문 그대로 표기한다.) {{% /note %}} {{% note %}} @@ -201,6 +239,7 @@ Age | 기간 | Allocation | 할당량 | alphanumeric | 영숫자 | Annotation | 어노테이션 | +APIService | API서비스(APIService) | API 오브젝트인 경우 App | 앱 | Appendix | 부록 | Application | 애플리케이션 | @@ -210,6 +249,7 @@ autoscaler | 오토스케일러 | availability zone | 가용성 영역(availability zone) | bare pod | 베어(bare) 파드 | beta | 베타 | +Binding | 바인딩(Binding) | API 오브젝트인 경우 boilerplate | 상용구 | Boot | 부트 | Build | 빌드 | @@ -217,31 +257,39 @@ Cache | 캐시 | Calico | 캘리코(Calico) | canary | 카나리(canary) | 릴리스 방식에 관련한 용어인 경우에 한함 cascading | 캐스케이딩(cascading) | +CertificateSigningRequest | CertificateSigningRequest | API 오브젝트인 경우 character set | 캐릭터 셋 | Charts | 차트 | checkpoint | 체크포인트 | Cilium | 실리움(Cilium) | CLI | CLI | Cluster | 클러스터 | +ClusterRole | 클러스터롤(ClusterRole) | API 오브젝트인 경우 +ClusterRoleBinding | 클러스터롤바인딩(ClusterRoleBinding) | API 오브젝트인 경우 Command Line Tool | 커맨드라인 툴 | -Config Map | 컨피그 맵 | +ComponentStatus | 컴포넌트스테이터스(ComponentStatus) | API 오브젝트인 경우 +ConfigMap | 컨피그맵(ConfigMap) | API 오브젝트인 경우 configuration | 구성, 설정 | Connection | 연결 | containerized | 컨테이너화 된 | Context | 컨텍스트 | Control Plane | 컨트롤 플레인 | controller | 컨트롤러 | -Cron Job | 크론 잡 | +ControllerRevision | 컨트롤러리비전(ControllerRevision) | API 오브젝트인 경우 +cron job | 크론 잡 | +CronJob | 크론잡(CronJob) | API 오브젝트인 경우 +CSIDriver | CSI드라이버(CSIDriver) | API 오브젝트인 경우 +CSINode | CSI노드(CSINode) | API 오브젝트인 경우 custom metrics | 사용자 정의 메트릭 | -Custom resource | 사용자 정의 리소스 | -CustomResourceDefinition | 커스텀 리소스 데피니션 | +custom resource | 사용자 정의 리소스 | +CustomResourceDefinition | 커스텀리소스데피니션(CustomResourceDefinition) | API 오브젝트인 경우 Daemon | 데몬 | -Daemon Set | 데몬 셋 | +DaemonSet | 데몬셋(DaemonSet) | API 오브젝트인 경우 Dashboard | 대시보드 | Data Plane | 데이터 플레인 | Default Limit | 기본 상한 | Default Request | 기본 요청량 | -Deployment | 디플로이먼트 | +Deployment | 디플로이먼트(Deployment) | API 오브젝트인 경우 deprecated | 사용 중단(deprecated) | descriptor | 디스크립터, 식별자 | Desired number of pods | 의도한 파드의 수 | @@ -254,9 +302,11 @@ Docker Swarm | Docker Swarm | Downward API | 다운워드(Downward) API | draining | 드레이닝(draining) | egress | 이그레스, 송신(egress) | -Endpoint | 엔드포인트 | +endpoint | 엔드포인트 | +EndpointSlice | 엔드포인트슬라이스(EndpointSlice) | API 오브젝트인 경우 +Endpoints | 엔드포인트(Endpoints) | API 오브젝트인 경우 entry point | 진입점 | -Event | 이벤트 | +Event | 이벤트(Event) | API 오브젝트인 경우 evict | 축출하다 | eviction | 축출 | Exec | Exec | @@ -283,20 +333,24 @@ Hypervisor | 하이퍼바이저 | idempotent | 멱등성 | Image | 이미지 | Image Pull Secrets | 이미지 풀(Pull) 시크릿 | -Ingress | 인그레스 | +Ingress | 인그레스(Ingress) | API 오브젝트인 경우 +IngressClass | 인그레스클래스(IngressClass) | API 오브젝트인 경우 Init Container | 초기화 컨테이너 | Instance group | 인스턴스 그룹 | introspection | 인트로스펙션(introspection) | Istio | 이스티오(Istio) | -Job | 잡 | +Job | 잡(Job) | API 오브젝트인 경우 kube-proxy | kube-proxy | Kubelet | Kubelet | Kubernetes | 쿠버네티스 | Kube-router | Kube-router | label | 레이블 | +Lease | 리스(Lease) | API 오브젝트인 경우 lifecycle | 라이프사이클 | +LimitRange | 리밋레인지(LimitRange) | API 오브젝트인 경우 Linux | 리눅스 | load | 부하 | +LocalSubjectAccessReview | 로컬서브젝트액세스리뷰(LocalSubjectAccessReview) | API 오브젝트인 경우 Log | 로그 | loopback | 루프백(loopback) | Lost | Lost | 클레임의 상태에 한함 @@ -311,11 +365,12 @@ Minikube | Minikube | Mirror pod | 미러 파드(mirror pod) | monitoring | 모니터링 | multihomed | 멀티홈드(multihomed) | +MutatingWebhookConfiguration | MutatingWebhookConfiguration | API 오브젝트인 경우 naked pod | 네이키드(naked) 파드 | -Namespace | 네임스페이스 | +Namespace | 네임스페이스(Namespace) | API 오브젝트인 경우 netfilter | 넷필터(netfilter) | -Network Policy | 네트워크 폴리시 | -Node | 노드 | +NetworkPolicy | 네트워크폴리시(NetworkPolicy) | API 오브젝트인 경우 +Node | 노드(Node) | API 오브젝트인 경우 node lease | 노드 리스(lease) Object | 오브젝트 | Orchestrate | 오케스트레이션하다 | @@ -323,16 +378,19 @@ Output | 출력 | parameter | 파라미터 | patch | 패치 | Pending | Pending | 파드, 클레임의 상태에 한함 -Persistent Volume | 퍼시스턴트 볼륨 | -Persistent Volume Claim | 퍼시스턴트 볼륨 클레임 | +PersistentVolume | 퍼시스턴트볼륨(PersistentVolume) | API 오브젝트인 경우 +PersistentVolumeClaim | 퍼시스턴트볼륨클레임(PersistentVolumeClaim) | API 오브젝트인 경우 pipeline | 파이프라인 | placeholder pod | 플레이스홀더(placeholder) 파드 | -Pod | 파드 | +Pod | 파드(Pod) | API 오브젝트인 경우 Pod Preset | 파드 프리셋 | PodAntiAffinity | 파드안티어피니티(PodAntiAffinity) | -PodDisruptionBudget | PodDisruptionBudget | +PodDisruptionBudget | PodDisruptionBudget | API 오브젝트인 경우 +PodSecurityPolicy | 파드시큐리티폴리시(PodSecurityPolicy) | API 오브젝트인 경우 +PodTemplate | 파드템플릿(PodTemplate) | API 오브젝트인 경우 postfix | 접미사 | prefix | 접두사 | +PriorityClass | 프라이어리티클래스(PriorityClass) | API 오브젝트인 경우 Privileged | 특권을 가진(privileged) | Prometheus | 프로메테우스 | proof of concept | 개념 증명 | @@ -348,29 +406,33 @@ redirect | 리다이렉트(redirect) | redirection | 리다이렉션 | Registry | 레지스트리 | Release | 릴리스 | -Replica Set | 레플리카 셋 | +ReplicaSet | 레플리카셋(ReplicaSet) | API 오브젝트인 경우 replicas | 레플리카 | -Replication Controller | 레플리케이션 컨트롤러 | +ReplicationController | 레플리케이션컨트롤러(ReplicationController) | API 오브젝트인 경우 repository | 리포지터리 | resource | 리소스 | Resource Limit | 리소스 상한 | -Resource Quota | 리소스 쿼터 | +ResourceQuota | 리소스쿼터(ResourceQuota) | API 오브젝트인 경우 return | 반환하다 | revision | 리비전 | -Role | 롤 | +Role | 롤(Role) | API 오브젝트인 경우 +RoleBinding | 롤바인딩(RoleBinding) | API 오브젝트인 경우 rollback | 롤백 | rolling update | 롤링 업데이트 | rollout | 롤아웃 | Romana | 로마나(Romana) | Running | Running | 파드의 상태에 한함 runtime | 런타임 | +RuntimeClass | 런타임클래스(RuntimeClass) | API 오브젝트인 경우 Scale | 스케일 | -Secret | 시크릿 | +Secret | 시크릿(Secret) | API 오브젝트인 경우 segment | 세그먼트 | Selector | 셀렉터 | Self-healing | 자가 치유 | -Service | 서비스 | -Service Account | 서비스 어카운트 | +SelfSubjectAccessReview | 셀프서브젝트액세스리뷰(SelfSubjectAccessReview) | API 오브젝트인 경우 +SelfSubjectRulesReview | SelfSubjectRulesReview | API 오브젝트이지만 용어를 구성하는 단어 중 복수형 Rules를 '룰스'로 외래어 표기하는 경우 한국어 독자에게 다소 생경할 수 있어 예외적으로 영문 용어를 사용함 +Service | 서비스(Service) | API 오브젝트인 경우 +ServiceAccount | 서비스어카운트(ServiceAccount) | API 오브젝트인 경우 service discovery | 서비스 디스커버리 | service mesh | 서비스 메시 | Session | 세션 | @@ -383,10 +445,11 @@ skew | 차이(skew) | snippet | 스니펫(snippet) | spec | 명세, 스펙, 사양 | specification | 명세 | -Stateful Set | 스테이트풀 셋 | +StatefulSet | 스테이트풀셋(StatefulSet) | API 오브젝트인 경우 stateless | 스테이트리스 | Static pod | 스태틱(static) 파드 | -Storage Class | 스토리지 클래스 | +StorageClass | 스토리지클래스(StorageClass) | API 오브젝트인 경우 +SubjectAccessReview | 서브젝트액세스리뷰(SubjectAccessReview) | API 오브젝트인 경우 Sub-Object | 서브-오브젝트 | support | 지원 | Surge | 증가율 | 롤링업데이트 전략에 한함 @@ -394,6 +457,7 @@ System | 시스템 | taint | 테인트(taint) | Task | 태스크 | Terminated | Terminated | 파드의 상태에 한함 +TokenReview | 토큰리뷰(TokenReview) | API 오브젝트인 경우 tolerations | 톨러레이션(toleration) | Topology spread constraints | 토폴로지 분배 제약 조건 | Tools | 도구 | @@ -403,9 +467,11 @@ ubuntu | 우분투 | use case | 유스케이스 | userspace | 유저스페이스(userspace) | Utilization | 사용량, 사용률 | +ValidatingWebhookConfiguration | ValidatingWebhookConfiguration | API 오브젝트인 경우 verbosity | 로그 상세 레벨(verbosity) | virtualization | 가상화 | Volume | 볼륨 | +VolumeAttachment | 볼륨어태치먼트(VolumeAttachment) | API 오브젝트인 경우 Waiting | Waiting | 파드의 상태에 한함 Walkthrough | 연습 | Weave-net | 위브넷(Weave Net) | Weaveworks 사의 솔루션 공식 명칭은 'Weave Net'이므로 한영병기 시 공식 명칭 사용 @@ -414,4 +480,4 @@ Worker | 워커 | 노드의 형태에 한함 Workload | 워크로드 | YAML | YAML | -{{% /capture %}} + diff --git a/content/ko/docs/contribute/new-content/open-a-pr.md b/content/ko/docs/contribute/new-content/open-a-pr.md index 17ea3342c1..6f01e04135 100644 --- a/content/ko/docs/contribute/new-content/open-a-pr.md +++ b/content/ko/docs/contribute/new-content/open-a-pr.md @@ -1,14 +1,14 @@ --- title: 풀 리퀘스트 열기 slug: new-content -content_template: templates/concept +content_type: concept weight: 10 card: name: contribute weight: 40 --- -{{% capture overview %}} + {{< note >}} **코드 개발자**: 향후 쿠버네티스 릴리스의 @@ -22,9 +22,9 @@ card: 변경 사항이 많으면, [로컬 포크에서 작업하기](#fork-the-repo)를 읽고 컴퓨터에서 로컬로 변경하는 방법을 배운다. -{{% /capture %}} -{{% capture body %}} + + ## GitHub을 사용하여 변경하기 @@ -475,10 +475,11 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 느낌을 얻으려면 열린 이슈와 PR을 살펴보자. 이슈나 PR을 제출할 때 가능한 한 상세하게 템플릿의 내용을 작성한다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + - 리뷰 프로세스에 대한 자세한 내용은 [리뷰하기](/ko/docs/contribute/reviewing/revewing-prs)를 읽어본다. -{{% /capture %}} + diff --git a/content/ko/docs/contribute/new-content/overview.md b/content/ko/docs/contribute/new-content/overview.md index ca1bc10737..c17a557c6d 100644 --- a/content/ko/docs/contribute/new-content/overview.md +++ b/content/ko/docs/contribute/new-content/overview.md @@ -1,19 +1,19 @@ --- title: 새로운 콘텐츠 기여하기에 대한 개요 linktitle: 개요 -content_template: templates/concept +content_type: concept main_menu: true weight: 5 --- -{{% capture overview %}} + 이 섹션에는 새로운 콘텐츠를 기여하기 전에 알아야 할 정보가 있다. -{{% /capture %}} -{{% capture body %}} + + ## 기여하기에 대한 기본 @@ -54,5 +54,8 @@ CLA에 서명하지 않은 기여자의 풀 리퀘스트(pull request)는 자동 PR 당 하나의 언어로 풀 리퀘스트를 제한한다. 여러 언어로 동일한 코드 샘플을 동일하게 변경해야 하는 경우 각 언어마다 별도의 PR을 연다. +## 기여자를 위한 도구들 + +`kubernetes/website` 리포지터리의 [문서 기여자를 위한 도구](https://github.com/kubernetes/website/tree/master/content/en/docs/doc-contributor-tools) 디렉터리에는 기여 여정이 좀 더 순조롭게 진행되도록 도와주는 도구들이 포함되어 있다. + -{{% /capture %}} diff --git a/content/ko/docs/contribute/participating.md b/content/ko/docs/contribute/participating.md index 401c91844e..8f9cb0b5f6 100644 --- a/content/ko/docs/contribute/participating.md +++ b/content/ko/docs/contribute/participating.md @@ -1,13 +1,13 @@ --- title: SIG Docs에 참여하기 -content_template: templates/concept +content_type: concept weight: 60 card: name: contribute weight: 60 --- -{{% capture overview %}} + SIG Docs는 쿠버네티스 프로젝트의 [분과회(special interest group)](https://github.com/kubernetes/community/blob/master/sig-list.md) @@ -30,9 +30,9 @@ SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다. 문서를 관리하는 책임을 가지는 SIG Docs에서, 이런 체계가 작동하는 특유의 방식에 대한 윤곽을 잡아보겠다. -{{% /capture %}} -{{% capture body %}} + + ## 역할과 책임 @@ -302,9 +302,10 @@ PR 소유자에게 조언하는데 활용된다. [PR Wrangler](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) 또는 [SIG Docs 의장](#sig-docs-의장)과 같은 특정 역할도 수행한다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + 쿠버네티스 문서화에 기여하는 일에 대한 보다 많은 정보는 다음 문서를 참고한다. @@ -312,5 +313,5 @@ PR 소유자에게 조언하는데 활용된다. - [컨텐츠 검토하기](/docs/contribute/review/reviewing-prs) - [문서 스타일 가이드](/docs/contribute/style/) -{{% /capture %}} + diff --git a/content/ko/docs/contribute/review/_index.md b/content/ko/docs/contribute/review/_index.md index a79fb6129f..161dcc8511 100644 --- a/content/ko/docs/contribute/review/_index.md +++ b/content/ko/docs/contribute/review/_index.md @@ -3,12 +3,12 @@ title: 변경 사항 리뷰하기 weight: 30 --- -{{% capture overview %}} + 이 섹션은 콘텐츠를 리뷰하는 방법에 대해 설명한다. -{{% /capture %}} -{{% capture body %}} -{{% /capture %}} + + + diff --git a/content/ko/docs/contribute/review/for-approvers.md b/content/ko/docs/contribute/review/for-approvers.md index 6713d5a50b..9b6c01d739 100644 --- a/content/ko/docs/contribute/review/for-approvers.md +++ b/content/ko/docs/contribute/review/for-approvers.md @@ -2,11 +2,11 @@ title: 승인자와 리뷰어의 리뷰 linktitle: 승인자와 리뷰어용 slug: for-approvers -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + SIG Docs [리뷰어](/ko/docs/contribute/participating/#리뷰어)와 [승인자](/ko/docs/contribute/participating/#승인자)는 변경 사항을 리뷰할 때 몇 가지 추가 작업을 수행한다. @@ -19,10 +19,10 @@ SIG Docs [리뷰어](/ko/docs/contribute/participating/#리뷰어)와 [승인자 로테이션 외에도, 봇은 영향을 받는 파일의 소유자를 기반으로 PR에 대한 리뷰어와 승인자를 할당한다. -{{% /capture %}} -{{% capture body %}} + + ## PR 리뷰 @@ -224,4 +224,4 @@ https://github.com/kubernetes/kubernetes 에서 ``` -{{% /capture %}} + diff --git a/content/ko/docs/contribute/review/reviewing-prs.md b/content/ko/docs/contribute/review/reviewing-prs.md index c220e9599c..b7416f505a 100644 --- a/content/ko/docs/contribute/review/reviewing-prs.md +++ b/content/ko/docs/contribute/review/reviewing-prs.md @@ -1,11 +1,11 @@ --- title: 풀 리퀘스트 리뷰 -content_template: templates/concept +content_type: concept main_menu: true weight: 10 --- -{{% capture overview %}} + 누구나 문서화에 대한 풀 리퀘스트를 리뷰할 수 있다. 쿠버네티스 website 리포지터리의 [풀 리퀘스트](https://github.com/kubernetes/website/pulls) 섹션을 방문하여 열린(open) 풀 리퀘스트를 확인한다. @@ -19,9 +19,9 @@ weight: 10 [스타일 가이드](/docs/contribute/style/style-guide/)를 읽는다. - 쿠버네티스 문서화 커뮤니티의 다양한 [역할과 책임](/docs/contribute/participating/#roles-and-responsibilities)을 이해한다. -{{% /capture %}} -{{% capture body %}} + + ## 시작하기 전에 @@ -95,4 +95,4 @@ weight: 10 오타나 공백과 같은 작은 이슈의 PR인 경우, 코멘트 앞에 `nit:` 를 추가한다. 이를 통해 문서의 저자는 이슈가 긴급하지 않다는 것을 알 수 있다. -{{% /capture %}} + diff --git a/content/ko/docs/contribute/style/write-new-topic.md b/content/ko/docs/contribute/style/write-new-topic.md index 4313b3bd2f..0c8ab86fbf 100644 --- a/content/ko/docs/contribute/style/write-new-topic.md +++ b/content/ko/docs/contribute/style/write-new-topic.md @@ -1,19 +1,20 @@ --- title: 새로운 주제의 문서 작성 -content_template: templates/task +content_type: task weight: 20 --- -{{% capture overview %}} + 이 페이지는 쿠버네티스 문서에서 새로운 주제를 생성하는 방법을 보여준다. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + [기여 시작하기](/docs/contribute/start/)에 설명된 대로 쿠버네티스 문서 저장소의 포크(fork)를 생성하자. -{{% /capture %}} -{{% capture steps %}} + + ## 페이지 타입 선택 @@ -159,9 +160,10 @@ kubectl create -f https://k8s.io/examples/pods/storage/gce-volume.yaml 이미지 파일을 `/images` 디렉토리에 넣는다. 기본 이미지 형식은 SVG 이다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [페이지 템플릿 사용](/docs/contribute/page-templates/))에 대해 알아보기. * [풀 리퀘스트 작성](/docs/contribute/new-content/open-a-pr/)에 대해 알아보기. -{{% /capture %}} + diff --git a/content/ko/docs/contribute/suggesting-improvements.md b/content/ko/docs/contribute/suggesting-improvements.md index ca2e8862ed..c7fe87ac07 100644 --- a/content/ko/docs/contribute/suggesting-improvements.md +++ b/content/ko/docs/contribute/suggesting-improvements.md @@ -1,14 +1,14 @@ --- title: 콘텐츠 개선 제안 slug: suggest-improvements -content_template: templates/concept +content_type: concept weight: 10 card: name: contribute weight: 20 --- -{{% capture overview %}} + 쿠버네티스 문서에 문제가 있거나, 새로운 내용에 대한 아이디어가 있으면, 이슈를 연다. [GitHub 계정](https://github.com/join)과 웹 브라우저만 있으면 된다. @@ -16,9 +16,9 @@ card: 쿠버네티스 기여자는 필요에 따라 이슈를 리뷰, 분류하고 태그를 지정한다. 다음으로, 여러분이나 다른 쿠버네티스 커뮤니티 멤버가 문제를 해결하기 위한 변경 사항이 있는 풀 리퀘스트를 연다. -{{% /capture %}} -{{% capture body %}} + + ## 이슈 열기 @@ -62,4 +62,4 @@ card: 존중한다. 예를 들어, "문서가 끔찍하다"는 도움이 되지 않거나 예의 바르지 않은 피드백이다. -{{% /capture %}} + diff --git a/content/ko/docs/home/_index.md b/content/ko/docs/home/_index.md index 94927fbfc1..2432f8781c 100644 --- a/content/ko/docs/home/_index.md +++ b/content/ko/docs/home/_index.md @@ -13,7 +13,7 @@ menu: title: "문서" weight: 20 post: > -

개념, 튜토리얼 및 참조 문서와 함께 쿠버네티스 사용하는 방법을 익힐 수 있다. 또한, 문서에 기여하는 것도 도움을 줄 수 있다!

+

개념, 튜토리얼 및 참조 문서와 함께 쿠버네티스 사용하는 방법을 익힐 수 있다. 또한, 문서에 기여하는 것도 도움을 줄 수 있다!

description: > 쿠버네티스는 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하기 위한 오픈소스 컨테이너 오케스트레이션 엔진이다. 오픈소스 프로젝트는 Cloud Native Computing Foundation에서 주관한다. overview: > diff --git a/content/ko/docs/home/supported-doc-versions.md b/content/ko/docs/home/supported-doc-versions.md index 69245a2f41..9bf7edfedf 100644 --- a/content/ko/docs/home/supported-doc-versions.md +++ b/content/ko/docs/home/supported-doc-versions.md @@ -1,20 +1,20 @@ --- title: 쿠버네티스 문서의 버전 지원 -content_template: templates/concept +content_type: concept card: name: about weight: 10 title: 문서의 버전 지원 --- -{{% capture overview %}} + 이 웹 사이트에는 현재 버전의 쿠버네티스와 이전 4개 버전의 쿠버네티스에 대한 문서가 포함되어 있습니다. -{{% /capture %}} -{{% capture body %}} + + ## 현재 버전 @@ -25,4 +25,4 @@ card: {{< versions-other >}} -{{% /capture %}} + diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index a9ce09b988..148abd29a3 100644 --- a/content/ko/docs/reference/_index.md +++ b/content/ko/docs/reference/_index.md @@ -3,16 +3,16 @@ title: 레퍼런스 linkTitle: "레퍼런스" main_menu: true weight: 70 -content_template: templates/concept +content_type: concept --- -{{% capture overview %}} + -쿠버네티스 문서의 본 섹션에서는 레퍼런스를 다룬다. +쿠버네티스 문서의 본 섹션에서는 레퍼런스를 다룬다. -{{% /capture %}} -{{% capture body %}} + + ## API 레퍼런스 @@ -21,8 +21,8 @@ content_template: templates/concept ## API 클라이언트 라이브러리 -프로그래밍 언어에서 쿠버네티스 API를 호출하기 위해서, -[클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 사용할 수 있다. +프로그래밍 언어에서 쿠버네티스 API를 호출하기 위해서, +[클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 사용할 수 있다. 공식적으로 지원되는 클라이언트 라이브러리는 다음과 같다. - [쿠버네티스 Go 클라이언트 라이브러리](https://github.com/kubernetes/client-go/) @@ -32,7 +32,7 @@ content_template: templates/concept ## CLI 레퍼런스 -* [kubectl](/docs/reference/kubectl/overview/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구. +* [kubectl](/ko/docs/reference/kubectl/overview/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구. * [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](http://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드. * [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구. @@ -50,4 +50,4 @@ content_template: templates/concept 쿠버네티스 기능에 대한 설계 문서의 아카이브. [쿠버네티스 아키텍처](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md)와 [쿠버네티스 디자인 개요](https://git.k8s.io/community/contributors/design-proposals)가 좋은 출발점이다. -{{% /capture %}} + diff --git a/content/ko/docs/reference/issues-security/security.md b/content/ko/docs/reference/issues-security/security.md index fd08a55a06..986af01cf1 100644 --- a/content/ko/docs/reference/issues-security/security.md +++ b/content/ko/docs/reference/issues-security/security.md @@ -1,14 +1,14 @@ --- title: 쿠버네티스 보안과 공개 정보 -content_template: templates/concept +content_type: concept weight: 20 --- -{{% capture overview %}} + 이 페이지는 쿠버네티스 보안 및 공개 정보를 설명한다. -{{% /capture %}} -{{% capture body %}} + + ## 보안 공지 보안 및 주요 API 공지에 대한 이메일을 위해 [kubernetes-security-announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce)) 그룹에 가입하세요. @@ -48,4 +48,4 @@ weight: 20 ## 공개 시기 공개 날짜는 쿠버네티스 제품 보안 위원회와 버그 제출자가 협상한다. 사용자 완화가 가능해지면 가능한 빨리 버그를 완전히 공개하는 것이 좋다. 버그 또는 픽스가 아직 완전히 이해되지 않았거나 솔루션이 제대로 테스트되지 않았거나 벤더 협력을 위해 공개를 지연시키는 것이 합리적이다. 공개 기간은 즉시(특히 이미 공개적으로 알려진 경우)부터 몇 주까지입니다. 간단한 완화 기능이 있는 취약점의 경우 보고 날짜부터 공개 날짜까지는 7일 정도 소요될 것으로 예상된다. 쿠버네티스 제품 보안 위원회는 공개 날짜를 설정할 때 최종 결정권을 갖는다. -{{% /capture %}} + diff --git a/content/ko/docs/reference/kubectl/_index.md b/content/ko/docs/reference/kubectl/_index.md new file mode 100755 index 0000000000..7b6c2d720b --- /dev/null +++ b/content/ko/docs/reference/kubectl/_index.md @@ -0,0 +1,5 @@ +--- +title: "kubectl CLI" +weight: 60 +--- + diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index 8956d72474..bcf654b0bd 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -1,20 +1,20 @@ --- title: kubectl 치트 시트 -content_template: templates/concept +content_type: concept card: name: reference weight: 30 --- -{{% capture overview %}} + -참고 항목: [Kubectl 개요](/docs/reference/kubectl/overview/)와 [JsonPath 가이드](/docs/reference/kubectl/jsonpath). +참고 항목: [Kubectl 개요](/ko/docs/reference/kubectl/overview/)와 [JsonPath 가이드](/docs/reference/kubectl/jsonpath). 이 페이지는 `kubectl` 커맨드의 개요이다. -{{% /capture %}} -{{% capture body %}} + + # kubectl - 치트 시트 @@ -203,7 +203,7 @@ kubectl diff -f ./my-manifest.yaml ```bash kubectl set image deployment/frontend www=image:v2 # "frontend" 디플로이먼트의 "www" 컨테이너 이미지를 업데이트하는 롤링 업데이트 -kubectl rollout history deployment/frontend # 현 리비전을 포함한 디플로이먼트의 이력을 체크 +kubectl rollout history deployment/frontend # 현 리비전을 포함한 디플로이먼트의 이력을 체크 kubectl rollout undo deployment/frontend # 이전 디플로이먼트로 롤백 kubectl rollout undo deployment/frontend --to-revision=2 # 특정 리비전으로 롤백 kubectl rollout status -w deployment/frontend # 완료될 때까지 "frontend" 디플로이먼트의 롤링 업데이트 상태를 감시 @@ -355,7 +355,7 @@ kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr. kubectl get pods -A -o=custom-columns='DATA:metadata.*' ``` -More examples in the kubectl [reference documentation](/docs/reference/kubectl/overview/#custom-columns). +더 많은 예제는 kubectl [참조 문서](/ko/docs/reference/kubectl/overview/#custom-columns)를 참고한다. ### Kubectl 출력 로그 상세 레벨(verbosity)과 디버깅 @@ -373,11 +373,12 @@ Kubectl 로그 상세 레벨(verbosity)은 `-v` 또는`--v` 플래그와 로그 `--v=8` | HTTP 요청 내용을 표시. `--v=9` | 내용을 잘라 내지 않고 HTTP 요청 내용을 표시. -{{% /capture %}} -{{% capture whatsnext %}} -* [kubectl 개요](/docs/reference/kubectl/overview/)에 대해 더 배워보자. +## {{% heading "whatsnext" %}} + + +* [kubectl 개요](/ko/docs/reference/kubectl/overview/)에 대해 더 배워보자. * [kubectl](/docs/reference/kubectl/kubectl/) 옵션을 참고한다. @@ -385,4 +386,4 @@ Kubectl 로그 상세 레벨(verbosity)은 `-v` 또는`--v` 플래그와 로그 * 더 많은 [kubectl 치트 시트](https://github.com/dennyzhang/cheatsheet-kubernetes-A4) 커뮤니티 확인 -{{% /capture %}} + diff --git a/content/ko/docs/reference/kubectl/overview.md b/content/ko/docs/reference/kubectl/overview.md new file mode 100644 index 0000000000..d70eb8939a --- /dev/null +++ b/content/ko/docs/reference/kubectl/overview.md @@ -0,0 +1,495 @@ +--- +title: kubectl 개요 +content_template: templates/concept +weight: 20 +card: + name: reference + weight: 20 +--- + +{{% capture overview %}} +Kubectl은 쿠버네티스 클러스터를 제어하기 위한 커맨드 라인 도구이다. `kubectl` 은 config 파일을 $HOME/.kube 에서 찾는다. KUBECONFIG 환경 변수를 설정하거나 [`--kubeconfig`](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 플래그를 설정하여 다른 [kubeconfig](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 파일을 지정할 수 있다. + +이 개요는 `kubectl` 구문을 다루고, 커맨드 동작을 설명하며, 일반적인 예제를 제공한다. 지원되는 모든 플래그 및 하위 명령을 포함한 각 명령에 대한 자세한 내용은 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 참조 문서를 참고한다. 설치 방법에 대해서는 [kubectl 설치](/ko/docs/tasks/tools/install-kubectl/)를 참고한다. + +{{% /capture %}} + +{{% capture body %}} + +## 구문 + +터미널 창에서 `kubectl` 명령을 실행하려면 다음의 구문을 사용한다. + +```shell +kubectl [command] [TYPE] [NAME] [flags] +``` + +다음은 `command`, `TYPE`, `NAME` 과 `flags` 에 대한 설명이다. + +* `command`: 하나 이상의 리소스에서 수행하려는 동작을 지정한다. 예: `create`, `get`, `describe`, `delete` + +* `TYPE`: [리소스 타입](#리소스-타입)을 지정한다. 리소스 타입은 대소문자를 구분하지 않으며 단수형, 복수형 또는 약어 형식을 지정할 수 있다. 예를 들어, 다음의 명령은 동일한 출력 결과를 생성한다. + + ```shell + kubectl get pod pod1 + kubectl get pods pod1 + kubectl get po pod1 + ``` + +* `NAME`: 리소스 이름을 지정한다. 이름은 대소문자를 구분한다. 이름을 생략하면, 모든 리소스에 대한 세부 사항이 표시된다. 예: `kubectl get pods` + + 여러 리소스에 대한 작업을 수행할 때, 타입 및 이름별로 각 리소스를 지정하거나 하나 이상의 파일을 지정할 수 있다. + + * 타입 및 이름으로 리소스를 지정하려면 다음을 참고한다. + + * 리소스가 모두 동일한 타입인 경우 리소스를 그룹화하려면 다음을 사용한다. `TYPE1 name1 name2 name<#>`
+ 예: `kubectl get pod example-pod1 example-pod2` + + * 여러 리소스 타입을 개별적으로 지정하려면 다음을 사용한다. `TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`
+ 예: `kubectl get pod/example-pod1 replicationcontroller/example-rc1` + + * 하나 이상의 파일로 리소스를 지정하려면 다음을 사용한다. `-f file1 -f file2 -f file<#>` + + * YAML이 특히 구성 파일에 대해 더 사용자 친화적이므로, [JSON 대신 YAML을 사용한다](/ko/docs/concepts/configuration/overview/#일반적인-구성-팁).
+ 예: `kubectl get pod -f ./pod.yaml` + +* `flags`: 선택적 플래그를 지정한다. 예를 들어, `-s` 또는 `--server` 플래그를 사용하여 쿠버네티스 API 서버의 주소와 포트를 지정할 수 있다.
+ +{{< caution >}} +커맨드 라인에서 지정하는 플래그는 기본값과 해당 환경 변수를 무시한다. +{{< /caution >}} + +도움이 필요하다면, 터미널 창에서 `kubectl help` 를 실행한다. + +## 명령어 + +다음 표에는 모든 `kubectl` 작업에 대한 간단한 설명과 일반적인 구문이 포함되어 있다. + +명령어 | 구문 | 설명 +-------------------- | -------------------- | -------------------- +`alpha` | `kubectl alpha SUBCOMMAND [flags]` | 쿠버네티스 클러스터에서 기본적으로 활성화되어 있지 않은 알파 기능의 사용할 수 있는 명령을 나열한다. +`annotate` | kubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | 하나 이상의 리소스 어노테이션을 추가하거나 업데이트한다. +`api-resources` | `kubectl api-resources [flags]` | 사용 가능한 API 리소스를 나열한다. +`api-versions` | `kubectl api-versions [flags]` | 사용 가능한 API 버전을 나열한다. +`apply` | `kubectl apply -f FILENAME [flags]`| 파일이나 표준입력(stdin)으로부터 리소스에 구성 변경 사항을 적용한다. +`attach` | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | 실행 중인 컨테이너에 연결하여 출력 스트림을 보거나 표준입력을 통해 컨테이너와 상호 작용한다. +`auth` | `kubectl auth [flags] [options]` | 승인을 검사한다. +`autoscale` | kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags] | 레플리케이션 컨트롤러에서 관리하는 파드 집합을 자동으로 조정한다. +`certificate` | `kubectl certificate SUBCOMMAND [options]` | 인증서 리소스를 수정한다. +`cluster-info` | `kubectl cluster-info [flags]` | 클러스터의 마스터와 서비스에 대한 엔드포인트 정보를 표시한다. +`completion` | `kubectl completion SHELL [options]` | 지정된 셸(bash 또는 zsh)에 대한 셸 완성 코드를 출력한다. +`config` | `kubectl config SUBCOMMAND [flags]` | kubeconfig 파일을 수정한다. 세부 사항은 개별 하위 명령을 참고한다. +`convert` | `kubectl convert -f FILENAME [options]` | 다른 API 버전 간에 구성 파일을 변환한다. YAML 및 JSON 형식이 모두 허용된다. +`cordon` | `kubectl cordon NODE [options]` | 노드를 스케줄 불가능(unschedulable)으로 표시한다. +`cp` | `kubectl cp [options]` | 컨테이너에서 그리고 컨테이너로 파일 및 디렉터리를 복사한다. +`create` | `kubectl create -f FILENAME [flags]` | 파일이나 표준입력에서 하나 이상의 리소스를 생성한다. +`delete` | kubectl delete (-f FILENAME | TYPE [NAME | /NAME | -l label | --all]) [flags] | 파일, 표준입력 또는 레이블 셀렉터, 이름, 리소스 셀렉터 또는 리소스를 지정하여 리소스를 삭제한다. +`describe` | kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | -l label]) [flags] | 하나 이상의 리소스의 자세한 상태를 표시한다. +`diff` | `kubectl diff -f FILENAME [flags]`| 라이브 구성에 대해 파일이나 표준입력의 차이점을 출력한다. +`drain` | `kubectl drain NODE [options]` | 유지 보수를 준비 중인 노드를 드레인한다. +`edit` | kubectl edit (-f FILENAME | TYPE NAME | TYPE/NAME) [flags] | 기본 편집기를 사용하여 서버에서 하나 이상의 리소스 정의를 편집하고 업데이트한다. +`exec` | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | 파드의 컨테이너에 대해 명령을 실행한다. +`explain` | `kubectl explain [--recursive=false] [flags]` | 파드, 노드, 서비스 등의 다양한 리소스에 대한 문서를 출력한다. +`expose` | kubectl expose (-f FILENAME | TYPE NAME | TYPE/NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags] | 레플리케이션 컨트롤러, 서비스 또는 파드를 새로운 쿠버네티스 서비스로 노출한다. +`get` | kubectl get (-f FILENAME | TYPE [NAME | /NAME | -l label]) [--watch] [--sort-by=FIELD] [[-o | --output]=OUTPUT_FORMAT] [flags] | 하나 이상의 리소스를 나열한다. +`kustomize` | `kubectl kustomize [flags] [options]` | kustomization.yaml 파일의 지시 사항에서 생성된 API 리소스 집합을 나열한다. 인수는 파일을 포함하는 디렉터리의 경로이거나, 리포지터리 루트와 관련하여 경로 접미사가 동일한 git 리포지터리 URL이어야 한다. +`label` | kubectl label (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | 하나 이상의 리소스 레이블을 추가하거나 업데이트한다. +`logs` | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | 파드의 컨테이너에 대한 로그를 출력한다. +`options` | `kubectl options` | 모든 명령에 적용되는 전역 커맨드 라인 옵션을 나열한다. +`patch` | kubectl patch (-f FILENAME | TYPE NAME | TYPE/NAME) --patch PATCH [flags] | 전략적 병합 패치 프로세스를 사용하여 리소스의 하나 이상의 필드를 업데이트한다. +`plugin` | `kubectl plugin [flags] [options]` | 플러그인과 상호 작용하기 위한 유틸리티를 제공한다. +`port-forward` | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | 하나 이상의 로컬 포트를 파드로 전달한다. +`proxy` | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | 쿠버네티스 API 서버에 프록시를 실행한다. +`replace` | `kubectl replace -f FILENAME` | 파일 또는 표준입력에서 리소스를 교체한다. +`rollout` | `kubectl rollout SUBCOMMAND [options]` | 리소스의 롤아웃을 관리한다. 유효한 리소스 타입에는 디플로이먼트(deployment), 데몬셋(daemonset)과 스테이트풀셋(statefulset)이 포함된다. +`run` | kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client|none] [--overrides=inline-json] [flags] | 클러스터에서 지정된 이미지를 실행한다. +`scale` | kubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags] | 지정된 레플리케이션 컨트롤러의 크기를 업데이트한다. +`set` | `kubectl set SUBCOMMAND [options]` | 애플리케이션 리소스를 구성한다. +`taint` | `kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]` | 하나 이상의 노드에서 테인트(taint)를 업데이트한다. +`top` | `kubectl top [flags] [options]` | 리소스(CPU/메모리/스토리지) 사용량을 표시한다. +`uncordon` | `kubectl uncordon NODE [options]` | 노드를 스케줄 가능(schedulable)으로 표시한다. +`version` | `kubectl version [--client] [flags]` | 클라이언트와 서버에서 실행 중인 쿠버네티스 버전을 표시한다. +`wait` | kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options] | 실험(experimental) 기능: 하나 이상의 리소스에서 특정 조건을 기다린다. + +기억하기: 명령 동작에 대한 자세한 내용은 [kubectl](/docs/user-guide/kubectl/) 참조 문서를 참고한다. + +## 리소스 타입 + +다음 표에는 지원되는 모든 리소스 타입과 해당 약어가 나열되어 있다. + +(이 출력은 `kubectl api-resources` 에서 확인할 수 있으며, 쿠버네티스 1.13.3 부터 일치한다.) + +| 리소스 이름 | 짧은 이름 | API 그룹 | 네임스페이스 | 리소스 종류 | +|---|---|---|---|---| +| `bindings` | | | true | Binding| +| `componentstatuses` | `cs` | | false | ComponentStatus | +| `configmaps` | `cm` | | true | ConfigMap | +| `endpoints` | `ep` | | true | Endpoints | +| `limitranges` | `limits` | | true | LimitRange | +| `namespaces` | `ns` | | false | Namespace | +| `nodes` | `no` | | false | Node | +| `persistentvolumeclaims` | `pvc` | | true | PersistentVolumeClaim | +| `persistentvolumes` | `pv` | | false | PersistentVolume | +| `pods` | `po` | | true | Pod | +| `podtemplates` | | | true | PodTemplate | +| `replicationcontrollers` | `rc` | | true| ReplicationController | +| `resourcequotas` | `quota` | | true | ResourceQuota | +| `secrets` | | | true | Secret | +| `serviceaccounts` | `sa` | | true | ServiceAccount | +| `services` | `svc` | | true | Service | +| `mutatingwebhookconfigurations` | | admissionregistration.k8s.io | false | MutatingWebhookConfiguration | +| `validatingwebhookconfigurations` | | admissionregistration.k8s.io | false | ValidatingWebhookConfiguration | +| `customresourcedefinitions` | `crd`, `crds` | apiextensions.k8s.io | false | CustomResourceDefinition | +| `apiservices` | | apiregistration.k8s.io | false | APIService | +| `controllerrevisions` | | apps | true | ControllerRevision | +| `daemonsets` | `ds` | apps | true | DaemonSet | +| `deployments` | `deploy` | apps | true | Deployment | +| `replicasets` | `rs` | apps | true | ReplicaSet | +| `statefulsets` | `sts` | apps | true | StatefulSet | +| `tokenreviews` | | authentication.k8s.io | false | TokenReview | +| `localsubjectaccessreviews` | | authorization.k8s.io | true | LocalSubjectAccessReview | +| `selfsubjectaccessreviews` | | authorization.k8s.io | false | SelfSubjectAccessReview | +| `selfsubjectrulesreviews` | | authorization.k8s.io | false | SelfSubjectRulesReview | +| `subjectaccessreviews` | | authorization.k8s.io | false | SubjectAccessReview | +| `horizontalpodautoscalers` | `hpa` | autoscaling | true | HorizontalPodAutoscaler | +| `cronjobs` | `cj` | batch | true | CronJob | +| `jobs` | | batch | true | Job | +| `certificatesigningrequests` | `csr` | certificates.k8s.io | false | CertificateSigningRequest | +| `leases` | | coordination.k8s.io | true | Lease | +| `events` | `ev` | events.k8s.io | true | Event | +| `ingresses` | `ing` | extensions | true | Ingress | +| `networkpolicies` | `netpol` | networking.k8s.io | true | NetworkPolicy | +| `poddisruptionbudgets` | `pdb` | policy | true | PodDisruptionBudget | +| `podsecuritypolicies` | `psp` | policy | false | PodSecurityPolicy | +| `clusterrolebindings` | | rbac.authorization.k8s.io | false | ClusterRoleBinding | +| `clusterroles` | | rbac.authorization.k8s.io | false | ClusterRole | +| `rolebindings` | | rbac.authorization.k8s.io | true | RoleBinding | +| `roles` | | rbac.authorization.k8s.io | true | Role | +| `priorityclasses` | `pc` | scheduling.k8s.io | false | PriorityClass | +| `csidrivers` | | storage.k8s.io | false | CSIDriver | +| `csinodes` | | storage.k8s.io | false | CSINode | +| `storageclasses` | `sc` | storage.k8s.io | false | StorageClass | +| `volumeattachments` | | storage.k8s.io | false | VolumeAttachment | + +## 출력 옵션 + +특정 명령의 출력을 서식화하거나 정렬하는 방법에 대한 정보는 다음 섹션을 참고한다. 다양한 출력 옵션을 지원하는 명령에 대한 자세한 내용은 [kubectl](/docs/user-guide/kubectl/) 참조 문서를 참고한다. + +### 출력 서식화 + +모든 `kubectl` 명령의 기본 출력 형식은 사람이 읽을 수 있는 일반 텍스트 형식이다. 특정 형식으로 터미널 창에 세부 정보를 출력하려면, 지원되는 `kubectl` 명령에 `-o` 또는 `--output` 플래그를 추가할 수 있다. + +#### 구문 + +```shell +kubectl [command] [TYPE] [NAME] -o +``` + +`kubectl` 명령에 따라, 다음과 같은 출력 형식이 지원된다. + +출력 형식 | 설명 +--------------| ----------- +`-o custom-columns=` | 쉼표로 구분된 [사용자 정의 열](#custom-columns) 목록을 사용하여 테이블을 출력한다. +`-o custom-columns-file=` | `` 파일에서 [사용자 정의 열](#custom-columns) 템플릿을 사용하여 테이블을 출력한다. +`-o json` | JSON 형식의 API 오브젝트를 출력한다. +`-o jsonpath=