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

Merge remote-tracking branch 'upstream/master' into merged-master-dev-1.16

Browse Source
This commit is contained in:
simplytunde
2019-08-23 12:43:41 -05:00
parent 0125d9477c 92e439e124
commit 6c66ccd456
94 changed files with 3831 additions and 292 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/architecture/master-node-communication.md
+1 -1
View File
@@ -3,7 +3,7 @@ reviewers:
- dchen1107
- roberthbailey
- liggitt
title: Master-Node communication
title: Master-Node Communication
content_template: templates/concept
weight: 20
---
content/en/docs/concepts/architecture/nodes.md
+1 -1
View File
@@ -176,7 +176,7 @@ checks the state of each node every `--node-monitor-period` seconds.
In versions of Kubernetes prior to 1.13, NodeStatus is the heartbeat from the
node. Starting from Kubernetes 1.13, node lease feature is introduced as an
alpha feature (feature gate `NodeLease`,
[KEP-0009](https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)).
[KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md)).
When node lease feature is enabled, each node has an associated `Lease` object in
`kube-node-lease` namespace that is renewed by the node periodically, and both
NodeStatus and node lease are treated as heartbeats from the node. Node leases
content/en/docs/concepts/security/overview.md
+2 -2
View File
@@ -75,9 +75,9 @@ consult your documentation for security best practices.
Area of Concern for Kubernetes Infrastructure | Recommendation |
--------------------------------------------- | ------------ |
Network access to API Server (Masters) | Ideally all access to the Kubernetes Masters is not allowed publicly on the internet and is controlled by network access control lists restricted to the set of IP addresses needed to administer the cluster.|
Network access to Nodes (Worker Servers) | Nodes should be configured to _only_ accept connections (via network access control lists) from the masters on the specified ports, and accept connections for services in Kubernetes of type NodePort and LoadBalancer. If possible, this nodes should not exposed on the public internet entirely.
Network access to Nodes (Worker Servers) | Nodes should be configured to _only_ accept connections (via network access control lists) from the masters on the specified ports, and accept connections for services in Kubernetes of type NodePort and LoadBalancer. If possible, these nodes should not be exposed on the public internet entirely.
Kubernetes access to Cloud Provider API | Each cloud provider will need to grant a different set of permissions to the Kubernetes Masters and Nodes, so this recommendation will be more generic. It is best to provide the cluster with cloud provider access that follows the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) for the resources it needs to administer. An example for Kops in AWS can be found here: https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles
Access to etcd | Access to etcd (the datastore of Kubernetes) should be limited to the masters only. Depending on your configuration you should also attempt to use etcd over TLS. More info can be found here: https://github.com/etcd-io/etcd/tree/master/Documentation#security
Access to etcd | Access to etcd (the datastore of Kubernetes) should be limited to the masters only. Depending on your configuration, you should also attempt to use etcd over TLS. More info can be found here: https://github.com/etcd-io/etcd/tree/master/Documentation#security
etcd Encryption | Wherever possible it's a good practice to encrypt all drives at rest, but since etcd holds the state of the entire cluster (including Secrets) its disk should especially be encrypted at rest.
## Cluster
content/en/docs/concepts/services-networking/ingress.md
+1 -1
View File
@@ -15,7 +15,7 @@ weight: 40
## Terminology
For the sake of clarity, this guide defines the following terms:
For clarity, this guide defines the following terms:
Node
: A worker machine in Kubernetes, part of a cluster.
content/en/docs/concepts/services-networking/service.md
+3 -3
View File
@@ -356,7 +356,7 @@ that are configured for a specific IP address and difficult to re-configure.
The IP address that you choose must be a valid IPv4 or IPv6 address from within the
`service-cluster-ip-range` CIDR range that is configured for the API server.
If you try to create a Service with an invalid clusterIP address value, the API
server will returns a 422 HTTP status code to indicate that there's a problem.
server will return a 422 HTTP status code to indicate that there's a problem.
## Discovering services
@@ -598,7 +598,7 @@ For more information, see the [docs](https://cloud.google.com/kubernetes-engine/
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0
service.beta.kubernetes.io/aws-load-balancer-internal: "true"
[...]
```
{{% /tab %}}
@@ -685,7 +685,7 @@ In the above example, if the Service contained three ports, `80`, `443`, and
`8443`, then `443` and `8443` would use the SSL certificate, but `80` would just
be proxied HTTP.
From Kubernetes v1.9 onwrds you can use [predefined AWS SSL policies](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html) with HTTPS or SSL listeners for your Services.
From Kubernetes v1.9 onwards you can use [predefined AWS SSL policies](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html) with HTTPS or SSL listeners for your Services.
To see which policies are available for use, you can use the `aws` command line tool:
```bash
content/en/docs/concepts/storage/storage-classes.md
+17 -4
View File
@@ -522,11 +522,12 @@ parameters:
Default is "default".
* `adminSecretName`: secret that holds information about the Quobyte user and
the password to authenticate against the API server. The provided secret
must have type "kubernetes.io/quobyte", e.g. created in this way:
must have type "kubernetes.io/quobyte" and the keys `user` and `password`,
e.g. created in this way:
```shell
kubectl create secret generic quobyte-admin-secret \
--type="kubernetes.io/quobyte" --from-literal=key='opensesame' \
--type="kubernetes.io/quobyte" --from-literal=user='admin' --from-literal=password='opensesame' \
--namespace=kube-system
```
@@ -610,13 +611,25 @@ parameters:
group are searched to find one that matches `skuName` and `location`. If a
storage account is provided, it must reside in the same resource group as the
cluster, and `skuName` and `location` are ignored.
* `secretNamespace`: the namespace of the secret that contains the Azure Storage
Account Name and Key. Default is the same as the Pod.
* `secretName`: the name of the secret that contains the Azure Storage Account Name and
Key. Default is `azure-storage-account-<accountName>-secret`
* `readOnly`: a flag indicating whether the storage will be mounted as read only.
Defaults to false which means a read/write mount. This setting will impact the
`ReadOnly` setting in VolumeMounts as well.
During provision, a secret is created for mounting credentials. If the cluster
has enabled both [RBAC](/docs/reference/access-authn-authz/rbac/) and
During storage provisioning, a secret named by `secretName` is created for the
mounting credentials. If the cluster has enabled both
[RBAC](/docs/reference/access-authn-authz/rbac/) and
[Controller Roles](/docs/reference/access-authn-authz/rbac/#controller-roles),
add the `create` permission of resource `secret` for clusterrole
`system:controller:persistent-volume-binder`.
In a multi-tenancy context, it is strongly recommended to set the value for
`secretNamespace` explicitly, otherwise the storage account credentials may
be read by other users.
### Portworx Volume
```yaml
content/en/docs/contribute/advanced.md
+1 -1
View File
@@ -177,7 +177,7 @@ SIG Docs [approvers](/docs/contribute/participating/#approvers) can serve a term
Approvers must meet the following requirements to be a co-chair:
- Have been a SIG Docs approver for at least 6 months
- Have [led a Kubernetes docs release][coordinate-docs-for-a-kubernetes-release] or shadowed two releases
- Have [led a Kubernetes docs release](/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release) or shadowed two releases
- Understand SIG Docs workflows and tooling: git, Hugo, localization, blog subproject
- Understand how other Kubernetes SIGs and repositories affect the SIG Docs workflow, including: [teams in k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), [process in k/community](https://github.com/kubernetes/community/tree/master/sig-docs), plugins in [k/test-infra](https://github.com/kubernetes/test-infra/), and the role of [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture).
- Commit at least 5 hours per week (and often more) to the role for a minimum of 6 months
content/en/docs/contribute/start.md
+8 -1
View File
@@ -261,11 +261,18 @@ pull request if it detects that you pushed a new branch to your fork.
link for the `deploy/netlify` test, near the bottom of the page. It opens in
the same browser window by default.
{{< note >}}
Please limit pull requests to one language per PR. For example, if you need to make an identical change to the same code sample in multiple languages, open a separate PR for each language.
{{< /note >}}
6. Wait for review. Generally, reviewers are suggested by the `k8s-ci-robot`.
If a reviewer asks you to make changes, you can go to the **Files changed**
tab and click the pencil icon on any files that have been changed by the
pull request. When you save the changed file, a new commit is created in
the branch being monitored by the pull request.
the branch being monitored by the pull request. If you are waiting on a
reviewer to review the changes, proactively reach out to the reviewer
once every 7 days. You can also drop into #sig-docs Slack channel,
which is a good place to ask for help regarding PR reviews.
7. If your change is accepted, a reviewer merges your pull request, and the
change is live on the Kubernetes website a few minutes later.
content/en/docs/reference/access-authn-authz/webhook.md
+24 -1
View File
@@ -108,7 +108,13 @@ the request and respond to either allow or disallow access. The response body's
}
```
To disallow access, the remote service would return:
For disallowing access there are two methods.
The first method is preferred in most cases, and indicates the authorization
webhook does not allow, or has "no opinion" about the request, but if other
authorizers are configured, they are given a chance to allow the request.
If there are no other authorizers, or none of them allow the request, the
request is forbidden. The webhook would return:
```json
{
@@ -121,6 +127,23 @@ To disallow access, the remote service would return:
}
```
The second method denies immediately, short-circuiting evaluation by other
configured authorizers. This should only be used by webhooks that have
detailed knowledge of the full authorizer configuration of the cluster.
The webhook would return:
```json
{
"apiVersion": "authorization.k8s.io/v1beta1",
"kind": "SubjectAccessReview",
"status": {
"allowed": false,
"denied": true,
"reason": "user does not have read access to the namespace"
}
}
```
Access to non-resource paths are sent as:
```json
content/en/docs/reference/glossary/qos-class.md
+1 -1
View File
@@ -15,7 +15,7 @@ related:
- pod
---
QoS Class (Quality of Service Class)) provides a way for Kubernetes to classify Pods within the cluster into several classes and make decisions about scheduling and eviction.
QoS Class (Quality of Service Class) provides a way for Kubernetes to classify Pods within the cluster into several classes and make decisions about scheduling and eviction.
<!--more-->
QoS Class of a Pod is set at creation time based on its compute resources requests and limits settings. QoS classes are used to make decisions about Pods scheduling and eviction.
content/en/docs/reference/kubectl/cheatsheet.md
+3
View File
@@ -205,9 +205,12 @@ As of version 1.11 `rolling-update` have been deprecated (see [CHANGELOG-1.11.md
```bash
kubectl set image deployment/frontend www=image:v2 # Rolling update "www" containers of "frontend" deployment, updating the image
kubectl rollout history deployment/frontend # Check the history of deployments including the revision
kubectl rollout undo deployment/frontend # Rollback to the previous deployment
kubectl rollout undo deployment/frontend --to-revision=2 # Rollback to a specific revision
kubectl rollout status -w deployment/frontend # Watch rolling update status of "frontend" deployment until completion
# deprecated starting version 1.11
kubectl rolling-update frontend-v1 -f frontend-v2.json # (deprecated) Rolling update pods of frontend-v1
kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2 # (deprecated) Change the name of the resource and update the image
content/en/docs/reference/using-api/api-concepts.md
+23
View File
@@ -452,3 +452,26 @@ Another difference is that an applier using Client Side Apply is unable to chang
### Custom Resources
Server Side Apply currently treats all custom resources as unstructured data. All keys are treated the same as struct fields, and all lists are considered atomic. In the future, it will use the validation field in Custom Resource Definitions to allow Custom Resource authors to define how to how to merge their own objects.
### Clearing ManagedFields
It is possible to strip all managedFields from an object by overwriting them using `MergePatch`, `StrategicMergePatch`, `JSONPatch` or `Update`, so every non-apply operation.
This can be done by overwriting the managedFields field with an empty entry. Two examples are:
```json
PATCH /api/v1/namespaces/default/configmaps/example-cm
Content-Type: application/merge-patch+json
Accept: application/json
Data: {"metadata":{"managedFields": [{}]}}
```
```json
PATCH /api/v1/namespaces/default/configmaps/example-cm
Content-Type: application/json-patch+json
Accept: application/json
Data: [{"op": "replace", "path": "/metadata/managedFields", "value": [{}]}]
```
This will overwrite the managedFields with a list containing a single empty entry that then results in the managedFields being stripped entirely from the object. Note that just setting the managedFields to an empty list will not reset the field. This is on purpose, so managedFields never get stripped by clients not aware of the field.
In cases where the reset operation is combined with changes to other fields than the managedFields, this will result in the managedFields being reset first and the other changes being processed afterwards. As a result the applier takes ownership of any fields updated in the same request.
content/en/docs/setup/learning-environment/minikube.md
+1 -11
View File
@@ -23,7 +23,7 @@ Minikube supports the following Kubernetes features:
* NodePorts
* ConfigMaps and Secrets
* Dashboards
* Container Runtime: Docker, [rkt](https://github.com/rkt/rkt), [CRI-O](https://github.com/kubernetes-incubator/cri-o), and [containerd](https://github.com/containerd/containerd)
* Container Runtime: Docker, [CRI-O](https://github.com/kubernetes-incubator/cri-o), and [containerd](https://github.com/containerd/containerd)
* Enabling CNI (Container Network Interface)
* Ingress
@@ -252,16 +252,6 @@ minikube start \
--bootstrapper=kubeadm
```
{{% /tab %}}
{{% tab name="rkt container engine" %}}
To use [rkt](https://github.com/rkt/rkt) as the container runtime run:
```shell
minikube start \
--network-plugin=cni \
--enable-default-cni \
--container-runtime=rkt
```
This will use an alternative minikube ISO image containing both rkt, and Docker, and enable CNI networking.
{{% /tab %}}
{{< /tabs >}}
#### Use local images by re-using the Docker daemon
content/en/docs/setup/production-environment/container-runtimes.md
+5
View File
@@ -215,6 +215,11 @@ Use the following commands to install Containerd on your system:
### Prerequisites
```shell
cat > /etc/modules-load.d/containerd.conf <<EOF
overlay
br_netfilter
EOF
modprobe overlay
modprobe br_netfilter
content/en/docs/setup/production-environment/windows/flannel-master-kubeclt-get-pods.png
BIN
View File
Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 109 KiB

content/en/docs/setup/production-environment/windows/flannel-master-kubectl-get-ds.png
BIN
View File
Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 25 KiB

content/en/docs/setup/production-environment/windows/user-guide-windows-nodes.md
+51 -9
View File
@@ -94,10 +94,9 @@ Once you have a Linux-based Kubernetes master node you are ready to choose a net
1. In the `net-conf.json` section of your `kube-flannel.yml`, double-check:
1. The cluster subnet (e.g. "10.244.0.0/16") is set as per your IP plan.
* VNI 4096 is set in the backend
* Port 4789 is set in the backend
2. In the `cni-conf.json` section of your `kube-flannel.yml`, change the network name to `vxlan0`.
* VNI 4096 is set in the backend
* Port 4789 is set in the backend
1. In the `cni-conf.json` section of your `kube-flannel.yml`, change the network name to `vxlan0`.
Your `cni-conf.json` should look as follows:
@@ -143,7 +142,18 @@ Once you have a Linux-based Kubernetes master node you are ready to choose a net
kubectl get pods --all-namespaces
```
![alt_text](../flannel-master-kubeclt-get-pods.png "flannel master kubectl get pods screen capture")
The output looks like as follows:
```
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system etcd-flannel-master 1/1 Running 0 1m
kube-system kube-apiserver-flannel-master 1/1 Running 0 1m
kube-system kube-controller-manager-flannel-master 1/1 Running 0 1m
kube-system kube-dns-86f4d74b45-hcx8x 3/3 Running 0 12m
kube-system kube-flannel-ds-54954 1/1 Running 0 1m
kube-system kube-proxy-Zjlxz 1/1 Running 0 1m
kube-system kube-scheduler-flannel-master 1/1 Running 0 1m
```
Verify that the Flannel DaemonSet has the NodeSelector applied.
@@ -151,13 +161,20 @@ Once you have a Linux-based Kubernetes master node you are ready to choose a net
kubectl get ds -n kube-system
```
![alt_text](../flannel-master-kubectl-get-ds.png "flannel master kubectl get ds screen capture")
The output looks like as follows. The NodeSelector `beta.kubernetes.io/os=linux` is applied.
```
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
kube-flannel-ds 2 2 2 2 2 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux 21d
kube-proxy 2 2 2 2 2 beta.kubernetes.io/os=linux 26d
```
#### Join Windows Worker
In this section we'll cover configuring a Windows node from scratch to join a cluster on-prem. If your cluster is on a cloud you'll likely want to follow the cloud specific guides in the next section.
#### Preparing a Windows Node
{{< note >}}
All code snippets in Windows sections are to be run in a PowerShell environment with elevated permissions (Admin).
{{< /note >}}
@@ -180,9 +197,28 @@ All code snippets in Windows sections are to be run in a PowerShell environment
[Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine)
```
If after reboot you see the following error, you need to restart the docker service manually
After reboot, you can verify that the docker service is ready with the command below.
![alt_text](../windows-docker-error.png "windows docker error screen capture")
```PowerShell
docker version
```
If you see error message like the following, you need to start the docker service manually.
```
Client:
Version: 17.06.2-ee-11
API version: 1.30
Go version: go1.8.7
Git commit: 06fc007
Built: Thu May 17 06:14:39 2018
OS/Arch: windows / amd64
error during connect: Get http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.30/version: open //./pipe/docker_engine: The system c
annot find the file specified. In the default daemon configuration on Windows, the docker client must be run elevated to
connect. This error may also indicate that the docker daemon is not running.
```
You can start the docker service manually like below.
```PowerShell
Start-Service docker
@@ -229,7 +265,13 @@ wget https://raw.githubusercontent.com/Microsoft/SDN/master/Kubernetes/flannel/s
{{< /note >}}
```PowerShell
.\start.ps1 -ManagementIP <Windows Node IP> -NetworkMode overlay -ClusterCIDR <Cluster CIDR> -ServiceCIDR <Service CIDR> -KubeDnsServiceIP <Kube-dns Service IP> -LogDir <Log directory>
cd c:\k
.\start.ps1 -ManagementIP <Windows Node IP> `
-NetworkMode overlay `
-ClusterCIDR <Cluster CIDR> `
-ServiceCIDR <Service CIDR> `
-KubeDnsServiceIP <Kube-dns Service IP> `
-LogDir <Log directory>
```
| Parameter | Default Value | Notes |
content/en/docs/setup/production-environment/windows/windows-docker-error.png
BIN
View File
Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 80 KiB

content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md
+49 -89
View File
@@ -9,6 +9,10 @@ weight: 80
This page shows how to create an External Load Balancer.
{{< note >}}
This feature is only available for cloud providers or environments which support external load balancers.
{{< /note >}}
When creating a service, you have the option of automatically creating a
cloud network load balancer. This provides an externally-accessible IP address
that sends traffic to the correct port on your cluster nodes
@@ -35,30 +39,24 @@ documentation.
To create an external load balancer, add the following line to your
[service configuration file](/docs/concepts/services-networking/service/#loadbalancer):
```json
"type": "LoadBalancer"
```yaml
type: LoadBalancer
```
Your configuration file might look like:
```json
{
"kind": "Service",
"apiVersion": "v1",
"metadata": {
"name": "example-service"
},
"spec": {
"ports": [{
"port": 8765,
"targetPort": 9376
}],
"selector": {
"app": "example"
},
"type": "LoadBalancer"
}
}
```yaml
apiVersion: v1
kind: Service
metadata:
name: example-service
spec:
selector:
app: example
ports:
- port: 8765
targetPort: 9376
type: LoadBalancer
```
## Using kubectl
@@ -118,82 +116,42 @@ minikube service example-service --url
## Preserving the client source IP
Due to the implementation of this feature, the source IP seen in the target
container will *not be the original source IP* of the client. To enable
container is *not the original source IP* of the client. To enable
preservation of the client IP, the following fields can be configured in the
service spec (supported in GCE/Google Kubernetes Engine environments):
* `service.spec.externalTrafficPolicy` - denotes if this Service desires to route
external traffic to node-local or cluster-wide endpoints. There are two available
options: "Cluster" (default) and "Local". "Cluster" obscures the client source
options: Cluster (default) and Local. Cluster obscures the client source
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
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 healthcheck 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
effect when type is set to "LoadBalancer" and externalTrafficPolicy is set
to "Local".
* `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
effect when `type` is set to LoadBalancer and `externalTrafficPolicy` is set
to Local.
This feature can be activated by setting `externalTrafficPolicy` to "Local" in the
Service Configuration file.
Setting `externalTrafficPolicy` to Local in the Service configuration file
activates this feature.
```json
{
"kind": "Service",
"apiVersion": "v1",
"metadata": {
"name": "example-service"
},
"spec": {
"ports": [{
"port": 8765,
"targetPort": 9376
}],
"selector": {
"app": "example"
},
"type": "LoadBalancer",
"externalTrafficPolicy": "Local"
}
}
```yaml
apiVersion: v1
kind: Service
metadata:
name: example-service
spec:
selector:
app: example
ports:
- port: 8765
targetPort: 9376
externalTrafficPolicy: Local
type: LoadBalancer
```
### Feature availability
| K8s version | Feature support |
| :---------: |:-----------:|
| 1.7+ | Supports the full API fields |
| 1.5 - 1.6 | Supports Beta Annotations |
| <1.5 | Unsupported |
Below you could find the deprecated Beta annotations used to enable this feature
prior to its stable version. Newer Kubernetes versions may stop supporting these
after v1.7. Please update existing applications to use the fields directly.
* `service.beta.kubernetes.io/external-traffic` annotation <-> `service.spec.externalTrafficPolicy` field
* `service.beta.kubernetes.io/healthcheck-nodeport` annotation <-> `service.spec.healthCheckNodePort` field
`service.beta.kubernetes.io/external-traffic` annotation has a different set of values
compared to the `service.spec.externalTrafficPolicy` field. The values match as follows:
* "OnlyLocal" for annotation <-> "Local" for field
* "Global" for annotation <-> "Cluster" for field
{{< note >}}
This feature is not currently implemented for all cloudproviders/environments.
{{< /note >}}
Known issues:
* AWS: [kubernetes/kubernetes#35758](https://github.com/kubernetes/kubernetes/issues/35758)
* Weave-Net: [weaveworks/weave/#2924](https://github.com/weaveworks/weave/issues/2924)
{{% /capture %}}
{{% capture discussion %}}
## Garbage Collecting Load Balancers
In usual case, the correlating load balancer resources in cloud provider should
@@ -203,7 +161,7 @@ associated Service is deleted. Finalizer Protection for Service LoadBalancers wa
introduced to prevent this from happening. By using finalizers, a Service resource
will never be deleted until the correlating load balancer resources are also deleted.
Specifically, if a Service has Type=LoadBalancer, the service controller will attach
Specifically, if a Service has `type` LoadBalancer, the service controller will attach
a finalizer named `service.kubernetes.io/load-balancer-cleanup`.
The finalizer will only be removed after the load balancer resource is cleaned up.
This prevents dangling load balancer resources even in corner cases such as the
@@ -217,14 +175,18 @@ enabling the [feature gate](/docs/reference/command-line-tools-reference/feature
It is important to note that the datapath for this functionality is provided by a load balancer external to the Kubernetes cluster.
When the service type is set to `LoadBalancer`, Kubernetes provides functionality equivalent to `type=<ClusterIP>` to pods within the cluster and extends it by programming the (external to Kubernetes) load balancer with entries for the Kubernetes pods. The Kubernetes service controller automates the creation of the external load balancer, health checks (if needed), firewall rules (if needed) and retrieves the external IP allocated by the cloud provider and populates it in the service object.
When the Service `type` is set to LoadBalancer, Kubernetes provides functionality equivalent to `type` equals ClusterIP to pods
within the cluster and extends it by programming the (external to Kubernetes) load balancer with entries for the Kubernetes
pods. The Kubernetes service controller automates the creation of the external load balancer, health checks (if needed),
firewall rules (if needed) and retrieves the external IP allocated by the cloud provider and populates it in the service
object.
## Caveats and Limitations when preserving source IPs
GCE/AWS load balancers do not provide weights for their target pools. This was not an issue with the old LB
kube-proxy rules which would correctly balance across all endpoints.
With the new functionality, the external traffic will not be equally load balanced across pods, but rather
With the new functionality, the external traffic is not equally load balanced across pods, but rather
equally balanced at the node level (because GCE/AWS and other external LB implementations do not have the ability
for specifying the weight per node, they balance equally across all target nodes, disregarding the number of
pods on each node).
@@ -238,5 +200,3 @@ Once the external load balancers provide weights, this functionality can be adde
Internal pod to pod traffic should behave similar to ClusterIP services, with equal probability across all pods.
{{% /capture %}}
content/en/docs/tasks/access-application-cluster/ingress-minikube.md
+2 -2
View File
@@ -140,13 +140,13 @@ The following file is an Ingress resource that sends traffic to your Service via
metadata:
name: example-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
rules:
- host: hello-world.info
http:
paths:
- path: /*
- path: /(.+)
backend:
serviceName: web
servicePort: 8080
content/en/docs/tasks/configure-pod-container/configure-volume-storage.md
+1 -1
View File
@@ -113,7 +113,7 @@ of `Always`.
kubectl exec -it redis -- /bin/bash
```
1. In your shell, goto `/data/redis`, and verify that `test-file` is still there.
1. In your shell, go to `/data/redis`, and verify that `test-file` is still there.
```shell
root@redis:/data/redis# cd /data/redis/
root@redis:/data/redis# ls
content/en/docs/tasks/debug-application-cluster/audit.md
+7 -12
View File
@@ -262,7 +262,7 @@ and can optionally include a custom CA bundle to use to verify the TLS connectio
The `host` should not refer to a service running in the cluster; use
a service reference by specifying the `service` field instead.
The host might be resolved via external DNS in some apiservers
(i.e., `kube-apiserver` cannot resolve in-cluster DNS as that would
(i.e., `kube-apiserver` cannot resolve in-cluster DNS as that would
be a layering violation). `host` may also be an IP address.
Please note that using `localhost` or `127.0.0.1` as a `host` is
@@ -489,16 +489,11 @@ Note that in addition to file output plugin, logstash has a variety of outputs t
let users route data where they want. For example, users can emit audit events to elasticsearch
plugin which supports full-text search and analytics.
[kube-apiserver]: /docs/admin/kube-apiserver
[auditing-proposal]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/auditing.md
[auditing-api]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go
[gce-audit-profile]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh#L735
[kubeconfig]: /docs/tasks/access-application-cluster/configure-access-multiple-clusters/
[fluentd]: http://www.fluentd.org/
[fluentd_install_doc]: https://docs.fluentd.org/v1.0/articles/quickstart#step-1:-installing-fluentd
[fluentd_plugin_management_doc]: https://docs.fluentd.org/v1.0/articles/plugin-management
[logstash]: https://www.elastic.co/products/logstash
[logstash_install_doc]: https://www.elastic.co/guide/en/logstash/current/installing-logstash.html
[kube-aggregator]: /docs/concepts/api-extension/apiserver-aggregation
{{% /capture %}}
{{% capture whatsnext %}}
Visit [Auditing with Falco](/docs/tasks/debug-application-cluster/falco)
{{% /capture %}}
content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
+1 -1
View File
@@ -63,7 +63,7 @@ case you can try several things:
information:
```shell
kubectl get nodes -o yaml | egrep '\sname:\|cpu:\|memory:'
kubectl get nodes -o yaml | egrep '\sname:|cpu:|memory:'
kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, cap: .status.capacity}'
```
content/en/docs/tasks/debug-application-cluster/falco.md
+121
View File
@@ -0,0 +1,121 @@
---
reviewers:
- soltysh
- sttts
- ericchiang
content_template: templates/concept
title: Auditing with Falco
---
{{% capture overview %}}
### Use Falco to collect audit events
[Falco](https://falco.org/) is an open source project for intrusion and abnormality detection for Cloud Native platforms.
This section describes how to set up Falco, how to send audit events to the Kubernetes Audit endpoint exposed by Falco, and how Falco applies a set of rules to automatically detect suspicious behavior.
{{% /capture %}}
{{% capture body %}}
#### Install Falco
Install Falco by using one of the following methods:
- [Standalone Falco][falco_installation]
- [Kubernetes DaemonSet][falco_installation]
- [Falco Helm Chart][falco_helm_chart]
Once Falco is installed make sure it is configured to expose the Audit webhook. To do so, use the following configuration:
```yaml
webserver:
enabled: true
listen_port: 8765
k8s_audit_endpoint: /k8s_audit
ssl_enabled: false
ssl_certificate: /etc/falco/falco.pem
```
This configuration is typically found in the `/etc/falco/falco.yaml` file. If Falco is installed as a Kubernetes DaemonSet, edit the `falco-config` ConfigMap and add this configuration.
#### Configure Kubernetes Audit
1. Create a [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) for the [kube-apiserver][kube-apiserver] webhook audit backend.
cat <<EOF > /etc/kubernetes/audit-webhook-kubeconfig
apiVersion: v1
kind: Config
clusters:
- cluster:
server: http://<ip_of_falco>:8765/k8s_audit
name: falco
contexts:
- context:
cluster: falco
user: ""
name: default-context
current-context: default-context
preferences: {}
users: []
EOF
1. Start [kube-apiserver][kube-apiserver] with the following options:
```shell
--audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig
```
#### Audit Rules
Rules devoted to Kubernetes Audit Events can be found in [k8s_audit_rules.yaml][falco_k8s_audit_rules]. If Audit Rules is installed as a native package or using the official Docker images, Falco copies the rules file to `/etc/falco/`, so they are available for use.
There are three classes of rules.
The first class of rules looks for suspicious or exceptional activities, such as:
- Any activity by an unauthorized or anonymous user.
- Creating a pod with an unknown or disallowed image.
- Creating a privileged pod, a pod mounting a sensitive filesystem from the host, or a pod using host networking.
- Creating a NodePort service.
- Creating a ConfigMap containing private credentials, such as passwords and cloud provider secrets.
- Attaching to or executing a command on a running pod.
- Creating a namespace external to a set of allowed namespaces.
- Creating a pod or service account in the kube-system or kube-public namespaces.
- Trying to modify or delete a system ClusterRole.
- Creating a ClusterRoleBinding to the cluster-admin role.
- Creating a ClusterRole with wildcarded verbs or resources. For example, overly permissive.
- Creating a ClusterRole with write permissions or a ClusterRole that can execute commands on pods.
A second class of rules tracks resources being created or destroyed, including:
- Deployments
- Services
- ConfigMaps
- Namespaces
- Service accounts
- Role/ClusterRoles
- Role/ClusterRoleBindings
The final class of rules simply displays any Audit Event received by Falco. This rule is disabled by default, as it can be quite noisy.
For further details, see [Kubernetes Audit Events][falco_ka_docs] in the Falco documentation.
[kube-apiserver]: /docs/admin/kube-apiserver
[auditing-proposal]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/auditing.md
[auditing-api]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go
[gce-audit-profile]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh#L735
[kubeconfig]: /docs/tasks/access-application-cluster/configure-access-multiple-clusters/
[fluentd]: http://www.fluentd.org/
[fluentd_install_doc]: https://docs.fluentd.org/v1.0/articles/quickstart#step-1:-installing-fluentd
[fluentd_plugin_management_doc]: https://docs.fluentd.org/v1.0/articles/plugin-management
[logstash]: https://www.elastic.co/products/logstash
[logstash_install_doc]: https://www.elastic.co/guide/en/logstash/current/installing-logstash.html
[kube-aggregator]: /docs/concepts/api-extension/apiserver-aggregation
[falco_website]: https://www.falco.org
[falco_k8s_audit_rules]: https://github.com/falcosecurity/falco/blob/master/rules/k8s_audit_rules.yaml
[falco_ka_docs]: https://falco.org/docs/event-sources/kubernetes-audit
[falco_installation]: https://falco.org/docs/installation
[falco_helm_chart]: https://github.com/helm/charts/tree/master/stable/falco
{{% /capture %}}
content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
+27 -87
View File
@@ -20,99 +20,39 @@ where bottlenecks can be removed to improve overall performance.
{{% capture body %}}
In Kubernetes, application monitoring does not depend on a single monitoring
solution. On new clusters, you can use two separate pipelines to collect
monitoring statistics by default:
- The [**resource metrics pipeline**](#resource-metrics-pipeline) provides a limited set of metrics related
to cluster components such as the HorizontalPodAutoscaler controller, as well
as the `kubectl top` utility. These metrics are collected by
[metrics-server](https://github.com/kubernetes-incubator/metrics-server)
and are exposed via the `metrics.k8s.io` API. `metrics-server` discovers
all nodes on the cluster and queries each node's [Kubelet](/docs/admin/kubelet)
for CPU and memory usage. The Kubelet fetches the data from
[cAdvisor](https://github.com/google/cadvisor). `metrics-server` is a
lightweight short-term in-memory store.
- A [**full metrics pipeline**](#full-metrics-pipelines), such as Prometheus, gives you access to richer
metrics. In addition, Kubernetes can respond to these metrics by automatically
scaling or adapting the cluster based on its current state, using mechanisms
such as the Horizontal Pod Autoscaler. The monitoring pipeline fetches
metrics from the Kubelet, and then exposes them to Kubernetes via an adapter
by implementing either the `custom.metrics.k8s.io` or
`external.metrics.k8s.io` API.
In Kubernetes, application monitoring does not depend on a single monitoring solution. On new clusters, you can use [resource metrics](#resource-metrics-pipeline) or [full metrics](#full-metrics-pipeline) pipelines to collect monitoring statistics.
## Resource metrics pipeline
### Kubelet
The resource metrics pipeline provides a limited set of metrics related to
cluster components such as the [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale) controller, as well as the `kubectl top` utility.
These metrics are collected by the lightweight, short-term, in-memory
[metrics-server](https://github.com/kubernetes-incubator/metrics-server) and
are exposed via the `metrics.k8s.io` API.
The Kubelet acts as a bridge between the Kubernetes master and the nodes. It manages the pods and containers running on a machine. Kubelet translates each pod into its constituent containers and fetches individual container usage statistics from the container runtime, through the container runtime interface. For the legacy docker integration, it fetches this information from cAdvisor. It then exposes the aggregated pod resource usage statistics through the kubelet resource metrics api. This api is served at `/metrics/resource/v1alpha1` on the kubelet's authenticated and read-only ports.
metrics-server discovers all nodes on the cluster and
queries each node's
[kubelet](/docs/reference/command-line-tools-reference/kubelet) for CPU and
memory usage. The kubelet acts as a bridge between the Kubernetes master and
the nodes, managing the pods and containers running on a machine. The kubelet
translates each pod into its constituent containers and fetches individual
container usage statistics from the container runtime through the container
runtime interface. The kubelet fetches this information from the integrated
cAdvisor for the legacy Docker integration. It then exposes the aggregated pod
resource usage statistics through the metrics-server Resource Metrics API.
This API is served at `/metrics/resource/v1beta1` on the kubelet's authenticated and
read-only ports.
### cAdvisor
## Full metrics pipeline
cAdvisor is an open source container resource usage and performance analysis agent. It is purpose-built for containers and supports Docker containers natively. In Kubernetes, cAdvisor is integrated into the Kubelet binary. cAdvisor auto-discovers all containers in the machine and collects CPU, memory, filesystem, and network usage statistics. cAdvisor also provides the overall machine usage by analyzing the 'root' container on the machine.
A full metrics pipeline gives you access to richer metrics. Kubernetes can
respond to these metrics by automatically scaling or adapting the cluster
based on its current state, using mechanisms such as the Horizontal Pod
Autoscaler. The monitoring pipeline fetches metrics from the kubelet and
then exposes them to Kubernetes via an adapter by implementing either the
`custom.metrics.k8s.io` or `external.metrics.k8s.io` API.
Kubelet exposes a simple cAdvisor UI for containers on a machine, via the default port 4194.
The picture below is an example showing the overall machine usage. However, this feature has been marked
deprecated in v1.10 and completely removed in v1.12.
![cAdvisor](/images/docs/cadvisor.png)
Starting from v1.13, you can [deploy cAdvisor as a DaemonSet](https://github.com/google/cadvisor/tree/master/deploy/kubernetes) for an access to the cAdvisor UI.
## Full metrics pipelines
Many full metrics solutions exist for Kubernetes.
### Prometheus
[Prometheus](https://prometheus.io) can natively monitor kubernetes, nodes, and prometheus itself.
The [Prometheus Operator](https://coreos.com/operators/prometheus/docs/latest/)
simplifies Prometheus setup on Kubernetes, and allows you to serve the
custom metrics API using the
[Prometheus adapter](https://github.com/directxman12/k8s-prometheus-adapter).
Prometheus provides a robust query language and a built-in dashboard for
querying and visualizing your data. Prometheus is also a supported
data source for [Grafana](https://prometheus.io/docs/visualization/grafana/).
### Sysdig
[Sysdig](http://sysdig.com) provides full spectrum container and platform intelligence, and is a
true container native solution. Sysdig pulls together data from system calls, Kubernetes events,
Prometheus metrics, statsD, JMX, and more into a single pane that gives you a comprehensive picture
of your environment. Sysdig also provides an API to query for providing robust and customizable
solutions. Sysdig is built on Open Source. [Sysdig and Sysdig Inspect](https://sysdig.com/opensource/inspect/) give you the
ability to freely perform troubleshooting, performance analyis and forensics.
### Google Cloud Monitoring
Google Cloud Monitoring is a hosted monitoring service you can use to
visualize and alert on important metrics in your application. You can collect
metrics from Kubernetes, and you can access them
using the [Cloud Monitoring Console](https://app.google.stackdriver.com/).
You can create and customize dashboards to visualize the data gathered
from your Kubernetes cluster.
This video shows how to configure and run a Google Cloud Monitoring backed Heapster:
[![how to setup and run a Google Cloud Monitoring backed Heapster](https://img.youtube.com/vi/xSMNR2fcoLs/0.jpg)](https://www.youtube.com/watch?v=xSMNR2fcoLs)
{{< figure src="/images/docs/gcm.png" alt="Google Cloud Monitoring dashboard example" title="Google Cloud Monitoring dashboard example" caption="This dashboard shows cluster-wide resource usage." >}}
## CronJob monitoring
### Kubernetes Job Monitor
With the [Kubernetes Job Monitor](https://github.com/pietervogelaar/kubernetes-job-monitor) dashboard a Cluster Administrator can see which jobs are running and view the status of completed jobs.
### New Relic Kubernetes monitoring integration
[New Relic Kubernetes](https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/kubernetes-monitoring-integration) integration provides increased visibility into the performance of your Kubernetes environment. New Relic's Kubernetes integration instruments the container orchestration layer by reporting metrics from Kubernetes objects. The integration gives you insight into your Kubernetes nodes, namespaces, deployments, replica sets, pods, and containers.
Marquee capabilities:
View your data in pre-built dashboards for immediate insight into your Kubernetes environment.
Create your own custom queries and charts in Insights from automatically reported data.
Create alert conditions on Kubernetes data.
Learn more on this [page](https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/kubernetes-monitoring-integration).
[Prometheus](https://prometheus.io), a CNCF project, can natively monitor Kubernetes, nodes, and Prometheus itself.
Full metrics pipeline projects that are not part of the CNCF are outside the scope of Kubernetes documentation.
{{% /capture %}}
content/en/docs/tasks/extend-kubectl/kubectl-plugins.md
+2 -2
View File
@@ -150,7 +150,7 @@ Example:
```bash
# create a plugin
echo '#!/bin/bash\n\necho "My first command-line argument was $1"' > kubectl-foo-bar-baz
echo -e '#!/bin/bash\n\necho "My first command-line argument was $1"' > kubectl-foo-bar-baz
sudo chmod +x ./kubectl-foo-bar-baz
# "install" our plugin by placing it on our PATH
@@ -185,7 +185,7 @@ Example:
```bash
# create a plugin containing an underscore in its filename
echo '#!/bin/bash\n\necho "I am a plugin with a dash in my name"' > ./kubectl-foo_bar
echo -e '#!/bin/bash\n\necho "I am a plugin with a dash in my name"' > ./kubectl-foo_bar
sudo chmod +x ./kubectl-foo_bar
# move the plugin into your PATH
content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+1 -1
View File
@@ -287,7 +287,7 @@ For example, if you had your monitoring system collecting metrics about network
you could update the definition above using `kubectl edit` to look like this:
```yaml
apiVersion: autoscaling/v2beta1
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
content/en/docs/tasks/run-application/update-api-object-kubectl-patch.md
+1 -1
View File
@@ -311,7 +311,7 @@ The following commands are equivalent:
```shell
kubectl patch deployment patch-demo --patch "$(cat patch-file.yaml)"
kubectl patch deployment patch-demo --patch "$(cat patch-file.json)"
kubectl patch deployment patch-demo --patch 'spec:\n template:\n spec:\n containers:\n - name: patch-demo-ctr-2\n image: redis'
kubectl patch deployment patch-demo --patch "$(cat patch-file.json)"
content/en/docs/tasks/tls/managing-tls-in-a-cluster.md
+1 -1
View File
@@ -44,7 +44,7 @@ chain and adding the parsed certificates to the `RootCAs` field in the
[`tls.Config`](https://godoc.org/crypto/tls#Config) struct.
You can distribute the CA certificate as a
[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-config) that your
[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap) that your
pods have access to use.
## Requesting a Certificate
content/en/docs/tutorials/stateless-application/expose-external-ip-address.md
+2 -2
View File
@@ -146,12 +146,12 @@ The preceding command creates a
To delete the Service, enter this command:
kubectl delete services my-service
kubectl delete services my-service
To delete the Deployment, the ReplicaSet, and the Pods that are running
the Hello World application, enter this command:
kubectl delete deployment hello-world
kubectl delete deployment hello-world
{{% /capture %}}