resolving conflicts

2020-07-19 19:15:36 -04:00
parent a25db870c3 c477e089b7
commit 53f2d23359
255 changed files with 7212 additions and 4368 deletions
@@ -79,7 +79,8 @@ and the former approach is used in any other environment. In both cases, by
 default rotation is configured to take place when log file exceeds 10MB.

 As an example, you can find detailed information about how `kube-up.sh` sets
-up logging for COS image on GCP in the corresponding [script][cosConfigureHelper].
+up logging for COS image on GCP in the corresponding
+[script](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)

 When you run [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) as in
 the basic logging example, the kubelet on the node handles the request and
@@ -94,6 +95,25 @@ the rotation and there are two files, one 10MB in size and one empty,
 {{< /note >}}

 [cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh
+### System component logs
+
+There are two types of system components: those that run in a container and those
+that do not run in a container. For example:
+
+* The Kubernetes scheduler and kube-proxy run in a container.
+* The kubelet and container runtime, for example Docker, do not run in containers.
+
+On machines with systemd, the kubelet and container runtime write to journald. If
+systemd is not present, they write to `.log` files in the `/var/log` directory.
+System components inside containers always write to the `/var/log` directory,
+bypassing the default logging mechanism. They use the [klog](https://github.com/kubernetes/klog)
+logging library. You can find the conventions for logging severity for those
+components in the [development docs on logging](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md).
+
+Similarly to the container logs, system component logs in the `/var/log`
+directory should be rotated. In Kubernetes clusters brought up by
+the `kube-up.sh` script, those logs are configured to be rotated by
+the `logrotate` tool daily or once the size exceeds 100MB.

 ## Cluster-level logging architectures

@@ -138,9 +138,7 @@ table](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntim
  runtime_path = "${PATH_TO_BINARY}"
 ```

-See CRI-O's [config documentation][100] for more details.
-
-[100]: https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md
+See CRI-O's [config documentation](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md) for more details.

 ## Scheduling

@@ -149,7 +147,8 @@ See CRI-O's [config documentation][100] for more details.
 As of Kubernetes v1.16, RuntimeClass includes support for heterogenous clusters through its
 `scheduling` fields. Through the use of these fields, you can ensure that pods running with this
 RuntimeClass are scheduled to nodes that support it. To use the scheduling support, you must have
-the [RuntimeClass admission controller][] enabled (the default, as of 1.16).
+the [RuntimeClass admission controller](/docs/reference/access-authn-authz/admission-controllers/#runtimeclass)
+enabled (the default, as of 1.16).

 To ensure pods land on nodes supporting a specific RuntimeClass, that set of nodes should have a
 common label which is then selected by the `runtimeclass.scheduling.nodeSelector` field. The
@@ -165,8 +164,6 @@ by each.
 To learn more about configuring the node selector and tolerations, see [Assigning Pods to
 Nodes](/docs/concepts/scheduling-eviction/assign-pod-node/).

-[RuntimeClass admission controller]: /docs/reference/access-authn-authz/admission-controllers/#runtimeclass
-
 ### Pod Overhead

 {{< feature-state for_k8s_version="v1.18" state="beta" >}}
@@ -35,7 +35,7 @@ on every resource object.
 | Key                                 | Description           | Example  | Type |
 | ----------------------------------- | --------------------- | -------- | ---- |
 | `app.kubernetes.io/name`            | The name of the application | `mysql` | string |
-| `app.kubernetes.io/instance`        | A unique name identifying the instance of an application | `wordpress-abcxzy` | string |
+| `app.kubernetes.io/instance`        | A unique name identifying the instance of an application | `mysql-abcxzy` | string |
 | `app.kubernetes.io/version`         | The current version of the application (e.g., a semantic version, revision hash, etc.) | `5.7.21` | string |
 | `app.kubernetes.io/component`       | The component within the architecture | `database` | string |
 | `app.kubernetes.io/part-of`         | The name of a higher level application this one is part of | `wordpress` | string |
@@ -49,7 +49,7 @@ kind: StatefulSet
 metadata:
  labels:
    app.kubernetes.io/name: mysql
-    app.kubernetes.io/instance: wordpress-abcxzy
+    app.kubernetes.io/instance: mysql-abcxzy
    app.kubernetes.io/version: "5.7.21"
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
@@ -26,7 +26,7 @@ need to create or think about namespaces at all.  Start using namespaces when yo
 need the features they provide.

 Namespaces provide a scope for names.  Names of resources need to be unique within a namespace,
-but not across namespaces. Namespaces can not be nested inside one another and each Kubernetes 
+but not across namespaces. Namespaces cannot be nested inside one another and each Kubernetes 
 resource can only be in one namespace.

 Namespaces are a way to divide cluster resources between multiple users (via [resource quota](/docs/concepts/policy/resource-quotas/)).
@@ -302,7 +302,7 @@ kubectl-user delete pod pause
 Let's try that again, slightly differently:

 ```shell
-kubectl-user run pause --image=k8s.gcr.io/pause
+kubectl-user create deployment pause --image=k8s.gcr.io/pause
 deployment "pause" created

 kubectl-user get pods
@@ -686,7 +686,7 @@ provisioner: kubernetes.io/portworx-volume
 parameters:
  repl: "1"
  snap_interval:   "70"
-  io_priority:  "high"
+  priority_io:  "high"

 ```

@@ -695,7 +695,7 @@ parameters:
 * `repl`: number of synchronous replicas to be provided in the form of
  replication factor `1..3` (default: `1`) A string is expected here i.e.
  `"1"` and not `1`.
-* `io_priority`: determines whether the volume will be created from higher
+* `priority_io`: determines whether the volume will be created from higher
  performance or a lower priority storage `high/medium/low` (default: `low`).
 * `snap_interval`: clock/time interval in minutes for when to trigger snapshots.
  Snapshots are incremental based on difference with the prior snapshot, 0
@@ -1068,7 +1068,7 @@ allowed, which is the default if not specified.

 ### Selector

-`.spec.selector` is an required field that specifies a [label selector](/docs/concepts/overview/working-with-objects/labels/)
+`.spec.selector` is a required field that specifies a [label selector](/docs/concepts/overview/working-with-objects/labels/)
 for the Pods targeted by this Deployment.

 `.spec.selector` must match `.spec.template.metadata.labels`, or it will be rejected by the API.
@@ -215,8 +215,8 @@ To do so, set `.spec.backoffLimit` to specify the number of retries before
 considering a Job as failed. The back-off limit is set by default to 6. Failed
 Pods associated with the Job are recreated by the Job controller with an
 exponential back-off delay (10s, 20s, 40s ...) capped at six minutes. The
-back-off count is reset if no new failed Pods appear before the Job's next
-status check.
+back-off count is reset when a Job's Pod is deleted or successful without any
+other Pods for the Job failing around that time.

 {{< note >}}
 If your job has `restartPolicy = "OnFailure"`, keep in mind that your container running the Job
@@ -474,4 +474,3 @@ object, but maintains complete control over what Pods are created and how work i
 ## Cron Jobs {#cron-jobs}

 You can use a [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) to create a Job that will run at specified times/dates, similar to the Unix tool `cron`.
-
@@ -141,6 +141,18 @@ As each Pod is created, it gets a matching DNS subdomain, taking the form:
 `$(podname).$(governing service domain)`, where the governing service is defined
 by the `serviceName` field on the StatefulSet.

+Depending on how DNS is configured in your cluster, you may not be able to look up the DNS
+name for a newly-run Pod immediately. This behavior can occur when other clients in the
+cluster have already sent queries for the hostname of the Pod before it was created.
+Negative caching (normal in DNS) means that the results of previous failed lookups are
+remembered and reused, even after the Pod is running, for at least a few seconds.
+
+If you need to discover Pods promptly after they are created, you have a few options:
+
+- Query the Kubernetes API directly (for example, using a watch) rather than relying on DNS lookups.
+- Decrease the time of caching in your Kubernetes DNS provider (tpyically this means editing the config map for CoreDNS, which currently caches for 30 seconds).
+
+
 As mentioned in the [limitations](#limitations) section, you are responsible for
 creating the [Headless Service](/docs/concepts/services-networking/service/#headless-services)
 responsible for the network identity of the pods.
@@ -278,5 +290,3 @@ StatefulSet will then begin to recreate the Pods using the reverted template.
 * Follow an example of [deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/).
 * Follow an example of [running a replicated stateful application](/docs/tasks/run-application/run-replicated-stateful-application/).

-
-