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

Sync between master and dev-1.18

Browse Source 
This PR contains sync up between master and dev-1.18 and also reolsved merge conflicts occured during previous sync during previous sync up caused due to missed adding tide-method merge

Signed-off-by: vineeth <vineethpothulapati@outlook.com>
This commit is contained in:
vineeth
2020-02-14 01:30:05 +05:30
parent 63f30b086a 669bf498a9
commit 9433b26564
37 changed files with 1287 additions and 433 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md
+6 -4
View File
@@ -127,10 +127,12 @@ IP and may cause a second hop to another node, but should have good overall
load-spreading. Local preserves the client source IP and avoids a second hop
for LoadBalancer and NodePort type services, but risks potentially imbalanced
traffic spreading.
* `service.spec.healthCheckNodePort` - specifies the health check nodePort
(numeric port number) for the service. If not specified, `healthCheckNodePort` is
created by the service API backend with the allocated `nodePort`. It will use the
user-specified `nodePort` value if specified by the client. It only has an
* `service.spec.healthCheckNodePort` - specifies the health check node port
(numeric port number) for the service. If `healthCheckNodePort` isn't specified,
the service controller allocates a port from your cluster's NodePort range. You
can configure that range by setting an API server command line option,
`--service-node-port-range`. It will use the
user-specified `healthCheckNodePort` value if specified by the client. It only has an
effect when `type` is set to LoadBalancer and `externalTrafficPolicy` is set
to Local.
content/en/docs/tasks/administer-cluster/declare-network-policy.md
+33 -48
View File
@@ -3,6 +3,7 @@ reviewers:
- caseydavenport
- danwinship
title: Declare Network Policy
min-kubernetes-server-version: v1.8
content_template: templates/task
---
{{% capture overview %}}
@@ -30,7 +31,7 @@ The above list is sorted alphabetically by product name, not by recommendation o
## Create an `nginx` deployment and expose it via a service
To see how Kubernetes network policy works, start off by creating an `nginx` deployment.
To see how Kubernetes network policy works, start off by creating an `nginx` Deployment.
```console
kubectl create deployment nginx --image=nginx
@@ -39,7 +40,7 @@ kubectl create deployment nginx --image=nginx
deployment.apps/nginx created
```
And expose it via a service.
Expose the Deployment through a Service called `nginx`.
```console
kubectl expose deployment nginx --port=80
@@ -49,7 +50,7 @@ kubectl expose deployment nginx --port=80
service/nginx exposed
```
This runs a `nginx` pods in the default namespace, and exposes it through a service called `nginx`.
The above commands create a Deployment with an nginx Pod and expose the Deployment through a Service named `nginx`. The `nginx` Pod and Deployment are found in the `default` namespace.
```console
kubectl get svc,pod
@@ -64,59 +65,43 @@ NAME READY STATUS RESTARTS AGE
pod/nginx-701339712-e0qfq 1/1 Running 0 35s
```
## Test the service by accessing it from another pod
## Test the service by accessing it from another Pod
You should be able to access the new `nginx` service from other pods. To test, access the service from another pod in the default namespace. Make sure you haven't enabled isolation on the namespace.
Start a busybox container, and use `wget` on the `nginx` service:
You should be able to access the new `nginx` service from other Pods. To access the `nginx` Service from another Pod in the `default` namespace, start a busybox container:
```console
kubectl run --generator=run-pod/v1 busybox --rm -ti --image=busybox -- /bin/sh
```
```console
Waiting for pod default/busybox-472357175-y0m47 to be running, status is Pending, pod ready: false
In your shell, run the following command:
Hit enter for command prompt
```shell
wget --spider --timeout=1 nginx
```
/ # wget --spider --timeout=1 nginx
```none
Connecting to nginx (10.100.0.16:80)
/ #
remote file exists
```
## Limit access to the `nginx` service
Let's say you want to limit access to the `nginx` service so that only pods with the label `access: true` can query it. To do that, create a `NetworkPolicy` that allows connections only from those pods:
To limit the access to the `nginx` service so that only Pods with the label `access: true` can query it, create a NetworkPolicy object as follows:
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: access-nginx
spec:
podSelector:
matchLabels:
app: nginx
ingress:
- from:
- podSelector:
matchLabels:
access: "true"
```
{{< codenew file="service/networking/nginx-policy.yaml" >}}
{{< note >}}
In the case, the label `app=nginx` is automatically added.
NetworkPolicy includes a `podSelector` which selects the grouping of Pods to which the policy applies. You can see this policy selects Pods with the label `app=nginx`. The label was automatically added to the Pod in the `nginx` Deployment. An empty `podSelector` selects all pods in the namespace.
{{< /note >}}
## Assign the policy to the service
Use kubectl to create a NetworkPolicy from the above nginx-policy.yaml file:
Use kubectl to create a NetworkPolicy from the above `nginx-policy.yaml` file:
```console
kubectl apply -f nginx-policy.yaml
kubectl apply -f https://k8s.io/examples/service/networking/nginx-policy.yaml
```
```none
@@ -124,40 +109,40 @@ networkpolicy.networking.k8s.io/access-nginx created
```
## Test access to the service when access label is not defined
If we attempt to access the nginx Service from a pod without the correct labels, the request will now time out:
When you attempt to access the `nginx` Service from a Pod without the correct labels, the request times out:
```console
kubectl run --generator=run-pod/v1 busybox --rm -ti --image=busybox -- /bin/sh
```
```console
Waiting for pod default/busybox-472357175-y0m47 to be running, status is Pending, pod ready: false
In your shell, run the command:
Hit enter for command prompt
```shell
wget --spider --timeout=1 nginx
```
/ # wget --spider --timeout=1 nginx
```none
Connecting to nginx (10.100.0.16:80)
wget: download timed out
/ #
```
## Define access label and test again
Create a pod with the correct labels, and you'll see that the request is allowed:
You can create a Pod with the correct labels to see that the request is allowed:
```console
kubectl run --generator=run-pod/v1 busybox --rm -ti --labels="access=true" --image=busybox -- /bin/sh
```
```console
Waiting for pod default/busybox-472357175-y0m47 to be running, status is Pending, pod ready: false
In your shell, run the command:
Hit enter for command prompt
/ # wget --spider --timeout=1 nginx
Connecting to nginx (10.100.0.16:80)
/ #
```shell
wget --spider --timeout=1 nginx
```
```none
Connecting to nginx (10.100.0.16:80)
remote file exists
```
{{% /capture %}}
content/en/docs/tasks/federation/policy.rego
-74
View File
@@ -1,74 +0,0 @@
# OPA supports a high-level declarative language named Rego for authoring and
# enforcing policies. For more information on Rego, visit
# http://openpolicyagent.org.
# Rego policies are namespaced by the "package" directive.
package kubernetes.placement
# Imports provide aliases for data inside the policy engine. In this case, the
# policy simply refers to "clusters" below.
import data.kubernetes.clusters
# The "annotations" rule generates a JSON object containing the key
# "federation.kubernetes.io/replica-set-preferences" mapped to <preferences>.
# The preferences values is generated dynamically by OPA when it evaluates the
# rule.
#
# The SchedulingPolicy Admission Controller running inside the Federation API
# server will merge these annotations into incoming Federated resources. By
# setting replica-set-preferences, we can control the placement of Federated
# ReplicaSets.
#
# Rules are defined to generate JSON values (booleans, strings, objects, etc.)
# When OPA evaluates a rule, it generates a value IF all of the expressions in
# the body evaluate successfully. All rules can be understood intuitively as
# <head> if <body> where <body> is true if <expr-1> AND <expr-2> AND ...
# <expr-N> is true (for some set of data.)
annotations["federation.kubernetes.io/replica-set-preferences"] = preferences {
input.kind = "ReplicaSet"
value = {"clusters": cluster_map, "rebalance": true}
json.marshal(value, preferences)
}
# This "annotations" rule generates a value for the "federation.alpha.kubernetes.io/cluster-selector"
# annotation.
#
# In English, the policy asserts that resources in the "production" namespace
# that are not annotated with "criticality=low" MUST be placed on clusters
# labelled with "on-premises=true".
annotations["federation.alpha.kubernetes.io/cluster-selector"] = selector {
input.metadata.namespace = "production"
not input.metadata.annotations.criticality = "low"
json.marshal([{
"operator": "=",
"key": "on-premises",
"values": "[true]",
}], selector)
}
# Generates a set of cluster names that satisfy the incoming Federated
# ReplicaSet's requirements. In this case, just PCI compliance.
replica_set_clusters[cluster_name] {
clusters[cluster_name]
not insufficient_pci[cluster_name]
}
# Generates a set of clusters that must not be used for Federated ReplicaSets
# that request PCI compliance.
insufficient_pci[cluster_name] {
clusters[cluster_name]
input.metadata.annotations["requires-pci"] = "true"
not pci_clusters[cluster_name]
}
# Generates a set of clusters that are PCI certified. In this case, we assume
# clusters are annotated to indicate if they have passed PCI compliance audits.
pci_clusters[cluster_name] {
clusters[cluster_name].metadata.annotations["pci-certified"] = "true"
}
# Helper rule to generate a mapping of desired clusters to weights. In this
# case, weights are static.
cluster_map[cluster_name] = {"weight": 1} {
replica_set_clusters[cluster_name]
}
content/en/docs/tasks/federation/set-up-placement-policies-federation.md
+76 -1
View File
@@ -108,7 +108,82 @@ Create the namespace if it does not already exist:
Configure a sample policy to test the external policy engine:
{{< code file="policy.rego" >}}
```
# OPA supports a high-level declarative language named Rego for authoring and
# enforcing policies. For more information on Rego, visit
# http://openpolicyagent.org.
# Rego policies are namespaced by the "package" directive.
package kubernetes.placement
# Imports provide aliases for data inside the policy engine. In this case, the
# policy simply refers to "clusters" below.
import data.kubernetes.clusters
# The "annotations" rule generates a JSON object containing the key
# "federation.kubernetes.io/replica-set-preferences" mapped to <preferences>.
# The preferences values is generated dynamically by OPA when it evaluates the
# rule.
#
# The SchedulingPolicy Admission Controller running inside the Federation API
# server will merge these annotations into incoming Federated resources. By
# setting replica-set-preferences, we can control the placement of Federated
# ReplicaSets.
#
# Rules are defined to generate JSON values (booleans, strings, objects, etc.)
# When OPA evaluates a rule, it generates a value IF all of the expressions in
# the body evaluate successfully. All rules can be understood intuitively as
# <head> if <body> where <body> is true if <expr-1> AND <expr-2> AND ...
# <expr-N> is true (for some set of data.)
annotations["federation.kubernetes.io/replica-set-preferences"] = preferences {
input.kind = "ReplicaSet"
value = {"clusters": cluster_map, "rebalance": true}
json.marshal(value, preferences)
}
# This "annotations" rule generates a value for the "federation.alpha.kubernetes.io/cluster-selector"
# annotation.
#
# In English, the policy asserts that resources in the "production" namespace
# that are not annotated with "criticality=low" MUST be placed on clusters
# labelled with "on-premises=true".
annotations["federation.alpha.kubernetes.io/cluster-selector"] = selector {
input.metadata.namespace = "production"
not input.metadata.annotations.criticality = "low"
json.marshal([{
"operator": "=",
"key": "on-premises",
"values": "[true]",
}], selector)
}
# Generates a set of cluster names that satisfy the incoming Federated
# ReplicaSet's requirements. In this case, just PCI compliance.
replica_set_clusters[cluster_name] {
clusters[cluster_name]
not insufficient_pci[cluster_name]
}
# Generates a set of clusters that must not be used for Federated ReplicaSets
# that request PCI compliance.
insufficient_pci[cluster_name] {
clusters[cluster_name]
input.metadata.annotations["requires-pci"] = "true"
not pci_clusters[cluster_name]
}
# Generates a set of clusters that are PCI certified. In this case, we assume
# clusters are annotated to indicate if they have passed PCI compliance audits.
pci_clusters[cluster_name] {
clusters[cluster_name].metadata.annotations["pci-certified"] = "true"
}
# Helper rule to generate a mapping of desired clusters to weights. In this
# case, weights are static.
cluster_map[cluster_name] = {"weight": 1} {
replica_set_clusters[cluster_name]
}
```
Shown below is the command to create the sample policy:
content/en/docs/tasks/run-application/run-replicated-stateful-application.md
+3 -2
View File
@@ -18,9 +18,10 @@ This page shows how to run a replicated stateful application using a
The example is a MySQL single-master topology with multiple slaves running
asynchronous replication.
Note that **this is not a production configuration**.
In particular, MySQL settings remain on insecure defaults to keep the focus
{{ < note > }}
**This is not a production configuration**. MySQL settings remain on insecure defaults to keep the focus
on general patterns for running stateful applications in Kubernetes.
{{ < /note > }}
{{% /capture %}}
content/en/docs/tasks/run-application/run-single-instance-stateful-application.md
+1 -1
View File
@@ -187,7 +187,7 @@ underlying resource upon deleting the PersistentVolume.
* Learn more about [Deployment objects](/docs/concepts/workloads/controllers/deployment/).
* Learn more about [Deploying applications](/docs/user-guide/deploying-applications/)
* Learn more about [Deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/)
* [kubectl run documentation](/docs/reference/generated/kubectl/kubectl-commands/#run)
content/en/docs/tasks/tools/install-minikube.md
+11 -3
View File
@@ -74,9 +74,17 @@ If you do not already have a hypervisor installed, install one of these now:
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
{{< note >}}
Minikube also supports a `--vm-driver=none` option that runs the Kubernetes components on the host and not in a VM. Using this driver requires [Docker](https://www.docker.com/products/docker-desktop) and a Linux environment but not a hypervisor. It is recommended to use the apt installation of docker from [Docker](https://www.docker.com/products/docker-desktop), when using the none driver. The snap installation of docker does not work with minikube.
{{< /note >}}
Minikube also supports a `--vm-driver=none` option that runs the Kubernetes components on the host and not in a VM.
Using this driver requires [Docker](https://www.docker.com/products/docker-desktop) and a Linux environment but not a hypervisor.
If you're using the `none` driver in Debian or a derivative, use the `.deb` packages for
Docker rather than the snap package, which does not work with Minikube.
You can download `.deb` packages from [Docker](https://www.docker.com/products/docker-desktop).
{{< caution >}}
The `none` VM driver can result in security and data loss issues.
Before using `--vm-driver=none`, consult [this documentation](https://minikube.sigs.k8s.io/docs/reference/drivers/none/) for more information.
{{< /caution >}}
### Install Minikube using a package