diff --git a/_sass/_base.sass b/_sass/_base.sass index d80aab8fc0..cb6ec8b04f 100644 --- a/_sass/_base.sass +++ b/_sass/_base.sass @@ -1138,10 +1138,8 @@ $feature-box-div-margin-bottom: 40px position: absolute top: 50% left: 75% - width: 50% - max-width: 600px - min-width: 500px - padding-right: 10% + width: 525px + padding-right: 80px transform: translate(-50%, -50%) color: white diff --git a/docs/concepts/cluster-administration/cloud-providers.md b/docs/concepts/cluster-administration/cloud-providers.md index b3b8ff25b1..5db0a3ac3d 100644 --- a/docs/concepts/cluster-administration/cloud-providers.md +++ b/docs/concepts/cluster-administration/cloud-providers.md @@ -158,6 +158,9 @@ file: distributed amongst members of the load balancer pool. The value can be `ROUND_ROBIN`, `LEAST_CONNECTIONS`, or `SOURCE_IP`. The default behavior if none is specified is `ROUND_ROBIN`. +* `lb-provider` (Optional): Used to specify the provider of the load balancer. + If not specified, the default provider service configured in neutron will be + used. * `create-monitor` (Optional): Indicates whether or not to create a health monitor for the Neutron load balancer. Valid values are `true` and `false`. The default is `false`. When `true` is specified then `monitor-delay`, diff --git a/docs/concepts/services-networking/dns-pod-service.md b/docs/concepts/services-networking/dns-pod-service.md index 92e942292e..6c11c0e42c 100644 --- a/docs/concepts/services-networking/dns-pod-service.md +++ b/docs/concepts/services-networking/dns-pod-service.md @@ -225,7 +225,7 @@ If you see that, DNS is working correctly. If the nslookup command fails, check the following: #### Check the local DNS configuration first -Take a look inside the resolv.conf file. (See "Inheriting DNS from the node" and "Known issues" below for more information) +Take a look inside the resolv.conf file. (See [Inheriting DNS from the node](#inheriting-dns-from-the-node) and [Known issues](#known-issues) below for more information) ``` kubectl exec busybox cat /etc/resolv.conf diff --git a/docs/concepts/workloads/controllers/garbage-collection.md b/docs/concepts/workloads/controllers/garbage-collection.md index f773c6bf02..b220a17cdd 100644 --- a/docs/concepts/workloads/controllers/garbage-collection.md +++ b/docs/concepts/workloads/controllers/garbage-collection.md @@ -70,12 +70,6 @@ deletion*. There are two modes of *cascading deletion*: *background* and *foreg If you delete an object without deleting its dependents automatically, the dependents are said to be *orphaned*. -### Background cascading deletion - -In *background cascading deletion*, Kubernetes deletes the owner object -immediately and the garbage collector then deletes the dependents in -the background. - ### Foreground cascading deletion In *foreground cascading deletion*, the root object first @@ -100,6 +94,12 @@ unauthorized dependents cannot delay deletion of an owner object. If an object's `ownerReferences` field is set by a controller (such as Deployment or ReplicaSet), blockOwnerDeletion is set automatically and you do not need to manually modify this field. +### Background cascading deletion + +In *background cascading deletion*, Kubernetes deletes the owner object +immediately and the garbage collector then deletes the dependents in +the background. + ### Setting the cascading deletion policy To control the cascading deletion policy, set the `deleteOptions.propagationPolicy` diff --git a/docs/setup/independent/create-cluster-kubeadm.md b/docs/setup/independent/create-cluster-kubeadm.md index 3ef70ec6ad..5590d16cbb 100644 --- a/docs/setup/independent/create-cluster-kubeadm.md +++ b/docs/setup/independent/create-cluster-kubeadm.md @@ -62,8 +62,9 @@ cloud providers is difficult. {% capture prerequisites %} 1. One or more machines running Ubuntu 16.04+, CentOS 7 or HypriotOS v1.0.1+ -1. 1GB or more of RAM per machine (any less will leave little room for your +1. 2 GB or more of RAM per machine (any less will leave little room for your apps) +1. 2 CPUs or more on the master 1. Full network connectivity between all machines in the cluster (public or private network is fine) {% endcapture %} @@ -232,7 +233,7 @@ Please select one of the tabs to see installation instructions for the respectiv {% capture calico %} -The official Calico guide is [here](http://docs.projectcalico.org/latest/getting-started/kubernetes/installation/hosted/kubeadm/). +Refer to the Calico documentation for a [kubeadm quickstart](https://docs.projectcalico.org/latest/getting-started/kubernetes/), a [kubeadm installation guide](http://docs.projectcalico.org/latest/getting-started/kubernetes/installation/hosted/kubeadm/), and other resources. **Note:** @@ -266,6 +267,9 @@ kubectl apply -f https://raw.githubusercontent.com/projectcalico/canal/master/k8 - For flannel to work correctly, `--pod-network-cidr=10.244.0.0/16` has to be passed to `kubeadm init`. - flannel works on `amd64`, `arm`, `arm64` and `ppc64le`, but for it to work on an other platform than `amd64` you have to manually download the manifest and replace `amd64` occurences with your chosen platform. + - Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1` +to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information +please see [here](https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements). ```shell kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/v0.9.0/Documentation/kube-flannel.yml @@ -274,6 +278,10 @@ kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/v0.9.0/Documen {% capture kube-router %} +Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1` +to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information +please see [here](https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements). + Kube-router relies on kube-controll-manager to allocate pod CIDR for the nodes. Therefore, use `kubeadm init` with the `--pod-network-cidr` flag. Kube-router provides pod networking, network policy, and high-performing IP Virtual Server(IPVS)/Linux Virtual Server(LVS) based service proxy. @@ -284,6 +292,10 @@ For information on setting up Kubernetes cluster with Kube-router using kubeadm {% capture romana %} +Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1` +to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information +please see [here](https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements). + The official Romana set-up guide is [here](https://github.com/romana/romana/tree/master/containerize#using-kubeadm). **Note:** Romana works on `amd64` only. @@ -295,6 +307,10 @@ kubectl apply -f https://raw.githubusercontent.com/romana/romana/master/containe {% capture weave_net %} +Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1` +to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information +please see [here](https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements). + The official Weave Net set-up guide is [here](https://www.weave.works/docs/net/latest/kube-addon/). **Note:** Weave Net works on `amd64`, `arm` and `arm64` without any extra action required. diff --git a/docs/setup/independent/install-kubeadm.md b/docs/setup/independent/install-kubeadm.md index f84d966ef2..a85fbd1f43 100644 --- a/docs/setup/independent/install-kubeadm.md +++ b/docs/setup/independent/install-kubeadm.md @@ -11,14 +11,12 @@ This page shows how to use install kubeadm. {% capture prerequisites %} * One or more machines running Ubuntu 16.04+, Debian 9, CentOS 7, RHEL 7, Fedora 25/26 (best-effort) or HypriotOS v1.0.1+ -* 1GB or more of RAM per machine (any less will leave little room for your apps) +* 2 GB or more of RAM per machine (any less will leave little room for your apps) +* 2 CPUs or more * Full network connectivity between all machines in the cluster (public or private network is fine) * Unique hostname, MAC address, and product_uuid for every node * Certain ports are open on your machines. See the section below for more details -* Swap disabled. You must disable swap in order for the kubelet to work properly. -* Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1` -to pass bridged IPv4 traffic to iptables' chains. This is a requirement for CNI plugins to work, for more information -please see [here](https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements). +* Swap disabled. You must disable swap in order for the kubelet to work properly. {% endcapture %} @@ -75,6 +73,8 @@ On each of your machines, install Docker. Version v1.12 is recommended, but v1.11, v1.13 and 17.03 are known to work as well. Versions 17.06+ _might work_, but have not yet been tested and verified by the Kubernetes node team. +Please proceed with executing the following commands based on your OS as root. You may become the root user by executing `sudo -i` after SSH-ing to each host. + You can use the following commands to install Docker on your system: {% capture docker_ubuntu %} @@ -151,9 +151,6 @@ server version. For example, kubelets running 1.7.0 should be fully compatible w For more information on version skews, please read our [version skew policy](/docs/setup/independent/create-cluster-kubeadm/#version-skew-policy). -Please proceed with executing the following commands based on your OS as `root`. -You may become the `root` user by executing `sudo -i` after SSH-ing to each host. - {% capture ubuntu %} ```bash diff --git a/docs/setup/pick-right-solution.md b/docs/setup/pick-right-solution.md index 678703238c..d823609725 100644 --- a/docs/setup/pick-right-solution.md +++ b/docs/setup/pick-right-solution.md @@ -15,7 +15,7 @@ If you just want to "kick the tires" on Kubernetes, use the [local Docker-based When you are ready to scale up to more machines and higher availability, a [hosted solution](#hosted-solutions) is the easiest to create and maintain. [Turnkey cloud solutions](#turnkey-cloud-solutions) require only a few commands to create -and cover a wide range of cloud providers. +and cover a wide range of cloud providers. [On-Premises turnkey cloud solutions](#on-premises-turnkey-cloud-solutions) have the simplicity of the turnkey cloud solution combined with the security of your own private network. If you already have a way to configure hosting resources, use [kubeadm](/docs/setup/independent/create-cluster-kubeadm/) to easily bring up a cluster with a single command per machine. @@ -75,6 +75,12 @@ few commands. These solutions are actively developed and have active community s * [KUBE2GO.io](https://kube2go.io/) * [Madcore.Ai](https://madcore.ai/) +# On-Premises turnkey cloud solutions +These solutions allow you to create Kubernetes clusters on your internal, secure, cloud network with only a +few commands. + +* [IBM Cloud Private](https://www.ibm.com/cloud-computing/products/ibm-cloud-private/) + # Custom Solutions Kubernetes can run on a wide range of Cloud providers and bare-metal environments, and with many diff --git a/docs/tasks/administer-cluster/access-cluster-api.md b/docs/tasks/administer-cluster/access-cluster-api.md index 83738368aa..7929387906 100644 --- a/docs/tasks/administer-cluster/access-cluster-api.md +++ b/docs/tasks/administer-cluster/access-cluster-api.md @@ -36,10 +36,10 @@ kubectl. Complete documentation is found in the [kubectl manual](/docs/user-gui ### Directly accessing the REST API -Kubectl handles locating and authenticating to the apiserver. If you want to directly access the REST API with an http client like -`curl` or `wget`, or a browser, there are multiple ways you can locate and authenticate against the apiserver: +kubectl handles locating and authenticating to the API server. If you want to directly access the REST API with an http client like +`curl` or `wget`, or a browser, there are multiple ways you can locate and authenticate against the API server: - 1. Run kubectl in proxy mode (recommended). This method is recommended, since it uses the stored apiserver location abd verifies the identity of the apiserver using a self-signed cert. No Man-in-the-middle (MITM) attack is possible using this method . + 1. Run kubectl in proxy mode (recommended). This method is recommended, since it uses the stored apiserver location and verifies the identity of the API server using a self-signed cert. No man-in-the-middle (MITM) attack is possible using this method. 1. Alternatively, you can provide the location and credentials directly to the http client. This works with for client code that is confused by proxies. To protect against man in the middle attacks, you'll need to import a root cert into your browser. Using the Go or Python client libraries provides accessing kubectl in proxy mode. @@ -47,7 +47,7 @@ Kubectl handles locating and authenticating to the apiserver. If you want to dir #### Using kubectl proxy The following command runs kubectl in a mode where it acts as a reverse proxy. It handles -locating the apiserver and authenticating. +locating the API server and authenticating. Run it like this: @@ -77,7 +77,7 @@ $ curl http://localhost:8080/api/ #### Without kubectl proxy It is possible to avoid using kubectl proxy by passing an authentication token -directly to the apiserver, like this: +directly to the API server, like this: ``` shell $ APISERVER=$(kubectl config view | grep server | cut -f 2- -d ":" | tr -d " ") @@ -104,7 +104,7 @@ and client certificates to access the server. (These are installed in the may take special configuration to get your http client to use root certificate. -On some clusters, the apiserver does not require authentication; it may serve +On some clusters, the API server does not require authentication; it may serve on localhost, or be protected by a firewall. There is not a standard for this. [Configuring Access to the API](/docs/admin/accessing-the-api) describes how a cluster admin can configure this. Such approaches may conflict @@ -121,7 +121,7 @@ Kubernetes officially supports client libraries for [Go](#go-client) and * Write an application atop of the client-go clients. Note that client-go defines its own API objects, so if needed, please import API definitions from client-go rather than from the main repository, e.g., `import "k8s.io/client-go/1.4/pkg/api/v1"` is correct. The Go client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) -as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go): +as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go): ```golang import ( @@ -148,7 +148,7 @@ If the application is deployed as a Pod in the cluster, please refer to the [nex To use [Python client](https://github.com/kubernetes-incubator/client-python), run the following command: `pip install kubernetes` See [Python Client Library page](https://github.com/kubernetes-incubator/client-python) for more installation options. The Python client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) -as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://github.com/kubernetes-incubator/client-python/tree/master/examples/example1.py): +as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-incubator/client-python/tree/master/examples/example1.py): ```python from kubernetes import client, config @@ -168,37 +168,46 @@ There are [client libraries](/docs/reference/client-libraries/) for accessing th ### Accessing the API from a Pod -When accessing the API from a pod, locating and authenticating +When accessing the API from a Pod, locating and authenticating to the API server are somewhat different. -The recommended way to locate the apiserver within the pod is with -the `kubernetes` DNS name, which resolves to a Service IP which in turn -will be routed to an apiserver. +The easiest way to use the Kubernetes API from a Pod is to use +one of the official [client libraries](/docs/reference/client-libraries/). These +libraries can automatically discover the API server and authenticate. -The recommended way to authenticate to the apiserver is with a -[service account](/docs/user-guide/service-accounts) credential. By kube-system, a pod +While running in a Pod, the Kubernetes apiserver is accessible via a Service named +`kubernetes` in the `default` namespace. Therefore, Pods can use the +`kubernetes.default` hostname to query the API server. Official client libraries +do this automatically. + +From within a Pod, the recommended way to authenticate to the API server is with a +[service account](/docs/user-guide/service-accounts) credential. By default, a Pod is associated with a service account, and a credential (token) for that -service account is placed into the filesystem tree of each container in that pod, +service account is placed into the filesystem tree of each container in that Pod, at `/var/run/secrets/kubernetes.io/serviceaccount/token`. If available, a certificate bundle is placed into the filesystem tree of each container at `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`, and should be -used to verify the serving certificate of the apiserver. +used to verify the serving certificate of the API server. Finally, the default namespace to be used for namespaced API operations is placed in a file at `/var/run/secrets/kubernetes.io/serviceaccount/namespace` in each container. -From within a pod the recommended ways to connect to API are: +From within a Pod, the recommended ways to connect to the Kubernetes API are: - - run a kubectl proxy as one of the containers in the pod, or as a background - process within a container. This proxies the - Kubernetes API to the localhost interface of the pod, so that other processes - in any container of the pod can access it. See this [example of using kubectl proxy - in a pod](https://github.com/kubernetes/examples/tree/{{page.githubbranch}}/staging/kubectl-container/). - - use the Go client library, and create a client using the `rest.InClusterConfig()` and `kubernetes.NewForConfig()` functions. - They handle locating and authenticating to the apiserver. [example](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go) + - Use one of the official [client libraries](/docs/reference/client-libraries/) + as they handle API host discovery and authentication automatically. + For Go client, the `rest.InClusterConfig()` function assists with this. + See [an example here](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go). -In each case, the credentials of the pod are used to communicate securely with the apiserver. + - If you would like to query the API without an official client library, you can run `kubectl proxy` + as the [command](/docs/tasks/inject-data-application/define-command-argument-container/) + of a new sidecar container in the Pod. This way, `kubectl proxy` will authenticate + to the API and expose it on the `localhost` interface of the Pod, so that other containers + in the Pod can use it directly. + +In each case, the service account credentials of the Pod are used to communicate +securely with the API server. {% endcapture %} diff --git a/docs/tutorials/kubernetes-basics/expose-intro.html b/docs/tutorials/kubernetes-basics/expose-intro.html index 2bf94c0b5f..02ff7edbd6 100644 --- a/docs/tutorials/kubernetes-basics/expose-intro.html +++ b/docs/tutorials/kubernetes-basics/expose-intro.html @@ -34,7 +34,7 @@ title: Using a Service to Expose Your App

Although each Pod has a unique IP address, those IPs are not exposed outside the cluster without a Service. Services allow your applications to receive traffic. Services can be exposed in different ways by specifying a type in the ServiceSpec: