- In `release v1.7`, navigating selector to version `v1.10` disappears
- modified `_config.yml` in branch `release-1.7`
Signed-off-by: harshvkarn <harshvkarn54@gmail.com>
* Chinese translation: 7.24-9.3, by shirdrn.
* Translate and review again, and fix any translation problems for these 14 docs.
* Delete network-policies.md temporarily, and then re-submit it for this PR.
- change afinity field value to match yaml spec
- update and reorder steps for cordoning nodes to make more sense. currenlty says "all but four". In reality, want to cordon the three nodes that the pods are scheduled on. not "all but four".
- add new line to code snippet for easier "copy/paste"
these links don't go anywhere anymore (the respective pages must have been moved?), and are more of a distraction than adding any real value when reading that paragraph.
* Update organize-cluster-access-kubeconfig.md
Explain that context is just a named group for convenience, and
that current context is used by default if no other params are present
* Update organize-cluster-access-kubeconfig.md
* Revert "Fix the doc example"
This reverts commit 2872def62b.
* Revert "add the set of sessionAffinity timeoutseconds (#5474)"
This reverts commit 657734de6f.
* Revert "pod-security-policy.md: fix broken link to PSP proposal."
This reverts commit 8db51e099f.
* Revert "fix typo"
This reverts commit 24e5383071.
* Revert "Update images.md"
This reverts commit f844a41502.
* Revert "Update links to avoid redirects. (#5614)"
This reverts commit 35c7393849.
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
ZTE-SH-CN-debug-pod-replication-controller-2017-09-14-14
ZTE-SH-CN-define-command-argument-container (#5381)
Update index.md
Update Kompose docs
Improve host aliases page (#5443)
Add link to AlwaysPullImages admission controller
Revert "create homepage for user journeys"
create homepage for user journeys
fix the command output
ZTE-SH-CN-run-application-run-single-instance-stateful-application-pr-2017-… (#5363)
Add a note to static pod manifest scanning
revert WordPress and MySQL PV doc changes to use apps/v1beta2 APIs (#5461)
Fix pod probes yaml file
Redirect v1 docs. (#5460)
Fix error link (#5459)
Fix typo in deployment documentation
My nvidia GPU name was "GeForce GTX 1070" which isn't a correct label
"a valid label must be an empty string or consist of alphanumeric characters, '-', '_' or '.', and must start and end with an alphanumeric character"
The SSL-on-AWS documentation was missing a critical annotation, without which SSL termination doesn't work (all ports are configured to use SSL).
This also fixes the indentation of the existing YAML.
The command was failing with
error: error parsing jsonpath {range, unclosed action
We need to quote `$JSONPATH` so the full contents of the variable are
passed to `-o jsonpath=`.
Fixes#4258
- Fixes an inaccuracy: `template: metadata: labels:` labels the Pod template rather than the containers
- Elaborates some more on the explanation of the manifest
Fix the mistakes in the "StatefulSet Basics"
In the section "Updating StatefulSets", when the update strategy is OnDelete and the web-0 pod is updated by deleting it manually.
Then the web-1 and web-2 should still have the original image. But in the current version, the article says that the web-0 and web-1
still have the original image.
This patch refactors the admin/admission-controllers section:
- Reorder the built-in controllers based on their names
- Added controllers that were not documented:
* GenericAdmissionWebhook
* Initializers
* LimitPodHardAntiAffinity
* NamespaceAutoProvision
* NamespaceExists
* OwnerReferencesPermissionEnforcement
* PersistenVolumeLabel
* PodPreset
* PodTolerationRestriction
* 'master' of https://github.com/kubernetes/kubernetes.github.io: (23 commits)
concepts/configuration/manage-compute-resources-container.md: fix a conversion (#4952)
Update authentication.md (#5281)
Update static-pod.md for consistency
Space needed before list in kramdown.
Update downward-api-volume-expose-pod-information.md
fix the command output
fix the command output
fix the command output
fix the command output
fix the command output
Fix CRD page typo
fix 404 page
Update binary_release.md
Update disruptions.md
fix the command output
fix typo
fix the command output
Fix curl does not work in zsh
use the term 'node' for consistency
fix typo
...
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
Update photon-controller.md (#5279)
add back Zach and Steve to PR assignment
fix the command output
Update troubleshooting.md
Update guaranteed-scheduling-critical-addon-pods.md
Include filename fix (#5139)
k8s-tutorials-stateful-application (#5112)
Update gce.md (#5163)
Update stage-documentation-changes.md (#5213)
fix the command output
Fix token-authentication-file internal link
* Update photon-controller.md
Fix format: number order in Prerequisites Part is 1->2->3->4->5->6, rather than 1->2->1->1->2->3
* add intents to fix ordered bullets
* Update stage-documentation-changes.md
Fix the format. The format in orginal web page is confusion.
* convert note to callout
* make note multiline
* fix code block
* 'master' of https://github.com/kubernetes/kubernetes.github.io: (32 commits)
Fixed broken link to Pods concept documentation (#5223)
Update some docs in /cn/docs (#4842)
Update deployment.md
fix the command output
Translate into chinese about NetworkPolicy
rootsongjc-pr-20170815
fix typo
fix the command output
Translate into chinese about GPU
index-pr-2017-08-15
Example links use kubernetes/examples
Make caret for version drop-down more visible
fix typo:ConfigMap
fix the command output
Fixed incorrect links for YAML files
Clean up the index page.
Remove broken link.
Update pod names to match what's in the spec.
Update daemonset.md
Update configure-aggregation-layer.md
...
* Add docs in Chinese
Add configure-redis-using-configmap.md in Chinese
* Modify docs in Chinese
Modify imperative-object-management-command.md in Chinese
When going through this section of the documentation, I found myself
wishing the concepts linked to the relevant documentation, so I could
verify I understood the concepts.
Remove the custom modules description in the authorization and
authentication docs. While we could add more later, we probably
don't want to advertise them to end users.
Also note that the authentication webhook and authenticating proxy
can be used to integrate with unsupported auth protocols.
Going through the guestbook tutorial for the first time,
the deployment configuration mentioned that whether my configuration
included a DNS service would dictate which env value I used for the
`GET_HOSTS_FROM` variable. According to
https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/,
k8s includes DNS by default starting with v1.3.
Add this additional info to help the user better understand when DNS
may/may not be enabled.
I struggled to discover information on how to specify a kubernetes
version when starting minikube. Ultimately, I found the answer through
searching Github issues, and also running `minikube start --help`.
Given it seems like a fairly common task, I think it could be useful to
include it in the getting started documentation.
On the concept overview page there are lists of example concepts.
Currently only two are linked to (and one of those to an old location).
This change adds links to all of the concepts so that a new user quickly
see some exaple concepts.
* [glossary] Glossary MVP
* resolve conflict
* initial pass at includable glossary data
* tag to term mapping
* Change StatefulSets to singular, StatefulSet
* revise glossary style guide, move
* make descriptions plural
* tutorials/guestbook: fix broken links
Importing from kubernetes/examples repository.
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
* Import newer versions for guestbook and cassandra
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
* Update mysql-wordpress-pd import script
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
* Import wordpress-mysql tutorial
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
* Update scheduling-gpus.md
It sounds like that kubelet will not automatically load the nvidia uvm driver,I have recurrent it when my cluster reboot nvml driver and nvidia-uvm driver not loaded.
To fix it simply,make the docker-plugin autostart.
I think it's important to tell other developers to prevent this situation
* Update scheduling-gpus.md
* Update kubectl-overview.md
The first letter of "where" should be capital, and some lost "." should be added.
* Update kubectl-overview.md
* Update kubectl-overview.md
* Deprecated docs warning
* Unknown tag 'endcomment'
* only add css when necessary
* try lighter bgcolor
* tweak copy
* change development url to point at vnext-staging
* try callout
* rollback
* change var names
* update var used
* fix var typo
* turn off deprecation message
* Show current version of docs in nav
* Branch in edit link
* WIP version selector
* An actual working but not pretty version dropdown
* update URLs for versions
v1.7: https://kubernetes.io/docs/home/
v1.6: https://v1-6.docs.kubernetes.io/docs/home/
v1.5: https://v1-5.docs.kubernetes.io/docs/home/
v1.4: https://v1-4.docs.kubernetes.io/docs/home/
* fix v1.4 and v1.5 paths
* Tidier drop downs
* Make font visible always
* Make background match main nav always
* change to major.minor version number
* show only major.minor version in drop down list
* switch from githubbranch to docsbranch
* update githubbranch
* update githubbranch values
* Border radius for bottom of dropdown
* Tabs are hard
* Update master-node-communication.md
Not working Links are updated
* Update master-node-communication.md
changed based on suggestion
* updated as per suggestion
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
fix noindex for vnext-staging (#4640)
Add network overlay details to cloud routes flag
Revert "Update volumes.md"
add examples for interpod configurations (#4557)
Update "readonly" in abac
* add examples for interpod configurations
* re-word and fix typo based on review comments
* explain podAffinity with examples
* review comments: make replicas 3 for both workload types
* Address final review comments
kube-apiserver heading did not render correct on my Chrome. The change did nothing to the github preview so maybe there is a fix already, but consistency with the other headings might be worth the change.
Hi, we've created and are maintaining the kubernetes-py library. It uses python objects to manipulate the kubernetes API objects. We're using it to manage our operations on kubernetes daily.
Initial PR to reflect new scalability limits. I have assumed the new number of total containers from the previous relationship but would prefer Wojciech to confirm
* Update the reference docs for kubefed
* fix syntax typos
* add period
* fix ToC links
* fix kubefed link
* revert to Kubefed title as link
* Add kubefed reference docs for the first time
* Add link for base kubefed command also
* secrets: add a best practices section and API access recommentations (#4380)
* secrets: add a best practices section and API access recommentations
This section attempts to capture some of the best practices around
client API access to secrets. Specitically that controllers should
avoid list and watch operations in favor of getting specific secrets.
* add "are"
* update scratch.md for issue #4068 (#4069)
* update scratch.md for issue #4068
Issue #4068 details the dangers of recommending single etcd instance.
This will likely need to be expanded into better "highly available" cluster documentation
* Refactor list style
* fix ordered list
* fix unordered list
* ul
* add back shell
* Adding tutorial links to docs (#4570)
* Adding tutorial links to docs
* Update index.md
* update scratch.md for issue #4068
Issue #4068 details the dangers of recommending single etcd instance.
This will likely need to be expanded into better "highly available" cluster documentation
* Refactor list style
* fix ordered list
* fix unordered list
* ul
* add back shell
* secrets: add a best practices section and API access recommentations
This section attempts to capture some of the best practices around
client API access to secrets. Specitically that controllers should
avoid list and watch operations in favor of getting specific secrets.
* add "are"
* Update assign-pod-node.md
I am a freshman on Kubernetes development.When I use the affinity feature,it confuses me that why the pod won't stop after I changing the node's label which makes the node no longer satisfy the affinity condition.Although I learn how this feature works by community, I hope the documentation can help people especially fresh man better.^_^
* Update assign-pod-node.md after review
I have fixed the commit after review
* Fix incorrect link and add missing ones for pod template
The current link to the pod template is pointing to replication controller
page. Also couple places missing a link to get better view of what pod
template is.
* fix pod link
* fix pods url
Fix restartPolicy indent.
Use valid keys from the ConfigMap in the step previous to the last special-config creation. Key special.type was not created anywhere in previous steps anywars.
Looks like
```
the cluster operator may want to set limits that a pod must consume at least 20% of the memory and CPU
```
was meant to be
```
the cluster operator may want to set limits that a pod must consume no more than 20% of the memory and CPU
```
* Fix Typo - "TokenAccessReviewStatus" -> "status"
"TokenAccessReview" is the value of the "kind" field of the request and response. The webhook has to fill in the "status" field to indicate authenticate pass/fail status.
* Use back ticks for spec
For consistency highlight spec better using back ticks
* Fix typos and add a paragraph for initializers doc
- Fixed a few consistency issues and typos in the doc
- Also fixed an username typo in assignees
- Added a paragraph explaining how the example initializerconfiguration will
be applied once it is created.
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
* Add .pending to metadata.initializers, re-wording
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
* Create callouts.css
* Linking callouts.css
* Alphabetical order
* Added doc for using callouts
* Fix link
* Deleting info
* Updates per Ahmet
Added more detailed examples and a common issues section
* Update style-guide.md
- "SubjectAccessReview" is the value of the "kind" field of the request and response. The webhook has to fill in the "status" field to indicate authorization passed or failed.
- For consistency highlight spec better using back ticks
The docs tell the reader to get a ConfigMap with the name `game-config-2`, but only one ConfigMap had been made in the documentation thusfar, `game-config`. This PR simply changes the name of that ConfigMap to the only existing ConfigMap if the reader follows the docs.
* Add CSS files for Ancestry case study
* Add HTML file for Ancestry case study
* Add images for Ancestry case study
* Delete golfnow.png
* Add files via upload
* Update index.html
* Delete ancestry-logo.png
* Add files via upload
* Update index.html
* Update style_ancestry.css
* All files for Wink case study and updated index files and logo fixes
* Update ancestry.html
* Update ancestry.html
In canonical American English, "large" is generally used to describe the size of a number. This is purely a style change, but "large number of" is less awkward sounding than "big number of".
This imports the tutorials from kubernetes/examples repository for the first
time. It adds "DO NOT UPDATE" notices and updates some titles. These tutorials
will be maintained at k/examples repository.
Also fixing a bug in the update script (we were inserting the `<!--` comments
before the metadata section on the top, causing articles to render incorrectly).
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* fix layout and logo
* fix golfnow layout and logo
* fix golfnow link
* Update box.html
* Update golfnow.html
* add custom css logic
* switch layouts back to *basic*
* remove class gridPage
* debug
* Update style_golfnow.css
realized the footer class was what making the bg dark, so added an override to white
* remove logo class on logo image
* remove logo class from golfnow image
* add mechanism to turn off default styles
* debug liquid logic
* rename variable
* Setup custom SASS
* test custom sass for case studies
* remove class for image logos
* cleanup and simplify
* New logo for landing page
* change GolfNow logo on landing page
* fix spacing on case studies landing page
* Updated custom sass
Fixed mobile issues and some spacing issues
* Update _case-studies.sass
* Update _case-studies.sass
The given example results in:
```
The NetworkPolicy "test-network-policy" is invalid: spec.ingress[0].ports[0].protocol: Unsupported value: "tcp": supported values: TCP, UDP
```
This Python script imports the tutorials that are going to be maintained
at the https://github.com/kubernetes/examples repository. Currently only
pulls the tutorials from master ref of examples.
This script:
- Deletes content between `<!-- EXCLUDE_FROM_DOCS BEGIN -->` and
`<!-- EXCLUDE_FROM_DOCS END -->` (including the markers). This is to drop
website redirection notices appear in the examples repo.
- Adds Jekyll title to the imported docs. The title can be customized so we do
not need to parse h1 elements from the markdown.
- Insert "DO NOT UPDATE" section (commented out HTML) to the markdown files
that are imported.
Once merged, I will go ahead and update the tutorials in kubernetes/examples,
then I will run this script and check in its results in a separate PR.
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
* Remove self-links with domain names in docs
Fixes#4191. Skipping the tutorials we import from kubernetes/examples.
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
* update federation/index.md user-guide links
* update assign-pod-node.md links
* update dns-pod-service.md link
* update link in jobs-run-to-completion.md
* update link in minikube.md
* update PS link in minikube.md
* update links in stackpoint.md
* update links in storage.md
* fix link in vsphere.md
* fix links in deprecation-policy.md
* Update pick-right-solution.md
* Update web-ui-dashboard.md
* Update ingress.md
* Update federation-service-discovery.md
* Update user-guide.md
* Update expose-external-ip-address.md
* Update README.md
* Update README.md
Add concept page about the Kubernetes API client libraries explaining what they
do and list officially-supported & community-maintained client libraries.
The list is obtained from https://github.com/kubernetes/community/blob/master/contributors/devel/client-libraries.md
and I am planning to add a notice there urging people to update the
/docs/reference/client-libraries.md when they add something there.
Alternatively we could remove that page altogether.
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
This helps shortening the /docs/tasks→Administer Cluster section by creating
a section for current and future networking providers. Also changing the
NetworkPolicy to Network Policy in titles.
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
The referenced doc doesn't mention "kube-proxy" anywhere and I don't think this is a general best-practice in many environments. And even if it is the opinion doesn't help users.
Reading through the communication patterns it was not obvious to me that the `hostPort` option is something I have to set myself.
While the **DNS** and **Service** options explicitly say one has to *create a service*.
There is no "kubectl" section in this page. And non-resource urls do not
have too much relationship with kubectl(At least I think so), so we
don't need "see kubectl"
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
Fix a couple of typos in tasks/debug-application-cluster/audit.md
Add an explanation of how the kubeadm kubelet dropin file works and a note about cAdvisor
All files for both new case study pages (#4235)
Add empty layout template
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* Add files via upload
* fix layout and logo
* fix golfnow layout and logo
* fix golfnow link
* Minor fixes in the Deployment doc
Signed-off-by: Michail Kargakis <mkargaki@redhat.com>
* add NodeRestriction to admission-controllers (#3842)
* Admins Can Configure Zones in Storage Class
The PR #38505 (https://github.com/kubernetes/kubernetes/pull/38505) added zones optional parameter to Storage Class for AWS and GCE provisioners.
That's why documentation needs to be updated accordingly.
* document custom resource definitions
* add host paths to psp (#3971)
* add host paths to psp
* add italics
* Update ConfigMap doc to explain TTL-based cache updates (#3989)
* Update ConfigMap doc to explain TTL-based cache updates
* swap word order
Change "When a ConfigMap being already consumed..." to "When a ConfigMap already being consumed..."
* Update NetworkPolicy docs for v1
* StorageOS Volume plugin
* Update GPU docs
* docs: HPA autoscaling/v2alpha1 status conditions
This commit documents the new status conditions feature for HPA
autoscaling/v2alpha1. It demonstrates how to get the status conditions
using `kubectl describe`, and how to interpret them.
* Update description about NodeRestriction
kubelet node can alse create mirror pods for their own static pods.
* adding storage as a supported resource to node allocatable
Signed-off-by: Vishnu kannan <vishnuk@google.com>
* Add documentation for podpreset opt-out annotation
This adds the annotation for having the podpreset admission controller
to skip (opt-out) manipulating the pod spec.
Also, the annotation format for what presets have acted on a pod has
been modified to add a prefix of "podpreset-". The new naming makes it such
that there is no chance of collision with the newly introduced opt-out
annotation (or future ones yet to be added).
Opt-out annotation PR:
kubernetes/kubernetes#44965
* Update PDB documentation to explain new field (#3885)
* update-docs-pdb
* Addressed erictune@'s comments
* Fix title and add a TOC to the logging concept page
* Patch #4118 for typos
* Describe setting coredns server in nameserver resolv chain
* Address comments in PR #3997.
Comment is in
https://github.com/kubernetes/kubernetes.github.io/pull/3997/files/f6eb59c67e28efc298c87b1ef49a96bc6adacd1e#diff-7a14981f3dd8eb203f897ce6c11d9828
* Update task for DaemonSet history and rollback (#4098)
* Update task for DaemonSet history and rollback
Also remove mentions of templateGeneration field because it's deprecated
* Address comments
* removed lt and gt as operators (#4152)
* removed lt and gt as operators
* replace lt and gt for node-affinfity
* updated based on bsalamat review
* Initial draft of upgrade guide for kubeadm clusters.
In-place upgrades are supported between 1.6 and 1.7 releases. Rollback
instructions to come in a separate commit.
Fixes https://github.com/kubernetes/kubeadm/issues/278
* Add local volume documentation (#4050)
* Add local volume documentation
* Add PV local volume example
* Patch PR #3999
* Add documentation for Stackdriver event exporter
* Add documentation about controller metrics
* Federation: Add task for setting up placement policies (#4075)
* Add task for setting up placement policies
* Update version of management sidecar in policy engine deployment
* Address @nikhiljindal's comments
- Lower case filenames
- Comments in policy
- Typo fixes
- Removed type LoadBalancer from OPA Service
* Add example that sets cluster selector
Per-@nikhiljindal's suggestion
* Fix wording and templating per @chenopis
* PodDisruptionBudget documentation Improvements (#4140)
* Changes from #3885
Title: Update PDB documentation to explain new field
Author: foxish
* Added Placeholder Disruptions Concept Guide
New file: docs/concepts/workloads/pods/disruptions.md
Intented contents: concept for Pod Disruption Budget,
cross reference to Eviction and Preemption docs.
Linked from: concepts > workloads > pods
* Added placeholder Configuring PDB Task
New file: docs/tasks/run-application/configure-pdb.md
Intented contents: task for writing a Pod Disruption Budget.
Linked from: tasks > configuring-applications > configure pdb.
* Add refs to the "drain a node" task.
* Refactor PDB docs.
Move the "Requesting an eviction" section from:
docs/tasks/administer-cluster/configure-pod-disruption-budget.md
-- which is going away -- to:
docs/tasks/administer-cluster/safely-drain-node.md
The move is verbatim, except for an introductory sentence.
Also added assignees.
* Refactor of PDB docs
Moved the section:
Specifying a PodDisruptionBudget
from:
docs/tasks/administer-cluster/configure-pod-disruption-budget.md
to:
docs/tasks/run-application/configure-pdb.md
because that former file is going away.
Move is verbatim.
* Explain how Eviction tools should handle failures
* Refactor PDB docs
Move text from:
docs/tasks/administer-cluster/configure-pod-disruption-budget.md
to:
docs/concepts/workloads/pods/disruptions.md
Delete the now empty:
docs/tasks/administer-cluster/configure-pod-disruption-budget.md
Added a redirects_from section to the new doc, containing the path
of the now-deleted doc, plus all the redirects from the deleted
doc.
* Expand PDB Concept guide
Building on a little content from the old task,
greatly expanded the Disruptions concept
guide, including an abstract example.
* Update creating a pdb Task.
* Address review comments.
* Fixed for all cody-clark's review comments
* Address review comments from mml
* Address review comments from maisem
* Fix missing backtick
* Api and Kubectl reference docs updates for 1.7 (#4193)
* Fix includes groups
* Generated kubectl docs for 1.7
* Generated references docs for 1.7 api
* Document node authorization mode
* API Aggregator (#4173)
* API Aggregator
* Additional bullet points
* incorporated feedback for apiserver-aggregation.md
* split setup-api-aggregator.md into two docs and address feedback
* fix link
* addressed docs feedback
* incorporate feedback
* integrate feedback
* Add documentation for DNS stub domains (#4063)
* Add documentation for DNS stub domains
* add additional prereq
* fix image path
* review feedback
* minor grammar and style nits
* documentation for using hostAliases to manage hosts file (#4080)
* documentation for using hostAliases to manage hosts file
* add to table of contents
* review comments
* update the right command to see hosts file
* reformat doc based on suggestion and change some wording
* Fix typo for #4080
* Patch PR #4063
* Fix wording in placement policy task introduction
* Add update to statefulset concepts and basic tutorial (#4174)
* Add update to statefulset concpets and basic tutorial
* Address tech comments.
* Update ESIPP docs for new added API fields
* Custom resource docs
* update audit document with advanced audit features added in 1.7
* kubeadm v1.7 documentation updates (#4018)
* v1.7 updates for kubeadm
* Address review comments
* Address Luke's comments
* Encrypting secrets at rest and cluster security guide
* Edits for Custom DNS Documentation (#4207)
* reorganize custom dns doc
* format fixes
* Update version numbers to 1.7
* Patch PR #4140 (#4215)
* Patch PR #4140
* fix link and typos
* Update PR template
* Update TLS bootstrapping with 1.7 features
This includes documenting the new CSR approver built into the
controller manager and the kubelet alpha features for certificate
rotation.
Since the CSR approver changed over the 1.7 release cycle we need
to call out the migration steps for those using the alpha feature.
This document as a whole could probably use some updates, but the
main focus of this PR is just to get these features minimally
documented before the release.
* Federated ClusterSelector
formatting updates from review
* complete PR #4181 (#4223)
* complete PR #4181
* fix security link
* Extensible admission controller (#4092)
* extensible-admission-controllers
* Update extensible-admission-controllers.md
* more on initializers
* fixes
* Expand external admission webhooks documentation
* wrap at 80 chars
* more
* add reference
* Use correct apigroup for network policy
* Docs changes to PR #4092 (#4224)
* Docs changes to PR #4092
* address feedback
* add doc for --as-group in cli
Add doc for this pr:
https://github.com/kubernetes/kubernetes/pull/43696
This includes documenting the new CSR approver built into the
controller manager and the kubelet alpha features for certificate
rotation.
Since the CSR approver changed over the 1.7 release cycle we need
to call out the migration steps for those using the alpha feature.
This document as a whole could probably use some updates, but the
main focus of this PR is just to get these features minimally
documented before the release.
* Add no_proxy settings one might need to use minikube and kubectl behind a proxy.
* add extra line before shell block for formatting
* include suggestions from chenopis
* Fix installing autocompletion documentation
The written solution did not work for me with the error `-bash: __git_ps1: command not found`. Since the auto-completion is already installed you can simply add the Kubernetes autocompletion to it.
* Remove sourcing bash-completion in .bash_profile
* Removed -fs from troubleshooting command
* Add YAML file for configmaps in concepts
* Add new topic for configmaps in concepts
* Add configuration entry for understanding configmaps
* Move Understanding Configmaps to a separate concept file
* Revert "Move Understanding Configmaps to a separate concept file"
This reverts commit 71bd80d7bccd090d0aa1829ae9e4db6cc4dc590c.
* Revert "Add configuration entry for understanding configmaps"
This reverts commit c27fc13f56453dff6e6b8b8f1f9641cbad8ace53.
* Revert "Add new topic for configmaps in concepts"
This reverts commit 3d535f59170a4b5cb290975871f167217484e7ab.
* Revert "Add YAML file for configmaps in concepts"
This reverts commit 8ecabd6d106647631819441be8bf7e834f0dbb54.
* documentation for using hostAliases to manage hosts file
* add to table of contents
* review comments
* update the right command to see hosts file
* reformat doc based on suggestion and change some wording
In copyCode function, removes target.value from if (succeed) sweetAlert function.
Sometimes target.value is too long, which causes the sweetAlert box to be cut off from the page. The confirmation button also gets cut off, which means that the user can't close the box, which means they need to refresh the page to continue.
Instead, the alert tells the user which file was copied.
* Changes from #3885
Title: Update PDB documentation to explain new field
Author: foxish
* Added Placeholder Disruptions Concept Guide
New file: docs/concepts/workloads/pods/disruptions.md
Intented contents: concept for Pod Disruption Budget,
cross reference to Eviction and Preemption docs.
Linked from: concepts > workloads > pods
* Added placeholder Configuring PDB Task
New file: docs/tasks/run-application/configure-pdb.md
Intented contents: task for writing a Pod Disruption Budget.
Linked from: tasks > configuring-applications > configure pdb.
* Add refs to the "drain a node" task.
* Refactor PDB docs.
Move the "Requesting an eviction" section from:
docs/tasks/administer-cluster/configure-pod-disruption-budget.md
-- which is going away -- to:
docs/tasks/administer-cluster/safely-drain-node.md
The move is verbatim, except for an introductory sentence.
Also added assignees.
* Refactor of PDB docs
Moved the section:
Specifying a PodDisruptionBudget
from:
docs/tasks/administer-cluster/configure-pod-disruption-budget.md
to:
docs/tasks/run-application/configure-pdb.md
because that former file is going away.
Move is verbatim.
* Explain how Eviction tools should handle failures
* Refactor PDB docs
Move text from:
docs/tasks/administer-cluster/configure-pod-disruption-budget.md
to:
docs/concepts/workloads/pods/disruptions.md
Delete the now empty:
docs/tasks/administer-cluster/configure-pod-disruption-budget.md
Added a redirects_from section to the new doc, containing the path
of the now-deleted doc, plus all the redirects from the deleted
doc.
* Expand PDB Concept guide
Building on a little content from the old task,
greatly expanded the Disruptions concept
guide, including an abstract example.
* Update creating a pdb Task.
* Address review comments.
* Fixed for all cody-clark's review comments
* Address review comments from mml
* Address review comments from maisem
* Fix missing backtick
Addresses the work described at #4134.
- Remove /docs/samples page: This page mostly had links to examples on
kubernetes/kubernetes (examples dir) which is now at kubernetes/examples
repository. It was linking to README.md files for tutorials. Now removing
this page as we are moving tutorials from kubernetes/examples to here:
- Create redirects from /docs/samples/ to /docs/tutorials/ (both JS and
redirect_from).
- Deprecate "MEAN Stack" tutorial: This tutorial overlaps quite a bit with
existing "maintained" examples and has been out-of-date for a while.
Creating an external redirect to its original and more up-to-date location:
https://medium.com/google-cloud/running-a-mean-stack-on-google-cloud-platform-with-app-engine-and-mongolab-4bbd2040ea75
- Import README.md files of maintained examples (guestbook, wordpress+mysql and
cassandra) to this repository and serve them under /docs/tutorial.
- Update /docs/tutorials ToC:
- Link to imported tutorials.
- Fix missing articles on sidebar (_data/tutorials.yml) and make the tutorials
listed on tutorials/index.md available on the sidebar (closes#4007).
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
* Add task for setting up placement policies
* Update version of management sidecar in policy engine deployment
* Address @nikhiljindal's comments
- Lower case filenames
- Comments in policy
- Typo fixes
- Removed type LoadBalancer from OPA Service
* Add example that sets cluster selector
Per-@nikhiljindal's suggestion
* Fix wording and templating per @chenopis
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
Document kubeadm KUBELET_DNS_ARGS issue
CronJobs aren't enabled in 1.6 by default
Fix typo
Document pod-template-hash label
Rename last remaining reference of kargo to kubespray
* Update installation instructions with snap
Update installation instructions with snap - the package manager for Ubuntu and other Linux distributions.
* fix md formatting
* fix shell formating
* fix shell block
* fix shell for Check the kubectl configuration
* switch to full width shell
* Update scratch.md: include download binary tarball
As `kubernetes-server-linux-amd64.tar.gz` is not provided with the tarball now, an extra step is required.
* Updated scratch.md to follow review comments
* rename kargo to kubespray in getting started docs
* remove old kargo guide, update link to kubespray doc
* update setup.yml with new kubespray pointer
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
whatisk8s - Chinese version (#3243)
split rows and nest to stack columns (#4129)
Updates to docs/admin/kubelet-tls-bootstrapping (#3617)
Replace "Pod Injection Policy" with "Pod Preset" (#3667)
Change example PersistentVolumeClaim
add PodNodeSelector to admission-controllers (#3691)
Get pods using a label selector instead of hardcoded indexes. Use JsonPath instead of go-template.
correct_init_container_state (#3972)
kubernetes.github.io/docs/tasks/administer-cluster: operating etcd clusters
Remove --no-check-certificate flag in bare_metal_offline.md
If a default storage class exists, it is going to create a new persistent volume to bind to that claim instead of using our example one, which will make the tutorial fail. In particular, this happens on minikube.
Specifying an empty storageClassName will prevent the storage class to be used, and force our volume to be selected.
Using `--no-check-certificate` is, frankly, dangerous and we shouldn't be recommending that users use it. Not without a good reason, anyway.
If a user's system is sufficiently broken that they are getting certificate validation problems during this step, I fail to see how it is our problem to tell the user to overcome that. Let's focus on installing Kubernetes here.
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
networkpolicies.md --> network-policies.md for SEO
Added link (#4161)
Use "sudo -i" instead of "sudo su -"
Create a section for kubeadm topics
Consolidate SecurityContext topics. (#4005)
Typo fix in "Adding ConfigMap data to a Volume" section (#3966)
`sudo su -` is redundant, as you are asking the system to elevate you after you have already elevated.
If what you actually want is to get a login environment, the `sudo -i` flag is designed exactly for that.
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
bump openstack cli tools versions to working values
fix header size for sub-sections under Services
Finish #4036
Be more specific about cpu-shares passed to Docker (#4016)
Clarify the required uniqueness of Label Key
Add --show-all to documentation
docs(service): remove invalid `,` from example
Add "remove" example for kubectl patch (#4042)
Fix wrong link to create a ConfigMap
Fix a typo in the High Availability docs (#4048)
Remove ports from ExternalName Service example
remove extra that
update kops installation instructions
Docker documentation (https://docs.docker.com/engine/reference/run/) reads:
"To modify the proportion from the default of 1024, use the -c or --cpu-shares flag to set the weighting to 2 or higher. If 0 is set, the system will ignore the value and use the default of 1024."
So the Kubernetes documentation gives the impression that if requests.cpu is zero, Docker would end up applying a value of 1024, which isn't the case.
This change makes the explanation more precise, hopefully without making it much more difficult to read.
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
fixes typos and corrects links in the minikube guide (#4051)
Use native patch functionality instead of JQ
add the introduce of using wildcard '*' in nonResourceURL
Rephrase doc about Deployment .spec.rollbackTo field
create-cluster-kubeadm: add ToC using task template
install-kubeadm: fix What's Next link text
This adds the annotation for having the podpreset admission controller
to skip (opt-out) manipulating the pod spec.
Also, the annotation format for what presets have acted on a pod has
been modified to add a prefix of "podpreset-". The new naming makes it such
that there is no chance of collision with the newly introduced opt-out
annotation (or future ones yet to be added).
Opt-out annotation PR:
kubernetes/kubernetes#44965
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
info about cron jobs updated (#4110)
fix example in configure-pod-configmap.md
Remove extraneous files from autogeneration of ref pages. (#4044)
Add notes for file/flag precedence
Removed "networked" from PersistentVolume (PV) definition. (#4121)
Fix syntax err in example
* Remove extraneous files from autogeneration of ref pages.
* Revert "Remove extraneous files from autogeneration of ref pages."
This reverts commit 39ec47ee44354c96070f89064374eb729d6da5ec.
This commit documents the new status conditions feature for HPA
autoscaling/v2alpha1. It demonstrates how to get the status conditions
using `kubectl describe`, and how to interpret them.
* update pod persistent volume example storage class
When binding to a manually created PersistentVolume, the claim must
disable dynamic provisioning by specifying an empty storage class.
Fixes#2803
* use specific storageclass
* revert gibibytes -> gigabytes change
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
fixed the line giving the template for creating configmap, should include the word configmap as part of the creation process.
Fixes issue #3939
Add CRI runtime support
e.g. "Issue with k8s.io/docs/getting-started-guides/kubeadm/" when people
open issues on the repo. This way we can just select the text, right-click
and say Go to Link.
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
* Update ConfigMap doc to explain TTL-based cache updates
* swap word order
Change "When a ConfigMap being already consumed..." to "When a ConfigMap already being consumed..."
* Remove spurious cluster-status role description
* Indicate controller-manager must be granted controller roles when not run with --use-service-account-credentials
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
Changes "Mac OS" to macOS, "bootcamp" to tutorial (#3955)
Remove apply/edit warning now that edit is fixed
Two minor fixes
Cleanup robots.txt
Readability: Split first paragraph into two (#3957)
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
Fix log rotation description in the logging doc (#3918)
Add colon to #3897
add prompt about KUBE_REPO_PREFIX (#3597)
Warn against managing ReplicaSets owned by Deployments
Update small typo in components page (#3930)
change the service name to pod ip (#3926)
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
Fixed a minor mistake
docs/concepts/policy/pod-security-policy.md: add projected to list of allowed types.
Init container exists beta in 1.6.
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
fix typo (#3895)
add unit of --ttl duration (#3915)
Fixes broken links
Prototype of custom description meta tags. (#3928)
Site URL for canonical URLs. (#3927)
Warn about implications on selector updates
grammar patch to #3922 (#3923)
add calico to the table of solution
Minor grammatical change
I Created a deployment yaml file tomcatdp.yaml， and did not set the .spec.strategy，then run
kubectl create -f tomcatdp.yaml,
and then run
kubectl get deployment tomcat-deployment -o yaml,
the tomcat-deployment is the name of the deployment,found that the MaxUnavailable and MaxSurge default value is 25%
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
Fix sentence
Minor grammatical correction
Remove beta as K8s support on Bluemix Container Service is live
Fix some output
replace REASON with STATUS
column IP is missed
replace kubectl.sh with kubectl
replace KUBECTL with kubectl
fix the command output
fix the command output
fix the command output
Correcting the typo in init-container's name
fix typo
fix typo
fix typo
fix typo
fix typo
Update pod-overview.md (#3881)
apps/v1beta1 is not valid (#3814)
Get access to search console. (#3901)
The GPU path is not permissive by default and requires a bit of
additional setup if the operator does not allow for privileged
containers.
Related kubernetes/kubernetes#46007
Signed-off-by: Christopher M. Luciano <cmluciano@us.ibm.com>
* Update projected volume task
- Rename file
- Build out steps
- Create separate yaml file for pod configuration
- Add new page to the sidenav
* Add projected volume type to volumes concept page
https://kubernetes.io/docs/home/ suggests:
Concepts, Tasks, and Tutorials
> The Kubernetes documentation contains a number of resources to help you understand and work with Kubernetes.
> Concepts provide a deep understanding of how Kubernetes works.
> Tasks contain step-by-step instructions for common Kubernetes tasks.
> Tutorials contain detailed walkthroughs of the Kubernetes workflow.
This is a logical order and I've rearranged the header to match.
* WtD: Picking the Right Solution, edit
Fixes content of overview sitting too close to next section's heading.
* Update pick-right-solution.md
* Update pick-right-solution.md
* access-clusters docs revamp
Fix the accessing clusters docs, bring them into the right templates
and put them in the right parts of the site.
* Update proxies.md
* Update concepts.yml
* Update tasks.yml
* Update install-kubectl.md
Write the Docs:
Added Task template to the document.
Edited for clarity.
* Update install-kubectl.md
Write the Docs. Responded to review feedback: https://github.com/kubernetes/kubernetes.github.io/pull/3760#pullrequestreview-38008755
* Update install-kubectl.md
Write the Docs. Seeing if this makes the bulleted list render correctly.
* Update install-kubectl.md
Write the Docs. Markdown really doesn't seem to like that bulleted list there, so we'll just do it in sentence flow.
- edit /docs/tasks/configure-pod-container/configmap.md to use the task template
- move the Consuming ConfigMap in pods section to its own doc (coming in a separate PR)
Now that we have new repositories to house RPMs for other architectures,
and are populating them with new releases, we should advertise them in
the kubeadm getting started instructions.
* NetworkPolicy clarifications
- For clarity, only use the word "policy" in reference to
NetworkPolicies, not in reference to the isolation annotation.
- Drop a bunch of text related to the isolation annotation since
there's only one interesting value so there's no reason to
complicate things.
- Fix bad YAML indentation
- Misc rewording
* Update NetworkPolicy docs for v1
Similar to the pod-network-cird= issue, with no = there is no immediate problem but it causes trouble along the way (i.e. I wasn't able to access the dashboard via kubectl proxy)
Wasted hours today trying to get kubeadm working on a Ubuntu VM. The culprit is a missing = for the pod-network-cidr parameter to the kubeadm init command when using calico. Without it kube-dns refused to start, oddly enough pods had 10.244.0.0 network setup but somehow it was failing sending a request to destroy and recreate the pod.
Here's the events for the kube-dns pods if someone's interested.
Events:
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
2m 2m 1 default-scheduler Normal Scheduled Successfully assigned kube-dns-3913472980-5xfzt to kube-master
1m 1m 1 kubelet, kube-master Warning FailedSync Error syncing pod, skipping: failed to "CreatePodSandbox" for "kube-dns-3913472980-5xfzt_kube-system(3bd90f8c-33a8-11e7-8a23-080027ac04f3)" with CreatePodSandboxError: "CreatePodSandbox for pod \"kube-dns-3913472980-5xfzt_kube-system(3bd90f8c-33a8-11e7-8a23-080027ac04f3)\" failed: rpc error: code = 2 desc = NetworkPlugin cni failed to set up pod \"kube-dns-3913472980-5xfzt_kube-system\" network: Get https://10.96.0.1:443/api/v1/namespaces/kube-system/pods/kube-dns-3913472980-5xfzt: dial tcp 10.96.0.1:443: i/o timeout"
1m 50s 6 kubelet, kube-master Warning FailedSync Error syncing pod, skipping: failed to "KillPodSandbox" for "3bd90f8c-33a8-11e7-8a23-080027ac04f3" with KillPodSandboxError: "rpc error: code = 2 desc = NetworkPlugin cni failed to teardown pod \"kube-dns-3913472980-5xfzt_kube-system\" network: connection is unauthorized"
1m 9s 9 kubelet, kube-master Normal SandboxChanged Pod sandbox changed, it will be killed and re-created.
37s 9s 3 kubelet, kube-master Warning FailedSync Error syncing pod, skipping: failed to "KillPodSandbox" for "3bd90f8c-33a8-11e7-8a23-080027ac04f3" with KillPodSandboxError: "rpc error: code = 2 desc = NetworkPlugin cni failed to teardown pod \"kube-dns-3913472980-5xfzt_kube-system\" network: netplugin failed but error parsing its diagnostic message \"\": unexpected end of JSON input"
* Refactor tabs implementation
* tidy head.html
* test jquery-ui tabs
* Initial tabs code refactor
* test liquid parsing
* test liquid stack
* move into tabs.html
* test jekyll tabs
* construct array
* test cleaner way
* add example content
* test split hack
* fix md
* add site.emptyArray
* set good defaults
* fix CSS
* cleanup li
* fix a href
* fix content tabs
* add space to default
* remove a href underline
* rename docs/tab-test.md to docs/tab-example.md
* fix skip toc check
* add assignees
* add comment to reference example
* add documentation to example
* escape md
* move demo to top, pretty it up
* add word
* tweak wording
Fixes#3357. I'm removing this statement as it's not clear where it should
actually be pointing to...
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
This table of contents is redundant (it's also available from the side nav) and confusing (not clear if it's a copy of the side nav or contains additional information). Plus, it was out of sync with the actual table of contents (last section on GPU was missing). So, I think it's best to just remove it.
* Update link to Adding ImagePullSecrets to a service account
* Link to appropriate docs for Automatic Mounting of Manually Created Secrets
* Replace here w/ title of pages
* Syntax for Kubernetes version 1.6
Included 1.6 syntax change for declaration of init containers.
* Reorder services.yaml & add 1.5 syntax still works
* Corrected YAML headings & add syntax explanation
When -w option is not available for base64, for example, when using alpine Docker image.
`echo -n "<text>" | base64 | tr -d '\n'` should be used, it works better.
* Remove bash completion from gce.md
Bash completion instructions do not belong to this guide. (ref: #3476)
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
* Update kubectl installation instructions on gce.md
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
This topic is not yet important enough to list exhaustively on /docs/reference.
Also the links are broken anyway. Fixes#3535.
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
* Update federation setup guide link to kubefed
We no longer support federation setup scripts `federation.sh` and
`deploy.sh`. Update the main federation guide setup link accordingly, by
making kubefed guide the way to go.
* Update federation.md
* initial commit for structure
* migrate Container Lifecycle Hooks and related files to Concepts
* update Concepts ToC
* fix formatting
* Formatting tweaks
* comment out What's next
* remove What's next
* Begin rewrite of container-lifecycle-hooks.md
* incremental update to edit
* Split Container Lifecycle Hooks into container-lifecycle-hooks.md and container-environment.md; change all referring links.
* Add concept template to volumes.md and images.md
* Apply changes for steveperry-53 feedback.
* fix format issue
* tweak formatting
* fix Concepts ToC
* update links
* add back changes to Concepts ToC
* fix a link
* update links
* adding documentation for TCP checks, replacing "discussion" section with more detailed "configuration" section, other small tweaks
* some line breaks and a small tweak
* tweaking config section
* fixing problems with http get field descriptions, more detailed TCP example
* Added note about Docker credentials store
Docker might use a credentials store when logging in to docker repositories, see https://docs.docker.com/engine/reference/commandline/login/#credentials-store. In that case you don't find the `auth` token in the `config.json` file. I added a note that this might happen, in order to prevent confusion.
* added "NOTE:" to the Docker credentials store note
as suggested in PR review
- avoiding cloning the full history of k8s repo, there doesn't seem to be any
difference (--depth=1 gives the same result and fetched branches are not
used in this script)
- quoting around variables and add '--' to some commands to separate positional
arguments
- using subshells instead of pushd/popd stuff, easier to read IMO
- added 'set -o errexit', couldn't add 'set -o pipefail'. For some reason when
I enable pipefail, it produces a vastly different output but I don't see any
errors in the output.
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
Create a documentation link for IBM Bluemix Container Service similar to
GCE and Azure. Also rename Softlayer references to Bluemix.
Co-Authored-By: Xavier Loup <xavier.loup@fr.ibm.com>
* Update links to outdated user-guide and admin docs
* Add script for updating outdated links.
* Update regex to include init-containers file.
* Pull upstream, rewrite links in and to namespaces walkthrough.
Currently kubefed does not create the default namespace, therefore anyone
following this doc today will hit this issue. Adding a few comments to bridge
that gap until the bug is fixed.
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
This is the only place in all of the documentation where addon(s) is used
instead of addons. Even though with brackets it can be read as one or more
addons, it looks strange and inconsistent with the rest of the documentation.
Signed-off-by: Brad Topol <btopol@us.ibm.com>
* Massive updates to expose-intro.html
Updates to the non-interactive tutorial on exposing apps via services
* more updates to expose-intro
* fixed broken link
* fixed some wording
* removed extra space
* sub backticks for code and newline
* added small legend to fist svg
* fixed svg scaling
* removed extra div
Kubernetes release .tar.gz no longer provides binaries. So the existing
instructions are invalid (#2815).
User has to get the .tar.gz file and then run a script, only to download them
from storage.googleapis.com/kubernetes-release. That's already what's documented
in the "install via curl" section.
Therefore deleting "Extract kubectl from Release .tar.gz" section.
Signed-off-by: Ahmet Alp Balkan <ahmetalpbalkan@gmail.com>
People are hitting issues copy-pasting the complicated way to install
`kubectl` and we're suggesting them to `sudo mv` binaries to /usr/local/bin.
That is not very ideal. Instead suggesting users to use Homebrew. I think it's
ok for this tutorial, as the tutorial already uses Homebrew to install
other stuff, plus it's a much better way than `sudo mv`ing.
Closes#2478.
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
- Pods do not start with missing ConfigMaps or Secrets
- Pods do not start with missing keys in ConfigMaps or Secrets
- Pods start with invalid keys when referring to entire ConfigMaps or
Secrets. An event documents the skipped keys from said resource.
This replaces the two buttons on the right of the footer.
It does not seem like get.k8s.io is useful to anyone. Replacing it with the
installation guide and avoiding K8s abbreviation in these buttons.
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
* Updates ZooKeeper example to use the Anti-Affinity field instead of the
1.5 annotation.
* Changed podAntiAffinity field references to lower case
Changed references to PodAntiAffinity object/concept to plain text
Changed link to PodAntiAffinity to reference subsection
* 'master' of https://github.com/kubernetes/kubernetes.github.io: (21 commits)
revert issue URL, turn into link
docs/admin/authorization: remove duplicated phrase (#3045)
update urls
Fix a typo and update one url
update urls
update a url
update urls
update invalid links
update some urls
modify the url of RestartPolicy (#3034)
Fix the url
amend the url
amend the readiness probes (#3031)
modify the link url (#3030)
change the url (#3029)
Fix the typo.
Fix the link url
delete redundant example
fix typo
change a link's url
...
# Conflicts:
# docs/admin/authorization/index.md
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
s/Wildard/Wildcard/
rephrase the sentence
Fix the number of processes on Kubernetes master (#2985)
Pod Security Policy doc improvements (#3010)
docs/admin: document OpenID Connect plugin "extra-scopes" field
# Conflicts:
# docs/admin/kubelet.md
# docs/user-guide/pod-security-policy/index.md
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
fix the command output
delete invalid link
Revert "fix the command output"
fix the command output
Delete the useless spaces
Dollar signs used before commands without showing output
bare-url-used
Fix typo in authorization docs
Update networking.md
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
change the link icon
fix command kubectl get serviceAccounts output
Flannel is not longer the only network addon that supports ARM
# Conflicts:
# docs/getting-started-guides/kubeadm.md
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
Update some description about secrets
[Federation] Add a note about DNS API scopes to the Federation tutorial (#2943)
Delete the useless spaces in html files
Fix typo
update resource-usage-monitoring.md
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
Replace the tab with 4 spaces in md files (#2797)
fix link error
Replace the tab with 4 spaces in html files
hitting the `ClusterIP` from a pod (#2826)
# Conflicts:
# docs/admin/accessing-the-api.md
# docs/api-reference/extensions/v1beta1/definitions.html
# docs/getting-started-guides/kubeadm.md
# docs/user-guide/kubectl/index.md
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
rephrase the expression of configmap/index.md
Do not link to org/team links on GitHub
Fixed typos (#2721)
Revert "update init-containers.md"
Fix doc sentence
Add Minikube reference in the Kubectl configuration doc
Mention Minikube in the Kubectl configuration doc
# Conflicts:
# docs/tasks/index.md
* 'release-1.6' of https://github.com/kubernetes/kubernetes.github.io:
* 'master' of https://github.com/kubernetes/kubernetes.github.io: (23 commits)
Apply changes from PR #2787
rephrase the sentence to make expression clear (#2789)
update index.md (#2788)
Apply changes from PR #2784 (#2950)
The link URL of [kube-controller-manager] is wrong
Added pod name in run command
Fix grammar in docs/admin/daemon.md
update index.md (#2755)
Update garbage-collection.md (#2732)
Fix typo (#2842)
Fix typo
Fix the typos
Apply typo fixes from #2791 (#2949)
Fix typo in kubectl_completion.md
fix typeo (#2856)
Use kubectl config current-context to simplify the instructions
fix a typo in /docs/user-guide/configmap/index.md
Fix monitor-node-health.md
amend monitor-node-health.md
Update manage-compute-resources-container.md
...
# Conflicts:
# docs/tools/index.md
* Delete the parameter "--google-json-key string"
Delete the parameter "--google-json-key string"
* Fix apimachinery vendored dependencies in examples_test.
* package apt-transport-https should be installed
Ubuntu default install not include apt-transport-https. so if you want to download package from https repo, you need install apt-transport-https package first
* doc-walkthrough-content
modify
* limitrange-update
I think it's redundant that the second to ,in order to do sth and do
sth!thanks!
* fix command kubectl get svc,pod output
fix command kubectl get svc,pod output
* Fix typo: federation-controller-mananger => federation-controller-manager
* Fix typo: federation-controller-mananger => federation-controller-manager
* Clarify minimum version of kubernetes supporting PSP authz
* Provide correct location for KUBE_ETCD_SERVERS
Provide correct location for KUBE_ETCD_SERVERS configuration key. It was
previously listed as being in /etc/kubernetes/config but is actually in
/etc/kubernetes/apiserver.
Related: https://github.com/kubernetes/kubernetes.github.io/issues/1600
* Move Compute Resources topic to Concepts. (#2410)
* Delete the parameter "--google-json-key string"
“# kube-scheduler -help”can not find --google-json-key option
# kubectl version
Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.1+82450d0", GitCommit:"f5ef9802914a47c848fd84c287333f8b4d28bbc1", GitTreeState:"dirty", BuildDate:"2017-01-23T00:04:39Z", GoVersion:"go1.7", Compiler:"gc", Platform:"linux/amd64", USEEVersion:"V1.02.01_alpha", USEEPublishDate:"2017-1-10 00:00:00"}
Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.1+82450d0", GitCommit:"f5ef9802914a47c848fd84c287333f8b4d28bbc1", GitTreeState:"dirty", BuildDate:"2017-01-22T23:56:57Z", GoVersion:"go1.7", Compiler:"gc", Platform:"linux/amd64", USEEVersion:"V1.02.01_alpha", USEEPublishDate:"2017-1-10 00:00:00"}
* Add diagnose tips when you face problem.
* Update grammar for kubeadm.md, thanks @chenopis
* Merge two pieces to one words
* add http proxy infomation in kubeadm
* Update landing pages for Tasks and Tutorials. (#2634)
* Update static-pods.md
It works. Please review it again.
* Move Guide Topic: Multi-container pods. (#2642)
* fix link to go to pod-lifecycle page
* fix the command output
fix the command output
* mirantis_logo.png
,/images/community_logos/mirantis_logo.png updated per Mirantis request
* kubeadm reference -- /
set up/manage mean set up or manage ? it's better use or?
* Prototype for deprecating User Guide topic.
* missing word
The return of the OCD.
* Move Guide topic: Using Environment Variables. (#2645)
* fix typo (#2656)
fix typo
* Move Guide topic: Using Port Forwarding. (#2661)
* Move Guide topic: Bootstrapping Pet Sets. (#2662)
* Move Guide topic: Bootstrapping Pet Sets.
* Add TOC entry.
* Move Guide topic: Connect with Proxies. (#2663)
* Move Guide topic: Connect with Proxies.
* Fix link.
* add DefaultTolerationSeconds admission controller
* getting-started-guides: add CoreOS Tectonic
* Correct the certificate name
* Update index.md
* Update installation.md
* Update validation.md
* Update backups.md
* Update backups.md
* Spell fixes
* Using it vs Juju Kubernetes
* Q1 update to k8s tech and service partner list
New partners registered to K8s Partner Ecosystem sign-up form. Logo updates companion to this edit still WIP
* Logo file updates for new registrants
Logos for new registrants
* The attribute [allowfullscree] must have a value
Signed-off-by: yupengzte <yu.peng36@zte.com.cn>
* Remove newline before passing to base64
* Use single quote to avoid string interpolation, update output
* Update command as files contain no newline
* Remove all dead links, use just filename
As user can guess that it is file copied from the shown content
* Fix link to dev guide.
* Add --leader-elect=false
Second scheduler could not start without disabling leader-elect.
* cluster-components-could be running
could be doing sth
* update cluster-components.md
In theory,Master components can be run....
* update cluster-components--add a space
add a space after the comma: "In theory, Master components..."
* Highlighted command --kubectl describe
In web page ,there is no space ,need some empty space,thanks!
* Revert "Highlighted command --kubectl describe"
This reverts commit a70d0a3e3537c3f91b197b23f949e1e506c951d1.
* Add example show how to configure proxy for kube
* Revision as the suggestion describe
* move ha-master-gce.png to images/docs
Signed-off-by: Xiuyu Li <nickleefly@gmail.com>
* use relative path for ha-master-gce image
Signed-off-by: Xiuyu Li <nickleefly@gmail.com>
* The attribute [calendarWrapper] must be unique
Signed-off-by: yupengzte <yu.peng36@zte.com.cn>
* add required images in kubeadm init step
* Add links to Docker/rtk in cluster-intro.html
* s/acomplish/accomplish/
* Modify the link URL of [kubelet eviction design doc]
[kubelet eviction design doc] should be linked to kubernetes.github.io
instead of community/design-proposal.
* fix CronJob object name
fix CronJob object name
* remove redundant a
Signed-off-by: Xiuyu Li <nickleefly@gmail.com>
* kubeadm reference--change any to some (#2683)
* modify one word
examples to example
* doc-walkthrough-content
modify
* limitrange-update
I think it's redundant that the second to ,in order to do sth and do
sth!thanks!
* cluster-components-could be running
could be doing sth
* update cluster-components.md
In theory,Master components can be run....
* update cluster-components--add a space
add a space after the comma: "In theory, Master components..."
* Highlighted command --kubectl describe
In web page ,there is no space ,need some empty space,thanks!
* Revert "Highlighted command --kubectl describe"
This reverts commit a70d0a3e3537c3f91b197b23f949e1e506c951d1.
* kubeadm reference--change any to some
kubeadm can install any add-on ?
* Move Guide topics: Logging (#2687)
* Disallow indexing for liveness/index (#2689)
* Deprecate Guide topics. (#2691)
* Wrong label and kubectl get completed pods
The label `app=jobexample` should be `jobgroup=jobexample`.
Also, for get completed pods the flag `--show-all` is necessary.
* Update garbage-collection.md
change “any” to "every"
* Deprecate Guide topic: Persistent Volume Walkthrough. (#2692)
* Reimplement PR #2525
Fixes typo by removing the word "controller"
* remove extra space
* Update multiple-schedulers doc (#2063)
* Update tutorial
* Fix md formatting.
* Remove extraneous space
* Deprecate Guide topic: Secrets Walkthrough. (#2695)
* Deprecate Guide topics: quick-start ... (#2696)
* Update Tasks landing page. (#2697)
* Remove redundant section in deployments
The status of the deployment is already covered in a later section in
this doc.
* Repair Spotinst logo
Corrected size
* fixed ASM blurb
* Correct ASM logo filename
* Highlighted command for `kubectl proxy`.
* Update ubuntu install instructions.
* Update local instructions to new method.
* update init-containers.md
add one word.
* Minor spelling correction -- "rtk" to "rkt"
* fixing typo
* Doc formatting update
Corrected indentation for the `nonResourcePath` and got a bit zealous with restructuring that section...
* Repair Spotinst logo
Corrected size
* fixed ASM blurb
* Correct ASM logo filename
* Update garbage-collection.md
change "any" to "every"
* Update Weave Net's title.
* fix unsupported parameter of wget command
* update to be retained
change "retain" to "to be retained".
* Update pod.md
* update init-containers.md
change "a different filesystem view" to "different filesystem views".
different init container should have different filesystem.
* Highlighted command --kubectl describe
In web page ,there is no space ,need some empty space,thanks!
* cluster-management--3
change 3 to three is better or not ?thanks!
* fix typo
1、Parameters “--allow-verification-with-non-compliant-keys” is missed.
2、Delete the parameter "--google-json-key string";
see the "# kube-controller-manager -help"
# kubectl version
Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.1+82450d0", GitCommit:"f5ef9802914a47c848fd84c287333f8b4d28bbc1", GitTreeState:"dirty", BuildDate:"2017-01-23T00:04:39Z", GoVersion:"go1.7", Compiler:"gc", Platform:"linux/amd64", USEEVersion:"V1.02.01_alpha", USEEPublishDate:"2017-1-10 00:00:00"}
Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.1+82450d0", GitCommit:"f5ef9802914a47c848fd84c287333f8b4d28bbc1", GitTreeState:"dirty", BuildDate:"2017-01-22T23:56:57Z", GoVersion:"go1.7", Compiler:"gc", Platform:"linux/amd64", USEEVersion:"V1.02.01_alpha", USEEPublishDate:"2017-1-10 00:00:00"}
* fix typo
1、Delete the parameter "--google-json-key string";
2、Parameters "--ir-data-source string"、"--ir-dbname string"、"--ir-hawkular string"、"--ir-influxdb-host string"、"--ir-namespace-only"、"--ir-password string"、"--ir-percentile int"、"--ir-user string" is missed.
see the "# kube-prxoy -help"
# kubectl version
Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.1+82450d0", GitCommit:"f5ef9802914a47c848fd84c287333f8b4d28bbc1", GitTreeState:"dirty", BuildDate:"2017-01-23T00:04:39Z", GoVersion:"go1.7", Compiler:"gc", Platform:"linux/amd64", USEEVersion:"V1.02.01_alpha", USEEPublishDate:"2017-1-10 00:00:00"}
Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.1+82450d0", GitCommit:"f5ef9802914a47c848fd84c287333f8b4d28bbc1", GitTreeState:"dirty", BuildDate:"2017-01-22T23:56:57Z", GoVersion:"go1.7", Compiler:"gc", Platform:"linux/amd64", USEEVersion:"V1.02.01_alpha", USEEPublishDate:"2017-1-10 00:00:00"}
* Update garbage-collection.md
modify the url and link
* update garbage-collection.md
change the url to relative path.
* update out-of-resource.md
change "in cases when" to "in case that"
* update out-of-resource.md
use a shorter and simpler expression.
* update out-of-resource.md
change "support" to "supports"
* Create a top-level CN directory to hold future md files for the Chinese kubernetes site
* Removed `=` at the end of the flags.
* Remove autogenerate todo
- This should be captured via a GitHub issue
and not a TODO in the README documentation
which leads to confusion.
* Move Guide topics: Federation Tasks. (#2799)
* Move Guide topics: Federation tutorial and concept. (#2802)
* Move Guide topics: Federation tutorial and concept.
* Add title.
* Fix link.
* Move kubectl Concept topics to Tutorials. (#2804)
* Move kubectl Concept topics to Tutorials.
* Add redirects and update links.
* The calendarWrapper attribute should be unique
Signed-off-by: yupengzte <yu.peng36@zte.com.cn>
* Fix links. (#2808)
* Fix link. (#2806)
* Move topic from clusters to cluster-administration. (#2812)
* Move a batch of cluster admin topics. (#2813)
* Move Guide topic: Limit storage consumption. (#2814)
* Move Guide topic: Limit storage consumption.
* Add title.
* Move Guide topic: Networking. (#2816)
* Move Guide topic: Network Plugins. (#2819)
* Move Guide topic: Network Plugins.
* Fix link.
* Move Guide topic: Static Pods. (#2820)
* User Guide content migration: post notice (#2818)
* Add User Guide content migration notice.
* Fix formatting
* Tweek formatting to block highlight text in light gray.
* Try table instead of code block
* remove extra lines
* try table format
* fix links
* incorporate @ddonnelly feedback
* Move Guide topic: Out of Resource. (#2821)
* Move Guide topic: Monitoring Node Health. (#2822)
* Move Guide topic: Monitoring Node Health.
* Move to Tasks.
* Move Guide topic: AppArmor. (#2823)
* Apparmor (#2825)
* Move Guide topic: AppArmor.
* Add included files.
* Move Guide topic: Audit. (#2824)
* Added 1.6 Upgrade notes to outline changes for etcd 3.
* Move Guide topic: Disruption Budget. (#2834)
* Move Guide topic: Limit range. (#2835)
* Quota (#2836)
* Move Guide topic: Limit range.
* Move Guide topic: Resource Quota and Limits.
* Quota2 (#2838)
* Move Guide topic: Limit range.
* Move Guide topic: Resource Quota concept.
* Dns (#2839)
* Move Guide topic: Limit range.
* Move Guide topic: DNS.
* Delete CNAME
* Create CNAME
* Delete CNAME
* Create CNAME
* Move docs/user-guide/managing-deployments.md to /docs/concepts/cluster-administration/manage-deployment.md
* add nginx-app.yaml file
* add back missing /
* fix link
* Move Guide topic: Replication Controller Operations
* Move Guide topic: Resizing a replication controller
* Concepts toc (#2840)
* Move Guide topic: Limit range.
* Adjust Concepts Overview TOC.
* Move Guide topic: Rolling Updates
* Move Kubernetes API page. (#2849)
* Move What is Kubernetes topic. (#2851)
* Move Guide topic: Rolling Update Demo (#2850)
* Move Guide topic: Rolling Update Demo
* rename file
* Move Guide topic: Configuration Best Practices
* Move Guide topic: Jobs (#2853)
* Move Guide topic: Jobs
* add job.yaml file
* change title
* Move Pod overview. (#2865)
* Move Pod overview.
* Fix redirection.
* Move Guide topic: Parallel Processing using Expansions (#2867)
* Move Guide topic: Parallel Processing using Expansions
* fix links to /docs/user-guide/jobs/
* Move Init Containers topic. (#2866)
* Move Guide topic: Coarse Parallel Processing Using a Work Queue
* Move Guide topic: Fine Parallel Processing using a Work Queue (#2870)
* Move Guide topic: Fine Parallel Processing using a Work Queue
* add migration notice
* fixed capitalization
* Rename /docs/tasks/job/work-queue-1/
* Move StatefulSets topic. (#2869)
* Move StatefulSets topic.
* Fix TOC.
* Move Guide topic: Pod Templates (#2872)
* Move Guide topic: Pod Templates
* tweak header level and capitalization
* Move PetSets topic. (#2873)
* Move Garbage Collection topic. (#2874)
* Move Garbage Collection topic.
* Fix included file.
* Move Guide topic: Prereqs
* Move Guide topic: Sharing Clusters
* Move Accessing Clusters topic to Concepts. (#2875)
* Move Accessing Clusters topic to Concepts.
* Update concepts.yml
* Move Guide topic: Kubeconfig File
* Move Guide topic: Config Provider Firewalls. (#2883)
* Move Guide topic: Federation Service Discovery. (#2884)
* Move Guide topic: Connecting Apps with Services. (#2885)
* Added example and docu for hostPort ranges
* Move Guide topic: Service. (#2891)
* Move Guide topic: Service.
* Move Guide topic: External Load Balancer.
* Fix TOC.
* Move Guide topic: Resource Monitoring. (#2895)
* docs/admin: document OpenID Connect plugin's claim prefixing
* Move Guide topic: Admin Guide
* fix the command output
fix the command output
* Update manage-compute-resources-container.md
Change "he" to "The"
* update out-of-resource.md
change "thresholds" to "threshold"
* update init-containers.md
change "apply" to "application"
* amend monitor-node-health.md
Amend the url link.
* Fix monitor-node-health.md
The url link does not exist.
* fix a typo in /docs/user-guide/configmap/index.md
change "value" to "values"
* View $PAGE on Github without forking the repo
Adding a "View docs/bla-bla.md on GitHub" button next to the
"Edit docs/bla-bla.md" button so that people can view the file
first without clicking the Edit button (which does not work without
forking the repository).
I did not need this because I was trying to do something without
forking. I just found it to be bit difficult to view source of a page
on GitHub.
I'm open to ideas, perhaps we can instead add an article footer button
named "View on GitHub" next to the "Edit this Page".
Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
* Move Guide topics: Container Lifestyle Hooks, Images, Volumes
* fix to taint the master node
* Add files via upload
* fix the link of ogging-elasticsearch-kibana.md
fix the link of url
* Remove from TOC/Search: pods/init-containers ... (#2694)
* Fix typo
* Add files via upload
* Create hyperlink
Create hyperlink for kubernetes repo link.
* updated PSP documentation with RBAC (#2552)
Added info about controller manager setup and current implementation when using PSP with RBAC support.
* Use kubectl config current-context to simplify the instructions
* fix typeo (#2856)
* fix typeo
* Update kargo.md
* Fix typo in kubectl_completion.md
evaluation --> evaluated
* Apply typo fixes from #2791 (#2949)
* Apply typo fixes from #2791
* remove style typos
* Fix the typos
Signed-off-by: yupengzte <yu.peng36@zte.com.cn>
* Fix typo
* Fix typo (#2842)
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
fix the link of ogging-elasticsearch-kibana.md
View $PAGE on Github without forking the repo
update init-containers.md
update out-of-resource.md
This updates the horizontal pod autoscaling documention to cover the new
autosclaing/v2alpha1 API version. It also notes the removal of the old
alpha annotations for autoscaling on custom metrics, and reccomends
against using the alpha collection method.
* Word wrap paragraphs
* Switch to fenced code blocks for all code samples
* Render programs as plain text
* Separate out program invocation from program output
Much of this is to follow the style guide: https://kubernetes.io/docs/contribute/style-guide/
Signed-off-by: Joe Beda <joe.github@bedafamily.com>
Update node-selection documentation with information about taints, tolerations, and alpha support for per-pod-configurable behavior when there are node problems
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
Revert "Updated description for kubeadm init --kubernetes-version"
Updated description for kubeadm init --kubernetes-version
Remove details about where authenticator is implemented
replace petset with statefulsets
Updated result of command
replace argumment with argument
Highlight some keyworks in garbage-collection.md.
Fixed typos in persistent volume index.md
Remove reference to port-forward to services
add an example
fix typo
Fix typo in concepts
Parallel Jobs with a *work queue*:
Add more options for self-registration.
dedent yaml code blocks
Add kubelet eviction in GC doc (#2484)
* 'master' of https://github.com/kubernetes/kubernetes.github.io: (22 commits)
Revert "Document new optional support for ConfigMap and Secret"
Revert "mend"
modify one word
fix typo
Fix typos in running zookeeper article
Add note about moved content. (#2563)
Move Guide topic to Tasks: Downward API (#2439)
modify typora
fix etcd disaster-recovery hyperlink
replace kubernetes.d with kubelet.d
remove its name from file content
Let's put kubectl in ~/bin.
Move Guide toic to Tasks: kubectl exec.
Fix travis and add comments
Move Pod Lifecycle to Concepts. (#2420)
Update deployment completeness documentation
rollback PR #2522
kubectl_apply.md-change it for label key
Update the links of Deployment User Guide
#2534 mark openstack-heat as standalone-salt-conf
...
# Conflicts:
# docs/user-guide/configmap/index.md
* 'master' of https://github.com/kubernetes/kubernetes.github.io:
Fix travis.yml
re: issue #2034; fix docker image link (#2532)
re: issue #1671; update to direct link
Update cheatsheet for multi-container handling
add "--show-all" to kubectl get pods
Fix broken/outdated links in the ingress.md file
column READY is missed
fix Kubenetes typo
Update overview.md
Update pod.md
Update multiple-schedulers.md
Fix the standard storageClass for GCE
fix typo
fix typo
Update index.md
doc(kubeadm.md) - change base64 decode option to '--decode'
Update links to ingress repository
Updated dead links
Fix unmatched closing paren
> NOTE: Please check the “Allow edits from maintainers” box (see image below) to
> [allow reviewers to fix problems](https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork/) on your patch and speed up the review process.
>
> Please delete this note before submitting the pull request.
@@ -17,7 +17,7 @@ The [Kubernetes SIG Docs Discussion Group](https://groups.google.com/forum/#!for
### Style Guides and Templates
Before submitting a pull request to create new content, please review the [Kubernetes.io style guide](http://kubernetes.io/docs/contribute/style-guide/) and follow the [instructions for using page templates](http://kubernetes.io/docs/contribute/page-templates/).
Before submitting a pull request to create new content, please review the [Kubernetes.io style guide](http://kubernetes.io/docs/home/contribute/style-guide/) and follow the [instructions for using page templates](http://kubernetes.io/docs/home/contribute/page-templates/).
## Contributing to Documentation
@@ -33,4 +33,4 @@ Note that code issues should be filed against the main kubernetes repository, wh
### Submitting Documentation Pull Requests
If you're fixing an issue in the existing documentation, you should submit a PR against the master branch. Follow [these instructions to create a documentation pull request against the kubernetes.io repository](http://kubernetes.io/docs/contribute/create-pull-request/).
If you're fixing an issue in the existing documentation, you should submit a PR against the master branch. Follow [these instructions to create a documentation pull request against the kubernetes.io repository](http://kubernetes.io/docs/home/contribute/create-pull-request/).
Required. One or two lines that provide a minimum definition. Do not repeat the term. Write about the plural of the term. Prefer fragments. Model after tooltips. End with a period.
long-description:|
Optional. Longer additional text to appear after (in conjunction with) short description. Provide where the short description is not sufficient as the intro paragraph to a topic. Write complete but concise sentences.
**See /_includes/templates/glossary/README.md for the official style guide.**
Manage the deployment and scaling of a set of Pods, *and provide guarantees about ordering*. They do so by maintaining a *unique*, sticky identity for each of their Pods.
long-description:|
Like Deployments, StatefulSets manage Pods that are based on an identical container spec. However, although their specs are the same, the Pods in a StatefulSet are not interchangeable. Each Pod has a persistent identifier that it maintains across any rescheduling.
StatefulSets also operate according to the Controller pattern. You define your desired state in a StatefulSet *object*, and the StatefulSet *controller* makes any necessary updates to the get there from the current state.
This feature is currently in a *beta* state, meaning:
* The version names contain beta (e.g. v2beta3).
* Code is well tested. Enabling the feature is considered safe. Enabled by default.
* Support for the overall feature will not be dropped, though details may change.
* The schema and/or semantics of objects may change in incompatible ways in a subsequent beta or stable release. When this happens, we will provide instructions for migrating to the next version. This may require deleting, editing, and re-creating API objects. The editing process may require some thought. This may require downtime for applications that rely on the feature.
* Recommended for only non-business-critical uses because of potential for incompatible changes in subsequent releases. If you have multiple clusters that can be upgraded independently, you may be able to relax this restriction.
* **Please do try our beta features and give feedback on them! After they exit beta, it may not be practical for us to make more changes.**
<p>Ready to get your hands dirty? Build a simple Kubernetes cluster that runs "Hello World" for Node.js.</p>
</div>
<divclass="nav-box">
<h3><ahref="/docs/">Documentation</a></h3>
<h3><ahref="/docs/home/">Documentation</a></h3>
<p>Learn how to use Kubernetes with the use of walkthroughs, samples, and reference documentation. You can even <ahref="/editdocs/"data-auto-burger-exclude>help contribute to the docs</a>!</p>
blurb:'Tectonic is the enterprise-ready Kubernetes product, by CoreOS. It adds key features to allow you to manage, update, and control clusters in production.'
},
{
type:0,
name:'Deis',
logo:'deis',
link:'https://deis.com',
blurb:'Deis the creators of Helm, Workflow, and Steward, helps developers and operators build, deploy, manage and scale their applications on top of Kubernetes.'
blurb:'CockroachDB is a distributed SQL database whose built-in replication and survivability model pair with Kubernetes to truly make data easy.'
},
{
type:0,
name:'Skippbox',
logo:'skippbox',
link:'http://www.skippbox.com/tag/products/',
blurb:'Creator of Cabin the first mobile application for Kubernetes, and kompose. Skippbox’s solutions distill all the power of k8s in simple easy to use interfaces.'
blurb:'Wercker automates your build, test and deploy pipelines for launching containers and triggering rolling updates on your Kubernetes cluster. '
},
{
type:0,
name:'Rancher',
logo:'rancher',
name:'Rancher Labs',
logo:'rancher-labs',
link:'http://rancher.com/kubernetes/',
blurb:'Rancher is an open-source, production-ready container management platform that makes it easy to deploy and leverage Kubernetes in the enterprise.'
blurb:'Rancher is an open-source, production-ready container management platform that makes it easy to deploy and manage Kubernetes.'
},
{
type:0,
@@ -134,7 +120,7 @@
blurb:'Deep, automated security for your containers running on Kubernetes.'
blurb:'ReactiveOps has written automation on best practices for infrastructure as code on GCP & AWS using Kubernetes, helping you build and maintain a world-class infrastructure at a fraction of the price of an internal hire.'
blurb:'Kubernetes experts that on-board applications and empower IT teams to get the most out of containerised technology.'
},
{
type:1,
name:'Deis',
logo:'deis',
link:'https://deis.com/services/',
blurb:'Deis provides professional services and 24x7 operational support for any Kubernetes cluster managed by our global cluster operations team.'
},
{
type:1,
name:'StackPointCloud',
logo:'stackpoint',
link:'https://stackpoint.io',
blurb:'StackPointCloud offers a wide range of support plans for managed Kubernetes clusters built through its universal control plane for Kubernetes Anywhere.'
blurb:'Samsung SDS’s Cloud Native Computing Team offers expert consulting across the range of technical aspects involved in building services targeted at a Kubernetes cluster.'
blurb:'Container Solutions is a premium software consultancy that focuses on programmable infrastructure, offering our expertise in software development, strategy and operations to help you innovate at speed and scale.'
blurb:'SUSE delivers Kubernetes as part of SUSE CaaS Platform and SUSE OpenStack Cloud, for enterprises that want truly open, open source solutions for cloud-native applications.'
blurb:'IBM Container Service is a managed k8s environment with built-in cluster security and isolation while leveraging services including Watson, IoT, Weather, etc.'
},
{
type:1,
name:'Kenzan',
logo:'Kenzan',
link:'http://kenzan.com/?ref=kubernetes',
blurb:'Kenzan is a software engineering and full-service consulting firm that provides customized, end-to-end solutions that drive change through digital transformation.'
},
{
type:0,
name:'Kublr',
logo:'kublr',
link:'http://kublr.com',
blurb:'Simplify your Kubernetes experience with a fully production-ready, enterprise-grade cluster management platform.'
},
{
type:0,
name:'Endocode AG',
logo:'endocode',
link:'https://endocode.com/kubernetes/',
blurb:'Endocode practices and teaches the open source way. Kernel to cluster - Dev to Ops. We offer Kubernetes trainings, services and support.'
blurb:'Architecture, implementation and operation of world-class Kubernetes solutions for cloud-native clients.'
},
{
type:1,
name:'Biarca',
logo:'biarca',
link:'http://biarca.io/',
blurb:'Biarca is a cloud services provider and key focus areas Key areas of focus for Biarca include Cloud Adoption Services, Infrastructure Services, DevOps Services and Application Services. Biarca leverages Kubernetes to deliver containerized solutions.'
blurb:'Claranet helps people migrate to the cloud and take full advantage of the new world it offers. We consult, design, build and proactively manage the right infrastructure and automation tooling for clients to achieve this.'
},
{
type:1,
name:'CloudKite',
logo:'cloudkite',
link:'https://cloudkite.io/',
blurb:'CloudKite.io helps companies build and maintain highly automated, resilient, and impressively performing software on Kubernetes.'
blurb:'CloudOps gets you hands-on with the K8s ecosystem via workshop/lab. Get prod ready K8s in cloud(s) of your choice with our managed services.'
},
{
type:2,
name:'Ghostcloud',
logo:'ghostcloud',
link:'https://www.ghostcloud.cn/ecos-kubernetes',
blurb:'EcOS is an enterprise-grade PaaS / CaaS based on Docker and Kubernetes, which makes it easier to configure, deploy and manage containerized applications.'
},
{
type:2,
name:'Contino',
logo:'contino',
link:'https://www.contino.io/',
blurb:'We help enterprise organizations adopt DevOps, containers and cloud computing. Contino is a global consultancy that enables regulated organizations to accelerate innovation through the adoption of modern approaches to software delivery.'
},
{
type:2,
name:'Heptio',
logo:'heptio',
link:'http://heptio.com',
blurb:'Heptio helps businesses of all sizes get closer to the vibrant Kubernetes community.'
},
{
type:2,
name:'Booz Allen Hamilton',
logo:'boozallenhamilton',
link:'https://www.boozallen.com/',
blurb:'Booz Allen partners with public and private sector clients to solve their most difficult challenges through a combination of consulting, analytics, mission operations, technology, systems delivery, cybersecurity, engineering, and innovation expertise.'
},
{
type:0,
name:'Applatix',
logo:'applatix',
link:'https://applatix.com/applatix-product/',
blurb:'Applatix helps build and run containerized apps on public cloud using Docker and Kubernetes.'
To write a glossary snippet, start with a copy of the template, [`/_data/glossary/_example.yml`](/_data/glossary/_example.yml). Make sure to provide (or omit) values for the following fields:
* (Required) `id`.
* This field must match the name of the glossary file itself (without the `*.yml` extension). It is *not* intended to be displayed to users, and is only used programmatically.
* (Required) `name`.
* The name of the term.
* (Required) `tags`.
* Must be one of the tags listed in kubernetes.github.io/_data/canonical-terms-tags.yml.
* (Required) `short description`.
* Make sure to replace the instructional text in the template with your content.
* (Optional) `formerly` and `related`.
* If you do not provide these values, remove the fields.
* (Optional) `long description`.
* If you do not provide a long description, remove the field -- that is, the complete key-value pair.
The `_example.yml` template also contains basic information about how to write your snippet. For additional guidance, continue reading this readme.
## Glossary snippet style guide
This style guide supplements the guidance provided in the glossary template. It's intended to help you think about what and how to write glossary definitions. For more general guidance on style, consult [the core docs style guide](https://kubernetes.io/docs/home/contribute/style-guide/).
### Minimum viable snippet:
Every snippet must include at least the short description. The long description is optional, but should be provided for terms that need additional clarification. For consistency with existing *Concept* definitions, *write your definitions as if the term is plural*.
**short-description** (Required): One line (or two short lines) that provides a minimum definition. Do not repeat the term. Prefer fragments. Model after tooltips. End with a period.
**long-description** (Optional): Longer additional text to appear after (in conjunction with) short description. Provide in cases where the short description is not sufficient for the intro paragraph to a topic. Write complete but concise sentences.
### Examples
```yaml
- name:Pod
- tags:
- Fundamental
- Workload
- API Object
- short-description:The smallest and simplest Kubernetes objects. Represent a set of running processes on your cluster.
- long-description:Pods most often run only a single container, and are managed by a Deployment.
```
```yaml
- name:Deployment
- tags:
- Fundamental
- Workload
- API Object
- short-description:Controllers that provide declarative updates for Pods and ReplicaSets.
- long-description:Deployments are responsible for creating and updating instances of an application.
```
### Thinking about definitions
* **Think of the short description as it would appear in a tooltip.** Is it sufficient to get the reader started? Is it short enough to be read inside a small UI element?
*Tip*: look at the API reference doc content (for example, https://kubernetes.io/docs/api-reference/v1.7/). Note, however, that this content should be used with care. The concept docs for Pod, for example, are clearer than the reference docs.
* **The long description should follow the short description to make a complete introduction to a topic.** (This is the content that appears at the top of the content, before any generated TOC.) Does it provide information that's not already clear from the short description? Does it provide information that readers should have a general sense of before they dive into the details of the topic it helps introduce?
*Tip:* the long description does not need to be long; it's intended to extend but not replace the short description. Look through current related docs for ideas. (The Deployment long description is taken from a tutorial, for example.)
{% include templates/glossary/_error.md term=term_data.name missing_block='short-description' purpose='concisely describes the key term in 1-2 lines' %}
{% endif %}
{% if include.length == "long" %}
{% if term_data.long-description %}
{{ term_data.long-description | markdownify }}
{% else %}
{% include templates/glossary/_error.md term=term_data.name missing_block='long-description' purpose='describes the key term in greater depth, supplementing the short-description' %}
<p>As of March 14, 2017, the Kubernetes SIG-Docs-Maintainers group have begun migration of the User Guide content as announced previously to the <a href="https://github.com/kubernetes/community/tree/master/sig-docs">SIG Docs community</a> through the <a href="https://groups.google.com/forum/#!forum/kubernetes-sig-docs">kubernetes-sig-docs</a> group and <a href="https://kubernetes.slack.com/messages/sig-docs/">kubernetes.slack.com #sig-docs</a> channel.</p>
<p>The user guides within this section are being refactored into topics within Tutorials, Tasks, and Concepts. Anything that has been moved will have a notice placed in its previous location as well as a link to its new location. The reorganization implements the table of contents (ToC) outlined in the <a href="https://docs.google.com/a/google.com/document/d/18hRCIorVarExB2eBVHTUR6eEJ2VVk5xq1iBmkQv8O6I/edit?usp=sharing">kubernetes-docs-toc</a> document and should improve the documentation's findability and readability for a wider range of audiences.</p>
<p>As of March 14, 2017, the Kubernetes SIG-Docs-Maintainers group have begun migration of the User Guide content as announced previously to the <a href="https://git.k8s.io/community/sig-docs">SIG Docs community</a> through the <a href="https://groups.google.com/forum/#!forum/kubernetes-sig-docs">kubernetes-sig-docs</a> group and <a href="https://kubernetes.slack.com/messages/sig-docs/">kubernetes.slack.com #sig-docs</a> channel.</p>
<p>The user guides within this section are being refactored into topics within Tutorials, Tasks, and Concepts. Anything that has been moved will have a notice placed in its previous location as well as a link to its new location. The reorganization implements a new table of contents and should improve the documentation's findability and readability for a wider range of audiences.</p>
<p>For any questions, please contact: <a href="mailto:kubernetes-sig-docs@googlegroups.com">kubernetes-sig-docs@googlegroups.com</a></p>
<tdclass="tableblock halign-left valign-top"><pclass="tableblock">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: <ahref="http://kubernetes.io/docs/user-guide/container-environment#hook-details">http://kubernetes.io/docs/user-guide/container-environment#hook-details</a></p></td>
<tdclass="tableblock halign-left valign-top"><pclass="tableblock">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: <ahref="http://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks#hook-details">http://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks#hook-details</a></p></td>
<tdclass="tableblock halign-left valign-top"><pclass="tableblock">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: <ahref="http://kubernetes.io/docs/user-guide/container-environment#hook-details">http://kubernetes.io/docs/user-guide/container-environment#hook-details</a></p></td>
<tdclass="tableblock halign-left valign-top"><pclass="tableblock">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: <ahref="http://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks#hook-details">http://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks#hook-details</a></p></td>
<h1> CASE STUDY:<imgsrc="http://c.mfcreative.com/i/logo/ancestry-on-dark.svg"width="22%"style="margin-bottom:-12px;margin-left:3px;"><br><divclass="subhead">Digging Into the Past With New Technology</div></h1>
</div>
<divclass="details">
Company <b>Ancestry</b> Location <b>Lehi, Utah</b> Industry <b>Internet Company, Online Services</b>
</div>
<hr>
<sectionclass="section1">
<divclass="cols">
<divclass="col1">
<h2>Challenge</h2>
Ancestry, the global leader in family history and consumer genomics, uses sophisticated engineering and technology to help everyone, everywhere discover the story of what led to them. The company has spent more than 30 years innovating and building products and technologies that at their core, result in real and emotional human responses. <ahref="https://www.ancestry.com">Ancestry</a> currently serves more than 2.6 million paying subscribers, holds 20 billion historical records, 90 million family trees and more than four million people are in its AncestryDNA network, making it the largest consumer genomics DNA network in the world. The company's popular website, <ahref="https://www.ancestry.com">ancestry.com</a>, has been working with big data long before the term was popularized. The site was built on hundreds of services, technologies and a traditional deployment methodology. "It's worked well for us in the past," says Paul MacKay, software engineer and architect at Ancestry, "but had become quite cumbersome in its processing and is time-consuming. As a primarily online service, we are constantly looking for ways to accelerate to be more agile in delivering our solutions and our products."
<br>
</div>
<divclass="col2">
<h2>Solution</h2>
The company is transitioning to cloud native infrastructure, using <ahref="https://www.docker.com">Docker</a> containerization, <ahref="https://kubernetes.io">Kubernetes</a> orchestration and <ahref="https://prometheus.io">Prometheus</a> for cluster monitoring.<br>
<br>
<h2>Impact</h2>
"Every single product, every decision we make at Ancestry, focuses on delighting our customers with intimate, sometimes life-changing discoveries about themselves and their families," says MacKay. "As the company continues to grow, the increased productivity gains from using Kubernetes has helped Ancestry make customer discoveries faster. With the move to Dockerization for example, instead of taking between 20 to 50 minutes to deploy a new piece of code, we can now deploy in under a minute for much of our code. We’ve truly experienced significant time savings in addition to the various features and benefits from cloud native and Kubernetes-type technologies."
</div>
</div>
</section>
<divclass="banner2">
<divclass="banner2text">
"At a certain point, you have to step back if you're going to push a new technology and get key thought leaders with engineers within the organization to become your champions for new technology adoption. At training sessions, the development teams were always the ones that were saying, 'Kubernetes saved our time tremendously; it's an enabler. It really is incredible.'"<br><br><spanstyle="font-size:16px">- PAUL MACKAY, SOFTWARE ENGINEER AND ARCHITECT AT ANCESTRY</span>
</div>
</div>
<sectionclass="section2">
<divclass="fullcol">
<h2>It started with a Shaky Leaf.</h2>
Since its introduction a decade ago, the Shaky Leaf icon has become one of Ancestry's signature features, which signals to users that there's a helpful hint you can use to find out more about your family tree.<br><br>
So when the company decided to begin moving its infrastructure to cloud native technology, the first service that was launched on <ahref="https://kubernetes.io">Kubernetes</a>, the open source platform for managing application containers across clusters of hosts, was this hint system. Think of it as Amazon's recommended products, but instead of recommending products the company recommends records, stories, or familial connections. "It was a very important part of the site," says Ancestry software engineer and architect Paul MacKay, "but also small enough for a pilot project that we knew we could handle in a very appropriate, secure way."<br><br>
And when it went live smoothly in early 2016, "our deployment time for this service literally was cut down from 50 minutes to 2 or 5 minutes," MacKay adds. "The development team was just thrilled because we're focused on supplying a great experience for our customers. And that means features, it means stability, it means all those things that we need for a first-in-class type operation."<br><br>
The stability of that Shaky Leaf was a signal for MacKay and his team that their decision to embrace cloud native technologies was the right one for the company. With a private data center, Ancestry built its website (which launched in 1996) on hundreds of services and technologies and a traditional deployment methodology. "It worked well for us in the past, but the sum of the legacy systems became quite cumbersome in its processing and was time-consuming," says MacKay. "We were looking for other ways to accelerate, to be more agile in delivering our solutions and our products."
</div>
</section>
<divclass="banner3">
<divclass="banner3text">
"And when it [Kubernetes] went live smoothly in early 2016, 'our deployment time for this service literally was cut down from 50 minutes to 2 or 5 minutes,' MacKay adds. 'The development team was just thrilled because we're focused on supplying a great experience for our customers. And that means features, it means stability, it means all those things that we need for a first-in-class type operation.'"
</div>
</div>
<sectionclass="section3">
<divclass="fullcol">
That need led them in 2015 to explore containerization. Ancestry engineers had already been using technology like <ahref="https://www.java.com/en/">Java</a> and <ahref="https://www.python.org">Python</a> on Linux, so part of the decision was about making the infrastructure more Linux-friendly. They quickly decided that they wanted to go with Docker for containerization, "but it always comes down to the orchestration part of it to make it really work," says MacKay.<br><br>
His team looked at orchestration platforms offered by <ahref="https://docs.docker.com/compose/">Docker Compose</a>, <ahref="http://mesos.apache.org">Mesos</a> and <ahref="https://www.openstack.org/software/">OpenStack</a>, and even started to prototype some homegrown solutions. And then they started hearing rumblings of the imminent release of Kubernetes v1.0. "At the forefront, we were looking at the secret store, so we didn't have to manage that all ourselves, the config maps, the methodology of seamless deployment strategy," he says. "We found that how Kubernetes had done their resources, their types, their labels and just their interface was so much further advanced than the other things we had seen. It was a feature fit."<br><br>
<divclass="quote">
Plus, MacKay says, "I just believed in the confidence that comes with the history that Google has with containerization. So we started out right on the leading edge of it. And we haven't looked back since."</div><br>
Which is not to say that adopting a new technology hasn't come with some challenges. "Change is hard," says MacKay. "Not because the technology is hard or that the technology is not good. It's just that people like to do things like they had done [before]. You have the early adopters and you have those who are coming in later. It was a learning experience on both sides."<br><br>
Figuring out the best deployment operations for Ancestry was a big part of the work it took to adopt cloud native infrastructure. "We want to make sure the process is easy and also controlled in the manner that allows us the highest degree of security that we demand and our customers demand," says MacKay. "With Kubernetes and other products, there are some good solutions, but a little bit of glue is needed to bring it into corporate processes and governances. It's like having a set of gloves that are generic, but when you really do want to grab something you have to make it so it's customized to you. That's what we had to do."<br><br>
Their best practices include allowing their developers to deploy into development stage and production, but then controlling the aspects that need governance and auditing, such as secrets. They found that having one namespace per service is useful for achieving that containment of secrets and config maps. And for their needs, having one container per pod makes it easier to manage and to have a smaller unit of deployment.
<br><br>
</div>
</section>
<divclass="banner4">
<divclass="banner4text">
"The success of Ancestry's first deployment of the hint system on Kubernetes helped create momentum for greater adoption of the technology."
</div>
</div>
<sectionclass="section4">
<divclass="fullcol">
With that process established, the time spent on deployment was cut down to under a minute for some services. "As programmers, we have what's called REPL: read, evaluate, print, and loop, but with Kubernetes, we have CDEL: compile, deploy, execute, and loop," says MacKay. "It's a very quick loop back and a great benefit to understand that when our services are deployed in production, they're the same as what we tested in the pre-production environments. The approach of cloud native for Ancestry provides us a better ability to scale and to accommodate the business needs as work loads occur."<br><br>
The success of Ancestry's first deployment of the hint system on Kubernetes helped create momentum for greater adoption of the technology. "Engineers like to code, they like to do features, they don't like to sit around waiting for things to be deployed and worrying about scaling up and out and down," says MacKay. "After a while the engineers became our champions. At training sessions, the development teams were always the ones saying, 'Kubernetes saved our time tremendously; it's an enabler; it really is incredible.' Over time, we were able to convince our management that this was a transition that the industry is making and that we needed to be a part of it."<br><br>
A year later, Ancestry has transitioned a good number of applications to Kubernetes. "We have many different services that make up the rich environment that [the website] has from both the DNA side and the family history side," says MacKay. "We have front-end stacks, back-end stacks and back-end processing type stacks that are in the cluster."<br><br>
The company continues to weigh which services it will move forward to Kubernetes, which ones will be kept as is, and which will be replaced in the future and thus don't have to be moved over. MacKay estimates that the company is "approaching halfway on those features that are going forward. We don't have to do a lot of convincing anymore. It's more of an issue of timing with getting product management and engineering staff the knowledge and information that they need."
</div>
</section>
<divclass="banner5">
<divclass="banner5text">
"... 'I believe in Kubernetes. I believe in containerization. I think
if we can get there and establish ourselves in that world, we will be further along and far better off being agile and all the things we talk about,
and it'll go forward.'"
</div>
</div>
<sectionclass="section5">
<divclass="fullcol">
Looking ahead, MacKay sees Ancestry maximizing the benefits of Kubernetes in 2017. "We're very close to having everything that should be or could be in a Linux-friendly world in Kubernetes by the end of the year," he says, adding that he's looking forward to features such as federation and horizontal pod autoscaling that are currently in the works. "Kubernetes has been very wonderful for us and we continue to ride the wave."<br><br>
That wave, he points out, has everything to do with the vibrant Kubernetes community, which has grown by leaps and bounds since Ancestry joined it as an early adopter. "This is just a very rough way of judging it, but on Slack in June 2015, there were maybe 500 on there," MacKay says. "The last time I looked there were maybe 8,500 just on the Slack channel. There are so many major companies and different kinds of companies involved now. It's the variety of contributors, the number of contributors, the incredibly competent and friendly community."<br><br>
As much as he and his team at Ancestry have benefited from what he calls "the goodness and the technical abilities of many" in the community, they've also contributed information about best practices, logged bug issues and participated in the open source conversation. And they've been active in attending <ahref="https://www.meetup.com/Utah-Kubernetes-Meetup/">meetups</a> to help educate and give back to the local tech community in Utah. Says MacKay: "We're trying to give back as far as our experience goes, rather than just code."
<br><br>When he meets with companies considering adopting cloud native infrastructure, the best advice he has to give from Ancestry's Kubernetes journey is this: "Start small, but with hard problems," he says. And "you need a patron who understands the vision of containerization, to help you tackle the political as well as other technical roadblocks that can occur when change is needed."<br><br>
With the changes that MacKay's team has led over the past year and a half, cloud native will be part of Ancestry's technological genealogy for years to come. MacKay has been such a champion of the technology that he says people have jokingly accused him of having a Kubernetes tattoo.<br><br>
"I really don't," he says with a laugh. "But I'm passionate. I'm not exclusive to any technology; I use whatever I need that's out there that makes us great. If it's something else, I'll use it. But right now I believe in Kubernetes. I believe in containerization. I think if we can get there and establish ourselves in that world, we will be further along and far better off being agile and all the things we talk about, and it'll go forward."<br><br>
He pauses. "So, yeah, I guess you can say I'm an evangelist for Kubernetes," he says. "But I'm not getting a tattoo!"
Company <b>Box</b> Location <b>Redwood City, California</b> Industry <b>Technology</b>
</div>
<hr>
<sectionclass="section1">
<divclass="cols">
<divclass="col1">
<h2>Challenge</h2>
Founded in 2005, the enterprise content management company allows its more than 50 million users to manage content in the cloud. <ahref="https://www.box.com/home">Box</a> was built primarily with bare metal inside the company’s own data centers, with a monolithic PHP code base. As the company was expanding globally, it needed to focus on "how we run our workload across many different cloud infrastructures from bare metal to public cloud," says Sam Ghods, Cofounder and Services Architect of Box. "It’s been a huge challenge because of different clouds, especially bare metal, have very different interfaces."
<br>
</div>
<divclass="col2">
<h2>Solution</h2>
Over the past couple of years, Box has been decomposing its infrastructure into microservices, and became an early adopter of, as well as contributor to, <ahref="http://kubernetes.io/">Kubernetes</a> container orchestration. Kubernetes, Ghods says, has allowed Box’s developers to "target a universal set of concepts that are portable across all clouds."<br><br>
<h2>Impact</h2>
"Before Kubernetes," Ghods says, "our infrastructure was so antiquated it was taking us more than six months to deploy a new microservice. Today, a new microservice takes less than five days to deploy. And we’re working on getting it to an hour."
</div>
</div>
</section>
<divclass="banner2">
<divclass="banner2text">
"We looked at a lot of different options, but Kubernetes really stood out....the fact that on day one it was designed to run on bare metal just as well as Google Cloud meant that we could actually migrate to it inside of our data centers, and then use those same tools and concepts to run across public cloud providers as well."<br><br><spanstyle="font-size:15px;letter-spacing:0.08em">- SAM GHOUDS, CO-FOUNDER AND SERVICES ARCHITECT OF BOX</span>
</div>
</div>
<sectionclass="section2">
<divclass="fullcol">
<h2>In the summer of 2014, Box was feeling the pain of a decade’s worth of hardware and software infrastructure that wasn’t keeping up with the company’s needs.</h2>
A platform that allows its more than 50 million users (including governments and big businesses like <ahref="https://www.ge.com/">General Electric</a>) to manage and share content in the cloud, Box was originally a <ahref="http://php.net/">PHP</a> monolith of millions of lines of code built exclusively with bare metal inside of its own data centers. It had already begun to slowly chip away at the monolith, decomposing it into microservices. And "as we’ve been expanding into regions around the globe, and as the public cloud wars have been heating up, we’ve been focusing a lot more on figuring out how we run our workload across many different environments and many different cloud infrastructure providers," says Box Cofounder and Services Architect Sam Ghods. "It’s been a huge challenge thus far because of all these different providers, especially bare metal, have very different interfaces and ways in which you work with them."<br><br>
Box’s cloud native journey accelerated that June, when Ghods attended <ahref="https://www.docker.com/events/dockercon">DockerCon</a>. The company had come to the realization that it could no longer run its applications only off bare metal, and was researching containerizing with Docker, virtualizing with OpenStack, and supporting public cloud.<br><br>
At that conference, Google announced the release of its Kubernetes container management system, and Ghods was won over. "We looked at a lot of different options, but Kubernetes really stood out, especially because of the incredibly strong team of <ahref="https://research.google.com/pubs/pub43438.html">Borg</a> veterans and the vision of having a completely infrastructure-agnostic way of being able to run cloud software," he says, referencing Google’s internal container orchestrator Borg. "The fact that on day one it was designed to run on bare metal just as well as <ahref="https://cloud.google.com/">Google Cloud</a> meant that we could actually migrate to it inside of our data centers, and then use those same tools and concepts to run across public cloud providers as well."<br><br>
Another plus: Ghods liked that <ahref="https://kubernetes.io/">Kubernetes</a> has a universal set of API objects like pod, service, replica set and deployment object, which created a consistent surface to build tooling against. "Even PaaS layers like <ahref="https://www.openshift.com/">OpenShift</a> or <ahref="http://deis.io/">Deis</a> that build on top of Kubernetes still treat those objects as first-class principles," he says. "We were excited about having these abstractions shared across the entire ecosystem, which would result in a lot more momentum than we saw in other potential solutions."<br><br>
Box deployed Kubernetes in a cluster in a production data center just six months later. Kubernetes was then still pre-beta, on version 0.11. They started small: The very first thing Ghods’s team ran on Kubernetes was a Box API checker that confirms Box is up. "That was just to write and deploy some software to get the whole pipeline functioning," he says. Next came some daemons that process jobs, which was "nice and safe because if they experienced any interruptions, we wouldn’t fail synchronous incoming requests from customers."
</div>
</section>
<divclass="banner3">
<divclass="banner3text">
"As we’ve been expanding into regions around the globe, and as the public cloud wars have been heating up, we’ve been focusing a lot more on figuring out how we [can have Kubernetes help] run our workload across many different environments and many different cloud infrastructure providers."
</div>
</div>
<sectionclass="section3">
<divclass="fullcol">
The first live service, which the team could route to and ask for information, was launched a few months later. At that point, Ghods says, "We were comfortable with the stability of the Kubernetes cluster. We started to port some services over, then we would increase the cluster size and port a few more, and that’s ended up to about 100 servers in each data center that are dedicated purely to Kubernetes. And that’s going to be expanding a lot over the next 12 months, probably too many hundreds if not thousands."<br><br>
While observing teams who began to use Kubernetes for their microservices, "we immediately saw an uptick in the number of microservices being released," Ghods notes. "There was clearly a pent-up demand for a better way of building software through microservices, and the increase in agility helped our developers be more productive and make better architectural choices."
<br><br><divclass="quote">"There was clearly a pent-up demand for a better way of building software through microservices, and the increase in agility helped our developers be more productive and make better architectural choices."</div><br>
Ghods reflects that as early adopters, Box had a different journey from what companies experience now. "We were definitely lock step with waiting for certain things to stabilize or features to get released," he says. "In the early days we were doing a lot of contributions [to components such as kubectl apply] and waiting for Kubernetes to release each of them, and then we’d upgrade, contribute more, and go back and forth several times. The entire project took about 18 months from our first real deployment on Kubernetes to having general availability. If we did that exact same thing today, it would probably be no more than six."<br><br>
In any case, Box didn’t have to make too many modifications to Kubernetes for it to work for the company. "The vast majority of the work our team has done to implement Kubernetes at Box has been making it work inside of our existing (and often legacy) infrastructure," says Ghods, "such as upgrading our base operating system from RHEL6 to RHEL7 or integrating it into <ahref="https://www.nagios.org/">Nagios</a>, our monitoring infrastructure. But overall Kubernetes has been remarkably flexible with fitting into many of our constraints, and we’ve been running it very successfully on our bare metal infrastructure."<br><br>
Perhaps the bigger challenge for Box was a cultural one. "Kubernetes, and cloud native in general, represents a pretty big paradigm shift, and it’s not very incremental," Ghods says. "We’re essentially making this pitch that Kubernetes is going to solve everything because it does things the right way and everything is just suddenly better. But it’s important to keep in mind that it’s not nearly as proven as many other solutions out there. You can’t say how long this or that company took to do it because there just aren’t that many yet. Our team had to really fight for resources because our project was a bit of a moonshot."
</div>
</section>
<divclass="banner4">
<divclass="banner4text">
"The vast majority of the work our team has done to implement Kubernetes at Box has been making it work inside of our existing [and often legacy] infrastructure....overall Kubernetes has been remarkably flexible with fitting into many of our constraints, and we’ve been running it very successfully on our bare metal infrastructure."
</div>
</div>
<sectionclass="section4">
<divclass="fullcol">
Having learned from experience, Ghods offers these two pieces of advice for companies going through similar challenges:
<h2>1. Deliver early and often.</h2> Service discovery was a huge problem for Box, and the team had to decide whether to build an interim solution or wait for Kubernetes to natively satisfy Box’s unique requirements. After much debate, "we just started focusing on delivering something that works, and then dealing with potentially migrating to a more native solution later," Ghods says. "The above-all-else target for the team should always be to serve real production use cases on the infrastructure, no matter how trivial. This helps keep the momentum going both for the team itself and for the organizational perception of the project." </br></br>
<h2>2. Keep an open mind about what your company has to abstract away from developers and what it doesn’t.</h2> Early on, the team built an abstraction on top of Docker files to help ensure that images had the right security updates.
This turned out to be superfluous work, since container images are considered immutable and you can easily scan them post-build to ensure they do not contain vulnerabilities. Because managing infrastructure through containerization is such a discontinuous leap, it’s better to start by interacting directly with the native tools and learning their unique advantages and caveats. An abstraction should be built only after a practical need for it arises.</br></br>
In the end, the impact has been powerful. "Before Kubernetes," Ghods says, "our infrastructure was so antiquated it was taking us more than six months to deploy a new microservice. Now a new microservice takes less than five days to deploy. And we’re working on getting it to an hour. Granted, much of that six months was due to how broken our systems were, but bare metal is intrinsically a difficult platform to support unless you have a system like Kubernetes to help manage it."</br></br>
By Ghods’s estimate, Box is still several years away from his goal of being a 90-plus percent Kubernetes shop. "We’re very far along on having a mission-critical, stable Kubernetes deployment that provides a lot of value," he says. "Right now about five percent of all of our compute runs on Kubernetes, and I think in the next six months we’ll likely be between 20 to 50 percent. We’re working hard on enabling all stateless service use cases, and shift our focus to stateful services after that."
</div>
</section>
<divclass="banner5">
<divclass="banner5text">
"Ghods predicts that Kubernetes has the opportunity to be the new cloud platform. '...because it’s a never-before-seen level of automation and intelligence surrounding infrastructure that is portable and agnostic to every way you can run your infrastructure.'"
</div>
</div>
<sectionclass="section5">
<divclass="fullcol">
In fact, that’s what he envisions across the industry: Ghods predicts that Kubernetes has the opportunity to be the new cloud platform. Kubernetes provides an API consistent across different cloud platforms including bare metal, and "I don’t think people have seen the full potential of what’s possible when you can program against one single interface," he says. "The same way <ahref="https://aws.amazon.com/">AWS</a> changed infrastructure so that you don’t have to think about servers or cabinets or networking equipment anymore, Kubernetes enables you to focus exclusively on the containers that you’re running, which is pretty exciting. That’s the vision."</br></br>
Ghods points to projects that are already in development or recently released for Kubernetes as a cloud platform: cluster federation, the Dashboard UI, and <ahref="https://coreos.com/">CoreOS</a>’s etcd operator. "I honestly believe it’s the most exciting thing I’ve seen in cloud infrastructure," he says, "because it’s a never-before-seen level of automation and intelligence surrounding infrastructure that is portable and agnostic to every way you can run your infrastructure."</br></br>
Box, with its early decision to use bare metal, embarked on its Kubernetes journey out of necessity. But Ghods says that even if companies don’t have to be agnostic about cloud providers today, Kubernetes may soon become the industry standard, as more and more tooling and extensions are built around the API.</br></br>
"The same way it doesn’t make sense to deviate from Linux because it’s such a standard," Ghods says, "I think Kubernetes is going down the same path. It is still early days—the documentation still needs work and the user experience for writing and publishing specs to the Kubernetes clusters is still rough. When you’re on the cutting edge you can expect to bleed a little. But the bottom line is, this is where the industry is going. Three to five years from now it’s really going to be shocking if you run your infrastructure any other way."
<divclass="subhead">Making Deployments Easy for a Small, Distributed Team</div>
</h1>
</div>
<divclass="details">
Company <b>Buffer</b> Location <b>Around the World</b> Industry <b>Social Media Technology</b>
</div>
<hr>
<sectionclass="section1">
<divclass="cols">
<divclass="col1">
<h2>Challenge</h2>
With a small but fully distributed team of 80 working across almost a dozen time zones, Buffer—which offers social media management to agencies and marketers—was looking to solve its "classic monolithic code base problem," says Architect Dan Farrelly. "We wanted to have the kind of liquid infrastructure where a developer could create an app and deploy it and scale it horizontally as necessary."
</div>
<divclass="col2">
<h2>Solution</h2>
Embracing containerization, Buffer moved its infrastructure from Amazon Web Services’ Elastic Beanstalk to Docker on AWS, orchestrated with Kubernetes.
<br>
<br>
<h2>Impact</h2>
The new system "leveled up our ability with deployment and rolling out new changes," says Farrelly. "Building something on your computer and knowing that it’s going to work has shortened things up a lot. Our feedback cycles are a lot faster now too."
</div>
</div>
</section>
<divclass="banner2">
<divclass="banner2text">
"It’s amazing that we can use the Kubernetes solution off the shelf with our team. And it just keeps getting better. Before we even know that we need something, it’s there in the next release or it’s coming in the next few months."<br><br><spanstyle="font-size:16px;letter-spacing:2px;">- DAN FARRELLY, BUFFER ARCHITECT</span>
</div>
</div>
<sectionclass="section2">
<divclass="fullcol">
<h2>Dan Farrelly uses a carpentry analogy to explain the problem his company, <ahref="https://buffer.com">Buffer</a>, began having as its team of developers grew over the past few years.</h2>
"If you’re building a table by yourself, it’s fine," the company’s architect says. "If you bring in a second person to work on the table, maybe that person can start sanding the legs while you’re sanding the top. But when you bring a third or fourth person in, someone should probably work on a different table." Needing to work on more and more different tables led Buffer on a path toward microservices and containerization made possible by Kubernetes.<br><br>
Since around 2012, Buffer had already been using <ahref="https://aws.amazon.com/elasticbeanstalk/">Elastic Beanstalk</a>, the orchestration service for deploying infrastructure offered by <ahref="https://aws.amazon.com">Amazon Web Services</a>. "We were deploying a single monolithic <ahref="http://php.net/manual/en/intro-whatis.php">PHP</a> application, and it was the same application across five or six environments," says Farrelly. "We were very much a product-driven company. It was all about shipping new features quickly and getting things out the door, and if something was not broken, we didn’t spend too much time on it. If things were getting a little bit slow, we’d maybe use a faster server or just scale up one instance, and it would be good enough. We’d move on."<br><br>
But things came to a head in 2016. With the growing number of committers on staff, Farrelly and Buffer’s then-CTO, Sunil Sadasivan, decided it was time to re-architect and rethink their infrastructure. "It was a classic monolithic code base problem," says Farrelly.<br><br>Some of the company’s team was already successfully using <ahref="https://www.docker.com">Docker</a> in their development environment, but the only application running on Docker in production was a marketing website that didn’t see real user traffic. They wanted to go further with Docker, and the next step was looking at options for orchestration.
</div>
</section>
<divclass="banner3">
<divclass="banner3text">
And all the things Kubernetes did well suited Buffer’s needs. "We wanted to have the kind of liquid infrastructure where a developer could create an app and deploy it and scale it horizontally as necessary," says Farrelly. "We quickly used some scripts to set up a couple of test clusters, we built some small proof-of-concept applications in containers, and we deployed things within an hour. We had very little experience in running containers in production. It was amazing how quickly we could get a handle on it [Kubernetes]."
</div>
</div>
<sectionclass="section3">
<divclass="fullcol">
First they considered <ahref="https://mesosphere.com">Mesosphere</a>, <ahref="https://dcos.io">DC/OS</a> and <ahref="https://aws.amazon.com/ecs/">Amazon Elastic Container Service</a> (which their data systems team was already using for some data pipeline jobs). While they were impressed by these offerings, they ultimately went with Kubernetes. "We run on AWS still, so spinning up, creating services and creating load balancers on demand for us without having to configure them manually was a great way for our team to get into this," says Farrelly. "We didn’t need to figure out how to configure this or that, especially coming from a former Elastic Beanstalk environment that gave us an automatically-configured load balancer. I really liked Kubernetes’ controls of the command line. It just took care of ports. It was a lot more flexible. Kubernetes was designed for doing what it does, so it does it very well."<br><br>
And all the things Kubernetes did well suited Buffer’s needs. "We wanted to have the kind of liquid infrastructure where a developer could create an app and deploy it and scale it horizontally as necessary," says Farrelly. "We quickly used some scripts to set up a couple of test clusters, we built some small proof-of-concept applications in containers, and we deployed things within an hour. We had very little experience in running containers in production. It was amazing how quickly we could get a handle on it [Kubernetes]."<br><br>
Above all, it provided a powerful solution for one of the company’s most distinguishing characteristics: their remote team that’s spread across a dozen different time zones. "The people with deep knowledge of our infrastructure live in time zones different from our peak traffic time zones, and most of our product engineers live in other places," says Farrelly. "So we really wanted something where anybody could get a grasp of the system early on and utilize it, and not have to worry that the deploy engineer is asleep. Otherwise people would sit around for 12 to 24 hours for something. It’s been really cool to see people moving much faster."
<br><br>
With a relatively small engineering team—just 25 people, and only a handful working on infrastructure, with the majority front-end developers—Buffer needed "something robust for them to deploy whatever they wanted," says Farrelly. Before, "it was only a couple of people who knew how to set up everything in the old way. With this system, it was easy to review documentation and get something out extremely quickly. It lowers the bar for us to get everything in production. We don't have the big team to build all these tools or manage the infrastructure like other larger companies might."
</div>
</section>
<divclass="banner4">
<divclass="banner4text">
"In our old way of working, the feedback loop was a lot longer, and it was delicate because if you deployed something, the risk was high to potentially break something else," Farrelly says. "With the kind of deploys that we built around Kubernetes, we were able to detect bugs and fix them, and get them deployed super fast. The second someone is fixing [a bug], it’s out the door."
</div>
</div>
<sectionclass="section4">
<divclass="fullcol">
To help with this, Buffer developers wrote a deploy bot that wraps the Kubernetes deploy process and can be used by every team. "Before, our data analysts would update, say, a <ahref="https://www.python.org">Python</a> analysis script and have to wait for the lead on that team to click the button and deploy it," Farrelly explains. "Now our data analysts can make a change, enter a <ahref="https://slack.com">Slack</a> command, ‘/deploy,’ and it goes out instantly. They don’t need to wait on these slow turnaround times. They don’t even know where it’s running; it doesn’t matter."
<br><br>
One of the first applications the team built from scratch using Kubernetes was a new image resizing service. As a social media management tool that allows marketing teams to collaborate on posts and send updates across multiple social media profiles and networks, Buffer has to be able to resize photographs as needed to meet the varying limitations of size and format posed by different social networks. "We always had these hacked together solutions," says Farrelly.
<br><br>
To create this new service, one of the senior product engineers was assigned to learn Docker and Kubernetes, then build the service, test it, deploy it and monitor it—which he was able to do relatively quickly. "In our old way of working, the feedback loop was a lot longer, and it was delicate because if you deployed something, the risk was high to potentially break something else," Farrelly says. "With the kind of deploys that we built around Kubernetes, we were able to detect bugs and fix them, and get them deployed super fast. The second someone is fixing [a bug], it’s out the door."
<br><br>
Plus, unlike with their old system, they could scale things horizontally with one command. "As we rolled it out," Farrelly says, "we could anticipate and just click a button. This allowed us to deal with the demand that our users were placing on the system and easily scale it to handle it."
<br><br>
Another thing they weren’t able to do before was a canary deploy. This new capability "made us so much more confident in deploying big changes," says Farrelly. "Before, it took a lot of testing, which is still good, but it was also a lot of ‘fingers crossed.’ And this is something that gets run 800,000 times a day, the core of our business. If it doesn’t work, our business doesn’t work. In a Kubernetes world, I can do a canary deploy to test it for 1 percent and I can shut it down very quickly if it isn’t working. This has leveled up our ability to deploy and roll out new changes quickly while reducing risk."
</div>
</section>
<divclass="banner5">
<divclass="banner5text">
"If you want to run containers in production, with nearly the power that Google uses internally, this [Kubernetes] is a great way to do that," Farrelly says. "We’re a relatively small team that’s actually running Kubernetes, and we’ve never run anything like it before. So it’s more approachable than you might think. That’s the one big thing that I tell people who are experimenting with it. Pick a couple of things, roll it out, kick the tires on this for a couple of months and see how much it can handle. You start learning a lot this way."
</div>
</div>
<sectionclass="section5">
<divclass="fullcol">
By October 2016, 54 percent of Buffer’s traffic was going through their Kubernetes cluster. "There’s a lot of our legacy functionality that still runs alright, and those parts might move to Kubernetes or stay in our old setup forever," says Farrelly. But the company made the commitment at that time that going forward, "all new development, all new features, will be running on Kubernetes."
<br><br>
The plan for 2017 is to move all the legacy applications to a new Kubernetes cluster, and run everything they’ve pulled out of their old infrastructure, plus the new services they’re developing in Kubernetes, on another cluster. "I want to bring all the benefits that we’ve seen on our early services to everyone on the team," says Farrelly.
<br><br>
<h2>For Buffer’s engineers, it’s an exciting process. "Every time we’re deploying a new service, we need to figure out: OK, what’s the architecture? How do these services communicate? What’s the best way to build this service?" Farrelly says. "And then we use the different features that Kubernetes has to glue all the pieces together. It’s enabling us to experiment as we’re learning how to design a service-oriented architecture. Before, we just wouldn’t have been able to do it. This is actually giving us a blank white board so we can do whatever we want on it."
</h2>
Part of that blank slate is the flexibility that Kubernetes offers should the time come when Buffer may want or need to change its cloud. "It’s cloud agnostic so maybe one day we could switch to Google or somewhere else," Farrelly says. "We’re very deep in Amazon but it’s nice to know we could move away if we need to."
<br><br>
At this point, the team at Buffer can’t imagine running their infrastructure any other way—and they’re happy to spread the word. "If you want to run containers in production, with nearly the power that Google uses internally, this [Kubernetes] is a great way to do that," Farrelly says. "We’re a relatively small team that’s actually running Kubernetes, and we’ve never run anything like it before. So it’s more approachable than you might think. That’s the one big thing that I tell people who are experimenting with it. Pick a couple of things, roll it out, kick the tires on this for a couple of months and see how much it can handle. You start learning a lot this way."
<divclass="subhead">Saving Time and Money with Cloud Native Infrastructure</div>
</h1>
</div>
<divclass="details">
Company <b>GolfNow</b> Location <b>Orlando, Florida</b> Industry <b>Golf Industry Technology and Services Provider</b>
</div>
<hr>
<sectionclass="section1">
<divclass="cols">
<divclass="col1">
<h2>Challenge</h2>
A member of the <ahref="http://www.nbcunicareers.com/our-businesses/nbc-sports-group">NBC Sports Group</a>, <ahref="https://www.golfnow.com/">GolfNow</a> is the golf industry’s technology and services leader, managing 10 different products, as well as the largest e-commerce tee time marketplace in the world. As its business began expanding rapidly and globally, GolfNow’s monolithic application became problematic. "We kept growing our infrastructure vertically rather than horizontally, and the cost of doing business became problematic," says Sheriff Mohamed, GolfNow’s Director, Architecture. "We wanted the ability to more easily expand globally."
<br>
</div>
<divclass="col2">
<h2>Solution</h2>
Turning to microservices and containerization, GolfNow began moving its applications and databases from third-party services to its own clusters running on <ahref="https://www.docker.com/">Docker</a> and <ahref="http://kubernetes.io/">Kubernetes.</a><br><br>
<h2>Impact</h2>
The results were immediate. While maintaining the same capacity—and beyond, during peak periods—GolfNow saw its infrastructure costs for the first application virtually cut in half.
</div>
</div>
</section>
<divclass="banner2">
<divclass="banner2text">
"With our growth we obviously needed to expand our infrastructure, and we kept growing vertically rather than horizontally. We were basically wasting money and doubling the cost of our infrastructure."<br><br><spanstyle="font-size:15px;letter-spacing:0.08em">- SHERIFF MOHAMED, DIRECTOR, ARCHITECTURE AT GOLFNOW</span>
</div>
</div>
<sectionclass="section2">
<divclass="fullcol">
<h2>It’s not every day that you can say you’ve slashed an operating expense by half.</h2>
But Sheriff Mohamed and Josh Chandler did just that when they helped lead their company, <ahref="https://www.golfnow.com/">GolfNow</a>, on a journey from a monolithic to a containerized, cloud native infrastructure managed by Kubernetes.
<br><br>
A top-performing business within the NBC Sports Group, GolfNow is a technology and services company with the largest tee time marketplace in the world. GolfNow serves 5 million active golfers across 10 different products. In recent years, the business had grown so fast that the infrastructure supporting their giant monolithic application (written in C#.NET and backed by SQL Server database management system) could not keep up. "With our growth we obviously needed to expand our infrastructure, and we kept growing vertically rather than horizontally," says Sheriff, GolfNow’s Director, Architecture. "Our costs were growing exponentially. And on top of that, we had to build a Disaster Recovery (DR) environment, which then meant we’d have to copy exactly what we had in our original data center to another data center that was just the standby. We were basically wasting money and doubling the cost of our infrastructure."
<br><br>
In moving just the first of GolfNow’s important applications—a booking engine for golf courses and B2B marketing platform—from third-party services to their own Kubernetes environment, "our bill went down drastically," says Sheriff.
<br><br>
The path to those stellar results began in late 2014. In order to support GolfNow’s global growth, the team decided that the company needed to have multiple data centers and the ability to quickly and easily re-route traffic as needed. "From there we knew that we needed to go in a direction of breaking things apart, microservices, and containerization," says Sheriff. "At the time we were trying to get away from <ahref="https://www.microsoft.com/net">C#.NET</a> and <ahref="https://www.microsoft.com/en-cy/sql-server/sql-server-2016">SQL Server</a> since it didn’t run very well on Linux, where everything container was running smoothly."
<br><br>
To that end, the team shifted to working with <ahref="https://nodejs.org/">Node.js</a>, the open-source, cross-platform JavaScript runtime environment for developing tools and applications, and <ahref="https://www.mongodb.com/">MongoDB</a>, the open-source database program. At the time, <ahref="https://www.docker.com/">Docker</a>, the platform for deploying applications in containers, was still new. But once the team began experimenting with it, Sheriff says, "we realized that was the way we wanted to go, especially since that’s the way the industry is heading."
</div>
</section>
<divclass="banner3">
<divclass="banner3text">
"The team migrated the rest of the application into their Kubernetes cluster. And the impact was immediate: On top of cutting monthly costs by a large percentage, says Sheriff, 'Running at the same capacity and during our peak time, we were able to horizontally grow. Since we were using our VMs more efficiently with containers, we didn’t have to pay extra money at all.'"
</div>
</div>
<sectionclass="section3">
<divclass="fullcol">
GolfNow’s dev team ran an "internal, low-key" proof of concept and were won over. "We really liked how easy it was to be able to pass containers around to each other and have them up and running in no time, exactly the way it was running on my machine," says Sheriff. "Because that is always the biggest gripe that Ops has with developers, right? ‘It worked on my machine!’ But then we started getting to the point of, ‘How do we make sure that these things stay up and running?’" <br><br>
That led the team on a quest to find the right orchestration system for the company’s needs. Sheriff says the first few options they tried were either too heavy or "didn’t feel quite right." In late summer 2015, they discovered the just-released <ahref="http://kubernetes.io/">Kubernetes</a>, which Sheriff immediately liked for its ease of use. "We did another proof of concept," he says, "and Kubernetes won because of the fact that the community backing was there, built on top of what Google had already done."
<br><br>
But before they could go with Kubernetes, <ahref="http://www.nbc.com/">NBC</a>, GolfNow’s parent company, also asked them to comparison shop with another company. Sheriff and his team liked the competing company’s platform user interface, but didn’t like that its platform would not allow containers to run natively on Docker. With no clear decision in sight, Sheriff’s VP at GolfNow, Steve McElwee, set up a three-month trial during which a GolfNow team (consisting of Sheriff and Josh, who’s now Lead Architect, Open Platforms) would build out a Kubernetes environment, and a large NBC team would build out one with the other company’s platform.
<br><br>
"We spun up the cluster and we tried to get everything to run the way we wanted it to run," Sheriff says. "The biggest thing that we took away from it is that not only did we want our applications to run within Kubernetes and Docker, we also wanted our databases to run there. We literally wanted our entire infrastructure to run within Kubernetes."
<br><br>
At the time there was nothing in the community to help them get Kafka and MongoDB clusters running within a Kubernetes and Docker environment, so Sheriff and Josh figured it out on their own, taking a full month to get it right. "Everything started rolling from there," Sheriff says. "We were able to get all our applications connected, and we finished our side of the proof of concept a month in advance. My VP was like, ‘Alright, it’s over. Kubernetes wins.’"
<br><br>
The next step, beginning in January 2016, was getting everything working in production. The team focused first on one application that was already written in Node.js and MongoDB. A booking engine for golf courses and B2B marketing platform, the application was already going in the microservice direction but wasn’t quite finished yet. At the time, it was running in <ahref="https://devcenter.heroku.com/articles/mongohq">Heroku Compose</a> and other third-party services—resulting in a large monthly bill.
</div>
</section>
<divclass="banner4">
<divclass="banner4text">
"'The time I spent actually moving the applications was under 30 seconds! We can move data centers in just incredible amounts of time. If you haven’t come from the Kubernetes world you wouldn’t believe me.' Sheriff puts it in these terms: 'Before Kubernetes I wasn’t sleeping at night, literally. I was woken up all the time, because things were down. After Kubernetes, I’ve been sleeping at night.'"
</div>
</div>
<sectionclass="section4">
<divclass="fullcol">
"The goal was to take all of that out and put it within this new platform we’ve created with Kubernetes on <ahref="https://cloud.google.com/compute/">Google Compute Engine (GCE)</a>," says Sheriff. "So we ended up building piece by piece, in parallel, what was out in Heroku and Compose, in our Kubernetes cluster. Then, literally, just switched configs in the background. So in Heroku we had the app running hitting a Compose database. We’d take the config, change it and make it hit the database that was running in our cluster."
<br><br>
Using this procedure, they were able to migrate piecemeal, without any downtime. The first migration was done during off hours, but to test the limits, the team migrated the second database in the middle of the day, when lots of users were running the application. "We did it," Sheriff says, "and again it was successful. Nobody noticed."
<br><br>
After three weeks of monitoring to make sure everything was running stable, the team migrated the rest of the application into their Kubernetes cluster. And the impact was immediate: On top of cutting monthly costs by a large percentage, says Sheriff, "Running at the same capacity and during our peak time, we were able to horizontally grow. Since we were using our VMs more efficiently with containers, we didn’t have to pay extra money at all."
<br><br>
Not only were they saving money, but they were also saving time. "I had a meeting this morning about migrating some applications from one cluster to another," says Josh. "I spent about 2 hours explaining the process. The time I spent actually moving the applications was under 30 seconds! We can move data centers in just incredible amounts of time. If you haven’t come from the Kubernetes world you wouldn’t believe me." Sheriff puts it in these terms: "Before Kubernetes I wasn’t sleeping at night, literally. I was woken up all the time, because things were down. After Kubernetes, I’ve been sleeping at night."
<br><br>
A small percentage of the applications on GolfNow have been migrated over to the Kubernetes environment. "Our Core Team is rewriting a lot of the .NET applications into <ahref="https://www.microsoft.com/net/core">.NET Core</a> [which is compatible with Linux and Docker] so that we can run them within containers," says Sheriff.
<br><br>
Looking ahead, Sheriff and his team want to spend 2017 continuing to build a whole platform around Kubernetes with <ahref="https://github.com/drone/drone">Drone</a>, an open-source continuous delivery platform, to make it more developer-centric. "Now they’re able to manage configuration, they’re able to manage their deployments and things like that, making all these subteams that are now creating all these microservices, be self sufficient," he says. "So it can pull us away from applications and allow us to just make sure the cluster is running and healthy, and then actually migrate that over to our Ops team."
</div>
</section>
<divclass="banner5">
<divclass="banner5text">
"Having gone from complete newbies to production-ready in three months, the GolfNow team is eager to encourage other companies to follow their lead. 'This is The Six Million Dollar Man of the cloud right now,' adds Josh. 'Just try it out, watch it happen. I feel like the proof is in the pudding when you look at these kinds of application stacks. They’re faster, they’re more resilient.'"
</div>
</div>
<sectionclass="section5">
<divclass="fullcol">
And long-term, Sheriff has an even bigger goal for getting more people into the Kubernetes fold. "We’re actually trying to make this platform generic enough so that any of our sister companies can use it if they wish," he says. "Most definitely I think it can be used as a model. I think the way we migrated into it, the way we built it out, are all ways that I think other companies can learn from, and should not be afraid of."
<br><br>
The GolfNow team is also giving back to the Kubernetes community by open-sourcing a bot framework that Josh built. "We noticed that the dashboard user interface is actually moving a lot faster than when we started," says Sheriff. "However we realized what we needed was something that’s more of a bot that really helps us administer Kubernetes as a whole through Slack." Josh explains: "With the Kubernetes-Slack integration, you can essentially hook into a cluster and the issue commands and edit configurations. We’ve tried to simplify the security configuration as much as possible. We hope this will be our major thank you to Kubernetes, for everything you’ve given us."
<br><br>
Having gone from complete newbies to production-ready in three months, the GolfNow team is eager to encourage other companies to follow their lead. The lessons they’ve learned: "You’ve got to have buy-in from your boss," says Sheriff. "Another big deal is having two to three people dedicated to this type of endeavor. You can’t have people who are half in, half out." And if you don’t have buy-in from the get go, proving it out will get you there.
<br><br>
"This is The Six Million Dollar Man of the cloud right now," adds Josh. "Just try it out, watch it happen. I feel like the proof is in the pudding when you look at these kinds of application stacks. They’re faster, they’re more resilient."
<pclass="quote">"With Kubernetes, we're simplifying our environment and making it easier for developers to build the tools that make wikis run better."</p>
<h4><i>"Kubernetes has the opportunity to be the new cloud platform. The amount of innovation that's going to come from being able to standardize on Kubernetes as a platform is incredibly exciting - more exciting than anything I've seen in the last 10 years of working on the cloud."</i></h4>
<div><buttononclick="kub.showVideo()"><imgsrc="/images/case_studies/video_thumb1.png"alt="SAP video"><h6>Kubernetes at SAP</h6></button></div>
<divstyle="padding-left: 40px;"><buttononclick="kub.showVideo()"><imgsrc="/images/case_studies/Video-Clip-Box.png"alt="Box video"><h6>Kubernetes at Box</h6></button></div>
</main>
</section>
@@ -62,38 +59,42 @@ cid: caseStudies
<main>
<h3>Kubernetes Users</h3>
<divid="usersGrid">
<atarget="_blank"href="https://www.youtube.com/watch?v=P5qfyv_zGcU"><imgsrc="/images/case_studies/nyt.png"alt="New York Times"></a>
<atarget="_blank"href="https://docs.google.com/a/google.com/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform"class="tell-your-story"><imgsrc="/images/case_studies/story.png"alt="Tell your story"></a>
<atarget="_blank"href="https://docs.google.com/a/google.com/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform"class="tell-your-story"><imgsrc="/images/case_studies/story.png"alt="Tell your story"></a>
<h1> CASE STUDY:<imgsrc="/images/peardeck_logo.png"width="22%"style="margin-bottom:-0px"><br><divclass="subhead">Infrastructure for a Growing EdTech Startup</div></h1>
</div>
<divclass="details">
Company <b>Pear Deck</b> Location <b>Iowa City, Iowa</b> Industry <b>Educational Software</b>
</div>
<hr>
<sectionclass="section1">
<divclass="cols">
<divclass="col1">
<h2>Challenge</h2>
The three-year-old startup provides a web app for teachers to interact with their students in the classroom. The JavaScript app was built on Google’s web app development platform <ahref="https://firebase.google.com/">Firebase</a>, using <ahref="https://www.heroku.com/">Heroku</a>. As the user base steadily grew, so did the development team. "We outgrew Heroku when we started wanting to have multiple services, and the deploying story got pretty horrendous. We were frustrated that we couldn’t have the developers quickly stage a version," says CEO Riley Eynon-Lynch. "Tracing and monitoring became basically impossible." On top of that, many of Pear Deck’s customers are behind government firewalls and connect through Firebase, not Pear Deck’s servers, making troubleshooting even more difficult.
</div>
<divclass="col2">
<h2>Solution</h2>
In 2016, the company began moving their code from Heroku to <ahref="https://www.docker.com/">Docker</a> containers running on <ahref="https://cloud.google.com/container-engine/">Google Container Engine</a>, orchestrated by <ahref="http://kubernetes.io/">Kubernetes</a> and monitored with <ahref="https://prometheus.io/">Prometheus</a>.
<br>
<br>
<h2>Impact</h2>
The new cloud native stack immediately improved the development workflow, speeding up deployments. Prometheus gave Pear Deck "a lot of confidence, knowing that people are still logging into the app and using it all the time," says Eynon-Lynch. "The biggest impact is being able to work as a team on the configuration in git in a pull request, and the biggest confidence comes from the solidity of the abstractions and the trust that we have in Kubernetes actually making our yaml files a reality."
</div>
</div>
</section>
<divclass="banner2">
<divclass="banner2text">
"We didn’t even realize how stressed out we were about our lack of insight into what was happening with the app. I’m really excited and have more and more confidence in the actual state of our application for our actual users, and not just what the CPU graphs are saying, because of Prometheus and Kubernetes."<br><br><spanstyle="font-size:16px;letter-spacing:2px;">– RILEY EYNON-LYNCH, CEO OF PEAR DECK</span>
</div>
</div>
<sectionclass="section2">
<divclass="fullcol">
<h2>With the speed befitting a startup, Pear Deck delivered its first prototype to customers within three months of incorporating.</h2>
As a former high school math teacher, CEO Riley Eynon-Lynch felt an urgency to provide a tech solution to classes where instructors struggle to interact with every student in a short amount of time. "Pear Deck is an app that students can use to interact with the teacher all at once," he says. "When the teacher asks a question, instead of just the kid at the front of the room answering again, everybody can answer every single question. It’s a huge fundamental shift in the messaging to the students about how much we care about them and how much they are a part of the classroom."<br><br>
Eynon-Lynch and his partners quickly built a JavaScript web app on Google’s web app development platform <ahref="https://firebase.google.com/">Firebase</a>, and launched the minimum viable product [MVP] on <ahref="https://www.heroku.com/">Heroku</a> "because it was fast and easy," he says. "We made everything as easy as we could."
<br><br>
But once it launched, the user base began growing steadily at a rate of 30 percent a month. "Our Heroku bill was getting totally insane," Eynon-Lynch says. But even more crucially, as the company hired more developers to keep pace, "we outgrew Heroku. We wanted to have multiple services and the deploying story got pretty horrendous. We were frustrated that we couldn’t have the developers quickly stage a version. Tracing and monitoring became basically impossible."
<br><br>
On top of that, many of Pear Deck’s customers are behind government firewalls and connect through Firebase, not Pear Deck’s servers, making troubleshooting even more difficult.
<br><br>
The team began looking around for another solution, and finally decided in early 2016 to start moving the app from Heroku to <ahref="https://www.docker.com/">Docker</a> containers running on <ahref="https://cloud.google.com/container-engine/">Google Container Engine</a>, orchestrated by <ahref="http://kubernetes.io/">Kubernetes</a> and monitored with <ahref="https://prometheus.io/">Prometheus</a>.
</div>
</section>
<divclass="banner3">
<divclass="banner3text">
"When it became clear that Google Container Engine was going to have a lot of support from Google and be a fully-managed Kubernetes platform, it seemed very obvious to us that was the way to go," says Eynon-Lynch.
</div>
</div>
<sectionclass="section3">
<divclass="fullcol">
They had considered other options like Google’s App Engine (which they were already using for one service) and Amazon’s <ahref="https://aws.amazon.com/ec2/">Elastic Compute Cloud</a> (EC2), while experimenting with running one small service that wasn’t accessible to the Internet in Kubernetes. "When it became clear that Google Container Engine was going to have a lot of support from Google and be a fully-managed Kubernetes platform, it seemed very obvious to us that was the way to go," says Eynon-Lynch. "We didn’t really consider Terraform and the other competitors because the abstractions offered by Kubernetes just jumped off the page to us."<br><br>
Once the team started porting its Heroku apps into Kubernetes, which was "super easy," he says, the impact was immediate. "Before, to make a new version of the app meant going to Heroku and reconfiguring 10 new services, so basically no one was willing to do it, and we never staged things," he says. "Now we can deploy our exact same configuration in lots of different clusters in 30 seconds. We have a full set up that’s always running, and then any of our developers or designers can stage new versions with one command, including their recent changes. We stage all the time now, and everyone stopped talking about how cool it is because it’s become invisible how great it is."
<br><br>
Along with Kubernetes came Prometheus. "Until pretty recently we didn’t have any kind of visibility into aggregate server metrics or performance," says Eynon-Lynch. The team had tried to use GKE’s <ahref="https://cloud.google.com/stackdriver/">Stackdriver</a> monitoring, but had problems making it work, and considered <ahref="https://newrelic.com/">New Relic</a>. When they started looking at Prometheus in the fall of 2016, "the fit between the abstractions in Prometheus and the way we think about how our system works, was so clear and obvious," he says.<br><br>
The integration with Kubernetes made set-up easy. Once Helm installed Prometheus, "We started getting a graph of the health of all our Kubernetes nodes and pods immediately. I think we were pretty hooked at that point," Eynon-Lynch says. "Then we got our own custom instrumentation working in 15 minutes, and had an actively updated count of requests that we could do, rate on and get a sense of how many users are connected at a given point. And then it was another hour before we had alarms automatically showing up in our Slack channel. All that was in one afternoon. And it was an afternoon of gasping with delight, basically!"
</div>
</section>
<divclass="banner4">
<divclass="banner4text">
"We started getting a graph of the health of all our Kubernetes nodes and pods immediately. I think we were pretty hooked at that point," Eynon-Lynch says. "Then we got our own custom instrumentation working in 15 minutes, and had an actively updated count of requests that we could do, rate on and get a sense of how many users are connected at a given point. And then it was another hour before we had alarms automatically showing up in our Slack channel. All that was in one afternoon. And it was an afternoon of gasping with delight, basically!"
</div>
</div>
<sectionclass="section4">
<divclass="fullcol">
With Pear Deck’s specific challenges—traffic through Firebase as well as government firewalls—Prometheus was a game-changer. "We didn’t even realize how stressed out we were about our lack of insight into what was happening with the app," Eynon-Lynch says. Before, when a customer would report that the app wasn’t working, the team had to manually investigate the problem without knowing whether customers were affected all over the world, or whether Firebase was down, and where.<br><br>
To help solve that problem, the team wrote a script that pings Firebase from several different geographical locations, and then reports the responses to Prometheus in a histogram. "A huge impact that Prometheus had on us was just an amazing sigh of relief, of feeling like we knew what was happening," he says. "It took 45 minutes to implement [the Firebase alarm] because we knew that we had this trustworthy metrics platform in Prometheus. We weren’t going to have to figure out, ‘Where do we send these metrics? How do we aggregate the metrics? How do we understand them?’"<br><br>
Plus, Prometheus has allowed Pear Deck to build alarms for business goals. One measures the rate of successful app loads and goes off if the day’s loads are less than 90 percent of the loads from seven days before. "We run a JavaScript app behind ridiculous firewalls and all kinds of crazy browser extensions messing with it—Chrome will push a feature that breaks some CSS that we’re using," Eynon-Lynch says. "So that gives us a lot of confidence, and we at least know that people are still logging into the app and using it all the time."<br><br>
Now, when a customer complains, and none of the alarms have gone off, the team can feel confident that it’s not a widespread problem. "Just to be sure, we can go and double check the graphs and say, ‘Yep, there’s currently 10,000 people connected to that Firebase node. It’s definitely working. Let’s investigate your network settings, customer,’" he says. "And we can pass that back off to our support reps instead of the whole development team freaking out that Firebase is down."<br><br>
Pear Deck is also giving back to the community, building and open-sourcing a <ahref="https://github.com/peardeck/prometheus-user-metrics">metrics aggregator</a> that enables end-user monitoring in Prometheus. "We can measure, for example, the time to interactive-dom on the web clients," he says. "The users all report that to our aggregator, then the aggregator reports to Prometheus. So we can set an alarm for some client side errors."<br><br>
Most of Pear Deck’s services have now been moved onto Kubernetes. And all of the team’s new code is going on Kubernetes. "Kubernetes lets us experiment with service configurations and stage them on a staging cluster all at once, and test different scenarios and talk about them as a development team looking at code, not just talking about the steps we would eventually take as humans," says Eynon-Lynch.
</div>
</section>
<divclass="banner5">
<divclass="banner5text">
"A huge impact that Prometheus had on us was just an amazing sigh of relief, of feeling like we knew what was happening. It took 45 minutes to implement [the Firebase alarm] because we knew that we had this trustworthy metrics platform in Prometheus...in terms of the cloud, Kubernetes and Prometheus have so much to offer," he says.
</div>
</div>
<sectionclass="section5">
<divclass="fullcol">
Looking ahead, the team is planning to explore autoscaling on Kubernetes. With users all over the world but mostly in the United States, there are peaks and valleys in the traffic. One service that’s still on App Engine can get as many as 10,000 requests a second during the day but far less at night. "We pay for the same servers at night, so I understand there’s autoscaling that we can be taking advantage of," he says. "Implementing it is a big worry, exposing the rest of our Kubernetes cluster to us and maybe messing that up. But it’s definitely our intention to move everything over, because now none of the developers want to work on that app anymore because it’s such a pain to deploy it."
<br><br>
They’re also eager to explore the work that Kubernetes is doing with stateful sets. "Right now all of the services we run in Kubernetes are stateless, and Google basically runs our databases for us and manages backups," Eynon-Lynch says. "But we’re interested in building our own web-socket solution that doesn’t have to be super stateful but will have maybe an hour’s worth of state on it."
<br><br>
That project will also involve Prometheus, for a dark launch of web socket connections. "We don’t know how reliable web socket connections behind all these horrible firewalls will be to our servers," he says. "We don’t know what work Firebase has done to make them more reliable. So I’m really looking forward to trying to get persistent connections with web sockets to our clients and have optional tools to understand if it’s working. That’s our next new adventure, into stateful servers."
<br><br>
As for Prometheus, Eynon-Lynch thinks the company has only gotten started. "We haven’t instrumented all our important features, especially those that depend on third parties," he says. "We have to wait for those third parties to tell us they’re down, which sometimes they don’t do for a long time. So I’m really excited and have more and more confidence in the actual state of our application for our actual users, and not just what the CPU graphs are saying, because of Prometheus and Kubernetes."
<br><br>
For a spry startup that’s continuing to grow rapidly—and yes, they’re <ahref="https://www.peardeck.com/careers/">hiring</a>!—Pear Deck is notably satisfied with how its infrastructure has evolved in the cloud native ecosystem. "Usually I have some angsty thing where I want to get to the new, better technology," says Eynon-Lynch, "but in terms of the cloud, Kubernetes and Prometheus have so much to offer."
<li>Pearson had difficulty in scaling and adapting to the growing online audience. They wanted to build and deliver content primarily over the web.</li>
<li>Pearson had difficulty in scaling and adapting to the growing online audience. They wanted to build and deliver content primarily over the web.</li>
</ul>
</div>
<divclass="bullet">
<h4>Why Kubernetes:</h4>
<ul>
<li>Kubernetes will allow Pearson's teams to develop their apps in a consistent manner, saving time and minimizing complexity.</li>
<li>Kubernetes will allow Pearson's teams to develop their apps in a consistent manner, saving time and minimizing complexity.</li>
<divclass="subhead">Cloud-Native Infrastructure Keeps Your Smart Home Connected</div>
</h1>
</div>
<divclass="details">
Company <b>Wink</b> Location <b>New York, N.Y.</b> Industry <b>Internet of Things Platform</b>
</div>
<hr>
<sectionclass="section1">
<divclass="cols">
<divclass="col1">
<h2>Challenge</h2>
Building a low-latency, highly reliable infrastructure to serve communications between millions of connected smart-home devices and the company’s consumer hubs and mobile app, with an emphasis on horizontal scalability, the ability to encrypt everything quickly and connections that could be easily brought back up if anything went wrong.
<br><br>
<h2>Solution</h2>
Across-the-board use of a Kubernetes-Docker-CoreOS Container Linux stack.<br><br>
</div>
<divclass="col2">
<h2>Impact</h2>
"Two of the biggest American retailers [Home Depot and Walmart] are carrying and promoting the brand and the hardware,” Wink Head of Engineering Kit Klein says proudly – though he adds that "it really comes with a lot of pressure. It’s not a retail situation where you have a lot of tech enthusiasts. These are everyday people who want something that works and have no tolerance for technical excuses.” And that’s further testament to how much faith Klein has in the infrastructure that the Wink team has built. With 80 percent of Wink’s workload running on a unified stack of Kubernetes-Docker-CoreOS, the company has put itself in a position to continually innovate and improve its products and services. Committing to this technology, says Klein, "makes building on top of the infrastructure relatively easy.”
</div>
</div>
</section>
<divclass="banner2">
<divclass="banner2text">
"It’s not proprietary, it’s totally open, it’s really portable. You can run all the workloads across different cloud providers. You can easily run a hybrid AWS or even bring in your own data center. That’s the benefit of having everything unified on one open source Kubernetes-Docker-CoreOS Container Linux stack. There are massive security benefits if you only have one Linux distro/machine image to validate. The benefits are enormous because you save money, and you save time.”<br><br><spanstyle="font-size:15px;letter-spacing:0.08em">- KIT KLEIN, HEAD OF ENGINEERING, WINK</span>
</div>
</div>
<sectionclass="section2">
<divclass="fullcol">
<h2>How many people does it take to turn on a light bulb?</h2>
Kit Klein whips out his phone to demonstrate. With a few swipes, the head of engineering at Wink pulls up the smart-home app created by the New York City-based company and taps the light button. "Honestly when you’re holding the phone and you’re hitting the light,” he says, "by the time you feel the pressure of your finger on the screen, it’s on. It takes as long as the signal to travel to your brain.”<br><br>
Sure, it takes just one finger and less than 200 milliseconds to turn on the light – or lock a door or change a thermostat. But what allows Wink to help consumers manage their connected smart-home products with such speed and ease is a sophisticated, cloud native infrastructure that Klein and his team built and continue to develop using a unified stack of CoreOS, the open-source operating system designed for clustered deployments, and Kubernetes, an open-source platform for automating deployment, scaling, and operations of application containers across clusters of hosts, providing container-centric infrastructure. "When you have a big, complex network of interdependent microservices that need to be able to discover each other, and need to be horizontally scalable and tolerant to failure, that’s what this is really optimized for,” says Klein. "A lot of people end up relying on proprietary services [offered by some big cloud providers] to do some of this stuff, but what you get by adopting CoreOS/Kubernetes is portability, to not be locked in to anyone. You can really make your own fate.”<br><br>
Indeed, Wink did. The company’s mission statement is to make the connected home accessible – that is, user-friendly for non-technical owners, affordable and perhaps most importantly, reliable. "If you can’t trust that when you hit the switch, you know a light is going to go on, or if you’re remote and you’re checking on your house and that information isn’t accurate, then the convenience of the system is lost,” says Klein. "So that’s where the infrastructure comes in.”<br><br>
Wink was incubated within Quirky, a company that developed crowd-sourced inventions. The Wink app was first introduced in 2013, and at the time, it controlled only a few consumer products such as the PivotPower Strip that Quirky produced in collaboration with GE. As smart-home products proliferated, Wink was launched in 2014 in Home Depot stores nationwide. Its first project: a hub that could integrate with smart products from about a dozen brands like Honeywell and Chamberlain. The biggest challenge would be to build the infrastructure to serve all those communications between the hub and the products, with a focus on maximizing reliability and minimizing latency.<br><br>
"When we originally started out, we were moving very fast trying to get the first product to market, the minimum viable product,” says Klein. "Lots of times you go down a path and end up having to backtrack and try different things. But in this particular case, we did a lot of the work up front, which led to us making a really sound decision to deploy it on CoreOS Container Linux. And that was very early in the life of it.”
</div>
</section>
<divclass="banner3">
<divclass="banner3text">
"...what you get by adopting CoreOS/Kubernetes is portability, to not be locked in to anyone. You can really make your own fate.”
</div>
</div>
<sectionclass="section3">
<divclass="fullcol">
Concern number one: Wink’s products need to connect to consumer devices in people’s homes, behind a firewall. "You don’t have an end point like a URL, and you don’t even know what ports are open behind that firewall,” Klein explains. "So you essentially need to have this thing wake up and talk to your system and then open real-time, bidirectional communication between the cloud and the device. And it’s really, really important that it’s persistent because you want to decrease as much as possible the overhead of sending a message – you never know when someone is going to turn on the lights.”<br><br>
With the earliest version of the Wink Hub, when you decided to turn your lights on or off, the request would be sent to the cloud and then executed. Subsequent updates to Wink’s software enabled local control, cutting latency down to about 10 milliseconds for many devices. But with the need for cloud-enabled integrations of an ever-growing ecosystem of smart home products, low-latency internet connectivity is still a critical consideration.
<br><br>
<h2>"You essentially need to have this thing wake up and talk to your system and then open real-time, bidirectional communication between the cloud and the device. And it’s really, really important that it’s persistent...you never know when someone is going to turn on the lights.”</h2>
In addition, Wink had other requirements: horizontal scalability, the ability to encrypt everything quickly, connections that could be easily brought back up if something went wrong. "Looking at this whole structure we started, we decided to make a secure socket-based service,” says Klein. "We’ve always used, I would say, some sort of clustering technology to deploy our services and so the decision we came to was, this thing is going to be containerized, running on Docker.”<br><br>
At the time – just over two years ago – Docker wasn’t yet widely used, but as Klein points out, "it was certainly understood by the people who were on the frontier of technology. We started looking at potential technologies that existed. One of the limiting factors was that we needed to deploy multi-port non-http/https services. It wasn’t really appropriate for some of the early cluster technology. We liked the project a lot and we ended up using it on other stuff for a while, but initially it was too targeted toward http workloads.”<br><br>
Once Wink’s backend engineering team decided on a Dockerized workload, they had to make decisions about the OS and the container orchestration platform. "Obviously you can’t just start the containers and hope everything goes well,” Klein says with a laugh. "You need to have a system that is helpful [in order] to manage where the workloads are being distributed out to. And when the container inevitably dies or something like that, to restart it, you have a load balancer. All sorts of housekeeping work is needed to have a robust infrastructure.”
</div>
</section>
<divclass="banner4">
<divclass="banner4text">
"Obviously you can’t just start the containers and hope everything goes well,” Klein says with a laugh. "You need to have a system that is helpful [in order] to manage where the workloads are being distributed out to. And when the container inevitably dies or something like that, to restart it, you have a load balancer. All sorts of housekeeping work is needed to have a robust infrastructure.”
</div>
</div>
<sectionclass="section4">
<divclass="fullcol">
Wink considered building directly on a general purpose Linux distro like Ubuntu (which would have required installing tools to run a containerized workload) and cluster management systems like Mesos (which was targeted toward enterprises with larger teams/workloads), but ultimately set their sights on CoreOS Container Linux. "A container-optimized Linux distribution system was exactly what we needed,” he says. "We didn’t have to futz around with trying to take something like a Linux distro and install everything. It’s got a built-in container orchestration system, which is Fleet, and an easy-to-use API. It’s not as feature-rich as some of the heavier solutions, but we realized that, at that moment, it was exactly what we needed.”<br><br>
Wink’s hub (along with a revamped app) was introduced in July 2014 with a short-term deployment, and within the first month, they had moved the service to the Dockerized CoreOS deployment. Since then, they’ve moved almost every other piece of their infrastructure – from third-party cloud-to-cloud integrations to their customer service and payment portals – onto CoreOS Container Linux clusters. <br><br>
Using this setup did require some customization. "Fleet is really nice as a basic container orchestration system, but it doesn’t take care of routing, sharing configurations, secrets, et cetera, among instances of a service,” Klein says. "All of those layers of functionality can be implemented, of course, but if you don’t want to spend a lot of time writing unit files manually – which of course nobody does – you need to create a tool to automate some of that, which we did.”<br><br>
Wink quickly embraced the Kubernetes container cluster manager when it was launched in 2015 and integrated with CoreOS core technology, and as promised, it ended up providing the features Wink wanted and had planned to build. "If not for Kubernetes, we likely would have taken the logic and library we implemented for the automation tool that we created, and would have used it in a higher level abstraction and tool that could be used by non-DevOps engineers from the command line to create and manage clusters,” Klein says. "But Kubernetes made that totally unnecessary – and is written and maintained by people with a lot more experience in cluster management than us, so all the better.” Now, an estimated 80 percent of Wink’s workload is run on Kubernetes on top of CoreOS Container Linux.
</div>
</section>
<divclass="banner5">
<divclass="banner5text">
"Stay close to the development. Understand why decisions are being made. If you understand the intent behind the project, from the technological intent to a certain philosophical intent, then it helps you understand how to build your system in harmony with those systems as opposed to trying to work against it.”
</div>
</div>
<sectionclass="section5">
<divclass="fullcol">
Wink’s reasons for going all in are clear: "It’s not proprietary, it’s totally open, it’s really portable,” Klein says. "You can run all the workloads across different cloud providers. You can easily run a hybrid AWS or even bring in your own data center. That’s the benefit of having everything unified on one Kubernetes-Docker-CoreOS Container Linux stack. There are massive security benefits if you only have one Linux distro to try to validate. The benefits are enormous because you save money, you save time.”<br><br>
Klein concedes that there are tradeoffs in every technology decision. "Cutting-edge technology is going to be scary for some people,” he says. "In order to take advantage of this, you really have to keep up with the technology. You can’t treat it like it’s a black box. Stay close to the development. Understand why decisions are being made. If you understand the intent behind the project, from the technological intent to a certain philosophical intent, then it helps you understand how to build your system in harmony with those systems as opposed to trying to work against it.”<br><br>
Wink, which was acquired by Flex in 2015, now controls 2.3 million connected devices in households all over the country. What’s next for the company? A new version of the hub - Wink Hub 2 - hit shelves last November – and is being offered for the first time at Walmart stores in addition to Home Depot. "Two of the biggest American retailers are carrying and promoting the brand and the hardware,” Klein says proudly – though he adds that "it really comes with a lot of pressure. It’s not a retail situation where you have a lot of tech enthusiasts. These are everyday people who want something that works and have no tolerance for technical excuses.” And that’s further testament to how much faith Klein has in the infrastructure that the Wink team has have built.<br><br>
Wink’s engineering team has grown exponentially since its early days, and behind the scenes, Klein is most excited about the machine learning Wink is using. "We built [a system of] containerized small sections of the data pipeline that feed each other and can have multiple outputs,” he says. "It’s like data pipelines as microservices.” Again, Klein points to having a unified stack running on CoreOS Container Linux and Kubernetes as the primary driver for the innovations to come. "You’re not reinventing the wheel every time,” he says. "You can just get down to work.” </div>
* **API request verb** - API 动词 `get`，`list`，`create`，`update`，`patch`，`watch`，`proxy`，`redirect`，`delete`和`deletecollection`用于资源请求。要确定资源 API 端点的请求动词，请参阅**确定下面的请求动词**.
A kubelet's HTTPS endpoint exposes APIs which give access to data of varying sensitivity,
and allow you to perform operations with varying levels of power on the node and within containers.
This document describes how to authenticate and authorize access to the kubelet's HTTPS endpoint.
## Kubelet authentication
By default, requests to the kubelet's HTTPS endpoint that are not rejected by other configured
authentication methods are treated as anonymous requests, and given a username of `system:anonymous`
and a group of `system:unauthenticated`.
To disable anonymous access and send `401 Unauthorized` responses to unauthenticated requests:
* start the kubelet with the `--anonymous-auth=false` flag
To enable X509 client certificate authentication to the kubelet's HTTPS endpoint:
* start the kubelet with the `--client-ca-file` flag, providing a CA bundle to verify client certificates with
* start the apiserver with `--kubelet-client-certificate` and `--kubelet-client-key` flags
* see the [apiserver authentication documentation](/docs/admin/authentication/#x509-client-certs) for more details
To enable API bearer tokens (including service account tokens) to be used to authenticate to the kubelet's HTTPS endpoint:
* ensure the `authentication.k8s.io/v1beta1` API group is enabled in the API server
* start the kubelet with the `--authentication-token-webhook`, `--kubeconfig`, and `--require-kubeconfig` flags
* the kubelet calls the `TokenReview` API on the configured API server to determine user information from bearer tokens
## Kubelet authorization
Any request that is successfully authenticated (including an anonymous request) is then authorized. The default authorization mode is `AlwaysAllow`, which allows all requests.
There are many possible reasons to subdivide access to the kubelet API:
* anonymous auth is enabled, but anonymous users' ability to call the kubelet API should be limited
* bearer token auth is enabled, but arbitrary API users' (like service accounts) ability to call the kubelet API should be limited
* client certificate auth is enabled, but only some of the client certificates signed by the configured CA should be allowed to use the kubelet API
To subdivide access to the kubelet API, delegate authorization to the API server:
* ensure the `authorization.k8s.io/v1beta1` API group is enabled in the API server
* start the kubelet with the `--authorization-mode=Webhook`, `--kubeconfig`, and `--require-kubeconfig` flags
* the kubelet calls the `SubjectAccessReview` API on the configured API server to determine whether each request is authorized
The kubelet authorizes API requests using the same [request attributes](/docs/admin/authorization/#request-attributes) approach as the apiserver.
The verb is determined from the incoming request's HTTP verb:
HTTP verb | request verb
----------|---------------
POST | create
GET, HEAD | get
PUT | update
PATCH | patch
DELETE | delete
The resource and subresource is determined from the incoming request's path:
Kubelet API | resource | subresource
-------------|----------|------------
/stats/\* | nodes | stats
/metrics/\* | nodes | metrics
/logs/\* | nodes | log
/spec/\* | nodes | spec
*all others* | nodes | proxy
The namespace and API group attributes are always an empty string, and
the resource name is always the name of the kubelet's `Node` API object.
When running in this mode, ensure the user identified by the `--kubelet-client-certificate` and `--kubelet-client-key`
flags passed to the apiserver is authorized for the following attributes:
This document describes how to set up TLS client certificate bootstrapping for kubelets.
Kubernetes 1.4 introduced an API for requesting certificates from a cluster-level Certificate Authority (CA). The original intent of this API is to enable provisioning of TLS client certificates for kubelets. The proposal can be found [here](https://github.com/kubernetes/kubernetes/pull/20439)
and progress on the feature is being tracked as [feature #43](https://github.com/kubernetes/features/issues/43).
## kube-apiserver configuration
The API server should be configured with an [authenticator](/docs/admin/authentication/) that can authenticate tokens as a user in the `system:bootstrappers` group.
This group will later be used in the controller-manager configuration to scope approvals in the default approval
controller. As this feature matures, you should ensure tokens are bound to a Role-Based Access Control (RBAC) policy which limits requests
(using the bootstrap token) strictly to client requests related to certificate provisioning. With RBAC in place, scoping the tokens to a group allows for great flexibility (e.g. you could disable a particular bootstrap group's access when you are done provisioning the nodes).
While any authentication strategy can be used for the kubelet's initial bootstrap credentials, the following two authenticators are recommended for ease of provisioning.
Add the `--token-auth-file=FILENAME` flag to the kube-apiserver command (in your systemd unit file perhaps) to enable the token file.
See docs [here](/docs/admin/authentication/#static-token-file) for further details.
### Client certificate CA bundle
Add the `--client-ca-file=FILENAME` flag to the kube-apiserver command to enable client certificate authentication,
referencing a certificate authority bundle containing the signing certificate (e.g. `--client-ca-file=/var/lib/kubernetes/ca.pem`).
## kube-controller-manager configuration
The API for requesting certificates adds a certificate-issuing control loop to the Kubernetes Controller Manager. This takes the form of a
[cfssl](https://blog.cloudflare.com/introducing-cfssl/) local signer using assets on disk. Currently, all certificates issued have one year validity and a default set of key usages.
### Signing assets
You must provide a Certificate Authority in order to provide the cryptographic materials necessary to issue certificates.
This CA should be trusted by kube-apiserver for authentication with the `--client-ca-file=FILENAME` flag. The management
of the CA is beyond the scope of this document but it is recommended that you generate a dedicated CA for Kubernetes.
Both certificate and key are assumed to be PEM-encoded.
An admin would create a `ClusterRoleBinding` targeting that group.
```yml
# Approve all CSRs for the group "system:bootstrappers"
kind:ClusterRoleBinding
apiVersion:rbac.authorization.k8s.io/v1beta1
metadata:
name:auto-approve-csrs-for-group
subjects:
- kind:Group
name:system:bootstrappers
apiGroup:rbac.authorization.k8s.io
roleRef:
kind:ClusterRole
name:approve-node-client-csr
apiGroup:rbac.authorization.k8s.io
```
To let a node renew its own credentials, an admin can construct a `ClusterRoleBinding` targeting
that node's credentials:
```yml
kind:ClusterRoleBinding
apiVersion:rbac.authorization.k8s.io/v1beta1
metadata:
name:node1-client-cert-renewal
subjects:
- kind:User
name:system:node:node-1# Let "node-1" renew its client certificate.
apiGroup:rbac.authorization.k8s.io
roleRef:
kind:ClusterRole
name:approve-node-client-renewal-csr
apiGroup:rbac.authorization.k8s.io
```
Deleting the binding will prevent the node from renewing its client credentials, effectively
removing it from the cluster once its certificate expires.
## kubelet configuration
To request a client certificate from kube-apiserver, the kubelet first needs a path to a kubeconfig file that contains the
bootstrap authentication token. You can use `kubectl config set-cluster`, `set-credentials`, and `set-context` to build this kubeconfig. Provide the name `kubelet-bootstrap` to `kubectl config set-credentials` and include `--token=<token-value>` as follows:
When starting the kubelet, if the file specified by `--kubeconfig` does not exist, the bootstrap kubeconfig is used to request a client certificate from the API server. On approval of the certificate request and receipt back by the kubelet, a kubeconfig file referencing the generated key and obtained certificate is written to the path specified by `--kubeconfig`. The certificate and key file will be placed in the directory specified by `--cert-dir`.
**Note:** The following flags are required to enable this bootstrapping when starting the kubelet:
`RotateKubeletClientCertificate` causes the kubelet to rotate its client certificates by creating new CSRs as its existing
credentials expire. `RotateKubeletServerCertificate` causes the kubelet to both request a serving certificate after
bootstrapping its client credentials and rotate the certificate. The serving cert currently does not request DNS or IP
SANs.
## kubectl approval
The signing controller does not immediately sign all certificate requests. Instead, it waits until they have been flagged with an
"Approved" status by an appropriately-privileged user. This is intended to eventually be an automated process handled by an external
approval controller, but for the alpha version of the API it can be done manually by a cluster administrator using kubectl.
An administrator can list CSRs with `kubectl get csr` and describe one in detail with `kubectl describe csr <name>`. Before the 1.6 release there were
[no direct approve/deny commands](https://github.com/kubernetes/kubernetes/issues/30163) so an approver had to update
the Status field directly ([rough how-to](https://github.com/gtank/csrctl)). Later versions of Kubernetes offer `kubectl certificate approve <name>` and `kubectl certificate deny <name>` commands.
This document highlights and consolidates configuration best practices that are introduced throughout the user-guide, getting-started documentation, and examples.
This is a living document. If you think of something that is not on this list but might be useful to others, please don't hesitate to file an issue or submit a PR.
{% endcapture %}
{% capture body %}
## General Config Tips
- When defining configurations, specify the latest stable API version (currently v1).
- Configuration files should be stored in version control before being pushed to the cluster. This allows quick roll-back of a configuration if needed. It also aids with cluster re-creation and restoration if necessary.
- Write your configuration files using YAML rather than JSON. Though these formats can be used interchangeably in almost all scenarios, YAML tends to be more user-friendly.
- Group related objects into a single file whenever it makes sense. One file is often easier to manage than several. See the [guestbook-all-in-one.yaml](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/guestbook/all-in-one/guestbook-all-in-one.yaml) file as an example of this syntax.
Note also that many `kubectl` commands can be called on a directory, so you can also call `kubectl create` on a directory of config files. See below for more details.
- Don't specify default values unnecessarily, in order to simplify and minimize configs, and to reduce error. For example, omit the selector and labels in a `ReplicationController` if you want them to be the same as the labels in its `podTemplate`, since those fields are populated from the `podTemplate` labels by default. See the [guestbook app's](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/guestbook/) .yaml files for some [examples](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/guestbook/frontend-deployment.yaml) of this.
- Put an object description in an annotation to allow better introspection.
## "Naked" Pods vs Replication Controllers and Jobs
- If there is a viable alternative to naked pods (in other words: pods not bound to a [replication controller](/docs/user-guide/replication-controller)), go with the alternative. Naked pods will not be rescheduled in the event of node failure.
Replication controllers are almost always preferable to creating pods, except for some explicit [`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) scenarios. A [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/) object (currently in Beta) may also be appropriate.
## Services
- It's typically best to create a [service](/docs/concepts/services-networking/service/) before corresponding [replication controllers](/docs/concepts/workloads/controllers/replicationcontroller/). This lets the scheduler spread the pods that comprise the service.
You can also use this process to ensure that at least one replica works before creating lots of them:
1. Create a replication controller without specifying replicas (this will set replicas=1);
2. Create a service;
3. Then scale up the replication controller.
- Don't use `hostPort` unless it is absolutely necessary (for example: for a node daemon). It specifies the port number to expose on the host. When you bind a Pod to a `hostPort`, there are a limited number of places to schedule a pod due to port conflicts— you can only schedule as many such Pods as there are nodes in your Kubernetes cluster.
If you only need access to the port for debugging purposes, you can use the [kubectl proxy and apiserver proxy](/docs/tasks/access-kubernetes-api/http-proxy-access-api/) or [kubectl port-forward](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
You can use a [Service](/docs/concepts/services-networking/service/) object for external service access.
If you explicitly need to expose a pod's port on the host machine, consider using a [NodePort](/docs/user-guide/services/#type-nodeport) service before resorting to `hostPort`.
- Avoid using `hostNetwork`, for the same reasons as `hostPort`.
- Use _headless services_ for easy service discovery when you don't need kube-proxy load balancing. See [headless services](/docs/user-guide/services/#headless-services).
## Using Labels
- Define and use [labels](/docs/user-guide/labels/) that identify __semantic attributes__ of your application or deployment. For example, instead of attaching a label to a set of pods to explicitly represent some service (For example, `service: myservice`), or explicitly representing the replication controller managing the pods (for example, `controller: mycontroller`), attach labels that identify semantic attributes, such as `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. This will let you select the object groups appropriate to the context— for example, a service for all "tier: frontend" pods, or all "test" phase components of app "myapp". See the [guestbook](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/guestbook/) app for an example of this approach.
A service can be made to span multiple deployments, such as is done across [rolling updates](/docs/tasks/run-application/rolling-update-replication-controller/), by simply omitting release-specific labels from its selector, rather than updating a service's selector to match the replication controller's selector fully.
- To facilitate rolling updates, include version info in replication controller names, for example as a suffix to the name. It is useful to set a 'version' label as well. The rolling update creates a new controller as opposed to modifying the existing controller. So, there will be issues with version-agnostic controller names. See the [documentation](/docs/tasks/run-application/rolling-update-replication-controller/) on the rolling-update command for more detail.
Note that the [Deployment](/docs/concepts/workloads/controllers/deployment/) object obviates the need to manage replication controller 'version names'. A desired state of an object is described by a Deployment, and if changes to that spec are _applied_, the deployment controller changes the actual state to the desired state at a controlled rate. (Deployment objects are currently part of the [`extensions` API Group](/docs/concepts/overview/kubernetes-api/#api-groups).)
- You can manipulate labels for debugging. Because Kubernetes replication controllers and services match to pods using labels, this allows you to remove a pod from being considered by a controller, or served traffic by a service, by removing the relevant selector labels. If you remove the labels of an existing pod, its controller will create a new pod to take its place. This is a useful way to debug a previously "live" pod in a quarantine environment. See the [`kubectl label`](/docs/concepts/overview/working-with-objects/labels/) command.
## Container Images
- The [default container image pull policy](/docs/concepts/containers/images/) is `IfNotPresent`, which causes the [Kubelet](/docs/admin/kubelet/) to not pull an image if it already exists. If you would like to always force a pull, you must specify a pull image policy of `Always` in your .yaml file (`imagePullPolicy: Always`) or specify a `:latest` tag on your image.
That is, if you're specifying an image with other than the `:latest` tag, for example `myimage:v1`, and there is an image update to that same tag, the Kubelet won't pull the updated image. You can address this by ensuring that any updates to an image bump the image tag as well (for example, `myimage:v2`), and ensuring that your configs point to the correct version.
**Note:** You should avoid using `:latest` tag when deploying containers in production, because this makes it hard to track which version of the image is running and hard to roll back.
- To work only with a specific version of an image, you can specify an image with its digest (SHA256). This approach guarantees that the image will never update. For detailed information about working with image digests, see [the Docker documentation](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier).
## Using kubectl
- Use `kubectl create -f <directory>` where possible. This looks for config objects in all `.yaml`, `.yml`, and `.json` files in `<directory>` and passes them to `create`.
- Use `kubectl delete` rather than `stop`. `Delete` has a superset of the functionality of `stop`, and `stop` is deprecated.
- Use kubectl bulk operations (via files and/or labels) for get and delete. See [label selectors](/docs/user-guide/labels/#label-selectors) and [using labels effectively](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
- Use `kubectl run` and `expose` to quickly create and expose single container Deployments. See the [quick start guide](/docs/user-guide/quick-start/) for an example.
此处，Kubernetes 不仅仅是一个 "编排系统"；它消除了编排的需要。 "编排"技术定义的是工作流的执行: 从 A 到 B，然后到 C。相反，Kubernetes 是包括一套独立、可组合的控制过程，通过声明式语法使其连续地朝着期望状态驱动当前状态。 不需要告诉它具体从 A 到 C 的过程，只要告诉到 C 的状态即可。 也不需要集中控制；该方法更类似于"编舞"。这使得系统更容易使用并且更强大、更可靠、更具弹性和可扩展性。
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Zach Corleissen