Sync between master and dev-1.18
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
@@ -24,9 +24,9 @@ Once you've set your desired state, the *Kubernetes Control Plane* makes the clu
|
||||
* **[kubelet](/docs/admin/kubelet/)**, which communicates with the Kubernetes Master.
|
||||
* **[kube-proxy](/docs/admin/kube-proxy/)**, a network proxy which reflects Kubernetes networking services on each node.
|
||||
|
||||
## Kubernetes Objects
|
||||
## Kubernetes objects
|
||||
|
||||
Kubernetes contains a number of abstractions that represent the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API. See [Understanding Kubernetes Objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/) for more details.
|
||||
Kubernetes contains a number of abstractions that represent the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API. See [Understanding Kubernetes objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) for more details.
|
||||
|
||||
The basic Kubernetes objects include:
|
||||
|
||||
@@ -35,7 +35,7 @@ The basic Kubernetes objects include:
|
||||
* [Volume](/docs/concepts/storage/volumes/)
|
||||
* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/)
|
||||
|
||||
Kubernetes also contains higher-level abstractions that rely on [Controllers](/docs/concepts/architecture/controller/) to build upon the basic objects, and provide additional functionality and convenience features. These include:
|
||||
Kubernetes also contains higher-level abstractions that rely on [controllers](/docs/concepts/architecture/controller/) to build upon the basic objects, and provide additional functionality and convenience features. These include:
|
||||
|
||||
* [Deployment](/docs/concepts/workloads/controllers/deployment/)
|
||||
* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
|
||||
|
||||
@@ -26,7 +26,7 @@ closer to the desired state, by turning equipment on or off.
|
||||
## Controller pattern
|
||||
|
||||
A controller tracks at least one Kubernetes resource type.
|
||||
These [objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/)
|
||||
These [objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)
|
||||
have a spec field that represents the desired state. The
|
||||
controller(s) for that resource are responsible for making the current
|
||||
state come closer to that desired state.
|
||||
|
||||
@@ -37,7 +37,7 @@ On their own, custom resources simply let you store and retrieve structured data
|
||||
When you combine a custom resource with a *custom controller*, custom resources
|
||||
provide a true _declarative API_.
|
||||
|
||||
A [declarative API](/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects)
|
||||
A [declarative API](/docs/concepts/overview/kubernetes-api/)
|
||||
allows you to _declare_ or specify the desired state of your resource and tries to
|
||||
keep the current state of Kubernetes objects in sync with the desired state.
|
||||
The controller interprets the structured data as a record of the user's
|
||||
|
||||
@@ -12,9 +12,9 @@ This page explains how Kubernetes objects are represented in the Kubernetes API,
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
## Understanding Kubernetes Objects
|
||||
## Understanding Kubernetes objects {#kubernetes-objects}
|
||||
|
||||
*Kubernetes Objects* are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Specifically, they can describe:
|
||||
*Kubernetes objects* are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Specifically, they can describe:
|
||||
|
||||
* What containerized applications are running (and on which nodes)
|
||||
* The resources available to those applications
|
||||
@@ -33,7 +33,7 @@ For example, a Kubernetes Deployment is an object that can represent an applicat
|
||||
|
||||
For more information on the object spec, status, and metadata, see the [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md).
|
||||
|
||||
### Describing a Kubernetes Object
|
||||
### Describing a Kubernetes object
|
||||
|
||||
When you create an object in Kubernetes, you must provide the object spec that describes its desired state, as well as some basic information about the object (such as a name). When you use the Kubernetes API to create the object (either directly or via `kubectl`), that API request must include that information as JSON in the request body. **Most often, you provide the information to `kubectl` in a .yaml file.** `kubectl` converts the information to JSON when making the API request.
|
||||
|
||||
@@ -51,7 +51,7 @@ kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```shell
|
||||
```
|
||||
deployment.apps/nginx-deployment created
|
||||
```
|
||||
|
||||
@@ -65,14 +65,15 @@ In the `.yaml` file for the Kubernetes object you want to create, you'll need to
|
||||
* `spec` - What state you desire for the object
|
||||
|
||||
The precise format of the object `spec` is different for every Kubernetes object, and contains nested fields specific to that object. The [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) can help you find the spec format for all of the objects you can create using Kubernetes.
|
||||
For example, the `spec` format for a `Pod` can be found
|
||||
[here](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core),
|
||||
and the `spec` format for a `Deployment` can be found
|
||||
[here](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps).
|
||||
For example, the `spec` format for a Pod can be found in
|
||||
[PodSpec v1 core](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core),
|
||||
and the `spec` format for a Deployment can be found
|
||||
[DeploymentSpec v1 apps](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
* [Kubernetes API overview](/docs/reference/using-api/api-overview/) explains some more API concepts
|
||||
* Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/pod-overview/).
|
||||
* Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -72,7 +72,7 @@ spec:
|
||||
image: nginx:1.7.9
|
||||
ports:
|
||||
- containerPort: 80
|
||||
|
||||
|
||||
```
|
||||
|
||||
## Label selectors
|
||||
@@ -92,7 +92,7 @@ them.
|
||||
For some API types, such as ReplicaSets, the label selectors of two instances must not overlap within a namespace, or the controller can see that as conflicting instructions and fail to determine how many replicas should be present.
|
||||
{{< /note >}}
|
||||
|
||||
{{< caution >}}
|
||||
{{< caution >}}
|
||||
For both equality-based and set-based conditions there is no logical _OR_ (`||`) operator. Ensure your filter statements are structured accordingly.
|
||||
{{< /caution >}}
|
||||
|
||||
@@ -210,7 +210,7 @@ this selector (respectively in `json` or `yaml` format) is equivalent to `compon
|
||||
|
||||
#### Resources that support set-based requirements
|
||||
|
||||
Newer resources, such as [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/), [`Deployment`](/docs/concepts/workloads/controllers/deployment/), [`Replica Set`](/docs/concepts/workloads/controllers/replicaset/), and [`Daemon Set`](/docs/concepts/workloads/controllers/daemonset/), support _set-based_ requirements as well.
|
||||
Newer resources, such as [`Job`](/docs/concepts/workloads/controllers/jobs-run-to-completion/), [`Deployment`](/docs/concepts/workloads/controllers/deployment/), [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/), and [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/), support _set-based_ requirements as well.
|
||||
|
||||
```yaml
|
||||
selector:
|
||||
|
||||
@@ -38,14 +38,16 @@ For more up-to-date specification, see
|
||||
|
||||
## Services
|
||||
|
||||
### A records
|
||||
### A/AAAA records
|
||||
|
||||
"Normal" (not headless) Services are assigned a DNS A record for a name of the
|
||||
form `my-svc.my-namespace.svc.cluster-domain.example`. This resolves to the cluster IP
|
||||
"Normal" (not headless) Services are assigned a DNS A or AAAA record,
|
||||
depending on the IP family of the service, for a name of the form
|
||||
`my-svc.my-namespace.svc.cluster-domain.example`. This resolves to the cluster IP
|
||||
of the Service.
|
||||
|
||||
"Headless" (without a cluster IP) Services are also assigned a DNS A record for
|
||||
a name of the form `my-svc.my-namespace.svc.cluster-domain.example`. Unlike normal
|
||||
"Headless" (without a cluster IP) Services are also assigned a DNS A or AAAA record,
|
||||
depending on the IP family of the service, for a name of the form
|
||||
`my-svc.my-namespace.svc.cluster-domain.example`. Unlike normal
|
||||
Services, this resolves to the set of IPs of the pods selected by the Service.
|
||||
Clients are expected to consume the set or else use standard round-robin
|
||||
selection from the set.
|
||||
@@ -128,22 +130,22 @@ spec:
|
||||
```
|
||||
|
||||
If there exists a headless service in the same namespace as the pod and with
|
||||
the same name as the subdomain, the cluster's KubeDNS Server also returns an A
|
||||
the same name as the subdomain, the cluster's DNS Server also returns an A or AAAA
|
||||
record for the Pod's fully qualified hostname.
|
||||
For example, given a Pod with the hostname set to "`busybox-1`" and the subdomain set to
|
||||
"`default-subdomain`", and a headless Service named "`default-subdomain`" in
|
||||
the same namespace, the pod will see its own FQDN as
|
||||
"`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`". DNS serves an
|
||||
A record at that name, pointing to the Pod's IP. Both pods "`busybox1`" and
|
||||
"`busybox2`" can have their distinct A records.
|
||||
A or AAAA record at that name, pointing to the Pod's IP. Both pods "`busybox1`" and
|
||||
"`busybox2`" can have their distinct A or AAAA records.
|
||||
|
||||
The Endpoints object can specify the `hostname` for any endpoint addresses,
|
||||
along with its IP.
|
||||
|
||||
{{< note >}}
|
||||
Because A records are not created for Pod names, `hostname` is required for the Pod's A
|
||||
Because A or AAAA records are not created for Pod names, `hostname` is required for the Pod's A or AAAA
|
||||
record to be created. A Pod with no `hostname` but with `subdomain` will only create the
|
||||
A record for the headless service (`default-subdomain.my-namespace.svc.cluster-domain.example`),
|
||||
A or AAAA record for the headless service (`default-subdomain.my-namespace.svc.cluster-domain.example`),
|
||||
pointing to the Pod's IP address. Also, Pod needs to become ready in order to have a
|
||||
record unless `publishNotReadyAddresses=True` is set on the Service.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -17,24 +17,15 @@ weight: 40
|
||||
|
||||
For clarity, this guide defines the following terms:
|
||||
|
||||
Node
|
||||
: A worker machine in Kubernetes, part of a cluster.
|
||||
|
||||
Cluster
|
||||
: A set of Nodes that run containerized applications managed by Kubernetes. For this example, and in most common Kubernetes deployments, nodes in the cluster are not part of the public internet.
|
||||
|
||||
Edge router
|
||||
: A router that enforces the firewall policy for your cluster. This could be a gateway managed by a cloud provider or a physical piece of hardware.
|
||||
|
||||
Cluster network
|
||||
: A set of links, logical or physical, that facilitate communication within a cluster according to the Kubernetes [networking model](/docs/concepts/cluster-administration/networking/).
|
||||
|
||||
Service
|
||||
: A Kubernetes {{< glossary_tooltip term_id="service" >}} that identifies a set of Pods using {{< glossary_tooltip text="label" term_id="label" >}} selectors. Unless mentioned otherwise, Services are assumed to have virtual IPs only routable within the cluster network.
|
||||
* Node: A worker machine in Kubernetes, part of a cluster.
|
||||
* Cluster: A set of Nodes that run containerized applications managed by Kubernetes. For this example, and in most common Kubernetes deployments, nodes in the cluster are not part of the public internet.
|
||||
* Edge router: A router that enforces the firewall policy for your cluster. This could be a gateway managed by a cloud provider or a physical piece of hardware.
|
||||
* Cluster network: A set of links, logical or physical, that facilitate communication within a cluster according to the Kubernetes [networking model](/docs/concepts/cluster-administration/networking/).
|
||||
* Service: A Kubernetes {{< glossary_tooltip term_id="service" >}} that identifies a set of Pods using {{< glossary_tooltip text="label" term_id="label" >}} selectors. Unless mentioned otherwise, Services are assumed to have virtual IPs only routable within the cluster network.
|
||||
|
||||
## What is Ingress?
|
||||
|
||||
Ingress exposes HTTP and HTTPS routes from outside the cluster to
|
||||
[Ingress](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io) exposes HTTP and HTTPS routes from outside the cluster to
|
||||
{{< link text="services" url="/docs/concepts/services-networking/service/" >}} within the cluster.
|
||||
Traffic routing is controlled by rules defined on the Ingress resource.
|
||||
|
||||
@@ -474,6 +465,7 @@ You can expose a Service in multiple ways that don't directly involve the Ingres
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
* Learn about [ingress controllers](/docs/concepts/services-networking/ingress-controllers/)
|
||||
* Learn about the [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)
|
||||
* Learn about [Ingress Controllers](/docs/concepts/services-networking/ingress-controllers/)
|
||||
* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube)
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -199,7 +199,7 @@ If you want to allow all traffic from all pods in a namespace (even if policies
|
||||
|
||||
You can create a "default" policy for a namespace which prevents all ingress AND egress traffic by creating the following NetworkPolicy in that namespace.
|
||||
|
||||
{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}}
|
||||
{{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}}
|
||||
|
||||
This ensures that even pods that aren't selected by any other NetworkPolicy will not be allowed ingress or egress traffic.
|
||||
|
||||
@@ -207,7 +207,7 @@ This ensures that even pods that aren't selected by any other NetworkPolicy will
|
||||
|
||||
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
|
||||
|
||||
To use this feature, you (or your cluster administrator) will need to enable the `SCTPSupport` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=SCTPSupport=true,…`.
|
||||
To use this feature, you (or your cluster administrator) will need to enable the `SCTPSupport` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=SCTPSupport=true,…`.
|
||||
When the feature gate is enabled, you can set the `protocol` field of a NetworkPolicy to `SCTP`.
|
||||
|
||||
{{< note >}}
|
||||
|
||||
@@ -61,7 +61,7 @@ formatting, and typographic conventions. Look over the style guide before you
|
||||
make your first contribution, and use it when you have questions.
|
||||
|
||||
Changes to the style guide are made by SIG Docs as a group. To propose a change
|
||||
or addition, [add it to the agenda](https://docs.google.com/document/d/1zg6By77SGg90EVUrhDIhopjZlSDg2jCebU-Ks9cYx0w/edit#) for an upcoming SIG Docs meeting, and attend the meeting to participate in the
|
||||
or addition, [add it to the agenda](https://docs.google.com/document/d/1ddHwLK3kUMX1wVFIwlksjTk0MsqitBnWPe1LRa1Rx5A/edit) for an upcoming SIG Docs meeting, and attend the meeting to participate in the
|
||||
discussion. See the [advanced contribution](/docs/contribute/advanced/) topic for more
|
||||
information.
|
||||
|
||||
|
||||
@@ -5,6 +5,7 @@ reviewers:
|
||||
- liggitt
|
||||
title: Using RBAC Authorization
|
||||
content_template: templates/concept
|
||||
aliases: [../../../rbac/]
|
||||
weight: 70
|
||||
---
|
||||
|
||||
|
||||
@@ -128,7 +128,7 @@ different Kubernetes components.
|
||||
| `ServerSideApply` | `false` | Alpha | 1.14 | 1.15 |
|
||||
| `ServerSideApply` | `true` | Beta | 1.16 | |
|
||||
| `ServiceNodeExclusion` | `false` | Alpha | 1.8 | |
|
||||
| `StartupProbe` | `true` | Beta | 1.17 | |
|
||||
| `StartupProbe` | `false` | Alpha | 1.16 | |
|
||||
| `StorageVersionHash` | `false` | Alpha | 1.14 | 1.14 |
|
||||
| `StorageVersionHash` | `true` | Beta | 1.15 | |
|
||||
| `StreamingProxyRedirects` | `false` | Beta | 1.5 | 1.5 |
|
||||
|
||||
@@ -18,7 +18,7 @@ updating, and deleting primary resources via the standard HTTP verbs (POST, PUT,
|
||||
|
||||
## Standard API terminology
|
||||
|
||||
Most Kubernetes API resource types are "objects" - they represent a concrete instance of a concept on the cluster, like a pod or namespace. A smaller number of API resource types are "virtual" - they often represent operations rather than objects, such as a permission check (use a POST with a JSON-encoded body of `SubjectAccessReview` to the `subjectaccessreviews` resource). All objects will have a unique name to allow idempotent creation and retrieval, but virtual resource types may not have unique names if they are not retrievable or do not rely on idempotency.
|
||||
Most Kubernetes API resource types are [objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects): they represent a concrete instance of a concept on the cluster, like a pod or namespace. A smaller number of API resource types are "virtual" - they often represent operations rather than objects, such as a permission check (use a POST with a JSON-encoded body of `SubjectAccessReview` to the `subjectaccessreviews` resource). All objects will have a unique name to allow idempotent creation and retrieval, but virtual resource types may not have unique names if they are not retrievable or do not rely on idempotency.
|
||||
|
||||
Kubernetes generally leverages standard RESTful terminology to describe the API concepts:
|
||||
|
||||
|
||||
@@ -71,6 +71,7 @@ their authors, not the Kubernetes team.
|
||||
| dotNet | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) |
|
||||
| DotNet (RestSharp) | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) |
|
||||
| Elixir | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) |
|
||||
| Elixir | [github.com/coryodaniel/k8s](https://github.com/coryodaniel/k8s) |
|
||||
| Haskell | [github.com/kubernetes-client/haskell](https://github.com/kubernetes-client/haskell) |
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -162,6 +162,11 @@ This section contains the necessary steps to install `CRI-O` as CRI runtime.
|
||||
|
||||
Use the following commands to install CRI-O on your system:
|
||||
|
||||
{{< note >}}
|
||||
The CRI-O major and minor versions must match the Kubernetes major and minor versions.
|
||||
For more information, see the [CRI-O compatiblity matrix](https://github.com/cri-o/cri-o).
|
||||
{{< /note >}}
|
||||
|
||||
### Prerequisites
|
||||
|
||||
```shell
|
||||
|
||||
@@ -100,9 +100,9 @@ update-alternatives --set iptables /usr/sbin/iptables-legacy
|
||||
| Protocol | Direction | Port Range | Purpose | Used By |
|
||||
|----------|-----------|-------------|-----------------------|-------------------------|
|
||||
| TCP | Inbound | 10250 | Kubelet API | Self, Control plane |
|
||||
| TCP | Inbound | 30000-32767 | NodePort Services** | All |
|
||||
| TCP | Inbound | 30000-32767 | NodePort Services† | All |
|
||||
|
||||
** Default port range for [NodePort Services](/docs/concepts/services-networking/service/).
|
||||
† Default port range for [NodePort Services](/docs/concepts/services-networking/service/).
|
||||
|
||||
Any port numbers marked with * are overridable, so you will need to ensure any
|
||||
custom ports you provide are also open.
|
||||
@@ -116,35 +116,48 @@ documentation for the plugins about what port(s) those need.
|
||||
|
||||
## Installing runtime {#installing-runtime}
|
||||
|
||||
Since v1.6.0, Kubernetes has enabled the use of CRI, Container Runtime Interface, by default.
|
||||
To run containers in Pods, Kubernetes uses a
|
||||
{{< glossary_tooltip term_id="container-runtime" text="container runtime" >}}.
|
||||
|
||||
Since v1.14.0, kubeadm will try to automatically detect the container runtime on Linux nodes
|
||||
by scanning through a list of well known domain sockets. The detectable runtimes and the
|
||||
socket paths, that are used, can be found in the table below.
|
||||
{{< tabs name="container_runtime" >}}
|
||||
{{% tab name="Linux nodes" %}}
|
||||
|
||||
| Runtime | Domain Socket |
|
||||
|------------|----------------------------------|
|
||||
| Docker | /var/run/docker.sock |
|
||||
| containerd | /run/containerd/containerd.sock |
|
||||
| CRI-O | /var/run/crio/crio.sock |
|
||||
By default, Kubernetes uses the
|
||||
{{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}} (CRI)
|
||||
to interface with your chosen container runtime.
|
||||
|
||||
If both Docker and containerd are detected together, Docker takes precedence. This is
|
||||
needed, because Docker 18.09 ships with containerd and both are detectable.
|
||||
If any other two or more runtimes are detected, kubeadm will exit with an appropriate
|
||||
error message.
|
||||
If you don't specify a runtime, kubeadm automatically tries to detect an installed
|
||||
container runtime by scanning through a list of well known Unix domain sockets.
|
||||
The following table lists container runtimes and their associated socket paths:
|
||||
|
||||
On non-Linux nodes the container runtime used by default is Docker.
|
||||
{{< table caption = "Container runtimes and their socket paths" >}}
|
||||
| Runtime | Path to Unix domain socket |
|
||||
|------------|-----------------------------------|
|
||||
| Docker | `/var/run/docker.sock` |
|
||||
| containerd | `/run/containerd/containerd.sock` |
|
||||
| CRI-O | `/var/run/crio/crio.sock` |
|
||||
{{< /table >}}
|
||||
|
||||
If the container runtime of choice is Docker, it is used through the built-in
|
||||
`dockershim` CRI implementation inside of the `kubelet`.
|
||||
<br />
|
||||
If both Docker and containerd are detected, Docker takes precedence. This is
|
||||
needed because Docker 18.09 ships with containerd and both are detectable even if you only
|
||||
installed Docker.
|
||||
If any other two or more runtimes are detected, kubeadm exits with an error.
|
||||
|
||||
Other CRI-based runtimes include:
|
||||
The kubelet integrates with Docker through the built-in `dockershim` CRI implementation.
|
||||
|
||||
- [containerd/cri](https://github.com/containerd/cri) (CRI plugin built into containerd)
|
||||
- [cri-o](https://cri-o.io/)
|
||||
- [frakti](https://github.com/kubernetes/frakti)
|
||||
See [container runtimes](/docs/setup/production-environment/container-runtimes/)
|
||||
for more information.
|
||||
{{% /tab %}}
|
||||
{{% tab name="other operating systems" %}}
|
||||
By default, kubeadm uses {{< glossary_tooltip term_id="docker" >}} as the container runtime.
|
||||
The kubelet integrates with Docker through the built-in `dockershim` CRI implementation.
|
||||
|
||||
See [container runtimes](/docs/setup/production-environment/container-runtimes/)
|
||||
for more information.
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
Refer to the [CRI installation instructions](/docs/setup/cri) for more information.
|
||||
|
||||
## Installing kubeadm, kubelet and kubectl
|
||||
|
||||
@@ -170,7 +183,7 @@ For information about installing `kubectl`, see [Install and set up kubectl](/do
|
||||
{{< warning >}}
|
||||
These instructions exclude all Kubernetes packages from any system upgrades.
|
||||
This is because kubeadm and Kubernetes require
|
||||
[special attention to upgrade](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-14/).
|
||||
[special attention to upgrade](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/).
|
||||
{{</ warning >}}
|
||||
|
||||
For more information on version skews, see:
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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 %}}
|
||||
|
||||
|
||||
|
||||
@@ -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]
|
||||
}
|
||||
@@ -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:
|
||||
|
||||
|
||||
@@ -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 %}}
|
||||
|
||||
|
||||
@@ -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)
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ menu:
|
||||
weight: 10
|
||||
post: >
|
||||
<p>Ready to get your hands dirty? Build a simple Kubernetes cluster that runs "Hello World" for Node.js.</p>
|
||||
card:
|
||||
card:
|
||||
name: tutorials
|
||||
weight: 10
|
||||
---
|
||||
@@ -17,7 +17,7 @@ card:
|
||||
|
||||
This tutorial shows you how to run a simple Hello World Node.js app
|
||||
on Kubernetes using [Minikube](/docs/setup/learning-environment/minikube) and Katacoda.
|
||||
Katacoda provides a free, in-browser Kubernetes environment.
|
||||
Katacoda provides a free, in-browser Kubernetes environment.
|
||||
|
||||
{{< note >}}
|
||||
You can also follow this tutorial if you've installed [Minikube locally](/docs/tasks/tools/install-minikube/).
|
||||
@@ -49,7 +49,7 @@ For more information on the `docker build` command, read the [Docker documentati
|
||||
|
||||
## Create a Minikube cluster
|
||||
|
||||
1. Click **Launch Terminal**
|
||||
1. Click **Launch Terminal**
|
||||
|
||||
{{< kat-button >}}
|
||||
|
||||
@@ -63,7 +63,7 @@ For more information on the `docker build` command, read the [Docker documentati
|
||||
|
||||
3. Katacoda environment only: At the top of the terminal pane, click the plus sign, and then click **Select port to view on Host 1**.
|
||||
|
||||
4. Katacoda environment only: Type `30000`, and then click **Display Port**.
|
||||
4. Katacoda environment only: Type `30000`, and then click **Display Port**.
|
||||
|
||||
## Create a Deployment
|
||||
|
||||
@@ -75,7 +75,7 @@ Pod and restarts the Pod's Container if it terminates. Deployments are the
|
||||
recommended way to manage the creation and scaling of Pods.
|
||||
|
||||
1. Use the `kubectl create` command to create a Deployment that manages a Pod. The
|
||||
Pod runs a Container based on the provided Docker image.
|
||||
Pod runs a Container based on the provided Docker image.
|
||||
|
||||
```shell
|
||||
kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node
|
||||
@@ -118,7 +118,7 @@ Pod runs a Container based on the provided Docker image.
|
||||
```shell
|
||||
kubectl config view
|
||||
```
|
||||
|
||||
|
||||
{{< note >}}For more information about `kubectl`commands, see the [kubectl overview](/docs/user-guide/kubectl-overview/).{{< /note >}}
|
||||
|
||||
## Create a Service
|
||||
@@ -133,7 +133,7 @@ Kubernetes [*Service*](/docs/concepts/services-networking/service/).
|
||||
```shell
|
||||
kubectl expose deployment hello-node --type=LoadBalancer --port=8080
|
||||
```
|
||||
|
||||
|
||||
The `--type=LoadBalancer` flag indicates that you want to expose your Service
|
||||
outside of the cluster.
|
||||
|
||||
@@ -199,13 +199,13 @@ Minikube has a set of built-in {{< glossary_tooltip text="addons" term_id="addon
|
||||
storage-provisioner: enabled
|
||||
storage-provisioner-gluster: disabled
|
||||
```
|
||||
|
||||
|
||||
2. Enable an addon, for example, `metrics-server`:
|
||||
|
||||
```shell
|
||||
minikube addons enable metrics-server
|
||||
```
|
||||
|
||||
|
||||
The output is similar to:
|
||||
|
||||
```
|
||||
@@ -246,7 +246,7 @@ Minikube has a set of built-in {{< glossary_tooltip text="addons" term_id="addon
|
||||
```shell
|
||||
minikube addons disable metrics-server
|
||||
```
|
||||
|
||||
|
||||
The output is similar to:
|
||||
|
||||
```
|
||||
@@ -279,7 +279,7 @@ minikube delete
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* 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/).
|
||||
* Learn more about [Service objects](/docs/concepts/services-networking/service/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
Reference in New Issue
Block a user