diff --git a/404.md b/404.md index bf053c1e3b..3d32e81bcf 100644 --- a/404.md +++ b/404.md @@ -2,67 +2,9 @@ layout: docwithnav title: 404 Error! permalink: /404.html +no_canonical: true --- - + + Sorry, this page was not found. :( diff --git a/README.md b/README.md index a468c1f947..381cd46567 100644 --- a/README.md +++ b/README.md @@ -4,20 +4,33 @@ Welcome! We are very pleased you want to contribute to the documentation and/or You can click the "Fork" button in the upper-right area of the screen to create a copy of our site on your GitHub account called a "fork." Make any changes you want in your fork, and when you are ready to send those changes to us, go to the index page for your fork and click "New Pull Request" to let us know about it. -## Staging the site on GitHub Pages +For more information about contributing to the Kubernetes documentation, see: -If you want to see your changes staged without having to install anything locally, remove the CNAME file in this directory and -change the name of the fork to be: +* [Creating a Documentation Pull Request](http://kubernetes.io/docs/contribute/create-pull-request/) +* [Writing a New Topic](http://kubernetes.io/docs/contribute/write-new-topic/) +* [Staging Your Documentation Changes](http://kubernetes.io/docs/contribute/stage-documentation-changes/) +* [Using Page Templates](http://kubernetes.io/docs/contribute/page-templates/) - YOUR_GITHUB_USERNAME.github.io +## Automatic Staging for Pull Requests -Then make your changes. +When you create a pull request (either against master or the upcoming release), your changes are staged in a custom subdomain on Netlify so that you can see your changes in rendered form before the PR is merged. You can use this to verify that everything is correct before the PR gets merged. To view your changes: -When you visit [http://YOUR_GITHUB_USERNAME.github.io](http://YOUR_GITHUB_USERNAME.github.io) you should see a special-to-you version of the site that contains the changes you just made. +- Scroll down to the PR's list of Automated Checks +- Click "Show All Checks" +- Look for "deploy/netlify"; you'll see "Deploy Preview Ready!" if staging was successful +- Click "Details" to bring up the staged site and navigate to your changes + +## Branch structure and staging + +The current version of the website is served out of the `master` branch. To make changes to the live docs, such as bug fixes, broken links, typos, etc, **target your pull request to the master branch** + +The `release-1.x` branch stores changes for **upcoming releases of Kubernetes**. For example, the `release-1.5` branch has changes for the 1.5 release. These changes target branches (and *not* master) to avoid publishing documentation updates prior to the release for which they're relevant. If you have a change for an upcoming release of Kubernetes, **target your pull request to the appropriate release branch**. + +The staging site for the next upcoming Kubernetes release is here: [http://kubernetes-io-vnext-staging.netlify.com/](http://kubernetes-io-vnext-staging.netlify.com/). The staging site reflects the current state of what's been merged in the release branch, or in other words, what the docs will look like for the next upcoming release. It's automatically updated as new PRs get merged. ## Staging the site locally (using Docker) -Don't like installing stuff? Download and run a local staging server with a single `docker run` command. +Don't like installing stuff? Download and run a local staging server with a single `docker run` command. git clone https://github.com/kubernetes/kubernetes.github.io.git cd kubernetes.github.io @@ -41,7 +54,7 @@ Install Ruby 2.2 or higher. If you're on Linux, run these commands: apt-get install ruby2.2 apt-get install ruby2.2-dev -* If you're on a Mac, follow [these instructions](https://gorails.com/setup/osx/). +* If you're on a Mac, follow [these instructions](https://gorails.com/setup/osx/). * If you're on a Windows machine you can use the [Ruby Installer](http://rubyinstaller.org/downloads/). During the installation make sure to check the option for *Add Ruby executables to your PATH*. The remainder of the steps should work the same across operating systems. @@ -64,7 +77,6 @@ Make any changes you want. Then, to see your changes locally: Your copy of the site will then be viewable at: [http://localhost:4000](http://localhost:4000) (or wherever Jekyll tells you). - ## GitHub help If you're a bit rusty with git/GitHub, you might want to read @@ -135,23 +147,6 @@ That, of course, will send users to: (Or whatever Kubernetes release that docs branch is associated with.) -## Branch structure - -The current version of the website is served out of the `master` branch. - -All versions of the site that relate to past and future versions will be named after their Kubernetes release number. For example, [the old branch for the 1.1 docs is called `release-1.1`](https://github.com/kubernetes/kubernetes.github.io/tree/release-1.1). - -Changes in the "docsv2" branch (where we are testing a revamp of the docs) are automatically staged here: -http://k8sdocs.github.io/docs/tutorials/ - -Changes in the "release-1.1" branch (for k8s v1.1 docs) are automatically staged here: -http://kubernetes-v1-1.github.io/ - -Changes in the "release-1.3" branch (for k8s v1.3 docs) are automatically staged here: -http://kubernetes-v1-3.github.io/ - -Editing of these branches will kick off a build using Travis CI that auto-updates these URLs; you can monitor the build progress at [https://travis-ci.org/kubernetes/kubernetes.github.io](https://travis-ci.org/kubernetes/kubernetes.github.io). - ## Config yaml guidelines Guidelines for config yamls that are included in the site docs. These diff --git a/_config.yml b/_config.yml index 5094499bfe..5b7f442fd8 100644 --- a/_config.yml +++ b/_config.yml @@ -18,7 +18,7 @@ defaults: values: version: "v1.3" githubbranch: "master" - docsbranch: "release-1.3" + docsbranch: "master" - scope: path: "docs" @@ -27,3 +27,6 @@ defaults: showedit: true permalink: pretty + +gems: + - jekyll-redirect-from diff --git a/_data/globals.yml b/_data/globals.yml index c83dae26dd..73978ea750 100644 --- a/_data/globals.yml +++ b/_data/globals.yml @@ -4,5 +4,6 @@ tocs: - tasks - concepts - reference +- tools - samples - support diff --git a/_data/guides.yml b/_data/guides.yml index 7c41285d0e..40d47b08d6 100644 --- a/_data/guides.yml +++ b/_data/guides.yml @@ -163,10 +163,10 @@ toc: path: /docs/getting-started-guides/gce/ - title: Running Kubernetes on AWS EC2 path: /docs/getting-started-guides/aws/ + - title: Running Kubernetes on Azure + path: /docs/getting-started-guides/azure/ - title: Running Kubernetes on Azure (Weave-based) path: /docs/getting-started-guides/coreos/azure/ - - title: Running Kubernetes on Azure (Flannel-based) - path: /docs/getting-started-guides/azure/ - title: Running Kubernetes on CenturyLink Cloud path: /docs/getting-started-guides/clc/ - title: Running Kubernetes on IBM SoftLayer @@ -252,6 +252,8 @@ toc: path: /docs/admin/ - title: Cluster Management Guide path: /docs/admin/cluster-management/ + - title: kubeadm reference + path: /docs/admin/kubeadm/ - title: Installing Addons path: /docs/admin/addons/ - title: Sharing a Cluster with Namespaces diff --git a/_data/reference.yml b/_data/reference.yml index 3cdd91de6e..5d4fe17f7b 100644 --- a/_data/reference.yml +++ b/_data/reference.yml @@ -63,7 +63,7 @@ toc: - title: kubectl Commands section: - title: kubectl - path: /docs/user-guide/kubectl/kubectl/ + path: /docs/user-guide/kubectl/ - title: kubectl annotate path: /docs/user-guide/kubectl/kubectl_annotate/ - title: kubectl api-versions @@ -230,6 +230,8 @@ toc: path: /docs/user-guide/services/ - title: Service Accounts path: /docs/user-guide/service-accounts/ + - title: Third Party Resources + path: /docs/user-guide/thirdpartyresources/ - title: Volumes path: /docs/user-guide/volumes/ diff --git a/_data/support.yml b/_data/support.yml index d287f0ecaa..e280c827d7 100644 --- a/_data/support.yml +++ b/_data/support.yml @@ -6,6 +6,12 @@ toc: - title: Contributing to the Kubernetes Docs section: + - title: Creating a Documentation Pull Request + path: /docs/contribute/create-pull-request/ + - title: Writing a New Topic + path: /docs/contribute/write-new-topic/ + - title: Staging Your Documentation Changes + path: /docs/contribute/stage-documentation-changes/ - title: Using Page Templates path: /docs/contribute/page-templates/ diff --git a/_data/tasks.yml b/_data/tasks.yml index 1019671e66..90c1f3b8b2 100644 --- a/_data/tasks.yml +++ b/_data/tasks.yml @@ -2,6 +2,12 @@ bigheader: "Tasks" toc: - title: Tasks path: /docs/tasks/ +- title: Configuring Pods and Containers + section: + - title: Defining Environment Variables for a Container + path: /docs/tasks/configure-pod-container/define-environment-variable-container/ + - title: Defining a Command and Arguments for a Container + path: /docs/tasks/configure-pod-container/define-command-argument-container/ - title: Accessing Applications in a Cluster section: - title: Using Port Forwarding to Access Applications in a Cluster @@ -10,4 +16,8 @@ toc: section: - title: Using an HTTP Proxy to Access the Kubernetes API path: /docs/tasks/access-kubernetes-api/http-proxy-access-api/ +- title: Administering a Cluster + section: + - title: Assigning Pods to Nodes + path: /docs/tasks/administer-cluster/assign-pods-nodes/ diff --git a/_data/tools.yml b/_data/tools.yml new file mode 100644 index 0000000000..8993e091bb --- /dev/null +++ b/_data/tools.yml @@ -0,0 +1,4 @@ +bigheader: "Tools" +toc: +- title: Tools + path: /docs/tools/ diff --git a/_data/tutorials.yml b/_data/tutorials.yml index b49283a702..01440b09d7 100644 --- a/_data/tutorials.yml +++ b/_data/tutorials.yml @@ -2,59 +2,51 @@ bigheader: "Tutorials" toc: - title: Tutorials path: /docs/tutorials/ -- title: Getting Started +- title: Kubernetes Basics section: + - title: Overview + path: /docs/tutorials/kubernetes-basics/ - title: 1. Create a Cluster section: - - title: Creating a Cluster - path: /docs/tutorials/getting-started/create-cluster/ - title: Using Minikube to Create a Cluster - path: /docs/tutorials/getting-started/cluster-intro/ + path: /docs/tutorials/kubernetes-basics/cluster-intro/ - title: Interactive Tutorial - Creating a Cluster - path: /docs/tutorials/getting-started/cluster-interactive/ + path: /docs/tutorials/kubernetes-basics/cluster-interactive/ - title: 2. Deploy an App section: - - title: Deploying an App - path: /docs/tutorials/getting-started/deploy-app/ - title: Using kubectl to Create a Deployment - path: /docs/tutorials/getting-started/deploy-intro/ + path: /docs/tutorials/kubernetes-basics/deploy-intro/ - title: Interactive Tutorial - Deploying an App - path: /docs/tutorials/getting-started/deploy-interactive/ + path: /docs/tutorials/kubernetes-basics/deploy-interactive/ - title: 3. Explore Your App section: - - title: Exploring Your App - path: /docs/tutorials/getting-started/explore-app/ - title: Viewing Pods and Nodes - path: /docs/tutorials/getting-started/explore-intro/ + path: /docs/tutorials/kubernetes-basics/explore-intro/ - title: Interactive Tutorial - Exploring Your App - path: /docs/tutorials/getting-started/explore-interactive/ + path: /docs/tutorials/kubernetes-basics/explore-interactive/ - title: 4. Expose Your App Publicly section: - - title: Exposing Your App Publicly - path: /docs/tutorials/getting-started/expose-app/ - title: Using a Service to Expose Your App - path: /docs/tutorials/getting-started/expose-intro/ + path: /docs/tutorials/kubernetes-basics/expose-intro/ - title: Interactive Tutorial - Exposing Your App - path: /docs/tutorials/getting-started/expose-interactive/ + path: /docs/tutorials/kubernetes-basics/expose-interactive/ - title: 5. Scale Your App section: - - title: Scaling Your App - path: /docs/tutorials/getting-started/scale-app/ - title: Running Multiple Instances of Your App - path: /docs/tutorials/getting-started/scale-intro/ + path: /docs/tutorials/kubernetes-basics/scale-intro/ - title: Interactive Tutorial - Scaling Your App - path: /docs/tutorials/getting-started/scale-interactive/ + path: /docs/tutorials/kubernetes-basics/scale-interactive/ - title: 6. Update Your App section: - - title: Updating Your App - path: /docs/tutorials/getting-started/update-app/ - title: Performing a Rolling Update - path: /docs/tutorials/getting-started/update-intro/ + path: /docs/tutorials/kubernetes-basics/update-intro/ - title: Interactive Tutorial - Updating Your App - path: /docs/tutorials/getting-started/update-interactive/ + path: /docs/tutorials/kubernetes-basics/update-interactive/ - title: Stateless Applications section: - title: Running a Stateless Application Using a Deployment path: /docs/tutorials/stateless-application/run-stateless-application-deployment/ - - title: Exposing an External IP Address Using a Service + - title: Using a Service to Access an Application in a Cluster path: /docs/tutorials/stateless-application/expose-external-ip-address-service/ + - title: Exposing an External IP Address to Access an Application in a Cluster + path: /docs/tutorials/stateless-application/expose-external-ip-address/ diff --git a/_includes/case-study-styles.html b/_includes/case-study-styles.html index 7914ef76ac..48058bd27b 100644 --- a/_includes/case-study-styles.html +++ b/_includes/case-study-styles.html @@ -3,40 +3,40 @@ margin-top: 1em !important; } - #caseStudies p { + .gridPage p { color: rgb(26,26,26) !important; margin-left: 0 !important; padding-left: 0 !important; font-weight: 300 !important; } - #caseStudies #mainContent { + .gridPage #mainContent { padding: 0; } - #caseStudies #mainContent .content { + .gridPage #mainContent .content { padding-top: 0; } - #caseStudies main { + .gridPage main { max-width: 1100px !important; } - #caseStudies .content { + .gridPage .content { position: relative; margin: 0 auto 50px; max-width: 90%; } - #caseStudies .content p { + .gridPage .content p { line-height: 24px !important; } - #caseStudies .content h3 { + .gridPage .content h3 { padding: 0 !important; } - #caseStudies #hero h5 { + .gridPage #hero h5 { padding-left: 20px; margin: 0; } @@ -67,7 +67,7 @@ left: 0; } - #caseStudies #mainContent .content .case-study p { + .gridPage #mainContent .content .case-study p { font-family: "Roboto", sans-serif; font-size: 16px; padding: 0; @@ -77,13 +77,13 @@ font-style: italic; } - #caseStudies #video { + .gridPage #video { background: #f9f9f9; height: auto; /*height: 340px;*/ } - #caseStudies #video main { + .gridPage #video main { position: relative; max-width: 900px !important; height: 100%; @@ -93,19 +93,19 @@ padding: 50px 20px; } - #caseStudies #video main > div { + .gridPage #video main > div { width: 50%; } - #caseStudies #video main #zulilyLogo { + .gridPage #video main #zulilyLogo { width: 100px; } - #caseStudies #video main img { + .gridPage #video main img { max-width: 100%; } - #caseStudies #video h3 { + .gridPage #video h3 { font-size: 32px; font-weight: 300; line-height: 38px; @@ -113,57 +113,57 @@ margin: 0 0 1em 0; } - #caseStudies #video p { + .gridPage #video p { margin: 0; } - #caseStudies #video p.attrib { + .gridPage #video p.attrib { margin-bottom: 20px; } - #caseStudies #video button > h6 { + .gridPage #video button > h6 { font-size: 18px; font-weight: 500; margin: 1em 0; color: #326de6; } - #caseStudies #users { + .gridPage #users { padding: 50px; } - #caseStudies #users main { + .gridPage #users main { max-width: 1150px !important; } - #caseStudies #users main h3 { + .gridPage #users main h3 { padding-left: 20px; margin-bottom: 20px; } - #caseStudies #usersGrid { + .gridPage #usersGrid { position: relative; display: flex; flex-wrap: wrap; justify-content: center; } - #caseStudies #usersGrid a { + .gridPage #usersGrid a { display: inline-block; margin: 5px; } - #caseStudies #usersGrid a img { + .gridPage #usersGrid a img { box-shadow: 1px 1px 2px transparent; transition: box-shadow 0.25s; } - #caseStudies #usersGrid a img:hover { + .gridPage #usersGrid a img:hover { box-shadow: 1px 1px 2px #cccccc; } - #caseStudies #usersGrid a:last-child img, - #caseStudies #usersGrid a:last-child img:hover { + .gridPage #usersGrid a:last-child img, + .gridPage #usersGrid a:last-child img:hover { box-shadow: 1px 1px 2px transparent; } @@ -173,12 +173,12 @@ box-shadow: 1px 2px 2px #dddddd; } - #caseStudies .feature { + .gridPage .feature { position: relative; padding: 20px 0 20px 242px; } - #caseStudies .feature img { + .gridPage .feature img { position: absolute; top: 20px; left: 0; @@ -225,7 +225,7 @@ margin-bottom: 0.5em; } - #caseStudies .feature p.quote { + .gridPage .feature p.quote { font-size: 20px; line-height: 28px !important; } @@ -250,20 +250,20 @@ } @media screen and (max-width: 900px){ - #caseStudies #video main { + .gridPage #video main { flex-direction: column; align-items: center; } - #caseStudies #video main > div { + .gridPage #video main > div { width: 400px; } - #caseStudies #video main > div + div { + .gridPage #video main > div + div { margin-top: 30px; } - #caseStudies #video h3 { + .gridPage #video h3 { max-width: 100%; } } @@ -282,12 +282,12 @@ transform: translateX(-50%); } - #caseStudies .feature { + .gridPage .feature { margin-top: 50px; padding: 180px 0 0; } - #caseStudies .feature img { + .gridPage .feature img { top: 0; left: 50%; transform: translateX(-50%); @@ -295,12 +295,12 @@ } @media screen and (max-width: 480px){ - #caseStudies #hero { + .gridPage #hero { padding-right: 20px; padding-left: 20px; } - #caseStudies #video main > div { + .gridPage #video main > div { width: 80%; min-width: 280px; } diff --git a/_includes/footer.html b/_includes/footer.html index f98dde06b5..15dacb72e0 100644 --- a/_includes/footer.html +++ b/_includes/footer.html @@ -4,6 +4,7 @@ Get Started Documentation Blog + Partners Community Case Studies diff --git a/_includes/head-header.html b/_includes/head-header.html index 12de81d975..0405f3699c 100644 --- a/_includes/head-header.html +++ b/_includes/head-header.html @@ -2,7 +2,7 @@ - + {% if !page.no_canonical %}{% endif %} diff --git a/_includes/partner-script.js b/_includes/partner-script.js new file mode 100644 index 0000000000..79cbf6d513 --- /dev/null +++ b/_includes/partner-script.js @@ -0,0 +1,208 @@ +;(function () { + var partners = [ + { + type: 0, + name: 'CoreOS', + logo: 'core_os', + link: 'https://tectonic.com/', + blurb: 'Tectonic is the enterprise-ready Kubernetes product, by CoreOS. It adds key features to allow you to manage, update, and control clusters in production.' + }, + { + type: 0, + name: 'Deis', + logo: 'deis', + link: 'https://deis.com', + blurb: 'Deis the creators of Helm, Workflow, and Steward, helps developers and operators build, deploy, manage and scale their applications on top of Kubernetes.' + }, + { + type: 0, + name: 'Sysdig Cloud', + logo: 'sys_dig', + link: 'https://sysdig.com/blog/monitoring-kubernetes-with-sysdig-cloud/', + blurb: 'Container native monitoring with deep support for Kubernetes.' + }, + { + type: 0, + name: 'Puppet', + logo: 'puppet', + link: 'https://puppet.com/blog/managing-kubernetes-configuration-puppet', + blurb: 'The Puppet module for Kubernetes makes it easy to manage Pods, Replication Controllers, Services and more in Kubernetes, and to build domain-specific interfaces to one\'s Kubernetes configuration.' + }, + { + type: 0, + name: 'Citrix', + logo: 'citrix', + link: 'http://wercker.com/workflows/partners/kubernetes/', + blurb: 'Netscaler CPX gives app developers all the features they need to load balance their microservices and containerized apps with Kubernetes.' + }, + { + type: 0, + name: 'Wercker', + logo: 'wercker', + link: 'http://wercker.com/workflows/partners/kubernetes/', + blurb: 'Wercker automates your build, test and deploy pipelines for launching containers and triggering rolling updates on your Kubernetes cluster. ' + }, + { + type: 0, + name: 'Rancher', + logo: 'rancher', + link: 'http://rancher.com/kubernetes/', + blurb: 'Rancher is an open-source, production-ready container management platform that makes it easy to deploy and leverage Kubernetes in the enterprise.' + }, + { + type: 0, + name: 'Red Hat', + logo: 'redhat', + link: 'https://www.openshift.com/', + blurb: 'Leverage an enterprise Kubernetes platform to orchestrate complex, multi-container apps.' + }, + { + type: 0, + name: 'Intel', + logo: 'intel', + link: 'https://tectonic.com/press/intel-coreos-collaborate-on-openstack-with-kubernetes.html', + blurb: 'Powering the GIFEE (Google’s Infrastructure for Everyone Else), to run OpenStack deployments on Kubernetes.' + }, + { + type: 0, + name: 'ElasticKube', + logo: 'elastickube', + link: 'https://www.ctl.io/elastickube-kubernetes/', + blurb: 'Self-service container management for Kubernetes.' + }, + { + type: 0, + name: 'Platform9', + logo: 'platform9', + link: 'https://platform9.com/products/kubernetes/', + blurb: 'Platform9 is the open source-as-a-service company that takes all of the goodness of Kubernetes and delivers it as a managed service.' + }, + { + type: 0, + name: 'Datadog', + logo: 'datadog', + link: 'http://docs.datadoghq.com/integrations/kubernetes/', + blurb: 'Full-stack observability for dynamic infrastructure & applications. Includes precision alerting, analytics and deep Kubernetes integrations. ' + }, + { + type: 0, + name: 'AppFormix', + logo: 'appformix', + link: 'http://www.appformix.com/solutions/appformix-for-kubernetes/', + blurb: 'AppFormix is a cloud infrastructure performance optimization service helping enterprise operators streamline their cloud operations on any Kubernetes cloud. ' + }, + { + type: 0, + name: 'Crunchy', + logo: 'crunchy', + link: 'http://info.crunchydata.com/blog/advanced-crunchy-containers-for-postgresql', + blurb: 'Crunchy PostgreSQL Container Suite is a set of containers for managing PostgreSQL with DBA microservices leveraging Kubernetes and Helm.' + }, + { + type: 0, + name: 'Aqua', + logo: 'aqua', + link: 'http://blog.aquasec.com/security-best-practices-for-kubernetes-deployment', + blurb: 'Deep, automated security for your containers running on Kubernetes.' + }, + { + type: 0, + name: 'Canonical', + logo: 'canonical', + link: 'https://jujucharms.com/canonical-kubernetes/', + blurb: 'The Canonical Distribution of Kubernetes enables you to operate Kubernetes clusters on demand on any major public cloud and private infrastructure.' + }, + { + type: 0, + name: 'Distelli', + logo: 'distelli', + link: 'https://www.distelli.com/', + blurb: 'Pipelines from your source repositories to your Kubernetes Clusters on any cloud.' + }, + { + type: 0, + name: 'Nuage networks', + logo: 'nuagenetworks', + link: 'https://github.com/nuagenetworks/nuage-kubernetes', + blurb: 'The Nuage SDN platform provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring.' + }, + { + type: 1, + name: 'Apprenda', + logo: 'apprenda', + link: 'https://apprenda.com/kubernetes-support/', + blurb: 'Apprenda offers flexible and wide range of support plans for pure play Kubernetes on your choice of infrastructure, cloud provider and operating system.' + }, + { + type: 1, + name: 'Reactive Ops', + logo: 'reactive_ops', + link: 'https://www.reactiveops.com/kubernetes/', + blurb: 'ReactiveOps has written automation on best practices for infrastructure as code on GCP & AWS using Kubernetes, helping you build and maintain a world-class infrastructure at a fraction of the price of an internal hire.' + }, + { + type: 1, + name: 'Livewyer', + logo: 'livewyer', + link: 'https://livewyer.io/services/kubernetes-experts/', + blurb: 'Kubernetes experts that on-board applications and empower IT teams to get the most out of containerised technology.' + }, + { + type: 1, + name: 'Deis', + logo: 'deis', + link: 'https://deis.com/services/', + blurb: 'Deis provides professional services and 24x7 operational support for any Kubernetes cluster managed by our global cluster operations team.' + }, + { + type: 1, + name: 'Samsung SDS', + logo: 'samsung_sds', + link: 'http://www.samsungsdsa.com/cloud-infrastructure_kubernetes', + blurb: 'Samsung SDS’s Cloud Native Computing Team offers expert consulting across the range of technical aspects involved in building services targeted at a Kubernetes cluster.' + }, + { + type: 1, + name: 'Container Solutions', + logo: 'container_solutions', + link: 'http://container-solutions.com/resources/kubernetes/', + blurb: 'Container Solutions is a premium software consultancy that focuses on programmable infrastructure, offering our expertise in software development, strategy and operations to help you innovate at speed and scale.' + } + ] + + var isvContainer = document.getElementById('isvContainer') + var servContainer = document.getElementById('servContainer') + + var sorted = partners.sort(function (a, b) { + if (a.name > b.name) return 1 + if (a.name < b.name) return -1 + return 0 + }) + + sorted.forEach(function (obj) { + var box = document.createElement('div') + box.className = 'partner-box' + + var img = document.createElement('img') + img.src = '/images/square-logos/' + obj.logo + '.png' + + var div = document.createElement('div') + + var p = document.createElement('p') + p.textContent = obj.blurb + + var link = document.createElement('a') + link.href = obj.link + link.target = '_blank' + link.textContent = 'Learn more' + + div.appendChild(p) + div.appendChild(link) + + box.appendChild(img) + box.appendChild(div) + + var container = obj.type ? servContainer : isvContainer + container.appendChild(box) + }) +})(); \ No newline at end of file diff --git a/_includes/partner-style.css b/_includes/partner-style.css new file mode 100644 index 0000000000..a8cc125992 --- /dev/null +++ b/_includes/partner-style.css @@ -0,0 +1,94 @@ +h5 { + font-size: 18px; + line-height: 1.5em; + margin-bottom: 2em; +} + +#usersGrid a { + display: inline-block; + background-color: #f9f9f9; +} + +#isvContainer, #servContainer { + position: relative; + width: 100%; + display: flex; + justify-content: space-between; + flex-wrap: wrap; +} + +#isvContainer { + margin-bottom: 80px; +} + +.partner-box { + position: relative; + width: 47%; + max-width: 48%; + min-width: 48%; + margin-bottom: 20px; + padding: 20px; + flex: 1; + display: flex; + justify-content: space-between; + align-items: flex-start; +} + +.partner-box img { + background-color: #f9f9f9; +} + +.partner-box > div { + margin-left: 30px; +} + +.partner-box a { + color: #3576E3; +} + +@media screen and (max-width: 1024px) { + .partner-box { + flex-direction: column; + justify-content: flex-start; + } + + .partner-box > div { + margin: 20px 0 0; + } +} + +@media screen and (max-width: 568px) { + #isvContainer, #servContainer { + justify-content: center; + } + + .partner-box { + flex-direction: column; + justify-content: flex-start; + width: 100%; + max-width: 100%; + min-width: 100%; + } + + .partner-box > div { + margin: 20px 0 0; + } +} + +@media screen and (max-width: 568px) { + #isvContainer, #servContainer { + justify-content: center; + } + + .partner-box { + flex-direction: column; + justify-content: flex-start; + width: 100%; + max-width: 100%; + min-width: 100%; + } + + .partner-box > div { + margin: 20px 0 0; + } +} diff --git a/_includes/task-tutorial-prereqs.md b/_includes/task-tutorial-prereqs.md new file mode 100644 index 0000000000..a9cf90d265 --- /dev/null +++ b/_includes/task-tutorial-prereqs.md @@ -0,0 +1,4 @@ +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 by using +[Minikube](/docs/getting-started-guides/minikube). diff --git a/_layouts/docwithnav.html b/_layouts/docwithnav.html index 16b1235bf5..c2f74c1bb4 100755 --- a/_layouts/docwithnav.html +++ b/_layouts/docwithnav.html @@ -16,6 +16,7 @@
  • TASKS
  • CONCEPTS
  • REFERENCE
    • +
  • TOOLS
  • SAMPLES
  • SUPPORT
    • @@ -48,7 +49,6 @@ (function(d,c,j){if(!document.getElementById(j)){var pd=d.createElement(c),s;pd.id=j;pd.src=('https:'==document.location.protocol)?'https://polldaddy.com/js/rating/rating.js':'http://i0.poll.fm/js/rating/rating.js';s=document.getElementsByTagName(c)[0];s.parentNode.insertBefore(pd,s);}}(document,'script','pd-rating-js')); Create Issue Edit This Page {% endif %} diff --git a/_sass/_base.sass b/_sass/_base.sass index 91d47a6b48..a8ac4b47c4 100644 --- a/_sass/_base.sass +++ b/_sass/_base.sass @@ -1131,7 +1131,7 @@ $feature-box-div-margin-bottom: 40px // Community -#community, #caseStudies +#community, .gridPage &.open-nav, &.flip-nav .logo background-image: url(/images/nav_logo2.svg) @@ -1340,3 +1340,4 @@ $feature-box-div-margin-bottom: 40px // // // +// \ No newline at end of file diff --git a/_sass/_desktop.sass b/_sass/_desktop.sass index 7faddf913c..9c02fbcf6c 100644 --- a/_sass/_desktop.sass +++ b/_sass/_desktop.sass @@ -164,10 +164,11 @@ $video-section-height: 550px margin-bottom: 20px a - width: 20% + width: 16.65% float: left font-size: 24px font-weight: 300 + white-space: nowrap .social padding: 0 30px @@ -270,7 +271,7 @@ $video-section-height: 550px - #community, #caseStudies + #community, .gridPage #hero text-align: left diff --git a/_sass/_tablet.sass b/_sass/_tablet.sass index ce9bcd941d..15d5b496f4 100644 --- a/_sass/_tablet.sass +++ b/_sass/_tablet.sass @@ -222,8 +222,7 @@ $feature-box-div-width: 45% text-align: center a - font-size: 22px - width: auto + width: 30% padding: 0 20px .social diff --git a/case-studies/index.html b/case-studies/index.html index 8b0ffea42c..4b92adb805 100644 --- a/case-studies/index.html +++ b/case-studies/index.html @@ -3,7 +3,7 @@ title: Case Studies --- - + {% include head-header.html %}
    diff --git a/case-studies/pearson.html b/case-studies/pearson.html index 8625707f11..bf871789b9 100644 --- a/case-studies/pearson.html +++ b/case-studies/pearson.html @@ -3,7 +3,7 @@ title: Pearson Case Study --- - + {% include head-header.html %}
    diff --git a/case-studies/wikimedia.html b/case-studies/wikimedia.html index c725ca7683..00eb47e3e0 100644 --- a/case-studies/wikimedia.html +++ b/case-studies/wikimedia.html @@ -3,7 +3,7 @@ title: Wikimedia Case Study --- - + {% include head-header.html %}
    diff --git a/community.html b/community.html index f47bff33e7..9ef63c1b66 100644 --- a/community.html +++ b/community.html @@ -10,8 +10,6 @@ title: Community

    Community

    - -
    @@ -29,20 +27,6 @@ title: Community from AWS and Openstack to Big Data and Scalability, there’s a place for you to contribute and instructions for forming a new SIG if your special interest isn’t covered (yet).

    -
    -

    Customers

    -
    - - - - - - - - - -
    -

    Events

    @@ -50,34 +34,6 @@ title: Community frameborder="0" scrolling="no">
    -
    -

    Partners

    -

    We are working with a broad group of partners who contribute to the kubernetes core codebase, making it stronger and richer, as well as help in growing the kubernetes ecosystem supporting - a sprectrum of compelmenting platforms, from open source solutions to market-leading technologies.

    -
    - - - - - - - - - - - - - - - - - - - - - -
    -
    diff --git a/docs/admin/accessing-the-api.md b/docs/admin/accessing-the-api.md index 6569ac93f8..cb3f3d4ce4 100644 --- a/docs/admin/accessing-the-api.md +++ b/docs/admin/accessing-the-api.md @@ -52,8 +52,8 @@ On GCE, Client Certificates, Password, Plain Tokens, and JWT Tokens are all enab If the request cannot be authenticated, it is rejected with HTTP status code 401. Otherwise, the user is authenticated as a specific `username`, and the user name is available to subsequent steps to use in their decisions. Some authenticators -may also provide the group memberships of the user, while other authenticators -do not (and expect the authorizer to determine these). +also provide the group memberships of the user, while other authenticators +do not. While Kubernetes uses "usernames" for access control decisions and in request logging, it does not have a `user` object nor does it store usernames or other information about diff --git a/docs/admin/apparmor/index.md b/docs/admin/apparmor/index.md index 395aba1989..9730c07953 100644 --- a/docs/admin/apparmor/index.md +++ b/docs/admin/apparmor/index.md @@ -349,8 +349,8 @@ logs or through `journalctl`. More information is provided in Additional resources: -- http://wiki.apparmor.net/index.php/QuickProfileLanguage -- http://wiki.apparmor.net/index.php/ProfileLanguage +- [Quick guide to the AppArmor profile language](http://wiki.apparmor.net/index.php/QuickProfileLanguage) +- [AppArmor core policy reference](http://wiki.apparmor.net/index.php/ProfileLanguage) ## API Reference diff --git a/docs/admin/authentication.md b/docs/admin/authentication.md index c3c5e52c77..6819677107 100644 --- a/docs/admin/authentication.md +++ b/docs/admin/authentication.md @@ -25,10 +25,11 @@ manually through API calls. Service accounts are tied to a set of credentials stored as `Secrets`, which are mounted into pods allowing in cluster processes to talk to the Kubernetes API. -All API requests are tied to either a normal user or a service account. This -means every process inside or outside the cluster, from a human user typing -`kubectl` on a workstation, to `kubelets` on nodes, to members of the control -plane, must authenticate when making requests to the the API server. +API requests are tied to either a normal user or a service account, or are treated +as anonymous requests. This means every process inside or outside the cluster, from +a human user typing `kubectl` on a workstation, to `kubelets` on nodes, to members +of the control plane, must authenticate when making requests to the the API server, +or be treated as an anonymous user. ## Authentication strategies @@ -54,20 +55,31 @@ When multiple are enabled, the first authenticator module to successfully authenticate the request short-circuits evaluation. The API server does not guarantee the order authenticators run in. +The `system:authenticated` group is included in the list of groups for all authenticated users. + ### X509 Client Certs Client certificate authentication is enabled by passing the `--client-ca-file=SOMEFILE` option to API server. The referenced file must contain one or more certificates authorities to use to validate client certificates presented to the API server. If a client certificate is presented and verified, the common name of the subject is used as the user name for the -request. +request. As of Kubernetes 1.4, client certificates can also indicate a user's group memberships +using the certificate's organization fields. To include multiple group memberships for a user, +include multiple organization fields in the certificate. + +For example, using the `openssl` command line tool to generate a certificate signing request: + +``` bash +openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app2" +``` + +This would create a CSR for the username "jbeda", belonging to two groups, "app1" and "app2". See [APPENDIX](#appendix) for how to generate a client cert. ### Static Token File -Token file is enabled by passing the `--token-auth-file=SOMEFILE` option to the -API server. Currently, tokens last indefinitely, and the token list cannot be +The API server reads bearer tokens from a file when given the `--token-auth-file=SOMEFILE` option on the command line. Currently, tokens last indefinitely, and the token list cannot be changed without restarting API server. The token file format is implemented in `plugin/pkg/auth/authenticator/token/tokenfile/...` @@ -78,8 +90,19 @@ optional group names. Note, if you have more than one group the column must be d token,user,uid,"group1,group2,group3" ``` -When using token authentication from an http client the API server expects an `Authorization` -header with a value of `Bearer SOMETOKEN`. +#### Putting a Bearer Token in a Request + +When using bearer token authentication from an http client, the API +server expects an `Authorization` header with a value of `Bearer +THETOKEN`. The bearer token must be a character sequence that can be +put in an HTTP header value using no more than the encoding and +quoting facilities of HTTP. For example: if the bearer token is +`31ada4fd-adec-460c-809a-9e56ceb75269` then it would appear in an HTTP +header as shown below. + +```http +Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269 +``` ### Static Password File @@ -171,7 +194,8 @@ type: kubernetes.io/service-account-token Note: values are base64 encoded because secrets are always base64 encoded. The signed JWT can be used as a bearer token to authenticate as the given service -account. Normally these secrets are mounted into pods for in-cluster access to +account. See [above](#putting-a-bearer-token-in-a-request) for how the token is included +in a request. Normally these secrets are mounted into pods for in-cluster access to the API server, but can be used from outside the cluster as well. Service accounts authenticate with the username `system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT)`, @@ -192,11 +216,8 @@ email, signed by the server. To identify the user, the authenticator uses the `id_token` (not the `access_token`) from the OAuth2 [token response](https://openid.net/specs/openid-connect-core-1_0.html#TokenResponse) -as a bearer token. - -``` -Authentication: Bearer (id_token) -``` +as a bearer token. See [above](#putting-a-bearer-token-in-a-request) for how the token +is included in a request. To enable the plugin, pass the following required flags: @@ -272,10 +293,11 @@ contexts: name: webhook ``` -When a client attempts to authenticate with the API server using a bearer token, -using the `Authorization: Bearer (TOKEN)` HTTP header the authentication webhook +When a client attempts to authenticate with the API server using a bearer token +as discussed [above](#putting-a-bearer-token-in-a-request), +the authentication webhook queries the remote service with a review object containing the token. Kubernetes -will not challenge request that lack such a header. +will not challenge a request that lacks such a header. Note that webhook API objects are subject to the same [versioning compatibility rules](/docs/api/) as other Kubernetes API objects. Implementers should be aware of looser @@ -354,6 +376,22 @@ Please refer to the [discussion](https://github.com/kubernetes/kubernetes/pull/1 [blueprint](https://github.com/kubernetes/kubernetes/issues/11626) and [proposed changes](https://github.com/kubernetes/kubernetes/pull/25536) for more details. +## Anonymous requests + +Anonymous access is enabled by default, and can be disabled by passing `--anonymous-auth=false` +option to the API server during startup. + +When enabled, requests that are not rejected by other configured authentication methods are +treated as anonymous requests, and given a username of `system:anonymous` and a group of +`system:unauthenticated`. + +For example, on a server with token authentication configured, and anonymous access enabled, +a request providing an invalid bearer token would receive a `401 Unauthorized` error. +A request providing no bearer token would be treated as an anonymous request. + +If you rely on authentication alone to authorize access, either change to use an +authorization mode other than `AlwaysAllow`, or set `--anonymous-auth=false`. + ## Plugin Development We plan for the Kubernetes API server to issue tokens after the user has been diff --git a/docs/admin/authorization.md b/docs/admin/authorization.md index 1e7b180773..a72a855cb2 100644 --- a/docs/admin/authorization.md +++ b/docs/admin/authorization.md @@ -53,7 +53,7 @@ A request has the following attributes that can be considered for authorization: - what resource is being accessed (for resource requests only) - what subresource is being accessed (for resource requests only) - the namespace of the object being accessed (for namespaced resource requests only) - - the API group being accessed (for resource requests only) + - the API group being accessed (for resource requests only); an empty string designates the [core API group](../api.md#api-groups) The request verb for a resource API endpoint can be determined by the HTTP verb used and whether or not the request acts on an individual resource or a collection of resources: @@ -231,7 +231,7 @@ metadata: namespace: default name: pod-reader rules: - - apiGroups: [""] # The API group "" indicates the default API Group. + - apiGroups: [""] # The API group "" indicates the core API Group. resources: ["pods"] verbs: ["get", "watch", "list"] nonResourceURLs: [] @@ -323,6 +323,32 @@ roleRef: apiVersion: rbac.authorization.k8s.io/v1alpha1 ``` +### Referring to Resources + +Most resources are represented by a string representation of their name, such as "pods", just as it +appears in the URL for the relevant API endpoint. However, some Kubernetes APIs involve a +"subresource" such as the logs for a pod. The URL for the pods logs endpoint is: + +``` +GET /api/v1/namespaces/{namespace}/pods/{name}/log +``` + +In this case, "pods" is the namespaced resource, and "log" is a subresource of pods. To represent +this in an RBAC role, use a slash to delimit the resource and subresource names. To allow a subject +to read both pods and pod logs, you would write: + +```yaml +kind: Role +apiVersion: rbac.authorization.k8s.io/v1alpha1 +metadata: + namespace: default + name: pod-and-pod-logs-reader +rules: + - apiGroups: [""] + resources: ["pods", "pods/log"] + verbs: ["get", "list"] +``` + ### Referring to Subjects RoleBindings and ClusterRoleBindings bind "subjects" to "roles". @@ -351,6 +377,7 @@ to groups with the `system:` prefix. Only the `subjects` section of a RoleBinding object shown in the following examples. For a user called `alice@example.com`, specify + ```yaml subjects: - kind: User @@ -358,6 +385,7 @@ subjects: ``` For a group called `frontend-admins`, specify: + ```yaml subjects: - kind: Group @@ -365,6 +393,7 @@ subjects: ``` For the default service account in the kube-system namespace: + ```yaml subjects: - kind: ServiceAccount @@ -373,6 +402,7 @@ subjects: ``` For all service accounts in the `qa` namespace: + ```yaml subjects: - kind: Group @@ -380,6 +410,7 @@ subjects: ``` For all service accounts everywhere: + ```yaml subjects: - kind: Group @@ -601,4 +632,4 @@ subjectaccessreview "" created ``` This is useful for debugging access problems, in that you can use this resource -to determine what access an authorizer is granting. \ No newline at end of file +to determine what access an authorizer is granting. diff --git a/docs/admin/dns.md b/docs/admin/dns.md index a85f2338ce..cc132201aa 100644 --- a/docs/admin/dns.md +++ b/docs/admin/dns.md @@ -9,10 +9,14 @@ assignees: ## Introduction As of Kubernetes 1.3, DNS is a built-in service launched automatically using the addon manager [cluster add-on](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/README.md). -A DNS Pod and Service will be scheduled on the cluster, and the kubelets will be -configured to tell individual containers to use the DNS Service's IP to resolve DNS names. -Every Service defined in the cluster (including the DNS server itself) will be +Kubernetes DNS schedules a DNS Pod and Service on the cluster, and configures +the kubelets to tell individual containers to use the DNS Service's IP to +resolve DNS names. + +## What things get DNS names? + +Every Service defined in the cluster (including the DNS server itself) is assigned a DNS name. By default, a client Pod's DNS search list will include the Pod's own namespace and the cluster's default domain. This is best illustrated by example: @@ -22,17 +26,164 @@ in namespace `bar` can look up this service by simply doing a DNS query for `foo`. A Pod running in namespace `quux` can look up this service by doing a DNS query for `foo.bar`. -The Kubernetes cluster DNS server (based off the [SkyDNS](https://github.com/skynetservices/skydns) library) -supports forward lookups (A records), service lookups (SRV records) and reverse IP address lookups (PTR records). +## Supported DNS schema +The following sections detail the supported record types and layout that is +supported. Any other layout or names or queries that happen to work are +considered implementation details and are subject to change without warning. -## How it Works +### Services -The running Kubernetes DNS pod holds 3 containers - kubedns, dnsmasq and a health check called healthz. -The kubedns process watches the Kubernetes master for changes in Services and Endpoints, and maintains -in-memory lookup structures to service DNS requests. The dnsmasq container adds DNS caching to improve -performance. The healthz container provides a single health check endpoint while performing dual healthchecks -(for dnsmasq and kubedns). +#### A records + +"Normal" (not headless) Services are assigned a DNS A record for a name of the +form `my-svc.my-namespace.svc.cluster.local`. This resolves to the cluster IP +of the Service. + +"Headless" (without a cluster IP) Services are also assigned a DNS A record for +a name of the form `my-svc.my-namespace.svc.cluster.local`. Unlike normal +Services, this resolves to the set of IPs of the pods selected by the Service. +Clients are expected to consume the set or else use standard round-robin +selection from the set. + +### SRV records + +SRV Records are created for named ports that are part of normal or Headless +Services. +For each named port, the SRV record would have the form +`_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster.local`. +For a regular service, this resolves to the port number and the CNAME: +`my-svc.my-namespace.svc.cluster.local`. +For a headless service, this resolves to multiple answers, one for each pod +that is backing the service, and contains the port number and a CNAME of the pod +of the form `auto-generated-name.my-svc.my-namespace.svc.cluster.local`. + +### Backwards compatibility + +Previous versions of kube-dns made names of the for +`my-svc.my-namespace.cluster.local` (the 'svc' level was added later). This +is no longer supported. + +### Pods + +#### A Records + +When enabled, pods are assigned a DNS A record in the form of `pod-ip-address.my-namespace.pod.cluster.local`. + +For example, a pod with ip `1.2.3.4` in the namespace `default` with a dns name of `cluster.local` would have an entry: `1-2-3-4.default.pod.cluster.local`. + +#### A Records and hostname based on Pod's hostname and subdomain fields + +Currently when a pod is created, its hostname is the Pod's `metadata.name` value. + +With v1.2, users can specify a Pod annotation, `pod.beta.kubernetes.io/hostname`, to specify what the Pod's hostname should be. +The Pod annotation, if specified, takes precendence over the Pod's name, to be the hostname of the pod. +For example, given a Pod with annotation `pod.beta.kubernetes.io/hostname: my-pod-name`, the Pod will have its hostname set to "my-pod-name". + +With v1.3, the PodSpec has a `hostname` field, which can be used to specify the Pod's hostname. This field value takes precedence over the +`pod.beta.kubernetes.io/hostname` annotation value. + +v1.2 introduces a beta feature where the user can specify a Pod annotation, `pod.beta.kubernetes.io/subdomain`, to specify the Pod's subdomain. +The final domain will be "...svc.". +For example, a Pod with the hostname annotation set to "foo", and the subdomain annotation set to "bar", in namespace "my-namespace", will have the FQDN "foo.bar.my-namespace.svc.cluster.local" + +With v1.3, the PodSpec has a `subdomain` field, which can be used to specify the Pod's subdomain. This field value takes precedence over the +`pod.beta.kubernetes.io/subdomain` annotation value. + +Example: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: busybox + namespace: default +spec: + hostname: busybox-1 + subdomain: default + containers: + - image: busybox + command: + - sleep + - "3600" + name: busybox +``` + +If there exists a headless service in the same namespace as the pod and with the same name as the subdomain, the cluster's KubeDNS Server also returns an A record for the Pod's fully qualified hostname. +Given a Pod with the hostname set to "foo" and the subdomain set to "bar", and a headless Service named "bar" in the same namespace, the pod will see it's own FQDN as "foo.bar.my-namespace.svc.cluster.local". DNS serves an A record at that name, pointing to the Pod's IP. + +With v1.2, the Endpoints object also has a new annotation `endpoints.beta.kubernetes.io/hostnames-map`. Its value is the json representation of map[string(IP)][endpoints.HostRecord], for example: '{"10.245.1.6":{HostName: "my-webserver"}}'. +If the Endpoints are for a headless service, an A record is created with the format ...svc. +For the example json, if endpoints are for a headless service named "bar", and one of the endpoints has IP "10.245.1.6", an A is created with the name "my-webserver.bar.my-namespace.svc.cluster.local" and the A record lookup would return "10.245.1.6". +This endpoints annotation generally does not need to be specified by end-users, but can used by the internal service controller to deliver the aforementioned feature. + +With v1.3, The Endpoints object can specify the `hostname` for any endpoint, along with its IP. The hostname field takes precedence over the hostname value +that might have been specified via the `endpoints.beta.kubernetes.io/hostnames-map` annotation. + +With v1.3, the following annotations are deprecated: `pod.beta.kubernetes.io/hostname`, `pod.beta.kubernetes.io/subdomain`, `endpoints.beta.kubernetes.io/hostnames-map` + +## How do I test if it is working? + +### Create a simple Pod to use as a test environment. + +Create a file named busybox.yaml with the +following contents: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: busybox + namespace: default +spec: + containers: + - image: busybox + command: + - sleep + - "3600" + imagePullPolicy: IfNotPresent + name: busybox + restartPolicy: Always +``` + +Then create a pod using this file: + +``` +kubectl create -f busybox.yaml +``` + +### Wait for this pod to go into the running state. + +You can get its status with: +``` +kubectl get pods busybox +``` + +You should see: +``` +NAME READY STATUS RESTARTS AGE +busybox 1/1 Running 0 +``` + +### Validate DNS works + +Once that pod is running, you can exec nslookup in that environment: + +``` +kubectl exec busybox -- nslookup kubernetes.default +``` + +You should see something like: + +``` +Server: 10.0.0.10 +Address 1: 10.0.0.10 + +Name: kubernetes.default +Address 1: 10.0.0.1 +``` + +If you see that, DNS is working correctly. ## Kubernetes Federation (Multiple Zone support) @@ -44,6 +195,25 @@ the lookup of federated services (which span multiple Kubernetes clusters). See the [Cluster Federation Administrators' Guide](/docs/admin/federation) for more details on Cluster Federation and multi-site support. +## How it Works + +The running Kubernetes DNS pod holds 3 containers - kubedns, dnsmasq and a health check called healthz. +The kubedns process watches the Kubernetes master for changes in Services and Endpoints, and maintains +in-memory lookup structures to service DNS requests. The dnsmasq container adds DNS caching to improve +performance. The healthz container provides a single health check endpoint while performing dual healthchecks +(for dnsmasq and kubedns). + +The DNS pod is exposed as a Kubernetes Service with a static IP. Once assigned the +kubelet passes DNS configured using the `--cluster-dns=10.0.0.10` flag to each +container. + +DNS names also need domains. The local domain is configurable, in the kubelet using +the flag `--cluster-domain=` + +The Kubernetes cluster DNS server (based off the [SkyDNS](https://github.com/skynetservices/skydns) library) +supports forward lookups (A records), service lookups (SRV records) and reverse IP address lookups (PTR records). + + ## References - [Docs for the DNS cluster addon](http://releases.k8s.io/{{page.githubbranch}}/build/kube-dns/README.md) diff --git a/docs/admin/kubeadm.md b/docs/admin/kubeadm.md new file mode 100644 index 0000000000..a8acd6b1cb --- /dev/null +++ b/docs/admin/kubeadm.md @@ -0,0 +1,214 @@ +--- +assignees: +- mikedanese +- luxas +- errordeveloper + +--- + + +This document provides information on how to use kubeadm's advanced options. + +Running `kubeadm init` bootstraps a Kubernetes cluster. This consists of the +following steps: + +1. kubeadm runs a series of pre-flight checks to validate the system state +before making changes. Some checks only trigger warnings, others are +considered errors and will exit kubeadm until the problem is corrected or +the user specifies `--skip-preflight-checks`. + +1. kubeadm generates a token that additional nodes can use to register +themselves with the master in future. Optionally, the user can provide a token. + +1. kubeadm generates a self-signed CA using openssl to provision identities +for each node in the cluster, and for the API server to secure communication +with clients. + +1. Outputting a kubeconfig file for the kubelet to use to connect to the API +server, as well as an additional kubeconfig file for administration. + +1. kubeadm generates Kubernetes resource manifests for the API server, +controller manager and scheduler, and placing them in +`/etc/kubernetes/manifests`. The kubelet watches this directory for static +resources to create on startup. These are the core components of Kubernetes, and +once they are up and running we can use `kubectl` to set up/manage any +additional components. + +1. kubeadm installs any add-on components, such as DNS or discovery, via the API +server. + +Running `kubeadm join` on each node in the cluster consists of the following steps: + +1. Use the token to talk to the API server and securely get the root CA +certificate. + +1. Creates a local key pair. Prepares a certificate signing request (CSR) and +sends that off to the API server for signing. + +1. Configures the local kubelet to connect to the API server + +## Usage + +Fields that support multiple values do so either with comma separation, or by specifying +the flag multiple times. + +### `kubeadm init` + +It is usually sufficient to run `kubeadm init` without any flags, +but in some cases you might like to override the default behaviour. +Here we specify all the flags that can be used to customise the Kubernetes +installation. + +- `--api-advertise-addresses` (multiple values are allowed) +- `--api-external-dns-names` (multiple values are allowed) + +By default, `kubeadm init` automatically detects IP addresses and uses +these to generate certificates for the API server. This uses the IP address +of the default network interface. If you would like to access the API server +through a different IP address, or through a hostname, you can override these +defaults with `--api-advertise-addresses` and `--api-external-dns-names`. +For example, to generate certificates that verify the API server at addresses +`10.100.245.1` and `100.123.121.1`, you could use +`--api-advertise-addresses=10.100.245.1,100.123.121.1`. To allow it to be accessed +with a hostname, `--api-external-dns-names=kubernetes.example.com,kube.example.com` +Specifying `--api-advertise-addresses` disables auto detection of IP addresses. + +- `--cloud-provider` + +Currently, `kubeadm init` does not provide autodetection of cloud provider. +This means that load balancing and persistent volumes are not supported out +of the box. You can specify a cloud provider using `--cloud-provider`. +Valid values are the ones supported by `controller-manager`, namely `"aws"`, +`"azure"`, `"cloudstack"`, `"gce"`, `"mesos"`, `"openstack"`, `"ovirt"`, +`"rackspace"`, `"vsphere"`. In order to provide additional configuration for +the cloud provider, you should create a `/etc/kubernetes/cloud-config.json` +file manually, before running `kubeadm init`. `kubeadm` automatically +picks those settings up and ensures other nodes are configured correctly. +You must also set the `--cloud-provider` and `--cloud-config` parameters +yourself by editing the `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` +file appropriately. + +- `--external-etcd-cafile` etcd certificate authority file +- `--external-etcd-endpoints` (multiple values are allowed) +- `--external-etcd-certfile` etcd client certificate file +- `--external-etcd-keyfile` etcd client key file + +By default, `kubeadm` deploys a single node etcd cluster on the master +to store Kubernetes state. This means that any failure on the master node +requires you to rebuild your cluster from scratch. Currently `kubeadm init` +does not support automatic deployment of a highly available etcd cluster. +If you would like to use your own etcd cluster, you can override this +behaviour with `--external-etcd-endpoints`. `kubeadm` supports etcd client +authentication using the `--external-etcd-cafile`, `--external-etcd-certfile` +and `--external-etcd-keyfile` flags. + +- `--pod-network-cidr` + +By default, `kubeadm init` does not set node CIDR's for pods and allows you to +bring your own networking configuration through a CNI compatible network +controller addon such as [Weave Net](https://github.com/weaveworks/weave-kube), +[Calico](https://github.com/projectcalico/calico-containers/tree/master/docs/cni/kubernetes/manifests/kubeadm) +or [Canal](https://github.com/tigera/canal/tree/master/k8s-install/kubeadm). +If you are using a compatible cloud provider or flannel, you can specify a +subnet to use for each pod on the cluster with the `--pod-network-cidr` flag. +This should be a minimum of a /16 so that kubeadm is able to assign /24 subnets +to each node in the cluster. + +- `--service-cidr` (default '10.12.0.0/12') + +You can use the `--service-cidr` flag to override the subnet Kubernetes uses to +assign pods IP addresses. If you do, you will also need to update the +`/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` file to reflect this change +else DNS will not function correctly. + +- `--service-dns-domain` (default 'cluster.local') + +By default, `kubeadm init` deploys a cluster that assigns services with DNS names +`..svc.cluster.local`. You can use the `--service-dns-domain` +to change the DNS name suffix. Again, you will need to update the +`/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` file accordingly else DNS will +not function correctly. + +- `--skip-preflight-checks` + +By default, `kubeadm` runs a series of preflight checks to validate the system +before making any changes. Advanced users can use this flag to bypass these if +necessary. + +- `--token` + +By default, `kubeadm init` automatically generates the token used to initialise +each new node. If you would like to manually specify this token, you can use the +`--token` flag. The token must be of the format `<6 character string>.<16 character string>`. + +- `--use-kubernetes-version` (default 'v1.4.1') the kubernetes version to initialise + +`kubeadm` was originally built for Kubernetes version **v1.4.0**, older versions are not +supported. With this flag you can try any future version, e.g. **v1.5.0-beta.1** +whenever it comes out (check [releases page](https://github.com/kubernetes/kubernetes/releases) +for a full list of available versions). + +### `kubeadm join` + +When you use kubeadm join, you must supply the token used to secure cluster +boostrap as a mandatory flag, and the master IP address as a mandatory argument. + +Here's an example on how to use it: + +`kubeadm join --token=the_secret_token 192.168.1.1` + +- `--skip-preflight-checks` + +By default, `kubeadm` runs a series of preflight checks to validate the system +before making any changes. Advanced users can use this flag to bypass these if +necessary. + +- `--token=` + +By default, when `kubeadm init` runs, a token is generated and revealed in the output. +That's the token you should use here. + +## Automating kubeadm + +Rather than copying the token you obtained from `kubeadm init` to each node, as +in the basic `kubeadm` tutorials, you can parallelize the token distribution for +easier automation. To implement this automation, you must know the IP address +that the master will have after it is started. + +1. Generate a token. This token must have the form `<6 character string>.<16 +character string>` + + Here is a simple python one-liner for this: + + ``` + python -c 'import random; print "%0x.%0x" % (random.SystemRandom().getrandbits(3*8), random.SystemRandom().getrandbits(8*8))' + ``` + +1. Start both the master node and the worker nodes concurrently with this token. As they come up they should find each other and form the cluster. + +Once the cluster is up, you can grab the admin credentials from the master node at `/etc/kubernetes/admin.conf` and use that to talk to the cluster. + +## Environment variables + +There are some environment variables that modify the way that `kubeadm` works. Most users will have no need to set these. + +| Variable | Default | Description | +| --- | --- | --- | +| `KUBE_KUBERNETES_DIR` | `/etc/kubernetes` | Where most configuration files are written to and read from | +| `KUBE_HOST_PKI_PATH` | `/etc/kubernetes/pki` | Directory for master PKI assets | +| `KUBE_HOST_ETCD_PATH` | `/var/lib/etcd` | Local etcd state for Kubernetes cluster | +| `KUBE_HYPERKUBE_IMAGE` | `` | If set, use a single hyperkube image with this name. If not set, individual images per server component will be used. | +| `KUBE_DISCOVERY_IMAGE` | `gcr.io/google_containers/kube-discovery-:1.0` | The bootstrap discovery helper image to use. | +| `KUBE_ETCD_IMAGE` | `gcr.io/google_containers/etcd-:2.2.5` | The etcd container image to use. | +| `KUBE_COMPONENT_LOGLEVEL` | `--v=4` | Logging configuration for all Kubernetes components | + + +## Troubleshooting + +* Some users on RHEL/CentOS 7 have reported issues with traffic being routed incorrectly due to iptables being bypassed. You should ensure `net.bridge.bridge-nf-call-iptables` is set to 1 in your sysctl config, eg. + +``` +# cat /etc/sysctl.d/k8s.conf +net.bridge.bridge-nf-call-ip6tables = 1 +net.bridge.bridge-nf-call-iptables = 1 +``` diff --git a/docs/admin/limitrange/index.md b/docs/admin/limitrange/index.md index f38737981d..0336264bc3 100644 --- a/docs/admin/limitrange/index.md +++ b/docs/admin/limitrange/index.md @@ -1,214 +1,214 @@ ---- -assignees: -- derekwaynecarr -- janetkuo - ---- - -By default, pods run with unbounded CPU and memory limits. This means that any pod in the -system will be able to consume as much CPU and memory on the node that executes the pod. - -Users may want to impose restrictions on the amount of resource a single pod in the system may consume -for a variety of reasons. - -For example: - -1. Each node in the cluster has 2GB of memory. The cluster operator does not want to accept pods -that require more than 2GB of memory since no node in the cluster can support the requirement. To prevent a -pod from being permanently unscheduled to a node, the operator instead chooses to reject pods that exceed 2GB -of memory as part of admission control. -2. A cluster is shared by two communities in an organization that runs production and development workloads -respectively. Production workloads may consume up to 8GB of memory, but development workloads may consume up -to 512MB of memory. The cluster operator creates a separate namespace for each workload, and applies limits to -each namespace. -3. Users may create a pod which consumes resources just below the capacity of a machine. The left over space -may be too small to be useful, but big enough for the waste to be costly over the entire cluster. As a result, -the cluster operator may want to set limits that a pod must consume at least 20% of the memory and cpu of their -average node size in order to provide for more uniform scheduling and to limit waste. - -This example demonstrates how limits can be applied to a Kubernetes [namespace](/docs/admin/namespaces/walkthrough/) to control -min/max resource limits per pod. In addition, this example demonstrates how you can -apply default resource limits to pods in the absence of an end-user specified value. - -See [LimitRange design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/admission_control_limit_range.md) for more information. For a detailed description of the Kubernetes resource model, see [Resources](/docs/user-guide/compute-resources/) - -## Step 0: Prerequisites - -This example requires a running Kubernetes cluster. See the [Getting Started guides](/docs/getting-started-guides/) for how to get started. - -Change to the `` directory if you're not already there. - -## Step 1: Create a namespace - -This example will work in a custom namespace to demonstrate the concepts involved. - -Let's create a new namespace called limit-example: - -```shell -$ kubectl create namespace limit-example -namespace "limit-example" created -``` - -Note that `kubectl` commands will print the type and name of the resource created or mutated, which can then be used in subsequent commands: - -```shell -$ kubectl get namespaces -NAME STATUS AGE -default Active 51s -limit-example Active 45s -``` - -## Step 2: Apply a limit to the namespace - -Let's create a simple limit in our namespace. - -```shell -$ kubectl create -f docs/admin/limitrange/limits.yaml --namespace=limit-example -limitrange "mylimits" created -``` - -Let's describe the limits that we have imposed in our namespace. - -```shell -$ kubectl describe limits mylimits --namespace=limit-example -Name: mylimits -Namespace: limit-example -Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio ----- -------- --- --- --------------- ------------- ----------------------- -Pod cpu 200m 2 - - - -Pod memory 6Mi 1Gi - - - -Container cpu 100m 2 200m 300m - -Container memory 3Mi 1Gi 100Mi 200Mi - -``` - -In this scenario, we have said the following: - -1. If a max constraint is specified for a resource (2 CPU and 1Gi memory in this case), then a limit -must be specified for that resource across all containers. Failure to specify a limit will result in -a validation error when attempting to create the pod. Note that a default value of limit is set by -*default* in file `limits.yaml` (300m CPU and 200Mi memory). -2. If a min constraint is specified for a resource (100m CPU and 3Mi memory in this case), then a -request must be specified for that resource across all containers. Failure to specify a request will -result in a validation error when attempting to create the pod. Note that a default value of request is -set by *defaultRequest* in file `limits.yaml` (200m CPU and 100Mi memory). -3. For any pod, the sum of all containers memory requests must be >= 6Mi and the sum of all containers -memory limits must be <= 1Gi; the sum of all containers CPU requests must be >= 200m and the sum of all -containers CPU limits must be <= 2. - -## Step 3: Enforcing limits at point of creation - -The limits enumerated in a namespace are only enforced when a pod is created or updated in -the cluster. If you change the limits to a different value range, it does not affect pods that -were previously created in a namespace. - -If a resource (cpu or memory) is being restricted by a limit, the user will get an error at time -of creation explaining why. - -Let's first spin up a [Deployment](/docs/user-guide/deployments) that creates a single container Pod to demonstrate -how default values are applied to each pod. - -```shell -$ kubectl run nginx --image=nginx --replicas=1 --namespace=limit-example -deployment "nginx" created -``` - -Note that `kubectl run` creates a Deployment named "nginx" on Kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead. -If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/user-guide/kubectl/kubectl_run/) for more details. -The Deployment manages 1 replica of single container Pod. Let's take a look at the Pod it manages. First, find the name of the Pod: - -```shell -$ kubectl get pods --namespace=limit-example -NAME READY STATUS RESTARTS AGE -nginx-2040093540-s8vzu 1/1 Running 0 11s -``` - -Let's print this Pod with yaml output format (using `-o yaml` flag), and then `grep` the `resources` field. Note that your pod name will be different. - -``` shell -$ kubectl get pods nginx-2040093540-s8vzu --namespace=limit-example -o yaml | grep resources -C 8 - resourceVersion: "57" - selfLink: /api/v1/namespaces/limit-example/pods/nginx-2040093540-ivimu - uid: 67b20741-f53b-11e5-b066-64510658e388 -spec: - containers: - - image: nginx - imagePullPolicy: Always - name: nginx - resources: - limits: - cpu: 300m - memory: 200Mi - requests: - cpu: 200m - memory: 100Mi - terminationMessagePath: /dev/termination-log - volumeMounts: -``` - -Note that our nginx container has picked up the namespace default cpu and memory resource *limits* and *requests*. - -Let's create a pod that exceeds our allowed limits by having it have a container that requests 3 cpu cores. - -```shell -$ kubectl create -f docs/admin/limitrange/invalid-pod.yaml --namespace=limit-example -Error from server: error when creating "docs/admin/limitrange/invalid-pod.yaml": Pod "invalid-pod" is forbidden: [Maximum cpu usage per Pod is 2, but limit is 3., Maximum cpu usage per Container is 2, but limit is 3.] -``` - -Let's create a pod that falls within the allowed limit boundaries. - -```shell -$ kubectl create -f docs/admin/limitrange/valid-pod.yaml --namespace=limit-example -pod "valid-pod" created -``` - -Now look at the Pod's resources field: - -```shell -$ kubectl get pods valid-pod --namespace=limit-example -o yaml | grep -C 6 resources - uid: 3b1bfd7a-f53c-11e5-b066-64510658e388 -spec: - containers: - - image: gcr.io/google_containers/serve_hostname - imagePullPolicy: Always - name: kubernetes-serve-hostname - resources: - limits: - cpu: "1" - memory: 512Mi - requests: - cpu: "1" - memory: 512Mi -``` - -Note that this pod specifies explicit resource *limits* and *requests* so it did not pick up the namespace -default values. - -Note: The *limits* for CPU resource are enforced in the default Kubernetes setup on the physical node -that runs the container unless the administrator deploys the kubelet with the folllowing flag: - -```shell -$ kubelet --help -Usage of kubelet -.... - --cpu-cfs-quota[=true]: Enable CPU CFS quota enforcement for containers that specify CPU limits -$ kubelet --cpu-cfs-quota=false ... -``` - -## Step 4: Cleanup - -To remove the resources used by this example, you can just delete the limit-example namespace. - -```shell -$ kubectl delete namespace limit-example -namespace "limit-example" deleted -$ kubectl get namespaces -NAME STATUS AGE -default Active 12m -``` - -## Summary - -Cluster operators that want to restrict the amount of resources a single container or pod may consume -are able to define allowable ranges per Kubernetes namespace. In the absence of any explicit assignments, -the Kubernetes system is able to apply default resource *limits* and *requests* if desired in order to -constrain the amount of resource a pod consumes on a node. +--- +assignees: +- derekwaynecarr +- janetkuo + +--- + +By default, pods run with unbounded CPU and memory limits. This means that any pod in the +system will be able to consume as much CPU and memory on the node that executes the pod. + +Users may want to impose restrictions on the amount of resources a single pod in the system may consume +for a variety of reasons. + +For example: + +1. Each node in the cluster has 2GB of memory. The cluster operator does not want to accept pods +that require more than 2GB of memory since no node in the cluster can support the requirement. To prevent a +pod from being permanently unscheduled to a node, the operator instead chooses to reject pods that exceed 2GB +of memory as part of admission control. +2. A cluster is shared by two communities in an organization that runs production and development workloads +respectively. Production workloads may consume up to 8GB of memory, but development workloads may consume up +to 512MB of memory. The cluster operator creates a separate namespace for each workload, and applies limits to +each namespace. +3. Users may create a pod which consumes resources just below the capacity of a machine. The left over space +may be too small to be useful, but big enough for the waste to be costly over the entire cluster. As a result, +the cluster operator may want to set limits that a pod must consume at least 20% of the memory and cpu of their +average node size in order to provide for more uniform scheduling and to limit waste. + +This example demonstrates how limits can be applied to a Kubernetes [namespace](/docs/admin/namespaces/walkthrough/) to control +min/max resource limits per pod. In addition, this example demonstrates how you can +apply default resource limits to pods in the absence of an end-user specified value. + +See [LimitRange design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/admission_control_limit_range.md) for more information. For a detailed description of the Kubernetes resource model, see [Resources](/docs/user-guide/compute-resources/) + +## Step 0: Prerequisites + +This example requires a running Kubernetes cluster. See the [Getting Started guides](/docs/getting-started-guides/) for how to get started. + +Change to the `` directory if you're not already there. + +## Step 1: Create a namespace + +This example will work in a custom namespace to demonstrate the concepts involved. + +Let's create a new namespace called limit-example: + +```shell +$ kubectl create namespace limit-example +namespace "limit-example" created +``` + +Note that `kubectl` commands will print the type and name of the resource created or mutated, which can then be used in subsequent commands: + +```shell +$ kubectl get namespaces +NAME STATUS AGE +default Active 51s +limit-example Active 45s +``` + +## Step 2: Apply a limit to the namespace + +Let's create a simple limit in our namespace. + +```shell +$ kubectl create -f docs/admin/limitrange/limits.yaml --namespace=limit-example +limitrange "mylimits" created +``` + +Let's describe the limits that we have imposed in our namespace. + +```shell +$ kubectl describe limits mylimits --namespace=limit-example +Name: mylimits +Namespace: limit-example +Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio +---- -------- --- --- --------------- ------------- ----------------------- +Pod cpu 200m 2 - - - +Pod memory 6Mi 1Gi - - - +Container cpu 100m 2 200m 300m - +Container memory 3Mi 1Gi 100Mi 200Mi - +``` + +In this scenario, we have said the following: + +1. If a max constraint is specified for a resource (2 CPU and 1Gi memory in this case), then a limit +must be specified for that resource across all containers. Failure to specify a limit will result in +a validation error when attempting to create the pod. Note that a default value of limit is set by +*default* in file `limits.yaml` (300m CPU and 200Mi memory). +2. If a min constraint is specified for a resource (100m CPU and 3Mi memory in this case), then a +request must be specified for that resource across all containers. Failure to specify a request will +result in a validation error when attempting to create the pod. Note that a default value of request is +set by *defaultRequest* in file `limits.yaml` (200m CPU and 100Mi memory). +3. For any pod, the sum of all containers memory requests must be >= 6Mi and the sum of all containers +memory limits must be <= 1Gi; the sum of all containers CPU requests must be >= 200m and the sum of all +containers CPU limits must be <= 2. + +## Step 3: Enforcing limits at point of creation + +The limits enumerated in a namespace are only enforced when a pod is created or updated in +the cluster. If you change the limits to a different value range, it does not affect pods that +were previously created in a namespace. + +If a resource (cpu or memory) is being restricted by a limit, the user will get an error at time +of creation explaining why. + +Let's first spin up a [Deployment](/docs/user-guide/deployments) that creates a single container Pod to demonstrate +how default values are applied to each pod. + +```shell +$ kubectl run nginx --image=nginx --replicas=1 --namespace=limit-example +deployment "nginx" created +``` + +Note that `kubectl run` creates a Deployment named "nginx" on Kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead. +If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/user-guide/kubectl/kubectl_run/) for more details. +The Deployment manages 1 replica of single container Pod. Let's take a look at the Pod it manages. First, find the name of the Pod: + +```shell +$ kubectl get pods --namespace=limit-example +NAME READY STATUS RESTARTS AGE +nginx-2040093540-s8vzu 1/1 Running 0 11s +``` + +Let's print this Pod with yaml output format (using `-o yaml` flag), and then `grep` the `resources` field. Note that your pod name will be different. + +```shell +$ kubectl get pods nginx-2040093540-s8vzu --namespace=limit-example -o yaml | grep resources -C 8 + resourceVersion: "57" + selfLink: /api/v1/namespaces/limit-example/pods/nginx-2040093540-ivimu + uid: 67b20741-f53b-11e5-b066-64510658e388 +spec: + containers: + - image: nginx + imagePullPolicy: Always + name: nginx + resources: + limits: + cpu: 300m + memory: 200Mi + requests: + cpu: 200m + memory: 100Mi + terminationMessagePath: /dev/termination-log + volumeMounts: +``` + +Note that our nginx container has picked up the namespace default cpu and memory resource *limits* and *requests*. + +Let's create a pod that exceeds our allowed limits by having it have a container that requests 3 cpu cores. + +```shell +$ kubectl create -f docs/admin/limitrange/invalid-pod.yaml --namespace=limit-example +Error from server: error when creating "docs/admin/limitrange/invalid-pod.yaml": Pod "invalid-pod" is forbidden: [Maximum cpu usage per Pod is 2, but limit is 3., Maximum cpu usage per Container is 2, but limit is 3.] +``` + +Let's create a pod that falls within the allowed limit boundaries. + +```shell +$ kubectl create -f docs/admin/limitrange/valid-pod.yaml --namespace=limit-example +pod "valid-pod" created +``` + +Now look at the Pod's resources field: + +```shell +$ kubectl get pods valid-pod --namespace=limit-example -o yaml | grep -C 6 resources + uid: 3b1bfd7a-f53c-11e5-b066-64510658e388 +spec: + containers: + - image: gcr.io/google_containers/serve_hostname + imagePullPolicy: Always + name: kubernetes-serve-hostname + resources: + limits: + cpu: "1" + memory: 512Mi + requests: + cpu: "1" + memory: 512Mi +``` + +Note that this pod specifies explicit resource *limits* and *requests* so it did not pick up the namespace +default values. + +Note: The *limits* for CPU resource are enforced in the default Kubernetes setup on the physical node +that runs the container unless the administrator deploys the kubelet with the folllowing flag: + +```shell +$ kubelet --help +Usage of kubelet +.... + --cpu-cfs-quota[=true]: Enable CPU CFS quota enforcement for containers that specify CPU limits +$ kubelet --cpu-cfs-quota=false ... +``` + +## Step 4: Cleanup + +To remove the resources used by this example, you can just delete the limit-example namespace. + +```shell +$ kubectl delete namespace limit-example +namespace "limit-example" deleted +$ kubectl get namespaces +NAME STATUS AGE +default Active 12m +``` + +## Summary + +Cluster operators that want to restrict the amount of resources a single container or pod may consume +are able to define allowable ranges per Kubernetes namespace. In the absence of any explicit assignments, +the Kubernetes system is able to apply default resource *limits* and *requests* if desired in order to +constrain the amount of resource a pod consumes on a node. diff --git a/docs/admin/network-plugins.md b/docs/admin/network-plugins.md index b20e788b1a..eadbd67120 100644 --- a/docs/admin/network-plugins.md +++ b/docs/admin/network-plugins.md @@ -36,7 +36,11 @@ Place plugins in `network-plugin-dir/plugin-name/plugin-name`, i.e if you have a ### CNI -The CNI plugin is selected by passing Kubelet the `--network-plugin=cni` command-line option. Kubelet reads the first CNI configuration file from `--network-plugin-dir` and uses the CNI configuration from that file to set up each pod's network. The CNI configuration file must match the [CNI specification](https://github.com/containernetworking/cni/blob/master/SPEC.md), and any required CNI plugins referenced by the configuration must be present in `/opt/cni/bin`. +The CNI plugin is selected by passing Kubelet the `--network-plugin=cni` command-line option. Kubelet reads a file from `--cni-conf-dir` (default `/etc/cni/net.d`) and uses the CNI configuration from that file to set up each pod's network. The CNI configuration file must match the [CNI specification](https://github.com/containernetworking/cni/blob/master/SPEC.md), and any required CNI plugins referenced by the configuration must be present in `--cni-bin-dir` (default `/opt/cni/bin`). + +If there are multiple CNI configuration files in the directory, the first one in lexicographic order of file name is used. + +In addition to the CNI plugin specified by the configuration file, Kubernetes requires the standard CNI `lo` plugin, at minimum version 0.2.0 ### kubenet @@ -48,7 +52,7 @@ The kubenet plugin is mutually exclusive with the --configure-cbr0 option. The plugin requires a few things: -* The standard CNI `bridge` and `host-local` plugins are required. Kubenet will first search for them in `/opt/cni/bin`. Specify `network-plugin-dir` to supply additional search path. The first found match will take effect. +* The standard CNI `bridge`, `lo` and `host-local` plugins are required, at minimum version 0.2.0. Kubenet will first search for them in `/opt/cni/bin`. Specify `network-plugin-dir` to supply additional search path. The first found match will take effect. * Kubelet must be run with the `--network-plugin=kubenet` argument to enable the plugin * Kubelet must also be run with the `--reconcile-cidr` argument to ensure the IP subnet assigned to the node by configuration or the controller-manager is propagated to the plugin * The node must be assigned an IP subnet through either the `--pod-cidr` kubelet command-line option or the `--allocate-node-cidrs=true --cluster-cidr=` controller-manager command-line options. @@ -70,6 +74,6 @@ This option is provided to the network-plugin; currently **only kubenet supports ## Usage Summary * `--network-plugin=exec` specifies that we use the `exec` plugin, with executables located in `--network-plugin-dir`. -* `--network-plugin=cni` specifies that we use the `cni` network plugin with actual CNI plugin binaries located in `/opt/cni/bin` and CNI plugin configuration located in `network-plugin-dir`, config location defaults to `/etc/cni/net.d`. +* `--network-plugin=cni` specifies that we use the `cni` network plugin with actual CNI plugin binaries located in `--cni-bin-dir` (default `/opt/cni/bin`) and CNI plugin configuration located in `--cni-conf-dir` (default `/etc/cni/net.d`). * `--network-plugin=kubenet` specifies that we use the `kubenet` network plugin with CNI `bridge` and `host-local` plugins placed in `/opt/cni/bin` or `network-plugin-dir`. * `--network-plugin-mtu=9001` specifies the MTU to use, currently only used by the `kubenet` network plugin. \ No newline at end of file diff --git a/docs/admin/out-of-resource.md b/docs/admin/out-of-resource.md index 480e074c42..8af7114ed6 100644 --- a/docs/admin/out-of-resource.md +++ b/docs/admin/out-of-resource.md @@ -29,7 +29,7 @@ table below. The value of each signal is described in the description column ba summary API. | Eviction Signal | Description | -|------------------|---------------------------------------------------------------------------------| +|----------------------------|-----------------------------------------------------------------------| | `memory.available` | `memory.available` := `node.status.capacity[memory]` - `node.stats.memory.workingSet` | | `nodefs.available` | `nodefs.available` := `node.stats.fs.available` | | `nodefs.inodesFree` | `nodefs.inodesFree` := `node.stats.fs.inodesFree` | @@ -128,7 +128,7 @@ reflects the node is under pressure. The following node conditions are defined that correspond to the specified eviction signal. | Node Condition | Eviction Signal | Description | -|----------------|------------------|------------------------------------------------------------------| +|-------------------------|-------------------------------|--------------------------------------------| | `MemoryPressure` | `memory.available` | Available memory on the node has satisfied an eviction threshold | | `DiskPressure` | `nodefs.available`, `nodefs.inodesFree`, `imagefs.available`, or `imagefs.inodesFree` | Available disk space and inodes on either the node's root filesytem or image filesystem has satisfied an eviction threshold | @@ -270,7 +270,7 @@ the node depends on the [oom_killer](https://lwn.net/Articles/391222/) to respon The `kubelet` sets a `oom_score_adj` value for each container based on the quality of service for the pod. | Quality of Service | oom_score_adj | -| ----------------- | ------------- | +|----------------------------|-----------------------------------------------------------------------| | `Guaranteed` | -998 | | `BestEffort` | 1000 | | `Burstable` | min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999) | diff --git a/docs/admin/resourcequota/index.md b/docs/admin/resourcequota/index.md index bda5120121..ff76942702 100644 --- a/docs/admin/resourcequota/index.md +++ b/docs/admin/resourcequota/index.md @@ -58,7 +58,7 @@ that can be requested in a given namespace. The following resource types are supported: | Resource Name | Description | -| ------------ | ----------- | +| --------------------- | ----------------------------------------------------------- | | `cpu` | Across all pods in a non-terminal state, the sum of CPU requests cannot exceed this value. | | `limits.cpu` | Across all pods in a non-terminal state, the sum of CPU limits cannot exceed this value. | | `limits.memory` | Across all pods in a non-terminal state, the sum of memory limits cannot exceed this value. | @@ -73,7 +73,7 @@ The number of objects of a given type can be restricted. The following types are supported: | Resource Name | Description | -| ------------ | ----------- | +| ------------------------------- | ------------------------------------------------- | | `configmaps` | The total number of config maps that can exist in the namespace. | | `persistentvolumeclaims` | The total number of [persistent volume claims](/docs/user-guide/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. | | `pods` | The total number of pods in a non-terminal state that can exist in the namespace. A pod is in a terminal state if `status.phase in (Failed, Succeeded)` is true. | diff --git a/docs/admin/salt.md b/docs/admin/salt.md index 2cb634d7c6..5d82b54d39 100644 --- a/docs/admin/salt.md +++ b/docs/admin/salt.md @@ -1,106 +1,106 @@ ---- -assignees: -- davidopp -- lavalamp - ---- - -The Kubernetes cluster can be configured using Salt. - -The Salt scripts are shared across multiple hosting providers, so it's important to understand some background information prior to making a modification to ensure your changes do not break hosting Kubernetes across multiple environments. Depending on where you host your Kubernetes cluster, you may be using different operating systems and different networking configurations. As a result, it's important to understand some background information before making Salt changes in order to minimize introducing failures for other hosting providers. - -## Salt cluster setup - -The **salt-master** service runs on the kubernetes-master [(except on the default GCE setup)](#standalone-salt-configuration-on-gce). - -The **salt-minion** service runs on the kubernetes-master and each kubernetes-node in the cluster. - -Each salt-minion service is configured to interact with the **salt-master** service hosted on the kubernetes-master via the **master.conf** file [(except on GCE)](#standalone-salt-configuration-on-gce). - -```shell -[root@kubernetes-master] $ cat /etc/salt/minion.d/master.conf -master: kubernetes-master -``` - -The salt-master is contacted by each salt-minion and depending upon the machine information presented, the salt-master will provision the machine as either a kubernetes-master or kubernetes-node with all the required capabilities needed to run Kubernetes. - -If you are running the Vagrant based environment, the **salt-api** service is running on the kubernetes-master. It is configured to enable the vagrant user to introspect the salt cluster in order to find out about machines in the Vagrant environment via a REST API. - -## Standalone Salt Configuration on GCE - -On GCE, the master and nodes are all configured as [standalone minions](http://docs.saltstack.com/en/latest/topics/tutorials/standalone_minion.html). The configuration for each VM is derived from the VM's [instance metadata](https://cloud.google.com/compute/docs/metadata) and then stored in Salt grains (`/etc/salt/minion.d/grains.conf`) and pillars (`/srv/salt-overlay/pillar/cluster-params.sls`) that local Salt uses to enforce state. - -All remaining sections that refer to master/minion setups should be ignored for GCE. One fallout of the GCE setup is that the Salt mine doesn't exist - there is no sharing of configuration amongst nodes. - -## Salt security - -*(Not applicable on default GCE setup.)* - -Security is not enabled on the salt-master, and the salt-master is configured to auto-accept incoming requests from minions. It is not recommended to use this security configuration in production environments without deeper study. (In some environments this isn't as bad as it might sound if the salt master port isn't externally accessible and you trust everyone on your network.) - -```shell -[root@kubernetes-master] $ cat /etc/salt/master.d/auto-accept.conf -open_mode: True -auto_accept: True -``` - -## Salt minion configuration - -Each minion in the salt cluster has an associated configuration that instructs the salt-master how to provision the required resources on the machine. - -An example file is presented below using the Vagrant based environment. - -```shell -[root@kubernetes-master] $ cat /etc/salt/minion.d/grains.conf -grains: - etcd_servers: $MASTER_IP - cloud: vagrant - roles: - - kubernetes-master -``` - -Each hosting environment has a slightly different grains.conf file that is used to build conditional logic where required in the Salt files. - -The following enumerates the set of defined key/value pairs that are supported today. If you add new ones, please make sure to update this list. - -Key | Value -------------- | ------------- -`api_servers` | (Optional) The IP address / host name where a kubelet can get read-only access to kube-apiserver -`cbr-cidr` | (Optional) The minion IP address range used for the docker container bridge. -`cloud` | (Optional) Which IaaS platform is used to host Kubernetes, *gce*, *azure*, *aws*, *vagrant* -`etcd_servers` | (Optional) Comma-delimited list of IP addresses the kube-apiserver and kubelet use to reach etcd. Uses the IP of the first machine in the kubernetes_master role, or 127.0.0.1 on GCE. -`hostnamef` | (Optional) The full host name of the machine, i.e. uname -n -`node_ip` | (Optional) The IP address to use to address this node -`hostname_override` | (Optional) Mapped to the kubelet hostname-override -`network_mode` | (Optional) Networking model to use among nodes: *openvswitch* -`networkInterfaceName` | (Optional) Networking interface to use to bind addresses, default value *eth0* -`publicAddressOverride` | (Optional) The IP address the kube-apiserver should use to bind against for external read-only access -`roles` | (Required) 1. `kubernetes-master` means this machine is the master in the Kubernetes cluster. 2. `kubernetes-pool` means this machine is a kubernetes-node. Depending on the role, the Salt scripts will provision different resources on the machine. - -These keys may be leveraged by the Salt sls files to branch behavior. - -In addition, a cluster may be running a Debian based operating system or Red Hat based operating system (Centos, Fedora, RHEL, etc.). As a result, it's important to sometimes distinguish behavior based on operating system using if branches like the following. - -```liquid -{% raw %} -{% if grains['os_family'] == 'RedHat' %} -// something specific to a RedHat environment (Centos, Fedora, RHEL) where you may use yum, systemd, etc. -{% else %} -// something specific to Debian environment (apt-get, initd) -{% endif %} -{% endraw %} -``` - -## Best Practices - -1. When configuring default arguments for processes, it's best to avoid the use of EnvironmentFiles (Systemd in Red Hat environments) or init.d files (Debian distributions) to hold default values that should be common across operating system environments. This helps keep our Salt template files easy to understand for editors who may not be familiar with the particulars of each distribution. - -## Future enhancements (Networking) - -Per pod IP configuration is provider-specific, so when making networking changes, it's important to sandbox these as all providers may not use the same mechanisms (iptables, openvswitch, etc.) - -We should define a grains.conf key that captures more specifically what network configuration environment is being used to avoid future confusion across providers. - -## Further reading - -The [cluster/saltbase](http://releases.k8s.io/{{page.githubbranch}}/cluster/saltbase/) tree has more details on the current SaltStack configuration. \ No newline at end of file +--- +assignees: +- davidopp +- lavalamp + +--- + +The Kubernetes cluster can be configured using Salt. + +The Salt scripts are shared across multiple hosting providers, so it's important to understand some background information prior to making a modification to ensure your changes do not break hosting Kubernetes across multiple environments. Depending on where you host your Kubernetes cluster, you may be using different operating systems and different networking configurations. As a result, it's important to understand some background information before making Salt changes in order to minimize introducing failures for other hosting providers. + +## Salt cluster setup + +The **salt-master** service runs on the kubernetes-master [(except on the default GCE setup)](#standalone-salt-configuration-on-gce). + +The **salt-minion** service runs on the kubernetes-master and each kubernetes-node in the cluster. + +Each salt-minion service is configured to interact with the **salt-master** service hosted on the kubernetes-master via the **master.conf** file [(except on GCE)](#standalone-salt-configuration-on-gce). + +```shell +[root@kubernetes-master] $ cat /etc/salt/minion.d/master.conf +master: kubernetes-master +``` + +The salt-master is contacted by each salt-minion and depending upon the machine information presented, the salt-master will provision the machine as either a kubernetes-master or kubernetes-node with all the required capabilities needed to run Kubernetes. + +If you are running the Vagrant based environment, the **salt-api** service is running on the kubernetes-master. It is configured to enable the vagrant user to introspect the salt cluster in order to find out about machines in the Vagrant environment via a REST API. + +## Standalone Salt Configuration on GCE + +On GCE, the master and nodes are all configured as [standalone minions](http://docs.saltstack.com/en/latest/topics/tutorials/standalone_minion.html). The configuration for each VM is derived from the VM's [instance metadata](https://cloud.google.com/compute/docs/metadata) and then stored in Salt grains (`/etc/salt/minion.d/grains.conf`) and pillars (`/srv/salt-overlay/pillar/cluster-params.sls`) that local Salt uses to enforce state. + +All remaining sections that refer to master/minion setups should be ignored for GCE. One fallout of the GCE setup is that the Salt mine doesn't exist - there is no sharing of configuration amongst nodes. + +## Salt security + +*(Not applicable on default GCE setup.)* + +Security is not enabled on the salt-master, and the salt-master is configured to auto-accept incoming requests from minions. It is not recommended to use this security configuration in production environments without deeper study. (In some environments this isn't as bad as it might sound if the salt master port isn't externally accessible and you trust everyone on your network.) + +```shell +[root@kubernetes-master] $ cat /etc/salt/master.d/auto-accept.conf +open_mode: True +auto_accept: True +``` + +## Salt minion configuration + +Each minion in the salt cluster has an associated configuration that instructs the salt-master how to provision the required resources on the machine. + +An example file is presented below using the Vagrant based environment. + +```shell +[root@kubernetes-master] $ cat /etc/salt/minion.d/grains.conf +grains: + etcd_servers: $MASTER_IP + cloud: vagrant + roles: + - kubernetes-master +``` + +Each hosting environment has a slightly different grains.conf file that is used to build conditional logic where required in the Salt files. + +The following enumerates the set of defined key/value pairs that are supported today. If you add new ones, please make sure to update this list. + +Key | Value +-----------------------------------|---------------------------------------------------------------- +`api_servers` | (Optional) The IP address / host name where a kubelet can get read-only access to kube-apiserver +`cbr-cidr` | (Optional) The minion IP address range used for the docker container bridge. +`cloud` | (Optional) Which IaaS platform is used to host Kubernetes, *gce*, *azure*, *aws*, *vagrant* +`etcd_servers` | (Optional) Comma-delimited list of IP addresses the kube-apiserver and kubelet use to reach etcd. Uses the IP of the first machine in the kubernetes_master role, or 127.0.0.1 on GCE. +`hostnamef` | (Optional) The full host name of the machine, i.e. uname -n +`node_ip` | (Optional) The IP address to use to address this node +`hostname_override` | (Optional) Mapped to the kubelet hostname-override +`network_mode` | (Optional) Networking model to use among nodes: *openvswitch* +`networkInterfaceName` | (Optional) Networking interface to use to bind addresses, default value *eth0* +`publicAddressOverride` | (Optional) The IP address the kube-apiserver should use to bind against for external read-only access +`roles` | (Required) 1. `kubernetes-master` means this machine is the master in the Kubernetes cluster. 2. `kubernetes-pool` means this machine is a kubernetes-node. Depending on the role, the Salt scripts will provision different resources on the machine. + +These keys may be leveraged by the Salt sls files to branch behavior. + +In addition, a cluster may be running a Debian based operating system or Red Hat based operating system (Centos, Fedora, RHEL, etc.). As a result, it's important to sometimes distinguish behavior based on operating system using if branches like the following. + +```liquid +{% raw %} +{% if grains['os_family'] == 'RedHat' %} +// something specific to a RedHat environment (Centos, Fedora, RHEL) where you may use yum, systemd, etc. +{% else %} +// something specific to Debian environment (apt-get, initd) +{% endif %} +{% endraw %} +``` + +## Best Practices + +1. When configuring default arguments for processes, it's best to avoid the use of EnvironmentFiles (Systemd in Red Hat environments) or init.d files (Debian distributions) to hold default values that should be common across operating system environments. This helps keep our Salt template files easy to understand for editors who may not be familiar with the particulars of each distribution. + +## Future enhancements (Networking) + +Per pod IP configuration is provider-specific, so when making networking changes, it's important to sandbox these as all providers may not use the same mechanisms (iptables, openvswitch, etc.) + +We should define a grains.conf key that captures more specifically what network configuration environment is being used to avoid future confusion across providers. + +## Further reading + +The [cluster/saltbase](http://releases.k8s.io/{{page.githubbranch}}/cluster/saltbase/) tree has more details on the current SaltStack configuration. diff --git a/docs/admin/static-pods.md b/docs/admin/static-pods.md index d1ad849b3a..531494fb04 100644 --- a/docs/admin/static-pods.md +++ b/docs/admin/static-pods.md @@ -88,7 +88,7 @@ static-web-my-node1 172.17.0.3 my-node1/192.168 Labels from the static pod are propagated into the mirror-pod and can be used as usual for filtering. -Notice we cannot delete the pod with the API server (e.g. via [`kubectl`](/docs/user-guide/kubectl/kubectl/) command), kubelet simply won't remove it. +Notice we cannot delete the pod with the API server (e.g. via [`kubectl`](/docs/user-guide/kubectl/) command), kubelet simply won't remove it. ```shell [joe@my-master ~] $ kubectl delete pod static-web-my-node1 diff --git a/docs/contribute/create-pull-request.md b/docs/contribute/create-pull-request.md new file mode 100644 index 0000000000..833b4abf08 --- /dev/null +++ b/docs/contribute/create-pull-request.md @@ -0,0 +1,94 @@ +--- +redirect_from: + - /editdocs/ +--- + +{% capture overview %} + +To contribute to the Kubernetes documentation, create a pull request against the +[kubernetes/kubernetes.github.io](https://github.com/kubernetes/kubernetes.github.io){: target="_blank"} +repository. This page shows how to create a pull request. + +{% endcapture %} + +{% capture prerequisites %} + +1. Create a [GitHub account](https://github.com){: target="_blank"}. + +1. Sign the +[Google Contributor License Agreement](https://cla.developers.google.com/about/google-individual){: target="_blank"}. + +1. Sign the +[Linux Contributor License Agreement](https://identity.linuxfoundation.org/projects/cncf){: target="_blank"}. + +{% endcapture %} + +{% capture steps %} + +### Creating a fork of the Kubernetes documentation repository + +1. Go to the +[kubernetes/kubernetes.github.io](https://github.com/kubernetes/kubernetes.github.io){: target="_blank"} +repository. + +1. In the upper-right corner, click **Fork**. This creates a copy of the +Kubernetes documentation repository in your GitHub account. The copy +is called a *fork*. + +### Making your changes + +1. In your GitHub account, in your fork of the Kubernetes docs, create +a new branch to use for your contribution. + +1. In your new branch, make your changes and commit them. If you want to +[write a new topic](/docs/contribute/write-new-topic/), +choose the +[page type](/docs/contribute/page-templates/) +that is the best fit for your content. + +### Submitting a pull request to the master branch + +If you want your change to be published in the released version Kubernetes docs, +create a pull request against the master branch of the Kubernetes +documentation repository. + +1. In your GitHub account, in your new branch, create a pull request +against the master branch of the kubernetes/kubernetes.github.io +repository. This opens a page that shows the status of your pull request. + +1. Click **Show all checks**. Wait for the **deploy/netlify** check to complete. +To the right of **deploy/netlify**, click **Details**. This opens a staging +site where you can verify that your changes have rendered correctly. + +1. During the next few days, check your pull request for reviewer comments. +If needed, revise your pull request by committing changes to your +new branch in your fork. + +### Submitting a pull request to the <vnext> branch + +If your documentation change should not be released until the next release of +the Kubernetes product, create a pull request against the <vnext> branch +of the Kubernetes documentation repository. The <vnext> branch has the +form `release-`, for example release-1.5. + +1. In your GitHub account, in your new branch, create a pull request +against the <vnext> branch of the kubernetes/kubernetes.github.io +repository. This opens a page that shows the status of your pull request. + +1. Click **Show all checks**. Wait for the **deploy/netlify** check to complete. +To the right of **deploy/netlify**, click **Details**. This opens a staging +site where you can verify that your changes have rendered correctly. + +1. During the next few days, check your pull request for reviewer comments. +If needed, revise your pull request by committing changes to your +new branch in your fork. + +{% endcapture %} + +{% capture whatsnext %} +* Learn about [writing a new topic](/docs/contribute/write-new-topic). +* Learn about [using page templates](/docs/contribute/page-templates/). +* Learn about [staging your changes](/docs/contribute/stage-documentation-changes). +{% endcapture %} + +{% include templates/task.md %} diff --git a/docs/contribute/page-templates.md b/docs/contribute/page-templates.md index da77bfc38e..5bea261e3c 100644 --- a/docs/contribute/page-templates.md +++ b/docs/contribute/page-templates.md @@ -12,7 +12,7 @@
  • Concept
    • -

    The page templates are in the _includes/templates directory of the kubernetes.github.io repository. +

    The page templates are in the _includes/templates directory of the kubernetes.github.io repository.

    Task template

    @@ -71,7 +71,7 @@ Here's an interesting thing to know about the steps you just did.

    Here's an example of a published topic that uses the task template:

    -

    Using an HTTP Proxy to Access Applications in a Cluster

    +

    Using an HTTP Proxy to Access the Kubernetes API

    Tutorial template

    diff --git a/docs/contribute/stage-documentation-changes.md b/docs/contribute/stage-documentation-changes.md new file mode 100644 index 0000000000..8c01d92158 --- /dev/null +++ b/docs/contribute/stage-documentation-changes.md @@ -0,0 +1,98 @@ +--- +--- + +{% capture overview %} +This page shows how to stage content that you want to contribute +to the Kubernetes documentation. +{% endcapture %} + +{% capture prerequisites %} +Create a fork of the Kubernetes documentation repository as described in +[Creating a Documentation Pull Request](/docs/contribute/create-pull-request/). +{% endcapture %} + +{% capture steps %} + +### Staging from your GitHub account + +GitHub provides staging of content in your master branch. Note that you +might not want to merge your changes into your master branch. If that is +the case, choose another option for staging your content. + +1. In your GitHub account, in your fork, merge your changes into +the master branch. + +1. Change the name of your repository to `.github.io`, where +`` is the username of your GitHub account. + +1. Delete the `CNAME` file. + +1. View your staged content at this URL: + + https://.github.io + +### Staging a pull request + +When you create pull request against the Kubernetes documentation +repository, you can see your changes on a staging server. + +1. In your GitHub account, in your new branch, submit a pull request to the +kubernetes/kubernetes.github.io repository. This opens a page that shows the +status of your pull request. + +1. Click **Show all checks**. Wait for the **deploy/netlify** check to complete. +To the right of **deploy/netlify**, click **Details**. This opens a staging +site where you see your changes. + +### Staging locally using Docker + +You can use the k8sdocs Docker image to run a local staging server. If you're +interested, you can view the +[Dockerfile](https://github.com/kubernetes/kubernetes.github.io/blob/master/staging-container/Dockerfile){: target="_blank"} +for this image. + +1. Install Docker if you don't already have it. + +1. Clone your fork to your local development machine. + +1. In the root of your cloned repository, enter this command to start a local +web server: + + docker run -ti --rm -v "$PWD":/k8sdocs -p 4000:4000 gcr.io/google-samples/k8sdocs:1.0 + +1. View your staged content at +[http://localhost:4000](http://localhost:4000){: target="_blank"}. + +### Staging locally without Docker + +1. [Install Ruby 2.2 or later](https://www.ruby-lang.org){: target="_blank"}. + +1. [Install RubyGems](https://rubygems.org){: target="_blank"}. + +1. Verify that Ruby and RubyGems are installed: + + gem --version + +1. Install the GitHub Pages package, which includes Jekyll: + + gem install github-pages + +1. Clone your fork to your local development machine. + +1. In the root of your cloned repository, enter this command to start a local +web server: + + jekyll serve + +1. View your staged content at +[http://localhost:4000](http://localhost:4000){: target="_blank"}. + +{% endcapture %} + +{% capture whatsnext %} +* Learn about [writing a new topic](/docs/contribute/write-new-topic/). +* Learn about [using page templates](/docs/contribute/page-templates/). +* Learn about [creating a pull request](/docs/contribute/create-pull-request/). +{% endcapture %} + +{% include templates/task.md %} diff --git a/docs/contribute/write-new-topic.md b/docs/contribute/write-new-topic.md new file mode 100644 index 0000000000..c34f3cfde1 --- /dev/null +++ b/docs/contribute/write-new-topic.md @@ -0,0 +1,83 @@ +--- +--- + +{% capture overview %} +This page shows how to create a new topic for the Kubernetes docs. +{% endcapture %} + +{% capture prerequisites %} +Create a fork of the Kubernetes documentation repository as described in +[Creating a Documentation Pull Request](/docs/contribute/create-pull-request/). +{% endcapture %} + +{% capture steps %} + +### Choosing a page type + +As you prepare to write a new topic, think about which of these page types +is the best fit for your content: + + + + + + + + + + + + + + + + + + +
    TaskA 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.
    TutorialA 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.
    ConceptA 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 is deployed, scaled, and updated. Typically, concept pages don't include sequences of steps, but instead provide links to tasks or tutorials.
    + +Each page type has a +[template](/docs/contribute/page-templates/) +that you can use as you write your topic. +Using templates helps ensure consistency among topics of a given type. + +### Choosing a title and filename + +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/) +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: + + http://kubernetes.io/docs/tasks/access-kubernetes-api/http-proxy-access-api/ + +### Choosing a directory + +Depending on your page type, put your new file in a subdirectory of one of these: + +* /docs/tasks/ +* /docs/tutorials/ +* /docs/concepts/ + +You can put your file in an existing subdirectory, or you can create a new +subdirectory. + +### Creating an entry in the table of contents + +Depending page type, create an entry in one of these files: + +* /_data/tasks.yaml +* /_data/tutorials.yaml +* /_data/concepts.yaml + +{% endcapture %} + +{% capture whatsnext %} +* Learn about [using page templates](/docs/contribute/page-templates/). +* Learn about [staging your changes](/docs/contribute/stage-documentation-changes). +* Learn about [creating a pull request](/docs/contribute/write-new-topic). +{% endcapture %} + +{% include templates/task.md %} diff --git a/docs/getting-started-guides/azure.md b/docs/getting-started-guides/azure.md index a6f29ef030..40652e3172 100644 --- a/docs/getting-started-guides/azure.md +++ b/docs/getting-started-guides/azure.md @@ -5,12 +5,8 @@ assignees: --- -* TOC -{:toc} - - -## Overview - The recommended approach for deploying a Kubernetes 1.4 cluster on Azure is the -[`kubernetes-anywhere`](https://github.com/kubernetes/kubernetes-anywhere) project. You will want to take a look at the -[Azure Getting Started Guide](https://github.com/kubernetes/kubernetes-anywhere/blob/master/phase1/azure/README.md). \ No newline at end of file +[`kubernetes-anywhere`](https://github.com/kubernetes/kubernetes-anywhere) project. + +You will want to take a look at the +[Azure Getting Started Guide](https://github.com/kubernetes/kubernetes-anywhere/blob/master/phase1/azure/README.md). diff --git a/docs/getting-started-guides/centos/centos_manual_config.md b/docs/getting-started-guides/centos/centos_manual_config.md index d2d12e9e15..75b7cccbf7 100644 --- a/docs/getting-started-guides/centos/centos_manual_config.md +++ b/docs/getting-started-guides/centos/centos_manual_config.md @@ -1,182 +1,224 @@ ---- -assignees: -- lavalamp -- thockin - ---- - -* TOC -{:toc} - -## Prerequisites - -You need two machines with CentOS installed on them. - -## Starting a cluster - -This is a getting started guide for CentOS. It is a manual configuration so you understand all the underlying packages / services / ports, etc... - -This guide will only get ONE node working. Multiple nodes requires a functional [networking configuration](/docs/admin/networking) done outside of kubernetes. Although the additional Kubernetes configuration requirements should be obvious. - -The Kubernetes package provides a few services: kube-apiserver, kube-scheduler, kube-controller-manager, kubelet, kube-proxy. These services are managed by systemd and the configuration resides in a central location: /etc/kubernetes. We will break the services up between the hosts. The first host, centos-master, will be the Kubernetes master. This host will run the kube-apiserver, kube-controller-manager, and kube-scheduler. In addition, the master will also run _etcd_. The remaining host, centos-minion will be the node and run kubelet, proxy, cadvisor and docker. - -**System Information:** - -Hosts: - -Please replace host IP with your environment. - -```conf -centos-master = 192.168.121.9 -centos-minion = 192.168.121.65 -``` - -**Prepare the hosts:** - -* Create a /etc/yum.repos.d/virt7-docker-common-release.repo on all hosts - centos-{master,minion} with following information. - -```conf -[virt7-docker-common-release] -name=virt7-docker-common-release -baseurl=http://cbs.centos.org/repos/virt7-docker-common-release/x86_64/os/ -gpgcheck=0 -``` - -* Install Kubernetes and etcd on all hosts - centos-{master,minion}. This will also pull in docker and cadvisor. - -```shell -yum -y install --enablerepo=virt7-docker-common-release kubernetes etcd -``` - -* Add master and node to /etc/hosts on all machines (not needed if hostnames already in DNS) - -```shell -echo "192.168.121.9 centos-master -192.168.121.65 centos-minion" >> /etc/hosts -``` - -* Edit /etc/kubernetes/config which will be the same on all hosts to contain: - -```shell -# Comma separated list of nodes in the etcd cluster -KUBE_ETCD_SERVERS="--etcd-servers=http://centos-master:2379" - -# logging to stderr means we get it in the systemd journal -KUBE_LOGTOSTDERR="--logtostderr=true" - -# journal message level, 0 is debug -KUBE_LOG_LEVEL="--v=0" - -# Should this cluster be allowed to run privileged docker containers -KUBE_ALLOW_PRIV="--allow-privileged=false" - -# How the replication controller and scheduler find the kube-apiserver -KUBE_MASTER="--master=http://centos-master:8080" -``` - -* Disable the firewall on both the master and node, as docker does not play well with other firewall rule managers - -```shell -systemctl disable iptables-services firewalld -systemctl stop iptables-services firewalld -``` - -**Configure the Kubernetes services on the master.** - -* Edit /etc/etcd/etcd.conf to appear as such: - -```shell -# [member] -ETCD_NAME=default -ETCD_DATA_DIR="/var/lib/etcd/default.etcd" -ETCD_LISTEN_CLIENT_URLS="http://0.0.0.0:2379" - -#[cluster] -ETCD_ADVERTISE_CLIENT_URLS="http://0.0.0.0:2379" -``` - -* Edit /etc/kubernetes/apiserver to appear as such: - -```shell -# The address on the local server to listen to. -KUBE_API_ADDRESS="--address=0.0.0.0" - -# The port on the local server to listen on. -KUBE_API_PORT="--port=8080" - -# Port kubelets listen on -KUBELET_PORT="--kubelet-port=10250" - -# Address range to use for services -KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16" - -# Add your own! -KUBE_API_ARGS="" -``` - -* Start the appropriate services on master: - -```shell -for SERVICES in etcd kube-apiserver kube-controller-manager kube-scheduler; do - systemctl restart $SERVICES - systemctl enable $SERVICES - systemctl status $SERVICES -done -``` - -**Configure the Kubernetes services on the node.** - -***We need to configure the kubelet and start the kubelet and proxy*** - -* Edit /etc/kubernetes/kubelet to appear as such: - -```shell -# The address for the info server to serve on -KUBELET_ADDRESS="--address=0.0.0.0" - -# The port for the info server to serve on -KUBELET_PORT="--port=10250" - -# You may leave this blank to use the actual hostname -KUBELET_HOSTNAME="--hostname-override=centos-minion" - -# Location of the api-server -KUBELET_API_SERVER="--api-servers=http://centos-master:8080" - -# Add your own! -KUBELET_ARGS="" -``` - -* Start the appropriate services on node (centos-minion). - -```shell -for SERVICES in kube-proxy kubelet docker; do - systemctl restart $SERVICES - systemctl enable $SERVICES - systemctl status $SERVICES -done -``` - -*You should be finished!* - -* Check to make sure the cluster can see the node (on centos-master) - -```shell -$ kubectl get nodes -NAME LABELS STATUS -centos-minion Ready -``` - -**The cluster should be running! Launch a test pod.** - -You should have a functional cluster, check out [101](/docs/user-guide/walkthrough/)! - -## Support Level - - -IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level --------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- -Bare-metal | custom | CentOS | _none_ | [docs](/docs/getting-started-guides/centos/centos_manual_config) | | Community ([@coolsvap](https://github.com/coolsvap)) - -For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions) chart. - +--- +assignees: +- lavalamp +- thockin + +--- + +* TOC +{:toc} + +## Prerequisites + +To configure Kubernetes with CentOS, you'll need a machine to act as a master, and one or more CentOS 7 hosts to act as cluster nodes. + +## Starting a cluster + +This is a getting started guide for CentOS. It is a manual configuration so you understand all the underlying packages / services / ports, etc... + +The Kubernetes package provides a few services: kube-apiserver, kube-scheduler, kube-controller-manager, kubelet, kube-proxy. These services are managed by systemd and the configuration resides in a central location: /etc/kubernetes. We will break the services up between the hosts. The first host, centos-master, will be the Kubernetes master. This host will run the kube-apiserver, kube-controller-manager and kube-scheduler. In addition, the master will also run _etcd_. The remaining hosts, centos-minion-n will be the nodes and run kubelet, proxy, cadvisor and docker. + +All of then run flanneld as networking overlay. + +**System Information:** + +Hosts: + +Please replace host IP with your environment. + +```conf +centos-master = 192.168.121.9 +centos-minion-1 = 192.168.121.65 +centos-minion-2 = 192.168.121.66 +centos-minion-3 = 192.168.121.67 +``` + +**Prepare the hosts:** + +* Create a /etc/yum.repos.d/virt7-docker-common-release.repo on all hosts - centos-{master,minion-n} with following information. + +```conf +[virt7-docker-common-release] +name=virt7-docker-common-release +baseurl=http://cbs.centos.org/repos/virt7-docker-common-release/x86_64/os/ +gpgcheck=0 +``` + +* Install Kubernetes, etcd and flannel on all hosts - centos-{master,minion-n}. This will also pull in docker and cadvisor. + +```shell +yum -y install --enablerepo=virt7-docker-common-release kubernetes etcd flannel +``` + +* Add master and node to /etc/hosts on all machines (not needed if hostnames already in DNS) + +```shell +echo "192.168.121.9 centos-master +192.168.121.65 centos-minion-1 +192.168.121.66 centos-minion-2 +192.168.121.67 centos-minion-3" >> /etc/hosts +``` + +* Edit /etc/kubernetes/config which will be the same on all hosts to contain: + +```shell +# Comma separated list of nodes in the etcd cluster +KUBE_ETCD_SERVERS="--etcd-servers=http://centos-master:2379" + +# logging to stderr means we get it in the systemd journal +KUBE_LOGTOSTDERR="--logtostderr=true" + +# journal message level, 0 is debug +KUBE_LOG_LEVEL="--v=0" + +# Should this cluster be allowed to run privileged docker containers +KUBE_ALLOW_PRIV="--allow-privileged=false" + +# How the replication controller and scheduler find the kube-apiserver +KUBE_MASTER="--master=http://centos-master:8080" +``` + +* Disable the firewall on the master and all the nodes, as docker does not play well with other firewall rule managers + +```shell +systemctl disable iptables-services firewalld +systemctl stop iptables-services firewalld +``` + +**Configure the Kubernetes services on the master.** + +* Edit /etc/etcd/etcd.conf to appear as such: + +```shell +# [member] +ETCD_NAME=default +ETCD_DATA_DIR="/var/lib/etcd/default.etcd" +ETCD_LISTEN_CLIENT_URLS="http://0.0.0.0:2379" + +#[cluster] +ETCD_ADVERTISE_CLIENT_URLS="http://0.0.0.0:2379" +``` + +* Edit /etc/kubernetes/apiserver to appear as such: + +```shell +# The address on the local server to listen to. +KUBE_API_ADDRESS="--address=0.0.0.0" + +# The port on the local server to listen on. +KUBE_API_PORT="--port=8080" + +# Port kubelets listen on +KUBELET_PORT="--kubelet-port=10250" + +# Address range to use for services +KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16" + +# Add your own! +KUBE_API_ARGS="" +``` + +* Configure ETCD to hold the network overlay configuration on master: +**Warning** This network must be unused in your network infrastructure! `172.30.0.0/16` is free in our network. + +```shell +$ etcdctl mkdir /kube-centos/network +$ etcdclt mk /kube-centos/network/config "{ \"Network\": \"172.30.0.0/16\", \"SubnetLen\": 24, \"Backend\": { \"Type\": \"vxlan\" } }" +``` + +* Configure flannel to overlay Docker network in /etc/sysconfig/flanneld on the master (also in the nodes as we'll see): + +```shell +# etcd url location. Point this to the server where etcd runs +FLANNEL_ETCD="http://centos-master:2379" + +# etcd config key. This is the configuration key that flannel queries +# For address range assignment +FLANNEL_ETCD_KEY="/kube-centos/network" + +# Any additional options that you want to pass +FLANNEL_OPTIONS="" +``` + +* Start the appropriate services on master: + +```shell +for SERVICES in etcd kube-apiserver kube-controller-manager kube-scheduler flanneld; do + systemctl restart $SERVICES + systemctl enable $SERVICES + systemctl status $SERVICES +done +``` + +**Configure the Kubernetes services on the nodes.** + +***We need to configure the kubelet and start the kubelet and proxy*** + +* Edit /etc/kubernetes/kubelet to appear as such: + +```shell +# The address for the info server to serve on +KUBELET_ADDRESS="--address=0.0.0.0" + +# The port for the info server to serve on +KUBELET_PORT="--port=10250" + +# You may leave this blank to use the actual hostname +KUBELET_HOSTNAME="--hostname-override=centos-minion-n" # Check the node number! + +# Location of the api-server +KUBELET_API_SERVER="--api-servers=http://centos-master:8080" + +# Add your own! +KUBELET_ARGS="" +``` + +* Configure flannel to overlay Docker network in /etc/sysconfig/flanneld (in all the nodes) + +```shell +# etcd url location. Point this to the server where etcd runs +FLANNEL_ETCD="http://centos-master:2379" + +# etcd config key. This is the configuration key that flannel queries +# For address range assignment +FLANNEL_ETCD_KEY="/kube-centos/network" + +# Any additional options that you want to pass +FLANNEL_OPTIONS="" +``` + +* Start the appropriate services on node (centos-minion-n). + +```shell +for SERVICES in kube-proxy kubelet flanneld docker; do + systemctl restart $SERVICES + systemctl enable $SERVICES + systemctl status $SERVICES +done +``` + +*You should be finished!* + +* Check to make sure the cluster can see the node (on centos-master) + +```shell +$ kubectl get nodes +NAME LABELS STATUS +centos-minion-1 Ready +centos-minion-2 Ready +centos-minion-3 Ready +``` + +**The cluster should be running! Launch a test pod.** + +You should have a functional cluster, check out [101](/docs/user-guide/walkthrough/)! + +## Support Level + + +IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level +-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- +Bare-metal | custom | CentOS | flannel | [docs](/docs/getting-started-guides/centos/centos_manual_config) | | Community ([@coolsvap](https://github.com/coolsvap)) + +For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions) chart. + diff --git a/docs/getting-started-guides/coreos/bare_metal_calico.md b/docs/getting-started-guides/coreos/bare_metal_calico.md index 9cbdd89b17..7c3f7ccca0 100644 --- a/docs/getting-started-guides/coreos/bare_metal_calico.md +++ b/docs/getting-started-guides/coreos/bare_metal_calico.md @@ -1,209 +1,209 @@ ---- - ---- - -This document describes how to deploy Kubernetes with Calico networking on _bare metal_ CoreOS. For more information on Project Calico, visit [projectcalico.org](http://projectcalico.org) and the [calico-containers repository](https://github.com/projectcalico/calico-containers). - -To install Calico on an existing Kubernetes cluster, or for more information on deploying Calico with Kubernetes in a number of other environments take a look at our supported [deployment guides](https://github.com/projectcalico/calico-containers/tree/master/docs/cni/kubernetes). - -Specifically, this guide will have you do the following: - -- Deploy a Kubernetes master node on CoreOS using cloud-config. -- Deploy two Kubernetes compute nodes with Calico Networking using cloud-config. -- Configure `kubectl` to access your cluster. - -The resulting cluster will use SSL between Kubernetes components. It will run the SkyDNS service and kube-ui, and be fully conformant with the Kubernetes v1.1 conformance tests. - -## Prerequisites and Assumptions - -- At least three bare-metal machines (or VMs) to work with. This guide will configure them as follows: - - 1 Kubernetes Master - - 2 Kubernetes Nodes -- Your nodes should have IP connectivity to each other and the internet. -- This guide assumes a DHCP server on your network to assign server IPs. -- This guide uses `192.168.0.0/16` as the subnet from which pod IP addresses are assigned. If this overlaps with your host subnet, you will need to configure Calico to use a different [IP pool](https://github.com/projectcalico/calico-containers/blob/master/docs/calicoctl/pool.md#calicoctl-pool-commands). - -## Cloud-config - -This guide will use [cloud-config](https://coreos.com/docs/cluster-management/setup/cloudinit-cloud-config/) to configure each of the nodes in our Kubernetes cluster. - -We'll use two cloud-config files: -- `master-config.yaml`: cloud-config for the Kubernetes master -- `node-config.yaml`: cloud-config for each Kubernetes node - -## Download CoreOS - -Download the stable CoreOS bootable ISO from the [CoreOS website](https://coreos.com/docs/running-coreos/platforms/iso/). - -## Configure the Kubernetes Master - -1. Once you've downloaded the ISO image, burn the ISO to a CD/DVD/USB key and boot from it (if using a virtual machine you can boot directly from the ISO). Once booted, you should be automatically logged in as the `core` user at the terminal. At this point CoreOS is running from the ISO and it hasn't been installed yet. - -2. *On another machine*, download the [master cloud-config template](https://raw.githubusercontent.com/projectcalico/calico-cni/k8s-1.1-docs/samples/kubernetes/cloud-config/master-config-template.yaml) and save it as `master-config.yaml`. - -3. Replace the following variables in the `master-config.yaml` file. - - - ``: The public key you will use for SSH access to this server. See [generating ssh keys](https://help.github.com/articles/generating-ssh-keys/) - -4. Copy the edited `master-config.yaml` to your Kubernetes master machine (using a USB stick, for example). - -5. The CoreOS bootable ISO comes with a tool called `coreos-install` which will allow us to install CoreOS and configure the machine using a cloud-config file. The following command will download and install stable CoreOS using the `master-config.yaml` file we just created for configuration. Run this on the Kubernetes master. - - > **Warning:** this is a destructive operation that erases disk `sda` on your server. - - ```shell - sudo coreos-install -d /dev/sda -C stable -c master-config.yaml - ``` - -6. Once complete, restart the server and boot from `/dev/sda` (you may need to remove the ISO image). When it comes back up, you should have SSH access as the `core` user using the public key provided in the `master-config.yaml` file. - -### Configure TLS - -The master requires the CA certificate, `ca.pem`; its own certificate, `apiserver.pem` and its private key, `apiserver-key.pem`. This [CoreOS guide](https://coreos.com/kubernetes/docs/latest/openssl.html) explains how to generate these. - -1. Generate the necessary certificates for the master. This [guide for generating Kubernetes TLS Assets](https://coreos.com/kubernetes/docs/latest/openssl.html) explains how to use OpenSSL to generate the required assets. - -2. Send the three files to your master host (using `scp` for example). - -3. Move them to the `/etc/kubernetes/ssl` folder and ensure that only the root user can read the key: - - ```shell - # Move keys - sudo mkdir -p /etc/kubernetes/ssl/ - sudo mv -t /etc/kubernetes/ssl/ ca.pem apiserver.pem apiserver-key.pem - - # Set Permissions - sudo chmod 600 /etc/kubernetes/ssl/apiserver-key.pem - sudo chown root:root /etc/kubernetes/ssl/apiserver-key.pem - ``` - -4. Restart the kubelet to pick up the changes: - - ```shell - sudo systemctl restart kubelet - ``` - -## Configure the compute nodes - -The following steps will set up a single Kubernetes node for use as a compute host. Run these steps to deploy each Kubernetes node in your cluster. - -1. Boot up the node machine using the bootable ISO we downloaded earlier. You should be automatically logged in as the `core` user. - -2. Make a copy of the [node cloud-config template](https://raw.githubusercontent.com/projectcalico/calico-cni/k8s-1.1-docs/samples/kubernetes/cloud-config/node-config-template.yaml) for this machine. - -3. Replace the following placeholders in the `node-config.yaml` file to match your deployment. - - - ``: Hostname for this node (e.g. kube-node1, kube-node2) - - ``: The public key you will use for SSH access to this server. - - ``: The IPv4 address of the Kubernetes master. - -4. Replace the following placeholders with the contents of their respective files. - - - ``: Complete contents of `ca.pem` - - ``: Complete contents of `ca-key.pem` - - > **Important:** in a production deployment, embedding the secret key in cloud-config is a bad idea! In production you should use an appropriate secret manager. - - > **Important:** Make sure you indent the entire file to match the indentation of the placeholder. For example: - > - > ```shell - > - path: /etc/kubernetes/ssl/ca.pem - > owner: core - > permissions: 0644 - > content: | - > - > ``` - > - > should look like this once the certificate is in place: - > - > ```shell - > - path: /etc/kubernetes/ssl/ca.pem - > owner: core - > permissions: 0644 - > content: | - > -----BEGIN CERTIFICATE----- - > MIIC9zCCAd+gAwIBAgIJAJMnVnhVhy5pMA0GCSqGSIb3DQEBCwUAMBIxEDAOBgNV - > ...... - > QHwi1rNc8eBLNrd4BM/A1ZeDVh/Q9KxN+ZG/hHIXhmWKgN5wQx6/81FIFg== - > -----END CERTIFICATE----- - > ``` - -5. Move the modified `node-config.yaml` to your Kubernetes node machine and install and configure CoreOS on the node using the following command. - - > **Warning:** this is a destructive operation that erases disk `sda` on your server. - - ```shell - sudo coreos-install -d /dev/sda -C stable -c node-config.yaml - ``` - -6. Once complete, restart the server and boot into `/dev/sda`. When it comes back up, you should have SSH access as the `core` user using the public key provided in the `node-config.yaml` file. It will take some time for the node to be fully configured. - -## Configure Kubeconfig - -To administer your cluster from a separate host, you will need the client and admin certificates generated earlier (`ca.pem`, `admin.pem`, `admin-key.pem`). With certificates in place, run the following commands with the appropriate filepaths. - -```shell -kubectl config set-cluster calico-cluster --server=https:// --certificate-authority= -kubectl config set-credentials calico-admin --certificate-authority= --client-key= --client-certificate= -kubectl config set-context calico --cluster=calico-cluster --user=calico-admin -kubectl config use-context calico -``` - -Check your work with `kubectl get nodes`. - -## Install the DNS Addon - -Most Kubernetes deployments will require the DNS addon for service discovery. To install DNS, create the skydns service and replication controller provided. - -```shell -kubectl create -f https://raw.githubusercontent.com/projectcalico/calico-cni/k8s-1.1-docs/samples/kubernetes/master/dns/skydns.yaml -``` - -## Install the Kubernetes UI Addon (Optional) - -The Kubernetes UI can be installed using `kubectl` to run the following manifest file. - -```shell -kubectl create -f https://raw.githubusercontent.com/projectcalico/calico-cni/k8s-1.1-docs/samples/kubernetes/master/kube-ui/kube-ui.yaml -``` - -## Launch other Services With Calico-Kubernetes - -At this point, you have a fully functioning cluster running on Kubernetes with a master and two nodes networked with Calico. You can now follow any of the [standard documentation](https://github.com/kubernetes/kubernetes/tree/{{page.version}}.0/examples/) to set up other services on your cluster. - -## Connectivity to outside the cluster - -Because containers in this guide have private `192.168.0.0/16` IPs, you will need NAT to allow connectivity between containers and the internet. However, in a production data center deployment, NAT is not always necessary, since Calico can peer with the data center's border routers over BGP. - -### NAT on the nodes - -The simplest method for enabling connectivity from containers to the internet is to use outgoing NAT on your Kubernetes nodes. - -Calico can provide outgoing NAT for containers. To enable it, use the following `calicoctl` command: - -```shell -ETCD_AUTHORITY= calicoctl pool add --nat-outgoing -``` - -By default, `` will be `192.168.0.0/16`. You can find out which pools have been configured with the following command: - -```shell -ETCD_AUTHORITY= calicoctl pool show -``` - -### NAT at the border router - -In a data center environment, it is recommended to configure Calico to peer with the border routers over BGP. This means that the container IPs will be routable anywhere in the data center, and so NAT is not needed on the nodes (though it may be enabled at the data center edge to allow outbound-only internet connectivity). - -The Calico documentation contains more information on how to configure Calico to [peer with existing infrastructure](https://github.com/projectcalico/calico-containers/blob/master/docs/ExternalConnectivity.md). - -## Support Level - - -IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level --------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- -Bare-metal | CoreOS | CoreOS | Calico | [docs](/docs/getting-started-guides/coreos/bare_metal_calico) | | Community ([@caseydavenport](https://github.com/caseydavenport)) - - -For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions) chart. - +--- + +--- + +This document describes how to deploy Kubernetes with Calico networking on _bare metal_ CoreOS. For more information on Project Calico, visit [projectcalico.org](http://projectcalico.org) and the [calico-containers repository](https://github.com/projectcalico/calico-containers). + +To install Calico on an existing Kubernetes cluster, or for more information on deploying Calico with Kubernetes in a number of other environments take a look at our supported [deployment guides](https://github.com/projectcalico/calico-containers/tree/master/docs/cni/kubernetes). + +Specifically, this guide will have you do the following: + +- Deploy a Kubernetes master node on CoreOS using cloud-config. +- Deploy two Kubernetes compute nodes with Calico Networking using cloud-config. +- Configure `kubectl` to access your cluster. + +The resulting cluster will use SSL between Kubernetes components. It will run the SkyDNS service and kube-ui, and be fully conformant with the Kubernetes v1.1 conformance tests. + +## Prerequisites and Assumptions + +- At least three bare-metal machines (or VMs) to work with. This guide will configure them as follows: + - 1 Kubernetes Master + - 2 Kubernetes Nodes +- Your nodes should have IP connectivity to each other and the internet. +- This guide assumes a DHCP server on your network to assign server IPs. +- This guide uses `192.168.0.0/16` as the subnet from which pod IP addresses are assigned. If this overlaps with your host subnet, you will need to configure Calico to use a different [IP pool](https://github.com/projectcalico/calico-containers/blob/master/docs/calicoctl/pool.md#calicoctl-pool-commands). + +## Cloud-config + +This guide will use [cloud-config](https://coreos.com/docs/cluster-management/setup/cloudinit-cloud-config/) to configure each of the nodes in our Kubernetes cluster. + +We'll use two cloud-config files: +- `master-config.yaml`: cloud-config for the Kubernetes master +- `node-config.yaml`: cloud-config for each Kubernetes node + +## Download CoreOS + +Download the stable CoreOS bootable ISO from the [CoreOS website](https://coreos.com/docs/running-coreos/platforms/iso/). + +## Configure the Kubernetes Master + +1. Once you've downloaded the ISO image, burn the ISO to a CD/DVD/USB key and boot from it (if using a virtual machine you can boot directly from the ISO). Once booted, you should be automatically logged in as the `core` user at the terminal. At this point CoreOS is running from the ISO and it hasn't been installed yet. + +2. *On another machine*, download the [master cloud-config template](https://raw.githubusercontent.com/projectcalico/calico-cni/k8s-1.1-docs/samples/kubernetes/cloud-config/master-config-template.yaml) and save it as `master-config.yaml`. + +3. Replace the following variables in the `master-config.yaml` file. + + - ``: The public key you will use for SSH access to this server. See [generating ssh keys](https://help.github.com/articles/generating-ssh-keys/) + +4. Copy the edited `master-config.yaml` to your Kubernetes master machine (using a USB stick, for example). + +5. The CoreOS bootable ISO comes with a tool called `coreos-install` which will allow us to install CoreOS and configure the machine using a cloud-config file. The following command will download and install stable CoreOS using the `master-config.yaml` file we just created for configuration. Run this on the Kubernetes master. + + > **Warning:** this is a destructive operation that erases disk `sda` on your server. + + ```shell + sudo coreos-install -d /dev/sda -C stable -c master-config.yaml + ``` + +6. Once complete, restart the server and boot from `/dev/sda` (you may need to remove the ISO image). When it comes back up, you should have SSH access as the `core` user using the public key provided in the `master-config.yaml` file. + +### Configure TLS + +The master requires the CA certificate, `ca.pem`; its own certificate, `apiserver.pem` and its private key, `apiserver-key.pem`. This [CoreOS guide](https://coreos.com/kubernetes/docs/latest/openssl.html) explains how to generate these. + +1. Generate the necessary certificates for the master. This [guide for generating Kubernetes TLS Assets](https://coreos.com/kubernetes/docs/latest/openssl.html) explains how to use OpenSSL to generate the required assets. + +2. Send the three files to your master host (using `scp` for example). + +3. Move them to the `/etc/kubernetes/ssl` folder and ensure that only the root user can read the key: + + ```shell + # Move keys + sudo mkdir -p /etc/kubernetes/ssl/ + sudo mv -t /etc/kubernetes/ssl/ ca.pem apiserver.pem apiserver-key.pem + + # Set Permissions + sudo chmod 600 /etc/kubernetes/ssl/apiserver-key.pem + sudo chown root:root /etc/kubernetes/ssl/apiserver-key.pem + ``` + +4. Restart the kubelet to pick up the changes: + + ```shell + sudo systemctl restart kubelet + ``` + +## Configure the compute nodes + +The following steps will set up a single Kubernetes node for use as a compute host. Run these steps to deploy each Kubernetes node in your cluster. + +1. Boot up the node machine using the bootable ISO we downloaded earlier. You should be automatically logged in as the `core` user. + +2. Make a copy of the [node cloud-config template](https://raw.githubusercontent.com/projectcalico/calico-cni/k8s-1.1-docs/samples/kubernetes/cloud-config/node-config-template.yaml) for this machine. + +3. Replace the following placeholders in the `node-config.yaml` file to match your deployment. + + - ``: Hostname for this node (e.g. kube-node1, kube-node2) + - ``: The public key you will use for SSH access to this server. + - ``: The IPv4 address of the Kubernetes master. + +4. Replace the following placeholders with the contents of their respective files. + + - ``: Complete contents of `ca.pem` + - ``: Complete contents of `ca-key.pem` + + > **Important:** in a production deployment, embedding the secret key in cloud-config is a bad idea! In production you should use an appropriate secret manager. + + > **Important:** Make sure you indent the entire file to match the indentation of the placeholder. For example: + > + > ```shell + > - path: /etc/kubernetes/ssl/ca.pem + > owner: core + > permissions: 0644 + > content: | + > + > ``` + > + > should look like this once the certificate is in place: + > + > ```shell + > - path: /etc/kubernetes/ssl/ca.pem + > owner: core + > permissions: 0644 + > content: | + > -----BEGIN CERTIFICATE----- + > MIIC9zCCAd+gAwIBAgIJAJMnVnhVhy5pMA0GCSqGSIb3DQEBCwUAMBIxEDAOBgNV + > ...... + > QHwi1rNc8eBLNrd4BM/A1ZeDVh/Q9KxN+ZG/hHIXhmWKgN5wQx6/81FIFg== + > -----END CERTIFICATE----- + > ``` + +5. Move the modified `node-config.yaml` to your Kubernetes node machine and install and configure CoreOS on the node using the following command. + + > **Warning:** this is a destructive operation that erases disk `sda` on your server. + + ```shell + sudo coreos-install -d /dev/sda -C stable -c node-config.yaml + ``` + +6. Once complete, restart the server and boot into `/dev/sda`. When it comes back up, you should have SSH access as the `core` user using the public key provided in the `node-config.yaml` file. It will take some time for the node to be fully configured. + +## Configure Kubeconfig + +To administer your cluster from a separate host, you will need the client and admin certificates generated earlier (`ca.pem`, `admin.pem`, `admin-key.pem`). With certificates in place, run the following commands with the appropriate filepaths. + +```shell +kubectl config set-cluster calico-cluster --server=https:// --certificate-authority= +kubectl config set-credentials calico-admin --certificate-authority= --client-key= --client-certificate= +kubectl config set-context calico --cluster=calico-cluster --user=calico-admin +kubectl config use-context calico +``` + +Check your work with `kubectl get nodes`. + +## Install the DNS Addon + +Most Kubernetes deployments will require the DNS addon for service discovery. To install DNS, create the skydns service and replication controller provided. + +```shell +kubectl create -f https://raw.githubusercontent.com/projectcalico/calico-cni/k8s-1.1-docs/samples/kubernetes/master/dns/skydns.yaml +``` + +## Install the Kubernetes UI Addon (Optional) + +The Kubernetes UI can be installed using `kubectl` to run the following manifest file. + +```shell +kubectl create -f https://raw.githubusercontent.com/projectcalico/calico-cni/k8s-1.1-docs/samples/kubernetes/master/kube-ui/kube-ui.yaml +``` + +## Launch other Services With Calico-Kubernetes + +At this point, you have a fully functioning cluster running on Kubernetes with a master and two nodes networked with Calico. You can now follow any of the [standard documentation](https://github.com/kubernetes/kubernetes/tree/{{page.version}}.0/examples/) to set up other services on your cluster. + +## Connectivity to outside the cluster + +Because containers in this guide have private `192.168.0.0/16` IPs, you will need NAT to allow connectivity between containers and the internet. However, in a production data center deployment, NAT is not always necessary, since Calico can peer with the data center's border routers over BGP. + +### NAT on the nodes + +The simplest method for enabling connectivity from containers to the internet is to use outgoing NAT on your Kubernetes nodes. + +Calico can provide outgoing NAT for containers. To enable it, use the following `calicoctl` command: + +```shell +ETCD_AUTHORITY= calicoctl pool add --nat-outgoing +``` + +By default, `` will be `192.168.0.0/16`. You can find out which pools have been configured with the following command: + +```shell +ETCD_AUTHORITY= calicoctl pool show +``` + +### NAT at the border router + +In a data center environment, it is recommended to configure Calico to peer with the border routers over BGP. This means that the container IPs will be routable anywhere in the data center, and so NAT is not needed on the nodes (though it may be enabled at the data center edge to allow outbound-only internet connectivity). + +The Calico documentation contains more information on how to configure Calico to [peer with existing infrastructure](https://github.com/projectcalico/calico-containers/blob/master/docs/ExternalConnectivity.md). + +## Support Level + + +IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level +-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- +Bare-metal | CoreOS | CoreOS | Calico | [docs](/docs/getting-started-guides/coreos/bare_metal_calico) | | Community ([@caseydavenport](https://github.com/caseydavenport)) + + +For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions) chart. + diff --git a/docs/getting-started-guides/docker-multinode.md b/docs/getting-started-guides/docker-multinode.md index 14e475ee10..5d6d4ee295 100644 --- a/docs/getting-started-guides/docker-multinode.md +++ b/docs/getting-started-guides/docker-multinode.md @@ -16,7 +16,7 @@ and a _worker_ node which receives work from the master. You can repeat the proc times to create larger clusters. Here's a diagram of what the final result will look like: -![Kubernetes on Docker](https://github.com/kubernetes/kubernetes/blob/master/docs/getting-started-guides/k8s-docker.png) +![Kubernetes on Docker](/images/docs/k8s-docker.png) ### Bootstrap Docker @@ -86,7 +86,7 @@ Clone the `kube-deploy` repo, and run `worker.sh` on the worker machine _with ro ```shell $ git clone https://github.com/kubernetes/kube-deploy -$ cd docker-multinode +$ cd kube-deploy/docker-multinode $ export MASTER_IP=${SOME_IP} $ ./worker.sh ``` diff --git a/docs/getting-started-guides/fedora/fedora_ansible_config.md b/docs/getting-started-guides/fedora/fedora_ansible_config.md index aa439f07b0..b5fe3802e0 100644 --- a/docs/getting-started-guides/fedora/fedora_ansible_config.md +++ b/docs/getting-started-guides/fedora/fedora_ansible_config.md @@ -1,241 +1,241 @@ ---- -assignees: -- aveshagarwal -- erictune - ---- - -Configuring Kubernetes on Fedora via Ansible offers a simple way to quickly create a clustered environment with little effort. - -* TOC -{:toc} - -## Prerequisites - -1. Host able to run ansible and able to clone the following repo: [kubernetes](https://github.com/kubernetes/kubernetes.git) -2. A Fedora 21+ host to act as cluster master -3. As many Fedora 21+ hosts as you would like, that act as cluster nodes - -The hosts can be virtual or bare metal. Ansible will take care of the rest of the configuration for you - configuring networking, installing packages, handling the firewall, etc. This example will use one master and two nodes. - -## Architecture of the cluster - -A Kubernetes cluster requires etcd, a master, and n nodes, so we will create a cluster with three hosts, for example: - -```shell -master,etcd = kube-master.example.com - node1 = kube-node-01.example.com - node2 = kube-node-02.example.com -``` - -**Make sure your local machine has** - - - ansible (must be 1.9.0+) - - git - - python-netaddr - -If not - -```shell -yum install -y ansible git python-netaddr -``` - -**Now clone down the Kubernetes repository** - -```shell -git clone https://github.com/kubernetes/contrib.git -cd contrib/ansible -``` - -**Tell ansible about each machine and its role in your cluster** - -Get the IP addresses from the master and nodes. Add those to the `~/contrib/ansible/inventory` file on the host running Ansible. - -```shell -[masters] -kube-master.example.com - -[etcd] -kube-master.example.com - -[nodes] -kube-node-01.example.com -kube-node-02.example.com -``` - -## Setting up ansible access to your nodes - -If you already are running on a machine which has passwordless ssh access to the kube-master and kube-node-{01,02} nodes, and 'sudo' privileges, simply set the value of `ansible_ssh_user` in `~/contrib/ansible/group_vars/all.yml` to the username which you use to ssh to the nodes (i.e. `fedora`), and proceed to the next step... - -*Otherwise* setup ssh on the machines like so (you will need to know the root password to all machines in the cluster). - -edit: ~/contrib/ansible/group_vars/all.yml - -```yaml -ansible_ssh_user: root -``` - -**Configuring ssh access to the cluster** - -If you already have ssh access to every machine using ssh public keys you may skip to [setting up the cluster](#setting-up-the-cluster) - -Make sure your local machine (root) has an ssh key pair if not - -```shell -ssh-keygen -``` - -Copy the ssh public key to **all** nodes in the cluster - -```shell -for node in kube-master.example.com kube-node-01.example.com kube-node-02.example.com; do - ssh-copy-id ${node} -done -``` - -## Setting up the cluster - -Although the default value of variables in `~/contrib/ansible/group_vars/all.yml` should be good enough, if not, change them as needed. - -```conf -edit: ~/contrib/ansible/group_vars/all.yml -``` - -**Configure access to kubernetes packages** - -Modify `source_type` as below to access kubernetes packages through the package manager. - -```yaml -source_type: packageManager -``` - -**Configure the IP addresses used for services** - -Each Kubernetes service gets its own IP address. These are not real IPs. You need only select a range of IPs which are not in use elsewhere in your environment. - -```yaml -kube_service_addresses: 10.254.0.0/16 -``` - -**Managing flannel** - -Modify `flannel_subnet`, `flannel_prefix` and `flannel_host_prefix` only if defaults are not appropriate for your cluster. - - -**Managing add on services in your cluster** - -Set `cluster_logging` to false or true (default) to disable or enable logging with elasticsearch. - -```yaml -cluster_logging: true -``` - -Turn `cluster_monitoring` to true (default) or false to enable or disable cluster monitoring with heapster and influxdb. - -```yaml -cluster_monitoring: true -``` - -Turn `dns_setup` to true (recommended) or false to enable or disable whole DNS configuration. - -```yaml -dns_setup: true -``` - -**Tell ansible to get to work!** - -This will finally setup your whole Kubernetes cluster for you. - -```shell -cd ~/contrib/ansible/ - -./setup.sh -``` - -## Testing and using your new cluster - -That's all there is to it. It's really that easy. At this point you should have a functioning Kubernetes cluster. - -**Show kubernetes nodes** - -Run the following on the kube-master: - -```shell -kubectl get nodes -``` - -**Show services running on masters and nodes** - -```shell -systemctl | grep -i kube -``` - -**Show firewall rules on the masters and nodes** - -```shell -iptables -nvL - -``` - -**Create /tmp/apache.json on the master with the following contents and deploy pod** - -```json -{ - "kind": "Pod", - "apiVersion": "v1", - "metadata": { - "name": "fedoraapache", - "labels": { - "name": "fedoraapache" - } - }, - "spec": { - "containers": [ - { - "name": "fedoraapache", - "image": "fedora/apache", - "ports": [ - { - "hostPort": 80, - "containerPort": 80 - } - ] - } - ] - } -} -``` - -```shell -kubectl create -f /tmp/apache.json -``` - -**Check where the pod was created** - -```shell -kubectl get pods -``` - -**Check Docker status on nodes** - -```shell -docker ps -docker images -``` - -**After the pod is 'Running' Check web server access on the node** - -```shell -curl http://localhost -``` - -That's it ! - -## Support Level - - -IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level --------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- -Bare-metal | Ansible | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/fedora_ansible_config) | | Project - -For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions) chart. +--- +assignees: +- aveshagarwal +- erictune + +--- + +Configuring Kubernetes on Fedora via Ansible offers a simple way to quickly create a clustered environment with little effort. + +* TOC +{:toc} + +## Prerequisites + +1. Host able to run ansible and able to clone the following repo: [kubernetes](https://github.com/kubernetes/kubernetes.git) +2. A Fedora 21+ host to act as cluster master +3. As many Fedora 21+ hosts as you would like, that act as cluster nodes + +The hosts can be virtual or bare metal. Ansible will take care of the rest of the configuration for you - configuring networking, installing packages, handling the firewall, etc. This example will use one master and two nodes. + +## Architecture of the cluster + +A Kubernetes cluster requires etcd, a master, and n nodes, so we will create a cluster with three hosts, for example: + +```shell +master,etcd = kube-master.example.com + node1 = kube-node-01.example.com + node2 = kube-node-02.example.com +``` + +**Make sure your local machine has** + + - ansible (must be 1.9.0+) + - git + - python-netaddr + +If not + +```shell +yum install -y ansible git python-netaddr +``` + +**Now clone down the Kubernetes repository** + +```shell +git clone https://github.com/kubernetes/contrib.git +cd contrib/ansible +``` + +**Tell ansible about each machine and its role in your cluster** + +Get the IP addresses from the master and nodes. Add those to the `~/contrib/ansible/inventory` file on the host running Ansible. + +```shell +[masters] +kube-master.example.com + +[etcd] +kube-master.example.com + +[nodes] +kube-node-01.example.com +kube-node-02.example.com +``` + +## Setting up ansible access to your nodes + +If you already are running on a machine which has passwordless ssh access to the kube-master and kube-node-{01,02} nodes, and 'sudo' privileges, simply set the value of `ansible_ssh_user` in `~/contrib/ansible/group_vars/all.yml` to the username which you use to ssh to the nodes (i.e. `fedora`), and proceed to the next step... + +*Otherwise* setup ssh on the machines like so (you will need to know the root password to all machines in the cluster). + +edit: ~/contrib/ansible/group_vars/all.yml + +```yaml +ansible_ssh_user: root +``` + +**Configuring ssh access to the cluster** + +If you already have ssh access to every machine using ssh public keys you may skip to [setting up the cluster](#setting-up-the-cluster) + +Make sure your local machine (root) has an ssh key pair if not + +```shell +ssh-keygen +``` + +Copy the ssh public key to **all** nodes in the cluster + +```shell +for node in kube-master.example.com kube-node-01.example.com kube-node-02.example.com; do + ssh-copy-id ${node} +done +``` + +## Setting up the cluster + +Although the default value of variables in `~/contrib/ansible/group_vars/all.yml` should be good enough, if not, change them as needed. + +```conf +edit: ~/contrib/ansible/group_vars/all.yml +``` + +**Configure access to kubernetes packages** + +Modify `source_type` as below to access kubernetes packages through the package manager. + +```yaml +source_type: packageManager +``` + +**Configure the IP addresses used for services** + +Each Kubernetes service gets its own IP address. These are not real IPs. You need only select a range of IPs which are not in use elsewhere in your environment. + +```yaml +kube_service_addresses: 10.254.0.0/16 +``` + +**Managing flannel** + +Modify `flannel_subnet`, `flannel_prefix` and `flannel_host_prefix` only if defaults are not appropriate for your cluster. + + +**Managing add on services in your cluster** + +Set `cluster_logging` to false or true (default) to disable or enable logging with elasticsearch. + +```yaml +cluster_logging: true +``` + +Turn `cluster_monitoring` to true (default) or false to enable or disable cluster monitoring with heapster and influxdb. + +```yaml +cluster_monitoring: true +``` + +Turn `dns_setup` to true (recommended) or false to enable or disable whole DNS configuration. + +```yaml +dns_setup: true +``` + +**Tell ansible to get to work!** + +This will finally setup your whole Kubernetes cluster for you. + +```shell +cd ~/contrib/ansible/ + +./setup.sh +``` + +## Testing and using your new cluster + +That's all there is to it. It's really that easy. At this point you should have a functioning Kubernetes cluster. + +**Show kubernetes nodes** + +Run the following on the kube-master: + +```shell +kubectl get nodes +``` + +**Show services running on masters and nodes** + +```shell +systemctl | grep -i kube +``` + +**Show firewall rules on the masters and nodes** + +```shell +iptables -nvL + +``` + +**Create /tmp/apache.json on the master with the following contents and deploy pod** + +```json +{ + "kind": "Pod", + "apiVersion": "v1", + "metadata": { + "name": "fedoraapache", + "labels": { + "name": "fedoraapache" + } + }, + "spec": { + "containers": [ + { + "name": "fedoraapache", + "image": "fedora/apache", + "ports": [ + { + "hostPort": 80, + "containerPort": 80 + } + ] + } + ] + } +} +``` + +```shell +kubectl create -f /tmp/apache.json +``` + +**Check where the pod was created** + +```shell +kubectl get pods +``` + +**Check Docker status on nodes** + +```shell +docker ps +docker images +``` + +**After the pod is 'Running' Check web server access on the node** + +```shell +curl http://localhost +``` + +That's it ! + +## Support Level + + +IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level +-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- +Bare-metal | Ansible | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/fedora_ansible_config) | | Project + +For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions) chart. diff --git a/docs/getting-started-guides/fedora/fedora_manual_config.md b/docs/getting-started-guides/fedora/fedora_manual_config.md index 238498d18c..d1948530a8 100644 --- a/docs/getting-started-guides/fedora/fedora_manual_config.md +++ b/docs/getting-started-guides/fedora/fedora_manual_config.md @@ -1,219 +1,219 @@ ---- -assignees: -- aveshagarwal -- eparis -- thockin - ---- - -* TOC -{:toc} - -## Prerequisites - -1. You need 2 or more machines with Fedora installed. - -## Instructions - -This is a getting started guide for Fedora. It is a manual configuration so you understand all the underlying packages / services / ports, etc... - -This guide will only get ONE node (previously minion) working. Multiple nodes require a functional [networking configuration](/docs/admin/networking/) done outside of Kubernetes. Although the additional Kubernetes configuration requirements should be obvious. - -The Kubernetes package provides a few services: kube-apiserver, kube-scheduler, kube-controller-manager, kubelet, kube-proxy. These services are managed by systemd and the configuration resides in a central location: /etc/kubernetes. We will break the services up between the hosts. The first host, fed-master, will be the Kubernetes master. This host will run the kube-apiserver, kube-controller-manager, and kube-scheduler. In addition, the master will also run _etcd_ (not needed if _etcd_ runs on a different host but this guide assumes that _etcd_ and Kubernetes master run on the same host). The remaining host, fed-node will be the node and run kubelet, proxy and docker. - -**System Information:** - -Hosts: - -```conf -fed-master = 192.168.121.9 -fed-node = 192.168.121.65 -``` - -**Prepare the hosts:** - -* Install Kubernetes on all hosts - fed-{master,node}. This will also pull in docker. Also install etcd on fed-master. This guide has been tested with kubernetes-0.18 and beyond. -* The [--enablerepo=updates-testing](https://fedoraproject.org/wiki/QA:Updates_Testing) directive in the yum command below will ensure that the most recent Kubernetes version that is scheduled for pre-release will be installed. This should be a more recent version than the Fedora "stable" release for Kubernetes that you would get without adding the directive. -* If you want the very latest Kubernetes release [you can download and yum install the RPM directly from Fedora Koji](http://koji.fedoraproject.org/koji/packageinfo?packageID=19202) instead of using the yum install command below. -* Running on AWS EC2 with RHEL 7.2, you need to enable "extras" repository for yum by editing `/etc/yum.repos.d/redhat-rhui.repo` and changing the changing the `enable=0` to `enable=1` for extras. - -```shell -yum -y install --enablerepo=updates-testing kubernetes -``` - -* Install etcd and iptables - -```shell -yum -y install etcd iptables -``` - -* Add master and node to /etc/hosts on all machines (not needed if hostnames already in DNS). Make sure that communication works between fed-master and fed-node by using a utility such as ping. - -```shell -echo "192.168.121.9 fed-master -192.168.121.65 fed-node" >> /etc/hosts -``` - -* Edit /etc/kubernetes/config which will be the same on all hosts (master and node) to contain: - -```shell -# Comma separated list of nodes in the etcd cluster -KUBE_MASTER="--master=http://fed-master:8080" - -# logging to stderr means we get it in the systemd journal -KUBE_LOGTOSTDERR="--logtostderr=true" - -# journal message level, 0 is debug -KUBE_LOG_LEVEL="--v=0" - -# Should this cluster be allowed to run privileged docker containers -KUBE_ALLOW_PRIV="--allow-privileged=false" -``` - -* Disable the firewall on both the master and node, as docker does not play well with other firewall rule managers. Please note that iptables-services does not exist on default fedora server install. - -```shell -systemctl disable iptables-services firewalld -systemctl stop iptables-services firewalld -``` - -**Configure the Kubernetes services on the master.** - -* Edit /etc/kubernetes/apiserver to appear as such. The service-cluster-ip-range IP addresses must be an unused block of addresses, not used anywhere else. They do not need to be routed or assigned to anything. - -```shell -# The address on the local server to listen to. -KUBE_API_ADDRESS="--address=0.0.0.0" - -# Comma separated list of nodes in the etcd cluster -KUBE_ETCD_SERVERS="--etcd-servers=http://127.0.0.1:4001" - -# Address range to use for services -KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16" - -# Add your own! -KUBE_API_ARGS="" -``` - -* Edit /etc/etcd/etcd.conf,let the etcd to listen all the ip instead of 127.0.0.1, if not, you will get the error like "connection refused". Note that Fedora 22 uses etcd 2.0, One of the changes in etcd 2.0 is that now uses port 2379 and 2380 (as opposed to etcd 0.46 which userd 4001 and 7001). - -```shell -ETCD_LISTEN_CLIENT_URLS="http://0.0.0.0:4001" -``` - -* Create /var/run/kubernetes on master: - -```shell -mkdir /var/run/kubernetes -chown kube:kube /var/run/kubernetes -chmod 750 /var/run/kubernetes -``` - -* Start the appropriate services on master: - -```shell -for SERVICES in etcd kube-apiserver kube-controller-manager kube-scheduler; do - systemctl restart $SERVICES - systemctl enable $SERVICES - systemctl status $SERVICES -done -``` - -* Addition of nodes: - -* Create following node.json file on Kubernetes master node: - -```json -{ - "apiVersion": "v1", - "kind": "Node", - "metadata": { - "name": "fed-node", - "labels":{ "name": "fed-node-label"} - }, - "spec": { - "externalID": "fed-node" - } -} -``` - -Now create a node object internally in your Kubernetes cluster by running: - -```shell -$ kubectl create -f ./node.json - -$ kubectl get nodes -NAME LABELS STATUS -fed-node name=fed-node-label Unknown -``` - -Please note that in the above, it only creates a representation for the node -_fed-node_ internally. It does not provision the actual _fed-node_. Also, it -is assumed that _fed-node_ (as specified in `name`) can be resolved and is -reachable from Kubernetes master node. This guide will discuss how to provision -a Kubernetes node (fed-node) below. - -**Configure the Kubernetes services on the node.** - -***We need to configure the kubelet on the node.*** - -* Edit /etc/kubernetes/kubelet to appear as such: - -```shell -### -# Kubernetes kubelet (node) config - -# The address for the info server to serve on (set to 0.0.0.0 or "" for all interfaces) -KUBELET_ADDRESS="--address=0.0.0.0" - -# You may leave this blank to use the actual hostname -KUBELET_HOSTNAME="--hostname-override=fed-node" - -# location of the api-server -KUBELET_API_SERVER="--api-servers=http://fed-master:8080" - -# Add your own! -#KUBELET_ARGS="" -``` - -* Start the appropriate services on the node (fed-node). - -```shell -for SERVICES in kube-proxy kubelet docker; do - systemctl restart $SERVICES - systemctl enable $SERVICES - systemctl status $SERVICES -done -``` - -* Check to make sure now the cluster can see the fed-node on fed-master, and its status changes to _Ready_. - -```shell -kubectl get nodes -NAME LABELS STATUS -fed-node name=fed-node-label Ready -``` - -* Deletion of nodes: - -To delete _fed-node_ from your Kubernetes cluster, one should run the following on fed-master (Please do not do it, it is just for information): - -```shell -kubectl delete -f ./node.json -``` - -*You should be finished!* - -**The cluster should be running! Launch a test pod.** - -You should have a functional cluster, check out [101](/docs/user-guide/walkthrough/)! - -## Support Level - - -IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level --------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- -Bare-metal | custom | Fedora | _none_ | [docs](/docs/getting-started-guides/fedora/fedora_manual_config) | | Project - -For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions) chart. - +--- +assignees: +- aveshagarwal +- eparis +- thockin + +--- + +* TOC +{:toc} + +## Prerequisites + +1. You need 2 or more machines with Fedora installed. + +## Instructions + +This is a getting started guide for Fedora. It is a manual configuration so you understand all the underlying packages / services / ports, etc... + +This guide will only get ONE node (previously minion) working. Multiple nodes require a functional [networking configuration](/docs/admin/networking/) done outside of Kubernetes. Although the additional Kubernetes configuration requirements should be obvious. + +The Kubernetes package provides a few services: kube-apiserver, kube-scheduler, kube-controller-manager, kubelet, kube-proxy. These services are managed by systemd and the configuration resides in a central location: /etc/kubernetes. We will break the services up between the hosts. The first host, fed-master, will be the Kubernetes master. This host will run the kube-apiserver, kube-controller-manager, and kube-scheduler. In addition, the master will also run _etcd_ (not needed if _etcd_ runs on a different host but this guide assumes that _etcd_ and Kubernetes master run on the same host). The remaining host, fed-node will be the node and run kubelet, proxy and docker. + +**System Information:** + +Hosts: + +```conf +fed-master = 192.168.121.9 +fed-node = 192.168.121.65 +``` + +**Prepare the hosts:** + +* Install Kubernetes on all hosts - fed-{master,node}. This will also pull in docker. Also install etcd on fed-master. This guide has been tested with kubernetes-0.18 and beyond. +* The [--enablerepo=updates-testing](https://fedoraproject.org/wiki/QA:Updates_Testing) directive in the yum command below will ensure that the most recent Kubernetes version that is scheduled for pre-release will be installed. This should be a more recent version than the Fedora "stable" release for Kubernetes that you would get without adding the directive. +* If you want the very latest Kubernetes release [you can download and yum install the RPM directly from Fedora Koji](http://koji.fedoraproject.org/koji/packageinfo?packageID=19202) instead of using the yum install command below. +* Running on AWS EC2 with RHEL 7.2, you need to enable "extras" repository for yum by editing `/etc/yum.repos.d/redhat-rhui.repo` and changing the changing the `enable=0` to `enable=1` for extras. + +```shell +yum -y install --enablerepo=updates-testing kubernetes +``` + +* Install etcd and iptables + +```shell +yum -y install etcd iptables +``` + +* Add master and node to /etc/hosts on all machines (not needed if hostnames already in DNS). Make sure that communication works between fed-master and fed-node by using a utility such as ping. + +```shell +echo "192.168.121.9 fed-master +192.168.121.65 fed-node" >> /etc/hosts +``` + +* Edit /etc/kubernetes/config which will be the same on all hosts (master and node) to contain: + +```shell +# Comma separated list of nodes in the etcd cluster +KUBE_MASTER="--master=http://fed-master:8080" + +# logging to stderr means we get it in the systemd journal +KUBE_LOGTOSTDERR="--logtostderr=true" + +# journal message level, 0 is debug +KUBE_LOG_LEVEL="--v=0" + +# Should this cluster be allowed to run privileged docker containers +KUBE_ALLOW_PRIV="--allow-privileged=false" +``` + +* Disable the firewall on both the master and node, as docker does not play well with other firewall rule managers. Please note that iptables-services does not exist on default fedora server install. + +```shell +systemctl disable iptables-services firewalld +systemctl stop iptables-services firewalld +``` + +**Configure the Kubernetes services on the master.** + +* Edit /etc/kubernetes/apiserver to appear as such. The service-cluster-ip-range IP addresses must be an unused block of addresses, not used anywhere else. They do not need to be routed or assigned to anything. + +```shell +# The address on the local server to listen to. +KUBE_API_ADDRESS="--address=0.0.0.0" + +# Comma separated list of nodes in the etcd cluster +KUBE_ETCD_SERVERS="--etcd-servers=http://127.0.0.1:4001" + +# Address range to use for services +KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16" + +# Add your own! +KUBE_API_ARGS="" +``` + +* Edit /etc/etcd/etcd.conf,let the etcd to listen all the ip instead of 127.0.0.1, if not, you will get the error like "connection refused". Note that Fedora 22 uses etcd 2.0, One of the changes in etcd 2.0 is that now uses port 2379 and 2380 (as opposed to etcd 0.46 which userd 4001 and 7001). + +```shell +ETCD_LISTEN_CLIENT_URLS="http://0.0.0.0:4001" +``` + +* Create /var/run/kubernetes on master: + +```shell +mkdir /var/run/kubernetes +chown kube:kube /var/run/kubernetes +chmod 750 /var/run/kubernetes +``` + +* Start the appropriate services on master: + +```shell +for SERVICES in etcd kube-apiserver kube-controller-manager kube-scheduler; do + systemctl restart $SERVICES + systemctl enable $SERVICES + systemctl status $SERVICES +done +``` + +* Addition of nodes: + +* Create following node.json file on Kubernetes master node: + +```json +{ + "apiVersion": "v1", + "kind": "Node", + "metadata": { + "name": "fed-node", + "labels":{ "name": "fed-node-label"} + }, + "spec": { + "externalID": "fed-node" + } +} +``` + +Now create a node object internally in your Kubernetes cluster by running: + +```shell +$ kubectl create -f ./node.json + +$ kubectl get nodes +NAME LABELS STATUS +fed-node name=fed-node-label Unknown +``` + +Please note that in the above, it only creates a representation for the node +_fed-node_ internally. It does not provision the actual _fed-node_. Also, it +is assumed that _fed-node_ (as specified in `name`) can be resolved and is +reachable from Kubernetes master node. This guide will discuss how to provision +a Kubernetes node (fed-node) below. + +**Configure the Kubernetes services on the node.** + +***We need to configure the kubelet on the node.*** + +* Edit /etc/kubernetes/kubelet to appear as such: + +```shell +### +# Kubernetes kubelet (node) config + +# The address for the info server to serve on (set to 0.0.0.0 or "" for all interfaces) +KUBELET_ADDRESS="--address=0.0.0.0" + +# You may leave this blank to use the actual hostname +KUBELET_HOSTNAME="--hostname-override=fed-node" + +# location of the api-server +KUBELET_API_SERVER="--api-servers=http://fed-master:8080" + +# Add your own! +#KUBELET_ARGS="" +``` + +* Start the appropriate services on the node (fed-node). + +```shell +for SERVICES in kube-proxy kubelet docker; do + systemctl restart $SERVICES + systemctl enable $SERVICES + systemctl status $SERVICES +done +``` + +* Check to make sure now the cluster can see the fed-node on fed-master, and its status changes to _Ready_. + +```shell +kubectl get nodes +NAME LABELS STATUS +fed-node name=fed-node-label Ready +``` + +* Deletion of nodes: + +To delete _fed-node_ from your Kubernetes cluster, one should run the following on fed-master (Please do not do it, it is just for information): + +```shell +kubectl delete -f ./node.json +``` + +*You should be finished!* + +**The cluster should be running! Launch a test pod.** + +You should have a functional cluster, check out [101](/docs/user-guide/walkthrough/)! + +## Support Level + + +IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level +-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- +Bare-metal | custom | Fedora | _none_ | [docs](/docs/getting-started-guides/fedora/fedora_manual_config) | | Project + +For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions) chart. + diff --git a/docs/getting-started-guides/fedora/flannel_multi_node_cluster.md b/docs/getting-started-guides/fedora/flannel_multi_node_cluster.md index 7f4504f2c9..bcd10f57b9 100644 --- a/docs/getting-started-guides/fedora/flannel_multi_node_cluster.md +++ b/docs/getting-started-guides/fedora/flannel_multi_node_cluster.md @@ -1,191 +1,191 @@ ---- -assignees: -- dchen1107 -- erictune -- thockin - ---- -* TOC -{:toc} - -This document describes how to deploy Kubernetes on multiple hosts to set up a multi-node cluster and networking with flannel. Follow fedora [getting started guide](/docs/getting-started-guides/fedora/fedora_manual_config/) to setup 1 master (fed-master) and 2 or more nodes. Make sure that all nodes have different names (fed-node1, fed-node2 and so on) and labels (fed-node1-label, fed-node2-label, and so on) to avoid any conflict. Also make sure that the Kubernetes master host is running etcd, kube-controller-manager, kube-scheduler, and kube-apiserver services, and the nodes are running docker, kube-proxy and kubelet services. Now install flannel on Kubernetes nodes. flannel on each node configures an overlay network that docker uses. flannel runs on each node to setup a unique class-C container network. - -## Prerequisites - -You need 2 or more machines with Fedora installed. - -## Master Setup - -**Perform following commands on the Kubernetes master** - -* Configure flannel by creating a `flannel-config.json` in your current directory on fed-master. Flannel provides udp and vxlan among other overlay networking backend options. In this guide, we choose kernel based vxlan backend. The contents of the json are: - -```json -{ - "Network": "18.16.0.0/16", - "SubnetLen": 24, - "Backend": { - "Type": "vxlan", - "VNI": 1 - } -} -``` - -**NOTE:** Choose an IP range that is *NOT* part of the public IP address range. - -Add the configuration to the etcd server on fed-master. - -```shell -etcdctl set /coreos.com/network/config < flannel-config.json -``` - -* Verify the key exists in the etcd server on fed-master. - -```shell -etcdctl get /coreos.com/network/config -``` - -## Node Setup - -**Perform following commands on all Kubernetes nodes** - -Edit the flannel configuration file /etc/sysconfig/flanneld as follows: - -```shell -# Flanneld configuration options - -# etcd url location. Point this to the server where etcd runs -FLANNEL_ETCD="http://fed-master:4001" - -# etcd config key. This is the configuration key that flannel queries -# For address range assignment -FLANNEL_ETCD_KEY="/coreos.com/network" - -# Any additional options that you want to pass -FLANNEL_OPTIONS="" -``` - -**Note:** By default, flannel uses the interface for the default route. If you have multiple interfaces and would like to use an interface other than the default route one, you could add "-iface=" to FLANNEL_OPTIONS. For additional options, run `flanneld --help` on command line. - -Enable the flannel service. - -```shell -systemctl enable flanneld -``` - -If docker is not running, then starting flannel service is enough and skip the next step. - -```shell -systemctl start flanneld -``` - -If docker is already running, then stop docker, delete docker bridge (docker0), start flanneld and restart docker as follows. Another alternative is to just reboot the system (`systemctl reboot`). - -```shell -systemctl stop docker -ip link delete docker0 -systemctl start flanneld -systemctl start docker -``` - - -## **Test the cluster and flannel configuration** - -Now check the interfaces on the nodes. Notice there is now a flannel.1 interface, and the ip addresses of docker0 and flannel.1 interfaces are in the same network. You will notice that docker0 is assigned a subnet (18.16.29.0/24 as shown below) on each Kubernetes node out of the IP range configured above. A working output should look like this: - -```shell -# ip -4 a|grep inet - inet 127.0.0.1/8 scope host lo - inet 192.168.122.77/24 brd 192.168.122.255 scope global dynamic eth0 - inet 18.16.29.0/16 scope global flannel.1 - inet 18.16.29.1/24 scope global docker0 -``` - -From any node in the cluster, check the cluster members by issuing a query to etcd server via curl (only partial output is shown using `grep -E "\{|\}|key|value"`). If you set up a 1 master and 3 nodes cluster, you should see one block for each node showing the subnets they have been assigned. You can associate those subnets to each node by the MAC address (VtepMAC) and IP address (Public IP) that is listed in the output. - -```shell -curl -s http://fed-master:4001/v2/keys/coreos.com/network/subnets | python -mjson.tool -``` - -```json -{ - "node": { - "key": "/coreos.com/network/subnets", - { - "key": "/coreos.com/network/subnets/18.16.29.0-24", - "value": "{\"PublicIP\":\"192.168.122.77\",\"BackendType\":\"vxlan\",\"BackendData\":{\"VtepMAC\":\"46:f1:d0:18:d0:65\"}}" - }, - { - "key": "/coreos.com/network/subnets/18.16.83.0-24", - "value": "{\"PublicIP\":\"192.168.122.36\",\"BackendType\":\"vxlan\",\"BackendData\":{\"VtepMAC\":\"ca:38:78:fc:72:29\"}}" - }, - { - "key": "/coreos.com/network/subnets/18.16.90.0-24", - "value": "{\"PublicIP\":\"192.168.122.127\",\"BackendType\":\"vxlan\",\"BackendData\":{\"VtepMAC\":\"92:e2:80:ba:2d:4d\"}}" - } - } -} -``` - -From all nodes, review the `/run/flannel/subnet.env` file. This file was generated automatically by flannel. - -```shell -# cat /run/flannel/subnet.env -FLANNEL_SUBNET=18.16.29.1/24 -FLANNEL_MTU=1450 -FLANNEL_IPMASQ=false -``` - -At this point, we have etcd running on the Kubernetes master, and flannel / docker running on Kubernetes nodes. Next steps are for testing cross-host container communication which will confirm that docker and flannel are configured properly. - -Issue the following commands on any 2 nodes: - -```shell -# docker run -it fedora:latest bash -bash-4.3# -``` - -This will place you inside the container. Install iproute and iputils packages to install ip and ping utilities. Due to a [bug](https://bugzilla.redhat.com/show_bug.cgi?id=1142311), it is required to modify capabilities of ping binary to work around "Operation not permitted" error. - -```shell -bash-4.3# yum -y install iproute iputils -bash-4.3# setcap cap_net_raw-ep /usr/bin/ping -``` - -Now note the IP address on the first node: - -```shell -bash-4.3# ip -4 a l eth0 | grep inet - inet 18.16.29.4/24 scope global eth0 -``` - -And also note the IP address on the other node: - -```shell -bash-4.3# ip a l eth0 | grep inet - inet 18.16.90.4/24 scope global eth0 -``` -Now ping from the first node to the other node: - -```shell -bash-4.3# ping 18.16.90.4 -PING 18.16.90.4 (18.16.90.4) 56(84) bytes of data. -64 bytes from 18.16.90.4: icmp_seq=1 ttl=62 time=0.275 ms -64 bytes from 18.16.90.4: icmp_seq=2 ttl=62 time=0.372 ms -``` - -Now Kubernetes multi-node cluster is set up with overlay networking set up by flannel. - -## Support Level - - -IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level --------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- -Bare-metal | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster) | | Community ([@aveshagarwal](https://github.com/aveshagarwal)) -libvirt | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster) | | Community ([@aveshagarwal](https://github.com/aveshagarwal)) -KVM | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster) | | Community ([@aveshagarwal](https://github.com/aveshagarwal)) - - - -For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions) chart. - +--- +assignees: +- dchen1107 +- erictune +- thockin + +--- +* TOC +{:toc} + +This document describes how to deploy Kubernetes on multiple hosts to set up a multi-node cluster and networking with flannel. Follow fedora [getting started guide](/docs/getting-started-guides/fedora/fedora_manual_config/) to setup 1 master (fed-master) and 2 or more nodes. Make sure that all nodes have different names (fed-node1, fed-node2 and so on) and labels (fed-node1-label, fed-node2-label, and so on) to avoid any conflict. Also make sure that the Kubernetes master host is running etcd, kube-controller-manager, kube-scheduler, and kube-apiserver services, and the nodes are running docker, kube-proxy and kubelet services. Now install flannel on Kubernetes nodes. flannel on each node configures an overlay network that docker uses. flannel runs on each node to setup a unique class-C container network. + +## Prerequisites + +You need 2 or more machines with Fedora installed. + +## Master Setup + +**Perform following commands on the Kubernetes master** + +* Configure flannel by creating a `flannel-config.json` in your current directory on fed-master. Flannel provides udp and vxlan among other overlay networking backend options. In this guide, we choose kernel based vxlan backend. The contents of the json are: + +```json +{ + "Network": "18.16.0.0/16", + "SubnetLen": 24, + "Backend": { + "Type": "vxlan", + "VNI": 1 + } +} +``` + +**NOTE:** Choose an IP range that is *NOT* part of the public IP address range. + +Add the configuration to the etcd server on fed-master. + +```shell +etcdctl set /coreos.com/network/config < flannel-config.json +``` + +* Verify the key exists in the etcd server on fed-master. + +```shell +etcdctl get /coreos.com/network/config +``` + +## Node Setup + +**Perform following commands on all Kubernetes nodes** + +Edit the flannel configuration file /etc/sysconfig/flanneld as follows: + +```shell +# Flanneld configuration options + +# etcd url location. Point this to the server where etcd runs +FLANNEL_ETCD="http://fed-master:4001" + +# etcd config key. This is the configuration key that flannel queries +# For address range assignment +FLANNEL_ETCD_KEY="/coreos.com/network" + +# Any additional options that you want to pass +FLANNEL_OPTIONS="" +``` + +**Note:** By default, flannel uses the interface for the default route. If you have multiple interfaces and would like to use an interface other than the default route one, you could add "-iface=" to FLANNEL_OPTIONS. For additional options, run `flanneld --help` on command line. + +Enable the flannel service. + +```shell +systemctl enable flanneld +``` + +If docker is not running, then starting flannel service is enough and skip the next step. + +```shell +systemctl start flanneld +``` + +If docker is already running, then stop docker, delete docker bridge (docker0), start flanneld and restart docker as follows. Another alternative is to just reboot the system (`systemctl reboot`). + +```shell +systemctl stop docker +ip link delete docker0 +systemctl start flanneld +systemctl start docker +``` + + +## **Test the cluster and flannel configuration** + +Now check the interfaces on the nodes. Notice there is now a flannel.1 interface, and the ip addresses of docker0 and flannel.1 interfaces are in the same network. You will notice that docker0 is assigned a subnet (18.16.29.0/24 as shown below) on each Kubernetes node out of the IP range configured above. A working output should look like this: + +```shell +# ip -4 a|grep inet + inet 127.0.0.1/8 scope host lo + inet 192.168.122.77/24 brd 192.168.122.255 scope global dynamic eth0 + inet 18.16.29.0/16 scope global flannel.1 + inet 18.16.29.1/24 scope global docker0 +``` + +From any node in the cluster, check the cluster members by issuing a query to etcd server via curl (only partial output is shown using `grep -E "\{|\}|key|value"`). If you set up a 1 master and 3 nodes cluster, you should see one block for each node showing the subnets they have been assigned. You can associate those subnets to each node by the MAC address (VtepMAC) and IP address (Public IP) that is listed in the output. + +```shell +curl -s http://fed-master:4001/v2/keys/coreos.com/network/subnets | python -mjson.tool +``` + +```json +{ + "node": { + "key": "/coreos.com/network/subnets", + { + "key": "/coreos.com/network/subnets/18.16.29.0-24", + "value": "{\"PublicIP\":\"192.168.122.77\",\"BackendType\":\"vxlan\",\"BackendData\":{\"VtepMAC\":\"46:f1:d0:18:d0:65\"}}" + }, + { + "key": "/coreos.com/network/subnets/18.16.83.0-24", + "value": "{\"PublicIP\":\"192.168.122.36\",\"BackendType\":\"vxlan\",\"BackendData\":{\"VtepMAC\":\"ca:38:78:fc:72:29\"}}" + }, + { + "key": "/coreos.com/network/subnets/18.16.90.0-24", + "value": "{\"PublicIP\":\"192.168.122.127\",\"BackendType\":\"vxlan\",\"BackendData\":{\"VtepMAC\":\"92:e2:80:ba:2d:4d\"}}" + } + } +} +``` + +From all nodes, review the `/run/flannel/subnet.env` file. This file was generated automatically by flannel. + +```shell +# cat /run/flannel/subnet.env +FLANNEL_SUBNET=18.16.29.1/24 +FLANNEL_MTU=1450 +FLANNEL_IPMASQ=false +``` + +At this point, we have etcd running on the Kubernetes master, and flannel / docker running on Kubernetes nodes. Next steps are for testing cross-host container communication which will confirm that docker and flannel are configured properly. + +Issue the following commands on any 2 nodes: + +```shell +# docker run -it fedora:latest bash +bash-4.3# +``` + +This will place you inside the container. Install iproute and iputils packages to install ip and ping utilities. Due to a [bug](https://bugzilla.redhat.com/show_bug.cgi?id=1142311), it is required to modify capabilities of ping binary to work around "Operation not permitted" error. + +```shell +bash-4.3# yum -y install iproute iputils +bash-4.3# setcap cap_net_raw-ep /usr/bin/ping +``` + +Now note the IP address on the first node: + +```shell +bash-4.3# ip -4 a l eth0 | grep inet + inet 18.16.29.4/24 scope global eth0 +``` + +And also note the IP address on the other node: + +```shell +bash-4.3# ip a l eth0 | grep inet + inet 18.16.90.4/24 scope global eth0 +``` +Now ping from the first node to the other node: + +```shell +bash-4.3# ping 18.16.90.4 +PING 18.16.90.4 (18.16.90.4) 56(84) bytes of data. +64 bytes from 18.16.90.4: icmp_seq=1 ttl=62 time=0.275 ms +64 bytes from 18.16.90.4: icmp_seq=2 ttl=62 time=0.372 ms +``` + +Now Kubernetes multi-node cluster is set up with overlay networking set up by flannel. + +## Support Level + + +IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level +-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- +Bare-metal | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster) | | Community ([@aveshagarwal](https://github.com/aveshagarwal)) +libvirt | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster) | | Community ([@aveshagarwal](https://github.com/aveshagarwal)) +KVM | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster) | | Community ([@aveshagarwal](https://github.com/aveshagarwal)) + + + +For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions) chart. + diff --git a/docs/getting-started-guides/gce.md b/docs/getting-started-guides/gce.md index 22b1679a50..778795c3db 100644 --- a/docs/getting-started-guides/gce.md +++ b/docs/getting-started-guides/gce.md @@ -25,7 +25,8 @@ If you want to use custom binaries or pure open source Kubernetes, please contin 1. Install `gcloud` as necessary. `gcloud` can be installed as a part of the [Google Cloud SDK](https://cloud.google.com/sdk/). 1. Enable the [Compute Engine Instance Group Manager API](https://developers.google.com/console/help/new/#activatingapis) in the [Google Cloud developers console](https://console.developers.google.com). 1. Make sure that gcloud is set to use the Google Cloud Platform project you want. You can check the current project using `gcloud config list project` and change it via `gcloud config set project `. -1. Make sure you have credentials for GCloud by running ` gcloud auth login`. +1. Make sure you have credentials for GCloud by running `gcloud auth login`. +1. (Optional) In order to make API calls against GCE, you must also run `gcloud auth application-default login`. 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. @@ -245,5 +246,3 @@ For support level information on all solutions, see the [Table of solutions](/do Please see the [Kubernetes docs](/docs/) for more details on administering and using a Kubernetes cluster. - - diff --git a/docs/getting-started-guides/index.md b/docs/getting-started-guides/index.md index ec5eb98759..a728980e50 100644 --- a/docs/getting-started-guides/index.md +++ b/docs/getting-started-guides/index.md @@ -41,6 +41,8 @@ clusters. [AppsCode.com](https://appscode.com/products/cloud-deployment/) provides managed Kubernetes clusters for various public clouds (including AWS and Google Cloud Platform). +[KCluster.io](https://kcluster.io) provides highly available and scalable managed Kubernetes clusters for AWS. + ### Turn-key Cloud Solutions These solutions allow you to create Kubernetes clusters on a range of Cloud IaaS providers with only a @@ -48,8 +50,8 @@ few commands, and have active community support. - [GCE](/docs/getting-started-guides/gce) - [AWS](/docs/getting-started-guides/aws) +- [Azure](/docs/getting-started-guides/azure/) - [Azure](/docs/getting-started-guides/coreos/azure/) (Weave-based, contributed by WeaveWorks employees) -- [Azure](/docs/getting-started-guides/azure/) (Flannel-based, contributed by Microsoft employee) - [CenturyLink Cloud](/docs/getting-started-guides/clc) - [IBM SoftLayer](https://github.com/patrocinio/kubernetes-softlayer) @@ -70,7 +72,7 @@ writing a new solution](https://github.com/kubernetes/kubernetes/tree/{{page.git These solutions are combinations of cloud provider and OS not covered by the above solutions. -- [AWS + coreos](/docs/getting-started-guides/coreos) +- [AWS + CoreOS](/docs/getting-started-guides/coreos) - [GCE + CoreOS](/docs/getting-started-guides/coreos) - [AWS + Ubuntu](/docs/getting-started-guides/juju) - [Joyent + Ubuntu](/docs/getting-started-guides/juju) @@ -120,9 +122,10 @@ IaaS Provider | Config. Mgmt | OS | Networking | Docs GKE | | | GCE | [docs](https://cloud.google.com/container-engine) | ['œ“][3] | Commercial Stackpoint.io | | multi-support | multi-support | [docs](http://www.stackpointcloud.com) | | Commercial AppsCode.com | Saltstack | Debian | multi-support | [docs](https://appscode.com/products/cloud-deployment/) | | Commercial +KCluster.io | | multi-support | multi-support | [docs](https://kcluster.io) | | Commercial GCE | Saltstack | Debian | GCE | [docs](/docs/getting-started-guides/gce) | ['œ“][1] | Project Azure | CoreOS | CoreOS | Weave | [docs](/docs/getting-started-guides/coreos/azure/) | | Community ([@errordeveloper](https://github.com/errordeveloper), [@squillace](https://github.com/squillace), [@chanezon](https://github.com/chanezon), [@crossorigin](https://github.com/crossorigin)) -Azure | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/azure) | | Community ([@colemickens](https://github.com/colemickens)) +Azure | Ignition | Ubuntu | Azure | [docs](/docs/getting-started-guides/azure) | | Community (Microsoft: [@brendandburns](https://github.com/brendandburns), [@colemickens](https://github.com/colemickens)) Docker Single Node | custom | N/A | local | [docs](/docs/getting-started-guides/docker) | | Project ([@brendandburns](https://github.com/brendandburns)) Docker Multi Node | custom | N/A | flannel | [docs](/docs/getting-started-guides/docker-multinode) | | Project ([@brendandburns](https://github.com/brendandburns)) Bare-metal | Ansible | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/fedora_ansible_config) | | Project diff --git a/docs/getting-started-guides/kubeadm.md b/docs/getting-started-guides/kubeadm.md index 6852438004..cd73f3e73f 100644 --- a/docs/getting-started-guides/kubeadm.md +++ b/docs/getting-started-guides/kubeadm.md @@ -13,6 +13,8 @@ The installation uses a tool called `kubeadm` which is part of Kubernetes 1.4. This process works with local VMs, physical servers and/or cloud servers. It is simple enough that you can easily integrate its use into your own automation (Terraform, Chef, Puppet, etc). +See the full [`kubeadm` reference](/docs/admin/kubeadm) for information on all `kubeadm` command-line flags and for advice on automating `kubeadm` itself. + **The `kubeadm` tool is currently in alpha but please try it out and give us [feedback](/docs/getting-started-guides/kubeadm/#feedback)!** ## Prerequisites @@ -45,7 +47,7 @@ For each host in turn: * SSH into the machine and become `root` if you are not already (for example, run `sudo su -`). * If the machine is running Ubuntu 16.04, run: - # curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - + # curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - # cat < /etc/apt/sources.list.d/kubernetes.list deb http://apt.kubernetes.io/ kubernetes-xenial main EOF @@ -177,14 +179,14 @@ Once a pod network has been installed, you can confirm that it is working by che As an example, install a sample microservices application, a socks shop, to put your cluster through its paces. To learn more about the sample microservices app, see the [GitHub README](https://github.com/microservices-demo/microservices-demo). - # git clone https://github.com/microservices-demo/microservices-demo - # kubectl apply -f microservices-demo/deploy/kubernetes/manifests + # kubectl create namespace sock-shop + # kubectl apply -n sock-shop -f "https://github.com/microservices-demo/microservices-demo/blob/master/deploy/kubernetes/complete-demo.yaml?raw=true" You can then find out the port that the [NodePort feature of services](/docs/user-guide/services/) allocated for the front-end service by running: - # kubectl describe svc front-end + # kubectl describe svc front-end -n sock-shop Name: front-end - Namespace: default + Namespace: sock-shop Labels: name=front-end Selector: name=front-end Type: NodePort @@ -194,7 +196,7 @@ You can then find out the port that the [NodePort feature of services](/docs/use Endpoints: Session Affinity: None -It takes several minutes to download and start all the containers, watch the output of `kubectl get pods` to see when they're all up and running. +It takes several minutes to download and start all the containers, watch the output of `kubectl get pods -n sock-shop` to see when they're all up and running. Then go to the IP address of your cluster's master node in your browser, and specify the given port. So for example, `http://:`. @@ -211,21 +213,24 @@ See the [list of add-ons](/docs/admin/addons/) to explore other add-ons, includi * Learn more about [Kubernetes concepts and kubectl in Kubernetes 101](/docs/user-guide/walkthrough/). * Install Kubernetes with [a cloud provider configurations](/docs/getting-started-guides/) to add Load Balancer and Persistent Volume support. +* Learn about `kubeadm`'s advanced usage on the [advanced reference doc](/docs/admin/kubeadm/) ## Cleanup -* To uninstall the socks shop, run `kubectl delete -f microservices-demo/deploy/kubernetes/manifests` on the master. +* To uninstall the socks shop, run `kubectl delete namespace sock-shop` on the master. -* To undo what `kubeadm` did, simply delete the machines you created for this tutorial, or run the script below and then uninstall the packages. -
    - 
    systemctl stop kubelet;
-  docker rm -f $(docker ps -q); mount | grep "/var/lib/kubelet/*" | awk '{print $3}' | xargs umount 1>/dev/null 2>/dev/null;
-  rm -rf /var/lib/kubelet /etc/kubernetes /var/lib/etcd /etc/cni;
-  ip link set cbr0 down; ip link del cbr0;
-  ip link set cni0 down; ip link del cni0;
-  systemctl start kubelet
    -
    +* To undo what `kubeadm` did, simply delete the machines you created for this tutorial, or run the script below and then start over or uninstall the packages. + +
    + Reset local state: + 
    systemctl stop kubelet;
+  docker rm -f -v $(docker ps -q);
+  find /var/lib/kubelet | xargs -n 1 findmnt -n -t tmpfs -o TARGET -T | uniq | xargs -r umount -v;
+  rm -r -f /etc/kubernetes /var/lib/kubelet /var/lib/etcd;
+
    + If you wish to start over, run `systemctl start kubelet` followed by `kubeadm init` or `kubeadm join`. + ## Feedback @@ -253,3 +258,9 @@ Please note: `kubeadm` is a work in progress and these limitations will be addre 1. There is not yet an easy way to generate a `kubeconfig` file which can be used to authenticate to the cluster remotely with `kubectl` on, for example, your workstation. Workaround: copy the kubelet's `kubeconfig` from the master: use `scp root@:/etc/kubernetes/admin.conf .` and then e.g. `kubectl --kubeconfig ./admin.conf get nodes` from your workstation. + +1. If you are using VirtualBox (directly or via Vagrant), you will need to ensure that `hostname -i` returns a routable IP address (i.e. one on the second network interface, not the first one). + By default, it doesn't do this and kubelet ends-up using first non-loopback network interface, which is usually NATed. + Workaround: Modify `/etc/hosts`, take a look at this [`Vagrantfile`][ubuntu-vagrantfile] for how you this can be achieved. + +[ubuntu-vagrantfile]: https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11), diff --git a/docs/getting-started-guides/libvirt-coreos.md b/docs/getting-started-guides/libvirt-coreos.md index f752a13aee..86b0707092 100644 --- a/docs/getting-started-guides/libvirt-coreos.md +++ b/docs/getting-started-guides/libvirt-coreos.md @@ -134,7 +134,7 @@ export KUBERNETES_PROVIDER=libvirt-coreos; wget -q -O - https://get.k8s.io | bas Here is the curl version of this command: ```shell -export KUBERNETES_PROVIDER=libvirt-coreos; curl -sS https://get.k8s.io | bash` +export KUBERNETES_PROVIDER=libvirt-coreos; curl -sS https://get.k8s.io | bash ``` This script downloads and unpacks the tarball, then spawns a Kubernetes cluster on CoreOS instances with the following characteristics: diff --git a/docs/getting-started-guides/mesos/index.md b/docs/getting-started-guides/mesos/index.md index bec65b64fd..2d909145a3 100644 --- a/docs/getting-started-guides/mesos/index.md +++ b/docs/getting-started-guides/mesos/index.md @@ -47,9 +47,8 @@ ssh jclouds@${ip_address_of_master_node} Build Kubernetes-Mesos. ```shell -git clone https://github.com/kubernetes/kubernetes -cd kubernetes -export KUBERNETES_CONTRIB=mesos +git clone https://github.com/kubernetes-incubator/kube-mesos-framework +cd kube-mesos-framework make ``` diff --git a/docs/getting-started-guides/ubuntu.md b/docs/getting-started-guides/ubuntu.md index 3018bd026e..e5a849d909 100644 --- a/docs/getting-started-guides/ubuntu.md +++ b/docs/getting-started-guides/ubuntu.md @@ -29,6 +29,7 @@ Internet to download the necessary files, while worker nodes do not. Ubuntu 15 which uses systemd instead of upstart. 4. Dependencies of this guide: etcd-2.2.1, flannel-0.5.5, k8s-1.2.0, may work with higher versions. 5. All the remote servers can be ssh logged in without a password by using key authentication. +6. The remote user on all machines is using /bin/bash as its login shell, and has sudo access. ## Starting a Cluster @@ -116,7 +117,13 @@ that conflicts with your own private network range. The `FLANNEL_NET` variable defines the IP range used for flannel overlay network, should not conflict with above `SERVICE_CLUSTER_IP_RANGE`. You can optionally provide additional Flannel network configuration -through `FLANNEL_OTHER_NET_CONFIG`, as explained in `cluster/ubuntu/config-default.sh`. +through `FLANNEL_BACKEND` and `FLANNEL_OTHER_NET_CONFIG`, as explained in `cluster/ubuntu/config-default.sh`. + +The default setting for `ADMISSION_CONTROL` is right for the latest +release of Kubernetes, but if you choose an earlier release then you +might want a different setting. See +[the admisson control doc](http://kubernetes.io/docs/admin/admission-controllers/#is-there-a-recommended-set-of-plug-ins-to-use) +for the recommended settings for various releases. **Note:** When deploying, master needs to be connected to the Internet to download the necessary files. If your machines are located in a private network that need proxy setting to connect the Internet, diff --git a/docs/index.md b/docs/index.md index 5e29c42dcb..3c813670db 100644 --- a/docs/index.md +++ b/docs/index.md @@ -77,9 +77,9 @@ h2, h3, h4 { Read the Overview
    -

    Hello World on Google Container Engine

    -

    In this quickstart, we’ll be creating a Kubernetes instance that stands up a simple “Hello World” app using Node.js. In just a few minutes you'll go from zero to deployed Kubernetes app on Google Container Engine (GKE), a hosted service from Google.

    - Get Started on GKE +

    Kubernetes Basics Interactive Tutorial

    +

    The Kubernetes Basics interactive tutorials let you try out Kubernetes features using Minikube right out of your web browser in a virtual terminal. Learn about the Kubernetes system and deploy, expose, scale, and upgrade a containerized application in just a few minutes.

    + Try the Interactive Tutorials

    Installing Kubernetes on Linux with kubeadm

    @@ -117,7 +117,7 @@ h2, h3, h4 {

    Contribute to Our Docs

    The docs for Kubernetes are open-source, just like the code for Kubernetes itself. The docs are on GitHub Pages, so you can fork it and it will auto-stage on username.github.io, previewing your changes!

    - Write Docs for K8s + Write Docs for K8s

    Need Help?

    diff --git a/docs/tasks/access-kubernetes-api/access-kubernetes-api/http-proxy-access-api.md b/docs/tasks/access-kubernetes-api/access-kubernetes-api/http-proxy-access-api.md deleted file mode 100644 index 0c7ad2ca87..0000000000 --- a/docs/tasks/access-kubernetes-api/access-kubernetes-api/http-proxy-access-api.md +++ /dev/null @@ -1,90 +0,0 @@ ---- ---- - -{% capture overview %} -This page shows how to use an HTTP proxy to access the Kubernetes API. -{% endcapture %} - -{% capture prerequisites %} - -* Install [kubectl](http://kubernetes.io/docs/user-guide/prereqs). - -* Create a Kubernetes cluster, including a running Kubernetes - API server. One way to create a new cluster is to use - [Minikube](/docs/getting-started-guides/minikube). - -* Configure `kubectl` to communicate with your Kubernetes API server. This - configuration is done automatically if you use Minikube. - -* If you do not already have an application running in your cluster, start - a Hello world application by entering this command: - - kubectl run --image=gcr.io/google-samples/node-hello:1.0 --port=8080 - -{% endcapture %} - -{% capture steps %} - -### Using kubectl to start a proxy server - -This command starts a proxy to the Kubernetes API server: - - kubectl proxy --port=8080 - -### Exploring the Kubernetes API - -When the proxy server is running, you can explore the API using `curl`, `wget`, -or a browser. - -Get the API versions: - - curl http://localhost:8080/api/ - - { - "kind": "APIVersions", - "versions": [ - "v1" - ], - "serverAddressByClientCIDRs": [ - { - "clientCIDR": "0.0.0.0/0", - "serverAddress": "10.0.2.15:8443" - } - ] - } - -Get a list of pods: - - curl http://localhost:8080/api/v1/namespaces/default/pods - - { - "kind": "PodList", - "apiVersion": "v1", - "metadata": { - "selfLink": "/api/v1/namespaces/default/pods", - "resourceVersion": "33074" - }, - "items": [ - { - "metadata": { - "name": "kubernetes-bootcamp-2321272333-ix8pt", - "generateName": "kubernetes-bootcamp-2321272333-", - "namespace": "default", - "selfLink": "/api/v1/namespaces/default/pods/kubernetes-bootcamp-2321272333-ix8pt", - "uid": "ba21457c-6b1d-11e6-85f7-1ef9f1dab92b", - "resourceVersion": "33003", - "creationTimestamp": "2016-08-25T23:43:30Z", - "labels": { - "pod-template-hash": "2321272333", - "run": "kubernetes-bootcamp" - }, - ... - } - -{% endcapture %} - -{% capture whatsnext %} -Learn more about [kubectl proxy](/docs/user-guide/kubectl/kubectl_proxy). -{% endcapture %} - -{% include templates/task.md %} diff --git a/docs/tasks/administer-cluster/assign-pods-nodes.md b/docs/tasks/administer-cluster/assign-pods-nodes.md new file mode 100644 index 0000000000..e966f23e28 --- /dev/null +++ b/docs/tasks/administer-cluster/assign-pods-nodes.md @@ -0,0 +1,88 @@ +--- +--- + +{% capture overview %} +This page shows how to assign a Kubernetes Pod to a particular node in a +Kubernetes cluster. +{% endcapture %} + +{% capture prerequisites %} + +* Install [kubectl](http://kubernetes.io/docs/user-guide/prereqs). + +* Create a Kubernetes cluster, including a running Kubernetes + API server. One way to create a new cluster is to use + [Minikube](/docs/getting-started-guides/minikube). + +* Configure `kubectl` to communicate with your Kubernetes API server. This + configuration is done automatically if you use Minikube. + +{% endcapture %} + +{% capture steps %} + +### Adding a label to a node + +1. List the nodes in your cluster: + + kubectl get nodes + + The output is similar to this: + + NAME STATUS AGE + worker0 Ready 1d + worker1 Ready 1d + worker2 Ready 1d + +1. Chose one of your nodes, and add a label to it: + + kubectl label nodes disktype=ssd + + where `` is the name of your chosen node. + +1. Verify that your chosen node has a `disktype=ssd` label: + + kubectl get nodes --show-labels + + + The output is similar to this: + + NAME STATUS AGE LABELS + worker0 Ready 1d ...,disktype=ssd,kubernetes.io/hostname=worker0 + worker1 Ready 1d ...,kubernetes.io/hostname=worker1 + worker2 Ready 1d ...,kubernetes.io/hostname=worker2 + + In the preceding output, you can see that the `worker0` node has a + `disktype=ssd` label. + +### Creating a pod that gets scheduled to your chosen node + +This pod configuration file describes a pod that has a node selector, +`disktype: ssd`. This means that the pod will get scheduled on a node that has +a `disktype=ssd` label. + +{% include code.html language="yaml" file="pod.yaml" ghlink="/docs/tasks/administer-cluster/pod.yaml" %} + +1. Use the configuration file to create a pod that will get scheduled on your + chosen node: + + export REPO=https://raw.githubusercontent.com/kubernetes/kubernetes.github.io/master + kubectl create -f $REPO/docs/tasks/administer-cluster/pod.yaml + +1. Verify that the pod is running on your chosen node: + + kubectl get pods --output=wide + + The output is similar to this: + + NAME READY STATUS RESTARTS AGE IP NODE + nginx 1/1 Running 0 13s 10.200.0.4 worker0 + +{% endcapture %} + +{% capture whatsnext %} +Learn more about +[labels and selectors](/docs/user-guide/labels/). +{% endcapture %} + +{% include templates/task.md %} diff --git a/docs/tasks/administer-cluster/pod.yaml b/docs/tasks/administer-cluster/pod.yaml new file mode 100644 index 0000000000..134ddae2aa --- /dev/null +++ b/docs/tasks/administer-cluster/pod.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx + labels: + env: test +spec: + containers: + - name: nginx + image: nginx + imagePullPolicy: IfNotPresent + nodeSelector: + disktype: ssd diff --git a/docs/tasks/configure-pod-container/commands.yaml b/docs/tasks/configure-pod-container/commands.yaml new file mode 100644 index 0000000000..8d58007db4 --- /dev/null +++ b/docs/tasks/configure-pod-container/commands.yaml @@ -0,0 +1,12 @@ +apiVersion: v1 +kind: Pod +metadata: + name: command-demo + labels: + purpose: demonstrate-command +spec: + containers: + - name: command-demo-container + image: debian + command: ["printenv"] + args: ["HOSTNAME", "KUBERNETES_PORT"] diff --git a/docs/tasks/configure-pod-container/define-command-argument-container.md b/docs/tasks/configure-pod-container/define-command-argument-container.md new file mode 100644 index 0000000000..22ac9b5e04 --- /dev/null +++ b/docs/tasks/configure-pod-container/define-command-argument-container.md @@ -0,0 +1,105 @@ +--- +--- + +{% capture overview %} + +This page shows how to define commands and arguments when you run a container +in a Kubernetes Pod. + +{% endcapture %} + + +{% capture prerequisites %} + +{% include task-tutorial-prereqs.md %} + +{% endcapture %} + + +{% capture steps %} + +### Defining a command and arguments when you create a Pod + +When you create a Pod, you can define a command and arguments for the +containers that run in the Pod. To define a command, include the `command` +field in the configuration file. To define arguments for the command, include +the `args` field in the configuration file. The command and arguments that +you define cannot be changed after the Pod is created. + +The command and arguments that you define in the configuration file +override the default command and arguments provided by the container image. +If you define args, but do not define a command, the default command is used +with your new arguments. For more information, see +[Commands and Capabilities](/docs/user-guide/containers/). + +In this exercise, you create a Pod that runs one container. The configuration +file for the Pod defines a command and two arguments: + +{% include code.html language="yaml" file="commands.yaml" ghlink="/docs/tasks/configure-pod-container/commands.yaml" %} + +1. Create a Pod based on the YAML configuration file: + + export REPO=https://raw.githubusercontent.com/kubernetes/kubernetes.github.io/master + kubectl create -f $REPO/docs/tasks/configure-pod-container/commands.yaml + +1. List the running Pods: + + kubectl get pods + + The output shows that the container that ran in the command-demo Pod has + completed. + +1. To see the output of the command that ran in the container, view the logs +from the Pod: + + kubectl logs command-demo + + The output shows the values of the HOSTNAME and KUBERNETES_PORT environment + variables: + + command-demo + tcp://10.3.240.1:443 + +### Using environment variables to define arguments + +In the preceding example, you defined the arguments directly by +providing strings. As an alternative to providing strings directly, +you can define arguments by using environment variables: + + env: + - name: MESSAGE + value: "hello world" + command: ["/bin/echo"] + args: ["$(MESSAGE)"] + +This means you can define an argument for a Pod using any of +the techniques available for defining environment variables, including +[ConfigMaps](/docs/user-guide/configmap/) +and +[Secrets](/docs/user-guide/secrets/). + +NOTE: The environment variable appears in parentheses, `"$(VAR)"`. This is +required for the variable to be expanded in the `command` or `args` field. + +### Running a command in a shell + +In some cases, you need your command to run in a shell. For example, your +command might consist of several commands piped together, or it might be a shell +script. To run your command in a shell, wrap it like this: + + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello; sleep 10;done"] + +{% endcapture %} + +{% capture whatsnext %} + +* Learn more about [containers and commands](/docs/user-guide/containers/). +* Learn more about [configuring containers](/docs/user-guide/configuring-containers/). +* Learn more about [running commands in a container](/docs/user-guide/getting-into-containers/). +* See [Container](/docs/api-reference/v1/definitions/#_v1_container). + +{% endcapture %} + + +{% include templates/task.md %} diff --git a/docs/tasks/configure-pod-container/define-environment-variable-container.md b/docs/tasks/configure-pod-container/define-environment-variable-container.md new file mode 100644 index 0000000000..2cba3c55f1 --- /dev/null +++ b/docs/tasks/configure-pod-container/define-environment-variable-container.md @@ -0,0 +1,77 @@ +--- +--- + +{% capture overview %} + +This page shows how to define environment variables when you run a container +in a Kubernetes Pod. + +{% endcapture %} + + +{% capture prerequisites %} + +{% include task-tutorial-prereqs.md %} + +{% endcapture %} + + +{% capture steps %} + +### Defining an environment variable for a container + +When you create a Pod, you can set environment variables for the containers +that run in the Pod. To set environment variables, include the `env` field in +the configuration file. + +In this exercise, you create a Pod that runs one container. The configuration +file for the Pod defines an environment variable with name `DEMO_GREETING` and +value `"Hello from the environment"`. Here is the configuration file for the +Pod: + +{% include code.html language="yaml" file="envars.yaml" ghlink="/docs/tasks/configure-pod-container/envars.yaml" %} + +1. Create a Pod based on the YAML configuration file: + + export REPO=https://raw.githubusercontent.com/kubernetes/kubernetes.github.io/master + kubectl create -f $REPO/docs/tasks/configure-pod-container/envars.yaml + +1. List the running Pods: + + kubectl get pods + + The output is similar to this: + + NAME READY STATUS RESTARTS AGE + envar-demo 1/1 Running 0 9s + +1. Get a shell to the container running in your Pod: + + kubectl exec -it envar-demo -- /bin/bash + +1. In your shell, run the `printenv` command to list the environment variables. + + root@envar-demo:/# printenv + + The output is similar to this: + + NODE_VERSION=4.4.2 + EXAMPLE_SERVICE_PORT_8080_TCP_ADDR=10.3.245.237 + HOSTNAME=envar-demo + ... + DEMO_GREETING=Hello from the environment + +1. To exit the shell, enter `exit`. + +{% endcapture %} + +{% capture whatsnext %} + +* Learn more about [environment variables](/docs/user-guide/environment-guide/). +* Learn about [using secrets as environment variables](/docs/user-guide/secrets/#using-secrets-as-environment-variables). +* See [EnvVarSource](/docs/api-reference/v1/definitions/#_v1_envvarsource). + +{% endcapture %} + + +{% include templates/task.md %} diff --git a/docs/tasks/configure-pod-container/envars.yaml b/docs/tasks/configure-pod-container/envars.yaml new file mode 100644 index 0000000000..97b296ac52 --- /dev/null +++ b/docs/tasks/configure-pod-container/envars.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Pod +metadata: + name: envar-demo + labels: + purpose: demonstrate-envars +spec: + containers: + - name: envar-demo-container + image: gcr.io/google-samples/node-hello:1.0 + env: + - name: DEMO_GREETING + value: "Hello from the environment" diff --git a/docs/tasks/index.md b/docs/tasks/index.md index b8fa301fa3..fc08a0469a 100644 --- a/docs/tasks/index.md +++ b/docs/tasks/index.md @@ -3,6 +3,11 @@ The Tasks section of the Kubernetes documentation is a work in progress +#### Configuring Pods and Containers + +* [Defining Environment Variables for a Container](/docs/tasks/configure-pod-container/define-environment-variable-container/) +* [Defining a Command and Arguments for a Container](/docs/tasks/configure-pod-container/define-command-argument-container/) + #### Accessing Applications in a Cluster * [Using Port Forwarding to Access Applications in a Cluster](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) @@ -11,6 +16,9 @@ The Tasks section of the Kubernetes documentation is a work in progress * [Using an HTTP Proxy to Access the Kubernetes API](/docs/tasks/access-kubernetes-api/http-proxy-access-api) +#### Administering a Cluster + +* [Assigning Pods to Nodes](/docs/tasks/administer-cluster/assign-pods-nodes/) ### What's next diff --git a/docs/tools/index.md b/docs/tools/index.md new file mode 100644 index 0000000000..37cc5bc54b --- /dev/null +++ b/docs/tools/index.md @@ -0,0 +1,40 @@ +--- +assignees: +- janetkuo + +--- + +* TOC +{:toc} + +## Native Tools + +### Kubectl + +[`kubectl`](/docs/user-guide/kubectl/) is the command line tool for Kubernetes. It controls the Kubernetes cluster manager. + +### Dashboard + +[Dashboard](/docs/user-guide/ui/), the web-based user interface of Kubernetes, allows you to deploy containerized applications +to a Kubernetes cluster, troubleshoot them, and manage the cluster and its resources itself. + +## Third-Party Tools + +### Helm + +[Kubernetes Helm](https://github.com/kubernetes/helm) is a tool for managing packages of pre-configured +Kubernetes resources, aka Kubernetes charts. + +Use Helm to: + +* Find and use popular software packaged as Kubernetes charts +* Share your own applications as Kubernetes charts +* Create reproducible builds of your Kubernetes applications +* Intelligently manage your Kubernetes manifest files +* Manage releases of Helm packages + +### Kompose + +[`kompose`](https://github.com/skippbox/kompose) is a tool to help users familiar with `docker-compose` +move to Kubernetes. It takes a Docker Compose file and translates it into Kubernetes objects. `kompose` +is a convenient tool to go from local Docker development to managing your application with Kubernetes. diff --git a/docs/tutorials/getting-started/create-cluster.html b/docs/tutorials/getting-started/create-cluster.html deleted file mode 100644 index 42c22f90e8..0000000000 --- a/docs/tutorials/getting-started/create-cluster.html +++ /dev/null @@ -1,47 +0,0 @@ ---- ---- - - - - - - - - - -
    - -
    - -
    -
    -

    Module overview

    -
      -
    • learn what a Kubernetes cluster is
      • -
    • learn what minikube is
      • -
    • start a Kubernetes cluster using an online terminal
      • -
    -

    -
    -
    -
    -

    What you need to know first

    -

    - Before you do this tutorial, you should be familiar with Linux containers. -

    -
    -
    -
    - -
    -
    - Start Module 1 › -
    -
    - -
    - -
    - - - diff --git a/docs/tutorials/getting-started/deploy-app.html b/docs/tutorials/getting-started/deploy-app.html deleted file mode 100644 index e60081b601..0000000000 --- a/docs/tutorials/getting-started/deploy-app.html +++ /dev/null @@ -1,52 +0,0 @@ ---- ---- - - - - - - - - - -
    - -
    - -
    -
    - ‹ Back -
    -
    - -
    -
    -

    Module overview

    -
      -
    • Learn about application Deployments
      • -
    • Deploy your first app on Kubernetes with Kubectl
      • -
    -

    -
    -
    -
    -

    What you need to know first

    -

    - How to start a Kubernetes cluster with minikube
    -

    -
    -
    -
    - -
    -
    - Start Module 2 › -
    -
    - -
    - -
    - - - diff --git a/docs/tutorials/getting-started/explore-app.html b/docs/tutorials/getting-started/explore-app.html deleted file mode 100644 index bc18696e81..0000000000 --- a/docs/tutorials/getting-started/explore-app.html +++ /dev/null @@ -1,53 +0,0 @@ ---- ---- - - - - - - - - - -
    - -
    - -
    -
    - ‹ Back -
    -
    - -
    -
    -

    Module overview

    -
      -
    • Learn about Kubernetes Pods
      • -
    • Learn about Kubernetes Nodes
      • -
    • Troubleshoot deployed applications
      • -
    -

    -
    -
    -
    -

    What you need to know first

    -

    - What are Deployments
    - How to deploy applications on Kubernetes -

    -
    -
    -
    -
    -
    - Start Module 3 › -
    -
    - -
    - -
    - - - diff --git a/docs/tutorials/getting-started/expose-app.html b/docs/tutorials/getting-started/expose-app.html deleted file mode 100644 index 04e8300b91..0000000000 --- a/docs/tutorials/getting-started/expose-app.html +++ /dev/null @@ -1,54 +0,0 @@ ---- ---- - - - - - - - - - -
    - -
    - -
    -
    - ‹ Back -
    -
    - -
    -
    -

    Module overview

    -
      -
    • Services
      • -
    • Learn about Kubernetes Labels
      • -
    • Exposing applications outside Kubernetes
      • -
    -

    -
    -
    -
    -

    What you need to know first

    -

    - How to deploy apps on Kubernetes
    - How to troubleshoot applications with Kubectl -

    -
    -
    -
    - -
    -
    - Start Module 4 › -
    -
    - -
    - -
    - - - diff --git a/docs/tutorials/getting-started/index.html b/docs/tutorials/getting-started/index.html deleted file mode 100644 index 932bd79363..0000000000 --- a/docs/tutorials/getting-started/index.html +++ /dev/null @@ -1,97 +0,0 @@ ---- ---- - - - - - - - - - -
    - -
    - -
    -
    -

    Getting Started with Kubernetes

    -

    By the end of this tutorial you will understand what Kubernetes does. You will also learn how to deploy, scale, update and debug containerized applications on a Kubernetes cluster using an interactive online terminal.

    -
    -
    - -
    - -
    -
    -

    Why Kubernetes?

    -

    Today users expect applications to be available 24/7, while developers expect to deploy new versions of those applications several times a day. The way we build software is moving in this direction, enabling applications to be released and updated in an easy and fast way without downtime. We also need to be able to scale application in line with the user demand and we expect them to make intelligent use of the available resources. Kubernetes is a platform designed to meet those requirements, using the experience accumulated by Google in this area, combined with best-of-breed ideas from the community.

    -
    -
    - -
    -

    Getting Started Modules

    -
    -
    -
    - -
    -
    1. Create a Kubernetes cluster
     -
    -
    -
    -
    -
    - -
    -
    2. Deploy an app
     -
    -
    -
    -
    -
    - -
    -
    3. Explore your app
     -
    -
    -
    -
    -
    - -
    -
    4. Expose your app publicly
     -
    -
    -
    -
    -
    - -
    -
    5. Scale up your app
     -
    -
    -
    -
    -
    - -
    -
    6. Update your app
     -
    -
    -
    -
    -
    - -
    -
    - Start the tutorial› -
    -
    - -
    - -
    - - - diff --git a/docs/tutorials/getting-started/scale-app.html b/docs/tutorials/getting-started/scale-app.html deleted file mode 100644 index 4996dd3cd4..0000000000 --- a/docs/tutorials/getting-started/scale-app.html +++ /dev/null @@ -1,52 +0,0 @@ ---- ---- - - - - - - - - - -
    - -
    - -
    -
    - ‹ Back -
    -
    - -
    -
    -

    Module overview

    -
      -
    • Scaling an app with Kubectl
      • -
    -

    -
    -
    -
    -

    What you need to know first

    -

    - What are Deployments
    - What are Services -

    -
    -
    -
    - -
    -
    - Start Module 5 › -
    -
    - -
    - -
    - - - diff --git a/docs/tutorials/getting-started/update-app.html b/docs/tutorials/getting-started/update-app.html deleted file mode 100644 index 6ce6600d0e..0000000000 --- a/docs/tutorials/getting-started/update-app.html +++ /dev/null @@ -1,54 +0,0 @@ ---- ---- - - - - - - - - - -
    - -
    - -
    -
    - ‹ Back -
    -
    - -
    -
    -

    Module overview

    -
      -
    • Performing Rolling Updates with Kubectl
      • -
    -

    -
    -
    -
    -

    What you need to know first

    -

    - What are Deployments
    - What is Scaling -

    -
    -
    -
    - -
    -
    - Start Module 6 › -
    -
    - -
    - - - -
    - - - diff --git a/docs/tutorials/index.md b/docs/tutorials/index.md index db1b224364..14530ca25e 100644 --- a/docs/tutorials/index.md +++ b/docs/tutorials/index.md @@ -3,11 +3,17 @@ The Tutorials section of the Kubernetes documentation is a work in progress. +#### Kubernetes Basics + +* [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) is an in-depth interactive tutorial that helps you understand the Kubernetes system and try out some basic Kubernetes features. + #### Stateless Applications * [Running a Stateless Application Using a Deployment](/docs/tutorials/stateless-application/run-stateless-application-deployment/) -* [Exposing an External IP Address Using a Service](/docs/tutorials/stateless-application/expose-external-ip-address-service/) +* [Using a Service to Access an Application in a Cluster](/docs/tutorials/stateless-application/expose-external-ip-address-service/) + +* [Exposing an External IP Address to Access an Application in a Cluster](/docs/tutorials/stateless-application/expose-external-ip-address/) ### What's next diff --git a/docs/tutorials/getting-started/cluster-interactive.html b/docs/tutorials/kubernetes-basics/cluster-interactive.html similarity index 60% rename from docs/tutorials/getting-started/cluster-interactive.html rename to docs/tutorials/kubernetes-basics/cluster-interactive.html index 8f74bab8b5..8b07b331c7 100644 --- a/docs/tutorials/getting-started/cluster-interactive.html +++ b/docs/tutorials/kubernetes-basics/cluster-interactive.html @@ -7,19 +7,13 @@ - +
    -
    -
    - ‹ Back -
    -
    -
    To interact with the Terminal, please use the desktop/tablet version @@ -28,7 +22,7 @@
    - Continue to Module 2› + Continue to Module 2›
    diff --git a/docs/tutorials/getting-started/cluster-intro.html b/docs/tutorials/kubernetes-basics/cluster-intro.html similarity index 75% rename from docs/tutorials/getting-started/cluster-intro.html rename to docs/tutorials/kubernetes-basics/cluster-intro.html index a3dafff437..009a8e3947 100644 --- a/docs/tutorials/getting-started/cluster-intro.html +++ b/docs/tutorials/kubernetes-basics/cluster-intro.html @@ -1,4 +1,7 @@ --- +redirect_from: + - /docs/tutorials/getting-started/create-cluster/ + - /docs/tutorials/getting-started/create-cluster.html --- @@ -7,23 +10,25 @@ - +
    -
    - ‹ Back + +
    +

    Objectives

    +
      +
    • Learn what a Kubernetes cluster is.
      • +
    • Learn what Minikube is.
      • +
    • Start a Kubernetes cluster using an online terminal.
      • +
    -
    -
    -
    - -
    +

    Kubernetes Clusters

    Kubernetes coordinates a highly available cluster of computers that are connected to work as a single unit. The abstractions in Kubernetes allow you to deploy containerized applications to a cluster without tying them specifically to individual machines. To make use of this new model of deployment, applications need to be packaged in a way that decouples them from individual hosts: they need to be containerized. Containerized applications are more flexible and available than in past deployment models, where applications were installed directly onto specific machines as packages deeply integrated into the host. Kubernetes automates the distribution and scheduling of application containers across a cluster in a more efficient way. Kubernetes is an open-source platform and is production-ready.

    @@ -60,7 +65,7 @@
    -

    +


    @@ -82,7 +87,7 @@

    When you deploy applications on Kubernetes, you tell the master to start the application containers. The master schedules the containers to run on the cluster's nodes. The nodes communicate with the master using the Kubernetes API, which the master exposes. End users can also use the Kubernetes API directly to interact with the cluster.

    -

    A Kubernetes cluster can be deployed on either physical or virtual machines. To get started with Kubernetes development, you can use minikube. Minikube is a is a lightweight Kubernetes implementation that creates a VM on your local machine and deploys a simple cluster containing only one node. Minikube is available for Linux, Mac OS and Windows systems. The minikube CLI provides basic bootstrapping operations for working with your cluster, including start, stop, status, and delete. For this bootcamp, however, you'll use a provided online terminal with minikube pre-installed.

    +

    A Kubernetes cluster can be deployed on either physical or virtual machines. To get started with Kubernetes development, you can use minikube. Minikube is a lightweight Kubernetes implementation that creates a VM on your local machine and deploys a simple cluster containing only one node. Minikube is available for Linux, Mac OS and Windows systems. The minikube CLI provides basic bootstrapping operations for working with your cluster, including start, stop, status, and delete. For this bootcamp, however, you'll use a provided online terminal with minikube pre-installed.

    Now that you know what Kubernetes is, let’s go to the online tutorial and start our first cluster!

    @@ -92,7 +97,7 @@
    - Start Interactive Tutorial › + Start Interactive Tutorial ›
    diff --git a/docs/tutorials/getting-started/deploy-interactive.html b/docs/tutorials/kubernetes-basics/deploy-interactive.html similarity index 61% rename from docs/tutorials/getting-started/deploy-interactive.html rename to docs/tutorials/kubernetes-basics/deploy-interactive.html index 6525b21c4c..73d7e9dfc3 100644 --- a/docs/tutorials/getting-started/deploy-interactive.html +++ b/docs/tutorials/kubernetes-basics/deploy-interactive.html @@ -7,18 +7,13 @@ - +
    -
    -
    - ‹ Back -
    -

    @@ -31,7 +26,7 @@
    - Continue to Module 3› + Continue to Module 3›
    diff --git a/docs/tutorials/getting-started/deploy-intro.html b/docs/tutorials/kubernetes-basics/deploy-intro.html similarity index 85% rename from docs/tutorials/getting-started/deploy-intro.html rename to docs/tutorials/kubernetes-basics/deploy-intro.html index cd72f424b8..9fafe6012e 100644 --- a/docs/tutorials/getting-started/deploy-intro.html +++ b/docs/tutorials/kubernetes-basics/deploy-intro.html @@ -7,23 +7,24 @@ - +
    -
    - ‹ Back + +
    +

    Objectives

    +
      +
    • Learn about application Deployments.
      • +
    • Deploy your first app on Kubernetes with kubectl.
      • +
    -
    -
    -
    - -
    +

    Kubernetes Deployments

    Once you have a running Kubernetes cluster, you can deploy your containerized applications on top of it. To do so, you create a Kubernetes Deployment. The Deployment is responsible for creating and updating instances of your application. Once you've created a Deployment, the Kubernetes master schedules the application instances that the Deployment creates onto individual Nodes in the cluster.

    @@ -59,7 +60,7 @@
    -

    +


    @@ -94,7 +95,7 @@
    - Start Interactive Tutorial › + Start Interactive Tutorial ›
    diff --git a/docs/tutorials/getting-started/explore-interactive.html b/docs/tutorials/kubernetes-basics/explore-interactive.html similarity index 61% rename from docs/tutorials/getting-started/explore-interactive.html rename to docs/tutorials/kubernetes-basics/explore-interactive.html index 5b82635398..9b16d4bca4 100644 --- a/docs/tutorials/getting-started/explore-interactive.html +++ b/docs/tutorials/kubernetes-basics/explore-interactive.html @@ -7,18 +7,13 @@ - +
    -
    -
    - ‹ Back -
    -

    @@ -31,7 +26,7 @@
    - Continue to Module 4› + Continue to Module 4›
    diff --git a/docs/tutorials/getting-started/explore-intro.html b/docs/tutorials/kubernetes-basics/explore-intro.html similarity index 82% rename from docs/tutorials/getting-started/explore-intro.html rename to docs/tutorials/kubernetes-basics/explore-intro.html index df9cd7c305..4789838827 100644 --- a/docs/tutorials/getting-started/explore-intro.html +++ b/docs/tutorials/kubernetes-basics/explore-intro.html @@ -7,7 +7,7 @@ - +
    @@ -15,18 +15,19 @@
    -
    - ‹ Back + +
    +

    Objectives

    +
      +
    • Learn about Kubernetes Pods.
      • +
    • Learn about Kubernetes Nodes.
      • +
    • Troubleshoot deployed applications.
      • +
    -
    -
    -
    - -
    -

    Pods

    -

    When you created a Deployment in Module 2, Kubernetes created a Pod to host your application instance. A Pod is Kubernetes abstraction that represents a group of one or more application containers (such as Docker or rkt), and some shared resources for those containers. Those resources include:

    +

    Kubernetes Pods

    +

    When you created a Deployment in Module 2, Kubernetes created a Pod to host your application instance. A Pod is Kubernetes abstraction that represents a group of one or more application containers (such as Docker or rkt), and some shared resources for those containers. Those resources include:

    • Shared storage, as Volumes
    • Networking, as a unique cluster IP address
      • @@ -63,7 +64,7 @@
      -

      +


      @@ -97,7 +98,7 @@
      -

      +


      @@ -128,7 +129,7 @@
      - Start Interactive Tutorial › + Start Interactive Tutorial ›
      diff --git a/docs/tutorials/getting-started/expose-interactive.html b/docs/tutorials/kubernetes-basics/expose-interactive.html similarity index 61% rename from docs/tutorials/getting-started/expose-interactive.html rename to docs/tutorials/kubernetes-basics/expose-interactive.html index 04d3bc3f53..3288807588 100644 --- a/docs/tutorials/getting-started/expose-interactive.html +++ b/docs/tutorials/kubernetes-basics/expose-interactive.html @@ -7,19 +7,13 @@ - +
      -
      -
      - ‹ Back -
      -
      -
      To interact with the Terminal, please use the desktop/tablet version @@ -29,7 +23,7 @@
      - Continue to Module 5› + Continue to Module 5›
      diff --git a/docs/tutorials/getting-started/expose-intro.html b/docs/tutorials/kubernetes-basics/expose-intro.html similarity index 86% rename from docs/tutorials/getting-started/expose-intro.html rename to docs/tutorials/kubernetes-basics/expose-intro.html index 2178a7dd25..81c1981bf4 100644 --- a/docs/tutorials/getting-started/expose-intro.html +++ b/docs/tutorials/kubernetes-basics/expose-intro.html @@ -7,23 +7,26 @@ - +
      -
      - ‹ Back + +
      +

      Objectives

      +
        +
      • Learn about Kubernetes Services.
        • +
      • Learn about Kubernetes Labels.
        • +
      • Expose an application outside Kubernetes.
        • +
      -
      -
      -
      - -
      +

      Kubernetes Services

      +

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

      This abstraction will allow us to expose Pods to traffic originating from outside the cluster. Services have their own unique cluster-private IP address and expose a port to receive traffic. If you choose to expose the service outside the cluster, the options are:

      @@ -58,7 +61,7 @@
      -

      +


      @@ -106,7 +109,7 @@
      -

      +


      @@ -122,7 +125,7 @@
      - Start Interactive Tutorial › + Start Interactive Tutorial ›
      diff --git a/docs/tutorials/kubernetes-basics/index.html b/docs/tutorials/kubernetes-basics/index.html new file mode 100644 index 0000000000..d678461e41 --- /dev/null +++ b/docs/tutorials/kubernetes-basics/index.html @@ -0,0 +1,105 @@ +--- +--- + + + + + + + + + +
      + +
      + +
      +
      +

      Kubernetes Basics

      +

      This tutorial provides a walkthrough of the basics of the Kubernetes cluster orchestration system. Each module contains some background information on major Kubernetes features and concepts, and includes an interactive online tutorial. These interactive tutorials let you manage a simple cluster and its containerized applications for yourself.

      +

      Using the interactive tutorials, you can learn to:

      +
        +
      • Deploy a containerized application on a cluster
        • +
      • Scale the deployment
        • +
      • Update the containerized application with a new software version
        • +
      • Debug the containerized application
        • +
      +

      The tutorials use Katacoda to run a virtual terminal in your web browser that runs Minikube, a small-scale local deployment of Kubernetes that can run anywhere. There's no need to install any software or configure anything; each interactive tutorial runs directly out of your web browser itself.

      +
      +
      + +
      + +
      +
      +

      What can Kubernetes do for you?

      +

      With modern web services, users expect applications to be available 24/7, and developers expect to deploy new versions of those applications several times a day. Containzerization helps package software to serve these goals, enabling applications to be released and updated in an easy and fast way without downtime. Kubernetes helps you make sure those containerized applications run where and when you want, and helps them find the resources and tools they need to work. Kubernetes is a production-ready, open source platform designed with the Google's accumulated experience in container orchestration, combined with best-of-breed ideas from the community.

      +
      +
      + +
      +

      Kubernetes Basics Modules

      +
      +
      +
      + +
      +
      1. Create a Kubernetes cluster
       +
      +
      +
      +
      +
      + +
      +
      2. Deploy an app
       +
      +
      +
      +
      +
      + +
      +
      3. Explore your app
       +
      +
      +
      +
      +
      + +
      +
      4. Expose your app publicly
       +
      +
      +
      +
      +
      + +
      +
      5. Scale up your app
       +
      +
      +
      +
      +
      + +
      +
      6. Update your app
       +
      +
      +
      +
      +
      + +
      +
      + Start the tutorial› +
      +
      + +
      + +
      + + + diff --git a/docs/tutorials/getting-started/public/css/styles.css b/docs/tutorials/kubernetes-basics/public/css/styles.css similarity index 100% rename from docs/tutorials/getting-started/public/css/styles.css rename to docs/tutorials/kubernetes-basics/public/css/styles.css diff --git a/docs/tutorials/getting-started/public/images/badge-01.svg b/docs/tutorials/kubernetes-basics/public/images/badge-01.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/badge-01.svg rename to docs/tutorials/kubernetes-basics/public/images/badge-01.svg diff --git a/docs/tutorials/getting-started/public/images/badge-02.svg b/docs/tutorials/kubernetes-basics/public/images/badge-02.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/badge-02.svg rename to docs/tutorials/kubernetes-basics/public/images/badge-02.svg diff --git a/docs/tutorials/getting-started/public/images/badge-03.svg b/docs/tutorials/kubernetes-basics/public/images/badge-03.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/badge-03.svg rename to docs/tutorials/kubernetes-basics/public/images/badge-03.svg diff --git a/docs/tutorials/getting-started/public/images/badge-04.svg b/docs/tutorials/kubernetes-basics/public/images/badge-04.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/badge-04.svg rename to docs/tutorials/kubernetes-basics/public/images/badge-04.svg diff --git a/docs/tutorials/getting-started/public/images/badge-05.svg b/docs/tutorials/kubernetes-basics/public/images/badge-05.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/badge-05.svg rename to docs/tutorials/kubernetes-basics/public/images/badge-05.svg diff --git a/docs/tutorials/getting-started/public/images/badge-06.svg b/docs/tutorials/kubernetes-basics/public/images/badge-06.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/badge-06.svg rename to docs/tutorials/kubernetes-basics/public/images/badge-06.svg diff --git a/docs/tutorials/getting-started/public/images/badge-07.svg b/docs/tutorials/kubernetes-basics/public/images/badge-07.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/badge-07.svg rename to docs/tutorials/kubernetes-basics/public/images/badge-07.svg diff --git a/docs/tutorials/getting-started/public/images/badge-08.svg b/docs/tutorials/kubernetes-basics/public/images/badge-08.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/badge-08.svg rename to docs/tutorials/kubernetes-basics/public/images/badge-08.svg diff --git a/docs/tutorials/getting-started/public/images/badge-09.svg b/docs/tutorials/kubernetes-basics/public/images/badge-09.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/badge-09.svg rename to docs/tutorials/kubernetes-basics/public/images/badge-09.svg diff --git a/docs/tutorials/getting-started/public/images/badge-1.png b/docs/tutorials/kubernetes-basics/public/images/badge-1.png similarity index 100% rename from docs/tutorials/getting-started/public/images/badge-1.png rename to docs/tutorials/kubernetes-basics/public/images/badge-1.png diff --git a/docs/tutorials/getting-started/public/images/dislike.svg b/docs/tutorials/kubernetes-basics/public/images/dislike.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/dislike.svg rename to docs/tutorials/kubernetes-basics/public/images/dislike.svg diff --git a/docs/tutorials/getting-started/public/images/like.svg b/docs/tutorials/kubernetes-basics/public/images/like.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/like.svg rename to docs/tutorials/kubernetes-basics/public/images/like.svg diff --git a/docs/tutorials/getting-started/public/images/logo.png b/docs/tutorials/kubernetes-basics/public/images/logo.png similarity index 100% rename from docs/tutorials/getting-started/public/images/logo.png rename to docs/tutorials/kubernetes-basics/public/images/logo.png diff --git a/docs/tutorials/getting-started/public/images/logo.svg b/docs/tutorials/kubernetes-basics/public/images/logo.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/logo.svg rename to docs/tutorials/kubernetes-basics/public/images/logo.svg diff --git a/docs/tutorials/getting-started/public/images/logo_2.svg b/docs/tutorials/kubernetes-basics/public/images/logo_2.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/logo_2.svg rename to docs/tutorials/kubernetes-basics/public/images/logo_2.svg diff --git a/docs/tutorials/getting-started/public/images/logo_mobile.png b/docs/tutorials/kubernetes-basics/public/images/logo_mobile.png similarity index 100% rename from docs/tutorials/getting-started/public/images/logo_mobile.png rename to docs/tutorials/kubernetes-basics/public/images/logo_mobile.png diff --git a/docs/tutorials/getting-started/public/images/module_01.svg b/docs/tutorials/kubernetes-basics/public/images/module_01.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/module_01.svg rename to docs/tutorials/kubernetes-basics/public/images/module_01.svg diff --git a/docs/tutorials/getting-started/public/images/module_01_cluster.svg b/docs/tutorials/kubernetes-basics/public/images/module_01_cluster.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/module_01_cluster.svg rename to docs/tutorials/kubernetes-basics/public/images/module_01_cluster.svg diff --git a/docs/tutorials/getting-started/public/images/module_02.svg b/docs/tutorials/kubernetes-basics/public/images/module_02.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/module_02.svg rename to docs/tutorials/kubernetes-basics/public/images/module_02.svg diff --git a/docs/tutorials/getting-started/public/images/module_02_first_app.svg b/docs/tutorials/kubernetes-basics/public/images/module_02_first_app.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/module_02_first_app.svg rename to docs/tutorials/kubernetes-basics/public/images/module_02_first_app.svg diff --git a/docs/tutorials/getting-started/public/images/module_03.svg b/docs/tutorials/kubernetes-basics/public/images/module_03.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/module_03.svg rename to docs/tutorials/kubernetes-basics/public/images/module_03.svg diff --git a/docs/tutorials/getting-started/public/images/module_03_nodes.svg b/docs/tutorials/kubernetes-basics/public/images/module_03_nodes.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/module_03_nodes.svg rename to docs/tutorials/kubernetes-basics/public/images/module_03_nodes.svg diff --git a/docs/tutorials/getting-started/public/images/module_03_pods.svg b/docs/tutorials/kubernetes-basics/public/images/module_03_pods.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/module_03_pods.svg rename to docs/tutorials/kubernetes-basics/public/images/module_03_pods.svg diff --git a/docs/tutorials/getting-started/public/images/module_04.svg b/docs/tutorials/kubernetes-basics/public/images/module_04.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/module_04.svg rename to docs/tutorials/kubernetes-basics/public/images/module_04.svg diff --git a/docs/tutorials/getting-started/public/images/module_04_labels.svg b/docs/tutorials/kubernetes-basics/public/images/module_04_labels.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/module_04_labels.svg rename to docs/tutorials/kubernetes-basics/public/images/module_04_labels.svg diff --git a/docs/tutorials/getting-started/public/images/module_04_services.svg b/docs/tutorials/kubernetes-basics/public/images/module_04_services.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/module_04_services.svg rename to docs/tutorials/kubernetes-basics/public/images/module_04_services.svg diff --git a/docs/tutorials/getting-started/public/images/module_05.svg b/docs/tutorials/kubernetes-basics/public/images/module_05.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/module_05.svg rename to docs/tutorials/kubernetes-basics/public/images/module_05.svg diff --git a/docs/tutorials/getting-started/public/images/module_05_scaling1.svg b/docs/tutorials/kubernetes-basics/public/images/module_05_scaling1.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/module_05_scaling1.svg rename to docs/tutorials/kubernetes-basics/public/images/module_05_scaling1.svg diff --git a/docs/tutorials/getting-started/public/images/module_05_scaling2.svg b/docs/tutorials/kubernetes-basics/public/images/module_05_scaling2.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/module_05_scaling2.svg rename to docs/tutorials/kubernetes-basics/public/images/module_05_scaling2.svg diff --git a/docs/tutorials/getting-started/public/images/module_06.svg b/docs/tutorials/kubernetes-basics/public/images/module_06.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/module_06.svg rename to docs/tutorials/kubernetes-basics/public/images/module_06.svg diff --git a/docs/tutorials/getting-started/public/images/module_06_rollingupdates1.svg b/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates1.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/module_06_rollingupdates1.svg rename to docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates1.svg diff --git a/docs/tutorials/getting-started/public/images/module_06_rollingupdates2.svg b/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates2.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/module_06_rollingupdates2.svg rename to docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates2.svg diff --git a/docs/tutorials/getting-started/public/images/module_06_rollingupdates3.svg b/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates3.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/module_06_rollingupdates3.svg rename to docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates3.svg diff --git a/docs/tutorials/getting-started/public/images/module_06_rollingupdates4.svg b/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates4.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/module_06_rollingupdates4.svg rename to docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates4.svg diff --git a/docs/tutorials/getting-started/public/images/nav_point.png b/docs/tutorials/kubernetes-basics/public/images/nav_point.png similarity index 100% rename from docs/tutorials/getting-started/public/images/nav_point.png rename to docs/tutorials/kubernetes-basics/public/images/nav_point.png diff --git a/docs/tutorials/getting-started/public/images/nav_point.svg b/docs/tutorials/kubernetes-basics/public/images/nav_point.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/nav_point.svg rename to docs/tutorials/kubernetes-basics/public/images/nav_point.svg diff --git a/docs/tutorials/getting-started/public/images/nav_point_active.png b/docs/tutorials/kubernetes-basics/public/images/nav_point_active.png similarity index 100% rename from docs/tutorials/getting-started/public/images/nav_point_active.png rename to docs/tutorials/kubernetes-basics/public/images/nav_point_active.png diff --git a/docs/tutorials/getting-started/public/images/nav_point_active.svg b/docs/tutorials/kubernetes-basics/public/images/nav_point_active.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/nav_point_active.svg rename to docs/tutorials/kubernetes-basics/public/images/nav_point_active.svg diff --git a/docs/tutorials/getting-started/public/images/nav_point_sub.svg b/docs/tutorials/kubernetes-basics/public/images/nav_point_sub.svg similarity index 100% rename from docs/tutorials/getting-started/public/images/nav_point_sub.svg rename to docs/tutorials/kubernetes-basics/public/images/nav_point_sub.svg diff --git a/docs/tutorials/getting-started/public/images/quiz_false.png b/docs/tutorials/kubernetes-basics/public/images/quiz_false.png similarity index 100% rename from docs/tutorials/getting-started/public/images/quiz_false.png rename to docs/tutorials/kubernetes-basics/public/images/quiz_false.png diff --git a/docs/tutorials/getting-started/public/images/quiz_true.png b/docs/tutorials/kubernetes-basics/public/images/quiz_true.png similarity index 100% rename from docs/tutorials/getting-started/public/images/quiz_true.png rename to docs/tutorials/kubernetes-basics/public/images/quiz_true.png diff --git a/docs/tutorials/getting-started/public/images/twitter.png b/docs/tutorials/kubernetes-basics/public/images/twitter.png similarity index 100% rename from docs/tutorials/getting-started/public/images/twitter.png rename to docs/tutorials/kubernetes-basics/public/images/twitter.png diff --git a/docs/tutorials/getting-started/scale-interactive.html b/docs/tutorials/kubernetes-basics/scale-interactive.html similarity index 62% rename from docs/tutorials/getting-started/scale-interactive.html rename to docs/tutorials/kubernetes-basics/scale-interactive.html index 9ab0d10557..d41b6cb36b 100644 --- a/docs/tutorials/getting-started/scale-interactive.html +++ b/docs/tutorials/kubernetes-basics/scale-interactive.html @@ -7,19 +7,13 @@ - +
      -
      -
      - ‹ Back -
      -
      -
      To interact with the Terminal, please use the desktop/tablet version @@ -29,7 +23,7 @@
      - Continue to Module 6› + Continue to Module 6›
      diff --git a/docs/tutorials/getting-started/scale-intro.html b/docs/tutorials/kubernetes-basics/scale-intro.html similarity index 83% rename from docs/tutorials/getting-started/scale-intro.html rename to docs/tutorials/kubernetes-basics/scale-intro.html index b06e574c7e..b4b5d47c91 100644 --- a/docs/tutorials/getting-started/scale-intro.html +++ b/docs/tutorials/kubernetes-basics/scale-intro.html @@ -7,23 +7,24 @@ - +
      -
      - ‹ Back + +
      +

      Objectives

      +
        +
      • Scale an app using kubectl.
        • +
      -
      -
      -
      - -
      +

      Scaling an application

      +

      In the previous modules we created a Deployment, and then exposed it publicly via a Service . The Deployment created only one Pod for running our application. When traffic increases, we will need to scale the application to keep up with user demand.

      Scaling is accomplished by changing the number of replicas in a Deployment

      @@ -59,11 +60,11 @@
      - +
      - +
      @@ -106,7 +107,7 @@
      - Start Interactive Tutorial › + Start Interactive Tutorial ›
      diff --git a/docs/tutorials/getting-started/update-interactive.html b/docs/tutorials/kubernetes-basics/update-interactive.html similarity index 68% rename from docs/tutorials/getting-started/update-interactive.html rename to docs/tutorials/kubernetes-basics/update-interactive.html index 5b399f06dc..a1399aeadb 100644 --- a/docs/tutorials/getting-started/update-interactive.html +++ b/docs/tutorials/kubernetes-basics/update-interactive.html @@ -7,19 +7,13 @@ - +
      -
      -
      - ‹ Back -
      -
      -
      To interact with the Terminal, please use the desktop/tablet version diff --git a/docs/tutorials/getting-started/update-intro.html b/docs/tutorials/kubernetes-basics/update-intro.html similarity index 81% rename from docs/tutorials/getting-started/update-intro.html rename to docs/tutorials/kubernetes-basics/update-intro.html index c6f65cfa58..b7867f3b1f 100644 --- a/docs/tutorials/getting-started/update-intro.html +++ b/docs/tutorials/kubernetes-basics/update-intro.html @@ -7,23 +7,24 @@ - +
      -
      - ‹ Back + +
      +

      Objectives

      +
        +
      • Perform a rolling update using kubectl.
        • +
      -
      -
      -
      - -
      +

      Updating an application

      +

      Users expect applications to be available all the time and developers are expected to deploy new versions of them several times a day. In Kubernetes this is done with rolling updates. Rolling updates allows Deployments to occur with zero downtime by incrementally updating Pods instances with new ones. The new Pods will be scheduled on Nodes with available resources.

      In the previous module we scaled our application to run multiple instances. This is a requirement for performing updates without affecting application availability. By default, the maximum number of Pods that can be unavailable during the update and the maximum number of new Pods that can be created, is one. Both options can be configured to either numbers or percentages (of Pods). @@ -61,19 +62,19 @@

      - +
      - +
      - +
      - +
      @@ -121,7 +122,7 @@
      - Start Interactive Tutorial › + Start Interactive Tutorial ›
      diff --git a/docs/tutorials/stateless-application/deployment-scale.yaml b/docs/tutorials/stateless-application/deployment-scale.yaml new file mode 100644 index 0000000000..2968b88360 --- /dev/null +++ b/docs/tutorials/stateless-application/deployment-scale.yaml @@ -0,0 +1,16 @@ +apiVersion: extensions/v1beta1 +kind: Deployment +metadata: + name: nginx-deployment +spec: + replicas: 4 + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.8 # Update the version of nginx from 1.7.9 to 1.8 + ports: + - containerPort: 80 diff --git a/docs/tutorials/stateless-application/expose-external-ip-address-service.md b/docs/tutorials/stateless-application/expose-external-ip-address-service.md index 65e13dd904..71112c6666 100644 --- a/docs/tutorials/stateless-application/expose-external-ip-address-service.md +++ b/docs/tutorials/stateless-application/expose-external-ip-address-service.md @@ -4,9 +4,8 @@ {% 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 exposes a stable IP address and provides load balancing for -an application that has two running instances. +clients can use to access an application running in a cluster. The Service +provides load balancing for an application that has two running instances. {% endcapture %} @@ -28,7 +27,7 @@ an application that has two running instances. {% capture objectives %} * Run two instances of a Hello World application. -* Create a Service object that exposes an external IP address. +* Create a Service object that exposes a node port. * Use the Service object to access the running application. {% endcapture %} @@ -55,63 +54,68 @@ an application that has two running instances. kubectl get deployments hello-world kubectl describe deployments hello-world -1. Display information about the ReplicaSet: +1. Display information about your ReplicaSet objects: - kubectl get replicasets hello-world - kubectl describe replicasets hello-world - -1. List the pods that are running the Hello World application: - - kubectl get pods --selector="run=load-balancer-example" - - The output is similar to this: - - NAME READY STATUS RESTARTS AGE - hello-world-2189936611-8fyp0 1/1 Running 0 6m - hello-world-2189936611-9isq8 1/1 Running 0 6m + kubectl get replicasets + kubectl describe replicasets 1. Create a Service object that exposes the deployment: - kubectl expose deployment hello-world --type="LoadBalancer" --name="example-service" + kubectl expose deployment hello-world --type=NodePort --name=example-service -1. Display the IP addresses for your service: +1. Display information about the Service: - kubectl get services example-service - - The output shows the internal IP address and the external IP address of - your service. If the external IP address shows as ``, repeat the - command. - - Note: If you are using Minikube, you don't get an external IP address. The - external IP address remains in the pending state. - - NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE - example-service 10.0.0.160 8080/TCP 40s - -1. Use your service to access the Hello World application: - - curl :8080 - - where `` is the external IP address of your - service. - - The output is a hello message from the application: - - Hello Kubernetes! - - Note: If you are using Minikube, enter these commands: - - kubectl cluster-info kubectl describe services example-service - The output displays the IP address of your Minikube node and the NodePort - value for your service. Enter this command to access the Hello World - application: + The output is similar to this: - curl : + Name: example-service + Namespace: default + Labels: run=load-balancer-example + Selector: run=load-balancer-example + Type: NodePort + IP: 10.32.0.16 + Port: 8080/TCP + NodePort: 31496/TCP + Endpoints: 10.200.1.4:8080,10.200.2.5:8080 + Session Affinity: None + No events. - where `` us the IP address of your Minikube node, - and `` is the NodePort value for your service. + Make a note of the NodePort value for the service. For example, + in the preceding output, the NodePort value is 31496. + +1. List the pods that are running the Hello World application: + + kubectl get pods --selector="run=load-balancer-example" --output=wide + + The output is similar to this: + + NAME READY STATUS ... IP NODE + hello-world-2895499144-bsbk5 1/1 Running ... 10.200.1.4 worker1 + hello-world-2895499144-m1pwt 1/1 Running ... 10.200.2.5 worker2 + +1. Get the public IP address of one of your nodes that is running + a Hello World pod. How you get this address depends on how you set + up your cluster. For example, if you are using Minikube, you can + see the node address by running `kubectl cluster-info`. If you are + using Google Compute Engine instances, you can use the + `gcloud compute instances list` command to see the public addresses of your + nodes. + +1. On your chosen node, create a firewall rule that allows TCP traffic + on your node port. For example, if your Service has a NodePort value of + 31568, create a firewall rule that allows TCP traffic on port 31568. + +1. Use the node address and node port to access the Hello World application: + + curl http://: + + where `` us the public IP address of your node, + and `` is the NodePort value for your service. + + The response to a successful request is a hello message: + + Hello Kubernetes! ### Using a service configuration file diff --git a/docs/tutorials/stateless-application/expose-external-ip-address.md b/docs/tutorials/stateless-application/expose-external-ip-address.md new file mode 100644 index 0000000000..63aabb813d --- /dev/null +++ b/docs/tutorials/stateless-application/expose-external-ip-address.md @@ -0,0 +1,153 @@ +--- +--- + +{% capture overview %} + +This page shows how to create a Kubernetes Service object that exposees an +external IP address. + +{% endcapture %} + + +{% capture prerequisites %} + +* Install [kubectl](http://kubernetes.io/docs/user-guide/prereqs). + +* Use a cloud provider like Google Container Engine or Amazon Web Services to + create a Kubernetes cluster. This tutorial creates an + [external load balancer](/docs/user-guide/load-balancer/), + which requires a cloud provider. + +* Configure `kubectl` to communicate with your Kubernetes API server. For + instructions, see the documentation for your cloud provider. + +{% endcapture %} + + +{% capture 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. + +{% endcapture %} + + +{% capture lessoncontent %} + +### Creating a service for an application running in five pods + +1. Run a Hello World application in your cluster: + + kubectl run hello-world --replicas=5 --labels="run=load-balancer-example" --image=gcr.io/google-samples/node-hello:1.0 --port=8080 + + The preceding command creates a + [Deployment](/docs/user-guide/deployments/) + object and an associated + [ReplicaSet](/docs/user-guide/replicasets/) + object. The ReplicaSet has five + [Pods](/docs/user-guide/pods/), + each of which runs the Hello World application. + +1. Display information about the Deployment: + + kubectl get deployments hello-world + kubectl describe deployments hello-world + +1. Display information about your ReplicaSet objects: + + kubectl get replicasets + kubectl describe replicasets + +1. Create a Service object that exposes the deployment: + + kubectl expose deployment hello-world --type=LoadBalancer --name=my-service + +1. Display information about the Service: + + kubectl get services my-service + + The output is similar to this: + + NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE + my-service 10.3.245.137 104.198.205.71 8080/TCP 54s + + Note: If the external IP address is shown as , wait for a minute + and enter the same command again. + +1. Display detailed information about the Service: + + kubectl describe services my-service + + The output is similar to this: + + Name: my-service + Namespace: default + Labels: run=load-balancer-example + Selector: run=load-balancer-example + Type: LoadBalancer + IP: 10.3.245.137 + LoadBalancer Ingress: 104.198.205.71 + Port: 8080/TCP + NodePort: 32377/TCP + Endpoints: 10.0.0.6:8080,10.0.1.6:8080,10.0.1.7:8080 + 2 more... + Session Affinity: None + Events: + + Make a note of the external IP address exposed by your service. In this + example, the external IP address is 104.198.205.71. Also note + the value of Port. In this example, the port is 8080. + +1. In the preceding output, you can see that the service has several endpoints: + 10.0.0.6:8080,10.0.1.6:8080,10.0.1.7:8080 + 2 more. These are internal + addresses of the pods that are running the Hello World application. To + verify these are pod addresses, enter this command: + + kubectl get pods --output=wide + + The output is similar to this: + + NAME ... IP NODE + hello-world-2895499144-1jaz9 ... 10.0.1.6 gke-cluster-1-default-pool-e0b8d269-1afc + hello-world-2895499144-2e5uh ... 0.0.1.8 gke-cluster-1-default-pool-e0b8d269-1afc + hello-world-2895499144-9m4h1 ... 10.0.0.6 gke-cluster-1-default-pool-e0b8d269-5v7a + hello-world-2895499144-o4z13 ... 10.0.1.7 gke-cluster-1-default-pool-e0b8d269-1afc + hello-world-2895499144-segjf ... 10.0.2.5 gke-cluster-1-default-pool-e0b8d269-cpuc + +1. Use the external IP address to access the Hello World application: + + curl http://: + + where `` us the external IP address of your Service, + and `` is the value of `Port` in your Service description. + + The response to a successful request is a hello message: + + Hello Kubernetes! + +{% endcapture %} + + +{% capture cleanup %} + +To delete the Service, enter this command: + + kubectl delete services my-service + +To delete the Deployment, the ReplicaSet, and the Pods that are running +the Hello World application, enter this command: + + kubectl delete deployment hello-world + +{% endcapture %} + + +{% capture whatsnext %} + +Learn more about +[connecting applications with services](/docs/user-guide/connecting-applications/). +{% endcapture %} + +{% include templates/tutorial.md %} + + diff --git a/docs/tutorials/stateless-application/run-stateless-application-deployment.md b/docs/tutorials/stateless-application/run-stateless-application-deployment.md index 70aeb925c2..20a7aff243 100644 --- a/docs/tutorials/stateless-application/run-stateless-application-deployment.md +++ b/docs/tutorials/stateless-application/run-stateless-application-deployment.md @@ -94,6 +94,30 @@ specifies that the deployment should be updated to use nginx 1.8. kubectl get pods -l app=nginx +### Scaling the application by increasing the replica count + +You can increase the number of pods in your Deployment by applying a new YAML +file. This YAML file sets `replicas` to 4, which specifies that the Deployment +should have four pods: + +{% include code.html language="yaml" file="deployment-scale.yaml" ghlink="/docs/tutorials/stateless-application/deployment-scale.yaml" %} + +1. Apply the new YAML file: + + kubectl apply -f $REPO/docs/tutorials/stateless-application/deployment-scale.yaml + +1. Verify that the Deployment has four pods: + + kubectl get pods + + The output is similar to this: + + NAME READY STATUS RESTARTS AGE + nginx-deployment-148880595-4zdqq 1/1 Running 0 25s + nginx-deployment-148880595-6zgi1 1/1 Running 0 25s + nginx-deployment-148880595-fxcez 1/1 Running 0 2m + nginx-deployment-148880595-rwovn 1/1 Running 0 2m + ### Deleting a deployment Delete the deployment by name: diff --git a/docs/user-guide/accessing-the-cluster.md b/docs/user-guide/accessing-the-cluster.md index c42adb4c6e..6f78ab5293 100644 --- a/docs/user-guide/accessing-the-cluster.md +++ b/docs/user-guide/accessing-the-cluster.md @@ -27,7 +27,7 @@ $ kubectl config view ``` Many of the [examples](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/) provide an introduction to using -kubectl and complete documentation is found in the [kubectl manual](/docs/user-guide/kubectl/kubectl). +kubectl and complete documentation is found in the [kubectl manual](/docs/user-guide/kubectl/index). ### Directly accessing the REST API diff --git a/docs/user-guide/connecting-applications.md b/docs/user-guide/connecting-applications.md index 4f0b804a4e..f75187d6c6 100644 --- a/docs/user-guide/connecting-applications.md +++ b/docs/user-guide/connecting-applications.md @@ -9,7 +9,7 @@ assignees: * TOC {:toc} -# The Kubernetes model for connecting containers +## The Kubernetes model for connecting containers Now that you have a continuously running, replicated application you can expose it on a network. Before discussing the Kubernetes approach to networking, it is worthwhile to contrast it with the "normal" way networking works with Docker. diff --git a/docs/user-guide/connecting-to-applications-port-forward.md b/docs/user-guide/connecting-to-applications-port-forward.md index 742730229f..5876d2ab48 100644 --- a/docs/user-guide/connecting-to-applications-port-forward.md +++ b/docs/user-guide/connecting-to-applications-port-forward.md @@ -1,50 +1,50 @@ ---- -assignees: -- caesarxuchao -- mikedanese - ---- - -kubectl port-forward forwards connections to a local port to a port on a pod. Its man page is available [here](/docs/user-guide/kubectl/kubectl_port-forward). Compared to [kubectl proxy](/docs/user-guide/accessing-the-cluster/#using-kubectl-proxy), `kubectl port-forward` is more generic as it can forward TCP traffic while `kubectl proxy` can only forward HTTP traffic. This guide demonstrates how to use `kubectl port-forward` to connect to a Redis database, which may be useful for database debugging. - -## Creating a Redis master - -```shell -$ kubectl create -f examples/redis/redis-master.yaml -pods/redis-master -``` - -wait until the Redis master pod is Running and Ready, - -```shell -$ kubectl get pods -NAME READY STATUS RESTARTS AGE -redis-master 2/2 Running 0 41s -``` - -## Connecting to the Redis master[a] - -The Redis master is listening on port 6379, to verify this, - -```shell{% raw %} -$ kubectl get pods redis-master --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}' -6379{% endraw %} -``` - -then we forward the port 6379 on the local workstation to the port 6379 of pod redis-master, - -```shell -$ kubectl port-forward redis-master 6379:6379 -I0710 14:43:38.274550 3655 portforward.go:225] Forwarding from 127.0.0.1:6379 -> 6379 -I0710 14:43:38.274797 3655 portforward.go:225] Forwarding from [::1]:6379 -> 6379 -``` - -To verify the connection is successful, we run a redis-cli on the local workstation, - -```shell -$ redis-cli -127.0.0.1:6379> ping -PONG -``` - -Now one can debug the database from the local workstation. +--- +assignees: +- caesarxuchao +- mikedanese + +--- + +kubectl port-forward forwards connections to a local port to a port on a pod. Its man page is available [here](/docs/user-guide/kubectl/kubectl_port-forward). Compared to [kubectl proxy](/docs/user-guide/accessing-the-cluster/#using-kubectl-proxy), `kubectl port-forward` is more generic as it can forward TCP traffic while `kubectl proxy` can only forward HTTP traffic. This guide demonstrates how to use `kubectl port-forward` to connect to a Redis database, which may be useful for database debugging. + +## Creating a Redis master + +```shell +$ kubectl create -f examples/redis/redis-master.yaml +pods/redis-master +``` + +wait until the Redis master pod is Running and Ready, + +```shell +$ kubectl get pods +NAME READY STATUS RESTARTS AGE +redis-master 2/2 Running 0 41s +``` + +## Connecting to the Redis master[a] + +The Redis master is listening on port 6379, to verify this, + +```shell{% raw %} +$ kubectl get pods redis-master --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}' +6379{% endraw %} +``` + +then we forward the port 6379 on the local workstation to the port 6379 of pod redis-master, + +```shell +$ kubectl port-forward redis-master 6379:6379 +I0710 14:43:38.274550 3655 portforward.go:225] Forwarding from 127.0.0.1:6379 -> 6379 +I0710 14:43:38.274797 3655 portforward.go:225] Forwarding from [::1]:6379 -> 6379 +``` + +To verify the connection is successful, we run a redis-cli on the local workstation, + +```shell +$ redis-cli +127.0.0.1:6379> ping +PONG +``` + +Now one can debug the database from the local workstation. diff --git a/docs/user-guide/connecting-to-applications-proxy.md b/docs/user-guide/connecting-to-applications-proxy.md index 4e9867a339..5404d2e769 100644 --- a/docs/user-guide/connecting-to-applications-proxy.md +++ b/docs/user-guide/connecting-to-applications-proxy.md @@ -1,32 +1,32 @@ ---- -assignees: -- caesarxuchao -- lavalamp - ---- - -You have seen the [basics](/docs/user-guide/accessing-the-cluster) about `kubectl proxy` and `apiserver proxy`. This guide shows how to use them together to access a service([kube-ui](/docs/user-guide/ui)) running on the Kubernetes cluster from your workstation. - - -## Getting the apiserver proxy URL of kube-ui - -kube-ui is deployed as a cluster add-on. To find its apiserver proxy URL, - -```shell -$ kubectl cluster-info | grep "KubeUI" -KubeUI is running at https://173.255.119.104/api/v1/proxy/namespaces/kube-system/services/kube-ui -``` - -if this command does not find the URL, try the steps [here](/docs/user-guide/ui/#accessing-the-ui). - - -## Connecting to the kube-ui service from your local workstation - -The above proxy URL is an access to the kube-ui service provided by the apiserver. To access it, you still need to authenticate to the apiserver. `kubectl proxy` can handle the authentication. - -```shell -$ kubectl proxy --port=8001 -Starting to serve on localhost:8001 -``` - +--- +assignees: +- caesarxuchao +- lavalamp + +--- + +You have seen the [basics](/docs/user-guide/accessing-the-cluster) about `kubectl proxy` and `apiserver proxy`. This guide shows how to use them together to access a service([kube-ui](/docs/user-guide/ui)) running on the Kubernetes cluster from your workstation. + + +## Getting the apiserver proxy URL of kube-ui + +kube-ui is deployed as a cluster add-on. To find its apiserver proxy URL, + +```shell +$ kubectl cluster-info | grep "KubeUI" +KubeUI is running at https://173.255.119.104/api/v1/proxy/namespaces/kube-system/services/kube-ui +``` + +if this command does not find the URL, try the steps [here](/docs/user-guide/ui/#accessing-the-ui). + + +## Connecting to the kube-ui service from your local workstation + +The above proxy URL is an access to the kube-ui service provided by the apiserver. To access it, you still need to authenticate to the apiserver. `kubectl proxy` can handle the authentication. + +```shell +$ kubectl proxy --port=8001 +Starting to serve on localhost:8001 +``` + Now you can access the kube-ui service on your local workstation at [http://localhost:8001/api/v1/proxy/namespaces/kube-system/services/kube-ui](http://localhost:8001/api/v1/proxy/namespaces/kube-system/services/kube-ui) \ No newline at end of file diff --git a/docs/user-guide/deployments.md b/docs/user-guide/deployments.md index 1fae4ddd7d..d160cce1e7 100644 --- a/docs/user-guide/deployments.md +++ b/docs/user-guide/deployments.md @@ -451,7 +451,8 @@ nginx-deployment-2035384211 0 0 1h nginx-deployment-3066724191 0 0 1h ``` -Note: A paused Deployment cannot be scaled at this moment, and we will add this feature in 1.3 release, see [issue #20853](https://github.com/kubernetes/kubernetes/issues/20853). You cannot rollback a paused Deployment either, and you should resume a Deployment first before doing a rollback. +Note: You cannot rollback a paused Deployment until you resume it. + ## Use Cases diff --git a/docs/user-guide/federation/federated-ingress.md b/docs/user-guide/federation/federated-ingress.md index 42e5ad536d..87965a3fc7 100644 --- a/docs/user-guide/federation/federated-ingress.md +++ b/docs/user-guide/federation/federated-ingress.md @@ -18,7 +18,7 @@ automatically checks the health of the pods comprising the service, and avoids sending requests to unresponsive or slow pods (or entire unresponsive clusters). -Federated Ingress is released as a beta feature, and supports Google Cloud (GKE, +Federated Ingress is released as an alpha feature, and supports Google Cloud Platform (GKE, GCE and hybrid scenarios involving both) in Kubernetes v1.4. Work is under way to support other cloud providers such as AWS, and other hybrid cloud scenarios (e.g. services spanning private on-premise as well as public cloud Kubernetes diff --git a/docs/user-guide/federation/replicasets.md b/docs/user-guide/federation/replicasets.md index 805da57782..d0ceaa8bde 100644 --- a/docs/user-guide/federation/replicasets.md +++ b/docs/user-guide/federation/replicasets.md @@ -35,7 +35,7 @@ The API for Federated Replica Set is 100% compatible with the API for traditional Kubernetes Replica Set. You can create a replica set by sending a request to the federation apiserver. -You can do that using [kubectl](/docs/user-guide/kubectl/kubectl/) by running: +You can do that using [kubectl](/docs/user-guide/kubectl/) by running: ``` shell kubectl --context=federation-cluster create -f myrs.yaml diff --git a/docs/user-guide/federation/secrets.md b/docs/user-guide/federation/secrets.md index 7e7a27fc7a..763b53e98e 100644 --- a/docs/user-guide/federation/secrets.md +++ b/docs/user-guide/federation/secrets.md @@ -35,7 +35,7 @@ The API for Federated Secret is 100% compatible with the API for traditional Kubernetes Secret. You can create a secret by sending a request to the federation apiserver. -You can do that using [kubectl](/docs/user-guide/kubectl/kubectl/) by running: +You can do that using [kubectl](/docs/user-guide/kubectl/) by running: ``` shell kubectl --context=federation-cluster create -f mysecret.yaml diff --git a/docs/user-guide/garbage-collection.md b/docs/user-guide/garbage-collection.md index bae6ed442f..2dc8e0c36a 100644 --- a/docs/user-guide/garbage-collection.md +++ b/docs/user-guide/garbage-collection.md @@ -32,5 +32,7 @@ Synchronous garbage collection will be supported in 1.5 (tracking [issue](https: If you specify `deleteOptions.orphanDependents=true`, or leave it blank, then the GC will first reset the `ownerReferences` in the dependents, then delete the owner. Note that the deletion of the owner object is asynchronous, that is, a 200 OK response will be sent by the API server before the owner object gets deleted. ### Other references + [Design Doc](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/garbage-collection.md) + [Known issues](https://github.com/kubernetes/kubernetes/issues/26120) diff --git a/docs/user-guide/getting-into-containers.md b/docs/user-guide/getting-into-containers.md index 25f0f5a3e4..f45da7b0eb 100644 --- a/docs/user-guide/getting-into-containers.md +++ b/docs/user-guide/getting-into-containers.md @@ -1,74 +1,74 @@ ---- -assignees: -- caesarxuchao -- mikedanese - ---- - -Developers can use `kubectl exec` to run commands in a container. This guide demonstrates two use cases. - -## Using kubectl exec to check the environment variables of a container - -Kubernetes exposes [services](/docs/user-guide/services/#environment-variables) through environment variables. It is convenient to check these environment variables using `kubectl exec`. - -We first create a pod and a service, - -```shell -$ kubectl create -f examples/guestbook/redis-master-controller.yaml -$ kubectl create -f examples/guestbook/redis-master-service.yaml -``` -wait until the pod is Running and Ready, - -```shell -$ kubectl get pod -NAME READY REASON RESTARTS AGE -redis-master-ft9ex 1/1 Running 0 12s -``` - -then we can check the environment variables of the pod, - -```shell -$ kubectl exec redis-master-ft9ex env -... -REDIS_MASTER_SERVICE_PORT=6379 -REDIS_MASTER_SERVICE_HOST=10.0.0.219 -... -``` - -We can use these environment variables in applications to find the service. - - -## Using kubectl exec to check the mounted volumes - -It is convenient to use `kubectl exec` to check if the volumes are mounted as expected. -We first create a Pod with a volume mounted at /data/redis, - -```shell -kubectl create -f docs/user-guide/walkthrough/pod-redis.yaml -``` - -wait until the pod is Running and Ready, - -```shell -$ kubectl get pods -NAME READY REASON RESTARTS AGE -storage 1/1 Running 0 1m -``` - -we then use `kubectl exec` to verify that the volume is mounted at /data/redis, - -```shell -$ kubectl exec storage ls /data -redis -``` - -## Using kubectl exec to open a bash terminal in a pod - -After all, open a terminal in a pod is the most direct way to introspect the pod. Assuming the pod/storage is still running, run - -```shell -$ kubectl exec -ti storage -- bash -root@storage:/data# -``` - +--- +assignees: +- caesarxuchao +- mikedanese + +--- + +Developers can use `kubectl exec` to run commands in a container. This guide demonstrates two use cases. + +## Using kubectl exec to check the environment variables of a container + +Kubernetes exposes [services](/docs/user-guide/services/#environment-variables) through environment variables. It is convenient to check these environment variables using `kubectl exec`. + +We first create a pod and a service, + +```shell +$ kubectl create -f examples/guestbook/redis-master-controller.yaml +$ kubectl create -f examples/guestbook/redis-master-service.yaml +``` +wait until the pod is Running and Ready, + +```shell +$ kubectl get pod +NAME READY REASON RESTARTS AGE +redis-master-ft9ex 1/1 Running 0 12s +``` + +then we can check the environment variables of the pod, + +```shell +$ kubectl exec redis-master-ft9ex env +... +REDIS_MASTER_SERVICE_PORT=6379 +REDIS_MASTER_SERVICE_HOST=10.0.0.219 +... +``` + +We can use these environment variables in applications to find the service. + + +## Using kubectl exec to check the mounted volumes + +It is convenient to use `kubectl exec` to check if the volumes are mounted as expected. +We first create a Pod with a volume mounted at /data/redis, + +```shell +kubectl create -f docs/user-guide/walkthrough/pod-redis.yaml +``` + +wait until the pod is Running and Ready, + +```shell +$ kubectl get pods +NAME READY REASON RESTARTS AGE +storage 1/1 Running 0 1m +``` + +we then use `kubectl exec` to verify that the volume is mounted at /data/redis, + +```shell +$ kubectl exec storage ls /data +redis +``` + +## Using kubectl exec to open a bash terminal in a pod + +After all, open a terminal in a pod is the most direct way to introspect the pod. Assuming the pod/storage is still running, run + +```shell +$ kubectl exec -ti storage -- bash +root@storage:/data# +``` + This gets you a terminal. \ No newline at end of file diff --git a/docs/user-guide/horizontal-pod-autoscaling/hpa-php-apache.yaml b/docs/user-guide/horizontal-pod-autoscaling/hpa-php-apache.yaml index 72d402743d..7ccdcabafd 100644 --- a/docs/user-guide/horizontal-pod-autoscaling/hpa-php-apache.yaml +++ b/docs/user-guide/horizontal-pod-autoscaling/hpa-php-apache.yaml @@ -1,14 +1,13 @@ -apiVersion: extensions/v1beta1 +apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata: name: php-apache namespace: default spec: - scaleRef: + scaleTargetRef: + apiVersion: extensions/v1beta1 kind: Deployment name: php-apache - subresource: scale minReplicas: 1 maxReplicas: 10 - cpuUtilization: - targetPercentage: 50 + targetCPUUtilizationPercentage: 50 diff --git a/docs/user-guide/horizontal-pod-autoscaling/walkthrough.md b/docs/user-guide/horizontal-pod-autoscaling/walkthrough.md index d445b854e4..0f288352a0 100644 --- a/docs/user-guide/horizontal-pod-autoscaling/walkthrough.md +++ b/docs/user-guide/horizontal-pod-autoscaling/walkthrough.md @@ -127,20 +127,19 @@ Here CPU utilization dropped to 0, and so HPA autoscaled the number of replicas Instead of using `kubectl autoscale` command we can use the [hpa-php-apache.yaml](/docs/user-guide/horizontal-pod-autoscaling/hpa-php-apache.yaml) file, which looks like this: ```yaml -apiVersion: extensions/v1beta1 +apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata: name: php-apache namespace: default spec: - scaleRef: + scaleTargetRef: + apiVersion: extensions/v1beta1 kind: Deployment name: php-apache - subresource: scale minReplicas: 1 maxReplicas: 10 - cpuUtilization: - targetPercentage: 50 + targetCPUUtilizationPercentage: 50 ``` We will create the autoscaler by executing the following command: diff --git a/docs/user-guide/index.md b/docs/user-guide/index.md index 44dd71f41e..70bcb5be6d 100644 --- a/docs/user-guide/index.md +++ b/docs/user-guide/index.md @@ -89,5 +89,5 @@ Pods and containers * [Images and registries](/docs/user-guide/images/) * [Migrating from docker-cli to kubectl](/docs/user-guide/docker-cli-to-kubectl/) * [Configuration Best Practices and Tips](/docs/user-guide/config-best-practices/) - * [Assign pods to selected nodes](https://github.com/kubernetes/kubernetes.github.io/tree/{{page.docsbranch}}/docs/user-guide/node-selection/) - * [Perform a rolling update on a running group of pods](https://github.com/kubernetes/kubernetes.github.io/tree/{{page.docsbranch}}/docs/user-guide/update-demo/) + * [Assign pods to selected nodes](/docs/user-guide/node-selection/) + * [Perform a rolling update on a running group of pods](/docs/user-guide/update-demo/) diff --git a/docs/user-guide/jobs.md b/docs/user-guide/jobs.md index 266444753a..4e42b8fcef 100644 --- a/docs/user-guide/jobs.md +++ b/docs/user-guide/jobs.md @@ -374,6 +374,6 @@ driver, and then cleans up. An advantage of this approach is that the overall process gets the completion guarantee of a Job object, but complete control over what pods are created and how work is assigned to them. -## Future work +## Scheduled Jobs -Support for creating Jobs at specified times/dates (i.e. cron) is expected in [1.4](https://github.com/kubernetes/kubernetes/pull/11980). +Support for creating Jobs at specified times/dates (i.e. cron) is available in Kubernetes [1.4](https://github.com/kubernetes/kubernetes/pull/11980). More information is available in the [scheduled job documents](http://kubernetes.io/docs/user-guide/scheduled-jobs/) diff --git a/docs/user-guide/jobs/work-queue-1/index.md b/docs/user-guide/jobs/work-queue-1/index.md index e579f4b295..9b0735b574 100644 --- a/docs/user-guide/jobs/work-queue-1/index.md +++ b/docs/user-guide/jobs/work-queue-1/index.md @@ -166,7 +166,7 @@ We will use the `amqp-consume` utility to read the message from the queue and run our actual program. Here is a very simple example program: -{% include code.html language="python" file="worker.py" ghlink="/docs/user-guide/job/work-queue-1/worker.py" %} +{% include code.html language="python" file="worker.py" ghlink="/docs/user-guide/jobs/work-queue-1/worker.py" %} Now, build an image. If you are working in the source tree, then change directory to `examples/job/work-queue-1`. @@ -204,7 +204,7 @@ Here is a job definition. You'll need to make a copy of the Job and edit the image to match the name you used, and call it `./job.yaml`. -{% include code.html language="yaml" file="job.yaml" ghlink="/docs/user-guide/job/work-queue-1/job.yaml" %} +{% include code.html language="yaml" file="job.yaml" ghlink="/docs/user-guide/jobs/work-queue-1/job.yaml" %} In this example, each pod works on one item from the queue and then exits. So, the completion count of the Job corresponds to the number of work items @@ -258,12 +258,12 @@ want to consider one of the other [job patterns](/docs/user-guide/jobs/#job-patt This approach creates a pod for every work item. If your work items only take a few seconds, though, creating a Pod for every work item may add a lot of overhead. Consider another -[example](/docs/user-guide/job/work-queue-2), that executes multiple work items per Pod. +[example](/docs/user-guide/jobs/work-queue-2/), that executes multiple work items per Pod. In this example, we used use the `amqp-consume` utility to read the message from the queue and run our actual program. This has the advantage that you do not need to modify your program to be aware of the queue. -A [different example](/docs/user-guide/job/work-queue-2), shows how to +A [different example](/docs/user-guide/jobs/work-queue-2/), shows how to communicate with the work queue using a client library. ## Caveats diff --git a/docs/user-guide/jobs/work-queue-2/index.md b/docs/user-guide/jobs/work-queue-2/index.md index 328ece5a64..fc31850c91 100644 --- a/docs/user-guide/jobs/work-queue-2/index.md +++ b/docs/user-guide/jobs/work-queue-2/index.md @@ -108,7 +108,7 @@ called rediswq.py ([Download](rediswq.py?raw=true)). The "worker" program in each Pod of the Job uses the work queue client library to get work. Here it is: -{% include code.html language="python" file="worker.py" ghlink="/docs/user-guide/job/work-queue-2/worker.py" %} +{% include code.html language="python" file="worker.py" ghlink="/docs/user-guide/jobs/work-queue-2/worker.py" %} If you are working from the source tree, change directory to the `examples/job/work-queue-2` directory. @@ -147,7 +147,7 @@ gcloud docker push gcr.io//job-wq-2 Here is the job definition: -{% include code.html language="yaml" file="job.yaml" ghlink="/docs/user-guide/job/work-queue-2/job.yaml" %} +{% include code.html language="yaml" file="job.yaml" ghlink="/docs/user-guide/jobs/work-queue-2/job.yaml" %} Be sure to edit the job template to change `gcr.io/myproject` to your own path. diff --git a/docs/user-guide/kubectl-cheatsheet.md b/docs/user-guide/kubectl-cheatsheet.md index b2e1c51fa9..14e6850f37 100644 --- a/docs/user-guide/kubectl-cheatsheet.md +++ b/docs/user-guide/kubectl-cheatsheet.md @@ -3,24 +3,57 @@ assignees: - bgrant0607 - erictune - krousey +- clove --- -An assortment of compact kubectl examples -See also: [Kubectl overview](/docs/user-guide/kubectl-overview/) and [JsonPath guide](/docs/user-guide/jsonpath). +See also: [Kubectl Overview](/docs/user-guide/kubectl-overview/) and [JsonPath Guide](/docs/user-guide/jsonpath). + +## Kubectl Autocomplete + +```console +$ source <(kubectl completion bash) # setup autocomplete in bash +$ source <(kubectl completion zsh) # setup autocomplete in zsh +``` + +## Kubectl Context and Configuration + +Set which Kubernetes cluster `kubectl` communicates with and modify configuration +information. See [kubeconfig file](/docs/user-guide/kubeconfig-file/) documentation for +detailed config file information. + +```console +$ kubectl config view # Show Merged kubeconfig settings. + +# use multiple kubeconfig files at the same time and view merged config +$ KUBECONFIG=~/.kube/config:~/.kube/kubconfig2 kubectl config view + +# Get the password for the e2e user +$ kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}' + +$ kubectl config current-context # Display the current-context +$ kubectl config use-context my-cluster-name # set the default context to my-cluster-name + +# add a new cluster to your kubeconf that supports basic auth +$ kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword + +# set a context utilizing a specific username and namespace. +$ kubectl config set-context gce --user=cluster-admin --namespace=foo \ + && kubectl config use-context gce +``` ## Creating Objects -```shell -$ kubectl create -f ./file.yml # create resource(s) in a json or yaml file +Kubernetes manifests can be defined in json or yaml. The file extension `.yaml`, +`.yml`, and `.json` can be used. -$ kubectl create -f ./file1.yml -f ./file2.yaml # create resource(s) in a json or yaml file - -$ kubectl create -f ./dir # create resources in all .json, .yml, and .yaml files in dir - -# Create from a URL - -$ kubectl create -f http://www.fpaste.org/279276/48569091/raw/ +```console +$ kubectl create -f ./my-manifest.yaml # create resource(s) +$ kubectl create -f ./my1.yaml -f ./my2.yaml # create from multiple files +$ kubectl create -f ./dir # create resource(s) in all manifest files in dir +$ kubectl create -f https://git.io/vPieo # create resource(s) from url +$ kubectl run nginx --image=nginx # start a single instance of nginx +$ kubectl explain pods,svc # get the documentation for pod and svc manifests # Create multiple YAML objects from stdin $ cat < # List a particular replication controller -$ kubectl get replicationcontroller # List a particular RC +$ kubectl get deployment my-dep # List a particular deployment -# Verbose output -$ kubectl describe nodes -$ kubectl describe pods -$ kubectl describe pods/ # Equivalent to previous -$ kubectl describe pods # Lists pods created by using common prefix +# Describe commands with verbose output +$ kubectl describe nodes my-node +$ kubectl describe pods my-pod -# List Services Sorted by Name -$ kubectl get services --sort-by=.metadata.name +$ kubectl get services --sort-by=.metadata.name # List Services Sorted by Name # List pods Sorted by Restart Count $ kubectl get pods --sort-by='.status.containerStatuses[0].restartCount' # Get the version label of all pods with label app=cassandra -$ kubectl get pods --selector=app=cassandra rc -o 'jsonpath={.items[*].metadata.labels.version}' +$ kubectl get pods --selector=app=cassandra rc -o \ + jsonpath='{.items[*].metadata.labels.version}' # Get ExternalIPs of all nodes $ kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' # List Names of Pods that belong to Particular RC # "jq" command useful for transformations that are too complex for jsonpath -$ sel=$(kubectl get rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"') -$ sel=${sel%?} # Remove trailing comma -$ pods=$(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name}) -$ echo $pods +$ sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?} +$ echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name}) # Check which nodes are ready -$ kubectl get nodes -o jsonpath='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}'| tr ';' "\n" | grep "Ready=True" +$ JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \ + && kubectl get nodes -o jsonpath=$JSONPATH | grep "Ready=True" ``` -## Modifying and Deleting Resources +## Updating Resources -```shell -$ kubectl label pods new-label=awesome # Add a Label -$ kubectl annotate pods icon-url=http://goo.gl/XXBTWq # Add an annotation +```console +$ kubectl rolling-update frontend-v1 -f frontend-v2.json # Rolling update pods of frontend-v1 +$ kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2 # Change the name of the resource and update the image +$ kubectl rolling-update frontend --image=image:v2 # Update the pods image of frontend +$ kubectl rolling-update frontend-v1 frontend-v2 --rollback # Abort existing rollout in progress +$ cat pod.json | kubectl replace -f - # Replace a pod based on the JSON passed into stdin -# TODO: examples of kubectl edit, patch, delete, replace, scale, and rolling-update commands. +# Force replace, delete and then re-create the resource. Will cause a service outage. +$ kubectl replace --force -f ./pod.json + +# Create a service for a replicated nginx, which serves on port 80 and connects to the containers on port 8000 +$ kubectl expose rc nginx --port=80 --target-port=8000 + +# Update a single-container pod's image version (tag) to v4 +$ kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f - + +$ kubectl label pods my-pod new-label=awesome # Add a Label +$ kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # Add an annotation +$ kubectl autoscale deployment foo --min=2 --max=10 # Auto scale a deployment "foo" +``` + +## Patching Resources +Patch a resource(s) with a strategic merge patch. + +```console +$ kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' # Partially update a node + +# Update a container's image; spec.containers[*].name is required because it's a merge key +$ kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}' + +# Update a container's image using a json patch with positional arrays +$ kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]' +``` + +## Editing Resources +The edit any API resource in an editor. + +```console +$ kubectl edit svc/docker-registry # Edit the service named docker-registry +$ KUBE_EDITOR="nano" kubectl edit svc/docker-registry # Use an alternative editor +``` + +## Scaling Resources + +```console +$ kubectl scale --replicas=3 rs/foo # Scale a replicaset named 'foo' to +$ kubectl scale --replicas=3 -f foo.yaml # Scale a resource specified in "foo.yaml" to 3 +$ kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # If the deployment named mysql's current size is 2, scale mysql to 3 +$ kubectl scale --replicas=5 rc/foo rc/bar rc/baz # Scale multiple replication controllers +``` + +## Deleting Resources + +```console +$ kubectl delete -f ./pod.json # Delete a pod using the type and name specified in pod.json +$ kubectl delete pod,service baz foo # Delete pods and services with same names "baz" and "foo" +$ kubectl delete pods,services -l name=myLabel # Delete pods and services with label name=myLabel +$ kubectl -n my-ns delete po,svc --all # Delete all pods and services in namespace my-ns ``` ## Interacting with running Pods -```shell -$ kubectl logs # dump pod logs (stdout) -$ kubectl logs -f # stream pod logs (stdout) until canceled (ctrl-c) or timeout - -$ kubectl run -i --tty busybox --image=busybox -- sh # Run pod as interactive shell -$ kubectl attach -i # Attach to Running Container -$ kubectl port-forward # Forward port of Pod to your local machine -$ kubectl port-forward # Forward port to service -$ kubectl exec -- ls / # Run command in existing pod (1 container case) -$ kubectl exec -c -- ls / # Run command in existing pod (multi-container case) +```console +$ kubectl logs my-pod # dump pod logs (stdout) +$ kubectl logs -f my-pod # stream pod logs (stdout) +$ kubectl run -i --tty busybox --image=busybox -- sh # Run pod as interactive shell +$ kubectl attach my-pod -i # Attach to Running Container +$ kubectl port-forward my-pod 5000 6000 # Forward port 6000 of Pod to your to 5000 on your local machine +$ kubectl port-forward my-svc 6000 # Forward port to service +$ kubectl exec my-pod -- ls / # Run command in existing pod (1 container case) +$ kubectl exec my-pod -c my-container -- ls / # Run command in existing pod (multi-container case) +$ kubectl top pod POD_NAME --containers # Show metrics for a given pod and its containers ``` + +## Interacting with Nodes and Cluster + +```console +$ kubectl cordon my-node # Mark my-node as unschedulable +$ kubectl drain my-node # Drain my-node in preparation for maintenance +$ kubectl uncordon my-node # Mark my-node as schedulable +$ kubectl top node my-node # Show metrics for a given node +$ kubectl cluster-info # Display addresses of the master and services +$ kubectl cluster-info dump # Dump current cluster state to stdout +$ kubectl cluster-info dump --output-directory=/path/to/cluster-state # Dump current cluster state to /path/to/cluster-state + +# If a taint with that key and effect already exists, its value is replaced as specified. +$ kubectl taint nodes foo dedicated=special-user:NoSchedule +``` + +## Resource types + +The following table includes a list of all the supported resource types and their abbreviated aliases. + +Resource type | Abbreviated alias +-------------------- | -------------------- +`clusters` | +`componentstatuses` |`cs` +`configmaps` |`cm` +`daemonsets` |`ds` +`deployments` |`deploy` +`endpoints` |`ep` +`event` |`ev` +`horizontalpodautoscalers` |`hpa` +`ingresses` |`ing` +`jobs` | +`limitranges` |`limits` +`namespaces` |`ns` +`networkpolicies` | +`nodes` |`no` +`petset` | +`persistentvolumeclaims` |`pvc` +`persistentvolumes` |`pv` +`pods` |`po` +`podsecuritypolicies` |`psp` +`podtemplates` | +`replicasets` |`rs` +`replicationcontrollers` |`rc` +`resourcequotas` |`quota` +`scheduledjob` | +`secrets` | +`serviceaccount` |`sa` +`services` |`svc` +`storageclasses` | +`thirdpartyresources` | + +### Formatting output + +To output details to your terminal window in a specific format, you can add either the `-o` or `-output` flags to a supported `kubectl` command. + +Output format | Description +--------------| ----------- +`-o=custom-columns=` | Print a table using a comma separated list of custom columns +`-o=custom-columns-file=` | Print a table using the custom columns template in the `` file +`-o=json` | Output a JSON formatted API object +`-o=jsonpath=