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

Merge branch 'master' into dev-1.15

Browse Source
This commit is contained in:
Barnabas Makonda
2019-06-19 23:19:27 +03:00
committed by GitHub
parent f04d0cf472 0e1e971f13
commit 455f312775
33 changed files with 458 additions and 302 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/reference/glossary/minikube.md
+3 -2
View File
@@ -2,7 +2,7 @@
title: Minikube
id: minikube
date: 2018-04-12
full_link: /docs/getting-started-guides/minikube/
full_link: /docs/setup/learning-environment/minikube/
short_description: >
A tool for running Kubernetes locally.
@@ -16,4 +16,5 @@ tags:
<!--more-->
Minikube runs a single-node cluster inside a VM on your computer.
You can use Minikube to
[try Kubernetes in a learning environment](/docs/setup/learning-environment/).
content/en/docs/reference/issues-security/security.md
+4 -2
View File
@@ -33,7 +33,9 @@ You may encrypt your email to this list using the GPG keys of the [Product Secur
- You think you discovered a potential security vulnerability in Kubernetes
- You are unsure how a vulnerability affects Kubernetes
- You think you discovered a vulnerability in another project that Kubernetes depends on (e.g. docker, rkt, etcd)
- You think you discovered a vulnerability in another project that Kubernetes depends on
- For projects with their own vulnerability reporting and disclosure process, please report it directly there
### When Should I NOT Report a Vulnerability?
@@ -51,5 +53,5 @@ As the security issue moves from triage, to identified fix, to release planning
## Public Disclosure Timing
A public disclosure date is negotiated by the Kubernetes Product Security Committee and the bug submitter. We prefer to fully disclose the bug as soon as possible once a user mitigation is available. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested, or for vendor coordination. The timeframe for disclosure is from immediate (especially if it's already publicly known) to a few weeks. As a basic default, we expect report date to disclosure date to be on the order of 7 days. The Kubernetes Product Security Committee holds the final say when setting a disclosure date.
A public disclosure date is negotiated by the Kubernetes Product Security Committee and the bug submitter. We prefer to fully disclose the bug as soon as possible once a user mitigation is available. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested, or for vendor coordination. The timeframe for disclosure is from immediate (especially if it's already publicly known) to a few weeks. For a vulnerability with a straightforward mitigation, we expect report date to disclosure date to be on the order of 7 days. The Kubernetes Product Security Committee holds the final say when setting a disclosure date.
{{% /capture %}}
content/en/docs/reference/kubectl/cheatsheet.md
+3
View File
@@ -182,6 +182,9 @@ echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name
# Also uses "jq"
for item in $( kubectl get pod --output=name); do printf "Labels for %s\n" "$item" | grep --color -E '[^/]+$' && kubectl get "$item" --output=json | jq -r -S '.metadata.labels | to_entries | .[] | " \(.key)=\(.value)"' 2>/dev/null; printf "\n"; done
# Or this command can be used as well to get all the labels associated with pods
kubectl get pods --show-labels
# Check which nodes are ready
JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \
&& kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"
content/en/docs/reference/kubectl/conventions.md
+9 -13
View File
@@ -37,19 +37,15 @@ For `kubectl run` to satisfy infrastructure as code:
You can create the following resources using `kubectl run` with the `--generator` flag:
| Resource | kubectl command |
|---------------------------------|---------------------------------------------------|
| Pod | `kubectl run --generator=run-pod/v1` |
| Replication controller | `kubectl run --generator=run/v1` |
| Deployment | `kubectl run --generator=extensions/v1beta1` |
| -for an endpoint (default) | `kubectl run --generator=deployment/v1beta1` |
| Deployment | `kubectl run --generator=apps/v1beta1` |
| -for an endpoint (recommended) | `kubectl run --generator=deployment/apps.v1beta1` |
| Job | `kubectl run --generator=job/v1` |
| CronJob | `kubectl run --generator=batch/v1beta1` |
| -for an endpoint (default) | `kubectl run --generator=cronjob/v1beta1` |
| CronJob | `kubectl run --generator=batch/v2alpha1` |
| -for an endpoint (deprecated) | `kubectl run --generator=cronjob/v2alpha1` |
| Resource | api group | kubectl command |
|---------------------------------|--------------------|---------------------------------------------------|
| Pod | v1 | `kubectl run --generator=run-pod/v1` |
| Replication controller | v1 | `kubectl run --generator=run/v1` |
| Deployment (deprecated) | extensions/v1beta1 | `kubectl run --generator=deployment/v1beta1` |
| Deployment (deprecated) | apps/v1beta1 | `kubectl run --generator=deployment/apps.v1beta1` |
| Job (deprecated) | batch/v1 | `kubectl run --generator=job/v1` |
| CronJob (default) | batch/v1beta1 | `kubectl run --generator=cronjob/v1beta1` |
| CronJob (deprecated) | batch/v2alpha1 | `kubectl run --generator=cronjob/v2alpha1` |
If you do not specify a generator flag, other flags prompt you to use a specific generator. The following table lists the flags that force you to use specific generators, depending on the version of the cluster: