diff --git a/_config.yml b/_config.yml index cb06611999..fff0133fe9 100644 --- a/_config.yml +++ b/_config.yml @@ -32,11 +32,14 @@ defaults: permalink: pretty gems: - - jekyll-redirect-from - jekyll-feed - jekyll-sitemap - jekyll-seo-tag - jekyll-include-cache +# disabled gems +# - jekyll-redirect-from + +include: [_redirects] # SEO logo: /images/favicon.png diff --git a/_includes/head.html b/_includes/head.html index 87c4a4f175..0410510070 100644 --- a/_includes/head.html +++ b/_includes/head.html @@ -7,6 +7,7 @@ {% if page.case_study_styles %}{% else %}{% endif %} + {% if page.class == "gridPage" %}{% endif %} {% if page.css %}{% else %}{% endif %} diff --git a/_includes/task-tutorial-prereqs.md b/_includes/task-tutorial-prereqs.md index a9cf90d265..6f1407fe45 100644 --- a/_includes/task-tutorial-prereqs.md +++ b/_includes/task-tutorial-prereqs.md @@ -1,4 +1,8 @@ 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). +[Minikube](/docs/getting-started-guides/minikube), +or you can use one of these Kubernetes playgrounds: + +* [Katacoda](https://www.katacoda.com/courses/kubernetes/playground) +* [Play with Kubernetes](http://labs.play-with-k8s.com/) diff --git a/_redirects b/_redirects new file mode 100644 index 0000000000..70e111ece7 --- /dev/null +++ b/_redirects @@ -0,0 +1,242 @@ +# +# set server-side redirects in this file +# see https://www.netlify.com/docs/redirects/ +# + +/docs/admin/addons /docs/concepts/cluster-administration/addons 301 +/docs/admin/apparmor/ /docs/tutorials/clusters/apparmor 301 +/docs/admin/audit /docs/tasks/debug-application-cluster/audit 301 +/docs/admin/cluster-components /docs/concepts/overview/components 301 +/docs/admin/cluster-management /docs/tasks/administer-cluster/cluster-management 301 +/docs/admin/cluster-troubleshooting /docs/tasks/debug-application-cluster/debug-cluster 301 +/docs/admin/daemons /docs/concepts/workloads/controllers/daemonset 301 +/docs/admin/disruptions /docs/concepts/workloads/pods/disruptions 301 +/docs/admin/dns /docs/concepts/services-networking/dns-pod-service 301 +/docs/admin/etcd /docs/tasks/administer-cluster/configure-upgrade-etcd 301 +/docs/admin/etcd_upgrade /docs/tasks/administer-cluster/configure-upgrade-etcd 301 +/docs/admin/federation/kubefed /docs/tasks/federation/set-up-cluster-federation-kubefed 301 +/docs/admin/garbage-collection /docs/concepts/cluster-administration/kubelet-garbage-collection 301 +/docs/admin/ha-master-gce /docs/tasks/administer-cluster/highly-available-master 301 +/docs/admin/ /docs/concepts/cluster-administration/cluster-administration-overview 301 +/docs/admin/kubeadm-upgrade-1-7 /docs/tasks/administer-cluster/kubeadm-upgrade-1-7 301 +/docs/admin/limitrange/ /docs/tasks/administer-cluster/cpu-memory-limit 301 +/docs/admin/master-node-communication /docs/concepts/architecture/master-node-communication 301 +/docs/admin/multi-cluster /docs/concepts/cluster-administration/federation 301 +/docs/admin/multiple-schedulers /docs/tasks/administer-cluster/configure-multiple-schedulers 301 +/docs/admin/namespaces/ /docs/tasks/administer-cluster/namespaces 301 +/docs/admin/namespaces/walkthrough /docs/tasks/administer-cluster/namespaces-walkthrough 301 +/docs/admin/network-plugins /docs/concepts/cluster-administration/network-plugins 301 +/docs/admin/networking /docs/concepts/cluster-administration/networking 301 +/docs/admin/node /docs/concepts/architecture/nodes 301 +/docs/admin/node-allocatable /docs/tasks/administer-cluster/reserve-compute-resources 301 +/docs/admin/node-problem /docs/tasks/debug-application-cluster/monitor-node-health 301 +/docs/admin/out-of-resource /docs/tasks/administer-cluster/out-of-resource 301 +/docs/admin/rescheduler /docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods 301 +/docs/admin/resourcequota/ /docs/concepts/policy/resource-quotas 301 +/docs/admin/resourcequota/limitstorageconsumption /docs/tasks/administer-cluster/limit-storage-consumption 301 +/docs/admin/resourcequota/walkthrough /docs/tasks/administer-cluster/apply-resource-quota-limit 301 +/docs/admin/static-pods /docs/tasks/administer-cluster/static-pod 301 +/docs/admin/sysctls /docs/concepts/cluster-administration/sysctl-cluster 301 +/docs/admin/upgrade-1-6 /docs/tasks/administer-cluster/upgrade-1-6 301 + +/docs/api /docs/concepts/overview/kubernetes-api 301 + +/docs/concepts/abstractions/controllers/garbage-collection /docs/concepts/workloads/controllers/garbage-collection 301 +/docs/concepts/abstractions/controllers/petsets /docs/concepts/workloads/controllers/petset 301 +/docs/concepts/abstractions/controllers/statefulsets /docs/concepts/workloads/controllers/statefulset 301 +/docs/concepts/abstractions/init-containers /docs/concepts/workloads/pods/init-containers 301 +/docs/concepts/abstractions/overview /docs/concepts/overview/working-with-objects/kubernetes-objects 301 +/docs/concepts/abstractions/pod /docs/concepts/workloads/pods/pod-overview 301 + +/docs/concepts/cluster-administration/access-cluster /docs/tasks/access-application-cluster/access-cluster 301 +/docs/concepts/cluster-administration/audit /docs/tasks/debug-application-cluster/audit 301 +/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig /docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig 301 +/docs/concepts/cluster-administration/cluster-management /docs/tasks/administer-cluster/cluster-management 301 +/docs/concepts/cluster-administration/configure-etcd /docs/tasks/administer-cluster/configure-upgrade-etcd 301 +/docs/concepts/cluster-administration/etcd-upgrade /docs/tasks/administer-cluster/configure-upgrade-etcd 301 +/docs/concepts/cluster-administration/federation-service-discovery /docs/tasks/federation/federation-service-discovery 301 +/docs/concepts/cluster-administration/guaranteed-scheduling-critical-addon-pods /docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods 301 +/docs/concepts/cluster-administration/master-node-communication /docs/concepts/architecture/master-node-communication 301 +/docs/concepts/cluster-administration/multiple-clusters /docs/concepts/cluster-administration/federation 301 +/docs/concepts/cluster-administration/out-of-resource /docs/tasks/administer-cluster/out-of-resource 301 +/docs/concepts/cluster-administration/resource-usage-monitoring /docs/tasks/debug-application-cluster/resource-usage-monitoring 301 +/docs/concepts/cluster-administration/static-pod /docs/tasks/administer-cluster/static-pod 301 + +/docs/concepts/clusters/logging /docs/concepts/cluster-administration/logging 301 +/docs/concepts/configuration/container-command-arg /docs/tasks/inject-data-application/define-command-argument-container/docs/concepts/ecosystem/thirdpartyresource 301 /docs/tasks/access-kubernetes-api/extend-api-third-party-resource +/docs/concepts/jobs/cron-jobs /docs/concepts/workloads/controllers/cron-jobs 301 +/docs/concepts/jobs/run-to-completion-finite-workloads /docs/concepts/workloads/controllers/jobs-run-to-completion 301 +/docs/concepts/nodes/node /docs/concepts/architecture/nodes 301 +/docs/concepts/storage/etcd-store-api-object /docs/tasks/administer-cluster/configure-upgrade-etcd 301 + +/docs/concepts/tools/kubectl/object-management-overview /docs/tutorials/object-management-kubectl/object-management 301 +/docs/concepts/tools/kubectl/object-management-using-declarative-config /docs/tutorials/object-management-kubectl/declarative-object-management-configuration 301 +/docs/concepts/tools/kubectl/object-management-using-imperative-commands /docs/tutorials/object-management-kubectl/imperative-object-management-command 301 +/docs/concepts/tools/kubectl/object-management-using-imperative-config /docs/tutorials/object-management-kubectl/imperative-object-management-configuration 301 + +/docs/getting-started-guides/ /docs/setup/pick-right-solution 301 +/docs/getting-started-guides/kubeadm /docs/setup/independent/create-cluster-kubeadm 301 +/docs/getting-started-guides/network-policy/calico /docs/tasks/administer-cluster/calico-network-policy 301 +/docs/getting-started-guides/network-policy/romana /docs/tasks/administer-cluster/romana-network-policy 301 +/docs/getting-started-guides/network-policy/walkthrough /docs/tasks/administer-cluster/declare-network-policy 301 +/docs/getting-started-guides/network-policy/weave /docs/tasks/administer-cluster/weave-network-policy 301 +/docs/getting-started-guides/running-cloud-controller /docs/tasks/administer-cluster/running-cloud-controller 301 +/docs/getting-started-guides/ubuntu/calico /docs/getting-started-guides/ubuntu/ 301 + +/docs/hellonode /docs/tutorials/stateless-application/hello-minikube 301 +/docs/ /docs/home/ 301 +/docs/samples /docs/tutorials/ 301 +/docs/tasks/administer-cluster/assign-pods-nodes /docs/tasks/configure-pod-container/assign-pods-nodes 301 +/docs/tasks/administer-cluster/overview /docs/concepts/cluster-administration/cluster-administration-overview 301 + +/docs/tasks/configure-pod-container/apply-resource-quota-limit /docs/tasks/administer-cluster/apply-resource-quota-limit 301 +/docs/tasks/configure-pod-container/calico-network-policy /docs/tasks/administer-cluster/calico-network-policy 301 +/docs/tasks/configure-pod-container/communicate-containers-same-pod /docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume 301 +/docs/tasks/configure-pod-container/declare-network-policy /docs/tasks/administer-cluster/declare-network-policy 301 +/docs/tasks/configure-pod-container/define-environment-variable-container /docs/tasks/inject-data-application/define-environment-variable-container 301 +/docs/tasks/configure-pod-container/distribute-credentials-secure /docs/tasks/inject-data-application/distribute-credentials-secure 301 +/docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information /docs/tasks/inject-data-application/downward-api-volume-expose-pod-information 301 +/docs/tasks/configure-pod-container/environment-variable-expose-pod-information /docs/tasks/inject-data-application/environment-variable-expose-pod-information 301 +/docs/tasks/configure-pod-container/limit-range /docs/tasks/administer-cluster/cpu-memory-limit 301 +/docs/tasks/configure-pod-container/romana-network-policy /docs/tasks/administer-cluster/romana-network-policy 301 +/docs/tasks/configure-pod-container/weave-network-policy /docs/tasks/administer-cluster/weave-network-policy 301 + +/docs/tasks/kubectl/get-shell-running-container /docs/tasks/debug-application-cluster/get-shell-running-container 301 +/docs/tasks/kubectl/install /docs/tasks/tools/install-kubectl 301 +/docs/tasks/kubectl/list-all-running-container-images /docs/tasks/access-application-cluster/list-all-running-container-images 301 + +/docs/tasks/manage-stateful-set/debugging-a-statefulset /docs/tasks/debug-application-cluster/debug-stateful-set 301 +/docs/tasks/manage-stateful-set/deleting-a-statefulset /docs/tasks/run-application/delete-stateful-set 301 +/docs/tasks/manage-stateful-set/scale-stateful-set /docs/tasks/run-application/scale-stateful-set 301 +/docs/tasks/manage-stateful-set/upgrade-pet-set-to-stateful-set /docs/tasks/run-application/upgrade-pet-set-to-stateful-set 301 + +/docs/tasks/run-application/podpreset /docs/tasks/inject-data-application/podpreset 301 +/docs/tasks/troubleshoot/debug-init-containers /docs/tasks/debug-application-cluster/debug-init-containers 301 +/docs/tasks/web-ui-dashboard /docs/tasks/access-application-cluster/web-ui-dashboard 301 +/docs/templatedemos /docs/home/contribute/page-templates 301 +/docs/tools/kompose/ /docs/tools/kompose/user-guide 301 + +/docs/tutorials/clusters/multiple-schedulers /docs/tasks/administer-cluster/configure-multiple-schedulers 301 +/docs/tutorials/connecting-apps/connecting-frontend-backend /docs/tasks/access-application-cluster/connecting-frontend-backend 301 +/docs/tutorials/federation/set-up-cluster-federation-kubefed /docs/tasks/federation/set-up-cluster-federation-kubefed 301 +/docs/tutorials/federation/set-up-coredns-provider-federation /docs/tasks/federation/set-up-coredns-provider-federation 301 +/docs/tutorials/federation/set-up-placement-policies-federation /docs/tasks/federation/set-up-placement-policies-federation 301 +/docs/tutorials/getting-started/create-cluster /docs/tutorials/kubernetes-basics/cluster-intro 301 +/docs/tutorials/stateful-application/run-replicated-stateful-application /docs/tasks/run-application/run-replicated-stateful-application 301 +/docs/tutorials/stateful-application/run-stateful-application /docs/tasks/run-application/run-single-instance-stateful-application 301 +/docs/tutorials/stateless-application/expose-external-ip-address-service /docs/tasks/access-application-cluster/service-access-application-cluster 301 +/docs/tutorials/stateless-application/run-stateless-ap-replication-controller /docs/tasks/run-application/run-stateless-application-deployment 301 +/docs/tutorials/stateless-application/run-stateless-application-deployment /docs/tasks/run-application/run-stateless-application-deployment 301 + +/docs/user-guide/accessing-the-cluster /docs/tasks/access-application-cluster/access-cluster 301 +/docs/user-guide/add-entries-to-pod-etc-hosts-with-host-aliases/ /docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases 301 +/docs/user-guide/annotations /docs/concepts/overview/working-with-objects/annotations 301 +/docs/user-guide/application-troubleshooting /docs/tasks/debug-application-cluster/debug-application 301 +/docs/user-guide/compute-resources /docs/concepts/configuration/manage-compute-resources-container 301 +/docs/user-guide/config-best-practices /docs/concepts/configuration/overview 301 +/docs/user-guide/configmap/ /docs/tasks/configure-pod-container/configmap 301 +/docs/user-guide/configuring-containers /docs/tasks/ 301 +/docs/user-guide/connecting-applications /docs/concepts/services-networking/connect-applications-service 301 +/docs/user-guide/connecting-to-applications-port-forward /docs/tasks/access-application-cluster/port-forward-access-application-cluster 301 +/docs/user-guide/connecting-to-applications-proxy /docs/tasks/access-kubernetes-api/http-proxy-access-api 301 +/docs/user-guide/container-environment /docs/concepts/containers/container-lifecycle-hooks 301 +/docs/user-guide/cron-jobs /docs/concepts/workloads/controllers/cron-jobs 301 +/docs/user-guide/debugging-pods-and-replication-controllers /docs/tasks/debug-application-cluster/debug-pod-replication-controller 301 +/docs/user-guide/debugging-services /docs/tasks/debug-application-cluster/debug-service 301 +/docs/user-guide/deploying-applications /docs/tasks/run-application/run-stateless-application-deployment 301 +/docs/user-guide/deployments /docs/concepts/workloads/controllers/deployment 301 +/docs/user-guide/downward-api/ /docs/tasks/inject-data-application/downward-api-volume-expose-pod-information 301 +/docs/user-guide/downward-api/volume/ /docs/tasks/inject-data-application/downward-api-volume-expose-pod-information 301 +/docs/user-guide/environment-guide/ /docs/tasks/inject-data-application/environment-variable-expose-pod-information 301 +/docs/user-guide/federation/cluster /docs/tasks/administer-federation/cluster 301 +/docs/user-guide/federation/configmap /docs/tasks/administer-federation/configmap 301 +/docs/user-guide/federation/daemonsets /docs/tasks/administer-federation/daemonset 301 +/docs/user-guide/federation/deployment /docs/tasks/administer-federation/deployment 301 +/docs/user-guide/federation/events /docs/tasks/administer-federation/events 301 +/docs/user-guide/federation/federated-ingress /docs/tasks/administer-federation/ingress 301 +/docs/user-guide/federation/federated-services /docs/tasks/federation/federation-service-discovery 301 +/docs/user-guide/federation/ /docs/concepts/cluster-administration/federation 301 +/docs/user-guide/federation/namespaces /docs/tasks/administer-federation/namespaces 301 +/docs/user-guide/federation/replicasets /docs/tasks/administer-federation/replicaset 301 +/docs/user-guide/federation/secrets /docs/tasks/administer-federation/secret 301 +/docs/user-guide/garbage-collection /docs/concepts/workloads/controllers/garbage-collection 301 +/docs/user-guide/getting-into-containers /docs/tasks/debug-application-cluster/get-shell-running-container 301 +/docs/user-guide/gpus /docs/tasks/manage-gpus/scheduling-gpus 301 +/docs/user-guide/horizontal-pod-autoscaling/ /docs/tasks/run-application/horizontal-pod-autoscale 301 +/docs/user-guide/horizontal-pod-autoscaling/walkthrough /docs/tasks/run-application/horizontal-pod-autoscale-walkthrough 301 +/docs/user-guide/identifiers /docs/concepts/overview/working-with-objects/names 301 +/docs/user-guide/images /docs/concepts/containers/images 301 +/docs/user-guide/ /docs/home/ 301 +/docs/user-guide/ingress /docs/concepts/services-networking/ingress 301 +/docs/user-guide/introspection-and-debugging /docs/tasks/debug-application-cluster/debug-application-introspection 301 +/docs/user-guide/jobs /docs/concepts/workloads/controllers/jobs-run-to-completion 301 +/docs/user-guide/jobs/expansions/ /docs/tasks/job/parallel-processing-expansion 301 +/docs/user-guide/jobs/work-queue-1/ /docs/tasks/job/coarse-parallel-processing-work-queue/ 301 +/docs/user-guide/jobs/work-queue-2/ /docs/tasks/job/fine-parallel-processing-work-queue/ 301 +/docs/user-guide/kubeconfig-file /docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig 301 +/docs/user-guide/labels /docs/concepts/overview/working-with-objects/labels 301 +/docs/user-guide/liveness /docs/tasks/configure-pod-container/configure-liveness-readiness-probes 301 +/docs/user-guide/load-balancer /docs/tasks/access-application-cluster/create-external-load-balancer 301 +/docs/user-guide/logging/elasticsearch /docs/tasks/debug-application-cluster/logging-elasticsearch-kibana 301 +/docs/user-guide/logging/overview /docs/concepts/cluster-administration/logging 301 +/docs/user-guide/logging/stackdriver /docs/tasks/debug-application-cluster/logging-stackdriver 301 +/docs/user-guide/managing-deployments /docs/concepts/cluster-administration/manage-deployment 301 +/docs/user-guide/monitoring /docs/tasks/debug-application-cluster/resource-usage-monitoring 301 +/docs/user-guide/namespaces /docs/concepts/overview/working-with-objects/namespaces 301 +/docs/user-guide/networkpolicies /docs/concepts/services-networking/network-policies 301 +/docs/user-guide/node-selection/ /docs/concepts/configuration/assign-pod-node 301 +/docs/user-guide/persistent-volumes/ /docs/concepts/storage/persistent-volumes 301 +/docs/user-guide/persistent-volumes/walkthrough /docs/tasks/configure-pod-container/configure-persistent-volume-storage 301 +/docs/user-guide/petset /docs/concepts/workloads/controllers/petset 301 +/docs/user-guide/petset/bootstrapping/ /docs/concepts/workloads/controllers/petset 301 +/docs/user-guide/pod-preset/ /docs/tasks/inject-data-application/podpreset 301 +/docs/user-guide/pod-security-policy/ /docs/concepts/policy/pod-security-policy 301 +/docs/user-guide/pod-states /docs/concepts/workloads/pods/pod-lifecycle 301 +/docs/user-guide/pod-templates /docs/concepts/workloads/pods/pod-overview 301 +/docs/user-guide/pods/ /docs/concepts/workloads/pods/pod 301 +/docs/user-guide/pods/init-container /docs/concepts/workloads/pods/init-containers 301 +/docs/user-guide/pods/multi-container /docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume 301 +/docs/user-guide/pods/single-container /docs/tasks/run-application/run-stateless-application-deployment 301 +/docs/user-guide/prereqs /docs/tasks/tools/install-kubectl 301 +/docs/user-guide/production-pods /docs/tasks/ 301 +/docs/user-guide/projected-volume/ /docs/tasks/configure-pod-container/configure-projected-volume-storage 301 +/docs/user-guide/quick-start /docs/tasks/access-application-cluster/service-access-application-cluster 301 +/docs/user-guide/replicasets /docs/concepts/workloads/controllers/replicaset 301 +/docs/user-guide/replication-controller/ /docs/concepts/workloads/controllers/replicationcontroller 301 +/docs/user-guide/rolling-updates /docs/tasks/run-application/rolling-update-replication-controller 301 +/docs/user-guide/secrets/ /docs/concepts/configuration/secret 301 +/docs/user-guide/secrets/walkthrough /docs/tasks/inject-data-application/distribute-credentials-secure 301 +/docs/user-guide/service-accounts /docs/tasks/configure-pod-container/configure-service-account 301 +/docs/user-guide/services-firewalls /docs/tasks/access-application-cluster/configure-cloud-provider-firewall 301 +/docs/user-guide/services/ /docs/concepts/services-networking/service 301 +/docs/user-guide/services/operations /docs/tasks/access-application-cluster/connecting-frontend-backend 301 +/docs/user-guide/sharing-clusters /docs/tasks/administer-cluster/share-configuration 301 +/docs/user-guide/simple-nginx /docs/tasks/run-application/run-stateless-application-deployment 301 +/docs/user-guide/thirdpartyresources /docs/tasks/access-kubernetes-api/extend-api-third-party-resource 301 +/docs/user-guide/ui /docs/tasks/access-application-cluster/web-ui-dashboard 301 +/docs/user-guide/update-demo/ /docs/tasks/run-application/rolling-update-replication-controller 301 +/docs/user-guide/volumes /docs/concepts/storage/volumes 301 +/docs/user-guide/working-with-resources /docs/tutorials/object-management-kubectl/object-management 301 + +/docs/whatisk8s /docs/concepts/overview/what-is-kubernetes 301 + +# +# redirects from /js/redirects.js +# +/resource-quota /docs/concepts/policy/resource-quotas 301 +/horizontal-pod-autoscaler /docs/tasks/run-application/horizontal-pod-autoscale 301 +/docs/roadmap https://github.com/kubernetes/kubernetes/milestones/ 301 +/api-ref https://github.com/kubernetes/kubernetes/milestones/ 301 +/kubernetes/third_party/swagger-ui /docs/reference 301 +/docs/user-guide/overview /docs/concepts/overview/what-is-kubernetes 301 +/docs/troubleshooting /docs/tasks/debug-application-cluster/troubleshooting 301 +/docs/concepts/services-networking/networkpolicies /docs/concepts/services-networking/network-policies 301 +/docs/getting-started-guides/meanstack https://medium.com/google-cloud/running-a-mean-stack-on-google-cloud-platform-with-kubernetes-149ca81c2b5d 301 +/docs/samples /docs/tutorials 301 +/v1.1 / 301 +/v1.0 / 301 + +# +# Redirect users with chinese language preference to /cn +# +#/ /cn 302 Language=zh diff --git a/cn/docs/getting-started-guides/centos/centos_manual_config.md b/cn/docs/getting-started-guides/centos/centos_manual_config.md new file mode 100644 index 0000000000..cfa79aa370 --- /dev/null +++ b/cn/docs/getting-started-guides/centos/centos_manual_config.md @@ -0,0 +1,238 @@ +--- +assignees: +- thockin +title: CentOS +--- + +* TOC +{:toc} + +## 警告 + +本文档适用于Kubernetes 1.1.0，目前已经被[废弃](https://github.com/kubernetes/kubernetes.github.io/issues/1613)。相关内容请参阅最新版[指南](/docs/getting-started-guides/kubeadm/)。 + +## 前提条件 + +在CentOS上部署和配置Kubernetes，您需要在集群中拥有一台机器作为master节点，并拥有至少一台运行CentOS 7系统的主机作为集群节点（node）。 + +## 启动一个集群 + +本文档是一篇基于CentOS系统部署和配置Kubernetes的入门指南，内容涵盖一个手工的配置，以便于您了解所有的底层软件包、服务以及端口等信息。 + +Kubernetes由一系列服务构成，包括kube-apiserver、kube-scheduler、kube-controller-manager、kubelet以及kube-proxy等。这些服务由systemd管理，配置集中位于/etc/kubernetes。我们将在集群中的不同主机上部署不同的服务。其中，第一台主机，即centos-master，将被部署成为Kubernetes集群中的master节点。这台主机上将运行kube-apiserver、kube-controller-manager和kube-scheduler。 此外，master节点还将运行 _etcd_。集群中剩余的主机，即centos-minion-n节点，将运行kubelet、proxy、cadvisor和docker。 + +集群中的所有节点将运行flanneld来构建网络（networking overlay）。 + +**系统信息：** + +主机： + +请使用您真实环境中的信息替换以下配置中的各个主机IP + +```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 +``` + +**配置主机环境：** + +* 在集群所有节点上——centos-{master,minion-n}，创建包含以下配置信息的/etc/yum.repos.d/virt7-docker-common-release.repo文件。 + +```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 +``` + +* 在集群所有节点上——centos-{master,minion-n}，安装Kubernetes、etcd和flanneld。这一过程也将同时在节点上安装docker和cadvisor。 + +```shell +yum -y install --enablerepo=virt7-docker-common-release kubernetes etcd flannel +``` + +* 将master节点和其他节点的主机名——IP映射添加到所有集群节点的/etc/hosts文件中（如果主机名已经在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 +``` + +* 编辑/etc/kubernetes/config文件以保证在集群所有主机上都包含以下内容： + +```shell +# logging to stderr意为从systemd journal获取日志 +KUBE_LOGTOSTDERR="--logtostderr=true" + +# journal消息级别, 0代表debug +KUBE_LOG_LEVEL="--v=0" + +# 是否允许集群运行privileged docker containers +KUBE_ALLOW_PRIV="--allow-privileged=false" + +# 配置replication conrtoller和scheduler所需的kube-apiserver地址 +KUBE_MASTER="--master=http://centos-master:8080" +``` + +* 由于docker与一些防火墙规则不兼容，需要在master节点及其他集群节点上禁用防火墙。在CentOS系统上，需要首先禁用SELinux，进而才能禁用防火墙。 + +```shell +setenforce 0 +systemctl disable iptables-services firewalld +systemctl stop iptables-services firewalld +``` + +**配置master节点上的Kubernetes服务** + +* 编辑/etc/etcd/etcd.conf文件内容如下： + +```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" +``` + +* 编辑/etc/kubernetes/apiserver文件内容如下： + +```shell +# 本地服务器监听地址 +KUBE_API_ADDRESS="--address=0.0.0.0" + +# 本地服务器监听端口 +KUBE_API_PORT="--port=8080" + +# Kubelet监听端口 +KUBELET_PORT="--kubelet-port=10250" + +# 以逗号间隔的etcd集群中各个节点的地址 +KUBE_ETCD_SERVERS="--etcd-servers=http://centos-master:2379" + +# Kubernetes服务IP地址网段 +KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16" + +# 请添加您需要的Kubernetes API Server启动参数 +KUBE_API_ARGS="" +``` + +* 启动ETCD并保存master节点的网络设置（network overlay configuration）： +**警告** 请根据您的真实环境配置网络信息！在本文环境中，`172.30.0.0/16`网段是可用的。 + +```shell +systemctl start etcd +etcdctl mkdir /kube-centos/network +etcdctl mk /kube-centos/network/config "{ \"Network\": \"172.30.0.0/16\", \"SubnetLen\": 24, \"Backend\": { \"Type\": \"vxlan\" } }" +``` + +* 在master节点上配置/etc/sysconfig/flanneld文件使用flannel覆盖Docker网络 (需要在其他集群节点上完成相同配置，详见下文): + +```shell +# Flanneld配置选项 + +# etcd url地址，指向运行etcd的服务器 +FLANNEL_ETCD_ENDPOINTS="http://centos-master:2379" + +# etcd配置秘钥，即flannel查询的配置秘钥 +# 用于网段分配 +FLANNEL_ETCD_PREFIX="/kube-centos/network" + +# 其它需要的Flannel启动参数 +#FLANNEL_OPTIONS="" +``` + +* 在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 +``` + +**在集群其他节点上配置Kubernetes服务** + +***我们需要在集群其他节点上配置kubelet，启动kubelet和proxy服务*** + +* 编辑/etc/kubernetes/kubelet文件内容如下： + +```shell +# info server的服务地址 +KUBELET_ADDRESS="--address=0.0.0.0" + +# info server的监听端口 +KUBELET_PORT="--port=10250" + +# 本字段可以设置空值以使用真实的主机名 +# 注意节点序号（n） +KUBELET_HOSTNAME="--hostname-override=centos-minion-n" + +# api-server地址 +KUBELET_API_SERVER="--api-servers=http://centos-master:8080" + +# 添加您所需要的Kubelet参数 +KUBELET_ARGS="" +``` + +* 在所有节点上配置/etc/sysconfig/flanneld文件设置使用flannel覆盖Docker网络： + +```shell +# Flanneld配置选项 + +# etcd url地址，指向运行etcd的服务器 +FLANNEL_ETCD_ENDPOINTS="http://centos-master:2379" + +# etcd配置秘钥，即flannel查询的配置秘钥 +# 用于网段分配 +FLANNEL_ETCD_PREFIX="/kube-centos/network" + +# 其他需要配置的选项 +#FLANNEL_OPTIONS="" +``` + +* 在节点上启动相关服务（centos-minion-n） + +```shell +for SERVICES in kube-proxy kubelet flanneld docker; do + systemctl restart $SERVICES + systemctl enable $SERVICES + systemctl status $SERVICES +done +``` +* 配置kubectl + +```shell +kubectl config set-cluster default-cluster --server=http://centos-master:8080 +kubectl config set-context default-context --cluster=default-cluster --user=default-admin +kubectl config use-context default-context +``` + +*至此，Kubernetes在CentOS集群中的部署已经完成 ！* + +* 在centos-master节点上通过kubectl命令检查所有的Kubernetes节点已经到位 + +```shell +$ kubectl get nodes +NAME STATUS AGE VERSION +centos-minion-1 Ready 3d v1.6.0+fff5156 +centos-minion-2 Ready 3d v1.6.0+fff5156 +centos-minion-3 Ready 3d v1.6.0+fff5156 +``` + +**现在，Kubernetes集群已经正常运行！可以创建测试pod验证集群了！** + +## 支持级别 + + +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)) + +有关所有解决方案的支持级别信息，请参阅[解决方案列表](/docs/getting-started-guides/#table-of-solutions)。 diff --git a/cn/docs/getting-started-guides/coreos/bare_metal_offline.md b/cn/docs/getting-started-guides/coreos/bare_metal_offline.md new file mode 100644 index 0000000000..389428c439 --- /dev/null +++ b/cn/docs/getting-started-guides/coreos/bare_metal_offline.md @@ -0,0 +1,708 @@ +--- +assignees: +- erictune +- thockin +title: Offline +--- + +本文档介绍了如何在CoreOS系统上部署Kubernetes。主要针对需要在离线环境下部署的场景，无论您是真实部署前的POC测试还是由于应用程序受限必须在离线环境中使用，本文档都是适用的。 + +* TOC +{:toc} + + +## 前提条件 + +1. 安装了 *CentOS 6* 系统的PXE服务器 +2. 集群中需要至少两台物理裸机节点 + +## 概要设计 + +1. 管理tftp目录 + * /tftpboot/(coreos)(centos)(RHEL) + * /tftpboot/pxelinux.0/(MAC) -> 链接到Linux镜像配置文件 +2. 安装时更新pxelinux链接 +3. 更新DHCP配置，添加所需要部署的主机的相关信息 +4. 创建一个etcd集群 +5. 确保集群处于离线环境[etcd discovery tool](https://discovery.etcd.io/). +6. 安装配置CoreOS slave节点作为Kubernetes节点 + +## 本文档定义的一些变量 + +| Node Description | MAC | IP | +| :---------------------------- | :---------------: | :---------: | +| CoreOS/etcd/Kubernetes Master | d0:00:67:13:0d:00 | 10.20.30.40 | +| CoreOS Slave 1 | d0:00:67:13:0d:01 | 10.20.30.41 | +| CoreOS Slave 2 | d0:00:67:13:0d:02 | 10.20.30.42 | + + +## 设置PXELINUX CentOS + +请参阅[这篇指南](http://docs.fedoraproject.org/en-US/Fedora/7/html/Installation_Guide/ap-pxe-server.html)以了解完整的CentOS PXELINUX环境设置步骤。本节内容仅是上述指南文档的概要缩写版本。 + +1. 安装CentOS上所需要的相关软件包 + +```shell +sudo yum install tftp-server dhcp syslinux +``` + +2. 编辑`/etc/xinetd.d/tftp`文件以启用tftp服务 + +```conf +disable = no +``` + +3. 拷贝所需的syslinux镜像文件 + +```shell +su - +mkdir -p /tftpboot +cd /tftpboot +cp /usr/share/syslinux/pxelinux.0 /tftpboot +cp /usr/share/syslinux/menu.c32 /tftpboot +cp /usr/share/syslinux/memdisk /tftpboot +cp /usr/share/syslinux/mboot.c32 /tftpboot +cp /usr/share/syslinux/chain.c32 /tftpboot + +/sbin/service dhcpd start +/sbin/service xinetd start +/sbin/chkconfig tftp on +``` + +4. 设置默认引导菜单 + +```shell +mkdir /tftpboot/pxelinux.cfg +touch /tftpboot/pxelinux.cfg/default +``` + +5. 编辑默认引导菜单`/tftpboot/pxelinux.cfg/default` + +```conf +default menu.c32 +prompt 0 +timeout 15 +ONTIMEOUT local +display boot.msg + +MENU TITLE Main Menu + +LABEL local + MENU LABEL Boot local hard drive + LOCALBOOT 0 +``` + +至此，您应当已经配置好一个可用的PXELINUX环境用来运行CoreOS节点了，您可以通过在本地运行VirtualBox或者物理裸机来验证这一点。 + +## 添加CoreOS至PXE + +本节将介绍如何在一个现有的PXELINUX环境上设置CoreOS镜像。 + +1. 查找或者创建TFTP根目录，后续所有步骤都将基于此目录。 + * 本文中我们假设`/tftpboot`是根目录。 +2. tftp根目录准备好后，我们将为CoreOS镜像创建一个新的目录结构。 +3. 下载由CoreOS团队提供的CoreOS PXE相关文件。 + +```shell +MY_TFTPROOT_DIR=/tftpboot +mkdir -p $MY_TFTPROOT_DIR/images/coreos/ +cd $MY_TFTPROOT_DIR/images/coreos/ +wget http://stable.release.core-os.net/amd64-usr/current/coreos_production_pxe.vmlinuz +wget http://stable.release.core-os.net/amd64-usr/current/coreos_production_pxe.vmlinuz.sig +wget http://stable.release.core-os.net/amd64-usr/current/coreos_production_pxe_image.cpio.gz +wget http://stable.release.core-os.net/amd64-usr/current/coreos_production_pxe_image.cpio.gz.sig +gpg --verify coreos_production_pxe.vmlinuz.sig +gpg --verify coreos_production_pxe_image.cpio.gz.sig +``` + +4. 再次编辑菜单`/tftpboot/pxelinux.cfg/default` + +```conf +default menu.c32 +prompt 0 +timeout 300 +ONTIMEOUT local +display boot.msg + +MENU TITLE Main Menu + +LABEL local + MENU LABEL Boot local hard drive + LOCALBOOT 0 + +MENU BEGIN CoreOS Menu + + LABEL coreos-master + MENU LABEL CoreOS Master + KERNEL images/coreos/coreos_production_pxe.vmlinuz + APPEND initrd=images/coreos/coreos_production_pxe_image.cpio.gz cloud-config-url=http:///pxe-cloud-config-single-master.yml + + LABEL coreos-slave + MENU LABEL CoreOS Slave + KERNEL images/coreos/coreos_production_pxe.vmlinuz + APPEND initrd=images/coreos/coreos_production_pxe_image.cpio.gz cloud-config-url=http:///pxe-cloud-config-slave.yml +MENU END +``` + +此文件配置了系统将从本地磁盘引导，但添加了从PXE CoreOS镜像引导的选项。 + +## DHCP配置 + +本节将介绍如何配置DHCP服务器分发新的镜像。这里我们假设集群中有其他的服务器需要从不同的CoreOS镜像引导。 + +1. 添加`filename`字段到 _host_ 或者 _subnet_ 部分。 + +```conf +filename "/tftpboot/pxelinux.0"; +``` + +2. 现在，我们可以创建pxelinux配置文件，这些配置将来也可以作为其他不同CoreOS部署的模版。 + +```conf +subnet 10.20.30.0 netmask 255.255.255.0 { + next-server 10.20.30.242; + option broadcast-address 10.20.30.255; + filename ""; + + ... + # http://www.syslinux.org/wiki/index.php/PXELINUX + host core_os_master { + hardware ethernet d0:00:67:13:0d:00; + option routers 10.20.30.1; + fixed-address 10.20.30.40; + option domain-name-servers 10.20.30.242; + filename "/pxelinux.0"; + } + host core_os_slave { + hardware ethernet d0:00:67:13:0d:01; + option routers 10.20.30.1; + fixed-address 10.20.30.41; + option domain-name-servers 10.20.30.242; + filename "/pxelinux.0"; + } + host core_os_slave2 { + hardware ethernet d0:00:67:13:0d:02; + option routers 10.20.30.1; + fixed-address 10.20.30.42; + option domain-name-servers 10.20.30.242; + filename "/pxelinux.0"; + } + ... +} +``` + +稍后我们将介绍节点的配置。 + +## Kubernetes + +部署以上配置前，需要首先创建一个`etcd`主节点(master)。为了做到这一点，我们需要使用一个特殊的cloud-config.yaml来pxe CoreOS，可以有两种方式： +1. 第一种方式是将云配置文件模版化，然后通过编程的方式为不同的集群提供不同的配置。 +2. 第二种方式是运行一个服务发现协议从而可以在云环境中做服务的自动发现。 + +在本demo中，我们仅简单地创建一个静态的单一`etcd`服务器来运行Kubernetes并提供`etcd`的主要服务。 + +由于我们的集群处于一个离线的环境中，所以大部分的CoreOS和Kubernetes帮助进程是受限的。为了完成部署，我们需要下载Kubernetes的各种可执行文件到本地然后再启动运行。 + +一种简单的方案是在DHCP/TFTP主机上搭建一个简易的web服务器，从而环境中的CoreOS PXE机器可以从其上下载各种可执行文件。 + +为了达到这一目标，我们将启动一个`apache`服务器并提供运行Kuberetes所需要的各种可执行文件。 + +以下脚本运行在上文中准备好的PXE服务器上： + +```shell +rm /etc/httpd/conf.d/welcome.conf +cd /var/www/html/ +wget -O kube-register https://github.com/kelseyhightower/kube-register/releases/download/v0.0.2/kube-register-0.0.2-linux-amd64 +wget -O setup-network-environment https://github.com/kelseyhightower/setup-network-environment/releases/download/v1.0.0/setup-network-environment +wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kubernetes +wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kube-apiserver +wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kube-controller-manager +wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kube-scheduler +wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kubectl +wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kubecfg +wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kubelet +wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kube-proxy +wget -O flanneld https://storage.googleapis.com/k8s/flanneld +``` + +以上脚本将准备好运行Kubernetes所需的所有可执行文件。未来这些文件将可通过互联网直接进行更新。 + +现在可以开始准备部署了！ + +## 云平台配置 + +以下Kubernetes离线版本部署配置文件经过了一定的裁减。 + +以下内容基于配置文件: [master.yml](/docs/getting-started-guides/coreos/cloud-configs/master.yaml), 以及[node.yml](/docs/getting-started-guides/coreos/cloud-configs/node.yaml) + +将文件中的一些占位字段做如下修改： + + - 使用您的PXE服务器的ip地址替换文件中的`` (例如10.20.30.242) + - 使用Kubernetes master节点的ip地址替换文件中的`` (例如10.20.30.40) + - 如果您使用私有docker镜像仓库，请使用您的镜像仓库DNS名字替换文件中的`rdocker.example.com` + - 如果您使用代理，请用代理服务器地址（包含端口）替换文件中的`rproxy.example.com` + - 在配置文件最后添加您的SSH公钥 + +### master.yml + +在PXE服务器上创建并编辑文件`/var/www/html/coreos/pxe-cloud-config-master.yml`。 + +```yaml +#cloud-config +--- +write_files: + - path: /opt/bin/waiter.sh + owner: root + content: | + #! /usr/bin/bash + until curl http://127.0.0.1:4001/v2/machines; do sleep 2; done + - path: /opt/bin/kubernetes-download.sh + owner: root + permissions: 0755 + content: | + #! /usr/bin/bash + /usr/bin/wget -N -P "/opt/bin" "http:///kubectl" + /usr/bin/wget -N -P "/opt/bin" "http:///kubernetes" + /usr/bin/wget -N -P "/opt/bin" "http:///kubecfg" + chmod +x /opt/bin/* + - path: /etc/profile.d/opt-path.sh + owner: root + permissions: 0755 + content: | + #! /usr/bin/bash + PATH=$PATH/opt/bin +coreos: + units: + - name: 10-eno1.network + runtime: true + content: | + [Match] + Name=eno1 + [Network] + DHCP=yes + - name: 20-nodhcp.network + runtime: true + content: | + [Match] + Name=en* + [Network] + DHCP=none + - name: get-kube-tools.service + runtime: true + command: start + content: | + [Service] + ExecStartPre=-/usr/bin/mkdir -p /opt/bin + ExecStart=/opt/bin/kubernetes-download.sh + RemainAfterExit=yes + Type=oneshot + - name: setup-network-environment.service + command: start + content: | + [Unit] + Description=Setup Network Environment + Documentation=https://github.com/kelseyhightower/setup-network-environment + Requires=network-online.target + After=network-online.target + [Service] + ExecStartPre=-/usr/bin/mkdir -p /opt/bin + ExecStartPre=/usr/bin/wget -N -P /opt/bin http:///setup-network-environment + ExecStartPre=/usr/bin/chmod +x /opt/bin/setup-network-environment + ExecStart=/opt/bin/setup-network-environment + RemainAfterExit=yes + Type=oneshot + - name: etcd.service + command: start + content: | + [Unit] + Description=etcd + Requires=setup-network-environment.service + After=setup-network-environment.service + [Service] + EnvironmentFile=/etc/network-environment + User=etcd + PermissionsStartOnly=true + ExecStart=/usr/bin/etcd \ + --name ${DEFAULT_IPV4} \ + --addr ${DEFAULT_IPV4}:4001 \ + --bind-addr 0.0.0.0 \ + --cluster-active-size 1 \ + --data-dir /var/lib/etcd \ + --http-read-timeout 86400 \ + --peer-addr ${DEFAULT_IPV4}:7001 \ + --snapshot true + Restart=always + RestartSec=10s + - name: fleet.socket + command: start + content: | + [Socket] + ListenStream=/var/run/fleet.sock + - name: fleet.service + command: start + content: | + [Unit] + Description=fleet daemon + Wants=etcd.service + After=etcd.service + Wants=fleet.socket + After=fleet.socket + [Service] + Environment="FLEET_ETCD_SERVERS=http://127.0.0.1:4001" + Environment="FLEET_METADATA=role=master" + ExecStart=/usr/bin/fleetd + Restart=always + RestartSec=10s + - name: etcd-waiter.service + command: start + content: | + [Unit] + Description=etcd waiter + Wants=network-online.target + Wants=etcd.service + After=etcd.service + After=network-online.target + Before=flannel.service + Before=setup-network-environment.service + [Service] + ExecStartPre=/usr/bin/chmod +x /opt/bin/waiter.sh + ExecStart=/usr/bin/bash /opt/bin/waiter.sh + RemainAfterExit=true + Type=oneshot + - name: flannel.service + command: start + content: | + [Unit] + Wants=etcd-waiter.service + After=etcd-waiter.service + Requires=etcd.service + After=etcd.service + After=network-online.target + Wants=network-online.target + Description=flannel is an etcd backed overlay network for containers + [Service] + Type=notify + ExecStartPre=-/usr/bin/mkdir -p /opt/bin + ExecStartPre=/usr/bin/wget -N -P /opt/bin http:///flanneld + ExecStartPre=/usr/bin/chmod +x /opt/bin/flanneld + ExecStartPre=-/usr/bin/etcdctl mk /coreos.com/network/config '{"Network":"10.100.0.0/16", "Backend": {"Type": "vxlan"}}' + ExecStart=/opt/bin/flanneld + - name: kube-apiserver.service + command: start + content: | + [Unit] + Description=Kubernetes API Server + Documentation=https://github.com/kubernetes/kubernetes + Requires=etcd.service + After=etcd.service + [Service] + ExecStartPre=-/usr/bin/mkdir -p /opt/bin + ExecStartPre=/usr/bin/wget -N -P /opt/bin http:///kube-apiserver + ExecStartPre=/usr/bin/chmod +x /opt/bin/kube-apiserver + ExecStart=/opt/bin/kube-apiserver \ + --address=0.0.0.0 \ + --port=8080 \ + --service-cluster-ip-range=10.100.0.0/16 \ + --etcd-servers=http://127.0.0.1:4001 \ + --logtostderr=true + Restart=always + RestartSec=10 + - name: kube-controller-manager.service + command: start + content: | + [Unit] + Description=Kubernetes Controller Manager + Documentation=https://github.com/kubernetes/kubernetes + Requires=kube-apiserver.service + After=kube-apiserver.service + [Service] + ExecStartPre=/usr/bin/wget -N -P /opt/bin http:///kube-controller-manager + ExecStartPre=/usr/bin/chmod +x /opt/bin/kube-controller-manager + ExecStart=/opt/bin/kube-controller-manager \ + --master=127.0.0.1:8080 \ + --logtostderr=true + Restart=always + RestartSec=10 + - name: kube-scheduler.service + command: start + content: | + [Unit] + Description=Kubernetes Scheduler + Documentation=https://github.com/kubernetes/kubernetes + Requires=kube-apiserver.service + After=kube-apiserver.service + [Service] + ExecStartPre=/usr/bin/wget -N -P /opt/bin http:///kube-scheduler + ExecStartPre=/usr/bin/chmod +x /opt/bin/kube-scheduler + ExecStart=/opt/bin/kube-scheduler --master=127.0.0.1:8080 + Restart=always + RestartSec=10 + - name: kube-register.service + command: start + content: | + [Unit] + Description=Kubernetes Registration Service + Documentation=https://github.com/kelseyhightower/kube-register + Requires=kube-apiserver.service + After=kube-apiserver.service + Requires=fleet.service + After=fleet.service + [Service] + ExecStartPre=/usr/bin/wget -N -P /opt/bin http:///kube-register + ExecStartPre=/usr/bin/chmod +x /opt/bin/kube-register + ExecStart=/opt/bin/kube-register \ + --metadata=role=node \ + --fleet-endpoint=unix:///var/run/fleet.sock \ + --healthz-port=10248 \ + --api-endpoint=http://127.0.0.1:8080 + Restart=always + RestartSec=10 + update: + group: stable + reboot-strategy: off +ssh_authorized_keys: + - ssh-rsa AAAAB3NzaC1yc2EAAAAD... +``` + +### node.yml + +在PXE服务器上创建并编辑文件`/var/www/html/coreos/pxe-cloud-config-slave.yml`。 + +```yaml +#cloud-config +--- +write_files: + - path: /etc/default/docker + content: | + DOCKER_EXTRA_OPTS='--insecure-registry="rdocker.example.com:5000"' +coreos: + units: + - name: 10-eno1.network + runtime: true + content: | + [Match] + Name=eno1 + [Network] + DHCP=yes + - name: 20-nodhcp.network + runtime: true + content: | + [Match] + Name=en* + [Network] + DHCP=none + - name: etcd.service + mask: true + - name: docker.service + drop-ins: + - name: 50-insecure-registry.conf + content: | + [Service] + Environment="HTTP_PROXY=http://rproxy.example.com:3128/" "NO_PROXY=localhost,127.0.0.0/8,rdocker.example.com" + - name: fleet.service + command: start + content: | + [Unit] + Description=fleet daemon + Wants=fleet.socket + After=fleet.socket + [Service] + Environment="FLEET_ETCD_SERVERS=http://:4001" + Environment="FLEET_METADATA=role=node" + ExecStart=/usr/bin/fleetd + Restart=always + RestartSec=10s + - name: flannel.service + command: start + content: | + [Unit] + After=network-online.target + Wants=network-online.target + Description=flannel is an etcd backed overlay network for containers + [Service] + Type=notify + ExecStartPre=-/usr/bin/mkdir -p /opt/bin + ExecStartPre=/usr/bin/wget -N -P /opt/bin http:///flanneld + ExecStartPre=/usr/bin/chmod +x /opt/bin/flanneld + ExecStart=/opt/bin/flanneld -etcd-endpoints http://:4001 + - name: docker.service + command: start + content: | + [Unit] + After=flannel.service + Wants=flannel.service + Description=Docker Application Container Engine + Documentation=http://docs.docker.io + [Service] + EnvironmentFile=-/etc/default/docker + EnvironmentFile=/run/flannel/subnet.env + ExecStartPre=/bin/mount --make-rprivate / + ExecStart=/usr/bin/docker -d --bip=${FLANNEL_SUBNET} --mtu=${FLANNEL_MTU} -s=overlay -H fd:// ${DOCKER_EXTRA_OPTS} + [Install] + WantedBy=multi-user.target + - name: setup-network-environment.service + command: start + content: | + [Unit] + Description=Setup Network Environment + Documentation=https://github.com/kelseyhightower/setup-network-environment + Requires=network-online.target + After=network-online.target + [Service] + ExecStartPre=-/usr/bin/mkdir -p /opt/bin + ExecStartPre=/usr/bin/wget -N -P /opt/bin http:///setup-network-environment + ExecStartPre=/usr/bin/chmod +x /opt/bin/setup-network-environment + ExecStart=/opt/bin/setup-network-environment + RemainAfterExit=yes + Type=oneshot + - name: kube-proxy.service + command: start + content: | + [Unit] + Description=Kubernetes Proxy + Documentation=https://github.com/kubernetes/kubernetes + Requires=setup-network-environment.service + After=setup-network-environment.service + [Service] + ExecStartPre=/usr/bin/wget -N -P /opt/bin http:///kube-proxy + ExecStartPre=/usr/bin/chmod +x /opt/bin/kube-proxy + ExecStart=/opt/bin/kube-proxy \ + --etcd-servers=http://:4001 \ + --logtostderr=true + Restart=always + RestartSec=10 + - name: kube-kubelet.service + command: start + content: | + [Unit] + Description=Kubernetes Kubelet + Documentation=https://github.com/kubernetes/kubernetes + Requires=setup-network-environment.service + After=setup-network-environment.service + [Service] + EnvironmentFile=/etc/network-environment + ExecStartPre=/usr/bin/wget -N -P /opt/bin http:///kubelet + ExecStartPre=/usr/bin/chmod +x /opt/bin/kubelet + ExecStart=/opt/bin/kubelet \ + --address=0.0.0.0 \ + --port=10250 \ + --hostname-override=${DEFAULT_IPV4} \ + --api-servers=:8080 \ + --healthz-bind-address=0.0.0.0 \ + --healthz-port=10248 \ + --logtostderr=true + Restart=always + RestartSec=10 + update: + group: stable + reboot-strategy: off +ssh_authorized_keys: + - ssh-rsa AAAAB3NzaC1yc2EAAAAD... +``` + +## 创建pxelinux.cfg相关文件 + +为 _slave_ 节点创建一个pxelinux目标文件： `vi /tftpboot/pxelinux.cfg/coreos-node-slave` + +```conf +default coreos +prompt 1 +timeout 15 + +display boot.msg + +label coreos + menu default + kernel images/coreos/coreos_production_pxe.vmlinuz + append initrd=images/coreos/coreos_production_pxe_image.cpio.gz cloud-config-url=http:///coreos/pxe-cloud-config-slave.yml console=tty0 console=ttyS0 coreos.autologin=tty1 coreos.autologin=ttyS0 +``` + +为 _master_ 节点也创建一个： `vi /tftpboot/pxelinux.cfg/coreos-node-master` + +```conf +default coreos +prompt 1 +timeout 15 + +display boot.msg + +label coreos + menu default + kernel images/coreos/coreos_production_pxe.vmlinuz + append initrd=images/coreos/coreos_production_pxe_image.cpio.gz cloud-config-url=http:///coreos/pxe-cloud-config-master.yml console=tty0 console=ttyS0 coreos.autologin=tty1 coreos.autologin=ttyS0 +``` + +## 指定pxelinux目标 + +在上一步骤中我们已经设置了master和slave节点的目标, 我们需要将特定的主机配置为这些目标。为实现这一点，我们可以通过将指定的MAC地址配置到指定的pxelinux.cfg文件的方法来解决。 + +参照本文开始时的MAC地址列表，可以做出下文中的修改。更多细节信息请参阅[相关文档](http://www.syslinux.org/wiki/index.php/PXELINUX). + +```shell +cd /tftpboot/pxelinux.cfg +ln -s coreos-node-master 01-d0-00-67-13-0d-00 +ln -s coreos-node-slave 01-d0-00-67-13-0d-01 +ln -s coreos-node-slave 01-d0-00-67-13-0d-02 +``` + +重启这些服务器令这些镜像PXE化并准备开始运行容器！ + +## 创建测试pod + +现在，Kubernetes已经成功部署在CoreOS上了，我们可以创建一些pod来测试部署。 + +请参考[一个简单的nginx样例部署](/docs/user-guide/simple-nginx)来测试集群环境。 + +更多完整的应用程序示例，请参阅[示例目录](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/)中的各种例子。 + +## 一些用于调试的帮助命令 + +列出etcd中的所有关键字： + +```shell +etcdctl ls --recursive +``` + +列出所有fleet集群中的机器： + +```shell +fleetctl list-machines +``` + +查阅master节点上各种Kubernetes服务的系统状态： + +```shell +systemctl status kube-apiserver +systemctl status kube-controller-manager +systemctl status kube-scheduler +systemctl status kube-register +``` + +查阅集群节点上各种服务的系统状态： + +```shell +systemctl status kube-kubelet +systemctl status docker.service +``` + +列举Kubernetes环境中的各种对象： + +```shell +kubectl get pods +kubectl get nodes +``` + +结束Kubernetes中的所有pod： + +```shell +for i in `kubectl get pods | awk '{print $1}'`; do kubectl delete pod $i; done +``` + +## 支持级别 + + +IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level +-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- +Bare-metal (Offline) | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/coreos/bare_metal_offline) | | Community ([@jeffbean](https://github.com/jeffbean)) + +有关所有解决方案的支持级别信息，请参阅[解决方案列表](/docs/getting-started-guides/#table-of-solutions)。 \ No newline at end of file diff --git a/css/callouts.css b/css/callouts.css new file mode 100644 index 0000000000..f3f34bbaee --- /dev/null +++ b/css/callouts.css @@ -0,0 +1,19 @@ +.caution, .note, .warning { + padding: 20px; + margin: 20px 0; + border: 1px solid #eee; + border-left-width: 5px; + border-radius: 3px; +} + +.caution { + border-left-color: #f0ad4e; +} + +.note { + border-left-color: #428bca; +} + +.warning { + border-left-color: #d9534f; +} diff --git a/docs/admin/admission-controllers.md b/docs/admin/admission-controllers.md index 266e98c9c2..3602bd43a6 100644 --- a/docs/admin/admission-controllers.md +++ b/docs/admin/admission-controllers.md @@ -232,7 +232,8 @@ See the [InitialResouces proposal](https://git.k8s.io/community/contributors/des ### NamespaceLifecycle This plug-in enforces that a `Namespace` that is undergoing termination cannot have new objects created in it, -and ensures that requests in a non-existent `Namespace` are rejected. +and ensures that requests in a non-existent `Namespace` are rejected. This plug-in also prevents deletion of +three system reserved namespaces `default`, `kube-system`, `kube-public`. A `Namespace` deletion kicks off a sequence of operations that remove all objects (pods, services, etc.) in that namespace. In order to enforce integrity of that process, we strongly recommend running this plug-in. diff --git a/docs/admin/authentication.md b/docs/admin/authentication.md index 2033b33206..f8ba5cb440 100644 --- a/docs/admin/authentication.md +++ b/docs/admin/authentication.md @@ -447,8 +447,8 @@ The request body will be of the following format: } ``` -The remote service is expected to fill the `TokenAccessReviewStatus` field of -the request to indicate the success of the login. The response body's "spec" +The remote service is expected to fill the `status` field of +the request to indicate the success of the login. The response body's `spec` field is ignored and may be omitted. A successful validation of the bearer token would return: diff --git a/docs/admin/authorization/webhook.md b/docs/admin/authorization/webhook.md index 1ceaa7a23b..6d2adc9d6f 100644 --- a/docs/admin/authorization/webhook.md +++ b/docs/admin/authorization/webhook.md @@ -86,9 +86,9 @@ An example request body: } ``` -The remote service is expected to fill the SubjectAccessReviewStatus field of +The remote service is expected to fill the `status` field of the request and respond to either allow or disallow access. The response body's -"spec" field is ignored and may be omitted. A permissive response would return: +`spec` field is ignored and may be omitted. A permissive response would return: ```json { diff --git a/docs/admin/extensible-admission-controllers.md b/docs/admin/extensible-admission-controllers.md index 6268639bdc..47bd8bc217 100644 --- a/docs/admin/extensible-admission-controllers.md +++ b/docs/admin/extensible-admission-controllers.md @@ -3,7 +3,7 @@ assignees: - smarterclayton - lavalamp - whitlockjc -- caesrxuchao +- caesarxuchao title: Dynamic Admission Control --- @@ -41,7 +41,7 @@ This page describes how to use Initializers and External Admission Webhooks. Once the controller has performed its assigned task, it removes its name from the list. For example, it may send a PATCH that inserts a container in a pod and -also removes its name from `metadata.initializers`. Initializers may make +also removes its name from `metadata.initializers.pending`. Initializers may make mutations to objects. Objects which have a non-empty initializer list are considered uninitialized, @@ -64,7 +64,7 @@ external admission webhooks, as they have better performance. When an object is POSTed, it is checked against all existing `initializerConfiguration` objects (explained below). For all that it matches, all `spec.initializers[].name`s are appended to the new object's -`metadata.initializers` field. +`metadata.initializers.pending` field. An initializer controller should list and watch for uninitialized objects, by using the query parameter `?includeUninitialized=true`. If using client-go, just @@ -73,7 +73,7 @@ set to true. For the observed uninitialized objects, an initializer controller should first -check if its name matches `metadata.initializers[0]`. If so, it should then +check if its name matches `metadata.initializers.pending[0]`. If so, it should then perform its assigned task and remove its name from the list. ### Enable initializers alpha feature @@ -81,7 +81,7 @@ perform its assigned task and remove its name from the list. *Initializers* is an alpha feature, so it is disabled by default. To turn it on, you need to: -* Include "Initializer" in the `--admission-control` flag when starting +* Include "Initializers" in the `--admission-control` flag when starting `kube-apiserver`. If you have multiple `kube-apiserver` replicas, all should have the same flag setting. @@ -99,13 +99,13 @@ API](/docs/api-reference/{{page.version}}/#deployment-v1beta1-apps). ### Configure initializers on the fly You can configure what initializers are enabled and what resources are subject -to the initializers by creating `initializerconfigurations`. +to the initializers by creating `initializerConfiguration` resources. You should first deploy the initializer controller and make sure that it is -working properly before creating the `initializerconfigurations`. Otherwise, any +working properly before creating the `initializerConfiguration`. Otherwise, any newly created resources will be stuck in an uninitialized state. -The following is an example `initiallizerConfiguration`. +The following is an example `initializerConfiguration`: ```yaml apiVersion: admissionregistration.k8s.io/v1alpha1 @@ -126,12 +126,16 @@ initializers: - pods ``` +After you create the `initializerConfiguration`, the system will take a few +seconds to honor the new configuration. Then, `"podimage.example.com"` will be +appended to the `metadata.initializers.pending` field of newly created pods. You +should already have a ready "podimage" initializer controller that handles pods +whose `metadata.initializers.pending[0].name="podimage.example.com"`. Otherwise +the pods will stuck uninitialized. + Make sure that all expansions of the `` tuple in a `rule` are valid. If they are not, separate them in different `rules`. -After you create the `initializerConfiguration`, the system will take a few -seconds to honor the new configuration. - ## External Admission Webhooks ### What are external admission webhooks? @@ -232,7 +236,7 @@ it is working properly before creating the externaladmissionhookconfigurations. Otherwise, depending whether the webhook is configured as fail open or fail closed, operations will be unconditionally accepted or rejected. -The following is an example externaladmissionhookconfiguration. +The following is an example `externaladmissionhookconfiguration`: ```yaml apiVersion: admissionregistration.k8s.io/v1alpha1 diff --git a/docs/admin/kubelet-tls-bootstrapping.md b/docs/admin/kubelet-tls-bootstrapping.md index a8c9f0c701..93bde8b44c 100644 --- a/docs/admin/kubelet-tls-bootstrapping.md +++ b/docs/admin/kubelet-tls-bootstrapping.md @@ -17,11 +17,19 @@ and progress on the feature is being tracked as [feature #43](https://github.com ## kube-apiserver configuration -You must provide a token file which specifies at least one "bootstrap token" assigned to a kubelet bootstrap-specific group. +The API server should be configured with an [authenticator](/docs/admin/authentication/) that can authenticate tokens as a user in the `system:bootstrappers` group. + This group will later be used in the controller-manager configuration to scope approvals in the default approval controller. As this feature matures, you should ensure tokens are bound to a Role-Based Access Control (RBAC) policy which limits requests (using the bootstrap token) strictly to client requests related to certificate provisioning. With RBAC in place, scoping the tokens to a group allows for great flexibility (e.g. you could disable a particular bootstrap group's access when you are done provisioning the nodes). +While any authentication strategy can be used for the kubelet's initial bootstrap credentials, the following two authenticators are recommended for ease of provisioning. + +1. [Bootstrap Tokens](/docs/admin/bootstrap-tokens/) - __alpha__ +2. [Token authentication file](###token-authentication-file) + +Using bootstrap tokens is currently __alpha__ and will simplify the management of bootstrap token management especially in a HA scenario. + ### Token authentication file Tokens are arbitrary but should represent at least 128 bits of entropy derived from a secure random number generator (such as /dev/urandom on most modern systems). There are multiple ways you can generate a token. For example: @@ -34,7 +42,7 @@ The token file should look like the following example, where the first three val name should be as depicted: ``` -02b50b05283e98dd0fd71db496ef01e8,kubelet-bootstrap,10001,"system:kubelet-bootstrap" +02b50b05283e98dd0fd71db496ef01e8,kubelet-bootstrap,10001,"system:bootstrappers" ``` Add the `--token-auth-file=FILENAME` flag to the kube-apiserver command (in your systemd unit file perhaps) to enable the token file. @@ -127,20 +135,20 @@ provided by the removed auto-approval flag, of approving all CSRs by a single gr ``` # REMOVED: This flag no longer works as of 1.7. ---insecure-experimental-approve-all-kubelet-csrs-for-group="kubelet-bootstrap-token" +--insecure-experimental-approve-all-kubelet-csrs-for-group="system:bootstrappers" ``` An admin would create a `ClusterRoleBinding` targeting that group. ```yml -# Approve all CSRs for the group "kubelet-bootstrap-token" +# Approve all CSRs for the group "system:bootstrappers" kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: auto-approve-csrs-for-group subjects: - kind: Group - name: kubelet-bootstrap-token + name: system:bootstrappers apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole @@ -179,10 +187,11 @@ kubectl config set-credentials kubelet-bootstrap --token=${BOOTSTRAP_TOKEN} --ku When starting the kubelet, if the file specified by `--kubeconfig` does not exist, the bootstrap kubeconfig is used to request a client certificate from the API server. On approval of the certificate request and receipt back by the kubelet, a kubeconfig file referencing the generated key and obtained certificate is written to the path specified by `--kubeconfig`. The certificate and key file will be placed in the directory specified by `--cert-dir`. -The flag to enable this bootstrapping when starting the kubelet is: +**Note:** The following flags are required to enable this bootstrapping when starting the kubelet: ``` ---experimental-bootstrap-kubeconfig="/path/to/bootstrap/kubeconfig" +--require-kubeconfig +--bootstrap-kubeconfig="/path/to/bootstrap/kubeconfig" ``` Additionally, in 1.7 the kubelet implements __alpha__ features for enabling rotation of both its client and/or serving certs. diff --git a/docs/concepts/api-extension/custom-resources.md b/docs/concepts/api-extension/custom-resources.md index 5ee2900ca3..43cc9256c2 100644 --- a/docs/concepts/api-extension/custom-resources.md +++ b/docs/concepts/api-extension/custom-resources.md @@ -63,7 +63,7 @@ persistent storage of objects. The main Kubernetes API server handles built-in resources like *pods* and *services*, and can also handle custom resources in a generic way through [CustomResourceDefinitions](#customresourcedefinitions). -The [aggregation layer](/docs/concepts/api-extension/) allows you to provide specialized +The [aggregation layer](/docs/concepts/api-extension/apiserver-aggregation/) allows you to provide specialized implementations for your custom resources by writing and deploying your own standalone API server. The main API server delegates requests to you for the custom resources that you handle, making them available to all of its clients. diff --git a/docs/concepts/architecture/master-node-communication.md b/docs/concepts/architecture/master-node-communication.md index 1e35922b1a..48b668990d 100644 --- a/docs/concepts/architecture/master-node-communication.md +++ b/docs/concepts/architecture/master-node-communication.md @@ -4,11 +4,6 @@ assignees: - roberthbailey - liggitt title: Master-Node communication -redirect_from: -- "/docs/admin/master-node-communication/" -- "/docs/admin/master-node-communication.html" -- "/docs/concepts/cluster-administration/master-node-communication/" -- "/docs/concepts/cluster-administration/master-node-communication.html" --- * TOC @@ -30,18 +25,18 @@ services). In a typical deployment, the apiserver is configured to listen for remote connections on a secure HTTPS port (443) with one or more forms of client [authentication](/docs/admin/authentication/) enabled. One or more forms of [authorization](/docs/admin/authorization/) should be enabled, especially -if [anonymous requests](/docs/admin/authentication/#anonymous-requests) or -[service account tokens](/docs/admin/authentication/#service-account-tokens) +if [anonymous requests](/docs/admin/authentication/#anonymous-requests) or +[service account tokens](/docs/admin/authentication/#service-account-tokens) are allowed. Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. For example, on a default GCE deployment, the client credentials -provided to the kubelet are in the form of a client certificate. See -[kubelet TLS bootstrapping](/docs/admin/kubelet-tls-bootstrapping/) for -automated provisioning of kubelet client certificates. +provided to the kubelet are in the form of a client certificate. See +[kubelet TLS bootstrapping](/docs/admin/kubelet-tls-bootstrapping/) for +automated provisioning of kubelet client certificates. -Pods that wish to connect to the apiserver can do so securely by leveraging a +Pods that wish to connect to the apiserver can do so securely by leveraging a service account so that Kubernetes will automatically inject the public root certificate and a valid bearer token into the pod when it is instantiated. The `kubernetes` service (in all namespaces) is configured with a virtual IP @@ -71,23 +66,23 @@ or service through the apiserver's proxy functionality. The connections from the apiserver to the kubelet are used for fetching logs for pods, attaching (through kubectl) to running pods, and using the kubelet's -port-forwarding functionality. These connections terminate at the kubelet's +port-forwarding functionality. These connections terminate at the kubelet's HTTPS endpoint. By default, the apiserver does not verify the kubelet's serving certificate, -which makes the connection subject to man-in-the-middle attacks, and +which makes the connection subject to man-in-the-middle attacks, and **unsafe** to run over untrusted and/or public networks. -To verify this connection, use the `--kubelet-certificate-authority` flag to -provide the apiserver with a root certificates bundle to use to verify the +To verify this connection, use the `--kubelet-certificate-authority` flag to +provide the apiserver with a root certificates bundle to use to verify the kubelet's serving certificate. If that is not possible, use [SSH tunneling](/docs/admin/master-node-communication/#ssh-tunnels) -between the apiserver and kubelet if required to avoid connecting over an +between the apiserver and kubelet if required to avoid connecting over an untrusted or public network. Finally, [Kubelet authentication and/or authorization](/docs/admin/kubelet-authentication-authorization/) -should be enabled to secure the kubelet API. +should be enabled to secure the kubelet API. ### apiserver -> nodes, pods, and services diff --git a/docs/concepts/architecture/nodes.md b/docs/concepts/architecture/nodes.md index 7afc36a1ee..a66d6fd7d4 100644 --- a/docs/concepts/architecture/nodes.md +++ b/docs/concepts/architecture/nodes.md @@ -3,11 +3,6 @@ assignees: - caesarxuchao - dchen1107 title: Nodes -redirect_from: -- "/docs/admin/node/" -- "/docs/admin/node.html" -- "/docs/concepts/nodes/node/" -- "/docs/concepts/nodes/node.html" --- * TOC @@ -54,8 +49,8 @@ The `conditions` field describes the status of all `Running` nodes. |----------------|-------------| | `OutOfDisk` | `True` if there is insufficient free space on the node for adding new pods, otherwise `False` | | `Ready` | `True` if the node is healthy and ready to accept pods, `False` if the node is not healthy and is not accepting pods, and `Unknown` if the node controller has not heard from the node in the last 40 seconds | -| `MemoryPressure` | `True` if node has no memory pressure, otherwise `False` | -| `DiskPressure` | `True` if node has no disk pressure, otherwise `False` | +| `MemoryPressure` | `True` if pressure exists on the node memory -- that is, if the node memory is low; otherwise `False` | +| `DiskPressure` | `True` if pressure exists on the disk size -- that is, if the disk capacity is low; otherwise `False` | The node condition is represented as a JSON object. For example, the following response describes a healthy node. @@ -68,7 +63,7 @@ The node condition is represented as a JSON object. For example, the following r ] ``` -If the Status of the Ready condition is "Unknown" or "False" for longer than the `pod-eviction-timeout`, an argument passed to the [kube-controller-manager](/docs/admin/kube-controller-manager/), all of the Pods on the node are scheduled for deletion by the Node Controller. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the apiserver is unable to communicate with the kubelet on it. The decision to delete the pods cannot be communicated to the kubelet until it re-establishes communication with the apiserver. In the meantime, the pods which are scheduled for deletion may continue to run on the partitioned node. +If the Status of the Ready condition is "Unknown" or "False" for longer than the `pod-eviction-timeout`, an argument passed to the [kube-controller-manager](/docs/admin/kube-controller-manager/), all of the Pods on the node are scheduled for deletion by the Node Controller. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the apiserver is unable to communicate with the kubelet on it. The decision to delete the pods cannot be communicated to the kubelet until it re-establishes communication with the apiserver. In the meantime, the pods which are scheduled for deletion may continue to run on the partitioned node. In versions of Kubernetes prior to 1.5, the node controller would [force delete](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) these unreachable pods from the apiserver. However, in 1.5 and higher, the node controller does not force delete pods until it is confirmed that they have stopped running in the cluster. One can see these pods which may be running on an unreachable node as being in the "Terminating" or "Unknown" states. In cases where Kubernetes cannot deduce from the underlying infrastructure if a node has permanently left a cluster, the cluster administrator may need to delete the node object by hand. Deleting the node object from Kubernetes causes all the Pod objects running on it to be deleted from the apiserver, freeing up their names. diff --git a/docs/concepts/cluster-administration/addons.md b/docs/concepts/cluster-administration/addons.md index b8c492679c..53b94997dc 100644 --- a/docs/concepts/cluster-administration/addons.md +++ b/docs/concepts/cluster-administration/addons.md @@ -1,8 +1,5 @@ --- title: Installing Addons -redirect_from: -- "/docs/admin/addons/" -- "/docs/admin/addons.html" --- ## Overview diff --git a/docs/concepts/cluster-administration/cluster-administration-overview.md b/docs/concepts/cluster-administration/cluster-administration-overview.md index fa6aee797d..e47b15c117 100644 --- a/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -3,11 +3,6 @@ assignees: - davidopp - lavalamp title: Cluster Administration Overview -redirect_from: -- "/docs/admin/" -- "/docs/admin/index.html" -- "/docs/tasks/administer-cluster/overview/" -- "/docs/tasks/administer-cluster/overview.html" --- {% capture overview %} diff --git a/docs/concepts/cluster-administration/federation.md b/docs/concepts/cluster-administration/federation.md index 5a698c7fb7..c62be6f39f 100644 --- a/docs/concepts/cluster-administration/federation.md +++ b/docs/concepts/cluster-administration/federation.md @@ -1,12 +1,5 @@ --- title: Federation -redirect_from: -- "/docs/user-guide/federation/" -- "/docs/user-guide/federation/index.html" -- "/docs/concepts/cluster-administration/multiple-clusters/" -- "/docs/concepts/cluster-administration/multiple-clusters.html" -- "/docs/admin/multi-cluster/" -- "/docs/admin/multi-cluster.html" --- {% capture overview %} @@ -48,7 +41,7 @@ why you might want multiple clusters are: * [Hybrid cloud](###hybrid-cloud-capabilities): You can have multiple clusters on different cloud providers or on-premises data centers. -### Caveats +### Caveats While there are a lot of attractive use cases for federation, there are also some caveats: diff --git a/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/docs/concepts/cluster-administration/kubelet-garbage-collection.md index bc9ea79282..e4b00f765b 100644 --- a/docs/concepts/cluster-administration/kubelet-garbage-collection.md +++ b/docs/concepts/cluster-administration/kubelet-garbage-collection.md @@ -2,9 +2,6 @@ assignees: - mikedanese title: Configuring kubelet Garbage Collection -redirect_from: -- "/docs/admin/garbage-collection/" -- "/docs/admin/garbage-collection.html" --- * TOC diff --git a/docs/concepts/cluster-administration/logging.md b/docs/concepts/cluster-administration/logging.md index 13773c90fd..d74e1eafc6 100644 --- a/docs/concepts/cluster-administration/logging.md +++ b/docs/concepts/cluster-administration/logging.md @@ -3,12 +3,6 @@ assignees: - crassirostris - piosz title: Logging Architecture -redirect_from: -- "/docs/concepts/clusters/logging/" -- "/docs/concepts/clusters/logging.html" -redirect_from: -- "/docs/user-guide/logging/overview/" -- "/docs/user-guide/logging/overview.html" --- Application and systems logs can help you understand what is happening inside your cluster. The logs are particularly useful for debugging problems and monitoring cluster activity. Most modern applications have some kind of logging mechanism; as such, most container engines are likewise designed to support some kind of logging. The easiest and most embraced logging method for containerized applications is to write to the standard output and standard error streams. diff --git a/docs/concepts/cluster-administration/manage-deployment.md b/docs/concepts/cluster-administration/manage-deployment.md index 904c0b61e6..c59278786c 100644 --- a/docs/concepts/cluster-administration/manage-deployment.md +++ b/docs/concepts/cluster-administration/manage-deployment.md @@ -4,9 +4,6 @@ assignees: - janetkuo - mikedanese title: Managing Resources -redirect_from: -- "/docs/user-guide/managing-deployments/" -- "/docs/user-guide/managing-deployments.html" --- You've deployed your application and exposed it via a service. Now what? Kubernetes provides a number of tools to help you manage your application deployment, including scaling and updating. Among the features we'll discuss in more depth are [configuration files](/docs/user-guide/configuring-containers/#configuration-in-kubernetes) and [labels](/docs/user-guide/deploying-applications/#labels). diff --git a/docs/concepts/cluster-administration/network-plugins.md b/docs/concepts/cluster-administration/network-plugins.md index d36a6c7f42..c0eee99423 100644 --- a/docs/concepts/cluster-administration/network-plugins.md +++ b/docs/concepts/cluster-administration/network-plugins.md @@ -4,9 +4,6 @@ assignees: - freehan - thockin title: Network Plugins -redirect_from: -- "/docs/admin/network-plugins/" -- "/docs/admin/network-plugins.html" --- * TOC diff --git a/docs/concepts/cluster-administration/networking.md b/docs/concepts/cluster-administration/networking.md index c65f3ca158..fccf11262a 100644 --- a/docs/concepts/cluster-administration/networking.md +++ b/docs/concepts/cluster-administration/networking.md @@ -2,9 +2,6 @@ assignees: - thockin title: Cluster Networking -redirect_from: -- "/docs/admin/networking/" -- "/docs/admin/networking.html" --- Kubernetes approaches networking somewhat differently than Docker does by @@ -85,7 +82,7 @@ talk to other VMs in your project. This is the same basic model. Until now this document has talked about containers. In reality, Kubernetes applies IP addresses at the `Pod` scope - containers within a `Pod` share their network namespaces - including their IP address. This means that containers -within a `Pod` can all reach each other's ports on `localhost`. This does imply +within a `Pod` can all reach each other's ports on `localhost`. This does imply that containers within a `Pod` must coordinate port usage, but this is no different than processes in a VM. We call this the "IP-per-pod" model. This is implemented in Docker as a "pod container" which holds the network namespace @@ -217,9 +214,9 @@ Calico can also be run in policy enforcement mode in conjunction with other netw ### Weave Net from Weaveworks -[Weave Net](https://www.weave.works/products/weave-net/) is a -resilient and simple to use network for Kubernetes and its hosted applications. -Weave Net runs as a [CNI plug-in](https://www.weave.works/docs/net/latest/cni-plugin/) +[Weave Net](https://www.weave.works/products/weave-net/) is a +resilient and simple to use network for Kubernetes and its hosted applications. +Weave Net runs as a [CNI plug-in](https://www.weave.works/docs/net/latest/cni-plugin/) or stand-alone. In either version, it doesn't require any configuration or extra code to run, and in both cases, the network provides one IP address per pod - as is standard for Kubernetes. diff --git a/docs/concepts/cluster-administration/proxies.md b/docs/concepts/cluster-administration/proxies.md index 2f7dbe400f..41e29d6cef 100644 --- a/docs/concepts/cluster-administration/proxies.md +++ b/docs/concepts/cluster-administration/proxies.md @@ -1,8 +1,5 @@ --- title: Proxies in Kubernetes -redirect_from: -- "/docs/user-guide/accessing-the-cluster/" -- "/docs/user-guide/accessing-the-cluster.html" --- {% capture overview %} diff --git a/docs/concepts/cluster-administration/sysctl-cluster.md b/docs/concepts/cluster-administration/sysctl-cluster.md index f37f520354..dad60e3f73 100644 --- a/docs/concepts/cluster-administration/sysctl-cluster.md +++ b/docs/concepts/cluster-administration/sysctl-cluster.md @@ -2,9 +2,6 @@ assignees: - sttts title: Using Sysctls in a Kubernetes Cluster -redirect_from: -- "/docs/admin/sysctls/" -- "/docs/admin/sysctls.html" --- * TOC diff --git a/docs/concepts/configuration/assign-pod-node.md b/docs/concepts/configuration/assign-pod-node.md index 799edcce2d..d2a379f6ee 100644 --- a/docs/concepts/configuration/assign-pod-node.md +++ b/docs/concepts/configuration/assign-pod-node.md @@ -4,9 +4,6 @@ assignees: - kevin-wangzefeng - bsalamat title: Assigning Pods to Nodes -redirect_from: -- "/docs/user-guide/node-selection/" -- "/docs/user-guide/node-selection/index.html" --- You can constrain a [pod](/docs/concepts/workloads/pods/pod/) to only be able to run on particular [nodes](/docs/concepts/nodes/node/) or to prefer to @@ -142,6 +139,8 @@ If you specify multiple `nodeSelectorTerms` associated with `nodeAffinity` types If you specify multiple `matchExpressions` associated with `nodeSelectorTerms`, then the pod can be scheduled onto a node **only if all** `matchExpressions` can be satisfied. +If you remove or change the label of the node where the pod is scheduled, the pod won't be removed. In other words, the affinity selection works only at the time of scheduling the pod. + For more information on node affinity, see the design doc [here](https://git.k8s.io/community/contributors/design-proposals/nodeaffinity.md). @@ -205,7 +204,7 @@ If omitted, it defaults to the namespace of the pod where the affinity/anti-affi If defined but empty, it means "all namespaces." All `matchExpressions` associated with `requiredDuringSchedulingIgnoredDuringExecution` affinity and anti-affinity -must be satisfied for the pod to schedule onto a node. +must be satisfied for the pod to schedule onto a node. For more information on inter-pod affinity/anti-affinity, see the design doc [here](https://git.k8s.io/community/contributors/design-proposals/podaffinity.md). @@ -236,7 +235,7 @@ taint created by the `kubectl taint` line above, and thus a pod with either tole to schedule onto `node1`: ```yaml -tolerations: +tolerations: - key: "key" operator: "Equal" value: "value" @@ -244,7 +243,7 @@ tolerations: ``` ```yaml -tolerations: +tolerations: - key: "key" operator: "Exists" effect: "NoSchedule" @@ -304,7 +303,7 @@ kubectl taint nodes node1 key2=value2:NoSchedule And a pod has two tolerations: ```yaml -tolerations: +tolerations: - key: "key1" operator: "Equal" value: "value1" @@ -327,7 +326,7 @@ an optional `tolerationSeconds` field that dictates how long the pod will stay b to the node after the taint is added. For example, ```yaml -tolerations: +tolerations: - key: "key1" operator: "Equal" value: "value1" @@ -345,7 +344,7 @@ Taints and tolerations are a flexible way to steer pods away from nodes or evict pods that shouldn't be running. A few of the use cases are * **dedicated nodes**: If you want to dedicate a set of nodes for exclusive use by -a particular set of users, you can add a taint to those nodes (say, +a particular set of users, you can add a taint to those nodes (say, `kubectl taint nodes nodename dedicated=groupName:NoSchedule`) and then add a corresponding toleration to their pods (this would be done most easily by writing a custom [admission controller](/docs/admin/admission-controllers/)). @@ -410,7 +409,7 @@ that the partition will recover and thus the pod eviction can be avoided. The toleration the pod would use in that case would look like ```yaml -tolerations: +tolerations: - key: "node.alpha.kubernetes.io/unreachable" operator: "Exists" effect: "NoExecute" diff --git a/docs/concepts/configuration/manage-compute-resources-container.md b/docs/concepts/configuration/manage-compute-resources-container.md index 2858dbd726..b9077f63f4 100644 --- a/docs/concepts/configuration/manage-compute-resources-container.md +++ b/docs/concepts/configuration/manage-compute-resources-container.md @@ -1,8 +1,5 @@ --- title: Managing Compute Resources for Containers -redirect_from: -- "/docs/user-guide/compute-resources/" -- "/docs/user-guide/compute-resources.html" --- {% capture overview %} @@ -197,7 +194,7 @@ is pending with a message of this type, there are several things to try: - Add more nodes to the cluster. - Terminate unneeded Pods to make room for pending Pods. - Check that the Pod is not larger than all the nodes. For example, if all the - nodes have a capacity of `cpu: 1`, then a Pod with a limit of `cpu: 1.1` will + nodes have a capacity of `cpu: 1`, then a Pod with a request of `cpu: 1.1` will never be scheduled. You can check node capacities and amounts allocated with the @@ -241,7 +238,7 @@ the node. The amount of resources available to Pods is less than the node capacity, because system daemons use a portion of the available resources. The `allocatable` field -[NodeStatus](/docs/resources-reference/v1.6/#nodestatus-v1-core) +[NodeStatus](/docs/resources-reference/{{page.version}}/#nodestatus-v1-core) gives the amount of resources that are available to Pods. For more information, see [Node Allocatable Resources](https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md). @@ -430,9 +427,9 @@ consistency across providers and platforms. * Get hands-on experience [assigning CPU and RAM resources to a container](/docs/tasks/configure-pod-container/assign-cpu-ram-container/). -* [Container](/docs/api-reference/v1.6/#container-v1-core) +* [Container](/docs/api-reference/{{page.version}}/#container-v1-core) -* [ResourceRequirements](/docs/resources-reference/v1.6/#resourcerequirements-v1-core) +* [ResourceRequirements](/docs/resources-reference/{{page.version}}/#resourcerequirements-v1-core) {% endcapture %} diff --git a/docs/concepts/configuration/overview.md b/docs/concepts/configuration/overview.md index a31d3c2156..e2e4b0f2e5 100644 --- a/docs/concepts/configuration/overview.md +++ b/docs/concepts/configuration/overview.md @@ -2,9 +2,6 @@ assignees: - mikedanese title: Configuration Best Practices -redirect_from: -- "/docs/user-guide/config-best-practices/" -- "/docs/user-guide/config-best-practices.html" --- {% capture overview %} diff --git a/docs/concepts/configuration/secret.md b/docs/concepts/configuration/secret.md index bcfc3df241..f72d4537e0 100644 --- a/docs/concepts/configuration/secret.md +++ b/docs/concepts/configuration/secret.md @@ -2,9 +2,6 @@ assignees: - mikedanese title: Secrets -redirect_from: -- "/docs/user-guide/secrets/index/" -- "/docs/user-guide/secrets/index.html" --- Objects of type `secret` are intended to hold sensitive information, such as @@ -769,6 +766,40 @@ it to read a file. +## Best practices + +### Clients that use the secrets API + +When deploying applications that interact with the secrets API, access should be +limited using [authorization policies]( +https://kubernetes.io/docs/admin/authorization/) such as [RBAC]( +https://kubernetes.io/docs/admin/authorization/rbac/). + +Secrets often hold values that span a spectrum of importance, many of which can +cause escalations within Kubernetes (e.g. service account tokens) and to +external systems. Even if an individual app can reason about the power of the +secrets it expects to interact with, other apps within the same namespace can +render those assumptions invalid. + +For these reasons `watch` and `list` requests for secrets within a namespace are +extremely powerful capabilities and should be avoided, since listing secrets allows +the clients to inspect the values if all secrets are in that namespace. The ability to +`watch` and `list` all secrets in a cluster should be reserved for only the most +privileged, system-level components. + +Applications that need to access the secrets API should perform `get` requests on +the secrets they need. This lets administrators restrict access to all secrets +while [white-listing access to individual instances]( +https://kubernetes.io/docs/admin/authorization/rbac/#referring-to-resources) that +the app needs. + +For improved performance over a looping `get`, clients can design resources that +reference a secret then `watch` the resource, re-requesting the secret when the +reference changes. Additionally, a ["bulk watch" API]( +https://github.com/kubernetes/community/blob/master/contributors/design-proposals/bulk_watch.md) +to let clients `watch` individual resources has also been proposed, and will likely +be available in future releases of Kubernetes. + ## Security Properties ### Protections diff --git a/docs/concepts/containers/container-lifecycle-hooks.md b/docs/concepts/containers/container-lifecycle-hooks.md index c53749d9d1..63ca4df1c4 100644 --- a/docs/concepts/containers/container-lifecycle-hooks.md +++ b/docs/concepts/containers/container-lifecycle-hooks.md @@ -3,15 +3,12 @@ assignees: - mikedanese - thockin title: Container Lifecycle Hooks -redirect_from: -- "/docs/user-guide/container-environment/" -- "/docs/user-guide/container-environment.html" --- {% capture overview %} This page describes how kubelet managed Containers can use the Container lifecycle hook framework -to run code triggered by events during their management lifecycle. +to run code triggered by events during their management lifecycle. {% endcapture %} @@ -34,14 +31,14 @@ There are two hooks that are exposed to Containers: This hook executes immediately after a container is created. However, there is no guarantee that the hook will execute before the container ENTRYPOINT. -No parameters are passed to the handler. +No parameters are passed to the handler. `PreStop` This hook is called immediately before a container is terminated. It is blocking, meaning it is synchronous, -so it must complete before the call to delete the container can be sent. -No parameters are passed to the handler. +so it must complete before the call to delete the container can be sent. +No parameters are passed to the handler. A more detailed description of the termination behavior can be found in [Termination of Pods](/docs/concepts/workloads/pods/pod/#termination-of-pods). @@ -58,13 +55,13 @@ Resources consumed by the command are counted against the Container. ### Hook handler execution When a Container lifecycle management hook is called, -the Kubernetes management system executes the handler in the Container registered for that hook.  +the Kubernetes management system executes the handler in the Container registered for that hook.  Hook handler calls are synchronous within the context of the Pod containing the Container. This means that for a `PostStart` hook, the Container ENTRYPOINT and hook fire asynchronously. However, if the hook takes too long to run or hangs, -the Container cannot reach a `running` state. +the Container cannot reach a `running` state. The behavior is similar for a `PreStop` hook. If the hook hangs during execution, @@ -87,16 +84,16 @@ Generally, only single deliveries are made. If, for example, an HTTP hook receiver is down and is unable to take traffic, there is no attempt to resend. In some rare cases, however, double delivery may occur. -For instance, if a kubelet restarts in the middle of sending a hook, +For instance, if a kubelet restarts in the middle of sending a hook, the hook might be resent after the kubelet comes back up. ### Debugging Hook handlers The logs for a Hook handler are not exposed in Pod events. If a handler fails for some reason, it broadcasts an event. -For `PostStart`, this is the `FailedPostStartHook` event, -and for `PreStop`, this is the `FailedPreStopHook` event. -You can see these events by running `kubectl describe pod `. +For `PostStart`, this is the `FailedPostStartHook` event, +and for `PreStop`, this is the `FailedPreStopHook` event. +You can see these events by running `kubectl describe pod `. Here is some example output of events from running this command: ``` @@ -111,7 +108,7 @@ Events: 38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1 37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1 38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1" - 1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook + 1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook ``` {% endcapture %} diff --git a/docs/concepts/containers/images.md b/docs/concepts/containers/images.md index 9c9221ada8..9960185f56 100644 --- a/docs/concepts/containers/images.md +++ b/docs/concepts/containers/images.md @@ -3,9 +3,6 @@ assignees: - erictune - thockin title: Images -redirect_from: -- "/docs/user-guide/images/" -- "/docs/user-guide/images.html" --- {% capture overview %} @@ -83,7 +80,7 @@ images in the ECR registry. The kubelet will fetch and periodically refresh ECR credentials. It needs the following permissions to do this: -- `ecr:GetAuthorizationToken` +- `ecr:GetAuthorizationToken` - `ecr:BatchCheckLayerAvailability` - `ecr:GetDownloadUrlForLayer` - `ecr:GetRepositoryPolicy` diff --git a/docs/concepts/index.md b/docs/concepts/index.md index b2bf610e77..de0a601133 100644 --- a/docs/concepts/index.md +++ b/docs/concepts/index.md @@ -36,7 +36,7 @@ In addition, Kubernetes contains a number of higher-level abstractions called Co ## Kubernetes Control Plane -The various parts of the Kubernetes Control Plane, such as the Kubernetes Master and kubelet processes, govern how Kubernetes communicates with your cluster. The Control Plane maintains a record of all of the Kubernetes Objects in the system, and runs continuous control loops to manage those objects' state. At any given time, the Control Plane's control loops will respond to changes in the cluster and work to make the actual state of all the objects in the system to the desired state that you provided. +The various parts of the Kubernetes Control Plane, such as the Kubernetes Master and kubelet processes, govern how Kubernetes communicates with your cluster. The Control Plane maintains a record of all of the Kubernetes Objects in the system, and runs continuous control loops to manage those objects' state. At any given time, the Control Plane's control loops will respond to changes in the cluster and work to make the actual state of all the objects in the system match the desired state that you provided. For example, when you use the Kubernetes API to create a Deployment object, you provide a new desired state for the system. The Kubernetes Control Plane records that object creation, and carries out your instructions by starting the required applications and scheduling them to cluster nodes--thus making the cluster's actual state match the desired state. diff --git a/docs/concepts/overview/components.md b/docs/concepts/overview/components.md index acf252e893..3e6dba96c3 100644 --- a/docs/concepts/overview/components.md +++ b/docs/concepts/overview/components.md @@ -2,10 +2,8 @@ assignees: - lavalamp title: Kubernetes Components -redirect_from: -- "/docs/admin/cluster-components/" -- "/docs/admin/cluster-components.html" --- + {% capture overview %} This document outlines the various binary components needed to deliver a functioning Kubernetes cluster. @@ -15,7 +13,7 @@ deliver a functioning Kubernetes cluster. ## Master Components Master components provide the cluster's control plane. Master components make global decisions about the -cluster (for example, scheduling), and detecting and responding to cluster events (starting up a new pod when a replication controller's 'replicas' field is unsatisfied). +cluster (for example, scheduling), and detecting and responding to cluster events (starting up a new pod when a replication controller's 'replicas' field is unsatisfied). Master components can be run on any node in the cluster. However, for simplicity, set up scripts typically start all master components on @@ -28,7 +26,7 @@ Kubernetes control plane. It is designed to scale horizontally -- that is, it sc ### etcd -[etcd](/docs/admin/etcd) is used as Kubernetes' backing store. All cluster data is stored here. Always have a backup plan for etcd's data for your Kubernetes cluster. +[etcd](/docs/admin/etcd) is used as Kubernetes' backing store. All cluster data is stored here. Always have a backup plan for etcd's data for your Kubernetes cluster. ### kube-controller-manager @@ -41,12 +39,12 @@ These controllers include: controller object in the system. * Endpoints Controller: Populates the Endpoints object (that is, joins Services & Pods). * Service Account & Token Controllers: Create default accounts and API access tokens for new namespaces. - + ### cloud-controller-manager -cloud-controller-manager runs controllers that interact with the underlying cloud providers. The cloud-controller-manager binary is an alpha feature introduced in Kubernetes release 1.6. +cloud-controller-manager runs controllers that interact with the underlying cloud providers. The cloud-controller-manager binary is an alpha feature introduced in Kubernetes release 1.6. -cloud-controller-manager runs cloud-provider-specific controller loops only. You must disable these controller loops in the kube-controller-manager. You can disable the controller loops by setting the `--cloud-provider` flag to `external` when starting the kube-controller-manager. +cloud-controller-manager runs cloud-provider-specific controller loops only. You must disable these controller loops in the kube-controller-manager. You can disable the controller loops by setting the `--cloud-provider` flag to `external` when starting the kube-controller-manager. cloud-controller-manager allows cloud vendors code and the Kubernetes core to evolve independent of each other. In prior releases, the core Kubernetes code was dependent upon cloud-provider-specific code for functionality. In future releases, code specific to cloud vendors should be maintained by the cloud vendor themselves, and linked to cloud-controller-manager while running Kubernetes. @@ -55,7 +53,7 @@ The following controllers have cloud provider dependencies: * Node Controller: For checking the cloud provider to determine if a node has been deleted in the cloud after it stops responding * Route Controller: For setting up routes in the underlying cloud infrastructure * Service Controller: For creating, updating and deleting cloud provider load balancers - * Volume Controller: For creating, attaching, and mounting volumes, and interacting with the cloud provider to orchestrate volumes + * Volume Controller: For creating, attaching, and mounting volumes, and interacting with the cloud provider to orchestrate volumes ### kube-scheduler diff --git a/docs/concepts/overview/kubernetes-api.md b/docs/concepts/overview/kubernetes-api.md index 3de65c5bef..bd227ecc74 100644 --- a/docs/concepts/overview/kubernetes-api.md +++ b/docs/concepts/overview/kubernetes-api.md @@ -2,9 +2,6 @@ assignees: - chenopis title: The Kubernetes API -redirect_from: -- "/docs/api/" -- "/docs/api.html" --- Overall API conventions are described in the [API conventions doc](https://git.k8s.io/community/contributors/devel/api-conventions.md). diff --git a/docs/concepts/overview/what-is-kubernetes.md b/docs/concepts/overview/what-is-kubernetes.md index 370af24b38..b2246d22ef 100644 --- a/docs/concepts/overview/what-is-kubernetes.md +++ b/docs/concepts/overview/what-is-kubernetes.md @@ -3,10 +3,8 @@ assignees: - bgrant0607 - mikedanese title: What is Kubernetes? -redirect_from: -- "/docs/whatisk8s/" -- "/docs/whatisk8s.html" --- + {% capture overview %} This page is an overview of Kubernetes. {% endcapture %} @@ -19,7 +17,7 @@ With Kubernetes, you are able to quickly and efficiently respond to customer dem - Deploy your applications quickly and predictably. - Scale your applications on the fly. - Roll out new features seamlessly. - - Limit hardware usage to required resources only. + - Limit hardware usage to required resources only. Our goal is to foster an ecosystem of components and tools that relieve the burden of running applications in public and private clouds. diff --git a/docs/concepts/overview/working-with-objects/annotations.md b/docs/concepts/overview/working-with-objects/annotations.md index 031d68b2cc..2bb89e17e5 100644 --- a/docs/concepts/overview/working-with-objects/annotations.md +++ b/docs/concepts/overview/working-with-objects/annotations.md @@ -1,8 +1,5 @@ --- title: Annotations -redirect_from: -- "/docs/user-guide/annotations/" -- "/docs/user-guide/annotations.html" --- {% capture overview %} diff --git a/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/docs/concepts/overview/working-with-objects/kubernetes-objects.md index e5873ff105..62af7d59ae 100644 --- a/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -1,9 +1,5 @@ --- title: Understanding Kubernetes Objects - -redirect_from: -- "/docs/concepts/abstractions/overview/" -- "/docs/concepts/abstractions/overview.html" --- {% capture overview %} diff --git a/docs/concepts/overview/working-with-objects/labels.md b/docs/concepts/overview/working-with-objects/labels.md index 8e4019fb77..5e4a1bc617 100644 --- a/docs/concepts/overview/working-with-objects/labels.md +++ b/docs/concepts/overview/working-with-objects/labels.md @@ -2,9 +2,6 @@ assignees: - mikedanese title: Labels and Selectors -redirect_from: -- "/docs/user-guide/labels/" -- "/docs/user-guide/labels.html" --- _Labels_ are key/value pairs that are attached to objects, such as pods. @@ -60,7 +57,7 @@ An empty label selector (that is, one with zero requirements) selects every obje A null label selector (which is only possible for optional selector fields) selects no objects. -**Note**: the label selectors of two controllers must not overlap within a namespace, otherwise they will fight with each other. +**Note**: the label selectors of two controllers must not overlap within a namespace, otherwise they will fight with each other. ### _Equality-based_ requirement @@ -79,7 +76,7 @@ One could filter for resources in `production` excluding `frontend` using the co ### _Set-based_ requirement -_Set-based_ label requirements allow filtering keys according to a set of values. Three kinds of operators are supported: `in`,`notin` and exists (only the key identifier). For example: +_Set-based_ label requirements allow filtering keys according to a set of values. Three kinds of operators are supported: `in`,`notin` and `exists` (only the key identifier). For example: ``` environment in (production, qa) diff --git a/docs/concepts/overview/working-with-objects/names.md b/docs/concepts/overview/working-with-objects/names.md index a213435795..71147450fd 100644 --- a/docs/concepts/overview/working-with-objects/names.md +++ b/docs/concepts/overview/working-with-objects/names.md @@ -3,9 +3,6 @@ assignees: - mikedanese - thockin title: Names -redirect_from: -- "/docs/user-guide/identifiers/" -- "/docs/user-guide/identifiers.html" --- All objects in the Kubernetes REST API are unambiguously identified by a Name and a UID. diff --git a/docs/concepts/overview/working-with-objects/namespaces.md b/docs/concepts/overview/working-with-objects/namespaces.md index 74af64b7e8..254ff95fa2 100644 --- a/docs/concepts/overview/working-with-objects/namespaces.md +++ b/docs/concepts/overview/working-with-objects/namespaces.md @@ -4,9 +4,6 @@ assignees: - mikedanese - thockin title: Namespaces -redirect_from: -- "/docs/user-guide/namespaces/" -- "/docs/user-guide/namespaces.html" --- Kubernetes supports multiple virtual clusters backed by the same physical cluster. diff --git a/docs/concepts/policy/pod-security-policy.md b/docs/concepts/policy/pod-security-policy.md index a7ca0c8d47..91567878b4 100644 --- a/docs/concepts/policy/pod-security-policy.md +++ b/docs/concepts/policy/pod-security-policy.md @@ -2,13 +2,10 @@ assignees: - pweil- title: Pod Security Policies -redirect_from: -- "/docs/user-guide/pod-security-policy/" -- "/docs/user-guide/pod-security-policy/index.html" --- Objects of type `PodSecurityPolicy` govern the ability -to make requests on a pod that affect the `SecurityContext` that will be +to make requests on a pod that affect the `SecurityContext` that will be applied to a pod and container. See [PodSecurityPolicy proposal](https://git.k8s.io/community/contributors/design-proposals/security-context-constraints.md) for more information. @@ -18,10 +15,10 @@ See [PodSecurityPolicy proposal](https://git.k8s.io/community/contributors/desig ## What is a Pod Security Policy? -A _Pod Security Policy_ is a cluster-level resource that controls the +A _Pod Security Policy_ is a cluster-level resource that controls the actions that a pod can perform and what it has the ability to access. The -`PodSecurityPolicy` objects define a set of conditions that a pod must -run with in order to be accepted into the system. They allow an +`PodSecurityPolicy` objects define a set of conditions that a pod must +run with in order to be accepted into the system. They allow an administrator to control the following: | Control Aspect | Field Name | @@ -35,23 +32,22 @@ administrator to control the following: | The use of host ports | `hostPorts` | | The use of host's PID namespace | `hostPID` | | The use of host's IPC namespace | `hostIPC` | -| The use of host paths | [`allowedHostPaths`](#allowed-host-paths) | | The SELinux context of the container | [`seLinux`](#selinux) | | The user ID | [`runAsUser`](#runasuser) | | Configuring allowable supplemental groups | [`supplementalGroups`](#supplementalgroups) | | Allocating an FSGroup that owns the pod's volumes | [`fsGroup`](#fsgroup) | | Requiring the use of a read only root file system | `readOnlyRootFilesystem` | -_Pod Security Policies_ are comprised of settings and strategies that -control the security features a pod has access to. These settings fall +_Pod Security Policies_ are comprised of settings and strategies that +control the security features a pod has access to. These settings fall into three categories: -- *Controlled by a boolean*: Fields of this type default to the most -restrictive value. -- *Controlled by an allowable set*: Fields of this type are checked +- *Controlled by a boolean*: Fields of this type default to the most +restrictive value. +- *Controlled by an allowable set*: Fields of this type are checked against the set to ensure their value is allowed. - *Controlled by a strategy*: Items that have a strategy to provide -a mechanism to generate the value and a mechanism to ensure that a +a mechanism to generate the value and a mechanism to ensure that a specified value falls into the set of allowable values. @@ -76,22 +72,22 @@ specified. ### SupplementalGroups -- *MustRunAs* - Requires at least one range to be specified. Uses the +- *MustRunAs* - Requires at least one range to be specified. Uses the minimum value of the first range as the default. Validates against all ranges. - *RunAsAny* - No default provided. Allows any `supplementalGroups` to be specified. ### FSGroup -- *MustRunAs* - Requires at least one range to be specified. Uses the -minimum value of the first range as the default. Validates against the +- *MustRunAs* - Requires at least one range to be specified. Uses the +minimum value of the first range as the default. Validates against the first ID in the first range. - *RunAsAny* - No default provided. Allows any `fsGroup` ID to be specified. ### Controlling Volumes -The usage of specific volume types can be controlled by setting the -volumes field of the PSP. The allowable values of this field correspond +The usage of specific volume types can be controlled by setting the +volumes field of the PSP. The allowable values of this field correspond to the volume sources that are defined when creating a volume: 1. azureFile @@ -123,15 +119,12 @@ to the volume sources that are defined when creating a volume: 1. storageos 1. \* (allow all volumes) -The recommended minimum set of allowed volumes for new PSPs are +The recommended minimum set of allowed volumes for new PSPs are configMap, downwardAPI, emptyDir, persistentVolumeClaim, secret, and projected. ### Host Network - *HostPorts*, default `empty`. List of `HostPortRange`, defined by `min`(inclusive) and `max`(inclusive), which define the allowed host ports. - -### Allowed Host Paths - - *AllowedHostPaths* is a white list of allowed host path prefixes. Empty indicates that all host paths may be used. - + ## Admission _Admission control_ with `PodSecurityPolicy` allows for control over the @@ -197,7 +190,7 @@ podsecuritypolicy "permissive" deleted ## Enabling Pod Security Policies -In order to use Pod Security Policies in your cluster you must ensure the +In order to use Pod Security Policies in your cluster you must ensure the following 1. You have enabled the api type `extensions/v1beta1/podsecuritypolicy` (only for versions prior 1.6) @@ -206,6 +199,29 @@ following ## Working With RBAC -In Kubernetes 1.5 and newer, you can use PodSecurityPolicy to control access to privileged containers based on user role and groups. Access to different PodSecurityPolicy objects can be controlled via authorization. To limit access to PodSecurityPolicy objects for pods created via a Deployment, ReplicaSet, etc, the [Controller Manager](/docs/admin/kube-controller-manager/) must be run against the secured API port, and must not have superuser permissions. +In Kubernetes 1.5 and newer, you can use PodSecurityPolicy to control access to +privileged containers based on user role and groups. Access to different +PodSecurityPolicy objects can be controlled via authorization. -PodSecurityPolicy authorization uses the union of all policies available to the user creating the pod and the service account specified on the pod. When pods are created via a Deployment, ReplicaSet, etc, it is Controller Manager that creates the pod, so if it is running against the unsecured API port, all PodSecurityPolicy objects would be allowed, and you could not effectively subdivide access. Access to given PSP policies for a user will be effective only when deploying Pods directly. For more details, see the [PodSecurityPolicy RBAC example](https://git.k8s.io/kubernetes/examples/podsecuritypolicy/rbac/README.md) of applying PodSecurityPolicy to control access to privileged containers based on role and groups when deploying Pods directly. +Note that [Controller Manager](/docs/admin/kube-controller-manager/) must be run +against [the secured API port](/docs/admin/accessing-the-api/), and must not +have superuser permissions. Otherwise requests would bypass authentication and +authorization modules, all PodSecurityPolicy objects would be allowed, +and user will be able to create privileged containers. + +PodSecurityPolicy authorization uses the union of all policies available to the +user creating the pod and +[the service account specified on the pod](/docs/tasks/configure-pod-container/configure-service-account/). + +Access to given PSP policies for a user will be effective only when creating +Pods directly. + +For pods created on behalf of a user, in most cases by Controller Manager, +access should be given to the service account specified on the pod spec +template. Examples of resources that create pods on behalf of a user are +Deployments, ReplicaSets, etc. + +For more details, see the +[PodSecurityPolicy RBAC example](https://git.k8s.io/examples/staging/podsecuritypolicy/rbac/README.md) +of applying PodSecurityPolicy to control access to privileged containers based +on role and groups when deploying Pods directly. diff --git a/docs/concepts/policy/resource-quotas.md b/docs/concepts/policy/resource-quotas.md index cc2daa5c5e..d9a4f022c3 100644 --- a/docs/concepts/policy/resource-quotas.md +++ b/docs/concepts/policy/resource-quotas.md @@ -2,9 +2,6 @@ assignees: - derekwaynecarr title: Resource Quotas -redirect_from: -- "/docs/admin/resourcequota/" -- "/docs/admin/resourcequota/index.html" --- When several users or teams share a cluster with a fixed number of nodes, @@ -56,7 +53,7 @@ Resource Quota is enforced in a particular namespace when there is a ## Compute Resource Quota You can limit the total sum of [compute resources](/docs/user-guide/compute-resources) that can be requested in a given namespace. - + The following resource types are supported: | Resource Name | Description | @@ -70,7 +67,7 @@ The following resource types are supported: ## Storage Resource Quota -You can limit the total sum of [storage resources](/docs/user-guide/persistent-volumes) that can be requested in a given namespace. +You can limit the total sum of [storage resources](/docs/user-guide/persistent-volumes) that can be requested in a given namespace. In addition, you can limit consumption of storage resources based on associated storage-class. diff --git a/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md b/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md index 7247e6cd63..36252dda0c 100644 --- a/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md +++ b/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md @@ -3,9 +3,6 @@ assignees: - rickypai - thockin title: Adding entries to Pod /etc/hosts with HostAliases -redirect_from: -- "/docs/user-guide/add-entries-to-pod-etc-hosts-with-host-aliases/" -- "/docs/user-guide/add-entries-to-pod-etc-hosts-with-host-aliases.md" --- * TOC diff --git a/docs/concepts/services-networking/connect-applications-service.md b/docs/concepts/services-networking/connect-applications-service.md index b530f587fb..1d8d5e7250 100644 --- a/docs/concepts/services-networking/connect-applications-service.md +++ b/docs/concepts/services-networking/connect-applications-service.md @@ -4,9 +4,6 @@ assignees: - lavalamp - thockin title: Connecting Applications with Services -redirect_from: -- "/docs/user-guide/connecting-applications/" -- "/docs/user-guide/connecting-applications.html" --- * TOC @@ -67,7 +64,7 @@ This is equivalent to `kubectl create -f` the following yaml: {% include code.html language="yaml" file="nginx-svc.yaml" ghlink="/docs/concepts/services-networking/nginx-svc.yaml" %} -This specification will create a Service which targets TCP port 80 on any Pod with the `run: my-nginx` label, and expose it on an abstracted Service port (`targetPort`: is the port the container accepts traffic on, `port`: is the abstracted Service port, which can be any port other pods use to access the Service). View [service API object](/docs/api-reference/v1.6/#service-v1-core) to see the list of supported fields in service definition. +This specification will create a Service which targets TCP port 80 on any Pod with the `run: my-nginx` label, and expose it on an abstracted Service port (`targetPort`: is the port the container accepts traffic on, `port`: is the abstracted Service port, which can be any port other pods use to access the Service). View [service API object](/docs/api-reference/{{page.version}}/#service-v1-core) to see the list of supported fields in service definition. Check your Service: ```shell @@ -181,7 +178,7 @@ secret "nginxsecret" created $ kubectl get secrets NAME TYPE DATA AGE default-token-il9rc kubernetes.io/service-account-token 1 1d -nginxsecret Opaque 2 1m +nginxsecret Opaque 2 1m ``` Now modify your nginx replicas to start an https server using the certificate in the secret, and the Service, to expose both ports (80 and 443): diff --git a/docs/concepts/services-networking/dns-pod-service.md b/docs/concepts/services-networking/dns-pod-service.md index 3d88bb322d..4a9f817d4c 100644 --- a/docs/concepts/services-networking/dns-pod-service.md +++ b/docs/concepts/services-networking/dns-pod-service.md @@ -3,9 +3,6 @@ assignees: - davidopp - thockin title: DNS Pods and Services -redirect_from: -- "/docs/admin/dns/" -- "/docs/admin/dns.html" --- ## Introduction @@ -105,7 +102,7 @@ spec: clusterIP: None ports: - name: foo # Actually, no port is needed. - port: 1234 + port: 1234 targetPort: 1234 --- apiVersion: v1 @@ -142,7 +139,7 @@ spec: ``` 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 "busybox-1" and the subdomain set to "default-subdomain", and a headless Service named "default-subdomain" in the same namespace, the pod will see it's own FQDN as "busybox-1.default-subdomain.my-namespace.svc.cluster.local". DNS serves an A record at that name, pointing to the Pod's IP. Both pods "busybox1" and "busybox2" can have their distinct A records. +Given a Pod with the hostname set to "busybox-1" and the subdomain set to "default-subdomain", and a headless Service named "default-subdomain" in the same namespace, the pod will see it's own FQDN as "busybox-1.default-subdomain.my-namespace.svc.cluster.local". DNS serves an A record at that name, pointing to the Pod's IP. Both pods "busybox1" and "busybox2" can have their distinct A records. As of Kubernetes v1.2, the Endpoints object also has the 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. @@ -237,6 +234,29 @@ nameserver 10.0.0.10 options ndots:5 ``` +### DNS Policy + +By default, DNS policy for a pod is 'ClusterFirst'. So pods running with hostNetwork cannot resolve DNS names. To have DNS options set along with hostNetwork, you should specify DNS policy explicitly to 'ClusterFirstWithHostNet'. Update the busybox.yaml as following: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: busybox + namespace: default +spec: + containers: + - image: busybox + command: + - sleep + - "3600" + imagePullPolicy: IfNotPresent + name: busybox + restartPolicy: Always + hostNetwork: true + dnsPolicy: ClusterFirstWithHostNet +``` + #### Quick diagnosis Errors such as the following indicate a problem with the kube-dns add-on or associated Services: @@ -285,7 +305,7 @@ Use `kubectl logs` command to see logs for the DNS daemons. ``` kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c kubedns kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c dnsmasq -kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c healthz +kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c sidecar ``` See if there is any suspicious log. W, E, F letter at the beginning represent Warning, Error and Failure. Please search for entries that have these as the logging level and use [kubernetes issues](https://github.com/kubernetes/kubernetes/issues) to report unexpected errors. diff --git a/docs/concepts/services-networking/ingress.md b/docs/concepts/services-networking/ingress.md index fbd82415f5..eddb9cc08d 100644 --- a/docs/concepts/services-networking/ingress.md +++ b/docs/concepts/services-networking/ingress.md @@ -2,9 +2,6 @@ assignees: - bprashanth title: Ingress Resources -redirect_from: -- "/docs/user-guide/ingress/" -- "/docs/user-guide/ingress.html" --- * TOC diff --git a/docs/concepts/services-networking/network-policies.md b/docs/concepts/services-networking/network-policies.md index b57c04a7d0..1ea2cdfe9d 100644 --- a/docs/concepts/services-networking/network-policies.md +++ b/docs/concepts/services-networking/network-policies.md @@ -4,9 +4,6 @@ assignees: - caseydavenport - danwinship title: Network Policies -redirect_from: -- "/docs/user-guide/networkpolicies/" -- "/docs/user-guide/networkpolicies.html" --- * TOC @@ -28,7 +25,7 @@ Pods become isolated by having a NetworkPolicy that selects them. Once there is ## The `NetworkPolicy` Resource -See the [api-reference](/docs/api-reference/v1.7/#networkpolicy-v1-networking) for a full definition of the resource. +See the [api-reference](/docs/api-reference/{{page.version}}/#networkpolicy-v1-networking) for a full definition of the resource. An example `NetworkPolicy` might look like this: diff --git a/docs/concepts/services-networking/service.md b/docs/concepts/services-networking/service.md index 2536969105..24a91dd366 100644 --- a/docs/concepts/services-networking/service.md +++ b/docs/concepts/services-networking/service.md @@ -2,9 +2,6 @@ assignees: - bprashanth title: Services -redirect_from: -- "/docs/user-guide/services/" -- "/docs/user-guide/services/index.html" --- Kubernetes [`Pods`](/docs/user-guide/pods) are mortal. They are born and when they die, they @@ -319,9 +316,9 @@ Sometimes you don't need or want load-balancing and a single service IP. In this case, you can create "headless" services by specifying `"None"` for the cluster IP (`spec.clusterIP`). -This option allows developers to reduce coupling to the Kubernetes system by -allowing them freedom to do discovery their own way. Applications can still use -a self-registration pattern and adapters for other discovery systems could easily +This option allows developers to reduce coupling to the Kubernetes system by +allowing them freedom to do discovery their own way. Applications can still use +a self-registration pattern and adapters for other discovery systems could easily be built upon this API. For such `Services`, a cluster IP is not allocated, kube-proxy does not handle @@ -356,15 +353,15 @@ The default is `ClusterIP`. `Type` values and their behaviors are: - * `ClusterIP`: Exposes the service on a cluster-internal IP. Choosing this value - makes the service only reachable from within the cluster. This is the + * `ClusterIP`: Exposes the service on a cluster-internal IP. Choosing this value + makes the service only reachable from within the cluster. This is the default `ServiceType`. - * `NodePort`: Exposes the service on each Node's IP at a static port (the `NodePort`). - A `ClusterIP` service, to which the NodePort service will route, is automatically - created. You'll be able to contact the `NodePort` service, from outside the cluster, + * `NodePort`: Exposes the service on each Node's IP at a static port (the `NodePort`). + A `ClusterIP` service, to which the NodePort service will route, is automatically + created. You'll be able to contact the `NodePort` service, from outside the cluster, by requesting `:`. - * `LoadBalancer`: Exposes the service externally using a cloud provider's load balancer. - `NodePort` and `ClusterIP` services, to which the external load balancer will route, + * `LoadBalancer`: Exposes the service externally using a cloud provider's load balancer. + `NodePort` and `ClusterIP` services, to which the external load balancer will route, are automatically created. * `ExternalName`: Maps the service to the contents of the `externalName` field (e.g. `foo.bar.example.com`), by returning a `CNAME` record with its value. @@ -441,9 +438,9 @@ This can be achieved by adding the following annotations to the service based on For AWS: ```yaml [...] -metadata: +metadata: name: my-service - annotations: + annotations: service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0 [...] ``` @@ -516,7 +513,7 @@ spec: protocol: TCP port: 80 targetPort: 9376 - externalIPs: + externalIPs: - 80.11.12.10 ``` diff --git a/docs/concepts/storage/persistent-volumes.md b/docs/concepts/storage/persistent-volumes.md index ee079a19a3..e96c7380b7 100644 --- a/docs/concepts/storage/persistent-volumes.md +++ b/docs/concepts/storage/persistent-volumes.md @@ -5,9 +5,6 @@ assignees: - saad-ali - thockin title: Persistent Volumes -redirect_from: -- "/docs/user-guide/persistent-volumes/" -- "/docs/user-guide/persistent-volumes/index.html" --- This document describes the current state of `PersistentVolumes` in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested. @@ -265,7 +262,7 @@ spec: pdName: "gce-disk-1" ``` -A mount option is a string which will be cumulatively joined and used while mounting volume to the disk. +A mount option is a string which will be cumulatively joined and used while mounting volume to the disk. Note that not all Persistent volume types support mount options. In Kubernetes version 1.6, the following volume types support mount options. @@ -734,7 +731,7 @@ parameters: If storage account is not provided, all storage accounts associated with the resource group are searched to find one that matches `skuName` and `location`. If storage account is provided, it must reside in the same resource group as the cluster, and `skuName` and `location` are ignored. During provision, a secret will be created for mounting credentials. If the cluster has enabled both [RBAC](/docs/admin/authorization/rbac/) and [Controller Roles](/docs/admin/authorization/rbac/#controller-roles), you will first need to add `create` permission of resource `secret` for clusterrole `system:controller:persistent-volume-binder`. - + #### Portworx Volume ```yaml @@ -786,7 +783,7 @@ parameters: * `readOnly`: specifies the access mode to the mounted volume * `fsType`: the file system to use for the volume -The ScaleIO Kubernetes volume plugin requires a configured Secret object. +The ScaleIO Kubernetes volume plugin requires a configured Secret object. The secret must be created with type `kubernetes.io/scaleio` and use the same namespace value as that of the PVC where it is referenced as shown in the following command: diff --git a/docs/concepts/storage/volumes.md b/docs/concepts/storage/volumes.md index 27116978e3..153a22f5bf 100644 --- a/docs/concepts/storage/volumes.md +++ b/docs/concepts/storage/volumes.md @@ -5,9 +5,6 @@ assignees: - saad-ali - thockin title: Volumes -redirect_from: -- "/docs/user-guide/volumes/" -- "/docs/user-guide/volumes.html" --- {% capture overview %} @@ -42,7 +39,7 @@ A Kubernetes volume, on the other hand, has an explicit lifetime - the same as the pod that encloses it. Consequently, a volume outlives any containers that run within the Pod, and data is preserved across Container restarts. Of course, when a Pod ceases to exist, the volume will cease to exist, too. Perhaps more -importantly than this, Kubernetes supports many type of volumes, and a Pod can +importantly than this, Kubernetes supports many types of volumes, and a Pod can use any number of them simultaneously. At its core, a volume is just a directory, possibly with some data in it, which @@ -788,7 +785,7 @@ spec: Note that local PersistentVolume cleanup and deletion requires manual intervention without the external provisioner. -For details on the `local` volume type, see the [Local Persistent Storage +For details on the `local` volume type, see the [Local Persistent Storage user guide](https://github.com/kubernetes-incubator/external-storage/tree/master/local-volume) ## Using subPath diff --git a/docs/concepts/workloads/controllers/cron-jobs.md b/docs/concepts/workloads/controllers/cron-jobs.md index f50179e638..480acd3d0b 100644 --- a/docs/concepts/workloads/controllers/cron-jobs.md +++ b/docs/concepts/workloads/controllers/cron-jobs.md @@ -4,11 +4,6 @@ assignees: - soltysh - janetkuo title: Cron Jobs -redirect_from: -- "/docs/concepts/jobs/cron-jobs/" -- "/docs/concepts/jobs/cron-jobs.html" -- "/docs/user-guide/cron-jobs/" -- "/docs/user-guide/cron-jobs.html" --- * TOC diff --git a/docs/concepts/workloads/controllers/daemonset.md b/docs/concepts/workloads/controllers/daemonset.md index 8962dba065..06d4227940 100644 --- a/docs/concepts/workloads/controllers/daemonset.md +++ b/docs/concepts/workloads/controllers/daemonset.md @@ -2,9 +2,6 @@ assignees: - erictune title: Daemon Sets -redirect_from: -- "/docs/admin/daemons/" -- "/docs/admin/daemons.html" --- * TOC @@ -41,9 +38,7 @@ A DaemonSet also needs a [`.spec`](https://git.k8s.io/community/contributors/dev The `.spec.template` is the only required field of the `.spec`. -The `.spec.template` is a [pod template](/docs/user-guide/replication-controller/#pod-template). -It has exactly the same schema as a [pod](/docs/user-guide/pods), except -it is nested and does not have an `apiVersion` or `kind`. +The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [pod](docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`. In addition to required fields for a pod, a pod template in a DaemonSet has to specify appropriate labels (see [pod selector](#pod-selector)). @@ -77,7 +72,7 @@ a node for testing. If you specify a `.spec.template.spec.nodeSelector`, then the DaemonSet controller will create pods on nodes which match that [node -selector](/docs/concepts/configuration/assign-pod-node/). Likewise if you specify a `.spec.template.spec.affinity` +selector](/docs/concepts/configuration/assign-pod-node/). Likewise if you specify a `.spec.template.spec.affinity` then DaemonSet controller will create pods on nodes which match that [node affinity](/docs/concepts/configuration/assign-pod-node/). If you do not specify either, then the DaemonSet controller will create pods on all nodes. @@ -91,7 +86,7 @@ when the pod is created, so it is ignored by the scheduler). Therefore: by the DaemonSet controller. - DaemonSet controller can make pods even when the scheduler has not been started, which can help cluster bootstrap. - + Daemon pods do respect [taints and tolerations](/docs/concepts/configuration/assign-pod-node/#taints-and-tolerations-beta-feature), but they are created with `NoExecute` tolerations for the `node.alpha.kubernetes.io/notReady` and `node.alpha.kubernetes.io/unreachable` taints with no `tolerationSeconds`. This ensures that when the `TaintBasedEvictions` alpha feature is enabled, diff --git a/docs/concepts/workloads/controllers/deployment.md b/docs/concepts/workloads/controllers/deployment.md index c4ad4ecb77..7e9fbd5964 100644 --- a/docs/concepts/workloads/controllers/deployment.md +++ b/docs/concepts/workloads/controllers/deployment.md @@ -3,30 +3,31 @@ assignees: - bgrant0607 - janetkuo title: Deployments -redirect_from: -- "/docs/user-guide/deployments/" -- "/docs/user-guide/deployments.html" --- -{:toc} - -## What is a Deployment? +{% capture overview %} A _Deployment_ provides declarative updates for [Pods](/docs/concepts/workloads/pods/pod/) and [ReplicaSets](/docs/concepts/workloads/controllers/replicaset/) (the next-generation ReplicationController). -You only need to describe the desired state in a Deployment object, and the Deployment controller will -change the actual state to the desired state at a controlled rate for you. You can define Deployments to -create new ReplicaSets, or remove existing Deployments and adopt all of their resources with new Deployments. +You describe the desired state in a Deployment object, and the Deployment controller changes the actual state to the desired state at a controlled rate. You can define Deployments to +create new ReplicaSets, or remove existing Deployments and adopt all their resources with new Deployments. -**Note:** You should not manage ReplicaSets owned by a Deployment, otherwise you are racing with the Deployment -controller! All of the use cases should be covered just by manipulating the Deployment object. Consider opening -an issue in the main Kubernetes repository, if your use case is not covered below. +**Note:** You should not manage ReplicaSets owned by a Deployment. If you do so, you are racing with the Deployment +controller! All the use cases should be covered by manipulating the Deployment object. Consider opening +an issue in the main Kubernetes repository if your use case is not covered below. + +{% endcapture %} + + +{% capture body %} + +## Use Case A typical use case is: * [Create a Deployment to rollout a ReplicaSet](#creating-a-deployment). The ReplicaSet creates Pods in the background. Check the status of the rollout to see if it succeeds or not. -* Later, [declare the new state of the Pods](#updating-a-deployment) you want to run by updating the PodTemplateSpec of the Deployment. A new ReplicaSet is created and the Deployment manages moving the Pods from the old to the new ReplicaSet in a controlled rate. Each new ReplicaSet that is created, updates the revision of the Deployment. -* [Rollback to an earlier Deployment revision](#rolling-back-a-deployment) if the current state of the Deployment will not be stable. Each rollback updates the revision of the Deployment. +* [Declare the new state of the Pods](#updating-a-deployment) by updating the PodTemplateSpec of the Deployment. A new ReplicaSet is created and the Deployment manages moving the Pods from the old ReplicaSet to the new one at a controlled rate. Each new ReplicaSet updates the revision of the Deployment. +* [Rollback to an earlier Deployment revision](#rolling-back-a-deployment) if the current state of the Deployment is not stable. Each rollback updates the revision of the Deployment. * [Scale up the Deployment to facilitate more load.](#scaling-a-deployment) * [Pause the Deployment](#pausing-and-resuming-a-deployment) to apply multiple fixes to its PodTemplateSpec and then resume it to start a new rollout. * [Use the status of the Deployment](#deployment-status) as an indicator that a rollout has stuck @@ -35,7 +36,7 @@ A typical use case is: ## Creating a Deployment -Here is an example Deployment. It creates a ReplicaSet to bring up 3 nginx Pods. +Here is an example Deployment. It creates a ReplicaSet to bring up three nginx Pods. {% include code.html language="yaml" file="nginx-deployment.yaml" ghlink="/docs/concepts/workloads/controllers/nginx-deployment.yaml" %} @@ -47,7 +48,7 @@ deployment "nginx-deployment" created ``` Setting the kubectl flag `--record` to `true` allows you to record current command in the annotations of -the resources being created or updated. It will be useful for future introspection; for example, to see the +the resources being created or updated. It is useful for future introspection: for example, to see the commands executed in each Deployment revision. Then running `get` immediately will give: @@ -62,7 +63,7 @@ This indicates that the Deployment's number of desired replicas is 3 (according the number of current replicas (`.status.replicas`) is 0, the number of up-to-date replicas (`.status.updatedReplicas`) is 0, and the number of available replicas (`.status.availableReplicas`) is also 0. -To see the Deployment rollout status, simply run: +To see the Deployment rollout status, run: ```shell $ kubectl rollout status deployment/nginx-deployment @@ -70,7 +71,7 @@ Waiting for rollout to finish: 2 out of 3 new replicas have been updated... deployment "nginx-deployment" successfully rolled out ``` -Running the `get` again a few seconds later, should give: +Running the `get` again a few seconds later should give: ```shell $ kubectl get deployments @@ -98,31 +99,30 @@ nginx-deployment-2035384211-kzszj 1/1 Running 0 18s app nginx-deployment-2035384211-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=2035384211 ``` -The created ReplicaSet will ensure that there are three nginx Pods at all times. +The created ReplicaSet ensures that there are three nginx Pods at all times. **Note:** You must specify an appropriate selector and pod template labels in a Deployment (in this case, -`app = nginx`), i.e. don't overlap with other controllers (including other Deployments, ReplicaSets, -StatefulSets, etc.). Kubernetes won't stop you from doing that, and if you end up with multiple -controllers that have overlapping selectors, those controllers may fight with each other and won't behave +`app = nginx`). That is, don't overlap with other controllers (including other Deployments, ReplicaSets, +StatefulSets, etc.). Kubernetes doesn't stop you from overlapping, and if multiple +controllers have overlapping selectors, those controllers may fight with each other and won't behave correctly. ### Pod-template-hash label -**Note:** This label is not meant to be mutated by users! +**Note:** This label is not meant to be changed by users! -Note the pod-template-hash label in the example output in the pod labels above. pod-template-hash is added by the -Deployment controller in every ReplicaSet that a Deployment creates or adopts. Its purpose is so that children -ReplicaSets of a Deployment will not overlap among them. It is computed by hashing the PodTemplate of the ReplicaSet +Note the pod-template-hash label in the example output in the pod labels above. This label is added by the +Deployment controller to every ReplicaSet that a Deployment creates or adopts. Its purpose is to make sure that child +ReplicaSets of a Deployment do not overlap. It is computed by hashing the PodTemplate of the ReplicaSet and using the resulting hash as the label value that will be added in the ReplicaSet selector, pod template labels, and in any existing Pods that the ReplicaSet may have. ## Updating a Deployment -**Note:** a Deployment's rollout is triggered if and only if the Deployment's pod template (i.e. `.spec.template`) -is changed, e.g. updating labels or container images of the template. Other updates, such as scaling the Deployment, -will not trigger a rollout. +**Note:** A Deployment's rollout is triggered if and only if the Deployment's pod template (that is, `.spec.template`) +is changed, for example if the labels or container images of the template are updated. Other updates, such as scaling the Deployment, do not trigger a rollout. -Suppose that we now want to update the nginx Pods to start using the `nginx:1.9.1` image +Suppose that we now want to update the nginx Pods to use the `nginx:1.9.1` image instead of the `nginx:1.7.9` image. ```shell @@ -137,7 +137,7 @@ $ kubectl edit deployment/nginx-deployment deployment "nginx-deployment" edited ``` -To see its rollout status, simply run: +To see the rollout status, run: ```shell $ kubectl rollout status deployment/nginx-deployment @@ -247,14 +247,14 @@ It is generally discouraged to make label selector updates and it is suggested t In any case, if you need to perform a label selector update, exercise great caution and make sure you have grasped all of the implications. -* Selector additions require the pod template labels in the Deployment spec to be updated with the new label, too, +* Selector additions require the pod template labels in the Deployment spec to be updated with the new label too, otherwise a validation error is returned. This change is a non-overlapping one, meaning that the new selector does not select ReplicaSets and Pods created with the old selector, resulting in orphaning all old ReplicaSets and creating a new ReplicaSet. -* Selector updates, i.e., changing the existing value in a selector key, result in the same behavior as additions. -* Selector removals, i.e., removing an existing key from the Deployment selector, do not require any changes in the -pod template labels, no existing ReplicaSet is orphaned, and a new ReplicaSet will not be created, but note that the -removed label will still exist in any existing Pods and ReplicaSets. +* Selector updates -- that is, changing the existing value in a selector key -- result in the same behavior as additions. +* Selector removals -- that is, removing an existing key from the Deployment selector -- do not require any changes in the +pod template labels. No existing ReplicaSet is orphaned, and a new ReplicaSet is not created, but note that the +removed label still exists in any existing Pods and ReplicaSets. ## Rolling Back a Deployment @@ -263,11 +263,11 @@ By default, all of the Deployment's rollout history is kept in the system so tha (you can change that by modifyingrevision history limit]). **Note:** a Deployment's revision is created when a Deployment's rollout is triggered. This means that the -new revision is created if and only if the Deployment's pod template (i.e. `.spec.template`) is changed, -e.g. updating labels or container images of the template. Other updates, such as scaling the Deployment, -will not create a Deployment revision -- so that we can facilitate simultaneous manual- or auto-scaling. -This implies that when you rollback to an earlier revision, only the Deployment's pod template part will -be rolled back. +new revision is created if and only if the Deployment's pod template (`.spec.template`) is changed, +for example if you update the labels or container images of the template. Other updates, such as scaling the Deployment, +do not create a Deployment revision, so that we can facilitate simultaneous manual- or auto-scaling. +This means that when you roll back to an earlier revision, only the Deployment's pod template part is +rolled back. Suppose that we made a typo while updating the Deployment, by putting the image name as `nginx:1.91` instead of `nginx:1.9.1`: @@ -503,7 +503,7 @@ nginx-deployment-1989198191 7 7 0 7m nginx-deployment-618515232 11 11 11 7m ``` -## Pausing and Resuming a Deployment +## Pausing and Resuming a Deployment You can pause a Deployment before triggering one or more updates and then resume it. This will allow you to apply multiple fixes in between pausing and resuming without triggering unnecesarry rollouts. @@ -549,7 +549,7 @@ deployment "nginx" resource requirements updated ``` The initial state of the Deployment prior to pausing it will continue its function, but new updates to -the Deployment will not have any effect as long as the Deployment is paused. +the Deployment will not have any effect as long as the Deployment is paused. Eventually, resume the Deployment and observe a new ReplicaSet coming up with all the new updates: ```shell @@ -630,7 +630,7 @@ due to some of the following factors: One way you can detect this condition is to specify a deadline parameter in your Deployment spec: ([`spec.progressDeadlineSeconds`](#progress-deadline-seconds)). `spec.progressDeadlineSeconds` denotes the -number of seconds the Deployment controller waits before indicating (via the Deployment status) that the +number of seconds the Deployment controller waits before indicating (in the Deployment status) that the Deployment progress has stalled. The following `kubectl` command sets the spec with `progressDeadlineSeconds` to make the controller report @@ -754,13 +754,13 @@ to a previous revision, or even pause it if you need to apply multiple tweaks in You can set `.spec.revisionHistoryLimit` field in a Deployment to specify how many old ReplicaSets for this Deployment you want to retain. The rest will be garbage-collected in the background. By default, -all revision history will be kept. In a future version, it will default to switch to 2. +all revision history will be kept. In a future version, it will default to switch to 2. **Note:** Explicitly setting this field to 0, will result in cleaning up all the history of your Deployment thus that Deployment will not be able to roll back. -## Use Cases +## Use Cases ### Canary Deployment @@ -780,12 +780,11 @@ A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contrib The `.spec.template` is the only required field of the `.spec`. -The `.spec.template` is a [pod template](/docs/user-guide/replication-controller/#pod-template). It has exactly -the same schema as a [Pod](/docs/user-guide/pods), except it is nested and does not have an +The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [Pod](docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`. In addition to required fields for a Pod, a pod template in a Deployment must specify appropriate -labels (i.e. don't overlap with other controllers, see [selector](#selector)) and an appropriate restart policy. +labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See [selector](#selector)). Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/) equal to `Always` is allowed, which is the default if not specified. @@ -800,19 +799,19 @@ allowed, which is the default if not specified. for the Pods targeted by this deployment. If specified, `.spec.selector` must match `.spec.template.metadata.labels`, or it will be rejected by -the API. If `.spec.selector` is unspecified, `.spec.selector.matchLabels` will be defaulted to +the API. If `.spec.selector` is unspecified, `.spec.selector.matchLabels` defaults to `.spec.template.metadata.labels`. -Deployment may kill Pods whose labels match the selector, in the case that their template is different -than `.spec.template` or if the total number of such Pods exceeds `.spec.replicas`. It will bring up new -Pods with `.spec.template` if number of Pods are less than the desired number. +A Deployment may terminate Pods whose labels match the selector if their template is different +tfrom `.spec.template` or if the total number of such Pods exceeds `.spec.replicas`. It brings up new +Pods with `.spec.template` if the number of Pods is less than the desired number. -**Note:** You should not create other pods whose labels match this selector, either directly, via -another Deployment or via another controller such as ReplicaSets or ReplicationControllers. Otherwise, -the Deployment will think that those pods were created by it. Kubernetes will not stop you from doing this. +**Note:** You should not create other pods whose labels match this selector, either directly, by creating +another Deployment, or by creating another controller such as a ReplicaSet or a ReplicationController. If you +do so, the first Deployment thinks that it created these other pods. Kubernetes does not stop you from doing this. If you have multiple controllers that have overlapping selectors, the controllers will fight with each -other's and won't behave correctly. +other and won't behave correctly. ### Strategy @@ -833,10 +832,9 @@ the rolling update process. ##### Max Unavailable `.spec.strategy.rollingUpdate.maxUnavailable` is an optional field that specifies the maximum number -of Pods that can be unavailable during the update process. The value can be an absolute number (e.g. 5) -or a percentage of desired Pods (e.g. 10%). The absolute number is calculated from percentage by -rounding down. This can not be 0 if `.spec.strategy.rollingUpdate.maxSurge` is 0. By default, a -value of 25% is used. +of Pods that can be unavailable during the update process. The value can be an absolute number (for example, 5) +or a percentage of desired Pods (for example, 10%). The absolute number is calculated from percentage by +rounding down. The value cannot be 0 if `.spec.strategy.rollingUpdate.maxSurge` is 0. The default value is 25%. For example, when this value is set to 30%, the old ReplicaSet can be scaled down to 70% of desired Pods immediately when the rolling update starts. Once new Pods are ready, old ReplicaSet can be scaled @@ -846,12 +844,12 @@ at all times during the update is at least 70% of the desired Pods. ##### Max Surge `.spec.strategy.rollingUpdate.maxSurge` is an optional field that specifies the maximum number of Pods -that can be created above the desired number of Pods. Value can be an absolute number (e.g. 5) or a -percentage of desired Pods (e.g. 10%). This can not be 0 if `MaxUnavailable` is 0. The absolute number -is calculated from percentage by rounding up. By default, a value of 25% is used. +that can be created over the desired number of Pods. The value can be an absolute number (for example, 5) or a +percentage of desired Pods (for example, 10%). The value cannot be 0 if `MaxUnavailable` is 0. The absolute number +is calculated from the percentage by rounding up. The default value is 25%. For example, when this value is set to 30%, the new ReplicaSet can be scaled up immediately when the -rolling update starts, such that the total number of old and new Pods do not exceed 130% of desired +rolling update starts, such that the total number of old and new Pods does not exceed 130% of desired Pods. Once old Pods have been killed, the new ReplicaSet can be scaled up further, ensuring that the total number of Pods running at any time during the update is at most 130% of desired Pods. @@ -900,7 +898,7 @@ ReplicaSets will be kept by default, consuming resources in `etcd` and crowding if this field is not set. The configuration of each Deployment revision is stored in its ReplicaSets; therefore, once an old ReplicaSet is deleted, you lose the ability to rollback to that revision of Deployment. -More specifically, setting this field to zero means that all old ReplicaSets with 0 replica will be cleaned up. +More specifically, setting this field to zero means that all old ReplicaSets with 0 replica will be cleaned up. In this case, a new Deployment rollout cannot be undone, since its revision history is cleaned up. ### Paused @@ -917,3 +915,7 @@ it is created. [Kubectl rolling update](/docs/user-guide/kubectl/{{page.version}}/#rolling-update) updates Pods and ReplicationControllers in a similar fashion. But Deployments are recommended, since they are declarative, server side, and have additional features, such as rolling back to any previous revision even after the rolling update is done. + +{% endcapture %} + +{% include templates/concept.md %} diff --git a/docs/concepts/workloads/controllers/garbage-collection.md b/docs/concepts/workloads/controllers/garbage-collection.md index bc6686bbe0..6c9d0d8224 100644 --- a/docs/concepts/workloads/controllers/garbage-collection.md +++ b/docs/concepts/workloads/controllers/garbage-collection.md @@ -1,11 +1,5 @@ --- title: Garbage Collection -redirect_from: -- "/docs/concepts/abstractions/controllers/garbage-collection/" -- "/docs/concepts/abstractions/controllers/garbage-collection.html" -- "/docs/user-guide/garbage-collection/" -- "/docs/user-guide/garbage-collection.html" - --- {% capture overview %} @@ -70,15 +64,15 @@ metadata: When you delete an object, you can specify whether the object's dependents are also deleted automatically. Deleting dependents automatically is called *cascading -deletion*. There are two modes of *cascading deletion*: *background* and *foreground*. +deletion*. There are two modes of *cascading deletion*: *background* and *foreground*. If you delete an object without deleting its dependents -automatically, the dependents are said to be *orphaned*. +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 +In *background cascading deletion*, Kubernetes deletes the owner object +immediately and the garbage collector then deletes the dependents in the background. ### Foreground cascading deletion @@ -90,7 +84,7 @@ the following things are true: * The object is still visible via the REST API * The object's `deletionTimestamp` is set * The object's `metadata.finalizers` contains the value "foregroundDeletion". - + Once the "deletion in progress" state is set, the garbage collector deletes the object's dependents. Once the garbage collector has deleted all "blocking" dependents (objects with `ownerReference.blockOwnerDeletion=true`), it delete @@ -100,7 +94,7 @@ Note that in the "foregroundDeletion", only dependents with `ownerReference.blockOwnerDeletion` block the deletion of the owner object. Kubernetes version 1.7 will add an admission controller that controls user access to set `blockOwnerDeletion` to true based on delete permissions on the owner object, so that -unauthorized dependents cannot delay deletion of an owner object. +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. diff --git a/docs/concepts/workloads/controllers/jobs-run-to-completion.md b/docs/concepts/workloads/controllers/jobs-run-to-completion.md index 8b225969a3..91ed94ba0d 100644 --- a/docs/concepts/workloads/controllers/jobs-run-to-completion.md +++ b/docs/concepts/workloads/controllers/jobs-run-to-completion.md @@ -3,11 +3,6 @@ assignees: - erictune - soltysh title: Jobs - Run to Completion -redirect_from: -- "/docs/concepts/jobs/run-to-completion-finite-workloads/" -- "/docs/concepts/jobs/run-to-completion-finite-workloads.html" -- "/docs/user-guide/jobs/" -- "/docs/user-guide/jobs.html" --- * TOC @@ -92,9 +87,7 @@ A Job also needs a [`.spec` section](https://git.k8s.io/community/contributors/d The `.spec.template` is the only required field of the `.spec`. -The `.spec.template` is a [pod template](/docs/user-guide/replication-controller/#pod-template). It has exactly -the same schema as a [pod](/docs/user-guide/pods), except it is nested and does not have an `apiVersion` or -`kind`. +The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [pod](/docs/user-guide/pods), except it is nested and does not have an `apiVersion` or `kind`. In addition to required fields for a Pod, a pod template in a job must specify appropriate labels (see [pod selector](#pod-selector)) and an appropriate restart policy. @@ -115,12 +108,12 @@ There are three main types of jobs: - normally only one pod is started, unless the pod fails. - job is complete as soon as Pod terminates successfully. 1. Parallel Jobs with a *fixed completion count*: - - specify a non-zero positive value for `.spec.completions` + - specify a non-zero positive value for `.spec.completions`. - the job is complete when there is one successful pod for each value in the range 1 to `.spec.completions`. - **not implemented yet:** each pod passed a different index in the range 1 to `.spec.completions`. 1. Parallel Jobs with a *work queue*: - - do not specify `.spec.completions`, default to `.spec.Parallelism` - - the pods must coordinate with themselves or an external service to determine what each should work on +  - do not specify `.spec.completions`, default to `.spec.Parallelism`. +  - the pods must coordinate with themselves or an external service to determine what each should work on. - each pod is independently capable of determining whether or not all its peers are done, thus the entire Job is done. - when _any_ pod terminates with success, no new pods are created. - once at least one pod has terminated with success and all pods are terminated, then the job is completed with success. diff --git a/docs/concepts/workloads/controllers/petset.md b/docs/concepts/workloads/controllers/petset.md index 253a9639a4..00513c5973 100644 --- a/docs/concepts/workloads/controllers/petset.md +++ b/docs/concepts/workloads/controllers/petset.md @@ -8,13 +8,6 @@ assignees: - kow3ns - smarterclayton title: PetSets -redirect_from: -- "/docs/concepts/abstractions/controllers/petsets/" -- "/docs/concepts/abstractions/controllers/petsets.html" -- "/docs/user-guide/petset/bootstrapping/" -- "/docs/user-guide/petset/bootstrapping/index.html" -- "/docs/user-guide/petset/" -- "/docs/user-guide/petset.html" --- __Warning:__ Starting in Kubernetes version 1.5, PetSet has been renamed to [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets). To use (or continue to use) PetSet in Kubernetes 1.5, you _must_ [migrate](/docs/tasks/manage-stateful-set/upgrade-pet-set-to-stateful-set/) your existing PetSets to StatefulSets. For information on working with StatefulSet, see the tutorial on [how to run replicated stateful applications](/docs/tutorials/stateful-application/run-replicated-stateful-application). diff --git a/docs/concepts/workloads/controllers/replicaset.md b/docs/concepts/workloads/controllers/replicaset.md index 0a48fa16aa..84077014e1 100644 --- a/docs/concepts/workloads/controllers/replicaset.md +++ b/docs/concepts/workloads/controllers/replicaset.md @@ -4,15 +4,9 @@ assignees: - bprashanth - madhusudancs title: Replica Sets -redirect_from: -- "/docs/user-guide/replicasets/" -- "/docs/user-guide/replicasets.html" --- -* TOC -{:toc} - -## What is a ReplicaSet? +{% capture overview %} ReplicaSet is the next-generation Replication Controller. The only difference between a _ReplicaSet_ and a @@ -21,6 +15,13 @@ the selector support. ReplicaSet supports the new set-based selector requirement as described in the [labels user guide](/docs/user-guide/labels/#label-selectors) whereas a Replication Controller only supports equality-based selector requirements. +{% endcapture %} + + +{% capture body %} + +## How to use a ReplicaSet + Most [`kubectl`](/docs/user-guide/kubectl/) commands that support Replication Controllers also support ReplicaSets. One exception is the [`rolling-update`](/docs/user-guide/kubectl/{{page.version}}/#rolling-update) command. If @@ -36,16 +37,16 @@ creation, deletion and updates. When you use Deployments you don't have to worry about managing the ReplicaSets that they create. Deployments own and manage their ReplicaSets. -## When to use a ReplicaSet? +## When to use a ReplicaSet -A ReplicaSet ensures that a specified number of pod “replicas” are running at any given +A ReplicaSet ensures that a specified number of pod replicas are running at any given time. However, a Deployment is a higher-level concept that manages ReplicaSets and provides declarative updates to pods along with a lot of other useful features. Therefore, we recommend using Deployments instead of directly using ReplicaSets, unless you require custom update orchestration or don't require updates at all. This actually means that you may never need to manipulate ReplicaSet objects: -use directly a Deployment and define your application in the spec section. +use a Deployment instead, and define your application in the spec section. ## Example @@ -82,8 +83,8 @@ frontend-qhloh 1/1 Running 0 1m ## ReplicaSet as an Horizontal Pod Autoscaler target A ReplicaSet can also be a target for -[Horizontal Pod Autoscalers (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/), -i.e. a ReplicaSet can be auto-scaled by an HPA. Here is an example HPA targeting +[Horizontal Pod Autoscalers (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/). That is, +a ReplicaSet can be auto-scaled by an HPA. Here is an example HPA targeting the ReplicaSet we created in the previous example. {% include code.html language="yaml" file="hpa-rs.yaml" ghlink="/docs/concepts/workloads/controllers/hpa-rs.yaml" %} @@ -97,9 +98,13 @@ of the replicated pods. kubectl create -f hpa-rs.yaml ``` -Alternatively, you can just use the `kubectl autoscale` command to accomplish the same +Alternatively, you can use the `kubectl autoscale` command to accomplish the same (and it's easier!) ```shell kubectl autoscale rs frontend ``` + +{% endcapture %} + +{% include templates/concept.md %} diff --git a/docs/concepts/workloads/controllers/replicationcontroller.md b/docs/concepts/workloads/controllers/replicationcontroller.md index 00effd9ee1..c44c6e1f4d 100644 --- a/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/docs/concepts/workloads/controllers/replicationcontroller.md @@ -3,38 +3,42 @@ assignees: - bprashanth - janetkuo title: Replication Controller -redirect_from: -- "/docs/user-guide/replication-controller/" -- "/docs/user-guide/replication-controller/index.html" --- -* TOC -{:toc} +{% capture overview %} -## What is a ReplicationController? +NOTE: A [`Deployment`](/docs/concepts/workloads/controllers/deployment/) that configures a [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) is now the recommended way to set up replication. -A _ReplicationController_ ensures that a specified number of pod "replicas" are running at any one -time. In other words, a ReplicationController makes sure that a pod or homogeneous set of pods are +A _ReplicationController_ ensures that a specified number of pod replicas are running at any one +time. In other words, a ReplicationController makes sure that a pod or a homogeneous set of pods is always up and available. -If there are too many pods, it will kill some. If there are too few, the -ReplicationController will start more. Unlike manually created pods, the pods maintained by a -ReplicationController are automatically replaced if they fail, get deleted, or are terminated. -For example, your pods get re-created on a node after disruptive maintenance such as a kernel upgrade. -For this reason, we recommend that you use a ReplicationController even if your application requires -only a single pod. You can think of a ReplicationController as something similar to a process supervisor, -but rather than individual processes on a single node, the ReplicationController supervises multiple pods + +{% endcapture %} + + +{% capture body %} + +## How a ReplicationController Works + +If there are too many pods, the ReplicationController terminates the extra pods. If there are too few, the +ReplicationController starts more pods. Unlike manually created pods, the pods maintained by a +ReplicationController are automatically replaced if they fail, are deleted, or are terminated. +For example, your pods are re-created on a node after disruptive maintenance such as a kernel upgrade. +For this reason, you should use a ReplicationController even if your application requires +only a single pod. A ReplicationController is similar to a process supervisor, +but instead of supervising individual processes on a single node, the ReplicationController supervises multiple pods across multiple nodes. ReplicationController is often abbreviated to "rc" or "rcs" in discussion, and as a shortcut in kubectl commands. -A simple case is to create 1 ReplicationController object in order to reliably run one instance of +A simple case is to create one ReplicationController object to reliably run one instance of a Pod indefinitely. A more complex use case is to run several identical replicas of a replicated service, such as web servers. ## Running an example ReplicationController -Here is an example ReplicationController config. It runs 3 copies of the nginx web server. +This example ReplicationController config runs three copies of the nginx web server. {% include code.html language="yaml" file="replication.yaml" ghlink="/docs/concepts/workloads/controllers/replication.yaml" %} @@ -64,14 +68,14 @@ Events: 20s 20s 1 {replication-controller } Normal SuccessfulCreate Created pod: nginx-4ok8v ``` -Here, 3 pods have been made, but none are running yet, perhaps because the image is being pulled. +Here, three pods are created, but none is running yet, perhaps because the image is being pulled. A little later, the same command may show: ```shell Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed ``` -To list all the pods that belong to the rc in a machine readable form, you can use a command like this: +To list all the pods that belong to the ReplicationController in a machine readable form, you can use a command like this: ```shell $ pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name}) @@ -96,12 +100,10 @@ A ReplicationController also needs a [`.spec` section](https://git.k8s.io/commun The `.spec.template` is the only required field of the `.spec`. -The `.spec.template` is a pod template. It has exactly -the same schema as a [pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or -`kind`. +The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`. In addition to required fields for a Pod, a pod template in a ReplicationController must specify appropriate -labels (i.e. don't overlap with other controllers, see [pod selector](#pod-selector)) and an appropriate restart policy. +labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See [pod selector](#pod-selector). Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/) equal to `Always` is allowed, which is the default if not specified. @@ -113,27 +115,27 @@ for example the [Kubelet](/docs/admin/kubelet/) or Docker. The ReplicationController can itself have labels (`.metadata.labels`). Typically, you would set these the same as the `.spec.template.metadata.labels`; if `.metadata.labels` is not specified -then it is defaulted to `.spec.template.metadata.labels`. However, they are allowed to be +then it defaults to `.spec.template.metadata.labels`. However, they are allowed to be different, and the `.metadata.labels` do not affect the behavior of the ReplicationController. ### Pod Selector -The `.spec.selector` field is a [label selector](/docs/user-guide/labels/#label-selectors). A replication -controller manages all the pods with labels which match the selector. It does not distinguish -between pods which it created or deleted versus pods which some other person or process created or -deleted. This allows the ReplicationController to be replaced without affecting the running pods. +The `.spec.selector` field is a [label selector](/docs/user-guide/labels/#label-selectors). A ReplicationController +manages all the pods with labels that match the selector. It does not distinguish +between pods that it created or deleted and pods that another person or process created or +deleted. This allows the ReplicationController to be replaced without affecting the running pods. If specified, the `.spec.template.metadata.labels` must be equal to the `.spec.selector`, or it will be rejected by the API. If `.spec.selector` is unspecified, it will be defaulted to `.spec.template.metadata.labels`. -Also you should not normally create any pods whose labels match this selector, either directly, via -another ReplicationController or via another controller such as Job. Otherwise, the -ReplicationController will think that those pods were created by it. Kubernetes will not stop you +Also you should not normally create any pods whose labels match this selector, either directly, with +another ReplicationController, or with another controller such as Job. If you do so, the +ReplicationController thinks that it created the other pods. Kubernetes does not stop you from doing this. If you do end up with multiple controllers that have overlapping selectors, you -will have to manage the deletion yourself (see [below](#updating-a-replication-controller)). +will have to manage the deletion yourself (see [below](#working-with-replicationcontrollers)). ### Multiple Replicas @@ -177,7 +179,7 @@ Pods may be removed from a ReplicationController's target set by changing their ### Rescheduling -As mentioned above, whether you have 1 pod you want to keep running, or 1000, a ReplicationController will ensure that the specified number of pods exists, even in the event of node failure or pod termination (e.g., due to an action by another control agent). +As mentioned above, whether you have 1 pod you want to keep running, or 1000, a ReplicationController will ensure that the specified number of pods exists, even in the event of node failure or pod termination (for example, due to an action by another control agent). ### Scaling @@ -194,7 +196,7 @@ Ideally, the rolling update controller would take application readiness into acc The two ReplicationControllers would need to create pods with at least one differentiating label, such as the image tag of the primary container of the pod, since it is typically image updates that motivate rolling updates. Rolling update is implemented in the client tool -[`kubectl rolling-update`](/docs/user-guide/kubectl/{{page.version}}/#rolling-update). Visit [`kubectl rolling-update` task](/docs/tasks/run-application/rolling-update-replication-controller/) for more concrete examples. +[`kubectl rolling-update`](/docs/user-guide/kubectl/{{page.version}}/#rolling-update). Visit [`kubectl rolling-update` task](/docs/tasks/run-application/rolling-update-replication-controller/) for more concrete examples. ### Multiple release tracks @@ -211,13 +213,13 @@ A ReplicationController will never terminate on its own, but it isn't expected t ## Writing programs for Replication -Pods created by a ReplicationController are intended to be fungible and semantically identical, though their configurations may become heterogeneous over time. This is an obvious fit for replicated stateless servers, but ReplicationControllers can also be used to maintain availability of master-elected, sharded, and worker-pool applications. Such applications should use dynamic work assignment mechanisms, such as the [etcd lock module](https://coreos.com/docs/distributed-configuration/etcd-modules/) or [RabbitMQ work queues](https://www.rabbitmq.com/tutorials/tutorial-two-python.html), as opposed to static/one-time customization of the configuration of each pod, which is considered an anti-pattern. Any pod customization performed, such as vertical auto-sizing of resources (e.g., cpu or memory), should be performed by another online controller process, not unlike the ReplicationController itself. +Pods created by a ReplicationController are intended to be fungible and semantically identical, though their configurations may become heterogeneous over time. This is an obvious fit for replicated stateless servers, but ReplicationControllers can also be used to maintain availability of master-elected, sharded, and worker-pool applications. Such applications should use dynamic work assignment mechanisms, such as the [etcd lock module](https://coreos.com/docs/distributed-configuration/etcd-modules/) or [RabbitMQ work queues](https://www.rabbitmq.com/tutorials/tutorial-two-python.html), as opposed to static/one-time customization of the configuration of each pod, which is considered an anti-pattern. Any pod customization performed, such as vertical auto-sizing of resources (for example, cpu or memory), should be performed by another online controller process, not unlike the ReplicationController itself. ## Responsibilities of the ReplicationController The ReplicationController simply ensures that the desired number of pods matches its label selector and are operational. Currently, only terminated pods are excluded from its count. In the future, [readiness](http://issue.k8s.io/620) and other information available from the system may be taken into account, we may add more controls over the replacement policy, and we plan to emit events that could be used by external clients to implement arbitrarily sophisticated replacement and/or scale-down policies. -The ReplicationController is forever constrained to this narrow responsibility. It itself will not perform readiness nor liveness probes. Rather than performing auto-scaling, it is intended to be controlled by an external auto-scaler (as discussed in [#492](http://issue.k8s.io/492)), which would change its `replicas` field. We will not add scheduling policies (e.g., [spreading](http://issue.k8s.io/367#issuecomment-48428019)) to the ReplicationController. Nor should it verify that the pods controlled match the currently specified template, as that would obstruct auto-sizing and other automated processes. Similarly, completion deadlines, ordering dependencies, configuration expansion, and other features belong elsewhere. We even plan to factor out the mechanism for bulk pod creation ([#170](http://issue.k8s.io/170)). +The ReplicationController is forever constrained to this narrow responsibility. It itself will not perform readiness nor liveness probes. Rather than performing auto-scaling, it is intended to be controlled by an external auto-scaler (as discussed in [#492](http://issue.k8s.io/492)), which would change its `replicas` field. We will not add scheduling policies (for example, [spreading](http://issue.k8s.io/367#issuecomment-48428019)) to the ReplicationController. Nor should it verify that the pods controlled match the currently specified template, as that would obstruct auto-sizing and other automated processes. Similarly, completion deadlines, ordering dependencies, configuration expansion, and other features belong elsewhere. We even plan to factor out the mechanism for bulk pod creation ([#170](http://issue.k8s.io/170)). The ReplicationController is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run, stop, scale, rolling-update) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing ReplicationControllers, auto-scalers, services, scheduling policies, canaries, etc. @@ -240,17 +242,17 @@ Note that we recommend using Deployments instead of directly using Replica Sets, ### Deployment (Recommended) [`Deployment`](/docs/concepts/workloads/controllers/deployment/) is a higher-level API object that updates its underlying Replica Sets and their Pods -in a similar fashion as `kubectl rolling-update`. Deployments are recommended if you want this rolling update functionality, +in a similar fashion as `kubectl rolling-update`. Deployments are recommended if you want this rolling update functionality, because unlike `kubectl rolling-update`, they are declarative, server-side, and have additional features. ### Bare Pods -Unlike in the case where a user directly created pods, a ReplicationController replaces pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, we recommend that you use a ReplicationController even if your application requires only a single pod. Think of it similarly to a process supervisor, only it supervises multiple pods across multiple nodes instead of individual processes on a single node. A ReplicationController delegates local container restarts to some agent on the node (e.g., Kubelet or Docker). +Unlike in the case where a user directly created pods, a ReplicationController replaces pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, we recommend that you use a ReplicationController even if your application requires only a single pod. Think of it similarly to a process supervisor, only it supervises multiple pods across multiple nodes instead of individual processes on a single node. A ReplicationController delegates local container restarts to some agent on the node (for example, Kubelet or Docker). ### Job Use a [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) instead of a ReplicationController for pods that are expected to terminate on their own -(i.e. batch jobs). +(that is, batch jobs). ### DaemonSet @@ -262,3 +264,7 @@ safe to terminate when the machine is otherwise ready to be rebooted/shutdown. ## For more information Read [Run Stateless AP Replication Controller](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/). + +{% endcapture %} + +{% include templates/concept.md %} \ No newline at end of file diff --git a/docs/concepts/workloads/controllers/statefulset.md b/docs/concepts/workloads/controllers/statefulset.md index fa58f58b77..933e4c92f5 100644 --- a/docs/concepts/workloads/controllers/statefulset.md +++ b/docs/concepts/workloads/controllers/statefulset.md @@ -7,14 +7,11 @@ assignees: - kow3ns - smarterclayton title: StatefulSets -redirect_from: -- "/docs/concepts/abstractions/controllers/statefulsets/" -- "/docs/concepts/abstractions/controllers/statefulsets.html" --- {% capture overview %} -**StatefulSets are a beta feature in 1.7. This feature replaces the -PetSets feature from 1.4. Users of PetSets are referred to the 1.5 +**StatefulSets are a beta feature in 1.7. This feature replaces the +PetSets feature from 1.4. Users of PetSets are referred to the 1.5 [Upgrade Guide](/docs/tasks/manage-stateful-set/upgrade-pet-set-to-stateful-set/) for further information on how to upgrade existing PetSets to StatefulSets.** @@ -26,7 +23,7 @@ guarantees about the ordering of deployment and scaling. ## Using StatefulSets -StatefulSets are valuable for applications that require one or more of the +StatefulSets are valuable for applications that require one or more of the following. * Stable, unique network identifiers. @@ -36,10 +33,10 @@ following. * Ordered, automated rolling updates. In the above, stable is synonymous with persistence across Pod (re)scheduling. -If an application doesn't require any stable identifiers or ordered deployment, -deletion, or scaling, you should deploy your application with a controller that -provides a set of stateless replicas. Controllers such as -[Deployment](/docs/concepts/workloads/controllers/deployment/) or +If an application doesn't require any stable identifiers or ordered deployment, +deletion, or scaling, you should deploy your application with a controller that +provides a set of stateless replicas. Controllers such as +[Deployment](/docs/concepts/workloads/controllers/deployment/) or [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) may be better suited to your stateless needs. ## Limitations @@ -50,11 +47,11 @@ provides a set of stateless replicas. Controllers such as * StatefulSets currently require a [Headless Service](/docs/concepts/services-networking/service/#headless-services) to be responsible for the network identity of the Pods. You are responsible for creating this Service. ## Components -The example below demonstrates the components of a StatefulSet. +The example below demonstrates the components of a StatefulSet. -* A Headless Service, named nginx, is used to control the network domain. +* A Headless Service, named nginx, is used to control the network domain. * The StatefulSet, named web, has a Spec that indicates that 3 replicas of the nginx container will be launched in unique Pods. -* The volumeClaimTemplates will provide stable storage using [PersistentVolumes](/docs/concepts/storage/volumes/) provisioned by a +* The volumeClaimTemplates will provide stable storage using [PersistentVolumes](/docs/concepts/storage/volumes/) provisioned by a PersistentVolume Provisioner. ```yaml @@ -107,30 +104,30 @@ spec: ``` ## Pod Identity -StatefulSet Pods have a unique identity that is comprised of an ordinal, a -stable network identity, and stable storage. The identity sticks to the Pod, +StatefulSet Pods have a unique identity that is comprised of an ordinal, a +stable network identity, and stable storage. The identity sticks to the Pod, regardless of which node it's (re)scheduled on. ### Ordinal Index -For a StatefulSet with N replicas, each Pod in the StatefulSet will be -assigned an integer ordinal, in the range [0,N), that is unique over the Set. +For a StatefulSet with N replicas, each Pod in the StatefulSet will be +assigned an integer ordinal, in the range [0,N), that is unique over the Set. ### Stable Network ID -Each Pod in a StatefulSet derives its hostname from the name of the StatefulSet -and the ordinal of the Pod. The pattern for the constructed hostname -is `$(statefulset name)-$(ordinal)`. The example above will create three Pods +Each Pod in a StatefulSet derives its hostname from the name of the StatefulSet +and the ordinal of the Pod. The pattern for the constructed hostname +is `$(statefulset name)-$(ordinal)`. The example above will create three Pods named `web-0,web-1,web-2`. A StatefulSet can use a [Headless Service](/docs/concepts/services-networking/service/#headless-services) -to control the domain of its Pods. The domain managed by this Service takes the form: -`$(service name).$(namespace).svc.cluster.local`, where "cluster.local" -is the [cluster domain](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/dns/README.md). -As each Pod is created, it gets a matching DNS subdomain, taking the form: -`$(podname).$(governing service domain)`, where the governing service is defined +to control the domain of its Pods. The domain managed by this Service takes the form: +`$(service name).$(namespace).svc.cluster.local`, where "cluster.local" +is the [cluster domain](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/dns/README.md). +As each Pod is created, it gets a matching DNS subdomain, taking the form: +`$(podname).$(governing service domain)`, where the governing service is defined by the `serviceName` field on the StatefulSet. -Here are some examples of choices for Cluster Domain, Service name, +Here are some examples of choices for Cluster Domain, Service name, StatefulSet name, and how that affects the DNS names for the StatefulSet's Pods. Cluster Domain | Service (ns/name) | StatefulSet (ns/name) | StatefulSet Domain | Pod DNS | Pod Hostname | @@ -139,96 +136,96 @@ Cluster Domain | Service (ns/name) | StatefulSet (ns/name) | StatefulSet Domain cluster.local | foo/nginx | foo/web | nginx.foo.svc.cluster.local | web-{0..N-1}.nginx.foo.svc.cluster.local | web-{0..N-1} | kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} | -Note that Cluster Domain will be set to `cluster.local` unless +Note that Cluster Domain will be set to `cluster.local` unless [otherwise configured](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/dns/README.md). ### Stable Storage -Kubernetes creates one [PersistentVolume](/docs/concepts/storage/volumes/) for each -VolumeClaimTemplate. In the nginx example above, each Pod will receive a single PersistentVolume -with a storage class of `anything` and 1 Gib of provisioned storage. When a Pod is (re)scheduled -onto a node, its `volumeMounts` mount the PersistentVolumes associated with its -PersistentVolume Claims. Note that, the PersistentVolumes associated with the -Pods' PersistentVolume Claims are not deleted when the Pods, or StatefulSet are deleted. +Kubernetes creates one [PersistentVolume](/docs/concepts/storage/volumes/) for each +VolumeClaimTemplate. In the nginx example above, each Pod will receive a single PersistentVolume +with a storage class of `anything` and 1 Gib of provisioned storage. When a Pod is (re)scheduled +onto a node, its `volumeMounts` mount the PersistentVolumes associated with its +PersistentVolume Claims. Note that, the PersistentVolumes associated with the +Pods' PersistentVolume Claims are not deleted when the Pods, or StatefulSet are deleted. This must be done manually. ## Deployment and Scaling Guarantees -* For a StatefulSet with N replicas, when Pods are being deployed, they are created sequentially, in order from {0..N-1}. +* For a StatefulSet with N replicas, when Pods are being deployed, they are created sequentially, in order from {0..N-1}. * When Pods are being deleted, they are terminated in reverse order, from {N-1..0}. -* Before a scaling operation is applied to a Pod, all of its predecessors must be Running and Ready. +* Before a scaling operation is applied to a Pod, all of its predecessors must be Running and Ready. * Before a Pod is terminated, all of its successors must be completely shutdown. The StatefulSet should not specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. This practice is unsafe and strongly discouraged. For further explanation, please refer to [force deleting StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/). -When the nginx example above is created, three Pods will be deployed in the order -web-0, web-1, web-2. web-1 will not be deployed before web-0 is -[Running and Ready](/docs/user-guide/pod-states), and web-2 will not be deployed until -web-1 is Running and Ready. If web-0 should fail, after web-1 is Running and Ready, but before -web-2 is launched, web-2 will not be launched until web-0 is successfully relaunched and -becomes Running and Ready. +When the nginx example above is created, three Pods will be deployed in the order +web-0, web-1, web-2. web-1 will not be deployed before web-0 is +[Running and Ready](/docs/user-guide/pod-states), and web-2 will not be deployed until +web-1 is Running and Ready. If web-0 should fail, after web-1 is Running and Ready, but before +web-2 is launched, web-2 will not be launched until web-0 is successfully relaunched and +becomes Running and Ready. If a user were to scale the deployed example by patching the StatefulSet such that -`replicas=1`, web-2 would be terminated first. web-1 would not be terminated until web-2 -is fully shutdown and deleted. If web-0 were to fail after web-2 has been terminated and -is completely shutdown, but prior to web-1's termination, web-1 would not be terminated +`replicas=1`, web-2 would be terminated first. web-1 would not be terminated until web-2 +is fully shutdown and deleted. If web-0 were to fail after web-2 has been terminated and +is completely shutdown, but prior to web-1's termination, web-1 would not be terminated until web-0 is Running and Ready. ### Pod Management Policies -In Kubernetes 1.7 and later, StatefulSet allows you to relax its ordering guarantees while +In Kubernetes 1.7 and later, StatefulSet allows you to relax its ordering guarantees while preserving its uniqueness and identity guarantees via its `.spec.podManagementPolicy` field. #### OrderedReady Pod Management -`OrderedReady` pod management is the default for StatefulSets. It implements the behavior +`OrderedReady` pod management is the default for StatefulSets. It implements the behavior described [above](#deployment-and-scaling-guarantees). #### Parallel Pod Management -`Parallel` pod management tells the StatefulSet controller to launch or -terminate all Pods in parallel, and to not wait for Pods to become Running -and Ready or completely terminated prior to launching or terminating another +`Parallel` pod management tells the StatefulSet controller to launch or +terminate all Pods in parallel, and to not wait for Pods to become Running +and Ready or completely terminated prior to launching or terminating another Pod. ## Update Strategies -In Kuberentes 1.7 and later, StatefulSet's `.spec.updateStrategy` field allows you to configure -and disable automated rolling updates for containers, labels, resource request/limits, and +In Kubernetes 1.7 and later, StatefulSet's `.spec.updateStrategy` field allows you to configure +and disable automated rolling updates for containers, labels, resource request/limits, and annotations for the Pods in a StatefulSet. ### On Delete -The `OnDelete` update strategy implements the legacy (1.6 and prior) behavior. It is the default -strategy when `spec.updateStrategy` is left unspecified. When a StatefulSet's -`.spec.updateStrategy.type` is set to `OnDelete`, the StatefulSet controller will not automatically -update the Pods in a StatefulSet. Users must manually delete Pods to cause the controller to +The `OnDelete` update strategy implements the legacy (1.6 and prior) behavior. It is the default +strategy when `spec.updateStrategy` is left unspecified. When a StatefulSet's +`.spec.updateStrategy.type` is set to `OnDelete`, the StatefulSet controller will not automatically +update the Pods in a StatefulSet. Users must manually delete Pods to cause the controller to create new Pods that reflect modifications made to a StatefulSet's `.spec.template`. ### Rolling Updates -The `RollingUpdate` update strategy implements automated, rolling update for the Pods in a -StatefulSet. When a StatefulSet's `.spec.updateStrategy.type` is set to `RollingUpdate`, the -StatefulSet controller will delete and recreate each Pod in the StatefulSet. It will proceed -in the same order as Pod termination (from the largest ordinal to the smallest), updating -each Pod one at a time. It will wait until an updated Pod is Running and Ready prior to +The `RollingUpdate` update strategy implements automated, rolling update for the Pods in a +StatefulSet. When a StatefulSet's `.spec.updateStrategy.type` is set to `RollingUpdate`, the +StatefulSet controller will delete and recreate each Pod in the StatefulSet. It will proceed +in the same order as Pod termination (from the largest ordinal to the smallest), updating +each Pod one at a time. It will wait until an updated Pod is Running and Ready prior to updating its predecessor. #### Partitions -The `RollingUpdate` update strategy can be partitioned, by specifying a -`.spec.updateStrategy.rollingUpdate.partition`. If a partition is specified, all Pods with an -ordinal that is greater than or equal to the partition will be updated when the StatefulSet's -`.spec.template` is updated. All Pods with an ordinal that is less than the partition will not -be updated, and, even if they are deleted, they will be recreated at the previous version. If a -StatefulSet's `.spec.updateStrategy.rollingUpdate.partition` is greater than its `.spec.replicas`, +The `RollingUpdate` update strategy can be partitioned, by specifying a +`.spec.updateStrategy.rollingUpdate.partition`. If a partition is specified, all Pods with an +ordinal that is greater than or equal to the partition will be updated when the StatefulSet's +`.spec.template` is updated. All Pods with an ordinal that is less than the partition will not +be updated, and, even if they are deleted, they will be recreated at the previous version. If a +StatefulSet's `.spec.updateStrategy.rollingUpdate.partition` is greater than its `.spec.replicas`, updates to its `.spec.template` will not be propagated to its Pods. -In most cases you will not need to use a partition, but they are useful if you want to stage an +In most cases you will not need to use a partition, but they are useful if you want to stage an update, roll out a canary, or perform a phased roll out. {% endcapture %} {% capture whatsnext %} -* Follow an example of [deploying a stateful application](/docs/tutorials/stateful-application/basic-stateful-set). +* Follow an example of [deploying a stateful application](/docs/tutorials/stateful-application/basic-stateful-set). {% endcapture %} {% include templates/concept.md %} diff --git a/docs/concepts/workloads/pods/disruptions.md b/docs/concepts/workloads/pods/disruptions.md index 79aa38bb9f..400bea7595 100644 --- a/docs/concepts/workloads/pods/disruptions.md +++ b/docs/concepts/workloads/pods/disruptions.md @@ -4,11 +4,6 @@ assignees: - foxish - davidopp title: Disruptions -redirect_from: -- "/docs/admin/disruptions/" -- "/docs/admin/disruptions.html" -- "/docs/tasks/configure-pod-container/configure-pod-disruption-budget/" -- "/docs/tasks/administer-cluster/configure-pod-disruption-budget/" --- {% capture overview %} @@ -41,7 +36,7 @@ an application. Examples are: - eviction of a pod due to the node being [out-of-resources](/docs/tasks/administer-cluster/out-of-resource.md). Except for the out-of-resources condition, all these conditions -should be familiar to most users; they are are not specific +should be familiar to most users; they are not specific to Kubernetes. We call other cases *voluntary disruptions*. These include both @@ -102,7 +97,7 @@ voluntary disruptions. For example, a quorum-based application would like to ensure that the number of replicas running is never brought below the number needed for a quorum. A web front end might want to ensure that the number of replicas serving load never falls below a certain -percentage of the total. +percentage of the total. Cluster managers and hosting providers should use tools which respect Pod Disruption Budgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api) @@ -136,7 +131,7 @@ during application updates is configured in the controller spec. (Learn about [updating a deployment](/docs/concepts/cluster-administration/manage-deployment/#updating-your-application-without-a-service-outage).) When a pod is evicted using the eviction API, it is gracefully terminated (see -`terminationGracePeriodSeconds` in [PodSpec](/docs/resources-reference/v1.6/#podspec-v1-core).) +`terminationGracePeriodSeconds` in [PodSpec](/docs/resources-reference/{{page.version}}/#podspec-v1-core).) ## PDB Example @@ -188,9 +183,7 @@ At some point, the pods terminate, and the cluster look like this: At this point, if an impatient cluster administrator tries to drain `node-2` or `node-3`, the drain command will block, because there are only 2 available -pods for the deployment, and its PDB requires at least 2. After some time - -asses, `pod-d` becomes available. +pods for the deployment, and its PDB requires at least 2. After some time passes, `pod-d` becomes available. The cluster state now looks like this: @@ -200,14 +193,14 @@ The cluster state now looks like this: | | pod-d *available* | pod-y | Now, the cluster admin tries to drain `node-2`. -The drain command will try to evict the two pods in some order, say +The drain command will try to evict the two pods in some order, say `pod-b` first and then `pod-d`. It will succeed at evicting `pod-b`. But, when it tries to evict `pod-d`, it will be refused because that would leave only one pod available for the deployment. The deployment creates a replacement for `pod-b` called `pod-e`. However, not there are not enough resources in the cluster to schedule -`pod-e`. So, the drain then the drain will block. The cluster may end up in this +`pod-e`. So, the drain will again block. The cluster may end up in this state: | node-1 *drained* | node-2 | node-3 | *no node* | @@ -234,7 +227,7 @@ and Application Owner as separate roles with limited knowledge of each other. This separation of responsibilities may make sense in these scenarios: -- when there are many application teams sharing a Kubernetes cluster, and +- when there are many application teams sharing a Kubernetes cluster, and there is natural specialization of roles - when third-party tools or services are used to automate cluster management @@ -249,7 +242,7 @@ you may not need to use Pod Disruption Budgets. If you are a Cluster Administrator, and you need to perform a disruptive action on all the nodes in your cluster, such as a node or system software upgrade, here are some options: -- Accept downtime during the upgrade. +- Accept downtime during the upgrade. - Fail over to another complete replica cluster. - No downtime, but may be costly both for the duplicated nodes, and for human effort to orchestrate the switchover. @@ -270,7 +263,7 @@ the nodes in your cluster, such as a node or system software upgrade, here are s * Learn more about [draining nodes](/docs/tasks/administer-cluster//safely-drain-node.md) -{% endcapture %} +{% endcapture %} {% include templates/concept.md %} diff --git a/docs/concepts/workloads/pods/init-containers.md b/docs/concepts/workloads/pods/init-containers.md index 50dfe247b2..6cac2b0532 100644 --- a/docs/concepts/workloads/pods/init-containers.md +++ b/docs/concepts/workloads/pods/init-containers.md @@ -2,11 +2,6 @@ assignees: - erictune title: Init Containers -redirect_from: -- "/docs/concepts/abstractions/init-containers/" -- "/docs/concepts/abstractions/init-containers.html" -- "/docs/user-guide/pods/init-container/" -- "/docs/user-guide/pods/init-container.html" --- {% capture overview %} @@ -36,7 +31,7 @@ Init Containers are exactly like regular Containers, except: If an Init Container fails for a Pod, Kubernetes restarts the Pod repeatedly until the Init Container succeeds. However, if the Pod has a `restartPolicy` of Never, it is not restarted. -To specify a Container as an Init Container, add the `initContainers` field on the PodSpec as a JSON array of objects of type [v1.Container](/docs/api-reference/v1.6/#container-v1-core) alongside the app `containers` array. +To specify a Container as an Init Container, add the `initContainers` field on the PodSpec as a JSON array of objects of type [v1.Container](/docs/api-reference/{{page.version}}/#container-v1-core) alongside the app `containers` array. The status of the init containers is returned in `status.initContainerStatuses` field as an array of the container statuses (similar to the `status.containerStatuses` field). @@ -185,7 +180,7 @@ pod "myapp-pod" created $ kubectl get -f myapp.yaml NAME READY STATUS RESTARTS AGE myapp-pod 0/1 Init:0/2 0 6m -$ kubectl describe -f myapp.yaml +$ kubectl describe -f myapp.yaml Name: myapp-pod Namespace: default [...] diff --git a/docs/concepts/workloads/pods/pod-lifecycle.md b/docs/concepts/workloads/pods/pod-lifecycle.md index ea478e377d..01986e993f 100644 --- a/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/docs/concepts/workloads/pods/pod-lifecycle.md @@ -1,8 +1,5 @@ --- title: Pod Lifecycle -redirect_from: -- "/docs/user-guide/pod-states/" -- "/docs/user-guide/pod-states.html" --- {% capture overview %} @@ -20,7 +17,7 @@ This page describes the lifecycle of a Pod. ## Pod phase A Pod's `status` field is a -[PodStatus](/docs/resources-reference/v1.6/#podstatus-v1-core) +[PodStatus](/docs/resources-reference/{{page.version}}/#podstatus-v1-core) object, which has a `phase` field. The phase of a Pod is a simple, high-level summary of where the Pod is in its @@ -55,7 +52,7 @@ Here are the possible values for `phase`: ## Pod conditions A Pod has a PodStatus, which has an array of -[PodConditions](/docs/resources-reference/v1.6/#podcondition-v1-core). Each element +[PodConditions](/docs/resources-reference/{{page.version}}/#podcondition-v1-core). Each element of the PodCondition array has a `type` field and a `status` field. The `type` field is a string, with possible values PodScheduled, Ready, Initialized, and Unschedulable. The `status` field is a string, with possible values True, False, @@ -63,22 +60,22 @@ and Unknown. ## Container probes -A [Probe](/docs/resources-reference/v1.6/#probe-v1-core) is a diagnostic +A [Probe](/docs/resources-reference/{{page.version}}/#probe-v1-core) is a diagnostic performed periodically by the [kubelet](/docs/admin/kubelet/) on a Container. To perform a diagnostic, the kubelet calls a [Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler) implemented by the Container. There are three types of handlers: -* [ExecAction](/docs/resources-reference/v1.6/#execaction-v1-core): +* [ExecAction](/docs/resources-reference/{{page.version}}/#execaction-v1-core): Executes a specified command inside the Container. The diagnostic is considered successful if the command exits with a status code of 0. -* [TCPSocketAction](/docs/resources-reference/v1.6/#tcpsocketaction-v1-core): +* [TCPSocketAction](/docs/resources-reference/{{page.version}}/#tcpsocketaction-v1-core): Performs a TCP check against the Container's IP address on a specified port. The diagnostic is considered successful if the port is open. -* [HTTPGetAction](/docs/resources-reference/v1.6/#httpgetaction-v1-core): +* [HTTPGetAction](/docs/resources-reference/{{page.version}}/#httpgetaction-v1-core): Performs an HTTP Get request against the Container's IP address on a specified port and path. The diagnostic is considered successful if the response has a status code greater than or equal to 200 and less than 400. @@ -132,11 +129,11 @@ to stop. ## Pod and Container status For detailed information about Pod Container status, see -[PodStatus](/docs/resources-reference/v1.6/#podstatus-v1-core) +[PodStatus](/docs/resources-reference/{{page.version}}/#podstatus-v1-core) and -[ContainerStatus](/docs/resources-reference/v1.6/#containerstatus-v1-core). +[ContainerStatus](/docs/resources-reference/{{page.version}}/#containerstatus-v1-core). Note that the information reported as Pod status depends on the current -[ContainerState](/docs/resources-reference/v1.6/#containerstatus-v1-core). +[ContainerState](/docs/resources-reference/{{page.version}}/#containerstatus-v1-core). ## Restart policy diff --git a/docs/concepts/workloads/pods/pod-overview.md b/docs/concepts/workloads/pods/pod-overview.md index 73bc80c17c..7256868552 100644 --- a/docs/concepts/workloads/pods/pod-overview.md +++ b/docs/concepts/workloads/pods/pod-overview.md @@ -2,11 +2,6 @@ assignees: - erictune title: Pod Overview -redirect_from: -- "/docs/concepts/abstractions/pod/" -- "/docs/concepts/abstractions/pod.html" -- "/docs/user-guide/pod-templates/" -- "/docs/user-guide/pod-templates.html" --- {% capture overview %} @@ -64,7 +59,7 @@ Pods do not, by themselves, self-heal. If a Pod is scheduled to a Node that fail ### Pods and Controllers -A Controller can create and manage multiple Pods for you, handling replication and rollout and providing self-healing capabilities at cluster scope. For example, if a Node fails, the Controller might automatically replace the Pod by scheduling an identical replacement on a different Node. +A Controller can create and manage multiple Pods for you, handling replication and rollout and providing self-healing capabilities at cluster scope. For example, if a Node fails, the Controller might automatically replace the Pod by scheduling an identical replacement on a different Node. Some examples of Controllers that contain one or more pods include: diff --git a/docs/concepts/workloads/pods/pod.md b/docs/concepts/workloads/pods/pod.md index 17decef946..ac20c50175 100644 --- a/docs/concepts/workloads/pods/pod.md +++ b/docs/concepts/workloads/pods/pod.md @@ -1,9 +1,6 @@ --- assignees: title: Pods -redirect_from: -- "/docs/user-guide/pods/index/" -- "/docs/user-guide/pods/index.html" --- * TOC @@ -153,7 +150,7 @@ Pod is exposed as a primitive in order to facilitate: * clean composition of Kubelet-level functionality with cluster-level functionality — Kubelet is effectively the "pod controller" * high-availability applications, which will expect pods to be replaced in advance of their termination and certainly in advance of deletion, such as in the case of planned evictions, image prefetching, or live pod migration [#3949](http://issue.k8s.io/3949) -There is new first-class support for stateful pods with the [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/) controller (currently in beta). The feature was alpha in 1.4 and was called [PetSet](/docs/concepts/workloads/controllers/petset/). For prior versions of Kubernetes, best practice for having stateful pods is to create a replication controller with `replicas` equal to `1` and a corresponding service, see [this MySQL deployment example](/docs/tutorials/stateful-application/run-stateful-application/). +There is new first-class support for stateful pods with the [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/) controller (currently in beta). The feature was alpha in 1.4 and was called [PetSet](/docs/concepts/workloads/controllers/petset/). For prior versions of Kubernetes, best practice for having stateful pods is to create a replication controller with `replicas` equal to `1` and a corresponding service, see [this MySQL deployment example](/docs/tutorials/stateful-application/run-stateful-application/). ## Termination of Pods @@ -196,4 +193,4 @@ spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true' Pod is a top-level resource in the Kubernetes REST API. More details about the API object can be found at: [Pod API -object](/docs/api-reference/v1.6/#pod-v1-core). +object](/docs/api-reference/{{page.version}}/#pod-v1-core). diff --git a/docs/getting-started-guides/clc.md b/docs/getting-started-guides/clc.md index 4a1eada797..e1be3568c8 100644 --- a/docs/getting-started-guides/clc.md +++ b/docs/getting-started-guides/clc.md @@ -252,7 +252,7 @@ kubectl cluster-info ### Accessing the cluster programmatically -It's possible to use the locally stored client certificates to access the api server. For example, you may want to use any of the [Kubernetes API client libraries](https://git.k8s.io/community/contributors/devel/client-libraries.md) to program against your Kubernetes cluster in the programming language of your choice. +It's possible to use the locally stored client certificates to access the api server. For example, you may want to use any of the [Kubernetes API client libraries](/docs/reference/client-libraries/) to program against your Kubernetes cluster in the programming language of your choice. To demonstrate how to use these locally stored certificates, we provide the following example of using ```curl``` to communicate to the master api server via https: diff --git a/docs/getting-started-guides/fedora/fedora_ansible_config.md b/docs/getting-started-guides/fedora/fedora_ansible_config.md index 363497942b..2b09d6b870 100644 --- a/docs/getting-started-guides/fedora/fedora_ansible_config.md +++ b/docs/getting-started-guides/fedora/fedora_ansible_config.md @@ -65,11 +65,11 @@ 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... +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/inventory/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 +edit: ~/contrib/ansible/inventory/group_vars/all.yml ```yaml ansible_ssh_user: root @@ -95,10 +95,10 @@ 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. +Although the default value of variables in `~/contrib/ansible/inventory/group_vars/all.yml` should be good enough, if not, change them as needed. ```conf -edit: ~/contrib/ansible/group_vars/all.yml +edit: ~/contrib/ansible/inventory/group_vars/all.yml ``` **Configure access to Kubernetes packages** diff --git a/docs/getting-started-guides/scratch.md b/docs/getting-started-guides/scratch.md index ffe52a3708..21da67226a 100644 --- a/docs/getting-started-guides/scratch.md +++ b/docs/getting-started-guides/scratch.md @@ -444,14 +444,29 @@ because of how this is used later. - Alternate, manual approach: 1. Set `--configure-cbr0=false` on kubelet and restart. - 1. Create a bridge - - `ip link add name cbr0 type bridge`. + 1. Create a bridge. + + ``` + ip link add name cbr0 type bridge + ``` + 1. Set appropriate MTU. NOTE: the actual value of MTU will depend on your network environment - - `ip link set dev cbr0 mtu 1460` + + ``` + ip link set dev cbr0 mtu 1460 + ``` + 1. Add the node's network to the bridge (docker will go on other side of bridge). - - `ip addr add $NODE_X_BRIDGE_ADDR dev cbr0` + + ``` + ip addr add $NODE_X_BRIDGE_ADDR dev cbr0 + ``` + 1. Turn it on - - `ip link set dev cbr0 up` + + ``` + ip link set dev cbr0 up + ``` If you have turned off Docker's IP masquerading to allow pods to talk to each other, then you may need to do masquerading just for destination IPs outside @@ -501,11 +516,13 @@ all configured and managed *by Kubernetes*: You will need to run one or more instances of etcd. - - Recommended approach: run one etcd instance, with its log written to a directory backed + - Highly available and easy to restore - Run 3 or 5 etcd instances with, their logs written to a directory backed by durable storage (RAID, GCE PD) - - Alternative: run 3 or 5 etcd instances. - - Log can be written to non-durable storage because storage is replicated. - - run a single apiserver which connects to one of the etcd nodes. + - Not highly available, but easy to restore - Run one etcd instance, with its log written to a directory backed + by durable storage (RAID, GCE PD) + **Note:** May result in operations outages in case of instance outage + - Highly available - Run 3 or 5 etcd instances with non durable storage. + **Note:** Log can be written to non-durable storage because storage is replicated. See [cluster-troubleshooting](/docs/admin/cluster-troubleshooting) for more discussion on factors affecting cluster availability. diff --git a/docs/getting-started-guides/ubuntu/index.md b/docs/getting-started-guides/ubuntu/index.md index ba50e5dd81..e732c75d0a 100644 --- a/docs/getting-started-guides/ubuntu/index.md +++ b/docs/getting-started-guides/ubuntu/index.md @@ -1,12 +1,9 @@ --- title: Kubernetes on Ubuntu -redirect_from: -- "/docs/getting-started-guides/ubuntu/calico/" -- "/docs/getting-started-guides/ubuntu/calico.html" --- {% capture overview %} -There are multiple ways to run a Kubernetes cluster with Ubuntu. These pages explain how to deploy Kubernetes on Ubuntu on multiple public and private clouds, as well as bare metal. +There are multiple ways to run a Kubernetes cluster with Ubuntu. These pages explain how to deploy Kubernetes on Ubuntu on multiple public and private clouds, as well as bare metal. {% endcapture %} {% capture body %} @@ -20,7 +17,7 @@ Supports AWS, GCE, Azure, Joyent, OpenStack, VMWare, Bare Metal and localhost de [conjure-up](http://conjure-up.io/) provides the quickest way to deploy Kubernetes on Ubuntu for multiple clouds and bare metal. It provides a user-friendly UI that prompts you for cloud credentials and configuration options -Available for Ubuntu 16.04 and newer: +Available for Ubuntu 16.04 and newer: ``` sudo snap install conjure-up --classic @@ -37,7 +34,7 @@ conjure-up kubernetes ### Operational Guides -These are more in-depth guides for users choosing to run Kubernetes in production: +These are more in-depth guides for users choosing to run Kubernetes in production: - [Installation](/docs/getting-started-guides/ubuntu/installation) - [Validation](/docs/getting-started-guides/ubuntu/validation) diff --git a/docs/getting-started-guides/vsphere.md b/docs/getting-started-guides/vsphere.md index 635aceb3d6..6cd0c87e71 100644 --- a/docs/getting-started-guides/vsphere.md +++ b/docs/getting-started-guides/vsphere.md @@ -10,7 +10,7 @@ This page covers how to get started with deploying Kubernetes on vSphere and det * TOC {:toc} -### Getting started with vSphere +### Getting started with the vSphere Cloud Provider Kubernetes comes with a cloud provider for vSphere. A quick and easy way to try out the cloud provider is to deploy Kubernetes using [Kubernetes-Anywhere](https://github.com/kubernetes/kubernetes-anywhere). @@ -20,7 +20,7 @@ This page also describes how to configure and get started with the cloud provide To start using Kubernetes on top of vSphere and use the vSphere Cloud Provider use Kubernetes-Anywhere. Kubernetes-Anywhere will deploy and configure a cluster from scratch. -Detailed steps can be found at the [getting started with Kubernetes-Anywhere on vSphere page](https://git.k8s.io/kubernetes-anywhere/phase1/vsphere/README.md) +Detailed steps can be found at the [getting started with Kubernetes-Anywhere on vSphere](https://git.k8s.io/kubernetes-anywhere/phase1/vsphere/README.md) page ### vSphere Cloud Provider @@ -31,219 +31,178 @@ vSphere Cloud Provider allows using vSphere managed storage within Kubernetes. I 3. Storage Classes and provisioning of volumes. 4. vSphere Storage Policy Based Management for Containers orchestrated by Kubernetes. -Documentation for how to use vSphere managed storage can be found in the -[persistent volumes user -guide](/docs/concepts/storage/persistent-volumes/#vsphere) and the -[volumes user -guide](/docs/concepts/storage/volumes/#vspherevolume) +Documentation for how to use vSphere managed storage can be found in the [persistent volumes user guide](/docs/concepts/storage/persistent-volumes/#vsphere) and the [volumes user guide](/docs/concepts/storage/volumes/#vspherevolume) -Examples can be found -[here](https://git.k8s.io/kubernetes/examples/volumes/vsphere) +Examples can be found [here](https://git.k8s.io/kubernetes/examples/volumes/vsphere) -#### Configuring vSphere Cloud Provider +#### Enable vSphere Cloud Provider -If a Kubernetes cluster has not been deployed using Kubernetes-Anywhere, follow the instructions below to use the vSphere Cloud Provider. These steps are not needed when using Kubernetes-Anywhere, they will be done as part of the deployment. +If a Kubernetes cluster has not been deployed using Kubernetes-Anywhere, follow the instructions below to enable the vSphere Cloud Provider. These steps are not needed when using Kubernetes-Anywhere, they will be done as part of the deployment. -* Enable UUID for a VM +**Step-1** [Create a VM folder](https://docs.vmware.com/en/VMware-vSphere/6.0/com.vmware.vsphere.vcenterhost.doc/GUID-031BDB12-D3B2-4E2D-80E6-604F304B4D0C.html) and move Kubernetes Node VMs to this folder. -This can be done via [govc tool](https://github.com/vmware/govmomi/tree/master/govc) +**Step-2** Make sure Node VM names must comply with the regex `[a-z](([-0-9a-z]+)?[0-9a-z])?(\.[a-z0-9](([-0-9a-z]+)?[0-9a-z])?)*` If Node VMs does not comply with this regex, rename them and make it compliant to this regex. -``` -export GOVC_URL= -export GOVC_USERNAME= -export GOVC_PASSWORD= -export GOVC_INSECURE=1 -govc vm.change -e="disk.enableUUID=1" -vm= -``` + Node VM names constraints: -* Create Role and User with Required Privileges for vSphere Cloud Provider + * VM names can not begin with numbers. + * VM names can not have capital letters, any special charaters except `.` and `-`. + * VM names can not be shorter than 3 chars and longer than 63 -vSphere Cloud Provider requires the following minimal set of privileges to interact with vCenter: +**Step-3** Enable disk UUID on Node virtual machines -Please refer [vSphere Documentation Center](http://pubs.vmware.com/vsphere-65/index.jsp?topic=%2Fcom.vmware.vsphere.security.doc%2FGUID-18071E9A-EED1-4968-8D51-E0B4F526FDA3.html&resultof=%22%43%72%65%61%74%65%22%20%22%63%72%65%61%74%22%20%22%43%75%73%74%6f%6d%22%20%22%63%75%73%74%6f%6d%22%20%22%52%6f%6c%65%22%20%22%72%6f%6c%65%22%20) to know about steps for creating a Custom Role, User and Role Assignment. +The disk.EnableUUID parameter must be set to "TRUE" for each Node VM. This step is necessary so that the VMDK always presents a consistent UUID to the VM, thus allowing the disk to be mounted properly. -Note: Assign Permissions at the vCenter Level and make sure to check Propagate. +For each of the virtual machine nodes that will be participating in the cluster, follow the steps below using [GOVC tool](https://github.com/vmware/govmomi/tree/master/govc) -``` -Datastore > Allocate space -Datastore > Low level file Operations -Virtual Machine > Configuration > Add existing disk -Virtual Machine > Configuration > Add or remove device -Virtual Machine > Configuration > Remove disk -``` +* Set up GOVC environment -For the VSAN policy based volume provisioning feature, the following additional privileges are required. + export GOVC_URL='vCenter IP OR FQDN' + export GOVC_USERNAME='vCenter User' + export GOVC_PASSWORD='vCenter Password' + export GOVC_INSECURE=1 -``` -Network > Assign network -Virtual machine > Configuration > Add new disk -Virtual Machine > Inventory > Create new -Virtual machine > Configuration > Add new disk -Resource > Assign virtual machine to resource pool -``` +* Find Node VM Paths -* Provide the cloud config file to each instance of kubelet, apiserver and controller manager via ```--cloud-config=``` flag. Cloud config [template can be found at Kubernetes-Anywhere](https://git.k8s.io/kubernetes-anywhere/phase1/vsphere/vsphere.conf) + govc ls /datacenter/vm/ -Sample Config: +* Set disk.EnableUUID to true for all VMs + + govc vm.change -e="disk.enableUUID=1" -vm='VM Path' + +Note: If Kubernetes Node VMs are created from template VM then `disk.EnableUUID=1` can be set on the template VM. VMs cloned from this template, will automatically inherit this property. + +**Step-4** Create and assign Roles to the vSphere Cloud Provider user and vSphere entities. + +Note: if you want to use Administrator account then this step can be skipped. + +vSphere Cloud Provider requires the following minimal set of privileges to interact with vCenter. Please refer [vSphere Documentation Center](https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-18071E9A-EED1-4968-8D51-E0B4F526FDA3.html) to know about steps for creating a Custom Role, User and Role Assignment. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
RolesPrivilegesEntitiesPropagate to Children
manage-k8s-node-vmsResource.AssignVMToPool
System.Anonymous
System.Read
System.View
VirtualMachine.Config.AddExistingDisk
VirtualMachine.Config.AddNewDisk
VirtualMachine.Config.AddRemoveDevice
VirtualMachine.Config.RemoveDisk
VirtualMachine.Inventory.Create
VirtualMachine.Inventory.Delete		Cluster,
Hosts,
VM Folder		Yes
manage-k8s-volumesDatastore.AllocateSpace
Datastore.FileManagement
System.Anonymous
System.Read
System.View		DatastoreNo
k8s-system-read-and-spbm-profile-viewStorageProfile.View
System.Anonymous
System.Read
System.View		vCenterNo
ReadOnlySystem.Anonymous
System.Read
System.View		Datacenter,
Datastore Cluster,
Datastore Storage Folder		No
+ +**Step-5** Create the vSphere cloud config file (`vsphere.conf`). Cloud config template can be found [here](https://github.com/kubernetes/kubernetes-anywhere/blob/master/phase1/vsphere/vsphere.conf) + +This config file needs to be placed in the shared directory which should be accessible from kubelet container, controller-manager pod, and API server pod. + +**```vsphere.conf``` for Master Node:** ``` [Global] - user = - password = - server = - port = - insecure-flag = - datacenter = - datastore = - working-dir = - vm-uuid = + user = "vCenter username for cloud provider" + password = "password" + server = "IP/FQDN for vCenter" + port = "443" #Optional + insecure-flag = "1" #set to 1 if the vCenter uses a self-signed cert + datacenter = "Datacenter name" + datastore = "Datastore name" #Datastore to use for provisioning volumes using storage classes/dynamic provisioning + working-dir = "vCenter VM folder path in which node VMs are located" + vm-name = "VM name of the Master Node" #Optional + vm-uuid = "UUID of the Node VM" # Optional [Disk] scsicontrollertype = pvscsi ``` -* Set the cloud provider via ```--cloud-provider=vsphere``` flag for each instance of kubelet, apiserver and controller manager. +Note: **```vm-name``` parameter is introduced in 1.6.4 release.** Both ```vm-uuid``` and ```vm-name``` are optional parameters. if ```vm-name``` is specified then ```vm-uuid``` is not used. if both are not specified then kubelet will get vm-uuid from `/sys/class/dmi/id/product_serial` and query vCenter to find the Node VM's name. -* When upgrading to 1.6 install the default storage class addons, [click here for more details](https://github.com/kubernetes/kubernetes/issues/40070) +**```vsphere.conf``` for Worker Nodes:** (Only Applicable to 1.6.4 release and above. For older releases this file should have all the parameters specified in Master node's ```vSphere.conf``` file) + +``` +[Global] + vm-name = "VM name of the Worker Node" +``` + +Below is summary of supported parameters in the `vsphere.conf` file + +* ```user``` is the vCenter username for vSphere Cloud Provider. +* ```password``` is the password for vCenter user specified with `user`. +* ```server``` is the vCenter Server IP or FQDN +* ```port``` is the vCenter Server Port. Default is 443 if not specified. +* ```insecure-flag``` is set to 1 if vCenter used a self-signed certificate. +* ```datacenter``` is the name of the datacenter on which Node VMs are deployed. +* ```datastore``` is the default datastore to use for provisioning volumes using storage classes/dynamic provisioning. +* ```vm-name``` is recently added configuration parameter. This is optional parameter. When this parameter is present, ```vsphere.conf``` file on the worker node does not need vCenter credentials. + + **Note:** ```vm-name``` is added in the release 1.6.4. Prior releases does not support this parameter. + +* ```working-dir``` can be set to empty ( working-dir = ""), if Node VMs are located in the root VM folder. +* ```vm-uuid``` is the VM Instance UUID of virtual machine. ```vm-uuid``` can be set to empty (```vm-uuid = ""```). if set to empty, this will be retrieved from /sys/class/dmi/id/product_serial file on virtual machine (requires root access). + + * ```vm-uuid``` needs to be set in this format - ```423D7ADC-F7A9-F629-8454-CE9615C810F1``` + + * ```vm-uuid``` can be retrieved from Node Virtual machines using following command. This will be different on each node VM. + + cat /sys/class/dmi/id/product_serial | sed -e 's/^VMware-//' -e 's/-/ /' | awk '{ print toupper($1$2$3$4 "-" $5$6 "-" $7$8 "-" $9$10 "-" $11$12$13$14$15$16) }' + +* `datastore` is the default datastore used for provisioning volumes using storage classes. If datastore is located in storage folder or datastore is member of datastore cluster, make sure to specify full datastore path. Make sure vSphere Cloud Provider user has Read Privilege set on the datastore cluster or storage folder to be able to find datastore. + * For datastore located in the datastore cluster, specify datastore as mentioned below + + datastore = "DatastoreCluster/datastore1" + + * For datastore located in the storage folder, specify datastore as mentioned below + + datastore = "DatastoreStorageFolder/datastore1" + +**Step-6** Add flags to controller-manager, API server and Kubelet to enable vSphere Cloud Provider. +* Add following flags to kubelet running on every node and to the controller-manager and API server pods manifest files. + +``` +--cloud-provider=vsphere +--cloud-config= +``` + +Manifest files for API server and controller-manager are generally located at `/etc/kubernetes` + +**Step-7** Restart Kubelet on all nodes. +* Reload kubelet systemd unit file using ```systemctl daemon-reload``` +* Restart kubelet service using ```systemctl restart kubelet.service``` + +Note: After enabling the vSphere Cloud Provider, Node names will be set to the VM names from the vCenter Inventory. #### Known issues - -### Kube-up (Deprecated) - -Kube-up.sh is no longer supported and is deprecated. The steps for kube-up are included but going forward [kube-anywhere](https://github.com/kubernetes/kubernetes-anywhere) is preferred. - -The recommended version for kube-up is [v1.4.7](https://github.com/kubernetes/kubernetes/releases/tag/v1.4.7) - -The example below creates a Kubernetes cluster with 4 worker node Virtual. -Machines and a master Virtual Machine (i.e. 5 VMs in your cluster). This cluster is set up and controlled from your workstation (or wherever you find convenient). - -#### Prerequisites - -* You need administrator credentials to an ESXi machine or vCenter instance with write mode api access enabled (not available on the free ESXi license). -* You must have Go (see [here](https://git.k8s.io/community/contributors/devel/development.md#go-versions) for supported versions) installed: [www.golang.org](http://www.golang.org). -* You must have your `GOPATH` set up and include `$GOPATH/bin` in your `PATH`. - -```shell -export GOPATH=$HOME/src/go -mkdir -p $GOPATH -export PATH=$PATH:$GOPATH/bin -``` - -* Install the govc tool to interact with ESXi/vCenter. Head to [govc Releases](https://github.com/vmware/govmomi/releases) to download the latest. - -```shell -# Sample commands for v0.8.0 for 64 bit Linux. -curl -OL https://github.com/vmware/govmomi/releases/download/v0.8.0/govc_linux_amd64.gz -gzip -d govc_linux_amd64.gz -chmod +x govc_linux_amd64 -mv govc_linux_amd64 /usr/local/bin/govc -``` - -* Get or build a [binary release](/docs/getting-started-guides/binary_release) - -#### Setup - -Download a prebuilt Debian 8.2 VMDK that we'll use as a base image: - -```shell -curl --remote-name-all https://storage.googleapis.com/govmomi/vmdk/2016-01-08/kube.vmdk.gz{,.md5} -md5sum -c kube.vmdk.gz.md5 -gzip -d kube.vmdk.gz -``` - -Configure the environment for govc - -```shell -export GOVC_URL='hostname' # hostname of the vc -export GOVC_USERNAME='username' # username for logging into the vsphere. -export GOVC_PASSWORD='password' # password for the above username -export GOVC_NETWORK='Network Name' # Name of the network the vms should join. Many times it could be "VM Network" -export GOVC_INSECURE=1 # If the host above uses a self-signed cert -export GOVC_DATASTORE='target datastore' -# To get resource pool via govc: govc ls -l 'host/*' | grep ResourcePool | awk '{print $1}' | xargs -n1 -t govc pool.info -export GOVC_RESOURCE_POOL='resource pool or cluster with access to datastore' -export GOVC_GUEST_LOGIN='kube:kube' # Used for logging into kube.vmdk during deployment. -export GOVC_PORT=443 # The port to be used by vSphere cloud provider plugin -# To get datacente via govc: govc datacenter.info -export GOVC_DATACENTER='ha-datacenter' # The datacenter to be used by vSphere cloud provider plugin -``` - -Sample environment - -```shell -export GOVC_URL='10.161.236.217' -export GOVC_USERNAME='administrator' -export GOVC_PASSWORD='MyPassword1' -export GOVC_NETWORK='VM Network' -export GOVC_INSECURE=1 -export GOVC_DATASTORE='datastore1' -export GOVC_RESOURCE_POOL='/Datacenter/host/10.20.104.24/Resources' -export GOVC_GUEST_LOGIN='kube:kube' -export GOVC_PORT='443' -export GOVC_DATACENTER='Datacenter' -``` - -Import this VMDK into your vSphere datastore: - -```shell -govc import.vmdk kube.vmdk ./kube/ -``` - -Verify that the VMDK was correctly uploaded and expanded to ~3GiB: - -```shell -govc datastore.ls ./kube/ -``` - -If you need to debug any part of the deployment, the guest login for -the image that you imported is `kube:kube`. It is normally specified -in the GOVC_GUEST_LOGIN parameter above. - -Also take a look at the file `cluster/vsphere/config-default.sh` and -make any needed changes. You can configure the number of nodes -as well as the IP subnets you have made available to Kubernetes, pods, -and services. - -#### Starting a cluster - -Now, let's continue with deploying Kubernetes. -This process takes about ~20-30 minutes depending on your network. - -##### From extracted binary release - -```shell -cd kubernetes -KUBERNETES_PROVIDER=vsphere cluster/kube-up.sh -``` - -##### Build from source - -```shell -cd kubernetes -make release -KUBERNETES_PROVIDER=vsphere cluster/kube-up.sh -``` - -Refer to the top level README and the getting started guide for Google Compute -Engine. Once you have successfully reached this point, your vSphere Kubernetes -deployment works just as any other one! - -**Enjoy!** - -#### Extra: debugging deployment failure - -The output of `kube-up.sh` displays the IP addresses of the VMs it deploys. You -can log into any VM as the `kube` user to poke around and figure out what is -going on (find yourself authorized with your SSH key, or use the password -`kube` otherwise). +[vmware#220](https://github.com/vmware/kubernetes/issues/220) : +vSphere Cloud Provider can not be used on the Kubernetes Cluster when vCenter port is configured other than the default port 443. Fix for this issue is already out (Kubernetes PR# [49689](https://github.com/kubernetes/kubernetes/pull/49689)). We will make sure that, PR 49689 is cherry picked to 1.7, 1.6 and 1.5 branches. ## Support Level -IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level --------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- -Vmware vSphere | Kube-anywhere | Photon OS | Flannel | [docs](/docs/getting-started-guides/vsphere) | | Community ([@abrarshivani](https://github.com/abrarshivani)), ([@kerneltime](https://github.com/kerneltime)), ([@BaluDontu](https://github.com/BaluDontu)), ([@luomiao](https://github.com/luomiao)), ([@divyenpatel](https://github.com/divyenpatel)) +IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level +-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | --------- | ---------------------------- +Vmware vSphere | Kube-anywhere | Photon OS | Flannel | [docs](/docs/getting-started-guides/vsphere) | | Community ([@abrarshivani](https://github.com/abrarshivani)), ([@kerneltime](https://github.com/kerneltime)), ([@BaluDontu](https://github.com/BaluDontu)), ([@luomiao](https://github.com/luomiao)), ([@divyenpatel](https://github.com/divyenpatel)) If you identify any issues/problems using the vSphere cloud provider, you can create an issue in our repo - [VMware Kubernetes](https://github.com/vmware/kubernetes). For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions) chart. - diff --git a/docs/home/contribute/page-templates.md b/docs/home/contribute/page-templates.md index ec9369af30..726969d2a4 100644 --- a/docs/home/contribute/page-templates.md +++ b/docs/home/contribute/page-templates.md @@ -1,7 +1,4 @@ --- -redirect_from: -- "/docs/templatedemos/" -- "/docs/templatedemos.html" title: Using Page Templates --- diff --git a/docs/home/contribute/style-guide.md b/docs/home/contribute/style-guide.md index a8277f8198..3945937866 100644 --- a/docs/home/contribute/style-guide.md +++ b/docs/home/contribute/style-guide.md @@ -137,6 +137,111 @@ A list of Kubernetes-specific terms and words to be used consistently across the TBDTBD {% endcomment %} +## Callout Formatting +Callouts help create different rhetorical appeal levels. Our documentation supports three different callouts: **Note:** {: .note}, **Caution:** {: .caution}, and **Warning:** {: .warning}. + +1. Start each callout with the appropriate prefix. + +2. Use the following syntax to apply a style: + +```console +**Note:** The prefix you use is the same text you use in the tag. +{: .note} +``` + +The output is: + +**Note:** The prefix you choose is the same text for the tag. +{: .note} + +### Note + +Use {: .note} to highlight a tip or a piece of information that may be helpful to know. + +For example: + +```console +**Note:** You can _still_ use Markdown inside these callouts. +{: .note} +``` + +The output is: + +**Note:** You can _still_ use Markdown inside these callouts. +{: .note} + +### Caution + +Use {: .caution} to call attention to an important piece of information to avoid pitfalls. + +For example: + +```console +**Caution:** The callout style only applies to the line directly above the tag. +{: .caution} +``` + +The output is: + +**Caution:** The callout style only applies to the line directly above the tag. +{: .caution} + +### Warning + +Use {: .warning} to indicate danger or a piece of information that is crucial to follow. + +For example: + +```console +**Warning:** Beware. +{: .warning} +``` + +The output is: + +**Warning:** Beware. +{: .warning} + +## Common Callout Issues + +### Style Does Not Apply + +Callout tags must be on a new line to apply the style. Github's Preview Changes feature further obfuscates this fact by rendering the tag on the same line, but your code must match the following syntax: + +```console +**Note:** Your text goes here. +{: .note} +``` + +### Multiple Lines + +Callouts should generally be single sentences and automatically span multiple lines. However, you can use `
` tags if you need to create multiple lines. + +For example: + +```console +**Note:"** This is my note. Use `
` to create multiple lines.

You can still use _Markdown_ to **format** text! +{: .note} +``` + +The output is: + +**Note:** This is my note. Use `
` to create multiple lines.

You can still use _Markdown_ to **format** text! +{: .note} + +Typing multiple lines does **not** work. The callout style only applies to the line directly above the tag. + +```console +**Note:** This is my note. + +I didn't read the stlye guide. +{: .note} +``` + +**Note:** This is my note. + +I didn't read the stlye guide. +{: .note} ## Content best practices diff --git a/docs/home/index.md b/docs/home/index.md index ea6b927032..89266aaa91 100644 --- a/docs/home/index.md +++ b/docs/home/index.md @@ -3,11 +3,6 @@ assignees: - bgrant0607 - thockin title: Kubernetes Documentation -redirect_from: -- "/docs/" -- "/docs/index.html" -- "/docs/user-guide/" -- "/docs/user-guide/index.html" --- Kubernetes documentation can help you set up Kubernetes, learn about the system, or get your applications and workloads running on Kubernetes. To learn the basics of what Kubernetes is and how it works, read "[What is Kubernetes](/docs/concepts/overview/what-is-kubernetes/)". diff --git a/docs/reference/client-libraries.md b/docs/reference/client-libraries.md index 4acc272602..a1f3a06646 100644 --- a/docs/reference/client-libraries.md +++ b/docs/reference/client-libraries.md @@ -36,21 +36,22 @@ Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery The following Kubernetes API client libraries are provided and maintained by their authors, not the Kubernetes team. -| Language | Client Library | -|----------|----------------| -| Clojure | [github.com/yanatan16/clj-kubernetes-api](https://github.com/yanatan16/clj-kubernetes-api) | -| Go | [github.com/ericchiang/k8s](https://github.com/ericchiang/k8s) | -| Java (OSGi) | [bitbucket.org/amdatulabs/amdatu-kubernetes](https://bitbucket.org/amdatulabs/amdatu-kubernetes) | +| Language | Client Library | +| -------------------- | ---------------------------------------- | +| Clojure | [github.com/yanatan16/clj-kubernetes-api](https://github.com/yanatan16/clj-kubernetes-api) | +| Go | [github.com/ericchiang/k8s](https://github.com/ericchiang/k8s) | +| Java (OSGi) | [bitbucket.org/amdatulabs/amdatu-kubernetes](https://bitbucket.org/amdatulabs/amdatu-kubernetes) | | Java (Fabric8, OSGi) | [github.com/fabric8io/kubernetes-client](https://github.com/fabric8io/kubernetes-client) | -| Node.js | [github.com/tenxcloud/node-kubernetes-client](https://github.com/tenxcloud/node-kubernetes-client) | -| Node.js | [github.com/godaddy/kubernetes-client](https://github.com/godaddy/kubernetes-client) | -| Perl | [metacpan.org/pod/Net::Kubernetes](https://metacpan.org/pod/Net::Kubernetes) | -| PHP | [github.com/devstub/kubernetes-api-php-client](https://github.com/devstub/kubernetes-api-php-client) | -| PHP | [github.com/maclof/kubernetes-client](https://github.com/maclof/kubernetes-client) | -| Python | [github.com/eldarion-gondor/pykube](https://github.com/eldarion-gondor/pykube) | -| Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) | -| Ruby | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) | -| Scala | [github.com/doriordan/skuber](https://github.com/doriordan/skuber) | +| Node.js (TypeScript) | [github.com/Goyoo/node-k8s-client](https://github.com/Goyoo/node-k8s-client) | +| Node.js | [github.com/tenxcloud/node-kubernetes-client](https://github.com/tenxcloud/node-kubernetes-client) | +| Node.js | [github.com/godaddy/kubernetes-client](https://github.com/godaddy/kubernetes-client) | +| Perl | [metacpan.org/pod/Net::Kubernetes](https://metacpan.org/pod/Net::Kubernetes) | +| PHP | [github.com/devstub/kubernetes-api-php-client](https://github.com/devstub/kubernetes-api-php-client) | +| PHP | [github.com/maclof/kubernetes-client](https://github.com/maclof/kubernetes-client) | +| Python | [github.com/eldarion-gondor/pykube](https://github.com/eldarion-gondor/pykube) | +| Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) | +| Ruby | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) | +| Scala | [github.com/doriordan/skuber](https://github.com/doriordan/skuber) | {% endcapture %} {% include templates/concept.md %} diff --git a/docs/reference/federation/index.md b/docs/reference/federation/index.md index 8cfd620d4b..81ace6743a 100644 --- a/docs/reference/federation/index.md +++ b/docs/reference/federation/index.md @@ -1,8 +1,5 @@ --- title: Federation API Reference -redirect_from: -- "/docs/federation/api-reference/" -- "/docs/federation/api-reference/index.md" --- # API Reference diff --git a/docs/setup/independent/create-cluster-kubeadm.md b/docs/setup/independent/create-cluster-kubeadm.md index 789e4a60a3..f57a483a38 100644 --- a/docs/setup/independent/create-cluster-kubeadm.md +++ b/docs/setup/independent/create-cluster-kubeadm.md @@ -5,9 +5,6 @@ assignees: - errordeveloper - jbeda title: Using kubeadm to Create a Cluster -redirect_from: -- "/docs/getting-started-guides/kubeadm/" -- "/docs/getting-started-guides/kubeadm.html" --- {% capture overview %} @@ -105,17 +102,16 @@ kubeadm on, and run: kubeadm init ``` -**Note:** this will autodetect the network interface to advertise the master on +**Note:** + - You need to choose a Pod Network Plugin in the next step. Depending on what +third-party provider you choose, you might have to set the `--pod-network-cidr` to +something provider-specific. The tabs below will contain a notice about what flags +on `kubeadm init` are required. + - This will autodetect the network interface to advertise the master on as the interface with the default gateway. If you want to use a different interface, specify `--apiserver-advertise-address=` argument to `kubeadm init`. -There are pod network implementations where the master also plays a role in -allocating a set of network address space for each node. When using -[flannel](https://github.com/coreos/flannel) as the [pod network](#pod-network) -(described in step 3), specify `--pod-network-cidr=10.244.0.0/16`. _This is not -required for any other networks besides flannel._ - Please refer to the [kubeadm reference doc](/docs/admin/kubeadm/) if you want to read more about the flags `kubeadm init` provides. @@ -182,31 +178,9 @@ token can add authenticated nodes to your cluster. These tokens can be listed, created and deleted with the `kubeadm token` command. See the [reference guide](/docs/admin/kubeadm/#manage-tokens). -#### Master Isolation - -By default, your cluster will not schedule pods on the master for security -reasons. If you want to be able to schedule pods on the master, e.g. for a -single-machine Kubernetes cluster for development, run: - -``` bash -kubectl taint nodes --all node-role.kubernetes.io/master- -``` - -With output looking something like: - -``` -node "test-01" tainted -taint key="dedicated" and effect="" not found. -taint key="dedicated" and effect="" not found. -``` - -This will remove the `node-role.kubernetes.io/master` taint from any nodes that -have it, including the master node, meaning that the scheduler will then be able -to schedule pods everywhere. - ### (3/4) Installing a pod network {#pod-network} -You must install a pod network add-on so that your pods can communicate with +You **must** install a pod network add-on so that your pods can communicate with each other. **The network must be deployed before any applications. Also, kube-dns, a @@ -228,13 +202,79 @@ You can install a pod network add-on with the following command: kubectl apply -f ``` -Please refer to the specific add-on installation guide for exact details. - **NOTE:** You can install **only one** pod network per cluster. -If you are on another architecture than amd64, you should use the -flannel or Weave Net overlay networks as described in [the -multi-platform section](#multi-platform) + +{% capture choose %} +Please select one of the tabs to see installation instructions for the respective third-party Pod Network Provider. +{% endcapture %} + +{% capture calico %} + +The official Calico guide is [here](http://docs.projectcalico.org/v2.3/getting-started/kubernetes/installation/hosted/kubeadm/) + +**Note:** + - In order for Network Policy to work correctly, you need to pass `--pod-network-cidr=192.168.0.0/16` to `kubeadm init` + - Calico works on `amd64` only. + +```shell +kubectl apply -f http://docs.projectcalico.org/v2.3/getting-started/kubernetes/installation/hosted/kubeadm/1.6/calico.yaml +``` +{% endcapture %} + +{% capture canal %} + +The official Canal set-up guide is [here](https://github.com/projectcalico/canal/tree/master/k8s-install) + +**Note:** + - For Canal to work correctly, `--pod-network-cidr=10.244.0.0/16` has to be passed to `kubeadm init`. + - Canal works on `amd64` only. + +```shell +kubectl apply -f https://raw.githubusercontent.com/projectcalico/canal/master/k8s-install/1.6/rbac.yaml +kubectl apply -f https://raw.githubusercontent.com/projectcalico/canal/master/k8s-install/1.6/canal.yaml +``` +{% endcapture %} + +{% capture flannel %} + +**Note:** + - 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` occurances with your chosen platform. + +```shell +kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml +kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel-rbac.yml +``` +{% endcapture %} + +{% capture romana %} + +The official Romana set-up guide is [here](https://github.com/romana/romana/tree/master/containerize#using-kubeadm) + +**Note:** Romana works on `amd64` only. + +```shell +kubectl apply -f https://raw.githubusercontent.com/romana/romana/master/containerize/specs/romana-kubeadm.yml +``` +{% endcapture %} + +{% capture weave_net %} + +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. + +```shell +kubectl apply -f https://git.io/weave-kube-1.6 +``` +{% endcapture %} + +{% assign tab_names = "Choose one...,Calico,Canal,Flannel,Romana,Weave Net" | split: ',' | compact %} +{% assign tab_contents = site.emptyArray | push: choose | push: calico | push: canal | push: flannel | push: romana | push: weave_net %} + +{% include tabs.md %} Once a pod network has been installed, you can confirm that it is working by checking that the kube-dns pod is Running in the output of `kubectl get pods --all-namespaces`. @@ -243,6 +283,28 @@ And once the kube-dns pod is up and running, you can continue by joining your no If your network is not working or kube-dns is not in the Running state, check out the [troubleshooting section](#troubleshooting) below. +#### Master Isolation + +By default, your cluster will not schedule pods on the master for security +reasons. If you want to be able to schedule pods on the master, e.g. for a +single-machine Kubernetes cluster for development, run: + +``` bash +kubectl taint nodes --all node-role.kubernetes.io/master- +``` + +With output looking something like: + +``` +node "test-01" tainted +taint key="dedicated" and effect="" not found. +taint key="dedicated" and effect="" not found. +``` + +This will remove the `node-role.kubernetes.io/master` taint from any nodes that +have it, including the master node, meaning that the scheduler will then be able +to schedule pods everywhere. + ### (4/4) Joining your nodes The nodes are where your workloads (containers and pods, etc) run. To add new nodes to your cluster do the following for each machine: @@ -294,7 +356,7 @@ kubectl --kubeconfig ./admin.conf get nodes **Note:** If you are using GCE, instances disable ssh access for root by default. If that's the case you can log in to the machine, copy the file someplace that -can be accessed and then use +can be accessed and then use [`gcloud compute copy-files`](https://cloud.google.com/sdk/gcloud/reference/compute/copy-files) ### (Optional) Proxying API Server to localhost @@ -419,7 +481,9 @@ kubeadm deb/rpm packages and binaries are built for amd64, arm (32-bit), arm64, following the [multi-platform proposal](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/multi-platform.md). -Currently, only the pod networks [flannel](https://github.com/coreos/flannel) and [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) work on multiple architectures. +Only some of the network providers offer solutions for all platforms. Please consult the list of +network providers above or the documentation from each provider to figure out whether the provider +supports your chosen platform. ## Limitations diff --git a/docs/setup/pick-right-solution.md b/docs/setup/pick-right-solution.md index 2e7d66a856..2a25d144c3 100644 --- a/docs/setup/pick-right-solution.md +++ b/docs/setup/pick-right-solution.md @@ -4,9 +4,6 @@ assignees: - erictune - mikedanese title: Picking the Right Solution -redirect_from: -- "/docs/getting-started-guides/index/" -- "/docs/getting-started-guides/index.html" --- Kubernetes can run on various platforms: from your laptop, to VMs on a cloud provider, to rack of diff --git a/docs/tasks/access-application-cluster/access-cluster.md b/docs/tasks/access-application-cluster/access-cluster.md index 69a8cf9ed0..5d7d0a7275 100644 --- a/docs/tasks/access-application-cluster/access-cluster.md +++ b/docs/tasks/access-application-cluster/access-cluster.md @@ -1,10 +1,5 @@ --- title: Accessing Clusters -redirect_from: -- "/docs/user-guide/accessing-the-cluster/" -- "/docs/user-guide/accessing-the-cluster.html" -- "/docs/concepts/cluster-administration/access-cluster/" -- "/docs/concepts/cluster-administration/access-cluster.html" --- * TOC @@ -124,7 +119,8 @@ with future high-availability support. ### Programmatic access to the API -Kubernetes supports [Go](#go-client) and [Python](#python-client) client libraries. +Kubernetes officially supports [Go](#go-client) and [Python](#python-client) +client libraries. #### Go client @@ -145,7 +141,8 @@ as the kubectl CLI does to locate and authenticate to the apiserver. See this [e #### Other languages -There are [client libraries](https://git.k8s.io/community/contributors/devel/client-libraries.md) for accessing the API from other languages. See documentation for other libraries for how they authenticate. +There are [client libraries](/docs/reference/client-libraries/) for accessing the API from other languages. +See documentation for other libraries for how they authenticate. ### Accessing the API from a Pod diff --git a/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md b/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md index 99050a6204..82a7fe3c89 100644 --- a/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md +++ b/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md @@ -3,11 +3,6 @@ assignees: - mikedanese - thockin title: Authenticate Across Clusters with kubeconfig -redirect_from: -- "/docs/user-guide/kubeconfig-file/" -- "/docs/user-guide/kubeconfig-file.html" -- "/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/" -- "/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig.html" --- Authentication in Kubernetes can differ for different individuals. diff --git a/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md b/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md index 4435b8c626..2edb8e379b 100644 --- a/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md +++ b/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md @@ -1,10 +1,5 @@ --- title: Communicate Between Containers in the Same Pod Using a Shared Volume -redirect_from: -- "/docs/user-guide/pods/multi-container/" -- "/docs/user-guide/pods/multi-container.html" -- "docs/tasks/configure-pod-container/communicate-containers-same-pod/" -- "docs/tasks/configure-pod-container/communicate-containers-same-pod.html" --- {% capture overview %} @@ -144,9 +139,9 @@ the shared Volume is lost. * See [Configuring a Pod to Use a Volume for Storage](/docs/tasks/configure-pod-container/configure-volume-storage/). -* See [Volume](/docs/api-reference/v1.6/#volume-v1-core). +* See [Volume](/docs/api-reference/{{page.version}}/#volume-v1-core). -* See [Pod](/docs/api-reference/v1.6/#pod-v1-core). +* See [Pod](/docs/api-reference/{{page.version}}/#pod-v1-core). {% endcapture %} diff --git a/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md b/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md index 042e49f16a..2941e3cb2b 100644 --- a/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md +++ b/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md @@ -3,9 +3,6 @@ assignees: - bprashanth - davidopp title: Configure Your Cloud Provider's Firewalls -redirect_from: -- "/docs/user-guide/services-firewalls/" -- "/docs/user-guide/services-firewalls.html" --- Many cloud providers (e.g. Google Compute Engine) define firewalls that help prevent inadvertent diff --git a/docs/tasks/access-application-cluster/connecting-frontend-backend.md b/docs/tasks/access-application-cluster/connecting-frontend-backend.md index 8f9c6046f4..76507c6f4b 100644 --- a/docs/tasks/access-application-cluster/connecting-frontend-backend.md +++ b/docs/tasks/access-application-cluster/connecting-frontend-backend.md @@ -1,10 +1,5 @@ --- title: Connect a Front End to a Back End Using a Service -redirect_from: -- "/docs/user-guide/services/operations/" -- "/docs/user-guide/services/operations.html" -- "/docs/tutorials/connecting-apps/connecting-frontend-backend/" -- "/docs/tutorials/connecting-apps/connecting-frontend-backend.html" --- {% capture overview %} diff --git a/docs/tasks/access-application-cluster/create-external-load-balancer.md b/docs/tasks/access-application-cluster/create-external-load-balancer.md index 1e197365b1..29533f315c 100644 --- a/docs/tasks/access-application-cluster/create-external-load-balancer.md +++ b/docs/tasks/access-application-cluster/create-external-load-balancer.md @@ -1,8 +1,5 @@ --- title: Create an External Load Balancer -redirect_from: -- "/docs/user-guide/load-balancer/" -- "/docs/user-guide/load-balancer.html" --- diff --git a/docs/tasks/access-application-cluster/list-all-running-container-images.md b/docs/tasks/access-application-cluster/list-all-running-container-images.md index 3cb33864e2..922e5c62d6 100644 --- a/docs/tasks/access-application-cluster/list-all-running-container-images.md +++ b/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -1,8 +1,5 @@ --- title: List All Container Images Running in a Cluster -redirect_from: -- "/docs/tasks/kubectl/list-all-running-container-images/" -- "/docs/tasks/kubectl/list-all-running-container-images.html" --- {% capture overview %} diff --git a/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md b/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md index 875c3cc78e..66ae046f3d 100644 --- a/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md +++ b/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md @@ -1,8 +1,5 @@ --- title: Use Port Forwarding to Access Applications in a Cluster -redirect_from: -- "/docs/user-guide/connecting-to-applications-port-forward/" -- "/docs/user-guide/connecting-to-applications-port-forward.html" --- {% capture overview %} diff --git a/docs/tasks/access-application-cluster/service-access-application-cluster.md b/docs/tasks/access-application-cluster/service-access-application-cluster.md index b32cfe22b3..314a55fe4b 100644 --- a/docs/tasks/access-application-cluster/service-access-application-cluster.md +++ b/docs/tasks/access-application-cluster/service-access-application-cluster.md @@ -1,10 +1,5 @@ --- title: Use a Service to Access an Application in a Cluster -redirect_from: -- "/docs/user-guide/quick-start/" -- "/docs/user-guide/quick-start.html" -- "/docs/tutorials/stateless-application/expose-external-ip-address-service/" -- "/docs/tutorials/stateless-application/expose-external-ip-address-service.html" --- {% capture overview %} @@ -99,11 +94,14 @@ provides load balancing for an application that has two running instances. 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. + nodes. For more information about this command, see the [GCE documentation](https://cloud.google.com/sdk/gcloud/reference/compute/instances/list). 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. + 31568, create a firewall rule that allows TCP traffic on port 31568. Different + cloud providers offer different ways of configuring firewall rules. See [the + GCE documentation on firewall rules](https://cloud.google.com/compute/docs/vpc/firewalls), + for example. 1. Use the node address and node port to access the Hello World application: diff --git a/docs/tasks/access-application-cluster/web-ui-dashboard.md b/docs/tasks/access-application-cluster/web-ui-dashboard.md index 4b541f9ad7..53b8cbe748 100644 --- a/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -4,11 +4,6 @@ assignees: - mikedanese - rf232 title: Web UI (Dashboard) -redirect_from: -- "/docs/user-guide/ui/" -- "/docs/user-guide/ui.html" -- "/docs/tasks/web-ui-dashboard/" -- "/docs/tasks/web-ui-dashboard.html" --- Dashboard is a web-based Kubernetes user interface. You can use Dashboard to deploy containerized applications to a Kubernetes cluster, troubleshoot your containerized application, and manage the cluster itself along with its attendant resources. You can use Dashboard to get an overview of applications running on your cluster, as well as for creating or modifying individual Kubernetes resources (such as Deployments, Jobs, DaemonSets, etc). For example, you can scale a Deployment, initiate a rolling update, restart a pod or deploy new applications using a deploy wizard. diff --git a/docs/tasks/access-kubernetes-api/extend-api-third-party-resource.md b/docs/tasks/access-kubernetes-api/extend-api-third-party-resource.md index e436d4929f..ddc033e571 100644 --- a/docs/tasks/access-kubernetes-api/extend-api-third-party-resource.md +++ b/docs/tasks/access-kubernetes-api/extend-api-third-party-resource.md @@ -3,11 +3,6 @@ assignees: - enisoc - IanLewis title: Extend the Kubernetes API with ThirdPartyResources -redirect_from: -- "/docs/user-guide/thirdpartyresources/" -- "/docs/user-guide/thirdpartyresources.html" -- "/docs/concepts/ecosystem/thirdpartyresource/" -- "/docs/concepts/ecosystem/thirdpartyresource.html" --- {% assign for_k8s_version="1.7" %}{% include feature-state-deprecated.md %} diff --git a/docs/tasks/access-kubernetes-api/http-proxy-access-api.md b/docs/tasks/access-kubernetes-api/http-proxy-access-api.md index 9e78cd052d..9818a02968 100644 --- a/docs/tasks/access-kubernetes-api/http-proxy-access-api.md +++ b/docs/tasks/access-kubernetes-api/http-proxy-access-api.md @@ -1,8 +1,5 @@ --- title: Use an HTTP Proxy to Access the Kubernetes API -redirect_from: -- "/docs/user-guide/connecting-to-applications-proxy/" -- "/docs/user-guide/connecting-to-applications-proxy.html" --- {% capture overview %} diff --git a/docs/tasks/administer-cluster/access-cluster-api.md b/docs/tasks/administer-cluster/access-cluster-api.md index 16f41c2631..c96524252a 100644 --- a/docs/tasks/administer-cluster/access-cluster-api.md +++ b/docs/tasks/administer-cluster/access-cluster-api.md @@ -1,9 +1,5 @@ --- title: Access Clusters Using the Kubernetes API -redirect_from: -- "/docs/user-guide/accessing-the-cluster/" -- "/docs/user-guide/accessing-the-cluster.html" -- "/docs/concepts/cluster-administration/access-cluster/" --- {% capture overview %} @@ -43,10 +39,10 @@ kubectl. Complete documentation is found in the [kubectl manual](/docs/user-gui 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: - 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 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. 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. + + Using the Go or Python client libraries provides accessing kubectl in proxy mode. #### Using kubectl proxy @@ -116,7 +112,8 @@ with future high-availability support. ### Programmatic access to the API -Kubernetes supports [Go](#go-client) and [Python](#python-client) client libraries. +Kubernetes officially supports client libraries for [Go](#go-client) and +[Python](#python-client). #### Go client @@ -167,7 +164,7 @@ for i in ret.items: #### Other languages -There are [client libraries](https://git.k8s.io/community/contributors/devel/client-libraries.md) for accessing the API from other languages. See documentation for other libraries for how they authenticate. +There are [client libraries](/docs/reference/client-libraries/) for accessing the API from other languages. See documentation for other libraries for how they authenticate. ### Accessing the API from a Pod diff --git a/docs/tasks/administer-cluster/access-cluster-services.md b/docs/tasks/administer-cluster/access-cluster-services.md index db0d9e5253..0630274bc3 100644 --- a/docs/tasks/administer-cluster/access-cluster-services.md +++ b/docs/tasks/administer-cluster/access-cluster-services.md @@ -1,12 +1,9 @@ --- title: Access Services Running on Clusters -redirect_from: -- "/docs/user-guide/accessing-the-cluster/" -- "/docs/user-guide/accessing-the-cluster.html" --- {% capture overview %} -This page shows how to connect to services running on the Kubernetes cluster. +This page shows how to connect to services running on the Kubernetes cluster. {% endcapture %} {% capture prerequisites %} diff --git a/docs/tasks/administer-cluster/apply-resource-quota-limit.md b/docs/tasks/administer-cluster/apply-resource-quota-limit.md index 5183797a0c..a1ee37b3ea 100644 --- a/docs/tasks/administer-cluster/apply-resource-quota-limit.md +++ b/docs/tasks/administer-cluster/apply-resource-quota-limit.md @@ -3,11 +3,6 @@ assignees: - derekwaynecarr - janetkuo title: Apply Resource Quotas and Limits -redirect_from: -- "/docs/admin/resourcequota/walkthrough/" -- "/docs/admin/resourcequota/walkthrough.html" -- "/docs/tasks/configure-pod-container/apply-resource-quota-limit/" -- "/docs/tasks/configure-pod-container/apply-resource-quota-limit.html" --- {% capture overview %} @@ -359,7 +354,7 @@ the 2 pods we created in the `not-best-effort-nginx` quota. Scopes provide a mechanism to subdivide the set of resources that are tracked by any quota document to allow greater flexibility in how operators deploy and track resource -consumption. +consumption. In addition to `BestEffort` and `NotBestEffort` scopes, there are scopes to restrict long-running versus time-bound pods. The `Terminating` scope will match any pod diff --git a/docs/tasks/administer-cluster/calico-network-policy.md b/docs/tasks/administer-cluster/calico-network-policy.md index b513c547c9..ef4903b765 100644 --- a/docs/tasks/administer-cluster/calico-network-policy.md +++ b/docs/tasks/administer-cluster/calico-network-policy.md @@ -2,11 +2,6 @@ assignees: - caseydavenport title: Use Calico for NetworkPolicy -redirect_from: -- "/docs/getting-started-guides/network-policy/calico/" -- "/docs/getting-started-guides/network-policy/calico.html" -- "/docs/tasks/configure-pod-container/calico-network-policy/" -- "/docs/tasks/configure-pod-container/calico-network-policy.html" --- {% capture overview %} @@ -14,7 +9,7 @@ This page shows how to use Calico for NetworkPolicy. {% endcapture %} {% capture prerequisites %} -* Install Calico for Kubernetes. +* Install Calico for Kubernetes. {% endcapture %} {% capture steps %} @@ -34,7 +29,7 @@ See the [Calico documentation](http://docs.projectcalico.org/) for more options {% capture discussion %} ## Understanding Calico components -Deploying a cluster with Calico adds Pods that support Kubernetes NetworkPolicy. These Pods run in the `kube-system` Namespace. +Deploying a cluster with Calico adds Pods that support Kubernetes NetworkPolicy. These Pods run in the `kube-system` Namespace. To see this list of Pods run: diff --git a/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/docs/tasks/administer-cluster/change-pv-reclaim-policy.md index 3ee13ff261..5b18dd7820 100644 --- a/docs/tasks/administer-cluster/change-pv-reclaim-policy.md +++ b/docs/tasks/administer-cluster/change-pv-reclaim-policy.md @@ -18,7 +18,7 @@ PersistentVolume. ## Why change reclaim policy of a PersistentVolume `PersistentVolumes` can have various reclaim policies, including "Retain", -"Recycle", and "Delete". For dynamically provisioned `PersistentVolumes`, +"Recycle", and "Delete". For dynamically provisioned `PersistentVolumes`, the default reclaim policy is "Delete". This means that a dynamically provisioned volume is automatically deleted when a user deletes the corresponding `PeristentVolumeClaim`. This automatic behavior might be inappropriate if the volume @@ -72,9 +72,9 @@ the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to ### Reference -* [PersistentVolume](/docs/api-reference/v1.6/#persistentvolume-v1-core) -* [PersistentVolumeClaim](/docs/api-reference/v1.6/#persistentvolumeclaim-v1-core) -* See the `persistentVolumeReclaimPolicy` field of [PersistentVolumeSpec](/docs/api-reference/v1.6/#persistentvolumeclaim-v1-core). +* [PersistentVolume](/docs/api-reference/{{page.version}}/#persistentvolume-v1-core) +* [PersistentVolumeClaim](/docs/api-reference/{{page.version}}/#persistentvolumeclaim-v1-core) +* See the `persistentVolumeReclaimPolicy` field of [PersistentVolumeSpec](/docs/api-reference/{{page.version}}/#persistentvolumeclaim-v1-core). {% endcapture %} {% include templates/task.md %} diff --git a/docs/tasks/administer-cluster/cluster-management.md b/docs/tasks/administer-cluster/cluster-management.md index da24a4a2b2..bfac133344 100644 --- a/docs/tasks/administer-cluster/cluster-management.md +++ b/docs/tasks/administer-cluster/cluster-management.md @@ -3,11 +3,6 @@ assignees: - lavalamp - thockin title: Cluster Management -redirect_from: -- "/docs/admin/cluster-management/" -- "/docs/admin/cluster-management.html" -- "/docs/concepts/cluster-administration/cluster-management/" -- "/docs/concepts/cluster-administration/cluster-management.html" --- * TOC diff --git a/docs/tasks/administer-cluster/configure-multiple-schedulers.md b/docs/tasks/administer-cluster/configure-multiple-schedulers.md index 1acff68bfd..6c7303fc06 100644 --- a/docs/tasks/administer-cluster/configure-multiple-schedulers.md +++ b/docs/tasks/administer-cluster/configure-multiple-schedulers.md @@ -3,11 +3,6 @@ assignees: - davidopp - madhusudancs title: Configure Multiple Schedulers -redirect_from: -- "/docs/admin/multiple-schedulers/" -- "/docs/admin/multiple-schedulers.html" -- "/docs/tutorials/clusters/multiple-schedulers/" -- "/docs/tutorials/clusters/multiple-schedulers.html" --- Kubernetes ships with a default scheduler that is described [here](/docs/admin/kube-scheduler/). diff --git a/docs/tasks/administer-cluster/configure-upgrade-etcd.md b/docs/tasks/administer-cluster/configure-upgrade-etcd.md index 142c3c7d6b..b80642072b 100644 --- a/docs/tasks/administer-cluster/configure-upgrade-etcd.md +++ b/docs/tasks/administer-cluster/configure-upgrade-etcd.md @@ -3,17 +3,6 @@ assignees: - mml - wojtek-t title: Operating etcd clusters for Kubernetes -redirect_from: -- "/docs/concepts/storage/etcd-store-api-object/" -- "/docs/concepts/storage/etcd-store-api-object.html" -- "/docs/admin/etcd/" -- "/docs/admin/etcd.html" -- "/docs/admin/etcd_upgrade/" -- "/docs/admin/etcd_upgrade.html" -- "/docs/concepts/cluster-administration/configure-etcd/" -- "/docs/concepts/cluster-administration/configure-etcd.html" -- "/docs/concepts/cluster-administration/etcd-upgrade/" -- "/docs/concepts/cluster-administration/etcd-upgrade.html" --- etcd is a strong, consistent, and highly-available key value store which Kubernetes uses for persistent storage of all of its API objects. This documentation provides specific instruction on operating, upgrading, and rolling back etcd clusters for Kubernetes. For in-depth information on etcd, see [etcd documentation](https://github.com/coreos/etcd/blob/master/Documentation/docs.md). diff --git a/docs/tasks/administer-cluster/cpu-memory-limit.md b/docs/tasks/administer-cluster/cpu-memory-limit.md index d04c9b14b4..10224c02c3 100644 --- a/docs/tasks/administer-cluster/cpu-memory-limit.md +++ b/docs/tasks/administer-cluster/cpu-memory-limit.md @@ -3,11 +3,6 @@ assignees: - derekwaynecarr - janetkuo title: Set Pod CPU and Memory Limits -redirect_from: -- "/docs/admin/limitrange/" -- "/docs/admin/limitrange/index.html" -- "/docs/tasks/configure-pod-container/limit-range/" -- "/docs/tasks/configure-pod-container/limit-range.html" --- {% capture overview %} @@ -39,7 +34,7 @@ $ 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: +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 @@ -103,7 +98,7 @@ 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/v1.6/#run) for more details. +If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/user-guide/kubectl/{{page.version}}/#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 @@ -112,7 +107,7 @@ 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. +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 @@ -151,7 +146,7 @@ $ kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/valid-pod. pod "valid-pod" created ``` -Now look at the Pod's resources field: +Now look at the Pod's resources field: ```shell $ kubectl get pods valid-pod --namespace=limit-example -o yaml | grep -C 6 resources @@ -215,8 +210,8 @@ to 512MB of memory. The cluster operator creates a separate namespace for each 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 limit waste. +the cluster operator may want to set limits that a pod must consume no more than 20% of the memory and CPU of +their average node size in order to provide for more uniform scheduling and limit waste. ## Summary diff --git a/docs/tasks/administer-cluster/declare-network-policy.md b/docs/tasks/administer-cluster/declare-network-policy.md index c1fc7feaf2..b85b75d2e2 100644 --- a/docs/tasks/administer-cluster/declare-network-policy.md +++ b/docs/tasks/administer-cluster/declare-network-policy.md @@ -3,14 +3,9 @@ assignees: - caseydavenport - danwinship title: Declare Network Policy -redirect_from: -- "/docs/getting-started-guides/network-policy/walkthrough/" -- "/docs/getting-started-guides/network-policy/walkthrough.html" -- "/docs/tasks/configure-pod-container/declare-network-policy/" -- "/docs/tasks/configure-pod-container/declare-network-policy.html" --- {% capture overview %} -This document helps you get started using using the Kubernetes [NetworkPolicy API](/docs/user-guide/network-policies) to declare network policies that govern how pods communicate with each other. +This document helps you get started using using the Kubernetes [NetworkPolicy API](/docs/concepts/services-networking/network-policies/) to declare network policies that govern how pods communicate with each other. {% endcapture %} {% capture prerequisites %} @@ -28,16 +23,16 @@ You'll need to have a Kubernetes cluster in place, with network policy support. ## Create an `nginx` deployment and expose it via a service -To see how Kubernetes network policy works, start off by creating an `nginx` deployment and exposing it via a service. +To see how Kubernetes network policy works, start off by creating an `nginx` deployment and exposing it via a service. ```console $ kubectl run nginx --image=nginx --replicas=2 deployment "nginx" created -$ kubectl expose deployment nginx --port=80 +$ kubectl expose deployment nginx --port=80 service "nginx" exposed ``` -This runs two `nginx` pods in the default namespace, and exposes them through a service called `nginx`. +This runs two `nginx` pods in the default namespace, and exposes them through a service called `nginx`. ```console $ kubectl get svc,pod @@ -104,7 +99,7 @@ Waiting for pod default/busybox-472357175-y0m47 to be running, status is Pending Hit enter for command prompt -/ # wget --spider --timeout=1 nginx +/ # wget --spider --timeout=1 nginx Connecting to nginx (10.100.0.16:80) wget: download timed out / # diff --git a/docs/tasks/administer-cluster/encrypt-data.md b/docs/tasks/administer-cluster/encrypt-data.md index 92bfbd6dc8..5f096631a3 100644 --- a/docs/tasks/administer-cluster/encrypt-data.md +++ b/docs/tasks/administer-cluster/encrypt-data.md @@ -148,7 +148,7 @@ program to retrieve the contents of your secret. Since secrets are encrypted on write, performing an update on a secret will encrypt that content. ``` -kubectl get secrets -o json | kubectl update -f - +kubectl get secrets -o json | kubectl replace -f - ``` The command above reads all secrets and then updates them to apply server side encryption. @@ -165,7 +165,7 @@ the presence of a highly available deployment where multiple `kube-apiserver` pr 2. Restart all `kube-apiserver` processes to ensure each server can decrypt using the new key 3. Make the new key the first entry in the `keys` array so that it is used for encryption in the config 4. Restart all `kube-apiserver` processes to ensure each server now encrypts using the new key -5. Run `kubectl get secrets -o json | kubectl update -f -` to update all secrets +5. Run `kubectl get secrets -o json | kubectl replace -f -` to encrypt all existing secrets with the new key 6. Remove the old decryption key from the config after you back up etcd with the new key in use and update all secrets With a single `kube-apiserver`, step 2 may be skipped @@ -189,7 +189,7 @@ resources: secret: ``` -and restart all `kube-apiserver` processes. Then run the command `kubectl get secrets -o json | kubectl update -f -` +and restart all `kube-apiserver` processes. Then run the command `kubectl get secrets -o json | kubectl replace -f -` to force all secrets to be decrypted. {% endcapture %} diff --git a/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md b/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md index 77415f3414..d131066f01 100644 --- a/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md +++ b/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md @@ -4,11 +4,6 @@ assignees: - filipg - piosz title: Guaranteed Scheduling For Critical Add-On Pods -redirect_from: -- "/docs/admin/rescheduler/" -- "/docs/admin/rescheduler.html" -- "/docs/concepts/cluster-administration/guaranteed-scheduling-critical-addon-pods/" -- "/docs/concepts/cluster-administration/guaranteed-scheduling-critical-addon-pods.html" --- * TOC diff --git a/docs/tasks/administer-cluster/highly-available-master.md b/docs/tasks/administer-cluster/highly-available-master.md index 666c2606f3..4b50fddbaf 100644 --- a/docs/tasks/administer-cluster/highly-available-master.md +++ b/docs/tasks/administer-cluster/highly-available-master.md @@ -2,9 +2,6 @@ assignees: - jszczepkowski title: Set up High-Availability Kubernetes Masters -redirect_from: -- "/docs/admin/ha-master-gce/" -- "/docs/admin/ha-master-gce.html" --- * TOC @@ -65,7 +62,7 @@ You can remove a master replica from an HA cluster by using a `kube-down` script * `KUBE_DELETE_NODES=false` - to restrain deletion of kubelets. * `KUBE_GCE_ZONE=zone` - the zone from where master replica will be removed. - + * `KUBE_REPLICA_NAME=replica_name` - (optional) the name of master replica to remove. If empty: any replica from the given zone will be removed. @@ -105,7 +102,7 @@ A two-replica cluster is thus inferior, in terms of HA, to a single replica clus * When you add a master replica, cluster state (etcd) is copied to a new instance. If the cluster is large, it may take a long time to duplicate its state. -This operation may be sped up by migrating etcd data directory, as described [here](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration) +This operation may be sped up by migrating etcd data directory, as described [here](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration) (we are considering adding support for etcd data dir migration in future). ## Implementation notes diff --git a/docs/tasks/administer-cluster/ip-masq-agent.md b/docs/tasks/administer-cluster/ip-masq-agent.md index 34c62dac18..f5da4a3a76 100644 --- a/docs/tasks/administer-cluster/ip-masq-agent.md +++ b/docs/tasks/administer-cluster/ip-masq-agent.md @@ -60,7 +60,7 @@ By default, in GCE/GKE starting with Kubernetes version 1.7.0, the ip-masq-agent To create an ip-masq-agent, run the following kubectl command: ` -kubectl create -f https://github.com/kubernetes-incubator/ip-masq-agent/blob/master/ip-masq-agent.yaml +kubectl create -f https://raw.githubusercontent.com/kubernetes-incubator/ip-masq-agent/master/ip-masq-agent.yaml ` More information can be found in the ip-masq-agent documentation [here](https://github.com/kubernetes-incubator/ip-masq-agent) diff --git a/docs/tasks/administer-cluster/kubeadm-upgrade-1-7.md b/docs/tasks/administer-cluster/kubeadm-upgrade-1-7.md index ffdcec348d..44c540028a 100644 --- a/docs/tasks/administer-cluster/kubeadm-upgrade-1-7.md +++ b/docs/tasks/administer-cluster/kubeadm-upgrade-1-7.md @@ -2,9 +2,6 @@ assignees: - pipejakob title: Upgrading kubeadm clusters from 1.6 to 1.7 -redirect_from: -- "/docs/admin/kubeadm-upgrade-1-7/" -- "/docs/admin/kubeadm-upgrade-1-7.html" --- {% capture overview %} @@ -95,4 +92,4 @@ You need to have a Kubernetes cluster running version 1.6.x. {% endcapture %} -{% include templates/task.md %} \ No newline at end of file +{% include templates/task.md %} diff --git a/docs/tasks/administer-cluster/limit-storage-consumption.md b/docs/tasks/administer-cluster/limit-storage-consumption.md index 2b402c8743..018ff996c3 100644 --- a/docs/tasks/administer-cluster/limit-storage-consumption.md +++ b/docs/tasks/administer-cluster/limit-storage-consumption.md @@ -1,16 +1,13 @@ --- title: Limit Storage Consumption -redirect_from: -- "/docs/admin/resourcequota/limitstorageconsumption/" -- "/docs/admin/resourcequota/limitstorageconsumption.html" --- {% capture overview %} This example demonstrates an easy way to limit the amount of storage consumed in a namespace. -The following resources are used in the demonstration: [ResourceQuota](/docs/concepts/policy/resource-quotas/), -[LimitRange](/docs/tasks/configure-pod-container/limit-range/), +The following resources are used in the demonstration: [ResourceQuota](/docs/concepts/policy/resource-quotas/), +[LimitRange](/docs/tasks/configure-pod-container/limit-range/), and [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/). {% endcapture %} @@ -56,17 +53,17 @@ spec: storage: 1Gi ``` -Minimum storage requests are used when the underlying storage provider requires certain minimums. For example, -AWS EBS volumes have a 1Gi minimum requirement. +Minimum storage requests are used when the underlying storage provider requires certain minimums. For example, +AWS EBS volumes have a 1Gi minimum requirement. ## StorageQuota to limit PVC count and cumulative storage capacity Admins can limit the number of PVCs in a namespace as well as the cumulative capacity of those PVCs. New PVCs that exceed either maximum value will be rejected. -In this example, a 6th PVC in the namespace would be rejected because it exceeds the maximum count of 5. Alternatively, +In this example, a 6th PVC in the namespace would be rejected because it exceeds the maximum count of 5. Alternatively, a 5Gi maximum quota when combined with the 2Gi max limit above, cannot have 3 PVCs where each has 2Gi. That would be 6Gi requested - for a namespace capped at 5Gi. + for a namespace capped at 5Gi. ``` apiVersion: v1 @@ -83,10 +80,10 @@ spec: {% capture discussion %} -## Summary +## Summary A limit range can put a ceiling on how much storage is requested while a resource quota can effectively cap the storage -consumed by a namespace through claim counts and cumulative storage capacity. The allows a cluster-admin to plan their +consumed by a namespace through claim counts and cumulative storage capacity. The allows a cluster-admin to plan their cluster's storage budget without risk of any one project going over their allotment. {% endcapture %} diff --git a/docs/tasks/administer-cluster/namespaces-walkthrough.md b/docs/tasks/administer-cluster/namespaces-walkthrough.md index 8b248e92c8..be275c798b 100644 --- a/docs/tasks/administer-cluster/namespaces-walkthrough.md +++ b/docs/tasks/administer-cluster/namespaces-walkthrough.md @@ -3,9 +3,6 @@ assignees: - derekwaynecarr - janetkuo title: Namespaces Walkthrough -redirect_from: -- "/docs/admin/namespaces/walkthrough/" -- "/docs/admin/namespaces/walkthrough.html" --- Kubernetes _namespaces_ help different projects, teams, or customers to share a Kubernetes cluster. @@ -153,9 +150,9 @@ Let's create some contents. ```shell $ kubectl run snowflake --image=kubernetes/serve_hostname --replicas=2 ``` -We have just created a deployment whose replica size is 2 that is running the pod called snowflake with a basic container that just serves the hostname. +We have just created a deployment whose replica size is 2 that is running the pod called snowflake with a basic container that just serves the hostname. Note that `kubectl run` creates deployments only 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/v1.6/#run) for more details. +If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/user-guide/kubectl/v1.6/#run) for more details. ```shell $ kubectl get deployment diff --git a/docs/tasks/administer-cluster/namespaces.md b/docs/tasks/administer-cluster/namespaces.md index ad0da4e625..95f453c431 100644 --- a/docs/tasks/administer-cluster/namespaces.md +++ b/docs/tasks/administer-cluster/namespaces.md @@ -3,47 +3,22 @@ assignees: - derekwaynecarr - janetkuo title: Share a Cluster with Namespaces -redirect_from: -- "/docs/admin/namespaces/" -- "/docs/admin/namespaces/index.html" --- -A Namespace is a mechanism to partition resources created by users into -a logically named group. +{% capture overview %} +This page shows how to view, work in, and delete namespaces. The page also shows how to use Kubernetes namespaces to subdivide your cluster. +{% endcapture %} -## Motivation +{% capture prerequisites %} +* Have an [existing Kubernetes cluster](/docs/getting-started-guides/). +* Have a basic understanding of Kubernetes _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, and _[Deployments](/docs/concepts/workloads/controllers/deployment/)_. +{% endcapture %} -A single cluster should be able to satisfy the needs of multiple users or groups of users (henceforth a 'user community'). - -Each user community wants to be able to work in isolation from other communities. - -Each user community has its own: - -1. resources (pods, services, replication controllers, etc.) -2. policies (who can or cannot perform actions in their community) -3. constraints (this community is allowed this much quota, etc.) - -A cluster operator may create a Namespace for each unique user community. - -The Namespace provides a unique scope for: - -1. named resources (to avoid basic naming collisions) -2. delegated management authority to trusted users -3. ability to limit community resource consumption - -## Use cases - -1. As a cluster operator, I want to support multiple user communities on a single cluster. -2. As a cluster operator, I want to delegate authority to partitions of the cluster to trusted users - in those communities. -3. As a cluster operator, I want to limit the amount of resources each community can consume in order - to limit the impact to other communities using the cluster. -4. As a cluster user, I want to interact with resources that are pertinent to my user community in - isolation of what other user communities are doing on the cluster. +{% capture steps %} ## Viewing namespaces -You can list the current namespaces in a cluster using: +1. List the current namespaces in a cluster using: ```shell $ kubectl get namespaces @@ -67,16 +42,16 @@ Or you can get detailed information with: ```shell $ kubectl describe namespaces -Name: default -Labels: -Status: Active +Name: default +Labels: +Status: Active No resource quota. Resource Limits - Type Resource Min Max Default - ---- -------- --- --- --- - Container cpu - - 100m + Type Resource Min Max Default + ---- -------- --- --- --- + Container cpu - - 100m ``` Note that these details show both resource quota (if present) as well as resource limit ranges. @@ -98,7 +73,7 @@ See the [design doc](https://git.k8s.io/community/contributors/design-proposals/ ## Creating a new namespace -To create a new namespace, first create a new YAML file called `my-namespace.yaml` with the contents: +1. Create a new YAML file called `my-namespace.yaml` with the contents: ```yaml apiVersion: v1 @@ -119,15 +94,9 @@ There's an optional field `finalizers`, which allows observables to purge resour More information on `finalizers` can be found in the namespace [design doc](https://git.k8s.io/community/contributors/design-proposals/namespaces.md#finalizers). - -### Working in namespaces - -See [Setting the namespace for a request](/docs/user-guide/namespaces/#setting-the-namespace-for-a-request) -and [Setting the namespace preference](/docs/user-guide/namespaces/#setting-the-namespace-preference). - ## Deleting a namespace -You can delete a namespace with +1. Delete a namespace with ```shell $ kubectl delete namespaces @@ -137,16 +106,246 @@ $ kubectl delete namespaces This delete is asynchronous, so for a time you will see the namespace in the `Terminating` state. -## Namespaces and DNS +## Subdividing your cluster using Kubernetes namespaces -When you create a [Service](/docs/user-guide/services), it creates a corresponding [DNS entry](/docs/admin/dns). +1. Understand the default namespace + +By default, a Kubernetes cluster will instantiate a default namespace when provisioning the cluster to hold the default set of Pods, +Services, and Deployments used by the cluster. + +Assuming you have a fresh cluster, you can introspect the available namespace's by doing the following: + +```shell +$ kubectl get namespaces +NAME STATUS AGE +default Active 13m +``` + +2. Create new namespaces + +For this exercise, we will create two additional Kubernetes namespaces to hold our content. + +In a scenario where an organization is using a shared Kubernetes cluster for development and production use cases: + +The development team would like to maintain a space in the cluster where they can get a view on the list of Pods, Services, and Deployments +they use to build and run their application. In this space, Kubernetes resources come and go, and the restrictions on who can or cannot modify resources +are relaxed to enable agile development. + +The operations team would like to maintain a space in the cluster where they can enforce strict procedures on who can or cannot manipulate the set of +Pods, Services, and Deployments that run the production site. + +One pattern this organization could follow is to partition the Kubernetes cluster into two namespaces: development and production. + +Let's create two new namespaces to hold our work. + +Use the file [`namespace-dev.json`](/docs/admin/namespaces/namespace-dev.json) which describes a development namespace: + +{% include code.html language="json" file="namespace-dev.json" ghlink="/docs/admin/namespaces/namespace-dev.json" %} + +Create the development namespace using kubectl. + +```shell +$ kubectl create -f docs/admin/namespaces/namespace-dev.json +``` + +And then let's create the production namespace using kubectl. + +```shell +$ kubectl create -f docs/admin/namespaces/namespace-prod.json +``` + +To be sure things are right, list all of the namespaces in our cluster. + +```shell +$ kubectl get namespaces --show-labels +NAME STATUS AGE LABELS +default Active 32m +development Active 29s name=development +production Active 23s name=production +``` + +3. Create pods in each namespace + +A Kubernetes namespace provides the scope for Pods, Services, and Deployments in the cluster. + +Users interacting with one namespace do not see the content in another namespace. + +To demonstrate this, let's spin up a simple Deployment and Pods in the development namespace. + +We first check what is the current context: + +```shell +$ kubectl config view +apiVersion: v1 +clusters: +- cluster: + certificate-authority-data: REDACTED + server: https://130.211.122.180 + name: lithe-cocoa-92103_kubernetes +contexts: +- context: + cluster: lithe-cocoa-92103_kubernetes + user: lithe-cocoa-92103_kubernetes + name: lithe-cocoa-92103_kubernetes +current-context: lithe-cocoa-92103_kubernetes +kind: Config +preferences: {} +users: +- name: lithe-cocoa-92103_kubernetes + user: + client-certificate-data: REDACTED + client-key-data: REDACTED + token: 65rZW78y8HbwXXtSXuUw9DbP4FLjHi4b +- name: lithe-cocoa-92103_kubernetes-basic-auth + user: + password: h5M0FtUUIflBSdI7 + username: admin + +$ kubectl config current-context +lithe-cocoa-92103_kubernetes +``` + +The next step is to define a context for the kubectl client to work in each namespace. The value of "cluster" and "user" fields are copied from the current context. + +```shell +$ kubectl config set-context dev --namespace=development --cluster=lithe-cocoa-92103_kubernetes --user=lithe-cocoa-92103_kubernetes +$ kubectl config set-context prod --namespace=production --cluster=lithe-cocoa-92103_kubernetes --user=lithe-cocoa-92103_kubernetes +``` + +The above commands provided two request contexts you can alternate against depending on what namespace you +wish to work against. + +Let's switch to operate in the development namespace. + +```shell +$ kubectl config use-context dev +``` + +You can verify your current context by doing the following: + +```shell +$ kubectl config current-context +dev +``` + +At this point, all requests we make to the Kubernetes cluster from the command line are scoped to the development namespace. + +Let's create some contents. + +```shell +$ kubectl run snowflake --image=kubernetes/serve_hostname --replicas=2 +``` +We have just created a deployment whose replica size is 2 that is running the pod called snowflake with a basic container that just serves the hostname. +Note that `kubectl run` creates deployments only 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/v1.7/#run) for more details. + +```shell +$ kubectl get deployment +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +snowflake 2 2 2 2 2m + +$ kubectl get pods -l run=snowflake +NAME READY STATUS RESTARTS AGE +snowflake-3968820950-9dgr8 1/1 Running 0 2m +snowflake-3968820950-vgc4n 1/1 Running 0 2m +``` + +And this is great, developers are able to do what they want, and they do not have to worry about affecting content in the production namespace. + +Let's switch to the production namespace and show how resources in one namespace are hidden from the other. + +```shell +$ kubectl config use-context prod +``` + +The production namespace should be empty, and the following commands should return nothing. + +```shell +$ kubectl get deployment +$ kubectl get pods +``` + +Production likes to run cattle, so let's create some cattle pods. + +```shell +$ kubectl run cattle --image=kubernetes/serve_hostname --replicas=5 + +$ kubectl get deployment +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +cattle 5 5 5 5 10s + +kubectl get pods -l run=cattle +NAME READY STATUS RESTARTS AGE +cattle-2263376956-41xy6 1/1 Running 0 34s +cattle-2263376956-kw466 1/1 Running 0 34s +cattle-2263376956-n4v97 1/1 Running 0 34s +cattle-2263376956-p5p3i 1/1 Running 0 34s +cattle-2263376956-sxpth 1/1 Running 0 34s +``` + +At this point, it should be clear that the resources users create in one namespace are hidden from the other namespace. + +As the policy support in Kubernetes evolves, we will extend this scenario to show how you can provide different +authorization rules for each namespace. + +{% endcapture %} + +{% capture discussion %} + +## Understanding the motivation for using namespaces + +A single cluster should be able to satisfy the needs of multiple users or groups of users (henceforth a 'user community'). + +Kubernetes _namespaces_ help different projects, teams, or customers to share a Kubernetes cluster. + +It does this by providing the following: + +1. A scope for [Names](/docs/concepts/overview/working-with-objects/names/). +2. A mechanism to attach authorization and policy to a subsection of the cluster. + +Use of multiple namespaces is optional. + +Each user community wants to be able to work in isolation from other communities. + +Each user community has its own: + +1. resources (pods, services, replication controllers, etc.) +2. policies (who can or cannot perform actions in their community) +3. constraints (this community is allowed this much quota, etc.) + +A cluster operator may create a Namespace for each unique user community. + +The Namespace provides a unique scope for: + +1. named resources (to avoid basic naming collisions) +2. delegated management authority to trusted users +3. ability to limit community resource consumption + +Use cases include: + +1. As a cluster operator, I want to support multiple user communities on a single cluster. +2. As a cluster operator, I want to delegate authority to partitions of the cluster to trusted users + in those communities. +3. As a cluster operator, I want to limit the amount of resources each community can consume in order + to limit the impact to other communities using the cluster. +4. As a cluster user, I want to interact with resources that are pertinent to my user community in + isolation of what other user communities are doing on the cluster. + +## Understanding namespaces and DNS + +When you create a [Service](/docs/concepts/services-networking/service/), it creates a corresponding [DNS entry](/docs/admin/dns). This entry is of the form `..svc.cluster.local`, which means that if a container just uses `` it will resolve to the service which is local to a namespace. This is useful for using the same configuration across multiple namespaces such as Development, Staging and Production. If you want to reach across namespaces, you need to use the fully qualified domain name (FQDN). -## Design +{% endcapture %} -Details of the design of namespaces in Kubernetes, including a [detailed example](https://git.k8s.io/community/contributors/design-proposals/namespaces.md#example-openshift-origin-managing-a-kubernetes-namespace) -can be found in the [namespaces design doc](https://git.k8s.io/community/contributors/design-proposals/namespaces.md) +{% capture whatsnext %} +* Learn more about [setting the namespace preference](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-preference). +* Learn more about [setting the namespace for a request](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-for-a-request) +* See [namespaces design](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/namespaces.md). +{% endcapture %} + +{% include templates/task.md %} diff --git a/docs/tasks/administer-cluster/out-of-resource.md b/docs/tasks/administer-cluster/out-of-resource.md index a076b0dc77..6fa0b45de7 100644 --- a/docs/tasks/administer-cluster/out-of-resource.md +++ b/docs/tasks/administer-cluster/out-of-resource.md @@ -4,11 +4,6 @@ assignees: - vishh - timstclair title: Configure Out Of Resource Handling -redirect_from: -- "/docs/admin/out-of-resource/" -- "/docs/admin/out-of-resource.html" -- "/docs/concepts/cluster-administration/out-of-resource/" -- "/docs/concepts/cluster-administration/out-of-resource.html" --- * TOC diff --git a/docs/tasks/administer-cluster/reserve-compute-resources.md b/docs/tasks/administer-cluster/reserve-compute-resources.md index 923c2b22af..a759fee87a 100644 --- a/docs/tasks/administer-cluster/reserve-compute-resources.md +++ b/docs/tasks/administer-cluster/reserve-compute-resources.md @@ -4,9 +4,6 @@ assignees: - derekwaynecarr - dashpole title: Reserve Compute Resources for System Daemons -redirect_from: -- "/docs/admin/node-allocatable/" -- "/docs/admin/node-allocatable.html" --- * TOC diff --git a/docs/tasks/administer-cluster/romana-network-policy.md b/docs/tasks/administer-cluster/romana-network-policy.md index 897298d863..a5f62a6ac7 100644 --- a/docs/tasks/administer-cluster/romana-network-policy.md +++ b/docs/tasks/administer-cluster/romana-network-policy.md @@ -2,11 +2,6 @@ assignees: - chrismarino title: Romana for NetworkPolicy -redirect_from: -- "/docs/getting-started-guides/network-policy/romana/" -- "/docs/getting-started-guides/network-policy/romana.html" -- "/docs/tasks/configure-pod-container/romana-network-policy/" -- "/docs/tasks/configure-pod-container/romana-network-policy.html" --- {% capture overview %} @@ -17,7 +12,7 @@ This page shows how to use Romana for NetworkPolicy. {% capture prerequisites %} -Complete steps 1, 2, and 3 of the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/). +Complete steps 1, 2, and 3 of the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/). {% endcapture %} @@ -25,16 +20,16 @@ Complete steps 1, 2, and 3 of the [kubeadm getting started guide](/docs/getting ## Installing Romana with kubeadm -Follow the [containerized installation guide](https://github.com/romana/romana/tree/master/containerize) for kubeadmin. +Follow the [containerized installation guide](https://github.com/romana/romana/tree/master/containerize) for kubeadmin. ## Applying network policies To apply network policies use one of the following: -* [Romana network policies](https://github.com/romana/romana/wiki/Romana-policies). +* [Romana network policies](https://github.com/romana/romana/wiki/Romana-policies). * [Example of Romana network policy](https://github.com/romana/core/tree/master/policy). * The NetworkPolicy API. - + {% endcapture %} {% capture whatsnext %} diff --git a/docs/tasks/administer-cluster/running-cloud-controller.md b/docs/tasks/administer-cluster/running-cloud-controller.md index 21b278b74c..d10ba81955 100644 --- a/docs/tasks/administer-cluster/running-cloud-controller.md +++ b/docs/tasks/administer-cluster/running-cloud-controller.md @@ -1,15 +1,12 @@ --- assignees: -- thockin +- thockin title: Build and Run cloud-controller-manager -redirect_from: -- "/docs/getting-started-guides/running-cloud-controller/" -- "/docs/getting-started-guides/running-cloud-controller.html" --- Kubernetes version 1.6 contains a new binary called as `cloud-controller-manager`. `cloud-controller-manager` is a daemon that embeds cloud-specific control loops in Kubernetes. These cloud-specific control loops were originally in the kube-controller-manager. However, cloud providers move at a different pace and schedule compared to the Kubernetes project, and abstracting the provider-specific code to the `cloud-controller-manager` binary allows cloud provider vendors to evolve independently from the core Kubernetes code. -The `cloud-controller-manager` can be linked to any cloud provider that satisifies the [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go). +The `cloud-controller-manager` can be linked to any cloud provider that satisifies the [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go). In future Kubernetes releases, cloud vendors should link code that satisfies the above interface to the `cloud-controller-manager` project and compile `cloud-controller-manager` for their own clouds. Cloud providers would also be responsible for maintaining and evolving their code. * TOC @@ -33,3 +30,5 @@ Once your code is ready, you must import that code into `cloud-controller-manage To run `cloud-controller-manager`, add it to your existing Kubernetes cluster as a Master component. All other master components except `kube-controller-manager` can be run without any changes. The `kube-controller-manager` should not run any cloud-specific controllers, since the `cloud-controller-manager` takes over this responsibility. To prevent the `kube-controller-manager` from running cloud-specific controllers, you must set the `--cloud-provider` flag in `kube-controller-manager` to `external`. + +The `kube-apiserver` should not run the Persistent Volume Label admission controller either since the `cloud-controller-manager` takes over labeling persistent volumes. To prevent the Persistent Volume Label admission plugin from running, make sure the `kube-apiserver` has a `--admission-control` flag with a value that does not include `PersistentVolumeLabel`. diff --git a/docs/tasks/administer-cluster/safely-drain-node.md b/docs/tasks/administer-cluster/safely-drain-node.md index f80b39e9c6..c673104429 100644 --- a/docs/tasks/administer-cluster/safely-drain-node.md +++ b/docs/tasks/administer-cluster/safely-drain-node.md @@ -83,7 +83,7 @@ For example, if you have a StatefulSet with three replicas and have set a `PodDisruptionBudget` for that set specifying `minAvailable: 2`. `kubectl drain` will only evict a pod from the StatefulSet if all three pods are ready, and if you issue multiple drain commands in -parallel, Kubernetes will respect the PodDisruptionBudget an ensure +parallel, Kubernetes will respect the PodDisruptionBudget and ensure that only one pod is unavailable at any given time. Any drains that would cause the number of ready replicas to fall below the specified budget are blocked. @@ -91,7 +91,7 @@ budget are blocked. ## The Eviction API If you prefer not to use [kubectl drain](/docs/user-guide/kubectl/{{page.version}}/#drain) (such as -to avoid calling to an external command, or to get finer control over over the pod +to avoid calling to an external command, or to get finer control over the pod eviction process), you can also programmatically cause evictions using the eviction API. You should first be familiar with using [Kubernetes language clients](/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api). diff --git a/docs/tasks/administer-cluster/share-configuration.md b/docs/tasks/administer-cluster/share-configuration.md index 77ae867707..57cd219b95 100644 --- a/docs/tasks/administer-cluster/share-configuration.md +++ b/docs/tasks/administer-cluster/share-configuration.md @@ -3,9 +3,6 @@ assignees: - mikedanese - thockin title: Share Cluster Access with kubeconfig -redirect_from: -- "/docs/user-guide/sharing-clusters/" -- "/docs/user-guide/sharing-clusters.html" --- Client access to a running Kubernetes cluster can be shared by copying diff --git a/docs/tasks/administer-cluster/static-pod.md b/docs/tasks/administer-cluster/static-pod.md index 84a35e696d..cb8a011ac9 100644 --- a/docs/tasks/administer-cluster/static-pod.md +++ b/docs/tasks/administer-cluster/static-pod.md @@ -2,11 +2,6 @@ assignees: - jsafrane title: Static Pods -redirect_from: -- "/docs/admin/static-pods/" -- "/docs/admin/static-pods.html" -- "/docs/concepts/cluster-administration/static-pod/" -- "/docs/concepts/cluster-administration/static-pod.html" --- **If you are running clustered Kubernetes and are using static pods to run a pod on every node, you should probably be using a [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)!** diff --git a/docs/tasks/administer-cluster/upgrade-1-6.md b/docs/tasks/administer-cluster/upgrade-1-6.md index 0ad116fdab..f2a2a5e9ee 100644 --- a/docs/tasks/administer-cluster/upgrade-1-6.md +++ b/docs/tasks/administer-cluster/upgrade-1-6.md @@ -2,28 +2,25 @@ assignees: - mml title: Cluster Management Guide for Version 1.6 -redirect_from: -- "/docs/admin/upgrade-1-6/" -- "/docs/admin/upgrade-1-6.html" --- * TOC {:toc} -This document outlines the potentially disruptive changes that exist in the 1.6 release cycle. Operators, administrators, and developers should -take note of the changes below in order to maintain continuity across their upgrade process. +This document outlines the potentially disruptive changes that exist in the 1.6 release cycle. Operators, administrators, and developers should +take note of the changes below in order to maintain continuity across their upgrade process. -## Cluster defaults set to etcd 3 +## Cluster defaults set to etcd 3 -In the 1.6 release cycle, the default backend storage layer has been upgraded to fully leverage [etcd 3 capabilities](https://coreos.com/blog/etcd3-a-new-etcd.html) by default. -For new clusters, there is nothing an operator will need to do, it should "just work". However, if you are upgrading from a 1.5 cluster, care should be taken to ensure -continuity. +In the 1.6 release cycle, the default backend storage layer has been upgraded to fully leverage [etcd 3 capabilities](https://coreos.com/blog/etcd3-a-new-etcd.html) by default. +For new clusters, there is nothing an operator will need to do, it should "just work". However, if you are upgrading from a 1.5 cluster, care should be taken to ensure +continuity. -It is possible to maintain v2 compatibility mode while running etcd 3 for an interim period of time. To do this, you will simply need to update an argument passed to your apiserver during -startup: +It is possible to maintain v2 compatibility mode while running etcd 3 for an interim period of time. To do this, you will simply need to update an argument passed to your apiserver during +startup: ``` $ kube-apiserver --storage-backend='etcd2' $(EXISTING_ARGS) -``` +``` -However, for long-term maintenance of the cluster, we recommend that the operator plan an outage window in order to perform a [v2->v3 data upgrade](https://coreos.com/etcd/docs/latest/upgrades/upgrade_3_0.html). +However, for long-term maintenance of the cluster, we recommend that the operator plan an outage window in order to perform a [v2->v3 data upgrade](https://coreos.com/etcd/docs/latest/upgrades/upgrade_3_0.html). diff --git a/docs/tasks/administer-cluster/weave-network-policy.md b/docs/tasks/administer-cluster/weave-network-policy.md index 7960007655..a6c9fad9a7 100644 --- a/docs/tasks/administer-cluster/weave-network-policy.md +++ b/docs/tasks/administer-cluster/weave-network-policy.md @@ -2,11 +2,6 @@ assignees: - bboreham title: Weave Net for NetworkPolicy -redirect_from: -- "/docs/getting-started-guides/network-policy/weave/" -- "/docs/getting-started-guides/network-policy/weave.html" -- "/docs/tasks/configure-pod-container/weave-network-policy/" -- "/docs/tasks/configure-pod-container/weave-network-policy.html" --- {% capture overview %} @@ -17,13 +12,13 @@ This page shows how to use Weave Net for NetworkPolicy. {% capture prerequisites %} -Complete steps 1, 2, and 3 of the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/). +Complete steps 1, 2, and 3 of the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/). {% endcapture %} {% capture steps %} -## Installing Weave Net addon +## Installing Weave Net addon Follow the [Integrating Kubernetes via the Addon](https://www.weave.works/docs/net/latest/kube-addon/) guide. diff --git a/docs/tasks/administer-federation/cluster.md b/docs/tasks/administer-federation/cluster.md index a08919a180..7d5a718b12 100644 --- a/docs/tasks/administer-federation/cluster.md +++ b/docs/tasks/administer-federation/cluster.md @@ -1,15 +1,12 @@ --- title: Federated Cluster -redirect_from: -- "/docs/user-guide/federation/cluster/" -- "/docs/user-guide/federation/cluster.html" --- {% capture overview %} This guide explains how to use Clusters API resource in a Federation control plane. -Different than other Kuberentes resources, such as Deployments, Services and ConfigMaps, +Different than other Kubernetes resources, such as Deployments, Services and ConfigMaps, clusters only exist in the federation context, i.e. those requests must be submitted to the federation api-server. diff --git a/docs/tasks/administer-federation/configmap.md b/docs/tasks/administer-federation/configmap.md index 1e8e1acbc0..857ea8a59a 100644 --- a/docs/tasks/administer-federation/configmap.md +++ b/docs/tasks/administer-federation/configmap.md @@ -1,8 +1,5 @@ --- title: Federated ConfigMap -redirect_from: -- "/docs/user-guide/federation/configmap/" -- "/docs/user-guide/federation/configmap.html" --- {% capture overview %} @@ -75,7 +72,7 @@ the federation apiserver instead of sending it to a specific Kubernetes cluster. For example, you can do that using kubectl by running: ```shell -kubectl --context=federation-cluster delete configmap +kubectl --context=federation-cluster delete configmap ``` Note that at this point, deleting a Federated ConfigMap will not delete the diff --git a/docs/tasks/administer-federation/daemonset.md b/docs/tasks/administer-federation/daemonset.md index 4caf90d645..0b79f261e4 100644 --- a/docs/tasks/administer-federation/daemonset.md +++ b/docs/tasks/administer-federation/daemonset.md @@ -1,8 +1,5 @@ --- title: Federated DaemonSet -redirect_from: -- "/docs/user-guide/federation/daemonsets/" -- "/docs/user-guide/federation/daemonsets.html" --- {% capture overview %} @@ -43,7 +40,7 @@ request to the Federation apiserver instead of sending it to a Kubernetes cluster. Once a Federated Daemonset is created, the federation control plane will create -a matching DaemonSet in all underlying Kubernetes clusters. +a matching DaemonSet in all underlying Kubernetes clusters. You can verify this by checking each of the underlying clusters, for example: ``` shell diff --git a/docs/tasks/administer-federation/deployment.md b/docs/tasks/administer-federation/deployment.md index 22caa24e66..6aa8b3b803 100644 --- a/docs/tasks/administer-federation/deployment.md +++ b/docs/tasks/administer-federation/deployment.md @@ -1,8 +1,5 @@ --- title: Federated Deployment -redirect_from: -- "/docs/user-guide/federation/deployment/" -- "/docs/user-guide/federation/deployment.html" --- {% capture overview %} @@ -14,8 +11,8 @@ Deployment](/docs/concepts/workloads/controllers/deployment/) and provide the sa Creating them in the federation control plane ensures that the desired number of replicas exist across the registered clusters. -**As of Kubernetes version 1.5, Federated Deployment is an Alpha feature. The core -functionality of Deployment is present, but some features +**As of Kubernetes version 1.5, Federated Deployment is an Alpha feature. The core +functionality of Deployment is present, but some features (such as full rollout compatibility) are still in development.** {% endcapture %} @@ -60,7 +57,7 @@ These Deployments in underlying clusters will match the federation Deployment _except_ in the number of replicas and revision-related annotations. Federation control plane ensures that the sum of replicas in each cluster combined matches the desired number of replicas in the -Federated Deployment. +Federated Deployment. ### Spreading Replicas in Underlying Clusters @@ -81,7 +78,7 @@ Deployment; however, for a Federated Deployment, you must send the request to the federation apiserver instead of sending it to a specific Kubernetes cluster. The federation control plane ensures that whenever the Federated Deployment is updated, it updates the corresponding Deployments in all underlying clusters to -match it. So if the rolling update strategy was chosen then the underlying +match it. So if the rolling update strategy was chosen then the underlying cluster will do the rolling update independently and `maxSurge` and `maxUnavailable` will apply only to individual clusters. This behavior may change in the future. diff --git a/docs/tasks/administer-federation/events.md b/docs/tasks/administer-federation/events.md index de5f6cefd9..1d9f72ea0e 100644 --- a/docs/tasks/administer-federation/events.md +++ b/docs/tasks/administer-federation/events.md @@ -1,8 +1,5 @@ --- title: Federated Events -redirect_from: -- "/docs/user-guide/federation/events/" -- "/docs/user-guide/federation/events.html" --- This guide explains how to use events in federation control plane to help in debugging. diff --git a/docs/tasks/administer-federation/ingress.md b/docs/tasks/administer-federation/ingress.md index 60ef62697c..9149b761b1 100644 --- a/docs/tasks/administer-federation/ingress.md +++ b/docs/tasks/administer-federation/ingress.md @@ -1,9 +1,7 @@ --- title: Federated Ingress -redirect_from: -- "/docs/user-guide/federation/federated-ingress/" -- "/docs/user-guide/federation/federated-ingress.html" --- + {% capture overview %} This page explains how to use Kubernetes Federated Ingress to deploy a common HTTP(S) virtual IP load balancer across a federated service running in @@ -25,7 +23,7 @@ Federated Ingress is released as an alpha feature, and supports Google Cloud Pla 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 -clusters). +clusters). You create Federated Ingresses in much that same way as traditional [Kubernetes Ingresses](/docs/concepts/services-networking/ingress/): by making an API @@ -151,7 +149,7 @@ may take up to a few minutes). the network traffic directed to this ingress (that is, 'Service Endpoints' behind the service backing the Ingress), so the Federated Ingress does not yet consider these to be healthy shards and will not direct traffic to any of these clusters. -* The federation control system +* The federation control system automatically reconfigures the load balancer controllers in all of the clusters in your federation to make them consistent, and allows them to share global load balancers. But this reconfiguration can @@ -202,7 +200,7 @@ nginx 10.63.250.98 104.199.136.89 80/TCP 9m Federations of Kubernetes Clusters can include clusters running in different cloud providers (for example, Google Cloud, AWS), and on-premises (for example, on OpenStack). However, in Kubernetes v1.4, Federated Ingress is only -supported across Google Cloud clusters. +supported across Google Cloud clusters. ## Discovering a federated ingress @@ -301,11 +299,11 @@ Check that: {% capture whatsnext %} * If you need assistance, use one of the [support channels](/docs/tasks/debug-application-cluster/troubleshooting/) to seek assistance. - * For details about use cases that motivated this work, see + * For details about use cases that motivated this work, see [Federation proposal](https://git.k8s.io/community/contributors/design-proposals/federation.md). {% endcapture %} {% include templates/task.md %} - - - - + + + + diff --git a/docs/tasks/administer-federation/namespaces.md b/docs/tasks/administer-federation/namespaces.md index 1fc319f553..45f85d1c2c 100644 --- a/docs/tasks/administer-federation/namespaces.md +++ b/docs/tasks/administer-federation/namespaces.md @@ -1,8 +1,5 @@ --- title: Federated Namespaces -redirect_from: -- "/docs/user-guide/federation/namespaces/" -- "/docs/user-guide/federation/namespaces.html" --- {% capture overview %} diff --git a/docs/tasks/administer-federation/replicaset.md b/docs/tasks/administer-federation/replicaset.md index f2b6c5a9d6..ea20022148 100644 --- a/docs/tasks/administer-federation/replicaset.md +++ b/docs/tasks/administer-federation/replicaset.md @@ -1,8 +1,5 @@ --- title: Federated ReplicaSets -redirect_from: -- "/docs/user-guide/federation/replicasets/" -- "/docs/user-guide/federation/replicasets.html" --- {% capture overview %} diff --git a/docs/tasks/administer-federation/secret.md b/docs/tasks/administer-federation/secret.md index c4ea460fb5..2cd9aa26ea 100644 --- a/docs/tasks/administer-federation/secret.md +++ b/docs/tasks/administer-federation/secret.md @@ -1,8 +1,5 @@ --- title: Federated Secrets -redirect_from: -- "/docs/user-guide/federation/secrets/" -- "/docs/user-guide/federation/secrets.html" --- This guide explains how to use secrets in Federation control plane. @@ -81,7 +78,7 @@ the federation apiserver instead of sending it to a specific Kubernetes cluster. For example, you can do that using kubectl by running: ```shell -kubectl --context=federation-cluster delete secret mysecret +kubectl --context=federation-cluster delete secret mysecret ``` Note that at this point, deleting a federated secret will not delete the diff --git a/docs/tasks/configure-pod-container/assign-cpu-ram-container.md b/docs/tasks/configure-pod-container/assign-cpu-ram-container.md index 0f7dcf3185..8208c934b5 100644 --- a/docs/tasks/configure-pod-container/assign-cpu-ram-container.md +++ b/docs/tasks/configure-pod-container/assign-cpu-ram-container.md @@ -113,7 +113,7 @@ For information about what happens if you don't specify CPU and RAM requests, se {% capture whatsnext %} * Learn more about [managing compute resources](/docs/concepts/configuration/manage-compute-resources-container/). -* See [ResourceRequirements](/docs/api-reference/v1.6/#resourcerequirements-v1-core). +* See [ResourceRequirements](/docs/api-reference/{{page.version}}/#resourcerequirements-v1-core). {% endcapture %} diff --git a/docs/tasks/configure-pod-container/assign-pods-nodes.md b/docs/tasks/configure-pod-container/assign-pods-nodes.md index 29dc7b6b3f..de002421eb 100644 --- a/docs/tasks/configure-pod-container/assign-pods-nodes.md +++ b/docs/tasks/configure-pod-container/assign-pods-nodes.md @@ -1,8 +1,5 @@ --- title: Assign Pods to Nodes -redirect_from: -- "/docs/tasks/administer-cluster/assign-pods-nodes/" -- "/docs/tasks/administer-cluster/assign-pods-nodes.html" --- {% capture overview %} diff --git a/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md b/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md index 84451b06f2..bac9c7fe4e 100644 --- a/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md +++ b/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md @@ -84,10 +84,10 @@ unless the Pod's grace period expires. For more details, see ### Reference - -* [Lifecycle](/docs/resources-reference/v1.6/#lifecycle-v1-core) -* [Container](/docs/resources-reference/v1.6/#container-v1-core) -* See `terminationGracePeriodSeconds` in [PodSpec](/docs/resources-reference/v1.6/#podspec-v1-core) + +* [Lifecycle](/docs/resources-reference/{{page.version}}/#lifecycle-v1-core) +* [Container](/docs/resources-reference/{{page.version}}/#container-v1-core) +* See `terminationGracePeriodSeconds` in [PodSpec](/docs/resources-reference/{{page.version}}/#podspec-v1-core) {% endcapture %} diff --git a/docs/tasks/configure-pod-container/configmap.md b/docs/tasks/configure-pod-container/configmap.md index a82740a0d9..4cc1f7d191 100644 --- a/docs/tasks/configure-pod-container/configmap.md +++ b/docs/tasks/configure-pod-container/configmap.md @@ -3,9 +3,6 @@ assignees: - eparis - pmorie title: Configure Containers Using a ConfigMap -redirect_from: -- "/docs/user-guide/configmap/index/" -- "/docs/user-guide/configmap/index.html" --- @@ -24,7 +21,7 @@ This page shows you how to configure an application using a ConfigMap. ConfigMap {% capture steps %} -## Use kubectl to create a ConfigMap +## Use kubectl to create a ConfigMap Use the `kubectl create configmap` command to create configmaps from [directories](#creating-configmaps-from-directories), [files](#creating-configmaps-from-files), or [literal values](#creating-configmaps-from-literal-values): @@ -33,17 +30,17 @@ kubectl create configmap ``` where \ is the name you want to assign to the ConfigMap and \ is the directory, file, or literal value to draw the data from. - + The data source corresponds to a key-value pair in the ConfigMap, where -* key = the file name or the key you provided on the command line, and +* key = the file name or the key you provided on the command line, and * value = the file contents or the literal value you provided on the command line. - + You can use [`kubectl describe`](/docs/user-guide/kubectl/v1.6/#describe) or [`kubectl get`](/docs/user-guide/kubectl/v1.6/#get) to retrieve information about a ConfigMap. The former shows a summary of the ConfigMap, while the latter returns the full contents of the ConfigMap. ### Create ConfigMaps from directories -You can use `kubectl create configmap` to create a ConfigMap from multiple files in the same directory. +You can use `kubectl create configmap` to create a ConfigMap from multiple files in the same directory. For example: @@ -110,10 +107,10 @@ metadata: You can use `kubectl create configmap` to create a ConfigMap from an individual file, or from multiple files. -For example, +For example, ```shell -kubectl create configmap game-config-2 --from-file=docs/user-guide/configmap/kubectl/game.properties +kubectl create configmap game-config-2 --from-file=docs/user-guide/configmap/kubectl/game.properties ``` would produce the following ConfigMap: @@ -131,9 +128,9 @@ game.properties: 158 bytes ``` You can pass in the `--from-file` argument multiple times to create a ConfigMap from multiple data sources. - + ```shell -kubectl create configmap game-config-2 --from-file=docs/user-guide/configmap/kubectl/game.properties --from-file=docs/user-guide/configmap/kubectl/ui.properties +kubectl create configmap game-config-2 --from-file=docs/user-guide/configmap/kubectl/game.properties --from-file=docs/user-guide/configmap/kubectl/ui.properties ``` ```shell @@ -158,8 +155,8 @@ kubectl create configmap game-config-3 --from-file== ``` where `` is the key you want to use in the ConfigMap and `` is the location of the data source file you want the key to represent. - -For example: + +For example: ```shell kubectl create configmap game-config-3 --from-file=game-special-key=docs/user-guide/configmap/kubectl/game.properties @@ -221,12 +218,12 @@ metadata: {% capture discussion %} -## Understanding ConfigMaps +## Understanding ConfigMaps -ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable. +ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable. The ConfigMap API resource stores configuration data as key-value pairs. The data can be consumed in pods or provide the configurations for system components such as controllers. ConfigMap is similar to [Secrets](/docs/concepts/configuration/secret/), but provides a means of working with strings that don't contain sensitive information. Users and system components alike can store configuration data in ConfigMap. -Note: ConfigMaps should reference properties files, not replace them. Think of the ConfigMap as representing something similar to the a Linux `/etc` directory and its contents. For example, if you create a [Kubernetes Volume](/docs/concepts/storage/volumes/) from a ConfigMap, each data item in the ConfigMap is represented by an individual file in the volume. +Note: ConfigMaps should reference properties files, not replace them. Think of the ConfigMap as representing something similar to the a Linux `/etc` directory and its contents. For example, if you create a [Kubernetes Volume](/docs/concepts/storage/volumes/) from a ConfigMap, each data item in the ConfigMap is represented by an individual file in the volume. The ConfigMap's `data` field contains the configuration data. As shown in the example below, this can be simple -- like individual properties defined using `--from-literal` -- or complex -- like configuration files or JSON blobs defined using `--from-file`. diff --git a/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md b/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md index 3d75725c91..4dc47cc5a6 100644 --- a/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md +++ b/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md @@ -1,7 +1,4 @@ --- -redirect_from: -- "/docs/user-guide/liveness/" -- "/docs/user-guide.liveness.html" title: Configure Liveness and Readiness Probes --- @@ -199,7 +196,7 @@ will be restarted. ## Use a named port You can use a named -[ContainerPort](/docs/api-reference/v1.6/#containerport-v1-core) +[ContainerPort](/docs/api-reference/{{page.version}}/#containerport-v1-core) for HTTP or TCP liveness checks: ```yaml @@ -250,7 +247,7 @@ for it, and that containers are restarted when they fail. Eventually, some of this section could be moved to a concept topic. {% endcomment %} -[Probes](/docs/api-reference/v1.6/#probe-v1-core) have a number of fields that +[Probes](/docs/api-reference/{{page.version}}/#probe-v1-core) have a number of fields that you can use to more precisely control the behavior of liveness and readiness checks: @@ -266,7 +263,7 @@ liveness. Minimum value is 1. * `failureThreshold`: Minimum consecutive failures for the probe to be considered failed after having succeeded. Defaults to 3. Minimum value is 1. -[HTTP probes](/docs/api-reference/v1.6/#httpgetaction-v1-core) +[HTTP probes](/docs/api-reference/{{page.version}}/#httpgetaction-v1-core) have additional fields that can be set on `httpGet`: * `host`: Host name to connect to, defaults to the pod IP. You probably want to @@ -295,9 +292,9 @@ you should not use `host`, but rather set the `Host` header in `httpHeaders`. ### Reference -* [Pod](/docs/api-reference/v1.6/#pod-v1-core) -* [Container](/docs/api-reference/v1.6/#container-v1-core) -* [Probe](/docs/api-reference/v1.6/#probe-v1-core) +* [Pod](/docs/api-reference/{{page.version}}/#pod-v1-core) +* [Container](/docs/api-reference/{{page.version}}/#container-v1-core) +* [Probe](/docs/api-reference/{{page.version}}/#probe-v1-core) {% endcapture %} diff --git a/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md b/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md index 1d8503caac..f4170b7a41 100644 --- a/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md +++ b/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md @@ -1,8 +1,5 @@ --- title: Configure a Pod to Use a PersistentVolume for Storage -redirect_from: -- "/docs/user-guide/persistent-volumes/walkthrough/" -- "/docs/user-guide/persistent-volumes/walkthrough.html" --- {% capture overview %} @@ -57,7 +54,7 @@ PersistentVolume uses a file or directory on the Node to emulate network-attache In a production cluster, you would not use hostPath. Instead a cluster administrator would provision a network resource like a Google Compute Engine persistent disk, an NFS share, or an Amazon Elastic Block Store volume. Cluster administrators can also -use [StorageClasses](/docs/resources-reference/v1.6/#storageclass-v1-storage) +use [StorageClasses](/docs/resources-reference/{{page.version}}/#storageclass-v1-storage) to set up [dynamic provisioning](http://blog.kubernetes.io/2016/10/dynamic-provisioning-and-storage-in-kubernetes.html). @@ -202,10 +199,10 @@ PersistentVolume are not present on the Pod resource itself. ### Reference -* [PersistentVolume](/docs/resources-reference/v1.6/#persistentvolume-v1-core) -* [PersistentVolumeSpec](/docs/resources-reference/v1.6/#persistentvolumespec-v1-core) -* [PersistentVolumeClaim](/docs/resources-reference/v1.6/#persistentvolumeclaim-v1-core) -* [PersistentVolumeClaimSpec](/docs/resources-reference/v1.6/#persistentvolumeclaimspec-v1-core) +* [PersistentVolume](/docs/resources-reference/{{page.version}}/#persistentvolume-v1-core) +* [PersistentVolumeSpec](/docs/resources-reference/{{page.version}}/#persistentvolumespec-v1-core) +* [PersistentVolumeClaim](/docs/resources-reference/{{page.version}}/#persistentvolumeclaim-v1-core) +* [PersistentVolumeClaimSpec](/docs/resources-reference/{{page.version}}/#persistentvolumeclaimspec-v1-core) {% endcapture %} diff --git a/docs/tasks/configure-pod-container/configure-pod-configmap.md b/docs/tasks/configure-pod-container/configure-pod-configmap.md index ef8c84ef66..e4c523d33f 100644 --- a/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -119,8 +119,8 @@ Note: This functionality is available to users running Kubernetes v1.6 and later name: special-config namespace: default data: - special_level: very - special_type: charm + SPECIAL_LEVEL: very + SPECIAL_TYPE: charm ``` 1. Use `env-from` to define all of the ConfigMap's data as Pod environment variables. The key from the ConfigMap becomes the environment variable name in the Pod. @@ -138,7 +138,7 @@ Note: This functionality is available to users running Kubernetes v1.6 and later envFrom: - configMapRef: name: special-config - restartPolicy: Never + restartPolicy: Never ``` 1. Save the changes to the Pod specification. Now, the Pod's output includes `SPECIAL_LEVEL=very` and `SPECIAL_TYPE=charm`. @@ -167,12 +167,12 @@ spec: valueFrom: configMapKeyRef: name: special-config - key: special.how + key: special_level - name: SPECIAL_TYPE_KEY valueFrom: configMapKeyRef: name: special-config - key: special.type + key: special_type restartPolicy: Never ``` diff --git a/docs/tasks/configure-pod-container/configure-projected-volume-storage.md b/docs/tasks/configure-pod-container/configure-projected-volume-storage.md index 896a96acc5..8a3a1505b0 100644 --- a/docs/tasks/configure-pod-container/configure-projected-volume-storage.md +++ b/docs/tasks/configure-pod-container/configure-projected-volume-storage.md @@ -3,10 +3,6 @@ assignees: - jpeeler - pmorie title: Configure a Pod to Use a Projected Volume for Storage -redirect_from: -- "/docs/tasks/configure-pod-container/projected-volume/" -- "/docs/user-guide/projected-volume/" -- "/docs/user-guide/projected-volume/index.html" --- {% capture overview %} diff --git a/docs/tasks/configure-pod-container/configure-service-account.md b/docs/tasks/configure-pod-container/configure-service-account.md index 4c8aecf290..2909ca9984 100644 --- a/docs/tasks/configure-pod-container/configure-service-account.md +++ b/docs/tasks/configure-pod-container/configure-service-account.md @@ -4,9 +4,6 @@ assignees: - liggitt - thockin title: Configure Service Accounts for Pods -redirect_from: -- "/docs/user-guide/service-accounts/" -- "/docs/user-guide/service-accounts.html" --- A service account provides an identity for processes that run in a Pod. @@ -134,7 +131,7 @@ apiVersion: v1 kind: Secret metadata: name: build-robot-secret - annotations: + annotations: kubernetes.io/service-account.name: build-robot type: kubernetes.io/service-account-token EOF @@ -147,7 +144,7 @@ Now you can confirm that the newly built secret is populated with an API token f Any tokens for non-existent service accounts will be cleaned up by the token controller. ```shell -$ kubectl describe secrets/build-robot-secret +$ kubectl describe secrets/build-robot-secret Name: build-robot-secret Namespace: default Labels: diff --git a/docs/tasks/configure-pod-container/configure-volume-storage.md b/docs/tasks/configure-pod-container/configure-volume-storage.md index a0374272e1..7fad341494 100644 --- a/docs/tasks/configure-pod-container/configure-volume-storage.md +++ b/docs/tasks/configure-pod-container/configure-volume-storage.md @@ -82,7 +82,7 @@ you will see something like this: At this point, the Container has terminated and restarted. This is because the redis Pod has a -[restartPolicy](/docs/api-reference/v1.6/#podspec-v1-core) +[restartPolicy](/docs/api-reference/{{page.version}}/#podspec-v1-core) of `Always`. 1. Get a shell into the restarted Container: @@ -95,9 +95,9 @@ of `Always`. {% capture whatsnext %} -* See [Volume](/docs/api-reference/v1.6/#volume-v1-core). +* See [Volume](/docs/api-reference/{{page.version}}/#volume-v1-core). -* See [Pod](/docs/api-reference/v1.6/#pod-v1-core). +* See [Pod](/docs/api-reference/{{page.version}}/#pod-v1-core). * In addition to the local disk storage provided by `emptyDir`, Kubernetes supports many different network-attached storage solutions, including PD on diff --git a/docs/tasks/configure-pod-container/pull-image-private-registry.md b/docs/tasks/configure-pod-container/pull-image-private-registry.md index 6504824873..ef2058e3ab 100644 --- a/docs/tasks/configure-pod-container/pull-image-private-registry.md +++ b/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -42,7 +42,7 @@ The output contains a section similar to this: } } } - + NOTE: If you use a Docker credentials store, you won't see that `auth` entry but a `credsStore` entry with the name of the store as value. ## Create a Secret that holds your authorization token @@ -127,9 +127,9 @@ Create a Pod that uses your Secret, and verify that the Pod is running: * Learn more about [using a private registry](/docs/concepts/containers/images/#using-a-private-registry). * See [kubectl create secret docker-registry](/docs/user-guide/kubectl/v1.6/#-em-secret-docker-registry-em-). -* See [Secret](/docs/api-reference/v1.6/#secret-v1-core) +* See [Secret](/docs/api-reference/{{page.version}}/#secret-v1-core) * See the `imagePullSecrets` field of -[PodSpec](/docs/api-reference/v1.6/#podspec-v1-core). +[PodSpec](/docs/api-reference/{{page.version}}/#podspec-v1-core). {% endcapture %} diff --git a/docs/tasks/configure-pod-container/security-context.md b/docs/tasks/configure-pod-container/security-context.md index fe00e519c4..00e3584e3a 100644 --- a/docs/tasks/configure-pod-container/security-context.md +++ b/docs/tasks/configure-pod-container/security-context.md @@ -4,9 +4,6 @@ assignees: - mikedanese - thockin title: Configure a Security Context for a Pod or Container -redirect_from: -- "/docs/user-guide/security-context/" -- "/docs/concepts/policy/container-capabilities/" --- {% capture overview %} @@ -44,7 +41,7 @@ For more information about security mechanisms in Linux, see To specify security settings for a Pod, include the `securityContext` field in the Pod specification. The `securityContext` field is a -[PodSecurityContext](/docs/api-reference/v1.6/#podsecuritycontext-v1-core) object. +[PodSecurityContext](/docs/api-reference/{{page.version}}/#podsecuritycontext-v1-core) object. The security settings that you specify for a Pod apply to all Containers in the Pod. Here is a configuration file for a Pod that has a `securityContext` and an `emptyDir` volume: @@ -80,9 +77,7 @@ In your shell, list the running processes: ps aux ``` -The output shows that the processes are running as user 1000, which isithub.io - 68dc8932..69f5ba31 qos-experiment -> qos-experi -the value of `runAsUser`: +The output shows that the processes are running as user 1000, which is the value of `runAsUser`: ```shell USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND @@ -134,7 +129,7 @@ exit To specify security settings for a Container, include the `securityContext` field in the Container manifest. The `securityContext` field is a -[SecurityContext](/docs/api-reference/v1.6/#securitycontext-v1-core) object. +[SecurityContext](/docs/api-reference/{{page.version}}/#securitycontext-v1-core) object. Security settings that you specify for a Container apply only to the individual Container, and they override settings made at the Pod level when there is overlap. Container settings do not affect the Pod's Volumes. @@ -291,7 +286,7 @@ Compare the capabilities of the two Containers: ``` 00000000a80425fb -00000000aa0435fb +00000000aa0435fb ``` In the capability bitmap of the first container, bits 12 and 25 are clear. In the second container, @@ -308,7 +303,7 @@ to add `CAP_SYS_TIME`, include `SYS_TIME` in your list of capabilities. To assign SELinux labels to a Container, include the `seLinuxOptions` field in the `securityContext` section of your Pod or Container manifest. The `seLinuxOptions` field is an -[SELinuxOptions](/docs/api-reference/v1.6/#selinuxoptions-v1-core) +[SELinuxOptions](/docs/api-reference/{{page.version}}/#selinuxoptions-v1-core) object. Here's an example that applies an SELinux level: ```yaml @@ -346,8 +341,8 @@ protection, you must ensure each Pod is assigned a unique MCS label. {% capture whatsnext %} -* [PodSecurityContext](/docs/api-reference/v1.6/#podsecuritycontext-v1-core) -* [SecurityContext](/docs/api-reference/v1.6/#securitycontext-v1-core) +* [PodSecurityContext](/docs/api-reference/{{page.version}}/#podsecuritycontext-v1-core) +* [SecurityContext](/docs/api-reference/{{page.version}}/#securitycontext-v1-core) * [Tuning Docker with the newest security enhancements](https://opensource.com/business/15/3/docker-security-tuning) * [Security Contexts design document](https://git.k8s.io/community/contributors/design-proposals/security_context.md) * [Ownership Management design document](https://git.k8s.io/community/contributors/design-proposals/volume-ownership-management.md) diff --git a/docs/tasks/debug-application-cluster/audit.md b/docs/tasks/debug-application-cluster/audit.md index 81352d0324..b67194a5d8 100644 --- a/docs/tasks/debug-application-cluster/audit.md +++ b/docs/tasks/debug-application-cluster/audit.md @@ -4,11 +4,6 @@ assignees: - sttts - ericchiang title: Auditing -redirect_from: -- "/docs/admin/audit/" -- "/docs/admin/audit.html" -- "/docs/concepts/cluster-administration/audit/" -- "/docs/concepts/cluster-administration/audit.html" --- * TOC diff --git a/docs/tasks/debug-application-cluster/debug-application-introspection.md b/docs/tasks/debug-application-cluster/debug-application-introspection.md index 8004407d3d..656a2f8fa5 100644 --- a/docs/tasks/debug-application-cluster/debug-application-introspection.md +++ b/docs/tasks/debug-application-cluster/debug-application-introspection.md @@ -3,9 +3,6 @@ assignees: - janetkuo - thockin title: Application Introspection and Debugging -redirect_from: -- "/docs/user-guide/introspection-and-debugging/" -- "/docs/user-guide/introspection-and-debugging.html" --- Once your application is running, you'll inevitably need to debug problems with it. @@ -90,7 +87,7 @@ Containers: Environment Variables: Conditions: Type Status - Ready True + Ready True Volumes: default-token-4bcbi: Type: Secret (a volume populated by a Secret) @@ -140,7 +137,7 @@ $ kubectl describe pod nginx-deployment-1370807587-fz9sd Node: / Labels: app=nginx,pod-template-hash=1370807587 Status: Pending - IP: + IP: Controllers: ReplicaSet/nginx-deployment-1370807587 Containers: nginx: @@ -278,7 +275,7 @@ Labels: kubernetes.io/hostname=kubernetes-node-861h CreationTimestamp: Fri, 10 Jul 2015 14:32:29 -0700 Conditions: Type Status LastHeartbeatTime LastTransitionTime Reason Message - Ready Unknown Fri, 10 Jul 2015 14:34:32 -0700 Fri, 10 Jul 2015 14:35:15 -0700 Kubelet stopped posting node status. + Ready Unknown Fri, 10 Jul 2015 14:34:32 -0700 Fri, 10 Jul 2015 14:35:15 -0700 Kubelet stopped posting node status. Addresses: 10.240.115.55,104.197.0.26 Capacity: cpu: 1 diff --git a/docs/tasks/debug-application-cluster/debug-application.md b/docs/tasks/debug-application-cluster/debug-application.md index 543d1145f0..86d66ffe93 100644 --- a/docs/tasks/debug-application-cluster/debug-application.md +++ b/docs/tasks/debug-application-cluster/debug-application.md @@ -3,9 +3,6 @@ assignees: - mikedanese - thockin title: Troubleshoot Applications -redirect_from: -- "/docs/user-guide/application-troubleshooting/" -- "/docs/user-guide/application-troubleshooting.html" --- This guide is to help users debug applications that are deployed into Kubernetes and not behaving correctly. diff --git a/docs/tasks/debug-application-cluster/debug-cluster.md b/docs/tasks/debug-application-cluster/debug-cluster.md index 7322ccdcd9..88a06b7074 100644 --- a/docs/tasks/debug-application-cluster/debug-cluster.md +++ b/docs/tasks/debug-application-cluster/debug-cluster.md @@ -2,14 +2,11 @@ assignees: - davidopp title: Troubleshoot Clusters -redirect_from: -- "/docs/admin/cluster-troubleshooting/" -- "/docs/admin/cluster-troubleshooting.html" --- This doc is about cluster troubleshooting; we assume you have already ruled out your application as the root cause of the problem you are experiencing. See -the [application troubleshooting guide]/docs/tasks/debug-application-cluster/debug-application) for tips on application debugging. +the [application troubleshooting guide](/docs/tasks/debug-application-cluster/debug-application) for tips on application debugging. You may also visit [troubleshooting document](/docs/troubleshooting/) for more information. ## Listing your cluster diff --git a/docs/tasks/debug-application-cluster/debug-init-containers.md b/docs/tasks/debug-application-cluster/debug-init-containers.md index 913023649b..1100c40025 100644 --- a/docs/tasks/debug-application-cluster/debug-init-containers.md +++ b/docs/tasks/debug-application-cluster/debug-init-containers.md @@ -8,9 +8,6 @@ assignees: - kow3ns - smarterclayton title: Debug Init Containers -redirect_from: -- "/docs/tasks/troubleshoot/debug-init-containers/" -- "/docs/tasks/troubleshoot/debug-init-containers.html" --- {% capture overview %} @@ -28,7 +25,7 @@ Init Containers. The example command lines below refer to the Pod as * You should be familiar with the basics of [Init Containers](/docs/concepts/abstractions/init-containers/). -* You should have [Configured an Init Container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/). +* You should have [Configured an Init Container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/). {% endcapture %} diff --git a/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md index 8c0c8e2e5e..6644f9a8cc 100644 --- a/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md +++ b/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md @@ -2,9 +2,6 @@ assignees: - bprashanth title: Debug Pods and Replication Controllers -redirect_from: -- "/docs/user-guide/debugging-pods-and-replication-controllers/" -- "/docs/user-guide/debugging-pods-and-replication-controllers.html" --- * TOC diff --git a/docs/tasks/debug-application-cluster/debug-service.md b/docs/tasks/debug-application-cluster/debug-service.md index 981225f55c..08db4fa1a2 100644 --- a/docs/tasks/debug-application-cluster/debug-service.md +++ b/docs/tasks/debug-application-cluster/debug-service.md @@ -4,9 +4,6 @@ assignees: - janetkuo - thockin title: Debug Services -redirect_from: -- "/docs/user-guide/debugging-services/" -- "/docs/user-guide/debugging-services.html" --- An issue that comes up rather frequently for new installations of Kubernetes is @@ -86,7 +83,7 @@ $ kubectl run hostnames --image=gcr.io/google_containers/serve_hostname \ deployment "hostnames" created ``` -`kubectl` commands will print the type and name of the resource created or mutated, which can then be used in subsequent commands. +`kubectl` commands will print the type and name of the resource created or mutated, which can then be used in subsequent commands. Note that this is the same as if you had started the `Deployment` with the following YAML: diff --git a/docs/tasks/debug-application-cluster/debug-stateful-set.md b/docs/tasks/debug-application-cluster/debug-stateful-set.md index 0dc1fdbbf1..2b0c52e0e7 100644 --- a/docs/tasks/debug-application-cluster/debug-stateful-set.md +++ b/docs/tasks/debug-application-cluster/debug-stateful-set.md @@ -8,9 +8,6 @@ assignees: - kow3ns - smarterclayton title: Debug a StatefulSet -redirect_from: -- "/docs/tasks/manage-stateful-set/debugging-a-statefulset/" -- "/docs/tasks/manage-stateful-set/debugging-a-statefulset.html" --- {% capture overview %} @@ -22,7 +19,7 @@ This task shows you how to debug a StatefulSet. {% capture prerequisites %} -* You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. +* You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. * You should have a StatefulSet running that you want to investigate. {% endcapture %} @@ -31,13 +28,13 @@ This task shows you how to debug a StatefulSet. ## Debugging a StatefulSet -In order to list all the pods which belong to a StatefulSet, which have a label `app=myapp` set on them, you can use the following: +In order to list all the pods which belong to a StatefulSet, which have a label `app=myapp` set on them, you can use the following: ```shell kubectl get pods -l app=myapp ``` -If you find that any Pods listed are in `Unknown` or `Terminating` state for an extended period of time, refer to the [Deleting StatefulSet Pods](/docs/tasks/manage-stateful-set/delete-pods/) task for instructions on how to deal with them. You can debug individual Pods in a StatefulSet using the [Debugging Pods](/docs/user-guide/debugging-pods-and-replication-controllers/#debugging-pods) guide. +If you find that any Pods listed are in `Unknown` or `Terminating` state for an extended period of time, refer to the [Deleting StatefulSet Pods](/docs/tasks/manage-stateful-set/delete-pods/) task for instructions on how to deal with them. You can debug individual Pods in a StatefulSet using the [Debugging Pods](/docs/user-guide/debugging-pods-and-replication-controllers/#debugging-pods) guide. StatefulSets provide a debug mechanism to pause all controller operations on Pods using an annotation. Setting the `pod.alpha.kubernetes.io/initialized` annotation to `"false"` on any StatefulSet Pod will *pause* all operations of the StatefulSet. When paused, the StatefulSet will not perform any scaling operations. Once the debug hook is set, you can execute commands within the containers of StatefulSet pods without interference from scaling operations. You can set the annotation to `"false"` by executing the following: @@ -45,11 +42,11 @@ StatefulSets provide a debug mechanism to pause all controller operations on Pod kubectl annotate pods pod.alpha.kubernetes.io/initialized="false" --overwrite ``` -When the annotation is set to `"false"`, the StatefulSet will not respond to its Pods becoming unhealthy or unavailable. It will not create replacement Pods till the annotation is removed or set to `"true"` on each StatefulSet Pod. +When the annotation is set to `"false"`, the StatefulSet will not respond to its Pods becoming unhealthy or unavailable. It will not create replacement Pods till the annotation is removed or set to `"true"` on each StatefulSet Pod. ### Step-wise Initialization -You can also use the same annotation to debug race conditions during bootstrapping of the StatefulSet by setting the `pod.alpha.kubernetes.io/initialized` annotation to `"false"` in the `.spec.template.metadata.annotations` field of the StatefulSet prior to creating it. +You can also use the same annotation to debug race conditions during bootstrapping of the StatefulSet by setting the `pod.alpha.kubernetes.io/initialized` annotation to `"false"` in the `.spec.template.metadata.annotations` field of the StatefulSet prior to creating it. ```yaml apiVersion: apps/v1beta1 @@ -67,12 +64,12 @@ spec: pod.alpha.kubernetes.io/initialized: "false" ... ... -... +... ``` After setting the annotation, if you create the StatefulSet, you can wait for each Pod to come up and verify that it has initialized correctly. The StatefulSet will not create any subsequent Pods till the debug annotation is set to `"true"` (or removed) on each Pod that has already been created. You can set the annotation to `"true"` by executing the following: - + ```shell kubectl annotate pods pod.alpha.kubernetes.io/initialized="true" --overwrite ``` diff --git a/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md b/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md index 770b676f61..15932527ae 100644 --- a/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md +++ b/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md @@ -100,7 +100,7 @@ Set `terminationMessagePath` as shown here: {% capture whatsnext %} * See the `terminationMessagePath` field in - [Container](/docs/api-reference/v1.6/#container-v1-core). + [Container](/docs/api-reference/{{page.version}}/#container-v1-core). * Learn about [retrieving logs](/docs/concepts/cluster-administration/logging/). * Learn about [Go templates](https://golang.org/pkg/text/template/). diff --git a/docs/tasks/debug-application-cluster/get-shell-running-container.md b/docs/tasks/debug-application-cluster/get-shell-running-container.md index 627eec5c15..5b2eae35f2 100644 --- a/docs/tasks/debug-application-cluster/get-shell-running-container.md +++ b/docs/tasks/debug-application-cluster/get-shell-running-container.md @@ -3,11 +3,6 @@ assignees: - caesarxuchao - mikedanese title: Get a Shell to a Running Container -redirect_from: -- "/docs/user-guide/getting-into-containers/" -- "/docs/user-guide/getting-into-containers.html" -- "/docs/tasks/kubectl/get-shell-running-container/" -- "/docs/tasks/kubectl/get-shell-running-container.html" --- {% capture overview %} diff --git a/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md b/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md index f369ce8c98..41fb8f43d9 100644 --- a/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md +++ b/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md @@ -3,9 +3,6 @@ assignees: - crassirostris - piosz title: Logging Using Elasticsearch and Kibana -redirect_from: -- "/docs/user-guide/logging/elasticsearch/" -- "/docs/user-guide/logging/elasticsearch.html" --- On the Google Compute Engine (GCE) platform, the default logging support targets diff --git a/docs/tasks/debug-application-cluster/logging-stackdriver.md b/docs/tasks/debug-application-cluster/logging-stackdriver.md index b9b4b77426..fb41d68082 100644 --- a/docs/tasks/debug-application-cluster/logging-stackdriver.md +++ b/docs/tasks/debug-application-cluster/logging-stackdriver.md @@ -3,9 +3,6 @@ assignees: - crassirostris - piosz title: Logging Using Stackdriver -redirect_from: -- "/docs/user-guide/logging/stackdriver/" -- "/docs/user-guide/logging/stackdriver.html" --- Before reading this page, it's highly recommended to familiarize yourself @@ -304,7 +301,7 @@ Get the current version of the Stackdriver Logging `ConfigMap` in your cluster by running the following command: ```shell -kubectl get ds fluentd-gcp-v2.0 --namespace kube-system -o yaml > fluentd-gcp-ds.yaml +kubectl get cm fluentd-gcp-config --namespace kube-system -o yaml > fluentd-gcp-configmap.yaml ``` Then in the value for the key `containers.input.conf` insert a new filter right after diff --git a/docs/tasks/debug-application-cluster/monitor-node-health.md b/docs/tasks/debug-application-cluster/monitor-node-health.md index 49e2a2f0c9..917514f4c6 100644 --- a/docs/tasks/debug-application-cluster/monitor-node-health.md +++ b/docs/tasks/debug-application-cluster/monitor-node-health.md @@ -3,9 +3,6 @@ assignees: - Random-Liu - dchen1107 title: Monitor Node Health -redirect_from: -- "/docs/admin/node-problem/" -- "/docs/admin/node-problem.html" --- * TOC @@ -16,7 +13,7 @@ redirect_from: *Node problem detector* is a [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) monitoring the node health. It collects node problems from various daemons and reports them to the apiserver as [NodeCondition](/docs/concepts/architecture/nodes/#condition) -and [Event](/docs/api-reference/v1.6/#event-v1-core). +and [Event](/docs/api-reference/{{page.version}}/#event-v1-core). It supports some known kernel issue detection now, and will detect more and more node problems over time. @@ -248,4 +245,4 @@ resource overhead on each node. Usually this is fine, because: * The kernel log is generated relatively slowly. * Resource limit is set for node problem detector. * Even under high load, the resource usage is acceptable. -(see [benchmark result](https://github.com/kubernetes/node-problem-detector/issues/2#issuecomment-220255629)) +(see [benchmark result](https://github.com/kubernetes/node-problem-detector/issues/2#issuecomment-220255629)) diff --git a/docs/tasks/debug-application-cluster/resource-usage-monitoring.md b/docs/tasks/debug-application-cluster/resource-usage-monitoring.md index f6424f8596..e23382df52 100644 --- a/docs/tasks/debug-application-cluster/resource-usage-monitoring.md +++ b/docs/tasks/debug-application-cluster/resource-usage-monitoring.md @@ -2,11 +2,6 @@ assignees: - mikedanese title: Tools for Monitoring Compute, Storage, and Network Resources -redirect_from: -- "/docs/user-guide/monitoring/" -- "/docs/user-guide/monitoring.html" -- "/docs/concepts/cluster-administration/resource-usage-monitoring/" -- "/docs/concepts/cluster-administration/resource-usage-monitoring.html" --- Understanding how an application behaves when deployed is crucial to scaling the application and providing a reliable service. In a Kubernetes cluster, application performance can be examined at many different levels: containers, [pods](/docs/user-guide/pods), [services](/docs/user-guide/services), and whole clusters. As part of Kubernetes we want to provide users with detailed resource usage information about their running applications at all these levels. This will give users deep insights into how their applications are performing and where possible application bottlenecks may be found. In comes [Heapster](https://github.com/kubernetes/heapster), a project meant to provide a base monitoring platform on Kubernetes. diff --git a/docs/tasks/debug-application-cluster/troubleshooting.md b/docs/tasks/debug-application-cluster/troubleshooting.md index 9253963ff3..a0e7a56196 100644 --- a/docs/tasks/debug-application-cluster/troubleshooting.md +++ b/docs/tasks/debug-application-cluster/troubleshooting.md @@ -3,8 +3,6 @@ assignees: - brendandburns - davidopp title: Troubleshooting -redirect_from: -- "/docs/troubleshooting/" --- Sometimes things go wrong. This guide is aimed at making them right. It has diff --git a/docs/tasks/federation/federation-service-discovery.md b/docs/tasks/federation/federation-service-discovery.md index 03875c3c48..dd5fc97ac1 100644 --- a/docs/tasks/federation/federation-service-discovery.md +++ b/docs/tasks/federation/federation-service-discovery.md @@ -3,11 +3,6 @@ assignees: - bprashanth - quinton-hoole title: Cross-cluster Service Discovery using Federated Services -redirect_from: -- "/docs/user-guide/federation/federated-services/" -- "/docs/user-guide/federation/federated-services.html" -- "/docs/concepts/cluster-administration/federation-service-discovery/" -- "/docs/concepts/cluster-administration/federation-service-discovery.html" --- This guide explains how to use Kubernetes Federated Services to deploy @@ -175,7 +170,7 @@ this. For example, if your Federation is configured to use Google Cloud DNS, and a managed DNS domain 'example.com': ``` shell -$ gcloud dns managed-zones describe example-dot-com +$ gcloud dns managed-zones describe example-dot-com creationTime: '2016-06-26T18:18:39.229Z' description: Example domain for Kubernetes Cluster Federation dnsName: example.com. diff --git a/docs/tasks/federation/set-up-cluster-federation-kubefed.md b/docs/tasks/federation/set-up-cluster-federation-kubefed.md index cd2c39c656..114d54b735 100644 --- a/docs/tasks/federation/set-up-cluster-federation-kubefed.md +++ b/docs/tasks/federation/set-up-cluster-federation-kubefed.md @@ -2,11 +2,6 @@ assignees: - madhusudancs title: Set up Cluster Federation with Kubefed -redirect_from: -- "/docs/admin/federation/kubefed/" -- "/docs/admin/federation/kubefed.html" -- "/docs/tutorials/federation/set-up-cluster-federation-kubefed/" -- "/docs/tutorials/federation/set-up-cluster-federation-kubefed.html" --- * TOC diff --git a/docs/tasks/federation/set-up-coredns-provider-federation.md b/docs/tasks/federation/set-up-coredns-provider-federation.md index 6a22b2b4ef..1161cefc9c 100644 --- a/docs/tasks/federation/set-up-coredns-provider-federation.md +++ b/docs/tasks/federation/set-up-coredns-provider-federation.md @@ -1,8 +1,5 @@ --- title: Set up CoreDNS as DNS provider for Cluster Federation -redirect_from: -- "/docs/tutorials/federation/set-up-coredns-provider-federation/" -- "/docs/tutorials/federation/set-up-coredns-provider-federation.html" --- {% capture overview %} diff --git a/docs/tasks/federation/set-up-placement-policies-federation.md b/docs/tasks/federation/set-up-placement-policies-federation.md index 5ed3fceadf..a5dd281593 100644 --- a/docs/tasks/federation/set-up-placement-policies-federation.md +++ b/docs/tasks/federation/set-up-placement-policies-federation.md @@ -1,8 +1,5 @@ --- title: Set up placement policies in Federation -redirect_from: -- "/docs/tutorials/federation/set-up-placement-policies-federation/" -- "/docs/tutorials/federation/set-up-placement-policies-federation.html" --- {% capture overview %} diff --git a/docs/tasks/index.md b/docs/tasks/index.md index 2921e97d38..86a435eeae 100644 --- a/docs/tasks/index.md +++ b/docs/tasks/index.md @@ -1,10 +1,5 @@ --- title: Tasks -redirect_from: -- "/docs/user-guide/configuring-containers/" -- "/docs/user-guide/configuring-containers.html" -- "/docs/user-guide/production-pods/" -- "/docs/user-guide/production-pods.html" --- This section of the Kubernetes documentation contains pages that diff --git a/docs/tasks/inject-data-application/define-command-argument-container.md b/docs/tasks/inject-data-application/define-command-argument-container.md index 4dc1386c13..c8209d0716 100644 --- a/docs/tasks/inject-data-application/define-command-argument-container.md +++ b/docs/tasks/inject-data-application/define-command-argument-container.md @@ -1,8 +1,5 @@ --- title: Define a Command and Arguments for a Container -redirect_from: -- "/docs/concepts/configuration/container-command-args/" -- "/docs/concepts/configuration/container-command-arg.html" --- {% capture overview %} @@ -134,7 +131,7 @@ Here are some examples: * 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/tasks/kubectl/get-shell-running-container/). -* See [Container](/docs/api-reference/v1.6/#container-v1-core). +* See [Container](/docs/api-reference/{{page.version}}/#container-v1-core). {% endcapture %} diff --git a/docs/tasks/inject-data-application/define-environment-variable-container.md b/docs/tasks/inject-data-application/define-environment-variable-container.md index e58867b205..6010f47624 100644 --- a/docs/tasks/inject-data-application/define-environment-variable-container.md +++ b/docs/tasks/inject-data-application/define-environment-variable-container.md @@ -1,8 +1,5 @@ --- title: Define Environment Variables for a Container -redirect_from: -- "/docs/tasks/configure-pod-container/define-environment-variable-container/" -- "/docs/tasks/configure-pod-container/define-environment-variable-container.html" --- {% capture overview %} @@ -72,7 +69,7 @@ Pod: * Learn more about [environment variables](/docs/tasks/configure-pod-container/environment-variable-expose-pod-information/). * Learn about [using secrets as environment variables](/docs/user-guide/secrets/#using-secrets-as-environment-variables). -* See [EnvVarSource](/docs/api-reference/v1.6/#envvarsource-v1-core). +* See [EnvVarSource](/docs/api-reference/{{page.version}}/#envvarsource-v1-core). {% endcapture %} diff --git a/docs/tasks/inject-data-application/distribute-credentials-secure.md b/docs/tasks/inject-data-application/distribute-credentials-secure.md index 53e4abcf87..219f117e00 100644 --- a/docs/tasks/inject-data-application/distribute-credentials-secure.md +++ b/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -1,10 +1,5 @@ --- title: Distribute Credentials Securely Using Secrets -redirect_from: -- "/docs/user-guide/secrets/walkthrough/" -- "/docs/user-guide/secrets/walkthrough.html" -- "/docs/tasks/configure-pod-container/distribute-credentials-secure/" -- "/docs/tasks/configure-pod-container/distribute-credentials-secure.html" --- {% capture overview %} @@ -47,7 +42,7 @@ username and password: **Note:** If you want to skip the Base64 encoding step, you can create a Secret by using the `kubectl create secret` command: - kubectl create secret generic test-secret --from-literal=username='my-app',password='39528$vdg7Jb' + kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb' 1. View information about the Secret: @@ -167,9 +162,9 @@ Here is a configuration file you can use to create a Pod: ### Reference -* [Secret](/docs/api-reference/v1.6/#secret-v1-core) -* [Volume](/docs/api-reference/v1.6/#volume-v1-core) -* [Pod](/docs/api-reference/v1.6/#pod-v1-core) +* [Secret](/docs/api-reference/{{page.version}}/#secret-v1-core) +* [Volume](/docs/api-reference/{{page.version}}/#volume-v1-core) +* [Pod](/docs/api-reference/{{page.version}}/#pod-v1-core) {% endcapture %} diff --git a/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md b/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md index b6abc3e7f4..606fb99c7d 100644 --- a/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md +++ b/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md @@ -1,12 +1,5 @@ --- title: Expose Pod Information to Containers Through Files -redirect_from: -- "/docs/user-guide/downward-api/" -- "/docs/user-guide/downward-api/index.html" -- "/docs/user-guide/downward-api/volume/" -- "/docs/user-guide/downward-api/volume/index.html" -- "/docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information/" -- "/docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information.html" --- {% capture overview %} @@ -47,10 +40,10 @@ In the configuration file, you can see that the Pod has a `downwardAPI` Volume, and the Container mounts the Volume at `/etc`. Look at the `items` array under `downwardAPI`. Each element of the array is a -[DownwardAPIVolumeFile](/docs/resources-reference/v1.6/#downwardapivolumefile-v1-core). +[DownwardAPIVolumeFile](/docs/resources-reference/{{page.version}}/#downwardapivolumefile-v1-core). The first element specifies that the value of the Pod's `metadata.labels` field should be stored in a file named `labels`. -The second element specifies that the value of the Pod's `annotations` +The second element specifies that the value of the Pod's `annotations` field should be stored in a file named `annotations`. **Note**: The fields in this example are Pod fields. They are not @@ -149,7 +142,7 @@ Exit the shell: ## Store Container fields -The preceding exercise, you stored Pod fields in a DownwardAPIVolumeFile. +The preceding exercise, you stored Pod fields in a DownwardAPIVolumeFile. In this next exercise, you store Container fields. Here is the configuration file for a Pod that has one Container: @@ -162,7 +155,7 @@ Look at the `items` array under `downwardAPI`. Each element of the array is a DownwardAPIVolumeFile. The first element specifies that in the Container named `client-container`, -the value of the `limits.cpu` field +the value of the `limits.cpu` field should be stored in a file named `cpu_limit`. Create the Pod: @@ -238,11 +231,11 @@ inject the Pod's name into the well-known environment variable. {% capture whatsnext %} -* [PodSpec](/docs/resources-reference/v1.6/#podspec-v1-core) -* [Volume](/docs/resources-reference/v1.6/#volume-v1-core) -* [DownwardAPIVolumeSource](/docs/resources-reference/v1.6/#downwardapivolumesource-v1-core) -* [DownwardAPIVolumeFile](/docs/resources-reference/v1.6/#downwardapivolumefile-v1-core) -* [ResourceFieldSelector](/docs/resources-reference/v1.6/#resourcefieldselector-v1-core) +* [PodSpec](/docs/resources-reference/{{page.version}}/#podspec-v1-core) +* [Volume](/docs/resources-reference/{{page.version}}/#volume-v1-core) +* [DownwardAPIVolumeSource](/docs/resources-reference/{{page.version}}/#downwardapivolumesource-v1-core) +* [DownwardAPIVolumeFile](/docs/resources-reference/{{page.version}}/#downwardapivolumefile-v1-core) +* [ResourceFieldSelector](/docs/resources-reference/{{page.version}}/#resourcefieldselector-v1-core) {% endcapture %} diff --git a/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md b/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md index db23b2935f..4934aebb17 100644 --- a/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md +++ b/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md @@ -1,10 +1,5 @@ --- title: Expose Pod Information to Containers Through Environment Variables -redirect_from: -- "/docs/user-guide/environment-guide/" -- "/docs/user-guide/environment-guide/index.html" -- "/docs/tasks/configure-pod-container/environment-variable-expose-pod-information/" -- "/docs/tasks/configure-pod-container/environment-variable-expose-pod-information.html" --- {% capture overview %} @@ -15,7 +10,7 @@ Pod fields and Container fields. There are two ways to expose Pod and Container fields to a running Container: environment variables and -[DownwardAPIVolumeFiles](/docs/resources-reference/v1.6/#downwardapivolumefile-v1-core). +[DownwardAPIVolumeFiles](/docs/resources-reference/{{page.version}}/#downwardapivolumefile-v1-core). Together, these two ways of exposing Pod and Container fields are called the *Downward API*. @@ -36,7 +31,7 @@ Together, these two ways of exposing Pod and Container fields are called the There are two ways to expose Pod and Container fields to a running Container: * Environment variables -* [DownwardAPIVolumeFiles](/docs/resources-reference/v1.6/#downwardapivolumefile-v1-core) +* [DownwardAPIVolumeFiles](/docs/resources-reference/{{page.version}}/#downwardapivolumefile-v1-core) Together, these two ways of exposing Pod and Container fields are called the *Downward API*. @@ -51,7 +46,7 @@ configuration file for the Pod: In the configuration file, you can see five environment variables. The `env` field is an array of -[EnvVars](/docs/resources-reference/v1.6/#envvar-v1-core). +[EnvVars](/docs/resources-reference/{{page.version}}/#envvar-v1-core). The first element in the array specifies that the `MY_NODE_NAME` environment variable gets its value from the Pod's `spec.nodeName` field. Similarly, the other environment variables get their names from Pod fields. @@ -128,7 +123,7 @@ container: In the configuration file, you can see four environment variables. The `env` field is an array of -[EnvVars](/docs/resources-reference/v1.6/#envvar-v1-core). +[EnvVars](/docs/resources-reference/{{page.version}}/#envvar-v1-core). The first element in the array specifies that the `MY_CPU_REQUEST` environment variable gets its value from the `requests.cpu` field of a Container named `test-container`. Similarly, the other environment variables get their values @@ -166,12 +161,12 @@ The output shows the values of selected environment variables: {% capture whatsnext %} * [Defining Environment Variables for a Container](/docs/tasks/configure-pod-container/define-environment-variable-container/) -* [PodSpec](/docs/resources-reference/v1.6/#podspec-v1-core) -* [Container](/docs/resources-reference/v1.6/#container-v1-core) -* [EnvVar](/docs/resources-reference/v1.6/#envvar-v1-core) -* [EnvVarSource](/docs/resources-reference/v1.6/#envvarsource-v1-core) -* [ObjectFieldSelector](/docs/resources-reference/v1.6/#objectfieldselector-v1-core) -* [ResourceFieldSelector](/docs/resources-reference/v1.6/#resourcefieldselector-v1-core) +* [PodSpec](/docs/resources-reference/{{page.version}}/#podspec-v1-core) +* [Container](/docs/resources-reference/{{page.version}}/#container-v1-core) +* [EnvVar](/docs/resources-reference/{{page.version}}/#envvar-v1-core) +* [EnvVarSource](/docs/resources-reference/{{page.version}}/#envvarsource-v1-core) +* [ObjectFieldSelector](/docs/resources-reference/{{page.version}}/#objectfieldselector-v1-core) +* [ResourceFieldSelector](/docs/resources-reference/{{page.version}}/#resourcefieldselector-v1-core) {% endcapture %} diff --git a/docs/tasks/inject-data-application/podpreset.md b/docs/tasks/inject-data-application/podpreset.md index 54af226c79..89222c4076 100644 --- a/docs/tasks/inject-data-application/podpreset.md +++ b/docs/tasks/inject-data-application/podpreset.md @@ -2,11 +2,6 @@ assignees: - jessfraz title: Inject Information into Pods Using a PodPreset -redirect_from: -- "/docs/user-guide/pod-preset/index/" -- "/docs/user-guide/pod-preset/index.html" -- "/docs/tasks/run-application/podpreset/" -- "/docs/tasks/run-application/podpreset.html" --- You can use a `podpreset` object to inject certain information into pods at creation @@ -148,7 +143,7 @@ spec: ### Pod Spec with `ConfigMap` Example -This is an example to show how a Pod spec is modified by the Pod Preset +This is an example to show how a Pod spec is modified by the Pod Preset that defines a `ConfigMap` for Environment Variables. **User submitted pod spec:** @@ -462,7 +457,7 @@ spec: ### Conflict Example -This is an example to show how a Pod spec is not modified by the Pod Preset +This is an example to show how a Pod spec is not modified by the Pod Preset when there is a conflict. **User submitted pod spec:** diff --git a/docs/tasks/job/coarse-parallel-processing-work-queue/index.md b/docs/tasks/job/coarse-parallel-processing-work-queue/index.md index 76694f21a7..7d95beccbd 100644 --- a/docs/tasks/job/coarse-parallel-processing-work-queue/index.md +++ b/docs/tasks/job/coarse-parallel-processing-work-queue/index.md @@ -1,8 +1,5 @@ --- title: Coarse Parallel Processing Using a Work Queue -redirect_from: -- "/docs/user-guide/jobs/work-queue-1/" -- "/docs/user-guide/jobs/work-queue-1/index.html" --- * TOC @@ -77,7 +74,7 @@ Later, we will make a docker image that includes these packages. Next, we will check that we can discover the rabbitmq service: ``` -# Note the rabitmq-service has a DNS name, provided by Kubernetes: +# Note the rabbitmq-service has a DNS name, provided by Kubernetes: root@temp-loe07:/# nslookup rabbitmq-service Server: 10.0.0.10 diff --git a/docs/tasks/job/fine-parallel-processing-work-queue/index.md b/docs/tasks/job/fine-parallel-processing-work-queue/index.md index dd8c2ac8b9..660f38bcf5 100644 --- a/docs/tasks/job/fine-parallel-processing-work-queue/index.md +++ b/docs/tasks/job/fine-parallel-processing-work-queue/index.md @@ -1,8 +1,5 @@ --- title: Fine Parallel Processing Using a Work Queue -redirect_from: -- "/docs/user-guide/jobs/work-queue-2/" -- "/docs/user-guide/jobs/work-queue-2/index.html" --- * TOC diff --git a/docs/tasks/job/parallel-processing-expansion.md b/docs/tasks/job/parallel-processing-expansion.md index 7a76447001..f4bec2dcc1 100644 --- a/docs/tasks/job/parallel-processing-expansion.md +++ b/docs/tasks/job/parallel-processing-expansion.md @@ -1,8 +1,5 @@ --- title: Parallel Processing using Expansions -redirect_from: -- "/docs/user-guide/jobs/expansions/index/" -- "/docs/user-guide/jobs/expansions/index.html" --- * TOC @@ -90,9 +87,9 @@ We can check on the pods as well using the same label selector: ```shell $ kubectl get pods -l jobgroup=jobexample --show-all NAME READY STATUS RESTARTS AGE -process-item-apple-kixwv 0/1 Completed 0 4m -process-item-banana-wrsf7 0/1 Completed 0 4m -process-item-cherry-dnfu9 0/1 Completed 0 4m +process-item-apple-kixwv 0/1 Completed 0 4m +process-item-banana-wrsf7 0/1 Completed 0 4m +process-item-cherry-dnfu9 0/1 Completed 0 4m ``` There is not a single command to check on the output of all jobs at once, @@ -124,7 +121,7 @@ First, copy and paste the following template of a Job object, into a file called {%- set params = [{ "name": "apple", "url": "http://www.orangepippin.com/apples", }, { "name": "banana", "url": "https://en.wikipedia.org/wiki/Banana", }, { "name": "raspberry", "url": "https://www.raspberrypi.org/" }] -%} +%} {%- for p in params %} {%- set name = p["name"] %} {%- set url = p["url"] %} diff --git a/docs/tasks/manage-gpus/scheduling-gpus.md b/docs/tasks/manage-gpus/scheduling-gpus.md index b392d88471..79768e6224 100644 --- a/docs/tasks/manage-gpus/scheduling-gpus.md +++ b/docs/tasks/manage-gpus/scheduling-gpus.md @@ -2,9 +2,6 @@ assignees: - vishh title: Schedule GPUs -redirect_from: -- "/docs/user-guide/gpus/" -- "/docs/user-guide/gpus.html" --- {% capture overview %} @@ -33,17 +30,17 @@ Nvidia GPUs can be consumed via container level resource requirements using the ```yaml apiVersion: v1 kind: pod -spec: - containers: - - +spec: + containers: + - name: gpu-container-1 - resources: - limits: + resources: + limits: alpha.kubernetes.io/nvidia-gpu: 2 # requesting 2 GPUs - - + - name: gpu-container-2 - resources: - limits: + resources: + limits: alpha.kubernetes.io/nvidia-gpu: 3 # requesting 3 GPUs ``` @@ -90,12 +87,12 @@ metadata: } } } -spec: - containers: - - +spec: + containers: + - name: gpu-container-1 - resources: - limits: + resources: + limits: alpha.kubernetes.io/nvidia-gpu: 2 ``` @@ -135,7 +132,7 @@ spec: - hostPath: path: /usr/lib/nvidia-375/bin name: bin - - hostPath: + - hostPath: path: /usr/lib/nvidia-375 name: lib ``` diff --git a/docs/tasks/run-application/delete-stateful-set.md b/docs/tasks/run-application/delete-stateful-set.md index 4b2b0cb34a..146bb6b326 100644 --- a/docs/tasks/run-application/delete-stateful-set.md +++ b/docs/tasks/run-application/delete-stateful-set.md @@ -6,9 +6,6 @@ assignees: - janetkuo - smarterclayton title: Delete a Stateful Set -redirect_from: -- "/docs/tasks/manage-stateful-set/deleting-a-statefulset/" -- "/docs/tasks/manage-stateful-set/deleting-a-statefulset.html" --- {% capture overview %} @@ -30,7 +27,7 @@ This task shows you how to delete a StatefulSet. You can delete a StatefulSet in the same way you delete other resources in Kubernetes: use the `kubectl delete` command, and specify the StatefulSet either by file or by name. ```shell -kubectl delete -f +kubectl delete -f ``` ```shell diff --git a/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index b3fd14864f..4619b8e086 100644 --- a/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -5,9 +5,6 @@ assignees: - justinsb - directxman12 title: Horizontal Pod Autoscaling Walkthrough -redirect_from: -- "/docs/user-guide/horizontal-pod-autoscaling/walkthrough/" -- "/docs/user-guide/horizontal-pod-autoscaling/walkthrough.html" --- Horizontal Pod Autoscaling automatically scales the number of pods diff --git a/docs/tasks/run-application/horizontal-pod-autoscale.md b/docs/tasks/run-application/horizontal-pod-autoscale.md index fcce446a72..049d51f165 100644 --- a/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -4,9 +4,6 @@ assignees: - jszczepkowski - directxman12 title: Horizontal Pod Autoscaling -redirect_from: -- "/docs/user-guide/horizontal-pod-autoscaling/" -- "/docs/user-guide/horizontal-pod-autoscaling/index.html" --- This document describes the current state of Horizontal Pod Autoscaling in Kubernetes. @@ -40,7 +37,7 @@ or the custom metrics API (for all other metrics). Then, if a target utilization value is set, the controller calculates the utilization value as a percentage of the equivalent resource request on the containers in each pod. If a target raw value is set, the raw metric values are used directly. - the controller then takes the mean of the utilization or the raw value (depending on the type + The controller then takes the mean of the utilization or the raw value (depending on the type of target specified) across all targeted pods, and produces a ratio used to scale the number of desired replicas. @@ -62,7 +59,7 @@ When using direct Heapster access, the HorizontalPodAutoscaler queries Heapster through the API server's service proxy subresource. Heapster needs to be deployed on the cluster and running in the kube-system namespace. -See [Support for custom metrics](#prerequisites) for more details on REST client access. +See [Support for custom metrics](#support-for-custom-metrics) for more details on REST client access. The autoscaler accesses corresponding replication controller, deployment or replica set by scale sub-resource. Scale is an interface that allows you to dynamically set the number of replicas and examine each of their current states. diff --git a/docs/tasks/run-application/rolling-update-replication-controller.md b/docs/tasks/run-application/rolling-update-replication-controller.md index 1eb797bee2..47f9673efe 100644 --- a/docs/tasks/run-application/rolling-update-replication-controller.md +++ b/docs/tasks/run-application/rolling-update-replication-controller.md @@ -2,11 +2,6 @@ assignees: - janetkuo title: Perform Rolling Update Using a Replication Controller -redirect_from: -- "/docs/user-guide/rolling-updates/" -- "/docs/user-guide/rolling-updates.html" -- "/docs/user-guide/update-demo/index/" -- "/docs/user-guide/update-demo/index.html" --- * TOC @@ -15,9 +10,9 @@ redirect_from: ## Overview **Note**: The preferred way to create a replicated application is to use a -[Deployment](/docs/api-reference/v1.6/#deployment-v1beta1-apps), +[Deployment](/docs/api-reference/{{page.version}}/#deployment-v1beta1-apps), which in turn uses a -[ReplicaSet](/docs/api-reference/v1.6/#replicaset-v1beta1-extensions). +[ReplicaSet](/docs/api-reference/{{page.version}}/#replicaset-v1beta1-extensions). For more information, see [Running a Stateless Application Using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/). diff --git a/docs/tasks/run-application/run-replicated-stateful-application.md b/docs/tasks/run-application/run-replicated-stateful-application.md index 0d18d10dab..f4b15adbb6 100644 --- a/docs/tasks/run-application/run-replicated-stateful-application.md +++ b/docs/tasks/run-application/run-replicated-stateful-application.md @@ -8,9 +8,6 @@ assignees: - kow3ns - smarterclayton title: Run a Replicated Stateful Application -redirect_from: -- "/docs/tutorials/stateful-application/run-replicated-stateful-application/" -- "/docs/tutorials/stateful-application/run-replicated-stateful-application.html" --- {% capture overview %} diff --git a/docs/tasks/run-application/run-single-instance-stateful-application.md b/docs/tasks/run-application/run-single-instance-stateful-application.md index 6e22164ba9..5860a79bdc 100644 --- a/docs/tasks/run-application/run-single-instance-stateful-application.md +++ b/docs/tasks/run-application/run-single-instance-stateful-application.md @@ -1,8 +1,5 @@ --- title: Run a Single-Instance Stateful Application -redirect_from: -- "/docs/tutorials/stateful-application/run-stateful-application/" -- "/docs/tutorials/stateful-application/run-stateful-application.html" --- {% capture overview %} @@ -115,7 +112,7 @@ for a secure solution. NAME READY STATUS RESTARTS AGE mysql-63082529-2z3ki 1/1 Running 0 3m - + 1. Inspect the Persistent Volume: kubectl describe pv mysql-pv @@ -127,7 +124,7 @@ for a secure solution. Reclaim Policy: Retain Access Modes: RWO Capacity: 20Gi - Message: + Message: Source: Type: GCEPersistentDisk (a Persistent Disk resource in Google Compute Engine) PDName: mysql-disk @@ -171,7 +168,7 @@ know your stateful MySQL database is up and running. Waiting for pod default/mysql-client-274442439-zyp6i to be running, status is Pending, pod ready: false If you don't see a command prompt, try pressing enter. -mysql> +mysql> ``` ## Updating diff --git a/docs/tasks/run-application/run-stateless-application-deployment.md b/docs/tasks/run-application/run-stateless-application-deployment.md index c0ed69b320..596b0fbbe3 100644 --- a/docs/tasks/run-application/run-stateless-application-deployment.md +++ b/docs/tasks/run-application/run-stateless-application-deployment.md @@ -1,16 +1,5 @@ --- title: Run a Stateless Application Using a Deployment -redirect_from: -- "/docs/user-guide/simple-nginx/" -- "/docs/user-guide/simple-nginx.html" -- "/docs/user-guide/pods/single-container/" -- "/docs/user-guide/pods/single-container.html" -- "/docs/user-guide/deploying-applications/" -- "/docs/user-guide/deploying-applications.html" -- "/docs/tutorials/stateless-application/run-stateless-application-deployment/" -- "/docs/tutorials/stateless-application/run-stateless-application-deployment.html" -- "/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/" -- "/docs/tutorials/stateless-application/run-stateless-ap-replication-controller.html" --- {% capture overview %} diff --git a/docs/tasks/run-application/scale-stateful-set.md b/docs/tasks/run-application/scale-stateful-set.md index de3b8fab46..12e68e556b 100644 --- a/docs/tasks/run-application/scale-stateful-set.md +++ b/docs/tasks/run-application/scale-stateful-set.md @@ -8,9 +8,6 @@ assignees: - kow3ns - smarterclayton title: Scale a StatefulSet -redirect_from: -- "/docs/tasks/manage-stateful-set/scale-stateful-set/" -- "/docs/tasks/manage-stateful-set/scale-stateful-set.html" --- {% capture overview %} @@ -19,8 +16,8 @@ This page shows how to scale a StatefulSet. {% capture prerequisites %} -* StatefulSets are only available in Kubernetes version 1.5 or later. -* **Not all stateful applications scale nicely.** You need to understand your StatefulSets well before continuing. If you're unsure, remember that it might not be safe to scale your StatefulSets. +* StatefulSets are only available in Kubernetes version 1.5 or later. +* **Not all stateful applications scale nicely.** You need to understand your StatefulSets well before continuing. If you're unsure, remember that it might not be safe to scale your StatefulSets. * You should perform scaling only when you're sure that your stateful application cluster is completely healthy. @@ -36,7 +33,7 @@ for which kubectl you're using. ### `kubectl scale` -First, find the StatefulSet you want to scale. Remember, you need to first understand if you can scale it or not. +First, find the StatefulSet you want to scale. Remember, you need to first understand if you can scale it or not. ```shell kubectl get statefulsets @@ -50,24 +47,24 @@ kubectl scale statefulsets --replicas= ### Alternative: `kubectl apply` / `kubectl edit` / `kubectl patch` -Alternatively, you can do [in-place updates](/docs/concepts/cluster-administration/manage-deployment/#in-place-updates-of-resources) on your StatefulSets. +Alternatively, you can do [in-place updates](/docs/concepts/cluster-administration/manage-deployment/#in-place-updates-of-resources) on your StatefulSets. -If your StatefulSet was initially created with `kubectl apply` or `kubectl create --save-config`, +If your StatefulSet was initially created with `kubectl apply` or `kubectl create --save-config`, update `.spec.replicas` of the StatefulSet manifests, and then do a `kubectl apply`: -```shell +```shell kubectl apply -f ``` Otherwise, edit that field with `kubectl edit`: -```shell +```shell kubectl edit statefulsets ``` Or use `kubectl patch`: -```shell +```shell kubectl patch statefulsets -p '{"spec":{"replicas":}}' ``` @@ -76,9 +73,9 @@ kubectl patch statefulsets -p '{"spec":{"replicas": 1, if there is an unhealthy Pod, there is no way +With a StatefulSet of size > 1, if there is an unhealthy Pod, there is no way for Kubernetes to know (yet) if it is due to a permanent fault or a transient one (upgrade/maintenance/node reboot). If the Pod is unhealthy due to a permanent fault, scaling without correcting the fault may lead to a state where the StatefulSet membership @@ -90,7 +87,7 @@ the transient error may interfere with your scale-up/scale-down operation. Some databases have issues when nodes join and leave at the same time. It is better to reason about scaling operations at the application level in these cases, and perform scaling only when you're sure that your stateful application cluster is -completely healthy. +completely healthy. {% endcapture %} diff --git a/docs/tasks/run-application/upgrade-pet-set-to-stateful-set.md b/docs/tasks/run-application/upgrade-pet-set-to-stateful-set.md index 358fc022f5..369e98d9aa 100644 --- a/docs/tasks/run-application/upgrade-pet-set-to-stateful-set.md +++ b/docs/tasks/run-application/upgrade-pet-set-to-stateful-set.md @@ -8,9 +8,6 @@ assignees: - kow3ns - smarterclayton title: Upgrade from PetSets to StatefulSets -redirect_from: -- "/docs/tasks/manage-stateful-set/upgrade-pet-set-to-stateful-set/" -- "/docs/tasks/manage-stateful-set/upgrade-pet-set-to-stateful-set.html" --- {% capture overview %} @@ -20,7 +17,7 @@ This page shows how to upgrade from PetSets (Kubernetes version 1.3 or 1.4) to * {% capture prerequisites %} * If you don't have PetSets in your current cluster, or you don't plan to upgrade - your master to Kubernetes 1.5 or later, you can skip this task. + your master to Kubernetes 1.5 or later, you can skip this task. {% endcapture %} @@ -28,12 +25,12 @@ This page shows how to upgrade from PetSets (Kubernetes version 1.3 or 1.4) to * ## Differences between alpha PetSets and beta StatefulSets -PetSet was introduced as an alpha resource in Kubernetes release 1.3, and was renamed to StatefulSet as a beta resource in 1.5. +PetSet was introduced as an alpha resource in Kubernetes release 1.3, and was renamed to StatefulSet as a beta resource in 1.5. Here are some notable changes: * **StatefulSet is the new PetSet**: PetSet is no longer available in Kubernetes release 1.5 or later. It becomes beta StatefulSet. To understand why the name was changed, see this [discussion thread](https://github.com/kubernetes/kubernetes/issues/27430). * **StatefulSet guards against split brain**: StatefulSets guarantee at most one Pod for a given ordinal index can be running anywhere in a cluster, to guard against split brain scenarios with distributed applications. *TODO: Link to doc about fencing.* -* **Flipped debug annotation behavior**: The default value of the debug annotation (`pod.alpha.kubernetes.io/initialized`) is now `true`. The absence of this annotation will pause PetSet operations, but will NOT pause StatefulSet operations. In most cases, you no longer need this annotation in your StatefulSet manifests. +* **Flipped debug annotation behavior**: The default value of the debug annotation (`pod.alpha.kubernetes.io/initialized`) is now `true`. The absence of this annotation will pause PetSet operations, but will NOT pause StatefulSet operations. In most cases, you no longer need this annotation in your StatefulSet manifests. ## Upgrading from PetSets to StatefulSets @@ -42,7 +39,7 @@ Note that these steps need to be done in the specified order. You **should NOT upgrade your Kubernetes master, nodes, or `kubectl` to Kubernetes version 1.5 or later**, until told to do so. -### Find all PetSets and their manifests +### Find all PetSets and their manifests First, find all existing PetSets in your cluster: @@ -53,42 +50,42 @@ kubectl get petsets --all-namespaces If you don't find any existing PetSets, you can safely upgrade your cluster to Kubernetes version 1.5 or later. -If you find existing PetSets and you have all their manifests at hand, you can continue to the next step to prepare StatefulSet manifests. +If you find existing PetSets and you have all their manifests at hand, you can continue to the next step to prepare StatefulSet manifests. -Otherwise, you need to save their manifests so that you can recreate them as StatefulSets later. -Here's an example command for you to save all existing PetSets as one file. +Otherwise, you need to save their manifests so that you can recreate them as StatefulSets later. +Here's an example command for you to save all existing PetSets as one file. ```shell -# Save all existing PetSets in all namespaces into a single file. Only needed when you don't have their manifests at hand. +# Save all existing PetSets in all namespaces into a single file. Only needed when you don't have their manifests at hand. kubectl get petsets --all-namespaces -o yaml > all-petsets.yaml ``` -### Prepare StatefulSet manifests +### Prepare StatefulSet manifests -Now, for every PetSet manifest you have, prepare a corresponding StatefulSet manifest: +Now, for every PetSet manifest you have, prepare a corresponding StatefulSet manifest: 1. Change `apiVersion` from `apps/v1alpha1` to `apps/v1beta1`. 2. Change `kind` from `PetSet` to `StatefulSet`. 3. If you have the debug hook annotation `pod.alpha.kubernetes.io/initialized` set to `true`, you can remove it because it's redundant. If you don't have this annotation, you should add one, with the value set to `false`, to pause StatefulSets operations. -It's recommended that you keep both PetSet manifests and StatefulSet manifests, so that you can safely roll back and recreate your PetSets, -if you decide not to upgrade your cluster. +It's recommended that you keep both PetSet manifests and StatefulSet manifests, so that you can safely roll back and recreate your PetSets, +if you decide not to upgrade your cluster. ### Delete all PetSets without cascading -If you find existing PetSets in your cluster in the previous step, you need to delete all PetSets *without cascading*. You can do this from `kubectl` with `--cascade=false`. -Note that if the flag isn't set, **cascading deletion will be performed by default**, and all Pods managed by your PetSets will be gone. +If you find existing PetSets in your cluster in the previous step, you need to delete all PetSets *without cascading*. You can do this from `kubectl` with `--cascade=false`. +Note that if the flag isn't set, **cascading deletion will be performed by default**, and all Pods managed by your PetSets will be gone. Delete those PetSets by specifying file names. This only works when the files contain only PetSets, but not other resources such as Services: ```shell -# Delete all existing PetSets without cascading +# Delete all existing PetSets without cascading # Note that should only contain PetSets that you want to delete, but not any other resources kubectl delete -f --cascade=false ``` -Alternatively, delete them by specifying resource names: +Alternatively, delete them by specifying resource names: ```shell # Alternatively, delete them by name and namespace without cascading @@ -98,23 +95,23 @@ kubectl delete petsets -n= --cascade=false Make sure you've deleted all PetSets in the system: ```shell -# Get all PetSets again to make sure you deleted them all +# Get all PetSets again to make sure you deleted them all # This should return nothing kubectl get petsets --all-namespaces ``` -At this moment, you've deleted all PetSets in your cluster, but not their Pods, Persistent Volumes, or Persistent Volume Claims. +At this moment, you've deleted all PetSets in your cluster, but not their Pods, Persistent Volumes, or Persistent Volume Claims. However, since the Pods are not managed by PetSets anymore, they will be vulnerable to node failures until you finish the master upgrade and recreate StatefulSets. ### Upgrade your master to Kubernetes version 1.5 or later Now, you can [upgrade your Kubernetes master](/docs/admin/cluster-management/#upgrading-a-cluster) to Kubernetes version 1.5 or later. Note that **you should NOT upgrade Nodes at this time**, because the Pods -(that were once managed by PetSets) are now vulnerable to node failures. +(that were once managed by PetSets) are now vulnerable to node failures. ### Upgrade kubectl to Kubernetes version 1.5 or later -Upgrade `kubectl` to Kubernetes version 1.5 or later, following [the steps for installing and setting up +Upgrade `kubectl` to Kubernetes version 1.5 or later, following [the steps for installing and setting up kubectl](/docs/tasks/kubectl/install/). ### Create StatefulSets diff --git a/docs/tasks/tools/install-kubectl.md b/docs/tasks/tools/install-kubectl.md index df655eb7a5..c320bbb66b 100644 --- a/docs/tasks/tools/install-kubectl.md +++ b/docs/tasks/tools/install-kubectl.md @@ -3,12 +3,8 @@ assignees: - bgrant0607 - mikedanese title: Install and Set Up kubectl -redirect_from: -- "/docs/tasks/kubectl/install/" -- "/docs/tasks/kubectl/install.html" -- "/docs/user-guide/prereqs/" -- "/docs/user-guide/prereqs.html" --- + {% capture overview %} Use the Kubernetes command-line tool, [kubectl](/docs/user-guide/kubectl), to deploy and manage applications on Kubernetes. Using kubectl, you can inspect cluster resources; create, delete, and update components; and look at your new cluster and bring up example apps. {% endcapture %} @@ -191,6 +187,13 @@ kubectl completion bash > $(brew --prefix)/etc/bash_completion.d/kubectl The Homebrew project is independent from kubernetes, so the bash-completion packages are not guaranteed to work. +### Using Oh-My-Zsh +When using [Oh-My-Zsh](http://ohmyz.sh/), edit the ~/.zshrc file and update the `plugins=` line to include the kubectl plugin. + +```shell +plugins=(git zsh-completions kubectl) +``` + {% endcapture %} {% capture whatsnext %} [Learn how to launch and expose your application.](/docs/user-guide/quick-start) diff --git a/docs/tools/kompose/user-guide.md b/docs/tools/kompose/user-guide.md index 109309e44d..83088fb600 100644 --- a/docs/tools/kompose/user-guide.md +++ b/docs/tools/kompose/user-guide.md @@ -4,9 +4,6 @@ assignees: - cdrage title: Translate a Docker Compose File to Kubernetes Resources -redirect_from: -- "/docs/tools/kompose/" -- "/docs/tools/kompose/index.html" --- * TOC @@ -42,7 +39,7 @@ Kompose is released via GitHub on a three-week cycle, you can see all current re The current release we use is `0.5.0`. ```sh -# Linux +# Linux curl -L https://github.com/kubernetes-incubator/kompose/releases/download/v0.5.0/kompose-linux-amd64 -o kompose # macOS @@ -111,27 +108,27 @@ You can also provide multiple docker-compose files at the same time: ```console $ kompose -f docker-compose.yml -f docker-guestbook.yml convert -file "frontend-service.yaml" created -file "mlbparks-service.yaml" created -file "mongodb-service.yaml" created -file "redis-master-service.yaml" created -file "redis-slave-service.yaml" created -file "frontend-deployment.yaml" created -file "mlbparks-deployment.yaml" created -file "mongodb-deployment.yaml" created -file "mongodb-claim0-persistentvolumeclaim.yaml" created -file "redis-master-deployment.yaml" created -file "redis-slave-deployment.yaml" created +file "frontend-service.yaml" created +file "mlbparks-service.yaml" created +file "mongodb-service.yaml" created +file "redis-master-service.yaml" created +file "redis-slave-service.yaml" created +file "frontend-deployment.yaml" created +file "mlbparks-deployment.yaml" created +file "mongodb-deployment.yaml" created +file "mongodb-claim0-persistentvolumeclaim.yaml" created +file "redis-master-deployment.yaml" created +file "redis-slave-deployment.yaml" created $ ls -mlbparks-deployment.yaml mongodb-service.yaml redis-slave-service.jsonmlbparks-service.yaml +mlbparks-deployment.yaml mongodb-service.yaml redis-slave-service.jsonmlbparks-service.yaml frontend-deployment.yaml mongodb-claim0-persistentvolumeclaim.yaml redis-master-service.yaml frontend-service.yaml mongodb-deployment.yaml redis-slave-deployment.yaml redis-master-deployment.yaml -``` +``` When multiple docker-compose files are provided the configuration is merged. Any configuration that is common will be over ridden by subsequent file. - + Using `--bundle, --dab` to specify a DAB file as below: ```console @@ -148,20 +145,20 @@ file "redis-deployment.yaml" created ```console $ kompose --provider openshift --file docker-voting.yml convert WARN [worker] Service cannot be created because of missing port. -INFO file "vote-service.yaml" created -INFO file "db-service.yaml" created -INFO file "redis-service.yaml" created -INFO file "result-service.yaml" created -INFO file "vote-deploymentconfig.yaml" created -INFO file "vote-imagestream.yaml" created -INFO file "worker-deploymentconfig.yaml" created -INFO file "worker-imagestream.yaml" created -INFO file "db-deploymentconfig.yaml" created -INFO file "db-imagestream.yaml" created -INFO file "redis-deploymentconfig.yaml" created -INFO file "redis-imagestream.yaml" created -INFO file "result-deploymentconfig.yaml" created -INFO file "result-imagestream.yaml" created +INFO file "vote-service.yaml" created +INFO file "db-service.yaml" created +INFO file "redis-service.yaml" created +INFO file "result-service.yaml" created +INFO file "vote-deploymentconfig.yaml" created +INFO file "vote-imagestream.yaml" created +INFO file "worker-deploymentconfig.yaml" created +INFO file "worker-imagestream.yaml" created +INFO file "db-deploymentconfig.yaml" created +INFO file "db-imagestream.yaml" created +INFO file "redis-deploymentconfig.yaml" created +INFO file "redis-imagestream.yaml" created +INFO file "result-deploymentconfig.yaml" created +INFO file "result-imagestream.yaml" created ``` In similar way you can convert DAB files to OpenShift. @@ -171,7 +168,7 @@ WARN: Unsupported key networks - ignoring INFO file "redis-svc.yaml" created INFO file "web-svc.yaml" created INFO file "web-deploymentconfig.yaml" created -INFO file "web-imagestream.yaml" created +INFO file "web-imagestream.yaml" created INFO file "redis-deploymentconfig.yaml" created INFO file "redis-imagestream.yaml" created ``` @@ -180,11 +177,11 @@ It also supports creating buildconfig for build directive in a service. By defau ```console $ kompose --provider openshift --file buildconfig/docker-compose.yml convert -WARN [foo] Service cannot be created because of missing port. -INFO Buildconfig using git@github.com:rtnpro/kompose.git::master as source. -INFO file "foo-deploymentconfig.yaml" created -INFO file "foo-imagestream.yaml" created -INFO file "foo-buildconfig.yaml" created +WARN [foo] Service cannot be created because of missing port. +INFO Buildconfig using git@github.com:rtnpro/kompose.git::master as source. +INFO file "foo-deploymentconfig.yaml" created +INFO file "foo-imagestream.yaml" created +INFO file "foo-buildconfig.yaml" created ``` **Note**: If you are manually pushing the Openshift artifacts using ``oc create -f``, you need to ensure that you push the imagestream artifact before the buildconfig artifact, to workaround this Openshift issue: https://github.com/openshift/origin/issues/4518 . @@ -200,12 +197,12 @@ $ kompose --file ./examples/docker-guestbook.yml up We are going to create Kubernetes deployments and services for your Dockerized application. If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead. -INFO Successfully created service: redis-master -INFO Successfully created service: redis-slave -INFO Successfully created service: frontend +INFO Successfully created service: redis-master +INFO Successfully created service: redis-slave +INFO Successfully created service: frontend INFO Successfully created deployment: redis-master INFO Successfully created deployment: redis-slave -INFO Successfully created deployment: frontend +INFO Successfully created deployment: frontend Your application has been deployed to Kubernetes. You can run 'kubectl get deployment,svc,pods' for details. @@ -236,13 +233,13 @@ $kompose --file ./examples/docker-guestbook.yml --provider openshift up We are going to create OpenShift DeploymentConfigs and Services for your Dockerized application. If you need different kind of resources, use the 'kompose convert' and 'oc create -f' commands instead. -INFO Successfully created service: redis-slave -INFO Successfully created service: frontend -INFO Successfully created service: redis-master +INFO Successfully created service: redis-slave +INFO Successfully created service: frontend +INFO Successfully created service: redis-master INFO Successfully created deployment: redis-slave INFO Successfully created ImageStream: redis-slave -INFO Successfully created deployment: frontend -INFO Successfully created ImageStream: frontend +INFO Successfully created deployment: frontend +INFO Successfully created ImageStream: frontend INFO Successfully created deployment: redis-master INFO Successfully created ImageStream: redis-master @@ -258,9 +255,9 @@ svc/frontend 172.30.46.64 80/TCP svc/redis-master 172.30.144.56 6379/TCP 8s svc/redis-slave 172.30.75.245 6379/TCP 8s NAME DOCKER REPO TAGS UPDATED -is/frontend 172.30.12.200:5000/fff/frontend -is/redis-master 172.30.12.200:5000/fff/redis-master -is/redis-slave 172.30.12.200:5000/fff/redis-slave v1 +is/frontend 172.30.12.200:5000/fff/frontend +is/redis-master 172.30.12.200:5000/fff/redis-master +is/redis-slave 172.30.12.200:5000/fff/redis-slave v1 ``` Note: @@ -272,11 +269,11 @@ Once you have deployed "composed" application to Kubernetes, `kompose down` will ```console $ kompose --file docker-guestbook.yml down -INFO Successfully deleted service: redis-master +INFO Successfully deleted service: redis-master INFO Successfully deleted deployment: redis-master -INFO Successfully deleted service: redis-slave +INFO Successfully deleted service: redis-slave INFO Successfully deleted deployment: redis-slave -INFO Successfully deleted service: frontend +INFO Successfully deleted service: frontend INFO Successfully deleted deployment: frontend ``` Note: @@ -296,7 +293,7 @@ file "web-deployment.json" created The `*-deployment.json` files contain the Deployment objects. ```console -$ kompose convert --rc +$ kompose convert --rc file "redis-svc.yaml" created file "web-svc.yaml" created file "redis-rc.yaml" created @@ -306,7 +303,7 @@ file "web-rc.yaml" created The `*-rc.yaml` files contain the Replication Controller objects. If you want to specify replicas (default is 1), use `--replicas` flag: `$ kompose convert --rc --replicas 3` ```console -$ kompose convert --ds +$ kompose convert --ds file "redis-svc.yaml" created file "web-svc.yaml" created file "redis-daemonset.yaml" created @@ -318,7 +315,7 @@ The `*-daemonset.yaml` files contain the Daemon Set objects If you want to generate a Chart to be used with [Helm](https://github.com/kubernetes/helm) simply do: ```console -$ kompose convert -c +$ kompose convert -c file "web-svc.yaml" created file "redis-svc.yaml" created file "web-deployment.yaml" created @@ -355,8 +352,8 @@ nginx: container_name: foobar $ kompose -f nginx.yml convert -WARN Unsupported key build - ignoring -WARN Unsupported key cap_add - ignoring +WARN Unsupported key build - ignoring +WARN Unsupported key cap_add - ignoring WARN Unsupported key dockerfile - ignoring ``` @@ -370,7 +367,7 @@ For example: ```yaml version: "2" -services: +services: nginx: image: nginx dockerfile: foobar @@ -378,7 +375,7 @@ services: cap_add: - ALL container_name: foobar - labels: + labels: kompose.service.type: nodeport ``` diff --git a/docs/tutorials/clusters/apparmor.md b/docs/tutorials/clusters/apparmor.md index 16967924b1..40d5d0591b 100644 --- a/docs/tutorials/clusters/apparmor.md +++ b/docs/tutorials/clusters/apparmor.md @@ -2,9 +2,6 @@ assignees: - stclair title: AppArmor -redirect_from: -- "/docs/admin/apparmor/index/" -- "/docs/admin/apparmor/index.html" --- {% capture overview %} diff --git a/docs/tutorials/index.md b/docs/tutorials/index.md index bbd289bcc6..9f48c6b9ea 100644 --- a/docs/tutorials/index.md +++ b/docs/tutorials/index.md @@ -1,8 +1,5 @@ --- title: Tutorials -redirect_from: -- "/docs/samples/" -- "/docs/samples.html" --- This section of the Kubernetes documentation contains tutorials. @@ -40,6 +37,16 @@ each of which has a sequence of steps. * [Running ZooKeeper, A CP Distributed System](/docs/tutorials/stateful-application/zookeeper/) +#### CI/CD Pipeline + +* [Set Up a CI/CD Pipeline with Kubernetes Part 1: Overview](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/5/set-cicd-pipeline-kubernetes-part-1-overview) + +* [Set Up a CI/CD Pipeline with a Jenkins Pod in Kubernetes (Part 2)](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/6/set-cicd-pipeline-jenkins-pod-kubernetes-part-2) + +* [Run and Scale a Distributed Crossword Puzzle App with CI/CD on Kubernetes (Part 3)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/run-and-scale-distributed-crossword-puzzle-app-cicd-kubernetes-part-3) + +* [Set Up CI/CD for a Distributed Crossword Puzzle App on Kubernetes (Part 4)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/set-cicd-distributed-crossword-puzzle-app-kubernetes-part-4) + #### Connecting Applications * [Connecting a Front End to a Back End Using a Service](/docs/tutorials/connecting-apps/connecting-frontend-backend/) diff --git a/docs/tutorials/kubernetes-basics/cluster-intro.html b/docs/tutorials/kubernetes-basics/cluster-intro.html index f6e1a60802..16427c1ee2 100644 --- a/docs/tutorials/kubernetes-basics/cluster-intro.html +++ b/docs/tutorials/kubernetes-basics/cluster-intro.html @@ -1,7 +1,4 @@ --- -redirect_from: -- "/docs/tutorials/getting-started/create-cluster/" -- "/docs/tutorials/getting-started/create-cluster.html" title: Using Minikube to Create a Cluster --- diff --git a/docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md b/docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md index c7b52f005f..d91cc4377b 100644 --- a/docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md +++ b/docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md @@ -1,8 +1,5 @@ --- title: Declarative Management of Kubernetes Objects Using Configuration Files -redirect_from: -- "/docs/concepts/tools/kubectl/object-management-using-declarative-config/" -- "/docs/concepts/tools/kubectl/object-management-using-declarative-config.html" --- {% capture overview %} @@ -952,7 +949,7 @@ template: - [Managing Kubernetes Objects Using Imperative Commands](/docs/tutorials/object-management-kubectl/imperative-object-management-command/) - [Imperative Management of Kubernetes Objects Using Configuration Files](/docs/tutorials/object-management-kubectl/imperative-object-management-configuration/) - [Kubectl Command Reference](/docs/user-guide/kubectl/v1.6/) -- [Kubernetes Object Schema Reference](/docs/resources-reference/v1.6/) +- [Kubernetes Object Schema Reference](/docs/resources-reference/{{page.version}}/) {% endcapture %} {% include templates/concept.md %} diff --git a/docs/tutorials/object-management-kubectl/imperative-object-management-command.md b/docs/tutorials/object-management-kubectl/imperative-object-management-command.md index d4a0837e1c..cbf6c44bb2 100644 --- a/docs/tutorials/object-management-kubectl/imperative-object-management-command.md +++ b/docs/tutorials/object-management-kubectl/imperative-object-management-command.md @@ -1,8 +1,5 @@ --- title: Managing Kubernetes Objects Using Imperative Commands -redirect_from: -- "/docs/concepts/tools/kubectl/object-management-using-imperative-commands/" -- "/docs/concepts/tools/kubectl/object-management-using-imperative-commands.html" --- {% capture overview %} @@ -83,7 +80,7 @@ The `kubectl` tool supports these additional ways to update a live object direct however they require a better understanding of the Kubernetes object schema. - `edit`: Directly edit the raw configuration of a live object by opening its configuration in an editor. -- `patch`: Directly modify specific fields of a live object by using a patch string. +- `patch`: Directly modify specific fields of a live object by using a patch string. For more details on patch strings, see the patch section in [API Conventions](https://git.k8s.io/community/contributors/devel/api-conventions.md#patch-operations). @@ -156,7 +153,7 @@ kubectl create --edit -f /tmp/srv.yaml - [Managing Kubernetes Objects Using Object Configuration (Imperative)](/docs/tutorials/object-management-kubectl/imperative-object-management-configuration/) - [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tutorials/object-management-kubectl/declarative-object-management-configuration/) - [Kubectl Command Reference](/docs/user-guide/kubectl/v1.6/) -- [Kubernetes Object Schema Reference](/docs/resources-reference/v1.6/) +- [Kubernetes Object Schema Reference](/docs/resources-reference/{{page.version}}/) {% endcapture %} {% include templates/concept.md %} diff --git a/docs/tutorials/object-management-kubectl/imperative-object-management-configuration.md b/docs/tutorials/object-management-kubectl/imperative-object-management-configuration.md index a4c5557a7d..ea26a5adc9 100644 --- a/docs/tutorials/object-management-kubectl/imperative-object-management-configuration.md +++ b/docs/tutorials/object-management-kubectl/imperative-object-management-configuration.md @@ -1,8 +1,5 @@ --- title: Imperative Management of Kubernetes Objects Using Configuration Files -redirect_from: -- "/docs/concepts/tools/kubectl/object-management-using-imperative-config/" -- "/docs/concepts/tools/kubectl/object-management-using-imperative-config.html" --- {% capture overview %} @@ -27,7 +24,7 @@ for a discussion of the advantages and disadvantage of each kind of object manag ## How to create objects You can use `kubectl create -f` to create an object from a configuration file. -Refer to the [kubernetes object schema reference](/docs/resources-reference/v1.6/) +Refer to the [kubernetes object schema reference](/docs/resources-reference/{{page.version}}/) for details. - `kubectl create -f ` @@ -61,7 +58,7 @@ described in a configuration file. - `kubectl get -f -o yaml` -The `-o yaml` flag specifies that the full object configuration is printed. +The `-o yaml` flag specifies that the full object configuration is printed. Use `kubectl get -h` to see a list of options. ## Limitations @@ -71,7 +68,7 @@ configuration is fully defined and recorded in its configuration file. However when a live object is updated, and the updates are not merged into its configuration file, the updates will be lost the next time a `replace` is executed. This can happen if a controller, such as -a HorizontalPodAutoscaler, makes updates directly to a live object. Here's +a HorizontalPodAutoscaler, makes updates directly to a live object. Here's an example: 1. You create an object from a configuration file. @@ -134,7 +131,7 @@ template: - [Managing Kubernetes Objects Using Imperative Commands](/docs/tutorials/object-management-kubectl/imperative-object-management-command/) - [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tutorials/object-management-kubectl/declarative-object-management-configuration/) - [Kubectl Command Reference](/docs/user-guide/kubectl/{{page.version}}/) -- [Kubernetes Object Schema Reference](/docs/resources-reference/v1.6/) +- [Kubernetes Object Schema Reference](/docs/resources-reference/{{page.version}}/) {% endcapture %} {% include templates/concept.md %} diff --git a/docs/tutorials/object-management-kubectl/object-management.md b/docs/tutorials/object-management-kubectl/object-management.md index c87b36e508..2a65f83bdc 100644 --- a/docs/tutorials/object-management-kubectl/object-management.md +++ b/docs/tutorials/object-management-kubectl/object-management.md @@ -1,10 +1,5 @@ --- title: Kubernetes Object Management -redirect_from: -- "/docs/concepts/tools/kubectl/object-management-overview/" -- "/docs/concepts/tools/kubectl/object-management-overview.html" -- "/docs/user-guide/working-with-resources/" -- "/docs/user-guide/working-with-resources.html" --- {% capture overview %} @@ -71,7 +66,7 @@ operation (create, replace, etc.), optional flags and at least one file name. The file specified must contain a full definition of the object in YAML or JSON format. -See the [resource reference](https://kubernetes.io/docs/resources-reference/v1.6/) +See the [resource reference](https://kubernetes.io/docs/resources-reference/{{page.version}}/) for more details on object definitions. **Warning:** The imperative `replace` command replaces the existing @@ -173,7 +168,7 @@ Disadvantages compared to imperative object configuration: - [Managing Kubernetes Objects Using Object Configuration (Imperative)](/docs/tutorials/object-management-kubectl/imperative-object-management-configuration/) - [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tutorials/object-management-kubectl/declarative-object-management-configuration/) - [Kubectl Command Reference](/docs/user-guide/kubectl/{{page.version}}/) -- [Kubernetes Object Schema Reference](/docs/resources-reference/v1.6/) +- [Kubernetes Object Schema Reference](/docs/resources-reference/{{page.version}}/) {% comment %} {% endcomment %} diff --git a/docs/tutorials/stateful-application/cassandra-service.yaml b/docs/tutorials/stateful-application/cassandra-service.yaml new file mode 100644 index 0000000000..35b07733b5 --- /dev/null +++ b/docs/tutorials/stateful-application/cassandra-service.yaml @@ -0,0 +1,12 @@ +apiVersion: v1 +kind: Service +metadata: + labels: + app: cassandra + name: cassandra +spec: + clusterIP: None + ports: + - port: 9042 + selector: + app: cassandra diff --git a/docs/tutorials/stateful-application/cassandra-statefulset.yaml b/docs/tutorials/stateful-application/cassandra-statefulset.yaml new file mode 100644 index 0000000000..f283acf657 --- /dev/null +++ b/docs/tutorials/stateful-application/cassandra-statefulset.yaml @@ -0,0 +1,94 @@ +apiVersion: "apps/v1beta1" +kind: StatefulSet +metadata: + name: cassandra +spec: + serviceName: cassandra + replicas: 3 + template: + metadata: + labels: + app: cassandra + spec: + containers: + - name: cassandra + image: gcr.io/google-samples/cassandra:v12 + imagePullPolicy: Always + ports: + - containerPort: 7000 + name: intra-node + - containerPort: 7001 + name: tls-intra-node + - containerPort: 7199 + name: jmx + - containerPort: 9042 + name: cql + resources: + limits: + cpu: "500m" + memory: 1Gi + requests: + cpu: "500m" + memory: 1Gi + securityContext: + capabilities: + add: + - IPC_LOCK + lifecycle: + preStop: + exec: + command: ["/bin/sh", "-c", "PID=$(pidof java) && kill $PID && while ps -p $PID > /dev/null; do sleep 1; done"] + env: + - name: MAX_HEAP_SIZE + value: 512M + - name: HEAP_NEWSIZE + value: 100M + - name: CASSANDRA_SEEDS + value: "cassandra-0.cassandra.default.svc.cluster.local" + - name: CASSANDRA_CLUSTER_NAME + value: "K8Demo" + - name: CASSANDRA_DC + value: "DC1-K8Demo" + - name: CASSANDRA_RACK + value: "Rack1-K8Demo" + - name: CASSANDRA_AUTO_BOOTSTRAP + value: "false" + - name: POD_IP + valueFrom: + fieldRef: + fieldPath: status.podIP + readinessProbe: + exec: + command: + - /bin/bash + - -c + - /ready-probe.sh + initialDelaySeconds: 15 + timeoutSeconds: 5 + # These volume mounts are persistent. They are like inline claims, + # but not exactly because the names need to match exactly one of + # the stateful pod volumes. + volumeMounts: + - name: cassandra-data + mountPath: /cassandra_data + # These are converted to volume claims by the controller + # and mounted at the paths mentioned above. + # do not use these in production until ssd GCEPersistentDisk or other ssd pd + volumeClaimTemplates: + - metadata: + name: cassandra-data + annotations: + volume.beta.kubernetes.io/storage-class: fast + spec: + accessModes: [ "ReadWriteOnce" ] + resources: + requests: + storage: 1Gi +--- +kind: StorageClass +apiVersion: storage.k8s.io/v1beta1 +metadata: + name: fast +provisioner: k8s.io/minikube-hostpath +parameters: + type: pd-ssd diff --git a/docs/tutorials/stateful-application/cassandra.md b/docs/tutorials/stateful-application/cassandra.md index a5b84a1a9e..f6172f4321 100644 --- a/docs/tutorials/stateful-application/cassandra.md +++ b/docs/tutorials/stateful-application/cassandra.md @@ -39,56 +39,16 @@ import it to the website. --> -## Table of Contents +{% capture overview %} +This tutorial shows you how to develop a native cloud [Cassandra](http://cassandra.apache.org/) deployment on Kubernetes. In this instance, a custom Cassandra `SeedProvider` enables Cassandra to discover new Cassandra nodes as they join the cluster. - - [Prerequisites](#prerequisites) - - [Cassandra Docker](#cassandra-docker) - - [Quickstart](#quickstart) - - [Step 1: Create a Cassandra Headless Service](#step-1-create-a-cassandra-headless-service) - - [Step 2: Use a StatefulSet to create Cassandra Ring](#step-2-use-a-statefulset-to-create-cassandra-ring) - - [Step 3: Validate and Modify The Cassandra StatefulSet](#step-3-validate-and-modify-the-cassandra-statefulset) - - [Step 4: Delete Cassandra StatefulSet](#step-4-delete-cassandra-statefulset) - - [Step 5: Use a Replication Controller to create Cassandra node pods](#step-5-use-a-replication-controller-to-create-cassandra-node-pods) - - [Step 6: Scale up the Cassandra cluster](#step-6-scale-up-the-cassandra-cluster) - - [Step 7: Delete the Replication Controller](#step-7-delete-the-replication-controller) - - [Step 8: Use a DaemonSet instead of a Replication Controller](#step-8-use-a-daemonset-instead-of-a-replication-controller) - - [Step 9: Resource Cleanup](#step-9-resource-cleanup) - - [Seed Provider Source](#seed-provider-source) +Deploying stateful distributed applications, like Cassandra, within a clustered environment can be challenging. StatefulSets greatly simplify this process. Please read about [StatefulSets](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) for more information about the features used in this tutorial. -The following document describes the development of a _cloud native_ -[Cassandra](http://cassandra.apache.org/) deployment on Kubernetes. When we say -_cloud native_, we mean an application which understands that it is running -within a cluster manager, and uses this cluster management infrastructure to -help implement the application. In particular, in this instance, a custom -Cassandra `SeedProvider` is used to enable Cassandra to dynamically discover -new Cassandra nodes as they join the cluster. - -This example also uses some of the core components of Kubernetes: - -- [_Pods_](/docs/user-guide/pods) -- [ _Services_](/docs/user-guide/services) -- [_Replication Controllers_](/docs/user-guide/replication-controller) -- [_Stateful Sets_](/docs/concepts/workloads/controllers/statefulset/) -- [_Daemon Sets_](/docs/admin/daemons) - -## Prerequisites - -This example assumes that you have a Kubernetes version >=1.2 cluster installed and running, -and that you have installed the [`kubectl`](https://kubernetes.io/docs/tasks/tools/install-kubectl/) -command line tool somewhere in your path. Please see the -[getting started guides](https://kubernetes.io/docs/getting-started-guides/) -for installation instructions for your platform. - -This example also has a few code and configuration files needed. To avoid -typing these out, you can `git clone` the Kubernetes repository to your local -computer. - -## Cassandra Docker +**Cassandra Docker** The pods use the [```gcr.io/google-samples/cassandra:v12```](https://github.com/kubernetes/examples/blob/master/cassandra/image/Dockerfile) image from Google's [container registry](https://cloud.google.com/container-registry/docs/). -The docker is based on `debian:jessie` and includes OpenJDK 8. This image -includes a standard Cassandra installation from the Apache Debian repo. Through the use of environment variables you are able to change values that are inserted into the `cassandra.yaml`. +The docker is based on `debian:jessie` and includes OpenJDK 8. This image includes a standard Cassandra installation from the Apache Debian repo. By using environment variables you can change values that are inserted into `cassandra.yaml`. | ENV VAR | DEFAULT VALUE | | ------------- |:-------------: | @@ -96,286 +56,132 @@ includes a standard Cassandra installation from the Apache Debian repo. Through | CASSANDRA_NUM_TOKENS | 32 | | CASSANDRA_RPC_ADDRESS | 0.0.0.0 | -## Quickstart +{% endcapture %} -If you want to jump straight to the commands we will run, -here are the steps: +{% capture objectives %} +* Create and Validate a Cassandra headless `Service`. +* Use a `StatefulSet` to create a Cassandra ring. +* Validate the `StatefulSet`. +* Modify the `StatefulSet`. +* Delete the `StatefulSet` and its `Pods`. +{% endcapture %} -```sh -# -# StatefulSet -# +{% capture prerequisites %} +To complete this tutorial, you should already have a basic familiarity with [Pods](https://kubernetes.io/docs/concepts/workloads/pods/pod/), [Services](https://kubernetes.io/docs/concepts/services-networking/service/), and [StatefulSets](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/). In addition, you should: -# clone the example repository -git clone https://github.com/kubernetes/examples -cd examples +* [Install and Configure](https://kubernetes.io/docs/tasks/tools/install-kubectl/) the `kubectl` command line -# create a service to track all cassandra statefulset nodes -kubectl create -f cassandra/cassandra-service.yaml +* Download [cassandra-service.yaml](https://kubernetes.io/docs/tutorials/stateful-application/cassandra-service.yaml) and [cassandra-statefulset.yaml](https://kubernetes.io/docs/tutorials/stateful-application/cassandra-statefulset.yaml) -# create a statefulset -kubectl create -f cassandra/cassandra-statefulset.yaml +* Have a supported Kubernetes Cluster running -# validate the Cassandra cluster. Substitute the name of one of your pods. -kubectl exec -ti cassandra-0 -- nodetool status +**Note:** Please read the [getting started guides](https://kubernetes.io/docs/setup/pick-right-solution/) if you do not already have a cluster. -# cleanup -grace=$(kubectl get po cassandra-0 -o=jsonpath='{.spec.terminationGracePeriodSeconds}') \ - && kubectl delete statefulset,po -l app=cassandra \ - && echo "Sleeping $grace" \ - && sleep $grace \ - && kubectl delete pvc -l app=cassandra +### Additional Minikube Setup Instructions -# -# Resource Controller Example -# +**Warning:** [Minikube](https://kubernetes.io/docs/getting-started-guides/minikube/) defaults to 1024MB of memory and 1 CPU which results in an insufficient resource errors. -# create a replication controller to replicate cassandra nodes -kubectl create -f cassandra/cassandra-controller.yaml +To avoid these errors, run minikube with: -# validate the Cassandra cluster. Substitute the name of one of your pods. -kubectl exec -ti cassandra-xxxxx -- nodetool status +``` +minikube start --memory 5120 --cpus=4 +``` +{% endcapture %} -# scale up the Cassandra cluster -kubectl scale rc cassandra --replicas=4 +{% capture lessoncontent %} +## Creating a Cassandra Headless Service +A Kubernetes [Service](https://kubernetes.io/docs/concepts/services-networking/service/) describes a set of [Pods](https://kubernetes.io/docs/concepts/workloads/pods/pod/) that perform the same task. -# delete the replication controller -kubectl delete rc cassandra +The following `Service` is used for DNS lookups between Cassandra pods and clients within the Kubernetes Cluster. -# -# Create a DaemonSet to place a cassandra node on each kubernetes node -# +1. `cd` to the folder you saved the .yaml files. +2. Create a `Service` to track all Cassandra StatefulSet Nodes from the following `.yaml` file: -kubectl create -f cassandra/cassandra-daemonset.yaml --validate=false - -# resource cleanup -kubectl delete service -l app=cassandra -kubectl delete daemonset cassandra +```shell +kubectl create -f cassandra-service.yaml ``` -## Step 1: Create a Cassandra Headless Service +{% include code.html language="yaml" file="cassandra-service.yaml" ghlink="/docs/tutorials/stateful-application/cassandra-service.yaml" %} -A Kubernetes _[Service](/docs/user-guide/services)_ describes a set of -[_Pods_](/docs/user-guide/pods) that perform the same task. In -Kubernetes, the atomic unit of an application is a Pod: one or more containers -that _must_ be scheduled onto the same host. +### Validating (optional) -The Service is used for DNS lookups between Cassandra Pods, and Cassandra clients -within the Kubernetes Cluster. +Get the Cassandra `Service`. -Here is the service description: - - - -```yaml -apiVersion: v1 -kind: Service -metadata: - labels: - app: cassandra - name: cassandra -spec: - clusterIP: None - ports: - - port: 9042 - selector: - app: cassandra +```shell +kubectl get svc cassandra ``` -[Download example](https://raw.githubusercontent.com/kubernetes/examples/master/cassandra-service.yaml) - - -Create the service for the StatefulSet: - - -```console -$ kubectl create -f cassandra/cassandra-service.yaml -``` - -The following command shows if the service has been created. - -```console -$ kubectl get svc cassandra -``` - -The response should be like: +The response should be ```console NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE cassandra None 9042/TCP 45s ``` -If an error is returned the service create failed. +If anything else returns, the service was not successfully created. Read [Debug Services](https://kubernetes.io/docs/tasks/debug-application-cluster/debug-service/) for common issues. -## Step 2: Use a StatefulSet to create Cassandra Ring +## Using a StatefulSet to Create a Cassandra Ring -StatefulSets (previously PetSets) are a feature that was upgraded to a Beta component in -Kubernetes 1.5. Deploying stateful distributed applications, like Cassandra, within a clustered -environment can be challenging. We implemented StatefulSet to greatly simplify this -process. Multiple StatefulSet features are used within this example, but is out of -scope of this documentation. [Please refer to the Stateful Set documentation.](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) +The StatefulSet manifest, included below, creates a Cassandra ring that consists of three pods. -The StatefulSet manifest that is included below, creates a Cassandra ring that consists -of three pods. +**Note:** This example uses the default provisioner for Minikube. Please update the following StatefulSet for the cloud you are working with. -This example includes using a GCE Storage Class, please update appropriately depending -on the cloud you are working with. +1. Update the StatefulSet if necessary. +2. Create the Cassandra StatefulSet from the following `.yaml` file: - - -```yaml -apiVersion: "apps/v1beta1" -kind: StatefulSet -metadata: - name: cassandra -spec: - serviceName: cassandra - replicas: 3 - template: - metadata: - labels: - app: cassandra - spec: - containers: - - name: cassandra - image: gcr.io/google-samples/cassandra:v12 - imagePullPolicy: Always - ports: - - containerPort: 7000 - name: intra-node - - containerPort: 7001 - name: tls-intra-node - - containerPort: 7199 - name: jmx - - containerPort: 9042 - name: cql - resources: - limits: - cpu: "500m" - memory: 1Gi - requests: - cpu: "500m" - memory: 1Gi - securityContext: - capabilities: - add: - - IPC_LOCK - lifecycle: - preStop: - exec: - command: ["/bin/sh", "-c", "PID=$(pidof java) && kill $PID && while ps -p $PID > /dev/null; do sleep 1; done"] - env: - - name: MAX_HEAP_SIZE - value: 512M - - name: HEAP_NEWSIZE - value: 100M - - name: CASSANDRA_SEEDS - value: "cassandra-0.cassandra.default.svc.cluster.local" - - name: CASSANDRA_CLUSTER_NAME - value: "K8Demo" - - name: CASSANDRA_DC - value: "DC1-K8Demo" - - name: CASSANDRA_RACK - value: "Rack1-K8Demo" - - name: CASSANDRA_AUTO_BOOTSTRAP - value: "false" - - name: POD_IP - valueFrom: - fieldRef: - fieldPath: status.podIP - readinessProbe: - exec: - command: - - /bin/bash - - -c - - /ready-probe.sh - initialDelaySeconds: 15 - timeoutSeconds: 5 - # These volume mounts are persistent. They are like inline claims, - # but not exactly because the names need to match exactly one of - # the stateful pod volumes. - volumeMounts: - - name: cassandra-data - mountPath: /cassandra_data - # These are converted to volume claims by the controller - # and mounted at the paths mentioned above. - # do not use these in production until ssd GCEPersistentDisk or other ssd pd - volumeClaimTemplates: - - metadata: - name: cassandra-data - annotations: - volume.beta.kubernetes.io/storage-class: fast - spec: - accessModes: [ "ReadWriteOnce" ] - resources: - requests: - storage: 1Gi ---- -kind: StorageClass -apiVersion: storage.k8s.io/v1beta1 -metadata: - name: fast -provisioner: kubernetes.io/gce-pd -parameters: - type: pd-ssd +```shell +kubectl create -f cassandra-statefulset.yaml ``` -[Download example](https://raw.githubusercontent.com/kubernetes/examples/master/cassandra-statefulset.yaml) - +{% include code.html language="yaml" file="cassandra-statefulset.yaml" ghlink="/docs/tutorials/stateful-application/cassandra-statefulset.yaml" %} -Create the Cassandra StatefulSet as follows: +## Validating The Cassandra StatefulSet -```console -$ kubectl create -f cassandra/cassandra-statefulset.yaml +1. Get the Cassandra StatefulSet: + +```shell +kubectl get statefulset cassandra ``` -## Step 3: Validate and Modify The Cassandra StatefulSet - -Deploying this StatefulSet shows off two of the new features that StatefulSets provides. - -1. The pod names are known -2. The pods deploy in incremental order - -First validate that the StatefulSet has deployed, by running `kubectl` command below. - -```console -$ kubectl get statefulset cassandra -``` - -The command should respond like: + The response should be ```console NAME DESIRED CURRENT AGE -cassandra 3 3 13s +cassandra 3 0 13s ``` -Next watch the Cassandra pods deploy, one after another. The StatefulSet resource -deploys pods in a number fashion: 1, 2, 3, etc. If you execute the following -command before the pods deploy you are able to see the ordered creation. + The StatefulSet resource deploys pods sequentially. -```console -$ kubectl get pods -l="app=cassandra" +{:start="2"} +2. Get the Pods to see the ordered creation status: + +```shell +kubectl get pods -l="app=cassandra" NAME READY STATUS RESTARTS AGE cassandra-0 1/1 Running 0 1m cassandra-1 0/1 ContainerCreating 0 8s ``` -The above example shows two of the three pods in the Cassandra StatefulSet deployed. -Once all of the pods are deployed the same command will respond with the full -StatefulSet. +**Note:** It can take up to ten minutes for all three pods to deploy. -```console -$ kubectl get pods -l="app=cassandra" +Once all pods are deployed, the same command returns: + +```shell +kubectl get pods -l="app=cassandra" NAME READY STATUS RESTARTS AGE cassandra-0 1/1 Running 0 10m cassandra-1 1/1 Running 0 9m cassandra-2 1/1 Running 0 8m ``` -Running the Cassandra utility `nodetool` will display the status of the ring. +{:start="3"} +3. Run the Cassandra utility nodetool to display the status of the ring. + +``` +kubectl exec cassandra-0 -- nodetool status +``` ```console -$ kubectl exec cassandra-0 -- nodetool status Datacenter: DC1-K8Demo ====================== Status=Up/Down @@ -386,26 +192,17 @@ UN 10.4.0.4 102.04 KiB 32 66.7% 5559a58c-8b03-47ad-bc32 UN 10.4.1.4 83.06 KiB 32 69.6% 9dce943c-581d-4c0e-9543-f519969cc805 Rack1-K8Demo ``` -You can also run `cqlsh` to describe the keyspaces in the cluster. +## Modifying the Cassandra StatefulSet +Use `kubectl edit` to modify the size of of a Cassandra StatefulSet. -```console -$ kubectl exec cassandra-0 -- cqlsh -e 'desc keyspaces' +1. Run the following command: -system_traces system_schema system_auth system system_distributed +```shell +kubectl edit statefulset cassandra ``` - -In order to increase or decrease the size of the Cassandra StatefulSet, you must use -`kubectl edit`. You can find more information about the edit command in the [documentation](/docs/user-guide/kubectl/kubectl_edit). - -Use the following command to edit the StatefulSet. - -```console -$ kubectl edit statefulset cassandra -``` - -This will create an editor in your terminal. The line you are looking to change is -`replicas`. The example does on contain the entire contents of the terminal window, and -the last line of the example below is the replicas line that you want to change. + This command opens an editor in your terminal. The line you need to change is `Replicas`. + + **Note:** The following sample is an excerpt of the StatefulSet file. ```console # Please edit the object below. Lines beginning with a '#' will be ignored, @@ -428,468 +225,56 @@ spec: replicas: 3 ``` -Modify the manifest to the following, and save the manifest. +{:start="2"} +2. Increase the number of replicas to 4, and then save the manifest. -```console -spec: - replicas: 4 + The StatefulSet now contains 4 pods. + +3. Get the Cassandra StatefulSet to verify: + +```shell +kubectl get statefulset cassandra ``` -The StatefulSet will now contain four pods. - -```console -$ kubectl get statefulset cassandra -``` - -The command should respond like: + The response should be ```console NAME DESIRED CURRENT AGE cassandra 4 4 36m ``` +{% endcapture %} -For the Kubernetes 1.5 release, the beta StatefulSet resource does not have `kubectl scale` -functionality, like a Deployment, ReplicaSet, Replication Controller, or Job. +{% capture cleanup %} +Deleting or scaling a StatefulSet down does not delete the volumes associated with the StatefulSet. This ensures safety first: your data is more valuable than an auto purge of all related StatefulSet resources. -## Step 4: Delete Cassandra StatefulSet +**Warning:** Depending on the storage class and reclaim policy, deleting the Persistent Volume Claims may cause the associated volumes to also be deleted. Never assume you’ll be able to access data if its volume claims are deleted. -Deleting and/or scaling a StatefulSet down will not delete the volumes associated with the StatefulSet. This is done to ensure safety first, your data is more valuable than an auto purge of all related StatefulSet resources. Deleting the Persistent Volume Claims may result in a deletion of the associated volumes, depending on the storage class and reclaim policy. You should never assume ability to access a volume after claim deletion. +1. Run the following commands to delete everything in a `StatefulSet`: -Use the following commands to delete the StatefulSet. - -```console -$ grace=$(kubectl get po cassandra-0 -o=jsonpath='{.spec.terminationGracePeriodSeconds}') \ +```shell +grace=$(kubectl get po cassandra-0 -o=jsonpath='{.spec.terminationGracePeriodSeconds}') \ && kubectl delete statefulset -l app=cassandra \ && echo "Sleeping $grace" \ && sleep $grace \ && kubectl delete pvc -l app=cassandra ``` -## Step 5: Use a Replication Controller to create Cassandra node pods +2. Run the following command to delete the Cassandra `Service`. -A Kubernetes -_[Replication Controller](/docs/user-guide/replication-controller)_ -is responsible for replicating sets of identical pods. Like a -Service, it has a selector query which identifies the members of its set. -Unlike a Service, it also has a desired number of replicas, and it will create -or delete Pods to ensure that the number of Pods matches up with its -desired state. - -The Replication Controller, in conjunction with the Service we just defined, -will let us easily build a replicated, scalable Cassandra cluster. - -Let's create a replication controller with two initial replicas. - - - -```yaml -apiVersion: v1 -kind: ReplicationController -metadata: - name: cassandra - # The labels will be applied automatically - # from the labels in the pod template, if not set - # labels: - # app: cassandra -spec: - replicas: 2 - # The selector will be applied automatically - # from the labels in the pod template, if not set. - # selector: - # app: cassandra - template: - metadata: - labels: - app: cassandra - spec: - containers: - - command: - - /run.sh - resources: - limits: - cpu: 0.5 - env: - - name: MAX_HEAP_SIZE - value: 512M - - name: HEAP_NEWSIZE - value: 100M - - name: CASSANDRA_SEED_PROVIDER - value: "io.k8s.cassandra.KubernetesSeedProvider" - - name: POD_NAMESPACE - valueFrom: - fieldRef: - fieldPath: metadata.namespace - - name: POD_IP - valueFrom: - fieldRef: - fieldPath: status.podIP - image: gcr.io/google-samples/cassandra:v12 - name: cassandra - ports: - - containerPort: 7000 - name: intra-node - - containerPort: 7001 - name: tls-intra-node - - containerPort: 7199 - name: jmx - - containerPort: 9042 - name: cql - volumeMounts: - - mountPath: /cassandra_data - name: data - volumes: - - name: data - emptyDir: {} +```shell +kubectl delete service -l app=cassandra ``` -[Download example](https://raw.githubusercontent.com/kubernetes/examples/master/cassandra-controller.yaml) - +{% endcapture %} -There are a few things to note in this description. +{% capture whatsnext %} +* Learn how to [Scale a StatefulSet](https://kubernetes.io/docs/tasks/run-application/scale-stateful-set/). +* Learn more about the [KubernetesSeedProvider](https://github.com/kubernetes/examples/blob/master/cassandra/java/src/main/java/io/k8s/cassandra/KubernetesSeedProvider.java) +* See more custom [Seed Provider Configurations](https://git.k8s.io/examples/cassandra/java/README.md) -The `selector` attribute contains the controller's selector query. It can be -explicitly specified, or applied automatically from the labels in the pod -template if not set, as is done here. - -The pod template's label, `app:cassandra`, matches the Service selector -from Step 1. This is how pods created by this replication controller are picked up -by the Service." - -The `replicas` attribute specifies the desired number of replicas, in this -case 2 initially. We'll scale up to more shortly. - -Create the Replication Controller: - -```console - -$ kubectl create -f cassandra/cassandra-controller.yaml - -``` - -You can list the new controller: - -```console - -$ kubectl get rc -o wide -NAME DESIRED CURRENT AGE CONTAINER(S) IMAGE(S) SELECTOR -cassandra 2 2 11s cassandra gcr.io/google-samples/cassandra:v12 app=cassandra - -``` - -Now if you list the pods in your cluster, and filter to the label -`app=cassandra`, you should see two Cassandra pods. (The `wide` argument lets -you see which Kubernetes nodes the pods were scheduled onto.) - -```console - -$ kubectl get pods -l="app=cassandra" -o wide -NAME READY STATUS RESTARTS AGE NODE -cassandra-21qyy 1/1 Running 0 1m kubernetes-minion-b286 -cassandra-q6sz7 1/1 Running 0 1m kubernetes-minion-9ye5 - -``` - -Because these pods have the label `app=cassandra`, they map to the service we -defined in Step 1. - -You can check that the Pods are visible to the Service using the following service endpoints query: - -```console - -$ kubectl get endpoints cassandra -o yaml -apiVersion: v1 -kind: Endpoints -metadata: - creationTimestamp: 2015-06-21T22:34:12Z - labels: - app: cassandra - name: cassandra - namespace: default - resourceVersion: "944373" - selfLink: /api/v1/namespaces/default/endpoints/cassandra - uid: a3d6c25f-1865-11e5-a34e-42010af01bcc -subsets: -- addresses: - - ip: 10.244.3.15 - targetRef: - kind: Pod - name: cassandra - namespace: default - resourceVersion: "944372" - uid: 9ef9895d-1865-11e5-a34e-42010af01bcc - ports: - - port: 9042 - protocol: TCP - -``` - -To show that the `SeedProvider` logic is working as intended, you can use the -`nodetool` command to examine the status of the Cassandra cluster. To do this, -use the `kubectl exec` command, which lets you run `nodetool` in one of your -Cassandra pods. Again, substitute `cassandra-xxxxx` with the actual name of one -of your pods. - -```console - -$ kubectl exec -ti cassandra-xxxxx -- nodetool status -Datacenter: datacenter1 -======================= -Status=Up/Down -|/ State=Normal/Leaving/Joining/Moving --- Address Load Tokens Owns (effective) Host ID Rack -UN 10.244.0.5 74.09 KB 256 100.0% 86feda0f-f070-4a5b-bda1-2eeb0ad08b77 rack1 -UN 10.244.3.3 51.28 KB 256 100.0% dafe3154-1d67-42e1-ac1d-78e7e80dce2b rack1 - -``` - -## Step 6: Scale up the Cassandra cluster - -Now let's scale our Cassandra cluster to 4 pods. We do this by telling the -Replication Controller that we now want 4 replicas. - -```sh - -$ kubectl scale rc cassandra --replicas=4 - -``` - -You can see the new pods listed: - -```console - -$ kubectl get pods -l="app=cassandra" -o wide -NAME READY STATUS RESTARTS AGE NODE -cassandra-21qyy 1/1 Running 0 6m kubernetes-minion-b286 -cassandra-81m2l 1/1 Running 0 47s kubernetes-minion-b286 -cassandra-8qoyp 1/1 Running 0 47s kubernetes-minion-9ye5 -cassandra-q6sz7 1/1 Running 0 6m kubernetes-minion-9ye5 - -``` - -In a few moments, you can examine the Cassandra cluster status again, and see -that the new pods have been detected by the custom `SeedProvider`: - -```console - -$ kubectl exec -ti cassandra-xxxxx -- nodetool status -Datacenter: datacenter1 -======================= -Status=Up/Down -|/ State=Normal/Leaving/Joining/Moving --- Address Load Tokens Owns (effective) Host ID Rack -UN 10.244.0.6 51.67 KB 256 48.9% d07b23a5-56a1-4b0b-952d-68ab95869163 rack1 -UN 10.244.1.5 84.71 KB 256 50.7% e060df1f-faa2-470c-923d-ca049b0f3f38 rack1 -UN 10.244.1.6 84.71 KB 256 47.0% 83ca1580-4f3c-4ec5-9b38-75036b7a297f rack1 -UN 10.244.0.5 68.2 KB 256 53.4% 72ca27e2-c72c-402a-9313-1e4b61c2f839 rack1 - -``` - -## Step 7: Delete the Replication Controller - -Before you start Step 5, __delete the replication controller__ you created above: - -```sh - -$ kubectl delete rc cassandra - -``` - -## Step 8: Use a DaemonSet instead of a Replication Controller - -In Kubernetes, a [_Daemon Set_](/docs/admin/daemons) can distribute pods -onto Kubernetes nodes, one-to-one. Like a _ReplicationController_, it has a -selector query which identifies the members of its set. Unlike a -_ReplicationController_, it has a node selector to limit which nodes are -scheduled with the templated pods, and replicates not based on a set target -number of pods, but rather assigns a single pod to each targeted node. - -An example use case: when deploying to the cloud, the expectation is that -instances are ephemeral and might die at any time. Cassandra is built to -replicate data across the cluster to facilitate data redundancy, so that in the -case that an instance dies, the data stored on the instance does not, and the -cluster can react by re-replicating the data to other running nodes. - -`DaemonSet` is designed to place a single pod on each node in the Kubernetes -cluster. That will give us data redundancy. Let's create a -DaemonSet to start our storage cluster: - - - -```yaml -apiVersion: extensions/v1beta1 -kind: DaemonSet -metadata: - labels: - name: cassandra - name: cassandra -spec: - template: - metadata: - labels: - app: cassandra - spec: - # Filter to specific nodes: - # nodeSelector: - # app: cassandra - containers: - - command: - - /run.sh - env: - - name: MAX_HEAP_SIZE - value: 512M - - name: HEAP_NEWSIZE - value: 100M - - name: CASSANDRA_SEED_PROVIDER - value: "io.k8s.cassandra.KubernetesSeedProvider" - - name: POD_NAMESPACE - valueFrom: - fieldRef: - fieldPath: metadata.namespace - - name: POD_IP - valueFrom: - fieldRef: - fieldPath: status.podIP - image: gcr.io/google-samples/cassandra:v12 - name: cassandra - ports: - - containerPort: 7000 - name: intra-node - - containerPort: 7001 - name: tls-intra-node - - containerPort: 7199 - name: jmx - - containerPort: 9042 - name: cql - # If you need it it is going away in C* 4.0 - #- containerPort: 9160 - # name: thrift - resources: - requests: - cpu: 0.5 - volumeMounts: - - mountPath: /cassandra_data - name: data - volumes: - - name: data - emptyDir: {} -``` - -[Download example](https://raw.githubusercontent.com/kubernetes/examples/master/cassandra-daemonset.yaml) - - -Most of this DaemonSet definition is identical to the ReplicationController -definition above; it simply gives the daemon set a recipe to use when it creates -new Cassandra pods, and targets all Cassandra nodes in the cluster. - -Differentiating aspects are the `nodeSelector` attribute, which allows the -DaemonSet to target a specific subset of nodes (you can label nodes just like -other resources), and the lack of a `replicas` attribute due to the 1-to-1 node- -pod relationship. - -Create this DaemonSet: - -```console - -$ kubectl create -f cassandra/cassandra-daemonset.yaml - -``` - -You may need to disable config file validation, like so: - -```console - -$ kubectl create -f cassandra/cassandra-daemonset.yaml --validate=false - -``` - -You can see the DaemonSet running: - -```console - -$ kubectl get daemonset -NAME DESIRED CURRENT NODE-SELECTOR -cassandra 3 3 - -``` - -Now, if you list the pods in your cluster, and filter to the label -`app=cassandra`, you should see one (and only one) new cassandra pod for each -node in your network. - -```console - -$ kubectl get pods -l="app=cassandra" -o wide -NAME READY STATUS RESTARTS AGE NODE -cassandra-ico4r 1/1 Running 0 4s kubernetes-minion-rpo1 -cassandra-kitfh 1/1 Running 0 1s kubernetes-minion-9ye5 -cassandra-tzw89 1/1 Running 0 2s kubernetes-minion-b286 - -``` - -To prove that this all worked as intended, you can again use the `nodetool` -command to examine the status of the cluster. To do this, use the `kubectl -exec` command to run `nodetool` in one of your newly-launched cassandra pods. - -```console - -$ kubectl exec -ti cassandra-xxxxx -- nodetool status -Datacenter: datacenter1 -======================= -Status=Up/Down -|/ State=Normal/Leaving/Joining/Moving --- Address Load Tokens Owns (effective) Host ID Rack -UN 10.244.0.5 74.09 KB 256 100.0% 86feda0f-f070-4a5b-bda1-2eeb0ad08b77 rack1 -UN 10.244.4.2 32.45 KB 256 100.0% 0b1be71a-6ffb-4895-ac3e-b9791299c141 rack1 -UN 10.244.3.3 51.28 KB 256 100.0% dafe3154-1d67-42e1-ac1d-78e7e80dce2b rack1 - -``` - -**Note**: This example had you delete the cassandra Replication Controller before -you created the DaemonSet. This is because – to keep this example simple – the -RC and the DaemonSet are using the same `app=cassandra` label (so that their pods map to the -service we created, and so that the SeedProvider can identify them). - -If we didn't delete the RC first, the two resources would conflict with -respect to how many pods they wanted to have running. If we wanted, we could support running -both together by using additional labels and selectors. - -## Step 9: Resource Cleanup - -When you are ready to take down your resources, do the following: - -```console - -$ kubectl delete service -l app=cassandra -$ kubectl delete daemonset cassandra - -``` - -### Custom Seed Provider - -A custom [`SeedProvider`](https://svn.apache.org/repos/asf/cassandra/trunk/src/java/org/apache/cassandra/locator/SeedProvider.java) -is included for running Cassandra on top of Kubernetes. Only when you deploy Cassandra -via a replication control or a daemonset, you will need to use the custom seed provider. -In Cassandra, a `SeedProvider` bootstraps the gossip protocol that Cassandra uses to find other -Cassandra nodes. Seed addresses are hosts deemed as contact points. Cassandra -instances use the seed list to find each other and learn the topology of the -ring. The [`KubernetesSeedProvider`](https://github.com/kubernetes/examples/blob/master/cassandra/java/src/main/java/io/k8s/cassandra/KubernetesSeedProvider.java) -discovers Cassandra seeds IP addresses via the Kubernetes API, those Cassandra -instances are defined within the Cassandra Service. - -Refer to the custom seed provider [README](https://git.k8s.io/examples/cassandra/java/README.md) for further -`KubernetesSeedProvider` configurations. For this example you should not need -to customize the Seed Provider configurations. - -See the [image](https://github.com/kubernetes/examples/tree/master/cassandra/image) directory of this example for specifics on -how the container docker image was built and what it contains. - -You may also note that we are setting some Cassandra parameters (`MAX_HEAP_SIZE` -and `HEAP_NEWSIZE`), and adding information about the -[namespace](/docs/user-guide/namespaces). -We also tell Kubernetes that the container exposes -both the `CQL` and `Thrift` API ports. Finally, we tell the cluster -manager that we need 0.1 cpu (0.1 core). +{% endcapture %} +{% include templates/tutorial.md %} [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/cassandra/README.md?pixel)]() diff --git a/docs/tutorials/stateful-application/zookeeper.yaml b/docs/tutorials/stateful-application/zookeeper.yaml index 29ea198e23..6fbce97825 100644 --- a/docs/tutorials/stateful-application/zookeeper.yaml +++ b/docs/tutorials/stateful-application/zookeeper.yaml @@ -150,8 +150,6 @@ spec: volumeClaimTemplates: - metadata: name: datadir - annotations: - volume.alpha.kubernetes.io/storage-class: anything spec: accessModes: [ "ReadWriteOnce" ] resources: diff --git a/docs/tutorials/stateless-application/hello-minikube.md b/docs/tutorials/stateless-application/hello-minikube.md index 47fabb336f..0e4e21fc55 100644 --- a/docs/tutorials/stateless-application/hello-minikube.md +++ b/docs/tutorials/stateless-application/hello-minikube.md @@ -1,9 +1,5 @@ --- - title: Hello Minikube -redirect_from: -- "/docs/hellonode/" -- "/docs/hellonode.html" --- {% capture overview %} @@ -77,10 +73,10 @@ brew install kubectl Determine whether you can access sites like [https://cloud.google.com/container-registry/](https://cloud.google.com/container-registry/) directly without a proxy, by opening a new terminal and using ```shell -curl --proxy "" https://cloud.google.com/container-registry/ +curl --proxy "" https://cloud.google.com/container-registry/ ``` -If NO proxy is required, start the Minikube cluster: +If NO proxy is required, start the Minikube cluster: ```shell minikube start --vm-driver=xhyve diff --git a/docs/user-guide/liveness/image/Dockerfile b/docs/user-guide/liveness/image/Dockerfile deleted file mode 100644 index 2c5481c63e..0000000000 --- a/docs/user-guide/liveness/image/Dockerfile +++ /dev/null @@ -1,18 +0,0 @@ -# Copyright 2016 The Kubernetes Authors All rights reserved. -# -# Licensed under the Apache License, Version 2.0 (the "License"); -# you may not use this file except in compliance with the License. -# You may obtain a copy of the License at -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an "AS IS" BASIS, -# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -# See the License for the specific language governing permissions and -# limitations under the License. - -FROM scratch - -ADD server /server - diff --git a/docs/user-guide/liveness/image/Makefile b/docs/user-guide/liveness/image/Makefile deleted file mode 100644 index b1a708dc14..0000000000 --- a/docs/user-guide/liveness/image/Makefile +++ /dev/null @@ -1,27 +0,0 @@ -# Copyright 2016 The Kubernetes Authors All rights reserved. -# -# Licensed under the Apache License, Version 2.0 (the "License"); -# you may not use this file except in compliance with the License. -# You may obtain a copy of the License at -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an "AS IS" BASIS, -# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -# See the License for the specific language governing permissions and -# limitations under the License. - -all: push - -server: server.go - CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -ldflags '-w' ./server.go - -container: server - docker build -t gcr.io/google_containers/liveness . - -push: container - gcloud docker -- push gcr.io/google_containers/liveness - -clean: - rm -f server diff --git a/docs/user-guide/liveness/image/README.md b/docs/user-guide/liveness/image/README.md new file mode 100644 index 0000000000..3b316fee59 --- /dev/null +++ b/docs/user-guide/liveness/image/README.md @@ -0,0 +1 @@ +This image has moved to https://github.com/kubernetes/kubernetes/tree/master/test/images/liveness \ No newline at end of file diff --git a/docs/user-guide/liveness/image/server.go b/docs/user-guide/liveness/image/server.go deleted file mode 100644 index 26c337e767..0000000000 --- a/docs/user-guide/liveness/image/server.go +++ /dev/null @@ -1,46 +0,0 @@ -/* -Copyright 2014 The Kubernetes Authors All rights reserved. - -Licensed under the Apache License, Version 2.0 (the "License"); -you may not use this file except in compliance with the License. -You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, software -distributed under the License is distributed on an "AS IS" BASIS, -WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -See the License for the specific language governing permissions and -limitations under the License. -*/ - -// A simple server that is alive for 10 seconds, then reports unhealthy for -// the rest of its (hopefully) short existence. -package main - -import ( - "fmt" - "log" - "net/http" - "time" -) - -func main() { - started := time.Now() - http.HandleFunc("/started", func(w http.ResponseWriter, r *http.Request) { - w.WriteHeader(200) - data := (time.Now().Sub(started)).String() - w.Write([]byte(data)) - }) - http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) { - duration := time.Now().Sub(started) - if duration.Seconds() > 10 { - w.WriteHeader(500) - w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds()))) - } else { - w.WriteHeader(200) - w.Write([]byte("ok")) - } - }) - log.Fatal(http.ListenAndServe(":8080", nil)) -} diff --git a/docs/user-guide/update-demo/build-images.sh b/docs/user-guide/update-demo/build-images.sh deleted file mode 100755 index 63c0fe9298..0000000000 --- a/docs/user-guide/update-demo/build-images.sh +++ /dev/null @@ -1,30 +0,0 @@ -#!/bin/bash - -# Copyright 2014 The Kubernetes Authors All rights reserved. -# -# Licensed under the Apache License, Version 2.0 (the "License"); -# you may not use this file except in compliance with the License. -# You may obtain a copy of the License at -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an "AS IS" BASIS, -# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -# See the License for the specific language governing permissions and -# limitations under the License. - -# This script will build and push the images necessary for the demo. - -set -o errexit -set -o nounset -set -o pipefail - -DOCKER_HUB_USER=${DOCKER_HUB_USER:-kubernetes} - -set -x - -docker build -t "${DOCKER_HUB_USER}/update-demo:kitten" images/kitten -docker build -t "${DOCKER_HUB_USER}/update-demo:nautilus" images/nautilus - -docker push "${DOCKER_HUB_USER}/update-demo" diff --git a/docs/user-guide/update-demo/images/kitten/Dockerfile b/docs/user-guide/update-demo/images/kitten/Dockerfile deleted file mode 100644 index aef0de58c6..0000000000 --- a/docs/user-guide/update-demo/images/kitten/Dockerfile +++ /dev/null @@ -1,17 +0,0 @@ -# Copyright 2016 The Kubernetes Authors All rights reserved. -# -# Licensed under the Apache License, Version 2.0 (the "License"); -# you may not use this file except in compliance with the License. -# You may obtain a copy of the License at -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an "AS IS" BASIS, -# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -# See the License for the specific language governing permissions and -# limitations under the License. - -FROM kubernetes/test-webserver -COPY html/kitten.jpg kitten.jpg -COPY html/data.json data.json diff --git a/docs/user-guide/update-demo/images/kitten/README.md b/docs/user-guide/update-demo/images/kitten/README.md new file mode 100644 index 0000000000..bc5f072bbc --- /dev/null +++ b/docs/user-guide/update-demo/images/kitten/README.md @@ -0,0 +1 @@ +This image has moved to https://github.com/kubernetes/kubernetes/tree/master/test/images/kitten \ No newline at end of file diff --git a/docs/user-guide/update-demo/images/kitten/html/data.json b/docs/user-guide/update-demo/images/kitten/html/data.json deleted file mode 100644 index 0be61a42b3..0000000000 --- a/docs/user-guide/update-demo/images/kitten/html/data.json +++ /dev/null @@ -1,3 +0,0 @@ -{ - "image": "kitten.jpg" -} diff --git a/docs/user-guide/update-demo/images/kitten/html/kitten.jpg b/docs/user-guide/update-demo/images/kitten/html/kitten.jpg deleted file mode 100644 index a382bf16ac..0000000000 Binary files a/docs/user-guide/update-demo/images/kitten/html/kitten.jpg and /dev/null differ diff --git a/docs/user-guide/update-demo/images/nautilus/Dockerfile b/docs/user-guide/update-demo/images/nautilus/Dockerfile deleted file mode 100644 index 16280b8215..0000000000 --- a/docs/user-guide/update-demo/images/nautilus/Dockerfile +++ /dev/null @@ -1,17 +0,0 @@ -# Copyright 2016 The Kubernetes Authors All rights reserved. -# -# Licensed under the Apache License, Version 2.0 (the "License"); -# you may not use this file except in compliance with the License. -# You may obtain a copy of the License at -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an "AS IS" BASIS, -# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -# See the License for the specific language governing permissions and -# limitations under the License. - -FROM kubernetes/test-webserver -COPY html/nautilus.jpg nautilus.jpg -COPY html/data.json data.json diff --git a/docs/user-guide/update-demo/images/nautilus/README.md b/docs/user-guide/update-demo/images/nautilus/README.md new file mode 100644 index 0000000000..4b2ddc9a60 --- /dev/null +++ b/docs/user-guide/update-demo/images/nautilus/README.md @@ -0,0 +1 @@ +This image has moved to https://github.com/kubernetes/kubernetes/tree/master/test/images/nautilus \ No newline at end of file diff --git a/docs/user-guide/update-demo/images/nautilus/html/data.json b/docs/user-guide/update-demo/images/nautilus/html/data.json deleted file mode 100644 index 2debee09a9..0000000000 --- a/docs/user-guide/update-demo/images/nautilus/html/data.json +++ /dev/null @@ -1,3 +0,0 @@ -{ - "image": "nautilus.jpg" -} diff --git a/docs/user-guide/update-demo/images/nautilus/html/nautilus.jpg b/docs/user-guide/update-demo/images/nautilus/html/nautilus.jpg deleted file mode 100644 index 544d2bd471..0000000000 Binary files a/docs/user-guide/update-demo/images/nautilus/html/nautilus.jpg and /dev/null differ diff --git a/js/redirects.js b/js/redirects.js index 3cd29fe6be..f7aae1ed62 100644 --- a/js/redirects.js +++ b/js/redirects.js @@ -3,7 +3,7 @@ $( document ).ready(function() { var notHere = false; var forwardingURL = window.location.href; - var oldURLs = ["/README.md","/README.html","/index.md",".html",".md","/v1.1/","/v1.0/"]; + var oldURLs = ["/README.md","/README.html","/index.md",".html",".md"]; /* var: forwardingRules * type: array of objects @@ -32,62 +32,6 @@ $( document ).ready(function() { "pattern":"\/contribute\/([0-9a-zA-Z\-\_]+)", "to":"/docs/home/contribute", "postfix":"/" - }, - { - "from":"/resource-quota", - "pattern":"", - "to":"/docs/concepts/policy/resource-quotas/", - "postfix":"" - }, - { - "from":"/horizontal-pod-autoscaler", - "pattern":"", - "to":"/docs/tasks/run-application/horizontal-pod-autoscale/", - "postfix":"" - }, - { - "from":"/docs/roadmap", - "pattern":"", - "to":"https://github.com/kubernetes/kubernetes/milestones/", - "postfix":"" - }, - { - "from":"/api-ref/", - "pattern":"", - "to":"https://github.com/kubernetes/kubernetes/milestones/", - "postfix":"" - }, - { - "from":"/kubernetes/third_party/swagger-ui/", - "pattern":"", - "to":"/docs/reference", - "postfix":"" - }, - { - "from":"/docs/user-guide/overview", - "pattern":"", - "to":"/docs/concepts/overview/what-is-kubernetes/", - "postfix":"" - }, - { - "from": "/docs/admin/multiple-schedulers", - "to": "/docs/tutorials/clusters/multiple-schedulers/" - }, - { - "from": "/docs/troubleshooting/", - "to": "/docs/tasks/debug-application-cluster/troubleshooting/" - }, - { - "from": "/docs/concepts/services-networking/networkpolicies/", - "to": "/docs/concepts/services-networking/network-policies/" - }, - { - "from": "/docs/getting-started-guides/meanstack/", - "to": "https://medium.com/google-cloud/running-a-mean-stack-on-google-cloud-platform-with-kubernetes-149ca81c2b5d" - }, - { - "from": "/docs/samples/", - "to": "/docs/tutorials/" } ]; diff --git a/skip_title_check.txt b/skip_title_check.txt index 7f1de8578c..29d3195ed9 100644 --- a/skip_title_check.txt +++ b/skip_title_check.txt @@ -11,4 +11,7 @@ docs/api-reference/v1/operations.md docs/user-guide/pods/_viewing-a-pod.md docs/user-guide/simple-yaml.md docs/concepts/abstractions/pod-termination.md -docs/contribute/README.md \ No newline at end of file +docs/contribute/README.md +docs/user-guide/liveness/image/README.md +docs/user-guide/update-demo/images/kitten/README.md +docs/user-guide/update-demo/images/nautilus/README.md diff --git a/skip_toc_check.txt b/skip_toc_check.txt index 60666bc805..46d01b0ec2 100644 --- a/skip_toc_check.txt +++ b/skip_toc_check.txt @@ -128,7 +128,6 @@ docs/user-guide/walkthrough/index.md docs/user-guide/walkthrough/k8s201.md docs/user-guide/working-with-resources.md docs/whatisk8s.md - docs/user-guide/configmap/index.md docs/user-guide/horizontal-pod-autoscaling/walkthrough.md docs/getting-started-guides/network-policy/walkthrough.md @@ -149,20 +148,6 @@ docs/admin/garbage-collection.md docs/admin/node-allocatable.md docs/user-guide/jobs/expansions/index.md docs/user-guide/ui/index.md - - - - - - - - - - - - - - - - - +docs/user-guide/liveness/image/README.md +docs/user-guide/update-demo/images/kitten/README.md +docs/user-guide/update-demo/images/nautilus/README.md diff --git a/test/examples_test.go b/test/examples_test.go index 9e58ff0ad4..011a68d4bd 100644 --- a/test/examples_test.go +++ b/test/examples_test.go @@ -43,6 +43,8 @@ import ( expvalidation "k8s.io/kubernetes/pkg/apis/extensions/validation" "k8s.io/kubernetes/pkg/apis/policy" policyvalidation "k8s.io/kubernetes/pkg/apis/policy/validation" + "k8s.io/kubernetes/pkg/apis/storage" + storagevalidation "k8s.io/kubernetes/pkg/apis/storage/validation" "k8s.io/kubernetes/pkg/capabilities" "k8s.io/kubernetes/pkg/registry/batch/job" schedulerapilatest "k8s.io/kubernetes/plugin/pkg/scheduler/api/latest" @@ -156,6 +158,9 @@ func validateObject(obj runtime.Object) (errors field.ErrorList) { t.Namespace = api.NamespaceDefault } errors = policyvalidation.ValidatePodDisruptionBudget(t) + case *storage.StorageClass: + // storageclass does not accept namespace + errors = storagevalidation.ValidateStorageClass(t) default: errors = field.ErrorList{} errors = append(errors, field.InternalError(field.NewPath(""), fmt.Errorf("no validation defined for %#v", obj))) @@ -215,15 +220,15 @@ func walkConfigFiles(inDir string, fn func(name, path string, data [][]byte)) er func TestExampleObjectSchemas(t *testing.T) { cases := map[string]map[string][]runtime.Object{ "../docs/user-guide/walkthrough": { - "deployment": {&extensions.Deployment{}}, - "deployment-update": {&extensions.Deployment{}}, - "pod-nginx": {&api.Pod{}}, - "pod-nginx-with-label": {&api.Pod{}}, - "pod-redis": {&api.Pod{}}, - "pod-with-http-healthcheck": {&api.Pod{}}, - "pod-with-tcp-socket-healthcheck": {&api.Pod{}}, - "podtemplate": {&api.PodTemplate{}}, - "service": {&api.Service{}}, + "deployment": {&extensions.Deployment{}}, + "deployment-update": {&extensions.Deployment{}}, + "pod-nginx": {&api.Pod{}}, + "pod-nginx-with-label": {&api.Pod{}}, + "pod-redis": {&api.Pod{}}, + "pod-with-http-healthcheck": {&api.Pod{}}, + "pod-with-tcp-socket-healthcheck": {&api.Pod{}}, + "podtemplate": {&api.PodTemplate{}}, + "service": {&api.Service{}}, }, "../docs/user-guide/update-demo": { "kitten-rc": {&api.ReplicationController{}}, @@ -326,14 +331,16 @@ func TestExampleObjectSchemas(t *testing.T) { "secret-env-pod": {&api.Pod{}}, }, "../docs/tutorials/stateful-application": { - "gce-volume": {&api.PersistentVolume{}}, - "mysql-deployment": {&api.Service{}, &api.PersistentVolumeClaim{}, &extensions.Deployment{}}, - "mysql-services": {&api.Service{}, &api.Service{}}, - "mysql-configmap": {&api.ConfigMap{}}, - "mysql-statefulset": {&apps.StatefulSet{}}, - "web": {&api.Service{}, &apps.StatefulSet{}}, - "webp": {&api.Service{}, &apps.StatefulSet{}}, - "zookeeper": {&api.Service{}, &api.ConfigMap{}, &policy.PodDisruptionBudget{}, &apps.StatefulSet{}}, + "gce-volume": {&api.PersistentVolume{}}, + "mysql-deployment": {&api.Service{}, &api.PersistentVolumeClaim{}, &extensions.Deployment{}}, + "mysql-services": {&api.Service{}, &api.Service{}}, + "mysql-configmap": {&api.ConfigMap{}}, + "mysql-statefulset": {&apps.StatefulSet{}}, + "cassandra-service": {&api.Service{}}, + "cassandra-statefulset": {&apps.StatefulSet{}, &storage.StorageClass{}}, + "web": {&api.Service{}, &apps.StatefulSet{}}, + "webp": {&api.Service{}, &apps.StatefulSet{}}, + "zookeeper": {&api.Service{}, &api.ConfigMap{}, &policy.PodDisruptionBudget{}, &apps.StatefulSet{}}, }, }