Merge branch 'master' into patch-1
Keith Wansbrough
GitHub
commit
b5a780cf3f
29
README.md
29
README.md
|
|
@ -4,6 +4,13 @@ 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.
|
||||
|
||||
For more information about contributing to the Kubernetes documentation, see:
|
||||
|
||||
* [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/)
|
||||
|
||||
## Automatic Staging for Pull Requests
|
||||
|
||||
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:
|
||||
|
|
@ -13,17 +20,17 @@ When you create a pull request (either against master or the upcoming release),
|
|||
- 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
|
||||
|
||||
## Release Branch Staging
|
||||
## Branch structure and staging
|
||||
|
||||
The Kubernetes site maintains staged versions at a subdomain provided by Netlify. Every PR for the Kubernetes site, either against the master branch or the upcoming release branch, is staged automatically.
|
||||
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 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 `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 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.
|
||||
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
|
||||
|
|
@ -47,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.
|
||||
|
|
@ -140,16 +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. 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` branches store changes for **upcoming releases of Kubernetes**. For example, the `release-1.5` branch has changes for the upcoming 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**.
|
||||
|
||||
Changes in the "docsv2" branch (where we are testing a revamp of the docs) are automatically staged here:
|
||||
http://k8sdocs.github.io/docs/tutorials/
|
||||
|
||||
|
||||
## Config yaml guidelines
|
||||
|
||||
Guidelines for config yamls that are included in the site docs. These
|
||||
|
|
|
|||
|
|
@ -30,4 +30,3 @@ permalink: pretty
|
|||
|
||||
gems:
|
||||
- jekyll-redirect-from
|
||||
|
||||
|
|
|
|||
|
|
@ -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/
|
||||
|
||||
|
|
|
|||
|
|
@ -101,7 +101,7 @@ quoting facilities of HTTP. For example: if the bearer token is
|
|||
header as shown below.
|
||||
|
||||
```http
|
||||
Authentication: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269
|
||||
Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269
|
||||
```
|
||||
|
||||
### Static Password File
|
||||
|
|
|
|||
|
|
@ -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-<version-number>`, 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 %}
|
||||
|
|
@ -71,7 +71,7 @@ Here's an interesting thing to know about the steps you just did.
|
|||
|
||||
<p>Here's an example of a published topic that uses the task template:</p>
|
||||
|
||||
<p><a href="/docs/tasks/access-application-cluster/http-proxy-access-application-cluster">Using an HTTP Proxy to Access Applications in a Cluster</a></p>
|
||||
<p><a href="/docs/tasks/access-kubernetes-api/http-proxy-access-api">Using an HTTP Proxy to Access the Kubernetes API</a></p>
|
||||
|
||||
<h3 id="tutorial_template">Tutorial template</h3>
|
||||
|
||||
|
|
|
|||
|
|
@ -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 `<your-username>.github.io`, where
|
||||
`<your-username>` is the username of your GitHub account.
|
||||
|
||||
1. Delete the `CNAME` file.
|
||||
|
||||
1. View your staged content at this URL:
|
||||
|
||||
https://<your-username>.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 %}
|
||||
|
|
@ -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:
|
||||
|
||||
<table>
|
||||
|
||||
<tr>
|
||||
<td>Task</td>
|
||||
<td>A task page shows how to do a single thing, typically by giving a short sequence of steps. Task pages have minimal explanation, but often provide links to conceptual topics that provide related background and knowledge.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Tutorial</td>
|
||||
<td>A tutorial page shows how to accomplish a goal that is larger than a single task. Typically a tutorial page has several sections, each of which has a sequence of steps. For example, a tutorial might provide a walkthrough of a code sample that illustrates a certain feature of Kubernetes. Tutorials can include surface-level explanations, but should link to related concept topics for deep explanations.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Concept</td>
|
||||
<td>A concept page explains some aspect of Kubernetes. For example, a concept page might describe the Kubernetes Deployment object and explain the role it plays as an application is deployed, scaled, and updated. Typically, concept pages don't include sequences of steps, but instead provide links to tasks or tutorials.</td>
|
||||
</tr>
|
||||
|
||||
</table>
|
||||
|
||||
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 %}
|
||||
|
|
@ -10,15 +10,15 @@ assignees:
|
|||
|
||||
## Prerequisites
|
||||
|
||||
You need two machines with CentOS installed on them.
|
||||
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...
|
||||
|
||||
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 hosts, centos-minion-n will be the nodes and run kubelet, proxy, cadvisor and docker.
|
||||
|
||||
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.
|
||||
All of then run flanneld as networking overlay.
|
||||
|
||||
**System Information:**
|
||||
|
||||
|
|
@ -28,12 +28,14 @@ Please replace host IP with your environment.
|
|||
|
||||
```conf
|
||||
centos-master = 192.168.121.9
|
||||
centos-minion = 192.168.121.65
|
||||
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} with following information.
|
||||
* 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]
|
||||
|
|
@ -42,17 +44,19 @@ 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.
|
||||
* 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
|
||||
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" >> /etc/hosts
|
||||
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:
|
||||
|
|
@ -74,7 +78,7 @@ KUBE_ALLOW_PRIV="--allow-privileged=false"
|
|||
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
|
||||
* 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
|
||||
|
|
@ -114,17 +118,39 @@ KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16"
|
|||
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; do
|
||||
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 node.**
|
||||
**Configure the Kubernetes services on the nodes.**
|
||||
|
||||
***We need to configure the kubelet and start the kubelet and proxy***
|
||||
|
||||
|
|
@ -138,7 +164,7 @@ KUBELET_ADDRESS="--address=0.0.0.0"
|
|||
KUBELET_PORT="--port=10250"
|
||||
|
||||
# You may leave this blank to use the actual hostname
|
||||
KUBELET_HOSTNAME="--hostname-override=centos-minion"
|
||||
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"
|
||||
|
|
@ -147,10 +173,24 @@ KUBELET_API_SERVER="--api-servers=http://centos-master:8080"
|
|||
KUBELET_ARGS=""
|
||||
```
|
||||
|
||||
* Start the appropriate services on node (centos-minion).
|
||||
* Configure flannel to overlay Docker network in /etc/sysconfig/flanneld (in all the nodes)
|
||||
|
||||
```shell
|
||||
for SERVICES in kube-proxy kubelet docker; do
|
||||
# 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
|
||||
|
|
@ -164,7 +204,9 @@ done
|
|||
```shell
|
||||
$ kubectl get nodes
|
||||
NAME LABELS STATUS
|
||||
centos-minion <none> Ready
|
||||
centos-minion-1 <none> Ready
|
||||
centos-minion-2 <none> Ready
|
||||
centos-minion-3 <none> Ready
|
||||
```
|
||||
|
||||
**The cluster should be running! Launch a test pod.**
|
||||
|
|
@ -176,7 +218,7 @@ You should have a functional cluster, check out [101](/docs/user-guide/walkthrou
|
|||
|
||||
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))
|
||||
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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -120,6 +122,7 @@ 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 | Ignition | Ubuntu | Azure | [docs](/docs/getting-started-guides/azure) | | Community (Microsoft: [@brendandburns](https://github.com/brendandburns), [@colemickens](https://github.com/colemickens))
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -117,7 +117,7 @@ h2, h3, h4 {
|
|||
<div class="col2nd">
|
||||
<h3>Contribute to Our Docs</h3>
|
||||
<p>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!</p>
|
||||
<a href="/editdocs/" class="button">Write Docs for K8s</a>
|
||||
<a href="/docs/contribute/create-pull-request/" class="button">Write Docs for K8s</a>
|
||||
</div>
|
||||
<div class="col2nd">
|
||||
<h3>Need Help?</h3>
|
||||
|
|
|
|||
|
|
@ -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 %}
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -12,6 +12,7 @@ Display one or many resources
|
|||
Display one or many resources.
|
||||
|
||||
Valid resource types include:
|
||||
|
||||
* clusters (valid only for federation apiservers)
|
||||
* componentstatuses (aka 'cs')
|
||||
* configmaps (aka 'cm')
|
||||
|
|
@ -68,7 +69,9 @@ kubectl get -o json pod web-pod-13je7
|
|||
kubectl get -f pod.yaml -o json
|
||||
|
||||
# Return only the phase value of the specified pod.
|
||||
{% raw %}
|
||||
kubectl get -o template pod/web-pod-13je7 --template={{.status.phase}}
|
||||
{% endraw %}
|
||||
|
||||
# List all replication controllers and services together in ps output format.
|
||||
kubectl get rc,services
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ Throughout this doc you will see a few terms that are sometimes used interchange
|
|||
* Persistent Volume Claim (PVC): A request for storage, typically a [persistent volume](/docs/user-guide/persistent-volumes/walkthrough/).
|
||||
* Host name: The hostname attached to the UTS namespace of the pod, i.e the output of `hostname` in the pod.
|
||||
* DNS/Domain name: A *cluster local* domain name resolvable using standard methods (eg: [gethostbyname](http://linux.die.net/man/3/gethostbyname)).
|
||||
* Ordinality: the proprety of being "ordinal", or occupying a position in a sequence.
|
||||
* Ordinality: the property of being "ordinal", or occupying a position in a sequence.
|
||||
* Pet: a single member of a PetSet; more generally, a stateful application.
|
||||
* Peer: a process running a server, capable of communicating with other such processes.
|
||||
|
||||
|
|
@ -29,7 +29,7 @@ This doc assumes familiarity with the following Kubernetes concepts:
|
|||
* [Cluster DNS](/docs/admin/dns/)
|
||||
* [Headless Services](/docs/user-guide/services/#headless-services)
|
||||
* [Persistent Volumes](/docs/user-guide/volumes/)
|
||||
* [Dynamic volume provisioning](http://releases.k8s.io/{{page.githubbranch}}/examples/experimental/persistent-volume-provisioning/README.md)
|
||||
* [Persistent Volume Provisioning](http://releases.k8s.io/{{page.githubbranch}}/examples/experimental/persistent-volume-provisioning/README.md)
|
||||
|
||||
You need a working Kubernetes cluster at version >= 1.3, with a healthy DNS [cluster addon](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/README.md) at version >= 15. You cannot use PetSet on a hosted Kubernetes provider that has disabled `alpha` resources.
|
||||
|
||||
|
|
@ -85,7 +85,7 @@ Before you start deploying applications as PetSets, there are a few limitations
|
|||
* PetSet is an *alpha* resource, not available in any Kubernetes release prior to 1.3.
|
||||
* As with all alpha/beta resources, it can be disabled through the `--runtime-config` option passed to the apiserver, and in fact most likely will be disabled on hosted offerings of Kubernetes.
|
||||
* The only updatable field on a PetSet is `replicas`
|
||||
* The storage for a given pet must either be provisioned by a [dynamic storage provisioner](http://releases.k8s.io/{{page.githubbranch}}/examples/experimental/persistent-volume-provisioning/README.md) based on the requested `storage class`, or pre-provisioned by an admin. Note that dynamic volume provisioning is also currently in alpha.
|
||||
* The storage for a given pet must either be provisioned by a [persistent volume provisioner](http://releases.k8s.io/{{page.githubbranch}}/examples/experimental/persistent-volume-provisioning/README.md) based on the requested `storage class`, or pre-provisioned by an admin. Note that persistent volume provisioning is also currently in alpha.
|
||||
* Deleting and/or scaling a PetSet down will *not* delete the volumes associated with the PetSet. This is done to ensure safety first, your data is more valuable than an auto purge of all related PetSet resources. **Deleting the Persistent Volume Claims will result in a deletion of the associated volumes**.
|
||||
* All PetSets currently require a "governing service", or a Service responsible for the network identity of the pets. The user is responsible for this Service.
|
||||
* Updating an existing PetSet is currently a manual process, meaning you either need to deploy a new PetSet with the new image version, or orphan Pets one by one, update their image, and join them back to the cluster.
|
||||
|
|
@ -392,7 +392,8 @@ $ grace=$(kubectl get po web-0 --template '{{.spec.terminationGracePeriodSeconds
|
|||
$ kubectl delete petset,po -l app=nginx
|
||||
$ sleep $grace
|
||||
$ kubectl delete pvc -l app=nginx
|
||||
{% endraw %}```
|
||||
{% endraw %}
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
|
|
|
|||
|
|
@ -108,6 +108,25 @@ While tmpfs is very fast, be aware that unlike disks, tmpfs is cleared on
|
|||
machine reboot and any files you write will count against your container's
|
||||
memory limit.
|
||||
|
||||
#### Example pod
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: test-pd
|
||||
spec:
|
||||
containers:
|
||||
- image: gcr.io/google_containers/test-webserver
|
||||
name: test-container
|
||||
volumeMounts:
|
||||
- mountPath: /cache
|
||||
name: cache-volume
|
||||
volumes:
|
||||
- name: cache-volume
|
||||
emptyDir: {}
|
||||
```
|
||||
|
||||
### hostPath
|
||||
|
||||
A `hostPath` volume mounts a file or directory from the host node's filesystem
|
||||
|
|
|
|||
42
editdocs.md
42
editdocs.md
|
|
@ -1,42 +0,0 @@
|
|||
---
|
||||
layout: docwithnav
|
||||
---
|
||||
|
||||
<!-- BEGIN: Gotta keep this section JS/HTML because it swaps out content dynamically -->
|
||||
<p> </p>
|
||||
<script language="JavaScript">
|
||||
var forwarding=window.location.hash.replace("#","");
|
||||
$( document ).ready(function() {
|
||||
if(forwarding) {
|
||||
$("#generalInstructions").hide();
|
||||
$("#continueEdit").show();
|
||||
$("#continueEditButton").text("Edit " + forwarding);
|
||||
$("#continueEditButton").attr("href", "https://github.com/kubernetes/kubernetes.github.io/edit/master/" + forwarding)
|
||||
} else {
|
||||
$("#generalInstructions").show();
|
||||
$("#continueEdit").hide();
|
||||
}
|
||||
});
|
||||
</script>
|
||||
<div id="continueEdit">
|
||||
|
||||
<h2>Continue your edit</h2>
|
||||
|
||||
<p>Click the below link to edit the page you were just on. When you are done, press "Commit Changes" at the bottom of the screen. This will create a copy of our site on your GitHub account called a "fork." You can make other changes in your fork after it is created, if you want. When you are ready to send us all your changes, go to the index page for your fork and click "New Pull Request" to let us know about it.</p>
|
||||
|
||||
<p><a id="continueEditButton" class="button"></a></p>
|
||||
|
||||
</div>
|
||||
<div id="generalInstructions">
|
||||
|
||||
<h2>Edit our site in the cloud</h2>
|
||||
|
||||
<p>Click the below button to visit the repo for our site. You can then 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.</p>
|
||||
|
||||
<p><a class="button" href="https://github.com/kubernetes/kubernetes.github.io/">Browse this site's source code</a></p>
|
||||
|
||||
</div>
|
||||
<!-- END: Dynamic section -->
|
||||
|
||||
|
||||
{% include_relative README.md %}
|
||||
Loading…
Reference in New Issue