diff --git a/.travis.yml b/.travis.yml index 4f15008944..0fe57ab80e 100644 --- a/.travis.yml +++ b/.travis.yml @@ -1,3 +1,6 @@ +env: + global: + - KUBE_VERSION: 1.13 language: go go: - 1.11.5 @@ -8,22 +11,10 @@ jobs: cache: directories: - $HOME/.cache/go-build - # Don't want default ./... here: install: - - export PATH=$GOPATH/bin:$PATH - - mkdir -p $HOME/gopath/src/k8s.io - - mv $TRAVIS_BUILD_DIR $HOME/gopath/src/k8s.io/website && cd $HOME/gopath/src/k8s.io/website - - # Make sure we are testing against the correct branch - - pushd $GOPATH/src/k8s.io && git clone https://github.com/kubernetes/kubernetes && popd - - pushd $GOPATH/src/k8s.io/kubernetes && git checkout release-1.13 && make generated_files && popd - - cp -L -R $GOPATH/src/k8s.io/kubernetes/vendor/ $GOPATH/src/ - - rm -r $GOPATH/src/k8s.io/kubernetes/vendor/ - - # Fetch additional dependencies to run the tests in examples/examples_test.go - - go get -t -v k8s.io/website/content/en/examples + - bash scripts/test_examples.sh install script: - - go test -v k8s.io/website/content/en/examples + - bash scripts/test_examples.sh run - name: "Hugo build" install: - make travis-hugo-build diff --git a/OWNERS b/OWNERS index 82662b6c46..62138a57ba 100644 --- a/OWNERS +++ b/OWNERS @@ -1,12 +1,10 @@ # See the OWNERS docs at https://go.k8s.io/owners -# Reviewers can /lgtm /approve but not sufficient for auto-merge without an -# approver reviewers: -- sig-docs-en-reviews +- sig-docs-en-reviews # Defined in OWNERS_ALIASES -# Approvers have all the ability of reviewers but their /approve makes -# auto-merge happen if a /lgtm exists, or vice versa, or they can do both -# No need for approvers to also be listed as reviewers approvers: -- sig-docs-en-owners +- sig-docs-en-owners # Defined in OWNERS_ALIASES + +labels: +- sig/docs \ No newline at end of file diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index 8ee41f9a72..6055674d4f 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -1,68 +1,4 @@ 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 - - andyzhangx - - feiskyer - - justaugustus - - karataliu - - khenidak - 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-kubeadm-approvers: # Approving changes to kubeadm documentation - timothysc - lukemarsden @@ -82,38 +18,7 @@ aliases: - chuckha - detiber - dixudx - 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-maintainers - - bradamant3 - - bradtopol - - chenopis - - cody-clark - - jaredbhatti - - kbarnard10 - - mistyhacks - - ryanmcginnis - - steveperry-53 - - tengqm - - tfogo - - xiangpengzhao - - zacharysarah - - zhangxiaoyu-zidif - - zparnold - sig-docs-en-owners: #Team: Documentation; GH: sig-docs-en-owners + sig-docs-en-owners: # Admins for English content - bradamant3 - bradtopol - chenopis @@ -131,13 +36,13 @@ aliases: - zacharysarah - zhangxiaoyu-zidif - zparnold - sig-docs-en-reviews: #Team: Documentation; GH: sig-docs-pr-reviews + sig-docs-en-reviews: # PR reviews for English content - jimangel - rajakavitha1 - stewart-yu - xiangpengzhao - zhangxiaoyu-zidif - sig-docs-fr-owners: #Team: Documentation; GH: sig-docs-fr-owners + sig-docs-fr-owners: # Admins for French content - sieben - perriea - rekcah78 @@ -150,7 +55,7 @@ aliases: - jygastaud - awkif - oussemos - sig-docs-fr-reviews: #Team: Documentation; GH: sig-docs-fr-reviews + sig-docs-fr-reviews: # PR reviews for French content - sieben - perriea - rekcah78 @@ -163,35 +68,47 @@ aliases: - jygastaud - awkif - oussemos - sig-docs-it-owners: #Team: Italian docs localization; GH: sig-docs-it-owners + sig-docs-it-owners: # Admins for Italian content - rlenferink - lledru - micheleberardi - sig-docs-it-reviews: #Team: Italian docs PR reviews; GH:sig-docs-it-reviews + sig-docs-it-reviews: # PR reviews for Italian content - rlenferink - lledru - micheleberardi - sig-docs-ja-owners: #Team: Japanese docs localization; GH: sig-docs-ja-owners + sig-docs-ja-owners: # Admins for Japanese content - cstoku - nasa9084 - tnir - zacharysarah - sig-docs-ja-reviews: #Team: Japanese docs PR reviews; GH:sig-docs-ja-reviews + sig-docs-ja-reviews: # PR reviews for Italian content - cstoku - makocchi-git - MasayaAoyama - nasa9084 - tnir - sig-docs-ko-owners: #Team Korean docs localization; GH: sig-docs-ko-owners + sig-docs-ko-owners: # Admins for Korean content - ClaudiaJKang - gochist - ianychoi - zacharysarah - sig-docs-ko-reviews: #Team Korean docs reviews; GH: sig-docs-ko-reviews + sig-docs-ko-reviews: # PR reviews for Korean content - ClaudiaJKang - gochist - ianychoi - sig-docs-zh-owners: #Team Chinese docs localization; GH: sig-docs-zh-owners + sig-docs-maintainers: # Website maintainers + - bradamant3 + - chenopis + - jaredbhatti + - jimangel + - kbarnard10 + - mistyhacks + - pwittrock + - steveperry-53 + - tengqm + - zacharysarah + - zparnold + sig-docs-zh-owners: # Admins for Chinese content - bradtopol - chenopis - chenrui333 @@ -201,128 +118,20 @@ aliases: - lichuqiang - lucperkins - markthink + - SataQiu - tengqm - xiangpengzhao - xichengliudui - zacharysarah - zhangxiaoyu-zidif - sig-docs-zh-reviews: #Team Chinese docs reviews; GH: sig-docs-zh-reviews + sig-docs-zh-reviews: # PR reviews for Chinese content - chenrui333 - idealhack - markthink + - SataQiu - tengqm - xiangpengzhao - xichengliudui - zhangxiaoyu-zidif - pigletfly - 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 - - 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 - - hogepodge - - dklyle - - rjmorse - 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 - + \ No newline at end of file diff --git a/SECURITY_CONTACTS b/SECURITY_CONTACTS index 22a9f7a2ba..a91048f714 100644 --- a/SECURITY_CONTACTS +++ b/SECURITY_CONTACTS @@ -1,10 +1,10 @@ # Defined below are the security contacts for this repo. # -# They are the contact point for the Product Security Team to reach out +# They are the contact point for the Product Security Committee to reach out # to for triaging and handling of incoming issues. # # The below names agree to abide by the -# [Embargo Policy](https://github.com/kubernetes/sig-release/blob/master/security-release-process-documentation/security-release-process.md#embargo-policy) +# [Embargo Policy](https://git.k8s.io/security/private-distributors-list.md#embargo-policy) # and will be removed and replaced if they violate that agreement. # # DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE diff --git a/content/en/blog/_posts/2015-05-00-Resource-Usage-Monitoring-Kubernetes.md b/content/en/blog/_posts/2015-05-00-Resource-Usage-Monitoring-Kubernetes.md index dd38f24a0d..e17eb61b5e 100644 --- a/content/en/blog/_posts/2015-05-00-Resource-Usage-Monitoring-Kubernetes.md +++ b/content/en/blog/_posts/2015-05-00-Resource-Usage-Monitoring-Kubernetes.md @@ -5,7 +5,7 @@ slug: resource-usage-monitoring-kubernetes url: /blog/2015/05/Resource-Usage-Monitoring-Kubernetes --- -Understanding how an application behaves when deployed is crucial to scaling the application and providing a reliable service. In a Kubernetes cluster, application performance can be examined at many different levels: containers, [pods](http://kubernetes.io/docs/user-guide/pods), [services](http://kubernetes.io/docs/user-guide/services), and whole clusters. As part of Kubernetes we want to provide users with detailed resource usage information about their running applications at all these levels. This will give users deep insights into how their applications are performing and where possible application bottlenecks may be found. In comes [Heapster](https://github.com/kubernetes/heapster), a project meant to provide a base monitoring platform on Kubernetes. +Understanding how an application behaves when deployed is crucial to scaling the application and providing a reliable service. In a Kubernetes cluster, application performance can be examined at many different levels: containers, [pods](/docs/user-guide/pods), [services](/docs/user-guide/services), and whole clusters. As part of Kubernetes we want to provide users with detailed resource usage information about their running applications at all these levels. This will give users deep insights into how their applications are performing and where possible application bottlenecks may be found. In comes [Heapster](https://github.com/kubernetes/heapster), a project meant to provide a base monitoring platform on Kubernetes. **Overview** diff --git a/content/en/blog/_posts/2016-03-00-1000-Nodes-And-Beyond-Updates-To-Kubernetes-Performance-And-Scalability-In-12.md b/content/en/blog/_posts/2016-03-00-1000-Nodes-And-Beyond-Updates-To-Kubernetes-Performance-And-Scalability-In-12.md index 3fe216a085..3275a4739b 100644 --- a/content/en/blog/_posts/2016-03-00-1000-Nodes-And-Beyond-Updates-To-Kubernetes-Performance-And-Scalability-In-12.md +++ b/content/en/blog/_posts/2016-03-00-1000-Nodes-And-Beyond-Updates-To-Kubernetes-Performance-And-Scalability-In-12.md @@ -26,7 +26,7 @@ We say Kubernetes scales to a certain number of nodes only if both of these SLOs ### API responsiveness for user-level abstractions[2](https://www.blogger.com/blogger.g?blogID=112706738355446097#2)  -Kubernetes offers high-level abstractions for users to represent their applications. For example, the ReplicationController is an abstraction representing a collection of [pods](http://kubernetes.io/docs/user-guide/pods/). Listing all ReplicationControllers or listing all pods from a given ReplicationController is a very common use case. On the other hand, there is little reason someone would want to list all pods in the system — for example, 30,000 pods (1000 nodes with 30 pods per node) represent ~150MB of data (~5kB/pod \* 30k pods). So this test uses ReplicationControllers. +Kubernetes offers high-level abstractions for users to represent their applications. For example, the ReplicationController is an abstraction representing a collection of [pods](/docs/user-guide/pods/). Listing all ReplicationControllers or listing all pods from a given ReplicationController is a very common use case. On the other hand, there is little reason someone would want to list all pods in the system — for example, 30,000 pods (1000 nodes with 30 pods per node) represent ~150MB of data (~5kB/pod \* 30k pods). So this test uses ReplicationControllers. For this test (assuming N to be number of nodes in the cluster), we: diff --git a/content/en/blog/_posts/2016-03-00-How-Container-Metadata-Changes-Your-Point-Of-View.md b/content/en/blog/_posts/2016-03-00-How-Container-Metadata-Changes-Your-Point-Of-View.md index bce09cab05..46307604bc 100644 --- a/content/en/blog/_posts/2016-03-00-How-Container-Metadata-Changes-Your-Point-Of-View.md +++ b/content/en/blog/_posts/2016-03-00-How-Container-Metadata-Changes-Your-Point-Of-View.md @@ -14,7 +14,7 @@ We’ll take a look at some examples of this below, but first... ### A quick intro to Kubernetes metadata  -Kubernetes metadata is abundant in the form of [_labels_](http://kubernetes.io/docs/user-guide/labels/) and [_annotations_](http://kubernetes.io/docs/user-guide/annotations/). Labels are designed to be identifying metadata for your infrastructure, whereas annotations are designed to be non-identifying. For both, they’re simply generic key:value pairs that look like this: +Kubernetes metadata is abundant in the form of [_labels_](/docs/user-guide/labels/) and [_annotations_](/docs/user-guide/annotations/). Labels are designed to be identifying metadata for your infrastructure, whereas annotations are designed to be non-identifying. For both, they’re simply generic key:value pairs that look like this: ``` "labels": { diff --git a/content/en/blog/_posts/2016-03-00-Kubernetes-1-2-And-Simplifying-Advanced-Networking-With-Ingress.md b/content/en/blog/_posts/2016-03-00-Kubernetes-1-2-And-Simplifying-Advanced-Networking-With-Ingress.md index f70857925a..3373680d42 100644 --- a/content/en/blog/_posts/2016-03-00-Kubernetes-1-2-And-Simplifying-Advanced-Networking-With-Ingress.md +++ b/content/en/blog/_posts/2016-03-00-Kubernetes-1-2-And-Simplifying-Advanced-Networking-With-Ingress.md @@ -11,7 +11,7 @@ In Kubernetes, Services and Pods have IPs only routable by the cluster network, ### Ingress controllers -Today, with containers or VMs, configuring a web server or load balancer is harder than it should be. Most web server configuration files are very similar. There are some applications that have weird little quirks that tend to throw a wrench in things, but for the most part, you can apply the same logic to them and achieve a desired result. In Kubernetes 1.2, the Ingress resource embodies this idea, and an Ingress controller is meant to handle all the quirks associated with a specific "class" of Ingress (be it a single instance of a load balancer, or a more complicated setup of frontends that provide GSLB, CDN, DDoS protection etc). An Ingress Controller is a daemon, deployed as a Kubernetes Pod, that watches the ApiServer's /ingresses endpoint for updates to the [Ingress resource](http://kubernetes.io/docs/user-guide/ingress/). Its job is to satisfy requests for ingress. +Today, with containers or VMs, configuring a web server or load balancer is harder than it should be. Most web server configuration files are very similar. There are some applications that have weird little quirks that tend to throw a wrench in things, but for the most part, you can apply the same logic to them and achieve a desired result. In Kubernetes 1.2, the Ingress resource embodies this idea, and an Ingress controller is meant to handle all the quirks associated with a specific "class" of Ingress (be it a single instance of a load balancer, or a more complicated setup of frontends that provide GSLB, CDN, DDoS protection etc). An Ingress Controller is a daemon, deployed as a Kubernetes Pod, that watches the ApiServer's /ingresses endpoint for updates to the [Ingress resource](/docs/user-guide/ingress/). Its job is to satisfy requests for ingress. Your Kubernetes cluster must have exactly one Ingress controller that supports TLS for the following example to work. If you’re on a cloud-provider, first check the “kube-system” namespace for an Ingress controller RC. If there isn’t one, you can deploy the [nginx controller](https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx), or [write your own](https://github.com/kubernetes/contrib/tree/master/ingress/controllers#writing-an-ingress-controller) in \< 100 lines of code. @@ -102,7 +102,7 @@ $ curl 130.X.X.X -Lk CLIENT VALUES:client\_address=10.48.0.1command=GETreal path=/ ``` ### Future work -You can read more about the [Ingress API](http://kubernetes.io/docs/user-guide/ingress/) or controllers by following the links. The Ingress is still in beta, and we would love your input to grow it. You can contribute by writing controllers or evolving the API. All things related to the meaning of the word “[ingress](https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=ingress%20meaning)” are in scope, this includes DNS, different TLS modes, SNI, load balancing at layer 4, content caching, more algorithms, better health checks; the list goes on. +You can read more about the [Ingress API](/docs/user-guide/ingress/) or controllers by following the links. The Ingress is still in beta, and we would love your input to grow it. You can contribute by writing controllers or evolving the API. All things related to the meaning of the word “[ingress](https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=ingress%20meaning)” are in scope, this includes DNS, different TLS modes, SNI, load balancing at layer 4, content caching, more algorithms, better health checks; the list goes on. There are many ways to participate. If you’re particularly interested in Kubernetes and networking, you’ll be interested in: diff --git a/content/en/blog/_posts/2016-03-00-Kubernetes-1-2-Even-More-Performance-Upgrades-Plus-Easier-Application-Deployment-And-Management-.md b/content/en/blog/_posts/2016-03-00-Kubernetes-1-2-Even-More-Performance-Upgrades-Plus-Easier-Application-Deployment-And-Management-.md index 8cf91e33f6..aae3e88517 100644 --- a/content/en/blog/_posts/2016-03-00-Kubernetes-1-2-Even-More-Performance-Upgrades-Plus-Easier-Application-Deployment-And-Management-.md +++ b/content/en/blog/_posts/2016-03-00-Kubernetes-1-2-Even-More-Performance-Upgrades-Plus-Easier-Application-Deployment-And-Management-.md @@ -60,7 +60,7 @@ All of our work is done in the open, to learn the latest about the project j[oin - Scheduled job  - Public dashboard that allows for nightly test runs across multiple cloud providers  - Lots, lots more!  -Kubernetes 1.2 is available for download at [get.k8s.io](http://get.k8s.io/) and via the open source repository hosted on [GitHub](https://github.com/kubernetes/kubernetes). To get started with Kubernetes try our new [Hello World app](http://kubernetes.io/docs/hellonode/).  +Kubernetes 1.2 is available for download at [get.k8s.io](http://get.k8s.io/) and via the open source repository hosted on [GitHub](https://github.com/kubernetes/kubernetes). To get started with Kubernetes try our new [Hello World app](/docs/hellonode/).  diff --git a/content/en/blog/_posts/2016-03-00-Scaling-Neural-Network-Image-Classification-Using-Kubernetes-With-Tensorflow-Serving.md b/content/en/blog/_posts/2016-03-00-Scaling-Neural-Network-Image-Classification-Using-Kubernetes-With-Tensorflow-Serving.md index 8454c95579..894b730436 100644 --- a/content/en/blog/_posts/2016-03-00-Scaling-Neural-Network-Image-Classification-Using-Kubernetes-With-Tensorflow-Serving.md +++ b/content/en/blog/_posts/2016-03-00-Scaling-Neural-Network-Image-Classification-Using-Kubernetes-With-Tensorflow-Serving.md @@ -27,7 +27,7 @@ Inference can be very resource intensive. Our server executes the following Tens | [![](https://2.bp.blogspot.com/-Gcb6gxzqDkE/VvHJHE7yD3I/AAAAAAAAA4Y/4EZD83OV_8goqodV2pcaQKYeinokf9UuA/s640/tensorflowserving-3.png)](https://2.bp.blogspot.com/-Gcb6gxzqDkE/VvHJHE7yD3I/AAAAAAAAA4Y/4EZD83OV_8goqodV2pcaQKYeinokf9UuA/s1600/tensorflowserving-3.png) | | Schematic diagram of Inception-v3 | -Fortunately, this is where Kubernetes can help us. Kubernetes distributes inference request processing across a cluster using its [External Load Balancer](http://kubernetes.io/docs/user-guide/load-balancer/). Each [pod](http://kubernetes.io/docs/user-guide/pods/) in the cluster contains a [TensorFlow Serving Docker image](https://tensorflow.github.io/serving/docker) with the TensorFlow Serving-based gRPC server and a trained Inception-v3 model. The model is represented as a [set of files](https://github.com/tensorflow/serving/blob/master/tensorflow_serving/session_bundle/README.md) describing the shape of the TensorFlow graph, model weights, assets, and so on. Since everything is neatly packaged together, we can dynamically scale the number of replicated pods using the [Kubernetes Replication Controller](http://kubernetes.io/docs/user-guide/replication-controller/operations/) to keep up with the service demands. +Fortunately, this is where Kubernetes can help us. Kubernetes distributes inference request processing across a cluster using its [External Load Balancer](/docs/user-guide/load-balancer/). Each [pod](/docs/user-guide/pods/) in the cluster contains a [TensorFlow Serving Docker image](https://tensorflow.github.io/serving/docker) with the TensorFlow Serving-based gRPC server and a trained Inception-v3 model. The model is represented as a [set of files](https://github.com/tensorflow/serving/blob/master/tensorflow_serving/session_bundle/README.md) describing the shape of the TensorFlow graph, model weights, assets, and so on. Since everything is neatly packaged together, we can dynamically scale the number of replicated pods using the [Kubernetes Replication Controller](/docs/user-guide/replication-controller/operations/) to keep up with the service demands. To help you try this out yourself, we’ve written a [step-by-step tutorial](https://tensorflow.github.io/serving/serving_inception), which shows you how to create the TensorFlow Serving Docker container to serve the Inception-v3 image classification model, configure a Kubernetes cluster and run classification requests against it. We hope this will make it easier for you to integrate machine learning into your own applications and scale it with Kubernetes! To learn more about TensorFlow Serving, check out [tensorflow.github.io/serving](http://tensorflow.github.io/serving).  diff --git a/content/en/blog/_posts/2016-03-00-Using-Spark-And-Zeppelin-To-Process-Big-Data-On-Kubernetes.md b/content/en/blog/_posts/2016-03-00-Using-Spark-And-Zeppelin-To-Process-Big-Data-On-Kubernetes.md index dcc9215c28..5870bb80f8 100644 --- a/content/en/blog/_posts/2016-03-00-Using-Spark-And-Zeppelin-To-Process-Big-Data-On-Kubernetes.md +++ b/content/en/blog/_posts/2016-03-00-Using-Spark-And-Zeppelin-To-Process-Big-Data-On-Kubernetes.md @@ -110,7 +110,7 @@ Computing the model and saving it is much slower than computing the model and th {{< /note >}} ### Using Horizontal Pod Autoscaling with Spark (Optional)  -Spark is somewhat elastic to workers coming and going, which means we have an opportunity: we can use use [Kubernetes Horizontal Pod Autoscaling](http://kubernetes.io/docs/user-guide/horizontal-pod-autoscaling/) to scale-out the Spark worker pool automatically, setting a target CPU threshold for the workers and a minimum/maximum pool size. This obviates the need for having to configure the number of worker replicas manually. +Spark is somewhat elastic to workers coming and going, which means we have an opportunity: we can use use [Kubernetes Horizontal Pod Autoscaling](/docs/user-guide/horizontal-pod-autoscaling/) to scale-out the Spark worker pool automatically, setting a target CPU threshold for the workers and a minimum/maximum pool size. This obviates the need for having to configure the number of worker replicas manually. Create the Autoscaler like this (note: if you didn’t change the machine type for the cluster, you probably want to limit the --max to something smaller):  diff --git a/content/en/blog/_posts/2016-04-00-Configuration-Management-With-Containers.md b/content/en/blog/_posts/2016-04-00-Configuration-Management-With-Containers.md index 9b7b0be21a..2aa7b047b7 100644 --- a/content/en/blog/_posts/2016-04-00-Configuration-Management-With-Containers.md +++ b/content/en/blog/_posts/2016-04-00-Configuration-Management-With-Containers.md @@ -184,7 +184,7 @@ spec: path: cfg/game.properties restartPolicy: Never ``` -In the above example, the Deployment uses keys of the ConfigMap via two of the different mechanisms available. The property-like keys of the ConfigMap are used as environment variables to the single container in the Deployment template, and the file-like keys populate a volume. For more details, please see the [ConfigMap docs](http://kubernetes.io/docs/user-guide/configmap/). +In the above example, the Deployment uses keys of the ConfigMap via two of the different mechanisms available. The property-like keys of the ConfigMap are used as environment variables to the single container in the Deployment template, and the file-like keys populate a volume. For more details, please see the [ConfigMap docs](/docs/user-guide/configmap/). We hope that these basic primitives are easy to use and look forward to seeing what people build with ConfigMaps. Thanks to the community members that provided feedback about this feature. Special thanks also to Tamer Tas who made a great contribution to the proposal and implementation of ConfigMap. diff --git a/content/en/blog/_posts/2016-04-00-Using-Deployment-Objects-With.md b/content/en/blog/_posts/2016-04-00-Using-Deployment-Objects-With.md index 030d7a6f1c..2bdffb9cc5 100644 --- a/content/en/blog/_posts/2016-04-00-Using-Deployment-Objects-With.md +++ b/content/en/blog/_posts/2016-04-00-Using-Deployment-Objects-With.md @@ -24,8 +24,8 @@ Without further ado, let’s start playing around with Deployments! ### Getting started If you want to try this example, basically you’ll need 3 things: -1. **A running Kubernetes cluster** : If you don’t already have one, check the [Getting Started guides](http://kubernetes.io/docs/getting-started-guides/) for a list of solutions on a range of platforms, from your laptop, to VMs on a cloud provider, to a rack of bare metal servers. -2. **Kubectl, the Kubernetes CLI** : If you see a URL response after running kubectl cluster-info, you’re ready to go. Otherwise, follow the [instructions](http://kubernetes.io/docs/user-guide/prereqs/) to install and configure kubectl; or the [instructions for hosted solutions](https://cloud.google.com/container-engine/docs/before-you-begin) if you have a Google Container Engine cluster. +1. **A running Kubernetes cluster** : If you don’t already have one, check the [Getting Started guides](/docs/getting-started-guides/) for a list of solutions on a range of platforms, from your laptop, to VMs on a cloud provider, to a rack of bare metal servers. +2. **Kubectl, the Kubernetes CLI** : If you see a URL response after running kubectl cluster-info, you’re ready to go. Otherwise, follow the [instructions](/docs/user-guide/prereqs/) to install and configure kubectl; or the [instructions for hosted solutions](https://cloud.google.com/container-engine/docs/before-you-begin) if you have a Google Container Engine cluster. 3. The [configuration files for this demo](https://github.com/kubernetes/kubernetes.github.io/tree/master/docs/user-guide/update-demo). If you choose not to run this example yourself, that’s okay. Just watch this [video](https://youtu.be/eigalYy0v4w) to see what’s going on in each step. @@ -99,7 +99,7 @@ deployment "update-demo" rolled back Everything’s back to normal, phew! -To learn more about rollback, visit [rolling back a Deployment](http://kubernetes.io/docs/user-guide/deployments/#rolling-back-a-deployment). +To learn more about rollback, visit [rolling back a Deployment](/docs/user-guide/deployments/#rolling-back-a-deployment). ### Updating your application (for real) After a while, we finally figure that the right image tag is “kitten”, instead of “kitty”. Now change .spec.template.spec.containers[0].image tag from “nautilus“ to “kitten“. @@ -119,7 +119,7 @@ $ kubectl describe deployment/update-demo [![](https://1.bp.blogspot.com/-3U1OTNqdz1s/Vv7Kfw4uGYI/AAAAAAAAChU/CgF6Mv5J6b8_lANXkpEIFytRGo9x0Bn_A/s640/deployment-API-6.png)](https://1.bp.blogspot.com/-3U1OTNqdz1s/Vv7Kfw4uGYI/AAAAAAAAChU/CgF6Mv5J6b8_lANXkpEIFytRGo9x0Bn_A/s1600/deployment-API-6.png) -From the events section, you’ll find that the Deployment is managing another resource called [Replica Set](http://kubernetes.io/docs/user-guide/replicasets/), each controls the number of replicas of a different pod template. The Deployment enables progressive rollout by scaling up and down Replica Sets of new and old pod templates. +From the events section, you’ll find that the Deployment is managing another resource called [Replica Set](/docs/user-guide/replicasets/), each controls the number of replicas of a different pod template. The Deployment enables progressive rollout by scaling up and down Replica Sets of new and old pod templates. ### Conclusion Now, you’ve learned the basic use of Deployment objects: @@ -127,7 +127,7 @@ Now, you’ve learned the basic use of Deployment objects: 1. Deploy an app with a Deployment, using kubectl run 2. Updating the app by updating the Deployment with kubectl edit 3. Rolling back to a previously deployed app with kubectl rollout undo -But there’s so much more in Deployment that this article didn’t cover! To discover more, continue reading [Deployment’s introduction](http://kubernetes.io/docs/user-guide/deployments/). +But there’s so much more in Deployment that this article didn’t cover! To discover more, continue reading [Deployment’s introduction](/docs/user-guide/deployments/). **_Note:_** _In Kubernetes 1.2, Deployment (beta release) is now feature-complete and enabled by default. For those of you who have tried Deployment in Kubernetes 1.1, please **delete all Deployment 1.1 resources** (including the Replication Controllers and Pods they manage) before trying out Deployments in 1.2. This is necessary because we made some non-backward-compatible changes to the API._ diff --git a/content/en/blog/_posts/2016-05-00-Hypernetes-Security-And-Multi-Tenancy-In-Kubernetes.md b/content/en/blog/_posts/2016-05-00-Hypernetes-Security-And-Multi-Tenancy-In-Kubernetes.md index 36846fe663..f80cd15d28 100644 --- a/content/en/blog/_posts/2016-05-00-Hypernetes-Security-And-Multi-Tenancy-In-Kubernetes.md +++ b/content/en/blog/_posts/2016-05-00-Hypernetes-Security-And-Multi-Tenancy-In-Kubernetes.md @@ -105,7 +105,7 @@ spec: ``` -If a Namespace does not have a Network spec, it will use the default Kubernetes network model instead, including the default kube-proxy. So if a user creates a Pod in a Namespace with an associated Network, Hypernetes will follow the [Kubernetes Network Plugin Model](http://kubernetes.io/docs/admin/network-plugins/) to set up a Neutron network for this Pod. Here is a high level example: +If a Namespace does not have a Network spec, it will use the default Kubernetes network model instead, including the default kube-proxy. So if a user creates a Pod in a Namespace with an associated Network, Hypernetes will follow the [Kubernetes Network Plugin Model](/docs/admin/network-plugins/) to set up a Neutron network for this Pod. Here is a high level example: diff --git a/content/en/blog/_posts/2016-06-00-Bringing-End-To-End-Testing-To-Azure.md b/content/en/blog/_posts/2016-06-00-Bringing-End-To-End-Testing-To-Azure.md index 2274ad0c8e..60be46f0a0 100644 --- a/content/en/blog/_posts/2016-06-00-Bringing-End-To-End-Testing-To-Azure.md +++ b/content/en/blog/_posts/2016-06-00-Bringing-End-To-End-Testing-To-Azure.md @@ -17,11 +17,11 @@ In this blog post, we describe the journey we took to implement deployment scrip **BACKGROUND** -While Kubernetes is designed to operate on any IaaS, and [solution guides](http://kubernetes.io/docs/getting-started-guides/#table-of-solutions) exist for many platforms including [Google Compute Engine](http://kubernetes.io/docs/getting-started-guides/gce/), [AWS](http://kubernetes.io/docs/getting-started-guides/aws/), [Azure](http://kubernetes.io/docs/getting-started-guides/coreos/azure/), and [Rackspace](http://kubernetes.io/docs/getting-started-guides/rackspace/), the Kubernetes project refers to these as “versioned distros,” as they are only tested against a particular binary release of Kubernetes. On the other hand, “development distros” are used daily by automated, e2e tests for the latest Kubernetes source code, and serve as gating checks to code submission. +While Kubernetes is designed to operate on any IaaS, and [solution guides](/docs/getting-started-guides/#table-of-solutions) exist for many platforms including [Google Compute Engine](/docs/getting-started-guides/gce/), [AWS](/docs/getting-started-guides/aws/), [Azure](/docs/getting-started-guides/coreos/azure/), and [Rackspace](/docs/getting-started-guides/rackspace/), the Kubernetes project refers to these as “versioned distros,” as they are only tested against a particular binary release of Kubernetes. On the other hand, “development distros” are used daily by automated, e2e tests for the latest Kubernetes source code, and serve as gating checks to code submission. -When we first surveyed existing support for Kubernetes on Azure, we found documentation for running Kubernetes on Azure using CoreOS and Weave. The documentation includes [scripts for deployment](http://kubernetes.io/docs/getting-started-guides/coreos/azure/), but the scripts do not conform to the cluster/kube-up.sh framework for automated cluster creation required by a “development distro.” Further, there did not exist a continuous integration job that utilized the scripts to validate Kubernetes using the end-to-end test scenarios (those found in test/e2e in the Kubernetes repository). +When we first surveyed existing support for Kubernetes on Azure, we found documentation for running Kubernetes on Azure using CoreOS and Weave. The documentation includes [scripts for deployment](/docs/getting-started-guides/coreos/azure/), but the scripts do not conform to the cluster/kube-up.sh framework for automated cluster creation required by a “development distro.” Further, there did not exist a continuous integration job that utilized the scripts to validate Kubernetes using the end-to-end test scenarios (those found in test/e2e in the Kubernetes repository). diff --git a/content/en/blog/_posts/2016-06-00-Container-Design-Patterns.md b/content/en/blog/_posts/2016-06-00-Container-Design-Patterns.md index bb15f72592..155bca0db4 100644 --- a/content/en/blog/_posts/2016-06-00-Container-Design-Patterns.md +++ b/content/en/blog/_posts/2016-06-00-Container-Design-Patterns.md @@ -9,13 +9,13 @@ Kubernetes automates deployment, operations, and scaling of applications, but ou Our work on the latter is just beginning, but you can already see it manifested in a few features of Kubernetes. For example: -- The “[graceful termination](http://kubernetes.io/docs/api-reference/v1/definitions/#_v1_podspec)” mechanism provides a callback into the container a configurable amount of time before it is killed (due to a rolling update, node drain for maintenance, etc.). This allows the application to cleanly shut down, e.g. persist in-memory state and cleanly conclude open connections. -- [Liveness and readiness probes](http://kubernetes.io/docs/user-guide/production-pods/#liveness-and-readiness-probes-aka-health-checks) check a configurable application HTTP endpoint (other probe types are supported as well) to determine if the container is alive and/or ready to receive traffic. The response determines whether Kubernetes will restart the container, include it in the load-balancing pool for its Service, etc. -- [ConfigMap](http://kubernetes.io/docs/user-guide/configmap/) allows applications to read their configuration from a Kubernetes resource rather than using command-line flags. +- The “[graceful termination](/docs/api-reference/v1/definitions/#_v1_podspec)” mechanism provides a callback into the container a configurable amount of time before it is killed (due to a rolling update, node drain for maintenance, etc.). This allows the application to cleanly shut down, e.g. persist in-memory state and cleanly conclude open connections. +- [Liveness and readiness probes](/docs/user-guide/production-pods/#liveness-and-readiness-probes-aka-health-checks) check a configurable application HTTP endpoint (other probe types are supported as well) to determine if the container is alive and/or ready to receive traffic. The response determines whether Kubernetes will restart the container, include it in the load-balancing pool for its Service, etc. +- [ConfigMap](/docs/user-guide/configmap/) allows applications to read their configuration from a Kubernetes resource rather than using command-line flags. More generally, we see Kubernetes enabling a new generation of design patterns, similar to [object oriented design patterns](https://en.wikipedia.org/wiki/Object-oriented_programming#Design_patterns), but this time for containerized applications. That design patterns would emerge from containerized architectures is not surprising -- containers provide many of the same benefits as software objects, in terms of modularity/packaging, abstraction, and reuse. Even better, because containers generally interact with each other via HTTP and widely available data formats like JSON, the benefits can be provided in a language-independent way. -This week Kubernetes co-founder Brendan Burns is presenting a [**paper**](https://www.usenix.org/conference/hotcloud16/workshop-program/presentation/burns) outlining our thoughts on this topic at the [8th Usenix Workshop on Hot Topics in Cloud Computing](https://www.usenix.org/conference/hotcloud16) (HotCloud ‘16), a venue where academic researchers and industry practitioners come together to discuss ideas at the forefront of research in private and public cloud technology. The paper describes three classes of patterns: management patterns (such as those described above), patterns involving multiple cooperating containers running on the same node, and patterns involving containers running across multiple nodes. We don’t want to spoil the fun of reading the paper, but we will say that you’ll see that the [Pod](http://kubernetes.io/docs/user-guide/pods/) abstraction is a key enabler for the last two types of patterns. +This week Kubernetes co-founder Brendan Burns is presenting a [**paper**](https://www.usenix.org/conference/hotcloud16/workshop-program/presentation/burns) outlining our thoughts on this topic at the [8th Usenix Workshop on Hot Topics in Cloud Computing](https://www.usenix.org/conference/hotcloud16) (HotCloud ‘16), a venue where academic researchers and industry practitioners come together to discuss ideas at the forefront of research in private and public cloud technology. The paper describes three classes of patterns: management patterns (such as those described above), patterns involving multiple cooperating containers running on the same node, and patterns involving containers running across multiple nodes. We don’t want to spoil the fun of reading the paper, but we will say that you’ll see that the [Pod](/docs/user-guide/pods/) abstraction is a key enabler for the last two types of patterns. As the Kubernetes project continues to bring our decade of experience with [Borg](https://queue.acm.org/detail.cfm?id=2898444) to the open source community, we aim not only to make application deployment and operations at scale simple and reliable, but also to make it easy to create “cloud-native” applications in the first place. Our work on documenting our ideas around design patterns for container-based services, and Kubernetes’s enabling of such patterns, is a first step in this direction. We look forward to working with the academic and practitioner communities to identify and codify additional patterns, with the aim of helping containers fulfill the promise of bringing increased simplicity and reliability to the entire software lifecycle, from development, to deployment, to operations. diff --git a/content/en/blog/_posts/2016-07-00-Dashboard-Web-Interface-For-Kubernetes.md b/content/en/blog/_posts/2016-07-00-Dashboard-Web-Interface-For-Kubernetes.md index 2b81ffaad6..3dcbaea420 100644 --- a/content/en/blog/_posts/2016-07-00-Dashboard-Web-Interface-For-Kubernetes.md +++ b/content/en/blog/_posts/2016-07-00-Dashboard-Web-Interface-For-Kubernetes.md @@ -13,7 +13,7 @@ _Editor’s note: this post is part of a [series of in-depth articles](https://k Thanks to a large number of contributions from the community and project members, we were able to deliver many new features for [Kubernetes 1.3 release](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads). We have been carefully listening to all the great feedback we have received from our users (see the [summary infographics](http://static.lwy.io/img/kubernetes_dashboard_infographic.png)) and addressed the highest priority requests and pain points. -The Dashboard UI now handles all workload resources. This means that no matter what workload type you run, it is visible in the web interface and you can do operational changes on it. For example, you can modify your stateful MySQL installation with [Pet Sets](http://kubernetes.io/docs/user-guide/petset/), do a rolling update of your web server with Deployments or install cluster monitoring with DaemonSets.  +The Dashboard UI now handles all workload resources. This means that no matter what workload type you run, it is visible in the web interface and you can do operational changes on it. For example, you can modify your stateful MySQL installation with [Pet Sets](/docs/user-guide/petset/), do a rolling update of your web server with Deployments or install cluster monitoring with DaemonSets.  diff --git a/content/en/blog/_posts/2016-07-00-Kubernetes-1-3-Bridging-Cloud-Native-And-Enterprise-Workloads.md b/content/en/blog/_posts/2016-07-00-Kubernetes-1-3-Bridging-Cloud-Native-And-Enterprise-Workloads.md index 277996d6f0..c13eac3f19 100644 --- a/content/en/blog/_posts/2016-07-00-Kubernetes-1-3-Bridging-Cloud-Native-And-Enterprise-Workloads.md +++ b/content/en/blog/_posts/2016-07-00-Kubernetes-1-3-Bridging-Cloud-Native-And-Enterprise-Workloads.md @@ -39,7 +39,7 @@ We could not have achieved this milestone without the tireless effort of countle **Availability** -Kubernetes 1.3 is available for download at [get.k8s.io](http://get.k8s.io/) and via the open source repository hosted on [GitHub](http://github.com/kubernetes/kubernetes). To get started with Kubernetes try our [Hello World app](http://kubernetes.io/docs/hellonode/). +Kubernetes 1.3 is available for download at [get.k8s.io](http://get.k8s.io/) and via the open source repository hosted on [GitHub](http://github.com/kubernetes/kubernetes). To get started with Kubernetes try our [Hello World app](/docs/hellonode/). diff --git a/content/en/blog/_posts/2016-07-00-Kubernetes-In-Rancher-Further-Evolution.md b/content/en/blog/_posts/2016-07-00-Kubernetes-In-Rancher-Further-Evolution.md index 7ce90e5791..34ad21d389 100644 --- a/content/en/blog/_posts/2016-07-00-Kubernetes-In-Rancher-Further-Evolution.md +++ b/content/en/blog/_posts/2016-07-00-Kubernetes-In-Rancher-Further-Evolution.md @@ -168,7 +168,7 @@ When we launched Kubernetes support in Rancher we decided to maintain our own di - Rancher as a CredentialProvider (to support Rancher private registries). - Rancher Ingress controller to back up Kubernetes ingress resource. -So we’ve decided to eliminate the need of Rancher Kubernetes distribution, and try to upstream all our changes to the Kubernetes repo. To do that, we will be reworking our networking integration, and support Rancher networking as a [CNI plugin for Kubernetes](http://kubernetes.io/docs/admin/network-plugins/#cni). More details on that will be shared as soon as the feature design is finalized, but expect it to come in the next 2-3 months. We will also continue investing in Rancher’s core capabilities integrated with Kubernetes, including, but not limited to: +So we’ve decided to eliminate the need of Rancher Kubernetes distribution, and try to upstream all our changes to the Kubernetes repo. To do that, we will be reworking our networking integration, and support Rancher networking as a [CNI plugin for Kubernetes](/docs/admin/network-plugins/#cni). More details on that will be shared as soon as the feature design is finalized, but expect it to come in the next 2-3 months. We will also continue investing in Rancher’s core capabilities integrated with Kubernetes, including, but not limited to: - Access rights management via Rancher environment that represents Kubernetes cluster - Credential management and easy web-based access to standard kubectl cli diff --git a/content/en/blog/_posts/2016-07-00-Rktnetes-Brings-Rkt-Container-Engine-To-Kubernetes.md b/content/en/blog/_posts/2016-07-00-Rktnetes-Brings-Rkt-Container-Engine-To-Kubernetes.md index 7ad6226e11..4bbe0d4147 100644 --- a/content/en/blog/_posts/2016-07-00-Rktnetes-Brings-Rkt-Container-Engine-To-Kubernetes.md +++ b/content/en/blog/_posts/2016-07-00-Rktnetes-Brings-Rkt-Container-Engine-To-Kubernetes.md @@ -71,10 +71,10 @@ This dual interface to the container environment is an area of very active devel So what can you do with rktnetes today? Currently, rktnetes passes all of [the applicable Kubernetes “end-to-end” (aka “e2e”) tests](http://storage.googleapis.com/kubernetes-test-history/static/suite-rktnetes:kubernetes-e2e-gce.html), provides standard metrics to cAdvisor, manages networks using [CNI](https://github.com/containernetworking/cni), handles per-container/pod logs, and automatically garbage collects old containers and images. Kubernetes running on rkt already provides more than the basics of a modular, flexible container runtime for Kubernetes clusters, and it is already a functional part of our development environment at CoreOS. -Developers and early adopters can follow the known issues in the [rktnetes notes](http://kubernetes.io/docs/getting-started-guides/rkt/notes/) to get an idea  of the wrinkles and bumps test-drivers can expect to encounter. This list groups the high-level pieces required to bring rktnetes to feature parity with the existing container runtime and API. We hope you’ll try out rktnetes in your Kubernetes clusters, too. +Developers and early adopters can follow the known issues in the [rktnetes notes](/docs/getting-started-guides/rkt/notes/) to get an idea  of the wrinkles and bumps test-drivers can expect to encounter. This list groups the high-level pieces required to bring rktnetes to feature parity with the existing container runtime and API. We hope you’ll try out rktnetes in your Kubernetes clusters, too. #### Use rkt with Kubernetes Today -The introductory guide [_Running Kubernetes on rkt_](http://kubernetes.io/docs/getting-started-guides/rkt/) walks through the steps to spin up a rktnetes cluster, from kubelet --container-runtime=rkt to networking and starting pods. This intro also sketches the configuration you’ll need to start a cluster on GCE with the Kubernetes kube-up.sh script. +The introductory guide [_Running Kubernetes on rkt_](/docs/getting-started-guides/rkt/) walks through the steps to spin up a rktnetes cluster, from kubelet --container-runtime=rkt to networking and starting pods. This intro also sketches the configuration you’ll need to start a cluster on GCE with the Kubernetes kube-up.sh script. Recent work aims to make rktnetes cluster creation much easier, too. While not yet merged, an [in-progress pull request creates a single rktnetes configuration toggle](https://github.com/coreos/coreos-kubernetes/pull/551) to select rkt as the container engine when deploying a Kubernetes cluster with the [coreos-kubernetes](https://github.com/coreos/coreos-kubernetes#kubernetes-on-coreos) configuration tools. You can also check out the [rktnetes workshop project](https://github.com/coreos/rkt8s-workshop), which launches a single-node rktnetes cluster on just about any developer workstation with one vagrant up command. diff --git a/content/en/blog/_posts/2016-07-00-The-Bet-On-Kubernetes.md b/content/en/blog/_posts/2016-07-00-The-Bet-On-Kubernetes.md index 5cbf3a94de..7d8d2f52de 100644 --- a/content/en/blog/_posts/2016-07-00-The-Bet-On-Kubernetes.md +++ b/content/en/blog/_posts/2016-07-00-The-Bet-On-Kubernetes.md @@ -25,7 +25,7 @@ I believe that reach to be a validation of the vision underlying Kubernetes: to - managing and maintaining clustered software like databases and message queues -Allow developers and operators to move to the next scale of abstraction, just like they have enabled Google and others in the tech ecosystem to scale to datacenter computers and beyond. From Kubernetes 1.0 to 1.3 we have continually improved the power and flexibility of the platform while ALSO improving performance, scalability, reliability, and usability. The explosion of integrations and tools that run on top of Kubernetes further validates core architectural decisions to be [composable](https://research.google.com/pubs/pub43438.html), to expose [open and flexible APIs](http://kubernetes.io/docs/api/), and to [deliberately limit the core platform](http://kubernetes.io/docs/whatisk8s/#kubernetes-is-not) and encourage extension. +Allow developers and operators to move to the next scale of abstraction, just like they have enabled Google and others in the tech ecosystem to scale to datacenter computers and beyond. From Kubernetes 1.0 to 1.3 we have continually improved the power and flexibility of the platform while ALSO improving performance, scalability, reliability, and usability. The explosion of integrations and tools that run on top of Kubernetes further validates core architectural decisions to be [composable](https://research.google.com/pubs/pub43438.html), to expose [open and flexible APIs](/docs/api/), and to [deliberately limit the core platform](/docs/whatisk8s/#kubernetes-is-not) and encourage extension. Today Kubernetes has one of the largest and most vibrant communities in the open source ecosystem, with almost a thousand contributors, one of the highest human-generated commit rates of any single-repository project on GitHub, over a thousand projects based around Kubernetes, and correspondingly active Stack Overflow and Slack channels. Red Hat is proud to be part of this ecosystem as the largest contributor to Kubernetes after Google, and every day more companies and individuals join us. The idea of Kubernetes found fertile ground, and you, the community, provided the excitement and commitment that made it grow. diff --git a/content/en/blog/_posts/2016-07-00-Thousand-Instances-Of-Cassandra-Using-Kubernetes-Pet-Set.md b/content/en/blog/_posts/2016-07-00-Thousand-Instances-Of-Cassandra-Using-Kubernetes-Pet-Set.md index ba88282838..6c9aa0f055 100644 --- a/content/en/blog/_posts/2016-07-00-Thousand-Instances-Of-Cassandra-Using-Kubernetes-Pet-Set.md +++ b/content/en/blog/_posts/2016-07-00-Thousand-Instances-Of-Cassandra-Using-Kubernetes-Pet-Set.md @@ -13,7 +13,7 @@ _Editor’s note: this post is part of a [series of in-depth articles](https://k For the [Kubernetes 1.3 launch](https://kubernetes.io/blog/2016/07/kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads), we wanted to put the new Pet Set through its paces. By testing a thousand instances of [Cassandra](https://cassandra.apache.org/), we could make sure that Kubernetes 1.3 was production ready. Read on for how we adapted Cassandra to Kubernetes, and had our largest deployment ever. -It’s fairly straightforward to use containers with basic stateful applications today. Using a persistent volume, you can mount a disk in a pod, and ensure that your data lasts beyond the life of your pod. However, with deployments of distributed stateful applications, things can become more tricky. With Kubernetes 1.3, the new [Pet Set](http://kubernetes.io/docs/user-guide/petset/) component makes everything much easier. To test this new feature out at scale, we decided to host the Greek Pet Monster Races! We raced Centaurs and other Ancient Greek Monsters over hundreds of thousands of races across multiple availability zones. +It’s fairly straightforward to use containers with basic stateful applications today. Using a persistent volume, you can mount a disk in a pod, and ensure that your data lasts beyond the life of your pod. However, with deployments of distributed stateful applications, things can become more tricky. With Kubernetes 1.3, the new [Pet Set](/docs/user-guide/petset/) component makes everything much easier. To test this new feature out at scale, we decided to host the Greek Pet Monster Races! We raced Centaurs and other Ancient Greek Monsters over hundreds of thousands of races across multiple availability zones. [![File:Cassandra1.jpeg](https://upload.wikimedia.org/wikipedia/commons/thumb/4/42/Cassandra1.jpeg/283px-Cassandra1.jpeg)](https://upload.wikimedia.org/wikipedia/commons/thumb/4/42/Cassandra1.jpeg/283px-Cassandra1.jpeg) As many of you know Kubernetes is from the Ancient Greek: κυβερνήτης. This means helmsman, pilot, steersman, or ship master. So in order to keep track of race results, we needed a data store, and we choose Cassandra. Κασσάνδρα, Cassandra who was the daughter of King of Priam and Queen Hecuba of Troy. With multiple references to the ancient Greek language, we thought it would be appropriate to race ancient Greek monsters. @@ -62,7 +62,7 @@ So back to our races! -As we have mentioned, Cassandra was a perfect candidate to deploy via a Pet Set. A Pet Set is much like a [Replica Controller](http://kubernetes.io/docs/user-guide/replication-controller/) with a few new bells and whistles. Here's an example YAML manifest: +As we have mentioned, Cassandra was a perfect candidate to deploy via a Pet Set. A Pet Set is much like a [Replica Controller](/docs/user-guide/replication-controller/) with a few new bells and whistles. Here's an example YAML manifest: @@ -367,7 +367,7 @@ Yes we deployed 1,000 pets, but one really did not want to join the party! Techn - The source code for the demo is available on [GitHub](https://github.com/k8s-for-greeks/gpmr): (Pet Set examples will be merged into the Kubernetes Cassandra Examples). -- More information about [Jobs](http://kubernetes.io/docs/user-guide/jobs/) +- More information about [Jobs](/docs/user-guide/jobs/) - [Documentation for Pet Set](https://github.com/kubernetes/kubernetes.github.io/blob/release-1.3/docs/user-guide/petset.md) - Image credits: Cassandra [image](https://commons.wikimedia.org/wiki/File:Cassandra1.jpeg) and Cyclops [image](https://commons.wikimedia.org/wiki/File:Polyphemus.gif) diff --git a/content/en/blog/_posts/2016-07-00-stateful-applications-in-containers-kubernetes.md b/content/en/blog/_posts/2016-07-00-stateful-applications-in-containers-kubernetes.md index c15dea8502..8546b0b9c5 100644 --- a/content/en/blog/_posts/2016-07-00-stateful-applications-in-containers-kubernetes.md +++ b/content/en/blog/_posts/2016-07-00-stateful-applications-in-containers-kubernetes.md @@ -15,7 +15,7 @@ You may have [heard me say before](https://www.diamanti.com/blog/the-next-great- Beyond stateless containers like web servers (so-called “cattle” because they are interchangeable), users are increasingly deploying stateful workloads with containers to benefit from “build once, run anywhere” and to improve bare metal efficiency/utilization. These “pets” (so-called because each requires special handling) bring new requirements including longer life cycle, configuration dependencies, stateful failover, and performance sensitivity. Container orchestration must address these needs to successfully deploy and scale apps. -Enter [Pet Set](http://kubernetes.io/docs/user-guide/petset/), a new object in Kubernetes 1.3 for improved stateful application support. Pet Set sequences through the startup phase of each database replica (for example), ensuring orderly master/slave configuration. Pet Set also simplifies service discovery by leveraging ubiquitous DNS SRV records, a well-recognized and long-understood mechanism. +Enter [Pet Set](/docs/user-guide/petset/), a new object in Kubernetes 1.3 for improved stateful application support. Pet Set sequences through the startup phase of each database replica (for example), ensuring orderly master/slave configuration. Pet Set also simplifies service discovery by leveraging ubiquitous DNS SRV records, a well-recognized and long-understood mechanism. Diamanti’s [FlexVolume contribution](https://github.com/kubernetes/kubernetes/pull/13840) to Kubernetes enables stateful workloads by providing persistent volumes with low-latency storage and guaranteed performance, including enforced quality-of-service from container to media. diff --git a/content/en/blog/_posts/2016-08-00-Challenges-Remotely-Managed-Onpremise-Kubernetes-Cluster.md b/content/en/blog/_posts/2016-08-00-Challenges-Remotely-Managed-Onpremise-Kubernetes-Cluster.md index 566a6e4911..e882c5191a 100644 --- a/content/en/blog/_posts/2016-08-00-Challenges-Remotely-Managed-Onpremise-Kubernetes-Cluster.md +++ b/content/en/blog/_posts/2016-08-00-Challenges-Remotely-Managed-Onpremise-Kubernetes-Cluster.md @@ -37,7 +37,7 @@ The first time one or more nodes are attached to a cluster, PMK configures the n **Containerized kubelet?** -Another hurdle we encountered resulted from our original decision to run kubelet as recommended by the [Multi-node Docker Deployment Guide](http://kubernetes.io/docs/getting-started-guides/docker-multinode/). We discovered that this approach introduces complexities that led to many difficult-to-troubleshoot bugs that were sensitive to the combined versions of Kubernetes, Docker, and the node OS. Example: kubelet’s need to mount directories containing secrets into containers to support the [Service Accounts](http://kubernetes.io/docs/user-guide/service-accounts/) mechanism. It turns out that [doing this from inside of a container is tricky](https://github.com/kubernetes/kubernetes/issues/6848), and requires a [complex sequence of steps](https://github.com/kubernetes/kubernetes/blob/release-1.0/pkg/util/mount/nsenter_mount.go#L37) that turned out to be fragile. After fixing a continuing stream of issues, we finally decided to run kubelet as a native program on the host OS, resulting in significantly better stability. +Another hurdle we encountered resulted from our original decision to run kubelet as recommended by the [Multi-node Docker Deployment Guide](/docs/getting-started-guides/docker-multinode/). We discovered that this approach introduces complexities that led to many difficult-to-troubleshoot bugs that were sensitive to the combined versions of Kubernetes, Docker, and the node OS. Example: kubelet’s need to mount directories containing secrets into containers to support the [Service Accounts](/docs/user-guide/service-accounts/) mechanism. It turns out that [doing this from inside of a container is tricky](https://github.com/kubernetes/kubernetes/issues/6848), and requires a [complex sequence of steps](https://github.com/kubernetes/kubernetes/blob/release-1.0/pkg/util/mount/nsenter_mount.go#L37) that turned out to be fragile. After fixing a continuing stream of issues, we finally decided to run kubelet as a native program on the host OS, resulting in significantly better stability. **Overcoming networking hurdles** diff --git a/content/en/blog/_posts/2016-08-00-Kubernetes-Namespaces-Use-Cases-Insights.md b/content/en/blog/_posts/2016-08-00-Kubernetes-Namespaces-Use-Cases-Insights.md index 9b6786fda6..7b05c1f74c 100644 --- a/content/en/blog/_posts/2016-08-00-Kubernetes-Namespaces-Use-Cases-Insights.md +++ b/content/en/blog/_posts/2016-08-00-Kubernetes-Namespaces-Use-Cases-Insights.md @@ -13,11 +13,11 @@ _[Who's on First?](https://www.youtube.com/watch?v=kTcRRaXV-fg) by Abbott and Co **Introduction** -Kubernetes is a system with several concepts. Many of these concepts get manifested as “objects” in the RESTful API (often called “resources” or “kinds”). One of these concepts is [Namespaces](http://kubernetes.io/docs/user-guide/namespaces/). In Kubernetes, Namespaces are the way to partition a single Kubernetes cluster into multiple virtual clusters. In this post we’ll highlight examples of how our customers are using Namespaces.  +Kubernetes is a system with several concepts. Many of these concepts get manifested as “objects” in the RESTful API (often called “resources” or “kinds”). One of these concepts is [Namespaces](/docs/user-guide/namespaces/). In Kubernetes, Namespaces are the way to partition a single Kubernetes cluster into multiple virtual clusters. In this post we’ll highlight examples of how our customers are using Namespaces.  But first, a metaphor: Namespaces are like human family names. A family name, e.g. Wong, identifies a family unit. Within the Wong family, one of its members, e.g. Sam Wong, is readily identified as just “Sam” by the family. Outside of the family, and to avoid “Which Sam?” problems, Sam would usually be referred to as “Sam Wong”, perhaps even “Sam Wong from San Francisco”.   -Namespaces are a logical partitioning capability that enable one Kubernetes cluster to be used by multiple users, teams of users, or a single user with multiple applications without concern for undesired interaction. Each user, team of users, or application may exist within its Namespace, isolated from every other user of the cluster and operating as if it were the sole user of the cluster. (Furthermore, [Resource Quotas](http://kubernetes.io/docs/admin/resourcequota/) provide the ability to allocate a subset of a Kubernetes cluster’s resources to a Namespace.) +Namespaces are a logical partitioning capability that enable one Kubernetes cluster to be used by multiple users, teams of users, or a single user with multiple applications without concern for undesired interaction. Each user, team of users, or application may exist within its Namespace, isolated from every other user of the cluster and operating as if it were the sole user of the cluster. (Furthermore, [Resource Quotas](/docs/admin/resourcequota/) provide the ability to allocate a subset of a Kubernetes cluster’s resources to a Namespace.) For all but the most trivial uses of Kubernetes, you will benefit by using Namespaces. In this post, we’ll cover the most common ways that we’ve seen Kubernetes users on Google Cloud Platform use Namespaces, but our list is not exhaustive and we’d be interested to learn other examples from you. @@ -125,7 +125,7 @@ You may wish to, but you cannot create a hierarchy of namespaces. Namespaces can -Namespaces are easy to create and use but it’s also easy to deploy code inadvertently into the wrong namespace. Good DevOps hygiene suggests documenting and automating processes where possible and this will help. The other way to avoid using the wrong namespace is to set a [kubectl context](http://kubernetes.io/docs/user-guide/kubectl/kubectl_config_set-context/).  +Namespaces are easy to create and use but it’s also easy to deploy code inadvertently into the wrong namespace. Good DevOps hygiene suggests documenting and automating processes where possible and this will help. The other way to avoid using the wrong namespace is to set a [kubectl context](/docs/user-guide/kubectl/kubectl_config_set-context/).  diff --git a/content/en/blog/_posts/2016-08-00-Security-Best-Practices-Kubernetes-Deployment.md b/content/en/blog/_posts/2016-08-00-Security-Best-Practices-Kubernetes-Deployment.md index 28b9a2ccb7..ce04594e55 100644 --- a/content/en/blog/_posts/2016-08-00-Security-Best-Practices-Kubernetes-Deployment.md +++ b/content/en/blog/_posts/2016-08-00-Security-Best-Practices-Kubernetes-Deployment.md @@ -4,7 +4,7 @@ date: 2016-08-31 slug: security-best-practices-kubernetes-deployment url: /blog/2016/08/Security-Best-Practices-Kubernetes-Deployment --- -_Note: some of the recommendations in this post are no longer current. Current cluster hardening options are described in this [documentation](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/)._ +_Note: some of the recommendations in this post are no longer current. Current cluster hardening options are described in this [documentation](/docs/tasks/administer-cluster/securing-a-cluster/)._ _Editor’s note: today’s post is by Amir Jerbi and Michael Cherny of Aqua Security, describing security best practices for Kubernetes deployments, based on data they’ve collected from various use-cases seen in both on-premises and cloud deployments._ @@ -32,7 +32,7 @@ There is work in progress being done in Kubernetes for image authorization plugi **Limit Direct Access to Kubernetes Nodes** You should limit SSH access to Kubernetes nodes, reducing the risk for unauthorized access to host resource. Instead you should ask users to use "kubectl exec", which will provide direct access to the container environment without the ability to access the host. -You can use Kubernetes [Authorization Plugins](http://kubernetes.io/docs/reference/access-authn-authz/authorization/) to further control user access to resources. This allows defining fine-grained-access control rules for specific namespace, containers and operations. +You can use Kubernetes [Authorization Plugins](/docs/reference/access-authn-authz/authorization/) to further control user access to resources. This allows defining fine-grained-access control rules for specific namespace, containers and operations. **Create Administrative Boundaries between Resources** Limiting the scope of user permissions can reduce the impact of mistakes or malicious activities. A Kubernetes namespace allows you to partition created resources into logically named groups. Resources created in one namespace can be hidden from other namespaces. By default, each resource created by a user in Kubernetes cluster runs in a default namespace, called default. You can create additional namespaces and attach resources and users to them. You can use Kubernetes Authorization plugins to create policies that segregate access to namespace resources between different users. @@ -203,11 +203,11 @@ spec: -Reference [here](http://kubernetes.io/docs/api-reference/v1/definitions/#_v1_podsecuritycontext). +Reference [here](/docs/api-reference/v1/definitions/#_v1_podsecuritycontext). -In case you are running containers with elevated privileges (--privileged) you should consider using the “DenyEscalatingExec” admission control. This control denies exec and attach commands to pods that run with escalated privileges that allow host access. This includes pods that run as privileged, have access to the host IPC namespace, and have access to the host PID namespace. For more details on admission controls, see the Kubernetes [documentation](http://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/). +In case you are running containers with elevated privileges (--privileged) you should consider using the “DenyEscalatingExec” admission control. This control denies exec and attach commands to pods that run with escalated privileges that allow host access. This includes pods that run as privileged, have access to the host IPC namespace, and have access to the host PID namespace. For more details on admission controls, see the Kubernetes [documentation](/docs/reference/access-authn-authz/admission-controllers/). diff --git a/content/en/blog/_posts/2016-08-00-Stateful-Applications-Using-Kubernetes-Datera.md b/content/en/blog/_posts/2016-08-00-Stateful-Applications-Using-Kubernetes-Datera.md index dfb9930c3d..e945828050 100644 --- a/content/en/blog/_posts/2016-08-00-Stateful-Applications-Using-Kubernetes-Datera.md +++ b/content/en/blog/_posts/2016-08-00-Stateful-Applications-Using-Kubernetes-Datera.md @@ -8,9 +8,9 @@ _Editor’s note: today’s guest post is by Shailesh Mittal, Software Architect **Introduction** -Persistent volumes in Kubernetes are foundational as customers move beyond stateless workloads to run stateful applications. While Kubernetes has supported stateful applications such as MySQL, Kafka, Cassandra, and Couchbase for a while, the introduction of Pet Sets has significantly improved this support. In particular, the procedure to sequence the provisioning and startup, the ability to scale and associate durably by [Pet Sets](http://kubernetes.io/docs/user-guide/petset/) has provided the ability to automate to scale the “Pets” (applications that require consistent handling and durable placement). +Persistent volumes in Kubernetes are foundational as customers move beyond stateless workloads to run stateful applications. While Kubernetes has supported stateful applications such as MySQL, Kafka, Cassandra, and Couchbase for a while, the introduction of Pet Sets has significantly improved this support. In particular, the procedure to sequence the provisioning and startup, the ability to scale and associate durably by [Pet Sets](/docs/user-guide/petset/) has provided the ability to automate to scale the “Pets” (applications that require consistent handling and durable placement). -Datera, elastic block storage for cloud deployments, has [seamlessly integrated with Kubernetes](http://datera.io/blog-library/8/19/datera-simplifies-stateful-containers-on-kubernetes-13) through the [FlexVolume](http://kubernetes.io/docs/user-guide/volumes/#flexvolume) framework. Based on the first principles of containers, Datera allows application resource provisioning to be decoupled from the underlying physical infrastructure. This brings clean contracts (aka, no dependency or direct knowledge of the underlying physical infrastructure), declarative formats, and eventually portability to stateful applications. +Datera, elastic block storage for cloud deployments, has [seamlessly integrated with Kubernetes](http://datera.io/blog-library/8/19/datera-simplifies-stateful-containers-on-kubernetes-13) through the [FlexVolume](/docs/user-guide/volumes/#flexvolume) framework. Based on the first principles of containers, Datera allows application resource provisioning to be decoupled from the underlying physical infrastructure. This brings clean contracts (aka, no dependency or direct knowledge of the underlying physical infrastructure), declarative formats, and eventually portability to stateful applications. While Kubernetes allows for great flexibility to define the underlying application infrastructure through yaml configurations, Datera allows for that configuration to be passed to the storage infrastructure to provide persistence. Through the notion of Datera AppTemplates, in a Kubernetes environment, stateful applications can be automated to scale. @@ -22,7 +22,7 @@ While Kubernetes allows for great flexibility to define the underlying applicati -Persistent storage is defined using the Kubernetes [PersistentVolume](http://kubernetes.io/docs/user-guide/persistent-volumes/#persistent-volumes) subsystem. PersistentVolumes are volume plugins and define volumes that live independently of the lifecycle of the pod that is using it. They are implemented as NFS, iSCSI, or by cloud provider specific storage system. Datera has developed a volume plugin for PersistentVolumes that can provision iSCSI block storage on the Datera Data Fabric for Kubernetes pods. +Persistent storage is defined using the Kubernetes [PersistentVolume](/docs/user-guide/persistent-volumes/#persistent-volumes) subsystem. PersistentVolumes are volume plugins and define volumes that live independently of the lifecycle of the pod that is using it. They are implemented as NFS, iSCSI, or by cloud provider specific storage system. Datera has developed a volume plugin for PersistentVolumes that can provision iSCSI block storage on the Datera Data Fabric for Kubernetes pods. diff --git a/content/en/blog/_posts/2016-09-00-High-Performance-Network-Policies-Kubernetes.md b/content/en/blog/_posts/2016-09-00-High-Performance-Network-Policies-Kubernetes.md index 3b6c46e37f..bc21d1edaa 100644 --- a/content/en/blog/_posts/2016-09-00-High-Performance-Network-Policies-Kubernetes.md +++ b/content/en/blog/_posts/2016-09-00-High-Performance-Network-Policies-Kubernetes.md @@ -20,7 +20,7 @@ Since the release of Kubernetes 1.3 back in July, users have been able to define -What does this mean for the application developer? At last, Kubernetes has gained the necessary capabilities to provide "[defence in depth](https://en.wikipedia.org/wiki/Defense_in_depth_(computing))". Traffic can be segmented and different parts of your application can be secured independently. For example, you can very easily protect each of your services via specific network policies: All the pods identified by a [Replication Controller](http://kubernetes.io/docs/user-guide/replication-controller/) behind a service are already identified by a specific label. Therefore, you can use this same label to apply a policy to those pods. +What does this mean for the application developer? At last, Kubernetes has gained the necessary capabilities to provide "[defence in depth](https://en.wikipedia.org/wiki/Defense_in_depth_(computing))". Traffic can be segmented and different parts of your application can be secured independently. For example, you can very easily protect each of your services via specific network policies: All the pods identified by a [Replication Controller](/docs/user-guide/replication-controller/) behind a service are already identified by a specific label. Therefore, you can use this same label to apply a policy to those pods. diff --git a/content/en/blog/_posts/2016-09-00-How-Qbox-Saved-50-Percent-On-Aws-Bills.md b/content/en/blog/_posts/2016-09-00-How-Qbox-Saved-50-Percent-On-Aws-Bills.md index 917144f835..98ca282479 100644 --- a/content/en/blog/_posts/2016-09-00-How-Qbox-Saved-50-Percent-On-Aws-Bills.md +++ b/content/en/blog/_posts/2016-09-00-How-Qbox-Saved-50-Percent-On-Aws-Bills.md @@ -22,7 +22,7 @@ To run performance tests, we had to find a system that could manage networked co The performance improvement we observed was due to the number of containers we could “pack” on a single machine. Ironically, we began the Docker experiment wanting to avoid “noisy neighbor,” which we assumed was inevitable when several containers shared the same VM. However, that isolation also acted as a bottleneck, both in performance and cost. To use a real-world example, If a machine has 2 cores and you need 3 cores, you have a problem. It’s rare to come across a public-cloud VM with 3 cores, so the typical solution is to buy 4 cores and not utilize them fully. -This is where Kubernetes really starts to shine. It has the concept of [requests and limits](http://kubernetes.io/docs/user-guide/compute-resources/), which provides granular control over resource sharing. Multiple containers can share an underlying host VM without the fear of “noisy neighbors”. They can request exclusive control over an amount of RAM, for example, and they can define a limit in anticipation of overflow. It’s practical, performant, and cost-effective multi-tenancy. We were able to deliver the best of both the single-tenant and multi-tenant worlds. +This is where Kubernetes really starts to shine. It has the concept of [requests and limits](/docs/user-guide/compute-resources/), which provides granular control over resource sharing. Multiple containers can share an underlying host VM without the fear of “noisy neighbors”. They can request exclusive control over an amount of RAM, for example, and they can define a limit in anticipation of overflow. It’s practical, performant, and cost-effective multi-tenancy. We were able to deliver the best of both the single-tenant and multi-tenant worlds. **Kubernetes + Supergiant** We built [Supergiant](https://supergiant.io/) originally for our own Elasticsearch customers. Supergiant solves Kubernetes complications by allowing pre-packaged and re-deployable application topologies. In more specific terms, Supergiant lets you use Components, which are somewhat similar to a microservice. Components represent an almost-uniform set of Instances of software (e.g., Elasticsearch, MongoDB, your web application, etc.). They roll up all the various Kubernetes and cloud operations needed to deploy a complex topology into a compact entity that is easy to manage. diff --git a/content/en/blog/_posts/2016-09-00-How-We-Made-Kubernetes-Easy-To-Install.md b/content/en/blog/_posts/2016-09-00-How-We-Made-Kubernetes-Easy-To-Install.md index 1e46d6ace1..5e7cb13756 100644 --- a/content/en/blog/_posts/2016-09-00-How-We-Made-Kubernetes-Easy-To-Install.md +++ b/content/en/blog/_posts/2016-09-00-How-We-Made-Kubernetes-Easy-To-Install.md @@ -16,26 +16,26 @@ There are three stages in setting up a Kubernetes cluster, and we decided to foc 3. **Add-ons** : installing necessary cluster add-ons like DNS and monitoring services, a pod network, etc We realized early on that there's enormous variety in the way that users want to **provision** their machines. -They use lots of different cloud providers, private clouds, bare metal, or even Raspberry Pi's, and almost always have their own preferred tools for automating provisioning machines: Terraform or CloudFormation, Chef, Puppet or Ansible, or even PXE booting bare metal. So we made an important decision: **kubeadm would not provision machines**. Instead, the only assumption it makes is that the user has some [computers running Linux](http://kubernetes.io/docs/getting-started-guides/kubeadm/#prerequisites). +They use lots of different cloud providers, private clouds, bare metal, or even Raspberry Pi's, and almost always have their own preferred tools for automating provisioning machines: Terraform or CloudFormation, Chef, Puppet or Ansible, or even PXE booting bare metal. So we made an important decision: **kubeadm would not provision machines**. Instead, the only assumption it makes is that the user has some [computers running Linux](/docs/getting-started-guides/kubeadm/#prerequisites). Another important constraint was we didn't want to just build another tool that "configures Kubernetes from the outside, by poking all the bits into place". There are many external projects out there for doing this, but we wanted to aim higher. We chose to actually improve the Kubernetes core itself to make it easier to install. Luckily, a lot of the groundwork for making this happen had already been started. We realized that if we made Kubernetes insanely easy to install manually, it should be obvious to users how to automate that process using any tooling. -So, enter [kubeadm](http://kubernetes.io/docs/getting-started-guides/kubeadm/). It has no infrastructure dependencies, and satisfies the requirements above. It's easy to use and should be easy to automate. It's still in **alpha** , but it works like this: +So, enter [kubeadm](/docs/getting-started-guides/kubeadm/). It has no infrastructure dependencies, and satisfies the requirements above. It's easy to use and should be easy to automate. It's still in **alpha** , but it works like this: - You install Docker and the official Kubernetes packages for you distribution. - Select a master host, run kubeadm init. - This sets up the control plane and outputs a kubeadm join [...] command which includes a secure token. - On each host selected to be a worker node, run the kubeadm join [...] command from above. - Install a pod network. [Weave Net](https://github.com/weaveworks/weave-kube) is a great place to start here. Install it using just kubectl apply -f https://git.io/weave-kube -Presto! You have a working Kubernetes cluster! [Try kubeadm today](http://kubernetes.io/docs/getting-started-guides/kubeadm/).  +Presto! You have a working Kubernetes cluster! [Try kubeadm today](/docs/getting-started-guides/kubeadm/).  For a video walkthrough, check this out: -Follow the [kubeadm getting started guide](http://kubernetes.io/docs/getting-started-guides/kubeadm/) to try it yourself, and please give us [feedback on GitHub](https://github.com/kubernetes/kubernetes/issues/new), mentioning **@kubernetes/sig-cluster-lifecycle**! +Follow the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/) to try it yourself, and please give us [feedback on GitHub](https://github.com/kubernetes/kubernetes/issues/new), mentioning **@kubernetes/sig-cluster-lifecycle**! Finally, I want to give a huge shout-out to so many people in the SIG-cluster-lifecycle, without whom this wouldn't have been possible. I'll mention just a few here: @@ -54,7 +54,7 @@ This truly has been an excellent cross-company and cross-timezone achievement, w _--[Luke Marsden](https://twitter.com/lmarsden), Head of Developer Experience at [Weaveworks](https://twitter.com/weaveworks)_ -- Try [kubeadm](http://kubernetes.io/docs/getting-started-guides/kubeadm/) to install Kubernetes today +- Try [kubeadm](/docs/getting-started-guides/kubeadm/) to install Kubernetes today - Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes)  - Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)  - Connect with the community on [Slack](http://slack.k8s.io/) diff --git a/content/en/blog/_posts/2016-09-00-Kubernetes-1-4-Making-It-Easy-To-Run-On-Kuberentes-Anywhere.md b/content/en/blog/_posts/2016-09-00-Kubernetes-1-4-Making-It-Easy-To-Run-On-Kuberentes-Anywhere.md index c40a925872..07efc8de42 100644 --- a/content/en/blog/_posts/2016-09-00-Kubernetes-1-4-Making-It-Easy-To-Run-On-Kuberentes-Anywhere.md +++ b/content/en/blog/_posts/2016-09-00-Kubernetes-1-4-Making-It-Easy-To-Run-On-Kuberentes-Anywhere.md @@ -17,38 +17,38 @@ Additional product highlights in this release include simplified cluster deploym **Cluster creation with two commands -** To get started with Kubernetes a user must provision nodes, install Kubernetes and bootstrap the cluster. A common request from users is to have an easy, portable way to do this on any cloud (public, private, or bare metal). -- Kubernetes 1.4 introduces ‘[kubeadm](http://kubernetes.io/docs/getting-started-guides/kubeadm/)’ which reduces bootstrapping to two commands, with no complex scripts involved. Once kubernetes is installed, kubeadm init starts the master while kubeadm join joins the nodes to the cluster. +- Kubernetes 1.4 introduces ‘[kubeadm](/docs/getting-started-guides/kubeadm/)’ which reduces bootstrapping to two commands, with no complex scripts involved. Once kubernetes is installed, kubeadm init starts the master while kubeadm join joins the nodes to the cluster. - Installation is also streamlined by packaging Kubernetes with its dependencies, for most major Linux distributions including Red Hat and Ubuntu Xenial. This means users can now install Kubernetes using familiar tools such as apt-get and yum. -- Add-on deployments, such as for an overlay network, can be reduced to one command by using a [DaemonSet](http://kubernetes.io/docs/admin/daemons/). -- Enabling this simplicity is a new certificates API and its use for kubelet [TLS bootstrap](http://kubernetes.io/docs/admin/master-node-communication/#kubelet-tls-bootstrap), as well as a new discovery API. +- Add-on deployments, such as for an overlay network, can be reduced to one command by using a [DaemonSet](/docs/admin/daemons/). +- Enabling this simplicity is a new certificates API and its use for kubelet [TLS bootstrap](/docs/admin/master-node-communication/#kubelet-tls-bootstrap), as well as a new discovery API. **Expanded stateful application support -** While cloud-native applications are built to run in containers, many existing applications need additional features to make it easy to adopt containers. Most commonly, these include stateful applications such as batch processing, databases and key-value stores. In Kubernetes 1.4, we have introduced a number of features simplifying the deployment of such applications, including:  -- [ScheduledJob](http://kubernetes.io/docs/user-guide/scheduled-jobs/) is introduced as Alpha so users can run batch jobs at regular intervals. +- [ScheduledJob](/docs/user-guide/scheduled-jobs/) is introduced as Alpha so users can run batch jobs at regular intervals. - Init-containers are Beta, addressing the need to run one or more containers before starting the main application, for example to sequence dependencies when starting a database or multi-tier app. -- [Dynamic PVC Provisioning](http://kubernetes.io/docs/user-guide/persistent-volumes/) moved to Beta. This feature now enables cluster administrators to expose multiple storage provisioners and allows users to select them using a new Storage Class API object.   +- [Dynamic PVC Provisioning](/docs/user-guide/persistent-volumes/) moved to Beta. This feature now enables cluster administrators to expose multiple storage provisioners and allows users to select them using a new Storage Class API object.   - Curated and pre-tested [Helm charts](https://github.com/kubernetes/charts) for common stateful applications such as MariaDB, MySQL and Jenkins will be available for one-command launches using version 2 of the Helm Package Manager. **Cluster federation API additions -** One of the most requested capabilities from our global customers has been the ability to build applications with clusters that span regions and clouds.  -- [Federated Replica Sets](http://kubernetes.io/docs/user-guide/federation/replicasets/) Beta - replicas can now span some or all clusters enabling cross region or cross cloud replication. The total federated replica count and relative cluster weights / replica counts are continually reconciled by a federated replica-set controller to ensure you have the pods you need in each region / cloud. -- Federated Services are now Beta, and [secrets](http://kubernetes.io/docs/user-guide/federation/secrets/), [events](http://kubernetes.io/docs/user-guide/federation/events) and [namespaces](http://kubernetes.io/docs/user-guide/federation/namespaces) have also been added to the federation API. -- [Federated Ingress](http://kubernetes.io/docs/user-guide/federation/federated-ingress/) Alpha - starting with Google Cloud Platform (GCP), users can create a single L7 globally load balanced VIP that spans services deployed across a federation of clusters within GCP. With Federated Ingress in GCP, external clients point to a single IP address and are sent to the closest cluster with usable capacity in any region or zone of the federation in GCP. +- [Federated Replica Sets](/docs/user-guide/federation/replicasets/) Beta - replicas can now span some or all clusters enabling cross region or cross cloud replication. The total federated replica count and relative cluster weights / replica counts are continually reconciled by a federated replica-set controller to ensure you have the pods you need in each region / cloud. +- Federated Services are now Beta, and [secrets](/docs/user-guide/federation/secrets/), [events](/docs/user-guide/federation/events) and [namespaces](/docs/user-guide/federation/namespaces) have also been added to the federation API. +- [Federated Ingress](/docs/user-guide/federation/federated-ingress/) Alpha - starting with Google Cloud Platform (GCP), users can create a single L7 globally load balanced VIP that spans services deployed across a federation of clusters within GCP. With Federated Ingress in GCP, external clients point to a single IP address and are sent to the closest cluster with usable capacity in any region or zone of the federation in GCP. **Container security support -** Administrators of multi-tenant clusters require the ability to provide varying sets of permissions among tenants, infrastructure components, and end users of the system. -- [Pod Security Policy](http://kubernetes.io/docs/user-guide/pod-security-policy/) is a new object that enables cluster administrators to control the creation and validation of security contexts for pods/containers. Admins can associate service accounts, groups, and users with a set of constraints to define a security context. -- [AppArmor](http://kubernetes.io/docs/admin/apparmor/) support is added, enabling admins to run a more secure deployment, and provide better auditing and monitoring of their systems. Users can configure a container to run in an AppArmor profile by setting a single field. +- [Pod Security Policy](/docs/user-guide/pod-security-policy/) is a new object that enables cluster administrators to control the creation and validation of security contexts for pods/containers. Admins can associate service accounts, groups, and users with a set of constraints to define a security context. +- [AppArmor](/docs/admin/apparmor/) support is added, enabling admins to run a more secure deployment, and provide better auditing and monitoring of their systems. Users can configure a container to run in an AppArmor profile by setting a single field. **Infrastructure enhancements - ** We continue adding to the scheduler, storage and client capabilities in Kubernetes based on user and ecosystem needs. -- Scheduler - introducing [inter-pod affinity and anti-affinity](http://kubernetes.io/docs/user-guide/node-selection/) Alpha for users who want to customize how Kubernetes co-locates or spreads their pods. Also [priority scheduling capability for cluster add-ons](http://kubernetes.io/docs/admin/rescheduler/#guaranteed-scheduling-of-critical-add-on-pods) such as DNS, Heapster, and the Kube Dashboard. +- Scheduler - introducing [inter-pod affinity and anti-affinity](/docs/user-guide/node-selection/) Alpha for users who want to customize how Kubernetes co-locates or spreads their pods. Also [priority scheduling capability for cluster add-ons](/docs/admin/rescheduler/#guaranteed-scheduling-of-critical-add-on-pods) such as DNS, Heapster, and the Kube Dashboard. - Disruption SLOs - Pod Disruption Budget is introduced to limit impact of pods deleted by cluster management operations (such as node upgrade) at any one time. -- Storage - New [volume plugins](http://kubernetes.io/docs/user-guide/volumes/) for Quobyte and Azure Data Disk have been added. +- Storage - New [volume plugins](/docs/user-guide/volumes/) for Quobyte and Azure Data Disk have been added. - Clients - Swagger 2.0 support is added, enabling non-Go clients. **Kubernetes Dashboard UI -** lastly, a great looking Kubernetes [Dashboard UI](https://github.com/kubernetes/dashboard#kubernetes-dashboard) with 90% CLI parity for at-a-glance management. @@ -56,7 +56,7 @@ Additional product highlights in this release include simplified cluster deploym For a complete list of updates see the [release notes](https://github.com/kubernetes/kubernetes/pull/33410) on GitHub. Apart from features the most impressive aspect of Kubernetes development is the community of contributors. This is particularly true of the 1.4 release, the full breadth of which will unfold in upcoming weeks. **Availability** -Kubernetes 1.4 is available for download at [get.k8s.io](http://get.k8s.io/) and via the open source repository hosted on [GitHub](http://github.com/kubernetes/kubernetes). To get started with Kubernetes try the [Hello World app](http://kubernetes.io/docs/hellonode/). +Kubernetes 1.4 is available for download at [get.k8s.io](http://get.k8s.io/) and via the open source repository hosted on [GitHub](http://github.com/kubernetes/kubernetes). To get started with Kubernetes try the [Hello World app](/docs/hellonode/). To get involved with the project, join the [weekly community meeting](https://groups.google.com/forum/#!forum/kubernetes-community-video-chat) or start contributing to the project here (marked help).  @@ -80,8 +80,3 @@ We’re very grateful to our community of over 900 contributors who contributed Thank you for your support!  _-- Aparna Sinha, Product Manager, Google_ - - - - - diff --git a/content/en/blog/_posts/2016-10-00-Dynamic-Provisioning-And-Storage-In-Kubernetes.md b/content/en/blog/_posts/2016-10-00-Dynamic-Provisioning-And-Storage-In-Kubernetes.md index 2d9e456fe3..50800b1f6d 100644 --- a/content/en/blog/_posts/2016-10-00-Dynamic-Provisioning-And-Storage-In-Kubernetes.md +++ b/content/en/blog/_posts/2016-10-00-Dynamic-Provisioning-And-Storage-In-Kubernetes.md @@ -13,11 +13,11 @@ The alpha version of dynamic provisioning only allowed a single, hard-coded prov Although the alpha version of the feature was limited in utility, it allowed us to “get some miles” on the idea, and helped determine the direction we wanted to take. -The beta version of dynamic provisioning, new in Kubernetes 1.4, introduces a [new API object](http://kubernetes.io/docs/user-guide/persistent-volumes/#storageclasses), StorageClass. Multiple StorageClass objects can be defined each specifying a volume plugin (aka provisioner) to use to provision a volume and the set of parameters to pass to that provisioner when provisioning. This design allows cluster administrators to define and expose multiple flavors of storage (from the same or different storage systems) within a cluster, each with a custom set of parameters. This design also ensures that end users don’t have to worry about the complexity and nuances of how storage is provisioned, but still have the ability to select from multiple storage options. +The beta version of dynamic provisioning, new in Kubernetes 1.4, introduces a [new API object](/docs/user-guide/persistent-volumes/#storageclasses), StorageClass. Multiple StorageClass objects can be defined each specifying a volume plugin (aka provisioner) to use to provision a volume and the set of parameters to pass to that provisioner when provisioning. This design allows cluster administrators to define and expose multiple flavors of storage (from the same or different storage systems) within a cluster, each with a custom set of parameters. This design also ensures that end users don’t have to worry about the complexity and nuances of how storage is provisioned, but still have the ability to select from multiple storage options. **How Do I use It?** -Below is an example of how a cluster administrator would expose two tiers of storage, and how a user would select and use one. For more details, see the [reference](http://kubernetes.io/docs/user-guide/persistent-volumes/#storageclasses) and [example](https://github.com/kubernetes/kubernetes/tree/release-1.4/examples/experimental/persistent-volume-provisioning) docs. +Below is an example of how a cluster administrator would expose two tiers of storage, and how a user would select and use one. For more details, see the [reference](/docs/user-guide/persistent-volumes/#storageclasses) and [example](https://github.com/kubernetes/kubernetes/tree/release-1.4/examples/experimental/persistent-volume-provisioning) docs. **Admin Configuration** diff --git a/content/en/blog/_posts/2016-10-00-Globally-Distributed-Services-Kubernetes-Cluster-Federation.md b/content/en/blog/_posts/2016-10-00-Globally-Distributed-Services-Kubernetes-Cluster-Federation.md index 3f7880d00a..4091b2b383 100644 --- a/content/en/blog/_posts/2016-10-00-Globally-Distributed-Services-Kubernetes-Cluster-Federation.md +++ b/content/en/blog/_posts/2016-10-00-Globally-Distributed-Services-Kubernetes-Cluster-Federation.md @@ -10,15 +10,15 @@ In Kubernetes 1.3, we announced Kubernetes Cluster Federation and introduced the In the latest release, [Kubernetes 1.4](https://kubernetes.io/blog/2016/09/kubernetes-1.4-making-it-easy-to-run-on-kuberentes-anywhere), we've extended Cluster Federation to support Replica Sets, Secrets, Namespaces and Ingress objects. This means that you no longer need to deploy and manage these objects individually in each of your federated clusters. Just create them once in the federation, and have its built-in controllers automatically handle that for you. -[**Federated Replica Sets**](http://kubernetes.io/docs/user-guide/federation/replicasets/) leverage the same configuration as non-federated Kubernetes Replica Sets and automatically distribute Pods across one or more federated clusters. By default, replicas are evenly distributed across all clusters, but for cases where that is not the desired behavior, we've introduced Replica Set preferences, which allow replicas to be distributed across only some clusters, or in non-equal proportions ([define annotations](https://github.com/kubernetes/kubernetes/blob/master/federation/apis/federation/types.go#L114)). +[**Federated Replica Sets**](/docs/user-guide/federation/replicasets/) leverage the same configuration as non-federated Kubernetes Replica Sets and automatically distribute Pods across one or more federated clusters. By default, replicas are evenly distributed across all clusters, but for cases where that is not the desired behavior, we've introduced Replica Set preferences, which allow replicas to be distributed across only some clusters, or in non-equal proportions ([define annotations](https://github.com/kubernetes/kubernetes/blob/master/federation/apis/federation/types.go#L114)). -Starting with Google Cloud Platform (GCP), we’ve introduced [**Federated Ingress**](http://kubernetes.io/docs/user-guide/federation/federated-ingress/) as a Kubernetes 1.4 alpha feature which enables external clients point to a single IP address and have requests sent to the closest cluster with usable capacity in any region, zone of the Federation. +Starting with Google Cloud Platform (GCP), we’ve introduced [**Federated Ingress**](/docs/user-guide/federation/federated-ingress/) as a Kubernetes 1.4 alpha feature which enables external clients point to a single IP address and have requests sent to the closest cluster with usable capacity in any region, zone of the Federation. -[**Federated Secrets**](http://kubernetes.io/docs/user-guide/federation/secrets/) automatically create and manage secrets across all clusters in a Federation, automatically ensuring that these are kept globally consistent and up-to-date, even if some clusters are offline when the original updates are applied. +[**Federated Secrets**](/docs/user-guide/federation/secrets/) automatically create and manage secrets across all clusters in a Federation, automatically ensuring that these are kept globally consistent and up-to-date, even if some clusters are offline when the original updates are applied. -[**Federated Namespaces**](http://kubernetes.io/docs/user-guide/federation/namespaces/) are similar to the traditional [Kubernetes Namespaces](http://kubernetes.io/docs/user-guide/namespaces/) providing the same functionality. Creating them in the Federation control plane ensures that they are synchronized across all the clusters in Federation. +[**Federated Namespaces**](/docs/user-guide/federation/namespaces/) are similar to the traditional [Kubernetes Namespaces](/docs/user-guide/namespaces/) providing the same functionality. Creating them in the Federation control plane ensures that they are synchronized across all the clusters in Federation. -[**Federated Events**](http://kubernetes.io/docs/user-guide/federation/events/) are similar to the traditional Kubernetes Events providing the same functionality. Federation Events are stored only in Federation control plane and are not passed on to the underlying kubernetes clusters. +[**Federated Events**](/docs/user-guide/federation/events/) are similar to the traditional Kubernetes Events providing the same functionality. Federation Events are stored only in Federation control plane and are not passed on to the underlying kubernetes clusters. Let’s walk through how all this stuff works. We’re going to provision 3 clusters per region, spanning 3 continents (Europe, North America and Asia). @@ -68,7 +68,7 @@ gce-us-central1-c Ready 39s -In our example, we’ll be deploying the service and ingress object using the federated control plane. The [ConfigMap](http://kubernetes.io/docs/user-guide/configmap/) object isn’t currently supported by Federation, so we’ll be deploying it manually in each of the underlying Federation clusters. Our cluster deployment will look as follows: +In our example, we’ll be deploying the service and ingress object using the federated control plane. The [ConfigMap](/docs/user-guide/configmap/) object isn’t currently supported by Federation, so we’ll be deploying it manually in each of the underlying Federation clusters. Our cluster deployment will look as follows: @@ -113,7 +113,7 @@ Session Affinity: None -Let’s now create a Federated Ingress. Federated Ingresses are created in much that same way as traditional [Kubernetes Ingresses](http://kubernetes.io/docs/user-guide/ingress/): by making an API call which specifies the desired properties of your logical ingress point. In the case of Federated Ingress, this API call is directed to the Federation API endpoint, rather than a Kubernetes cluster API endpoint. The API for Federated Ingress is 100% compatible with the API for traditional Kubernetes Services. +Let’s now create a Federated Ingress. Federated Ingresses are created in much that same way as traditional [Kubernetes Ingresses](/docs/user-guide/ingress/): by making an API call which specifies the desired properties of your logical ingress point. In the case of Federated Ingress, this API call is directed to the Federation API endpoint, rather than a Kubernetes cluster API endpoint. The API for Federated Ingress is 100% compatible with the API for traditional Kubernetes Services. diff --git a/content/en/blog/_posts/2016-10-00-Production-Kubernetes-Dashboard-UI-1-4-improvements_3.md b/content/en/blog/_posts/2016-10-00-Production-Kubernetes-Dashboard-UI-1-4-improvements_3.md index 5959e1d783..eb84069798 100644 --- a/content/en/blog/_posts/2016-10-00-Production-Kubernetes-Dashboard-UI-1-4-improvements_3.md +++ b/content/en/blog/_posts/2016-10-00-Production-Kubernetes-Dashboard-UI-1-4-improvements_3.md @@ -6,7 +6,7 @@ url: /blog/2016/10/Production-Kubernetes-Dashboard-UI-1.4-improvements_3 --- With the release of [Kubernetes 1.4](https://kubernetes.io/blog/2016/09/kubernetes-1.4-making-it-easy-to-run-on-kuberentes-anywhere) last week, Dashboard – the official web UI for Kubernetes – has a number of exciting updates and improvements of its own. The past three months have been busy ones for the Dashboard team, and we’re excited to share the resulting features of that effort here. If you’re not familiar with Dashboard, the [GitHub repo](https://github.com/kubernetes/dashboard#kubernetes-dashboard) is a great place to get started. -A quick recap before unwrapping our shiny new features: Dashboard was initially released March 2016. One of the focuses for Dashboard throughout its lifetime has been the onboarding experience; it’s a less intimidating way for Kubernetes newcomers to get started, and by showing multiple resources at once, it provides contextualization lacking in [kubectl](http://kubernetes.io/docs/user-guide/kubectl-overview/) (the CLI). After that initial release though, the product team realized that fine-tuning for a beginner audience was getting ahead of ourselves: there were still fundamental product requirements that Dashboard needed to satisfy in order to have a productive UX to onboard new users too. That became our mission for this release: closing the gap between Dashboard and kubectl by showing more resources, leveraging a web UI’s strengths in monitoring and troubleshooting, and architecting this all in a user friendly way. +A quick recap before unwrapping our shiny new features: Dashboard was initially released March 2016. One of the focuses for Dashboard throughout its lifetime has been the onboarding experience; it’s a less intimidating way for Kubernetes newcomers to get started, and by showing multiple resources at once, it provides contextualization lacking in [kubectl](/docs/user-guide/kubectl-overview/) (the CLI). After that initial release though, the product team realized that fine-tuning for a beginner audience was getting ahead of ourselves: there were still fundamental product requirements that Dashboard needed to satisfy in order to have a productive UX to onboard new users too. That became our mission for this release: closing the gap between Dashboard and kubectl by showing more resources, leveraging a web UI’s strengths in monitoring and troubleshooting, and architecting this all in a user friendly way. **Monitoring Graphs** Real time visualization is a strength that UI’s have over CLI’s, and with 1.4 we’re happy to capitalize on that capability with the introduction of real-time CPU and memory usage graphs for all workloads running on your cluster. Even with the numerous third-party solutions for monitoring, Dashboard should include at least some basic out-of-the box functionality in this area. Next up on the roadmap for graphs is extending the timespan the graph represents, adding drill-down capabilities to reveal more details, and improving the UX of correlating data between different graphs. @@ -49,7 +49,7 @@ Once in the relevant Namespace, I check out my Deployments to see if anything se ![](https://lh5.googleusercontent.com/rViAg6xFe219i7qxeBRU62-1SFBLI6VIg3pbU5HBmvIKsb3KJFr5RldP0vziVXao3u-hWM3EMvzTNnSFRQWCTViaQiVbAv_PTjd87s7GOZelroeL4gjcfFU3JljrOKKnWL3Wzy5c) -I realize we need to perform a rolling update to a newer version of that app that can handle the increased requests it’s evidently getting, so I update this Deployment’s image, which in turn creates a new [Replica Set](http://kubernetes.io/docs/user-guide/replicasets/). +I realize we need to perform a rolling update to a newer version of that app that can handle the increased requests it’s evidently getting, so I update this Deployment’s image, which in turn creates a new [Replica Set](/docs/user-guide/replicasets/). diff --git a/content/en/blog/_posts/2016-10-00-Tail-Kubernetes-With-Stern.md b/content/en/blog/_posts/2016-10-00-Tail-Kubernetes-With-Stern.md index 066c816002..ce2749f097 100644 --- a/content/en/blog/_posts/2016-10-00-Tail-Kubernetes-With-Stern.md +++ b/content/en/blog/_posts/2016-10-00-Tail-Kubernetes-With-Stern.md @@ -6,13 +6,13 @@ url: /blog/2016/10/Tail-Kubernetes-With-Stern --- _Editor’s note: today’s post is by Antti Kupila, Software Engineer, at Wercker, about building a tool to tail multiple pods and containers on Kubernetes._ -We love Kubernetes here at [Wercker](http://wercker.com/) and build all our infrastructure on top of it. When deploying anything you need to have good visibility to what's going on and logs are a first view into the inner workings of your application. Good old tail -f has been around for a long time and Kubernetes has this too, built right into [kubectl](http://kubernetes.io/docs/user-guide/kubectl-overview/). +We love Kubernetes here at [Wercker](http://wercker.com/) and build all our infrastructure on top of it. When deploying anything you need to have good visibility to what's going on and logs are a first view into the inner workings of your application. Good old tail -f has been around for a long time and Kubernetes has this too, built right into [kubectl](/docs/user-guide/kubectl-overview/). I should say that tail is by no means the tool to use for debugging issues but instead you should feed the logs into a more persistent place, such as [Elasticsearch](https://www.elastic.co/products/elasticsearch). However, there's still a place for tail where you need to quickly debug something or perhaps you don't have persistent logging set up yet (such as when developing an app in [Minikube](https://github.com/kubernetes/minikube)). **Multiple Pods** -Kubernetes has the concept of [Replication Controllers](http://kubernetes.io/docs/user-guide/replication-controller/) which ensure that n pods are running at the same time. This allows rolling updates and redundancy. Considering they're quite easy to set up there's really no reason not to do so. +Kubernetes has the concept of [Replication Controllers](/docs/user-guide/replication-controller/) which ensure that n pods are running at the same time. This allows rolling updates and redundancy. Considering they're quite easy to set up there's really no reason not to do so. However now there are multiple pods running and they all have a unique id. One issue here is that you'll need to know the exact pod id (kubectl get pods) but that changes every time a pod is created so you'll need to do this every time. Another consideration is the fact that Kubernetes load balances the traffic so you won't know at which pod the request ends up at. If you're tailing pod A but the traffic ends up at pod B you'll miss what happened. diff --git a/content/en/blog/_posts/2016-11-00-Skytap-Modernizing-Microservice-Architecture-With-Kubernetes.md b/content/en/blog/_posts/2016-11-00-Skytap-Modernizing-Microservice-Architecture-With-Kubernetes.md index 138cf9fd6d..340be12048 100644 --- a/content/en/blog/_posts/2016-11-00-Skytap-Modernizing-Microservice-Architecture-With-Kubernetes.md +++ b/content/en/blog/_posts/2016-11-00-Skytap-Modernizing-Microservice-Architecture-With-Kubernetes.md @@ -124,7 +124,7 @@ With dynamic reconfiguration of the network, the replication mechanics of Kubern - Build a load analysis and scaling service (easy, right?) - If load patterns match the configured triggers in the scaling service (for example, request rate or volume above certain bounds), issue: kubectl scale --replicas=COUNT rc NAME -This would allow us fine-grained control of autoscaling at the platform level, instead of from the applications themselves – but we’ll also evaluate [**Horizontal Pod Autoscaling**](http://kubernetes.io/docs/user-guide/horizontal-pod-autoscaling/) in Kubernetes; which may suit our need without a custom service.  +This would allow us fine-grained control of autoscaling at the platform level, instead of from the applications themselves – but we’ll also evaluate [**Horizontal Pod Autoscaling**](/docs/user-guide/horizontal-pod-autoscaling/) in Kubernetes; which may suit our need without a custom service.  diff --git a/content/en/blog/_posts/2016-11-00-Visualize-Kubelet-Performance-With-Node-Dashboard.md b/content/en/blog/_posts/2016-11-00-Visualize-Kubelet-Performance-With-Node-Dashboard.md index 9d263a8ad6..bdb43b49b9 100644 --- a/content/en/blog/_posts/2016-11-00-Visualize-Kubelet-Performance-With-Node-Dashboard.md +++ b/content/en/blog/_posts/2016-11-00-Visualize-Kubelet-Performance-With-Node-Dashboard.md @@ -9,7 +9,7 @@ In Kubernetes 1.4, we introduced a new node performance analysis tool, called th **Background** -A Kubernetes cluster is made up of both master and worker nodes. The master node manages the cluster’s state, and the worker nodes do the actual work of running and managing pods. To do so, on each worker node, a binary, called [Kubelet](http://kubernetes.io/docs/admin/kubelet/), watches for any changes in pod configuration, and takes corresponding actions to make sure that containers run successfully. High performance of the Kubelet, such as low latency to converge with new pod configuration and efficient housekeeping with low resource usage, is essential for the entire Kubernetes cluster. To measure this performance, Kubernetes uses [end-to-end (e2e) tests](https://github.com/kubernetes/kubernetes/blob/master/docs/devel/e2e-tests.md#overview) to continuously monitor benchmark changes of latest builds with new features. +A Kubernetes cluster is made up of both master and worker nodes. The master node manages the cluster’s state, and the worker nodes do the actual work of running and managing pods. To do so, on each worker node, a binary, called [Kubelet](/docs/admin/kubelet/), watches for any changes in pod configuration, and takes corresponding actions to make sure that containers run successfully. High performance of the Kubelet, such as low latency to converge with new pod configuration and efficient housekeeping with low resource usage, is essential for the entire Kubernetes cluster. To measure this performance, Kubernetes uses [end-to-end (e2e) tests](https://github.com/kubernetes/kubernetes/blob/master/docs/devel/e2e-tests.md#overview) to continuously monitor benchmark changes of latest builds with new features. **Kubernetes SLOs are defined by the following benchmarks** : diff --git a/content/en/blog/_posts/2016-12-00-Cluster-Federation-In-Kubernetes-1-5.md b/content/en/blog/_posts/2016-12-00-Cluster-Federation-In-Kubernetes-1-5.md index 8196ea26da..05330bd067 100644 --- a/content/en/blog/_posts/2016-12-00-Cluster-Federation-In-Kubernetes-1-5.md +++ b/content/en/blog/_posts/2016-12-00-Cluster-Federation-In-Kubernetes-1-5.md @@ -8,16 +8,16 @@ _Editor’s note: this post is part of a [series of in-depth articles](https://k In the latest [Kubernetes 1.5 release](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads), you’ll notice that support for Cluster Federation is maturing. That functionality was introduced in Kubernetes 1.3, and the 1.5 release includes a number of new features, including an easier setup experience and a step closer to supporting all Kubernetes API objects. -A new command line tool called ‘**[kubefed](http://kubernetes.io/docs/admin/federation/kubefed/)**’ was introduced to make getting started with Cluster Federation much simpler. Also, alpha level support was added for Federated DaemonSets, Deployments and ConfigMaps. In summary: +A new command line tool called ‘**[kubefed](/docs/admin/federation/kubefed/)**’ was introduced to make getting started with Cluster Federation much simpler. Also, alpha level support was added for Federated DaemonSets, Deployments and ConfigMaps. In summary: -- **DaemonSets** are Kubernetes deployment rules that guarantee that a given pod is always present at every node, as new nodes are added to the cluster (more [info](http://kubernetes.io/docs/admin/daemons/)). -- **Deployments** describe the desired state of Replica Sets (more [info](http://kubernetes.io/docs/user-guide/deployments/)). -- **ConfigMaps** are variables applied to Replica Sets (which greatly improves image reusability as their parameters can be externalized - more [info](http://kubernetes.io/docs/user-guide/configmap/)). +- **DaemonSets** are Kubernetes deployment rules that guarantee that a given pod is always present at every node, as new nodes are added to the cluster (more [info](/docs/admin/daemons/)). +- **Deployments** describe the desired state of Replica Sets (more [info](/docs/user-guide/deployments/)). +- **ConfigMaps** are variables applied to Replica Sets (which greatly improves image reusability as their parameters can be externalized - more [info](/docs/user-guide/configmap/)). **Federated DaemonSets** , **Federated Deployments** , **Federated ConfigMaps** take the qualities of the base concepts to the next level. For instance, Federated DaemonSets guarantee that a pod is deployed on every node of the newly added cluster. But what actually is “federation”? Let’s explain it by what needs it satisfies. Imagine a service that operates globally. Naturally, all its users expect to get the same quality of service, whether they are located in Asia, Europe, or the US. What this means is that the service must respond equally fast to requests at each location. This sounds simple, but there’s lots of logic involved behind the scenes. This is what Kubernetes Cluster Federation aims to do. -How does it work? One of the Kubernetes clusters must become a master by running a **Federation Control Plane**. In practice, this is a controller that monitors the health of other clusters, and provides a single entry point for administration. The entry point behaves like a typical Kubernetes cluster. It allows creating [Replica Sets](http://kubernetes.io/docs/user-guide/replicasets/), [Deployments](http://kubernetes.io/docs/user-guide/deployments/), [Services](http://kubernetes.io/docs/user-guide/services/), but the federated control plane passes the resources to underlying clusters. This means that if we request the federation control plane to create a Replica Set with 1,000 replicas, it will spread the request across all underlying clusters. If we have 5 clusters, then by default each will get its share of 200 replicas. +How does it work? One of the Kubernetes clusters must become a master by running a **Federation Control Plane**. In practice, this is a controller that monitors the health of other clusters, and provides a single entry point for administration. The entry point behaves like a typical Kubernetes cluster. It allows creating [Replica Sets](/docs/user-guide/replicasets/), [Deployments](/docs/user-guide/deployments/), [Services](/docs/user-guide/services/), but the federated control plane passes the resources to underlying clusters. This means that if we request the federation control plane to create a Replica Set with 1,000 replicas, it will spread the request across all underlying clusters. If we have 5 clusters, then by default each will get its share of 200 replicas. This on its own is a powerful mechanism. But there’s more. It’s also possible to create a Federated Ingress. Effectively, this is a global application-layer load balancer. Thanks to an understanding of the application layer, it allows load balancing to be “smarter” -- for instance, by taking into account the geographical location of clients and servers, and routing the traffic between them in an optimal way. @@ -54,7 +54,7 @@ export FED\_DNS\_ZONE=\ ``` -And get kubectl and kubefed binaries. (for installation instructions refer to guides [here](http://kubernetes.io/docs/user-guide/prereqs/) and [here](http://kubernetes.io/docs/admin/federation/kubefed/#getting-kubefed)). +And get kubectl and kubefed binaries. (for installation instructions refer to guides [here](/docs/user-guide/prereqs/) and [here](/docs/admin/federation/kubefed/#getting-kubefed)). Now the setup is ready to create a few Google Container Engine (GKE) clusters with gcloud container clusters create (1-create.sh). In this case one is in US, one in Europe and one in Asia. ``` @@ -210,7 +210,7 @@ As you can see, the two commands refer to the “federation” context, i.e. to **Creating The Ingress** -After the Service is ready, we can create [Ingress](http://kubernetes.io/docs/user-guide/ingress/) - the global load balancer. The command is like this: +After the Service is ready, we can create [Ingress](/docs/user-guide/ingress/) - the global load balancer. The command is like this: diff --git a/content/en/blog/_posts/2016-12-00-From-Network-Policies-To-Security-Policies.md b/content/en/blog/_posts/2016-12-00-From-Network-Policies-To-Security-Policies.md index 6d4ed2f745..abf3268f5a 100644 --- a/content/en/blog/_posts/2016-12-00-From-Network-Policies-To-Security-Policies.md +++ b/content/en/blog/_posts/2016-12-00-From-Network-Policies-To-Security-Policies.md @@ -9,7 +9,7 @@ _Editor's note: Today’s post is by Bernard Van De Walle, Kubernetes Lead Engin **Kubernetes Network Policies ** -Kubernetes supports a [new API for network policies](http://kubernetes.io/docs/user-guide/networkpolicies/) that provides a sophisticated model for isolating applications and reducing their attack surface. This feature, which came out of the [SIG-Network group](https://github.com/kubernetes/community/wiki/SIG-Network), makes it very easy and elegant to define network policies by using the built-in labels and selectors Kubernetes constructs. +Kubernetes supports a [new API for network policies](/docs/user-guide/networkpolicies/) that provides a sophisticated model for isolating applications and reducing their attack surface. This feature, which came out of the [SIG-Network group](https://github.com/kubernetes/community/wiki/SIG-Network), makes it very easy and elegant to define network policies by using the built-in labels and selectors Kubernetes constructs. Kubernetes has left it up to third parties to implement these network policies and does not provide a default implementation. @@ -28,7 +28,7 @@ The authentication and authorization function in Trireme is overlaid on the TCP ![](https://lh3.googleusercontent.com/PhkJ4eoRc50gm6oSTZbw138l3jzVKjjQrn2mNHjys9Cu7RG-q2X-f5PX07ZY6xjbIQT0ud8oMSX6yNwjDpmDq3a3lYWcc_gBYJBjvBLP8PIHZaTW54fJppDze9pYxOmZY-JNqQ1Y) -The Trireme implementation talks directly to the Kubernetes master without an external controller and receives notifications on policy updates and pod instantiations so that it can maintain a local cache of the policy and update the authorization rules as needed. There is no requirement for any shared state between Trireme components that needs to be synchronized. Trireme can be deployed either as a standalone process in every worker or by using [Daemon Sets](http://kubernetes.io/docs/admin/daemons/). In the latter case, Kubernetes takes ownership of the lifecycle of the Trireme pods.  +The Trireme implementation talks directly to the Kubernetes master without an external controller and receives notifications on policy updates and pod instantiations so that it can maintain a local cache of the policy and update the authorization rules as needed. There is no requirement for any shared state between Trireme components that needs to be synchronized. Trireme can be deployed either as a standalone process in every worker or by using [Daemon Sets](/docs/admin/daemons/). In the latter case, Kubernetes takes ownership of the lifecycle of the Trireme pods.  Trireme's simplicity is derived from the separation of security policy from network transport. Policy enforcement is linked directly to the labels present on the connection, irrespective of the networking scheme used to make the pods communicate. This identity linkage enables tremendous flexibility to operators to use any networking scheme they like without tying security policy enforcement to network implementation details. Also, the implementation of security policy across the federated clusters becomes simple and viable. diff --git a/content/en/blog/_posts/2016-12-00-Kubernetes-1-5-Supporting-Production-Workloads.md b/content/en/blog/_posts/2016-12-00-Kubernetes-1-5-Supporting-Production-Workloads.md index 750f792edf..5f44ce1767 100644 --- a/content/en/blog/_posts/2016-12-00-Kubernetes-1-5-Supporting-Production-Workloads.md +++ b/content/en/blog/_posts/2016-12-00-Kubernetes-1-5-Supporting-Production-Workloads.md @@ -17,24 +17,24 @@ Lastly, for those interested in the internals of Kubernetes, 1.5 introduces Cont **What’s New** -[**StatefulSet**](http://kubernetes.io/docs/concepts/abstractions/controllers/statefulsets/) beta (formerly known as PetSet) allows workloads that require persistent identity or per-instance storage to be [created](http://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/#creating-a-statefulset), [scaled](http://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/#scaling-a-statefulset), [deleted](http://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/#deleting-statefulsets) and [repaired](http://kubernetes.io/docs/tasks/manage-stateful-set/debugging-a-statefulset/) on Kubernetes. You can use StatefulSets to ease the deployment of any stateful service, and tutorial examples are available in the repository. In order to ensure that there are never two pods with the same identity, the Kubernetes node controller no longer force deletes pods on unresponsive nodes. Instead, it waits until the old pod is confirmed dead in one of several ways: automatically when the kubelet reports back and confirms the old pod is terminated; automatically when a cluster-admin deletes the node; or when a database admin confirms it is safe to proceed by force deleting the old pod. Users are now warned if they try to force delete pods via the CLI. For users who will be migrating from PetSets to StatefulSets, please follow the upgrade [guide](http://kubernetes.io/docs/tasks/manage-stateful-set/upgrade-pet-set-to-stateful-set). +[**StatefulSet**](/docs/concepts/abstractions/controllers/statefulsets/) beta (formerly known as PetSet) allows workloads that require persistent identity or per-instance storage to be [created](/docs/tutorials/stateful-application/basic-stateful-set/#creating-a-statefulset), [scaled](/docs/tutorials/stateful-application/basic-stateful-set/#scaling-a-statefulset), [deleted](/docs/tutorials/stateful-application/basic-stateful-set/#deleting-statefulsets) and [repaired](/docs/tasks/manage-stateful-set/debugging-a-statefulset/) on Kubernetes. You can use StatefulSets to ease the deployment of any stateful service, and tutorial examples are available in the repository. In order to ensure that there are never two pods with the same identity, the Kubernetes node controller no longer force deletes pods on unresponsive nodes. Instead, it waits until the old pod is confirmed dead in one of several ways: automatically when the kubelet reports back and confirms the old pod is terminated; automatically when a cluster-admin deletes the node; or when a database admin confirms it is safe to proceed by force deleting the old pod. Users are now warned if they try to force delete pods via the CLI. For users who will be migrating from PetSets to StatefulSets, please follow the upgrade [guide](/docs/tasks/manage-stateful-set/upgrade-pet-set-to-stateful-set). -**[PodDisruptionBudget](http://kubernetes.io/docs/admin/disruptions/)** beta is an API object that specifies the minimum number or minimum percentage of replicas of a collection of pods that must be up at any time. With PodDisruptionBudget, an application deployer can ensure that cluster operations that voluntarily evict pods will never take down so many simultaneously as to cause data loss, an outage, or an unacceptable service degradation. In Kubernetes 1.5 the “kubectl drain” command supports PodDisruptionBudget, allowing safe draining of nodes for maintenance activities, and it will soon also be used by node upgrade and cluster autoscaler (when removing nodes). This can be useful for a quorum based application to ensure the number of replicas running is never below the number needed for quorum, or for a web front end to ensure the number of replicas serving load never falls below a certain percentage. +**[PodDisruptionBudget](/docs/admin/disruptions/)** beta is an API object that specifies the minimum number or minimum percentage of replicas of a collection of pods that must be up at any time. With PodDisruptionBudget, an application deployer can ensure that cluster operations that voluntarily evict pods will never take down so many simultaneously as to cause data loss, an outage, or an unacceptable service degradation. In Kubernetes 1.5 the “kubectl drain” command supports PodDisruptionBudget, allowing safe draining of nodes for maintenance activities, and it will soon also be used by node upgrade and cluster autoscaler (when removing nodes). This can be useful for a quorum based application to ensure the number of replicas running is never below the number needed for quorum, or for a web front end to ensure the number of replicas serving load never falls below a certain percentage. -**[Kubefed](http://kubernetes.io/docs/admin/federation/kubefed.md)** alpha is a new command line tool to help you manage federated clusters, making it easy to deploy new federation control planes and add or remove clusters from existing federations. Also new in cluster federation is the addition of [ConfigMaps](http://kubernetes.io/docs/user-guide/federation/configmap.md) alpha and [DaemonSets](http://kubernetes.io/docs/user-guide/federation/daemonsets.md) alpha and [deployments](http://kubernetes.io/docs/user-guide/federation/deployment.md) alpha to the [federation API](http://kubernetes.io/docs/user-guide/federation/index.md) allowing you to create, update and delete these objects across multiple clusters from a single endpoint. +**[Kubefed](/docs/admin/federation/kubefed.md)** alpha is a new command line tool to help you manage federated clusters, making it easy to deploy new federation control planes and add or remove clusters from existing federations. Also new in cluster federation is the addition of [ConfigMaps](/docs/user-guide/federation/configmap.md) alpha and [DaemonSets](/docs/user-guide/federation/daemonsets.md) alpha and [deployments](/docs/user-guide/federation/deployment.md) alpha to the [federation API](/docs/user-guide/federation/index.md) allowing you to create, update and delete these objects across multiple clusters from a single endpoint. -**[HA Masters](http://kubernetes.io/docs/admin/ha-master-gce.md)** alpha provides the ability to create and delete clusters with highly available (replicated) masters on GCE using the kube-up/kube-down scripts. Allows setup of zone distributed HA masters, with at least one etcd replica per zone, at least one API server per zone, and master-elected components like scheduler and controller-manager distributed across zones. +**[HA Masters](/docs/admin/ha-master-gce.md)** alpha provides the ability to create and delete clusters with highly available (replicated) masters on GCE using the kube-up/kube-down scripts. Allows setup of zone distributed HA masters, with at least one etcd replica per zone, at least one API server per zone, and master-elected components like scheduler and controller-manager distributed across zones. -**[Windows server containers](http://kubernetes.io/docs/getting-started-guides/windows/)** alpha provides initial support for Windows Server 2016 nodes and scheduling Windows Server Containers.  +**[Windows server containers](/docs/getting-started-guides/windows/)** alpha provides initial support for Windows Server 2016 nodes and scheduling Windows Server Containers.  **[Container Runtime Interface](https://github.com/kubernetes/kubernetes/blob/release-1.5/docs/devel/container-runtime-interface.md)** (CRI) alpha introduces the v1 CRI API to allow pluggable container runtimes; an experimental docker-CRI integration is ready for testing and feedback. -[**Node conformance test**](http://kubernetes.io/docs/admin/node-conformance.md) beta is a containerized test framework that provides a system verification and functionality test for nodes. The test validates whether the node meets the minimum requirements for Kubernetes; a node that passes the tests is qualified to join a Kubernetes. Node conformance test is available at: gcr.io/google\_containers/node-test:0.2 for users to verify node setup. +[**Node conformance test**](/docs/admin/node-conformance.md) beta is a containerized test framework that provides a system verification and functionality test for nodes. The test validates whether the node meets the minimum requirements for Kubernetes; a node that passes the tests is qualified to join a Kubernetes. Node conformance test is available at: gcr.io/google\_containers/node-test:0.2 for users to verify node setup. These are just some of the highlights in our last release for the year. For a complete list please visit the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#v151).  **Availability** -Kubernetes 1.5 is available for download [here](https://github.com/kubernetes/kubernetes/releases/tag/v1.5.1) on GitHub and via [get.k8s.io](http://get.k8s.io/). To get started with Kubernetes, try one of the [new interactive tutorials](http://kubernetes.io/docs/tutorials/kubernetes-basics/). Don’t forget to take 1.5 for a spin before the holidays!  +Kubernetes 1.5 is available for download [here](https://github.com/kubernetes/kubernetes/releases/tag/v1.5.1) on GitHub and via [get.k8s.io](http://get.k8s.io/). To get started with Kubernetes, try one of the [new interactive tutorials](/docs/tutorials/kubernetes-basics/). Don’t forget to take 1.5 for a spin before the holidays!  **User Adoption** It’s been a year-and-a-half since GA, and the rate of [Kubernetes user adoption](http://kubernetes.io/case-studies/) continues to surpass estimates. Organizations running production workloads on Kubernetes include the world's largest companies, young startups, and everything in between. Since Kubernetes is open and runs anywhere, we’ve seen adoption on a diverse set of platforms; Pokémon Go (Google Cloud), Ticketmaster (AWS), SAP (OpenStack), Box (bare-metal), and hybrid environments that mix-and-match the above. Here are a few user highlights: diff --git a/content/en/blog/_posts/2016-12-00-Statefulset-Run-Scale-Stateful-Applications-In-Kubernetes.md b/content/en/blog/_posts/2016-12-00-Statefulset-Run-Scale-Stateful-Applications-In-Kubernetes.md index 44c875547b..ab02152b6b 100644 --- a/content/en/blog/_posts/2016-12-00-Statefulset-Run-Scale-Stateful-Applications-In-Kubernetes.md +++ b/content/en/blog/_posts/2016-12-00-Statefulset-Run-Scale-Stateful-Applications-In-Kubernetes.md @@ -6,11 +6,11 @@ url: /blog/2016/12/Statefulset-Run-Scale-Stateful-Applications-In-Kubernetes --- _Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2016/12/five-days-of-kubernetes-1.5) on what's new in Kubernetes 1.5_ -In the latest release, [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads), we’ve moved the feature formerly known as PetSet into beta as [StatefulSet](http://kubernetes.io/docs/concepts/abstractions/controllers/statefulsets/). There were no major changes to the API Object, other than the community selected name, but we added the semantics of “at most one pod per index” for deployment of the Pods in the set. Along with ordered deployment, ordered termination, unique network names, and persistent stable storage, we think we have the right primitives to support many containerized stateful workloads. We don’t claim that the feature is 100% complete (it is software after all), but we believe that it is useful in its current form, and that we can extend the API in a backwards-compatible way as we progress toward an eventual GA release. +In the latest release, [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads), we’ve moved the feature formerly known as PetSet into beta as [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/). There were no major changes to the API Object, other than the community selected name, but we added the semantics of “at most one pod per index” for deployment of the Pods in the set. Along with ordered deployment, ordered termination, unique network names, and persistent stable storage, we think we have the right primitives to support many containerized stateful workloads. We don’t claim that the feature is 100% complete (it is software after all), but we believe that it is useful in its current form, and that we can extend the API in a backwards-compatible way as we progress toward an eventual GA release. **When is StatefulSet the Right Choice for my Storage Application?** -[Deployments](http://kubernetes.io/docs/user-guide/deployments/) and [ReplicaSets](http://kubernetes.io/docs/user-guide/replicasets/) are a great way to run stateless replicas of an application on Kubernetes, but their semantics aren’t really right for deploying stateful applications. The purpose of StatefulSet is to provide a controller with the correct semantics for deploying a wide range of stateful workloads. However, moving your storage application onto Kubernetes isn’t always the correct choice. Before you go all in on converging your storage tier and your orchestration framework, you should ask yourself a few questions. +[Deployments](/docs/user-guide/deployments/) and [ReplicaSets](/docs/user-guide/replicasets/) are a great way to run stateless replicas of an application on Kubernetes, but their semantics aren’t really right for deploying stateful applications. The purpose of StatefulSet is to provide a controller with the correct semantics for deploying a wide range of stateful workloads. However, moving your storage application onto Kubernetes isn’t always the correct choice. Before you go all in on converging your storage tier and your orchestration framework, you should ask yourself a few questions. **Can your application run using remote storage or does it require local storage media?** @@ -34,10 +34,10 @@ If you run your storage application on high-end hardware or extra-large instance **A Practical Example - ZooKeeper** -[ZooKeeper](https://zookeeper.apache.org/doc/current/) is an interesting use case for StatefulSet for two reasons. First, it demonstrates that StatefulSet can be used to run a distributed, strongly consistent storage application on Kubernetes. Second, it's a prerequisite for running workloads like [Apache Hadoop](http://hadoop.apache.org/) and [Apache Kakfa](https://kafka.apache.org/) on Kubernetes. An [in-depth tutorial](http://kubernetes.io/docs/tutorials/stateful-application/zookeeper/) on deploying a ZooKeeper ensemble on Kubernetes is available in the Kubernetes documentation, and we’ll outline a few of the key features below. +[ZooKeeper](https://zookeeper.apache.org/doc/current/) is an interesting use case for StatefulSet for two reasons. First, it demonstrates that StatefulSet can be used to run a distributed, strongly consistent storage application on Kubernetes. Second, it's a prerequisite for running workloads like [Apache Hadoop](http://hadoop.apache.org/) and [Apache Kakfa](https://kafka.apache.org/) on Kubernetes. An [in-depth tutorial](/docs/tutorials/stateful-application/zookeeper/) on deploying a ZooKeeper ensemble on Kubernetes is available in the Kubernetes documentation, and we’ll outline a few of the key features below. **Creating a ZooKeeper Ensemble** -Creating an ensemble is as simple as using [kubectl create](http://kubernetes.io/docs/user-guide/kubectl/kubectl_create/) to generate the objects stored in the manifest. +Creating an ensemble is as simple as using [kubectl create](/docs/user-guide/kubectl/kubectl_create/) to generate the objects stored in the manifest. ``` @@ -297,7 +297,7 @@ zk-0 0/1 Terminating 0 15m -You can use [kubectl apply](http://kubernetes.io/docs/user-guide/kubectl/kubectl_apply/) to recreate the zk StatefulSet and redeploy the ensemble. +You can use [kubectl apply](/docs/user-guide/kubectl/kubectl_apply/) to recreate the zk StatefulSet and redeploy the ensemble. @@ -355,7 +355,7 @@ You should always provision headroom capacity for critical processes in your clu -If the SLAs for your service preclude even brief outages due to a single node failure, you should use a [PodAntiAffinity](http://kubernetes.io/docs/user-guide/node-selection/) annotation. The manifest used to create the ensemble contains such an annotation, and it tells the Kubernetes Scheduler to not place more than one Pod from the zk StatefulSet on the same node. +If the SLAs for your service preclude even brief outages due to a single node failure, you should use a [PodAntiAffinity](/docs/user-guide/node-selection/) annotation. The manifest used to create the ensemble contains such an annotation, and it tells the Kubernetes Scheduler to not place more than one Pod from the zk StatefulSet on the same node. @@ -366,7 +366,7 @@ If the SLAs for your service preclude even brief outages due to a single node fa -The manifest used to create the ZooKeeper ensemble also creates a [PodDistruptionBudget](http://kubernetes.io/docs/admin/disruptions/), zk-budget. The zk-budget informs Kubernetes about the upper limit of disruptions (unhealthy Pods) that the service can tolerate. +The manifest used to create the ZooKeeper ensemble also creates a [PodDistruptionBudget](/docs/admin/disruptions/), zk-budget. The zk-budget informs Kubernetes about the upper limit of disruptions (unhealthy Pods) that the service can tolerate. @@ -418,7 +418,7 @@ zk-budget 2 1 2h -zk-budget indicates that at least two members of the ensemble must be available at all times for the ensemble to be healthy. If you attempt to drain a node prior taking it offline, and if draining it would terminate a Pod that violates the budget, the drain operation will fail. If you use [kubectl drain](http://kubernetes.io/docs/user-guide/kubectl/kubectl_drain/), in conjunction with PodDisruptionBudgets, to cordon your nodes and to evict all Pods prior to maintenance or decommissioning, you can ensure that the procedure won’t be disruptive to your stateful applications. +zk-budget indicates that at least two members of the ensemble must be available at all times for the ensemble to be healthy. If you attempt to drain a node prior taking it offline, and if draining it would terminate a Pod that violates the budget, the drain operation will fail. If you use [kubectl drain](/docs/user-guide/kubectl/kubectl_drain/), in conjunction with PodDisruptionBudgets, to cordon your nodes and to evict all Pods prior to maintenance or decommissioning, you can ensure that the procedure won’t be disruptive to your stateful applications. diff --git a/content/en/blog/_posts/2016-12-00-Windows-Server-Support-Kubernetes.md b/content/en/blog/_posts/2016-12-00-Windows-Server-Support-Kubernetes.md index 8858194f88..fa32e6ef69 100644 --- a/content/en/blog/_posts/2016-12-00-Windows-Server-Support-Kubernetes.md +++ b/content/en/blog/_posts/2016-12-00-Windows-Server-Support-Kubernetes.md @@ -64,7 +64,7 @@ Support for Windows Server-based containers is in alpha release mode for Kuberne - **Runtime Operations** - the SIG will play a key part in defining the monitoring interface of the Container Runtime Interface (CRI), leveraging it to provide deep insight and monitoring for Windows Server-based containers **Get Started** -To get started with Kubernetes on Windows Server 2016, please visit the [GitHub guide](http://kubernetes.io/docs/getting-started-guides/windows/) for more details. +To get started with Kubernetes on Windows Server 2016, please visit the [GitHub guide](/docs/getting-started-guides/windows/) for more details. If you want to help with Windows Server support, then please connect with the [Windows Server SIG](https://github.com/kubernetes/community/blob/master/sig-windows/README.md) or connect directly with Michael Michael, the SIG lead, on [GitHub](https://github.com/michmike).  _--[Michael Michael](https://twitter.com/michmike77), Senior Director of Product Management, Apprenda _ diff --git a/content/en/blog/_posts/2017-01-00-Running-Mongodb-On-Kubernetes-With-Statefulsets.md b/content/en/blog/_posts/2017-01-00-Running-Mongodb-On-Kubernetes-With-Statefulsets.md index 8c609bfc88..70c03ecce3 100644 --- a/content/en/blog/_posts/2017-01-00-Running-Mongodb-On-Kubernetes-With-Statefulsets.md +++ b/content/en/blog/_posts/2017-01-00-Running-Mongodb-On-Kubernetes-With-Statefulsets.md @@ -9,7 +9,7 @@ _Editor's note: Today’s post is by Sandeep Dinesh, Developer Advocate, Google Conventional wisdom says you can’t run a database in a container. “Containers are stateless!” they say, and “databases are pointless without state!” -Of course, this is not true at all. At Google, everything runs in a container, including databases. You just need the right tools. [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads) includes the new [StatefulSet](http://kubernetes.io/docs/concepts/abstractions/controllers/statefulsets/) API object (in previous versions, StatefulSet was known as PetSet). With StatefulSets, Kubernetes makes it much easier to run stateful workloads such as databases. +Of course, this is not true at all. At Google, everything runs in a container, including databases. You just need the right tools. [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads) includes the new [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/) API object (in previous versions, StatefulSet was known as PetSet). With StatefulSets, Kubernetes makes it much easier to run stateful workloads such as databases. If you’ve followed my previous posts, you know how to create a [MEAN Stack app with Docker](http://blog.sandeepdinesh.com/2015/07/running-mean-web-application-in-docker.html), then [migrate it to Kubernetes](https://medium.com/google-cloud/running-a-mean-stack-on-google-cloud-platform-with-kubernetes-149ca81c2b5d) to provide easier management and reliability, and [create a MongoDB replica set](https://medium.com/google-cloud/mongodb-replica-sets-with-kubernetes-d96606bd9474) to provide redundancy and high availability. @@ -25,7 +25,7 @@ _Note: StatefulSets are currently a beta resource. The [sidecar container](https -Before we get started, you’ll need a Kubernetes 1.5+ and the [Kubernetes command line tool](http://kubernetes.io/docs/user-guide/prereqs/). If you want to follow along with this tutorial and use Google Cloud Platform, you also need the [Google Cloud SDK](http://cloud.google.com/sdk). +Before we get started, you’ll need a Kubernetes 1.5+ and the [Kubernetes command line tool](/docs/user-guide/prereqs/). If you want to follow along with this tutorial and use Google Cloud Platform, you also need the [Google Cloud SDK](http://cloud.google.com/sdk). @@ -62,7 +62,7 @@ gcloud container clusters get-credentials test-cluster -To set up the MongoDB replica set, you need three things: A [StorageClass](http://kubernetes.io/docs/user-guide/persistent-volumes/#storageclasses), a [Headless Service](http://kubernetes.io/docs/user-guide/services/#headless-services), and a [StatefulSet](http://kubernetes.io/docs/concepts/abstractions/controllers/statefulsets/). +To set up the MongoDB replica set, you need three things: A [StorageClass](/docs/user-guide/persistent-volumes/#storageclasses), a [Headless Service](/docs/user-guide/services/#headless-services), and a [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/). @@ -108,7 +108,7 @@ Let’s examine each piece in more detail. -The storage class tells Kubernetes what kind of storage to use for the database nodes. You can set up many different types of StorageClasses in a ton of different environments. For example, if you run Kubernetes in your own datacenter, you can use [GlusterFS](https://www.gluster.org/). On GCP, your [storage choices](https://cloud.google.com/compute/docs/disks/) are SSDs and hard disks. There are currently drivers for [AWS](http://kubernetes.io/docs/user-guide/persistent-volumes/#aws), [Azure](http://kubernetes.io/docs/user-guide/persistent-volumes/#azure-disk), [Google Cloud](http://kubernetes.io/docs/user-guide/persistent-volumes/#gce), [GlusterFS](http://kubernetes.io/docs/user-guide/persistent-volumes/#glusterfs), [OpenStack Cinder](http://kubernetes.io/docs/user-guide/persistent-volumes/#openstack-cinder), [vSphere](http://kubernetes.io/docs/user-guide/persistent-volumes/#vsphere), [Ceph RBD](http://kubernetes.io/docs/user-guide/persistent-volumes/#ceph-rbd), and [Quobyte](http://kubernetes.io/docs/user-guide/persistent-volumes/#quobyte). +The storage class tells Kubernetes what kind of storage to use for the database nodes. You can set up many different types of StorageClasses in a ton of different environments. For example, if you run Kubernetes in your own datacenter, you can use [GlusterFS](https://www.gluster.org/). On GCP, your [storage choices](https://cloud.google.com/compute/docs/disks/) are SSDs and hard disks. There are currently drivers for [AWS](/docs/user-guide/persistent-volumes/#aws), [Azure](/docs/user-guide/persistent-volumes/#azure-disk), [Google Cloud](/docs/user-guide/persistent-volumes/#gce), [GlusterFS](/docs/user-guide/persistent-volumes/#glusterfs), [OpenStack Cinder](/docs/user-guide/persistent-volumes/#openstack-cinder), [vSphere](/docs/user-guide/persistent-volumes/#vsphere), [Ceph RBD](/docs/user-guide/persistent-volumes/#ceph-rbd), and [Quobyte](/docs/user-guide/persistent-volumes/#quobyte). @@ -189,7 +189,7 @@ You can tell this is a Headless Service because the clusterIP is set to “None. -The pièce de résistance. The StatefulSet actually runs MongoDB and orchestrates everything together. StatefulSets differ from Kubernetes [ReplicaSets](http://kubernetes.io/docs/user-guide/replicasets/) (not to be confused with MongoDB replica sets!) in certain ways that makes them more suited for stateful applications. Unlike Kubernetes ReplicaSets, pods created under a StatefulSet have a few unique attributes. The name of the pod is not random, instead each pod gets an ordinal name. Combined with the Headless Service, this allows pods to have stable identification. In addition, pods are created one at a time instead of all at once, which can help when bootstrapping a stateful system. You can read more about StatefulSets in the [documentation](http://kubernetes.io/docs/concepts/abstractions/controllers/statefulsets/). +The pièce de résistance. The StatefulSet actually runs MongoDB and orchestrates everything together. StatefulSets differ from Kubernetes [ReplicaSets](/docs/user-guide/replicasets/) (not to be confused with MongoDB replica sets!) in certain ways that makes them more suited for stateful applications. Unlike Kubernetes ReplicaSets, pods created under a StatefulSet have a few unique attributes. The name of the pod is not random, instead each pod gets an ordinal name. Combined with the Headless Service, this allows pods to have stable identification. In addition, pods are created one at a time instead of all at once, which can help when bootstrapping a stateful system. You can read more about StatefulSets in the [documentation](/docs/concepts/abstractions/controllers/statefulsets/). diff --git a/content/en/blog/_posts/2017-01-00-Scaling-Kubernetes-Deployments-With-Policy-Base-Networking.md b/content/en/blog/_posts/2017-01-00-Scaling-Kubernetes-Deployments-With-Policy-Base-Networking.md index 5516f4779d..3318aabd17 100644 --- a/content/en/blog/_posts/2017-01-00-Scaling-Kubernetes-Deployments-With-Policy-Base-Networking.md +++ b/content/en/blog/_posts/2017-01-00-Scaling-Kubernetes-Deployments-With-Policy-Base-Networking.md @@ -24,13 +24,13 @@ For companies deploying applications on Kubernetes, one of biggest questions is **Kubernetes Networking** -Kubernetes provides a core set of platform services exposed through [APIs](http://kubernetes.io/docs/api/). The platform can be extended in several ways through the extensions API, plugins and labels. This has allowed a wide variety integrations and tools to be developed for Kubernetes. Kubernetes recognizes that the network in each deployment is going to be unique. Instead of trying to make the core system try to handle all those use cases, Kubernetes chose to make the network pluggable. +Kubernetes provides a core set of platform services exposed through [APIs](/docs/api/). The platform can be extended in several ways through the extensions API, plugins and labels. This has allowed a wide variety integrations and tools to be developed for Kubernetes. Kubernetes recognizes that the network in each deployment is going to be unique. Instead of trying to make the core system try to handle all those use cases, Kubernetes chose to make the network pluggable. With [Nuage Networks](http://www.nuagenetworks.net/) we provide a scalable policy-based SDN platform. The platform is managed by a Network Policy Engine that abstracts away the complexity associated with configuring the system. There is a separate SDN Controller that comes with a very rich routing feature set and is designed to scale horizontally. Nuage uses the open source [Open vSwitch (OVS)](http://www.openvswitch.org/) for the data plane with some enhancements in the OVS user space. Just like Kubernetes, Nuage has embraced openness as a core tenet for its platform. Nuage provides open APIs that allow users to orchestrate their networks and integrate network services such as firewalls, load balancers, IPAM tools etc. Nuage is supported in a wide variety of cloud platforms like OpenStack and VMware as well as container platforms like Kubernetes and others. -The Nuage platform implements a Kubernetes [network plugin](http://kubernetes.io/docs/admin/network-plugins/) that creates VXLAN overlays to provide seamless policy-based networking between Kubernetes Pods and non-Kubernetes environments (VMs and bare metal servers). Each Pod is given an IP address from a network that belongs to a [Namespace](https://kubernetes.io/docs/user-guide/namespaces/) and is not tied to the Kubernetes node. +The Nuage platform implements a Kubernetes [network plugin](/docs/admin/network-plugins/) that creates VXLAN overlays to provide seamless policy-based networking between Kubernetes Pods and non-Kubernetes environments (VMs and bare metal servers). Each Pod is given an IP address from a network that belongs to a [Namespace](/docs/user-guide/namespaces/) and is not tied to the Kubernetes node. -As cloud applications are built using microservices, the ability to control traffic among these microservices is a fundamental requirement. It is important to point out that these network policies also need to control traffic that is going to/coming from external networks and services. Nuage’s policy abstraction model makes it easy to declare fine-grained ingress/egress policies for applications. Kubernetes has a beta [Network Policy API](http://kubernetes.io/docs/user-guide/networkpolicies/) implemented using the Kubernetes Extensions API. Nuage implements this Network Policy API to address a wide variety of policy use cases such as: +As cloud applications are built using microservices, the ability to control traffic among these microservices is a fundamental requirement. It is important to point out that these network policies also need to control traffic that is going to/coming from external networks and services. Nuage’s policy abstraction model makes it easy to declare fine-grained ingress/egress policies for applications. Kubernetes has a beta [Network Policy API](/docs/user-guide/networkpolicies/) implemented using the Kubernetes Extensions API. Nuage implements this Network Policy API to address a wide variety of policy use cases such as: - Kubernetes Namespace isolation diff --git a/content/en/blog/_posts/2017-02-00-Caas-The-Foundation-For-Next-Gen-Paas.md b/content/en/blog/_posts/2017-02-00-Caas-The-Foundation-For-Next-Gen-Paas.md index c3d029af93..afdeee4c60 100644 --- a/content/en/blog/_posts/2017-02-00-Caas-The-Foundation-For-Next-Gen-Paas.md +++ b/content/en/blog/_posts/2017-02-00-Caas-The-Foundation-For-Next-Gen-Paas.md @@ -9,7 +9,7 @@ _Today’s post is by Brendan Burns, Partner Architect, at Microsoft & Kubernete -Containers are revolutionizing the way that people build, package and deploy software. But what is often overlooked is how they are revolutionizing the way that people build the software that builds, packages and deploys software. (it’s ok if you have to read that sentence twice…) Today, and in a talk at [Container World](https://tmt.knect365.com/container-world/) tomorrow, I’m taking a look at how container orchestrators like Kubernetes form the foundation for next generation platform as a service (PaaS). In particular, I’m interested in how cloud container as a service (CaaS) platforms like [Azure Container Service](https://azure.microsoft.com/en-us/services/container-service/), [Google Container Engine](https://cloud.google.com/container-engine/) and [others](https://kubernetes.io/docs/getting-started-guides/#hosted-solutions) are becoming the new infrastructure layer that PaaS is built upon. +Containers are revolutionizing the way that people build, package and deploy software. But what is often overlooked is how they are revolutionizing the way that people build the software that builds, packages and deploys software. (it’s ok if you have to read that sentence twice…) Today, and in a talk at [Container World](https://tmt.knect365.com/container-world/) tomorrow, I’m taking a look at how container orchestrators like Kubernetes form the foundation for next generation platform as a service (PaaS). In particular, I’m interested in how cloud container as a service (CaaS) platforms like [Azure Container Service](https://azure.microsoft.com/en-us/services/container-service/), [Google Container Engine](https://cloud.google.com/container-engine/) and [others](/docs/getting-started-guides/#hosted-solutions) are becoming the new infrastructure layer that PaaS is built upon. To see this, it’s important to consider the set of services that have traditionally been provided by PaaS platforms: @@ -18,7 +18,7 @@ To see this, it’s important to consider the set of services that have traditio - Reliable, zero-downtime rollout of software versions - Healing, auto-scaling, load balancing -When you look at this list, it’s clear that most of these traditional “PaaS” roles have now been taken over by containers. The container image and container image build tooling has become the way to package up your application. [Container registries](https://kubernetes.io/docs/user-guide/images/#using-a-private-registry) have become the way to distribute your application across the world. Reliable software rollout is achieved using orchestrator concepts like [Deployment](https://kubernetes.io/docs/user-guide/deployments/#what-is-a-deployment) in Kubernetes, and service healing, auto-scaling and load-balancing are all properties of an application deployed in Kubernetes using [ReplicaSets](https://kubernetes.io/docs/user-guide/replicasets/#what-is-a-replicaset) and [Services](https://kubernetes.io/docs/user-guide/services/). +When you look at this list, it’s clear that most of these traditional “PaaS” roles have now been taken over by containers. The container image and container image build tooling has become the way to package up your application. [Container registries](/docs/user-guide/images/#using-a-private-registry) have become the way to distribute your application across the world. Reliable software rollout is achieved using orchestrator concepts like [Deployment](/docs/user-guide/deployments/#what-is-a-deployment) in Kubernetes, and service healing, auto-scaling and load-balancing are all properties of an application deployed in Kubernetes using [ReplicaSets](/docs/user-guide/replicasets/#what-is-a-replicaset) and [Services](/docs/user-guide/services/). What then is left for PaaS? Is PaaS going to be replaced by container as a service? I think the answer is “no.” The piece that is left for PaaS is the part that was always the most important part of PaaS in the first place, and that’s the opinionated developer experience. In addition to all of the generic parts of PaaS that I listed above, the most important part of a PaaS has always been the way in which the developer experience and application framework made developers more productive within the boundaries of the platform. PaaS enables developers to go from source code on their laptop to a world-wide scalable service in less than an hour. That’s hugely powerful.  diff --git a/content/en/blog/_posts/2017-02-00-Highly-Available-Kubernetes-Clusters.md b/content/en/blog/_posts/2017-02-00-Highly-Available-Kubernetes-Clusters.md index d042699192..1b60bb52d7 100644 --- a/content/en/blog/_posts/2017-02-00-Highly-Available-Kubernetes-Clusters.md +++ b/content/en/blog/_posts/2017-02-00-Highly-Available-Kubernetes-Clusters.md @@ -38,7 +38,7 @@ $ KUBE\_GCE\_ZONE=europe-west1-b ./cluster/kube-up.sh -Now, we will add two additional pools of worker nodes, each of three nodes, in zones europe-west1-c and europe-west1-d (more details on adding pools of worker nodes can be find [here](http://kubernetes.io/docs/setup/multiple-zones/)): +Now, we will add two additional pools of worker nodes, each of three nodes, in zones europe-west1-c and europe-west1-d (more details on adding pools of worker nodes can be find [here](/docs/setup/multiple-zones/)): ``` diff --git a/content/en/blog/_posts/2017-02-00-Postgresql-Clusters-Kubernetes-Statefulsets.md b/content/en/blog/_posts/2017-02-00-Postgresql-Clusters-Kubernetes-Statefulsets.md index b8747f50f3..89cf84a285 100644 --- a/content/en/blog/_posts/2017-02-00-Postgresql-Clusters-Kubernetes-Statefulsets.md +++ b/content/en/blog/_posts/2017-02-00-Postgresql-Clusters-Kubernetes-Statefulsets.md @@ -6,7 +6,7 @@ url: /blog/2017/02/Postgresql-Clusters-Kubernetes-Statefulsets --- _Editor’s note: Today’s guest post is by Jeff McCormick, a developer at Crunchy Data, showing how to build a PostgreSQL cluster using the new Kubernetes StatefulSet feature._ -In an earlier [post](https://kubernetes.io/blog/2016/09/creating-postgresql-cluster-using-helm), I described how to deploy a PostgreSQL cluster using [Helm](https://github.com/kubernetes/helm), a Kubernetes package manager. The following example provides the steps for building a PostgreSQL cluster using the new Kubernetes [StatefulSets](https://kubernetes.io/docs/concepts/abstractions/controllers/statefulsets/) feature. +In an earlier [post](https://kubernetes.io/blog/2016/09/creating-postgresql-cluster-using-helm), I described how to deploy a PostgreSQL cluster using [Helm](https://github.com/kubernetes/helm), a Kubernetes package manager. The following example provides the steps for building a PostgreSQL cluster using the new Kubernetes [StatefulSets](/docs/concepts/abstractions/controllers/statefulsets/) feature. **StatefulSets Example** @@ -14,7 +14,7 @@ In an earlier [post](https://kubernetes.io/blog/2016/09/creating-postgresql-clus StatefulSets is a new feature implemented in [Kubernetes 1.5](https://kubernetes.io/blog/2016/12/kubernetes-1.5-supporting-production-workloads) (prior versions it was known as PetSets). As a result, running this example will require an environment based on Kubernetes 1.5.0 or above. -The example in this blog deploys on Centos7 using [kubeadm](https://kubernetes.io/docs/admin/kubeadm/). Some instructions on what kubeadm provides and how to deploy a Kubernetes cluster is located [here](http://linoxide.com/containers/setup-kubernetes-kubeadm-centos). +The example in this blog deploys on Centos7 using [kubeadm](/docs/admin/kubeadm/). Some instructions on what kubeadm provides and how to deploy a Kubernetes cluster is located [here](http://linoxide.com/containers/setup-kubernetes-kubeadm-centos). **Step 2** - Install NFS @@ -177,7 +177,7 @@ PostgreSQL replicas are configured to connect to the master database via a Servi -During the container initialization, a master container will use a [Service Account](https://kubernetes.io/docs/user-guide/service-accounts/) (pgset-sa) to change it’s container label value to match the master Service selector. Changing the label is important to enable traffic destined to the master database to reach the correct container within the Stateful Set. All other pods in the set assume the replica Service label by default. +During the container initialization, a master container will use a [Service Account](/docs/user-guide/service-accounts/) (pgset-sa) to change it’s container label value to match the master Service selector. Changing the label is important to enable traffic destined to the master database to reach the correct container within the Stateful Set. All other pods in the set assume the replica Service label by default. diff --git a/content/en/blog/_posts/2017-02-00-Run-Deep-Learning-With-Paddlepaddle-On-Kubernetes.md b/content/en/blog/_posts/2017-02-00-Run-Deep-Learning-With-Paddlepaddle-On-Kubernetes.md index 90dcb447d0..bae95f2c0d 100644 --- a/content/en/blog/_posts/2017-02-00-Run-Deep-Learning-With-Paddlepaddle-On-Kubernetes.md +++ b/content/en/blog/_posts/2017-02-00-Run-Deep-Learning-With-Paddlepaddle-On-Kubernetes.md @@ -139,7 +139,7 @@ Figure 2: Job A of three pods and Job B of one pod running on two nodes. The entrypoint of each pod is [start.sh](https://github.com/PaddlePaddle/Paddle/blob/develop/doc/howto/usage/k8s/src/k8s_train/start.sh). It downloads data from a storage service, so that trainers can read quickly from the pod-local disk space. After downloading completes, it runs a Python script, [start\_paddle.py](https://github.com/PaddlePaddle/Paddle/blob/develop/doc/howto/usage/k8s/src/k8s_train/start_paddle.py), which starts a parameter server, waits until parameter servers of all pods are ready to serve, and then starts the trainer process in the pod. -This waiting is necessary because each trainer needs to talk to all parameter servers, as shown in Figure. 1. Kubernetes [API](http://kubernetes.io/docs/api-reference/v1/operations/#_list_or_watch_objects_of_kind_pod) enables trainers to check the status of pods, so the Python script could wait until all parameter servers’ status change to "running" before it triggers the training process. +This waiting is necessary because each trainer needs to talk to all parameter servers, as shown in Figure. 1. Kubernetes [API](/docs/api-reference/v1/operations/#_list_or_watch_objects_of_kind_pod) enables trainers to check the status of pods, so the Python script could wait until all parameter servers’ status change to "running" before it triggers the training process. Currently, the mapping from data shards to pods/trainers is static. If we are going to run N trainers, we would need to partition the data into N shards, and statically assign each shard to a trainer. Again we rely on the Kubernetes API to enlist pods in a job so could we index pods / trainers from 1 to N. The i-th trainer would read the i-th data shard. diff --git a/content/en/blog/_posts/2017-03-00-Advanced-Scheduling-In-Kubernetes.md b/content/en/blog/_posts/2017-03-00-Advanced-Scheduling-In-Kubernetes.md index 615c7a8350..d8afd2264a 100644 --- a/content/en/blog/_posts/2017-03-00-Advanced-Scheduling-In-Kubernetes.md +++ b/content/en/blog/_posts/2017-03-00-Advanced-Scheduling-In-Kubernetes.md @@ -6,13 +6,13 @@ url: /blog/2017/03/Advanced-Scheduling-In-Kubernetes --- _Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1.6) on what's new in Kubernetes 1.6_ -The Kubernetes scheduler’s default behavior works well for most cases -- for example, it ensures that pods are only placed on nodes that have sufficient free resources, it ties to spread pods from the same set ([ReplicaSet](https://kubernetes.io/docs/user-guide/replicasets/), [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/), etc.) across nodes, it tries to balance out the resource utilization of nodes, etc. +The Kubernetes scheduler’s default behavior works well for most cases -- for example, it ensures that pods are only placed on nodes that have sufficient free resources, it ties to spread pods from the same set ([ReplicaSet](/docs/user-guide/replicasets/), [StatefulSet](/docs/concepts/workloads/controllers/statefulset/), etc.) across nodes, it tries to balance out the resource utilization of nodes, etc. But sometimes you want to control how your pods are scheduled. For example, perhaps you want to ensure that certain pods only schedule on nodes with specialized hardware, or you want to co-locate services that communicate frequently, or you want to dedicate a set of nodes to a particular set of users. Ultimately, you know much more about how your applications should be scheduled and deployed than Kubernetes ever will. So **[Kubernetes 1.6](https://kubernetes.io/blog/2017/03/kubernetes-1.6-multi-user-multi-workloads-at-scale) offers four advanced scheduling features: node affinity/anti-affinity, taints and tolerations, pod affinity/anti-affinity, and custom schedulers**. Each of these features are now in _beta_ in Kubernetes 1.6. **Node Affinity/Anti-Affinity** -[Node Affinity/Anti-Affinity](https://kubernetes.io/docs/user-guide/node-selection/#node-affinity-beta-feature) is one way to set rules on which nodes are selected by the scheduler. This feature is a generalization of the [nodeSelector](https://kubernetes.io/docs/user-guide/node-selection/#nodeselector) feature which has been in Kubernetes since version 1.0. The rules are defined using the familiar concepts of custom labels on nodes and selectors specified in pods, and they can be either required or preferred, depending on how strictly you want the scheduler to enforce them. +[Node Affinity/Anti-Affinity](/docs/user-guide/node-selection/#node-affinity-beta-feature) is one way to set rules on which nodes are selected by the scheduler. This feature is a generalization of the [nodeSelector](/docs/user-guide/node-selection/#nodeselector) feature which has been in Kubernetes since version 1.0. The rules are defined using the familiar concepts of custom labels on nodes and selectors specified in pods, and they can be either required or preferred, depending on how strictly you want the scheduler to enforce them. Required rules must be met for a pod to schedule on a particular node. If no node matches the criteria (plus all of the other normal criteria, such as having enough free resources for the pod’s resource request), then the pod won’t be scheduled. Required rules are specified in the requiredDuringSchedulingIgnoredDuringExecution field of nodeAffinity. @@ -91,7 +91,7 @@ Additional use cases for this feature are to restrict scheduling based on nodes **Taints and Tolerations** -A related feature is “[taints and tolerations](https://kubernetes.io/docs/user-guide/node-selection/#taints-and-toleations-beta-feature),” which allows you to mark (“taint”) a node so that no pods can schedule onto it unless a pod explicitly “tolerates” the taint. Marking nodes instead of pods (as in node affinity/anti-affinity) is particularly useful for situations where most pods in the cluster should avoid scheduling onto the node. For example, you might want to mark your master node as schedulable only by Kubernetes system components, or dedicate a set of nodes to a particular group of users, or keep regular pods away from nodes that have special hardware so as to leave room for pods that need the special hardware. +A related feature is “[taints and tolerations](/docs/user-guide/node-selection/#taints-and-toleations-beta-feature),” which allows you to mark (“taint”) a node so that no pods can schedule onto it unless a pod explicitly “tolerates” the taint. Marking nodes instead of pods (as in node affinity/anti-affinity) is particularly useful for situations where most pods in the cluster should avoid scheduling onto the node. For example, you might want to mark your master node as schedulable only by Kubernetes system components, or dedicate a set of nodes to a particular group of users, or keep regular pods away from nodes that have special hardware so as to leave room for pods that need the special hardware. The kubectl command allows you to set taints on nodes, for example: @@ -120,7 +120,7 @@ tolerations: -In addition to moving taints and tolerations to _beta_ in Kubernetes 1.6, we have introduced an _alpha_ feature that uses taints and tolerations to allow you to customize how long a pod stays bound to a node when the node experiences a problem like a network partition instead of using the default five minutes. See [this section](https://kubernetes.io/docs/user-guide/node-selection/#per-pod-configurable-eviction-behavior-when-there-are-node-problems-alpha-feature) of the documentation for more details. +In addition to moving taints and tolerations to _beta_ in Kubernetes 1.6, we have introduced an _alpha_ feature that uses taints and tolerations to allow you to customize how long a pod stays bound to a node when the node experiences a problem like a network partition instead of using the default five minutes. See [this section](/docs/user-guide/node-selection/#per-pod-configurable-eviction-behavior-when-there-are-node-problems-alpha-feature) of the documentation for more details. @@ -128,7 +128,7 @@ In addition to moving taints and tolerations to _beta_ in Kubernetes 1.6, we hav -Node affinity/anti-affinity allows you to constrain which nodes a pod can run on based on the nodes’ labels. But what if you want to specify rules about how pods should be placed relative to one another, for example to spread or pack pods within a service or relative to pods in other services? For that you can use [pod affinity/anti-affinity](https://kubernetes.io/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature), which is also _beta_ in Kubernetes 1.6. +Node affinity/anti-affinity allows you to constrain which nodes a pod can run on based on the nodes’ labels. But what if you want to specify rules about how pods should be placed relative to one another, for example to spread or pack pods within a service or relative to pods in other services? For that you can use [pod affinity/anti-affinity](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature), which is also _beta_ in Kubernetes 1.6. @@ -163,7 +163,7 @@ Pod affinity/anti-affinity is very flexible. Imagine you have profiled the perfo **Custom Schedulers** -If the Kubernetes scheduler’s various features don’t give you enough control over the scheduling of your workloads, you can delegate responsibility for scheduling arbitrary subsets of pods to your own custom scheduler(s) that run(s) alongside, or instead of, the default Kubernetes scheduler. [Multiple schedulers](https://kubernetes.io/docs/admin/multiple-schedulers/) is _beta_ in Kubernetes 1.6. +If the Kubernetes scheduler’s various features don’t give you enough control over the scheduling of your workloads, you can delegate responsibility for scheduling arbitrary subsets of pods to your own custom scheduler(s) that run(s) alongside, or instead of, the default Kubernetes scheduler. [Multiple schedulers](/docs/admin/multiple-schedulers/) is _beta_ in Kubernetes 1.6. Each new pod is normally scheduled by the default scheduler. But if you provide the name of your own custom scheduler, the default scheduler will ignore that Pod and allow your scheduler to schedule the Pod to a node. Let’s look at an example. diff --git a/content/en/blog/_posts/2017-03-00-Dynamic-Provisioning-And-Storage-Classes-Kubernetes.md b/content/en/blog/_posts/2017-03-00-Dynamic-Provisioning-And-Storage-Classes-Kubernetes.md index 18a3aa0a8e..2ea326f56a 100644 --- a/content/en/blog/_posts/2017-03-00-Dynamic-Provisioning-And-Storage-Classes-Kubernetes.md +++ b/content/en/blog/_posts/2017-03-00-Dynamic-Provisioning-And-Storage-Classes-Kubernetes.md @@ -9,9 +9,9 @@ _Editor’s note: this post is part of a [series of in-depth articles](https://k -Storage is a critical part of running stateful containers, and Kubernetes offers powerful primitives for managing it. Dynamic volume provisioning, a feature unique to Kubernetes, allows storage volumes to be created on-demand. Before dynamic provisioning, cluster administrators had to manually make calls to their cloud or storage provider to provision new storage volumes, and then create PersistentVolume objects to represent them in Kubernetes. With dynamic provisioning, these two steps are automated, eliminating the need for cluster administrators to pre-provision storage. Instead, the storage resources can be dynamically provisioned using the provisioner specified by the StorageClass object (see [user-guide](https://kubernetes.io/docs/user-guide/persistent-volumes/index#storageclasses)). StorageClasses are essentially blueprints that abstract away the underlying storage provider, as well as other parameters, like disk-type (e.g.; solid-state vs standard disks). +Storage is a critical part of running stateful containers, and Kubernetes offers powerful primitives for managing it. Dynamic volume provisioning, a feature unique to Kubernetes, allows storage volumes to be created on-demand. Before dynamic provisioning, cluster administrators had to manually make calls to their cloud or storage provider to provision new storage volumes, and then create PersistentVolume objects to represent them in Kubernetes. With dynamic provisioning, these two steps are automated, eliminating the need for cluster administrators to pre-provision storage. Instead, the storage resources can be dynamically provisioned using the provisioner specified by the StorageClass object (see [user-guide](/docs/user-guide/persistent-volumes/index#storageclasses)). StorageClasses are essentially blueprints that abstract away the underlying storage provider, as well as other parameters, like disk-type (e.g.; solid-state vs standard disks). -StorageClasses use provisioners that are specific to the storage platform or cloud provider to give Kubernetes access to the physical media being used. Several storage provisioners are provided in-tree (see [user-guide](https://kubernetes.io/docs/user-guide/persistent-volumes/index#provisioner)), but additionally out-of-tree provisioners are now supported (see [kubernetes-incubator](https://github.com/kubernetes-incubator/external-storage)). +StorageClasses use provisioners that are specific to the storage platform or cloud provider to give Kubernetes access to the physical media being used. Several storage provisioners are provided in-tree (see [user-guide](/docs/user-guide/persistent-volumes/index#provisioner)), but additionally out-of-tree provisioners are now supported (see [kubernetes-incubator](https://github.com/kubernetes-incubator/external-storage)). In the [Kubernetes 1.6 release](https://kubernetes.io/blog/2017/03/kubernetes-1.6-multi-user-multi-workloads-at-scale), **dynamic provisioning has been promoted to stable** (having entered beta in 1.4). This is a big step forward in completing the Kubernetes storage automation vision, allowing cluster administrators to control how resources are provisioned and giving users the ability to focus more on their application. With all of these benefits, **there are a few important user-facing changes (discussed below) that are important to understand before using Kubernetes 1.6**. @@ -78,7 +78,7 @@ The following table provides more detail on default storage classes pre-installe | VMware vSphere | thin | vsphere-volume | -While these pre-installed default storage classes are chosen to be “reasonable” for most storage users, [this guide](https://kubernetes.io/docs/tasks/administer-cluster/change-default-storage-class) provides instructions on how to specify your own default. +While these pre-installed default storage classes are chosen to be “reasonable” for most storage users, [this guide](/docs/tasks/administer-cluster/change-default-storage-class) provides instructions on how to specify your own default. @@ -86,13 +86,13 @@ While these pre-installed default storage classes are chosen to be “reasonable -All PVs have a reclaim policy associated with them that dictates what happens to a PV once it becomes released from a claim (see [user-guide](https://kubernetes.io/docs/user-guide/persistent-volumes/#reclaiming)). Since the goal of dynamic provisioning is to completely automate the lifecycle of storage resources, the default reclaim policy for dynamically provisioned volumes is “delete”. This means that when a PersistentVolumeClaim (PVC) is released, the dynamically provisioned volume is de-provisioned (deleted) on the storage provider and the data is likely irretrievable. If this is not the desired behavior, the user must change the reclaim policy on the corresponding PersistentVolume (PV) object after the volume is provisioned. +All PVs have a reclaim policy associated with them that dictates what happens to a PV once it becomes released from a claim (see [user-guide](/docs/user-guide/persistent-volumes/#reclaiming)). Since the goal of dynamic provisioning is to completely automate the lifecycle of storage resources, the default reclaim policy for dynamically provisioned volumes is “delete”. This means that when a PersistentVolumeClaim (PVC) is released, the dynamically provisioned volume is de-provisioned (deleted) on the storage provider and the data is likely irretrievable. If this is not the desired behavior, the user must change the reclaim policy on the corresponding PersistentVolume (PV) object after the volume is provisioned. **How do I change the reclaim policy on a dynamically provisioned volume?** -You can change the reclaim policy by editing the PV object and changing the “persistentVolumeReclaimPolicy” field to the desired value. For more information on various reclaim policies see [user-guide](https://kubernetes.io/docs/user-guide/persistent-volumes/#reclaim-policy). +You can change the reclaim policy by editing the PV object and changing the “persistentVolumeReclaimPolicy” field to the desired value. For more information on various reclaim policies see [user-guide](/docs/user-guide/persistent-volumes/#reclaim-policy). diff --git a/content/en/blog/_posts/2017-03-00-Kubernetes-1-6-Multi-User-Multi-Workloads-At-Scale.md b/content/en/blog/_posts/2017-03-00-Kubernetes-1-6-Multi-User-Multi-Workloads-At-Scale.md index d22811dc3a..d6a16b391d 100644 --- a/content/en/blog/_posts/2017-03-00-Kubernetes-1-6-Multi-User-Multi-Workloads-At-Scale.md +++ b/content/en/blog/_posts/2017-03-00-Kubernetes-1-6-Multi-User-Multi-Workloads-At-Scale.md @@ -6,60 +6,60 @@ url: /blog/2017/03/Kubernetes-1.6-Multi-User-Multi-Workloads-At-Scale --- Today we’re announcing the release of Kubernetes 1.6. -In this release the community’s focus is on scale and automation, to help you deploy multiple workloads to multiple users on a cluster. We are announcing that 5,000 node clusters are supported. We moved dynamic storage provisioning to _stable_. Role-based access control ([RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)), [kubefed](https://kubernetes.io/docs/tutorials/federation/set-up-cluster-federation-kubefed/), [kubeadm](https://kubernetes.io/docs/getting-started-guides/kubeadm/), and several scheduling features are moving to _beta_. We have also added intelligent defaults throughout to enable greater automation out of the box. +In this release the community’s focus is on scale and automation, to help you deploy multiple workloads to multiple users on a cluster. We are announcing that 5,000 node clusters are supported. We moved dynamic storage provisioning to _stable_. Role-based access control ([RBAC](/docs/reference/access-authn-authz/rbac/)), [kubefed](/docs/tutorials/federation/set-up-cluster-federation-kubefed/), [kubeadm](/docs/getting-started-guides/kubeadm/), and several scheduling features are moving to _beta_. We have also added intelligent defaults throughout to enable greater automation out of the box. **What’s New** **Scale and Federation** : Large enterprise users looking for proof of at-scale performance will be pleased to know that Kubernetes’ stringent scalability [SLO](https://kubernetes.io/blog/2016/03/1000-nodes-and-beyond-updates-to-Kubernetes-performance-and-scalability-in-12) now supports 5,000 node (150,000 pod) clusters. This 150% increase in total cluster size, powered by a new version of [etcd v3](https://coreos.com/blog/etcd3-a-new-etcd.html) by CoreOS, is great news if you are deploying applications such as search or games which can grow to consume larger clusters. -For users who want to scale beyond 5,000 nodes or spread across multiple regions or clouds, [federation](https://kubernetes.io/docs/concepts/cluster-administration/federation/) lets you combine multiple Kubernetes clusters and address them through a single API endpoint. In this release, the [kubefed](https://kubernetes.io//docs/tutorials/federation/set-up-cluster-federation-kubefed) command line utility graduated to _beta_ - with improved support for on-premise clusters. kubefed now [automatically configures](https://kubernetes.io//docs/tutorials/federation/set-up-cluster-federation-kubefed.md#kube-dns-configuration) kube-dns on joining clusters and can pass arguments to federated components. +For users who want to scale beyond 5,000 nodes or spread across multiple regions or clouds, [federation](/docs/concepts/cluster-administration/federation/) lets you combine multiple Kubernetes clusters and address them through a single API endpoint. In this release, the [kubefed](https://kubernetes.io//docs/tutorials/federation/set-up-cluster-federation-kubefed) command line utility graduated to _beta_ - with improved support for on-premise clusters. kubefed now [automatically configures](https://kubernetes.io//docs/tutorials/federation/set-up-cluster-federation-kubefed.md#kube-dns-configuration) kube-dns on joining clusters and can pass arguments to federated components. -**Security and Setup** : Users concerned with security will find that [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac), now _beta_ adds a significant security benefit through more tightly scoped default roles for system components. The default RBAC policies in 1.6 grant scoped permissions to control-plane components, nodes, and controllers. RBAC allows cluster administrators to selectively grant particular users or service accounts fine-grained access to specific resources on a per-namespace basis. RBAC users upgrading from 1.5 to 1.6 should view the guidance [here](https://kubernetes.io/docs/reference/access-authn-authz/rbac#upgrading-from-1-5).  +**Security and Setup** : Users concerned with security will find that [RBAC](/docs/reference/access-authn-authz/rbac), now _beta_ adds a significant security benefit through more tightly scoped default roles for system components. The default RBAC policies in 1.6 grant scoped permissions to control-plane components, nodes, and controllers. RBAC allows cluster administrators to selectively grant particular users or service accounts fine-grained access to specific resources on a per-namespace basis. RBAC users upgrading from 1.5 to 1.6 should view the guidance [here](/docs/reference/access-authn-authz/rbac#upgrading-from-1-5).  -Users looking for an easy way to provision a secure cluster on physical or cloud servers can use [kubeadm](https://kubernetes.io/docs/getting-started-guides/kubeadm/), which is now _beta_. kubeadm has been enhanced with a set of command line flags and a base feature set that includes RBAC setup, use of the [Bootstrap Token system](http://kubernetes.io/docs/reference/access-authn-authz/bootstrap-tokens/) and an enhanced [Certificates API](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/). +Users looking for an easy way to provision a secure cluster on physical or cloud servers can use [kubeadm](/docs/getting-started-guides/kubeadm/), which is now _beta_. kubeadm has been enhanced with a set of command line flags and a base feature set that includes RBAC setup, use of the [Bootstrap Token system](/docs/reference/access-authn-authz/bootstrap-tokens/) and an enhanced [Certificates API](/docs/tasks/tls/managing-tls-in-a-cluster/). -**Advanced Scheduling** : This release adds a set of [powerful and versatile scheduling constructs](https://kubernetes.io/docs/user-guide/node-selection/) to give you greater control over how pods are scheduled, including rules to restrict pods to particular nodes in heterogeneous clusters, and rules to spread or pack pods across failure domains such as nodes, racks, and zones. +**Advanced Scheduling** : This release adds a set of [powerful and versatile scheduling constructs](/docs/user-guide/node-selection/) to give you greater control over how pods are scheduled, including rules to restrict pods to particular nodes in heterogeneous clusters, and rules to spread or pack pods across failure domains such as nodes, racks, and zones. -[Node affinity/anti-affinity](https://kubernetes.io/docs/user-guide/node-selection/#node-affinity-beta-feature), now in _beta_, allows you to restrict pods to schedule only on certain nodes based on node labels. Use built-in or custom node labels to select specific zones, hostnames, hardware architecture, operating system version, specialized hardware, etc. The scheduling rules can be required or preferred, depending on how strictly you want the scheduler to enforce them. +[Node affinity/anti-affinity](/docs/user-guide/node-selection/#node-affinity-beta-feature), now in _beta_, allows you to restrict pods to schedule only on certain nodes based on node labels. Use built-in or custom node labels to select specific zones, hostnames, hardware architecture, operating system version, specialized hardware, etc. The scheduling rules can be required or preferred, depending on how strictly you want the scheduler to enforce them. -A related feature, called [taints and tolerations](https://kubernetes.io/docs/user-guide/node-selection/#taints-and-tolerations-beta-feature), makes it possible to compactly represent rules for excluding pods from particular nodes. The feature, also now in _beta_, makes it easy, for example, to dedicate sets of nodes to particular sets of users, or to keep nodes that have special hardware available for pods that need the special hardware by excluding pods that don’t need it. +A related feature, called [taints and tolerations](/docs/user-guide/node-selection/#taints-and-tolerations-beta-feature), makes it possible to compactly represent rules for excluding pods from particular nodes. The feature, also now in _beta_, makes it easy, for example, to dedicate sets of nodes to particular sets of users, or to keep nodes that have special hardware available for pods that need the special hardware by excluding pods that don’t need it. -Sometimes you want to co-schedule services, or pods within a service, near each other topologically, for example to optimize North-South or East-West communication. Or you want to spread pods of a service for failure tolerance, or keep antagonistic pods separated, or ensure sole tenancy of nodes. [Pod affinity and anti-affinity](https://kubernetes.io/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature), now in _beta_, enables such use cases by letting you set hard or soft requirements for spreading and packing pods relative to one another within arbitrary topologies (node, zone, etc.). +Sometimes you want to co-schedule services, or pods within a service, near each other topologically, for example to optimize North-South or East-West communication. Or you want to spread pods of a service for failure tolerance, or keep antagonistic pods separated, or ensure sole tenancy of nodes. [Pod affinity and anti-affinity](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature), now in _beta_, enables such use cases by letting you set hard or soft requirements for spreading and packing pods relative to one another within arbitrary topologies (node, zone, etc.). -Lastly, for the ultimate in scheduling flexibility, you can run your own custom scheduler(s) alongside, or instead of, the default Kubernetes scheduler. Each scheduler is responsible for different sets of pods. [Multiple schedulers](https://kubernetes.io/docs/admin/multiple-schedulers/) is _beta_ in this release.  +Lastly, for the ultimate in scheduling flexibility, you can run your own custom scheduler(s) alongside, or instead of, the default Kubernetes scheduler. Each scheduler is responsible for different sets of pods. [Multiple schedulers](/docs/admin/multiple-schedulers/) is _beta_ in this release.  **Dynamic Storage Provisioning** : Users deploying stateful applications will benefit from the extensive storage automation capabilities in this release of Kubernetes. -Since its early days, Kubernetes has been able to automatically attach and detach storage, format disk, mount and unmount volumes per the pod spec, and do so seamlessly as pods move between nodes. In addition, the PersistentVolumeClaim (PVC) and PersistentVolume (PV) objects decouple the request for storage from the specific storage implementation, making the pod spec portable across a range of cloud and on-premise environments. In this release [StorageClass](https://kubernetes.io/docs/user-guide/persistent-volumes/#storageclasses) and [dynamic volume provisioning](https://kubernetes.io/docs/user-guide/persistent-volumes/#dynamic) are promoted to _stable_, completing the automation story by creating and deleting storage on demand, eliminating the need to pre-provision. +Since its early days, Kubernetes has been able to automatically attach and detach storage, format disk, mount and unmount volumes per the pod spec, and do so seamlessly as pods move between nodes. In addition, the PersistentVolumeClaim (PVC) and PersistentVolume (PV) objects decouple the request for storage from the specific storage implementation, making the pod spec portable across a range of cloud and on-premise environments. In this release [StorageClass](/docs/user-guide/persistent-volumes/#storageclasses) and [dynamic volume provisioning](/docs/user-guide/persistent-volumes/#dynamic) are promoted to _stable_, completing the automation story by creating and deleting storage on demand, eliminating the need to pre-provision. The design allows cluster administrators to define and expose multiple flavors of storage within a cluster, each with a custom set of parameters. End users can stop worrying about the complexity and nuances of how storage is provisioned, while still selecting from multiple storage options. -In 1.6 Kubernetes comes with a set of built-in defaults to completely automate the storage provisioning lifecycle, freeing you to work on your applications. Specifically, Kubernetes now pre-installs system-defined StorageClass objects for AWS, Azure, GCP, OpenStack and VMware vSphere [by default](https://kubernetes.io/docs/tasks/administer-cluster/change-default-storage-class). This gives Kubernetes users on these providers the benefits of dynamic storage provisioning without having to manually setup StorageClass objects. This is a [change in the default behavior](https://kubernetes.io/docs/user-guide/persistent-volumes/index#class-1) of PVC objects on these clouds. Note that default behavior is that dynamically provisioned volumes are created with the “delete” [reclaim policy](https://kubernetes.io/docs/user-guide/persistent-volumes#reclaim-policy). That means once the PVC is deleted, the dynamically provisioned volume is automatically deleted so users do not have the extra step of ‘cleaning up’. +In 1.6 Kubernetes comes with a set of built-in defaults to completely automate the storage provisioning lifecycle, freeing you to work on your applications. Specifically, Kubernetes now pre-installs system-defined StorageClass objects for AWS, Azure, GCP, OpenStack and VMware vSphere [by default](/docs/tasks/administer-cluster/change-default-storage-class). This gives Kubernetes users on these providers the benefits of dynamic storage provisioning without having to manually setup StorageClass objects. This is a [change in the default behavior](/docs/user-guide/persistent-volumes/index#class-1) of PVC objects on these clouds. Note that default behavior is that dynamically provisioned volumes are created with the “delete” [reclaim policy](/docs/user-guide/persistent-volumes#reclaim-policy). That means once the PVC is deleted, the dynamically provisioned volume is automatically deleted so users do not have the extra step of ‘cleaning up’. In addition, we have expanded the range of storage supported overall including: -- ScaleIO Kubernetes [Volume Plugin](https://kubernetes.io/docs/user-guide/persistent-volumes/index#scaleio) enabling pods to seamlessly access and use data stored on ScaleIO volumes. -- Portworx Kubernetes [Volume Plugin](https://kubernetes.io/docs/user-guide/persistent-volumes/index#portworx-volume) adding the capability to use Portworx as a storage provider for Kubernetes clusters. Portworx pools your server capacity and turns your servers or cloud instances into converged, highly available compute and storage nodes. +- ScaleIO Kubernetes [Volume Plugin](/docs/user-guide/persistent-volumes/index#scaleio) enabling pods to seamlessly access and use data stored on ScaleIO volumes. +- Portworx Kubernetes [Volume Plugin](/docs/user-guide/persistent-volumes/index#portworx-volume) adding the capability to use Portworx as a storage provider for Kubernetes clusters. Portworx pools your server capacity and turns your servers or cloud instances into converged, highly available compute and storage nodes. - Support for NFSv3, NFSv4, and GlusterFS on clusters using the [COS node image](https://cloud.google.com/container-engine/docs/node-image-migration)  - Support for user-written/run dynamic PV provisioners. A golang library and examples can be found [here](http://github.com/kubernetes-incubator/external-storage). -- _Beta_ support for [mount options](https://kubernetes.io/docs/user-guide/persistent-volumes/index.md#mount-options) in persistent volumes +- _Beta_ support for [mount options](/docs/user-guide/persistent-volumes/index.md#mount-options) in persistent volumes **Container Runtime Interface, etcd v3 and Daemon set updates** : while users may not directly interact with the container runtime or the API server datastore, they are foundational components for user facing functionality in Kubernetes’. As such the community invests in expanding the capabilities of these and other system components. - The Docker-CRI implementation is _beta_ and is enabled by default in kubelet. _Alpha_ support for other runtimes, [cri-o](https://github.com/kubernetes-incubator/cri-o/releases/tag/v0.1), [frakti](https://github.com/kubernetes/frakti/releases/tag/v0.1), [rkt](https://github.com/coreos/rkt/issues?q=is%3Aopen+is%3Aissue+label%3Aarea%2Fcri), has also been implemented. -- The default backend storage for the API server has been [upgraded](https://kubernetes.io/docs/admin/upgrade-1-6/) to use [etcd v3](https://coreos.com/blog/etcd3-a-new-etcd.html) by default for new clusters. If you are upgrading from a 1.5 cluster, care should be taken to ensure continuity by planning a data migration window.  +- The default backend storage for the API server has been [upgraded](/docs/admin/upgrade-1-6/) to use [etcd v3](https://coreos.com/blog/etcd3-a-new-etcd.html) by default for new clusters. If you are upgrading from a 1.5 cluster, care should be taken to ensure continuity by planning a data migration window.  - Node reliability is improved as Kubelet exposes an admin configurable [Node Allocatable](https://kubernetes.io//docs/admin/node-allocatable.md#node-allocatable) feature to reserve compute resources for system daemons. -- [Daemon set updates](https://kubernetes.io/docs/tasks/manage-daemon/update-daemon-set) lets you perform rolling updates on a daemon set +- [Daemon set updates](/docs/tasks/manage-daemon/update-daemon-set) lets you perform rolling updates on a daemon set **Alpha features** : this release was mostly focused on maturing functionality, however, a few alpha features were added to support the roadmap -- [Out-of-tree cloud provider](https://kubernetes.io/docs/concepts/overview/components#cloud-controller-manager) support adds a new cloud-controller-manager binary that may be used for testing the new out-of-core cloud provider flow -- [Per-pod-eviction](https://kubernetes.io/docs/user-guide/node-selection/#per-pod-configurable-eviction-behavior-when-there-are-node-problems-alpha-feature) in case of node problems combined with tolerationSeconds, lets users tune the duration a pod stays bound to a node that is experiencing problems -- [Pod Injection Policy](https://kubernetes.io/docs/user-guide/pod-preset/) adds a new API resource PodPreset to inject information such as secrets, volumes, volume mounts, and environment variables into pods at creation time. -- [Custom metrics](https://kubernetes.io/docs/user-guide/horizontal-pod-autoscaling/#support-for-custom-metrics) support in the Horizontal Pod Autoscaler changed to use  +- [Out-of-tree cloud provider](/docs/concepts/overview/components#cloud-controller-manager) support adds a new cloud-controller-manager binary that may be used for testing the new out-of-core cloud provider flow +- [Per-pod-eviction](/docs/user-guide/node-selection/#per-pod-configurable-eviction-behavior-when-there-are-node-problems-alpha-feature) in case of node problems combined with tolerationSeconds, lets users tune the duration a pod stays bound to a node that is experiencing problems +- [Pod Injection Policy](/docs/user-guide/pod-preset/) adds a new API resource PodPreset to inject information such as secrets, volumes, volume mounts, and environment variables into pods at creation time. +- [Custom metrics](/docs/user-guide/horizontal-pod-autoscaling/#support-for-custom-metrics) support in the Horizontal Pod Autoscaler changed to use  - Multiple Nvidia [GPU support](https://vishh.github.io/docs/user-guide/gpus/) is introduced with the Docker runtime only @@ -89,7 +89,7 @@ We’re continuing to see rapid adoption of Kubernetes in all sectors and sizes - Share your Kubernetes use case story with the community [here](https://docs.google.com/a/google.com/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform). **Availability** -Kubernetes 1.6 is available for download [here](https://github.com/kubernetes/kubernetes/releases/tag/v1.6.0) on GitHub and via [get.k8s.io](http://get.k8s.io/). To get started with Kubernetes, try one of the these [interactive tutorials](http://kubernetes.io/docs/tutorials/kubernetes-basics/).  +Kubernetes 1.6 is available for download [here](https://github.com/kubernetes/kubernetes/releases/tag/v1.6.0) on GitHub and via [get.k8s.io](http://get.k8s.io/). To get started with Kubernetes, try one of the these [interactive tutorials](/docs/tutorials/kubernetes-basics/).  **Get Involved** diff --git a/content/en/blog/_posts/2017-03-00-Scalability-Updates-In-Kubernetes-1-6.md b/content/en/blog/_posts/2017-03-00-Scalability-Updates-In-Kubernetes-1-6.md index a72112baf9..3ed8bf2d44 100644 --- a/content/en/blog/_posts/2017-03-00-Scalability-Updates-In-Kubernetes-1-6.md +++ b/content/en/blog/_posts/2017-03-00-Scalability-Updates-In-Kubernetes-1-6.md @@ -69,7 +69,7 @@ We want to emphasize that the optimization work we have done during the last few **What’s next?** -People frequently ask how far we are going to go in improving Kubernetes scalability. Currently we do not have plans to increase scalability beyond 5000-node clusters (within our SLOs) in the next few releases. If you need clusters larger than 5000 nodes, we recommend to use [federation](https://kubernetes.io/docs/concepts/cluster-administration/federation/) to aggregate multiple Kubernetes clusters. +People frequently ask how far we are going to go in improving Kubernetes scalability. Currently we do not have plans to increase scalability beyond 5000-node clusters (within our SLOs) in the next few releases. If you need clusters larger than 5000 nodes, we recommend to use [federation](/docs/concepts/cluster-administration/federation/) to aggregate multiple Kubernetes clusters. However, that doesn’t mean we are going to stop working on scalability and performance. As we mentioned at the beginning of this post, our top priority is to refine our two existing SLOs and introduce new ones that will cover more parts of the system, e.g. networking. This effort has already started within the Scalability SIG. We have made significant progress on how we would like to define performance SLOs, and this work should be finished in the coming month. diff --git a/content/en/blog/_posts/2017-04-00-Configuring-Private-Dns-Zones-Upstream-Nameservers-Kubernetes.md b/content/en/blog/_posts/2017-04-00-Configuring-Private-Dns-Zones-Upstream-Nameservers-Kubernetes.md index 6b8df58863..49c2e0a543 100644 --- a/content/en/blog/_posts/2017-04-00-Configuring-Private-Dns-Zones-Upstream-Nameservers-Kubernetes.md +++ b/content/en/blog/_posts/2017-04-00-Configuring-Private-Dns-Zones-Upstream-Nameservers-Kubernetes.md @@ -6,7 +6,7 @@ url: /blog/2017/04/Configuring-Private-Dns-Zones-Upstream-Nameservers-Kubernetes --- _Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1.6) on what's new in Kubernetes 1.6_ -Many users have existing domain name zones that they would like to integrate into their Kubernetes DNS namespace. For example, hybrid-cloud users may want to resolve their internal “.corp” domain addresses within the cluster. Other users may have a zone populated by a non-Kubernetes service discovery system (like Consul). We’re pleased to announce that, in [Kubernetes 1.6](https://kubernetes.io/blog/2017/03/kubernetes-1.6-multi-user-multi-workloads-at-scale), [kube-dns](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/) adds support for configurable private DNS zones (often called “stub domains”) and external upstream DNS nameservers. In this blog post, we describe how to configure and use this feature. +Many users have existing domain name zones that they would like to integrate into their Kubernetes DNS namespace. For example, hybrid-cloud users may want to resolve their internal “.corp” domain addresses within the cluster. Other users may have a zone populated by a non-Kubernetes service discovery system (like Consul). We’re pleased to announce that, in [Kubernetes 1.6](https://kubernetes.io/blog/2017/03/kubernetes-1.6-multi-user-multi-workloads-at-scale), [kube-dns](/docs/concepts/services-networking/dns-pod-service/) adds support for configurable private DNS zones (often called “stub domains”) and external upstream DNS nameservers. In this blog post, we describe how to configure and use this feature. **Default lookup flow** diff --git a/content/en/blog/_posts/2017-04-00-Multi-Stage-Canary-Deployments-With-Kubernetes-In-The-Cloud-Onprem.md b/content/en/blog/_posts/2017-04-00-Multi-Stage-Canary-Deployments-With-Kubernetes-In-The-Cloud-Onprem.md index c23bc90264..976e628c19 100644 --- a/content/en/blog/_posts/2017-04-00-Multi-Stage-Canary-Deployments-With-Kubernetes-In-The-Cloud-Onprem.md +++ b/content/en/blog/_posts/2017-04-00-Multi-Stage-Canary-Deployments-With-Kubernetes-In-The-Cloud-Onprem.md @@ -98,7 +98,7 @@ spec: -In front of the Kubernetes services, load balancing the different canary versions of the service, lives a small cluster of HAProxy pods that get their haproxy.conf from the Kubernetes [ConfigMaps](https://kubernetes.io/docs/tasks/configure-pod-container/configmap/) that looks something like this: +In front of the Kubernetes services, load balancing the different canary versions of the service, lives a small cluster of HAProxy pods that get their haproxy.conf from the Kubernetes [ConfigMaps](/docs/tasks/configure-pod-container/configmap/) that looks something like this: diff --git a/content/en/blog/_posts/2017-04-00-Rbac-Support-In-Kubernetes.md b/content/en/blog/_posts/2017-04-00-Rbac-Support-In-Kubernetes.md index 26d8b40186..1b496157a7 100644 --- a/content/en/blog/_posts/2017-04-00-Rbac-Support-In-Kubernetes.md +++ b/content/en/blog/_posts/2017-04-00-Rbac-Support-In-Kubernetes.md @@ -13,7 +13,7 @@ The focus of this post is to highlight some of the interesting new capabilities **RBAC vs ABAC** -Currently there are several [authorization mechanisms](https://kubernetes.io/docs/reference/access-authn-authz/authorization/) available for use with Kubernetes. Authorizers are the mechanisms that decide who is permitted to make what changes to the cluster using the Kubernetes API. This affects things like kubectl, system components, and also certain applications that run in the cluster and manipulate the state of the cluster, like Jenkins with the Kubernetes plugin, or [Helm](https://github.com/kubernetes/helm) that runs in the cluster and uses the Kubernetes API to install applications in the cluster. Out of the available authorization mechanisms, ABAC and RBAC are the mechanisms local to a Kubernetes cluster that allow configurable permissions policies. +Currently there are several [authorization mechanisms](/docs/reference/access-authn-authz/authorization/) available for use with Kubernetes. Authorizers are the mechanisms that decide who is permitted to make what changes to the cluster using the Kubernetes API. This affects things like kubectl, system components, and also certain applications that run in the cluster and manipulate the state of the cluster, like Jenkins with the Kubernetes plugin, or [Helm](https://github.com/kubernetes/helm) that runs in the cluster and uses the Kubernetes API to install applications in the cluster. Out of the available authorization mechanisms, ABAC and RBAC are the mechanisms local to a Kubernetes cluster that allow configurable permissions policies. ABAC, Attribute Based Access Control, is a powerful concept. However, as implemented in Kubernetes, ABAC is difficult to manage and understand. It requires ssh and root filesystem access on the master VM of the cluster to make authorization policy changes. For permission changes to take effect the cluster API server must be restarted. @@ -23,7 +23,7 @@ Based on where the Kubernetes community is focusing their development efforts, g **Basic Concepts** -There are a few basic ideas behind RBAC that are foundational in understanding it. At its core, RBAC is a way of granting users granular access to [Kubernetes API resources](https://kubernetes.io/docs/api-reference/v1.6/). +There are a few basic ideas behind RBAC that are foundational in understanding it. At its core, RBAC is a way of granting users granular access to [Kubernetes API resources](/docs/api-reference/v1.6/). [![](https://1.bp.blogspot.com/-v6KLs1tT_xI/WOa0anGP4sI/AAAAAAAABBo/KIgYfp8PjusuykUVTfgu9-2uKj_wXo4lwCLcB/s400/rbac1.png)](https://1.bp.blogspot.com/-v6KLs1tT_xI/WOa0anGP4sI/AAAAAAAABBo/KIgYfp8PjusuykUVTfgu9-2uKj_wXo4lwCLcB/s1600/rbac1.png) @@ -42,11 +42,11 @@ A RoleBinding maps a Role to a user or set of users, granting that Role's permis [![](https://1.bp.blogspot.com/-ixDe91-cnqw/WOa0auxC0mI/AAAAAAAABBs/4LxVsr6shEgTYqUapt5QPISUeuTuztVwwCEw/s640/rbac2.png)](https://1.bp.blogspot.com/-ixDe91-cnqw/WOa0auxC0mI/AAAAAAAABBs/4LxVsr6shEgTYqUapt5QPISUeuTuztVwwCEw/s1600/rbac2.png) -Additionally there are cluster roles and cluster role bindings to consider. Cluster roles and cluster role bindings function like roles and role bindings except they have wider scope. The exact differences and how cluster roles and cluster role bindings interact with roles and role bindings are covered in the [Kubernetes documentation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding). +Additionally there are cluster roles and cluster role bindings to consider. Cluster roles and cluster role bindings function like roles and role bindings except they have wider scope. The exact differences and how cluster roles and cluster role bindings interact with roles and role bindings are covered in the [Kubernetes documentation](/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding). **RBAC in Kubernetes** -RBAC is now deeply integrated into Kubernetes and used by the system components to grant the permissions necessary for them to function. [System roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) are typically prefixed with system: so they can be easily recognized. +RBAC is now deeply integrated into Kubernetes and used by the system components to grant the permissions necessary for them to function. [System roles](/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) are typically prefixed with system: so they can be easily recognized. ``` @@ -76,7 +76,7 @@ system:controller:certificate-controller ClusterRole.v1beta1.rbac.authorization. The RBAC system roles have been expanded to cover the necessary permissions for running a Kubernetes cluster with RBAC only. -During the permission translation from ABAC to RBAC, some of the permissions that were enabled by default in many deployments of ABAC authorized clusters were identified as unnecessarily broad and were [scoped down](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#upgrading-from-1-5) in RBAC. The area most likely to impact workloads on a cluster is the permissions available to service accounts. With the permissive ABAC configuration, requests from a pod using the pod mounted token to authenticate to the API server have broad authorization. As a concrete example, the curl command at the end of this sequence will return a JSON formatted result when ABAC is enabled and an error when only RBAC is enabled. +During the permission translation from ABAC to RBAC, some of the permissions that were enabled by default in many deployments of ABAC authorized clusters were identified as unnecessarily broad and were [scoped down](/docs/reference/access-authn-authz/rbac/#upgrading-from-1-5) in RBAC. The area most likely to impact workloads on a cluster is the permissions available to service accounts. With the permissive ABAC configuration, requests from a pod using the pod mounted token to authenticate to the API server have broad authorization. As a concrete example, the curl command at the end of this sequence will return a JSON formatted result when ABAC is enabled and an error when only RBAC is enabled. ``` @@ -96,13 +96,13 @@ During the permission translation from ABAC to RBAC, some of the permissions tha Any applications you run in your Kubernetes cluster that interact with the Kubernetes API have the potential to be affected by the permissions changes when transitioning from ABAC to RBAC. -To smooth the transition from ABAC to RBAC, you can create Kubernetes 1.6 clusters with both [ABAC and RBAC authorizers](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#parallel-authorizers) enabled. When both ABAC and RBAC are enabled, authorization for a resource is granted if either authorization policy grants access. However, under that configuration the most permissive authorizer is used and it will not be possible to use RBAC to fully control permissions. +To smooth the transition from ABAC to RBAC, you can create Kubernetes 1.6 clusters with both [ABAC and RBAC authorizers](/docs/reference/access-authn-authz/rbac/#parallel-authorizers) enabled. When both ABAC and RBAC are enabled, authorization for a resource is granted if either authorization policy grants access. However, under that configuration the most permissive authorizer is used and it will not be possible to use RBAC to fully control permissions. At this point, RBAC is complete enough that ABAC support should be considered deprecated going forward. It will still remain in Kubernetes for the foreseeable future but development attention is focused on RBAC. -Two different talks at the at the Google Cloud Next conference touched on RBAC related changes in Kubernetes 1.6, jump to the relevant parts [here](https://www.youtube.com/watch?v=Cd4JU7qzYbE#t=8m01s) and [here](https://www.youtube.com/watch?v=18P7cFc6nTU#t=41m06s). For more detailed information about using RBAC in Kubernetes 1.6 read the full [RBAC documentation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/). +Two different talks at the at the Google Cloud Next conference touched on RBAC related changes in Kubernetes 1.6, jump to the relevant parts [here](https://www.youtube.com/watch?v=Cd4JU7qzYbE#t=8m01s) and [here](https://www.youtube.com/watch?v=18P7cFc6nTU#t=41m06s). For more detailed information about using RBAC in Kubernetes 1.6 read the full [RBAC documentation](/docs/reference/access-authn-authz/rbac/). **Get Involved** diff --git a/content/en/blog/_posts/2017-05-00-Kubernetes-Monitoring-Guide.md b/content/en/blog/_posts/2017-05-00-Kubernetes-Monitoring-Guide.md index 53dbe14675..87a26f14b4 100644 --- a/content/en/blog/_posts/2017-05-00-Kubernetes-Monitoring-Guide.md +++ b/content/en/blog/_posts/2017-05-00-Kubernetes-Monitoring-Guide.md @@ -7,16 +7,16 @@ url: /blog/2017/05/Kubernetes-Monitoring-Guide _Today’s post is by Jean-Mathieu Saponaro, Research & Analytics Engineer at Datadog, discussing what Kubernetes changes for monitoring, and how you can prepare to properly monitor a containerized infrastructure orchestrated by Kubernetes._ -Container technologies are taking the infrastructure world by storm. While containers solve or simplify infrastructure management processes, they also introduce significant complexity in terms of orchestration. That’s where Kubernetes comes to our rescue. Just like a conductor directs an orchestra, [Kubernetes](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/) oversees our ensemble of containers—starting, stopping, creating, and destroying them automatically to keep our applications humming along. +Container technologies are taking the infrastructure world by storm. While containers solve or simplify infrastructure management processes, they also introduce significant complexity in terms of orchestration. That’s where Kubernetes comes to our rescue. Just like a conductor directs an orchestra, [Kubernetes](/docs/concepts/overview/what-is-kubernetes/) oversees our ensemble of containers—starting, stopping, creating, and destroying them automatically to keep our applications humming along. -Kubernetes makes managing a containerized infrastructure much easier by creating levels of abstractions such as [pods](https://kubernetes.io/docs/concepts/workloads/pods/pod/) and [services](https://kubernetes.io/docs/concepts/services-networking/service/). We no longer have to worry about where applications are running or if they have enough resources to work properly. But that doesn’t change the fact that, in order to ensure good performance, we need to monitor our applications, the containers running them, and Kubernetes itself. +Kubernetes makes managing a containerized infrastructure much easier by creating levels of abstractions such as [pods](/docs/concepts/workloads/pods/pod/) and [services](/docs/concepts/services-networking/service/). We no longer have to worry about where applications are running or if they have enough resources to work properly. But that doesn’t change the fact that, in order to ensure good performance, we need to monitor our applications, the containers running them, and Kubernetes itself. **Rethinking monitoring for the Kubernetes era** Just as containers have completely transformed how we think about running services on virtual machines, Kubernetes has changed the way we interact with containers. The good news is that with proper monitoring, the abstraction levels inherent to Kubernetes provide a comprehensive view of your infrastructure, even if the containers and applications are constantly moving. But Kubernetes monitoring requires us to rethink and reorient our strategies, since it differs from monitoring traditional hosts such as VMs or physical machines in several ways. **Tags and labels become essential** -With containers and their orchestration completely managed by Kubernetes, labels are now the only way we have to interact with pods and containers. That’s why they are absolutely crucial for monitoring since all metrics and events will be sliced and diced using [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) across the different layers of your infrastructure. Defining your labels with a logical and easy-to-understand schema is essential so your metrics will be as useful as possible. +With containers and their orchestration completely managed by Kubernetes, labels are now the only way we have to interact with pods and containers. That’s why they are absolutely crucial for monitoring since all metrics and events will be sliced and diced using [labels](/docs/concepts/overview/working-with-objects/labels/) across the different layers of your infrastructure. Defining your labels with a logical and easy-to-understand schema is essential so your metrics will be as useful as possible. **There are now more components to monitor** @@ -29,7 +29,7 @@ Kubernetes schedules applications dynamically based on scheduling policy, so you **Be prepared for distributed clusters** -Kubernetes has the [ability](https://kubernetes.io/docs/tasks/federation/federation-service-discovery/#hybrid-cloud-capabilities) to distribute containerized applications across multiple data centers and potentially different cloud providers. That means metrics must be collected and aggregated among all these different sources.  +Kubernetes has the [ability](/docs/tasks/federation/federation-service-discovery/#hybrid-cloud-capabilities) to distribute containerized applications across multiple data centers and potentially different cloud providers. That means metrics must be collected and aggregated among all these different sources.    diff --git a/content/en/blog/_posts/2017-05-00-Kubernetes-Security-Process-Explained.md b/content/en/blog/_posts/2017-05-00-Kubernetes-Security-Process-Explained.md index 34062d5ac6..c1874e1650 100644 --- a/content/en/blog/_posts/2017-05-00-Kubernetes-Security-Process-Explained.md +++ b/content/en/blog/_posts/2017-05-00-Kubernetes-Security-Process-Explained.md @@ -13,7 +13,7 @@ The Kubernetes community believes that we can help teams restore their footing o With over 1,200 contributors and [over a million lines of code](https://www.openhub.net/p/kubernetes), each release of Kubernetes is a massive undertaking staffed by brave volunteer [release managers](https://github.com/kubernetes/community/wiki). These normal releases are fully transparent and the process happens in public. However, security releases must be handled differently to keep potential attackers in the dark until a fix is made available to users. -We drew inspiration from other open source projects in order to create the [**Kubernetes security release process**](https://github.com/kubernetes/community/blob/master/contributors/devel/security-release-process.md). Unlike a regularly scheduled release, a security release must be delivered on an accelerated schedule, and we created the [Product Security Team](https://github.com/kubernetes/community/blob/master/contributors/devel/security-release-process.md#product-security-team-pst) to handle this process. +We drew inspiration from other open source projects in order to create the [**Kubernetes security release process**](https://github.com/kubernetes/community/blob/master/contributors/devel/security-release-process.md). Unlike a regularly scheduled release, a security release must be delivered on an accelerated schedule, and we created the [Product Security Team](https://git.k8s.io/security/security-release-process.md#product-security-committee-psc) to handle this process. This team quickly selects a lead to coordinate work and manage communication with the persons that disclosed the vulnerability and the Kubernetes community. The security release process also documents ways to measure vulnerability severity using the [Common Vulnerability Scoring System (CVSS) Version 3.0 Calculator](https://www.first.org/cvss/calculator/3.0). This calculation helps inform decisions on release cadence in the face of holidays or limited developer bandwidth. By making severity criteria transparent we are able to better set expectations and hit critical timelines during an incident where we strive to: diff --git a/content/en/blog/_posts/2017-05-00-Kubespray-Ansible-Collaborative-Kubernetes-Ops.md b/content/en/blog/_posts/2017-05-00-Kubespray-Ansible-Collaborative-Kubernetes-Ops.md index d2ef9f3985..8c63574864 100644 --- a/content/en/blog/_posts/2017-05-00-Kubespray-Ansible-Collaborative-Kubernetes-Ops.md +++ b/content/en/blog/_posts/2017-05-00-Kubespray-Ansible-Collaborative-Kubernetes-Ops.md @@ -10,7 +10,7 @@ _Today’s guest post is by Rob Hirschfeld, co-founder of open infrastructure au Making Kubernetes operationally strong is a widely held priority and I track many deployment efforts around the project. The [incubated Kubespray project](https://github.com/kubernetes-incubator/kubespray) is of particular interest for me because it uses the popular Ansible toolset to build robust, upgradable clusters on both cloud and physical targets. I believe using tools familiar to operators grows our community. -We’re excited to see the breadth of platforms enabled by Kubespray and how well it handles a wide range of options like integrating Ceph for [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) persistence and Helm for easier application uploads. Those additions have allowed us to fully integrate the [OpenStack Helm charts](https://github.com/att-comdev/openstack-helm) ([demo video](https://www.youtube.com/watch?v=wZ0vMrdx4a4&list=PLXPBeIrpXjfjabMbwYyDULOX3kZmlxEXK&index=2)). +We’re excited to see the breadth of platforms enabled by Kubespray and how well it handles a wide range of options like integrating Ceph for [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) persistence and Helm for easier application uploads. Those additions have allowed us to fully integrate the [OpenStack Helm charts](https://github.com/att-comdev/openstack-helm) ([demo video](https://www.youtube.com/watch?v=wZ0vMrdx4a4&list=PLXPBeIrpXjfjabMbwYyDULOX3kZmlxEXK&index=2)). By working with the upstream source instead of creating different install scripts, we get the benefits of a larger community. This requires some extra development effort; however, we believe helping share operational practices makes the whole community stronger. That was also the motivation behind the [SIG-Cluster Ops](https://github.com/kubernetes/community/tree/master/sig-cluster-ops). diff --git a/content/en/blog/_posts/2017-05-00-Managing-Microservices-With-Istio-Service-Mesh.md b/content/en/blog/_posts/2017-05-00-Managing-Microservices-With-Istio-Service-Mesh.md index 16fe833aaa..4e417f1255 100644 --- a/content/en/blog/_posts/2017-05-00-Managing-Microservices-With-Istio-Service-Mesh.md +++ b/content/en/blog/_posts/2017-05-00-Managing-Microservices-With-Istio-Service-Mesh.md @@ -13,7 +13,7 @@ With the adoption of microservices, however, new problems emerge due to the shee **Kubernetes and Services** -Kubernetes supports a microservices architecture through the [Service](https://kubernetes.io/docs/concepts/services-networking/service/) construct. It allows developers to abstract away the functionality of a set of [Pods](https://kubernetes.io/docs/concepts/workloads/pods/pod/), and expose it to other developers through a well-defined API. It allows adding a name to this level of abstraction and perform rudimentary L4 load balancing. But it doesn’t help with higher-level problems, such as L7 metrics, traffic splitting, rate limiting, circuit breaking, etc. +Kubernetes supports a microservices architecture through the [Service](/docs/concepts/services-networking/service/) construct. It allows developers to abstract away the functionality of a set of [Pods](/docs/concepts/workloads/pods/pod/), and expose it to other developers through a well-defined API. It allows adding a name to this level of abstraction and perform rudimentary L4 load balancing. But it doesn’t help with higher-level problems, such as L7 metrics, traffic splitting, rate limiting, circuit breaking, etc. [Istio](https://istio.io/), announced last week at GlueCon 2017, addresses these problems in a fundamental way through a service mesh framework. With Istio, developers can implement the core logic for the microservices, and let the framework take care of the rest – traffic management, discovery, service identity and security, and policy enforcement. Better yet, this can be also done for existing microservices without rewriting or recompiling any of their parts. Istio uses [Envoy](https://lyft.github.io/envoy/) as its runtime proxy component and provides an [extensible intermediation layer](https://istio.io/docs/concepts/policy-and-control/mixer.html) which allows global cross-cutting policy enforcement and telemetry collection. diff --git a/content/en/blog/_posts/2017-06-00-Kubernetes-1-7-Security-Hardening-Stateful-Application-Extensibility-Updates.md b/content/en/blog/_posts/2017-06-00-Kubernetes-1-7-Security-Hardening-Stateful-Application-Extensibility-Updates.md index b827e9aa3c..123841116c 100644 --- a/content/en/blog/_posts/2017-06-00-Kubernetes-1-7-Security-Hardening-Stateful-Application-Extensibility-Updates.md +++ b/content/en/blog/_posts/2017-06-00-Kubernetes-1-7-Security-Hardening-Stateful-Application-Extensibility-Updates.md @@ -15,34 +15,34 @@ Also, for power users, API aggregation in this release allows user-provided apis **What’s New** Security: -- [The Network Policy API](https://kubernetes.io/docs/concepts/services-networking/network-policies/) is promoted to stable. Network policy, implemented through a network plug-in, allows users to set and enforce rules governing which pods can communicate with each other.  -- [Node authorizer](https://kubernetes.io/docs/reference/access-authn-authz/node/) and admission control plugin are new additions that restrict kubelet’s access to secrets, pods and other objects based on its node. -- [Encryption for Secrets](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/), and other resources in etcd, is now available as alpha.  -- [Kubelet TLS bootstrapping](https://kubernetes.io/docs/admin/kubelet-tls-bootstrapping/) now supports client and server certificate rotation. -- [Audit logs](https://kubernetes.io/docs/tasks/debug-application-cluster/audit/) stored by the API server are now more customizable and extensible with support for event filtering and webhooks. They also provide richer data for system audit. +- [The Network Policy API](/docs/concepts/services-networking/network-policies/) is promoted to stable. Network policy, implemented through a network plug-in, allows users to set and enforce rules governing which pods can communicate with each other.  +- [Node authorizer](/docs/reference/access-authn-authz/node/) and admission control plugin are new additions that restrict kubelet’s access to secrets, pods and other objects based on its node. +- [Encryption for Secrets](/docs/tasks/administer-cluster/encrypt-data/), and other resources in etcd, is now available as alpha.  +- [Kubelet TLS bootstrapping](/docs/admin/kubelet-tls-bootstrapping/) now supports client and server certificate rotation. +- [Audit logs](/docs/tasks/debug-application-cluster/audit/) stored by the API server are now more customizable and extensible with support for event filtering and webhooks. They also provide richer data for system audit. Stateful workloads: -- [StatefulSet Updates](https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/#updating-statefulsets) is a new beta feature in 1.7, allowing automated updates of stateful applications such as Kafka, Zookeeper and etcd, using a range of update strategies including rolling updates. -- StatefulSets also now support faster scaling and startup for applications that do not require ordering through [Pod Management Policy](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#pod-management-policies). This can be a major performance improvement.  -- [Local Storage](https://kubernetes.io/docs/concepts/storage/volumes/#local) (alpha) was one of most frequently requested features for stateful applications. Users can now access local storage volumes through the standard PVC/PV interface and via StorageClasses in StatefulSets. -- DaemonSets, which create one pod per node already have an update feature, and in 1.7 have added smart [rollback and history](https://kubernetes.io/docs/tasks/manage-daemon/rollback-daemon-set/) capability. -- A new [StorageOS Volume plugin](https://kubernetes.io/docs/concepts/storage/volumes/#storageos) provides highly-available cluster-wide persistent volumes from local or attached node storage. +- [StatefulSet Updates](/docs/tutorials/stateful-application/basic-stateful-set/#updating-statefulsets) is a new beta feature in 1.7, allowing automated updates of stateful applications such as Kafka, Zookeeper and etcd, using a range of update strategies including rolling updates. +- StatefulSets also now support faster scaling and startup for applications that do not require ordering through [Pod Management Policy](/docs/concepts/workloads/controllers/statefulset/#pod-management-policies). This can be a major performance improvement.  +- [Local Storage](/docs/concepts/storage/volumes/#local) (alpha) was one of most frequently requested features for stateful applications. Users can now access local storage volumes through the standard PVC/PV interface and via StorageClasses in StatefulSets. +- DaemonSets, which create one pod per node already have an update feature, and in 1.7 have added smart [rollback and history](/docs/tasks/manage-daemon/rollback-daemon-set/) capability. +- A new [StorageOS Volume plugin](/docs/concepts/storage/volumes/#storageos) provides highly-available cluster-wide persistent volumes from local or attached node storage. Extensibility: -- [API aggregation](https://kubernetes.io/docs/concepts/api-extension/apiserver-aggregation/) at runtime is the most powerful extensibility features in this release, allowing power users to add Kubernetes-style pre-built, 3rd party or user-created APIs to their cluster. +- [API aggregation](/docs/concepts/api-extension/apiserver-aggregation/) at runtime is the most powerful extensibility features in this release, allowing power users to add Kubernetes-style pre-built, 3rd party or user-created APIs to their cluster. - [Container Runtime Interface](https://github.com/kubernetes/community/blob/master/contributors/devel/container-runtime-interface.md) (CRI) has been enhanced with New RPC calls to retrieve container metrics from the runtime. [Validation tests for the CRI](https://github.com/kubernetes/community/blob/master/contributors/devel/cri-validation.md) have been published and Alpha integration with [containerd](http://containerd.io/), which supports basic pod lifecycle and image management is now available. Read our previous [in-depth post introducing CRI](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes). Additional Features: -- Alpha support for [external admission controllers](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) is introduced, providing two options for adding custom business logic to the API server for modifying objects as they are created and validating policy.  -- [Policy-based Federated Resource Placement](https://kubernetes.io/docs/tasks/federation/set-up-placement-policies-federation/) is introduced as Alpha providing placement policies for the federated clusters, based on custom requirements such as regulation, pricing or performance. +- Alpha support for [external admission controllers](/docs/reference/access-authn-authz/extensible-admission-controllers/) is introduced, providing two options for adding custom business logic to the API server for modifying objects as they are created and validating policy.  +- [Policy-based Federated Resource Placement](/docs/tasks/federation/set-up-placement-policies-federation/) is introduced as Alpha providing placement policies for the federated clusters, based on custom requirements such as regulation, pricing or performance. Deprecation:  -- Third Party Resource (TPR) has been replaced with Custom Resource Definitions (CRD) which provides a cleaner API, and resolves issues and corner cases that were raised during the beta period of TPR. If you use the TPR beta feature, you are encouraged to [migrate](https://kubernetes.io/docs/tasks/access-kubernetes-api/migrate-third-party-resource/), as it is slated for removal by the community in Kubernetes 1.8. +- Third Party Resource (TPR) has been replaced with Custom Resource Definitions (CRD) which provides a cleaner API, and resolves issues and corner cases that were raised during the beta period of TPR. If you use the TPR beta feature, you are encouraged to [migrate](/docs/tasks/access-kubernetes-api/migrate-third-party-resource/), as it is slated for removal by the community in Kubernetes 1.8. The above are a subset of the feature highlights in Kubernetes 1.7. For a complete list please visit the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#v170). @@ -60,7 +60,7 @@ Kubernetes adoption has been coming from every sector across the world. Recent u Huge kudos and thanks go out to the Kubernetes 1.7 [release team](https://github.com/kubernetes/features/blob/master/release-1.7/release_team.md), led by Dawn Chen of Google.  **Availability** -Kubernetes 1.7 is available for [download on GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.7.0). To get started with Kubernetes, try one of the these [interactive tutorials](http://kubernetes.io/docs/tutorials/kubernetes-basics/).  +Kubernetes 1.7 is available for [download on GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.7.0). To get started with Kubernetes, try one of the these [interactive tutorials](/docs/tutorials/kubernetes-basics/).  **Get Involved** Join the community at [CloudNativeCon + KubeCon](http://events.linuxfoundation.org/events/cloudnativecon-and-kubecon-north-america) in Austin Dec. 6-8 for the largest Kubernetes gathering ever. [Speaking submissions](http://events.linuxfoundation.org/events/cloudnativecon-and-kubecon-north-america/program/cfp) are open till August 21 and [discounted registration](https://www.regonline.com/registration/Checkin.aspx?EventID=1903774&_ga=2.224109086.464556664.1498490094-1623727562.1496428006) ends October 6. diff --git a/content/en/blog/_posts/2017-07-00-Happy-Second-Birthday-Kubernetes.md b/content/en/blog/_posts/2017-07-00-Happy-Second-Birthday-Kubernetes.md index 059b48d6b5..cfb38b2376 100644 --- a/content/en/blog/_posts/2017-07-00-Happy-Second-Birthday-Kubernetes.md +++ b/content/en/blog/_posts/2017-07-00-Happy-Second-Birthday-Kubernetes.md @@ -4,7 +4,7 @@ date: 2017-07-28 slug: happy-second-birthday-kubernetes url: /blog/2017/07/Happy-Second-Birthday-Kubernetes --- -As we do every July, we’re excited to celebrate Kubernetes 2nd birthday! In the two years since GA 1.0 launched as an open source project, [Kubernetes](http://kubernetes.io/docs/whatisk8s/) (abbreviated as K8s) has grown to become the highest velocity cloud-related project. With more than 2,611 diverse contributors, from independents to leading global companies, the project has had 50,685 commits in the last 12 months. Of the 54 million projects on GitHub, Kubernetes is in the top 5 for number of unique developers contributing code. It also has [more pull requests and issue comments](https://www.cncf.io/blog/2017/02/27/measuring-popularity-kubernetes-using-bigquery/) than any other project on GitHub.   +As we do every July, we’re excited to celebrate Kubernetes 2nd birthday! In the two years since GA 1.0 launched as an open source project, [Kubernetes](/docs/whatisk8s/) (abbreviated as K8s) has grown to become the highest velocity cloud-related project. With more than 2,611 diverse contributors, from independents to leading global companies, the project has had 50,685 commits in the last 12 months. Of the 54 million projects on GitHub, Kubernetes is in the top 5 for number of unique developers contributing code. It also has [more pull requests and issue comments](https://www.cncf.io/blog/2017/02/27/measuring-popularity-kubernetes-using-bigquery/) than any other project on GitHub.   ![Screen Shot 2017-07-18 at 9.39.42 AM.png](https://lh3.googleusercontent.com/ldb4PfuqammWmcPiFpMa48ALxD0kGrSre0WGMpuXKqAqnKhyWEmIcJXnQcAK2sdVCiE5cvw0H2FXtLt_dVihAk4b-XTA2HIQba3A0irnRaIHup4bhFUwPLSSFmw3zFk9ZOt61TKc) diff --git a/content/en/blog/_posts/2017-07-00-How-Watson-Health-Cloud-Deploys.md b/content/en/blog/_posts/2017-07-00-How-Watson-Health-Cloud-Deploys.md index 0d6e6481cd..de516c17a8 100644 --- a/content/en/blog/_posts/2017-07-00-How-Watson-Health-Cloud-Deploys.md +++ b/content/en/blog/_posts/2017-07-00-How-Watson-Health-Cloud-Deploys.md @@ -47,7 +47,7 @@ Our clusters consist of one or more physical or virtual machines, also known as -A user makes a request to Kubernetes to deploy the containers, specifying the number of replicas required for high availability. The Kubernetes scheduler decides where the [pods](https://kubernetes.io/docs/concepts/workloads/pods/pod/) (groups of one or more containers) will be scheduled and which worker nodes they will be deployed on, storing this information internally in Kubernetes and [etcd](https://github.com/coreos/etcd#etcd). The deployment of pods in worker nodes is updated based on load at runtime, optimizing the placement of pods in the cluster. +A user makes a request to Kubernetes to deploy the containers, specifying the number of replicas required for high availability. The Kubernetes scheduler decides where the [pods](/docs/concepts/workloads/pods/pod/) (groups of one or more containers) will be scheduled and which worker nodes they will be deployed on, storing this information internally in Kubernetes and [etcd](https://github.com/coreos/etcd#etcd). The deployment of pods in worker nodes is updated based on load at runtime, optimizing the placement of pods in the cluster. @@ -111,7 +111,7 @@ Deploying the application in IBM Cloud Kubernetes Service: -Provision a cluster in IBM Cloud Kubernetes Service with \ worker nodes. Create Kubernetes controllers for deploying the containers in worker nodes, the IBM Cloud Kubernetes Service infrastructure pulls the Docker images from IBM Cloud Container Registry to create containers. We tried deploying an application container and running a logmet agent (see Reading and displaying logs using logmet container, below) inside the containers that forwards the application logs to an IBM Cloud logging service. As part of the process, YAML files are used to create a controller resource for the UrbanCode Deploy (UCD). UCD agent is deployed as a [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) controller, which is used to connect to the UCD server. The whole process of deployment of application happens in UCD. To support the application for public access, we created a service resource to interact between pods and access container services. For storage support, we created persistent volume claims and mounted the volume for the containers. +Provision a cluster in IBM Cloud Kubernetes Service with \ worker nodes. Create Kubernetes controllers for deploying the containers in worker nodes, the IBM Cloud Kubernetes Service infrastructure pulls the Docker images from IBM Cloud Container Registry to create containers. We tried deploying an application container and running a logmet agent (see Reading and displaying logs using logmet container, below) inside the containers that forwards the application logs to an IBM Cloud logging service. As part of the process, YAML files are used to create a controller resource for the UrbanCode Deploy (UCD). UCD agent is deployed as a [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) controller, which is used to connect to the UCD server. The whole process of deployment of application happens in UCD. To support the application for public access, we created a service resource to interact between pods and access container services. For storage support, we created persistent volume claims and mounted the volume for the containers. @@ -138,7 +138,7 @@ Exposing services with Ingress: -[Ingress controllers](https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-controllers) are reverse proxies that expose services outside cluster through URLs. They act as an external HTTP load balancer that uses a unique public entry point to route requests to the application. +[Ingress controllers](/docs/concepts/services-networking/ingress/#ingress-controllers) are reverse proxies that expose services outside cluster through URLs. They act as an external HTTP load balancer that uses a unique public entry point to route requests to the application. diff --git a/content/en/blog/_posts/2017-08-00-High-Performance-Networking-With-Ec2.md b/content/en/blog/_posts/2017-08-00-High-Performance-Networking-With-Ec2.md index 367914e4e7..b735c501e7 100644 --- a/content/en/blog/_posts/2017-08-00-High-Performance-Networking-With-Ec2.md +++ b/content/en/blog/_posts/2017-08-00-High-Performance-Networking-With-Ec2.md @@ -15,7 +15,7 @@ When it comes to networking, however, EC2 has some limits that hinder performanc ## Traditional VPC Networking Performance Roadblocks -A Kubernetes pod network is separate from an Amazon Virtual Private Cloud (VPC) instance network; consequently, off-instance pod traffic needs a route to the destination pods. Fortunately, VPCs support setting these routes. When building a cluster network with the [kubenet](https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#kubenet) plugin, whenever new nodes are added, the AWS cloud provider will automatically add a VPC route to the pods running on that node. +A Kubernetes pod network is separate from an Amazon Virtual Private Cloud (VPC) instance network; consequently, off-instance pod traffic needs a route to the destination pods. Fortunately, VPCs support setting these routes. When building a cluster network with the [kubenet](/docs/concepts/cluster-administration/network-plugins/#kubenet) plugin, whenever new nodes are added, the AWS cloud provider will automatically add a VPC route to the pods running on that node. Using kubenet to set routes provides native VPC network performance and visibility. However, since kubenet does not support more advanced network functions like network policy for pod traffic isolation, many users choose to run a Container Network Interface (CNI) provider on the back end. diff --git a/content/en/blog/_posts/2017-08-00-Kubernetes-Meets-High-Performance.md b/content/en/blog/_posts/2017-08-00-Kubernetes-Meets-High-Performance.md index 6db792a6e3..08de339bb9 100644 --- a/content/en/blog/_posts/2017-08-00-Kubernetes-Meets-High-Performance.md +++ b/content/en/blog/_posts/2017-08-00-Kubernetes-Meets-High-Performance.md @@ -12,7 +12,7 @@ In this post, I discuss some of the challenges of running HPC workloads with Kub ## HPC workloads unique challenges -In Kubernetes, the base unit of scheduling is a Pod: one or more Docker containers scheduled to a cluster host. Kubernetes assumes that workloads are containers. While Kubernetes has the notion of [Cron Jobs](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/) and [Jobs](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/) that run to completion, applications deployed on Kubernetes are typically long-running services, like web servers, load balancers or data stores and while they are highly dynamic with pods coming and going, they differ greatly from HPC application patterns. +In Kubernetes, the base unit of scheduling is a Pod: one or more Docker containers scheduled to a cluster host. Kubernetes assumes that workloads are containers. While Kubernetes has the notion of [Cron Jobs](/docs/concepts/workloads/controllers/cron-jobs/) and [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) that run to completion, applications deployed on Kubernetes are typically long-running services, like web servers, load balancers or data stores and while they are highly dynamic with pods coming and going, they differ greatly from HPC application patterns. Traditional HPC applications often exhibit different characteristics: @@ -44,7 +44,7 @@ For sites running traditional HPC workloads, another approach is to use existing - Use native job scheduling features in Kubernetes -Sites less invested in existing HPC applications can use existing scheduling facilities in Kubernetes for [jobs that run to completion](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/). While this is an option, it may be impractical for many HPC users. HPC applications are often either optimized towards massive throughput or large scale parallelism. In both cases startup and teardown latencies have a discriminating impact. Latencies that appear to be acceptable for containerized microservices today would render such applications unable to scale to the required levels. +Sites less invested in existing HPC applications can use existing scheduling facilities in Kubernetes for [jobs that run to completion](/docs/concepts/workloads/controllers/jobs-run-to-completion/). While this is an option, it may be impractical for many HPC users. HPC applications are often either optimized towards massive throughput or large scale parallelism. In both cases startup and teardown latencies have a discriminating impact. Latencies that appear to be acceptable for containerized microservices today would render such applications unable to scale to the required levels. All of these solutions involve tradeoffs. The first option doesn’t allow resources to be shared (increasing costs) and the second and third options require customers to pick a single scheduler, constraining future flexibility. diff --git a/content/en/blog/_posts/2017-09-00-Kubernetes-18-Security-Workloads-And.md b/content/en/blog/_posts/2017-09-00-Kubernetes-18-Security-Workloads-And.md index 9fa916fe29..d8f09da298 100644 --- a/content/en/blog/_posts/2017-09-00-Kubernetes-18-Security-Workloads-And.md +++ b/content/en/blog/_posts/2017-09-00-Kubernetes-18-Security-Workloads-And.md @@ -12,10 +12,10 @@ We’re pleased to announce the delivery of Kubernetes 1.8, our third release th ## Spotlight on security -Kubernetes 1.8 graduates support for [role based access control](https://en.wikipedia.org/wiki/Role-based_access_control) (RBAC) to stable. RBAC allows cluster administrators to [dynamically define roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) to enforce access policies through the Kubernetes API. Beta support for filtering outbound traffic through [network policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) augments existing support for filtering inbound traffic to a pod. RBAC and Network Policies are two powerful tools for enforcing organizational and regulatory security requirements within Kubernetes. +Kubernetes 1.8 graduates support for [role based access control](https://en.wikipedia.org/wiki/Role-based_access_control) (RBAC) to stable. RBAC allows cluster administrators to [dynamically define roles](/docs/reference/access-authn-authz/rbac/) to enforce access policies through the Kubernetes API. Beta support for filtering outbound traffic through [network policies](/docs/concepts/services-networking/network-policies/) augments existing support for filtering inbound traffic to a pod. RBAC and Network Policies are two powerful tools for enforcing organizational and regulatory security requirements within Kubernetes. -Transport Layer Security (TLS) [certificate rotation](https://kubernetes.io/docs/admin/kubelet-tls-bootstrapping/) for the Kubelet graduates to beta. Automatic certificate rotation eases secure cluster operation. +Transport Layer Security (TLS) [certificate rotation](/docs/admin/kubelet-tls-bootstrapping/) for the Kubelet graduates to beta. Automatic certificate rotation eases secure cluster operation. ## Spotlight on workload support @@ -24,9 +24,9 @@ Kubernetes 1.8 promotes the core Workload APIs to beta with the apps/v1beta2 gro For those considering running Big Data workloads on Kubernetes, the Workloads API now enables [native Kubernetes support](https://apache-spark-on-k8s.github.io/userdocs/) in Apache Spark. -Batch workloads, such as nightly ETL jobs, will benefit from the graduation of [CronJobs](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/) to beta. +Batch workloads, such as nightly ETL jobs, will benefit from the graduation of [CronJobs](/docs/concepts/workloads/controllers/cron-jobs/) to beta. -[Custom Resource Definitions](https://kubernetes.io/docs/concepts/api-extension/custom-resources/) (CRDs) remain in beta for Kubernetes 1.8. A CRD provides a powerful mechanism to extend Kubernetes with user-defined API objects. One use case for CRDs is the automation of complex stateful applications such as [key-value stores](https://github.com/coreos/etcd-operator), databases and [storage engines](https://rook.io/) through the Operator Pattern. Expect continued enhancements to CRDs such as [validation](https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) as stabilization continues. +[Custom Resource Definitions](/docs/concepts/api-extension/custom-resources/) (CRDs) remain in beta for Kubernetes 1.8. A CRD provides a powerful mechanism to extend Kubernetes with user-defined API objects. One use case for CRDs is the automation of complex stateful applications such as [key-value stores](https://github.com/coreos/etcd-operator), databases and [storage engines](https://rook.io/) through the Operator Pattern. Expect continued enhancements to CRDs such as [validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) as stabilization continues. ## Spoilers ahead @@ -40,7 +40,7 @@ Each Special Interest Group (SIG) in the community continues to deliver the most #### Availability -Kubernetes 1.8 is available for [download on GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.8.0). To get started with Kubernetes, check out these [interactive tutorials](https://kubernetes.io/docs/tutorials/kubernetes-basics/). +Kubernetes 1.8 is available for [download on GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.8.0). To get started with Kubernetes, check out these [interactive tutorials](/docs/tutorials/kubernetes-basics/). ## Release team diff --git a/content/en/blog/_posts/2017-09-00-Kubernetes-Statefulsets-Daemonsets.md b/content/en/blog/_posts/2017-09-00-Kubernetes-Statefulsets-Daemonsets.md index d014efc295..fe156e00df 100644 --- a/content/en/blog/_posts/2017-09-00-Kubernetes-Statefulsets-Daemonsets.md +++ b/content/en/blog/_posts/2017-09-00-Kubernetes-Statefulsets-Daemonsets.md @@ -8,15 +8,15 @@ url: /blog/2017/09/Kubernetes-Statefulsets-Daemonsets Editor's note: today's post is by Janet Kuo and Kenneth Owens, Software Engineers at Google. -This post talks about recent updates to the [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) and [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) API objects for Kubernetes. We explore these features using [Apache ZooKeeper](https://zookeeper.apache.org/) and [Apache Kafka](https://kafka.apache.org/) StatefulSets and a [Prometheus node exporter](https://github.com/prometheus/node_exporter) DaemonSet. +This post talks about recent updates to the [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) and [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) API objects for Kubernetes. We explore these features using [Apache ZooKeeper](https://zookeeper.apache.org/) and [Apache Kafka](https://kafka.apache.org/) StatefulSets and a [Prometheus node exporter](https://github.com/prometheus/node_exporter) DaemonSet. -In Kubernetes 1.6, we added the [RollingUpdate](https://kubernetes.io/docs/tasks/manage-daemon/update-daemon-set/) update strategy to the DaemonSet API Object. Configuring your DaemonSets with the RollingUpdate strategy causes the DaemonSet controller to perform automated rolling updates to the Pods in your DaemonSets when their spec.template are updated. +In Kubernetes 1.6, we added the [RollingUpdate](/docs/tasks/manage-daemon/update-daemon-set/) update strategy to the DaemonSet API Object. Configuring your DaemonSets with the RollingUpdate strategy causes the DaemonSet controller to perform automated rolling updates to the Pods in your DaemonSets when their spec.template are updated. -In Kubernetes 1.7, we enhanced the DaemonSet controller to track a history of revisions to the PodTemplateSpecs of DaemonSets. This allows the DaemonSet controller to roll back an update. We also added the [RollingUpdate](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#update-strategies) strategy to the [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) API Object, and implemented revision history tracking for the StatefulSet controller. Additionally, we added the [Parallel](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#parallel-pod-management) pod management policy to support stateful applications that require Pods with unique identities but not ordered Pod creation and termination. +In Kubernetes 1.7, we enhanced the DaemonSet controller to track a history of revisions to the PodTemplateSpecs of DaemonSets. This allows the DaemonSet controller to roll back an update. We also added the [RollingUpdate](/docs/concepts/workloads/controllers/statefulset/#update-strategies) strategy to the [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) API Object, and implemented revision history tracking for the StatefulSet controller. Additionally, we added the [Parallel](/docs/concepts/workloads/controllers/statefulset/#parallel-pod-management) pod management policy to support stateful applications that require Pods with unique identities but not ordered Pod creation and termination. # StatefulSet rolling update and Pod management policy @@ -59,7 +59,7 @@ The manifest creates an ensemble of three ZooKeeper servers using a StatefulSet, -If you use kubectl get to watch Pod creation in another terminal you will see that, in contrast to the [OrderedReady](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#orderedready-pod-management) strategy (the default policy that implements the full version of the StatefulSet guarantees), all of the Pods in the zk StatefulSet are created in parallel. +If you use kubectl get to watch Pod creation in another terminal you will see that, in contrast to the [OrderedReady](/docs/concepts/workloads/controllers/statefulset/#orderedready-pod-management) strategy (the default policy that implements the full version of the StatefulSet guarantees), all of the Pods in the zk StatefulSet are created in parallel. @@ -627,7 +627,7 @@ By design, the StatefulSet controller does not delete any persistent volume clai # DaemonSet rolling update, history, and rollback -In this section, we’re going to show you how to perform a rolling update on a DaemonSet, look at its history, and then perform a rollback after a bad rollout. We will use a DaemonSet to deploy a [Prometheus node exporter](https://github.com/prometheus/node_exporter) on each Kubernetes node in the cluster. These node exporters export node metrics to the Prometheus monitoring system. For the sake of simplicity, we’ve omitted the installation of the [Prometheus server](https://github.com/prometheus/prometheus) and the service for [communication with DaemonSet pods](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/#communicating-with-daemon-pods) from this blogpost. +In this section, we’re going to show you how to perform a rolling update on a DaemonSet, look at its history, and then perform a rollback after a bad rollout. We will use a DaemonSet to deploy a [Prometheus node exporter](https://github.com/prometheus/node_exporter) on each Kubernetes node in the cluster. These node exporters export node metrics to the Prometheus monitoring system. For the sake of simplicity, we’ve omitted the installation of the [Prometheus server](https://github.com/prometheus/prometheus) and the service for [communication with DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/#communicating-with-daemon-pods) from this blogpost. ## Prerequisites diff --git a/content/en/blog/_posts/2017-09-00-Windows-Networking-At-Parity-With-Linux.md b/content/en/blog/_posts/2017-09-00-Windows-Networking-At-Parity-With-Linux.md index 6f99cc5d95..14d7aae14e 100644 --- a/content/en/blog/_posts/2017-09-00-Windows-Networking-At-Parity-With-Linux.md +++ b/content/en/blog/_posts/2017-09-00-Windows-Networking-At-Parity-With-Linux.md @@ -13,7 +13,7 @@ _**Editor's note: today's post is by Jason Messer, Principal PM Manager at Micro ## Tightly-Coupled Communication -These improvements enable tightly-coupled communication between multiple Windows Server containers (without Hyper-V isolation) within a single "[Pod](https://kubernetes.io/docs/concepts/workloads/pods/pod/)". Think of Pods as the scheduling unit for the Kubernetes cluster, inside of which, one or more application containers are co-located and able to share storage and networking resources. All containers within a Pod shared the same IP address and port range and are able to communicate with each other using localhost. This enables applications to easily leverage "helper" programs for tasks such as monitoring, configuration updates, log management, and proxies. Another way to think of a Pod is as a compute host with the app containers representing processes. +These improvements enable tightly-coupled communication between multiple Windows Server containers (without Hyper-V isolation) within a single "[Pod](/docs/concepts/workloads/pods/pod/)". Think of Pods as the scheduling unit for the Kubernetes cluster, inside of which, one or more application containers are co-located and able to share storage and networking resources. All containers within a Pod shared the same IP address and port range and are able to communicate with each other using localhost. This enables applications to easily leverage "helper" programs for tasks such as monitoring, configuration updates, log management, and proxies. Another way to think of a Pod is as a compute host with the app containers representing processes. ## Simplified Network Topology We also simplified the network topology on Windows nodes in a Kubernetes cluster by reducing the number of endpoints required per container (or more generally, per pod) to one. Previously, Windows containers (pods) running in a Kubernetes cluster required two endpoints - one for external (internet) communication and a second for intra-cluster communication between between other nodes or pods in the cluster. This was due to the fact that external communication from containers attached to a host network with local scope (i.e. not publicly routable) required a NAT operation which could only be provided through the Windows NAT (WinNAT) component on the host. Intra-cluster communication required containers to be attached to a separate network with "global" (cluster-level) scope through a second endpoint. Recent platform improvements now enable NAT''ing to occur directly on a container endpoint which is implemented with the Microsoft Virtual Filtering Platform (VFP) Hyper-V switch extension. Now, both external and intra-cluster traffic can flow through a single endpoint. diff --git a/content/en/blog/_posts/2017-10-00-Enforcing-Network-Policies-In-Kubernetes.md b/content/en/blog/_posts/2017-10-00-Enforcing-Network-Policies-In-Kubernetes.md index 828650f59f..acbae0265c 100644 --- a/content/en/blog/_posts/2017-10-00-Enforcing-Network-Policies-In-Kubernetes.md +++ b/content/en/blog/_posts/2017-10-00-Enforcing-Network-Policies-In-Kubernetes.md @@ -8,7 +8,7 @@ _**Editor's note: this post is part of a [series of in-depth articles](https://k -Kubernetes now offers functionality to enforce rules about which pods can communicate with each other using [network policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/). This feature is has become stable Kubernetes 1.7 and is ready to use with supported networking plugins. The Kubernetes 1.8 release has added better capabilities to this feature. +Kubernetes now offers functionality to enforce rules about which pods can communicate with each other using [network policies](/docs/concepts/services-networking/network-policies/). This feature is has become stable Kubernetes 1.7 and is ready to use with supported networking plugins. The Kubernetes 1.8 release has added better capabilities to this feature. ## Network policy: What does it mean? @@ -19,7 +19,7 @@ If you’re running multiple applications in a Kubernetes cluster or sharing a c ## How do I add Network Policy to my cluster? -Networking Policies are implemented by networking plugins. These plugins typically install an overlay network in your cluster to enforce the Network Policies configured. A number of networking plugins, including [Calico](https://kubernetes.io/docs/tasks/configure-pod-container/calico-network-policy/), [Romana](https://kubernetes.io/docs/tasks/configure-pod-container/romana-network-policy/) and [Weave Net](https://kubernetes.io/docs/tasks/configure-pod-container/weave-network-policy/), support using Network Policies. +Networking Policies are implemented by networking plugins. These plugins typically install an overlay network in your cluster to enforce the Network Policies configured. A number of networking plugins, including [Calico](/docs/tasks/configure-pod-container/calico-network-policy/), [Romana](/docs/tasks/configure-pod-container/romana-network-policy/) and [Weave Net](/docs/tasks/configure-pod-container/weave-network-policy/), support using Network Policies. Google Container Engine (GKE) also provides beta support for [Network Policies](https://cloud.google.com/container-engine/docs/network-policy) using the Calico networking plugin when you create clusters with the following command: @@ -71,7 +71,7 @@ spec: ``` -Once you apply this configuration, only pods with label **app: foo** can talk to the pods with the label **app: nginx**. For a more detailed tutorial, see the [Kubernetes documentation](https://kubernetes.io/docs/tasks/administer-cluster/declare-network-policy/). +Once you apply this configuration, only pods with label **app: foo** can talk to the pods with the label **app: nginx**. For a more detailed tutorial, see the [Kubernetes documentation](/docs/tasks/administer-cluster/declare-network-policy/). ## Example: restricting traffic between all pods by default @@ -111,7 +111,7 @@ In addition to the previous examples, you can make the Network Policy API enforc ## Learn more -- Read more: [Networking Policy documentation](https://kubernetes.io/docs/concepts/services-networking/network-policies/) +- Read more: [Networking Policy documentation](/docs/concepts/services-networking/network-policies/) - Read more: [Unofficial Network Policy Guide](https://ahmet.im/blog/kubernetes-network-policy/) -- Hands-on: [Declare a Network Policy](https://kubernetes.io/docs/tasks/administer-cluster/declare-network-policy/) +- Hands-on: [Declare a Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) - Try: [Network Policy Recipes](https://github.com/ahmetb/kubernetes-networkpolicy-tutorial) diff --git a/content/en/blog/_posts/2017-10-00-Using-Rbac-Generally-Available-18.md b/content/en/blog/_posts/2017-10-00-Using-Rbac-Generally-Available-18.md index 43f4dd36ad..35f9234a67 100644 --- a/content/en/blog/_posts/2017-10-00-Using-Rbac-Generally-Available-18.md +++ b/content/en/blog/_posts/2017-10-00-Using-Rbac-Generally-Available-18.md @@ -6,7 +6,7 @@ url: /blog/2017/10/Using-Rbac-Generally-Available-18 --- **_Editor's note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2017/10/five-days-of-kubernetes-18) on what's new in Kubernetes 1.8. Today’s post comes from Eric Chiang, software engineer, CoreOS, and SIG-Auth co-lead._** -Kubernetes 1.8 represents a significant milestone for the [role-based access control (RBAC) authorizer](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), which was promoted to GA in this release. RBAC is a mechanism for controlling access to the Kubernetes API, and since its [beta in 1.6](https://kubernetes.io/blog/2017/04/rbac-support-in-kubernetes), many Kubernetes clusters and provisioning strategies have enabled it by default. +Kubernetes 1.8 represents a significant milestone for the [role-based access control (RBAC) authorizer](/docs/reference/access-authn-authz/rbac/), which was promoted to GA in this release. RBAC is a mechanism for controlling access to the Kubernetes API, and since its [beta in 1.6](https://kubernetes.io/blog/2017/04/rbac-support-in-kubernetes), many Kubernetes clusters and provisioning strategies have enabled it by default. Going forward, we expect to see RBAC become a fundamental building block for securing Kubernetes clusters. This post explores using RBAC to manage user and application access to the Kubernetes API. diff --git a/content/en/blog/_posts/2017-11-00-Containerd-Container-Runtime-Options-Kubernetes.md b/content/en/blog/_posts/2017-11-00-Containerd-Container-Runtime-Options-Kubernetes.md index 2ecb1eee8b..37308b21c5 100644 --- a/content/en/blog/_posts/2017-11-00-Containerd-Container-Runtime-Options-Kubernetes.md +++ b/content/en/blog/_posts/2017-11-00-Containerd-Container-Runtime-Options-Kubernetes.md @@ -107,7 +107,7 @@ We are focused on stability and usability improvements as our next steps. - Usability: - Improve the user experience of [_crictl_](https://github.com/kubernetes-incubator/cri-tools/blob/master/docs/crictl.md). Crictl is a portable command line tool for all CRI container runtimes. The goal here is to make it easy to use for debug and development scenarios. - - Integrate cri-containerd with [_kube-up.sh_](https://kubernetes.io/docs/getting-started-guides/gce/), to help users bring up a production quality Kubernetes cluster using cri-containerd and containerd. + - Integrate cri-containerd with [_kube-up.sh_](/docs/getting-started-guides/gce/), to help users bring up a production quality Kubernetes cluster using cri-containerd and containerd. - Improve our documentation for users and admins alike. We plan to release our v1.0.0-beta.0 by the end of 2017. diff --git a/content/en/blog/_posts/2017-12-00-Introducing-Kubeflow-Composable.md b/content/en/blog/_posts/2017-12-00-Introducing-Kubeflow-Composable.md index 95a1cda4d4..28ecb75d77 100644 --- a/content/en/blog/_posts/2017-12-00-Introducing-Kubeflow-Composable.md +++ b/content/en/blog/_posts/2017-12-00-Introducing-Kubeflow-Composable.md @@ -22,14 +22,14 @@ Worse, these deployments are so tied to the clusters they have been deployed to To address these concerns, we’re announcing the creation of the Kubeflow project, a new open source Github repo dedicated to making using ML stacks on Kubernetes easy, fast and extensible. This repository contains: - JupyterHub to create & manage interactive Jupyter notebooks -- A Tensorflow [Custom Resource](https://kubernetes.io/docs/concepts/api-extension/custom-resources/) (CRD) that can be configured to use CPUs or GPUs, and adjusted to the size of a cluster with a single setting +- A Tensorflow [Custom Resource](/docs/concepts/api-extension/custom-resources/) (CRD) that can be configured to use CPUs or GPUs, and adjusted to the size of a cluster with a single setting - A TF Serving container Because this solution relies on Kubernetes, it runs wherever Kubernetes runs. Just spin up a cluster and go! ## Using Kubeflow -Let's suppose you are working with two different Kubernetes clusters: a local [minikube](https://github.com/kubernetes/minikube) cluster; and a [GKE cluster with GPUs](https://docs.google.com/forms/d/1JNnoUe1_3xZvAogAi16DwH6AjF2eu08ggED24OGO7Xc/viewform?edit_requested=true); and that you have two [kubectl contexts](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#define-clusters-users-and-contexts) defined named minikube and gke. +Let's suppose you are working with two different Kubernetes clusters: a local [minikube](https://github.com/kubernetes/minikube) cluster; and a [GKE cluster with GPUs](https://docs.google.com/forms/d/1JNnoUe1_3xZvAogAi16DwH6AjF2eu08ggED24OGO7Xc/viewform?edit_requested=true); and that you have two [kubectl contexts](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#define-clusters-users-and-contexts) defined named minikube and gke. diff --git a/content/en/blog/_posts/2017-12-00-Kubernetes-19-Workloads-Expanded-Ecosystem.md b/content/en/blog/_posts/2017-12-00-Kubernetes-19-Workloads-Expanded-Ecosystem.md index 77a5b24bee..cb73d95162 100644 --- a/content/en/blog/_posts/2017-12-00-Kubernetes-19-Workloads-Expanded-Ecosystem.md +++ b/content/en/blog/_posts/2017-12-00-Kubernetes-19-Workloads-Expanded-Ecosystem.md @@ -11,13 +11,13 @@ Today’s release continues the evolution of an increasingly rich feature set, m ## Workloads API GA -We’re excited to announce General Availability (GA) of the [apps/v1 Workloads API](https://kubernetes.io/docs/reference/workloads-18-19/), which is now enabled by default. The Apps Workloads API groups the DaemonSet, Deployment, ReplicaSet, and StatefulSet APIs together to form the foundation for long-running stateless and stateful workloads in Kubernetes. Note that the Batch Workloads API (Job and CronJob) is not part of this effort and will have a separate path to GA stability. +We’re excited to announce General Availability (GA) of the [apps/v1 Workloads API](/docs/reference/workloads-18-19/), which is now enabled by default. The Apps Workloads API groups the DaemonSet, Deployment, ReplicaSet, and StatefulSet APIs together to form the foundation for long-running stateless and stateful workloads in Kubernetes. Note that the Batch Workloads API (Job and CronJob) is not part of this effort and will have a separate path to GA stability. Deployment and ReplicaSet, two of the most commonly used objects in Kubernetes, are now stabilized after more than a year of real-world use and feedback. [SIG Apps](https://github.com/kubernetes/community/tree/master/sig-apps) has applied the lessons from this process to all four resource kinds over the last several release cycles, enabling DaemonSet and StatefulSet to join this graduation. The v1 (GA) designation indicates production hardening and readiness, and comes with the guarantee of long-term backwards compatibility. ## Windows Support (beta) -Kubernetes was originally developed for Linux systems, but as our users are realizing the benefits of container orchestration at scale, we are seeing demand for Kubernetes to run Windows workloads. Work to support Windows Server in Kubernetes began in earnest about 12 months ago. [SIG-Windows](https://github.com/kubernetes/community/tree/master/sig-windows)has now promoted this feature to beta status, which means that we can evaluate it for [usage](https://kubernetes.io/docs/getting-started-guides/windows/). +Kubernetes was originally developed for Linux systems, but as our users are realizing the benefits of container orchestration at scale, we are seeing demand for Kubernetes to run Windows workloads. Work to support Windows Server in Kubernetes began in earnest about 12 months ago. [SIG-Windows](https://github.com/kubernetes/community/tree/master/sig-windows)has now promoted this feature to beta status, which means that we can evaluate it for [usage](/docs/getting-started-guides/windows/). @@ -46,7 +46,7 @@ Each Special Interest Group (SIG) in the community continues to deliver the most ## Availability -Kubernetes 1.9 is available for [download on GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.9.0). To get started with Kubernetes, check out these [interactive tutorials](https://kubernetes.io/docs/tutorials/kubernetes-basics/).  +Kubernetes 1.9 is available for [download on GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.9.0). To get started with Kubernetes, check out these [interactive tutorials](/docs/tutorials/kubernetes-basics/).  diff --git a/content/en/blog/_posts/2017-12-00-Using-Ebpf-In-Kubernetes.md b/content/en/blog/_posts/2017-12-00-Using-Ebpf-In-Kubernetes.md index 8ee87f02cf..7cf7746775 100644 --- a/content/en/blog/_posts/2017-12-00-Using-Ebpf-In-Kubernetes.md +++ b/content/en/blog/_posts/2017-12-00-Using-Ebpf-In-Kubernetes.md @@ -67,7 +67,7 @@ The original implementation of seccomp was highly restrictive. Once applied, if [seccomp-bpf](https://blog.yadutaf.fr/2014/05/29/introduction-to-seccomp-bpf-linux-syscall-filter/) enables more complex filters and a wider range of actions. Seccomp-bpf, also known as seccomp mode 2, allows for applying custom filters in the form of BPF programs. When the BPF program is loaded, the filter is applied to each syscall and the appropriate action is taken (Allow, Kill, Trap, etc.). -seccomp-bpf is widely used in Kubernetes tools and exposed in Kubernetes itself. For example, seccomp-bpf is used in Docker to apply custom [seccomp security profiles](https://docs.docker.com/engine/security/seccomp/), in rkt to apply [seccomp isolators](https://github.com/rkt/rkt/blob/5fadf0f1f444cdfde40d57e1d199b6dd6371594c/Documentation/seccomp-guide.md), and in Kubernetes itself in its [Security Context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/). +seccomp-bpf is widely used in Kubernetes tools and exposed in Kubernetes itself. For example, seccomp-bpf is used in Docker to apply custom [seccomp security profiles](https://docs.docker.com/engine/security/seccomp/), in rkt to apply [seccomp isolators](https://github.com/rkt/rkt/blob/5fadf0f1f444cdfde40d57e1d199b6dd6371594c/Documentation/seccomp-guide.md), and in Kubernetes itself in its [Security Context](/docs/tasks/configure-pod-container/security-context/). But in all of these cases the use of BPF is hidden behind [libseccomp](https://github.com/seccomp/libseccomp). Behind the scenes, libseccomp generates BPF code from rules provided to it. Once generated, the BPF program is loaded and the rules applied. @@ -117,7 +117,7 @@ To achieve the best possible isolation, each function call would have to happen By using Landlock, we could isolate function calls from each other within the same container, making a temporary file created by one function call inaccessible to the next function call, for example. Integration between Landlock and technologies like Kubernetes-based serverless frameworks would be a ripe area for further exploration. ## Auditing kubectl-exec with eBPF -In Kubernetes 1.7 the [audit proposal](https://kubernetes.io/docs/tasks/debug-application-cluster/audit/) started making its way in. It's currently pre-stable with plans to be stable in the 1.10 release. As the name implies, it allows administrators to log and audit events that take place in a Kubernetes cluster. +In Kubernetes 1.7 the [audit proposal](/docs/tasks/debug-application-cluster/audit/) started making its way in. It's currently pre-stable with plans to be stable in the 1.10 release. As the name implies, it allows administrators to log and audit events that take place in a Kubernetes cluster. While these events log Kubernetes events, they don't currently provide the level of visibility that some may require. For example, while we can see that someone has used `kubectl exec` to enter a container, we are not able to see what commands were executed in that session. With eBPF one can attach a BPF program that would record any commands executed in the `kubectl exec` session and pass those commands to a user-space program that logs those events. We could then play that session back and know the exact sequence of events that took place. ## Learn more about eBPF diff --git a/content/en/blog/_posts/2018-01-00-Core-Workloads-Api-Ga.md b/content/en/blog/_posts/2018-01-00-Core-Workloads-Api-Ga.md index 570342a126..385e6a814a 100644 --- a/content/en/blog/_posts/2018-01-00-Core-Workloads-Api-Ga.md +++ b/content/en/blog/_posts/2018-01-00-Core-Workloads-Api-Ga.md @@ -11,15 +11,15 @@ url: /blog/2018/01/Core-Workloads-Api-Ga ## In the Beginning … -There were [Pods](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/), tightly coupled containers that share resource requirements, networking, storage, and a lifecycle. Pods were useful, but, as it turns out, users wanted to seamlessly, reproducibly, and automatically create many identical replicas of the same Pod, so we created [ReplicationController](https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/). +There were [Pods](/docs/concepts/workloads/pods/pod-overview/), tightly coupled containers that share resource requirements, networking, storage, and a lifecycle. Pods were useful, but, as it turns out, users wanted to seamlessly, reproducibly, and automatically create many identical replicas of the same Pod, so we created [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/). -Replication was a step forward, but what users really needed was higher level orchestration of their replicated Pods. They wanted rolling updates, roll backs, and roll overs. So the OpenShift team created [DeploymentConfig](https://docs.openshift.org/latest/architecture/core_concepts/deployments.html#deployments-and-deployment-configurations). DeploymentConfigs were also useful, and OpenShift users were happy. In order to allow all OSS Kubernetes uses to share in the elation, and to take advantage of [set-based label selectors](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors), [ReplicaSet](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/) and [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) were added to the extensions/v1beta1 group version providing rolling updates, roll backs, and roll overs for all Kubernetes users. +Replication was a step forward, but what users really needed was higher level orchestration of their replicated Pods. They wanted rolling updates, roll backs, and roll overs. So the OpenShift team created [DeploymentConfig](https://docs.openshift.org/latest/architecture/core_concepts/deployments.html#deployments-and-deployment-configurations). DeploymentConfigs were also useful, and OpenShift users were happy. In order to allow all OSS Kubernetes uses to share in the elation, and to take advantage of [set-based label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors), [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) and [Deployment](/docs/concepts/workloads/controllers/deployment/) were added to the extensions/v1beta1 group version providing rolling updates, roll backs, and roll overs for all Kubernetes users. -That mostly solved the problem of orchestrating containerized 12 factor apps on Kubernetes, so the community turned its attention to a different problem. Replicating a Pod \ times isn’t the right hammer for every nail in your cluster. Sometimes, you need to run a Pod on every Node, or on a subset of Nodes (for example, shared side cars like log shippers and metrics collectors, Kubernetes add-ons, and Distributed File Systems). The state of the art was Pods combined with NodeSelectors, or static Pods, but this is unwieldy. After having grown used to the ease of automation provided by Deployments, users demanded the same features for this category of application, so [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) was added to extension/v1beta1 as well. +That mostly solved the problem of orchestrating containerized 12 factor apps on Kubernetes, so the community turned its attention to a different problem. Replicating a Pod \ times isn’t the right hammer for every nail in your cluster. Sometimes, you need to run a Pod on every Node, or on a subset of Nodes (for example, shared side cars like log shippers and metrics collectors, Kubernetes add-ons, and Distributed File Systems). The state of the art was Pods combined with NodeSelectors, or static Pods, but this is unwieldy. After having grown used to the ease of automation provided by Deployments, users demanded the same features for this category of application, so [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) was added to extension/v1beta1 as well. For a time, users were content, until they decided that Kubernetes needed to be able to orchestrate more than just 12 factor apps and cluster infrastructure. Whether your architecture is N-tier, service oriented, or micro-service oriented, your 12 factor apps depend on stateful workloads (for example, RDBMSs, distributed key value stores, and messaging queues) to provide services to end users and other applications. These stateful workloads can have availability and durability requirements that can only be achieved by distributed systems, and users were ready to use Kubernetes to orchestrate the entire stack. -While Deployments are great for stateless workloads, they don’t provide the right guarantees for the orchestration of distributed systems. These applications can require stable network identities, ordered, sequential deployment, updates, and deletion, and stable, durable storage. [PetSet](https://kubernetes.io/docs/tasks/run-application/upgrade-pet-set-to-stateful-set/) was added to the apps/v1beta1 group version to address this category of application. Unfortunately, [we were less than thoughtful with its naming](https://github.com/kubernetes/kubernetes/issues/27430), and, as we always strive to be an inclusive community, we renamed the kind to [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/). +While Deployments are great for stateless workloads, they don’t provide the right guarantees for the orchestration of distributed systems. These applications can require stable network identities, ordered, sequential deployment, updates, and deletion, and stable, durable storage. [PetSet](/docs/tasks/run-application/upgrade-pet-set-to-stateful-set/) was added to the apps/v1beta1 group version to address this category of application. Unfortunately, [we were less than thoughtful with its naming](https://github.com/kubernetes/kubernetes/issues/27430), and, as we always strive to be an inclusive community, we renamed the kind to [StatefulSet](/docs/concepts/workloads/controllers/statefulset/). Finally, we were done. @@ -44,7 +44,7 @@ This was completely incompatible with strategic merge patch and kubectl apply. M ### Immutable Selectors -Selector mutation, while allowing for some use cases like promotable Deployment canaries, is not handled gracefully by our workload controllers, and we have always [strongly cautioned users against it](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#label-selector-updates). To provide a consistent, usable, and stable API, selectors were made immutable for all kinds in the workloads API. +Selector mutation, while allowing for some use cases like promotable Deployment canaries, is not handled gracefully by our workload controllers, and we have always [strongly cautioned users against it](/docs/concepts/workloads/controllers/deployment/#label-selector-updates). To provide a consistent, usable, and stable API, selectors were made immutable for all kinds in the workloads API. We believe that there are better ways to support features like promotable canaries and orchestrated Pod relabeling, but, if restricted selector mutation is a necessary feature for our users, we can relax immutability in the future without breaking backward compatibility. @@ -83,9 +83,9 @@ We originally added a scale subresource to the apps group. This was the wrong di ## Migration and Deprecation -The question most you’re probably asking now is, “What’s my migration path onto apps/v1 and how soon should I plan on migrating?” All of the group versions prior to apps/v1 are deprecated as of Kubernetes 1.9, and all new code should be developed against apps/v1, but, as discussed above, many of our users treat extensions/v1beta1 as if it were GA. We realize this, and the minimum support timelines in our [deprecation policy](https://kubernetes.io/docs/reference/deprecation-policy/) are just that, minimums. +The question most you’re probably asking now is, “What’s my migration path onto apps/v1 and how soon should I plan on migrating?” All of the group versions prior to apps/v1 are deprecated as of Kubernetes 1.9, and all new code should be developed against apps/v1, but, as discussed above, many of our users treat extensions/v1beta1 as if it were GA. We realize this, and the minimum support timelines in our [deprecation policy](/docs/reference/deprecation-policy/) are just that, minimums. -In future releases, before completely removing any of the group versions, we will disable them by default in the API Server. At this point, you will still be able to use the group version, but you will have to explicitly enable it. We will also provide utilities to upgrade the storage version of the API objects to apps/v1. Remember, all of the versions of the core workloads kinds are bidirectionally convertible. If you want to manually update your core workloads API objects now, you can use [kubectl convert](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#convert) to convert manifests between group versions. +In future releases, before completely removing any of the group versions, we will disable them by default in the API Server. At this point, you will still be able to use the group version, but you will have to explicitly enable it. We will also provide utilities to upgrade the storage version of the API objects to apps/v1. Remember, all of the versions of the core workloads kinds are bidirectionally convertible. If you want to manually update your core workloads API objects now, you can use [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert) to convert manifests between group versions. diff --git a/content/en/blog/_posts/2018-01-00-Extensible-Admission-Is-Beta.md b/content/en/blog/_posts/2018-01-00-Extensible-Admission-Is-Beta.md index cc258be758..07e1892bf4 100644 --- a/content/en/blog/_posts/2018-01-00-Extensible-Admission-Is-Beta.md +++ b/content/en/blog/_posts/2018-01-00-Extensible-Admission-Is-Beta.md @@ -11,7 +11,7 @@ The admission stage of API server processing is one of the most powerful tools f ## What is Admission? -[Admission](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#what-are-they) is the phase of [handling an API server request](https://blog.openshift.com/kubernetes-deep-dive-api-server-part-1/) that happens before a resource is persisted, but after authorization. Admission gets access to the same information as authorization (user, URL, etc) and the complete body of an API request (for most requests). +[Admission](/docs/reference/access-authn-authz/admission-controllers/#what-are-they) is the phase of [handling an API server request](https://blog.openshift.com/kubernetes-deep-dive-api-server-part-1/) that happens before a resource is persisted, but after authorization. Admission gets access to the same information as authorization (user, URL, etc) and the complete body of an API request (for most requests). [![](https://2.bp.blogspot.com/-p8WGg2BATsY/WlfywbD_tAI/AAAAAAAAAJw/mDqZV0dB4_Y0gXXQp_1tQ7CtMRSd6lHVwCK4BGAYYCw/s640/Screen%2BShot%2B2018-01-11%2Bat%2B3.22.07%2BPM.png)](https://2.bp.blogspot.com/-p8WGg2BATsY/WlfywbD_tAI/AAAAAAAAAJw/mDqZV0dB4_Y0gXXQp_1tQ7CtMRSd6lHVwCK4BGAYYCw/s1600/Screen%2BShot%2B2018-01-11%2Bat%2B3.22.07%2BPM.png) diff --git a/content/en/blog/_posts/2018-01-00-Introducing-Client-Go-Version-6.md b/content/en/blog/_posts/2018-01-00-Introducing-Client-Go-Version-6.md index fecda0a338..067d555cdf 100644 --- a/content/en/blog/_posts/2018-01-00-Introducing-Client-Go-Version-6.md +++ b/content/en/blog/_posts/2018-01-00-Introducing-Client-Go-Version-6.md @@ -16,13 +16,13 @@ This blog post is one of a number of efforts to make client-go more accessible t The following API group promotions are part of Kubernetes 1.9: -- Workload objects (Deployments, DaemonSets, ReplicaSets, and StatefulSets) have been [promoted to the apps/v1 API group in Kubernetes 1.9](https://kubernetes.io/docs/reference/workloads-18-19/). client-go follows this transition and allows developers to use the latest version by importing the k8s.io/api/apps/v1 package instead of k8s.io/api/apps/v1beta1 and by using Clientset.AppsV1(). -- Admission Webhook Registration has been promoted to the admissionregistration.k8s.io/v1beta1 API group in Kubernetes 1.9. The former ExternalAdmissionHookConfiguration type has been replaced by the incompatible ValidatingWebhookConfiguration and MutatingWebhookConfiguration types. Moreover, the webhook admission payload type AdmissionReview in admission.k8s.io has been promoted to v1beta1. Note that versioned objects are now passed to webhooks. Refer to the admission webhook [documentation](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) for details. +- Workload objects (Deployments, DaemonSets, ReplicaSets, and StatefulSets) have been [promoted to the apps/v1 API group in Kubernetes 1.9](/docs/reference/workloads-18-19/). client-go follows this transition and allows developers to use the latest version by importing the k8s.io/api/apps/v1 package instead of k8s.io/api/apps/v1beta1 and by using Clientset.AppsV1(). +- Admission Webhook Registration has been promoted to the admissionregistration.k8s.io/v1beta1 API group in Kubernetes 1.9. The former ExternalAdmissionHookConfiguration type has been replaced by the incompatible ValidatingWebhookConfiguration and MutatingWebhookConfiguration types. Moreover, the webhook admission payload type AdmissionReview in admission.k8s.io has been promoted to v1beta1. Note that versioned objects are now passed to webhooks. Refer to the admission webhook [documentation](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) for details. ## Validation for CustomResources -In Kubernetes 1.8 we introduced CustomResourceDefinitions (CRD) [pre-persistence schema validation](https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) as an alpha feature. With 1.9, the feature got promoted to beta and will be enabled by default. As a client-go user, you will find the API types at k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1beta1. +In Kubernetes 1.8 we introduced CustomResourceDefinitions (CRD) [pre-persistence schema validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) as an alpha feature. With 1.9, the feature got promoted to beta and will be enabled by default. As a client-go user, you will find the API types at k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1beta1. The [OpenAPI v3 schema](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#schemaObject) can be defined in the CRD spec as: @@ -84,12 +84,12 @@ spec.version in body should be one of [v1.0.0 v1.0.1] -Note that with [Admission Webhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks), Kubernetes 1.9 provides another beta feature to validate objects before they are created or updated. Starting with 1.9, these webhooks also allow mutation of objects (for example, to set defaults or to inject values). Of course, webhooks work with CRDs as well. Moreover, webhooks can be used to implement validations that are not easily expressible with CRD validation. Note that webhooks are harder to implement than CRD validation, so for many purposes, CRD validation is the right tool. +Note that with [Admission Webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks), Kubernetes 1.9 provides another beta feature to validate objects before they are created or updated. Starting with 1.9, these webhooks also allow mutation of objects (for example, to set defaults or to inject values). Of course, webhooks work with CRDs as well. Moreover, webhooks can be used to implement validations that are not easily expressible with CRD validation. Note that webhooks are harder to implement than CRD validation, so for many purposes, CRD validation is the right tool. ## Creating namespaced informers -Often objects in one namespace or only with certain labels are to be processed in a controller. Informers [now allow](https://github.com/kubernetes/kubernetes/pull/54660) you to tweak the ListOptions used to query the API server to list and watch objects. Uninitialized objects (for consumption by [initializers](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-initializers)) can be made visible by setting IncludeUnitialized to true. All this can be done using the new NewFilteredSharedInformerFactory constructor for shared informers: +Often objects in one namespace or only with certain labels are to be processed in a controller. Informers [now allow](https://github.com/kubernetes/kubernetes/pull/54660) you to tweak the ListOptions used to query the API server to list and watch objects. Uninitialized objects (for consumption by [initializers](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-initializers)) can be made visible by setting IncludeUnitialized to true. All this can be done using the new NewFilteredSharedInformerFactory constructor for shared informers: ``` @@ -251,7 +251,7 @@ It’s finally possible to have dots in Go package names. In this section’s ex ## Example projects Kubernetes 1.9 includes a number of example projects which can serve as a blueprint for your own projects: -- [k8s.io/sample-apiserver](https://github.com/kubernetes/sample-apiserver) is a simple user-provided API server that is integrated into a cluster via [API aggregation](https://kubernetes.io/docs/concepts/api-extension/apiserver-aggregation/). +- [k8s.io/sample-apiserver](https://github.com/kubernetes/sample-apiserver) is a simple user-provided API server that is integrated into a cluster via [API aggregation](/docs/concepts/api-extension/apiserver-aggregation/). - [k8s.io/sample-controller](https://github.com/kubernetes/sample-controller) is a full-featured [controller](https://github.com/kubernetes/community/blob/master/contributors/devel/controllers.md) (also called an operator) with shared informers and a workqueue to process created, changed or deleted objects. It is based on CustomResourceDefinitions and uses [k8s.io/code-generator](https://github.com/kubernetes/code-generator) to generate deepcopy functions, typed clientsets, informers, and listers. diff --git a/content/en/blog/_posts/2018-01-00-Introducing-Container-Storage-Interface.md b/content/en/blog/_posts/2018-01-00-Introducing-Container-Storage-Interface.md index a50e30ac46..1eb099f0c1 100644 --- a/content/en/blog/_posts/2018-01-00-Introducing-Container-Storage-Interface.md +++ b/content/en/blog/_posts/2018-01-00-Introducing-Container-Storage-Interface.md @@ -5,7 +5,7 @@ slug: introducing-container-storage-interface url: /blog/2018/01/Introducing-Container-Storage-Interface --- -One of the key differentiators for Kubernetes has been a powerful [volume plugin system](https://kubernetes.io/docs/concepts/storage/volumes/) that enables many different types of storage systems to: +One of the key differentiators for Kubernetes has been a powerful [volume plugin system](/docs/concepts/storage/volumes/) that enables many different types of storage systems to: 1. Automatically create storage when required. 2. Make storage available to containers wherever they’re scheduled. diff --git a/content/en/blog/_posts/2018-01-00-Kubernetes-V19-Beta-Windows-Support.md b/content/en/blog/_posts/2018-01-00-Kubernetes-V19-Beta-Windows-Support.md index 537f434c94..9d059827d9 100644 --- a/content/en/blog/_posts/2018-01-00-Kubernetes-V19-Beta-Windows-Support.md +++ b/content/en/blog/_posts/2018-01-00-Kubernetes-V19-Beta-Windows-Support.md @@ -29,7 +29,7 @@ The crown jewels of Kubernetes 1.9 Windows support, however, are the networking 1. Upstream L3 Routing - IP routes configured in upstream ToR 2. Host-Gateway - IP routes configured on each host 3. Open vSwitch (OVS) & Open Virtual Network (OVN) with Overlay - Supports STT and Geneve tunneling types -You can read more about each of their [configuration, setup, and runtime capabilities](https://kubernetes.io/docs/getting-started-guides/windows/) to make an informed selection for your networking stack in Kubernetes. +You can read more about each of their [configuration, setup, and runtime capabilities](/docs/getting-started-guides/windows/) to make an informed selection for your networking stack in Kubernetes. Even though you have to continue running the Kubernetes Control Plane and Master Components in Linux, you are now able to introduce Windows Server as a Node in Kubernetes. As a community, this is a huge milestone and achievement. We will now start seeing .NET, .NET Core, ASP.NET, IIS, Windows Services, Windows executables and many more windows-based applications in Kubernetes. @@ -53,7 +53,7 @@ Even though we have not committed to a timeline for GA, SIG-Windows estimates a ### Get Involved As we continue to make progress towards General Availability of this feature in Kubernetes, we welcome you to get involved, contribute code, provide feedback, deploy Windows Server containers to your Kubernetes cluster, or simply join our community. -- If you want to get started on deploying Windows Server containers in Kubernetes, read our getting started guide at [https://kubernetes.io/docs/getting-started-guides/windows/](https://kubernetes.io/docs/getting-started-guides/windows/) +- If you want to get started on deploying Windows Server containers in Kubernetes, read our getting started guide at [/docs/getting-started-guides/windows/](/docs/getting-started-guides/windows/) - We meet every other Tuesday at 12:30 Eastern Standard Time (EST) at [https://zoom.us/my/sigwindows](https://zoom.us/my/sigwindows). All our meetings are recorded on youtube and referenced at [https://www.youtube.com/playlist?list=PL69nYSiGNLP2OH9InCcNkWNu2bl-gmIU4](https://www.youtube.com/playlist?list=PL69nYSiGNLP2OH9InCcNkWNu2bl-gmIU4) - Chat with us on Slack at [https://kubernetes.slack.com/messages/sig-windows](https://kubernetes.slack.com/messages/sig-windows) - Find us on GitHub at [https://github.com/kubernetes/community/tree/master/sig-windows](https://github.com/kubernetes/community/tree/master/sig-windows) diff --git a/content/en/blog/_posts/2018-01-00-Reporting-Errors-Using-Kubernetes-Events.md b/content/en/blog/_posts/2018-01-00-Reporting-Errors-Using-Kubernetes-Events.md index 213bf4cc29..488a862236 100644 --- a/content/en/blog/_posts/2018-01-00-Reporting-Errors-Using-Kubernetes-Events.md +++ b/content/en/blog/_posts/2018-01-00-Reporting-Errors-Using-Kubernetes-Events.md @@ -15,7 +15,7 @@ One use case of Box’s control plane is [public key infrastructure](https://en. | Figure1: Block Diagram of the PKI flow | -If an application needs a new certificate, the application owner explicitly adds a [Custom Resource Definition](https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/) (CRD) to the application’s Kubernetes config [1]. This CRD specifies parameters for the SSL certificate: _name, common name, and others_. A microservice in the control plane watches CRDs and triggers some processing for SSL certificate generation [2]. Once the certificate is ready, the same control plane service sends it to the API server in a Kubernetes [Secret](https://kubernetes.io/docs/concepts/configuration/secret/) [3]. After that, the application containers access their certificates using Kubernetes [Secret VolumeMounts](https://kubernetes.io/docs/concepts/storage/volumes/#secret) [4]. You can see a working demo of this system in our [example application](https://github.com/box/error-reporting-with-kubernetes-events) on GitHub. +If an application needs a new certificate, the application owner explicitly adds a [Custom Resource Definition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/) (CRD) to the application’s Kubernetes config [1]. This CRD specifies parameters for the SSL certificate: _name, common name, and others_. A microservice in the control plane watches CRDs and triggers some processing for SSL certificate generation [2]. Once the certificate is ready, the same control plane service sends it to the API server in a Kubernetes [Secret](/docs/concepts/configuration/secret/) [3]. After that, the application containers access their certificates using Kubernetes [Secret VolumeMounts](/docs/concepts/storage/volumes/#secret) [4]. You can see a working demo of this system in our [example application](https://github.com/box/error-reporting-with-kubernetes-events) on GitHub. The rest of this post covers the error scenarios in this “triggered” processing in the control plane. In particular, we are especially concerned with user input errors. Because the SSL certificate parameters come from the application’s config file in a CRD format, what should happen if there is an error in that CRD specification? Even a typo results in a failure of the SSL certificate creation. The error information is available in the control plane even though the root cause is most probably inside the application’s config file. The application owner does not have access to the control plane’s state or logs. diff --git a/content/en/blog/_posts/2018-03-26-kubernetes-1-10-stabilizing-storage-security-networking.md b/content/en/blog/_posts/2018-03-26-kubernetes-1-10-stabilizing-storage-security-networking.md index 4ebfacfa12..8beec44ef3 100644 --- a/content/en/blog/_posts/2018-03-26-kubernetes-1-10-stabilizing-storage-security-networking.md +++ b/content/en/blog/_posts/2018-03-26-kubernetes-1-10-stabilizing-storage-security-networking.md @@ -61,14 +61,14 @@ providers, vendors, and other platform developers can now release binary plugins to handle authentication for specific cloud-provider IAM services, or that integrate with in-house authentication systems that aren’t supported in-tree, such as Active Directory. This complements the [Cloud Controller -Manager](https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/) +Manager](/docs/tasks/administer-cluster/running-cloud-controller/) feature added in 1.9. ## Networking - CoreDNS as a DNS provider (beta) The ability to [switch the DNS service](https://github.com/kubernetes/website/pull/7638) to CoreDNS at -[install time](https://kubernetes.io/docs/tasks/administer-cluster/coredns/) +[install time](/docs/tasks/administer-cluster/coredns/) is now in beta. CoreDNS has fewer moving parts: it’s a single executable and a single process, and supports additional use cases. @@ -83,7 +83,7 @@ notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.10.md#11 Kubernetes 1.10 is available for [download on GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.10.0). To get started with Kubernetes, check out these i[nteractive -tutorials](https://kubernetes.io/docs/tutorials/). +tutorials](/docs/tutorials/). ## 2 Day Features Blog Series diff --git a/content/en/blog/_posts/2018-04-04-fixing-subpath-volume-vulnerability.md b/content/en/blog/_posts/2018-04-04-fixing-subpath-volume-vulnerability.md index b7a25e7473..88b0113dd1 100644 --- a/content/en/blog/_posts/2018-04-04-fixing-subpath-volume-vulnerability.md +++ b/content/en/blog/_posts/2018-04-04-fixing-subpath-volume-vulnerability.md @@ -4,7 +4,7 @@ date: 2018-04-04 slug: fixing-subpath-volume-vulnerability --- -On March 12, 2018, the Kubernetes Product Security team disclosed [CVE-2017-1002101](https://issue.k8s.io/60813), which allowed containers using [subpath](https://kubernetes.io/docs/concepts/storage/volumes/#using-subpath) volume mounts to access files outside of the volume. This means that a container could access any file available on the host, including volumes for other containers that it should not have access to. +On March 12, 2018, the Kubernetes Product Security team disclosed [CVE-2017-1002101](https://issue.k8s.io/60813), which allowed containers using [subpath](/docs/concepts/storage/volumes/#using-subpath) volume mounts to access files outside of the volume. This means that a container could access any file available on the host, including volumes for other containers that it should not have access to. The vulnerability has been fixed and released in the latest Kubernetes patch releases. We recommend that all users upgrade to get the fix. For more details on the impact and how to get the fix, please see the [announcement](https://groups.google.com/forum/#!topic/kubernetes-announce/6sNHO_jyBzE). (Note, some functional regressions were found after the initial fix and are being tracked in [issue #61563](https://github.com/kubernetes/kubernetes/issues/61563)). diff --git a/content/en/blog/_posts/2018-04-10-container-storage-interface-beta.md b/content/en/blog/_posts/2018-04-10-container-storage-interface-beta.md index 79f0741d71..4e3fd89584 100644 --- a/content/en/blog/_posts/2018-04-10-container-storage-interface-beta.md +++ b/content/en/blog/_posts/2018-04-10-container-storage-interface-beta.md @@ -24,7 +24,7 @@ With the promotion to beta CSI is now enabled by default on standard Kubernetes The move of the Kubernetes implementation of CSI to beta also means: * Kubernetes is compatible with [v0.2](https://github.com/container-storage-interface/spec/releases/tag/v0.2.0) of the CSI spec (instead of [v0.1](https://github.com/container-storage-interface/spec/releases/tag/v0.1.0)) * There were breaking changes between the CSI spec v0.1 and v0.2, so existing CSI drivers must be updated to be 0.2 compatible before use with Kubernetes 1.10.0+. -* [Mount propagation](https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation), a feature that allows bidirectional mounts between containers and host (a requirement for containerized CSI drivers), has also moved to beta. +* [Mount propagation](/docs/concepts/storage/volumes/#mount-propagation), a feature that allows bidirectional mounts between containers and host (a requirement for containerized CSI drivers), has also moved to beta. * The Kubernetes `VolumeAttachment` object, introduced in v1.9 in the storage v1alpha1 group, has been added to the storage v1beta1 group. * The Kubernetes `CSIPersistentVolumeSource` object has been promoted to beta. A `VolumeAttributes` field was added to Kubernetes `CSIPersistentVolumeSource` object (in alpha this was passed around via annotations). @@ -161,7 +161,7 @@ As part of the suggested deployment process, the Kubernetes team provides the fo * [driver-registrar](https://github.com/kubernetes-csi/driver-registrar) * registers the CSI driver with kubelet (in the future) and adds the drivers custom `NodeId` (retrieved via `GetNodeID` call against the CSI endpoint) to an annotation on the Kubernetes Node API Object * [livenessprobe](https://github.com/kubernetes-csi/livenessprobe) - * can be included in a CSI plugin pod to enable the [Kubernetes Liveness Probe](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) mechanism + * can be included in a CSI plugin pod to enable the [Kubernetes Liveness Probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) mechanism Storage vendors can build Kubernetes deployments for their plugins using these components, while leaving their CSI driver completely unaware of Kubernetes. diff --git a/content/en/blog/_posts/2018-04-13-local-persistent-volumes-beta.md b/content/en/blog/_posts/2018-04-13-local-persistent-volumes-beta.md index 0c867dc9ee..42f9b60e66 100644 --- a/content/en/blog/_posts/2018-04-13-local-persistent-volumes-beta.md +++ b/content/en/blog/_posts/2018-04-13-local-persistent-volumes-beta.md @@ -4,7 +4,7 @@ date: 2018-04-13 slug: local-persistent-volumes-beta --- -The [Local Persistent Volumes](https://kubernetes.io/docs/concepts/storage/volumes/#local) beta feature in Kubernetes 1.10 makes it possible to leverage local disks in your StatefulSets. You can specify directly-attached local disks as PersistentVolumes, and use them in StatefulSets with the same PersistentVolumeClaim objects that previously only supported remote volume types. +The [Local Persistent Volumes](/docs/concepts/storage/volumes/#local) beta feature in Kubernetes 1.10 makes it possible to leverage local disks in your StatefulSets. You can specify directly-attached local disks as PersistentVolumes, and use them in StatefulSets with the same PersistentVolumeClaim objects that previously only supported remote volume types. Persistent storage is important for running stateful applications, and Kubernetes has supported these workloads with StatefulSets, PersistentVolumeClaims and PersistentVolumes. These primitives have supported remote volume types well, where the volumes can be accessed from any node in the cluster, but did not support local volumes, where the volumes can only be accessed from a specific node. The demand for using local, fast SSDs in replicated, stateful workloads has increased with demand to run more workloads in Kubernetes. @@ -129,7 +129,7 @@ kind: StatefulSet ## Documentation -The Kubernetes website provides full documentation for [local persistent volumes](https://kubernetes.io/docs/concepts/storage/volumes/#local). +The Kubernetes website provides full documentation for [local persistent volumes](/docs/concepts/storage/volumes/#local). ## Future enhancements @@ -140,11 +140,11 @@ The local persistent volume beta feature is not complete by far. Some notable en ## Complementary features -[Pod priority and preemption](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/) is another Kubernetes feature that is complementary to local persistent volumes. When your application uses local storage, it must be scheduled to the specific node where the local volume resides. You can give your local storage workload high priority so if that node ran out of room to run your workload, Kubernetes can preempt lower priority workloads to make room for it. +[Pod priority and preemption](/docs/concepts/configuration/pod-priority-preemption/) is another Kubernetes feature that is complementary to local persistent volumes. When your application uses local storage, it must be scheduled to the specific node where the local volume resides. You can give your local storage workload high priority so if that node ran out of room to run your workload, Kubernetes can preempt lower priority workloads to make room for it. -[Pod disruption budget](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/) is also very important for those workloads that must maintain quorum. Setting a disruption budget for your workload ensures that it does not drop below quorum due to voluntary disruption events, such as node drains during upgrade. +[Pod disruption budget](/docs/concepts/workloads/pods/disruptions/) is also very important for those workloads that must maintain quorum. Setting a disruption budget for your workload ensures that it does not drop below quorum due to voluntary disruption events, such as node drains during upgrade. -[Pod affinity and anti-affinity](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature) ensures that your workloads stay either co-located or spread out across failure domains. If you have multiple local persistent volumes available on a single node, it may be preferable to specify an pod anti-affinity policy to spread your workload across nodes. Note that if you want multiple pods to share the same local persistent volume, you do not need to specify a pod affinity policy. The scheduler understands the locality constraints of the local persistent volume and schedules your pod to the correct node. +[Pod affinity and anti-affinity](/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature) ensures that your workloads stay either co-located or spread out across failure domains. If you have multiple local persistent volumes available on a single node, it may be preferable to specify an pod anti-affinity policy to spread your workload across nodes. Note that if you want multiple pods to share the same local persistent volume, you do not need to specify a pod affinity policy. The scheduler understands the locality constraints of the local persistent volume and schedules your pod to the correct node. ## Getting involved diff --git a/content/en/blog/_posts/2018-04-25-open-source-charts-2017.md b/content/en/blog/_posts/2018-04-25-open-source-charts-2017.md index 0051669ebb..8dbda89abe 100644 --- a/content/en/blog/_posts/2018-04-25-open-source-charts-2017.md +++ b/content/en/blog/_posts/2018-04-25-open-source-charts-2017.md @@ -6,7 +6,7 @@ slug: open-source-charts-2017 2017 was a huge year for Kubernetes, and GitHub’s latest [Octoverse report](https://octoverse.github.com) illustrates just how much attention this project has been getting. -Kubernetes, an [open source platform for running application containers](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/), provides a consistent interface that enables developers and ops teams to automate the deployment, management, and scaling of a wide variety of applications on just about any infrastructure. +Kubernetes, an [open source platform for running application containers](/docs/concepts/overview/what-is-kubernetes/), provides a consistent interface that enables developers and ops teams to automate the deployment, management, and scaling of a wide variety of applications on just about any infrastructure. Solving these shared challenges by leveraging a wide community of expertise and industrial experience, as Kubernetes does, helps engineers focus on building their own products at the top of the stack, rather than needlessly duplicating work that now exists as a standard part of the “cloud native” toolkit. diff --git a/content/en/blog/_posts/2018-05-01-developing-on-kubernetes.md b/content/en/blog/_posts/2018-05-01-developing-on-kubernetes.md index f17d73a9c6..3f931b7eee 100644 --- a/content/en/blog/_posts/2018-05-01-developing-on-kubernetes.md +++ b/content/en/blog/_posts/2018-05-01-developing-on-kubernetes.md @@ -21,7 +21,7 @@ As a developer you want to think about where the Kubernetes cluster you’re dev A number of tools support pure offline development including Minikube, Docker for Mac/Windows, Minishift, and the ones we discuss in detail below. Sometimes, for example, in a microservices setup where certain microservices already run in the cluster, a proxied setup (forwarding traffic into and from the cluster) is preferable and Telepresence is an example tool in this category. The live mode essentially means you’re building and/or deploying against a remote cluster and, finally, the pure online mode means both your development environment and the cluster are remote, as this is the case with, for example, [Eclipse Che](https://www.eclipse.org/che/docs/kubernetes-single-user.html) or [Cloud 9](https://github.com/errordeveloper/k9c). Let’s now have a closer look at the basics of offline development: running Kubernetes locally. -[Minikube](https://kubernetes.io/docs/getting-started-guides/minikube/) is a popular choice for those who prefer to run Kubernetes in a local VM. More recently Docker for [Mac](https://docs.docker.com/docker-for-mac/kubernetes/) and [Windows](https://docs.docker.com/docker-for-windows/kubernetes/) started shipping Kubernetes as an experimental package (in the “edge” channel). Some reasons why you may want to prefer using Minikube over the Docker desktop option are: +[Minikube](/docs/getting-started-guides/minikube/) is a popular choice for those who prefer to run Kubernetes in a local VM. More recently Docker for [Mac](https://docs.docker.com/docker-for-mac/kubernetes/) and [Windows](https://docs.docker.com/docker-for-windows/kubernetes/) started shipping Kubernetes as an experimental package (in the “edge” channel). Some reasons why you may want to prefer using Minikube over the Docker desktop option are: * You already have Minikube installed and running * You prefer to wait until Docker ships a stable package diff --git a/content/en/blog/_posts/2018-05-17-gardener-the-kubernetes-botanist.md b/content/en/blog/_posts/2018-05-17-gardener-the-kubernetes-botanist.md index 9341d33b68..b22ad9aecb 100644 --- a/content/en/blog/_posts/2018-05-17-gardener-the-kubernetes-botanist.md +++ b/content/en/blog/_posts/2018-05-17-gardener-the-kubernetes-botanist.md @@ -150,7 +150,7 @@ Another important topic we are focusing on is disaster recovery. When a seed clu In order to enable a more independent evolution of the Botanists, which contain the infrastructure provider specific parts of the implementation, we plan to describe well-defined interfaces and factor out the Botanists into their own components. This is similar to what Kubernetes is currently doing with the cloud-controller-manager. Currently, all the cloud specifics are part of the core Gardener repository presenting a soft barrier to extending or supporting new cloud providers. -When taking a look at how the shoots are actually provisioned, we need to gain more experience on how really large clusters with thousands of nodes and pods (or more) behave. Potentially, we will have to deploy e.g. the API server and other components in a scaled-out fashion for large clusters to spread the load. Fortunately, horizontal pod autoscaling based on custom metrics from Prometheus will make this relatively easy with our setup. Additionally, the feedback from teams who run production workloads on our clusters, is that Gardener should support with prearranged Kubernetes [QoS](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/). Needless to say, our aspiration is going to be the integration and contribution to the vision of [Kubernetes Autopilot](https://speakerdeck.com/thockin/a-few-things-to-know-about-resource-scheduling). +When taking a look at how the shoots are actually provisioned, we need to gain more experience on how really large clusters with thousands of nodes and pods (or more) behave. Potentially, we will have to deploy e.g. the API server and other components in a scaled-out fashion for large clusters to spread the load. Fortunately, horizontal pod autoscaling based on custom metrics from Prometheus will make this relatively easy with our setup. Additionally, the feedback from teams who run production workloads on our clusters, is that Gardener should support with prearranged Kubernetes [QoS](/docs/tasks/configure-pod-container/quality-service-pod/). Needless to say, our aspiration is going to be the integration and contribution to the vision of [Kubernetes Autopilot](https://speakerdeck.com/thockin/a-few-things-to-know-about-resource-scheduling). [4] Prototypes already validated CTyun & Aliyun. diff --git a/content/en/blog/_posts/2018-05-22-getting-to-know-kubevirt.md b/content/en/blog/_posts/2018-05-22-getting-to-know-kubevirt.md index 5cfba8de04..556701f2e6 100644 --- a/content/en/blog/_posts/2018-05-22-getting-to-know-kubevirt.md +++ b/content/en/blog/_posts/2018-05-22-getting-to-know-kubevirt.md @@ -9,7 +9,7 @@ Once you've become accustomed to running Linux container workloads on Kubernetes These sorts of workloads are often well-suited to running in virtual machines (VMs), and [KubeVirt](http://www.kubevirt.io/), a virtual machine management add-on for Kubernetes, is aimed at allowing users to run VMs right alongside containers in the their Kubernetes or OpenShift clusters. -KubeVirt extends Kubernetes by adding resource types for VMs and sets of VMs through Kubernetes' [Custom Resource Definitions API](https://kubernetes.io/docs/concepts/api-extension/custom-resources/#customresourcedefinitions) (CRD). KubeVirt VMs run within regular Kubernetes pods, where they have access to standard pod networking and storage, and can be managed using standard Kubernetes tools such as kubectl. +KubeVirt extends Kubernetes by adding resource types for VMs and sets of VMs through Kubernetes' [Custom Resource Definitions API](/docs/concepts/api-extension/custom-resources/#customresourcedefinitions) (CRD). KubeVirt VMs run within regular Kubernetes pods, where they have access to standard pod networking and storage, and can be managed using standard Kubernetes tools such as kubectl. Running VMs with Kubernetes involves a bit of an adjustment compared to using something like oVirt or OpenStack, and understanding the basic architecture of KubeVirt is a good place to begin. @@ -21,7 +21,7 @@ In this post, we’ll talk about some of the components that are involved in Kub ## Custom Resource Definitions -Kubernetes resources are endpoints in the Kubernetes API that store collections of related API objects. For instance, the built-in pods resource contains a collection of Pod objects. The Kubernetes [Custom Resource Definition](https://kubernetes.io/docs/concepts/api-extension/custom-resources/#customresourcedefinitions) API allows users to extend Kubernetes with additional resources by defining new objects with a given name and schema. Once you've applied a custom resource to your cluster, the Kubernetes API server serves and handles the storage of your custom resource. +Kubernetes resources are endpoints in the Kubernetes API that store collections of related API objects. For instance, the built-in pods resource contains a collection of Pod objects. The Kubernetes [Custom Resource Definition](/docs/concepts/api-extension/custom-resources/#customresourcedefinitions) API allows users to extend Kubernetes with additional resources by defining new objects with a given name and schema. Once you've applied a custom resource to your cluster, the Kubernetes API server serves and handles the storage of your custom resource. KubeVirt's primary CRD is the VirtualMachine (VM) resource, which contains a collection of VM objects inside the Kubernetes API server. The VM resource defines all the properties of the Virtual machine itself, such as the machine and CPU type, the amount of RAM and vCPUs, and the number and type of NICs available in the VM. diff --git a/content/en/blog/_posts/2018-05-24-kubernetes-containerd-integration-goes-ga.md b/content/en/blog/_posts/2018-05-24-kubernetes-containerd-integration-goes-ga.md index 4336880154..4dc7c400c9 100644 --- a/content/en/blog/_posts/2018-05-24-kubernetes-containerd-integration-goes-ga.md +++ b/content/en/blog/_posts/2018-05-24-kubernetes-containerd-integration-goes-ga.md @@ -60,7 +60,7 @@ _crictl_ is a tool providing a similar experience to the Docker CLI for Kubernet The scope of _crictl_ is limited to troubleshooting, it is not a replacement to docker or kubectl. Docker's CLI provides a rich set of commands, making it a very useful development tool. But it is not the best fit for troubleshooting on Kubernetes nodes. Some Docker commands are not useful to Kubernetes, such as _docker network_ and _docker build_; and some may even break the system, such as _docker rename_. _crictl_ provides just enough commands for node troubleshooting, which is arguably safer to use on production nodes. ## Kubernetes Oriented -_crictl_ offers a more kubernetes-friendly view of containers. Docker CLI lacks core Kubernetes concepts, e.g. _pod_ and _[namespace](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/)_, so it can't provide a clear view of containers and pods. One example is that _docker ps_ shows somewhat obscure, long Docker container names, and shows pause containers and application containers together: +_crictl_ offers a more kubernetes-friendly view of containers. Docker CLI lacks core Kubernetes concepts, e.g. _pod_ and _[namespace](/docs/concepts/overview/working-with-objects/namespaces/)_, so it can't provide a clear view of containers and pods. One example is that _docker ps_ shows somewhat obscure, long Docker container names, and shows pause containers and application containers together: docker ps diff --git a/content/en/blog/_posts/2018-06-26-kubernetes-1-11-release-announcement.md b/content/en/blog/_posts/2018-06-26-kubernetes-1-11-release-announcement.md index 2e546d291e..4614421d1b 100644 --- a/content/en/blog/_posts/2018-06-26-kubernetes-1-11-release-announcement.md +++ b/content/en/blog/_posts/2018-06-26-kubernetes-1-11-release-announcement.md @@ -25,7 +25,7 @@ In this release, [IPVS-based in-cluster service load balancing](https://github.c ## Dynamic Kubelet Configuration Moves to Beta -This feature makes it possible for new Kubelet configurations to be rolled out in a live cluster. Currently, Kubelets are configured via command-line flags, which makes it difficult to update Kubelet configurations in a running cluster. With this beta feature, [users can configure Kubelets in a live cluster](https://kubernetes.io/docs/tasks/administer-cluster/reconfigure-kubelet/) via the API server. +This feature makes it possible for new Kubelet configurations to be rolled out in a live cluster. Currently, Kubelets are configured via command-line flags, which makes it difficult to update Kubelet configurations in a running cluster. With this beta feature, [users can configure Kubelets in a live cluster](/docs/tasks/administer-cluster/reconfigure-kubelet/) via the API server. ## Custom Resource Definitions Can Now Define Multiple Versions @@ -49,9 +49,9 @@ Each Special Interest Group (SIG) within the community continues to deliver the ## Availability -Kubernetes 1.11 is available for [download on GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.11.0). To get started with Kubernetes, check out these [interactive tutorials](https://kubernetes.io/docs/tutorials/). +Kubernetes 1.11 is available for [download on GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.11.0). To get started with Kubernetes, check out these [interactive tutorials](/docs/tutorials/). -You can also install 1.11 using Kubeadm. Version 1.11.0 will be available as Deb and RPM packages, installable using the [Kubeadm cluster installer](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/) sometime on June 28th. +You can also install 1.11 using Kubeadm. Version 1.11.0 will be available as Deb and RPM packages, installable using the [Kubeadm cluster installer](/docs/setup/independent/create-cluster-kubeadm/) sometime on June 28th. ## 4 Day Features Blog Series diff --git a/content/en/blog/_posts/2018-07-10-coredns-ga.md b/content/en/blog/_posts/2018-07-10-coredns-ga.md index 01c438f131..6a30fa080c 100644 --- a/content/en/blog/_posts/2018-07-10-coredns-ga.md +++ b/content/en/blog/_posts/2018-07-10-coredns-ga.md @@ -42,7 +42,7 @@ primary configuration file that CoreDNS uses for configuration of all of its fea Kubernetes related. When upgrading from kube-dns to CoreDNS using `kubeadm`, your existing ConfigMap will be used to generate the -customized Corefile for you, including all of the configuration for stub domains, federation, and upstream nameservers. See [Using CoreDNS for Service Discovery](https://kubernetes.io/docs/tasks/administer-cluster/coredns/) for more details. +customized Corefile for you, including all of the configuration for stub domains, federation, and upstream nameservers. See [Using CoreDNS for Service Discovery](/docs/tasks/administer-cluster/coredns/) for more details. ## Bug fixes and enhancements diff --git a/content/en/blog/_posts/2018-07-11-dynamic-kubelet-configuration.md b/content/en/blog/_posts/2018-07-11-dynamic-kubelet-configuration.md index 582bb89af3..ed3914f3e5 100644 --- a/content/en/blog/_posts/2018-07-11-dynamic-kubelet-configuration.md +++ b/content/en/blog/_posts/2018-07-11-dynamic-kubelet-configuration.md @@ -18,7 +18,7 @@ Dynamic Kubelet configuration gives cluster administrators and service providers ## What is Dynamic Kubelet Configuration? -Kubernetes v1.10 made it possible to configure the Kubelet via a beta [config file](https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/) API. Kubernetes already provides the ConfigMap abstraction for storing arbitrary file data in the API server. +Kubernetes v1.10 made it possible to configure the Kubelet via a beta [config file](/docs/tasks/administer-cluster/kubelet-config-file/) API. Kubernetes already provides the ConfigMap abstraction for storing arbitrary file data in the API server. Dynamic Kubelet configuration extends the Node object so that a Node can refer to a ConfigMap that contains the same type of config file. When a Node is updated to refer to a new ConfigMap, the associated Kubelet will attempt to use the new configuration. @@ -45,4 +45,4 @@ See the following diagram for a high-level overview of a configuration update fo ## How can I learn more? -Please see the official tutorial at https://kubernetes.io/docs/tasks/administer-cluster/reconfigure-kubelet/, which contains more in-depth details on user workflow, how a configuration becomes "last-known-good," how the Kubelet "checkpoints" config, and possible failure modes. +Please see the official tutorial at /docs/tasks/administer-cluster/reconfigure-kubelet/, which contains more in-depth details on user workflow, how a configuration becomes "last-known-good," how the Kubelet "checkpoints" config, and possible failure modes. diff --git a/content/en/blog/_posts/2018-07-16-kubernetes-1-11-release-interview.md b/content/en/blog/_posts/2018-07-16-kubernetes-1-11-release-interview.md index 5bfd60c125..da146e6b6c 100644 --- a/content/en/blog/_posts/2018-07-16-kubernetes-1-11-release-interview.md +++ b/content/en/blog/_posts/2018-07-16-kubernetes-1-11-release-interview.md @@ -94,7 +94,7 @@ JOSH BERKUS: That goes into release notes. I mean, keep in mind that one of the However, stuff happens, and we do occasionally have to do those. And so far, our main way to identify that to people actually is in the release notes. If you look at [the current release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md#no-really-you-must-do-this-before-you-upgrade), there are actually two things in there right now that are sort of breaking changes. -One of them is the bit with [priority and preemption](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/) in that preemption being on by default now allows badly behaved users of the system to cause trouble in new ways. I'd actually have to look at the release notes to see what the second one was... +One of them is the bit with [priority and preemption](/docs/concepts/configuration/pod-priority-preemption/) in that preemption being on by default now allows badly behaved users of the system to cause trouble in new ways. I'd actually have to look at the release notes to see what the second one was... TIM PEPPER: The [JSON capitalization case sensitivity](https://github.com/kubernetes/kubernetes/issues/64612). diff --git a/content/en/blog/_posts/2018-07-18-11-ways-not-to-get-hacked.md b/content/en/blog/_posts/2018-07-18-11-ways-not-to-get-hacked.md index 36e12c87fe..61b5472e4a 100644 --- a/content/en/blog/_posts/2018-07-18-11-ways-not-to-get-hacked.md +++ b/content/en/blog/_posts/2018-07-18-11-ways-not-to-get-hacked.md @@ -34,7 +34,7 @@ The control plane is Kubernetes' brain. It has an overall view of every cont > Note that some components and installation methods may enable local ports over HTTP and administrators should familiarize themselves with the settings of each component to identify potentially unsecured traffic. -[Source](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/#use-transport-level-security-tls-for-all-api-traffic) +[Source](/docs/tasks/administer-cluster/securing-a-cluster/#use-transport-level-security-tls-for-all-api-traffic) This network diagram by [Lucas Käldström](https://docs.google.com/presentation/d/1Gp-2blk5WExI_QR59EUZdwfO2BWLJqa626mK2ej-huo/edit#slide=id.g1e639c415b_0_56) demonstrates some of the places TLS should ideally be applied: between every component on the master, and between the Kubelet and API server. [Kelsey Hightower](https://twitter.com/kelseyhightower/)'s canonical [Kubernetes The Hard Way](https://github.com/kelseyhightower/kubernetes-the-hard-way/blob/1.9.0/docs/04-certificate-authority.md) provides detailed manual instructions, as does [etcd's security model](https://coreos.com/etcd/docs/latest/op-guide/security.html) documentation. @@ -62,11 +62,11 @@ Or use this flag to disable it in GKE: --no-enable-legacy-authorization ``` -There are plenty of [good examples](https://docs.bitnami.com/kubernetes/how-to/configure-rbac-in-your-kubernetes-cluster/) of [RBAC policies for cluster services](https://github.com/uruddarraju/kubernetes-rbac-policies), as well as [the docs](https://kubernetes.io/docs/admin/authorization/rbac/#role-binding-examples). And it doesn't have to stop there - fine-grained RBAC policies can be extracted from audit logs with [audit2rbac](https://github.com/liggitt/audit2rbac). +There are plenty of [good examples](https://docs.bitnami.com/kubernetes/how-to/configure-rbac-in-your-kubernetes-cluster/) of [RBAC policies for cluster services](https://github.com/uruddarraju/kubernetes-rbac-policies), as well as [the docs](/docs/admin/authorization/rbac/#role-binding-examples). And it doesn't have to stop there - fine-grained RBAC policies can be extracted from audit logs with [audit2rbac](https://github.com/liggitt/audit2rbac). Incorrect or excessively permissive RBAC policies are a security threat in case of a compromised pod. Maintaining least privilege, and continuously reviewing and improving RBAC rules, should be considered part of the "technical debt hygiene" that teams build into their development lifecycle. -[Audit Logging](https://kubernetes.io/docs/tasks/debug-application-cluster/audit/) (beta in 1.10) provides customisable API logging at the payload (e.g. request and response), and also metadata levels. Log levels can be tuned to your organisation's security policy - [GKE](https://cloud.google.com/kubernetes-engine/docs/how-to/audit-logging#audit_policy) provides sane defaults to get you started. +[Audit Logging](/docs/tasks/debug-application-cluster/audit/) (beta in 1.10) provides customisable API logging at the payload (e.g. request and response), and also metadata levels. Log levels can be tuned to your organisation's security policy - [GKE](https://cloud.google.com/kubernetes-engine/docs/how-to/audit-logging#audit_policy) provides sane defaults to get you started. For read requests such as get, list, and watch, only the request object is saved in the audit logs; the response object is not. For requests involving sensitive data such as Secret and ConfigMap, only the metadata is exported. For all other requests, both request and response objects are saved in audit logs. @@ -94,9 +94,9 @@ etcd should be configured with [peer and client TLS certificates](https://github **A security best practice is to regularly rotate encryption keys and certificates, in order to limit the "blast radius" of a key compromise.** -Kubernetes will [rotate some certificates automatically](https://kubernetes.io/docs/tasks/tls/certificate-rotation/) (notably, the kubelet client and server certs) by creating new CSRs as its existing credentials expire. +Kubernetes will [rotate some certificates automatically](/docs/tasks/tls/certificate-rotation/) (notably, the kubelet client and server certs) by creating new CSRs as its existing credentials expire. -However, the [symmetric encryption keys](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) that the API server uses to encrypt etcd values are not automatically rotated - they must be [rotated manually](https://www.twistlock.com/2017/08/02/kubernetes-secrets-encryption/). Master access is required to do this, so managed services (such as GKE or AKS) abstract this problem from an operator. +However, the [symmetric encryption keys](/docs/tasks/administer-cluster/encrypt-data/) that the API server uses to encrypt etcd values are not automatically rotated - they must be [rotated manually](https://www.twistlock.com/2017/08/02/kubernetes-secrets-encryption/). Master access is required to do this, so managed services (such as GKE or AKS) abstract this problem from an operator. # Part Two: Workloads @@ -109,7 +109,7 @@ With minimum viable security on the control plane the cluster is able to operate Tools like [bane](https://github.com/genuinetools/bane) can help to generate AppArmor profiles, and [docker-slim](https://github.com/docker-slim/docker-slim#quick-seccomp-example) for seccomp profiles, but beware - a comprehensive test suite it required to exercise all code paths in your application when verifying the side effects of applying these policies. -[PodSecurityPolicies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) can be used to mandate the use of security extensions and other Kubernetes security directives. They provide a minimum contract that a pod must fulfil to be submitted to the API server - including security profiles, the privileged flag, and the sharing of host network, process, or IPC namespaces. +[PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/) can be used to mandate the use of security extensions and other Kubernetes security directives. They provide a minimum contract that a pod must fulfil to be submitted to the API server - including security profiles, the privileged flag, and the sharing of host network, process, or IPC namespaces. These directives are important, as they help to prevent containerised processes from escaping their isolation boundaries, and [Tim Allclair](https://twitter.com/tallclair)'s [example PodSecurityPolicy](https://gist.github.com/tallclair/11981031b6bfa829bb1fb9dcb7e026b0) is a comprehensive resource that you can customise to your use case. @@ -135,7 +135,7 @@ Static analysis of YAML configuration can be used to establish a baseline for ru }, { "selector": "containers[] .securityContext .capabilities .drop", "reason": "Reducing kernel capabilities available to a container limits its attack surface", - "href": "https://kubernetes.io/docs/tasks/configure-pod-container/security-context/" + "href": "/docs/tasks/configure-pod-container/security-context/" }] } } @@ -197,7 +197,7 @@ Having to run workloads as a non-root user is not going to change until user nam ## 9. Use Network Policies -**By default, Kubernetes networking allows all pod to pod traffic; this can be restricted using a** [**Network Policy**](https://kubernetes.io/docs/concepts/services-networking/network-policies/) **.** +**By default, Kubernetes networking allows all pod to pod traffic; this can be restricted using a** [**Network Policy**](/docs/concepts/services-networking/network-policies/) **.** @@ -263,7 +263,7 @@ Cloud provider metadata APIs are a constant source of escalation (as the recent **Web servers present an attack surface to the network they're attached to: scanning an image's installed files ensures the absence of known vulnerabilities that an attacker could exploit to gain remote access to the container. An IDS (Intrusion Detection System) detects them if they do.** -Kubernetes permits pods into the cluster through a series of [admission controller](https://kubernetes.io/docs/admin/admission-controllers/) gates, which are applied to pods and other resources like deployments. These gates can validate each pod for admission or change its contents, and they now support backend webhooks. +Kubernetes permits pods into the cluster through a series of [admission controller](/docs/admin/admission-controllers/) gates, which are applied to pods and other resources like deployments. These gates can validate each pod for admission or change its contents, and they now support backend webhooks. diff --git a/content/en/blog/_posts/2018-07-24-cpu-manager.md b/content/en/blog/_posts/2018-07-24-cpu-manager.md index a50fcc4132..c777245565 100644 --- a/content/en/blog/_posts/2018-07-24-cpu-manager.md +++ b/content/en/blog/_posts/2018-07-24-cpu-manager.md @@ -6,13 +6,13 @@ date: 2018-07-24 **Authors**: Balaji Subramaniam ([Intel](mailto:balaji.subramaniam@intel.com)), Connor Doyle ([Intel](mailto:connor.p.doyle@intel.com)) -This blog post describes the [CPU Manager](https://kubernetes.io/docs/tasks/administer-cluster/cpu-management-policies/), a beta feature in [Kubernetes](https://kubernetes.io/). The CPU manager feature enables better placement of workloads in the [Kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/), the Kubernetes node agent, by allocating exclusive CPUs to certain pod containers. +This blog post describes the [CPU Manager](/docs/tasks/administer-cluster/cpu-management-policies/), a beta feature in [Kubernetes](https://kubernetes.io/). The CPU manager feature enables better placement of workloads in the [Kubelet](/docs/reference/command-line-tools-reference/kubelet/), the Kubernetes node agent, by allocating exclusive CPUs to certain pod containers. ![cpu manager](/images/blog/2018-07-24-cpu-manager/cpu-manager.png) ## Sounds Good! But Does the CPU Manager Help Me? -It depends on your workload. A single compute node in a Kubernetes cluster can run many [pods](https://kubernetes.io/docs/concepts/workloads/pods/pod/) and some of these pods could be running CPU-intensive workloads. In such a scenario, the pods might contend for the CPU resources available in that compute node. When this contention intensifies, the workload can move to different CPUs depending on whether the pod is throttled and the availability of CPUs at scheduling time. There might also be cases where the workload could be sensitive to context switches. In all the above scenarios, the performance of the workload might be affected. +It depends on your workload. A single compute node in a Kubernetes cluster can run many [pods](/docs/concepts/workloads/pods/pod/) and some of these pods could be running CPU-intensive workloads. In such a scenario, the pods might contend for the CPU resources available in that compute node. When this contention intensifies, the workload can move to different CPUs depending on whether the pod is throttled and the availability of CPUs at scheduling time. There might also be cases where the workload could be sensitive to context switches. In all the above scenarios, the performance of the workload might be affected. If your workload is sensitive to such scenarios, then CPU Manager can be enabled to provide better performance isolation by allocating exclusive CPUs for your workload. @@ -27,7 +27,7 @@ CPU manager might help workloads with the following characteristics: ## Ok! How Do I use it? -Using the CPU manager is simple. First, [enable CPU manager with the Static policy](https://kubernetes.io/docs/tasks/administer-cluster/cpu-management-policies/#cpu-management-policies) in the Kubelet running on the compute nodes of your cluster. Then configure your pod to be in the [Guaranteed Quality of Service (QoS) class](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/#create-a-pod-that-gets-assigned-a-qos-class-of-guaranteed). Request whole numbers of CPU cores (e.g., `1000m`, `4000m`) for containers that need exclusive cores. Create your pod in the same way as before (e.g., `kubectl create -f pod.yaml`). And _voilà_, the CPU manager will assign exclusive CPUs to each of container in the pod according to their CPU requests. +Using the CPU manager is simple. First, [enable CPU manager with the Static policy](/docs/tasks/administer-cluster/cpu-management-policies/#cpu-management-policies) in the Kubelet running on the compute nodes of your cluster. Then configure your pod to be in the [Guaranteed Quality of Service (QoS) class](/docs/tasks/configure-pod-container/quality-service-pod/#create-a-pod-that-gets-assigned-a-qos-class-of-guaranteed). Request whole numbers of CPU cores (e.g., `1000m`, `4000m`) for containers that need exclusive cores. Create your pod in the same way as before (e.g., `kubectl create -f pod.yaml`). And _voilà_, the CPU manager will assign exclusive CPUs to each of container in the pod according to their CPU requests. ``` apiVersion: v1 @@ -54,7 +54,7 @@ _Pod specification requesting two exclusive CPUs._ For Kubernetes, and the purposes of this blog post, we will discuss three kinds of CPU resource controls available in most Linux distributions. The first two are CFS shares (what's my weighted fair share of CPU time on this system) and CFS quota (what's my hard cap of CPU time over a period). The CPU manager uses a third control called CPU affinity (on what logical CPUs am I allowed to execute). -By default, all the pods and the containers running on a compute node of your Kubernetes cluster can execute on any available cores in the system. The total amount of allocatable shares and quota are limited by the CPU resources explicitly [reserved for kubernetes and system daemons](https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/). However, limits on the CPU time being used can be specified using [CPU limits in the pod spec](https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource/#specify-a-cpu-request-and-a-cpu-limit). Kubernetes uses [CFS quota](https://www.kernel.org/doc/Documentation/scheduler/sched-bwc.txt) to enforce CPU limits on pod containers. +By default, all the pods and the containers running on a compute node of your Kubernetes cluster can execute on any available cores in the system. The total amount of allocatable shares and quota are limited by the CPU resources explicitly [reserved for kubernetes and system daemons](/docs/tasks/administer-cluster/reserve-compute-resources/). However, limits on the CPU time being used can be specified using [CPU limits in the pod spec](/docs/tasks/configure-pod-container/assign-cpu-resource/#specify-a-cpu-request-and-a-cpu-limit). Kubernetes uses [CFS quota](https://www.kernel.org/doc/Documentation/scheduler/sched-bwc.txt) to enforce CPU limits on pod containers. When CPU manager is enabled with the "static" policy, it manages a shared pool of CPUs. Initially this shared pool contains all the CPUs in the compute node. When a container with integer CPU request in a Guaranteed pod is created by the Kubelet, CPUs for that container are removed from the shared pool and assigned exclusively for the lifetime of the container. Other containers are migrated off these exclusively allocated CPUs. diff --git a/content/en/blog/_posts/2018-07-27-kubevirt-crds-for-virtualization.md b/content/en/blog/_posts/2018-07-27-kubevirt-crds-for-virtualization.md index b6ea48288c..5f953e4a1e 100644 --- a/content/en/blog/_posts/2018-07-27-kubevirt-crds-for-virtualization.md +++ b/content/en/blog/_posts/2018-07-27-kubevirt-crds-for-virtualization.md @@ -8,7 +8,7 @@ date: 2018-07-27 ## What is KubeVirt? -[KubeVirt](https://github.com/kubevirt/kubevirt) is a Kubernetes addon that provides users the ability to schedule traditional virtual machine workloads side by side with container workloads. Through the use of [Custom Resource Definitions](https://Kubernetes.io/docs/concepts/extend-Kubernetes/api-extension/custom-resources/) (CRDs) and other Kubernetes features, KubeVirt seamlessly extends existing Kubernetes clusters to provide a set of virtualization APIs that can be used to manage virtual machines. +[KubeVirt](https://github.com/kubevirt/kubevirt) is a Kubernetes addon that provides users the ability to schedule traditional virtual machine workloads side by side with container workloads. Through the use of [Custom Resource Definitions](/docs/concepts/extend-Kubernetes/api-extension/custom-resources/) (CRDs) and other Kubernetes features, KubeVirt seamlessly extends existing Kubernetes clusters to provide a set of virtualization APIs that can be used to manage virtual machines. ## Why Use CRDs Over an Aggregated API Server? @@ -44,7 +44,7 @@ One of the responsibilities of the Kubernetes API server is to intercept and val This validation occurs during a process called admission control. Until recently, it was not possible to extend the default Kubernetes admission controllers without altering code and compiling/deploying an entirely new Kubernetes API server. This meant that if we wanted to perform admission control on KubeVirt’s CRD objects while they are posted to the cluster, we’d have to build our own version of the Kubernetes API server and convince our users to use that instead. That was not a viable solution for us. -Using the new [Dynamic Admission Control](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) feature that first landed in Kubernetes 1.9, we now have a path for performing custom validation on KubeVirt API through the use of a [ValidatingAdmissionWebhook](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#external-admission-webhooks). This feature allows KubeVirt to dynamically register an HTTPS webhook with Kubernetes at KubeVirt install time. After registering the custom webhook, all requests related to KubeVirt API objects are forwarded from the Kubernetes API server to our HTTPS endpoint for validation. If our endpoint rejects a request for any reason, the object will not be persisted into etcd and the client receives our response outlining the reason for the rejection. +Using the new [Dynamic Admission Control](/docs/reference/access-authn-authz/extensible-admission-controllers/) feature that first landed in Kubernetes 1.9, we now have a path for performing custom validation on KubeVirt API through the use of a [ValidatingAdmissionWebhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#external-admission-webhooks). This feature allows KubeVirt to dynamically register an HTTPS webhook with Kubernetes at KubeVirt install time. After registering the custom webhook, all requests related to KubeVirt API objects are forwarded from the Kubernetes API server to our HTTPS endpoint for validation. If our endpoint rejects a request for any reason, the object will not be persisted into etcd and the client receives our response outlining the reason for the rejection. For example, if someone posts a malformed VirtualMachine object, they’ll receive an error indicating what the problem is. @@ -57,7 +57,7 @@ In the example output above, that error response is coming directly from KubeVir ## CRD OpenAPIv3 Validation -In addition to the validating webhook, KubeVirt also uses the ability to provide an [OpenAPIv3 validation schema](https://kubernetes.io/docs/tasks/access-kubernetes-API/extend-api-custom-resource-definitions/#advanced-topics) when registering a CRD with the cluster. While the OpenAPIv3 schema does not let us express some of the more advanced validation checks that the validation webhook provides, it does offer the ability to enforce simple validation checks involving things like required fields, max/min value lengths, and verifying that values are formatted in a way that matches a regular expression string. +In addition to the validating webhook, KubeVirt also uses the ability to provide an [OpenAPIv3 validation schema](/docs/tasks/access-kubernetes-API/extend-api-custom-resource-definitions/#advanced-topics) when registering a CRD with the cluster. While the OpenAPIv3 schema does not let us express some of the more advanced validation checks that the validation webhook provides, it does offer the ability to enforce simple validation checks involving things like required fields, max/min value lengths, and verifying that values are formatted in a way that matches a regular expression string. ## Dynamic Webhooks for “PodPreset Like” Behavior @@ -93,7 +93,7 @@ One thing worth noting is that in Kubernetes 1.10 a very basic form of CRD subre ## CRD Finalizers -A [CRD finalizer](https://kubernetes.io/docs/tasks/access-kubernetes-API/extend-api-custom-resource-definitions/#advanced-topics) is a feature that lets us provide a pre-delete hook in order to perform actions before allowing a CRD object to be removed from persistent storage. In KubeVirt, we use finalizers to guarantee a virtual machine has completely terminated before we allow the corresponding VMI object to be removed from etcd. +A [CRD finalizer](/docs/tasks/access-kubernetes-API/extend-api-custom-resource-definitions/#advanced-topics) is a feature that lets us provide a pre-delete hook in order to perform actions before allowing a CRD object to be removed from persistent storage. In KubeVirt, we use finalizers to guarantee a virtual machine has completely terminated before we allow the corresponding VMI object to be removed from etcd. ## API Versioning for CRDs @@ -104,4 +104,3 @@ Prior to Kubernetes 1.11, CRDs did not have support for multiple versions. This That strategy was not exactly a viable option for us. Fortunately thanks to some recent [work to rectify this issue in Kubernetes](https://github.com/kubernetes/features/issues/544), the latest Kubernetes v1.11 now supports [CRDs with multiple versions](https://github.com/kubernetes/kubernetes/pull/63830). Note however that this initial multi version support is limited. While a CRD can now have multiple versions, the feature does not currently contain a path for performing conversions between versions. In KubeVirt, the lack of conversion makes it difficult us to evolve our API as we progress versions. Luckily, support for conversions between versions is underway and we look forward to taking advantage of that feature once it lands in a future Kubernetes release. - diff --git a/content/en/blog/_posts/2018-08-03-make-kubernetes-production-grade-anywhere.md b/content/en/blog/_posts/2018-08-03-make-kubernetes-production-grade-anywhere.md index 3d99195437..024506a2de 100644 --- a/content/en/blog/_posts/2018-08-03-make-kubernetes-production-grade-anywhere.md +++ b/content/en/blog/_posts/2018-08-03-make-kubernetes-production-grade-anywhere.md @@ -48,7 +48,7 @@ Risks to these components include hardware failures, software bugs, bad updates, The API Server uses multiple instances behind a load balancer to achieve scale and availability. The load balancer is a critical component for purposes of high availability. Multiple DNS API Server ‘A’ records might be an alternative if you don’t have a load balancer. -The kube-scheduler and kube-controller-manager engage in a leader election process, rather than utilizing a load balancer. Since a [cloud-controller-manager](https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/) is used for selected types of hosting infrastructure, and these have implementation variations, they will not be discussed, beyond indicating that they are a control plane component. +The kube-scheduler and kube-controller-manager engage in a leader election process, rather than utilizing a load balancer. Since a [cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) is used for selected types of hosting infrastructure, and these have implementation variations, they will not be discussed, beyond indicating that they are a control plane component. Pods running on Kubernetes worker nodes are managed by the kubelet agent. Each worker instance runs the kubelet agent and a [CRI-compatible](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/) container runtime. Kubernetes itself is designed to monitor and recover from worker node outages. But for critical workloads, hypervisor resource management, workload isolation and availability features can be used to enhance availability and make performance more predictable. @@ -102,15 +102,15 @@ Running a hypervisor layer offers operational advantages and better workload iso ## Kubernetes configuration settings Master and Worker nodes should be protected from overload and resource exhaustion. Hypervisor features can be used to isolate critical components and reserve resources. There are also Kubernetes configuration settings that can throttle things like API call rates and pods per node. Some install suites and commercial distributions take care of this, but if you are performing a custom Kubernetes deployment, you may find that the defaults are not appropriate, particularly if your resources are small or your cluster is large. -Resource consumption by the control plane will correlate with the number of pods and the pod churn rate. Very large and very small clusters will benefit from non-default [settings](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/) of kube-apiserver request throttling and memory. Having these too high can lead to request limit exceeded and out of memory errors. +Resource consumption by the control plane will correlate with the number of pods and the pod churn rate. Very large and very small clusters will benefit from non-default [settings](/docs/reference/command-line-tools-reference/kube-apiserver/) of kube-apiserver request throttling and memory. Having these too high can lead to request limit exceeded and out of memory errors. -On worker nodes, [Node Allocatable](https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/) should be configured based on a reasonable supportable workload density at each node. Namespaces can be created to subdivide the worker node cluster into multiple virtual clusters with resource CPU and memory [quotas](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/). Kubelet handling of [out of resource](https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/) conditions can be configured. +On worker nodes, [Node Allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/) should be configured based on a reasonable supportable workload density at each node. Namespaces can be created to subdivide the worker node cluster into multiple virtual clusters with resource CPU and memory [quotas](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/). Kubelet handling of [out of resource](/docs/tasks/administer-cluster/out-of-resource/) conditions can be configured. ## Security Every Kubernetes cluster has a cluster root Certificate Authority (CA). The Controller Manager, API Server, Scheduler, kubelet client, kube-proxy and administrator certificates need to be generated and installed. If you use an install tool or a distribution this may be handled for you. A manual process is described [here](https://github.com/kelseyhightower/kubernetes-the-hard-way/blob/master/docs/04-certificate-authority.md). You should be prepared to reinstall certificates in the event of node replacements or expansions. -As Kubernetes is entirely API driven, controlling and limiting who can access the cluster and what actions they are allowed to perform is essential. Encryption and authentication options are addressed in this [documentation](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/). +As Kubernetes is entirely API driven, controlling and limiting who can access the cluster and what actions they are allowed to perform is essential. Encryption and authentication options are addressed in this [documentation](/docs/tasks/administer-cluster/securing-a-cluster/). Kubernetes application workloads are based on container images. You want the source and content of these images to be trustworthy. This will almost always mean that you will host a local container image repository. Pulling images from the public Internet can present both reliability and security issues. You should choose a repository that supports image signing, security scanning, access controls on pushing and pulling images, and logging of activity. @@ -119,13 +119,13 @@ Processes must be in place to support applying updates for host firmware, hyperv Recommendations: * Tighten security settings on the control plane components beyond defaults (e.g., [locking down worker nodes](http://blog.kontena.io/locking-down-kubernetes-workers/)) -* Utilize [Pod Security Policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) -* Consider the [NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/) integration available with your networking solution, including how you will accomplish tracing, monitoring and troubleshooting. +* Utilize [Pod Security Policies](/docs/concepts/policy/pod-security-policy/) +* Consider the [NetworkPolicy](/docs/concepts/services-networking/network-policies/) integration available with your networking solution, including how you will accomplish tracing, monitoring and troubleshooting. * Use RBAC to drive authorization decisions and enforcement. * Consider physical security, especially when deploying to edge or remote office locations that may be unattended. Include storage encryption to limit exposure from stolen devices and protection from attachment of malicious devices like USB keys. * Protect Kubernetes plain-text cloud provider credentials (access keys, tokens, passwords, etc.) -Kubernetes [secret](https://kubernetes.io/docs/concepts/configuration/secret/) objects are appropriate for holding small amounts of sensitive data. These are retained within etcd. These can be readily used to hold credentials for the Kubernetes API but there are times when a workload or an extension of the cluster itself needs a more full-featured solution. The HashiCorp Vault project is a popular solution if you need more than the built-in secret objects can provide. +Kubernetes [secret](/docs/concepts/configuration/secret/) objects are appropriate for holding small amounts of sensitive data. These are retained within etcd. These can be readily used to hold credentials for the Kubernetes API but there are times when a workload or an extension of the cluster itself needs a more full-featured solution. The HashiCorp Vault project is a popular solution if you need more than the built-in secret objects can provide. ## Disaster Recovery and Backup @@ -166,7 +166,7 @@ Some critical state is held outside etcd. Certificates, container images, and ot * Cloud provider specific account and configuration data ## Considerations for your production workloads -Anti-affinity specifications can be used to split clustered services across backing hosts, but at this time the settings are used only when the pod is scheduled. This means that Kubernetes can restart a failed node of your clustered application, but does not have a native mechanism to rebalance after a fail back. This is a topic worthy of a separate blog, but supplemental logic might be useful to achieve optimal workload placements after host or worker node recoveries or expansions. The [Pod Priority and Preemption feature](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/) can be used to specify a preferred triage in the event of resource shortages caused by failures or bursting workloads. +Anti-affinity specifications can be used to split clustered services across backing hosts, but at this time the settings are used only when the pod is scheduled. This means that Kubernetes can restart a failed node of your clustered application, but does not have a native mechanism to rebalance after a fail back. This is a topic worthy of a separate blog, but supplemental logic might be useful to achieve optimal workload placements after host or worker node recoveries or expansions. The [Pod Priority and Preemption feature](/docs/concepts/configuration/pod-priority-preemption/) can be used to specify a preferred triage in the event of resource shortages caused by failures or bursting workloads. For stateful services, external attached volume mounts are the standard Kubernetes recommendation for a non-clustered service (e.g., a typical SQL database). At this time Kubernetes managed snapshots of these external volumes is in the category of a [roadmap feature request](https://docs.google.com/presentation/d/1dgxfnroRAu0aF67s-_bmeWpkM1h2LCxe6lB1l1oS0EQ/edit#slide=id.g3ca07c98c2_0_47), likely to align with the Container Storage Interface (CSI) integration. Thus performing backups of such a service would involve application specific, in-pod activity that is beyond the scope of this document. While awaiting better Kubernetes support for a snapshot and backup workflow, running your database service in a VM rather than a container, and exposing it to your Kubernetes workload may be worth considering. @@ -174,9 +174,9 @@ Cluster-distributed stateful services (e.g., Cassandra) can benefit from splitti ## Other considerations -[Logs](https://kubernetes.io/docs/concepts/cluster-administration/logging/) and [metrics](https://kubernetes.io/docs/tasks/debug-application-cluster/resource-usage-monitoring/) (if collected and persistently retained) are valuable to diagnose outages, but given the variety of technologies available it will not be addressed in this blog. If Internet connectivity is available, it may be desirable to retain logs and metrics externally at a central location. +[Logs](/docs/concepts/cluster-administration/logging/) and [metrics](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) (if collected and persistently retained) are valuable to diagnose outages, but given the variety of technologies available it will not be addressed in this blog. If Internet connectivity is available, it may be desirable to retain logs and metrics externally at a central location. -Your production deployment should utilize an automated installation, configuration and update tool (e.g., [Ansible](https://github.com/kubernetes-incubator/kubespray), [BOSH](https://github.com/cloudfoundry-incubator/kubo-deployment), [Chef](https://github.com/chef-cookbooks/kubernetes), [Juju](https://kubernetes.io/docs/getting-started-guides/ubuntu/installation/), [kubeadm](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/), [Puppet](https://forge.puppet.com/puppetlabs/kubernetes), etc.). A manual process will have repeatability issues, be labor intensive, error prone, and difficult to scale. [Certified distributions](https://www.cncf.io/certification/software-conformance/#logos) are likely to include a facility for retaining configuration settings across updates, but if you implement your own install and config toolchain, then retention, backup and recovery of the configuration artifacts is essential. Consider keeping your deployment components and settings under a version control system such as Git. +Your production deployment should utilize an automated installation, configuration and update tool (e.g., [Ansible](https://github.com/kubernetes-incubator/kubespray), [BOSH](https://github.com/cloudfoundry-incubator/kubo-deployment), [Chef](https://github.com/chef-cookbooks/kubernetes), [Juju](/docs/getting-started-guides/ubuntu/installation/), [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), [Puppet](https://forge.puppet.com/puppetlabs/kubernetes), etc.). A manual process will have repeatability issues, be labor intensive, error prone, and difficult to scale. [Certified distributions](https://www.cncf.io/certification/software-conformance/#logos) are likely to include a facility for retaining configuration settings across updates, but if you implement your own install and config toolchain, then retention, backup and recovery of the configuration artifacts is essential. Consider keeping your deployment components and settings under a version control system such as Git. ## Outage recovery diff --git a/content/en/blog/_posts/2018-09-27-kubernetes-1-12-release-announcement.md b/content/en/blog/_posts/2018-09-27-kubernetes-1-12-release-announcement.md index d1e9508bf9..b24a6cbe09 100644 --- a/content/en/blog/_posts/2018-09-27-kubernetes-1-12-release-announcement.md +++ b/content/en/blog/_posts/2018-09-27-kubernetes-1-12-release-announcement.md @@ -52,7 +52,7 @@ Improvements that will allow the [Horizontal Pod Autoscaler to reach proper size ## Availability -Kubernetes 1.12 is available for [download on GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.12.0). To get started with Kubernetes, check out these [interactive tutorials](https://kubernetes.io/docs/tutorials/). You can also install 1.12 using [Kubeadm](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/). +Kubernetes 1.12 is available for [download on GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.12.0). To get started with Kubernetes, check out these [interactive tutorials](/docs/tutorials/). You can also install 1.12 using [Kubeadm](/docs/setup/independent/create-cluster-kubeadm/). ## 5 Day Features Blog Series diff --git a/content/en/blog/_posts/2018-10-01-health-checking-grpc.md b/content/en/blog/_posts/2018-10-01-health-checking-grpc.md index b1f3cd6ed0..21eb668dc2 100644 --- a/content/en/blog/_posts/2018-10-01-health-checking-grpc.md +++ b/content/en/blog/_posts/2018-10-01-health-checking-grpc.md @@ -93,5 +93,5 @@ feedback](https://github.com/grpc-ecosystem/grpc-health-probe/). ## Further reading - Protocol: [GRPC Health Checking Protocol](https://github.com/grpc/grpc/blob/v1.15.0/doc/health-checking.md) ([health.proto](https://github.com/grpc/grpc/blob/v1.15.0/src/proto/grpc/health/v1/health.proto)) -- Documentation: [Kubernetes liveness and readiness probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) +- Documentation: [Kubernetes liveness and readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) - Article: [Advanced Kubernetes Health Check Patterns](https://ahmet.im/blog/advanced-kubernetes-health-checks/) diff --git a/content/en/blog/_posts/2018-10-08-support-for-azure-vmss.md b/content/en/blog/_posts/2018-10-08-support-for-azure-vmss.md index 64bae6d87b..fa2d75c49f 100644 --- a/content/en/blog/_posts/2018-10-08-support-for-azure-vmss.md +++ b/content/en/blog/_posts/2018-10-08-support-for-azure-vmss.md @@ -52,7 +52,7 @@ Kubernetes clusters are built on top of disks created in Azure. In a typical con ![](/images/blog/2018-10-08-support-for-azure-vmss/cloud-provider-components.png) -Kubernetes cloud provider interface provides interactions with clouds for managing cloud-specific resources, e.g. public IPs and routes. A good overview of these components is given in [[2]](https://kubernetes.io/docs/concepts/architecture/cloud-controller/). In case of Azure Kubernetes cluster, the Kubernetes interactions go through the Azure cloud provider layer and contact the various services running in the cloud. +Kubernetes cloud provider interface provides interactions with clouds for managing cloud-specific resources, e.g. public IPs and routes. A good overview of these components is given in [[2]](/docs/concepts/architecture/cloud-controller/). In case of Azure Kubernetes cluster, the Kubernetes interactions go through the Azure cloud provider layer and contact the various services running in the cloud. The cloud provider implementation of K8s can be largely divided into the following component interfaces which we need to implement: @@ -142,7 +142,7 @@ In future there will be support for the following: ## Cluster Autoscaler -A Kubernetes cluster consists of nodes. These nodes can be virtual machines, bare metal servers or could be even virtual node (virtual kubelet). To avoid getting lost in permutations and combinations of Kubernetes ecosystem ;-), let's consider that the cluster we are discussing consists of virtual machines, which are hosted in a cloud (eg: Azure, Google or AWS). What this effectively means is that you have access to virtual machines which run Kubernetes agents and a master node which runs k8s services like API server. A detailed version of k8s architecture can be found here [[11]](https://kubernetes.io/docs/concepts/architecture/). +A Kubernetes cluster consists of nodes. These nodes can be virtual machines, bare metal servers or could be even virtual node (virtual kubelet). To avoid getting lost in permutations and combinations of Kubernetes ecosystem ;-), let's consider that the cluster we are discussing consists of virtual machines, which are hosted in a cloud (eg: Azure, Google or AWS). What this effectively means is that you have access to virtual machines which run Kubernetes agents and a master node which runs k8s services like API server. A detailed version of k8s architecture can be found here [[11]](/docs/concepts/architecture/). The number of nodes which are required on a cluster depends on the workload on the cluster. When the load goes up there is a need to increase the nodes and when it subsides, there is a need to reduce the nodes and clean up the resources which are no longer in use. One way this can be taken care of is to manually scale up the nodes which are part of the Kubernetes cluster and manually scale down when the demand reduces. But shouldn’t this be done automatically ? Answer to this question is the Cluster Autoscaler (CA). @@ -309,7 +309,7 @@ For the acs-engine (the unmanaged variety) on Azure docs can be found here: [[9] 1) https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/overview -2) https://kubernetes.io/docs/concepts/architecture/cloud-controller/ +2) /docs/concepts/architecture/cloud-controller/ 3) https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/azure/azure_vmss.go @@ -327,7 +327,7 @@ For the acs-engine (the unmanaged variety) on Azure docs can be found here: [[9] 10) https://github.com/kubernetes/client-go -11) https://kubernetes.io/docs/concepts/architecture/ +11) /docs/concepts/architecture/ 12) https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview diff --git a/content/en/blog/_posts/2018-10-09-volume-snapshot-alpha.md b/content/en/blog/_posts/2018-10-09-volume-snapshot-alpha.md index e8d4181ae0..d18fc11dcd 100644 --- a/content/en/blog/_posts/2018-10-09-volume-snapshot-alpha.md +++ b/content/en/blog/_posts/2018-10-09-volume-snapshot-alpha.md @@ -55,7 +55,7 @@ Similar to the API for managing Kubernetes Persistent Volumes, Kubernetes Volume * `VolumeSnapshotClass` * Created by cluster administrators to describe how snapshots should be created. including the driver information, the secrets to access the snapshot, etc. -It is important to note that unlike the core Kubernetes Persistent Volume objects, these Snapshot objects are defined as [CustomResourceDefinitions (CRDs)](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#customresourcedefinitions). The Kubernetes project is moving away from having resource types pre-defined in the API server, and is moving towards a model where the API server is independent of the API objects. This allows the API server to be reused for projects other than Kubernetes, and consumers (like Kubernetes) can simply install the resource types they require as CRDs. +It is important to note that unlike the core Kubernetes Persistent Volume objects, these Snapshot objects are defined as [CustomResourceDefinitions (CRDs)](/docs/concepts/extend-kubernetes/api-extension/custom-resources/#customresourcedefinitions). The Kubernetes project is moving away from having resource types pre-defined in the API server, and is moving towards a model where the API server is independent of the API objects. This allows the API server to be reused for projects other than Kubernetes, and consumers (like Kubernetes) can simply install the resource types they require as CRDs. [CSI Drivers](https://kubernetes-csi.github.io/docs/Drivers.html) that support snapshots will automatically install the required CRDs. Kubernetes end users only need to verify that a CSI driver that supports snapshots is deployed on their Kubernetes cluster. diff --git a/content/en/blog/_posts/2018-10-10-runtimeclass.md b/content/en/blog/_posts/2018-10-10-runtimeclass.md index 9899884299..d47ad9c9cb 100644 --- a/content/en/blog/_posts/2018-10-10-runtimeclass.md +++ b/content/en/blog/_posts/2018-10-10-runtimeclass.md @@ -27,7 +27,7 @@ Why is RuntimeClass a pod level concept? The Kubernetes resource model expects c ## What's next? -The RuntimeClass resource is an important foundation for surfacing runtime properties to the control plane. For example, to implement scheduler support for clusters with heterogeneous nodes supporting different runtimes, we might add [NodeAffinity](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity) terms to the RuntimeClass definition. Another area to address is managing the variable resource requirements to run pods of different runtimes. The [Pod Overhead proposal](https://docs.google.com/document/d/1EJKT4gyl58-kzt2bnwkv08MIUZ6lkDpXcxkHqCvvAp4/preview) was an early take on this that aligns nicely with the RuntimeClass design, and may be pursued further. +The RuntimeClass resource is an important foundation for surfacing runtime properties to the control plane. For example, to implement scheduler support for clusters with heterogeneous nodes supporting different runtimes, we might add [NodeAffinity](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity) terms to the RuntimeClass definition. Another area to address is managing the variable resource requirements to run pods of different runtimes. The [Pod Overhead proposal](https://docs.google.com/document/d/1EJKT4gyl58-kzt2bnwkv08MIUZ6lkDpXcxkHqCvvAp4/preview) was an early take on this that aligns nicely with the RuntimeClass design, and may be pursued further. Many other RuntimeClass extensions have also been proposed, and will be revisited as the feature continues to develop and mature. A few more extensions that are being considered include: @@ -41,7 +41,7 @@ RuntimeClass will be under active development at least through 2019, and we’re ## Learn More -- Take it for a spin! As an alpha feature, there are some additional setup steps to use RuntimeClass. Refer to the [RuntimeClass documentation](https://kubernetes.io/docs/concepts/containers/runtime-class/#runtime-class) for how to get it running. +- Take it for a spin! As an alpha feature, there are some additional setup steps to use RuntimeClass. Refer to the [RuntimeClass documentation](/docs/concepts/containers/runtime-class/#runtime-class) for how to get it running. - Check out the [RuntimeClass Kubernetes Enhancement Proposal](https://github.com/kubernetes/community/blob/master/keps/sig-node/0014-runtime-class.md) for more nitty-gritty design details. - The [Sandbox Isolation Level Decision](https://docs.google.com/document/d/1fe7lQUjYKR0cijRmSbH_y0_l3CYPkwtQa5ViywuNo8Q/preview) documents the thought process that initially went into making RuntimeClass a pod-level choice. - Join the discussions and help shape the future of RuntimeClass with the [SIG-Node community](https://github.com/kubernetes/community/tree/master/sig-node) diff --git a/content/en/blog/_posts/2018-10-11-topology-aware-volume-provisioning.md b/content/en/blog/_posts/2018-10-11-topology-aware-volume-provisioning.md index 6daecd1c5f..3494838cb6 100644 --- a/content/en/blog/_posts/2018-10-11-topology-aware-volume-provisioning.md +++ b/content/en/blog/_posts/2018-10-11-topology-aware-volume-provisioning.md @@ -140,7 +140,7 @@ logs-web-1 us-central1-a ## How can I learn more? Official documentation on the topology-aware dynamic provisioning feature is available here: -https://kubernetes.io/docs/concepts/storage/storage-classes/#volume-binding-mode +/docs/concepts/storage/storage-classes/#volume-binding-mode Documentation for CSI drivers is available at https://kubernetes-csi.github.io/docs/ diff --git a/content/en/blog/_posts/2018-11-07-grpc-load-balancing-with-linkerd.md.md b/content/en/blog/_posts/2018-11-07-grpc-load-balancing-with-linkerd.md.md index d56074cc3b..38515642c1 100644 --- a/content/en/blog/_posts/2018-11-07-grpc-load-balancing-with-linkerd.md.md +++ b/content/en/blog/_posts/2018-11-07-grpc-load-balancing-with-linkerd.md.md @@ -85,9 +85,9 @@ application would have to watch the Kubernetes API and keep itself up to date with the pods. Alternatively, in Kubernetes, we could deploy our app as [headless -services](https://kubernetes.io/docs/concepts/services-networking/service/#headless-services). +services](/docs/concepts/services-networking/service/#headless-services). In this case, Kubernetes [will create multiple A -records](https://kubernetes.io/docs/concepts/services-networking/service/#headless-services) +records](/docs/concepts/services-networking/service/#headless-services) in the DNS entry for the service. If our gRPC client is sufficiently advanced, it can automatically maintain the load balancing pool from those DNS entries. But this approach restricts us to certain gRPC clients, and it's rarely diff --git a/content/en/blog/_posts/2018-11-08-kubernetes-docs-update-i18n.md b/content/en/blog/_posts/2018-11-08-kubernetes-docs-update-i18n.md index 1cf40bd820..38fd24372c 100644 --- a/content/en/blog/_posts/2018-11-08-kubernetes-docs-update-i18n.md +++ b/content/en/blog/_posts/2018-11-08-kubernetes-docs-update-i18n.md @@ -51,7 +51,7 @@ We're looking forward to the [doc sprint in Shanghai](https://kccncchina2018engl We're excited to continue supporting the Japanese and Korean l10n teams, who are making excellent progress. -If you're interested in localizing Kubernetes for your own language or region, check out our [guide to localizing Kubernetes docs](https://kubernetes.io/docs/contribute/localization/) and reach out to a [SIG Docs chair](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) for support. +If you're interested in localizing Kubernetes for your own language or region, check out our [guide to localizing Kubernetes docs](/docs/contribute/localization/) and reach out to a [SIG Docs chair](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) for support. ### Get involved with SIG Docs diff --git a/content/en/blog/_posts/2018-12-03-kubernetes-1-13-release-announcement.md b/content/en/blog/_posts/2018-12-03-kubernetes-1-13-release-announcement.md index 90949f3b7c..c04b6c1633 100644 --- a/content/en/blog/_posts/2018-12-03-kubernetes-1-13-release-announcement.md +++ b/content/en/blog/_posts/2018-12-03-kubernetes-1-13-release-announcement.md @@ -17,7 +17,7 @@ Let’s dive into the key features of this release: ## Simplified Kubernetes Cluster Management with kubeadm in GA -Most people who have gotten hands-on with Kubernetes have at some point been hands-on with kubeadm. It's an essential tool for managing the cluster lifecycle, from creation to configuration to upgrade; and now kubeadm is officially GA. [kubeadm](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/) handles the bootstrapping of production clusters on existing hardware and configuring the core Kubernetes components in a best-practice-manner to providing a secure yet easy joining flow for new nodes and supporting easy upgrades. What’s notable about this GA release are the now graduated advanced features, specifically around pluggability and configurability. The scope of kubeadm is to be a toolbox for both admins and automated, higher-level system and this release is a significant step in that direction. +Most people who have gotten hands-on with Kubernetes have at some point been hands-on with kubeadm. It's an essential tool for managing the cluster lifecycle, from creation to configuration to upgrade; and now kubeadm is officially GA. [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) handles the bootstrapping of production clusters on existing hardware and configuring the core Kubernetes components in a best-practice-manner to providing a secure yet easy joining flow for new nodes and supporting easy upgrades. What’s notable about this GA release are the now graduated advanced features, specifically around pluggability and configurability. The scope of kubeadm is to be a toolbox for both admins and automated, higher-level system and this release is a significant step in that direction. ## Container Storage Interface (CSI) Goes GA @@ -49,7 +49,7 @@ Each Special Interest Group (SIG) within the community continues to deliver the ## Availability -Kubernetes 1.13 is available for [download on GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.13.0). To get started with Kubernetes, check out these [interactive tutorials](https://kubernetes.io/docs/tutorials/). You can also easily install 1.13 using [kubeadm](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/). +Kubernetes 1.13 is available for [download on GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.13.0). To get started with Kubernetes, check out these [interactive tutorials](/docs/tutorials/). You can also easily install 1.13 using [kubeadm](/docs/setup/independent/create-cluster-kubeadm/). ## Features Blog Series diff --git a/content/en/blog/_posts/2018-12-04-kubeadm-ga-release.md b/content/en/blog/_posts/2018-12-04-kubeadm-ga-release.md index c586eb916e..a88999a15d 100644 --- a/content/en/blog/_posts/2018-12-04-kubeadm-ga-release.md +++ b/content/en/blog/_posts/2018-12-04-kubeadm-ga-release.md @@ -6,7 +6,7 @@ date: 2018-12-04 **Authors**: Lucas Käldström (CNCF Ambassador) and Luc Perkins (CNCF Developer Advocate) -[kubeadm](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/) is a tool that enables Kubernetes administrators to quickly and easily bootstrap minimum viable clusters that are fully compliant with [Certified Kubernetes](https://github.com/cncf/k8s-conformance/blob/master/terms-conditions/Certified_Kubernetes_Terms.md) guidelines. It's been under active development by [SIG Cluster Lifecycle](https://github.com/kubernetes/community/tree/master/sig-cluster-lifecycle) since 2016 and we're excited to announce that it has now graduated from beta to stable and generally available (GA)! +[kubeadm](/docs/setup/independent/create-cluster-kubeadm/) is a tool that enables Kubernetes administrators to quickly and easily bootstrap minimum viable clusters that are fully compliant with [Certified Kubernetes](https://github.com/cncf/k8s-conformance/blob/master/terms-conditions/Certified_Kubernetes_Terms.md) guidelines. It's been under active development by [SIG Cluster Lifecycle](https://github.com/kubernetes/community/tree/master/sig-cluster-lifecycle) since 2016 and we're excited to announce that it has now graduated from beta to stable and generally available (GA)! This GA release of kubeadm is an important event in the progression of the Kubernetes ecosystem, bringing stability to an area where stability is paramount. @@ -14,7 +14,7 @@ The goal of kubeadm is to provide a foundational implementation for Kubernetes c ### The scope of kubeadm -kubeadm is focused on bootstrapping Kubernetes clusters on existing infrastructure and performing an essential set of maintenance tasks. The core of the kubeadm interface is quite simple: new control plane nodes are created by running [`kubeadm init`](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init/) and worker nodes are joined to the control plane by running [`kubeadm join`](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-join/). Also included are utilities for managing already bootstrapped clusters, such as control plane upgrades and token and certificate renewal. +kubeadm is focused on bootstrapping Kubernetes clusters on existing infrastructure and performing an essential set of maintenance tasks. The core of the kubeadm interface is quite simple: new control plane nodes are created by running [`kubeadm init`](/docs/reference/setup-tools/kubeadm/kubeadm-init/) and worker nodes are joined to the control plane by running [`kubeadm join`](/docs/reference/setup-tools/kubeadm/kubeadm-join/). Also included are utilities for managing already bootstrapped clusters, such as control plane upgrades and token and certificate renewal. To keep kubeadm lean, focused, and vendor/infrastructure agnostic, the following tasks are out of its scope: @@ -23,7 +23,7 @@ To keep kubeadm lean, focused, and vendor/infrastructure agnostic, the following - Non-critical add-ons, e.g. for monitoring, logging, and visualization - Specific cloud provider integrations -Infrastructure provisioning, for example, is left to other SIG Cluster Lifecycle projects, such as the [Cluster API](https://github.com/kubernetes-sigs/cluster-api). Instead, kubeadm covers only the common denominator in every Kubernetes cluster: the [control plane](https://kubernetes.io/docs/concepts/#kubernetes-control-plane). The user may install their preferred networking solution and other add-ons on top of Kubernetes *after* cluster creation. +Infrastructure provisioning, for example, is left to other SIG Cluster Lifecycle projects, such as the [Cluster API](https://github.com/kubernetes-sigs/cluster-api). Instead, kubeadm covers only the common denominator in every Kubernetes cluster: the [control plane](/docs/concepts/#kubernetes-control-plane). The user may install their preferred networking solution and other add-ons on top of Kubernetes *after* cluster creation. ### What kubeadm's GA release means @@ -31,11 +31,11 @@ General Availability means different things for different projects. For kubeadm, We now consider kubeadm to have achieved GA-level maturity in each of these important domains: - * **Stable command-line UX** --- The kubeadm CLI conforms to [#5a GA rule of the Kubernetes Deprecation Policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-a-flag-or-cli), which states that a command or flag that exists in a GA version must be kept for at least 12 months after deprecation. - * **Stable underlying implementation** --- kubeadm now creates a new Kubernetes cluster using methods that shouldn't change any time soon. The control plane, for example, is run as a set of static Pods, bootstrap tokens are used for the [`kubeadm join`](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-join/) flow, and [ComponentConfig](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cluster-lifecycle/0014-20180707-componentconfig-api-types-to-staging.md) is used for configuring the [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/). + * **Stable command-line UX** --- The kubeadm CLI conforms to [#5a GA rule of the Kubernetes Deprecation Policy](/docs/reference/using-api/deprecation-policy/#deprecating-a-flag-or-cli), which states that a command or flag that exists in a GA version must be kept for at least 12 months after deprecation. + * **Stable underlying implementation** --- kubeadm now creates a new Kubernetes cluster using methods that shouldn't change any time soon. The control plane, for example, is run as a set of static Pods, bootstrap tokens are used for the [`kubeadm join`](/docs/reference/setup-tools/kubeadm/kubeadm-join/) flow, and [ComponentConfig](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cluster-lifecycle/0014-20180707-componentconfig-api-types-to-staging.md) is used for configuring the [kubelet](/docs/reference/command-line-tools-reference/kubelet/). * **Configuration file schema** --- With the new **v1beta1** API version, you can now tune almost every part of the cluster declaratively and thus build a "GitOps" flow around kubeadm-built clusters. In future versions, we plan to graduate the API to version **v1** with minimal changes (and perhaps none). - * **The "toolbox" interface of kubeadm** --- Also known as **phases**. If you don't want to perform all [`kubeadm init`](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init/) tasks, you can instead apply more fine-grained actions using the `kubeadm init phase` command (for example generating certificates or control plane [Static Pod](https://kubernetes.io/docs/tasks/administer-cluster/static-pod/) manifests). - * **Upgrades between minor versions** --- The [`kubeadm upgrade`](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) command is now fully GA. It handles control plane upgrades for you, which includes upgrades to [etcd](https://etcd.io), the [API Server](https://kubernetes.io/docs/reference/using-api/api-overview/), the [Controller Manager](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/), and the [Scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/). You can seamlessly upgrade your cluster between minor or patch versions (e.g. v1.12.2 -> v1.13.1 or v1.13.1 -> v1.13.3). + * **The "toolbox" interface of kubeadm** --- Also known as **phases**. If you don't want to perform all [`kubeadm init`](/docs/reference/setup-tools/kubeadm/kubeadm-init/) tasks, you can instead apply more fine-grained actions using the `kubeadm init phase` command (for example generating certificates or control plane [Static Pod](/docs/tasks/administer-cluster/static-pod/) manifests). + * **Upgrades between minor versions** --- The [`kubeadm upgrade`](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) command is now fully GA. It handles control plane upgrades for you, which includes upgrades to [etcd](https://etcd.io), the [API Server](/docs/reference/using-api/api-overview/), the [Controller Manager](/docs/reference/command-line-tools-reference/kube-controller-manager/), and the [Scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/). You can seamlessly upgrade your cluster between minor or patch versions (e.g. v1.12.2 -> v1.13.1 or v1.13.1 -> v1.13.3). * **etcd setup** --- [etcd](https://etcd.io) is now set up in a way that is secure by default, with TLS communication everywhere, and allows for expanding to a highly available cluster when needed. ### Who will benefit from a stable kubeadm @@ -44,7 +44,7 @@ SIG Cluster Lifecycle has identified a handful of likely kubeadm user profiles, Here's our list: -- You're a **new user** who wants to take Kubernetes for a spin. kubeadm is the fastest way to get up and running on [Linux machines](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/). If you're using [Minikube](https://github.com/kubernetes/minikube) on a Mac or Windows workstation, you're actually already running kubeadm inside the Minikube VM! +- You're a **new user** who wants to take Kubernetes for a spin. kubeadm is the fastest way to get up and running on [Linux machines](/docs/setup/independent/create-cluster-kubeadm/). If you're using [Minikube](https://github.com/kubernetes/minikube) on a Mac or Windows workstation, you're actually already running kubeadm inside the Minikube VM! - You're a **system administrator** responsible for setting up Kubernetes on bare metal machines and you want to quickly create Kubernetes clusters that are secure and in conformance with best practices but also highly configurable. - You're a **cloud provider** who wants to add a Kubernetes offering to your suite of cloud services. kubeadm is the go-to tool for creating clusters at a low level. - You're an **organization that requires highly customized Kubernetes clusters**. Existing public cloud offerings like [Amazon EKS](https://aws.amazon.com/eks/) and [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) won't cut it for you; you need customized Kubernetes clusters tailored to your hardware, security, policy, and other needs. diff --git a/content/en/blog/_posts/2018-12-11-Kubernetes-Federation-Evolution.md b/content/en/blog/_posts/2018-12-11-Kubernetes-Federation-Evolution.md index 02768fafd3..53c89f9c33 100644 --- a/content/en/blog/_posts/2018-12-11-Kubernetes-Federation-Evolution.md +++ b/content/en/blog/_posts/2018-12-11-Kubernetes-Federation-Evolution.md @@ -8,7 +8,7 @@ date: 2018-12-12 Kubernetes provides great primitives for deploying applications to a cluster: it can be as simple as `kubectl create -f app.yaml`. Deploy apps across multiple clusters has never been that simple. How should app workloads be distributed? Should the app resources be replicated into all clusters, replicated into selected clusters, or partitioned into clusters? How is access to the clusters managed? What happens if some of the resources that a user wants to distribute pre-exist, in some or all of the clusters, in some form? -In SIG Multicluster, our journey has revealed that there are multiple possible models to solve these problems and there probably is no single best-fit, all-scenario solution. [Federation](https://kubernetes.io/docs/concepts/cluster-administration/federation/), however, is the single biggest Kubernetes open source sub-project, and has seen the maximum interest and contribution from the community in this problem space. The project initially reused the Kubernetes API to do away with any added usage complexity for an existing Kubernetes user. This approach was not viable, because of the problems summarised below: +In SIG Multicluster, our journey has revealed that there are multiple possible models to solve these problems and there probably is no single best-fit, all-scenario solution. [Federation](/docs/concepts/cluster-administration/federation/), however, is the single biggest Kubernetes open source sub-project, and has seen the maximum interest and contribution from the community in this problem space. The project initially reused the Kubernetes API to do away with any added usage complexity for an existing Kubernetes user. This approach was not viable, because of the problems summarised below: * Difficulties in re-implementing the Kubernetes API at the cluster level, as federation-specific extensions were stored in annotations. * Limited flexibility in federated types, placement and reconciliation, due to 1:1 emulation of the Kubernetes API. diff --git a/content/en/blog/_posts/2019-01-14-apiserver-dry-run-and-kubectl-diff.md b/content/en/blog/_posts/2019-01-14-apiserver-dry-run-and-kubectl-diff.md index bbaeb891c1..7853218a0c 100644 --- a/content/en/blog/_posts/2019-01-14-apiserver-dry-run-and-kubectl-diff.md +++ b/content/en/blog/_posts/2019-01-14-apiserver-dry-run-and-kubectl-diff.md @@ -38,7 +38,7 @@ The working group has tried to address these problems. ## APIServer dry-run -[APIServer dry-run](https://kubernetes.io/docs/reference/using-api/api-concepts/#dry-run) was implemented to address these two problems: +[APIServer dry-run](/docs/reference/using-api/api-concepts/#dry-run) was implemented to address these two problems: - it allows individual requests to the apiserver to be marked as "dry-run", - the apiserver guarantees that dry-run requests won't be persisted to storage, @@ -60,7 +60,7 @@ using `kube-apiserver --feature-gates DryRun=true`. If you have dynamic admission controllers, you might have to fix them to: - Remove any side-effects when the dry-run parameter is specified on the webhook request, -- Specify in the [`sideEffects`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.13/#webhook-v1beta1-admissionregistration) +- Specify in the [`sideEffects`](/docs/reference/generated/kubernetes-api/v1.13/#webhook-v1beta1-admissionregistration) field of the `admissionregistration.k8s.io/v1beta1.Webhook` object to indicate that the object doesn't have side-effects on dry-run (or at all). diff --git a/content/en/blog/_posts/2019-01-15-container-storage-interface-ga.md b/content/en/blog/_posts/2019-01-15-container-storage-interface-ga.md index 05adbc3cb6..192d928b02 100644 --- a/content/en/blog/_posts/2019-01-15-container-storage-interface-ga.md +++ b/content/en/blog/_posts/2019-01-15-container-storage-interface-ga.md @@ -11,7 +11,7 @@ slug: container-storage-interface-ga The Kubernetes implementation of the [Container Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI) has been promoted to GA in the Kubernetes v1.13 release. Support for CSI was [introduced as alpha](http://blog.kubernetes.io/2018/01/introducing-container-storage-interface.html) in Kubernetes v1.9 release, and [promoted to beta](https://kubernetes.io/blog/2018/04/10/container-storage-interface-beta/) in the Kubernetes v1.10 release. -The GA milestone indicates that Kubernetes users may depend on the feature and its API without fear of backwards incompatible changes in future causing regressions. GA features are protected by the [Kubernetes deprecation policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/). +The GA milestone indicates that Kubernetes users may depend on the feature and its API without fear of backwards incompatible changes in future causing regressions. GA features are protected by the [Kubernetes deprecation policy](/docs/reference/using-api/deprecation-policy/). ## Why CSI? @@ -30,7 +30,7 @@ With the promotion to GA, the Kubernetes implementation of CSI introduces the fo - There were breaking changes between the CSI spec v0.1 and v0.2, so very old drivers implementing CSI 0.1 must be updated to be at least 0.2 compatible before use with Kubernetes v1.10.0+. - The Kubernetes `VolumeAttachment` object (introduced in v1.9 in the storage v1alpha1 group, and added to the v1beta1 group in v1.10) has been added to the storage v1 group in v1.13. - The Kubernetes `CSIPersistentVolumeSource` volume type has been promoted to GA. -- The [Kubelet device plugin registration mechanism](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-registration), which is the means by which kubelet discovers new CSI drivers, has been promoted to GA in Kubernetes v1.13. +- The [Kubelet device plugin registration mechanism](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-registration), which is the means by which kubelet discovers new CSI drivers, has been promoted to GA in Kubernetes v1.13. ## How to deploy a CSI driver? @@ -38,7 +38,7 @@ Kubernetes users interested in how to deploy or manage an existing CSI driver on ## How to use a CSI volume? -Assuming a CSI storage plugin is already deployed on a Kubernetes cluster, users can use CSI volumes through the familiar Kubernetes storage API objects: `PersistentVolumeClaims`, `PersistentVolumes`, and `StorageClasses`. Documented [here](https://kubernetes.io/docs/concepts/storage/volumes/#csi). +Assuming a CSI storage plugin is already deployed on a Kubernetes cluster, users can use CSI volumes through the familiar Kubernetes storage API objects: `PersistentVolumeClaims`, `PersistentVolumes`, and `StorageClasses`. Documented [here](/docs/concepts/storage/volumes/#csi). Although the Kubernetes implementation of CSI is a GA feature in Kubernetes v1.13, it may require the following flag: @@ -143,7 +143,7 @@ spec: When the pod referencing a CSI volume is scheduled, Kubernetes will trigger the appropriate operations against the external CSI plugin (`ControllerPublishVolume`, `NodeStageVolume`, `NodePublishVolume`, etc.) to ensure the specified volume is attached, mounted, and ready to use by the containers in the pod. -For more details please see the CSI implementation [design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md) and [documentation](https://kubernetes.io/docs/concepts/storage/volumes/#csi). +For more details please see the CSI implementation [design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md) and [documentation](/docs/concepts/storage/volumes/#csi). ## How to write a CSI Driver? @@ -154,13 +154,13 @@ The [kubernetes-csi](https://kubernetes-csi.github.io/) site details how to deve - [external-provisioner](https://github.com/kubernetes-csi/external-provisioner) - Watches Kubernetes `PersistentVolumeClaim` objects and triggers `CreateVolume` and `DeleteVolume` operations against a CSI endpoint. - [node-driver-registrar](https://github.com/kubernetes-csi/node-driver-registrar) - - Registers the CSI driver with kubelet using the [Kubelet device plugin mechanism](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-registration). + - Registers the CSI driver with kubelet using the [Kubelet device plugin mechanism](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-registration). - [cluster-driver-registrar](https://github.com/kubernetes-csi/cluster-driver-registrar) (Alpha) - Registers a CSI Driver with the Kubernetes cluster by creating a `CSIDriver` object which enables the driver to customize how Kubernetes interacts with it. - [external-snapshotter](https://github.com/kubernetes-csi/external-snapshotter) (Alpha) - Watches Kubernetes `VolumeSnapshot` CRD objects and triggers `CreateSnapshot` and `DeleteSnapshot` operations against a CSI endpoint. - [livenessprobe](https://github.com/kubernetes-csi/livenessprobe) - - May be included in a CSI plugin pod to enable the [Kubernetes Liveness Probe](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) mechanism. + - May be included in a CSI plugin pod to enable the [Kubernetes Liveness Probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) mechanism. Storage vendors can build Kubernetes deployments for their plugins using these components, while leaving their CSI driver completely unaware of Kubernetes. diff --git a/content/en/blog/_posts/2019-01-17-update-volume-snapshot-alpha.md b/content/en/blog/_posts/2019-01-17-update-volume-snapshot-alpha.md index 208a940ba6..6b89b3d4c6 100644 --- a/content/en/blog/_posts/2019-01-17-update-volume-snapshot-alpha.md +++ b/content/en/blog/_posts/2019-01-17-update-volume-snapshot-alpha.md @@ -52,7 +52,7 @@ The `Retain` policy allows for manual reclamation of the resource. If a `VolumeS ### Delete -A `Delete` policy enables automatic deletion of the bound `VolumeSnapshotContent` object from Kubernetes and the associated storage asset in the external infrastructure (such as an AWS EBS snapshot or GCE PD snapshot, etc.). Snapshots that are dynamically provisioned inherit the deletion policy of their [`VolumeSnapshotClass`](https://kubernetes.io/docs/concepts/storage/volume-snapshot-classes/), which defaults to `Delete`. The administrator should configure the `VolumeSnapshotClass` with the desired retention policy. The policy may be changed for individual `VolumeSnapshotContent` after it is created by patching the object. +A `Delete` policy enables automatic deletion of the bound `VolumeSnapshotContent` object from Kubernetes and the associated storage asset in the external infrastructure (such as an AWS EBS snapshot or GCE PD snapshot, etc.). Snapshots that are dynamically provisioned inherit the deletion policy of their [`VolumeSnapshotClass`](/docs/concepts/storage/volume-snapshot-classes/), which defaults to `Delete`. The administrator should configure the `VolumeSnapshotClass` with the desired retention policy. The policy may be changed for individual `VolumeSnapshotContent` after it is created by patching the object. The following example demonstrates how to check the deletion policy of a dynamically provisioned `VolumeSnapshotContent`. diff --git a/content/en/blog/_posts/2019-02-06-poseidon-firmament-scheduler-announcement.md b/content/en/blog/_posts/2019-02-06-poseidon-firmament-scheduler-announcement.md index 12b3cf21af..54d63b675d 100644 --- a/content/en/blog/_posts/2019-02-06-poseidon-firmament-scheduler-announcement.md +++ b/content/en/blog/_posts/2019-02-06-poseidon-firmament-scheduler-announcement.md @@ -15,11 +15,11 @@ In this blog post, we briefly describe the novel Firmament flow network graph ba ## Poseidon-Firmament Scheduler – How It Works -At a very high level, [Poseidon-Firmament scheduler](https://kubernetes.io/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler/) augments the current Kubernetes scheduling capabilities by incorporating novel flow network graph based scheduling capabilities alongside the default Kubernetes Scheduler. It models the scheduling problem as a constraint-based optimization over a flow network graph – by reducing scheduling to a min-cost max-flow optimization problem. Due to the inherent rescheduling capabilities, the new scheduler enables a globally optimal scheduling environment that constantly keeps refining the workloads placements dynamically. +At a very high level, [Poseidon-Firmament scheduler](/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler/) augments the current Kubernetes scheduling capabilities by incorporating novel flow network graph based scheduling capabilities alongside the default Kubernetes Scheduler. It models the scheduling problem as a constraint-based optimization over a flow network graph – by reducing scheduling to a min-cost max-flow optimization problem. Due to the inherent rescheduling capabilities, the new scheduler enables a globally optimal scheduling environment that constantly keeps refining the workloads placements dynamically. ## Key Advantages -Flow graph scheduling based [Poseidon-Firmament scheduler](https://kubernetes.io/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler/) provides the following key advantages: +Flow graph scheduling based [Poseidon-Firmament scheduler](/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler/) provides the following key advantages: * Workloads (pods) are bulk scheduled to enable scheduling decisions at massive scale. @@ -49,7 +49,7 @@ Poseidon is a service that acts as the integration glue for the Firmament schedu {{
}} -As part of the Kubernetes multiple schedulers support, each new pod is typically scheduled by the default scheduler, but Kubernetes can be instructed to use another scheduler by specifying the name of another custom scheduler (in our case, [Poseidon-Firmament](https://kubernetes.io/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler/)) at the time of pod deployment. In this case, the default scheduler will ignore that Pod and allow Poseidon scheduler to schedule the Pod to a relevant node. +As part of the Kubernetes multiple schedulers support, each new pod is typically scheduled by the default scheduler, but Kubernetes can be instructed to use another scheduler by specifying the name of another custom scheduler (in our case, [Poseidon-Firmament](/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler/)) at the time of pod deployment. In this case, the default scheduler will ignore that Pod and allow Poseidon scheduler to schedule the Pod to a relevant node. {{< note >}} For details about the design of this project see the [design document](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/design/README.md). @@ -57,9 +57,9 @@ For details about the design of this project see the [design document](https://g ## Possible Use Case Scenarios – When To Use It -[Poseidon-Firmament scheduler](https://kubernetes.io/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler/) enables extremely high throughput scheduling environment at scale due to its bulk scheduling approach superiority versus K8s pod-at-a-time approach. In our extensive tests, we have observed substantial throughput benefits as long as resource requirements (CPU/Memory) for incoming Pods is uniform across jobs (Replicasets/Deployments/Jobs), mainly due to efficient amortization of work across jobs. +[Poseidon-Firmament scheduler](/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler/) enables extremely high throughput scheduling environment at scale due to its bulk scheduling approach superiority versus K8s pod-at-a-time approach. In our extensive tests, we have observed substantial throughput benefits as long as resource requirements (CPU/Memory) for incoming Pods is uniform across jobs (Replicasets/Deployments/Jobs), mainly due to efficient amortization of work across jobs. -Although, [Poseidon-Firmament scheduler](https://kubernetes.io/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler/) is capable of scheduling various types of workloads (service, batch, etc.), following are the few use cases where it excels the most: +Although, [Poseidon-Firmament scheduler](/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler/) is capable of scheduling various types of workloads (service, batch, etc.), following are the few use cases where it excels the most: 1. For “Big Data/AI” jobs consisting of a large number of tasks, throughput benefits are tremendous. diff --git a/content/en/blog/_posts/2019-02-12-building-a-kubernetes-edge-control-plane-for-envoy-v2.md b/content/en/blog/_posts/2019-02-12-building-a-kubernetes-edge-control-plane-for-envoy-v2.md index 7751712f0e..2beb0ee5cb 100644 --- a/content/en/blog/_posts/2019-02-12-building-a-kubernetes-edge-control-plane-for-envoy-v2.md +++ b/content/en/blog/_posts/2019-02-12-building-a-kubernetes-edge-control-plane-for-envoy-v2.md @@ -20,7 +20,7 @@ With the open source [Ambassador API Gateway](https://www.getambassador.io), we ## Ambassador pre-2019: Envoy v1 APIs, Jinja Template Files, and Hot Restarts -Ambassador itself is deployed within a container as a Kubernetes service, and uses annotations added to Kubernetes Services as its [core configuration model](https://www.getambassador.io/reference/configuration). This approach [enables application developers to manage routing](https://www.getambassador.io/concepts/developers) as part of the Kubernetes service definition. We explicitly decided to go down this route because of [limitations](https://blog.getambassador.io/kubernetes-ingress-nodeport-load-balancers-and-ingress-controllers-6e29f1c44f2d) in the current [Ingress API spec](https://kubernetes.io/docs/concepts/services-networking/ingress/), and we liked the simplicity of extending Kubernetes services, rather than introducing another custom resource type. An example of an Ambassador annotation can be seen here: +Ambassador itself is deployed within a container as a Kubernetes service, and uses annotations added to Kubernetes Services as its [core configuration model](https://www.getambassador.io/reference/configuration). This approach [enables application developers to manage routing](https://www.getambassador.io/concepts/developers) as part of the Kubernetes service definition. We explicitly decided to go down this route because of [limitations](https://blog.getambassador.io/kubernetes-ingress-nodeport-load-balancers-and-ingress-controllers-6e29f1c44f2d) in the current [Ingress API spec](/docs/concepts/services-networking/ingress/), and we liked the simplicity of extending Kubernetes services, rather than introducing another custom resource type. An example of an Ambassador annotation can be seen here: ``` diff --git a/content/en/blog/_posts/2019-03-07-raw-block-volume-support-to-beta.md b/content/en/blog/_posts/2019-03-07-raw-block-volume-support-to-beta.md index fc08eadf83..c763c90d9e 100644 --- a/content/en/blog/_posts/2019-03-07-raw-block-volume-support-to-beta.md +++ b/content/en/blog/_posts/2019-03-07-raw-block-volume-support-to-beta.md @@ -104,13 +104,13 @@ Raw block support for CSI plugins is still alpha, but support can be added today Because block devices are actually devices, it’s possible to do low-level actions on them from inside containers that wouldn’t be possible with file system volumes. For example, block devices that are actually SCSI disks support sending SCSI commands to the device using Linux ioctls. -By default, Linux won’t allow containers to send SCSI commands to disks from inside containers though. In order to do so, you must grant the `SYS_RAWIO` capability to the container security context to allow this. See documentation [here](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container). +By default, Linux won’t allow containers to send SCSI commands to disks from inside containers though. In order to do so, you must grant the `SYS_RAWIO` capability to the container security context to allow this. See documentation [here](/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container). Also, while Kubernetes is guaranteed to deliver a block device to the container, there’s no guarantee that it’s actually a SCSI disk or any other kind of disk for that matter. The user must either ensure that the desired disk type is used with his pods, or only deploy applications that can handle a variety of block device types. ## How can I learn more? -Check out additional documentation on the snapshot feature here: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#raw-block-volume-support +Check out additional documentation on the snapshot feature here: /docs/concepts/storage/persistent-volumes/#raw-block-volume-support How do I get involved? diff --git a/content/en/blog/_posts/2019-03-19-kubeedge-k8s-based-edge-intro.md b/content/en/blog/_posts/2019-03-19-kubeedge-k8s-based-edge-intro.md new file mode 100644 index 0000000000..2d0d0e738d --- /dev/null +++ b/content/en/blog/_posts/2019-03-19-kubeedge-k8s-based-edge-intro.md @@ -0,0 +1,105 @@ +--- +title: KubeEdge, a Kubernetes Native Edge Computing Framework +date: 2019-03-19 +slug: kubeedge-k8s-based-edge-intro +--- + +**Author:** Sanil Kumar D (Huawei), Jun Du(Huawei) + +## KubeEdge becomes the first Kubernetes Native Edge Computing Platform with both Edge and Cloud components open sourced! + +Open source edge computing is going through its most dynamic phase of development in the industry. So many open source platforms, so many consolidations and so many initiatives for standardization! This shows the strong drive to build better platforms to bring cloud computing to the edges to meet ever increasing demand. [KubeEdge](https://github.com/kubeedge/kubeedge), which was announced last year, now brings great news for cloud native computing! It provides a complete edge computing solution based on Kubernetes with separate cloud and edge core modules. Currently, both the cloud and edge modules are open sourced. + +Unlike certain light weight kubernetes platforms available around, KubeEdge is made to build edge computing solutions extending the cloud. The control plane resides in cloud, though scalable and extendable. At the same time, the edge can work in offline mode. Also it is lightweight and containerized, and can support heterogeneous hardware at the edge. With the optimization in edge resource utlization, KubeEdge positions to save significant setup and operation cost for edge solutions. This makes it the most compelling edge computing platform in the world currently, based on Kubernetes! + +## Kube(rnetes)Edge! - Opening up a new Kubernetes-based ecosystem for Edge Computing + +The key goal for KubeEdge is extending Kubernetes ecosystem from cloud to edge. From the time it was announced to the public at KubeCon in Shanghai in November 2018, the architecture direction for KubeEdge was aligned to Kubernetes, as its name! + +It started with its v0.1 providing the basic edge computing features. Now, with its latest release v0.2, it brings the cloud components to connect and complete the loop. With consistent and scalable Kubernetes-based interfaces, KubeEdge enables the orchestration and management of edge clusters similar to how Kubernetes manages in the cloud. This opens up seamless possibilities of bringing cloud computing capabilities to the edge, quickly and efficiently. + +

+ +

+ +**KubeEdge Links:** + + - [Website](https://kubeedge.io) + - [SourceCode](https://github.com/kubeedge/kubeedge) + - [Documentation](https://docs.kubeedge.io) + +Based on its roadmap and architecture, KubeEdge tries to support all edge nodes, applications, devices and even the cluster management consistent with the Kuberenetes interface. This will help the edge cloud act exactly like a cloud cluster. This can save a lot of time and cost on the edge cloud development deployment based on KubeEdge. + +KubeEdge provides a containerized edge computing platform, which is inherently scalable. As it's modular and optimized, it is lightweight (66MB foot print and ~30MB running memory) and could be deployed on low resource devices. Similarly, the edge node can be of different hardware architecture and with different hardware configurations. For the device connectivity, it can support multiple protocols and it uses a standard MQTT-based communication. This helps in scaling the edge clusters with new nodes and devices efficiently. + +**

You heard it right!

** +**

KubeEdge Cloud Core modules are open sourced!

** + +By open sourcing both the edge and cloud modules, KubeEdge brings a complete cloud vendor agnostic lightweight heterogeneous edge computing platform. It is now ready to support building a complete Kubernetes ecosystem for edge computing, exploiting most of the existing cloud native projects or software modules. This can enable a mini-cloud at the edge to support demanding use cases like data analytics, video analytics, machine learning and more. + +## KubeEdge Architecture: Building Kuberenetes Native Edge computing! + +The core architecture tenet for KubeEdge is to build interfaces that are consistent with Kubernetes, be it on the cloud side or edge side. + +

+ +

+ +**Edged**: Manages containerized Applications at the Edge. + +**EdgeHub**: Communication interface module at the Edge. It is a web socket client responsible for interacting with Cloud Service for edge computing. + +**CloudHub**: Communication interface module at the Cloud. A web socket server responsible for watching changes on the cloud side, caching and sending messages to EdgeHub. + +**EdgeController**: Manages the Edge nodes. It is an extended Kubernetes controller which manages edge nodes and pods metadata so that the data can be targeted to a specific edge node. + +**EventBus**: Handles the internal edge communications using MQTT. It is an MQTT client to interact with MQTT servers (mosquitto), offering publish and subscribe capabilities to other components. + +**DeviceTwin**: It is software mirror for devices that handles the device metadata. This module helps in handling device status and syncing the same to cloud. It also provides query interfaces for applications, as it interfaces to a lightweight database (SQLite). + +**MetaManager**: It manages the metadata at the edge node. This is the message processor between edged and edgehub. It is also responsible for storing/retrieving metadata to/from a lightweight database (SQLite). + +Even if you want to add more control plane modules based on the architecture refinement and improvement (for example enhanced security), it is simple as it uses consistent registration and modular communication within these modules. + +**

KubeEdge provides scalable lightweight Kubernetes Native Edge Computing Platform which can work in offline mode.

** + +**

It helps simplify edge application development and deployment.

** + +**

Cloud vendor agnostic and can run the cloud core modules on any compute node.

** + +## Release 0.1 to 0.2 -- game changer! + +KubeEdge v0.1 was released at the end of December 2018 with very basic edge features to manage edge applications along with Kubernetes API primitives for node, pod, config etc. In ~2 months, KubeEdge v0.2 was release on March 5th, 2019. This release provides the cloud core modules and enables the end to end open source edge computing solution. The cloud core modules can be deployed to any compute node from any cloud vendors or on-prem. + +Now, the complete edge solution can be installed and tested very easily, also with a laptop. + +## Run Anywhere - Simple and Light + +As described, the KubeEdge Edge and Cloud core components can be deployed easily and can run the user applications. The edge core has a foot print of 66MB and just needs 30MB memory to run. Similarly the cloud core can run on any cloud nodes. (User can experience by running it on a laptop as well) + +The installation is simple and can be done in few steps: + + 1. Setup the pre-requisites Docker, Kubernetes, MQTT and openssl + 2. Clone and Build KubeEdge Cloud and Edge + 3. Run Cloud + 4. Run Edge + +The detailed steps for each are available at [KubeEdge/kubeedge](https://github.com/kubeedge/kubeedge) + +## Future: Taking off with competent features and community collaboration + +KubeEdge has been developed by members from the community who are active contributors to Kubernetes/CNCF and doing research in edge computing. The KubeEdge team is also actively collaborating with Kubernetes IOT/EDGE WORKING GROUP. Within a few months of the KubeEdge announcement it has attracted members from different organizations including JingDong, Zhejiang University, SEL Lab, Eclipse, China Mobile, ARM, Intel to collaborate in building the platform and ecosystem. + +KubeEdge has a clear roadmap for its upcoming major releases in 2019. vc1.0 targets to provide a complete edge cluster and device management solution with standard edge to edge communication, while v2.0 targets to have advanced features like service mesh, function service , data analytics etc at edge. Also, for all the features, KubeEdge architecture would attempt to utilize the existing CNCF projects/software. + +The KubeEdge community needs varied organizations, their requirements, use cases and support to build it. Please join to make a kubernetes native edge computing platform which can extend the cloud native computing paradigm to edge cloud. + +## How to Get Involved? + +We welcome more collaboration to build the Kubernetes native edge computing ecosystem. Please join us! + +- Twitter: https://twitter.com/kubeedge +- Slack: [kubeedge.slack.com](mailto:kubeedge.slack.com) +- Website: https://kubeedge.io +- GitHub: https://github.com/kubeedge/kubeedge +- Email: [kubeedge@gmail.com](mailto:kubeedge@gmail.com) diff --git a/content/en/blog/_posts/2019-03-20-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits.md b/content/en/blog/_posts/2019-03-20-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits.md new file mode 100644 index 0000000000..741fbd176e --- /dev/null +++ b/content/en/blog/_posts/2019-03-20-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits.md @@ -0,0 +1,92 @@ +--- +title: A Look Back and What's in Store for Kubernetes Contributor Summits +date: 2019-03-20 +--- + +**Authors:** +Paris Pittman (Google), Jonas Rosland (VMware) + +**tl;dr** - [click here] for Barcelona Contributor Summit information. + +{{
}} + +As our contributing community grows in great numbers, with more than 16,000 contributors this year across 150+ GitHub repositories, it’s important to provide face to face connections for our large distributed teams to have opportunities for collaboration and learning. In [Contributor Experience], our methodology with planning events is a lot like our documentation; we build from personas -- interests, skills, and motivators to name a few. This way we ensure there is valuable content and learning for everyone. + +We build the contributor summits around you: + +* New Contributor +* Current Contributor + * docs + * code + * community management +* [Subproject OWNERs] (aka maintainers in other OSS circles) +* Special Interest Group (SIG) / Working Group (WG) [Chair or Tech Lead] +* Active Contributors +* Casual Contributors + +{{
}} + +These personas combined with ample feedback from previous events, produce the altogether experience that welcomed over 600 contributors in Copenhagen (May), Shanghai(November), and Seattle(December) in 2018. Seattle's event drew over 300+ contributors, equal to Shanghai and Copenhagen combined, for the 6th contributor event in Kubernetes history. In true Kubernetes fashion, we expect another record breaking year of attendance. We've pre-ordered 900+ [contributor patches], a tradition, and we are looking forward to giving them to you! + +With that said... +**Save the Dates:** +Barcelona: May 19th (evening) and 20th (all day) +Shanghai: June 24th (all day) +San Diego: November 18th, 19th, and activities in KubeCon/CloudNativeCon week + +In an effort of continual improvement, here's what to expect from us this year: + +* Large new contributor workshops and contributor socials at all three events expected to break previous attendance records +* A multiple track event in San Diego for all contributor types including workshops, birds of a feather, lightning talks and more +* Addition of a “201” / “Intermediate” edition of the new contributor workshop in San Diego +* [An event website]! +* Follow along with updates: kubernetes-dev@googlegroups.com is our main communication hub as always; however, we will also blog here, our [Thursday Kubernetes Community Meeting], [twitter], SIG meetings, event site, discuss.kubernetes.io, and #contributor-summit on Slack. +* Opportunities to get involved: We still have 2019 roles available! +Reach out to Contributor Experience via community@kubernetes.io, stop by a Wednesday SIG update meeting, or catch us on Slack (#sig-contribex). + +{{
}} + +## Thanks! + +Our 2018 crew 🥁 +Jorge Castro, Paris Pittman, Bob Killen, Jeff Sica, Megan Lehn, Guinevere Saenger, Josh Berkus, Noah Abrahams, Yang Li, Xiangpeng Zhao, Puja Abbassi, Lindsey Tulloch, Zach Corleissen, Tim Pepper, Ihor Dvoretskyi, Nancy Mohamed, Chris Short, Mario Loria, Jason DeTiberus, Sahdev Zala, Mithra Raja + +And an introduction to our 2019 crew (a thanks in advance ;) )... +Jonas Rosland, Josh Berkus, Paris Pittman, Jorge Castro, Bob Killen, Deb Giles, Guinevere Saenger, Noah Abrahams, Yang Li, Xiangpeng Zhao, Puja Abbassi, Rui Chen, Tim Pepper, Ihor Dvoretskyi, Dawn Foster + + +## Relive Seattle Contributor Summit + +📈 80% growth rate since the Austin 2017 December event +📜 Event waiting list: 103 +🎓 76 contributors were on-boarded through the New Contributor Workshop +🎉 92% of the current contributors RSVPs attended and of those: +👩🏻‍🚒 25% were [Special Interest Group] or Working Group Chairs or Tech Leads +🗳 70% were eligible to vote in the last [steering committee election] (more than 50 contributions in 2018) +📹 20+ [Sessions] +👀 Most watched to date: Technical Vision, Security, API Code Base Tour +🌟 Top 3 according to survey: Live API Code Review, Deflaking Unconference, Technical Vision +🎱 🎳 160 attendees for the social at [Garage] on Sunday night where we sunk eight balls and recorded strikes (out in some cases) +🏆 Special recognition: SIG Storage, @dims, and @jordan +📸 Pictures (special thanks to [rdodev]) +Garage Pic +Reg Desk + +{{
}} + +“I love Contrib Summit! The intros and deep dives during KubeCon were a great extension of Contrib Summit. Y'all did an excellent job in the morning to level set expectations and prime everyone.” -- julianv +“great work! really useful and fun!” - coffeepac + +[click here]: https://events.linuxfoundation.org/events/contributor-summit-europe-2019/ +[Contributor Experience]: https://github.com/kubernetes/community/tree/master/sig-contributor-experience +[Subproject OWNERs]: https://github.com/kubernetes/community/blob/master/community-membership.md +[Chair or Tech Lead]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md +[contributor patches]: https://store.cncf.io/collections/kubernetes/products/copy-of-kubernetes-decal +[An event website]: https://events.linuxfoundation.org/events/contributor-summit-europe-2019/ +[Thursday Kubernetes Community Meeting]: https://github.com/kubernetes/community/blob/master/events/community-meeting.md +[twitter]: https://twitter.com/kubernetesio +[Special Interest Group]: https://github.com/kubernetes/community/blob/master/sig-list.md +[steering committee election]: https://github.com/kubernetes/steering/blob/master/elections.md +[Sessions]: https://www.youtube.com/playlist?list=PL69nYSiGNLP0kaZWKZc9KizriafE4pzh0 +[Garage]: https://www.garagebilliards.com/ +[rdodev]: https://github.com/rdodev diff --git a/content/en/blog/_posts/2019-03-21-a-guide-to-kubernetes-admission-controllers.md b/content/en/blog/_posts/2019-03-21-a-guide-to-kubernetes-admission-controllers.md new file mode 100644 index 0000000000..f3da77db5b --- /dev/null +++ b/content/en/blog/_posts/2019-03-21-a-guide-to-kubernetes-admission-controllers.md @@ -0,0 +1,182 @@ +--- +title: A Guide to Kubernetes Admission Controllers +date: 2019-03-21 +--- + +**Author:** Malte Isberner (StackRox) + +Kubernetes has greatly improved the speed and manageability of backend clusters in production today. Kubernetes has emerged as the de facto standard in container orchestrators thanks to its flexibility, scalability, and ease of use. Kubernetes also provides a range of features that secure production workloads. A more recent introduction in security features is a set of plugins called “[admission controllers](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/).” Admission controllers must be enabled to use some of the more advanced security features of Kubernetes, such as [pod security policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) that enforce a security configuration baseline across an entire namespace. The following must-know tips and tricks will help you leverage admission controllers to make the most of these security capabilities in Kubernetes. + +## What are Kubernetes admission controllers? + +In a nutshell, Kubernetes admission controllers are plugins that govern and enforce how the cluster is used. They can be thought of as a gatekeeper that intercept (authenticated) API requests and may change the request object or deny the request altogether. The admission control process has two phases: the _mutating_ phase is executed first, followed by the _validating_ phase. Consequently, admission controllers can act as mutating or validating controllers or as a combination of both. For example, the **LimitRanger** admission controller can augment pods with default resource requests and limits (mutating phase), as well as verify that pods with explicitly set resource requirements do not exceed the per-namespace limits specified in the **LimitRange object** (validating phase). + +
{{
}}
+ +It is worth noting that some aspects of Kubernetes’ operation that many users would consider built-in are in fact governed by admission controllers. For example, when a namespace is deleted and subsequently enters the `Terminating` state, the [`NamespaceLifecycle`](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#namespacelifecycle) admission controller is what prevents any new objects from being created in this namespace. + +Among the more than 30 admission controllers shipped with Kubernetes, two take a special role because of their nearly limitless flexibility - `ValidatingAdmissionWebhooks` and `MutatingAdmissionWebhooks`, both of which are in beta status as of Kubernetes 1.13. We will examine these two admission controllers closely, as they do not implement any policy decision logic themselves. Instead, the respective action is obtained from a REST endpoint (a _webhook_) of a service running inside the cluster. This approach decouples the admission controller logic from the Kubernetes API server, thus allowing users to implement custom logic to be executed whenever resources are created, updated, or deleted in a Kubernetes cluster. + +The difference between the two kinds of admission controller webhooks is pretty much self-explanatory: mutating admission webhooks may mutate the objects, while validating admission webhooks may not. However, even a mutating admission webhook can reject requests and thus act in a validating fashion. Validating admission webhooks have two main advantages over mutating ones: first, for security reasons it might be desirable to disable the `MutatingAdmissionWebhook` admission controller (or apply stricter RBAC restrictions as to who may create `MutatingWebhookConfiguration` objects) because of its potentially confusing or even dangerous side effects. Second, as shown in the previous diagram, validating admission controllers (and thus webhooks) are run after any mutating ones. As a result, whatever request object a validating webhook sees is the final version that would be persisted to `etcd`. + +The set of enabled admission controllers is configured by passing a flag to the Kubernetes API server. Note that the old **--admission-control** flag was deprecated in 1.10 and replaced with **--enable-admission-plugins**. + +``` +--enable-admission-plugins=ValidatingAdmissionWebhook,MutatingAdmissionWebhook +``` + +Kubernetes recommends the following admission controllers to be enabled by default. + +``` +--enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,Priority,ResourceQuota,PodSecurityPolicy +``` + +The complete list of admission controllers with their descriptions can be found [in the official Kubernetes reference](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#what-does-each-admission-controller-do). This discussion will focus only on the webhook-based admission controllers. + +## Why do I need admission controllers? + +* **Security:** Admission controllers can increase security by mandating a reasonable security baseline across an entire namespace or cluster. The built-in `PodSecurityPolicy` admission controller is perhaps the most prominent example; it can be used for disallowing containers from running as root or making sure the container’s root filesystem is always mounted read-only, for example. Further use cases that can be realized by custom, webhook-based admission controllers include: + * Allow pulling images only from specific registries known to the enterprise, while denying unknown image registries. + * Reject deployments that do not meet security standards. For example, containers using the `privileged` flag can circumvent a lot of security checks. This risk could be mitigated by a webhook-based admission controller that either rejects such deployments (validating) or overrides the `privileged` flag, setting it to `false`. +* **Governance:** Admission controllers allow you to enforce the adherence to certain practices such as having good labels, annotations, resource limits, or other settings. Some of the common scenarios include: + * Enforce label validation on different objects to ensure proper labels are being used for various objects, such as every object being assigned to a team or project, or every deployment specifying an app label. + * Automatically add annotations to objects, such as attributing the correct cost center for a “dev” deployment resource. +* **Configuration management:** Admission controllers allow you to validate the configuration of the objects running in the cluster and prevent any obvious misconfigurations from hitting your cluster. Admission controllers can be useful in detecting and fixing images deployed without semantic tags, such as by: + * automatically adding resource limits or validating resource limits, + * ensuring reasonable labels are added to pods, or + * ensuring image references used in production deployments are not using the `latest` tags, or tags with a `-dev` suffix. + +In this way, admission controllers and policy management help make sure that applications stay in compliance within an ever-changing landscape of controls. + +## Example: Writing and Deploying an Admission Controller Webhook + +To illustrate how admission controller webhooks can be leveraged to establish custom security policies, let’s consider an example that addresses one of the shortcomings of Kubernetes: a lot of its defaults are optimized for ease of use and reducing friction, sometimes at the expense of security. One of these settings is that containers are by default allowed to run as root (and, without further configuration and no `USER` directive in the Dockerfile, will also do so). Even though containers are isolated from the underlying host to a certain extent, running containers as root does increase the risk profile of your deployment— and should be avoided as one of many [security best practices](https://www.stackrox.com/post/2018/12/6-container-security-best-practices-you-should-be-following/). The [recently exposed runC vulnerability](https://www.stackrox.com/post/2019/02/the-runc-vulnerability-a-deep-dive-on-protecting-yourself/) ([CVE-2019-5736](https://nvd.nist.gov/vuln/detail/CVE-2019-5736)), for example, could be exploited only if the container ran as root. + +You can use a custom mutating admission controller webhook to apply more secure defaults: unless explicitly requested, our webhook will ensure that pods run as a non-root user (we assign the user ID 1234 if no explicit assignment has been made). Note that this setup does not prevent you from deploying any workloads in your cluster, including those that legitimately require running as root. It only requires you to explicitly enable this risker mode of operation in the deployment configuration, while defaulting to non-root mode for all other workloads. + +The full code along with deployment instructions can be found in our accompanying [GitHub repository](https://github.com/stackrox/admission-controller-webhook-demo). Here, we will highlight a few of the more subtle aspects about how webhooks work. + +## Mutating Webhook Configuration + +A mutating admission controller webhook is defined by creating a `MutatingWebhookConfiguration` object in Kubernetes. In our example, we use the following configuration: + +``` +apiVersion: admissionregistration.k8s.io/v1beta1 +kind: MutatingWebhookConfiguration +metadata: + name: demo-webhook +webhooks: + - name: webhook-server.webhook-demo.svc + clientConfig: + service: + name: webhook-server + namespace: webhook-demo + path: "/mutate" + caBundle: ${CA_PEM_B64} + rules: + - operations: [ "CREATE" ] + apiGroups: [""] + apiVersions: ["v1"] + resources: ["pods"] +``` + +This configuration defines a `webhook webhook-server.webhook-demo.svc`, and instructs the Kubernetes API server to consult the service `webhook-server` in n`amespace webhook-demo` whenever a pod is created by making a HTTP POST request to the `/mutate` URL. For this configuration to work, several prerequisites have to be met. + +## Webhook REST API + +The Kubernetes API server makes an HTTPS POST request to the given service and URL path, with a JSON-encoded [`AdmissionReview`](https://github.com/kubernetes/api/blob/master/admission/v1beta1/types.go#L29) (with the `Request` field set) in the request body. The response should in turn be a JSON-encoded `AdmissionReview`, this time with the Response field set. + +Our demo repository contains a [function](https://github.com/stackrox/admission-controller-webhook-demo/blob/master/cmd/webhook-server/admission_controller.go#L132) that takes care of the serialization/deserialization boilerplate code and allows you to focus on implementing the logic operating on Kubernetes API objects. In our example, the function implementing the admission controller logic is called `applySecurityDefaults`, and an HTTPS server serving this function under the /mutate URL can be set up as follows: + +``` +mux := http.NewServeMux() +mux.Handle("/mutate", admitFuncHandler(applySecurityDefaults)) +server := &http.Server{ + Addr: ":8443", + Handler: mux, +} +log.Fatal(server.ListenAndServeTLS(certPath, keyPath)) +``` + +Note that for the server to run without elevated privileges, we have the HTTP server listen on port 8443. Kubernetes does not allow specifying a port in the webhook configuration; it always assumes the HTTPS port 443. However, since a service object is required anyway, we can easily map port 443 of the service to port 8443 on the container: + +``` +apiVersion: v1 +kind: Service +metadata: + name: webhook-server + namespace: webhook-demo +spec: + selector: + app: webhook-server # specified by the deployment/pod + ports: + - port: 443 + targetPort: webhook-api # name of port 8443 of the container +``` + +## Object Modification Logic + +In a mutating admission controller webhook, mutations are performed via [JSON patches](https://tools.ietf.org/html/rfc6902). While the JSON patch standard includes a lot of intricacies that go well beyond the scope of this discussion, the Go data structure in our example as well as its usage should give the user a good initial overview of how JSON patches work: + +``` +type patchOperation struct { + Op string `json:"op"` + Path string `json:"path"` + Value interface{} `json:"value,omitempty"` +} +``` + +For setting the field `.spec.securityContext.runAsNonRoot` of a pod to true, we construct the following `patchOperation` object: + +``` +patches = append(patches, patchOperation{ + Op: "add", + Path: "/spec/securityContext/runAsNonRoot", + Value: true, +}) +``` + +## TLS Certificates + +Since a webhook must be served via HTTPS, we need proper certificates for the server. These certificates can be self-signed (rather: signed by a self-signed CA), but we need Kubernetes to instruct the respective CA certificate when talking to the webhook server. In addition, the common name (CN) of the certificate must match the server name used by the Kubernetes API server, which for internal services is ``.`.svc`, i.e., `webhook-server.webhook-demo.svc` in our case. Since the generation of self-signed TLS certificates is well documented across the Internet, we simply refer to the respective [shell script](https://github.com/stackrox/admission-controller-webhook-demo/blob/master/deployment/generate-keys.sh) in our example. + +The webhook configuration shown previously contains a placeholder `${CA_PEM_B64}`. Before we can create this configuration, we need to replace this portion with the Base64-encoded PEM certificate of the CA. The `openssl base64 -A` command can be used for this purpose. + +## Testing the Webhook + +After deploying the webhook server and configuring it, which can be done by invoking the ./deploy.sh script from the repository, it is time to test and verify that the webhook indeed does its job. The repository contains [three examples](https://github.com/stackrox/admission-controller-webhook-demo/tree/master/examples): + +* A pod that does not specify a security context (`pod-with-defaults`). We expect this pod to be run as non-root with user id 1234. +* A pod that does specify a security context, explicitly allowing it to run as root (`pod-with-override`). +* A pod with a conflicting configuration, specifying it must run as non-root but with a user id of 0 (`pod-with-conflict`). To showcase the rejection of object creation requests, we have augmented our admission controller logic to reject such obvious misconfigurations. + +Create one of these pods by running `kubectl create -f examples/.yaml`. In the first two examples, you can verify the user id under which the pod ran by inspecting the logs, for example: + +``` +$ kubectl create -f examples/pod-with-defaults.yaml +$ kubectl logs pod-with-defaults +I am running as user 1234 +``` + +In the third example, the object creation should be rejected with an appropriate error message: + +``` +$ kubectl create -f examples/pod-with-conflict.yaml +Error from server (InternalError): error when creating "examples/pod-with-conflict.yaml": Internal error occurred: admission webhook "webhook-server.webhook-demo.svc" denied the request: runAsNonRoot specified, but runAsUser set to 0 (the root user) +``` + +Feel free to test this with your own workloads as well. Of course, you can also experiment a little bit further by changing the logic of the webhook and see how the changes affect object creation. More information on how to do experiment with such changes can be found in the [repository’s readme](https://github.com/stackrox/admission-controller-webhook-demo/blob/master/README.md). + +## Summary + +Kubernetes admission controllers offer significant advantages for security. Digging into two powerful examples, with accompanying available code, will help you get started on leveraging these powerful capabilities. + +## References: + +* https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/ +* https://docs.okd.io/latest/architecture/additional_concepts/dynamic_admission_controllers.html +* https://kubernetes.io/blog/2018/01/extensible-admission-is-beta/ +* https://medium.com/ibm-cloud/diving-into-kubernetes-mutatingadmissionwebhook-6ef3c5695f74 +* https://github.com/kubernetes/kubernetes/blob/v1.10.0-beta.1/test/images/webhook/main.go +* https://github.com/istio/istio +* https://www.stackrox.com/post/2019/02/the-runc-vulnerability-a-deep-dive-on-protecting-yourself/ diff --git a/content/en/blog/_posts/2019-03-22-e2e-testing-for-everyone.md b/content/en/blog/_posts/2019-03-22-e2e-testing-for-everyone.md new file mode 100644 index 0000000000..e23c4ce82f --- /dev/null +++ b/content/en/blog/_posts/2019-03-22-e2e-testing-for-everyone.md @@ -0,0 +1,366 @@ +--- +title: Kubernetes End-to-end Testing for Everyone +date: 2019-03-22 +--- + +**Author:** Patrick Ohly (Intel) + +More and more components that used to be part of Kubernetes are now +being developed outside of Kubernetes. For example, storage drivers +used to be compiled into Kubernetes binaries, then were moved into +[stand-alone Flexvolume +binaries](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) +on the host, and now are delivered as [Container Storage Interface +(CSI) drivers](https://github.com/container-storage-interface/spec) +that get deployed in pods inside the Kubernetes cluster itself. + +This poses a challenge for developers who work on such components: how +can end-to-end (E2E) testing on a Kubernetes cluster be done for such +external components? The E2E framework that is used for testing +Kubernetes itself has all the necessary functionality. However, trying +to use it outside of Kubernetes was difficult and only possible by +carefully selecting the right versions of a large number of +dependencies. E2E testing has become a lot simpler in Kubernetes 1.13. + +This blog post summarizes the changes that went into Kubernetes +1.13. For CSI driver developers, it will cover the ongoing effort to +also make the storage tests available for testing of third-party CSI +drivers. How to use them will be shown based on two Intel CSI drivers: + +* [Open Infrastructure Manager (OIM)](https://github.com/intel/oim/) +* [PMEM-CSI](https://github.com/intel/pmem-csi) + +Testing those drivers was the main motivation behind most of these +enhancements. + +## E2E overview + +E2E testing consists of several phases: + +* Implementing a test suite. This is the main focus of this blog + post. The Kubernetes E2E framework is written in Go. It relies on + [Ginkgo](https://onsi.github.io/ginkgo/) for managing tests and + [Gomega](http://onsi.github.io/gomega/) for assertions. These tools + support “behavior driven development”, which describes expected + behavior in “specs”. In this blog post, “test” is used to reference + an individual `Ginkgo.It` spec. Tests interact with the Kubernetes + cluster using + [client-go](https://godoc.org/k8s.io/client-go/kubernetes). +* Bringing up a test cluster. Tools like + [kubetest](https://github.com/kubernetes/test-infra/blob/master/kubetest/README.md) + can help here. +* Running an E2E test suite against that cluster. Ginkgo test suites + can be run with the `ginkgo` tool or as a normal Go test with `go + test`. Without any parameters, a Kubernetes E2E test suite will + connect to the default cluster based on environment variables like + KUBECONFIG, exactly like kubectl. Kubetest also knows how to run the + Kubernetes E2E suite. + +## E2E framework enhancements in Kubernetes 1.13 + +All of the following enhancements follow the same basic pattern: they +make the E2E framework more useful and easier to use outside of +Kubernetes, without changing the behavior of the original Kubernetes +e2e.test binary. + +### Splitting out provider support + +The main reason why using the E2E framework from Kubernetes <= 1.12 +was difficult were the dependencies on provider-specific SDKs, which +pulled in a large number of packages. Just getting it compiled was +non-trivial. + +Many of these packages are only needed for certain tests. For example, +testing the mounting of a pre-provisioned volume must first provision +such a volume the same way as an administrator would, by talking +directly to a specific storage backend via some non-Kubernetes API. + +There is an effort to [remove cloud provider-specific +tests](https://github.com/kubernetes/kubernetes/issues/70194) from +core Kubernetes. The approach taken in [PR +#68483](https://github.com/kubernetes/kubernetes/pull/68483) can be +seen as an incremental step towards that goal: instead of ripping out +the code immediately and breaking all tests that depend on it, all +cloud provider-specific code was moved into optional packages under +[test/e2e/framework/providers](https://github.com/kubernetes/kubernetes/tree/release-1.13/test/e2e/framework/providers). The +E2E framework then accesses it via [an +interface](https://github.com/kubernetes/kubernetes/blob/6c1e64b94a3e111199c934c39a0c25bc219ed5f9/test/e2e/framework/provider.go#L79-L99) +that gets implemented separately by each vendor package. + +The author of a E2E test suite decides which of these packages get +imported into the test suite. The vendor support is then activated via +the `--provider` command line flag. The Kubernetes e2e.test binary in +1.13 and 1.14 still contains support for the same providers as in +1.12. It is also okay to include no packages, which means that only +the generic providers will be available: + +* “skeleton”: cluster is accessed via the Kubernetes API and nothing + else +* “local”: like “skeleton”, but in addition the scripts in + kubernetes/kubernetes/cluster can retrieve logs via ssh after a test + suite is run + +### External files + +Tests may have to read additional files at runtime, like .yaml +manifests. But the Kubernetes e2e.test binary is supposed to be usable +and entirely stand-alone because that simplifies shipping and running +it. The solution in the Kubernetes build system is to link all files +under `test/e2e/testing-manifests` into the binary with +[go-bindata](https://github.com/jteeuwen/go-bindata/go-bindata). The +E2E framework used to have a hard dependency on the output of +`go-bindata`, now [bindata support is +optional](https://github.com/kubernetes/kubernetes/pull/69103). When +accessing a file via the [testfiles +package](https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/e2e/framework/testfiles/testfiles.go), +files will be retrieved from different sources: + +* relative to the directory specified with `--repo-root` parameter +* zero or more bindata chunks + +### Test parameters + +The e2e.test binary takes additional parameters which control test +execution. In 2016, an effort was started to replace all E2E command +line parameters with a Viper configuration file. But that effort +[stalled](https://github.com/kubernetes/kubernetes/blob/0ed33881dc4355495f623c6f22e7dd0b7632b7c0/test/e2e/framework/test_context.go#L318-L319 +), which left developers without clear guidance how they should handle +test-specific parameters. + +The approach in v1.12 was to add all flags to the central +[test/e2e/framework/test_context.go](https://github.com/kubernetes/kubernetes/blob/v1.12.0/test/e2e/framework/test_context.go), +which does not work for tests developed independently from the +framework. Since [PR +#69105](https://github.com/kubernetes/kubernetes/pull/69105) the +recommendation has been to use the normal `flag` package to +define its parameters, in its own source code. Flag names must be +hierarchical with dots separating different levels, for example +`my.test.parameter`, and must be unique. Uniqueness is enforced by the +`flag` package which panics when registering a flag a second time. The +new +[config](https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/e2e/framework/config/config.go) +package simplifies the definition of multiple options, which are +stored in a single struct. + +To summarize, this is how parameters are handled now: + +* The init code in test packages defines tests and parameters. The + actual parameter *values* are not available yet, so test definitions + cannot use them. +* The init code of the test suite parses parameters and (optionally) + the configuration file. +* The tests run and now can use parameter values. + +However, recently it [was pointed +out](https://github.com/kubernetes/kubernetes/pull/69105#discussion_r267960062) +that it is desirable and was possible to not expose test settings as +command line flags and only set them via a configuration file. There +is an [open bug](https://github.com/kubernetes/kubernetes/issues/75590) and a +[pending PR](https://github.com/kubernetes/kubernetes/pull/75593) +about this. + +Viper support has been enhanced. Like the provider support, it is +completely optional. It gets pulled into a e2e.test binary by +importing the `viperconfig` package and [calling +it](https://github.com/kubernetes/kubernetes/blob/ddf47ac13c1a9483ea035a79cd7c10005ff21a6d/test/e2e/e2e_test.go#L49-L57) +after parsing the normal command line flags. This has been implemented +so that all variables which can be set via command line flags are also +set when the flag appears in a Viper config file. For example, the +Kubernetes v1.13 `e2e.test` binary accepts +`--viper-config=/tmp/my-config.yaml` and that file will set the +`my.test.parameter` to `value` when it has this content: my: test: +parameter: value + +In older Kubernetes releases, that option could only load a file from +the current directory, the suffix had to be left out, and only a few +parameters actually could be set this way. Beware that one limitation +of Viper still exists: it works by matching config file entries +against known flags, without warning about unknown config file entries +and thus leaving typos undetected. A [better config file +parser](https://github.com/kubernetes/kubeadm/issues/1040) for +Kubernetes is still work in progress. + +### Creating items from .yaml manifests + +In Kubernetes 1.12, there was some support for loading individual +items from a .yaml file, but then creating that item had to be done by +hand-written code. Now the framework has [new +methods](https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/e2e/framework/create.go) +for loading a .yaml file that has multiple items, patching those items +(for example, setting the namespace created for the current test), and +creating them. This is currently [used to deploy CSI +drivers](https://github.com/kubernetes/kubernetes/blob/ddf47ac13c1a9483ea035a79cd7c10005ff21a6d/test/e2e/storage/drivers/csi.go#L192-L209 +) anew for each test from exactly the same .yaml files that are also +used for deployment via kubectl. If the CSI driver supports running +under different names, then tests are completely independent and can +run in parallel. + +However, redeploying a driver slows down test execution and it does +not cover concurrent operations against the driver. A more realistic +test scenario is to deploy a driver once when bringing up the test +cluster, then run all tests against that deployment. Eventually the +Kubernetes E2E testing will move to that model, once it is clearer how +test cluster bringup can be extended such that it also includes +installing additional entities like CSI drivers. + +## Upcoming enhancements in Kubernetes 1.14 + +### Reusing storage tests + +Being able to use the framework outside of Kubernetes enables building +a custom test suite. But a test suite without tests is still +useless. Several of the existing tests, in particular for storage, can +also be applied to out-of-tree components. Thanks to the work done by +Masaki Kimura, [storage +tests](https://github.com/kubernetes/kubernetes/tree/v1.13.0/test/e2e/storage/testsuites) +in Kubernetes 1.13 are defined such that they can be instantiated +multiple times for different drivers. + +But history has a habit of repeating itself. As with providers, the +package defining these tests also pulled in driver definitions for all +in-tree storage backends, which in turn pulled in more additional +packages than were needed. This has been +[fixed](https://github.com/kubernetes/kubernetes/pull/70862) for the +upcoming Kubernetes 1.14. + +### Skipping unsupported tests + +Some of the storage tests depend on features of the cluster (like +running on a host that supports XFS) or of the driver (like supporting +block volumes). These conditions are checked while the test runs, +leading to skipped tests when they are not satisfied. The good thing +is that this records an explanation why the test did not run. + +Starting a test is slow, in particular when it must first deploy the +CSI driver, but also in other scenarios. Creating the namespace for a +test has been measured at 5 seconds on a fast cluster, and it produces +a lot of noisy test output. It would have been possible to address +that by [skipping the definition of unsupported +tests](https://github.com/kubernetes/kubernetes/pull/70992), but then +reporting why a test isn’t even part of the test suite becomes +tricky. This approach has been dropped in favor of reorganizing the +storage test suite such that it [first checks +conditions](https://github.com/kubernetes/kubernetes/pull/72434) +before doing the more expensive test setup steps. + +### More readable test definitions + +The same PR also rewrites the tests to operate like conventional +Ginkgo tests, with test cases and their local variables in [a single +function](https://github.com/pohly/kubernetes/blob/ec3655a1d40ced6b1873e627b736aae1cf242477/test/e2e/storage/testsuites/provisioning.go#L82). + +### Testing external drivers + +Building a custom E2E test suite is still quite a bit of work. The +e2e.test binary that will get distributed in the [Kubernetes 1.14 test +archive](https://dl.k8s.io/v1.14.0/kubernetes-test.tar.gz) will have +the [ability to +test](https://github.com/kubernetes/kubernetes/pull/72836) already +installed storage drivers without rebuilding the test suite. See this +[README](https://github.com/pohly/kubernetes/blob/6644db9914379a4a7b3d3487b41b2010f226e4dc/test/e2e/storage/external/README.md) +for further instructions. + +## E2E test suite HOWTO + +### Test suite initialization + +The first step is to set up the necessary boilerplate code that +defines the test suite. [In Kubernetes +E2E](https://github.com/kubernetes/kubernetes/tree/v1.13.0/test/e2e), +this is done in the `e2e.go` and `e2e_test.go` files. It could also be +done in a single `e2e_test.go` file. Kubernetes imports all of the +various providers, in-tree tests, Viper configuration support, and +bindata file lookup in `e2e_test.go`. `e2e.go` controls the actual +execution, including some cluster preparations and metrics collection. + +A simpler starting point are the `e2e_[test].go` files [from +PMEM-CSI](https://github.com/intel/pmem-csi/tree/586ae281ac2810cb4da6f1e160cf165c7daf0d80/test/e2e). It +doesn’t use any providers, no Viper, no bindata, and imports just the +storage tests. + +Like PMEM-CSI, OIM drops all of the extra features, but is a bit more +complex because it integrates a custom cluster startup directly into +the [test +suite](https://github.com/intel/pmem-csi/blob/a7b0d66b59771bf615e07fcd3d4f0ba08cfdf90f/test/e2e/e2e.go), +which was useful in this case because some additional components have +to run on the host side. By running them directly in the E2E binary, +interactive debugging with `dlv` becomes easier. + +Both CSI drivers follow the Kubernetes example and use the `test/e2e` +directory for their test suites, but any other directory and other +file names would also work. + +### Adding E2E storage tests + +Tests are defined by packages that get imported into a test suite. The +only thing specific to E2E tests is that they instantiate a +`framework.Framework` pointer (usually called `f`) with +`framework.NewDefaultFramework`. This variable gets initialized anew +in a `BeforeEach` for each test and freed in an `AfterEach`. It has a +`f.ClientSet` and `f.Namespace` at runtime (and only at runtime!) +which can be used by a test. + +The [PMEM-CSI storage +test](https://github.com/intel/pmem-csi/blob/586ae281ac2810cb4da6f1e160cf165c7daf0d80/storage/csi_volumes.go#L51) +imports the Kubernetes storage test suite and sets up one instance of +the provisioning tests for a PMEM-CSI driver which must be already +installed in the test cluster. The storage test suite changes the +storage class to run tests with different filesystem types. Because of +this requirement, the storage class is created from a .yaml file. + +Explaining all the various utility methods available in the framework +is out of scope for this blog post. Reading existing tests and the +source code of the framework is a good way to get started. + +### Vendoring + +Vendoring Kubernetes code is still not trivial, even after eliminating +many of the unnecessary dependencies. `k8s.io/kubernetes` is not meant +to be included in other projects and does not define its dependencies +in a way that is understood by tools like `dep`. The other `k8s.io` +packages are meant to be included, but [don’t follow semantic +versioning +yet]([https://github.com/kubernetes/kubernetes/issues/72638) or don’t +tag any releases (`k8s.io/kube-openapi`, `k8s.io/utils`). + +PMEM-CSI uses [dep](https://golang.github.io/dep/). It’s +[Gopkg.toml](https://github.com/intel/pmem-csi/blob/0ad8251c064b1010c91e7fc1dd423b95d5594bba/Gopkg.toml) +file is a good starting point. It enables pruning (not enabled in dep +by default) and locks certain projects onto versions that are +compatible with the Kubernetes version that is used. When `dep` +doesn’t pick a compatible version, then checking Kubernetes’ +[Godeps.json](https://github.com/kubernetes/kubernetes/blob/master/Godeps/Godeps.json) +helps to determine which revision might be the right one. + +### Compiling and running the test suite + +`go test ./test/e2e -args -help` is the fastest way to test that the +test suite compiles. + +Once it does compile and a cluster has been set up, the command `go +test -timeout=0 -v ./test/e2e -ginkgo.v` runs all tests. In order to +run tests in parallel, use the `ginkgo -p ./test/e2e` command instead. + +## Getting involved + +The Kubernetes E2E framework is owned by the testing-commons +sub-project in +[SIG-testing](https://github.com/kubernetes/community/tree/master/sig-testing). See +that page for contact information. + +There are various tasks that could be worked on, including but not +limited to: + +* Moving test/e2e/framework into a staging repo and restructuring it + so that it is more modular + ([#74352](https://github.com/kubernetes/kubernetes/issues/74352)). +* Simplifying `e2e.go` by moving more of its code into + `test/e2e/framework` + ([#74353](https://github.com/kubernetes/kubernetes/issues/74353)). +* Removing provider-specific code from the Kubernetes E2E test suite + ([#70194](https://github.com/kubernetes/kubernetes/issues/70194)). + +Special thanks to the reviewers of this article: + +- Olev Kartau (https://github.com/okartau) +- Mary Camp (https://github.com/MCamp859) diff --git a/content/en/case-studies/blackrock/index.html b/content/en/case-studies/blackrock/index.html index 96b66334d9..6bef0ec708 100644 --- a/content/en/case-studies/blackrock/index.html +++ b/content/en/case-studies/blackrock/index.html @@ -69,7 +69,7 @@ css: /css/style_blackrock.css Made up of managers from technology, infrastructure, production operations, development and information security, Francis’s team was able to look at the problem holistically and come up with a solution that made sense for BlackRock. "Our initial straw man was that we were going to build everything using Ansible and run it all using some completely different distributed environment," says Francis. "That would have been absolutely the wrong thing to do. Had we gone off on our own as the dev team and developed this solution, it would have been a very different product. And it would have been very expensive. We would not have gone down the route of running under our existing orchestration system. Because we don’t understand it. These guys [in operations and infrastructure] understand it. Having the multidisciplinary team allowed us to get to the right solutions and that actually meant we didn’t build anywhere near the amount we thought we were going to end up building."

In search of a solution in which they could manage usage on a user-by-user level, Francis’s team gravitated to Red Hat’s OpenShift Kubernetes offering. The company had already experimented with other cloud-native environments, but the team liked that Kubernetes was open source, and "we felt the winds were blowing in the direction of Kubernetes long term," says Francis. "Typically we make technology choices that we believe are going to be here in 5-10 years’ time, in some form. And right now, in this space, Kubernetes feels like the one that’s going to be there." Adds Uri Morris, Vice President of Production Operations: "When you see that the non-Google committers to Kubernetes overtook the Google committers, that’s an indicator of the momentum."

Once that decision was made, the major challenge was figuring out how to make Kubernetes work within BlackRock’s existing framework. "It’s about understanding how we can operate, manage and support a platform like this, in addition to tacking it onto our existing technology platform," says Project Manager Michael Maskallis. "All the controls we have in place, the change management process, the software development lifecycle, onboarding processes we go through—how can we do all these things?"

- The first (anticipated) speed bump was working around issues behind BlackRock’s corporate firewalls. "One of our challenges is there are no firewalls in most open source software," says Francis. "So almost all install scripts fail in some bizarre way, and pulling down packages doesn’t necessarily work." The team ran into these types of problems using Minikube and did a few small pushes back to the open source project. + The first (anticipated) speed bump was working around issues behind BlackRock’s corporate firewalls. "One of our challenges is there are no firewalls in most open source software," says Francis. "So almost all install scripts fail in some bizarre way, and pulling down packages doesn’t necessarily work." The team ran into these types of problems using Minikube and did a few small pushes back to the open source project. diff --git a/content/en/case-studies/nav/index.html b/content/en/case-studies/nav/index.html new file mode 100644 index 0000000000..3f15678a31 --- /dev/null +++ b/content/en/case-studies/nav/index.html @@ -0,0 +1,92 @@ +--- +title: Nav Case Study +case_study_styles: true +cid: caseStudies +css: /css/style_case_studies.css +--- + +
+

CASE STUDY:
How A Startup Reduced Its Infrastructure Costs by 50% With Kubernetes +

+ +
+ +
+ Company  Nav     Location  Salt Lake City, Utah, and San Mateo, California     Industry  Financial services for businesses +
+ +
+
+
+
+

+

Challenge

+ Founded in 2012, Nav provides small business owners with access to their business credit scores from all three major commercial credit bureaus—Equifax, Experian and Dun & Bradstreet—and financing options that best fit their needs. Five years in, the startup was growing rapidly, and “our cloud environments were getting very large, and our usage of those environments was extremely low, like under 1%,” says Director of Engineering Travis Jeppson. “We wanted our usage of cloud environments to be more tightly coupled with what we actually needed, so we started looking at containerization and orchestration to help us be able to run workloads that were distinct from one another but could share a similar resource pool.” +

+

Solution

+ After evaluating a number of orchestration solutions, the Nav team decided to adopt Kubernetes running on AWS. The strength of the community around Kubernetes was a strong draw, as well as its Google provenance. Plus, “the other solutions tended to be fairly heavy-handed, really complex, really large, and really hard to manage just off the bat,” says Jeppson. “Kubernetes gave us a very simple way to be able to step into an orchestration solution that fit our needs at the time, but also the extensibility of it allowed us to be able to grow with it and be able to build in more features and functionality later on.” +

+

Impact

+ The four-person team got Kubernetes up and running in six months, and the full migration of Nav’s 25 microservices was completed in another six months. The results have been impressive: Resource utilization, which led the company on this path in the first place, has increased from 1% to 40%. Launching a new service used to take two developers two weeks; now it takes only one developer less than 10 minutes. Deployments have increased 5x. And the company is saving 50% in infrastructure costs. + +
+
+
+
+
+ +

+ "Kubernetes gave us a very simple way to be able to step into an orchestration solution that fit our needs at the time, but also the extensibility of it allowed us to be able to grow with it and be able to build in more features and functionality later on." +

- Travis Jeppson, Director of Engineering, Nav +
+
+
+
+

Founded in 2012, Nav provides small business owners with access to their business credit scores from all three major commercial credit bureaus—Equifax, Experian and Dun & Bradstreet—as well as details on their businesses’ financial health and financing options that best fit their needs. Its mission boils down to this, says Director of Engineering Travis Jeppson: “to increase the success rate of small businesses.”

+ A couple of years ago, Nav recognized an obstacle in its own path to success. The business was growing rapidly, and “our cloud environments were getting very large, and our usage of those environments was extremely low, like under 1%,” says Jeppson. “Most of the problem was around the ability to scale. We were just throwing money at it. ‘Let’s just spin up more servers. Let’s just do more things in order to handle an increased load.’ And with us being a startup, that could lead to our demise. We don’t have the money to burn on that kind of stuff.”

+ Plus, every new service had to go through 10 different people, taking an unacceptably long two weeks to launch. “All of the patch management and the server management was done very manually, and so we all had to watch it and maintain it really well,” adds Jeppson. “It was just a very troublesome system.” + + +
+
+
+
+ "The community is absolutely vital: being able to pass ideas around, talk about a lot of the similar challenges that we’re all facing, and just get help. I like that we’re able to tackle the same problems for different reasons but help each other along the way."

- Travis Jeppson, Director of Engineering, Nav + +
+
+
+
+ Jeppson had worked with containers at his previous job, and pitched that technology to Nav’s management as a solution to these problems. He got the green light in early 2017. “We wanted our usage of cloud environments to be more tightly coupled with what we actually needed, so we started looking at containerization and orchestration to help us be able to run workloads that were distinct from one another but could share a similar resource pool,” he says.

+ After evaluating a number of orchestration solutions, the company decided to adopt Kubernetes running on AWS. The strength of the community around Kubernetes was a strong draw, as was its Google origins. Additionally, “the other solutions tended to be fairly heavy-handed, really complex, really large, and really hard to manage just off the bat,” says Jeppson. “Kubernetes gave us a very simple way to be able to step into an orchestration solution that fit our needs at the time, but the extensibility of it would also allow us to grow with it and build in more features and functionality later on.”

+ Jeppson’s four-person Engineering Services team got Kubernetes up and running in six months (they decided to use Kubespray to spin up clusters), and the full migration of Nav’s 25 microservices and one primary monolith was completed in another six months. “We couldn’t rewrite everything; we couldn’t stop,” he says. “We had to stay up, we had to stay available, and we had to have minimal amount of downtime. So we got really comfortable around our building pipeline, our metrics and logging, and then around Kubernetes itself: how to launch it, how to upgrade it, how to service it. And we moved little by little.” +
+
+
+
+ “Kubernetes has brought so much value to Nav by allowing all of these new freedoms that we had just never had before.”

- Travis Jeppson, Director of Engineering, Nav +
+
+ +
+ +
+ A crucial part of the process involved educating Nav’s 50 engineers and being transparent regarding the new workflow as well as the roadmap for the migration. Jeppson did regular presentations along the way, and a week of four-hours-a-day labs for the entire staff of engineers. He then created a repository in GitLab to house all of the information. “We showed all the frontend and backend developers how to go in, create their own namespace using kubectl, all themselves,” he says. “Now, a lot of times, they just come to us and say, ‘This is ready.’ We click a little button in GitLab to allow it to release into production, and they’re off to the races.”

+ Since the migration was completed in early 2018, the results have been impressive: Resource utilization, which led the company on this path in the first place, has increased from 1% to 40%. Launching a new service used to take two developers two weeks; now it takes only one developer less than 10 minutes. Deployments have increased 5x, from 10 a day to 50 a day. And the company is saving 50% in infrastructure costs on the computational side. “Next we want to go in to address the database side, and once we do that, then we’re going to continue to drop that cost quite a bit more,” says Jeppson.

+ Kubernetes has also helped Nav with its compliance needs. Before, “we had to map one application to one server, mostly due to different compliance regulations around data,” Jeppson says. “With the Kubernetes API, we could add in network policies and segregate that data and restrict it if needed.” The company segregates its cluster into an unrestricted zone and a restricted zone, which has its own set of nodes where data protection happens. The company also uses the Twistlock tool to ensure security, “and that makes it a lot easier to sleep at night,” he adds. + +
+ +
+
+"We’re talking four to 10 times the amount of traffic that we handle now, and it’s just like, 'Oh, yeah. We’re good. Kubernetes handles this for us.'"

- Travis Jeppson, Director of Engineering, Nav
+
+ +
+ With Kubernetes in place, the Nav team also started improving the system’s metrics and logging by adopting Prometheus. “Prometheus created a standard around metrics that was really easy for a developer to adopt,” says Jeppson. “They have the freedom to display what they want, to do what they need, and keep their codebase clean, and that to us was absolutely a must.”

+ Next up for Nav in the coming year: looking at tracing, storage, and service mesh. They’re currently evaluating Envoy, OpenTracing, and Jaeger after spending much of KubeCon talking to other companies. “The community is absolutely vital: being able to pass ideas around, talk about a lot of the similar challenges that we’re all facing, and just get help. I like that we’re able to tackle the same problems for different reasons but help each other along the way,” says Jeppson. “There’s still so, so much to do around scalability, around being able to really fully adopt a cloud native solution.”

+ Of course, it all starts with Kubernetes. With that technology, Jeppson’s team has built a platform that allows Nav to scale, and that “has brought so much value to Nav by allowing all of these new freedoms that we had just never had before,” he says.

+ Conversations about new products used to be bogged down by the fact they’d have to wait six months to get an environment set up with isolation and then figure out how to handle spikes of traffic. “But now it’s just nothing to us,” says Jeppson. “We’re talking four to 10 times the amount of traffic that we handle now, and it’s just like, ‘Oh, yeah. We’re good. Kubernetes handles this for us.’” + +
+
diff --git a/content/en/case-studies/nav/nav_featured_logo.png b/content/en/case-studies/nav/nav_featured_logo.png new file mode 100644 index 0000000000..22d96017c4 Binary files /dev/null and b/content/en/case-studies/nav/nav_featured_logo.png differ diff --git a/content/en/case-studies/pinterest/index.html b/content/en/case-studies/pinterest/index.html index 56bf0ecbc5..0aa2381aa1 100644 --- a/content/en/case-studies/pinterest/index.html +++ b/content/en/case-studies/pinterest/index.html @@ -26,28 +26,27 @@ quote: >
+

Challenge

After eight years in existence, Pinterest had grown into 1,000 microservices and multiple layers of infrastructure and diverse set-up tools and platforms. In 2016 the company launched a roadmap towards a new compute platform, led by the vision of creating the fastest path from an idea to production, without making engineers worry about the underlying infrastructure. -
+

Solution

The first phase involved moving services to Docker containers. Once these services went into production in early 2017, the team began looking at orchestration to help create efficiencies and manage them in a decentralized way. After an evaluation of various solutions, Pinterest went with Kubernetes. -
- -
+

Impact

"By moving to Kubernetes the team was able to build on-demand scaling and new failover policies, in addition to simplifying the overall deployment and management of a complicated piece of infrastructure such as Jenkins," says Micheal Benedict, Product Manager for the Cloud and the Data Infrastructure Group at Pinterest. "We not only saw reduced build times but also huge efficiency wins. For instance, the team reclaimed over 80 percent of capacity during non-peak hours. As a result, the Jenkins Kubernetes cluster now uses 30 percent less instance-hours per-day when compared to the previous static cluster." - +
-
-
-
+
+ +


"So far it’s been good, especially the elasticity around how we can configure our Jenkins workloads on that Kubernetes shared cluster. That is the win we were pushing for."

— Micheal Benedict, Product Manager for the Cloud and the Data Infrastructure Group at Pinterest
diff --git a/content/en/docs/concepts/cluster-administration/cloud-providers.md b/content/en/docs/concepts/cluster-administration/cloud-providers.md index ff3df214b4..e468092d01 100644 --- a/content/en/docs/concepts/cluster-administration/cloud-providers.md +++ b/content/en/docs/concepts/cluster-administration/cloud-providers.md @@ -338,7 +338,7 @@ Kubernetes network plugin and should appear in the `[Router]` section of the the default router for the node network). This value is required to use [kubenet] on OpenStack. -[kubenet]: https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#kubenet +[kubenet]: /docs/concepts/cluster-administration/network-plugins/#kubenet {{% /capture %}} diff --git a/content/en/docs/concepts/cluster-administration/federation.md b/content/en/docs/concepts/cluster-administration/federation.md index 501568531b..5f103db328 100644 --- a/content/en/docs/concepts/cluster-administration/federation.md +++ b/content/en/docs/concepts/cluster-administration/federation.md @@ -70,7 +70,7 @@ some caveats: Federations of Kubernetes Clusters can include clusters running in different cloud providers (e.g. Google Cloud, AWS), and on-premises -(e.g. on OpenStack). [Kubefed](https://kubernetes.io/docs/tasks/federation/set-up-cluster-federation-kubefed/) is the recommended way to deploy federated clusters. +(e.g. on OpenStack). [Kubefed](/docs/tasks/federation/set-up-cluster-federation-kubefed/) is the recommended way to deploy federated clusters. Thereafter, your [API resources](#api-resources) can span different clusters and cloud providers. @@ -184,6 +184,3 @@ clusters up to 5000 nodes. See [Building Large Clusters](/docs/setup/cluster-lar * See this [Kubecon2018 Europe Federation-v2 prototype presentation](https://youtu.be/q27rbaX5Jis?t=7m20s) * See this [Federation-v2 Userguide](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md) {{% /capture %}} - - - diff --git a/content/en/docs/concepts/configuration/overview.md b/content/en/docs/concepts/configuration/overview.md index b7d74b4abe..d1069d34d2 100644 --- a/content/en/docs/concepts/configuration/overview.md +++ b/content/en/docs/concepts/configuration/overview.md @@ -46,7 +46,10 @@ This is a living document. If you think of something that is not on this list bu FOO_SERVICE_PORT= ``` - If you are writing code that talks to a Service, don't use these environment variables; use the [DNS name of the Service](/docs/concepts/services-networking/dns-pod-service/) instead. Service environment variables are provided only for older software which can't be modified to use DNS lookups, and are a much less flexible way of accessing Services. + *This does imply an ordering requirement* - any `Service` that a `Pod` wants to access must be created before the `Pod` itself, or else the environment variables will not be populated. DNS does not have this restriction. + +- An optional (though strongly recommended) [cluster add-on](/docs/concepts/cluster-administration/addons/) is a DNS server. The +DNS server watches the Kubernetes API for new `Services` and creates a set of DNS records for each. If DNS has been enabled throughout the cluster then all `Pods` should be able to do name resolution of `Services` automatically. - Don't specify a `hostPort` for a Pod unless it is absolutely necessary. When you bind a Pod to a `hostPort`, it limits the number of places the Pod can be scheduled, because each <`hostIP`, `hostPort`, `protocol`> combination must be unique. If you don't specify the `hostIP` and `protocol` explicitly, Kubernetes will use `0.0.0.0` as the default `hostIP` and `TCP` as the default `protocol`. diff --git a/content/en/docs/concepts/configuration/pod-priority-preemption.md b/content/en/docs/concepts/configuration/pod-priority-preemption.md index bcb1fab197..9ccfa2d53c 100644 --- a/content/en/docs/concepts/configuration/pod-priority-preemption.md +++ b/content/en/docs/concepts/configuration/pod-priority-preemption.md @@ -38,7 +38,7 @@ Kubernetes Version | Priority and Preemption State | Enabled by default {{< warning >}}In a cluster where not all users are trusted, a malicious user could create pods at the highest possible priorities, causing other pods to be evicted/not get scheduled. To resolve this issue, -[ResourceQuota](https://kubernetes.io/docs/concepts/policy/resource-quotas/) is +[ResourceQuota](/docs/concepts/policy/resource-quotas/) is augmented to support Pod priority. An admin can create ResourceQuota for users at specific priority levels, preventing them from creating pods at high priorities. This feature is in beta since Kubernetes 1.12. diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md index b6911c5fd9..31b3aca072 100644 --- a/content/en/docs/concepts/configuration/secret.md +++ b/content/en/docs/concepts/configuration/secret.md @@ -623,10 +623,10 @@ start until all the pod's volumes are mounted. Create a secret containing some ssh keys: ```shell -kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa +kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub ``` ``` ---from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub +secret "ssh-key-secret" created ``` {{< caution >}} @@ -676,10 +676,8 @@ credentials. Make the secrets: ```shell -kubectl create secret generic prod-db-secret --from-literal=username=produser ---from-literal=password=Y4nys7f11 +kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11 ``` - ``` secret "prod-db-secret" created ``` diff --git a/content/en/docs/concepts/containers/runtime-class.md b/content/en/docs/concepts/containers/runtime-class.md index 861ce41d9e..b8363b2e13 100644 --- a/content/en/docs/concepts/containers/runtime-class.md +++ b/content/en/docs/concepts/containers/runtime-class.md @@ -89,7 +89,7 @@ spec: {{< note >}} It is recommended that RuntimeClass write operations (create/update/patch/delete) be restricted to the cluster administrator. This is typically the default. See [Authorization -Overview](https://kubernetes.io/docs/reference/access-authn-authz/authorization/) for more details. +Overview](/docs/reference/access-authn-authz/authorization/) for more details. {{< /note >}} ### Usage diff --git a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index 84f3c70209..fc70413535 100644 --- a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -178,8 +178,8 @@ Aggregated APIs offer more advanced API features and customization of other feat | Multi-versioning | Allows serving the same object through two API versions. Can help ease API changes like renaming fields. Less important if you control your client versions. | [Yes](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning) | Yes | | Custom Storage | If you need storage with a different performance mode (for example, time-series database instead of key-value store) or isolation for security (for example, encryption secrets or different | No | Yes | | Custom Business Logic | Perform arbitrary checks or actions when creating, reading, updating or deleting an object | Yes, using [Webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks). | Yes | -| Scale Subresource | Allows systems like HorizontalPodAutoscaler and PodDisruptionBudget interact with your new resource | [Yes](https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#scale-subresource) | Yes | -| Status Subresource |
  • Finer-grained access control: user writes spec section, controller writes status section.
  • Allows incrementing object Generation on custom resource data mutation (requires separate spec and status sections in the resource)
| [Yes](https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | Yes | +| Scale Subresource | Allows systems like HorizontalPodAutoscaler and PodDisruptionBudget interact with your new resource | [Yes](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#scale-subresource) | Yes | +| Status Subresource |
  • Finer-grained access control: user writes spec section, controller writes status section.
  • Allows incrementing object Generation on custom resource data mutation (requires separate spec and status sections in the resource)
| [Yes](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | Yes | | Other Subresources | Add operations other than CRUD, such as "logs" or "exec". | No | Yes | | strategic-merge-patch | The new endpoints support PATCH with `Content-Type: application/strategic-merge-patch+json`. Useful for updating objects that may be modified both locally, and by the server. For more information, see ["Update API Objects in Place Using kubectl patch"](/docs/tasks/run-application/update-api-object-kubectl-patch/) | No | Yes | | Protocol Buffers | The new resource supports clients that want to use Protocol Buffers | No | Yes | diff --git a/content/en/docs/concepts/services-networking/dns-pod-service.md b/content/en/docs/concepts/services-networking/dns-pod-service.md index 5c519d479a..d843027dfc 100644 --- a/content/en/docs/concepts/services-networking/dns-pod-service.md +++ b/content/en/docs/concepts/services-networking/dns-pod-service.md @@ -112,7 +112,7 @@ spec: hostname: busybox-1 subdomain: default-subdomain containers: - - image: busybox + - image: busybox:1.28 command: - sleep - "3600" @@ -128,7 +128,7 @@ spec: hostname: busybox-2 subdomain: default-subdomain containers: - - image: busybox + - image: busybox:1.28 command: - sleep - "3600" @@ -192,7 +192,7 @@ metadata: namespace: default spec: containers: - - image: busybox + - image: busybox:1.28 command: - sleep - "3600" diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index 3723ca6bbe..a6bc859b79 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -973,7 +973,7 @@ to expose HTTP / HTTPS services. {{< feature-state for_k8s_version="v1.1" state="stable" >}} -If your cloud provider supports it (eg, [AWS](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#aws)), +If your cloud provider supports it (eg, [AWS](/docs/concepts/cluster-administration/cloud-providers/#aws)), you can use a Service in LoadBalancer mode to configure a load balancer outside of Kubernetes itself, that will forward connections prefixed with [PROXY protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt). diff --git a/content/en/docs/concepts/workloads/controllers/jobs-run-to-completion.md b/content/en/docs/concepts/workloads/controllers/jobs-run-to-completion.md index 4c22be980c..18e213f17e 100644 --- a/content/en/docs/concepts/workloads/controllers/jobs-run-to-completion.md +++ b/content/en/docs/concepts/workloads/controllers/jobs-run-to-completion.md @@ -249,7 +249,7 @@ spec: restartPolicy: Never ``` -Note that both the Job spec and the [Pod template spec](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/#detailed-behavior) within the Job have an `activeDeadlineSeconds` field. Ensure that you set this field at the proper level. +Note that both the Job spec and the [Pod template spec](/docs/concepts/workloads/pods/init-containers/#detailed-behavior) within the Job have an `activeDeadlineSeconds` field. Ensure that you set this field at the proper level. ## Clean Up Finished Jobs Automatically diff --git a/content/en/docs/concepts/workloads/controllers/statefulset.md b/content/en/docs/concepts/workloads/controllers/statefulset.md index e83a4f3c8b..ae390739ab 100644 --- a/content/en/docs/concepts/workloads/controllers/statefulset.md +++ b/content/en/docs/concepts/workloads/controllers/statefulset.md @@ -48,6 +48,10 @@ provides a set of stateless replicas. Controllers such as * Deleting and/or scaling a StatefulSet down will *not* delete the volumes associated with the StatefulSet. This is done to ensure data safety, which is generally more valuable than an automatic purge of all related StatefulSet resources. * StatefulSets currently require a [Headless Service](/docs/concepts/services-networking/service/#headless-services) to be responsible for the network identity of the Pods. You are responsible for creating this Service. * StatefulSets do not provide any guarantees on the termination of pods when a StatefulSet is deleted. To achieve ordered and graceful termination of the pods in the StatefulSet, it is possible to scale the StatefulSet down to 0 prior to deletion. +* When using [Rolling Updates](#rolling-updates) with the default + [Pod Management Policy](#pod-management-policies) (`OrderedReady`), + it's possible to get into a broken state that requires + [manual intervention to repair](#forced-rollback). ## Components The example below demonstrates the components of a StatefulSet. @@ -241,6 +245,26 @@ updates to its `.spec.template` will not be propagated to its Pods. In most cases you will not need to use a partition, but they are useful if you want to stage an update, roll out a canary, or perform a phased roll out. +#### Forced Rollback + +When using [Rolling Updates](#rolling-updates) with the default +[Pod Management Policy](#pod-management-policies) (`OrderedReady`), +it's possible to get into a broken state that requires manual intervention to repair. + +If you update the Pod template to a configuration that never becomes Running and +Ready (for example, due to a bad binary or application-level configuration error), +StatefulSet will stop the rollout and wait. + +In this state, it's not enough to revert the Pod template to a good configuration. +Due to a [known issue](https://github.com/kubernetes/kubernetes/issues/67250), +StatefulSet will continue to wait for the broken Pod to become Ready +(which never happens) before it will attempt to revert it back to the working +configuration. + +After reverting the template, you must also delete any Pods that StatefulSet had +already attempted to run with the bad configuration. +StatefulSet will then begin to recreate the Pods using the reverted template. + {{% /capture %}} {{% capture whatsnext %}} diff --git a/content/en/docs/concepts/workloads/pods/init-containers.md b/content/en/docs/concepts/workloads/pods/init-containers.md index d4592138de..70b5a60aa9 100644 --- a/content/en/docs/concepts/workloads/pods/init-containers.md +++ b/content/en/docs/concepts/workloads/pods/init-containers.md @@ -112,19 +112,19 @@ metadata: pod.beta.kubernetes.io/init-containers: '[ { "name": "init-myservice", - "image": "busybox", + "image": "busybox:1.28", "command": ["sh", "-c", "until nslookup myservice; do echo waiting for myservice; sleep 2; done;"] }, { "name": "init-mydb", - "image": "busybox", + "image": "busybox:1.28", "command": ["sh", "-c", "until nslookup mydb; do echo waiting for mydb; sleep 2; done;"] } ]' spec: containers: - name: myapp-container - image: busybox + image: busybox:1.28 command: ['sh', '-c', 'echo The app is running! && sleep 3600'] ``` @@ -140,14 +140,14 @@ metadata: spec: containers: - name: myapp-container - image: busybox + image: busybox:1.28 command: ['sh', '-c', 'echo The app is running! && sleep 3600'] initContainers: - name: init-myservice - image: busybox + image: busybox:1.28 command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;'] - name: init-mydb - image: busybox + image: busybox:1.28 command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;'] ``` diff --git a/content/en/docs/contribute/generate-ref-docs/federation-api.md b/content/en/docs/contribute/generate-ref-docs/federation-api.md index 34365bea76..3921fba084 100644 --- a/content/en/docs/contribute/generate-ref-docs/federation-api.md +++ b/content/en/docs/contribute/generate-ref-docs/federation-api.md @@ -73,10 +73,10 @@ repository. These files are published at [kubernetes.io/docs/reference](/docs/reference/): -* [Federation API v1 Operations](https://kubernetes.io/docs/reference/federation/v1/operations/) -* [Federation API v1 Definitions](https://kubernetes.io/docs/reference/federation/v1/definitions/) -* [Federation API extensions/v1beta1 Operations](https://kubernetes.io/docs/reference/federation/extensions/v1beta1/operations/) -* [Federation API extensions/v1beta1 Definitions](https://kubernetes.io/docs/reference/federation/extensions/v1beta1/definitions/) +* [Federation API v1 Operations](/docs/reference/federation/v1/operations/) +* [Federation API v1 Definitions](/docs/reference/federation/v1/definitions/) +* [Federation API extensions/v1beta1 Operations](/docs/reference/federation/extensions/v1beta1/operations/) +* [Federation API extensions/v1beta1 Definitions](/docs/reference/federation/extensions/v1beta1/definitions/) {{% /capture %}} @@ -87,6 +87,3 @@ These files are published at * [Generating Reference Pages for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/) {{% /capture %}} - - - diff --git a/content/en/docs/contribute/generate-ref-docs/kubernetes-components.md b/content/en/docs/contribute/generate-ref-docs/kubernetes-components.md index b19f060714..cca0381185 100644 --- a/content/en/docs/contribute/generate-ref-docs/kubernetes-components.md +++ b/content/en/docs/contribute/generate-ref-docs/kubernetes-components.md @@ -126,7 +126,7 @@ directory. The tool performs the following steps: When the Markdown files are in your local clone of the `kubernetes/website` repository, you can submit them in a -[pull request](https://kubernetes.io/docs/home/contribute/create-pull-request/) +[pull request](/docs/home/contribute/create-pull-request/) to `kubernetes/website`. ## Customizing the config file diff --git a/content/en/docs/contribute/intermediate.md b/content/en/docs/contribute/intermediate.md index 2ef7278621..c5b680f7c4 100644 --- a/content/en/docs/contribute/intermediate.md +++ b/content/en/docs/contribute/intermediate.md @@ -70,7 +70,7 @@ and the [code of conduct](/community/code-of-conduct/) To see all open PRs, go to the **Pull Requests** tab in the Github repository. A PR is eligible for review when it meets all of the following criteria: -- Has the `cnf-cla:yes` tag +- Has the `cncf-cla:yes` tag - Does not have WIP in the description - Does not a have tag including the phrase `do-not-merge` - Has no merge conflicts diff --git a/content/en/docs/contribute/localization.md b/content/en/docs/contribute/localization.md index db3ef4e980..bdb3fabf8e 100644 --- a/content/en/docs/contribute/localization.md +++ b/content/en/docs/contribute/localization.md @@ -45,7 +45,7 @@ cd website ``` {{< note >}} -Contributors to `k/website` must [create a fork](https://kubernetes.io/docs/contribute/start/#improve-existing-content) from which to open pull requests. For localizations, we ask additionally that: +Contributors to `k/website` must [create a fork](/docs/contribute/start/#improve-existing-content) from which to open pull requests. For localizations, we ask additionally that: 1. Team approvers open development branches directly from https://github.com/kubernetes/website. 2. Localization contributors work from forks, with branches based on the current development branch. @@ -109,12 +109,12 @@ At a minimum, all localizations must include: Description | URLs -----|----- -Home | [All heading and subheading URLs](https://kubernetes.io/docs/home/) -Setup | [All heading and subheading URLs](https://kubernetes.io/docs/setup/) -Tutorials | [Kubernetes Basics](https://kubernetes.io/docs/tutorials/kubernetes-basics/), [Hello Minikube](https://kubernetes.io/docs/tutorials/stateless-application/hello-minikube/) +Home | [All heading and subheading URLs](/docs/home/) +Setup | [All heading and subheading URLs](/docs/setup/) +Tutorials | [Kubernetes Basics](/docs/tutorials/kubernetes-basics/), [Hello Minikube](/docs/tutorials/stateless-application/hello-minikube/) Site strings | [All site strings in a new localized TOML file](https://github.com/kubernetes/website/tree/master/i18n) -Translated documents must reside in their own `content/**/` subdirectory, but otherwise follow the same URL path as the English source. For example, to prepare the [Kubernetes Basics](https://kubernetes.io/docs/tutorials/kubernetes-basics/) tutorial for translation into German, create a subfolder under the `content/de/` folder and copy the English source: +Translated documents must reside in their own `content/**/` subdirectory, but otherwise follow the same URL path as the English source. For example, to prepare the [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) tutorial for translation into German, create a subfolder under the `content/de/` folder and copy the English source: ```shell mkdir -p content/de/docs/tutorials diff --git a/content/en/docs/contribute/style/write-new-topic.md b/content/en/docs/contribute/style/write-new-topic.md index 4c92eb25f3..6d9572a8f7 100644 --- a/content/en/docs/contribute/style/write-new-topic.md +++ b/content/en/docs/contribute/style/write-new-topic.md @@ -53,7 +53,7 @@ has filename `http-proxy-access-api.md`. You don't need to put "kubernetes" in the filename, because "kubernetes" is already in the URL for the topic, for example: - http://kubernetes.io/docs/tasks/access-kubernetes-api/http-proxy-access-api/ + /docs/tasks/access-kubernetes-api/http-proxy-access-api/ ## Adding the topic title to the front matter @@ -176,5 +176,3 @@ image format is SVG. * Learn about [staging your changes](/docs/home/contribute/stage-documentation-changes/). * Learn about [creating a pull request](/docs/home/contribute/create-pull-request/). {{% /capture %}} - - diff --git a/content/en/docs/getting-started-guides/ubuntu/installation.md b/content/en/docs/getting-started-guides/ubuntu/installation.md index ab5b42a76d..eb01d37fbc 100644 --- a/content/en/docs/getting-started-guides/ubuntu/installation.md +++ b/content/en/docs/getting-started-guides/ubuntu/installation.md @@ -208,7 +208,7 @@ Copy the kubeconfig file to the default location. juju scp kubernetes-master/0:/home/ubuntu/config ~/.kube/config ``` -The next step is to install the kubectl client on your local machine. The recommended way to do this on Ubuntu is using the kubectl snap ([https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-with-snap-on-ubuntu](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-with-snap-on-ubuntu)). +The next step is to install the kubectl client on your local machine. The recommended way to do this on Ubuntu is using the kubectl snap ([/docs/tasks/tools/install-kubectl/#install-with-snap-on-ubuntu](/docs/tasks/tools/install-kubectl/#install-with-snap-on-ubuntu)). The following command should be run on the machine you wish to use to control the kubernetes cluster: @@ -297,5 +297,3 @@ project on github.com: Feature requests, bug reports, pull requests and feedback are appreciated. {{% /capture %}} - - diff --git a/content/en/docs/getting-started-guides/ubuntu/rancher.md b/content/en/docs/getting-started-guides/ubuntu/rancher.md index f2d77c11f4..dea8d44348 100644 --- a/content/en/docs/getting-started-guides/ubuntu/rancher.md +++ b/content/en/docs/getting-started-guides/ubuntu/rancher.md @@ -14,7 +14,7 @@ The original documentation for this integration can be found at [https://github. {{% capture prerequisites %}} To use this guide, you must have a working kubernetes cluster that was deployed using Canonical's juju. -The full instructions for deploying Kubernetes with juju can be found at [https://kubernetes.io/docs/getting-started-guides/ubuntu/installation/](https://kubernetes.io/docs/getting-started-guides/ubuntu/installation/). +The full instructions for deploying Kubernetes with juju can be found at [/docs/getting-started-guides/ubuntu/installation/](/docs/getting-started-guides/ubuntu/installation/). {{% /capture %}} @@ -358,5 +358,3 @@ You can remove Rancher from your cluster using kubectl. Deleting constructs in K kubectl delete -f cdk-rancher-nodeport.yaml ``` {{% /capture %}} - - diff --git a/content/en/docs/getting-started-guides/ubuntu/troubleshooting.md b/content/en/docs/getting-started-guides/ubuntu/troubleshooting.md index 925e816bee..9c40c49fef 100644 --- a/content/en/docs/getting-started-guides/ubuntu/troubleshooting.md +++ b/content/en/docs/getting-started-guides/ubuntu/troubleshooting.md @@ -175,7 +175,5 @@ This is caused by the API load balancer not forwarding ports in the context of t ## Logging and monitoring -By default there is no log aggregation of the Kubernetes nodes, each node logs locally. Please read over the [logging](https://kubernetes.io/docs/getting-started-guides/ubuntu/logging/) page for more information. +By default there is no log aggregation of the Kubernetes nodes, each node logs locally. Please read over the [logging](/docs/getting-started-guides/ubuntu/logging/) page for more information. {{% /capture %}} - - diff --git a/content/en/docs/getting-started-guides/windows/_index.md b/content/en/docs/getting-started-guides/windows/_index.md index 5d0ca0d122..9f27564b07 100644 --- a/content/en/docs/getting-started-guides/windows/_index.md +++ b/content/en/docs/getting-started-guides/windows/_index.md @@ -272,14 +272,14 @@ Use your preferred method to start Kubernetes cluster on Linux. Please note that ## Support for kubeadm join -If your cluster has been created by [kubeadm](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/), +If your cluster has been created by [kubeadm](/docs/setup/independent/create-cluster-kubeadm/), and your networking is setup correctly using one of the methods listed above (networking is setup outside of kubeadm), you can use kubeadm to add a Windows node to your cluster. At a high level, you first have to initialize the master with kubeadm (Linux), then set up the CNI based networking (outside of kubeadm), and finally start joining Windows or Linux worker nodes to the cluster. For additional documentation and reference material, visit the kubeadm link above. The kubeadm binary can be found at [Kubernetes Releases](https://github.com/kubernetes/kubernetes/releases), inside the node binaries archive. Adding a Windows node is not any different than adding a Linux node: `kubeadm.exe join --token : --discovery-token-ca-cert-hash sha256:` -See [joining-your-nodes](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/#joining-your-nodes) for more details. +See [joining-your-nodes](/docs/setup/independent/create-cluster-kubeadm/#joining-your-nodes) for more details. ## Supported Features diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md b/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md index 88d1359e69..137b38a2b3 100644 --- a/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md +++ b/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md @@ -111,7 +111,7 @@ containing the signing certificate, for example ### Initial bootstrap authentication In order for the bootstrapping kubelet to connect to kube-apiserver and request a certificate, it must first authenticate to the server. -You can use any [authenticator](https://kubernetes.io/docs/reference/access-authn-authz/authentication/) that can authenticate the kubelet. +You can use any [authenticator](/docs/reference/access-authn-authz/authentication/) that can authenticate the kubelet. While any authentication strategy can be used for the kubelet's initial bootstrap credentials, the following two authenticators are recommended for ease diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet.md b/content/en/docs/reference/command-line-tools-reference/kubelet.md index 2c2795eb9d..dc90116c31 100644 --- a/content/en/docs/reference/command-line-tools-reference/kubelet.md +++ b/content/en/docs/reference/command-line-tools-reference/kubelet.md @@ -405,7 +405,7 @@ kubelet [flags] --enforce-node-allocatable stringSlice - A comma separated list of levels of node allocatable enforcement to be enforced by kubelet. Acceptable options are 'pods', 'system-reserved' & 'kube-reserved'. If the latter two options are specified, '--system-reserved-cgroup' & '--kube-reserved-cgroup' must also be set respectively. See https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/ for more details. (default [pods]) + A comma separated list of levels of node allocatable enforcement to be enforced by kubelet. Acceptable options are 'pods', 'system-reserved' & 'kube-reserved'. If the latter two options are specified, '--system-reserved-cgroup' & '--kube-reserved-cgroup' must also be set respectively. See /docs/tasks/administer-cluster/reserve-compute-resources/ for more details. (default [pods]) @@ -489,7 +489,7 @@ kubelet [flags] --experimental-allocatable-ignore-eviction - When set to 'true', Hard Eviction Thresholds will be ignored while calculating Node Allocatable. See https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/ for more details. [default=false] + When set to 'true', Hard Eviction Thresholds will be ignored while calculating Node Allocatable. See /docs/tasks/administer-cluster/reserve-compute-resources/ for more details. [default=false] @@ -707,7 +707,7 @@ kubelet [flags] --kube-reserved mapStringString - A set of ResourceName=ResourceQuantity (e.g. cpu=200m,memory=500Mi,ephemeral-storage=1Gi) pairs that describe resources reserved for kubernetes system components. Currently cpu, memory and local ephemeral storage for root file system are supported. See http://kubernetes.io/docs/user-guide/compute-resources for more detail. [default=none] + A set of ResourceName=ResourceQuantity (e.g. cpu=200m,memory=500Mi,ephemeral-storage=1Gi) pairs that describe resources reserved for kubernetes system components. Currently cpu, memory and local ephemeral storage for root file system are supported. See /docs/user-guide/compute-resources for more detail. [default=none] @@ -1092,7 +1092,7 @@ kubelet [flags] --system-reserved mapStringString - A set of ResourceName=ResourceQuantity (e.g. cpu=200m,memory=500Mi,ephemeral-storage=1Gi) pairs that describe resources reserved for non-kubernetes components. Currently only cpu and memory are supported. See http://kubernetes.io/docs/user-guide/compute-resources for more detail. [default=none] + A set of ResourceName=ResourceQuantity (e.g. cpu=200m,memory=500Mi,ephemeral-storage=1Gi) pairs that describe resources reserved for non-kubernetes components. Currently only cpu and memory are supported. See /docs/user-guide/compute-resources for more detail. [default=none] @@ -1167,6 +1167,3 @@ kubelet [flags] - - - diff --git a/content/en/docs/reference/federation/extensions/v1beta1/definitions.html b/content/en/docs/reference/federation/extensions/v1beta1/definitions.html index 333a1816cf..5d94a7d881 100755 --- a/content/en/docs/reference/federation/extensions/v1beta1/definitions.html +++ b/content/en/docs/reference/federation/extensions/v1beta1/definitions.html @@ -622,21 +622,21 @@ span.icon > [class^="icon-"], span.icon > [class*=" icon-"] { cursor: default; }

currentNumberScheduled

-

The number of nodes that are running at least 1 daemon pod and are supposed to run the daemon pod. More info: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/

+

The number of nodes that are running at least 1 daemon pod and are supposed to run the daemon pod. More info: /docs/concepts/workloads/controllers/daemonset/

true

integer (int32)

numberMisscheduled

-

The number of nodes that are running the daemon pod, but are not supposed to run the daemon pod. More info: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/

+

The number of nodes that are running the daemon pod, but are not supposed to run the daemon pod. More info: /docs/concepts/workloads/controllers/daemonset/

true

integer (int32)

desiredNumberScheduled

-

The total number of nodes that should be running the daemon pod (including nodes correctly running the daemon pod). More info: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/

+

The total number of nodes that should be running the daemon pod (including nodes correctly running the daemon pod). More info: /docs/concepts/workloads/controllers/daemonset/

true

integer (int32)

@@ -1134,7 +1134,7 @@ span.icon > [class^="icon-"], span.icon > [class*=" icon-"] { cursor: default; }

items

-

List of ReplicaSets. More info: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller

+

List of ReplicaSets. More info: /docs/concepts/workloads/controllers/replicationcontroller

true

v1beta1.ReplicaSet array

@@ -1377,28 +1377,28 @@ span.icon > [class^="icon-"], span.icon > [class*=" icon-"] { cursor: default; }

pdName

-

Unique name of the PD resource in GCE. Used to identify the disk in GCE. More info: https://kubernetes.io/docs/concepts/storage/volumes#gcepersistentdisk

+

Unique name of the PD resource in GCE. Used to identify the disk in GCE. More info: /docs/concepts/storage/volumes#gcepersistentdisk

true

string

fsType

-

Filesystem type of the volume that you want to mount. Tip: Ensure that the filesystem type is supported by the host operating system. Examples: "ext4", "xfs", "ntfs". Implicitly inferred to be "ext4" if unspecified. More info: https://kubernetes.io/docs/concepts/storage/volumes#gcepersistentdisk

+

Filesystem type of the volume that you want to mount. Tip: Ensure that the filesystem type is supported by the host operating system. Examples: "ext4", "xfs", "ntfs". Implicitly inferred to be "ext4" if unspecified. More info: /docs/concepts/storage/volumes#gcepersistentdisk

false

string

partition

-

The partition in the volume that you want to mount. If omitted, the default is to mount by volume name. Examples: For volume /dev/sda1, you specify the partition as "1". Similarly, the volume partition for /dev/sda is "0" (or you can leave the property empty). More info: https://kubernetes.io/docs/concepts/storage/volumes#gcepersistentdisk

+

The partition in the volume that you want to mount. If omitted, the default is to mount by volume name. Examples: For volume /dev/sda1, you specify the partition as "1". Similarly, the volume partition for /dev/sda is "0" (or you can leave the property empty). More info: /docs/concepts/storage/volumes#gcepersistentdisk

false

integer (int32)

readOnly

-

ReadOnly here will force the ReadOnly setting in VolumeMounts. Defaults to false. More info: https://kubernetes.io/docs/concepts/storage/volumes#gcepersistentdisk

+

ReadOnly here will force the ReadOnly setting in VolumeMounts. Defaults to false. More info: /docs/concepts/storage/volumes#gcepersistentdisk

false

boolean

false

@@ -1510,7 +1510,7 @@ span.icon > [class^="icon-"], span.icon > [class*=" icon-"] { cursor: default; }

name

-

Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

+

Name of the referent. More info: /docs/concepts/overview/working-with-objects/names/#names

false

string

@@ -1616,7 +1616,7 @@ span.icon > [class^="icon-"], span.icon > [class*=" icon-"] { cursor: default; }

name

-

Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

+

Name of the referent. More info: /docs/concepts/overview/working-with-objects/names/#names

false

string

@@ -1780,7 +1780,7 @@ span.icon > [class^="icon-"], span.icon > [class*=" icon-"] { cursor: default; }

name

-

Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

+

Name of the referent. More info: /docs/concepts/overview/working-with-objects/names/#names

false

string

@@ -1923,7 +1923,7 @@ span.icon > [class^="icon-"], span.icon > [class*=" icon-"] { cursor: default; }

name

-

Name must be unique within a namespace. Is required when creating resources, although some resources may allow a client to request the generation of an appropriate name automatically. Name is primarily intended for creation idempotence and configuration definition. Cannot be updated. More info: http://kubernetes.io/docs/user-guide/identifiers#names

+

Name must be unique within a namespace. Is required when creating resources, although some resources may allow a client to request the generation of an appropriate name automatically. Name is primarily intended for creation idempotence and configuration definition. Cannot be updated. More info: /docs/user-guide/identifiers#names

false

string

@@ -1943,7 +1943,7 @@ Applied only if Name is not specified. More info:

namespace

Namespace defines the space within each name must be unique. An empty namespace is equivalent to the "default" namespace, but "default" is the canonical representation. Not all objects are required to be scoped to a namespace - the value of this field for those objects will be empty.

-Must be a DNS_LABEL. Cannot be updated. More info: http://kubernetes.io/docs/user-guide/namespaces

+Must be a DNS_LABEL. Cannot be updated. More info: /docs/user-guide/namespaces

false

string

@@ -1959,7 +1959,7 @@ Must be a DNS_LABEL. Cannot be updated. More info:

uid

UID is the unique in time and space value for this object. It is typically generated by the server on successful creation of a resource and is not allowed to change on PUT operations.

-Populated by the system. Read-only. More info: http://kubernetes.io/docs/user-guide/identifiers#uids

+Populated by the system. Read-only. More info: /docs/user-guide/identifiers#uids

false

string

@@ -2007,14 +2007,14 @@ Populated by the system when a graceful deletion is requested. Read-only. More i

labels

-

Map of string keys and values that can be used to organize and categorize (scope and select) objects. May match selectors of replication controllers and services. More info: http://kubernetes.io/docs/user-guide/labels

+

Map of string keys and values that can be used to organize and categorize (scope and select) objects. May match selectors of replication controllers and services. More info: /docs/user-guide/labels

false

object

annotations

-

Annotations is an unstructured key value map stored with a resource that may be set by external tools to store and retrieve arbitrary metadata. They are not queryable and should be preserved when modifying objects. More info: http://kubernetes.io/docs/user-guide/annotations

+

Annotations is an unstructured key value map stored with a resource that may be set by external tools to store and retrieve arbitrary metadata. They are not queryable and should be preserved when modifying objects. More info: /docs/user-guide/annotations

false

object

@@ -2078,7 +2078,7 @@ When an object is created, the system will populate this list with the current s

replicas

-

Replicas is the number of desired replicas. This is a pointer to distinguish between explicit zero and unspecified. Defaults to 1. More info: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/#what-is-a-replicationcontroller

+

Replicas is the number of desired replicas. This is a pointer to distinguish between explicit zero and unspecified. Defaults to 1. More info: /docs/concepts/workloads/controllers/replicationcontroller/#what-is-a-replicationcontroller

false

integer (int32)

@@ -2092,14 +2092,14 @@ When an object is created, the system will populate this list with the current s

selector

-

Selector is a label query over pods that should match the replica count. If the selector is empty, it is defaulted to the labels present on the pod template. Label keys and values that must match in order to be controlled by this replica set. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors

+

Selector is a label query over pods that should match the replica count. If the selector is empty, it is defaulted to the labels present on the pod template. Label keys and values that must match in order to be controlled by this replica set. More info: /docs/concepts/overview/working-with-objects/labels/#label-selectors

false

v1.LabelSelector

template

-

Template is the object that describes the pod that will be created if insufficient replicas are detected. More info: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#pod-template

+

Template is the object that describes the pod that will be created if insufficient replicas are detected. More info: /docs/concepts/workloads/controllers/replicationcontroller#pod-template

false

v1.PodTemplateSpec

@@ -2195,14 +2195,14 @@ When an object is created, the system will populate this list with the current s

selector

-

A label query over pods that are managed by the daemon set. Must match in order to be controlled. If empty, defaulted to labels on Pod template. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors

+

A label query over pods that are managed by the daemon set. Must match in order to be controlled. If empty, defaulted to labels on Pod template. More info: /docs/concepts/overview/working-with-objects/labels/#label-selectors

false

v1.LabelSelector

template

-

An object that describes the pod that will be created. The DaemonSet will create exactly one copy of this pod on every node that matches the template’s node selector (or on every node if no node selector is specified). More info: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#pod-template

+

An object that describes the pod that will be created. The DaemonSet will create exactly one copy of this pod on every node that matches the template’s node selector (or on every node if no node selector is specified). More info: /docs/concepts/workloads/controllers/replicationcontroller#pod-template

true

v1.PodTemplateSpec

@@ -2344,7 +2344,7 @@ When an object is created, the system will populate this list with the current s

fsType

-

Filesystem type of the volume that you want to mount. Tip: Ensure that the filesystem type is supported by the host operating system. Examples: "ext4", "xfs", "ntfs". Implicitly inferred to be "ext4" if unspecified. More info: https://kubernetes.io/docs/concepts/storage/volumes#iscsi

+

Filesystem type of the volume that you want to mount. Tip: Ensure that the filesystem type is supported by the host operating system. Examples: "ext4", "xfs", "ntfs". Implicitly inferred to be "ext4" if unspecified. More info: /docs/concepts/storage/volumes#iscsi

false

string

@@ -2475,14 +2475,14 @@ When an object is created, the system will populate this list with the current s

medium

-

What type of storage medium should back this directory. The default is "" which means to use the node’s default medium. Must be an empty string (default) or Memory. More info: https://kubernetes.io/docs/concepts/storage/volumes#emptydir

+

What type of storage medium should back this directory. The default is "" which means to use the node’s default medium. Must be an empty string (default) or Memory. More info: /docs/concepts/storage/volumes#emptydir

false

string

sizeLimit

-

Total amount of local storage required for this EmptyDir volume. The size limit is also applicable for memory medium. The maximum usage on memory medium EmptyDir would be the minimum value between the SizeLimit specified here and the sum of memory limits of all containers in a pod. The default is nil which means that the limit is undefined. More info: http://kubernetes.io/docs/user-guide/volumes#emptydir

+

Total amount of local storage required for this EmptyDir volume. The size limit is also applicable for memory medium. The maximum usage on memory medium EmptyDir would be the minimum value between the SizeLimit specified here and the sum of memory limits of all containers in a pod. The default is nil which means that the limit is undefined. More info: /docs/user-guide/volumes#emptydir

false

string

@@ -2728,7 +2728,7 @@ When an object is created, the system will populate this list with the current s

claimName

-

ClaimName is the name of a PersistentVolumeClaim in the same namespace as the pod using this volume. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#persistentvolumeclaims

+

ClaimName is the name of a PersistentVolumeClaim in the same namespace as the pod using this volume. More info: /docs/concepts/storage/persistent-volumes#persistentvolumeclaims

true

string

@@ -2854,7 +2854,7 @@ When an object is created, the system will populate this list with the current s

secretName

-

Name of the secret in the pod’s namespace to use. More info: https://kubernetes.io/docs/concepts/storage/volumes#secret

+

Name of the secret in the pod’s namespace to use. More info: /docs/concepts/storage/volumes#secret

false

string

@@ -3401,35 +3401,35 @@ When an object is created, the system will populate this list with the current s

name

-

Volume’s name. Must be a DNS_LABEL and unique within the pod. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

+

Volume’s name. Must be a DNS_LABEL and unique within the pod. More info: /docs/concepts/overview/working-with-objects/names/#names

true

string

hostPath

-

HostPath represents a pre-existing file or directory on the host machine that is directly exposed to the container. This is generally used for system agents or other privileged things that are allowed to see the host machine. Most containers will NOT need this. More info: https://kubernetes.io/docs/concepts/storage/volumes#hostpath

+

HostPath represents a pre-existing file or directory on the host machine that is directly exposed to the container. This is generally used for system agents or other privileged things that are allowed to see the host machine. Most containers will NOT need this. More info: /docs/concepts/storage/volumes#hostpath

false

v1.HostPathVolumeSource

emptyDir

-

EmptyDir represents a temporary directory that shares a pod’s lifetime. More info: https://kubernetes.io/docs/concepts/storage/volumes#emptydir

+

EmptyDir represents a temporary directory that shares a pod’s lifetime. More info: /docs/concepts/storage/volumes#emptydir

false

v1.EmptyDirVolumeSource

gcePersistentDisk

-

GCEPersistentDisk represents a GCE Disk resource that is attached to a kubelet’s host machine and then exposed to the pod. More info: https://kubernetes.io/docs/concepts/storage/volumes#gcepersistentdisk

+

GCEPersistentDisk represents a GCE Disk resource that is attached to a kubelet’s host machine and then exposed to the pod. More info: /docs/concepts/storage/volumes#gcepersistentdisk

false

v1.GCEPersistentDiskVolumeSource

awsElasticBlockStore

-

AWSElasticBlockStore represents an AWS Disk resource that is attached to a kubelet’s host machine and then exposed to the pod. More info: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore

+

AWSElasticBlockStore represents an AWS Disk resource that is attached to a kubelet’s host machine and then exposed to the pod. More info: /docs/concepts/storage/volumes#awselasticblockstore

false

v1.AWSElasticBlockStoreVolumeSource

@@ -3443,14 +3443,14 @@ When an object is created, the system will populate this list with the current s

secret

-

Secret represents a secret that should populate this volume. More info: https://kubernetes.io/docs/concepts/storage/volumes#secret

+

Secret represents a secret that should populate this volume. More info: /docs/concepts/storage/volumes#secret

false

v1.SecretVolumeSource

nfs

-

NFS represents an NFS mount on the host that shares a pod’s lifetime More info: https://kubernetes.io/docs/concepts/storage/volumes#nfs

+

NFS represents an NFS mount on the host that shares a pod’s lifetime More info: /docs/concepts/storage/volumes#nfs

false

v1.NFSVolumeSource

@@ -3471,7 +3471,7 @@ When an object is created, the system will populate this list with the current s

persistentVolumeClaim

-

PersistentVolumeClaimVolumeSource represents a reference to a PersistentVolumeClaim in the same namespace. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#persistentvolumeclaims

+

PersistentVolumeClaimVolumeSource represents a reference to a PersistentVolumeClaim in the same namespace. More info: /docs/concepts/storage/persistent-volumes#persistentvolumeclaims

false

v1.PersistentVolumeClaimVolumeSource

@@ -3741,14 +3741,14 @@ When an object is created, the system will populate this list with the current s

initialDelaySeconds

-

Number of seconds after the container has started before liveness probes are initiated. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

+

Number of seconds after the container has started before liveness probes are initiated. More info: /docs/concepts/workloads/pods/pod-lifecycle#container-probes

false

integer (int32)

timeoutSeconds

-

Number of seconds after which the probe times out. Defaults to 1 second. Minimum value is 1. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

+

Number of seconds after which the probe times out. Defaults to 1 second. Minimum value is 1. More info: /docs/concepts/workloads/pods/pod-lifecycle#container-probes

false

integer (int32)

@@ -3934,7 +3934,7 @@ When an object is created, the system will populate this list with the current s

name

-

Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

+

Name of the referent. More info: /docs/concepts/overview/working-with-objects/names/#names

false

string

@@ -4041,14 +4041,14 @@ When an object is created, the system will populate this list with the current s

volumes

-

List of volumes that can be mounted by containers belonging to the pod. More info: https://kubernetes.io/docs/concepts/storage/volumes

+

List of volumes that can be mounted by containers belonging to the pod. More info: /docs/concepts/storage/volumes

false

v1.Volume array

initContainers

-

List of initialization containers belonging to the pod. Init containers are executed in order prior to containers being started. If any init container fails, the pod is considered to have failed and is handled according to its restartPolicy. The name for an init container or normal container must be unique among all containers. Init containers may not have Lifecycle actions, Readiness probes, or Liveness probes. The resourceRequirements of an init container are taken into account during scheduling by finding the highest request/limit for each resource type, and then using the max of of that value or the sum of the normal containers. Limits are applied to init containers in a similar fashion. Init containers cannot currently be added or removed. Cannot be updated. More info: https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

+

List of initialization containers belonging to the pod. Init containers are executed in order prior to containers being started. If any init container fails, the pod is considered to have failed and is handled according to its restartPolicy. The name for an init container or normal container must be unique among all containers. Init containers may not have Lifecycle actions, Readiness probes, or Liveness probes. The resourceRequirements of an init container are taken into account during scheduling by finding the highest request/limit for each resource type, and then using the max of of that value or the sum of the normal containers. Limits are applied to init containers in a similar fashion. Init containers cannot currently be added or removed. Cannot be updated. More info: /docs/concepts/workloads/pods/init-containers/

false

v1.Container array

@@ -4062,7 +4062,7 @@ When an object is created, the system will populate this list with the current s

restartPolicy

-

Restart policy for all containers within the pod. One of Always, OnFailure, Never. Default to Always. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy

+

Restart policy for all containers within the pod. One of Always, OnFailure, Never. Default to Always. More info: /docs/concepts/workloads/pods/pod-lifecycle/#restart-policy

false

string

@@ -4090,14 +4090,14 @@ When an object is created, the system will populate this list with the current s

nodeSelector

-

NodeSelector is a selector which must be true for the pod to fit on a node. Selector which must match a node’s labels for the pod to be scheduled on that node. More info: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/

+

NodeSelector is a selector which must be true for the pod to fit on a node. Selector which must match a node’s labels for the pod to be scheduled on that node. More info: /docs/concepts/configuration/assign-pod-node/

false

object

serviceAccountName

-

ServiceAccountName is the name of the ServiceAccount to use to run this pod. More info: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/

+

ServiceAccountName is the name of the ServiceAccount to use to run this pod. More info: /docs/tasks/configure-pod-container/configure-service-account/

false

string

@@ -4153,7 +4153,7 @@ When an object is created, the system will populate this list with the current s

imagePullSecrets

-

ImagePullSecrets is an optional list of references to secrets in the same namespace to use for pulling any of the images used by this PodSpec. If specified, these secrets will be passed to individual puller implementations for them to use. For example, in the case of docker, only DockerConfig type secrets are honored. More info: https://kubernetes.io/docs/concepts/containers/images#specifying-imagepullsecrets-on-a-pod

+

ImagePullSecrets is an optional list of references to secrets in the same namespace to use for pulling any of the images used by this PodSpec. If specified, these secrets will be passed to individual puller implementations for them to use. For example, in the case of docker, only DockerConfig type secrets are honored. More info: /docs/concepts/containers/images#specifying-imagepullsecrets-on-a-pod

false

v1.LocalObjectReference array

@@ -4312,14 +4312,14 @@ When an object is created, the system will populate this list with the current s

postStart

-

PostStart is called immediately after a container is created. If the handler fails, the container is terminated and restarted according to its restart policy. Other management of the container blocks until the hook completes. More info: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks

+

PostStart is called immediately after a container is created. If the handler fails, the container is terminated and restarted according to its restart policy. Other management of the container blocks until the hook completes. More info: /docs/concepts/containers/container-lifecycle-hooks/#container-hooks

false

v1.Handler

preStop

-

PreStop is called immediately before a container is terminated. The container is terminated after the handler completes. The reason for termination is passed to the handler. Regardless of the outcome of the handler, the container is eventually terminated. Other management of the container blocks until the hook completes. More info: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks

+

PreStop is called immediately before a container is terminated. The container is terminated after the handler completes. The reason for termination is passed to the handler. Regardless of the outcome of the handler, the container is eventually terminated. Other management of the container blocks until the hook completes. More info: /docs/concepts/containers/container-lifecycle-hooks/#container-hooks

false

v1.Handler

@@ -4680,7 +4680,7 @@ Examples:

fsType

-

Filesystem type of the volume that you want to mount. Tip: Ensure that the filesystem type is supported by the host operating system. Examples: "ext4", "xfs", "ntfs". Implicitly inferred to be "ext4" if unspecified. More info: https://kubernetes.io/docs/concepts/storage/volumes#rbd

+

Filesystem type of the volume that you want to mount. Tip: Ensure that the filesystem type is supported by the host operating system. Examples: "ext4", "xfs", "ntfs". Implicitly inferred to be "ext4" if unspecified. More info: /docs/concepts/storage/volumes#rbd

false

string

@@ -4752,7 +4752,7 @@ Examples:

name

-

Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

+

Name of the referent. More info: /docs/concepts/overview/working-with-objects/names/#names

false

string

@@ -5121,14 +5121,14 @@ Examples:

selector

-

label query over pods that should match the replicas count. More info: http://kubernetes.io/docs/user-guide/labels#label-selectors

+

label query over pods that should match the replicas count. More info: /docs/user-guide/labels#label-selectors

false

object

targetSelector

-

label selector for pods that should match the replicas count. This is a serializated version of both map-based and more expressive set-based selectors. This is done to avoid introspection in the clients. The string will be in the same format as the query-param syntax. If the target type only supports map-based selectors, both this field and map-based selector field are populated. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors

+

label selector for pods that should match the replicas count. This is a serializated version of both map-based and more expressive set-based selectors. This is done to avoid introspection in the clients. The string will be in the same format as the query-param syntax. If the target type only supports map-based selectors, both this field and map-based selector field are populated. More info: /docs/concepts/overview/working-with-objects/labels/#label-selectors

false

string

@@ -5162,21 +5162,21 @@ Examples:

server

-

Server is the hostname or IP address of the NFS server. More info: https://kubernetes.io/docs/concepts/storage/volumes#nfs

+

Server is the hostname or IP address of the NFS server. More info: /docs/concepts/storage/volumes#nfs

true

string

path

-

Path that is exported by the NFS server. More info: https://kubernetes.io/docs/concepts/storage/volumes#nfs

+

Path that is exported by the NFS server. More info: /docs/concepts/storage/volumes#nfs

true

string

readOnly

-

ReadOnly here will force the NFS export to be mounted with read-only permissions. Defaults to false. More info: https://kubernetes.io/docs/concepts/storage/volumes#nfs

+

ReadOnly here will force the NFS export to be mounted with read-only permissions. Defaults to false. More info: /docs/concepts/storage/volumes#nfs

false

boolean

false

@@ -5686,7 +5686,7 @@ Both these may change in the future. Incoming requests are matched against the h

uid

-

UID of the resource. (when there is a single resource which can be described). More info: http://kubernetes.io/docs/user-guide/identifiers#uids

+

UID of the resource. (when there is a single resource which can be described). More info: /docs/user-guide/identifiers#uids

false

string

@@ -5775,21 +5775,21 @@ Both these may change in the future. Incoming requests are matched against the h

image

-

Docker image name. More info: https://kubernetes.io/docs/concepts/containers/images This field is optional to allow higher level config management to default or override container images in workload controllers like Deployments and StatefulSets.

+

Docker image name. More info: /docs/concepts/containers/images This field is optional to allow higher level config management to default or override container images in workload controllers like Deployments and StatefulSets.

false

string

command

-

Entrypoint array. Not executed within a shell. The docker image’s ENTRYPOINT is used if this is not provided. Variable references $(VAR_NAME) are expanded using the container’s environment. If a variable cannot be resolved, the reference in the input string will be unchanged. The $(VAR_NAME) syntax can be escaped with a double $$, ie: $$(VAR_NAME). Escaped references will never be expanded, regardless of whether the variable exists or not. Cannot be updated. More info: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell

+

Entrypoint array. Not executed within a shell. The docker image’s ENTRYPOINT is used if this is not provided. Variable references $(VAR_NAME) are expanded using the container’s environment. If a variable cannot be resolved, the reference in the input string will be unchanged. The $(VAR_NAME) syntax can be escaped with a double $$, ie: $$(VAR_NAME). Escaped references will never be expanded, regardless of whether the variable exists or not. Cannot be updated. More info: /docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell

false

string array

args

-

Arguments to the entrypoint. The docker image’s CMD is used if this is not provided. Variable references $(VAR_NAME) are expanded using the container’s environment. If a variable cannot be resolved, the reference in the input string will be unchanged. The $(VAR_NAME) syntax can be escaped with a double $$, ie: $$(VAR_NAME). Escaped references will never be expanded, regardless of whether the variable exists or not. Cannot be updated. More info: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell

+

Arguments to the entrypoint. The docker image’s CMD is used if this is not provided. Variable references $(VAR_NAME) are expanded using the container’s environment. If a variable cannot be resolved, the reference in the input string will be unchanged. The $(VAR_NAME) syntax can be escaped with a double $$, ie: $$(VAR_NAME). Escaped references will never be expanded, regardless of whether the variable exists or not. Cannot be updated. More info: /docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell

false

string array

@@ -5824,7 +5824,7 @@ Both these may change in the future. Incoming requests are matched against the h

resources

-

Compute Resources required by this container. Cannot be updated. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#resources

+

Compute Resources required by this container. Cannot be updated. More info: /docs/concepts/storage/persistent-volumes#resources

false

v1.ResourceRequirements

@@ -5845,14 +5845,14 @@ Both these may change in the future. Incoming requests are matched against the h

livenessProbe

-

Periodic probe of container liveness. Container will be restarted if the probe fails. Cannot be updated. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

+

Periodic probe of container liveness. Container will be restarted if the probe fails. Cannot be updated. More info: /docs/concepts/workloads/pods/pod-lifecycle#container-probes

false

v1.Probe

readinessProbe

-

Periodic probe of container service readiness. Container will be removed from service endpoints if the probe fails. Cannot be updated. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

+

Periodic probe of container service readiness. Container will be removed from service endpoints if the probe fails. Cannot be updated. More info: /docs/concepts/workloads/pods/pod-lifecycle#container-probes

false

v1.Probe

@@ -5880,14 +5880,14 @@ Both these may change in the future. Incoming requests are matched against the h

imagePullPolicy

-

Image pull policy. One of Always, Never, IfNotPresent. Defaults to Always if :latest tag is specified, or IfNotPresent otherwise. Cannot be updated. More info: https://kubernetes.io/docs/concepts/containers/images#updating-images

+

Image pull policy. One of Always, Never, IfNotPresent. Defaults to Always if :latest tag is specified, or IfNotPresent otherwise. Cannot be updated. More info: /docs/concepts/containers/images#updating-images

false

string

securityContext

-

Security options the pod should run with. More info: https://kubernetes.io/docs/concepts/policy/security-context/ More info: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

+

Security options the pod should run with. More info: /docs/concepts/policy/security-context/ More info: /docs/tasks/configure-pod-container/security-context/

false

v1.SecurityContext

@@ -6020,14 +6020,14 @@ Both these may change in the future. Incoming requests are matched against the h

name

-

Name of the referent. More info: http://kubernetes.io/docs/user-guide/identifiers#names

+

Name of the referent. More info: /docs/user-guide/identifiers#names

true

string

uid

-

UID of the referent. More info: http://kubernetes.io/docs/user-guide/identifiers#uids

+

UID of the referent. More info: /docs/user-guide/identifiers#uids

true

string

@@ -6075,7 +6075,7 @@ Both these may change in the future. Incoming requests are matched against the h

replicas

-

Replicas is the most recently oberved number of replicas. More info: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/#what-is-a-replicationcontroller

+

Replicas is the most recently oberved number of replicas. More info: /docs/concepts/workloads/controllers/replicationcontroller/#what-is-a-replicationcontroller

true

integer (int32)

@@ -6385,14 +6385,14 @@ Both these may change in the future. Incoming requests are matched against the h

path

-

Path of the directory on the host. If the path is a symlink, it will follow the link to the real path. More info: https://kubernetes.io/docs/concepts/storage/volumes#hostpath

+

Path of the directory on the host. If the path is a symlink, it will follow the link to the real path. More info: /docs/concepts/storage/volumes#hostpath

true

string

type

-

Type for HostPath Volume Defaults to "" More info: https://kubernetes.io/docs/concepts/storage/volumes#hostpath

+

Type for HostPath Volume Defaults to "" More info: /docs/concepts/storage/volumes#hostpath

false

v1.HostPathType

@@ -6429,7 +6429,7 @@ Both these may change in the future. Incoming requests are matched against the h

name

-

Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

+

Name of the referent. More info: /docs/concepts/overview/working-with-objects/names/#names

false

string

@@ -6707,14 +6707,14 @@ Both these may change in the future. Incoming requests are matched against the h

volumeID

-

Unique ID of the persistent disk resource in AWS (Amazon EBS volume). More info: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore

+

Unique ID of the persistent disk resource in AWS (Amazon EBS volume). More info: /docs/concepts/storage/volumes#awselasticblockstore

true

string

fsType

-

Filesystem type of the volume that you want to mount. Tip: Ensure that the filesystem type is supported by the host operating system. Examples: "ext4", "xfs", "ntfs". Implicitly inferred to be "ext4" if unspecified. More info: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore

+

Filesystem type of the volume that you want to mount. Tip: Ensure that the filesystem type is supported by the host operating system. Examples: "ext4", "xfs", "ntfs". Implicitly inferred to be "ext4" if unspecified. More info: /docs/concepts/storage/volumes#awselasticblockstore

false

string

@@ -6728,7 +6728,7 @@ Both these may change in the future. Incoming requests are matched against the h

readOnly

-

Specify "true" to force and set the ReadOnly property in VolumeMounts to "true". If omitted, the default is "false". More info: https://kubernetes.io/docs/concepts/storage/volumes#awselasticblockstore

+

Specify "true" to force and set the ReadOnly property in VolumeMounts to "true". If omitted, the default is "false". More info: /docs/concepts/storage/volumes#awselasticblockstore

false

boolean

false

@@ -6958,14 +6958,14 @@ Both these may change in the future. Incoming requests are matched against the h

limits

-

Limits describes the maximum amount of compute resources allowed. More info: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/

+

Limits describes the maximum amount of compute resources allowed. More info: /docs/concepts/configuration/manage-compute-resources-container/

false

object

requests

-

Requests describes the minimum amount of compute resources required. If Requests is omitted for a container, it defaults to Limits if that is explicitly specified, otherwise to an implementation-defined value. More info: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/

+

Requests describes the minimum amount of compute resources required. If Requests is omitted for a container, it defaults to Limits if that is explicitly specified, otherwise to an implementation-defined value. More info: /docs/concepts/configuration/manage-compute-resources-container/

false

object

@@ -7193,7 +7193,7 @@ Both these may change in the future. Incoming requests are matched against the h

name

-

Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

+

Name of the referent. More info: /docs/concepts/overview/working-with-objects/names/#names

false

string

@@ -7444,7 +7444,7 @@ Both these may change in the future. Incoming requests are matched against the h

name

-

Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

+

Name of the referent. More info: /docs/concepts/overview/working-with-objects/names/#names

false

string

diff --git a/content/en/docs/reference/federation/federation/v1beta1/definitions.html b/content/en/docs/reference/federation/federation/v1beta1/definitions.html index f71ec6ce0f..31f204cb00 100755 --- a/content/en/docs/reference/federation/federation/v1beta1/definitions.html +++ b/content/en/docs/reference/federation/federation/v1beta1/definitions.html @@ -707,7 +707,7 @@ span.icon > [class^="icon-"], span.icon > [class*=" icon-"] { cursor: default; }

uid

-

UID of the resource. (when there is a single resource which can be described). More info: http://kubernetes.io/docs/user-guide/identifiers#uids

+

UID of the resource. (when there is a single resource which can be described). More info: /docs/user-guide/identifiers#uids

false

string

@@ -912,7 +912,7 @@ span.icon > [class^="icon-"], span.icon > [class*=" icon-"] { cursor: default; }

name

-

Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

+

Name of the referent. More info: /docs/concepts/overview/working-with-objects/names/#names

false

string

@@ -1177,7 +1177,7 @@ span.icon > [class^="icon-"], span.icon > [class*=" icon-"] { cursor: default; }

name

-

Name must be unique within a namespace. Is required when creating resources, although some resources may allow a client to request the generation of an appropriate name automatically. Name is primarily intended for creation idempotence and configuration definition. Cannot be updated. More info: http://kubernetes.io/docs/user-guide/identifiers#names

+

Name must be unique within a namespace. Is required when creating resources, although some resources may allow a client to request the generation of an appropriate name automatically. Name is primarily intended for creation idempotence and configuration definition. Cannot be updated. More info: /docs/user-guide/identifiers#names

false

string

@@ -1197,7 +1197,7 @@ Applied only if Name is not specified. More info:

namespace

Namespace defines the space within each name must be unique. An empty namespace is equivalent to the "default" namespace, but "default" is the canonical representation. Not all objects are required to be scoped to a namespace - the value of this field for those objects will be empty.

-Must be a DNS_LABEL. Cannot be updated. More info: http://kubernetes.io/docs/user-guide/namespaces

+Must be a DNS_LABEL. Cannot be updated. More info: /docs/user-guide/namespaces

false

string

@@ -1213,7 +1213,7 @@ Must be a DNS_LABEL. Cannot be updated. More info:

uid

UID is the unique in time and space value for this object. It is typically generated by the server on successful creation of a resource and is not allowed to change on PUT operations.

-Populated by the system. Read-only. More info: http://kubernetes.io/docs/user-guide/identifiers#uids

+Populated by the system. Read-only. More info: /docs/user-guide/identifiers#uids

false

string

@@ -1261,14 +1261,14 @@ Populated by the system when a graceful deletion is requested. Read-only. More i

labels

-

Map of string keys and values that can be used to organize and categorize (scope and select) objects. May match selectors of replication controllers and services. More info: http://kubernetes.io/docs/user-guide/labels

+

Map of string keys and values that can be used to organize and categorize (scope and select) objects. May match selectors of replication controllers and services. More info: /docs/user-guide/labels

false

object

annotations

-

Annotations is an unstructured key value map stored with a resource that may be set by external tools to store and retrieve arbitrary metadata. They are not queryable and should be preserved when modifying objects. More info: http://kubernetes.io/docs/user-guide/annotations

+

Annotations is an unstructured key value map stored with a resource that may be set by external tools to store and retrieve arbitrary metadata. They are not queryable and should be preserved when modifying objects. More info: /docs/user-guide/annotations

false

object

@@ -1346,14 +1346,14 @@ When an object is created, the system will populate this list with the current s

name

-

Name of the referent. More info: http://kubernetes.io/docs/user-guide/identifiers#names

+

Name of the referent. More info: /docs/user-guide/identifiers#names

true

string

uid

-

UID of the referent. More info: http://kubernetes.io/docs/user-guide/identifiers#uids

+

UID of the referent. More info: /docs/user-guide/identifiers#uids

true

string

diff --git a/content/en/docs/reference/federation/v1/definitions.html b/content/en/docs/reference/federation/v1/definitions.html index b0b55365a7..5533399112 100755 --- a/content/en/docs/reference/federation/v1/definitions.html +++ b/content/en/docs/reference/federation/v1/definitions.html @@ -512,7 +512,7 @@ span.icon > [class^="icon-"], span.icon > [class*=" icon-"] { cursor: default; }

items

-

Items is the list of Namespace objects in the list. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/

+

Items is the list of Namespace objects in the list. More info: /docs/concepts/overview/working-with-objects/namespaces/

true

v1.Namespace array

@@ -1146,7 +1146,7 @@ span.icon > [class^="icon-"], span.icon > [class*=" icon-"] { cursor: default; }

phase

-

Phase is the current lifecycle phase of the namespace. More info: https://kubernetes.io/docs/tasks/administer-cluster/namespaces/

+

Phase is the current lifecycle phase of the namespace. More info: /docs/tasks/administer-cluster/namespaces/

false

string

@@ -1235,7 +1235,7 @@ span.icon > [class^="icon-"], span.icon > [class*=" icon-"] { cursor: default; }

finalizers

-

Finalizers is an opaque list of values that must be empty to permanently remove object from storage. More info: https://kubernetes.io/docs/tasks/administer-cluster/namespaces/

+

Finalizers is an opaque list of values that must be empty to permanently remove object from storage. More info: /docs/tasks/administer-cluster/namespaces/

false

v1.FinalizerName array

@@ -1530,7 +1530,7 @@ span.icon > [class^="icon-"], span.icon > [class*=" icon-"] { cursor: default; }

uid

-

UID of the resource. (when there is a single resource which can be described). More info: http://kubernetes.io/docs/user-guide/identifiers#uids

+

UID of the resource. (when there is a single resource which can be described). More info: /docs/user-guide/identifiers#uids

false

string

@@ -1681,21 +1681,21 @@ span.icon > [class^="icon-"], span.icon > [class*=" icon-"] { cursor: default; }

namespace

-

Namespace of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/

+

Namespace of the referent. More info: /docs/concepts/overview/working-with-objects/namespaces/

false

string

name

-

Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

+

Name of the referent. More info: /docs/concepts/overview/working-with-objects/names/#names

false

string

uid

-

UID of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids

+

UID of the referent. More info: /docs/concepts/overview/working-with-objects/names/#uids

false

string

@@ -1805,7 +1805,7 @@ span.icon > [class^="icon-"], span.icon > [class*=" icon-"] { cursor: default; }

items

-

Items is a list of secret objects. More info: https://kubernetes.io/docs/concepts/configuration/secret

+

Items is a list of secret objects. More info: /docs/concepts/configuration/secret

true

v1.Secret array

@@ -1864,14 +1864,14 @@ span.icon > [class^="icon-"], span.icon > [class*=" icon-"] { cursor: default; }

targetPort

-

Number or name of the port to access on the pods targeted by the service. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. If this is a string, it will be looked up as a named port in the target Pod’s container ports. If this is not specified, the value of the port field is used (an identity map). This field is ignored for services with clusterIP=None, and should be omitted or set equal to the port field. More info: https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service

+

Number or name of the port to access on the pods targeted by the service. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. If this is a string, it will be looked up as a named port in the target Pod’s container ports. If this is not specified, the value of the port field is used (an identity map). This field is ignored for services with clusterIP=None, and should be omitted or set equal to the port field. More info: /docs/concepts/services-networking/service/#defining-a-service

false

string

nodePort

-

The port on each node on which this service is exposed when type=NodePort or LoadBalancer. Usually assigned by the system. If specified, it will be allocated to the service if unused or else creation of the service will fail. Default is to auto-allocate a port if the ServiceType of this Service requires one. More info: https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport

+

The port on each node on which this service is exposed when type=NodePort or LoadBalancer. Usually assigned by the system. If specified, it will be allocated to the service if unused or else creation of the service will fail. Default is to auto-allocate a port if the ServiceType of this Service requires one. More info: /docs/concepts/services-networking/service/#type-nodeport

false

integer (int32)

@@ -1919,14 +1919,14 @@ span.icon > [class^="icon-"], span.icon > [class*=" icon-"] { cursor: default; }

name

-

Name of the referent. More info: http://kubernetes.io/docs/user-guide/identifiers#names

+

Name of the referent. More info: /docs/user-guide/identifiers#names

true

string

uid

-

UID of the referent. More info: http://kubernetes.io/docs/user-guide/identifiers#uids

+

UID of the referent. More info: /docs/user-guide/identifiers#uids

true

string

@@ -1974,7 +1974,7 @@ span.icon > [class^="icon-"], span.icon > [class*=" icon-"] { cursor: default; }

name

-

Name must be unique within a namespace. Is required when creating resources, although some resources may allow a client to request the generation of an appropriate name automatically. Name is primarily intended for creation idempotence and configuration definition. Cannot be updated. More info: http://kubernetes.io/docs/user-guide/identifiers#names

+

Name must be unique within a namespace. Is required when creating resources, although some resources may allow a client to request the generation of an appropriate name automatically. Name is primarily intended for creation idempotence and configuration definition. Cannot be updated. More info: /docs/user-guide/identifiers#names

false

string

@@ -1994,7 +1994,7 @@ Applied only if Name is not specified. More info:

namespace

Namespace defines the space within each name must be unique. An empty namespace is equivalent to the "default" namespace, but "default" is the canonical representation. Not all objects are required to be scoped to a namespace - the value of this field for those objects will be empty.

-Must be a DNS_LABEL. Cannot be updated. More info: http://kubernetes.io/docs/user-guide/namespaces

+Must be a DNS_LABEL. Cannot be updated. More info: /docs/user-guide/namespaces

false

string

@@ -2010,7 +2010,7 @@ Must be a DNS_LABEL. Cannot be updated. More info:

uid

UID is the unique in time and space value for this object. It is typically generated by the server on successful creation of a resource and is not allowed to change on PUT operations.

-Populated by the system. Read-only. More info: http://kubernetes.io/docs/user-guide/identifiers#uids

+Populated by the system. Read-only. More info: /docs/user-guide/identifiers#uids

false

string

@@ -2058,14 +2058,14 @@ Populated by the system when a graceful deletion is requested. Read-only. More i

labels

-

Map of string keys and values that can be used to organize and categorize (scope and select) objects. May match selectors of replication controllers and services. More info: http://kubernetes.io/docs/user-guide/labels

+

Map of string keys and values that can be used to organize and categorize (scope and select) objects. May match selectors of replication controllers and services. More info: /docs/user-guide/labels

false

object

annotations

-

Annotations is an unstructured key value map stored with a resource that may be set by external tools to store and retrieve arbitrary metadata. They are not queryable and should be preserved when modifying objects. More info: http://kubernetes.io/docs/user-guide/annotations

+

Annotations is an unstructured key value map stored with a resource that may be set by external tools to store and retrieve arbitrary metadata. They are not queryable and should be preserved when modifying objects. More info: /docs/user-guide/annotations

false

object

@@ -2308,28 +2308,28 @@ When an object is created, the system will populate this list with the current s

ports

-

The list of ports that are exposed by this service. More info: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies

+

The list of ports that are exposed by this service. More info: /docs/concepts/services-networking/service/#virtual-ips-and-service-proxies

false

v1.ServicePort array

selector

-

Route service traffic to pods with label keys and values matching this selector. If empty or not present, the service is assumed to have an external process managing its endpoints, which Kubernetes will not modify. Only applies to types ClusterIP, NodePort, and LoadBalancer. Ignored if type is ExternalName. More info: https://kubernetes.io/docs/concepts/services-networking/service/

+

Route service traffic to pods with label keys and values matching this selector. If empty or not present, the service is assumed to have an external process managing its endpoints, which Kubernetes will not modify. Only applies to types ClusterIP, NodePort, and LoadBalancer. Ignored if type is ExternalName. More info: /docs/concepts/services-networking/service/

false

object

clusterIP

-

clusterIP is the IP address of the service and is usually assigned randomly by the master. If an address is specified manually and is not in use by others, it will be allocated to the service; otherwise, creation of the service will fail. This field can not be changed through updates. Valid values are "None", empty string (""), or a valid IP address. "None" can be specified for headless services when proxying is not required. Only applies to types ClusterIP, NodePort, and LoadBalancer. Ignored if type is ExternalName. More info: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies

+

clusterIP is the IP address of the service and is usually assigned randomly by the master. If an address is specified manually and is not in use by others, it will be allocated to the service; otherwise, creation of the service will fail. This field can not be changed through updates. Valid values are "None", empty string (""), or a valid IP address. "None" can be specified for headless services when proxying is not required. Only applies to types ClusterIP, NodePort, and LoadBalancer. Ignored if type is ExternalName. More info: /docs/concepts/services-networking/service/#virtual-ips-and-service-proxies

false

string

type

-

type determines how the Service is exposed. Defaults to ClusterIP. Valid options are ExternalName, ClusterIP, NodePort, and LoadBalancer. "ExternalName" maps to the specified externalName. "ClusterIP" allocates a cluster-internal IP address for load-balancing to endpoints. Endpoints are determined by the selector or if that is not specified, by manual construction of an Endpoints object. If clusterIP is "None", no virtual IP is allocated and the endpoints are published as a set of endpoints rather than a stable IP. "NodePort" builds on ClusterIP and allocates a port on every node which routes to the clusterIP. "LoadBalancer" builds on NodePort and creates an external load-balancer (if supported in the current cloud) which routes to the clusterIP. More info: https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services

+

type determines how the Service is exposed. Defaults to ClusterIP. Valid options are ExternalName, ClusterIP, NodePort, and LoadBalancer. "ExternalName" maps to the specified externalName. "ClusterIP" allocates a cluster-internal IP address for load-balancing to endpoints. Endpoints are determined by the selector or if that is not specified, by manual construction of an Endpoints object. If clusterIP is "None", no virtual IP is allocated and the endpoints are published as a set of endpoints rather than a stable IP. "NodePort" builds on ClusterIP and allocates a port on every node which routes to the clusterIP. "LoadBalancer" builds on NodePort and creates an external load-balancer (if supported in the current cloud) which routes to the clusterIP. More info: /docs/concepts/services-networking/service/#publishing-services

false

string

@@ -2343,7 +2343,7 @@ When an object is created, the system will populate this list with the current s

sessionAffinity

-

Supports "ClientIP" and "None". Used to maintain session affinity. Enable client IP based session affinity. Must be ClientIP or None. Defaults to None. More info: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies

+

Supports "ClientIP" and "None". Used to maintain session affinity. Enable client IP based session affinity. Must be ClientIP or None. Defaults to None. More info: /docs/concepts/services-networking/service/#virtual-ips-and-service-proxies

false

string

@@ -2357,7 +2357,7 @@ When an object is created, the system will populate this list with the current s

loadBalancerSourceRanges

-

If specified and supported by the platform, this will restrict traffic through the cloud-provider load-balancer will be restricted to the specified client IPs. This field will be ignored if the cloud-provider does not support the feature." More info: https://kubernetes.io/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/

+

If specified and supported by the platform, this will restrict traffic through the cloud-provider load-balancer will be restricted to the specified client IPs. This field will be ignored if the cloud-provider does not support the feature." More info: /docs/tasks/access-application-cluster/configure-cloud-provider-firewall/

false

string array

diff --git a/content/en/docs/reference/glossary/aggregation-layer.md b/content/en/docs/reference/glossary/aggregation-layer.md index d97b34d16d..e5bafd9c06 100644 --- a/content/en/docs/reference/glossary/aggregation-layer.md +++ b/content/en/docs/reference/glossary/aggregation-layer.md @@ -16,5 +16,4 @@ tags: -When you've configured the {{< glossary_tooltip text="Kubernetes API Server" term_id="kube-apiserver" >}} to [support additional APIs](https://kubernetes.io/docs/tasks/access-kubernetes-api/configure-aggregation-layer/), you can add `APIService` objects to "claim" a URL path in the Kubernetes API. - +When you've configured the {{< glossary_tooltip text="Kubernetes API Server" term_id="kube-apiserver" >}} to [support additional APIs](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/), you can add `APIService` objects to "claim" a URL path in the Kubernetes API. diff --git a/content/en/docs/reference/glossary/cloud-controller-manager.md b/content/en/docs/reference/glossary/cloud-controller-manager.md index 9a818ff93e..974b8539df 100755 --- a/content/en/docs/reference/glossary/cloud-controller-manager.md +++ b/content/en/docs/reference/glossary/cloud-controller-manager.md @@ -2,7 +2,7 @@ title: Cloud Controller Manager id: cloud-controller-manager date: 2018-04-12 -full_link: https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/ +full_link: /docs/tasks/administer-cluster/running-cloud-controller/ short_description: > Cloud Controller Manager is an alpha feature in 1.8. In upcoming releases it will be the preferred way to integrate Kubernetes with any cloud. @@ -17,4 +17,3 @@ tags: Kubernetes v1.6 contains a new binary called cloud-controller-manager. cloud-controller-manager is a daemon that embeds cloud-specific control loops. These cloud-specific control loops were originally in the kube-controller-manager. Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the cloud-controller-manager binary allows cloud vendors to evolve independently from the core Kubernetes code. - diff --git a/content/en/docs/reference/glossary/cni.md b/content/en/docs/reference/glossary/cni.md index c989cc8f69..3dda6d44a0 100644 --- a/content/en/docs/reference/glossary/cni.md +++ b/content/en/docs/reference/glossary/cni.md @@ -2,7 +2,7 @@ title: Container network interface (CNI) id: cni date: 2018-05-25 -full_link: https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni +full_link: /docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni short_description: > Container network interface (CNI) plugins are a type of Network plugin that adheres to the appc/CNI specification. @@ -14,5 +14,5 @@ tags: Container network interface (CNI) plugins are a type of Network plugin that adheres to the appc/CNI specification. -* For information on Kubernetes and CNI refer to [this](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni). -* For information on Kubernetes and CNI, see ["Network plugins"](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni). +* For information on Kubernetes and CNI refer to [this](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni). +* For information on Kubernetes and CNI, see ["Network plugins"](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni). diff --git a/content/en/docs/reference/glossary/configmap.md b/content/en/docs/reference/glossary/configmap.md index 14be411cf2..b541a78762 100755 --- a/content/en/docs/reference/glossary/configmap.md +++ b/content/en/docs/reference/glossary/configmap.md @@ -14,5 +14,4 @@ tags: -Allows you to decouple environment-specific configuration from your {{< glossary_tooltip text="container images" term_id="container" >}}, so that your applications are easily portable. When storing confidential data use a [Secret](https://kubernetes.io/docs/concepts/configuration/secret/). - +Allows you to decouple environment-specific configuration from your {{< glossary_tooltip text="container images" term_id="container" >}}, so that your applications are easily portable. When storing confidential data use a [Secret](/docs/concepts/configuration/secret/). diff --git a/content/en/docs/reference/glossary/csi.md b/content/en/docs/reference/glossary/csi.md index 8b04559082..b170639660 100644 --- a/content/en/docs/reference/glossary/csi.md +++ b/content/en/docs/reference/glossary/csi.md @@ -2,7 +2,7 @@ title: Container Storage Interface (CSI) id: csi date: 2018-06-25 -full_link: https://kubernetes.io/docs/concepts/storage/volumes/#csi +full_link: /docs/concepts/storage/volumes/#csi short_description: > The Container Storage Interface (CSI) defines a standard interface to expose storage systems to containers. @@ -17,5 +17,5 @@ tags: CSI allows vendors to create custom storage plugins for Kubernetes without adding them to the Kubernetes repository (out-of-tree plugins). To use a CSI driver from a storage provider, you must first [deploy it to your cluster](https://kubernetes-csi.github.io/docs/deploying.html). You will then be able to create a {{< glossary_tooltip text="Storage Class" term_id="storage-class" >}} that uses that CSI driver. -* [CSI in the Kubernetes documentation](https://kubernetes.io/docs/concepts/storage/volumes/#csi) +* [CSI in the Kubernetes documentation](/docs/concepts/storage/volumes/#csi) * [List of available CSI drivers](https://kubernetes-csi.github.io/docs/drivers.html) diff --git a/content/en/docs/reference/glossary/device-plugin.md b/content/en/docs/reference/glossary/device-plugin.md index 02e5500677..be653a7580 100644 --- a/content/en/docs/reference/glossary/device-plugin.md +++ b/content/en/docs/reference/glossary/device-plugin.md @@ -2,7 +2,7 @@ title: Device Plugin id: device-plugin date: 2019-02-02 -full_link: https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/ +full_link: /docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/ short_description: > Device Plugins are containers running in Kubernetes that provide access to a vendor specific resource. aka: @@ -14,4 +14,4 @@ tags: -[Device Plugin](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) are containers running in Kubernetes that provide access to a vendor specific resource. Device Plugins advertise these resources to kubelet and can be deployed manually or as a DeamonSet, rather than writing custom Kubernetes code. +[Device Plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) are containers running in Kubernetes that provide access to a vendor specific resource. Device Plugins advertise these resources to kubelet and can be deployed manually or as a DeamonSet, rather than writing custom Kubernetes code. diff --git a/content/en/docs/reference/glossary/extensions.md b/content/en/docs/reference/glossary/extensions.md index 1451bd3865..1515bffcfd 100644 --- a/content/en/docs/reference/glossary/extensions.md +++ b/content/en/docs/reference/glossary/extensions.md @@ -2,7 +2,7 @@ title: Extensions id: Extensions date: 2019-02-01 -full_link: https://kubernetes.io/docs/concepts/extend-kubernetes/extend-cluster/#extensions +full_link: /docs/concepts/extend-kubernetes/extend-cluster/#extensions short_description: > Extensions are software components that extend and deeply integrate with Kubernetes to support new types of hardware. @@ -15,4 +15,4 @@ tags: -Most cluster administrators will use a hosted or distribution instance of Kubernetes. As a result, most Kubernetes users will need to install [extensions](https://kubernetes.io/docs/concepts/extend-kubernetes/extend-cluster/#extensions) and fewer will need to author new ones. +Most cluster administrators will use a hosted or distribution instance of Kubernetes. As a result, most Kubernetes users will need to install [extensions](/docs/concepts/extend-kubernetes/extend-cluster/#extensions) and fewer will need to author new ones. diff --git a/content/en/docs/reference/glossary/flexvolume.md b/content/en/docs/reference/glossary/flexvolume.md index 612c1abed1..2b7abc0e86 100644 --- a/content/en/docs/reference/glossary/flexvolume.md +++ b/content/en/docs/reference/glossary/flexvolume.md @@ -2,7 +2,7 @@ title: Flexvolume id: flexvolume date: 2018-06-25 -full_link: https://kubernetes.io/docs/concepts/storage/volumes/#flexvolume +full_link: /docs/concepts/storage/volumes/#flexvolume short_description: > Flexvolume is an interface for creating out-of-tree volume plugins. The {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} is a newer interface which addresses several problems with Flexvolumes. @@ -17,6 +17,6 @@ tags: Flexvolumes enable users to write their own drivers and add support for their volumes in Kubernetes. FlexVolume driver binaries and dependencies must be installed on host machines. This requires root access. The Storage SIG suggests implementing a {{< glossary_tooltip text="CSI" term_id="csi" >}} driver if possible since it addresses the limitations with Flexvolumes. -* [Flexvolume in the Kubernetes documentation](https://kubernetes.io/docs/concepts/storage/volumes/#flexvolume) +* [Flexvolume in the Kubernetes documentation](/docs/concepts/storage/volumes/#flexvolume) * [More information on Flexvolumes](https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md) * [Volume Plugin FAQ for Storage Vendors](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md) diff --git a/content/en/docs/reference/glossary/host-aliases.md b/content/en/docs/reference/glossary/host-aliases.md index e67b1c25ce..fa92be21f4 100644 --- a/content/en/docs/reference/glossary/host-aliases.md +++ b/content/en/docs/reference/glossary/host-aliases.md @@ -2,7 +2,7 @@ title: HostAliases id: HostAliases date: 2019-01-31 -full_link: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.13/#hostalias-v1-core +full_link: /docs/reference/generated/kubernetes-api/v1.13/#hostalias-v1-core short_description: > A HostAliases is a mapping between the IP address and hostname to be injected into a Pod's hosts file. @@ -14,4 +14,4 @@ tags: -[HostAliases](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.13/#hostalias-v1-corev) is an optional list of hostnames and IP addresses that will be injected into the Pod's hosts file if specified. This is only valid for non-hostNetwork Pods. +[HostAliases](/docs/reference/generated/kubernetes-api/v1.13/#hostalias-v1-corev) is an optional list of hostnames and IP addresses that will be injected into the Pod's hosts file if specified. This is only valid for non-hostNetwork Pods. diff --git a/content/en/docs/reference/glossary/pod-disruption-budget.md b/content/en/docs/reference/glossary/pod-disruption-budget.md index ea5e30e08f..1665224174 100644 --- a/content/en/docs/reference/glossary/pod-disruption-budget.md +++ b/content/en/docs/reference/glossary/pod-disruption-budget.md @@ -15,5 +15,4 @@ tags: - operation --- - A [Pod Disruption Budget](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/) allows an application owner to create an object for a replicated application, that ensures a certain number or percentage of Pods with an assigned label will not be voluntarily evicted at any point in time. PDBs cannot prevent an involuntary disruption, but will count against the budget. - + A [Pod Disruption Budget](/docs/concepts/workloads/pods/disruptions/) allows an application owner to create an object for a replicated application, that ensures a certain number or percentage of Pods with an assigned label will not be voluntarily evicted at any point in time. PDBs cannot prevent an involuntary disruption, but will count against the budget. diff --git a/content/en/docs/reference/glossary/pod-lifecycle.md b/content/en/docs/reference/glossary/pod-lifecycle.md index caa588bb8c..554a20ca3c 100644 --- a/content/en/docs/reference/glossary/pod-lifecycle.md +++ b/content/en/docs/reference/glossary/pod-lifecycle.md @@ -9,8 +9,11 @@ related: tags: - fundamental short_description: > - A high-level summary of what phase the Pod is in within its lifecyle. + A high-level summary of what phase the Pod is in within its lifecyle. --- + A high-level summary of what phase the Pod is in within its lifecyle. -The [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/) is a high level summary of where a Pod is in its lifecyle. A Pod’s `status` field is a [PodStatus](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.13/#podstatus-v1-core) object, which has a `phase` field that displays one of the following phases: Running, Pending, Succeeded, Failed, Unknown, Completed, or CrashLoopBackOff. + + +The [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/) is a high level summary of where a Pod is in its lifecyle. A Pod’s `status` field is a [PodStatus](/docs/reference/generated/kubernetes-api/v1.13/#podstatus-v1-core) object, which has a `phase` field that displays one of the following phases: Running, Pending, Succeeded, Failed, Unknown, Completed, or CrashLoopBackOff. diff --git a/content/en/docs/reference/glossary/pod-priority.md b/content/en/docs/reference/glossary/pod-priority.md index 09d1caab15..0b80602b35 100644 --- a/content/en/docs/reference/glossary/pod-priority.md +++ b/content/en/docs/reference/glossary/pod-priority.md @@ -2,7 +2,7 @@ title: Pod Priority id: pod-priority date: 2019-01-31 -full_link: https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/#pod-priority +full_link: /docs/concepts/configuration/pod-priority-preemption/#pod-priority short_description: > Pod Priority indicates the importance of a Pod relative to other Pods. @@ -14,4 +14,4 @@ tags: -[Pod Priority](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/#pod-priority) gives the ability to set scheduling priority of a Pod to be higher and lower than other Pods — an important feature for production clusters workload. +[Pod Priority](/docs/concepts/configuration/pod-priority-preemption/#pod-priority) gives the ability to set scheduling priority of a Pod to be higher and lower than other Pods — an important feature for production clusters workload. diff --git a/content/en/docs/reference/glossary/preemption.md b/content/en/docs/reference/glossary/preemption.md index ac1334c979..0810acfcfc 100644 --- a/content/en/docs/reference/glossary/preemption.md +++ b/content/en/docs/reference/glossary/preemption.md @@ -2,7 +2,7 @@ title: Preemption id: preemption date: 2019-01-31 -full_link: https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/#preemption +full_link: /docs/concepts/configuration/pod-priority-preemption/#preemption short_description: > Preemption logic in Kubernetes helps a pending Pod to find a suitable Node by evicting low priority Pods existing on that Node. @@ -14,4 +14,4 @@ tags: -If a Pod cannot be scheduled, the scheduler tries to [preempt](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/#preemption) lower priority Pods to make scheduling of the pending Pod possible. +If a Pod cannot be scheduled, the scheduler tries to [preempt](/docs/concepts/configuration/pod-priority-preemption/#preemption) lower priority Pods to make scheduling of the pending Pod possible. diff --git a/content/en/docs/reference/glossary/replica-set.md b/content/en/docs/reference/glossary/replica-set.md index 0d53c9f31b..e2c09eed59 100755 --- a/content/en/docs/reference/glossary/replica-set.md +++ b/content/en/docs/reference/glossary/replica-set.md @@ -2,7 +2,7 @@ title: ReplicaSet id: replica-set date: 2018-04-12 -full_link: https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/ +full_link: /docs/concepts/workloads/controllers/replicaset/ short_description: > ReplicaSet is the next-generation Replication Controller. @@ -17,4 +17,3 @@ tags: ReplicaSet, like ReplicationController, ensures that a specified number of pods replicas are running at one time. ReplicaSet supports the new set-based selector requirements as described in the labels user guide, whereas a Replication Controller only supports equality-based selector requirements. - diff --git a/content/en/docs/reference/glossary/secret.md b/content/en/docs/reference/glossary/secret.md index e1290f8d7e..48088bbf9c 100755 --- a/content/en/docs/reference/glossary/secret.md +++ b/content/en/docs/reference/glossary/secret.md @@ -15,5 +15,4 @@ tags: -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/configure-pod-configmap/) for non-confidential data. - +Allows for more control over how sensitive information is used and reduces the risk of accidental exposure, including [encryption](/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](/docs/tasks/configure-pod-container/configure-pod-configmap/) for non-confidential data. diff --git a/content/en/docs/reference/issues-security/security.md b/content/en/docs/reference/issues-security/security.md index 26d04ab0f3..e67c7863aa 100644 --- a/content/en/docs/reference/issues-security/security.md +++ b/content/en/docs/reference/issues-security/security.md @@ -25,7 +25,7 @@ We’re extremely grateful for security researchers and users that report vulner To make a report, please email the private [security@kubernetes.io](mailto:security@kubernetes.io) list with the security details and the details expected for [all Kubernetes bug reports](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE/bug-report.md). -You may encrypt your email to this list using the GPG keys of the [Product Security Team members](https://git.k8s.io/sig-release/security-release-process-documentation/security-release-process.md#product-security-team-pst). Encryption using GPG is NOT required to make a disclosure. +You may encrypt your email to this list using the GPG keys of the [Product Security Committee members](https://git.k8s.io/security/security-release-process.md#product-security-committee-psc). Encryption using GPG is NOT required to make a disclosure. ### When Should I Report a Vulnerability? @@ -41,13 +41,13 @@ You may encrypt your email to this list using the GPG keys of the [Product Secur ## Security Vulnerability Response -Each report is acknowledged and analyzed by Product Security Team members within 3 working days. This will set off the [Security Release Process](https://git.k8s.io/sig-release/security-release-process-documentation/security-release-process.md#disclosures). +Each report is acknowledged and analyzed by Product Security Committee members within 3 working days. This will set off the [Security Release Process](https://git.k8s.io/security/security-release-process.md#disclosures). -Any vulnerability information shared with Product Security Team stays within Kubernetes project and will not be disseminated to other projects unless it is necessary to get the issue fixed. +Any vulnerability information shared with Product Security Committee stays within Kubernetes project and will not be disseminated to other projects unless it is necessary to get the issue fixed. As the security issue moves from triage, to identified fix, to release planning we will keep the reporter updated. ## Public Disclosure Timing -A public disclosure date is negotiated by the Kubernetes product security team and the bug submitter. We prefer to fully disclose the bug as soon as possible once a user mitigation is available. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested, or for vendor coordination. The timeframe for disclosure is from immediate (especially if it's already publicly known) to a few weeks. As a basic default, we expect report date to disclosure date to be on the order of 7 days. The Kubernetes product security team holds the final say when setting a disclosure date. +A public disclosure date is negotiated by the Kubernetes Product Security Committee and the bug submitter. We prefer to fully disclose the bug as soon as possible once a user mitigation is available. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested, or for vendor coordination. The timeframe for disclosure is from immediate (especially if it's already publicly known) to a few weeks. As a basic default, we expect report date to disclosure date to be on the order of 7 days. The Kubernetes Product Security Committee holds the final say when setting a disclosure date. {{% /capture %}} diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md index 47c9a505e5..47f9c3017d 100644 --- a/content/en/docs/reference/kubectl/cheatsheet.md +++ b/content/en/docs/reference/kubectl/cheatsheet.md @@ -58,11 +58,12 @@ kubectl config view # Show Merged kubeconfig settings. # use multiple kubeconfig files at the same time and view merged config KUBECONFIG=~/.kube/config:~/.kube/kubconfig2 kubectl config view -# Get the password for the e2e user +# get the password for the e2e user kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}' -kubectl config current-context # Display the current-context -kubectl config use-context my-cluster-name # set the default context to my-cluster-name +kubectl config view -o jsonpath='{.users[].name}' # get a list of users +kubectl config current-context # display the current-context +kubectl config use-context my-cluster-name # set the default context to my-cluster-name # add a new cluster to your kubeconf that supports basic auth kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword @@ -70,6 +71,8 @@ kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser - # set a context utilizing a specific username and namespace. kubectl config set-context gce --user=cluster-admin --namespace=foo \ && kubectl config use-context gce + +kubectl config unset users.foo # delete user foo ``` ## Creating Objects diff --git a/content/en/docs/reference/kubectl/kubectl.md b/content/en/docs/reference/kubectl/kubectl.md index d1851a3e3e..b5d188e57d 100755 --- a/content/en/docs/reference/kubectl/kubectl.md +++ b/content/en/docs/reference/kubectl/kubectl.md @@ -11,7 +11,7 @@ kubectl controls the Kubernetes cluster manager kubectl controls the Kubernetes cluster manager. -Find more information at: https://kubernetes.io/docs/reference/kubectl/overview/ +Find more information at: /docs/reference/kubectl/overview/ ``` kubectl [flags] @@ -311,4 +311,3 @@ kubectl [flags] * [kubectl uncordon](/docs/reference/generated/kubectl/kubectl-commands#uncordon) - Mark node as schedulable * [kubectl version](/docs/reference/generated/kubectl/kubectl-commands#version) - Print the client and server version information * [kubectl wait](/docs/reference/generated/kubectl/kubectl-commands#wait) - Experimental: Wait for a specific condition on one or many resources. - diff --git a/content/en/docs/reference/kubectl/overview.md b/content/en/docs/reference/kubectl/overview.md index b37233e860..bba5468c93 100644 --- a/content/en/docs/reference/kubectl/overview.md +++ b/content/en/docs/reference/kubectl/overview.md @@ -101,48 +101,58 @@ Remember: For more about command operations, see the [kubectl](/docs/user-guide/ ## Resource types -The following table includes a list of all the supported resource types and their abbreviated aliases: +The following table includes a list of all the supported resource types and their abbreviated aliases. -Resource type | Abbreviated alias --------------------- | -------------------- -`apiservices` | -`certificatesigningrequests` |`csr` -`clusters` | -`clusterrolebindings` | -`clusterroles` | -`componentstatuses` |`cs` -`configmaps` |`cm` -`controllerrevisions` | -`cronjobs` | -`customresourcedefinition` |`crd` -`daemonsets` |`ds` -`deployments` |`deploy` -`endpoints` |`ep` -`events` |`ev` -`horizontalpodautoscalers` |`hpa` -`ingresses` |`ing` -`jobs` | -`limitranges` |`limits` -`namespaces` |`ns` -`networkpolicies` |`netpol` -`nodes` |`no` -`persistentvolumeclaims` |`pvc` -`persistentvolumes` |`pv` -`poddisruptionbudget` |`pdb` -`podpreset` | -`pods` |`po` -`podsecuritypolicies` |`psp` -`podtemplates` | -`replicasets` |`rs` -`replicationcontrollers` |`rc` -`resourcequotas` |`quota` -`rolebindings` | -`roles` | -`secrets` | -`serviceaccounts` |`sa` -`services` |`svc` -`statefulsets` | -`storageclasses` | +(This output can be retrieved from `kubectl api-resources`, and is accurate as of Kubernetes 1.13.3.) + +| Resource Name | Short Names | API Group | Namespaced | Resource Kind | +|---|---|---|---|---| +| `componentstatuses` | `cs` | | false | ComponentStatus | +| `configmaps` | `cm` | | true | ConfigMap | +| `endpoints` | `ep` | | true | Endpoints | +| `limitranges` | `limits` | | true | LimitRange | +| `namespaces` | `ns` | | false | Namespace | +| `nodes` | `no` | | false | Node | +| `persistentvolumeclaims` | `pvc` | | true | PersistentVolumeClaim | +| `persistentvolumes` | `pv` | | false | PersistentVolume | +| `pods` | `po` | | true | Pod | +| `podtemplates` | | | true | PodTemplate | +| `replicationcontrollers` | `rc` | | true| ReplicationController | +| `resourcequotas` | `quota` | | true | ResourceQuota | +| `secrets` | | | true | Secret | +| `serviceaccounts` | `sa` | | true | ServiceAccount | +| `services` | `svc` | | true | Service | +| `mutatingwebhookconfigurations` | | admissionregistration.k8s.io | false | MutatingWebhookConfiguration | +| `validatingwebhookconfigurations` | | admissionregistration.k8s.io | false | ValidatingWebhookConfiguration | +| `customresourcedefinitions` | `crd`, `crds` | apiextensions.k8s.io | false | CustomResourceDefinition | +| `apiservices` | | apiregistration.k8s.io | false | APIService | +| `controllerrevisions` | | apps | true | ControllerRevision | +| `daemonsets` | `ds` | apps | true | DaemonSet | +| `deployments` | `deploy` | apps | true | Deployment | +| `replicasets` | `rs` | apps | true | ReplicaSet | +| `statefulsets` | `sts` | apps | true | StatefulSet | +| `tokenreviews` | | authentication.k8s.io | false | TokenReview | +| `localsubjectaccessreviews` | | authorization.k8s.io | true | LocalSubjectAccessReview | +| `selfsubjectaccessreviews` | | authorization.k8s.io | false | SelfSubjectAccessReview | +| `selfsubjectrulesreviews` | | authorization.k8s.io | false | SelfSubjectRulesReview | +| `subjectaccessreviews` | | authorization.k8s.io | false | SubjectAccessReview | +| `horizontalpodautoscalers` | `hpa` | autoscaling | true | HorizontalPodAutoscaler | +| `cronjobs` | `cj` | batch | true | CronJob | +| `jobs` | | batch | true | Job | +| `certificatesigningrequests` | `csr` | certificates.k8s.io | false | CertificateSigningRequest | +| `leases` | | coordination.k8s.io | true | Lease | +| `events` | `ev` | events.k8s.io | true | Event | +| `ingresses` | `ing` | extensions | true | Ingress | +| `networkpolicies` | `netpol` | networking.k8s.io | true | NetworkPolicy | +| `poddisruptionbudgets` | `pdb` | policy | true | PodDisruptionBudget | +| `podsecuritypolicies` | `psp` | policy | false | PodSecurityPolicy | +| `clusterrolebindings` | | rbac.authorization.k8s.io | false | ClusterRoleBinding | +| `clusterroles` | | rbac.authorization.k8s.io | false | ClusterRole | +| `rolebindings` | | rbac.authorization.k8s.io | true | RoleBinding | +| `roles` | | rbac.authorization.k8s.io | true | Role | +| `priorityclasses` | `pc` | scheduling.k8s.io | false | PriorityClass | +| `storageclasses` | `sc` | storage.k8s.io | false | StorageClass | +| `volumeattachments` | | storage.k8s.io | false | VolumeAttachment | ## Output options diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token.md index 3ba6f21456..0f57b4a9fd 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token.md @@ -20,7 +20,7 @@ What is a bootstrap token more exactly? - The name of the Secret must be named "bootstrap-token-(token-id)". You can read more about bootstrap tokens here: - https://kubernetes.io/docs/admin/bootstrap-tokens/ + /docs/admin/bootstrap-tokens/ ``` @@ -80,6 +80,3 @@ kubeadm token [flags] - - - diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md index 1130a20b1d..edeea8a103 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md @@ -283,7 +283,7 @@ In order to set up a cluster where the master and worker nodes communicate with ### Setting the node name By default, `kubeadm` assigns a node name based on a machine's host address. You can override this setting with the `--node-name`flag. -The flag passes the appropriate [`--hostname-override`](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/#options) +The flag passes the appropriate [`--hostname-override`](/docs/reference/command-line-tools-reference/kubelet/#options) to the kubelet. Be aware that overriding the hostname can [interfere with cloud providers](https://github.com/kubernetes/website/pull/8873). @@ -311,7 +311,7 @@ without manual intervention. This and other limitations are expected to be resolved before self-hosting graduates from alpha. By default, self-hosted control plane Pods rely on credentials loaded from -[`hostPath`](https://kubernetes.io/docs/concepts/storage/volumes/#hostpath) +[`hostPath`](/docs/concepts/storage/volumes/#hostpath) volumes. Except for initial creation, these credentials are not managed by kubeadm. diff --git a/content/en/docs/reference/setup-tools/kubefed/kubefed_join.md b/content/en/docs/reference/setup-tools/kubefed/kubefed_join.md index 7acf150340..8a514e1f5a 100644 --- a/content/en/docs/reference/setup-tools/kubefed/kubefed_join.md +++ b/content/en/docs/reference/setup-tools/kubefed/kubefed_join.md @@ -44,7 +44,7 @@ kubefed join CLUSTER_NAME --host-cluster-context=HOST_CONTEXT [flags] -h, --help help for join --host-cluster-context string Host cluster context --no-headers When using the default or custom-column output format, don't print headers (default print headers). - -o, --output string Output format. One of: json|yaml|wide|name|custom-columns=...|custom-columns-file=...|go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=... See custom columns [http://kubernetes.io/docs/user-guide/kubectl-overview/#custom-columns], golang template [http://golang.org/pkg/text/template/#pkg-overview] and jsonpath template [http://kubernetes.io/docs/user-guide/jsonpath]. + -o, --output string Output format. One of: json|yaml|wide|name|custom-columns=...|custom-columns-file=...|go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=... See custom columns [/docs/user-guide/kubectl-overview/#custom-columns], golang template [http://golang.org/pkg/text/template/#pkg-overview] and jsonpath template [/docs/user-guide/jsonpath]. --save-config If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future. -a, --show-all When printing, show all resources (default hide terminated pods.) --show-labels When printing, show all labels as the last column (default hide labels column) diff --git a/content/en/docs/reference/using-api/client-libraries.md b/content/en/docs/reference/using-api/client-libraries.md index e239976c70..99aff48a40 100644 --- a/content/en/docs/reference/using-api/client-libraries.md +++ b/content/en/docs/reference/using-api/client-libraries.md @@ -53,9 +53,11 @@ their authors, not the Kubernetes team. | Node.js (TypeScript) | [github.com/Goyoo/node-k8s-client](https://github.com/Goyoo/node-k8s-client) | | Node.js | [github.com/tenxcloud/node-kubernetes-client](https://github.com/tenxcloud/node-kubernetes-client) | | Node.js | [github.com/godaddy/kubernetes-client](https://github.com/godaddy/kubernetes-client) | +| Node.js | [github.com/ajpauwels/easy-k8s](https://github.com/ajpauwels/easy-k8s) | Perl | [metacpan.org/pod/Net::Kubernetes](https://metacpan.org/pod/Net::Kubernetes) | | PHP | [github.com/maclof/kubernetes-client](https://github.com/maclof/kubernetes-client) | | PHP | [github.com/allansun/kubernetes-php-client](https://github.com/allansun/kubernetes-php-client) | +| PHP | [github.com/travisghansen/kubernetes-client-php](https://github.com/travisghansen/kubernetes-client-php) | | Python | [github.com/eldarion-gondor/pykube](https://github.com/eldarion-gondor/pykube) | | Python | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) | | Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) | diff --git a/content/en/docs/setup/certificates.md b/content/en/docs/setup/certificates.md index 460bcf7db8..d8957389d5 100644 --- a/content/en/docs/setup/certificates.md +++ b/content/en/docs/setup/certificates.md @@ -63,8 +63,8 @@ Required certificates: | Default CN | Parent CA | O (in Subject) | kind | hosts (SAN) | |-------------------------------|---------------------------|----------------|----------------------------------------|---------------------------------------------| -| kube-etcd | etcd-ca | | server, client [1][etcdbug] | `localhost`, `127.0.0.1` | -| kube-etcd-peer | etcd-ca | | server, client | ``, ``, `localhost`, `127.0.0.1` | +| kube-etcd | etcd-ca | | server, client | `localhost`, `127.0.0.1` | +| kube-etcd-peer | etcd-ca | | server, client | ``, ``, `localhost`, `127.0.0.1` | | kube-etcd-healthcheck-client | etcd-ca | | client | | | kube-apiserver-etcd-client | etcd-ca | system:masters | client | | | kube-apiserver | kubernetes-ca | | server | ``, ``, ``, `[1]` | diff --git a/content/en/docs/setup/independent/create-cluster-kubeadm.md b/content/en/docs/setup/independent/create-cluster-kubeadm.md index c34921894e..5a7bc6956c 100644 --- a/content/en/docs/setup/independent/create-cluster-kubeadm.md +++ b/content/en/docs/setup/independent/create-cluster-kubeadm.md @@ -88,7 +88,7 @@ timeframe; which also applies to `kubeadm`. ## Objectives -* Install a single master Kubernetes cluster or [high availability cluster](https://kubernetes.io/docs/setup/independent/high-availability/) +* Install a single master Kubernetes cluster or [high availability cluster](/docs/setup/independent/high-availability/) * Install a Pod network on the cluster so that your Pods can talk to each other @@ -210,7 +210,7 @@ To start using your cluster, you need to run the following as a regular user: You should now deploy a pod network to the cluster. Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at: - https://kubernetes.io/docs/concepts/cluster-administration/addons/ + /docs/concepts/cluster-administration/addons/ You can now join any number of machines by running the following on each node as root: @@ -334,7 +334,7 @@ For `flannel` to work correctly, you must pass `--pod-network-cidr=10.244.0.0/16 Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1` to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information -please see [here](https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements). +please see [here](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements). Note that `flannel` works on `amd64`, `arm`, `arm64`, `ppc64le` and `s390x` under Linux. Windows (`amd64`) is claimed as supported in v0.11.0 but the usage is undocumented. @@ -350,7 +350,7 @@ For more information about `flannel`, see [the CoreOS flannel repository on GitH {{% tab name="Kube-router" %}} Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1` to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information -please see [here](https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements). +please see [here](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements). Kube-router relies on kube-controller-manager to allocate pod CIDR for the nodes. Therefore, use `kubeadm init` with the `--pod-network-cidr` flag. @@ -362,7 +362,7 @@ For information on setting up Kubernetes cluster with Kube-router using kubeadm, {{% tab name="Romana" %}} Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1` to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information -please see [here](https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements). +please see [here](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements). The official Romana set-up guide is [here](https://github.com/romana/romana/tree/master/containerize#using-kubeadm). @@ -376,7 +376,7 @@ kubectl apply -f https://raw.githubusercontent.com/romana/romana/master/containe {{% tab name="Weave Net" %}} Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1` to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information -please see [here](https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements). +please see [here](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements). The official Weave Net set-up guide is [here](https://www.weave.works/docs/net/latest/kube-addon/). @@ -663,7 +663,3 @@ addressed in due course. ## Troubleshooting {#troubleshooting} If you are running into difficulties with kubeadm, please consult our [troubleshooting docs](/docs/setup/independent/troubleshooting-kubeadm/). - - - - diff --git a/content/en/docs/setup/independent/troubleshooting-kubeadm.md b/content/en/docs/setup/independent/troubleshooting-kubeadm.md index 359ce55b74..b69979ecd1 100644 --- a/content/en/docs/setup/independent/troubleshooting-kubeadm.md +++ b/content/en/docs/setup/independent/troubleshooting-kubeadm.md @@ -130,7 +130,7 @@ services](/docs/concepts/services-networking/service/#nodeport) or use `HostNetw ## Pods are not accessible via their Service IP -- Many network add-ons do not yet enable [hairpin mode](https://kubernetes.io/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip) +- Many network add-ons do not yet enable [hairpin mode](/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip) which allows pods to access themselves via their Service IP. This is an issue related to [CNI](https://github.com/containernetworking/cni/issues/476). Please contact the network add-on provider to get the latest status of their support for hairpin mode. @@ -278,6 +278,6 @@ Alternativelly, you can try separating the `key=value` pairs like so: but this will result in the key `enable-admission-plugins` only having the value of `NamespaceExists`. A known workaround is to use the kubeadm -[configuration file](https://kubernetes.io/docs/setup/independent/control-plane-flags/#apiserver-flags). +[configuration file](/docs/setup/independent/control-plane-flags/#apiserver-flags). {{% /capture %}} diff --git a/content/en/docs/setup/pick-right-solution.md b/content/en/docs/setup/pick-right-solution.md index 05df472220..c0316c043e 100644 --- a/content/en/docs/setup/pick-right-solution.md +++ b/content/en/docs/setup/pick-right-solution.md @@ -52,11 +52,13 @@ a Kubernetes cluster from scratch. * [Kubeadm-dind](https://github.com/kubernetes-sigs/kubeadm-dind-cluster) is a multi-node (while minikube is single-node) Kubernetes cluster which only requires a docker daemon. It uses docker-in-docker technique to spawn the Kubernetes cluster. +* [Kubernetes IN Docker](https://github.com/kubernetes-sigs/kind) is a tool for running local Kubernetes clusters using Docker container "nodes". It is primarily designed for testing Kubernetes 1.11+. You can use it to create multi-node or multi-control-plane Kubernetes clusters. + ### Ecosystem Tools * [Docker Desktop](https://www.docker.com/products/docker-desktop) is an easy-to-install application for your Mac or Windows environment that enables you to -start coding and deploying in containers in minutes on a single-node Kubernetes +start coding and deploying in containers in minutes on a single-node Kubernetes cluster. * [Minishift](https://docs.okd.io/latest/minishift/) installs the community version of the Kubernetes enterprise platform OpenShift for local development & testing. It offers an all-in-one VM (`minishift start`) for Windows, macOS, and Linux. The container start is based on `oc cluster up` (Linux only). You can also install [the included add-ons](https://github.com/minishift/minishift-addons/tree/master/add-ons). @@ -67,8 +69,6 @@ cluster. * [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers) is a Terraform/Packer/BASH based Infrastructure as Code (IaC) scripts to create a seven node (1 Boot, 1 Master, 1 Management, 1 Proxy and 3 Workers) LXD cluster on Linux Host. -* [Kind](https://kind.sigs.k8s.io/), Kubernetes IN Docker is a tool for running local Kubernetes clusters using Docker containers as "nodes". It is primarily designed for testing Kubernetes, initially targeting the conformance tests. - * [Ubuntu on LXD](/docs/getting-started-guides/ubuntu/local/) supports a nine-instance deployment on localhost. ## Hosted Solutions @@ -113,6 +113,8 @@ cluster. * [SysEleven MetaKube](https://www.syseleven.io/products-services/managed-kubernetes/) offers managed Kubernetes as a service powered on our OpenStack public cloud. It includes lifecycle management, administration dashboards, monitoring, autoscaling and much more. +* [VEXXHOST](https://vexxhost.com/public-cloud/container-services/kubernetes/) VEXXHOST proudly offers Certified Kubernetes on our public cloud, which also happens to be the largest OpenStack public cloud in Canada. + * [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) is an enterprise Kubernetes-as-a-Service offering in the VMware Cloud Services portfolio that provides easy to use, secure by default, cost effective, SaaS-based Kubernetes clusters. ## Turnkey Cloud Solutions @@ -144,6 +146,7 @@ few commands. These solutions are actively developed and have active community s * [Rancher 2.0](https://rancher.com/docs/rancher/v2.x/en/) * [Stackpoint.io](/docs/setup/turnkey/stackpoint/) * [Supergiant.io](https://supergiant.io/) +* [VEXXHOST](https://vexxhost.com/private-cloud/) * [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) * [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) @@ -231,57 +234,58 @@ Below is a table of all of the solutions listed above. IaaS Provider | Config. Mgmt. | OS | Networking | Docs | Support Level -------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------------------------- +Agile Stacks | Terraform | CoreOS | multi-support | [docs](https://www.agilestacks.com/products/kubernetes) | Commercial +Alibaba Cloud Container Service For Kubernetes | ROS | CentOS | flannel/Terway | [docs](https://www.aliyun.com/product/containerservice) | Commercial any | any | multi-support | any CNI | [docs](/docs/setup/independent/create-cluster-kubeadm/) | Project ([SIG-cluster-lifecycle](https://git.k8s.io/community/sig-cluster-lifecycle)) -Google Kubernetes Engine | | | GCE | [docs](https://cloud.google.com/kubernetes-engine/docs/) | Commercial -Docker Enterprise | custom | [multi-support](https://success.docker.com/article/compatibility-matrix) | [multi-support](https://docs.docker.com/ee/ucp/kubernetes/install-cni-plugin/) | [docs](https://docs.docker.com/ee/) | Commercial -IBM Cloud Private | Ansible | multi-support | multi-support | [docs](https://www.ibm.com/support/knowledgecenter/SSBS6K/product_welcome_cloud_private.html) | [Commercial](https://www.ibm.com/mysupport/s/topic/0TO500000001o0fGAA/ibm-cloud-private?language=en_US&productId=01t50000004X1PWAA0) and [Community](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/troubleshoot/support_types.html) | -Red Hat OpenShift | Ansible & CoreOS | RHEL & CoreOS | [multi-support](https://docs.openshift.com/container-platform/3.11/architecture/networking/network_plugins.html) | [docs](https://docs.openshift.com/container-platform/3.11/welcome/index.html) | Commercial -Stackpoint.io | | multi-support | multi-support | [docs](https://stackpoint.io/) | Commercial -AppsCode.com | Saltstack | Debian | multi-support | [docs](https://appscode.com/products/cloud-deployment/) | Commercial -Madcore.Ai | Jenkins DSL | Ubuntu | flannel | [docs](https://madcore.ai) | Community ([@madcore-ai](https://github.com/madcore-ai)) -Platform9 | | multi-support | multi-support | [docs](https://platform9.com/managed-kubernetes/) | Commercial -Kublr | custom | multi-support | multi-support | [docs](http://docs.kublr.com/) | Commercial -Kubermatic | | multi-support | multi-support | [docs](http://docs.kubermatic.io/) | Commercial -IBM Cloud Kubernetes Service | | Ubuntu | IBM Cloud Networking + Calico | [docs](https://cloud.ibm.com/docs/containers?topic=containers-container_index#container_index) | Commercial -Giant Swarm | | CoreOS | flannel and/or Calico | [docs](https://docs.giantswarm.io/) | Commercial -GCE | Saltstack | Debian | GCE | [docs](/docs/setup/turnkey/gce/) | Project -Azure Kubernetes Service | | Ubuntu | Azure | [docs](https://docs.microsoft.com/en-us/azure/aks/) | Commercial -Azure (IaaS) | | Ubuntu | Azure | [docs](/docs/setup/turnkey/azure/) | [Community (Microsoft)](https://github.com/Azure/acs-engine) -Bare-metal | custom | Fedora | _none_ | [docs](/docs/getting-started-guides/fedora/fedora_manual_config/) | Project -Bare-metal | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | Community ([@aveshagarwal](https://github.com/aveshagarwal)) -libvirt | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | Community ([@aveshagarwal](https://github.com/aveshagarwal)) -KVM | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | Community ([@aveshagarwal](https://github.com/aveshagarwal)) -DCOS | Marathon | CoreOS/Alpine | custom | [docs](/docs/getting-started-guides/dcos/) | Community ([Kubernetes-Mesos Authors](https://github.com/mesosphere/kubernetes-mesos/blob/master/AUTHORS.md)) -CloudStack | Ansible | CoreOS | flannel | [docs](/docs/getting-started-guides/cloudstack/) | Community ([@sebgoa](https://github.com/sebgoa)) -VMware vSphere | any | multi-support | multi-support | [docs](https://github.com/kubernetes/cloud-provider-vsphere/tree/master/docs) | [Community](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/contactus.html) -Bare-metal | custom | CentOS | flannel | [docs](/docs/getting-started-guides/centos/centos_manual_config/) | Community ([@coolsvap](https://github.com/coolsvap)) -lxd | Juju | Ubuntu | flannel/canal | [docs](/docs/getting-started-guides/ubuntu/local/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) -AWS | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) -Azure | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) -GCE | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) -Oracle Cloud | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) -Rackspace | custom | CoreOS | flannel/calico/canal | [docs](https://developer.rackspace.com/docs/rkaas/latest/) | [Commercial](https://www.rackspace.com/managed-kubernetes) -VMware vSphere | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) -Bare Metal | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) -AWS | Saltstack | Debian | AWS | [docs](/docs/setup/turnkey/aws/) | Community ([@justinsb](https://github.com/justinsb)) -AWS | kops | Debian | AWS | [docs](https://github.com/kubernetes/kops/) | Community ([@justinsb](https://github.com/justinsb)) -Bare-metal | custom | Ubuntu | flannel | [docs](/docs/getting-started-guides/ubuntu/) | Community ([@resouer](https://github.com/resouer), [@WIZARD-CXY](https://github.com/WIZARD-CXY)) -oVirt | | | | [docs](/docs/setup/on-premises-vm/ovirt/) | Community ([@simon3z](https://github.com/simon3z)) +any | any | any | any | [docs](/docs/setup/scratch/) | Community ([@erictune](https://github.com/erictune)) any | any | any | any | [docs](http://docs.projectcalico.org/v2.2/getting-started/kubernetes/installation/) | Commercial and Community any | RKE | multi-support | flannel or canal | [docs](https://rancher.com/docs/rancher/v2.x/en/quick-start-guide/) | [Commercial](https://rancher.com/what-is-rancher/overview/) and [Community](https://github.com/rancher/rancher) any | [Gardener Cluster-Operator](https://kubernetes.io/blog/2018/05/17/gardener/) | multi-support | multi-support | [docs](https://gardener.cloud) | [Project/Community](https://github.com/gardener) and [Commercial]( https://cloudplatform.sap.com/) -Alibaba Cloud Container Service For Kubernetes | ROS | CentOS | flannel/Terway | [docs](https://www.aliyun.com/product/containerservice) | Commercial -Agile Stacks | Terraform | CoreOS | multi-support | [docs](https://www.agilestacks.com/products/kubernetes) | Commercial -IBM Cloud Kubernetes Service | | Ubuntu | calico | [docs](https://cloud.ibm.com/docs/containers?topic=containers-container_index#container_index) | Commercial +AppsCode.com | Saltstack | Debian | multi-support | [docs](https://appscode.com/products/cloud-deployment/) | Commercial +AWS | CoreOS | CoreOS | flannel | [docs](/docs/setup/turnkey/aws/) | Community +AWS | Saltstack | Debian | AWS | [docs](/docs/setup/turnkey/aws/) | Community ([@justinsb](https://github.com/justinsb)) +AWS | kops | Debian | AWS | [docs](https://github.com/kubernetes/kops/) | Community ([@justinsb](https://github.com/justinsb)) +AWS | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) +Azure | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) +Azure (IaaS) | | Ubuntu | Azure | [docs](/docs/setup/turnkey/azure/) | [Community (Microsoft)](https://github.com/Azure/acs-engine) +Azure Kubernetes Service | | Ubuntu | Azure | [docs](https://docs.microsoft.com/en-us/azure/aks/) | Commercial +Bare-metal | custom | CentOS | flannel | [docs](/docs/getting-started-guides/centos/centos_manual_config/) | Community ([@coolsvap](https://github.com/coolsvap)) +Bare-metal | custom | Fedora | _none_ | [docs](/docs/getting-started-guides/fedora/fedora_manual_config/) | Project +Bare-metal | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | Community ([@aveshagarwal](https://github.com/aveshagarwal)) +Bare Metal | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) +Bare-metal | custom | Ubuntu | flannel | [docs](/docs/getting-started-guides/ubuntu/) | Community ([@resouer](https://github.com/resouer), [@WIZARD-CXY](https://github.com/WIZARD-CXY)) +CloudStack | Ansible | CoreOS | flannel | [docs](/docs/getting-started-guides/cloudstack/) | Community ([@sebgoa](https://github.com/sebgoa)) +DCOS | Marathon | CoreOS/Alpine | custom | [docs](/docs/getting-started-guides/dcos/) | Community ([Kubernetes-Mesos Authors](https://github.com/mesosphere/kubernetes-mesos/blob/master/AUTHORS.md)) Digital Rebar | kubeadm | any | metal | [docs](/docs/setup/on-premises-metal/krib/) | Community ([@digitalrebar](https://github.com/digitalrebar)) +Docker Enterprise | custom | [multi-support](https://success.docker.com/article/compatibility-matrix) | [multi-support](https://docs.docker.com/ee/ucp/kubernetes/install-cni-plugin/) | [docs](https://docs.docker.com/ee/) | Commercial +Giant Swarm | | CoreOS | flannel and/or Calico | [docs](https://docs.giantswarm.io/) | Commercial +GCE | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/coreos/) | Community ([@pires](https://github.com/pires)) +GCE | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) +GCE | Saltstack | Debian | GCE | [docs](/docs/setup/turnkey/gce/) | Project +Google Kubernetes Engine | | | GCE | [docs](https://cloud.google.com/kubernetes-engine/docs/) | Commercial +IBM Cloud Kubernetes Service | | Ubuntu | IBM Cloud Networking + Calico | [docs](https://cloud.ibm.com/docs/containers?topic=containers-container_index#container_index) | Commercial +IBM Cloud Kubernetes Service | | Ubuntu | calico | [docs](https://cloud.ibm.com/docs/containers?topic=containers-container_index#container_index) | Commercial +IBM Cloud Private | Ansible | multi-support | multi-support | [docs](https://www.ibm.com/support/knowledgecenter/SSBS6K/product_welcome_cloud_private.html) | [Commercial](https://www.ibm.com/mysupport/s/topic/0TO500000001o0fGAA/ibm-cloud-private?language=en_US&productId=01t50000004X1PWAA0) and [Community](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/troubleshoot/support_types.html) | +Kublr | custom | multi-support | multi-support | [docs](http://docs.kublr.com/) | Commercial +Kubermatic | | multi-support | multi-support | [docs](http://docs.kubermatic.io/) | Commercial +KVM | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | Community ([@aveshagarwal](https://github.com/aveshagarwal)) +libvirt | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | Community ([@aveshagarwal](https://github.com/aveshagarwal)) +lxd | Juju | Ubuntu | flannel/canal | [docs](/docs/getting-started-guides/ubuntu/local/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) +Madcore.Ai | Jenkins DSL | Ubuntu | flannel | [docs](https://madcore.ai) | Community ([@madcore-ai](https://github.com/madcore-ai)) +Mirantis Cloud Platform | Salt | Ubuntu | multi-support | [docs](https://docs.mirantis.com/mcp/) | Commercial +Oracle Cloud Infrastructure | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) +Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) | | | multi-support | [docs](https://docs.cloud.oracle.com/iaas/Content/ContEng/Concepts/contengoverview.htm) | Commercial +oVirt | | | | [docs](/docs/setup/on-premises-vm/ovirt/) | Community ([@simon3z](https://github.com/simon3z)) +Platform9 | | multi-support | multi-support | [docs](https://platform9.com/managed-kubernetes/) | Commercial +Rackspace | custom | CoreOS | flannel/calico/canal | [docs](https://developer.rackspace.com/docs/rkaas/latest/) | [Commercial](https://www.rackspace.com/managed-kubernetes) +Red Hat OpenShift | Ansible & CoreOS | RHEL & CoreOS | [multi-support](https://docs.openshift.com/container-platform/3.11/architecture/networking/network_plugins.html) | [docs](https://docs.openshift.com/container-platform/3.11/welcome/index.html) | Commercial +Stackpoint.io | | multi-support | multi-support | [docs](https://stackpoint.io/) | Commercial +Vagrant | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/coreos/) | Community ([@pires](https://github.com/pires), [@AntonioMeireles](https://github.com/AntonioMeireles)) +VMware vSphere | any | multi-support | multi-support | [docs](https://github.com/kubernetes/cloud-provider-vsphere/tree/master/docs) | [Community](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/contactus.html) +VMware vSphere | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) VMware Cloud PKS | | Photon OS | Canal | [docs](https://docs.vmware.com/en/VMware-Kubernetes-Engine/index.html) | Commercial VMware Enterprise PKS | BOSH | Ubuntu | VMware NSX-T/flannel | [docs](https://docs.vmware.com/en/VMware-Enterprise-PKS/) | Commercial -Mirantis Cloud Platform | Salt | Ubuntu | multi-support | [docs](https://docs.mirantis.com/mcp/) | Commercial -IAAS Provider- Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) | | | multi-support | [docs](https://docs.cloud.oracle.com/iaas/Content/ContEng/Concepts/contengoverview.htm) | Commercial - -{{< note >}} -The above table is ordered by version test/used in nodes, followed by support level. -{{< /note >}} +VMware Essential PKS | any | multi-support | multi-support | [docs](https://cloud.vmware.com/vmware-essential-PKS) | Commercial ### Definition of columns @@ -291,8 +295,6 @@ The above table is ordered by version test/used in nodes, followed by support le nodes. * **Networking** is what implements the [networking model](/docs/concepts/cluster-administration/networking/). Those with networking type _none_ may not support more than a single node, or may support multiple VM nodes in a single physical node. -* **Conformance** indicates whether a cluster created with this configuration has passed the project's conformance - tests for supporting the API and base features of Kubernetes v1.0.0. * **Support Levels** * **Project**: Kubernetes committers regularly use this configuration, so it usually works with the latest release of Kubernetes. diff --git a/content/en/docs/setup/release/notes.md b/content/en/docs/setup/release/notes.md index c024e44135..43ff3e6191 100644 --- a/content/en/docs/setup/release/notes.md +++ b/content/en/docs/setup/release/notes.md @@ -106,7 +106,7 @@ Before upgrading to Kubernetes 1.13, you must keep the following in mind: - kubelet - Use of the beta plugin registration directory `{kubelet_root_dir}/plugins/` for registration of external drivers via the kubelet plugin registration protocol is deprecated in favor of `{kubelet_root_dir}/plugins_registry/`. Support for the old directory is planned to be removed in v1.15. Device plugin and CSI storage drivers should switch to the new directory prior to v1.15. Only CSI storage drivers that support 0.x versions of the CSI API are allowed in the old directory. ([#70494](https://github.com/kubernetes/kubernetes/pull/70494) by [@RenaudWasTaken](https://github.com/RenaudWasTaken) and [#71314](https://github.com/kubernetes/kubernetes/pull/71314) by [@saad-ali](https://github.com/saad-ali)) - With the release of the CSI 1.0 API, support for CSI drivers using 0.3 and older releases of the CSI API is deprecated, and is planned to be removed in Kubernetes v1.15. CSI drivers should be updated to support the CSI 1.0 API, and deployed in the new kubelet plugin registration directory (`{kubelet_root_dir}/plugins_registry/`) once all nodes in the cluster are at 1.13 or higher ([#71020](https://github.com/kubernetes/kubernetes/pull/71020) and [#71314](https://github.com/kubernetes/kubernetes/pull/71314), both by [@saad-ali](https://github.com/saad-ali)) - - Use of the `--node-labels` flag to set labels under the `kubernetes.io/` and `k8s.io/` prefix will be subject to restriction by the `NodeRestriction` admission plugin in future releases. [See admission plugin documentation](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction) for allowed labels. ([#68267](https://github.com/kubernetes/kubernetes/pull/68267), [@liggitt](https://github.com/liggitt)) + - Use of the `--node-labels` flag to set labels under the `kubernetes.io/` and `k8s.io/` prefix will be subject to restriction by the `NodeRestriction` admission plugin in future releases. [See admission plugin documentation](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) for allowed labels. ([#68267](https://github.com/kubernetes/kubernetes/pull/68267), [@liggitt](https://github.com/liggitt)) - kube-scheduler - The alpha critical pod annotation (`scheduler.alpha.kubernetes.io/critical-pod`) is deprecated. Pod priority should be used instead to mark pods as critical. ([#70298](https://github.com/kubernetes/kubernetes/pull/70298), [@bsalamat](https://github.com/bsalamat)) - The following features are now GA, and the associated feature gates are deprecated and will be removed in a future release: @@ -131,7 +131,7 @@ For the 1.13 release, SIG API Machinery is happy to announce that the [dry-run f ### SIG Auth -With this release we've made several important enhancements to core SIG Auth areas. In the authorization category, we've further reduced Kubelet privileges by [restricting node self-updates of labels to a whitelisted selection and by disallowing kubelets from deleting their Node API object](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction). In authentication, we added alpha-level support for automounting improved service account tokens through projected volumes. We also enabled [audience validation in TokenReview](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.13/#tokenreview-v1-authentication-k8s-io) for the new tokens for improved scoping. Under audit logging, the new alpha-level "dynamic audit configuration" adds support for [dynamically registering webhooks to receive a stream of audit events](https://kubernetes.io/docs/tasks/debug-application-cluster/audit/#dynamic-backend). Finally, we've enhanced secrets protection by graduating [etcd encryption](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) out of experimental. +With this release we've made several important enhancements to core SIG Auth areas. In the authorization category, we've further reduced Kubelet privileges by [restricting node self-updates of labels to a whitelisted selection and by disallowing kubelets from deleting their Node API object](/docs/reference/access-authn-authz/admission-controllers/#noderestriction). In authentication, we added alpha-level support for automounting improved service account tokens through projected volumes. We also enabled [audience validation in TokenReview](/docs/reference/generated/kubernetes-api/v1.13/#tokenreview-v1-authentication-k8s-io) for the new tokens for improved scoping. Under audit logging, the new alpha-level "dynamic audit configuration" adds support for [dynamically registering webhooks to receive a stream of audit events](/docs/tasks/debug-application-cluster/audit/#dynamic-backend). Finally, we've enhanced secrets protection by graduating [etcd encryption](/docs/tasks/administer-cluster/encrypt-data/) out of experimental. ### SIG AWS @@ -157,7 +157,7 @@ During the 1.13 release cycle, SIG Big Data has been focused on community engage ### SIG CLI -Over the course of 1.13 release SIG CLI mostly focused on stabilizing the items we’ve been working on over the past releases such as server-side printing and its support in kubectl, as well as finishing [kubectl diff which is based on server-side dry-run feature](https://kubernetes.io/docs/concepts/overview/object-management-kubectl/#how-to-create-objects). We’ve continued separating kubectl code to prepare for extraction out of main repository. Finally, thanks to the awesome support and feedback from community we’ve managed to promote the new [plugin mechanism to Beta](https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/). +Over the course of 1.13 release SIG CLI mostly focused on stabilizing the items we’ve been working on over the past releases such as server-side printing and its support in kubectl, as well as finishing [kubectl diff which is based on server-side dry-run feature](/docs/concepts/overview/object-management-kubectl/#how-to-create-objects). We’ve continued separating kubectl code to prepare for extraction out of main repository. Finally, thanks to the awesome support and feedback from community we’ve managed to promote the new [plugin mechanism to Beta](/docs/tasks/extend-kubectl/kubectl-plugins/). ### SIG Cloud Provider @@ -233,7 +233,7 @@ With CSI the Kubernetes volume layer becomes truly extensible, allowing third pa CSI was first introduction as alpha in Kubernetes v1.9 and moved to beta in Kubernetes v1.10. -You can find a list of sample and production drivers in the [CSI Documentation](https://kubernetes.io/docs/concepts/storage/volumes/#csi). +You can find a list of sample and production drivers in the [CSI Documentation](/docs/concepts/storage/volumes/#csi). SIG Storage also moves support for Block Volumes to beta (introduced as alpha in v1.9) and support for Topology Aware Volume Scheduling to stable (introduced as alpha in v1.9 and promoted to beta in 1.10). @@ -1228,4 +1228,3 @@ filename | sha512 hash * Get public IP for Azure vmss nodes. ([#68498](https://github.com/kubernetes/kubernetes/pull/68498), [@feiskyer](https://github.com/feiskyer)) * test/integration: add a basic test for covering CronJobs ([#66937](https://github.com/kubernetes/kubernetes/pull/66937), [@mortent](https://github.com/mortent)) * Make service environment variables optional ([#68754](https://github.com/kubernetes/kubernetes/pull/68754), [@bradhoekstra](https://github.com/bradhoekstra)) - diff --git a/content/en/docs/setup/version-skew-policy.md b/content/en/docs/setup/version-skew-policy.md index 6903c6cf5b..e2078028e1 100644 --- a/content/en/docs/setup/version-skew-policy.md +++ b/content/en/docs/setup/version-skew-policy.md @@ -37,7 +37,7 @@ Minor releases occur approximately every 3 months, so each minor release branch ### kube-apiserver -In [highly-availabile (HA) clusters](https://kubernetes.io/docs/setup/independent/high-availability/), the newest and oldest `kube-apiserver` instances must be within one minor version. +In [highly-availabile (HA) clusters](/docs/setup/independent/high-availability/), the newest and oldest `kube-apiserver` instances must be within one minor version. Example: @@ -119,7 +119,7 @@ Pre-requisites: Upgrade `kube-apiserver` to **1.(n+1)** {{< note >}} -Project policies for [API deprecation](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) and +Project policies for [API deprecation](/docs/reference/using-api/deprecation-policy/) and [API change guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/api_changes.md) require `kube-apiserver` to not skip minor versions when upgrading, even in single-instance clusters. {{< /note >}} diff --git a/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index 55d5c6873d..8ab3e1007a 100644 --- a/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -85,6 +85,10 @@ kubectl config --kubeconfig=config-demo set-credentials developer --client-certi kubectl config --kubeconfig=config-demo set-credentials experimenter --username=exp --password=some-password ``` +{{< note >}} +To delete a user you can run `kubectl config unset users.` +{{< /note >}} + Add context details to your configuration file: ```shell diff --git a/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md b/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md index a66be5a1ad..e5a8f1932b 100644 --- a/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md +++ b/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md @@ -19,12 +19,16 @@ Configuring the [aggregation layer](/docs/concepts/extend-kubernetes/api-extensi {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} {{< note >}} -There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the master CA. +There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the master CA. + +{{< caution >}} +Reusing the same CA for different client types can negatively impact the cluster's ability to function. For more information, see ["CA Reusage and Conflicts"][ca-reusage-and-conflicts]. +{{< /caution >}} {{< /note >}} {{% /capture %}} -{{% capture authflow %}} +{{% capture steps %}} ## Authentication Flow @@ -182,10 +186,6 @@ In order for the extension apiserver to be authorized itself to submit the `Subj If the `SubjectAccessReview` passes, the extension apiserver executes the request. -{{% /capture %}} - -{{% capture steps %}} - ## Enable Kubernetes Apiserver flags Enable the aggregation layer via the following `kube-apiserver` flags. They may have already been taken care of by your provider. @@ -198,6 +198,22 @@ Enable the aggregation layer via the following `kube-apiserver` flags. They may --proxy-client-cert-file= --proxy-client-key-file= +### CA Reusage and Conflicts + +The Kubernetes apiserver has two client CA options: + +* `--client-ca-file` +* `--requestheader-client-ca-file` + +Each of these functions independently and can conflict with each other, if not used correctly. + +* `--client-ca-file`: When a request arrives to the Kubernetes apiserver, if this option is enabled, the Kubernetes apiserver checks the certificate of the request. If it is signed by one of the CA certificates in the file referenced by `--client-ca-file`, then the request is treated as a legitimate request, and the user is the value of the common name `CN=`, while the group is the organization `O=`. See the [documentaton on TLS authentication](/docs/reference/access-authn-authz/authentication/#x509-client-certs). +* `--requestheader-client-ca-file`: When a request arrives to the Kubernetes apiserver, if this option is enabled, the Kubernetes apiserver checks the certificate of the request. If it is signed by one of the CA certificates in the file reference by `--requestheader-client-ca-file`, then the request is treated as a potentially legitimate request. The Kubernetes apiserver then checks if the common name `CN=` is one of the names in the list provided by `--requestheader-allowed-names`. If the name is allowed, the request is approved; if it is not, the request is not. + +If _both_ `--client-ca-file` and `--requestheader-client-ca-file` are provided, then the request first checks the `--requestheader-client-ca-file` CA and then the `--client-ca-file`. Normally, different CAs, either root CAs or intermediate CAs, are used for each of these options; regular client requests match against `--client-ca-file`, while aggregation requests match against `--requestheader-client-ca-file`. However, if both use the _same_ CA, then client requests that normally would pass via `--client-ca-file` will fail, because the CA will match the CA in `--requestheader-client-ca-file`, but the common name `CN=` will **not** match one of the acceptable common names in `--requestheader-allowed-names`. This can cause your kubelets and other control plane components, as well as end-users, to be unable to authenticate to the Kubernetes apiserver. + +For this reason, use different CA certs for the `--client-ca-file` option - to authorize control plane components and end-users - and the `--requestheader-client-ca-file` option - to authorize aggregation apiserver requests. + {{< warning >}} Do **not** reuse a CA that is used in a different context unless you understand the risks and the mechanisms to protect the CA's usage. {{< /warning >}} diff --git a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md b/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md index 275955c8f5..4e8effea64 100644 --- a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md +++ b/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md @@ -149,7 +149,7 @@ the version. {{< note >}} Webhook conversion is introduced in Kubernetes 1.13 as an alpha feature. To use it, the -`CustomResourceWebhookConversion` feature should be enabled. Please refer to the [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) documentation for more information. +`CustomResourceWebhookConversion` feature should be enabled. Please refer to the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) documentation for more information. {{< /note >}} The above example has a None conversion between versions which only sets the `apiVersion` field diff --git a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md b/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md index fddff0fcbe..ab18190bf5 100644 --- a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md +++ b/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md @@ -228,7 +228,7 @@ meaning all finalizers have been executed. {{< feature-state state="beta" for_kubernetes_version="1.9" >}} Validation of custom objects is possible via -[OpenAPI v3 schema](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#schemaObject) or [validatingadmissionwebhook](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook). +[OpenAPI v3 schema](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#schemaObject) or [validatingadmissionwebhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook). Additionally, the following restrictions are applied to the schema: - The fields `default`, `nullable`, `discriminator`, `readOnly`, `writeOnly`, `xml`, diff --git a/content/en/docs/tasks/administer-cluster/ip-masq-agent.md b/content/en/docs/tasks/administer-cluster/ip-masq-agent.md index cd7c90ac75..5821536e1f 100644 --- a/content/en/docs/tasks/administer-cluster/ip-masq-agent.md +++ b/content/en/docs/tasks/administer-cluster/ip-masq-agent.md @@ -51,7 +51,7 @@ MASQUERADE all -- anywhere anywhere /* ip-masq-agent: ``` -By default, in GCE/Google Kubernetes Engine starting with Kubernetes version 1.7.0, if network policy is enabled or you are using a cluster CIDR not in the 10.0.0.0/8 range, the ip-masq-agent will run in your cluster. If you are running in another environment, you can add the ip-masq-agent [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) to your cluster: +By default, in GCE/Google Kubernetes Engine starting with Kubernetes version 1.7.0, if network policy is enabled or you are using a cluster CIDR not in the 10.0.0.0/8 range, the ip-masq-agent will run in your cluster. If you are running in another environment, you can add the ip-masq-agent [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) to your cluster: {{% /capture %}} @@ -111,5 +111,3 @@ resyncInterval: 60s masqLinkLocal: true ``` {{% /capture %}} - - diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index 913e672ac0..5afdcffa15 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -60,9 +60,9 @@ You pass these arguments in any of the following ways: * You can also upload a config file using [`kubeadm config upload from-files`][config-upload] [cert-manager-issuer]: https://cert-manager.readthedocs.io/en/latest/tutorials/ca/creating-ca-issuer.html -[kcm]: https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/ +[kcm]: /docs/reference/command-line-tools-reference/kube-controller-manager/ [config]: https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta1 -[config-upload]: https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-config/#cmd-config-from-file +[config-upload]: /docs/reference/setup-tools/kubeadm/kubeadm-config/#cmd-config-from-file ### Approve requests @@ -85,9 +85,9 @@ certificatesigningrequest.certificates.k8s.io/kubeadm-cert-kube-apiserver-ld526 You can view a list of pending certificates with `kubectl get csr`. -[manage-tls]: https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/ +[manage-tls]: /docs/tasks/tls/managing-tls-in-a-cluster/ [cert-manager]: https://github.com/jetstack/cert-manager -[certs]: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#certificate +[certs]: /docs/reference/generated/kubectl/kubectl-commands#certificate ## Certificate requests with kubeadm @@ -122,8 +122,8 @@ Kubeadm sets up [three CAs][cert-cas] by default. Make sure to sign the CSRs wit [openssl-ca]: https://superuser.com/questions/738612/openssl-ca-keyusage-extension [cfssl-usages]: https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170 -[certs]: https://kubernetes.io/docs/setup/certificates -[cert-cas]: https://kubernetes.io/docs/setup/certificates/#single-root-ca -[cert-table]: https://kubernetes.io/docs/setup/certificates/#all-certificates +[certs]: /docs/setup/certificates +[cert-cas]: /docs/setup/certificates/#single-root-ca +[cert-table]: /docs/setup/certificates/#all-certificates {{% /capture %}} diff --git a/content/en/docs/tasks/administer-cluster/out-of-resource.md b/content/en/docs/tasks/administer-cluster/out-of-resource.md index 9051f57d15..6b87909a95 100644 --- a/content/en/docs/tasks/administer-cluster/out-of-resource.md +++ b/content/en/docs/tasks/administer-cluster/out-of-resource.md @@ -205,7 +205,7 @@ If `nodefs` filesystem has met eviction thresholds, `kubelet` frees up disk spac If the `kubelet` is unable to reclaim sufficient resource on the node, `kubelet` begins evicting Pods. The `kubelet` ranks Pods for eviction first by whether or not their usage of the starved resource exceeds requests, -then by [Priority](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/), and then by the consumption of the starved compute resource relative to the Pods' scheduling requests. +then by [Priority](/docs/concepts/configuration/pod-priority-preemption/), and then by the consumption of the starved compute resource relative to the Pods' scheduling requests. As a result, `kubelet` ranks and evicts Pods in the following order: diff --git a/content/en/docs/tasks/debug-application-cluster/_index.md b/content/en/docs/tasks/debug-application-cluster/_index.md index a7f507eff2..edce58d23a 100755 --- a/content/en/docs/tasks/debug-application-cluster/_index.md +++ b/content/en/docs/tasks/debug-application-cluster/_index.md @@ -1,5 +1,5 @@ --- -title: "Monitor, Log, and Debug" +title: "Monitoring, Logging, and Debugging" weight: 80 --- diff --git a/content/en/docs/tasks/debug-application-cluster/core-metrics-pipeline.md b/content/en/docs/tasks/debug-application-cluster/core-metrics-pipeline.md index 18033665e9..19f612a5dc 100644 --- a/content/en/docs/tasks/debug-application-cluster/core-metrics-pipeline.md +++ b/content/en/docs/tasks/debug-application-cluster/core-metrics-pipeline.md @@ -48,7 +48,7 @@ It's supported in Kubernetes 1.7+ (see details below). Metric server collects metrics from the Summary API, exposed by [Kubelet](/docs/admin/kubelet/) on each node. Metrics Server registered in the main API server through -[Kubernetes aggregator](https://kubernetes.io/docs/concepts/api-extension/apiserver-aggregation/), +[Kubernetes aggregator](/docs/concepts/api-extension/apiserver-aggregation/), which was introduced in Kubernetes 1.7. Learn more about the metrics server in [the design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md). diff --git a/content/en/docs/tasks/debug-application-cluster/crictl.md b/content/en/docs/tasks/debug-application-cluster/crictl.md index 4f91efb8a4..f1f8694c2e 100644 --- a/content/en/docs/tasks/debug-application-cluster/crictl.md +++ b/content/en/docs/tasks/debug-application-cluster/crictl.md @@ -51,10 +51,9 @@ You can also specify timeout values when connecting to the server and enable or disable debugging, by specifying `timeout` or `debug` values in the configuration file or using the `--timeout` and `--debug` command-line flags. -To view or edit the current configuration, view or edit the contents of -`/etc/crictl.yaml`. +To view or edit the current configuration, view or edit the contents of `/etc/crictl.yaml`. -```sh +```shell cat /etc/crictl.yaml runtime-endpoint: unix:///var/run/dockershim.sock image-endpoint: unix:///var/run/dockershim.sock @@ -76,10 +75,12 @@ general purpose workflow tool, but a tool that is useful for debugging. List all pods: -```bash +```shell crictl pods ``` -```none +The output is similar to this: + +``` POD ID CREATED STATE NAME NAMESPACE ATTEMPT 926f1b5a1d33a About a minute ago Ready sh-84d7dcf559-4r2gq default 0 4dccb216c4adb About a minute ago Ready nginx-65899c769f-wv2gp default 0 @@ -89,20 +90,24 @@ a86316e96fa89 17 hours ago Ready kube-proxy-gblk4 List pods by name: -```bash +```shell crictl pods --name nginx-65899c769f-wv2gp ``` -```none +The output is similar to this: + +``` POD ID CREATED STATE NAME NAMESPACE ATTEMPT 4dccb216c4adb 2 minutes ago Ready nginx-65899c769f-wv2gp default 0 ``` List pods by label: -```bash +```shell crictl pods --label run=nginx ``` -```none +The output is similar to this: + +``` POD ID CREATED STATE NAME NAMESPACE ATTEMPT 4dccb216c4adb 2 minutes ago Ready nginx-65899c769f-wv2gp default 0 ``` @@ -111,10 +116,12 @@ POD ID CREATED STATE NAME List all images: -```bash +```shell crictl images ``` -```none +The output is similar to this: + +``` IMAGE TAG IMAGE ID SIZE busybox latest 8c811b4aec35f 1.15MB k8s-gcrio.azureedge.net/hyperkube-amd64 v1.10.3 e179bbfe5d238 665MB @@ -124,20 +131,24 @@ nginx latest cd5239a0906a6 List images by repository: -```bash +```shell crictl images nginx ``` -```none +The output is similar to this: + +``` IMAGE TAG IMAGE ID SIZE nginx latest cd5239a0906a6 109MB ``` Only list image IDs: -```bash +```shell crictl images -q ``` -```none +The output is similar to this: + +``` sha256:8c811b4aec35f259572d0f79207bc0678df4c736eeec50bc9fec37ed936a472a sha256:e179bbfe5d238de6069f3b03fccbecc3fb4f2019af741bfff1233c4d7b2970c5 sha256:da86e6ba6ca197bf6bc5e9d900febd906b133eaa4750e6bed647b0fbe50ed43e @@ -148,10 +159,12 @@ sha256:cd5239a0906a6ccf0562354852fae04bc5b52d72a2aff9a871ddb6bd57553569 List all containers: -```bash +```shell crictl ps -a ``` -```none +The output is similar to this: + +``` CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT 1f73f2d81bf98 busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 7 minutes ago Running sh 1 9c5951df22c78 busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 8 minutes ago Exited sh 0 @@ -161,10 +174,12 @@ CONTAINER ID IMAGE List running containers: -```bash +``` crictl ps ``` -```none +The output is similar to this: + +``` CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT 1f73f2d81bf98 busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 6 minutes ago Running sh 1 87d3992f84f74 nginx@sha256:d0a8828cccb73397acb0073bf34f4d7d8aa315263f1e7806bf8c55d8ac139d5f 7 minutes ago Running nginx 0 @@ -173,10 +188,12 @@ CONTAINER ID IMAGE ### Execute a command in a running container -```bash +```shell crictl exec -i -t 1f73f2d81bf98 ls ``` -```none +The output is similar to this: + +``` bin dev etc home proc root sys tmp usr var ``` @@ -184,10 +201,12 @@ bin dev etc home proc root sys tmp usr var Get all container logs: -```bash +```shell crictl logs 87d3992f84f74 ``` -```none +The output is similar to this: + +``` 10.240.0.96 - - [06/Jun/2018:02:45:49 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" 10.240.0.96 - - [06/Jun/2018:02:45:50 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" 10.240.0.96 - - [06/Jun/2018:02:45:51 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" @@ -195,10 +214,12 @@ crictl logs 87d3992f84f74 Get only the latest `N` lines of logs: -```bash +```shell crictl logs --tail=1 87d3992f84f74 ``` -```none +The output is similar to this: + +``` 10.240.0.96 - - [06/Jun/2018:02:45:51 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" ``` @@ -226,7 +247,7 @@ deleted by the Kubelet. 2. Use the `crictl runp` command to apply the JSON and run the sandbox. - ```bash + ```shell crictl runp pod-config.json ``` @@ -240,7 +261,7 @@ deleted by the Kubelet. 1. Pull a busybox image - ```bash + ```shell crictl pull busybox Image is up to date for busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 ``` @@ -284,17 +305,19 @@ deleted by the Kubelet. container config file, and the pod config file. The ID of the container is returned. - ```bash + ```shell crictl create f84dd361f8dc51518ed291fbadd6db537b0496536c1d2d6c05ff943ce8c9a54f container-config.json pod-config.json ``` 4. List all containers and verify that the newly-created container has its state set to `Created`. - ```bash + ```shell crictl ps -a ``` - ```none + The output is similar to this: + + ``` CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT 3e025dd50a72d busybox 32 seconds ago Created busybox 0 ``` @@ -303,19 +326,23 @@ deleted by the Kubelet. To start a container, pass its ID to `crictl start`: -```bash +```shell crictl start 3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60 ``` -```none +The output is similar to this: + +``` 3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60 ``` Check the container has its state set to `Running`. -```bash +```shell crictl ps ``` -```none +The output is similar to this: + +``` CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT 3e025dd50a72d busybox About a minute ago Running busybox 0 ``` diff --git a/content/en/docs/tasks/debug-application-cluster/debug-cluster.md b/content/en/docs/tasks/debug-application-cluster/debug-cluster.md index 620bfa4e2b..2b726a98a7 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-cluster.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-cluster.md @@ -36,20 +36,20 @@ of the relevant log files. (note that on systemd-based systems, you may need to ### Master - * /var/log/kube-apiserver.log - API Server, responsible for serving the API - * /var/log/kube-scheduler.log - Scheduler, responsible for making scheduling decisions - * /var/log/kube-controller-manager.log - Controller that manages replication controllers + * `/var/log/kube-apiserver.log` - API Server, responsible for serving the API + * `/var/log/kube-scheduler.log` - Scheduler, responsible for making scheduling decisions + * `/var/log/kube-controller-manager.log` - Controller that manages replication controllers ### Worker Nodes - * /var/log/kubelet.log - Kubelet, responsible for running containers on the node - * /var/log/kube-proxy.log - Kube Proxy, responsible for service load balancing + * `/var/log/kubelet.log` - Kubelet, responsible for running containers on the node + * `/var/log/kube-proxy.log` - Kube Proxy, responsible for service load balancing ## A general overview of cluster failure modes This is an incomplete list of things that could go wrong, and how to adjust your cluster setup to mitigate the problems. -Root causes: +### Root causes: - VM(s) shutdown - Network partition within cluster, or between cluster and users @@ -57,7 +57,7 @@ Root causes: - Data loss or unavailability of persistent storage (e.g. GCE PD or AWS EBS volume) - Operator error, e.g. misconfigured Kubernetes software or application software -Specific scenarios: +### Specific scenarios: - Apiserver VM shutdown or apiserver crashing - Results @@ -91,7 +91,7 @@ Specific scenarios: - users unable to read API - etc. -Mitigations: +### Mitigations: - Action: Use IaaS provider's automatic VM restarting feature for IaaS VMs - Mitigates: Apiserver VM shutdown or apiserver crashing diff --git a/content/en/docs/tasks/debug-application-cluster/local-debugging.md b/content/en/docs/tasks/debug-application-cluster/local-debugging.md index 92d68aad98..9cfc216ee4 100644 --- a/content/en/docs/tasks/debug-application-cluster/local-debugging.md +++ b/content/en/docs/tasks/debug-application-cluster/local-debugging.md @@ -5,7 +5,7 @@ content_template: templates/task {{% capture overview %}} -Kubernetes applications usually consist of multiple, separate services, each running in its own container. Developing and debugging these services on a remote Kubernetes cluster can be cumbersome, requiring you to [get a shell on a running container](https://kubernetes.io/docs/tasks/debug-application-cluster/get-shell-running-container/) and running your tools inside the remote shell. +Kubernetes applications usually consist of multiple, separate services, each running in its own container. Developing and debugging these services on a remote Kubernetes cluster can be cumbersome, requiring you to [get a shell on a running container](/docs/tasks/debug-application-cluster/get-shell-running-container/) and running your tools inside the remote shell. `telepresence` is a tool to ease the process of developing and debugging services locally, while proxying the service to a remote Kubernetes cluster. Using `telepresence` allows you to use custom tools, such as a debugger and IDE, for a local service and provides the service full access to ConfigMap, secrets, and the services running on the remote cluster. @@ -57,5 +57,3 @@ Telepresence has [numerous proxying options](https://www.telepresence.io/referen For further reading, visit the [Telepresence website](https://www.telepresence.io). {{% /capture %}} - - diff --git a/content/en/docs/tasks/federation/set-up-cluster-federation-kubefed.md b/content/en/docs/tasks/federation/set-up-cluster-federation-kubefed.md index 9a751661e8..9452dcd236 100644 --- a/content/en/docs/tasks/federation/set-up-cluster-federation-kubefed.md +++ b/content/en/docs/tasks/federation/set-up-cluster-federation-kubefed.md @@ -94,7 +94,7 @@ sudo chmod +x /usr/local/bin/kubefed ### Install kubectl You can install a matching version of kubectl using the instructions on -the [kubectl install page](https://kubernetes.io/docs/tasks/tools/install-kubectl/). +the [kubectl install page](/docs/tasks/tools/install-kubectl/). ## Choosing a host cluster. diff --git a/content/en/docs/tasks/run-application/delete-stateful-set.md b/content/en/docs/tasks/run-application/delete-stateful-set.md index 7c2db63971..8db021c6c6 100644 --- a/content/en/docs/tasks/run-application/delete-stateful-set.md +++ b/content/en/docs/tasks/run-application/delete-stateful-set.md @@ -79,7 +79,7 @@ In the example above, the Pods have the label `app=myapp`; substitute your own l ### Force deletion of StatefulSet pods -If you find that some pods in your StatefulSet are stuck in the 'Terminating' or 'Unknown' states for an extended period of time, you may need to manually intervene to forcefully delete the pods from the apiserver. This is a potentially dangerous task. Refer to [Deleting StatefulSet Pods](/docs/tasks/manage-stateful-set/delete-pods/) for details. +If you find that some pods in your StatefulSet are stuck in the 'Terminating' or 'Unknown' states for an extended period of time, you may need to manually intervene to forcefully delete the pods from the apiserver. This is a potentially dangerous task. Refer to [Force Delete StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/) for details. {{% /capture %}} diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md index 38d615293d..37528b3052 100644 --- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -71,7 +71,7 @@ or the custom metrics API (for all other metrics). The HorizontalPodAutoscaler normally fetches metrics from a series of aggregated APIs (`metrics.k8s.io`, `custom.metrics.k8s.io`, and `external.metrics.k8s.io`). The `metrics.k8s.io` API is usually provided by metrics-server, which needs to be launched separately. See -[metrics-server](https://kubernetes.io/docs/tasks/debug-application-cluster/core-metrics-pipeline/#metrics-server) +[metrics-server](/docs/tasks/debug-application-cluster/core-metrics-pipeline/#metrics-server) for instructions. The HorizontalPodAutoscaler can also fetch metrics directly from Heapster. {{< note >}} diff --git a/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md b/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md index a265c91974..90572b0b88 100644 --- a/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md +++ b/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md @@ -19,7 +19,7 @@ Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes clust * You must have a Kubernetes cluster with cluster DNS enabled. * If you are using a cloud-based Kubernetes cluster or {{< glossary_tooltip text="Minikube" term_id="minikube" >}}, you may already have cluster DNS enabled. * If you are using `hack/local-up-cluster.sh`, ensure that the `KUBE_ENABLE_CLUSTER_DNS` environment variable is set, then run the install script. -* [Install and setup kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) v1.7 or higher. Make sure it is configured to connect to the Kubernetes cluster. +* [Install and setup kubectl](/docs/tasks/tools/install-kubectl/) v1.7 or higher. Make sure it is configured to connect to the Kubernetes cluster. * Install [Helm](http://helm.sh/) v2.7.0 or newer. * Follow the [Helm install instructions](https://github.com/kubernetes/helm/blob/master/docs/install.md). * If you already have an appropriate version of Helm installed, execute `helm init` to install Tiller, the server-side component of Helm. @@ -105,6 +105,3 @@ helm install svc-cat/catalog \ * Explore the [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) project. {{% /capture %}} - - - diff --git a/content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md b/content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md index 68a565779d..63ddb5c376 100644 --- a/content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md +++ b/content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md @@ -18,7 +18,7 @@ Use the [Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-s * Install [Go 1.6+](https://golang.org/dl/) and set the `GOPATH`. * Install the [cfssl](https://github.com/cloudflare/cfssl) tool needed for generating SSL artifacts. * Service Catalog requires Kubernetes version 1.7+. -* [Install and setup kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) so that it is configured to connect to a Kubernetes v1.7+ cluster. +* [Install and setup kubectl](/docs/tasks/tools/install-kubectl/) so that it is configured to connect to a Kubernetes v1.7+ cluster. * The kubectl user must be bound to the *cluster-admin* role for it to install Service Catalog. To ensure that this is true, run the following command: kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user= @@ -73,6 +73,3 @@ sc uninstall * Explore the [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) project. {{% /capture %}} - - - diff --git a/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md b/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md index 2180f05d36..ccb7dd854c 100644 --- a/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md +++ b/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md @@ -36,7 +36,7 @@ Trusting the cluster root CA from an application running as a pod usually requires some extra application configuration. You will need to add the CA certificate bundle to the list of CA certificates that the TLS client or server trusts. For example, you would do this with a golang TLS config by parsing the -certificate chain and adding the parsed certificates to the `Certificates` field +certificate chain and adding the parsed certificates to the `RootCAs` field in the [`tls.Config`](https://godoc.org/crypto/tls#Config) struct. The CA certificate bundle is automatically mounted into pods using the default diff --git a/content/en/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/en/docs/tutorials/kubernetes-basics/scale/scale-intro.html index 18773dc6bc..2c90e68e69 100644 --- a/content/en/docs/tutorials/kubernetes-basics/scale/scale-intro.html +++ b/content/en/docs/tutorials/kubernetes-basics/scale/scale-intro.html @@ -27,7 +27,7 @@ weight: 10

Scaling an application

-

In the previous modules we created a Deployment, and then exposed it publicly via a Service. The Deployment created only one Pod for running our application. When traffic increases, we will need to scale the application to keep up with user demand.

+

In the previous modules we created a Deployment, and then exposed it publicly via a Service. The Deployment created only one Pod for running our application. When traffic increases, we will need to scale the application to keep up with user demand.

Scaling is accomplished by changing the number of replicas in a Deployment

@@ -86,7 +86,7 @@ weight: 10
-

Scaling out a Deployment will ensure new Pods are created and scheduled to Nodes with available resources. Scaling will increase the number of Pods to the new desired state. Kubernetes also supports autoscaling of Pods, but it is outside of the scope of this tutorial. Scaling to zero is also possible, and it will terminate all Pods of the specified Deployment.

+

Scaling out a Deployment will ensure new Pods are created and scheduled to Nodes with available resources. Scaling will increase the number of Pods to the new desired state. Kubernetes also supports autoscaling of Pods, but it is outside of the scope of this tutorial. Scaling to zero is also possible, and it will terminate all Pods of the specified Deployment.

Running multiple instances of an application will require a way to distribute the traffic to all of them. Services have an integrated load-balancer that will distribute network traffic to all Pods of an exposed Deployment. Services will monitor continuously the running Pods using endpoints, to ensure the traffic is sent only to available Pods.

diff --git a/content/en/docs/tutorials/stateful-application/basic-stateful-set.md b/content/en/docs/tutorials/stateful-application/basic-stateful-set.md index e8a44b5a74..c7ed8641bc 100644 --- a/content/en/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/en/docs/tutorials/stateful-application/basic-stateful-set.md @@ -218,7 +218,7 @@ for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done web-0 web-1 -kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh +kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm /bin/sh nslookup web-0.nginx Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local diff --git a/content/en/docs/tutorials/stateless-application/guestbook.md b/content/en/docs/tutorials/stateless-application/guestbook.md index b8d7045e32..7f0f1209e4 100644 --- a/content/en/docs/tutorials/stateless-application/guestbook.md +++ b/content/en/docs/tutorials/stateless-application/guestbook.md @@ -225,7 +225,7 @@ Some cloud providers, like Google Compute Engine or Google Kubernetes Engine, su ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - frontend ClusterIP 10.0.0.112 80:31323/TCP 6s + frontend NodePort 10.0.0.112 80:31323/TCP 6s kubernetes ClusterIP 10.0.0.1 443/TCP 4m redis-master ClusterIP 10.0.0.151 6379/TCP 2m redis-slave ClusterIP 10.0.0.223 6379/TCP 1m diff --git a/content/en/docs/user-journeys/users/application-developer/foundational.md b/content/en/docs/user-journeys/users/application-developer/foundational.md index 9bcd490626..1a9ccbe009 100644 --- a/content/en/docs/user-journeys/users/application-developer/foundational.md +++ b/content/en/docs/user-journeys/users/application-developer/foundational.md @@ -226,7 +226,7 @@ All of these controllers implement a *control loop*. For simplicity, you can thi or scaling the number of replicas of a given application. Return to 1. {{< /note >}} -By continuously looping, these controllers ensure the cluster can pick up new updates and avoid drifting from the desired state. These ideas are covered in more detail {{< link text="here" url="https://kubernetes.io/docs/concepts/" >}}. +By continuously looping, these controllers ensure the cluster can pick up new updates and avoid drifting from the desired state. These ideas are covered in more detail {{< link text="here" url="/docs/concepts/" >}}. ## Additional resources diff --git a/content/en/includes/partner-script.js b/content/en/includes/partner-script.js index 25c13ef3c5..499dc3f2e3 100644 --- a/content/en/includes/partner-script.js +++ b/content/en/includes/partner-script.js @@ -1061,7 +1061,7 @@ type: 3, name: 'Weaveworks', logo: 'weave_works', - link: 'https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/', + link: '/docs/setup/independent/create-cluster-kubeadm/', blurb: 'Weaveworks - kubeadm' }, { diff --git a/content/fr/docs/concepts/containers/images.md b/content/fr/docs/concepts/containers/images.md new file mode 100644 index 0000000000..10a5e61d8c --- /dev/null +++ b/content/fr/docs/concepts/containers/images.md @@ -0,0 +1,335 @@ +--- +title: Images +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} + +Vous créez une image Docker et la poussez dans un registre avant de la référencer depuis un pod Kubernetes. + +La propriété `image` d'un conteneur utilise la même syntaxe que la commande `docker`, y compris pour les registres privés et les tags. + +{{% /capture %}} + + +{{% capture body %}} + +## Mettre à jour des images + +La politique de récupération par défaut est `IfNotPresent`, Kubelet ne récupère alors pas une image si elle est déjà présente sur le nœud. +Si vous voulez forcer une récupération à chaque fois, vous pouvez faire une des actions suivantes : + +- définissez `imagePullPolicy` du conteneur à `Always`. +- omettez `imagePullPolicy` et utilisez `:latest` comme tag pour l'image à utiliser. +- omettez `imagePullPolicy` et le tag de l'image à utiliser. +- activez l'admission controller [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages). + +Notez que vous devez éviter d'utiliser le tag `:latest`, voir [Bonnes pratiques pour la configuration](/docs/concepts/configuration/overview/#container-images) pour plus d'informations. + +## Créer des images multi-architecture à partir de manifestes + +La CLI Docker prend maintenant en charge la commande `docker manifest` avec des sous-commandes comme `create`, `annotate` et `push`. Ces commandes peuvent être utilisées pour construire et pousser les manifestes. Vous pouvez utiliser `docker manifest inspect` pour voir le manifeste. + +Vous pouvez voir la documentation Docker ici : +https://docs.docker.com/edge/engine/reference/commandline/manifest/ + +Voici comment nous l'utilisons dans notre outil de build: +https://cs.k8s.io/?q=docker%20manifest%20(create%7Cpush%7Cannotate)&i=nope&files=&repos= + +Ces commandes se basent et sont implémentées purement sur la CLI Docker. Vous devrez soit éditer `$HOME/.docker/config.json` et définir la clé `experimental` à `enabled` ou vous pouvez simplement définir la variable d'environnement `DOCKER_CLI_EXPERIMENTAL` à `enabled` lorsque vous appelez les commandes de la CLI. + +{{< note >}} +Veuillez utiliser les versions *18.06 ou ultérieure*, les versions antérieures ayant des bugs ou ne prenant pas en charge l'option `experimental` pour la ligne de commande. Par exemple https://github.com/docker/cli/issues/1135 cause des problèmes sous `containerd`. +{{< /note >}} + +Si vous avez des problèmes en téléchargeant des manifestes viciés, nettoyez les anciens manifestes dans `$HOME/.docker/manifests` pour recommencer de zéro. + +Pour Kubernetes, nous avons historiquement utilisé des images avec des suffixes `-$(ARCH)`. Pour une rétrocompatibilité, veuillez générer les anciennes images avec des suffixes. Par exemple, l'image `pause` qui a le manifeste pour toutes les architetures et l'image `pause-amd64` qui est rétrocompatible +pour d'anciennes configurations ou des fichiers YAML qui auraient codé en dur les images avec des suffixes. + +## Utiliser un registre privé + +Les registres privés peuvent demander des clés pour pouvoir lire leurs images. + +Ces certificats peuvent être fournis de différentes manières : + + - En utilisant la Google Container Registry + - par cluster + - automatiqueent configuré dans Google Compute Engine ou Google Kubernetes Engine + - tous les pods peuvent lire le registre privé du projet + - En utilisant AWS EC2 Container Registry (ECR) + - utilise des rôles et politiques IAM pour contrôler l'accès aux dépôts ECR + - rafraîchit automatiquement les certificats de login ECR + - En utilisant Azure Container Registry (ACR) + - En utilisant IBM Cloud Container Registry + - En configurant les nœuds pour s'authentifier auprès d'un registre privé + - tous les pods peuvent lire les registres privés configurés + - nécessite la configuration des nœuds par un administrateur du cluster + - En pré-chargeant les images + - tous les pods peuvent utiliser toutes les images mises en cache sur un nœud + - nécessite l'accès root à tous les nœuds pour la mise en place + - En spécifiant ImagePullSecrets dans un Pod + - seuls les pods fournissant ses propres clés peuvent accéder au registre privé + +Chaque option est décrite plus en détails ci-dessous. + +### Utiliser la Google Container Registry + +Kubernetes prend en charge nativement la [Google Container +Registry (GCR)](https://cloud.google.com/tools/container-registry/), lorsqu'il s'exécute dans Google Compute +Engine (GCE). Si vous exécutez votre cluster dans GCE ou Google Kubernetes Engine, utilisez simplement le nom complet de l'image (par ex. gcr.io/my_project/image:tag). + +Tous les pods dans un cluster auront un accès en lecture aux images dans le registre. + +Kubelet va s'authentifier auprès de GCR en utilisant le compte de service Google de l'instance. +Le compte de service dans l'instance aura un `https://www.googleapis.com/auth/devstorage.read_only`, +afin qu'il puisse récupérer depuis le GCR du projet mais qu'il ne puisse pas pousser une image. + +### Utiliser AWS EC2 Container Registry + +Kubernetes prend en charge nativement [AWS EC2 Container +Registry](https://aws.amazon.com/ecr/), lorsque les nœuds sont des instances de AWS EC2. + +Utilisez simplement le nom complet de l'image (par ex. `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`) +dans la définition du Pod. + +Tous les utilisateurs du cluster qui peuvent créer des pods auront la possibilité +d'exécuter des pods qui utilisent n'importe quelle image du registre ECR. + +Kubelet va aller chercher et rafraîchir périodiquement les certificats ECR. Les permissions suivantes sont requises par kubelet : + +- `ecr:GetAuthorizationToken` +- `ecr:BatchCheckLayerAvailability` +- `ecr:GetDownloadUrlForLayer` +- `ecr:GetRepositoryPolicy` +- `ecr:DescribeRepositories` +- `ecr:ListImages` +- `ecr:BatchGetImage` + +Exigences : + +- Vous devez utiliser kubelet version `v1.2.0` ou ultérieure. (exécutez par ex. `/usr/bin/kubelet --version=true`). +- Si vos nœuds sont dans une région différente de votre registre, vous devez utiliser la version `v1.3.0` ou ultérieure. +- ECR doit être disponible dans votre région. + +Dépannage : + +- Vérifiez toutes les exigences ci-dessus. +- Copiez les certificats de $REGION (par ex. `us-west-2`) sur votre poste de travail. Connectez-vous en SSH sur l'hôte et exécutez Docker manuellement avec ces certificats. Est-ce que ça marche ? +- Vérifiez que kubelet s'exécute avec `--cloud-provider=aws`. +- Recherchez dans les logs de kubelet (par ex. `journalctl -u kubelet`) des lignes de logs ressemblant à : + - `plugins.go:56] Registering credential provider: aws-ecr-key` + - `provider.go:91] Refreshing cache for provider: *aws_credentials.ecrProvider` + +### Utiliser Azure Container Registry (ACR) +En utilisant [Azure Container Registry](https://azure.microsoft.com/en-us/services/container-registry/) +vous pouvez vous authentifier en utilisant soit un utilisateur admin soit un service principal. +Dans les deux cas, l'authentification est faite via l'authentification standard de Docker. Ces instructions assument l'outil en ligne de commande [azure-cli](https://github.com/azure/azure-cli). + +Vous devez d'abord créer un registre et générer des certificats, la documentation complète pour cela peut être touvée dans la [documentation de Azure container registry](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-get-started-azure-cli). + +Une fois votre registre de conteneurs créé, vous utiliserez les certificats suivants pour vous connecter : + + * `DOCKER_USER` : service principal ou utilisateur admin + * `DOCKER_PASSWORD`: mot de passe du service principal ou utilisateur admin + * `DOCKER_REGISTRY_SERVER`: `${un-nom-de-registre}.azurecr.io` + * `DOCKER_EMAIL`: `${une-adresse-email}` + +Une fois que vous avez défini ces variables, vous pouvez +[configurer un Secret Kubernetes et l'utiliser pour déployer un Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). + +### Utiliser IBM Cloud Container Registry + +IBM Cloud Container Registry fournit un registre d'images multi-tenant privé que vous pouvez utiliser pour stocker et partager de manière sécurisée vos images Docker. Par défaut, les images de votre registre privé sont scannées par le Vulnerability Advisor intégré pour détecter des failles de sécurité et des vulnérabilités potentielles. Les utilisateurs de votre compte IBM Cloud peuvent accéder à vos images, ou vous pouvez créer un token pour garantir l'accès à des namespaces du registre. + +Pour installer le plugin du CLI de IBM Cloud Container Registry et créer un namespace pour vos images, voir [Débuter avec IBM Cloud Container Registry](https://cloud.ibm.com/docs/services/Registry?topic=registry-index#index). + +Vous pouvez utiliser le IBM Cloud Container Registry pour déployer des conteneurs depuis des [images publiques de IBM Cloud](https://cloud.ibm.com/docs/services/Registry?topic=registry-public_images#public_images) et vos images privées dans le namespace `default` de votre cluster IBM Cloud Kubernetes Service. Pour déployer un conteneur dans d'autres namespaces, ou pour utiliser une image d'une autre région de IBM Cloud Container Registry ou d'un autre compte IBM Cloud, créez un `imagePullSecret` Kubernetes. Pour plus d'informations, voir [Construire des conteneurs à partir d'images](https://cloud.ibm.com/docs/containers?topic=containers-images#images). + +### Configurer les nœuds pour s'authentifier auprès d'un registre privé + +{{< note >}} +Si vous travaillez dans Google Kubernetes Engine, vous trouverez un `.dockercfg` sur chaque nœud avec les certificats pour Google Container Registry. Vous ne pourrez pas utiliser cette méthode. +{{< /note >}} + +{{< note >}} +Si vous travaillez dans AWS EC2 et utilisez EC2 Container Registry (ECR), kubelet sur chaque nœud va gérer et mettre à jour les certificats du login ECR. Vous ne pourrez pas utiliser cette méthode. +{{< /note >}} + +{{< note >}} +Cette méthode est utilisable si vous avez le contrôle sur la configuration des nœuds. Elle ne marchera pas +correctement sur GCE, et sur tout autre fournisseur cloud qui fait du remplacement de nœud automatique. +{{< /note >}} + +{{< note >}} +Kubernetes prend pour l'instant en charge uniquement les sections `auths` et `HttpHeaders` de la config docker. Cela veut dire que les aides aux certificats (`credHelpers` ou `credsStore`) ne sont pas pris en charge. +{{< /note >}} + + +Docker stocke les clés pour les regisres privés dans le fichier `$HOME/.dockercfg` ou `$HOME/.docker/config.json`. Si vous placez le même fichier dans un des chemins de recherche ci-dessous, kubelet l'utilise comme fournisseur de clés lorsque les images sont récupérées. + +* `{--root-dir:-/var/lib/kubelet}/config.json` +* `{cwd of kubelet}/config.json` +* `${HOME}/.docker/config.json` +* `/.docker/config.json` +* `{--root-dir:-/var/lib/kubelet}/.dockercfg` +* `{cwd of kubelet}/.dockercfg` +* `${HOME}/.dockercfg` +* `/.dockercfg` + +{{< note >}} +Vous pouvez avoir à définir `HOME=/root` explicitement dans votre fichier d'environnement pour kubelet. +{{< /note >}} + +Voici les étapes recommandées pour configurer vos nœuds pour qu'ils utilisent un registre privé. Dans cet exemple, exécutez-les sur votre poste de travail : + + 1. Exécutez `docker login [server]` pour chaque jeu de certificats que vous désirez utiliser. Ceci met à jour `$HOME/.docker/config.json`. + 1. Examinez `$HOME/.docker/config.json` dans un éditeur pour vous assurer qu'il contient uniquement les certificats que vous désirez utiliser. + 1. Récupérez la liste de vos nœuds, par exemple : + - si vous voulez connaître les noms : `nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')` + - si vous voulez connaître les IPs : `nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')` + 1. Copiez votre fichier `.docker/config.json` local dans un des chemins de recherche ci-dessus. + - par exemple : `for n in $nodes; do scp ~/.docker/config.json root@$n:/var/lib/kubelet/config.json; done` + +Vérifiez en créant un pod utilisant une image privée, par ex. : + +```yaml +kubectl create -f - <}} +Si vous travaillez dans Google Kubernetes Engine, vous trouverez un `.dockercfg` sur chaque nœud avec les certificats pour Google Container Registry. Vous ne pourrez pas utiliser cette méthode. +{{< /note >}} + +{{< note >}} +Cette méthode est utilisable si vous avez le contrôle sur la configuration des nœuds. Elle ne marchera pas +correctement sur GCE, et sur tout autre fournisseur cloud qui fait du remplacement de nœud automatique. +{{< /note >}} + +Par défaut, kubelet essaiera de récupérer chaque image depuis le registre spécifié. +Cependant, si la propriété `imagePullPolicy` du conteneur est `IfNotPresent` ou `Never`, +alors une image locale est utilisée (respectivement de préférence ou exclusivement). + +Si vous désirez vous reposer sur des images pré-chargées pour éviter l'authentification à un registre, +vous devez vous assurer que tous les nœuds du cluster ont les mêmes images pré-chargées. + +Ceci peut être utilisé pour pré-charger certaines images pour gagner du temps, ou comme une alternative à l'authentification à un registre privé. + +Tous les pods auront un accès en lecture aux images pré-chargées. + +### Spécifier ImagePullSecrets dans un Pod + +{{< note >}} +Cette méthode est actuellement la méthode recommandée pour Google Kubernetes Engine, GCE, et tout autre fournisseur de cloud où la création de nœuds est automatisée. +{{< /note >}} + +Kubernetes permet de spécifier des clés de registre dans un pod. + +#### Créer un Secret avec une config Docker + +Exécutez la commande suivante, en substituant les valeurs en majuscule : + +```shell +kubectl create secret docker-registry myregistrykey --docker-server=SERVEUR_REGISTRE_DOCKER --docker-username=UTILISATEUR_DOCKER --docker-password=MOT_DE_PASSE_DOCKER --docker-email=EMAIL_DOCKER +secret/myregistrykey created. +``` + +Si vous avez déjà un fichier de clés Docker, alors, plutôt que d'utiliser la commande ci-dessus, +vous pouvez importer le fichier de clés comme un Secret Kubernetes. +[Créer un Secret basé sur des clés Docker existantes](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) explique comment s'y prendre. +Ceci est particulièrement utile si vous utilisez plusieurs registres privés, `kubectl create secret docker-registry` créant un Secret ne fonctionnant qu'avec un seul registre privé. + +{{< note >}} +Les pods peuvent référencer des pull secrets dans leur propre namespace uniquement, +ces étapes doivent donc être faites pour chaque namespace. +{{< /note >}} + +#### Se référer à un imagePullSecrets dans un Pod + +Vous pouvez maintenant créer des pods qui référencent ce secret en ajoutant une section `imagePullSecrets` +dans la définition du pod. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: foo + namespace: awesomeapps +spec: + containers: + - name: foo + image: janedoe/awesomeapp:v1 + imagePullSecrets: + - name: myregistrykey +``` + +Ceci doit être fait pour chaque pod utilisant un registre privé. + +Cependant, la définition de ce champ peut être automatisé en définissant `imagePullSecrets` +dans une ressource [serviceAccount](/docs/user-guide/service-accounts). +Voyez [Ajouter un ImagePullSecrets à un Service Account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) pour des instructions détaillées. + +Vous pouvez utiliser cette méthode en conjonction avec un `.docker/config.json` par nœud. Les certificats seront alors regroupés. Cette approche fonctionnera dans Google Kubernetes Engine. + +### Cas d'utilisation + +Il y a plusieurs solutions pour configurer des registres privés. Voici quelques cas d'utilisation classiques et des propositions de solutions. + +1. Cluster exécutant uniquement des images non propriétaires (par ex. open-source). Inutile de protéger les images. + - Utilisez des images publiques dans le Hub Docker. + - Pas de configuration requise. + - Dans GCE/Google Kubernetes Engine, un miroir local est automatiquement utilisé pour améliorer la vitesse et la disponibilité. +1. Cluster exécutant quelques images propriétaires qui doivent être protégées de l'extérieur de l'entreprise, mais visibles pour tous les utilisteurs du cluster. + - Utilisez un [registre Docker](https://docs.docker.com/registry/) hébergé privé. + - Il peut être hébergé sur le [Hub Docker](https://hub.docker.com/signup), ou ailleurs. + - Configurez manuellement .docker/config.json sur caque nœud comme décrit ci-dessus. + - Ou, utilisez un registre privé interne derrière votre pare-feu avec un accès ouvert en lecture. + - Aucune configuration Kubernetes n'est nécessaire. + - Ou, dans GCE/Google Kubernetes Engine, utilisez le Google Container Registry du projet. + - Cela fonctionnera mieux pour l'autoscaling du cluster que la configuration manuelle des nœuds. + - Ou, dans un cluster où le changement de la configuration des nœuds est difficile, utilisez `imagePullSecrets`. +1. Cluster avec des images propriétaires, dont quelques-unes nécessitent un contrôle d'accès plus strict. + - Assurez-vous que [l'admission controller AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) est actif. Autrement, tous les Pods ont potentiellement accès à toutes les images. + - Déplacez les données sensibles dans une ressource "Secret", plutôt que de les intégrer dans une image. +1. Un cluster multi-tenant où chaque *tenant* doit avoir son propre registre privé. + - Assurez-vous que [l'admission controller AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) est actif. Autrement, tous les Pods ont potentiellement accès à toutes les images. + - Utilisez un registre privé nécessitant l'autorisation. + - Générez des certificats de registre pour chaque *tenant*, placez-les dans des secrets, et placez ces secrets dans les namespaces de chaque *tenant*. +pod - Le *tenant* ajoute ce secret dans les imagePullSecrets de chaque pod. + +{{% /capture %}} + +Si vous devez accéder à plusieurs registres, vous pouvez créer un secret pour chaque registre. +Kubelet va fusionner tous les `imagePullSecrets` dans un unique `.docker/config.json` virtuel. diff --git a/content/it/partners/_index.html b/content/it/partners/_index.html new file mode 100644 index 0000000000..7ab14e34bb --- /dev/null +++ b/content/it/partners/_index.html @@ -0,0 +1,91 @@ +--- +title: Partners +bigheader: Kubernetes Partners +abstract: Growing the Kubernetes ecosystem. +class: gridPage +cid: partners +--- + +
+
+
Kubernetes collabora con i partner per creare una base di codice forte e vivace che supporti uno spettro di piattaforme complementari.
+
+
+
+
+ Fornitori di servizi certificati Kubernetes +
+
Fornitori di servizi con una grande esperienza nell'aiutare le imprese ad adottare con successo Kubernetes. +


+ +

Interessato a diventare un KCSP? +
+
+
+
+
+ Distribuzioni certificate di Kubernetes, piattaforme hosted e installer +
La conformità del software garantisce che la versione di Kubernetes di ogni fornitore supporti le API richieste. +


+ +

Interessato a diventare un Certificato Kubernetes? +
+
+
+
+
Partner di formazione di Kubernetes
+
Fornitori di formazione con esperienza che hanno una profonda esperienza nella formazione della tecnologia cloud nativa. +



+ +

Interessato a diventare un KTP? +
+
+
+ + + +
+ + +
+ +
+
+ + + + diff --git a/content/ja/docs/setup/independent/create-cluster-kubeadm.md b/content/ja/docs/setup/independent/create-cluster-kubeadm.md index f74e55bd3b..288900b67a 100644 --- a/content/ja/docs/setup/independent/create-cluster-kubeadm.md +++ b/content/ja/docs/setup/independent/create-cluster-kubeadm.md @@ -86,7 +86,7 @@ timeframe; which also applies to `kubeadm`. ## 目的 -* Install a single master Kubernetes cluster or [high availability cluster](https://kubernetes.io/docs/setup/independent/high-availability/) +* Install a single master Kubernetes cluster or [high availability cluster](/docs/setup/independent/high-availability/) * Install a Pod network on the cluster so that your Pods can talk to each other @@ -191,7 +191,7 @@ To start using your cluster, you need to run (as a regular user): You should now deploy a pod network to the cluster. Run "kubectl apply -f [podnetwork].yaml" with one of the addon options listed at: - http://kubernetes.io/docs/admin/addons/ + /docs/admin/addons/ You can now join any number of machines by running the following on each node as root: @@ -316,7 +316,7 @@ For `flannel` to work correctly, you must pass `--pod-network-cidr=10.244.0.0/16 Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1` to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information -please see [here](https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements). +please see [here](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements). Note that `flannel` works on `amd64`, `arm`, `arm64` and `ppc64le`. @@ -331,7 +331,7 @@ For more information about `flannel`, see [the CoreOS flannel repository on GitH {{% tab name="Kube-router" %}} Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1` to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information -please see [here](https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements). +please see [here](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements). Kube-router relies on kube-controller-manager to allocate pod CIDR for the nodes. Therefore, use `kubeadm init` with the `--pod-network-cidr` flag. @@ -343,7 +343,7 @@ For information on setting up Kubernetes cluster with Kube-router using kubeadm, {{% tab name="Romana" %}} Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1` to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information -please see [here](https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements). +please see [here](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements). The official Romana set-up guide is [here](https://github.com/romana/romana/tree/master/containerize#using-kubeadm). @@ -357,7 +357,7 @@ kubectl apply -f https://raw.githubusercontent.com/romana/romana/master/containe {{% tab name="Weave Net" %}} Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1` to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information -please see [here](https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements). +please see [here](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements). The official Weave Net set-up guide is [here](https://www.weave.works/docs/net/latest/kube-addon/). @@ -620,7 +620,3 @@ addressed in due course. ## トラブルシューティング {#troubleshooting} If you are running into difficulties with kubeadm, please consult our [troubleshooting docs](/docs/setup/independent/troubleshooting-kubeadm/). - - - - diff --git a/content/ja/docs/setup/independent/troubleshooting-kubeadm.md b/content/ja/docs/setup/independent/troubleshooting-kubeadm.md index 98462cb4ba..8ece7268d8 100644 --- a/content/ja/docs/setup/independent/troubleshooting-kubeadm.md +++ b/content/ja/docs/setup/independent/troubleshooting-kubeadm.md @@ -131,7 +131,7 @@ services](/docs/concepts/services-networking/service/#nodeport) or use `HostNetw ## サービスIP経由でPodにアクセスすることができない -- Many network add-ons do not yet enable [hairpin mode](https://kubernetes.io/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip) +- Many network add-ons do not yet enable [hairpin mode](/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip) which allows pods to access themselves via their Service IP. This is an issue related to [CNI](https://github.com/containernetworking/cni/issues/476). Please contact the network add-on provider to get the latest status of their support for hairpin mode. diff --git a/content/ja/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/ja/docs/tutorials/kubernetes-basics/scale/scale-intro.html index 91bda9377d..8df0ac278d 100644 --- a/content/ja/docs/tutorials/kubernetes-basics/scale/scale-intro.html +++ b/content/ja/docs/tutorials/kubernetes-basics/scale/scale-intro.html @@ -27,7 +27,7 @@ weight: 10

アプリケーションのスケーリング

-

前回のモジュールでは、Deploymentを作成し、それをService経由で公開しました。該当のDeploymentでは、アプリケーションを実行するためのPodを1つだけ作成しました。トラフィックが増加した場合、ユーザーの需要に対応するためにアプリケーションをスケールする必要があります。

+

前回のモジュールでは、Deploymentを作成し、それをService経由で公開しました。該当のDeploymentでは、アプリケーションを実行するためのPodを1つだけ作成しました。トラフィックが増加した場合、ユーザーの需要に対応するためにアプリケーションをスケールする必要があります。

スケーリングは、Deploymentのレプリカの数を変更することによって実現可能です。

@@ -86,7 +86,7 @@ weight: 10
-

Deploymentをスケールアウトすると、新しいPodが作成され、使用可能なリソースを持つNodeにスケジュールされます。スケールすると、Podの数が増えて新たな望ましい状態になります。KubernetesはPodのオートスケーリングもサポートしていますが、このチュートリアルでは範囲外です。スケーリングを0に設定することも可能で、指定された配置のすべてのPodを終了させます。

+

Deploymentをスケールアウトすると、新しいPodが作成され、使用可能なリソースを持つNodeにスケジュールされます。スケールすると、Podの数が増えて新たな望ましい状態になります。KubernetesはPodのオートスケーリングもサポートしていますが、このチュートリアルでは範囲外です。スケーリングを0に設定することも可能で、指定された配置のすべてのPodを終了させます。

アプリケーションの複数インスタンスを実行するには、それらすべてにトラフィックを分散する方法が必要になります。Serviceには、公開されたDeploymentのすべてのPodにネットワークトラフィックを分散する統合ロードバランサがあります。Serviceは、エンドポイントを使用して実行中のPodを継続的に監視し、トラフィックが使用可能なPodにのみ送信されるようにします。

diff --git a/content/ko/case-studies/blackrock/index.html b/content/ko/case-studies/blackrock/index.html index 96b66334d9..6bef0ec708 100644 --- a/content/ko/case-studies/blackrock/index.html +++ b/content/ko/case-studies/blackrock/index.html @@ -69,7 +69,7 @@ css: /css/style_blackrock.css Made up of managers from technology, infrastructure, production operations, development and information security, Francis’s team was able to look at the problem holistically and come up with a solution that made sense for BlackRock. "Our initial straw man was that we were going to build everything using Ansible and run it all using some completely different distributed environment," says Francis. "That would have been absolutely the wrong thing to do. Had we gone off on our own as the dev team and developed this solution, it would have been a very different product. And it would have been very expensive. We would not have gone down the route of running under our existing orchestration system. Because we don’t understand it. These guys [in operations and infrastructure] understand it. Having the multidisciplinary team allowed us to get to the right solutions and that actually meant we didn’t build anywhere near the amount we thought we were going to end up building."

In search of a solution in which they could manage usage on a user-by-user level, Francis’s team gravitated to Red Hat’s OpenShift Kubernetes offering. The company had already experimented with other cloud-native environments, but the team liked that Kubernetes was open source, and "we felt the winds were blowing in the direction of Kubernetes long term," says Francis. "Typically we make technology choices that we believe are going to be here in 5-10 years’ time, in some form. And right now, in this space, Kubernetes feels like the one that’s going to be there." Adds Uri Morris, Vice President of Production Operations: "When you see that the non-Google committers to Kubernetes overtook the Google committers, that’s an indicator of the momentum."

Once that decision was made, the major challenge was figuring out how to make Kubernetes work within BlackRock’s existing framework. "It’s about understanding how we can operate, manage and support a platform like this, in addition to tacking it onto our existing technology platform," says Project Manager Michael Maskallis. "All the controls we have in place, the change management process, the software development lifecycle, onboarding processes we go through—how can we do all these things?"

- The first (anticipated) speed bump was working around issues behind BlackRock’s corporate firewalls. "One of our challenges is there are no firewalls in most open source software," says Francis. "So almost all install scripts fail in some bizarre way, and pulling down packages doesn’t necessarily work." The team ran into these types of problems using Minikube and did a few small pushes back to the open source project. + The first (anticipated) speed bump was working around issues behind BlackRock’s corporate firewalls. "One of our challenges is there are no firewalls in most open source software," says Francis. "So almost all install scripts fail in some bizarre way, and pulling down packages doesn’t necessarily work." The team ran into these types of problems using Minikube and did a few small pushes back to the open source project.
diff --git a/content/ko/docs/concepts/architecture/master-node-communication.md b/content/ko/docs/concepts/architecture/master-node-communication.md index 7ab5615255..cbeda8aa78 100644 --- a/content/ko/docs/concepts/architecture/master-node-communication.md +++ b/content/ko/docs/concepts/architecture/master-node-communication.md @@ -68,7 +68,7 @@ apiserver는 kubelet의 제공 인증서를 확인하지 않는데, 루트 인증서 번들로 `--kubelet-certificate-authority` 플래그를 이용한다 그것이 불가능한 경우, 신뢰할 수 없는 또는 공인 네트워크에 대한 연결을 피하고 싶다면, -apiserver와 kubelet 사이에 [SSH 터널링](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)을 +apiserver와 kubelet 사이에 [SSH 터널링](/docs/concepts/architecture/master-node-communication/#ssh-tunnels)을 사용한다. 마지막으로, kubelet API를 안전하게 하기 위해 diff --git a/content/ko/docs/concepts/cluster-administration/_index.md b/content/ko/docs/concepts/cluster-administration/_index.md new file mode 100755 index 0000000000..e13a5fdb48 --- /dev/null +++ b/content/ko/docs/concepts/cluster-administration/_index.md @@ -0,0 +1,5 @@ +--- +title: "클러스터 관리" +weight: 100 +--- + diff --git a/content/ko/docs/concepts/cluster-administration/federation.md b/content/ko/docs/concepts/cluster-administration/federation.md new file mode 100644 index 0000000000..61bfe04c3f --- /dev/null +++ b/content/ko/docs/concepts/cluster-administration/federation.md @@ -0,0 +1,184 @@ +--- +title: 페더레이션 +content_template: templates/concept +weight: 80 +--- + +{{% capture overview %}} + +{{< include "federation-current-state.md" >}} + +이 페이지는 여러 쿠버네티스 클러스터를 페더레이션을 통해서 관리해야 하는 이유와 방법을 +설명한다. +{{% /capture %}} + +{{% capture body %}} +## 페더레이션 이유 + +페더레이션을 사용하면 여러 클러스터를 쉽게 관리할 수 있다. 이는 2가지 주요 빌딩 블록을 +제공함으로써 이루어진다. + + * 클러스터 간의 리소스 동기화: 페더레이션은 여러 클러스터 내의 리소스를 + 동기화하는 능력을 제공한다. 예를 들면, 여러 클러스터에 동일한 디플로이먼트가 존재하는 것을 확인 할 수 있다. + * 클러스터 간의 디스커버리: 페더레이션은 모든 클러스터의 백엔드에 DNS 서버 및 로드벨런서를 자동 구성하는 능력을 제공한다. 예를 들면, 글로벌 VIP 또는 DNS 기록이 여러 클러스터의 백엔드 엑세스에 사용될 수 있는 것을 확인할 수 있다. + +페더레이션이 가능하게 하는 다른 사례는 다음과 같다. + +* 고가용성: 클러스터에 걸쳐서 부하를 분산하고 DNS + 서버와 로드벨런서를 자동 구성함으로써, 페더레이션은 클러스터 장애의 영향을 + 최소화한다. +* 공급자 락인(lock-in) 회피: 애플리케이션의 클러스터 간 마이그레이션을 쉽게 + 만듦으로써, 페더레이션은 클러스터 공급자의 락인을 방지한다. + + +여러 클러스터를 운영하는 경우가 아니면 페더레이션은 필요 없다. 여러 클러스터가 필요한 +이유의 일부는 다음과 같다. + +* 짧은 지연시간: 클러스터가 여러 지역(region)에 있으면 사용자에게 가장 가까운 클러스터로부터 + 서비스함으로써 지연시간을 최소화한다. +* 결함 격리: 하나의 큰 클러스터보다 여러 개의 작은 클러스터를 사용하는 것이 + 결함을 격리하는데 더 효과적이다(예를 들면, 클라우드 + 공급자의 다른 가용 영역(availability zone)에 있는 여러 클러스터). +* 확장성: 단일 쿠버네티스 클러스터는 확장성에 한계가 있다(일반적인 + 사용자에게 해당되는 사항은 아니다. 더 자세한 내용: + [쿠버네티스 스케일링 및 성능 목표](https://git.k8s.io/community/sig-scalability/goals.md)). +* [하이브리드 클라우드](#하이브리드-클라우드-역량): 다른 클라우드 공급자나 온-프레미스 데이터 센터에 있는 여러 클러스터를 + 운영할 수 있다. + +### 주의 사항 + +페더레이션에는 매력적인 사례가 많지만, 다소 주의 해야 할 +사항도 있다. + +* 네트워크 대역폭과 비용 증가: 페더레이션 컨트롤 플레인은 모든 클러스터를 + 감시하여 현재 상태가 예정된 상태와 같은지 확인한다. 이것은 클러스터들이 + 한 클라우드 제공자의 여러 다른 지역에서 또는 클라우드 제공자 간에 걸쳐 동작하는 + 경우 상당한 네트워크 비용을 초래할 수 있다. +* 클러스터 간 격리 수준 감소: 페더레이션 컨트롤 플레인에서의 오류는 모든 클러스터에 + 영향을 줄 수 있다. 이것은 페더레이션 컨트롤 플레인의 논리를 최소한으로 + 유지함으로써 완화된다. 페더레이션은 가능한 경우 언제라도 + 쿠버네티스 클러스터에 컨트롤 플레인을 위임한다. 페더레이션은 안전성을 제공하고 + 여러 클러스터의 중단을 방지할 수 있도록 민감하게 설계 및 구현되었다. +* 성숙도: 페더레이션 프로젝트는 상대적으로 신규 프로젝트이고 성숙도가 높지 않다. + 모든 리소스가 이용 가능한 상태는 아니며 많은 리소스가 아직 알파 상태이다. [이슈 + 88](https://github.com/kubernetes/federation/issues/88)은 팀이 해결 + 중에 있는 시스템의 알려진 이슈를 열거하고 있다. + +### 하이브리드 클라우드 역량 + +쿠버네티스 클러스터의 페더레이션은 다른 클라우드 제공자(예를 들어, Google 클라우드, AWS), +그리고 온-프레미스(예를 들어, OpenStack)에서 동작 중인 클러스터를 포함할 수 +있다. [Kubefed](/docs/tasks/federation/set-up-cluster-federation-kubefed/)는 연합된 클러스터 배치에 권장되는 방법이다. + +그 후에, [API 리소스](#api-리소스)는 서로 다른 클러스터와 클라우드 +제공자에 걸쳐 확장될 수 있다. + +## 페더레이션 설치 + +여러 클러스터의 페더레이션 구성을 위해서는, 페더레이션 컨트롤 플레인을 우선적으로 +설치해야 한다. +페더레이션 컨트롤 플레인의 설치를 위해서는 [설치 가이드](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) +를 따른다. + +## API 리소스 + +컨트롤 플레인이 설치되고 나면, 페더레이션 API 리소스 생성을 시작할 수 +있다. +다음의 가이드는 일부 리소스에 대해서 자세히 설명한다. + +* [클러스터](/docs/tasks/administer-federation/cluster/) +* [컨피그 맵](/docs/tasks/administer-federation/configmap/) +* [데몬 셋](/docs/tasks/administer-federation/daemonset/) +* [디플로이먼트](/docs/tasks/administer-federation/deployment/) +* [이벤트](/docs/tasks/administer-federation/events/) +* [Hpa](/docs/tasks/administer-federation/hpa/) +* [인그레스](/docs/tasks/administer-federation/ingress/) +* [잡](/docs/tasks/administer-federation/job/) +* [네임스페이스](/docs/tasks/administer-federation/namespaces/) +* [레플리카 셋](/docs/tasks/administer-federation/replicaset/) +* [시크릿](/docs/tasks/administer-federation/secret/) +* [서비스](/docs/concepts/cluster-administration/federation-service-discovery/) + + +[API 참조 문서](/docs/reference/federation/)는 페더레이션 +apiserver가 지원하는 모든 리소스를 열거한다. + +## 삭제 캐스케이딩(cascading) + +쿠버네티스 버전 1.6은 연합된 리소스에 대한 삭제 캐스케이딩을 +지원한다. 삭제 케스케이딩이 적용된 경우, 페더레이션 컨트롤 플레인에서 +리소스를 삭제하면, 모든 클러스터에서 상응하는 리소스가 삭제된다. + +REST API 사용하는 경우 삭제 캐스케이딩이 기본으로 활성화되지 않는다. 그것을 +활성화하려면, REST API를 사용하여 페더레이션 컨트롤 플레인에서 리소스를 삭제할 때 +`DeleteOptions.orphanDependents=false` 옵션을 설정한다. `kubectl +delete`를 사용하면 +삭제 캐스케이딩이 기본으로 활성화된다. `kubectl +delete --cascade=false`를 실행하여 비활성화할 수 있다. + +참고: 쿠버네티스 버전 1.5는 페더레이션 리소스의 부분 집합에 대한 삭제 +캐스케이딩을 지원하였다. + +## 단일 클러스터의 범위 + +Google Compute Engine 또는 Amazon Web Services와 같은 IaaS 제공자에서는, VM이 +[영역(zone)](https://cloud.google.com/compute/docs/zones) 또는 [가용 영역(availability +zone)](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)에 존재한다. +다음과 같은 이유로, 쿠버네티스 클러스터의 모든 VM을 동일한 가용 영역에 두는 것을 추천한다. + + - 단일 글로벌 쿠버네티스 클러스터에 비해서, 장애에 대한 단일-포인트가 더 적다. + - 여러 가용 영역에 걸친 클러스터에 비해서, 단일-영역 클러스터의 가용성 속성에 대한 추론이 + 더 쉽다. + - 쿠버네티스 개발자가 시스템을 디자인할 때(예를 들어, 지연 시간, 대역폭, 연관된 장애를 + 고려할 때) 모든 기계가 단일 데이터 센터에 있거나 밀접하게 연결되어 있다고 가정하고 있다. + +가용 영역당 더 많은 VM이 포함되는 적은 수의 클러스터 실행을 추천한다. 다만, 여러 가용 영역 마다 여러 클러스터의 실행도 가능하다. + +가용 영역당 더 적은 수의 클러스터가 선호되는 이유는 다음과 같다. + + - 한 클러스터에 많은 노드가 있는 일부의 경우 파드의 빈 패킹(bin packing)이 향상됨(리소스 단편화 감소). + - 운영 오버헤드 감소(운영 툴과 프로세스의 성숙도에 의해 해당 장점은 반감되는 측면이 있음). + - apiserver VMs와 같이, 클러스터당 비용이 고정된 리소스의 비용을 감소(그러나 중간 규모 부터 큰 규모에 이르는 클러스터의 + 전체 클러스터 비용에 비하면 상대적으로 적은 비용). + +여러 클러스터가 필요한 이유는 다음을 포함한다. + + - 다른 업무의 계층으로부터 특정 계층의 격리가 요구되는 엄격한 보안 정책(다만, 아래의 클러스터 분할하기 정보를 확인하기 + 바람). + - 새로운 쿠버네티스 릴리스 또는 다른 클러스터 소프트웨어를 카나리아(canary) 방식으로 릴리스하기 위해서 클러스터를 테스트. + +## 적절한 클러스터 수 선택하기 + +쿠버네티스 클러스터의 수를 선택하는 것은 상대적으로 고정적인 선택이며, 가끔식만 재고된다. +대조적으로, 클러스터의 노드 수와 서비스 내의 파드 수는 부하와 규모 증가에 따라 +빈번하게 변경될 수 있다. + +클러스터의 수를 선택하기 위해서, 첫 번째로, 쿠버네티스에서 동작할 서비스의 모든 최종 사용자에게 적절한 지연 시간을 제공할 수 있는 지역들을 선택할 +필요가 있다(만약 콘텐츠 전송 네트워크를 사용한다면, CDN-호스트된 콘텐츠의 지연 시간 요구사항 +고려할 필요가 없음). 법적인 이슈 또한 이것에 영향을 줄 수 있다. 예를 들면, 어떤 글로벌 고객 기반의 회사는 US, AP, SA 지역 등 특정 지역에서 클러스터를 운영하도록 결정할 수도 있다. +지역의 수를 `R`이라 부르자. + +두 번째로, 여전히 사용 가능한 상태에서, 얼마나 많은 클러스터가 동시에 사용할 수 없는 상태가 될 수 있는지 결정한다. +사용하지 않는 상태가 될 수 있는 수를 `U`라고 하자. 만약이 값에 확신이 없다면, 1이 괜찮은 선택이다. + +클러스터 장애 상황에서 어느 지역으로든지 직접적인 트래픽에 대한 로드밸런싱이 허용된다면, `R` +또는 적어도 `U + 1` 이상의 클러스터가 있으면 된다. 만약 그렇지 않다면(예를 들어, 클러스터 장애 상황에서 모든 +사용자에 대한 낮은 지연 시간을 유지하고 싶다면), `R * (U + 1)`(각 `R` 지역 내에 `U + 1`) +클러스터가 필요하다. 어느 경우든지, 각 클러스터는 다른 영역에 배치하도록 노력하는 것이 좋다. + +마지막으로, 클러스터 중 어느 클러스터라도 쿠버네티스 클러스터에서 추천되는 최대 노드 수 보다 더 많은 노드가 필요하다면, +더 많은 클러스터가 필요할 것이다. 쿠버네티스 v1.3은 클러스터를 최대 1000노드까지 지원한다. 쿠버네티스 v1.8은 +클러스터를 최대 5000 노드까지 지원한다. 더 자세한 가이드는 [대규모 클러스터 구축하기](/docs/setup/cluster-large/)에서 확인 가능하다. + +{{% /capture %}} + +{{% capture whatsnext %}} +* [페더레이션 + 제안](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)에 대해 더 학습하기. +* 클러스터 페더레이션 [설치 가이드](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) 보기. +* [Kubecon2016 페더레이션 발표](https://www.youtube.com/watch?v=pq9lbkmxpS8) 보기 +* [Kubecon2017 유럽 페더레이션 업데이트 내용](https://www.youtube.com/watch?v=kwOvOLnFYck) 보기 +* [Kubecon2018 유럽 sig-multicluster 업데이트 내용](https://www.youtube.com/watch?v=vGZo5DaThQU) 보기 +* [Kubecon2018 유럽 Federation-v2 프로토타입 발표](https://youtu.be/q27rbaX5Jis?t=7m20s) 보기 +* [Federation-v2 사용자 가이드](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md) 보기 +{{% /capture %}} diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index b58d11a08d..a01e11532c 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -279,43 +279,17 @@ kubectl create secret docker-registry myregistrykey --docker-server=DOCKER_REGIS secret/myregistrykey created. ``` -만약 다중 레지스트리에 접근이 필요하다면, 각 레지스트리에 대한 하나의 시크릿을 생성할 수 있다. -Kubelet은 파드를 위한 이미지를 풀링할 때 `imagePullSecrets`를 단일의 가상 `.docker/config.json` -에 병합할 것이다. +만약 Docer 자격 증명 파일이 이미 존재한다면, 위의 명령을 사용하지 않고, +자격 증명 파일을 쿠버네티스 시크릿으로 가져올 수 있다. +[기존 Docker 자격 증명으로 시크릿 생성](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials)에서 관련 방법을 설명하고 있다. +`kubectl create secret docker-registry`는 +하나의 개인 레지스트리에서만 작동하는 시크릿을 생성하기 때문에, +여러 개인 컨테이너 레지스트리를 사용하는 경우 특히 유용하다. +{{< note >}} 파드는 이미지 풀 시크릿을 자신의 네임스페이스에서만 참조할 수 있다. 따라서 이 과정은 네임스페이스 당 한 번만 수행될 필요가 있다. - -##### kubectl create secrets 우회 - -어떤 이유에서 단일 `.docker/config.json`에 여러 항목이 필요하거나 -위의 커맨드를 통해서는 주어지지 않는 제어가 필요한 경우, [json 또는 yaml로 -시크릿 생성](/docs/user-guide/secrets/#creating-a-secret-manually)을 수행할 수 있다. - -다음 사항을 준수해야 한다. - -- `.dockerconfigjson`에 해당 데이터 항목의 이름을 설정 -- Docker 파일을 base64로 인코딩하여 해당 문자열을 붙여넣을 때, - `data[".dockerconfigjson"]` 필드의 값으로써 깨짐 방지 -- `kubernetes.io/dockerconfigjson`에 `type`을 설정 - -예: - -```yaml -apiVersion: v1 -kind: Secret -metadata: - name: myregistrykey - namespace: awesomeapps -data: - .dockerconfigjson: UmVhbGx5IHJlYWxseSByZWVlZWVlZWVlZWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGx5eXl5eXl5eXl5eXl5eXl5eXl5eSBsbGxsbGxsbGxsbGxsbG9vb29vb29vb29vb29vb29vb29vb29vb29vb25ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg== -type: kubernetes.io/dockerconfigjson -``` - - -`error: no objects passed to create`라는 에러 메시지가 나오면, 그것은 base64 인코딩된 문자열이 유효하지 않다는 것을 뜻한다. -`Secret "myregistrykey" is invalid: data[.dockerconfigjson]: invalid value ...`와 유사한 에러 메시지가 나오면, 그것은 -base64 인코딩 된 데이터가 성공적으로 디코딩되었지만, `.docker/config.json` 파일로는 파싱될 수 없었음을 의미한다. +{{< /note >}} #### 파드의 imagePullSecrets 참조 @@ -374,3 +348,6 @@ imagePullSecrets을 셋팅하여 자동화할 수 있다. - 테넌트는 해당 시크릿을 각 네임스페이스의 imagePullSecrets에 추가한다. {{% /capture %}} + +다중 레지스트리에 접근해야 하는 경우, 각 레지스트리에 대해 하나의 시크릿을 생성할 수 있다. +Kubelet은 모든`imagePullSecrets` 파일을 하나의 가상`.docker / config.json` 파일로 병합한다. diff --git a/content/ko/docs/concepts/containers/runtime-class.md b/content/ko/docs/concepts/containers/runtime-class.md index 33b2d3cce2..72923dc571 100644 --- a/content/ko/docs/concepts/containers/runtime-class.md +++ b/content/ko/docs/concepts/containers/runtime-class.md @@ -87,7 +87,7 @@ spec: {{< note >}} 런타임 클래스 쓰기 작업(create/update/patch/delete)은 클러스터 관리자로 제한할 것을 권장한다. 이것은 일반적으로 기본 설정이다. 더 자세한 정보는 [권한 -개요](https://kubernetes.io/docs/reference/access-authn-authz/authorization/)를 참고한다. +개요](/docs/reference/access-authn-authz/authorization/)를 참고한다. {{< /note >}} ### 사용 diff --git a/content/ko/docs/concepts/overview/components.md b/content/ko/docs/concepts/overview/components.md index 717c2e6b29..2c1d161d2d 100644 --- a/content/ko/docs/concepts/overview/components.md +++ b/content/ko/docs/concepts/overview/components.md @@ -2,6 +2,9 @@ title: 쿠버네티스 컴포넌트 content_template: templates/concept weight: 20 +card: + name: concepts + weight: 20 --- {{% capture overview %}} diff --git a/content/ko/docs/concepts/overview/kubernetes-api.md b/content/ko/docs/concepts/overview/kubernetes-api.md index 860cdc003b..d5e93902cf 100644 --- a/content/ko/docs/concepts/overview/kubernetes-api.md +++ b/content/ko/docs/concepts/overview/kubernetes-api.md @@ -2,6 +2,9 @@ title: 쿠버네티스 API content_template: templates/concept weight: 30 +card: + name: concepts + weight: 30 --- {{% capture overview %}} diff --git a/content/ko/docs/concepts/overview/object-management-kubectl/imperative-command.md b/content/ko/docs/concepts/overview/object-management-kubectl/imperative-command.md new file mode 100644 index 0000000000..228363911b --- /dev/null +++ b/content/ko/docs/concepts/overview/object-management-kubectl/imperative-command.md @@ -0,0 +1,162 @@ +--- +title: 명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기 +content_template: templates/concept +weight: 20 +--- + +{{% capture overview %}} +쿠버네티스 오브젝트는 `kubectl` 커맨드 라인 툴 속에 내장된 명령형 커맨드를 이용함으로써 +바로 신속하게 생성, 업데이트 및 삭제할 수 있다. 이 문서는 어떻게 커맨드가 구성되어 있으며, +이를 사용하여 활성 오브젝트를 어떻게 관리하는 지에 대해 설명한다. +{{% /capture %}} + +{{% capture body %}} + +## 트레이드 오프 + +`kubectl`툴은 3가지 종류의 오브젝트 관리를 지원한다. + +* 명령형 커맨드 +* 명령형 오브젝트 구성 +* 선언형 오브젝트 구성 + +각 종류별 오브젝트 관리의 장점과 단점에 대한 논의는 [쿠버네티스 오브젝트 관리](/ko/docs/concepts/overview/object-management-kubectl/overview/) +를 참고한다. + +## 오브젝트 생성 방법 + +`kubectl` 툴은 가장 일반적인 오브젝트 타입을 생성하는데 동사 형태 기반의 커맨드를 +지원한다. 쿠버네티스 오브젝트 타입에 익숙하지 않은 사용자가 인지할 수 있도록 커맨드 +이름이 지어졌다. + +- `run`: 하나 이상의 파드 내 컨테이너를 실행하도록 새로운 디플로이먼트 오브젝트를 생성한다. +- `expose`: 파드에 걸쳐 트래픽을 로드 밸런스하도록 새로운 서비스 오브젝트를 생성한다. +- `autoscale`: 디플로이먼트와 같이, 하나의 컨트롤러에 대해 자동으로 수평적 스케일이 이루어 지도록 새로운 Autoscaler 오브젝트를 생성한다. + +또한 `kubectl` 툴은 오브젝트 타입에 의해 구동되는 생성 커맨드를 지원한다. +이러한 커맨드는 더 많은 오브젝트 타입을 지원해주며 그 의도하는 바에 대해 +보다 명확하게 해주지만, 사용자가 생성하고자 하는 오브젝트 타입에 대해 +알 수 있도록 해야 한다. + +- `create <오브젝트 타입> [<서브 타입>] <인스턴스명>` + +일부 오브젝트 타입은 `create` 커맨드 내 정의할 수 있는 서브 타입을 가진다. +예를 들어, 서비스 오브젝트는 ClusterIP, LoadBalancer 및 NodePort 등을 +포함하는 여러 서브 타입을 가진다, 다음은 NodePort 서브 타입을 통해 서비스를 +생성하는 예제이다. + +```shell +kubectl create service nodeport <사용자 서비스 명칭> +``` + +이전 예제에서, `create service nodeport` 커맨드는 +`create service` 커맨드의 서브 커맨드라고 칭한다. + +`-h` 플래그를 사용하여 서브 커맨드에 의해 지원되는 인수 및 플래그를 +찾아 볼 수 있다. + +```shell +kubectl create service nodeport -h +``` + +## 오브젝트 업데이트 방법 + +`kubectl` 커맨드는 일반적인 몇몇의 업데이트 작업을 위해 동사 형태 기반의 커맨드를 지원한다. +이 커맨드는 쿠버네티스 오브젝트에 익숙하지 않은 사용자가 설정되어야 +하는 특정 필드를 모르는 상태에서도 업데이트를 수행할 수 있도록 +이름 지어졌다. + +- `scale`: 컨트롤러의 레플리카 수를 업데이트 함으로써 파드를 추가 또는 제거하는 컨트롤러를 수평적으로 스케일한다. +- `annotate`: 오브젝트로부터 어노테이션을 추가 또는 제거한다. +- `label`: 오브젝트에서 레이블을 추가 또는 제거한다. + +`kubectl` 커맨드는 또한 오브젝트 측면에서 구동되는 업데이트 커맨드를 지원한다. +이 측면의 설정은 다른 오브젝트 타입에 대한 다른 필드를 설정 할 수도 있다. + +- `set` ``: 오브젝트의 측면을 설정한다. + +{{< note >}} +쿠버네티스 1.5 버전에서는 모든 동사 형태 기반의 커맨드가 관련된 측면 중심의 커맨드를 가지는 것은 아니다. +{{< /note >}} + +`kubectl` 툴은 활성 오브젝트를 직접 업데이트하기 위해 추가적인 방법을 지원하지만, +쿠버네티스 오브젝트 스키마에 대한 추가적인 이해를 요구한다. + +- `edit`: 편집기에서 구성을 열어 활성 오브젝트에 대한 원래 그대로의 구성을 바로 편집한다. +- `patch`: 패치 문자열를 사용하여 활성 오브젝트를 바로 편집한다. +패치 문자열에 대한 보다 자세한 정보를 보려면 +[API 규정](https://git.k8s.io/community/contributors/devel/api-conventions.md#patch-operations)에서 패치 섹션을 참고한다. + +## 오브젝트 삭제 방법 + +클러스터에서 오브젝트를 삭제하기 위해 `delete` 커맨드을 사용할 수 있다. + +- `delete <타입>/<이름>` + +{{< note >}} +명령형 커맨드와 명령형 오브젝트 구성 모두 `kubectl delete`를 사용할 수 +있다. 차이점은 커맨드에 전해지는 인수에 있다. 명령형 커맨드로 +`kubectl delete`을 사용하기 위해, 삭제할 오브젝트를 인수로 전한다. +다음은 nginx라는 디플로이먼트 오브젝트를 전하는 예제이다. +{{< /note >}} + +```shell +kubectl delete deployment/nginx +``` + +## 오브젝트 확인 방법 + +{{< comment >}} +TODO(pwittrock): 구현이 이루어지면 주석을 해제한다. + +오브젝트의 특정 필드를 출력하기 위해 `kubectl view`를 사용할 수 있다. + +- `view`: 오브젝트의 특정 필드의 값을 출력한다. + +{{< /comment >}} + + + +오브젝트에 대한 정보를 출력하는 몇 가지 커맨드가 있다. + +- `get`: 일치하는 오브젝트에 대한 기본 정보를 출력한다. 옵션 리스트를 확인하기 위해 `get -h`를 사용한다. +- `describe`: 일치하는 오브젝트에 대해 수집한 상세한 정보를 출력한다. +- `logs`: 파드에서 실행 중인 컨테이너에 대한 stdout과 stderr를 출력한다. + +## 생성 전 오브젝트 수정을 위해 `set` 커맨드 사용하기 + +`create` 커맨드에 사용할 수 있는 플래그가 없는 몇 가지 오브젝트 +필드가 있다. 이러한 경우, 오브젝트 생성 전에 필드에 대한 값을 +정의하기 위해 `set`과 `create`을 조합해서 사용할 수 있다. +이는 `set` 커맨드에 `create` 커맨드의 출력을 파이프 함으로써 수행할 수 있다. +다음은 관련 예제이다. + +```sh +kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run | kubectl set selector --local -f - 'environment=qa' -o yaml | kubectl create -f - +``` + +1. `kubectl create service -o yaml --dry-run` 커맨드는 서비스에 대한 구성을 생성하지만, 이를 쿠버네티스 API 서버에 전송하는 대신 YAML 형식으로 stdout에 출력한다. +1. `kubectl set selector --local -f - -o yaml` 커맨드는 stdin으로부터 구성을 읽어, YAML 형식으로 stdout에 업데이트된 구성을 기록한다. +1. `kubectl create -f -` 커맨드는 stdin을 통해 제공된 구성을 사용하여 오브젝트를 생성한다. + +## 생성 전 오브젝트 수정을 위해 `--edit` 사용하기 + +생성 전에 오브젝트에 임의의 변경을 가하기 위해 `kubectl create --edit` 을 사용할 수 있다. +다음은 관련 예제이다. + +```sh +kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run > /tmp/srv.yaml +kubectl create --edit -f /tmp/srv.yaml +``` + +1. `kubectl create service` 커맨드는 서비스에 대한 구성을 생성하고 이를 `/tmp/srv.yaml`에 저장한다. +1. `kubectl create --edit` 커맨드는 오브젝트를 생성하기 전에 편집을 위해 구성파일을 열어준다. + +{{% /capture %}} + +{{% capture whatsnext %}} +- [오브젝트 구성을 이용하여 쿠베네티스 관리하기(명령형)](/docs/concepts/overview/object-management-kubectl/imperative-config/) +- [오브젝트 구성을 이용하여 쿠버네티스 관리하기(선언형)](/docs/concepts/overview/object-management-kubectl/declarative-config/) +- [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl/) +- [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) +{{% /capture %}} \ No newline at end of file diff --git a/content/ko/docs/concepts/overview/what-is-kubernetes.md b/content/ko/docs/concepts/overview/what-is-kubernetes.md index e507e8540e..8d69e47990 100644 --- a/content/ko/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ko/docs/concepts/overview/what-is-kubernetes.md @@ -2,6 +2,9 @@ title: 쿠버네티스란 무엇인가? content_template: templates/concept weight: 10 +card: + name: concepts + weight: 10 --- {{% capture overview %}} @@ -104,7 +107,7 @@ A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필 ![Why Containers?](/images/docs/why_containers.svg) -애플리케이션을 배포하는 *구식의 방법* 은 운영 체제의 패키지 관리자를 +애플리케이션을 배포하는 *옛 방식* 은 운영 체제의 패키지 관리자를 사용해서 애플리케이션을 호스트에 설치하는 것이었다. 이 방식은 애플리케이션의 실행 파일, 설정, 라이브러리 서로 간의 라이프사이클과 호스트 OS와 얽히게 된다는 단점이 있다. 예측 가능한 롤아웃과 롤백을 diff --git a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 02f081bde9..6be2c9212d 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -2,6 +2,9 @@ title: 쿠버네티스 오브젝트 이해하기 content_template: templates/concept weight: 10 +card: + name: concepts + weight: 40 --- {{% capture overview %}} @@ -21,7 +24,7 @@ weight: 10 생성이든, 수정이든, 또는 삭제든 쿠버네티스 오브젝트를 동작시키려면, [Kubernetes API](/docs/concepts/overview/kubernetes-api/)를 이용해야 한다. 예를 들어, `kubectl` 커맨드-라인 인터페이스를 이용할 때, CLI는 여러분 대신 필요한 쿠버네티스 API를 호출해 준다. 또한, 여러분은 [Client Libraries](/docs/reference/using-api/client-libraries/) 중 하나를 이용하여 여러분만의 프로그램에서 쿠버네티스 API를 직접 이용할 수도 있다. -### 오브젝트 (spec)과 상태(status) +### 오브젝트 스펙(spec)과 상태(status) 모든 쿠버네티스 오브젝트는 오브젝트의 구성을 결정해주는 두 개의 중첩된 오브젝트 필드를 포함하는데 오브젝트 *spec* 과 오브젝트 *status* 가 그것이다. 필히 제공되어야만 하는 *spec* 은, 여러분이 오브젝트가 가졌으면 하고 원하는 특징, 즉 *의도한 상태* 를 기술한다. *status* 는 오브젝트의 *실제 상태* 를 기술하고, 쿠버네티스 시스템에 의해 제공되고 업데이트 된다. 주어진 임의의 시간에, 쿠버네티스 컨트롤 플레인은 오브젝트의 실제 상태를 여러분이 제시한 의도한 상태에 일치시키기 위해 능동적으로 관리한다. diff --git a/content/ko/docs/concepts/workloads/pods/pod-overview.md b/content/ko/docs/concepts/workloads/pods/pod-overview.md index 3af57fe0cc..416f3983eb 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-overview.md +++ b/content/ko/docs/concepts/workloads/pods/pod-overview.md @@ -2,6 +2,9 @@ title: 파드(Pod) 개요 content_template: templates/concept weight: 10 +card: + name: concepts + weight: 60 --- {{% capture overview %}} diff --git a/content/ko/docs/home/_index.md b/content/ko/docs/home/_index.md index d418be6fb8..a2a01163ae 100644 --- a/content/ko/docs/home/_index.md +++ b/content/ko/docs/home/_index.md @@ -1,8 +1,9 @@ --- title: 쿠버네티스 문서 -noedit: true +noedit: true cid: docsHome layout: docsportal_home +class: gridPage linkTitle: "홈" main_menu: true weight: 10 @@ -13,4 +14,43 @@ menu: weight: 20 post: >

개념, 튜토리얼 및 참조 문서와 함께 쿠버네티스 사용하는 방법을 익힐 수 있다. 또한, 문서에 기여하는 것도 도움을 줄 수 있다!

+overview: > + 쿠버네티스는 배포, 스케일링, 그리고 컨테이너화된 애플리케이션의 관리를 자동화 해주는 오픈 소스 컨테이너 오케스트레이션 엔진이다. 본 오픈 소스 프로젝트는 Cloud Native Computing Foundation(CNCF)가 주관한다. +cards: +- name: concepts + title: "기초 이해하기" + description: "쿠버네티스와 쿠버네티스의 기본 개념을 배운다." + button: "개념 배우기" + button_path: "/docs/concepts" +- name: tutorials + title: "쿠버네티스 사용해보기" + description: "쿠버네티스에 애플리케이션을 배포하는 방법을 튜토리얼을 따라하며 배운다." + button: "튜토리얼 보기" + button_path: "/docs/tutorials" +- name: setup + title: "클러스터 구축하기" + description: "보유한 자원과 요구에 맞게 동작하는 쿠버네티스를 구축한다." + button: "쿠버네티스 구축하기" + button_path: "/docs/setup" +- name: tasks + title: "쿠버네티스 사용법 배우기" + description: "일반적인 태스크와 이를 수행하는 방법을 여러 단계로 구성된 짧은 시퀀스를 통해 살펴본다." + button: "태스크 보기" + button_path: "/docs/tasks" +- name: reference + title: 레퍼런스 정보 찾기 + description: 용어, 커맨드 라인 구문, API 자원 종류, 그리고 설치 툴 문서를 살펴본다. + button: 레퍼런스 보기 + button_path: /docs/reference +- name: contribute + title: 문서에 기여하기 + description: 이 프로젝트가 처음인 사람이든, 오래 활동한 사람이든 상관없이 누구나 기여할 수 있다. + button: 문서에 기여하기 + button_path: /docs/contribute +- name: download + title: 쿠버네티스 내려받기 + description: 쿠버네티스를 설치하거나 최신의 버전으로 업그레이드하는 경우, 현재 릴리스 노트를 참고한다. +- name: about + title: 문서에 대하여 + description: 이 웹사이트는 현재 버전과 이전 4개 버전의 쿠버네티스 문서를 포함한다. --- diff --git a/content/ko/docs/reference/glossary/index.md b/content/ko/docs/reference/glossary/index.md index d462206f54..c7a4b3a927 100755 --- a/content/ko/docs/reference/glossary/index.md +++ b/content/ko/docs/reference/glossary/index.md @@ -4,5 +4,9 @@ layout: glossary noedit: true default_active_tag: fundamental weight: 5 +card: + name: reference + weight: 10 + title: Glossary --- diff --git a/content/ko/docs/setup/cri.md b/content/ko/docs/setup/cri.md index af367d0852..f60582c985 100644 --- a/content/ko/docs/setup/cri.md +++ b/content/ko/docs/setup/cri.md @@ -4,33 +4,42 @@ content_template: templates/concept weight: 100 --- {{% capture overview %}} -v1.6.0에서부터, 쿠버네티스는 CRI(컨테이너 런타임 인터페이스) 사용을 기본으로 지원한다. +{{< feature-state for_k8s_version="v1.6" state="stable" >}} +파드에서 컨테이너를 실행하기 위해 쿠버네티스는 컨테이너 런타임을 사용한다. 이 페이지는 다양한 런타임들에 대한 설치 지침을 담고 있다. {{% /capture %}} {{% capture body %}} -다음의 커맨드들은 사용자의 운영체제에 따라 root로서 실행하길 바란다. -각 호스트에 SSH 접속 후 `sudo -i` 실행을 통해서 root 사용자가 될 수 있을 것이다. - {{< caution >}} -A flaw was found in the way runc handled system file descriptors when running containers. -A malicious container could use this flaw to overwrite contents of the runc binary and -consequently run arbitrary commands on the container host system. +컨테이너를 실행할 때 runc가 시스템 파일 디스크립터를 처리하는 방식에서 결함이 발견되었다. +악성 컨테이너는 이 결함을 사용하여 runc 바이너리의 내용을 덮어쓸 수 있으며 +따라서 컨테이너 호스트 시스템에서 임의의 명령을 실행할 수 있다. -Please refer to this link for more information about this issue -[cve-2019-5736 : runc vulnerability ] (https://access.redhat.com/security/cve/cve-2019-5736) +이 문제에 대한 자세한 내용은 +[cve-2019-5736 : runc 취약점 ] (https://access.redhat.com/security/cve/cve-2019-5736) 참고하자. {{< /caution >}} -## Cgroup 드라이버 +### 적용 가능성 -Linux 배포판의 init 시스템이 systemd인 경우, init 프로세스는 루트 cgroup을 생성 및 사용하고 -cgroup 관리자로 작동한다. Systemd는 cgroup과의 긴밀한 통합을 통해 -프로세스당 cgroup을 할당한다. 컨테이너 런타임과 kubelet이 -`cgroupfs`를 사용하도록 설정할 수 있다. 이 경우는 두 개의 서로 다른 cgroup 관리자가 존재하게 된다는 뜻이다. +{{< note >}} +이 문서는 Linux에 CRI를 설치하는 사용자를 위해 작성되었다. +다른 운영 체제의 경우, 해당 플랫폼과 관련된 문서를 찾아보자. +{{< /note >}} -Cgroup은 프로세스에 할당된 리소스를 제한하는데 사용된다. +이 가이드의 모든 명령은 `root`로 실행해야 한다. +예를 들어,`sudo`로 접두사를 붙이거나, `root` 사용자가 되어 명령을 실행한다. + +### Cgroup 드라이버 + +Linux 배포판의 init 시스템이 systemd인 경우, init 프로세스는 +root control group(`cgroup`)을 생성 및 사용하는 cgroup 관리자로 작동한다. +Systemd는 cgroup과의 긴밀한 통합을 통해 프로세스당 cgroup을 할당한다. +컨테이너 런타임과 kubelet이 `cgroupfs`를 사용하도록 설정할 수 있다. +systemd와 함께`cgroupfs`를 사용하면 두 개의 서로 다른 cgroup 관리자가 존재하게 된다는 뜻이다. + +Control group은 프로세스에 할당된 리소스를 제한하는데 사용된다. 단일 cgroup 관리자는 할당된 리소스가 무엇인지를 단순화하고, 기본적으로 사용가능한 리소스와 사용중인 리소스를 일관성있게 볼 수 있다. 관리자가 두 개인 경우, 이런 리소스도 두 개의 관점에서 보게 된다. kubelet과 Docker는 diff --git a/content/ko/docs/setup/multiple-zones.md b/content/ko/docs/setup/multiple-zones.md index b2360a9fe2..679a55f5ef 100644 --- a/content/ko/docs/setup/multiple-zones.md +++ b/content/ko/docs/setup/multiple-zones.md @@ -1,8 +1,17 @@ --- title: 여러 영역에서 구동 weight: 90 +content_template: templates/concept --- +{{% capture overview %}} + +이 페이지는 여러 영역에서 어떻게 클러스터를 구동하는지 설명한다. + +{{% /capture %}} + +{{% capture body %}} + ## 소개 Kubernetes 1.2 adds support for running a single cluster in multiple failure zones @@ -23,8 +32,6 @@ add similar support for other clouds or even bare metal, by simply arranging for the appropriate labels to be added to nodes and volumes). -{{< toc >}} - ## 기능 When nodes are started, the kubelet automatically adds labels to them with @@ -118,9 +125,12 @@ labels are `failure-domain.beta.kubernetes.io/region` for the region, and `failure-domain.beta.kubernetes.io/zone` for the zone: ```shell -> kubectl get nodes --show-labels +kubectl get nodes --show-labels +``` +The output is similar to this: +```shell NAME STATUS ROLES AGE VERSION LABELS kubernetes-master Ready,SchedulingDisabled 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master kubernetes-minion-87j9 Ready 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9 @@ -154,8 +164,12 @@ View the nodes again; 3 more nodes should have launched and be tagged in us-central1-b: ```shell -> kubectl get nodes --show-labels +kubectl get nodes --show-labels +``` +The output is similar to this: + +```shell NAME STATUS ROLES AGE VERSION LABELS kubernetes-master Ready,SchedulingDisabled 16m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master kubernetes-minion-281d Ready 2m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d @@ -207,7 +221,12 @@ was addressed in 1.3+. Now let's validate that Kubernetes automatically labeled the zone & region the PV was created in. ```shell -> kubectl get pv --show-labels +kubectl get pv --show-labels +``` + +The output is similar to this: + +```shell NAME CAPACITY ACCESSMODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE LABELS pv-gce-mj4gm 5Gi RWO Retain Bound default/claim1 manual 46s failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a ``` @@ -240,9 +259,20 @@ Note that the pod was automatically created in the same zone as the volume, as cross-zone attachments are not generally permitted by cloud providers: ```shell -> kubectl describe pod mypod | grep Node +kubectl describe pod mypod | grep Node +``` + +```shell Node: kubernetes-minion-9vlv/10.240.0.5 -> kubectl get node kubernetes-minion-9vlv --show-labels +``` + +And check node labels: + +```shell +kubectl get node kubernetes-minion-9vlv --show-labels +``` + +```shell NAME STATUS AGE VERSION LABELS kubernetes-minion-9vlv Ready 22m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv ``` @@ -279,12 +309,20 @@ find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl crea The pods should be spread across all 3 zones: ```shell -> kubectl describe pod -l app=guestbook | grep Node +kubectl describe pod -l app=guestbook | grep Node +``` + +```shell Node: kubernetes-minion-9vlv/10.240.0.5 Node: kubernetes-minion-281d/10.240.0.8 Node: kubernetes-minion-olsh/10.240.0.11 +``` - > kubectl get node kubernetes-minion-9vlv kubernetes-minion-281d kubernetes-minion-olsh --show-labels +```shell +kubectl get node kubernetes-minion-9vlv kubernetes-minion-281d kubernetes-minion-olsh --show-labels +``` + +```shell NAME STATUS ROLES AGE VERSION LABELS kubernetes-minion-9vlv Ready 34m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv kubernetes-minion-281d Ready 20m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d @@ -296,15 +334,42 @@ Load-balancers span all zones in a cluster; the guestbook-go example includes an example load-balanced service: ```shell -> kubectl describe service guestbook | grep LoadBalancer.Ingress +kubectl describe service guestbook | grep LoadBalancer.Ingress +``` + +The output is similar to this: + +```shell LoadBalancer Ingress: 130.211.126.21 +``` -> ip=130.211.126.21 +Set the above IP: -> curl -s http://${ip}:3000/env | grep HOSTNAME +```shell +export IP=130.211.126.21 +``` + +Explore with curl via IP: + +```shell +curl -s http://${IP}:3000/env | grep HOSTNAME +``` + +The output is similar to this: + +```shell "HOSTNAME": "guestbook-44sep", +``` -> (for i in `seq 20`; do curl -s http://${ip}:3000/env | grep HOSTNAME; done) | sort | uniq +Again, explore multiple times: + +```shell +(for i in `seq 20`; do curl -s http://${IP}:3000/env | grep HOSTNAME; done) | sort | uniq +``` + +The output is similar to this: + +```shell "HOSTNAME": "guestbook-44sep", "HOSTNAME": "guestbook-hum5n", "HOSTNAME": "guestbook-ppm40", @@ -331,3 +396,5 @@ KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2c k KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b kubernetes/cluster/kube-down.sh KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh ``` + +{{% /capture %}} diff --git a/content/ko/docs/setup/pick-right-solution.md b/content/ko/docs/setup/pick-right-solution.md index bf49e04cab..b6c60fd84a 100644 --- a/content/ko/docs/setup/pick-right-solution.md +++ b/content/ko/docs/setup/pick-right-solution.md @@ -2,6 +2,20 @@ title: 알맞은 솔루션 선정 weight: 10 content_template: templates/concept +card: + name: setup + weight: 20 + anchors: + - anchor: "#호스트-된-솔루션" + title: 호스트 된 솔루션 + - anchor: "#턴키-클라우드-솔루션" + title: 턴키 클라우드 솔루션 + - anchor: "#온-프레미스-턴키-클라우드-솔루션" + title: 온-프레미스 솔루션 + - anchor: "#사용자-지정-솔루션" + title: 사용자 지정 솔루션 + - anchor: "#로컬-머신-솔루션" + title: 로컬 머신 --- {{% capture overview %}} diff --git a/content/ko/docs/setup/release/building-from-source.md b/content/ko/docs/setup/release/building-from-source.md index 5320056d08..d8b9af438f 100644 --- a/content/ko/docs/setup/release/building-from-source.md +++ b/content/ko/docs/setup/release/building-from-source.md @@ -1,6 +1,10 @@ --- title: 릴리스 빌드 content_template: templates/concept +card: + name: download + weight: 20 + title: 릴리스 빌드하기 --- {{% capture overview %}} diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index c402d2740d..61884a8829 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -243,7 +243,7 @@ spec: resource: name: cpu target: - kind: AverageUtilization + type: AverageUtilization averageUtilization: 50 - type: Pods pods: diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md index e9490e0c8b..83d146845e 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -67,7 +67,7 @@ Horizontal Pod Autoscaler는 컨트롤러 HorizontalPodAutoscaler는 보통 일련의 API 집합(`metrics.k8s.io`, `custom.metrics.k8s.io`, `external.metrics.k8s.io`)에서 메트릭을 가져온다. `metrics.k8s.io` API는 대개 별도로 시작해야 하는 메트릭-서버에 의해 제공된다. 가이드는 -[메트릭-서버](https://kubernetes.io/docs/tasks/debug-application-cluster/core-metrics-pipeline/#metrics-server)를 +[메트릭-서버](/docs/tasks/debug-application-cluster/core-metrics-pipeline/#metrics-server)를 참조한다. HorizontalPodAutoscaler는 힙스터(Heapster)에서 직접 메트릭을 가져올 수도 있다. {{< note >}} diff --git a/content/ko/docs/tasks/tools/install-minikube.md b/content/ko/docs/tasks/tools/install-minikube.md index 1fd805533a..038851b475 100644 --- a/content/ko/docs/tasks/tools/install-minikube.md +++ b/content/ko/docs/tasks/tools/install-minikube.md @@ -2,6 +2,9 @@ title: Minikube 설치 content_template: templates/task weight: 20 +card: + name: tasks + weight: 10 --- {{% capture overview %}} diff --git a/content/ko/docs/tutorials/hello-minikube.md b/content/ko/docs/tutorials/hello-minikube.md index 0a00e5e5d0..e6269333d1 100644 --- a/content/ko/docs/tutorials/hello-minikube.md +++ b/content/ko/docs/tutorials/hello-minikube.md @@ -8,6 +8,9 @@ menu: weight: 10 post: >

Ready to get your hands dirty? Build a simple Kubernetes cluster that runs "Hello World" for Node.js.

+card: + name: tutorials + weight: 10 --- {{% capture overview %}} diff --git a/content/ko/docs/tutorials/kubernetes-basics/_index.html b/content/ko/docs/tutorials/kubernetes-basics/_index.html index ff57ddc2d3..1f9659628a 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/_index.html +++ b/content/ko/docs/tutorials/kubernetes-basics/_index.html @@ -2,6 +2,10 @@ title: 쿠버네티스 기초 학습 linkTitle: 쿠버네티스 기초 학습 weight: 10 +card: + name: tutorials + weight: 20 + title: 쿠버네티스 기초 학습 --- diff --git a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html index db88345168..ff14825a38 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html @@ -28,8 +28,8 @@ weight: 10

애플리케이션을 스케일하기

지난 모듈에서 디플로이먼트, - 를 만들고 서비스를 + href="/docs/concepts/workloads/controllers/deployment/"> 디플로이먼트, + 를 만들고 서비스를 통해서 디플로이먼트를 외부에 노출시켜 봤다. 해당 디플로이먼트는 애플리케이션을 구동하기 위해 단 하나의 파드(Pod)만을 생성했었다. 트래픽이 증가하면, 사용자 요청에 맞추어 애플리케이션의 규모를 조정할 필요가 있다.

@@ -94,7 +94,7 @@ weight: 10

디플로이먼트를 스케일 아웃하면 신규 파드가 생성되어서 가용한 자원이 있는 노드에 스케줄된다. 스케일링 기능은 새로 의도한 상태(desired state)까지 파드의 수를 늘린다. 쿠버네티스는 - 파드의 오토스케일링 + 파드의 오토스케일링 도 지원하지만 본 튜토리얼에서는 다루지 않는다. 0까지 스케일링하는 것도 가능하다. 이 경우 해당 디플로이먼트의 모든 파드가 종료된다.

diff --git a/content/ko/docs/tutorials/online-training/overview.md b/content/ko/docs/tutorials/online-training/overview.md index d3a41008fe..d2e9da7f48 100644 --- a/content/ko/docs/tutorials/online-training/overview.md +++ b/content/ko/docs/tutorials/online-training/overview.md @@ -17,6 +17,8 @@ content_template: templates/concept * [Google Kubernetes Engine 시작하기 (Coursera)](https://www.coursera.org/learn/google-kubernetes-engine) +* [Google Kubernetes Engine Deep Dive (Linux Academy)](https://linuxacademy.com/google-cloud-platform/training/course/name/google-kubernetes-engine-deep-dive) + * [쿠버네티스 시작하기 (Pluralsight)](https://www.pluralsight.com/courses/getting-started-kubernetes) * [쿠버네티스 소개 및 실습 (Instruqt)](https://play.instruqt.com/public/topics/getting-started-with-kubernetes) @@ -25,12 +27,20 @@ content_template: templates/concept * [쿠버네티스 소개 (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x) +* [Kubernetes Essentials (Linux Academy)](https://linuxacademy.com/linux/training/course/name/kubernetes-essentials) + * [초보자를 위한 쿠버네티스 실습 랩 (KodeKloud.com)](https://kodekloud.com/p/kubernetes-for-the-absolute-beginners-hands-on) +* [Kubernetes Quick Start (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-quick-start) + * [쿠버네티스 심화 학습 (LinuxAcademy.com)](https://linuxacademy.com/linux/training/course/name/kubernetes-the-hard-way) * [대화식 실습 시나리오를 사용하여 쿠버네티스 배우기 (Katacoda)](https://www.katacoda.com/courses/kubernetes/) +* [Monitoring Kubernetes With Prometheus (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-and-prometheus) + * [쿠버네티스와 확장 가능한 마이크로서비스(Microservices) (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615) +* [Self-paced Kubernetes online course (Learnk8s Academy)](https://learnk8s.io/academy) + {{% /capture %}} diff --git a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md new file mode 100644 index 0000000000..4c80d9c805 --- /dev/null +++ b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md @@ -0,0 +1,1038 @@ +--- +reviewers: +title: 스테이트풀셋 기본 +content_template: templates/tutorial +weight: 10 +--- + +{{% capture overview %}} +이 튜토리얼은 스테이트풀셋([StatefulSets](/docs/concepts/workloads/controllers/statefulset/))을 이용하여 +애플리케이션을 관리하는 방법을 소개한다. 어떻게 스테이트풀셋의 파드(Pod)을 생성하고 삭제하며 +스케일링하고 업데이트하는지 시연한다. +{{% /capture %}} + +{{% capture prerequisites %}} +튜토리얼을 시작하기 전에 다음의 쿠버네티스 컨셉에 대해 +익숙해야 한다. + +* [파드](/docs/user-guide/pods/single-container/) +* [클러스터 DNS(Cluster DNS)](/docs/concepts/services-networking/dns-pod-service/) +* [헤드리스 서비스(Headless Services)](/docs/concepts/services-networking/service/#headless-services) +* [퍼시스턴트볼륨(PersistentVolumes)](/docs/concepts/storage/persistent-volumes/) +* [퍼시턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) +* [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/) +* [kubectl CLI](/docs/user-guide/kubectl/) + +이 튜토리얼은 클러스터가 퍼시스턴스볼륨을 동적으로 프로비저닝 하도록 +설정되었다고 가정한다. 만약 클러스터가 이렇게 설정되어 있지 않다면, +튜토리얼 시작 전에 수동으로 2개의 1 GiB 볼륨을 +프로비저닝해야 한다. +{{% /capture %}} + +{{% capture objectives %}} +스테이트풀셋은 상태 유지가 필요한(stateful) 애플리케이션과 분산시스템에서 +이용하도록 의도했다. 그러나 쿠버네티스 상에 스테이트풀 애플리케이션과 +분산시스템을 관리하는 것은 광범위하고 복잡한 주제이다. 스테이트풀셋의 기본 기능을 보여주기 위해 +이 둘을 결합하지 않고, 스테이트풀셋을 사용한 +단순 웹 애플리케이션을 배포할 것이다. + +이 튜토리얼을 마치면 다음 항목에 대해 익숙해질 것이다. + +* 스테이트풀셋을 어떻게 생성하는지 +* 스테이트풀셋이 어떻게 파드를 관리하는지 +* 스테이트풀셋을 어떻게 삭제하는지 +* 스테이트풀셋은 어떻게 스케일링하는지 +* 스테이트풀셋의 파드는 어떻게 업데이트하는지 +{{% /capture %}} + +{{% capture lessoncontent %}} +## 스테이트풀셋 생성하기 + +아래 예제를 이용해서 스테이트풀셋을 생성하자. 이는 +[스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/) 개념에서 보인 +예제와 유사하다. 이것은 `web`과 이 스테이트풀셋 파드의 IP 주소를 게시하는 +[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)인 +`nginx` 를 생성한다. + +{{< codenew file="application/web/web.yaml" >}} + +위에 예제를 다운로드 받아서 파일이름을 `web.yaml`으로 저장하자. + +2개의 터미널창을 사용한다. 첫째 터미널에서 +[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get)을 이용해서 +스테이트풀셋의 파드가 생성되는지 감시하자. + +```shell +kubectl get pods -w -l app=nginx +``` + +두번째 터미널에서 +[`kubectl create`](/docs/reference/generated/kubectl/kubectl-commands/#create)로 +`web.yaml`에 정의된 헤드리스 서비스와 스테이트풀셋을 생성한다. + +```shell +kubectl create -f web.yaml +service/nginx created +statefulset.apps/web created +``` + +상기 명령어는 [NGINX](https://www.nginx.com) 웹 서버를 +실행하는 2개의 파드를 생성한다. `nginx` 서비스와 +`web` 스테이트풀셋이 성공적으로 생성되었는지 알아보자. + +```shell +kubectl get service nginx +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +nginx ClusterIP None 80/TCP 12s + +kubectl get statefulset web +NAME DESIRED CURRENT AGE +web 2 1 20s +``` + +### 차례대로 파드 생성하기 + +N개의 레플리카를 가진 스테이트풀셋은 배포시에 +순차적으로 {0..N-1} 순으로 생성된다. +첫째 터미널에서 `kubectl get` 명령의 출력 내용을 살펴보자. +결국 그 내용은 아래 예와 비슷할 것이다. + +```shell +kubectl get pods -w -l app=nginx +NAME READY STATUS RESTARTS AGE +web-0 0/1 Pending 0 0s +web-0 0/1 Pending 0 0s +web-0 0/1 ContainerCreating 0 0s +web-0 1/1 Running 0 19s +web-1 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-1 0/1 ContainerCreating 0 0s +web-1 1/1 Running 0 18s +``` + +`web-1` 파드는 `web-0` 파드가 [Running과 Ready](/docs/user-guide/pod-states) 상태가 되기 전에 +시작하지 않음을 주의하자. + +## 스테이트풀셋 안에 파드 + +스테이트풀셋 안에 파드는 고유한 순번과 동일한 네트워크 신원을 가진다. + +### 파드 순번 살펴보기 + +스테이트풀셋의 파드를 가져오자. + +```shell +kubectl get pods -l app=nginx +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 1m +web-1 1/1 Running 0 1m + +``` + +[스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/) 개념에서 +언급했듯 스테이트풀셋의 파드는 끈끈하고 고유한 정체성을 가진다. +이 정체성은 스테이트풀 컨트롤러에서 각 파드에 주어지는 +고유한 순번에 기인한다. 파드의 이름의 형식은 +`<스테이트풀셋 이름>-<순번>` 이다. 앞서 `web` 스테이트풀셋은 +2개의 레플리카를 가졌으므로 `web-0` 과 `web-1` 2개 파드를 생성한다. + +### 안정적인 네트워크 신원 사용하기 + +각 파드는 각 순번에 따른 안정적인 호스트네임을 갖는다. 각 파드에서 +`hostname` 명령어를 실행하도록 +[`kubectl exec`](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 이용하자. + +```shell +for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done +web-0 +web-1 +``` + +`dnsutils` 패키지에서 `nslookup` 명령을 제공하는 컨테이너를 +실행하도록 [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run)을 이용하자. +파드의 호스트네임에 `nslookup`을 이용하면 클러스터 내부 DNS 주소를 +확인할 수 있다. + +```shell +kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh +nslookup web-0.nginx +Server: 10.0.0.10 +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: web-0.nginx +Address 1: 10.244.1.6 + +nslookup web-1.nginx +Server: 10.0.0.10 +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: web-1.nginx +Address 1: 10.244.2.6 +``` + +헤드리스 서비스의 CNAME은 SRV 레코드를 지칭한다 +(Running과 Ready 상태의 각 파드마다 1개). +SRV 레코드는 파드의 IP 주소를 포함한 A 레코드 엔트리를 지칭한다. + +첫째 터미널에서 스테이트풀셋의 파드를 가져오자. + +```shell +kubectl get pod -w -l app=nginx +``` +두번째 터미널에서 스테이트풀셋 내에 파드를 모두 삭제하기위해 +[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete)를 +이용하자. + +```shell +kubectl delete pod -l app=nginx +pod "web-0" deleted +pod "web-1" deleted +``` + +스테이트풀셋이 재시작되고 두 파드가 Running과 Ready 상태로 +전환되도록 기다리자. + +```shell +kubectl get pod -w -l app=nginx +NAME READY STATUS RESTARTS AGE +web-0 0/1 ContainerCreating 0 0s +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 2s +web-1 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-1 0/1 ContainerCreating 0 0s +web-1 1/1 Running 0 34s +``` + +파드의 호스트네임과 클러스터 내부 DNS 엔트리를 보기 위해 +`kubectl exec`과 `kubectl run`을 이용하자. + +```shell +for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done +web-0 +web-1 + +kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh +nslookup web-0.nginx +Server: 10.0.0.10 +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: web-0.nginx +Address 1: 10.244.1.7 + +nslookup web-1.nginx +Server: 10.0.0.10 +Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local + +Name: web-1.nginx +Address 1: 10.244.2.8 +``` + +파드의 순번, 호스트네임, SRV 레코드와 A 레코드이름은 변경되지 않지만 +파드의 IP 주소는 변경될 수 있다. 이는 튜토리얼에서 사용하는 클러스터나 +다른 클러스터에도 동일하다. 따라서 다른 애플리케이션이 IP 주소로 +스테이트풀셋의 파드에 접속하지 않도록 하는 것이 중요하다. + + +스테이트풀셋의 활성 맴버를 찾아 연결할 경우 +헤드리스 서비스(`nginx.default.svc.cluster.local`)의 CNAME을 쿼리해야 한다. +CNAME과 연관된 SRV 레코드는 스테이트풀셋의 +Running과 Ready 상태의 모든 파드들을 +담고 있다. + +애플리케이션에서 이미 활성상태(liveness)와 준비성(readiness) 테스트하는 +연결 로직을 구현되어 있다면 +파드`web-0.nginx.default.svc.cluster.local`, +`web-1.nginx.default.svc.cluster.local`)의 SRV레코드를 안정적으로 사용할 수 있어 +애플리케이션은 파드가 Running과 Ready 상태로 전환할 때 +파드의 주소를 검색할 수 있다. + +### 안정적인 스토리지에 쓰기 {#writing-to-stable-storage} + +`web-0`과 `web-1`에 대해 퍼시스턴트볼륨클레임(PersistentVolumeClaim)을 가져오자. + +```shell +kubectl get pvc -l app=nginx +NAME STATUS VOLUME CAPACITY ACCESSMODES AGE +www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 48s +www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 48s +``` +스테이트풀셋 컨트롤러는 2개의 [퍼시스턴트볼륨](/docs/concepts/storage/persistent-volumes/)에 +묶인 2개의 퍼시스턴트볼륨클레임을 생성했다. 본 튜토리얼에서 사용되는 클러스터는 퍼시스턴트볼륨을 동적으로 +프로비저닝하도록 설정되었으므로 생성된 퍼시스턴트볼륨도 자동으로 묶인다. + +NGINX 웹서버는 기본 색인 파일로 +`/usr/share/nginx/html/index.html`을 이용합니다. +스테이트풀셋 `spec`내의 `volumeMounts` 필드는 `/usr/share/nginx/html` 디렉터리가 +퍼시스턴트볼륨으로 제공되는지 보증합니다. + +파드의 호스트네임을 `index.html` 파일에 작성하고 +NGINX 웹서버가 해당 호스트네임을 제공하는지 확인해보자. + +```shell +for i in 0 1; do kubectl exec web-$i -- sh -c 'echo $(hostname) > /usr/share/nginx/html/index.html'; done + +for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done +web-0 +web-1 +``` + +{{< note >}} +위에 curl 명령어로 403 Forbidden 아닌 응답을 보려면 +`volumeMounts`로 마운트된 디렉터리의 퍼미션을 수정해야 한다 +([hostPath 볼륨을 사용할 때에 버그](https://github.com/kubernetes/kubernetes/issues/2630)로 인함). + +```shell +for i in 0 1; do kubectl exec web-$i -- chmod 755 /usr/share/nginx/html; done +``` + +위에 curl 명령을 재시도하기 전에 +{{< /note >}} + +첫째 터미널에서 스테이트풀셋의 파드를 감시하자. + +```shell +kubectl get pod -w -l app=nginx +``` + +두번째 터미널에서 스테이트풀셋의 모든 파드를 삭제하자. + +```shell +kubectl delete pod -l app=nginx +pod "web-0" deleted +pod "web-1" deleted +``` +첫번째 터미널에서 실행 중인 `kubectl get`명령어의 출력을 확인하고, +모든 파드가 Running과 Ready 상태로 전환될때까지 기다리자. + +```shell +kubectl get pod -w -l app=nginx +NAME READY STATUS RESTARTS AGE +web-0 0/1 ContainerCreating 0 0s +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 2s +web-1 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-1 0/1 ContainerCreating 0 0s +web-1 1/1 Running 0 34s +``` + +웹서버에서 자신의 호스트네임을 계속 제공하는지 확인하자. + +``` +for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done +web-0 +web-1 +``` + +비록 `web-0`과 `web-1`이 재스케줄링되어도 계속해서 +자신의 호스트네임을 제공하는데 이는 각 퍼시스턴트볼륨클레임에 +연관된 퍼시스턴트볼륨이 해당 `volumeMounts`로 재마운트되기 때문이다. +`web-0`과 `web-1`의 스케줄링에 관계없이 +각각의 퍼시스턴트볼륨은 적절하게 마운트된다. + +## 스테이트풀셋 스케일링 +스테이트풀셋을 스케일링하는 것은 레플리카 개수를 늘리거나 줄이는 것을 의미한다. 이것은 `replicas` 필드를 갱신하여 이뤄진다. +[`kubectl scale`](/docs/reference/generated/kubectl/kubectl-commands/#scale)이나 +[`kubectl patch`](/docs/reference/generated/kubectl/kubectl-commands/#patch)을 +이용해서 스테이트풀셋을 스케일링할 수 있다. + +### 스케일 업 + +터미널창에서 스테이트풀셋의 파드를 감시하자. + +```shell +kubectl get pods -w -l app=nginx +``` + +다른 터미널창에서 `kubectl scale`을 이용하여 레플리카 개수를 +5로 스케일링하자. + +```shell +kubectl scale sts web --replicas=5 +statefulset.apps/web scaled +``` + +첫번째 터미널에서 실행 중인 `kubectl get`명령어의 출력을 확인하고, +3개의 추가 파드가 Running과 Ready 상태로 전환될때까지 기다리자. + +```shell +kubectl get pods -w -l app=nginx +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 2h +web-1 1/1 Running 0 2h +NAME READY STATUS RESTARTS AGE +web-2 0/1 Pending 0 0s +web-2 0/1 Pending 0 0s +web-2 0/1 ContainerCreating 0 0s +web-2 1/1 Running 0 19s +web-3 0/1 Pending 0 0s +web-3 0/1 Pending 0 0s +web-3 0/1 ContainerCreating 0 0s +web-3 1/1 Running 0 18s +web-4 0/1 Pending 0 0s +web-4 0/1 Pending 0 0s +web-4 0/1 ContainerCreating 0 0s +web-4 1/1 Running 0 19s +``` + +스테이트풀셋 컨트롤러는 레플리카개수를 스케일링한다. +[스테이트풀셋 생성](#ordered-pod-creation)으로 스테이트풀셋 컨트롤러는 +각 파드을 순차적으로 각 순번에 따라 생성하고 후속 파드 시작 전에 +이전 파드가 Running과 Ready 상태가 될때까지 +기다린다. + +### 스케일 다운 {#scaling-down} + +터미널에서 스테이트풀셋의 파드를 감시하자. + +```shell +kubectl get pods -w -l app=nginx +``` + +다른 터미널에서 `kubectl patch`으로 스테이트풀셋을 뒤로 + 3개의 레플리카로 스케일링하자. + +```shell +kubectl patch sts web -p '{"spec":{"replicas":3}}' +statefulset.apps/web patched +``` + +`web-4`와 `web-3`이 Terminating으로 전환되기까지 기다리자. + +``` +kubectl get pods -w -l app=nginx +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 3h +web-1 1/1 Running 0 3h +web-2 1/1 Running 0 55s +web-3 1/1 Running 0 36s +web-4 0/1 ContainerCreating 0 18s +NAME READY STATUS RESTARTS AGE +web-4 1/1 Running 0 19s +web-4 1/1 Terminating 0 24s +web-4 1/1 Terminating 0 24s +web-3 1/1 Terminating 0 42s +web-3 1/1 Terminating 0 42s +``` + +### 순차 파드 종료 + +컨트롤러는 순번의 역순으로 한번에 1개 파드를 삭제하고 +다음 파드를 삭제하기 전에 +각각이 완전하게 종료되기까지 기다린다. + +스테이트풀셋의 퍼시스턴트볼륨클레임을 가져오자. + +```shell +kubectl get pvc -l app=nginx +NAME STATUS VOLUME CAPACITY ACCESSMODES AGE +www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 13h +www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 13h +www-web-2 Bound pvc-e1125b27-b508-11e6-932f-42010a800002 1Gi RWO 13h +www-web-3 Bound pvc-e1176df6-b508-11e6-932f-42010a800002 1Gi RWO 13h +www-web-4 Bound pvc-e11bb5f8-b508-11e6-932f-42010a800002 1Gi RWO 13h + +``` + +여전히 5개의 퍼시스턴트볼륨클레임과 5개의 퍼시스턴트볼륨이 있다. +파드의 [안전한 스토리지](#writing-to-stable-storage)를 탐색하면서 스테이트풀셋의 파드가 삭제될 때에 파드에 마운트된 스테이트풀셋의 퍼시스턴트볼륨이 삭제되지 않은 것을 보았다. 스테이트풀셋 스케일 다운으로 파드 삭제할 때에도 여전히 사실이다. + +## 스테이트풀셋 업데이트하기 + +쿠버네티스 1.7 이상에서 스테이트풀셋 컨트롤러는 자동 업데이트를 지원한다. +전략은 스테이트풀셋 API 오브젝트의 `spec.updateStrategy` 필드로 결정된다. +이 기능은 컨테이너 이미지, 스테이트풀셋의 리소스 요청이나 +혹은 한계와 레이블과 파드의 어노테이션을 업그레이드하기 위해 사용될 수 있다. +`RollingUpdate`과 `OnDelete`의 2개의 +유효한 업데이트 전략이 있다. + +`RollingUpdate` 업데이트 전략은 스테이트풀셋에서 기본 값이다. + +### 롤링 업데이트 + +`RollingUpdate` 업데이트 전략은 스테이트풀셋을 보장하면서 스테이트풀셋 내에 파드를 역순으로 업데이트합니다. + +스테이트풀셋 `web`의 업데이트 전략을 `RollingUpdate`으로 패치하자. + +```shell +kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate"}}}' +statefulset.apps/web patched +``` + +터미널 창에서 스테이트풀셋 `web`의 컨테이너 이미지를 바꾸도록 +또 패치하자. + +```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"}]' +statefulset.apps/web patched +``` + +다른 터미널창에서 스테이트풀셋의 파드를 감시하자. + +```shell +kubectl get po -l app=nginx -w +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 7m +web-1 1/1 Running 0 7m +web-2 1/1 Running 0 8m +web-2 1/1 Terminating 0 8m +web-2 1/1 Terminating 0 8m +web-2 0/1 Terminating 0 8m +web-2 0/1 Terminating 0 8m +web-2 0/1 Terminating 0 8m +web-2 0/1 Terminating 0 8m +web-2 0/1 Pending 0 0s +web-2 0/1 Pending 0 0s +web-2 0/1 ContainerCreating 0 0s +web-2 1/1 Running 0 19s +web-1 1/1 Terminating 0 8m +web-1 0/1 Terminating 0 8m +web-1 0/1 Terminating 0 8m +web-1 0/1 Terminating 0 8m +web-1 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-1 0/1 ContainerCreating 0 0s +web-1 1/1 Running 0 6s +web-0 1/1 Terminating 0 7m +web-0 1/1 Terminating 0 7m +web-0 0/1 Terminating 0 7m +web-0 0/1 Terminating 0 7m +web-0 0/1 Terminating 0 7m +web-0 0/1 Terminating 0 7m +web-0 0/1 Pending 0 0s +web-0 0/1 Pending 0 0s +web-0 0/1 ContainerCreating 0 0s +web-0 1/1 Running 0 10s +``` + +스테이트풀셋 내에 파드는 순번의 역순으로 업데이트된다. +이 스테이트풀셋 컨트롤러는 각 파드를 종료시키고 다음 파드를 업데이트하기 전에 +그것이 Running과 Ready 상태로 전환될때까지 기다린다. +알아둘 것은 비록 스테이트풀셋 컨트롤러에서 이전 파드가 Running과 Ready 상태가 되기까지 +다음 파드를 업데이트하지 않아도 현재 버전으로 파드를 업데이트하다 실패하면 복원한다는 것이다. +업데이트를 이미 받은 파드는 업데이트된 버전으로 복원되고 아직 업데이트를 받지 못한 파드는 +이전 버전으로 복원한다. +이런 식으로 컨트롤러는 간헐적인 오류가 발생해도 +애플리케이션을 계속 건강하게 유지하고 +업데이트도 일관되게 유지하려 한다. + +컨테이너 이미지를 살펴보기 위해 파드를 가져오자. + +```shell +for p in 0 1 2; do kubectl get po web-$p --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done +k8s.gcr.io/nginx-slim:0.8 +k8s.gcr.io/nginx-slim:0.8 +k8s.gcr.io/nginx-slim:0.8 + +``` + +스테이트풀셋의 모든 파드가 지금은 이전 컨테이너 이미지를 실행 중이이다. + +**팁** 롤링 업데이트 상황을 살펴보기 위해 `kubectl rollout status sts/` +명령어도 사용할 수 있다. + +#### 단계적으로 업데이트 하기 {#staging-an-update} +`RollingUpdate` 업데이트 전략의 파라미터인 `partition`를 이용하여 +스테이트풀셋의 단계적으로 업데이트할 수 있다. +단계적 업데이트는 스테이트풀셋의 모든 파드를 현재 버전으로 유지하면서 +스테이트풀셋의 `.spec.template`에 변경을 허용한다. + +스테이트풀셋 `web`의 `updateStrategy` 필드에 partition을 추가하자. + +```shell +kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":3}}}}' +statefulset.apps/web patched +``` + +컨테이너의 이미지를 바꾸도록 스테이트풀셋을 또 패치하자. + +```shell +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.apps/web patched +``` + +스테이트풀셋의 파드를 삭제하자. + +```shell +kubectl delete po web-2 +pod "web-2" deleted +``` + +파드가 Running과 Ready 상태가 되기까지 기다리자. + +```shell +kubectl get po -l app=nginx -w +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 4m +web-1 1/1 Running 0 4m +web-2 0/1 ContainerCreating 0 11s +web-2 1/1 Running 0 18s +``` + +파드의 컨테이너를 가져오자. + +```shell +kubectl get po web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +k8s.gcr.io/nginx-slim:0.8 + +``` + +비록 업데이트 전략이 `RollingUpdate`이지만 스테이트풀셋은 +파드를 그것의 원래 컨테이너로 복원한다. +파드의 순번이 `updateStrategy`에서 지정된 +`파티션`보다 작기 때문이다. + +#### 카나리(Canary) 롤링 아웃 +[위에서](#staging-an-update) 지정한 `partition`값을 차감시키면 +변경사항을 테스트하기 위해 카나리 롤아웃을 할 수 있다. + +스테이트풀셋에 partition을 차감하도록 패치하자. + +```shell +kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":2}}}}' +statefulset.apps/web patched +``` + +`web-2` 파드가 Running과 Ready 상태가 되기까지 기다리자. + +```shell +kubectl get po -l app=nginx -w +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 4m +web-1 1/1 Running 0 4m +web-2 0/1 ContainerCreating 0 11s +web-2 1/1 Running 0 18s +``` + +파드의 컨테이너를 가져오자. + +```shell +kubectl get po web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +k8s.gcr.io/nginx-slim:0.7 + +``` + +`partition`을 바꾸면 스테이트풀셋 컨트롤러는 자동으로 +`web-2` 파드를 업데이트하는데 +이는 해당 파드의 순번이 `partition` 이상이기 때문이다. + +`web-1` 파드를 삭제하자. + +```shell +kubectl delete po web-1 +pod "web-1" deleted +``` + +`web-1` 파드가 Running과 Ready 상태가 되기까지 기다리자. + +```shell +kubectl get po -l app=nginx -w +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 6m +web-1 0/1 Terminating 0 6m +web-2 1/1 Running 0 2m +web-1 0/1 Terminating 0 6m +web-1 0/1 Terminating 0 6m +web-1 0/1 Terminating 0 6m +web-1 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-1 0/1 ContainerCreating 0 0s +web-1 1/1 Running 0 18s +``` + +`web-1` 파드의 컨테이너를 가져오자. + +```shell +kubectl get po web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' +k8s.gcr.io/nginx-slim:0.8 + +``` + +`web-1` 는 원래 환경설정으로 복원되었는데 +이는 파드의 순번이 partition보다 작기 때문이다. +스테이트풀셋의 `.spec.template`이 갱신되면, 지정된 partition 이상의 순번을 +가진 모든 파드는 업데이트된다. 미만의 순번을 가진 파드라면 삭제되거나 +종료되어 원래 환경설정으로 복원된다. + +#### 단계적 롤아웃 +[카나리 롤아웃](#rolling-out-a-canary)에서 했던 방법과 비슷하게 +분할된 롤링 업데이트를 이용하여 단계적 롤아웃(e.g. 선형, 기하 또는 지수적 롤아웃)을 +수행할 수 있다. 단계적 롤아웃을 수행하려면 +컨트롤러가 업데이트를 일시 중지할 순번으로 +`partition`를 정하자. + +partition은 현재 `2`이다. partition을 `0`으로 바꾸자. + +```shell +kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":0}}}}' +statefulset.apps/web patched +``` + +스테이트풀셋의 모든 파드가 Running과 Ready 상태가 되기까지 기다리자. + +```shell +kubectl get po -l app=nginx -w +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 3m +web-1 0/1 ContainerCreating 0 11s +web-2 1/1 Running 0 2m +web-1 1/1 Running 0 18s +web-0 1/1 Terminating 0 3m +web-0 1/1 Terminating 0 3m +web-0 0/1 Terminating 0 3m +web-0 0/1 Terminating 0 3m +web-0 0/1 Terminating 0 3m +web-0 0/1 Terminating 0 3m +web-0 0/1 Pending 0 0s +web-0 0/1 Pending 0 0s +web-0 0/1 ContainerCreating 0 0s +web-0 1/1 Running 0 3s +``` + +파드의 컨테이너를 가져오자. + +```shell +for p in 0 1 2; do kubectl get po web-$p --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done +k8s.gcr.io/nginx-slim:0.7 +k8s.gcr.io/nginx-slim:0.7 +k8s.gcr.io/nginx-slim:0.7 + +``` + +`partition`을 `0`으로 이동하여 스테이트풀셋 컨트롤러에서 계속해서 +업데이트 처리를 하도록 허용하였다. + +### 삭제시 동작 + +`OnDelete` 업데이트 전략은 예전 동작(1.6 이하)으로, +이 업데이트 전략을 선택하면 스테이트풀셋 컨트롤러는 스테이트풀셋의 +`.spec.template` 필드에 수정 사항이 발생해도 자동으로 파드를 업데이트하지 않는다. +이 전략은 `.spec.template.updateStrategy.type`을 `OnDelete`로 설정하여 선택할 수 있다. + +## 스테이트풀셋 삭제하기 + +스테이트풀셋은 비종속적(non-cascading), 종속적(cascading) 삭제를 둘 다 지원한다. +비종속적 삭제에서는 스테이트풀셋이 지워질 때에 스테이트풀셋의 파드는 지워지지 않는다. +종속적 삭제에서는 스테이트풀셋과 그에 속한 파드가 모두 지워진다. + +### 비종속적 삭제 + +터미널창에서 스테이트풀셋의 파드를 감시하자. + +``` +kubectl get pods -w -l app=nginx +``` + +다른 터미널에서는 스테이트풀셋을 지우기 위해 +[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) 명령어를 이용하자. +이 명령어에 `--cascade=false` 파라미터가 추가되었다. +이 파라미터는 쿠버네티스에 스테이트풀셋만 삭제하고 그에 속한 파드는 지우지 않도록 요청한다. + +```shell +kubectl delete statefulset web --cascade=false +statefulset.apps "web" deleted +``` + +상태를 확인하기 위해 파드를 가져오자. + +```shell +kubectl get pods -l app=nginx +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 6m +web-1 1/1 Running 0 7m +web-2 1/1 Running 0 5m +``` + +비록 `web`이 삭제되고 있어도, 모든 파드는 여전히 Running과 Ready 상태이다. +`web-0`을 삭제하자. + +```shell +kubectl delete pod web-0 +pod "web-0" deleted +``` + +스테이트풀셋의 파드를 가져오자. + +```shell +kubectl get pods -l app=nginx +NAME READY STATUS RESTARTS AGE +web-1 1/1 Running 0 10m +web-2 1/1 Running 0 7m +``` + +스테이트풀셋 `web`이 삭제되는 동안 `web-0`은 재시작하지 않았다. + +첫째 터미널에서 스테이트풀셋의 파드를 감시하자. + +```shell +kubectl get pods -w -l app=nginx +``` + +두번째 터미널에서 스테이트풀셋을 다시 생성하자. +`nginx` 서비스(가지지 말았어야 하는)를 삭제하기 전까지는 그 서비스가 이미 존재한다는 에러를 +볼 것이라는 것을 명심하자. + +```shell +kubectl create -f web.yaml +statefulset.apps/web created +Error from server (AlreadyExists): error when creating "web.yaml": services "nginx" already exists +``` + +이 에러는 무시하자. 이것은 다만 해당 서비스가 있더라도 +nginx 헤드리스 서비스를 생성하려고 했음을 뜻한다. + +첫째 터미널에서 실행 중인 `kubectl get` 명령어의 출력을 살펴보자. + +```shell +kubectl get pods -w -l app=nginx +NAME READY STATUS RESTARTS AGE +web-1 1/1 Running 0 16m +web-2 1/1 Running 0 2m +NAME READY STATUS RESTARTS AGE +web-0 0/1 Pending 0 0s +web-0 0/1 Pending 0 0s +web-0 0/1 ContainerCreating 0 0s +web-0 1/1 Running 0 18s +web-2 1/1 Terminating 0 3m +web-2 0/1 Terminating 0 3m +web-2 0/1 Terminating 0 3m +web-2 0/1 Terminating 0 3m +``` + +`web` 스테이트풀셋이 다시 생성될때 먼저 `web-0` 시작한다. +`web-1`은 이미 Running과 Ready 상태이므로 `web-0`이 Running과 Ready 상태로 +전환될 때는 단순히 이 파드에 적용됬다. 스테이트풀셋에`replicas`를 2로 하고 +`web-0`을 재생성했다면 `web-1`이 +이미 Running과 Ready 상태이고, +`web-2`은 종료되었을 것이다. + +파드의 웹서버에서 제공한 `index.html` 파일 내용을 +다른 관점으로 살펴보자. + +```shell +for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done +web-0 +web-1 +``` + +스테이트풀셋과 `web-0` 파드를 둘다 삭제했으나 여전히 `index.html` 파일에 입력했던 +원래 호스트네임을 제공한다. 스테이트풀셋은 +파드에 할당된 퍼시스턴트볼륨을 결코 삭제하지 않기때문이다. +다시 스테이트풀셋을 생성하면 `web-0`을 시작하며 +원래 퍼시스턴트볼륨을 다시 마운트한다. + +### 단계식 삭제 + +터미널창에서 스테이트풀셋의 파드를 감시하자. + +```shell +kubectl get pods -w -l app=nginx +``` + +다른 터미널창에서 스테이트풀셋을 다시 지우자. 이번에는 +`--cascade=false` 파라미터를 생략하자. + +```shell +kubectl delete statefulset web +statefulset.apps "web" deleted +``` +첫째 터미널에서 실행 중인 `kubectl get` 명령어의 출력을 살펴보고 +모든 파드가 Terminating 상태로 전환될때까지 기다리자. + +```shell +kubectl get pods -w -l app=nginx +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 11m +web-1 1/1 Running 0 27m +NAME READY STATUS RESTARTS AGE +web-0 1/1 Terminating 0 12m +web-1 1/1 Terminating 0 29m +web-0 0/1 Terminating 0 12m +web-0 0/1 Terminating 0 12m +web-0 0/1 Terminating 0 12m +web-1 0/1 Terminating 0 29m +web-1 0/1 Terminating 0 29m +web-1 0/1 Terminating 0 29m + +``` + +[스케일 다운](#scaling-down) 섹션에서 보았듯 파드는 +각 순번의 역순으로 하나씩 종료된다. 파드가 종료될 때 +스테이트풀 컨트롤러는 이전 파드가 +완전히 종료되기까지 기다린다. + +스테이트풀셋과 그 파드를 종속적으로 삭제하는 중에 연관된 헤드리스 서비스를 +삭제하지 않음을 주의하자. +꼭 `nginx` 서비스를 수동으로 삭제해라. + +```shell +kubectl delete service nginx +service "nginx" deleted +``` + +스테이트풀셋과 헤드리스 서비스를 한번 더 다시 생성하자. + +```shell +kubectl create -f web.yaml +service/nginx created +statefulset.apps/web created +``` + +스테이트풀셋의 모든 파드가 Running과 Ready 상태로 전환될 때 +`index.html` 파일 내용을 검색하자. + +```shell +for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done +web-0 +web-1 +``` + +스테이트풀셋과 그 내부의 모든 파드를 삭제했지만 퍼시스턴트볼륨이 마운트된 채로 +다시 생성되고 `web-0`과 `web-1`은 여전히 +각 호스트네임을 제공한다. + +최종적으로 `web` 스테이트풀셋과`nginx` 서비스를 삭제한다. + +```shell +kubectl delete service nginx +service "nginx" deleted + +kubectl delete statefulset web +statefulset "web" deleted +``` + +## 파드 관리 정책 + +일부 분산 시스템의 경우 스테이트풀셋의 순서 보증은 +불필요하거나 바람직하지 않다. 이러한 시스템은 고유성과 신원만 필요하다. +이를 해결하기 위해 쿠버네티스 1.7에서 `.spec.podManagementPolicy`를 +스테이트풀셋 API 오브젝트에 도입했다. + +### OrderedReady 파드 관리 + +`OrderedReady` 파드 관리는 스테이트풀셋에서는 기본이다. +이는 스테이트풀셋 컨트롤러가 지금까지 위에서 설명했던 순서를 +보증함을 뜻한다. + +### Parallel 파드 관리 + +`Parallel` 파드 관리는 스테이트풀셋 컨트롤러가 모든 파드를 +병렬로 시작하고 종료하는 것으로 다른 파드를 시작/종료하기 전에 +파드가 Running과 Ready 상태로 전환되거나 완전히 종료되기까지 +기다리지 않음을 뜻한다. + +{{< codenew file="application/web/web-parallel.yaml" >}} + +상기 예제를 다운로드받아 파일 이름을 `web-parallel.yaml`로 저장하자. + +이 매니페스트는 `web` 스테이트풀셋의 `.spec.podManagementPolicy`이 +`Parallel`인 것 말고는 이전에 다운로드 받았던 것과 동일하다. + +터미널에서 스테이트풀셋의 파드를 감시하자. + +```shell +kubectl get po -l app=nginx -w +``` + +다른 터미널에서 매니페스트 안에 스테이트풀셋과 서비스를 생성하자. + +```shell +kubectl create -f web-parallel.yaml +service/nginx created +statefulset.apps/web created +``` + +첫째 터미널에서 실행했던 `kubectl get` 명령어의 출력을 살펴보자. + +```shell +kubectl get po -l app=nginx -w +NAME READY STATUS RESTARTS AGE +web-0 0/1 Pending 0 0s +web-0 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-0 0/1 ContainerCreating 0 0s +web-1 0/1 ContainerCreating 0 0s +web-0 1/1 Running 0 10s +web-1 1/1 Running 0 10s +``` + +스테이트풀셋 컨트롤러는 `web-0`와 `web-1`를 둘다 동시에 시작했다. + +두번째 터미널을 열어 놓고 다른 터미널창에서 스테이트풀셋을 +스케일링 하자. + +```shell +kubectl scale statefulset/web --replicas=4 +statefulset.apps/web scaled +``` + +`kubectl get` 명령어를 실행 중인 터미널의 출력을 살펴보자. + +```shell +web-3 0/1 Pending 0 0s +web-3 0/1 Pending 0 0s +web-3 0/1 Pending 0 7s +web-3 0/1 ContainerCreating 0 7s +web-2 1/1 Running 0 10s +web-3 1/1 Running 0 26s +``` + + +스테이트풀 컨트롤러는 두개의 새 파드를 시작하였다. +두번째 것을 런칭하기 위해 먼저 런칭한 것이 Running과 Ready 상태가 될 떄까지 기다리지 않는다. + +이 터미널을 열어 놓고 다른 터미널에서 `web` 스테이트풀셋을 삭제하자. + +```shell +kubectl delete sts web +``` + +다시 한번 다른 터미널에서 실행 중인 `kubectl get`명령의 출력을 확인해보자. + +```shell +web-3 1/1 Terminating 0 9m +web-2 1/1 Terminating 0 9m +web-3 1/1 Terminating 0 9m +web-2 1/1 Terminating 0 9m +web-1 1/1 Terminating 0 44m +web-0 1/1 Terminating 0 44m +web-0 0/1 Terminating 0 44m +web-3 0/1 Terminating 0 9m +web-2 0/1 Terminating 0 9m +web-1 0/1 Terminating 0 44m +web-0 0/1 Terminating 0 44m +web-2 0/1 Terminating 0 9m +web-2 0/1 Terminating 0 9m +web-2 0/1 Terminating 0 9m +web-1 0/1 Terminating 0 44m +web-1 0/1 Terminating 0 44m +web-1 0/1 Terminating 0 44m +web-0 0/1 Terminating 0 44m +web-0 0/1 Terminating 0 44m +web-0 0/1 Terminating 0 44m +web-3 0/1 Terminating 0 9m +web-3 0/1 Terminating 0 9m +web-3 0/1 Terminating 0 9m +``` + +스테이트풀 컨트롤러는 모든 파드를 동시에 삭제한다. 파드를 삭제하기 전에 +그 파드의 순서상 후계자를 기다리지 않는다. + +`kubectl get` 명령어가 실행된 터미널을 닫고 +`nginx` 서비스를 삭제하자. + +```shell +kubectl delete svc nginx +``` +{{% /capture %}} + +{{% capture cleanup %}} +이 튜토리얼에서 사용된 퍼시턴트볼륨을 위한 +퍼시스턴트 스토리지 미디어를 삭제해야 한다. +모든 스토리지를 반환하도록 환경, 스토리지 설정과 +프로비저닝 방법에 따른 단계를 따르자. +{{% /capture %}} + + diff --git a/content/ko/docs/tutorials/stateless-application/guestbook.md b/content/ko/docs/tutorials/stateless-application/guestbook.md index e185446172..914f3a9607 100644 --- a/content/ko/docs/tutorials/stateless-application/guestbook.md +++ b/content/ko/docs/tutorials/stateless-application/guestbook.md @@ -2,6 +2,10 @@ title: "예시: Redis를 사용한 PHP 방명록 애플리케이션 배포하기" content_template: templates/tutorial weight: 20 +card: + name: tutorials + weight: 30 + title: "상태를 유지하지 않는 예제: Redis를 사용한 PHP 방명록" --- {{% capture overview %}} diff --git a/content/ko/examples/application/web/web-parallel.yaml b/content/ko/examples/application/web/web-parallel.yaml new file mode 100644 index 0000000000..4eab2dc206 --- /dev/null +++ b/content/ko/examples/application/web/web-parallel.yaml @@ -0,0 +1,47 @@ +apiVersion: v1 +kind: Service +metadata: + name: nginx + labels: + app: nginx +spec: + ports: + - port: 80 + name: web + clusterIP: None + selector: + app: nginx +--- +apiVersion: apps/v1 +kind: StatefulSet +metadata: + name: web +spec: + serviceName: "nginx" + podManagementPolicy: "Parallel" + replicas: 2 + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: k8s.gcr.io/nginx-slim:0.8 + ports: + - containerPort: 80 + name: web + volumeMounts: + - name: www + mountPath: /usr/share/nginx/html + volumeClaimTemplates: + - metadata: + name: www + spec: + accessModes: [ "ReadWriteOnce" ] + resources: + requests: + storage: 1Gi diff --git a/content/ko/examples/application/web/web.yaml b/content/ko/examples/application/web/web.yaml new file mode 100644 index 0000000000..37c1fabf9c --- /dev/null +++ b/content/ko/examples/application/web/web.yaml @@ -0,0 +1,47 @@ +apiVersion: v1 +kind: Service +metadata: + name: nginx + labels: + app: nginx +spec: + ports: + - port: 80 + name: web + clusterIP: None + selector: + app: nginx +--- +apiVersion: apps/v1 +kind: StatefulSet +metadata: + name: web +spec: + serviceName: "nginx" + replicas: 2 + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: k8s.gcr.io/nginx-slim:0.8 + ports: + - containerPort: 80 + name: web + volumeMounts: + - name: www + mountPath: /usr/share/nginx/html + volumeClaimTemplates: + - metadata: + name: www + spec: + accessModes: [ "ReadWriteOnce" ] + resources: + requests: + storage: 1Gi + diff --git a/content/ko/includes/federation-current-state.md b/content/ko/includes/federation-current-state.md new file mode 100644 index 0000000000..4ba85405e5 --- /dev/null +++ b/content/ko/includes/federation-current-state.md @@ -0,0 +1 @@ +쿠버네티스 API 리소스를 '있는 그대로' 재사용하는 현재의 쿠버네티스 페더레이션 API `Federation V1`는 많은 특징에 의해서 알파 상태로 여겨지고 있다. 페더레이션 API를 GA 단계로 진화시키는데 명확한 길은 없지만, 쿠버네티스 API와 별도로 페더레이션 전용 API를 구현하기 위한 `Federation V2`에 대한 노력이 진행 중이다. 자세한 사항은 [sig-multicluster 커뮤니티 페이지](https://github.com/kubernetes/community/tree/master/sig-multicluster)에서 확인할 수 있다. diff --git a/content/zh/docs/concepts/_index.md b/content/zh/docs/concepts/_index.md index dae8d1bb9c..6059a0544e 100644 --- a/content/zh/docs/concepts/_index.md +++ b/content/zh/docs/concepts/_index.md @@ -28,7 +28,7 @@ weight: 40 -要使用 Kubernetes，你需要用 *Kubernetes API 对象*来描述集群的*预期状态（desired state）*：包括你需要运行的应用或者负载，它们使用的镜像、副本数，以及所需网络和磁盘资源等等。你可以使用命令行工具 `kubectl` 来调用 Kubernetes API 创建对象，通过所创建的这些对象来配置预期状态。你也可以直接调用 Kubernetes API 和集群进行交互，设置或者修改预期状态。 +要使用 Kubernetes，你需要用 *Kubernetes API 对象* 来描述集群的*预期状态（desired state）* ：包括你需要运行的应用或者负载，它们使用的镜像、副本数，以及所需网络和磁盘资源等等。你可以使用命令行工具 `kubectl` 来调用 Kubernetes API 创建对象，通过所创建的这些对象来配置预期状态。你也可以直接调用 Kubernetes API 和集群进行交互，设置或者修改预期状态。 @@ -63,7 +63,7 @@ Kubernetes 包含若干抽象用来表示系统状态，包括：已部署的容 -另外，Kubernetes 包含大量的被称作*控制器（controllers）*的高级抽象。控制器基于基本对象构建并提供额外的功能和方便使用的特性。具体包括： +另外，Kubernetes 包含大量的被称作*控制器（controllers）* 的高级抽象。控制器基于基本对象构建并提供额外的功能和方便使用的特性。具体包括： * [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) * [Deployment](/docs/concepts/workloads/controllers/deployment/) diff --git a/content/zh/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/zh/docs/concepts/cluster-administration/cluster-administration-overview.md index d21cc0bb1b..49c30bb7ce 100644 --- a/content/zh/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/content/zh/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -17,7 +17,7 @@ content_template: templates/concept ## 规划集群 -查阅 [选择正确解决方案](/docs/setup/pick-right-solution/) 中的指导，获取如何规划、建立以及配置 Kubernetes 集群的示例。本文所列的文章称为*发行版*。 +查阅 [选择正确解决方案](/docs/setup/pick-right-solution/) 中的指导，获取如何规划、建立以及配置 Kubernetes 集群的示例。本文所列的文章称为*发行版* 。 在选择一个指南前，有一些因素需要考虑： diff --git a/content/zh/docs/concepts/configuration/manage-compute-resources-container.md b/content/zh/docs/concepts/configuration/manage-compute-resources-container.md index 78ddbf153c..0d798d058b 100644 --- a/content/zh/docs/concepts/configuration/manage-compute-resources-container.md +++ b/content/zh/docs/concepts/configuration/manage-compute-resources-container.md @@ -14,9 +14,9 @@ content_template: templates/concept ## 资源类型 -*CPU* 和 *内存* 都是 *资源类型*。资源类型具有基本单位。CPU 的单位是 core，内存的单位是 byte。 +*CPU* 和 *内存* 都是 *资源类型* 。资源类型具有基本单位。CPU 的单位是 core，内存的单位是 byte。 -CPU和内存统称为*计算资源*，也可以称为*资源*。计算资源的数量是可以被请求、分配、消耗和可测量的。它们与 [API 资源](/docs/api/) 不同。 API 资源（如 Pod 和 [Service](/docs/user-guide/services)）是可通过 Kubernetes API server 读取和修改的对象。 +CPU和内存统称为*计算资源* ，也可以称为*资源* 。计算资源的数量是可以被请求、分配、消耗和可测量的。它们与 [API 资源](/docs/api/) 不同。 API 资源（如 Pod 和 [Service](/docs/user-guide/services)）是可通过 Kubernetes API server 读取和修改的对象。 ## Pod 和 容器的资源请求和限制 @@ -226,7 +226,7 @@ Kubernetes 1.5 版本中引入不透明整型资源。不透明的整数资源 **注意：** 不透明整型资源在 kubernetes 1.5 中还是 Alpha 版本。只实现了资源计量，节点级别的隔离还处于积极的开发阶段。 -不透明整型资源是以 `pod.alpha.kubernetes.io/opaque-int-resource-` 为前缀的资源。API server 将限制这些资源的数量为整数。*有效* 数量的例子有 `3`、`3000m` 和 `3Ki`。*无效*数量的例子有 `0.5` 和 `1500m`。 +不透明整型资源是以 `pod.alpha.kubernetes.io/opaque-int-resource-` 为前缀的资源。API server 将限制这些资源的数量为整数。*有效* 数量的例子有 `3`、`3000m` 和 `3Ki`。*无效* 数量的例子有 `0.5` 和 `1500m`。 申请使用不透明整型资源需要两步。首先，集群运维人员必须在一个或多个节点上通告每个节点不透明的资源。然后，用户必须在 Pod 中请求不透明资源。 diff --git a/content/zh/docs/concepts/containers/container-environment-variables.md b/content/zh/docs/concepts/containers/container-environment-variables.md index 6b1c49f3a2..6b84845df1 100644 --- a/content/zh/docs/concepts/containers/container-environment-variables.md +++ b/content/zh/docs/concepts/containers/container-environment-variables.md @@ -40,7 +40,7 @@ Pod 名称和名字空间可以通过 容器创建时运行的所有服务的列表都会作为环境变量提供给容器。 这些环境变量与 Docker 链接语法相匹配。 -对一个名为 *foo*，映射到名为 *bar* 的容器端口的服务， +对一个名为 *foo* ，映射到名为 *bar* 的容器端口的服务， 会定义如下变量： ```shell diff --git a/content/zh/docs/concepts/overview/what-is-kubernetes.md b/content/zh/docs/concepts/overview/what-is-kubernetes.md index fd5a6cb493..58c4aad000 100644 --- a/content/zh/docs/concepts/overview/what-is-kubernetes.md +++ b/content/zh/docs/concepts/overview/what-is-kubernetes.md @@ -107,7 +107,7 @@ Kubernetes 不是一个传统意义上，包罗万象的 PaaS (平台即服务) * Kubernetes 不提供或授权一个全面的应用程序配置语言/系统 (例如 [jsonnet](https://github.com/google/jsonnet)). * Kubernetes 不提供也不采用任何全面机器配置、保养、管理或自我修复系统 -另一方面，许多 PaaS 系统*运行*在 Kubernetes 上面，例如 [Openshift](https://github.com/openshift/origin), [Deis](http://deis.io/), and [Eldarion](http://eldarion.cloud/)。 您也可以自定义您自己的 PaaS, 与您选择的 CI 系统集成，或与 Kubernetes 一起使用: 将您的容器镜像部署到 Kubernetes。 +另一方面，许多 PaaS 系统*运行* 在 Kubernetes 上面，例如 [Openshift](https://github.com/openshift/origin), [Deis](http://deis.io/), and [Eldarion](http://eldarion.cloud/)。 您也可以自定义您自己的 PaaS, 与您选择的 CI 系统集成，或与 Kubernetes 一起使用: 将您的容器镜像部署到 Kubernetes。 由于 Kubernetes 在应用级别而不仅仅在硬件级别上运行，因此它提供 PaaS 产品通用的一些功能，例如部署、扩展、负载均衡、日志记录、监控等。但是，Kubernetes 不是单一的，默认解决方案是可选和可插拔的。 diff --git a/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md index c9b1af5917..d5d6f84df7 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -36,9 +36,9 @@ Kubernetes 对象是 “目标性记录” —— 一旦创建对象，Kubernete ### 对象规约（Spec）与状态（Status） -每个 Kubernetes 对象包含两个嵌套的对象字段，它们负责管理对象的配置：对象 *spec* 和 对象 *status*。 +每个 Kubernetes 对象包含两个嵌套的对象字段，它们负责管理对象的配置：对象 *spec* 和 对象 *status* 。 *spec* 是必需的，它描述了对象的 *期望状态（Desired State）* —— 希望对象所具有的特征。 -*status* 描述了对象的 *实际状态（Actual State）*，它是由 Kubernetes 系统提供和更新的。在任何时刻，Kubernetes 控制面一直努力地管理着对象的实际状态以与期望状态相匹配。 +*status* 描述了对象的 *实际状态（Actual State）* ，它是由 Kubernetes 系统提供和更新的。在任何时刻，Kubernetes 控制面一直努力地管理着对象的实际状态以与期望状态相匹配。 diff --git a/content/zh/docs/concepts/policy/pod-security-policy.md b/content/zh/docs/concepts/policy/pod-security-policy.md index 8932a23c8a..48c8de8fa8 100644 --- a/content/zh/docs/concepts/policy/pod-security-policy.md +++ b/content/zh/docs/concepts/policy/pod-security-policy.md @@ -46,9 +46,9 @@ _Pod 安全策略_ 是集群级别的资源，它能够控制 Pod 运行的行 _Pod 安全策略_ 由设置和策略组成，它们能够控制 Pod 访问的安全特征。这些设置分为如下三类： -- *基于布尔值控制*：这种类型的字段默认为最严格限制的值。 -- *基于被允许的值集合控制*：这种类型的字段会与这组值进行对比，以确认值被允许。 -- *基于策略控制*：设置项通过一种策略提供的机制来生成该值，这种机制能够确保指定的值落在被允许的这组值中。 +- *基于布尔值控制* ：这种类型的字段默认为最严格限制的值。 +- *基于被允许的值集合控制* ：这种类型的字段会与这组值进行对比，以确认值被允许。 +- *基于策略控制* ：设置项通过一种策略提供的机制来生成该值，这种机制能够确保指定的值落在被允许的这组值中。 @@ -122,7 +122,7 @@ _Pod 安全策略_ 由设置和策略组成，它们能够控制 Pod 访问的 ### 主机网络 - - *HostPorts*， 默认为 `empty`。`HostPortRange` 列表通过 `min`(包含) and `max`(包含) 来定义，指定了被允许的主机端口。 + - *HostPorts* ， 默认为 `empty`。`HostPortRange` 列表通过 `min`(包含) and `max`(包含) 来定义，指定了被允许的主机端口。 ### 允许的主机路径 - *AllowedHostPaths* 是一个被允许的主机路径前缀的白名单。空值表示所有的主机路径都可以使用。 diff --git a/content/zh/docs/concepts/workloads/controllers/garbage-collection.md b/content/zh/docs/concepts/workloads/controllers/garbage-collection.md index a25ae71064..0aa305a6e7 100644 --- a/content/zh/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/zh/docs/concepts/workloads/controllers/garbage-collection.md @@ -26,7 +26,7 @@ Kubernetes 垃圾收集器的角色是删除指定的对象，这些对象曾经 ## Owner 和 Dependent 某些 Kubernetes 对象是其它一些对象的 Owner。例如，一个 ReplicaSet 是一组 Pod 的 Owner。 -具有 Owner 的对象被称为是 Owner 的 *Dependent*。 +具有 Owner 的对象被称为是 Owner 的 *Dependent* 。 每个 Dependent 对象具有一个指向其所属对象的 `metadata.ownerReferences` 字段。 有时，Kubernetes 会自动设置 `ownerReference` 的值。 @@ -73,10 +73,10 @@ metadata: ## 控制垃圾收集器删除 Dependent 当删除对象时，可以指定是否该对象的 Dependent 也自动删除掉。 -自动删除 Dependent 也称为 *级联删除*。 +自动删除 Dependent 也称为 *级联删除* 。 Kubernetes 中有两种 *级联删除* 的模式：*background* 模式和 *foreground* 模式。 -如果删除对象时，不自动删除它的 Dependent，这些 Dependent 被称作是原对象的 *孤儿*。 +如果删除对象时，不自动删除它的 Dependent，这些 Dependent 被称作是原对象的 *孤儿* 。 diff --git a/content/zh/docs/concepts/workloads/pods/init-containers.md b/content/zh/docs/concepts/workloads/pods/init-containers.md index 3b809a78da..9645097d43 100644 --- a/content/zh/docs/concepts/workloads/pods/init-containers.md +++ b/content/zh/docs/concepts/workloads/pods/init-containers.md @@ -18,7 +18,7 @@ content_template: templates/concept {{< toc >}} -这个特性在 1.6 版本已经退出 beta 版本。Init 容器可以在 PodSpec 中同应用的 `containers` 数组一起来指定。 +这个特性在 1.6 版本已经退出 beta 版本。Init 容器可以在 PodSpec 中有效 QoS 层同应用的 `containers` 数组一起来指定。 beta 注解的值将仍然需要保留，并覆盖 PodSpec 字段值。 {{% capture body %}} @@ -291,7 +291,7 @@ Init 容器具有应用容器的所有字段。 * 所有应用容器对某个资源的请求/限制之和 * 对某个资源的有效初始请求/限制 * 基于有效请求/限制完成调度，这意味着 Init 容器能够为初始化预留资源，这些资源在 Pod 生命周期过程中并没有被使用。 -* Pod 的 *有效 QoS 层*，是 Init 容器和应用容器相同的 QoS 层。 +* Pod 的 *有效 QoS 层* ，是 Init 容器和应用容器相同的 QoS 层。 diff --git a/content/zh/docs/concepts/workloads/pods/pod-lifecycle.md b/content/zh/docs/concepts/workloads/pods/pod-lifecycle.md index f5e6db4b40..afbe139e2e 100644 --- a/content/zh/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/zh/docs/concepts/workloads/pods/pod-lifecycle.md @@ -98,6 +98,13 @@ PodSpec 中有一个 `restartPolicy` 字段，可能的值为 Always、OnFailure 存活探针由 kubelet 来执行，因此所有的请求都在 kubelet 的网络命名空间中进行。 + + ```yaml apiVersion: v1 kind: Pod @@ -112,9 +119,9 @@ spec: image: k8s.gcr.io/liveness livenessProbe: httpGet: - # when "host" is not defined, "PodIP" will be used + # 当没有定义 "host" 时，使用 "PodIP" # host: my-host - # when "scheme" is not defined, "HTTP" scheme will be used. Only "HTTP" and "HTTPS" are allowed + # 当没有定义 "scheme" 时，使用 "HTTP" scheme 只允许 "HTTP" 和 "HTTPS" # scheme: HTTPS path: /healthz port: 8080 diff --git a/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md b/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md index 81a6b1b356..025b91b9bb 100644 --- a/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/zh/docs/tutorials/stateful-application/basic-stateful-set.md @@ -6,7 +6,7 @@ approvers: - janetkuo - kow3ns - smarterclayton -title: StatefulSet基本使用 +title: StatefulSet 基本使用 content_template: templates/tutorial --- @@ -20,7 +20,7 @@ content_template: templates/tutorial 在开始本教程之前，你应该熟悉以下 Kubernetes 的概念： * [Pods](/docs/user-guide/pods/single-container/) -* [Cluster DNS](/docs/concepts/services-networking/dns-pod-service/) +* [集群 DNS](/docs/concepts/services-networking/dns-pod-service/) * [Headless Services](/docs/concepts/services-networking/service/#headless-services) * [PersistentVolumes](/docs/concepts/storage/volumes/) * [PersistentVolume Provisioning](http://releases.k8s.io/{{< param "githubbranch" >}}/examples/persistent-volume-provisioning/) @@ -46,10 +46,10 @@ StatefulSets 旨在与有状态的应用及分布式系统一起使用。然而 {{% capture lessoncontent %}} -##创建 StatefulSet +## 创建 StatefulSet -作为开始，使用如下示例创建一个 StatefulSet。它和 [StatefulSets](/docs/concepts/abstractions/controllers/statefulsets/) 概念中的示例相似。它创建了一个 [Headless Service](/docs/user-guide/services/#headless-services) `nginx` 用来发布StatefulSet `web` 中的 Pod 的 IP 地址。 +作为开始，使用如下示例创建一个 StatefulSet。它和 [StatefulSets](/docs/concepts/abstractions/controllers/statefulsets/) 概念中的示例相似。它创建了一个 [Headless Service](/docs/user-guide/services/#headless-services) `nginx` 用来发布 StatefulSet `web` 中的 Pod 的 IP 地址。 {{< code file="web.yaml" >}} @@ -131,7 +131,7 @@ web-1 1/1 Running 0 1m ``` -如同 [StatefulSets](/docs/concepts/abstractions/controllers/statefulsets/) 概念中所提到的， StatefulSet 中的 Pod 拥有一个具有黏性的、独一无二的身份标志。这个标志基于 StatefulSet 控制器分配给每个 Pod 的唯一顺序索引。 Pod 的名称的形式为`-`。`web` StatefulSet 拥有两个副本，所以它创建了两个 Pod：`web-0`和`web-1`。 +如同 [StatefulSets](/docs/concepts/abstractions/controllers/statefulsets/) 概念中所提到的， StatefulSet 中的 Pod 拥有一个具有黏性的、独一无二的身份标志。这个标志基于 StatefulSet 控制器分配给每个 Pod 的唯一顺序索引。 Pod 的名称的形式为 `-`。`web` StatefulSet 拥有两个副本，所以它创建了两个 Pod：`web-0` 和 `web-1`。 ### 使用稳定的网络身份标识 @@ -451,6 +451,7 @@ pod "web-0" deleted <-- Watch the `web-0` Pod, and wait for it to transition to Running and Ready. --> + 观察 `web-0` Pod， 等待它变成 Running 和 Ready。 ```shell @@ -477,8 +478,11 @@ web-1 k8s.gcr.io/nginx-slim:0.8 web-2 k8s.gcr.io/nginx-slim:0.8 ``` + +`web-0` 已经更新了它的镜像，但是 `web-1` 和 `web-2` 仍保留了原始镜像。 ​```shell kubectl delete pod web-1 web-2 diff --git a/layouts/blog/baseof.html b/layouts/blog/baseof.html index fe8919e95c..83d439810d 100644 --- a/layouts/blog/baseof.html +++ b/layouts/blog/baseof.html @@ -22,6 +22,7 @@ RSS Feed {{ end -}} + Submit a Post @Kubernetesio View on Github #kubernetes-users diff --git a/sass/_tablet.sass b/sass/_tablet.sass index d37d515384..4434ed5b82 100644 --- a/sass/_tablet.sass +++ b/sass/_tablet.sass @@ -205,10 +205,8 @@ $feature-box-div-width: 45% margin-left: 20px div:nth-child(3) - margin-top: 20px div:nth-child(4) - margin-top: 20px margin-left: 20px a diff --git a/scripts/test_examples.sh b/scripts/test_examples.sh new file mode 100644 index 0000000000..9938477871 --- /dev/null +++ b/scripts/test_examples.sh @@ -0,0 +1,61 @@ +#!/bin/bash + +set -e + +# List files changed in the commit to check +FILES=`git log -n 2 --name-only --format=""` + +TEST_EXAMPLES=No + +# Currently examine en directory only, can extend to other lang when neded +for f in $FILES; do + if [[ $f =~ "content/en/examples/" ]]; then + TEST_EXAMPLES=Yes + break + fi + if [[ $f =~ ".travis.yml" ]]; then + TEST_EXAMPLES=Yes + break + fi +done + +function install() { + if [[ $TEST_EXAMPLES == No ]]; then + echo "PR not touching examples, skipping example tests install" + exit 0 + fi + + export PATH=$GOPATH/bin:$PATH + mkdir -p $HOME/gopath/src/k8s.io + mv $TRAVIS_BUILD_DIR $HOME/gopath/src/k8s.io/website && cd $HOME/gopath/src/k8s.io/website + + # Make sure we are testing against the correct branch + wget https://github.com/kubernetes/kubernetes/archive/v${KUBE_VERSION}.0.tar.gz -P $GOPATH/src/k8s.io + + pushd $GOPATH/src/k8s.io + tar xzf v${KUBE_VERSION}.0.tar.gz + mv kubernetes-${KUBE_VERSION}.0 kubernetes + cd kubernetes + make generated_files + cp -L -R vendor $GOPATH/src/ + rm -r vendor + popd + + # Fetch additional dependencies to run the tests in examples/examples_test.go + go get -t -v k8s.io/website/content/en/examples +} + +function run_test() { + if [[ $TEST_EXAMPLES == No ]]; then + echo "PR not touching examples, skipping example tests execution" + exit 0 + fi + go test -v k8s.io/website/content/en/examples +} + +if [[ $1 == install ]]; then + install + exit 0 +elif [[ $1 == "run" ]]; then + run_test +fi diff --git a/static/css/blog.css b/static/css/blog.css index 29bce5c2fc..eefa7aeac3 100644 --- a/static/css/blog.css +++ b/static/css/blog.css @@ -393,6 +393,11 @@ body { text-decoration: none; } +div a.button { + font-size: 16px; +} + + a:link.button { color: #ffffff; } diff --git a/static/css/case-study-styles.css b/static/css/case-study-styles.css index e330cd2677..d3dd3d4c58 100644 --- a/static/css/case-study-styles.css +++ b/static/css/case-study-styles.css @@ -1,2 +1 @@ -html,body{margin:0;padding:0}input,button{outline:none}button{cursor:pointer}ul,li{list-style:none}ul{margin:0;padding:0}a{text-decoration:none}.clear{display:block;clear:both}.light-text{color:#fff}.right{float:right}.left{float:left}.center{text-align:center}*,.button{box-sizing:border-box;font-family:"Roboto",sans-serif;background:none;margin:0;border:0}body{font-family:"Roboto",sans-serif}h1,h2,h5,p{font-weight:300}h3,h4{font-weight:400}html,body{margin:0;padding:0}input,button{outline:none}button{cursor:pointer}ul,li{list-style:none}ul{margin:0;padding:0}a{text-decoration:none}.clear{display:block;clear:both}.light-text{color:#fff}.right{float:right}.left{float:left}.center{text-align:center}h1{font-size:32px;line-height:40px}h2{font-size:28px;line-height:60px}h3{font-size:24px;line-height:32px}h4{font-size:20px;line-height:40px}h5{font-size:16px;line-height:36px}p{font-size:14px;line-height:22px}section,header,#vendorStrip{padding-left:20px;padding-right:20px}section main,header main,#vendorStrip main{width:100%;max-width:100%}header{height:80px}.nav-buttons{height:80px;line-height:80px}.nav-buttons .button+*{margin-left:30px}#hamburger{width:50px;height:50px}#mainNav{padding:140px 0 30px}#mainNav h5{margin-bottom:1em}#mainNav h3{margin-bottom:.6em}#mainNav .nav-box{width:20%}#mainNav .nav-box+.nav-box{margin-left:calc(20% / 3)}#mainNav main+main{margin-top:60px}#mainNav .left .button{height:50px;line-height:50px;font-size:18px}.open-nav #tryKubernetes,.y-enough #tryKubernetes{margin-left:30px}#hero{padding-top:80px}#docs #hero h1,#docs #hero h5{padding-left:20px;padding-right:20px}#vendorStrip{height:88px;line-height:88px;font-size:16px}body{background-color:#fff}section{position:relative;background-color:#fff}section main,header main,footer main{position:relative;margin:auto}p{font-size:14px;font-weight:400}.button{display:inline-block;border-radius:6px;padding:0 20px;line-height:40px;color:#fff;background-color:#3371e3;text-decoration:none;font-size:1rem}#cellophane{position:fixed;top:0;left:0;width:100%;height:100%;display:none}header{position:fixed;top:0;left:0;width:100%;z-index:8888;background-color:transparent;box-shadow:0 0 0 transparent;overflow:hidden;transition:.3s;text-align:center}.logo{position:relative;float:left;display:block;width:180px;height:88px;top:0;left:0;transform:none;background-image:url(/images/nav_logo.svg);background-size:contain;background-position:center center;background-repeat:no-repeat}.blog-content table{max-width:100%;border:1px solid #ccc;border-spacing:0;margin-top:30px;margin-bottom:30px}.blog-content table thead{border-bottom:2px solid #ccc}.blog-content table thead tr th{padding:.5rem;font-size:1.5rem}.blog-content table tbody tr td{padding:.5rem;border-bottom:1px solid #ccc;border-left:1px solid #ccc;padding-right:5rem}#docs .flyout-button{position:fixed;top:20px;left:20px;width:50px;height:50px;background-image:url(/images/toc_icon.png);background-position:center center;background-repeat:no-repeat;background-size:auto;border-radius:50%;transition:.3s;z-index:99999}#docs.open-nav .flyout-button{display:none}#docs .logo{position:absolute;top:40px;left:50%;transform:translate(-50%, -50%);display:block;width:45px;height:44px;background-image:url(/images/favicon.png)}#docs.flip-nav .flyout-button{background-image:url(/images/toc_icon_grey.png)}.nav-buttons{float:right}#viewDocs,#tryKubernetes{display:none}#viewDocs{border:2px solid #fff;background-color:transparent;transition:.3s}#viewDocs:hover{background-color:#fff;color:#303030}#tryKubernetes{width:0;padding:0 0;border:1px solid transparent;background-color:transparent;text-align:center;white-space:nowrap;vertical-align:middle;overflow:hidden;transition:.3s}#hamburger{display:inline-block;position:relative;vertical-align:middle;padding:0;border:0;background:none}#hamburger div,#hamburger:before,#hamburger:after{position:absolute;left:15%;width:70%;height:2px;background-color:#3371e3;transition:.3s;content:""}#hamburger div{top:calc(50% - 1px)}#hamburger:before{top:24%}#hamburger:after{bottom:24%}#hamburger:hover div,#hamburger:hover:before,#hamburger:hover:after{background-color:#fff}#mainNav h5{color:#3371e3;font-weight:normal}#mainNav main{white-space:nowrap;overflow:hidden;clear:both}#mainNav .nav-box{float:left;white-space:normal}#mainNav h3 a{color:#3371e3;text-decoration:none}ul.global-nav{display:none}ul.global-nav li{display:inline-block;margin-right:14px}ul.global-nav li a{color:#fff;font-weight:400;padding:0;position:relative}ul.global-nav li a.active:after{position:absolute;width:100%;height:2px;content:"";bottom:-4px;left:0;background:#fff}ul.global-nav li a .ui-icon{filter:brightness(0) invert(1)}ul.global-nav li ul{display:none;position:fixed;top:40px;text-align:left}ul.global-nav li ul li{display:block;height:28px}ul.global-nav li ul li a{background:#303030;color:#fff;padding:7px}ul.global-nav li ul li:last-child a{border-radius:7px}ul.global-nav li:hover ul{display:block}.flip-nav ul.global-nav li a,.open-nav ul.global-nav li a{color:#303030}.flip-nav ul.global-nav li a .ui-icon,.open-nav ul.global-nav li a .ui-icon{filter:brightness(0)}.flip-nav ul.global-nav li ul li a{background:#fff;color:#303030}.flip-nav ul.global-nav li a.active:after,.flip-nav ul.global-nav li ul li a.active:after,.open-nav ul.global-nav li a.active:after{background:#3371e3}.flip-nav header{background-color:#fff}.open-nav body{overflow:hidden}.open-nav #cellophane{display:block;z-index:9998}.open-nav header{background-color:#e8e8e8;z-index:9999}.open-nav #hamburger div{opacity:0}.open-nav #hamburger:before,.open-nav #hamburger:after{left:12px;transform-origin:0 1px}.open-nav #hamburger:before{transform:rotate(45deg)}.open-nav #hamburger:after{transform:rotate(-45deg)}.open-nav #tryKubernetes,.y-enough #tryKubernetes{width:auto;padding:0 20px;background-color:#3371e3;border-color:#3371e3}.flip-nav header,.open-nav header{box-shadow:0 1px 2px #4c4c4c}.flip-nav #viewDocs,.open-nav #viewDocs{border-color:#303030;color:#303030}.flip-nav #viewDocs:hover,.open-nav #viewDocs:hover{border-color:#3371e3;background-color:#3371e3;color:#fff}.flip-nav #hamburger:hover div,.flip-nav #hamburger:hover:before,.flip-nav #hamburger:hover:after,.open-nav #hamburger:hover div,.open-nav #hamburger:hover:before,.open-nav #hamburger:hover:after{background-color:#303030}#hero{background-image:url(/images/texture.png);background-color:#303030;text-align:center;padding-left:0;padding-right:0;margin-bottom:0;position:relative}#hero.bot-bar:after{display:block;margin-bottom:-20px;height:8px;width:100%;background-color:rgba(255,255,255,0.1);content:""}#hero.no-sub h5{display:none}#hero.no-sub h1{margin-bottom:20px}#home #hero:after{display:none}#vendorStrip{position:relative;background-color:rgba(255,255,255,0.1);font-weight:100;white-space:nowrap;text-align:center}#vendorStrip li a{color:rgba(255,255,255,0.5)}#vendorStrip li a.YAH{color:#fff;position:relative}footer{width:100%;background-image:url(/images/texture.png);background-color:#303030}footer main{padding:20px 0}footer nav a{width:100%;text-align:center;display:inline-block;margin:10px 0;font-size:24px;font-weight:300;color:#fff;text-decoration:none}footer .social{margin:20px 0}footer .social div{text-align:center;margin-bottom:20px}footer .social div:last-child{margin:30px 0}footer .social span{display:block;margin-bottom:8px}footer .social input{text-align:center}#search,#wishField{background-color:transparent;padding:10px;font-size:16px;font-weight:100;color:#fff;border:1px solid #fff;transition:.3s}#search:focus,#wishField:focus{background-color:#f7f7f7;color:#303030}.social a{display:inline-block;background-image:url(/images/social_sprite.png);background-repeat:no-repeat;background-size:auto;width:50px;height:50px;border-radius:5px;margin-right:10px}.social a:hover{background-color:#fff}.social a span{position:absolute;display:block;height:0;overflow:hidden}.social a.button{background-image:none;width:auto;height:auto}.social a.button:hover{color:#3371e3}a.twitter{background-position:0 0}a.twitter:hover{background-position:0 100%}a.stack-overflow{background-position:-50px 0}a.stack-overflow:hover{background-position:-50px 100%}a.slack{background-position:-100px 0}a.slack:hover{background-position:-100px 100%}a.github{background-position:-150px 0}a.github:hover{background-position:-150px 100%}a.mailing-list{background-position:-200px 0}a.mailing-list:hover{background-position:-200px 100%}a.calendar{background-position:-250px 0}a.calendar:hover{background-position:-250px 100%}#viewDocs{display:none}section{background-color:#fff}#hero{background-color:#303030}#hero h5{margin:20px 0;line-height:28px}#vendorStrip{position:relative}#vendorStrip ul{float:left}#vendorStrip li{display:inline-block;height:100%}#vendorStrip a{display:block;height:100%;color:#fff;font-size:.75em;font-weight:bold}#vendorStrip li+li{margin-left:0}#docs #vendorStrip{line-height:44px;max-width:100%;overflow-x:auto;-webkit-overflow-scrolling:touch}#docs #vendorStrip ul{float:none}#docs #vendorStrip #searchBox{float:none;display:block;width:80%;margin:0 auto;height:44px;line-height:44px;position:relative}#docs #vendorStrip #searchBox:before{position:absolute;width:15px;height:15px;content:"";right:8px;top:7px;background-image:url(/images/search-icon.svg);background-repeat:no-repeat;background-size:100% 100%;z-index:1}#docs #vendorStrip #search{width:100%;padding:0 10px;height:30px;line-height:30px;font-size:16px;vertical-align:top;background:#fff;border:none;border-radius:4px;position:relative}#encyclopedia{position:relative;padding:50px 20px 20px 20px;overflow:hidden;font-size:14px}#encyclopedia>div{height:100%}#docsToc{position:fixed;background-color:#fff;top:0;left:0;width:0;height:100vh;overflow:hidden;padding:50px 0;z-index:999999;transition:.3s}#docsToc .yah>.title{background-color:#f7f7f7;border-left:3px solid #3371e3;padding:7.5px 10px 7.5px 18px;margin-left:-3px;color:#3371e3}.open-toc body{overflow:hidden}.open-toc #docsToc{padding:50px 20px;width:400px;max-width:100vw;overflow-y:auto}.pi-accordion>.container:first-child>.item:first-child>.title:first-child{padding-left:0;font-size:1.5em;font-weight:700}.pi-accordion>.container:first-child>.item.yah:first-child>.title:first-child{margin-left:-20px !important}.pi-accordion .item{overflow:hidden}.pi-accordion .title{color:#303030;position:relative;padding:7.5px 10px 7.5px 18px;cursor:pointer;transition:.3s}.pi-accordion .title:hover{color:#3371e3}.pi-accordion a.item>.title{color:#000}.pi-accordion a.item>.title:hover{color:#3371e3}.pi-accordion div.item>.title:before{content:"";position:absolute;top:12px;left:2px;border-style:solid;border-width:5px 0 5px 8px;border-color:transparent transparent transparent #3371e3;transform:rotate(0deg);transition:.3s}.pi-accordion .wrapper{position:relative;width:100%;transition:height .3s}.pi-accordion .content{padding-left:20px;opacity:0;transition:.3s}.pi-accordion .item.on>.title:before{transform:rotate(90deg)}.pi-accordion .item.on>.wrapper>.content{opacity:1}dt{margin-bottom:8px}dd{margin-bottom:16px}.pi-pushmenu{display:none;position:fixed;top:0;width:100%;height:100%;opacity:0;transition:opacity .3s}.pi-pushmenu.on{opacity:1}.pi-pushmenu .overlay{position:fixed;top:0;left:0;width:100%;height:100%;background-color:rgba(0,0,0,0.4)}.pi-pushmenu .sled{position:absolute;top:0;width:0;height:100%;background-color:#fff;overflow:auto;transition:.3s}.pi-pushmenu.on .sled{width:400px;max-width:100vw}.pi-pushmenu .top-bar{height:0;line-height:60px;background-color:#444}.pi-pushmenu ul{margin-top:25px}.pi-pushmenu li{position:relative;display:block;width:100%;min-height:45px;padding:0 60px 0 20px;border-bottom:1px solid #ccc}.pi-pushmenu a{display:inline-block;width:100%;height:45px;line-height:45px;font-family:"Roboto",sans-serif;font-size:20px;color:#3371e3}.pi-pushmenu .button{background:none;padding:0}.pi-pushmenu ul ul{padding:0 20px}.pi-pushmenu ul ul li{min-height:40px}.pi-pushmenu ul ul a{height:40px;line-height:40px;font-size:18px;color:#555}.push-menu-close-button{position:absolute;top:0;right:0;width:50px;height:50px}.push-menu-close-button:before,.push-menu-close-button:after{content:"";position:absolute;top:calc(50% - 1px);left:25%;width:50%;height:2px;background-color:#000}.push-menu-close-button:before{transform:rotate(45deg)}.push-menu-close-button:after{transform:rotate(-45deg)}#docsContent{position:relative;float:right;width:100%}#docsContent *+h2,#docsContent *+h3,#docsContent *+h4,#docsContent *+h5,#docsContent *+h6{margin-top:30px}#docsContent h1,#docsContent h2,#docsContent h3,#docsContent h4,#docsContent h5,#docsContent h6{line-height:normal;font-weight:500;margin-bottom:30px;padding-bottom:10px}#docsContent h1:before,#docsContent h2:before,#docsContent h3:before,#docsContent h4:before,#docsContent h5:before,#docsContent h6:before{display:block;content:" ";margin-top:-100px;height:100px;visibility:hidden}#docsContent h1,#docsContent h2{border-bottom:1px solid #ccc}#docsContent h1{font-size:32px;padding-right:60px}#docsContent h2{font-size:28px}#docsContent h3{font-size:24px;font-weight:300;margin-bottom:5px}#docsContent h4{font-size:20px;margin-bottom:0px}#docsContent h5,#docsContent h6{font-size:16px;font-weight:500}#docsContent p{font-size:16px;font-weight:300;line-height:1.75em}#docsContent p+p{margin-top:10px}#docsContent code{display:inline-block;box-sizing:border-box;background-color:#f7f7f7;color:#303030;font-family:"Roboto Mono",monospace;vertical-align:baseline;font-size:14px;font-weight:bold;padding:2px 4px}#docsContent a code{color:#3371e3;text-decoration:underline}#docsContent pre .pi,#docsContent pre .s{margin:0;padding:0}#docsContent .highlight code span,#docsContent code,#docsContent pre code{font-family:"Roboto Mono",monospace}#docsContent code,#docsContent pre code{color:#303030}#docsContent pre code{padding:0}#docsContent pre{background-color:#f7f7f7;display:block;margin:20px 0;padding:15px;position:relative;overflow-x:auto}#docsContent h1 code,#docsContent h2 code,#docsContent h3 code,#docsContent h4 code,#docsContent h5 code,#docsContent h6 code{font-size:inherit;background-color:transparent}#docsContent .includecode{table-layout:fixed}#docsContent .includecode,#docsContent .includecode th,#docsContent .includecode td{padding:0 !important}#docsContent .includecode th{text-align:right !important;padding:10px !important}#docsContent .includecode th a,#docsContent .includecode th a code{color:#fff !important;background-color:transparent !important}#docsContent .includecode pre{margin:0 !important}#docsContent ul li{list-style:disc}#docsContent ol ul li{list-style:disc}#docsContent ol li{list-style:decimal}#docsContent ul,#docsContent ol{margin:20px 0;padding-left:30px;font-weight:300}#docsContent ul ul,#docsContent ol ol,#docsContent ul ol,#docsContent ol ul{margin:.75em 0}#docsContent li{margin-bottom:.75em;font-size:16px;line-height:1.75em}#docsContent table{width:100%;border:1px solid #ccc;border-spacing:0;margin-top:30px;margin-bottom:30px}#docsContent thead,#docsContent tr:nth-child(even){background-color:#f7f7f7}#docsContent thead{background-color:#555;color:#fff}#docsContent th,#docsContent td{padding:8px;text-align:left;margin:0}#docsContent th{font-weight:normal}#docsContent td{font-size:.85em}#docsContent #editPageButton{position:absolute;top:-25px;right:5px;width:50px;height:50px;line-height:50px;border-radius:50%;white-space:nowrap;text-indent:50px;overflow:hidden;background:#3371e3 url(/images/icon-pencil.svg) no-repeat;background-position:12px 10px;background-size:29px 29px}#docsContent #markdown-toc,#docsContent #TableOfContents{margin-bottom:20px}#docsContent #markdown-toc ul,#docsContent #markdown-toc li,#docsContent #TableOfContents ul,#docsContent #TableOfContents li{list-style:disc;color:#3371e3}#docsContent #markdown-toc ul,#docsContent #TableOfContents ul{padding:0 15px;margin:0}#docsContent #markdown-toc li,#docsContent #TableOfContents li{padding:0;line-height:1.5em;margin-bottom:0}#docsContent #markdown-toc a,#docsContent #TableOfContents a{position:relative;color:#3371e3;font-weight:700}#docsContent img{max-width:100%}#docsContent #TableOfContents>ul>li{list-style:none}#docsContent #TableOfContents ul,#docsContent #TableOfContents li{list-style:disk}#docsContent a.button{border-radius:2px;text-decoration:none}#docsContent a.button:visited{color:#fff}#docsContent a.issue{margin-left:0px}.feedback--no{margin-left:1em}.feedback--prompt{margin-bottom:1em}.feedback--response{margin-top:1em}.feedback--button__disabled{background-color:#f7f7f7;color:graytext}.feedback--response__hidden{display:none}.fixed footer{position:fixed;bottom:0}#miceType{clear:both;font-size:11px;line-height:18px;color:#aaa}html.search #docsContent{position:relative;float:none;width:90%;max-width:850px;margin:0 auto}html.search #docsContent #editPageButton{display:none}html.search #docsContent table{border:0;margin-bottom:0}html.search #docsContent td{padding:0}html.search #docsContent h1{margin-bottom:0;border-bottom:0;padding-bottom:0;padding-left:8px}#home.flip-nav .logo,#home.open-nav .logo{background-image:url(/images/nav_logo2.svg)}#home #hero{margin-bottom:0;padding-bottom:1px}#home #hero main{padding:0 10px;margin-bottom:30px}#home #hero #vendorStrip{display:none}#oceanNodes{padding-top:60px;padding-bottom:60px}#oceanNodes a{color:#3371e3}#oceanNodes main{margin-bottom:60px;min-height:160px}#oceanNodes .image-wrapper{max-width:75%;margin:0 auto 20px;text-align:center}#oceanNodes .image-wrapper img{width:100%;max-width:160px}#oceanNodes main:first-child .image-wrapper{max-width:100%}#oceanNodes main:first-child .image-wrapper img{max-width:491px}#oceanNodes h3{margin-bottom:30px}#video{height:200px}#video{width:100%;position:relative;background-position:center center;background-size:cover}#video>.light-text{display:none;position:absolute;top:50%;left:75%;width:525px;padding-right:80px;transform:translate(-50%, -50%);color:#fff}#video h2{font-size:32px;line-height:44px;margin-bottom:20px}#video p{margin-bottom:20px}#video #desktopKCButton{position:relative;font-size:18px;background-color:#303030;border-radius:8px;color:#fff;padding:20px 10px 20px 10px}#video #desktopShowVideoButton{position:relative;font-size:24px;background-color:#fff;border-radius:8px;color:#3371e3;padding:15px 30px 15px 80px;margin-bottom:15px}#video #desktopShowVideoButton:before{content:"";position:absolute;position:absolute;top:50%;left:40px;transform:translate(-50%, -50%);width:0;height:0;border-style:solid;border-width:10px 0 10px 20px;border-color:transparent transparent transparent #3371e3}#video #mobileShowVideoButton{position:absolute;top:50%;left:50%;transform:translate(-50%, -50%);width:80px;height:80px;border-radius:50%;background-color:transparent;border:5px solid rgba(255,255,255,0.2);overflow:visible}#video #mobileShowVideoButton:after{position:absolute;top:50%;left:50%;transform:translate(-50%, -50%);left:40px;content:"";width:0;height:0;border-style:solid;border-width:20px 0 20px 30px;border-color:transparent transparent transparent #fff}#videoPlayer{position:fixed;top:0;left:0;width:100vw;height:100vh;background-color:rgba(0,0,0,0.9);display:none}#videoPlayer iframe{position:absolute;top:50%;left:50%;transform:translate(-50%, -50%);width:80vw;height:45vw;max-width:142.2222222222vh;max-height:80vh}#videoPlayer #closeButton{position:absolute;top:20px;right:20px;width:50px;height:50px;border:2px solid transparent;transition:.3s}#videoPlayer #closeButton:before,#videoPlayer #closeButton:after{content:"";position:absolute;top:calc(50% - 1px);left:10%;width:80%;height:2px;background-color:#fff}#videoPlayer #closeButton:before{transform:rotate(45deg)}#videoPlayer #closeButton:after{transform:rotate(-45deg)}#videoPlayer #closeButton:hover{border-color:#fff}#cncf{padding-top:60px;padding-bottom:140px;background-image:url(/images/cncf-color.png);background-position:center 100px;background-repeat:no-repeat;background-size:300px}#kubeweekly{background-color:#f7f7f7;padding-top:60px;padding-bottom:140px;background-size:auto;font-family:"Roboto Mono",monospace !important;font-size:24px;font-weight:bold}#kubeweekly h5{font-size:20px}.subscribe-button{border-radius:6px;padding:0 20px;line-height:31px;color:#fff;background-color:blue;text-decoration:none;font-size:14px}#features{padding-top:140px;background-color:#f7f7f7;background-image:url(/images/wheel.png);background-position:center 60px;background-repeat:no-repeat;background-size:auto}.feature-box{width:100%;overflow:hidden;clear:both}.feature-box h4{line-height:normal;margin-bottom:15px}.feature-box>div:first-child{float:left}.feature-box>div:last-child{float:right}#features h3{margin-bottom:20px}#features .feature-box{margin-bottom:0}#features .feature-box>div{width:100%;margin-bottom:40px}#community.open-nav .logo,#community.flip-nav .logo,.gridPage.open-nav .logo,.gridPage.flip-nav .logo{background-image:url(/images/nav_logo2.svg)}#community #hero,.gridPage #hero{padding-bottom:20px}#community #mainContent,.gridPage #mainContent{padding:20px 0}#community #mainContent main,.gridPage #mainContent main{max-width:none}#community #mainContent a,.gridPage #mainContent a{color:#3371e3}#community #mainContent .content,.gridPage #mainContent .content{margin-bottom:30px;padding:30px 0}#community #mainContent .content h1,#community #mainContent .content h2,#community #mainContent .content h3,#community #mainContent .content h4,#community #mainContent .content h5,#community #mainContent .content h6,#community #mainContent .content p,.gridPage #mainContent .content h1,.gridPage #mainContent .content h2,.gridPage #mainContent .content h3,.gridPage #mainContent .content h4,.gridPage #mainContent .content h5,.gridPage #mainContent .content h6,.gridPage #mainContent .content p{line-height:normal;max-width:1200px;padding:0 20px;margin:0 auto 20px}#community #mainContent .content:nth-child(even),.gridPage #mainContent .content:nth-child(even){background-color:#f7f7f7}#community #mainContent .company-logos,.gridPage #mainContent .company-logos{text-align:center;max-width:1200px;margin:0 auto}#community #mainContent .company-logos img,.gridPage #mainContent .company-logos img{width:auto;margin:10px;background-color:#f7f7f7}#community #mainContent .partner-logos,.gridPage #mainContent .partner-logos{text-align:center;max-width:1200px;margin:0 auto}#community #mainContent .partner-logos img,.gridPage #mainContent .partner-logos img{width:auto;margin:10px;background-color:#fff;box-shadow:0 5px 5px rgba(0,0,0,0.24),0 0 5px rgba(0,0,0,0.12)}#community #mainContent #calendarMeetings,.gridPage #mainContent #calendarMeetings{position:relative;width:80vw;height:60vw;max-width:1200px;max-height:900px;margin:20px auto}#community #mainContent #calendarEvents,.gridPage #mainContent #calendarEvents{position:relative;width:80vw;height:30vw;max-width:1200px;max-height:450px;margin:20px auto}#community #mainContent iframe,.gridPage #mainContent iframe{position:absolute;border:0;width:100%;height:100%}.ui-icon{display:inline-block !important}#feature-state-dialog-link{text-decoration:none !important;padding:5px !important}#feature-state-dialog-link a:visited{color:#454545 !important}#feature-state-dialog-link a code{display:inline-block !important;box-sizing:border-box !important;background-color:#f7f7f7 !important;color:#303030 !important;font-family:"Roboto Mono",monospace !important;vertical-align:baseline !important;font-size:14px !important;font-weight:bold !important;padding:0px 4px !important}#feature-state-dialog{background:#fff !important;border:1px solid #ddd !important;padding:.5em 1em !important}#feature-state-dialog ul,#feature-state-dialog li{list-style:disc !important;margin:4px 12px !important}#feature-state-dialog p{margin:8px 0px !important}#feature-state-dialog code{display:inline-block !important;box-sizing:border-box !important;background-color:#f7f7f7 !important;color:#303030 !important;font-family:"Roboto Mono",monospace !important;vertical-align:baseline !important;font-size:14px !important;font-weight:bold !important;padding:0px 4px !important}.ui-dialog{background:#f7f7f7 !important;padding:.5em}.ui-dialog-content{position:relative;float:right;width:100%}.ui-dialog-content *+h2,.ui-dialog-content *+h3,.ui-dialog-content *+h4,.ui-dialog-content *+h5,.ui-dialog-content *+h6{margin-top:30px}.ui-dialog-content h1,.ui-dialog-content h2,.ui-dialog-content h3,.ui-dialog-content h4,.ui-dialog-content h5,.ui-dialog-content h6{line-height:normal;font-weight:500;margin-bottom:30px;padding-bottom:10px}.ui-dialog-content h1:before,.ui-dialog-content h2:before,.ui-dialog-content h3:before,.ui-dialog-content h4:before,.ui-dialog-content h5:before,.ui-dialog-content h6:before{display:block;content:" ";margin-top:-100px;height:100px;visibility:hidden}.ui-dialog-content h1,.ui-dialog-content h2{border-bottom:1px solid #ccc}.ui-dialog-content h1{font-size:32px;padding-right:60px}.ui-dialog-content h2{font-size:28px}.ui-dialog-content h3{font-size:24px;font-weight:300;margin-bottom:5px}.ui-dialog-content h4{font-size:20px;margin-bottom:0px}.ui-dialog-content h5,.ui-dialog-content h6{font-size:16px;font-weight:500}.ui-dialog-content p{font-size:16px;font-weight:300;line-height:1.75em}.ui-dialog-content p+p{margin-top:10px}.ui-dialog-content code{display:inline-block;box-sizing:border-box;background-color:#f7f7f7;color:#303030;font-family:"Roboto Mono",monospace;vertical-align:baseline;font-size:14px;font-weight:bold;padding:2px 4px}.ui-dialog-content a code{color:#3371e3;text-decoration:underline}.ui-dialog-content pre .pi,.ui-dialog-content pre .s{margin:0;padding:0}.ui-dialog-content .highlight code span,.ui-dialog-content code,.ui-dialog-content pre code{font-family:"Roboto Mono",monospace}.ui-dialog-content code,.ui-dialog-content pre code{color:#303030}.ui-dialog-content pre code{padding:0}.ui-dialog-content pre{background-color:#f7f7f7;display:block;margin:20px 0;padding:15px;position:relative;overflow-x:auto}.ui-dialog-content h1 code,.ui-dialog-content h2 code,.ui-dialog-content h3 code,.ui-dialog-content h4 code,.ui-dialog-content h5 code,.ui-dialog-content h6 code{font-family:inherit;font-size:inherit;background-color:transparent}.ui-dialog-content .includecode{table-layout:fixed}.ui-dialog-content .includecode,.ui-dialog-content .includecode th,.ui-dialog-content .includecode td{padding:0 !important}.ui-dialog-content .includecode th{text-align:right !important;padding:10px !important}.ui-dialog-content .includecode th a,.ui-dialog-content .includecode th a code{color:#fff !important;background-color:transparent !important}.ui-dialog-content .includecode pre{margin:0 !important}.ui-dialog-content ul li{list-style:disc}.ui-dialog-content ol li{list-style:decimal}.ui-dialog-content ul,.ui-dialog-content ol{margin:20px 0;padding-left:30px;font-weight:300}.ui-dialog-content ul ul,.ui-dialog-content ol ol,.ui-dialog-content ul ol,.ui-dialog-content ol ul{margin:.75em 0}.ui-dialog-content li{margin-bottom:.75em;font-size:16px;line-height:1.75em}.ui-dialog-content table{width:100%;border:1px solid #ccc;border-spacing:0;margin-top:30px;margin-bottom:30px}.ui-dialog-content thead,.ui-dialog-content tr:nth-child(even){background-color:#f7f7f7}.ui-dialog-content thead{background-color:#555;color:#fff}.ui-dialog-content th,.ui-dialog-content td{padding:8px;text-align:left;margin:0}.ui-dialog-content th{font-weight:normal}.ui-dialog-content td{font-size:.85em}.ui-dialog-content #editPageButton{position:absolute;top:-25px;right:5px;width:50px;height:50px;line-height:50px;border-radius:50%;white-space:nowrap;text-indent:50px;overflow:hidden;background:#3371e3 url(/images/icon-pencil.svg) no-repeat;background-position:12px 10px;background-size:29px 29px}.ui-dialog-content #markdown-toc{margin-bottom:20px}.ui-dialog-content #markdown-toc ul,.ui-dialog-content #markdown-toc li{list-style:disc;color:#3371e3}.ui-dialog-content #markdown-toc ul{padding:0 15px;margin:0}.ui-dialog-content #markdown-toc li{padding:0;line-height:1.5em;margin-bottom:0}.ui-dialog-content #markdown-toc a{position:relative;color:#3371e3;font-weight:700}.ui-dialog-content img{max-width:100%}.ui-dialog-content a{text-decoration:underline}.ui-dialog-content a.button{border-radius:2px;text-decoration:none}.ui-dialog-content a.button:visited{color:#fff}.ui-dialog-content a.issue{margin-left:0px}.ui-dialog-buttonpane{background:#f7f7f7 !important}.ui-widget-header{background:transparent !important;background-color:transparent !important;border:0px !important}.ui-tabs ul,.ui-tabs ol,.ui-tabs li{padding:0px !important;list-style:none !important;margin-bottom:0px !important;margin-left:4px !important}.ui-tabs-panel ul li{list-style:disc !important}.ui-tabs-panel ol li{list-style:decimal !important}.ui-widget-content{border:0px !important}.ui-widget-content p a{color:#3371e3}.ui-widget-content table{margin:0px !important}.ui-tabs .ui-tabs-panel{border:1px solid #ccc !important}.ui-tabs-anchor{text-decoration:none !important}#talkToUs h3,#talkToUs h4{text-align:center}#talkToUs h3{margin-bottom:15px}#talkToUs h4{line-height:normal;margin-bottom:50px}#talkToUs h4 br{display:none}#talkToUs #bigSocial{overflow:hidden}#talkToUs #bigSocial div{width:100%;float:left;padding:30px;padding-top:110px;background-position:center top;background-size:auto;background-repeat:no-repeat}#talkToUs #bigSocial div:nth-child(1){background-image:url(/images/twitter_icon.png)}#talkToUs #bigSocial div:nth-child(2){background-image:url(/images/github_icon.png)}#talkToUs #bigSocial div:nth-child(3){background-image:url(/images/slack_icon.png)}#talkToUs #bigSocial div:nth-child(4){background-image:url(/images/stackoverflow_icon.png)}#talkToUs #bigSocial div+div{margin-top:20px;margin-left:0}#talkToUs #bigSocial a{display:inline-block;color:#3371e3;font-size:24px;font-weight:400;text-decoration:none;margin-bottom:15px}#talkToUs #bigSocial a,#talkToUs #bigSocial p{text-align:center;width:100%}#home #talkToUs main{padding:30px 0}#home #talkToUs h5{font-size:20px}#home #caseStudiesWrapper{position:relative;text-align:center;margin-bottom:30px}#home #caseStudiesWrapper img{padding-bottom:1rem}#home #caseStudiesWrapper div{position:relative;display:inline-block;vertical-align:top;width:100%;min-height:230px;margin-bottom:60px;padding-right:1rem;background-position:top center}#home #caseStudiesWrapper p{font-size:20px}#home #caseStudiesWrapper a{position:absolute;bottom:-30px;left:50%;transform:translateX(-50%);color:#3371e3;font-weight:400}.cse .gsc-control-cse,.gsc-control-cse{padding:0}.gsc-control-cse table,.gsc-control-cse-en table{margin:0px !important}.gsc-above-wrapper-area{border-bottom:0}#bing-results-container{margin-top:30px;margin-left:20px}.bing-result{margin-bottom:20px}.bing-result-name a{font-size:16px;color:#00c}.bing-result-url{color:green;font-size:13px}.bing-result-snippet{color:#000;font-size:11px}#bing-pagination-container{margin:10px;margin-left:20px}.bing-page-anchor{text-decoration:none !important;cursor:pointer;color:#00c;margin-right:8px}.page{display:flex;flex-direction:column;min-height:100vh}.page .page-content{flex:1}.container-404{text-align:center;margin:3.5rem 0}.container-404 ul li a{font-size:1.5rem}#pre-footer{margin-top:2rem}#pre-footer .button{font-size:1.1rem}#pre-footer .button:first-of-type{margin-right:.75rem}#pre-footer .lastedit{margin-top:1rem;font-size:1rem}hr{background-color:#999}h2{margin-bottom:15px !important}.subhead{padding-bottom:2% !important;padding-top:0% !important}.details{margin-left:1.9%;padding-right:5%;font-size:16px !important;padding-bottom:2% !important}.section1{margin-bottom:3%}.section1 .cols{width:80% !important;margin-left:6.8%;padding-top:1.5%}.section1 .cols .col1{width:52% !important;font-weight:300 !important}.section1 .cols .col2{width:46% !important}.banner2text{width:63%;padding-top:10%;padding-left:0% !important;float:initial !important;text-align:center;margin:0 auto;position:relative}.banner3text,.banner4text,.banner5text{width:63%;padding-left:0% !important;float:initial !important;text-align:center;margin:0 auto;position:relative}.fullcol{float:initial !important}body footer{background-color:#585858 !important}.section1{float:left !important}.banner1{padding-left:11.9% !important}.banner2{float:initial !important;padding-bottom:2% !important}footer{padding:0% 7%}.banner4,.banner3,.banner5{float:initial !important}@media screen and (max-width: 910px){.banner2text{width:47%;padding-top:45%}.details{margin-left:0%;margin-bottom:3%}.subhead{padding-bottom:0% !important;padding-top:0% !important}.banner3{width:100% !important}}@media screen and (max-width: 780px){.section1 .cols{width:100% !important;margin-left:0%;padding-top:5%}.section1 .cols .col1,.section1 .cols .col2{width:100% !important;margin-left:0% !important}.fullcol{width:90% !important;margin-left:5% !important}.banner1{padding-left:10% !important;margin-bottom:6% !important}.banner2text{padding-top:60% !important;padding-bottom:2% !important}}@media screen and (min-width: 750px){h1{font-size:32px;line-height:40px}h2{font-size:28px;line-height:60px}h3{font-size:24px;line-height:32px}h4{font-size:20px;line-height:40px}h5{font-size:16px;line-height:36px}p{font-size:14px;line-height:22px}section,header,#vendorStrip{padding-left:20px;padding-right:20px}section main,header main,#vendorStrip main{width:100%;max-width:100%}header{height:80px}.nav-buttons{height:80px;line-height:80px}.nav-buttons .button+*{margin-left:30px}#hamburger{width:50px;height:50px}#mainNav{padding:140px 0 30px}#mainNav h5{margin-bottom:1em}#mainNav h3{margin-bottom:.6em}#mainNav .nav-box{width:20%}#mainNav .nav-box+.nav-box{margin-left:calc(20% / 3)}#mainNav main+main{margin-top:60px}#mainNav .left .button{height:50px;line-height:50px;font-size:18px}.open-nav #tryKubernetes,.y-enough #tryKubernetes{margin-left:30px}#hero{padding-top:80px}#docs #hero h1,#docs #hero h5{padding-left:20px;padding-right:20px}#vendorStrip{height:88px;line-height:88px;font-size:16px}p{font-size:16px;line-height:24px;letter-spacing:.1px}h1{font-size:36px;line-height:44px}h3{font-size:28px;line-height:36px}h4{font-size:24px;line-height:40px}#home #viewDocs,#home #tryKubernetes{display:inline-block}#vendorStrip{display:block;text-align:center}#vendorStrip img{max-height:24px;vertical-align:middle;margin:0 30px}#docs #vendorStrip li a{font-size:1em;font-weight:normal}#docs #vendorStrip li li+li{margin-left:60px}#oceanNodes h3{text-align:left;margin-bottom:18px}#oceanNodes main{position:relative;clear:both;display:table;height:160px}#oceanNodes main .content{display:table-cell;position:relative;vertical-align:middle}#oceanNodes main .image-wrapper{position:absolute;top:50%;max-width:25%;max-height:100%;transform:translateY(-50%)}#oceanNodes main:nth-child(odd){padding-right:210px}#oceanNodes main:nth-child(odd) .image-wrapper{right:0}#oceanNodes main:nth-child(even){padding-left:210px}#oceanNodes main:nth-child(even) .image-wrapper{left:0}#oceanNodes main:nth-child(1){padding-right:0}#oceanNodes main:nth-child(1) h3,#oceanNodes main:nth-child(1) p{text-align:center}#oceanNodes main:nth-child(1) .image-wrapper{position:relative;display:block;float:none;max-width:100%;transform:none}#oceanNodes main:nth-child(1) .content{display:block}#oceanNodes main img{width:100%}#video{height:400px;display:block}#video>.light-text{display:block}#mobileShowVideoButton{display:none}#features{padding-bottom:60px}#features .feature-box{margin-bottom:30px}#features .feature-box:last-child{margin-bottom:0}#features h3{margin-bottom:40px}#features .feature-box>div{width:45%;margin-bottom:0}#talkToUs #bigSocial div{width:calc(50% - 15px)}#talkToUs #bigSocial div+div{margin-top:0}#talkToUs #bigSocial div:nth-child(2){margin-left:20px}#talkToUs #bigSocial div:nth-child(3){margin-top:20px}#talkToUs #bigSocial div:nth-child(4){margin-top:20px;margin-left:20px}#talkToUs #bigSocial a{display:inline-block;color:#3371e3;font-weight:400;text-decoration:none}footer nav{text-align:center}footer nav a{width:30%;padding:0 20px}footer .social{text-align:center}footer .social div{display:inline-block}footer .social div:last-child{display:block;margin:0}footer .social span{display:inline-block;margin-right:10px}footer .social input{text-align:left}#home #caseStudiesWrapper div{width:48%}}@media screen and (min-width: 1025px){#hamburger{display:none}ul.global-nav{display:inline-block}#docs #vendorStrip #searchBox:before{top:15px}#vendorStrip{height:44px;line-height:44px}#vendorStrip li a.YAH:after{content:"";display:block;position:absolute;left:0;bottom:0;width:100%;height:4px;background-color:#3371e3}#vendorStrip #searchBox{float:right}#home #hero #vendorStrip{display:block}#docs #hero h1,#docs #hero h5{text-align:left}#docs #hero #vendorStrip ul{float:left}#docs #hero #vendorStrip #searchBox{float:right;width:250px}#docs #hero #vendorStrip #search{vertical-align:middle}#docs .flyout-button{display:none}#docs .logo{position:relative;float:left;display:block;width:180px;height:88px;top:0;left:0;transform:none;background-image:url(../images/nav_logo.svg)}#docs.flip-nav .logo,#docs.open-nav .logo{background-image:url(../images/nav_logo2.svg)}#encyclopedia{padding:50px 50px 100px 100px;clear:both}#docsToc{position:relative;float:left;padding:0 20px;left:0;width:350px;z-index:auto}#docsToc .push-menu-close-button{display:none}#docsContent{width:calc(100% - 400px)}#docsContent #editPageButton{right:-25px}section main,header main,footer main{max-width:1200px}header,#vendorStrip,#encyclopedia,#hero h1,#hero h5,#docs #hero h1,#docs #hero h5,#community #hero h1,.gridPage #hero h1,#community #hero h5,.gridPage #hero h5{padding-left:100px;padding-right:100px}#vendorStrip{padding-right:10px}#home section main,#home header main,#home footer main{max-width:1000px}#oceanNodes main{position:relative;max-width:830px}#oceanNodes main:nth-child(1){max-width:1000px;padding-right:475px}#oceanNodes main:nth-child(1) h3,#oceanNodes main:nth-child(1) p{text-align:left}#oceanNodes main:nth-child(1) .image-wrapper{position:absolute;max-width:48%;transform:translateY(-50%)}#oceanNodes main:nth-child(1) .image-wrapper img{max-width:425px}#video{height:550px;position:relative;background-position:center center;background-size:cover}#talkToUs h4 br{display:block}#talkToUs #bigSocial div{width:calc(25% - 18px)}#talkToUs #bigSocial div+div{margin-left:20px}footer{width:100%;background-image:url(../images/texture.png);background-color:#303030}footer main{padding:20px 0}footer nav{overflow:hidden;margin-bottom:20px}footer nav a{width:16.65%;float:left;font-size:24px;font-weight:300;white-space:nowrap}footer .social{padding:0 30px;max-width:1200px}footer .social div{float:left}footer .social div:last-child{float:right}#search,#wishField{background-color:transparent;padding:10px;font-size:16px;font-weight:100;color:#fff;border:1px solid #fff;transition:.3s}#search:focus,#wishField:focus{background-color:#f7f7f7;color:#303030}.social a{display:inline-block;background-image:url(../images/social_sprite.png);background-repeat:no-repeat;background-size:auto;width:50px;height:50px;border-radius:5px;margin-right:10px}.social a:hover{background-color:#fff}.social a span{position:absolute;display:block;height:0;overflow:hidden}a.twitter{background-position:0 0}a.twitter:hover{background-position:0 100%}a.stack-overflow{background-position:-50px 0}a.stack-overflow:hover{background-position:-50px 100%}a.slack{background-position:-100px 0}a.slack:hover{background-position:-100px 100%}a.github{background-position:-150px 0}a.github:hover{background-position:-150px 100%}a.mailing-list{background-position:-200px 0}a.mailing-list:hover{background-position:-200px 100%}a.calendar{background-position:-250px 0}a.calendar:hover{background-position:-250px 100%}#community #hero,.gridPage #hero{text-align:left}#community #hero h1,.gridPage #hero h1{padding:20px 100px}#community #tryKubernetes,.gridPage #tryKubernetes{width:auto;background-color:#3371e3;padding:0 20px}#bigSocial div{width:calc(25% - 18px)}#home #caseStudiesWrapper div{width:24%;min-height:260px}}@media screen and (min-width: 1300px){#vendorStrip{padding-right:100px}}@media screen and (min-width: 456px){#vendorStrip li+li{margin-left:20px}} -/*# sourceMappingURL=case-study-styles.css.map */ +html,body{margin:0;padding:0}input,button{outline:none}button{cursor:pointer}ul,li{list-style:none}ul{margin:0;padding:0}a{text-decoration:none}.clear{display:block;clear:both}.light-text{color:#fff}.right{float:right}.left{float:left}.center{text-align:center}*,.button{box-sizing:border-box;font-family:"Roboto",sans-serif;background:none;margin:0;border:0}body{font-family:"Roboto",sans-serif}h1,h2,h5,p{font-weight:300}h3,h4{font-weight:400}html,body{margin:0;padding:0}input,button{outline:none}button{cursor:pointer}ul,li{list-style:none}ul{margin:0;padding:0}a{text-decoration:none}.clear{display:block;clear:both}.light-text{color:#fff}.right{float:right}.left{float:left}.center{text-align:center}h1{font-size:32px;line-height:40px}h2{font-size:28px;line-height:60px}h3{font-size:24px;line-height:32px}h4{font-size:20px;line-height:40px}h5{font-size:16px;line-height:36px}p{font-size:14px;line-height:22px}section,header,#vendorStrip{padding-left:20px;padding-right:20px}section main,header main,#vendorStrip main{width:100%;max-width:100%}header{height:80px}.nav-buttons{height:80px;line-height:80px}.nav-buttons .button+*{margin-left:30px}#hamburger{width:50px;height:50px}#mainNav{padding:140px 0 30px}#mainNav h5{margin-bottom:1em}#mainNav h3{margin-bottom:0.6em}#mainNav .nav-box{width:20%}#mainNav .nav-box+.nav-box{margin-left:calc(20% / 3)}#mainNav main+main{margin-top:60px}#mainNav .left .button{height:50px;line-height:50px;font-size:18px}.open-nav #tryKubernetes,.y-enough #tryKubernetes{margin-left:30px}#hero{padding-top:80px}#docs #hero h1,#docs #hero h5{padding-left:20px;padding-right:20px}#vendorStrip{height:88px;line-height:88px;font-size:16px}body{background-color:#fff}section{position:relative;background-color:#fff}section main,header main,footer main{position:relative;margin:auto}p{font-size:14px;font-weight:400}.button{display:inline-block;border-radius:6px;padding:0 20px;line-height:40px;color:#fff;background-color:#3371e3;text-decoration:none;font-size:1rem}#cellophane{position:fixed;top:0;left:0;width:100%;height:100%;display:none}header{position:fixed;top:0;left:0;width:100%;z-index:8888;background-color:transparent;box-shadow:0 0 0 transparent;overflow:hidden;transition:0.3s;text-align:center}.logo{position:relative;float:left;display:block;width:180px;height:88px;top:0;left:0;transform:none;background-image:url(/images/nav_logo.svg);background-size:contain;background-position:center center;background-repeat:no-repeat}.blog-content table{max-width:100%;border:1px solid #ccc;border-spacing:0;margin-top:30px;margin-bottom:30px}.blog-content table thead{border-bottom:2px solid #ccc}.blog-content table thead tr th{padding:0.5rem;font-size:1.5rem}.blog-content table tbody tr td{padding:0.5rem;border-bottom:1px solid #ccc;border-left:1px solid #ccc;padding-right:5rem}#docs .flyout-button{position:fixed;top:20px;left:20px;width:50px;height:50px;background-image:url(/images/toc_icon.png);background-position:center center;background-repeat:no-repeat;background-size:auto;border-radius:50%;transition:0.3s;z-index:99999}#docs.open-nav .flyout-button{display:none}#docs .logo{position:absolute;top:40px;left:50%;transform:translate(-50%, -50%);display:block;width:45px;height:44px;background-image:url(/images/favicon.png)}#docs.flip-nav .flyout-button{background-image:url(/images/toc_icon_grey.png)}.nav-buttons{float:right}#viewDocs,#tryKubernetes{display:none}#viewDocs{border:2px solid #fff;background-color:transparent;transition:0.3s}#viewDocs:hover{background-color:#fff;color:#303030}#tryKubernetes{width:0;padding:0 0;border:1px solid transparent;background-color:transparent;text-align:center;white-space:nowrap;vertical-align:middle;overflow:hidden;transition:0.3s}#hamburger{display:inline-block;position:relative;vertical-align:middle;padding:0;border:0;background:none}#hamburger div,#hamburger:before,#hamburger:after{position:absolute;left:15%;width:70%;height:2px;background-color:#3371e3;transition:0.3s;content:""}#hamburger div{top:calc(50% - 1px)}#hamburger:before{top:24%}#hamburger:after{bottom:24%}#hamburger:hover div,#hamburger:hover:before,#hamburger:hover:after{background-color:#fff}#mainNav h5{color:#3371e3;font-weight:normal}#mainNav main{white-space:nowrap;overflow:hidden;clear:both}#mainNav .nav-box{float:left;white-space:normal}#mainNav h3 a{color:#3371e3;text-decoration:none}ul.global-nav{display:none}ul.global-nav li{display:inline-block;margin-right:14px}ul.global-nav li a{color:#fff;font-weight:400;padding:0;position:relative}ul.global-nav li a.active:after{position:absolute;width:100%;height:2px;content:"";bottom:-4px;left:0;background:#fff}ul.global-nav li a .ui-icon{filter:brightness(0) invert(1)}ul.global-nav li ul{display:none;position:fixed;top:40px;text-align:left}ul.global-nav li ul li{display:block;height:28px}ul.global-nav li ul li a{background:#303030;color:#fff;padding:7px}ul.global-nav li ul li:last-child a{border-radius:7px}ul.global-nav li:hover ul{display:block}.flip-nav ul.global-nav li a,.open-nav ul.global-nav li a{color:#303030}.flip-nav ul.global-nav li a .ui-icon,.open-nav ul.global-nav li a .ui-icon{filter:brightness(0)}.flip-nav ul.global-nav li ul li a{background:#fff;color:#303030}.flip-nav ul.global-nav li a.active:after,.flip-nav ul.global-nav li ul li a.active:after,.open-nav ul.global-nav li a.active:after{background:#3371e3}.flip-nav header{background-color:#fff}.open-nav body{overflow:hidden}.open-nav #cellophane{display:block;z-index:9998}.open-nav header{background-color:#e8e8e8;z-index:9999}.open-nav #hamburger div{opacity:0}.open-nav #hamburger:before,.open-nav #hamburger:after{left:12px;transform-origin:0 1px}.open-nav #hamburger:before{transform:rotate(45deg)}.open-nav #hamburger:after{transform:rotate(-45deg)}.open-nav #tryKubernetes,.y-enough #tryKubernetes{width:auto;padding:0 20px;background-color:#3371e3;border-color:#3371e3}.flip-nav header,.open-nav header{box-shadow:0 1px 2px #4c4c4c}.flip-nav #viewDocs,.open-nav #viewDocs{border-color:#303030;color:#303030}.flip-nav #viewDocs:hover,.open-nav #viewDocs:hover{border-color:#3371e3;background-color:#3371e3;color:#fff}.flip-nav #hamburger:hover div,.flip-nav #hamburger:hover:before,.flip-nav #hamburger:hover:after,.open-nav #hamburger:hover div,.open-nav #hamburger:hover:before,.open-nav #hamburger:hover:after{background-color:#303030}#hero{background-image:url(/images/texture.png);background-color:#303030;text-align:center;padding-left:0;padding-right:0;margin-bottom:0;position:relative}#hero.bot-bar:after{display:block;margin-bottom:-20px;height:8px;width:100%;background-color:rgba(255,255,255,0.1);content:""}#hero.no-sub h5{display:none}#hero.no-sub h1{margin-bottom:20px}#home #hero:after{display:none}#vendorStrip{position:relative;background-color:rgba(255,255,255,0.1);font-weight:100;white-space:nowrap;text-align:center}#vendorStrip li a{color:rgba(255,255,255,0.5)}#vendorStrip li a.YAH{color:#fff;position:relative}footer{width:100%;background-image:url(/images/texture.png);background-color:#303030}footer main{padding:20px 0}footer nav a{width:100%;text-align:center;display:inline-block;margin:10px 0;font-size:24px;font-weight:300;color:#fff;text-decoration:none}footer .social{margin:20px 0}footer .social div{text-align:center;margin-bottom:20px}footer .social div:last-child{margin:30px 0}footer .social span{display:block;margin-bottom:8px}footer .social input{text-align:center}#search,#wishField{background-color:transparent;padding:10px;font-size:16px;font-weight:100;color:#fff;border:1px solid #fff;transition:0.3s}#search:focus,#wishField:focus{background-color:#f7f7f7;color:#303030}.social a{display:inline-block;background-image:url(/images/social_sprite.png);background-repeat:no-repeat;background-size:auto;width:50px;height:50px;border-radius:5px;margin-right:10px}.social a:hover{background-color:#fff}.social a span{position:absolute;display:block;height:0;overflow:hidden}.social a.button{background-image:none;width:auto;height:auto}.social a.button:hover{color:#3371e3}a.twitter{background-position:0 0}a.twitter:hover{background-position:0 100%}a.stack-overflow{background-position:-50px 0}a.stack-overflow:hover{background-position:-50px 100%}a.slack{background-position:-100px 0}a.slack:hover{background-position:-100px 100%}a.github{background-position:-150px 0}a.github:hover{background-position:-150px 100%}a.mailing-list{background-position:-200px 0}a.mailing-list:hover{background-position:-200px 100%}a.calendar{background-position:-250px 0}a.calendar:hover{background-position:-250px 100%}#viewDocs{display:none}section{background-color:#fff}#hero{background-color:#303030}#hero h5{margin:20px 0;line-height:28px}#vendorStrip{position:relative}#vendorStrip ul{float:left}#vendorStrip li{display:inline-block;height:100%}#vendorStrip a{display:block;height:100%;color:#fff;font-size:0.75em;font-weight:bold}#vendorStrip li+li{margin-left:0}#docs #vendorStrip{line-height:44px;max-width:100%;overflow-x:auto;-webkit-overflow-scrolling:touch}#docs #vendorStrip ul{float:none}#docs #vendorStrip #searchBox{float:none;display:block;width:80%;margin:0 auto;height:44px;line-height:44px;position:relative}#docs #vendorStrip #searchBox:before{position:absolute;width:15px;height:15px;content:"";right:8px;top:7px;background-image:url(/images/search-icon.svg);background-repeat:no-repeat;background-size:100% 100%;z-index:1}#docs #vendorStrip #search{width:100%;padding:0 10px;height:30px;line-height:30px;font-size:16px;vertical-align:top;background:#fff;border:none;border-radius:4px;position:relative}#encyclopedia{position:relative;padding:50px 20px 20px 20px;overflow:hidden;font-size:14px}#encyclopedia>div{height:100%}#docsToc{position:fixed;background-color:#fff;top:0;left:0;width:0;height:100vh;overflow:hidden;padding:50px 0;z-index:999999;transition:0.3s}#docsToc .yah>.title{background-color:#f7f7f7;border-left:3px solid #3371e3;padding:7.5px 10px 7.5px 18px;margin-left:-3px;color:#3371e3}.open-toc body{overflow:hidden}.open-toc #docsToc{padding:50px 20px;width:400px;max-width:100vw;overflow-y:auto}.pi-accordion>.container:first-child>.item:first-child>.title:first-child{padding-left:0;font-size:1.5em;font-weight:700}.pi-accordion>.container:first-child>.item.yah:first-child>.title:first-child{margin-left:-20px !important}.pi-accordion .item{overflow:hidden}.pi-accordion .title{color:#303030;position:relative;padding:7.5px 10px 7.5px 18px;cursor:pointer;transition:0.3s}.pi-accordion .title:hover{color:#3371e3}.pi-accordion a.item>.title{color:#000}.pi-accordion a.item>.title:hover{color:#3371e3}.pi-accordion div.item>.title:before{content:"";position:absolute;top:12px;left:2px;border-style:solid;border-width:5px 0 5px 8px;border-color:transparent transparent transparent #3371e3;transform:rotate(0deg);transition:0.3s}.pi-accordion .wrapper{position:relative;width:100%;transition:height 0.3s}.pi-accordion .content{padding-left:20px;opacity:0;transition:0.3s}.pi-accordion .item.on>.title:before{transform:rotate(90deg)}.pi-accordion .item.on>.wrapper>.content{opacity:1}dt{margin-bottom:8px}dd{margin-bottom:16px}.pi-pushmenu{display:none;position:fixed;top:0;width:100%;height:100%;opacity:0;transition:opacity 0.3s}.pi-pushmenu.on{opacity:1}.pi-pushmenu .overlay{position:fixed;top:0;left:0;width:100%;height:100%;background-color:rgba(0,0,0,0.4)}.pi-pushmenu .sled{position:absolute;top:0;width:0;height:100%;background-color:#fff;overflow:auto;transition:0.3s}.pi-pushmenu.on .sled{width:400px;max-width:100vw}.pi-pushmenu .top-bar{height:0;line-height:60px;background-color:#444}.pi-pushmenu ul{margin-top:25px}.pi-pushmenu li{position:relative;display:block;width:100%;min-height:45px;padding:0 60px 0 20px;border-bottom:1px solid #ccc}.pi-pushmenu a{display:inline-block;width:100%;height:45px;line-height:45px;font-family:"Roboto",sans-serif;font-size:20px;color:#3371e3}.pi-pushmenu .button{background:none;padding:0}.pi-pushmenu ul ul{padding:0 20px}.pi-pushmenu ul ul li{min-height:40px}.pi-pushmenu ul ul a{height:40px;line-height:40px;font-size:18px;color:#555}.push-menu-close-button{position:absolute;top:0;right:0;width:50px;height:50px}.push-menu-close-button:before,.push-menu-close-button:after{content:"";position:absolute;top:calc(50% - 1px);left:25%;width:50%;height:2px;background-color:#000}.push-menu-close-button:before{transform:rotate(45deg)}.push-menu-close-button:after{transform:rotate(-45deg)}#docsContent{position:relative;float:right;width:100%}#docsContent *+h2,#docsContent *+h3,#docsContent *+h4,#docsContent *+h5,#docsContent *+h6{margin-top:30px}#docsContent h1,#docsContent h2,#docsContent h3,#docsContent h4,#docsContent h5,#docsContent h6{line-height:normal;font-weight:500;margin-bottom:30px;padding-bottom:10px}#docsContent h1:before,#docsContent h2:before,#docsContent h3:before,#docsContent h4:before,#docsContent h5:before,#docsContent h6:before{display:block;content:" ";margin-top:-100px;height:100px;visibility:hidden}#docsContent h1,#docsContent h2{border-bottom:1px solid #ccc}#docsContent h1{font-size:32px;padding-right:60px}#docsContent h2{font-size:28px}#docsContent h3{font-size:24px;font-weight:300;margin-bottom:5px}#docsContent h4{font-size:20px;margin-bottom:0px}#docsContent h5,#docsContent h6{font-size:16px;font-weight:500}#docsContent p{font-size:16px;font-weight:300;line-height:1.75em}#docsContent p+p{margin-top:10px}#docsContent code{display:inline-block;box-sizing:border-box;background-color:#f7f7f7;color:#303030;font-family:"Roboto Mono",monospace;vertical-align:baseline;font-size:14px;font-weight:bold;padding:2px 4px}#docsContent a code{color:#3371e3;text-decoration:underline}#docsContent pre .pi,#docsContent pre .s{margin:0;padding:0}#docsContent .highlight code span,#docsContent code,#docsContent pre code{font-family:"Roboto Mono",monospace}#docsContent code,#docsContent pre code{color:#303030}#docsContent pre code{padding:0}#docsContent pre{background-color:#f7f7f7;display:block;margin:20px 0;padding:15px;position:relative;overflow-x:auto}#docsContent h1 code,#docsContent h2 code,#docsContent h3 code,#docsContent h4 code,#docsContent h5 code,#docsContent h6 code{font-size:inherit;background-color:transparent}#docsContent .includecode{table-layout:fixed}#docsContent .includecode,#docsContent .includecode th,#docsContent .includecode td{padding:0 !important}#docsContent .includecode th{text-align:right !important;padding:10px !important}#docsContent .includecode th a,#docsContent .includecode th a code{color:#fff !important;background-color:transparent !important}#docsContent .includecode pre{margin:0 !important}#docsContent ul li{list-style:disc}#docsContent ol ul li{list-style:disc}#docsContent ol li{list-style:decimal}#docsContent ul,#docsContent ol{margin:20px 0;padding-left:30px;font-weight:300}#docsContent ul ul,#docsContent ol ol,#docsContent ul ol,#docsContent ol ul{margin:0.75em 0}#docsContent li{margin-bottom:0.75em;font-size:16px;line-height:1.75em}#docsContent table{width:100%;border:1px solid #ccc;border-spacing:0;margin-top:30px;margin-bottom:30px}#docsContent thead,#docsContent tr:nth-child(even){background-color:#f7f7f7}#docsContent thead{background-color:#555;color:#fff}#docsContent th,#docsContent td{padding:8px;text-align:left;margin:0}#docsContent th{font-weight:normal}#docsContent td{font-size:0.85em}#docsContent #editPageButton{position:absolute;top:-25px;right:5px;width:50px;height:50px;line-height:50px;border-radius:50%;white-space:nowrap;text-indent:50px;overflow:hidden;background:#3371e3 url(/images/icon-pencil.svg) no-repeat;background-position:12px 10px;background-size:29px 29px}#docsContent #markdown-toc,#docsContent #TableOfContents{margin-bottom:20px}#docsContent #markdown-toc ul,#docsContent #markdown-toc li,#docsContent #TableOfContents ul,#docsContent #TableOfContents li{list-style:disc;color:#3371e3}#docsContent #markdown-toc ul,#docsContent #TableOfContents ul{padding:0 15px;margin:0}#docsContent #markdown-toc li,#docsContent #TableOfContents li{padding:0;line-height:1.5em;margin-bottom:0}#docsContent #markdown-toc a,#docsContent #TableOfContents a{position:relative;color:#3371e3;font-weight:700}#docsContent img{max-width:100%}#docsContent #TableOfContents>ul>li{list-style:none}#docsContent #TableOfContents ul,#docsContent #TableOfContents li{list-style:disk}#docsContent a.button{border-radius:2px;text-decoration:none}#docsContent a.button:visited{color:#fff}#docsContent a.issue{margin-left:0px}.feedback--no{margin-left:1em}.feedback--prompt{margin-bottom:1em}.feedback--response{margin-top:1em}.feedback--button__disabled{background-color:#f7f7f7;color:graytext}.feedback--response__hidden{display:none}.fixed footer{position:fixed;bottom:0}#miceType{clear:both;font-size:11px;line-height:18px;color:#aaa}html.search #docsContent{position:relative;float:none;width:90%;max-width:850px;margin:0 auto}html.search #docsContent #editPageButton{display:none}html.search #docsContent table{border:0;margin-bottom:0}html.search #docsContent td{padding:0}html.search #docsContent h1{margin-bottom:0;border-bottom:0;padding-bottom:0;padding-left:8px}#home.flip-nav .logo,#home.open-nav .logo{background-image:url(/images/nav_logo2.svg)}#home #hero{margin-bottom:0;padding-bottom:1px}#home #hero main{padding:0 10px;margin-bottom:30px}#home #hero #vendorStrip{display:none}#oceanNodes{padding-top:60px;padding-bottom:60px}#oceanNodes a{color:#3371e3}#oceanNodes main{margin-bottom:60px;min-height:160px}#oceanNodes .image-wrapper{max-width:75%;margin:0 auto 20px;text-align:center}#oceanNodes .image-wrapper img{width:100%;max-width:160px}#oceanNodes main:first-child .image-wrapper{max-width:100%}#oceanNodes main:first-child .image-wrapper img{max-width:491px}#oceanNodes h3{margin-bottom:30px}#video{height:200px}#video{width:100%;position:relative;background-position:center center;background-size:cover}#video>.light-text{display:none;position:absolute;top:50%;left:75%;width:525px;padding-right:80px;transform:translate(-50%, -50%);color:#fff}#video h2{font-size:32px;line-height:44px;margin-bottom:20px}#video p{margin-bottom:20px}#video #desktopKCButton{position:relative;font-size:18px;background-color:#303030;border-radius:8px;color:#fff;padding:20px 10px 20px 10px}#video #desktopShowVideoButton{position:relative;font-size:24px;background-color:#fff;border-radius:8px;color:#3371e3;padding:15px 30px 15px 80px;margin-bottom:15px}#video #desktopShowVideoButton:before{content:"";position:absolute;position:absolute;top:50%;left:40px;transform:translate(-50%, -50%);width:0;height:0;border-style:solid;border-width:10px 0 10px 20px;border-color:transparent transparent transparent #3371e3}#video #mobileShowVideoButton{position:absolute;top:50%;left:50%;transform:translate(-50%, -50%);width:80px;height:80px;border-radius:50%;background-color:transparent;border:5px solid rgba(255,255,255,0.2);overflow:visible}#video #mobileShowVideoButton:after{position:absolute;top:50%;left:50%;transform:translate(-50%, -50%);left:40px;content:"";width:0;height:0;border-style:solid;border-width:20px 0 20px 30px;border-color:transparent transparent transparent #fff}#videoPlayer{position:fixed;top:0;left:0;width:100vw;height:100vh;background-color:rgba(0,0,0,0.9);display:none}#videoPlayer iframe{position:absolute;top:50%;left:50%;transform:translate(-50%, -50%);width:80vw;height:45vw;max-width:142.22222vh;max-height:80vh}#videoPlayer #closeButton{position:absolute;top:20px;right:20px;width:50px;height:50px;border:2px solid transparent;transition:0.3s}#videoPlayer #closeButton:before,#videoPlayer #closeButton:after{content:"";position:absolute;top:calc(50% - 1px);left:10%;width:80%;height:2px;background-color:#fff}#videoPlayer #closeButton:before{transform:rotate(45deg)}#videoPlayer #closeButton:after{transform:rotate(-45deg)}#videoPlayer #closeButton:hover{border-color:#fff}#cncf{padding-top:60px;padding-bottom:140px;background-image:url(/images/cncf-color.png);background-position:center 100px;background-repeat:no-repeat;background-size:300px}#kubeweekly{background-color:#f7f7f7;padding-top:60px;padding-bottom:140px;background-size:auto;font-family:"Roboto Mono",monospace !important;font-size:24px;font-weight:bold}#kubeweekly h5{font-size:20px}.subscribe-button{border-radius:6px;padding:0 20px;line-height:31px;color:#fff;background-color:blue;text-decoration:none;font-size:14px}#features{padding-top:140px;background-color:#f7f7f7;background-image:url(/images/wheel.png);background-position:center 60px;background-repeat:no-repeat;background-size:auto}.feature-box{width:100%;overflow:hidden;clear:both}.feature-box h4{line-height:normal;margin-bottom:15px}.feature-box>div:first-child{float:left}.feature-box>div:last-child{float:right}#features h3{margin-bottom:20px}#features .feature-box{margin-bottom:0}#features .feature-box>div{width:100%;margin-bottom:40px}#community.open-nav .logo,#community.flip-nav .logo,.gridPage.open-nav .logo,.gridPage.flip-nav .logo{background-image:url(/images/nav_logo2.svg)}#community #hero,.gridPage #hero{padding-bottom:20px}#community #mainContent,.gridPage #mainContent{padding:20px 0}#community #mainContent main,.gridPage #mainContent main{max-width:none}#community #mainContent a,.gridPage #mainContent a{color:#3371e3}#community #mainContent .content,.gridPage #mainContent .content{margin-bottom:30px;padding:30px 0}#community #mainContent .content h1,#community #mainContent .content h2,#community #mainContent .content h3,#community #mainContent .content h4,#community #mainContent .content h5,#community #mainContent .content h6,#community #mainContent .content p,.gridPage #mainContent .content h1,.gridPage #mainContent .content h2,.gridPage #mainContent .content h3,.gridPage #mainContent .content h4,.gridPage #mainContent .content h5,.gridPage #mainContent .content h6,.gridPage #mainContent .content p{line-height:normal;max-width:1200px;padding:0 20px;margin:0 auto 20px}#community #mainContent .content:nth-child(even),.gridPage #mainContent .content:nth-child(even){background-color:#f7f7f7}#community #mainContent .company-logos,.gridPage #mainContent .company-logos{text-align:center;max-width:1200px;margin:0 auto}#community #mainContent .company-logos img,.gridPage #mainContent .company-logos img{width:auto;margin:10px;background-color:#f7f7f7}#community #mainContent .partner-logos,.gridPage #mainContent .partner-logos{text-align:center;max-width:1200px;margin:0 auto}#community #mainContent .partner-logos img,.gridPage #mainContent .partner-logos img{width:auto;margin:10px;background-color:#fff;box-shadow:0 5px 5px rgba(0,0,0,0.24),0 0 5px rgba(0,0,0,0.12)}#community #mainContent #calendarMeetings,.gridPage #mainContent #calendarMeetings{position:relative;width:80vw;height:60vw;max-width:1200px;max-height:900px;margin:20px auto}#community #mainContent #calendarEvents,.gridPage #mainContent #calendarEvents{position:relative;width:80vw;height:30vw;max-width:1200px;max-height:450px;margin:20px auto}#community #mainContent iframe,.gridPage #mainContent iframe{position:absolute;border:0;width:100%;height:100%}.ui-icon{display:inline-block !important}#feature-state-dialog-link{text-decoration:none !important;padding:5px !important}#feature-state-dialog-link a:visited{color:#454545 !important}#feature-state-dialog-link a code{display:inline-block !important;box-sizing:border-box !important;background-color:#f7f7f7 !important;color:#303030 !important;font-family:"Roboto Mono",monospace !important;vertical-align:baseline !important;font-size:14px !important;font-weight:bold !important;padding:0px 4px !important}#feature-state-dialog{background:#fff !important;border:1px solid #ddd !important;padding:0.5em 1em !important}#feature-state-dialog ul,#feature-state-dialog li{list-style:disc !important;margin:4px 12px !important}#feature-state-dialog p{margin:8px 0px !important}#feature-state-dialog code{display:inline-block !important;box-sizing:border-box !important;background-color:#f7f7f7 !important;color:#303030 !important;font-family:"Roboto Mono",monospace !important;vertical-align:baseline !important;font-size:14px !important;font-weight:bold !important;padding:0px 4px !important}.ui-dialog{background:#f7f7f7 !important;padding:0.5em}.ui-dialog-content{position:relative;float:right;width:100%}.ui-dialog-content *+h2,.ui-dialog-content *+h3,.ui-dialog-content *+h4,.ui-dialog-content *+h5,.ui-dialog-content *+h6{margin-top:30px}.ui-dialog-content h1,.ui-dialog-content h2,.ui-dialog-content h3,.ui-dialog-content h4,.ui-dialog-content h5,.ui-dialog-content h6{line-height:normal;font-weight:500;margin-bottom:30px;padding-bottom:10px}.ui-dialog-content h1:before,.ui-dialog-content h2:before,.ui-dialog-content h3:before,.ui-dialog-content h4:before,.ui-dialog-content h5:before,.ui-dialog-content h6:before{display:block;content:" ";margin-top:-100px;height:100px;visibility:hidden}.ui-dialog-content h1,.ui-dialog-content h2{border-bottom:1px solid #ccc}.ui-dialog-content h1{font-size:32px;padding-right:60px}.ui-dialog-content h2{font-size:28px}.ui-dialog-content h3{font-size:24px;font-weight:300;margin-bottom:5px}.ui-dialog-content h4{font-size:20px;margin-bottom:0px}.ui-dialog-content h5,.ui-dialog-content h6{font-size:16px;font-weight:500}.ui-dialog-content p{font-size:16px;font-weight:300;line-height:1.75em}.ui-dialog-content p+p{margin-top:10px}.ui-dialog-content code{display:inline-block;box-sizing:border-box;background-color:#f7f7f7;color:#303030;font-family:"Roboto Mono",monospace;vertical-align:baseline;font-size:14px;font-weight:bold;padding:2px 4px}.ui-dialog-content a code{color:#3371e3;text-decoration:underline}.ui-dialog-content pre .pi,.ui-dialog-content pre .s{margin:0;padding:0}.ui-dialog-content .highlight code span,.ui-dialog-content code,.ui-dialog-content pre code{font-family:"Roboto Mono",monospace}.ui-dialog-content code,.ui-dialog-content pre code{color:#303030}.ui-dialog-content pre code{padding:0}.ui-dialog-content pre{background-color:#f7f7f7;display:block;margin:20px 0;padding:15px;position:relative;overflow-x:auto}.ui-dialog-content h1 code,.ui-dialog-content h2 code,.ui-dialog-content h3 code,.ui-dialog-content h4 code,.ui-dialog-content h5 code,.ui-dialog-content h6 code{font-family:inherit;font-size:inherit;background-color:transparent}.ui-dialog-content .includecode{table-layout:fixed}.ui-dialog-content .includecode,.ui-dialog-content .includecode th,.ui-dialog-content .includecode td{padding:0 !important}.ui-dialog-content .includecode th{text-align:right !important;padding:10px !important}.ui-dialog-content .includecode th a,.ui-dialog-content .includecode th a code{color:#fff !important;background-color:transparent !important}.ui-dialog-content .includecode pre{margin:0 !important}.ui-dialog-content ul li{list-style:disc}.ui-dialog-content ol li{list-style:decimal}.ui-dialog-content ul,.ui-dialog-content ol{margin:20px 0;padding-left:30px;font-weight:300}.ui-dialog-content ul ul,.ui-dialog-content ol ol,.ui-dialog-content ul ol,.ui-dialog-content ol ul{margin:0.75em 0}.ui-dialog-content li{margin-bottom:0.75em;font-size:16px;line-height:1.75em}.ui-dialog-content table{width:100%;border:1px solid #ccc;border-spacing:0;margin-top:30px;margin-bottom:30px}.ui-dialog-content thead,.ui-dialog-content tr:nth-child(even){background-color:#f7f7f7}.ui-dialog-content thead{background-color:#555;color:#fff}.ui-dialog-content th,.ui-dialog-content td{padding:8px;text-align:left;margin:0}.ui-dialog-content th{font-weight:normal}.ui-dialog-content td{font-size:0.85em}.ui-dialog-content #editPageButton{position:absolute;top:-25px;right:5px;width:50px;height:50px;line-height:50px;border-radius:50%;white-space:nowrap;text-indent:50px;overflow:hidden;background:#3371e3 url(/images/icon-pencil.svg) no-repeat;background-position:12px 10px;background-size:29px 29px}.ui-dialog-content #markdown-toc{margin-bottom:20px}.ui-dialog-content #markdown-toc ul,.ui-dialog-content #markdown-toc li{list-style:disc;color:#3371e3}.ui-dialog-content #markdown-toc ul{padding:0 15px;margin:0}.ui-dialog-content #markdown-toc li{padding:0;line-height:1.5em;margin-bottom:0}.ui-dialog-content #markdown-toc a{position:relative;color:#3371e3;font-weight:700}.ui-dialog-content img{max-width:100%}.ui-dialog-content a{text-decoration:underline}.ui-dialog-content a.button{border-radius:2px;text-decoration:none}.ui-dialog-content a.button:visited{color:#fff}.ui-dialog-content a.issue{margin-left:0px}.ui-dialog-buttonpane{background:#f7f7f7 !important}.ui-widget-header{background:transparent !important;background-color:transparent !important;border:0px !important}.ui-tabs ul,.ui-tabs ol,.ui-tabs li{padding:0px !important;list-style:none !important;margin-bottom:0px !important;margin-left:4px !important}.ui-tabs-panel ul li{list-style:disc !important}.ui-tabs-panel ol li{list-style:decimal !important}.ui-widget-content{border:0px !important}.ui-widget-content p a{color:#3371e3}.ui-widget-content table{margin:0px !important}.ui-tabs .ui-tabs-panel{border:1px solid #ccc !important}.ui-tabs-anchor{text-decoration:none !important}#talkToUs h3,#talkToUs h4{text-align:center}#talkToUs h3{margin-bottom:15px}#talkToUs h4{line-height:normal;margin-bottom:50px}#talkToUs h4 br{display:none}#talkToUs #bigSocial{overflow:hidden}#talkToUs #bigSocial div{width:100%;float:left;padding:30px;padding-top:110px;background-position:center top;background-size:auto;background-repeat:no-repeat}#talkToUs #bigSocial div:nth-child(1){background-image:url(/images/twitter_icon.png)}#talkToUs #bigSocial div:nth-child(2){background-image:url(/images/github_icon.png)}#talkToUs #bigSocial div:nth-child(3){background-image:url(/images/slack_icon.png)}#talkToUs #bigSocial div:nth-child(4){background-image:url(/images/stackoverflow_icon.png)}#talkToUs #bigSocial div+div{margin-top:20px;margin-left:0}#talkToUs #bigSocial a{display:inline-block;color:#3371e3;font-size:24px;font-weight:400;text-decoration:none;margin-bottom:15px}#talkToUs #bigSocial a,#talkToUs #bigSocial p{text-align:center;width:100%}#home #talkToUs main{padding:30px 0}#home #talkToUs h5{font-size:20px}#home #caseStudiesWrapper{position:relative;text-align:center;margin-bottom:30px}#home #caseStudiesWrapper img{padding-bottom:1rem}#home #caseStudiesWrapper div{position:relative;display:inline-block;vertical-align:top;width:100%;min-height:230px;margin-bottom:60px;padding-right:1rem;background-position:top center}#home #caseStudiesWrapper p{font-size:20px}#home #caseStudiesWrapper a{position:absolute;bottom:-30px;left:50%;transform:translateX(-50%);color:#3371e3;font-weight:400}.cse .gsc-control-cse,.gsc-control-cse{padding:0}.gsc-control-cse table,.gsc-control-cse-en table{margin:0px !important}.gsc-above-wrapper-area{border-bottom:0}#bing-results-container{margin-top:30px;margin-left:20px}.bing-result{margin-bottom:20px}.bing-result-name a{font-size:16px;color:#00c}.bing-result-url{color:green;font-size:13px}.bing-result-snippet{color:#000;font-size:11px}#bing-pagination-container{margin:10px;margin-left:20px}.bing-page-anchor{text-decoration:none !important;cursor:pointer;color:#00c;margin-right:8px}.page{display:flex;flex-direction:column;min-height:100vh}.page .page-content{flex:1}.container-404{text-align:center;margin:3.5rem 0}.container-404 ul li a{font-size:1.5rem}#pre-footer{margin-top:2rem}#pre-footer .button{font-size:1.1rem}#pre-footer .button:first-of-type{margin-right:0.75rem}#pre-footer .lastedit{margin-top:1rem;font-size:1rem}hr{background-color:#999}h2{margin-bottom:15px !important}.subhead{padding-bottom:2% !important;padding-top:0% !important}.details{margin-left:1.9%;padding-right:5%;font-size:16px !important;padding-bottom:2% !important}.section1{margin-bottom:3%}.section1 .cols{width:80% !important;margin-left:6.8%;padding-top:1.5%}.section1 .cols .col1{width:52% !important;font-weight:300 !important}.section1 .cols .col2{width:46% !important}.banner2text{width:63%;padding-top:10%;padding-left:0% !important;float:initial !important;text-align:center;margin:0 auto;position:relative}.banner3text,.banner4text,.banner5text{width:63%;padding-left:0% !important;float:initial !important;text-align:center;margin:0 auto;position:relative}.fullcol{float:initial !important}body footer{background-color:#585858 !important}.section1{float:left !important}.banner1{padding-left:11.9% !important}.banner2{float:initial !important;padding-bottom:2% !important}footer{padding:0% 7%}.banner4,.banner3,.banner5{float:initial !important}@media screen and (max-width: 910px){.banner2text{width:47%;padding-top:45%}.details{margin-left:0%;margin-bottom:3%}.subhead{padding-bottom:0% !important;padding-top:0% !important}.banner3{width:100% !important}}@media screen and (max-width: 780px){.section1 .cols{width:100% !important;margin-left:0%;padding-top:5%}.section1 .cols .col1,.section1 .cols .col2{width:100% !important;margin-left:0% !important}.fullcol{width:90% !important;margin-left:5% !important}.banner1{padding-left:10% !important;margin-bottom:6% !important}.banner2text{padding-top:60% !important;padding-bottom:2% !important}}@media screen and (min-width: 750px){h1{font-size:32px;line-height:40px}h2{font-size:28px;line-height:60px}h3{font-size:24px;line-height:32px}h4{font-size:20px;line-height:40px}h5{font-size:16px;line-height:36px}p{font-size:14px;line-height:22px}section,header,#vendorStrip{padding-left:20px;padding-right:20px}section main,header main,#vendorStrip main{width:100%;max-width:100%}header{height:80px}.nav-buttons{height:80px;line-height:80px}.nav-buttons .button+*{margin-left:30px}#hamburger{width:50px;height:50px}#mainNav{padding:140px 0 30px}#mainNav h5{margin-bottom:1em}#mainNav h3{margin-bottom:0.6em}#mainNav .nav-box{width:20%}#mainNav .nav-box+.nav-box{margin-left:calc(20% / 3)}#mainNav main+main{margin-top:60px}#mainNav .left .button{height:50px;line-height:50px;font-size:18px}.open-nav #tryKubernetes,.y-enough #tryKubernetes{margin-left:30px}#hero{padding-top:80px}#docs #hero h1,#docs #hero h5{padding-left:20px;padding-right:20px}#vendorStrip{height:88px;line-height:88px;font-size:16px}p{font-size:16px;line-height:24px;letter-spacing:0.1px}h1{font-size:36px;line-height:44px}h3{font-size:28px;line-height:36px}h4{font-size:24px;line-height:40px}#home #viewDocs,#home #tryKubernetes{display:inline-block}#vendorStrip{display:block;text-align:center}#vendorStrip img{max-height:24px;vertical-align:middle;margin:0 30px}#docs #vendorStrip li a{font-size:1em;font-weight:normal}#docs #vendorStrip li li+li{margin-left:60px}#oceanNodes h3{text-align:left;margin-bottom:18px}#oceanNodes main{position:relative;clear:both;display:table;height:160px}#oceanNodes main .content{display:table-cell;position:relative;vertical-align:middle}#oceanNodes main .image-wrapper{position:absolute;top:50%;max-width:25%;max-height:100%;transform:translateY(-50%)}#oceanNodes main:nth-child(odd){padding-right:210px}#oceanNodes main:nth-child(odd) .image-wrapper{right:0}#oceanNodes main:nth-child(even){padding-left:210px}#oceanNodes main:nth-child(even) .image-wrapper{left:0}#oceanNodes main:nth-child(1){padding-right:0}#oceanNodes main:nth-child(1) h3,#oceanNodes main:nth-child(1) p{text-align:center}#oceanNodes main:nth-child(1) .image-wrapper{position:relative;display:block;float:none;max-width:100%;transform:none}#oceanNodes main:nth-child(1) .content{display:block}#oceanNodes main img{width:100%}#video{height:400px;display:block}#video>.light-text{display:block}#mobileShowVideoButton{display:none}#features{padding-bottom:60px}#features .feature-box{margin-bottom:30px}#features .feature-box:last-child{margin-bottom:0}#features h3{margin-bottom:40px}#features .feature-box>div{width:45%;margin-bottom:0}#talkToUs #bigSocial div{width:calc(50% - 15px)}#talkToUs #bigSocial div+div{margin-top:0}#talkToUs #bigSocial div:nth-child(2){margin-left:20px}#talkToUs #bigSocial div:nth-child(4){margin-left:20px}#talkToUs #bigSocial a{display:inline-block;color:#3371e3;font-weight:400;text-decoration:none}footer nav{text-align:center}footer nav a{width:30%;padding:0 20px}footer .social{text-align:center}footer .social div{display:inline-block}footer .social div:last-child{display:block;margin:0}footer .social span{display:inline-block;margin-right:10px}footer .social input{text-align:left}#home #caseStudiesWrapper div{width:48%}}@media screen and (min-width: 1025px){#hamburger{display:none}ul.global-nav{display:inline-block}#docs #vendorStrip #searchBox:before{top:15px}#vendorStrip{height:44px;line-height:44px}#vendorStrip li a.YAH:after{content:"";display:block;position:absolute;left:0;bottom:0;width:100%;height:4px;background-color:#3371e3}#vendorStrip #searchBox{float:right}#home #hero #vendorStrip{display:block}#docs #hero h1,#docs #hero h5{text-align:left}#docs #hero #vendorStrip ul{float:left}#docs #hero #vendorStrip #searchBox{float:right;width:250px}#docs #hero #vendorStrip #search{vertical-align:middle}#docs .flyout-button{display:none}#docs .logo{position:relative;float:left;display:block;width:180px;height:88px;top:0;left:0;transform:none;background-image:url(../images/nav_logo.svg)}#docs.flip-nav .logo,#docs.open-nav .logo{background-image:url(../images/nav_logo2.svg)}#encyclopedia{padding:50px 50px 100px 100px;clear:both}#docsToc{position:relative;float:left;padding:0 20px;left:0;width:350px;z-index:auto}#docsToc .push-menu-close-button{display:none}#docsContent{width:calc(100% - 400px)}#docsContent #editPageButton{right:-25px}section main,header main,footer main{max-width:1200px}header,#vendorStrip,#encyclopedia,#hero h1,#hero h5,#docs #hero h1,#docs #hero h5,#community #hero h1,.gridPage #hero h1,#community #hero h5,.gridPage #hero h5{padding-left:100px;padding-right:100px}#vendorStrip{padding-right:10px}#home section main,#home header main,#home footer main{max-width:1000px}#oceanNodes main{position:relative;max-width:830px}#oceanNodes main:nth-child(1){max-width:1000px;padding-right:475px}#oceanNodes main:nth-child(1) h3,#oceanNodes main:nth-child(1) p{text-align:left}#oceanNodes main:nth-child(1) .image-wrapper{position:absolute;max-width:48%;transform:translateY(-50%)}#oceanNodes main:nth-child(1) .image-wrapper img{max-width:425px}#video{height:550px;position:relative;background-position:center center;background-size:cover}#talkToUs h4 br{display:block}#talkToUs #bigSocial div{width:calc(25% - 18px)}#talkToUs #bigSocial div+div{margin-left:20px}footer{width:100%;background-image:url(../images/texture.png);background-color:#303030}footer main{padding:20px 0}footer nav{overflow:hidden;margin-bottom:20px}footer nav a{width:16.65%;float:left;font-size:24px;font-weight:300;white-space:nowrap}footer .social{padding:0 30px;max-width:1200px}footer .social div{float:left}footer .social div:last-child{float:right}#search,#wishField{background-color:transparent;padding:10px;font-size:16px;font-weight:100;color:#fff;border:1px solid #fff;transition:0.3s}#search:focus,#wishField:focus{background-color:#f7f7f7;color:#303030}.social a{display:inline-block;background-image:url(../images/social_sprite.png);background-repeat:no-repeat;background-size:auto;width:50px;height:50px;border-radius:5px;margin-right:10px}.social a:hover{background-color:#fff}.social a span{position:absolute;display:block;height:0;overflow:hidden}a.twitter{background-position:0 0}a.twitter:hover{background-position:0 100%}a.stack-overflow{background-position:-50px 0}a.stack-overflow:hover{background-position:-50px 100%}a.slack{background-position:-100px 0}a.slack:hover{background-position:-100px 100%}a.github{background-position:-150px 0}a.github:hover{background-position:-150px 100%}a.mailing-list{background-position:-200px 0}a.mailing-list:hover{background-position:-200px 100%}a.calendar{background-position:-250px 0}a.calendar:hover{background-position:-250px 100%}#community #hero,.gridPage #hero{text-align:left}#community #hero h1,.gridPage #hero h1{padding:20px 100px}#community #tryKubernetes,.gridPage #tryKubernetes{width:auto;background-color:#3371e3;padding:0 20px}#bigSocial div{width:calc(25% - 18px)}#home #caseStudiesWrapper div{width:24%;min-height:260px}}@media screen and (min-width: 1300px){#vendorStrip{padding-right:100px}}@media screen and (min-width: 456px){#vendorStrip li+li{margin-left:20px}} diff --git a/static/css/styles.css b/static/css/styles.css index 62020d68de..158a3a27f2 100644 --- a/static/css/styles.css +++ b/static/css/styles.css @@ -1,2 +1 @@ -html,body{margin:0;padding:0}input,button{outline:none}button{cursor:pointer}ul,li{list-style:none}ul{margin:0;padding:0}a{text-decoration:none}.clear{display:block;clear:both}.light-text{color:#fff}.right{float:right}.left{float:left}.center{text-align:center}*,.button{box-sizing:border-box;font-family:"Roboto",sans-serif;background:none;margin:0;border:0}body{font-family:"Roboto",sans-serif}h1,h2,h5,p{font-weight:300}h3,h4{font-weight:400}html,body{margin:0;padding:0}input,button{outline:none}button{cursor:pointer}ul,li{list-style:none}ul{margin:0;padding:0}a{text-decoration:none}.clear{display:block;clear:both}.light-text{color:#fff}.right{float:right}.left{float:left}.center{text-align:center}h1{font-size:32px;line-height:40px}h2{font-size:28px;line-height:60px}h3{font-size:24px;line-height:32px}h4{font-size:20px;line-height:40px}h5{font-size:16px;line-height:36px}p{font-size:14px;line-height:22px}section,header,#vendorStrip{padding-left:20px;padding-right:20px}section main,header main,#vendorStrip main{width:100%;max-width:100%}header{height:80px}.nav-buttons{height:80px;line-height:80px}.nav-buttons .button+*{margin-left:30px}#hamburger{width:50px;height:50px}#mainNav{padding:140px 0 30px}#mainNav h5{margin-bottom:1em}#mainNav h3{margin-bottom:.6em}#mainNav .nav-box{width:20%}#mainNav .nav-box+.nav-box{margin-left:calc(20% / 3)}#mainNav main+main{margin-top:60px}#mainNav .left .button{height:50px;line-height:50px;font-size:18px}.open-nav #tryKubernetes,.y-enough #tryKubernetes{margin-left:30px}#hero{padding-top:80px}#docs #hero h1,#docs #hero h5{padding-left:20px;padding-right:20px}#vendorStrip{height:88px;line-height:88px;font-size:16px}body{background-color:#fff}section{position:relative;background-color:#fff}section main,header main,footer main{position:relative;margin:auto}p{font-size:14px;font-weight:400}.button{display:inline-block;border-radius:6px;padding:0 20px;line-height:40px;color:#fff;background-color:#3371e3;text-decoration:none;font-size:1rem}#cellophane{position:fixed;top:0;left:0;width:100%;height:100%;display:none}header{position:fixed;top:0;left:0;width:100%;z-index:8888;background-color:transparent;box-shadow:0 0 0 transparent;overflow:hidden;transition:.3s;text-align:center}.logo{position:relative;float:left;display:block;width:180px;height:88px;top:0;left:0;transform:none;background-image:url(/images/nav_logo.svg);background-size:contain;background-position:center center;background-repeat:no-repeat}.blog-content table{max-width:100%;border:1px solid #ccc;border-spacing:0;margin-top:30px;margin-bottom:30px}.blog-content table thead{border-bottom:2px solid #ccc}.blog-content table thead tr th{padding:.5rem;font-size:1.5rem}.blog-content table tbody tr td{padding:.5rem;border-bottom:1px solid #ccc;border-left:1px solid #ccc;padding-right:5rem}#docs .flyout-button{position:fixed;top:20px;left:20px;width:50px;height:50px;background-image:url(/images/toc_icon.png);background-position:center center;background-repeat:no-repeat;background-size:auto;border-radius:50%;transition:.3s;z-index:99999}#docs.open-nav .flyout-button{display:none}#docs .logo{position:absolute;top:40px;left:50%;transform:translate(-50%, -50%);display:block;width:45px;height:44px;background-image:url(/images/favicon.png)}#docs.flip-nav .flyout-button{background-image:url(/images/toc_icon_grey.png)}.nav-buttons{float:right}#viewDocs,#tryKubernetes{display:none}#viewDocs{border:2px solid #fff;background-color:transparent;transition:.3s}#viewDocs:hover{background-color:#fff;color:#303030}#tryKubernetes{width:0;padding:0 0;border:1px solid transparent;background-color:transparent;text-align:center;white-space:nowrap;vertical-align:middle;overflow:hidden;transition:.3s}#hamburger{display:inline-block;position:relative;vertical-align:middle;padding:0;border:0;background:none}#hamburger div,#hamburger:before,#hamburger:after{position:absolute;left:15%;width:70%;height:2px;background-color:#3371e3;transition:.3s;content:""}#hamburger div{top:calc(50% - 1px)}#hamburger:before{top:24%}#hamburger:after{bottom:24%}#hamburger:hover div,#hamburger:hover:before,#hamburger:hover:after{background-color:#fff}#mainNav h5{color:#3371e3;font-weight:normal}#mainNav main{white-space:nowrap;overflow:hidden;clear:both}#mainNav .nav-box{float:left;white-space:normal}#mainNav h3 a{color:#3371e3;text-decoration:none}ul.global-nav{display:none}ul.global-nav li{display:inline-block;margin-right:14px}ul.global-nav li a{color:#fff;font-weight:400;padding:0;position:relative}ul.global-nav li a.active:after{position:absolute;width:100%;height:2px;content:"";bottom:-4px;left:0;background:#fff}ul.global-nav li a .ui-icon{filter:brightness(0) invert(1)}ul.global-nav li ul{display:none;position:fixed;top:40px;text-align:left}ul.global-nav li ul li{display:block;height:28px}ul.global-nav li ul li a{background:#303030;color:#fff;padding:7px}ul.global-nav li ul li:last-child a{border-radius:7px}ul.global-nav li:hover ul{display:block}.flip-nav ul.global-nav li a,.open-nav ul.global-nav li a{color:#303030}.flip-nav ul.global-nav li a .ui-icon,.open-nav ul.global-nav li a .ui-icon{filter:brightness(0)}.flip-nav ul.global-nav li ul li a{background:#fff;color:#303030}.flip-nav ul.global-nav li a.active:after,.flip-nav ul.global-nav li ul li a.active:after,.open-nav ul.global-nav li a.active:after{background:#3371e3}.flip-nav header{background-color:#fff}.open-nav body{overflow:hidden}.open-nav #cellophane{display:block;z-index:9998}.open-nav header{background-color:#e8e8e8;z-index:9999}.open-nav #hamburger div{opacity:0}.open-nav #hamburger:before,.open-nav #hamburger:after{left:12px;transform-origin:0 1px}.open-nav #hamburger:before{transform:rotate(45deg)}.open-nav #hamburger:after{transform:rotate(-45deg)}.open-nav #tryKubernetes,.y-enough #tryKubernetes{width:auto;padding:0 20px;background-color:#3371e3;border-color:#3371e3}.flip-nav header,.open-nav header{box-shadow:0 1px 2px #4c4c4c}.flip-nav #viewDocs,.open-nav #viewDocs{border-color:#303030;color:#303030}.flip-nav #viewDocs:hover,.open-nav #viewDocs:hover{border-color:#3371e3;background-color:#3371e3;color:#fff}.flip-nav #hamburger:hover div,.flip-nav #hamburger:hover:before,.flip-nav #hamburger:hover:after,.open-nav #hamburger:hover div,.open-nav #hamburger:hover:before,.open-nav #hamburger:hover:after{background-color:#303030}#hero{background-image:url(/images/texture.png);background-color:#303030;text-align:center;padding-left:0;padding-right:0;margin-bottom:0;position:relative}#hero.bot-bar:after{display:block;margin-bottom:-20px;height:8px;width:100%;background-color:rgba(255,255,255,0.1);content:""}#hero.no-sub h5{display:none}#hero.no-sub h1{margin-bottom:20px}#home #hero:after{display:none}#vendorStrip{position:relative;background-color:rgba(255,255,255,0.1);font-weight:100;white-space:nowrap;text-align:center}#vendorStrip li a{color:rgba(255,255,255,0.5)}#vendorStrip li a.YAH{color:#fff;position:relative}footer{width:100%;background-image:url(/images/texture.png);background-color:#303030}footer main{padding:20px 0}footer nav a{width:100%;text-align:center;display:inline-block;margin:10px 0;font-size:24px;font-weight:300;color:#fff;text-decoration:none}footer .social{margin:20px 0}footer .social div{text-align:center;margin-bottom:20px}footer .social div:last-child{margin:30px 0}footer .social span{display:block;margin-bottom:8px}footer .social input{text-align:center}#search,#wishField{background-color:transparent;padding:10px;font-size:16px;font-weight:100;color:#fff;border:1px solid #fff;transition:.3s}#search:focus,#wishField:focus{background-color:#f7f7f7;color:#303030}.social a{display:inline-block;background-image:url(/images/social_sprite.png);background-repeat:no-repeat;background-size:auto;width:50px;height:50px;border-radius:5px;margin-right:10px}.social a:hover{background-color:#fff}.social a span{position:absolute;display:block;height:0;overflow:hidden}.social a.button{background-image:none;width:auto;height:auto}.social a.button:hover{color:#3371e3}a.twitter{background-position:0 0}a.twitter:hover{background-position:0 100%}a.stack-overflow{background-position:-50px 0}a.stack-overflow:hover{background-position:-50px 100%}a.slack{background-position:-100px 0}a.slack:hover{background-position:-100px 100%}a.github{background-position:-150px 0}a.github:hover{background-position:-150px 100%}a.mailing-list{background-position:-200px 0}a.mailing-list:hover{background-position:-200px 100%}a.calendar{background-position:-250px 0}a.calendar:hover{background-position:-250px 100%}#viewDocs{display:none}section{background-color:#fff}#hero{background-color:#303030}#hero h5{margin:20px 0;line-height:28px}#vendorStrip{position:relative}#vendorStrip ul{float:left}#vendorStrip li{display:inline-block;height:100%}#vendorStrip a{display:block;height:100%;color:#fff;font-size:.75em;font-weight:bold}#vendorStrip li+li{margin-left:0}#docs #vendorStrip{line-height:44px;max-width:100%;overflow-x:auto;-webkit-overflow-scrolling:touch}#docs #vendorStrip ul{float:none}#docs #vendorStrip #searchBox{float:none;display:block;width:80%;margin:0 auto;height:44px;line-height:44px;position:relative}#docs #vendorStrip #searchBox:before{position:absolute;width:15px;height:15px;content:"";right:8px;top:7px;background-image:url(/images/search-icon.svg);background-repeat:no-repeat;background-size:100% 100%;z-index:1}#docs #vendorStrip #search{width:100%;padding:0 10px;height:30px;line-height:30px;font-size:16px;vertical-align:top;background:#fff;border:none;border-radius:4px;position:relative}#encyclopedia{position:relative;padding:50px 20px 20px 20px;overflow:hidden;font-size:14px}#encyclopedia>div{height:100%}#docsToc{position:fixed;background-color:#fff;top:0;left:0;width:0;height:100vh;overflow:hidden;padding:50px 0;z-index:999999;transition:.3s}#docsToc .yah>.title{background-color:#f7f7f7;border-left:3px solid #3371e3;padding:7.5px 10px 7.5px 18px;margin-left:-3px;color:#3371e3}.open-toc body{overflow:hidden}.open-toc #docsToc{padding:50px 20px;width:400px;max-width:100vw;overflow-y:auto}.pi-accordion>.container:first-child>.item:first-child>.title:first-child{padding-left:0;font-size:1.5em;font-weight:700}.pi-accordion>.container:first-child>.item.yah:first-child>.title:first-child{margin-left:-20px !important}.pi-accordion .item{overflow:hidden}.pi-accordion .title{color:#303030;position:relative;padding:7.5px 10px 7.5px 18px;cursor:pointer;transition:.3s}.pi-accordion .title:hover{color:#3371e3}.pi-accordion a.item>.title{color:#000}.pi-accordion a.item>.title:hover{color:#3371e3}.pi-accordion div.item>.title:before{content:"";position:absolute;top:12px;left:2px;border-style:solid;border-width:5px 0 5px 8px;border-color:transparent transparent transparent #3371e3;transform:rotate(0deg);transition:.3s}.pi-accordion .wrapper{position:relative;width:100%;transition:height .3s}.pi-accordion .content{padding-left:20px;opacity:0;transition:.3s}.pi-accordion .item.on>.title:before{transform:rotate(90deg)}.pi-accordion .item.on>.wrapper>.content{opacity:1}dt{margin-bottom:8px}dd{margin-bottom:16px}.pi-pushmenu{display:none;position:fixed;top:0;width:100%;height:100%;opacity:0;transition:opacity .3s}.pi-pushmenu.on{opacity:1}.pi-pushmenu .overlay{position:fixed;top:0;left:0;width:100%;height:100%;background-color:rgba(0,0,0,0.4)}.pi-pushmenu .sled{position:absolute;top:0;width:0;height:100%;background-color:#fff;overflow:auto;transition:.3s}.pi-pushmenu.on .sled{width:400px;max-width:100vw}.pi-pushmenu .top-bar{height:0;line-height:60px;background-color:#444}.pi-pushmenu ul{margin-top:25px}.pi-pushmenu li{position:relative;display:block;width:100%;min-height:45px;padding:0 60px 0 20px;border-bottom:1px solid #ccc}.pi-pushmenu a{display:inline-block;width:100%;height:45px;line-height:45px;font-family:"Roboto",sans-serif;font-size:20px;color:#3371e3}.pi-pushmenu .button{background:none;padding:0}.pi-pushmenu ul ul{padding:0 20px}.pi-pushmenu ul ul li{min-height:40px}.pi-pushmenu ul ul a{height:40px;line-height:40px;font-size:18px;color:#555}.push-menu-close-button{position:absolute;top:0;right:0;width:50px;height:50px}.push-menu-close-button:before,.push-menu-close-button:after{content:"";position:absolute;top:calc(50% - 1px);left:25%;width:50%;height:2px;background-color:#000}.push-menu-close-button:before{transform:rotate(45deg)}.push-menu-close-button:after{transform:rotate(-45deg)}#docsContent{position:relative;float:right;width:100%}#docsContent *+h2,#docsContent *+h3,#docsContent *+h4,#docsContent *+h5,#docsContent *+h6{margin-top:30px}#docsContent h1,#docsContent h2,#docsContent h3,#docsContent h4,#docsContent h5,#docsContent h6{line-height:normal;font-weight:500;margin-bottom:30px;padding-bottom:10px}#docsContent h1:before,#docsContent h2:before,#docsContent h3:before,#docsContent h4:before,#docsContent h5:before,#docsContent h6:before{display:block;content:" ";margin-top:-100px;height:100px;visibility:hidden}#docsContent h1,#docsContent h2{border-bottom:1px solid #ccc}#docsContent h1{font-size:32px;padding-right:60px}#docsContent h2{font-size:28px}#docsContent h3{font-size:24px;font-weight:300;margin-bottom:5px}#docsContent h4{font-size:20px;margin-bottom:0px}#docsContent h5,#docsContent h6{font-size:16px;font-weight:500}#docsContent p{font-size:16px;font-weight:300;line-height:1.75em}#docsContent p+p{margin-top:10px}#docsContent code{display:inline-block;box-sizing:border-box;background-color:#f7f7f7;color:#303030;font-family:"Roboto Mono",monospace;vertical-align:baseline;font-size:14px;font-weight:bold;padding:2px 4px}#docsContent a code{color:#3371e3;text-decoration:underline}#docsContent pre .pi,#docsContent pre .s{margin:0;padding:0}#docsContent .highlight code span,#docsContent code,#docsContent pre code{font-family:"Roboto Mono",monospace}#docsContent code,#docsContent pre code{color:#303030}#docsContent pre code{padding:0}#docsContent pre{background-color:#f7f7f7;display:block;margin:20px 0;padding:15px;position:relative;overflow-x:auto}#docsContent h1 code,#docsContent h2 code,#docsContent h3 code,#docsContent h4 code,#docsContent h5 code,#docsContent h6 code{font-size:inherit;background-color:transparent}#docsContent .includecode{table-layout:fixed}#docsContent .includecode,#docsContent .includecode th,#docsContent .includecode td{padding:0 !important}#docsContent .includecode th{text-align:right !important;padding:10px !important}#docsContent .includecode th a,#docsContent .includecode th a code{color:#fff !important;background-color:transparent !important}#docsContent .includecode pre{margin:0 !important}#docsContent ul li{list-style:disc}#docsContent ol ul li{list-style:disc}#docsContent ol li{list-style:decimal}#docsContent ul,#docsContent ol{margin:20px 0;padding-left:30px;font-weight:300}#docsContent ul ul,#docsContent ol ol,#docsContent ul ol,#docsContent ol ul{margin:.75em 0}#docsContent li{margin-bottom:.75em;font-size:16px;line-height:1.75em}#docsContent table{width:100%;border:1px solid #ccc;border-spacing:0;margin-top:30px;margin-bottom:30px}#docsContent thead,#docsContent tr:nth-child(even){background-color:#f7f7f7}#docsContent thead{background-color:#555;color:#fff}#docsContent th,#docsContent td{padding:8px;text-align:left;margin:0}#docsContent th{font-weight:normal}#docsContent td{font-size:.85em}#docsContent #editPageButton{position:absolute;top:-25px;right:5px;width:50px;height:50px;line-height:50px;border-radius:50%;white-space:nowrap;text-indent:50px;overflow:hidden;background:#3371e3 url(/images/icon-pencil.svg) no-repeat;background-position:12px 10px;background-size:29px 29px}#docsContent #markdown-toc,#docsContent #TableOfContents{margin-bottom:20px}#docsContent #markdown-toc ul,#docsContent #markdown-toc li,#docsContent #TableOfContents ul,#docsContent #TableOfContents li{list-style:disc;color:#3371e3}#docsContent #markdown-toc ul,#docsContent #TableOfContents ul{padding:0 15px;margin:0}#docsContent #markdown-toc li,#docsContent #TableOfContents li{padding:0;line-height:1.5em;margin-bottom:0}#docsContent #markdown-toc a,#docsContent #TableOfContents a{position:relative;color:#3371e3;font-weight:700}#docsContent img{max-width:100%}#docsContent #TableOfContents>ul>li{list-style:none}#docsContent #TableOfContents ul,#docsContent #TableOfContents li{list-style:disk}#docsContent a.button{border-radius:2px;text-decoration:none}#docsContent a.button:visited{color:#fff}#docsContent a.issue{margin-left:0px}.feedback--no{margin-left:1em}.feedback--prompt{margin-bottom:1em}.feedback--response{margin-top:1em}.feedback--button__disabled{background-color:#f7f7f7;color:graytext}.feedback--response__hidden{display:none}.fixed footer{position:fixed;bottom:0}#miceType{clear:both;font-size:11px;line-height:18px;color:#aaa}html.search #docsContent{position:relative;float:none;width:90%;max-width:850px;margin:0 auto}html.search #docsContent #editPageButton{display:none}html.search #docsContent table{border:0;margin-bottom:0}html.search #docsContent td{padding:0}html.search #docsContent h1{margin-bottom:0;border-bottom:0;padding-bottom:0;padding-left:8px}#home.flip-nav .logo,#home.open-nav .logo{background-image:url(/images/nav_logo2.svg)}#home #hero{margin-bottom:0;padding-bottom:1px}#home #hero main{padding:0 10px;margin-bottom:30px}#home #hero #vendorStrip{display:none}#oceanNodes{padding-top:60px;padding-bottom:60px}#oceanNodes a{color:#3371e3}#oceanNodes main{margin-bottom:60px;min-height:160px}#oceanNodes .image-wrapper{max-width:75%;margin:0 auto 20px;text-align:center}#oceanNodes .image-wrapper img{width:100%;max-width:160px}#oceanNodes main:first-child .image-wrapper{max-width:100%}#oceanNodes main:first-child .image-wrapper img{max-width:491px}#oceanNodes h3{margin-bottom:30px}#video{height:200px}#video{width:100%;position:relative;background-position:center center;background-size:cover}#video>.light-text{display:none;position:absolute;top:50%;left:75%;width:525px;padding-right:80px;transform:translate(-50%, -50%);color:#fff}#video h2{font-size:32px;line-height:44px;margin-bottom:20px}#video p{margin-bottom:20px}#video #desktopKCButton{position:relative;font-size:18px;background-color:#303030;border-radius:8px;color:#fff;padding:20px 10px 20px 10px}#video #desktopShowVideoButton{position:relative;font-size:24px;background-color:#fff;border-radius:8px;color:#3371e3;padding:15px 30px 15px 80px;margin-bottom:15px}#video #desktopShowVideoButton:before{content:"";position:absolute;position:absolute;top:50%;left:40px;transform:translate(-50%, -50%);width:0;height:0;border-style:solid;border-width:10px 0 10px 20px;border-color:transparent transparent transparent #3371e3}#video #mobileShowVideoButton{position:absolute;top:50%;left:50%;transform:translate(-50%, -50%);width:80px;height:80px;border-radius:50%;background-color:transparent;border:5px solid rgba(255,255,255,0.2);overflow:visible}#video #mobileShowVideoButton:after{position:absolute;top:50%;left:50%;transform:translate(-50%, -50%);left:40px;content:"";width:0;height:0;border-style:solid;border-width:20px 0 20px 30px;border-color:transparent transparent transparent #fff}#videoPlayer{position:fixed;top:0;left:0;width:100vw;height:100vh;background-color:rgba(0,0,0,0.9);display:none}#videoPlayer iframe{position:absolute;top:50%;left:50%;transform:translate(-50%, -50%);width:80vw;height:45vw;max-width:142.2222222222vh;max-height:80vh}#videoPlayer #closeButton{position:absolute;top:20px;right:20px;width:50px;height:50px;border:2px solid transparent;transition:.3s}#videoPlayer #closeButton:before,#videoPlayer #closeButton:after{content:"";position:absolute;top:calc(50% - 1px);left:10%;width:80%;height:2px;background-color:#fff}#videoPlayer #closeButton:before{transform:rotate(45deg)}#videoPlayer #closeButton:after{transform:rotate(-45deg)}#videoPlayer #closeButton:hover{border-color:#fff}#cncf{padding-top:60px;padding-bottom:140px;background-image:url(/images/cncf-color.png);background-position:center 100px;background-repeat:no-repeat;background-size:300px}#kubeweekly{background-color:#f7f7f7;padding-top:60px;padding-bottom:140px;background-size:auto;font-family:"Roboto Mono",monospace !important;font-size:24px;font-weight:bold}#kubeweekly h5{font-size:20px}.subscribe-button{border-radius:6px;padding:0 20px;line-height:31px;color:#fff;background-color:blue;text-decoration:none;font-size:14px}#features{padding-top:140px;background-color:#f7f7f7;background-image:url(/images/wheel.png);background-position:center 60px;background-repeat:no-repeat;background-size:auto}.feature-box{width:100%;overflow:hidden;clear:both}.feature-box h4{line-height:normal;margin-bottom:15px}.feature-box>div:first-child{float:left}.feature-box>div:last-child{float:right}#features h3{margin-bottom:20px}#features .feature-box{margin-bottom:0}#features .feature-box>div{width:100%;margin-bottom:40px}#community.open-nav .logo,#community.flip-nav .logo,.gridPage.open-nav .logo,.gridPage.flip-nav .logo{background-image:url(/images/nav_logo2.svg)}#community #hero,.gridPage #hero{padding-bottom:20px}#community #mainContent,.gridPage #mainContent{padding:20px 0}#community #mainContent main,.gridPage #mainContent main{max-width:none}#community #mainContent a,.gridPage #mainContent a{color:#3371e3}#community #mainContent .content,.gridPage #mainContent .content{margin-bottom:30px;padding:30px 0}#community #mainContent .content h1,#community #mainContent .content h2,#community #mainContent .content h3,#community #mainContent .content h4,#community #mainContent .content h5,#community #mainContent .content h6,#community #mainContent .content p,.gridPage #mainContent .content h1,.gridPage #mainContent .content h2,.gridPage #mainContent .content h3,.gridPage #mainContent .content h4,.gridPage #mainContent .content h5,.gridPage #mainContent .content h6,.gridPage #mainContent .content p{line-height:normal;max-width:1200px;padding:0 20px;margin:0 auto 20px}#community #mainContent .content:nth-child(even),.gridPage #mainContent .content:nth-child(even){background-color:#f7f7f7}#community #mainContent .company-logos,.gridPage #mainContent .company-logos{text-align:center;max-width:1200px;margin:0 auto}#community #mainContent .company-logos img,.gridPage #mainContent .company-logos img{width:auto;margin:10px;background-color:#f7f7f7}#community #mainContent .partner-logos,.gridPage #mainContent .partner-logos{text-align:center;max-width:1200px;margin:0 auto}#community #mainContent .partner-logos img,.gridPage #mainContent .partner-logos img{width:auto;margin:10px;background-color:#fff;box-shadow:0 5px 5px rgba(0,0,0,0.24),0 0 5px rgba(0,0,0,0.12)}#community #mainContent #calendarMeetings,.gridPage #mainContent #calendarMeetings{position:relative;width:80vw;height:60vw;max-width:1200px;max-height:900px;margin:20px auto}#community #mainContent #calendarEvents,.gridPage #mainContent #calendarEvents{position:relative;width:80vw;height:30vw;max-width:1200px;max-height:450px;margin:20px auto}#community #mainContent iframe,.gridPage #mainContent iframe{position:absolute;border:0;width:100%;height:100%}.ui-icon{display:inline-block !important}#feature-state-dialog-link{text-decoration:none !important;padding:5px !important}#feature-state-dialog-link a:visited{color:#454545 !important}#feature-state-dialog-link a code{display:inline-block !important;box-sizing:border-box !important;background-color:#f7f7f7 !important;color:#303030 !important;font-family:"Roboto Mono",monospace !important;vertical-align:baseline !important;font-size:14px !important;font-weight:bold !important;padding:0px 4px !important}#feature-state-dialog{background:#fff !important;border:1px solid #ddd !important;padding:.5em 1em !important}#feature-state-dialog ul,#feature-state-dialog li{list-style:disc !important;margin:4px 12px !important}#feature-state-dialog p{margin:8px 0px !important}#feature-state-dialog code{display:inline-block !important;box-sizing:border-box !important;background-color:#f7f7f7 !important;color:#303030 !important;font-family:"Roboto Mono",monospace !important;vertical-align:baseline !important;font-size:14px !important;font-weight:bold !important;padding:0px 4px !important}.ui-dialog{background:#f7f7f7 !important;padding:.5em}.ui-dialog-content{position:relative;float:right;width:100%}.ui-dialog-content *+h2,.ui-dialog-content *+h3,.ui-dialog-content *+h4,.ui-dialog-content *+h5,.ui-dialog-content *+h6{margin-top:30px}.ui-dialog-content h1,.ui-dialog-content h2,.ui-dialog-content h3,.ui-dialog-content h4,.ui-dialog-content h5,.ui-dialog-content h6{line-height:normal;font-weight:500;margin-bottom:30px;padding-bottom:10px}.ui-dialog-content h1:before,.ui-dialog-content h2:before,.ui-dialog-content h3:before,.ui-dialog-content h4:before,.ui-dialog-content h5:before,.ui-dialog-content h6:before{display:block;content:" ";margin-top:-100px;height:100px;visibility:hidden}.ui-dialog-content h1,.ui-dialog-content h2{border-bottom:1px solid #ccc}.ui-dialog-content h1{font-size:32px;padding-right:60px}.ui-dialog-content h2{font-size:28px}.ui-dialog-content h3{font-size:24px;font-weight:300;margin-bottom:5px}.ui-dialog-content h4{font-size:20px;margin-bottom:0px}.ui-dialog-content h5,.ui-dialog-content h6{font-size:16px;font-weight:500}.ui-dialog-content p{font-size:16px;font-weight:300;line-height:1.75em}.ui-dialog-content p+p{margin-top:10px}.ui-dialog-content code{display:inline-block;box-sizing:border-box;background-color:#f7f7f7;color:#303030;font-family:"Roboto Mono",monospace;vertical-align:baseline;font-size:14px;font-weight:bold;padding:2px 4px}.ui-dialog-content a code{color:#3371e3;text-decoration:underline}.ui-dialog-content pre .pi,.ui-dialog-content pre .s{margin:0;padding:0}.ui-dialog-content .highlight code span,.ui-dialog-content code,.ui-dialog-content pre code{font-family:"Roboto Mono",monospace}.ui-dialog-content code,.ui-dialog-content pre code{color:#303030}.ui-dialog-content pre code{padding:0}.ui-dialog-content pre{background-color:#f7f7f7;display:block;margin:20px 0;padding:15px;position:relative;overflow-x:auto}.ui-dialog-content h1 code,.ui-dialog-content h2 code,.ui-dialog-content h3 code,.ui-dialog-content h4 code,.ui-dialog-content h5 code,.ui-dialog-content h6 code{font-family:inherit;font-size:inherit;background-color:transparent}.ui-dialog-content .includecode{table-layout:fixed}.ui-dialog-content .includecode,.ui-dialog-content .includecode th,.ui-dialog-content .includecode td{padding:0 !important}.ui-dialog-content .includecode th{text-align:right !important;padding:10px !important}.ui-dialog-content .includecode th a,.ui-dialog-content .includecode th a code{color:#fff !important;background-color:transparent !important}.ui-dialog-content .includecode pre{margin:0 !important}.ui-dialog-content ul li{list-style:disc}.ui-dialog-content ol li{list-style:decimal}.ui-dialog-content ul,.ui-dialog-content ol{margin:20px 0;padding-left:30px;font-weight:300}.ui-dialog-content ul ul,.ui-dialog-content ol ol,.ui-dialog-content ul ol,.ui-dialog-content ol ul{margin:.75em 0}.ui-dialog-content li{margin-bottom:.75em;font-size:16px;line-height:1.75em}.ui-dialog-content table{width:100%;border:1px solid #ccc;border-spacing:0;margin-top:30px;margin-bottom:30px}.ui-dialog-content thead,.ui-dialog-content tr:nth-child(even){background-color:#f7f7f7}.ui-dialog-content thead{background-color:#555;color:#fff}.ui-dialog-content th,.ui-dialog-content td{padding:8px;text-align:left;margin:0}.ui-dialog-content th{font-weight:normal}.ui-dialog-content td{font-size:.85em}.ui-dialog-content #editPageButton{position:absolute;top:-25px;right:5px;width:50px;height:50px;line-height:50px;border-radius:50%;white-space:nowrap;text-indent:50px;overflow:hidden;background:#3371e3 url(/images/icon-pencil.svg) no-repeat;background-position:12px 10px;background-size:29px 29px}.ui-dialog-content #markdown-toc{margin-bottom:20px}.ui-dialog-content #markdown-toc ul,.ui-dialog-content #markdown-toc li{list-style:disc;color:#3371e3}.ui-dialog-content #markdown-toc ul{padding:0 15px;margin:0}.ui-dialog-content #markdown-toc li{padding:0;line-height:1.5em;margin-bottom:0}.ui-dialog-content #markdown-toc a{position:relative;color:#3371e3;font-weight:700}.ui-dialog-content img{max-width:100%}.ui-dialog-content a{text-decoration:underline}.ui-dialog-content a.button{border-radius:2px;text-decoration:none}.ui-dialog-content a.button:visited{color:#fff}.ui-dialog-content a.issue{margin-left:0px}.ui-dialog-buttonpane{background:#f7f7f7 !important}.ui-widget-header{background:transparent !important;background-color:transparent !important;border:0px !important}.ui-tabs ul,.ui-tabs ol,.ui-tabs li{padding:0px !important;list-style:none !important;margin-bottom:0px !important;margin-left:4px !important}.ui-tabs-panel ul li{list-style:disc !important}.ui-tabs-panel ol li{list-style:decimal !important}.ui-widget-content{border:0px !important}.ui-widget-content p a{color:#3371e3}.ui-widget-content table{margin:0px !important}.ui-tabs .ui-tabs-panel{border:1px solid #ccc !important}.ui-tabs-anchor{text-decoration:none !important}#talkToUs h3,#talkToUs h4{text-align:center}#talkToUs h3{margin-bottom:15px}#talkToUs h4{line-height:normal;margin-bottom:50px}#talkToUs h4 br{display:none}#talkToUs #bigSocial{overflow:hidden}#talkToUs #bigSocial div{width:100%;float:left;padding:30px;padding-top:110px;background-position:center top;background-size:auto;background-repeat:no-repeat}#talkToUs #bigSocial div:nth-child(1){background-image:url(/images/twitter_icon.png)}#talkToUs #bigSocial div:nth-child(2){background-image:url(/images/github_icon.png)}#talkToUs #bigSocial div:nth-child(3){background-image:url(/images/slack_icon.png)}#talkToUs #bigSocial div:nth-child(4){background-image:url(/images/stackoverflow_icon.png)}#talkToUs #bigSocial div+div{margin-top:20px;margin-left:0}#talkToUs #bigSocial a{display:inline-block;color:#3371e3;font-size:24px;font-weight:400;text-decoration:none;margin-bottom:15px}#talkToUs #bigSocial a,#talkToUs #bigSocial p{text-align:center;width:100%}#home #talkToUs main{padding:30px 0}#home #talkToUs h5{font-size:20px}#home #caseStudiesWrapper{position:relative;text-align:center;margin-bottom:30px}#home #caseStudiesWrapper img{padding-bottom:1rem}#home #caseStudiesWrapper div{position:relative;display:inline-block;vertical-align:top;width:100%;min-height:230px;margin-bottom:60px;padding-right:1rem;background-position:top center}#home #caseStudiesWrapper p{font-size:20px}#home #caseStudiesWrapper a{position:absolute;bottom:-30px;left:50%;transform:translateX(-50%);color:#3371e3;font-weight:400}.cse .gsc-control-cse,.gsc-control-cse{padding:0}.gsc-control-cse table,.gsc-control-cse-en table{margin:0px !important}.gsc-above-wrapper-area{border-bottom:0}#bing-results-container{margin-top:30px;margin-left:20px}.bing-result{margin-bottom:20px}.bing-result-name a{font-size:16px;color:#00c}.bing-result-url{color:green;font-size:13px}.bing-result-snippet{color:#000;font-size:11px}#bing-pagination-container{margin:10px;margin-left:20px}.bing-page-anchor{text-decoration:none !important;cursor:pointer;color:#00c;margin-right:8px}.page{display:flex;flex-direction:column;min-height:100vh}.page .page-content{flex:1}.container-404{text-align:center;margin:3.5rem 0}.container-404 ul li a{font-size:1.5rem}#pre-footer{margin-top:2rem}#pre-footer .button{font-size:1.1rem}#pre-footer .button:first-of-type{margin-right:.75rem}#pre-footer .lastedit{margin-top:1rem;font-size:1rem}@media screen and (min-width: 750px){h1{font-size:32px;line-height:40px}h2{font-size:28px;line-height:60px}h3{font-size:24px;line-height:32px}h4{font-size:20px;line-height:40px}h5{font-size:16px;line-height:36px}p{font-size:14px;line-height:22px}section,header,#vendorStrip{padding-left:20px;padding-right:20px}section main,header main,#vendorStrip main{width:100%;max-width:100%}header{height:80px}.nav-buttons{height:80px;line-height:80px}.nav-buttons .button+*{margin-left:30px}#hamburger{width:50px;height:50px}#mainNav{padding:140px 0 30px}#mainNav h5{margin-bottom:1em}#mainNav h3{margin-bottom:.6em}#mainNav .nav-box{width:20%}#mainNav .nav-box+.nav-box{margin-left:calc(20% / 3)}#mainNav main+main{margin-top:60px}#mainNav .left .button{height:50px;line-height:50px;font-size:18px}.open-nav #tryKubernetes,.y-enough #tryKubernetes{margin-left:30px}#hero{padding-top:80px}#docs #hero h1,#docs #hero h5{padding-left:20px;padding-right:20px}#vendorStrip{height:88px;line-height:88px;font-size:16px}p{font-size:16px;line-height:24px;letter-spacing:.1px}h1{font-size:36px;line-height:44px}h3{font-size:28px;line-height:36px}h4{font-size:24px;line-height:40px}#home #viewDocs,#home #tryKubernetes{display:inline-block}#vendorStrip{display:block;text-align:center}#vendorStrip img{max-height:24px;vertical-align:middle;margin:0 30px}#docs #vendorStrip li a{font-size:1em;font-weight:normal}#docs #vendorStrip li li+li{margin-left:60px}#oceanNodes h3{text-align:left;margin-bottom:18px}#oceanNodes main{position:relative;clear:both;display:table;height:160px}#oceanNodes main .content{display:table-cell;position:relative;vertical-align:middle}#oceanNodes main .image-wrapper{position:absolute;top:50%;max-width:25%;max-height:100%;transform:translateY(-50%)}#oceanNodes main:nth-child(odd){padding-right:210px}#oceanNodes main:nth-child(odd) .image-wrapper{right:0}#oceanNodes main:nth-child(even){padding-left:210px}#oceanNodes main:nth-child(even) .image-wrapper{left:0}#oceanNodes main:nth-child(1){padding-right:0}#oceanNodes main:nth-child(1) h3,#oceanNodes main:nth-child(1) p{text-align:center}#oceanNodes main:nth-child(1) .image-wrapper{position:relative;display:block;float:none;max-width:100%;transform:none}#oceanNodes main:nth-child(1) .content{display:block}#oceanNodes main img{width:100%}#video{height:400px;display:block}#video>.light-text{display:block}#mobileShowVideoButton{display:none}#features{padding-bottom:60px}#features .feature-box{margin-bottom:30px}#features .feature-box:last-child{margin-bottom:0}#features h3{margin-bottom:40px}#features .feature-box>div{width:45%;margin-bottom:0}#talkToUs #bigSocial div{width:calc(50% - 15px)}#talkToUs #bigSocial div+div{margin-top:0}#talkToUs #bigSocial div:nth-child(2){margin-left:20px}#talkToUs #bigSocial div:nth-child(3){margin-top:20px}#talkToUs #bigSocial div:nth-child(4){margin-top:20px;margin-left:20px}#talkToUs #bigSocial a{display:inline-block;color:#3371e3;font-weight:400;text-decoration:none}footer nav{text-align:center}footer nav a{width:30%;padding:0 20px}footer .social{text-align:center}footer .social div{display:inline-block}footer .social div:last-child{display:block;margin:0}footer .social span{display:inline-block;margin-right:10px}footer .social input{text-align:left}#home #caseStudiesWrapper div{width:48%}}@media screen and (min-width: 1025px){#hamburger{display:none}ul.global-nav{display:inline-block}#docs #vendorStrip #searchBox:before{top:15px}#vendorStrip{height:44px;line-height:44px}#vendorStrip li a.YAH:after{content:"";display:block;position:absolute;left:0;bottom:0;width:100%;height:4px;background-color:#3371e3}#vendorStrip #searchBox{float:right}#home #hero #vendorStrip{display:block}#docs #hero h1,#docs #hero h5{text-align:left}#docs #hero #vendorStrip ul{float:left}#docs #hero #vendorStrip #searchBox{float:right;width:250px}#docs #hero #vendorStrip #search{vertical-align:middle}#docs .flyout-button{display:none}#docs .logo{position:relative;float:left;display:block;width:180px;height:88px;top:0;left:0;transform:none;background-image:url(../images/nav_logo.svg)}#docs.flip-nav .logo,#docs.open-nav .logo{background-image:url(../images/nav_logo2.svg)}#encyclopedia{padding:50px 50px 100px 100px;clear:both}#docsToc{position:relative;float:left;padding:0 20px;left:0;width:350px;z-index:auto}#docsToc .push-menu-close-button{display:none}#docsContent{width:calc(100% - 400px)}#docsContent #editPageButton{right:-25px}section main,header main,footer main{max-width:1200px}header,#vendorStrip,#encyclopedia,#hero h1,#hero h5,#docs #hero h1,#docs #hero h5,#community #hero h1,.gridPage #hero h1,#community #hero h5,.gridPage #hero h5{padding-left:100px;padding-right:100px}#vendorStrip{padding-right:10px}#home section main,#home header main,#home footer main{max-width:1000px}#oceanNodes main{position:relative;max-width:830px}#oceanNodes main:nth-child(1){max-width:1000px;padding-right:475px}#oceanNodes main:nth-child(1) h3,#oceanNodes main:nth-child(1) p{text-align:left}#oceanNodes main:nth-child(1) .image-wrapper{position:absolute;max-width:48%;transform:translateY(-50%)}#oceanNodes main:nth-child(1) .image-wrapper img{max-width:425px}#video{height:550px;position:relative;background-position:center center;background-size:cover}#talkToUs h4 br{display:block}#talkToUs #bigSocial div{width:calc(25% - 18px)}#talkToUs #bigSocial div+div{margin-left:20px}footer{width:100%;background-image:url(../images/texture.png);background-color:#303030}footer main{padding:20px 0}footer nav{overflow:hidden;margin-bottom:20px}footer nav a{width:16.65%;float:left;font-size:24px;font-weight:300;white-space:nowrap}footer .social{padding:0 30px;max-width:1200px}footer .social div{float:left}footer .social div:last-child{float:right}#search,#wishField{background-color:transparent;padding:10px;font-size:16px;font-weight:100;color:#fff;border:1px solid #fff;transition:.3s}#search:focus,#wishField:focus{background-color:#f7f7f7;color:#303030}.social a{display:inline-block;background-image:url(../images/social_sprite.png);background-repeat:no-repeat;background-size:auto;width:50px;height:50px;border-radius:5px;margin-right:10px}.social a:hover{background-color:#fff}.social a span{position:absolute;display:block;height:0;overflow:hidden}a.twitter{background-position:0 0}a.twitter:hover{background-position:0 100%}a.stack-overflow{background-position:-50px 0}a.stack-overflow:hover{background-position:-50px 100%}a.slack{background-position:-100px 0}a.slack:hover{background-position:-100px 100%}a.github{background-position:-150px 0}a.github:hover{background-position:-150px 100%}a.mailing-list{background-position:-200px 0}a.mailing-list:hover{background-position:-200px 100%}a.calendar{background-position:-250px 0}a.calendar:hover{background-position:-250px 100%}#community #hero,.gridPage #hero{text-align:left}#community #hero h1,.gridPage #hero h1{padding:20px 100px}#community #tryKubernetes,.gridPage #tryKubernetes{width:auto;background-color:#3371e3;padding:0 20px}#bigSocial div{width:calc(25% - 18px)}#home #caseStudiesWrapper div{width:24%;min-height:260px}}@media screen and (min-width: 1300px){#vendorStrip{padding-right:100px}}@media screen and (min-width: 456px){#vendorStrip li+li{margin-left:20px}} -/*# sourceMappingURL=styles.css.map */ +html,body{margin:0;padding:0}input,button{outline:none}button{cursor:pointer}ul,li{list-style:none}ul{margin:0;padding:0}a{text-decoration:none}.clear{display:block;clear:both}.light-text{color:#fff}.right{float:right}.left{float:left}.center{text-align:center}*,.button{box-sizing:border-box;font-family:"Roboto",sans-serif;background:none;margin:0;border:0}body{font-family:"Roboto",sans-serif}h1,h2,h5,p{font-weight:300}h3,h4{font-weight:400}html,body{margin:0;padding:0}input,button{outline:none}button{cursor:pointer}ul,li{list-style:none}ul{margin:0;padding:0}a{text-decoration:none}.clear{display:block;clear:both}.light-text{color:#fff}.right{float:right}.left{float:left}.center{text-align:center}h1{font-size:32px;line-height:40px}h2{font-size:28px;line-height:60px}h3{font-size:24px;line-height:32px}h4{font-size:20px;line-height:40px}h5{font-size:16px;line-height:36px}p{font-size:14px;line-height:22px}section,header,#vendorStrip{padding-left:20px;padding-right:20px}section main,header main,#vendorStrip main{width:100%;max-width:100%}header{height:80px}.nav-buttons{height:80px;line-height:80px}.nav-buttons .button+*{margin-left:30px}#hamburger{width:50px;height:50px}#mainNav{padding:140px 0 30px}#mainNav h5{margin-bottom:1em}#mainNav h3{margin-bottom:0.6em}#mainNav .nav-box{width:20%}#mainNav .nav-box+.nav-box{margin-left:calc(20% / 3)}#mainNav main+main{margin-top:60px}#mainNav .left .button{height:50px;line-height:50px;font-size:18px}.open-nav #tryKubernetes,.y-enough #tryKubernetes{margin-left:30px}#hero{padding-top:80px}#docs #hero h1,#docs #hero h5{padding-left:20px;padding-right:20px}#vendorStrip{height:88px;line-height:88px;font-size:16px}body{background-color:#fff}section{position:relative;background-color:#fff}section main,header main,footer main{position:relative;margin:auto}p{font-size:14px;font-weight:400}.button{display:inline-block;border-radius:6px;padding:0 20px;line-height:40px;color:#fff;background-color:#3371e3;text-decoration:none;font-size:1rem}#cellophane{position:fixed;top:0;left:0;width:100%;height:100%;display:none}header{position:fixed;top:0;left:0;width:100%;z-index:8888;background-color:transparent;box-shadow:0 0 0 transparent;overflow:hidden;transition:0.3s;text-align:center}.logo{position:relative;float:left;display:block;width:180px;height:88px;top:0;left:0;transform:none;background-image:url(/images/nav_logo.svg);background-size:contain;background-position:center center;background-repeat:no-repeat}.blog-content table{max-width:100%;border:1px solid #ccc;border-spacing:0;margin-top:30px;margin-bottom:30px}.blog-content table thead{border-bottom:2px solid #ccc}.blog-content table thead tr th{padding:0.5rem;font-size:1.5rem}.blog-content table tbody tr td{padding:0.5rem;border-bottom:1px solid #ccc;border-left:1px solid #ccc;padding-right:5rem}#docs .flyout-button{position:fixed;top:20px;left:20px;width:50px;height:50px;background-image:url(/images/toc_icon.png);background-position:center center;background-repeat:no-repeat;background-size:auto;border-radius:50%;transition:0.3s;z-index:99999}#docs.open-nav .flyout-button{display:none}#docs .logo{position:absolute;top:40px;left:50%;transform:translate(-50%, -50%);display:block;width:45px;height:44px;background-image:url(/images/favicon.png)}#docs.flip-nav .flyout-button{background-image:url(/images/toc_icon_grey.png)}.nav-buttons{float:right}#viewDocs,#tryKubernetes{display:none}#viewDocs{border:2px solid #fff;background-color:transparent;transition:0.3s}#viewDocs:hover{background-color:#fff;color:#303030}#tryKubernetes{width:0;padding:0 0;border:1px solid transparent;background-color:transparent;text-align:center;white-space:nowrap;vertical-align:middle;overflow:hidden;transition:0.3s}#hamburger{display:inline-block;position:relative;vertical-align:middle;padding:0;border:0;background:none}#hamburger div,#hamburger:before,#hamburger:after{position:absolute;left:15%;width:70%;height:2px;background-color:#3371e3;transition:0.3s;content:""}#hamburger div{top:calc(50% - 1px)}#hamburger:before{top:24%}#hamburger:after{bottom:24%}#hamburger:hover div,#hamburger:hover:before,#hamburger:hover:after{background-color:#fff}#mainNav h5{color:#3371e3;font-weight:normal}#mainNav main{white-space:nowrap;overflow:hidden;clear:both}#mainNav .nav-box{float:left;white-space:normal}#mainNav h3 a{color:#3371e3;text-decoration:none}ul.global-nav{display:none}ul.global-nav li{display:inline-block;margin-right:14px}ul.global-nav li a{color:#fff;font-weight:400;padding:0;position:relative}ul.global-nav li a.active:after{position:absolute;width:100%;height:2px;content:"";bottom:-4px;left:0;background:#fff}ul.global-nav li a .ui-icon{filter:brightness(0) invert(1)}ul.global-nav li ul{display:none;position:fixed;top:40px;text-align:left}ul.global-nav li ul li{display:block;height:28px}ul.global-nav li ul li a{background:#303030;color:#fff;padding:7px}ul.global-nav li ul li:last-child a{border-radius:7px}ul.global-nav li:hover ul{display:block}.flip-nav ul.global-nav li a,.open-nav ul.global-nav li a{color:#303030}.flip-nav ul.global-nav li a .ui-icon,.open-nav ul.global-nav li a .ui-icon{filter:brightness(0)}.flip-nav ul.global-nav li ul li a{background:#fff;color:#303030}.flip-nav ul.global-nav li a.active:after,.flip-nav ul.global-nav li ul li a.active:after,.open-nav ul.global-nav li a.active:after{background:#3371e3}.flip-nav header{background-color:#fff}.open-nav body{overflow:hidden}.open-nav #cellophane{display:block;z-index:9998}.open-nav header{background-color:#e8e8e8;z-index:9999}.open-nav #hamburger div{opacity:0}.open-nav #hamburger:before,.open-nav #hamburger:after{left:12px;transform-origin:0 1px}.open-nav #hamburger:before{transform:rotate(45deg)}.open-nav #hamburger:after{transform:rotate(-45deg)}.open-nav #tryKubernetes,.y-enough #tryKubernetes{width:auto;padding:0 20px;background-color:#3371e3;border-color:#3371e3}.flip-nav header,.open-nav header{box-shadow:0 1px 2px #4c4c4c}.flip-nav #viewDocs,.open-nav #viewDocs{border-color:#303030;color:#303030}.flip-nav #viewDocs:hover,.open-nav #viewDocs:hover{border-color:#3371e3;background-color:#3371e3;color:#fff}.flip-nav #hamburger:hover div,.flip-nav #hamburger:hover:before,.flip-nav #hamburger:hover:after,.open-nav #hamburger:hover div,.open-nav #hamburger:hover:before,.open-nav #hamburger:hover:after{background-color:#303030}#hero{background-image:url(/images/texture.png);background-color:#303030;text-align:center;padding-left:0;padding-right:0;margin-bottom:0;position:relative}#hero.bot-bar:after{display:block;margin-bottom:-20px;height:8px;width:100%;background-color:rgba(255,255,255,0.1);content:""}#hero.no-sub h5{display:none}#hero.no-sub h1{margin-bottom:20px}#home #hero:after{display:none}#vendorStrip{position:relative;background-color:rgba(255,255,255,0.1);font-weight:100;white-space:nowrap;text-align:center}#vendorStrip li a{color:rgba(255,255,255,0.5)}#vendorStrip li a.YAH{color:#fff;position:relative}footer{width:100%;background-image:url(/images/texture.png);background-color:#303030}footer main{padding:20px 0}footer nav a{width:100%;text-align:center;display:inline-block;margin:10px 0;font-size:24px;font-weight:300;color:#fff;text-decoration:none}footer .social{margin:20px 0}footer .social div{text-align:center;margin-bottom:20px}footer .social div:last-child{margin:30px 0}footer .social span{display:block;margin-bottom:8px}footer .social input{text-align:center}#search,#wishField{background-color:transparent;padding:10px;font-size:16px;font-weight:100;color:#fff;border:1px solid #fff;transition:0.3s}#search:focus,#wishField:focus{background-color:#f7f7f7;color:#303030}.social a{display:inline-block;background-image:url(/images/social_sprite.png);background-repeat:no-repeat;background-size:auto;width:50px;height:50px;border-radius:5px;margin-right:10px}.social a:hover{background-color:#fff}.social a span{position:absolute;display:block;height:0;overflow:hidden}.social a.button{background-image:none;width:auto;height:auto}.social a.button:hover{color:#3371e3}a.twitter{background-position:0 0}a.twitter:hover{background-position:0 100%}a.stack-overflow{background-position:-50px 0}a.stack-overflow:hover{background-position:-50px 100%}a.slack{background-position:-100px 0}a.slack:hover{background-position:-100px 100%}a.github{background-position:-150px 0}a.github:hover{background-position:-150px 100%}a.mailing-list{background-position:-200px 0}a.mailing-list:hover{background-position:-200px 100%}a.calendar{background-position:-250px 0}a.calendar:hover{background-position:-250px 100%}#viewDocs{display:none}section{background-color:#fff}#hero{background-color:#303030}#hero h5{margin:20px 0;line-height:28px}#vendorStrip{position:relative}#vendorStrip ul{float:left}#vendorStrip li{display:inline-block;height:100%}#vendorStrip a{display:block;height:100%;color:#fff;font-size:0.75em;font-weight:bold}#vendorStrip li+li{margin-left:0}#docs #vendorStrip{line-height:44px;max-width:100%;overflow-x:auto;-webkit-overflow-scrolling:touch}#docs #vendorStrip ul{float:none}#docs #vendorStrip #searchBox{float:none;display:block;width:80%;margin:0 auto;height:44px;line-height:44px;position:relative}#docs #vendorStrip #searchBox:before{position:absolute;width:15px;height:15px;content:"";right:8px;top:7px;background-image:url(/images/search-icon.svg);background-repeat:no-repeat;background-size:100% 100%;z-index:1}#docs #vendorStrip #search{width:100%;padding:0 10px;height:30px;line-height:30px;font-size:16px;vertical-align:top;background:#fff;border:none;border-radius:4px;position:relative}#encyclopedia{position:relative;padding:50px 20px 20px 20px;overflow:hidden;font-size:14px}#encyclopedia>div{height:100%}#docsToc{position:fixed;background-color:#fff;top:0;left:0;width:0;height:100vh;overflow:hidden;padding:50px 0;z-index:999999;transition:0.3s}#docsToc .yah>.title{background-color:#f7f7f7;border-left:3px solid #3371e3;padding:7.5px 10px 7.5px 18px;margin-left:-3px;color:#3371e3}.open-toc body{overflow:hidden}.open-toc #docsToc{padding:50px 20px;width:400px;max-width:100vw;overflow-y:auto}.pi-accordion>.container:first-child>.item:first-child>.title:first-child{padding-left:0;font-size:1.5em;font-weight:700}.pi-accordion>.container:first-child>.item.yah:first-child>.title:first-child{margin-left:-20px !important}.pi-accordion .item{overflow:hidden}.pi-accordion .title{color:#303030;position:relative;padding:7.5px 10px 7.5px 18px;cursor:pointer;transition:0.3s}.pi-accordion .title:hover{color:#3371e3}.pi-accordion a.item>.title{color:#000}.pi-accordion a.item>.title:hover{color:#3371e3}.pi-accordion div.item>.title:before{content:"";position:absolute;top:12px;left:2px;border-style:solid;border-width:5px 0 5px 8px;border-color:transparent transparent transparent #3371e3;transform:rotate(0deg);transition:0.3s}.pi-accordion .wrapper{position:relative;width:100%;transition:height 0.3s}.pi-accordion .content{padding-left:20px;opacity:0;transition:0.3s}.pi-accordion .item.on>.title:before{transform:rotate(90deg)}.pi-accordion .item.on>.wrapper>.content{opacity:1}dt{margin-bottom:8px}dd{margin-bottom:16px}.pi-pushmenu{display:none;position:fixed;top:0;width:100%;height:100%;opacity:0;transition:opacity 0.3s}.pi-pushmenu.on{opacity:1}.pi-pushmenu .overlay{position:fixed;top:0;left:0;width:100%;height:100%;background-color:rgba(0,0,0,0.4)}.pi-pushmenu .sled{position:absolute;top:0;width:0;height:100%;background-color:#fff;overflow:auto;transition:0.3s}.pi-pushmenu.on .sled{width:400px;max-width:100vw}.pi-pushmenu .top-bar{height:0;line-height:60px;background-color:#444}.pi-pushmenu ul{margin-top:25px}.pi-pushmenu li{position:relative;display:block;width:100%;min-height:45px;padding:0 60px 0 20px;border-bottom:1px solid #ccc}.pi-pushmenu a{display:inline-block;width:100%;height:45px;line-height:45px;font-family:"Roboto",sans-serif;font-size:20px;color:#3371e3}.pi-pushmenu .button{background:none;padding:0}.pi-pushmenu ul ul{padding:0 20px}.pi-pushmenu ul ul li{min-height:40px}.pi-pushmenu ul ul a{height:40px;line-height:40px;font-size:18px;color:#555}.push-menu-close-button{position:absolute;top:0;right:0;width:50px;height:50px}.push-menu-close-button:before,.push-menu-close-button:after{content:"";position:absolute;top:calc(50% - 1px);left:25%;width:50%;height:2px;background-color:#000}.push-menu-close-button:before{transform:rotate(45deg)}.push-menu-close-button:after{transform:rotate(-45deg)}#docsContent{position:relative;float:right;width:100%}#docsContent *+h2,#docsContent *+h3,#docsContent *+h4,#docsContent *+h5,#docsContent *+h6{margin-top:30px}#docsContent h1,#docsContent h2,#docsContent h3,#docsContent h4,#docsContent h5,#docsContent h6{line-height:normal;font-weight:500;margin-bottom:30px;padding-bottom:10px}#docsContent h1:before,#docsContent h2:before,#docsContent h3:before,#docsContent h4:before,#docsContent h5:before,#docsContent h6:before{display:block;content:" ";margin-top:-100px;height:100px;visibility:hidden}#docsContent h1,#docsContent h2{border-bottom:1px solid #ccc}#docsContent h1{font-size:32px;padding-right:60px}#docsContent h2{font-size:28px}#docsContent h3{font-size:24px;font-weight:300;margin-bottom:5px}#docsContent h4{font-size:20px;margin-bottom:0px}#docsContent h5,#docsContent h6{font-size:16px;font-weight:500}#docsContent p{font-size:16px;font-weight:300;line-height:1.75em}#docsContent p+p{margin-top:10px}#docsContent code{display:inline-block;box-sizing:border-box;background-color:#f7f7f7;color:#303030;font-family:"Roboto Mono",monospace;vertical-align:baseline;font-size:14px;font-weight:bold;padding:2px 4px}#docsContent a code{color:#3371e3;text-decoration:underline}#docsContent pre .pi,#docsContent pre .s{margin:0;padding:0}#docsContent .highlight code span,#docsContent code,#docsContent pre code{font-family:"Roboto Mono",monospace}#docsContent code,#docsContent pre code{color:#303030}#docsContent pre code{padding:0}#docsContent pre{background-color:#f7f7f7;display:block;margin:20px 0;padding:15px;position:relative;overflow-x:auto}#docsContent h1 code,#docsContent h2 code,#docsContent h3 code,#docsContent h4 code,#docsContent h5 code,#docsContent h6 code{font-size:inherit;background-color:transparent}#docsContent .includecode{table-layout:fixed}#docsContent .includecode,#docsContent .includecode th,#docsContent .includecode td{padding:0 !important}#docsContent .includecode th{text-align:right !important;padding:10px !important}#docsContent .includecode th a,#docsContent .includecode th a code{color:#fff !important;background-color:transparent !important}#docsContent .includecode pre{margin:0 !important}#docsContent ul li{list-style:disc}#docsContent ol ul li{list-style:disc}#docsContent ol li{list-style:decimal}#docsContent ul,#docsContent ol{margin:20px 0;padding-left:30px;font-weight:300}#docsContent ul ul,#docsContent ol ol,#docsContent ul ol,#docsContent ol ul{margin:0.75em 0}#docsContent li{margin-bottom:0.75em;font-size:16px;line-height:1.75em}#docsContent table{width:100%;border:1px solid #ccc;border-spacing:0;margin-top:30px;margin-bottom:30px}#docsContent thead,#docsContent tr:nth-child(even){background-color:#f7f7f7}#docsContent thead{background-color:#555;color:#fff}#docsContent th,#docsContent td{padding:8px;text-align:left;margin:0}#docsContent th{font-weight:normal}#docsContent td{font-size:0.85em}#docsContent #editPageButton{position:absolute;top:-25px;right:5px;width:50px;height:50px;line-height:50px;border-radius:50%;white-space:nowrap;text-indent:50px;overflow:hidden;background:#3371e3 url(/images/icon-pencil.svg) no-repeat;background-position:12px 10px;background-size:29px 29px}#docsContent #markdown-toc,#docsContent #TableOfContents{margin-bottom:20px}#docsContent #markdown-toc ul,#docsContent #markdown-toc li,#docsContent #TableOfContents ul,#docsContent #TableOfContents li{list-style:disc;color:#3371e3}#docsContent #markdown-toc ul,#docsContent #TableOfContents ul{padding:0 15px;margin:0}#docsContent #markdown-toc li,#docsContent #TableOfContents li{padding:0;line-height:1.5em;margin-bottom:0}#docsContent #markdown-toc a,#docsContent #TableOfContents a{position:relative;color:#3371e3;font-weight:700}#docsContent img{max-width:100%}#docsContent #TableOfContents>ul>li{list-style:none}#docsContent #TableOfContents ul,#docsContent #TableOfContents li{list-style:disk}#docsContent a.button{border-radius:2px;text-decoration:none}#docsContent a.button:visited{color:#fff}#docsContent a.issue{margin-left:0px}.feedback--no{margin-left:1em}.feedback--prompt{margin-bottom:1em}.feedback--response{margin-top:1em}.feedback--button__disabled{background-color:#f7f7f7;color:graytext}.feedback--response__hidden{display:none}.fixed footer{position:fixed;bottom:0}#miceType{clear:both;font-size:11px;line-height:18px;color:#aaa}html.search #docsContent{position:relative;float:none;width:90%;max-width:850px;margin:0 auto}html.search #docsContent #editPageButton{display:none}html.search #docsContent table{border:0;margin-bottom:0}html.search #docsContent td{padding:0}html.search #docsContent h1{margin-bottom:0;border-bottom:0;padding-bottom:0;padding-left:8px}#home.flip-nav .logo,#home.open-nav .logo{background-image:url(/images/nav_logo2.svg)}#home #hero{margin-bottom:0;padding-bottom:1px}#home #hero main{padding:0 10px;margin-bottom:30px}#home #hero #vendorStrip{display:none}#oceanNodes{padding-top:60px;padding-bottom:60px}#oceanNodes a{color:#3371e3}#oceanNodes main{margin-bottom:60px;min-height:160px}#oceanNodes .image-wrapper{max-width:75%;margin:0 auto 20px;text-align:center}#oceanNodes .image-wrapper img{width:100%;max-width:160px}#oceanNodes main:first-child .image-wrapper{max-width:100%}#oceanNodes main:first-child .image-wrapper img{max-width:491px}#oceanNodes h3{margin-bottom:30px}#video{height:200px}#video{width:100%;position:relative;background-position:center center;background-size:cover}#video>.light-text{display:none;position:absolute;top:50%;left:75%;width:525px;padding-right:80px;transform:translate(-50%, -50%);color:#fff}#video h2{font-size:32px;line-height:44px;margin-bottom:20px}#video p{margin-bottom:20px}#video #desktopKCButton{position:relative;font-size:18px;background-color:#303030;border-radius:8px;color:#fff;padding:20px 10px 20px 10px}#video #desktopShowVideoButton{position:relative;font-size:24px;background-color:#fff;border-radius:8px;color:#3371e3;padding:15px 30px 15px 80px;margin-bottom:15px}#video #desktopShowVideoButton:before{content:"";position:absolute;position:absolute;top:50%;left:40px;transform:translate(-50%, -50%);width:0;height:0;border-style:solid;border-width:10px 0 10px 20px;border-color:transparent transparent transparent #3371e3}#video #mobileShowVideoButton{position:absolute;top:50%;left:50%;transform:translate(-50%, -50%);width:80px;height:80px;border-radius:50%;background-color:transparent;border:5px solid rgba(255,255,255,0.2);overflow:visible}#video #mobileShowVideoButton:after{position:absolute;top:50%;left:50%;transform:translate(-50%, -50%);left:40px;content:"";width:0;height:0;border-style:solid;border-width:20px 0 20px 30px;border-color:transparent transparent transparent #fff}#videoPlayer{position:fixed;top:0;left:0;width:100vw;height:100vh;background-color:rgba(0,0,0,0.9);display:none}#videoPlayer iframe{position:absolute;top:50%;left:50%;transform:translate(-50%, -50%);width:80vw;height:45vw;max-width:142.22222vh;max-height:80vh}#videoPlayer #closeButton{position:absolute;top:20px;right:20px;width:50px;height:50px;border:2px solid transparent;transition:0.3s}#videoPlayer #closeButton:before,#videoPlayer #closeButton:after{content:"";position:absolute;top:calc(50% - 1px);left:10%;width:80%;height:2px;background-color:#fff}#videoPlayer #closeButton:before{transform:rotate(45deg)}#videoPlayer #closeButton:after{transform:rotate(-45deg)}#videoPlayer #closeButton:hover{border-color:#fff}#cncf{padding-top:60px;padding-bottom:140px;background-image:url(/images/cncf-color.png);background-position:center 100px;background-repeat:no-repeat;background-size:300px}#kubeweekly{background-color:#f7f7f7;padding-top:60px;padding-bottom:140px;background-size:auto;font-family:"Roboto Mono",monospace !important;font-size:24px;font-weight:bold}#kubeweekly h5{font-size:20px}.subscribe-button{border-radius:6px;padding:0 20px;line-height:31px;color:#fff;background-color:blue;text-decoration:none;font-size:14px}#features{padding-top:140px;background-color:#f7f7f7;background-image:url(/images/wheel.png);background-position:center 60px;background-repeat:no-repeat;background-size:auto}.feature-box{width:100%;overflow:hidden;clear:both}.feature-box h4{line-height:normal;margin-bottom:15px}.feature-box>div:first-child{float:left}.feature-box>div:last-child{float:right}#features h3{margin-bottom:20px}#features .feature-box{margin-bottom:0}#features .feature-box>div{width:100%;margin-bottom:40px}#community.open-nav .logo,#community.flip-nav .logo,.gridPage.open-nav .logo,.gridPage.flip-nav .logo{background-image:url(/images/nav_logo2.svg)}#community #hero,.gridPage #hero{padding-bottom:20px}#community #mainContent,.gridPage #mainContent{padding:20px 0}#community #mainContent main,.gridPage #mainContent main{max-width:none}#community #mainContent a,.gridPage #mainContent a{color:#3371e3}#community #mainContent .content,.gridPage #mainContent .content{margin-bottom:30px;padding:30px 0}#community #mainContent .content h1,#community #mainContent .content h2,#community #mainContent .content h3,#community #mainContent .content h4,#community #mainContent .content h5,#community #mainContent .content h6,#community #mainContent .content p,.gridPage #mainContent .content h1,.gridPage #mainContent .content h2,.gridPage #mainContent .content h3,.gridPage #mainContent .content h4,.gridPage #mainContent .content h5,.gridPage #mainContent .content h6,.gridPage #mainContent .content p{line-height:normal;max-width:1200px;padding:0 20px;margin:0 auto 20px}#community #mainContent .content:nth-child(even),.gridPage #mainContent .content:nth-child(even){background-color:#f7f7f7}#community #mainContent .company-logos,.gridPage #mainContent .company-logos{text-align:center;max-width:1200px;margin:0 auto}#community #mainContent .company-logos img,.gridPage #mainContent .company-logos img{width:auto;margin:10px;background-color:#f7f7f7}#community #mainContent .partner-logos,.gridPage #mainContent .partner-logos{text-align:center;max-width:1200px;margin:0 auto}#community #mainContent .partner-logos img,.gridPage #mainContent .partner-logos img{width:auto;margin:10px;background-color:#fff;box-shadow:0 5px 5px rgba(0,0,0,0.24),0 0 5px rgba(0,0,0,0.12)}#community #mainContent #calendarMeetings,.gridPage #mainContent #calendarMeetings{position:relative;width:80vw;height:60vw;max-width:1200px;max-height:900px;margin:20px auto}#community #mainContent #calendarEvents,.gridPage #mainContent #calendarEvents{position:relative;width:80vw;height:30vw;max-width:1200px;max-height:450px;margin:20px auto}#community #mainContent iframe,.gridPage #mainContent iframe{position:absolute;border:0;width:100%;height:100%}.ui-icon{display:inline-block !important}#feature-state-dialog-link{text-decoration:none !important;padding:5px !important}#feature-state-dialog-link a:visited{color:#454545 !important}#feature-state-dialog-link a code{display:inline-block !important;box-sizing:border-box !important;background-color:#f7f7f7 !important;color:#303030 !important;font-family:"Roboto Mono",monospace !important;vertical-align:baseline !important;font-size:14px !important;font-weight:bold !important;padding:0px 4px !important}#feature-state-dialog{background:#fff !important;border:1px solid #ddd !important;padding:0.5em 1em !important}#feature-state-dialog ul,#feature-state-dialog li{list-style:disc !important;margin:4px 12px !important}#feature-state-dialog p{margin:8px 0px !important}#feature-state-dialog code{display:inline-block !important;box-sizing:border-box !important;background-color:#f7f7f7 !important;color:#303030 !important;font-family:"Roboto Mono",monospace !important;vertical-align:baseline !important;font-size:14px !important;font-weight:bold !important;padding:0px 4px !important}.ui-dialog{background:#f7f7f7 !important;padding:0.5em}.ui-dialog-content{position:relative;float:right;width:100%}.ui-dialog-content *+h2,.ui-dialog-content *+h3,.ui-dialog-content *+h4,.ui-dialog-content *+h5,.ui-dialog-content *+h6{margin-top:30px}.ui-dialog-content h1,.ui-dialog-content h2,.ui-dialog-content h3,.ui-dialog-content h4,.ui-dialog-content h5,.ui-dialog-content h6{line-height:normal;font-weight:500;margin-bottom:30px;padding-bottom:10px}.ui-dialog-content h1:before,.ui-dialog-content h2:before,.ui-dialog-content h3:before,.ui-dialog-content h4:before,.ui-dialog-content h5:before,.ui-dialog-content h6:before{display:block;content:" ";margin-top:-100px;height:100px;visibility:hidden}.ui-dialog-content h1,.ui-dialog-content h2{border-bottom:1px solid #ccc}.ui-dialog-content h1{font-size:32px;padding-right:60px}.ui-dialog-content h2{font-size:28px}.ui-dialog-content h3{font-size:24px;font-weight:300;margin-bottom:5px}.ui-dialog-content h4{font-size:20px;margin-bottom:0px}.ui-dialog-content h5,.ui-dialog-content h6{font-size:16px;font-weight:500}.ui-dialog-content p{font-size:16px;font-weight:300;line-height:1.75em}.ui-dialog-content p+p{margin-top:10px}.ui-dialog-content code{display:inline-block;box-sizing:border-box;background-color:#f7f7f7;color:#303030;font-family:"Roboto Mono",monospace;vertical-align:baseline;font-size:14px;font-weight:bold;padding:2px 4px}.ui-dialog-content a code{color:#3371e3;text-decoration:underline}.ui-dialog-content pre .pi,.ui-dialog-content pre .s{margin:0;padding:0}.ui-dialog-content .highlight code span,.ui-dialog-content code,.ui-dialog-content pre code{font-family:"Roboto Mono",monospace}.ui-dialog-content code,.ui-dialog-content pre code{color:#303030}.ui-dialog-content pre code{padding:0}.ui-dialog-content pre{background-color:#f7f7f7;display:block;margin:20px 0;padding:15px;position:relative;overflow-x:auto}.ui-dialog-content h1 code,.ui-dialog-content h2 code,.ui-dialog-content h3 code,.ui-dialog-content h4 code,.ui-dialog-content h5 code,.ui-dialog-content h6 code{font-family:inherit;font-size:inherit;background-color:transparent}.ui-dialog-content .includecode{table-layout:fixed}.ui-dialog-content .includecode,.ui-dialog-content .includecode th,.ui-dialog-content .includecode td{padding:0 !important}.ui-dialog-content .includecode th{text-align:right !important;padding:10px !important}.ui-dialog-content .includecode th a,.ui-dialog-content .includecode th a code{color:#fff !important;background-color:transparent !important}.ui-dialog-content .includecode pre{margin:0 !important}.ui-dialog-content ul li{list-style:disc}.ui-dialog-content ol li{list-style:decimal}.ui-dialog-content ul,.ui-dialog-content ol{margin:20px 0;padding-left:30px;font-weight:300}.ui-dialog-content ul ul,.ui-dialog-content ol ol,.ui-dialog-content ul ol,.ui-dialog-content ol ul{margin:0.75em 0}.ui-dialog-content li{margin-bottom:0.75em;font-size:16px;line-height:1.75em}.ui-dialog-content table{width:100%;border:1px solid #ccc;border-spacing:0;margin-top:30px;margin-bottom:30px}.ui-dialog-content thead,.ui-dialog-content tr:nth-child(even){background-color:#f7f7f7}.ui-dialog-content thead{background-color:#555;color:#fff}.ui-dialog-content th,.ui-dialog-content td{padding:8px;text-align:left;margin:0}.ui-dialog-content th{font-weight:normal}.ui-dialog-content td{font-size:0.85em}.ui-dialog-content #editPageButton{position:absolute;top:-25px;right:5px;width:50px;height:50px;line-height:50px;border-radius:50%;white-space:nowrap;text-indent:50px;overflow:hidden;background:#3371e3 url(/images/icon-pencil.svg) no-repeat;background-position:12px 10px;background-size:29px 29px}.ui-dialog-content #markdown-toc{margin-bottom:20px}.ui-dialog-content #markdown-toc ul,.ui-dialog-content #markdown-toc li{list-style:disc;color:#3371e3}.ui-dialog-content #markdown-toc ul{padding:0 15px;margin:0}.ui-dialog-content #markdown-toc li{padding:0;line-height:1.5em;margin-bottom:0}.ui-dialog-content #markdown-toc a{position:relative;color:#3371e3;font-weight:700}.ui-dialog-content img{max-width:100%}.ui-dialog-content a{text-decoration:underline}.ui-dialog-content a.button{border-radius:2px;text-decoration:none}.ui-dialog-content a.button:visited{color:#fff}.ui-dialog-content a.issue{margin-left:0px}.ui-dialog-buttonpane{background:#f7f7f7 !important}.ui-widget-header{background:transparent !important;background-color:transparent !important;border:0px !important}.ui-tabs ul,.ui-tabs ol,.ui-tabs li{padding:0px !important;list-style:none !important;margin-bottom:0px !important;margin-left:4px !important}.ui-tabs-panel ul li{list-style:disc !important}.ui-tabs-panel ol li{list-style:decimal !important}.ui-widget-content{border:0px !important}.ui-widget-content p a{color:#3371e3}.ui-widget-content table{margin:0px !important}.ui-tabs .ui-tabs-panel{border:1px solid #ccc !important}.ui-tabs-anchor{text-decoration:none !important}#talkToUs h3,#talkToUs h4{text-align:center}#talkToUs h3{margin-bottom:15px}#talkToUs h4{line-height:normal;margin-bottom:50px}#talkToUs h4 br{display:none}#talkToUs #bigSocial{overflow:hidden}#talkToUs #bigSocial div{width:100%;float:left;padding:30px;padding-top:110px;background-position:center top;background-size:auto;background-repeat:no-repeat}#talkToUs #bigSocial div:nth-child(1){background-image:url(/images/twitter_icon.png)}#talkToUs #bigSocial div:nth-child(2){background-image:url(/images/github_icon.png)}#talkToUs #bigSocial div:nth-child(3){background-image:url(/images/slack_icon.png)}#talkToUs #bigSocial div:nth-child(4){background-image:url(/images/stackoverflow_icon.png)}#talkToUs #bigSocial div+div{margin-top:20px;margin-left:0}#talkToUs #bigSocial a{display:inline-block;color:#3371e3;font-size:24px;font-weight:400;text-decoration:none;margin-bottom:15px}#talkToUs #bigSocial a,#talkToUs #bigSocial p{text-align:center;width:100%}#home #talkToUs main{padding:30px 0}#home #talkToUs h5{font-size:20px}#home #caseStudiesWrapper{position:relative;text-align:center;margin-bottom:30px}#home #caseStudiesWrapper img{padding-bottom:1rem}#home #caseStudiesWrapper div{position:relative;display:inline-block;vertical-align:top;width:100%;min-height:230px;margin-bottom:60px;padding-right:1rem;background-position:top center}#home #caseStudiesWrapper p{font-size:20px}#home #caseStudiesWrapper a{position:absolute;bottom:-30px;left:50%;transform:translateX(-50%);color:#3371e3;font-weight:400}.cse .gsc-control-cse,.gsc-control-cse{padding:0}.gsc-control-cse table,.gsc-control-cse-en table{margin:0px !important}.gsc-above-wrapper-area{border-bottom:0}#bing-results-container{margin-top:30px;margin-left:20px}.bing-result{margin-bottom:20px}.bing-result-name a{font-size:16px;color:#00c}.bing-result-url{color:green;font-size:13px}.bing-result-snippet{color:#000;font-size:11px}#bing-pagination-container{margin:10px;margin-left:20px}.bing-page-anchor{text-decoration:none !important;cursor:pointer;color:#00c;margin-right:8px}.page{display:flex;flex-direction:column;min-height:100vh}.page .page-content{flex:1}.container-404{text-align:center;margin:3.5rem 0}.container-404 ul li a{font-size:1.5rem}#pre-footer{margin-top:2rem}#pre-footer .button{font-size:1.1rem}#pre-footer .button:first-of-type{margin-right:0.75rem}#pre-footer .lastedit{margin-top:1rem;font-size:1rem}@media screen and (min-width: 750px){h1{font-size:32px;line-height:40px}h2{font-size:28px;line-height:60px}h3{font-size:24px;line-height:32px}h4{font-size:20px;line-height:40px}h5{font-size:16px;line-height:36px}p{font-size:14px;line-height:22px}section,header,#vendorStrip{padding-left:20px;padding-right:20px}section main,header main,#vendorStrip main{width:100%;max-width:100%}header{height:80px}.nav-buttons{height:80px;line-height:80px}.nav-buttons .button+*{margin-left:30px}#hamburger{width:50px;height:50px}#mainNav{padding:140px 0 30px}#mainNav h5{margin-bottom:1em}#mainNav h3{margin-bottom:0.6em}#mainNav .nav-box{width:20%}#mainNav .nav-box+.nav-box{margin-left:calc(20% / 3)}#mainNav main+main{margin-top:60px}#mainNav .left .button{height:50px;line-height:50px;font-size:18px}.open-nav #tryKubernetes,.y-enough #tryKubernetes{margin-left:30px}#hero{padding-top:80px}#docs #hero h1,#docs #hero h5{padding-left:20px;padding-right:20px}#vendorStrip{height:88px;line-height:88px;font-size:16px}p{font-size:16px;line-height:24px;letter-spacing:0.1px}h1{font-size:36px;line-height:44px}h3{font-size:28px;line-height:36px}h4{font-size:24px;line-height:40px}#home #viewDocs,#home #tryKubernetes{display:inline-block}#vendorStrip{display:block;text-align:center}#vendorStrip img{max-height:24px;vertical-align:middle;margin:0 30px}#docs #vendorStrip li a{font-size:1em;font-weight:normal}#docs #vendorStrip li li+li{margin-left:60px}#oceanNodes h3{text-align:left;margin-bottom:18px}#oceanNodes main{position:relative;clear:both;display:table;height:160px}#oceanNodes main .content{display:table-cell;position:relative;vertical-align:middle}#oceanNodes main .image-wrapper{position:absolute;top:50%;max-width:25%;max-height:100%;transform:translateY(-50%)}#oceanNodes main:nth-child(odd){padding-right:210px}#oceanNodes main:nth-child(odd) .image-wrapper{right:0}#oceanNodes main:nth-child(even){padding-left:210px}#oceanNodes main:nth-child(even) .image-wrapper{left:0}#oceanNodes main:nth-child(1){padding-right:0}#oceanNodes main:nth-child(1) h3,#oceanNodes main:nth-child(1) p{text-align:center}#oceanNodes main:nth-child(1) .image-wrapper{position:relative;display:block;float:none;max-width:100%;transform:none}#oceanNodes main:nth-child(1) .content{display:block}#oceanNodes main img{width:100%}#video{height:400px;display:block}#video>.light-text{display:block}#mobileShowVideoButton{display:none}#features{padding-bottom:60px}#features .feature-box{margin-bottom:30px}#features .feature-box:last-child{margin-bottom:0}#features h3{margin-bottom:40px}#features .feature-box>div{width:45%;margin-bottom:0}#talkToUs #bigSocial div{width:calc(50% - 15px)}#talkToUs #bigSocial div+div{margin-top:0}#talkToUs #bigSocial div:nth-child(2){margin-left:20px}#talkToUs #bigSocial div:nth-child(4){margin-left:20px}#talkToUs #bigSocial a{display:inline-block;color:#3371e3;font-weight:400;text-decoration:none}footer nav{text-align:center}footer nav a{width:30%;padding:0 20px}footer .social{text-align:center}footer .social div{display:inline-block}footer .social div:last-child{display:block;margin:0}footer .social span{display:inline-block;margin-right:10px}footer .social input{text-align:left}#home #caseStudiesWrapper div{width:48%}}@media screen and (min-width: 1025px){#hamburger{display:none}ul.global-nav{display:inline-block}#docs #vendorStrip #searchBox:before{top:15px}#vendorStrip{height:44px;line-height:44px}#vendorStrip li a.YAH:after{content:"";display:block;position:absolute;left:0;bottom:0;width:100%;height:4px;background-color:#3371e3}#vendorStrip #searchBox{float:right}#home #hero #vendorStrip{display:block}#docs #hero h1,#docs #hero h5{text-align:left}#docs #hero #vendorStrip ul{float:left}#docs #hero #vendorStrip #searchBox{float:right;width:250px}#docs #hero #vendorStrip #search{vertical-align:middle}#docs .flyout-button{display:none}#docs .logo{position:relative;float:left;display:block;width:180px;height:88px;top:0;left:0;transform:none;background-image:url(../images/nav_logo.svg)}#docs.flip-nav .logo,#docs.open-nav .logo{background-image:url(../images/nav_logo2.svg)}#encyclopedia{padding:50px 50px 100px 100px;clear:both}#docsToc{position:relative;float:left;padding:0 20px;left:0;width:350px;z-index:auto}#docsToc .push-menu-close-button{display:none}#docsContent{width:calc(100% - 400px)}#docsContent #editPageButton{right:-25px}section main,header main,footer main{max-width:1200px}header,#vendorStrip,#encyclopedia,#hero h1,#hero h5,#docs #hero h1,#docs #hero h5,#community #hero h1,.gridPage #hero h1,#community #hero h5,.gridPage #hero h5{padding-left:100px;padding-right:100px}#vendorStrip{padding-right:10px}#home section main,#home header main,#home footer main{max-width:1000px}#oceanNodes main{position:relative;max-width:830px}#oceanNodes main:nth-child(1){max-width:1000px;padding-right:475px}#oceanNodes main:nth-child(1) h3,#oceanNodes main:nth-child(1) p{text-align:left}#oceanNodes main:nth-child(1) .image-wrapper{position:absolute;max-width:48%;transform:translateY(-50%)}#oceanNodes main:nth-child(1) .image-wrapper img{max-width:425px}#video{height:550px;position:relative;background-position:center center;background-size:cover}#talkToUs h4 br{display:block}#talkToUs #bigSocial div{width:calc(25% - 18px)}#talkToUs #bigSocial div+div{margin-left:20px}footer{width:100%;background-image:url(../images/texture.png);background-color:#303030}footer main{padding:20px 0}footer nav{overflow:hidden;margin-bottom:20px}footer nav a{width:16.65%;float:left;font-size:24px;font-weight:300;white-space:nowrap}footer .social{padding:0 30px;max-width:1200px}footer .social div{float:left}footer .social div:last-child{float:right}#search,#wishField{background-color:transparent;padding:10px;font-size:16px;font-weight:100;color:#fff;border:1px solid #fff;transition:0.3s}#search:focus,#wishField:focus{background-color:#f7f7f7;color:#303030}.social a{display:inline-block;background-image:url(../images/social_sprite.png);background-repeat:no-repeat;background-size:auto;width:50px;height:50px;border-radius:5px;margin-right:10px}.social a:hover{background-color:#fff}.social a span{position:absolute;display:block;height:0;overflow:hidden}a.twitter{background-position:0 0}a.twitter:hover{background-position:0 100%}a.stack-overflow{background-position:-50px 0}a.stack-overflow:hover{background-position:-50px 100%}a.slack{background-position:-100px 0}a.slack:hover{background-position:-100px 100%}a.github{background-position:-150px 0}a.github:hover{background-position:-150px 100%}a.mailing-list{background-position:-200px 0}a.mailing-list:hover{background-position:-200px 100%}a.calendar{background-position:-250px 0}a.calendar:hover{background-position:-250px 100%}#community #hero,.gridPage #hero{text-align:left}#community #hero h1,.gridPage #hero h1{padding:20px 100px}#community #tryKubernetes,.gridPage #tryKubernetes{width:auto;background-color:#3371e3;padding:0 20px}#bigSocial div{width:calc(25% - 18px)}#home #caseStudiesWrapper div{width:24%;min-height:260px}}@media screen and (min-width: 1300px){#vendorStrip{padding-right:100px}}@media screen and (min-width: 456px){#vendorStrip li+li{margin-left:20px}} diff --git a/static/images/CaseStudy_nav_banner1.jpg b/static/images/CaseStudy_nav_banner1.jpg new file mode 100644 index 0000000000..01ab0f8613 Binary files /dev/null and b/static/images/CaseStudy_nav_banner1.jpg differ diff --git a/static/images/CaseStudy_nav_banner3.jpg b/static/images/CaseStudy_nav_banner3.jpg new file mode 100644 index 0000000000..ea7f50ec29 Binary files /dev/null and b/static/images/CaseStudy_nav_banner3.jpg differ diff --git a/static/images/CaseStudy_nav_banner4.jpg b/static/images/CaseStudy_nav_banner4.jpg new file mode 100644 index 0000000000..aff21af401 Binary files /dev/null and b/static/images/CaseStudy_nav_banner4.jpg differ diff --git a/static/images/blog/2019-03-12-kubeedge-k8s-based-edge-intro/kubeedge-highlevel-arch.png b/static/images/blog/2019-03-12-kubeedge-k8s-based-edge-intro/kubeedge-highlevel-arch.png new file mode 100644 index 0000000000..3bbe0fdbd1 Binary files /dev/null and b/static/images/blog/2019-03-12-kubeedge-k8s-based-edge-intro/kubeedge-highlevel-arch.png differ diff --git a/static/images/blog/2019-03-12-kubeedge-k8s-based-edge-intro/kubeedge-logo.png b/static/images/blog/2019-03-12-kubeedge-k8s-based-edge-intro/kubeedge-logo.png new file mode 100644 index 0000000000..a9237b4b47 Binary files /dev/null and b/static/images/blog/2019-03-12-kubeedge-k8s-based-edge-intro/kubeedge-logo.png differ diff --git a/static/images/blog/2019-03-14-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits/celebrationsig.jpg b/static/images/blog/2019-03-14-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits/celebrationsig.jpg new file mode 100644 index 0000000000..84db1b4e87 Binary files /dev/null and b/static/images/blog/2019-03-14-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits/celebrationsig.jpg differ diff --git a/static/images/blog/2019-03-14-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits/grouppicseatle.JPG b/static/images/blog/2019-03-14-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits/grouppicseatle.JPG new file mode 100644 index 0000000000..2f1b270a20 Binary files /dev/null and b/static/images/blog/2019-03-14-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits/grouppicseatle.JPG differ diff --git a/static/images/blog/2019-03-14-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits/newcontrib.jpg b/static/images/blog/2019-03-14-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits/newcontrib.jpg new file mode 100644 index 0000000000..bc47015088 Binary files /dev/null and b/static/images/blog/2019-03-14-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits/newcontrib.jpg differ diff --git a/static/images/blog/2019-03-14-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits/unconference.jpg b/static/images/blog/2019-03-14-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits/unconference.jpg new file mode 100644 index 0000000000..d814181243 Binary files /dev/null and b/static/images/blog/2019-03-14-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits/unconference.jpg differ diff --git a/static/images/blog/2019-03-21-a-guide-to-kubernetes-admission-controllers/admission-controller-phases.png b/static/images/blog/2019-03-21-a-guide-to-kubernetes-admission-controllers/admission-controller-phases.png new file mode 100644 index 0000000000..fe6db00cc9 Binary files /dev/null and b/static/images/blog/2019-03-21-a-guide-to-kubernetes-admission-controllers/admission-controller-phases.png differ diff --git a/static/images/nav_logo.png b/static/images/nav_logo.png new file mode 100644 index 0000000000..56319417b8 Binary files /dev/null and b/static/images/nav_logo.png differ