whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'master' of https://github.com/kubernetes/website into release-1.9

Browse Source 
* 'master' of https://github.com/kubernetes/website: (140 commits)
  Update configure-multiple-schedulers.md (#6877)
  Explicitly specify the components that need a change (#6873)
  Updates to partner page (#6797)
  Add steps for extension api-server setup (#6667)
  securing a cluster: add recommendations about cloud metadata APIs (#6659)
  Namespace glossary term (#6607)
  Update device plugin doc with upgrade suggestions and known limitations. (#6501)
  Add Kubermatic to pick-right-solution.md (#6459)
  extra word
  typo
  Fix concepts/configuration/secret
  Link to extended resources instead of deprecated opaque integer resources
  Fix CI issue
  Corrected the group in runtime-config of ValidatingAdmissionWebhook and MutatingAdmissionWebhook. It should be admissionregistration.k8s.io (was admissionregistration).
  Correct references in Jekyll data files
  Update scheduling-hugepages.md
  Drop reference to outdated FAQ
  Follow sig list to kubernetes/community
  Update scheduling-hugepages.md
  Fix references to ConfigMap for the CN website
  ...

# Conflicts:
#	docs/concepts/policy/pod-security-policy.md
This commit is contained in:
Andrew Chen
2018-01-08 18:24:38 -08:00
parent 3013651535 96648cfc1d
commit b09f1b94f2
270 changed files with 2961 additions and 2071 deletions
Download Patch File Download Diff File Expand all files Collapse all files
OWNERS_ALIASES
+206
View File
@@ -0,0 +1,206 @@
aliases:
sig-api-machinery: #Team: API Server; GH: sig-api-machinery-pr-reviews; e.g. Annotations, Labels
- lavalamp
- sttts
- liggitt
- smarterclayton
- deads2k
sig-apps: #Team: Workloads; GH: sig-apps-pr-reviews; e.g. ConfigMaps, CronJobs, CustomResourceDefinitions, DaemonSets, Deployments, Jobs, Secrets, StatefulSets
- enisoc
- erictune
- foxish
- janetkuo
- kow3ns
- lukaszo
- mfojtik
- smarterclayton
- soltysh
- tnozicka
sig-architecture: #GH: sig-architecture-pr-reviews
- smarterclayton
- bgrant0607
sig-auth: #GH: sig-auth-pr-reviews
- php-coder
- liggitt
- mikedanese
- ericchiang
- mattmoyer
- enj
- deads2k
- davidopp
sig-autoscaling: #GH: sig-autoscaling-pr-reviews
- DirectXMan12
- bskiba
- aleksandra-malinowska
- MaciekPytel
- davidopp
- mwielgus
sig-aws: #Amazon AWS
- justinsb
- kris-nova
- chrislovecnm
- mfburnett
sig-azure: #Microsoft Azure
- slack
- colemickens
- jdumars
sig-big-data: #GH: sig-big-data-pr-reviews
- foxish
sig-cli: #Team: CLI; GH: sig-cli-pr-reviews; e.g. kubectl
- adohe
- deads2k
- derekwaynecarr
- dims
- dshulyak
- eparis
- ericchiang
- ghodss
- mengqiy
- rootfs
- shiywang
- smarterclayton
- soltysh
- sttts
sig-cluster-lifecycle: #GH: sig-cluster-lifecycle-pr-reviews
- jbeda
- timothysc
- lukemarsden
- pipejakob
- dmmcquay
- mattmoyer
- luxas
- roberthbailey
- medinatiger
sig-cluster-ops:
- zehicle
- jdumars
sig-contribex: #aka Contributor Experience; GH: sig-contributor-experience-pr-reviews
- rmmh
- cblecker
- apelisse
- grodrigues3
- spxtr
sig-contributor-experience: #GH: sig-contributor-experience-pr-reviews
- rmmh
- cblecker
- apelisse
- grodrigues3
- spxtr
sig-docs: #Team: documentation; GH: sig-docs-pr-reviews
- a-mccarthy
- abiogenesis-now
- bradamant3
- steveperry-53
- zacharysarah
sig-federation: #Team: Federation; e.g. Federated Clusters
- csbell
sig-gcp: #Google Cloud Platform; GH: sig-gcp-pr-reviews
- abgworrall
sig-instrumentation: #GH: sig-instrumentation-pr-reviews; e.g. metrics, logging, events
- DirectXMan12
- x13n
- kawych
- crassirostris
- brancz
- fabxc
- loburm
- piosz
- fgrzadkowski
sig-multicluster: #GH: sig-multicluster-pr-reviews; e.g. resiliency against availability zone outages; hybrid clouds; spanning multiple cloud providers; migration to public clouds
- madhusudancs
- marun
- jianhuiz
- shashidharatd
- nikhiljindal
- quinton-hoole
- mwielgus
- csbell
sig-network: #Team: Network; GH: sig-network-pr-reviews; e.g. Ingress, Network Policies, Services
- bowei
- caseydavenport
- danwinship
- dcbw
- dnardo
- freehan
- mrhohn
- nicksardo
- thockin
sig-node: #Team: Node; GH: sig-node-pr-reviews; e.g. Containers, Docker, Images, OS images, Pods, Registries
- Random-Liu
- dashpole
- dchen1107
- derekwaynecarr
- dims
- feiskyer
- mtaufen
- ncdc
- pmorie
- resouer
- sjpotter
- tallclair
- tmrts
- vishh
- yifan-gu
- yujuhong
sig-onprem: #On-premises; GH: sig-onprem-pr-reviews
- zen
- idvoretskyi
- pigmej
- feiskyer
- nebril
sig-openstack: #GH: sig-openstack-pr-reviews
- idvoretskyi
- xsgordon
- NickrenREN
sig-pm: #aka Product Management
- apsinha
- idvoretskyi
- calebamiles
sig-product-management:
- apsinha
- idvoretskyi
- calebamiles
sig-release: #GH: sig-release-pr-reviews
- calebamiles
- enisoc
- pwittrock
sig-rktnetes:
- calebamiles
sig-scalability: #GH: sig-scalability-pr-reviews
- jbeda
- spiffxp
- lavalamp
- countspongebob
sig-scheduling: #Team: Sharing; GH: sig-scheduling-pr-reviews; e.g. Scheduler
- bsalamat
- davidopp
- jayunit100
- k82cn
- resouer
- timothysc
- wojtek-t
sig-service-catalog: #GH: sig-service-catalog-pr-reviews; e.g. Service Broker
- pmorie
- jessfraz
- pwittrock
- droot
- seans3
sig-storage: #Team: Storage; GH: sig-storage-pr-reviews; e.g. Volumes
- childsb
- jsafrane
- rootfs
- saad-ali
- matchstick
- msau42
sig-testing: #GH: sig-testing-pr-reviews
- fejta
- ixdy
- rmmh
- spiffxp
- spxtr
sig-ui: #User Interface
- danielromlein
- floreks
sig-windows:
- michmike
_config.yml
+5 -5
View File
@@ -27,27 +27,27 @@ defaults:
version: "v1.9"
githubbranch: "v1.9.0"
docsbranch: "release-1.9"
url: https://kubernetes.io/docs/home/
url: https://kubernetes.io
- fullversion: "v1.8.4"
version: "v1.8"
githubbranch: "v1.8.4"
docsbranch: "release-1.8"
url: https://v1-8.docs.kubernetes.io/docs/home/
url: https://v1-8.docs.kubernetes.io
- fullversion: "v1.7.6"
version: "v1.7"
githubbranch: "v1.7.6"
docsbranch: "release-1.7"
url: https://v1-7.docs.kubernetes.io/docs/home/
url: https://v1-7.docs.kubernetes.io
- fullversion: "v1.6.8"
version: "v1.6"
githubbranch: "v1.6.8"
docsbranch: "release-1.6"
url: https://v1-6.docs.kubernetes.io/docs/home/
url: https://v1-6.docs.kubernetes.io
- fullversion: "v1.5.7"
version: "v1.5"
githubbranch: "v1.5.7"
docsbranch: "release-1.5"
url: https://v1-5.docs.kubernetes.io/docs/
url: https://v1-5.docs.kubernetes.io
deprecated: false
currentUrl: https://kubernetes.io/docs/home/
nextUrl: http://kubernetes-io-vnext-staging.netlify.com/
_data/glossary/configmap.yaml
+1 -1
View File
@@ -1,6 +1,6 @@
id: configmap
name: ConfigMap
full-link: /docs/tasks/configure-pod-container/configmap/
full-link: /docs/tasks/configure-pod-container/configure-pod-configmap/
related:
- pod
- secret
_data/glossary/labels.yaml
+5 -4
View File
@@ -1,9 +1,10 @@
id: labels
name: Labels
id: label
name: Label
full-link: /docs/concepts/overview/working-with-objects/labels
tags:
- fundamental
short-description: >
Used to tag objects with identifying attributes that are meaningful and relevant to users.
Tags objects with identifying attributes that are meaningful and relevant to users.
long-description: >
Labels are key/value pairs that are attached to objects, such as pods. They can be used to organize and to select subsets of objects.
Labels are key/value pairs that are attached to objects such as {% glossary_tooltip text="Pods" term_id="pod" %}.
They are used to organize and to select subsets of objects.
_data/glossary/namespace.yaml
+4 -3
View File
@@ -2,8 +2,9 @@ id: namespace
name: Namespace
full-link: /docs/concepts/overview/working-with-objects/namespaces
tags:
- fundamental
- fundamental
short-description: >
An abstraction used by Kubernetes to support virtual clusters on the same physical {% glossary_tooltip term_id="cluster" %}.
An abstraction used by Kubernetes to support multiple virtual clusters on the same physical {% glossary_tooltip term_id="cluster" %}.
long-description: >
Namespaces are used to organize objects in a cluster and provide a way to divide cluster resources. Names of resources need to be unique within a namespace, but not across namespaces.
Namespaces are used to organize objects in a cluster and provide a way to divide cluster resources.
Names of resources need to be unique within a namespace, but not across namespaces.
_data/glossary/persistent-volume-claim.yaml
+15
View File
@@ -0,0 +1,15 @@
id: persistent-volume-claim
name: Persistent Volume Claim
full-link: /docs/concepts/storage/persistent-volumes/
related:
- persistent-volume
- statefulset
- deployment
- pod
tags:
- core-object
- storage
short-description: >
Claims storage resources defined in a {% glossary_tooltip text="PersistentVolume (PV)" term_id="persistent-volume" %} so that it can be mounted as a volume in a container.
long-description: |
Specifies the amount of storage, how the storage will be accessed (read-only, read-write and/or exclusive) and how it is reclaimed (retained, recycled or deleted). Details of the storage itself are in the PersistentVolume specification.
_data/glossary/persistent-volume.yaml
+17
View File
@@ -0,0 +1,17 @@
id: persistent-volume
name: Persistent Volume
full-link: /docs/concepts/storage/persistent-volumes/
related:
- statefulset
- deployment
- persistent-volume-claim
- pod
tags:
- core-object
- storage
short-description: >
An API object that represents a piece of storage in the cluster. Available as a general, pluggable resource that persists beyond the lifecycle of any individual {% glossary_tooltip term_id="pod" %}.
long-description: |
PersistentVolumes (PVs) provide an API that abstracts details of how storage is provided from how it is consumed.
PVs are used directly in scenarios where storage can be be created ahead of time (static provisioning).
For scenarios that require on-demand storage (dynamic provisioning), PersistentVolumeClaims (PVCs) are used instead.
_data/glossary/secret.yml
+1 -1
View File
@@ -12,4 +12,4 @@ short-description: >
long-description: >
Allows for more control over how sensitive information is used and reduces the risk of accidental exposure, including [encryption](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted) at rest.
A {% glossary_tooltip text="Pod" term_id="pod" %} references the secret as a file in a volume mount or by the kubelet pulling images for a pod.
Secrets are great for confidential data and [ConfigMaps](https://kubernetes.io/docs/tasks/configure-pod-container/configmap/) for non-confidential data.
Secrets are great for confidential data and [ConfigMaps](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/) for non-confidential data.
_data/glossary/service-catalog.yaml
+1 -1
View File
@@ -5,4 +5,4 @@ tags:
short-description: >
An extension API that enables applications running in Kubernetes clusters to easily use external managed software offerings, such as a datastore service offered by a cloud provider.
long-description: >
Service Catalog provides a way to list, provision, and bind with external {% glossary_tooltip text="Managed Services" term_id="managed-service" %} from {% glossary_tooltip text="Service Brokers" term_id="service-broker" %} without needing detailed knowledge about how those services are created or managed.
It provides a way to list, provision, and bind with external {% glossary_tooltip text="Managed Services" term_id="managed-service" %} from {% glossary_tooltip text="Service Brokers" term_id="service-broker" %} without needing detailed knowledge about how those services are created or managed.
_data/tasks.yml
-1
View File
@@ -28,7 +28,6 @@ toc:
- docs/tasks/configure-pod-container/assign-pods-nodes.md
- docs/tasks/configure-pod-container/configure-pod-initialization.md
- docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
- docs/tasks/configure-pod-container/configmap.md
- docs/tasks/configure-pod-container/configure-pod-configmap.md
- docs/tools/kompose/user-guide.md
_includes/footer.html
+1 -1
View File
@@ -28,7 +28,7 @@
&copy; {{ 'now' | date: "%Y" }} The Kubernetes Authors | Documentation Distributed under <a href="https://git.k8s.io/website/LICENSE" class="light-text">CC BY 4.0</a>
</div>
<div id="miceType" class="center">
Copyright &copy; {{ 'now' | date: "%Y" }} The Linux Foundation&reg;. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our Trademark Usage page: <a href="https://www.linuxfoundation.org/trademark-usage" class="light-text">https://www.linuxfoundation.org/trademark-usage</a>
Copyright &copy; {{ 'now' | date: "%Y" }} The Linux Foundation&reg;. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our <a href="https://www.linuxfoundation.org/trademark-usage" class="light-text">Trademark Usage page</a>
</div>
</main>
</footer>
_includes/header.html
+5 -1
View File
@@ -16,7 +16,11 @@
</a>
<ul>
{% for version in page.versions %}
<li><a href="{{ version.url }}">{{ version.version }}</a></li>
{% if page.versionedurl contains version.version %}
<li><a href="{{ version.url }}{{ page.versionedurl[version.version] }}">{{ version.version }}</a></li>
{% else %}
<li><a href="{{ version.url }}{{ page.url }}">{{ version.version }}</a></li>
{% endif %}
{% endfor %}
</ul>
</li>
_includes/partner-script.js
+65 -9
View File
@@ -11,8 +11,8 @@
type: 0,
name: 'Puppet',
logo: 'puppet',
link: 'https://puppet.com/blog/managing-kubernetes-configuration-puppet',
blurb: 'The Puppet module for Kubernetes makes it easy to manage Pods, Replication Controllers, Services and more in Kubernetes, and to build domain-specific interfaces to one\'s Kubernetes configuration.'
link: 'https://puppet.com/blog/announcing-kream-and-new-kubernetes-helm-and-docker-modules',
blurb: 'We\'ve developed tools and products to make your adoption of Kubernetes as efficient as possible, covering your full workflow cycle from development to production. And now Puppet Pipelines for Containers is your complete DevOps dashboard for Kubernetes.'
},
{
type: 0,
@@ -43,7 +43,7 @@
blurb: 'Powering the GIFEE (Google’s Infrastructure for Everyone Else), to run OpenStack deployments on Kubernetes.'
},
{
type: 0,
type: 3,
name: 'Platform9',
logo: 'platform9',
link: 'https://platform9.com/products/kubernetes/',
@@ -131,7 +131,7 @@
name: 'Hasura',
logo: 'hasura',
link: 'https://hasura.io',
blurb: 'Hasura - Hasura'
blurb: 'Hasura is a Kubernetes-based PaaS and a Postgres-based BaaS that accelerates app development with ready-to-use components.'
},
{
type: 3,
@@ -462,6 +462,13 @@
link: 'http://kublr.com',
blurb: 'Kublr - Accelerate and control the deployment, scaling, monitoring and management of your containerized applications.'
},
{
type: 1,
name: 'ControlPlane',
logo: 'controlplane',
link: 'https://control-plane.io',
blurb: 'We are a London-based Kubernetes consultancy with a focus on security and continuous delivery. We offer consulting & training.'
},
{
type: 3,
name: 'Nirmata',
@@ -469,6 +476,13 @@
link: 'https://www.nirmata.com/',
blurb: 'Nirmata - Nirmata Managed Kubernetes'
},
{
type: 2,
name: 'Nirmata',
logo: 'nirmata',
link: 'https://www.nirmata.com/',
blurb: 'Nirmata is a software platform that helps DevOps teams deliver enterprise-grade and cloud-provider agnostic Kubernetes based container management solutions.'
},
{
type: 3,
name: 'TenxCloud',
@@ -477,11 +491,11 @@
blurb: 'TenxCloud - TenxCloud Container Engine (TCE)'
},
{
type: 3,
type: 0,
name: 'Twistlock',
logo: 'twistlock',
link: 'https://www.twistlock.com/',
blurb: 'Twistlock - Twistlock'
blurb: 'Security at Kubernetes Scale: Twistlock allows you to deploy fearlessly with assurance that your images and containers are free of vulnerabilities and protected at runtime.'
},
{
type: 0,
@@ -519,7 +533,7 @@
blurb: 'CloudKite.io helps companies build and maintain highly automated, resilient, and impressively performing software on Kubernetes.'
},
{
type: 1,
type: 2,
name: 'CloudOps',
logo: 'CloudOps',
link: 'https://www.cloudops.com/services/docker-and-kubernetes-workshops/',
@@ -532,6 +546,13 @@
link: 'https://www.ghostcloud.cn/ecos-kubernetes',
blurb: 'EcOS is an enterprise-grade PaaS / CaaS based on Docker and Kubernetes, which makes it easier to configure, deploy and manage containerized applications.'
},
{
type: 3,
name: 'Ghostcloud',
logo: 'ghostcloud',
link: 'https://www.ghostcloud.cn/ecos-kubernetes',
blurb: 'EcOS is an enterprise-grade PaaS / CaaS based on Docker and Kubernetes, which makes it easier to configure, deploy and manage containerized applications.'
},
{
type: 2,
name: 'Contino',
@@ -703,7 +724,7 @@
{
type: 3,
name: 'Google Kubernetes Engine',
logo: 'gcp',
logo: 'google',
link: 'https://cloud.google.com/kubernetes-engine/',
blurb: 'Google - Google Kubernetes Engine'
},
@@ -864,7 +885,7 @@
{
type: 3,
name: 'Google',
logo: 'gcp',
logo: 'google',
link: 'https://github.com/kubernetes/kubernetes/tree/master/cluster',
blurb: 'Google - kube-up.sh on Google Compute Engine'
},
@@ -882,6 +903,13 @@
link: 'https://www.163yun.com/product/container-service-dedicated',
blurb: 'Netease - Netease Container Service Dedicated'
},
{
type: 2,
name: 'Loodse',
logo: 'loodse',
link: 'https://loodse.com',
blurb: 'Loodse provides Kubernetes training & consulting, and host related events regularly across Europe.'
},
{
type: 3,
name: 'Loodse',
@@ -889,6 +917,13 @@
link: 'https://loodse.com',
blurb: 'Loodse - Kubermatic Container Engine'
},
{
type: 1,
name: 'LTI',
logo: 'lti',
link: 'https://www.lntinfotech.com/',
blurb: 'LTI helps enterprises architect, develop and support scalable cloud native apps using Docker and Kubernetes for private or public cloud.'
},
{
type: 3,
name: 'Microsoft',
@@ -966,6 +1001,13 @@
link: 'https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/',
blurb: 'Weaveworks - kubeadm'
},
{
type: 3,
name: 'Joyent',
logo: 'joyent',
link: 'https://github.com/joyent/triton-kubernetes',
blurb: 'Joyent - Triton Kubernetes'
},
{
type: 3,
name: 'Wise2c',
@@ -994,6 +1036,13 @@
link: 'http://www.daocloud.io/dce',
blurb: 'DaoCloud - DaoCloud Enterprise'
},
{
type: 2,
name: 'Daocloud',
logo: 'daocloud',
link: 'http://www.daocloud.io/dce',
blurb: 'We provide enterprise-level cloud native application platform that supports both Kubernetes and Docker Swarm.'
},
{
type: 3,
name: 'SUSE',
@@ -1127,6 +1176,13 @@
link: 'http://dataspine.xyz/',
blurb: 'Dataspine is building a secure, elastic and serverless deployment platform for production ML/AI workloads on top of k8s.'
},
{
type: 1,
name: 'CloudBourne',
logo: 'cloudbourne',
link: 'https://cloudbourne.com/kubernetes-enterprise-hybrid-cloud/',
blurb: 'Want to achieve maximum build, deploy and monitoring automation using Kubernetes? We can help.'
},
{
type: 0,
name: 'Logdna',
_includes/v1.3/v1-definitions.html
+1 -1
View File
@@ -6415,7 +6415,7 @@ The resulting set of endpoints can be viewed as:<br>
<tbody>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">names</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Names by which this image is known. e.g. ["gcr.io/google_containers/hyperkube:v1.0.7", "dockerhub.io/google_containers/hyperkube:v1.0.7"]</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Names by which this image is known. e.g. ["k8s.gcr.io/hyperkube:v1.0.7", "dockerhub.io/google_containers/hyperkube:v1.0.7"]</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">true</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">string array</p></td>
<td class="tableblock halign-left valign-top"></td>
_includes/v1.4/v1-definitions.html
+1 -1
View File
@@ -6671,7 +6671,7 @@ The resulting set of endpoints can be viewed as:<br>
<tbody>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">names</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Names by which this image is known. e.g. ["gcr.io/google_containers/hyperkube:v1.0.7", "dockerhub.io/google_containers/hyperkube:v1.0.7"]</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Names by which this image is known. e.g. ["k8s.gcr.io/hyperkube:v1.0.7", "dockerhub.io/google_containers/hyperkube:v1.0.7"]</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">true</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">string array</p></td>
<td class="tableblock halign-left valign-top"></td>
_includes/v1.5/v1-definitions.html
+1 -1
View File
@@ -6850,7 +6850,7 @@ The resulting set of endpoints can be viewed as:<br>
<tbody>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">names</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Names by which this image is known. e.g. ["gcr.io/google_containers/hyperkube:v1.0.7", "dockerhub.io/google_containers/hyperkube:v1.0.7"]</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Names by which this image is known. e.g. ["k8s.gcr.io/hyperkube:v1.0.7", "dockerhub.io/google_containers/hyperkube:v1.0.7"]</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">true</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">string array</p></td>
<td class="tableblock halign-left valign-top"></td>
_plugins/README.md
+1
View File
@@ -25,6 +25,7 @@ This renders the definition of the glossary term inside a `<div>`, preserving Ma
| --- | --- | --- |
| `term_id` | N/A (Required) | The `id` of the glossary term whose definition will be used. (This `id` is the same as the filename of the term, i.e. `_data/glossary/<ID>.yml`.) |
| `length` | "short" | Specifies which term definition should be used ("short" for the `short-definition`, "long" for `long-description`, "all" when both should be included). |
| `prepend` | "Service Catalog is" | A prefix which can be attached in front of a term's short definition (which is one or more sentence fragments). |
#### (2) `glossary_tooltip` tag
_plugins/glossary_tags.rb
+8 -2
View File
@@ -55,11 +55,17 @@ module Jekyll
class Definition < Base
VALID_PARAM_NAMES = [
:term_id,
:length
:length,
:prepend,
].freeze
def render(context)
include_snippet(context)
text = include_snippet(context)
if @args[:prepend]
text.sub(/<p>(.)/) { "<p>#{@args[:prepend]} #{$1.downcase}" }
else
text
end
end
end
_redirects
+6 -5
View File
@@ -76,11 +76,10 @@
/docs/api-reference/v1.5/* https://v1-5.docs.kubernetes.io/docs/reference/ 301
/docs/api-reference/v1.6/* https://v1-6.docs.kubernetes.io/docs/reference/ 301
/docs/api-reference/v1.7/* https://v1-7.docs.kubernetes.io/docs/reference/ 301
/docs/api-reference/v1.8/* https://v1-8.docs.kubernetes.io/docs/reference/ 301
/docs/api-reference/v1.8/* https://v1-8.docs.kubernetes.io/docs/api-reference/v1.8/:splat 301
/docs/api-reference/v1/definitions/ /docs/api-reference/v1.9/ 301
/docs/api-reference/v1/operations/ /docs/api-reference/v1.9/ 301
/docs/concepts/abstractions/controllers/garbage-collection/ /docs/concepts/workloads/controllers/garbage-collection/ 301
/docs/concepts/abstractions/controllers/petsets/ /docs/concepts/workloads/controllers/statefulset/ 301
/docs/concepts/abstractions/controllers/statefulsets/ /docs/concepts/workloads/controllers/statefulset/ 301
@@ -197,9 +196,9 @@
/docs/resources-reference/1_5/* /docs/resources-reference/v1.5/ 301
/docs/resources-reference/1_5/* https://v1-5.docs.kubernetes.io/docs/resources-reference/v1.5/ 301
/docs/resources-reference/v1.5/node_modules/* https://v1-5.docs.kubernetes.io/docs/resources-reference/v1.5/ 301
/docs/resources-reference/1_6/* /docs/resources-reference/v1.6/ 301
/docs/resources-reference/1_7/* /docs/resources-reference/v1.7/ 301
/docs/resources-reference/v1.5/node_modules/* https://v1-5.docs.kubernetes.io/docs/resources-reference/v1.5/ 301
/docs/resources-reference/v1.8/* /docs/api-reference/v1.8/:splat 301
/docs/roadmap/ https://github.com/kubernetes/kubernetes/milestones/ 301
@@ -218,7 +217,7 @@
/docs/tasks/administer-cluster/default-cpu-request-limit/ /docs/tasks/configure-pod-container/assign-cpu-resource/#specify-a-cpu-request-and-a-cpu-limit/ 301
/docs/tasks/administer-cluster/default-memory-request-limit/ /docs/tasks/configure-pod-container/assign-memory-resource/#specify-a-memory-request-and-a-memory-limit/ 301
/docs/tasks/administer-cluster/developing-cloud-controller-manager.md /docs/tasks/administer-cluster/developing-cloud-controller-manager/ 301
/docs/tasks/administer-cluster/out-of-resource/memory-available.sh /docs/concepts/cluster-administration/out-of-resource/memory-available.sh 301
/docs/tasks/administer-cluster/out-of-resource/memory-available.sh /docs/tasks/administer-cluster/memory-available.sh 301
/docs/tasks/administer-cluster/overview/ /docs/concepts/cluster-administration/cluster-administration-overview/ 301
/docs/tasks/administer-cluster/reserve-compute-resources/out-of-resource.md /docs/tasks/administer-cluster/out-of-resource/ 301
/docs/tasks/administer-cluster/running-cloud-controller.md /docs/tasks/administer-cluster/running-cloud-controller/ 301
@@ -341,7 +340,8 @@
/docs/user-guide/kubeconfig-file/ /docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/ 301
/docs/user-guide/kubectl-overview/ /docs/reference/kubectl/overview/
/docs/user-guide/kubectl/ /docs/reference/generated/kubectl/kubectl-options/
/docs/user-guide/kubectl/v1.8/ /docs/reference/generated/kubectl/kubectl-commands/
/docs/user-guide/kubectl/v1.8/* https://v1-8.docs.kubernetes.io/docs/reference/generated/kubectl/kubectl-commands/:splat 301
/docs/user-guide/kubectl/v1.9/* /docs/reference/generated/kubectl/kubectl-commands/:splat 301
/docs/user-guide/kubectl-conventions/ /docs/reference/kubectl/conventions/
/docs/user-guide/kubectl-cheatsheet/ /docs/reference/kubectl/cheatsheet/
/docs/user-guide/kubectl/1_5/* https://v1-5.docs.kubernetes.io/docs/user-guide/kubectl/v1.5/ 301
@@ -443,3 +443,4 @@ https://kubernetes-io-v1-7.netlify.com/* https://v1-7.docs.kubernetes.io/:spl
/docs/admin/kubefed_unjoin/ /docs/reference/generated/kubefed_unjoin/ 301
/docs/admin/kubefed_version/ /docs/reference/generated/kubefed_version/ 301
/docs/reference/generated/kubeadm/ /docs/reference/setup-tools/kubeadm/kubeadm/ 301
cn/docs/admin/cluster-large.md
+1 -1
View File
@@ -85,7 +85,7 @@ AWS使用的规格为：
```yaml
containers:
- name: fluentd-cloud-logging
image: gcr.io/google_containers/fluentd-gcp:1.16
image: k8s.gcr.io/fluentd-gcp:1.16
resources:
limits:
cpu: 100m
cn/docs/admin/node-conformance.md
+3 -3
View File
@@ -40,7 +40,7 @@ title: 节点设置校验
# $LOG_DIR 是测试结果输出的路径。
sudo docker run -it --rm --privileged --net=host \
-v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
gcr.io/google_containers/node-test:0.2
k8s.gcr.io/node-test:0.2
```
## 针对其他硬件体系结构运行节点合规性测试
@@ -61,7 +61,7 @@ Kubernetes 也为其他硬件体系结构的系统提供了节点合规性测试
sudo docker run -it --rm --privileged --net=host \
-v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
-e FOCUS=MirrorPod \ # 只运行MirrorPod测试
gcr.io/google_containers/node-test:0.2
k8s.gcr.io/node-test:0.2
```
为跳过指定的测试，用正则表达式来描述将要跳过的测试，并重载 `SKIP` 环境变量。
@@ -70,7 +70,7 @@ sudo docker run -it --rm --privileged --net=host \
sudo docker run -it --rm --privileged --net=host \
-v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
-e SKIP=MirrorPod \ # 运行除MirrorPod外的所有测试
gcr.io/google_containers/node-test:0.2
k8s.gcr.io/node-test:0.2
```
节点合规性测试是[节点端到端测试](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/devel/e2e-node-tests.md)的一个容器化的版本。
cn/docs/concepts/architecture/cloud-controller.md
+1 -1
View File
@@ -172,7 +172,7 @@ v1/ServiceAccount:
针对CCM的RBAC ClusterRole如下所示：
```yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cloud-controller-manager
cn/docs/concepts/architecture/nodes.md
+1 -1
View File
@@ -216,7 +216,7 @@ metadata:
spec:
containers:
- name: sleep-forever
image: gcr.io/google_containers/pause:0.8.0
image: k8s.gcr.io/pause:0.8.0
resources:
requests:
cpu: 100m
cn/docs/concepts/configuration/manage-compute-resources-container.md
+1 -1
View File
@@ -199,7 +199,7 @@ Conditions:
Events:
FirstSeen LastSeen Count From SubobjectPath Reason Message
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {scheduler } scheduled Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "gcr.io/google_containers/pause:0.8.0" already present on machine
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "k8s.gcr.io/pause:0.8.0" already present on machine
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD created Created with docker id 6a41280f516d
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD started Started with docker id 6a41280f516d
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} spec.containers{simmemleak} created Created with docker id 87348f12526a
cn/docs/concepts/configuration/pod-with-node-affinity.yaml
+1 -1
View File
@@ -23,4 +23,4 @@ spec:
- another-node-label-value
containers:
- name: with-node-affinity
image: gcr.io/google_containers/pause:2.0
image: k8s.gcr.io/pause:2.0
cn/docs/concepts/configuration/pod-with-pod-affinity.yaml
+1 -1
View File
@@ -26,4 +26,4 @@ spec:
topologyKey: kubernetes.io/hostname
containers:
- name: with-pod-affinity
image: gcr.io/google_containers/pause:2.0
image: k8s.gcr.io/pause:2.0
cn/docs/concepts/configuration/secret.md
+1 -1
View File
@@ -518,7 +518,7 @@ spec:
secretName: dotfile-secret
containers:
- name: dotfile-test-container
image: gcr.io/google_containers/busybox
image: k8s.gcr.io/busybox
command:
- ls
- "-l"
cn/docs/concepts/workloads/pods/pod-lifecycle.md
+1 -1
View File
@@ -108,7 +108,7 @@ spec:
containers:
- args:
- /server
image: gcr.io/google_containers/liveness
image: k8s.gcr.io/liveness
livenessProbe:
httpGet:
# when "host" is not defined, "PodIP" will be used
cn/docs/tasks/access-application-cluster/connecting-frontend-backend.md
+2 -2
View File
@@ -160,7 +160,7 @@ service "frontend" created
**注意**：这个 nginx 配置文件是被打包在 [容器镜像](/docs/tasks/access-application-cluster/frontend/Dockerfile) 里的。
更好的方法是使用 [ConfigMap](/docs/tasks/configure-pod-container/configmap/)，这样的话你可以更轻易地更改配置。
更好的方法是使用 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)，这样的话你可以更轻易地更改配置。
### 与前端 Service 交互
@@ -216,7 +216,7 @@ curl http://<EXTERNAL-IP>
* 了解更多 [Services](/docs/concepts/services-networking/service/)
* 了解更多 [ConfigMaps](/docs/tasks/configure-pod-container/configmap/)
* 了解更多 [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)
{% endcapture %}
cn/docs/tasks/access-application-cluster/redis-master.yaml
+1 -1
View File
@@ -9,7 +9,7 @@ metadata:
spec:
containers:
- name: master
image: gcr.io/google_containers/redis:v1
image: k8s.gcr.io/redis:v1
env:
- name: MASTER
value: "true"
cn/docs/tasks/administer-cluster/cpu-memory-limit.md
+1 -1
View File
@@ -178,7 +178,7 @@ $ kubectl get pods valid-pod --namespace=limit-example -o yaml | grep -C 6 resou
uid: 3b1bfd7a-f53c-11e5-b066-64510658e388
spec:
containers:
- image: gcr.io/google_containers/serve_hostname
- image: k8s.gcr.io/serve_hostname
imagePullPolicy: Always
name: kubernetes-serve-hostname
resources:
cn/docs/tasks/administer-cluster/dns-horizontal-autoscaler.yaml
+1 -1
View File
@@ -13,7 +13,7 @@ spec:
spec:
containers:
- name: autoscaler
image: gcr.io/google_containers/cluster-proportional-autoscaler-amd64:1.0.0
image: k8s.gcr.io/cluster-proportional-autoscaler-amd64:1.0.0
resources:
requests:
cpu: "20m"
cn/docs/tasks/administer-cluster/pod1.yaml
+1 -1
View File
@@ -7,4 +7,4 @@ metadata:
spec:
containers:
- name: pod-with-no-annotation-container
image: gcr.io/google_containers/pause:2.0
image: k8s.gcr.io/pause:2.0
cn/docs/tasks/administer-cluster/pod2.yaml
+1 -1
View File
@@ -8,4 +8,4 @@ spec:
schedulerName: default-scheduler
containers:
- name: pod-with-default-annotation-container
image: gcr.io/google_containers/pause:2.0
image: k8s.gcr.io/pause:2.0
cn/docs/tasks/administer-cluster/pod3.yaml
+1 -1
View File
@@ -8,4 +8,4 @@ spec:
schedulerName: my-scheduler
containers:
- name: pod-with-second-annotation-container
image: gcr.io/google_containers/pause:2.0
image: k8s.gcr.io/pause:2.0
cn/docs/tasks/configure-pod-container/exec-liveness.yaml
+1 -1
View File
@@ -15,7 +15,7 @@ spec:
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
image: gcr.io/google_containers/busybox
image: k8s.gcr.io/busybox
livenessProbe:
exec:
cn/docs/tasks/configure-pod-container/http-liveness.yaml
+1 -1
View File
@@ -9,7 +9,7 @@ spec:
- name: liveness
args:
- /server
image: gcr.io/google_containers/liveness
image: k8s.gcr.io/liveness
livenessProbe:
httpGet:
path: /healthz
cn/docs/tasks/configure-pod-container/tcp-liveness-readiness.yaml
+1 -1
View File
@@ -7,7 +7,7 @@ metadata:
spec:
containers:
- name: goproxy
image: gcr.io/google_containers/goproxy:0.1
image: k8s.gcr.io/goproxy:0.1
ports:
- containerPort: 8080
readinessProbe:
cn/docs/tasks/debug-application-cluster/debug-application.md
-4
View File
@@ -8,10 +8,6 @@ title: 应用故障排查
* TOC
{:toc}
## FAQ
强烈建议用户参考我们的[FAQ](https://github.com/kubernetes/kubernetes/wiki/User-FAQ).
## 诊断问题
故障排查的第一步是先给问题分下类。这个问题是什么？Pods，Replication Controller或者Service？
cn/docs/tasks/inject-data-application/dapi-envars-container.yaml
+1 -1
View File
@@ -5,7 +5,7 @@ metadata:
spec:
containers:
- name: test-container
image: gcr.io/google_containers/busybox:1.24
image: k8s.gcr.io/busybox:1.24
command: [ "sh", "-c"]
args:
- while true; do
cn/docs/tasks/inject-data-application/dapi-envars-pod.yaml
+1 -1
View File
@@ -5,7 +5,7 @@ metadata:
spec:
containers:
- name: test-container
image: gcr.io/google_containers/busybox
image: k8s.gcr.io/busybox
command: [ "sh", "-c"]
args:
- while true; do
cn/docs/tasks/inject-data-application/dapi-volume-resources.yaml
+1 -1
View File
@@ -5,7 +5,7 @@ metadata:
spec:
containers:
- name: client-container
image: gcr.io/google_containers/busybox:1.24
image: k8s.gcr.io/busybox:1.24
command: ["sh", "-c"]
args:
- while true; do
cn/docs/tasks/inject-data-application/dapi-volume.yaml
+1 -1
View File
@@ -12,7 +12,7 @@ metadata:
spec:
containers:
- name: client-container
image: gcr.io/google_containers/busybox
image: k8s.gcr.io/busybox
command: ["sh", "-c"]
args:
- while true; do
cn/docs/tasks/inject-data-application/define-command-argument-container.md
+1 -1
View File
@@ -63,7 +63,7 @@ title: 为容器设置启动时要执行的命令及其入参
args: ["$(MESSAGE)"]
这样一来，我们就可以将那些用来设置环境变量的方法应用于设置命令的入参，其
中包括了[ConfigMaps](/docs/tasks/configure-pod-container/configmap/)
中包括了[ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)
与
[Secrets](/docs/concepts/configuration/secret/).
cn/docs/tasks/manage-gpus/scheduling-gpus.md
+3 -3
View File
@@ -41,13 +41,13 @@ spec:
containers:
-
name: gpu-container-1
image: gcr.io/google_containers/pause:2.0
image: k8s.gcr.io/pause:2.0
resources:
limits:
alpha.kubernetes.io/nvidia-gpu: 2 # requesting 2 GPUs
-
name: gpu-container-2
image: gcr.io/google_containers/pause:2.0
image: k8s.gcr.io/pause:2.0
resources:
limits:
alpha.kubernetes.io/nvidia-gpu: 3 # requesting 3 GPUs
@@ -141,7 +141,7 @@ metadata:
spec:
containers:
- name: gpu-container-1
image: gcr.io/google_containers/pause:2.0
image: k8s.gcr.io/pause:2.0
resources:
limits:
alpha.kubernetes.io/nvidia-gpu: 1
cn/docs/tutorials/configuration/configure-redis-using-configmap.md
+3 -5
View File
@@ -7,7 +7,7 @@ title: 使用ConfigMap来配置Redis
{% capture overview %}
这篇文档基于[在Pods中使用ConfigMap数据](/docs/tasks/configure-pod-container/configure-pod-configmap/) 和 [使用ConfigMap来配置Containers](/docs/tasks/configure-pod-container/configmap/) 两个任务，提供了一个使用ConfigMap来配置Redis的真实案例。
这篇文档基于[使用ConfigMap来配置Containers](/docs/tasks/configure-pod-container/configure-pod-configmap/) 这个任务，提供了一个使用ConfigMap来配置Redis的真实案例。
{% endcapture %}
@@ -23,8 +23,7 @@ title: 使用ConfigMap来配置Redis
{% capture prerequisites %}
* {% include task-tutorial-prereqs.md %}
* 理解[在Pods中使用ConfigMap数据](/docs/tasks/configure-pod-container/configure-pod-configmap/)。
* 理解[使用ConfigMap来配置Containers](/docs/tasks/configure-pod-container/configmap/)。
* 理解[使用ConfigMap来配置Containers](/docs/tasks/configure-pod-container/configure-pod-configmap/)。
{% endcapture %}
@@ -120,8 +119,7 @@ title: 使用ConfigMap来配置Redis
{% capture whatsnext %}
* 了解关于[ConfigMaps](/docs/tasks/configure-pod-container/configmap/)的更多知识。
* 参见[在Pods中使用ConfigMap数据](/docs/tasks/configure-pod-container/configure-pod-configmap/)。
* 了解关于[ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)的更多知识。
{% endcapture %}
cn/docs/tutorials/services/source-ip.md
+1 -1
View File
@@ -33,7 +33,7 @@ Kubernetes 集群中运行的应用通过抽象的 Service 查找彼此，相互
你必须拥有一个正常工作的 Kubernetes 1.5 集群，用来运行本文中的示例。该示例使用一个简单的 nginx webserver 回送它接收到的请求的 HTTP 头中的源 IP 地址。你可以像下面这样创建它：
```console
$ kubectl run source-ip-app --image=gcr.io/google_containers/echoserver:1.4
$ kubectl run source-ip-app --image=k8s.gcr.io/echoserver:1.4
deployment "source-ip-app" created
```
cn/docs/tutorials/stateful-application/basic-stateful-set.md
+18 -18
View File
@@ -434,7 +434,7 @@ Kubernetes 1.7 版本的 StatefulSet 控制器支持自动更新。更新策略
Patch `web` StatefulSet 的容器镜像。
```shell
kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"gcr.io/google_containers/nginx-slim:0.7"}]'
kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"k8s.gcr.io/nginx-slim:0.7"}]'
"web" patched
```
@@ -470,9 +470,9 @@ web-0 1/1 Running 0 3s
```shell{% raw %}
kubectl get pod -l app=nginx -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[0].image}{"\n"}{end}'
web-0 gcr.io/google_containers/nginx-slim:0.7
web-1 gcr.io/google_containers/nginx-slim:0.8
web-2 gcr.io/google_containers/nginx-slim:0.8
web-0 k8s.gcr.io/nginx-slim:0.7
web-1 k8s.gcr.io/nginx-slim:0.8
web-2 k8s.gcr.io/nginx-slim:0.8
{% endraw %}```
`web-0` has had its image updated, but `web-0` and `web-1` still have the original
@@ -513,9 +513,9 @@ web-2 1/1 Running 0 36s
```shell{% raw %}
kubectl get pod -l app=nginx -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[0].image}{"\n"}{end}'
web-0 gcr.io/google_containers/nginx-slim:0.7
web-1 gcr.io/google_containers/nginx-slim:0.7
web-2 gcr.io/google_containers/nginx-slim:0.7
web-0 k8s.gcr.io/nginx-slim:0.7
web-1 k8s.gcr.io/nginx-slim:0.7
web-2 k8s.gcr.io/nginx-slim:0.7
{% endraw %}
```
@@ -539,7 +539,7 @@ statefulset "web" patched
在一个终端窗口中 patch `web` StatefulSet 来再次的改变容器镜像。
```shell
kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"gcr.io/google_containers/nginx-slim:0.8"}]'
kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"k8s.gcr.io/nginx-slim:0.8"}]'
statefulset "web" patched
```
@@ -589,9 +589,9 @@ StatefulSet 里的 Pod 采用和序号相反的顺序更新。在更新下一个
```shell{% raw %}
for p in 0 1 2; do kubectl get po web-$p --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
gcr.io/google_containers/nginx-slim:0.8
gcr.io/google_containers/nginx-slim:0.8
gcr.io/google_containers/nginx-slim:0.8
k8s.gcr.io/nginx-slim:0.8
k8s.gcr.io/nginx-slim:0.8
k8s.gcr.io/nginx-slim:0.8
{% endraw %}
```
@@ -617,7 +617,7 @@ statefulset "web" patched
再次 Patch StatefulSet 来改变容器镜像。
```shell
kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"gcr.io/google_containers/nginx-slim:0.7"}]'
kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"k8s.gcr.io/nginx-slim:0.7"}]'
statefulset "web" patched
```
@@ -646,7 +646,7 @@ web-2 1/1 Running 0 18s
```shell{% raw %}
get po web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
gcr.io/google_containers/nginx-slim:0.8
k8s.gcr.io/nginx-slim:0.8
{% endraw %}
```
@@ -683,7 +683,7 @@ web-2 1/1 Running 0 18s
```shell{% raw %}
kubectl get po web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
gcr.io/google_containers/nginx-slim:0.7
k8s.gcr.io/nginx-slim:0.7
{% endraw %}
```
@@ -721,7 +721,7 @@ web-1 1/1 Running 0 18s
```shell{% raw %}
get po web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
gcr.io/google_containers/nginx-slim:0.8
k8s.gcr.io/nginx-slim:0.8
{% endraw %}
```
@@ -767,9 +767,9 @@ web-0 1/1 Running 0 3s
```shell{% raw %}
for p in 0 1 2; do kubectl get po web-$p --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
gcr.io/google_containers/nginx-slim:0.7
gcr.io/google_containers/nginx-slim:0.7
gcr.io/google_containers/nginx-slim:0.7
k8s.gcr.io/nginx-slim:0.7
k8s.gcr.io/nginx-slim:0.7
k8s.gcr.io/nginx-slim:0.7
{% endraw %}
```
cn/docs/tutorials/stateful-application/web.yaml
+1 -1
View File
@@ -27,7 +27,7 @@ spec:
spec:
containers:
- name: nginx
image: gcr.io/google_containers/nginx-slim:0.8
image: k8s.gcr.io/nginx-slim:0.8
ports:
- containerPort: 80
name: web
cn/docs/tutorials/stateful-application/webp.yaml
+1 -1
View File
@@ -28,7 +28,7 @@ spec:
spec:
containers:
- name: nginx
image: gcr.io/google_containers/nginx-slim:0.8
image: k8s.gcr.io/nginx-slim:0.8
ports:
- containerPort: 80
name: web
cn/docs/tutorials/stateful-application/zookeeper.md
+2 -2
View File
@@ -25,7 +25,7 @@ title: 运行 ZooKeeper， 一个 CP 分布式系统
* [Headless Services](/docs/concepts/services-networking/service/#headless-services)
* [PersistentVolumes](/docs/concepts/storage/volumes/)
* [PersistentVolume Provisioning](http://releases.k8s.io/{{page.githubbranch}}/examples/persistent-volume-provisioning/)
* [ConfigMaps](/docs/tasks/configure-pod-container/configmap/)
* [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)
* [StatefulSets](/docs/concepts/abstractions/controllers/statefulsets/)
* [PodDisruptionBudgets](/docs/admin/disruptions/#specifying-a-poddisruptionbudget)
* [PodAntiAffinity](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature)
@@ -67,7 +67,7 @@ ZooKeeper 在内存中保存它们的整个状态机，但是每个改变都被
## 创建一个 ZooKeeper Ensemble
下面的清单包含一个 [Headless Service](/docs/user-guide/services/#headless-services)，一个 [ConfigMap](/docs/tasks/configure-pod-container/configmap/)，一个 [PodDisruptionBudget](/docs/admin/disruptions/#specifying-a-poddisruptionbudget) 和 一个 [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/)。
下面的清单包含一个 [Headless Service](/docs/user-guide/services/#headless-services)，一个 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)，一个 [PodDisruptionBudget](/docs/admin/disruptions/#specifying-a-poddisruptionbudget) 和 一个 [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/)。
{% include code.html language="yaml" file="zookeeper.yaml" ghlink="/docs/tutorials/stateful-application/zookeeper.yaml" %}
cn/index.html
+1 -1
View File
@@ -107,7 +107,7 @@ cid: home
<p>Kubernetes 逐渐部署对应用程序或其配置的更改，同时监视应用程序运行状况，以确保它不会同时终止所有实例。 如果出现问题，Kubernetes会为您恢复更改，利用日益增长的部署解决方案的生态系统。</p>
</div>
<div>
<h4><a href="/docs/concepts/configuration/secret/">密钥</a> 和 <a href="/docs/tasks/configure-pod-container/configmap/">配置</a> 管理</h4>
<h4><a href="/docs/concepts/configuration/secret/">密钥</a> 和 <a href="/docs/tasks/configure-pod-container/configure-pod-configmap/">配置</a> 管理</h4>
<p>部署和更新密钥和应用程序配置，不会重新编译您的镜像，不会在堆栈配置中暴露密钥(secrets)。</p>
</div>
</div>
code-of-conduct.md
+3
View File
@@ -0,0 +1,3 @@
# Kubernetes Community Code of Conduct
Please refer to our [Kubernetes Community Code of Conduct](https://git.k8s.io/community/code-of-conduct.md)
community/index.html
+3 -3
View File
@@ -24,7 +24,7 @@ cid: community
<div class="content">
<h3>Special Interest Groups (SIGs)</h3>
<p>Have a special interest in how Kubernetes works with another technology? See our ever growing
<a href="https://github.com/kubernetes/kubernetes/wiki/Special-Interest-Groups-(SIGs)">lists of SIGs</a>,
<a href="https://git.k8s.io/community/sig-list.md">lists of SIGs</a>,
from AWS and Openstack to Big Data and Scalability, there's a place for you to contribute and instructions
for forming a new SIG if your special interest isn't covered (yet).</p>
@@ -35,13 +35,13 @@ cid: community
frameborder="0" scrolling="no"></iframe>
</div>
</div>
<div class="content">
<!-- <div class="content">
<h3>Events</h3>
<div id="calendarEvents">
<iframe src="https://calendar.google.com/calendar/embed?src=nt2tcnbtbied3l6gi2h29slvc0%40group.calendar.google.com&ctz=America/Los_Angeles"
frameborder="0" scrolling="no"></iframe>
</div>
</div>
</div> -->
</main>
</section>
docs/admin/admission-controllers.md
+15 -2
View File
@@ -56,6 +56,19 @@ support all the features you expect.
The Kubernetes API server supports a flag, `admission-control` that takes a comma-delimited,
ordered list of admission control choices to invoke prior to modifying objects in the cluster.
For example, the following command line turns on the `NamespaceLifecycle` and the `LimitRanger`
admission controller:
```shell
kube-apiserver --admission-control=NamespaceLifecyle,LimitRanger ...
```
**Note**: Depending on the way your Kubernetes cluster is deployed and how the
API server is started, you may need to apply the settings in different ways.
For example, you may have to modify the systemd unit file if the API server is
deployed as a systemd service, you may modify the manifest file for the API
server if Kubernetes is deployed in a self-hosted way.
{: .note}
## What does each admission controller do?
@@ -321,7 +334,7 @@ If a webhook called by this has side effects (for example, decrementing quota) i
webhooks or validating admission controllers will permit the request to finish.
If you disable the MutatingAdmissionWebhook, you must also disable the
`MutatingWebhookConfiguration` object in the `admissionregistration/v1beta1`
`MutatingWebhookConfiguration` object in the `admissionregistration.k8s.io/v1beta1`
group/version via the `--runtime-config` flag (both are on by default in
versions >= 1.9).
@@ -522,7 +535,7 @@ If a webhook called by this has side effects (for example, decrementing quota) i
webhooks or other validating admission controllers will permit the request to finish.
If you disable the ValidatingAdmissionWebhook, you must also disable the
`ValidatingWebhookConfiguration` object in the `admissionregistration/v1beta1`
`ValidatingWebhookConfiguration` object in the `admissionregistration.k8s.io/v1beta1`
group/version via the `--runtime-config` flag (both are on by default in
versions >= 1.9).
docs/admin/authentication.md
+1 -1
View File
@@ -196,10 +196,10 @@ spec:
metadata:
# ...
spec:
serviceAccountName: bob-the-bot
containers:
- name: nginx
image: nginx:1.7.9
serviceAccountName: bob-the-bot
```
Service account bearer tokens are perfectly valid to use outside the cluster and
docs/admin/authorization/rbac.md
+1 -1
View File
@@ -851,7 +851,7 @@ You can use that information to determine which roles need to be granted to whic
Once you have [granted roles to service accounts](#service-account-permissions) and workloads are running with no RBAC denial messages
in the server logs, you can remove the ABAC authorizer.
### Permissive RBAC Permissions
## Permissive RBAC Permissions
You can replicate a permissive policy using RBAC role bindings.
docs/admin/bootstrap-tokens.md
+63 -36
View File
@@ -36,74 +36,86 @@ information. It is used when referring to a token without leaking the secret
part used for authentication. The second part is the "Token Secret" and should
only be shared with trusted parties.
## Enabling Bootstrap Tokens
## Enabling Bootstrap Token Authentication
All features for Bootstrap Tokens are disabled by default in Kubernetes v1.8.
The Bootstrap Token authenticator can be enabled using the following flag on the
API server:
You can enable the Bootstrap Token authenticator with the
`--enable-bootstrap-token-auth` flag on the API server. You can enable
the Bootstrap controllers by specifying them with the `--controllers` flag on the
controller manager with something like
`--controllers=*,tokencleaner,bootstrapsigner`. This is done automatically when
using `kubeadm`.
```
--enable-bootstrap-token-auth
```
Tokens are used in an HTTPS call as follows:
When enabled, bootstrapping tokens can be used as bearer token credentials to
authenticate requests against the API server.
```http
Authorization: Bearer 07401b.f395accd246ae52d
```
Tokens authenticate as the username `system:bootstrap:<token id>` and are members
of the group `system:bootstrappers`. Additional groups may be specified in the
token's Secret.
Expired tokens can be deleted automatically by enabling the `tokencleaner`
controller on the controller manager.
```
--controllers=*,tokencleaner
```
## Bootstrap Token Secret Format
Each valid token is backed by a secret in the `kube-system` namespace. You can
find the full design doc
[here](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md).
Here is what the secret looks like. Note that `base64(string)` indicates the
value should be base64 encoded. The undecoded version is provided here for
readability.
Here is what the secret looks like.
```yaml
apiVersion: v1
kind: Secret
metadata:
# Name MUST be of form "bootstrap-token-<token id>"
name: bootstrap-token-07401b
namespace: kube-system
# Type MUST be 'bootstrap.kubernetes.io/token'
type: bootstrap.kubernetes.io/token
data:
description: base64(The default bootstrap token generated by 'kubeadm init'.)
token-id: base64(07401b)
token-secret: base64(f395accd246ae52d)
expiration: base64(2017-03-10T03:22:11Z)
usage-bootstrap-authentication: base64(true)
usage-bootstrap-signing: base64(true)
auth-extra-groups: base64(system:bootstrappers:group1,system:bootstrappers:group2)
stringData:
# Human readable description. Optional.
description: "The default bootstrap token generated by 'kubeadm init'."
# Token ID and secret. Required.
token-id: 07401b
token-secret: f395accd246ae52d
# Expiration. Optional.
expiration: 2017-03-10T03:22:11Z
# Allowed usages.
usage-bootstrap-authentication: true
usage-bootstrap-signing: true
# Extra groups to authenticate the token as. Must start with "system:bootstrappers:"
auth-extra-groups: system:bootstrappers:worker,system:bootstrappers:ingress
```
The type of the secret must be `bootstrap.kubernetes.io/token` and the name must
be `bootstrap-token-<token id>`. It must also exist in the `kube-system`
namespace. `description` is a human readable description that should not be
used for machine readable information. The Token ID and Secret are included in
the data dictionary.
namespace.
The `usage-bootstrap-*` members indicate what this secret is intended to be used
for. A value must be set to `true` to be enabled.
`usage-bootstrap-authentication` indicates that the token can be used to
authenticate to the API server. The authenticator authenticates as
`system:bootstrap:<Token ID>`. It is included in the `system:bootstrappers`
group. `auth-extra-groups` indicates that it will also be included in the
`system:bootstrappers:group1`, and `system:bootstrappers:group2` groups. The
naming and groups are intentionally limited to discourage users from using these
tokens past bootstrapping. Extra bootstrap token groups must start with
`system:bootstrappers:`.
`usage-bootstrap-signing` indicates that the token should be used to sign the
* `usage-bootstrap-authentication` indicates that the token can be used to
authenticate to the API server as a bearer token.
* `usage-bootstrap-signing` indicates that the token may be used to sign the
`cluster-info` ConfigMap as described below.
The `expiration` data member lists a time after which the token is no longer
valid. This is encoded as an absolute UTC time using RFC3339. The TokenCleaner
controller will delete expired tokens.
The `expiration` field controls the expiry of the token. Expired tokens are
rejected when used for authentication and ignored during ConfigMap signing.
The expiry value is encoded as an absolute UTC time using RFC3339. Enable the
`tokencleaner` controller to automatically delete expired tokens.
## Token Management with `kubeadm`
@@ -116,6 +128,13 @@ In addition to authentication, the tokens can be used to sign a ConfigMap. This
is used early in a cluster bootstrap process before the client trusts the API
server. The signed ConfigMap can be authenticated by the shared token.
Enable ConfigMap signing by enabling the `bootstrapsigner` controller on the
Controller Manager.
```
--controllers=*,bootstrapsigner
```
The ConfigMap that is signed is `cluster-info` in the `kube-public` namespace.
The typical flow is that a client reads this ConfigMap while unauthenticated and
ignoring TLS errors. It then validates the payload of the ConfigMap by looking
@@ -156,3 +175,11 @@ is then used to form a whole JWS by inserting it between the 2 dots. You can
verify the JWS using the `HS256` scheme (HMAC-SHA256) with the full token (e.g.
`07401b.f395accd246ae52d`) as the shared secret. Users _must_ verify that HS256
is used.
WARNING: Any party with a bootstrapping token can create a valid signature for that
token. When using ConfigMap signing it's discouraged to share the same token with
many clients, since a compromised client can potentially man-in-the middle another
client relying on the signature to bootstrap TLS trust.
Consult the [kubeadm security model](/docs/reference/generated/kubeadm/#security-model)
section for more information.
docs/admin/cluster-large.md
+1 -1
View File
@@ -86,7 +86,7 @@ For example:
```yaml
containers:
- name: fluentd-cloud-logging
image: gcr.io/google_containers/fluentd-gcp:1.16
image: k8s.gcr.io/fluentd-gcp:1.16
resources:
limits:
cpu: 100m
docs/admin/federation/index.md
+6 -6
View File
@@ -87,9 +87,9 @@ images or you can build them yourself from HEAD.
### Using official release images
As part of every Kubernetes release, official release images are pushed to
`gcr.io/google_containers`. To use the images in this repository, you can
`k8s.gcr.io`. To use the images in this repository, you can
set the container image fields in the following configs to point to the
images in this repository. `gcr.io/google_containers/hyperkube` image
images in this repository. `k8s.gcr.io/hyperkube` image
includes the federation-apiserver and federation-controller-manager
binaries, so you can point the corresponding configs for those components
to the hyperkube image.
@@ -247,7 +247,7 @@ federation, and
in your federation DNS.
You can find more details about config maps in general at
[config map](/docs/tasks/configure-pod-container/configmap/).
[config map](/docs/tasks/configure-pod-container/configure-pod-configmap/).
### Kubernetes 1.4 and earlier: Setting federations flag on kube-dns-rc
@@ -315,8 +315,8 @@ official release images or you can build from HEAD.
#### Using official release images
As part of every release, images are pushed to `gcr.io/google_containers`. To use
these images, set env var `FEDERATION_PUSH_REPO_BASE=gcr.io/google_containers`
As part of every release, images are pushed to `k8s.gcr.io`. To use
these images, set env var `FEDERATION_PUSH_REPO_BASE=k8s.gcr.io`
This will always use the latest image.
To use the hyperkube image which includes federation-apiserver and
federation-controller-manager from a specific release, set the
@@ -345,7 +345,7 @@ Once you have the images, you can run these as pods on your existing kubernetes
The command to run these pods on an existing GCE cluster will look like:
```shell
$ KUBERNETES_PROVIDER=gce FEDERATION_DNS_PROVIDER=google-clouddns FEDERATION_NAME=myfederation DNS_ZONE_NAME=myfederation.example FEDERATION_PUSH_REPO_BASE=gcr.io/google_containers ./federation/cluster/federation-up.sh
$ KUBERNETES_PROVIDER=gce FEDERATION_DNS_PROVIDER=google-clouddns FEDERATION_NAME=myfederation DNS_ZONE_NAME=myfederation.example FEDERATION_PUSH_REPO_BASE=k8s.gcr.io ./federation/cluster/federation-up.sh
```
`KUBERNETES_PROVIDER` is the cloud provider.
docs/admin/high-availability/etcd.yaml
+1 -1
View File
@@ -5,7 +5,7 @@ metadata:
spec:
hostNetwork: true
containers:
- image: gcr.io/google_containers/etcd:3.0.17
- image: k8s.gcr.io/etcd:3.0.17
name: etcd-container
command:
- /usr/local/bin/etcd
docs/admin/high-availability/index.md
+51
View File
@@ -175,6 +175,57 @@ For pods that you deploy into the cluster, the `kubernetes` service/dns name sho
For external users of the API (e.g. the `kubectl` command line interface, continuous build pipelines, or other clients) you will want to configure
them to talk to the external load balancer's IP address.
### Endpoint reconciler
As mentioned in the previous section, the apiserver is exposed through a
service called `kubernetes`. The endpoints for this service correspond to
the apiserver replicas that we just deployed.
Since updating endpoints and services requires the apiserver to be up, there
is special code in the apiserver to let it update its own endpoints directly.
This code is called the "reconciler," because it reconciles the list of
endpoints stored in etcd, and the list of endpoints that are actually up
and running.
Prior Kubernetes 1.9, the reconciler expects you to provide the
number of endpoints (i.e., the number of apiserver replicas) through
a command-line flag (e.g. `--apiserver-count=3`). If more replicas
are available, the reconciler trims down the list of endpoints.
As a result, if a node running a replica of the apiserver crashes
and gets replaced, the list of endpoints is eventually updated.
However, until the replica gets replaced, its endpoint stays in
the list. During that time, a fraction of the API requests sent
to the `kubernetes` service will fail, because they will be sent
to a down endpoint.
This is why the previous section advises you to deploy a load
balancer, and access the API through that load balancer. The
load balancer will directly assess the health of the apiserver
replicas, and make sure that requests are not sent to crashed
instances.
If you do not add the `--apiserver-count` flag, the value defaults to 1.
Your cluster will work correctly, but each apiserver replica will
continuously try to add itself to the list of endpoints while removing
the other ones, causing a lot of extraneous updates in kube-proxy
and other components.
Starting with Kubernetes 1.9, a new reconciler implementation is available.
It uses a *lease* that is regularly renewed by each apiserver
replica. When a replica is down, it stops renewing its lease, and
the other replicas notice that the lease expired and remove it
from the list of endpoints. You can switch to the new reconciler
by adding the flag `--endpoint-reconciler-type=lease` when starting
your apiserver replicas.
If you want to know more, you can check the following resources:
- [issue kubernetes/kuberenetes#22609](https://github.com/kubernetes/kubernetes/issues/22609),
which gives additional context
- [master/reconcilers/mastercount.go](https://github.com/kubernetes/kubernetes/blob/dd9981d038012c120525c9e6df98b3beb3ef19e1/pkg/master/reconcilers/mastercount.go#L63),
the implementation of the master count reconciler
- [PR kubernetes/kubernetes#51698](https://github.com/kubernetes/kubernetes/pull/51698),
which adds support for the lease reconciler
## Master elected components
So far we have set up state storage, and we have set up the API server, but we haven't run anything that actually modifies
docs/admin/high-availability/kube-apiserver.yaml
+1 -1
View File
@@ -6,7 +6,7 @@ spec:
hostNetwork: true
containers:
- name: kube-apiserver
image: gcr.io/google_containers/kube-apiserver:9680e782e08a1a1c94c656190011bd02
image: k8s.gcr.io/kube-apiserver:9680e782e08a1a1c94c656190011bd02
command:
- /bin/sh
- -c
docs/admin/high-availability/kube-controller-manager.yaml
+1 -1
View File
@@ -10,7 +10,7 @@ spec:
- /usr/local/bin/kube-controller-manager --master=127.0.0.1:8080 --cluster-name=e2e-test-bburns
--cluster-cidr=10.245.0.0/16 --allocate-node-cidrs=true --cloud-provider=gce --service-account-private-key-file=/srv/kubernetes/server.key
--v=2 --leader-elect=true 1>>/var/log/kube-controller-manager.log 2>&1
image: gcr.io/google_containers/kube-controller-manager:fda24638d51a48baa13c35337fcd4793
image: k8s.gcr.io/kube-controller-manager:fda24638d51a48baa13c35337fcd4793
livenessProbe:
httpGet:
path: /healthz
docs/admin/high-availability/kube-scheduler.yaml
+1 -1
View File
@@ -6,7 +6,7 @@ spec:
hostNetwork: true
containers:
- name: kube-scheduler
image: gcr.io/google_containers/kube-scheduler:34d0b8f8b31e27937327961528739bc9
image: k8s.gcr.io/kube-scheduler:34d0b8f8b31e27937327961528739bc9
command:
- /bin/sh
- -c
docs/admin/high-availability/podmaster.yaml
+2 -2
View File
@@ -6,7 +6,7 @@ spec:
hostNetwork: true
containers:
- name: scheduler-elector
image: gcr.io/google_containers/podmaster:1.1
image: k8s.gcr.io/podmaster:1.1
command:
- /podmaster
- --etcd-servers=http://127.0.0.1:4001
@@ -20,7 +20,7 @@ spec:
- mountPath: /manifests
name: manifests
- name: controller-manager-elector
image: gcr.io/google_containers/podmaster:1.1
image: k8s.gcr.io/podmaster:1.1
command:
- /podmaster
- --etcd-servers=http://127.0.0.1:4001
docs/admin/limitrange/invalid-pod.yaml
+1 -1
View File
@@ -5,7 +5,7 @@ metadata:
spec:
containers:
- name: kubernetes-serve-hostname
image: gcr.io/google_containers/serve_hostname
image: k8s.gcr.io/serve_hostname
resources:
limits:
cpu: "3"
docs/admin/limitrange/valid-pod.yaml
+1 -1
View File
@@ -7,7 +7,7 @@ metadata:
spec:
containers:
- name: kubernetes-serve-hostname
image: gcr.io/google_containers/serve_hostname
image: k8s.gcr.io/serve_hostname
resources:
limits:
cpu: "1"
docs/admin/multiple-schedulers/pod1.yaml
+1 -1
View File
@@ -7,4 +7,4 @@ metadata:
spec:
containers:
- name: pod-with-no-annotation-container
image: gcr.io/google_containers/pause:2.0
image: k8s.gcr.io/pause:2.0
docs/admin/multiple-schedulers/pod2.yaml
+1 -1
View File
@@ -8,4 +8,4 @@ spec:
schedulerName: default-scheduler
containers:
- name: pod-with-default-annotation-container
image: gcr.io/google_containers/pause:2.0
image: k8s.gcr.io/pause:2.0
docs/admin/multiple-schedulers/pod3.yaml
+1 -1
View File
@@ -8,4 +8,4 @@ spec:
schedulerName: my-scheduler
containers:
- name: pod-with-second-annotation-container
image: gcr.io/google_containers/pause:2.0
image: k8s.gcr.io/pause:2.0
docs/admin/multiple-zones.md
+1 -1
View File
@@ -43,7 +43,7 @@ placement, and so if the zones in your cluster are heterogeneous
(e.g. different numbers of nodes, different types of nodes, or
different pod resource requirements), this might prevent perfectly
even spreading of your pods across zones. If desired, you can use
homogenous zones (same number and types of nodes) to reduce the
homogeneous zones (same number and types of nodes) to reduce the
probability of unequal spreading.
When persistent volumes are created, the `PersistentVolumeLabel`
docs/admin/namespaces/OWNERS
-4
View File
@@ -1,4 +0,0 @@
approvers:
- derekwaynecarr
- janetkuo
docs/admin/namespaces/namespace-dev.json
-10
View File
@@ -1,10 +0,0 @@
{
"kind": "Namespace",
"apiVersion": "v1",
"metadata": {
"name": "development",
"labels": {
"name": "development"
}
}
}
docs/admin/node-conformance.md
+3 -3
View File
@@ -48,7 +48,7 @@ other Kubelet flags you may care:
# $LOG_DIR is the test output path.
sudo docker run -it --rm --privileged --net=host \
-v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
gcr.io/google_containers/node-test:0.2
k8s.gcr.io/node-test:0.2
```
## Running Node Conformance Test for Other Architectures
@@ -71,7 +71,7 @@ regular expression of tests you want to run.
sudo docker run -it --rm --privileged --net=host \
-v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
-e FOCUS=MirrorPod \ # Only run MirrorPod test
gcr.io/google_containers/node-test:0.2
k8s.gcr.io/node-test:0.2
```
To skip specific tests, overwrite the environment variable `SKIP` with the
@@ -81,7 +81,7 @@ regular expression of tests you want to skip.
sudo docker run -it --rm --privileged --net=host \
-v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
-e SKIP=MirrorPod \ # Run all conformance tests but skip MirrorPod test
gcr.io/google_containers/node-test:0.2
k8s.gcr.io/node-test:0.2
```
Node conformance test is a containerized version of [node e2e test](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/devel/e2e-node-tests.md).
docs/api-reference/v1.9/index.html
+1 -1
View File
@@ -56950,7 +56950,7 @@ Appears In:
<tbody>
<tr>
<td>names <br /> <em>string array</em></td>
<td>Names by which this image is known. e.g. [&quot;gcr.io/google_containers/hyperkube:v1.0.7&quot;, &quot;dockerhub.io/google_containers/hyperkube:v1.0.7&quot;]</td>
<td>Names by which this image is known. e.g. [&quot;k8s.gcr.io/hyperkube:v1.0.7&quot;, &quot;dockerhub.io/google_containers/hyperkube:v1.0.7&quot;]</td>
</tr>
<tr>
<td>sizeBytes <br /> <em>integer</em></td>
docs/concepts/api-extension/custom-resources.md
+2 -2
View File
@@ -98,7 +98,7 @@ Kubernetes provides two ways to add custom resources to your cluster:
Kubernetes provides these two options to meet the needs of different users, so that neither ease of use nor flexibility are compromised.
Aggregated APIs are subordinate APIServers that sit behind the primary API server, which acts as a proxy. This arrangement is called [API Aggregation](docs/concepts/api-extension/apiserver-aggregation.md) (AA). To users, it simply appears that the Kubernetes API is extended.
Aggregated APIs are subordinate APIServers that sit behind the primary API server, which acts as a proxy. This arrangement is called [API Aggregation](/docs/concepts/api-extension/apiserver-aggregation/) (AA). To users, it simply appears that the Kubernetes API is extended.
Custom Resource Definitions (CRDS) allow users to create new types of resources without adding another APIserver. You do not need to understand API Aggregation to use CRDs.
@@ -112,7 +112,7 @@ This frees you from writing your own API server to handle the custom resource,
but the generic nature of the implementation means you have less flexibility than with
[API server aggregation](#api-server-aggregation).
Refer to the [Custom Controler example, which uses Custom Resources](https://github.com/kubernetes/sample-controller)
Refer to the [Custom Controller example, which uses Custom Resources](https://github.com/kubernetes/sample-controller)
for a demonstration of how to register a new custom resource, work with instances of your new resource type,
and setup a controller to handle events.
docs/concepts/architecture/cloud-controller.md
+2 -2
View File
@@ -97,7 +97,7 @@ The Node controller contains the cloud-dependent functionality of the kubelet. P
In this new model, the kubelet initializes a node without cloud-specific information. However, it adds a taint to the newly created node that makes the node unschedulable until the CCM initializes the node with cloud-specific information, and then removes this taint.
### 3. Kubernets API server
### 3. Kubernetes API server
The PersistentVolumeLabels controller moves the cloud-dependent functionality of the Kubernetes API server to the CCM as described in the preceding sections.
@@ -174,7 +174,7 @@ v1/ServiceAccount:
The RBAC ClusterRole for the CCM looks like this:
```yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cloud-controller-manager
docs/concepts/architecture/nodes.md
+1 -1
View File
@@ -265,7 +265,7 @@ metadata:
spec:
containers:
- name: sleep-forever
image: gcr.io/google_containers/pause:0.8.0
image: k8s.gcr.io/pause:0.8.0
resources:
requests:
cpu: 100m
docs/concepts/cluster-administration/addons.md
+3 -3
View File
@@ -17,10 +17,10 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply
* [Cilium](https://github.com/cilium/cilium) is a L3 network and network policy plugin that can enforce HTTP/API/L7 policies transparently. Both routing and overlay/encapsulation mode are supported.
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) enables Kubernetes to seamlessly connect to a choice of CNI plugins, such as Calico, Canal, Flannel, Romana, or Weave.
* [Contiv](http://contiv.github.io) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](http://github.com/contiv). The [installer](http://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options.
* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml) is an overlay network provider that can be used with Kubernetes.
* [Multus](https://github.com/Intel-Corp/multus-cni) is a Multi plugin for multiple network support in Kubernetes to support all CNI plugins (e.g. Calico, Cilium, Contiv, Flannel), in addition to SRIOV, DPDK, OVS-DPDK and VPP based workloads in Kubernetes.
* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) is an overlay network provider that can be used with Kubernetes.
* [Multus](https://github.com/Intel-Corp/multus-cni) is a Multi plugin for multiple network support in Kubernetes to support all CNI plugins (e.g. Calico, Cilium, Contiv, Flannel), in addition to SRIOV, DPDK, OVS-DPDK and VPP based workloads in Kubernetes.
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) provides integration between VMware NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and Openshift.
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) is an SDN platform that provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring.
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) is an SDN platform that provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring.
* [Romana](http://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize).
* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database.
docs/concepts/cluster-administration/controller-metrics.md
+2 -2
View File
@@ -13,10 +13,10 @@ the controller manager.
Controller manager metrics provide important insight into the performance and health of the controller manager.
These metrics include common Go language runtime metrics such as go_routine count and controller specific metrics such as
etcd request latencies or Cloudprovider (AWS, GCE, Openstack) API latencies that can be used
etcd request latencies or Cloudprovider (AWS, GCE, OpenStack) API latencies that can be used
to gauge the health of a cluster.
Starting from Kubernetes 1.7, detailed Cloudprovider metrics are available for storage operations for GCE, AWS, Vsphere and Openstack.
Starting from Kubernetes 1.7, detailed Cloudprovider metrics are available for storage operations for GCE, AWS, Vsphere and OpenStack.
These metrics can be used to monitor health of persistent volume operations.
For example, for GCE these metrics are called:
docs/concepts/cluster-administration/device-plugins.md
+39 -10
View File
@@ -34,7 +34,7 @@ During the registration, the device plugin needs to send:
* The name of its Unix socket.
* The Device Plugin API version against which it was built.
* The `ResourceName` it wants to advertise. Here `ResourceName` needs to follow the
[extended resource naming scheme](https://github.com/kubernetes/kubernetes/pull/48922)
[extended resource naming scheme](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
as `vendor-domain/resource`.
For example, an Nvidia GPU is advertised as `nvidia.com/gpu`.
@@ -45,12 +45,29 @@ For example, after a device plugin registers `vendor-domain/foo` with the kubele
and reports two healthy devices on a node, the node status is updated
to advertise 2 `vendor-domain/foo`.
Then, developers can request devices in a
Then, users can request devices in a
[Container](/docs/api-reference/{{page.version}}/#container-v1-core)
specification by using the same process that is used for
[opaque integer resources](/docs/concepts/configuration/manage-compute-resources-container/#opaque-integer-resources-alpha-feature).
In version 1.8, extended resources are supported only as integer resources and must have
`limit` equal to `request` in the Container specification.
specification as they request other types of resources, with the following limitations:
* Extended resources are only supported as integer resources and cannot be overcommitted.
* Devices cannot be shared among Containers.
Suppose a Kubernetes cluster is running a device plugin that advertises resource `vendor-domain/resource`
on certain nodes, here is an example user pod requesting this resource:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: demo-pod
spec:
containers:
-
name: demo-container-1
image: gcr.io/google_containers/pause:2.0
resources:
limits:
vendor-domain/resource: 2 # requesting 2 vendor-domain/resource
```
## Device plugin implementation
@@ -65,7 +82,7 @@ The general workflow of a device plugin includes the following steps:
```gRPC
service DevicePlugin {
// ListAndWatch returns a stream of List of Devices
// Whenever a Device state change or a Device disapears, ListAndWatch
// Whenever a Device state change or a Device disappears, ListAndWatch
// returns the new list
rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}
@@ -88,7 +105,7 @@ runtime configurations for accessing the allocated devices. The kubelet passes t
to the container runtime.
A device plugin is expected to detect kubelet restarts and re-register itself with the new
kubelet instance. In version 1.8, a new kubelet instance cleans up all the existing Unix sockets
kubelet instance. In the current implementation, a new kubelet instance deletes all the existing Unix sockets
under `/var/lib/kubelet/device-plugins` when it starts. A device plugin can monitor the deletion
of its Unix socket and re-register itself upon such an event.
@@ -105,10 +122,22 @@ must be mounted as a
in the plugin's
[PodSpec](/docs/api-reference/{{page.version}}/#podspec-v1-core).
Kubernetes device plugin support is still in alpha. As development continues, its API version can
change in incompatible ways. We recommend that device plugin developers do the following:
* Watch for changes in future releases.
* Support multiple versions of the device plugin API for backward/forward compatibility.
If you enable the DevicePlugins feature and run device plugins on nodes that need to be upgraded to
a Kubernetes release with a newer device plugin API version, upgrade your device plugins
to support both versions before upgrading these nodes to
ensure the continuous functioning of the device allocations during the upgrade.
## Examples
For an example device plugin implementation, see
[nvidia GPU device plugin for COS base OS](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu).
For examples of device plugin implementations, see:
* The official [NVIDIA GPU device plugin](https://github.com/NVIDIA/k8s-device-plugin)
* it requires using [nvidia-docker 2.0](https://github.com/NVIDIA/nvidia-docker) which allows you to run GPU enabled docker containers
* The [NVIDIA GPU device plugin for COS base OS](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu).
{% endcapture %}
docs/concepts/cluster-administration/logging.md
+1 -1
View File
@@ -216,7 +216,7 @@ by the kubelet.
As an example, you could use [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/),
which uses fluentd as a logging agent. Here are two configuration files that
you can use to implement this approach. The first file contains
a [ConfigMap](/docs/tasks/configure-pod-container/configmap/) to configure fluentd.
a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to configure fluentd.
{% include code.html language="yaml" file="fluentd-sidecar-config.yaml" ghlink="/docs/concepts/cluster-administration/fluentd-sidecar-config.yaml" %}
docs/concepts/cluster-administration/networking.md
+1 -1
View File
@@ -128,7 +128,7 @@ people have reported success with Flannel and Kubernetes.
### Google Compute Engine (GCE)
For the Google Compute Engine cluster configuration scripts, we use [advanced
routing](https://cloud.google.com/compute/docs/networking#routing) to
routing](https://cloud.google.com/vpc/docs/routes) to
assign each VM a subnet (default is `/24` - 254 IPs). Any traffic bound for that
subnet will be routed directly to the VM by the GCE network fabric. This is in
addition to the "main" IP address assigned to the VM, which is NAT'ed for
docs/concepts/cluster-administration/two-files-counter-pod-agent-sidecar.yaml
+1 -1
View File
@@ -22,7 +22,7 @@ spec:
- name: varlog
mountPath: /var/log
- name: count-agent
image: gcr.io/google_containers/fluentd-gcp:1.30
image: k8s.gcr.io/fluentd-gcp:1.30
env:
- name: FLUENTD_ARGS
value: -c /etc/fluentd-config/fluentd.conf
docs/concepts/configuration/assign-pod-node.md
+1 -1
View File
@@ -212,7 +212,7 @@ must be satisfied for the pod to schedule onto a node.
#### More Practical Use-cases
Interpod Affinity and AnitAffinity can be even more useful when they are used with higher
Interpod Affinity and AntiAffinity can be even more useful when they are used with higher
level collections such as ReplicaSets, Statefulsets, Deployments, etc. One can easily configure that a set of workloads should
be co-located in the same defined topology, eg., the same node.
docs/concepts/configuration/manage-compute-resources-container.md
+7 -5
View File
@@ -239,7 +239,7 @@ the node.
The amount of resources available to Pods is less than the node capacity, because
system daemons use a portion of the available resources. The `allocatable` field
[NodeStatus](/docs/resources-reference/{{page.version}}/#nodestatus-v1-core)
[NodeStatus](/docs/api-reference/{{page.version}}/#nodestatus-v1-core)
gives the amount of resources that are available to Pods. For more information, see
[Node Allocatable Resources](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md).
@@ -285,7 +285,7 @@ Conditions:
Events:
FirstSeen LastSeen Count From SubobjectPath Reason Message
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {scheduler } scheduled Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "gcr.io/google_containers/pause:0.8.0" already present on machine
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "k8s.gcr.io/pause:0.8.0" already present on machine
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD created Created with docker id 6a41280f516d
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD started Started with docker id 6a41280f516d
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} spec.containers{simmemleak} created Created with docker id 87348f12526a
@@ -312,7 +312,7 @@ Kubernetes version 1.8 introduces a new resource, _ephemeral-storage_ for managi
This partition is “ephemeral” and applications cannot expect any performance SLAs (Disk IOPS for example) from this partition. Local ephemeral storage management only applies for the root partition; the optional partition for image layer and writable layer is out of scope.
**Note:** If an optional runntime partition is used, root partition will not hold any image layer or writable layers.
**Note:** If an optional runtime partition is used, root partition will not hold any image layer or writable layers.
{: .note}
### Requests and limits setting for local ephemeral storage
@@ -507,7 +507,7 @@ JSON-Pointer. For more details, see
{: .note}
To consume an Extended Resource in a Pod, include the resource name as a key
in the `spec.containers[].resources.requests` map.
in the `spec.containers[].resources.limits` map in the container spec.
**Note:** Extended resources cannot be overcommitted, so request and limit
must be equal if both are present in a container spec.
@@ -535,6 +535,8 @@ spec:
requests:
cpu: 2
example.com/foo: 1
limits:
example.com/foo: 1
```
## Planned Improvements
@@ -570,7 +572,7 @@ consistency across providers and platforms.
* [Container](/docs/api-reference/{{page.version}}/#container-v1-core)
* [ResourceRequirements](/docs/resources-reference/{{page.version}}/#resourcerequirements-v1-core)
* [ResourceRequirements](/docs/api-reference/{{page.version}}/#resourcerequirements-v1-core)
{% endcapture %}
docs/concepts/configuration/pod-priority-preemption.md
+25 -38
View File
@@ -12,19 +12,15 @@ title: Pod Priority and Preemption
[Pods](/docs/user-guide/pods) in Kubernetes 1.8 and later can have priority. Priority
indicates the importance of a Pod relative to other Pods. When a Pod cannot be scheduled,
the scheduler tries to preempt (evict) lower priority Pods to make scheduling of the
pending Pod possible. In a future Kubernetes release, priority will also affect
out-of-resource eviction ordering on the Node.
**Note:** Preemption does not respect PodDisruptionBudget; see
[the limitations section](#poddisruptionbudget-is-not-supported) for more details.
{: .note}
pending Pod possible. In Kubernetes 1.9 and later, Priority also affects scheduling
order of pods and out-of-resource eviction ordering on the Node.
{% endcapture %}
{% capture body %}
## How to use priority and preemption
To use priority and preemption in Kubernetes 1.8, follow these steps:
To use priority and preemption in Kubernetes 1.8 and later, follow these steps:
1. Enable the feature.
@@ -135,6 +131,15 @@ spec:
priorityClassName: high-priority
```
### Effect of Pod priority on scheduling order
In Kubernetes 1.9 and later, when Pod priority is enabled, scheduler orders pending
pods by their priority and a pending Pod is placed ahead of other pending Pods with
lower priority in the scheduling queue. As a result, the higher priority pod may
by scheduled sooner that pods with lower priority if its scheduling requirements
are met. If such pod cannot be scheduled, scheduler will continue and tries to
schedule other lower priority Pods.
## Preemption
When Pods are created, they go to a queue and wait to be scheduled. The scheduler
@@ -145,9 +150,9 @@ where removal of one or more Pods with lower priority than P would enable P to b
on that Node. If such a Node is found, one or more lower priority Pods get
deleted from the Node. After the Pods are gone, P can be scheduled on the Node.
### Limitations of preemption (alpha version)
### Limitations of preemption
#### Starvation of preempting Pod
#### Graceful termination of preemption victims
When Pods are preempted, the victims get their
[graceful termination period](https://kubernetes.io/docs/concepts/workloads/pods/pod/#termination-of-pods).
@@ -156,33 +161,24 @@ killed. This graceful termination period creates a time gap between the point
that the scheduler preempts Pods and the time when the pending Pod (P) can be
scheduled on the Node (N). In the meantime, the scheduler keeps scheduling other
pending Pods. As victims exit or get terminated, the scheduler tries to schedule
Pods in the pending queue, and one or more of them may be considered and
scheduled to N before the scheduler considers scheduling P on N. In such a case,
it is likely that when all the victims exit, Pod P won't fit on Node N anymore.
So, scheduler will have to preempt other Pods on Node N or another Node so that
P can be scheduled. This scenario might be repeated again for the second and
subsequent rounds of preemption, and P might not get scheduled for a while.
This scenario can cause problems in various clusters, but is particularly
problematic in clusters with a high Pod creation rate.
Pods in the pending queue. Therefore, there is usually a time gap between the point
that scheduler preempts victims and the time that Pod P is scheduled. In order to
minimize this gap, one can set graceful termination period of lower priority pods
to zero or a small number.
We will address this problem in the beta version of Pod preemption. The solution
we plan to implement is
[provided here](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-preemption.md#preemption-mechanics).
#### PodDisruptionBudget is not supported
#### PodDisruptionBudget is supported, but not guaranteed!
A [Pod Disruption Budget (PDB)](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/)
allows application owners to limit the number Pods of a replicated application that
are down simultaneously from voluntary disruptions. However, the alpha version of
preemption does not respect PDB when choosing preemption victims.
We plan to add PDB support in beta, but even in beta, respecting PDB will be best
effort. The Scheduler will try to find victims whose PDB won't be violated by preemption,
but if no such victims are found, preemption will still happen, and lower priority Pods
will be removed despite their PDBs being violated.
are down simultaneously from voluntary disruptions. Kubernetes 1.9 supports PDB
when preempting pods, but respecting PDB is best effort. The Scheduler tries to
find victims whose PDB are not violated by preemption, but if no such victims are
found, preemption will still happen, and lower priority Pods will be removed
despite their PDBs being violated.
#### Inter-Pod affinity on lower-priority Pods
In version 1.8, a Node is considered for preemption only when
A Node is considered for preemption only when
the answer to this question is yes: "If all the Pods with lower priority than
the pending Pod are removed from the Node, can the pending pod be scheduled on
the Node?"
@@ -200,15 +196,6 @@ lower-priority Pods. In this case, the scheduler does not preempt any Pods on th
Node. Instead, it looks for another Node. The scheduler might find a suitable Node
or it might not. There is no guarantee that the pending Pod can be scheduled.
We might address this issue in future versions, but we don't have a clear plan yet.
We will not consider it a blocker for Beta or GA. Part
of the reason is that finding the set of lower-priority Pods that satisfy all
inter-Pod affinity rules is computationally expensive, and adds substantial
complexity to the preemption logic. Besides, even if preemption keeps the lower-priority
Pods to satisfy inter-Pod affinity, the lower priority Pods might be preempted
later by other Pods, which removes the benefits of having the complex logic of
respecting inter-Pod affinity.
Our recommended solution for this problem is to create inter-Pod affinity only towards
equal or higher priority pods.
docs/concepts/configuration/pod-with-node-affinity.yaml
+1 -1
View File
@@ -23,4 +23,4 @@ spec:
- another-node-label-value
containers:
- name: with-node-affinity
image: gcr.io/google_containers/pause:2.0
image: k8s.gcr.io/pause:2.0
docs/concepts/configuration/pod-with-pod-affinity.yaml
+1 -1
View File
@@ -26,4 +26,4 @@ spec:
topologyKey: kubernetes.io/hostname
containers:
- name: with-pod-affinity
image: gcr.io/google_containers/pause:2.0
image: k8s.gcr.io/pause:2.0
docs/concepts/configuration/secret.md
+3 -3
View File
@@ -399,10 +399,10 @@ You can manually create an imagePullSecret, and reference it from
a serviceAccount. Any pods created with that serviceAccount
or that default to use that serviceAccount, will get their imagePullSecret
field set to that of the service account.
See [Adding ImagePullSecrets to a service account](/docs/tasks/configure-pod-container/configure-service-account/#adding-imagepullsecrets-to-a-service-account)
See [Add ImagePullSecrets to a service account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)
for a detailed explanation of that process.
#### Automatic Mounting of Manually Created Secrets
### Automatic Mounting of Manually Created Secrets
Manually created secrets (e.g. one containing a token for accessing a github account)
can be automatically attached to pods based on their service account.
@@ -618,7 +618,7 @@ spec:
secretName: dotfile-secret
containers:
- name: dotfile-test-container
image: gcr.io/google_containers/busybox
image: k8s.gcr.io/busybox
command:
- ls
- "-l"
docs/concepts/configuration/taint-and-toleration.md
+1 -1
View File
@@ -171,7 +171,7 @@ the special nodes and hence the admission controller should add the toleration.
To ensure that the pods that need
the special hardware *only* schedule onto the nodes that have the special hardware, you will need some
additional mechanism, e.g. you could represent the special resource using
[opaque integer resources](/docs/concepts/configuration/manage-compute-resources-container/#opaque-integer-resources-alpha-feature)
[extended resources](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
and request it as a resource in the PodSpec, or you could label the nodes that have
the special hardware and use node affinity on the pods that need the hardware.
docs/concepts/containers/images.md
+1
View File
@@ -291,6 +291,7 @@ This needs to be done for each pod that is using a private registry.
However, setting of this field can be automated by setting the imagePullSecrets
in a [serviceAccount](/docs/user-guide/service-accounts) resource.
Check [Add ImagePullSecrets to a Service Account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) for detailed instructions.
You can use this in conjunction with a per-node `.docker/config.json`. The credentials
will be merged. This approach will work on Google Kubernetes Engine.
docs/concepts/overview/components.md
+2 -2
View File
@@ -58,8 +58,8 @@ The following controllers have cloud provider dependencies:
### kube-scheduler
[kube-scheduler](/docs/admin/kube-scheduler/) watches newly created pods that have no node assigned, and
selects a node for them to run on.
[kube-scheduler](/docs/admin/kube-scheduler/) watches newly created pods that
are not assigned to any node, and selects a node for them to run on.
### addons
docs/concepts/overview/working-with-objects/kubernetes-objects.md
+4
View File
@@ -57,6 +57,10 @@ In the `.yaml` file for the Kubernetes object you want to create, you'll need to
* `metadata` - Data that helps uniquely identify the object, including a `name` string, UID, and optional `namespace`
You'll also need to provide the object `spec` field. The precise format of the object `spec` is different for every Kubernetes object, and contains nested fields specific to that object. The [Kubernetes API reference](/docs/concepts/overview/kubernetes-api/) can help you find the spec format for all of the objects you can create using Kubernetes.
For example, the `spec` format for a `Pod` object can be found
[here](/docs/reference/generated/kubernetes-api/{{page.version}}/#podspec-v1-core),
and the `spec` format for a `Deployment` object can be found
[here](/docs/reference/generated/kubernetes-api/{{page.version}}/#deploymentspec-v1-apps).
{% endcapture %}
docs/concepts/overview/working-with-objects/labels.md
+19
View File
@@ -73,6 +73,25 @@ The former selects all resources with key equal to `environment` and value equal
The latter selects all resources with key equal to `tier` and value distinct from `frontend`, and all resources with no labels with the `tier` key.
One could filter for resources in `production` excluding `frontend` using the comma operator: `environment=production,tier!=frontend`
One usage scenario for equality-based label requirement is for Pods to specify
node selection criteria. For example, the sample Pod below selects nodes with
the label "`accelerator=nvidia-tesla-p100`".
```yaml
apiVersion: v1
kind: Pod
metadata:
name: cuda-test
spec:
containers:
- name: cuda-test
image: "k8s.gcr.io/cuda-vector-add:v0.1"
resources:
limits:
nvidia.com/gpu: 1
nodeSelector:
accelerator: nvidia-tesla-p100
```
### _Set-based_ requirement
docs/concepts/policy/pod-security-policy.md
+487 -250
View File
@@ -1,71 +1,492 @@
---
approvers:
- pweil-
- tallclair
title: Pod Security Policies
---
Objects of type `PodSecurityPolicy` govern the ability
to make requests on a pod that affect the `SecurityContext` that will be
applied to a pod and container.
{% include feature-state-beta.md %}
See [PodSecurityPolicy proposal](https://git.k8s.io/community/contributors/design-proposals/auth/pod-security-policy.md) for more information.
Pod Security Policies enable fine-grained authorization of pod creation and
updates.
* TOC
{:toc}
## What is a Pod Security Policy?
A _Pod Security Policy_ is a cluster-level resource that controls the
actions that a pod can perform and what it has the ability to access. The
`PodSecurityPolicy` objects define a set of conditions that a pod must
run with in order to be accepted into the system. They allow an
A _Pod Security Policy_ is a cluster-level resource that controls security
sensitive aspects of the pod specification. The `PodSecurityPolicy` objects
define a set of conditions that a pod must run with in order to be accepted into
the system, as well as defaults for the related fields. They allow an
administrator to control the following:
| Control Aspect | Field Name |
| ---------------------------------------------------------------------- | ------------------------------------------- |
| Running of privileged containers | `privileged` |
| Default set of capabilities that will be added to a container | `defaultAddCapabilities` |
| Capabilities that will be dropped from a container | `requiredDropCapabilities` |
| Capabilities a container can request to be added | `allowedCapabilities` |
| Controlling the usage of volume types | [`volumes`](#controlling-volumes) |
| The use of host networking | [`hostNetwork`](#host-network) |
| The use of host ports | `hostPorts` |
| The use of host's PID namespace | `hostPID` |
| The use of host's IPC namespace | `hostIPC` |
| The SELinux context of the container | [`seLinux`](#selinux) |
| The user ID | [`runAsUser`](#runasuser) |
| Configuring allowable supplemental groups | [`supplementalGroups`](#supplementalgroups) |
| Allocating an FSGroup that owns the pod's volumes | [`fsGroup`](#fsgroup) |
| Requiring the use of a read only root file system | `readOnlyRootFilesystem` |
| Running of a container that allow privilege escalation from its parent | [`allowPrivilegeEscalation`](#allowprivilegeescalation) |
| Control whether a process can gain more privileges than its parent process | [`defaultAllowPrivilegeEscalation`](#defaultallowprivilegeescalation) |
| Whitelist of allowed host paths | [`allowedHostPaths`](#allowedhostpaths) |
| Whitelist of the flex volume drivers | [`allowedFlexVolumes`](#allowedflexvolumes) |
_Pod Security Policies_ are comprised of settings and strategies that
control the security features a pod has access to. These settings fall
into three categories:
- *Controlled by a Boolean*: Fields of this type default to the most
restrictive value.
- *Controlled by an allowable set*: Fields of this type are checked
against the set to ensure their values are allowed.
- *Controlled by a strategy*: Items that have a strategy to provide
a mechanism to generate the value and a mechanism to ensure that a
specified value falls into the set of allowable values.
| Control Aspect | Field Names |
| ----------------------------------------------------| ------------------------------------------- |
| Running of privileged containers | `privileged` |
| Usage of the root namespaces | [`hostPID`, `hostIPC`](#host-namespaces) |
| Usage of host networking and ports | [`hostNetwork`, `hostPorts`](#host-namespaces) |
| Usage of volume types | [`volumes`](#volumes-and-file-systems) |
| Usage of the host filesystem | [`allowedHostPaths`](#volumes-and-file-systems) |
| Allocating an FSGroup that owns the pod's volumes | [`fsGroup`](#volumes-and-file-systems) |
| Requiring the use of a read only root file system | [`readOnlyRootFilesystem`](#volumes-and-file-systems) |
| The user and group IDs of the container | [`runAsUser`, `supplementalGroups`](#users-and-groups) |
| Restricting escalation to root privileges | [`allowPrivilegeEscalation`, `defaultAllowPrivilegeEscalation`](#privilege-escalation) |
| Linux capabilities | [`defaultAddCapabilities`, `requiredDropCapabilities`, `allowedCapabilities`](#capabilities) |
| The SELinux context of the container | [`seLinux`](#selinux) |
| The AppArmor profile used by containers | [annotations](#apparmor) |
| The seccomp profile used by containers | [annotations](#seccomp) |
## Strategies
## Enabling Pod Security Policies
### RunAsUser
Pod security policy control is implemented as an optional (but recommended)
[admission
controller](/docs/admin/admission-controllers/#podsecuritypolicy). PodSecurityPolicies
are enforced by [enabling the admission
controller](/docs/admin/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in),
but doing so without authorizing any policies **will prevent any pods from being
created** in the cluster.
- *MustRunAs* - Requires a `range` to be configured. Uses the first value
of the range as the default. Validates against the configured range.
Since the pod security policy API (`extensions/v1beta1/podsecuritypolicy`) is
enabled independently of the admission controller, for existing clusters it is
recommended that policies are added and authorized before enabling the admission
controller.
## Authorizing Policies
When a PodSecurityPolicy resource is created, it does nothing. In order to use
it, the requesting user or target pod's [service
account](/docs/tasks/configure-pod-container/configure-service-account/) must be
authorized to use the policy, by allowing the `use` verb on the policy.
Most Kubernetes pods are not created directly by users. Instead, they are
typically created indirectly as part of a
[Deployment](/docs/concepts/workloads/controllers/deployment/),
[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/), or other
templated controller via the controller manager. Granting the controller access
to the policy would grant access for *all* pods created by that the controller,
so the preferred method for authorizing policies is to grant access to the
pod's service account (see [example](#run-another-pod)).
### Via RBAC
[RBAC](/docs/admin/authorization/rbac/) is a standard Kubernetes authorization
mode, and can easily be used to authorize use of policies.
First, a `Role` or `ClusterRole` needs to grant access to `use` the desired
policies. The rules to grant access look like this:
```yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: <role name>
rules:
- apiGroups: ['extensions']
resources: ['podsecuritypolicies']
verbs: ['use']
resourceNames:
- <list of policies to authorize>
```
Then the `(Cluster)Role` is bound to the authorized user(s):
```yaml
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: <binding name>
roleRef:
kind: ClusterRole
name: <role name>
apiGroup: rbac.authorization.k8s.io
subjects:
# Authorize specific service accounts:
- kind: ServiceAccount
name: <authorized service account name>
namespace: <authorized pod namespace>
# Authorize specific users (not recommended):
- kind: User
apiGroup: rbac.authorization.k8s.io
name: <authorized user name>
```
If a `RoleBinding` (not a `ClusterRoleBinding`) is used, it will only grant
usage for pods being run in the same namespace as the binding. This can be
paired with system groups to grant access to all pods run in the namespace:
```yaml
# Authorize all service accounts in a namespace:
- kind: Group
apiGroup: rbac.authorization.k8s.io
name: system:serviceaccounts
# Or equivalently, all authenticated users in a namespace:
- kind: Group
apiGroup: rbac.authorization.k8s.io
name: system:authenticated
```
For more examples of RBAC bindings, see [Role Binding
Examples](/docs/admin/authorization/rbac#role-binding-examples). For a complete
example of authorizing a PodSecurityPolicy, see
[below](#example).
### Troubleshooting
- The [Controller Manager](/docs/admin/kube-controller-manager/) must be run
against [the secured API port](/docs/admin/accessing-the-api/), and must not
have superuser permissions. Otherwise requests would bypass authentication and
authorization modules, all PodSecurityPolicy objects would be allowed, and users
would be able to create privileged containers. For more details on configuring
Controller Manager authorization, see [Controller
Roles](docs/admin/authorization/rbac/#controller-roles).
## Policy Order
In addition to restricting pod creation and update, pod security policies can
also be used to provide default values for many of the fields that it
controls. When multiple policies are available, the pod security policy
controller selects policies in the following order:
1. If any policies successfully validate the pod without altering it, they are
used.
2. Otherwise, the first valid policy in alphabetical order is used.
## Example
_This example assumes you have a running cluster with the PodSecurityPolicy
admission controller enabled and you have cluster admin privileges._
### Set up
Set up a namespace and a service account to act as for this example. We'll use
this service account to mock a non-admin user.
```shell
$ kubectl create namespace psp-example
$ kubectl create serviceaccount -n psp-example fake-user
$ kubectl create rolebinding -n psp-example fake-editor --clusterrole=edit --serviceaccount=psp-example:fake-user
```
To make it clear which user we're acting as and save some typing, create 2
aliases:
```shell
$ alias kubectl-admin='kubectl -n psp-example'
$ alias kubectl-user='kubectl --as=system:serviceaccount:psp-example:fake-user -n psp-example'
```
### Create a policy and a pod
Define the example PodSecurityPolicy object in a file. This is a policy that
simply prevents the creation of privileged pods.
{% include code.html language="yaml" file="example-psp.yaml" ghlink="/docs/concepts/policy/example-psp.yaml" %}
And create it with kubectl:
```shell
$ kubectl-admin create -f example-psp.yaml
```
Now, as the unprivileged user, try to create a simple pod:
```shell
$ kubectl-user create -f- <<EOF
apiVersion: v1
kind: Pod
metadata:
name: pause
spec:
containers:
- name: pause
image: gcr.io/google-containers/pause
EOF
Error from server (Forbidden): error when creating "STDIN": pods "pause" is forbidden: unable to validate against any pod security policy: []
```
**What happened?** Although the PodSecurityPolicy was created, neither the
pod's service account nor `fake-user` have permission to use the new policy:
```shell
$ kubectl-user auth can-i use podsecuritypolicy/example
no
```
Create the rolebinding to grant `fake-user` the `use` verb on the example
policy:
_Note: This is not the recommended way! See the [next section](#run-another-pod)
for the preferred approach._
```shell
$ kubectl-admin create role psp:unprivileged \
--verb=use \
--resource=podsecuritypolicy \
--resource-name=example
role "psp:unprivileged" created
$ kubectl-admin create rolebinding fake-user:psp:unprivileged \
--role=psp:unprivileged \
--serviceaccount=psp-example:fake-user
rolebinding "fake-user:psp:unprivileged" created
$ kubectl-user auth can-i use podsecuritypolicy/example
yes
```
Now retry creating the pod:
```shell
$ kubectl-user create -f- <<EOF
apiVersion: v1
kind: Pod
metadata:
name: pause
spec:
containers:
- name: pause
image: gcr.io/google-containers/pause
EOF
pod "pause" created
```
It works as expected! But any attempts to create a privileged pod should still
be denied:
```shell
$ kubectl-user create -f- <<EOF
apiVersion: v1
kind: Pod
metadata:
name: privileged
spec:
containers:
- name: pause
image: gcr.io/google-containers/pause
securityContext:
privileged: true
EOF
Error from server (Forbidden): error when creating "STDIN": pods "privileged" is forbidden: unable to validate against any pod security policy: [spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed]
```
Delete the pod before moving on:
```shell
$ kubectl-user delete pause
```
### Run another pod
Let's try that again, slightly differently:
```shell
$ kubectl-user run pause --image=gcr.io/google-containers/pause
deployment "pause" created
$ kubectl-user get pods
No resources found.
$ kubectl-user get events | head -n 2
LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE
1m 2m 15 pause-7774d79b5 ReplicaSet Warning FailedCreate replicaset-controller Error creating: pods "pause-7774d79b5-" is forbidden: no providers available to validate pod request
```
**What happened?** We already bound the `psp:unprivileged` role for our `fake-user`,
why are we getting the error `Error creating: pods "pause-7774d79b5-" is
forbidden: no providers available to validate pod request`? The answer lies in
the source - `replicaset-controller`. Fake-user successfully created the
deployment (which successfully created a replicaset), but when the replicaset
went to create the pod it was not authorized to use the example
podsecuritypolicy.
In order to fix this, bind the `psp:unprivileged` role to the pod's service
account instead. In this case (since we didn't specify it) the service account
is `default`:
```shell
$ kubectl-admin create rolebinding default:psp:unprivileged \
--role=psp:unprivileged \
--serviceaccount=psp-example:default
rolebinding "default:psp:unprivileged" created
```
Now if you give it a minute to retry, the replicaset-controller should
eventually succeed in creating the pod:
```shell
$ kubectl-user get pods --watch
NAME READY STATUS RESTARTS AGE
pause-7774d79b5-qrgcb 0/1 Pending 0 1s
pause-7774d79b5-qrgcb 0/1 Pending 0 1s
pause-7774d79b5-qrgcb 0/1 ContainerCreating 0 1s
pause-7774d79b5-qrgcb 1/1 Running 0 2s
^C
```
### Clean up
Delete the namespace to clean up most of the example resources:
```shell
$ kubectl-admin delete ns psp-example
namespace "psp-example" deleted
```
Note that `PodSecurityPolicy` resources are not namespaced, and must be cleaned
up separately:
```shell
$ kubectl-admin delete psp example
podsecuritypolicy "example" deleted
```
### Example Policies
This is the least restricted policy you can create, equivalent to not using the
pod security policy admission controller:
{% include code.html language="yaml" file="privileged-psp.yaml" ghlink="/docs/concepts/policy/privileged-psp.yaml" %}
This is an example of a restrictive policy that requires users to run as an
unprivileged user, blocks possible escalations to root, and requires use of
several security mechanisms.
{% include code.html language="yaml" file="restricted-psp.yaml" ghlink="/docs/concepts/policy/restricted-psp.yaml" %}
## Policy Reference
### Host namespaces
**HostPID** - Controls whether the pod containers can share the host process ID
namespace. Note that when paired with ptrace this can be used to escalate
privileges outside of the container (ptrace is forbidden by default).
**HostIPC** - Controls whether the pod containers can share the host IPC
namespace.
**HostNetwork** - Controls whether the pod may use the node network
namespace. Doing so gives the pod access to the loopback device, services
listening on localhost, and could be used to snoop on network activity of other
pods on the same node.
**HostPorts** - Provides a whitelist of ranges of allowable ports in the host
network namespace. Defined as a list of `HostPortRange`, with `min`(inclusive)
and `max`(inclusive). Defaults to no allowed host ports.
**AllowedHostPaths** - See [Volumes and file systems](#volumes-and-file-systems).
### Volumes and file systems
**Volumes** - Provides a whitelist of allowed volume types. The allowable values
correspond to the volume sources that are defined when creating a volume. For
the complete list of volume types, see [Types of
Volumes](/docs/concepts/storage/volumes/#types-of-volumes). Additionally, `*`
may be used to allow all volume types.
The **recommended minimum set** of allowed volumes for new PSPs are:
- configMap
- downwardAPI
- emptyDir
- persistentVolumeClaim
- secret
- projected
**FSGroup** - Controls the supplemental group applied to some volumes.
- *MustRunAs* - Requires at least one `range` to be specified. Uses the
minimum value of the first range as the default. Validates against all ranges.
- *RunAsAny* - No default provided. Allows any `fsGroup` ID to be specified.
**AllowedHostPaths** - This specifies a whitelist of host paths that are allowed
to be used by hostPath volumes. An empty list means there is no restriction on
host paths used. This is defined as a list of objects with a single `pathPrefix`
field, which allows hostPath volumes to mount a path that begins with an
allowed prefix. For example:
```yaml
allowedHostPaths:
# This allows "/foo", "/foo/", "/foo/bar" etc., but
# disallows "/fool", "/etc/foo" etc.
# "/foo/../" is never valid.
- pathPrefix: "/foo"
```
_Note: There are many ways a container with unrestricted access to the host
filesystem can escalate privileges, including reading data from other
containers, and abusing the credentials of system services, such as Kubelet._
**ReadOnlyRootFilesystem** - Requires that containers must run with a read-only
root filesystem (i.e. no writeable layer).
### Users and groups
**RunAsUser** - Controls the what user ID containers run as.
- *MustRunAs* - Requires at least one `range` to be specified. Uses the
minimum value of the first range as the default. Validates against all ranges.
- *MustRunAsNonRoot* - Requires that the pod be submitted with a non-zero
`runAsUser` or have the `USER` directive defined in the image. No default
provided.
`runAsUser` or have the `USER` directive defined (using a numeric UID) in the
image. No default provided. Setting `allowPrivilegeEscalation=false` is strongly
recommended with this strategy.
- *RunAsAny* - No default provided. Allows any `runAsUser` to be specified.
**SupplementalGroups** - Controls which group IDs containers add.
- *MustRunAs* - Requires at least one `range` to be specified. Uses the
minimum value of the first range as the default. Validates against all ranges.
- *RunAsAny* - No default provided. Allows any `supplementalGroups` to be
specified.
### Privilege Escalation
These options control the `allowPrivilegeEscalation` container option. This bool
directly controls whether the
[`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt)
flag gets set on the container process. This flag will prevent `setuid` binaries
from changing the effective user ID, and prevent files from enabling extra
capabilities (e.g. it will prevent the use of the `ping` tool). This behavior is
required to effectively enforce `MustRunAsNonRoot`.
It defaults to `nil`. The default behavior of `nil` allows privilege escalation
so as to not break setuid binaries. Setting it to `false` ensures that no child
process of a container can gain more privileges than its parent.
**AllowPrivilegeEscalation** - Gates whether or not a user is allowed to set the
security context of a container to `allowPrivilegeEscalation=true`. This
defaults to allowed. When set to false, the container's
`allowPrivilegeEscalation` is defaulted to false.
**DefaultAllowPrivilegeEscalation** - Sets the default for the
`allowPrivilegeEscalation` option. The default behavior without this is to allow
privilege escalation so as to not break setuid binaries. If that behavior is not
desired, this field can be used to default to disallow, while still permitting
pods to request `allowPrivilegeEscalation` explicitly.
### Capabilities
Linux capabilities provide a finer grained breakdown of the privileges
traditionally associated with the superuser. Some of these capabilities can be
used to escalate privileges or for container breakout, and may be restricted by
the PodSecurityPolicy. For more details on Linux capabilities, see
[capabilities(7)](http://man7.org/linux/man-pages/man7/capabilities.7.html).
The following fields take a list of capabilities, specified as the capability
name in ALL_CAPS without the `CAP_` prefix.
**AllowedCapabilities** - Provides a whitelist of capabilities that may be added
to a container. The default set of capabilities are implicitly allowed. The
empty set means that no additional capabilities may be added beyond the default
set. `*` can be used to allow all capabilities.
**RequiredDropCapabilities** - The capabilities which must be dropped from
containers. These capabilities are removed from the default set, and must not be
added. Capabilities listed in `RequiredDropCapabilities` must not be included in
`AllowedCapabilities` or `DefaultAddCapabilities`.
**DefaultAddCapabilities** - The capabilities which are added to containers by
default, in addition to the runtime defaults. See the [Docker
documentation](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)
for the default list of capabilities when using the Docker runtime.
### SELinux
- *MustRunAs* - Requires `seLinuxOptions` to be configured if not using
@@ -74,213 +495,29 @@ pre-allocated values. Uses `seLinuxOptions` as the default. Validates against
- *RunAsAny* - No default provided. Allows any `seLinuxOptions` to be
specified.
### SupplementalGroups
### AppArmor
- *MustRunAs* - Requires at least one range to be specified. Uses the
minimum value of the first range as the default. Validates against all ranges.
- *RunAsAny* - No default provided. Allows any `supplementalGroups` to be
specified.
Controlled via annotations on the PodSecurityPolicy. Refer to the [AppArmor
documentation](/docs/tutorials/clusters/apparmor/#podsecuritypolicy-annotations).
### FSGroup
### Seccomp
- *MustRunAs* - Requires at least one range to be specified. Uses the
minimum value of the first range as the default. Validates against the
first ID in the first range.
- *RunAsAny* - No default provided. Allows any `fsGroup` ID to be specified.
The use of seccomp profiles in pods can be controlled via annotations on the
PodSecurityPolicy. Seccomp is an alpha feature in Kubernetes.
### Controlling Volumes
**seccomp.security.alpha.kubernetes.io/defaultProfileName** - Annotation that
specifies the default seccomp profile to apply to containers. Possible values
are:
The usage of specific volume types can be controlled by setting the
volumes field of the PSP. The allowable values of this field correspond
to the volume sources that are defined when creating a volume:
- `unconfined` - Seccomp is not applied to the container processes (this is the
default in Kubernetes), if no alternative is provided.
- `docker/default` - The Docker default seccomp profile is used.
- `localhost/<path>` - Specify a profile as a file on the node located at
`<seccomp_root>/<path>`, where `<seccomp_root>` is defined via the
`--seccomp-profile-root` flag on the Kubelet.
1. azureFile
1. azureDisk
1. flocker
1. flexVolume
1. hostPath
1. emptyDir
1. gcePersistentDisk
1. awsElasticBlockStore
1. gitRepo
1. secret
1. nfs
1. iscsi
1. glusterfs
1. persistentVolumeClaim
1. rbd
1. cinder
1. cephFS
1. downwardAPI
1. fc
1. configMap
1. vsphereVolume
1. quobyte
1. photonPersistentDisk
1. projected
1. portworxVolume
1. scaleIO
1. storageos
1. \* (allow all volumes)
The recommended minimum set of allowed volumes for new PSPs are
configMap, downwardAPI, emptyDir, persistentVolumeClaim, secret, and projected.
### Host Network
- *HostPorts*, default `empty`. List of `HostPortRange`, defined by `min`(inclusive) and `max`(inclusive), which define the allowed host ports.
### AllowPrivilegeEscalation
Gates whether or not a user is allowed to set the security context of a container
to `allowPrivilegeEscalation=true`. This field defaults to `false`.
### DefaultAllowPrivilegeEscalation
Sets the default for the security context `AllowPrivilegeEscalation` of a container.
This bool directly controls whether the `no_new_privs` flag gets set on the
container process. It defaults to `nil`. The default behavior of `nil`
allows privilege escalation so as to not break setuid binaries. Setting it to `false`
ensures that no child process of a container can gain more privileges than
its parent.
### AllowedHostPaths
This specifies a whitelist of host paths that are allowed to be used by Pods.
An empty list means there is no restriction on host paths used.
Each item in the list must specify a string value named `pathPrefix` that
defines a host path to match. The value cannot be "`*`" though.
An example is shown below:
```yaml
apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
name: custom-paths
spec:
allowedHostPaths:
# This allows "/foo", "/foo/", "/foo/bar" etc., but
# disallows "/fool", "/etc/foo" etc.
- pathPrefix: "/foo"
```
### AllowedFlexVolumes
This specifies a whitelist of flex volume drivers that are allowed
to be used by flexVolume. An empty list means there is no restriction on the drivers. Please
make sure `volumes` contains the `flexVolume` volume type, no flex volume driver is allowed
otherwise. For example:
```yaml
apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
name: allow-flex-volumes
spec:
volumes:
- flexVolume
allowedFlexVolumes:
- driver: example/lvm
- driver: example/cifs
```
## Admission
[_Admission control_ with `PodSecurityPolicy`](/docs/admin/admission-controllers/#podsecuritypolicy)
allows for control over the creation and modification of resources based on the
capabilities allowed in the cluster.
Admission uses the following approach to create the final security context for
the pod:
1. Retrieve all PSPs available for use.
1. Generate field values for security context settings that were not specified
on the request.
1. Validate the final settings against the available policies.
If a matching policy is found, then the pod is accepted. If the
request cannot be matched to a PSP, the pod is rejected.
A pod must validate every field against the PSP.
## Creating a Pod Security Policy
Here is an example Pod Security Policy. It has permissive settings for
all fields
{% include code.html language="yaml" file="psp.yaml" ghlink="/docs/concepts/policy/psp.yaml" %}
Create the policy by downloading the example file and then running this command:
```shell
$ kubectl create -f ./psp.yaml
podsecuritypolicy "permissive" created
```
## Getting a list of Pod Security Policies
To get a list of existing policies, use `kubectl get`:
```shell
$ kubectl get psp
NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP READONLYROOTFS VOLUMES
permissive false [] RunAsAny RunAsAny RunAsAny RunAsAny false [*]
privileged true [] RunAsAny RunAsAny RunAsAny RunAsAny false [*]
restricted false [] RunAsAny MustRunAsNonRoot RunAsAny RunAsAny false [emptyDir secret downwardAPI configMap persistentVolumeClaim projected]
```
## Editing a Pod Security Policy
To modify policy interactively, use `kubectl edit`:
```shell
$ kubectl edit psp permissive
```
This command will open a default text editor where you will be able to modify policy.
## Deleting a Pod Security Policy
Once you don't need a policy anymore, simply delete it with `kubectl`:
```shell
$ kubectl delete psp permissive
podsecuritypolicy "permissive" deleted
```
## Enabling Pod Security Policies
In order to use Pod Security Policies in your cluster you must ensure the
following
1. You have enabled the API type `extensions/v1beta1/podsecuritypolicy` (only for versions prior 1.6)
1. [You have enabled the admission control plug-in `PodSecurityPolicy`](/docs/admin/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in)
1. You have defined your policies
## Working With RBAC
In Kubernetes 1.5 and newer, you can use PodSecurityPolicy to control access to
privileged containers based on user role and groups. Access to different
PodSecurityPolicy objects can be controlled via authorization.
Note that [Controller Manager](/docs/admin/kube-controller-manager/) must be run
against [the secured API port](/docs/admin/accessing-the-api/), and must not
have superuser permissions. Otherwise requests would bypass authentication and
authorization modules, all PodSecurityPolicy objects would be allowed,
and user will be able to create privileged containers.
PodSecurityPolicy authorization uses the union of all policies available to the
user creating the pod and
[the service account specified on the pod](/docs/tasks/configure-pod-container/configure-service-account/).
Access to given PSP policies for a user will be effective only when creating
Pods directly.
For pods created on behalf of a user, in most cases by Controller Manager,
access should be given to the service account specified on the pod spec
template. Examples of resources that create pods on behalf of a user are
Deployments, ReplicaSets, etc.
For more details, see the
[PodSecurityPolicy RBAC example](https://git.k8s.io/examples/staging/podsecuritypolicy/rbac/README.md)
of applying PodSecurityPolicy to control access to privileged containers based
on role and groups when deploying Pods directly.
**seccomp.security.alpha.kubernetes.io/allowedProfileNames** - Annotation that
specifies which values are allowed for the pod seccomp annotations. Specified as
a comma-delimited list of allowed values. Possible values are those listed
above, plus `*` to allow all profiles. Absence of this annotation means that the
default cannot be changed.
docs/concepts/service-catalog/index.md
+1 -1
View File
@@ -5,7 +5,7 @@ approvers:
---
{% capture overview %}
{% glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is " %}
{% glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" %}
A *Service Broker*, as defined by the [Open Service Broker API spec](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md), is an endpoint for a set of Managed Services offered and maintained by a third-party, which could be a cloud provider such as AWS, GCP, or Azure.
Some examples of *Managed Services* are Microsoft Azure Cloud Queue, Amazon Simple Queue Service, and Google Cloud Pub/Sub, but they can be any software offering that can be used by an application.
docs/concepts/services-networking/ingress.md
+2 -2
View File
@@ -73,7 +73,7 @@ spec:
*POSTing this to the API server will have no effect if you have not configured an [Ingress controller](#ingress-controllers).*
__Lines 1-6__: As with all other Kubernetes config, an Ingress needs `apiVersion`, `kind`, and `metadata` fields. For general information about working with config files, see [deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/), [configuring containers](/docs/tasks/configure-pod-container/configmap/), [managing resources](/docs/concepts/cluster-administration/manage-deployment/) and [ingress configuration rewrite](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md).
__Lines 1-6__: As with all other Kubernetes config, an Ingress needs `apiVersion`, `kind`, and `metadata` fields. For general information about working with config files, see [deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/), [configuring containers](/docs/tasks/configure-pod-container/configure-pod-configmap/), [managing resources](/docs/concepts/cluster-administration/manage-deployment/) and [ingress configuration rewrite](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md).
__Lines 7-9__: Ingress [spec](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) has all the information needed to configure a loadbalancer or proxy server. Most importantly, it contains a list of rules matched against all incoming requests. Currently the Ingress resource only supports http rules.
@@ -224,7 +224,7 @@ Note that there is a gap between TLS features supported by various Ingress contr
### Loadbalancing
An Ingress controller is bootstrapped with some load balancing policy settings that it applies to all Ingress, such as the load balancing algorithm, backend weight scheme, and others. More advanced load balancing concepts (e.g.: persistent sessions, dynamic weights) are not yet exposed through the Ingress. You can still get these features through the [service loadbalancer](https://git.k8s.io/contrib/service-loadbalancer). With time, we plan to distill load balancing patterns that are applicable cross platform into the Ingress resource.
An Ingress controller is bootstrapped with some load balancing policy settings that it applies to all Ingress, such as the load balancing algorithm, backend weight scheme, and others. More advanced load balancing concepts (e.g.: persistent sessions, dynamic weights) are not yet exposed through the Ingress. You can still get these features through the [service loadbalancer](https://github.com/kubernetes/ingress-nginx/blob/master/docs/catalog.md). With time, we plan to distill load balancing patterns that are applicable cross platform into the Ingress resource.
It's also worth noting that even though health checks are not exposed directly through the Ingress, there exist parallel concepts in Kubernetes such as [readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) which allow you to achieve the same end result. Please review the controller specific docs to see how they handle health checks ([nginx](https://git.k8s.io/ingress-nginx/README.md), [GCE](https://git.k8s.io/ingress-gce/README.md#health-checks)).
docs/concepts/services-networking/network-policies.md
+1 -1
View File
@@ -68,7 +68,7 @@ spec:
*POSTing this to the API server will have no effect unless your chosen networking solution supports network policy.*
__Mandatory Fields__: As with all other Kubernetes config, a `NetworkPolicy` needs `apiVersion`, `kind`, and `metadata` fields. For general information about working with config files, see [Configure Containers Using a ConfigMap](/docs/tasks/configure-pod-container/configmap/), and [Object Management](https://kubernetes.io/docs/tutorials/object-management-kubectl/object-management/).
__Mandatory Fields__: As with all other Kubernetes config, a `NetworkPolicy` needs `apiVersion`, `kind`, and `metadata` fields. For general information about working with config files, see [Configure Containers Using a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/), and [Object Management](https://kubernetes.io/docs/tutorials/object-management-kubectl/object-management/).
__spec__: `NetworkPolicy` [spec](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) has all the information needed to define a particular network policy in the given namespace.

Some files were not shown because too many files have changed in this diff Show More