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

update with master content resolving merge conflicts

Browse Source
This commit is contained in:
MAKOSCAFEE
2019-06-19 19:10:18 +03:00
parent b42f019aae 42cbe1256e
commit 8781518d32
1439 changed files with 70927 additions and 43295 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md
+1 -1
View File
@@ -82,7 +82,7 @@ pod/hostaliases-pod created
Examine a Pod IP and status:
```shell
kubectl get pod -o=wide
kubectl get pod --output=wide
```
```shell
content/en/docs/concepts/services-networking/dns-pod-service.md
+9 -10
View File
@@ -64,14 +64,6 @@ of the form `auto-generated-name.my-svc.my-namespace.svc.cluster.local`.
## Pods
### A Records
When enabled, pods are assigned a DNS A record in the form of
"`pod-ip-address.my-namespace.pod.cluster.local`".
For example, a pod with IP `1.2.3.4` in the namespace `default` with a DNS name
of `cluster.local` would have an entry: `1-2-3-4.default.pod.cluster.local`.
### Pod's hostname and subdomain fields
Currently when a pod is created, its hostname is the Pod's `metadata.name` value.
@@ -149,7 +141,11 @@ 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 record to be created. A Pod with no `hostname` but with `subdomain` only will only create the A record for the headless service (`default-subdomain.my-namespace.svc.cluster.local`), pointing to the Pod's IP address.
Because A records are not created for Pod names, `hostname` is required for the Pod's A
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.local`),
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 >}}
### Pod's DNS Policy
@@ -244,8 +240,11 @@ options ndots:2 edns0
For IPv6 setup, search path and name server should be setup like this:
```shell
kubectl exec -it dns-example -- cat /etc/resolv.conf
```
$ kubectl exec -it dns-example -- cat /etc/resolv.conf
The output is similar to this:
```shell
nameserver fd00:79:30::a
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
content/en/docs/concepts/services-networking/ingress.md
+69 -64
View File
@@ -7,23 +7,34 @@ weight: 40
---
{{% capture overview %}}
{{< feature-state for_k8s_version="v1.1" state="beta" >}}
{{< glossary_definition term_id="ingress" length="all" >}}
{{% /capture %}}
{{% capture body %}}
## Terminology
For the sake of clarity, this guide defines the following terms:
* Node: A single virtual or physical machine in a Kubernetes cluster.
* Cluster: A group of nodes firewalled from the internet, that are the primary compute resources managed by Kubernetes.
* 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 [Service](/docs/concepts/services-networking/service/) that identifies a set of pods using 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, added in Kubernetes v1.1, exposes HTTP and HTTPS routes from outside the cluster to
Ingress 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.
@@ -35,7 +46,7 @@ Traffic routing is controlled by rules defined on the Ingress resource.
[ Services ]
```
An Ingress can be configured to give services externally-reachable URLs, load balance traffic, terminate SSL, and offer name based virtual hosting. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers) is responsible for fulfilling the Ingress, usually with a loadbalancer, though it may also configure your edge router or additional frontends to help handle the traffic.
An Ingress can be configured to give services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name based virtual hosting. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers) is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic.
An Ingress does not expose arbitrary ports or protocols. Exposing services other than HTTP and HTTPS to the internet typically
uses a service of type [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) or
@@ -43,25 +54,12 @@ uses a service of type [Service.Type=NodePort](/docs/concepts/services-networkin
## Prerequisites
{{< feature-state for_k8s_version="v1.1" state="beta" >}}
You must have an [ingress controller](/docs/concepts/services-networking/ingress-controllers) to satisfy an Ingress. Only creating an Ingress resource has no effect.
Before you start using an Ingress, there are a few things you should understand. The Ingress is a beta resource.
{{< note >}}
You must have an [Ingress controller](/docs/concepts/services-networking/ingress-controllers) to satisfy an Ingress. Only creating an Ingress resource has no effect.
{{< /note >}}
GCE/Google Kubernetes Engine deploys an Ingress controller on the master. Review the
[beta limitations](https://github.com/kubernetes/ingress-gce/blob/master/BETA_LIMITATIONS.md#glbc-beta-limitations)
of this controller if you are using GCE/GKE.
In environments other than GCE/Google Kubernetes Engine, you may need to
[deploy an ingress controller](https://kubernetes.github.io/ingress-nginx/deploy/). There are a number of
You may need to deploy an ingress controller such as [ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/). There are a number of
[ingress controllers](/docs/concepts/services-networking/ingress-controllers) you may choose from.
### Before you begin
Ideally, all ingress controllers should fulfill this specification, but the various ingress
Ideally, all ingress controllers should fit the reference specification. In reality, the various ingress
controllers operate slightly differently.
{{< note >}}
@@ -70,10 +68,10 @@ Make sure you review your ingress controller's documentation to understand the c
## The Ingress Resource
A minimal ingress resource example:
A minimal Ingress resource example:
```yaml
apiVersion: extensions/v1beta1
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: test-ingress
@@ -89,15 +87,15 @@ spec:
servicePort: 80
```
As with all other Kubernetes resources, an Ingress needs `apiVersion`, `kind`, and `metadata` fields.
As with all other Kubernetes resources, an Ingress needs `apiVersion`, `kind`, and `metadata` fields.
For general information about working with config files, see [deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/), [configuring containers](/docs/tasks/configure-pod-container/configure-pod-configmap/), [managing resources](/docs/concepts/cluster-administration/manage-deployment/).
Ingress frequently uses annotations to configure some options depending on the Ingress controller, an example of which
is the [rewrite-target annotation](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md).
Different [Ingress controller](/docs/concepts/services-networking/ingress-controllers) support different annotations. Review the documentation for
your choice of Ingress controller to learn which annotations are supported.
The Ingress [spec](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status)
has all the information needed to configure a loadbalancer or proxy server. Most importantly, it
The Ingress [spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)
has all the information needed to configure a load balancer or proxy server. Most importantly, it
contains a list of rules matched against all incoming requests. Ingress resource only supports rules
for directing HTTP traffic.
@@ -106,11 +104,11 @@ for directing HTTP traffic.
Each http rule contains the following information:
* An optional host. In this example, no host is specified, so the rule applies to all inbound
HTTP traffic through the IP address is specified. If a host is provided (for example,
HTTP traffic through the IP address specified. If a host is provided (for example,
foo.bar.com), the rules apply to that host.
* a list of paths (for example, /testpath), each of which has an associated backend defined with a `serviceName`
* a list of paths (for example, `/testpath`), each of which has an associated backend defined with a `serviceName`
and `servicePort`. Both the host and path must match the content of an incoming request before the
loadbalancer will direct traffic to the referenced service.
load balancer will direct traffic to the referenced service.
* A backend is a combination of service and port names as described in the
[services doc](/docs/concepts/services-networking/service/). HTTP (and HTTPS) requests to the
Ingress matching the host and path of the rule will be sent to the listed backend.
@@ -136,13 +134,14 @@ There are existing Kubernetes concepts that allow you to expose a single Service
{{< codenew file="service/networking/ingress.yaml" >}}
If you create it using `kubectl apply -f` you should see:
If you create it using `kubectl apply -f` you should be able to view the state
of the Ingress you just added:
```shell
kubectl get ingress test-ingress
```
```shell
```
NAME HOSTS ADDRESS PORTS AGE
test-ingress * 107.178.254.228 80 59s
```
@@ -158,10 +157,10 @@ Until that time you will often see the address listed as `<pending>`.
### Simple fanout
A fanout configuration routes traffic from a single IP address to more than one service,
based on the HTTP URI being requested. An Ingress allows you to keep the number of loadbalancers
based on the HTTP URI being requested. An Ingress allows you to keep the number of load balancers
down to a minimum. For example, a setup like:
```shell
```none
foo.bar.com -> 178.91.123.132 -> / foo service1:4200
/ bar service2:8080
```
@@ -169,7 +168,7 @@ foo.bar.com -> 178.91.123.132 -> / foo service1:4200
would require an Ingress such as:
```yaml
apiVersion: extensions/v1beta1
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: simple-fanout-example
@@ -196,7 +195,7 @@ When you create the ingress with `kubectl apply -f`:
kubectl describe ingress simple-fanout-example
```
```shell
```
Name: simple-fanout-example
Namespace: default
Address: 178.91.123.132
@@ -215,14 +214,15 @@ Events:
Normal ADD 22s loadbalancer-controller default/test
```
The Ingress controller provisions an implementation specific loadbalancer
The Ingress controller provisions an implementation-specific load balancer
that satisfies the Ingress, as long as the services (`s1`, `s2`) exist.
When it has done so, you can see the address of the loadbalancer at the
When it has done so, you can see the address of the load balancer at the
Address field.
{{< note >}}
Depending on the [Ingress controller](/docs/concepts/services-networking/ingress-controllers) you are using, you may need to
create a default-http-backend [Service](/docs/concepts/services-networking/service/).
Depending on the [Ingress controller](/docs/concepts/services-networking/ingress-controllers)
you are using, you may need to create a default-http-backend
[Service](/docs/concepts/services-networking/service/).
{{< /note >}}
### Name based virtual hosting
@@ -235,11 +235,11 @@ foo.bar.com --| |-> foo.bar.com s1:80
bar.foo.com --| |-> bar.foo.com s2:80
```
The following Ingress tells the backing loadbalancer to route requests based on
The following Ingress tells the backing load balancer to route requests based on
the [Host header](https://tools.ietf.org/html/rfc7230#section-5.4).
```yaml
apiVersion: extensions/v1beta1
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: name-virtual-host-ingress
@@ -261,13 +261,15 @@ spec:
If you create an Ingress resource without any hosts defined in the rules, then any
web traffic to the IP address of your Ingress controller can be matched without a name based
virtual host being required. For example, the following Ingress resource will route traffic
virtual host being required.
For example, the following Ingress resource will route traffic
requested for `first.bar.com` to `service1`, `second.foo.com` to `service2`, and any traffic
to the IP address without a hostname defined in request (that is, without a request header being
presented) to `service3`.
```yaml
apiVersion: extensions/v1beta1
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: name-virtual-host-ingress
@@ -294,7 +296,7 @@ spec:
### TLS
You can secure an Ingress by specifying a [secret](/docs/concepts/configuration/secret)
You can secure an Ingress by specifying a {{< glossary_tooltip term_id="secret" >}}
that contains a TLS private key and certificate. Currently the Ingress only
supports a single TLS port, 443, and assumes TLS termination. If the TLS
configuration section in an Ingress specifies different hosts, they will be
@@ -305,23 +307,23 @@ and private key to use for TLS, e.g.:
```yaml
apiVersion: v1
data:
tls.crt: base64 encoded cert
tls.key: base64 encoded key
kind: Secret
metadata:
name: testsecret-tls
namespace: default
data:
tls.crt: base64 encoded cert
tls.key: base64 encoded key
type: kubernetes.io/tls
```
Referencing this secret in an Ingress will tell the Ingress controller to
secure the channel from the client to the loadbalancer using TLS. You need to make
sure the TLS secret you created came from a certificate that contains a CN
secure the channel from the client to the load balancer using TLS. You need to make
sure the TLS secret you created came from a certificate that contains a CN
for `sslexample.foo.com`.
```yaml
apiVersion: extensions/v1beta1
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: tls-example-ingress
@@ -354,14 +356,14 @@ An Ingress controller is bootstrapped with some load balancing policy settings
that it applies to all Ingress, such as the load balancing algorithm, backend
weight scheme, and others. More advanced load balancing concepts
(e.g. persistent sessions, dynamic weights) are not yet exposed through the
Ingress. You can still get these features through the
[service loadbalancer](https://github.com/kubernetes/ingress-nginx).
Ingress. You can instead get these features through the load balancer used for
a Service.
It's also worth noting that even though health checks are not exposed directly
through the Ingress, there exist parallel concepts in Kubernetes such as
[readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)
which allow you to achieve the same end result. Please review the controller
specific docs to see how they handle health checks (
that allow you to achieve the same end result. Please review the controller
specific documentation to see how they handle health checks (
[nginx](https://git.k8s.io/ingress-nginx/README.md),
[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks)).
@@ -373,7 +375,7 @@ To update an existing Ingress to add a new Host, you can update it by editing th
kubectl describe ingress test
```
```shell
```
Name: test
Namespace: default
Address: 178.91.123.132
@@ -395,7 +397,8 @@ Events:
kubectl edit ingress test
```
This should pop up an editor with the existing yaml, modify it to include the new Host:
This should pop up an editor with the existing configuration in yaml format.
Modify it to include the new Host:
```yaml
spec:
@@ -417,14 +420,16 @@ spec:
..
```
Saving the yaml will update the resource in the API server, which should tell the
Ingress controller to reconfigure the loadbalancer.
After you save your changes, kubectl will update the resource in the API server, which should tell the
Ingress controller to reconfigure the load balancer.
Verify this:
```shell
kubectl describe ingress test
```
```shell
```
Name: test
Namespace: default
Address: 178.91.123.132
@@ -444,7 +449,7 @@ Events:
Normal ADD 45s loadbalancer-controller default/test
```
You can achieve the same by invoking `kubectl replace -f` on a modified Ingress yaml file.
You can achieve the same outcome by invoking `kubectl replace -f` on a modified Ingress yaml file.
## Failing across availability zones
@@ -455,7 +460,7 @@ for details on deploying Ingress in a federated cluster.
## Future Work
Track [SIG Network](https://github.com/kubernetes/community/tree/master/sig-network)
for more details on the evolution of the ingress and related resources. You may also track the
for more details on the evolution of Ingress and related resources. You may also track the
[Ingress repository](https://github.com/kubernetes/ingress/tree/master) for more details on the
evolution of various Ingress controllers.
@@ -465,10 +470,10 @@ You can expose a Service in multiple ways that don't directly involve the Ingres
* Use [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)
* Use [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)
* Use a [Port Proxy](https://git.k8s.io/contrib/for-demos/proxy-to-service)
{{% /capture %}}
{{% capture whatsnext %}}
* 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 %}}
content/en/docs/concepts/services-networking/network-policies.md
+2 -2
View File
@@ -77,9 +77,9 @@ __Mandatory Fields__: As with all other Kubernetes config, a `NetworkPolicy`
needs `apiVersion`, `kind`, and `metadata` fields. For general information
about working with config files, see
[Configure Containers Using a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/),
and [Object Management](/docs/concepts/overview/object-management-kubectl/overview/).
and [Object Management](/docs/concepts/overview/working-with-objects/object-management).
__spec__: `NetworkPolicy` [spec](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) has all the information needed to define a particular network policy in the given namespace.
__spec__: `NetworkPolicy` [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) has all the information needed to define a particular network policy in the given namespace.
__podSelector__: Each `NetworkPolicy` includes a `podSelector` which selects the grouping of pods to which the policy applies. The example policy selects pods with the label "role=db". An empty `podSelector` selects all pods in the namespace.
content/en/docs/concepts/services-networking/service.md
+443 -313
View File
File diff suppressed because it is too large Load Diff
content/en/docs/concepts/services-networking/service.md.orig
+1147
View File
File diff suppressed because it is too large Load Diff
content/en/docs/concepts/services-networking/service_BACKUP_16221.md
+1147
View File
File diff suppressed because it is too large Load Diff
content/en/docs/concepts/services-networking/service_BACKUP_80035.md
+1147
View File
File diff suppressed because it is too large Load Diff
content/en/docs/concepts/services-networking/service_BASE_16221.md
+1021
View File
File diff suppressed because it is too large Load Diff
content/en/docs/concepts/services-networking/service_BASE_80035.md
+1021
View File
File diff suppressed because it is too large Load Diff
content/en/docs/concepts/services-networking/service_LOCAL_16221.md
+1017
View File
File diff suppressed because it is too large Load Diff
content/en/docs/concepts/services-networking/service_LOCAL_80035.md
+1017
View File
File diff suppressed because it is too large Load Diff
content/en/docs/concepts/services-networking/service_REMOTE_16221.md
+1151
View File
File diff suppressed because it is too large Load Diff
content/en/docs/concepts/services-networking/service_REMOTE_80035.md
+1151
View File
File diff suppressed because it is too large Load Diff