Moving docs from /vX to /docs; we will use branches for old versions.
This commit is contained in:
John Mulhausen
+1
-11
@@ -14,20 +14,10 @@ lsi: false
|
||||
defaults:
|
||||
-
|
||||
scope:
|
||||
path: "v1.1"
|
||||
path: "docs"
|
||||
values:
|
||||
version: "v1.1"
|
||||
versionfilesafe: "v1_1"
|
||||
layout: docwithnav
|
||||
showedit: true
|
||||
githubbranch: "release-1.1"
|
||||
-
|
||||
scope:
|
||||
path: "v1.2"
|
||||
values:
|
||||
version: "v1.2"
|
||||
versionfilesafe: "v1_2"
|
||||
layout: docwithnav
|
||||
showedit: true
|
||||
githubbranch: "release-1.2"
|
||||
permalink: pretty
|
||||
|
||||
@@ -2,178 +2,178 @@ bigheader: "Guides"
|
||||
abstract: "How to get started, and acheive tasks, using Kubernetes"
|
||||
toc:
|
||||
- title: Guides
|
||||
path: /v1.1/
|
||||
path: /docs/
|
||||
|
||||
- title: Quickstarts
|
||||
section:
|
||||
- title: What is Kubernetes?
|
||||
path: /v1.1/docs/whatisk8s/
|
||||
path: /docs/whatisk8s/
|
||||
- title: TODO - 5-minute Quickstart
|
||||
path: /v1.1/docs/hellonode/
|
||||
path: /docs/hellonode/
|
||||
- title: Kubernetes 101
|
||||
path: /v1.1/docs/user-guide/walkthrough/
|
||||
path: /docs/user-guide/walkthrough/
|
||||
- title: Kubernetes 201
|
||||
path: /v1.1/docs/user-guide/walkthrough/k8s201/
|
||||
path: /docs/user-guide/walkthrough/k8s201/
|
||||
|
||||
- title: Running Kubernetes
|
||||
section:
|
||||
- title: Picking the Right Solution
|
||||
path: /v1.1/docs/getting-started-guides/
|
||||
path: /docs/getting-started-guides/
|
||||
- title: Running Kubernetes on Your Local Machine
|
||||
section:
|
||||
- title: Running Kubernetes Locally via Docker
|
||||
path: /v1.1/docs/getting-started-guides/docker/
|
||||
path: /docs/getting-started-guides/docker/
|
||||
- title: Running Kubernetes Locally via Vagrant
|
||||
path: /v1.1/docs/getting-started-guides/vagrant/
|
||||
path: /docs/getting-started-guides/vagrant/
|
||||
- title: Running Kubernetes Locally with No VM
|
||||
path: /v1.1/docs/getting-started-guides/locally/
|
||||
path: /docs/getting-started-guides/locally/
|
||||
- title: Running Kubernetes on Turn-key Cloud Solutions
|
||||
section:
|
||||
- title: Running Kubernetes on Google Container Engine
|
||||
path: https://cloud.google.com/container-engine/docs/before-you-begin/
|
||||
- title: Running Kubernetes on Google Compute Engine
|
||||
path: /v1.1/docs/getting-started-guides/gce/
|
||||
path: /docs/getting-started-guides/gce/
|
||||
- title: Running Kubernetes on AWS EC2
|
||||
path: /v1.1/docs/getting-started-guides/aws/
|
||||
path: /docs/getting-started-guides/aws/
|
||||
- title: Running Kubernetes on Azure
|
||||
path: /v1.1/docs/getting-started-guides/coreos/azure/
|
||||
path: /docs/getting-started-guides/coreos/azure/
|
||||
- title: Running Kubernetes on Custom Solutions
|
||||
section:
|
||||
- title: Getting Started From Scratch
|
||||
path: /v1.1/docs/getting-started-guides/scratch/
|
||||
path: /docs/getting-started-guides/scratch/
|
||||
- title: Custom Cloud Solutions
|
||||
section:
|
||||
- title: AWS or GCE on CoreOS
|
||||
path: /v1.1/docs/getting-started-guides/coreos/
|
||||
path: /docs/getting-started-guides/coreos/
|
||||
- title: AWS or Joyent on Ubuntu
|
||||
path: /v1.1/docs/getting-started-guides/juju/
|
||||
path: /docs/getting-started-guides/juju/
|
||||
- title: Rackspace on CoreOS
|
||||
path: /v1.1/docs/getting-started-guides/rackspace/
|
||||
path: /docs/getting-started-guides/rackspace/
|
||||
- title: On-Premise VMs
|
||||
section:
|
||||
- title: Vagrant or VMware
|
||||
path: /v1.1/docs/getting-started-guides/coreos/
|
||||
path: /docs/getting-started-guides/coreos/
|
||||
- title: Cloudstack
|
||||
path: /v1.1/docs/getting-started-guides/cloudstack/
|
||||
path: /docs/getting-started-guides/cloudstack/
|
||||
- title: VMWare
|
||||
path: /v1.1/docs/getting-started-guides/vsphere/
|
||||
path: /docs/getting-started-guides/vsphere/
|
||||
- title: Juju
|
||||
path: /v1.1/docs/getting-started-guides/juju/
|
||||
path: /docs/getting-started-guides/juju/
|
||||
- title: libvirt on CoreOS
|
||||
path: /v1.1/docs/getting-started-guides/libvirt-coreos/
|
||||
path: /docs/getting-started-guides/libvirt-coreos/
|
||||
- title: oVirt
|
||||
path: /v1.1/docs/getting-started-guides/ovirt/
|
||||
path: /docs/getting-started-guides/ovirt/
|
||||
- title: libvirt or KVM
|
||||
path: /v1.1/docs/getting-started-guides/fedora/flannel_multi_node_cluster/
|
||||
path: /docs/getting-started-guides/fedora/flannel_multi_node_cluster/
|
||||
- title: Bare Metal
|
||||
section:
|
||||
- title: Offline
|
||||
path: /v1.1/docs/getting-started-guides/coreos/bare_metal_offline/
|
||||
path: /docs/getting-started-guides/coreos/bare_metal_offline/
|
||||
- title: Fedora via Ansible
|
||||
path: /v1.1/docs/getting-started-guides/fedora/fedora_ansible_config/
|
||||
path: /docs/getting-started-guides/fedora/fedora_ansible_config/
|
||||
- title: Fedora (Single Node)
|
||||
path: /v1.1/docs/getting-started-guides/fedora/fedora_manual_config/
|
||||
path: /docs/getting-started-guides/fedora/fedora_manual_config/
|
||||
- title: Fedora (Multi Node)
|
||||
path: /v1.1/docs/getting-started-guides/fedora/flannel_multi_node_cluster/
|
||||
path: /docs/getting-started-guides/fedora/flannel_multi_node_cluster/
|
||||
- title: Centos
|
||||
path: /v1.1/docs/getting-started-guides/centos/centos_manual_config/
|
||||
path: /docs/getting-started-guides/centos/centos_manual_config/
|
||||
- title: Ubuntu
|
||||
path: /v1.1/docs/getting-started-guides/ubuntu/
|
||||
path: /docs/getting-started-guides/ubuntu/
|
||||
- title: Docker (Multi Node)
|
||||
path: /v1.1/docs/getting-started-guides/docker-multinode/
|
||||
path: /docs/getting-started-guides/docker-multinode/
|
||||
|
||||
- title: Administering Clusters
|
||||
section:
|
||||
- title: Kubernetes Cluster Admin Guide
|
||||
path: /v1.1/docs/admin/
|
||||
path: /docs/admin/
|
||||
- title: Using Multiple Clusters
|
||||
path: /v1.1/docs/admin/multi-cluster/
|
||||
path: /docs/admin/multi-cluster/
|
||||
- title: Using Large Clusters
|
||||
path: /v1.1/docs/admin/cluster-large/
|
||||
path: /docs/admin/cluster-large/
|
||||
- title: Building High-Availability Clusters
|
||||
path: /v1.1/docs/admin/high-availability/
|
||||
path: /docs/admin/high-availability/
|
||||
- title: Accessing Clusters
|
||||
path: /v1.1/docs/user-guide/accessing-the-cluster/
|
||||
path: /docs/user-guide/accessing-the-cluster/
|
||||
- title: Sharing a Cluster
|
||||
path: /v1.1/docs/admin/namespaces/
|
||||
path: /docs/admin/namespaces/
|
||||
- title: Changing Cluster Size
|
||||
path: https://github.com/kubernetes/kubernetes/wiki/User-FAQ#how-do-i-change-the-size-of-my-cluster/
|
||||
- title: Creating a Custom Cluster from Scratch
|
||||
path: /v1.1/docs/getting-started-guides/scratch/
|
||||
path: /docs/getting-started-guides/scratch/
|
||||
- title: Authenticating Across Clusters with kubeconfig
|
||||
path: /v1.1/docs/user-guide/kubeconfig-file/
|
||||
path: /docs/user-guide/kubeconfig-file/
|
||||
|
||||
- title: Using Nodes, Pods, and Containers
|
||||
section:
|
||||
- title: Assigning Pods to Nodes
|
||||
path: /v1.1/docs/user-guide/node-selection/
|
||||
path: /docs/user-guide/node-selection/
|
||||
- title: Working with Containers
|
||||
path: /v1.1/docs/user-guide/production-pods/
|
||||
path: /docs/user-guide/production-pods/
|
||||
- title: Creating Pods with the Downward API
|
||||
path: /v1.1/docs/user-guide/downward-api/
|
||||
path: /docs/user-guide/downward-api/
|
||||
- title: Updating Live Pods
|
||||
path: /v1.1/docs/user-guide/update-demo/
|
||||
path: /docs/user-guide/update-demo/
|
||||
- title: Running Commands in a Container with kubectl exec
|
||||
path: /v1.1/docs/user-guide/getting-into-containers/
|
||||
path: /docs/user-guide/getting-into-containers/
|
||||
|
||||
- title: Networking
|
||||
section:
|
||||
- title: Networking in Kubernetes
|
||||
path: /v1.1/docs/admin/networking/
|
||||
path: /docs/admin/networking/
|
||||
- title: Setting Up and Configuring DNS
|
||||
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/cluster-dns
|
||||
- title: Connecting Applications
|
||||
path: /v1.1/docs/user-guide/connecting-applications/
|
||||
path: /docs/user-guide/connecting-applications/
|
||||
- title: Creating Servers with External IPs
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/examples/simple-nginx.md
|
||||
- title: Using DNS Pods and Services
|
||||
path: /v1.1/docs/admin/dns/
|
||||
path: /docs/admin/dns/
|
||||
- title: Connect with Proxies
|
||||
path: /v1.1/docs/user-guide/connecting-to-applications-proxy/
|
||||
path: /docs/user-guide/connecting-to-applications-proxy/
|
||||
- title: Connect with Port Forwarding
|
||||
path: /v1.1/docs/user-guide/connecting-to-applications-port-forward/
|
||||
path: /docs/user-guide/connecting-to-applications-port-forward/
|
||||
|
||||
- title: Configuring Kubernetes
|
||||
section:
|
||||
- title: Using Configuration Files
|
||||
path: /v1.1/docs/user-guide/simple-yaml/
|
||||
path: /docs/user-guide/simple-yaml/
|
||||
- title: Configuring Containers
|
||||
path: /v1.1/docs/user-guide/configuring-containers/
|
||||
path: /docs/user-guide/configuring-containers/
|
||||
- title: Using Environment Variables
|
||||
path: /v1.1/docs/user-guide/environment-guide/
|
||||
path: /docs/user-guide/environment-guide/
|
||||
- title: Managing Compute Resources
|
||||
path: /v1.1/docs/user-guide/compute-resources/
|
||||
path: /docs/user-guide/compute-resources/
|
||||
- title: Applying Resource Quotas and Limits
|
||||
path: /v1.1/docs/admin/resourcequota/
|
||||
path: /docs/admin/resourcequota/
|
||||
- title: Setting Pod CPU and Memory Limits
|
||||
path: /v1.1/docs/admin/limitrange/
|
||||
path: /docs/admin/limitrange/
|
||||
- title: Configuring Garbage Collection
|
||||
path: /v1.1/docs/admin/garbage-collection/
|
||||
path: /docs/admin/garbage-collection/
|
||||
- title: Configuring Kubernetes with Salt
|
||||
path: /v1.1/docs/admin/salt/
|
||||
path: /docs/admin/salt/
|
||||
- title: Best Practices for Configuration
|
||||
path: /v1.1/docs/user-guide/config-best-practices/
|
||||
path: /docs/user-guide/config-best-practices/
|
||||
|
||||
- title: Application Management and Deployment
|
||||
section:
|
||||
- title: "Managing Applications: Prerequisites"
|
||||
path: /v1.1/docs/user-guide/prereqs/
|
||||
path: /docs/user-guide/prereqs/
|
||||
- title: Managing Deployments
|
||||
path: /v1.1/docs/user-guide/managing-deployments/
|
||||
path: /docs/user-guide/managing-deployments/
|
||||
- title: Deploying Applications
|
||||
path: /v1.1/docs/user-guide/deploying-applications/
|
||||
path: /docs/user-guide/deploying-applications/
|
||||
- title: Launching, Exposing, and Killing Applications
|
||||
path: /v1.1/docs/user-guide/quick-start/
|
||||
path: /docs/user-guide/quick-start/
|
||||
|
||||
- title: Testing and Monitoring
|
||||
section:
|
||||
- title: Simulating Large Test Loads
|
||||
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/k8petstore
|
||||
- title: Checking Pod Health
|
||||
path: /v1.1/docs/user-guide/liveness/
|
||||
path: /docs/user-guide/liveness/
|
||||
- title: Using Explorer to Examine the Runtime Environment
|
||||
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/explorer
|
||||
- title: Resource Usage Monitoring
|
||||
path: /v1.1/docs/user-guide/monitoring/
|
||||
path: /docs/user-guide/monitoring/
|
||||
- title: Logging
|
||||
path: /v1.1/docs/user-guide/logging/
|
||||
path: /docs/user-guide/logging/
|
||||
+7
-14
@@ -1,15 +1,8 @@
|
||||
overrides:
|
||||
- path: v1.1/docs/api-reference
|
||||
- path: v1.1/docs/user-guide/kubectl
|
||||
- path: v1.1/docs/admin/kube-apiserver.md
|
||||
- path: v1.1/docs/admin/kube-controller-manager.md
|
||||
- path: v1.1/docs/admin/kube-proxy.md
|
||||
- path: v1.1/docs/admin/kube-scheduler.md
|
||||
- path: v1.1/docs/admin/kubelet.md
|
||||
- path: v1.2/docs/api-reference
|
||||
- path: v1.2/docs/user-guide/kubectl
|
||||
- path: v1.2/docs/admin/kube-apiserver.md
|
||||
- path: v1.2/docs/admin/kube-controller-manager.md
|
||||
- path: v1.2/docs/admin/kube-proxy.md
|
||||
- path: v1.2/docs/admin/kube-scheduler.md
|
||||
- path: v1.2/docs/admin/kubelet.md
|
||||
- path: docs/api-reference
|
||||
- path: docs/user-guide/kubectl
|
||||
- path: docs/admin/kube-apiserver.md
|
||||
- path: docs/admin/kube-controller-manager.md
|
||||
- path: docs/admin/kube-proxy.md
|
||||
- path: docs/admin/kube-scheduler.md
|
||||
- path: docs/admin/kubelet.md
|
||||
@@ -0,0 +1,184 @@
|
||||
bigheader: "Reference Documentation"
|
||||
abstract: "Design docs, concept definitions, and references for APIs and CLIs."
|
||||
toc:
|
||||
- title: Reference Documentation
|
||||
path: /docs/reference/
|
||||
|
||||
- title: Kubernetes API
|
||||
section:
|
||||
- title: Kubernetes API Overview
|
||||
path: /docs/api/
|
||||
- title: Kubernetes API Operations
|
||||
path: /docs/api-reference/v1/operations/
|
||||
- title: Kubernetes API Definitions
|
||||
path: /docs/api-reference/v1/definitions/
|
||||
|
||||
- title: Extensions API
|
||||
section:
|
||||
- title: Extensions API Operations
|
||||
path: /docs/api-reference/extensions/v1beta1/operations/
|
||||
- title: Extensions API Definitions
|
||||
path: /docs/api-reference/extensions/v1beta1/definitions/
|
||||
|
||||
- title: kubectl
|
||||
section:
|
||||
- title: kubectl Overview
|
||||
path: /docs/user-guide/kubectl-overview/
|
||||
- title: kubectl for Docker Users
|
||||
path: /docs/user-guide/docker-cli-to-kubectl/
|
||||
- title: kubectl Commands
|
||||
section:
|
||||
- title: kubectl
|
||||
path: /docs/user-guide/kubectl/kubectl/
|
||||
- title: kubectl annotate
|
||||
path: /docs/user-guide/kubectl/kubectl_annotate/
|
||||
- title: kubectl api-versions
|
||||
path: /docs/user-guide/kubectl/kubectl_api-versions/
|
||||
- title: kubectl apply
|
||||
path: /docs/user-guide/kubectl/kubectl_apply/
|
||||
- title: kubectl attach
|
||||
path: /docs/user-guide/kubectl/kubectl_attach/
|
||||
- title: kubectl autoscale
|
||||
path: /docs/user-guide/kubectl/kubectl_autoscale/
|
||||
- title: kubectl cluster-info
|
||||
path: /docs/user-guide/kubectl/kubectl_cluster-info/
|
||||
- title: kubectl config
|
||||
path: /docs/user-guide/kubectl/kubectl_config/
|
||||
- title: kubectl config set-cluster
|
||||
path: /docs/user-guide/kubectl/kubectl_config_set-cluster/
|
||||
- title: kubectl config set-context
|
||||
path: /docs/user-guide/kubectl/kubectl_config_set-context/
|
||||
- title: kubectl set-credentials
|
||||
path: /docs/user-guide/kubectl/kubectl_config_set-credentials/
|
||||
- title: kubectl config set
|
||||
path: /docs/user-guide/kubectl/kubectl_config_set/
|
||||
- title: kubectl config unset
|
||||
path: /docs/user-guide/kubectl/kubectl_config_unset/
|
||||
- title: kubectl config use-context
|
||||
path: /docs/user-guide/kubectl/kubectl_config_use-context/
|
||||
- title: kubectl config view
|
||||
path: /docs/user-guide/kubectl/kubectl_config_view/
|
||||
- title: kubectl create
|
||||
path: /docs/user-guide/kubectl/kubectl_create/
|
||||
- title: kubectl delete
|
||||
path: /docs/user-guide/kubectl/kubectl_delete/
|
||||
- title: kubectl describe
|
||||
path: /docs/user-guide/kubectl/kubectl_describe/
|
||||
- title: kubectl edit
|
||||
path: /docs/user-guide/kubectl/kubectl_edit/
|
||||
- title: kubectl exec
|
||||
path: /docs/user-guide/kubectl/kubectl_exec/
|
||||
- title: kubectl expose
|
||||
path: /docs/user-guide/kubectl/kubectl_expose/
|
||||
- title: kubectl get
|
||||
path: /docs/user-guide/kubectl/kubectl_get/
|
||||
- title: kubectl label
|
||||
path: /docs/user-guide/kubectl/kubectl_label/
|
||||
- title: kubectl logs
|
||||
path: /docs/user-guide/kubectl/kubectl_logs/
|
||||
- title: kubectl patch
|
||||
path: /docs/user-guide/kubectl/kubectl_patch/
|
||||
- title: kubectl port-forward
|
||||
path: /docs/user-guide/kubectl/kubectl_port-forward/
|
||||
- title: kubectl proxy
|
||||
path: /docs/user-guide/kubectl/kubectl_proxy/
|
||||
- title: kubectl replace
|
||||
path: /docs/user-guide/kubectl/kubectl_replace/
|
||||
- title: kubectl rolling-update
|
||||
path: /docs/user-guide/kubectl/kubectl_rolling-update/
|
||||
- title: kubectl run
|
||||
path: /docs/user-guide/kubectl/kubectl_run/
|
||||
- title: kubectl scale
|
||||
path: /docs/user-guide/kubectl/kubectl_scale/
|
||||
- title: kubectl stop
|
||||
path: /docs/user-guide/kubectl/kubectl_stop/
|
||||
- title: kubectl version
|
||||
path: /docs/user-guide/kubectl/kubectl_version/
|
||||
|
||||
- title: kube-apiserver
|
||||
section:
|
||||
- title: Overview
|
||||
path: /docs/admin/kube-apiserver/
|
||||
- title: Authorization Plugins
|
||||
path: /docs/admin/authorization/
|
||||
- title: Authentication
|
||||
path: /docs/admin/authentication/
|
||||
- title: Accessing the API
|
||||
path: /docs/admin/accessing-the-api/
|
||||
- title: Admission Controllers
|
||||
path: /docs/admin/admission-controllers/
|
||||
- title: Managing Service Accounts
|
||||
path: /docs/admin/service-accounts-admin/
|
||||
|
||||
- title: kub-scheduler
|
||||
path: /docs/admin/kube-scheduler/
|
||||
|
||||
- title: kubelet
|
||||
path: /docs/admin/kubelet.md
|
||||
|
||||
- title: kube-proxy
|
||||
path: /docs/admin/kube-proxy/
|
||||
|
||||
- title: JSONpath
|
||||
path: /docs/user-guide/jsonpath/
|
||||
|
||||
- title: etcd
|
||||
path: /docs/admin/etcd/
|
||||
|
||||
- title: Concept Definitions
|
||||
section:
|
||||
- title: Container Environment
|
||||
path: /docs/user-guide/container-environment/
|
||||
- title: Images
|
||||
path: /docs/user-guide/images/
|
||||
- title: Pods
|
||||
path: /docs/user-guide/pods/
|
||||
- title: Labels and Selectors
|
||||
path: /docs/user-guide/labels/
|
||||
- title: Replication Controller
|
||||
path: /docs/user-guide/replication-controller/
|
||||
- title: Services
|
||||
path: /docs/user-guide/services/
|
||||
- title: Volumes
|
||||
path: /docs/user-guide/volumes/
|
||||
- title: Persistent Volumes
|
||||
path: /docs/user-guide/persistent-volumes/
|
||||
- title: Secrets
|
||||
path: /docs/user-guide/secrets/
|
||||
- title: Names
|
||||
path: /docs/user-guide/identifiers/
|
||||
- title: Namespaces
|
||||
path: /docs/user-guide/namespaces/
|
||||
- title: Nodes
|
||||
path: /docs/admin/node/
|
||||
- title: Service Accounts
|
||||
path: /docs/user-guide/service-accounts/
|
||||
- title: Annotations
|
||||
path: /docs/user-guide/annotations/
|
||||
- title: Daemon Sets
|
||||
path: /docs/admin/daemons/
|
||||
- title: Deployments
|
||||
path: /docs/user-guide/deployments/
|
||||
- title: Ingress Resources
|
||||
path: /docs/user-guide/ingress/
|
||||
- title: Horizontal Pod Autoscaling
|
||||
path: /docs/user-guide/horizontal-pod-autoscaler/
|
||||
- title: Jobs
|
||||
path: /docs/user-guide/jobs/
|
||||
- title: Resource Quotas
|
||||
path: /docs/admin/resource-quota/
|
||||
|
||||
- title: Kubernetes Design Docs
|
||||
section:
|
||||
- title: Kubernetes Architecture
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/architecture.md
|
||||
- title: Kubernetes Design Overview
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/
|
||||
- title: Security in Kubernetes
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/security.md
|
||||
- title: Kubernetes Identity and Access Management
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/access.md
|
||||
- title: Security Contexts
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/security_context.md
|
||||
- title: Kubernetes OpenVSwitch GRE/VxLAN networking
|
||||
path: /docs/admin/ovs-networking/
|
||||
@@ -2,7 +2,7 @@ bigheader: "Samples"
|
||||
abstract: "A collection of example applications that show how to use Kubernetes."
|
||||
toc:
|
||||
- title: Samples
|
||||
path: /v1.2/samples/
|
||||
path: /docs/samples/
|
||||
|
||||
- title: Clustered Application Samples
|
||||
section:
|
||||
@@ -31,7 +31,7 @@ toc:
|
||||
- title: Ceph
|
||||
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/rbd/
|
||||
- title: MEAN stack on Google Cloud Platform
|
||||
path: /v1.2/docs/getting-started-guides/meanstack/
|
||||
path: /docs/getting-started-guides/meanstack/
|
||||
|
||||
- title: Persistent Volume Samples
|
||||
section:
|
||||
@@ -2,16 +2,16 @@ bigheader: "Support"
|
||||
abstract: "Troubleshooting resources, frequently asked questions, and community support channels."
|
||||
toc:
|
||||
- title: Support
|
||||
path: /v1.1/docs/troubleshooting/
|
||||
path: /docs/troubleshooting/
|
||||
|
||||
- title: Troubleshooting
|
||||
section:
|
||||
- title: Web Interface
|
||||
path: /v1.1/docs/user-guide/ui/
|
||||
path: /docs/user-guide/ui/
|
||||
- title: Troubleshooting Applications
|
||||
path: /v1.1/docs/user-guide/application-troubleshooting/
|
||||
path: /docs/user-guide/application-troubleshooting/
|
||||
- title: Troubleshooting Clusters
|
||||
path: /v1.1/docs/admin/cluster-troubleshooting/
|
||||
path: /docs/admin/cluster-troubleshooting/
|
||||
|
||||
- title: Frequently Asked Questions
|
||||
section:
|
||||
@@ -25,16 +25,16 @@ toc:
|
||||
- title: Other Resources
|
||||
section:
|
||||
- title: Known Issues
|
||||
path: /v1.1/docs/user-guide/known-issues/
|
||||
path: /docs/user-guide/known-issues/
|
||||
- title: Kubernetes Issue Tracker on GitHub
|
||||
path: https://github.com/kubernetes/kubernetes/issues/
|
||||
- title: Report a Security Vulnerability
|
||||
path: /v1.1/docs/reporting-security-issues/
|
||||
path: /docs/reporting-security-issues/
|
||||
- title: Release Notes
|
||||
path: https://github.com/kubernetes/kubernetes/releases/
|
||||
- title: Release Roadmap
|
||||
path: /v1.1/docs/roadmap/
|
||||
path: /docs/roadmap/
|
||||
- title: Contributing to Kubernetes Documentation
|
||||
path: /v1.1/editdocs/
|
||||
path: /docs/editdocs/
|
||||
- title: Sitemap for v1.1
|
||||
path: /v1.1/pagelist/
|
||||
path: /docs/pagelist/
|
||||
@@ -1,184 +0,0 @@
|
||||
bigheader: "Reference Documentation"
|
||||
abstract: "Design docs, concept definitions, and references for APIs and CLIs."
|
||||
toc:
|
||||
- title: Reference Documentation
|
||||
path: /v1.1/reference/
|
||||
|
||||
- title: Kubernetes API
|
||||
section:
|
||||
- title: Kubernetes API Overview
|
||||
path: /v1.1/docs/api/
|
||||
- title: Kubernetes API Operations
|
||||
path: http://kubernetes.io/v1.1/docs/api-reference/v1/operations.html
|
||||
- title: Kubernetes API Definitions
|
||||
path: http://kubernetes.io/v1.1/docs/api-reference/v1/definitions.html
|
||||
|
||||
- title: Extensions API
|
||||
section:
|
||||
- title: Extensions API Operations
|
||||
path: http://kubernetes.io/v1.1/docs/api-reference/extensions/v1beta1/operations.html
|
||||
- title: Extensions API Definitions
|
||||
path: http://kubernetes.io/v1.1/docs/api-reference/extensions/v1beta1/definitions.html
|
||||
|
||||
- title: kubectl
|
||||
section:
|
||||
- title: kubectl Overview
|
||||
path: /v1.1/docs/user-guide/kubectl-overview/
|
||||
- title: kubectl for Docker Users
|
||||
path: /v1.1/docs/user-guide/docker-cli-to-kubectl/
|
||||
- title: kubectl Commands
|
||||
section:
|
||||
- title: kubectl
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl.md
|
||||
- title: kubectl annotate
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_annotate.md
|
||||
- title: kubectl api-versions
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_api-versions.md
|
||||
- title: kubectl apply
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_apply.md
|
||||
- title: kubectl attach
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_attach.md
|
||||
- title: kubectl autoscale
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_autoscale.md
|
||||
- title: kubectl cluster-info
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_cluster-info.md
|
||||
- title: kubectl config
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_config.md
|
||||
- title: kubectl config set-cluster
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_config_set-cluster.md
|
||||
- title: kubectl config set-context
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_config_set-context.md
|
||||
- title: kubectl set-credentials
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_config_set-credentials.md
|
||||
- title: kubectl config set
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_config_set.md
|
||||
- title: kubectl config unset
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_config_unset.md
|
||||
- title: kubectl config use-context
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_config_use-context.md
|
||||
- title: kubectl config view
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_config_view.md
|
||||
- title: kubectl create
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_create.md
|
||||
- title: kubectl delete
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_delete.md
|
||||
- title: kubectl describe
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_describe.md
|
||||
- title: kubectl edit
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_edit.md
|
||||
- title: kubectl exec
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_exec.md
|
||||
- title: kubectl expose
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_expose.md
|
||||
- title: kubectl get
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_get.md
|
||||
- title: kubectl label
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_label.md
|
||||
- title: kubectl logs
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_logs.md
|
||||
- title: kubectl patch
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_patch.md
|
||||
- title: kubectl port-forward
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_port-forward.md
|
||||
- title: kubectl proxy
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_proxy.md
|
||||
- title: kubectl replace
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_replace.md
|
||||
- title: kubectl rolling-update
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_rolling-update.md
|
||||
- title: kubectl run
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_run.md
|
||||
- title: kubectl scale
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_scale.md
|
||||
- title: kubectl stop
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_stop.md
|
||||
- title: kubectl version
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_version.md
|
||||
|
||||
- title: kube-apiserver
|
||||
section:
|
||||
- title: Overview
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/admin/kube-apiserver.md
|
||||
- title: Authorization Plugins
|
||||
path: /v1.1/docs/admin/authorization/
|
||||
- title: Authentication
|
||||
path: /v1.1/docs/admin/authentication/
|
||||
- title: Accessing the API
|
||||
path: /v1.1/docs/admin/accessing-the-api/
|
||||
- title: Admission Controllers
|
||||
path: /v1.1/docs/admin/admission-controllers/
|
||||
- title: Managing Service Accounts
|
||||
path: /v1.1/docs/admin/service-accounts-admin/
|
||||
|
||||
- title: kub-scheduler
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/admin/kube-scheduler.md
|
||||
|
||||
- title: kubelet
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/admin/kubelet.md
|
||||
|
||||
- title: kube-proxy
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/admin/kube-proxy.md
|
||||
|
||||
- title: JSONpath
|
||||
path: /v1.1/docs/user-guide/jsonpath/
|
||||
|
||||
- title: etcd
|
||||
path: /v1.1/docs/admin/etcd/
|
||||
|
||||
- title: Concept Definitions
|
||||
section:
|
||||
- title: Container Environment
|
||||
path: /v1.1/docs/user-guide/container-environment/
|
||||
- title: Images
|
||||
path: /v1.1/docs/user-guide/images/
|
||||
- title: Pods
|
||||
path: /v1.1/docs/user-guide/pods/
|
||||
- title: Labels and Selectors
|
||||
path: /v1.1/docs/user-guide/labels/
|
||||
- title: Replication Controller
|
||||
path: /v1.1/docs/user-guide/replication-controller/
|
||||
- title: Services
|
||||
path: /v1.1/docs/user-guide/services/
|
||||
- title: Volumes
|
||||
path: /v1.1/docs/user-guide/volumes/
|
||||
- title: Persistent Volumes
|
||||
path: /v1.1/docs/user-guide/persistent-volumes/
|
||||
- title: Secrets
|
||||
path: /v1.1/docs/user-guide/secrets/
|
||||
- title: Names
|
||||
path: /v1.1/docs/user-guide/identifiers/
|
||||
- title: Namespaces
|
||||
path: /v1.1/docs/user-guide/namespaces/
|
||||
- title: Nodes
|
||||
path: /v1.1/docs/admin/node/
|
||||
- title: Service Accounts
|
||||
path: /v1.1/docs/user-guide/service-accounts/
|
||||
- title: Annotations
|
||||
path: /v1.1/docs/user-guide/annotations/
|
||||
- title: Daemon Sets
|
||||
path: /v1.1/docs/admin/daemons/
|
||||
- title: Deployments
|
||||
path: /v1.1/docs/user-guide/deployments/
|
||||
- title: Ingress Resources
|
||||
path: /v1.1/docs/user-guide/ingress/
|
||||
- title: Horizontal Pod Autoscaling
|
||||
path: /v1.1/docs/user-guide/horizontal-pod-autoscaler/
|
||||
- title: Jobs
|
||||
path: /v1.1/docs/user-guide/jobs/
|
||||
- title: Resource Quotas
|
||||
path: /v1.1/docs/admin/resource-quota/
|
||||
|
||||
- title: Kubernetes Design Docs
|
||||
section:
|
||||
- title: Kubernetes Architecture
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/architecture.md
|
||||
- title: Kubernetes Design Overview
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/
|
||||
- title: Security in Kubernetes
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/security.md
|
||||
- title: Kubernetes Identity and Access Management
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/access.md
|
||||
- title: Security Contexts
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/security_context.md
|
||||
- title: Kubernetes OpenVSwitch GRE/VxLAN networking
|
||||
path: /v1.1/docs/admin/ovs-networking/
|
||||
@@ -1,54 +0,0 @@
|
||||
bigheader: "Samples"
|
||||
abstract: "A collection of example applications that show how to use Kubernetes."
|
||||
toc:
|
||||
- title: Samples
|
||||
path: /v1.1/samples/
|
||||
|
||||
- title: Clustered Application Samples
|
||||
section:
|
||||
- title: Apache Cassandra Database
|
||||
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/cassandra
|
||||
- title: Apache Spark
|
||||
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/spark
|
||||
- title: Apache Storm
|
||||
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/storm
|
||||
- title: Distributed Task Queue
|
||||
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/celery-rabbitmq
|
||||
- title: Hazelcast
|
||||
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/hazelcast
|
||||
- title: Meteor Applications
|
||||
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/meteor/
|
||||
- title: Redis
|
||||
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/redis/
|
||||
- title: RethinkDB
|
||||
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/rethinkdb/
|
||||
- title: Elasticsearch/Kibana Logging Demonstration
|
||||
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/logging-demo/
|
||||
- title: Elasticsearch
|
||||
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/elasticsearch/
|
||||
- title: OpenShift Origin
|
||||
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/openshift-origin/
|
||||
- title: Ceph
|
||||
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/rbd/
|
||||
- title: MEAN stack on Google Cloud Platform
|
||||
path: /v1.1/docs/getting-started-guides/meanstack/
|
||||
|
||||
- title: Persistent Volume Samples
|
||||
section:
|
||||
- title: WordPress on a Kubernetes Persistent Volume
|
||||
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/mysql-wordpress-pd/
|
||||
- title: GlusterFS
|
||||
path: /https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/glusterfs/
|
||||
- title: iSCSI
|
||||
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/iscsi/
|
||||
- title: NFS
|
||||
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/nfs/
|
||||
|
||||
- title: Multi-tier Application Samples
|
||||
section:
|
||||
- title: Guestbook - Go Server
|
||||
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/guestbook-go/
|
||||
- title: GuestBook - PHP Server
|
||||
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/guestbook/
|
||||
- title: MySQL - Phabricator Server
|
||||
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/phabricator/
|
||||
@@ -1,5 +0,0 @@
|
||||
tocs:
|
||||
- guides
|
||||
- reference
|
||||
- samples
|
||||
- support
|
||||
@@ -1,179 +0,0 @@
|
||||
bigheader: "Guides"
|
||||
abstract: "How to get started, and acheive tasks, using Kubernetes"
|
||||
toc:
|
||||
- title: Guides
|
||||
path: /v1.2/
|
||||
|
||||
- title: Quickstarts
|
||||
section:
|
||||
- title: What is Kubernetes?
|
||||
path: /v1.2/docs/whatisk8s/
|
||||
- title: TODO - 5-minute Quickstart
|
||||
path: /v1.2/docs/hellonode/
|
||||
- title: Kubernetes 101
|
||||
path: /v1.2/docs/user-guide/walkthrough/
|
||||
- title: Kubernetes 201
|
||||
path: /v1.2/docs/user-guide/walkthrough/k8s201/
|
||||
|
||||
- title: Running Kubernetes
|
||||
section:
|
||||
- title: Picking the Right Solution
|
||||
path: /v1.2/docs/getting-started-guides/
|
||||
- title: Running Kubernetes on Your Local Machine
|
||||
section:
|
||||
- title: Running Kubernetes Locally via Docker
|
||||
path: /v1.2/docs/getting-started-guides/docker/
|
||||
- title: Running Kubernetes Locally via Vagrant
|
||||
path: /v1.2/docs/getting-started-guides/vagrant/
|
||||
- title: Running Kubernetes Locally with No VM
|
||||
path: /v1.2/docs/getting-started-guides/locally/
|
||||
- title: Running Kubernetes on Turn-key Cloud Solutions
|
||||
section:
|
||||
- title: Running Kubernetes on Google Container Engine
|
||||
path: https://cloud.google.com/container-engine/docs/before-you-begin/
|
||||
- title: Running Kubernetes on Google Compute Engine
|
||||
path: /v1.2/docs/getting-started-guides/gce/
|
||||
- title: Running Kubernetes on AWS EC2
|
||||
path: /v1.2/docs/getting-started-guides/aws/
|
||||
- title: Running Kubernetes on Azure
|
||||
path: /v1.2/docs/getting-started-guides/coreos/azure/
|
||||
- title: Running Kubernetes on Custom Solutions
|
||||
section:
|
||||
- title: Getting Started From Scratch
|
||||
path: /v1.2/docs/getting-started-guides/scratch/
|
||||
- title: Custom Cloud Solutions
|
||||
section:
|
||||
- title: AWS or GCE on CoreOS
|
||||
path: /v1.2/docs/getting-started-guides/coreos/
|
||||
- title: AWS or Joyent on Ubuntu
|
||||
path: /v1.2/docs/getting-started-guides/juju/
|
||||
- title: Rackspace on CoreOS
|
||||
path: /v1.2/docs/getting-started-guides/rackspace/
|
||||
- title: On-Premise VMs
|
||||
section:
|
||||
- title: Vagrant or VMware
|
||||
path: /v1.2/docs/getting-started-guides/coreos/
|
||||
- title: Cloudstack
|
||||
path: /v1.2/docs/getting-started-guides/cloudstack/
|
||||
- title: VMWare
|
||||
path: /v1.2/docs/getting-started-guides/vsphere/
|
||||
- title: Juju
|
||||
path: /v1.2/docs/getting-started-guides/juju/
|
||||
- title: libvirt on CoreOS
|
||||
path: /v1.2/docs/getting-started-guides/libvirt-coreos/
|
||||
- title: oVirt
|
||||
path: /v1.2/docs/getting-started-guides/ovirt/
|
||||
- title: libvirt or KVM
|
||||
path: /v1.2/docs/getting-started-guides/fedora/flannel_multi_node_cluster/
|
||||
- title: Bare Metal
|
||||
section:
|
||||
- title: Offline
|
||||
path: /v1.2/docs/getting-started-guides/coreos/bare_metal_offline/
|
||||
- title: Fedora via Ansible
|
||||
path: /v1.2/docs/getting-started-guides/fedora/fedora_ansible_config/
|
||||
- title: Fedora (Single Node)
|
||||
path: /v1.2/docs/getting-started-guides/fedora/fedora_manual_config/
|
||||
- title: Fedora (Multi Node)
|
||||
path: /v1.2/docs/getting-started-guides/fedora/flannel_multi_node_cluster/
|
||||
- title: Centos
|
||||
path: /v1.2/docs/getting-started-guides/centos/centos_manual_config/
|
||||
- title: Ubuntu
|
||||
path: /v1.2/docs/getting-started-guides/ubuntu/
|
||||
- title: Docker (Multi Node)
|
||||
path: /v1.2/docs/getting-started-guides/docker-multinode/
|
||||
|
||||
- title: Administering Clusters
|
||||
section:
|
||||
- title: Kubernetes Cluster Admin Guide
|
||||
path: /v1.2/docs/admin/
|
||||
- title: Using Multiple Clusters
|
||||
path: /v1.2/docs/admin/multi-cluster/
|
||||
- title: Using Large Clusters
|
||||
path: /v1.2/docs/admin/cluster-large/
|
||||
- title: Building High-Availability Clusters
|
||||
path: /v1.2/docs/admin/high-availability/
|
||||
- title: Accessing Clusters
|
||||
path: /v1.2/docs/user-guide/accessing-the-cluster/
|
||||
- title: Sharing a Cluster
|
||||
path: /v1.2/docs/admin/namespaces/
|
||||
- title: Changing Cluster Size
|
||||
path: https://github.com/kubernetes/kubernetes/wiki/User-FAQ#how-do-i-change-the-size-of-my-cluster/
|
||||
- title: Creating a Custom Cluster from Scratch
|
||||
path: /v1.2/docs/getting-started-guides/scratch/
|
||||
- title: Authenticating Across Clusters with kubeconfig
|
||||
path: /v1.2/docs/user-guide/kubeconfig-file/
|
||||
|
||||
- title: Using Nodes, Pods, and Containers
|
||||
section:
|
||||
- title: Assigning Pods to Nodes
|
||||
path: /v1.2/docs/user-guide/node-selection/
|
||||
- title: Working with Containers
|
||||
path: /v1.2/docs/user-guide/production-pods/
|
||||
- title: Creating Pods with the Downward API
|
||||
path: /v1.2/docs/user-guide/downward-api/
|
||||
- title: Updating Live Pods
|
||||
path: /v1.2/docs/user-guide/update-demo/
|
||||
- title: Running Commands in a Container with kubectl exec
|
||||
path: /v1.2/docs/user-guide/getting-into-containers/
|
||||
|
||||
- title: Networking
|
||||
section:
|
||||
- title: Networking in Kubernetes
|
||||
path: /v1.2/docs/admin/networking/
|
||||
- title: Setting Up and Configuring DNS
|
||||
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/cluster-dns
|
||||
- title: Connecting Applications
|
||||
path: /v1.2/docs/user-guide/connecting-applications/
|
||||
- title: Creating Servers with External IPs
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/examples/simple-nginx.md
|
||||
- title: Using DNS Pods and Services
|
||||
path: /v1.2/docs/admin/dns/
|
||||
- title: Connect with Proxies
|
||||
path: /v1.2/docs/user-guide/connecting-to-applications-proxy/
|
||||
- title: Connect with Port Forwarding
|
||||
path: /v1.2/docs/user-guide/connecting-to-applications-port-forward/
|
||||
|
||||
- title: Configuring Kubernetes
|
||||
section:
|
||||
- title: Using Configuration Files
|
||||
path: /v1.2/docs/user-guide/simple-yaml/
|
||||
- title: Configuring Containers
|
||||
path: /v1.2/docs/user-guide/configuring-containers/
|
||||
- title: Using Environment Variables
|
||||
path: /v1.2/docs/user-guide/environment-guide/
|
||||
- title: Managing Compute Resources
|
||||
path: /v1.2/docs/user-guide/compute-resources/
|
||||
- title: Applying Resource Quotas and Limits
|
||||
path: /v1.2/docs/admin/resourcequota/
|
||||
- title: Setting Pod CPU and Memory Limits
|
||||
path: /v1.2/docs/admin/limitrange/
|
||||
- title: Configuring Garbage Collection
|
||||
path: /v1.2/docs/admin/garbage-collection/
|
||||
- title: Configuring Kubernetes with Salt
|
||||
path: /v1.2/docs/admin/salt/
|
||||
- title: Best Practices for Configuration
|
||||
path: /v1.2/docs/user-guide/config-best-practices/
|
||||
|
||||
- title: Application Management and Deployment
|
||||
section:
|
||||
- title: "Managing Applications: Prerequisites"
|
||||
path: /v1.2/docs/user-guide/prereqs/
|
||||
- title: Managing Deployments
|
||||
path: /v1.2/docs/user-guide/managing-deployments/
|
||||
- title: Deploying Applications
|
||||
path: /v1.2/docs/user-guide/deploying-applications/
|
||||
- title: Launching, Exposing, and Killing Applications
|
||||
path: /v1.2/docs/user-guide/quick-start/
|
||||
|
||||
- title: Testing and Monitoring
|
||||
section:
|
||||
- title: Simulating Large Test Loads
|
||||
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/k8petstore
|
||||
- title: Checking Pod Health
|
||||
path: /v1.2/docs/user-guide/liveness/
|
||||
- title: Using Explorer to Examine the Runtime Environment
|
||||
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/explorer
|
||||
- title: Resource Usage Monitoring
|
||||
path: /v1.2/docs/user-guide/monitoring/
|
||||
- title: Logging
|
||||
path: /v1.2/docs/user-guide/logging/
|
||||
@@ -1,184 +0,0 @@
|
||||
bigheader: "Reference Documentation"
|
||||
abstract: "Design docs, concept definitions, and references for APIs and CLIs."
|
||||
toc:
|
||||
- title: Reference Documentation
|
||||
path: /v1.2/reference/
|
||||
|
||||
- title: Kubernetes API
|
||||
section:
|
||||
- title: Kubernetes API Overview
|
||||
path: /v1.2/docs/api/
|
||||
- title: Kubernetes API Operations
|
||||
path: http://kubernetes.io/v1.2/docs/api-reference/v1/operations.html
|
||||
- title: Kubernetes API Definitions
|
||||
path: http://kubernetes.io/v1.2/docs/api-reference/v1/definitions.html
|
||||
|
||||
- title: Extensions API
|
||||
section:
|
||||
- title: Extensions API Operations
|
||||
path: http://kubernetes.io/v1.2/docs/api-reference/extensions/v1beta1/operations.html
|
||||
- title: Extensions API Definitions
|
||||
path: http://kubernetes.io/v1.2/docs/api-reference/extensions/v1beta1/definitions.html
|
||||
|
||||
- title: kubectl
|
||||
section:
|
||||
- title: kubectl Overview
|
||||
path: /v1.2/docs/user-guide/kubectl-overview/
|
||||
- title: kubectl for Docker Users
|
||||
path: /v1.2/docs/user-guide/docker-cli-to-kubectl/
|
||||
- title: kubectl Commands
|
||||
section:
|
||||
- title: kubectl
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl.md
|
||||
- title: kubectl annotate
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_annotate.md
|
||||
- title: kubectl api-versions
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_api-versions.md
|
||||
- title: kubectl apply
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_apply.md
|
||||
- title: kubectl attach
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_attach.md
|
||||
- title: kubectl autoscale
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_autoscale.md
|
||||
- title: kubectl cluster-info
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_cluster-info.md
|
||||
- title: kubectl config
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_config.md
|
||||
- title: kubectl config set-cluster
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_config_set-cluster.md
|
||||
- title: kubectl config set-context
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_config_set-context.md
|
||||
- title: kubectl set-credentials
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_config_set-credentials.md
|
||||
- title: kubectl config set
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_config_set.md
|
||||
- title: kubectl config unset
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_config_unset.md
|
||||
- title: kubectl config use-context
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_config_use-context.md
|
||||
- title: kubectl config view
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_config_view.md
|
||||
- title: kubectl create
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_create.md
|
||||
- title: kubectl delete
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_delete.md
|
||||
- title: kubectl describe
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_describe.md
|
||||
- title: kubectl edit
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_edit.md
|
||||
- title: kubectl exec
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_exec.md
|
||||
- title: kubectl expose
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_expose.md
|
||||
- title: kubectl get
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_get.md
|
||||
- title: kubectl label
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_label.md
|
||||
- title: kubectl logs
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_logs.md
|
||||
- title: kubectl patch
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_patch.md
|
||||
- title: kubectl port-forward
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_port-forward.md
|
||||
- title: kubectl proxy
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_proxy.md
|
||||
- title: kubectl replace
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_replace.md
|
||||
- title: kubectl rolling-update
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_rolling-update.md
|
||||
- title: kubectl run
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_run.md
|
||||
- title: kubectl scale
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_scale.md
|
||||
- title: kubectl stop
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_stop.md
|
||||
- title: kubectl version
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_version.md
|
||||
|
||||
- title: kube-apiserver
|
||||
section:
|
||||
- title: Overview
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/admin/kube-apiserver.md
|
||||
- title: Authorization Plugins
|
||||
path: /v1.2/docs/admin/authorization/
|
||||
- title: Authentication
|
||||
path: /v1.2/docs/admin/authentication/
|
||||
- title: Accessing the API
|
||||
path: /v1.2/docs/admin/accessing-the-api/
|
||||
- title: Admission Controllers
|
||||
path: /v1.2/docs/admin/admission-controllers/
|
||||
- title: Managing Service Accounts
|
||||
path: /v1.2/docs/admin/service-accounts-admin/
|
||||
|
||||
- title: kub-scheduler
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/admin/kube-scheduler.md
|
||||
|
||||
- title: kubelet
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/admin/kubelet.md
|
||||
|
||||
- title: kube-proxy
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/admin/kube-proxy.md
|
||||
|
||||
- title: JSONpath
|
||||
path: /v1.2/docs/user-guide/jsonpath/
|
||||
|
||||
- title: etcd
|
||||
path: /v1.2/docs/admin/etcd/
|
||||
|
||||
- title: Concept Definitions
|
||||
section:
|
||||
- title: Container Environment
|
||||
path: /v1.2/docs/user-guide/container-environment/
|
||||
- title: Images
|
||||
path: /v1.2/docs/user-guide/images/
|
||||
- title: Pods
|
||||
path: /v1.2/docs/user-guide/pods/
|
||||
- title: Labels and Selectors
|
||||
path: /v1.2/docs/user-guide/labels/
|
||||
- title: Replication Controller
|
||||
path: /v1.2/docs/user-guide/replication-controller/
|
||||
- title: Services
|
||||
path: /v1.2/docs/user-guide/services/
|
||||
- title: Volumes
|
||||
path: /v1.2/docs/user-guide/volumes/
|
||||
- title: Persistent Volumes
|
||||
path: /v1.2/docs/user-guide/persistent-volumes/
|
||||
- title: Secrets
|
||||
path: /v1.2/docs/user-guide/secrets/
|
||||
- title: Names
|
||||
path: /v1.2/docs/user-guide/identifiers/
|
||||
- title: Namespaces
|
||||
path: /v1.2/docs/user-guide/namespaces/
|
||||
- title: Nodes
|
||||
path: /v1.2/docs/admin/node/
|
||||
- title: Service Accounts
|
||||
path: /v1.2/docs/user-guide/service-accounts/
|
||||
- title: Annotations
|
||||
path: /v1.2/docs/user-guide/annotations/
|
||||
- title: Daemon Sets
|
||||
path: /v1.2/docs/admin/daemons/
|
||||
- title: Deployments
|
||||
path: /v1.2/docs/user-guide/deployments/
|
||||
- title: Ingress Resources
|
||||
path: /v1.2/docs/user-guide/ingress/
|
||||
- title: Horizontal Pod Autoscaling
|
||||
path: /v1.2/docs/user-guide/horizontal-pod-autoscaler/
|
||||
- title: Jobs
|
||||
path: /v1.2/docs/user-guide/jobs/
|
||||
- title: Resource Quotas
|
||||
path: /v1.2/docs/admin/resource-quota/
|
||||
|
||||
- title: Kubernetes Design Docs
|
||||
section:
|
||||
- title: Kubernetes Architecture
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/architecture.md
|
||||
- title: Kubernetes Design Overview
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/
|
||||
- title: Security in Kubernetes
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/security.md
|
||||
- title: Kubernetes Identity and Access Management
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/access.md
|
||||
- title: Security Contexts
|
||||
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/security_context.md
|
||||
- title: Kubernetes OpenVSwitch GRE/VxLAN networking
|
||||
path: /v1.2/docs/admin/ovs-networking/
|
||||
@@ -1,40 +0,0 @@
|
||||
bigheader: "Support"
|
||||
abstract: "Troubleshooting resources, frequently asked questions, and community support channels."
|
||||
toc:
|
||||
- title: Support
|
||||
path: /v1.2/docs/troubleshooting/
|
||||
|
||||
- title: Troubleshooting
|
||||
section:
|
||||
- title: Web Interface
|
||||
path: /v1.2/docs/user-guide/ui/
|
||||
- title: Troubleshooting Applications
|
||||
path: /v1.2/docs/user-guide/application-troubleshooting/
|
||||
- title: Troubleshooting Clusters
|
||||
path: /v1.2/docs/admin/cluster-troubleshooting/
|
||||
|
||||
- title: Frequently Asked Questions
|
||||
section:
|
||||
- title: User FAQ
|
||||
path: https://github.com/kubernetes/kubernetes/wiki/User-FAQ/
|
||||
- title: Debugging FAQ
|
||||
path: https://github.com/kubernetes/kubernetes/wiki/Debugging-FAQ/
|
||||
- title: Services FAQ
|
||||
path: https://github.com/kubernetes/kubernetes/wiki/Services-FAQ/
|
||||
|
||||
- title: Other Resources
|
||||
section:
|
||||
- title: Known Issues
|
||||
path: /v1.2/docs/user-guide/known-issues/
|
||||
- title: Kubernetes Issue Tracker on GitHub
|
||||
path: https://github.com/kubernetes/kubernetes/issues/
|
||||
- title: Report a Security Vulnerability
|
||||
path: /v1.2/docs/reporting-security-issues/
|
||||
- title: Release Notes
|
||||
path: https://github.com/kubernetes/kubernetes/releases/
|
||||
- title: Release Roadmap
|
||||
path: /v1.2/docs/roadmap/
|
||||
- title: Contributing to Kubernetes Documentation
|
||||
path: /v1.2/editdocs/
|
||||
- title: Sitemap for v1.2
|
||||
path: /v1.2/pagelist/
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
---
|
||||
{% for thistoc in site.data[page.versionfilesafe].globals.tocs %}{% if foundTOC %}{% break %}{% else %}{% assign tree = site.data[page.versionfilesafe][thistoc].toc %}{% include tocsearch.html %}{% endif %}{% endfor %}
|
||||
{% for thistoc in site.data.globals.tocs %}{% if foundTOC %}{% break %}{% else %}{% assign tree = site.data[thistoc].toc %}{% include tocsearch.html %}{% endif %}{% endfor %}
|
||||
{% if page.title %}{% assign title=page.title %}{% endif %}
|
||||
<!Doctype html>
|
||||
<html id="docs">
|
||||
@@ -69,14 +69,14 @@
|
||||
|
||||
<!-- HERO -->
|
||||
<section id="hero" class="light-text">
|
||||
<h1>{{ site.data[page.versionfilesafe][foundTOC].bigheader }}</h1>
|
||||
<h5>{{ site.data[page.versionfilesafe][foundTOC].abstract }}</h5>
|
||||
<h1>{{ site.data[foundTOC].bigheader }}</h1>
|
||||
<h5>{{ site.data[foundTOC].abstract }}</h5>
|
||||
<div id="vendorStrip" class="light-text">
|
||||
<ul>
|
||||
<li><a href="/{{page.version}}/">GUIDES</a></li>
|
||||
<li><a href="/{{page.version}}/reference">REFERENCE</a></li>
|
||||
<li><a href="/{{page.version}}/samples">SAMPLES</a></li>
|
||||
<li><a href="/{{page.version}}/docs/troubleshooting/">SUPPORT</a></li>
|
||||
<li><a href="/docs/">GUIDES</a></li>
|
||||
<li><a href="/docs/reference">REFERENCE</a></li>
|
||||
<li><a href="/docs/samples">SAMPLES</a></li>
|
||||
<li><a href="/docs/troubleshooting/">SUPPORT</a></li>
|
||||
</ul>
|
||||
<div class="dropdown">
|
||||
<div class="readout"></div>
|
||||
@@ -90,10 +90,10 @@
|
||||
<section id="encyclopedia">
|
||||
<div id="docsToc">
|
||||
<div class="pi-accordion">
|
||||
{% assign tree = site.data[page.versionfilesafe][foundTOC].toc %}{% include tree.html %}
|
||||
{% assign tree = site.data[foundTOC].toc %}{% include tree.html %}
|
||||
</div> <!-- /pi-accordion -->
|
||||
</div> <!-- /docsToc -->
|
||||
<div id="docsContent"><a href="/{{ page.version }}/editdocs#{{ page.path }}" id="editPageButton">Edit This Page</a>
|
||||
<div id="docsContent"><a href="/docs/editdocs#{{ page.path }}" id="editPageButton">Edit This Page</a>
|
||||
<h1>{{ title }}</h1>
|
||||
{{ content }}
|
||||
<p><a href=""><img src="https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/{{ page.path }}?pixel" alt="Analytics" /></a>
|
||||
|
||||
@@ -7,7 +7,7 @@ cluster administrators who want to customize their cluster
|
||||
or understand the details.
|
||||
|
||||
Most questions about accessing the cluster are covered
|
||||
in [Accessing the cluster](/{{page.version}}/docs/user-guide/accessing-the-cluster).
|
||||
in [Accessing the cluster](/docs/user-guide/accessing-the-cluster).
|
||||
|
||||
|
||||
## Ports and IPs Served On
|
||||
@@ -27,10 +27,10 @@ By default the Kubernetes APIserver serves HTTP on 2 ports:
|
||||
- default is port 6443, change with `--secure-port` flag.
|
||||
- default IP is first non-localhost network interface, change with `--bind-address` flag.
|
||||
- serves HTTPS. Set cert with `--tls-cert-file` and key with `--tls-private-key-file` flag.
|
||||
- uses token-file or client-certificate based [authentication](/{{page.version}}/docs/admin/authentication).
|
||||
- uses policy-based [authorization](/{{page.version}}/docs/admin/authorization).
|
||||
- uses token-file or client-certificate based [authentication](/docs/admin/authentication).
|
||||
- uses policy-based [authorization](/docs/admin/authorization).
|
||||
3. Removed: ReadOnly Port
|
||||
- For security reasons, this had to be removed. Use the [service account](/{{page.version}}/docs/user-guide/service-accounts) feature instead.
|
||||
- For security reasons, this had to be removed. Use the [service account](/docs/user-guide/service-accounts) feature instead.
|
||||
|
||||
## Proxies and Firewall rules
|
||||
|
||||
@@ -54,7 +54,7 @@ variety of uses cases:
|
||||
running on the `kubernetes-master` machine. The proxy can use cert-based authentication
|
||||
or token-based authentication.
|
||||
2. Processes running in Containers on Kubernetes that need to read from
|
||||
the apiserver. Currently, these can use a [service account](/{{page.version}}/docs/user-guide/service-accounts).
|
||||
the apiserver. Currently, these can use a [service account](/docs/user-guide/service-accounts).
|
||||
3. Scheduler and Controller-manager processes, which need to do read-write
|
||||
API operations. Currently, these have to run on the same host as the
|
||||
apiserver and use the Localhost Port. In the future, these will be
|
||||
@@ -62,12 +62,12 @@ enabling this plug-in.
|
||||
|
||||
### ServiceAccount
|
||||
|
||||
This plug-in implements automation for [serviceAccounts](/{{page.version}}/docs/user-guide/service-accounts).
|
||||
This plug-in implements automation for [serviceAccounts](/docs/user-guide/service-accounts).
|
||||
We strongly recommend using this plug-in if you intend to make use of Kubernetes `ServiceAccount` objects.
|
||||
|
||||
### SecurityContextDeny
|
||||
|
||||
This plug-in will deny any pod with a [SecurityContext](/{{page.version}}/docs/user-guide/security-context) that defines options that were not available on the `Container`.
|
||||
This plug-in will deny any pod with a [SecurityContext](/docs/user-guide/security-context) that defines options that were not available on the `Container`.
|
||||
|
||||
### ResourceQuota
|
||||
|
||||
@@ -75,7 +75,7 @@ This plug-in will observe the incoming request and ensure that it does not viola
|
||||
enumerated in the `ResourceQuota` object in a `Namespace`. If you are using `ResourceQuota`
|
||||
objects in your Kubernetes deployment, you MUST use this plug-in to enforce quota constraints.
|
||||
|
||||
See the [resourceQuota design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/admission_control_resource_quota.md) and the [example of Resource Quota](/{{page.version}}/docs/admin/resourcequota/) for more details.
|
||||
See the [resourceQuota design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/admission_control_resource_quota.md) and the [example of Resource Quota](/docs/admin/resourcequota/) for more details.
|
||||
|
||||
It is strongly encouraged that this plug-in is configured last in the sequence of admission control plug-ins. This is
|
||||
so that quota is not prematurely incremented only for the request to be rejected later in admission control.
|
||||
@@ -88,7 +88,7 @@ your Kubernetes deployment, you MUST use this plug-in to enforce those constrain
|
||||
be used to apply default resource requests to Pods that don't specify any; currently, the default LimitRanger
|
||||
applies a 0.1 CPU requirement to all Pods in the `default` namespace.
|
||||
|
||||
See the [limitRange design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/admission_control_limit_range.md) and the [example of Limit Range](/{{page.version}}/docs/admin/limitrange/) for more details.
|
||||
See the [limitRange design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/admission_control_limit_range.md) and the [example of Limit Range](/docs/admin/limitrange/) for more details.
|
||||
|
||||
### InitialResources (experimental)
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
---
|
||||
|
||||
In Kubernetes, authorization happens as a separate step from authentication.
|
||||
See the [authentication documentation](/{{page.version}}/docs/admin/authentication) for an
|
||||
See the [authentication documentation](/docs/admin/authentication) for an
|
||||
overview of authentication.
|
||||
|
||||
Authorization applies to all HTTP accesses on the main (secure) apiserver port.
|
||||
@@ -15,7 +15,7 @@ unsatisfied).
|
||||
Master components could in theory be run on any node in the cluster. However,
|
||||
for simplicity, current set up scripts typically start all master components on
|
||||
the same VM, and does not run user containers on this VM. See
|
||||
[high-availability.md](/{{page.version}}/docs/admin/high-availability) for an example multi-master-VM setup.
|
||||
[high-availability.md](/docs/admin/high-availability) for an example multi-master-VM setup.
|
||||
|
||||
Even in the future, when Kubernetes is fully self-hosting, it will probably be
|
||||
wise to only allow master components to schedule on a subset of nodes, to limit
|
||||
@@ -24,19 +24,19 @@ node-compromising security exploit.
|
||||
|
||||
### kube-apiserver
|
||||
|
||||
[kube-apiserver](/{{page.version}}/docs/admin/kube-apiserver) exposes the Kubernetes API; it is the front-end for the
|
||||
[kube-apiserver](/docs/admin/kube-apiserver) exposes the Kubernetes API; it is the front-end for the
|
||||
Kubernetes control plane. It is designed to scale horizontally (i.e., one scales
|
||||
it by running more of them-- [high-availability.md](/{{page.version}}/docs/admin/high-availability)).
|
||||
it by running more of them-- [high-availability.md](/docs/admin/high-availability)).
|
||||
|
||||
### etcd
|
||||
|
||||
[etcd](/{{page.version}}/docs/admin/etcd) is used as Kubernetes' backing store. All cluster data is stored here.
|
||||
[etcd](/docs/admin/etcd) is used as Kubernetes' backing store. All cluster data is stored here.
|
||||
Proper administration of a Kubernetes cluster includes a backup plan for etcd's
|
||||
data.
|
||||
|
||||
### kube-controller-manager
|
||||
|
||||
[kube-controller-manager](/{{page.version}}/docs/admin/kube-controller-manager) is a binary that runs controllers, which are the
|
||||
[kube-controller-manager](/docs/admin/kube-controller-manager) is a binary that runs controllers, which are the
|
||||
background threads that handle routine tasks in the cluster. Logically, each
|
||||
controller is a separate process, but to reduce the number of moving pieces in
|
||||
the system, they are all compiled into a single binary and run in a single
|
||||
@@ -57,7 +57,7 @@ These controllers include:
|
||||
|
||||
### kube-scheduler
|
||||
|
||||
[kube-scheduler](/{{page.version}}/docs/admin/kube-scheduler) watches newly created pods that have no node assigned, and
|
||||
[kube-scheduler](/docs/admin/kube-scheduler) watches newly created pods that have no node assigned, and
|
||||
selects a node for them to run on.
|
||||
|
||||
### addons
|
||||
@@ -83,16 +83,16 @@ in their DNS searches.
|
||||
#### User interface
|
||||
|
||||
The kube-ui provides a read-only overview of the cluster state. Access
|
||||
[the UI using kubectl proxy](/{{page.version}}/docs/user-guide/connecting-to-applications-proxy/#connecting-to-the-kube-ui-service-from-your-local-workstation)
|
||||
[the UI using kubectl proxy](/docs/user-guide/connecting-to-applications-proxy/#connecting-to-the-kube-ui-service-from-your-local-workstation)
|
||||
|
||||
#### Container Resource Monitoring
|
||||
|
||||
[Container Resource Monitoring](/{{page.version}}/docs/user-guide/monitoring) records generic time-series metrics
|
||||
[Container Resource Monitoring](/docs/user-guide/monitoring) records generic time-series metrics
|
||||
about containers in a central database, and provides a UI for browsing that data.
|
||||
|
||||
#### Cluster-level Logging
|
||||
|
||||
[Container Logging](/{{page.version}}/docs/user-guide/monitoring.md) saves container logs
|
||||
[Container Logging](/docs/user-guide/monitoring.md) saves container logs
|
||||
to a central log store with search/browsing interface. There are two
|
||||
implementations:
|
||||
|
||||
@@ -109,7 +109,7 @@ the Kubernetes runtime environment.
|
||||
|
||||
### kubelet
|
||||
|
||||
[kubelet](/{{page.version}}/docs/admin/kubelet) is the primary node agent. It:
|
||||
[kubelet](/docs/admin/kubelet) is the primary node agent. It:
|
||||
* Watches for pods that have been assigned to its node (either by apiserver
|
||||
or via local configuration file) and:
|
||||
* Mounts the pod's required volumes
|
||||
@@ -122,7 +122,7 @@ the Kubernetes runtime environment.
|
||||
|
||||
### kube-proxy
|
||||
|
||||
[kube-proxy](/{{page.version}}/docs/admin/kube-proxy) enables the Kubernetes service abstraction by maintaining
|
||||
[kube-proxy](/docs/admin/kube-proxy) enables the Kubernetes service abstraction by maintaining
|
||||
network rules on the host and performing connection forwarding.
|
||||
|
||||
### docker
|
||||
@@ -66,4 +66,4 @@ To avoid running into cluster addon resource issues, when creating a cluster wit
|
||||
* [FluentD with ElasticSearch Plugin](http://releases.k8s.io/{{page.githubbranch}}/cluster/saltbase/salt/fluentd-es/fluentd-es.yaml)
|
||||
* [FluentD with GCP Plugin](http://releases.k8s.io/{{page.githubbranch}}/cluster/saltbase/salt/fluentd-gcp/fluentd-gcp.yaml)
|
||||
|
||||
For directions on how to detect if addon containers are hitting resource limits, see the [Troubleshooting section of Compute Resources](/{{page.version}}/docs/user-guide/compute-resources/#troubleshooting).
|
||||
For directions on how to detect if addon containers are hitting resource limits, see the [Troubleshooting section of Compute Resources](/docs/user-guide/compute-resources/#troubleshooting).
|
||||
@@ -8,7 +8,7 @@ running cluster.
|
||||
|
||||
## Creating and configuring a Cluster
|
||||
|
||||
To install Kubernetes on a set of machines, consult one of the existing [Getting Started guides](/{{page.version}}/docs/getting-started-guides/) depending on your environment.
|
||||
To install Kubernetes on a set of machines, consult one of the existing [Getting Started guides](/docs/getting-started-guides/) depending on your environment.
|
||||
|
||||
## Upgrading a cluster
|
||||
|
||||
@@ -63,7 +63,7 @@ recommend testing the upgrade on an experimental cluster before performing the u
|
||||
|
||||
## Resizing a cluster
|
||||
|
||||
If your cluster runs short on resources you can easily add more machines to it if your cluster is running in [Node self-registration mode](/{{page.version}}/docs/admin/node/#self-registration-of-nodes).
|
||||
If your cluster runs short on resources you can easily add more machines to it if your cluster is running in [Node self-registration mode](/docs/admin/node/#self-registration-of-nodes).
|
||||
If you're using GCE or GKE it's done by resizing Instance Group managing your Nodes. It can be accomplished by modifying number of instances on `Compute > Compute Engine > Instance groups > your group > Edit group` [Google Cloud Console page](https://console.developers.google.com) or using gcloud CLI:
|
||||
|
||||
```shell
|
||||
@@ -145,7 +145,7 @@ kubectl replace nodes $NODENAME --patch='{"apiVersion": "v1", "spec": {"unschedu
|
||||
|
||||
If you deleted the node's VM instance and created a new one, then a new schedulable node resource will
|
||||
be created automatically when you create a new VM instance (if you're using a cloud provider that supports
|
||||
node discovery; currently this is only Google Compute Engine, not including CoreOS on Google Compute Engine using kube-register). See [Node](/{{page.version}}/docs/admin/node) for more details.
|
||||
node discovery; currently this is only Google Compute Engine, not including CoreOS on Google Compute Engine using kube-register). See [Node](/docs/admin/node) for more details.
|
||||
|
||||
## Advanced Topics
|
||||
|
||||
@@ -3,8 +3,8 @@
|
||||
|
||||
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](/{{page.version}}/docs/user-guide/application-troubleshooting) for tips on application debugging.
|
||||
You may also visit [troubleshooting document](/{{page.version}}/docs/troubleshooting/) for more information.
|
||||
the [application troubleshooting guide](/docs/user-guide/application-troubleshooting) for tips on application debugging.
|
||||
You may also visit [troubleshooting document](/docs/troubleshooting/) for more information.
|
||||
|
||||
## Listing your cluster
|
||||
|
||||
@@ -89,7 +89,7 @@ Mitigations:
|
||||
- Action use IaaS providers reliable storage (e.g GCE PD or AWS EBS volume) for VMs with apiserver+etcd
|
||||
- Mitigates: Apiserver backing storage lost
|
||||
|
||||
- Action: Use (experimental) [high-availability](/{{page.version}}/docs/admin/high-availability) configuration
|
||||
- Action: Use (experimental) [high-availability](/docs/admin/high-availability) configuration
|
||||
- Mitigates: Master VM shutdown or master components (scheduler, API server, controller-managing) crashing
|
||||
- Will tolerate one or more simultaneous node or component failures
|
||||
- Mitigates: Apiserver backing storage (i.e., etcd's data directory) lost
|
||||
@@ -108,5 +108,5 @@ Mitigations:
|
||||
- Mitigates: Node shutdown
|
||||
- Mitigates: Kubelet software fault
|
||||
|
||||
- Action: [Multiple independent clusters](/{{page.version}}/docs/admin/multi-cluster) (and avoid making risky changes to all clusters at once)
|
||||
- Action: [Multiple independent clusters](/docs/admin/multi-cluster) (and avoid making risky changes to all clusters at once)
|
||||
- Mitigates: Everything listed above.
|
||||
@@ -26,30 +26,30 @@ but with different flags and/or different memory and cpu requests for different
|
||||
### Required Fields
|
||||
|
||||
As with all other Kubernetes config, a DaemonSet needs `apiVersion`, `kind`, and `metadata` fields. For
|
||||
general information about working with config files, see [here](/{{page.version}}/docs/user-guide/simple-yaml),
|
||||
[here](/{{page.version}}/docs/user-guide/configuring-containers), and [here](/{{page.version}}/docs/user-guide/working-with-resources).
|
||||
general information about working with config files, see [here](/docs/user-guide/simple-yaml),
|
||||
[here](/docs/user-guide/configuring-containers), and [here](/docs/user-guide/working-with-resources).
|
||||
|
||||
A DaemonSet also needs a [`.spec`](/{{page.version}}/docs/devel/api-conventions/#spec-and-status) section.
|
||||
A DaemonSet also needs a [`.spec`](/docs/devel/api-conventions/#spec-and-status) section.
|
||||
|
||||
### Pod Template
|
||||
|
||||
The `.spec.template` is the only required field of the `.spec`.
|
||||
|
||||
The `.spec.template` is a [pod template](/{{page.version}}/docs/user-guide/replication-controller/#pod-template).
|
||||
It has exactly the same schema as a [pod](/{{page.version}}/docs/user-guide/pods), except
|
||||
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`.
|
||||
|
||||
In addition to required fields for a pod, a pod template in a DaemonSet has to specify appropriate
|
||||
labels (see [pod selector](#pod-selector)).
|
||||
|
||||
A pod template in a DaemonSet must have a [`RestartPolicy`](/{{page.version}}/docs/user-guide/pod-states)
|
||||
A pod template in a DaemonSet must have a [`RestartPolicy`](/docs/user-guide/pod-states)
|
||||
equal to `Always`, or be unspecified, which defaults to `Always`.
|
||||
|
||||
### Pod Selector
|
||||
|
||||
The `.spec.selector` field is a pod selector. It works the same as the `.spec.selector` of
|
||||
a [ReplicationController](/{{page.version}}/docs/user-guide/replication-controller) or
|
||||
[Job](/{{page.version}}/docs/user-guide/jobs).
|
||||
a [ReplicationController](/docs/user-guide/replication-controller) or
|
||||
[Job](/docs/user-guide/jobs).
|
||||
|
||||
If the `.spec.selector` is specified, it must equal the `.spec.template.metadata.labels`. If not
|
||||
specified, the are default to be equal. Config with these unequal will be rejected by the API.
|
||||
@@ -64,7 +64,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](/{{page.version}}/docs/user-guide/node-selection/).
|
||||
selector](/docs/user-guide/node-selection/).
|
||||
|
||||
If you do not specify a `.spec.template.spec.nodeSelector`, then the DaemonSet controller will
|
||||
create pods on all nodes.
|
||||
@@ -75,7 +75,7 @@ Normally, the machine that a pod runs on is selected by the Kubernetes scheduler
|
||||
created by the Daemon controller have the machine already selected (`.spec.nodeName` is specified
|
||||
when the pod is created, so it is ignored by the scheduler). Therefore:
|
||||
|
||||
- the [`unschedulable`](/{{page.version}}/docs/admin/node/#manual-node-administration) field of a node is not respected
|
||||
- the [`unschedulable`](/docs/admin/node/#manual-node-administration) field of a node is not respected
|
||||
by the daemon set controller.
|
||||
- daemon set controller can make pods even when the scheduler has not been started, which can help cluster
|
||||
bootstrap.
|
||||
@@ -88,7 +88,7 @@ Some possible patterns for communicating with pods in a DaemonSet are:
|
||||
as a stats database. They do not have clients.
|
||||
- **NodeIP and Known Port**: Pods in the Daemon Set use a `hostPort`, so that the pods are reachable
|
||||
via the node IPs. Clients knows the the list of nodes ips somehow, and know the port by convention.
|
||||
- **DNS**: Create a [headless service](/{{page.version}}/docs/user-guide/services/#headless-services) with the same pod selector,
|
||||
- **DNS**: Create a [headless service](/docs/user-guide/services/#headless-services) with the same pod selector,
|
||||
and then discover DaemonSets using the `endpoints` resource or retrieve multiple A records from
|
||||
DNS.
|
||||
- **Service**: Create a service with the same pod selector, and use the service to reach a
|
||||
@@ -140,14 +140,14 @@ use a Daemon Set rather than creating individual pods.
|
||||
### Static Pods
|
||||
|
||||
It is possible to create pods by writing a file to a certain directory watched by Kubelet. These
|
||||
are called [static pods](/{{page.version}}/docs/admin/static-pods).
|
||||
are called [static pods](/docs/admin/static-pods).
|
||||
Unlike DaemonSet, static pods cannot be managed with kubectl
|
||||
or other Kubernetes API clients. Static pods do not depend on the apiserver, making them useful
|
||||
in cluster bootstrapping cases. Also, static pods may be deprecated in the future.
|
||||
|
||||
### Replication Controller
|
||||
|
||||
Daemon Set are similar to [Replication Controllers](/{{page.version}}/docs/user-guide/replication-controller) in that
|
||||
Daemon Set are similar to [Replication Controllers](/docs/user-guide/replication-controller) in that
|
||||
they both create pods, and those pods have processes which are not expected to terminate (e.g. web servers,
|
||||
storage servers).
|
||||
|
||||
@@ -158,12 +158,12 @@ all or certain hosts, and when it needs to start before other pods.
|
||||
|
||||
## Caveats
|
||||
|
||||
DaemonSet objects are in the [`extensions` API Group](/{{page.version}}/docs/api/#api-groups).
|
||||
DaemonSet objects are in the [`extensions` API Group](/docs/api/#api-groups).
|
||||
DaemonSet is not enabled by default. Enable it by setting
|
||||
`--runtime-config=extensions/v1beta1/daemonsets=true` on the api server. This can be
|
||||
achieved by exporting ENABLE_DAEMONSETS=true before running kube-up.sh script
|
||||
on GCE.
|
||||
|
||||
DaemonSet objects effectively have [API version `v1alpha1`](/{{page.version}}/docs/api/)#api-versioning).
|
||||
DaemonSet objects effectively have [API version `v1alpha1`](/docs/api/)#api-versioning).
|
||||
Alpha objects may change or even be discontinued in future software releases.
|
||||
However, due to to a known issue, they will appear as API version `v1beta1` if enabled.
|
||||
@@ -13,7 +13,7 @@ internet at large), because access to etcd is equivalent to root in your
|
||||
cluster.
|
||||
|
||||
Data Reliability: for reasonable safety, either etcd needs to be run as a
|
||||
[cluster](/{{page.version}}/docs/admin/high-availability/#clustering-etcd) (multiple machines each running
|
||||
[cluster](/docs/admin/high-availability/#clustering-etcd) (multiple machines each running
|
||||
etcd) or etcd's data directory should be located on durable storage (e.g., GCE's
|
||||
persistent disk). In either case, if high availability is required--as it might
|
||||
be in a production cluster--the data directory ought to be [backed up
|
||||
@@ -30,7 +30,7 @@ be run on master VMs. The default location that kubelet scans for manifests is
|
||||
## Kubernetes's usage of etcd
|
||||
|
||||
By default, Kubernetes objects are stored under the `/registry` key in etcd.
|
||||
This path can be prefixed by using the [kube-apiserver](/{{page.version}}/docs/admin/kube-apiserver) flag
|
||||
This path can be prefixed by using the [kube-apiserver](/docs/admin/kube-apiserver) flag
|
||||
`--etcd-prefix="/foo"`.
|
||||
|
||||
`etcd` is the only place that Kubernetes keeps state.
|
||||
@@ -3,7 +3,7 @@
|
||||
|
||||
This document describes how to build a high-availability (HA) Kubernetes cluster. This is a fairly advanced topic.
|
||||
Users who merely want to experiment with Kubernetes are encouraged to use configurations that are simpler to set up such as
|
||||
the simple [Docker based single node cluster instructions](/{{page.version}}/docs/getting-started-guides/docker),
|
||||
the simple [Docker based single node cluster instructions](/docs/getting-started-guides/docker),
|
||||
or try [Google Container Engine](https://cloud.google.com/container-engine/) for hosted Kubernetes.
|
||||
|
||||
Also, at this time high availability support for Kubernetes is not continuously tested in our end-to-end (e2e) testing. We will
|
||||
@@ -53,11 +53,11 @@ choices. For example, on systemd-based systems (e.g. RHEL, CentOS), you can run
|
||||
If you are extending from a standard Kubernetes installation, the `kubelet` binary should already be present on your system. You can run
|
||||
`which kubelet` to determine if the binary is in fact installed. If it is not installed,
|
||||
you should install the [kubelet binary](https://storage.googleapis.com/kubernetes-release/release/v0.19.3/bin/linux/amd64/kubelet), the
|
||||
[kubelet init file](http://releases.k8s.io/{{page.githubbranch}}/cluster/saltbase/salt/kubelet/initd) and [high-availability/default-kubelet](/{{page.version}}/docs/admin/high-availability/default-kubelet)
|
||||
[kubelet init file](http://releases.k8s.io/{{page.githubbranch}}/cluster/saltbase/salt/kubelet/initd) and [high-availability/default-kubelet](/docs/admin/high-availability/default-kubelet)
|
||||
scripts.
|
||||
|
||||
If you are using monit, you should also install the monit daemon (`apt-get install monit`) and the [high-availability/monit-kubelet](/{{page.version}}/docs/admin/high-availability/monit-kubelet) and
|
||||
[high-availability/monit-docker](/{{page.version}}/docs/admin/high-availability/monit-docker) configs.
|
||||
If you are using monit, you should also install the monit daemon (`apt-get install monit`) and the [high-availability/monit-kubelet](/docs/admin/high-availability/monit-kubelet) and
|
||||
[high-availability/monit-docker](/docs/admin/high-availability/monit-docker) configs.
|
||||
|
||||
On systemd systems you `systemctl enable kubelet` and `systemctl enable docker`.
|
||||
|
||||
@@ -86,7 +86,7 @@ First, hit the etcd discovery service to create a new token:
|
||||
curl https://discovery.etcd.io/new?size=3
|
||||
```
|
||||
|
||||
On each node, copy the [etcd.yaml](/{{page.version}}/docs/admin/high-availability/etcd.yaml) file into `/etc/kubernetes/manifests/etcd.yaml`
|
||||
On each node, copy the [etcd.yaml](/docs/admin/high-availability/etcd.yaml) file into `/etc/kubernetes/manifests/etcd.yaml`
|
||||
|
||||
The kubelet on each node actively monitors the contents of that directory, and it will create an instance of the `etcd`
|
||||
server from the definition of the pod specified in `etcd.yaml`.
|
||||
@@ -156,7 +156,7 @@ The easiest way to create this directory, may be to copy it from the master node
|
||||
|
||||
### Starting the API Server
|
||||
|
||||
Once these files exist, copy the [kube-apiserver.yaml](/{{page.version}}/docs/admin/high-availability/kube-apiserver.yaml) into `/etc/kubernetes/manifests/` on each master node.
|
||||
Once these files exist, copy the [kube-apiserver.yaml](/docs/admin/high-availability/kube-apiserver.yaml) into `/etc/kubernetes/manifests/` on each master node.
|
||||
|
||||
The kubelet monitors this directory, and will automatically create an instance of the `kube-apiserver` container using the pod definition specified
|
||||
in the file.
|
||||
@@ -197,11 +197,11 @@ touch /var/log/kube-controller-manager.log
|
||||
```
|
||||
|
||||
Next, set up the descriptions of the scheduler and controller manager pods on each node.
|
||||
by copying [kube-scheduler.yaml](/{{page.version}}/docs/admin/high-availability/kube-scheduler.yaml) and [kube-controller-manager.yaml](high-availability//{{page.version}}/docs/admin/kube-controller-manager.yaml) into the `/srv/kubernetes/` directory.
|
||||
by copying [kube-scheduler.yaml](/docs/admin/high-availability/kube-scheduler.yaml) and [kube-controller-manager.yaml](high-availability//{{page.version}}/docs/admin/kube-controller-manager.yaml) into the `/srv/kubernetes/` directory.
|
||||
|
||||
### Running the podmaster
|
||||
|
||||
Now that the configuration files are in place, copy the [podmaster.yaml](/{{page.version}}/docs/admin/high-availability/podmaster.yaml) config file into `/etc/kubernetes/manifests/`
|
||||
Now that the configuration files are in place, copy the [podmaster.yaml](/docs/admin/high-availability/podmaster.yaml) config file into `/etc/kubernetes/manifests/`
|
||||
|
||||
As before, the kubelet on the node monitors this directory, and will start an instance of the podmaster using the pod specification provided in `podmaster.yaml`.
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
---
|
||||
|
||||
The cluster admin guide is for anyone creating or administering a Kubernetes cluster.
|
||||
It assumes some familiarity with concepts in the [User Guide](/{{page.version}}/docs/user-guide/).
|
||||
It assumes some familiarity with concepts in the [User Guide](/docs/user-guide/).
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
@@ -10,7 +10,7 @@ It assumes some familiarity with concepts in the [User Guide](/{{page.version}}/
|
||||
## Planning a cluster
|
||||
|
||||
There are many different examples of how to setup a kubernetes cluster. Many of them are listed in this
|
||||
[matrix](/{{page.version}}/docs/getting-started-guides/). We call each of the combinations in this matrix a *distro*.
|
||||
[matrix](/docs/getting-started-guides/). We call each of the combinations in this matrix a *distro*.
|
||||
|
||||
Before choosing a particular guide, here are some things to consider:
|
||||
|
||||
@@ -27,52 +27,52 @@ Before choosing a particular guide, here are some things to consider:
|
||||
- Not all distros are maintained as actively. Prefer ones which are listed as tested on a more recent version of
|
||||
Kubernetes.
|
||||
- If you are configuring kubernetes on-premises, you will need to consider what [networking
|
||||
model](/{{page.version}}/docs/admin/networking) fits best.
|
||||
- If you are designing for very high-availability, you may want [clusters in multiple zones](/{{page.version}}/docs/admin/multi-cluster).
|
||||
model](/docs/admin/networking) fits best.
|
||||
- If you are designing for very high-availability, you may want [clusters in multiple zones](/docs/admin/multi-cluster).
|
||||
- You may want to familiarize yourself with the various
|
||||
[components](/{{page.version}}/docs/admin/cluster-components) needed to run a cluster.
|
||||
[components](/docs/admin/cluster-components) needed to run a cluster.
|
||||
|
||||
## Setting up a cluster
|
||||
|
||||
Pick one of the Getting Started Guides from the [matrix](/{{page.version}}/docs/getting-started-guides/) and follow it.
|
||||
Pick one of the Getting Started Guides from the [matrix](/docs/getting-started-guides/) and follow it.
|
||||
If none of the Getting Started Guides fits, you may want to pull ideas from several of the guides.
|
||||
|
||||
One option for custom networking is *OpenVSwitch GRE/VxLAN networking* ([ovs-networking.md](/{{page.version}}/docs/admin/ovs-networking)), which
|
||||
One option for custom networking is *OpenVSwitch GRE/VxLAN networking* ([ovs-networking.md](/docs/admin/ovs-networking)), which
|
||||
uses OpenVSwitch to set up networking between pods across
|
||||
Kubernetes nodes.
|
||||
|
||||
If you are modifying an existing guide which uses Salt, this document explains [how Salt is used in the Kubernetes
|
||||
project](/{{page.version}}/docs/admin/salt).
|
||||
project](/docs/admin/salt).
|
||||
|
||||
## Managing a cluster, including upgrades
|
||||
|
||||
[Managing a cluster](/{{page.version}}/docs/admin/cluster-management).
|
||||
[Managing a cluster](/docs/admin/cluster-management).
|
||||
|
||||
## Managing nodes
|
||||
|
||||
[Managing nodes](/{{page.version}}/docs/admin/node).
|
||||
[Managing nodes](/docs/admin/node).
|
||||
|
||||
## Optional Cluster Services
|
||||
|
||||
* **DNS Integration with SkyDNS** ([dns.md](/{{page.version}}/docs/admin/dns)):
|
||||
* **DNS Integration with SkyDNS** ([dns.md](/docs/admin/dns)):
|
||||
Resolving a DNS name directly to a Kubernetes service.
|
||||
|
||||
* **Logging** with [Kibana](/{{page.version}}/docs/user-guide/logging)
|
||||
* **Logging** with [Kibana](/docs/user-guide/logging)
|
||||
|
||||
## Multi-tenant support
|
||||
|
||||
* **Resource Quota** ([resource-quota.md](/{{page.version}}/docs/admin/resource-quota))
|
||||
* **Resource Quota** ([resource-quota.md](/docs/admin/resource-quota))
|
||||
|
||||
## Security
|
||||
|
||||
* **Kubernetes Container Environment** ([docs/user-guide/container-environment.md](/{{page.version}}/docs/user-guide/container-environment)):
|
||||
* **Kubernetes Container Environment** ([docs/user-guide/container-environment.md](/docs/user-guide/container-environment)):
|
||||
Describes the environment for Kubelet managed containers on a Kubernetes
|
||||
node.
|
||||
|
||||
* **Securing access to the API Server** [accessing the api](/{{page.version}}/docs/admin/accessing-the-api)
|
||||
* **Securing access to the API Server** [accessing the api](/docs/admin/accessing-the-api)
|
||||
|
||||
* **Authentication** [authentication](/{{page.version}}/docs/admin/authentication)
|
||||
* **Authentication** [authentication](/docs/admin/authentication)
|
||||
|
||||
* **Authorization** [authorization](/{{page.version}}/docs/admin/authorization)
|
||||
* **Authorization** [authorization](/docs/admin/authorization)
|
||||
|
||||
* **Admission Controllers** [admission_controllers](/{{page.version}}/docs/admin/admission-controllers)
|
||||
* **Admission Controllers** [admission_controllers](/docs/admin/admission-controllers)
|
||||
@@ -26,11 +26,11 @@ This example demonstrates how limits can be applied to a Kubernetes namespace to
|
||||
min/max resource limits per pod. In addition, this example demonstrates how you can
|
||||
apply default resource limits to pods in the absence of an end-user specified value.
|
||||
|
||||
See [LimitRange design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/admission_control_limit_range.md) for more information. For a detailed description of the Kubernetes resource model, see [Resources](/{{page.version}}/docs/user-guide/compute-resources)
|
||||
See [LimitRange design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/admission_control_limit_range.md) for more information. For a detailed description of the Kubernetes resource model, see [Resources](/docs/user-guide/compute-resources)
|
||||
|
||||
## Step 0: Prerequisites
|
||||
|
||||
This example requires a running Kubernetes cluster. See the [Getting Started guides](/{{page.version}}/docs/getting-started-guides/) for how to get started.
|
||||
This example requires a running Kubernetes cluster. See the [Getting Started guides](/docs/getting-started-guides/) for how to get started.
|
||||
|
||||
Change to the `<kubernetes>` directory if you're not already there.
|
||||
|
||||
@@ -37,7 +37,7 @@ The Namespace provides a unique scope for:
|
||||
|
||||
## Usage
|
||||
|
||||
Look [here](/{{page.version}}/docs/admin/namespaces/) for an in depth example of namespaces.
|
||||
Look [here](/docs/admin/namespaces/) for an in depth example of namespaces.
|
||||
|
||||
### Viewing namespaces
|
||||
|
||||
@@ -115,8 +115,8 @@ $ kubectl create -f ./my-namespace.yaml
|
||||
|
||||
### Working in namespaces
|
||||
|
||||
See [Setting the namespace for a request](/{{page.version}}/docs/user-guide/namespaces/#setting-the-namespace-for-a-request)
|
||||
and [Setting the namespace preference](/{{page.version}}/docs/user-guide/namespaces/#setting-the-namespace-preference).
|
||||
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
|
||||
|
||||
@@ -132,7 +132,7 @@ This delete is asynchronous, so for a time you will see the namespace in the `Te
|
||||
|
||||
## Namespaces and DNS
|
||||
|
||||
When you create a [Service](/{{page.version}}/docs/user-guide/services), it creates a corresponding [DNS entry](/{{page.version}}/docs/admin/dns).
|
||||
When you create a [Service](/docs/user-guide/services), it creates a corresponding [DNS entry](/docs/admin/dns).
|
||||
This entry is of the form `<service-name>.<namespace-name>.svc.cluster.local`, which means
|
||||
that if a container just uses `<service-name>` it will resolve to the service which
|
||||
is local to a namespace. This is useful for using the same configuration across
|
||||
@@ -5,7 +5,7 @@ Kubernetes _namespaces_ help different projects, teams, or customers to share a
|
||||
|
||||
It does this by providing the following:
|
||||
|
||||
1. A scope for [Names](/{{page.version}}/docs/user-guide/identifiers).
|
||||
1. A scope for [Names](/docs/user-guide/identifiers).
|
||||
2. A mechanism to attach authorization and policy to a subsection of the cluster.
|
||||
|
||||
Use of multiple namespaces is optional.
|
||||
@@ -16,8 +16,8 @@ This example demonstrates how to use Kubernetes namespaces to subdivide your clu
|
||||
|
||||
This example assumes the following:
|
||||
|
||||
1. You have an [existing Kubernetes cluster](/{{page.version}}/docs/getting-started-guides/).
|
||||
2. You have a basic understanding of Kubernetes _[pods](/{{page.version}}/docs/user-guide/pods)_, _[services](/{{page.version}}/docs/user-guide/services)_, and _[replication controllers](/{{page.version}}/docs/user-guide/replication-controller)_.
|
||||
1. You have an [existing Kubernetes cluster](/docs/getting-started-guides/).
|
||||
2. You have a basic understanding of Kubernetes _[pods](/docs/user-guide/pods)_, _[services](/docs/user-guide/services)_, and _[replication controllers](/docs/user-guide/replication-controller)_.
|
||||
|
||||
### Step One: Understand the default namespace
|
||||
|
||||
@@ -49,7 +49,7 @@ One pattern this organization could follow is to partition the Kubernetes cluste
|
||||
|
||||
Let's create two new namespaces to hold our work.
|
||||
|
||||
Use the file [`namespace-dev.json`](/{{page.version}}/docs/admin/namespacesnamespace-dev.json) which describes a development namespace:
|
||||
Use the file [`namespace-dev.json`](/docs/admin/namespacesnamespace-dev.json) which describes a development namespace:
|
||||
|
||||
<!-- BEGIN MUNGE: EXAMPLE namespace-dev.json -->
|
||||
|
||||
@@ -66,7 +66,7 @@ Use the file [`namespace-dev.json`](/{{page.version}}/docs/admin/namespacesnames
|
||||
}
|
||||
```
|
||||
|
||||
[Download example](/{{page.version}}/docs/admin/namespacesnamespace-dev.json)
|
||||
[Download example](/docs/admin/namespacesnamespace-dev.json)
|
||||
<!-- END MUNGE: EXAMPLE namespace-dev.json -->
|
||||
|
||||
Create the development namespace using kubectl.
|
||||
@@ -5,10 +5,10 @@ Kubernetes approaches networking somewhat differently than Docker does by
|
||||
default. There are 4 distinct networking problems to solve:
|
||||
|
||||
1. Highly-coupled container-to-container communications: this is solved by
|
||||
[pods](/{{page.version}}/docs/user-guide/pods) and `localhost` communications.
|
||||
[pods](/docs/user-guide/pods) and `localhost` communications.
|
||||
2. Pod-to-Pod communications: this is the primary focus of this document.
|
||||
3. Pod-to-Service communications: this is covered by [services](/{{page.version}}/docs/user-guide/services).
|
||||
4. External-to-Service communications: this is covered by [services](/{{page.version}}/docs/user-guide/services).
|
||||
3. Pod-to-Service communications: this is covered by [services](/docs/user-guide/services).
|
||||
4. External-to-Service communications: this is covered by [services](/docs/user-guide/services).
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
@@ -163,7 +163,7 @@ people have reported success with Flannel and Kubernetes.
|
||||
|
||||
### OpenVSwitch
|
||||
|
||||
[OpenVSwitch](/{{page.version}}/docs/admin/ovs-networking) is a somewhat more mature but also
|
||||
[OpenVSwitch](/docs/admin/ovs-networking) is a somewhat more mature but also
|
||||
complicated way to build an overlay network. This is endorsed by several of the
|
||||
"Big Shops" for networking.
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
|
||||
`Node` is a worker machine in Kubernetes, previously known as `Minion`. Node
|
||||
may be a VM or physical machine, depending on the cluster. Each node has
|
||||
the services necessary to run [Pods](/{{page.version}}/docs/user-guide/pods) and is managed by the master
|
||||
the services necessary to run [Pods](/docs/user-guide/pods) and is managed by the master
|
||||
components. The services on a node include docker, kubelet and network proxy. See
|
||||
[The Kubernetes Node](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/architecture.md#the-kubernetes-node) section in the
|
||||
architecture design doc for more details.
|
||||
@@ -82,7 +82,7 @@ The information is gathered by Kubelet from the node.
|
||||
|
||||
## Node Management
|
||||
|
||||
Unlike [Pods](/{{page.version}}/docs/user-guide/pods) and [Services](/{{page.version}}/docs/user-guide/services), a Node is not inherently
|
||||
Unlike [Pods](/docs/user-guide/pods) and [Services](/docs/user-guide/services), a Node is not inherently
|
||||
created by Kubernetes: it is either taken from cloud providers like Google Compute Engine,
|
||||
or from your pool of physical or virtual machines. What this means is that when
|
||||
Kubernetes creates a node, it is really just creating an object that represents the node in its internal state.
|
||||
@@ -18,7 +18,7 @@ work like this:
|
||||
their resource requests defaulted to match their defined limits. The user is only charged for the
|
||||
resources they request in the Resource Quota versus their limits because the request is the minimum
|
||||
amount of resource guaranteed by the cluster during scheduling. For more information on over commit,
|
||||
see [compute-resources](/{{page.version}}/docs/user-guide/compute-resources).
|
||||
see [compute-resources](/docs/user-guide/compute-resources).
|
||||
- If creating a pod would cause the namespace to exceed any of the limits specified in the
|
||||
the Resource Quota for that namespace, then the request will fail with HTTP status
|
||||
code `403 FORBIDDEN`.
|
||||
@@ -26,7 +26,7 @@ work like this:
|
||||
of the resources for which quota is enabled, then the POST of the pod will fail with HTTP
|
||||
status code `403 FORBIDDEN`. Hint: Use the LimitRange admission controller to force default
|
||||
values of *limits* (then resource *requests* would be equal to *limits* by default, see
|
||||
[admission controller](/{{page.version}}/docs/admin/admission-controllers)) before the quota is checked to avoid this problem.
|
||||
[admission controller](/docs/admin/admission-controllers)) before the quota is checked to avoid this problem.
|
||||
|
||||
Examples of policies that could be created using namespaces and quotas are:
|
||||
|
||||
@@ -52,7 +52,7 @@ Resource Quota is enforced in a particular namespace when there is a
|
||||
|
||||
## Compute Resource Quota
|
||||
|
||||
The total sum of [compute resources](/{{page.version}}/docs/user-guide/compute-resources) requested by pods
|
||||
The total sum of [compute resources](/docs/user-guide/compute-resources) requested by pods
|
||||
in a namespace can be limited. The following compute resource types are supported:
|
||||
|
||||
| ResourceName | Description |
|
||||
@@ -73,9 +73,9 @@ are supported:
|
||||
| pods | Total number of pods |
|
||||
| services | Total number of services |
|
||||
| replicationcontrollers | Total number of replication controllers |
|
||||
| resourcequotas | Total number of [resource quotas](/{{page.version}}/docs/admin/admission-controllers/#resourcequota) |
|
||||
| resourcequotas | Total number of [resource quotas](/docs/admin/admission-controllers/#resourcequota) |
|
||||
| secrets | Total number of secrets |
|
||||
| persistentvolumeclaims | Total number of [persistent volume claims](/{{page.version}}/docs/user-guide/persistent-volumes/#persistentvolumeclaims) |
|
||||
| persistentvolumeclaims | Total number of [persistent volume claims](/docs/user-guide/persistent-volumes/#persistentvolumeclaims) |
|
||||
|
||||
For example, `pods` quota counts and enforces a maximum on the number of `pods`
|
||||
created in a single namespace.
|
||||
@@ -147,7 +147,7 @@ restrictions around nodes: pods from several namespaces may run on the same node
|
||||
|
||||
## Example
|
||||
|
||||
See a [detailed example for how to use resource quota](/{{page.version}}/docs/admin/resourcequota/).
|
||||
See a [detailed example for how to use resource quota](/docs/admin/resourcequota/).
|
||||
|
||||
## Read More
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
---
|
||||
---
|
||||
|
||||
This example demonstrates how [resource quota](/{{page.version}}/docs/admin/admission-controllers/#resourcequota) and
|
||||
[limitsranger](/{{page.version}}/docs/admin/admission-controllers/#limitranger) can be applied to a Kubernetes namespace.
|
||||
This example demonstrates how [resource quota](/docs/admin/admission-controllers/#resourcequota) and
|
||||
[limitsranger](/docs/admin/admission-controllers/#limitranger) can be applied to a Kubernetes namespace.
|
||||
See [ResourceQuota design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/admission_control_resource_quota.md) for more information.
|
||||
|
||||
This example assumes you have a functional Kubernetes setup.
|
||||
@@ -2,7 +2,7 @@
|
||||
---
|
||||
|
||||
*This is a Cluster Administrator guide to service accounts. It assumes knowledge of
|
||||
the [User Guide to Service Accounts](/{{page.version}}/docs/user-guide/service-accounts).*
|
||||
the [User Guide to Service Accounts](/docs/user-guide/service-accounts).*
|
||||
|
||||
*Support for authorization and user accounts is planned but incomplete. Sometimes
|
||||
incomplete features are referred to in order to better describe service accounts.*
|
||||
@@ -38,7 +38,7 @@ Three separate components cooperate to implement the automation around service a
|
||||
### Service Account Admission Controller
|
||||
|
||||
The modification of pods is implemented via a plugin
|
||||
called an [Admission Controller](/{{page.version}}/docs/admin/admission-controllers). It is part of the apiserver.
|
||||
called an [Admission Controller](/docs/admin/admission-controllers). It is part of the apiserver.
|
||||
It acts synchronously to modify pods as they are created or updated. When this plugin is active
|
||||
(and it is by default on most distributions), then it does the following when a pod is created or modified:
|
||||
|
||||
@@ -85,7 +85,7 @@ static-web-my-minion1 172.17.0.3 my-minion1/192.1
|
||||
|
||||
Labels from the static pod are propagated into the mirror-pod and can be used as usual for filtering.
|
||||
|
||||
Notice we cannot delete the pod with the API server (e.g. via [`kubectl`](/{{page.version}}/docs/user-guide/kubectl/kubectl) command), kubelet simply won't remove it.
|
||||
Notice we cannot delete the pod with the API server (e.g. via [`kubectl`](/docs/user-guide/kubectl/kubectl) command), kubelet simply won't remove it.
|
||||
|
||||
```shell
|
||||
[joe@my-master ~] $ kubectl delete pod static-web-my-minion1
|
||||
@@ -1,15 +1,15 @@
|
||||
---
|
||||
---
|
||||
|
||||
Primary system and API concepts are documented in the [User guide](/{{page.version}}/docs/user-guide/).
|
||||
Primary system and API concepts are documented in the [User guide](/docs/user-guide/).
|
||||
|
||||
Overall API conventions are described in the [API conventions doc](/{{page.version}}/docs/devel/api-conventions).
|
||||
Overall API conventions are described in the [API conventions doc](/docs/devel/api-conventions).
|
||||
|
||||
Complete API details are documented via [Swagger](http://swagger.io/). The Kubernetes apiserver (aka "master") exports an API that can be used to retrieve the [Swagger spec](https://github.com/swagger-api/swagger-spec/tree/master/schemas/v1.2) for the Kubernetes API, by default at `/swaggerapi`, and a UI you can use to browse the API documentation at `/swagger-ui`. We also periodically update a [statically generated UI](http://kubernetes.io/third_party/swagger-ui/).
|
||||
|
||||
Remote access to the API is discussed in the [access doc](/{{page.version}}/docs/admin/accessing-the-api).
|
||||
Remote access to the API is discussed in the [access doc](/docs/admin/accessing-the-api).
|
||||
|
||||
The Kubernetes API also serves as the foundation for the declarative configuration schema for the system. The [Kubectl](/{{page.version}}/docs/user-guide/kubectl/kubectl) command-line tool can be used to create, update, delete, and get API objects.
|
||||
The Kubernetes API also serves as the foundation for the declarative configuration schema for the system. The [Kubectl](/docs/user-guide/kubectl/kubectl) command-line tool can be used to create, update, delete, and get API objects.
|
||||
|
||||
Kubernetes also stores its serialized state (currently in [etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)) in terms of the API resources.
|
||||
|
||||
@@ -19,7 +19,7 @@ Kubernetes itself is decomposed into multiple components, which interact through
|
||||
|
||||
In our experience, any system that is successful needs to grow and change as new use cases emerge or existing ones change. Therefore, we expect the Kubernetes API to continuously change and grow. However, we intend to not break compatibility with existing clients, for an extended period of time. In general, new API resources and new resource fields can be expected to be added frequently. Elimination of resources or fields will require following a deprecation process. The precise deprecation policy for eliminating features is TBD, but once we reach our 1.0 milestone, there will be a specific policy.
|
||||
|
||||
What constitutes a compatible change and how to change the API are detailed by the [API change document](/{{page.version}}/docs/devel/api_changes).
|
||||
What constitutes a compatible change and how to change the API are detailed by the [API change document](/docs/devel/api_changes).
|
||||
|
||||
## API versioning
|
||||
|
||||
@@ -35,7 +35,7 @@ software versioning.
|
||||
|
||||
|
||||
Different API versions imply different levels of stability and support. The criteria for each level are described
|
||||
in more detail in the [API Changes documentation](/{{page.version}}/docs/devel/api_changes/#alpha-beta-and-stable-versions). They are summarized here:
|
||||
in more detail in the [API Changes documentation](/docs/devel/api_changes/#alpha-beta-and-stable-versions). They are summarized here:
|
||||
|
||||
- Alpha level:
|
||||
- The version names contain `alpha` (e.g. `v1alpha1`).
|
||||
@@ -88,17 +88,17 @@ As of June 4, 2015, the Kubernetes v1 API has been enabled by default. The v1bet
|
||||
|
||||
### v1 conversion tips (from v1beta3)
|
||||
|
||||
We're working to convert all documentation and examples to v1. A simple [API conversion tool](/{{page.version}}/docs/admin/cluster-management/#switching-your-config-files-to-a-new-api-version) has been written to simplify the translation process. Use `kubectl create --validate` in order to validate your json or yaml against our Swagger spec.
|
||||
We're working to convert all documentation and examples to v1. A simple [API conversion tool](/docs/admin/cluster-management/#switching-your-config-files-to-a-new-api-version) has been written to simplify the translation process. Use `kubectl create --validate` in order to validate your json or yaml against our Swagger spec.
|
||||
|
||||
Changes to services are the most significant difference between v1beta3 and v1.
|
||||
|
||||
* The `service.spec.portalIP` property is renamed to `service.spec.clusterIP`.
|
||||
* The `service.spec.createExternalLoadBalancer` property is removed. Specify `service.spec.type: "LoadBalancer"` to create an external load balancer instead.
|
||||
* The `service.spec.publicIPs` property is deprecated and now called `service.spec.deprecatedPublicIPs`. This property will be removed entirely when v1beta3 is removed. The vast majority of users of this field were using it to expose services on ports on the node. Those users should specify `service.spec.type: "NodePort"` instead. Read [External Services](/{{page.version}}/docs/user-guide/services/#external-services) for more info. If this is not sufficient for your use case, please file an issue or contact @thockin.
|
||||
* The `service.spec.publicIPs` property is deprecated and now called `service.spec.deprecatedPublicIPs`. This property will be removed entirely when v1beta3 is removed. The vast majority of users of this field were using it to expose services on ports on the node. Those users should specify `service.spec.type: "NodePort"` instead. Read [External Services](/docs/user-guide/services/#external-services) for more info. If this is not sufficient for your use case, please file an issue or contact @thockin.
|
||||
|
||||
Some other difference between v1beta3 and v1:
|
||||
|
||||
* The `pod.spec.containers[*].privileged` and `pod.spec.containers[*].capabilities` properties are now nested under the `pod.spec.containers[*].securityContext` property. See [Security Contexts](/{{page.version}}/docs/user-guide/security-context).
|
||||
* The `pod.spec.containers[*].privileged` and `pod.spec.containers[*].capabilities` properties are now nested under the `pod.spec.containers[*].securityContext` property. See [Security Contexts](/docs/user-guide/security-context).
|
||||
* The `pod.spec.host` property is renamed to `pod.spec.nodeName`.
|
||||
* The `endpoints.subsets[*].addresses.IP` property is renamed to `endpoints.subsets[*].addresses.ip`.
|
||||
* The `pod.status.containerStatuses[*].state.termination` and `pod.status.containerStatuses[*].lastState.termination` properties are renamed to `pod.status.containerStatuses[*].state.terminated` and `pod.status.containerStatuses[*].lastState.terminated` respectively.
|
||||
@@ -119,11 +119,8 @@ Some important differences between v1beta1/2 and v1beta3:
|
||||
* The `labels` query parameter has been renamed to `labelSelector`.
|
||||
* The `fields` query parameter has been renamed to `fieldSelector`.
|
||||
* The container `entrypoint` has been renamed to `command`, and `command` has been renamed to `args`.
|
||||
* Container, volume, and node resources are expressed as nested maps (e.g., `resources{cpu:1}`) rather than as individual fields, and resource values support [scaling suffixes](/{{page.version}}/docs/user-guide/compute-resources/#specifying-resource-quantities) rather than fixed scales (e.g., milli-cores).
|
||||
* Container, volume, and node resources are expressed as nested maps (e.g., `resources{cpu:1}`) rather than as individual fields, and resource values support [scaling suffixes](/docs/user-guide/compute-resources/#specifying-resource-quantities) rather than fixed scales (e.g., milli-cores).
|
||||
* Restart policy is represented simply as a string (e.g., `"Always"`) rather than as a nested map (`always{}`).
|
||||
* Pull policies changed from `PullAlways`, `PullNever`, and `PullIfNotPresent` to `Always`, `Never`, and `IfNotPresent`.
|
||||
* The volume `source` is inlined into `volume` rather than nested.
|
||||
* Host volumes have been changed from `hostDir` to `hostPath` to better reflect that they can be files or directories.
|
||||
|
||||
|
||||
|
||||
* Host volumes have been changed from `hostDir` to `hostPath` to better reflect that they can be files or directories.
|
||||
@@ -5,12 +5,12 @@ Updated: 9/20/2015
|
||||
|
||||
*This document is oriented at users who want a deeper understanding of the Kubernetes
|
||||
API structure, and developers wanting to extend the Kubernetes API. An introduction to
|
||||
using resources with kubectl can be found in [Working with resources](/{{page.version}}/docs/user-guide/working-with-resources).*
|
||||
using resources with kubectl can be found in [Working with resources](/docs/user-guide/working-with-resources).*
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
The conventions of the [Kubernetes API](/{{page.version}}/docs/api/) (and related APIs in the ecosystem) are intended to ease client development and ensure that configuration mechanisms can be implemented that work across a diverse set of use cases consistently.
|
||||
The conventions of the [Kubernetes API](/docs/api/) (and related APIs in the ecosystem) are intended to ease client development and ensure that configuration mechanisms can be implemented that work across a diverse set of use cases consistently.
|
||||
|
||||
The general style of the Kubernetes API is RESTful - clients create, update, delete, or retrieve a description of an object via the standard HTTP verbs (POST, PUT, DELETE, and GET) - and those APIs preferentially accept and return JSON. Kubernetes also exposes additional endpoints for non-standard verbs and allows alternative content types. All of the JSON accepted and returned by the server has a schema, identified by the "kind" and "apiVersion" fields. Where relevant HTTP header fields exist, they should mirror the content of JSON fields, but the information should not be represented only in the HTTP header.
|
||||
|
||||
@@ -44,7 +44,7 @@ Kinds are grouped into three categories:
|
||||
|
||||
Most objects defined in the system should have an endpoint that returns the full set of resources, as well as zero or more endpoints that return subsets of the full list. Some objects may be singletons (the current user, the system defaults) and may not have lists.
|
||||
|
||||
In addition, all lists that return objects with labels should support label filtering (see [docs/user-guide/labels.md](/{{page.version}}/docs/user-guide/labels), and most lists should support filtering by fields.
|
||||
In addition, all lists that return objects with labels should support label filtering (see [docs/user-guide/labels.md](/docs/user-guide/labels), and most lists should support filtering by fields.
|
||||
|
||||
Examples: PodLists, ServiceLists, NodeLists
|
||||
|
||||
@@ -62,7 +62,7 @@ Kinds are grouped into three categories:
|
||||
* `/status`: Used to write just the status portion of a resource. For example, the `/pods` endpoint only allows updates to `metadata` and `spec`, since those reflect end-user intent. An automated process should be able to modify status for users to see by sending an updated Pod kind to the server to the "/pods/<name>/status" endpoint - the alternate endpoint allows different rules to be applied to the update, and access to be appropriately restricted.
|
||||
* `/scale`: Used to read and write the count of a resource in a manner that is independent of the specific resource schema.
|
||||
|
||||
Two additional subresources, `proxy` and `portforward`, provide access to cluster resources as described in [docs/user-guide/accessing-the-cluster.md](/{{page.version}}/docs/user-guide/accessing-the-cluster).
|
||||
Two additional subresources, `proxy` and `portforward`, provide access to cluster resources as described in [docs/user-guide/accessing-the-cluster.md](/docs/user-guide/accessing-the-cluster).
|
||||
|
||||
The standard REST verbs (defined below) MUST return singular JSON objects. Some API endpoints may deviate from the strict REST pattern and return resources that are not singular JSON objects, such as streams of JSON objects or unstructured text log data.
|
||||
|
||||
@@ -83,9 +83,9 @@ These fields are required for proper decoding of the object. They may be populat
|
||||
|
||||
Every object kind MUST have the following metadata in a nested object field called "metadata":
|
||||
|
||||
* namespace: a namespace is a DNS compatible subdomain that objects are subdivided into. The default namespace is 'default'. See [docs/user-guide/namespaces.md](/{{page.version}}/docs/user-guide/namespaces) for more.
|
||||
* name: a string that uniquely identifies this object within the current namespace (see [docs/user-guide/identifiers.md](/{{page.version}}/docs/user-guide/identifiers)). This value is used in the path when retrieving an individual object.
|
||||
* uid: a unique in time and space value (typically an RFC 4122 generated identifier, see [docs/user-guide/identifiers.md](/{{page.version}}/docs/user-guide/identifiers)) used to distinguish between objects with the same name that have been deleted and recreated
|
||||
* namespace: a namespace is a DNS compatible subdomain that objects are subdivided into. The default namespace is 'default'. See [docs/user-guide/namespaces.md](/docs/user-guide/namespaces) for more.
|
||||
* name: a string that uniquely identifies this object within the current namespace (see [docs/user-guide/identifiers.md](/docs/user-guide/identifiers)). This value is used in the path when retrieving an individual object.
|
||||
* uid: a unique in time and space value (typically an RFC 4122 generated identifier, see [docs/user-guide/identifiers.md](/docs/user-guide/identifiers)) used to distinguish between objects with the same name that have been deleted and recreated
|
||||
|
||||
Every object SHOULD have the following metadata in a nested object field called "metadata":
|
||||
|
||||
@@ -93,8 +93,8 @@ Every object SHOULD have the following metadata in a nested object field called
|
||||
* generation: a sequence number representing a specific generation of the desired state. Set by the system and monotonically increasing, per-resource. May be compared, such as for RAW and WAW consistency.
|
||||
* creationTimestamp: a string representing an RFC 3339 date of the date and time an object was created
|
||||
* deletionTimestamp: a string representing an RFC 3339 date of the date and time after which this resource will be deleted. This field is set by the server when a graceful deletion is requested by the user, and is not directly settable by a client. The resource will be deleted (no longer visible from resource lists, and not reachable by name) after the time in this field. Once set, this value may not be unset or be set further into the future, although it may be shortened or the resource may be deleted prior to this time.
|
||||
* labels: a map of string keys and values that can be used to organize and categorize objects (see [docs/user-guide/labels.md](/{{page.version}}/docs/user-guide/labels))
|
||||
* annotations: a map of string keys and values that can be used by external tooling to store and retrieve arbitrary metadata about this object (see [docs/user-guide/annotations.md](/{{page.version}}/docs/user-guide/annotations))
|
||||
* labels: a map of string keys and values that can be used to organize and categorize objects (see [docs/user-guide/labels.md](/docs/user-guide/labels))
|
||||
* annotations: a map of string keys and values that can be used by external tooling to store and retrieve arbitrary metadata about this object (see [docs/user-guide/annotations.md](/docs/user-guide/annotations))
|
||||
|
||||
Labels are intended for organizational purposes by end users (select the pods that match this label query). Annotations enable third-party automation and tooling to decorate objects with additional metadata for their own use.
|
||||
|
||||
@@ -139,7 +139,7 @@ In general, condition values may change back and forth, but some condition trans
|
||||
|
||||
A typical oscillating condition type is `Ready`, which indicates the object was believed to be fully operational at the time it was last probed. A possible monotonic condition could be `Succeeded`. A `False` status for `Succeeded` would imply failure. An object that was still active would not have a `Succeeded` condition, or its status would be `Unknown`.
|
||||
|
||||
Some resources in the v1 API contain fields called **`phase`**, and associated `message`, `reason`, and other status fields. The pattern of using `phase` is deprecated. Newer API types should use conditions instead. Phase was essentially a state-machine enumeration field, that contradicted [system-design principles](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/principles.md#control-logic) and hampered evolution, since [adding new enum values breaks backward compatibility](/{{page.version}}/docs/devel/api_changes). Rather than encouraging clients to infer implicit properties from phases, we intend to explicitly expose the conditions that clients need to monitor. Conditions also have the benefit that it is possible to create some conditions with uniform meaning across all resource types, while still exposing others that are unique to specific resource types. See [#7856](http://issues.k8s.io/7856) for more details and discussion.
|
||||
Some resources in the v1 API contain fields called **`phase`**, and associated `message`, `reason`, and other status fields. The pattern of using `phase` is deprecated. Newer API types should use conditions instead. Phase was essentially a state-machine enumeration field, that contradicted [system-design principles](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/principles.md#control-logic) and hampered evolution, since [adding new enum values breaks backward compatibility](/docs/devel/api_changes). Rather than encouraging clients to infer implicit properties from phases, we intend to explicitly expose the conditions that clients need to monitor. Conditions also have the benefit that it is possible to create some conditions with uniform meaning across all resource types, while still exposing others that are unique to specific resource types. See [#7856](http://issues.k8s.io/7856) for more details and discussion.
|
||||
|
||||
In condition types, and everywhere else they appear in the API, **`Reason`** is intended to be a one-word, CamelCase representation of the category of cause of the current status, and **`Message`** is intended to be a human-readable phrase or sentence, which may contain specific details of the individual occurrence. `Reason` is intended to be used in concise output, such as one-line `kubectl get` output, and in summarizing occurrences of causes, whereas `Message` is intended to be presented to users in detailed status explanations, such as `kubectl describe` output.
|
||||
|
||||
@@ -151,7 +151,7 @@ Some resources report the `observedGeneration`, which is the `generation` most r
|
||||
|
||||
#### References to related objects
|
||||
|
||||
References to loosely coupled sets of objects, such as [pods](/{{page.version}}/docs/user-guide/pods) overseen by a [replication controller](/{{page.version}}/docs/user-guide/replication-controller), are usually best referred to using a [label selector](/{{page.version}}/docs/user-guide/labels). In order to ensure that GETs of individual objects remain bounded in time and space, these sets may be queried via separate API queries, but will not be expanded in the referring object's status.
|
||||
References to loosely coupled sets of objects, such as [pods](/docs/user-guide/pods) overseen by a [replication controller](/docs/user-guide/replication-controller), are usually best referred to using a [label selector](/docs/user-guide/labels). In order to ensure that GETs of individual objects remain bounded in time and space, these sets may be queried via separate API queries, but will not be expanded in the referring object's status.
|
||||
|
||||
References to specific objects, especially specific resource versions and/or specific fields of those objects, are specified using the `ObjectReference` type (or other types representing strict subsets of it). Unlike partial URLs, the ObjectReference type facilitates flexible defaulting of fields from the referring object or other contextual information.
|
||||
|
||||
@@ -298,7 +298,7 @@ labels:
|
||||
|
||||
## Idempotency
|
||||
|
||||
All compatible Kubernetes APIs MUST support "name idempotency" and respond with an HTTP status code 409 when a request is made to POST an object that has the same name as an existing object in the system. See [docs/user-guide/identifiers.md](/{{page.version}}/docs/user-guide/identifiers) for details.
|
||||
All compatible Kubernetes APIs MUST support "name idempotency" and respond with an HTTP status code 409 when a request is made to POST an object that has the same name as an existing object in the system. See [docs/user-guide/identifiers.md](/docs/user-guide/identifiers) for details.
|
||||
|
||||
Names generated by the system may be requested using `metadata.generateName`. GenerateName indicates that the name should be made unique by the server prior to persisting it. A non-empty value for the field indicates the name will be made unique (and the name returned to the client will be different than the name passed). The value of this field will be combined with a unique suffix on the server if the Name field has not been provided. The provided value must be valid within the rules for Name, and may be truncated by the length of the suffix required to make the value unique on the server. If this field is specified, and Name is not present, the server will NOT return a 409 if the generated name exists - instead, it will either return 201 Created or 504 with Reason `ServerTimeout` indicating a unique name could not be found in the time allotted, and the client should retry (optionally after the time indicated in the Retry-After header).
|
||||
|
||||
@@ -637,7 +637,7 @@ However, we should support conveniences for common cases by default. For example
|
||||
|
||||
If the user wants to apply additional labels to the pods that it doesn't select upon, such as to facilitate adoption of pods or in the expectation that some label values will change, they can set the selector to a subset of the pod labels. Similarly, the RC's labels could be initialized to a subset of the pod template's labels, or could include additional/different labels.
|
||||
|
||||
For disciplined users managing resources within their own namespaces, it's not that hard to consistently apply schemas that ensure uniqueness. One just needs to ensure that at least one value of some label key in common differs compared to all other comparable resources. We could/should provide a verification tool to check that. However, development of conventions similar to the examples in [Labels](/{{page.version}}/docs/user-guide/labels) make uniqueness straightforward. Furthermore, relatively narrowly used namespaces (e.g., per environment, per application) can be used to reduce the set of resources that could potentially cause overlap.
|
||||
For disciplined users managing resources within their own namespaces, it's not that hard to consistently apply schemas that ensure uniqueness. One just needs to ensure that at least one value of some label key in common differs compared to all other comparable resources. We could/should provide a verification tool to check that. However, development of conventions similar to the examples in [Labels](/docs/user-guide/labels) make uniqueness straightforward. Furthermore, relatively narrowly used namespaces (e.g., per environment, per application) can be used to reduce the set of resources that could potentially cause overlap.
|
||||
|
||||
In cases where users could be running misc. examples with inconsistent schemas, or where tooling or components need to programmatically generate new objects to be selected, there needs to be a straightforward way to generate unique label sets. A simple way to ensure uniqueness of the set is to ensure uniqueness of a single label value, such as by using a resource name, uid, resource hash, or generation number.
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
|
||||
Before attempting a change to the API, you should familiarize yourself
|
||||
with a number of existing API types and with the [API
|
||||
conventions](/{{page.version}}/docs/devel/api-conventions). If creating a new API
|
||||
conventions](/docs/devel/api-conventions). If creating a new API
|
||||
type/resource, we also recommend that you first send a PR containing
|
||||
just a proposal for the new API types, and that you initially target
|
||||
the extensions API (pkg/apis/extensions).
|
||||
@@ -182,7 +182,7 @@ pass (e.g., `heightInInches` from `height`, and vice versa), which runs just pri
|
||||
to conversion. That works fine when the user creates a resource from a hand-written
|
||||
configuration -- clients can write either field and read either field, but what about
|
||||
creation or update from the output of GET, or update via PATCH (see
|
||||
[In-place updates](/{{page.version}}/docs/user-guide/managing-deployments/#in-place-updates-of-resources))?
|
||||
[In-place updates](/docs/user-guide/managing-deployments/#in-place-updates-of-resources))?
|
||||
In this case, the two fields will conflict, because only one field would be updated
|
||||
in the case of an old client that was only aware of the old field (e.g., `height`).
|
||||
|
||||
@@ -252,7 +252,7 @@ Compatibility for experimental or alpha APIs is not strictly required, but
|
||||
breaking compatibility should not be done lightly, as it disrupts all users of the
|
||||
feature. Experimental APIs may be removed. Alpha and beta API versions may be deprecated
|
||||
and eventually removed wholesale, as described in the [versioning document](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/versioning.md).
|
||||
Document incompatible changes across API versions under the [conversion tips](/{{page.version}}/docs/api/).
|
||||
Document incompatible changes across API versions under the [conversion tips](/docs/api/).
|
||||
|
||||
If your change is going to be backward incompatible or might be a breaking change for API
|
||||
consumers, please send an announcement to `kubernetes-dev@googlegroups.com` before
|
||||
@@ -494,7 +494,7 @@ doing!
|
||||
|
||||
## Write end-to-end tests
|
||||
|
||||
Check out the [E2E docs](/{{page.version}}/docs/devel/e2e-tests) for detailed information about how to write end-to-end
|
||||
Check out the [E2E docs](/docs/devel/e2e-tests) for detailed information about how to write end-to-end
|
||||
tests for your feature.
|
||||
|
||||
## Examples and docs
|
||||
@@ -564,7 +564,7 @@ New feature development proceeds through a series of stages of increasing maturi
|
||||
upgrade may require downtime for anything relying on the new feature, and may require
|
||||
manual conversion of objects to the new version; when manual conversion is necessary, the
|
||||
project will provide documentation on the process (for an example, see [v1 conversion
|
||||
tips](/{{page.version}}/docs/api/))
|
||||
tips](/docs/api/))
|
||||
- Cluster Reliability: since the feature has e2e tests, enabling the feature via a flag should not
|
||||
create new bugs in unrelated features; because the feature is new, it may have minor bugs
|
||||
- Support: the project commits to complete the feature, in some form, in a subsequent Stable
|
||||
@@ -6,7 +6,7 @@
|
||||
- https://google-styleguide.googlecode.com/svn/trunk/shell.xml
|
||||
- Ensure that build, release, test, and cluster-management scripts run on OS X
|
||||
- Go
|
||||
- Ensure your code passes the [presubmit checks](/{{page.version}}/docs/devel/development/#hooks)
|
||||
- Ensure your code passes the [presubmit checks](/docs/devel/development/#hooks)
|
||||
- [Go Code Review Comments](https://github.com/golang/go/wiki/CodeReviewComments)
|
||||
- [Effective Go](https://golang.org/doc/effective_go)
|
||||
- Comment your code.
|
||||
@@ -23,10 +23,10 @@
|
||||
- Importers can use a different name if they need to disambiguate.
|
||||
- Locks should be called `lock` and should never be embedded (always `lock sync.Mutex`). When multiple locks are present, give each lock a distinct name following Go conventions - `stateLock`, `mapLock` etc.
|
||||
- API conventions
|
||||
- [API changes](/{{page.version}}/docs/devel/api_changes)
|
||||
- [API conventions](/{{page.version}}/docs/devel/api-conventions)
|
||||
- [Kubectl conventions](/{{page.version}}/docs/devel/kubectl-conventions)
|
||||
- [Logging conventions](/{{page.version}}/docs/devel/logging)
|
||||
- [API changes](/docs/devel/api_changes)
|
||||
- [API conventions](/docs/devel/api-conventions)
|
||||
- [Kubectl conventions](/docs/devel/kubectl-conventions)
|
||||
- [Logging conventions](/docs/devel/logging)
|
||||
|
||||
Testing conventions
|
||||
|
||||
@@ -45,7 +45,7 @@ Directory and file conventions
|
||||
- Package directories should generally avoid using separators as much as possible (when packages are multiple words, they usually should be in nested subdirectories).
|
||||
- Document directories and filenames should use dashes rather than underscores
|
||||
- Contrived examples that illustrate system features belong in /docs/user-guide or /docs/admin, depending on whether it is a feature primarily intended for users that deploy applications or cluster administrators, respectively. Actual application examples belong in /examples.
|
||||
- Examples should also illustrate [best practices for using the system](/{{page.version}}/docs/user-guide/config-best-practices)
|
||||
- Examples should also illustrate [best practices for using the system](/docs/user-guide/config-best-practices)
|
||||
- Third-party code
|
||||
- Third-party Go code is managed using Godeps
|
||||
- Other third-party code belongs in /third_party
|
||||
+1
-1
@@ -11,7 +11,7 @@ Running kubernetes with Vagrant (and VirtualBox) is an easy way to run/test/deve
|
||||
2. [VMWare Fusion](https://www.vmware.com/products/fusion/) version 5 or greater as well as the appropriate [Vagrant VMWare Fusion provider](https://www.vagrantup.com/vmware)
|
||||
3. [VMWare Workstation](https://www.vmware.com/products/workstation/) version 9 or greater as well as the [Vagrant VMWare Workstation provider](https://www.vagrantup.com/vmware)
|
||||
4. [Parallels Desktop](https://www.parallels.com/products/desktop/) version 9 or greater as well as the [Vagrant Parallels provider](https://parallels.github.io/vagrant-parallels/)
|
||||
3. Get or build a [binary release](/{{page.version}}/docs/getting-started-guides/binary_release)
|
||||
3. Get or build a [binary release](/docs/getting-started-guides/binary_release)
|
||||
|
||||
### Setup
|
||||
|
||||
@@ -66,7 +66,7 @@ git push -f origin myfeature
|
||||
|
||||
1. Visit https://github.com/$YOUR_GITHUB_USERNAME/kubernetes
|
||||
2. Click the "Compare and pull request" button next to your "myfeature" branch.
|
||||
3. Check out the pull request [process](/{{page.version}}/docs/devel/pull-requests) for more details
|
||||
3. Check out the pull request [process](/docs/devel/pull-requests) for more details
|
||||
|
||||
### When to retain commits and when to squash
|
||||
|
||||
@@ -80,7 +80,7 @@ fixups (e.g. automated doc formatting), use one or more commits for the
|
||||
changes to tooling and a final commit to apply the fixup en masse. This makes
|
||||
reviews much easier.
|
||||
|
||||
See [Faster Reviews](/{{page.version}}/docs/devel/faster_reviews) for more details.
|
||||
See [Faster Reviews](/docs/devel/faster_reviews) for more details.
|
||||
|
||||
## godep and dependency management
|
||||
|
||||
@@ -297,8 +297,8 @@ go run hack/e2e.go -v -ctl='delete pod foobar'
|
||||
## Conformance testing
|
||||
|
||||
End-to-end testing, as described above, is for [development
|
||||
distributions](/{{page.version}}/docs/devel/writing-a-getting-started-guide). A conformance test is used on
|
||||
a [versioned distro](/{{page.version}}/docs/devel/writing-a-getting-started-guide).
|
||||
distributions](/docs/devel/writing-a-getting-started-guide). A conformance test is used on
|
||||
a [versioned distro](/docs/devel/writing-a-getting-started-guide).
|
||||
|
||||
The conformance test runs a subset of the e2e-tests against a manually-created cluster. It does not
|
||||
require support for up/push/down and other operations. To run a conformance test, you need to know the
|
||||
@@ -308,7 +308,7 @@ See [conformance-test.sh](http://releases.k8s.io/{{page.githubbranch}}/hack/conf
|
||||
|
||||
## Testing out flaky tests
|
||||
|
||||
[Instructions here](/{{page.version}}/docs/devel/flaky-tests)
|
||||
[Instructions here](/docs/devel/flaky-tests)
|
||||
|
||||
## Regenerating the CLI documentation
|
||||
|
||||
@@ -23,10 +23,10 @@ Let's talk about how to avoid this.
|
||||
|
||||
## 0. Familiarize yourself with project conventions
|
||||
|
||||
* [Development guide](/{{page.version}}/docs/devel/development)
|
||||
* [Coding conventions](/{{page.version}}/docs/devel/coding-conventions)
|
||||
* [API conventions](/{{page.version}}/docs/devel/api-conventions)
|
||||
* [Kubectl conventions](/{{page.version}}/docs/devel/kubectl-conventions)
|
||||
* [Development guide](/docs/devel/development)
|
||||
* [Coding conventions](/docs/devel/coding-conventions)
|
||||
* [API conventions](/docs/devel/api-conventions)
|
||||
* [Kubectl conventions](/docs/devel/kubectl-conventions)
|
||||
|
||||
## 1. Don't build a cathedral in one PR
|
||||
|
||||
@@ -0,0 +1,78 @@
|
||||
---
|
||||
---
|
||||
|
||||
The developer guide is for anyone wanting to either write code which directly accesses the
|
||||
Kubernetes API, or to contribute directly to the Kubernetes project.
|
||||
It assumes some familiarity with concepts in the [User Guide](/docs/user-guide/) and the [Cluster Admin
|
||||
Guide](/docs/admin/).
|
||||
|
||||
|
||||
## The process of developing and contributing code to the Kubernetes project
|
||||
|
||||
* **On Collaborative Development** ([collab.md](/docs/devel/collab)): Info on pull requests and code reviews.
|
||||
|
||||
* **GitHub Issues** ([issues.md](/docs/devel/issues)): How incoming issues are reviewed and prioritized.
|
||||
|
||||
* **Pull Request Process** ([pull-requests.md](/docs/devel/pull-requests)): When and why pull requests are closed.
|
||||
|
||||
* **Faster PR reviews** ([faster_reviews.md](/docs/devel/faster_reviews)): How to get faster PR reviews.
|
||||
|
||||
* **Getting Recent Builds** ([getting-builds.md](/docs/devel/getting-builds)): How to get recent builds including the latest builds that pass CI.
|
||||
|
||||
* **Automated Tools** ([automation.md](/docs/devel/automation)): Descriptions of the automation that is running on our github repository.
|
||||
|
||||
|
||||
## Setting up your dev environment, coding, and debugging
|
||||
|
||||
* **Development Guide** ([development.md](/docs/devel/development)): Setting up your development environment.
|
||||
|
||||
* **Hunting flaky tests** ([flaky-tests.md](/docs/devel/flaky-tests)): We have a goal of 99.9% flake free tests.
|
||||
Here's how to run your tests many times.
|
||||
|
||||
* **Logging Conventions** ([logging.md](/docs/devel/logging)]: Glog levels.
|
||||
|
||||
* **Profiling Kubernetes** ([profiling.md](/docs/devel/profiling)): How to plug in go pprof profiler to Kubernetes.
|
||||
|
||||
* **Instrumenting Kubernetes with a new metric**
|
||||
([instrumentation.md](/docs/devel/instrumentation)): How to add a new metrics to the
|
||||
Kubernetes code base.
|
||||
|
||||
* **Coding Conventions** ([coding-conventions.md](/docs/devel/coding-conventions)):
|
||||
Coding style advice for contributors.
|
||||
|
||||
|
||||
## Developing against the Kubernetes API
|
||||
|
||||
* API objects are explained at [http://kubernetes.io/third_party/swagger-ui/](http://kubernetes.io/third_party/swagger-ui/).
|
||||
|
||||
* **Annotations** ([docs/user-guide/annotations.md](/docs/user-guide/annotations)): are for attaching arbitrary non-identifying metadata to objects.
|
||||
Programs that automate Kubernetes objects may use annotations to store small amounts of their state.
|
||||
|
||||
* **API Conventions** ([api-conventions.md](/docs/devel/api-conventions)):
|
||||
Defining the verbs and resources used in the Kubernetes API.
|
||||
|
||||
* **API Client Libraries** ([client-libraries.md](/docs/devel/client-libraries)):
|
||||
A list of existing client libraries, both supported and user-contributed.
|
||||
|
||||
|
||||
## Writing plugins
|
||||
|
||||
* **Authentication Plugins** ([docs/admin/authentication.md](/docs/admin/authentication)):
|
||||
The current and planned states of authentication tokens.
|
||||
|
||||
* **Authorization Plugins** ([docs/admin/authorization.md](/docs/admin/authorization)):
|
||||
Authorization applies to all HTTP requests on the main apiserver port.
|
||||
This doc explains the available authorization implementations.
|
||||
|
||||
* **Admission Control Plugins** ([admission_control](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/admission_control.md))
|
||||
|
||||
|
||||
## Building releases
|
||||
|
||||
* **Making release notes** ([making-release-notes.md](/docs/devel/making-release-notes)): Generating release nodes for a new release.
|
||||
|
||||
* **Releasing Kubernetes** ([releasing.md](/docs/devel/releasing)): How to create a Kubernetes release (as in version)
|
||||
and how the version information gets embedded into the built binaries.
|
||||
|
||||
|
||||
|
||||
@@ -30,7 +30,7 @@ Additionally, for infrequent or new contributors, we require the on call to appl
|
||||
## Automation
|
||||
|
||||
We use a variety of automation to manage pull requests. This automation is described in detail
|
||||
[elsewhere.](/{{page.version}}/docs/devel/automation)
|
||||
[elsewhere.](/docs/devel/automation)
|
||||
|
||||
|
||||
|
||||
@@ -87,7 +87,7 @@ In your git repo (you still have `${VER}` set from above right?):
|
||||
|
||||
#### Writing Release Notes
|
||||
|
||||
[This helpful guide](/{{page.version}}/docs/devel/making-release-notes) describes how to write release
|
||||
[This helpful guide](/docs/devel/making-release-notes) describes how to write release
|
||||
notes for a major/minor release. In the release template on GitHub, leave the
|
||||
last PR number that the tool finds for the `.0` release, so the next releaser
|
||||
doesn't have to hunt.
|
||||
@@ -99,7 +99,7 @@ doesn't have to hunt.
|
||||
We cut `vX.Y.Z` releases from the `release-vX.Y` branch after all cherry picks
|
||||
to the branch have been resolved. You should ensure all outstanding cherry picks
|
||||
have been reviewed and merged and the branch validated on Jenkins (validation
|
||||
TBD). See the [Cherry Picks](/{{page.version}}/docs/devel/cherry-picks) for more information on how to
|
||||
TBD). See the [Cherry Picks](/docs/devel/cherry-picks) for more information on how to
|
||||
manage cherry picks prior to cutting the release.
|
||||
|
||||
#### Tagging and Merging
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
---
|
||||
|
||||
For each unscheduled Pod, the Kubernetes scheduler tries to find a node across the cluster according to a set of rules. A general introduction to the Kubernetes scheduler can be found at [scheduler.md](/{{page.version}}/docs/devel/scheduler). In this document, the algorithm of how to select a node for the Pod is explained. There are two steps before a destination node of a Pod is chosen. The first step is filtering all the nodes and the second is ranking the remaining nodes to find a best fit for the Pod.
|
||||
For each unscheduled Pod, the Kubernetes scheduler tries to find a node across the cluster according to a set of rules. A general introduction to the Kubernetes scheduler can be found at [scheduler.md](/docs/devel/scheduler). In this document, the algorithm of how to select a node for the Pod is explained. There are two steps before a destination node of a Pod is chosen. The first step is filtering all the nodes and the second is ranking the remaining nodes to find a best fit for the Pod.
|
||||
|
||||
## Filtering the nodes
|
||||
|
||||
@@ -11,7 +11,7 @@ The purpose of filtering the nodes is to filter out the nodes that do not meet c
|
||||
- `PodFitsResources`: Check if the free resource (CPU and Memory) meets the requirement of the Pod. The free resource is measured by the capacity minus the sum of requests of all Pods on the node. To learn more about the resource QoS in Kubernetes, please check [QoS proposal](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/proposals/resource-qos.md).
|
||||
- `PodFitsHostPorts`: Check if any HostPort required by the Pod is already occupied on the node.
|
||||
- `PodFitsHost`: Filter out all nodes except the one specified in the PodSpec's NodeName field.
|
||||
- `PodSelectorMatches`: Check if the labels of the node match the labels specified in the Pod's `nodeSelector` field ([Here](/{{page.version}}/docs/user-guide/node-selection/) is an example of how to use `nodeSelector` field).
|
||||
- `PodSelectorMatches`: Check if the labels of the node match the labels specified in the Pod's `nodeSelector` field ([Here](/docs/user-guide/node-selection/) is an example of how to use `nodeSelector` field).
|
||||
- `CheckNodeLabelPresence`: Check if all the specified labels exist on a node or not, regardless of the value.
|
||||
|
||||
The details of the above predicates can be found in [plugin/pkg/scheduler/algorithm/predicates/predicates.go](http://releases.k8s.io/{{page.githubbranch}}/plugin/pkg/scheduler/algorithm/predicates/predicates.go). All predicates mentioned above can be used in combination to perform a sophisticated filtering policy. Kubernetes uses some, but not all, of these predicates by default. You can see which ones are used by default in [plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go](http://releases.k8s.io/{{page.githubbranch}}/plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go).
|
||||
@@ -32,7 +32,7 @@ Currently, Kubernetes scheduler provides some practical priority functions, incl
|
||||
- `CalculateSpreadPriority`: Spread Pods by minimizing the number of Pods belonging to the same service on the same node.
|
||||
- `CalculateAntiAffinityPriority`: Spread Pods by minimizing the number of Pods belonging to the same service on nodes with the same value for a particular label.
|
||||
|
||||
The details of the above priority functions can be found in [plugin/pkg/scheduler/algorithm/priorities](http://releases.k8s.io/{{page.githubbranch}}/plugin/pkg/scheduler/algorithm/priorities/). Kubernetes uses some, but not all, of these priority functions by default. You can see which ones are used by default in [plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go](http://releases.k8s.io/{{page.githubbranch}}/plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go). Similar as predicates, you can combine the above priority functions and assign weight factors (positive number) to them as you want (check [scheduler.md](/{{page.version}}/docs/devel/scheduler) for how to customize).
|
||||
The details of the above priority functions can be found in [plugin/pkg/scheduler/algorithm/priorities](http://releases.k8s.io/{{page.githubbranch}}/plugin/pkg/scheduler/algorithm/priorities/). Kubernetes uses some, but not all, of these priority functions by default. You can see which ones are used by default in [plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go](http://releases.k8s.io/{{page.githubbranch}}/plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go). Similar as predicates, you can combine the above priority functions and assign weight factors (positive number) to them as you want (check [scheduler.md](/docs/devel/scheduler) for how to customize).
|
||||
|
||||
|
||||
|
||||
+4
-4
@@ -12,7 +12,7 @@ A guide refers to scripts, Configuration Management files, and/or binary assets
|
||||
the combination of all these things needed to run on a particular type of infrastructure a
|
||||
**distro**.
|
||||
|
||||
[The Matrix](/{{page.version}}/docs/getting-started-guides/) lists the distros. If there is already a guide
|
||||
[The Matrix](/docs/getting-started-guides/) lists the distros. If there is already a guide
|
||||
which is similar to the one you have planned, consider improving that one.
|
||||
|
||||
|
||||
@@ -35,9 +35,9 @@ These guidelines say *what* to do. See the Rationale section for *why*.
|
||||
search for uses of flags by guides.
|
||||
- We may ask that you host binary assets or large amounts of code in our `contrib` directory or on your
|
||||
own repo.
|
||||
- Add or update a row in [The Matrix](/{{page.version}}/docs/getting-started-guides/).
|
||||
- Add or update a row in [The Matrix](/docs/getting-started-guides/).
|
||||
- State the binary version of Kubernetes that you tested clearly in your Guide doc.
|
||||
- Setup a cluster and run the [conformance test](/{{page.version}}/docs/devel/development/#conformance-testing) against it, and report the
|
||||
- Setup a cluster and run the [conformance test](/docs/devel/development/#conformance-testing) against it, and report the
|
||||
results in your PR.
|
||||
- Versioned distros should typically not modify or add code in `cluster/`. That is just scripts for developer
|
||||
distros.
|
||||
@@ -46,7 +46,7 @@ These guidelines say *what* to do. See the Rationale section for *why*.
|
||||
|
||||
If you have a cluster partially working, but doing all the above steps seems like too much work,
|
||||
we still want to hear from you. We suggest you write a blog post or a Gist, and we will link to it on our wiki page.
|
||||
Just file an issue or chat us on [Slack](/{{page.version}}/docs/troubleshooting/#slack) and one of the committers will link to it from the wiki.
|
||||
Just file an issue or chat us on [Slack](/docs/troubleshooting/#slack) and one of the committers will link to it from the wiki.
|
||||
|
||||
## Development Distro Guidelines
|
||||
|
||||
@@ -56,7 +56,7 @@ NOTE: If using an existing keypair named "kubernetes" then you must set the `AWS
|
||||
|
||||
### Alternatives
|
||||
|
||||
A contributed [example](/{{page.version}}/docs/getting-started-guides/coreos/coreos_multinode_cluster) allows you to setup a Kubernetes cluster based on [CoreOS](http://www.coreos.com), using
|
||||
A contributed [example](/docs/getting-started-guides/coreos/coreos_multinode_cluster) allows you to setup a Kubernetes cluster based on [CoreOS](http://www.coreos.com), using
|
||||
EC2 with user data (cloud-config).
|
||||
|
||||
## Getting started with your cluster
|
||||
@@ -75,14 +75,14 @@ export PATH=<path/to/kubernetes-directory>/platforms/darwin/amd64:$PATH
|
||||
export PATH=<path/to/kubernetes-directory>/platforms/linux/amd64:$PATH
|
||||
```
|
||||
|
||||
An up-to-date documentation page for this tool is available here: [kubectl manual](/{{page.version}}/docs/user-guide/kubectl/kubectl)
|
||||
An up-to-date documentation page for this tool is available here: [kubectl manual](/docs/user-guide/kubectl/kubectl)
|
||||
|
||||
By default, `kubectl` will use the `kubeconfig` file generated during the cluster startup for authenticating against the API.
|
||||
For more information, please read [kubeconfig files](/{{page.version}}/docs/user-guide/kubeconfig-file)
|
||||
For more information, please read [kubeconfig files](/docs/user-guide/kubeconfig-file)
|
||||
|
||||
### Examples
|
||||
|
||||
See [a simple nginx example](/{{page.version}}/docs/user-guide/simple-nginx) to try out your new cluster.
|
||||
See [a simple nginx example](/docs/user-guide/simple-nginx) to try out your new cluster.
|
||||
|
||||
The "Guestbook" application is another popular example to get started with Kubernetes: [guestbook example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/guestbook/)
|
||||
|
||||
@@ -99,5 +99,5 @@ cluster/kube-down.sh
|
||||
|
||||
## Further reading
|
||||
|
||||
Please see the [Kubernetes docs](/{{page.version}}/docs/) for more details on administering
|
||||
Please see the [Kubernetes docs](/docs/) for more details on administering
|
||||
and using a Kubernetes cluster.
|
||||
@@ -0,0 +1,10 @@
|
||||
---
|
||||
---
|
||||
|
||||
|
||||
## Getting started on Microsoft Azure
|
||||
|
||||
Checkout the [coreos azure getting started guide](/docs/getting-started-guides/coreos/azure/)
|
||||
|
||||
|
||||
|
||||
+2
-2
@@ -12,7 +12,7 @@ You need two machines with CentOS installed on them.
|
||||
|
||||
This is a getting started guide for CentOS. It is a manual configuration so you understand all the underlying packages / services / ports, etc...
|
||||
|
||||
This guide will only get ONE node working. Multiple nodes requires a functional [networking configuration](/{{page.version}}/docs/admin/networking) done outside of kubernetes. Although the additional Kubernetes configuration requirements should be obvious.
|
||||
This guide will only get ONE node working. Multiple nodes requires a functional [networking configuration](/docs/admin/networking) done outside of kubernetes. Although the additional Kubernetes configuration requirements should be obvious.
|
||||
|
||||
The Kubernetes package provides a few services: kube-apiserver, kube-scheduler, kube-controller-manager, kubelet, kube-proxy. These services are managed by systemd and the configuration resides in a central location: /etc/kubernetes. We will break the services up between the hosts. The first host, centos-master, will be the Kubernetes master. This host will run the kube-apiserver, kube-controller-manager, and kube-scheduler. In addition, the master will also run _etcd_. The remaining host, centos-minion will be the node and run kubelet, proxy, cadvisor and docker.
|
||||
|
||||
@@ -168,4 +168,4 @@ centos-minion <none> Ready
|
||||
|
||||
**The cluster should be running! Launch a test pod.**
|
||||
|
||||
You should have a functional cluster, check out [101](/{{page.version}}/docs/user-guide/walkthrough/)!
|
||||
You should have a functional cluster, check out [101](/docs/user-guide/walkthrough/)!
|
||||
+1
-1
@@ -6,7 +6,7 @@ CloudStack is a software to build public and private clouds based on hardware vi
|
||||
[CoreOS](http://coreos.com) templates for CloudStack are built [nightly](http://stable.release.core-os.net/amd64-usr/current/). CloudStack operators need to [register](http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/templates) this template in their cloud before proceeding with these Kubernetes deployment instructions.
|
||||
|
||||
This guide uses an [Ansible playbook](https://github.com/runseb/ansible-kubernetes).
|
||||
This is a completely automated, a single playbook deploys Kubernetes based on the coreOS [instructions](/{{page.version}}/docs/getting-started-guides/coreos/coreos_multinode_cluster).
|
||||
This is a completely automated, a single playbook deploys Kubernetes based on the coreOS [instructions](/docs/getting-started-guides/coreos/coreos_multinode_cluster).
|
||||
|
||||
|
||||
This [Ansible](http://ansibleworks.com) playbook deploys Kubernetes on a CloudStack based Cloud using CoreOS images. The playbook, creates an ssh key pair, creates a security group and associated rules and finally starts coreOS instances configured via cloud-init.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user