From 527960a0925287d80fc7840de4ffafb23f065732 Mon Sep 17 00:00:00 2001 From: Ori Hoch Date: Mon, 15 Jun 2020 10:20:56 +0300 Subject: [PATCH 01/86] volume_attributes is now volume_context in CSI spec this is reflected in the code as well: https://github.com/kubernetes/kubernetes/blob/master/pkg/volume/csi/csi_client.go#L52 --- content/en/docs/concepts/storage/volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md index fe71c2e86e..c8bf65a292 100644 --- a/content/en/docs/concepts/storage/volumes.md +++ b/content/en/docs/concepts/storage/volumes.md @@ -1323,7 +1323,7 @@ persistent volume: of a volume. This map must correspond to the map returned in the `volume.attributes` field of the `CreateVolumeResponse` by the CSI driver as defined in the [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume). - The map is passed to the CSI driver via the `volume_attributes` field in the + The map is passed to the CSI driver via the `volume_context` field in the `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, and `NodePublishVolumeRequest`. - `controllerPublishSecretRef`: A reference to the secret object containing From 8308aabb860e07e4a826433bd9819369acbdc486 Mon Sep 17 00:00:00 2001 From: "Johannes M. Scheuermann" Date: Mon, 25 May 2020 15:17:02 +0200 Subject: [PATCH 02/86] Add documentation for API server health checks --- .../docs/reference/using-api/health-checks.md | 93 +++++++++++++++++++ 1 file changed, 93 insertions(+) create mode 100644 content/en/docs/reference/using-api/health-checks.md diff --git a/content/en/docs/reference/using-api/health-checks.md b/content/en/docs/reference/using-api/health-checks.md new file mode 100644 index 0000000000..7e1aabbf21 --- /dev/null +++ b/content/en/docs/reference/using-api/health-checks.md @@ -0,0 +1,93 @@ +--- +title: Kubernetes API health endpoints +reviewers: +- logicalhan +content_type: concept +weight: 50 +--- + + +The Kubernetes {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} provides API endpoints to indicate the current status of the API server. +This page describes these API endpoints and explains how you can use them. + + + +## API endpoints for health + +The Kubernetes API server provides 3 API endpoints (`healthz`, `livez` and `readyz`) to indicate the current status of the API server. +The `healthz` endpoint is deprecated (since Kubernetes v1.16), and you should use the more specific `livez` and `readyz` endpoints instead. +The `livez` endpoint can be used with the `--livez-grace-period` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) to specify the startup duration. +For a graceful shutdown you can specify the `--shutdown-delay-duration` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) with the `/readyz` endpoint. +Machines that check the `health`/`livez`/`readyz` of the API server should rely on the HTTP status code. +A status code `200` indicates the the API server is `healthy`/`live`/`ready`, depending of the called endpoint. +The more verbose options shown below are intended to be used by human operators to debug their cluster or specially the state of the API server. + +The following examples will show how you can interact with the health API endpoints. + +For all endpoints you can use the `verbose` parameter to print out the checks and their status. +This can be useful for a human operator to debug the current status of the Api server, it is not intended to be consumed by a machine: + + ```shell + curl -k https://localhost:6443/livez?verbose + ``` + +The output will look like this: + + [+]ping ok + [+]log ok + [+]etcd ok + [+]poststarthook/start-kube-apiserver-admission-initializer ok + [+]poststarthook/generic-apiserver-start-informers ok + [+]poststarthook/start-apiextensions-informers ok + [+]poststarthook/start-apiextensions-controllers ok + [+]poststarthook/crd-informer-synced ok + [+]poststarthook/bootstrap-controller ok + [+]poststarthook/rbac/bootstrap-roles ok + [+]poststarthook/scheduling/bootstrap-system-priority-classes ok + [+]poststarthook/start-cluster-authentication-info-controller ok + [+]poststarthook/start-kube-aggregator-informers ok + [+]poststarthook/apiservice-registration-controller ok + [+]poststarthook/apiservice-status-available-controller ok + [+]poststarthook/kube-apiserver-autoregistration ok + [+]autoregister-completion ok + [+]poststarthook/apiservice-openapi-controller ok + healthz check passed + +The Kubernetes API server also supports to exclude specific checks. +The query parameters can also be combined like in this example: + + ```shell + curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd' + ``` + +The output show that the `etcd` check is excluded: + + [+]ping ok + [+]log ok + [+]etcd excluded: ok + [+]poststarthook/start-kube-apiserver-admission-initializer ok + [+]poststarthook/generic-apiserver-start-informers ok + [+]poststarthook/start-apiextensions-informers ok + [+]poststarthook/start-apiextensions-controllers ok + [+]poststarthook/crd-informer-synced ok + [+]poststarthook/bootstrap-controller ok + [+]poststarthook/rbac/bootstrap-roles ok + [+]poststarthook/scheduling/bootstrap-system-priority-classes ok + [+]poststarthook/start-cluster-authentication-info-controller ok + [+]poststarthook/start-kube-aggregator-informers ok + [+]poststarthook/apiservice-registration-controller ok + [+]poststarthook/apiservice-status-available-controller ok + [+]poststarthook/kube-apiserver-autoregistration ok + [+]autoregister-completion ok + [+]poststarthook/apiservice-openapi-controller ok + [+]shutdown ok + healthz check passed + +Each individual health check exposes an http endpoint and could can be checked individually. +The schema for the individual health checks is `/livez/` where `livez` and `readyz` and be used to indicate if you want to check thee liveness or the readiness of the API server. +The `` path can be discovered using the `verbose` flag from above and take the path between `[+]` and `ok`. +These individual health checks should not be consumed by machines but can be helpful for a human operator to debug a system: + + ```shell + curl -k https://localhost:6443/livez/etcd + ``` From 9adc2c7c6c0347dc88ebd3a8fbdcfba100e5711b Mon Sep 17 00:00:00 2001 From: Richard Mokua Date: Fri, 19 Jun 2020 03:36:56 +0200 Subject: [PATCH 03/86] Update audit.md --- .../tasks/debug-application-cluster/audit.md | 33 +++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/content/en/docs/tasks/debug-application-cluster/audit.md b/content/en/docs/tasks/debug-application-cluster/audit.md index 600af51d00..5e435ba32d 100644 --- a/content/en/docs/tasks/debug-application-cluster/audit.md +++ b/content/en/docs/tasks/debug-application-cluster/audit.md @@ -133,6 +133,39 @@ log audit backend using the following [kube-apiserver][kube-apiserver] flags: - `--audit-log-maxbackup` defines the maximum number of audit log files to retain - `--audit-log-maxsize` defines the maximum size in megabytes of the audit log file before it gets rotated +{{< note >}} +In case kube-apiserver is configured as a Pod,remember to mount the hostPath to the localtion of the policy file and log file. For example, +` +--audit-policy-file=/etc/kubernetes/audit-policy.yaml +--audit-log-path=/var/log/audit.log +` +then mount the volumes: + + +``` +- mountPath: /etc/kubernetes/audit-policy.yaml + name: audit + readOnly: true + - mountPath: /var/log/audit.log + name: audit-log + readOnly: false +``` +finally the hostPath: + +``` +- hostPath: + path: /etc/kubernetes/audit-policy.yaml + type: File + name: audit + - hostPath: + path: /var/log/audit.log + type: FileOrCreate + name: audit-log + +``` + + +{{< /note >}} ### Webhook backend Webhook backend sends audit events to a remote API, which is assumed to be the From f5d6481d3d1b78e8240203d0778b14e5c5ca8f34 Mon Sep 17 00:00:00 2001 From: Richard Mokua Date: Wed, 1 Jul 2020 07:50:46 +0200 Subject: [PATCH 04/86] Update audit.md removed comment tag and indentation --- content/en/docs/tasks/debug-application-cluster/audit.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/content/en/docs/tasks/debug-application-cluster/audit.md b/content/en/docs/tasks/debug-application-cluster/audit.md index 5e435ba32d..8c81f2c1c9 100644 --- a/content/en/docs/tasks/debug-application-cluster/audit.md +++ b/content/en/docs/tasks/debug-application-cluster/audit.md @@ -133,8 +133,7 @@ log audit backend using the following [kube-apiserver][kube-apiserver] flags: - `--audit-log-maxbackup` defines the maximum number of audit log files to retain - `--audit-log-maxsize` defines the maximum size in megabytes of the audit log file before it gets rotated -{{< note >}} -In case kube-apiserver is configured as a Pod,remember to mount the hostPath to the localtion of the policy file and log file. For example, +In case kube-apiserver is configured as a Pod,remember to mount the hostPath to the location of the policy file and log file. For example, ` --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-log-path=/var/log/audit.log @@ -146,7 +145,7 @@ then mount the volumes: - mountPath: /etc/kubernetes/audit-policy.yaml name: audit readOnly: true - - mountPath: /var/log/audit.log +- mountPath: /var/log/audit.log name: audit-log readOnly: false ``` @@ -157,7 +156,7 @@ finally the hostPath: path: /etc/kubernetes/audit-policy.yaml type: File name: audit - - hostPath: +- hostPath: path: /var/log/audit.log type: FileOrCreate name: audit-log @@ -165,7 +164,7 @@ finally the hostPath: ``` -{{< /note >}} + ### Webhook backend Webhook backend sends audit events to a remote API, which is assumed to be the From 259655797b66f22a5729d496844967e3a94d1a0c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Serta=C3=A7=20=C3=96zercan?= <852750+sozercan@users.noreply.github.com> Date: Thu, 2 Jul 2020 11:07:24 -0700 Subject: [PATCH 05/86] Remove container level supplementalGroups and fsgroup --- content/en/docs/concepts/security/pod-security-standards.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/content/en/docs/concepts/security/pod-security-standards.md b/content/en/docs/concepts/security/pod-security-standards.md index 2afd6c7335..20574c8f91 100644 --- a/content/en/docs/concepts/security/pod-security-standards.md +++ b/content/en/docs/concepts/security/pod-security-standards.md @@ -236,11 +236,7 @@ well as lower-trust users.The following listed controls should be enforced/disal spec.securityContext.supplementalGroups[*]
spec.securityContext.fsGroup
spec.containers[*].securityContext.runAsGroup
- spec.containers[*].securityContext.supplementalGroups[*]
- spec.containers[*].securityContext.fsGroup
spec.initContainers[*].securityContext.runAsGroup
- spec.initContainers[*].securityContext.supplementalGroups[*]
- spec.initContainers[*].securityContext.fsGroup

Allowed Values:
non-zero
undefined / nil (except for `*.runAsGroup`)
From a87bb799c23f5e05669337ec3f87f7b2529a2139 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sat, 4 Jul 2020 11:31:20 +0800 Subject: [PATCH 06/86] Remove Poseidon page The [Poseidon project](https://github.com/kubernetes-sigs/poseidon/commits/master) is virtually dead: - No PRs coming in since Dec 2019 - PRs related to code changes date back to April 2019. By removing this page, we can save folks' effort on localizing the content, i.e. #22265. --- .../poseidon-firmament-alternate-scheduler.md | 112 ------------------ 1 file changed, 112 deletions(-) delete mode 100644 content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md diff --git a/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md b/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md deleted file mode 100644 index 7f81439c41..0000000000 --- a/content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -title: Poseidon-Firmament Scheduler -content_type: concept -weight: 80 ---- - - - -{{< feature-state for_k8s_version="v1.6" state="alpha" >}} - -The Poseidon-Firmament scheduler is an alternate scheduler that can be deployed alongside the default Kubernetes scheduler. - - - - - - -## Introduction - -Poseidon is a service that acts as the integration glue between the [Firmament scheduler](https://github.com/Huawei-PaaS/firmament) and Kubernetes. Poseidon-Firmament augments the current Kubernetes scheduling capabilities. It incorporates novel flow network graph based scheduling capabilities alongside the default Kubernetes scheduler. The Firmament scheduler models workloads and clusters as flow networks and runs min-cost flow optimizations over these networks to make scheduling decisions. - -Firmament models the scheduling problem as a constraint-based optimization over a flow network graph. This is achieved by reducing scheduling to a min-cost max-flow optimization problem. The Poseidon-Firmament scheduler dynamically refines the workload placements. - -Poseidon-Firmament scheduler runs alongside the default Kubernetes scheduler as an alternate scheduler. You can simultaneously run multiple, different schedulers. - -Flow graph scheduling with the Poseidon-Firmament scheduler provides the following advantages: - -- Workloads (Pods) are bulk scheduled to enable scheduling at massive scale. - The Poseidon-Firmament scheduler outperforms the Kubernetes default scheduler by a wide margin when it comes to throughput performance for scenarios where compute resource requirements are somewhat uniform across your workload (Deployments, ReplicaSets, Jobs). -- The Poseidon-Firmament's scheduler's end-to-end throughput performance and bind time improves as the number of nodes in a cluster increases. As you scale out, Poseidon-Firmament scheduler is able to amortize more and more work across workloads. -- Scheduling in Poseidon-Firmament is dynamic; it keeps cluster resources in a global optimal state during every scheduling run. -- The Poseidon-Firmament scheduler supports scheduling complex rule constraints. - -## How the Poseidon-Firmament scheduler works - -Kubernetes supports [using multiple schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/). You can specify, for a particular Pod, that it is scheduled by a custom scheduler (“poseidon” for this case), by setting the `schedulerName` field in the PodSpec at the time of pod creation. The default scheduler will ignore that Pod and allow Poseidon-Firmament scheduler to schedule the Pod on a relevant node. - -For example: - -```yaml -apiVersion: v1 -kind: Pod -... -spec: - schedulerName: poseidon -... -``` - -## Batch scheduling - -As mentioned earlier, Poseidon-Firmament scheduler enables an extremely high throughput scheduling environment at scale due to its bulk scheduling approach versus Kubernetes pod-at-a-time approach. In our extensive tests, we have observed substantial throughput benefits as long as resource requirements (CPU/Memory) for incoming Pods are uniform across jobs (Replicasets/Deployments/Jobs), mainly due to efficient amortization of work across jobs. - -Although, Poseidon-Firmament scheduler is capable of scheduling various types of workloads, such as service, batch, etc., the following are a few use cases where it excels the most: - -1. For “Big Data/AI” jobs consisting of large number of tasks, throughput benefits are tremendous. -2. Service or batch jobs where workload resource requirements are uniform across jobs (Replicasets/Deployments/Jobs). - -## Feature state - -Poseidon-Firmament is designed to work with Kubernetes release 1.6 and all subsequent releases. - -{{< caution >}} -Poseidon-Firmament scheduler does not provide support for high availability; its implementation assumes that the scheduler cannot fail. -{{< /caution >}} - -## Feature comparison {#feature-comparison-matrix} - -{{< table caption="Feature comparison of Kubernetes and Poseidon-Firmament schedulers." >}} -|Feature|Kubernetes Default Scheduler|Poseidon-Firmament Scheduler|Notes| -|--- |--- |--- |--- | -|Node Affinity/Anti-Affinity|Y|Y|| -|Pod Affinity/Anti-Affinity - including support for pod anti-affinity symmetry|Y|Y|The default scheduler outperforms the Poseidon-Firmament scheduler pod affinity/anti-affinity functionality.| -|Taints & Tolerations|Y|Y|| -|Baseline Scheduling capability in accordance to available compute resources (CPU & Memory) on a node|Y|Y†|**†** Not all Predicates & Priorities are supported with Poseidon-Firmament.| -|Extreme Throughput at scale|Y†|Y|**†** Bulk scheduling approach scales or increases workload placement. Firmament scheduler offers high throughput when resource requirements (CPU/Memory) for incoming Pods are uniform across ReplicaSets/Deployments/Jobs.| -|Colocation Interference Avoidance|N|N|| -|Priority Preemption|Y|N†|**†** Partially exists in Poseidon-Firmament versus extensive support in Kubernetes default scheduler.| -|Inherent Rescheduling|N|Y†|**†** Poseidon-Firmament scheduler supports workload re-scheduling. In each scheduling run, Poseidon-Firmament considers all Pods, including running Pods, and as a result can migrate or evict Pods – a globally optimal scheduling environment.| -|Gang Scheduling|N|Y|| -|Support for Pre-bound Persistence Volume Scheduling|Y|Y|| -|Support for Local Volume & Dynamic Persistence Volume Binding Scheduling|Y|N|| -|High Availability|Y|N|| -|Real-time metrics based scheduling|N|Y†|**†** Partially supported in Poseidon-Firmament using Heapster (now deprecated) for placing Pods using actual cluster utilization statistics rather than reservations.| -|Support for Max-Pod per node|Y|Y|Poseidon-Firmament scheduler seamlessly co-exists with Kubernetes default scheduler.| -|Support for Ephemeral Storage, in addition to CPU/Memory|Y|Y|| -{{< /table >}} - -## Installation - -The [Poseidon-Firmament installation guide](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/install/README.md#Installation) explains how to deploy Poseidon-Firmament to your cluster. - -## Performance comparison - -{{< note >}} - Please refer to the [latest benchmark results](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/benchmark/README.md) for detailed throughput performance comparison test results between Poseidon-Firmament scheduler and the Kubernetes default scheduler. -{{< /note >}} - -Pod-by-pod schedulers, such as the Kubernetes default scheduler, process Pods in small batches (typically one at a time). These schedulers have the following crucial drawbacks: - -1. The scheduler commits to a pod placement early and restricts the choices for other pods that wait to be placed. -2. There is limited opportunities for amortizing work across pods because they are considered for placement individually. - -These downsides of pod-by-pod schedulers are addressed by batching or bulk scheduling in Poseidon-Firmament scheduler. Processing several pods in a batch allows the scheduler to jointly consider their placement, and thus to find the best trade-off for the whole batch instead of one pod. At the same time it amortizes work across pods resulting in much higher throughput. - - -## {{% heading "whatsnext" %}} - -* See [Poseidon-Firmament](https://github.com/kubernetes-sigs/poseidon#readme) on GitHub for more information. -* See the [design document](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/design/README.md) for Poseidon. -* Read [Firmament: Fast, Centralized Cluster Scheduling at Scale](https://www.usenix.org/system/files/conference/osdi16/osdi16-gog.pdf), the academic paper on the Firmament scheduling design. -* If you'd like to contribute to Poseidon-Firmament, refer to the [developer setup instructions](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/devel/README.md). - From e097b93c8e557c7c1e7c78d70180fca7732319ee Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sat, 4 Jul 2020 13:23:26 +0800 Subject: [PATCH 07/86] Fix pages that reference removed API groups Quite some resources have been moved out of the `extensions` API group since 1.18; the `apps/v1beta1` and `apps/v1beta2` group versions are also dropped. This PR updates the pages which still reference such API groups or group versions. --- .../cluster-administration/manage-deployment.md | 2 +- content/en/docs/concepts/overview/kubernetes-api.md | 12 +----------- .../concepts/workloads/controllers/deployment.md | 4 ---- .../workloads/controllers/garbage-collection.md | 6 ------ .../access-authn-authz/admission-controllers.md | 5 +---- .../extensible-admission-controllers.md | 2 +- content/en/docs/reference/using-api/api-overview.md | 9 +-------- .../access-application-cluster/ingress-minikube.md | 4 ++-- .../administer-cluster/dns-horizontal-autoscaling.md | 2 +- 9 files changed, 8 insertions(+), 38 deletions(-) diff --git a/content/en/docs/concepts/cluster-administration/manage-deployment.md b/content/en/docs/concepts/cluster-administration/manage-deployment.md index b052dd3a15..d0485a4342 100644 --- a/content/en/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/en/docs/concepts/cluster-administration/manage-deployment.md @@ -323,7 +323,7 @@ When load on your application grows or shrinks, it's easy to scale with `kubectl kubectl scale deployment/my-nginx --replicas=1 ``` ```shell -deployment.extensions/my-nginx scaled +deployment.apps/my-nginx scaled ``` Now you only have one pod managed by the deployment. diff --git a/content/en/docs/concepts/overview/kubernetes-api.md b/content/en/docs/concepts/overview/kubernetes-api.md index b3b6960358..42d12425b7 100644 --- a/content/en/docs/concepts/overview/kubernetes-api.md +++ b/content/en/docs/concepts/overview/kubernetes-api.md @@ -25,8 +25,6 @@ The Kubernetes API lets you query and manipulate the state of objects in the Kub API endpoints, resource types and samples are described in the [API Reference](/docs/reference/kubernetes-api/). - - ## API changes @@ -87,7 +85,7 @@ Kubernetes implements an alternative Protobuf based serialization format for the To make it easier to eliminate fields or restructure resource representations, Kubernetes supports multiple API versions, each at a different API path, such as `/api/v1` or -`/apis/extensions/v1beta1`. +`/apis/rbac.authorization.k8s.io/v1alpha1`. Versioning is done at the API level rather than at the resource or field level to ensure that the API presents a clear, consistent view of system resources and behavior, and to enable controlling @@ -157,14 +155,6 @@ The flag accepts comma separated set of key=value pairs describing runtime confi {{< note >}}Enabling or disabling groups or resources requires restarting the kube-apiserver and the kube-controller-manager to pick up the `--runtime-config` changes.{{< /note >}} -## Enabling specific resources in the extensions/v1beta1 group - -DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies and ReplicaSets in the `extensions/v1beta1` API group are disabled by default. -For example: to enable deployments and daemonsets, set -`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`. - -{{< note >}}Individual resource enablement/disablement is only supported in the `extensions/v1beta1` API group for legacy reasons.{{< /note >}} - ## Persistence Kubernetes stores its serialized state in terms of the API resources by writing them into diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md index 6b117cdc44..e58095517b 100644 --- a/content/en/docs/concepts/workloads/controllers/deployment.md +++ b/content/en/docs/concepts/workloads/controllers/deployment.md @@ -1155,10 +1155,6 @@ created Pod should be ready without any of its containers crashing, for it to be This defaults to 0 (the Pod will be considered available as soon as it is ready). To learn more about when a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes). -### Rollback To - -Field `.spec.rollbackTo` has been deprecated in API versions `extensions/v1beta1` and `apps/v1beta1`, and is no longer supported in API versions starting `apps/v1beta2`. Instead, `kubectl rollout undo` as introduced in [Rolling Back to a Previous Revision](#rolling-back-to-a-previous-revision) should be used. - ### Revision History Limit A Deployment's revision history is stored in the ReplicaSets it controls. diff --git a/content/en/docs/concepts/workloads/controllers/garbage-collection.md b/content/en/docs/concepts/workloads/controllers/garbage-collection.md index a20951a35e..79cc905f58 100644 --- a/content/en/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/en/docs/concepts/workloads/controllers/garbage-collection.md @@ -111,12 +111,6 @@ To control the cascading deletion policy, set the `propagationPolicy` field on the `deleteOptions` argument when deleting an Object. Possible values include "Orphan", "Foreground", or "Background". -Prior to Kubernetes 1.9, the default garbage collection policy for many controller resources was `orphan`. -This included ReplicationController, ReplicaSet, StatefulSet, DaemonSet, and -Deployment. For kinds in the `extensions/v1beta1`, `apps/v1beta1`, and `apps/v1beta2` group versions, unless you -specify otherwise, dependent objects are orphaned by default. In Kubernetes 1.9, for all kinds in the `apps/v1` -group version, dependent objects are deleted by default. - Here's an example that deletes dependents in background: ```shell diff --git a/content/en/docs/reference/access-authn-authz/admission-controllers.md b/content/en/docs/reference/access-authn-authz/admission-controllers.md index 874bcbeb1c..18e525ac35 100644 --- a/content/en/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md @@ -677,9 +677,6 @@ for more information. This admission controller acts on creation and modification of the pod and determines if it should be admitted based on the requested security context and the available Pod Security Policies. -For Kubernetes < 1.6.0, the API Server must enable the extensions/v1beta1/podsecuritypolicy API -extensions group (`--runtime-config=extensions/v1beta1/podsecuritypolicy=true`). - See also [Pod Security Policy documentation](/docs/concepts/policy/pod-security-policy/) for more information. @@ -793,4 +790,4 @@ phase, and therefore is the last admission controller to run. in the mutating phase. For earlier versions, there was no concept of validating versus mutating and the -admission controllers ran in the exact order specified. \ No newline at end of file +admission controllers ran in the exact order specified. diff --git a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md index 718c9d1147..8b0794a6b7 100644 --- a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md +++ b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md @@ -949,7 +949,7 @@ See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels for ### Matching requests: matchPolicy API servers can make objects available via multiple API groups or versions. -For example, the Kubernetes API server allows creating and modifying `Deployment` objects +For example, the Kubernetes API server may allow creating and modifying `Deployment` objects via `extensions/v1beta1`, `apps/v1beta1`, `apps/v1beta2`, and `apps/v1` APIs. For example, if a webhook only specified a rule for some API groups/versions (like `apiGroups:["apps"], apiVersions:["v1","v1beta1"]`), diff --git a/content/en/docs/reference/using-api/api-overview.md b/content/en/docs/reference/using-api/api-overview.md index 25b7d46af9..c0adee3bdb 100644 --- a/content/en/docs/reference/using-api/api-overview.md +++ b/content/en/docs/reference/using-api/api-overview.md @@ -33,7 +33,7 @@ if you are writing an application using the Kubernetes API. To eliminate fields or restructure resource representations, Kubernetes supports multiple API versions, each at a different API path. For example: `/api/v1` or -`/apis/extensions/v1beta1`. +`/apis/rbac.authorization.k8s.io/v1alpha1`. The version is set at the API level rather than at the resource or field level to: @@ -106,10 +106,3 @@ When you enable or disable groups or resources, you need to restart the apiserve to pick up the `--runtime-config` changes. {{< /note >}} -## Enabling specific resources in the extensions/v1beta1 group - -DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies and ReplicaSets in the `extensions/v1beta1` API group are disabled by default. -For example: to enable deployments and daemonsets, set -`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`. - -{{< note >}}Individual resource enablement/disablement is only supported in the `extensions/v1beta1` API group for legacy reasons.{{< /note >}} diff --git a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md index 9288ec3064..a0c68ff682 100644 --- a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md +++ b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md @@ -132,7 +132,7 @@ The following file is an Ingress resource that sends traffic to your Service via 1. Create `example-ingress.yaml` from the following file: - apiVersion: networking.k8s.io/v1beta1 # for versions before 1.14 use extensions/v1beta1 + apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: example-ingress @@ -243,7 +243,7 @@ The following file is an Ingress resource that sends traffic to your Service via Output: ```shell - ingress.extensions/example-ingress configured + ingress.networking/example-ingress configured ``` ## Test Your Ingress diff --git a/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md b/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md index 6fd887bd8f..f333b215a2 100644 --- a/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md +++ b/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md @@ -160,7 +160,7 @@ kubectl scale deployment --replicas=0 dns-autoscaler --namespace=kube-system The output is: - deployment.extensions/dns-autoscaler scaled + deployment.apps/dns-autoscaler scaled Verify that the replica count is zero: From e140c2a6dce466d027331a4be649a99b97f9e33b Mon Sep 17 00:00:00 2001 From: Robert Stoll Date: Mon, 6 Jul 2020 08:09:26 +0200 Subject: [PATCH 08/86] doc(auth): typo --- content/en/docs/reference/access-authn-authz/authentication.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md index 973c605127..582f53dc5f 100644 --- a/content/en/docs/reference/access-authn-authz/authentication.md +++ b/content/en/docs/reference/access-authn-authz/authentication.md @@ -26,7 +26,7 @@ even a file with a list of usernames and passwords. In this regard, _Kubernetes does not have objects which represent normal user accounts._ Normal users cannot be added to a cluster through an API call. -Even though normal user cannot be added via an API call, but any user that presents a valid certificate signed by the cluster’s certificate authority (CA) is considered authenticated. In this configuration, Kubernetes determines the username from the common name field in the ‘subject’ of the cert (e.g., “/CN=bob”). From there, the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation a resource. You can refer to [creating user certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#user-csr) for more details about this. +Even though normal user cannot be added via an API call, but any user that presents a valid certificate signed by the cluster’s certificate authority (CA) is considered authenticated. In this configuration, Kubernetes determines the username from the common name field in the ‘subject’ of the cert (e.g., “/CN=bob”). From there, the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation on a resource. You can refer to [creating user certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#user-csr) for more details about this. In contrast, service accounts are users managed by the Kubernetes API. They are bound to specific namespaces, and created automatically by the API server or From 664d53195e6250ec674af0f53ab7062fd0ddafac Mon Sep 17 00:00:00 2001 From: Muhammad Panji Date: Wed, 8 Jul 2020 06:56:43 +0700 Subject: [PATCH 09/86] ID translation of /docs/tasks/administer-cluster/namespaces --- .../tasks/administer-cluster/namespaces.md | 303 ++++++++++++++++++ 1 file changed, 303 insertions(+) create mode 100644 content/id/docs/tasks/administer-cluster/namespaces.md diff --git a/content/id/docs/tasks/administer-cluster/namespaces.md b/content/id/docs/tasks/administer-cluster/namespaces.md new file mode 100644 index 0000000000..51ec55c3df --- /dev/null +++ b/content/id/docs/tasks/administer-cluster/namespaces.md @@ -0,0 +1,303 @@ +--- +title: Berbagi Klaster dengan Namespaces +content_type: task +--- + + +Halaman ini menunjukkan bagaimana cara melihat, menggunakan dan menghapus {{< glossary_tooltip text="namespaces" term_id="namespace" >}}. Halaman ini juga menunjukkan bagaimana cara menggunakan namespace Kubernetes namespaces untuk membagi klaster kamu. + + +## {{% heading "prerequisites" %}} + +* Memiliki [Klaster Kubernetes](/docs/setup/). +* Memiliki pemahaman dasar _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, dan _[Deployments](/docs/concepts/workloads/controllers/deployment/)_ di Kubernetes. + + + + +## Melihat namespaces + +1. Untuk melihat namespaces yang ada saat ini disebuah klaster anda bisa menggunakan: + +```shell +kubectl get namespaces +``` +``` +NAME STATUS AGE +default Active 11d +kube-system Active 11d +kube-public Active 11d +``` + +Kubernetes berjalan dengan tiga namespaces awal: + + * `default` Namespace bawaan untuk objek-objek yang belum terkait dengan namespace lain + * `kube-system` Namespace untuk objek-objek yang dibuat oleh sistem Kubernetes + * `kube-public` Namespae ini dibuat secara otomatis dan dapat dibaca seluruh pengguna (termasuk yang tidak terotentikasi). Namespace ini sering dicadangkan untuk penggunaan klaster, untuk kasus dimana beberapa sumber daya agar dapat terlihat dan dapat dibaca secara publik di keseluruhan klaster. Aspek publik di namespace ini hanya sebuah konvensi bukan kebutuhan. + +Kamu bisa mendapat ringkasan namespace tertentu menggunakan: + +```shell +kubectl get namespaces +``` + +Atau anda bisa mendapatkan informasi detail menggunakan: + +```shell +kubectl describe namespaces +``` +``` +Name: default +Labels: +Annotations: +Status: Active + +No resource quota. + +Resource Limits + Type Resource Min Max Default + ---- -------- --- --- --- + Container cpu - - 100m +``` + +Sebagai catatan, detail diatas menunjukkan baik kuota sumber daya (apabila ada) dan juga jangkauan batas sumber daya + +Kuota sumber daya melacak penggunaan total sumber daya didalam *Namespace* dan mengijinkan operator-operator klaster mendefinisikan *batas atas* penggunaan sumber daya yang dapat di gunakan sebuah *Namespace*. + +Jangkauan batas mendefinisikan pembatas min/maks jumlah sumber daya yang dapat di gunakan oleh sebuah entitas di sebuah *Namespace*. + +Lihat [Admission control: Limit Range](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) + +Sebuah namespace dapat berada di salah satu dari dua fase: + + * `Active` namespace sedang digunakan + * `Terminating` namespace sedang dihapus dan tidak dapat digunakan untuk objek-objek baru + +Lihat [dokumentasi desain](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#phases) untuk detil lebih lanjut. + +## Membuat sebuah namespace baru + +{{< note >}} + Hindari membuat namespace dengan awalan `kube-`, karena awalan ini dicadangkan untuk namespace sistem Kubernetes. +{{< /note >}} + +1. Buat berkas YAML baru dengan nama `my-namespace.yaml` dengan isi berikut ini: + + ```yaml + apiVersion: v1 + kind: Namespace + metadata: + name: + ``` + Then run: + + ``` + kubectl create -f ./my-namespace.yaml + ``` + +2. Cara alternatif, kamu bisa membuat namespace menggunakan perintah dibawah ini: + + ``` + kubectl create namespace + ``` + +Nama namespace kamu harus merupakan +[DNS label](/docs/concepts/overview/working-with-objects/names#dns-label-names) yang valid. + +Ada kolom opsional `finalizers`, yang memungkinkan _obvservables_ untuk membersihkan sumber daya ketika namespace dihapus. Ingat bahwa jika kamu memberikan finalizer yang tidak ada, namespace akan dibuat tapi akan macet di status `Terminating` jika pengguna mencoba untuk menghapusnya. + +Informasi lebih lanjut mengenai `finalizers` bisa dibaca di [dokumentasi desain](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#finalizers) namespace. + +## Menghapus namespace + +Hapus namespace dengan + +```shell +kubectl delete namespaces +``` + +{{< warning >}} +Ini akan menghapus _semua hal_ di dalam namespace! +{{< /warning >}} + +Proses penghapusan ini asinkrin, jadi untuk beberapa waktu kamu akan melihat namespace dalam status `Terminating`. + +## Membagi klaster kamu menggunakan namespace Kubernetes + +1. Pahami namespace bawaan + + Secara bawaan, sebuah klaster Kubernetes akan membuat namespace bawaan ketika menyediakan klaster untuk menampung Pod, Services, dan Deployment yang digunakan oleh klaster. + + Dengan asumsi kamu memiliki klaster baru, kamu bisa mengecek namespace yang tersedia dengan melakukan hal berikut: + + ```shell + kubectl get namespaces + ``` + ``` + NAME STATUS AGE + default Active 13m + ``` + +2. Membuat namespace baru + + Untuk latihan ini, kita akan membuat dua namespace Kubernetes tambahan untuk menyimpan konten kita + + Dalam sebuah skenario dimana sebuah organisasi menggunakan klaster Kuberetes yang digunakan bersama untuk pengguaan _development_ dan _production_: + + Tim pengembang ingin mengelola ruang di dalam klaster dimana mereka bisa melihat daftar Pod, Layanan, dan Deployment yang digunakan untuk membangun dan menjalankan apliksi mereka. Di ruang ini sumber daya akan datang dan prgi dan pembatasan mengenai siapa bisa atau tidak bisa memodifikasi sumber daya lebih santai untuk mendukung pengembangan secara _agile_. + + Tim operasi ingin mengelola ruang didalam klaster dimana mereka bisa memaksakan prosedur ketat mengenai siapa yang bisa atau tidak bisa melakukan manipulasi kumpulan Pod, Layanan, dan Deployment yang berjalan di situs _production_. + + Satu pola yang bisa diikuti organisasi ini adalah dengan membagi klaster Kubernetes menjadi dua namespace: `development` dan `production` + + Mari kita buat dua namespace untuk menyimpan hasil kerja kita. + + Buat namespace `development` menggunakan kubectl: + + ```shell + kubectl create -f https://k8s.io/examples/admin/namespace-dev.json + ``` + + Kemudian mari kita buat namespace `production` menggunakan kubectl: + + ```shell + kubectl create -f https://k8s.io/examples/admin/namespace-prod.json + ``` + + Untuk memastikan apa yang kita lakukan benar, lihat seluruh namespace didalam klaster. + + ```shell + kubectl get namespaces --show-labels + ``` + ``` + NAME STATUS AGE LABELS + default Active 32m + development Active 29s name=development + production Active 23s name=production + ``` + +3. Buat pod di tiap namespace + + Sebuah namespace Kubernetes memberikan batasan untuk Pods, Layanan, dan Deployment di dalam klaster. + + Pengguna yang berinteraksi dengan salah satu namespace tidak melihat konten di dalam namespace lain + + Untuk menunjukkan hal ini, Mari kita jalankan Deployment dan Pods sederhana di dalam namespace `development`. + + ```shell + kubectl create deployment snowflake --image=k8s.gcr.io/serve_hostname -n=development + kubectl scale deployment snowflake --replicas=2 -n=development + ``` + Kita baru aja membuat sebuah deployment yang memiliki ukuran replika 2 menjalankan pod dengan nama `snowflake` dengan sebuah kontainer dasar yang hanya melayani hostname. + + + ```shell + kubectl get deployment -n=development + ``` + ``` + NAME READY UP-TO-DATE AVAILABLE AGE + snowflake 2/2 2 2 2m + ``` + ```shell + kubectl get pods -l app=snowflake -n=development + ``` + ``` + NAME READY STATUS RESTARTS AGE + snowflake-3968820950-9dgr8 1/1 Running 0 2m + snowflake-3968820950-vgc4n 1/1 Running 0 2m + ``` + + Dan ini keren, pengembang bisa melakukan hal yang ingin mereka lakukan dan mereka tidak harus khawatir akan mempengaruhi konten di namespace `production`. + + Mari kita pindah ke namespace `production` dan menujukkan bagaimana sumber daya di satu namespace disembunyikan dari yang lain + + Namespace `production` seharusnya kosong, dan perintah berikut ini seharunsnya tidak mengembalikan apapun. + + ```shell + kubectl get deployment -n=production + kubectl get pods -n=production + ``` + + Production ingin menjalankan cattle, mari kita buat beberapa pod cattle. + + ```shell + kubectl create deployment cattle --image=k8s.gcr.io/serve_hostname -n=production + kubectl scale deployment cattle --replicas=5 -n=production + + kubectl get deployment -n=production + ``` + ``` + NAME READY UP-TO-DATE AVAILABLE AGE + cattle 5/5 5 5 10s + ``` + + ```shell + kubectl get pods -l app=cattle -n=production + ``` + ``` + NAME READY STATUS RESTARTS AGE + cattle-2263376956-41xy6 1/1 Running 0 34s + cattle-2263376956-kw466 1/1 Running 0 34s + cattle-2263376956-n4v97 1/1 Running 0 34s + cattle-2263376956-p5p3i 1/1 Running 0 34s + cattle-2263376956-sxpth 1/1 Running 0 34s + ``` + +Sampai titik ini, seharusnya sudah jelas bahwa sumber daya yang dibuat pengguna di sebuah namespace disembunyikan dari namespace lainnya + +Seiring dengan evolusi dukungan kebijakan di kubernetes, kami akan memperluas skenario ini untuk menunjukkan bagaimana kamu bisa menyediakan aturan otorisasi yang berbeda untuk tiap namespace. + + + + +## Memahami motivasi penggunaan namespace + +Sebuah klaster tunggal umumnya bisa memenuhi kebutuhan pengguna yang berbeda atau kelompok pengguna (itulah sebabnya disebut 'komunitas pengguna'). + +_namespace_ Kubernetes membantu proyek-proyek, tim-tim dan pelanggan yang berbeda untuk berbagi klaster Kubernetes. + +Ini dilakukan dengan menyediakan hal berikut: + +1. Cakupan untuk [Names](/docs/concepts/overview/working-with-objects/names/). +2. Sebuah mekanisme untuk memasang otorisasi dan kebijakan untuk bagian dari klaster. + +Penggunaan namespace berbeda merupakan hal opsional. + +Tiap komunitas pengguna ingin bisa bekerja secara terisolasi dari komunitas lainnya. + +Tiap komunitas pengguna memiliki hal berikut sendiri: + +1. sumber daya (pods, services, pengendali replikasi, dll.) +2. kebijakan (siapa yang bisa atau tidak bisa melakukan hal tertentu di komunitasnya) +3. batasan (komunitas ini diberi kuota sekian, dll.) + +Seorang operator klaster dapat membuat sebuah Namespace untuk tiap komunitas user unik. + +Namespace tersebut memberikan cakupan unik untuk: + +1. sumber daya yang diberi nama (untuk menghindari benturan penamaan mendasar) +2. otoritas pengelolaan terdelegasi untuk pengguna yang dipercaya +3. kemampuan untuk membatasi konsumsi sumber daya komunitas + +Contoh penggunaan mencakup + +1. Sebagai operator klaster, aku ingin mendukung beberapa komunitas pengguna di sebuah klaster. +2. Sebagai operator klaster, aku ingin mendelegasikan otoritas untuk mempartisi klaster ke pengguna terpercaya di komunitasnya. +3. Sebagai operator klaster, aku ingin membatasi jumlah sumberdaya yang bisa dikonsumsi komunitas dalam rangka membatasi dampak ke komunitas lain yang menggunakan klaster yang sama. +4. Sebagai pengguna klaster, aku ingin berinteraks dengan sumber daya yang berkaitan dengan komunitas penggunaku secara terisolasi dari apa yang dilakukan komunitas lain di klaster yang sama. + +## Memahami namespace dan DNS + +Ketika kamu membuat sebuah [Layanan](/docs/concepts/services-networking/service/), akan terbentuk [entri DNS](/docs/concepts/services-networking/dns-pod-service/) untuk layanan tersebut. +Entri DNS ini dalam bentuk `..svc.cluster.local`, yang berarti jika sebuah kontainer hanya menggunakan `` makan dia akan me-_resolve_ ke layanan yang lokal dalam namespace yang sama. Ini berguna untuk menggunakan konfigurasi yang sama di namespace yang berbeda seperti _Development_, _Staging_ dan _Production_. Jika kami ingin menjangkau lintas namespace, kamu harus menggunakan _fully qualified domain name_ (FQDN). + + + +## {{% heading "whatsnext" %}} + +* Pelajari lebih lanjut mengenai [pengaturan preferensi namespace preference](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-preference). +* Pelajari lebih lanjut mengenai [pengaturan namespace untuk sebuah permintaan](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-for-a-request) +* Baca [desain namespaces](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/architecture/namespaces.md). + + + From ff92bc9c85097993cd4986e01ce9d665dabdb69d Mon Sep 17 00:00:00 2001 From: Muhammad Panji Date: Thu, 9 Jul 2020 08:26:17 +0700 Subject: [PATCH 10/86] Apply suggestions from code review Co-authored-by: Aris Cahyadi Risdianto --- .../tasks/administer-cluster/namespaces.md | 147 +++++++++--------- 1 file changed, 73 insertions(+), 74 deletions(-) diff --git a/content/id/docs/tasks/administer-cluster/namespaces.md b/content/id/docs/tasks/administer-cluster/namespaces.md index 51ec55c3df..4d8baea5e9 100644 --- a/content/id/docs/tasks/administer-cluster/namespaces.md +++ b/content/id/docs/tasks/administer-cluster/namespaces.md @@ -1,23 +1,23 @@ --- -title: Berbagi Klaster dengan Namespaces +title: Membagi sebuah Klaster dengan Namespace content_type: task --- -Halaman ini menunjukkan bagaimana cara melihat, menggunakan dan menghapus {{< glossary_tooltip text="namespaces" term_id="namespace" >}}. Halaman ini juga menunjukkan bagaimana cara menggunakan namespace Kubernetes namespaces untuk membagi klaster kamu. +Laman ini menunjukkan bagaimana cara melihat, menggunakan dan menghapus {{< glossary_tooltip text="namespaces" term_id="namespace" >}}. Laman ini juga menunjukkan bagaimana cara menggunakan Namespace Kubernetes namespaces untuk membagi klaster kamu. ## {{% heading "prerequisites" %}} -* Memiliki [Klaster Kubernetes](/docs/setup/). -* Memiliki pemahaman dasar _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, dan _[Deployments](/docs/concepts/workloads/controllers/deployment/)_ di Kubernetes. +* Memiliki [Klaster Kubernetes](/id/docs/setup/). +* Memiliki pemahaman dasar [_Pod_](/id/docs/concepts/workloads/pods/pod/), [_Service_](/id/docs/concepts/services-networking/service/), dan [_Deployment_](/id/docs/concepts/workloads/controllers/deployment/) dalam Kubernetes. -## Melihat namespaces +## Melihat Namespace -1. Untuk melihat namespaces yang ada saat ini disebuah klaster anda bisa menggunakan: +1. Untuk melihat Namespace yang ada saat ini pada sebuah klaster anda bisa menggunakan: ```shell kubectl get namespaces @@ -29,19 +29,19 @@ kube-system Active 11d kube-public Active 11d ``` -Kubernetes berjalan dengan tiga namespaces awal: +Kubernetes mulai dengan tiga Namespace pertama: - * `default` Namespace bawaan untuk objek-objek yang belum terkait dengan namespace lain + * `default` Namespace bawaan untuk objek-objek yang belum terkait dengan Namespace lain * `kube-system` Namespace untuk objek-objek yang dibuat oleh sistem Kubernetes - * `kube-public` Namespae ini dibuat secara otomatis dan dapat dibaca seluruh pengguna (termasuk yang tidak terotentikasi). Namespace ini sering dicadangkan untuk penggunaan klaster, untuk kasus dimana beberapa sumber daya agar dapat terlihat dan dapat dibaca secara publik di keseluruhan klaster. Aspek publik di namespace ini hanya sebuah konvensi bukan kebutuhan. + * `kube-public` Namespace ini dibuat secara otomatis dan dapat dibaca oleh seluruh pengguna (termasuk yang tidak terotentikasi). Namespace ini sering dicadangkan untuk kepentingan klaster, untuk kasus dimana beberapa sumber daya seharusnya dapat terlihat dan dapat terlihat secara publik di seluruh klaster. Aspek publik pada Namespace ini hanya sebuah konvensi bukan suatu kebutuhan. -Kamu bisa mendapat ringkasan namespace tertentu menggunakan: +Kamu bisa mendapat ringkasan Namespace tertentu dengan menggunakan: ```shell kubectl get namespaces ``` -Atau anda bisa mendapatkan informasi detail menggunakan: +Atau kamu bisa mendapatkan informasi detail menggunakan: ```shell kubectl describe namespaces @@ -60,25 +60,25 @@ Resource Limits Container cpu - - 100m ``` -Sebagai catatan, detail diatas menunjukkan baik kuota sumber daya (apabila ada) dan juga jangkauan batas sumber daya +Sebagai catatan, detail diatas menunjukkan baik kuota sumber daya (jika ada) dan juga jangkauan batas sumber daya. -Kuota sumber daya melacak penggunaan total sumber daya didalam *Namespace* dan mengijinkan operator-operator klaster mendefinisikan *batas atas* penggunaan sumber daya yang dapat di gunakan sebuah *Namespace*. +Kuota sumber daya melacak penggunaan total sumber daya didalam Namespace dan mengijinkan operator-operator klaster mendefinisikan batas atas penggunaan sumber daya yang dapat di gunakan sebuah Namespace. -Jangkauan batas mendefinisikan pembatas min/maks jumlah sumber daya yang dapat di gunakan oleh sebuah entitas di sebuah *Namespace*. +Jangkauan batas mendefinisikan pertimbangan min/maks jumlah sumber daya yang dapat di gunakan oleh sebuah entitas dalam sebuah Namespace. -Lihat [Admission control: Limit Range](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) +Lihatlah [Kontrol Admisi: Rentang Batas](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) -Sebuah namespace dapat berada di salah satu dari dua fase: +Sebuah Namespace dapat berada dalam salah satu dari dua buah fase: - * `Active` namespace sedang digunakan - * `Terminating` namespace sedang dihapus dan tidak dapat digunakan untuk objek-objek baru + * `Active` Namespace sedang digunakan + * `Terminating` Namespace sedang dihapus dan tidak dapat digunakan untuk objek-objek baru Lihat [dokumentasi desain](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#phases) untuk detil lebih lanjut. -## Membuat sebuah namespace baru +## Membuat sebuah Namespace baru {{< note >}} - Hindari membuat namespace dengan awalan `kube-`, karena awalan ini dicadangkan untuk namespace sistem Kubernetes. + Hindari membuat Namespace dengan awalan `kube-`, karena awalan ini dicadangkan untuk Namespace dari sistem Kubernetes. {{< /note >}} 1. Buat berkas YAML baru dengan nama `my-namespace.yaml` dengan isi berikut ini: @@ -95,40 +95,40 @@ Lihat [dokumentasi desain](https://git.k8s.io/community/contributors/design-prop kubectl create -f ./my-namespace.yaml ``` -2. Cara alternatif, kamu bisa membuat namespace menggunakan perintah dibawah ini: +2. Sebagai alternatif, kamu bisa membuat Namespace menggunakan perintah dibawah ini: ``` kubectl create namespace ``` -Nama namespace kamu harus merupakan -[DNS label](/docs/concepts/overview/working-with-objects/names#dns-label-names) yang valid. +Nama Namespace kamu harus merupakan +[Label DNS](/docs/concepts/overview/working-with-objects/names#dns-label-names) yang valid. -Ada kolom opsional `finalizers`, yang memungkinkan _obvservables_ untuk membersihkan sumber daya ketika namespace dihapus. Ingat bahwa jika kamu memberikan finalizer yang tidak ada, namespace akan dibuat tapi akan macet di status `Terminating` jika pengguna mencoba untuk menghapusnya. +Ada kolom opsional `finalizers`, yang memungkinkan _observables_ untuk membersihkan sumber daya ketika Namespace dihapus. Ingat bahwa jika kamu memberikan finalizer yang tidak ada, Namespace akan dibuat tapi akan berhenti pada status `Terminating` jika pengguna mencoba untuk menghapusnya. -Informasi lebih lanjut mengenai `finalizers` bisa dibaca di [dokumentasi desain](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#finalizers) namespace. +Informasi lebih lanjut mengenai `finalizers` bisa dibaca pada [dokumentasi desain](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#finalizers) dari Namespace. -## Menghapus namespace +## Menghapus Namespace -Hapus namespace dengan +Hapus Namespace dengan ```shell kubectl delete namespaces ``` {{< warning >}} -Ini akan menghapus _semua hal_ di dalam namespace! +Ini akan menghapus semua hal yang ada dalam Namespace! {{< /warning >}} -Proses penghapusan ini asinkrin, jadi untuk beberapa waktu kamu akan melihat namespace dalam status `Terminating`. +Proses penghapusan ini asinkron, jadi untuk beberapa waktu kamu akan melihat Namespace dalam status `Terminating`. -## Membagi klaster kamu menggunakan namespace Kubernetes +## Membagi klaster kamu menggunakan Namespace Kubernetes -1. Pahami namespace bawaan +1. Pahami Namespace bawaan - Secara bawaan, sebuah klaster Kubernetes akan membuat namespace bawaan ketika menyediakan klaster untuk menampung Pod, Services, dan Deployment yang digunakan oleh klaster. + Secara bawaan, sebuah klaster Kubernetes akan membuat Namespace bawaan ketika menyediakan klaster untuk menampung Pod, Service, dan Deployment yang digunakan oleh klaster. - Dengan asumsi kamu memiliki klaster baru, kamu bisa mengecek namespace yang tersedia dengan melakukan hal berikut: + Dengan asumsi kamu memiliki klaster baru, kamu bisa mengecek Namespace yang tersedia dengan melakukan hal berikut: ```shell kubectl get namespaces @@ -138,33 +138,33 @@ Proses penghapusan ini asinkrin, jadi untuk beberapa waktu kamu akan melihat nam default Active 13m ``` -2. Membuat namespace baru +2. Membuat Namespace baru - Untuk latihan ini, kita akan membuat dua namespace Kubernetes tambahan untuk menyimpan konten kita + Untuk latihan ini, kita akan membuat dua Namespace Kubernetes tambahan untuk menyimpan konten kita - Dalam sebuah skenario dimana sebuah organisasi menggunakan klaster Kuberetes yang digunakan bersama untuk pengguaan _development_ dan _production_: + Dalam sebuah skenario dimana sebuah organisasi menggunakan klaster Kubernetes yang digunakan bersama untuk penggunaan pengembangan dan produksi: - Tim pengembang ingin mengelola ruang di dalam klaster dimana mereka bisa melihat daftar Pod, Layanan, dan Deployment yang digunakan untuk membangun dan menjalankan apliksi mereka. Di ruang ini sumber daya akan datang dan prgi dan pembatasan mengenai siapa bisa atau tidak bisa memodifikasi sumber daya lebih santai untuk mendukung pengembangan secara _agile_. + Tim pengembang ingin mengelola ruang di dalam klaster dimana mereka bisa melihat daftar Pod, Service, dan Deployment yang digunakan untuk membangun dan menjalankan apliksi mereka. Di ruang ini sumber daya akan datang dan pergi, dan pembatasan yang tidak ketat mengenai siapa yang bisa atau tidak bisa memodifikasi sumber daya untuk mendukung pengembangan secara gesit (_agile_). - Tim operasi ingin mengelola ruang didalam klaster dimana mereka bisa memaksakan prosedur ketat mengenai siapa yang bisa atau tidak bisa melakukan manipulasi kumpulan Pod, Layanan, dan Deployment yang berjalan di situs _production_. + Tim operasi ingin mengelola ruang didalam klaster dimana mereka bisa memaksakan prosedur ketat mengenai siapa yang bisa atau tidak bisa melakukan manipulasi pada kumpulan Pod, Layanan, dan Deployment yang berjalan pada situs produksi. - Satu pola yang bisa diikuti organisasi ini adalah dengan membagi klaster Kubernetes menjadi dua namespace: `development` dan `production` + Satu pola yang bisa diikuti organisasi ini adalah dengan membagi klaster Kubernetes menjadi dua Namespace: `development` dan `production` - Mari kita buat dua namespace untuk menyimpan hasil kerja kita. + Mari kita buat dua Namespace untuk menyimpan hasil kerja kita. - Buat namespace `development` menggunakan kubectl: + Buat Namespace `development` menggunakan kubectl: ```shell kubectl create -f https://k8s.io/examples/admin/namespace-dev.json ``` - Kemudian mari kita buat namespace `production` menggunakan kubectl: + Kemudian mari kita buat Namespace `production` menggunakan kubectl: ```shell kubectl create -f https://k8s.io/examples/admin/namespace-prod.json ``` - Untuk memastikan apa yang kita lakukan benar, lihat seluruh namespace didalam klaster. + Untuk memastikan apa yang kita lakukan benar, lihat seluruh Namespace dalam klaster. ```shell kubectl get namespaces --show-labels @@ -176,19 +176,19 @@ Proses penghapusan ini asinkrin, jadi untuk beberapa waktu kamu akan melihat nam production Active 23s name=production ``` -3. Buat pod di tiap namespace +3. Buat pod pada setiap Namespace - Sebuah namespace Kubernetes memberikan batasan untuk Pods, Layanan, dan Deployment di dalam klaster. + Sebuah Namespace Kubernetes memberikan batasan untuk Pod, Service, dan Deployment dalam klaster. - Pengguna yang berinteraksi dengan salah satu namespace tidak melihat konten di dalam namespace lain + Pengguna yang berinteraksi dengan salah satu Namespace tidak melihat konten di dalam Namespace lain - Untuk menunjukkan hal ini, Mari kita jalankan Deployment dan Pods sederhana di dalam namespace `development`. + Untuk menunjukkan hal ini, mari kita jalankan Deployment dan Pod sederhana di dalam Namespace `development`. ```shell kubectl create deployment snowflake --image=k8s.gcr.io/serve_hostname -n=development kubectl scale deployment snowflake --replicas=2 -n=development ``` - Kita baru aja membuat sebuah deployment yang memiliki ukuran replika 2 menjalankan pod dengan nama `snowflake` dengan sebuah kontainer dasar yang hanya melayani hostname. + Kita baru aja membuat sebuah Deployment yang memiliki ukuran replika dua yang menjalankan Pod dengan nama `snowflake` dengan sebuah Container dasar yang hanya melayani _hostname_. ```shell @@ -207,18 +207,18 @@ Proses penghapusan ini asinkrin, jadi untuk beberapa waktu kamu akan melihat nam snowflake-3968820950-vgc4n 1/1 Running 0 2m ``` - Dan ini keren, pengembang bisa melakukan hal yang ingin mereka lakukan dan mereka tidak harus khawatir akan mempengaruhi konten di namespace `production`. + Dan ini merupakan sesuatu yang bagus, dimana pengembang bisa melakukan hal yang ingin mereka lakukan tanpa harus khawatir hal itu akan mempengaruhi konten pada namespace `production`. - Mari kita pindah ke namespace `production` dan menujukkan bagaimana sumber daya di satu namespace disembunyikan dari yang lain + Mari kita pindah ke Namespace `production` dan menujukkan bagaimana sumber daya di satu Namespace disembunyikan dari yang lain - Namespace `production` seharusnya kosong, dan perintah berikut ini seharunsnya tidak mengembalikan apapun. + Namespace `production` seharusnya kosong, dan perintah berikut ini seharusnya tidak menghasilkan apapun. ```shell kubectl get deployment -n=production kubectl get pods -n=production ``` - Production ingin menjalankan cattle, mari kita buat beberapa pod cattle. + `Production` Namespace ingin menjalankan `cattle`, mari kita buat beberapa Pod `cattle`. ```shell kubectl create deployment cattle --image=k8s.gcr.io/serve_hostname -n=production @@ -243,61 +243,60 @@ Proses penghapusan ini asinkrin, jadi untuk beberapa waktu kamu akan melihat nam cattle-2263376956-sxpth 1/1 Running 0 34s ``` -Sampai titik ini, seharusnya sudah jelas bahwa sumber daya yang dibuat pengguna di sebuah namespace disembunyikan dari namespace lainnya +Sampai sini, seharusnya sudah jelas bahwa sumber daya yang dibuat pengguna pada sebuah Namespace disembunyikan dari Namespace lainnya. -Seiring dengan evolusi dukungan kebijakan di kubernetes, kami akan memperluas skenario ini untuk menunjukkan bagaimana kamu bisa menyediakan aturan otorisasi yang berbeda untuk tiap namespace. +Seiring dengan evolusi dukungan kebijakan di Kubernetes, kami akan memperluas skenario ini untuk menunjukkan bagaimana kamu bisa menyediakan aturan otorisasi yang berbeda untuk tiap Namespace. -## Memahami motivasi penggunaan namespace +## Memahami motivasi penggunaan Namespace Sebuah klaster tunggal umumnya bisa memenuhi kebutuhan pengguna yang berbeda atau kelompok pengguna (itulah sebabnya disebut 'komunitas pengguna'). -_namespace_ Kubernetes membantu proyek-proyek, tim-tim dan pelanggan yang berbeda untuk berbagi klaster Kubernetes. +Namespace Kubernetes membantu proyek-proyek, tim-tim dan pelanggan yang berbeda untuk berbagi klaster Kubernetes. Ini dilakukan dengan menyediakan hal berikut: -1. Cakupan untuk [Names](/docs/concepts/overview/working-with-objects/names/). +1. Cakupan untuk [Names](/id/docs/concepts/overview/working-with-objects/names/). 2. Sebuah mekanisme untuk memasang otorisasi dan kebijakan untuk bagian dari klaster. -Penggunaan namespace berbeda merupakan hal opsional. +Penggunaan Namespace berbeda merupakan hal opsional. Tiap komunitas pengguna ingin bisa bekerja secara terisolasi dari komunitas lainnya. Tiap komunitas pengguna memiliki hal berikut sendiri: -1. sumber daya (pods, services, pengendali replikasi, dll.) -2. kebijakan (siapa yang bisa atau tidak bisa melakukan hal tertentu di komunitasnya) +1. sumber daya (Pod, Service, _controller_ replikasi, dll.) +2. kebijakan (siapa yang bisa atau tidak bisa melakukan hal tertentu dalam komunitasnya) 3. batasan (komunitas ini diberi kuota sekian, dll.) -Seorang operator klaster dapat membuat sebuah Namespace untuk tiap komunitas user unik. +Seorang operator klaster dapat membuat sebuah Namespace untuk tiap komunitas user yang unik. -Namespace tersebut memberikan cakupan unik untuk: +Namespace tersebut memberikan cakupan yang unik untuk: -1. sumber daya yang diberi nama (untuk menghindari benturan penamaan mendasar) -2. otoritas pengelolaan terdelegasi untuk pengguna yang dipercaya +1. penamaan sumber daya (untuk menghindari benturan penamaan dasar) +2. pendelegasian otoritas pengelolaan untuk pengguna yang dapat dipercaya 3. kemampuan untuk membatasi konsumsi sumber daya komunitas Contoh penggunaan mencakup -1. Sebagai operator klaster, aku ingin mendukung beberapa komunitas pengguna di sebuah klaster. +1. Sebagai operator klaster, aku ingin mendukung beberapa komunitas pengguna dalam sebuah klaster. 2. Sebagai operator klaster, aku ingin mendelegasikan otoritas untuk mempartisi klaster ke pengguna terpercaya di komunitasnya. -3. Sebagai operator klaster, aku ingin membatasi jumlah sumberdaya yang bisa dikonsumsi komunitas dalam rangka membatasi dampak ke komunitas lain yang menggunakan klaster yang sama. -4. Sebagai pengguna klaster, aku ingin berinteraks dengan sumber daya yang berkaitan dengan komunitas penggunaku secara terisolasi dari apa yang dilakukan komunitas lain di klaster yang sama. +3. Sebagai operator klaster, aku ingin membatasi jumlah sumber daya yang bisa dikonsumsi komunitas dalam rangka membatasi dampak ke komunitas lain yang menggunakan klaster yang sama. +4. Sebagai pengguna klaster, aku ingin berinteraksi dengan sumber daya yang berkaitan dengan komunitas pengguna saya secara terisolasi dari apa yang dilakukan komunitas lain di klaster yang sama. -## Memahami namespace dan DNS +## Memahami Namespace dan DNS -Ketika kamu membuat sebuah [Layanan](/docs/concepts/services-networking/service/), akan terbentuk [entri DNS](/docs/concepts/services-networking/dns-pod-service/) untuk layanan tersebut. -Entri DNS ini dalam bentuk `..svc.cluster.local`, yang berarti jika sebuah kontainer hanya menggunakan `` makan dia akan me-_resolve_ ke layanan yang lokal dalam namespace yang sama. Ini berguna untuk menggunakan konfigurasi yang sama di namespace yang berbeda seperti _Development_, _Staging_ dan _Production_. Jika kami ingin menjangkau lintas namespace, kamu harus menggunakan _fully qualified domain name_ (FQDN). +Ketika kamu membuat sebuah [Service](/docs/concepts/services-networking/service/), akan terbentuk [entri DNS](/id/docs/concepts/services-networking/dns-pod-service/) untuk Service tersebut. +Entri DNS ini dalam bentuk `..svc.cluster.local`, yang berarti jika sebuah Container hanya menggunakan `` maka dia akan me-_resolve_ ke layanan yang lokal dalam Namespace yang sama. Ini berguna untuk menggunakan konfigurasi yang sama pada Namespace yang berbeda seperti _Development_, _Staging_ dan _Production_. Jika kami ingin menjangkau antar Namespace, kamu harus menggunakan _fully qualified domain name_ (FQDN). ## {{% heading "whatsnext" %}} -* Pelajari lebih lanjut mengenai [pengaturan preferensi namespace preference](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-preference). -* Pelajari lebih lanjut mengenai [pengaturan namespace untuk sebuah permintaan](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-for-a-request) -* Baca [desain namespaces](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/architecture/namespaces.md). - +* Pelajari lebih lanjut mengenai [pengaturan preferensi Namespace](/id/docs/concepts/overview/working-with-objects/namespaces/#pengaturan-preferensi-namespace). +* Pelajari lebih lanjut mengenai [pengaturan namespace untuk sebuah permintaan](/id/docs/concepts/overview/working-with-objects/namespaces/#pengaturan-namespace-untuk-sebuah-permintaan) +* Baca [desain Namespace](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/architecture/namespaces.md). From d01f716f8eec890297e8267711e39c432e4eba76 Mon Sep 17 00:00:00 2001 From: Muhammad Panji Date: Fri, 10 Jul 2020 04:36:05 +0700 Subject: [PATCH 11/86] Apply suggestions from code review --- content/id/docs/tasks/administer-cluster/namespaces.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/id/docs/tasks/administer-cluster/namespaces.md b/content/id/docs/tasks/administer-cluster/namespaces.md index 4d8baea5e9..409e42dd70 100644 --- a/content/id/docs/tasks/administer-cluster/namespaces.md +++ b/content/id/docs/tasks/administer-cluster/namespaces.md @@ -87,7 +87,7 @@ Lihat [dokumentasi desain](https://git.k8s.io/community/contributors/design-prop apiVersion: v1 kind: Namespace metadata: - name: + name: ``` Then run: @@ -98,7 +98,7 @@ Lihat [dokumentasi desain](https://git.k8s.io/community/contributors/design-prop 2. Sebagai alternatif, kamu bisa membuat Namespace menggunakan perintah dibawah ini: ``` - kubectl create namespace + kubectl create namespace ``` Nama Namespace kamu harus merupakan @@ -267,7 +267,7 @@ Tiap komunitas pengguna ingin bisa bekerja secara terisolasi dari komunitas lain Tiap komunitas pengguna memiliki hal berikut sendiri: -1. sumber daya (Pod, Service, _controller_ replikasi, dll.) +1. sumber daya (Pod, Service, ReplicationController, dll.) 2. kebijakan (siapa yang bisa atau tidak bisa melakukan hal tertentu dalam komunitasnya) 3. batasan (komunitas ini diberi kuota sekian, dll.) From 0c799ef757368c8839a912df5d949fa2603042f5 Mon Sep 17 00:00:00 2001 From: Gede Wahyu Date: Fri, 10 Jul 2020 22:24:05 +0700 Subject: [PATCH 12/86] Replace EN links to ID links --- content/id/docs/concepts/_index.md | 20 +++++------ .../docs/concepts/architecture/controller.md | 6 ++-- .../id/docs/concepts/architecture/nodes.md | 14 ++++---- .../concepts/cluster-administration/addons.md | 2 +- .../cluster-administration/certificates.md | 2 +- .../cluster-administration/cloud-providers.md | 2 +- .../cluster-administration-overview.md | 14 ++++---- .../cluster-administration/federation.md | 2 +- .../cluster-administration/logging.md | 2 +- .../manage-deployment.md | 10 +++--- .../cluster-administration/networking.md | 8 ++--- .../cluster-administration/proxies.md | 6 ++-- .../concepts/configuration/assign-pod-node.md | 6 ++-- .../manage-compute-resources-container.md | 10 +++--- .../organize-cluster-access-kubeconfig.md | 6 ++-- .../docs/concepts/configuration/overview.md | 22 ++++++------ .../concepts/configuration/pod-overhead.md | 4 +-- .../configuration/pod-priority-preemption.md | 6 ++-- .../id/docs/concepts/configuration/secret.md | 10 +++--- .../configuration/taint-and-toleration.md | 8 ++--- .../containers/container-environment.md | 4 +-- .../containers/container-lifecycle-hooks.md | 4 +-- content/id/docs/concepts/containers/images.md | 8 ++--- .../id/docs/concepts/containers/overview.md | 2 +- .../docs/concepts/containers/runtime-class.md | 4 +-- .../api-extension/custom-resources.md | 16 ++++----- .../compute-storage-net/device-plugins.md | 2 +- .../extend-kubernetes/extend-cluster.md | 6 ++-- .../concepts/extend-kubernetes/operator.md | 4 +-- .../extend-kubernetes/service-catalog.md | 2 +- .../id/docs/concepts/overview/components.md | 6 ++-- .../declarative-config.md | 8 ++--- .../imperative-command.md | 4 +-- .../imperative-config.md | 4 +-- .../working-with-objects/annotations.md | 2 +- .../working-with-objects/field-selectors.md | 6 ++-- .../kubernetes-objects.md | 4 +-- .../overview/working-with-objects/names.md | 2 +- .../working-with-objects/namespaces.md | 4 +-- .../concepts/policy/pod-security-policy.md | 12 +++---- .../docs/concepts/policy/resource-quotas.md | 12 +++---- .../concepts/scheduling/kube-scheduler.md | 6 ++-- .../scheduling/scheduler-perf-tuning.md | 4 +-- content/id/docs/concepts/security/overview.md | 6 ++-- .../connect-applications-service.md | 8 ++--- .../services-networking/dns-pod-service.md | 2 +- .../services-networking/endpoint-slices.md | 4 +-- .../ingress-controllers.md | 2 +- .../concepts/services-networking/ingress.md | 36 +++++++++---------- .../services-networking/network-policies.md | 2 +- .../services-networking/service-topology.md | 2 +- .../concepts/services-networking/service.md | 18 +++++----- .../concepts/storage/dynamic-provisioning.md | 6 ++-- .../concepts/storage/persistent-volumes.md | 14 ++++---- .../docs/concepts/storage/storage-classes.md | 22 ++++++------ .../concepts/storage/volume-pvc-datasource.md | 2 +- .../storage/volume-snapshot-classes.md | 4 +-- .../docs/concepts/storage/volume-snapshots.md | 10 +++--- content/id/docs/concepts/storage/volumes.md | 16 ++++----- .../workloads/controllers/cron-jobs.md | 4 +-- .../workloads/controllers/daemonset.md | 18 +++++----- .../controllers/jobs-run-to-completion.md | 16 ++++----- .../workloads/controllers/replicaset.md | 12 +++---- .../controllers/replicationcontroller.md | 16 ++++----- .../workloads/controllers/statefulset.md | 16 ++++----- .../workloads/controllers/ttlafterfinished.md | 6 ++-- .../concepts/workloads/pods/disruptions.md | 2 +- .../workloads/pods/ephemeral-containers.md | 2 +- .../workloads/pods/init-containers.md | 4 +-- .../concepts/workloads/pods/pod-lifecycle.md | 14 ++++---- .../concepts/workloads/pods/pod-overview.md | 14 ++++---- .../id/docs/concepts/workloads/pods/pod.md | 18 +++++----- .../docs/concepts/workloads/pods/podpreset.md | 2 +- .../docs/reference/access-authn-authz/rbac.md | 10 +++--- .../id/docs/reference/kubectl/cheatsheet.md | 4 +-- .../tools/kubeadm/create-cluster-kubeadm.md | 14 ++++---- .../tools/kubeadm/install-kubeadm.md | 10 +++--- .../access-cluster.md | 4 +-- .../configure-access-multiple-clusters.md | 4 +-- .../create-external-load-balancer.md | 4 +-- .../web-ui-dashboard.md | 18 +++++----- .../configure-pod-configmap.md | 10 +++--- .../configure-service-account.md | 6 ++-- .../pull-image-private-registry.md | 2 +- .../security-context.md | 2 +- .../job/automated-tasks-with-cron-jobs.md | 8 ++--- .../horizontal-pod-autoscaler.md | 2 +- .../tasks/tls/managing-tls-in-a-cluster.md | 2 +- .../id/docs/tasks/tools/install-kubectl.md | 6 ++-- .../id/docs/tasks/tools/install-minikube.md | 8 ++--- content/id/docs/tutorials/_index.md | 4 +-- content/id/docs/tutorials/hello-minikube.md | 12 +++---- 92 files changed, 357 insertions(+), 357 deletions(-) diff --git a/content/id/docs/concepts/_index.md b/content/id/docs/concepts/_index.md index ebc205d84a..33f4ada445 100644 --- a/content/id/docs/concepts/_index.md +++ b/content/id/docs/concepts/_index.md @@ -49,19 +49,19 @@ untuk penjelasan yang lebih mendetail. Objek mendasar Kubernetes termasuk: -* [Pod](/docs/concepts/workloads/pods/pod-overview/) -* [Service](/docs/concepts/services-networking/service/) -* [Volume](/docs/concepts/storage/volumes/) -* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/) +* [Pod](/id/docs/concepts/workloads/pods/pod-overview/) +* [Service](/id/docs/concepts/services-networking/service/) +* [Volume](/id/docs/concepts/storage/volumes/) +* [Namespace](/id/docs/concepts/overview/working-with-objects/namespaces/) Sebagai tambahan, Kubernetes memiliki beberapa abstraksi yang lebih tinggi yang disebut kontroler. Kontroler merupakan objek mendasar dengan fungsi tambahan, contoh dari kontroler ini adalah: -* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) -* [Deployment](/docs/concepts/workloads/controllers/deployment/) -* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) -* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) -* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) +* [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/) +* [Deployment](/id/docs/concepts/workloads/controllers/deployment/) +* [StatefulSet](/id/docs/concepts/workloads/controllers/statefulset/) +* [DaemonSet](/id/docs/concepts/workloads/controllers/daemonset/) +* [Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/) ## *Control Plane* Kubernetes @@ -95,7 +95,7 @@ dengan *node* secara langsung. #### Metadata objek -* [Anotasi](/docs/concepts/overview/working-with-objects/annotations/) +* [Anotasi](/id/docs/concepts/overview/working-with-objects/annotations/) diff --git a/content/id/docs/concepts/architecture/controller.md b/content/id/docs/concepts/architecture/controller.md index a0ff6b9256..6cf90cf9e6 100644 --- a/content/id/docs/concepts/architecture/controller.md +++ b/content/id/docs/concepts/architecture/controller.md @@ -33,7 +33,7 @@ klaster saat ini mendekati keadaan yang diinginkan. Sebuah _controller_ melacak sekurang-kurangnya satu jenis sumber daya dari Kubernetes. -[objek-objek](/docs/concepts/overview/working-with-objects/kubernetes-objects/) ini +[objek-objek](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/) ini memiliki *spec field* yang merepresentasikan keadaan yang diinginkan. Satu atau lebih _controller_ untuk *resource* tersebut bertanggung jawab untuk membuat keadaan sekarang mendekati keadaan yang diinginkan. @@ -174,6 +174,6 @@ khusus itu lakukan. * Silahkan baca tentang [_control plane_ Kubernetes](/docs/concepts/#kubernetes-control-plane) * Temukan beberapa dasar tentang [objek-objek Kubernetes](/docs/concepts/#kubernetes-objects) -* Pelajari lebih lanjut tentang [Kubernetes API](/docs/concepts/overview/kubernetes-api/) -* Apabila kamu ingin membuat _controller_ sendiri, silakan lihat [pola perluasan](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) dalam memperluas Kubernetes. +* Pelajari lebih lanjut tentang [Kubernetes API](/id/docs/concepts/overview/kubernetes-api/) +* Apabila kamu ingin membuat _controller_ sendiri, silakan lihat [pola perluasan](/id/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) dalam memperluas Kubernetes. diff --git a/content/id/docs/concepts/architecture/nodes.md b/content/id/docs/concepts/architecture/nodes.md index 8913c9df65..ab13cf122a 100644 --- a/content/id/docs/concepts/architecture/nodes.md +++ b/content/id/docs/concepts/architecture/nodes.md @@ -8,8 +8,8 @@ weight: 10 Node merupakan sebuah mesin worker di dalam Kubernetes, yang sebelumnya dinamakan `minion`. Sebuah node bisa berupa VM ataupun mesin fisik, tergantung dari klaster-nya. -Masing-masing node berisi beberapa servis yang berguna untuk menjalankan banyak [pod](/docs/concepts/workloads/pods/pod/) dan diatur oleh komponen-komponen yang dimiliki oleh master. -Servis-servis di dalam sebuah node terdiri dari [runtime kontainer](/docs/concepts/overview/components/#node-components), kubelet dan kube-proxy. +Masing-masing node berisi beberapa servis yang berguna untuk menjalankan banyak [pod](/id/docs/concepts/workloads/pods/pod/) dan diatur oleh komponen-komponen yang dimiliki oleh master. +Servis-servis di dalam sebuah node terdiri dari [runtime kontainer](/id/docs/concepts/overview/components/#node-components), kubelet dan kube-proxy. Untuk lebih detail, lihat dokumentasi desain arsitektur pada [Node Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node). @@ -67,12 +67,12 @@ Pada kasus tertentu ketika node terputus jaringannya, apiserver tidak dapat berk Keputusan untuk menghilangkan pod tidak dapat diberitahukan pada kubelet, sampai komunikasi dengan apiserver terhubung kembali. Sementara itu, pod-pod akan terus berjalan pada node yang sudah terputus, walaupun mendapati schedule untuk dihilangkan. -Pada versi Kubernetes sebelum 1.5, kontroler node dapat menghilangkan dengan paksa ([force delete](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)) pod-pod yang terputus dari apiserver. +Pada versi Kubernetes sebelum 1.5, kontroler node dapat menghilangkan dengan paksa ([force delete](/id/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)) pod-pod yang terputus dari apiserver. Namun, pada versi 1.5 dan seterusnya, kontroler node tidak menghilangkan pod dengan paksa, sampai ada konfirmasi bahwa pod tersebut sudah berhenti jalan di dalam klaster. Pada kasus dimana Kubernetes tidak bisa menarik kesimpulan bahwa ada node yang telah meninggalkan klaster, admin klaster mungkin perlu untuk menghilangkan node secara manual. Menghilangkan obyek node dari Kubernetes akan membuat semua pod yang berjalan pada node tersebut dihilangkan oleh apiserver, dan membebaskan nama-namanya agar bisa digunakan kembali. -Pada versi 1.12, fitur `TaintNodesByCondition` telah dipromosikan ke beta, sehingga kontroler lifecycle node secara otomatis membuat [taints](/docs/concepts/configuration/taint-and-toleration/) yang merepresentasikan conditions. +Pada versi 1.12, fitur `TaintNodesByCondition` telah dipromosikan ke beta, sehingga kontroler lifecycle node secara otomatis membuat [taints](/id/docs/concepts/configuration/taint-and-toleration/) yang merepresentasikan conditions. Akibatnya, scheduler menghiraukan conditions ketika mempertimbangkan sebuah Node; scheduler akan melihat pada taints sebuah Node dan tolerations sebuah Pod. Sekarang, para pengguna dapat memilih antara model scheduling yang lama dan model scheduling yang lebih fleksibel. @@ -93,7 +93,7 @@ Informasi ini dikumpulkan oleh Kubelet di dalam node. ## Manajemen -Tidak seperti [pod](/docs/concepts/workloads/pods/pod/) dan [service](/docs/concepts/services-networking/service/), sebuah node tidaklah dibuat dan dikonfigurasi oleh Kubernetes: tapi node dibuat di luar klaster oleh penyedia layanan cloud, seperti Google Compute Engine, atau pool mesin fisik ataupun virtual (VM) yang kamu punya. +Tidak seperti [pod](/id/docs/concepts/workloads/pods/pod/) dan [service](/id/docs/concepts/services-networking/service/), sebuah node tidaklah dibuat dan dikonfigurasi oleh Kubernetes: tapi node dibuat di luar klaster oleh penyedia layanan cloud, seperti Google Compute Engine, atau pool mesin fisik ataupun virtual (VM) yang kamu punya. Jadi ketika Kubernetes membuat sebuah node, obyek yang merepresentasikan node tersebut akan dibuat. Setelah pembuatan, Kubernetes memeriksa apakah node tersebut valid atau tidak. Contohnya, jika kamu mencoba untuk membuat node dari konten berikut: @@ -164,7 +164,7 @@ Pada kasus ini, kontroler node berasumsi ada masalah pada jaringan master, dan m Mulai dari Kubernetes 1.6, kontroler node juga bertanggung jawab untuk melakukan eviction pada pod-pod yang berjalan di atas node dengan taints `NoExecute`, ketika pod-pod tersebut sudah tidak lagi tolerate terhadap taints. Sebagai tambahan, hal ini di-nonaktifkan secara default pada fitur alpha, kontroler node bertanggung jawab untuk menambahkan taints yang berhubungan dengan masalah pada node, seperti terputus atau `NotReady`. -Lihat [dokumentasi ini](/docs/concepts/configuration/taint-and-toleration/) untuk bahasan detail tentang taints `NoExecute` dan fitur alpha. +Lihat [dokumentasi ini](/id/docs/concepts/configuration/taint-and-toleration/) untuk bahasan detail tentang taints `NoExecute` dan fitur alpha. Mulai dari versi 1.8, kontroler node bisa diatur untuk bertanggung jawab pada pembuatan taints yang merepresentasikan node condition. Ini merupakan fitur alpha untuk versi 1.8. @@ -218,7 +218,7 @@ Jika kamu melakukan [administrasi node manual](#manual-node-administration), mak Scheduler Kubernetes memastikan kalau ada resource yang cukup untuk menjalankan semua pod di dalam sebuah node. Kubernetes memeriksa jumlah semua request untuk kontainer pada sebuah node tidak lebih besar daripada kapasitas node. -Hal ini termasuk semua kontainer yang dijalankan oleh kubelet. Namun, ini tidak termasuk kontainer-kontainer yang dijalankan secara langsung oleh [runtime kontainer](/docs/concepts/overview/components/#node-components) ataupun process yang ada di luar kontainer. +Hal ini termasuk semua kontainer yang dijalankan oleh kubelet. Namun, ini tidak termasuk kontainer-kontainer yang dijalankan secara langsung oleh [runtime kontainer](/id/docs/concepts/overview/components/#node-components) ataupun process yang ada di luar kontainer. Kalau kamu ingin secara eksplisit menyimpan resource cadangan untuk menjalankan process-process selain Pod, ikut tutorial [menyimpan resource cadangan untuk system daemon](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved). diff --git a/content/id/docs/concepts/cluster-administration/addons.md b/content/id/docs/concepts/cluster-administration/addons.md index b404465d8f..ca50347492 100644 --- a/content/id/docs/concepts/cluster-administration/addons.md +++ b/content/id/docs/concepts/cluster-administration/addons.md @@ -32,7 +32,7 @@ Laman ini akan menjabarkan beberapa *add-ons* yang tersedia serta tautan instruk * [Multus](https://github.com/Intel-Corp/multus-cni) merupakan sebuah multi *plugin* agar Kubernetes mendukung multipel jaringan secara bersamaan sehingga dapat menggunakan semua *plugin* CNI (contoh: Calico, Cilium, Contiv, Flannel), ditambah pula dengan SRIOV, DPDK, OVS-DPDK dan VPP pada *workload* Kubernetes. * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) menyediakan integrasi antara VMware NSX-T dan orkestrator kontainer seperti Kubernetes, termasuk juga integrasi antara NSX-T dan platform CaaS/PaaS berbasis kontainer seperti *Pivotal Container Service* (PKS) dan OpenShift. * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) merupakan platform SDN yang menyediakan *policy-based* jaringan antara Kubernetes Pods dan non-Kubernetes *environment* dengan *monitoring* visibilitas dan keamanan. -* [Romana](http://romana.io) merupakan solusi jaringan *Layer* 3 untuk jaringan pod yang juga mendukung [*NetworkPolicy* API](/docs/concepts/services-networking/network-policies/). Instalasi Kubeadm *add-on* ini tersedia [di sini](https://github.com/romana/romana/tree/master/containerize). +* [Romana](http://romana.io) merupakan solusi jaringan *Layer* 3 untuk jaringan pod yang juga mendukung [*NetworkPolicy* API](/id/docs/concepts/services-networking/network-policies/). Instalasi Kubeadm *add-on* ini tersedia [di sini](https://github.com/romana/romana/tree/master/containerize). * [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) menyediakan jaringan serta *policy* jaringan, yang akan membawa kedua sisi dari partisi jaringan, serta tidak membutuhkan basis data eksternal. ## _Service Discovery_ diff --git a/content/id/docs/concepts/cluster-administration/certificates.md b/content/id/docs/concepts/cluster-administration/certificates.md index a605a78547..ee1f91cbeb 100644 --- a/content/id/docs/concepts/cluster-administration/certificates.md +++ b/content/id/docs/concepts/cluster-administration/certificates.md @@ -245,6 +245,6 @@ done. Kamu dapat menggunakan API `Certificate.k8s.io` untuk menyediakan sertifikat x509 yang digunakan untuk autentikasi seperti yang didokumentasikan -[di sini](/docs/tasks/tls/managing-tls-in-a-cluster). +[di sini](/id/docs/tasks/tls/managing-tls-in-a-cluster). diff --git a/content/id/docs/concepts/cluster-administration/cloud-providers.md b/content/id/docs/concepts/cluster-administration/cloud-providers.md index 45820e3660..9a32af1eb8 100644 --- a/content/id/docs/concepts/cluster-administration/cloud-providers.md +++ b/content/id/docs/concepts/cluster-administration/cloud-providers.md @@ -56,7 +56,7 @@ Bagian ini akan menjelaskan semua konfigurasi yang dapat diatur saat menjalankan Penyedia layanan cloud AWS menggunakan nama DNS privat dari *instance* AWS sebagai nama dari objek Kubernetes Node. ### *Load Balancer* -Kamu dapat mengatur [load balancers eksternal](/docs/tasks/access-application-cluster/create-external-load-balancer/) sehingga dapat menggunakan fitur khusus AWS dengan mengatur anotasi seperti di bawah ini. +Kamu dapat mengatur [load balancers eksternal](/id/docs/tasks/access-application-cluster/create-external-load-balancer/) sehingga dapat menggunakan fitur khusus AWS dengan mengatur anotasi seperti di bawah ini. ```yaml apiVersion: v1 diff --git a/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md index b485b5e142..b2bd349908 100644 --- a/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -20,10 +20,10 @@ Lihat panduan di [Persiapan](/docs/setup) untuk mempelajari beberapa contoh tent Sebelum memilih panduan, berikut adalah beberapa hal yang perlu dipertimbangkan: - Apakah kamu hanya ingin mencoba Kubernetes pada komputermu, atau kamu ingin membuat sebuah klaster dengan *high-availability*, *multi-node*? Pilihlah distro yang paling sesuai dengan kebutuhanmu. - - **Jika kamu merencanakan klaster dengan _high-availability_**, pelajari bagaimana cara mengonfigurasi [klaster pada *multiple zone*](/docs/concepts/cluster-administration/federation/). + - **Jika kamu merencanakan klaster dengan _high-availability_**, pelajari bagaimana cara mengonfigurasi [klaster pada *multiple zone*](/id/docs/concepts/cluster-administration/federation/). - Apakah kamu akan menggunakan **Kubernetes klaster di _hosting_**, seperti [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), atau **_hosting_ sendiri klastermu**? - Apakah klastermu berada pada **_on-premises_**, atau **di cloud (IaaS)**? Kubernetes belum mendukung secara langsung klaster hibrid. Sebagai gantinya, kamu dapat membuat beberapa klaster. - - **Jika kamu ingin mengonfigurasi Kubernetes _on-premises_**, pertimbangkan [model jaringan](/docs/concepts/cluster-administration/networking/) yang paling sesuai. + - **Jika kamu ingin mengonfigurasi Kubernetes _on-premises_**, pertimbangkan [model jaringan](/id/docs/concepts/cluster-administration/networking/) yang paling sesuai. - Apakah kamu ingin menjalankan Kubernetes pada **"bare metal" _hardware_** atau pada **_virtual machines_ (VM)**? - Apakah kamu **hanya ingin mencoba klaster Kubernetes**, atau kamu ingin ikut aktif melakukan **pengembangan kode dari proyek Kubernetes**? Jika jawabannya yang terakhir, pilihlah distro yang aktif dikembangkan. Beberapa distro hanya menggunakan rilis *binary*, namun menawarkan lebih banyak variasi pilihan. - Pastikan kamu paham dan terbiasa dengan beberapa [komponen](/docs/admin/cluster-components/) yang dibutuhkan untuk menjalankan sebuah klaster. @@ -36,13 +36,13 @@ Catatan: Tidak semua distro aktif dikelola. Pilihlah distro yang telah diuji den * Pelajari bagaimana cara [mengatur *node*](/docs/concepts/nodes/node/). -* Pelajari bagaimana cara membuat dan mengatur kuota resource [(*resource quota*)](/docs/concepts/policy/resource-quotas/) untuk *shared* klaster. +* Pelajari bagaimana cara membuat dan mengatur kuota resource [(*resource quota*)](/id/docs/concepts/policy/resource-quotas/) untuk *shared* klaster. ## Mengamankan Klaster -* [Sertifikat (*certificate*)](/docs/concepts/cluster-administration/certificates/) akan menjabarkan langkah-langkah untuk membuat sertifikat menggunakan beberapa *tool chains*. +* [Sertifikat (*certificate*)](/id/docs/concepts/cluster-administration/certificates/) akan menjabarkan langkah-langkah untuk membuat sertifikat menggunakan beberapa *tool chains*. -* [Kubernetes *Container Environment*](/docs/concepts/containers/container-environment-variables/) akan menjelaskan *environment* untuk kontainer yang dikelola oleh Kubelet pada Kubernetes *node*. +* [Kubernetes *Container Environment*](/id/docs/concepts/containers/container-environment-variables/) akan menjelaskan *environment* untuk kontainer yang dikelola oleh Kubelet pada Kubernetes *node*. * [Mengontrol Akses ke Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) akan menjabarkan bagaimana cara mengatur izin (*permission*) untuk akun pengguna dan *service account*. @@ -63,9 +63,9 @@ Catatan: Tidak semua distro aktif dikelola. Pilihlah distro yang telah diuji den ## Layanan Tambahan Klaster -* [Integrasi DNS](/docs/concepts/services-networking/dns-pod-service/) akan menjelaskan bagaimana cara *resolve* suatu nama DNS langsung pada *service* Kubernetes. +* [Integrasi DNS](/id/docs/concepts/services-networking/dns-pod-service/) akan menjelaskan bagaimana cara *resolve* suatu nama DNS langsung pada *service* Kubernetes. -* [*Logging* dan *Monitoring* Aktivitas Klaster](/docs/concepts/cluster-administration/logging/) akan menjelaskan bagaimana cara *logging* bekerja di Kubernetes serta bagaimana cara mengimplementasikannya. +* [*Logging* dan *Monitoring* Aktivitas Klaster](/id/docs/concepts/cluster-administration/logging/) akan menjelaskan bagaimana cara *logging* bekerja di Kubernetes serta bagaimana cara mengimplementasikannya. diff --git a/content/id/docs/concepts/cluster-administration/federation.md b/content/id/docs/concepts/cluster-administration/federation.md index 7690a75a82..d59da126ad 100644 --- a/content/id/docs/concepts/cluster-administration/federation.md +++ b/content/id/docs/concepts/cluster-administration/federation.md @@ -106,7 +106,7 @@ Berikut merupakan panduan yang akan menjelaskan masing-masing _resource_ secara * [Namespaces](/docs/tasks/administer-federation/namespaces/) * [ReplicaSets](/docs/tasks/administer-federation/replicaset/) * [Secrets](/docs/tasks/administer-federation/secret/) -* [Services](/docs/concepts/cluster-administration/federation-service-discovery/) +* [Services](/id/docs/concepts/cluster-administration/federation-service-discovery/) [Referensi Dokumentasi API](/docs/reference/federation/) memberikan semua daftar diff --git a/content/id/docs/concepts/cluster-administration/logging.md b/content/id/docs/concepts/cluster-administration/logging.md index 53203777f2..75f3b97189 100644 --- a/content/id/docs/concepts/cluster-administration/logging.md +++ b/content/id/docs/concepts/cluster-administration/logging.md @@ -173,7 +173,7 @@ Menggunakan agen _logging_ di dalam kontainer _sidecar_ dapat berakibat pengguna {{< /note >}} Sebagai contoh, kamu dapat menggunakan [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/), -yang menggunakan fluentd sebagai agen _logging_. Berikut ini dua _file_ konfigurasi yang dapat kamu pakai untuk mengimplementasikan cara ini. _File_ yang pertama berisi sebuah [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) untuk mengonfigurasi fluentd. +yang menggunakan fluentd sebagai agen _logging_. Berikut ini dua _file_ konfigurasi yang dapat kamu pakai untuk mengimplementasikan cara ini. _File_ yang pertama berisi sebuah [ConfigMap](/id/docs/tasks/configure-pod-container/configure-pod-configmap/) untuk mengonfigurasi fluentd. {{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}} diff --git a/content/id/docs/concepts/cluster-administration/manage-deployment.md b/content/id/docs/concepts/cluster-administration/manage-deployment.md index 81c0ba4d08..d67da9c13e 100644 --- a/content/id/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/id/docs/concepts/cluster-administration/manage-deployment.md @@ -6,7 +6,7 @@ weight: 40 -Kamu telah melakukan _deploy_ pada aplikasimu dan mengeksposnya melalui sebuah _service_. Lalu? Kubernetes menyediakan berbagai peralatan untuk membantu mengatur mekanisme _deploy_ aplikasi, termasuk pengaturan kapasitas dan pembaruan. Diantara fitur yang akan didiskusikan lebih mendalam yaitu [berkas konfigurasi](/docs/concepts/configuration/overview/) dan [label](/docs/concepts/overview/working-with-objects/labels/). +Kamu telah melakukan _deploy_ pada aplikasimu dan mengeksposnya melalui sebuah _service_. Lalu? Kubernetes menyediakan berbagai peralatan untuk membantu mengatur mekanisme _deploy_ aplikasi, termasuk pengaturan kapasitas dan pembaruan. Diantara fitur yang akan didiskusikan lebih mendalam yaitu [berkas konfigurasi](/id/docs/concepts/configuration/overview/) dan [label](/id/docs/concepts/overview/working-with-objects/labels/). @@ -290,7 +290,7 @@ my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe Akan muncul semua _pod_ dengan "app=nginx" dan sebuah kolom label tambahan yaitu tier (ditentukan dengan `-L` atau `--label-columns`). -Untuk informasi lebih lanjut, silahkan baca [label](/docs/concepts/overview/working-with-objects/labels/) dan [kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label). +Untuk informasi lebih lanjut, silahkan baca [label](/id/docs/concepts/overview/working-with-objects/labels/) dan [kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label). ## Memperbarui anotasi @@ -309,7 +309,7 @@ metadata: ... ``` -Untuk informasi lebih lanjut, silahkan lihat laman [annotations](/docs/concepts/overview/working-with-objects/annotations/) dan [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate). +Untuk informasi lebih lanjut, silahkan lihat laman [annotations](/id/docs/concepts/overview/working-with-objects/annotations/) dan [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate). ## Memperbesar dan memperkecil aplikasi kamu @@ -432,7 +432,7 @@ Untuk memperbarui versi ke 1.9.1, ganti `.spec.template.spec.containers[0].image kubectl edit deployment/my-nginx ``` -Selesai! Deployment akan memperbarui aplikasi nginx yang terdeploy secara berangsur di belakang. Dia akan menjamin hanya ada sekian replika lama yang akan down selagi pembaruan berjalan dan hanya ada sekian replika baru akan dibuat melebihi jumlah pod. Untuk mempelajari lebih lanjut, kunjungi [laman Deployment](/docs/concepts/workloads/controllers/deployment/). +Selesai! Deployment akan memperbarui aplikasi nginx yang terdeploy secara berangsur di belakang. Dia akan menjamin hanya ada sekian replika lama yang akan down selagi pembaruan berjalan dan hanya ada sekian replika baru akan dibuat melebihi jumlah pod. Untuk mempelajari lebih lanjut, kunjungi [laman Deployment](/id/docs/concepts/workloads/controllers/deployment/). @@ -440,6 +440,6 @@ Selesai! Deployment akan memperbarui aplikasi nginx yang terdeploy secara berang - [Pelajari tentang bagaimana memakai `kubectl` untuk memeriksa dan _debug_ aplikasi.](/docs/tasks/debug-application-cluster/debug-application-introspection/) -- [Praktik Terbaik dan Tips Konfigurasi](/docs/concepts/configuration/overview/) +- [Praktik Terbaik dan Tips Konfigurasi](/id/docs/concepts/configuration/overview/) diff --git a/content/id/docs/concepts/cluster-administration/networking.md b/content/id/docs/concepts/cluster-administration/networking.md index 038465bcb8..6bcd78d7ef 100644 --- a/content/id/docs/concepts/cluster-administration/networking.md +++ b/content/id/docs/concepts/cluster-administration/networking.md @@ -10,10 +10,10 @@ untuk memahami persis bagaimana mengharapkannya bisa bekerja. Ada 4 masalah yang berbeda untuk diatasi: 1. Komunikasi antar kontainer yang sangat erat: hal ini diselesaikan oleh - [Pod](/docs/concepts/workloads/pods/pod/) dan komunikasi `localhost`. + [Pod](/id/docs/concepts/workloads/pods/pod/) dan komunikasi `localhost`. 2. Komunikasi antar Pod: ini adalah fokus utama dari dokumen ini. -3. Komunikasi Pod dengan Service: ini terdapat di [Service](/docs/concepts/services-networking/service/). -4. Komunikasi eksternal dengan Service: ini terdapat di [Service](/docs/concepts/services-networking/service/). +3. Komunikasi Pod dengan Service: ini terdapat di [Service](/id/docs/concepts/services-networking/service/). +4. Komunikasi eksternal dengan Service: ini terdapat di [Service](/id/docs/concepts/services-networking/service/). @@ -213,7 +213,7 @@ Calico juga dapat dijalankan dalam mode penegakan kebijakan bersama dengan solus ### Romana -[Romana](http://romana.io) adalah jaringan sumber terbuka dan solusi otomasi keamanan yang memungkinkan kamu menggunakan Kubernetes tanpa jaringan hamparan. Romana mendukung Kubernetes [Kebijakan Jaringan](/docs/concepts/services-networking/network-policies/) untuk memberikan isolasi di seluruh ruang nama jaringan. +[Romana](http://romana.io) adalah jaringan sumber terbuka dan solusi otomasi keamanan yang memungkinkan kamu menggunakan Kubernetes tanpa jaringan hamparan. Romana mendukung Kubernetes [Kebijakan Jaringan](/id/docs/concepts/services-networking/network-policies/) untuk memberikan isolasi di seluruh ruang nama jaringan. ### Weave Net dari Weaveworks diff --git a/content/id/docs/concepts/cluster-administration/proxies.md b/content/id/docs/concepts/cluster-administration/proxies.md index 5595414aa9..f3567233e0 100644 --- a/content/id/docs/concepts/cluster-administration/proxies.md +++ b/content/id/docs/concepts/cluster-administration/proxies.md @@ -14,7 +14,7 @@ Laman ini menjelaskan berbagai proxy yang ada di dalam Kubernetes. Ada beberapa jenis proxy yang akan kamu temui saat menggunakan Kubernetes: -1. [kubectl proxy](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api): +1. [kubectl proxy](/id/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api): - dijalankan pada desktop pengguna atau di dalam sebuah Pod - melakukan proxy dari alamat localhost ke apiserver Kubernetes @@ -23,7 +23,7 @@ Ada beberapa jenis proxy yang akan kamu temui saat menggunakan Kubernetes - mencari lokasi apiserver - menambahkan header autentikasi -1. [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services): +1. [apiserver proxy](/id/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services): - merupakan sebuah bastion yang ada di dalam apiserver - menghubungkan pengguna di luar klaster ke alamat-alamat IP di dalam klaster yang tidak bisa terjangkau @@ -33,7 +33,7 @@ Ada beberapa jenis proxy yang akan kamu temui saat menggunakan Kubernetes - dapat digunakan untuk menghubungi Node, Pod, atau Service - melakukan load balancing saat digunakan untuk menjangkau sebuah Service -1. [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips): +1. [kube proxy](/id/docs/concepts/services-networking/service/#ips-and-vips): - dijalankan pada setiap Node - melakukan proxy untuk UDP, TCP dan SCTP diff --git a/content/id/docs/concepts/configuration/assign-pod-node.md b/content/id/docs/concepts/configuration/assign-pod-node.md index 8af1abba28..ee9e8bf2f4 100644 --- a/content/id/docs/concepts/configuration/assign-pod-node.md +++ b/content/id/docs/concepts/configuration/assign-pod-node.md @@ -7,7 +7,7 @@ weight: 30 -Kamu dapat memaksa sebuah [pod](/docs/concepts/workloads/pods/pod/) untuk hanya dapat berjalan pada [node](/docs/concepts/architecture/nodes/) tertentu atau mengajukannya agar berjalan pada node tertentu. Ada beberapa cara untuk melakukan hal tersebut. Semua cara yang direkomendasikan adalah dengan menggunakan [_selector_ label](/docs/concepts/overview/working-with-objects/labels/) untuk menetapkan pilihan yang kamu inginkan. Pada umumnya, pembatasan ini tidak dibutuhkan, sebagaimana _scheduler_ akan melakukan penempatan yang proporsional dengan otomatis (seperti contohnya menyebar pod di node-node, tidak menempatkan pod pada node dengan sumber daya yang tidak memadai, dst.) tetapi ada keadaan-keadaan tertentu yang membuat kamu memiliki kendali lebih terhadap node yang menjadi tempat pod dijalankan, contohnya untuk memastikan pod dijalankan pada mesin yang telah terpasang SSD, atau untuk menempatkan pod-pod dari dua servis yang berbeda yang sering berkomunikasi bersamaan ke dalam zona ketersediaan yang sama. +Kamu dapat memaksa sebuah [pod](/id/docs/concepts/workloads/pods/pod/) untuk hanya dapat berjalan pada [node](/id/docs/concepts/architecture/nodes/) tertentu atau mengajukannya agar berjalan pada node tertentu. Ada beberapa cara untuk melakukan hal tersebut. Semua cara yang direkomendasikan adalah dengan menggunakan [_selector_ label](/id/docs/concepts/overview/working-with-objects/labels/) untuk menetapkan pilihan yang kamu inginkan. Pada umumnya, pembatasan ini tidak dibutuhkan, sebagaimana _scheduler_ akan melakukan penempatan yang proporsional dengan otomatis (seperti contohnya menyebar pod di node-node, tidak menempatkan pod pada node dengan sumber daya yang tidak memadai, dst.) tetapi ada keadaan-keadaan tertentu yang membuat kamu memiliki kendali lebih terhadap node yang menjadi tempat pod dijalankan, contohnya untuk memastikan pod dijalankan pada mesin yang telah terpasang SSD, atau untuk menempatkan pod-pod dari dua servis yang berbeda yang sering berkomunikasi bersamaan ke dalam zona ketersediaan yang sama. Kamu dapat menemukan semua berkas untuk contoh-contoh berikut pada [dokumentasi yang kami sediakan di sini](https://github.com/kubernetes/website/tree/{{< param "docsbranch" >}}/content/en/docs/concepts/configuration/) @@ -114,7 +114,7 @@ Berikut ini contoh dari pod yang menggunakan afinitas node: Aturan afinitas node tersebut menyatakan pod hanya bisa ditugaskan pada node dengan label yang memiliki kunci `kubernetes.io/e2e-az-name` dan bernilai `e2e-az1` atau `e2e-az2`. Selain itu, dari semua node yang memenuhi kriteria tersebut, mode dengan label dengan kunci `another-node-label-key` and bernilai `another-node-label-value` harus lebih diutamakan. -Kamu dapat meilhat operator `In` digunakan dalam contoh berikut. Sitaksis afinitas node yang baru mendukung operator-operator berikut: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`. Kamu dapat menggunakan `NotIn` dan `DoesNotExist` untuk mewujudkan perilaku node anti-afinitas, atau menggunakan [node taints](/docs/concepts/configuration/taint-and-toleration/) untuk menolak pod dari node tertentu. +Kamu dapat meilhat operator `In` digunakan dalam contoh berikut. Sitaksis afinitas node yang baru mendukung operator-operator berikut: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`. Kamu dapat menggunakan `NotIn` dan `DoesNotExist` untuk mewujudkan perilaku node anti-afinitas, atau menggunakan [node taints](/id/docs/concepts/configuration/taint-and-toleration/) untuk menolak pod dari node tertentu. Jika kamu menyatakan `nodeSelector` dan `nodeAffinity`. *keduanya* harus dipenuhi agar pod dapat dijadwalkan pada node kandidat. @@ -284,7 +284,7 @@ Lihat [tutorial ZooKeeper](/docs/tutorials/stateful-application/zookeeper/#toler Untuk informasi lebih lanjut tentang afinitas/anti-afinitas antar pod, lihat [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md). -Kamu juga dapat mengecek [Taints](/docs/concepts/configuration/taint-and-toleration/), yang memungkinkan sebuah *node* untuk *menolak* sekumpulan pod. +Kamu juga dapat mengecek [Taints](/id/docs/concepts/configuration/taint-and-toleration/), yang memungkinkan sebuah *node* untuk *menolak* sekumpulan pod. ## nodeName diff --git a/content/id/docs/concepts/configuration/manage-compute-resources-container.md b/content/id/docs/concepts/configuration/manage-compute-resources-container.md index 3450bab459..600a4cc6cd 100644 --- a/content/id/docs/concepts/configuration/manage-compute-resources-container.md +++ b/content/id/docs/concepts/configuration/manage-compute-resources-container.md @@ -10,7 +10,7 @@ feature: -Saat kamu membuat spesifikasi sebuah [Pod](/docs/concepts/workloads/pods/pod/), kamu +Saat kamu membuat spesifikasi sebuah [Pod](/id/docs/concepts/workloads/pods/pod/), kamu dapat secara opsional menentukan seberapa banyak CPU dan memori (RAM) yang dibutuhkan oleh setiap Container. Saat Container-Container menentukan _request_ (permintaan) sumber daya, scheduler dapat membuat keputusan yang lebih baik mengenai Node mana yang akan dipilih @@ -42,8 +42,8 @@ Hal ini berbeda dari sumber daya `memory` dan `cpu` (yang dapat di-_overcommit_) CPU dan memori secara kolektif disebut sebagai _sumber daya komputasi_, atau cukup _sumber daya_ saja. Sumber daya komputasi adalah jumlah yang dapat diminta, dialokasikan, -dan dikonsumsi. Mereka berbeda dengan [sumber daya API](/docs/concepts/overview/kubernetes-api/). -Sumber daya API, seperti Pod dan [Service](/docs/concepts/services-networking/service/) adalah +dan dikonsumsi. Mereka berbeda dengan [sumber daya API](/id/docs/concepts/overview/kubernetes-api/). +Sumber daya API, seperti Pod dan [Service](/id/docs/concepts/services-networking/service/) adalah objek-objek yang dapat dibaca dan diubah melalui Kubernetes API Server. ## Request dan Limit Sumber daya dari Pod dan Container @@ -270,7 +270,7 @@ _daemon_ sistem menggunakan sebagian dari sumber daya yang ada. Kolom `allocatab memberikan jumlah sumber daya yang tersedia untuk Pod-Pod. Untuk lebih lanjut, lihat [Sumber daya Node yang dapat dialokasikan](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md). -Fitur [kuota sumber daya](/docs/concepts/policy/resource-quotas/) dapat disetel untuk +Fitur [kuota sumber daya](/id/docs/concepts/policy/resource-quotas/) dapat disetel untuk membatasi jumlah sumber daya yang dapat digunakan. Jika dipakai bersama dengan Namespace, kuota sumber daya dapat mencegah suatu tim menghabiskan semua sumber daya. @@ -489,7 +489,7 @@ Sumber daya yang diperluas pada tingkat Node terikat pada Node. ##### Sumber daya Device Plugin yang dikelola Lihat [Device -Plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) untuk +Plugin](/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) untuk cara menyatakan sumber daya _device plugin_ yang dikelola pada setiap node. ##### Sumber daya lainnya diff --git a/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md index 929c895821..caba991a8d 100644 --- a/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md +++ b/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md @@ -24,7 +24,7 @@ tanda [`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/). Instruksi langkah demi langkah untuk membuat dan menentukan berkas kubeconfig, bisa mengacu pada [Mengatur Akses Pada Beberapa Klaster] -(/docs/tasks/access-application-cluster/configure-access-multiple-clusters). +(/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters). @@ -103,7 +103,7 @@ kubeconfig: abaikan mereka. Beberapa contoh pengaturan variabel _environment_ `KUBECONFIG`, bisa melihat pada - [pengaturan vaiabel _environment_ KUBECONFIG](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable). + [pengaturan vaiabel _environment_ KUBECONFIG](/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable). Sebaliknya, bisa menggunakan berkas kubeconfig _default_, `$HOME/.kube/config`, tanpa melakukan penggabungan. @@ -158,7 +158,7 @@ _absolute path_ akan disimpan secara mutlak. ## {{% heading "whatsnext" %}} -* [Mengatur Akses Pada Beberapa Klaster](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +* [Mengatur Akses Pada Beberapa Klaster](/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) * [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config) diff --git a/content/id/docs/concepts/configuration/overview.md b/content/id/docs/concepts/configuration/overview.md index 76d68658ec..67fb2061fe 100644 --- a/content/id/docs/concepts/configuration/overview.md +++ b/content/id/docs/concepts/configuration/overview.md @@ -32,14 +32,14 @@ Dokumentasi ini terbuka. Jika Anda menemukan sesuatu yang tidak ada dalam daftar ## "Naked" Pods vs ReplicaSets, Deployments, and Jobs -- Jangan gunakan Pods naked (artinya, Pods tidak terikat dengan a [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) a [Deployment](/docs/concepts/workloads/controllers/deployment/)) jika kamu bisa menghindarinya. Pod naked tidak akan dijadwal ulang jika terjadi kegagalan pada node. +- Jangan gunakan Pods naked (artinya, Pods tidak terikat dengan a [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/) a [Deployment](/id/docs/concepts/workloads/controllers/deployment/)) jika kamu bisa menghindarinya. Pod naked tidak akan dijadwal ulang jika terjadi kegagalan pada node. - Deployment, yang keduanya menciptakan ReplicaSet untuk memastikan bahwa jumlah Pod yang diinginkan selalu tersedia, dan menentukan strategi untuk mengganti Pods (seperti [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), hampir selalu lebih disukai daripada membuat Pods secara langsung, kecuali untuk beberapa yang eksplisit [`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) banyak skenario . A [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) mungkin juga sesuai. + Deployment, yang keduanya menciptakan ReplicaSet untuk memastikan bahwa jumlah Pod yang diinginkan selalu tersedia, dan menentukan strategi untuk mengganti Pods (seperti [RollingUpdate](/id/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), hampir selalu lebih disukai daripada membuat Pods secara langsung, kecuali untuk beberapa yang eksplisit [`restartPolicy: Never`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) banyak skenario . A [Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/) mungkin juga sesuai. ## Services -- Buat [Service](/docs/concepts/services-networking/service/) sebelum workloads backend terkait (Penyebaran atau ReplicaSets), dan sebelum workloads apa pun yang perlu mengaksesnya. Ketika Kubernetes memulai sebuah container, ia menyediakan environment variabel yang menunjuk ke semua Layanan yang berjalan ketika container itu dimulai. Misalnya, jika Layanan bernama `foo` ada, semua container akan mendapatkan variabel berikut di environment awalnya: +- Buat [Service](/id/docs/concepts/services-networking/service/) sebelum workloads backend terkait (Penyebaran atau ReplicaSets), dan sebelum workloads apa pun yang perlu mengaksesnya. Ketika Kubernetes memulai sebuah container, ia menyediakan environment variabel yang menunjuk ke semua Layanan yang berjalan ketika container itu dimulai. Misalnya, jika Layanan bernama `foo` ada, semua container akan mendapatkan variabel berikut di environment awalnya: ```shell FOO_SERVICE_HOST= @@ -48,26 +48,26 @@ Dokumentasi ini terbuka. Jika Anda menemukan sesuatu yang tidak ada dalam daftar *Ini menunjukan persyaratan pemesanan * - `Service` apa pun yang ingin diakses oleh` Pod` harus dibuat sebelum `Pod` itu sendiri, atau environment variabel tidak akan diisi. DNS tidak memiliki batasan ini. -- Opsional (meskipun sangat disarankan) [cluster add-on](/docs/concepts/cluster-administration/addons/) adalah server DNS. +- Opsional (meskipun sangat disarankan) [cluster add-on](/id/docs/concepts/cluster-administration/addons/) adalah server DNS. Server DNS melihat API Kubernetes untuk `Service` baru dan membuat satu set catatan DNS untuk masing-masing. Jika DNS telah diaktifkan di seluruh cluster maka semua `Pods` harus dapat melakukan resolusi nama`Service` secara otomatis. - Jangan tentukan `hostPort` untuk Pod kecuali jika benar-benar diperlukan. Ketika Anda bind Pod ke `hostPort`, hal itu membatasi jumlah tempat Pod dapat dijadwalkan, karena setiap kombinasi <` hostIP`, `hostPort`,` protokol`> harus unik. Jika Anda tidak menentukan `hostIP` dan` protokol` secara eksplisit, Kubernetes akan menggunakan `0.0.0.0` sebagai` hostIP` dan `TCP` sebagai default` protokol`. - Jika kamu hanya perlu akses ke port untuk keperluan debugging, Anda bisa menggunakan [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) atau [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/). + Jika kamu hanya perlu akses ke port untuk keperluan debugging, Anda bisa menggunakan [apiserver proxy](/id/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) atau [`kubectl port-forward`](/id/docs/tasks/access-application-cluster/port-forward-access-application-cluster/). - Jika Anda secara eksplisit perlu mengekspos port Pod pada node, pertimbangkan untuk menggunakan [NodePort](/docs/concepts/services-networking/service/#nodeport) Service sebelum beralih ke `hostPort`. + Jika Anda secara eksplisit perlu mengekspos port Pod pada node, pertimbangkan untuk menggunakan [NodePort](/id/docs/concepts/services-networking/service/#nodeport) Service sebelum beralih ke `hostPort`. - Hindari menggunakan `hostNetwork`, untuk alasan yang sama seperti` hostPort`. -- Gunakan [headless Services](/docs/concepts/services-networking/service/#headless- +- Gunakan [headless Services](/id/docs/concepts/services-networking/service/#headless- services) (yang memiliki `ClusterIP` dari` None`) untuk Service discovery yang mudah ketika Anda tidak membutuhkan `kube-proxy` load balancing. ## Menggunakan label -- Deklarasi dan gunakan [labels] (/docs/concepts/overview/working-with-objects/labels/) untuk identifikasi __semantic attributes__ aplikasi atau Deployment kamu, seperti `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. Kamu dapat menggunakan label ini untuk memilih Pod yang sesuai untuk sumber daya lainnya; misalnya, Service yang memilih semua `tier: frontend` Pods, atau semua komponen` phase: test` dari `app: myapp`. Lihat [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) aplikasi untuk contoh-contoh pendekatan ini. +- Deklarasi dan gunakan [labels] (/id/docs/concepts/overview/working-with-objects/labels/) untuk identifikasi __semantic attributes__ aplikasi atau Deployment kamu, seperti `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. Kamu dapat menggunakan label ini untuk memilih Pod yang sesuai untuk sumber daya lainnya; misalnya, Service yang memilih semua `tier: frontend` Pods, atau semua komponen` phase: test` dari `app: myapp`. Lihat [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) aplikasi untuk contoh-contoh pendekatan ini. -Service dapat dibuat untuk menjangkau beberapa Penyebaran dengan menghilangkan label khusus rilis dari pemilihnya. [Deployments](/docs/concepts/workloads/controllers/deployment/) membuatnya mudah untuk memperbarui Service yang sedang berjalan tanpa downtime. +Service dapat dibuat untuk menjangkau beberapa Penyebaran dengan menghilangkan label khusus rilis dari pemilihnya. [Deployments](/id/docs/concepts/workloads/controllers/deployment/) membuatnya mudah untuk memperbarui Service yang sedang berjalan tanpa downtime. Keadaan objek yang diinginkan dideskripsikan oleh Deployment, dan jika perubahan terhadap spesifikasi tersebut adalah _applied_, Deployment controller mengubah keadaan aktual ke keadaan yang diinginkan pada tingkat yang terkontrol. @@ -75,7 +75,7 @@ Keadaan objek yang diinginkan dideskripsikan oleh Deployment, dan jika perubahan ## Container Images -Ini [imagePullPolicy](/docs/concepts/containers/images/#updating-images) dan tag dari image mempengaruhi ketika [kubelet](/docs/admin/kubelet/) mencoba menarik image yang ditentukan +Ini [imagePullPolicy](/id/docs/concepts/containers/images/#updating-images) dan tag dari image mempengaruhi ketika [kubelet](/docs/admin/kubelet/) mencoba menarik image yang ditentukan - `imagePullPolicy: IfNotPresent`: image ditarik hanya jika belum ada secara lokal. @@ -105,7 +105,7 @@ Semantik caching dari penyedia gambar yang mendasarinya membuat bahkan `imagePul - Gunakan `kubectl apply -f `. Ini mencari konfigurasi Kubernetes di semua file `.yaml`,` .yml`, dan `.json` di` `dan meneruskannya ke` apply`. -- Gunakan label selector untuk operasi `get` dan` delete` alih-alih nama objek tertentu. Lihat bagian di [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors) dan [using labels effectively](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively). +- Gunakan label selector untuk operasi `get` dan` delete` alih-alih nama objek tertentu. Lihat bagian di [label selectors](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors) dan [using labels effectively](/id/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively). - Gunakan `kubectl run` dan` kubectl expose` untuk dengan cepat membuat Deployment dan Service single-container. Lihat [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) untuk Contoh. diff --git a/content/id/docs/concepts/configuration/pod-overhead.md b/content/id/docs/concepts/configuration/pod-overhead.md index e59301bb96..13db4e32f8 100644 --- a/content/id/docs/concepts/configuration/pod-overhead.md +++ b/content/id/docs/concepts/configuration/pod-overhead.md @@ -22,7 +22,7 @@ _Pod Overhead_ adalah fitur yang berfungsi untuk menghitung sumber daya digunaka Pada Kubernetes, Overhead Pod ditentukan pada [saat admisi](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) sesuai dengan Overhead yang ditentukan di dalam -[RuntimeClass](/docs/concepts/containers/runtime-class/) milik Pod. +[RuntimeClass](/id/docs/concepts/containers/runtime-class/) milik Pod. Ketika Overhead Pod diaktifkan, Overhead akan dipertimbangkan sebagai tambahan terhadap jumlah permintaan sumber daya Container saat menjadwalkan Pod. Begitu pula Kubelet, yang akan memasukkan Overhead Pod saat menentukan ukuran @@ -49,7 +49,7 @@ Lihat [Ringkasan Otorisasi](/docs/reference/access-authn-authz/authorization/) u ## {{% heading "whatsnext" %}} -* [RuntimeClass](/docs/concepts/containers/runtime-class/) +* [RuntimeClass](/id/docs/concepts/containers/runtime-class/) * [Desain PodOverhead](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) diff --git a/content/id/docs/concepts/configuration/pod-priority-preemption.md b/content/id/docs/concepts/configuration/pod-priority-preemption.md index a0c6035482..7350470fa3 100644 --- a/content/id/docs/concepts/configuration/pod-priority-preemption.md +++ b/content/id/docs/concepts/configuration/pod-priority-preemption.md @@ -24,7 +24,7 @@ Versi Kubernetes | Keadaan Priority and Pemindahan | Dihidupkan secara Bawaan 1.11 | beta | ya 1.14 | stable | ya -{{< warning >}}Pada sebuah klaster di mana tidak semua pengguna dipercaya, seorang pengguna yang berniat jahat dapat membuat Pod-pod dengan prioritas paling tinggi, membuat Pod-pod lainnya dipindahkan/tidak dapat dijadwalkan. Untuk mengatasi masalah ini, [ResourceQuota](/docs/concepts/policy/resource-quotas/) ditambahkan untuk mendukung prioritas Pod. Seorang admin dapat membuat ResourceQuota untuk pengguna-pengguna pada tingkat prioritas tertentu, mencegah mereka untuk membuat Pod-pod pada prioritas tinggi. Fitur ini telah beta sejak Kubernetes 1.12. +{{< warning >}}Pada sebuah klaster di mana tidak semua pengguna dipercaya, seorang pengguna yang berniat jahat dapat membuat Pod-pod dengan prioritas paling tinggi, membuat Pod-pod lainnya dipindahkan/tidak dapat dijadwalkan. Untuk mengatasi masalah ini, [ResourceQuota](/id/docs/concepts/policy/resource-quotas/) ditambahkan untuk mendukung prioritas Pod. Seorang admin dapat membuat ResourceQuota untuk pengguna-pengguna pada tingkat prioritas tertentu, mencegah mereka untuk membuat Pod-pod pada prioritas tinggi. Fitur ini telah beta sejak Kubernetes 1.12. {{< /warning >}} @@ -178,11 +178,11 @@ Harap catat bahwa Pod P tidak harus dijadwalkan pada "_nominated_ Node" (Node ya #### Penghentian secara sopan dari korban-korban pemindahan Pod -Saat Pod-pod dipindahkan, korban-korbannya mendapatkan [periode penghentian secara sopan](/docs/concepts/workloads/pods/pod/#penghentian-pod). Mereka memiliki waktu sebanyak itu untuk menyelesaikan pekerjaan merekan dan berhenti. Jika mereka tidak menyelesaikannya sebelum waktu tersebut, mereka akan dihentikan secara paksa. Periode penghentian secara sopan ini membuat sebuah jarak waktu antara saat di mana Scheduler memindahkan Pod-pod dengan waktu saat Pod yang tertunda tersebut (P) dapat dijadwalkan pada Node tersebut (N). Sementara itu, Scheduler akan terus menjadwalkan Pod-pod lain yang tertunda. Oleh karena itu, biasanya ada jarak waktu antara titik di mana Scheduler memindahkan korban-korban dan titik saat Pod P dijadwalkan. Untuk meminimalkan jarak waktu ini, kamu dapat menyetel periode penghentian secara sopan dari Pod-pod dengan prioritas lebih rendah menjadi nol atau sebuah angka yang kecil. +Saat Pod-pod dipindahkan, korban-korbannya mendapatkan [periode penghentian secara sopan](/id/docs/concepts/workloads/pods/pod/#penghentian-pod). Mereka memiliki waktu sebanyak itu untuk menyelesaikan pekerjaan merekan dan berhenti. Jika mereka tidak menyelesaikannya sebelum waktu tersebut, mereka akan dihentikan secara paksa. Periode penghentian secara sopan ini membuat sebuah jarak waktu antara saat di mana Scheduler memindahkan Pod-pod dengan waktu saat Pod yang tertunda tersebut (P) dapat dijadwalkan pada Node tersebut (N). Sementara itu, Scheduler akan terus menjadwalkan Pod-pod lain yang tertunda. Oleh karena itu, biasanya ada jarak waktu antara titik di mana Scheduler memindahkan korban-korban dan titik saat Pod P dijadwalkan. Untuk meminimalkan jarak waktu ini, kamu dapat menyetel periode penghentian secara sopan dari Pod-pod dengan prioritas lebih rendah menjadi nol atau sebuah angka yang kecil. #### PodDisruptionBudget didukung, tapi tidak dijamin! -Sebuah [Pod Disruption Budget (PDB)](/docs/concepts/workloads/pods/disruptions/) memungkinkan pemilik-pemilik aplikasi untuk membatasi jumlah Pod-pod dari sebuah aplikasi yang direplikasi yang mati secara bersamaan dikarenakan disrupsi yang disengaja. Kubernetes 1.9 mendukung PDB saat memindahkan Pod-pod, tetapi penghormatan terhadap PDB ini bersifat "usaha terbaik" (_best-effort_). Scheduler akan mencoba mencari korban-korban yang PDB-nya tidak dilanggar oleh pemindahan, tetapi jika tidak ada korban yang ditemukan, pemindahan akan tetap terjadi, dan Pod-pod dengan prioritas lebih rendah akan dihapus/dipindahkan meskipun PDB mereka dilanggar. +Sebuah [Pod Disruption Budget (PDB)](/id/docs/concepts/workloads/pods/disruptions/) memungkinkan pemilik-pemilik aplikasi untuk membatasi jumlah Pod-pod dari sebuah aplikasi yang direplikasi yang mati secara bersamaan dikarenakan disrupsi yang disengaja. Kubernetes 1.9 mendukung PDB saat memindahkan Pod-pod, tetapi penghormatan terhadap PDB ini bersifat "usaha terbaik" (_best-effort_). Scheduler akan mencoba mencari korban-korban yang PDB-nya tidak dilanggar oleh pemindahan, tetapi jika tidak ada korban yang ditemukan, pemindahan akan tetap terjadi, dan Pod-pod dengan prioritas lebih rendah akan dihapus/dipindahkan meskipun PDB mereka dilanggar. #### Afinitas antar-Pod pada Pod-pod dengan prioritas lebih rendah diff --git a/content/id/docs/concepts/configuration/secret.md b/content/id/docs/concepts/configuration/secret.md index a6ca8dca88..40875648ff 100644 --- a/content/id/docs/concepts/configuration/secret.md +++ b/content/id/docs/concepts/configuration/secret.md @@ -49,7 +49,7 @@ Mekanisme otomatisasi pembuatan secret dan penggunaan kredensial API dapat di no atau di-_override_ jika kamu menginginkannya. Meskipun begitu, jika apa yang kamu butuhkan hanyalah mengakses apiserver secara aman, maka mekanisme _default_ inilah yang disarankan. -Baca lebih lanjut dokumentasi [_Service Account_](/docs/tasks/configure-pod-container/configure-service-account/) +Baca lebih lanjut dokumentasi [_Service Account_](/id/docs/tasks/configure-pod-container/configure-service-account/) untuk informasi lebih lanjut mengenai bagaimana cara kerja _Service Account_. ### Membuat Objek Secret Kamu Sendiri @@ -569,7 +569,7 @@ _delay_ propagasi _cache_, dimana _delay_ propagasi _cache_ bergantung pada jeni {{< note >}} Sebuah container menggunakan Secret sebagai -[subPath](/docs/concepts/storage/volumes#using-subpath) dari _volume_ +[subPath](/id/docs/concepts/storage/volumes#using-subpath) dari _volume_ yang di-_mount_ tidak akan menerima perubahan Secret. {{< /note >}} @@ -636,7 +636,7 @@ pada Kubelet, sehingga Kubelet dapat mengunduh _image_ dan menempatkannya pada P **Memberikan spesifikasi manual dari sebuah imagePullSecret** -Penggunaan imagePullSecrets dideskripsikan di dalam [dokumentasi _image_](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) +Penggunaan imagePullSecrets dideskripsikan di dalam [dokumentasi _image_](/id/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) ### Mekanisme yang Dapat Diterapkan agar imagePullSecrets dapat Secara Otomatis Digunakan @@ -644,7 +644,7 @@ Kamu dapat secara manual membuat sebuah imagePullSecret, serta merujuk imagePull yang sudah kamu buat dari sebuah serviceAccount. Semua Pod yang dibuat dengan menggunakan serviceAccount tadi atau serviceAccount _default_ akan menerima _field_ imagePullSecret dari serviceAccount yang digunakan. -Bacalah [Cara menambahkan ImagePullSecrets pada sebuah _service account_](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) +Bacalah [Cara menambahkan ImagePullSecrets pada sebuah _service account_](/id/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) untuk informasi lebih detail soal proses yang dijalankan. ### Mekanisme _Mounting_ Otomatis dari Secret yang Sudah Dibuat @@ -985,7 +985,7 @@ hanya boleh dimiliki oleh komponen pada sistem level yang paling _previleged_. Aplikasi yang membutuhkan akses ke API secret harus melakukan _request_ `get` pada secret yang dibutuhkan. Hal ini memungkinkan administrator untuk membatasi -akses pada semua secret dengan tetap memberikan [akses pada instans secret tertentu](/docs/reference/access-authn-authz/rbac/#referring-to-resources) +akses pada semua secret dengan tetap memberikan [akses pada instans secret tertentu](/id/docs/reference/access-authn-authz/rbac/#referring-to-resources) yang dibutuhkan aplikasi. Untuk meningkatkan performa dengan menggunakan iterasi `get`, klien dapat mendesain diff --git a/content/id/docs/concepts/configuration/taint-and-toleration.md b/content/id/docs/concepts/configuration/taint-and-toleration.md index 9a30b48f5b..723bbd1c9c 100644 --- a/content/id/docs/concepts/configuration/taint-and-toleration.md +++ b/content/id/docs/concepts/configuration/taint-and-toleration.md @@ -6,7 +6,7 @@ weight: 40 -Afinitas Node, seperti yang dideskripsikan [di sini](/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature), +Afinitas Node, seperti yang dideskripsikan [di sini](/id/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature), adalah salah satu properti dari Pod yang menyebabkan pod tersebut memiliki preferensi untuk ditempatkan di sekelompok Node tertentu (preferensi ini dapat berupa _soft constraints_ atau _hard constraints_ yang harus dipenuhi). _Taint_ merupakan kebalikan dari afinitas -- @@ -193,7 +193,7 @@ khusus (misalnya, `kubectl taint nodes nodename special=true:NoSchedule` atau yang sesuai pada _pod_ yang menggunakan _node_ dengan perangkat keras khusus. Seperti halnya pada kebutuhan _dedicated_ _node_, hal ini dapat dilakukan dengan mudah dengan cara menulis [_admission controller_](/docs/reference/access-authn-authz/admission-controllers/) yang -bersifat khusus. Misalnya, kita dapat menggunakan [_Extended Resource_](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) +bersifat khusus. Misalnya, kita dapat menggunakan [_Extended Resource_](/id/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) untuk merepresentasikan perangkat keras khusus, kemudian _taint_ _node_ dengan perangkat keras khusus dengan nama _extended resource_ dan jalankan _admission controller_ [ExtendedResourceToleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration). @@ -244,7 +244,7 @@ dan logika normal untuk melakukan _eviction_ pada _pod_ dari suatu _node_ terten dari _Ready_ yang ada pada _NodeCondition_ dinonaktifkan. {{< note >}} -Untuk menjaga perilaku [_rate limiting_](/docs/concepts/architecture/nodes/) yang +Untuk menjaga perilaku [_rate limiting_](/id/docs/concepts/architecture/nodes/) yang ada pada _eviction_ _pod_ apabila _node_ mengalami masalah, sistem sebenarnya menambahkan _taint_ dalam bentuk _rate limiter_. Hal ini mencegah _eviction_ besar-besaran pada _pod_ pada skenario dimana master menjadi terpisah dari _node_ lainnya. @@ -280,7 +280,7 @@ _node_ apabila salah satu masalah terdeteksi. Kedua _toleration_ _default_ tadi ditambahkan oleh [DefaultTolerationSeconds _admission controller_](https://git.k8s.io/kubernetes/plugin/pkg/admission/defaulttolerationseconds). -_Pod-pod_ pada [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) dibuat dengan _toleration_ +_Pod-pod_ pada [DaemonSet](/id/docs/concepts/workloads/controllers/daemonset/) dibuat dengan _toleration_ `NoExecute` untuk _taint_ tanpa `tolerationSeconds`: * `node.kubernetes.io/unreachable` diff --git a/content/id/docs/concepts/containers/container-environment.md b/content/id/docs/concepts/containers/container-environment.md index affb371001..6c0ba354e8 100644 --- a/content/id/docs/concepts/containers/container-environment.md +++ b/content/id/docs/concepts/containers/container-environment.md @@ -17,7 +17,7 @@ Laman ini menjelaskan berbagai *resource* yang tersedia di dalam Kontainer pada *Environment* Kontainer pada Kubernetes menyediakan beberapa *resource* penting yang tersedia di dalam Kontainer: -* Sebuah *Filesystem*, yang merupakan kombinasi antara [image](/docs/concepts/containers/images/) dan satu atau banyak [*volumes*](/docs/concepts/storage/volumes/). +* Sebuah *Filesystem*, yang merupakan kombinasi antara [image](/id/docs/concepts/containers/images/) dan satu atau banyak [*volumes*](/id/docs/concepts/storage/volumes/). * Informasi tentang Kontainer tersebut. * Informasi tentang objek-objek lain di dalam klaster. @@ -53,7 +53,7 @@ jika [*addon* DNS](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/a ## {{% heading "whatsnext" %}} -* Pelajari lebih lanjut tentang [berbagai *hook* pada *lifecycle* Kontainer](/docs/concepts/containers/container-lifecycle-hooks/). +* Pelajari lebih lanjut tentang [berbagai *hook* pada *lifecycle* Kontainer](/id/docs/concepts/containers/container-lifecycle-hooks/). * Dapatkan pengalaman praktis soal [memberikan *handler* untuk *event* dari *lifecycle* Kontainer](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). diff --git a/content/id/docs/concepts/containers/container-lifecycle-hooks.md b/content/id/docs/concepts/containers/container-lifecycle-hooks.md index a7b5164864..d45a5ad23e 100644 --- a/content/id/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/id/docs/concepts/containers/container-lifecycle-hooks.md @@ -40,7 +40,7 @@ Hal ini bersifat *blocking*, yang artinya panggilan bersifat sinkron (*synchrono untuk menghapus kontainer tersebut. Tidak ada parameter yang diberikan pada *handler*. -Penjelasan yang lebih rinci tentang proses terminasi dapat dilihat pada [Terminasi Pod](/docs/concepts/workloads/pods/pod/#termination-of-pods). +Penjelasan yang lebih rinci tentang proses terminasi dapat dilihat pada [Terminasi Pod](/id/docs/concepts/workloads/pods/pod/#termination-of-pods). ### Implementasi *handler* untuk *hook* @@ -113,7 +113,7 @@ Events: ## {{% heading "whatsnext" %}} -* Pelajari lebih lanjut tentang [*environment* Kontainer](/docs/concepts/containers/container-environment-variables/). +* Pelajari lebih lanjut tentang [*environment* Kontainer](/id/docs/concepts/containers/container-environment-variables/). * Pelajari bagaimana caranya [melakukan *attach handler* pada *event lifecycle* sebuah Kontainer](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). diff --git a/content/id/docs/concepts/containers/images.md b/content/id/docs/concepts/containers/images.md index 7a5fa28154..8fa81801ff 100644 --- a/content/id/docs/concepts/containers/images.md +++ b/content/id/docs/concepts/containers/images.md @@ -26,7 +26,7 @@ selalu diunduh, kamu bisa melakukan salah satu dari berikut: - buang `imagePullPolicy` dan juga _tag_ untuk _image_. - aktifkan [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) _admission controller_. -Harap diingat kamu sebaiknya hindari penggunaan _tag_ `:latest`, lihat [panduan konfigurasi](/docs/concepts/configuration/overview/#container-images) untuk informasi lebih lanjut. +Harap diingat kamu sebaiknya hindari penggunaan _tag_ `:latest`, lihat [panduan konfigurasi](/id/docs/concepts/configuration/overview/#container-images) untuk informasi lebih lanjut. ## Membuat Image Multi-arsitektur dengan Manifest @@ -142,7 +142,7 @@ Setelah kamu membuat registri, kamu akan menggunakan kredensial berikut untuk lo * `DOCKER_EMAIL`: `${some-email-address}` Ketika kamu sudah memiliki variabel-variabel di atas, kamu dapat -[mengkonfigurasi sebuah Kubernetes Secret dan menggunakannya untuk _deploy_ sebuah Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). +[mengkonfigurasi sebuah Kubernetes Secret dan menggunakannya untuk _deploy_ sebuah Pod](/id/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). ### Menggunakan IBM Cloud Container Registry IBM Cloud Container Registry menyediakan sebuah registri _image_ privat yang _multi-tenant_, dapat kamu gunakan untuk menyimpan dan membagikan _image-image_ secara aman. Secara _default_, _image-image_ di dalam registri privat kamu akan dipindai (_scan_) oleh Vulnerability Advisor terintegrasi untuk deteksi isu @@ -291,7 +291,7 @@ kubectl create secret docker-registry --docker-server=DOCKER_REGISTRY_SER Jika kamu sudah memiliki berkas kredensial Docker, daripada menggunakan perintah di atas, kamu dapat mengimpor berkas kredensial sebagai Kubernetes Secret. -[Membuat sebuah Secret berbasiskan pada kredensial Docker yang sudah ada](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) menjelaskan bagaimana mengatur ini. +[Membuat sebuah Secret berbasiskan pada kredensial Docker yang sudah ada](/id/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) menjelaskan bagaimana mengatur ini. Cara ini berguna khususnya jika kamu menggunakan beberapa registri kontainer privat, perintah `kubectl create secret docker-registry` akan membuat sebuah Secret yang akan hanya bekerja menggunakan satu registri privat. @@ -331,7 +331,7 @@ Cara ini perlu untuk diselesaikan untuk setiap Pod yang mengguunakan registri pr Hanya saja, mengatur _field_ ini dapat diotomasi dengan mengatur imagePullSecrets di dalam sumber daya [serviceAccount](/docs/user-guide/service-accounts). -Periksa [Tambahan ImagePullSecrets untuk sebuah Service Account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) untuk instruksi yang lebih detail. +Periksa [Tambahan ImagePullSecrets untuk sebuah Service Account](/id/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) untuk instruksi yang lebih detail. Kamu dapat menggunakan cara ini bersama `.docker/config.json` pada setiap Node. Kredensial-kredensial akan dapat di-_merged_. Cara ini akan dapat bekerja pada Google Kubernetes Engine. diff --git a/content/id/docs/concepts/containers/overview.md b/content/id/docs/concepts/containers/overview.md index d31c760ee0..715230d14d 100644 --- a/content/id/docs/concepts/containers/overview.md +++ b/content/id/docs/concepts/containers/overview.md @@ -21,7 +21,7 @@ ini membuat penyebaran lebih mudah di lingkungan cloud atau OS yang berbeda. ## Image-Image Kontainer -[Kontainer image](/docs/concepts/containers/images/) meruapakan paket perangkat lunak +[Kontainer image](/id/docs/concepts/containers/images/) meruapakan paket perangkat lunak yang siap dijalankan, mengandung semua yang diperlukan untuk menjalankan sebuah aplikasi: kode dan setiap *runtime* yang dibutuhkan, *library* dari aplikasi dan sistem, dan nilai *default* untuk penganturan yang penting. diff --git a/content/id/docs/concepts/containers/runtime-class.md b/content/id/docs/concepts/containers/runtime-class.md index 31bd8a25ec..73252a03e4 100644 --- a/content/id/docs/concepts/containers/runtime-class.md +++ b/content/id/docs/concepts/containers/runtime-class.md @@ -45,7 +45,7 @@ soal bagaimana melakukan konfigurasi untuk implementasi CRI yang kamu miliki. Untuk saat ini, RuntimeClass berasumsi bahwa semua _node_ di dalam klaster punya konfigurasi yang sama (homogen). Jika ada _node_ yang punya konfigurasi berbeda dari yang lain (heterogen), maka perbedaan ini harus diatur secara independen di luar RuntimeClass -melalui fitur _scheduling_ (lihat [Menempatkan Pod pada Node](/docs/concepts/configuration/assign-pod-node/)). +melalui fitur _scheduling_ (lihat [Menempatkan Pod pada Node](/id/docs/concepts/configuration/assign-pod-node/)). {{< /note >}} Seluruh konfigurasi memiliki nama `handler` yang terkait, dijadikan referensi oleh RuntimeClass. @@ -91,7 +91,7 @@ spec: Kubelet akan mendapat instruksi untuk menggunakan RuntimeClass dengan nama yang sudah ditentukan tersebut untuk menjalankan Pod ini. Jika RuntimeClass dengan nama tersebut tidak ditemukan, atau CRI tidak dapat -menjalankan _handler_ yang terkait, maka Pod akan memasuki [tahap](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) `Failed`. +menjalankan _handler_ yang terkait, maka Pod akan memasuki [tahap](/id/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) `Failed`. Lihat [_event_](/docs/tasks/debug-application-cluster/debug-application-introspection/) untuk mengetahui pesan error yang terkait. Jika tidak ada `runtimeClassName` yang ditentukan di dalam Pod, maka RuntimeHandler yang _default_ akan digunakan. diff --git a/content/id/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/id/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index d8be642856..3a3ece65b0 100644 --- a/content/id/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/id/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -14,7 +14,7 @@ _Custom Resource_ adalah ekstensi dari Kubernetes API. Laman ini mendiskusikan k ## _Custom Resource_ -Sebuah sumber daya adalah sebuah *endpoint* pada [Kubernetes API](/docs/reference/using-api/api-overview/) yang menyimpan sebuah koleksi [objek API](/docs/concepts/overview/working-with-objects/kubernetes-objects/) dari sebuah jenis tertentu. Sebagai contoh, sumber daya bawaan Pod mengandung sebuah koleksi objek-objek Pod. +Sebuah sumber daya adalah sebuah *endpoint* pada [Kubernetes API](/docs/reference/using-api/api-overview/) yang menyimpan sebuah koleksi [objek API](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/) dari sebuah jenis tertentu. Sebagai contoh, sumber daya bawaan Pod mengandung sebuah koleksi objek-objek Pod. Sebuah _Custom Resource_ adalah sebuah ekstensi dari Kubernetes API yang tidak seharusnya tersedia pada pemasangan default Kubernetes. Namun, banyak fungsi-fungsi inti Kubernetes yang sekarang dibangun menggunakan _Custom Resource_, membuat Kubernetes lebih modular. @@ -25,7 +25,7 @@ dipasang, pengguna dapat membuat dan mengakses objek-objek _Custom Resource_ men Dengan sendirinya, _Custom Resource_ memungkinkan kamu untuk menyimpan dan mengambil data terstruktur. Ketika kamu menggabungkan sebuah _Custom Resource_ dengan _controller_ khusus, _Custom Resource_ akan memberikan sebuah API deklaratif yang sebenarnya. -Sebuah [API deklaratif](/docs/concepts/overview/working-with-objects/kubernetes-objects/#memahami-konsep-objek-objek-yang-ada-pada-kubernetes) +Sebuah [API deklaratif](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/#memahami-konsep-objek-objek-yang-ada-pada-kubernetes) memungkinkan kamu untuk mendeklarasikan atau menspesifikasikan keadaan dari sumber daya kamu dan mencoba untuk menjaga agar keadaan saat itu tersinkronisasi dengan keadaan yang diinginkan. *Controller* menginterpretasikan data terstruktur sebagai sebuah rekaman dari keadaan yang diinginkan pengguna, dan secara kontinu menjaga keadaan ini. Kamu bisa men-_deploy_ dan memperbaharui sebuah _controller_ khusus pada sebuah klaster yang berjalan, secara independen dari siklus hidup klaster itu sendiri. _Controller_ khusus dapat berfungsi dengan sumber daya jenis apapun, tetapi mereka sangat efektif ketika dikombinasikan dengan _Custom Resource_. [_Operator pattern_](https://coreos.com/blog/introducing-operators.html) mengkombinasikan _Custom Resource_ dan _controller_ khusus. Kamu bisa menggunakan _controller_ khusus untuk menyandi pengetahuan domain untuk aplikasi spesifik menjadi sebuah ekstensi dari Kubernetes API. @@ -40,7 +40,7 @@ Ketika membuat sebuah API baru, pikirkan apakah kamu ingin [mengagregasikan API | Kamu mau tipe baru yang dapat dibaca dan ditulis dengan `kubectl`.| Dukungan `kubectl` tidak diperlukan | | Kamu mau melihat tipe baru pada sebuah Kubernetes UI, seperti dasbor, bersama dengan tipe-tipe bawaan. | Dukungan Kubernetes UI tidak diperlukan. | | Kamu mengembangkan sebuah API baru. | Kamu memiliki sebuah program yang melayani API kamu dan dapat berkerja dengan baik. | -| Kamu bersedia menerima pembatasan format yang Kubernetes terapkan pada jalur sumber daya API (Lihat [Ikhtisar API](/docs/concepts/overview/kubernetes-api/).) | Kamu perlu memiliki jalur REST spesifik agar menjadi cocok dengan REST API yang telah didefinisikan. | +| Kamu bersedia menerima pembatasan format yang Kubernetes terapkan pada jalur sumber daya API (Lihat [Ikhtisar API](/id/docs/concepts/overview/kubernetes-api/).) | Kamu perlu memiliki jalur REST spesifik agar menjadi cocok dengan REST API yang telah didefinisikan. | | Sumber daya kamu secara alami mencakup hingga sebuah klaster atau sebuah *namespace* dari sebuah klaster. | Sumber daya yang mencakup klaster atau *namespace* adalah sebuah ketidakcocokan; kamu perlu mengendalikan jalur sumber daya spesifik. | | Kamu ingin menggunakan kembali [dukungan fitur Kubernetes API](#fitur-umum). | Kamu tidak membutuhkan fitur tersebut. | @@ -77,7 +77,7 @@ Gunakan ConfigMap jika salah satu hal berikut berlaku: * Kamu ingin melakukan pembaharuan bergulir lewat Deployment, dll, ketika berkas diperbaharui. {{< note >}} -Gunakan sebuah [Secret](/docs/concepts/configuration/secret/) untuk data sensitif, yang serupa dengan ConfigMap tetapi lebih aman. +Gunakan sebuah [Secret](/id/docs/concepts/configuration/secret/) untuk data sensitif, yang serupa dengan ConfigMap tetapi lebih aman. {{< /note >}} Gunakan sebuah _Custom Resource_ (CRD atau _Aggregated API_) jika kebanyakan dari hal berikut berlaku: @@ -93,11 +93,11 @@ Gunakan sebuah _Custom Resource_ (CRD atau _Aggregated API_) jika kebanyakan dar Kubernetes menyediakan dua cara untuk menambahkan sumber daya ke klaster kamu: - CRD cukup sederhana dan bisa diciptakan tanpa pemrograman apapun. -- [Agregasi API](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) membutuhkan pemrograman, tetapi memungkinkan kendali lebih terhadap perilaku API seperti bagaimana data disimpan dan perubahan antar versi API. +- [Agregasi API](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) membutuhkan pemrograman, tetapi memungkinkan kendali lebih terhadap perilaku API seperti bagaimana data disimpan dan perubahan antar versi API. Kubernetes menyediakan kedua opsi tersebut untuk memenuhi kebutuhan pengguna berbeda, jadi tidak ada kemudahan penggunaan atau fleksibilitas yang dikompromikan. -_Aggregated API_ adalah bawahan dari APIServer yang duduk dibelakang API server utama, yang bertindak sebagai sebuah _proxy_. Pengaturan ini disebut [Agregasi API](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) (AA). Untuk pengguna, yang terlihat adalah Kubernetes API yang diperluas. +_Aggregated API_ adalah bawahan dari APIServer yang duduk dibelakang API server utama, yang bertindak sebagai sebuah _proxy_. Pengaturan ini disebut [Agregasi API](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) (AA). Untuk pengguna, yang terlihat adalah Kubernetes API yang diperluas. CRD memungkinkan pengguna untuk membuat tipe baru sumber daya tanpa menambahkan APIserver lain. Kamu tidak perlu mengerti Agregasi API untuk menggunakan CRD. @@ -115,7 +115,7 @@ Lihat [contoh *controller* khusus](https://github.com/kubernetes/sample-controll Biasanya, tiap sumber daya di API Kubernetes membutuhkan kode yang menangani permintaan REST dan mengatur peyimpanan tetap dari objek-objek. Server Kubernetes API utama menangani sumber daya bawaan seperti Pod dan Service, dan juga menangani _Custom Resource_ dalam sebuah cara yang umum melalui [CRD](#customresourcedefinition). -[Lapisan agregasi](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) memungkinkan kamu untuk menyediakan implementasi khusus untuk _Custom Resource_ dengan menulis dan men-_deploy_ API server kamu yang berdiri sendiri. API server utama menlimpahkan permintaan kepada kamu untuk _Custom Resource_ yang kamu tangani, membuat mereka tersedia untuk semua kliennya. +[Lapisan agregasi](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) memungkinkan kamu untuk menyediakan implementasi khusus untuk _Custom Resource_ dengan menulis dan men-_deploy_ API server kamu yang berdiri sendiri. API server utama menlimpahkan permintaan kepada kamu untuk _Custom Resource_ yang kamu tangani, membuat mereka tersedia untuk semua kliennya. ## Memilih sebuah metode untuk menambahkan _Custom Resource_ @@ -216,7 +216,7 @@ Ketika kamu menambahkan sebuah _Custom Resource_, kamu dapat mengaksesnya dengan ## {{% heading "whatsnext" %}} -* Belajar bagaimana untuk [Memperluas Kubernetes API dengan lapisan agregasi](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/). +* Belajar bagaimana untuk [Memperluas Kubernetes API dengan lapisan agregasi](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/). * Belajar bagaimana untuk [Memperluas Kubernetes API dengan CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/). diff --git a/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index 3bde2909ca..62f7c8d41d 100644 --- a/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/id/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -37,7 +37,7 @@ Dalam pendaftaran, _plugin_ perangkat perlu mengirim: * Nama Unix socket-nya. * Versi API Plugin Perangkat yang dipakai. * `ResourceName` yang ingin ditunjukkan. `ResourceName` ini harus mengikuti - [skema penamaan sumber daya ekstensi](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) + [skema penamaan sumber daya ekstensi](/id/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) sebagai `vendor-domain/tipe-sumber-daya`. (Contohnya, NVIDIA GPU akan dinamai `nvidia.com/gpu`.) diff --git a/content/id/docs/concepts/extend-kubernetes/extend-cluster.md b/content/id/docs/concepts/extend-kubernetes/extend-cluster.md index b7b07b46ff..9d80881724 100644 --- a/content/id/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/id/docs/concepts/extend-kubernetes/extend-cluster.md @@ -36,7 +36,7 @@ _Flag-flag_ dan _berkas-berkas konfigurasi_ didokumentasikan di bagian Referensi _Flag-flag_ dan berkas-berkas konfigurasi mungkin tidak selalu dapat diubah pada layanan Kubernetes yang _hosted_ atau pada distribusi dengan instalasi yang dikelola. Ketika mereka dapat diubah, mereka biasanya hanya dapat diubah oleh Administrator Klaster. Dan juga, mereka dapat sewaktu-waktu diubah dalam versi Kubernetes di masa depan, dan menyetel mereka mungkin memerlukan proses pengulangan kembali. Oleh karena itu, mereka harus digunakan hanya ketika tidak ada pilihan lain. -*API kebijakan bawaan*, seperti [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) dan Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), adalah API bawaan Kubernetes. API biasanya digunakan oleh layanan Kubernetes yang _hosted_ dan diatur oleh instalasi Kubernetes. Mereka bersifat deklaratif dan menggunakan konvensi yang sama dengan sumber daya Kubernetes lainnya seperti pod-pod, jadi konfigurasi klaster baru dapat diulang-ulang dan dapat diatur dengan cara yang sama dengan aplikasi. Dan, ketika mereka stabil, mereka mendapatkan keuntungan dari [kebijakan pendukung yang jelas](/docs/reference/deprecation-policy/) seperti API Kubernetes lainnya. Oleh karena itu, mereka lebih disukai daripada _berkas konfigurasi_ dan _flag-flag_ saat mereka cocok dengan situasi yang dibutuhkan. +*API kebijakan bawaan*, seperti [ResourceQuota](/id/docs/concepts/policy/resource-quotas/), [PodSecurityPolicy](/id/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/id/docs/concepts/services-networking/network-policies/) dan Role-based Access Control ([RBAC](/id/docs/reference/access-authn-authz/rbac/)), adalah API bawaan Kubernetes. API biasanya digunakan oleh layanan Kubernetes yang _hosted_ dan diatur oleh instalasi Kubernetes. Mereka bersifat deklaratif dan menggunakan konvensi yang sama dengan sumber daya Kubernetes lainnya seperti pod-pod, jadi konfigurasi klaster baru dapat diulang-ulang dan dapat diatur dengan cara yang sama dengan aplikasi. Dan, ketika mereka stabil, mereka mendapatkan keuntungan dari [kebijakan pendukung yang jelas](/docs/reference/deprecation-policy/) seperti API Kubernetes lainnya. Oleh karena itu, mereka lebih disukai daripada _berkas konfigurasi_ dan _flag-flag_ saat mereka cocok dengan situasi yang dibutuhkan. ## Perluasan @@ -107,7 +107,7 @@ Untuk lebih jelasnya tentang Sumber Daya _Custom_, lihat [Panduan Konsep Sumber ### Menggabungkan API Baru dengan Otomasi -Kombinasi antara sebuah API sumber daya _custom_ dan _loop_ kontrol disebut [Pola Operator](/docs/concepts/extend-kubernetes/operator/). Pola Operator digunakan untuk mengelola aplikasi yang spesifik dan biasanya _stateful_. API-API _custom_ dan _loop_ kontrol ini dapat digunakan untuk mengatur sumber daya lainnya, seperti penyimpanan dan kebijakan-kebijakan. +Kombinasi antara sebuah API sumber daya _custom_ dan _loop_ kontrol disebut [Pola Operator](/id/docs/concepts/extend-kubernetes/operator/). Pola Operator digunakan untuk mengelola aplikasi yang spesifik dan biasanya _stateful_. API-API _custom_ dan _loop_ kontrol ini dapat digunakan untuk mengatur sumber daya lainnya, seperti penyimpanan dan kebijakan-kebijakan. ### Mengubah Sumber Daya Bawaan @@ -173,6 +173,6 @@ Penjadwal juga mendukung [_webhook_](https://github.com/kubernetes/community/blo * [_Plugin_ Jaringan](/docs/concepts/cluster-administration/network-plugins/) * [_Plugin_ Perangkat](/docs/concepts/cluster-administration/device-plugins/) * Pelajari tentang [_Plugin_ kubectl](/docs/tasks/extend-kubectl/kubectl-plugins/) -* Pelajari tentang [Pola Operator](/docs/concepts/extend-kubernetes/operator/) +* Pelajari tentang [Pola Operator](/id/docs/concepts/extend-kubernetes/operator/) diff --git a/content/id/docs/concepts/extend-kubernetes/operator.md b/content/id/docs/concepts/extend-kubernetes/operator.md index 269f7312a1..315ae35e3d 100644 --- a/content/id/docs/concepts/extend-kubernetes/operator.md +++ b/content/id/docs/concepts/extend-kubernetes/operator.md @@ -7,7 +7,7 @@ weight: 30 Operator adalah ekstensi perangkat lunak untuk Kubernetes yang memanfaatkan -[_custom resource_](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +[_custom resource_](/id/docs/concepts/extend-kubernetes/api-extension/custom-resources/) untuk mengelola aplikasi dan komponen-komponennya. Operator mengikuti prinsip Kubernetes, khususnya dalam hal [_control loop_](/docs/concepts/#kubernetes-control-plane). @@ -126,7 +126,7 @@ menggunakan bahasa / _runtime_ yang dapat bertindak sebagai ## {{% heading "whatsnext" %}} -* Memahami lebih lanjut tentang [_custome resources_](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +* Memahami lebih lanjut tentang [_custome resources_](/id/docs/concepts/extend-kubernetes/api-extension/custom-resources/) * Temukan "ready-made" _operators_ dalam [OperatorHub.io](https://operatorhub.io/) untuk memenuhi use case kamu * Menggunakan perangkat yang ada untuk menulis Operator kamu sendiri, misalnya: diff --git a/content/id/docs/concepts/extend-kubernetes/service-catalog.md b/content/id/docs/concepts/extend-kubernetes/service-catalog.md index efea4eda97..cd63a89355 100644 --- a/content/id/docs/concepts/extend-kubernetes/service-catalog.md +++ b/content/id/docs/concepts/extend-kubernetes/service-catalog.md @@ -46,7 +46,7 @@ untuk berkomunikasi dengan makelar servis, bertindak sebagai perantara untuk API merundingkan penyediaan awal dan mengambil kredensial untuk aplikasi bisa menggunakan servis terkelola tersebut. Ini terimplementasi sebagai ekstensi API Server dan pengontrol, menggunakan etcd sebagai media penyimpanan. -Ini juga menggunakan [lapisan agregasi](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) +Ini juga menggunakan [lapisan agregasi](/id/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) yang tersedia pada Kubernetes versi 1.7+ untuk menampilkan API-nya.
diff --git a/content/id/docs/concepts/overview/components.md b/content/id/docs/concepts/overview/components.md index 63e7b4b3af..aa2ee52152 100644 --- a/content/id/docs/concepts/overview/components.md +++ b/content/id/docs/concepts/overview/components.md @@ -120,7 +120,7 @@ Meskipun tidak semua addons dibutuhkan, semua klaster Kubernetes hendakny memiliki DNS klaster. Komponen ini penting karena banyak dibutuhkan oleh komponen lainnya. -[Klaster DNS](/docs/concepts/cluster-administration/addons/) adalah server DNS, selain beberapa server DNS lain yang sudah ada di +[Klaster DNS](/id/docs/concepts/cluster-administration/addons/) adalah server DNS, selain beberapa server DNS lain yang sudah ada di environment kamu, yang berfungsi sebagai catatan DNS bagi Kubernetes services Kontainer yang dimulai oleh kubernetes secara otomatis akan memasukkan server DNS ini @@ -129,7 +129,7 @@ ke dalam mekanisme pencarian DNS yang dimilikinya. ### Web UI (Dasbor) -[Dasbor](/docs/tasks/access-application-cluster/web-ui-dashboard/) adalah antar muka berbasis web multifungsi yang ada pada klaster Kubernetes. +[Dasbor](/id/docs/tasks/access-application-cluster/web-ui-dashboard/) adalah antar muka berbasis web multifungsi yang ada pada klaster Kubernetes. Dasbor ini memungkinkan user melakukan manajemen dan troubleshooting klaster maupun aplikasi yang ada pada klaster itu sendiri. @@ -143,7 +143,7 @@ untuk melakukan pencarian data yang dibutuhkan. ### Cluster-level Logging -[Cluster-level logging](/docs/concepts/cluster-administration/logging/) bertanggung jawab mencatat log kontainer pada +[Cluster-level logging](/id/docs/concepts/cluster-administration/logging/) bertanggung jawab mencatat log kontainer pada penyimpanan log terpusat dengan antar muka yang dapat digunakan untuk melakukan pencarian. diff --git a/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md b/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md index 9599feaf24..46066769d4 100644 --- a/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md +++ b/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md @@ -25,8 +25,8 @@ Lihat [Pengelolaan Objek Kubernetes](/docs/concepts/overview/object-management-k Konfigurasi objek secara deklaratif membutuhkan pemahaman yang baik tentang definisi dan konfigurasi objek-objek Kubernetes. Jika belum pernah, kamu disarankan untuk membaca terlebih dulu dokumen-dokumen berikut: -- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-command/) -- [Pengelolaan Objek Kubernetes Menggunakan File Konfigurasi Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-config/) +- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-command/) +- [Pengelolaan Objek Kubernetes Menggunakan File Konfigurasi Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-config/) Berikut adalah beberapa defnisi dari istilah-istilah yang digunakan dalam dokumen ini: @@ -862,8 +862,8 @@ template: ## {{% heading "whatsnext" %}} -- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-command/) -- [Pengelolaan Objek Kubernetes secara Imperatif Menggunakan File Konfigurasi](/docs/concepts/overview/object-management-kubectl/imperative-config/) +- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-command/) +- [Pengelolaan Objek Kubernetes secara Imperatif Menggunakan File Konfigurasi](/id/docs/concepts/overview/object-management-kubectl/imperative-config/) - [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl/) - [Rujukan API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) diff --git a/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md b/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md index e77cc9ca63..23489efb59 100644 --- a/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md +++ b/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md @@ -126,8 +126,8 @@ kubectl create --edit -f /tmp/srv.yaml ## {{% heading "whatsnext" %}} -- [Pengelolaan Objek Kubernetes secara Imperatif dengan Menggunakan Konfigurasi Objek](/docs/concepts/overview/object-management-kubectl/imperative-config/) -- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/docs/concepts/overview/object-management-kubectl/declarative-config/) +- [Pengelolaan Objek Kubernetes secara Imperatif dengan Menggunakan Konfigurasi Objek](/id/docs/concepts/overview/object-management-kubectl/imperative-config/) +- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/id/docs/concepts/overview/object-management-kubectl/declarative-config/) - [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl/) - [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) diff --git a/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md b/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md index 7df68f579d..94f1082e35 100644 --- a/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md +++ b/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md @@ -108,8 +108,8 @@ template: ## {{% heading "whatsnext" %}} -- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/docs/concepts/overview/object-management-kubectl/imperative-command/) -- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/docs/concepts/overview/object-management-kubectl/declarative-config/) +- [Pengelolaan Objek Kubernetes Menggunakan Perintah Imperatif](/id/docs/concepts/overview/object-management-kubectl/imperative-command/) +- [Pengelolaan Objek Kubernetes secara Deklaratif dengan Menggunakan File Konfigurasi](/id/docs/concepts/overview/object-management-kubectl/declarative-config/) - [Rujukan Perintah Kubectl](/docs/reference/generated/kubectl/kubectl/) - [Rujukan API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) diff --git a/content/id/docs/concepts/overview/working-with-objects/annotations.md b/content/id/docs/concepts/overview/working-with-objects/annotations.md index 8a822f255d..aaa238add5 100644 --- a/content/id/docs/concepts/overview/working-with-objects/annotations.md +++ b/content/id/docs/concepts/overview/working-with-objects/annotations.md @@ -80,5 +80,5 @@ Prefiks `kubernetes.io/` dan `k8s.io/` merupakan reservasi dari komponen inti Ku ## {{% heading "whatsnext" %}} -Pelajari lebih lanjut tentang [Label dan Selektor](/docs/concepts/overview/working-with-objects/labels/). +Pelajari lebih lanjut tentang [Label dan Selektor](/id/docs/concepts/overview/working-with-objects/labels/). diff --git a/content/id/docs/concepts/overview/working-with-objects/field-selectors.md b/content/id/docs/concepts/overview/working-with-objects/field-selectors.md index 7cd81495cd..e46916ee3d 100644 --- a/content/id/docs/concepts/overview/working-with-objects/field-selectors.md +++ b/content/id/docs/concepts/overview/working-with-objects/field-selectors.md @@ -3,14 +3,14 @@ title: Selektor Field weight: 60 --- -Selektor *field* memungkinkan kamu untuk [memilih (*select*) *resource* Kubernetes](/docs/concepts/overview/working-with-objects/kubernetes-objects) berdasarkan +Selektor *field* memungkinkan kamu untuk [memilih (*select*) *resource* Kubernetes](/id/docs/concepts/overview/working-with-objects/kubernetes-objects) berdasarkan nilai dari satu atau banyak *field resource*. Di bawah ini merupakan contoh dari beberapa *query* selektor *field*: * `metadata.name=my-service` * `metadata.namespace!=default` * `status.phase=Pending` -Perintah `kubectl` di bawah ini memilih semua Pod dengan *field* [`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) yang bernilai +Perintah `kubectl` di bawah ini memilih semua Pod dengan *field* [`status.phase`](/id/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) yang bernilai `Running`: ```shell @@ -50,7 +50,7 @@ kubectl get services --field-selector metadata.namespace!=default ## Selektor berantai -Seperti halnya [label](/docs/concepts/overview/working-with-objects/labels) dan selektor-selektor lainnya, kamu dapat membuat selektor *field* berantai +Seperti halnya [label](/id/docs/concepts/overview/working-with-objects/labels) dan selektor-selektor lainnya, kamu dapat membuat selektor *field* berantai (*chained*) dengan *list* yang dipisahkan oleh koma. Perintah `kubectl` di bawah ini memilih semua Pod dengan `status.phase` tidak sama dengan `Running` dan *field* `spec.restartPolicy` sama dengan `Always`: diff --git a/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 57eef5e9c6..aa702827b9 100644 --- a/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -30,7 +30,7 @@ memberikan informasi pada sistem Kubernetes mengenai perilaku apakah yang kamu i dengan kata lain ini merupakan definisi _state_ klaster yang kamu inginkan. Untuk menggunakan objek-objek Kubernetes--baik membuat, mengubah, atau menghapus objek-objek tersebut--kamu -harus menggunakan [API Kubernetes](/docs/concepts/overview/kubernetes-api/). +harus menggunakan [API Kubernetes](/id/docs/concepts/overview/kubernetes-api/). Ketika kamu menggunakan perintah `kubectl`, perintah ini akan melakukan _API call_ untuk perintah yang kamu berikan. Kamu juga dapat menggunakan API Kubernetes secara langsung pada program yang kamu miliki menggunakan salah satu [_library_ klien](/docs/reference/using-api/client-libraries/) yang disediakan. @@ -103,7 +103,7 @@ dan format _spec_ untuk _Deployment_ dapat ditemukan ## {{% heading "whatsnext" %}} -* Pelajari lebih lanjut mengenai dasar-dasar penting bagi objek Kubernetes, seperti [Pod](/docs/concepts/workloads/pods/pod-overview/). +* Pelajari lebih lanjut mengenai dasar-dasar penting bagi objek Kubernetes, seperti [Pod](/id/docs/concepts/workloads/pods/pod-overview/). diff --git a/content/id/docs/concepts/overview/working-with-objects/names.md b/content/id/docs/concepts/overview/working-with-objects/names.md index 5527c15b72..0d6528c41d 100644 --- a/content/id/docs/concepts/overview/working-with-objects/names.md +++ b/content/id/docs/concepts/overview/working-with-objects/names.md @@ -8,7 +8,7 @@ weight: 20 Seluruh objek di dalam REST API Kubernetes secara jelas ditandai dengan nama dan UID. -Apabila pengguna ingin memberikan atribut tidak unik, Kubernetes menyediakan [label](/docs/user-guide/labels) dan [anotasi](/docs/concepts/overview/working-with-objects/annotations/). +Apabila pengguna ingin memberikan atribut tidak unik, Kubernetes menyediakan [label](/docs/user-guide/labels) dan [anotasi](/id/docs/concepts/overview/working-with-objects/annotations/). Bacalah [dokumentasi desain penanda](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) agar kamu dapat memahami lebih lanjut sintaks yang digunakan untuk Nama dan UID. diff --git a/content/id/docs/concepts/overview/working-with-objects/namespaces.md b/content/id/docs/concepts/overview/working-with-objects/namespaces.md index 5eb358a17a..89ffb8ea14 100644 --- a/content/id/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/id/docs/concepts/overview/working-with-objects/namespaces.md @@ -19,7 +19,7 @@ Kubernetes mendukung banyak klaster virtual di dalam satu klaster fisik. Klaster *Namespace* menyediakan ruang untuk nama objek. Nama dari *resource* atau objek harus berbeda di dalam sebuah *namespace*, tetapi boleh sama jika berbeda *namespace*. *Namespace* tidak bisa dibuat di dalam *namespace* lain dan setiap *resource* atau objek Kubernetes hanya dapat berada di dalam satu *namespace*. -*Namespace* merupakan cara yang digunakan untuk memisahkan *resource* klaster untuk beberapa pengguna (dengan [*resource quota*](/docs/concepts/policy/resource-quotas/)). +*Namespace* merupakan cara yang digunakan untuk memisahkan *resource* klaster untuk beberapa pengguna (dengan [*resource quota*](/id/docs/concepts/policy/resource-quotas/)). Dalam versi Kubernetes yang akan datang, objek di dalam satu *namespace* akan mempunyai *access control policies* yang sama secara *default*. @@ -74,7 +74,7 @@ kubectl config view | grep namespace: ## Namespace dan DNS -Saat kamu membuat sebuah [Service](/docs/user-guide/services), Kubernetes membuat [Entri DNS](/docs/concepts/services-networking/dns-pod-service/) untuk *service* tersebut. Entri *DNS* ini berformat `..svc.cluster.local`, yang berarti jika sebuah kontainer hanya menggunakan ``, kontainer tersebut akan berkomunikasi dengan *service* yang berada di dalam satu *namespace*. Ini berguna untuk menggunakan konfigurasi yang sama di beberapa *namespace* seperti *Development*, *Staging*, dan *Production*. Jika kamu ingin berkomunikasi antar *namespace*, kamu harus menggunakan seluruh *fully qualified domain name (FQDN)*. +Saat kamu membuat sebuah [Service](/docs/user-guide/services), Kubernetes membuat [Entri DNS](/id/docs/concepts/services-networking/dns-pod-service/) untuk *service* tersebut. Entri *DNS* ini berformat `..svc.cluster.local`, yang berarti jika sebuah kontainer hanya menggunakan ``, kontainer tersebut akan berkomunikasi dengan *service* yang berada di dalam satu *namespace*. Ini berguna untuk menggunakan konfigurasi yang sama di beberapa *namespace* seperti *Development*, *Staging*, dan *Production*. Jika kamu ingin berkomunikasi antar *namespace*, kamu harus menggunakan seluruh *fully qualified domain name (FQDN)*. ## Tidak semua objek di dalam Namespace diff --git a/content/id/docs/concepts/policy/pod-security-policy.md b/content/id/docs/concepts/policy/pod-security-policy.md index 2dbbd53144..991ebb44aa 100644 --- a/content/id/docs/concepts/policy/pod-security-policy.md +++ b/content/id/docs/concepts/policy/pod-security-policy.md @@ -45,13 +45,13 @@ Sejak API dari Pod Security Policy (`policy/v1beta1/podsecuritypolicy`) diaktifk ## Mengizinkan Kebijakan -Saat sebuah sumber daya PodSecurityPolicy dibuat, ia tidak melakukan apa-apa. Untuk menggunakannya, [Service Account](/docs/tasks/configure-pod-container/configure-service-account/) dari pengguna yang memintanya atau target Pod-nya harus diizinkan terlebih dahulu untuk menggunakan kebijakan tersebut, dengan membolehkan kata kerja `use` terhadap kebijakan tersebut. +Saat sebuah sumber daya PodSecurityPolicy dibuat, ia tidak melakukan apa-apa. Untuk menggunakannya, [Service Account](/id/docs/tasks/configure-pod-container/configure-service-account/) dari pengguna yang memintanya atau target Pod-nya harus diizinkan terlebih dahulu untuk menggunakan kebijakan tersebut, dengan membolehkan kata kerja `use` terhadap kebijakan tersebut. -Kebanyakan Pod Kubernetes tidak dibuat secara langsung oleh pengguna. Sebagai gantinya, mereka biasanya dibuat secara tidak langsung sebagai bagian dari sebuah [Deployment](/docs/concepts/workloads/controllers/deployment/), [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/), atau pengontrol yang sudah ditemplat lainnya melalui Controller Manager. Memberikan akses untuk pengontrol terhadap kebijakan tersebut akan mengizinkan akses untuk *semua* Pod yang dibuat oleh pengontrol tersebut, sehingga metode yang lebih baik untuk mengizinkan kebijakan adalah dengan memberikan akses pada Service Account milik Pod (lihat [contohnya](#run-another-pod)). +Kebanyakan Pod Kubernetes tidak dibuat secara langsung oleh pengguna. Sebagai gantinya, mereka biasanya dibuat secara tidak langsung sebagai bagian dari sebuah [Deployment](/id/docs/concepts/workloads/controllers/deployment/), [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/), atau pengontrol yang sudah ditemplat lainnya melalui Controller Manager. Memberikan akses untuk pengontrol terhadap kebijakan tersebut akan mengizinkan akses untuk *semua* Pod yang dibuat oleh pengontrol tersebut, sehingga metode yang lebih baik untuk mengizinkan kebijakan adalah dengan memberikan akses pada Service Account milik Pod (lihat [contohnya](#run-another-pod)). ### Melalui RBAC -[RBAC](/docs/reference/access-authn-authz/rbac/) adalah mode otorisasi standar Kubernetes, dan dapat digunakan dengan mudah untuk mengotorisasi penggunaan kebijakan-kebijakan. +[RBAC](/id/docs/reference/access-authn-authz/rbac/) adalah mode otorisasi standar Kubernetes, dan dapat digunakan dengan mudah untuk mengotorisasi penggunaan kebijakan-kebijakan. Pertama-tama, sebuah `Role` atau `ClusterRole` perlu memberikan akses pada kata kerja `use` terhadap kebijakan-kebijakan yang diinginkan. `rules` yang digunakan untuk memberikan akses tersebut terlihat seperti berikut: @@ -103,12 +103,12 @@ Jika sebuah `RoleBinding` (bukan `ClusterRoleBinding`) digunakan, maka ia hanya name: system:authenticated ``` -Untuk lebih banyak contoh pengikatan RBAC, lihat [Contoh Role Binding](/docs/reference/access-authn-authz/rbac#role-binding-examples). +Untuk lebih banyak contoh pengikatan RBAC, lihat [Contoh Role Binding](/id/docs/reference/access-authn-authz/rbac#role-binding-examples). Untuk contoh lengkap untuk mengotorisasi sebuah PodSecurityPolicy, lihat [di bawah](#contoh). ### Mengatasi Masalah -- [Controller Manager](/docs/admin/kube-controller-manager/) harus dijalankan terhadap [port API yang telah diamankan](/docs/reference/access-authn-authz/controlling-access/), dan tidak boleh memiliki izin _superuser_, atau semua permintaan akan melewati modul-modul otentikasi dan otorisasi, semua objek PodSecurityPolicy tidak akan diizinkan, dan semua pengguna dapat membuat Container-container yang _privileged_. Untuk lebih detil tentang mengkonfigurasi otorisasi Controller Manager, lihat [Controller Roles](/docs/reference/access-authn-authz/rbac/#controller-roles). +- [Controller Manager](/docs/admin/kube-controller-manager/) harus dijalankan terhadap [port API yang telah diamankan](/docs/reference/access-authn-authz/controlling-access/), dan tidak boleh memiliki izin _superuser_, atau semua permintaan akan melewati modul-modul otentikasi dan otorisasi, semua objek PodSecurityPolicy tidak akan diizinkan, dan semua pengguna dapat membuat Container-container yang _privileged_. Untuk lebih detil tentang mengkonfigurasi otorisasi Controller Manager, lihat [Controller Roles](/id/docs/reference/access-authn-authz/rbac/#controller-roles). ## Urutan Kebijakan @@ -324,7 +324,7 @@ determines if any container in a pod can enable privileged mode. ### Volume dan _file system_ -**Volume** - Menyediakan sebuah daftar putih dari tipe-tipe Volume yang diizinkan. Nilai-nilai yang diizinkan sesuai dengan sumber Volume yang didefinisikan saat membuat sebuah Volume. Untuk daftar lengkap tipe-tipe Volume, lihat [tipe-tipe Volume](/docs/concepts/storage/volumes/#tipe-tipe-volume). Sebagai tambahan, `*` dapat digunakan untuk mengizinkan semua tipe Volume. +**Volume** - Menyediakan sebuah daftar putih dari tipe-tipe Volume yang diizinkan. Nilai-nilai yang diizinkan sesuai dengan sumber Volume yang didefinisikan saat membuat sebuah Volume. Untuk daftar lengkap tipe-tipe Volume, lihat [tipe-tipe Volume](/id/docs/concepts/storage/volumes/#tipe-tipe-volume). Sebagai tambahan, `*` dapat digunakan untuk mengizinkan semua tipe Volume. **Kumpulan Volume-volume minimal yang direkomendasikan** untuk PodSecurityPolicy baru adalah sebagai berikut: diff --git a/content/id/docs/concepts/policy/resource-quotas.md b/content/id/docs/concepts/policy/resource-quotas.md index 47bfa996bb..c001ef4a40 100644 --- a/content/id/docs/concepts/policy/resource-quotas.md +++ b/content/id/docs/concepts/policy/resource-quotas.md @@ -81,7 +81,7 @@ Berikut jenis-jenis sumber daya yang didukung: ### Resource Quota untuk sumber daya yang diperluas Sebagai tambahan untuk sumber daya yang disebutkan di atas, pada rilis 1.10, dukungan kuota untuk -[sumber daya yang diperluas](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) ditambahkan. +[sumber daya yang diperluas](/id/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) ditambahkan. Karena _overcommit_ tidak diperbolehkan untuk sumber daya yang diperluas, tidak masuk akal untuk menentukan keduanya; `requests` dan `limits` untuk sumber daya yang diperluas yang sama pada sebuah kuota. Jadi, untuk @@ -98,7 +98,7 @@ Lihat [Melihat dan Menyetel Kuota](#melihat-dan-menyetel-kuota) untuk informasi ## Resource Quota untuk penyimpanan -Kamu dapat membatasi jumlah total [sumber daya penyimpanan](/docs/concepts/storage/persistent-volumes/) yang dapat +Kamu dapat membatasi jumlah total [sumber daya penyimpanan](/id/docs/concepts/storage/persistent-volumes/) yang dapat diminta pada sebuah Namespace. Sebagai tambahan, kamu dapat membatasi penggunaan sumber daya penyimpanan berdasarkan _storage class_ @@ -107,9 +107,9 @@ sumber daya penyimpanan tersebut. | Nama Sumber Daya | Deskripsi | | --------------------- | ----------------------------------------------------------- | | `requests.storage` | Pada seluruh Persistent Volume Claim, jumlah `requests` penyimpanan tidak dapat melebihi nilai ini. | -| `persistentvolumeclaims` | Jumlah kuantitas [Persistent Volume Claim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat ada di dalam sebuah Namespace. | +| `persistentvolumeclaims` | Jumlah kuantitas [Persistent Volume Claim](/id/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat ada di dalam sebuah Namespace. | | `.storageclass.storage.k8s.io/requests.storage` | Pada seluruh Persistent Volume Claim yang dikaitkan dengan sebuah nama _storage-class_ (melalui kolom `storageClassName`), jumlah permintaan penyimpanan tidak dapat melebihi nilai ini. | -| `.storageclass.storage.k8s.io/persistentvolumeclaims` | Pada seluruh Persistent Volume Claim yang dikaitkan dengan sebuah nama _storage-class_ (melalui kolom `storageClassName`), jumlah kuantitas [Persistent Volume Claim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat ada di dalam sebuah Namespace. | +| `.storageclass.storage.k8s.io/persistentvolumeclaims` | Pada seluruh Persistent Volume Claim yang dikaitkan dengan sebuah nama _storage-class_ (melalui kolom `storageClassName`), jumlah kuantitas [Persistent Volume Claim](/id/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat ada di dalam sebuah Namespace. | Sebagai contoh, jika sebuah operator ingin membatasi penyimpanan dengan Storage Class `gold` yang berbeda dengan Storage Class `bronze`, maka operator tersebut dapat menentukan kuota sebagai berikut: @@ -163,7 +163,7 @@ Berikut jenis-jenis yang telah didukung: | Nama Sumber Daya | Deskripsi | | ------------------------------- | ------------------------------------------------- | | `configmaps` | Jumlah total ConfigMap yang dapat berada pada suatu Namespace. | -| `persistentvolumeclaims` | Jumlah total PersistentVolumeClaim[persistent volume claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat berada pada suatu Namespace. | +| `persistentvolumeclaims` | Jumlah total PersistentVolumeClaim[persistent volume claims](/id/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) yang dapat berada pada suatu Namespace. | | `pods` | Jumlah total Pod yang berada pada kondisi non-terminal yang dapat berada pada suatu Namespace. Sebuah Pod berada kondisi terminal yaitu jika `.status.phase in (Failed, Succeded)` adalah `true`. | | `replicationcontrollers` | Jumlah total ReplicationController yang dapat berada pada suatu Namespace. | | `resourcequotas` | Jumlah total [ResourceQuota](/docs/reference/access-authn-authz/admission-controllers/#resourcequota) yang dapat berada pada suatu Namespace. | @@ -208,7 +208,7 @@ Lingkup `Terminating`, `NotTerminating`, dan `NotBestEffort` membatasi sebuah k {{< feature-state for_k8s_version="1.12" state="beta" >}} -Pod-Pod dapat dibuat dengan sebuah [Priority (prioritas)](/docs/concepts/configuration/pod-priority-preemption/#pod-priority) tertentu. +Pod-Pod dapat dibuat dengan sebuah [Priority (prioritas)](/id/docs/concepts/configuration/pod-priority-preemption/#pod-priority) tertentu. Kamu dapat mengontrol konsumsi sumber daya sistem sebuah Pod berdasarkan Priority Pod tersebut, menggunakan kolom `scopeSelector` pada spesifikasi kuota tersebut. diff --git a/content/id/docs/concepts/scheduling/kube-scheduler.md b/content/id/docs/concepts/scheduling/kube-scheduler.md index f4cd477608..6f7efab3d9 100644 --- a/content/id/docs/concepts/scheduling/kube-scheduler.md +++ b/content/id/docs/concepts/scheduling/kube-scheduler.md @@ -94,10 +94,10 @@ penilaian oleh penjadwal: ## {{% heading "whatsnext" %}} -* Baca tentang [penyetelan performa penjadwal](/docs/concepts/scheduling/scheduler-perf-tuning/) -* Baca tentang [pertimbangan penyebarang topologi pod](/docs/concepts/workloads/pods/pod-topology-spread-constraints/) +* Baca tentang [penyetelan performa penjadwal](/id/docs/concepts/scheduling/scheduler-perf-tuning/) +* Baca tentang [pertimbangan penyebarang topologi pod](/id/docs/concepts/workloads/pods/pod-topology-spread-constraints/) * Baca [referensi dokumentasi](/docs/reference/command-line-tools-reference/kube-scheduler/) untuk _kube-scheduler_ * Pelajari tentang [mengkonfigurasi beberapa penjadwal](/docs/tasks/administer-cluster/configure-multiple-schedulers/) * Pelajari tentang [aturan manajemen topologi](/docs/tasks/administer-cluster/topology-manager/) -* Pelajari tentang [pengeluaran tambahan Pod](/docs/concepts/configuration/pod-overhead/) +* Pelajari tentang [pengeluaran tambahan Pod](/id/docs/concepts/configuration/pod-overhead/) diff --git a/content/id/docs/concepts/scheduling/scheduler-perf-tuning.md b/content/id/docs/concepts/scheduling/scheduler-perf-tuning.md index 0a20d9050a..3689ecf7cb 100644 --- a/content/id/docs/concepts/scheduling/scheduler-perf-tuning.md +++ b/content/id/docs/concepts/scheduling/scheduler-perf-tuning.md @@ -8,7 +8,7 @@ weight: 70 {{< feature-state for_k8s_version="v1.14" state="beta" >}} -[kube-scheduler](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler) +[kube-scheduler](/id/docs/concepts/scheduling/kube-scheduler/#kube-scheduler) merupakan penjadwal (_scheduler_) Kubernetes bawaan yang bertanggung jawab terhadap penempatan Pod-Pod pada seluruh Node di dalam sebuah klaster. @@ -66,7 +66,7 @@ Kamu bisa mengatur ambang batas untuk menentukan berapa banyak jumlah Node minim persentase bagian dari seluruh Node di dalam klaster kamu. kube-scheduler akan mengubahnya menjadi bilangan bulat berisi jumlah Node. Saat penjadwalan, jika kube-scheduler mengidentifikasi cukup banyak Node-Node layak untuk melewati jumlah persentase yang diatur, maka kube-scheduler -akan berhenti mencari Node-Node layak dan lanjut ke [fase penskoran] (/docs/concepts/scheduling/kube-scheduler/#kube-scheduler-implementation). +akan berhenti mencari Node-Node layak dan lanjut ke [fase penskoran] (/id/docs/concepts/scheduling/kube-scheduler/#kube-scheduler-implementation). [Bagaimana penjadwal mengecek Node](#bagaimana-penjadwal-mengecek-node) menjelaskan proses ini secara detail. diff --git a/content/id/docs/concepts/security/overview.md b/content/id/docs/concepts/security/overview.md index caff040bc5..bc271e0645 100644 --- a/content/id/docs/concepts/security/overview.md +++ b/content/id/docs/concepts/security/overview.md @@ -107,11 +107,11 @@ Kebanyakan dari saran yang disebut di atas dapat diotomasi di dalam _delivery pi ## {{% heading "whatsnext" %}} -* Pelajari tentang [Network Policy untuk Pod](/docs/concepts/services-networking/network-policies/) +* Pelajari tentang [Network Policy untuk Pod](/id/docs/concepts/services-networking/network-policies/) * Pelajari tentang [mengamankan klaster kamu](/docs/tasks/administer-cluster/securing-a-cluster/) * Pelajari tentang [kontrol akses API](/docs/reference/access-authn-authz/controlling-access/) -* Pelajari tentang [enkripsi data saat transit](/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane +* Pelajari tentang [enkripsi data saat transit](/id/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane * Pelajari tentang [enkripsi data saat diam](/docs/tasks/administer-cluster/encrypt-data/) -* Pelajari tentang [Secret (data sensitif) pada Kubernetes](/docs/concepts/configuration/secret/) +* Pelajari tentang [Secret (data sensitif) pada Kubernetes](/id/docs/concepts/configuration/secret/) diff --git a/content/id/docs/concepts/services-networking/connect-applications-service.md b/content/id/docs/concepts/services-networking/connect-applications-service.md index 4bbd0bbf56..806fff3a46 100644 --- a/content/id/docs/concepts/services-networking/connect-applications-service.md +++ b/content/id/docs/concepts/services-networking/connect-applications-service.md @@ -47,7 +47,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP Kamu dapat melakukan akses dengan *ssh* ke dalam *node* di dalam klaster dan mengakses IP *Pod* tersebut menggunakan *curl*. Perlu dicatat bahwa kontainer tersebut tidak menggunakan *port* 80 di dalam *node*, atau aturan *NAT* khusus untuk merutekan trafik ke dalam *Pod*. Ini berarti kamu dapat menjalankan banyak *nginx Pod* di *node* yang sama dimana setiap *Pod* dapat menggunakan *containerPort* yang sama, kamu dapat mengakses semua itu dari *Pod* lain ataupun dari *node* di dalam klaster menggunakan IP. Seperti *Docker*, *port* masih dapat di publikasi ke dalam * interface node*, tetapi kebutuhan seperti ini sudah berkurang karena model jaringannya. -Kamu dapat membaca lebih detail [bagaimana kita melakukan ini](/docs/concepts/cluster-administration/networking/#how-to-achieve-this) jika kamu penasaran. +Kamu dapat membaca lebih detail [bagaimana kita melakukan ini](/id/docs/concepts/cluster-administration/networking/#how-to-achieve-this) jika kamu penasaran. ## Membuat Service @@ -107,7 +107,7 @@ NAME ENDPOINTS AGE my-nginx 10.244.2.5:80,10.244.3.4:80 1m ``` -Kamu sekarang dapat melakukan *curl* ke dalam *nginx Service* di `:` dari *node* manapun di klaster. Perlu dicatat bahwa *Service IP* adalah IP virtual, IP tersebut tidak pernah ada di *interface node* manapun. Jika kamu penasaran bagaimana konsep ini bekerja, kamu dapat membaca lebih lanjut tentang [service proxy](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies). +Kamu sekarang dapat melakukan *curl* ke dalam *nginx Service* di `:` dari *node* manapun di klaster. Perlu dicatat bahwa *Service IP* adalah IP virtual, IP tersebut tidak pernah ada di *interface node* manapun. Jika kamu penasaran bagaimana konsep ini bekerja, kamu dapat membaca lebih lanjut tentang [service proxy](/id/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies). ## Mengakses Service @@ -194,7 +194,7 @@ Hingga sekarang kita hanya mengakses *nginx* server dari dalam klaster. Sebelum * *Self signed certificates* untuk *https* (kecuali jika kamu sudah mempunyai *identity certificate*) * Sebuah server *nginx* yang terkonfigurasi untuk menggunakan *certificate* tersebut -* Sebuah [secret](/docs/concepts/configuration/secret/) yang membuat setifikat tersebut dapat diakses oleh *pod* +* Sebuah [secret](/id/docs/concepts/configuration/secret/) yang membuat setifikat tersebut dapat diakses oleh *pod* Kamu dapat melihat semua itu di [contoh nginx https](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/). Contoh ini mengaharuskan kamu melakukan instalasi *go* dan *make*. Jika kamu tidak ingin melakukan instalasi tersebut, ikuti langkah-langkah manualnya nanti, singkatnya: @@ -362,6 +362,6 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el ## {{% heading "whatsnext" %}} -Kubernetes juga mendukung *Federated Service*, yang bisa mempengaruhi banyak klaster dan penyedia layanan *cloud*, untuk meningkatkan ketersediaan, peningkatan toleransi kesalahan, dan pengembangan dari *Service* kamu. Lihat [Panduan Federated Service](/docs/concepts/cluster-administration/federation-service-discovery/) untuk informasi lebih lanjut. +Kubernetes juga mendukung *Federated Service*, yang bisa mempengaruhi banyak klaster dan penyedia layanan *cloud*, untuk meningkatkan ketersediaan, peningkatan toleransi kesalahan, dan pengembangan dari *Service* kamu. Lihat [Panduan Federated Service](/id/docs/concepts/cluster-administration/federation-service-discovery/) untuk informasi lebih lanjut. diff --git a/content/id/docs/concepts/services-networking/dns-pod-service.md b/content/id/docs/concepts/services-networking/dns-pod-service.md index 52ec19a420..efdba8d7a1 100644 --- a/content/id/docs/concepts/services-networking/dns-pod-service.md +++ b/content/id/docs/concepts/services-networking/dns-pod-service.md @@ -50,7 +50,7 @@ menggunakan penjadwalan Round-Robin dari set yang ada. ### SRV _record_ SRV _record_ dibuat untuk port bernama yang merupakan bagian dari Service normal maupun [Headless -Services](/docs/concepts/services-networking/service/#headless-services). +Services](/id/docs/concepts/services-networking/service/#headless-services). Untuk setiap port bernama, SRV _record_ akan memiliki format `_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`. Untuk sebuah Service normal, ini akan melakukan resolusi pada nomor port dan diff --git a/content/id/docs/concepts/services-networking/endpoint-slices.md b/content/id/docs/concepts/services-networking/endpoint-slices.md index 224e7b4bbd..1782f4273e 100644 --- a/content/id/docs/concepts/services-networking/endpoint-slices.md +++ b/content/id/docs/concepts/services-networking/endpoint-slices.md @@ -45,7 +45,7 @@ term_id="selector" >}} dituliskan. EndpointSlice tersebut akan memiliki referensi-referensi menuju Pod manapun yang cocok dengan selektor pada Service tersebut. EndpointSlice mengelompokkan _endpoint_ jaringan berdasarkan kombinasi Service dan Port yang unik. Nama dari sebuah objek EndpointSlice haruslah berupa -[nama subdomain DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) yang sah. +[nama subdomain DNS](/id/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) yang sah. Sebagai contoh, berikut merupakan sampel sumber daya EndpointSlice untuk sebuah Service Kubernetes yang bernama `example`. @@ -180,6 +180,6 @@ bersangkutan. * [Mengaktifkan EndpointSlice](/docs/tasks/administer-cluster/enabling-endpointslices) -* Baca [Menghubungkan Aplikasi dengan Service](/docs/concepts/services-networking/connect-applications-service/) +* Baca [Menghubungkan Aplikasi dengan Service](/id/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/id/docs/concepts/services-networking/ingress-controllers.md b/content/id/docs/concepts/services-networking/ingress-controllers.md index 9491f5dc1c..645f2dbf8d 100644 --- a/content/id/docs/concepts/services-networking/ingress-controllers.md +++ b/content/id/docs/concepts/services-networking/ingress-controllers.md @@ -71,7 +71,7 @@ Pastikan kamu sudah terlebih dahulu memahami dokumentasi kontroler Ingress yang ## {{% heading "whatsnext" %}} -* Pelajari [Ingress](/docs/concepts/services-networking/ingress/) lebih lanjut. +* Pelajari [Ingress](/id/docs/concepts/services-networking/ingress/) lebih lanjut. * [Melakukan konfigurasi Ingress pada Minikube dengan kontroler NGINX](/docs/tasks/access-application-cluster/ingress-minikube) diff --git a/content/id/docs/concepts/services-networking/ingress.md b/content/id/docs/concepts/services-networking/ingress.md index 617581b421..1cc56c5960 100644 --- a/content/id/docs/concepts/services-networking/ingress.md +++ b/content/id/docs/concepts/services-networking/ingress.md @@ -16,8 +16,8 @@ Untuk memudahkan, di awal akan dijelaskan beberapa terminologi yang sering dipak * Node: Sebuah mesin fisik atau virtual yang berada di dalam klaster Kubernetes. * Klaster: Sekelompok node yang merupakan *resource* komputasi primer yang diatur oleh Kubernetes, biasanya diproteksi dari internet dengan menggunakan *firewall*. * *Edge router*: Sebuah *router* mengatur *policy firewall* pada klaster kamu. *Router* ini bisa saja berupa *gateway* yang diatur oleh penyedia layanan *cloud* maupun perangkat keras. -* Jaringan klaster: Seperangkat *links* baik logis maupus fisik, yang memfasilitasi komunikasi di dalam klaster berdasarkan [model jaringan Kubernetes](/docs/concepts/cluster-administration/networking/). -* *Service*: Sebuah [*Service*](/docs/concepts/services-networking/service/) yang mengidentifikasi beberapa *Pod* dengan menggunakan *selector label*. Secara umum, semua *Service* diasumsikan hanya memiliki IP virtual yang hanya dapat diakses dari dalam jaringan klaster. +* Jaringan klaster: Seperangkat *links* baik logis maupus fisik, yang memfasilitasi komunikasi di dalam klaster berdasarkan [model jaringan Kubernetes](/id/docs/concepts/cluster-administration/networking/). +* *Service*: Sebuah [*Service*](/id/docs/concepts/services-networking/service/) yang mengidentifikasi beberapa *Pod* dengan menggunakan *selector label*. Secara umum, semua *Service* diasumsikan hanya memiliki IP virtual yang hanya dapat diakses dari dalam jaringan klaster. ## Apakah *Ingress* itu? @@ -34,11 +34,11 @@ Mekanisme *routing* trafik dikendalikan oleh aturan-aturan yang didefinisikan pa ``` Sebuah *Ingress* dapat dikonfigurasi agar berbagai *Service* memiliki URL yang dapat diakses dari eksternal (luar klaster), melakukan *load balance* pada trafik, terminasi SSL, serta Virtual Host berbasis Nama. -Sebuah [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) bertanggung jawab untuk menjalankan fungsi Ingress yaitu sebagai *loadbalancer*, meskipun dapat juga digunakan untuk mengatur *edge router* atau *frontend* tambahan untuk menerima trafik. +Sebuah [kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) bertanggung jawab untuk menjalankan fungsi Ingress yaitu sebagai *loadbalancer*, meskipun dapat juga digunakan untuk mengatur *edge router* atau *frontend* tambahan untuk menerima trafik. Sebuah *Ingress* tidak mengekspos sembarang *port* atau protokol. Mengekspos *Service* untuk protokol selain HTTP ke HTTPS internet biasanya dilakukan dengan menggunakan -*service* dengan tipe [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) atau -[Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer). +*service* dengan tipe [Service.Type=NodePort](/id/docs/concepts/services-networking/service/#nodeport) atau +[Service.Type=LoadBalancer](/id/docs/concepts/services-networking/service/#loadbalancer). ## Prasyarat @@ -47,7 +47,7 @@ Sebuah *Ingress* tidak mengekspos sembarang *port* atau protokol. Mengekspos *Se Sebelum kamu mulai menggunakan *Ingress*, ada beberapa hal yang perlu kamu ketahui sebelumnya. *Ingress* merupakan *resource* dengan tipe beta. {{< note >}} -Kamu harus terlebih dahulu memiliki [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) untuk dapat memenuhi *Ingress*. Membuat sebuah *Ingress* tanpa adanya kontroler *Ingres* tidak akan berdampak apa pun. +Kamu harus terlebih dahulu memiliki [kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) untuk dapat memenuhi *Ingress*. Membuat sebuah *Ingress* tanpa adanya kontroler *Ingres* tidak akan berdampak apa pun. {{< /note >}} GCE/Google Kubernetes Engine melakukan deploy kontroler *Ingress* pada *master*. Perhatikan laman berikut @@ -56,7 +56,7 @@ kontroler ini jika kamu menggunakan GCE/GKE. Jika kamu menggunakan *environment* selain GCE/Google Kubernetes Engine, kemungkinan besar kamu harus [melakukan proses deploy kontroler ingress kamu sendiri](https://kubernetes.github.io/ingress-nginx/deploy/). Terdapat beberapa jenis -[kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) yang bisa kamu pilih. +[kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) yang bisa kamu pilih. ### Sebelum kamu memulai @@ -89,10 +89,10 @@ spec: ``` Seperti layaknya *resource* Kubernetes yang lain, sebuah Ingress membutuhkan *field* `apiVersion`, `kind`, dan `metadata`. - Untuk informasi umum soal bagaimana cara bekerja dengan menggunakan file konfigurasi, silahkan merujuk pada [melakukan deploy aplikasi](/docs/tasks/run-application/run-stateless-application-deployment/), [konfigurasi kontainer](/docs/tasks/configure-pod-container/configure-pod-configmap/), [mengatur *resource*](/docs/concepts/cluster-administration/manage-deployment/). + Untuk informasi umum soal bagaimana cara bekerja dengan menggunakan file konfigurasi, silahkan merujuk pada [melakukan deploy aplikasi](/docs/tasks/run-application/run-stateless-application-deployment/), [konfigurasi kontainer](/id/docs/tasks/configure-pod-container/configure-pod-configmap/), [mengatur *resource*](/id/docs/concepts/cluster-administration/manage-deployment/). Ingress seringkali menggunakan anotasi untuk melakukan konfigurasi beberapa opsi yang ada bergantung pada kontroler Ingress yang digunakan, sebagai contohnya adalah [anotasi rewrite-target](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md). - [Kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) yang berbeda memiliki jenis anotasi yang berbeda. Pastikan kamu sudah terlebih dahulu memahami dokumentasi + [Kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) yang berbeda memiliki jenis anotasi yang berbeda. Pastikan kamu sudah terlebih dahulu memahami dokumentasi kontroler Ingress yang akan kamu pakai untuk mengetahui jenis anotasi apa sajakah yang disediakan. [Spesifikasi](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) Ingress @@ -111,7 +111,7 @@ Setiap *rule* HTTP mengandung informasi berikut: dan `servicePort`. Baik *host* dan *path* harus sesuai dengan konten dari *request* yang masuk sebelum *loadbalancer* akan mengarahkan trafik pada *service* yang sesuai. * Suatu *backend* adalah kombinasi *service* dan *port* seperti yang dideskripsikan di - [dokumentasi *Service*](/docs/concepts/services-networking/service/). *Request* HTTP (dan HTTPS) yang sesuai dengan + [dokumentasi *Service*](/id/docs/concepts/services-networking/service/). *Request* HTTP (dan HTTPS) yang sesuai dengan *host* dan *path* yang ada pada *rule* akan diteruskan pada *backend* terkait. *Backend default* seringkali dikonfigurasi pada kontroler kontroler Ingress, tugas *backend default* ini adalah @@ -120,7 +120,7 @@ Setiap *rule* HTTP mengandung informasi berikut: ### *Backend Default* Sebuah Ingress yang tidak memiliki *rules* akan mengarahkan semua trafik pada sebuah *backend default*. *Backend default* inilah yang -biasanya bisa dimasukkan sebagai salah satu opsi konfigurasi dari [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) dan tidak dimasukkan dalam spesifikasi *resource* Ingress. +biasanya bisa dimasukkan sebagai salah satu opsi konfigurasi dari [kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) dan tidak dimasukkan dalam spesifikasi *resource* Ingress. Jika tidak ada *host* atau *path* yang sesuai dengan *request* HTTP pada objek Ingress, maka trafik tersebut akan diarahkan pada *backend default*. @@ -218,8 +218,8 @@ Apabila *Ingress* selesai dibuat, maka kamu dapat melihat alamat IP dari berbaga pada kolom `address`. {{< note >}} -Kamu mungkin saja membutuhkan konfigurasi default-http-backend [Service](/docs/concepts/services-networking/service/) -bergantung pada [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) yang kamu pakai. +Kamu mungkin saja membutuhkan konfigurasi default-http-backend [Service](/id/docs/concepts/services-networking/service/) +bergantung pada [kontroler Ingress](/id/docs/concepts/services-networking/ingress-controllers) yang kamu pakai. {{< /note >}} ### Virtual Host berbasis Nama @@ -291,7 +291,7 @@ spec: ### TLS -Kamu dapat mengamankan *Ingress* yang kamu miliki dengan memberikan spesifikasi [secret](/docs/concepts/configuration/secret) +Kamu dapat mengamankan *Ingress* yang kamu miliki dengan memberikan spesifikasi [secret](/id/docs/concepts/configuration/secret) yang mengandung *private key* dan sertifikat TLS. Saat ini, Ingress hanya memiliki fitur untuk melakukan konfigurasi *single TLS port*, yaitu 443, serta melakukan terminasi TLS. Jika *section* TLS pada Ingress memiliki spesifikasi *host* yang berbeda, @@ -448,8 +448,8 @@ Ingress yang ingin diubah. ## Mekanisme *failing* pada beberapa zona *availability* Teknik untuk menyeimbangkan persebaran trafik pada *failure domain* berbeda antar penyedia layanan *cloud*. -Kamu dapat mempelajari dokumentasi yang relevan bagi [kontoler Ingress](/docs/concepts/services-networking/ingress-controllers) -untuk informasi yang lebih detail. Kamu juga dapat mempelajari [dokumentasi federasi](/docs/concepts/cluster-administration/federation/) +Kamu dapat mempelajari dokumentasi yang relevan bagi [kontoler Ingress](/id/docs/concepts/services-networking/ingress-controllers) +untuk informasi yang lebih detail. Kamu juga dapat mempelajari [dokumentasi federasi](/id/docs/concepts/cluster-administration/federation/) untuk informasi lebih detail soal bagaimana melakukan *deploy* untuk federasi klaster. ## Pengembangan selanjutnya @@ -463,8 +463,8 @@ soal perubahan berbagai kontroler. Kamu dapat mengekspos sebuah *Service* dalam berbagai cara, tanpa harus menggunakan *resource* Ingress, dengan menggunakan: -* [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer) -* [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) +* [Service.Type=LoadBalancer](/id/docs/concepts/services-networking/service/#loadbalancer) +* [Service.Type=NodePort](/id/docs/concepts/services-networking/service/#nodeport) * [Port Proxy](https://git.k8s.io/contrib/for-demos/proxy-to-service) diff --git a/content/id/docs/concepts/services-networking/network-policies.md b/content/id/docs/concepts/services-networking/network-policies.md index 25f42ddb98..fe510b846d 100644 --- a/content/id/docs/concepts/services-networking/network-policies.md +++ b/content/id/docs/concepts/services-networking/network-policies.md @@ -80,7 +80,7 @@ kecuali penyedia jaringan mendukung network policy. **_Field-field_ yang bersifat wajib**: Sama dengan seluruh _config_ Kubernetes lainnya, sebuah `NetworkPolicy` membutuhkan _field-field_ `apiVersion`, `kind`, dan `metadata`. Informasi generik mengenai bagaimana bekerja dengan _file_ `config`, dapat dilihat di -[Konfigurasi Kontainer menggunakan `ConfigMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/), +[Konfigurasi Kontainer menggunakan `ConfigMap`](/id/docs/tasks/configure-pod-container/configure-pod-configmap/), serta [Manajemen Objek](/docs/concepts/overview/object-management-kubectl/overview/). **spec**: `NetworkPolicy` [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) memiliki semua informasi yang harus diberikan untuk memberikan definisi _network policy_ yang ada pada _namespace_ tertentu. diff --git a/content/id/docs/concepts/services-networking/service-topology.md b/content/id/docs/concepts/services-networking/service-topology.md index ef15d1ab3d..05abffa323 100644 --- a/content/id/docs/concepts/services-networking/service-topology.md +++ b/content/id/docs/concepts/services-networking/service-topology.md @@ -186,5 +186,5 @@ spec: * Baca tentang [mengaktifkan topologi Service](/docs/tasks/administer-cluster/enabling-service-topology) -* Baca [menghubungkan aplikasi dengan Service](/docs/concepts/services-networking/connect-applications-service/) +* Baca [menghubungkan aplikasi dengan Service](/id/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/id/docs/concepts/services-networking/service.md b/content/id/docs/concepts/services-networking/service.md index 97626bf9ce..00bf4e6241 100644 --- a/content/id/docs/concepts/services-networking/service.md +++ b/content/id/docs/concepts/services-networking/service.md @@ -12,9 +12,9 @@ weight: 10 -[`Pod`](/docs/concepts/workloads/pods/pod/) pada Kubernetes bersifat *mortal*. +[`Pod`](/id/docs/concepts/workloads/pods/pod/) pada Kubernetes bersifat *mortal*. Artinya apabila _pod-pod_ tersebut dibuat dan kemudian mati, _pod-pod_ tersebut -tidak akan dihidupkan kembali. [`ReplicaSets`](/docs/concepts/workloads/controllers/replicaset/) secara +tidak akan dihidupkan kembali. [`ReplicaSets`](/id/docs/concepts/workloads/controllers/replicaset/) secara khusus bertugas membuat dan menghapus `Pod` secara dinamsi (misalnya, pada proses *scaling out* atau *scaling in*). Meskipun setiap `Pod` memiliki alamat IP-nya masing-masing, kamu tidak dapat mengandalkan alamat IP yang diberikan pada _pod-pod_ tersebut, karena alamat IP yang diberikan tidak stabil. @@ -26,7 +26,7 @@ Inilah alasan kenapa `Service` ada. Sebuah `Service` pada Kubernetes adalah sebuah abstraksi yang memberikan definisi set logis yang terdiri beberapa `Pod` serta _policy_ bagaimana cara kamu mengakses sekumpulan `Pod` tadi - seringkali disebut sebagai _microservices_. -Set `Pod` yang dirujuk oleh suatu `Service` (biasanya) ditentukan oleh sebuah [`Label Selector`](/docs/concepts/overview/working-with-objects/labels/#label-selectors) +Set `Pod` yang dirujuk oleh suatu `Service` (biasanya) ditentukan oleh sebuah [`Label Selector`](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors) (lihat penjelasan di bawah untuk mengetahui alasan kenapa kamu mungkin saja membutuhkan `Service` tanpa sebuah _selector_). @@ -95,7 +95,7 @@ mereka juga melakukan abstraksi bagi _backend_ lainnya. Misalnya saja: * Kamu ingin memiliki sebuah basis data eksternal di _environment_ _production_ tapi pada tahap _test_, kamu ingin menggunakan basis datamu sendiri. * Kamu ingin merujuk _service_ kamu pada _service_ lainnya yang berada pada - [_Namespace_](/docs/concepts/overview/working-with-objects/namespaces/) yang berbeda atau bahkan klaster yang berbeda. + [_Namespace_](/id/docs/concepts/overview/working-with-objects/namespaces/) yang berbeda atau bahkan klaster yang berbeda. * Kamu melakukan migrasi _workloads_ ke Kubernetes dan beberapa _backend_ yang kamu miliki masih berada di luar klaster Kubernetes. @@ -319,7 +319,7 @@ Meskipun begitu, DNS tidak memiliki keterbatasan ini. ### DNS -Salah satu [_add-on_](/docs/concepts/cluster-administration/addons/) opsional +Salah satu [_add-on_](/id/docs/concepts/cluster-administration/addons/) opsional (meskipun sangat dianjurkan) adalah server DNS. Server DNS bertugas untuk mengamati apakah terdapat objek `Service` baru yang dibuat dan kemudian bertugas menyediakan DNS baru untuk _Service_ tersebut. Jika DNS ini diaktifkan untuk seluruh klaster, maka semua `Pod` akan secara otomatis @@ -338,7 +338,7 @@ nomor _port_ yang digunakan oleh _http_. Server DNS Kubernetes adalah satu-satunya cara untuk mengakses _Service_ dengan tipe `ExternalName`. Informasi lebih lanjut tersedia di -[DNS _Pods_ dan _Services_](/docs/concepts/services-networking/dns-pod-service/). +[DNS _Pods_ dan _Services_](/id/docs/concepts/services-networking/dns-pod-service/). ## `Service` _headless_ @@ -745,10 +745,10 @@ dan tidak akan menerima trafik apa pun. Untuk menghasilkan distribusi trafik yang merata, kamu dapat menggunakan _DaemonSet_ atau melakukan spesifikasi -[pod anti-affinity](/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature) +[pod anti-affinity](/id/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature) agar `Pod` tidak di-_assign_ ke _node_ yang sama. -NLB juga dapat digunakan dengan anotasi [internal load balancer](/docs/concepts/services-networking/service/#internal-load-balancer). +NLB juga dapat digunakan dengan anotasi [internal load balancer](/id/docs/concepts/services-networking/service/#internal-load-balancer). Agar trafik klien berhasil mencapai _instances_ dibelakang ELB, _security group_ dari _node_ akan diberikan _rules_ IP sebagai berikut: @@ -1006,7 +1006,7 @@ alternatif penggunaan `Service` untuk HTTP/HTTPS. {{< feature-state for_k8s_version="v1.1" state="stable" >}} -Apabila penyedia layanan _cloud_ yang kamu gunakan mendukung, (misalnya saja, [AWS](/docs/concepts/cluster-administration/cloud-providers/#aws)), +Apabila penyedia layanan _cloud_ yang kamu gunakan mendukung, (misalnya saja, [AWS](/id/docs/concepts/cluster-administration/cloud-providers/#aws)), _Service_ dengan _type_ `LoadBalancer` untuk melakukan konfigurasi _load balancer_ di luar Kubernetes sendiri, serta akan melakukan _forwarding_ koneksi yang memiliki prefiks [protokol PROXY](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt). diff --git a/content/id/docs/concepts/storage/dynamic-provisioning.md b/content/id/docs/concepts/storage/dynamic-provisioning.md index ac206dfacd..4b9fa6f35c 100644 --- a/content/id/docs/concepts/storage/dynamic-provisioning.md +++ b/content/id/docs/concepts/storage/dynamic-provisioning.md @@ -8,7 +8,7 @@ weight: 40 Penyediaan volume dinamis memungkinkan volume penyimpanan untuk dibuat sesuai permintaan (_on-demand_). Tanpa adanya penyediaan dinamis (_dynamic provisioning_), untuk membuat volume penyimpanan baru, admin klaster secara manual harus -memanggil penyedia layanan cloud atau layanan penyimpanan, dan kemudian membuat [objek PersistentVolume](/docs/concepts/storage/persistent-volumes/) +memanggil penyedia layanan cloud atau layanan penyimpanan, dan kemudian membuat [objek PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) sebagai representasi di Kubernetes. Fitur penyediaan dinamis menghilangkan kebutuhan admin klaster untuk menyediakan penyimpanan sebelumnya (_pre-provision_). Dengan demikian, penyimpanan akan tersedia secara otomatis ketika diminta oleh pengguna. @@ -32,7 +32,7 @@ kumpulan parameter tertentu. Desain ini memastikan bahwa pengguna tidak perlu kh rumitnya mekanisme penyediaan penyimpanan, tapi tetap memiliki kemampuan untuk memilih berbagai macam pilihan penyimpanan. -Info lebih lanjut mengenai _storage class_ dapat dilihat [di sini](/docs/concepts/storage/storage-classes/). +Info lebih lanjut mengenai _storage class_ dapat dilihat [di sini](/id/docs/concepts/storage/storage-classes/). ## Mengaktifkan Penyediaan Dinamis (_Dynamic Provisioning_) @@ -123,6 +123,6 @@ tidak bisa terbuat. Pada klaster [Multi-Zona](/docs/setup/multiple-zones), Pod dapat tersebar di banyak Zona pada sebuah Region. Penyimpanan dengan *backend* Zona-Tunggal seharusnya disediakan pada Zona-Zona dimana Pod dijalankan. Hal ini dapat dicapai dengan mengatur -[Mode Volume Binding](/docs/concepts/storage/storage-classes/#volume-binding-mode). +[Mode Volume Binding](/id/docs/concepts/storage/storage-classes/#volume-binding-mode). diff --git a/content/id/docs/concepts/storage/persistent-volumes.md b/content/id/docs/concepts/storage/persistent-volumes.md index f75941b86a..51163d36a9 100644 --- a/content/id/docs/concepts/storage/persistent-volumes.md +++ b/content/id/docs/concepts/storage/persistent-volumes.md @@ -11,7 +11,7 @@ weight: 20 -Dokumen ini menjelaskan kondisi terkini dari `PersistentVolumes` pada Kubernetes. Disarankan telah memiliki familiaritas dengan [volume](/docs/concepts/storage/volumes/). +Dokumen ini menjelaskan kondisi terkini dari `PersistentVolumes` pada Kubernetes. Disarankan telah memiliki familiaritas dengan [volume](/id/docs/concepts/storage/volumes/). @@ -34,7 +34,7 @@ mode akses, tanpa memaparkan detail-detail bagaimana cara volume tersebut diimpl kepada para pengguna. Untuk mengatasi hal ini maka dibutuhkan sumber daya `StorageClass`. -Silakan lihat [panduan mendetail dengan contoh-contoh yang sudah berjalan](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/). +Silakan lihat [panduan mendetail dengan contoh-contoh yang sudah berjalan](/id/docs/tasks/configure-pod-container/configure-persistent-volume-storage/). ## Siklus hidup dari sebuah volume dan klaim @@ -360,7 +360,7 @@ Pada CLI, mode-mode akses tersebut disingkat menjadi: Sebuah PV bisa memiliki sebuah kelas, yang dispesifikasi dalam pengaturan atribut `storageClassName` menjadi nama -[StorageClass](/docs/concepts/storage/storage-classes/). +[StorageClass](/id/docs/concepts/storage/storage-classes/). Sebuah PV dari kelas tertentu hanya dapat terikat dengan PVC yang meminta kelas tersebut. Sebuah PV tanpa `storageClassName` tidak memiliki kelas dan hanya dapat terikat dengan PVC yang tidak meminta kelas tertentu. @@ -412,7 +412,7 @@ akan dihilangkan sepenuhnya pada rilis Kubernetes mendatang. ### Afinitas Node {{< note >}} -Untuk kebanyakan tipe volume, kamu tidak perlu memasang kolom ini. Kolom ini secara otomatis terisi untuk tipe blok volume [AWS EBS](/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/docs/concepts/storage/volumes/#gcepersistentdisk) dan [Azure Disk](/docs/concepts/storage/volumes/#azuredisk). Kamu harus mengaturnya secara eksplisit untuk volume [lokal](/docs/concepts/storage/volumes/#local). +Untuk kebanyakan tipe volume, kamu tidak perlu memasang kolom ini. Kolom ini secara otomatis terisi untuk tipe blok volume [AWS EBS](/id/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/id/docs/concepts/storage/volumes/#gcepersistentdisk) dan [Azure Disk](/id/docs/concepts/storage/volumes/#azuredisk). Kamu harus mengaturnya secara eksplisit untuk volume [lokal](/id/docs/concepts/storage/volumes/#local). {{< /note >}} Sebuah PV dapat menspesifikasi [afinitas node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core) untuk mendefinisikan batasan yang membatasi _node_ mana saja yang dapat mengakses volume tersebut. _Pod_ yang menggunakan sebuah PV hanya akan bisa dijadwalkan ke _node_ yang dipilih oleh afinitas _node_. @@ -466,7 +466,7 @@ Klaim, seperti _pod_, bisa meminta sumber daya dengan jumlah tertentu. Pada kas ### _Selector_ -Klaim dapat menspesifikasi [_label selector_](/docs/concepts/overview/working-with-objects/labels/#label-selectors) untuk memilih serangkaian volume lebih jauh. Hanya volume yang cocok labelnya dengan _selector_ yang dapat terikat dengan klaim. _Selector_ dapat terdiri dari dua kolom: +Klaim dapat menspesifikasi [_label selector_](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors) untuk memilih serangkaian volume lebih jauh. Hanya volume yang cocok labelnya dengan _selector_ yang dapat terikat dengan klaim. _Selector_ dapat terdiri dari dua kolom: * `matchLabels` - volume harus memiliki label dengan nilai ini * `matchExpressions` - daftar dari persyaratan yang dibuat dengan menentukan kunci, daftar nilai, dan operator yang menghubungkan kunci dengan nilai. Operator yang valid meliputi In, NotIn, Exists, dan DoesNotExist. @@ -476,7 +476,7 @@ Semua persyaratan tersebut, dari `matchLabels` dan `matchExpressions` akan dilak ### Kelas Sebuah klaim dapat meminta kelas tertentu dengan menspesifikasi nama dari -[StorageClass](/docs/concepts/storage/storage-classes/) +[StorageClass](/id/docs/concepts/storage/storage-classes/) menggunakan atribut `storageClassName`. Hanya PV dari kelas yang diminta, yang memiliki `storageClassName` yang sama dengan PVC, yang dapat terikat dengan PVC. @@ -647,7 +647,7 @@ Hanya volume yang disediakan secara statis yang didukung untuk rilis alfa. Admin {{< feature-state for_k8s_version="v1.12" state="alpha" >}} -Fitur _volume snapshot_ ditambahkan hanya untuk mendukung _CSI Volume Plugins_. Untuk lebih detail, lihat [_volume snapshots_](/docs/concepts/storage/volume-snapshots/). +Fitur _volume snapshot_ ditambahkan hanya untuk mendukung _CSI Volume Plugins_. Untuk lebih detail, lihat [_volume snapshots_](/id/docs/concepts/storage/volume-snapshots/). Untuk mengaktifkan dukungan pemulihan sebuah volume dari sebuah sumber data _volume snapshot_, aktifkan gerbang fitur `VolumeSnapshotDataSource` pada apiserver dan _controller-manager_. diff --git a/content/id/docs/concepts/storage/storage-classes.md b/content/id/docs/concepts/storage/storage-classes.md index 9e0a5b1664..2897399e80 100644 --- a/content/id/docs/concepts/storage/storage-classes.md +++ b/content/id/docs/concepts/storage/storage-classes.md @@ -8,8 +8,8 @@ weight: 30 Dokumen ini mendeskripsikan konsep StorageClass yang ada pada Kubernetes. Sebelum lanjut membaca, sangat dianjurkan untuk memiliki pengetahuan terhadap -[volumes](/docs/concepts/storage/volumes/) dan -[peristent volume](/docs/concepts/storage/persistent-volumes) terlebih dahulu. +[volumes](/id/docs/concepts/storage/volumes/) dan +[peristent volume](/id/docs/concepts/storage/persistent-volumes) terlebih dahulu. @@ -40,7 +40,7 @@ dan objek yang sudah dibuat tidak dapat diubah lagi definisinya. Administrator dapat memberikan spesifikasi StorageClass _default_ bagi PVC yang tidak membutuhkan kelas tertentu untuk dapat melakukan mekanisme _bind_: -kamu dapat membaca [bagian `PersistentVolumeClaim`](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) +kamu dapat membaca [bagian `PersistentVolumeClaim`](/id/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) untuk penjelasan lebih lanjut. ```yaml @@ -131,7 +131,7 @@ akan gagal apabila salah satu dari keduanya bersifat invalid. ### Mode Volume _Binding_ _Field_ `volumeBindingMode` mengontrol kapan mekanisme [_binding_ volume dan -_provisioning_ dinamis](/docs/concepts/storage/persistent-volumes/#provisioning) +_provisioning_ dinamis](/id/docs/concepts/storage/persistent-volumes/#provisioning) harus dilakukan. Secara _default_, ketika mode `Immediate` yang mengindikasikan @@ -148,11 +148,11 @@ dan _binding_ dari sebuah PersistentVolume hingga sebuah Pod yang menggunakan PersistentVolumeClaim dibuat. PersistentVolume akan dipilih atau di-_provisioning_ sesuai dengan topologi yang dispesifikasikan oleh limitasi yang diberikan oleh mekanisme _scheduling_ Pod. Hal ini termasuk, tetapi tidak hanya terbatas pada, -[persyaratan sumber daya](/docs/concepts/configuration/manage-compute-resources-container), -[_node selector_](/docs/concepts/configuration/assign-pod-node/#nodeselector), +[persyaratan sumber daya](/id/docs/concepts/configuration/manage-compute-resources-container), +[_node selector_](/id/docs/concepts/configuration/assign-pod-node/#nodeselector), [afinitas dan -anti-afinitas Pod](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity), -serta [_taint_ dan _toleration_](/docs/concepts/configuration/taint-and-toleration). +anti-afinitas Pod](/id/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity), +serta [_taint_ dan _toleration_](/id/docs/concepts/configuration/taint-and-toleration). Beberapa _plugin_ di bawah ini mendukung `WaitForFirstConsumer` dengan _provisioning_ dinamis: @@ -168,7 +168,7 @@ PersistentVolume yang terlebih dahulu dibuat: * [Lokal](#lokal) {{< feature-state state="beta" for_k8s_version="1.14" >}} -[Volume-volume CSI](/docs/concepts/storage/volumes/#csi) juga didukung +[Volume-volume CSI](/id/docs/concepts/storage/volumes/#csi) juga didukung dengan adanya _provisioning_ dinamis serta PV yang telah terlebih dahulu dibuat, meskipun demikian, akan lebih baik apabila kamu melihat dokumentasi untuk driver spesifik CSI untuk melihat topologi _key_ yang didukung @@ -634,8 +634,8 @@ parameters: di dalam grup sumber daya yang sama dengan klaster, serta `skuName` dan `location` akan diabaikan. Selama _provision_, sebuah secret dibuat untuk menyimpan _credentials_. Jika klaster -menggunakan konsep [RBAC](/docs/reference/access-authn-authz/rbac/) dan -[_Roles_ Controller](/docs/reference/access-authn-authz/rbac/#controller-roles), +menggunakan konsep [RBAC](/id/docs/reference/access-authn-authz/rbac/) dan +[_Roles_ Controller](/id/docs/reference/access-authn-authz/rbac/#controller-roles), menambahkan kapabilitas `create` untuk sumber daya `secret` bagi clusterrole `system:controller:persistent-volume-binder`. diff --git a/content/id/docs/concepts/storage/volume-pvc-datasource.md b/content/id/docs/concepts/storage/volume-pvc-datasource.md index 4a5f5d8c8c..481e74c976 100644 --- a/content/id/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/id/docs/concepts/storage/volume-pvc-datasource.md @@ -7,7 +7,7 @@ weight: 30 {{< feature-state for_k8s_version="v1.16" state="beta" >}} -Dokumen ini mendeskripsikan konsep pengklonaan Volume CSI yang telah tersedia di dalam Kubernetes. Pengetahuan tentang [Volume](/docs/concepts/storage/volumes) disarankan. +Dokumen ini mendeskripsikan konsep pengklonaan Volume CSI yang telah tersedia di dalam Kubernetes. Pengetahuan tentang [Volume](/id/docs/concepts/storage/volumes) disarankan. diff --git a/content/id/docs/concepts/storage/volume-snapshot-classes.md b/content/id/docs/concepts/storage/volume-snapshot-classes.md index 0414a9d7de..fff7de9baa 100644 --- a/content/id/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/id/docs/concepts/storage/volume-snapshot-classes.md @@ -7,8 +7,8 @@ weight: 30 Laman ini menjelaskan tentang konsep VolumeSnapshotClass pada Kubernetes. Sebelum melanjutkan, -sangat disarankan untuk membaca [_snapshot_ volume](/docs/concepts/storage/volume-snapshots/) -dan [kelas penyimpanan (_storage class_)](/docs/concepts/storage/storage-classes) terlebih dahulu. +sangat disarankan untuk membaca [_snapshot_ volume](/id/docs/concepts/storage/volume-snapshots/) +dan [kelas penyimpanan (_storage class_)](/id/docs/concepts/storage/storage-classes) terlebih dahulu. diff --git a/content/id/docs/concepts/storage/volume-snapshots.md b/content/id/docs/concepts/storage/volume-snapshots.md index 39ab3d31aa..5ddfc2aaa6 100644 --- a/content/id/docs/concepts/storage/volume-snapshots.md +++ b/content/id/docs/concepts/storage/volume-snapshots.md @@ -7,7 +7,7 @@ weight: 20 {{< feature-state for_k8s_version="v1.12" state="alpha" >}} -Laman ini menjelaskan tentang fitur VolumeSnapshot pada Kubernetes. Sebelum lanjut membaca, sangat disarankan untuk memahami [PersistentVolume](/docs/concepts/storage/persistent-volumes/) terlebih dahulu. +Laman ini menjelaskan tentang fitur VolumeSnapshot pada Kubernetes. Sebelum lanjut membaca, sangat disarankan untuk memahami [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) terlebih dahulu. @@ -48,7 +48,7 @@ Seorang adminstrator klaster membuat beberapa VolumeSnapshotContent, yang masing #### Dinamis Ketika VolumeSnapshotContent yang dibuat oleh administrator tidak ada yang sesuai dengan VolumeSnapshot yang dibuat pengguna, klaster bisa saja mencoba untuk menyediakan sebuah VolumeSnapshot secara dinamis, khususnya untuk objek VolumeSnapshot. -Proses penyediaan ini berdasarkan VolumeSnapshotClasses: VolumeSnapshot harus meminta sebuah [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/) +Proses penyediaan ini berdasarkan VolumeSnapshotClasses: VolumeSnapshot harus meminta sebuah [VolumeSnapshotClass](/id/docs/concepts/storage/volume-snapshot-classes/) dan administrator harus membuat serta mengatur _class_ tersebut supaya penyediaan dinamis bisa terjadi. ### Ikatan (_Binding_) @@ -93,7 +93,7 @@ spec: ### _Class_ Suatu VolumeSnapshotContent dapat memiliki suatu _class_, yang didapat dengan mengatur atribut -`snapshotClassName` dengan nama dari [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/). +`snapshotClassName` dengan nama dari [VolumeSnapshotClass](/id/docs/concepts/storage/volume-snapshot-classes/). VolumeSnapshotContent dari _class_ tertentu hanya dapat terikat (_bound_) dengan VolumeSnapshot yang "meminta" _class_ tersebut. VolumeSnapshotContent tanpa `snapshotClassName` tidak memiliki _class_ dan hanya dapat terikat (_bound_) dengan VolumeSnapshot yang "meminta" untuk tidak menggunakan _class_. @@ -117,7 +117,7 @@ spec: ### _Class_ Suatu VolumeSnapshot dapat meminta sebuah _class_ tertentu dengan mengatur nama dari -[VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/) +[VolumeSnapshotClass](/id/docs/concepts/storage/volume-snapshot-classes/) menggunakan atribut `snapshotClassName`. Hanya VolumeSnapshotContent dari _class_ yang diminta, memiliki `snapshotClassName` yang sama dengan VolumeSnapshot, dapat terikat (_bound_) dengan VolumeSnapshot tersebut. @@ -127,6 +127,6 @@ dengan VolumeSnapshot, dapat terikat (_bound_) dengan VolumeSnapshot tersebut. Kamu dapat menyediakan sebuah volume baru, yang telah terisi dengan data dari suatu _snapshot_, dengan menggunakan _field_ `dataSource` pada objek PersistentVolumeClaim. -Untuk detailnya bisa dilihat pada [VolumeSnapshot and Mengembalikan Volume dari _Snapshot_](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support). +Untuk detailnya bisa dilihat pada [VolumeSnapshot and Mengembalikan Volume dari _Snapshot_](/id/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support). diff --git a/content/id/docs/concepts/storage/volumes.md b/content/id/docs/concepts/storage/volumes.md index 679de8c865..8d593f1eba 100644 --- a/content/id/docs/concepts/storage/volumes.md +++ b/content/id/docs/concepts/storage/volumes.md @@ -185,7 +185,7 @@ Pada saat fitur migrasi CSI untuk Cinder diaktifkan, fitur ini akan menterjemahk ### configMap {#configmap} -Sumber daya [`configMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/) memungkinkan kamu untuk menyuntikkan data konfigurasi ke dalam Pod. +Sumber daya [`configMap`](/id/docs/tasks/configure-pod-container/configure-pod-configmap/) memungkinkan kamu untuk menyuntikkan data konfigurasi ke dalam Pod. Data yang ditaruh di dalam sebuah objek `ConfigMap` dapat dirujuk dalam sebuah Volume dengan tipe `configMap` dan kemudian digunakan oleh aplikasi/container yang berjalan di dalam sebuah Pod. Saat mereferensikan sebuah objek `configMap`, kamu tinggal memasukkan nama ConfigMap tersebut ke dalam rincian Volume yang bersangkutan. Kamu juga dapat mengganti _path_ spesifik yang akan digunakan pada ConfigMap. Misalnya, untuk menambatkan ConfigMap `log-config` pada Pod yang diberi nama `configmap-pod`, kamu dapat menggunakan YAML ini: @@ -215,7 +215,7 @@ ConfigMap `log-config` ditambatkan sebagai sebuah Volume, dan semua isinya yang Perlu dicatat bahwa _path_ tersebut berasal dari isian `mountPath` pada Volume, dan `path` yang ditunjuk dengan `key` bernama `log_level`. {{< caution >}} -Kamu harus membuat sebuah [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) sebelum kamu dapat menggunakannya. +Kamu harus membuat sebuah [ConfigMap](/id/docs/tasks/configure-pod-container/configure-pod-configmap/) sebelum kamu dapat menggunakannya. {{< /caution >}} {{< note >}} @@ -346,7 +346,7 @@ Fitur [Regional Persistent Disks](https://cloud.google.com/compute/docs/disks/#r #### Menyediakan sebuah Regional PD PersistentVolume Secara Manual -Penyediaan secara dinamis mungkin dilakukan dengan sebuah [StorageClass untuk GCE PD](/docs/concepts/storage/storage-classes/#gce). +Penyediaan secara dinamis mungkin dilakukan dengan sebuah [StorageClass untuk GCE PD](/id/docs/concepts/storage/storage-classes/#gce). Sebelum membuat sebuah PersistentVolume, kamu harus membuat PD-nya: ```shell @@ -533,7 +533,7 @@ Kolom `nodeAffinity` ada PersistentVolue dibutuhkan saat menggunakan Volume `loc Kolom `volumeMode` pada PersistentVolume sekarang dapat disetel menjadi "Block" (menggantikan nilai bawaan "Filesystem") untuk membuka Volume `local` tersebut sebagai media penyimpanan blok mentah. Hal ini membutuhkan diaktifkannya _Alpha feature gate_ `BlockVolume`. -Saat menggunakan Volume `local`, disarankan untuk membuat sebuah StorageClass dengan `volumeBindingMode` yang disetel menjadi `WaitForFirstConsumer`. Lihat[contohnya](/docs/concepts/storage/storage-classes/#local). Menunda pengikatan Volume memastikan bahwa keputusan pengikatan PersistentVolumeClaim juga akan dievaluasi terhadap batasan-batasan Node yang berlaku pada Pod, seperti kebutuhan sumber daya Node, `nodeSelector`, `podAffinity`, dan `podAntiAffinity`. +Saat menggunakan Volume `local`, disarankan untuk membuat sebuah StorageClass dengan `volumeBindingMode` yang disetel menjadi `WaitForFirstConsumer`. Lihat[contohnya](/id/docs/concepts/storage/storage-classes/#local). Menunda pengikatan Volume memastikan bahwa keputusan pengikatan PersistentVolumeClaim juga akan dievaluasi terhadap batasan-batasan Node yang berlaku pada Pod, seperti kebutuhan sumber daya Node, `nodeSelector`, `podAffinity`, dan `podAntiAffinity`. Sebuah penyedia statis eksternal dapat berjalan secara terpisah untuk memperbaik pengaturan siklus hidup Volume `local`. Perlu dicatat bahwa penyedia ini belum mendukung _dynamic provisioning_. Untuk contoh bagaimana menjalankan penyedia Volume `local` eksternal, lihat [petunjuk penggunaannya](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner). @@ -554,9 +554,9 @@ Lihat [contoh NFS](https://github.com/kubernetes/examples/tree/{{< param "github ### persistentVolumeClaim {#persistentvolumeclaim} -Sebuah Volume `persistentVolumeClaim` digunakan untuk menambatkan sebuah [PersistentVolume](/docs/concepts/storage/persistent-volumes/) ke dalam sebuag Pod. PersistentVolume adalah sebuah cara bagi pengguna untuk "mengklaim" penyimpanan yang _durable_ (seperti sebuah GCE PD atau sebuah volume iSCSI) tanpa mengetahui detil lingkungan _cloud_ yang bersangkutan. +Sebuah Volume `persistentVolumeClaim` digunakan untuk menambatkan sebuah [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) ke dalam sebuag Pod. PersistentVolume adalah sebuah cara bagi pengguna untuk "mengklaim" penyimpanan yang _durable_ (seperti sebuah GCE PD atau sebuah volume iSCSI) tanpa mengetahui detil lingkungan _cloud_ yang bersangkutan. -Lihat [contoh PersistentVolumes](/docs/concepts/storage/persistent-volumes/) untuk lebih lanjut. +Lihat [contoh PersistentVolumes](/id/docs/concepts/storage/persistent-volumes/) untuk lebih lanjut. ### projected {#projected} @@ -742,7 +742,7 @@ Lihat [contoh RBD](https://github.com/kubernetes/examples/tree/{{< param "github ### scaleIO {#scaleio} -ScaleIO adalah _platform_ penyimpanan berbasis perangkat lunak yang dapat menggunakan perangkat keras yang sudah tersedia untuk membuat klaster-klaster media penyimpanan terhubung jaringan yang _scalable_. _Plugin_ Volume `scaleIO` memungkinkan Pod-pod yang di-_deploy_ untuk mengakses Volume-volume ScaleIO yang telah tersedia (atau dapat menyediakan volume-volume untuk PersistentVolumeClaim secara dinamis, lihat [Persistent Volume ScaleIO](/docs/concepts/storage/persistent-volumes/#scaleio)). +ScaleIO adalah _platform_ penyimpanan berbasis perangkat lunak yang dapat menggunakan perangkat keras yang sudah tersedia untuk membuat klaster-klaster media penyimpanan terhubung jaringan yang _scalable_. _Plugin_ Volume `scaleIO` memungkinkan Pod-pod yang di-_deploy_ untuk mengakses Volume-volume ScaleIO yang telah tersedia (atau dapat menyediakan volume-volume untuk PersistentVolumeClaim secara dinamis, lihat [Persistent Volume ScaleIO](/id/docs/concepts/storage/persistent-volumes/#scaleio)). {{< caution >}} Kamu harus memiliki klaster ScaleIO yang berjalan dengan volume-volume yang sudah dibuat sebelum kamu dapat menggunakannya. @@ -1033,7 +1033,7 @@ Dimulai pada versi 1.11, CSI memperkenalkan dukungak untuk volume blok _raw_, ya Dukungan untuk volume blok CSI bersifat _feature-gate_, tapi secara bawaan diaktifkan. Kedua _feature-gate_ yang harus diaktifkan adalah `BlockVolume` dan `CSIBlockVolume`. -Pelajari cara [menyiapkan PV/PVC dengan dukungan volume blok _raw_](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support). +Pelajari cara [menyiapkan PV/PVC dengan dukungan volume blok _raw_](/id/docs/concepts/storage/persistent-volumes/#raw-block-volume-support). #### Volume CSI Sementara diff --git a/content/id/docs/concepts/workloads/controllers/cron-jobs.md b/content/id/docs/concepts/workloads/controllers/cron-jobs.md index 29fde331ea..ca5df2d86d 100644 --- a/content/id/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/id/docs/concepts/workloads/controllers/cron-jobs.md @@ -6,7 +6,7 @@ weight: 80 -Suatu CronJob menciptakan [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) yang dijadwalkan berdasarkan waktu tertentu. +Suatu CronJob menciptakan [Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/) yang dijadwalkan berdasarkan waktu tertentu. Satu objek CronJob sepadan dengan satu baris pada _file_ _crontab_ (_cron table_). CronJob tersebut menjalankan suatu pekerjaan secara berkala pada waktu tertentu, dituliskan dalam format [Cron](https://en.wikipedia.org/wiki/Cron). @@ -15,7 +15,7 @@ pada waktu tertentu, dituliskan dalam format [Cron](https://en.wikipedia.org/wik Seluruh waktu `schedule:` pada _**CronJob**_ mengikuti zona waktu dari _master_ di mana Job diinisiasi. {{< /note >}} -Untuk panduan dalam berkreasi dengan _cron job_, dan contoh _spec file_ untuk suatu _cron job_, lihat [Menjalankan otomasi _task_ dengan _cron job_](/docs/tasks/job/automated-tasks-with-cron-jobs). +Untuk panduan dalam berkreasi dengan _cron job_, dan contoh _spec file_ untuk suatu _cron job_, lihat [Menjalankan otomasi _task_ dengan _cron job_](/id/docs/tasks/job/automated-tasks-with-cron-jobs). diff --git a/content/id/docs/concepts/workloads/controllers/daemonset.md b/content/id/docs/concepts/workloads/controllers/daemonset.md index baa79aa3f2..0b1c0e71e9 100644 --- a/content/id/docs/concepts/workloads/controllers/daemonset.md +++ b/content/id/docs/concepts/workloads/controllers/daemonset.md @@ -48,7 +48,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml Seperti semua konfigurasi Kubernetes lainnya, DaemonSet membutuhkan _field_ `apiVersion`, `kind`, dan `metadata`. Untuk informasi umum tentang berkas konfigurasi, lihat dokumen [men-_deploy_ aplikasi](/docs/user-guide/deploying-applications/), -[pengaturan kontainer](/docs/tasks/), dan [pengelolaan objek dengan kubectl](/docs/concepts/overview/working-with-objects/object-management/). +[pengaturan kontainer](/docs/tasks/), dan [pengelolaan objek dengan kubectl](/id/docs/concepts/overview/working-with-objects/object-management/). DaemonSet juga membutuhkan bagian [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). @@ -61,7 +61,7 @@ DaemonSet juga membutuhkan bagian [`.spec`](https://git.k8s.io/community/contrib Selain _field_ wajib untuk Pod, templat Pod di DaemonSet harus menspesifikasikan label yang sesuai (lihat [selektor Pod](#selektor-pod)). -Templat Pod di DaemonSet harus memiliki [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) +Templat Pod di DaemonSet harus memiliki [`RestartPolicy`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) yang bernilai `Always`, atau tidak dispesifikasikan, sehingga _default_ menjadi `Always`. DaemonSet dengan nilai `Always` membuat Pod akan selalu di-_restart_ saat kontainer keluar/berhenti atau terjadi _crash_. @@ -77,7 +77,7 @@ Mengubah selektor Pod dapat menyebabkan Pod _orphan_ yang tidak disengaja, dan m Objek `.spec.selector` memiliki dua _field_: -* `matchLabels` - bekerja seperti `.spec.selector` pada [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/). +* `matchLabels` - bekerja seperti `.spec.selector` pada [ReplicationController](/id/docs/concepts/workloads/controllers/replicationcontroller/). * `matchExpressions` - bisa digunakan untuk membuat selektor yang lebih canggih dengan mendefinisikan _key_, daftar _value_ dan operator yang menyatakan hubungan antara _key_ dan _value_. @@ -97,8 +97,8 @@ membuat Pod dengan nilai yang berbeda di sebuah Node untuk _testing_. Jika kamu menspesifikasikan `.spec.template.spec.nodeSelector`, maka _controller_ DaemonSet akan membuat Pod pada Node yang cocok dengan [selektor -Node](/docs/concepts/configuration/assign-pod-node/). Demikian juga, jika kamu menspesifikasikan `.spec.template.spec.affinity`, -maka _controller_ DaemonSet akan membuat Pod pada Node yang cocok dengan [Node affinity](/docs/concepts/configuration/assign-pod-node/). +Node](/id/docs/concepts/configuration/assign-pod-node/). Demikian juga, jika kamu menspesifikasikan `.spec.template.spec.affinity`, +maka _controller_ DaemonSet akan membuat Pod pada Node yang cocok dengan [Node affinity](/id/docs/concepts/configuration/assign-pod-node/). Jika kamu tidak menspesifikasikan sama sekali, maka _controller_ DaemonSet akan membuat Pod pada semua Node. @@ -116,7 +116,7 @@ mendatangkan masalah-masalah berikut: * Inkonsistensi perilaku Pod: Pod normal yang menunggu dijadwalkan akan dibuat dalam keadaan `Pending`, tapi Pod DaemonSet tidak seperti itu. Ini membingungkan untuk pengguna. - * [Pod preemption](/docs/concepts/configuration/pod-priority-preemption/) + * [Pod preemption](/id/docs/concepts/configuration/pod-priority-preemption/) ditangani oleh _default scheduler_. Ketika _preemption_ dinyalakan, _controller_ DaemonSet akan membuat keputusan penjadwalan tanpa memperhitungkan prioritas Pod dan _preemption_. @@ -148,7 +148,7 @@ mengabaikan Node `unschedulable` ketika menjadwalkan Pod DaemonSet. ### _Taint_ dan _Toleration_ Meskipun Pod Daemon menghormati -[taint dan toleration](/docs/concepts/configuration/taint-and-toleration), +[taint dan toleration](/id/docs/concepts/configuration/taint-and-toleration), _toleration_ berikut ini akan otomatis ditambahkan ke Pod DaemonSet sesuai dengan fitur yang bersangkutan. @@ -170,7 +170,7 @@ Beberapa pola yang mungkin digunakan untuk berkomunikasi dengan Pod dalam Daemon - **Push**: Pod dalam DaemonSet diatur untuk mengirim pembaruan status ke servis lain, contohnya _stats database_. Pod ini tidak memiliki klien. - **IP Node dan Konvensi Port**: Pod dalam DaemonSet dapat menggunakan `hostPort`, sehingga Pod dapat diakses menggunakan IP Node. Klien tahu daftar IP Node dengan suatu cara, dan tahu port berdasarkan konvensi. -- **DNS**: Buat [headless service](/docs/concepts/services-networking/service/#headless-services) dengan Pod selektor yang sama, +- **DNS**: Buat [headless service](/id/docs/concepts/services-networking/service/#headless-services) dengan Pod selektor yang sama, dan temukan DaemonSet menggunakan _resource_ `endpoints` atau mengambil beberapa A _record_ dari DNS. - **Service**: Buat Servis dengan Pod selektor yang sama, dan gunakan Servis untuk mengakses _daemon_ pada Node random. (Tidak ada cara mengakses spesifik Node) @@ -223,7 +223,7 @@ _bootstrapping_ klaster. ### Deployment -DaemonSet mirip dengan [Deployment](/docs/concepts/workloads/controllers/deployment/) sebab mereka +DaemonSet mirip dengan [Deployment](/id/docs/concepts/workloads/controllers/deployment/) sebab mereka sama-sama membuat Pod, dan Pod yang mereka buat punya proses yang seharusnya tidak berhenti (e.g. peladen web, peladen penyimpanan) diff --git a/content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md b/content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md index 4aca03535f..5f4720646b 100644 --- a/content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md +++ b/content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md @@ -119,14 +119,14 @@ Sebuah Job juga membutuhkan sebuah [bagian `.spec`](https://git.k8s.io/community _Field_ `.spec.template` merupakan satu-satunya _field_ wajib pada `.spec`. -_Field_ `.spec.template` merupakan sebuah [templat Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). _Field_ ini memiliki skema yang sama dengan yang ada pada [Pod](/docs/user-guide/pods), +_Field_ `.spec.template` merupakan sebuah [templat Pod](/id/docs/concepts/workloads/pods/pod-overview/#pod-templates). _Field_ ini memiliki skema yang sama dengan yang ada pada [Pod](/docs/user-guide/pods), kecuali _field_ ini bersifat _nested_ dan tidak memiliki _field_ `apiVersion` atau _field_ `kind`. Sebagai tambahan dari _field_ wajib pada sebuah Job, sebuah tempat pod pada Job haruslah menspesifikasikan label yang sesuai (perhatikan [selektor pod](#pod-selektor)) dan sebuah mekanisme _restart_ yang sesuai. -Hanya sebuah [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) yang sesuai dengan `Never` atau `OnFailure` yang bersifat valid. +Hanya sebuah [`RestartPolicy`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) yang sesuai dengan `Never` atau `OnFailure` yang bersifat valid. ### Selektor Pod @@ -194,7 +194,7 @@ Jika hal ini terjadi, dan `.spec.template.spec.restartPolicy = "OnFailure"`, mak akan tetap ada di dalam node, tetapi Container tersebut akan dijalankan kembali. Dengan demikian, program kamu harus dapat mengatasi kasus dimana program tersebut di-_restart_ secara lokal, atau jika tidak maka spesifikasikan `.spec.template.spec.restartPolicy = "Never"`. Perhatikan -[_lifecycle_ pod](/docs/concepts/workloads/pods/pod-lifecycle/#example-states) untuk informasi lebih lanjut mengenai `restartPolicy`. +[_lifecycle_ pod](/id/docs/concepts/workloads/pods/pod-lifecycle/#example-states) untuk informasi lebih lanjut mengenai `restartPolicy`. Sebuah Pod juga dapat gagal secara menyeluruh, untuk beberapa alasan yang mungkin, misalnya saja, ketika Pod tersebut dipindahkan dari Node (ketika Node diperbarui, di-_restart_, dihapus, dsb.), atau @@ -288,7 +288,7 @@ Pastikan kamu telah menspesifikasikan nilai tersebut pada level yang dibutuhkan. Job yang sudah selesai biasanya tidak lagi dibutuhkan di dalam sistem. Tetap menjaga keberadaan objek-objek tersebut di dalam sistem akan memberikan tekanan tambahan pada API server. Jika sebuah Job yang diatur secara langsung oleh _controller_ dengan level yang lebih tinggi, seperti -[CronJob](/docs/concepts/workloads/controllers/cron-jobs/), maka Job ini dapat +[CronJob](/id/docs/concepts/workloads/controllers/cron-jobs/), maka Job ini dapat di-_clean up_ oleh CronJob berdasarkan _policy_ berbasis kapasitas yang dispesifikasikan. ### Mekanisme TTL untuk Job yang Telah Selesai Dijalankan @@ -298,7 +298,7 @@ di-_clean up_ oleh CronJob berdasarkan _policy_ berbasis kapasitas yang dispesif Salah satu cara untuk melakukan _clean up_ Job yang telah selesai dijalankan (baik dengan status `Complete` atau `Failed`) secara otomatis adalah dengan menerapkan mekanisme TTL yang disediakan oleh -[_controller_ TTL](/docs/concepts/workloads/controllers/ttlafterfinished/) untuk +[_controller_ TTL](/id/docs/concepts/workloads/controllers/ttlafterfinished/) untuk sumber daya yang telah selesai digunakan, dengan cara menspesifikasikan _field_ `.spec.ttlSecondsAfterFinished` dari Job tersebut. @@ -334,7 +334,7 @@ maka Job ini tidak akan dihapus oleh _controller_ TTL setelah Job ini selesai di Perhatikan bahwa mekanisme TTL ini merupakan fitur alpha, dengan gerbang fitur `TTLAfterFinished`. Untuk informasi lebih lanjut, kamu dapat membaca dokumentasi untuk -[_controller_ TTL](/docs/concepts/workloads/controllers/ttlafterfinished/) untuk +[_controller_ TTL](/id/docs/concepts/workloads/controllers/ttlafterfinished/) untuk sumber daya yang telah selesai dijalankan. ## Pola Job @@ -478,7 +478,7 @@ Job merupakan komplemen dari [Replication Controller](/docs/user-guide/replicati Sebuah Replication Controller mengatur Pod yang diharapkan untuk tidak dihentikan (misalnya, _web server_), dan sebuah Job mengatur Pod yang diharapkan untuk berhenti (misalnya, _batch task_). -Seperti yang sudah dibahas pada [_Lifecycle_ Pod](/docs/concepts/workloads/pods/pod-lifecycle/), `Job` *hanya* pantas +Seperti yang sudah dibahas pada [_Lifecycle_ Pod](/id/docs/concepts/workloads/pods/pod-lifecycle/), `Job` *hanya* pantas digunakan untuk Pod dengan `RestartPolicy` yang sama dengan `OnFailure` atau `Never`. (Perhatikan bahwa: Jika `RestartPolicy` tidak dispesifikasikan, nilai defaultnya adalah `Always`.) @@ -499,7 +499,7 @@ dari sebuah Job, tetapi kontrol secara mutlak atas Pod yang dibuat serta tugas y ## CronJob {#cron-jobs} -Kamu dapat menggunakan [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) untuk membuat Job yang akan +Kamu dapat menggunakan [`CronJob`](/id/docs/concepts/workloads/controllers/cron-jobs/) untuk membuat Job yang akan dijalankan pada waktu/tanggal yang spesifik, mirip dengan perangkat lunak `cron` yang ada pada Unix. diff --git a/content/id/docs/concepts/workloads/controllers/replicaset.md b/content/id/docs/concepts/workloads/controllers/replicaset.md index c0c3a83d51..57b1124208 100644 --- a/content/id/docs/concepts/workloads/controllers/replicaset.md +++ b/content/id/docs/concepts/workloads/controllers/replicaset.md @@ -197,7 +197,7 @@ Untuk _field_ [_restart policy_](/docs/concepts/workloads/Pods/pod-lifecycle/#re ### Selektor Pod -_Field_ `.spec.selector` adalah sebuah [selektor labe](/docs/concepts/overview/working-with-objects/labels/). Seperti yang telah dibahas [sebelumnya](#how-a-replicaset-works), _field_ ini adalah label yang digunakan untuk mengidentifikasi Pod yang memungkinkan untuk diakuisisi. Pada contoh `frontend.yaml`, selektornya adalah: +_Field_ `.spec.selector` adalah sebuah [selektor labe](/id/docs/concepts/overview/working-with-objects/labels/). Seperti yang telah dibahas [sebelumnya](#how-a-replicaset-works), _field_ ini adalah label yang digunakan untuk mengidentifikasi Pod yang memungkinkan untuk diakuisisi. Pada contoh `frontend.yaml`, selektornya adalah: ```shell matchLabels: tier: frontend @@ -219,7 +219,7 @@ Jika nilai `.spec.replicas` tidak ditentukan maka akan diatur ke nilai _default_ ### Menghapus ReplicaSet dan Pod-nya -Untuk menghapus sebuah ReplicaSet beserta dengan Pod-nya, gunakan [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). [_Garbage collector_](/docs/concepts/workloads/controllers/garbage-collection/) secara otomatis akan menghapus semua Pod dependen secara _default_. +Untuk menghapus sebuah ReplicaSet beserta dengan Pod-nya, gunakan [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). [_Garbage collector_](/id/docs/concepts/workloads/controllers/garbage-collection/) secara otomatis akan menghapus semua Pod dependen secara _default_. Ketika menggunakan REST API atau _library_ `client-go`, kamu harus mengatur nilai `propagationPolicy` menjadi `Background` atau `Foreground` pada opsi -d. Sebagai contoh: @@ -243,7 +243,7 @@ curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/repli ``` Ketika ReplicaSet yang asli telah dihapus, kamu dapat membuat ReplicaSet baru untuk menggantikannya. Selama _field_ `.spec.selector` yang lama dan baru memilki nilai yang sama, maka ReplicaSet baru akan mengadopsi Pod lama namun tidak serta merta membuat Pod yang sudah ada sama dan sesuai dengan templat Pod yang baru. -Untuk memperbarui Pod dengan _spec_ baru dapat menggunakan [Deployment](/docs/concepts/workloads/controllers/deployment/#creating-a-deployment) karena ReplicaSet tidak mendukung pembaruan secara langsung. +Untuk memperbarui Pod dengan _spec_ baru dapat menggunakan [Deployment](/id/docs/concepts/workloads/controllers/deployment/#creating-a-deployment) karena ReplicaSet tidak mendukung pembaruan secara langsung. ### Mengisolasi Pod dari ReplicaSet @@ -275,7 +275,7 @@ kubectl autoscale rs frontend --max=10 ### Deployment (direkomendasikan) -[`Deployment`](/docs/concepts/workloads/controllers/deployment/) adalah sebuah objek yang bisa memiliki ReplicaSet dan memperbarui ReplicaSet dan Pod-nya melalui _rolling update_ deklaratif dan _server-side_. +[`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) adalah sebuah objek yang bisa memiliki ReplicaSet dan memperbarui ReplicaSet dan Pod-nya melalui _rolling update_ deklaratif dan _server-side_. Walaupun ReplicaSet dapat digunakan secara independen, seringkali ReplicaSet digunakan oleh Deployments sebagai mekanisme untuk mengorkestrasi pembuatan, penghapusan dan pembaruan Pod. Ketika kamu menggunakan Deployments kamu tidak perlu khawatir akan pengaturan dari ReplicaSet yang dibuat. Deployments memiliki dan mengatur ReplicaSet-nya sendiri. Maka dari itu penggunaan Deployments direkomendasikan jika kamu menginginkan ReplicaSet. @@ -289,9 +289,9 @@ Gunakan [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) alih-al ### DaemonSet -Gunakan [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) alih-alih ReplicaSet untuk Pod yang menyediakan fungsi pada level mesin, seperti _monitoring_ mesin atau _logging_ mesin. Pod ini memiliki waktu hidup yang bergantung terhadap waktu hidup mesin: Pod perlu untuk berjalan pada mesin sebelum Pod lain dijalankan, dan aman untuk diterminasi ketika mesin siap untuk di-_reboot_ atau dimatikan. +Gunakan [`DaemonSet`](/id/docs/concepts/workloads/controllers/daemonset/) alih-alih ReplicaSet untuk Pod yang menyediakan fungsi pada level mesin, seperti _monitoring_ mesin atau _logging_ mesin. Pod ini memiliki waktu hidup yang bergantung terhadap waktu hidup mesin: Pod perlu untuk berjalan pada mesin sebelum Pod lain dijalankan, dan aman untuk diterminasi ketika mesin siap untuk di-_reboot_ atau dimatikan. ### ReplicationController -ReplicaSet adalah suksesor dari [_ReplicationControllers_](/docs/concepts/workloads/controllers/replicationcontroller/). Keduanya memenuhi tujuan yang sama dan memiliki perilaku yang serupa, kecuali bahwa ReplicationController tidak mendukung kebutuhan selektor _set-based_ seperti yang dijelaskan pada [panduan penggunaan label](/docs/concepts/overview/working-with-objects/labels/#label-selectors). Pada kasus tersebut, ReplicaSet lebih direkomendasikan dibandingkan ReplicationController. +ReplicaSet adalah suksesor dari [_ReplicationControllers_](/id/docs/concepts/workloads/controllers/replicationcontroller/). Keduanya memenuhi tujuan yang sama dan memiliki perilaku yang serupa, kecuali bahwa ReplicationController tidak mendukung kebutuhan selektor _set-based_ seperti yang dijelaskan pada [panduan penggunaan label](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors). Pada kasus tersebut, ReplicaSet lebih direkomendasikan dibandingkan ReplicationController. diff --git a/content/id/docs/concepts/workloads/controllers/replicationcontroller.md b/content/id/docs/concepts/workloads/controllers/replicationcontroller.md index f828ff9c64..48ec718a6d 100644 --- a/content/id/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/id/docs/concepts/workloads/controllers/replicationcontroller.md @@ -13,7 +13,7 @@ weight: 20 {{< note >}} -[`Deployment`](/docs/concepts/workloads/controllers/deployment/) yang mengonfigurasi [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) sekarang menjadi cara yang direkomendasikan untuk melakukan replikasi. +[`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) yang mengonfigurasi [`ReplicaSet`](/id/docs/concepts/workloads/controllers/replicaset/) sekarang menjadi cara yang direkomendasikan untuk melakukan replikasi. {{< /note >}} Sebuah _ReplicationController_ memastikan bahwa terdapat sejumlah Pod yang sedang berjalan dalam suatu waktu tertentu. Dengan kata lain, ReplicationController memastikan bahwa sebuah Pod atau sebuah kumpulan Pod yang homogen selalu berjalan dan tersedia. @@ -101,7 +101,7 @@ Pada perintah di atas, selektor yang dimaksud adalah selektor yang sama dengan y Seperti semua konfigurasi Kubernetes lainnya, sebuah ReplicationController membutuhkan _field_ `apiVersion`, `kind`, dan `metadata`. -Untuk informasi umum mengenai berkas konfigurasi, kamu dapat melihat [pengaturan objek](/docs/concepts/overview/working-with-objects/object-management/). +Untuk informasi umum mengenai berkas konfigurasi, kamu dapat melihat [pengaturan objek](/id/docs/concepts/overview/working-with-objects/object-management/). Sebuah ReplicationController juga membutuhkan [bagian `.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). @@ -109,11 +109,11 @@ Sebuah ReplicationController juga membutuhkan [bagian `.spec`](https://git.k8s.i `.spec.template` adalah satu-satunya _field_ yang diwajibkan pada `.spec`. -`.spec.template` adalah sebuah [templat Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). Ia memiliki skema yang sama persis dengan sebuah [Pod](/docs/concepts/workloads/pods/pod/), namun dapat berbentuk _nested_ dan tidak memiliki _field_ `apiVersion` ataupun `kind`. +`.spec.template` adalah sebuah [templat Pod](/id/docs/concepts/workloads/pods/pod-overview/#pod-templates). Ia memiliki skema yang sama persis dengan sebuah [Pod](/id/docs/concepts/workloads/pods/pod/), namun dapat berbentuk _nested_ dan tidak memiliki _field_ `apiVersion` ataupun `kind`. Selain _field-field_ yang diwajibkan untuk sebuah Pod, templat Pod pada ReplicationController harus menentukan label dan kebijakan pengulangan kembali yang tepat. Untuk label, pastikan untuk tidak tumpang tindih dengan kontroler lain. Lihat [selektor pod](#selektor-pod). -Nilai yang diperbolehkan untuk [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) hanyalah `Always`, yaitu nilai bawaan jika tidak ditentukan. +Nilai yang diperbolehkan untuk [`.spec.template.spec.restartPolicy`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) hanyalah `Always`, yaitu nilai bawaan jika tidak ditentukan. Untuk pengulangan kembali dari sebuah kontainer lokal, ReplicationController mendelegasikannya ke agen pada Node, contohnya [Kubelet](/docs/admin/kubelet/) atau Docker. @@ -123,7 +123,7 @@ ReplicationController itu sendiri dapat memiliki label (`.metadata.labels`). Bia ### Selektor Pod -_Field_ `.spec.selector` adalah sebuah [selektor label](/docs/concepts/overview/working-with-objects/labels/#label-selectors). Sebuah ReplicationController mengatur semua Pod dengan label yang sesuai dengan nilai selektor tersebut. Ia tidak membedakan antara Pod yang ia buat atau hapus atau Pod yang dibuat atau dihapus oleh orang atau proses lain. Hal ini memungkinkan ReplicationController untuk digantikan tanpa memengaruhi Pod-Pod yang sedang berjalan. +_Field_ `.spec.selector` adalah sebuah [selektor label](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors). Sebuah ReplicationController mengatur semua Pod dengan label yang sesuai dengan nilai selektor tersebut. Ia tidak membedakan antara Pod yang ia buat atau hapus atau Pod yang dibuat atau dihapus oleh orang atau proses lain. Hal ini memungkinkan ReplicationController untuk digantikan tanpa memengaruhi Pod-Pod yang sedang berjalan. Jika ditentukan, `.spec.template.metadata.labels` harus memiliki nilai yang sama dengan `.spec.selector`, atau akan ditolak oleh API. Jika `.spec.selector` tidak ditentukan, maka akan menggunakan nilai bawaan yaitu `.spec.template.metadata.labels`. @@ -216,13 +216,13 @@ ReplicationController adalah sebuah sumber daya _top-level_ pada REST API Kubern ### ReplicaSet -[`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) adalah kelanjutan dari ReplicationController yang mendukung selektor [selektor label _set-based_](/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) yang baru. Umumnya digunakan oleh [`Deployment`](/docs/concepts/workloads/controllers/deployment/) sebagai mekanisme untuk mengorkestrasi pembuatan, penghapusan, dan pembaruan Pod. +[`ReplicaSet`](/id/docs/concepts/workloads/controllers/replicaset/) adalah kelanjutan dari ReplicationController yang mendukung selektor [selektor label _set-based_](/id/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) yang baru. Umumnya digunakan oleh [`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) sebagai mekanisme untuk mengorkestrasi pembuatan, penghapusan, dan pembaruan Pod. Perhatikan bahwa kami merekomendasikan untuk menggunakan Deployment sebagai ganti dari menggunakan ReplicaSet secara langsung, kecuali jika kamu membutuhkan orkestrasi pembaruan khusus atau tidak membutuhkan pembaruan sama sekali. ### Deployment (Direkomendasikan) -[`Deployment`](/docs/concepts/workloads/controllers/deployment/) adalah objek API tingkat tinggi yang memperbarui ReplicaSet dan Pod-Pod di bawahnya yang mirip dengan cara kerja `kubectl rolling-update`. Deployment direkomendasikan jika kamu menginginkan fungsionalitas dari pembaruan bergulir ini, karena tidak seperti `kubectl rolling-update`, Deployment memiliki sifat deklaratif, _server-side_, dan memiliki beberapa fitur tambahan lainnya. +[`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) adalah objek API tingkat tinggi yang memperbarui ReplicaSet dan Pod-Pod di bawahnya yang mirip dengan cara kerja `kubectl rolling-update`. Deployment direkomendasikan jika kamu menginginkan fungsionalitas dari pembaruan bergulir ini, karena tidak seperti `kubectl rolling-update`, Deployment memiliki sifat deklaratif, _server-side_, dan memiliki beberapa fitur tambahan lainnya. ### Pod sederhana @@ -234,7 +234,7 @@ Gunakan [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) sebagai ### DaemonSet -Gunakan [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) sebagai ganti ReplicationController untuk Pod-Pod yang menyediakan fungsi pada level mesin, seperti pengamatan mesin atau pencatatan mesin. Pod-Pod ini memiliki waktu hidup yang bergantung dengan waktu hidup mesin: Pod butuh untuk dijalankan di mesin sebelum Pod-Pod lainnya dimulai, dan aman untuk diterminasi ketika mesin sudah siap untuk dinyalakan ulang atau dimatikan. +Gunakan [`DaemonSet`](/id/docs/concepts/workloads/controllers/daemonset/) sebagai ganti ReplicationController untuk Pod-Pod yang menyediakan fungsi pada level mesin, seperti pengamatan mesin atau pencatatan mesin. Pod-Pod ini memiliki waktu hidup yang bergantung dengan waktu hidup mesin: Pod butuh untuk dijalankan di mesin sebelum Pod-Pod lainnya dimulai, dan aman untuk diterminasi ketika mesin sudah siap untuk dinyalakan ulang atau dimatikan. ## Informasi lanjutan diff --git a/content/id/docs/concepts/workloads/controllers/statefulset.md b/content/id/docs/concepts/workloads/controllers/statefulset.md index 9d12de91dd..aa99acd6e6 100644 --- a/content/id/docs/concepts/workloads/controllers/statefulset.md +++ b/content/id/docs/concepts/workloads/controllers/statefulset.md @@ -31,8 +31,8 @@ Stabil dalam poin-poin di atas memiliki arti yang sama dengan persisten pada Pod saat dilakukan _(re)scheduling_. Jika suatu aplikasi tidak membutuhkan identitas yang stabil atau _deployment_ yang memiliki urutan, penghapusan, atau mekanisme _scaling_, kamu harus melakukan _deploy_ aplikasi dengan _controller_ yang menyediakan -replika _stateless_. _Controller_ seperti [Deployment](/docs/concepts/workloads/controllers/deployment/) atau -[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) akan lebih sesuai dengan kebutuhan kamu. +replika _stateless_. _Controller_ seperti [Deployment](/id/docs/concepts/workloads/controllers/deployment/) atau +[ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/) akan lebih sesuai dengan kebutuhan kamu. ## Keterbatasan @@ -40,7 +40,7 @@ replika _stateless_. _Controller_ seperti [Deployment](/docs/concepts/workloads pada Kubernetes rilis sebelum versi 1.5. * Penyimpanan untuk sebuah Pod harus terlebih dahulu di-_provision_ dengan menggunakan sebuah [Provisioner PersistentVolume](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) berdasarkan `storage class` yang dispesifikasikan, atau sudah ditentukan sebelumnya oleh administrator. * Menghapus dan/atau _scaling_ sebuah StatefulSet *tidak akan* menghapus volume yang berkaitan dengan StatefulSet tersebut. Hal ini dilakukan untuk menjamin data yang disimpan, yang secara umum dinilai lebih berhaga dibandingkan dengan mekanisme penghapusan data secara otomatis pada sumber daya terkait. -* StatefulSet saat ini membutuhkan sebuah [Headless Service](/docs/concepts/services-networking/service/#headless-services) yang nantinya akan bertanggung jawab terhadap pada identitas jaringan pada Pod. Kamulah yang bertanggung jawab untuk membuat Service tersebut. +* StatefulSet saat ini membutuhkan sebuah [Headless Service](/id/docs/concepts/services-networking/service/#headless-services) yang nantinya akan bertanggung jawab terhadap pada identitas jaringan pada Pod. Kamulah yang bertanggung jawab untuk membuat Service tersebut. * StatefulSet tidak menjamin terminasi Pod ketika sebuah StatefulSet dihapus. Untuk mendapatkan terminasi Pod yang terurut dan _graceful_ pada StatefulSet, kita dapat melakukan _scale down_ Pod ke 0 sebelum penghapusan. * Ketika menggunakan [Rolling Update](#mekanisme-strategi-update-rolling-update) dengan [Kebijakan Manajemen Pod](#kebijakan-manajemen-pod) (`OrderedReady`) secara default, @@ -52,7 +52,7 @@ Contoh di bawah ini akna menunjukkan komponen-komponen penyusun StatefulSet. * Sebuah Service Headless, dengan nama nginx, digunakan untuk mengontrol domain jaringan. * StatefulSet, dengan nama web, memiliki Spek yang mengindikasikan terdapat 3 replika Container yang akan dihidupkan pada Pod yang unik. -* _Field_ `volumeClaimTemplates` akan menyediakan penyimpanan stabil menggunakan [PersistentVolume](/docs/concepts/storage/persistent-volumes/) yang di-_provision_ oleh sebuah Provisioner PersistentVolume. +* _Field_ `volumeClaimTemplates` akan menyediakan penyimpanan stabil menggunakan [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) yang di-_provision_ oleh sebuah Provisioner PersistentVolume. ```yaml apiVersion: v1 @@ -124,7 +124,7 @@ Setiap Pod di dalam StatefulSet memiliki _hostname_ diturunkan dari nama Satetul serta ordinal Pod tersebut. Pola pada _hostname_ yang terbentuk adalah `$(statefulset name)-$(ordinal)`. Contoh di atas akan menghasilkan tiga Pod dengan nama `web-0,web-1,web-2`. -Sebuah StatefulSet dapat menggunakan sebuah [Service Headless](/docs/concepts/services-networking/service/#headless-services) +Sebuah StatefulSet dapat menggunakan sebuah [Service Headless](/id/docs/concepts/services-networking/service/#headless-services) untuk mengontrol domain dari Pod yang ada. Domain yang diatur oleh Service ini memiliki format: `$(service name).$(namespace).svc.cluster.local`, dimana "cluster.local" merupakan domain klaster. @@ -133,7 +133,7 @@ Seiring dibuatnya setiap Pod, Pod tersebut akan memiliki subdomain DNS-nya sendi _field_ `serviceName` pada StatefulSet. Seperti sudah disebutkan di dalam bagian [keterbatasan](#keterbatasan), kamulah yang bertanggung jawab -untuk membuat [Service Headless](/docs/concepts/services-networking/service/#headless-services) +untuk membuat [Service Headless](/id/docs/concepts/services-networking/service/#headless-services) yang bertanggung jawab terhadap identitas jaringan pada Pod. Di sini terdapat beberapa contoh penggunaan Domain Klaster, nama Service, @@ -147,12 +147,12 @@ Domain Klaster | Service (ns/nama) | StatefulSet (ns/nama) | Domain StatefulSet {{< note >}} Domain klaster akan diatur menjadi `cluster.local` kecuali -[nilainya dikonfigurasi](/docs/concepts/services-networking/dns-pod-service/). +[nilainya dikonfigurasi](/id/docs/concepts/services-networking/dns-pod-service/). {{< /note >}} ### Penyimpanan Stabil -Kubernetes membuat sebuah [PersistentVolume](/docs/concepts/storage/persistent-volumes/) untuk setiap +Kubernetes membuat sebuah [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) untuk setiap VolumeClaimTemplate. Pada contoh nginx di atas, setiap Pod akan menerima sebuah PersistentVolume dengan StorageClass `my-storage-class` dan penyimpanan senilai 1 Gib yang sudah di-_provisioning_. Jika tidak ada StorageClass yang dispesifikasikan, maka StorageClass _default_ akan digunakan. Ketika sebuah Pod dilakukan _(re)schedule_ diff --git a/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md index f2c232faf2..0e1b36ccc5 100644 --- a/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -10,7 +10,7 @@ weight: 65 Pengendali TTL menyediakan mekanisme TTL yang membatasi umur dari suatu objek sumber daya yang telah selesai digunakan. Pengendali TTL untuk saat ini hanya menangani -[Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/), +[Jobs](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/), dan nantinya bisa saja digunakan untuk sumber daya lain yang telah selesai digunakan misalnya saja Pod atau sumber daya khusus (_custom resource_) lainnya. @@ -32,7 +32,7 @@ Pengendali TTL untuk saat ini hanya mendukung Job. Sebuah operator klaster dapat menggunakan fitur ini untuk membersihkan Job yang telah dieksekusi (baik `Complete` atau `Failed`) secara otomatis dengan menentukan _field_ `.spec.ttlSecondsAfterFinished` pada Job, seperti yang tertera di -[contoh](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically). +[contoh](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically). Pengendali TTL akan berasumsi bahwa sebuah sumber daya dapat dihapus apabila TTL dari sumber daya tersebut telah habis. Proses dihapusnya sumber daya ini dilakukan secara berantai, dimana sumber daya lain yang @@ -83,7 +83,7 @@ Perhatikan bahwa hal ini dapat terjadi apabila TTL diaktifkan dengan nilai selai ## {{% heading "whatsnext" %}} -[Membersikan Job secara Otomatis](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically) +[Membersikan Job secara Otomatis](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically) [Dokumentasi Rancangan](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) diff --git a/content/id/docs/concepts/workloads/pods/disruptions.md b/content/id/docs/concepts/workloads/pods/disruptions.md index 1adde6c949..7a09eed3a5 100644 --- a/content/id/docs/concepts/workloads/pods/disruptions.md +++ b/content/id/docs/concepts/workloads/pods/disruptions.md @@ -79,7 +79,7 @@ Jumlah Pod yang "diharapkan" dihitung dari `.spec.replicas` dari pengendali Pod PDB tidak dapat mencegah [disrupsi yang tidak disengaja](#disrupsi-yang-disengaja-dan-tidak-disengaja), tapi disrupsi ini akan dihitung terhadap bujet PDB. -Pod yang dihapus atau tidak tersetia dikarenakan pembaruan bertahap juga dihitung terhadap bujet PDB, tetapi pengendali (seperti Deployment dan StatefulSet) tidak dibatasi oleh PDB ketika melakukan pembaruan bertahap; Penanganan kerusakan saat pembaruan aplikasi dikonfigurasikan pada spesifikasi pengendali. (Pelajari tentang [memperbarui sebuah Deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment).) +Pod yang dihapus atau tidak tersetia dikarenakan pembaruan bertahap juga dihitung terhadap bujet PDB, tetapi pengendali (seperti Deployment dan StatefulSet) tidak dibatasi oleh PDB ketika melakukan pembaruan bertahap; Penanganan kerusakan saat pembaruan aplikasi dikonfigurasikan pada spesifikasi pengendali. (Pelajari tentang [memperbarui sebuah Deployment](/id/docs/concepts/workloads/controllers/deployment/#updating-a-deployment).) Saat sebuah Pod diusir menggunakan _eviction API_, Pod tersebut akan dihapus secara _graceful_ (lihat `terminationGracePeriodSeconds` pada [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#Podspec-v1-core).)) diff --git a/content/id/docs/concepts/workloads/pods/ephemeral-containers.md b/content/id/docs/concepts/workloads/pods/ephemeral-containers.md index 45154caf25..e952bdd19b 100644 --- a/content/id/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/id/docs/concepts/workloads/pods/ephemeral-containers.md @@ -80,7 +80,7 @@ pun, sehingga sulit untuk memecahkan masalah _image distroless_ dengan menggunakan `kubectl exec` saja. Saat menggunakan kontainer sementara, akan sangat membantu untuk mengaktifkan -[_process namespace sharing_](/docs/tasks/configure-pod-container/share-process-namespace/) +[_process namespace sharing_](/id/docs/tasks/configure-pod-container/share-process-namespace/) sehingga kamu dapat melihat proses pada kontainer lain. ### Contoh diff --git a/content/id/docs/concepts/workloads/pods/init-containers.md b/content/id/docs/concepts/workloads/pods/init-containers.md index 91807fdaf6..9cd208fbc8 100644 --- a/content/id/docs/concepts/workloads/pods/init-containers.md +++ b/content/id/docs/concepts/workloads/pods/init-containers.md @@ -14,7 +14,7 @@ Fitur ini telah keluar dari trek Beta sejak versi 1.6. Init Container dapat disp ## Memahami Init Container -Sebuah [Pod](/docs/concepts/workloads/pods/pod-overview/) dapat memiliki beberapa Container yang berjalan di dalamnya, dan dapat juga memiliki satu atau lebih Init Container, yang akan berjalan sebelum Container aplikasi dijalankan. +Sebuah [Pod](/id/docs/concepts/workloads/pods/pod-overview/) dapat memiliki beberapa Container yang berjalan di dalamnya, dan dapat juga memiliki satu atau lebih Init Container, yang akan berjalan sebelum Container aplikasi dijalankan. Init Container sama saja seperti Container biasa, kecuali: @@ -59,7 +59,7 @@ Berikut beberapa contoh kasus penggunaan Init Container: * Mengklon sebuah _git repository_ ke dalam sebuah _volume_. * Menaruh nilai-nilai tertentu ke dalam sebuah _file_ konfigurasi dan menjalankan peralatan _template_ untuk membuat _file_ konfigurasi secara dinamis untuk Container aplikasi utama. Misalnya, untuk menaruh nilai POD_IP ke dalam sebuah konfigurasi dan membuat konfigurasi aplikasi utama menggunakan Jinja. -Contoh-contoh penggunaan yang lebih detail dapat dilihat pada [dokumentasi StatefulSet](/docs/concepts/workloads/controllers/statefulset/) dan [petunjuk Produksi Pod](/docs/tasks/configure-pod-container/configure-pod-initialization/). +Contoh-contoh penggunaan yang lebih detail dapat dilihat pada [dokumentasi StatefulSet](/id/docs/concepts/workloads/controllers/statefulset/) dan [petunjuk Produksi Pod](/docs/tasks/configure-pod-container/configure-pod-initialization/). ### Menggunakan Init Container diff --git a/content/id/docs/concepts/workloads/pods/pod-lifecycle.md b/content/id/docs/concepts/workloads/pods/pod-lifecycle.md index 8dac6706a7..fdb3e7b71c 100644 --- a/content/id/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/id/docs/concepts/workloads/pods/pod-lifecycle.md @@ -52,7 +52,7 @@ Suatu Pod memiliki sebuah PodStatus, yang merupakan _array_ dari [PodConditions] * `PodScheduled`: Pod telah dijadwalkan masuk ke node; * `Ready`: Pod sudah mampu menerima _request_ masuk dan seharusnya sudah ditambahkan ke daftar pembagian beban kerja untuk servis yang sama; - * `Initialized`: Semua [init containers](/docs/concepts/workloads/pods/init-containers) telah berjalan sempurna. + * `Initialized`: Semua [init containers](/id/docs/concepts/workloads/pods/init-containers) telah berjalan sempurna. * `Unschedulable`: _scheduler_ belum dapat menjadwalkan Pod saat ini, sebagai contoh karena kekurangan _resources_ atau ada batasan-batasan lain. * `ContainersReady`: Semua kontainer di dalam Pod telah siap. @@ -191,7 +191,7 @@ status: ... ``` -Kondisi Pod yang baru harus memenuhi [format label](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) pada Kubernetes. +Kondisi Pod yang baru harus memenuhi [format label](/id/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) pada Kubernetes. Sejak perintah `kubectl patch` belum mendukung perubahan status objek, kondisi Pod yang baru harus mengubah melalui aksi `PATCH` dengan menggunakan salah satu dari [KubeClient _libraries_](/docs/reference/using-api/client-libraries/). @@ -232,13 +232,13 @@ Tiga tipe pengontrol yang tersedia yaitu: sebagai contoh, penghitungan dalam jumlah banyak. Jobs hanyak cocok untuk Pod dengan `restartPolicy` yang bernilai OnFailure atau Never. -- Menggunakan sebuah [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/), - [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/), atau - [Deployment](/docs/concepts/workloads/controllers/deployment/) untuk Pod yang tidak diharapkan untuk berakhir, +- Menggunakan sebuah [ReplicationController](/id/docs/concepts/workloads/controllers/replicationcontroller/), + [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/), atau + [Deployment](/id/docs/concepts/workloads/controllers/deployment/) untuk Pod yang tidak diharapkan untuk berakhir, sebagai contoh, _web servers_. ReplicationControllers hanya cocok digunakan pada Pod dengan `restartPolicy` yang bernilai Always. -- Menggunakan sebuah [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) untuk Pod yang akan berjalan +- Menggunakan sebuah [DaemonSet](/id/docs/concepts/workloads/controllers/daemonset/) untuk Pod yang akan berjalan hanya satu untuk setiap mesin, karena menyediakan servis yang spesifik untuk suatu mesin. @@ -346,7 +346,7 @@ spec: * Dapatkan pengalaman langsung mengenai [pengaturan _liveness_ dan _readiness probes_](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/). -* Pelajari lebih lanjut mengenai [_lifecycle hooks_ pada kontainer](/docs/concepts/containers/container-lifecycle-hooks/). +* Pelajari lebih lanjut mengenai [_lifecycle hooks_ pada kontainer](/id/docs/concepts/containers/container-lifecycle-hooks/). diff --git a/content/id/docs/concepts/workloads/pods/pod-overview.md b/content/id/docs/concepts/workloads/pods/pod-overview.md index 0e9593e0d1..f427358999 100644 --- a/content/id/docs/concepts/workloads/pods/pod-overview.md +++ b/content/id/docs/concepts/workloads/pods/pod-overview.md @@ -47,7 +47,7 @@ Setiap *Pod* diberikan sebuah alamat *IP* unik. Setiap kontainer di dalam *Pod* #### Penyimpanan -*Pod* dapat menentukan penyimpanan bersama yaitu *volumes*. Semua kontainer di dalam *Pod* dapat mengakses *volumes* ini, mengizinkan kontainer untuk berbagi data. *Volumes* juga memungkinkan data di *Pod* untuk bertahan jika salah satu kontainer perlu melakukan proses *restart*. Lihat *[Volumes](/docs/concepts/storage/volumes/)* untuk informasi lebih lanjut bagaimana Kubernetes mengimplementasikan penyimpanan di dalam *Pod*. +*Pod* dapat menentukan penyimpanan bersama yaitu *volumes*. Semua kontainer di dalam *Pod* dapat mengakses *volumes* ini, mengizinkan kontainer untuk berbagi data. *Volumes* juga memungkinkan data di *Pod* untuk bertahan jika salah satu kontainer perlu melakukan proses *restart*. Lihat *[Volumes](/id/docs/concepts/storage/volumes/)* untuk informasi lebih lanjut bagaimana Kubernetes mengimplementasikan penyimpanan di dalam *Pod*. ## Bekerja dengan Pod @@ -66,16 +66,16 @@ Kontroler dapat membuat dan mengelola banyak *Pod* untuk kamu, menangani replika Beberapa contoh kontroler yang berisi satu atau lebih *Pod* meliputi: -* [Deployment](/docs/concepts/workloads/controllers/deployment/) -* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) -* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) +* [Deployment](/id/docs/concepts/workloads/controllers/deployment/) +* [StatefulSet](/id/docs/concepts/workloads/controllers/statefulset/) +* [DaemonSet](/id/docs/concepts/workloads/controllers/daemonset/) Secara umum, kontroler menggunakan templat *Pod* yang kamu sediakan untuk membuat *Pod*. ## Templat Pod Templat *Pod* adalah spesifikasi dari *Pod* yang termasuk di dalam objek lain seperti -[Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/), [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), dan [DaemonSets](/docs/concepts/workloads/controllers/daemonset/). Kontroler menggunakan templat *Pod* untuk membuat *Pod*. +[Replication Controllers](/id/docs/concepts/workloads/controllers/replicationcontroller/), [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), dan [DaemonSets](/id/docs/concepts/workloads/controllers/daemonset/). Kontroler menggunakan templat *Pod* untuk membuat *Pod*. Contoh di bawah merupakan manifestasi sederhana untuk *Pod* yang berisi kontainer yang membuat sebuah pesan. @@ -102,6 +102,6 @@ Perubahan yang terjadi pada templat atau berganti ke templat yang baru tidak mem ## {{% heading "whatsnext" %}} * Pelajari lebih lanjut tentang perilaku *Pod*: - * [Terminasi Pod](/docs/concepts/workloads/pods/pod/#termination-of-pods) - * [Lifecycle Pod](/docs/concepts/workloads/pods/pod-lifecycle/) + * [Terminasi Pod](/id/docs/concepts/workloads/pods/pod/#termination-of-pods) + * [Lifecycle Pod](/id/docs/concepts/workloads/pods/pod-lifecycle/) diff --git a/content/id/docs/concepts/workloads/pods/pod.md b/content/id/docs/concepts/workloads/pods/pod.md index 3838ec56b5..e25a3a9104 100644 --- a/content/id/docs/concepts/workloads/pods/pod.md +++ b/content/id/docs/concepts/workloads/pods/pod.md @@ -39,7 +39,7 @@ dan bisa saling berkomunikasi melalui `localhost`. Komunikasi tersebut mengunaka standar _inter-process communications_ (IPC) seperti SystemV semaphores atau POSIX shared memory. Kontainer pada Pod yang berbeda memiliki alamat IP yang berbeda dan tidak dapat berkomunikasi menggunakan IPC tanpa -[pengaturan khusus](/docs/concepts/policy/pod-security-policy/). Kontainer ini +[pengaturan khusus](/id/docs/concepts/policy/pod-security-policy/). Kontainer ini biasa berkomunikasi dengan yang lain menggunakan alamat IP setiap Pod. Aplikasi dalam suatu Pod juga memiliki akses ke {{< glossary_tooltip text="ruang penyimpanan" term_id="volume" >}} bersama, @@ -51,14 +51,14 @@ gabungan dari kontainer Docker yang berbagi _namespace_ dan ruang penyimpanan _f Layaknya aplikasi dengan kontainer, Pod dianggap sebagai entitas yang relatif tidak kekal (tidak bertahan lama). Seperti yang didiskusikan dalam -[siklus hidup Pod](/docs/concepts/workloads/pods/pod-lifecycle/), Pod dibuat, diberikan +[siklus hidup Pod](/id/docs/concepts/workloads/pods/pod-lifecycle/), Pod dibuat, diberikan ID unik (UID), dan dijadwalkan pada suatu mesin dan akan tetap disana hingga dihentikan (bergantung pada aturan _restart_) atau dihapus. Jika {{< glossary_tooltip text="mesin" term_id="node" >}} mati, maka semua Pod pada mesin tersebut akan dijadwalkan untuk dihapus, namun setelah suatu batas waktu. Suatu Pod tertentu (sesuai dengan ID unik) tidak akan dijadwalkan ulang ke mesin baru, namun akan digantikan oleh Pod yang identik, bahkan jika dibutuhkan bisa dengan nama yang sama, tapi dengan ID unik yang baru -(baca [_replication controller_](/docs/concepts/workloads/controllers/replicationcontroller/) +(baca [_replication controller_](/id/docs/concepts/workloads/controllers/replicationcontroller/) untuk info lebih lanjut) Ketika sesuatu dikatakan memiliki umur yang sama dengan Pod, misalnya saja ruang penyimpanan, @@ -96,7 +96,7 @@ dan Pod lain dalam jaringan yang sama. Kontainer dalam suatu Pod melihat _hostname_ sistem sebagai sesuatu yang sama dengan konfigurasi `name` pada Pod. Informasi lebih lanjut terdapat dibagian -[jaringan](/docs/concepts/cluster-administration/networking/). +[jaringan](/id/docs/concepts/cluster-administration/networking/). Sebagai tambahan dalam mendefinisikan kontainer aplikasi yang berjalan dalam Pod, Pod memberikan sepaket sistem penyimpanan bersama. Sistem penyimpanan memungkinkan @@ -153,10 +153,10 @@ kasus mesin sedang dalam pemeliharaan. Secara umum, pengguna tidak seharusnya butuh membuat Pod secara langsung. Mereka seharusnya selalu menggunakan pengontrol, sekalipun untuk yang tunggal, misalnya, -[_Deployment_](/docs/concepts/workloads/controllers/deployment/). Pengontrol +[_Deployment_](/id/docs/concepts/workloads/controllers/deployment/). Pengontrol menyediakan penyembuhan diri dengan ruang lingkup kelompok, begitu juga dengan pengelolaan replikasi dan penluncuran. -Pengontrol seperti [_StatefulSet_](/docs/concepts/workloads/controllers/statefulset.md) +Pengontrol seperti [_StatefulSet_](/id/docs/concepts/workloads/controllers/statefulset.md) bisa memberikan dukungan terhadap Pod yang _stateful_. Penggunaan API kolektif sebagai _user-facing primitive_ utama adalah hal yang @@ -202,7 +202,7 @@ bersama dengan masa tenggang. 1. (bersamaan dengan poin 3) Ketika Kubelet melihat Pod sudah ditandai sebagai "Terminating" karena waktu pada poin 2 sudah diatur, ini memulai proses penghentian Pod 1. Jika salah satu kontainer pada Pod memiliki - [preStop _hook_](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), + [preStop _hook_](/id/docs/concepts/containers/container-lifecycle-hooks/#hook-details), maka akan dipanggil di dalam kontainer. Jika `preStop` _hook_ masih berjalan setelah masa tenggang habis, langkah 2 akan dipanggil dengan tambahan masa tenggang yang sedikit, 2 detik. @@ -223,7 +223,7 @@ Secara _default_, semua penghapusan akan berjalan normal selama 30 detik. Perint `kubectl delete` mendukung opsi `--grace-period=` yang akan memperbolehkan pengguna untuk menimpa nilai awal dan memberikan nilai sesuai keinginan pengguna. Nilai `0` akan membuat Pod -[dihapus paksa](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods). +[dihapus paksa](/id/docs/concepts/workloads/pods/pod/#force-deletion-of-pods). Kamu harus memberikan opsi tambahan `--force` bersamaan dengan `--grace-period=0` untuk melakukan penghapusan paksa. @@ -243,7 +243,7 @@ dokumentasi untuk [penghentian Pod dari StatefulSet](/docs/tasks/run-application ## Hak istimewa untuk kontainer pada Pod Setiap kontainer dalam Pod dapat mengaktifkan hak istimewa (mode _privileged_), dengan menggunakan tanda -`privileged` pada [konteks keamanan](/docs/tasks/configure-pod-container/security-context/) +`privileged` pada [konteks keamanan](/id/docs/tasks/configure-pod-container/security-context/) pada spesifikasi kontainer. Ini akan berguna untuk kontainer yang ingin menggunakan kapabilitas Linux seperti memanipulasi jaringan dan mengakses perangkat. Proses dalam kontainer mendapatkan hak istimewa yang hampir sama dengan proses di luar kontainer. diff --git a/content/id/docs/concepts/workloads/pods/podpreset.md b/content/id/docs/concepts/workloads/pods/podpreset.md index 2fc1b8598b..9b899c4687 100644 --- a/content/id/docs/concepts/workloads/pods/podpreset.md +++ b/content/id/docs/concepts/workloads/pods/podpreset.md @@ -57,6 +57,6 @@ Dalam rangka untuk menggunakan Pod Preset di dalam klaster kamu, kamu harus mema ## {{% heading "whatsnext" %}} - * [Memasukkan data ke dalam sebuah Pod dengan PodPreset](/docs/concepts/workloads/pods/pod/#injecting-data-into-a-pod-using-podpreset.md) + * [Memasukkan data ke dalam sebuah Pod dengan PodPreset](/id/docs/concepts/workloads/pods/pod/#injecting-data-into-a-pod-using-podpreset.md) diff --git a/content/id/docs/reference/access-authn-authz/rbac.md b/content/id/docs/reference/access-authn-authz/rbac.md index 8dd4c02c3a..49aa20ed6e 100644 --- a/content/id/docs/reference/access-authn-authz/rbac.md +++ b/content/id/docs/reference/access-authn-authz/rbac.md @@ -24,7 +24,7 @@ kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options ## Objek API {#api-overview} API RBAC mendeklarasikan empat jenis objek Kubernetes: Role, ClusterRole, -RoleBinding and ClusterRoleBinding. kamu bisa [mendeskripsikan beberapa objek](/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects), atau mengubahnya menggunakan alat seperti `kubectl`, seperti objek Kubernetes lain. +RoleBinding and ClusterRoleBinding. kamu bisa [mendeskripsikan beberapa objek](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects), atau mengubahnya menggunakan alat seperti `kubectl`, seperti objek Kubernetes lain. {{< caution >}} Objek-objek ini, dengan disengaja, memaksakan pembatasan akses. Jika kamu melakukan perubahan @@ -100,7 +100,7 @@ rules: verbs: ["get", "watch", "list"] ``` -Nama objek Role dan ClusterRole harus menggunakan [nama _path segment_](/docs/concepts/overview/working-with-objects/names#path-segment-names) yang valid. +Nama objek Role dan ClusterRole harus menggunakan [nama _path segment_](/id/docs/concepts/overview/working-with-objects/names#path-segment-names) yang valid. ### RoleBinding dan ClusterRoleBinding @@ -116,7 +116,7 @@ Jika kamu ingin memasangkan ClusterRole ke semua Namespace di klaster kamu, kamu ClusterRoleBinding. Nama objek RoleBinding atau ClusterRoleBinding harus valid menggunakan -[nama _path segment_](/docs/concepts/overview/working-with-objects/names#path-segment-names) yang valid. +[nama _path segment_](/id/docs/concepts/overview/working-with-objects/names#path-segment-names) yang valid. #### Contoh RoleBinding @@ -456,7 +456,7 @@ Di Kubernetes, modul otentikasi menyediakan informasi grup. Grup, seperti halnya pengguna, direpresentasikan sebagai string, dan string tersebut tidak memiliki format tertentu, selain awalan `system:` yang sudah direservasi. -[ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/) memiliki nama yang diawali dengan `system:serviceaccount:`, dan menjadi milik grup yang diawali dengan nama `system:serviceaccounts:`. +[ServiceAccount](/id/docs/tasks/configure-pod-container/configure-service-account/) memiliki nama yang diawali dengan `system:serviceaccount:`, dan menjadi milik grup yang diawali dengan nama `system:serviceaccounts:`. {{< note >}} - `system:serviceaccount:` (tunggal) adalah awalan untuk ServiceAccount _username_. @@ -1077,7 +1077,7 @@ In order from most secure to least secure, the approaches are: --namespace=my-namespace ``` - Many [add-ons](/docs/concepts/cluster-administration/addons/) run as the + Many [add-ons](/id/docs/concepts/cluster-administration/addons/) run as the "default" service account in the `kube-system` namespace. To allow those add-ons to run with super-user access, grant cluster-admin permissions to the "default" service account in the `kube-system` namespace. diff --git a/content/id/docs/reference/kubectl/cheatsheet.md b/content/id/docs/reference/kubectl/cheatsheet.md index 9afe999064..671ac6b77a 100644 --- a/content/id/docs/reference/kubectl/cheatsheet.md +++ b/content/id/docs/reference/kubectl/cheatsheet.md @@ -319,8 +319,8 @@ kubectl taint nodes foo dedicated=special-user:NoSchedule ### Berbagai Tipe Sumber Daya -Mendapatkan seluruh daftar tipe sumber daya yang didukung lengkap dengan singkatan pendeknya, [grup API](/docs/concepts/overview/kubernetes-api/#api-groups), -apakah sumber daya merupakan sumber daya yang berada di dalam Namespace atau tidak, serta [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects): +Mendapatkan seluruh daftar tipe sumber daya yang didukung lengkap dengan singkatan pendeknya, [grup API](/id/docs/concepts/overview/kubernetes-api/#api-groups), +apakah sumber daya merupakan sumber daya yang berada di dalam Namespace atau tidak, serta [Kind](/id/docs/concepts/overview/working-with-objects/kubernetes-objects): ```bash kubectl api-resources diff --git a/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md index e0db168ccd..8a345296a3 100644 --- a/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md +++ b/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md @@ -66,7 +66,7 @@ Semua perintah di dalam `kubeadm alpha`, sesuai definisi, didukung pada level _a ### Menginstal kubeadm pada hos -Lihat ["Menginstal kubeadm"](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/). +Lihat ["Menginstal kubeadm"](/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm/). {{< note >}} Jika kamu sudah menginstal kubeadm sebelumnya, jalankan `apt-get update && @@ -94,7 +94,7 @@ yang spesifik pada penyedia tertentu. Lihat [Menginstal _add-on_ jaringan Pod](# 3. (Opsional) Sejak versi 1.14, `kubeadm` mencoba untuk mendeteksi _runtime_ kontainer pada Linux dengan menggunakan daftar _domain socket path_ yang umum diketahui. Untuk menggunakan _runtime_ kontainer yang berbeda atau jika ada lebih dari satu yang terpasang pada Node yang digunakan, tentukan argumen `--cri-socket` -pada `kubeadm init`. Lihat [Menginstal _runtime_](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime). +pada `kubeadm init`. Lihat [Menginstal _runtime_](/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime). 4. (Opsional) Kecuali ditentukan sebelumnya, `kubeadm` akan menggunakan antarmuka jaringan yang diasosiasikan dengan _default gateway_ untuk mengatur alamat _advertise_ untuk API Server pada Node _control-plane_ ini. Untuk menggunakan antarmuka jaringan yang berbeda, tentukan argumen `--apiserver-advertise-address=` @@ -262,7 +262,7 @@ DNS klaster (CoreDNS) tidak akan menyala sebelum jaringan dipasangkan.** `--pod-network-cidr`, atau sebagai penggantinya pada YAML _plugin_ jaringan kamu). - Secara bawaan, `kubeadm` mengatur klastermu untuk menggunakan dan melaksanakan penggunaan - [RBAC](/docs/reference/access-authn-authz/rbac/) (_role based access control_). + [RBAC](/id/docs/reference/access-authn-authz/rbac/) (_role based access control_). Pastikan _plugin_ jaringan Pod mendukung RBAC, dan begitu juga seluruh manifes yang kamu gunakan untuk men-_deploy_-nya. @@ -571,14 +571,14 @@ opsinya. untuk detail mengenai pembaruan klaster menggunakan `kubeadm`. * Pelajari penggunaan `kubeadm` lebih lanjut pada [dokumentasi referensi kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm) * Pelajari lebih lanjut mengenai [konsep-konsep](/docs/concepts/) Kubernetes dan [`kubectl`](/docs/user-guide/kubectl-overview/). -* Lihat halaman [Cluster Networking](/docs/concepts/cluster-administration/networking/) untuk daftar +* Lihat halaman [Cluster Networking](/id/docs/concepts/cluster-administration/networking/) untuk daftar _add-on_ jaringan Pod yang lebih banyak. -* Lihat [daftar _add-on_](/docs/concepts/cluster-administration/addons/) untuk +* Lihat [daftar _add-on_](/id/docs/concepts/cluster-administration/addons/) untuk mengeksplor _add-on_ lainnya, termasuk perkakas untuk _logging_, _monitoring_, _network policy_, visualisasi & pengendalian klaster Kubernetes. * Atur bagaimana klaster mengelola log untuk peristiwa-peristiwa klaster dan dari aplikasi-aplikasi yang berjalan pada Pod. - Lihat [Arsitektur Logging](/docs/concepts/cluster-administration/logging/) untuk + Lihat [Arsitektur Logging](/id/docs/concepts/cluster-administration/logging/) untuk gambaran umum tentang hal-hal yang terlibat. ### Umpan balik @@ -602,7 +602,7 @@ Karena kita tidak dapat memprediksi masa depan, CLI kubeadm v{{< skew latestVers Sumber daya ini menyediakan informasi lebih lanjut mengenai _version skew_ yang didukung antara kubelet dan _control plane_, serta komponen Kubernetes lainnya: * [Kebijakan versi and version-skew Kubernetes](/docs/setup/release/version-skew-policy/) -* [Panduan instalasi](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl) spesifik untuk kubeadm +* [Panduan instalasi](/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl) spesifik untuk kubeadm ## Keterbatasan diff --git a/content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index c81e9f41ec..adcf73db77 100644 --- a/content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -11,7 +11,7 @@ card: Laman ini menunjukkan cara untuk menginstal `kubeadm`. -Untuk informasi mengenai cara membuat sebuah klaster dengan kubeadm setelah kamu melakukan proses instalasi ini, lihat laman [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/). +Untuk informasi mengenai cara membuat sebuah klaster dengan kubeadm setelah kamu melakukan proses instalasi ini, lihat laman [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/). @@ -132,14 +132,14 @@ Jika ditemukan selain dari kedua _runtime_ Container tersebut, kubeadm akan berh Komponen kubelet berintegrasi dengan Docker melalui implementasi CRI `dockershim` bawaannya. -Lihat [_runtime_ Container](/docs/setup/production-environment/container-runtimes/) +Lihat [_runtime_ Container](/id/docs/setup/production-environment/container-runtimes/) untuk informasi lebih lanjut. {{% /tab %}} {{% tab name="sistem operasi lainnya" %}} Secara bawaan, kubeadm menggunakan {{< glossary_tooltip term_id="docker" >}} sebagai _runtime_ Container. Komponen kubelet berintegrasi dengan Docker melalui implementasi CRI `dockershim` bawaannya. -Lihat [_runtime_ Container](/docs/setup/production-environment/container-runtimes/) +Lihat [_runtime_ Container](/id/docs/setup/production-environment/container-runtimes/) untuk informasi lebih lanjut. {{% /tab %}} {{< /tabs >}} @@ -174,7 +174,7 @@ Hal ini karena kubeadm dan Kubernetes membutuhkan Untuk informasi lebih lanjut mengenai _version skew_, lihat: * [Kebijakan _version-skew_ dan versi Kubernetes](/docs/setup/release/version-skew-policy/) -* [Kebijakan _version skew_](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy) yang spesifik untuk kubeadm +* [Kebijakan _version skew_](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy) yang spesifik untuk kubeadm {{< tabs name="k8s_install" >}} {{% tab name="Ubuntu, Debian atau HypriotOS" %}} @@ -304,4 +304,4 @@ Jika kamu menemui kesulitan dengan kubeadm, silakan merujuk pada [dokumen penyel ## {{% heading "whatsnext" %}} -* [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) +* [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) diff --git a/content/id/docs/tasks/access-application-cluster/access-cluster.md b/content/id/docs/tasks/access-application-cluster/access-cluster.md index 148f402402..6a575ad8f1 100644 --- a/content/id/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/id/docs/tasks/access-application-cluster/access-cluster.md @@ -178,7 +178,7 @@ Saat mengakses API dari Pod, pencarian dan autentikasi ke apiserver agak berbeda Cara yang disarankan untuk menemukan apiserver di dalam Pod adalah dengan nama DNS `kubernetes.default.svc`, yang akan mengubah kedalam bentuk Service IP yang pada gilirannya akan dialihkan ke apiserver. -Cara yang disarankan untuk mengautentikasi ke apiserver adalah dengan kredensial [akun servis](/docs/tasks/configure-pod-container/configure-service-account/). +Cara yang disarankan untuk mengautentikasi ke apiserver adalah dengan kredensial [akun servis](/id/docs/tasks/configure-pod-container/configure-service-account/). Oleh kube-system, Pod dikaitkan dengan sebuah akun servis (_service account_), dan sebuah kredensial (token) untuk akun servis (_service account_) tersebut ditempatkan ke pohon sistem berkas (_file system tree_) dari setiap Container di dalam Pod tersebut, di `/var/run/secrets/kubernetes.io/serviceaccount/token`. @@ -317,7 +317,7 @@ Ada beberapa proksi berbeda yang mungkin kamu temui saat menggunakan Kubernetes: - dapat digunakan untuk menjangkau Node, Pod, atau Service - melakukan _load balancing_ saat digunakan untuk menjangkau sebuah Service -1. [kube-proxy](/docs/concepts/services-networking/service/#ips-and-vips): +1. [kube-proxy](/id/docs/concepts/services-networking/service/#ips-and-vips): - berjalan di setiap Node - memproksi UDP dan TCP diff --git a/content/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index b2b80aacba..8775823304 100644 --- a/content/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -320,7 +320,7 @@ contexts: ``` Untuk informasi lebih tentang bagaimana berkas Kubeconfig tergabung, lihat -[Mengatur Akses Cluster Menggunakan Berkas Kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +[Mengatur Akses Cluster Menggunakan Berkas Kubeconfig](/id/docs/concepts/configuration/organize-cluster-access-kubeconfig/) ## Jelajahi direktori $HOME/.kube @@ -372,7 +372,7 @@ $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED ## {{% heading "whatsnext" %}} -* [Mengatur Akses Cluster Menggunakan Berkas Kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +* [Mengatur Akses Cluster Menggunakan Berkas Kubeconfig](/id/docs/concepts/configuration/organize-cluster-access-kubeconfig/) * [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config) diff --git a/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md b/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md index 1c6226b1be..d6d04df2ad 100644 --- a/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md +++ b/content/id/docs/tasks/access-application-cluster/create-external-load-balancer.md @@ -19,7 +19,7 @@ _asalkan klaster kamu beroperasi pada lingkungan yang mendukung dan terkonfigura Untuk informasi mengenai penyediaan dan penggunaan sumber daya Ingress yang dapat memberikan servis URL yang dapat dijangkau secara eksternal, penyeimbang beban lalu lintas, terminasi SSL, dll., -silahkan cek dokumentasi [Ingress](/docs/concepts/services-networking/ingress/) +silahkan cek dokumentasi [Ingress](/id/docs/concepts/services-networking/ingress/) @@ -35,7 +35,7 @@ silahkan cek dokumentasi [Ingress](/docs/concepts/services-networking/ingress/) ## Berkas konfigurasi Untuk membuat _load balancer_ eksternal, tambahkan baris di bawah ini ke -[berkas konfigurasi Service](/docs/concepts/services-networking/service/#loadbalancer) kamu: +[berkas konfigurasi Service](/id/docs/concepts/services-networking/service/#loadbalancer) kamu: ```yaml type: LoadBalancer diff --git a/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md index a83605db40..99d23c823d 100644 --- a/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/id/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -69,17 +69,17 @@ Tekan tombol **CREATE** di pojok kanan atas di laman apapun untuk memulai. _Deploy wizard_ meminta kamu untuk menyediakan informasi sebagai berikut: -- **App name** (wajib): Nama dari aplikasi kamu. Sebuah [label](/docs/concepts/overview/working-with-objects/labels/) dengan nama tersebut akan ditambahkan ke Deployment dan Service, jika ada, akan di-_deploy_. +- **App name** (wajib): Nama dari aplikasi kamu. Sebuah [label](/id/docs/concepts/overview/working-with-objects/labels/) dengan nama tersebut akan ditambahkan ke Deployment dan Service, jika ada, akan di-_deploy_. Nama aplikasi harus unik di dalam [Namespace](/docs/tasks/administer-cluster/namespaces/) Kubernetes yang kamu pilih. Nama tersebut harus dimulai dengan huruf kecil, dan diakhiri dengan huruf kecil atau angka, dan hanya berisi huruf kecil, angka dan tanda hubung (-). Nama tersebut juga dibatasi hanya 24 karakter. Spasi di depan dan belakang nama tersebut diabaikan. -- **Container image** (wajib): Tautan publik dari sebuah [_image_](/docs/concepts/containers/images/) kontainer Docker pada _registry_ apapun, atau sebuah _image_ privat (biasanya di-_hosting_ di Google Container Registry atau Docker Hub). Spesifikasi _image_ kontainer tersebut harus diakhiri dengan titik dua. +- **Container image** (wajib): Tautan publik dari sebuah [_image_](/id/docs/concepts/containers/images/) kontainer Docker pada _registry_ apapun, atau sebuah _image_ privat (biasanya di-_hosting_ di Google Container Registry atau Docker Hub). Spesifikasi _image_ kontainer tersebut harus diakhiri dengan titik dua. - **Number of pods** (wajib): Berapa banyak Pod yang kamu inginkan untuk men-_deploy_ aplikasimu. Nilainya haruslah sebuah bilangan bulat positif. - Sebuah [Deployment](/docs/concepts/workloads/controllers/deployment/) akan terbuat untuk mempertahankan jumlah Pod di klaster kamu. + Sebuah [Deployment](/id/docs/concepts/workloads/controllers/deployment/) akan terbuat untuk mempertahankan jumlah Pod di klaster kamu. -- **Service** (opsional): Untuk beberapa aplikasi (misalnya aplikasi _frontend_) kamu mungkin akan mengekspos sebuah [Service](/docs/concepts/services-networking/service/) ke alamat IP publik yang mungkin berada diluar klaster kamu(Service eksternal). Untuk Service eksternal, kamu mungkin perlu membuka lebih dari satu porta jaringan untuk mengeksposnya. Lihat lebih lanjut [di sini](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/). +- **Service** (opsional): Untuk beberapa aplikasi (misalnya aplikasi _frontend_) kamu mungkin akan mengekspos sebuah [Service](/id/docs/concepts/services-networking/service/) ke alamat IP publik yang mungkin berada diluar klaster kamu(Service eksternal). Untuk Service eksternal, kamu mungkin perlu membuka lebih dari satu porta jaringan untuk mengeksposnya. Lihat lebih lanjut [di sini](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/). Service lainnya yang hanya dapat diakses dari dalam klaster disebut Service internal. @@ -87,9 +87,9 @@ _Deploy wizard_ meminta kamu untuk menyediakan informasi sebagai berikut: Jika membutuhkan, kamu dapat membuka bagian **Advanced options** di mana kamu dapat menyetel lebih banyak pengaturan: -- **Description**: Tels yang kamu masukkan ke sini akan ditambahkan sebagai sebuah [anotasi](/docs/concepts/overview/working-with-objects/annotations/) ke Deployment dan akan ditampilkan di detail aplikasi. +- **Description**: Tels yang kamu masukkan ke sini akan ditambahkan sebagai sebuah [anotasi](/id/docs/concepts/overview/working-with-objects/annotations/) ke Deployment dan akan ditampilkan di detail aplikasi. -- **Labels**: [Label-label](/docs/concepts/overview/working-with-objects/labels/) bawaan yang akan digunakan untuk aplikasi kamu adalah `name` dan `version` aplikasi. Kamu dapat menentukan label lain untuk diterapkan ke Deployment, Service (jika ada), dan Pod, seperti `release`, `environment`, `tier`, `partition`, dan `track` rilis. +- **Labels**: [Label-label](/id/docs/concepts/overview/working-with-objects/labels/) bawaan yang akan digunakan untuk aplikasi kamu adalah `name` dan `version` aplikasi. Kamu dapat menentukan label lain untuk diterapkan ke Deployment, Service (jika ada), dan Pod, seperti `release`, `environment`, `tier`, `partition`, dan `track` rilis. Contoh: @@ -107,9 +107,9 @@ track=stable Jika pembuatan Namespace berhasil, Namespace tersebut akan dipilih secara bawaan. Jika pembuatannya gagal, maka Namespace yang pertama akan terpilih. -- **_Image Pull Secret_**: Jika kamu menggunakan _image_ kontainer Docker yang privat, mungkin diperlukan kredensial [_pull secret_](/docs/concepts/configuration/secret/). +- **_Image Pull Secret_**: Jika kamu menggunakan _image_ kontainer Docker yang privat, mungkin diperlukan kredensial [_pull secret_](/id/docs/concepts/configuration/secret/). - Dashboard menampilkan semua _secret_ yang tersedia dengan daftar _dropdown_, dan mengizinkan kamu untuk membuat _secret_ baru. Nama _secret_ tersebut harus mengikuti aturan Nama DNS, misalnya `new.image-pull.secret`. Isi dari sebuah _secret_ harus dienkode dalam bentuk _base64_ dan ditentukan dalam sebuah berkas [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). Nama kredensial dapat berisi maksimal 253 karakter. + Dashboard menampilkan semua _secret_ yang tersedia dengan daftar _dropdown_, dan mengizinkan kamu untuk membuat _secret_ baru. Nama _secret_ tersebut harus mengikuti aturan Nama DNS, misalnya `new.image-pull.secret`. Isi dari sebuah _secret_ harus dienkode dalam bentuk _base64_ dan ditentukan dalam sebuah berkas [`.dockercfg`](/id/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). Nama kredensial dapat berisi maksimal 253 karakter. Jika pembuatan _image pull secret_ berhasil, _image pull secret_ tersebut akan terpilih secara bawaan. Jika gagal, maka tidak ada _secret_ yang dipilih. @@ -123,7 +123,7 @@ track=stable ### Menggungah berkas YAML atau JSON -Kubernetes mendukung pengaturan deklaratif. Dengan cara ini, semua pengaturan disimpan dalam bentuk berkas YAML atau JSON menggunakan skema sumber daya [[API](/docs/concepts/overview/kubernetes-api/). +Kubernetes mendukung pengaturan deklaratif. Dengan cara ini, semua pengaturan disimpan dalam bentuk berkas YAML atau JSON menggunakan skema sumber daya [[API](/id/docs/concepts/overview/kubernetes-api/). Sebagai alternatif untuk menentukan detail aplikasi di _deploy wizard_, kamu dapat menentukan sendiri detail aplikasi kamu dalam berkas YAML atau JSON, dan mengunggah berkas tersebut menggunakan Dashboard. diff --git a/content/id/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/id/docs/tasks/configure-pod-container/configure-pod-configmap.md index e5175ccf0e..bfdad56610 100644 --- a/content/id/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/id/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -35,7 +35,7 @@ kubectl create configmap di mana \ merupakan nama yang ingin kamu berikan pada ConfigMap tersebut dan \ adalah direktori, berkas, atau nilai harfiah yang digunakan sebagai sumber data. Nama dari sebuah objek ConfigMap haruslah berupa -[nama subdomain DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) yang sah. +[nama subdomain DNS](/id/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) yang sah. Ketika kamu membuat ConfigMap dari sebuah berkas, secara bawaan, _basename_ dari berkas tersebut akan menjadi kunci pada \, dan isi dari berkas tersebut akan menjadi nilai dari kunci tersebut. @@ -615,14 +615,14 @@ Seperti sebelumnya, semua berkas yang sebelumnya berada pada direktori `/etc/con ### Memproyeksikan kunci ke jalur dan perizinan berkas tertentu Kamu dapat memproyeksikan kunci ke jalur dan perizinan tertentu pada setiap -berkas. Panduan pengguna [Secret](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod) menjelaskan mengenai sintaks-sintaksnya. +berkas. Panduan pengguna [Secret](/id/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod) menjelaskan mengenai sintaks-sintaksnya. ### ConfigMap yang dipasang akan diperbarui secara otomatis Ketika sebuah ConfigMap yang sudah dipasang pada sebuah volume diperbarui, kunci-kunci yang diproyeksikan akan turut diperbarui. Kubelet akan memeriksa apakah ConfigMap yang dipasang merupakan yang terbaru pada sinkronisasi berkala. Namun, ConfigMap menggunakan _cache_ lokal berbasis ttl (_time-to-live_) miliknya untuk mendapatkan nilai dari ConfigMap saat ini. Hasilnya, keseluruhan penundaan dari saat ketika ConfigMap diperbarui sampai saat ketika kunci-kunci baru diproyeksikan ke pada Pod bisa selama periode sinkronisasi kubelet (secara bawaan selama 1 menit) + ttl dari _cache_ ConfigMap (secara bawaan selama 1 menit) pada kubelet. Kamu dapat memicu pembaruan langsung dengan memperbarui salah satu dari anotasi Pod. {{< note >}} -Kontainer yang menggunakan ConfigMap sebagai volume [subPath](/docs/concepts/storage/volumes/#using-subpath) tidak akan menerima pembaruan ConfigMap. +Kontainer yang menggunakan ConfigMap sebagai volume [subPath](/id/docs/concepts/storage/volumes/#using-subpath) tidak akan menerima pembaruan ConfigMap. {{< /note >}} @@ -631,10 +631,10 @@ Kontainer yang menggunakan ConfigMap sebagai volume [subPath](/docs/concepts/sto ## Memahami ConfigMap dan Pod -Sumber daya API ConfigMap menyimpan data konfigurasi sebagai pasangan kunci-nilai. Data tersebut dapat dikonsumsi oleh Pod atau sebagai penyedia konfigurasi untuk komponen-komponen sistem seperti kontroler. ConfigMap mirip dengan [Secret](/docs/concepts/configuration/secret/), tetapi ConfigMap dimaksudkan untuk mengolah tulisan yang tidak memiliki informasi yang sensitif. Baik pengguna maupun komponen sistem dapat menyimpan data konfigurasi pada ConfigMap. +Sumber daya API ConfigMap menyimpan data konfigurasi sebagai pasangan kunci-nilai. Data tersebut dapat dikonsumsi oleh Pod atau sebagai penyedia konfigurasi untuk komponen-komponen sistem seperti kontroler. ConfigMap mirip dengan [Secret](/id/docs/concepts/configuration/secret/), tetapi ConfigMap dimaksudkan untuk mengolah tulisan yang tidak memiliki informasi yang sensitif. Baik pengguna maupun komponen sistem dapat menyimpan data konfigurasi pada ConfigMap. {{< note >}} -ConfigMap harus mereferensikan berkas-berkas properti, bukan menggantikannya. Anggaplah ConfigMap sebagai sesuatu yang merepresentasikan direktori `/etc` beserta isinya pada Linux. Sebagai contoh, jika kamu membuat sebuah [Volume Kubernetes](/docs/concepts/storage/volumes/) dari ConfigMap, tiap butir data pada ConfigMap direpresentasikan sebagai sebuah berkas pada volume. +ConfigMap harus mereferensikan berkas-berkas properti, bukan menggantikannya. Anggaplah ConfigMap sebagai sesuatu yang merepresentasikan direktori `/etc` beserta isinya pada Linux. Sebagai contoh, jika kamu membuat sebuah [Volume Kubernetes](/id/docs/concepts/storage/volumes/) dari ConfigMap, tiap butir data pada ConfigMap direpresentasikan sebagai sebuah berkas pada volume. {{< /note >}} Kolom `data` pada ConfigMap berisi data konfigurasi. Seperti pada contoh di bawah, hal ini bisa berupa sesuatu yang sederhana -- seperti properti individual yang ditentukan menggunakan `--from-literal` -- atau sesuatu yang kompleks -- seperti berkas konfigurasi atau _blob_ JSON yang ditentukan dengan `--from-file`. diff --git a/content/id/docs/tasks/configure-pod-container/configure-service-account.md b/content/id/docs/tasks/configure-pod-container/configure-service-account.md index 73c0946b8f..4a4d5999db 100644 --- a/content/id/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/id/docs/tasks/configure-pod-container/configure-service-account.md @@ -84,7 +84,7 @@ metadata: EOF ``` -Nama dari objek ServiceAccount haruslah sebuah [nama subdomain DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) yang valid. +Nama dari objek ServiceAccount haruslah sebuah [nama subdomain DNS](/id/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) yang valid. Jika kamu mendapatkan objek ServiceAccount secara komplit, seperti ini: @@ -108,7 +108,7 @@ secrets: maka kamu dapat melihat bahwa _token_ telah dibuat secara otomatis dan dirujuk oleh ServiceAccount. -Kamu dapat menggunakan _plugin_ otorisasi untuk [mengatur hak akses dari ServiceAccount](/docs/reference/access-authn-authz/rbac/#service-account-permissions). +Kamu dapat menggunakan _plugin_ otorisasi untuk [mengatur hak akses dari ServiceAccount](/id/docs/reference/access-authn-authz/rbac/#service-account-permissions). Untuk menggunakan ServiceAccount selain nilai standar, atur _field_ `spec.serviceAccountName` dari Pod menjadi nama dari ServiceAccount yang hendak kamu gunakan. @@ -280,7 +280,7 @@ ServiceAccountTokenVolumeProjection masih dalam tahap __beta__ untuk versi 1.12 Kubelet juga dapat memproyeksikan _token_ ServiceAccount ke Pod. Kamu dapat menentukan properti yang diinginkan dari _token_ seperti target pengguna dan durasi validitas. Properti tersebut tidak dapat diubah pada _token_ ServiceAccount standar. _Token_ ServiceAccount juga akan menjadi tidak valid terhadap API ketika Pod atau ServiceAccount dihapus. -Perilaku ini diatur pada PodSpec menggunakan tipe ProjectedVolume yaitu [ServiceAccountToken](/docs/concepts/storage/volumes/#projected). Untuk memungkinkan Pod dengan _token_ dengan pengguna bertipe _"vault"_ dan durasi validitas selama dua jam, kamu harus mengubah bagian ini pada PodSpec: +Perilaku ini diatur pada PodSpec menggunakan tipe ProjectedVolume yaitu [ServiceAccountToken](/id/docs/concepts/storage/volumes/#projected). Untuk memungkinkan Pod dengan _token_ dengan pengguna bertipe _"vault"_ dan durasi validitas selama dua jam, kamu harus mengubah bagian ini pada PodSpec: {{< codenew file="pods/pod-projected-svc-token.yaml" >}} diff --git a/content/id/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/id/docs/tasks/configure-pod-container/pull-image-private-registry.md index 2158afcf35..50aad8de9a 100644 --- a/content/id/docs/tasks/configure-pod-container/pull-image-private-registry.md +++ b/content/id/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -206,7 +206,7 @@ kubectl get pod private-reg * Pelajari lebih lanjut tentang [Secret](/id/docs/concepts/configuration/secret/). * Pelajari lebih lanjut tentang [menggunakan register pribadi](/id/docs/concepts/containers/images/#menggunakan-register-privat). -* Pelajari lebih lanjut tentang [menambahkan Secret untuk menarik _image_ ke dalam sebuah akun service](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account). +* Pelajari lebih lanjut tentang [menambahkan Secret untuk menarik _image_ ke dalam sebuah akun service](/id/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account). * Lihatlah [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-). * Lihatlah [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core). * Lihatlah bidang `imagePullSecrets` dari [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core). diff --git a/content/id/docs/tasks/configure-pod-container/security-context.md b/content/id/docs/tasks/configure-pod-container/security-context.md index f21655d3c5..d190468399 100644 --- a/content/id/docs/tasks/configure-pod-container/security-context.md +++ b/content/id/docs/tasks/configure-pod-container/security-context.md @@ -412,7 +412,7 @@ kubectl delete pod security-context-demo-4 * [Menyetel Docker dengan peningkatan keamanan terbaru](https://opensource.com/business/15/3/docker-security-tuning) * [Dokumen desain konteks keamanan](https://git.k8s.io/community/contributors/design-proposals/auth/security_context.md) * [Dokumen desain manajemen kepemilikan](https://git.k8s.io/community/contributors/design-proposals/storage/volume-ownership-management.md) -* [Kebijakan keamanan Pod](/docs/concepts/policy/pod-security-policy/) +* [Kebijakan keamanan Pod](/id/docs/concepts/policy/pod-security-policy/) * [Dokumen desain AllowPrivilegeEscalation](https://git.k8s.io/community/contributors/design-proposals/auth/no-new-privs.md) diff --git a/content/id/docs/tasks/job/automated-tasks-with-cron-jobs.md b/content/id/docs/tasks/job/automated-tasks-with-cron-jobs.md index 2139f51629..c2c4b9399f 100644 --- a/content/id/docs/tasks/job/automated-tasks-with-cron-jobs.md +++ b/content/id/docs/tasks/job/automated-tasks-with-cron-jobs.md @@ -16,7 +16,7 @@ CronJob memiliki keterbatasan dan kekhasan. Misalnya, dalam keadaan tertentu, sebuah CronJob dapat membuat banyak Job. Karena itu, Job haruslah _idempotent._ -Untuk informasi lanjut mengenai keterbatasan, lihat [CronJob](/docs/concepts/workloads/controllers/cron-jobs). +Untuk informasi lanjut mengenai keterbatasan, lihat [CronJob](/id/docs/concepts/workloads/controllers/cron-jobs). @@ -127,7 +127,7 @@ kubectl delete cronjob hello ``` Menghapus CronJob akan menghapus semua Job dan Pod yang telah terbuat dan menghentikanya dari pembuatan Job tambahan. -Kamu dapat membaca lebih lanjut tentang menghapus Job di [_garbage collection_](/docs/concepts/workloads/controllers/garbage-collection/). +Kamu dapat membaca lebih lanjut tentang menghapus Job di [_garbage collection_](/id/docs/concepts/workloads/controllers/garbage-collection/). ## Menulis Speifikasi Sebuah Cron @@ -162,8 +162,8 @@ Sebuah tanda tanya (`?`) dalam penjadwalan memiliki makna yang sama dengan tanda ### Templat Job `.spec.JobTemplate` adalah templat untuk sebuah Job, dan itu wajib. -Templat Job memiliki skema yang sama dengan [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/), kecuali jika bersarang dan tidak memiliki sebuah `apiVersion` atau `kind`. -Untuk informasi lebih lanjut tentang menulis sebuah Job `.spec` lihat [Menulis spesifikasi Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/#writing-a-job-spec). +Templat Job memiliki skema yang sama dengan [Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/), kecuali jika bersarang dan tidak memiliki sebuah `apiVersion` atau `kind`. +Untuk informasi lebih lanjut tentang menulis sebuah Job `.spec` lihat [Menulis spesifikasi Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/#writing-a-job-spec). ### _Starting Deadline_ diff --git a/content/id/docs/tasks/run-application/horizontal-pod-autoscaler.md b/content/id/docs/tasks/run-application/horizontal-pod-autoscaler.md index 85b90d1e9e..c4ed16413f 100644 --- a/content/id/docs/tasks/run-application/horizontal-pod-autoscaler.md +++ b/content/id/docs/tasks/run-application/horizontal-pod-autoscaler.md @@ -172,7 +172,7 @@ dapat ditemukan pada `autoscaling/v2beta2`. *Field* yang baru diperkenalkan pada `autoscaling/v2beta2` adalah *preserved* sebagai anotasi ketika menggunakan `autoscaling/v1`. Ketika kamu membuat sebuah HorizontalPodAutoscaler, pastikan nama yang ditentukan adalah valid -[nama subdomain DNS](/docs/concepts/overview/working-with-objects/names#nama). +[nama subdomain DNS](/id/docs/concepts/overview/working-with-objects/names#nama). Untuk lebih detail tentang objek API ini dapat ditemukan di [Objek HorizontalPodAutoscaler](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object). diff --git a/content/id/docs/tasks/tls/managing-tls-in-a-cluster.md b/content/id/docs/tasks/tls/managing-tls-in-a-cluster.md index 5cdc19c60e..9df307b56e 100644 --- a/content/id/docs/tasks/tls/managing-tls-in-a-cluster.md +++ b/content/id/docs/tasks/tls/managing-tls-in-a-cluster.md @@ -40,7 +40,7 @@ dan menambahkan sertifikat yang diurai ke `RootCAs` di _struct_ [`tls.Config`](https://godoc.org/crypto/tls#Config). Kamu bisa mendistribusikan sertifikat CA sebagai sebuah -[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap) yang bisa diakses oleh Pod kamu. +[ConfigMap](/id/docs/tasks/configure-pod-container/configure-pod-configmap) yang bisa diakses oleh Pod kamu. ## Meminta Sertifikat diff --git a/content/id/docs/tasks/tools/install-kubectl.md b/content/id/docs/tasks/tools/install-kubectl.md index e4d0019c3e..bc112c3cdd 100644 --- a/content/id/docs/tasks/tools/install-kubectl.md +++ b/content/id/docs/tasks/tools/install-kubectl.md @@ -284,7 +284,7 @@ Kamu dapat menginstal `kubectl` sebagai bagian dari Google Cloud SDK. ## Memeriksa konfigurasi kubectl -Agar `kubectl` dapat mengakses klaster Kubernetes, dibutuhkan sebuah [berkas kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/), yang akan otomatis dibuat ketika kamu membuat klaster baru menggunakan [kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh) atau setelah berhasil men-_deploy_ klaster Minikube. Secara bawaan, konfigurasi `kubectl` disimpan di `~/.kube/config`. +Agar `kubectl` dapat mengakses klaster Kubernetes, dibutuhkan sebuah [berkas kubeconfig](/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters/), yang akan otomatis dibuat ketika kamu membuat klaster baru menggunakan [kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh) atau setelah berhasil men-_deploy_ klaster Minikube. Secara bawaan, konfigurasi `kubectl` disimpan di `~/.kube/config`. Kamu dapat memeriksa apakah konfigurasi `kubectl` sudah benar dengan mengambil keadaan klaster: @@ -490,9 +490,9 @@ compinit ## {{% heading "whatsnext" %}} -* [Menginstal Minikube.](/docs/tasks/tools/install-minikube/) +* [Menginstal Minikube.](/id/docs/tasks/tools/install-minikube/) * Lihat [panduan persiapan](/docs/setup/) untuk mencari tahu tentang pembuatan klaster. * [Pelajari cara untuk menjalankan dan mengekspos aplikasimu.](/docs/tasks/access-application-cluster/service-access-application-cluster/) -* Jika kamu membutuhkan akses ke klaster yang tidak kamu buat, lihat [dokumen Berbagi Akses Klaster](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/). +* Jika kamu membutuhkan akses ke klaster yang tidak kamu buat, lihat [dokumen Berbagi Akses Klaster](/id/docs/tasks/access-application-cluster/configure-access-multiple-clusters/). * Baca [dokumen referensi kubectl](/docs/reference/kubectl/kubectl/) diff --git a/content/id/docs/tasks/tools/install-minikube.md b/content/id/docs/tasks/tools/install-minikube.md index 342f05246a..d3e10f4fd6 100644 --- a/content/id/docs/tasks/tools/install-minikube.md +++ b/content/id/docs/tasks/tools/install-minikube.md @@ -9,7 +9,7 @@ card: -Halaman ini menunjukkan cara instalasi [Minikube](/docs/tutorials/hello-minikube), sebuah alat untuk menjalankan sebuah klaster Kubernetes dengan satu Node pada mesin virtual yang ada di komputer kamu. +Halaman ini menunjukkan cara instalasi [Minikube](/id/docs/tutorials/hello-minikube), sebuah alat untuk menjalankan sebuah klaster Kubernetes dengan satu Node pada mesin virtual yang ada di komputer kamu. @@ -65,7 +65,7 @@ Hyper-V Requirements: A hypervisor has been detected. Features required for ### Menginstal kubectl -Pastikan kamu mempunyai kubectl yang terinstal. Kamu bisa menginstal kubectl dengan mengikuti instruksi pada halaman [Menginstal dan Menyiapkan kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux). +Pastikan kamu mempunyai kubectl yang terinstal. Kamu bisa menginstal kubectl dengan mengikuti instruksi pada halaman [Menginstal dan Menyiapkan kubectl](/id/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux). ### Menginstal sebuah Hypervisor @@ -125,7 +125,7 @@ brew install minikube {{% tab name="macOS" %}} ### Instalasi kubectl -Pastikan kamu mempunyai kubectl yang terinstal. Kamu bisa menginstal kubectl berdasarkan instruksi pada laman [Menginstal dan Menyiapkan kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos). +Pastikan kamu mempunyai kubectl yang terinstal. Kamu bisa menginstal kubectl berdasarkan instruksi pada laman [Menginstal dan Menyiapkan kubectl](/id/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos). ### Instalasi sebuah Hypervisor @@ -161,7 +161,7 @@ sudo mv minikube /usr/local/bin {{% tab name="Windows" %}} ### Instalasi kubectl -Pastikan kamu mempunyai kubectl yang terinstal. Kamu bisa menginstal kubectl berdasarkan instruksi pada halaman [Menginstal dan Menyiapkan kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows). +Pastikan kamu mempunyai kubectl yang terinstal. Kamu bisa menginstal kubectl berdasarkan instruksi pada halaman [Menginstal dan Menyiapkan kubectl](/id/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows). ### Menginstal sebuah Hypervisor diff --git a/content/id/docs/tutorials/_index.md b/content/id/docs/tutorials/_index.md index 1093644e15..f56702b94e 100644 --- a/content/id/docs/tutorials/_index.md +++ b/content/id/docs/tutorials/_index.md @@ -24,7 +24,7 @@ Sebelum melangkah lebih lanjut ke tutorial, sebaiknya tandai dulu halaman [Kamus * [Pengenalan Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#) -* [Halo Minikube](/docs/tutorials/hello-minikube/) +* [Halo Minikube](/id/docs/tutorials/hello-minikube/) ## Konfigurasi @@ -32,7 +32,7 @@ Sebelum melangkah lebih lanjut ke tutorial, sebaiknya tandai dulu halaman [Kamus ## Aplikasi Stateless -* [Memberi Akses Aplikasi di dalam Klaster melalui IP Eksternal](/docs/tutorials/stateless-application/expose-external-ip-address/) +* [Memberi Akses Aplikasi di dalam Klaster melalui IP Eksternal](/id/docs/tutorials/stateless-application/expose-external-ip-address/) * [Contoh: Deploy aplikasi Guestbook PHP dengan Redis](/docs/tutorials/stateless-application/guestbook/) diff --git a/content/id/docs/tutorials/hello-minikube.md b/content/id/docs/tutorials/hello-minikube.md index f2588e776b..faba283d89 100644 --- a/content/id/docs/tutorials/hello-minikube.md +++ b/content/id/docs/tutorials/hello-minikube.md @@ -19,7 +19,7 @@ Tutorial ini menunjukkan bagaimana caranya menjalankan aplikasi sederhana Node.j Katacoda menyediakan environment Kubernetes secara gratis di dalam browser. {{< note >}} -Kamupun bisa mengikuti tutorial ini kalau sudah instalasi [Minikube di lokal](/docs/tasks/tools/install-minikube/) kamu. +Kamupun bisa mengikuti tutorial ini kalau sudah instalasi [Minikube di lokal](/id/docs/tasks/tools/install-minikube/) kamu. {{< /note >}} @@ -68,9 +68,9 @@ Untuk info lebih lanjut tentang perintah `docker build`, baca [dokumentasi Docke ## Membuat sebuah Deployment -Sebuah Kubernetes [*Pod*](/docs/concepts/workloads/pods/pod/) adalah kumpulan dari satu atau banyak Kontainer, +Sebuah Kubernetes [*Pod*](/id/docs/concepts/workloads/pods/pod/) adalah kumpulan dari satu atau banyak Kontainer, saling terhubung untuk kebutuhan administrasi dan jaringan. Pod dalam tutorial ini hanya punya satu Kontainer. Sebuah Kubernetes -[*Deployment*](/docs/concepts/workloads/controllers/deployment/) selalu memeriksa kesehatan +[*Deployment*](/id/docs/concepts/workloads/controllers/deployment/) selalu memeriksa kesehatan Pod kamu dan melakukan restart saat Kontainer di dalam Pod tersebut mati. Deployment adalah cara jitu untuk membuat dan mereplikasi Pod. 1. Gunakan perintah `kubectl create` untuk membuat Deployment yang dapat mengatur Pod. @@ -122,7 +122,7 @@ Pod menjalankan Kontainer sesuai dengan image Docker yang telah diberikan. ## Membuat sebuah Servis Secara default, Pod hanya bisa diakses melalui alamat IP internal di dalam klaster Kubernetes. -Supaya Kontainer `hello-node` bisa diakses dari luar jaringan virtual Kubernetes, kamu harus ekspos Pod sebagai [*Servis*](/docs/concepts/services-networking/service/) Kubernetes. +Supaya Kontainer `hello-node` bisa diakses dari luar jaringan virtual Kubernetes, kamu harus ekspos Pod sebagai [*Servis*](/id/docs/concepts/services-networking/service/) Kubernetes. 1. Ekspos Pod pada internet publik menggunakan perintah `kubectl expose`: @@ -266,8 +266,8 @@ minikube delete ## {{% heading "whatsnext" %}} -* Pelajari lebih lanjut tentang [Deployment](/docs/concepts/workloads/controllers/deployment/). +* Pelajari lebih lanjut tentang [Deployment](/id/docs/concepts/workloads/controllers/deployment/). * Pelajari lebih lanjut tentang [Deploy aplikasi](/docs/user-guide/deploying-applications/). -* Pelajari lebih lanjut tentang [Servis](/docs/concepts/services-networking/service/). +* Pelajari lebih lanjut tentang [Servis](/id/docs/concepts/services-networking/service/). From ed8dfbda6e382afd1a4a2119376b86a3219ab3d0 Mon Sep 17 00:00:00 2001 From: Irvi Firqotul Aini Date: Sun, 12 Jul 2020 17:28:56 +0700 Subject: [PATCH 13/86] docs: Add Translation to Assign Pods to Nodes using Node Affinity --- .../assign-pods-nodes-using-node-affinity.md | 119 ++++++++++++++++++ .../pods/pod-nginx-preferred-affinity.yaml | 20 +++ .../pods/pod-nginx-required-affinity.yaml | 19 +++ 3 files changed, 158 insertions(+) create mode 100644 content/id/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md create mode 100644 content/id/examples/pods/pod-nginx-preferred-affinity.yaml create mode 100644 content/id/examples/pods/pod-nginx-required-affinity.yaml diff --git a/content/id/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md b/content/id/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md new file mode 100644 index 0000000000..a60d862fd2 --- /dev/null +++ b/content/id/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md @@ -0,0 +1,119 @@ +--- +title: Menempatkan Pod pada Node Menggunakan Afinitas Pod +min-kubernetes-server-version: v1.10 +content_type: task +weight: 120 +--- + + +Dokumen ini menunjukkan cara menempatkan Pod Kubernetes pada sebuah Node menggunakan +Afinitas Node di dalam klaster Kubernetes. + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + + +## Menambahkan sebuah Label pada sebuah Node + +1. Jabarkan Node-Node yang ada pada klaster kamu, bersamaan dengan label yang ada: + + ```shell + kubectl get nodes --show-labels + ``` + Keluaran dari perintah tersebut akan berupa: + + ```shell + NAME STATUS ROLES AGE VERSION LABELS + worker0 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker0 + worker1 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker1 + worker2 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker2 + ``` +1. Pilihkan salah satu dari Node yang ada dan tambahkan label pada Node tersebut. + + ```shell + kubectl label nodes disktype=ssd + ``` + dimana `` merupakan nama dari Node yang kamu pilih. + +1. Keluaran dari Node yang kamu pilih dan sudah memiliki label `disktype=ssd`: + + ```shell + kubectl get nodes --show-labels + ``` + + Keluaran dari perintah tersebut akan berupa: + + ``` + NAME STATUS ROLES AGE VERSION LABELS + worker0 Ready 1d v1.13.0 ...,disktype=ssd,kubernetes.io/hostname=worker0 + worker1 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker1 + worker2 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker2 + ``` + + Pada keluaran dari perintah di atas, kamu dapat melihat bahwa Node `worker0` + memiliki label `disktype=ssd`. + +## Menjadwalkan Pod menggunakan Afinitas Node + +Konfigurasi ini menunjukkan sebuah Pod yang memiliki afinitas node `requiredDuringSchedulingIgnoredDuringExecution`, `disktype: ssd`. +Dengan kata lain, Pod hanya akan dijadwalkan hanya pada Node yang memiliki label `disktype=ssd`. + +{{< codenew file="pods/pod-nginx-required-affinity.yaml" >}} + +1. Terapkan konfigurasi berikut untuk membuat sebuah Pod yang akan dijadwalkan pada Node yang kamu pilih: + + ```shell + kubectl apply -f https://k8s.io/examples/pods/pod-nginx-required-affinity.yaml + ``` + +1. Verifikasi apakah Pod yang kamu pilih sudah dijalankan pada Node yang kamu pilih: + + ```shell + kubectl get pods --output=wide + ``` + + Keluaran dari perintah tersebut akan berupa: + + ``` + NAME READY STATUS RESTARTS AGE IP NODE + nginx 1/1 Running 0 13s 10.200.0.4 worker0 + ``` + +## Jadwalkan Pod menggunakan Afinitas Node yang Dipilih + +Konfigurasi ini memberikan deskripsi sebuah Pod yang memiliki afinitas Node `preferredDuringSchedulingIgnoredDuringExecution`,`disktype: ssd`. +Artinya Pod akan diutamakan dijalankan pada Node yang memiliki label `disktype=ssd`. + +{{< codenew file="pods/pod-nginx-preferred-affinity.yaml" >}} + +1. Terapkan konfigurasi berikut untuk membuat sebuah Pod yang akan dijadwalkan pada Node yang kamu pilih: + + ```shell + kubectl apply -f https://k8s.io/examples/pods/pod-nginx-preferred-affinity.yaml + ``` + +1. Verifikasi apakah Pod yang kamu pilih sudah dijalankan pada Node yang kamu pilih: + + ```shell + kubectl get pods --output=wide + ``` + + Keluaran dari perintah tersebut akan berupa: + + ``` + NAME READY STATUS RESTARTS AGE IP NODE + nginx 1/1 Running 0 13s 10.200.0.4 worker0 + ``` + + + +## {{% heading "whatsnext" %}} + +Pelajari lebih lanjut mengenai +[Afinitas Node](/id/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity). diff --git a/content/id/examples/pods/pod-nginx-preferred-affinity.yaml b/content/id/examples/pods/pod-nginx-preferred-affinity.yaml new file mode 100644 index 0000000000..f169576bc2 --- /dev/null +++ b/content/id/examples/pods/pod-nginx-preferred-affinity.yaml @@ -0,0 +1,20 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + affinity: + nodeAffinity: + preferredDuringSchedulingIgnoredDuringExecution: + - weight: 1 + preference: + matchExpressions: + - key: disktype + operator: In + values: + - ssd + containers: + - name: nginx + image: nginx + imagePullPolicy: IfNotPresent + diff --git a/content/id/examples/pods/pod-nginx-required-affinity.yaml b/content/id/examples/pods/pod-nginx-required-affinity.yaml new file mode 100644 index 0000000000..a1093da188 --- /dev/null +++ b/content/id/examples/pods/pod-nginx-required-affinity.yaml @@ -0,0 +1,19 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + affinity: + nodeAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + nodeSelectorTerms: + - matchExpressions: + - key: disktype + operator: In + values: + - ssd + containers: + - name: nginx + image: nginx + imagePullPolicy: IfNotPresent + From df7b5416e68c0a4935de1a3eff5b08bbd27c3ec9 Mon Sep 17 00:00:00 2001 From: Benjamin Elder Date: Thu, 16 Jul 2020 23:28:19 -0700 Subject: [PATCH 14/86] automatically tag docker image based on hugo version and dockerfile version --- Dockerfile | 5 +++++ Makefile | 3 ++- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/Dockerfile b/Dockerfile index 3e3335076c..2ff4db8602 100644 --- a/Dockerfile +++ b/Dockerfile @@ -4,6 +4,11 @@ # change is that the Hugo version is now an overridable argument rather than a fixed # environment variable. +# Bump this by 1 whenever you change the Dockerfile below, e.g. if +# `DOCKERFFILE_VERSION=1` then change this to `DOCKERFILE_VERSION=2` when you +# change something else in this file. +# DOCKERFILE_VERSION=0 + FROM alpine:latest LABEL maintainer="Luc Perkins " diff --git a/Makefile b/Makefile index c6a411ddd2..149dc9c57e 100644 --- a/Makefile +++ b/Makefile @@ -6,7 +6,8 @@ NETLIFY_FUNC = $(NODE_BIN)/netlify-lambda # but this can be overridden when calling make, e.g. # CONTAINER_ENGINE=podman make container-image CONTAINER_ENGINE ?= docker -CONTAINER_IMAGE = kubernetes-hugo +DOCKERFILE_VERSION = $(shell grep DOCKERFILE_VERSION Dockerfile | tail -n 1 | cut -d '=' -f 2 | tr -d " \"\n") +CONTAINER_IMAGE = kubernetes-hugo:v$(HUGO_VERSION)-$(DOCKERFILE_VERSION) CONTAINER_RUN = $(CONTAINER_ENGINE) run --rm --interactive --tty --volume $(CURDIR):/src CCRED=\033[0;31m From b1b66740c3e63524804ba4167ed7426e36d85424 Mon Sep 17 00:00:00 2001 From: Aris Cahyadi Risdianto Date: Wed, 8 Jul 2020 00:35:48 +0800 Subject: [PATCH 15/86] ID localization for administer cluster - network policy - calico Fix translation word. Addressing several comments. --- .../calico-network-policy.md | 52 +++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 content/id/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md diff --git a/content/id/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md b/content/id/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md new file mode 100644 index 0000000000..9eb79e7676 --- /dev/null +++ b/content/id/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md @@ -0,0 +1,52 @@ +--- +title: Menggunakan Calico untuk NetworkPolicy +content_type: task +weight: 10 +--- + + +Laman ini menunjukkan beberapa cara cepat untuk membuat klaster Calico pada Kubernetes. + + +## {{% heading "prerequisites" %}} + +Putuskan apakah kamu ingin menggelar (_deploy_) sebuah klaster di [_cloud_](#membuat-klaster-calico-menggunakan-google-kubernetes-engine-gke) atau di [lokal](#membuat-klaster-calico-dengan-kubeadm). + + + +## Membuat klaster Calico dengan menggunakan _Google Kubernetes Engine_ (GKE) {#membuat-klaster-calico-menggunakan-google-kubernetes-engine-gke} + +**Prasyarat**: [gcloud](https://cloud.google.com/sdk/docs/quickstarts). + +1. Untuk meluncurkan klaster GKE dengan Calico, cukup sertakan opsi `--enable-network-policy`. + + **Sintaksis** + ```shell + gcloud container clusters create [CLUSTER_NAME] --enable-network-policy + ``` + + **Contoh** + ```shell + gcloud container clusters create my-calico-cluster --enable-network-policy + ``` + +2. Untuk memverifikasi penggelaran, gunakanlah perintah berikut ini. + + ```shell + kubectl get pods --namespace=kube-system + ``` + + Pod Calico dimulai dengan kata `calico`. Periksa untuk memastikan bahwa statusnya `Running`. + +## Membuat klaster lokal Calico dengan kubeadm {#membuat-klaster-calico-dengan-kubeadm} + +Untuk membuat satu klaster Calico dengan hos tunggal dalam waktu lima belas menit dengan menggunakan kubeadm, silakan merujuk pada + +[Memulai cepat Calico](https://docs.projectcalico.org/latest/getting-started/kubernetes/). + + +## {{% heading "whatsnext" %}} + +Setelah klaster kamu berjalan, kamu dapat mengikuti [Mendeklarasikan Kebijakan Jaringan](/id/docs/tasks/administer-cluster/declare-network-policy/) untuk mencoba NetworkPolicy Kubernetes. + + From 57e7cf6c7df2a8eba9aa01d69f80fd851025b1c7 Mon Sep 17 00:00:00 2001 From: Arhell Date: Mon, 20 Jul 2020 01:17:38 +0300 Subject: [PATCH 16/86] fix broken field on the main page in the video block --- assets/scss/_base.scss | 2 +- content/en/_index.html | 1 - 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/assets/scss/_base.scss b/assets/scss/_base.scss index fab7dd4e7e..ad462067c6 100644 --- a/assets/scss/_base.scss +++ b/assets/scss/_base.scss @@ -511,7 +511,7 @@ section#cncf { } #desktopKCButton { - position: relative; + position: absolute; font-size: 18px; background-color: $dark-grey; border-radius: 8px; diff --git a/content/en/_index.html b/content/en/_index.html index 97e02aa259..08ff1658d4 100644 --- a/content/en/_index.html +++ b/content/en/_index.html @@ -41,7 +41,6 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise

-
Attend KubeCon EU virtually on August 17-20, 2020

From 139da7d7316f031c139f7c17c666ebe836f5fbb6 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Fri, 17 Jul 2020 12:07:19 +0800 Subject: [PATCH 17/86] Tidy up: fix bad links in contribution guide --- content/en/docs/contribute/_index.md | 49 ++-- content/en/docs/contribute/advanced.md | 35 +-- .../contribute/generate-ref-docs/kubectl.md | 9 +- .../generate-ref-docs/kubernetes-api.md | 4 +- .../prerequisites-ref-docs.md | 3 +- .../generate-ref-docs/quickstart.md | 7 +- content/en/docs/contribute/localization.md | 2 +- .../docs/contribute/new-content/overview.md | 8 +- .../en/docs/contribute/participate/_index.md | 19 +- .../participate/roles-and-responsibilities.md | 237 ++++++++++++++++++ .../participate/roles-and-responsibilties.md | 195 -------------- .../docs/contribute/review/for-approvers.md | 11 +- .../docs/contribute/review/reviewing-prs.md | 8 +- .../en/docs/contribute/style/content-guide.md | 6 +- .../contribute/style/hugo-shortcodes/index.md | 4 +- .../contribute/style/page-content-types.md | 2 +- .../en/docs/contribute/style/style-guide.md | 11 +- .../docs/contribute/style/write-new-topic.md | 4 +- 18 files changed, 337 insertions(+), 277 deletions(-) create mode 100644 content/en/docs/contribute/participate/roles-and-responsibilities.md delete mode 100644 content/en/docs/contribute/participate/roles-and-responsibilties.md diff --git a/content/en/docs/contribute/_index.md b/content/en/docs/contribute/_index.md index d8f57e5e82..cd1b03efd4 100644 --- a/content/en/docs/contribute/_index.md +++ b/content/en/docs/contribute/_index.md @@ -28,41 +28,62 @@ Kubernetes documentation welcomes improvements from all contributors, new and ex ## Getting started -Anyone can open an issue about documentation, or contribute a change with a pull request (PR) to the [`kubernetes/website` GitHub repository](https://github.com/kubernetes/website). You need to be comfortable with [git](https://git-scm.com/) and [GitHub](https://lab.github.com/) to operate effectively in the Kubernetes community. +Anyone can open an issue about documentation, or contribute a change with a +pull request (PR) to the +[`kubernetes/website` GitHub repository](https://github.com/kubernetes/website). +You need to be comfortable with +[git](https://git-scm.com/) and +[GitHub](https://lab.github.com/) +to work effectively in the Kubernetes community. To get involved with documentation: 1. Sign the CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md). -2. Familiarize yourself with the [documentation repository](https://github.com/kubernetes/website) and the website's [static site generator](https://gohugo.io). -3. Make sure you understand the basic processes for [opening a pull request](/docs/contribute/new-content/new-content/) and [reviewing changes](/docs/contribute/review/reviewing-prs/). +1. Familiarize yourself with the [documentation repository](https://github.com/kubernetes/website) + and the website's [static site generator](https://gohugo.io). +1. Make sure you understand the basic processes for + [opening a pull request](/docs/contribute/new-content/open-a-pr/) and + [reviewing changes](/docs/contribute/review/reviewing-prs/). Some tasks require more trust and more access in the Kubernetes organization. -See [Participating in SIG Docs](/docs/contribute/participating/) for more details about +See [Participating in SIG Docs](/docs/contribute/participate/) for more details about roles and permissions. ## Your first contribution -- Read the [Contribution overview](/docs/contribute/new-content/overview/) to learn about the different ways you can contribute. -- See [Contribute to kubernetes/website](https://github.com/kubernetes/website/contribute) to find issues that make good entry points. -- [Open a pull request using GitHub](/docs/contribute/new-content/new-content/#changes-using-github) to existing documentation and learn more about filing issues in GitHub. -- [Review pull requests](/docs/contribute/review/reviewing-prs/) from other Kubernetes community members for accuracy and language. -- Read the Kubernetes [content](/docs/contribute/style/content-guide/) and [style guides](/docs/contribute/style/style-guide/) so you can leave informed comments. -- Learn about [page content types](/docs/contribute/style/page-content-types/) and [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/). +- Read the [Contribution overview](/docs/contribute/new-content/overview/) to + learn about the different ways you can contribute. +- Check [kubernetes/website issues list](/https://github.com/kubernetes/website/issues/) + for issues that make good entry points. +- [Open a pull request using GitHub](/docs/contribute/new-content/open-a-pr/#changes-using-github) + to existing documentation and learn more about filing issues in GitHub. +- [Review pull requests](/docs/contribute/review/reviewing-prs/) from other + Kubernetes community members for accuracy and language. +- Read the Kubernetes [content](/docs/contribute/style/content-guide/) and + [style guides](/docs/contribute/style/style-guide/) so you can leave informed comments. +- Learn about [page content types](/docs/contribute/style/page-content-types/) + and [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/). ## Next steps -- Learn to [work from a local clone](/docs/contribute/new-content/new-content/#fork-the-repo) of the repository. +- Learn to [work from a local clone](/docs/contribute/new-content/open-a-pr/#fork-the-repo) + of the repository. - Document [features in a release](/docs/contribute/new-content/new-features/). -- Participate in [SIG Docs](/docs/contribute/participating/), and become a [member or reviewer](/docs/contribute/participating/#roles-and-responsibilities). +- Participate in [SIG Docs](/docs/contribute/participate/), and become a + [member or reviewer](/docs/contribute/participate/roles-and-responsibilities/). + - Start or help with a [localization](/docs/contribute/localization/). ## Get involved with SIG Docs -[SIG Docs](/docs/contribute/participating/) is the group of contributors who publish and maintain Kubernetes documentation and the website. Getting involved with SIG Docs is a great way for Kubernetes contributors (feature development or otherwise) to have a large impact on the Kubernetes project. +[SIG Docs](/docs/contribute/participate/) is the group of contributors who +publish and maintain Kubernetes documentation and the website. Getting +involved with SIG Docs is a great way for Kubernetes contributors (feature +development or otherwise) to have a large impact on the Kubernetes project. SIG Docs communicates with different methods: -- [Join `#sig-docs` on the Kubernetes Slack instance](http://slack.k8s.io/). Make sure to +- [Join `#sig-docs` on the Kubernetes Slack instance](https://slack.k8s.io/). Make sure to introduce yourself! - [Join the `kubernetes-sig-docs` mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs), where broader discussions take place and official decisions are recorded. diff --git a/content/en/docs/contribute/advanced.md b/content/en/docs/contribute/advanced.md index 44c72916d9..e50287842a 100644 --- a/content/en/docs/contribute/advanced.md +++ b/content/en/docs/contribute/advanced.md @@ -13,13 +13,12 @@ This page assumes that you understand how to to learn about more ways to contribute. You need to use the Git command line client and other tools for some of these tasks. - - ## Propose improvements -SIG Docs [members](/docs/contribute/participating/#members) can propose improvements. +SIG Docs [members](/docs/contribute/participate/roles-and-responsibilities/#members) +can propose improvements. After you've been contributing to the Kubernetes documentation for a while, you may have ideas for improving the [Style Guide](/docs/contribute/style/style-guide/) @@ -42,8 +41,8 @@ documentation testing might involve working with sig-testing. ## Coordinate docs for a Kubernetes release -SIG Docs [approvers](/docs/contribute/participating/#approvers) can coordinate -docs for a Kubernetes release. +SIG Docs [approvers](/docs/contribute/participate/roles-and-responsibilities/#approvers) +can coordinate docs for a Kubernetes release. Each Kubernetes release is coordinated by a team of people participating in the sig-release Special Interest Group (SIG). Others on the release team for a given @@ -73,8 +72,8 @@ rotated among SIG Docs approvers. ## Serve as a New Contributor Ambassador -SIG Docs [approvers](/docs/contribute/participating/#approvers) can serve as -New Contributor Ambassadors. +SIG Docs [approvers](/docs/contribute/participate/roles-and-responsibilities/#approvers) +can serve as New Contributor Ambassadors. New Contributor Ambassadors welcome new contributors to SIG-Docs, suggest PRs to new contributors, and mentor new contributors through their first @@ -92,14 +91,14 @@ Current New Contributor Ambassadors are announced at each SIG-Docs meeting, and ## Sponsor a new contributor -SIG Docs [reviewers](/docs/contribute/participating/#reviewers) can sponsor -new contributors. +SIG Docs [reviewers](/docs/contribute/participate/roles-and-responsibilities/#reviewers) +can sponsor new contributors. After a new contributor has successfully submitted 5 substantive pull requests to one or more Kubernetes repositories, they are eligible to apply for -[membership](/docs/contribute/participating#members) in the Kubernetes -organization. The contributor's membership needs to be backed by two sponsors -who are already reviewers. +[membership](/docs/contribute/participate/roles-and-responsibilities/#members) +in the Kubernetes organization. The contributor's membership needs to be +backed by two sponsors who are already reviewers. New docs contributors can request sponsors by asking in the #sig-docs channel on the [Kubernetes Slack instance](https://kubernetes.slack.com) or on the @@ -111,7 +110,8 @@ membership in the Kubernetes organization. ## Serve as a SIG Co-chair -SIG Docs [approvers](/docs/contribute/participating/#approvers) can serve a term as a co-chair of SIG Docs. +SIG Docs [approvers](/docs/contribute/participate/roles-and-responsibilities/#approvers) +can serve a term as a co-chair of SIG Docs. ### Prerequisites @@ -120,7 +120,12 @@ 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](/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). +- 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 ### Responsibilities @@ -183,4 +188,4 @@ When you’re ready to start the recording, click Record to Cloud. When you’re ready to stop recording, click Stop. -The video uploads automatically to YouTube. \ No newline at end of file +The video uploads automatically to YouTube. diff --git a/content/en/docs/contribute/generate-ref-docs/kubectl.md b/content/en/docs/contribute/generate-ref-docs/kubectl.md index a1fed1642e..ea6065472e 100644 --- a/content/en/docs/contribute/generate-ref-docs/kubectl.md +++ b/content/en/docs/contribute/generate-ref-docs/kubectl.md @@ -15,21 +15,16 @@ like [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) and [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint). This topic does not show how to generate the -[kubectl](/docs/reference/generated/kubectl/kubectl/) +[kubectl](/docs/reference/generated/kubectl/kubectl-commands/) options reference page. For instructions on how to generate the kubectl options reference page, see -[Generating Reference Pages for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/). +[Generating Reference Pages for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/). {{< /note >}} - - ## {{% heading "prerequisites" %}} - {{< include "prerequisites-ref-docs.md" >}} - - ## Setting up the local repositories diff --git a/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md b/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md index f68d81dfb4..f2ec01d8e8 100644 --- a/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md +++ b/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md @@ -194,16 +194,14 @@ The use of `make docker-serve` is deprecated. Please use `make container-serve` In `` run `git add` and `git commit` to commit the change. Submit your changes as a -[pull request](/docs/contribute/start/) to the +[pull request](/docs/contribute/new-content/open-a-pr/) to the [kubernetes/website](https://github.com/kubernetes/website) repository. Monitor your pull request, and respond to reviewer comments as needed. Continue to monitor your pull request until it has been merged. - ## {{% heading "whatsnext" %}} - * [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/) * [Generating Reference Docs for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/) * [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/) diff --git a/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md b/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md index a777fb77e5..c719920813 100644 --- a/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md +++ b/content/en/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md @@ -18,4 +18,5 @@ - You need to know how to create a pull request to a GitHub repository. This involves creating your own fork of the repository. For more - information, see [Work from a local clone](/docs/contribute/intermediate/#work_from_a_local_clone). + information, see [Work from a local clone](/docs/contribute/new-content/open-a-pr/#fork-the-repo). + diff --git a/content/en/docs/contribute/generate-ref-docs/quickstart.md b/content/en/docs/contribute/generate-ref-docs/quickstart.md index df5cdbb95f..0790f7925a 100644 --- a/content/en/docs/contribute/generate-ref-docs/quickstart.md +++ b/content/en/docs/contribute/generate-ref-docs/quickstart.md @@ -10,15 +10,10 @@ This page shows how to use the `update-imported-docs` script to generate the Kubernetes reference documentation. The script automates the build setup and generates the reference documentation for a release. - - ## {{% heading "prerequisites" %}} - {{< include "prerequisites-ref-docs.md" >}} - - ## Getting the docs repository @@ -87,7 +82,7 @@ The `update-imported-docs` script performs the following steps: the sections in the `kubectl` command reference. When the generated files are in your local clone of the `` -repository, you can submit them in a [pull request](/docs/contribute/start/) +repository, you can submit them in a [pull request](/docs/contribute/new-content/open-a-pr/) to ``. ## Configuration file format diff --git a/content/en/docs/contribute/localization.md b/content/en/docs/contribute/localization.md index 0c698305b9..1ae4796522 100644 --- a/content/en/docs/contribute/localization.md +++ b/content/en/docs/contribute/localization.md @@ -183,7 +183,7 @@ Description | URLs -----|----- Home | [All heading and subheading URLs](/docs/home/) Setup | [All heading and subheading URLs](/docs/setup/) -Tutorials | [Kubernetes Basics](/docs/tutorials/kubernetes-basics/), [Hello Minikube](/docs/tutorials/stateless-application/hello-minikube/) +Tutorials | [Kubernetes Basics](/docs/tutorials/kubernetes-basics/), [Hello Minikube](/docs/tutorials/hello-minikube/) Site strings | [All site strings in a new localized TOML file](https://github.com/kubernetes/website/tree/master/i18n) Translated documents must reside in their own `content/**/` subdirectory, but otherwise follow the same URL path as the English source. For example, to prepare the [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) tutorial for translation into German, create a subfolder under the `content/de/` folder and copy the English source: diff --git a/content/en/docs/contribute/new-content/overview.md b/content/en/docs/contribute/new-content/overview.md index e9ef332430..b1f7e4f20a 100644 --- a/content/en/docs/contribute/new-content/overview.md +++ b/content/en/docs/contribute/new-content/overview.md @@ -20,8 +20,12 @@ This section contains information you should know before contributing new conten - Write Kubernetes documentation in Markdown and build the Kubernetes site using [Hugo](https://gohugo.io/). - The source is in [GitHub](https://github.com/kubernetes/website). You can find Kubernetes documentation at `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory. - [Page content types](/docs/contribute/style/page-content-types/) describe the presentation of documentation content in Hugo. -- In addition to the standard Hugo shortcodes, we use a number of [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our documentation to control the presentation of content. -- Documentation source is available in multiple languages in `/content/`. Each language has its own folder with a two-letter code determined by the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For example, English documentation source is stored in `/content/en/docs/`. +- In addition to the standard Hugo shortcodes, we use a number of + [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our documentation to control the presentation of content. +- Documentation source is available in multiple languages in `/content/`. Each + language has its own folder with a two-letter code determined by the + [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For + example, English documentation source is stored in `/content/en/docs/`. - For more information about contributing to documentation in multiple languages or starting a new translation, see [localization](/docs/contribute/localization). ## Before you begin {#before-you-begin} diff --git a/content/en/docs/contribute/participate/_index.md b/content/en/docs/contribute/participate/_index.md index a99eaf464e..a5c0f2880a 100644 --- a/content/en/docs/contribute/participate/_index.md +++ b/content/en/docs/contribute/participate/_index.md @@ -20,18 +20,18 @@ SIG Docs welcomes content and reviews from all contributors. Anyone can open a pull request (PR), and anyone is welcome to file issues about content or comment on pull requests in progress. -You can also become a [member](/docs/contribute/participating/roles-and-responsibilities/#members), -[reviewer](/docs/contribute/participating/roles-and-responsibilities/#reviewers), or [approver](/docs/contribute/participating/roles-and-responsibilities/#approvers). These roles require greater -access and entail certain responsibilities for approving and committing changes. -See [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md) +You can also become a [member](/docs/contribute/participate/roles-and-responsibilities/#members), +[reviewer](/docs/contribute/participate/roles-and-responsibilities/#reviewers), or +[approver](/docs/contribute/participate/roles-and-responsibilities/#approvers). +These roles require greater access and entail certain responsibilities for +approving and committing changes. See +[community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md) for more information on how membership works within the Kubernetes community. The rest of this document outlines some unique ways these roles function within SIG Docs, which is responsible for maintaining one of the most public-facing aspects of Kubernetes -- the Kubernetes website and documentation. - - ## SIG Docs chairperson @@ -58,8 +58,9 @@ There are two categories of SIG Docs [teams](https://github.com/orgs/kubernetes/ Each can be referenced with their `@name` in GitHub comments to communicate with everyone in that group. -Sometimes Prow and GitHub teams overlap without matching exactly. For assignment of issues, pull requests, and to support PR approvals, -the automation uses information from `OWNERS` files. +Sometimes Prow and GitHub teams overlap without matching exactly. For +assignment of issues, pull requests, and to support PR approvals, the +automation uses information from `OWNERS` files. ### OWNERS files and front-matter @@ -114,6 +115,6 @@ SIG Docs approvers. Here's how it works. For more information about contributing to the Kubernetes documentation, see: -- [Contributing new content](/docs/contribute/overview/) +- [Contributing new content](/docs/contribute/new-content/overview/) - [Reviewing content](/docs/contribute/review/reviewing-prs) - [Documentation style guide](/docs/contribute/style/) diff --git a/content/en/docs/contribute/participate/roles-and-responsibilities.md b/content/en/docs/contribute/participate/roles-and-responsibilities.md new file mode 100644 index 0000000000..8ebe7a1303 --- /dev/null +++ b/content/en/docs/contribute/participate/roles-and-responsibilities.md @@ -0,0 +1,237 @@ +--- +title: Roles and responsibilities +content_type: concept +weight: 10 +--- + + + +Anyone can contribute to Kubernetes. As your contributions to SIG Docs grow, +you can apply for different levels of membership in the community. +These roles allow you to take on more responsibility within the community. +Each role requires more time and commitment. The roles are: + +- Anyone: regular contributors to the Kubernetes documentation +- Members: can assign and triage issues and provide non-binding review on pull requests +- Reviewers: can lead reviews on documentation pull requests and can vouch for a change's quality +- Approvers: can lead reviews on documentation and merge changes + + + +## Anyone + +Anyone with a GitHub account can contribute to Kubernetes. SIG Docs welcomes all new contributors! + +Anyone can: + +- Open an issue in any [Kubernetes](https://github.com/kubernetes/) + repository, including + [`kubernetes/website`](https://github.com/kubernetes/website) +- Give non-binding feedback on a pull request +- Contribute to a localization +- Suggest improvements on [Slack](https://slack.k8s.io/) or the + [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). + +After [signing the CLA](/docs/contribute/new-content/overview/#sign-the-cla), anyone can also: + +- Open a pull request to improve existing content, add new content, or write a blog post or case study +- Create diagrams, graphics assets, and embeddable screencasts and videos + +For more information, see [contributing new content](/docs/contribute/new-content/). + +## Members + +A member is someone who has submitted multiple pull requests to +`kubernetes/website`. Members are a part of the +[Kubernetes GitHub organization](https://github.com/kubernetes). + +Members can: + +- Do everything listed under [Anyone](#anyone) +- Use the `/lgtm` comment to add the LGTM (looks good to me) label to a pull request + + {{< note >}} + Using `/lgtm` triggers automation. If you want to provide non-binding + approval, simply commenting "LGTM" works too! + {{< /note >}} + +- Use the `/hold` comment to block merging for a pull request +- Use the `/assign` comment to assign a reviewer to a pull request +- Provide non-binding review on pull requests +- Use automation to triage and categorize issues +- Document new features + +### Becoming a member + +After submitting at least 5 substantial pull requests and meeting the other +[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#member): + +1. Find two [reviewers](#reviewers) or [approvers](#approvers) to + [sponsor](/docs/contribute/advanced#sponsor-a-new-contributor) your + membership. + + Ask for sponsorship in the [#sig-docs channel on Slack](https://kubernetes.slack.com) or on the + [SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). + + {{< note >}} + Don't send a direct email or Slack direct message to an individual + SIG Docs member. You must request sponsorship before submitting your application. + {{< /note >}} + +1. Open a GitHub issue in the + [`kubernetes/org`](https://github.com/kubernetes/org/) repository. Use the + **Organization Membership Request** issue template. + +1. Let your sponsors know about the GitHub issue. You can either: + - Mention their GitHub username in an issue (`@`) + - Send them the issue link using Slack or email. + + Sponsors will approve your request with a `+1` vote. Once your sponsors + approve the request, a Kubernetes GitHub admin adds you as a member. + Congratulations! + + If your membership request is not accepted you will receive feedback. + After addressing the feedback, apply again. + +1. Accept the invitation to the Kubernetes GitHub organization in your email account. + + {{< note >}} + GitHub sends the invitation to the default email address in your account. + {{< /note >}} + +## Reviewers + +Reviewers are responsible for reviewing open pull requests. Unlike member +feedback, you must address reviewer feedback. Reviewers are members of the +[@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs) +GitHub team. + +Reviewers can: + +- Do everything listed under [Anyone](#anyone) and [Members](#members) +- Review pull requests and provide binding feedback + + {{< note >}} + To provide non-binding feedback, prefix your comments with a phrase like "Optionally: ". + {{< /note >}} + +- Edit user-facing strings in code +- Improve code comments + +You can be a SIG Docs reviewer, or a reviewer for docs in a specific subject area. + +### Assigning reviewers to pull requests + +Automation assigns reviewers to all pull requests. You can request a +review from a specific person by commenting: `/assign +[@_github_handle]`. + +If the assigned reviewer has not commented on the PR, another reviewer can +step in. You can also assign technical reviewers as needed. + +### Using `/lgtm` + +LGTM stands for "Looks good to me" and indicates that a pull request is +technically accurate and ready to merge. All PRs need a `/lgtm` comment from a +reviewer and a `/approve` comment from an approver to merge. + +A `/lgtm` comment from reviewer is binding and triggers automation that adds the `lgtm` label. + +### Becoming a reviewer + +When you meet the +[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer), +you can become a SIG Docs reviewer. Reviewers in other SIGs must apply +separately for reviewer status in SIG Docs. + +To apply: + +1. Open a pull request that adds your GitHub user name to a section of the + [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file + in the `kubernetes/website` repository. + + {{< note >}} + If you aren't sure where to add yourself, add yourself to `sig-docs-en-reviews`. + {{< /note >}} + +1. Assign the PR to one or more SIG-Docs approvers (user names listed under + `sig-docs-{language}-owners`). + +If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, +[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) +assigns and suggests you as a reviewer on new pull requests. + +## Approvers + +Approvers review and approve pull requests for merging. Approvers are members of the +[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs) +GitHub teams. + +Approvers can do the following: + +- Everything listed under [Anyone](#anyone), [Members](#members) and [Reviewers](#reviewers) +- Publish contributor content by approving and merging pull requests using the `/approve` comment +- Propose improvements to the style guide +- Propose improvements to docs tests +- Propose improvements to the Kubernetes website or other tooling + +If the PR already has a `/lgtm`, or if the approver also comments with +`/lgtm`, the PR merges automatically. A SIG Docs approver should only leave a +`/lgtm` on a change that doesn't need additional technical review. + + +### Approving pull requests + +Approvers and SIG Docs leads are the only ones who can merge pull requests +into the website repository. This comes with certain responsibilities. + +- Approvers can use the `/approve` command, which merges PRs into the repo. + + {{< warning >}} + A careless merge can break the site, so be sure that when you merge something, you mean it. + {{< /warning >}} + +- Make sure that proposed changes meet the + [contribution guidelines](/docs/contribute/style/content-guide/#contributing-content). + + If you ever have a question, or you're not sure about something, feel free + to call for additional review. + +- Verify that Netlify tests pass before you `/approve` a PR. + + Netlify tests must pass before approving + +- Visit the Netlify page preview for a PR to make sure things look good before approving. + +- Participate in the + [PR Wrangler rotation schedule](https://github.com/kubernetes/website/wiki/PR-Wranglers) + for weekly rotations. SIG Docs expects all approvers to participate in this + rotation. See [PR wranglers](/docs/contribute/participate/pr-wranglers/). + for more details. + +### Becoming an approver + +When you meet the +[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#approver), +you can become a SIG Docs approver. Approvers in other SIGs must apply +separately for approver status in SIG Docs. + +To apply: + +1. Open a pull request adding yourself to a section of the + [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) + file in the `kubernetes/website` repository. + + {{< note >}} + If you aren't sure where to add yourself, add yourself to `sig-docs-en-owners`. + {{< /note >}} + +2. Assign the PR to one or more current SIG Docs approvers. + +If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, +[@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) +assigns and suggests you as a reviewer on new pull requests. + +## {{% heading "whatsnext" %}} + +- Read about [PR wrangling](/docs/contribute/participate/pr-wranglers/), a role all approvers take on rotation. diff --git a/content/en/docs/contribute/participate/roles-and-responsibilties.md b/content/en/docs/contribute/participate/roles-and-responsibilties.md deleted file mode 100644 index f4cca67155..0000000000 --- a/content/en/docs/contribute/participate/roles-and-responsibilties.md +++ /dev/null @@ -1,195 +0,0 @@ ---- -title: Roles and responsibilities -content_type: concept -weight: 10 ---- - - - -Anyone can contribute to Kubernetes. As your contributions to SIG Docs grow, you can apply for different levels of membership in the community. -These roles allow you to take on more responsibility within the community. -Each role requires more time and commitment. The roles are: - -- Anyone: regular contributors to the Kubernetes documentation -- Members: can assign and triage issues and provide non-binding review on pull requests -- Reviewers: can lead reviews on documentation pull requests and can vouch for a change's quality -- Approvers: can lead reviews on documentation and merge changes - - - -## Anyone - -Anyone with a GitHub account can contribute to Kubernetes. SIG Docs welcomes all new contributors! - -Anyone can: - -- Open an issue in any [Kubernetes](https://github.com/kubernetes/) repository, including [`kubernetes/website`](https://github.com/kubernetes/website) -- Give non-binding feedback on a pull request -- Contribute to a localization -- Suggest improvements on [Slack](http://slack.k8s.io/) or the [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). - -After [signing the CLA](/docs/contribute/new-content/overview/#sign-the-cla), anyone can also: - -- Open a pull request to improve existing content, add new content, or write a blog post or case study -- Create diagrams, graphics assets, and embeddable screencasts and videos - -For more information, see [contributing new content](/docs/contribute/new-content/). - -## Members - -A member is someone who has submitted multiple pull requests to `kubernetes/website`. Members are a part of the [Kubernetes GitHub organization](https://github.com/kubernetes). - -Members can: - -- Do everything listed under [Anyone](#anyone) -- Use the `/lgtm` comment to add the LGTM (looks good to me) label to a pull request - - {{< note >}} - Using `/lgtm` triggers automation. If you want to provide non-binding approval, simply commenting "LGTM" works too! - {{< /note >}} -- Use the `/hold` comment to block merging for a pull request -- Use the `/assign` comment to assign a reviewer to a pull request -- Provide non-binding review on pull requests -- Use automation to triage and categorize issues -- Document new features - -### Becoming a member - -After submitting at least 5 substantial pull requests and meeting the other [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#member): - -1. Find two [reviewers](#reviewers) or [approvers](#approvers) to [sponsor](/docs/contribute/advanced#sponsor-a-new-contributor) your membership. - - Ask for sponsorship in the [#sig-docs channel on Slack](https://kubernetes.slack.com) or on the - [SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). - - {{< note >}} - Don't send a direct email or Slack direct message to an individual - SIG Docs member. You must request sponsorship before submitting your application. - {{< /note >}} - -2. Open a GitHub issue in the [`kubernetes/org`](https://github.com/kubernetes/org/) repository. Use the **Organization Membership Request** issue template. - -3. Let your sponsors know about the GitHub issue. You can either: - - Mention their GitHub username in an issue (`@`) - - Send them the issue link using Slack or email. - - Sponsors will approve your request with a `+1` vote. Once your sponsors approve the request, a Kubernetes GitHub admin adds you as a member. Congratulations! - - If your membership request is not accepted you will receive feedback. After addressing the feedback, apply again. - -4. Accept the invitation to the Kubernetes GitHub organization in your email account. - - {{< note >}} - GitHub sends the invitation to the default email address in your account. - {{< /note >}} - -## Reviewers - -Reviewers are responsible for reviewing open pull requests. Unlike member feedback, you must address reviewer feedback. Reviewers are members of the [@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs) GitHub team. - -Reviewers can: - -- Do everything listed under [Anyone](#anyone) and [Members](#members) -- Review pull requests and provide binding feedback - - {{< note >}} - To provide non-binding feedback, prefix your comments with a phrase like "Optionally: ". - {{< /note >}} - -- Edit user-facing strings in code -- Improve code comments - -You can be a SIG Docs reviewer, or a reviewer for docs in a specific subject area. - -### Assigning reviewers to pull requests - -Automation assigns reviewers to all pull requests. You can request a -review from a specific person by commenting: `/assign -[@_github_handle]`. - -If the assigned reviewer has not commented on the PR, another reviewer can step in. You can also assign technical reviewers as needed. - -### Using `/lgtm` - -LGTM stands for "Looks good to me" and indicates that a pull request is technically accurate and ready to merge. All PRs need a `/lgtm` comment from a reviewer and a `/approve` comment from an approver to merge. - -A `/lgtm` comment from reviewer is binding and triggers automation that adds the `lgtm` label. - -### Becoming a reviewer - -When you meet the -[requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer), you can become a SIG Docs reviewer. Reviewers in other SIGs must apply separately for reviewer status in SIG Docs. - -To apply: - -1. Open a pull request that adds your GitHub user name to a section of the -[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file -in the `kubernetes/website` repository. - - {{< note >}} - If you aren't sure where to add yourself, add yourself to `sig-docs-en-reviews`. - {{< /note >}} - -2. Assign the PR to one or more SIG-Docs approvers (user names listed under `sig-docs-{language}-owners`). - -If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests. - -## Approvers - -Approvers review and approve pull requests for merging. Approvers are members of the -[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs) GitHub teams. - -Approvers can do the following: - -- Everything listed under [Anyone](#anyone), [Members](#members) and [Reviewers](#reviewers) -- Publish contributor content by approving and merging pull requests using the `/approve` comment -- Propose improvements to the style guide -- Propose improvements to docs tests -- Propose improvements to the Kubernetes website or other tooling - -If the PR already has a `/lgtm`, or if the approver also comments with `/lgtm`, the PR merges automatically. A SIG Docs approver should only leave a `/lgtm` on a change that doesn't need additional technical review. - - -### Approving pull requests - -Approvers and SIG Docs leads are the only ones who can merge pull requests into the website repository. This comes with certain responsibilities. - -- Approvers can use the `/approve` command, which merges PRs into the repo. - - {{< warning >}} - A careless merge can break the site, so be sure that when you merge something, you mean it. - {{< /warning >}} - -- Make sure that proposed changes meet the [contribution guidelines](/docs/contribute/style/content-guide/#contributing-content). - - If you ever have a question, or you're not sure about something, feel free to call for additional review. - -- Verify that Netlify tests pass before you `/approve` a PR. - - Netlify tests must pass before approving - -- Visit the Netlify page preview for a PR to make sure things look good before approving. - -- Participate in the [PR Wrangler rotation schedule](https://github.com/kubernetes/website/wiki/PR-Wranglers) for weekly rotations. SIG Docs expects all approvers to participate in this -rotation. See [PR wranglers](/docs/contribute/participating/pr-wranglers/). -for more details. - -### Becoming an approver - -When you meet the [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#approver), you can become a SIG Docs approver. Approvers in other SIGs must apply separately for approver status in SIG Docs. - -To apply: - -1. Open a pull request adding yourself to a section of the [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file in the `kubernetes/website` repository. - - {{< note >}} - If you aren't sure where to add yourself, add yourself to `sig-docs-en-owners`. - {{< /note >}} - -2. Assign the PR to one or more current SIG Docs approvers. - -If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests. - -## {{% heading "whatsnext" %}} - -- Read about [PR wrangling](/docs/contribute/participating/pr-wranglers), a role all approvers take on rotation. \ No newline at end of file diff --git a/content/en/docs/contribute/review/for-approvers.md b/content/en/docs/contribute/review/for-approvers.md index 0cddbcba6a..82a05bdb86 100644 --- a/content/en/docs/contribute/review/for-approvers.md +++ b/content/en/docs/contribute/review/for-approvers.md @@ -8,7 +8,9 @@ weight: 20 -SIG Docs [Reviewers](/docs/contribute/participating/#reviewers) and [Approvers](/docs/contribute/participating/#approvers) do a few extra things when reviewing a change. +SIG Docs [Reviewers](/docs/contribute/participate/#reviewers) and +[Approvers](/docs/contribute/participate/#approvers) do a few extra things +when reviewing a change. Every week a specific docs approver volunteers to triage and review pull requests. This @@ -19,9 +21,6 @@ requests (PRs) that are not already under active review. In addition to the rotation, a bot assigns reviewers and approvers for the PR based on the owners for the affected files. - - - ## Reviewing a PR @@ -202,9 +201,9 @@ Sample response to a request for support: This issue sounds more like a request for support and less like an issue specifically for docs. I encourage you to bring your question to the `#kubernetes-users` channel in -[Kubernetes slack](http://slack.k8s.io/). You can also search +[Kubernetes slack](https://slack.k8s.io/). You can also search resources like -[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) +[Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) for answers to similar questions. You can also open issues for Kubernetes functionality in diff --git a/content/en/docs/contribute/review/reviewing-prs.md b/content/en/docs/contribute/review/reviewing-prs.md index 3c271aa44f..ff6ef9d709 100644 --- a/content/en/docs/contribute/review/reviewing-prs.md +++ b/content/en/docs/contribute/review/reviewing-prs.md @@ -16,10 +16,10 @@ It helps you learn the code base and build trust with other contributors. Before reviewing, it's a good idea to: - Read the [content guide](/docs/contribute/style/content-guide/) and -[style guide](/docs/contribute/style/style-guide/) so you can leave informed comments. -- Understand the different [roles and responsibilities](/docs/contribute/participating/#roles-and-responsibilities) in the Kubernetes documentation community. - - + [style guide](/docs/contribute/style/style-guide/) so you can leave informed comments. +- Understand the different + [roles and responsibilities](/docs/contribute/participate/roles-and-responsibilities/) + in the Kubernetes documentation community. diff --git a/content/en/docs/contribute/style/content-guide.md b/content/en/docs/contribute/style/content-guide.md index 569ca8d72c..0de4a381a3 100644 --- a/content/en/docs/contribute/style/content-guide.md +++ b/content/en/docs/contribute/style/content-guide.md @@ -10,9 +10,9 @@ weight: 10 This page contains guidelines for Kubernetes documentation. If you have questions about what's allowed, join the #sig-docs channel in -[Kubernetes Slack](http://slack.k8s.io/) and ask! +[Kubernetes Slack](https://slack.k8s.io/) and ask! -You can register for Kubernetes Slack at http://slack.k8s.io/. +You can register for Kubernetes Slack at https://slack.k8s.io/. For information on creating new content for the Kubernetes docs, follow the [style guide](/docs/contribute/style/style-guide). @@ -67,7 +67,7 @@ ask for help in [#sig-docs on Kubernetes Slack](https://kubernetes.slack.com/mes ### More information -If you have questions about allowed content, join the [Kubernetes Slack](http://slack.k8s.io/) #sig-docs channel and ask! +If you have questions about allowed content, join the [Kubernetes Slack](https://slack.k8s.io/) #sig-docs channel and ask! diff --git a/content/en/docs/contribute/style/hugo-shortcodes/index.md b/content/en/docs/contribute/style/hugo-shortcodes/index.md index e4a6d703ad..ab949be7fc 100644 --- a/content/en/docs/contribute/style/hugo-shortcodes/index.md +++ b/content/en/docs/contribute/style/hugo-shortcodes/index.md @@ -232,7 +232,7 @@ Renders to: {{< tabs name="tab_with_file_include" >}} {{< tab name="Content File #1" include="example1" />}} {{< tab name="Content File #2" include="example2" />}} -{{< tab name="JSON File" include="podtemplate" />}} +{{< tab name="JSON File" include="podtemplate.json" />}} {{< /tabs >}} @@ -242,6 +242,6 @@ Renders to: * Learn about [Hugo](https://gohugo.io/). * Learn about [writing a new topic](/docs/contribute/style/write-new-topic/). * Learn about [page content types](/docs/contribute/style/page-content-types/). -* Learn about [creating a pull request](/docs/contribute/new-content/new-content/). +* Learn about [opening a pull request](/docs/contribute/new-content/open-a-pr/). * Learn about [advanced contributing](/docs/contribute/advanced/). diff --git a/content/en/docs/contribute/style/page-content-types.md b/content/en/docs/contribute/style/page-content-types.md index 2a3325d397..5d3b519bc0 100644 --- a/content/en/docs/contribute/style/page-content-types.md +++ b/content/en/docs/contribute/style/page-content-types.md @@ -191,7 +191,7 @@ Within each section, write your content. Use the following guidelines: interested in reading next. An example of a published tutorial topic is -[Running a Stateless Application Using a Deployment](/docs/tutorials/stateless-application/run-stateless-application-deployment/). +[Running a Stateless Application Using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/). ### Reference diff --git a/content/en/docs/contribute/style/style-guide.md b/content/en/docs/contribute/style/style-guide.md index 55aa30d66c..44653708ec 100644 --- a/content/en/docs/contribute/style/style-guide.md +++ b/content/en/docs/contribute/style/style-guide.md @@ -22,8 +22,11 @@ discussion. {{< note >}} -Kubernetes documentation uses [Blackfriday Markdown Renderer](https://github.com/russross/blackfriday) along with a few [Hugo Shortcodes](/docs/home/contribute/includes/) to support glossary entries, tabs, -and representing feature state. +Kubernetes documentation uses +[Goldmark Markdown Renderer](https://github.com/yuin/goldmark) +with some adjustments along with a few +[Hugo Shortcodes](/docs/contribute/style/hugo-shortcodes/) to support +glossary entries, tabs, and representing feature state. {{< /note >}} ## Language @@ -584,12 +587,8 @@ The Federation feature provides ... | The new Federation feature provides ... {{< /table >}} - - ## {{% heading "whatsnext" %}} - * Learn about [writing a new topic](/docs/contribute/style/write-new-topic/). * Learn about [using page templates](/docs/contribute/style/page-content-types/). -* Learn about [staging your changes](/docs/contribute/stage-documentation-changes/) * Learn about [creating a pull request](/docs/contribute/new-content/open-a-pr/). diff --git a/content/en/docs/contribute/style/write-new-topic.md b/content/en/docs/contribute/style/write-new-topic.md index 3e4f999c08..7cac1aa6b7 100644 --- a/content/en/docs/contribute/style/write-new-topic.md +++ b/content/en/docs/contribute/style/write-new-topic.md @@ -11,7 +11,7 @@ This page shows how to create a new topic for the Kubernetes docs. ## {{% heading "prerequisites" %}} Create a fork of the Kubernetes documentation repository as described in -[Open a PR](/docs/new-content/open-a-pr/). +[Open a PR](/docs/contribute/new-content/open-a-pr/). @@ -160,7 +160,7 @@ submitted to ensure all examples pass the tests. {{< /note >}} For an example of a topic that uses this technique, see -[Running a Single-Instance Stateful Application](/docs/tutorials/stateful-application/run-stateful-application/). +[Running a Single-Instance Stateful Application](/docs/tasks/run-application/run-single-instance-stateful-application/). ## Adding images to a topic From c4add100ffd74508886312f7170c1c2f0cba9845 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Mon, 20 Jul 2020 16:17:37 +0800 Subject: [PATCH 18/86] Replace redirected links with the real targets For some links that are invalid forever, this PR drops them. --- .../setup/best-practices/cluster-large.md | 25 +++++++++---------- .../setup/best-practices/multiple-zones.md | 2 +- .../setup/learning-environment/minikube.md | 4 +-- .../on-premises-vm/cloudstack.md | 7 +----- .../production-environment/tools/kops.md | 5 ++-- .../tools/kubeadm/create-cluster-kubeadm.md | 6 ++--- .../tools/kubeadm/high-availability.md | 6 +---- .../tools/kubeadm/self-hosting.md | 4 +-- .../tools/kubeadm/troubleshooting-kubeadm.md | 5 ++-- .../production-environment/tools/kubespray.md | 15 +++++------ .../production-environment/turnkey/aws.md | 14 ++++------- .../production-environment/turnkey/gce.md | 18 +++++-------- .../docs/setup/release/version-skew-policy.md | 2 +- 13 files changed, 43 insertions(+), 70 deletions(-) diff --git a/content/en/docs/setup/best-practices/cluster-large.md b/content/en/docs/setup/best-practices/cluster-large.md index c8692c8872..2b8f7b487f 100644 --- a/content/en/docs/setup/best-practices/cluster-large.md +++ b/content/en/docs/setup/best-practices/cluster-large.md @@ -20,7 +20,7 @@ At {{< param "version" >}}, Kubernetes supports clusters with up to 5000 nodes. A cluster is a set of nodes (physical or virtual machines) running Kubernetes agents, managed by a "master" (the cluster-level control plane). -Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)). +Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)). Simply changing that value to something very large, however, may cause the setup script to fail for many cloud providers. A GCE deployment, for example, will run in to quota issues and fail to bring the cluster up. @@ -80,7 +80,7 @@ On AWS, master node sizes are currently set at cluster startup time and do not c ### Addon Resources -To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](http://pr.k8s.io/10653/files) and [#10778](http://pr.k8s.io/10778/files)). +To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](https://pr.k8s.io/10653/files) and [#10778](https://pr.k8s.io/10778/files)). For example: @@ -94,28 +94,26 @@ For example: memory: 200Mi ``` -Except for Heapster, these limits are static and are based on data we collected from addons running on 4-node clusters (see [#10335](http://issue.k8s.io/10335#issuecomment-117861225)). The addons consume a lot more resources when running on large deployment clusters (see [#5880](http://issue.k8s.io/5880#issuecomment-113984085)). So, if a large cluster is deployed without adjusting these values, the addons may continuously get killed because they keep hitting the limits. +Except for Heapster, these limits are static and are based on data we collected from addons running on 4-node clusters (see [#10335](https://issue.k8s.io/10335#issuecomment-117861225)). The addons consume a lot more resources when running on large deployment clusters (see [#5880](http://issue.k8s.io/5880#issuecomment-113984085)). So, if a large cluster is deployed without adjusting these values, the addons may continuously get killed because they keep hitting the limits. To avoid running into cluster addon resource issues, when creating a cluster with many nodes, consider the following: * Scale memory and CPU limits for each of the following addons, if used, as you scale up the size of cluster (there is one replica of each handling the entire cluster so memory and CPU usage tends to grow proportionally with size/load on cluster): - * [InfluxDB and Grafana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml) - * [kubedns, dnsmasq, and sidecar](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in) - * [Kibana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml) + * [InfluxDB and Grafana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml) + * [kubedns, dnsmasq, and sidecar](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in) + * [Kibana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml) * Scale number of replicas for the following addons, if used, along with the size of cluster (there are multiple replicas of each so increasing replicas should help handle increased load, but, since load per replica also increases slightly, also consider increasing CPU/memory limits): - * [elasticsearch](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml) + * [elasticsearch](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml) * Increase memory and CPU limits slightly for each of the following addons, if used, along with the size of cluster (there is one replica per node but CPU/memory usage increases slightly along with cluster load/size as well): - * [FluentD with ElasticSearch Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml) - * [FluentD with GCP Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml) + * [FluentD with ElasticSearch Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml) + * [FluentD with GCP Plugin](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml) Heapster's resource limits are set dynamically based on the initial size of your cluster (see [#16185](http://issue.k8s.io/16185) and [#22940](http://issue.k8s.io/22940)). If you find that Heapster is running out of resources, you should adjust the formulas that compute heapster memory request (see those PRs for details). -For directions on how to detect if addon containers are hitting resource limits, see the [Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-compute-resources-container/#troubleshooting). - -In the [future](http://issue.k8s.io/13048), we anticipate to set all cluster addon resource limits based on cluster size, and to dynamically adjust them if you grow or shrink your cluster. -We welcome PRs that implement those features. +For directions on how to detect if addon containers are hitting resource limits, see the +[Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-resources-containers/#troubleshooting). ### Allowing minor node failure at startup @@ -126,3 +124,4 @@ running `kube-up.sh` set the environment variable `ALLOWED_NOTREADY_NODES` to wh with. This will allow `kube-up.sh` to succeed with fewer than `NUM_NODES` coming up. Depending on the reason for the failure, those additional nodes may join later or the cluster may remain at a size of `NUM_NODES - ALLOWED_NOTREADY_NODES`. + diff --git a/content/en/docs/setup/best-practices/multiple-zones.md b/content/en/docs/setup/best-practices/multiple-zones.md index ab61c839a9..7c2622641b 100644 --- a/content/en/docs/setup/best-practices/multiple-zones.md +++ b/content/en/docs/setup/best-practices/multiple-zones.md @@ -78,7 +78,7 @@ federation support). a single master node by default. While services are highly available and can tolerate the loss of a zone, the control plane is located in a single zone. Users that want a highly available control -plane should follow the [high availability](/docs/admin/high-availability) instructions. +plane should follow the [high availability](/docs/setup/production-environment/tools/kubeadm/high-availability/) instructions. ### Volume limitations The following limitations are addressed with [topology-aware volume binding](/docs/concepts/storage/storage-classes/#volume-binding-mode). diff --git a/content/en/docs/setup/learning-environment/minikube.md b/content/en/docs/setup/learning-environment/minikube.md index a794141f2d..009be9adc8 100644 --- a/content/en/docs/setup/learning-environment/minikube.md +++ b/content/en/docs/setup/learning-environment/minikube.md @@ -198,7 +198,7 @@ This brief demo guides you on how to start, use, and delete Minikube locally. Fo The `minikube start` command can be used to start your cluster. This command creates and configures a Virtual Machine that runs a single-node Kubernetes cluster. -This command also configures your [kubectl](/docs/user-guide/kubectl-overview/) installation to communicate with this cluster. +This command also configures your [kubectl](/docs/reference/kubectl/overview/) installation to communicate with this cluster. {{< note >}} If you are behind a web proxy, you need to pass this information to the `minikube start` command: @@ -514,6 +514,6 @@ For more information about Minikube, see the [proposal](https://git.k8s.io/commu ## Community -Contributions, questions, and comments are all welcomed and encouraged! Minikube developers hang out on [Slack](https://kubernetes.slack.com) in the #minikube channel (get an invitation [here](http://slack.kubernetes.io/)). We also have the [kubernetes-dev Google Groups mailing list](https://groups.google.com/forum/#!forum/kubernetes-dev). If you are posting to the list please prefix your subject with "minikube: ". +Contributions, questions, and comments are all welcomed and encouraged! Minikube developers hang out on [Slack](https://kubernetes.slack.com) in the `#minikube` channel (get an invitation [here](https://slack.kubernetes.io/)). We also have the [kubernetes-dev Google Groups mailing list](https://groups.google.com/forum/#!forum/kubernetes-dev). If you are posting to the list please prefix your subject with "minikube: ". diff --git a/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md b/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md index 1f7d1fd81f..c440f14b31 100644 --- a/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md +++ b/content/en/docs/setup/production-environment/on-premises-vm/cloudstack.md @@ -9,12 +9,10 @@ content_type: concept [CloudStack](https://cloudstack.apache.org/) is a software to build public and private clouds based on hardware virtualization principles (traditional IaaS). To deploy Kubernetes on CloudStack there are several possibilities depending on the Cloud being used and what images are made available. CloudStack also has a vagrant plugin available, hence Vagrant could be used to deploy Kubernetes either using the existing shell provisioner or using new Salt based recipes. -[CoreOS](http://coreos.com) templates for CloudStack are built [nightly](http://stable.release.core-os.net/amd64-usr/current/). CloudStack operators need to [register](http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/templates.html) this template in their cloud before proceeding with these Kubernetes deployment instructions. +[CoreOS](https://coreos.com) templates for CloudStack are built [nightly](https://stable.release.core-os.net/amd64-usr/current/). CloudStack operators need to [register](https://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/templates.html) this template in their cloud before proceeding with these Kubernetes deployment instructions. This guide uses a single [Ansible playbook](https://github.com/apachecloudstack/k8s), which is completely automated and can deploy Kubernetes on a CloudStack based Cloud using CoreOS images. The playbook, creates an ssh key pair, creates a security group and associated rules and finally starts coreOS instances configured via cloud-init. - - ## Prerequisites @@ -112,10 +110,7 @@ e9af8293... role=node ## Support Level - IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level -------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- CloudStack | Ansible | CoreOS | flannel | [docs](/docs/setup/production-environment/on-premises-vm/cloudstack/) | | Community ([@Guiques](https://github.com/ltupin/)) - - diff --git a/content/en/docs/setup/production-environment/tools/kops.md b/content/en/docs/setup/production-environment/tools/kops.md index 7cbeccf7cb..8394c28faf 100644 --- a/content/en/docs/setup/production-environment/tools/kops.md +++ b/content/en/docs/setup/production-environment/tools/kops.md @@ -140,7 +140,7 @@ you choose for organization reasons (e.g. you are allowed to create records unde but not under `example.com`). Let's assume you're using `dev.example.com` as your hosted zone. You create that hosted zone using -the [normal process](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), or +the [normal process](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), or with a command such as `aws route53 create-hosted-zone --name dev.example.com --caller-reference 1`. You must then set up your NS records in the parent domain, so that records in the domain will resolve. Here, @@ -231,9 +231,8 @@ See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to expl ## {{% heading "whatsnext" %}} -* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/). +* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/reference/kubectl/overview/). * Learn more about `kops` [advanced usage](https://kops.sigs.k8s.io/) for tutorials, best practices and advanced configuration options. * Follow `kops` community discussions on Slack: [community discussions](https://github.com/kubernetes/kops#other-ways-to-communicate-with-the-contributors) * Contribute to `kops` by addressing or raising an issue [GitHub Issues](https://github.com/kubernetes/kops/issues) - diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md index aa9245ea65..89cd094162 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md @@ -284,7 +284,7 @@ tracker instead of the kubeadm or kubernetes issue trackers. {{< /note >}} Several external projects provide Kubernetes Pod networks using CNI, some of which also -support [Network Policy](/docs/concepts/services-networking/networkpolicies/). +support [Network Policy](/docs/concepts/services-networking/network-policies/). See the list of available [networking and network policy add-ons](/docs/concepts/cluster-administration/addons/#networking-and-network-policy). @@ -578,9 +578,9 @@ options. * See [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) for details about upgrading your cluster using `kubeadm`. * Learn about advanced `kubeadm` usage in the [kubeadm reference documentation](/docs/reference/setup-tools/kubeadm/kubeadm) -* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/). +* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/reference/kubectl/overview/). * See the [Cluster Networking](/docs/concepts/cluster-administration/networking/) page for a bigger list -of Pod network add-ons. + of Pod network add-ons. * See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to explore other add-ons, including tools for logging, monitoring, network policy, visualization & control of your Kubernetes cluster. diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md index 5584309406..e91e9f7a60 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md @@ -22,7 +22,7 @@ and environment. [This comparison topic](/docs/setup/production-environment/tool If you encounter issues with setting up the HA cluster, please provide us with feedback in the kubeadm [issue tracker](https://github.com/kubernetes/kubeadm/issues/new). -See also [The upgrade documentation](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15). +See also [The upgrade documentation](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/). {{< caution >}} This page does not address running your cluster on a cloud provider. In a cloud @@ -30,8 +30,6 @@ environment, neither approach documented here works with Service objects of type LoadBalancer, or with dynamic PersistentVolumes. {{< /caution >}} - - ## {{% heading "prerequisites" %}} @@ -51,8 +49,6 @@ For the external etcd cluster only, you also need: - Three additional machines for etcd members - - ## First steps for both methods diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md b/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md index 334e2266f2..d860a88bdd 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md @@ -13,14 +13,12 @@ weight: 100 kubeadm allows you to experimentally create a _self-hosted_ Kubernetes control plane. This means that key components such as the API server, controller manager, and scheduler run as [DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/) -configured via the Kubernetes API instead of [static pods](/docs/tasks/administer-cluster/static-pod/) +configured via the Kubernetes API instead of [static pods](/docs/tasks/configure-pod-container/static-pod/) configured in the kubelet via static files. To create a self-hosted cluster see the [kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) command. - - #### Caveats diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md index a4d6d54cc2..696778f974 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md @@ -15,11 +15,10 @@ If your problem is not listed below, please follow the following steps: - Go to [github.com/kubernetes/kubeadm](https://github.com/kubernetes/kubeadm/issues) and search for existing issues. - If no issue exists, please [open one](https://github.com/kubernetes/kubeadm/issues/new) and follow the issue template. -- If you are unsure about how kubeadm works, you can ask on [Slack](http://slack.k8s.io/) in #kubeadm, or open a question on [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Please include +- If you are unsure about how kubeadm works, you can ask on [Slack](https://slack.k8s.io/) in `#kubeadm`, + or open a question on [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Please include relevant tags like `#kubernetes` and `#kubeadm` so folks can help you. - - ## Not possible to join a v1.18 Node to a v1.17 cluster due to missing RBAC diff --git a/content/en/docs/setup/production-environment/tools/kubespray.md b/content/en/docs/setup/production-environment/tools/kubespray.md index 64ad3f4b1a..02d99d926a 100644 --- a/content/en/docs/setup/production-environment/tools/kubespray.md +++ b/content/en/docs/setup/production-environment/tools/kubespray.md @@ -8,7 +8,7 @@ weight: 30 This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Packet (bare metal), Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-sigs/kubespray). -Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides: +Kubespray is a composition of [Ansible](https://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides: * a highly available cluster * composable attributes @@ -21,9 +21,8 @@ Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [in * openSUSE Leap 15 * continuous integration tests -To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/). - - +To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to +[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/). @@ -50,7 +49,7 @@ Kubespray provides the following utilities to help provision your environment: ### (2/5) Compose an inventory file -After you provision your servers, create an [inventory file for Ansible](http://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)". +After you provision your servers, create an [inventory file for Ansible](https://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)". ### (3/5) Plan your cluster deployment @@ -68,7 +67,7 @@ Kubespray provides the ability to customize many aspects of the deployment: * {{< glossary_tooltip term_id="cri-o" >}} * Certificate generation methods -Kubespray customizations can be made to a [variable file](http://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes. +Kubespray customizations can be made to a [variable file](https://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes. ### (4/5) Deploy a Cluster @@ -110,11 +109,9 @@ When running the reset playbook, be sure not to accidentally target your product ## Feedback -* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](http://slack.k8s.io/)) +* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) (You can get your invite [here](https://slack.k8s.io/)) * [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues) - - ## {{% heading "whatsnext" %}} diff --git a/content/en/docs/setup/production-environment/turnkey/aws.md b/content/en/docs/setup/production-environment/turnkey/aws.md index cbfccd7a56..be75623158 100644 --- a/content/en/docs/setup/production-environment/turnkey/aws.md +++ b/content/en/docs/setup/production-environment/turnkey/aws.md @@ -48,7 +48,7 @@ export PATH=/platforms/darwin/amd64:$PATH export PATH=/platforms/linux/amd64:$PATH ``` -An up-to-date documentation page for this tool is available here: [kubectl manual](/docs/user-guide/kubectl/) +An up-to-date documentation page for this tool is available here: [kubectl manual](/docs/reference/kubectl/kubectl/) By default, `kubectl` will use the `kubeconfig` file generated during the cluster startup for authenticating against the API. For more information, please read [kubeconfig files](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) @@ -63,7 +63,8 @@ For more complete applications, please look in the [examples directory](https:// ## Scaling the cluster -Adding and removing nodes through `kubectl` is not supported. You can still scale the amount of nodes manually through adjustments of the 'Desired' and 'Max' properties within the [Auto Scaling Group](http://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html), which was created during the installation. +Adding and removing nodes through `kubectl` is not supported. You can still scale the amount of nodes manually through adjustments of the 'Desired' and 'Max' properties within the +[Auto Scaling Group](https://docs.aws.amazon.com/autoscaling/latest/userguide/as-manual-scaling.html), which was created during the installation. ## Tearing down the cluster @@ -80,13 +81,8 @@ cluster/kube-down.sh IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level -------------------- | ------------ | ------------- | ---------- | --------------------------------------------- | ---------| ---------------------------- AWS | kops | Debian | k8s (VPC) | [docs](https://github.com/kubernetes/kops) | | Community ([@justinsb](https://github.com/justinsb)) -AWS | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/aws) | | Community -AWS | Juju | Ubuntu | flannel, calico, canal | [docs](/docs/getting-started-guides/ubuntu) | 100% | Commercial, Community +AWS | CoreOS | CoreOS | flannel | - | | Community +AWS | Juju | Ubuntu | flannel, calico, canal | - | 100% | Commercial, Community AWS | KubeOne | Ubuntu, CoreOS, CentOS | canal, weavenet | [docs](https://github.com/kubermatic/kubeone) | 100% | Commercial, Community -## Further reading - -Please see the [Kubernetes docs](/docs/) for more details on administering -and using a Kubernetes cluster. - diff --git a/content/en/docs/setup/production-environment/turnkey/gce.md b/content/en/docs/setup/production-environment/turnkey/gce.md index 60c4e690d9..3ea666eb7c 100644 --- a/content/en/docs/setup/production-environment/turnkey/gce.md +++ b/content/en/docs/setup/production-environment/turnkey/gce.md @@ -72,7 +72,7 @@ cluster/kube-up.sh If you want more than one cluster running in your project, want to use a different name, or want a different number of worker nodes, see the `/cluster/gce/config-default.sh` file for more fine-grained configuration before you start up your cluster. If you run into trouble, please see the section on [troubleshooting](/docs/setup/production-environment/turnkey/gce/#troubleshooting), post to the -[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on [Slack](/docs/troubleshooting/#slack). +[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on `#gke` Slack channel. The next few steps will show you: @@ -85,7 +85,7 @@ The next few steps will show you: The cluster startup script will leave you with a running cluster and a `kubernetes` directory on your workstation. -The [kubectl](/docs/user-guide/kubectl/) tool controls the Kubernetes cluster +The [kubectl](/docs/reference/kubectl/kubectl/) tool controls the Kubernetes cluster manager. It lets you inspect your cluster resources, create, delete, and update components, and much more. You will use it to look at your new cluster and bring up example apps. @@ -98,7 +98,7 @@ gcloud components install kubectl {{< note >}} The kubectl version bundled with `gcloud` may be older than the one -downloaded by the get.k8s.io install script. See [Installing kubectl](/docs/tasks/kubectl/install/) +downloaded by the get.k8s.io install script. See [Installing kubectl](/docs/tasks/tools/install-kubectl/) document to see how you can set up the latest `kubectl` on your workstation. {{< /note >}} @@ -112,7 +112,7 @@ Once `kubectl` is in your path, you can use it to look at your cluster. E.g., ru kubectl get --all-namespaces services ``` -should show a set of [services](/docs/user-guide/services) that look something like this: +should show a set of [services](/docs/concepts/services-networking/service/) that look something like this: ```shell NAMESPACE NAME TYPE CLUSTER_IP EXTERNAL_IP PORT(S) AGE @@ -122,7 +122,7 @@ kube-system kube-ui ClusterIP 10.0.0.3 ... ``` -Similarly, you can take a look at the set of [pods](/docs/user-guide/pods) that were created during cluster startup. +Similarly, you can take a look at the set of [pods](/docs/concepts/workloads/pods/pod/) that were created during cluster startup. You can do this via the ```shell @@ -149,7 +149,7 @@ Some of the pods may take a few seconds to start up (during this time they'll sh ### Run some examples -Then, see [a simple nginx example](/docs/user-guide/simple-nginx) to try out your new cluster. +Then, see [a simple nginx example](/docs/tasks/run-application/run-stateless-application-deployment/) to try out your new cluster. For more complete applications, please look in the [examples directory](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/). The [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) is a good "getting started" walkthrough. @@ -221,9 +221,3 @@ IaaS Provider | Config. Mgmt | OS | Networking | Docs GCE | Saltstack | Debian | GCE | [docs](/docs/setup/production-environment/turnkey/gce/) | | Project -## Further reading - -Please see the [Kubernetes docs](/docs/) for more details on administering -and using a Kubernetes cluster. - - diff --git a/content/en/docs/setup/release/version-skew-policy.md b/content/en/docs/setup/release/version-skew-policy.md index 08abfe7bd5..5b189667db 100644 --- a/content/en/docs/setup/release/version-skew-policy.md +++ b/content/en/docs/setup/release/version-skew-policy.md @@ -21,7 +21,7 @@ Specific cluster deployment tools may place additional restrictions on version s ## Supported versions Kubernetes versions are expressed as **x.y.z**, -where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](http://semver.org/) terminology. +where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](https://semver.org/) terminology. For more information, see [Kubernetes Release Versioning](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning). The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). From d13f959fa182f4dafd7df7639087b736c1e91787 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Wed, 15 Jul 2020 17:08:23 +0800 Subject: [PATCH 19/86] Link checker for doc site. Please see the in-file comment for details. --- scripts/linkchecker.py | 425 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 425 insertions(+) create mode 100755 scripts/linkchecker.py diff --git a/scripts/linkchecker.py b/scripts/linkchecker.py new file mode 100755 index 0000000000..71f40ac22b --- /dev/null +++ b/scripts/linkchecker.py @@ -0,0 +1,425 @@ +#!/usr/bin/env python3 +# +# This a link checker for Kubernetes documentation website. +# - We cover the following cases for the language you provide via `-l`, which +# defaults to 'en'. +# - If the language specified is not English (`en`), we check if you are +# actually using the localized links. For example, if you specify `zh` as +# the language, and for link target `/docs/foo/bar`, we check if the English +# version exists AND if the Chinese version exists as well. A checking record +# is produced if the link can use the localized version. +# +# Usage: linkchecker.py -h +# +# Cases handled: +# +# - [foo](#bar) : ignored currently +# + [foo](http://bar) : insecure links to external site +# + [foo](https://k8s.io/website/...) : hardcoded site domain name +# +# + [foo](//docs/bar/...) : where is not 'en' +# + //docs/bar : contains shortcode, so ignore, or +# + //docs/bar : is a image link (ignore currently), or +# + //docs/bar : points to shared (non-localized) page, or +# + //docs/bar.md : exists for current lang, or +# + //docs/bar/_index.md : exists for current lang, or +# + //docs/bar/ : is a redirect entry, or +# + //docs/bar : is something we don't understand, then ERR +# +# + [foo](/docs/bar/...) +# + /docs/bar : contains shortcode, so ignore, or +# + /docs/bar : is a image link (ignore currently), or +# + /docs/bar : points to a shared (non-localized) page, or +# + /docs/bar.md : exists for current lang, or +# + /docs/bar/_index.md : exists for current lang, or +# + /docs/bar : is a redirect entry, or +# + /docs/bar : is something we don't understand +# + +import argparse +import glob +import os +import re +import sys + +# These are the bad links that doesn't hurt, though good to fix +BAD_LINK_TYPES = { + "B01": { + "reason": "Using bad protocol", + "level": "WARNING", + }, + "B02": { + "reason": "Link target is a redirect entry", + "level": "WARNING", + }, + "B03": { + "reason": "Intra-site linkes should use relative path", + "level": "WARNING", + }, +} + +# Constants for colored printing +C_RED = "\033[31m" +C_GREEN = "\033[32m" +C_YELLOW = "\033[33m" +C_GRAY = "\033[90m" +C_CYAN = "\033[36m" +C_END = "\033[0m" + +# Command line arguments shared across functions +ARGS = None +# Global result dictionary keyed by page examined +RESULT = {} +# Cached redirect entries +REDIRECTS = {} + + +def new_record(level, message, target): + """Create new checking record. + + :param level: Record severity level, one of 'INFO', 'WARNING' and 'ERROR' + :param message: Error message string + :param target: The link target in question + :returns: A string representation the checking result, may contain ASCII + coded terminal colors, or None if the record is suppressed. + """ + global ARGS + + # Skip info when verbose + if ARGS.verbose == False and level == "INFO": + return None + + result = None + if ARGS.no_color: + result = target + ": " + message + else: + target = C_GRAY + target + C_END + if level == "INFO": + result = target + ": " + C_GREEN + message + C_END + elif level == "WARNING": + result = target + ": " + C_YELLOW+ message + C_END + else: # default to error + result = target + ": " + C_RED + message + C_END + + return result + + +def dump_result(): + """Dump result to stdout.""" + global RESULT, ARGS + + for path, path_output in RESULT.items(): + norm_path = os.path.normpath(path) + if ARGS.no_color: + print("File: " + norm_path) + else: + print(C_CYAN + "File: " + norm_path + C_END) + for p in path_output: + print(" "*4 + p) + return + + +def strip_comments(content): + """Manual striping of comments from file content. + + Many localized content pages contain original English content in comments. + These comments have to be stripped out before analyzing the links. + Doing this using regular expression is difficult. Even the grep tool is + not suitable for this use case. + + NOTE: We strived to preserve line numbers when producing the resulted + text. This can be useful in future if we want to print out the line + numbers for bad links. + """ + result = [] + in_comment = False + for line in content: + idx1 = line.find("") + if not in_comment: + # only care if new comment started + if idx1 < 0: + result.append(line) + continue + + # single line comment + if idx2 > 0: + result.append(line[:idx1] + line[idx2+4:]) + continue + result.append(line[:idx1]) + in_comment = True + continue + + # already in comment block + if idx2 < 0: # ignore whole line + result.append("") + continue + result.append(line[idx2+4:]) + in_comment = False + + return result + + +def normalize_filename(name, ftype="markdown"): + """Guess the filename based on a link target. + + This function only deals with regular files. + """ + if name.endswith("/"): + name = name[:-1] + if ftype == "markdown": + name += ".md" + else: + name += ".html" + return name + + +def check_file_exists(base, path, ftype="markdown"): + """Check if the target file exists. + + NOTE: We build a normalized path using 'base' and 'path' values. Suppose + the resulted path string is 'foo/bar', we check if 'foo/bar.md' exists, + AND we check if 'foo/bar/_index.md' exists. + + :param base: The base directory to begin with + :param path: The link target which is a relative path string + :returns: A boolean indicating whether the target file exists. + """ + # NOTE: anchor is ignored, can be a todo item + parts = path.split("#") + + fn = normalize_filename(parts[0], ftype=ftype) + target = base + fn + + if os.path.isfile(target): + return True + + dir_name = base + parts[0] + if os.path.isdir(dir_name): + if os.path.isfile(dir_name + "/_index.md"): + return True + if os.path.isfile(dir_name + "/_index.html"): + return True + # /docs/contribute/style/hugo-shortcodes/ has this + if os.path.isfile(dir_name + "/index.md"): + return True + return False + + +def get_redirect(path): + """Check if the path exists in the redirect database. + + NOTE: We do NOT check if the redirect target is there or not. We do an + **exact** matching for redirection entries. + :returns: The redirect target if any, or None if not found. + """ + global REDIRECTS + + def _check_redirect(t): + for key, value in REDIRECTS.items(): + if key == t: # EXACT MATCH + return value + return None + + # NOTE: anchor is ignored, can be a future todo + parts = path.split("#") + target = parts[0] + if not target.endswith("/"): + target += "/" + + new_target = _check_redirect(target) + last_target = new_target + while new_target: + new_target = _check_redirect(new_target) + if new_target is None: + break + last_target = new_target + + return last_target + + +def check_target(page, anchor, target): + """Check a link from anchor to target on provided page. + + :param page: Currently not used. Passed here in case we want to check the + in-page links in the future. + :param anchor: Anchor string from the content page. This is provided to + help handle cases where target is empty. + :param target: The link target string to check + :returns: A checking record (string) if errors found, or None if we can + find the target link. + """ + target = target.strip() + # B01: bad protocol + if target.startswith("http://"): + return new_record("WARNING", "Use HTTPS rather than HTTP", target) + + # full link + if target.startswith("https://"): + # B03: self link, should revise to relative path + if (target.startswith("https://k8s.io/docs") or + target.startswith("https://kubernetes.io/docs")): + return new_record("ERROR", "Should use relative paths", target) + # external link, skip + return new_record("INFO", "External link, skipped", target) + + # in-page link + # TODO: check if the target anchor does exists + if target.startswith("#"): + return new_record("INFO", "In-page link, skipped", target) + + # Link has shortcode + if target.find("{{") > 0: + return new_record("INFO", "Link has shortcode, skipped", target) + + # TODO: check links to examples + if target.startswith("/examples/"): + return new_record("WARNING", "Examples link, skipped", target) + + # it is an embedded image + # TODO: an image might get translated as well + if target.endswith(".png") or target.endswith(".svg"): + return new_record("INFO", "Link to image, skipped", target) + + # link to English or localized page + if (target.startswith("/docs/") or + target.startswith("/" + ARGS.lang + "/docs/")): + + # target is shared reference (kubectl or kubernetes-api? + if (target.find("/docs/reference/generated/kubectl/") >= 0 or + target.find("/docs/reference/generated/kubernetes-api/") >= 0): + if check_file_exists(ROOT + "/static", target, "html"): + return None + return new_record("ERROR", "Missing shared reference", target) + + # target is a markdown (.md) or a "/_index.md"? + if target.startswith("/docs/"): + base = os.path.join(ROOT, "content", "en") + else: + # localized target + base = os.path.join(ROOT, "content") + ok = check_file_exists(base, target) + if ok: + # We do't do additional checks for English site even if it has + # links to a non-English page + if ARGS.lang == "en": + return None + + # If we are already checking localized link, fine + if target.startswith("/" + ARGS.lang + "/docs/"): + return None + + # additional check for localization even if English target exists + base = os.path.join(ROOT, "content", ARGS.lang) + found = check_file_exists(base, target) + if not found: + # Still to be translated + return None + msg = ("Localized page detected, please append '/%s' to the target" + % ARGS.lang) + return new_record("ERROR", "Link not using localized page", target) + + # taget might be a redirect entry + real_target = get_redirect(target) + if real_target: + msg = ("Link using redirect records, should use %s instead" % + real_target) + return new_record("WARNING", msg, target) + return new_record("ERROR", "Missing link for [%s]" % anchor, target) + + msg = "Link may be wrong for the anchor [%s]" % anchor + return new_record("WARNING", msg, target) + + +def validate_links(page): + """Find and validate links on a content page. + + The checking records are consolidated into the global variable RESULT. + """ + try: + with open(page, "r") as f: + data = f.readlines() + except Exception as ex: + print("[Error] failed in reading markdown file: " + str(ex)) + return + + content = "\n".join(strip_comments(data)) + + # Single results: searches for pattern: []() + link_pattern = r"\[([`/\w\s\n]*)\]\(([^\)]*)\)" + regex = re.compile(link_pattern) + + matches = regex.findall(content) + records = [] + for m in matches: + r = check_target(page, m[0], m[1]) + if r: + records.append(r) + if len(records): + RESULT[page] = records + + +def parse_arguments(): + """Argument parser. + + Result is returned and saved into global variable ARGS. + """ + parser = argparse.ArgumentParser(description="Links checker for docs.") + parser.add_argument("-l", dest="lang", default="en", metavar="", + help=("two letter language code, e.g. 'zh'. " + "(default='en')")) + parser.add_argument("-v", dest="verbose", action="store_true", + help="switch on verbose level") + parser.add_argument("-f", dest="filter", default="/docs/**/*.md", + metavar="", + help=("File pattern to scan, e.g. '/docs/foo.md'. " + "(default='/docs/foo/*.md')")) + parser.add_argument("-n", "--no-color", action="store_true", + help="Suppress colored printing.") + + return parser.parse_args() + + +def main(): + """The main entry of the program.""" + global ARGS, ROOT, REDIRECTS + + ARGS = parse_arguments() + print("Language: " + ARGS.lang) + ROOT = os.path.join(os.path.dirname(__file__), '..') + content_dir = os.path.join(ROOT, 'content') + lang_dir = os.path.join(content_dir, ARGS.lang) + + # read redirects data + redirects_fn = os.path.join(ROOT, "static", "_redirects") + try: + with open(redirects_fn, "r") as f: + data = f.readlines() + for item in data: + parts = item.split() + # There are entries without 301 specified + if len(parts) < 2: + continue + entry = parts[0] + # There are some entries not ended with "/" + if entry.endswith("/"): + REDIRECTS[entry] = parts[1] + else: + REDIRECTS[entry + "/"] = parts[1] + + except Exception as ex: + print("[Error] failed in reading redirects file: " + str(ex)) + return + + folders = [f for f in glob.glob(lang_dir + ARGS.filter, recursive=True)] + for page in folders: + validate_links(page) + + dump_result() + + # Done + print("Completed link validation.") + + +if __name__ == '__main__': + sys.exit(main()) From df17b10ec844a866f798923e3dbce0e1e28ace7e Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sat, 16 May 2020 13:24:34 +0800 Subject: [PATCH 20/86] [ZH] Sync kube-controller-manager localization Also fixes the table rendering issue. --- .../kube-controller-manager.md | 1903 ++++++++++------- 1 file changed, 1109 insertions(+), 794 deletions(-) diff --git a/content/zh/docs/reference/command-line-tools-reference/kube-controller-manager.md b/content/zh/docs/reference/command-line-tools-reference/kube-controller-manager.md index 448f0de7ae..cf7ca4a28a 100644 --- a/content/zh/docs/reference/command-line-tools-reference/kube-controller-manager.md +++ b/content/zh/docs/reference/command-line-tools-reference/kube-controller-manager.md @@ -1,18 +1,10 @@ --- title: kube-controller-manager -notitle: true +content_template: templates/tool-reference +weight: 30 --- - -## kube-controller-manager - - - -### 概述 +## {{% heading "synopsis" %}} -Kubernetes 控制器管理器是一个守护进程，嵌入了 Kubernetes 附带的核心控制循环。 在机器人和自动化的应用中，控制回路是一个永不休止的循环，用于调节系统状态。 在 Kubernetes 中，控制器是一个控制循环，它通过 apiserver 监视集群的共享状态，并尝试进行更改以将当前状态转为所需状态。现今，Kubernetes 自带的控制器包括副本控制器，节点控制器，命名空间控制器和serviceaccounts 控制器。 + +Kubernetes 控制器管理器是一个守护进程，内嵌随 Kubernetes 一起发布的核心控制回路。 +在机器人和自动化的应用中，控制回路是一个永不休止的循环，用于调节系统状态。 +在 Kubernetes 中，每个控制器是一个控制回路，通过 API 服务器监视集群的共享状态， +并尝试进行更改以将当前状态转为期望状态。 +目前，Kubernetes 自带的控制器例子包括副本控制器、节点控制器、命名空间控制器和服务账号控制器等。 ``` kube-controller-manager [flags] ``` +## {{% heading "options" %}} + + ++++ + + + + + + -### 选项 - -
--add-dir-header
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--allocate-node-cidrs
Should CIDRs for Pods be allocated and set on the cloud provider.
--alsologtostderr
log to standard error as well as files
--attach-detach-reconcile-sync-period duration     Default: 1m0s
The reconciler sync wait time between volume attach detach. This duration must be larger than one second, and increasing this value from the default may allow for volumes to be mismatched with pods.
--authentication-kubeconfig string
kubeconfig file pointing at the 'core' kubernetes server with enough rights to create tokenaccessreviews.authentication.k8s.io. This is optional. If empty, all token requests are considered to be anonymous and no client CA is looked up in the cluster.
--authentication-skip-lookup
If false, the authentication-kubeconfig will be used to lookup missing authentication configuration from the cluster.
--authentication-token-webhook-cache-ttl duration     Default: 10s
The duration to cache responses from the webhook token authenticator.
--authentication-tolerate-lookup-failure
If true, failures to look up missing authentication configuration from the cluster are not considered fatal. Note that this can result in authentication that treats all requests as anonymous.
--authorization-always-allow-paths stringSlice     Default: [/healthz]
A list of HTTP paths to skip during authorization, i.e. these are authorized without contacting the 'core' kubernetes server.
--authorization-kubeconfig string
kubeconfig file pointing at the 'core' kubernetes server with enough rights to create subjectaccessreviews.authorization.k8s.io. This is optional. If empty, all requests not skipped by authorization are forbidden.
--authorization-webhook-cache-authorized-ttl duration     Default: 10s
The duration to cache 'authorized' responses from the webhook authorizer.
--authorization-webhook-cache-unauthorized-ttl duration     Default: 10s
The duration to cache 'unauthorized' responses from the webhook authorizer.
--azure-container-registry-config string
Path to the file containing Azure container registry configuration information.
--bind-address ip     Default: 0.0.0.0
The IP address on which to listen for the --secure-port port. The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. If blank, all interfaces will be used (0.0.0.0 for all IPv4 interfaces and :: for all IPv6 interfaces).
--cert-dir string
The directory where the TLS certs are located. If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored.
--cidr-allocator-type string     Default: "RangeAllocator"
Type of CIDR allocator to use
--client-ca-file string
If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate.
--cloud-config string
The path to the cloud provider configuration file. Empty string for no configuration file.
--cloud-provider string
The provider for cloud services. Empty string for no provider.
--cluster-cidr string
CIDR Range for Pods in cluster. Requires --allocate-node-cidrs to be true
--cluster-name string     Default: "kubernetes"
The instance prefix for the cluster.
--cluster-signing-cert-file string     Default: "/etc/kubernetes/ca/ca.pem"
Filename containing a PEM-encoded X509 CA certificate used to issue cluster-scoped certificates
--cluster-signing-key-file string     Default: "/etc/kubernetes/ca/ca.key"
Filename containing a PEM-encoded RSA or ECDSA private key used to sign cluster-scoped certificates
--concurrent-deployment-syncs int32     Default: 5
The number of deployment objects that are allowed to sync concurrently. Larger number = more responsive deployments, but more CPU (and network) load
--concurrent-endpoint-syncs int32     Default: 5
The number of endpoint syncing operations that will be done concurrently. Larger number = faster endpoint updating, but more CPU (and network) load
--concurrent-gc-syncs int32     Default: 20
The number of garbage collector workers that are allowed to sync concurrently.
--concurrent-namespace-syncs int32     Default: 10
The number of namespace objects that are allowed to sync concurrently. Larger number = more responsive namespace termination, but more CPU (and network) load
--concurrent-replicaset-syncs int32     Default: 5
The number of replica sets that are allowed to sync concurrently. Larger number = more responsive replica management, but more CPU (and network) load
--concurrent-resource-quota-syncs int32     Default: 5
The number of resource quotas that are allowed to sync concurrently. Larger number = more responsive quota management, but more CPU (and network) load
--concurrent-service-syncs int32     Default: 1
The number of services that are allowed to sync concurrently. Larger number = more responsive service management, but more CPU (and network) load
--concurrent-serviceaccount-token-syncs int32     Default: 5
The number of service account token objects that are allowed to sync concurrently. Larger number = more responsive token generation, but more CPU (and network) load
--concurrent-ttl-after-finished-syncs int32     Default: 5
The number of TTL-after-finished controller workers that are allowed to sync concurrently.
--concurrent_rc_syncs int32     Default: 5
The number of replication controllers that are allowed to sync concurrently. Larger number = more responsive replica management, but more CPU (and network) load
--configure-cloud-routes     Default: true
Should CIDRs allocated by allocate-node-cidrs be configured on the cloud provider.
--contention-profiling
Enable lock contention profiling, if profiling is enabled
--controller-start-interval duration
Interval between starting controller managers.
--controllers stringSlice     Default: [*]
A list of controllers to enable. '*' enables all on-by-default controllers, 'foo' enables the controller named 'foo', '-foo' disables the controller named 'foo'.
All controllers: attachdetach, bootstrapsigner, cloud-node-lifecycle, clusterrole-aggregation, cronjob, csrapproving, csrcleaner, csrsigning, daemonset, deployment, disruption, endpoint, garbagecollector, horizontalpodautoscaling, job, namespace, nodeipam, nodelifecycle, persistentvolume-binder, persistentvolume-expander, podgc, pv-protection, pvc-protection, replicaset, replicationcontroller, resourcequota, root-ca-cert-publisher, route, service, serviceaccount, serviceaccount-token, statefulset, tokencleaner, ttl, ttl-after-finished
Disabled-by-default controllers: bootstrapsigner, tokencleaner
--deployment-controller-sync-period duration     Default: 30s
Period for syncing the deployments.
--disable-attach-detach-reconcile-sync
Disable volume attach detach reconciler sync. Disabling this may cause volumes to be mismatched with pods. Use wisely.
--enable-dynamic-provisioning     Default: true
Enable dynamic provisioning for environments that support it.
--enable-garbage-collector     Default: true
Enables the generic garbage collector. MUST be synced with the corresponding flag of the kube-apiserver.
--enable-hostpath-provisioner
Enable HostPath PV provisioning when running without a cloud provider. This allows testing and development of provisioning features. HostPath provisioning is not supported in any way, won't work in a multi-node cluster, and should not be used for anything other than testing or development.
--enable-taint-manager     Default: true
WARNING: Beta feature. If set to true enables NoExecute Taints and will evict all not-tolerating Pod running on Nodes tainted with this kind of Taints.
--experimental-cluster-signing-duration duration     Default: 8760h0m0s
The length of duration signed certificates will be given.
--external-cloud-volume-plugin string
The plugin to use when cloud provider is set to external. Can be empty, should only be set when cloud-provider is external. Currently used to allow node and volume controllers to work for in tree cloud providers.
--feature-gates mapStringBool
A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:
APIListChunking=true|false (BETA - default=true)
APIResponseCompression=true|false (ALPHA - default=false)
AllAlpha=true|false (ALPHA - default=false)
AppArmor=true|false (BETA - default=true)
AttachVolumeLimit=true|false (BETA - default=true)
BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)
BlockVolume=true|false (BETA - default=true)
BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)
CPUManager=true|false (BETA - default=true)
CRIContainerLogRotation=true|false (BETA - default=true)
CSIBlockVolume=true|false (BETA - default=true)
CSIDriverRegistry=true|false (BETA - default=true)
CSIInlineVolume=true|false (ALPHA - default=false)
CSIMigration=true|false (ALPHA - default=false)
CSIMigrationAWS=true|false (ALPHA - default=false)
CSIMigrationGCE=true|false (ALPHA - default=false)
CSIMigrationOpenStack=true|false (ALPHA - default=false)
CSINodeInfo=true|false (BETA - default=true)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)
CustomResourcePublishOpenAPI=true|false (ALPHA - default=false)
CustomResourceSubresources=true|false (BETA - default=true)
CustomResourceValidation=true|false (BETA - default=true)
CustomResourceWebhookConversion=true|false (ALPHA - default=false)
DebugContainers=true|false (ALPHA - default=false)
DevicePlugins=true|false (BETA - default=true)
DryRun=true|false (BETA - default=true)
DynamicAuditing=true|false (ALPHA - default=false)
DynamicKubeletConfig=true|false (BETA - default=true)
ExpandCSIVolumes=true|false (ALPHA - default=false)
ExpandInUsePersistentVolumes=true|false (ALPHA - default=false)
ExpandPersistentVolumes=true|false (BETA - default=true)
ExperimentalCriticalPodAnnotation=true|false (ALPHA - default=false)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
HyperVContainer=true|false (ALPHA - default=false)
KubeletPodResources=true|false (ALPHA - default=false)
LocalStorageCapacityIsolation=true|false (BETA - default=true)
MountContainers=true|false (ALPHA - default=false)
NodeLease=true|false (BETA - default=true)
PodShareProcessNamespace=true|false (BETA - default=true)
ProcMountType=true|false (ALPHA - default=false)
QOSReserved=true|false (ALPHA - default=false)
ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)
ResourceQuotaScopeSelectors=true|false (BETA - default=true)
RotateKubeletClientCertificate=true|false (BETA - default=true)
RotateKubeletServerCertificate=true|false (BETA - default=true)
RunAsGroup=true|false (BETA - default=true)
RuntimeClass=true|false (BETA - default=true)
SCTPSupport=true|false (ALPHA - default=false)
ScheduleDaemonSetPods=true|false (BETA - default=true)
ServerSideApply=true|false (ALPHA - default=false)
ServiceNodeExclusion=true|false (ALPHA - default=false)
StorageVersionHash=true|false (ALPHA - default=false)
StreamingProxyRedirects=true|false (BETA - default=true)
SupportNodePidsLimit=true|false (ALPHA - default=false)
SupportPodPidsLimit=true|false (BETA - default=true)
Sysctls=true|false (BETA - default=true)
TTLAfterFinished=true|false (ALPHA - default=false)
TaintBasedEvictions=true|false (BETA - default=true)
TaintNodesByCondition=true|false (BETA - default=true)
TokenRequest=true|false (BETA - default=true)
TokenRequestProjection=true|false (BETA - default=true)
ValidateProxyRedirects=true|false (BETA - default=true)
VolumeSnapshotDataSource=true|false (ALPHA - default=false)
VolumeSubpathEnvExpansion=true|false (ALPHA - default=false)
WinDSR=true|false (ALPHA - default=false)
WinOverlay=true|false (ALPHA - default=false)
WindowsGMSA=true|false (ALPHA - default=false)
--flex-volume-plugin-dir string     Default: "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/"
Full path of the directory in which the flex volume plugin should search for additional third party volume plugins.
-h, --help
help for kube-controller-manager
--horizontal-pod-autoscaler-cpu-initialization-period duration     Default: 5m0s
The period after pod start when CPU samples might be skipped.
--horizontal-pod-autoscaler-downscale-stabilization duration     Default: 5m0s
The period for which autoscaler will look backwards and not scale down below any recommendation it made during that period.
--horizontal-pod-autoscaler-initial-readiness-delay duration     Default: 30s
The period after pod start during which readiness changes will be treated as initial readiness.
--horizontal-pod-autoscaler-sync-period duration     Default: 15s
The period for syncing the number of pods in horizontal pod autoscaler.
--horizontal-pod-autoscaler-tolerance float     Default: 0.1
The minimum change (from 1.0) in the desired-to-actual metrics ratio for the horizontal pod autoscaler to consider scaling.
--http2-max-streams-per-connection int
The limit that the server gives to clients for the maximum number of streams in an HTTP/2 connection. Zero means to use golang's default.
--kube-api-burst int32     Default: 30
Burst to use while talking with kubernetes apiserver.
--kube-api-content-type string     Default: "application/vnd.kubernetes.protobuf"
Content type of requests sent to apiserver.
--kube-api-qps float32     Default: 20
QPS to use while talking with kubernetes apiserver.
--kubeconfig string
Path to kubeconfig file with authorization and master location information.
--large-cluster-size-threshold int32     Default: 50
Number of nodes from which NodeController treats the cluster as large for the eviction logic purposes. --secondary-node-eviction-rate is implicitly overridden to 0 for clusters this size or smaller.
--leader-elect     Default: true
Start a leader election client and gain leadership before executing the main loop. Enable this when running replicated components for high availability.
--leader-elect-lease-duration duration     Default: 15s
The duration that non-leader candidates will wait after observing a leadership renewal until attempting to acquire leadership of a led but unrenewed leader slot. This is effectively the maximum duration that a leader can be stopped before it is replaced by another candidate. This is only applicable if leader election is enabled.
--leader-elect-renew-deadline duration     Default: 10s
The interval between attempts by the acting master to renew a leadership slot before it stops leading. This must be less than or equal to the lease duration. This is only applicable if leader election is enabled.
--leader-elect-resource-lock endpoints     Default: "endpoints"
The type of resource object that is used for locking during leader election. Supported options are endpoints (default) and `configmaps`.
--leader-elect-retry-period duration     Default: 2s
The duration the clients should wait between attempting acquisition and renewal of a leadership. This is only applicable if leader election is enabled.
--log-backtrace-at traceLocation     Default: :0
when logging hits line file:N, emit a stack trace
--log-dir string
If non-empty, write log files in this directory
--log-file string
If non-empty, use this log file
--log-flush-frequency duration     Default: 5s
Maximum number of seconds between log flushes
--logtostderr     Default: true
log to standard error instead of files
--master string
The address of the Kubernetes API server (overrides any value in kubeconfig).
--min-resync-period duration     Default: 12h0m0s
The resync period in reflectors will be random between MinResyncPeriod and 2*MinResyncPeriod.
--namespace-sync-period duration     Default: 5m0s
The period for syncing namespace life-cycle updates
--node-cidr-mask-size int32     Default: 24
Mask size for node cidr in cluster.
--node-eviction-rate float32     Default: 0.1
Number of nodes per second on which pods are deleted in case of node failure when a zone is healthy (see --unhealthy-zone-threshold for definition of healthy/unhealthy). Zone refers to entire cluster in non-multizone clusters.
--node-monitor-grace-period duration     Default: 40s
Amount of time which we allow running Node to be unresponsive before marking it unhealthy. Must be N times more than kubelet's nodeStatusUpdateFrequency, where N means number of retries allowed for kubelet to post node status.
--node-monitor-period duration     Default: 5s
The period for syncing NodeStatus in NodeController.
--node-startup-grace-period duration     Default: 1m0s
Amount of time which we allow starting Node to be unresponsive before marking it unhealthy.
--pod-eviction-timeout duration     Default: 5m0s
The grace period for deleting pods on failed nodes.
--profiling
Enable profiling via web interface host:port/debug/pprof/
--pv-recycler-increment-timeout-nfs int32     Default: 30
the increment of time added per Gi to ActiveDeadlineSeconds for an NFS scrubber pod
--pv-recycler-minimum-timeout-hostpath int32     Default: 60
The minimum ActiveDeadlineSeconds to use for a HostPath Recycler pod. This is for development and testing only and will not work in a multi-node cluster.
--pv-recycler-minimum-timeout-nfs int32     Default: 300
The minimum ActiveDeadlineSeconds to use for an NFS Recycler pod
--pv-recycler-pod-template-filepath-hostpath string
The file path to a pod definition used as a template for HostPath persistent volume recycling. This is for development and testing only and will not work in a multi-node cluster.
--pv-recycler-pod-template-filepath-nfs string
The file path to a pod definition used as a template for NFS persistent volume recycling
--pv-recycler-timeout-increment-hostpath int32     Default: 30
the increment of time added per Gi to ActiveDeadlineSeconds for a HostPath scrubber pod. This is for development and testing only and will not work in a multi-node cluster.
--pvclaimbinder-sync-period duration     Default: 15s
The period for syncing persistent volumes and persistent volume claims
--requestheader-allowed-names stringSlice
List of client certificate common names to allow to provide usernames in headers specified by --requestheader-username-headers. If empty, any client certificate validated by the authorities in --requestheader-client-ca-file is allowed.
--requestheader-client-ca-file string
Root certificate bundle to use to verify client certificates on incoming requests before trusting usernames in headers specified by --requestheader-username-headers. WARNING: generally do not depend on authorization being already done for incoming requests.
--requestheader-extra-headers-prefix stringSlice     Default: [x-remote-extra-]
List of request header prefixes to inspect. X-Remote-Extra- is suggested.
--requestheader-group-headers stringSlice     Default: [x-remote-group]
List of request headers to inspect for groups. X-Remote-Group is suggested.
--requestheader-username-headers stringSlice     Default: [x-remote-user]
List of request headers to inspect for usernames. X-Remote-User is common.
--resource-quota-sync-period duration     Default: 5m0s
The period for syncing quota usage status in the system
--root-ca-file string
If set, this root certificate authority will be included in service account's token secret. This must be a valid PEM-encoded CA bundle.
--route-reconciliation-period duration     Default: 10s
The period for reconciling routes created for Nodes by cloud provider.
--secondary-node-eviction-rate float32     Default: 0.01
Number of nodes per second on which pods are deleted in case of node failure when a zone is unhealthy (see --unhealthy-zone-threshold for definition of healthy/unhealthy). Zone refers to entire cluster in non-multizone clusters. This value is implicitly overridden to 0 if the cluster size is smaller than --large-cluster-size-threshold.
--secure-port int     Default: 10257
The port on which to serve HTTPS with authentication and authorization.If 0, don't serve HTTPS at all.
--service-account-private-key-file string
Filename containing a PEM-encoded private RSA or ECDSA key used to sign service account tokens.
--service-cluster-ip-range string
CIDR Range for Services in cluster. Requires --allocate-node-cidrs to be true
--skip-headers
If true, avoid header prefixes in the log messages
--stderrthreshold severity     Default: 2
logs at or above this threshold go to stderr
--terminated-pod-gc-threshold int32     Default: 12500
Number of terminated pods that can exist before the terminated pod garbage collector starts deleting terminated pods. If <= 0, the terminated pod garbage collector is disabled.
--tls-cert-file string
File containing the default x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert). If HTTPS serving is enabled, and --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to the directory specified by --cert-dir.
--tls-cipher-suites stringSlice
Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be use. Possible values: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_RC4_128_SHA
--tls-min-version string
Minimum TLS version supported. Possible values: VersionTLS10, VersionTLS11, VersionTLS12
--tls-private-key-file string
File containing the default x509 private key matching --tls-cert-file.
--tls-sni-cert-key namedCertKey     Default: []
A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com".
--unhealthy-zone-threshold float32     Default: 0.55
Fraction of Nodes in a zone which needs to be not Ready (minimum 3) for zone to be treated as unhealthy.
--use-service-account-credentials
If true, use individual service account credentials for each controller.
-v, --v Level
number for the log level verbosity
--version version[=true]
Print version information and quit
--vmodule moduleSpec
comma-separated list of pattern=N settings for file-filtered logging
若为 true，将文件目录添加到头部。
--allocate-node-cidrs
基于云供应商特性来为 Pod 分配和设置子网掩码。
--alsologtostderr
在向文件输出日志的同时，也将日志写到标准输出。
--attach-detach-reconcile-sync-period duration     默认值：1m0s
协调器（reconciler）在相邻两次对存储卷进行挂载和解除挂载操作之间的等待时间。此时长必须长于 1 秒钟。此值设置为大于默认值时，可能导致存储卷无法与 Pods 匹配。
--authentication-kubeconfig string
kubeconfig 文件的路径名。该文件中包含与某 Kubernetes “核心” 服务器相关的信息，并支持足够的权限以创建 tokenreviews.authentication.k8s.io。此选项是可选的。如果设置为空值，所有令牌请求都会被认作匿名请求，Kubernetes 也不再在集群中查找客户端的 CA 证书信息。
--authentication-skip-lookup
此值为 false 时，通过 authentication-kubeconfig 参数所指定的文件会被用来检索集群中缺失的身份认证配置信息。
--authentication-token-webhook-cache-ttl duration     默认值：10s
对 Webhook 令牌认证设施返回结果的缓存时长。
--authentication-tolerate-lookup-failure
此值 true 时，即使无法从集群中检索到缺失的身份认证配置信息也无大碍。需要注意的是，这样设置可能导致所有请求都被视作匿名请求。
--authorization-always-allow-paths stringSlice     默认值：[/healthz]
鉴权过程中会忽略的一个 HTTP 路径列表。换言之，控制器管理器会对列表中路径的访问进行授权，并且无须征得 Kubernetes “核心” 服务器同意。
--authorization-kubeconfig string
包含 Kubernetes “核心” 服务器信息的 kubeconfig 文件路径，所包含信息具有创建 subjectaccessreviews.authorization.k8s.io 的足够权限。此参数是可选的。如果配置为空字符串，未被鉴权模块所忽略的请求都会被禁止。
--authorization-webhook-cache-authorized-ttl duration     默认值：10s
对 Webhook 形式鉴权组件所返回的“已授权（Authorized）”响应的缓存时长。
--authorization-webhook-cache-unauthorized-ttl duration     默认值：10s
对 Webhook 形式鉴权组件所返回的“未授权（Unauthorized）”响应的缓存时长。
--azure-container-registry-config string
指向包含 Azure 容器仓库配置信息的文件的路径名。
--bind-address ip     默认值：0.0.0.0
针对 --secure-port 端口上请求执行监听操作的 IP 地址。所对应的网络接口必须从集群中其它位置可访问（含命令行及 Web 客户端）。如果此值为空或者设定为非特定地址（0.0.0.0 或 ::），意味着所有网络接口都在监听范围。
--cert-dir string
TLS 证书所在的目录。如果提供了 --tls-cert-file 和 --tls-private-key-file，此标志会被忽略。
--cidr-allocator-type string     默认值："RangeAllocator"
要使用的 CIDR 分配器类型。
--client-ca-file string
如果设置了此标志，对于所有能够提供客户端证书的请求，若该证书由 client-ca-file 中所给机构之一签署，则该请求会被成功认证为客户端证书中 CommonName 所给的实体。
--cloud-config string
云驱动程序配置文件的路径。空字符串表示没有配置文件。
--cloud-provider string
云服务的提供者。空字符串表示没有对应的提供者（驱动）。
--cluster-cidr string
集群中 Pods 的 CIDR 范围。要求 --allocate-node-cidrs 标志为 true。
--cluster-name string     默认值："kubernetes"
集群实例的前缀。
--cluster-signing-cert-file string     默认值："/etc/kubernetes/ca/ca.pem"
包含 PEM 编码格式的 X509 CA 证书的文件名。该证书用来发放集群范围的证书。
--cluster-signing-key-file string     默认值："/etc/kubernetes/ca/ca.key"
包含 PEM 编码的 RSA 或 ECDSA 私钥的文件名。该私钥用来对集群范围证书签名。
--concurrent-deployment-syncs int32     默认值：5
可以并发同步的 Deployment 对象个数。数值越大意味着对 Deployment 的响应越及时，同时也意味着更大的 CPU（和网络带宽）压力。
--concurrent-endpoint-syncs int32     默认值：5
可以并发执行的 Endpoints 同步操作个数。数值越大意味着更快的 Endpoints 更新操作，同时也意味着更大的 CPU （和网络）压力。
--concurrent-gc-syncs int32     默认值：20
可以并发同步的垃圾收集工作线程个数。
--concurrent-namespace-syncs int32     默认值：10
可以并发同步的 Namespace 对象个数。较大的数值意味着更快的名字空间终结操作，不过也意味着更多的 CPU （和网络）占用。
--concurrent-replicaset-syncs int32     默认值：5
可以并发同步的 ReplicaSet 个数。数值越大意味着副本管理的响应速度越快，同时也意味着更多的 CPU （和网络）占用。
--concurrent-resource-quota-syncs int32     默认值：5
可以并发同步的 ResourceQuota 对象个数。数值越大，配额管理的响应速度越快，不过对 CPU （和网络）的占用也越高。
--concurrent-service-endpoint-syncs int32     默认值：5
可以并发执行的服务端点同步操作个数。数值越大，端点片段（Endpoint Slice）的更新速度越快，不过对 CPU （和网络）的占用也越高。默认值为 5。
--concurrent-service-syncs int32     默认值：1
可以并发同步的 Service 对象个数。数值越大，服务管理的响应速度越快，不过对 CPU （和网络）的占用也越高。
--concurrent-serviceaccount-token-syncs int32     默认值：5
可以并发同步的服务账号令牌对象个数。数值越大，令牌生成的速度越快，不过对 CPU （和网络）的占用也越高。
--concurrent-statefulset-syncs int32     默认值：5
可以并发同步的 StatefulSet 对象个数。数值越大，StatefulSet 管理的响应速度越快，不过对 CPU （和网络）的占用也越高。
--concurrent-ttl-after-finished-syncs int32     默认值：5
可以并行同步的 TTL-after-finished 控制器线程个数。
--concurrent_rc_syncs int32     默认值：5
可以并发同步的 ReplicationController 对象个数。数值越大，副本管理的响应速度越快，不过对 CPU （和网络）的占用也越高。
--configure-cloud-routes     默认值：true
决定是否由 --allocate-node-cidrs 所分配的 CIDR 要通过云驱动程序来配置。
--contention-profiling
在启用了性能分析（profiling）时，也启用锁竞争情况分析。
--controller-start-interval duration
在两次启动控制器管理器之间的时间间隔。
--controllers stringSlice     默认值：[*]
要启用的控制器列表。* 表示启用所有默认启用的控制器；foo 启用名为 foo 的控制器；-foo 表示禁用名为 foo 的控制器。
+控制器的全集：attachdetach、bootstrapsigner、cloud-node-lifecycle、clusterrole-aggregation、cronjob、csrapproving、csrcleaner、csrsigning、daemonset、deployment、disruption、endpoint、endpointslice、garbagecollector、horizontalpodautoscaling、job、namespace、nodeipam、nodelifecycle、persistentvolume-binder、persistentvolume-expander、podgc、pv-protection、pvc-protection、replicaset、replicationcontroller、resourcequota、root-ca-cert-publisher、route、service、serviceaccount、serviceaccount-token、statefulset、tokencleaner、ttl、ttl-after-finished
+默认禁用的控制器有：bootstrapsigner 和 tokencleaner。
--deployment-controller-sync-period duration     默认值：30s
Deployment 资源的同步周期。
--disable-attach-detach-reconcile-sync
禁用卷挂接/解挂调节器的同步。禁用此同步可能导致卷存储与 Pod 之间出现错位。请小心使用。
--enable-dynamic-provisioning     默认值：true
在环境允许的情况下启用动态卷供应。
--enable-garbage-collector     默认值：true
启用通用垃圾收集器。必须与 kube-apiserver 中对应的标志一致。
--enable-hostpath-provisioner
在没有云驱动程序的情况下，启用 HostPath 持久卷的供应。此参数便于对卷供应功能进行开发和测试。 HostPath 卷供应并非受支持的功能特性，在多节点的集群中也无法工作，因此除了开发和测试环境中不应使用。
--enable-taint-manager     默认值：true
警告：Beta 阶段特性。设置为 true 时会启用 NoExecute 污点，并在所有标记了此污点的节点上逐出所有无法忍受该污点的 Pods。
--endpoint-updates-batch-period duration
端点（Endpoint）批量更新周期时长。对 Pods 变更的处理会被延迟，以便将其与即将到来的更新操作合并，从而减少端点更新操作次数。较大的数值意味着端点更新的迟滞时间会增长，也意味着所生成的端点版本个数会变少。
--endpointslice-updates-batch-period duration
端点片段（Endpoint Slice）批量更新周期时长。对 Pods 变更的处理会被延迟，以便将其与即将到来的更新操作合并，从而减少端点更新操作次数。较大的数值意味着端点更新的迟滞时间会增长，也意味着所生成的端点版本个数会变少。
--experimental-cluster-signing-duration duration     默认值：8760h0m0s
所签署的证书的有效期时长。
--external-cloud-volume-plugin string
当云驱动程序设置为 external 时要使用的插件名称。此字符串可以为空。只能在云驱动程序为 external 时设置。目前用来保证节点控制器和卷控制器能够在三种云驱动上正常工作。
--feature-gates mapStringBool
一组 key=value 耦对，用来描述测试性/试验性功能的特性门控（Feature Gate）。可选项有：
APIListChunking=true|false (BETA - default=true)
APIPriorityAndFairness=true|false (ALPHA - default=false)
APIResponseCompression=true|false (BETA - default=true)
AllAlpha=true|false (ALPHA - default=false)
AllBeta=true|false (BETA - default=false)
AllowInsecureBackendProxy=true|false (BETA - default=true)
AnyVolumeDataSource=true|false (ALPHA - default=false)
AppArmor=true|false (BETA - default=true)
BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)
BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)
CPUManager=true|false (BETA - default=true)
CRIContainerLogRotation=true|false (BETA - default=true)
CSIInlineVolume=true|false (BETA - default=true)
CSIMigration=true|false (BETA - default=true)
CSIMigrationAWS=true|false (BETA - default=false)
CSIMigrationAWSComplete=true|false (ALPHA - default=false)
CSIMigrationAzureDisk=true|false (ALPHA - default=false)
CSIMigrationAzureDiskComplete=true|false (ALPHA - default=false)
CSIMigrationAzureFile=true|false (ALPHA - default=false)
CSIMigrationAzureFileComplete=true|false (ALPHA - default=false)
CSIMigrationGCE=true|false (BETA - default=false)
CSIMigrationGCEComplete=true|false (ALPHA - default=false)
CSIMigrationOpenStack=true|false (BETA - default=false)
CSIMigrationOpenStackComplete=true|false (ALPHA - default=false)
ConfigurableFSGroupPolicy=true|false (ALPHA - default=false)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)
DefaultIngressClass=true|false (BETA - default=true)
DevicePlugins=true|false (BETA - default=true)
DryRun=true|false (BETA - default=true)
DynamicAuditing=true|false (ALPHA - default=false)
DynamicKubeletConfig=true|false (BETA - default=true)
EndpointSlice=true|false (BETA - default=true)
EndpointSliceProxying=true|false (ALPHA - default=false)
EphemeralContainers=true|false (ALPHA - default=false)
EvenPodsSpread=true|false (BETA - default=true)
ExpandCSIVolumes=true|false (BETA - default=true)
ExpandInUsePersistentVolumes=true|false (BETA - default=true)
ExpandPersistentVolumes=true|false (BETA - default=true)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
HPAScaleToZero=true|false (ALPHA - default=false)
HugePageStorageMediumSize=true|false (ALPHA - default=false)
HyperVContainer=true|false (ALPHA - default=false)
IPv6DualStack=true|false (ALPHA - default=false)
ImmutableEphemeralVolumes=true|false (ALPHA - default=false)
KubeletPodResources=true|false (BETA - default=true)
LegacyNodeRoleBehavior=true|false (ALPHA - default=true)
LocalStorageCapacityIsolation=true|false (BETA - default=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)
NodeDisruptionExclusion=true|false (ALPHA - default=false)
NonPreemptingPriority=true|false (ALPHA - default=false)
PodDisruptionBudget=true|false (BETA - default=true)
PodOverhead=true|false (BETA - default=true)
ProcMountType=true|false (ALPHA - default=false)
QOSReserved=true|false (ALPHA - default=false)
RemainingItemCount=true|false (BETA - default=true)
RemoveSelfLink=true|false (ALPHA - default=false)
ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)
RotateKubeletClientCertificate=true|false (BETA - default=true)
RotateKubeletServerCertificate=true|false (BETA - default=true)
RunAsGroup=true|false (BETA - default=true)
RuntimeClass=true|false (BETA - default=true)
SCTPSupport=true|false (ALPHA - default=false)
SelectorIndex=true|false (ALPHA - default=false)
ServerSideApply=true|false (BETA - default=true)
ServiceAccountIssuerDiscovery=true|false (ALPHA - default=false)
ServiceAppProtocol=true|false (ALPHA - default=false)
ServiceNodeExclusion=true|false (ALPHA - default=false)
ServiceTopology=true|false (ALPHA - default=false)
StartupProbe=true|false (BETA - default=true)
StorageVersionHash=true|false (BETA - default=true)
SupportNodePidsLimit=true|false (BETA - default=true)
SupportPodPidsLimit=true|false (BETA - default=true)
Sysctls=true|false (BETA - default=true)
TTLAfterFinished=true|false (ALPHA - default=false)
TokenRequest=true|false (BETA - default=true)
TokenRequestProjection=true|false (BETA - default=true)
TopologyManager=true|false (BETA - default=true)
ValidateProxyRedirects=true|false (BETA - default=true)
VolumeSnapshotDataSource=true|false (BETA - default=true)
WinDSR=true|false (ALPHA - default=false)
WinOverlay=true|false (ALPHA - default=false)
--flex-volume-plugin-dir string     默认值："/usr/libexec/kubernetes/kubelet-plugins/volume/exec/"
FlexVolume 插件要搜索第三方卷插件的目录路径。
-h, --help
kube-controller-manager 的帮助信息
--horizontal-pod-autoscaler-cpu-initialization-period duration     默认值：5m0s
Pod 启动之后可以忽略 CPU 采样值的时长。
--horizontal-pod-autoscaler-downscale-stabilization duration     默认值：5m0s
自动扩缩程序的回溯时长。自动扩缩器不会基于在给定的时长内所建议的规模对负载执行规模缩小的操作。
--horizontal-pod-autoscaler-initial-readiness-delay duration     默认值：30s
Pod 启动之后，在此值所给定的时长内，就绪状态的变化都不会作为初始的就绪状态。
--horizontal-pod-autoscaler-sync-period duration     默认值：15s
水平 Pod 扩缩器对 Pods 数目执行同步操作的周期。
--horizontal-pod-autoscaler-tolerance float     默认值：0.1
此值为目标值与实际值的比值与 1.0 的差值。只有超过此标志所设的阈值时，HPA 才会考虑执行缩放操作。
--http2-max-streams-per-connection int
服务器为客户端所设置的 HTTP/2 连接中流式连接个数上限。此值为 0 表示采用 Go 语言库所设置的默认值。
--kube-api-burst int32     默认值：30
与 Kubernetes API 服务器通信时突发峰值请求个数上限。
--kube-api-content-type string     默认值："application/vnd.kubernetes.protobuf"
向 API 服务器发送请求时使用的内容类型（Content-Type）。
--kube-api-qps float32     默认值：20
与 API 服务器通信时每秒请求数（QPS）限制。
--kubeconfig string
指向 kubeconfig 文件的路径。该文件中包含主控节点位置以及鉴权凭据信息。
--large-cluster-size-threshold int32     默认值：50
节点控制器在执行 Pod 逐出操作逻辑时，基于此标志所设置的节点个数阈值来判断所在集群是否为大规模集群。当集群规模小于等于此规模时，--secondary-node-eviction-rate 会被隐式重设为 0。
--leader-elect     默认值：true
在执行主循环之前，启动领导选举（Leader Election）客户端，并尝试获得领导者身份。在运行多副本组件时启用此标志有助于提高可用性。
--leader-elect-lease-duration duration     默认值：15s
对于未获得领导者身份的节点，在探测到领导者身份需要更迭时需要等待此标志所设置的时长，才能尝试去获得曾经是领导者但尚未续约的席位。本质上，这个时长也是现有领导者节点在被其他候选节点替代之前可以停止的最长时长。只有集群启用了领导者选举机制时，此标志才起作用。
--leader-elect-renew-deadline duration     默认值：10s
当前执行领导者角色的节点在被停止履行领导职责之前可多次尝试续约领导者身份；此标志给出相邻两次尝试之间的间歇时长。此值必须小于或等于租期时长（Lease Duration）。仅在集群启用了领导者选举时有效。
--leader-elect-resource-lock endpoints     默认值："endpointsleases"
在领导者选举期间用来执行锁操作的资源对象类型。可选项为 endpointsleases （默认值）和 configmaps。
--leader-elect-resource-name string     默认值："kube-controller-manager"
在领导者选举期间，用来执行锁操作的资源对象名称。
--leader-elect-resource-namespace string     默认值："kube-system"
在领导者选举期间，用来执行锁操作的资源对象的名字空间。
--leader-elect-retry-period duration     默认值：2s
尝试获得领导者身份时，客户端在相邻两次尝试之间要等待的时长。此标志仅在启用了领导者选举的集群中起作用。
--log-backtrace-at traceLocation     默认值：:0
当执行到 file:N 所给的文件和代码行时，日志机制会生成一个调用栈快照。
--log-dir string
此标志为非空字符串时，日志文件会写入到所给的目录中。
--log-file string
此标志为非空字符串时，意味着日志会写入到所给的文件中。
--log-file-max-size uint     默认值：1800
定义日志文件大小的上限。单位是兆字节（MB）。若此值为 0，则不对日志文件尺寸进行约束。
--log-flush-frequency duration     默认值：5s
将内存中日志数据清除到日志文件中时，相邻两次清除操作之间最大间隔秒数。
--logtostderr     默认值：true
将日志写出到标准错误输出（stderr）而不是写入到日志文件。
--master string
Kubernetes API 服务器的地址。此值会覆盖 kubeconfig 文件中所给的地址。
--max-endpoints-per-slice int32     默认值：100
每个 EndpointSlice 中可以添加的端点个数上限。每个片段中端点个数越多，得到的片段个数越少，但是片段的规模会变得更大。默认值为 100。
--min-resync-period duration     默认值：12h0m0s
自省程序的重新同步时隔下限。实际时隔长度会在 min-resync-period 和 2 * min-resync-period 之间。
--namespace-sync-period duration     默认值：5m0s
对名字空间对象进行同步的周期。
--node-cidr-mask-size int32
集群中节点 CIDR 的掩码长度。对 IPv4 而言默认为 24；对 IPv6 而言默认为 64。
--node-cidr-mask-size-ipv4 int32
在双堆栈（同时支持 IPv4 和 IPv6）的集群中，节点 IPV4 CIDR 掩码长度。默认为 24。
--node-cidr-mask-size-ipv6 int32
在双堆栈（同时支持 IPv4 和 IPv6）的集群中，节点 IPv6 CIDR 掩码长度。默认为 64。
--node-eviction-rate float32     默认值：0.1
当某区域变得不健康，节点失效时，每秒钟可以从此标志所设定的节点个数上删除 Pods。请参阅 --unhealthy-zone-threshold 以了解“健康”的判定标准。这里的区域（zone）在集群并不跨多个区域时指的是整个集群。
--node-monitor-grace-period duration     默认值：40s
在将一个 Node 标记为不健康之前允许其无响应的时长上限。必须比 kubelet 的 nodeStatusUpdateFrequency 大 N 倍；这里 N 指的是 kubelet 发送节点状态的重试次数。
--node-monitor-period duration     默认值：5s
节点控制器对节点状态进行同步的重复周期。
--node-startup-grace-period duration     默认值：1m0s
在节点启动期间，节点可以处于无响应状态；但超出此标志所设置的时长仍然无响应则该节点被标记为不健康。
--pod-eviction-timeout duration     默认值：5m0s
在失效的节点上删除 Pods 时为其预留的宽限期。
--profiling     默认值：true
通过位于 host:port/debug/pprof/ 的 Web 接口启用性能分析。
--pv-recycler-increment-timeout-nfs int32     默认值：30
NFS 清洗 Pod 在清洗用过的卷时，根据此标志所设置的秒数，为每清洗 1 GiB 数据增加对应超时时长，作为 activeDeadlineSeconds。
--pv-recycler-minimum-timeout-hostpath int32     默认值：60
对于 HostPath 回收器 Pod，设置其 activeDeadlineSeconds 参数下限。此参数仅用于开发和测试目的，不适合在多节点集群中使用。
--pv-recycler-minimum-timeout-nfs int32     默认值：300
NFS 回收器 Pod 要使用的 activeDeadlineSeconds 参数下限。
--pv-recycler-pod-template-filepath-hostpath string
对 HostPath 持久卷进行回收利用时，用作模版的 Pod 定义文件所在路径。此标志仅用于开发和测试目的，不适合多节点集群中使用。
--pv-recycler-pod-template-filepath-nfs string
对 NFS 卷执行回收利用时，用作模版的 Pod 定义文件所在路径。
--pv-recycler-timeout-increment-hostpath int32     默认值：30
HostPath 清洗器 Pod 在清洗对应类型持久卷时，为每 GiB 数据增加此标志所设置的秒数，作为其 activeDeadlineSeconds 参数。此标志仅用于开发和测试环境，不适合多节点集群环境。
--pvclaimbinder-sync-period duration     默认值：15s
持久卷（PV）和持久卷申领（PVC）对象的同步周期。
--requestheader-allowed-names stringSlice
标志值是客户端证书中的 Common Names 列表。其中所列的名称可以通过 --requestheader-username-headers 所设置的 HTTP 头部来提供用户名。如果此标志值为空表，则被 --requestheader-client-ca-file 中机构所验证过的所有客户端证书都是允许的。
--requestheader-client-ca-file string
根证书包文件名。在信任通过 --requestheader-username-headers 所指定的任何用户名之前，要使用这里的证书来检查请求中的客户证书。警告：一般不要依赖对请求所作的鉴权结果。
--requestheader-extra-headers-prefix stringSlice     默认值：[x-remote-extra-]
要插入的请求头部前缀。建议使用 X-Remote-Exra-。
--requestheader-group-headers stringSlice     默认值：[x-remote-group]
用来检查用户组名的请求头部名称列表。建议使用 X-Remote-Group。
--requestheader-username-headers stringSlice     默认值：[x-remote-user]
用来检查用户名的请求头部名称列表。建议使用 X-Remote-User。
--resource-quota-sync-period duration     默认值：5m0s
对系统中配合用量信息进行同步的周期。
--root-ca-file string
如果此标志非空，则在服务账号的令牌 Secret 中会包含此根证书机构。所指定标志值必须是一个合法的 PEM 编码的 CA 证书包。
--route-reconciliation-period duration     默认值：10s
对云驱动为节点所创建的路由信息进行调解的周期。
--secondary-node-eviction-rate float32     默认值：0.01
当区域不健康，节点失效时，每秒钟从此标志所给的节点个数上删除 Pods。参见 --unhealthy-zone-threshold 以了解“健康与否”的判定标准。在只有一个区域的集群中，区域指的是整个集群。如果集群规模小于 --large-cluster-size-threshold 所设置的节点个数时，此值被隐式地重设为 0。
--secure-port int     默认值：10257
在此端口上提供 HTTPS 身份认证和鉴权操作。若此标志值为0，则不提供 HTTPS 服务。
--service-account-private-key-file string
包含 PEM 编码的 RSA 或 ECDSA 私钥数据的文件名，这些私钥用来对服务账号令牌签名。
--service-cluster-ip-range string
集群中 Service 对象的 CIDR 范围。要求 --allocate-node-cidrs 标志为 true。
--show-hidden-metrics-for-version string
你希望展示隐藏度量值的上一个版本。只有上一个次版本号有意义，其他值都是不允许的。字符串格式为 "<major>.<minor>"。例如："1.16"。此格式的目的是确保你能够有机会注意到下一个版本隐藏了一些额外的度量值，而不是在更新版本中某些度量值被彻底删除时措手不及。
--skip-headers
若此标志为 true，则在日志消息中避免写入头部前缀信息。
--skip-log-headers
若此标志为 true，则在写入日志文件时避免写入头部信息。
--stderrthreshold severity     默认值：2
等于或大于此阈值的日志信息会被写入到标准错误输出（stderr）。
--terminated-pod-gc-threshold int32     默认值：12500
在已终止 Pods 垃圾收集器删除已终止 Pods 之前，可以保留的已删除 Pods 的个数上限。若此值小于等于 0，则相当于禁止垃圾回收已终止的 Pods。
--tls-cert-file string
包含 HTTPS 所用的默认 X509 证书的文件。如果有 CA 证书，会被串接在服务器证书之后。若启用了 HTTPS 服务且 --tls-cert-file 和 --tls-private-key-file 标志未设置，则为节点的公开地址生成自签名的证书和密钥，并保存到 --cert-dir 所给的目录中。
--tls-cipher-suites stringSlice
供服务器使用的加密包的逗号分隔列表。若忽略此标志，则使用 Go 语言默认的加密包。可选值包括：TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_RC4_128_SHA
--tls-min-version string
可支持的最低 TLS 版本。可选值包括：“VersionTLS10”、“VersionTLS11”、“VersionTLS12”、“VersionTLS13”。
--tls-private-key-file string
包含与 --tls-cert-file 对应的默认 X509 私钥的文件。
--tls-sni-cert-key namedCertKey     默认值：[]
X509 证书和私钥文件路径的耦对。作为可选项，可以添加域名模式的列表，其中每个域名模式都是可以带通配片段前缀的全限定域名（FQDN）。域名模式也可以使用 IP 地址字符串，不过只有 API 服务器在所给 IP 地址上对客户端可见时才可以使用 IP 地址。在未提供域名模式时，从证书中提取域名。如果有非通配方式的匹配，则优先于通配方式的匹配；显式的域名模式优先于提取的域名。当存在多个密钥/证书耦对时，可以多次使用 --tls-sni-cert-key 标志。例如：example.crt,example.key 或 foo.crt,foo.key:*.foo.com,foo.com。
--unhealthy-zone-threshold float32     默认值：0.55
仅当给定区域中处于非就绪状态的节点（最少 3 个）的占比高于此值时，才将该区域视为不健康。
--use-service-account-credentials
当此标志为 true 时，为每个控制器单独使用服务账号凭据。
-v, --v Level
日志级别详细程度取值
--version version[=true]
打印版本信息之后退出
--vmodule moduleSpec
由逗号分隔的列表，每一项都是 pattern=N 格式，用来执行根据文件过滤的日志行为。
- From 12d2ae6d9d717b26a831451ea455d35aa8cd7def Mon Sep 17 00:00:00 2001 From: Aris Cahyadi Risdianto Date: Tue, 14 Jul 2020 23:06:40 +0800 Subject: [PATCH 21/86] ID localization for access-application-cluster list-image Addressing several comments. Addressing several comments. --- .../list-all-running-container-images.md | 129 ++++++++++++++++++ 1 file changed, 129 insertions(+) create mode 100644 content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md diff --git a/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md new file mode 100644 index 0000000000..f2140e5276 --- /dev/null +++ b/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -0,0 +1,129 @@ +--- +title: Membuat Daftar Semua Image Container yang Berjalan dalam Klaster +content_type: task +weight: 100 +--- + + + +Laman ini menunjukkan cara menggunakan kubectl untuk membuat daftar semua _image_ Container +untuk Pod yang berjalan dalam sebuah klaster. + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + + +Dalam latihan ini kamu akan menggunakan kubectl untuk mengambil semua Pod yang +berjalan dalam sebuah klaster, dan mengubah format keluarannya untuk melihat daftar +Container untuk masing-masing Pod. + +## Membuat daftar semua _image_ Container pada semua Namespace + +- Silakan ambil semua Pod dalam Namespace dengan menggunakan perintah `kubectl get pods --all-namespaces` +- Silakan format keluarannya agar hanya menyertakan daftar nama _image_ dari Container + dengan menggunakan perintah `-o jsonpath={..image}`. Perintah ini akan mem-_parsing field_ + `image` dari keluaran json yang dihasilkan. + - Silakan lihat [referensi jsonpath](/docs/user-guide/jsonpath/) + untuk informasi lebih lanjut tentang cara menggunakan `jsonpath`. +- Silakan format keluaran dengan menggunakan peralatan standar: `tr`, `sort`, `uniq` + - Gunakan `tr` untuk mengganti spasi dengan garis baru + - Gunakan `sort` untuk menyortir hasil + - Gunakan `uniq` untuk mengumpulkan jumlah _image_ + +```sh +kubectl get pods --all-namespaces -o jsonpath="{..image}" |\ +tr -s '[[:space:]]' '\n' |\ +sort |\ +uniq -c +``` + +Perintah di atas secara berulang akan mengembalikan semua _field_ bernama `image` +dari semua poin yang dikembalikan. + +Sebagai pilihan, dimungkinkan juga untuk menggunakan jalur (_path_) absolut ke _field image_ +di dalam Pod. Hal ini memastikan _field_ yang diambil benar +bahkan ketika nama _field_ tersebut diulangi, +misalnya banyak _field_ disebut dengan `name` dalam sebuah poin yang diberikan: + +```sh +kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" +``` + +`Jsonpath` dapat diartikan sebagai berikut: + +- `.items[*]`: untuk setiap nilai yang dihasilkan +- `.spec`: untuk mendapatkan spesifikasi +- `.containers[*]`: untuk setiap Container +- `.image`: untuk mendapatkan _image_ + +{{< note >}} +Pada saat mengambil sebuah Pod berdasarkan namanya, misalnya `kubectl get pod nginx`, +bagian `.items[*]` dari jalur harus dihilangkan karena hanya akan menghasilkan sebuah Pod +sebagai keluarannya, bukan daftar dari semua Pod. + +{{< /note >}} + +## Membuat daftar _image_ Container berdasarkan Pod + +Format dapat dikontrol lebih lanjut dengan menggunakan operasi `range` untuk +melakukan iterasi untuk setiap elemen secara individual. + +```sh +kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\ +sort +``` + +## Membuat daftar _image_ yang difilter berdasarkan label dari Pod + +Untuk menargetkan hanya Pod yang cocok dengan label tertentu saja, gunakan tanda -l. Filter +dibawah ini akan menghasilkan Pod dengan label yang cocok dengan `app=nginx`. + +```sh +kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx +``` + +## Membuat daftar _image_ Container yang difilter berdasarkan Namespace Pod + +Untuk hanya menargetkan Pod pada Namespace tertentu, gunakankan tanda Namespace. Filter +dibawah ini hanya menyaring Pod pada Namespace `kube-system`. + +```sh +kubectl get pods --namespace kube-system -o jsonpath="{..image}" +``` + +## Membuat daftar _image_ Container dengan menggunakan go-template sebagai alternatif dari jsonpath + +Sebagai alternatif untuk `jsonpath`, kubectl mendukung penggunaan [go-template](https://golang.org/pkg/text/template/) +untuk memformat keluaran seperti berikut: + + +```sh +kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}" +``` + + + + + + + + + +## {{% heading "whatsnext" %}} + + +### Referensi + +* Referensi panduan [Jsonpath](/docs/user-guide/jsonpath/). +* Referensi panduan [Go template](https://golang.org/pkg/text/template/). + + + + From 67d95db8cd744ccd64914ed349f64a5fefad8919 Mon Sep 17 00:00:00 2001 From: "Lubomir I. Ivanov" Date: Mon, 20 Jul 2020 22:41:55 +0300 Subject: [PATCH 22/86] kubeadm: remove the preferred / popular list of CNIs Kubeadm should be CNI agnostic and should not define what is considered a popular CNI plugin and what isn't. - Remove the tabs that list CNIs such as Calico, WeaveNet, etc. - Preserve the note that Calico is currently the only CNI kubeadm e2e tests are run against. - Change the link to enumerate CNIs to: /docs/concepts/cluster-administration/networking/ --- .../tools/kubeadm/create-cluster-kubeadm.md | 87 ++----------------- 1 file changed, 7 insertions(+), 80 deletions(-) diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md index aa9245ea65..b428e6304a 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md @@ -8,7 +8,7 @@ weight: 30 -The `kubeadm` tool helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification). +The `kubeadm` tool helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification). `kubeadm` also supports other cluster lifecycle functions, such as [bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) and cluster upgrades. @@ -254,11 +254,11 @@ Read all of this advice carefully before proceeding. **You must deploy a {{< glossary_tooltip text="Container Network Interface" term_id="cni" >}} -(CNI) based Pod network add-on so that your Pods can communicate with each other. +(CNI) based Pod network add-on so that your Pods can communicate with each other. Cluster DNS (CoreDNS) will not start up before a network is installed.** - Take care that your Pod network must not overlap with any of the host - networks: you are likely to see problems if there is any overlap. + networks: you are likely to see problems if there is any overlap. (If you find a collision between your network plugin’s preferred Pod network and some of your host networks, you should think of a suitable CIDR block to use instead, then use that during `kubeadm init` with @@ -266,13 +266,13 @@ Cluster DNS (CoreDNS) will not start up before a network is installed.** - By default, `kubeadm` sets up your cluster to use and enforce use of [RBAC](/docs/reference/access-authn-authz/rbac/) (role based access - control). + control). Make sure that your Pod network plugin supports RBAC, and so do any manifests that you use to deploy it. - If you want to use IPv6--either dual-stack, or single-stack IPv6 only networking--for your cluster, make sure that your Pod network plugin - supports IPv6. + supports IPv6. IPv6 support was added to CNI in [v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0). {{< /caution >}} @@ -286,8 +286,8 @@ tracker instead of the kubeadm or kubernetes issue trackers. Several external projects provide Kubernetes Pod networks using CNI, some of which also support [Network Policy](/docs/concepts/services-networking/networkpolicies/). -See the list of available -[networking and network policy add-ons](/docs/concepts/cluster-administration/addons/#networking-and-network-policy). +See a list of add-ons that implement the +[Kubernetes networking model](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model). You can install a Pod network add-on with the following command on the control-plane node or a node that has the kubeconfig credentials: @@ -297,79 +297,6 @@ kubectl apply -f ``` You can install only one Pod network per cluster. -Below you can find installation instructions for some popular Pod network plugins: - -{{< tabs name="tabs-pod-install" >}} - -{{% tab name="Calico" %}} -[Calico](https://docs.projectcalico.org/latest/introduction/) is a networking and network policy provider. Calico supports a flexible set of networking options so you can choose the most efficient option for your situation, including non-overlay and overlay networks, with or without BGP. Calico uses the same engine to enforce network policy for hosts, pods, and (if using Istio & Envoy) applications at the service mesh layer. Calico works on several architectures, including `amd64`, `arm64`, and `ppc64le`. - -Calico will automatically detect which IP address range to use for pod IPs based on the value provided via the `--pod-network-cidr` flag or via kubeadm's configuration. - -```shell -kubectl apply -f https://docs.projectcalico.org/v3.14/manifests/calico.yaml -``` - -{{% /tab %}} - -{{% tab name="Cilium" %}} - -To deploy Cilium you just need to run: - -```shell -kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml -``` - -Once all Cilium Pods are marked as `READY`, you start using your cluster. - -```shell -kubectl get pods -n kube-system --selector=k8s-app=cilium -``` -The output is similar to this: -``` -NAME READY STATUS RESTARTS AGE -cilium-drxkl 1/1 Running 0 18m -``` - -Cilium can be used as a replacement for kube-proxy, see [Kubernetes without kube-proxy](https://docs.cilium.io/en/stable/gettingstarted/kubeproxy-free). - -For more information about using Cilium with Kubernetes, see [Kubernetes Install guide for Cilium](https://docs.cilium.io/en/stable/kubernetes/). - -{{% /tab %}} - -{{% tab name="Contiv-VPP" %}} -[Contiv-VPP](https://contivpp.io/) employs a programmable CNF vSwitch based on [FD.io VPP](https://fd.io/), -offering feature-rich & high-performance cloud-native networking and services. - -It implements k8s services and network policies in the user space (on VPP). - -Please refer to this installation guide: [Contiv-VPP Manual Installation](https://github.com/contiv/vpp/blob/master/docs/setup/MANUAL_INSTALL.md) -{{% /tab %}} - -{{% tab name="Kube-router" %}} - -Kube-router relies on kube-controller-manager to allocate Pod CIDR for the nodes. Therefore, use `kubeadm init` with the `--pod-network-cidr` flag. - -Kube-router provides Pod networking, network policy, and high-performing IP Virtual Server(IPVS)/Linux Virtual Server(LVS) based service proxy. - -For information on using the `kubeadm` tool to set up a Kubernetes cluster with Kube-router, please see the official [setup guide](https://github.com/cloudnativelabs/kube-router/blob/master/docs/kubeadm.md). -{{% /tab %}} - -{{% tab name="Weave Net" %}} - -For more information on setting up your Kubernetes cluster with Weave Net, please see [Integrating Kubernetes via the Addon](https://www.weave.works/docs/net/latest/kube-addon/). - -Weave Net works on `amd64`, `arm`, `arm64` and `ppc64le` platforms without any extra action required. -Weave Net sets hairpin mode by default. This allows Pods to access themselves via their Service IP address -if they don't know their PodIP. - -```shell -kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" -``` -{{% /tab %}} - -{{< /tabs >}} - Once a Pod network has been installed, you can confirm that it is working by checking that the CoreDNS Pod is `Running` in the output of `kubectl get pods --all-namespaces`. From a491d86a0c12210fb3c8f65ec564810e228b21e5 Mon Sep 17 00:00:00 2001 From: Ben Gadbois Date: Mon, 20 Jul 2020 14:30:44 -0700 Subject: [PATCH 23/86] audit: typo fix --- content/en/docs/tasks/debug-application-cluster/audit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/debug-application-cluster/audit.md b/content/en/docs/tasks/debug-application-cluster/audit.md index 730097e432..14d5bef7f1 100644 --- a/content/en/docs/tasks/debug-application-cluster/audit.md +++ b/content/en/docs/tasks/debug-application-cluster/audit.md @@ -331,7 +331,7 @@ Currently, this feature has performance implications for the apiserver in the fo If you're extending the Kubernetes API with the [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/), -y ou can also set up audit logging for the aggregated apiserver. To do this, +you can also set up audit logging for the aggregated apiserver. To do this, pass the configuration options in the same format as described above to the aggregated apiserver and set up the log ingesting pipeline to pick up audit logs. Different apiservers can have different audit configurations and From f1588c03f30ac62be64eefee5e451fac1c81500e Mon Sep 17 00:00:00 2001 From: "Johannes M. Scheuermann" Date: Tue, 21 Jul 2020 10:24:40 +0200 Subject: [PATCH 24/86] Add feature state for individual health checks --- content/en/docs/reference/using-api/health-checks.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/content/en/docs/reference/using-api/health-checks.md b/content/en/docs/reference/using-api/health-checks.md index 7e1aabbf21..a7be3b267f 100644 --- a/content/en/docs/reference/using-api/health-checks.md +++ b/content/en/docs/reference/using-api/health-checks.md @@ -31,6 +31,12 @@ This can be useful for a human operator to debug the current status of the Api s curl -k https://localhost:6443/livez?verbose ``` +or from a remote host with authentication: + + ```shell + kubectl get --raw='/readyz?verbose' + ``` + The output will look like this: [+]ping ok @@ -83,6 +89,10 @@ The output show that the `etcd` check is excluded: [+]shutdown ok healthz check passed +## Individual health checks + +{{< feature-state state="alpha" >}} + Each individual health check exposes an http endpoint and could can be checked individually. The schema for the individual health checks is `/livez/` where `livez` and `readyz` and be used to indicate if you want to check thee liveness or the readiness of the API server. The `` path can be discovered using the `verbose` flag from above and take the path between `[+]` and `ok`. From 96b76320c716ff9bb4bb57c4248fdeb5cce9f777 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Tue, 21 Jul 2020 18:55:59 +0800 Subject: [PATCH 25/86] Remove the 'slug' attribute from open-a-pr The slug is causing problems for tracking missing links. Other than that, I'm not seeing any advantage of using it. --- content/en/docs/contribute/new-content/open-a-pr.md | 1 - 1 file changed, 1 deletion(-) diff --git a/content/en/docs/contribute/new-content/open-a-pr.md b/content/en/docs/contribute/new-content/open-a-pr.md index 98998d7f74..d511360e22 100644 --- a/content/en/docs/contribute/new-content/open-a-pr.md +++ b/content/en/docs/contribute/new-content/open-a-pr.md @@ -1,6 +1,5 @@ --- title: Opening a pull request -slug: new-content content_type: concept weight: 10 card: From 27c5df83f8772144a6e376d91f85e198e9af0dbd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=81ngel=20Barrera?= Date: Tue, 21 Jul 2020 13:03:00 +0200 Subject: [PATCH 26/86] typo clusers -> clusters FIX a typo in clusers -> clusters --- content/en/docs/concepts/containers/images.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/containers/images.md b/content/en/docs/concepts/containers/images.md index a01e8d84f9..415d920b40 100644 --- a/content/en/docs/concepts/containers/images.md +++ b/content/en/docs/concepts/containers/images.md @@ -129,7 +129,7 @@ example, run these on your desktop/laptop: - for example, to test this out: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done` {{< note >}} -For production clusers, use a configuration management tool so that you can apply this +For production clusters, use a configuration management tool so that you can apply this setting to all the nodes where you need it. {{< /note >}} From cfc4d906e03837e333fbbec71d811d5b6bbb9556 Mon Sep 17 00:00:00 2001 From: Aris Cahyadi Risdianto Date: Fri, 10 Jul 2020 00:28:05 +0800 Subject: [PATCH 27/86] ID localization for administer cluster - high available master Fix translation word. Small change to initiate hugo deploy. Addressing several comments. --- .../highly-available-master.md | 177 ++++++++++++++++++ 1 file changed, 177 insertions(+) create mode 100644 content/id/docs/tasks/administer-cluster/highly-available-master.md diff --git a/content/id/docs/tasks/administer-cluster/highly-available-master.md b/content/id/docs/tasks/administer-cluster/highly-available-master.md new file mode 100644 index 0000000000..0b2ebea7fe --- /dev/null +++ b/content/id/docs/tasks/administer-cluster/highly-available-master.md @@ -0,0 +1,177 @@ +--- +title: Mengatur Control Plane Kubernetes dengan Ketersediaan Tinggi (High-Availability) +content_type: task +--- + + + +{{< feature-state for_k8s_version="v1.5" state="alpha" >}} + +Kamu dapat mereplikasi _control plane_ Kubernetes dalam skrip `kube-up` atau `kube-down` untuk Google Compute Engine (GCE). +Dokumen ini menjelaskan cara menggunakan skrip kube-up/down untuk mengelola _control plane_ dengan ketersedian tinggi atau _high_availability_ (HA) dan bagaimana _control plane_ HA diimplementasikan untuk digunakan dalam GCE. + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + + +## Memulai klaster yang kompatibel dengan HA + +Untuk membuat klaster yang kompatibel dengan HA, kamu harus mengatur tanda ini pada skrip `kube-up`: + +* `MULTIZONE=true` - untuk mencegah penghapusan replika _control plane_ kubelet dari zona yang berbeda dengan zona bawaan server. +Ini diperlukan jika kamu ingin menjalankan replika _control plane_ pada zona berbeda, dimana hal ini disarankan. + +* `ENABLE_ETCD_QUORUM_READ=true` - untuk memastikan bahwa pembacaan dari semua server API akan mengembalikan data terbaru. +Jika `true`, bacaan akan diarahkan ke replika pemimpin dari etcd. +Menetapkan nilai ini menjadi `true` bersifat opsional: pembacaan akan lebih dapat diandalkan tetapi juga akan menjadi lebih lambat. + +Sebagai pilihan, kamu dapat menentukan zona GCE tempat dimana replika _control plane_ pertama akan dibuat. +Atur tanda berikut: + +* `KUBE_GCE_ZONE=zone` - zona tempat di mana replika _control plane_ pertama akan berjalan. + +Berikut ini contoh perintah untuk mengatur klaster yang kompatibel dengan HA pada zona GCE europe-west1-b: + +```shell +MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh +``` + +Perhatikan bahwa perintah di atas digunakan untuk membuat klaster dengan sebuah _control plane_; +Namun, kamu bisa menambahkan replika _control plane_ baru ke klaster dengan perintah berikutnya. + + +## Menambahkan replika _control plane_ yang baru + +Setelah kamu membuat klaster yang kompatibel dengan HA, kamu bisa menambahkan replika _control plane_ ke sana. +Kamu bisa menambahkan replika _control plane_ dengan menggunakan skrip `kube-up` dengan tanda berikut ini: + +* `KUBE_REPLICATE_EXISTING_MASTER=true` - untuk membuat replika dari _control plane_ yang sudah ada. + +* `KUBE_GCE_ZONE=zone` - zona di mana replika _control plane_ itu berjalan. +Region ini harus sama dengan region dari zona replika yang lain. + +Kamu tidak perlu mengatur tanda `MULTIZONE` atau `ENABLE_ETCD_QUORUM_READS`, +karena tanda itu diturunkan pada saat kamu memulai klaster yang kompatible dengan HA. + +Berikut ini contoh perintah untuk mereplikasi _control plane_ pada klaster sebelumnya yang kompatibel dengan HA: + +```shell +KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh +``` + +## Menghapus replika _control plane_ + +Kamu dapat menghapus replika _control plane_ dari klaster HA dengan menggunakan skrip `kube-down` dengan tanda berikut: + +* `KUBE_DELETE_NODES=false` - untuk mencegah penghapusan kubelet. + +* `KUBE_GCE_ZONE=zone` - zona di mana replika _control plane_ akan dihapus. + +* `KUBE_REPLICA_NAME=replica_name` - (opsional) nama replika _control plane_ yang akan dihapus. +Jika kosong: replika mana saja dari zona yang diberikan akan dihapus. + +Berikut ini contoh perintah untuk menghapus replika _control plane_ dari klaster HA yang sudah ada sebelumnya: + +```shell +KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh +``` + +## Mengatasi replika _control plane_ yang gagal + +Jika salah satu replika _control plane_ di klaster HA kamu gagal, +praktek terbaik adalah menghapus replika dari klaster kamu dan menambahkan replika baru pada zona yang sama. +Berikut ini contoh perintah yang menunjukkan proses tersebut: + +1. Menghapus replika yang gagal: + +```shell +KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh +``` + +2. Menambahkan replika baru untuk menggantikan replika yang lama + +```shell +KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh +``` + +## Praktek terbaik untuk mereplikasi _control plane_ untuk klaster HA + +* Usahakan untuk menempatkan replika _control plane_ pada zona yang berbeda. Pada saat terjadi kegagalan zona, semua _control plane_ yang ditempatkan dalam zona tersebut akan gagal pula. +Untuk bertahan dari kegagalan pada sebuah zona, tempatkan juga Node pada beberapa zona yang lain +(Lihatlah [multi-zona](/id/docs/setup/best-practices/multiple-zones/) untuk lebih detail). + +* Jangan gunakan klaster dengan dua replika _control plane_. Konsensus pada klaster dengan dua replika membutuhkan kedua replika tersebut berjalan pada saat mengubah keadaan yang persisten. +Akibatnya, kedua replika tersebut diperlukan dan kegagalan salah satu replika mana pun mengubah klaster dalam status kegagalan mayoritas. +Dengan demikian klaster dengan dua replika lebih buruk, dalam hal HA, daripada klaster dengan replika tunggal. + +* Ketika kamu menambahkan sebuah replika _control plane_, status klaster (etcd) disalin ke sebuah _instance_ baru. +Jika klaster itu besar, mungkin butuh waktu yang lama untuk menduplikasi keadaannya. +Operasi ini dapat dipercepat dengan memigrasi direktori data etcd, seperti yang dijelaskan [di sini](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration) +(Kami sedang mempertimbangkan untuk menambahkan dukungan untuk migrasi direktori data etcd di masa mendatang). + + + + + +## Catatan implementasi + +![ha-master-gce](/images/docs/ha-master-gce.png) + +### Ikhtisar + +Setiap replika _control plane_ akan menjalankan komponen berikut dalam mode berikut: + +* _instance_ etcd: semua _instance_ akan dikelompokkan bersama menggunakan konsensus; + +* server API : setiap server akan berbicara dengan lokal etcd - semua server API pada cluster akan tersedia; + +* pengontrol (_controller_), penjadwal (_scheduler_), dan _scaler_ klaster automatis: akan menggunakan mekanisme sewa - dimana hanya satu _instance_ dari masing-masing mereka yang akan aktif dalam klaster; + +* manajer tambahan (_add-on_): setiap manajer akan bekerja secara independen untuk mencoba menjaga tambahan dalam sinkronisasi. + +Selain itu, akan ada penyeimbang beban (_load balancer_) di depan server API yang akan mengarahkan lalu lintas eksternal dan internal menuju mereka. + + +### Penyeimbang Beban + +Saat memulai replika _control plane_ kedua, penyeimbang beban yang berisi dua replika akan dibuat +dan alamat IP dari replika pertama akan dipromosikan ke alamat IP penyeimbang beban. +Demikian pula, setelah penghapusan replika _control plane_ kedua yang dimulai dari paling akhir, penyeimbang beban akan dihapus dan alamat IP-nya akan diberikan ke replika terakhir yang ada. +Mohon perhatikan bahwa pembuatan dan penghapusan penyeimbang beban adalah operasi yang rumit dan mungkin perlu beberapa waktu (~20 menit) untuk dipropagasikan. + + +### Service _control plane_ & kubelet + +Daripada sistem mencoba untuk menjaga daftar terbaru dari apiserver Kubernetes yang ada dalam Service Kubernetes, +sistem akan mengarahkan semua lalu lintas ke IP eksternal: + +* dalam klaster dengan satu _control plane_, IP diarahkan ke _control plane_ tunggal. + +* dalam klaster dengan multiple _control plane_, IP diarahkan ke penyeimbang beban yang ada di depan _control plane_. + +Demikian pula, IP eksternal akan digunakan oleh kubelet untuk berkomunikasi dengan _control plane_. + + +### Sertifikat _control plane_ + +Kubernetes menghasilkan sertifikat TLS _control plane_ untuk IP publik eksternal dan IP lokal untuk setiap replika. +Tidak ada sertifikat untuk IP publik sementara (_ephemeral_) dari replika; +Untuk mengakses replika melalui IP publik sementara, kamu harus melewatkan verifikasi TLS. + +### Pengklasteran etcd + +Untuk mengizinkan pengelompokkan etcd, porta yang diperlukan untuk berkomunikasi antara _instance_ etcd akan dibuka (untuk komunikasi dalam klaster). +Untuk membuat penyebaran itu aman, komunikasi antara _instance_ etcd diotorisasi menggunakan SSL. + +## Bacaan tambahan + +[Dokumen desain - Penyebaran master HA automatis](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md) + + From e5e0faf011e45d61354efbb7435e7cd2ec540fa4 Mon Sep 17 00:00:00 2001 From: Oleg Atamanenko Date: Tue, 21 Jul 2020 12:01:45 -0700 Subject: [PATCH 28/86] Fixed typo in feature gate name. Fixed typo. related PR: https://github.com/kubernetes/kubernetes/pull/86377/ --- content/en/docs/concepts/configuration/configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/configuration/configmap.md b/content/en/docs/concepts/configuration/configmap.md index c22c8f0312..d7d2feb9d5 100644 --- a/content/en/docs/concepts/configuration/configmap.md +++ b/content/en/docs/concepts/configuration/configmap.md @@ -224,7 +224,7 @@ data has the following advantages: - improves performance of your cluster by significantly reducing load on kube-apiserver, by closing watches for config maps marked as immutable. -To use this feature, enable the `ImmutableEmphemeralVolumes` +To use this feature, enable the `ImmutableEphemeralVolumes` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) and set your Secret or ConfigMap `immutable` field to `true`. For example: ```yaml From 73e002ed93e12a7745014e08160525d384683981 Mon Sep 17 00:00:00 2001 From: Arhell Date: Wed, 22 Jul 2020 00:36:26 +0300 Subject: [PATCH 29/86] add review member for ru content --- OWNERS_ALIASES | 1 + 1 file changed, 1 insertion(+) diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index 0d5f4975fb..9498e2c228 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -192,6 +192,7 @@ aliases: - potapy4 - dianaabv sig-docs-ru-reviews: # PR reviews for Russian content + - Arhell - msheldyakov - aisonaku - potapy4 From 795164081107df2790df2c25af7c4fd927ad9619 Mon Sep 17 00:00:00 2001 From: TianYi Date: Wed, 22 Jul 2020 08:56:39 +0800 Subject: [PATCH 30/86] Update scale-intro.html --- .../docs/tutorials/kubernetes-basics/scale/scale-intro.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html index d173bddc87..73151bdcb8 100644 --- a/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html +++ b/content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html @@ -126,8 +126,8 @@ weight: 10
- - 开始互动教程 › + + 开始互动教程 ›
From 7fa16ffcb610500a1b2700d0b88d475c99c731f5 Mon Sep 17 00:00:00 2001 From: Jeremy Date: Wed, 22 Jul 2020 11:59:30 +0800 Subject: [PATCH 31/86] Update declare-network-policy.md modify default nginx label --- .../zh/docs/tasks/administer-cluster/declare-network-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/tasks/administer-cluster/declare-network-policy.md b/content/zh/docs/tasks/administer-cluster/declare-network-policy.md index 7620b37f9d..11ddbff307 100644 --- a/content/zh/docs/tasks/administer-cluster/declare-network-policy.md +++ b/content/zh/docs/tasks/administer-cluster/declare-network-policy.md @@ -90,7 +90,7 @@ metadata: spec: podSelector: matchLabels: - run: nginx + app: nginx ingress: - from: - podSelector: From 130822d3d6314940ba12c0ff3824747ff78f2fc4 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Wed, 22 Jul 2020 12:44:37 +0900 Subject: [PATCH 32/86] Clean up case study images. --- content/en/case-studies/adform/index.html | 6 +++--- content/en/case-studies/adidas/index.html | 6 +++--- .../en/case-studies/ant-financial/index.html | 6 +++--- content/en/case-studies/appdirect/index.html | 6 +++--- content/en/case-studies/babylon/index.html | 6 +++--- .../en/case-studies/booking-com/index.html | 6 +++--- content/en/case-studies/booz-allen/index.html | 6 +++--- content/en/case-studies/bose/index.html | 6 +++--- .../en/case-studies/capital-one/index.html | 6 +++--- content/en/case-studies/cern/index.html | 6 +++--- .../en/case-studies/chinaunicom/index.html | 6 +++--- .../case-studies/city-of-montreal/index.html | 6 +++--- content/en/case-studies/denso/index.html | 6 +++--- content/en/case-studies/ibm/index.html | 6 +++--- content/en/case-studies/ing/index.html | 6 +++--- content/en/case-studies/jd-com/index.html | 6 +++--- content/en/case-studies/naic/index.html | 6 +++--- content/en/case-studies/nav/index.html | 6 +++--- content/en/case-studies/nerdalize/index.html | 6 +++--- content/en/case-studies/netease/index.html | 6 +++--- .../en/case-studies/newyorktimes/index.html | 6 +++--- content/en/case-studies/nokia/index.html | 6 +++--- content/en/case-studies/nordstrom/index.html | 6 +++--- .../northwestern-mutual/index.html | 10 +++++----- content/en/case-studies/ocado/index.html | 8 ++++---- content/en/case-studies/openAI/index.html | 6 +++--- content/en/case-studies/pearson/index.html | 6 +++--- content/en/case-studies/pingcap/index.html | 6 +++--- content/en/case-studies/pinterest/index.html | 6 +++--- content/en/case-studies/prowise/index.html | 6 +++--- content/en/case-studies/ricardo-ch/index.html | 6 +++--- content/en/case-studies/slamtec/index.html | 6 +++--- content/en/case-studies/slingtv/index.html | 6 +++--- content/en/case-studies/sos/index.html | 6 +++--- content/en/case-studies/spotify/index.html | 6 +++--- .../en/case-studies/squarespace/index.html | 6 +++--- content/en/case-studies/thredup/index.html | 6 +++--- content/en/case-studies/vsco/index.html | 6 +++--- content/en/case-studies/woorank/index.html | 6 +++--- content/en/case-studies/workiva/index.html | 16 ++++++++-------- content/en/case-studies/ygrene/index.html | 6 +++--- layouts/case-studies/list.html | 6 +++--- static/css/style_amadeus.css | 18 +++++++++--------- static/css/style_ancestry.css | 8 ++++---- static/css/style_blablacar.css | 14 +++++++------- static/css/style_blackrock.css | 14 +++++++------- static/css/style_box.css | 14 +++++++------- static/css/style_buffer.css | 14 +++++++------- static/css/style_crowdfire.css | 16 ++++++++-------- static/css/style_golfnow.css | 16 ++++++++-------- static/css/style_haufegroup.css | 14 +++++++------- static/css/style_huawei.css | 14 +++++++------- static/css/style_peardeck.css | 12 ++++++------ static/css/style_wink.css | 12 ++++++------ static/css/style_zalando.css | 12 ++++++------ .../adform/banner1.jpg} | Bin .../adform/banner3.jpg} | Bin .../adform/banner4.jpg} | Bin .../adidas/banner1.png} | Bin .../adidas/banner2.png} | Bin .../adidas/banner3.png} | Bin .../amadeus/banner1.jpg} | Bin .../amadeus/banner1_mobile.jpg} | Bin .../amadeus/banner3.jpg} | Bin .../amadeus/banner4.jpg} | Bin .../ancestry/banner1.jpg} | Bin .../ancestry/banner3.jpg} | Bin .../ancestry/banner4.jpg} | Bin .../antfinancial/banner1.jpg} | Bin .../antfinancial/banner3.jpg} | Bin .../antfinancial/banner4.jpg} | Bin .../appdirect/banner1.jpg} | Bin .../appdirect/banner3.jpg} | Bin .../appdirect/banner4.jpg} | Bin .../babylon/banner1.jpg} | Bin .../babylon/banner2.jpg} | Bin .../babylon/banner4.jpg} | Bin .../blablacar/banner1.jpg} | Bin .../blablacar/banner1_mobile.jpg} | Bin .../blablacar/banner3.jpg} | Bin .../blablacar/banner4.jpg} | Bin .../blackrock/banner1.jpg} | Bin .../blackrock/banner3.jpg} | Bin .../blackrock/banner4.jpg} | Bin .../booking/banner1.jpg} | Bin .../booking/banner2.jpg} | Bin .../booking/banner3.jpg} | Bin .../booz-allen/banner1.png} | Bin .../booz-allen/banner2.jpg} | Bin .../booz-allen/banner4.jpg} | Bin .../bose/banner1.jpg} | Bin .../bose/banner3.jpg} | Bin .../bose/banner4.jpg} | Bin .../box/banner1.jpg} | Bin .../box/banner3.jpg} | Bin .../box/banner4.jpg} | Bin .../buffer/banner1.jpg} | Bin .../buffer/banner3.jpg} | Bin .../buffer/banner4.jpg} | Bin .../capitalone/banner1.jpg} | Bin .../capitalone/banner3.jpg} | Bin .../capitalone/banner4.jpg} | Bin .../cern/banner1.jpg} | Bin .../cern/banner3.jpg} | Bin .../cern/banner4.jpg} | Bin .../chinaunicom/banner1.jpg} | Bin .../chinaunicom/banner3.jpg} | Bin .../chinaunicom/banner4.jpg} | Bin .../crowdfire/banner1.jpg} | Bin .../crowdfire/banner3.jpg} | Bin .../crowdfire/banner4.jpg} | Bin .../denso/banner1.png} | Bin .../denso/banner2.jpg} | Bin .../denso/banner4.jpg} | Bin .../ft/banner1.jpg} | Bin .../ft/banner3.jpg} | Bin .../ft/banner4.jpg} | Bin .../golfnow/banner1.jpg} | Bin .../golfnow/banner3.jpg} | Bin .../golfnow/banner4.jpg} | Bin .../haufegroup/banner1.jpg} | Bin .../haufegroup/banner3.jpg} | Bin .../haufegroup/banner4.jpg} | Bin .../huawei/banner1.jpg} | Bin .../huawei/banner3.jpg} | Bin .../huawei/banner4.jpg} | Bin .../ibm/banner1.jpg} | Bin .../ibm/banner3.jpg} | Bin .../ibm/banner4.jpg} | Bin .../ing/banner1.jpg} | Bin .../ing/banner3.jpg} | Bin .../ing/banner4.jpg} | Bin .../jdcom/banner1.jpg} | Bin .../jdcom/banner3.jpg} | Bin .../jdcom/banner4.jpg} | Bin .../montreal/banner1.jpg} | Bin .../montreal/banner3.jpg} | Bin .../montreal/banner4.jpg} | Bin .../naic/banner1.jpg} | Bin .../naic/banner3.jpg} | Bin .../naic/banner4.jpg} | Bin .../nav/banner1.jpg} | Bin .../nav/banner3.jpg} | Bin .../nav/banner4.jpg} | Bin .../nerdalize/banner1.jpg} | Bin .../nerdalize/banner3.jpg} | Bin .../nerdalize/banner4.jpg} | Bin .../netease/banner1.jpg} | Bin .../netease/banner3.jpg} | Bin .../netease/banner4.jpg} | Bin .../newyorktimes/banner1.jpg} | Bin .../newyorktimes/banner3.jpg} | Bin .../newyorktimes/banner4.jpg} | Bin .../nokia/banner1.jpg} | Bin .../nokia/banner3.jpg} | Bin .../nokia/banner4.jpg} | Bin .../nordstrom/banner1.jpg} | Bin .../nordstrom/banner3.jpg} | Bin .../nordstrom/banner4.jpg} | Bin .../northwestern/banner1.jpg} | Bin .../northwestern/banner3.jpg} | Bin .../northwestern/banner4.jpg} | Bin .../ocado/banner1.jpg} | Bin .../ocado/banner3.jpg} | Bin .../ocado/banner4.jpg} | Bin .../openAI/banner1.jpg} | Bin .../openAI/banner3.jpg} | Bin .../openAI/banner4.jpg} | Bin .../peardeck/banner1.jpg} | Bin .../peardeck/banner2.jpg} | Bin .../peardeck/banner3.jpg} | Bin .../pearson/banner1.jpg} | Bin .../pearson/banner3.jpg} | Bin .../pearson/banner4.jpg} | Bin .../pingcap/banner1.jpg} | Bin .../pingcap/banner3.jpg} | Bin .../pingcap/banner4.jpg} | Bin .../pinterest/banner1.jpg} | Bin .../pinterest/banner3.jpg} | Bin .../pinterest/banner4.jpg} | Bin .../prowise/banner1.jpg} | Bin .../prowise/banner3.jpg} | Bin .../prowise/banner4.jpg} | Bin .../ricardoch/banner1.png} | Bin .../ricardoch/banner3.png} | Bin .../ricardoch/banner4.png} | Bin .../slamtec/banner1.jpg} | Bin .../slamtec/banner3.jpg} | Bin .../slamtec/banner4.jpg} | Bin .../slingtv/banner1.jpg} | Bin .../slingtv/banner3.jpg} | Bin .../slingtv/banner4.jpg} | Bin .../sos/banner1.jpg} | Bin .../sos/banner3.jpg} | Bin .../sos/banner4.jpg} | Bin .../spotify/banner1.jpg} | Bin .../spotify/banner3.jpg} | Bin .../spotify/banner4.jpg} | Bin .../squarespace/banner1.jpg} | Bin .../squarespace/banner3.jpg} | Bin .../squarespace/banner4.jpg} | Bin .../{case_studies => case-studies}/story.png | Bin .../{case_studies => case-studies}/story.svg | 0 .../thredup/banner1.jpg} | Bin .../thredup/banner3.jpg} | Bin .../thredup/banner4.jpg} | Bin .../video_thumb.jpg | Bin .../video_thumb1.png | Bin .../vsco/banner1.jpg} | Bin .../vsco/banner2.jpg} | Bin .../vsco/banner4.jpg} | Bin .../wink/banner1.jpg} | Bin .../wink/banner3.jpg} | Bin .../wink/banner4.jpg} | Bin .../{case_studies => case-studies}/wmc.png | Bin .../woorank/banner1.jpg} | Bin .../woorank/banner3.jpg} | Bin .../woorank/banner4.jpg} | Bin .../workiva/banner1.jpg} | Bin .../workiva/banner3.jpg} | Bin .../workiva/banner4.jpg} | Bin .../yahoojapan.png | Bin .../ygrene/banner1.jpg} | Bin .../ygrene/banner3.jpg} | Bin .../ygrene/banner4.jpg} | Bin .../zalando/banner1.jpg} | Bin .../zalando/banner3.jpg} | Bin .../zalando/banner4.jpg} | Bin 228 files changed, 223 insertions(+), 223 deletions(-) rename static/images/{CaseStudy_adform_banner1.jpg => case-studies/adform/banner1.jpg} (100%) rename static/images/{CaseStudy_adform_banner3.jpg => case-studies/adform/banner3.jpg} (100%) rename static/images/{CaseStudy_adform_banner4.jpg => case-studies/adform/banner4.jpg} (100%) rename static/images/{Adidas1.png => case-studies/adidas/banner1.png} (100%) rename static/images/{Adidas2.png => case-studies/adidas/banner2.png} (100%) rename static/images/{Adidas3.png => case-studies/adidas/banner3.png} (100%) rename static/images/{CaseStudy_amadeus_banner1.jpg => case-studies/amadeus/banner1.jpg} (100%) rename static/images/{CaseStudy_amadeus_banner_mobile.jpg => case-studies/amadeus/banner1_mobile.jpg} (100%) rename static/images/{CaseStudy_amadeus_banner3.jpg => case-studies/amadeus/banner3.jpg} (100%) rename static/images/{CaseStudy_amadeus_banner4.jpg => case-studies/amadeus/banner4.jpg} (100%) rename static/images/{CaseStudy_ancestry_banner1.jpg => case-studies/ancestry/banner1.jpg} (100%) rename static/images/{CaseStudy_ancestry_banner3.jpg => case-studies/ancestry/banner3.jpg} (100%) rename static/images/{CaseStudy_ancestry_banner4.jpg => case-studies/ancestry/banner4.jpg} (100%) rename static/images/{CaseStudy_antfinancial_banner1.jpg => case-studies/antfinancial/banner1.jpg} (100%) rename static/images/{CaseStudy_antfinancial_banner3.jpg => case-studies/antfinancial/banner3.jpg} (100%) rename static/images/{CaseStudy_antfinancial_banner4.jpg => case-studies/antfinancial/banner4.jpg} (100%) rename static/images/{CaseStudy_appdirect_banner1.jpg => case-studies/appdirect/banner1.jpg} (100%) rename static/images/{CaseStudy_appdirect_banner3.jpg => case-studies/appdirect/banner3.jpg} (100%) rename static/images/{CaseStudy_appdirect_banner4.jpg => case-studies/appdirect/banner4.jpg} (100%) rename static/images/{Babylon1.jpg => case-studies/babylon/banner1.jpg} (100%) rename static/images/{Babylon2.jpg => case-studies/babylon/banner2.jpg} (100%) rename static/images/{babylon4.jpg => case-studies/babylon/banner4.jpg} (100%) rename static/images/{CaseStudy_blablacar_banner1.jpg => case-studies/blablacar/banner1.jpg} (100%) rename static/images/{CaseStudy_blablacar_banner1_mobile.jpg => case-studies/blablacar/banner1_mobile.jpg} (100%) rename static/images/{CaseStudy_blablacar_banner3.jpg => case-studies/blablacar/banner3.jpg} (100%) rename static/images/{CaseStudy_blablacar_banner4.jpg => case-studies/blablacar/banner4.jpg} (100%) rename static/images/{CaseStudy_blackrock_banner1.jpg => case-studies/blackrock/banner1.jpg} (100%) rename static/images/{CaseStudy_blackrock_banner3.jpg => case-studies/blackrock/banner3.jpg} (100%) rename static/images/{CaseStudy_blackrock_banner4.jpg => case-studies/blackrock/banner4.jpg} (100%) rename static/images/{booking1.jpg => case-studies/booking/banner1.jpg} (100%) rename static/images/{booking2.JPG => case-studies/booking/banner2.jpg} (100%) rename static/images/{booking3.jpg => case-studies/booking/banner3.jpg} (100%) rename static/images/{BoozAllen1.png => case-studies/booz-allen/banner1.png} (100%) rename static/images/{BoozAllen2.jpg => case-studies/booz-allen/banner2.jpg} (100%) rename static/images/{BoozAllen4.jpg => case-studies/booz-allen/banner4.jpg} (100%) rename static/images/{CaseStudy_bose_banner1.jpg => case-studies/bose/banner1.jpg} (100%) rename static/images/{CaseStudy_bose_banner3.jpg => case-studies/bose/banner3.jpg} (100%) rename static/images/{CaseStudy_bose_banner4.jpg => case-studies/bose/banner4.jpg} (100%) rename static/images/{CaseStudy_box_banner1.jpg => case-studies/box/banner1.jpg} (100%) rename static/images/{CaseStudy_box_banner3.jpg => case-studies/box/banner3.jpg} (100%) rename static/images/{CaseStudy_box_banner4.jpg => case-studies/box/banner4.jpg} (100%) rename static/images/{CaseStudy_buffer_banner1.jpg => case-studies/buffer/banner1.jpg} (100%) rename static/images/{CaseStudy_buffer_banner3.jpg => case-studies/buffer/banner3.jpg} (100%) rename static/images/{CaseStudy_buffer_banner4.jpg => case-studies/buffer/banner4.jpg} (100%) rename static/images/{CaseStudy_capitalone_banner1.jpg => case-studies/capitalone/banner1.jpg} (100%) rename static/images/{CaseStudy_capitalone_banner3.jpg => case-studies/capitalone/banner3.jpg} (100%) rename static/images/{CaseStudy_capitalone_banner4.jpg => case-studies/capitalone/banner4.jpg} (100%) rename static/images/{CaseStudy_cern_banner1.jpg => case-studies/cern/banner1.jpg} (100%) rename static/images/{CaseStudy_cern_banner3.jpg => case-studies/cern/banner3.jpg} (100%) rename static/images/{CaseStudy_cern_banner4.jpg => case-studies/cern/banner4.jpg} (100%) rename static/images/{CaseStudy_chinaunicom_banner1.jpg => case-studies/chinaunicom/banner1.jpg} (100%) rename static/images/{CaseStudy_chinaunicom_banner3.jpg => case-studies/chinaunicom/banner3.jpg} (100%) rename static/images/{CaseStudy_chinaunicom_banner4.jpg => case-studies/chinaunicom/banner4.jpg} (100%) rename static/images/{CaseStudy_crowdfire_banner1.jpg => case-studies/crowdfire/banner1.jpg} (100%) rename static/images/{CaseStudy_crowdfire_banner3.jpg => case-studies/crowdfire/banner3.jpg} (100%) rename static/images/{CaseStudy_crowdfire_banner4.jpg => case-studies/crowdfire/banner4.jpg} (100%) rename static/images/{Denso1.png => case-studies/denso/banner1.png} (100%) rename static/images/{Denso2.jpg => case-studies/denso/banner2.jpg} (100%) rename static/images/{Denso4.jpg => case-studies/denso/banner4.jpg} (100%) rename static/images/{CaseStudy_ft_banner1.jpg => case-studies/ft/banner1.jpg} (100%) rename static/images/{CaseStudy_ft_banner3.jpg => case-studies/ft/banner3.jpg} (100%) rename static/images/{CaseStudy_ft_banner4.jpg => case-studies/ft/banner4.jpg} (100%) rename static/images/{CaseStudy_golfnow_banner1.jpg => case-studies/golfnow/banner1.jpg} (100%) rename static/images/{CaseStudy_golfnow_banner3.jpg => case-studies/golfnow/banner3.jpg} (100%) rename static/images/{CaseStudy_golfnow_banner4.jpg => case-studies/golfnow/banner4.jpg} (100%) rename static/images/{CaseStudy_haufegroup_banner1.jpg => case-studies/haufegroup/banner1.jpg} (100%) rename static/images/{CaseStudy_haufegroup_banner3.jpg => case-studies/haufegroup/banner3.jpg} (100%) rename static/images/{CaseStudy_haufegroup_banner4.jpg => case-studies/haufegroup/banner4.jpg} (100%) rename static/images/{CaseStudy_huawei_banner1.jpg => case-studies/huawei/banner1.jpg} (100%) rename static/images/{CaseStudy_huawei_banner3.jpg => case-studies/huawei/banner3.jpg} (100%) rename static/images/{CaseStudy_huawei_banner4.jpg => case-studies/huawei/banner4.jpg} (100%) rename static/images/{CaseStudy_ibm_banner1.jpg => case-studies/ibm/banner1.jpg} (100%) rename static/images/{CaseStudy_ibm_banner3.jpg => case-studies/ibm/banner3.jpg} (100%) rename static/images/{CaseStudy_ibm_banner4.jpg => case-studies/ibm/banner4.jpg} (100%) rename static/images/{CaseStudy_ing_banner1.jpg => case-studies/ing/banner1.jpg} (100%) rename static/images/{CaseStudy_ing_banner3.jpg => case-studies/ing/banner3.jpg} (100%) rename static/images/{CaseStudy_ing_banner4.jpg => case-studies/ing/banner4.jpg} (100%) rename static/images/{CaseStudy_jdcom_banner1.jpg => case-studies/jdcom/banner1.jpg} (100%) rename static/images/{CaseStudy_jdcom_banner3.jpg => case-studies/jdcom/banner3.jpg} (100%) rename static/images/{CaseStudy_jdcom_banner4.jpg => case-studies/jdcom/banner4.jpg} (100%) rename static/images/{CaseStudy_montreal_banner1.jpg => case-studies/montreal/banner1.jpg} (100%) rename static/images/{CaseStudy_montreal_banner3.jpg => case-studies/montreal/banner3.jpg} (100%) rename static/images/{CaseStudy_montreal_banner4.jpg => case-studies/montreal/banner4.jpg} (100%) rename static/images/{CaseStudy_naic_banner1.jpg => case-studies/naic/banner1.jpg} (100%) rename static/images/{CaseStudy_naic_banner3.jpg => case-studies/naic/banner3.jpg} (100%) rename static/images/{CaseStudy_naic_banner4.jpg => case-studies/naic/banner4.jpg} (100%) rename static/images/{CaseStudy_nav_banner1.jpg => case-studies/nav/banner1.jpg} (100%) rename static/images/{CaseStudy_nav_banner3.jpg => case-studies/nav/banner3.jpg} (100%) rename static/images/{CaseStudy_nav_banner4.jpg => case-studies/nav/banner4.jpg} (100%) rename static/images/{CaseStudy_nerdalize_banner1.jpg => case-studies/nerdalize/banner1.jpg} (100%) rename static/images/{CaseStudy_nerdalize_banner3.jpg => case-studies/nerdalize/banner3.jpg} (100%) rename static/images/{CaseStudy_nerdalize_banner4.jpg => case-studies/nerdalize/banner4.jpg} (100%) rename static/images/{CaseStudy_netease_banner1.jpg => case-studies/netease/banner1.jpg} (100%) rename static/images/{CaseStudy_netease_banner3.jpg => case-studies/netease/banner3.jpg} (100%) rename static/images/{CaseStudy_netease_banner4.jpg => case-studies/netease/banner4.jpg} (100%) rename static/images/{CaseStudy_newyorktimes_banner1.jpg => case-studies/newyorktimes/banner1.jpg} (100%) rename static/images/{CaseStudy_newyorktimes_banner3.jpg => case-studies/newyorktimes/banner3.jpg} (100%) rename static/images/{CaseStudy_newyorktimes_banner4.jpg => case-studies/newyorktimes/banner4.jpg} (100%) rename static/images/{CaseStudy_nokia_banner1.jpg => case-studies/nokia/banner1.jpg} (100%) rename static/images/{CaseStudy_nokia_banner3.jpg => case-studies/nokia/banner3.jpg} (100%) rename static/images/{CaseStudy_nokia_banner4.jpg => case-studies/nokia/banner4.jpg} (100%) rename static/images/{CaseStudy_nordstrom_banner1.jpg => case-studies/nordstrom/banner1.jpg} (100%) rename static/images/{CaseStudy_nordstrom_banner3.jpg => case-studies/nordstrom/banner3.jpg} (100%) rename static/images/{CaseStudy_nordstrom_banner4.jpg => case-studies/nordstrom/banner4.jpg} (100%) rename static/images/{CaseStudy_northwestern_banner1.jpg => case-studies/northwestern/banner1.jpg} (100%) rename static/images/{CaseStudy_northwestern_banner3.jpg => case-studies/northwestern/banner3.jpg} (100%) rename static/images/{CaseStudy_northwestern_banner4.jpg => case-studies/northwestern/banner4.jpg} (100%) rename static/images/{CaseStudy_ocado_banner1.jpg => case-studies/ocado/banner1.jpg} (100%) rename static/images/{CaseStudy_ocado_banner3.jpg => case-studies/ocado/banner3.jpg} (100%) rename static/images/{CaseStudy_ocado_banner4.jpg => case-studies/ocado/banner4.jpg} (100%) rename static/images/{CaseStudy_openAI_banner1.jpg => case-studies/openAI/banner1.jpg} (100%) rename static/images/{CaseStudy_openAI_banner3.jpg => case-studies/openAI/banner3.jpg} (100%) rename static/images/{CaseStudy_openAI_banner4.jpg => case-studies/openAI/banner4.jpg} (100%) rename static/images/{CaseStudy_peardeck_banner1.jpg => case-studies/peardeck/banner1.jpg} (100%) rename static/images/{CaseStudy_peardeck_banner2.jpg => case-studies/peardeck/banner2.jpg} (100%) rename static/images/{CaseStudy_peardeck_banner3.jpg => case-studies/peardeck/banner3.jpg} (100%) rename static/images/{CaseStudy_pearson_banner1.jpg => case-studies/pearson/banner1.jpg} (100%) rename static/images/{CaseStudy_pearson_banner3.jpg => case-studies/pearson/banner3.jpg} (100%) rename static/images/{CaseStudy_pearson_banner4.jpg => case-studies/pearson/banner4.jpg} (100%) rename static/images/{CaseStudy_pingcap_banner1.jpg => case-studies/pingcap/banner1.jpg} (100%) rename static/images/{CaseStudy_pingcap_banner3.jpg => case-studies/pingcap/banner3.jpg} (100%) rename static/images/{CaseStudy_pingcap_banner4.jpg => case-studies/pingcap/banner4.jpg} (100%) rename static/images/{CaseStudy_pinterest_banner1.jpg => case-studies/pinterest/banner1.jpg} (100%) rename static/images/{CaseStudy_pinterest_banner3.jpg => case-studies/pinterest/banner3.jpg} (100%) rename static/images/{CaseStudy_pinterest_banner4.jpg => case-studies/pinterest/banner4.jpg} (100%) rename static/images/{CaseStudy_prowise_banner1.jpg => case-studies/prowise/banner1.jpg} (100%) rename static/images/{CaseStudy_prowise_banner3.jpg => case-studies/prowise/banner3.jpg} (100%) rename static/images/{CaseStudy_prowise_banner4.jpg => case-studies/prowise/banner4.jpg} (100%) rename static/images/{CaseStudy_ricardoch_banner1.png => case-studies/ricardoch/banner1.png} (100%) rename static/images/{CaseStudy_ricardoch_banner3.png => case-studies/ricardoch/banner3.png} (100%) rename static/images/{CaseStudy_ricardoch_banner4.png => case-studies/ricardoch/banner4.png} (100%) rename static/images/{CaseStudy_slamtec_banner1.jpg => case-studies/slamtec/banner1.jpg} (100%) rename static/images/{CaseStudy_slamtec_banner3.jpg => case-studies/slamtec/banner3.jpg} (100%) rename static/images/{CaseStudy_slamtec_banner4.jpg => case-studies/slamtec/banner4.jpg} (100%) rename static/images/{CaseStudy_slingtv_banner1.jpg => case-studies/slingtv/banner1.jpg} (100%) rename static/images/{CaseStudy_slingtv_banner3.jpg => case-studies/slingtv/banner3.jpg} (100%) rename static/images/{CaseStudy_slingtv_banner4.jpg => case-studies/slingtv/banner4.jpg} (100%) rename static/images/{CaseStudy_sos_banner1.jpg => case-studies/sos/banner1.jpg} (100%) rename static/images/{CaseStudy_sos_banner3.jpg => case-studies/sos/banner3.jpg} (100%) rename static/images/{CaseStudy_sos_banner4.jpg => case-studies/sos/banner4.jpg} (100%) rename static/images/{CaseStudy_spotify_banner1.jpg => case-studies/spotify/banner1.jpg} (100%) rename static/images/{CaseStudy_spotify_banner3.jpg => case-studies/spotify/banner3.jpg} (100%) rename static/images/{CaseStudy_spotify_banner4.jpg => case-studies/spotify/banner4.jpg} (100%) rename static/images/{CaseStudy_squarespace_banner1.jpg => case-studies/squarespace/banner1.jpg} (100%) rename static/images/{CaseStudy_squarespace_banner3.jpg => case-studies/squarespace/banner3.jpg} (100%) rename static/images/{CaseStudy_squarespace_banner4.jpg => case-studies/squarespace/banner4.jpg} (100%) rename static/images/{case_studies => case-studies}/story.png (100%) rename static/images/{case_studies => case-studies}/story.svg (100%) rename static/images/{CaseStudy_thredup_banner1.jpg => case-studies/thredup/banner1.jpg} (100%) rename static/images/{CaseStudy_thredup_banner3.jpg => case-studies/thredup/banner3.jpg} (100%) rename static/images/{CaseStudy_thredup_banner4.jpg => case-studies/thredup/banner4.jpg} (100%) rename static/images/{case_studies => case-studies}/video_thumb.jpg (100%) rename static/images/{case_studies => case-studies}/video_thumb1.png (100%) rename static/images/{CaseStudy_vsco_banner1.jpg => case-studies/vsco/banner1.jpg} (100%) rename static/images/{CaseStudy_vsco_banner2.jpg => case-studies/vsco/banner2.jpg} (100%) rename static/images/{CaseStudy_vsco_banner4.jpg => case-studies/vsco/banner4.jpg} (100%) rename static/images/{CaseStudy_wink_banner1.jpg => case-studies/wink/banner1.jpg} (100%) rename static/images/{CaseStudy_wink_banner3.jpg => case-studies/wink/banner3.jpg} (100%) rename static/images/{CaseStudy_wink_banner4.jpg => case-studies/wink/banner4.jpg} (100%) rename static/images/{case_studies => case-studies}/wmc.png (100%) rename static/images/{CaseStudy_woorank_banner1.jpg => case-studies/woorank/banner1.jpg} (100%) rename static/images/{CaseStudy_woorank_banner3.jpg => case-studies/woorank/banner3.jpg} (100%) rename static/images/{CaseStudy_woorank_banner4.jpg => case-studies/woorank/banner4.jpg} (100%) rename static/images/{CaseStudy_workiva_banner1.jpg => case-studies/workiva/banner1.jpg} (100%) rename static/images/{CaseStudy_workiva_banner3.jpg => case-studies/workiva/banner3.jpg} (100%) rename static/images/{CaseStudy_workiva_banner4.jpg => case-studies/workiva/banner4.jpg} (100%) rename static/images/{case_studies => case-studies}/yahoojapan.png (100%) rename static/images/{CaseStudy_ygrene_banner1.jpg => case-studies/ygrene/banner1.jpg} (100%) rename static/images/{CaseStudy_ygrene_banner3.jpg => case-studies/ygrene/banner3.jpg} (100%) rename static/images/{CaseStudy_ygrene_banner4.jpg => case-studies/ygrene/banner4.jpg} (100%) rename static/images/{CaseStudy_zalando_banner1.jpg => case-studies/zalando/banner1.jpg} (100%) rename static/images/{CaseStudy_zalando_banner3.jpg => case-studies/zalando/banner3.jpg} (100%) rename static/images/{CaseStudy_zalando_banner4.jpg => case-studies/zalando/banner4.jpg} (100%) diff --git a/content/en/case-studies/adform/index.html b/content/en/case-studies/adform/index.html index e9a8acc7a2..be35a2d837 100644 --- a/content/en/case-studies/adform/index.html +++ b/content/en/case-studies/adform/index.html @@ -12,7 +12,7 @@ quote: > Kubernetes enabled the self-healing and immutable infrastructure. We can do faster releases, so our developers are really happy. They can ship our features faster than before, and that makes our clients happier. --- -
+

CASE STUDY:
Improving Performance and Morale with Cloud Native

@@ -66,7 +66,7 @@ The company has a large infrastructure: Ope
-
+
"The fact that Cloud Native Computing Foundation incubated Kubernetes was a really big point for us because it was vendor neutral. And we can see that a community really gathers around it. Everyone shares their experiences, their knowledge, and the fact that it’s open source, you can contribute."

— Edgaras Apšega, IT Systems Engineer, Adform
@@ -83,7 +83,7 @@ The first production cluster was launched in the spring of 2018, and is now up t
-
+
"Releases are really nice for them, because they just push their code to Git and that’s it. They don’t have to worry about their virtual machines anymore."

— Andrius Cibulskis, IT Systems Engineer, Adform
diff --git a/content/en/case-studies/adidas/index.html b/content/en/case-studies/adidas/index.html index 3f7982765a..5f9d0da24a 100644 --- a/content/en/case-studies/adidas/index.html +++ b/content/en/case-studies/adidas/index.html @@ -9,7 +9,7 @@ featured: false ​ -
+

CASE STUDY: adidas

Staying True to Its Culture, adidas Got 40% of Its Most Impactful Systems Running on Kubernetes in a Year
@@ -33,7 +33,7 @@ featured: false
-
+
"For me, Kubernetes is a platform made by engineers for engineers. It’s relieving the development team from tasks that they don’t want to do, but at the same time giving the visibility of what is behind the curtain, so they can also control it."

- FERNANDO CORNAGO, SENIOR DIRECTOR OF PLATFORM ENGINEERING AT ADIDAS

@@ -74,7 +74,7 @@ featured: false ​ ​ -
+
“There is no competitive edge over our competitors like Puma or Nike in running and operating a Kubernetes cluster. Our competitive edge is that we teach our internal engineers how to build cool e-comm stores that are fast, that are resilient, that are running perfectly.”

- DANIEL EICHTEN, SENIOR DIRECTOR OF PLATFORM ENGINEERING AT ADIDAS

diff --git a/content/en/case-studies/ant-financial/index.html b/content/en/case-studies/ant-financial/index.html index 92b46526de..1711ef97b8 100644 --- a/content/en/case-studies/ant-financial/index.html +++ b/content/en/case-studies/ant-financial/index.html @@ -7,7 +7,7 @@ css: /css/style_case_studies.css featured: false --- -
+

CASE STUDY:
Ant Financial’s Hypergrowth Strategy Using Kubernetes

@@ -50,7 +50,7 @@ featured: false To address those challenges and provide reliable and consistent services to its customers, Ant Financial embraced Docker containerization in 2014. But they soon realized that they needed an orchestration solution for some tens-of-thousands-of-node clusters in the company’s data centers.
-
+
"On Double 11 this year, we had plenty of nodes on Kubernetes, but compared to the whole scale of our infrastructure, this is still in progress."

- RANGER YU, GLOBAL TECHNOLOGY PARTNERSHIP & DEVELOPMENT, ANT FINANCIAL @@ -65,7 +65,7 @@ featured: false All core financial systems were containerized by November 2017, and the migration to Kubernetes is ongoing. Ant’s platform also leverages a number of other CNCF projects, including Prometheus, OpenTracing, etcd and CoreDNS. “On Double 11 this year, we had plenty of nodes on Kubernetes, but compared to the whole scale of our infrastructure, this is still in progress,” says Ranger Yu, Global Technology Partnership & Development.
-
+
"We’re very grateful for CNCF and this amazing technology, which we need as we continue to scale globally. We’re definitely embracing the community and open source more in the future."

- HAOJIE HANG, PRODUCT MANAGEMENT, ANT FINANCIAL
diff --git a/content/en/case-studies/appdirect/index.html b/content/en/case-studies/appdirect/index.html index 16d93cce5c..ca6b0b8fe9 100644 --- a/content/en/case-studies/appdirect/index.html +++ b/content/en/case-studies/appdirect/index.html @@ -12,7 +12,7 @@ quote: > We made the right decisions at the right time. Kubernetes and the cloud native technologies are now seen as the de facto ecosystem. --- -
+

CASE STUDY:
AppDirect: How AppDirect Supported the 10x Growth of Its Engineering Staff with Kubernetess

@@ -53,7 +53,7 @@ quote: >
-
+
"We made the right decisions at the right time. Kubernetes and the cloud native technologies are now seen as the de facto ecosystem. We know where to focus our efforts in order to tackle the new wave of challenges we face as we scale out. The community is so active and vibrant, which is a great complement to our awesome internal team."

- Alexandre Gervais, Staff Software Developer, AppDirect @@ -69,7 +69,7 @@ quote: > Lacerte’s strategy ultimately worked because of the very real impact the Kubernetes platform has had to deployment time. Due to less dependency on custom-made, brittle shell scripts with SCP commands, time to deploy a new version has shrunk from 4 hours to a few minutes. Additionally, the company invested a lot of effort to make things self-service for developers. "Onboarding a new service doesn’t require Jira tickets or meeting with three different teams," says Lacerte. Today, the company sees 1,600 deployments per week, compared to 1-30 before.
-
+
"I think our velocity would have slowed down a lot if we didn’t have this new infrastructure."

- Pierre-Alexandre Lacerte, Director of Software Development, AppDirect
diff --git a/content/en/case-studies/babylon/index.html b/content/en/case-studies/babylon/index.html index afdc005411..dce0612175 100644 --- a/content/en/case-studies/babylon/index.html +++ b/content/en/case-studies/babylon/index.html @@ -12,7 +12,7 @@ quote: > --- -
+

CASE STUDY: Babylon

How Cloud Native Is Enabling Babylon’s Medical AI Innovations
@@ -36,7 +36,7 @@ quote: > Instead of waiting hours or days to be able to compute, teams can get access instantaneously. Clinical validations used to take 10 hours; now they are done in under 20 minutes. The portability of the cloud native platform has also enabled Babylon to expand into other countries.
-
+
“Kubernetes is a great platform for machine learning because it comes with all the scheduling and scalability that you need.”

- JÉRÉMIE VALLÉE, AI INFRASTRUCTURE LEAD AT BABYLON

@@ -84,7 +84,7 @@ quote: > -
+
“Giving a Kubernetes-based platform to our data scientists has meant increased security, increased innovation through empowerment, and a more affordable health service as our cloud engineers are building an experience that is used by hundreds on a daily basis, rather than supporting specific bespoke use cases.”

- JEAN MARIE FERDEGUE, DIRECTOR OF PLATFORM OPERATIONS AT BABYLON

diff --git a/content/en/case-studies/booking-com/index.html b/content/en/case-studies/booking-com/index.html index ffeb3f2707..99369a2bf9 100644 --- a/content/en/case-studies/booking-com/index.html +++ b/content/en/case-studies/booking-com/index.html @@ -14,7 +14,7 @@ quote: > ​ -
+

CASE STUDY: Booking.com

After Learning the Ropes with a Kubernetes Distribution, Booking.com Built a Platform of Its Own
@@ -40,7 +40,7 @@ quote: >
-
+
“As our users learn Kubernetes and become more sophisticated Kubernetes users, they put pressure on us to provide a better, more native Kubernetes experience, which is great. It’s a super healthy dynamic.”

- BEN TYLER, PRINCIPAL DEVELOPER, B PLATFORM TRACK AT BOOKING.COM

@@ -91,7 +91,7 @@ quote: > ​ ​ -
+
“We have a tutorial. You follow the tutorial. Your code is running. Then, it’s business-logic time. The time to gain access to resources is decreased enormously.”

- BEN TYLER, PRINCIPAL DEVELOPER, B PLATFORM TRACK AT BOOKING.COM

diff --git a/content/en/case-studies/booz-allen/index.html b/content/en/case-studies/booz-allen/index.html index 2a48c7f3b7..fdda5e976a 100644 --- a/content/en/case-studies/booz-allen/index.html +++ b/content/en/case-studies/booz-allen/index.html @@ -13,7 +13,7 @@ quote: > ​ -
+

CASE STUDY: Booz Allen Hamilton

How Booz Allen Hamilton Is Helping Modernize the Federal Government with Kubernetes
@@ -38,7 +38,7 @@ quote: >
-
+
"When there’s a regulatory change in an agency, or a legislative change in Congress, or an executive order that changes the way you do business, how do I deploy that and get that out to the people who need it rapidly? At the end of the day, that’s the problem we’re trying to help the government solve with tools like Kubernetes."

- JOSH BOYD, CHIEF TECHNOLOGIST AT BOOZ ALLEN HAMILTON

@@ -75,7 +75,7 @@ quote: > ​ ​ -
+
"Kubernetes alone enables a dramatic reduction in cost as resources are prioritized to the day’s event"

- MARTIN FOLKOFF, SENIOR LEAD TECHNOLOGIST AT BOOZ ALLEN HAMILTON

diff --git a/content/en/case-studies/bose/index.html b/content/en/case-studies/bose/index.html index d22de2187a..c77f416c13 100644 --- a/content/en/case-studies/bose/index.html +++ b/content/en/case-studies/bose/index.html @@ -11,7 +11,7 @@ quote: > The CNCF Landscape quickly explains what’s going on in all the different areas from storage to cloud providers to automation and so forth. This is our shopping cart to build a cloud infrastructure. We can go choose from the different aisles. --- -
+

CASE STUDY:
Bose: Supporting Rapid Development for Millions of IoT Products With Kubernetes

@@ -56,7 +56,7 @@ From the beginning, the team knew it wanted a microservices architecture and pla
-
+
"Everybody on the team thinks in terms of automation, leaning out the processes, getting things done as quickly as possible. When you step back and look at what it means for a 50-plus-year-old speaker company to have that sort of culture, it really is quite incredible, and I think the tools that we use and the foundation that we’ve built with them is a huge piece of that."

- Dylan O’Mahony, Cloud Architecture Manager, Bose @@ -70,7 +70,7 @@ From the beginning, the team knew it wanted a microservices architecture and pla
-
+
"The CNCF Landscape quickly explains what’s going on in all the different areas from storage to cloud providers to automation and so forth. This is our shopping cart to build a cloud infrastructure. We can go choose from the different aisles."

- Josh West, Lead Cloud Engineer, Bose
diff --git a/content/en/case-studies/capital-one/index.html b/content/en/case-studies/capital-one/index.html index 773db4869e..f95fb2acc7 100644 --- a/content/en/case-studies/capital-one/index.html +++ b/content/en/case-studies/capital-one/index.html @@ -5,7 +5,7 @@ cid: caseStudies css: /css/style_case_studies.css --- -
+

CASE STUDY:
Supporting Fast Decisioning Applications with Kubernetes

@@ -55,7 +55,7 @@ css: /css/style_case_studies.css
-
+
"We want to provide the tools in the same ecosystem, in a consistent way, rather than have a large custom snowflake ecosystem where every tool needs its own custom deployment. Kubernetes gives us the ability to bring all of these together, so the richness of the open source and even the license community dealing with big data can be corralled." @@ -69,7 +69,7 @@ css: /css/style_case_studies.css
-
+
With Kubernetes, "a team can come to us and we can have them up and running with a basic decisioning app in a fortnight, which before would have taken a whole quarter, if not longer. Kubernetes is a manifold productivity multiplier."
diff --git a/content/en/case-studies/cern/index.html b/content/en/case-studies/cern/index.html index 9bd7970245..48e965d7fb 100644 --- a/content/en/case-studies/cern/index.html +++ b/content/en/case-studies/cern/index.html @@ -7,7 +7,7 @@ css: /css/style_case_studies.css logo: cern_featured_logo.png --- -
+

CASE STUDY: CERN
CERN: Processing Petabytes of Data More Efficiently with Kubernetes

@@ -52,7 +52,7 @@ logo: cern_featured_logo.png
-
+
"Before, the tendency was always: ‘I need this, I get a couple of developers, and I implement it.’ Right now it’s ‘I need this, I’m sure other people also need this, so I’ll go and ask around.’ The CNCF is a good source because there’s a very large catalog of applications available. It’s very hard right now to justify developing a new product in-house. There is really no real reason to keep doing that. It’s much easier for us to try it out, and if we see it’s a good solution, we try to reach out to the community and start working with that community."

- Ricardo Rocha, Software Engineer, CERN @@ -66,7 +66,7 @@ logo: cern_featured_logo.png
-
+
"With Kubernetes, there’s a well-established technology and a big community that we can contribute to. It allows us to do our physics analysis without having to focus so much on the lower level software. This is just exciting. We are looking forward to keep contributing to the community and collaborating with everyone."

- Ricardo Rocha, Software Engineer, CERN
diff --git a/content/en/case-studies/chinaunicom/index.html b/content/en/case-studies/chinaunicom/index.html index 296b2ce1fc..4479d60e67 100644 --- a/content/en/case-studies/chinaunicom/index.html +++ b/content/en/case-studies/chinaunicom/index.html @@ -8,7 +8,7 @@ css: /css/style_case_studies.css featured: false --- -
+

CASE STUDY:
China Unicom: How China Unicom Leveraged Kubernetes to Boost Efficiency
and Lower IT Costs

@@ -51,7 +51,7 @@ featured: false
-
+
"We could never imagine we can achieve this scalability in such a short time."

- Chengyu Zhang, Group Leader of Platform Technology R&D, China Unicom @@ -65,7 +65,7 @@ featured: false
-
+
"This technology is relatively complicated, but as long as developers get used to it, they can enjoy all the benefits."

- Jie Jia, Member of Platform Technology R&D, China Unicom
diff --git a/content/en/case-studies/city-of-montreal/index.html b/content/en/case-studies/city-of-montreal/index.html index 151ce44b21..55378c649e 100644 --- a/content/en/case-studies/city-of-montreal/index.html +++ b/content/en/case-studies/city-of-montreal/index.html @@ -7,7 +7,7 @@ css: /css/style_case_studies.css featured: false --- -
+

CASE STUDY:
City of Montréal - How the City of Montréal Is Modernizing Its 30-Year-Old, Siloed Architecture with Kubernetes

@@ -50,7 +50,7 @@ featured: false The first step to modernize the architecture was containerization. “We based our effort on the new trends; we understood the benefits of immutability and deployments without downtime and such things,” says Solutions Architect Marc Khouzam. The team started with a small Docker farm with four or five servers, with Rancher for providing access to the Docker containers and their logs and Jenkins for deployment.
-
+
"Getting a project running in Kubernetes is entirely dependent on how long you need to program the actual software. It’s no longer dependent on deployment. Deployment is so fast that it’s negligible."

- MARC KHOUZAM, SOLUTIONS ARCHITECT, CITY OF MONTRÉAL @@ -65,7 +65,7 @@ featured: false Another important factor in the decision was vendor neutrality. “As a government entity, it is essential for us to be neutral in our selection of products and providers,” says Thibault. “The independence of the Cloud Native Computing Foundation from any company provides this.”
-
+
"Kubernetes has been great. It’s been stable, and it provides us with elasticity, resilience, and robustness. While re-architecting for Kubernetes, we also benefited from the monitoring and logging aspects, with centralized logging, Prometheus logging, and Grafana dashboards. We have enhanced visibility of what’s being deployed."

- MORGAN MARTINET, ENTERPRISE ARCHITECT, CITY OF MONTRÉAL
diff --git a/content/en/case-studies/denso/index.html b/content/en/case-studies/denso/index.html index 3ad0812d24..27ef1c77ed 100644 --- a/content/en/case-studies/denso/index.html +++ b/content/en/case-studies/denso/index.html @@ -12,7 +12,7 @@ quote: > --- -
+

CASE STUDY: Denso

How DENSO Is Fueling Development on the Vehicle Edge with Kubernetes
@@ -36,7 +36,7 @@ quote: > Critical layer features can take 2-3 years to implement in the traditional, waterfall model of development at DENSO. With the Kubernetes platform and agile methods, there’s a 2-month development cycle for non-critical software. Now, ten new applications are released a year, and a new prototype is introduced every week. "By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation," says Koizumi.
-
+
"Another disruptive innovation is coming, so to survive in this situation, we need to change our culture."

- SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO

@@ -79,7 +79,7 @@ quote: > -
+
"By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation."

- SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO

diff --git a/content/en/case-studies/ibm/index.html b/content/en/case-studies/ibm/index.html index 54e941c9cb..e9a78a9443 100644 --- a/content/en/case-studies/ibm/index.html +++ b/content/en/case-studies/ibm/index.html @@ -9,7 +9,7 @@ logo: ibm_featured_logo.svg featured: false --- -
+

CASE STUDY:
Building an Image Trust Service on Kubernetes with Notary and TUF

@@ -58,7 +58,7 @@ The availability of image signing "is a huge benefit to security-conscious custo
-
+
"Image signing is one key part of our Kubernetes container service offering, and our container registry team saw Notary as the de facto way to implement that capability in the current Docker and container ecosystem"

- Michael Hough, a software developer with the IBM Cloud Container Registry team
@@ -75,7 +75,7 @@ The availability of image signing "is a huge benefit to security-conscious custo
-
+
"With our IBM Cloud Kubernetes as-a-service offering and the admission controller we have made available, it allows both IBM services as well as customers of the IBM public cloud to use security policies to control service deployment."

- Michael Hough, a software developer with the IBM Cloud Container Registry team
diff --git a/content/en/case-studies/ing/index.html b/content/en/case-studies/ing/index.html index 6e2648a455..943daec2de 100644 --- a/content/en/case-studies/ing/index.html +++ b/content/en/case-studies/ing/index.html @@ -11,7 +11,7 @@ quote: > --- -
+

CASE STUDY:
Driving Banking Innovation with Cloud Native

@@ -58,7 +58,7 @@ quote: >
-
+
"We decided to standardize ING on a Kubernetes framework." Everything is run on premise due to banking regulations, he adds, but "we will be building an internal public cloud. We are trying to get on par with what public clouds are doing. That’s one of the reasons we got Kubernetes."

— Thijs Ebbers, Infrastructure Architect, ING @@ -72,7 +72,7 @@ quote: >
-
+
"We have to run the complete platform of services we need, many routing from different places. We need this Kubernetes framework for deploying the containers, with all those components, monitoring, logging. It’s complex."

— Onno Van der Voort, Infrastructure Architect, ING
diff --git a/content/en/case-studies/jd-com/index.html b/content/en/case-studies/jd-com/index.html index 636f226339..aed12fc54b 100644 --- a/content/en/case-studies/jd-com/index.html +++ b/content/en/case-studies/jd-com/index.html @@ -7,7 +7,7 @@ css: /css/style_case_studies.css featured: false --- -
+

CASE STUDY:
JD.com: How JD.com Pioneered Kubernetes for E-Commerce at Hyperscale

@@ -51,7 +51,7 @@ featured: false
-
+
"We customized Kubernetes and built a modern system on top of it. This entire ecosystem of Kubernetes plus our own optimizations have helped us save costs and time."

- HAIFENG LIU, CHIEF ARCHITECT, JD.com @@ -67,7 +67,7 @@ featured: false
-
+
"My advice is first you need to combine this technology with your own businesses, and the second is you need clear goals. You cannot just use the technology because others are using it. You need to consider your own objectives."

- HAIFENG LIU, CHIEF ARCHITECT, JD.com
diff --git a/content/en/case-studies/naic/index.html b/content/en/case-studies/naic/index.html index d40dd19c77..3deb91e480 100644 --- a/content/en/case-studies/naic/index.html +++ b/content/en/case-studies/naic/index.html @@ -9,7 +9,7 @@ logo: naic_featured_logo.png featured: false --- -
+

CASE STUDY:
A Culture and Technology Transition Enabled by Kubernetes

@@ -59,7 +59,7 @@ In addition, NAIC is onboarding teams to the new platform, and those teams have
-
+
"In our experience, vendor lock-in and tooling that is highly specific results in less resilient technology with fewer minds working to solve problems and grow the community."

- Dan Barker, Chief Enterprise Architect, NAIC
@@ -77,7 +77,7 @@ As for other CNCF projects, NAIC is using Prometheus on a small scale and hopes
-
+
"We knew that Kubernetes had become the de facto standard for container orchestration. Two major factors for selecting this were the three major cloud vendors hosting their own versions and having it hosted in a neutral party as fully open source."

- Dan Barker, Chief Enterprise Architect, NAIC
diff --git a/content/en/case-studies/nav/index.html b/content/en/case-studies/nav/index.html index d4cc89590d..bd606e7314 100644 --- a/content/en/case-studies/nav/index.html +++ b/content/en/case-studies/nav/index.html @@ -8,7 +8,7 @@ css: /css/style_case_studies.css featured: false --- -
+

CASE STUDY:
How A Startup Reduced Its Infrastructure Costs by 50% With Kubernetes

@@ -52,7 +52,7 @@ featured: false
-
+
"The community is absolutely vital: being able to pass ideas around, talk about a lot of the similar challenges that we’re all facing, and just get help. I like that we’re able to tackle the same problems for different reasons but help each other along the way."

- Travis Jeppson, Director of Engineering, Nav @@ -65,7 +65,7 @@ featured: false Jeppson’s four-person Engineering Services team got Kubernetes up and running in six months (they decided to use Kubespray to spin up clusters), and the full migration of Nav’s 25 microservices and one primary monolith was completed in another six months. “We couldn’t rewrite everything; we couldn’t stop,” he says. “We had to stay up, we had to stay available, and we had to have minimal amount of downtime. So we got really comfortable around our building pipeline, our metrics and logging, and then around Kubernetes itself: how to launch it, how to upgrade it, how to service it. And we moved little by little.”
-
+
“Kubernetes has brought so much value to Nav by allowing all of these new freedoms that we had just never had before.”

- Travis Jeppson, Director of Engineering, Nav
diff --git a/content/en/case-studies/nerdalize/index.html b/content/en/case-studies/nerdalize/index.html index 127d95c375..2756ce431c 100644 --- a/content/en/case-studies/nerdalize/index.html +++ b/content/en/case-studies/nerdalize/index.html @@ -6,7 +6,7 @@ cid: caseStudies css: /css/style_case_studies.css featured: false --- -
+

CASE STUDY:
Nerdalize: Providing Affordable and Sustainable Cloud Hosting with Kubernetes

@@ -47,7 +47,7 @@ featured: false After trying to develop its own scheduling system using another open source tool, Nerdalize found Kubernetes. “Kubernetes provided us with more functionality out of the gate,” says van der Veer.
-
+
“We always try to get a working version online first, like minimal viable products, and then move to stabilize that,” says van der Veer. “And I think that these kinds of day-two problems are now immediately solved. The rapid prototyping we saw internally is a very valuable aspect of Kubernetes.”

— AD VAN DER VEER, PRODUCT ENGINEER, NERDALIZE @@ -62,7 +62,7 @@ featured: false Not to mention the 40% cost savings. “Every euro that we have to invest for licensing of software that’s not open source comes from that 40%,” says van der Veer. If Nerdalize had used a non-open source orchestration platform instead of Kubernetes, “that would reduce our cost savings proposition to like 30%. Kubernetes directly allows us to have this business model and this strategic advantage.”
-
+
“One of our customers used to spend up to a day setting up the virtual machines, network and software every time they wanted to run a project in the cloud. On our platform, with Docker and Kubernetes, customers can have their projects running in a couple of minutes.”

- MAAIKE STOOPS, CUSTOMER EXPERIENCE QUEEN, NERDALIZE diff --git a/content/en/case-studies/netease/index.html b/content/en/case-studies/netease/index.html index a62ade486f..6cba5579ab 100644 --- a/content/en/case-studies/netease/index.html +++ b/content/en/case-studies/netease/index.html @@ -9,7 +9,7 @@ featured: false --- -
+

CASE STUDY:
How NetEase Leverages Kubernetes to Support Internet Business Worldwide

@@ -47,7 +47,7 @@ featured: false After considering building its own orchestration solution, NetEase decided to base its private cloud platform on Kubernetes. The fact that the technology came out of Google gave the team confidence that it could keep up with NetEase’s scale. “After our 2-to-3-month evaluation, we believed it could satisfy our needs,” says Feng.
-
+
"We leveraged the programmability of Kubernetes so that we can build a platform to satisfy the needs of our internal customers for upgrades and deployment."

- Feng Changjian, Architect for NetEase Cloud and Container Service, NetEase @@ -60,7 +60,7 @@ featured: false And the team is continuing to make improvements. For example, the e-commerce part of the business needs to leverage mixed deployments, which in the past required using two separate platforms: the infrastructure-as-a-service platform and the Kubernetes platform. More recently, NetEase has created a cross-platform application that enables using both with one-command deployment.
-
+
"As long as a company has a mature team and enough developers, I think Kubernetes is a very good technology that can help them."

- Li Lanqing, Kubernetes Developer, NetEase diff --git a/content/en/case-studies/newyorktimes/index.html b/content/en/case-studies/newyorktimes/index.html index c65b5fe883..53dbd06a55 100644 --- a/content/en/case-studies/newyorktimes/index.html +++ b/content/en/case-studies/newyorktimes/index.html @@ -5,7 +5,7 @@ cid: caseStudies css: /css/style_case_studies.css --- -
+

CASE STUDY:
The New York Times: From Print to the Web to Cloud Native

@@ -64,7 +64,7 @@ css: /css/style_case_studies.css
-
+
"We had some internal tooling that attempted to do what Kubernetes does for containers, but for VMs. We asked why are we building and maintaining these tools ourselves?"
@@ -79,7 +79,7 @@ css: /css/style_case_studies.css
-
+
"Right now, every team is running a small Kubernetes cluster, but it would be nice if we could all live in a larger ecosystem," says Kapadia. "Then we can harness the power of things like service mesh proxies that can actually do a lot of instrumentation between microservices, or service-to-service orchestration. Those are the new things that we want to experiment with as we go forward." diff --git a/content/en/case-studies/nokia/index.html b/content/en/case-studies/nokia/index.html index d8aaafc7f5..f824685327 100644 --- a/content/en/case-studies/nokia/index.html +++ b/content/en/case-studies/nokia/index.html @@ -8,7 +8,7 @@ logo: nokia_featured_logo.png --- -
+

CASE STUDY:
Nokia: Enabling 5G and DevOps at a Telecom Company with Kubernetes

@@ -51,7 +51,7 @@ logo: nokia_featured_logo.png
-
+
"Having the community and CNCF around Kubernetes is not only important for having a connection to other companies who are using Kubernetes and a forum where you can ask or discuss features of Kubernetes. But as a company who would like to contribute to Kubernetes, it was very important to have a CLA (Contributors License Agreement) which is connected to the CNCF and not to a particular company. That was a critical step for us to start contributing to Kubernetes and Helm."

- Gergely Csatari, Senior Open Source Engineer, Nokia @@ -65,7 +65,7 @@ logo: nokia_featured_logo.png
-
+
"Kubernetes opened the window to all of these open source projects instead of implementing everything in house. Our engineers can focus more on the application level, which is actually the thing what we are selling, and not on the infrastructure level. For us, the most important thing about Kubernetes is it allows us to focus on value creation of our business."

- Gergely Csatari, Senior Open Source Engineer, Nokia
diff --git a/content/en/case-studies/nordstrom/index.html b/content/en/case-studies/nordstrom/index.html index 5385c2473d..788453de35 100644 --- a/content/en/case-studies/nordstrom/index.html +++ b/content/en/case-studies/nordstrom/index.html @@ -5,7 +5,7 @@ cid: caseStudies css: /css/style_case_studies.css --- -
+

CASE STUDY:
Finding Millions in Potential Savings in a Tough Retail Climate @@ -60,7 +60,7 @@ css: /css/style_case_studies.css
-
+
"We made a bet that Kubernetes was going to take off, informed by early indicators of community support and project velocity, so we rebuilt our system with Kubernetes at the core,"
@@ -77,7 +77,7 @@ The benefits were immediate for the teams that came on board. "Teams running on
-
+
"Teams running on our Kubernetes cluster loved the fact that they had fewer issues to worry about. They didn’t need to manage infrastructure or operating systems," says Grigoriu. "Early adopters loved the declarative nature of Kubernetes. They loved the reduced surface area they had to deal with."
diff --git a/content/en/case-studies/northwestern-mutual/index.html b/content/en/case-studies/northwestern-mutual/index.html index dac0ef0d66..47b4bbc7be 100644 --- a/content/en/case-studies/northwestern-mutual/index.html +++ b/content/en/case-studies/northwestern-mutual/index.html @@ -5,7 +5,7 @@ cid: caseStudies css: /css/style_case_studies.css --- -
+

CASE STUDY:
Cloud Native at Northwestern Mutual @@ -22,7 +22,7 @@ css: /css/style_case_studies.css

Challenge

- In the spring of 2015, Northwestern Mutual acquired a fintech startup, LearnVest, and decided to take "Northwestern Mutual’s leading products and services and meld it with LearnVest’s digital experience and innovative financial planning platform," says Brad Williams, Director of Engineering for Client Experience, Northwestern Mutual. The company’s existing infrastructure had been optimized for batch workflows hosted on on-prem networks; deployments were very traditional, focused on following a process instead of providing deployment agility. "We had to build a platform that was elastically scalable, but also much more responsive, so we could quickly get data to the client website so our end-customers have the experience they expect," says Williams. + In the spring of 2015, Northwestern Mutual acquired a fintech startup, LearnVest, and decided to take "Northwestern Mutual’s leading products and services and meld it with LearnVest’s digital experience and innovative financial planning platform," says Brad Williams, Director of Engineering for Client Experience, Northwestern Mutual. The company’s existing infrastructure had been optimized for batch workflows hosted on on-prem networks; deployments were very traditional, focused on following a process instead of providing deployment agility. "We had to build a platform that was elastically scalable, but also much more responsive, so we could quickly get data to the client website so our end-customers have the experience they expect," says Williams.

Solution

The platform team came up with a plan for using the public cloud (AWS), Docker containers, and Kubernetes for orchestration. "Kubernetes gave us that base framework so teams can be very autonomous in what they’re building and deliver very quickly and frequently," says Northwestern Mutual Cloud Native Engineer Frank Greco Jr. The team also built and open-sourced Kanali, a Kubernetes-native API management tool that uses OpenTracing, Jaeger, and gRPC. @@ -53,7 +53,7 @@ In order to give the company’s 4.5 million clients the digital experience they
-
+
"Kubernetes has definitely been the right choice for us. It gave us that base framework so teams can be autonomous in what they’re building and deliver very quickly and frequently." @@ -63,12 +63,12 @@ In order to give the company’s 4.5 million clients the digital experience they
Williams and the rest of the platform team decided that the first step would be to start moving from private data centers to AWS. With a new microservice architecture in mind—and the freedom to implement what was best for the organization—they began using Docker containers. After looking into the various container orchestration options, they went with Kubernetes, even though it was still in beta at the time. "There was some debate whether we should build something ourselves, or just leverage that product and evolve with it," says Northwestern Mutual Cloud Native Engineer Frank Greco Jr. "Kubernetes has definitely been the right choice for us. It gave us that base framework so teams can be autonomous in what they’re building and deliver very quickly and frequently."

As early adopters, the team had to do a lot of work with Ansible scripts to stand up the cluster. "We had a lot of hard security requirements given the nature of our business," explains Bryan Pfremmer, App Platform Teams Manager, Northwestern Mutual. "We found ourselves running a configuration that very few other people ever tried." The client experience group was the first to use the new platform; today, a few hundred of the company’s 1,500 engineers are using it and more are eager to get on board. -The results have been dramatic. Before, infrastructure deployments could take two weeks; now, it is done in a matter of minutes. Now with a focus on Infrastructure automation, and self-service, "You can take an app to production in that same day if you want to," says Pfremmer. +The results have been dramatic. Before, infrastructure deployments could take two weeks; now, it is done in a matter of minutes. Now with a focus on Infrastructure automation, and self-service, "You can take an app to production in that same day if you want to," says Pfremmer.
-
+
"Now, developers have autonomy, they can use this whenever they want, however they want. It becomes more valuable the more instrumentation downstream that happens, as we mature in it."
diff --git a/content/en/case-studies/ocado/index.html b/content/en/case-studies/ocado/index.html index 6a930f945c..79ac9bf3a8 100644 --- a/content/en/case-studies/ocado/index.html +++ b/content/en/case-studies/ocado/index.html @@ -11,7 +11,7 @@ weight: 4 quote: > People at Ocado Technology have been quite amazed. They ask, ‘Can we do this on a Dev cluster?’ and 10 minutes later we have rolled out something that is deployed across the cluster. The speed from idea to implementation to deployment is amazing. --- -
+

CASE STUDY:
Ocado: Running Grocery Warehouses with a Cloud Native Platform

@@ -32,7 +32,7 @@ quote: >
- +

Impact

With Kubernetes, "the speed from idea to implementation to deployment is amazing," says Bryant. "I’ve seen features go from development to production inside of a week now. In the old world, a new application deployment could easily take over a month." And because there are no longer restrictive deployment windows in the warehouses, the rate of deployments has gone from as few as two per week to dozens per week. Ocado has also achieved cost savings because Kubernetes gives the team the ability to have more fine-grained resource allocation. Says DevOps Team Leader Kevin McCormack: "We have more confidence in the resource allocation/separation features of Kubernetes, so we have been able to migrate from around 10 fleet clusters to one Kubernetes cluster." The team also uses Prometheus and Grafana to visualize resource allocation, and makes the data available to developers. "The increased visibility offered by Prometheus means developers are more aware of what they are using and how their use impacts others, especially since we now have one shared cluster," says McCormack. "I’d estimate that we use about 15-25% less hardware resources to host the same applications in Kubernetes in our test environments." @@ -54,7 +54,7 @@ Bryant had already been using Kubernetes with +
"We were looking for a platform with wide adoption, and that was where the momentum was, the two paths converged, and we didn’t even go through any proof-of-concept stage. The Code for Life work served that purpose,"

- Kevin McCormack, DevOps Team Leader, Ocado
@@ -68,7 +68,7 @@ Bryant had already been using Kubernetes with +
"The unified API of Kubernetes means this is all in one place, and it’s one flow for approval and rollout. I’ve seen features go from development to production inside of a week now. In the old world, a new application deployment could easily take over a month."

- Mike Bryant, Platform Engineer, Ocado
diff --git a/content/en/case-studies/openAI/index.html b/content/en/case-studies/openAI/index.html index 040f704efa..1b95ec5f35 100644 --- a/content/en/case-studies/openAI/index.html +++ b/content/en/case-studies/openAI/index.html @@ -5,7 +5,7 @@ cid: caseStudies css: /css/style_case_studies.css --- -
+

CASE STUDY:
Launching and Scaling Up Experiments, Made Simple

@@ -56,7 +56,7 @@ css: /css/style_case_studies.css
-
+
OpenAI’s experiments take advantage of Kubernetes’ benefits, including portability. "Because Kubernetes provides a consistent API, we can move our research experiments very easily between clusters..." @@ -69,7 +69,7 @@ css: /css/style_case_studies.css
-
+
"One of our researchers who is working on a new distributed training system has been able to get his experiment running in two or three days," says Berner. "In a week or two he scaled it out to hundreds of GPUs. Previously, that would have easily been a couple of months of work."
diff --git a/content/en/case-studies/pearson/index.html b/content/en/case-studies/pearson/index.html index ddb567afb3..78f70228e5 100644 --- a/content/en/case-studies/pearson/index.html +++ b/content/en/case-studies/pearson/index.html @@ -8,7 +8,7 @@ featured: false quote: > We’re already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure. But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online. --- -
+

CASE STUDY:
Reinventing the World’s Largest Education Company With Kubernetes

@@ -47,7 +47,7 @@ quote: > The team adopted Kubernetes when it was still version 1.2 and are still going strong now on 1.7; they use Terraform and Ansible to deploy it on to basic AWS primitives. "We were trying to understand how we can create value for Pearson from this technology," says Ben Somogyi, Principal Architect for the Cloud Platforms. "It turned out that Kubernetes’ benefits are huge. We’re trying to help our applications development teams that use our platform go faster, so we filled that gap with a CI/CD pipeline that builds their images for them, standardizes them, patches everything up, allows them to deploy their different environments onto the cluster, and obfuscating the details of how difficult the work underneath the covers is."
-
+
"Your internal customers need to feel like they are choosing the very best option for them. We are experiencing this first hand in the growth of adoption. We are seeing triple-digit, year-on-year growth of the service."

— Chris Jackson, Director for Cloud Platforms & SRE at Pearson
@@ -60,7 +60,7 @@ quote: > Jackson estimates they’ve achieved a 15-20% boost in productivity for developer teams who adopt the platform. They also see a reduction in the number of customer-impacting incidents. Plus, says Jackson, "Teams who were previously limited to 1-2 releases per academic year can now ship code multiple times per day!"
-
+
"Teams who were previously limited to 1-2 releases per academic year can now ship code multiple times per day!"

— Chris Jackson, Director for Cloud Platforms & SRE at Pearson
diff --git a/content/en/case-studies/pingcap/index.html b/content/en/case-studies/pingcap/index.html index 637f891b3e..8d032c7a8b 100644 --- a/content/en/case-studies/pingcap/index.html +++ b/content/en/case-studies/pingcap/index.html @@ -7,7 +7,7 @@ css: /css/style_case_studies.css featured: false --- -
+

CASE STUDY:
PingCAP Bets on Cloud Native for Its TiDB Database Platform

@@ -52,7 +52,7 @@ featured: false Knowing that using a distributed system isn’t easy, the PingCAP team began looking for the right orchestration layer to help reduce some of that complexity for end users. Kubernetes had been on their radar for quite some time. "We knew Kubernetes had the promise of helping us solve our problems," says Xu. "We were just waiting for it to mature."
-
+
"With the governance process being so open, it’s not hard to find out what’s the latest development in the technology and community, or figure out who to reach out to if we have problems or issues."

- KEVIN XU, GENERAL MANAGER OF GLOBAL STRATEGY AND OPERATIONS, PINGCAP @@ -65,7 +65,7 @@ featured: false TiDB’s cloud native architecture consists of a stateless SQL layer (also called TiDB) and a persistent key-value storage layer that supports distributed transactions (TiKV, which is now in the CNCF Sandbox), which are loosely coupled. "You can scale both out or in depending on your computation and storage needs, and the two scaling processes can happen independent of each other," says Xu. The PingCAP team also built the TiDB Operator based on Kubernetes, which helps bootstrap a TiDB cluster on any cloud environment and simplifies and automates deployment, scaling, scheduling, upgrades, and maintenance. The company also recently previewed its fully-managed TiDB Cloud offering.
-
+
"A cloud native infrastructure will not only save you money and allow you to be more in control of the infrastructure resources you consume, but also empower new product innovation, new experience for your users, and new business possibilities. It’s both a cost reducer and a money maker."

- KEVIN XU, GENERAL MANAGER OF GLOBAL STRATEGY AND OPERATIONS, PINGCAP
diff --git a/content/en/case-studies/pinterest/index.html b/content/en/case-studies/pinterest/index.html index 0aa2381aa1..e4be7031bb 100644 --- a/content/en/case-studies/pinterest/index.html +++ b/content/en/case-studies/pinterest/index.html @@ -11,7 +11,7 @@ quote: > --- -
+

CASE STUDY:
Pinning Its Past, Present, and Future on Cloud Native

@@ -60,7 +60,7 @@ The first phase involved moving to Docker. "Pinterest has been heavily running o
-
+
"Though Kubernetes lacked certain things we wanted, we realized that by the time we get to productionizing many of those things, we’ll be able to leverage what the community is doing."

— MICHEAL BENEDICT, PRODUCT MANAGER FOR THE CLOUD AND THE DATA INFRASTRUCTURE GROUP AT PINTEREST
@@ -75,7 +75,7 @@ At the beginning of 2018, the team began onboarding its first use case into the
-
+
"So far it’s been good, especially the elasticity around how we can configure our Jenkins workloads on Kubernetes shared cluster. That is the win we were pushing for."

— MICHEAL BENEDICT, PRODUCT MANAGER FOR THE CLOUD AND THE DATA INFRASTRUCTURE GROUP AT PINTEREST
diff --git a/content/en/case-studies/prowise/index.html b/content/en/case-studies/prowise/index.html index 03bbc51173..2f0beda5ae 100644 --- a/content/en/case-studies/prowise/index.html +++ b/content/en/case-studies/prowise/index.html @@ -8,7 +8,7 @@ featured: false --- -
+

CASE STUDY:
Prowise: How Kubernetes is Enabling the Edtech Solution’s Global Expansion

@@ -50,7 +50,7 @@ featured: false The company’s existing infrastructure on Microsoft Azure Cloud was all on virtual machines, “a pretty traditional setup,” van den Bosch says. “We decided that we want some features in our software that requires being able to scale quickly, being able to deploy new applications and versions on different versions of different programming languages quickly. And we didn’t really want the hassle of trying to keep those servers in a particular state.”
-
+
"You don’t have to go all-in immediately. You can just take a few projects, a service, run it alongside your more traditional stack, and build it up from there. Kubernetes scales, so as you add applications and services to it, it will scale with you. You don’t have to do it all at once, and that’s really a secret to everything, but especially true to Kubernetes."

— VICTOR VAN DEN BOSCH, SENIOR DEVOPS ENGINEER, PROWISE @@ -67,7 +67,7 @@ featured: false With its first web-based applications now running in beta on Prowise’s Kubernetes platform, the team is seeing the benefits of rapid and smooth deployments. “The old way of deploying took half an hour of preparations and half an hour deploying it. With Kubernetes, it’s a couple of seconds,” says Senior Developer Bart Haalstra. As a result, adds van den Bosch, “We’ve gone from quarterly releases to a release every month in production. We’re pretty much deploying every hour or just when we find that a feature is ready for production. Before, our releases were mostly done on off-hours, where it couldn’t impact our customers, as our confidence the process itself was relatively low. With Kubernetes, we dare to deploy in the middle of a busy day with high confidence the deployment will succeed.”
-
+
"Kubernetes allows us to really consider the best tools for a problem. Want to have a full-fledged analytics application developed by a third party that is just right for your use case? Run it. Dabbling in machine learning and AI algorithms but getting tired of waiting days for training to complete? It takes only seconds to scale it. Got a stubborn developer that wants to use a programming language no one has heard of? Let him, if it runs in a container, of course. And all of that while your operations team/DevOps get to sleep at night."

- VICTOR VAN DEN BOSCH, SENIOR DEVOPS ENGINEER, PROWISE
diff --git a/content/en/case-studies/ricardo-ch/index.html b/content/en/case-studies/ricardo-ch/index.html index 62501c4f5b..2863ceac75 100644 --- a/content/en/case-studies/ricardo-ch/index.html +++ b/content/en/case-studies/ricardo-ch/index.html @@ -7,7 +7,7 @@ css: /css/style_case_studies.css featured: false --- -
+

CASE STUDY:
ricardo.ch: How Kubernetes Improved Velocity and DevOps Harmony

@@ -48,7 +48,7 @@ featured: false To address the velocity issue, ricardo.ch CTO Jeremy Seitz established a new software factory called EPD, which consists of 65 engineers, 7 product managers and 2 designers. "We brought these three departments together so that they can kind of streamline this and talk to each other much more closely," says Meury.
-
+
"Being in the End User Community demonstrates that we stand behind these technologies. In Switzerland, if all the companies see that ricardo.ch’s using it, I think that will help adoption. I also like that we’re connected to the other end users, so if there is a really heavy problem, I could go to the Slack channel, and say, ‘Hey, you guys…’ Like Reddit, Github and New York Times or whoever can give a recommendation on what to use here or how to solve that. So that’s kind of a superpower."

— CEDRIC MEURY, HEAD OF PLATFORM ENGINEERING, RICARDO.CH @@ -64,7 +64,7 @@ featured: false Meury estimates that half of the application has been migrated to Kubernetes. And the plan is to move everything to the Google Cloud Platform by the end of 2018. "We are still running some servers in our own data centers, but all of the containerization efforts and describing our services as Kubernetes manifests will allow us to quite easily make that shift," says Meury.
-
+
"One of the core moments was when a front-end developer asked me how to do a port forward from his laptop to a front-end application to debug, and I told him the command. And he was like, ‘Wow, that’s all I need to do?’ He was super excited and happy about it. That showed me that this power in the right hands can just accelerate development."

- CEDRIC MEURY, HEAD OF PLATFORM ENGINEERING, RICARDO.CH diff --git a/content/en/case-studies/slamtec/index.html b/content/en/case-studies/slamtec/index.html index 4a99d28fb3..86ebe15f91 100644 --- a/content/en/case-studies/slamtec/index.html +++ b/content/en/case-studies/slamtec/index.html @@ -7,7 +7,7 @@ css: /css/style_case_studies.css featured: false --- -
+

CASE STUDY:



@@ -47,7 +47,7 @@ featured: false After an evaluation of existing technologies, Ji’s team chose Kubernetes for orchestration. "CNCF brings quality assurance and a complete ecosystem for Kubernetes, which is very important for the wide application of Kubernetes," says Ji. Plus, "avoiding binding to an infrastructure technology or provider can help us ensure that our business is deployed and migrated in cross-regional environments, and can serve users all over the world."
-
+
"CNCF brings quality assurance and a complete ecosystem for Kubernetes, which is very important for the wide application of Kubernetes."

- BENNIU JI, DIRECTOR OF CLOUD COMPUTING BUSINESS DIVISION @@ -60,7 +60,7 @@ featured: false The company uses Harbor as a container image repository. "Harbor’s replication function helps us implement CI/CD on both private and public clouds," says Ji. "In addition, multi-project support, certification and policy configuration, and integration with Kubernetes are also excellent functions." Helm is also being used as a package manager, and the team is evaluating the Istio framework. "We’re very pleased that Kubernetes and these frameworks can be seamlessly integrated," Ji adds.
-
+
"Cloud native is suitable for microservice architecture, it’s suitable for fast iteration and agile development, and it has a relatively perfect ecosystem and active community."

- BENNIU JI, DIRECTOR OF CLOUD COMPUTING BUSINESS DIVISION
diff --git a/content/en/case-studies/slingtv/index.html b/content/en/case-studies/slingtv/index.html index a11527c2d9..349ed8c2de 100644 --- a/content/en/case-studies/slingtv/index.html +++ b/content/en/case-studies/slingtv/index.html @@ -11,7 +11,7 @@ quote: > --- -
+

CASE STUDY:
Sling TV: Marrying Kubernetes and AI to Enable Proper Web Scale

@@ -62,7 +62,7 @@ Led by the belief that “the cloud native architectures and patterns really giv
-
+
“We needed the flexibility to enable our use case versus just a simple orchestrater. Enabling our future in a way that did not give us vendor lock-in was also a key part of our strategy. I think that is part of the Rancher value proposition.”

— Brad Linder, Cloud Native & Big Data Evangelist for Sling TV
@@ -75,7 +75,7 @@ With the emphasis on common tooling, “We are getting to the place where we can
-
+
“We have to be able to react to changes and hiccups in the matrix. It is the foundation for our ability to deliver a high-quality service for our customers."

— Brad Linder, Cloud Native & Big Data Evangelist for Sling TV
diff --git a/content/en/case-studies/sos/index.html b/content/en/case-studies/sos/index.html index 64708a20f8..becf486413 100644 --- a/content/en/case-studies/sos/index.html +++ b/content/en/case-studies/sos/index.html @@ -8,7 +8,7 @@ logo: sos_featured_logo.png --- -
+

CASE STUDY:
SOS International: Using Kubernetes to Provide Emergency Assistance in a Connected World

@@ -56,7 +56,7 @@ logo: sos_featured_logo.png
-
+
"We have to deliver new digital services, but we also have to migrate the old stuff, and we have to transform our core systems into new systems built on top of this platform. One of the reasons why we chose this technology is that we could build new digital services while changing the old one."

- Martin Ahrentsen, Head of Enterprise Architecture, SOS International @@ -70,7 +70,7 @@ logo: sos_featured_logo.png
-
+
"During our onboarding, we could see that we were chosen by IT professionals because we provided the new technologies."

- Martin Ahrentsen, Head of Enterprise Architecture, SOS International
diff --git a/content/en/case-studies/spotify/index.html b/content/en/case-studies/spotify/index.html index 85e7fc1e86..63243b08f6 100644 --- a/content/en/case-studies/spotify/index.html +++ b/content/en/case-studies/spotify/index.html @@ -7,7 +7,7 @@ css: /css/style_case_studies.css featured: false --- -
+

CASE STUDY: Spotify
Spotify: An Early Adopter of Containers, Spotify Is Migrating from Homegrown Orchestration to Kubernetes

@@ -52,7 +52,7 @@ featured: false
-
+
"The community has been extremely helpful in getting us to work through all the technology much faster and much easier. And it’s helped us validate all the things we’re doing."

- Dave Zolotusky, Software Engineer, Infrastructure and Operations, Spotify @@ -67,7 +67,7 @@ featured: false
-
+
"We were able to use a lot of the Kubernetes APIs and extensibility features to support and interface with our legacy infrastructure, so the integration was straightforward and easy."

- James Wen, Site Reliability Engineer, Spotify
diff --git a/content/en/case-studies/squarespace/index.html b/content/en/case-studies/squarespace/index.html index d2b2a18c92..27340835f4 100644 --- a/content/en/case-studies/squarespace/index.html +++ b/content/en/case-studies/squarespace/index.html @@ -5,7 +5,7 @@ cid: caseStudies css: /css/style_case_studies.css --- -
+

CASE STUDY:
Squarespace: Gaining Productivity and Resilience with Kubernetes

@@ -51,7 +51,7 @@ Since Squarespace moved to Kubernetes, in conjunction with modernizing its netwo
-
+
After experimenting with another container orchestration platform and "breaking it in very painful ways," Lynch says, the team began experimenting with Kubernetes in mid-2016 and found that it "answered all the questions that we had." @@ -68,7 +68,7 @@ Since Squarespace moved to Kubernetes, in conjunction with modernizing its netwo
-
+
"We switched to Kubernetes, a new world....It allowed us to streamline our process, so we can now easily create an entire microservice project from templates," Lynch says. And the whole process takes only five minutes, an almost 85% reduction in time compared to their VM deployment.
diff --git a/content/en/case-studies/thredup/index.html b/content/en/case-studies/thredup/index.html index 0a35de2b1a..ad990356ff 100644 --- a/content/en/case-studies/thredup/index.html +++ b/content/en/case-studies/thredup/index.html @@ -7,7 +7,7 @@ css: /css/style_case_studies.css featured: false --- -
+

CASE STUDY:



@@ -49,7 +49,7 @@ featured: false "We wanted to make sure that our engineers could embrace the DevOps mindset as they built software," Homer says. "It was really important to us that they could own the life cycle from end to end, from conception at design, through shipping it and running it in production, from marketing to ecommerce, the user experience and our internal distribution center operations."
-
+
"Kubernetes enabled auto scaling in a seamless and easily manageable way on days like Black Friday. We no longer have to sit there adding instances, monitoring the traffic, doing a lot of manual work."

- CHRIS HOMER, COFOUNDER/CTO, THREDUP @@ -62,7 +62,7 @@ featured: false According to the infrastructure team, the key improvement was the consistent experience Kubernetes enabled for developers. "It lets developers work in the same environment that their application will be running in production," says Infrastructure Engineer Oleksandr Snagovskyi. Plus, "It became easier to test, easier to refine, and easier to deploy, because everything’s done automatically," says Infrastructure Engineer Oleksii Asiutin. "One of the main goals of our team is to make developers’ lives more comfortable, and we are achieving this with Kubernetes. They can experiment with existing applications and create new services, and do it all blazingly fast."
-
+
"One of the main goals of our team is to make developers’ lives more comfortable, and we are achieving this with Kubernetes. They can experiment with existing applications and create new services, and do it all blazingly fast."

- OLEKSII ASIUTIN, INFRASTRUCTURE ENGINEER, THREDUP
diff --git a/content/en/case-studies/vsco/index.html b/content/en/case-studies/vsco/index.html index 4ca7aa1bbc..c2ac2a2a72 100644 --- a/content/en/case-studies/vsco/index.html +++ b/content/en/case-studies/vsco/index.html @@ -7,7 +7,7 @@ css: /css/style_case_studies.css featured: false --- -
+

CASE STUDY:
VSCO: How a Mobile App Saved 70% on Its EC2 Bill with Cloud Native

@@ -48,7 +48,7 @@ featured: false
-
+
"Kubernetes seemed to have the strongest open source community around it, plus, we had started to standardize on a lot of the Google stack, with Go as a language, and gRPC for almost all communication between our own services inside the data center. So it seemed pretty natural for us to choose Kubernetes."

- MELINDA LU, ENGINEERING MANAGER FOR VSCO'S MACHINE LEARNING TEAM @@ -64,7 +64,7 @@ featured: false
-
+
"I've been really impressed seeing how our engineers have come up with really creative solutions to things by just combining a lot of Kubernetes primitives, exposing Kubernetes constructs as a service to our engineers as opposed to exposing higher order constructs has worked well for us. It lets you get familiar with the technology and do more interesting things with it."

- MELINDA LU, ENGINEERING MANAGER FOR VSCO’S MACHINE LEARNING TEAM
diff --git a/content/en/case-studies/woorank/index.html b/content/en/case-studies/woorank/index.html index aa41b7cb44..fbb86bdd24 100644 --- a/content/en/case-studies/woorank/index.html +++ b/content/en/case-studies/woorank/index.html @@ -8,7 +8,7 @@ featured: false --- -
+

CASE STUDY:
Woorank: How Kubernetes Helped a Startup Manage 50 Microservices with
12 Engineers—At 30% Less Cost

@@ -50,7 +50,7 @@ featured: false
-
+
"Cloud native technologies have brought to us a transparency on everything going on in our system, from the code to the server. It has brought huge cost savings and a better way of dealing with those costs and keeping them under control. And performance-wise, it has helped our team understand how we can make our code work better on the cloud native infrastructure."

— NILS DE MOOR, CTO/COFOUNDER, WOORANK @@ -66,7 +66,7 @@ featured: false The company’s number one concern was immediately erased: Maintaining Kubernetes is the responsibility of just one person on staff, and it’s not his fulltime job. Updating the old infrastructure “was always a pain,” says De Moor: It used to take two active working days, “and it was always a bit scary when we did that.” With Kubernetes, it’s just a matter of “a few hours of passively following the process.”
-
+
"When things fail and errors pop up, the system tries to heal itself, and that’s really, for us, the key reason to work with Kubernetes. It allowed us to set up certain testing frameworks to just be alerted when things go wrong, instead of having to look at whether everything went right. It’s made people’s lives much easier. It’s quite a big mindset change."

- NILS DE MOOR, CTO/COFOUNDER, WOORANK
diff --git a/content/en/case-studies/workiva/index.html b/content/en/case-studies/workiva/index.html index 95f323d5ae..1c09503bfb 100644 --- a/content/en/case-studies/workiva/index.html +++ b/content/en/case-studies/workiva/index.html @@ -11,7 +11,7 @@ quote: > With OpenTracing, my team was able to look at a trace and make optimization suggestions to another team without ever looking at their code. --- -
+

CASE STUDY:
Using OpenTracing to Help Pinpoint the Bottlenecks

@@ -30,12 +30,12 @@ quote: > Workiva offers a cloud-based platform for managing and reporting business data. This SaaS product, Wdesk, is used by more than 70 percent of the Fortune 500 companies. As the company made the shift from a monolith to a more distributed, microservice-based system, "We had a number of people working on this, all on different teams, so we needed to identify what the issues were and where the bottlenecks were," says Senior Software Architect MacLeod Broad. With back-end code running on Google App Engine, Google Compute Engine, as well as Amazon Web Services, Workiva needed a tracing system that was agnostic of platform. While preparing one of the company’s first products utilizing AWS, which involved a "sync and link" feature that linked data from spreadsheets built in the new application with documents created in the old application on Workiva’s existing system, Broad’s team found an ideal use case for tracing: There were circular dependencies, and optimizations often turned out to be micro-optimizations that didn’t impact overall speed.
- +

Solution

- Broad’s team introduced the platform-agnostic distributed tracing system OpenTracing to help them pinpoint the bottlenecks. + Broad’s team introduced the platform-agnostic distributed tracing system OpenTracing to help them pinpoint the bottlenecks.

Impact

Now used throughout the company, OpenTracing produced immediate results. Software Engineer Michael Davis reports: "Tracing has given us immediate, actionable insight into how to improve our service. Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix." @@ -61,14 +61,14 @@ The challenges faced by Broad’s team may sound familiar to other companies tha
-
+
"A tracing system can at a glance explain an architecture, narrow down a performance bottleneck and zero in on it, and generally just help direct an investigation at a high level. Being able to do that at a glance is much faster than at a meeting or with three days of debugging, and it’s a lot faster than never figuring out the problem and just moving on."
— MACLEOD BROAD, SENIOR SOFTWARE ARCHITECT AT WORKIVA
- + Simply put, it was an ideal use case for tracing. "A tracing system can at a glance explain an architecture, narrow down a performance bottleneck and zero in on it, and generally just help direct an investigation at a high level," says Broad. "Being able to do that at a glance is much faster than at a meeting or with three days of debugging, and it’s a lot faster than never figuring out the problem and just moving on."

With Workiva’s back-end code running on Google Compute Engine as well as App Engine and AWS, Broad knew that he needed a tracing system that was platform agnostic. "We were looking at different tracing solutions," he says, "and we decided that because it seemed to be a very evolving market, we didn’t want to get stuck with one vendor. So OpenTracing seemed like the cleanest way to avoid vendor lock-in on what backend we actually had to use."

Once they introduced OpenTracing into this first use case, Broad says, "The trace made it super obvious where the bottlenecks were." Even though everyone had assumed it was Workiva’s existing code that was slowing things down, that wasn’t exactly the case. "It looked like the existing code was slow only because it was reaching out to our next-generation services, and they were taking a very long time to service all those requests," says Broad. "On the waterfall graph you can see the exact same work being done on every request when it was calling back in. So every service request would look the exact same for every response being paged out. And then it was just a no-brainer of, ‘Why is it doing all this work again?’"

@@ -78,7 +78,7 @@ Using the insight OpenTracing gave them, "My team was able to look at a trace an
-
+
"We were looking at different tracing solutions and we decided that because it seemed to be a very evolving market, we didn’t want to get stuck with one vendor. So OpenTracing seemed like the cleanest way to avoid vendor lock-in on what backend we actually had to use."
— MACLEOD BROAD, SENIOR SOFTWARE ARCHITECT AT WORKIVA
@@ -90,7 +90,7 @@ Using the insight OpenTracing gave them, "My team was able to look at a trace an Some teams were won over quickly. "Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service," says Software Engineer Michael Davis. "Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix."

Most of Workiva’s major products are now traced using OpenTracing, with data pushed into Google StackDriver. Even the products that aren’t fully traced have some components and libraries that are.

Broad points out that because some of the engineers were working on App Engine and already had experience with the platform’s Appstats library for profiling performance, it didn’t take much to get them used to using OpenTracing. But others were a little more reluctant. "The biggest hindrance to adoption I think has been the concern about how much latency is introducing tracing [and StackDriver] going to cost," he says. "People are also very concerned about adding middleware to whatever they’re working on. Questions about passing the context around and how that’s done were common. A lot of our Go developers were fine with it, because they were already doing that in one form or another. Our Java developers were not super keen on doing that because they’d used other systems that didn’t require that."

-But the benefits clearly outweighed the concerns, and today, Workiva’s official policy is to use tracing." +But the benefits clearly outweighed the concerns, and today, Workiva’s official policy is to use tracing." In fact, Broad believes that tracing naturally fits in with Workiva’s existing logging and metrics systems. "This was the way we presented it internally, and also the way we designed our use," he says. "Our traces are logged in the exact same mechanism as our app metric and logging data, and they get pushed the exact same way. So we treat all that data exactly the same when it’s being created and when it’s being recorded. We have one internal library that we use for logging, telemetry, analytics and tracing." @@ -98,7 +98,7 @@ In fact, Broad believes that tracing naturally fits in with Workiva’s existing
- "Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service. Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix."
— Michael Davis, Software Engineer, Workiva + "Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service. Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix."
— Michael Davis, Software Engineer, Workiva
diff --git a/content/en/case-studies/ygrene/index.html b/content/en/case-studies/ygrene/index.html index 498dc0ec73..c07443249a 100644 --- a/content/en/case-studies/ygrene/index.html +++ b/content/en/case-studies/ygrene/index.html @@ -12,7 +12,7 @@ quote: > We had to change some practices and code, and the way things were built, but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That’s very fast for a finance company. --- -
+

CASE STUDY:
Ygrene: Using Cloud Native to Bring Security and Scalability to the Finance Industry

@@ -61,7 +61,7 @@ By 2017, deployments and scalability had become pain points. The company was uti
-
+
"CNCF has been an amazing incubator for so many projects. Now we look at its webpage regularly to find out if there are any new, awesome, high-quality projects we can implement into our stack. It’s actually become a hub for us for knowing what software we need to be looking at to make our systems more secure or more scalable."

— Austin Adams, Development Manager, Ygrene Energy Fund
@@ -78,7 +78,7 @@ Notary, in particular, "has been a godsend," says Adams. "We need to know that o
-
+
"We had to change some practices and code, and the way things were built," Adams says, "but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That’s very fast for a finance company."
diff --git a/layouts/case-studies/list.html b/layouts/case-studies/list.html index 05aca4ecb1..deec393953 100644 --- a/layouts/case-studies/list.html +++ b/layouts/case-studies/list.html @@ -3,11 +3,11 @@ {{ with site.Params.language_alternatives }} {{ range . }} {{ with (where $.Translations ".Lang" . ) }} - {{ $p := index . 0 }} + {{ $p := index . 0 }} {{ $pages = $pages | lang.Merge $p.Pages }} {{ end }} {{ end }} -{{ end }} +{{ end }} {{ $featured := (where $pages "Params.featured" true).ByWeight | first 4 }}
@@ -59,7 +59,7 @@ {{ end }} {{ end }} - {{ T + {{ T
diff --git a/static/css/style_amadeus.css b/static/css/style_amadeus.css index bf4d9e3c82..709ecb078d 100644 --- a/static/css/style_amadeus.css +++ b/static/css/style_amadeus.css @@ -50,7 +50,7 @@ h1 { padding-bottom:0.5%; padding-left:10%; font-size:32px; - background: url('/images/CaseStudy_amadeus_banner1.jpg'); + background: url('/images/case-studies/amadeus/banner1.jpg'); background-size:100% auto; background-repeat:no-repeat; } @@ -82,7 +82,7 @@ h1 { font-size:24px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_amadeus_banner3.jpg'); + background: url('/images/case-studies/amadeus/banner3.jpg'); background-size:100% auto; } @@ -95,7 +95,7 @@ h1 { font-size:24px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_amadeus_banner4.jpg'); + background: url('/images/case-studies/amadeus/banner4.jpg'); background-size:100% auto; } @@ -276,7 +276,7 @@ h4 { .logo { width:8%; } - + .col1 { width: 95%; padding-right:8%; @@ -310,7 +310,7 @@ h4 { padding-bottom:2%; padding-left:10%; font-size:18px; - background: url('/images/CaseStudy_amadeus_banner1.jpg'); + background: url('/images/case-studies/amadeus/banner1.jpg'); background-size:100% auto; } @@ -340,7 +340,7 @@ h4 { line-height:23px; width:90%; float:left; - background: url('/images/CaseStudy_amadeus_banner3.jpg'); + background: url('/images/case-studies/amadeus/banner3.jpg'); } .banner4 { @@ -354,7 +354,7 @@ h4 { line-height:24px; width:100%; float:left; - background: url('/images/CaseStudy_amadeus_banner4.jpg'); + background: url('/images/case-studies/amadeus/banner4.jpg'); } .banner5 { @@ -439,7 +439,7 @@ h4 { } /* End Media 910px */ @media screen and (max-width: 580px){ - + .header_logo { width:60%; margin-bottom:1%; @@ -448,6 +448,6 @@ h4 { } .banner1 { - background: url('/images/CaseStudy_amadeus_banner_mobile.jpg'); + background: url('/images/case-studies/amadeus/banner_mobile.jpg'); } } diff --git a/static/css/style_ancestry.css b/static/css/style_ancestry.css index d5ecfd98d7..9f93d22bb9 100644 --- a/static/css/style_ancestry.css +++ b/static/css/style_ancestry.css @@ -43,7 +43,7 @@ h1 { padding-bottom:0.5%; padding-left:10.9%; font-size:32px; - background: url('/images/CaseStudy_ancestry_banner1.jpg'); + background: url('/images/case-studies/ancestry/banner1.jpg'); background-size:100% auto; background-repeat:no-repeat; } @@ -74,7 +74,7 @@ h1 { font-size:21px; letter-spacing:0.03em; line-height:32px; - background: url('/images/CaseStudy_ancestry_banner3.jpg'); + background: url('/images/case-studies/ancestry/banner3.jpg'); background-size:100% auto; } @@ -87,7 +87,7 @@ h1 { font-size:21px; letter-spacing:0.03em; line-height:32px; - background: url('/images/CaseStudy_ancestry_banner4.jpg'); + background: url('/images/case-studies/ancestry/banner4.jpg'); background-size:100% auto; } @@ -263,7 +263,7 @@ h4 { .logo { width:8%; } - + .col1 { width: 90%; padding-left:5%; diff --git a/static/css/style_blablacar.css b/static/css/style_blablacar.css index e5e45c2284..ffa005ee71 100644 --- a/static/css/style_blablacar.css +++ b/static/css/style_blablacar.css @@ -47,7 +47,7 @@ h1 { padding-bottom:0.5%; padding-left:10%; font-size:34px; - background: url('/images/CaseStudy_blablacar_banner1.jpg'); + background: url('/images/case-studies/blablacar/banner1.jpg'); background-size:100% auto; background-repeat:no-repeat; } @@ -78,7 +78,7 @@ h1 { font-size:24px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_blablacar_banner3.jpg'); + background: url('/images/case-studies/blablacar/banner3.jpg'); background-size:100% auto; } @@ -91,7 +91,7 @@ h1 { font-size:25px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_blablacar_banner4.jpg'); + background: url('/images/case-studies/blablacar/banner4.jpg'); background-size:100% auto; } @@ -304,7 +304,7 @@ h4 { padding-bottom:2%; padding-left:10%; font-size:18px; - background: url('/images/CaseStudy_blablacar_banner1.jpg'); + background: url('/images/case-studies/blablacar/banner1.jpg'); background-size:100% auto; } @@ -334,7 +334,7 @@ h4 { line-height:23px; width:90%; float:left; - background: url('/images/CaseStudy_blablacar_banner3.jpg'); + background: url('/images/case-studies/blablacar/banner3.jpg'); } .banner4 { @@ -348,7 +348,7 @@ h4 { line-height:24px; width:100%; float:left; - background: url('/images/CaseStudy_blablacar_banner4.jpg'); + background: url('/images/case-studies/blablacar/banner4.jpg'); } .banner5 { @@ -441,6 +441,6 @@ h4 { } .banner1 { - background: url('/images/CaseStudy_blablacar_banner1_mobile.jpg'); + background: url('/images/case-studies/blablacar/banner1_mobile.jpg'); } } diff --git a/static/css/style_blackrock.css b/static/css/style_blackrock.css index 8c05f839a9..61d997ba41 100644 --- a/static/css/style_blackrock.css +++ b/static/css/style_blackrock.css @@ -47,7 +47,7 @@ h1 { padding-bottom:0.5%; padding-left:10%; font-size:32px; - background: url('/images/CaseStudy_blackrock_banner1.jpg'); + background: url('/images/case-studies/blackrock/banner1.jpg'); background-size:100% auto; background-repeat:no-repeat; } @@ -78,7 +78,7 @@ h1 { font-size:24px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_blackrock_banner3.jpg'); + background: url('/images/case-studies/blackrock/banner3.jpg'); background-size:100% auto; } @@ -91,7 +91,7 @@ h1 { font-size:24px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_blackrock_banner4.jpg'); + background: url('/images/case-studies/blackrock/banner4.jpg'); background-size:100% auto; } @@ -302,7 +302,7 @@ h4 { padding-bottom:2%; padding-left:10%; font-size:18px; - background: url('/images/CaseStudy_blackrock_banner1.jpg'); + background: url('/images/case-studies/blackrock/banner1.jpg'); background-size:100% auto; } @@ -332,7 +332,7 @@ h4 { line-height:23px; width:90%; float:left; - background: url('/images/CaseStudy_blackrock_banner3.jpg'); + background: url('/images/case-studies/blackrock/banner3.jpg'); } .banner4 { @@ -346,7 +346,7 @@ h4 { line-height:24px; width:100%; float:left; - background: url('/images/CaseStudy_blackrock_banner4.jpg'); + background: url('/images/case-studies/blackrock/banner4.jpg'); } .banner5 { @@ -431,7 +431,7 @@ h4 { } /* End Media 910px */ @media screen and (max-width: 580px){ - + .header_logo { width:60%; margin-bottom:1%; diff --git a/static/css/style_box.css b/static/css/style_box.css index 90c4e8ea00..9ca316ed1e 100644 --- a/static/css/style_box.css +++ b/static/css/style_box.css @@ -44,7 +44,7 @@ h1 { padding-bottom:0.5%; padding-left:9.9%; font-size:32px; - background: url('/images/CaseStudy_box_banner1.jpg'); + background: url('/images/case-studies/box/banner1.jpg'); background-size:100% auto; background-repeat:no-repeat; } @@ -72,7 +72,7 @@ h1 { font-size:21px; letter-spacing:0.03em; line-height:32px; - background: url('/images/CaseStudy_box_banner3.jpg'); + background: url('/images/case-studies/box/banner3.jpg'); background-size:100% auto; } @@ -85,7 +85,7 @@ h1 { font-size:21px; letter-spacing:0.03em; line-height:32px; - background: url('/images/CaseStudy_box_banner4.jpg'); + background: url('/images/case-studies/box/banner4.jpg'); background-size:100% auto; } @@ -256,7 +256,7 @@ h4 { .logo { width:8%; } - + .col1 { width: 100%; padding-left:5%; @@ -292,7 +292,7 @@ h4 { padding-bottom:2%; padding-left:10%; font-size:18px; - background: url('/images/CaseStudy_box_banner1.jpg'); + background: url('/images/case-studies/box/banner1.jpg'); background-size:100% auto; } @@ -323,7 +323,7 @@ h4 { line-height:24px; width:100%; float:left; - background: url('/images/CaseStudy_box_banner3.jpg'); + background: url('/images/case-studies/box/banner3.jpg'); } .banner4 { @@ -337,7 +337,7 @@ h4 { line-height:24px; width:100%; float:left; - background: url('/images/CaseStudy_box_banner4.jpg'); + background: url('/images/case-studies/box/banner4.jpg'); } .banner5 { diff --git a/static/css/style_buffer.css b/static/css/style_buffer.css index 0928365b13..299a1aea21 100644 --- a/static/css/style_buffer.css +++ b/static/css/style_buffer.css @@ -45,7 +45,7 @@ h1 { padding-bottom:0.5%; padding-left:9.9%; font-size:32px; - background: url('/images/CaseStudy_buffer_banner3.jpg'); + background: url('/images/case-studies/buffer/banner3.jpg'); background-size:100% auto; background-repeat:no-repeat; } @@ -75,7 +75,7 @@ h1 { font-size:21px; letter-spacing:0.03em; line-height:32px; - background: url('/images/CaseStudy_buffer_banner1.jpg'); + background: url('/images/case-studies/buffer/banner1.jpg'); background-size:100% auto; } @@ -88,7 +88,7 @@ h1 { font-size:21px; letter-spacing:0.03em; line-height:32px; - background: url('/images/CaseStudy_buffer_banner4.jpg'); + background: url('/images/case-studies/buffer/banner4.jpg'); background-size:100% auto; } @@ -259,7 +259,7 @@ h4 { .logo { width:8%; } - + .col1 { width: 100%; padding-left:5%; @@ -295,7 +295,7 @@ h4 { padding-bottom:2%; padding-left:10%; font-size:18px; - background: url('/images/CaseStudy_buffer_banner3.jpg'); + background: url('/images/case-studies/buffer/banner3.jpg'); background-size:100% auto; } @@ -328,7 +328,7 @@ h4 { padding-left:15%; padding-right:10%; float:left; - background: url('/images/CaseStudy_buffer_banner1.jpg'); + background: url('/images/case-studies/buffer/banner1.jpg'); } .banner4 { @@ -342,7 +342,7 @@ h4 { line-height:24px; width:100%; float:left; - background: url('/images/CaseStudy_buffer_banner4.jpg'); + background: url('/images/case-studies/buffer/banner4.jpg'); } .banner5 { diff --git a/static/css/style_crowdfire.css b/static/css/style_crowdfire.css index a03bfb4bd5..3e153e1006 100644 --- a/static/css/style_crowdfire.css +++ b/static/css/style_crowdfire.css @@ -47,7 +47,7 @@ h1 { padding-bottom:0.5%; padding-left:10%; font-size:32px; - background: url('/images/CaseStudy_crowdfire_banner1.jpg'); + background: url('/images/case-studies/crowdfire/banner1.jpg'); background-size:100% auto; background-repeat:no-repeat; } @@ -78,7 +78,7 @@ h1 { font-size:24px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_crowdfire_banner3.jpg'); + background: url('/images/case-studies/crowdfire/banner3.jpg'); background-size:100% auto; } @@ -91,7 +91,7 @@ h1 { font-size:24px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_crowdfire_banner4.jpg'); + background: url('/images/case-studies/crowdfire/banner4.jpg'); background-size:100% auto; } @@ -268,7 +268,7 @@ h4 { .logo { width:8%; } - + .col1 { width: 95%; padding-right:8%; @@ -302,7 +302,7 @@ h4 { padding-bottom:2%; padding-left:10%; font-size:18px; - background: url('/images/CaseStudy_crowdfire_banner1.jpg'); + background: url('/images/case-studies/crowdfire/banner1.jpg'); background-size:100% auto; } @@ -332,7 +332,7 @@ h4 { line-height:23px; width:90%; float:left; - background: url('/images/CaseStudy_crowdfire_banner3.jpg'); + background: url('/images/case-studies/crowdfire/banner3.jpg'); } .banner4 { @@ -346,7 +346,7 @@ h4 { line-height:24px; width:100%; float:left; - background: url('/images/CaseStudy_crowdfire_banner4.jpg'); + background: url('/images/case-studies/crowdfire/banner4.jpg'); } .banner5 { @@ -441,6 +441,6 @@ h4 { } .banner1 { - background: url('/images/CaseStudy_crowdfire_banner1.jpg'); + background: url('/images/case-studies/crowdfire/banner1.jpg'); } } diff --git a/static/css/style_golfnow.css b/static/css/style_golfnow.css index b33d3cfdab..abd875080d 100644 --- a/static/css/style_golfnow.css +++ b/static/css/style_golfnow.css @@ -18,7 +18,7 @@ body { } footer { - background-color:#ffffff !important; + background-color:#ffffff !important; } h1 { @@ -44,7 +44,7 @@ h1 { padding-bottom:0.5%; padding-left:9.9%; font-size:32px; - background: url('/images/CaseStudy_golfnow_banner1.jpg'); + background: url('/images/case-studies/golfnow/banner1.jpg'); background-size:100% auto; background-repeat:no-repeat; } @@ -74,7 +74,7 @@ h1 { font-size:21px; letter-spacing:0.03em; line-height:32px; - background: url('/images/CaseStudy_golfnow_banner3.jpg'); + background: url('/images/case-studies/golfnow/banner3.jpg'); background-size:100% auto; } @@ -87,7 +87,7 @@ h1 { font-size:21px; letter-spacing:0.03em; line-height:32px; - background: url('/images/CaseStudy_golfnow_banner4.jpg'); + background: url('/images/case-studies/golfnow/banner4.jpg'); background-size:100% auto; } @@ -294,7 +294,7 @@ h4 { padding-bottom:2%; padding-left:10%; font-size:18px; - background: url('/images/CaseStudy_golfnow_banner1.jpg'); + background: url('/images/case-studies/golfnow/banner1.jpg'); background-size:100% auto; } @@ -327,7 +327,7 @@ h4 { padding-left:15%; padding-right:10%; float:left; - background: url('/images/CaseStudy_golfnow_banner3.jpg'); + background: url('/images/case-studies/golfnow/banner3.jpg'); } .banner4 { @@ -341,7 +341,7 @@ h4 { line-height:24px; width:100%; float:left; - background: url('/images/CaseStudy_golfnow_banner4.jpg'); + background: url('/images/case-studies/golfnow/banner4.jpg'); } .banner5 { @@ -402,7 +402,7 @@ h4 { text-align:center; color:#ffffff; } - + .fullcol { margin-top:6%; } diff --git a/static/css/style_haufegroup.css b/static/css/style_haufegroup.css index b472a3d57f..b8cee6ca6e 100644 --- a/static/css/style_haufegroup.css +++ b/static/css/style_haufegroup.css @@ -47,7 +47,7 @@ h1 { padding-bottom:0.5%; padding-left:10%; font-size:32px; - background: url('/images/CaseStudy_haufegroup_banner1.jpg'); + background: url('/images/case-studies/haufegroup/banner1.jpg'); background-size:100% auto; background-repeat:no-repeat; } @@ -78,7 +78,7 @@ h1 { font-size:24px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_haufegroup_banner3.jpg'); + background: url('/images/case-studies/haufegroup/banner3.jpg'); background-size:100% auto; } @@ -91,7 +91,7 @@ h1 { font-size:24px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_haufegroup_banner4.jpg'); + background: url('/images/case-studies/haufegroup/banner4.jpg'); background-size:100% auto; } @@ -302,7 +302,7 @@ h4 { padding-bottom:2%; padding-left:10%; font-size:18px; - background: url('/images/CaseStudy_haufegroup_banner1.jpg'); + background: url('/images/case-studies/haufegroup/banner1.jpg'); background-size:100% auto; } @@ -332,7 +332,7 @@ h4 { line-height:23px; width:90%; float:left; - background: url('/images/CaseStudy_haufegroup_banner3.jpg'); + background: url('/images/case-studies/haufegroup/banner3.jpg'); } .banner4 { @@ -346,7 +346,7 @@ h4 { line-height:24px; width:100%; float:left; - background: url('/images/CaseStudy_haufegroup_banner4.jpg'); + background: url('/images/case-studies/haufegroup/banner4.jpg'); } .banner5 { @@ -439,6 +439,6 @@ h4 { } .banner1 { - background: url('/images/CaseStudy_haufegroup_banner1.jpg'); + background: url('/images/case-studies/haufegroup/banner1.jpg'); } } diff --git a/static/css/style_huawei.css b/static/css/style_huawei.css index 05c4f30ee0..a1d449e621 100644 --- a/static/css/style_huawei.css +++ b/static/css/style_huawei.css @@ -47,7 +47,7 @@ h1 { padding-bottom:0.5%; padding-left:10%; font-size:32px; - background: url('/images/CaseStudy_huawei_banner1.jpg'); + background: url('/images/case-studies/huawei/banner1.jpg'); background-size:100% auto; background-repeat:no-repeat; } @@ -78,7 +78,7 @@ h1 { font-size:24px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_huawei_banner3.jpg'); + background: url('/images/case-studies/huawei/banner3.jpg'); background-size:100% auto; } @@ -91,7 +91,7 @@ h1 { font-size:24px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_huawei_banner4.jpg'); + background: url('/images/case-studies/huawei/banner4.jpg'); background-size:100% auto; } @@ -302,7 +302,7 @@ h4 { padding-bottom:2%; padding-left:10%; font-size:18px; - background: url('/images/CaseStudy_huawei_banner1.jpg'); + background: url('/images/case-studies/huawei/banner1.jpg'); background-size:100% auto; } @@ -332,7 +332,7 @@ h4 { line-height:23px; width:90%; float:left; - background: url('/images/CaseStudy_huawei_banner3.jpg'); + background: url('/images/case-studies/huawei/banner3.jpg'); } .banner4 { @@ -346,7 +346,7 @@ h4 { line-height:24px; width:100%; float:left; - background: url('/images/CaseStudy_huawei_banner4.jpg'); + background: url('/images/case-studies/huawei/banner4.jpg'); } .banner5 { @@ -439,6 +439,6 @@ h4 { } .banner1 { - background: url('/images/CaseStudy_blablacar_banner1_mobile.jpg'); + background: url('/images/case-studies/blablacar/banner1_mobile.jpg'); } } diff --git a/static/css/style_peardeck.css b/static/css/style_peardeck.css index 610dc29b85..0ec3a55bef 100644 --- a/static/css/style_peardeck.css +++ b/static/css/style_peardeck.css @@ -44,7 +44,7 @@ h1 { padding-bottom:0.5%; padding-left:10%; font-size:32px; - background: url('/images/CaseStudy_peardeck_banner3.jpg'); + background: url('/images/case-studies/peardeck/banner3.jpg'); background-size:100% auto; background-repeat:no-repeat; } @@ -74,7 +74,7 @@ h1 { font-size:21px; letter-spacing:0.03em; line-height:32px; - background: url('/images/CaseStudy_peardeck_banner1.jpg'); + background: url('/images/case-studies/peardeck/banner1.jpg'); background-size:100% auto; } @@ -87,7 +87,7 @@ h1 { font-size:21px; letter-spacing:0.03em; line-height:32px; - background: url('/images/CaseStudy_peardeck_banner2.jpg'); + background: url('/images/case-studies/peardeck/banner2.jpg'); background-size:100% auto; } @@ -294,7 +294,7 @@ h4 { padding-bottom:2%; padding-left:10%; font-size:18px; - background: url('/images/CaseStudy_peardeck_banner1.jpg'); + background: url('/images/case-studies/peardeck/banner1.jpg'); background-size:100% auto; } @@ -327,7 +327,7 @@ h4 { padding-left:15%; padding-right:10%; float:left; - background: url('/images/CaseStudy_peardeck_banner3.jpg'); + background: url('/images/case-studies/peardeck/banner3.jpg'); } .banner4 { @@ -341,7 +341,7 @@ h4 { line-height:24px; width:100%; float:left; - background: url('/images/CaseStudy_peardeck_banner2.jpg'); + background: url('/images/case-studies/peardeck/banner2.jpg'); } .banner5 { diff --git a/static/css/style_wink.css b/static/css/style_wink.css index 226426d233..9dce4c391d 100644 --- a/static/css/style_wink.css +++ b/static/css/style_wink.css @@ -40,7 +40,7 @@ h1 { padding-bottom:0.5%; padding-left:9.9%; font-size:32px; - background: url('/images/CaseStudy_wink_banner1.jpg'); + background: url('/images/case-studies/wink/banner1.jpg'); background-size:100% auto; background-repeat:no-repeat; } @@ -70,7 +70,7 @@ h1 { font-size:21px; letter-spacing:0.03em; line-height:32px; - background: url('/images/CaseStudy_wink_banner3.jpg'); + background: url('/images/case-studies/wink/banner3.jpg'); background-size:100% auto; } @@ -83,7 +83,7 @@ h1 { font-size:21px; letter-spacing:0.03em; line-height:32px; - background: url('/images/CaseStudy_wink_banner4.jpg'); + background: url('/images/case-studies/wink/banner4.jpg'); background-size:100% auto; } @@ -290,7 +290,7 @@ h4 { padding-bottom:2%; padding-left:10%; font-size:18px; - background: url('/images/CaseStudy_wink_banner1.jpg'); + background: url('/images/case-studies/wink/banner1.jpg'); background-size:100% auto; } @@ -323,7 +323,7 @@ h4 { padding-left:15%; padding-right:10%; float:left; - background: url('/images/CaseStudy_wink_banner3.jpg'); + background: url('/images/case-studies/wink/banner3.jpg'); } .banner4 { @@ -337,7 +337,7 @@ h4 { line-height:24px; width:100%; float:left; - background: url('/images/CaseStudy_wink_banner4.jpg'); + background: url('/images/case-studies/wink/banner4.jpg'); } .banner5 { diff --git a/static/css/style_zalando.css b/static/css/style_zalando.css index c962f4f76d..a7e9cd4397 100644 --- a/static/css/style_zalando.css +++ b/static/css/style_zalando.css @@ -47,7 +47,7 @@ h1 { padding-bottom:0.5%; padding-left:10%; font-size:32px; - background: url('/images/CaseStudy_zalando_banner1.jpg'); + background: url('/images/case-studies/zalando/banner1.jpg'); background-size:100% auto; background-repeat:no-repeat; } @@ -78,7 +78,7 @@ h1 { font-size:24px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_zalando_banner3.jpg'); + background: url('/images/case-studies/zalando/banner3.jpg'); background-size:100% auto; } @@ -91,7 +91,7 @@ h1 { font-size:24px; letter-spacing:0.03em; line-height:34px; - background: url('/images/CaseStudy_zalando_banner4.jpg'); + background: url('/images/case-studies/zalando/banner4.jpg'); background-size:100% auto; } @@ -302,7 +302,7 @@ h4 { padding-bottom:2%; padding-left:10%; font-size:18px; - background: url('/images/CaseStudy_zalando_banner1.jpg'); + background: url('/images/case-studies/zalando/banner1.jpg'); background-size:100% auto; } @@ -332,7 +332,7 @@ h4 { line-height:23px; width:90%; float:left; - background: url('/images/CaseStudy_zalando_banner3.jpg'); + background: url('/images/case-studies/zalando/banner3.jpg'); } .banner4 { @@ -346,7 +346,7 @@ h4 { line-height:24px; width:100%; float:left; - background: url('/images/CaseStudy_zalando_banner4.jpg'); + background: url('/images/case-studies/zalando/banner4.jpg'); } .banner5 { diff --git a/static/images/CaseStudy_adform_banner1.jpg b/static/images/case-studies/adform/banner1.jpg similarity index 100% rename from static/images/CaseStudy_adform_banner1.jpg rename to static/images/case-studies/adform/banner1.jpg diff --git a/static/images/CaseStudy_adform_banner3.jpg b/static/images/case-studies/adform/banner3.jpg similarity index 100% rename from static/images/CaseStudy_adform_banner3.jpg rename to static/images/case-studies/adform/banner3.jpg diff --git a/static/images/CaseStudy_adform_banner4.jpg b/static/images/case-studies/adform/banner4.jpg similarity index 100% rename from static/images/CaseStudy_adform_banner4.jpg rename to static/images/case-studies/adform/banner4.jpg diff --git a/static/images/Adidas1.png b/static/images/case-studies/adidas/banner1.png similarity index 100% rename from static/images/Adidas1.png rename to static/images/case-studies/adidas/banner1.png diff --git a/static/images/Adidas2.png b/static/images/case-studies/adidas/banner2.png similarity index 100% rename from static/images/Adidas2.png rename to static/images/case-studies/adidas/banner2.png diff --git a/static/images/Adidas3.png b/static/images/case-studies/adidas/banner3.png similarity index 100% rename from static/images/Adidas3.png rename to static/images/case-studies/adidas/banner3.png diff --git a/static/images/CaseStudy_amadeus_banner1.jpg b/static/images/case-studies/amadeus/banner1.jpg similarity index 100% rename from static/images/CaseStudy_amadeus_banner1.jpg rename to static/images/case-studies/amadeus/banner1.jpg diff --git a/static/images/CaseStudy_amadeus_banner_mobile.jpg b/static/images/case-studies/amadeus/banner1_mobile.jpg similarity index 100% rename from static/images/CaseStudy_amadeus_banner_mobile.jpg rename to static/images/case-studies/amadeus/banner1_mobile.jpg diff --git a/static/images/CaseStudy_amadeus_banner3.jpg b/static/images/case-studies/amadeus/banner3.jpg similarity index 100% rename from static/images/CaseStudy_amadeus_banner3.jpg rename to static/images/case-studies/amadeus/banner3.jpg diff --git a/static/images/CaseStudy_amadeus_banner4.jpg b/static/images/case-studies/amadeus/banner4.jpg similarity index 100% rename from static/images/CaseStudy_amadeus_banner4.jpg rename to static/images/case-studies/amadeus/banner4.jpg diff --git a/static/images/CaseStudy_ancestry_banner1.jpg b/static/images/case-studies/ancestry/banner1.jpg similarity index 100% rename from static/images/CaseStudy_ancestry_banner1.jpg rename to static/images/case-studies/ancestry/banner1.jpg diff --git a/static/images/CaseStudy_ancestry_banner3.jpg b/static/images/case-studies/ancestry/banner3.jpg similarity index 100% rename from static/images/CaseStudy_ancestry_banner3.jpg rename to static/images/case-studies/ancestry/banner3.jpg diff --git a/static/images/CaseStudy_ancestry_banner4.jpg b/static/images/case-studies/ancestry/banner4.jpg similarity index 100% rename from static/images/CaseStudy_ancestry_banner4.jpg rename to static/images/case-studies/ancestry/banner4.jpg diff --git a/static/images/CaseStudy_antfinancial_banner1.jpg b/static/images/case-studies/antfinancial/banner1.jpg similarity index 100% rename from static/images/CaseStudy_antfinancial_banner1.jpg rename to static/images/case-studies/antfinancial/banner1.jpg diff --git a/static/images/CaseStudy_antfinancial_banner3.jpg b/static/images/case-studies/antfinancial/banner3.jpg similarity index 100% rename from static/images/CaseStudy_antfinancial_banner3.jpg rename to static/images/case-studies/antfinancial/banner3.jpg diff --git a/static/images/CaseStudy_antfinancial_banner4.jpg b/static/images/case-studies/antfinancial/banner4.jpg similarity index 100% rename from static/images/CaseStudy_antfinancial_banner4.jpg rename to static/images/case-studies/antfinancial/banner4.jpg diff --git a/static/images/CaseStudy_appdirect_banner1.jpg b/static/images/case-studies/appdirect/banner1.jpg similarity index 100% rename from static/images/CaseStudy_appdirect_banner1.jpg rename to static/images/case-studies/appdirect/banner1.jpg diff --git a/static/images/CaseStudy_appdirect_banner3.jpg b/static/images/case-studies/appdirect/banner3.jpg similarity index 100% rename from static/images/CaseStudy_appdirect_banner3.jpg rename to static/images/case-studies/appdirect/banner3.jpg diff --git a/static/images/CaseStudy_appdirect_banner4.jpg b/static/images/case-studies/appdirect/banner4.jpg similarity index 100% rename from static/images/CaseStudy_appdirect_banner4.jpg rename to static/images/case-studies/appdirect/banner4.jpg diff --git a/static/images/Babylon1.jpg b/static/images/case-studies/babylon/banner1.jpg similarity index 100% rename from static/images/Babylon1.jpg rename to static/images/case-studies/babylon/banner1.jpg diff --git a/static/images/Babylon2.jpg b/static/images/case-studies/babylon/banner2.jpg similarity index 100% rename from static/images/Babylon2.jpg rename to static/images/case-studies/babylon/banner2.jpg diff --git a/static/images/babylon4.jpg b/static/images/case-studies/babylon/banner4.jpg similarity index 100% rename from static/images/babylon4.jpg rename to static/images/case-studies/babylon/banner4.jpg diff --git a/static/images/CaseStudy_blablacar_banner1.jpg b/static/images/case-studies/blablacar/banner1.jpg similarity index 100% rename from static/images/CaseStudy_blablacar_banner1.jpg rename to static/images/case-studies/blablacar/banner1.jpg diff --git a/static/images/CaseStudy_blablacar_banner1_mobile.jpg b/static/images/case-studies/blablacar/banner1_mobile.jpg similarity index 100% rename from static/images/CaseStudy_blablacar_banner1_mobile.jpg rename to static/images/case-studies/blablacar/banner1_mobile.jpg diff --git a/static/images/CaseStudy_blablacar_banner3.jpg b/static/images/case-studies/blablacar/banner3.jpg similarity index 100% rename from static/images/CaseStudy_blablacar_banner3.jpg rename to static/images/case-studies/blablacar/banner3.jpg diff --git a/static/images/CaseStudy_blablacar_banner4.jpg b/static/images/case-studies/blablacar/banner4.jpg similarity index 100% rename from static/images/CaseStudy_blablacar_banner4.jpg rename to static/images/case-studies/blablacar/banner4.jpg diff --git a/static/images/CaseStudy_blackrock_banner1.jpg b/static/images/case-studies/blackrock/banner1.jpg similarity index 100% rename from static/images/CaseStudy_blackrock_banner1.jpg rename to static/images/case-studies/blackrock/banner1.jpg diff --git a/static/images/CaseStudy_blackrock_banner3.jpg b/static/images/case-studies/blackrock/banner3.jpg similarity index 100% rename from static/images/CaseStudy_blackrock_banner3.jpg rename to static/images/case-studies/blackrock/banner3.jpg diff --git a/static/images/CaseStudy_blackrock_banner4.jpg b/static/images/case-studies/blackrock/banner4.jpg similarity index 100% rename from static/images/CaseStudy_blackrock_banner4.jpg rename to static/images/case-studies/blackrock/banner4.jpg diff --git a/static/images/booking1.jpg b/static/images/case-studies/booking/banner1.jpg similarity index 100% rename from static/images/booking1.jpg rename to static/images/case-studies/booking/banner1.jpg diff --git a/static/images/booking2.JPG b/static/images/case-studies/booking/banner2.jpg similarity index 100% rename from static/images/booking2.JPG rename to static/images/case-studies/booking/banner2.jpg diff --git a/static/images/booking3.jpg b/static/images/case-studies/booking/banner3.jpg similarity index 100% rename from static/images/booking3.jpg rename to static/images/case-studies/booking/banner3.jpg diff --git a/static/images/BoozAllen1.png b/static/images/case-studies/booz-allen/banner1.png similarity index 100% rename from static/images/BoozAllen1.png rename to static/images/case-studies/booz-allen/banner1.png diff --git a/static/images/BoozAllen2.jpg b/static/images/case-studies/booz-allen/banner2.jpg similarity index 100% rename from static/images/BoozAllen2.jpg rename to static/images/case-studies/booz-allen/banner2.jpg diff --git a/static/images/BoozAllen4.jpg b/static/images/case-studies/booz-allen/banner4.jpg similarity index 100% rename from static/images/BoozAllen4.jpg rename to static/images/case-studies/booz-allen/banner4.jpg diff --git a/static/images/CaseStudy_bose_banner1.jpg b/static/images/case-studies/bose/banner1.jpg similarity index 100% rename from static/images/CaseStudy_bose_banner1.jpg rename to static/images/case-studies/bose/banner1.jpg diff --git a/static/images/CaseStudy_bose_banner3.jpg b/static/images/case-studies/bose/banner3.jpg similarity index 100% rename from static/images/CaseStudy_bose_banner3.jpg rename to static/images/case-studies/bose/banner3.jpg diff --git a/static/images/CaseStudy_bose_banner4.jpg b/static/images/case-studies/bose/banner4.jpg similarity index 100% rename from static/images/CaseStudy_bose_banner4.jpg rename to static/images/case-studies/bose/banner4.jpg diff --git a/static/images/CaseStudy_box_banner1.jpg b/static/images/case-studies/box/banner1.jpg similarity index 100% rename from static/images/CaseStudy_box_banner1.jpg rename to static/images/case-studies/box/banner1.jpg diff --git a/static/images/CaseStudy_box_banner3.jpg b/static/images/case-studies/box/banner3.jpg similarity index 100% rename from static/images/CaseStudy_box_banner3.jpg rename to static/images/case-studies/box/banner3.jpg diff --git a/static/images/CaseStudy_box_banner4.jpg b/static/images/case-studies/box/banner4.jpg similarity index 100% rename from static/images/CaseStudy_box_banner4.jpg rename to static/images/case-studies/box/banner4.jpg diff --git a/static/images/CaseStudy_buffer_banner1.jpg b/static/images/case-studies/buffer/banner1.jpg similarity index 100% rename from static/images/CaseStudy_buffer_banner1.jpg rename to static/images/case-studies/buffer/banner1.jpg diff --git a/static/images/CaseStudy_buffer_banner3.jpg b/static/images/case-studies/buffer/banner3.jpg similarity index 100% rename from static/images/CaseStudy_buffer_banner3.jpg rename to static/images/case-studies/buffer/banner3.jpg diff --git a/static/images/CaseStudy_buffer_banner4.jpg b/static/images/case-studies/buffer/banner4.jpg similarity index 100% rename from static/images/CaseStudy_buffer_banner4.jpg rename to static/images/case-studies/buffer/banner4.jpg diff --git a/static/images/CaseStudy_capitalone_banner1.jpg b/static/images/case-studies/capitalone/banner1.jpg similarity index 100% rename from static/images/CaseStudy_capitalone_banner1.jpg rename to static/images/case-studies/capitalone/banner1.jpg diff --git a/static/images/CaseStudy_capitalone_banner3.jpg b/static/images/case-studies/capitalone/banner3.jpg similarity index 100% rename from static/images/CaseStudy_capitalone_banner3.jpg rename to static/images/case-studies/capitalone/banner3.jpg diff --git a/static/images/CaseStudy_capitalone_banner4.jpg b/static/images/case-studies/capitalone/banner4.jpg similarity index 100% rename from static/images/CaseStudy_capitalone_banner4.jpg rename to static/images/case-studies/capitalone/banner4.jpg diff --git a/static/images/CaseStudy_cern_banner1.jpg b/static/images/case-studies/cern/banner1.jpg similarity index 100% rename from static/images/CaseStudy_cern_banner1.jpg rename to static/images/case-studies/cern/banner1.jpg diff --git a/static/images/CaseStudy_cern_banner3.jpg b/static/images/case-studies/cern/banner3.jpg similarity index 100% rename from static/images/CaseStudy_cern_banner3.jpg rename to static/images/case-studies/cern/banner3.jpg diff --git a/static/images/CaseStudy_cern_banner4.jpg b/static/images/case-studies/cern/banner4.jpg similarity index 100% rename from static/images/CaseStudy_cern_banner4.jpg rename to static/images/case-studies/cern/banner4.jpg diff --git a/static/images/CaseStudy_chinaunicom_banner1.jpg b/static/images/case-studies/chinaunicom/banner1.jpg similarity index 100% rename from static/images/CaseStudy_chinaunicom_banner1.jpg rename to static/images/case-studies/chinaunicom/banner1.jpg diff --git a/static/images/CaseStudy_chinaunicom_banner3.jpg b/static/images/case-studies/chinaunicom/banner3.jpg similarity index 100% rename from static/images/CaseStudy_chinaunicom_banner3.jpg rename to static/images/case-studies/chinaunicom/banner3.jpg diff --git a/static/images/CaseStudy_chinaunicom_banner4.jpg b/static/images/case-studies/chinaunicom/banner4.jpg similarity index 100% rename from static/images/CaseStudy_chinaunicom_banner4.jpg rename to static/images/case-studies/chinaunicom/banner4.jpg diff --git a/static/images/CaseStudy_crowdfire_banner1.jpg b/static/images/case-studies/crowdfire/banner1.jpg similarity index 100% rename from static/images/CaseStudy_crowdfire_banner1.jpg rename to static/images/case-studies/crowdfire/banner1.jpg diff --git a/static/images/CaseStudy_crowdfire_banner3.jpg b/static/images/case-studies/crowdfire/banner3.jpg similarity index 100% rename from static/images/CaseStudy_crowdfire_banner3.jpg rename to static/images/case-studies/crowdfire/banner3.jpg diff --git a/static/images/CaseStudy_crowdfire_banner4.jpg b/static/images/case-studies/crowdfire/banner4.jpg similarity index 100% rename from static/images/CaseStudy_crowdfire_banner4.jpg rename to static/images/case-studies/crowdfire/banner4.jpg diff --git a/static/images/Denso1.png b/static/images/case-studies/denso/banner1.png similarity index 100% rename from static/images/Denso1.png rename to static/images/case-studies/denso/banner1.png diff --git a/static/images/Denso2.jpg b/static/images/case-studies/denso/banner2.jpg similarity index 100% rename from static/images/Denso2.jpg rename to static/images/case-studies/denso/banner2.jpg diff --git a/static/images/Denso4.jpg b/static/images/case-studies/denso/banner4.jpg similarity index 100% rename from static/images/Denso4.jpg rename to static/images/case-studies/denso/banner4.jpg diff --git a/static/images/CaseStudy_ft_banner1.jpg b/static/images/case-studies/ft/banner1.jpg similarity index 100% rename from static/images/CaseStudy_ft_banner1.jpg rename to static/images/case-studies/ft/banner1.jpg diff --git a/static/images/CaseStudy_ft_banner3.jpg b/static/images/case-studies/ft/banner3.jpg similarity index 100% rename from static/images/CaseStudy_ft_banner3.jpg rename to static/images/case-studies/ft/banner3.jpg diff --git a/static/images/CaseStudy_ft_banner4.jpg b/static/images/case-studies/ft/banner4.jpg similarity index 100% rename from static/images/CaseStudy_ft_banner4.jpg rename to static/images/case-studies/ft/banner4.jpg diff --git a/static/images/CaseStudy_golfnow_banner1.jpg b/static/images/case-studies/golfnow/banner1.jpg similarity index 100% rename from static/images/CaseStudy_golfnow_banner1.jpg rename to static/images/case-studies/golfnow/banner1.jpg diff --git a/static/images/CaseStudy_golfnow_banner3.jpg b/static/images/case-studies/golfnow/banner3.jpg similarity index 100% rename from static/images/CaseStudy_golfnow_banner3.jpg rename to static/images/case-studies/golfnow/banner3.jpg diff --git a/static/images/CaseStudy_golfnow_banner4.jpg b/static/images/case-studies/golfnow/banner4.jpg similarity index 100% rename from static/images/CaseStudy_golfnow_banner4.jpg rename to static/images/case-studies/golfnow/banner4.jpg diff --git a/static/images/CaseStudy_haufegroup_banner1.jpg b/static/images/case-studies/haufegroup/banner1.jpg similarity index 100% rename from static/images/CaseStudy_haufegroup_banner1.jpg rename to static/images/case-studies/haufegroup/banner1.jpg diff --git a/static/images/CaseStudy_haufegroup_banner3.jpg b/static/images/case-studies/haufegroup/banner3.jpg similarity index 100% rename from static/images/CaseStudy_haufegroup_banner3.jpg rename to static/images/case-studies/haufegroup/banner3.jpg diff --git a/static/images/CaseStudy_haufegroup_banner4.jpg b/static/images/case-studies/haufegroup/banner4.jpg similarity index 100% rename from static/images/CaseStudy_haufegroup_banner4.jpg rename to static/images/case-studies/haufegroup/banner4.jpg diff --git a/static/images/CaseStudy_huawei_banner1.jpg b/static/images/case-studies/huawei/banner1.jpg similarity index 100% rename from static/images/CaseStudy_huawei_banner1.jpg rename to static/images/case-studies/huawei/banner1.jpg diff --git a/static/images/CaseStudy_huawei_banner3.jpg b/static/images/case-studies/huawei/banner3.jpg similarity index 100% rename from static/images/CaseStudy_huawei_banner3.jpg rename to static/images/case-studies/huawei/banner3.jpg diff --git a/static/images/CaseStudy_huawei_banner4.jpg b/static/images/case-studies/huawei/banner4.jpg similarity index 100% rename from static/images/CaseStudy_huawei_banner4.jpg rename to static/images/case-studies/huawei/banner4.jpg diff --git a/static/images/CaseStudy_ibm_banner1.jpg b/static/images/case-studies/ibm/banner1.jpg similarity index 100% rename from static/images/CaseStudy_ibm_banner1.jpg rename to static/images/case-studies/ibm/banner1.jpg diff --git a/static/images/CaseStudy_ibm_banner3.jpg b/static/images/case-studies/ibm/banner3.jpg similarity index 100% rename from static/images/CaseStudy_ibm_banner3.jpg rename to static/images/case-studies/ibm/banner3.jpg diff --git a/static/images/CaseStudy_ibm_banner4.jpg b/static/images/case-studies/ibm/banner4.jpg similarity index 100% rename from static/images/CaseStudy_ibm_banner4.jpg rename to static/images/case-studies/ibm/banner4.jpg diff --git a/static/images/CaseStudy_ing_banner1.jpg b/static/images/case-studies/ing/banner1.jpg similarity index 100% rename from static/images/CaseStudy_ing_banner1.jpg rename to static/images/case-studies/ing/banner1.jpg diff --git a/static/images/CaseStudy_ing_banner3.jpg b/static/images/case-studies/ing/banner3.jpg similarity index 100% rename from static/images/CaseStudy_ing_banner3.jpg rename to static/images/case-studies/ing/banner3.jpg diff --git a/static/images/CaseStudy_ing_banner4.jpg b/static/images/case-studies/ing/banner4.jpg similarity index 100% rename from static/images/CaseStudy_ing_banner4.jpg rename to static/images/case-studies/ing/banner4.jpg diff --git a/static/images/CaseStudy_jdcom_banner1.jpg b/static/images/case-studies/jdcom/banner1.jpg similarity index 100% rename from static/images/CaseStudy_jdcom_banner1.jpg rename to static/images/case-studies/jdcom/banner1.jpg diff --git a/static/images/CaseStudy_jdcom_banner3.jpg b/static/images/case-studies/jdcom/banner3.jpg similarity index 100% rename from static/images/CaseStudy_jdcom_banner3.jpg rename to static/images/case-studies/jdcom/banner3.jpg diff --git a/static/images/CaseStudy_jdcom_banner4.jpg b/static/images/case-studies/jdcom/banner4.jpg similarity index 100% rename from static/images/CaseStudy_jdcom_banner4.jpg rename to static/images/case-studies/jdcom/banner4.jpg diff --git a/static/images/CaseStudy_montreal_banner1.jpg b/static/images/case-studies/montreal/banner1.jpg similarity index 100% rename from static/images/CaseStudy_montreal_banner1.jpg rename to static/images/case-studies/montreal/banner1.jpg diff --git a/static/images/CaseStudy_montreal_banner3.jpg b/static/images/case-studies/montreal/banner3.jpg similarity index 100% rename from static/images/CaseStudy_montreal_banner3.jpg rename to static/images/case-studies/montreal/banner3.jpg diff --git a/static/images/CaseStudy_montreal_banner4.jpg b/static/images/case-studies/montreal/banner4.jpg similarity index 100% rename from static/images/CaseStudy_montreal_banner4.jpg rename to static/images/case-studies/montreal/banner4.jpg diff --git a/static/images/CaseStudy_naic_banner1.jpg b/static/images/case-studies/naic/banner1.jpg similarity index 100% rename from static/images/CaseStudy_naic_banner1.jpg rename to static/images/case-studies/naic/banner1.jpg diff --git a/static/images/CaseStudy_naic_banner3.jpg b/static/images/case-studies/naic/banner3.jpg similarity index 100% rename from static/images/CaseStudy_naic_banner3.jpg rename to static/images/case-studies/naic/banner3.jpg diff --git a/static/images/CaseStudy_naic_banner4.jpg b/static/images/case-studies/naic/banner4.jpg similarity index 100% rename from static/images/CaseStudy_naic_banner4.jpg rename to static/images/case-studies/naic/banner4.jpg diff --git a/static/images/CaseStudy_nav_banner1.jpg b/static/images/case-studies/nav/banner1.jpg similarity index 100% rename from static/images/CaseStudy_nav_banner1.jpg rename to static/images/case-studies/nav/banner1.jpg diff --git a/static/images/CaseStudy_nav_banner3.jpg b/static/images/case-studies/nav/banner3.jpg similarity index 100% rename from static/images/CaseStudy_nav_banner3.jpg rename to static/images/case-studies/nav/banner3.jpg diff --git a/static/images/CaseStudy_nav_banner4.jpg b/static/images/case-studies/nav/banner4.jpg similarity index 100% rename from static/images/CaseStudy_nav_banner4.jpg rename to static/images/case-studies/nav/banner4.jpg diff --git a/static/images/CaseStudy_nerdalize_banner1.jpg b/static/images/case-studies/nerdalize/banner1.jpg similarity index 100% rename from static/images/CaseStudy_nerdalize_banner1.jpg rename to static/images/case-studies/nerdalize/banner1.jpg diff --git a/static/images/CaseStudy_nerdalize_banner3.jpg b/static/images/case-studies/nerdalize/banner3.jpg similarity index 100% rename from static/images/CaseStudy_nerdalize_banner3.jpg rename to static/images/case-studies/nerdalize/banner3.jpg diff --git a/static/images/CaseStudy_nerdalize_banner4.jpg b/static/images/case-studies/nerdalize/banner4.jpg similarity index 100% rename from static/images/CaseStudy_nerdalize_banner4.jpg rename to static/images/case-studies/nerdalize/banner4.jpg diff --git a/static/images/CaseStudy_netease_banner1.jpg b/static/images/case-studies/netease/banner1.jpg similarity index 100% rename from static/images/CaseStudy_netease_banner1.jpg rename to static/images/case-studies/netease/banner1.jpg diff --git a/static/images/CaseStudy_netease_banner3.jpg b/static/images/case-studies/netease/banner3.jpg similarity index 100% rename from static/images/CaseStudy_netease_banner3.jpg rename to static/images/case-studies/netease/banner3.jpg diff --git a/static/images/CaseStudy_netease_banner4.jpg b/static/images/case-studies/netease/banner4.jpg similarity index 100% rename from static/images/CaseStudy_netease_banner4.jpg rename to static/images/case-studies/netease/banner4.jpg diff --git a/static/images/CaseStudy_newyorktimes_banner1.jpg b/static/images/case-studies/newyorktimes/banner1.jpg similarity index 100% rename from static/images/CaseStudy_newyorktimes_banner1.jpg rename to static/images/case-studies/newyorktimes/banner1.jpg diff --git a/static/images/CaseStudy_newyorktimes_banner3.jpg b/static/images/case-studies/newyorktimes/banner3.jpg similarity index 100% rename from static/images/CaseStudy_newyorktimes_banner3.jpg rename to static/images/case-studies/newyorktimes/banner3.jpg diff --git a/static/images/CaseStudy_newyorktimes_banner4.jpg b/static/images/case-studies/newyorktimes/banner4.jpg similarity index 100% rename from static/images/CaseStudy_newyorktimes_banner4.jpg rename to static/images/case-studies/newyorktimes/banner4.jpg diff --git a/static/images/CaseStudy_nokia_banner1.jpg b/static/images/case-studies/nokia/banner1.jpg similarity index 100% rename from static/images/CaseStudy_nokia_banner1.jpg rename to static/images/case-studies/nokia/banner1.jpg diff --git a/static/images/CaseStudy_nokia_banner3.jpg b/static/images/case-studies/nokia/banner3.jpg similarity index 100% rename from static/images/CaseStudy_nokia_banner3.jpg rename to static/images/case-studies/nokia/banner3.jpg diff --git a/static/images/CaseStudy_nokia_banner4.jpg b/static/images/case-studies/nokia/banner4.jpg similarity index 100% rename from static/images/CaseStudy_nokia_banner4.jpg rename to static/images/case-studies/nokia/banner4.jpg diff --git a/static/images/CaseStudy_nordstrom_banner1.jpg b/static/images/case-studies/nordstrom/banner1.jpg similarity index 100% rename from static/images/CaseStudy_nordstrom_banner1.jpg rename to static/images/case-studies/nordstrom/banner1.jpg diff --git a/static/images/CaseStudy_nordstrom_banner3.jpg b/static/images/case-studies/nordstrom/banner3.jpg similarity index 100% rename from static/images/CaseStudy_nordstrom_banner3.jpg rename to static/images/case-studies/nordstrom/banner3.jpg diff --git a/static/images/CaseStudy_nordstrom_banner4.jpg b/static/images/case-studies/nordstrom/banner4.jpg similarity index 100% rename from static/images/CaseStudy_nordstrom_banner4.jpg rename to static/images/case-studies/nordstrom/banner4.jpg diff --git a/static/images/CaseStudy_northwestern_banner1.jpg b/static/images/case-studies/northwestern/banner1.jpg similarity index 100% rename from static/images/CaseStudy_northwestern_banner1.jpg rename to static/images/case-studies/northwestern/banner1.jpg diff --git a/static/images/CaseStudy_northwestern_banner3.jpg b/static/images/case-studies/northwestern/banner3.jpg similarity index 100% rename from static/images/CaseStudy_northwestern_banner3.jpg rename to static/images/case-studies/northwestern/banner3.jpg diff --git a/static/images/CaseStudy_northwestern_banner4.jpg b/static/images/case-studies/northwestern/banner4.jpg similarity index 100% rename from static/images/CaseStudy_northwestern_banner4.jpg rename to static/images/case-studies/northwestern/banner4.jpg diff --git a/static/images/CaseStudy_ocado_banner1.jpg b/static/images/case-studies/ocado/banner1.jpg similarity index 100% rename from static/images/CaseStudy_ocado_banner1.jpg rename to static/images/case-studies/ocado/banner1.jpg diff --git a/static/images/CaseStudy_ocado_banner3.jpg b/static/images/case-studies/ocado/banner3.jpg similarity index 100% rename from static/images/CaseStudy_ocado_banner3.jpg rename to static/images/case-studies/ocado/banner3.jpg diff --git a/static/images/CaseStudy_ocado_banner4.jpg b/static/images/case-studies/ocado/banner4.jpg similarity index 100% rename from static/images/CaseStudy_ocado_banner4.jpg rename to static/images/case-studies/ocado/banner4.jpg diff --git a/static/images/CaseStudy_openAI_banner1.jpg b/static/images/case-studies/openAI/banner1.jpg similarity index 100% rename from static/images/CaseStudy_openAI_banner1.jpg rename to static/images/case-studies/openAI/banner1.jpg diff --git a/static/images/CaseStudy_openAI_banner3.jpg b/static/images/case-studies/openAI/banner3.jpg similarity index 100% rename from static/images/CaseStudy_openAI_banner3.jpg rename to static/images/case-studies/openAI/banner3.jpg diff --git a/static/images/CaseStudy_openAI_banner4.jpg b/static/images/case-studies/openAI/banner4.jpg similarity index 100% rename from static/images/CaseStudy_openAI_banner4.jpg rename to static/images/case-studies/openAI/banner4.jpg diff --git a/static/images/CaseStudy_peardeck_banner1.jpg b/static/images/case-studies/peardeck/banner1.jpg similarity index 100% rename from static/images/CaseStudy_peardeck_banner1.jpg rename to static/images/case-studies/peardeck/banner1.jpg diff --git a/static/images/CaseStudy_peardeck_banner2.jpg b/static/images/case-studies/peardeck/banner2.jpg similarity index 100% rename from static/images/CaseStudy_peardeck_banner2.jpg rename to static/images/case-studies/peardeck/banner2.jpg diff --git a/static/images/CaseStudy_peardeck_banner3.jpg b/static/images/case-studies/peardeck/banner3.jpg similarity index 100% rename from static/images/CaseStudy_peardeck_banner3.jpg rename to static/images/case-studies/peardeck/banner3.jpg diff --git a/static/images/CaseStudy_pearson_banner1.jpg b/static/images/case-studies/pearson/banner1.jpg similarity index 100% rename from static/images/CaseStudy_pearson_banner1.jpg rename to static/images/case-studies/pearson/banner1.jpg diff --git a/static/images/CaseStudy_pearson_banner3.jpg b/static/images/case-studies/pearson/banner3.jpg similarity index 100% rename from static/images/CaseStudy_pearson_banner3.jpg rename to static/images/case-studies/pearson/banner3.jpg diff --git a/static/images/CaseStudy_pearson_banner4.jpg b/static/images/case-studies/pearson/banner4.jpg similarity index 100% rename from static/images/CaseStudy_pearson_banner4.jpg rename to static/images/case-studies/pearson/banner4.jpg diff --git a/static/images/CaseStudy_pingcap_banner1.jpg b/static/images/case-studies/pingcap/banner1.jpg similarity index 100% rename from static/images/CaseStudy_pingcap_banner1.jpg rename to static/images/case-studies/pingcap/banner1.jpg diff --git a/static/images/CaseStudy_pingcap_banner3.jpg b/static/images/case-studies/pingcap/banner3.jpg similarity index 100% rename from static/images/CaseStudy_pingcap_banner3.jpg rename to static/images/case-studies/pingcap/banner3.jpg diff --git a/static/images/CaseStudy_pingcap_banner4.jpg b/static/images/case-studies/pingcap/banner4.jpg similarity index 100% rename from static/images/CaseStudy_pingcap_banner4.jpg rename to static/images/case-studies/pingcap/banner4.jpg diff --git a/static/images/CaseStudy_pinterest_banner1.jpg b/static/images/case-studies/pinterest/banner1.jpg similarity index 100% rename from static/images/CaseStudy_pinterest_banner1.jpg rename to static/images/case-studies/pinterest/banner1.jpg diff --git a/static/images/CaseStudy_pinterest_banner3.jpg b/static/images/case-studies/pinterest/banner3.jpg similarity index 100% rename from static/images/CaseStudy_pinterest_banner3.jpg rename to static/images/case-studies/pinterest/banner3.jpg diff --git a/static/images/CaseStudy_pinterest_banner4.jpg b/static/images/case-studies/pinterest/banner4.jpg similarity index 100% rename from static/images/CaseStudy_pinterest_banner4.jpg rename to static/images/case-studies/pinterest/banner4.jpg diff --git a/static/images/CaseStudy_prowise_banner1.jpg b/static/images/case-studies/prowise/banner1.jpg similarity index 100% rename from static/images/CaseStudy_prowise_banner1.jpg rename to static/images/case-studies/prowise/banner1.jpg diff --git a/static/images/CaseStudy_prowise_banner3.jpg b/static/images/case-studies/prowise/banner3.jpg similarity index 100% rename from static/images/CaseStudy_prowise_banner3.jpg rename to static/images/case-studies/prowise/banner3.jpg diff --git a/static/images/CaseStudy_prowise_banner4.jpg b/static/images/case-studies/prowise/banner4.jpg similarity index 100% rename from static/images/CaseStudy_prowise_banner4.jpg rename to static/images/case-studies/prowise/banner4.jpg diff --git a/static/images/CaseStudy_ricardoch_banner1.png b/static/images/case-studies/ricardoch/banner1.png similarity index 100% rename from static/images/CaseStudy_ricardoch_banner1.png rename to static/images/case-studies/ricardoch/banner1.png diff --git a/static/images/CaseStudy_ricardoch_banner3.png b/static/images/case-studies/ricardoch/banner3.png similarity index 100% rename from static/images/CaseStudy_ricardoch_banner3.png rename to static/images/case-studies/ricardoch/banner3.png diff --git a/static/images/CaseStudy_ricardoch_banner4.png b/static/images/case-studies/ricardoch/banner4.png similarity index 100% rename from static/images/CaseStudy_ricardoch_banner4.png rename to static/images/case-studies/ricardoch/banner4.png diff --git a/static/images/CaseStudy_slamtec_banner1.jpg b/static/images/case-studies/slamtec/banner1.jpg similarity index 100% rename from static/images/CaseStudy_slamtec_banner1.jpg rename to static/images/case-studies/slamtec/banner1.jpg diff --git a/static/images/CaseStudy_slamtec_banner3.jpg b/static/images/case-studies/slamtec/banner3.jpg similarity index 100% rename from static/images/CaseStudy_slamtec_banner3.jpg rename to static/images/case-studies/slamtec/banner3.jpg diff --git a/static/images/CaseStudy_slamtec_banner4.jpg b/static/images/case-studies/slamtec/banner4.jpg similarity index 100% rename from static/images/CaseStudy_slamtec_banner4.jpg rename to static/images/case-studies/slamtec/banner4.jpg diff --git a/static/images/CaseStudy_slingtv_banner1.jpg b/static/images/case-studies/slingtv/banner1.jpg similarity index 100% rename from static/images/CaseStudy_slingtv_banner1.jpg rename to static/images/case-studies/slingtv/banner1.jpg diff --git a/static/images/CaseStudy_slingtv_banner3.jpg b/static/images/case-studies/slingtv/banner3.jpg similarity index 100% rename from static/images/CaseStudy_slingtv_banner3.jpg rename to static/images/case-studies/slingtv/banner3.jpg diff --git a/static/images/CaseStudy_slingtv_banner4.jpg b/static/images/case-studies/slingtv/banner4.jpg similarity index 100% rename from static/images/CaseStudy_slingtv_banner4.jpg rename to static/images/case-studies/slingtv/banner4.jpg diff --git a/static/images/CaseStudy_sos_banner1.jpg b/static/images/case-studies/sos/banner1.jpg similarity index 100% rename from static/images/CaseStudy_sos_banner1.jpg rename to static/images/case-studies/sos/banner1.jpg diff --git a/static/images/CaseStudy_sos_banner3.jpg b/static/images/case-studies/sos/banner3.jpg similarity index 100% rename from static/images/CaseStudy_sos_banner3.jpg rename to static/images/case-studies/sos/banner3.jpg diff --git a/static/images/CaseStudy_sos_banner4.jpg b/static/images/case-studies/sos/banner4.jpg similarity index 100% rename from static/images/CaseStudy_sos_banner4.jpg rename to static/images/case-studies/sos/banner4.jpg diff --git a/static/images/CaseStudy_spotify_banner1.jpg b/static/images/case-studies/spotify/banner1.jpg similarity index 100% rename from static/images/CaseStudy_spotify_banner1.jpg rename to static/images/case-studies/spotify/banner1.jpg diff --git a/static/images/CaseStudy_spotify_banner3.jpg b/static/images/case-studies/spotify/banner3.jpg similarity index 100% rename from static/images/CaseStudy_spotify_banner3.jpg rename to static/images/case-studies/spotify/banner3.jpg diff --git a/static/images/CaseStudy_spotify_banner4.jpg b/static/images/case-studies/spotify/banner4.jpg similarity index 100% rename from static/images/CaseStudy_spotify_banner4.jpg rename to static/images/case-studies/spotify/banner4.jpg diff --git a/static/images/CaseStudy_squarespace_banner1.jpg b/static/images/case-studies/squarespace/banner1.jpg similarity index 100% rename from static/images/CaseStudy_squarespace_banner1.jpg rename to static/images/case-studies/squarespace/banner1.jpg diff --git a/static/images/CaseStudy_squarespace_banner3.jpg b/static/images/case-studies/squarespace/banner3.jpg similarity index 100% rename from static/images/CaseStudy_squarespace_banner3.jpg rename to static/images/case-studies/squarespace/banner3.jpg diff --git a/static/images/CaseStudy_squarespace_banner4.jpg b/static/images/case-studies/squarespace/banner4.jpg similarity index 100% rename from static/images/CaseStudy_squarespace_banner4.jpg rename to static/images/case-studies/squarespace/banner4.jpg diff --git a/static/images/case_studies/story.png b/static/images/case-studies/story.png similarity index 100% rename from static/images/case_studies/story.png rename to static/images/case-studies/story.png diff --git a/static/images/case_studies/story.svg b/static/images/case-studies/story.svg similarity index 100% rename from static/images/case_studies/story.svg rename to static/images/case-studies/story.svg diff --git a/static/images/CaseStudy_thredup_banner1.jpg b/static/images/case-studies/thredup/banner1.jpg similarity index 100% rename from static/images/CaseStudy_thredup_banner1.jpg rename to static/images/case-studies/thredup/banner1.jpg diff --git a/static/images/CaseStudy_thredup_banner3.jpg b/static/images/case-studies/thredup/banner3.jpg similarity index 100% rename from static/images/CaseStudy_thredup_banner3.jpg rename to static/images/case-studies/thredup/banner3.jpg diff --git a/static/images/CaseStudy_thredup_banner4.jpg b/static/images/case-studies/thredup/banner4.jpg similarity index 100% rename from static/images/CaseStudy_thredup_banner4.jpg rename to static/images/case-studies/thredup/banner4.jpg diff --git a/static/images/case_studies/video_thumb.jpg b/static/images/case-studies/video_thumb.jpg similarity index 100% rename from static/images/case_studies/video_thumb.jpg rename to static/images/case-studies/video_thumb.jpg diff --git a/static/images/case_studies/video_thumb1.png b/static/images/case-studies/video_thumb1.png similarity index 100% rename from static/images/case_studies/video_thumb1.png rename to static/images/case-studies/video_thumb1.png diff --git a/static/images/CaseStudy_vsco_banner1.jpg b/static/images/case-studies/vsco/banner1.jpg similarity index 100% rename from static/images/CaseStudy_vsco_banner1.jpg rename to static/images/case-studies/vsco/banner1.jpg diff --git a/static/images/CaseStudy_vsco_banner2.jpg b/static/images/case-studies/vsco/banner2.jpg similarity index 100% rename from static/images/CaseStudy_vsco_banner2.jpg rename to static/images/case-studies/vsco/banner2.jpg diff --git a/static/images/CaseStudy_vsco_banner4.jpg b/static/images/case-studies/vsco/banner4.jpg similarity index 100% rename from static/images/CaseStudy_vsco_banner4.jpg rename to static/images/case-studies/vsco/banner4.jpg diff --git a/static/images/CaseStudy_wink_banner1.jpg b/static/images/case-studies/wink/banner1.jpg similarity index 100% rename from static/images/CaseStudy_wink_banner1.jpg rename to static/images/case-studies/wink/banner1.jpg diff --git a/static/images/CaseStudy_wink_banner3.jpg b/static/images/case-studies/wink/banner3.jpg similarity index 100% rename from static/images/CaseStudy_wink_banner3.jpg rename to static/images/case-studies/wink/banner3.jpg diff --git a/static/images/CaseStudy_wink_banner4.jpg b/static/images/case-studies/wink/banner4.jpg similarity index 100% rename from static/images/CaseStudy_wink_banner4.jpg rename to static/images/case-studies/wink/banner4.jpg diff --git a/static/images/case_studies/wmc.png b/static/images/case-studies/wmc.png similarity index 100% rename from static/images/case_studies/wmc.png rename to static/images/case-studies/wmc.png diff --git a/static/images/CaseStudy_woorank_banner1.jpg b/static/images/case-studies/woorank/banner1.jpg similarity index 100% rename from static/images/CaseStudy_woorank_banner1.jpg rename to static/images/case-studies/woorank/banner1.jpg diff --git a/static/images/CaseStudy_woorank_banner3.jpg b/static/images/case-studies/woorank/banner3.jpg similarity index 100% rename from static/images/CaseStudy_woorank_banner3.jpg rename to static/images/case-studies/woorank/banner3.jpg diff --git a/static/images/CaseStudy_woorank_banner4.jpg b/static/images/case-studies/woorank/banner4.jpg similarity index 100% rename from static/images/CaseStudy_woorank_banner4.jpg rename to static/images/case-studies/woorank/banner4.jpg diff --git a/static/images/CaseStudy_workiva_banner1.jpg b/static/images/case-studies/workiva/banner1.jpg similarity index 100% rename from static/images/CaseStudy_workiva_banner1.jpg rename to static/images/case-studies/workiva/banner1.jpg diff --git a/static/images/CaseStudy_workiva_banner3.jpg b/static/images/case-studies/workiva/banner3.jpg similarity index 100% rename from static/images/CaseStudy_workiva_banner3.jpg rename to static/images/case-studies/workiva/banner3.jpg diff --git a/static/images/CaseStudy_workiva_banner4.jpg b/static/images/case-studies/workiva/banner4.jpg similarity index 100% rename from static/images/CaseStudy_workiva_banner4.jpg rename to static/images/case-studies/workiva/banner4.jpg diff --git a/static/images/case_studies/yahoojapan.png b/static/images/case-studies/yahoojapan.png similarity index 100% rename from static/images/case_studies/yahoojapan.png rename to static/images/case-studies/yahoojapan.png diff --git a/static/images/CaseStudy_ygrene_banner1.jpg b/static/images/case-studies/ygrene/banner1.jpg similarity index 100% rename from static/images/CaseStudy_ygrene_banner1.jpg rename to static/images/case-studies/ygrene/banner1.jpg diff --git a/static/images/CaseStudy_ygrene_banner3.jpg b/static/images/case-studies/ygrene/banner3.jpg similarity index 100% rename from static/images/CaseStudy_ygrene_banner3.jpg rename to static/images/case-studies/ygrene/banner3.jpg diff --git a/static/images/CaseStudy_ygrene_banner4.jpg b/static/images/case-studies/ygrene/banner4.jpg similarity index 100% rename from static/images/CaseStudy_ygrene_banner4.jpg rename to static/images/case-studies/ygrene/banner4.jpg diff --git a/static/images/CaseStudy_zalando_banner1.jpg b/static/images/case-studies/zalando/banner1.jpg similarity index 100% rename from static/images/CaseStudy_zalando_banner1.jpg rename to static/images/case-studies/zalando/banner1.jpg diff --git a/static/images/CaseStudy_zalando_banner3.jpg b/static/images/case-studies/zalando/banner3.jpg similarity index 100% rename from static/images/CaseStudy_zalando_banner3.jpg rename to static/images/case-studies/zalando/banner3.jpg diff --git a/static/images/CaseStudy_zalando_banner4.jpg b/static/images/case-studies/zalando/banner4.jpg similarity index 100% rename from static/images/CaseStudy_zalando_banner4.jpg rename to static/images/case-studies/zalando/banner4.jpg From 280afd8896e20da343bbed4bff67c292b8e2f690 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sat, 4 Jul 2020 10:32:59 +0800 Subject: [PATCH 33/86] Remove Falco from website This content is dual hosted 3rd party content. --- .../tasks/debug-application-cluster/falco.md | 103 ------------------ 1 file changed, 103 deletions(-) delete mode 100644 content/en/docs/tasks/debug-application-cluster/falco.md diff --git a/content/en/docs/tasks/debug-application-cluster/falco.md b/content/en/docs/tasks/debug-application-cluster/falco.md deleted file mode 100644 index 634b9d33c1..0000000000 --- a/content/en/docs/tasks/debug-application-cluster/falco.md +++ /dev/null @@ -1,103 +0,0 @@ ---- -reviewers: -- soltysh -- sttts -- ericchiang -content_type: concept -title: Auditing with Falco ---- - - -### 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. - - - -#### Install Falco - -Install Falco by using one of the following methods: - -- [Standalone Falco](https://falco.org/docs/installation) -- [Kubernetes DaemonSet](https://falco.org/docs/installation) -- [Falco Helm Chart](https://github.com/falcosecurity/charts/tree/master/falco) - -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](/docs/reference/generated/kube-apiserver/) webhook audit backend. - - cat < /etc/kubernetes/audit-webhook-kubeconfig - apiVersion: v1 - kind: Config - clusters: - - cluster: - server: http://:8765/k8s_audit - name: falco - contexts: - - context: - cluster: falco - user: "" - name: default-context - current-context: default-context - preferences: {} - users: [] - EOF - -1. Start `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](https://github.com/falcosecurity/falco/blob/master/rules/k8s_audit_rules.yaml). -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](https://falco.org/docs/event-sources/kubernetes-audit) in the Falco documentation. - - From c84caa795a0c7575a50d22b6140ddcc61d809c70 Mon Sep 17 00:00:00 2001 From: Houssem Dellai Date: Wed, 22 Jul 2020 15:34:00 +0200 Subject: [PATCH 34/86] Replaced ADD with COPY in Dockerfile COPY is more safe than ADD --- .../run-application/horizontal-pod-autoscale-walkthrough.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index 7f3b046b68..6806ba0dc0 100644 --- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -47,7 +47,7 @@ The Dockerfile has the following content: ``` FROM php:5-apache -ADD index.php /var/www/html/index.php +COPY index.php /var/www/html/index.php RUN chmod a+rx index.php ``` From aa7da1c6e57f749f6db0a4aeef6f4f79cce21eca Mon Sep 17 00:00:00 2001 From: Sameul Zhang Date: Wed, 22 Jul 2020 22:15:36 +0800 Subject: [PATCH 35/86] Update kubelet.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 修改了一处表达略不通顺的译文 --- .../zh/docs/reference/command-line-tools-reference/kubelet.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/reference/command-line-tools-reference/kubelet.md b/content/zh/docs/reference/command-line-tools-reference/kubelet.md index d4f4b6d2c0..9cfb1dbddd 100644 --- a/content/zh/docs/reference/command-line-tools-reference/kubelet.md +++ b/content/zh/docs/reference/command-line-tools-reference/kubelet.md @@ -11,7 +11,7 @@ weight: 28 The kubelet is the primary "node agent" that runs on each node. It can register the node with the apiserver using one of: the hostname; a flag to override the hostname; or specific logic for a cloud provider. --> -kubelet 是在每个 Node 节点上运行的主要 “节点代理”。它向 apiserver 注册节点时可以使用主机名（hostname）；可以提供用于覆盖主机名的参数；还可以执行特定于某云服务商的逻辑。 +kubelet 是在每个 Node 节点上运行的主要 “节点代理”。它可以通过以下方式向 apiserver 进行注册：主机名（hostname）；覆盖主机名的参数；某云服务商的特定逻辑。 + +```shell # 安装 Docker CE ## 设置仓库 ### 安装软件包以允许 apt 通过 HTTPS 使用存储库 apt-get update && apt-get install \ apt-transport-https ca-certificates curl software-properties-common +``` +```shell ### 新增 Docker 的 官方 GPG 秘钥 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - - +``` +```shell ### 添加 Docker apt 仓库 add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" +``` +```shell ## 安装 Docker CE -apt-get update && apt-get install docker-ce=18.06.2~ce~3-0~ubuntu +apt-get update && apt-get install -y\ + containerd.io=1.2.13-2 \ + docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \ + docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) +``` +```shell # 设置 daemon cat > /etc/docker/daemon.json < /etc/docker/daemon.json < +```shell # 重启 docker. systemctl daemon-reload systemctl restart docker -{{< /tab >}} -{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} +``` +{{% /tab %}} +{{% tab name="CentOS/RHEL 7.4+" %}} +```shell # 安装 Docker CE ## 设置仓库 ### 安装所需包 yum install yum-utils device-mapper-persistent-data lvm2 +``` +```shell ### 新增 Docker 仓库。 yum-config-manager \ --add-repo \ https://download.docker.com/linux/centos/docker-ce.repo +``` +```shell ## 安装 Docker CE. yum update && yum install docker-ce-18.06.2.ce +``` +```shell ## 创建 /etc/docker 目录。 mkdir /etc/docker +``` +```shell # 设置 daemon。 cat > /etc/docker/daemon.json < /etc/docker/daemon.json < +```shell # 重启 Docker systemctl daemon-reload systemctl restart docker -{{< /tab >}} -{{< /tabs >}} +``` +{{% /tab %}} +{{% /tabs %}} + + + +如果你想开机即启动 docker 服务，执行以下命令： + +```shell +sudo systemctl enable docker +``` + 请参阅[官方 Docker 安装指南](https://docs.docker.com/engine/installation/) 来获取更多的信息。 @@ -349,7 +394,113 @@ sysctl --system ``` {{< tabs name="tab-cri-cri-o-installation" >}} -{{< tab name="Ubuntu 16.04" codelang="bash" >}} +{{% tab name="Debian" %}} + + + +```shell +# Debian Unstable/Sid +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add - +``` + + + +```shell +# Debian Testing +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add - +``` + + + +```shell +# Debian 10 +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add - +``` + + + +```shell +# Raspbian 10 +echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add - +``` + + + +随后安装 CRI-O: + +```shell +sudo apt-get install cri-o-1.17 +``` + +{{% /tab %}} + +{{% tab name="Ubuntu 18.04, 19.04 and 19.10" %}} + + + +```shell +# 配置仓库 +. /etc/os-release +sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list" +wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add - +sudo apt-get update +``` + + + +```shell +# 安装 CRI-O +sudo apt-get install cri-o-1.17 +``` +{{% /tab %}} + +{{% tab name="Ubuntu 16.04" %}} +```shell # 安装必备软件 apt-get update apt-get install software-properties-common @@ -371,9 +523,9 @@ apt-get update # 安装 CRI-O apt-get install cri-o-1.15 - -{{< /tab >}} -{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} +``` +{{% /tab %}} +{{% tab name="CentOS/RHEL 7.4+" codelang="bash" %}} + +```shell # 安装必备软件 yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/ +``` +```shell # 安装 CRI-O yum install --nogpgcheck cri-o +``` + +{{% /tab %}} + +{{% tab name="openSUSE Tumbleweed" %}} + +```shell +sudo zypper install cri-o +``` +{{% /tab %}} -{{< /tab >}} {{< /tabs >}} + +```shell # 安装 containerd ## 设置仓库 ### 安装软件包以允许 apt 通过 HTTPS 使用存储库 apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common +``` +```shell ### 安装 Docker 的官方 GPG 密钥 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - +``` +```shell ### 新增 Docker apt 仓库。 add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" +``` +```shell ## 安装 containerd apt-get update && apt-get install -y containerd.io +``` +```shell # 配置 containerd mkdir -p /etc/containerd containerd config default > /etc/containerd/config.toml +``` +```shell # 重启 containerd systemctl restart containerd +``` {{< /tab >}} -{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} +{{% tab name="CentOS/RHEL 7.4+" %}} + +```shell # 安装 containerd ## 设置仓库 ### 安装所需包 yum install yum-utils device-mapper-persistent-data lvm2 +``` +```shell ### 新增 Docker 仓库 yum-config-manager \ --add-repo \ https://download.docker.com/linux/centos/docker-ce.repo +``` +```shell ## 安装 containerd yum update && yum install containerd.io +``` +```shell # 配置 containerd mkdir -p /etc/containerd containerd config default > /etc/containerd/config.toml - +``` + +```shell # 重启 containerd systemctl restart containerd -{{< /tab >}} +``` +{{% /tab %}} {{< /tabs >}} ### systemd @@ -587,5 +801,3 @@ Refer to the [Frakti QuickStart guide](https://github.com/kubernetes/frakti#quic ## 其他的 CRI 运行时：frakti 请参阅 [Frakti 快速开始指南](https://github.com/kubernetes/frakti#quickstart) 来获取更多的信息。 - - From 7ecf3561c061516a5e6eb6d7147ef1d5e3824a5b Mon Sep 17 00:00:00 2001 From: Tej-Singh-Rana <58101587+Tej-Singh-Rana@users.noreply.github.com> Date: Thu, 23 Jul 2020 17:31:16 +0530 Subject: [PATCH 42/86] Fixed spell error --- content/en/docs/concepts/services-networking/ingress.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md index 4b6d1f4ab0..fc069a593c 100644 --- a/content/en/docs/concepts/services-networking/ingress.md +++ b/content/en/docs/concepts/services-networking/ingress.md @@ -192,7 +192,7 @@ IngressClass resource will ensure that new Ingresses without an If you have more than one IngressClass marked as the default for your cluster, the admission controller prevents creating new Ingress objects that don't have an `ingressClassName` specified. You can resolve this by ensuring that at most 1 -IngressClasess are marked as default in your cluster. +IngressClasses are marked as default in your cluster. {{< /caution >}} ## Types of Ingress From 7080355d102fda62129bd1fe1b113cb4c65c47be Mon Sep 17 00:00:00 2001 From: Mike Spreitzer Date: Thu, 23 Jul 2020 11:35:04 -0400 Subject: [PATCH 43/86] Improve doc of /debug/api_priority_and_fairness/dump_requests Include a non-phantom line. Document the phantom lines (these are a bug, but not fixed yet, so need to be documented). --- .../concepts/cluster-administration/flow-control.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/content/en/docs/concepts/cluster-administration/flow-control.md b/content/en/docs/concepts/cluster-administration/flow-control.md index 8a8e631742..5cdd070e0f 100644 --- a/content/en/docs/concepts/cluster-administration/flow-control.md +++ b/content/en/docs/concepts/cluster-administration/flow-control.md @@ -409,9 +409,12 @@ When you enable the API Priority and Fairness feature, the kube-apiserver serves ``` The output is similar to this: ``` - PriorityLevelName, FlowSchemaName, QueueIndex, RequestIndexInQueue, FlowDistingsher, ArriveTime, - exempt, , , , , , + PriorityLevelName, FlowSchemaName, QueueIndex, RequestIndexInQueue, FlowDistingsher, ArriveTime, + exempt, , , , , , + system, system-nodes, 12, 0, system:node:127.0.0.1, 2020-07-23T15:26:57.179170694Z, ``` + + In addition to the queued requests, the output includeas one phantom line for each priority level that is exempt from limitation. You can get a more detailed listing with a command like this: ```shell @@ -419,8 +422,9 @@ When you enable the API Priority and Fairness feature, the kube-apiserver serves ``` The output is similar to this: ``` - PriorityLevelName, FlowSchemaName, QueueIndex, RequestIndexInQueue, FlowDistingsher, ArriveTime, UserName, Verb, APIPath, Namespace, Name, APIVersion, Resource, SubResource, - exempt, , , , , , , , , , , , , , + PriorityLevelName, FlowSchemaName, QueueIndex, RequestIndexInQueue, FlowDistingsher, ArriveTime, UserName, Verb, APIPath, Namespace, Name, APIVersion, Resource, SubResource, + system, system-nodes, 12, 0, system:node:127.0.0.1, 2020-07-23T15:31:03.583823404Z, system:node:127.0.0.1, create, /api/v1/namespaces/scaletest/configmaps, + system, system-nodes, 12, 1, system:node:127.0.0.1, 2020-07-23T15:31:03.594555947Z, system:node:127.0.0.1, create, /api/v1/namespaces/scaletest/configmaps, ``` ## {{% heading "whatsnext" %}} From 7cd2327f871bb80beacda1712e368b6d71c0452c Mon Sep 17 00:00:00 2001 From: Celeste Horgan Date: Fri, 17 Jul 2020 12:51:54 -0700 Subject: [PATCH 44/86] Remove shortcodes in favor of layout partials Signed-off-by: Celeste Horgan --- layouts/shortcodes/announcement.html | 14 -------------- layouts/shortcodes/deprecationwarning.html | 13 ------------- 2 files changed, 27 deletions(-) delete mode 100644 layouts/shortcodes/announcement.html delete mode 100644 layouts/shortcodes/deprecationwarning.html diff --git a/layouts/shortcodes/announcement.html b/layouts/shortcodes/announcement.html deleted file mode 100644 index 66455dc347..0000000000 --- a/layouts/shortcodes/announcement.html +++ /dev/null @@ -1,14 +0,0 @@ -{{ if .Page.Param "announcement" }} - -
-
-
- -

- {{ .Page.Param "announcement_message" | markdownify }} -

- -
-
-
-{{ end }} \ No newline at end of file diff --git a/layouts/shortcodes/deprecationwarning.html b/layouts/shortcodes/deprecationwarning.html deleted file mode 100644 index f26244ed75..0000000000 --- a/layouts/shortcodes/deprecationwarning.html +++ /dev/null @@ -1,13 +0,0 @@ -{{ if .Page.Param "deprecated" }} -
-
-
-

- Kubernetes {{ .Page.Param "version" }} - {{ T "deprecation_warning" }} - {{ T "latest_version" }} -

-
-
-
-{{ end }} From 97b22f9fbe14218005562d8ce3a69fffe482a178 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Fri, 24 Jul 2020 01:40:15 +0900 Subject: [PATCH 45/86] Fix a bug of shortcode 'glossary_definition' which selects a wrong term. --- layouts/shortcodes/glossary_definition.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/layouts/shortcodes/glossary_definition.html b/layouts/shortcodes/glossary_definition.html index 2104d1dbc6..76d38fc14b 100644 --- a/layouts/shortcodes/glossary_definition.html +++ b/layouts/shortcodes/glossary_definition.html @@ -4,7 +4,7 @@ {{- $prepend := .Get "prepend" }} {{- $glossaryBundle := site.GetPage "page" "docs/reference/glossary" -}} {{- $glossaryItems := $glossaryBundle.Resources.ByType "page" -}} -{{- $term_info := $glossaryItems.GetMatch (printf "%s*" $id ) -}} +{{- $term_info := $glossaryItems.GetMatch (printf "%s.md" $id ) -}} {{- if not $term_info -}} {{- errorf "[%s] %q: %q is not a valid glossary term_id, see ./docs/reference/glossary/* for a full list" site.Language.Lang .Page.Path $id -}} {{- end -}} From 8e06ed46587bca46f5fc71b6d5113e50a1842228 Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Thu, 23 Jul 2020 23:20:27 +0100 Subject: [PATCH 46/86] Improve diagrams for Source IP tutorial The existing diagrams were ASCII art. Use drawings instead. --- .../en/docs/tutorials/services/source-ip.md | 59 +-- .../docs/sourceip-externaltrafficpolicy.svg | 473 ++++++++++++++++++ 2 files changed, 499 insertions(+), 33 deletions(-) create mode 100644 static/images/docs/sourceip-externaltrafficpolicy.svg diff --git a/content/en/docs/tutorials/services/source-ip.md b/content/en/docs/tutorials/services/source-ip.md index 2e8710b758..5cf25be4d2 100644 --- a/content/en/docs/tutorials/services/source-ip.md +++ b/content/en/docs/tutorials/services/source-ip.md @@ -1,6 +1,7 @@ --- title: Using Source IP content_type: tutorial +mermaid: true min-kubernetes-server-version: v1.5 --- @@ -206,18 +207,19 @@ Note that these are not the correct client IPs, they're cluster internal IPs. Th Visually: -``` - client - \ ^ - \ \ - v \ - node 1 <--- node 2 - | ^ SNAT - | | ---> - v | - endpoint -``` +{{< mermaid >}} +graph LR; + client(client)-->node2[Node 2]; + node2-->client; + node2-. SNAT .->node1[Node 1]; + node1-. SNAT .->node2; + node1-->endpoint(Endpoint); + classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; + classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; + class node1,node2,endpoint k8s; + class client plain; +{{}} To avoid this, Kubernetes has a feature to [preserve the client source IP](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip). @@ -261,17 +263,18 @@ This is what happens: Visually: -``` - client - ^ / \ - / / \ - / v X - node 1 node 2 - ^ | - | | - | v - endpoint -``` +{{< mermaid >}} +graph TD; + client --> node1[Node 1]; + client(client) --x node2[Node 2]; + node1 --> endpoint(endpoint); + endpoint --> node1; + + classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; + classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; + class node1,node2,endpoint k8s; + class client plain; +{{}} @@ -324,17 +327,7 @@ deliberately failing health checks. Visually: -``` - client - | - lb VIP - / ^ - v / -health check ---> node 1 node 2 <--- health check - 200 <--- ^ | ---> 500 - | V - endpoint -``` +![Source IP with externalTrafficPolicy](/images/docs/sourceip-externaltrafficpolicy.svg) You can test this by setting the annotation: diff --git a/static/images/docs/sourceip-externaltrafficpolicy.svg b/static/images/docs/sourceip-externaltrafficpolicy.svg new file mode 100644 index 0000000000..eace834f71 --- /dev/null +++ b/static/images/docs/sourceip-externaltrafficpolicy.svg @@ -0,0 +1,473 @@ + +image/svg+xmlSource IP with externalTrafficPolicyServiceLoad balancerconfigurationServiceNode 2Node 1Health check of node 2returns 500Health check of node 1returns 200 From e7c2510a893be827f33db576b694f387eec3a3da Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Thu, 23 Jul 2020 23:53:33 +0100 Subject: [PATCH 47/86] Mark RBAC table header as header Use and elements to distinguish between the header and the body of the table. Slightly improves accessibility and also visual style. --- .../docs/reference/access-authn-authz/rbac.md | 24 +++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-) diff --git a/content/en/docs/reference/access-authn-authz/rbac.md b/content/en/docs/reference/access-authn-authz/rbac.md index 20b1224e59..2be833826c 100644 --- a/content/en/docs/reference/access-authn-authz/rbac.md +++ b/content/en/docs/reference/access-authn-authz/rbac.md @@ -606,12 +606,15 @@ either do not manually edit the role, or disable auto-reconciliation. - + + + + @@ -627,6 +630,7 @@ either do not manually edit the role, or disable auto-reconciliation. +
Kubernetes RBAC API discovery roles
Default ClusterRole Default ClusterRoleBinding Description
system:basic-user system:authenticated groupsystem:authenticated and system:unauthenticated groups Allows read-only access to non-sensitive information about the cluster. Introduced in Kubernetes v1.14.
### User-facing roles @@ -649,12 +653,15 @@ metadata: ``` - + + + + @@ -691,17 +698,21 @@ the contents of Secrets enables access to ServiceAccount credentials in the namespace, which would allow API access as any ServiceAccount in the namespace (a form of privilege escalation). +
Default ClusterRole Default ClusterRoleBinding Description
cluster-admin system:masters group
### Core component roles - + + + + @@ -733,17 +744,21 @@ The system:node role only exists for compatibility with Kubernetes clus +
Default ClusterRole Default ClusterRoleBinding Description
system:kube-scheduler system:kube-scheduler usersystem:kube-proxy user Allows access to the resources required by the {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} component.
### Other component roles - + + + + @@ -786,6 +801,7 @@ This is commonly used by add-on API servers for unified authentication and autho +
Default ClusterRole Default ClusterRoleBinding Description
system:auth-delegator NoneNone Allows access to the resources required by most dynamic volume provisioners.
### Roles for built-in controllers {#controller-roles} From 1f33802b2a095c7abb44e9db0224e3e28577606a Mon Sep 17 00:00:00 2001 From: Arhell Date: Fri, 24 Jul 2020 02:07:47 +0300 Subject: [PATCH 48/86] large indent fix on video block --- content/uk/_index.html | 1 - 1 file changed, 1 deletion(-) diff --git a/content/uk/_index.html b/content/uk/_index.html index 3a0a04e1da..4bef7023f6 100644 --- a/content/uk/_index.html +++ b/content/uk/_index.html @@ -62,7 +62,6 @@ Kubernetes - проект з відкритим вихідним кодом. В

-
Відвідати KubeCon в Амстердамі, 30.03-02.04 2020

From fe296af1870fcb44c4ff9a5285fa4f1dc8bb6580 Mon Sep 17 00:00:00 2001 From: bluefriday Date: Wed, 15 Jul 2020 10:59:52 +0900 Subject: [PATCH 49/86] Eighth Korean l10n work for release 1.18 - Translate tasks/administer-cluster/declare-network-policy in Korean (#22526) - Translate tasks/debug-application-cluster/debug-init-containers in Korean (#22608) - Fix a missing markdown syntax to enable external link (#22661) - Translate tasks/administer-cluster/change-pv-reclaim-policy in Korean (#22551) - Update docs/contribute/participate/ for Korean (#22605) - Update outdated files in dev-1.18-ko.8 (#22466) - Translate tasks/administer-cluster/dns-custom-nameservers in Korean (#22524) Co-authored-by: Daehyun Paik Co-authored-by: Jerry Park Co-authored-by: bluefriday Co-authored-by: June Yi Co-authored-by: Jesang Myung Co-authored-by: Seokho Son --- content/ko/docs/concepts/_index.md | 56 ---- .../ko/docs/concepts/architecture/_index.md | 2 + .../concepts/cluster-administration/_index.md | 68 +++- .../cluster-administration-overview.md | 66 ---- .../ko/docs/concepts/configuration/_index.md | 3 +- .../docs/concepts/configuration/configmap.md | 33 +- .../manage-resources-containers.md | 4 +- .../concepts/configuration/pod-overhead.md | 40 ++- content/ko/docs/concepts/containers/_index.md | 38 ++- .../ko/docs/concepts/containers/overview.md | 43 --- .../docs/concepts/extend-kubernetes/_index.md | 204 +++++++++++- content/ko/docs/concepts/overview/_index.md | 3 +- .../overview/working-with-objects/_index.md | 2 +- content/ko/docs/concepts/policy/_index.md | 2 + .../concepts/scheduling-eviction/_index.md | 3 + .../scheduling-eviction/kube-scheduler.md | 1 - content/ko/docs/concepts/security/_index.md | 2 + .../concepts/services-networking/_index.md | 8 + .../ingress-controllers.md | 2 +- .../concepts/services-networking/ingress.md | 2 +- content/ko/docs/concepts/storage/_index.md | 3 +- .../concepts/storage/persistent-volumes.md | 2 +- content/ko/docs/concepts/workloads/_index.md | 2 + content/ko/docs/contribute/_index.md | 3 +- content/ko/docs/contribute/advanced.md | 63 ---- .../docs/contribute/new-content/open-a-pr.md | 24 +- .../ko/docs/contribute/participate/_index.md | 120 +++++++ .../contribute/participate/pr-wranglers.md | 70 ++++ .../participate/roles-and-responsibilties.md | 195 +++++++++++ content/ko/docs/contribute/participating.md | 314 ------------------ .../docs/contribute/style/write-new-topic.md | 12 +- .../feature-gates.md | 9 +- content/ko/docs/reference/glossary/volume.md | 7 +- content/ko/docs/setup/_index.md | 23 +- .../production-environment/tools/kops.md | 2 +- content/ko/docs/setup/release/notes.md | 2 +- content/ko/docs/tasks/_index.md | 4 - .../web-ui-dashboard.md | 12 +- .../change-pv-reclaim-policy.md | 97 ++++++ .../declare-network-policy.md | 145 ++++++++ .../dns-custom-nameservers.md | 261 +++++++++++++++ .../debug-init-containers.md | 125 +++++++ content/ko/docs/tutorials/_index.md | 8 +- .../ko/docs/tutorials/services/source-ip.md | 8 +- .../expose-external-ip-address.md | 2 +- .../service/networking/nginx-policy.yaml | 13 + 46 files changed, 1454 insertions(+), 654 deletions(-) delete mode 100644 content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md delete mode 100644 content/ko/docs/concepts/containers/overview.md create mode 100644 content/ko/docs/contribute/participate/_index.md create mode 100644 content/ko/docs/contribute/participate/pr-wranglers.md create mode 100644 content/ko/docs/contribute/participate/roles-and-responsibilties.md delete mode 100644 content/ko/docs/contribute/participating.md create mode 100644 content/ko/docs/tasks/administer-cluster/change-pv-reclaim-policy.md create mode 100644 content/ko/docs/tasks/administer-cluster/declare-network-policy.md create mode 100644 content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md create mode 100644 content/ko/docs/tasks/debug-application-cluster/debug-init-containers.md create mode 100644 content/ko/examples/service/networking/nginx-policy.yaml diff --git a/content/ko/docs/concepts/_index.md b/content/ko/docs/concepts/_index.md index 89b8e7910c..f23bec1529 100644 --- a/content/ko/docs/concepts/_index.md +++ b/content/ko/docs/concepts/_index.md @@ -12,59 +12,3 @@ weight: 40 - -## 개요 - -쿠버네티스를 사용하려면, *쿠버네티스 API 오브젝트* 로 클러스터에 대해 사용자가 *바라는 상태* 를 기술해야 한다. 어떤 애플리케이션이나 워크로드를 구동시키려고 하는지, 어떤 컨테이너 이미지를 쓰는지, 복제의 수는 몇 개인지, 어떤 네트워크와 디스크 자원을 쓸 수 있도록 할 것인지 등을 의미한다. 바라는 상태를 설정하는 방법은 쿠버네티스 API를 사용해서 오브젝트를 만드는 것인데, 대개 `kubectl`이라는 커맨드라인 인터페이스를 사용한다. 클러스터와 상호 작용하고 바라는 상태를 설정하거나 수정하기 위해서 쿠버네티스 API를 직접 사용할 수도 있다. - -바라는 상태를 설정하면, *쿠버네티스 컨트롤 플레인* 은 Pod Lifecycle Event Generator ([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md))를 통해 클러스터의 현재 상태를 바라는 상태와 일치시킨다. 그렇게 함으로써, 쿠버네티스가 컨테이너를 시작 또는 재시작하거나, 주어진 애플리케이션의 복제 수를 스케일링하는 등의 다양한 작업을 자동으로 수행한다. 쿠버네티스 컨트롤 플레인은 클러스터에서 실행 중인 프로세스의 묶음(collection)으로 구성된다. - -* **쿠버네티스 마스터**는 클러스터 내 마스터 노드로 지정된 노드 내에서 구동되는 세 개의 프로세스 묶음이다. 해당 프로세스는 [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) 및 [kube-scheduler](/docs/admin/kube-scheduler/)이다. -* 클러스터 내 마스터 노드가 아닌 각각의 노드는 다음 두 개의 프로세스를 구동시킨다. - * 쿠버네티스 마스터와 통신하는 **[kubelet](/docs/admin/kubelet/)**. - * 각 노드의 쿠버네티스 네트워킹 서비스를 반영하는 네트워크 프록시인 **[kube-proxy](/docs/admin/kube-proxy/)**. - -## 쿠버네티스 오브젝트 - -쿠버네티스는 시스템의 상태를 나타내는 추상 개념을 다수 포함하고 있다. 컨테이너화되어 배포된 애플리케이션과 워크로드, 이에 연관된 네트워크와 디스크 자원, 그 밖에 클러스터가 무엇을 하고 있는지에 대한 정보가 이에 해당한다. 이런 추상 개념은 쿠버네티스 API 내 오브젝트로 표현된다. 보다 자세한 내용은 [쿠버네티스 오브젝트 이해하기](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) 문서를 참조한다. - -기초적인 쿠버네티스 오브젝트에는 다음과 같은 것들이 있다. - -* [파드](/ko/docs/concepts/workloads/pods/pod-overview/) -* [서비스](/ko/docs/concepts/services-networking/service/) -* [볼륨](/ko/docs/concepts/storage/volumes/) -* [네임스페이스(Namespace)](/ko/docs/concepts/overview/working-with-objects/namespaces/) - -또한, 쿠버네티스에는 기초 오브젝트를 기반으로, 부가 기능 및 편의 기능을 제공하는 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 의존하는 보다 높은 수준의 추상 개념도 포함되어 있다. 다음이 포함된다. - -* [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/) -* [데몬셋(DaemonSet)](/ko/docs/concepts/workloads/controllers/daemonset/) -* [스테이트풀셋(StatefulSet)](/ko/docs/concepts/workloads/controllers/statefulset/) -* [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/) -* [잡(Job)](/ko/docs/concepts/workloads/controllers/job/) - -## 쿠버네티스 컨트롤 플레인 - -쿠버네티스 마스터와 kubelet 프로세스와 같은 쿠버네티스 컨트롤 플레인의 다양한 구성 요소는 쿠버네티스가 클러스터와 통신하는 방식을 관장한다. 컨트롤 플레인은 시스템 내 모든 쿠버네티스 오브젝트의 레코드를 유지하면서, 오브젝트의 상태를 관리하는 제어 루프를 지속적으로 구동시킨다. 컨트롤 플레인의 제어 루프는 클러스터 내 변경이 발생하면 언제라도 응답하고 시스템 내 모든 오브젝트의 실제 상태가 사용자가 바라는 상태와 일치시키기 위한 일을 한다. - -예를 들어, 쿠버네티스 API를 사용해서 디플로이먼트를 만들 때에는, 바라는 상태를 시스템에 신규로 입력해야한다. 쿠버네티스 컨트롤 플레인이 오브젝트 생성을 기록하고, 사용자 지시대로 필요한 애플리케이션을 시작시키고 클러스터 노드에 스케줄링한다. 그래서 결국 클러스터의 실제 상태가 바라는 상태와 일치하게 된다. - -### 쿠버네티스 마스터 - -클러스터에 대해 바라는 상태를 유지할 책임은 쿠버네티스 마스터에 있다. `kubectl` 커맨드라인 인터페이스와 같은 것을 사용해서 쿠버네티스로 상호 작용할 때에는 쿠버네티스 마스터와 통신하고 있는 셈이다. - -> "마스터"는 클러스터 상태를 관리하는 프로세스의 묶음이다. 주로 모든 프로세스는 클러스터 내 단일 노드에서 구동되며, 이 노드가 바로 마스터이다. 마스터는 가용성과 중복을 위해 복제될 수도 있다. - -### 쿠버네티스 노드 - -클러스터 내 노드는 애플리케이션과 클라우드 워크플로우를 구동시키는 머신(VM, 물리 서버 등)이다. 쿠버네티스 마스터는 각 노드를 관리한다. 직접 노드와 직접 상호 작용할 일은 거의 없을 것이다. - - - - -## {{% heading "whatsnext" %}} - - -개념 페이지를 작성하기를 원하면, -개념 페이지 타입에 대한 정보가 있는 -[페이지 컨텐츠 타입](/docs/contribute/style/page-content-types/#concept)을 참고한다. diff --git a/content/ko/docs/concepts/architecture/_index.md b/content/ko/docs/concepts/architecture/_index.md index cbcb8e810d..4a83cc3c08 100644 --- a/content/ko/docs/concepts/architecture/_index.md +++ b/content/ko/docs/concepts/architecture/_index.md @@ -1,4 +1,6 @@ --- title: "클러스터 아키텍처" weight: 30 +description: > + 쿠버네티스 뒤편의 구조와 설계 개념들 --- diff --git a/content/ko/docs/concepts/cluster-administration/_index.md b/content/ko/docs/concepts/cluster-administration/_index.md index e13a5fdb48..c21e17e3ec 100755 --- a/content/ko/docs/concepts/cluster-administration/_index.md +++ b/content/ko/docs/concepts/cluster-administration/_index.md @@ -1,5 +1,71 @@ --- -title: "클러스터 관리" +title: 클러스터 관리 weight: 100 +content_type: concept +description: > + 쿠버네티스 클러스터 생성 또는 관리에 관련된 로우-레벨(lower-level)의 세부 정보를 설명한다. +no_list: true --- + +클러스터 관리 개요는 쿠버네티스 클러스터를 생성하거나 관리하는 모든 사람들을 위한 것이다. +핵심 쿠버네티스 [개념](/ko/docs/concepts/)에 어느 정도 익숙하다고 가정한다. + + +## 클러스터 계획 + +쿠버네티스 클러스터를 계획, 설정 및 구성하는 방법에 대한 예는 [시작하기](/ko/docs/setup/)에 있는 가이드를 참고한다. 이 문서에 나열된 솔루션을 *배포판* 이라고 한다. + + {{< note >}} + 모든 배포판이 활발하게 유지되는 것은 아니다. 최신 버전의 쿠버네티스에서 테스트된 배포판을 선택한다. + {{< /note >}} + +가이드를 선택하기 전에 고려해야 할 사항은 다음과 같다. + + - 컴퓨터에서 쿠버네티스를 그냥 한번 사용해보고 싶은가? 아니면, 고가용 멀티 노드 클러스터를 만들고 싶은가? 사용자의 필요에 따라 가장 적합한 배포판을 선택한다. + - [구글 쿠버네티스 엔진(Google Kubernetes Engine)](https://cloud.google.com/kubernetes-engine/)과 같은 클라우드 제공자의 **쿠버네티스 클러스터 호스팅** 을 사용할 것인가? 아니면, **자체 클러스터를 호스팅** 할 것인가? + - 클러스터가 **온-프레미스 환경** 에 있나? 아니면, **클라우드(IaaS)** 에 있나? 쿠버네티스는 하이브리드 클러스터를 직접 지원하지는 않는다. 대신 여러 클러스터를 설정할 수 있다. + - **온-프레미스 환경에 쿠버네티스** 를 구성하는 경우, 어떤 [네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/)이 가장 적합한 지 고려한다. + - 쿠버네티스를 **"베어 메탈" 하드웨어** 에서 실행할 것인가? 아니면, **가상 머신(VM)** 에서 실행할 것인가? + - **단지 클러스터만 실행할 것인가?** 아니면, **쿠버네티스 프로젝트 코드를 적극적으로 개발** 하는 것을 기대하는가? 만약 + 후자라면, 활발하게 개발이 진행되고 있는 배포판을 선택한다. 일부 배포판은 바이너리 릴리스만 사용하지만, + 더 다양한 선택을 제공한다. + - 클러스터를 실행하는 데 필요한 [컴포넌트](/ko/docs/concepts/overview/components/)에 익숙해지자. + + +## 클러스터 관리 + +* [클러스터 관리](/ko/docs/tasks/administer-cluster/cluster-management/)는 클러스터 라이프사이클과 관련된 몇 가지 주제를 설명한다. 새로운 클러스터 생성, 클러스터의 마스터 및 워커 노드 업그레이드, 노드 유지 관리 수행(예: 커널 업그레이드) 및 실행 중인 클러스터의 쿠버네티스 API 버전 업그레이드 + +* [노드 관리](/ko/docs/concepts/architecture/nodes/) 방법을 배운다. + +* 공유 클러스터에 대한 [리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 설정하고 관리하는 방법을 배운다. + +## 클러스터 보안 + +* [인증서](/ko/docs/concepts/cluster-administration/certificates/)는 다른 툴 체인을 사용하여 인증서를 생성하는 단계를 설명한다. + +* [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 쿠버네티스 노드에서 Kubelet으로 관리하는 컨테이너에 대한 환경을 설명한다. + +* [쿠버네티스 API에 대한 접근 제어](/docs/reference/access-authn-authz/controlling-access/)는 사용자와 서비스 어카운트에 대한 권한을 설정하는 방법을 설명한다. + +* [인증](/docs/reference/access-authn-authz/authentication/)은 다양한 인증 옵션을 포함한 쿠버네티스에서의 인증에 대해 설명한다. + +* [인가](/docs/reference/access-authn-authz/authorization/)는 인증과는 별개로, HTTP 호출 처리 방법을 제어한다. + +* [어드미션 컨트롤러 사용하기](/docs/reference/access-authn-authz/admission-controllers/)는 인증과 권한 부여 후 쿠버네티스 API 서버에 대한 요청을 가로채는 플러그인에 대해 설명한다. + +* [쿠버네티스 클러스터에서 Sysctls 사용하기](/docs/concepts/cluster-administration/sysctl-cluster/)는 관리자가 `sysctl` 커맨드라인 도구를 사용하여 커널 파라미터를 설정하는 방법에 대해 설명한다. + +* [감사(audit)](/docs/tasks/debug-application-cluster/audit/)는 쿠버네티스의 감사 로그를 다루는 방법에 대해 설명한다. + +### kubelet 보안 + * [마스터-노드 통신](/ko/docs/concepts/architecture/control-plane-node-communication/) + * [TLS 부트스트래핑(bootstrapping)](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) + * [Kubelet 인증/인가](/docs/admin/kubelet-authentication-authorization/) + +## 선택적 클러스터 서비스 + +* [DNS 통합](/ko/docs/concepts/services-networking/dns-pod-service/)은 DNS 이름을 쿠버네티스 서비스로 직접 확인하는 방법을 설명한다. + +* [클러스터 액티비티 로깅과 모니터링](/ko/docs/concepts/cluster-administration/logging/)은 쿠버네티스에서의 로깅이 어떻게 작동하는지와 구현 방법에 대해 설명한다. diff --git a/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md deleted file mode 100644 index 2efa8436fb..0000000000 --- a/content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -title: 클러스터 관리 개요 -content_type: concept -weight: 10 ---- - - -클러스터 관리 개요는 쿠버네티스 클러스터를 만들거나 관리하는 모든 사람들을 위한 것이다. -여기서는 쿠버네티스의 핵심 [개념](/ko/docs/concepts/)에 대해 잘 알고 있다고 가정한다. - - - -## 클러스터 계획 - -[올바른 솔루션 고르기](/ko/docs/setup/pick-right-solution/)에서 쿠버네티스 클러스터를 어떻게 계획하고, 셋업하고, 구성하는 지에 대한 예시를 참조하자. 이 글에 쓰여진 솔루션들은 *배포판* 이라고 부른다. - -가이드를 고르기 전에, 몇 가지 고려사항이 있다. - - - 단지 자신의 컴퓨터에 쿠버네티스를 테스트를 하는지, 또는 고가용성의 멀티 노드 클러스터를 만들려고 하는지에 따라 니즈에 가장 적절한 배포판을 고르자. - - [구글 쿠버네티스 엔진](https://cloud.google.com/kubernetes-engine/)과 같은 **호스팅된 쿠버네티스 클러스터** 를 사용할 것인지, **자신의 클러스터에 호스팅할 것인지**? - - 클러스터가 **온프레미스** 인지, 또는 **클라우드(IaaS)** 인지? 쿠버네티스는 하이브리드 클러스터를 직접적으로 지원하지는 않는다. 대신에, 사용자는 여러 클러스터를 구성할 수 있다. - - **만약 온프레미스에서 쿠버네티스를 구성한다면**, 어떤 [네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/)이 가장 적합한지 고려한다. - - 쿠버네티스 실행을 **"베어메탈" 하드웨어** 또는, **가상 머신 (VMs)** 중 어디에서 할 것 인지? - - **단지 클러스터 동작** 만 할 것인지, 아니면 **쿠버네티스 프로젝트 코드의 적극적인 개발** 을 원하는지? 만약 후자의 경우라면, - 적극적으로 개발된 배포판을 선택한다. 몇몇 배포판은 바이너리 릴리스 밖에 없지만, - 매우 다양한 선택권을 제공한다. - - 스스로 클러스터 구동에 필요한 [구성요소](/ko/docs/concepts/overview/components/)에 익숙해지자. - -참고: 모든 배포판이 적극적으로 유지되는 것은 아니다. 최근 버전의 쿠버네티스로 테스트 된 배포판을 선택하자. - -## 클러스터 관리 - -* [클러스터 관리](/ko/docs/tasks/administer-cluster/cluster-management/)는 클러스터의 라이프사이클과 관련된 몇 가지 주제를 설명한다. 이는 새 클러스터 생성, 마스터와 워커노드 업그레이드, 노드 유지보수 실행 (예: 커널 업그레이드), 그리고 동작 중인 클러스터의 쿠버네티스 API 버전 업그레이드 등을 포함한다. - -* 어떻게 [노드 관리](/ko/docs/concepts/architecture/nodes/)를 하는지 배워보자. - -* 공유된 클러스터의 [리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 어떻게 셋업하고 관리할 것인지 배워보자. - -## 클러스터 보안 - -* [인증서](/ko/docs/concepts/cluster-administration/certificates/)는 다른 툴 체인을 이용하여 인증서를 생성하는 방법을 설명한다. - -* [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 쿠버네티스 노드에서 Kubelet에 의해 관리되는 컨테이너 환경에 대해 설명한다. - -* [쿠버네티스 API에 대한 접근 제어](/docs/reference/access-authn-authz/controlling-access/)는 사용자와 서비스 계정에 어떻게 권한 설정을 하는지 설명한다. - -* [인증](/docs/reference/access-authn-authz/authentication/)은 다양한 인증 옵션을 포함한 쿠버네티스에서의 인증을 설명한다. - -* [인가](/docs/reference/access-authn-authz/authorization/)은 인증과 다르며, HTTP 호출이 처리되는 방법을 제어한다. - -* [어드미션 컨트롤러 사용](/docs/reference/access-authn-authz/admission-controllers/)은 쿠버네티스 API 서버에서 인증과 인가 후 요청을 가로채는 플러그인을 설명한다. - -* [쿠버네티스 클러스터에서 Sysctls 사용](/docs/concepts/cluster-administration/sysctl-cluster/)는 관리자가 `sysctl` 커맨드라인 툴을 사용하여 커널 파라미터를 설정하는 방법을 설명한다. - -* [감시](/docs/tasks/debug-application-cluster/audit/)는 쿠버네티스 감시 로그가 상호작용 하는 방법을 설명한다. - -### kubelet 보안 - * [마스터노드 커뮤니케이션](/ko/docs/concepts/architecture/master-node-communication/) - * [TLS 부트스트래핑](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) - * [Kubelet 인증/인가](/docs/admin/kubelet-authentication-authorization/) - -## 선택적 클러스터 서비스 - -* [DNS 통합](/ko/docs/concepts/services-networking/dns-pod-service/)은 DNS 이름이 쿠버네티스 서비스에 바로 연결되도록 변환하는 방법을 설명한다. - -* [클러스터 활동 로깅과 모니터링](/ko/docs/concepts/cluster-administration/logging/)은 쿠버네티스 로깅이 로깅의 작동 방법과 로깅을 어떻게 구현하는지 설명한다. diff --git a/content/ko/docs/concepts/configuration/_index.md b/content/ko/docs/concepts/configuration/_index.md index 11dbabc7b2..5485f559a1 100755 --- a/content/ko/docs/concepts/configuration/_index.md +++ b/content/ko/docs/concepts/configuration/_index.md @@ -1,5 +1,6 @@ --- title: "구성" weight: 80 +description: > + 쿠버네티스가 파드 구성을 위해 제공하는 리소스 --- - diff --git a/content/ko/docs/concepts/configuration/configmap.md b/content/ko/docs/concepts/configuration/configmap.md index 542fef1bcc..5031b06cf5 100644 --- a/content/ko/docs/concepts/configuration/configmap.md +++ b/content/ko/docs/concepts/configuration/configmap.md @@ -126,25 +126,32 @@ spec: configMap: # 마운트하려는 컨피그맵의 이름을 제공한다. name: game-demo + # 컨피그맵에서 파일로 생성할 키 배열 + items: + - key: "game.properties" + path: "game.properties" + - key: "user-interface.properties" + path: "user-interface.properties" ``` 컨피그맵은 단일 라인 속성(single line property) 값과 멀티 라인의 파일과 비슷한(multi-line file-like) 값을 구분하지 않는다. 더 중요한 것은 파드와 다른 오브젝트가 이러한 값을 소비하는 방식이다. + 이 예제에서, 볼륨을 정의하고 `demo` 컨테이너에 -`/config` 로 마운트하면 4개의 파일이 생성된다. +`/config` 로 마운트하면 컨피그맵에 4개의 키가 있더라도 +`/config/game.properties` 와 `/config/user-interface.properties` +2개의 파일이 생성된다. 이것은 파드 정의가 +`volume` 섹션에서 `items` 배열을 지정하기 때문이다. +`items` 배열을 완전히 생략하면, 컨피그맵의 모든 키가 +키와 이름이 같은 파일이 되고, 4개의 파일을 얻게 된다. -- `/config/player_initial_lives` -- `/config/ui_properties_file_name` -- `/config/game.properties` -- `/config/user-interface.properties` +## 컨피그맵 사용하기 -`/config` 에 `.properties` 확장자를 가진 파일만 -포함시키려면, 두 개의 다른 컨피그맵을 사용하고, 파드에 -대해서는 `spec` 의 두 컨피그맵을 참조한다. 첫 번째 컨피그맵은 -`player_initial_lives` 와 `ui_properties_file_name` 을 정의한다. 두 번째 -컨피그맵은 kubelet이 `/config` 에 넣는 파일을 정의한다. +컨피그맵은 데이터 볼륨으로 마운트할 수 있다. 컨피그맵은 파드에 직접적으로 +노출되지 않고, 시스템의 다른 부분에서도 사용할 수 있다. 예를 들어, +컨피그맵은 시스템의 다른 부분이 구성을 위해 사용해야 하는 데이터를 보유할 수 있다. {{< note >}} 컨피그맵을 사용하는 가장 일반적인 방법은 동일한 네임스페이스의 @@ -157,12 +164,6 @@ spec: 사용할 수도 있다. {{< /note >}} -## 컨피그맵 사용하기 - -컨피그맵은 데이터 볼륨으로 마운트할 수 있다. 컨피그맵은 파드에 직접적으로 -노출되지 않고, 시스템의 다른 부분에서도 사용할 수 있다. 예를 들어, -컨피그맵은 시스템의 다른 부분이 구성을 위해 사용해야 하는 데이터를 보유할 수 있다. - ### 파드에서 컨피그맵을 파일로 사용하기 파드의 볼륨에서 컨피그맵을 사용하려면 다음을 수행한다. diff --git a/content/ko/docs/concepts/configuration/manage-resources-containers.md b/content/ko/docs/concepts/configuration/manage-resources-containers.md index 1e20865133..3c1414fcd6 100644 --- a/content/ko/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ko/docs/concepts/configuration/manage-resources-containers.md @@ -657,7 +657,7 @@ Allocated resources: (Total limits may be over 100 percent, i.e., overcommitted.) CPU Requests CPU Limits Memory Requests Memory Limits ------------ ---------- --------------- ------------- - 680m (34%) 400m (20%) 920Mi (12%) 1070Mi (14%) + 680m (34%) 400m (20%) 920Mi (11%) 1070Mi (13%) ``` 위의 출력에서, ​파드가 1120m 이상의 CPU 또는 6.23Gi의 메모리를 @@ -758,5 +758,3 @@ LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-0 * [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) API 레퍼런스 읽어보기 * XFS의 [프로젝트 쿼터](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html)에 대해 읽어보기 - - diff --git a/content/ko/docs/concepts/configuration/pod-overhead.md b/content/ko/docs/concepts/configuration/pod-overhead.md index 6b7aa489b1..d4888ecbfb 100644 --- a/content/ko/docs/concepts/configuration/pod-overhead.md +++ b/content/ko/docs/concepts/configuration/pod-overhead.md @@ -11,7 +11,7 @@ weight: 20 노드 위에서 파드를 구동할 때, 파드는 그 자체적으로 많은 시스템 리소스를 사용한다. 이러한 리소스는 파드 내의 컨테이너들을 구동하기 위한 리소스 이외에 추가적으로 필요한 것이다. -_파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파드의 인프라에 의해 +_파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파드의 인프라에 의해 소비되는 리소스를 계산하는 기능이다. @@ -20,25 +20,25 @@ _파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파 -쿠버네티스에서 파드의 오버헤드는 파드의 -[런타임클래스](/ko/docs/concepts/containers/runtime-class/) 와 관련된 오버헤드에 따라 -[어드미션](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) +쿠버네티스에서 파드의 오버헤드는 파드의 +[런타임클래스](/ko/docs/concepts/containers/runtime-class/) 와 관련된 오버헤드에 따라 +[어드미션](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) 이 수행될 때 지정된다. -파드 오버헤드가 활성화 되면, 파드를 노드에 스케줄링 할 때 컨테이너 리소스 요청의 합에 -파드의 오버헤드를 추가해서 스케줄링을 고려한다. 마찬가지로, Kubelet은 파드의 cgroups 크기를 변경하거나 +파드 오버헤드가 활성화 되면, 파드를 노드에 스케줄링 할 때 컨테이너 리소스 요청의 합에 +파드의 오버헤드를 추가해서 스케줄링을 고려한다. 마찬가지로, Kubelet은 파드의 cgroups 크기를 변경하거나 파드의 축출 등급을 부여할 때에도 파드의 오버헤드를 포함하여 고려한다. ## 파드 오버헤드 활성화하기 {#set-up} -기능 활성화를 위해 클러스터에서 -`PodOverhead` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 가 활성화 되어 있고 (1.18 버전에서는 기본적으로 활성화), +기능 활성화를 위해 클러스터에서 +`PodOverhead` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 가 활성화 되어 있고 (1.18 버전에서는 기본적으로 활성화), `overhead` 필드를 정의하는 `RuntimeClass` 가 사용되고 있는지 확인해야 한다. ## 사용 예제 파드 오버헤드 기능을 사용하기 위하여, `overhead` 필드를 정의하는 런타임클래스가 필요하다. -예를 들어, 가상 머신 및 게스트 OS에 대하여 파드 당 120 MiB를 사용하는 +예를 들어, 가상 머신 및 게스트 OS에 대하여 파드 당 120 MiB를 사용하는 가상화 컨테이너 런타임의 런타임클래스의 경우 다음과 같이 정의 할 수 있다. ```yaml @@ -54,7 +54,7 @@ overhead: cpu: "250m" ``` -`kata-fc` 런타임클래스 핸들러를 지정하는 워크로드는 리소스 쿼터 계산, +`kata-fc` 런타임클래스 핸들러를 지정하는 워크로드는 리소스 쿼터 계산, 노드 스케줄링 및 파드 cgroup 크기 조정을 위하여 메모리와 CPU 오버헤드를 고려한다. 주어진 예제 워크로드 test-pod의 구동을 고려해보자. @@ -83,9 +83,9 @@ spec: memory: 100Mi ``` -어드미션 수행 시에, [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)는 -런타임클래스에 기술된 `overhead` 를 포함하기 위하여 워크로드의 PodSpec 항목을 갱신한다. 만약 PodSpec이 이미 해당 필드에 정의되어 있으면, -파드는 거부된다. 주어진 예제에서, 오직 런타임클래스의 이름만이 정의되어 있기 때문에, 어드미션 컨트롤러는 파드가 +어드미션 수행 시에, [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)는 +런타임클래스에 기술된 `overhead` 를 포함하기 위하여 워크로드의 PodSpec 항목을 갱신한다. 만약 PodSpec이 이미 해당 필드에 정의되어 있으면, +파드는 거부된다. 주어진 예제에서, 오직 런타임클래스의 이름만이 정의되어 있기 때문에, 어드미션 컨트롤러는 파드가 `overhead` 를 포함하도록 변경한다. 런타임클래스의 어드미션 수행 후에, 파드의 스펙이 갱신된 것을 확인할 수 있다. @@ -99,11 +99,11 @@ kubectl get pod test-pod -o jsonpath='{.spec.overhead}' map[cpu:250m memory:120Mi] ``` -만약 리소스쿼터 항목이 정의되어 있다면, 컨테이너의 리소스 요청의 합에는 +만약 리소스쿼터 항목이 정의되어 있다면, 컨테이너의 리소스 요청의 합에는 `overhead` 필드도 추가된다. -kube-scheduler 는 어떤 노드에 파드가 기동 되어야 할지를 정할 때, 파드의 `overhead` 와 -해당 파드에 대한 컨테이너의 리소스 요청의 합을 고려한다. 이 예제에서, 스케줄러는 +kube-scheduler 는 어떤 노드에 파드가 기동 되어야 할지를 정할 때, 파드의 `overhead` 와 +해당 파드에 대한 컨테이너의 리소스 요청의 합을 고려한다. 이 예제에서, 스케줄러는 리소스 요청과 파드의 오버헤드를 더하고, 2.25 CPU와 320 MiB 메모리가 사용 가능한 노드를 찾는다. 일단 파드가 특정 노드에 스케줄링 되면, 해당 노드에 있는 kubelet 은 파드에 대한 새로운 {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}을 생성한다. @@ -142,7 +142,7 @@ CPU 2250m와 메모리 320MiB 가 리소스로 요청되었으며, 이 결과는 ## 파드 cgroup 상한 확인하기 -워크로드가 실행 중인 노드에서 파드의 메모리 cgroup들을 확인 해보자. 다음의 예제에서, [`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)은 노드에서 사용되며, +워크로드가 실행 중인 노드에서 파드의 메모리 cgroup들을 확인 해보자. 다음의 예제에서, [`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)은 노드에서 사용되며, CRI-호환 컨테이너 런타임을 위해서 노드에서 사용할 수 있는 CLI 를 제공한다. 파드의 오버헤드 동작을 보여주는 좋은 예이며, 사용자가 노드에서 직접 cgroup들을 확인하지 않아도 된다. @@ -178,8 +178,8 @@ sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath ``` ### 관찰성 -`kube_pod_overhead` 항목은 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) -에서 사용할 수 있어, 파드 오버헤드가 사용되는 시기를 식별하고, +`kube_pod_overhead` 항목은 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) +에서 사용할 수 있어, 파드 오버헤드가 사용되는 시기를 식별하고, 정의된 오버헤드로 실행되는 워크로드의 안정성을 관찰할 수 있다. 이 기능은 kube-state-metrics 의 1.9 릴리스에서는 사용할 수 없지만, 다음 릴리스에서는 가능할 예정이다. 그 전까지는 소스로부터 kube-state-metric 을 빌드해야 한다. @@ -191,5 +191,3 @@ sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath * [런타임클래스](/ko/docs/concepts/containers/runtime-class/) * [파드오버헤드 디자인](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) - - diff --git a/content/ko/docs/concepts/containers/_index.md b/content/ko/docs/concepts/containers/_index.md index bdcb03bde5..76b1756a19 100755 --- a/content/ko/docs/concepts/containers/_index.md +++ b/content/ko/docs/concepts/containers/_index.md @@ -1,5 +1,41 @@ --- -title: "컨테이너" +title: 컨테이너 weight: 40 +description: 런타임 의존성과 함께 애플리케이션을 패키징하는 기술 +content_type: concept +no_list: true --- + + +실행하는 각 컨테이너는 반복 가능하다. 의존성이 포함된 표준화는 +어디에서 실행하던지 동일한 동작을 얻는다는 것을 +의미한다. + +컨테이너는 기본 호스트 인프라에서 애플리케이션을 분리한다. +따라서 다양한 클라우드 또는 OS 환경에서 보다 쉽게 ​​배포할 수 있다. + + + + + + +## 컨테이너 이미지 +[컨테이너 이미지](/ko/docs/concepts/containers/images/)는 애플리케이션을 +실행하는 데 필요한 모든 것이 포함된 실행할 준비가 되어있는(ready-to-run) 소프트웨어 패키지이다. +여기에는 실행하는 데 필요한 코드와 모든 런타임, 애플리케이션 및 시스템 라이브러리, +그리고 모든 필수 설정에 대한 기본값이 포함된다. + +설계 상, 컨테이너는 변경할 수 없다. 이미 실행 중인 컨테이너의 코드를 +변경할 수 없다. 컨테이너화된 애플리케이션이 있고 +변경하려는 경우, 변경 사항이 포함된 새 컨테이너를 빌드한 +다음, 업데이트된 이미지에서 시작하도록 컨테이너를 다시 생성해야 한다. + +## 컨테이너 런타임 + +{{< glossary_definition term_id="container-runtime" length="all" >}} + +## {{% heading "whatsnext" %}} + +* [컨테이너 이미지](/ko/docs/concepts/containers/images/)에 대해 읽어보기 +* [파드](/ko/docs/concepts/workloads/pods/)에 대해 읽어보기 diff --git a/content/ko/docs/concepts/containers/overview.md b/content/ko/docs/concepts/containers/overview.md deleted file mode 100644 index 9fc833a4ca..0000000000 --- a/content/ko/docs/concepts/containers/overview.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: 컨테이너 개요 -content_type: concept -weight: 10 ---- - - - -컨테이너는 런타임에 필요한 종속성과 애플리케이션의 -컴파일 된 코드를 패키징 하는 기술이다. 실행되는 각각의 -컨테이너는 반복해서 사용 가능하다. 종속성이 포함된 표준화를 -통해 컨테이너가 실행되는 환경과 무관하게 항상 동일하게 -동작한다. - -컨테이너는 기본 호스트 인프라 환경에서 애플리케이션의 실행환경을 분리한다. -따라서 다양한 클라우드 환경이나 운영체제에서 쉽게 배포 할 수 있다. - - - - - - -## 컨테이너 이미지 -[컨테이너 이미지](/ko/docs/concepts/containers/images/) 는 즉시 실행할 수 있는 -소프트웨어 패키지이며, 애플리케이션을 실행하는데 필요한 모든 것 -(필요한 코드와 런타임, 애플리케이션 및 시스템 라이브러리 등의 모든 필수 설정에 대한 기본값) -을 포함한다. - -원칙적으로, 컨테이너는 변경되지 않는다. 이미 구동 중인 컨테이너의 -코드를 변경할 수 없다. 컨테이너화 된 애플리케이션이 있고 그 -애플리케이션을 변경하려는 경우, 변경사항을 포함하여 만든 -새로운 이미지를 통해 컨테이너를 다시 생성해야 한다. - -## 컨테이너 런타임 - -{{< glossary_definition term_id="container-runtime" length="all" >}} - - -## {{% heading "whatsnext" %}} - -* [컨테이너 이미지](/ko/docs/concepts/containers/images/)에 대해 읽어보기 -* [파드](/ko/docs/concepts/workloads/pods/)에 대해 읽어보기 - diff --git a/content/ko/docs/concepts/extend-kubernetes/_index.md b/content/ko/docs/concepts/extend-kubernetes/_index.md index ff8525f171..29d8672fca 100644 --- a/content/ko/docs/concepts/extend-kubernetes/_index.md +++ b/content/ko/docs/concepts/extend-kubernetes/_index.md @@ -1,4 +1,206 @@ --- -title: 쿠버네티스 확장하기 +title: 쿠버네티스 확장 weight: 110 +description: 쿠버네티스 클러스터의 동작을 변경하는 다양한 방법 +content_type: concept +no_list: true --- + + + +쿠버네티스는 매우 유연하게 구성할 수 있고 확장 가능하다. 결과적으로 +쿠버네티스 프로젝트를 포크하거나 코드에 패치를 제출할 필요가 +거의 없다. + +이 가이드는 쿠버네티스 클러스터를 사용자 정의하기 위한 옵션을 설명한다. +쿠버네티스 클러스터를 업무 환경의 요구에 맞게 +조정하는 방법을 이해하려는 {{< glossary_tooltip text="클러스터 운영자" term_id="cluster-operator" >}}를 대상으로 한다. +잠재적인 {{< glossary_tooltip text="플랫폼 개발자" term_id="platform-developer" >}} 또는 쿠버네티스 프로젝트 {{< glossary_tooltip text="컨트리뷰터" term_id="contributor" >}}인 개발자에게도 +어떤 익스텐션(extension) 포인트와 패턴이 있는지, +그리고 그것들의 트레이드오프와 제약에 대한 소개 자료로 유용할 것이다. + + + + + + +## 개요 + +사용자 정의 방식은 크게 플래그, 로컬 구성 파일 또는 API 리소스 변경만 포함하는 *구성* 과 추가 프로그램이나 서비스 실행과 관련된 *익스텐션* 으로 나눌 수 있다. 이 문서는 주로 익스텐션에 관한 것이다. + +## 구성 + +*구성 파일* 및 *플래그* 는 온라인 문서의 레퍼런스 섹션에 각 바이너리 별로 문서화되어 있다. + +* [kubelet](/docs/admin/kubelet/) +* [kube-apiserver](/docs/admin/kube-apiserver/) +* [kube-controller-manager](/docs/admin/kube-controller-manager/) +* [kube-scheduler](/docs/admin/kube-scheduler/). + +호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서 플래그 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경 가능한 경우 일반적으로 클러스터 관리자만 변경할 수 있다. 또한 향후 쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시 시작해야 할 수도 있다. 이러한 이유로 다른 옵션이 없는 경우에만 사용해야 한다. + +[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/), [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/policy/pod-security-policy/), [네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및 역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은 *빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는 일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은 선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터 구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 ​​있다. 또한, 이들 API가 안정적인 경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/deprecation-policy/)을 사용할 수 있다. 이러한 이유로 인해 구성 파일과 플래그보다 선호된다. + +## 익스텐션 + +익스텐션은 쿠버네티스를 확장하고 쿠버네티스와 긴밀하게 통합되는 소프트웨어 컴포넌트이다. +이들 컴포넌트는 쿠버네티스가 새로운 유형과 새로운 종류의 하드웨어를 지원할 수 있게 해준다. + +대부분의 클러스터 관리자는 쿠버네티스의 호스팅 또는 배포판 인스턴스를 사용한다. +결과적으로 대부분의 쿠버네티스 사용자는 익스텐션 기능을 설치할 필요가 없고 +새로운 익스텐션 기능을 작성할 필요가 있는 사람은 더 적다. + +## 익스텐션 패턴 + +쿠버네티스는 클라이언트 프로그램을 작성하여 자동화 되도록 설계되었다. +쿠버네티스 API를 읽고 쓰는 프로그램은 유용한 자동화를 제공할 수 있다. +*자동화* 는 클러스터 상에서 또는 클러스터 밖에서 실행할 수 있다. 이 문서의 지침에 따라 +고가용성과 강력한 자동화를 작성할 수 있다. +자동화는 일반적으로 호스트 클러스터 및 매니지드 설치 환경을 포함한 모든 +쿠버네티스 클러스터에서 작동한다. + +쿠버네티스와 잘 작동하는 클라이언트 프로그램을 작성하기 위한 특정 패턴은 *컨트롤러* 패턴이라고 한다. +컨트롤러는 일반적으로 오브젝트의 `.spec`을 읽고, 가능한 경우 수행한 다음 +오브젝트의 `.status`를 업데이트 한다. + +컨트롤러는 쿠버네티스의 클라이언트이다. 쿠버네티스가 클라이언트이고 +원격 서비스를 호출할 때 이를 *웹훅(Webhook)* 이라고 한다. 원격 서비스를 +*웹훅 백엔드* 라고 한다. 컨트롤러와 마찬가지로 웹훅은 장애 지점을 +추가한다. + +웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 한다. +*바이너리 플러그인* 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다. +바이너리 플러그인은 kubelet(예: +[Flex Volume 플러그인](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)과 +[네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))과 +kubectl에서 +사용한다. + +아래는 익스텐션 포인트가 쿠버네티스 컨트롤 플레인과 상호 작용하는 방법을 +보여주는 다이어그램이다. + + + + + + +## 익스텐션 포인트 + +이 다이어그램은 쿠버네티스 시스템의 익스텐션 포인트를 보여준다. + + + + + +1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다. +2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#api-접근-익스텐션) 섹션에 설명되어 있다. +3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/extend-cluster/#사용자-정의-유형) 섹션에 설명된대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다. +4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스케줄러-익스텐션) 섹션에 설명되어 있다. +5. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다. +6. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 한다. [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#네트워크-플러그인)을 사용하면 다양한 파드 네트워킹 구현이 가능하다. +7. kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는 [스토리지 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스토리지-플러그인)을 통해 지원될 수 있다. + +어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다. + + + + + + +## API 익스텐션 +### 사용자 정의 유형 + +새 컨트롤러, 애플리케이션 구성 오브젝트 또는 기타 선언적 API를 정의하고 `kubectl` 과 같은 쿠버네티스 도구를 사용하여 관리하려면 쿠버네티스에 커스텀 리소스를 추가하자. + +애플리케이션, 사용자 또는 모니터링 데이터의 데이터 저장소로 커스텀 리소스를 사용하지 않는다. + +커스텀 리소스에 대한 자세한 내용은 [커스텀 리소스 개념 가이드](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)를 참고하길 바란다. + + +### 새로운 API와 자동화의 결합 + +사용자 정의 리소스 API와 컨트롤 루프의 조합을 [오퍼레이터(operator) 패턴](/ko/docs/concepts/extend-kubernetes/operator/)이라고 한다. 오퍼레이터 패턴은 특정 애플리케이션, 일반적으로 스테이트풀(stateful) 애플리케이션을 관리하는 데 사용된다. 이러한 사용자 정의 API 및 컨트롤 루프를 사용하여 스토리지나 정책과 같은 다른 리소스를 제어할 수도 있다. + +### 빌트인 리소스 변경 + +사용자 정의 리소스를 추가하여 쿠버네티스 API를 확장하면 추가된 리소스는 항상 새로운 API 그룹에 속한다. 기존 API 그룹을 바꾸거나 변경할 수 없다. +API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치지는 않지만 API 접근 익스텐션은 영향을 준다. + + +### API 접근 익스텐션 + +요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/docs/reference/access-authn-authz/controlling-access/)를 참고하길 바란다. + +이러한 각 단계는 익스텐션 포인트를 제공한다. + +쿠버네티스에는 이를 지원하는 몇 가지 빌트인 인증 방법이 있다. 또한 인증 프록시 뒤에 있을 수 있으며 인증 헤더에서 원격 서비스로 토큰을 전송하여 확인할 수 있다(웹훅). 이러한 방법은 모두 [인증 설명서](/docs/reference/access-authn-authz/authentication/)에 설명되어 있다. + +### 인증 + +[인증](/docs/reference/access-authn-authz/authentication/)은 모든 요청의 헤더 또는 인증서를 요청하는 클라이언트의 사용자 이름에 매핑한다. + +쿠버네티스는 몇 가지 빌트인 인증 방법과 필요에 맞지 않는 경우 [인증 웹훅](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 방법을 제공한다. + + +### 인가 + +[인가](/docs/reference/access-authn-authz/webhook/)은 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다. + + +### 동적 어드미션 컨트롤 + +요청이 승인된 후, 쓰기 작업인 경우 [어드미션 컨트롤](/docs/reference/access-authn-authz/admission-controllers/) 단계도 수행된다. 빌트인 단계 외에도 몇 가지 익스텐션이 있다. + +* [이미지 정책 웹훅](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)은 컨테이너에서 실행할 수 있는 이미지를 제한한다. +* 임의의 어드미션 컨트롤 결정을 내리기 위해 일반적인 [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)을 사용할 수 있다. 어드미션 웹훅은 생성 또는 업데이트를 거부할 수 있다. + +## 인프라스트럭처 익스텐션 + + +### 스토리지 플러그인 + +[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md)을 사용하면 +Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도록 함으로써 +빌트인 지원 없이 볼륨 유형을 마운트 할 수 있다. + + +### 장치 플러그인 + +장치 플러그인은 노드가 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)을 +통해 새로운 노드 리소스(CPU 및 메모리와 같은 빌트인 자원 외에)를 +발견할 수 있게 해준다. + + +### 네트워크 플러그인 + +노드-레벨의 [네트워크 플러그인](/docs/admin/network-plugins/)을 통해 다양한 네트워킹 패브릭을 지원할 수 있다. + +### 스케줄러 익스텐션 + +스케줄러는 파드를 감시하고 파드를 노드에 할당하는 특수한 유형의 +컨트롤러이다. 다른 쿠버네티스 컴포넌트를 계속 사용하면서 +기본 스케줄러를 완전히 교체하거나, +[여러 스케줄러](/docs/tasks/administer-cluster/configure-multiple-schedulers/)를 +동시에 실행할 수 있다. + +이것은 중요한 부분이며, 거의 모든 쿠버네티스 사용자는 스케줄러를 수정할 +필요가 없다는 것을 알게 된다. + +스케줄러는 또한 웹훅 백엔드(스케줄러 익스텐션)가 +파드에 대해 선택된 노드를 필터링하고 우선 순위를 지정할 수 있도록 하는 +[웹훅](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)을 +지원한다. + + + + +## {{% heading "whatsnext" %}} + + +* [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에 대해 더 알아보기 +* [동적 어드미션 컨트롤](/docs/reference/access-authn-authz/extensible-admission-controllers/)에 대해 알아보기 +* 인프라스트럭처 익스텐션에 대해 더 알아보기 + * [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) + * [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) +* [kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)에 대해 알아보기 +* [오퍼레이터 패턴](/ko/docs/concepts/extend-kubernetes/operator/)에 대해 알아보기 diff --git a/content/ko/docs/concepts/overview/_index.md b/content/ko/docs/concepts/overview/_index.md index ae91f70ffd..0b3df10062 100755 --- a/content/ko/docs/concepts/overview/_index.md +++ b/content/ko/docs/concepts/overview/_index.md @@ -1,4 +1,5 @@ --- title: "개요" weight: 20 ---- \ No newline at end of file +description: 쿠버네티스와 그 컴포넌트에 대한 하이-레벨(high-level) 개요를 제공한다. +--- diff --git a/content/ko/docs/concepts/overview/working-with-objects/_index.md b/content/ko/docs/concepts/overview/working-with-objects/_index.md index 84ea350c8f..26aa4dc83b 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/_index.md +++ b/content/ko/docs/concepts/overview/working-with-objects/_index.md @@ -2,6 +2,6 @@ title: "쿠버네티스 오브젝트로 작업하기" weight: 40 description: > - 쿠버네티스 오브젝트는 쿠버네티스 시스템의 영구 엔티티이다. 쿠버네티스는 이러한 엔티티들을 사용하여 클러스터의 상태를 나타낸다. + 쿠버네티스 오브젝트는 쿠버네티스 시스템의 영구 엔티티이다. 쿠버네티스는 이러한 엔티티들을 사용하여 클러스터의 상태를 나타낸다. 쿠버네티스 오브젝트 모델과 쿠버네티스 오브젝트를 사용하는 방법에 대해 학습한다. --- diff --git a/content/ko/docs/concepts/policy/_index.md b/content/ko/docs/concepts/policy/_index.md index ae03c565c1..425e725037 100644 --- a/content/ko/docs/concepts/policy/_index.md +++ b/content/ko/docs/concepts/policy/_index.md @@ -1,4 +1,6 @@ --- title: "정책" weight: 90 +description: > + 리소스의 그룹에 적용되도록 구성할 수 있는 정책 --- diff --git a/content/ko/docs/concepts/scheduling-eviction/_index.md b/content/ko/docs/concepts/scheduling-eviction/_index.md index d368e230d7..5cd57c3a29 100644 --- a/content/ko/docs/concepts/scheduling-eviction/_index.md +++ b/content/ko/docs/concepts/scheduling-eviction/_index.md @@ -1,4 +1,7 @@ --- title: "스케줄링과 축출(eviction)" weight: 90 +description: > + 쿠버네티스에서, 스케줄링은 kubelet이 파드를 실행할 수 있도록 파드가 노드와 일치하는지 확인하는 것을 말한다. + 축출은 리소스가 부족한 노드에서 하나 이상의 파드를 사전에 장애로 처리하는 프로세스이다. --- diff --git a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md index 1db0e6a09b..3c0a4c5110 100644 --- a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -95,4 +95,3 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순 * [멀티 스케줄러 구성하기](/docs/tasks/administer-cluster/configure-multiple-schedulers/)에 대해 배우기 * [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기 * [파드 오버헤드](/ko/docs/concepts/configuration/pod-overhead/)에 대해 배우기 - diff --git a/content/ko/docs/concepts/security/_index.md b/content/ko/docs/concepts/security/_index.md index 079e3dd8f8..d71d63c77a 100644 --- a/content/ko/docs/concepts/security/_index.md +++ b/content/ko/docs/concepts/security/_index.md @@ -1,4 +1,6 @@ --- title: "보안" weight: 81 +description: > + 클라우드 네이티브 워크로드를 안전하게 유지하기 위한 개념 --- diff --git a/content/ko/docs/concepts/services-networking/_index.md b/content/ko/docs/concepts/services-networking/_index.md index 101f141102..9cfcfd540b 100644 --- a/content/ko/docs/concepts/services-networking/_index.md +++ b/content/ko/docs/concepts/services-networking/_index.md @@ -1,4 +1,12 @@ --- title: "서비스, 로드밸런싱, 네트워킹" weight: 60 +description: > + 쿠버네티스의 네트워킹에 대한 개념과 리소스에 대해 설명한다. --- + +쿠버네티스 네트워킹은 다음의 네 가지 문제를 해결한다. +- 파드 내의 컨테이너는 루프백(loopback)을 통한 네트워킹을 사용하여 통신한다. +- 클러스터 네트워킹은 서로 다른 파드 간의 통신을 제공한다. +- 서비스 리소스를 사용하면 파드에서 실행 중인 애플리케이션을 클러스터 외부에서 접근할 수 있다. +- 또한 서비스를 사용하여 클러스터 내부에서 사용할 수 있는 서비스만 게시할 수 있다. diff --git a/content/ko/docs/concepts/services-networking/ingress-controllers.md b/content/ko/docs/concepts/services-networking/ingress-controllers.md index 85aebe74af..47d2687dee 100644 --- a/content/ko/docs/concepts/services-networking/ingress-controllers.md +++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md @@ -31,7 +31,7 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 * [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러로 VMware에서 제공하고 지원한다. * Citrix는 [베어메탈](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)과 [클라우드](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) 배포를 위해 하드웨어 (MPX), 가상화 (VPX) 및 [무료 컨테이너화 (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html)를 위한 [인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller)를 제공한다. -* F5 Networks는 [쿠버네티스를 위한 F5 BIG-IP 컨트롤러](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)에 대한 +* F5 Networks는 [쿠버네티스를 위한 F5 BIG-IP 컨테이너 인그레스 서비스](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)에 대한 [지원과 유지 보수](https://support.f5.com/csp/article/K86859508)를 제공한다. * [Gloo](https://gloo.solo.io)는 [solo.io](https://www.solo.io)의 엔터프라이즈 지원과 함께 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의 오픈 소스 인그레스 컨트롤러다. * [HAProxy 인그레스](https://haproxy-ingress.github.io)는 HAProxy를 위한 고도로 커스터마이징 가능한 커뮤니티 주도형 인그레스 컨트롤러다. diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index 1a6de81950..23ab2d1ade 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -88,7 +88,7 @@ spec: 인그레스 [사양](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 에는 로드 밸런서 또는 프록시 서버를 구성하는데 필요한 모든 정보가 있다. 가장 중요한 것은, -들어오는 요청과 일치하는 규칙 목록을 포함하는 것이다. 인그레스 리소스는 HTTP 트래픽을 +들어오는 요청과 일치하는 규칙 목록을 포함하는 것이다. 인그레스 리소스는 HTTP(S) 트래픽을 지시하는 규칙만 지원한다. ### 인그레스 규칙 diff --git a/content/ko/docs/concepts/storage/_index.md b/content/ko/docs/concepts/storage/_index.md index 1e0fb99a5d..dc9ae5cd82 100644 --- a/content/ko/docs/concepts/storage/_index.md +++ b/content/ko/docs/concepts/storage/_index.md @@ -1,5 +1,6 @@ --- title: "스토리지" weight: 70 +description: > + 클러스터의 파드에 장기(long-term) 및 임시 스토리지를 모두 제공하는 방법 --- - diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index 63892d11f4..0e418f414b 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -24,7 +24,7 @@ weight: 20 _퍼시스턴트볼륨_ (PV)은 관리자가 프로비저닝하거나 [스토리지 클래스](/ko/docs/concepts/storage/storage-classes/)를 사용하여 동적으로 프로비저닝한 클러스터의 스토리지이다. 노드가 클러스터 리소스인 것처럼 PV는 클러스터 리소스이다. PV는 Volumes와 같은 볼륨 플러그인이지만, PV를 사용하는 개별 파드와는 별개의 라이프사이클을 가진다. 이 API 오브젝트는 NFS, iSCSI 또는 클라우드 공급자별 스토리지 시스템 등 스토리지 구현에 대한 세부 정보를 담아낸다. -_퍼시스턴트볼륨클레임_ (PVC)은 사용자의 스토리지에 대한 요청이다. 파드와 비슷하다. 파드는 노드 리소스를 사용하고 PVC는 PV 리소스를 사용한다. 파드는 특정 수준의 리소스(CPU 및 메모리)를 요청할 수 있다. 클레임은 특정 크기 및 접근 모드를 요청할 수 있다(예: 한 번 읽기/쓰기 또는 여러 번 읽기 전용으로 마운트 할 수 있음). +_퍼시스턴트볼륨클레임_ (PVC)은 사용자의 스토리지에 대한 요청이다. 파드와 비슷하다. 파드는 노드 리소스를 사용하고 PVC는 PV 리소스를 사용한다. 파드는 특정 수준의 리소스(CPU 및 메모리)를 요청할 수 있다. 클레임은 특정 크기 및 접근 모드를 요청할 수 있다(예: ReadWriteOnce, ReadOnlyMany 또는 ReadWriteMany로 마운트 할 수 있음. [AccessModes](#접근-모드) 참고). 퍼시스턴트볼륨클레임을 사용하면 사용자가 추상화된 스토리지 리소스를 사용할 수 있지만, 다른 문제들 때문에 성능과 같은 다양한 속성을 가진 퍼시스턴트볼륨이 필요한 경우가 일반적이다. 클러스터 관리자는 사용자에게 해당 볼륨의 구현 방법에 대한 세부 정보를 제공하지 않고 단순히 크기와 접근 모드와는 다른 방식으로 다양한 퍼시스턴트볼륨을 제공할 수 있어야 한다. 이러한 요구에는 _스토리지클래스_ 리소스가 있다. diff --git a/content/ko/docs/concepts/workloads/_index.md b/content/ko/docs/concepts/workloads/_index.md index c704540b85..c898502b39 100644 --- a/content/ko/docs/concepts/workloads/_index.md +++ b/content/ko/docs/concepts/workloads/_index.md @@ -1,4 +1,6 @@ --- title: "워크로드" weight: 50 +description: > + 쿠버네티스에서 배포할 수 있는 가장 작은 컴퓨트 오브젝트인 파드와, 이를 실행하는 데 도움이 되는 하이-레벨(higher-level) 추상화 --- diff --git a/content/ko/docs/contribute/_index.md b/content/ko/docs/contribute/_index.md index fb87ebeed6..9034f3d98b 100644 --- a/content/ko/docs/contribute/_index.md +++ b/content/ko/docs/contribute/_index.md @@ -3,6 +3,7 @@ content_type: concept title: 쿠버네티스 문서에 기여하기 linktitle: 기여 main_menu: true +no_list: true weight: 80 card: name: contribute @@ -23,8 +24,6 @@ card: 쿠버네티스 문서는 새롭고 경험이 풍부한 모든 기여자의 개선을 환영합니다! - - ## 시작하기 diff --git a/content/ko/docs/contribute/advanced.md b/content/ko/docs/contribute/advanced.md index 2c4163ab47..55661a6734 100644 --- a/content/ko/docs/contribute/advanced.md +++ b/content/ko/docs/contribute/advanced.md @@ -17,67 +17,6 @@ weight: 98 -## 일주일 동안 PR 랭글러(Wrangler) 되기 - -SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 리포지터리에 대해 1주일 정도씩 [PR을 조정(wrangling)](https://github.com/kubernetes/website/wiki/PR-Wranglers)하는 역할을 맡는다. - -PR 랭글러의 임무는 다음과 같다. - -- [스타일](/docs/contribute/style/style-guide/)과 [콘텐츠](/docs/contribute/style/content-guide/) 가이드를 준수하는지에 대해 [열린(open) 풀 리퀘스트](https://github.com/kubernetes/website/pulls)를 매일 리뷰한다. - - 가장 작은 PR(`size/XS`)을 먼저 리뷰한 다음, 가장 큰(`size/XXL`) PR까지 옮겨가며 리뷰를 반복한다. - - 가능한 한 많은 PR을 리뷰한다. -- 각 기여자가 CLA에 서명했는지 확인한다. - - 새로운 기여자가 [CLA](https://github.com/kubernetes/community/blob/master/CLA.md)에 서명하도록 도와준다. - - CLA에 서명하지 않은 기여자에게 CLA에 서명하도록 자동으로 알리려면 [이](https://github.com/zparnold/k8s-docs-pr-botherer) 스크립트를 사용한다. -- 제안된 변경 사항에 대한 피드백을 제공하고 다른 SIG의 멤버로부터의 기술 리뷰가 잘 진행되게 조율한다. - - 제안된 콘텐츠 변경에 대해 PR에 인라인 제안(inline suggestion)을 제공한다. - - 내용을 확인해야 하는 경우, PR에 코멘트를 달고 자세한 내용을 요청한다. - - 관련 `sig/` 레이블을 할당한다. - - 필요한 경우, 파일의 머리말(front matter)에 있는 `reviewers:` 블록의 리뷰어를 할당한다. - - PR의 리뷰 상태를 표시하기 위해 `Docs Review` 와 `Tech Review` 레이블을 할당한다. - - 아직 리뷰되지 않은 PR에 `Needs Doc Review` 나 `Needs Tech Review` 를 할당한다. - - 리뷰가 진행되었고, 병합하기 전에 추가 입력이나 조치가 필요한 PR에 `Doc Review: Open Issues` 나 `Tech Review: Open Issues` 를 할당한다. - - 병합할 수 있는 PR에 `/lgtm` 과 `/approve` 를 할당한다. -- PR이 준비가 되면 병합하거나, 수락해서는 안되는 PR을 닫는다. - - 콘텐츠가 문서의 [스타일 가이드라인](/docs/contribute/style/style-guide/) 중 일부만 충족하더라도 정확한 기술 콘텐츠를 수락하는 것이 좋다. 스타일 문제를 해결하기 위해 `good first issue` 라는 레이블로 새로운 이슈를 연다. -- 새로운 이슈를 매일 심사하고 태그를 지정한다. SIG Docs가 메타데이터를 사용하는 방법에 대한 지침은 [이슈 심사 및 분류](/ko/docs/contribute/review/for-approvers/#이슈-심사와-분류)를 참고한다. - -## 랭글러에게 유용한 GitHub 쿼리 - -다음의 쿼리는 랭글러에게 도움이 된다. 이 쿼리들을 수행하여 작업한 후에는, 리뷰할 나머지 PR 목록은 -일반적으로 작다. 이 쿼리들은 특히 현지화 PR을 제외하고, `master` 브랜치만 포함한다(마지막 쿼리는 제외). - -- [CLA 서명 없음, 병합할 수 없음](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen): - CLA에 서명하도록 기여자에게 상기시킨다. 봇과 사람이 이미 알렸다면, PR을 닫고 - CLA에 서명한 후 PR을 열 수 있음을 알린다. - **작성자가 CLA에 서명하지 않은 PR은 리뷰하지 않는다!** -- [LGTM 필요](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+): - 기술 리뷰가 필요한 경우, 봇이 제안한 리뷰어 중 한 명을 지정한다. 문서 리뷰나 - 교정이 필요한 경우, 변경 사항을 제안하거나 교정하는 커밋을 PR에 추가하여 진행한다. -- [LGTM 보유, 문서 승인 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm): - PR을 병합하기 위해 추가 변경이나 업데이트가 필요한지 여부를 결정한다. PR을 병합할 준비가 되었다고 생각되면, `/approve` 코멘트를 남긴다. -- [퀵윈(Quick Wins)](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): 명확한 결격 사유가 없는 master에 대한 작은 PR인 경우. ([XS, S, M, L, XL, XXL] 크기의 PR을 작업할 때 크기 레이블에서 "XS"를 변경한다) -- [master 이외의 브랜치에 대한 PR](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): `dev-` 브랜치에 대한 것일 경우, 곧 출시될 예정인 릴리스이다. `/assign @` 을 코멘트로 추가하여 [릴리스 마이스터](https://github.com/kubernetes/sig-release/tree/master/release-team)가 그것에 대해 알고 있는지 확인한다. 오래된 브랜치에 대한 PR인 경우, PR 작성자가 가장 적합한 브랜치를 대상으로 하고 있는지 여부를 파악할 수 있도록 도와준다. - -### 풀 리퀘스트를 종료하는 시기 - -리뷰와 승인은 PR 대기열을 최신 상태로 유지하는 도구 중 하나이다. 또 다른 도구는 종료(closure)이다. - -- CLA가 2주 동안 서명되지 않은 모든 PR을 닫는다. -PR 작성자는 CLA에 서명한 후 PR을 다시 열 수 있으므로, 이는 어떤 것도 CLA 서명없이 병합되지 않게 하는 위험이 적은 방법이다. - -- 작성자가 2주 이상 동안 코멘트나 피드백에 응답하지 않은 모든 PR을 닫는다. - -풀 리퀘스트를 닫는 것을 두려워하지 말자. 기여자는 진행 중인 작업을 쉽게 다시 열고 다시 시작할 수 있다. 종종 종료 통지는 작성자가 기여를 재개하고 끝내도록 자극하는 것이다. - -풀 리퀘스트를 닫으려면, PR에 `/close` 코멘트를 남긴다. - -{{< note >}} - -[`fejta-bot`](https://github.com/fejta-bot)이라는 자동화 서비스는 90일 동안 활동이 없으면 자동으로 이슈를 오래된 것으로 표시한 다음, 그 상태에서 추가로 30일 동안 활동이 없으면 종료한다. PR 랭글러는 14-30일 동안 활동이 없으면 이슈를 닫아야 한다. - -{{< /note >}} - ## 개선 제안 SIG Docs [멤버](/ko/docs/contribute/participating/#멤버)는 개선을 제안할 수 있다. @@ -245,5 +184,3 @@ SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 SIG Docs 녹화를 중지하려면, Stop을 클릭한다. 비디오가 자동으로 유튜브에 업로드된다. - - diff --git a/content/ko/docs/contribute/new-content/open-a-pr.md b/content/ko/docs/contribute/new-content/open-a-pr.md index 3c535edda7..82c72e2ce8 100644 --- a/content/ko/docs/contribute/new-content/open-a-pr.md +++ b/content/ko/docs/contribute/new-content/open-a-pr.md @@ -97,10 +97,12 @@ git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우, ### 로컬 클론 생성 및 업스트림 설정 -3. 터미널 창에서, 포크를 클론한다. +3. 터미널 창에서, 포크를 클론하고 [Docsy Hugo 테마](https://github.com/google/docsy#readme)를 업데이트한다. ```bash git clone git@github.com//website + cd website + git submodule update --init --recursive --depth 1 ``` 4. 새 `website` 디렉터리로 이동한다. `kubernetes/website` 리포지터리를 `upstream` 원격으로 설정한다. @@ -263,18 +265,26 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할 또는, 컴퓨터에 `hugo` 명령을 설치하여 사용한다. -5. [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml)에 지정된 [Hugo](https://gohugo.io/getting-started/installing/) 버전을 설치한다. +1. [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml)에 지정된 [Hugo](https://gohugo.io/getting-started/installing/) 버전을 설치한다. -6. 터미널에서, 쿠버네티스 website 리포지터리로 이동하여 Hugo 서버를 시작한다. +2. website 리포지터리를 업데이트하지 않았다면, `website/themes/docsy` 디렉터리가 비어 있다. +테마의 로컬 복제본이 없으면 사이트를 빌드할 수 없다. website 테마를 업데이트하려면, 다음을 실행한다. + + ```bash + git submodule update --init --recursive --depth 1 + ``` + +3. 터미널에서, 쿠버네티스 website 리포지터리로 이동하여 Hugo 서버를 시작한다. ```bash cd /website - hugo server + hugo server --buildFuture ``` -7. 브라우저의 주소 표시줄에 `https://localhost:1313` 을 입력한다. +4. 웹 브라우저에서 `https://localhost:1313` 으로 이동한다. Hugo는 + 변경 사항을 보고 필요에 따라 사이트를 다시 구축한다. -8. 로컬의 Hugo 인스턴스를 중지하려면, 터미널로 돌아가서 `Ctrl+C` 를 입력하거나, +5. 로컬의 Hugo 인스턴스를 중지하려면, 터미널로 돌아가서 `Ctrl+C` 를 입력하거나,     터미널 창을 닫는다. {{% /tab %}} @@ -498,4 +508,4 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 ## {{% heading "whatsnext" %}} -- 리뷰 프로세스에 대한 자세한 내용은 [리뷰하기](/ko/docs/contribute/reviewing/revewing-prs)를 읽어본다. +- 리뷰 프로세스에 대한 자세한 내용은 [리뷰하기](/ko/docs/contribute/review/reviewing-prs)를 읽어본다. diff --git a/content/ko/docs/contribute/participate/_index.md b/content/ko/docs/contribute/participate/_index.md new file mode 100644 index 0000000000..610815e65b --- /dev/null +++ b/content/ko/docs/contribute/participate/_index.md @@ -0,0 +1,120 @@ +--- +title: SIG Docs에 참여하기 +content_type: concept +weight: 60 +card: + name: contribute + weight: 60 +--- + + + +SIG Docs는 쿠버네티스 프로젝트의 +[분과회(special interest group)](https://github.com/kubernetes/community/blob/master/sig-list.md) +중 하나로, 쿠버네티스 전반에 대한 문서를 작성하고, 업데이트하며 유지보수하는 일을 주로 수행한다. +분과회에 대한 보다 자세한 정보는 +[커뮤니티 GitHub 저장소 내 SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs) +를 참조한다. + +SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다. +누구나 풀 리퀘스트(PR)를 요청할 수 있고, +누구나 콘텐츠에 대해 이슈를 등록하거나 진행 중인 풀 리퀘스트에 코멘트를 등록할 수 있다. + +[멤버](/ko/docs/contribute/participating/roles-and-responsibilities/#멤버), [리뷰어](/ko/docs/contribute/participating/roles-and-responsibilities/#리뷰어), 또는 [승인자](/ko/docs/contribute/participating/roles-and-responsibilities/#승인자)가 될 수 있다. +이런 역할은 변경을 승인하고 커밋할 수 있도록 보다 많은 접근 권한과 이에 상응하는 책임이 수반된다. +쿠버네티스 커뮤니티 내에서 멤버십이 운영되는 방식에 대한 보다 많은 정보를 확인하려면 +[커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md) +문서를 확인한다. + +문서의 나머지에서는 대외적으로 쿠버네티스를 가장 잘 드러내는 수단 중 하나인 쿠버네티스 웹사이트와 +문서를 관리하는 책임을 가지는 SIG Docs에서, +이런 체계가 작동하는 특유의 방식에 대한 윤곽을 잡아보겠다. + + + + + +## SIG Docs 의장 + +SIG Docs를 포함한 각 SIG는, 한 명 이상의 SIG 멤버가 의장 역할을 하도록 선정한다. 이들은 SIG Docs와 +다른 쿠버네티스 조직 간 연락책(point of contact)이 된다. 이들은 쿠버네티스 프로젝트 전반의 조직과 +그 안에서 SIG Docs가 어떻게 운영되는지에 대한 폭넓은 지식을 갖추어야한다. +현재 의장의 목록을 확인하려면 +[리더십](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) +문서를 참조한다. + +## SIG Docs 팀과 자동화 + +SIG Docs의 자동화는 다음의 두 가지 메커니즘에 의존한다. +GitHub 팀과 OWNERS 파일이다. + +### GitHub 팀 + +GitHub의 SIG Docs [팀]에는 두 분류가 있다. + +- 승인자와 리더를 위한 `@sig-docs-{language}-owners` +- 리뷰어를 위한 `@sig-docs-{language}-reviewers` + +그룹의 전원과 의사소통하기 위해서 +각각 GitHub 코멘트에서 그룹의 `@name`으로 참조할 수 있다. + +가끔은 Prow와 GitHub 팀은 정확히 일치하지 않고 중복된다. 이슈, 풀 리퀘스트를 할당하고, PR 승인을 지원하기 위해서 +자동화 시스템이 `OWNERS` 파일의 정보를 활용한다. + +### OWNERS 파일과 전문(front-matter) + +쿠버네티스 프로젝트는 GitHub 이슈와 풀 리퀘스트 자동화와 관련해서 prow라고 부르는 자동화 툴을 사용한다. +[쿠버네티스 웹사이트 리포지터리](https://github.com/kubernetes/website)는 +다음의 두개의 [prow 플러그인](https://github.com/kubernetes/test-infra/tree/master/prow/plugins)을 +사용한다. + +- blunderbuss +- approve + +이 두 플러그인은 `kubernetes/website` GitHub 리포지터리 최상위 수준에 있는 +[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS)와 +[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) +파일을 사용해서 +해당 리포지터리에 대해 prow가 작동하는 방식을 제어한다. + +OWNERS 파일은 SIG Docs 리뷰어와 승인자의 목록을 포함한다. OWNERS 파일은 하위 디렉터리에 있을 수 +있고, 해당 하위 디렉터리와 그 이하의 파일에 대해 리뷰어와 승인자 역할을 수행할 사람을 새로 지정할 수 있다. +일반적인 OWNERS 파일에 대한 보다 많은 정보는 +[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md) +문서를 참고한다. + +추가로, 개별 마크다운(Markdown) 파일 내 전문에 +리뷰어와 승인자를 개별 GitHub 사용자 이름이나 GitHub 그룹으로 열거할 수 있다. + +OWNERS 파일과 마크다운 파일 내 전문의 조합은 +자동화 시스템이 누구에게 기술적, 편집적 리뷰를 요청해야 할지를 +PR 소유자에게 조언하는데 활용된다. + +## 병합 작업 방식 + +풀 리퀘스트 요청이 콘텐츠를 발행하는데 사용하는 +브랜치에 병합되면, 해당 콘텐츠는 http://kubernetes.io 에 공개된다. 게시된 콘텐츠의 +품질을 높히기 위해 SIG Docs 승인자가 풀 리퀘스트를 병합하는 것을 제한한다. +작동 방식은 다음과 같다. + +- 풀 리퀘스트에 `lgtm` 과 `approve` 레이블이 있고, `hold` 레이블이 없고, + 모든 테스트를 통과하면 풀 리퀘스트는 자동으로 병합된다. +- 쿠버네티스 조직의 멤버와 SIG Docs 승인자들은 지정된 풀 리퀘스트의 + 자동 병합을 방지하기 위해 코멘트를 추가할 수 있다(코멘트에 `/hold` 추가 또는 + `/lgtm` 코멘트 보류). +- 모든 쿠버네티스 멤버는 코멘트에 `/lgtm` 을 추가해서 `lgtm` 레이블을 추가할 수 있다. +- SIG Docs 승인자들만이 코멘트에 `/approve` 를 + 추가해서 풀 리퀘스트를 병합할 수 있다. 일부 승인자들은 + [PR Wrangler](/ko/docs/contribute/advanced/#일주일-동안-pr-랭글러-wrangler-되기) 또는 [SIG Docs 의장](#sig-docs-의장)과 + 같은 특정 역할도 수행한다. + + + +## {{% heading "whatsnext" %}} + + +쿠버네티스 문서화에 기여하는 일에 대한 보다 많은 정보는 다음 문서를 참고한다. + +- [신규 콘텐츠 기여하기](/ko/docs/contribute/new-content/overview/) +- [콘텐츠 검토하기](/ko/docs/contribute/review/reviewing-prs/) +- [문서 스타일 가이드](/ko/docs/contribute/style/) diff --git a/content/ko/docs/contribute/participate/pr-wranglers.md b/content/ko/docs/contribute/participate/pr-wranglers.md new file mode 100644 index 0000000000..4581400ea3 --- /dev/null +++ b/content/ko/docs/contribute/participate/pr-wranglers.md @@ -0,0 +1,70 @@ +--- +title: PR 랭글러(PR Wrangler) +content_type: concept +weight: 20 +--- + + + +SIG Docs [승인자](/ko/docs/contribute/participating/roles-and-responsibilites/#승인자)는 리포지터리에 대해 일주일 동안 교대로 [풀 리퀘스트 관리](https://github.com/kubernetes/website/wiki/PR-Wranglers)를 수행한다. + +이 섹션은 PR 랭글러의 의무에 대해 다룬다. 좋은 리뷰 제공에 대한 자세한 내용은 [Reviewing changes](/ko/docs/contribute/review/)를 참고한다. + + + +## 의무 + +PR 랭글러는 일주일 간 매일 다음의 일을 해야 한다. + +- 매일 새로 올라오는 이슈를 심사하고 태그를 지정한다. SIG Docs가 메타데이터를 사용하는 방법에 대한 지침은 [이슈 심사 및 분류](/docs/contribute/review/for-approvers/#triage-and-categorize-issues)를 참고한다. +- [스타일](/docs/contribute/style/style-guide/)과 [콘텐츠](/docs/contribute/style/content-guide/) 가이드를 준수하는지에 대해 [열린(open) 풀 리퀘스트](https://github.com/kubernetes/website/pulls)를 매일 리뷰한다. + - 가장 작은 PR(`size/XS`)부터 시작하고, 가장 큰(`size/XXL`) PR까지 리뷰한다. 가능한 한 많은 PR을 리뷰한다. +- PR 기여자들이 [CLA]()에 서명했는지 확인한다. + - CLA에 서명하지 않은 기여자에게 CLA에 서명하도록 알리려면 [이](https://github.com/zparnold/k8s-docs-pr-botherer) 스크립트를 사용한다. +- 제안된 변경 사항에 대한 피드백을 제공하고 다른 SIG의 멤버에게 기술 리뷰를 요청한다. + - 제안된 콘텐츠 변경에 대해 PR에 인라인 제안(inline suggestion)을 제공한다. + - 내용을 확인해야 하는 경우, PR에 코멘트를 달고 자세한 내용을 요청한다. + - 관련 `sig/` 레이블을 할당한다. + - 필요한 경우, 파일의 머리말(front matter)에 있는 `reviewers:` 블록의 리뷰어를 할당한다. +- PR을 병합하려면 승인을 위한 `approve` 코멘트를 사용한다. 준비가 되면 PR을 병합한다. + - 병합하기 전에 PR은 다른 멤버의 `/lgtm` 코멘트를 받아야 한다. + - [스타일 지침]을 충족하지 않지만 기술적으로는 정확한 PR은 수락하는 것을 고려한다. 스타일 문제를 해결하는 `good first issue` 레이블의 새로운 이슈를 올리면 된다. + +### 랭글러를 위해 도움이 되는 GitHub 쿼리 + +다음의 쿼리는 랭글러에게 도움이 된다. +이 쿼리들을 수행하여 작업한 후에는, 리뷰할 나머지 PR 목록은 일반적으로 작다. +이 쿼리들은 특히 현지화 PR을 제외한다. 모든 쿼리는 마지막 쿼리를 제외하고 메인 브렌치를 대상으로 한다. + +- [CLA 서명 없음, 병합할 수 없음](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen): + CLA에 서명하도록 기여자에게 상기시킨다. 봇과 사람이 이미 알렸다면, PR을 닫고 + CLA에 서명한 후 PR을 열 수 있음을 알린다. + **작성자가 CLA에 서명하지 않은 PR은 리뷰하지 않는다!** +- [LGTM 필요](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+): + 멤버의 LGTM이 필요한 PR을 나열한다. PR에 기술 리뷰가 필요한 경우, 봇이 제안한 리뷰어 중 한 명을 + 지정한다. 콘텐츠에 대한 작업이 필요하다면, 제안하거나 인라인 피드백을 추가한다. +- [LGTM 보유, 문서 승인 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm): + 병합을 위해 `/approve` 코멘트가 필요한 PR을 나열한다. +- [퀵윈(Quick Wins)](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): 명확한 결격 사유가 없는 메인 브랜치에 대한 PR을 나열한다. ([XS, S, M, L, XL, XXL] 크기의 PR을 작업할 때 크기 레이블에서 "XS"를 변경한다) +- [메인 브랜치이외의 브랜치에 대한 PR](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): `dev-` 브랜치에 대한 것일 경우, 곧 출시될 예정인 릴리스이다. `/assign @` 을 사용하여 [문서 릴리스 관리자](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles)를 할당한다. 오래된 브랜치에 대한 PR인 경우, PR 작성자가 가장 적합한 브랜치를 대상으로 하고 있는지 여부를 파악할 수 있도록 도와준다. + +### 풀 리퀘스트를 종료하는 시기 + +리뷰와 승인은 PR 대기열을 최신 상태로 유지하는 도구 중 하나이다. 또 다른 도구는 종료(closure)이다. + +다음의 상황에서 PR을 닫는다. +- 작성자가 CLA에 2주 동안 서명하지 않았다. + + 작성자는 CLA에 서명한 후 PR을 다시 열 수 있다. 이는 어떤 것도 CLA 서명없이 병합되지 않게 하는 위험이 적은 방법이다. + +- 작성자가 2주 이상 동안 코멘트나 피드백에 응답하지 않았다. + +풀 리퀘스트를 닫는 것을 두려워하지 말자. 기여자는 진행 중인 작업을 쉽게 다시 열고 다시 시작할 수 있다. 종종 종료 통지는 작성자가 기여를 재개하고 끝내도록 자극하는 것이다. + +풀 리퀘스트를 닫으려면, PR에 `/close` 코멘트를 남긴다. + +{{< note >}} + +[`fejta-bot`](https://github.com/fejta-bot)이라는 봇은 90일 동안 활동이 없으면 이슈를 오래된 것(stale)으로 표시한다. 30일이 더 지나면 rotten으로 표시하고 종료한다. PR 랭글러는 14-30일 동안 활동이 없으면 이슈를 닫아야 한다. + +{{< /note >}} diff --git a/content/ko/docs/contribute/participate/roles-and-responsibilties.md b/content/ko/docs/contribute/participate/roles-and-responsibilties.md new file mode 100644 index 0000000000..e5dbfb85ff --- /dev/null +++ b/content/ko/docs/contribute/participate/roles-and-responsibilties.md @@ -0,0 +1,195 @@ +--- +title: 역할과 책임 +content_type: concept +weight: 10 +--- + + + +누구나 쿠버네티스에 기여할 수 있다. SIG Docs에 대한 기여가 커짐에 따라, 커뮤니티의 다양한 멤버십을 신청할 수 있다. +이러한 역할을 통해 커뮤니티 내에서 더 많은 책임을 질 수 있다. +각 역할마다 많은 시간과 노력이 필요하다. 역할은 다음과 같다. + +- 모든 사람: 쿠버네티스 문서에 정기적으로 기여하는 기여자 +- 멤버: 이슈를 할당, 심사하고 풀 리퀘스트에 대한 구속력 없는 리뷰를 제공할 수 있다. +- 리뷰어: 문서의 풀 리퀘스트에 대한 리뷰를 리딩할 수 있으며 변경 사항에 대한 품질을 보증할 수 있다. +- 승인자: 문서에 대한 리뷰를 리딩하고 변경 사항을 병합할 수 있다 + + + +## 모든 사람 + +GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG Docs는 모든 새로운 기여자를 환영한다! + +모든 사람은 다음의 작업을 할 수 있다. + +- [`kubernetes/website`](https://github.com/kubernetes/website)를 포함한 모든 [쿠버네티스] 리포지터리에서 이슈를 올린다. +- 풀 리퀘스트에 대해 구속력 없는 피드백을 제공한다. +- 현지화에 기여한다. +- [슬랙](http://slack.k8s.io/) 또는 [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선을 제안한다. + +[CLA에 서명](/ko/docs/contribute/new-content/overview/#sign-the-cla) 후에 누구나 다음을 할 수 있다. + +- 기존 콘텐츠를 개선하거나, 새 콘텐츠를 추가하거나, 블로그 게시물 또는 사례연구 작성을 위해 풀 리퀘스트를 연다. +- 다이어그램, 그래픽 자산 그리고 포함할 수 있는 스크린캐스트와 비디오를 제작한다. + +자세한 내용은 [새로운 콘텐츠 기여하기](/ko/docs/contribute/new-content/)를 참고한다. + +## 멤버 + +멤버는 `kubernetes/website` 에 여러 개의 풀 리퀘스트를 제출한 사람이다. 멤버는 [쿠버네티스 GitHub 조직](https://github.com/kubernetes)의 회원이다. + +멤버는 다음의 작업을 할 수 있다. + +- [모든 사람](#모든-사람)에 나열된 모든 것을 한다. +- 풀 리퀘스트에 `/lgtm` 코멘트를 사용하여 LGTM(looks good to me) 레이블을 추가한다. + + {{< note >}} + `/lgtm` 사용은 자동화를 트리거한다. 만약 구속력 없는 승인을 제공하려면, 단순히 "LGTM" 코멘트를 남기는 것도 좋다! + {{< /note >}} +- `/hold` 코멘트를 사용하여 풀 리퀘스트에 대한 병합을 차단한다. +- `/assign` 코멘트를 사용하여 풀 리퀘스트에 리뷰어를 지정한다. +- 풀 리퀘스트에 구속력 없는 리뷰를 제공한다. +- 자동화를 사용하여 이슈를 심사하고 분류한다. +- 새로운 기능에 대한 문서를 작성한다. + +### 멤버 되기 + +최소 5개의 실질적인 풀 리퀘스트를 제출하고 다른 [요구 사항](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을 충족시킨 후, 다음의 단계를 따른다. + +1. 멤버십을 [후원](/docs/contribute/advanced#sponsor-a-new-contributor)해 줄 두 명의 [리뷰어](#리뷰어) 또는 [승인자](#승인자)를 찾는다. + + [슬랙의 #sig-docs 채널](https://kubernetes.slack.com) 또는 + [SIG Docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에서 후원을 요청한다. + + {{< note >}} + SIG Docs 멤버 개인에게 직접 email을 보내거나 + 슬랙 다이렉트 메시지를 보내지 않는다. 반드시 지원서를 제출하기 전에 후원을 요청해야 한다. + {{< /note >}} + +2. [`kubernetes/org`](https://github.com/kubernetes/org/) 리포지터리에 GitHub 이슈를 등록한다. **Organization Membership Request** 이슈 템플릿을 사용한다. + +3. 후원자에게 GitHub 이슈를 알린다. 다음 중 하나를 수행할 수 있다. + - 이슈에서 후원자의 GitHub 사용자 이름을 코멘트로 추가한다. (`@`) + - 슬랙 또는 이메일을 사용해 이슈 링크를 후원자에게 보낸다. + + 후원자는 `+1` 투표로 여러분의 요청을 승인할 것이다. 후원자가 요청을 승인하면, 쿠버네티스 GitHub 관리자가 여러분을 멤버로 추가한다. 축하한다! + + 만약 멤버십이 수락되지 않으면 피드백을 받게 될 것이다. 피드백의 내용을 해결한 후, 다시 지원하자. + +4. 여러분의 이메일 계정으로 수신된 쿠버네티스 GitHub 조직으로의 초대를 수락한다. + + {{< note >}} + GitHub은 초대를 여러분 계정의 기본 이메일 주소로 보낸다. + {{< /note >}} + +## 리뷰어 + +리뷰어는 열린 풀 리퀘스트를 리뷰할 책임이 있다. 멤버 피드백과는 달리, 여러분은 리뷰어의 피드백을 반드시 해결해야 한다. 리뷰어는 [@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs) GitHub 팀의 멤버이다. + +리뷰어는 다음의 작업을 수행할 수 있다. + +- [모든 사람](#모든-사람)과 [멤버](#멤버)에 나열된 모든 것을 수행한다. +- 풀 리퀘스트 리뷰와 구속력 있는 피드백을 제공한다. + + {{< note >}} + 구속력 없는 피드백을 제공하려면, 코멘트에 "선택 사항: "과 같은 문구를 접두어로 남긴다. + {{< /note >}} + +- 코드에서 사용자 화면 문자열 편집 +- 코드 코멘트 개선 + +여러분은 SIG DOcs 리뷰어이거나, 특정 주제 영역의 문서에 대한 리뷰어일 수 있다. + +### 풀 리퀘스트에 대한 리뷰어 할당 + +자동화 시스템은 모든 풀 리퀘스트에 대해 리뷰어를 할당한다. `/assign +[@_github_handle]` 코멘트를 남겨 특정 사람에게 리뷰를 요청할 수 +있다. + +지정된 리뷰어가 PR에 코멘트를 남기지 않는다면, 다른 리뷰어가 개입할 수 있다. 필요에 따라 기술 리뷰어를 지정할 수도 있다. + +### `/lgtm` 사용하기 + +LGTM은 "Looks good to me"의 약자이며 풀 리퀘스트가 기술적으로 정확하고 병합할 준비가 되었음을 나타낸다. 모든 PR은 리뷰어의 `/lgtm` 코멘트가 필요하고 병합을 위해 승인자의 `/approve` 코멘트가 필요하다. + +리뷰어의 `/lgtm` 코멘트는 구속력 있고 자동화 시스템이 `lgtm` 레이블을 추가하도록 트리거한다. + +### 리뷰어 되기 + +[요건](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer)을 +충족하면, SIG Docs 리뷰어가 될 수 있다. 다른 SIG의 리뷰어는 SIG Docs의 리뷰어 자격에 반드시 별도로 지원해야 한다. + +지원하려면, 다음을 수행한다. + +1. `kubernetes/website` 리포지터리 내 +[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) 파일의 섹션에 +여러분의 GitHub 사용자 이름을 추가하는 풀 리퀘스트를 연다. + + {{< note >}} + 자신을 추가할 위치가 확실하지 않으면, `sig-docs-ko-reviews` 에 추가한다. + {{< /note >}} + +2. PR을 하나 이상의 SIG-Docs 승인자(`sig-docs-{language}-owners` 에 나열된 사용자 이름)에게 지정한다. + +승인되면, SIG Docs 리더가 적당한 GitHub 팀에 여러분을 추가한다. 일단 추가되면, [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이 새로운 풀 리퀘스트에서 리뷰어로 여러분을 할당하고 제안한다. + +## 승인자 + +승인자는 병합하기 위해 풀 리퀘스트를 리뷰하고 승인한다. 승인자는 +[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs) GitHub 팀의 멤버이다. + +승인자는 다음의 작업을 할 수 있다. + +- [모든 사람](#모든-사람), [멤버](#멤버) 그리고 [리뷰어](#리뷰어) 하위의 모든 목록을 할 수 있다. +- 코멘트에 `/approve` 를 사용해서 풀 리퀘스트를 승인하고, 병합해서 기여자의 컨텐츠를 게시한다. +- 스타일 가이드 개선을 제안한다. +- 문서 테스트 개선을 제안한다. +- 쿠버네티스 웹사이트 또는 다른 도구 개선을 제안한다. + +PR에 이미 `/lgtm` 이 있거나, 승인자도 `/lgtm` 코멘트를 남긴다면, PR은 자동으로 병합된다. SIG Docs 승인자는 추가적인 기술 리뷰가 필요치 않는 변경에 대해서만 `/lgtm` 을 남겨야 한다. + + +### 풀 리퀘스트 승인 + +승인자와 SIG Docs 리더는 website 리포지터리로 풀 리퀘스트를 병합할 수 있는 유일한 사람들이다. 이것은 특정한 책임이 따른다. + +- 승인자는 PR들을 리포지터리에 병합하는 `/approve` 명령을 사용할 수 있다. + + {{< warning >}} + 부주의한 머지로 인해 사이트를 파괴할 수 있으므로, 머지할 때에 그 의미를 확인해야 한다. + {{< /warning >}} + +- 제안된 변경이 [컨트리뷰션 가이드 라인](/docs/contribute/style/content-guide/#contributing-content)에 적합한지 확인한다. + + 질문이 생기거나 확실하지 않다면 자유롭게 추가 리뷰를 요청한다. + +- PR을 `/approve` 하기 전에 Netlify 테스트 결과를 검토한다. + + 승인 전에 반드시 Netlify 테스트를 통과해야 한다 + +- 승인 전에 PR에 대한 Netlify 프리뷰 페이지를 방문하여, 제대로 보이는지 확인한다. + +- 주간 로테이션을 위해 [PR Wrangler 로테이션 스케줄](https://github.com/kubernetes/website/wiki/PR-Wranglers)에 참여한다. SIG Docs는 모든 승인자들이 이 로테이션에 참여할 +것으로 기대한다. 자세한 내용은 [PR 랭글러(PR wrangler)](/ko/docs/contribute/participating/pr-wranglers/)를 +참고한다. + +## 승인자 되기 + +[요구 사항](https://github.com/kubernetes/community/blob/master/community-membership.md#approver)을 충족하면 SIG Docs 승인자가 될 수 있다. 다른 SIG의 승인자는 SIG Docs의 승인자 자격에 대해 별도로 신청해야 한다. + +지원하려면 다음을 수행한다. + +1. `kubernetes/website` 리포지터리 내 [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) 파일의 섹션에 자신을 추가하는 풀 리퀘스트를 연다. + + {{< note >}} + 자신을 추가할 위치가 확실하지 않으면, `sig-docs-ko-owners` 에 추가한다. + {{< /note >}} + +2. PR에 한 명 이상의 현재 SIG Docs 승인자를 지정한다. + +승인되면, SIG Docs 리더가 적당한 GitHub 팀에 여러분을 추가한다. 일단 추가되면, [@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이 새로운 풀 리퀘스트에서 승인자로 여러분을 할당하고 제안한다. + +## {{% heading "whatsnext" %}} + +- 모든 승인자가 교대로 수행하는 역할인 [PR 랭글러](/ko/docs/contribute/participating/pr-wranglers)에 대해 읽어보기 diff --git a/content/ko/docs/contribute/participating.md b/content/ko/docs/contribute/participating.md deleted file mode 100644 index 0b4c34aee8..0000000000 --- a/content/ko/docs/contribute/participating.md +++ /dev/null @@ -1,314 +0,0 @@ ---- -title: SIG Docs에 참여하기 -content_type: concept -weight: 60 -card: - name: contribute - weight: 60 ---- - - - -SIG Docs는 쿠버네티스 프로젝트의 -[분과회(special interest group)](https://github.com/kubernetes/community/blob/master/sig-list.md) -중 하나로, 쿠버네티스 전반에 대한 문서를 작성하고, 업데이트하며 유지보수하는 일을 주로 수행한다. -분과회에 대한 보다 자세한 정보는 -[커뮤니티 GitHub 저장소 내 SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs) -를 참조한다. - -SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다. -누구나 풀 리퀘스트(PR)를 요청할 수 있고, -누구나 콘텐츠에 대해 이슈를 등록하거나 진행 중인 풀 리퀘스트에 코멘트를 등록할 수 있다. - -[멤버](#멤버), [리뷰어](#리뷰어), 또는 [승인자](#승인자)가 될 수 있다. -이런 역할은 변경을 승인하고 커밋할 수 있도록 보다 많은 접근 권한과 이에 상응하는 책임이 수반된다. -쿠버네티스 커뮤니티 내에서 멤버십이 운영되는 방식에 대한 보다 많은 정보를 확인하려면 -[커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md) -문서를 확인한다. - -문서의 나머지에서는 대외적으로 쿠버네티스를 가장 잘 드러내는 수단 중 하나인 쿠버네티스 웹사이트와 -문서를 관리하는 책임을 가지는 SIG Docs에서, -이런 체계가 작동하는 특유의 방식에 대한 윤곽을 잡아보겠다. - - - - - -## 역할과 책임 - -- **모든 사람** 은 쿠버네티스 문서에 기여할 수 있다. 기여 시 [CLA에 서명](/ko/docs/contribute/new-content/overview/#sign-the-cla)하고 GitHub 계정을 가지고 있어야 한다. -- 쿠버네티스 조직의 **멤버** 는 쿠버네티스 프로젝트에 시간과 노력을 투자한 기여자이다. 일반적으로 승인되는 변경이 되는 풀 리퀘스트를 연다. 멤버십 기준은 [커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md)을 참조한다. -- SIG Docs의 **리뷰어** 는 쿠버네티스 조직의 일원으로 - 문서 풀 리퀘스트에 관심을 표명했고, SIG Docs 승인자에 - 의해 GitHub 리포지터리에 있는 GitHub - 그룹과 `OWNER` 파일에 추가되었다. -- SIG Docs의 **승인자** 는 프로젝트에 대한 지속적인 헌신을 보여준 - 좋은 멤버이다. 승인자는 쿠버네티스 조직을 대신해서 - 풀 리퀘스트를 병합하고 컨텐츠를 게시할 수 있다. - 또한 승인자는 더 큰 쿠버네티스 커뮤니티의 SIG Docs를 대표할 수 있다. - 릴리즈 조정과 같은 SIG Docs 승인자의 일부 의무에는 - 상당한 시간 투입이 필요하다. - -## 모든 사람 - -누구나 다음 작업을 할 수 있다. - -- 문서를 포함한 쿠버네티스의 모든 부분에 대해 GitHub 이슈 열기. -- 풀 리퀘스트에 대한 구속력 없는 피드백 제공 -- 기존 컨텐츠를 현지화하는데 도움주는 것 -- [슬랙](http://slack.k8s.io/) 또는 [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선할 아이디어를 제시한다. -- `/lgtm` Prow 명령 ("looks good to me" 의 줄임말)을 사용해서 병합을 위한 풀 리퀘스트의 변경을 추천한다. - {{< note >}} - 만약 쿠버네티스 조직의 멤버가 아니라면, `/lgtm` 을 사용하는 것은 자동화된 시스템에 아무런 영향을 주지 않는다. - {{< /note >}} - -[CLA에 서명](/ko/docs/contribute/new-content/overview/#sign-the-cla) 후에 누구나 다음을 할 수 있다. -- 기존 콘텐츠를 개선하거나, 새 콘텐츠를 추가하거나, 블로그 게시물 또는 사례연구 작성을 위해 풀 리퀘스트를 연다. - -## 멤버 - -멤버는 [멤버 기준](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을 충족하는 쿠버네티스 프로젝트에 기여한 사람들이다. SIG Docs는 쿠버네티스 커뮤니티의 모든 멤버로부터 기여를 환경하며, -기술적 정확성에 대한 다른 SIG 멤버들의 검토를 수시로 요청한다. - -쿠버네티스 조직의 모든 멤버는 다음 작업을 할 수 있다. - -- [모든 사람](#모든-사람) 하위에 나열된 모든 것 -- 풀 리퀘스트 코멘트에 `/lgtm` 을 사용해서 LGTM(looks good to me) 레이블을 붙일 수 있다. -- 풀 리퀘스트에 이미 LGTM 과 승인 레이블이 있는 경우에 풀 리퀘스트가 병합되지 않도록 코멘트에 `/hold` 를 사용할 수 있다. -- 코멘트에 `/assign` 을 사용해서 풀 리퀘스트에 리뷰어를 배정한다. - -### 멤버 되기 - -최소 5개의 실질적인 풀 리퀘스트를 성공적으로 제출한 경우, 쿠버네티스 조직의 -[멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을 -요청할 수 있다. 다음의 단계를 따른다. - -1. 멤버십을 [후원](/docs/contribute/advanced#sponsor-a-new-contributor)해 줄 두 명의 리뷰어 또는 승인자를 - 찾는다. - - [쿠버네티스 Slack 인스턴스의 #sig-docs 채널](https://kubernetes.slack.com) 또는 - [SIG Docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에서 - 후원을 요청한다. - - {{< note >}} - SIG Docs 멤버 개인에게 직접 email을 보내거나 - Slack 다이렉트 메시지를 보내지 않는다. - {{< /note >}} - -2. `kubernetes/org` 리포지터리에 멤버십을 요청하는 GitHub 이슈를 등록한다. - [커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md) - 문서의 가이드라인을 따라서 양식을 채운다. - -3. 해당 GitHub 이슈에 후원자를 at-mentioning(`@`을 포함한 코멘트를 추가)하거나 - 링크를 직접 보내주어서 - 후원자가 해당 GitHub 이슈를 확인하고 `+1` 표를 줄 수 있도록 한다. - -4. 멤버십이 승인되면, 요청에 할당된 GitHub 관리자 팀 멤버가 승인되었음을 업데이트해주고 - 해당 GitHub 이슈를 종료한다. - 축하한다, 이제 멤버가 되었다! - -만약 멤버십 요청이 받아들여지지 않으면, -멤버십 위원회에서 재지원 전에 -필요한 정보나 단계를 알려준다. - -## 리뷰어 - -리뷰어는 -[@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) -GitHub 그룹의 멤버이다. 리뷰어는 문서 풀 리퀘스트를 리뷰하고 제안받은 변경에 대한 피드백을 -제공한다. 리뷰어는 다음 작업을 수행할 수 있다. - -- [모든 사람](#모든-사람)과 [멤버](#멤버)에 나열된 모든 것을 수행 -- 새 기능의 문서화 -- 이슈 해결 및 분류 -- 풀 리퀘스트 리뷰와 구속력있는 피드백 제공 -- 다이어그램, 그래픽 자산과 포함가능한 스크린샷과 비디오를 생성 -- 코드에서 사용자 화면 문자열 편집 -- 코드 코멘트 개선 - -### 풀 리퀘스트에 대한 리뷰어 할당 - -자동화 시스템은 풀 리퀘스트에 대해 리뷰어를 할당하고, 사용자는 해당 풀 리퀘스트에 -`/assign [@_github_handle]` 코멘트를 남겨서 특정 리뷰어에게 리뷰를 요청할 수 있다. -풀 리퀘스트가 기술적으로 정확하고 더 변경이 필요하지 않다는 의미로, -리뷰어는 `/lgtm` 코멘트를 -해당 풀 리퀘스트에 추가할 수 있다. - -할당된 리뷰어가 내용을 아직 리뷰하지 않은 경우, -다른 리뷰어가 나설 수 있다. 추가로, 기술 리뷰어를 -할당해서 그들이 `/lgtm`을 주기를 기다릴 수도 있다. - -사소한 변경이나 기술적 리뷰가 필요한 PR의 경우, SIG Docs [승인자](#승인자)가 `/lgtm`을 줄 -수도 있다. - -리뷰어의 `/approve` 코멘트는 자동화 시스템에서 무시된다. - -### 리뷰어 되기 - -[요건](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer)을 -충족하면, SIG Docs 리뷰어가 될 수 있다. -다른 SIG의 리뷰어는 SIG Docs의 리뷰어 자격에 -반드시 별도로 지원해야 한다. - -지원하려면, `kubernetes/website` 저장소의 -[최상위 OWNERS 파일](https://github.com/kubernetes/website/blob/master/OWNERS) -내 `reviewers` 섹션에 자신을 추가하는 풀 리퀘스트를 연다. PR을 한 명 이상의 현재 SIG Docs -승인자에게 할당한다. - -풀 리퀘스트가 승인되면, 이제 SIG Docs 리뷰어가 된다. -[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이 -새로운 풀 리퀘스트에 대한 리뷰어로 당신을 추천하게 된다. - -일단 승인되면, 현재 SIG Docs 승인자가 -[@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) -GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-admins` GitHub 그룹의 -멤버만이 신규 멤버를 GitHub 그룹에 추가할 수 있다. - -## 승인자 - -승인자는 -[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) -GitHub 그룹의 멤버이다. [SIG Docs 팀과 자동화](#sig-docs-팀과-자동화) 문서를 참조한다. - -승인자는 다음의 작업을 할 수 있다. - -- [모든 사람](#모든-사람), [멤버](#멤버) 그리고 [리뷰어](#리뷰어) 하위의 모든 목록을 할 수 있다. -- 코멘트에 `/approve` 를 사용해서 풀 리퀘스트를 승인하고, 병합해서 기여자의 컨텐츠를 게시한다. - 만약 승인자가 아닌 사람이 코멘트에 승인을 남기면 자동화 시스템에서 이를 무시한다. -- 쿠버네티스 릴리즈팀에 문서 담당자로 참여 -- 스타일 가이드 개선 제안 -- 문서 테스트 개선 제안 -- 쿠버네티스 웹사이트 또는 다른 도구 개선 제안 - -PR이 이미 `/lgtm`을 받았거나, 승인자가 `/lgtm`을 포함한 코멘트를 남긴 경우에는 -해당 PR이 자동으로 머지된다. SIG Docs 승인자는 추가적인 기술 리뷰가 필요하지 않은 변경에 대해서만 -`/lgtm`을 남겨야한다. - -### 승인자 되기 - -[요건](https://github.com/kubernetes/community/blob/master/community-membership.md#approver)을 -충족하면, SIG Docs 승인자가 될 수 있다. -다른 SIG의 승인자는 SIG Docs의 승인자 자격에 -반드시 별도로 지원해야 한다. - -지원하려면, `kubernetes/website` 저장소의 -[최상위 OWNERS 파일](https://github.com/kubernetes/website/blob/master/OWNERS) -내 `approvers` 섹션에 자신을 추가하는 풀 리퀘스트를 연다. PR을 한 명 이상의 현재 SIG Docs -승인자에게 할당한다. - -풀 리퀘스트가 승인되면, 이제 SIG Docs 승인자가 된다. -[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이 -새로운 풀 리퀘스트에 대한 리뷰어로 당신을 추천하게 된다. - -일단 승인되면, 현재 SIG Docs 승인자가 -[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) -GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-admins` GitHub 그룹의 -멤버만이 신규 멤버를 GitHub 그룹에 추가할 수 있다. - -### 승인자의 책임 - -승인자는 리뷰와 풀리퀘스트를 웹사이트 리포지터리에 머지하여 문서를 개선한다. 이 역할에는 추가적인 권한이 필요하므로, 승인자에게는 별도의 책임이 부여된다. - -- 승인자는 PR들을 리포에 머지하는 `/approve` 명령을 사용할 수 있다. - - 부주의한 머지로 인해 사이트를 파괴할 수 있으므로, 머지할 때에 그 의미를 확인해야 한다. - -- 제안된 변경이 [컨트리뷰션 가이드 라인](/docs/contribute/style/content-guide/#contributing-content)에 적합한지 확인한다. - - 질문이 생기거나 확실하지 않다면 자유롭게 추가 리뷰를 요청한다. - -- PR을 `/approve` 하기 전에 Netlify 테스트 결과를 검토한다. - - 승인 전에 반드시 Netlify 테스트를 통과해야 한다 - -- 승인 전에 PR에 대한 Netlify 프리뷰 페이지를 방문하여, 제대로 보이는지 확인한다. - -- 주간 로테이션을 위해 [PR Wrangler 로테이션 스케줄](https://github.com/kubernetes/website/wiki/PR-Wranglers)에 참여한다. SIG Docs는 모든 승인자들이 이 로테이션에 참여할 -것으로 기대한다. [일주일 간 PR Wrangler 되기](/ko/docs/contribute/advanced/#일주일-동안-pr-랭글러-wrangler-되기) -문서를 참고한다. - -## SIG Docs 의장 - -SIG Docs를 포함한 각 SIG는, 한 명 이상의 SIG 멤버가 의장 역할을 하도록 선정한다. 이들은 SIG Docs와 -다른 쿠버네티스 조직 간 연락책(point of contact)이 된다. 이들은 쿠버네티스 프로젝트 전반의 조직과 -그 안에서 SIG Docs가 어떻게 운영되는지에 대한 폭넓은 지식을 갖추어야한다. -현재 의장의 목록을 확인하려면 -[리더십](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) -문서를 참조한다. - -## SIG Docs 팀과 자동화 - -SIG Docs의 자동화는 다음의 두 가지 자동화 메커니즘에 의존한다. -GitHub 그룹과 OWNERS 파일이다. - -### GitHub 그룹 - -GitHub의 SIG Docs 그룹은 두 팀을 정의한다. - - - [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) - - [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) - -그룹의 전원과 의사소통하기 위해서 -각각 GitHub 코멘트에서 그룹의 `@name`으로 참조할 수 있다. - -이 팀은 중복되지만, 정확히 일치하지는 않으며, 이 그룹은 자동화 툴에서 사용된다. -이슈, 풀 리퀘스트를 할당하고, -PR 승인을 지원하기 위해서 자동화 시스템이 OWNERS 파일의 정보를 활용한다. - -### OWNERS 파일과 전문(front-matter) - -쿠버네티스 프로젝트는 GitHub 이슈와 풀 리퀘스트 자동화와 관련해서 prow라고 부르는 자동화 툴을 사용한다. -[쿠버네티스 웹사이트 리포지터리](https://github.com/kubernetes/website)는 -다음의 두개의 [prow 플러그인](https://github.com/kubernetes/test-infra/tree/master/prow/plugins)을 -사용한다. - -- blunderbuss -- approve - -이 두 플러그인은 `kubernetes/website` GitHub 리포지터리 최상위 수준에 있는 -[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS)와 -[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) -파일을 사용해서 -해당 리포지터리에 대해 prow가 작동하는 방식을 제어한다. - -OWNERS 파일은 SIG Docs 리뷰어와 승인자의 목록을 포함한다. OWNERS 파일은 하위 디렉터리에 있을 수 -있고, 해당 하위 디렉터리와 그 이하의 파일에 대해 리뷰어와 승인자 역할을 수행할 사람을 새로 지정할 수 있다. -일반적인 OWNERS 파일에 대한 보다 많은 정보는 -[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md) -문서를 참고한다. - -추가로, 개별 마크다운(Markdown) 파일 내 전문에 -리뷰어와 승인자를 개별 GitHub 사용자 이름이나 GitHub 그룹으로 열거할 수 있다. - -OWNERS 파일과 마크다운 파일 내 전문의 조합은 -자동화 시스템이 누구에게 기술적, 편집적 리뷰를 요청해야 할지를 -PR 소유자에게 조언하는데 활용된다. - -## 병합 작업 방식 - -풀 리퀘스트 요청이 콘텐츠(현재 `master`)를 발행하는데 사용하는 -브랜치에 병합되면 그 내용이 전 세계에 공개된다. 게시된 콘텐츠의 -품질을 높히기 위해 SIG Docs 승인자가 풀 리퀘스트를 병합하는 것을 제한한다. -작동 방식은 다음과 같다. - -- 풀 리퀘스트에 `lgtm` 과 `approve` 레이블이 있고, `hold` 레이블이 없고, - 모든 테스트를 통과하면 풀 리퀘스트는 자동으로 병합된다. -- 쿠버네티스 조직의 멤버와 SIG Docs 승인자들은 지정된 풀 리퀘스트의 - 자동 병합을 방지하기 위해 코멘트를 추가할 수 있다(코멘트에 `/hold` 추가 또는 - `/lgtm` 코멘트 보류). -- 모든 쿠버네티스 멤버는 코멘트에 `/lgtm` 을 추가해서 `lgtm` 레이블을 추가할 수 있다. -- SIG Docs 승인자들만이 코멘트에 `/approve` 를 - 추가해서 풀 리퀘스트를 병합할 수 있다. 일부 승인자들은 - [PR Wrangler](/ko/docs/contribute/advanced/#일주일-동안-pr-랭글러-wrangler-되기) 또는 [SIG Docs 의장](#sig-docs-의장)과 - 같은 특정 역할도 수행한다. - - - -## {{% heading "whatsnext" %}} - - -쿠버네티스 문서화에 기여하는 일에 대한 보다 많은 정보는 다음 문서를 참고한다. - -- [신규 콘텐츠 기여하기](/ko/docs/contribute/new-content/overview/) -- [콘텐츠 검토하기](/ko/docs/contribute/review/reviewing-prs/) -- [문서 스타일 가이드](/ko/docs/contribute/style/) diff --git a/content/ko/docs/contribute/style/write-new-topic.md b/content/ko/docs/contribute/style/write-new-topic.md index a2a36ee0c8..9bff308df1 100644 --- a/content/ko/docs/contribute/style/write-new-topic.md +++ b/content/ko/docs/contribute/style/write-new-topic.md @@ -28,9 +28,17 @@ weight: 20 튜토리얼 | 튜토리얼 페이지는 여러 쿠버네티스의 특징들을 하나로 묶어서 목적을 달성하는 방법을 보여준다. 튜토리얼은 독자들이 페이지를 읽을 때 실제로 할 수 있는 몇 가지 단계의 순서를 제공한다. 또는 관련 코드 일부에 대한 설명을 제공할 수도 있다. 예를 들어 튜토리얼은 코드 샘플의 연습을 제공할 수 있다. 튜토리얼에는 쿠버네티스의 특징에 대한 간략한 설명이 포함될 수 있지만 개별 기능에 대한 자세한 설명은 관련 개념 문서과 연결지어야 한다. {{< /table >}} +### 새 페이지 작성 + 작성하는 각각의 새 페이지에 대해 [콘텐츠 타입](/docs/contribute/style/page-content-types/)을 -사용하자. 페이지 타입을 사용하면 -지정된 타입의 문서 간에 일관성을 보장할 수 있다. +사용하자. 문서 사이트는 새 콘텐츠 페이지를 작성하기 위한 템플리트 또는 +[Hugo archetypes](https://gohugo.io/content-management/archetypes/)을 +제공한다. 새로운 타입의 페이지를 작성하려면, 작성하려는 파일의 경로로 `hugo new` 를 +실행한다. 예를 들면, 다음과 같다. + +``` +hugo new docs/concepts/my-first-concept.md +``` ## 제목과 파일 이름 선택 diff --git a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md index 1d344c0cb5..1e2796b484 100644 --- a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md @@ -129,12 +129,14 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `RuntimeClass` | `false` | 알파 | 1.12 | 1.13 | | `RuntimeClass` | `true` | 베타 | 1.14 | | | `SCTPSupport` | `false` | 알파 | 1.12 | | -| `ServiceAppProtocol` | `false` | 알파 | 1.18 | | | `ServerSideApply` | `false` | 알파 | 1.14 | 1.15 | | `ServerSideApply` | `true` | 베타 | 1.16 | | +| `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | | +| `ServiceAppProtocol` | `false` | 알파 | 1.18 | | | `ServiceNodeExclusion` | `false` | 알파 | 1.8 | | | `ServiceTopology` | `false` | 알파 | 1.17 | | -| `StartupProbe` | `false` | 알파 | 1.16 | | +| `StartupProbe` | `false` | 알파 | 1.16 | 1.17 | +| `StartupProbe` | `true` | 베타 | 1.18 | | | `StorageVersionHash` | `false` | 알파 | 1.14 | 1.14 | | `StorageVersionHash` | `true` | 베타 | 1.15 | | | `StreamingProxyRedirects` | `false` | 베타 | 1.5 | 1.5 | @@ -412,7 +414,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `ExperimentalCriticalPodAnnotation`: 특정 파드에 *critical* 로 어노테이션을 달아서 [스케줄링이 보장되도록](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 한다. 이 기능은 v1.13부터 파드 우선 순위 및 선점으로 인해 사용 중단되었다. - `ExperimentalHostUserNamespaceDefaultingGate`: 사용자 네임스페이스를 호스트로 - 기본 활성화한다. 이것은 다른 호스트 네임스페이스, 호스트 마운트, + 기본 활성화한다. 이것은 다른 호스트 네임스페이스, 호스트 마운트, 권한이 있는 컨테이너 또는 특정 비-네임스페이스(non-namespaced) 기능(예: `MKNODE`, `SYS_MODULE` 등)을 사용하는 컨테이너를 위한 것이다. 도커 데몬에서 사용자 네임스페이스 재 매핑이 활성화된 경우에만 활성화해야 한다. @@ -472,6 +474,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `ScheduleDaemonSetPods`: 데몬셋(DaemonSet) 컨트롤러 대신 기본 스케줄러로 데몬셋 파드를 스케줄링할 수 있다. - `SCTPSupport`: SCTP를 `Service`, `Endpoint`, `NetworkPolicy` 및 `Pod` 정의에서 `protocol` 값으로 사용하는 것을 활성화한다. - `ServerSideApply`: API 서버에서 [SSA(Sever Side Apply)](/docs/reference/using-api/api-concepts/#server-side-apply) 경로를 활성화한다. +- `ServiceAccountIssuerDiscovery`: API 서버에서 서비스 어카운트 발행자에 대해 OIDC 디스커버리 엔드포인트(발급자 및 JWKS URL)를 활성화한다. 자세한 내용은 [파드의 서비스 어카운트 구성](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)을 참고한다. - `ServiceAppProtocol`: 서비스와 엔드포인트에서 `AppProtocol` 필드를 활성화한다. - `ServiceLoadBalancerFinalizer`: 서비스 로드 밸런서에 대한 Finalizer 보호를 활성화한다. - `ServiceNodeExclusion`: 클라우드 제공자가 생성한 로드 밸런서에서 노드를 제외할 수 있다. diff --git a/content/ko/docs/reference/glossary/volume.md b/content/ko/docs/reference/glossary/volume.md index 651b81d1d2..6aa9985eb0 100755 --- a/content/ko/docs/reference/glossary/volume.md +++ b/content/ko/docs/reference/glossary/volume.md @@ -6,16 +6,15 @@ full_link: /ko/docs/concepts/storage/volumes/ short_description: > 데이터를 포함하고 있는 디렉터리이며, 파드의 컨테이너에서 접근 가능하다. -aka: +aka: tags: - core-object - fundamental --- 데이터를 포함하고 있는 디렉터리이며, {{< glossary_tooltip text="파드" term_id="pod" >}}의 {{< glossary_tooltip text="컨테이너" term_id="container" >}}에서 접근 가능하다. - + 쿠버네티스 볼륨은 그것을 포함하고 있는 파드만큼 오래 산다. 결과적으로, 볼륨은 파드 안에서 실행되는 모든 컨테이너 보다 오래 지속되며, 데이터는 컨테이너의 재시작 간에도 보존된다. -더 많은 정보는 [스토리지](https://kubernetes.io/ko/docs/concepts/storage/)를 본다. - +더 많은 정보는 [스토리지](/ko/docs/concepts/storage/)를 본다. diff --git a/content/ko/docs/setup/_index.md b/content/ko/docs/setup/_index.md index 098ed2c7ba..b09963d0e2 100644 --- a/content/ko/docs/setup/_index.md +++ b/content/ko/docs/setup/_index.md @@ -16,30 +16,17 @@ card: -본 섹션에서는 쿠버네티스를 구축하고 실행하는 여러가지 옵션을 다룬다. - -각각의 쿠버네티스 솔루션은 유지보수의 용이성, 보안, 제어, 가용 자원, 클러스터를 운영하고 관리하기 위해 필요한 전문성과 같은 제각각의 요구사항을 충족한다. - -쿠버네티스 클러스터를 로컬 머신에, 클라우드에, 온-프레미스 데이터센터에 배포할 수 있고, 아니면 매니지드 쿠버네티스 클러스터를 선택할 수도 있다. 넓은 범위의 클라우드 프로바이더에 걸치거나 베어 메탈 환경을 사용하는 커스텀 솔루션을 만들 수도 있다. - -더 간단하게 정리하면, 쿠버네티스 클러스터를 학습 환경과 운영 환경에 만들 수 있다. - +본 섹션에는 쿠버네티스를 설정하고 실행하는 다양한 방법이 나열되어 있다. +쿠버네티스를 설치할 때는 유지보수의 용이성, 보안, 제어, 사용 가능한 리소스, 그리고 +클러스터를 운영하고 관리하기 위해 필요한 전문성을 기반으로 설치 유형을 선택한다. +쿠버네티스 클러스터를 로컬 머신에, 클라우드에, 온-프레미스 데이터센터에 배포할 수 있고, 아니면 매니지드 쿠버네티스 클러스터를 선택할 수도 있다. 광범위한 클라우드 제공 업체 또는 베어 메탈 환경에 걸쳐 사용할 수 있는 맞춤형 솔루션도 있다. ## 학습 환경 -쿠버네티스를 배우고 있다면, 쿠버네티스 커뮤니티에서 지원하는 도구나, 로컬 머신에서 쿠버네티스를 설치하기 위한 생태계 내의 도구와 같은 도커 기반의 솔루션을 사용하자. - -{{< table caption="쿠버네티스를 배포하기 위해 커뮤니티와 생태계에서 지원하는 도구를 나열한 로컬 머신 솔루션 표." >}} - -|커뮤니티 |생태계 | -| ------------ | -------- | -| [Minikube](/ko/docs/setup/learning-environment/minikube/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| -| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Minishift](https://docs.okd.io/latest/minishift/)| -| | [MicroK8s](https://microk8s.io/)| - +쿠버네티스를 배우고 있다면, 쿠버네티스 커뮤니티에서 지원하는 도구나, 로컬 머신에서 쿠버네티스를 설치하기 위한 생태계 내의 도구를 사용하자. ## 운영 환경 diff --git a/content/ko/docs/setup/production-environment/tools/kops.md b/content/ko/docs/setup/production-environment/tools/kops.md index 3fc7d975b7..644ca5dae4 100644 --- a/content/ko/docs/setup/production-environment/tools/kops.md +++ b/content/ko/docs/setup/production-environment/tools/kops.md @@ -27,7 +27,7 @@ kops는 자동화된 프로비저닝 시스템인데, * 반드시 64-bit (AMD64 그리고 Intel 64)디바이스 아키텍쳐 위에서 `kops` 를 [설치](https://github.com/kubernetes/kops#installing) 한다. -* [AWS 계정](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html)이 있고 [IAM 키](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys)를 생성하고 [구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration) 해야 한다. +* [AWS 계정](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html)이 있고 [IAM 키](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys)를 생성하고 [구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration)해야 한다. IAM 사용자는 [적절한 권한](https://github.com/kubernetes/kops/blob/master/docs/getting_started/aws.md#setup-iam-user)이 필요하다. diff --git a/content/ko/docs/setup/release/notes.md b/content/ko/docs/setup/release/notes.md index 3bc3dad135..a0cd9168a1 100644 --- a/content/ko/docs/setup/release/notes.md +++ b/content/ko/docs/setup/release/notes.md @@ -86,7 +86,7 @@ card: ### SIG CLI의 kubectl 디버그 소개 -SIG CLI는 이미 오랫동안 디버그 유틸리티의 필요성에 대해 논의하고 있었다. [임시(ephemeral) 컨테이너](https://kubernetes.io/ko/docs/concepts/workloads/pods/ephemeral-containers/)가 개발되면서, `kubectl exec` 위에 구축된 도구를 통해 개발자를 지원할 수 있는 방법이 더욱 분명해졌다. `kubectl debug` [커맨드](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md) 추가(알파이지만 피드백은 언제나 환영)로 개발자는 클러스터 내에서 파드를 쉽게 디버깅할 수 있다. 우리는 이 추가 기능이 매우 유용하다고 생각한다. 이 커맨드를 사용하면 검사하려는 파드 바로 옆에서 실행되는 임시 컨테이너를 만들 수 있고, 대화식 문제 해결을 위해 콘솔에 연결할 수도 있다. +SIG CLI는 이미 오랫동안 디버그 유틸리티의 필요성에 대해 논의하고 있었다. [임시(ephemeral) 컨테이너](/ko/docs/concepts/workloads/pods/ephemeral-containers/)가 개발되면서, `kubectl exec` 위에 구축된 도구를 통해 개발자를 지원할 수 있는 방법이 더욱 분명해졌다. `kubectl debug` [커맨드](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md) 추가(알파이지만 피드백은 언제나 환영)로 개발자는 클러스터 내에서 파드를 쉽게 디버깅할 수 있다. 우리는 이 추가 기능이 매우 유용하다고 생각한다. 이 커맨드를 사용하면 검사하려는 파드 바로 옆에서 실행되는 임시 컨테이너를 만들 수 있고, 대화식 문제 해결을 위해 콘솔에 연결할 수도 있다. ### 쿠버네티스를 위한 윈도우 CSI 지원 알파 소개 diff --git a/content/ko/docs/tasks/_index.md b/content/ko/docs/tasks/_index.md index 6ce0119d9f..e6c80f32ed 100644 --- a/content/ko/docs/tasks/_index.md +++ b/content/ko/docs/tasks/_index.md @@ -11,9 +11,5 @@ content_type: concept 보여준다. 한 태스크 페이지는 일반적으로 여러 단계로 이루어진 짧은 시퀀스를 제공함으로써, 하나의 일을 수행하는 방법을 보여준다. - -## {{% heading "whatsnext" %}} - - 만약 태스크 페이지를 작성하고 싶다면, [문서 풀 리퀘스트(Pull Request) 생성하기](/ko/docs/contribute/new-content/new-content/)를 참조한다. diff --git a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md index 711130bbb4..3aa05a92b0 100644 --- a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -97,12 +97,12 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 예를 들면: -```conf -release=1.0 -tier=frontend -environment=pod -track=stable -``` + ```conf + release=1.0 + tier=frontend + environment=pod + track=stable + ``` - **네임스페이스**: 쿠버네티스는 동일한 물리 클러스터를 바탕으로 여러 가상의 클러스터를 제공한다. 이러한 가상 클러스터들을 [네임스페이스](/docs/tasks/administer-cluster/namespaces/)라고 부른다. 논리적으로 명명된 그룹으로 리소스들을 분할 할 수 있다. diff --git a/content/ko/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/content/ko/docs/tasks/administer-cluster/change-pv-reclaim-policy.md new file mode 100644 index 0000000000..dfd9923113 --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/change-pv-reclaim-policy.md @@ -0,0 +1,97 @@ +--- +title: 퍼시스턴트볼륨 반환 정책 변경하기 +content_type: task +--- + + +이 페이지는 쿠버네티스 퍼시트턴트볼륨(PersistentVolume)의 반환 정책을 +변경하는 방법을 보여준다. + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + + +## 왜 퍼시스턴트볼륨 반환 정책을 변경하는가? + +`PersistentVolumes` 은 "Retain(보존)", "Recycle(재활용)", "Delete(삭제)" 를 포함한 +다양한 반환 정책을 갖는다. 동적으로 프로비저닝 된 `PersistentVolumes` 의 경우 +기본 반환 정책은 "Delete" 이다. 이는 사용자가 해당 `PersistentVolumeClaim` 을 삭제하면, +동적으로 프로비저닝 된 볼륨이 자동적으로 삭제됨을 의미한다. +볼륨에 중요한 데이터가 포함된 경우, 이러한 자동 삭제는 부적절 할 수 있다. +이 경우에는, "Retain" 정책을 사용하는 것이 더 적합하다. +"Retain" 정책에서, 사용자가 `PersistentVolumeClaim` 을 삭제할 경우 해당하는 +`PersistentVolume` 은 삭제되지 않는다. +대신, `Released` 단계로 이동되어, 모든 데이터를 수동으로 복구할 수 있다. + +## 퍼시스턴트볼륨 반환 정책 변경하기 + +1. 사용자의 클러스터에서 퍼시스턴트볼륨을 조회한다. + + ```shell + kubectl get pv + ``` + + 결과는 아래와 같다. + + NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE + pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 manual 10s + pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 6s + pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim3 manual 3s + + 이 목록은 동적으로 프로비저닝 된 볼륨을 쉽게 식별할 수 있도록 + 각 볼륨에 바인딩 되어 있는 퍼시스턴트볼륨클레임(PersistentVolumeClaim)의 이름도 포함한다. + +1. 사용자의 퍼시스턴트볼륨 중 하나를 선택한 후에 반환 정책을 변경한다. + + ```shell + kubectl patch pv -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}' + ``` + + `` 는 사용자가 선택한 퍼시스턴트볼륨의 이름이다. + + {{< note >}} + 윈도우에서는, 공백이 포함된 모든 JSONPath 템플릿에 _겹_ 따옴표를 사용해야 한다.(bash에 대해 위에서 표시된 홑 따옴표가 아니다.) 따라서 템플릿의 모든 표현식에서 홑 따옴표를 쓰거나, 이스케이프 처리된 겹 따옴표를 써야 한다. 예를 들면 다음과 같다. + +```cmd +kubectl patch pv -p "{\"spec\":{\"persistentVolumeReclaimPolicy\":\"Retain\"}}" +``` + + {{< /note >}} + +1. 선택한 PersistentVolume이 올바른 정책을 갖는지 확인한다. + + ```shell + kubectl get pv + ``` + + 결과는 아래와 같다. + + NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE + pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 manual 40s + pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 36s + pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Retain Bound default/claim3 manual 33s + + 위 결과에서, `default/claim3` 클레임과 바인딩 되어 있는 볼륨이 `Retain` 반환 정책을 + 갖는 것을 볼 수 있다. 사용자가 `default/claim3` 클레임을 삭제할 경우, + 볼륨은 자동으로 삭제 되지 않는다. + + + +## {{% heading "whatsnext" %}} + +* [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)에 대해 더 배워 보기. +* [퍼시스턴트볼륨클레임](/ko/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)에 대해 더 배워 보기. + +### Reference + +* [퍼시스턴트볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core) +* [퍼시스턴트볼륨클레임](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core) +* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)의 `persistentVolumeReclaimPolicy` 필드에 대해 보기. + + diff --git a/content/ko/docs/tasks/administer-cluster/declare-network-policy.md b/content/ko/docs/tasks/administer-cluster/declare-network-policy.md new file mode 100644 index 0000000000..58865f9443 --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/declare-network-policy.md @@ -0,0 +1,145 @@ +--- +title: 네트워크 폴리시(Network Policy) 선언하기 +min-kubernetes-server-version: v1.8 +content_type: task +--- + +이 문서는 사용자가 쿠버네티스 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)를 사용하여 파드(Pod)가 서로 통신하는 방법을 제어하는 네트워크 폴리시를 선언하는데 도움을 준다. + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +네트워크 폴리시를 지원하는 네트워크 제공자를 구성하였는지 확인해야 한다. 다음과 같이 네트워크폴리시를 제공하는 많은 네트워크 제공자들이 있다. + +* [캘리코(Calico)](/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy/) +* [실리움(Cilium)](/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy/) +* [Kube-router](/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy/) +* [로마나(Romana)](/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy/) +* [위브넷(Weave Net)](/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy/) + +{{< note >}} +위 목록은 추천순이나 선호도순이 아닌, 제품 이름의 알파벳 순으로 정렬되어 있다. 이 예제는 이러한 제공자 중 하나를 사용하는 쿠버네티스 클러스터에 유효하다. +{{< /note >}} + + + + +## `nginx` 디플로이먼트(Deployment)를 생성하고 서비스(Service)를 통해 노출하기 + +쿠버네티스 네트워크 폴리시가 어떻게 동작하는지 확인하기 위해서, `nginx` 디플로이먼트를 생성한다. + +```console +kubectl create deployment nginx --image=nginx +``` +```none +deployment.apps/nginx created +``` + +`nginx` 라는 이름의 서비스를 통해 디플로이먼트를 노출한다. + +```console +kubectl expose deployment nginx --port=80 +``` + +```none +service/nginx exposed +``` + +위 명령어들은 nginx 파드에 대한 디플로이먼트를 생성하고, `nginx` 라는 이름의 서비스를 통해 디플로이먼트를 노출한다. `nginx` 파드와 디플로이먼트는 `default` 네임스페이스(namespace)에 존재한다. + +```console +kubectl get svc,pod +``` + +```none +NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE +service/kubernetes 10.100.0.1 443/TCP 46m +service/nginx 10.100.0.16 80/TCP 33s + +NAME READY STATUS RESTARTS AGE +pod/nginx-701339712-e0qfq 1/1 Running 0 35s +``` + +## 다른 파드에서 접근하여 서비스 테스트하기 + +사용자는 다른 파드에서 새 `nginx` 서비스에 접근할 수 있어야 한다. `default` 네임스페이스에 있는 다른 파드에서 `nginx` 서비스에 접근하기 위하여, busybox 컨테이너를 생성한다. + +```console +kubectl run busybox --rm -ti --image=busybox -- /bin/sh +``` + +사용자 쉘에서, 다음의 명령을 실행한다. + +```shell +wget --spider --timeout=1 nginx +``` + +```none +Connecting to nginx (10.100.0.16:80) +remote file exists +``` + +## `nginx` 서비스에 대해 접근 제한하기 + +`access: true` 레이블을 가지고 있는 파드만 `nginx` 서비스에 접근할 수 있도록 하기 위하여, 다음과 같은 네트워크폴리시 오브젝트를 생성한다. + +{{< codenew file="service/networking/nginx-policy.yaml" >}} + +네트워크폴리시 오브젝트의 이름은 유효한 +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)이어야 한다. + +{{< note >}} +네트워크폴리시는 정책이 적용되는 파드의 그룹을 선택하는 `podSelector` 를 포함한다. 사용자는 이 정책이 `app=nginx` 레이블을 갖는 파드를 선택하는 것을 볼 수 있다. 레이블은 `nginx` 디플로이먼트에 있는 파드에 자동으로 추가된다. 빈 `podSelector` 는 네임스페이스의 모든 파드를 선택한다. +{{< /note >}} + +## 서비스에 정책 할당하기 + +kubectl을 사용하여 위 `nginx-policy.yaml` 파일로부터 네트워크폴리시를 생성한다. + +```console +kubectl apply -f https://k8s.io/examples/service/networking/nginx-policy.yaml +``` + +```none +networkpolicy.networking.k8s.io/access-nginx created +``` + +## access 레이블이 정의되지 않은 서비스에 접근 테스트 +올바른 레이블이 없는 파드에서 `nginx` 서비스에 접근하려 할 경우, 요청 타임 아웃이 발생한다. + +```console +kubectl run busybox --rm -ti --image=busybox -- /bin/sh +``` + +사용자 쉘에서, 다음의 명령을 실행한다. + +```shell +wget --spider --timeout=1 nginx +``` + +```none +Connecting to nginx (10.100.0.16:80) +wget: download timed out +``` + +## 접근 레이블을 정의하고 다시 테스트 + +사용자는 요청이 허용되도록 하기 위하여 올바른 레이블을 갖는 파드를 생성한다. + +```console +kubectl run busybox --rm -ti --labels="access=true" --image=busybox -- /bin/sh +``` + +사용자 쉘에서, 다음의 명령을 실행한다. + +```shell +wget --spider --timeout=1 nginx +``` + +```none +Connecting to nginx (10.100.0.16:80) +remote file exists +``` diff --git a/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md b/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md new file mode 100644 index 0000000000..5af4ea94b0 --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md @@ -0,0 +1,261 @@ +--- +title: DNS 서비스 사용자 정의하기 +content_type: task +min-kubernetes-server-version: v1.12 +--- + + +이 페이지는 클러스터 안에서 사용자의 +DNS {{< glossary_tooltip text="파드(Pod)" term_id="pod" >}} 를 설정하고 +DNS 변환(DNS resolution) 절차를 사용자 정의하는 방법을 설명한다. + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} + +클러스터는 CoreDNS 애드온을 구동하고 있어야 한다. +[CoreDNS로 이관하기](/ko/docs/tasks/administer-cluster/coredns/#coredns로-이관하기) +는 `kubeadm` 을 이용하여 `kube-dns` 로부터 이관하는 방법을 설명한다. + +{{% version-check %}} + + + +## 소개 + +DNS는 _애드온 관리자_ 인 [클러스터 애드온](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md)을 +사용하여 자동으로 시작되는 쿠버네티스 +내장 서비스이다. + +쿠버네티스 v1.12 부터, CoreDNS는 kube-dns를 대체하여 권장되는 DNS 서버이다. 만약 사용자의 클러스터가 원래 kube-dns를 사용하였을 경우, +CoreDNS 대신 `kube-dns` 를 계속 사용할 수도 있다. + +{{< note >}} +CoreDNS와 kube-dns 서비스 모두 `metadata.name` 필드에 `kube-dns` 로 이름이 지정된다. +이를 통해, 기존의 `kube-dns` 서비스 이름을 사용하여 클러스터 내부의 주소를 확인하는 워크로드에 대한 상호 운용성이 증가된다. `kube-dns` 로 서비스 이름을 사용하면, 해당 DNS 공급자가 어떤 공통 이름으로 실행되고 있는지에 대한 구현 세부 정보를 추상화한다. +{{< /note >}} + +CoreDNS를 디플로이먼트(Deployment)로 실행하고 있을 경우, 일반적으로 고정 IP 주소를 갖는 쿠버네티스 서비스로 노출된다. +Kubelet 은 `--cluster-dns=` 플래그를 사용하여 DNS 확인자 정보를 각 컨테이너에 전달한다. + +DNS 이름에도 도메인이 필요하다. 사용자는 kubelet 에 있는 `--cluster-domain=` 플래그를 +통하여 로컬 도메인을 설정할 수 있다. + +DNS 서버는 정방향 조회(A 및 AAAA 레코드), 포트 조회(SRV 레코드), 역방향 IP 주소 조회(PTR 레코드) 등을 지원한다. +더 자세한 내용은 [서비스 및 파드용 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)를 참고한다. + +만약 파드의 `dnsPolicy` 가 `default` 로 지정되어 있는 경우, +파드는 자신이 실행되는 노드의 이름 변환(name resolution) 구성을 상속한다. +파드의 DNS 변환도 노드와 동일하게 작동해야 한다. +그 외에는 [알려진 이슈](/docs/tasks/debug-application-cluster/dns-debugging-resolution/#known-issues)를 참고한다. + +만약 위와 같은 방식을 원하지 않거나, 파드를 위해 다른 DNS 설정이 필요한 경우, +사용자는 kubelet 의 `--resolv-conf` 플래그를 사용할 수 있다. +파드가 DNS를 상속받지 못하도록 하기 위해 이 플래그를 ""로 설정한다. +DNS 상속을 위해 `/etc/resolv.conf` 이외의 파일을 지정할 경우 유효한 파일 경로를 설정한다. + +## CoreDNS + +CoreDNS는 [dns 명세](https://github.com/kubernetes/dns/blob/master/docs/specification.md)를 준수하며 클러스터 DNS 역할을 할 수 있는, 범용적인 권한을 갖는 DNS 서버이다. + +### CoreDNS 컨피그맵(ConfigMap) 옵션 + +CoreDNS는 모듈형이자 플러그인이 가능한 DNS 서버이며, 각 플러그인들은 CoreDNS에 새로운 기능을 부가한다. +이는 CoreDNS 구성 파일인 [Corefile](https://coredns.io/2017/07/23/corefile-explained/)을 관리하여 구성할 수 있다. +클러스터 관리자는 CoreDNS Corefile에 대한 {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}을 수정하여 +해당 클러스터에 대한 DNS 서비스 검색 동작을 +변경할 수 있다. + +쿠버네티스에서 CoreDNS는 아래의 기본 Corefile 구성으로 설치된다. + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: coredns + namespace: kube-system +data: + Corefile: | + .:53 { + errors + health { + lameduck 5s + } + ready + kubernetes cluster.local in-addr.arpa ip6.arpa { + pods insecure + fallthrough in-addr.arpa ip6.arpa + ttl 30 + } + prometheus :9153 + forward . /etc/resolv.conf + cache 30 + loop + reload + loadbalance + } +``` + +Corefile의 구성은 CoreDNS의 아래 [플러그인](https://coredns.io/plugins)을 포함한다. + +* [errors](https://coredns.io/plugins/errors/): 오류가 표준 출력(stdout)에 기록된다. +* [health](https://coredns.io/plugins/health/): CoreDNS의 상태(healthy)가 `http://localhost:8080/health` 에 기록된다. 이 확장 구문에서 `lameduck` 은 프로세스를 비정상 상태(unhealthy)로 만들고, 프로세스가 종료되기 전에 5초 동안 기다린다. +* [ready](https://coredns.io/plugins/ready/): 8181 포트의 HTTP 엔드포인트가, 모든 플러그인이 준비되었다는 신호를 보내면 200 OK 를 반환한다. +* [kubernetes](https://coredns.io/plugins/kubernetes/): CoreDNS가 쿠버네티스의 서비스 및 파드의 IP를 기반으로 DNS 쿼리에 대해 응답한다. 해당 플러그인에 대한 [세부 사항](https://coredns.io/plugins/kubernetes/)은 CoreDNS 웹사이트에서 확인할 수 있다. `ttl` 을 사용하면 응답에 대한 사용자 정의 TTL 을 지정할 수 있으며, 기본값은 5초이다. 허용되는 최소 TTL은 0초이며, 최대값은 3600초이다. 레코드가 캐싱되지 않도록 할 경우, TTL을 0으로 설정한다. + `pods insecure` 옵션은 _kube-dns_ 와의 하위 호환성을 위해 제공된다. `pods verified` 옵션을 사용하여, 일치하는 IP의 동일 네임스페이스(Namespace)에 파드가 존재하는 경우에만 A 레코드를 반환하게 할 수 있다. `pods disabled` 옵션은 파드 레코드를 사용하지 않을 경우 사용된다. +* [prometheus](https://coredns.io/plugins/metrics/): CoreDNS의 메트릭은 [프로메테우스](https://prometheus.io/) 형식(OpenMetrics 라고도 알려진)의 `http://localhost:9153/metrics` 에서 사용 가능하다. +* [forward](https://coredns.io/plugins/forward/): 쿠버네티스 클러스터 도메인에 없는 쿼리들은 모두 사전에 정의된 리졸버(/etc/resolv.conf)로 전달된다. +* [cache](https://coredns.io/plugins/cache/): 프론트 엔드 캐시를 활성화한다. +* [loop](https://coredns.io/plugins/loop/): 간단한 전달 루프(loop)를 감지하고, 루프가 발견되면 CoreDNS 프로세스를 중단(halt)한다. +* [reload](https://coredns.io/plugins/reload): 변경된 Corefile을 자동으로 다시 로드하도록 한다. 컨피그맵 설정을 변경한 후에 변경 사항이 적용되기 위하여 약 2분정도 소요된다. +* [loadbalance](https://coredns.io/plugins/loadbalance): 응답에 대하여 A, AAAA, MX 레코드의 순서를 무작위로 선정하는 라운드-로빈 DNS 로드밸런서이다. + +사용자는 컨피그맵을 변경하여 기본 CoreDNS 동작을 변경할 수 있다. + +### CoreDNS를 사용하는 스텁 도메인(Stub-domain)과 업스트림 네임서버(nameserver)의 설정 + +CoreDNS는 [포워드 플러그인](https://coredns.io/plugins/forward/)을 사용하여 스텁 도메인 및 업스트림 네임서버를 구성할 수 있다. + +#### 예시 +만약 클러스터 운영자가 10.150.0.1 에 위치한 [Consul](https://www.consul.io/) 도메인 서버를 가지고 있고, 모든 Consul 이름의 접미사가 .consul.local 인 경우, CoreDNS에서 이를 구성하기 위해 클러스터 관리자는 CoreDNS 컨피그맵에서 다음 구문을 생성한다. + +``` +consul.local:53 { + errors + cache 30 + forward . 10.150.0.1 + } +``` + +모든 비 클러스터의 DNS 조회가 172.16.0.1 의 특정 네임서버를 통과하도록 할 경우, `/etc/resolv.conf` 대신 `forward` 를 네임서버로 지정한다. + +``` +forward . 172.16.0.1 +``` + +기본 `Corefile` 구성에 따른 최종 컨피그맵은 다음과 같다. + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: coredns + namespace: kube-system +data: + Corefile: | + .:53 { + errors + health + kubernetes cluster.local in-addr.arpa ip6.arpa { + pods insecure + fallthrough in-addr.arpa ip6.arpa + } + prometheus :9153 + forward . 172.16.0.1 + cache 30 + loop + reload + loadbalance + } + consul.local:53 { + errors + cache 30 + forward . 10.150.0.1 + } +``` + +`Kubeadm` 툴은 kube-dns 컨피그맵에서 동일한 설정의 CoreDNS 컨피그맵으로의 +자동 변환을 지원한다. + +{{< note >}} +kube-dns는 스텁 도메인 및 네임서버(예: ns.foo.com)에 대한 FQDN을 허용하지만 CoreDNS에서는 이 기능을 지원하지 않는다. +변환 과정에서, 모든 FQDN 네임서버는 CoreDNS 설정에서 생략된다. +{{< /note >}} + +## kube-dns에 대응되는 CoreDNS 설정 + +CoreDNS는 kube-dns 이상의 기능을 지원한다. +`StubDomains` 과 `upstreamNameservers` 를 지원하도록 생성된 kube-dns의 컨피그맵은 CoreDNS의 `forward` 플러그인으로 변환된다. +마찬가지로, kube-dns의 `Federations` 플러그인은 CoreDNS의 `federation` 플러그인으로 변환된다. + +### 예시 + +kube-dns에 대한 이 컨피그맵 예제는 federations, stubDomains 및 upstreamNameservers를 지정한다. + +```yaml +apiVersion: v1 +data: + federations: | + {"foo" : "foo.feddomain.com"} + stubDomains: | + {"abc.com" : ["1.2.3.4"], "my.cluster.local" : ["2.3.4.5"]} + upstreamNameservers: | + ["8.8.8.8", "8.8.4.4"] +kind: ConfigMap +``` + +CoreDNS에서는 동등한 설정으로 Corefile을 생성한다. + +* federations 에 대응하는 설정: +``` +federation cluster.local { + foo foo.feddomain.com +} +``` + +* stubDomains 에 대응하는 설정: +```yaml +abc.com:53 { + errors + cache 30 + forward . 1.2.3.4 +} +my.cluster.local:53 { + errors + cache 30 + forward . 2.3.4.5 +} +``` + +기본 플러그인으로 구성된 완전한 Corefile. + +``` +.:53 { + errors + health + kubernetes cluster.local in-addr.arpa ip6.arpa { + pods insecure + fallthrough in-addr.arpa ip6.arpa + } + federation cluster.local { + foo foo.feddomain.com + } + prometheus :9153 + forward . 8.8.8.8 8.8.4.4 + cache 30 +} +abc.com:53 { + errors + cache 30 + forward . 1.2.3.4 +} +my.cluster.local:53 { + errors + cache 30 + forward . 2.3.4.5 +} +``` + +## CoreDNS로의 이관 + +kube-dns에서 CoreDNS로 이관하기 위하여, +kube-dns를 CoreDNS로 교체하여 적용하는 방법에 대한 상세 정보는 +[블로그 기사](https://coredns.io/2018/05/21/migration-from-kube-dns-to-coredns/)를 참고한다. + +또한 공식적인 CoreDNS [배포 스크립트](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh)를 +사용하여 이관할 수도 있다. + + +## {{% heading "whatsnext" %}} + +- [DNS 변환 디버깅하기](/docs/tasks/debug-application-cluster/dns-debugging-resolution/) 읽기 diff --git a/content/ko/docs/tasks/debug-application-cluster/debug-init-containers.md b/content/ko/docs/tasks/debug-application-cluster/debug-init-containers.md new file mode 100644 index 0000000000..dc774b9ce3 --- /dev/null +++ b/content/ko/docs/tasks/debug-application-cluster/debug-init-containers.md @@ -0,0 +1,125 @@ +--- +title: 초기화 컨테이너(Init Containers) 디버그하기 +content_type: task +--- + + + +이 페이지는 초기화 컨테이너의 실행과 관련된 문제를 +조사하는 방법에 대해 보여준다. 아래 예제의 커맨드 라인은 파드(Pod)를 `` 으로, +초기화 컨테이너를 `` 과 +`` 로 표시한다. + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +* 사용자는 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)의 + 기본 사항에 익숙해야 한다. +* 사용자는 [초기화 컨테이너를 구성](/ko/docs/tasks/configure-pod-container/configure-pod-initialization/#초기화-컨테이너를-갖는-파드-생성)해야 한다. + + + + + +## 초기화 컨테이너의 상태 체크하기 + +사용자 파드의 상태를 표시한다. + +```shell +kubectl get pod +``` + +예를 들어, `Init:1/2` 상태는 두 개의 초기화 컨테이너 중 +하나가 성공적으로 완료되었음을 나타낸다. + +``` +NAME READY STATUS RESTARTS AGE + 0/1 Init:1/2 0 7s +``` + +상태값과 그 의미에 대한 추가 예제는 +[파드 상태 이해하기](#파드의-상태-이해하기)를 참조한다. + +## 초기화 컨테이너에 대한 상세 정보 조회하기 + +초기화 컨테이너의 실행에 대한 상세 정보를 확인한다. + +```shell +kubectl describe pod +``` + +예를 들어, 2개의 초기화 컨테이너가 있는 파드는 다음과 같이 표시될 수 있다. + +``` +Init Containers: + : + Container ID: ... + ... + State: Terminated + Reason: Completed + Exit Code: 0 + Started: ... + Finished: ... + Ready: True + Restart Count: 0 + ... + : + Container ID: ... + ... + State: Waiting + Reason: CrashLoopBackOff + Last State: Terminated + Reason: Error + Exit Code: 1 + Started: ... + Finished: ... + Ready: False + Restart Count: 3 + ... +``` + +파드 스펙의 `status.initContainerStatuses` 필드를 읽어서 +프로그래밍 방식으로 초기화 컨테이너의 상태를 조회할 수도 있다. + + +```shell +kubectl get pod nginx --template '{{.status.initContainerStatuses}}' +``` + + +이 명령은 원시 JSON 방식으로 위와 동일한 정보를 반환한다. + +## 초기화 컨테이너의 로그 조회하기 + +초기화 컨테이너의 로그를 확인하기 위해 +파드의 이름과 초기화 컨테이너의 이름을 같이 전달한다. + +```shell +kubectl logs -c +``` + +셸 스크립트를 실행하는 초기화 컨테이너는, 초기화 컨테이너가 +실행될 때 명령어를 출력한다. 예를 들어, 스크립트의 시작 부분에 +`set -x` 를 추가하고 실행하여 Bash에서 명령어를 출력할 수 있도록 수행할 수 있다. + + + + + +## 파드의 상태 이해하기 + +`Init:` 으로 시작하는 파드 상태는 초기화 컨테이너의 +실행 상태를 요약한다. 아래 표는 초기화 컨테이너를 디버깅하는 +동안 사용자가 확인할 수 있는 몇 가지 상태값의 예이다. + +상태 | 의미 +------ | ------- +`Init:N/M` | 파드가 `M` 개의 초기화 컨테이너를 갖고 있으며, 현재까지 `N` 개가 완료. +`Init:Error` | 초기화 컨테이너 실행 실패. +`Init:CrashLoopBackOff` | 초기화 컨테이너가 반복적으로 실행 실패. +`Pending` | 파드가 아직 초기화 컨테이너를 실행하지 않음. +`PodInitializing` or `Running` | 파드가 이미 초기화 컨테이너 실행을 완료. diff --git a/content/ko/docs/tutorials/_index.md b/content/ko/docs/tutorials/_index.md index 493d31e95f..a0dfb80ca1 100644 --- a/content/ko/docs/tutorials/_index.md +++ b/content/ko/docs/tutorials/_index.md @@ -1,6 +1,7 @@ --- title: 튜토리얼 main_menu: true +no_list: true weight: 60 content_type: concept --- @@ -14,8 +15,6 @@ content_type: concept 각 튜토리얼을 따라하기 전에, 나중에 참조할 수 있도록 [표준 용어집](/ko/docs/reference/glossary/) 페이지를 북마크하기를 권한다. - - ## 기초 @@ -64,13 +63,8 @@ content_type: concept * [소스 IP 주소 이용하기](/ko/docs/tutorials/services/source-ip/) - - ## {{% heading "whatsnext" %}} - 튜토리얼을 작성하고 싶다면, 튜토리얼 페이지 유형에 대한 정보가 있는 [콘텐츠 페이지 유형](/docs/contribute/style/page-content-types/) 페이지를 참조한다. - - diff --git a/content/ko/docs/tutorials/services/source-ip.md b/content/ko/docs/tutorials/services/source-ip.md index 5c4d94f624..ae9e5abf03 100644 --- a/content/ko/docs/tutorials/services/source-ip.md +++ b/content/ko/docs/tutorials/services/source-ip.md @@ -226,7 +226,7 @@ client_address=10.240.0.3 다른 노드로 트래픽 전달하지 않는다. 이 방법은 원본 소스 IP 주소를 보존한다. 만약 로컬 엔드 포인트가 없다면, 그 노드로 보내진 패킷은 버려지므로 -패킷 처리 규칙에서 정확한 소스 IP 임을 신뢰할 수 있으므로, +패킷 처리 규칙에서 정확한 소스 IP 임을 신뢰할 수 있으므로, 패킷을 엔드포인트까지 전달할 수 있다. 다음과 같이 `service.spec.externalTrafficPolicy` 필드를 설정하자. @@ -249,7 +249,7 @@ for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i cli client_address=104.132.1.79 ``` -엔드포인트 파드가 실행 중인 노드에서 *올바른* 클라이언트 IP 주소인 +엔드포인트 파드가 실행 중인 노드에서 *올바른* 클라이언트 IP 주소인 딱 한 종류의 응답만 수신한다. 어떻게 이렇게 되었는가: @@ -319,7 +319,7 @@ client_address=10.240.0.5 그러나 구글 클라우드 엔진/GCE 에서 실행 중이라면 동일한 `service.spec.externalTrafficPolicy` 필드를 `Local`로 설정하면 서비스 엔드포인트가 *없는* 노드는 고의로 헬스 체크에 실패하여 -강제로 로드밸런싱 트래픽을 받을 수 있는 노드 목록에서 +강제로 로드밸런싱 트래픽을 받을 수 있는 노드 목록에서 자신을 스스로 제거한다. 시각적으로: @@ -448,5 +448,3 @@ kubectl delete deployment source-ip-app * [서비스를 통한 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에 더 자세히 본다. * 어떻게 [외부 로드밸런서 생성](/docs/tasks/access-application-cluster/create-external-load-balancer/)하는지 본다. - - diff --git a/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md index ec5ea3b53d..719c998366 100644 --- a/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md +++ b/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md @@ -84,7 +84,7 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml {{< note >}} - `type=LoadBalancer` 서비스는 이 예시에서 다루지 않은 외부 클라우드 공급자가 지원하며, 자세한 내용은 [이 페이지](/ko/docs/concepts/services-networking/service/#loadbalancer를 참조한다. + `type=LoadBalancer` 서비스는 이 예시에서 다루지 않은 외부 클라우드 공급자가 지원하며, 자세한 내용은 [이 페이지](/ko/docs/concepts/services-networking/service/#loadbalancer)를 참조한다. {{< /note >}} diff --git a/content/ko/examples/service/networking/nginx-policy.yaml b/content/ko/examples/service/networking/nginx-policy.yaml new file mode 100644 index 0000000000..89ee988692 --- /dev/null +++ b/content/ko/examples/service/networking/nginx-policy.yaml @@ -0,0 +1,13 @@ +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: access-nginx +spec: + podSelector: + matchLabels: + app: nginx + ingress: + - from: + - podSelector: + matchLabels: + access: "true" From b8892750ef913378ad02034fd2137c3c0cc7b540 Mon Sep 17 00:00:00 2001 From: Evan Adi Date: Wed, 22 Jul 2020 20:30:51 +0700 Subject: [PATCH 50/86] Translate high-availability into Bahasa Indonesia nits: - typos - leftover translation - use bertumpuk for stacked - update reference to id docs - fix the title of directory's index - update title to match index - remove - in control plane - unitalicize cloud - remove non inclusive word - correct anchor links - fix typos - leftover translation - remove alias anchor - adopt bootstrapping - add index - translate bootstrap to menyiapkan - add index for /setup/production-environment/tools/ fix: Moved page to correct path --- .../production-environment/tools/_index.md | 4 + .../tools/kubeadm/_index.md | 4 + .../tools/kubeadm/high-availability.md | 364 ++++++++++++++++++ content/id/docs/tasks/tools/kubeadm/_index.md | 4 + 4 files changed, 376 insertions(+) create mode 100644 content/id/docs/setup/production-environment/tools/_index.md create mode 100644 content/id/docs/setup/production-environment/tools/kubeadm/_index.md create mode 100644 content/id/docs/setup/production-environment/tools/kubeadm/high-availability.md create mode 100644 content/id/docs/tasks/tools/kubeadm/_index.md diff --git a/content/id/docs/setup/production-environment/tools/_index.md b/content/id/docs/setup/production-environment/tools/_index.md new file mode 100644 index 0000000000..fc98544230 --- /dev/null +++ b/content/id/docs/setup/production-environment/tools/_index.md @@ -0,0 +1,4 @@ +--- +title: Menginstal Kubernetes dengan perkakas penyebaran +weight: 30 +--- diff --git a/content/id/docs/setup/production-environment/tools/kubeadm/_index.md b/content/id/docs/setup/production-environment/tools/kubeadm/_index.md new file mode 100644 index 0000000000..f88a749c9b --- /dev/null +++ b/content/id/docs/setup/production-environment/tools/kubeadm/_index.md @@ -0,0 +1,4 @@ +--- +title: "Menyiapkan klaster dengan kubeadm" +weight: 10 +--- diff --git a/content/id/docs/setup/production-environment/tools/kubeadm/high-availability.md b/content/id/docs/setup/production-environment/tools/kubeadm/high-availability.md new file mode 100644 index 0000000000..afe6d1e6b8 --- /dev/null +++ b/content/id/docs/setup/production-environment/tools/kubeadm/high-availability.md @@ -0,0 +1,364 @@ +--- +title: Membangun Klaster dengan Ketersediaan Tinggi menggunakan kubeadm +content_type: task +weight: 60 +--- + + + +Laman ini menjelaskan dua pendekatan yang berbeda untuk membuat klaster Kubernetes dengan ketersediaan tinggi menggunakan kubeadm: + +- Dengan Node _control plane_ yang bertumpuk (_stacked_). Pendekatan ini membutuhkan sumber daya infrastruktur yang lebih sedikit. Anggota-anggota etcd dan Node _control plane_ diletakkan pada tempat yang sama (_co-located_). +- Dengan klaster etcd eksternal. Pendekatan ini membutuhkan lebih banyak sumber daya infrastruktur. Node _control plane_ dan anggota etcd berada pada tempat yang berbeda. + +Sebelum memulai, kamu harus memikirkan dengan matang pendekatan mana yang paling sesuai untuk kebutuhan aplikasi dan _environment_-mu. [Topik perbandingan berikut](/id/docs/setup/production-environment/tools/kubeadm/ha-topology/) menguraikan kelebihan dan kekurangan dari masing-masing pendekatan. + +Jika kamu menghadapi masalah dalam pembuatan klaster dengan ketersediaan tinggi, silakan berikan umpan balik +pada [pelacak isu](https://github.com/kubernetes/kubeadm/issues/new) kubeadm. + +Lihat juga [dokumentasi pembaruan](/id/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15). + +{{< caution >}} +Laman ini tidak menunjukkan cara untuk menjalankan klastermu pada penyedia layanan cloud. Pada _environment_ cloud, kedua pendekatan yang didokumentasikan di sini tidak akan bekerja untuk objek Service dengan tipe LoadBalancer maupun PersistentVolume dinamis. +{{< /caution >}} + + + +## {{% heading "prerequisites" %}} + + +Untuk kedua metode kamu membutuhkan infrastruktur seperti berikut: + +- Tiga mesin yang memenuhi [kebutuhan minimum kubeadm](/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#sebelum-mulai) untuk + Node _control plane_ +- Tiga mesin yang memenuhi [kebutuhan minimum kubeadm](/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#sebelum-mulai) untuk Node _worker_ +- Konektivitas internet pada seluruh mesin di dalam klaster (baik jaringan publik maupun jaringan pribadi) +- Hak akses sudo pada seluruh mesin +- Akses SSH dari satu perangkat ke seluruh Node pada sistem +- Perkakas `kubeadm` dan `kubelet` diinstal pada seluruh mesin. Perkakas `kubectl` bersifat opsional. + +Untuk klaster etcd eksternal saja, kamu juga membutuhkan: + +- Tiga mesin tambahan untuk anggota-anggota etcd + + + + + +## Langkah pertama untuk kedua metode + +### Membuat _load balancer_ untuk kube-apiserver + +{{< note >}} +Akan ada banyak konfigurasi untuk _load balancer_. Contoh berikut ini hanyalah salah satu +opsi. Kebutuhan klastermu mungkin membutuhkan konfigurasi berbeda. +{{< /note >}} + +1. Buat sebuah _load balancer_ kube-apiserver dengan sebuah nama yang yang akan mengubah ke dalam bentuk DNS. + + - Pada _environment_ cloud kamu harus meletakkan Node _control plane_ di belakang _load balancer_ yang meneruskan TCP. _Load balancer_ ini mendistribusikan trafik ke seluruh Node _control plane_ pada daftar tujuan. _Health check_ untuk + apiserver adalah pengujian TCP pada porta yang didengarkan oleh kube-apiserver + (nilai semula `:6443`). + + - Tidak direkomendasikan untuk menggunakan alamat IP secara langsung pada _environment_ cloud. + + - _Load balancer_ harus dapat berkomunikasi dengan seluruh Node _control plane_ + pada porta yang digunakan apiserver. _Load balancer_ tersebut juga harus mengizinkan trafik masuk pada porta yang didengarkannya. + + - Pastikan alamat _load balancer_ sesuai + dengan alamat `ControlPlaneEndpoint` pada kubeadm. + + - Baca panduan [Opsi untuk _Software Load Balancing_](https://github.com/kubernetes/kubeadm/blob/master/id/docs/ha-considerations.md#options-for-software-load-balancing) + untuk detail lebih lanjut. + +2. Tambahkan Node _control plane_ pertama pada _load balancer_ dan lakukan pengujian koneksi: + + ```sh + nc -v LOAD_BALANCER_IP PORT + ``` + + - Kegalatan koneksi yang ditolak memang diantisipasi karena apiserver belum + berjalan. Namun jika mendapat _timeout_, berarti _load balancer_ tidak dapat berkomunikasi + dengan Node _control plane_. Jika terjadi _timeout_, lakukan pengaturan ulang pada _load balancer_ agar dapat berkomunikasi dengan Node _control plane_. + +3. Tambahkan Node _control plane_ lainnya pada grup tujuan _load balancer_. + +## Node _control plane_ dan etcd bertumpuk (_stacked_) + +### Langkah-langkah untuk Node _control plane_ pertama + +1. Inisialisasi _control plane_: + + ```sh + sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs + ``` + + - Kamu bisa menggunakan opsi `--kubernetes-version` untuk mengatur versi Kubernetes yang akan digunakan. + Direkomendasikan untuk menggunakan versi kubeadm, kubelet, kubectl, dan Kubernetes yang sama. + + - Opsi `--control-plane-endpoint` harus diatur menuju alamat atau DNS dan porta dari _load balancer_. + + - Opsi `--upload-certs` digunakan untuk mengunggah sertifikat-sertifikat yang harus dibagikan ke seluruh + Node _control plane_ pada klaster. Jika sebaliknya, kamu memilih untuk menyalin sertifikat ke + seluruh Node _control plane_ sendiri atau menggunakan perkakas automasi, silakan hapus opsi ini dan merujuk ke bagian [Distribusi sertifikat manual](#distribusi-sertifikat-manual) di bawah. + + {{< note >}} + Opsi `--config` dan `--certificate-key` pada `kubeadm init` tidak dapat digunakan secara bersamaan, maka dari itu jika kamu ingin menggunakan + [konfigurasi kubeadm](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2) + kamu harus menambahkan _field_ `certificateKey` pada lokasi pengaturan yang sesuai + (berada di bawah `InitConfiguration` dan `JoinConfiguration: controlPlane`). + {{< /note >}} + + {{< note >}} + Beberapa _plugin_ jaringan CNI membutuhkan pengaturan tambahan, seperti menentukan CIDR IP untuk Pod, meski beberapa lainnya tidak. + Lihat [dokumentasi jaringan CNI](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#jaringan-pod). + Untuk menambahkan CIDR Pod, tambahkan opsi `--pod-network-cidr`, atau jika kamu menggunakan berkas konfigurasi kubeadm + pasang _field_ `podSubnet` di bawah objek `networking` dari `ClusterConfiguration`. + {{< /note >}} + + - Keluaran yang dihasilkan terlihat seperti berikut ini: + + ```sh + ... + You can now join any number of control-plane node by running the following command on each as a root: + kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07 + + Please note that the certificate-key gives access to cluster sensitive data, keep it secret! + As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward. + + Then you can join any number of worker nodes by running the following on each as root: + kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 + ``` + + - Salin keluaran ini pada sebuah berkas teks. Kamu akan membutuhkannya nanti untuk menggabungkan Node _control plane_ dan _worker_ ke klaster. + - Ketika opsi `--upload-certs` digunakan dengan `kubeadm init`, sertifikat dari _control plane_ utama + akan dienkripsi dan diunggah ke Secret `kubeadm-certs`. + - Untuk mengunggah ulang sertifikat dan membuat kunci dekripsi baru, gunakan perintah berikut pada Node _control plane_ + yang sudah tergabung pada klaster: + + ```sh + sudo kubeadm init phase upload-certs --upload-certs + ``` + + - Kamu juga dapat menentukan `--certificate-key` _custom_ pada saat `init` yang nanti dapat digunakan pada saat `join`. + Untuk membuat kunci tersebut kamu dapat menggunakan perintah berikut: + + ```sh + kubeadm alpha certs certificate-key + ``` + + {{< note >}} + Secret `kubeadm-certs` dan kunci dekripsi akan kadaluarsa setelah dua jam. + {{< /note >}} + + {{< caution >}} + Seperti yang tertera pada keluaran perintah, kunci sertifikat memberikan akses ke data klaster yang bersifat sensitif, jaga kerahasiaannya! + {{< /caution >}} + +2. Pasang _plugin_ CNI pilihanmu: + [Ikuti petunjuk berikut](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#jaringan-pod) + untuk menginstal penyedia CNI. Pastikan konfigurasinya sesuai dengan CIDR Pod yang ditentukan pada berkas konfigurasi kubeadm jika diterapkan. + + Pada contoh berikut kami menggunakan Weave Net: + + ```sh + kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" + ``` + +3. Tulis perintah berikut dan saksikan Pod komponen-komponen _control plane_ mulai dinyalakan: + + ```sh + kubectl get pod -n kube-system -w + ``` + +### Langkah-langkah selanjutnya untuk Node _control plane_ + +{{< note >}} +Sejak kubeadm versi 1.15 kamu dapat menggabungkan beberapa Node _control plane_ secara bersamaan. +Pada versi sebelumnya, kamu harus menggabungkan Node _control plane_ baru secara berurutan, setelah +Node pertama selesai diinisialisasi. +{{< /note >}} + +Untuk setiap Node _control plane_ kamu harus: + +1. Mengeksekusi perintah untuk bergabung yang sebelumnya diberikan pada keluaran `kubeadm init` pada Node pertama. + Perintah tersebut terlihat seperti ini: + + ```sh + sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07 + ``` + + - Opsi `--control-plane` menunjukkan `kubeadm join` untuk membuat _control plane_ baru. + - Opsi `--certificate-key ...` akan membuat sertifikat _control plane_ diunduh + dari Secret `kubeadm-certs` pada klaster dan didekripsi menggunakan kunci yang diberikan. + +## Node etcd eksternal + +Membangun sebuah klaster dengan Node etcd eksternal memiliki prosedur yang mirip dengan etcd bertumpuk +dengan pengecualian yaitu kamu harus setup etcd terlebih dulu, dan kamu harus memberikan informasi etcd +pada berkas konfigurasi kubeadm. + +### Memasang klaster etcd + +1. Ikuti [petunjuk berikut](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) untuk membangun klaster etcd. + +2. Lakukan pengaturan SSH seperti yang dijelaskan [di sini](#distribusi-sertifikat-manual). + +3. Salin berkas-berkas berikut dari Node etcd manapun pada klaster ke Node _control plane_ pertama: + + ```sh + export CONTROL_PLANE="ubuntu@10.0.0.7" + scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}": + scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}": + scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}": + ``` + + - Ganti nilai `CONTROL_PLANE` dengan `user@host` dari mesin _control plane_ pertama. + +### Mengatur Node _control plane_ pertama + +1. Buat sebuah berkas bernama `kubeadm-config.yaml` dengan konten sebagai berikut: + + apiVersion: kubeadm.k8s.io/v1beta2 + kind: ClusterConfiguration + kubernetesVersion: stable + controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" + etcd: + external: + endpoints: + - https://ETCD_0_IP:2379 + - https://ETCD_1_IP:2379 + - https://ETCD_2_IP:2379 + caFile: /etc/kubernetes/pki/etcd/ca.crt + certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt + keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key + + {{< note >}} + Perbedaan antara etcd bertumpuk dan etcd eksternal yaitu etcd eksternal membutuhkan + sebuah berkas konfigurasi dengan _endpoint_ etcd di bawah objek `external`untuk `etcd`. + Pada kasus ini topologi etcd bertumpuk dikelola secara otomatis. + {{< /note >}} + + - Ganti variabel-variabel berikut pada templat konfigurasi dengan nilai yang sesuai untuk klastermu: + + - `LOAD_BALANCER_DNS` + - `LOAD_BALANCER_PORT` + - `ETCD_0_IP` + - `ETCD_1_IP` + - `ETCD_2_IP` + +Langkah-langkah berikut sama dengan pengaturan pada etcd bertumpuk: + +1. Jalankan `sudo kubeadm init --config kubeadm-config.yaml --upload-certs` pada Node ini. + +2. Tulis perintah untuk bergabung yang didapat dari keluaran ke dalam sebuah berkas teks untuk digunakan nanti. + +3. Pasang _plugin_ CNI pilihanmu. Contoh berikut ini untuk Weave Net: + + ```sh + kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" + ``` + +### Langkah selanjutnya untuk Node _control plane_ lainnya + +Langkah-langkah selanjutnya sama untuk pengaturan etcd bertumpuk: + +- Pastikan Node _control plane_ pertama sudah diinisialisasi dengan sempurna. +- Gabungkan setiap Node _control plane_ dengan perintah untuk bergabung yang kamu simpan dalam berkas teks. Direkomendasikan untuk +menggabungkan Node _control plane_ satu persatu. +- Jangan lupakan bahwa kunci dekripsi dari `--certificate-key` akan kadaluarsa setelah dua jam, pada pengaturan semula. + +## Tugas-tugas umum setelah menyiapkan _control plane_ + +### Menginstal _worker_ + +Node _worker_ bisa digabungkan ke klaster menggunakan perintah yang kamu simpan sebelumnya +dari keluaran perintah `kubeadm init`: + +```sh +sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 +``` + +## Distribusi sertifikat manual + +Jika kamu memilih untuk tidak menggunakan `kubeadm init` dengan opsi `--upload-certs` berarti kamu harus +menyalin sertifikat dari Node _control plane_ utama secara manual ke +Node _control plane_ yang akan bergabung. + +Ada beberapa cara untuk melakukan hal ini. Pada contoh berikut ini kami menggunakan `ssh` dan `scp`: + +SSH dibutuhkan jika kamu ingin mengendalikan seluruh Node dari satu mesin. + +1. Nyalakan ssh-agent pada perangkat utamamu yang memiliki akses ke seluruh Node pada + sistem: + + ``` + eval $(ssh-agent) + ``` + +2. Tambahkan identitas SSH milikmu ke dalam sesi: + + ``` + ssh-add ~/.ssh/path_to_private_key + ``` + +3. Lakukan SSH secara bergantian ke setiap Node untuk memastikan koneksi bekerja dengan baik. + + - Ketika kamu melakukan SSH ke Node, pastikan untuk menambahkan opsi `-A`: + + ``` + ssh -A 10.0.0.7 + ``` + + - Jika kamu menggunakan sudo pada Node, pastikan kamu menyimpan _environment_ yang ada sehingga penerusan SSH + dapat bekerja dengan baik: + + ``` + sudo -E -s + ``` + +4. Setelah mengatur SSH pada seluruh Node kamu harus menjalankan skrip berikut pada Node _control plane_ pertama setelah + menjalankan `kubeadm init`. Skrip ini akan menyalin sertifikat dari Node _control plane_ pertama ke Node + _control plane_ lainnya: + + Pada contoh berikut, ganti `CONTROL_PLANE_IPS` dengan alamat IP dari + Node _control plane_ lainnya. + ```sh + USER=ubuntu # dapat disesuaikan + CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8" + for host in ${CONTROL_PLANE_IPS}; do + scp /etc/kubernetes/pki/ca.crt "${USER}"@$host: + scp /etc/kubernetes/pki/ca.key "${USER}"@$host: + scp /etc/kubernetes/pki/sa.key "${USER}"@$host: + scp /etc/kubernetes/pki/sa.pub "${USER}"@$host: + scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host: + scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host: + scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt + # Kutip baris berikut jika kamu menggunakan etcd eksternal + scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key + done + ``` + + {{< caution >}} + Salinlah hanya sertifikat yang berada pada daftar di atas saja. Perkakas kubeadm akan mengambil alih pembuatan sertifikat lainnya + dengan SANs yang dibutuhkan untuk Node _control plane_ yang akan bergabung. Jika kamu menyalin seluruh sertifikat tanpa sengaja, + pembuatan Node tambahan dapat gagal akibat tidak adanya SANs yang dibutuhkan. + {{< /caution >}} + +5. Lalu, pada setiap Node _control plane_ yang bergabung kamu harus menjalankan skrip berikut sebelum menjalankan `kubeadm join`. + Skrip ini akan memindahkan sertifikat yang telah disalin sebelumnya dari direktori _home_ ke `/etc/kubernetes/pki`: + + ```sh + USER=ubuntu # dapat disesuaikan + mkdir -p /etc/kubernetes/pki/etcd + mv /home/${USER}/ca.crt /etc/kubernetes/pki/ + mv /home/${USER}/ca.key /etc/kubernetes/pki/ + mv /home/${USER}/sa.pub /etc/kubernetes/pki/ + mv /home/${USER}/sa.key /etc/kubernetes/pki/ + mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/ + mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/ + mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt + # Kutip baris berikut jika kamu menggunakan etcd eksternal + mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key + ``` + diff --git a/content/id/docs/tasks/tools/kubeadm/_index.md b/content/id/docs/tasks/tools/kubeadm/_index.md new file mode 100644 index 0000000000..e342c2da51 --- /dev/null +++ b/content/id/docs/tasks/tools/kubeadm/_index.md @@ -0,0 +1,4 @@ +--- +title: "Membangun klaster menggunakan kubeadm" +weight: 10 +--- From 920197b7b20bc6d98ca8ae943773084be189c6d4 Mon Sep 17 00:00:00 2001 From: Giri Kuncoro Date: Thu, 23 Jul 2020 09:37:57 +0700 Subject: [PATCH 51/86] Translate kustomize task page into bahasa indonesia Signed-off-by: Giri Kuncoro --- .../tasks/manage-kubernetes-objects/_index.md | 5 + .../kustomization.md | 841 ++++++++++++++++++ 2 files changed, 846 insertions(+) create mode 100644 content/id/docs/tasks/manage-kubernetes-objects/_index.md create mode 100644 content/id/docs/tasks/manage-kubernetes-objects/kustomization.md diff --git a/content/id/docs/tasks/manage-kubernetes-objects/_index.md b/content/id/docs/tasks/manage-kubernetes-objects/_index.md new file mode 100644 index 0000000000..26a982813e --- /dev/null +++ b/content/id/docs/tasks/manage-kubernetes-objects/_index.md @@ -0,0 +1,5 @@ +--- +title: "Mengelola Objek Kubernetes" +description: Paradigma deklaratif dan imperatif untuk berinteraksi dengan API Kubernetes. +weight: 25 +--- \ No newline at end of file diff --git a/content/id/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/id/docs/tasks/manage-kubernetes-objects/kustomization.md new file mode 100644 index 0000000000..680b20d371 --- /dev/null +++ b/content/id/docs/tasks/manage-kubernetes-objects/kustomization.md @@ -0,0 +1,841 @@ +--- +title: Mengelola Objek Kubernetes secara Deklaratif menggunakan Kustomize +content_type: task +weight: 20 +--- + + + +[Kustomize](https://github.com/kubernetes-sigs/kustomize) merupakan sebuah alat +untuk melakukan kustomisasi objek Kubernetes melalui sebuah berkas [berkas kustomization](https://github.com/kubernetes-sigs/kustomize/blob/master/docs/glossary.md#kustomization). + +Sejak versi 1.14, kubectl mendukung pengelolaan objek Kubernetes melalui berkas kustomization. +Untuk melihat sumber daya yang ada di dalam direktori yang memiliki berkas kustomization, jalankan perintah berikut: + +```shell +kubectl kustomize +``` + +Untuk menerapkan sumber daya tersebut, jalankan perintah `kubectl apply` dengan _flag_ `--kustomize` atau `-k`: + +```shell +kubectl apply -k +``` + + + +## {{% heading "prerequisites" %}} + + +Instal [`kubectl`](/id/docs/tasks/tools/install-kubectl/) terlebih dahulu. + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + + +## Gambaran Umum Kustomize + +Kustomize adalah sebuah alat untuk melakukan kustomisasi konfigurasi Kubernetes. Untuk mengelola berkas-berkas konfigurasi, kustomize memiliki fitur -fitur di bawah ini: + +* membangkitkan (_generate_) sumber daya dari sumber lain +* mengatur _field_ dari berbagai sumber daya yang bersinggungan +* mengkomposisikan dan melakukan kustomisasi sekelompok sumber daya + +### Membangkitkan Sumber Daya + +ConfigMap dan Secret menyimpan konfigurasi atau data sensitif yang digunakan oleh objek-objek Kubernetes lainnya, seperti Pod. +Biasanya, _source of truth_ dari ConfigMap atau Secret berasal dari luar klaster, seperti berkas `.properties` atau berkas kunci SSH. +Kustomize memiliki `secretGenerator` dan `configMapGenerator`, yang akan membangkitkan (_generate_) Secret dan ConfigMap dari berkas-berkas atau nilai-nilai literal. + +#### configMapGenerator + +Untuk membangkitkan sebuah ConfigMap dari berkas, tambahkan entri ke daftar `files` pada `configMapGenerator`. +Contoh di bawah ini membangkitkan sebuah ConfigMap dengan data dari berkas `.properties`: + +```shell +# Membuat berkas application.properties +cat <application.properties +FOO=Bar +EOF + +cat <./kustomization.yaml +configMapGenerator: +- name: example-configmap-1 + files: + - application.properties +EOF +``` + +ConfigMap yang telah dibangkitkan dapat dilihat menggunakan perintah berikut: + +```shell +kubectl kustomize ./ +``` + +Isinya seperti di bawah ini: + +```yaml +apiVersion: v1 +data: + application.properties: | + FOO=Bar +kind: ConfigMap +metadata: + name: example-configmap-1-8mbdf7882g +``` + +ConfigMap juga dapat dibangkitkan dari pasangan _key-value_ literal. Untuk membangkitkan secara literal, tambahkan entri pada daftar `literals` di `configMapGenerator`. +Contoh di bawah ini membangkitkan ConfigMap dengan data dari pasangan _key-value_: + +```shell +cat <./kustomization.yaml +configMapGenerator: +- name: example-configmap-2 + literals: + - FOO=Bar +EOF +``` + +ConfigMap yang dibangkitkan dapat dilihat menggunakan perintah berikut: + +```shell +kubectl kustomize ./ +``` + +Isinya seperti ini: + +```yaml +apiVersion: v1 +data: + FOO: Bar +kind: ConfigMap +metadata: + name: example-configmap-2-g2hdhfc6tk +``` + +#### secretGenerator + +Kamu dapat membangkitkan Secret dari berkas atau pasangan _key-value_ literal. Untuk membangkitkan dari berkas, tambahkan entri pada daftar `files` di `secretGenerator`. +Contoh di bawah ini membangkitkan Secret dengan data dari berkas: + +```shell +# Membuat berkas password.txt +cat <./password.txt +username=admin +password=secret +EOF + +cat <./kustomization.yaml +secretGenerator: +- name: example-secret-1 + files: + - password.txt +EOF +``` + +Isinya seperti ini: + +```yaml +apiVersion: v1 +data: + password.txt: dXNlcm5hbWU9YWRtaW4KcGFzc3dvcmQ9c2VjcmV0Cg== +kind: Secret +metadata: + name: example-secret-1-t2kt65hgtb +type: Opaque +``` + +Untuk membangkitkan secara literal dari pasangan _key-value_, tambahkan entri pada daftar `literals` di `secretGenerator`. +Contoh di bawah ini membangkitkan Secret dengan data dari pasangan _key-value_: + +```shell +cat <./kustomization.yaml +secretGenerator: +- name: example-secret-2 + literals: + - username=admin + - password=secret +EOF +``` + +Isinya seperti ini: + +```yaml +apiVersion: v1 +data: + password: c2VjcmV0 + username: YWRtaW4= +kind: Secret +metadata: + name: example-secret-2-t52t6g96d8 +type: Opaque +``` + +#### generatorOptions + +ConfigMap dan Secret yang dibangkitkan memiliki informasi sufiks _hash_. Hal ini memastikan bahwa ConfigMap atau Secret yang baru, dibangkitkan saat isinya berubah. +Untuk menonaktifkan penambahan sufiks ini, kamu bisa menggunakan `generatorOptions`. Selain itu, melalui _field_ ini kamu juga bisa mengatur opsi-opsi yang bersinggungan untuk ConfigMap dan Secret yang dibangkitkan. + +```shell +cat <./kustomization.yaml +configMapGenerator: +- name: example-configmap-3 + literals: + - FOO=Bar +generatorOptions: + disableNameSuffixHash: true + labels: + type: generated + annotations: + note: generated +EOF +``` + +Jalankan perintah `kubectl kustomize ./` untuk melihat ConfigMap yang dibangkitkan: + +```yaml +apiVersion: v1 +data: + FOO: Bar +kind: ConfigMap +metadata: + annotations: + note: generated + labels: + type: generated + name: example-configmap-3 +``` + +### Mengatur _field_ yang bersinggungan + +Mengatur _field-field_ yang bersinggungan untuk semua sumber daya Kubernetes dalam sebuah proyek. +Beberapa contoh kasusnya seperti di bawah ini: + +* mengatur Namespace yang sama untuk semua sumber daya +* menambahkan prefiks atau sufiks yang sama +* menambahkan kumpulan label yang sama +* menambahkan kumpulan anotasi yang sama + +Lihat contoh di bawah ini: + +```shell +# Membuat sebuah deployment.yaml +cat <./deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: nginx-deployment + labels: + app: nginx +spec: + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx +EOF + +cat <./kustomization.yaml +namespace: my-namespace +namePrefix: dev- +nameSuffix: "-001" +commonLabels: + app: bingo +commonAnnotations: + oncallPager: 800-555-1212 +resources: +- deployment.yaml +EOF +``` + +Jalankan perintah `kubectl kustomize ./` untuk melihat _field-field_ tersebut telah terisi di dalam sumber daya Deployment: + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + annotations: + oncallPager: 800-555-1212 + labels: + app: bingo + name: dev-nginx-deployment-001 + namespace: my-namespace +spec: + selector: + matchLabels: + app: bingo + template: + metadata: + annotations: + oncallPager: 800-555-1212 + labels: + app: bingo + spec: + containers: + - image: nginx + name: nginx +``` + +### Mengkomposisi dan Melakukan Kustomisasi Sumber Daya + +Mengkomposisi kumpulan sumber daya dalam sebuah proyek dan mengelolanya di dalam berkas atau direktori yang sama merupakan hal yang cukup umum dilakukan. +Kustomize menyediakan cara untuk mengkomposisi sumber daya dari berkas-berkas yang berbeda, lalu menerapkan _patch_ atau kustomisasi lain di atasnya. + +#### Melakukan Komposisi + +Kustomize mendukung komposisi dari berbagai sumber daya yang berbeda. _Field_ `resources` pada berkas `kustomization.yaml`, mendefinisikan daftar sumber daya yang diinginkan dalam sebuah konfigurasi. Atur terlebih dahulu jalur (_path_) ke berkas konfigurasi sumber daya pada daftar `resources`. +Contoh di bawah ini merupakan sebuah aplikasi NGINX yang terdiri dari sebuah Deployment dan sebuah Service: + +```shell +# Membuat berkas deployment.yaml +cat < deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + selector: + matchLabels: + run: my-nginx + replicas: 2 + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - name: my-nginx + image: nginx + ports: + - containerPort: 80 +EOF + +# Membuat berkas service.yaml +cat < service.yaml +apiVersion: v1 +kind: Service +metadata: + name: my-nginx + labels: + run: my-nginx +spec: + ports: + - port: 80 + protocol: TCP + selector: + run: my-nginx +EOF + +# Membuat berkas kustomization.yaml yang terdiri dari keduanya +cat <./kustomization.yaml +resources: +- deployment.yaml +- service.yaml +EOF +``` + +Sumber daya dari `kubectl kustomize ./` berisi kedua objek Deployment dan Service. + +#### Melakukan Kustomisasi + +_Patch_ dapat digunakan untuk menerapkan berbagai macam kustomisasi pada sumber daya. Kustomize mendukung berbagai mekanisme _patching_ yang berbeda melalui `patchesStrategicMerge` dan `patchesJson6902`. `patchesStrategicMerge` adalah daftar dari yang berisi tentang _path_ berkas. Setiap berkas akan dioperasikan dengan cara [strategic merge patch](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/strategic-merge-patch.md). Nama di dalam _patch_ harus sesuai dengan nama sumber daya yang telah dimuat. Kami menyarankan _patch-patch_ kecil yang hanya melakukan satu hal saja. +Contoh membuat sebuah _patch_ di bawah ini akan menambahkan jumlah replika Deployment dan _patch_ lainnya untuk mengatur limit memori. + +```shell +# Membuat berkas deployment.yaml +cat < deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + selector: + matchLabels: + run: my-nginx + replicas: 2 + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - name: my-nginx + image: nginx + ports: + - containerPort: 80 +EOF + +# Membuat sebuah patch increase_replicas.yaml +cat < increase_replicas.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + replicas: 3 +EOF + +# Membuat patch lainnya set_memory.yaml +cat < set_memory.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + template: + spec: + containers: + - name: my-nginx + resources: + limits: + memory: 512Mi +EOF + +cat <./kustomization.yaml +resources: +- deployment.yaml +patchesStrategicMerge: +- increase_replicas.yaml +- set_memory.yaml +EOF +``` + +Jalankan perintah `kubectl kustomize ./` untuk melihat isi dari Deployment: + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + replicas: 3 + selector: + matchLabels: + run: my-nginx + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - image: nginx + limits: + memory: 512Mi + name: my-nginx + ports: + - containerPort: 80 +``` + +Tidak semua sumber daya atau _field_ mendukung _strategic merge patch_. Untuk mendukung _field_ sembarang pada sumber daya _field_, Kustomize +menyediakan penerapan [_patch_ JSON](https://tools.ietf.org/html/rfc6902) melalui `patchesJson6902`. +Untuk mencari sumber daya yang tepat dengan sebuah _patch_ Json, maka grup, versi, jenis dan nama dari sumber daya harus dispesifikasikan dalam `kustomization.yaml`. +Contoh di bawah ini menambahkan jumlah replika dari objek Deployment yang bisa juga dilakukan melalui `patchesJson6902`. + +```shell +# Membuat berkas deployment.yaml +cat < deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + selector: + matchLabels: + run: my-nginx + replicas: 2 + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - name: my-nginx + image: nginx + ports: + - containerPort: 80 +EOF + +# Membuat patch json +cat < patch.yaml +- op: replace + path: /spec/replicas + value: 3 +EOF + +# Membuat berkas kustomization.yaml +cat <./kustomization.yaml +resources: +- deployment.yaml + +patchesJson6902: +- target: + group: apps + version: v1 + kind: Deployment + name: my-nginx + path: patch.yaml +EOF +``` + +Jalankan perintah `kubectl kustomize ./` untuk melihat _field_ `replicas` yang telah diperbarui: + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + replicas: 3 + selector: + matchLabels: + run: my-nginx + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - image: nginx + name: my-nginx + ports: + - containerPort: 80 +``` + +Selain _patch_, Kustomize juga menyediakan cara untuk melakukan kustomisasi _image_ Container atau memasukkan nilai _field_ dari objek lainnya ke dalam Container tanpa membuat _patch_. Sebagai contoh, kamu dapat melakukan kustomisasi _image_ yang digunakan di dalam Container dengan menyebutkan spesifikasi _field_ `images` di dalam `kustomization.yaml`. + +```shell +cat < deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + selector: + matchLabels: + run: my-nginx + replicas: 2 + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - name: my-nginx + image: nginx + ports: + - containerPort: 80 +EOF + +cat <./kustomization.yaml +resources: +- deployment.yaml +images: +- name: nginx + newName: my.image.registry/nginx + newTag: 1.4.0 +EOF +``` + +Jalankan perintah `kubectl kustomize ./` untuk melihat _image_ yang sedang digunakan telah diperbarui: +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + replicas: 2 + selector: + matchLabels: + run: my-nginx + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - image: my.image.registry/nginx:1.4.0 + name: my-nginx + ports: + - containerPort: 80 +``` + +Terkadang, aplikasi yang berjalan di dalam Pod perlu untuk menggunakan nilai konfigurasi dari objek lainnya. +Contohnya, sebuah Pod dari objek Deployment perlu untuk membaca nama Service dari Env atau sebagai argumen perintah. +Ini karena nama Service bisa saja berubah akibat dari penambahan `namePrefix` atau `nameSuffix` pada berkas `kustomization.yaml`. +Kami tidak menyarankan kamu untuk meng-_hardcode_ nama Service di dalam argumen perintah. +Untuk penggunaan ini, Kustomize dapat memasukkan nama Service ke dalam Container melalui `vars`. + +```shell +# Membuat berkas deployment.yaml +cat < deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + selector: + matchLabels: + run: my-nginx + replicas: 2 + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - name: my-nginx + image: nginx + command: ["start", "--host", "\$(MY_SERVICE_NAME)"] +EOF + +# Membuat berkas service.yaml +cat < service.yaml +apiVersion: v1 +kind: Service +metadata: + name: my-nginx + labels: + run: my-nginx +spec: + ports: + - port: 80 + protocol: TCP + selector: + run: my-nginx +EOF + +cat <./kustomization.yaml +namePrefix: dev- +nameSuffix: "-001" + +resources: +- deployment.yaml +- service.yaml + +vars: +- name: MY_SERVICE_NAME + objref: + kind: Service + name: my-nginx + apiVersion: v1 +EOF +``` + +Jalankan perintah `kubectl kustomize ./` untuk melihat nama Service yang dimasukkan ke dalam Container menjadi `dev-my-nginx-001`: + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: dev-my-nginx-001 +spec: + replicas: 2 + selector: + matchLabels: + run: my-nginx + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - command: + - start + - --host + - dev-my-nginx-001 + image: nginx + name: my-nginx +``` + +## Base dan Overlay + +Kustomize memiliki konsep **base** dan **overlay**. **base** merupakan direktori dengan `kustomization.yaml`, yang berisi +sekumpulan sumber daya dan kustomisasi yang terkait. **base** dapat berupa direktori lokal maupun direktori dari repo _remote_, +asalkan berkas `kustomization.yaml` ada di dalamnya. **overlay** merupakan direktori dengan `kustomization.yaml` yang merujuk pada +direktori kustomization lainnya sebagai **base**-nya. **base** tidak memiliki informasi tentang **overlay**. dan dapat digunakan pada beberapa **overlay** sekaligus. +**overlay** bisa memiliki beberapa **base** dan terdiri dari semua sumber daya yang berasal dari **base** yang juga dapat memiliki kustomisasi lagi di atasnya. + +Contoh di bawah ini memperlihatkan kegunaan dari **base**: + +```shell +# Membuat direktori untuk menyimpan base +mkdir base +# Membuat base/deployment.yaml +cat < base/deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + selector: + matchLabels: + run: my-nginx + replicas: 2 + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - name: my-nginx + image: nginx +EOF + +# Membuat berkas base/service.yaml +cat < base/service.yaml +apiVersion: v1 +kind: Service +metadata: + name: my-nginx + labels: + run: my-nginx +spec: + ports: + - port: 80 + protocol: TCP + selector: + run: my-nginx +EOF + +# Membuat berkas base/kustomization.yaml +cat < base/kustomization.yaml +resources: +- deployment.yaml +- service.yaml +EOF +``` + +**base** ini dapat digunakan di dalam beberapa **overlay** sekaligus. Kamu dapat menambahkan `namePrefix` yang berbeda ataupun +_field_ lainnya yang bersinggungan di dalam **overlay** berbeda. Di bawah ini merupakan dua buah **overlay** yang menggunakan **base** yang sama. + +```shell +mkdir dev +cat < dev/kustomization.yaml +bases: +- ../base +namePrefix: dev- +EOF + +mkdir prod +cat < prod/kustomization.yaml +bases: +- ../base +namePrefix: prod- +EOF +``` + +## Cara menerapkan/melihat/menghapus objek menggunakan Kustomize + +Gunakan `--kustomize` atau `-k` di dalam perintah `kubectl` untuk mengenali sumber daya yang dikelola oleh `kustomization.yaml`. +Perhatikan bahwa `-k` harus merujuk pada direktori kustomization, misalnya: + +```shell +kubectl apply -k / +``` + +Buatlah `kustomization.yaml` seperti di bawah ini: + +```shell +# Membuat berkas deployment.yaml +cat < deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + selector: + matchLabels: + run: my-nginx + replicas: 2 + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - name: my-nginx + image: nginx + ports: + - containerPort: 80 +EOF + +# Membuat berkas kustomization.yaml +cat <./kustomization.yaml +namePrefix: dev- +commonLabels: + app: my-nginx +resources: +- deployment.yaml +EOF +``` + +Jalankan perintah di bawah ini untuk menerapkan objek Deployment `dev-my-nginx`: + +```shell +> kubectl apply -k ./ +deployment.apps/dev-my-nginx created +``` + +Jalankan perintah di bawah ini untuk melihat objek Deployment `dev-my-nginx`: + +```shell +kubectl get -k ./ +``` + +```shell +kubectl describe -k ./ +``` + +Jalankan perintah di bawah ini untuk membandingkan objek Deployment `dev-my-nginx` dengan kondisi yang diinginkan pada klaster jika manifes telah berhasil diterapkan: + +```shell +kubectl diff -k ./ +``` + +Jalankan perintah di bawah ini untuk menghapus objek Deployment `dev-my-nginx`: + +```shell +> kubectl delete -k ./ +deployment.apps "dev-my-nginx" deleted +``` + +## Daftar Fitur Kustomize + +| _Field_ | Tipe | Deskripsi | +|-----------------------|--------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------| +| namespace | string | menambahkan Namespace untuk semua sumber daya | +| namePrefix | string | nilai dari _field_ ini ditambahkan di awal pada nama dari semua sumber daya | +| nameSuffix | string | nilai dari _field_ ini ditambahkan di akhir pada nama dari semua sumber daya | +| commonLabels | map[string]string | label untuk ditambahkan pada semua sumber daya dan selektor | +| commonAnnotations | map[string]string | anotasi untuk ditambahkan pada semua sumber daya | +| resources | []string | setiap entri di dalam daftar ini harus diselesaikan pada berkas konfigurasi sumber daya yang sudah ada | +| configmapGenerator | [][ConfigMapArgs](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/kustomization.go#L99) | setiap entri di dalam daftar ini membangkitkan ConfigMap | +| secretGenerator | [][SecretArgs](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/kustomization.go#L106) | setiap entri di dalam daftar ini membangkitkan Secret | +| generatorOptions | [GeneratorOptions](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/kustomization.go#L109) | memodifikasi perilaku dari semua generator ConfigMap dan Secret | +| bases | []string | setiap entri di dalam daftar ini harus diselesaikan ke dalam sebuah direktori yang berisi berkas kustomization.yaml | +| patchesStrategicMerge | []string | setiap entri di dalam daftar ini harus diselesaikan dengan _strategic merge patch_ dari sebuah objek Kubernetes | +| patchesJson6902 | [][Json6902](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/patchjson6902.go#L8) | setiap entri di dalam daftar ini harus diselesaikan ke suatu objek Kubernetes atau _patch_ Json | +| vars | [][Var](https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/var.go#L31) | setiap entri digunakan untuk menangkap teks yang berasal dari _field_ sebuah sumber daya | +| images | [][Image](https://github.com/kubernetes-sigs/kustomize/tree/master/api/types/image.go#L23) | setiap entri digunakan untuk memodifikasi nama, tag dan/atau _digest_ untuk sebuah _image_ tanpa membuat _patch_ | +| configurations | []string | setiap entri di dalam daftar ini harus diselesaikan ke sebuah berkas yang berisi [konfigurasi transformer Kustomize](https://github.com/kubernetes-sigs/kustomize/tree/master/examples/transformerconfigs) | +| crds | []string | setiap entri di dalam daftar ini harus diselesaikan ke sebuah berkas definisi OpenAPI untuk tipe Kubernetes | + + + +## {{% heading "whatsnext" %}} + + +* [Kustomize](https://github.com/kubernetes-sigs/kustomize) +* [Buku Kubectl](https://kubectl.docs.kubernetes.io) +* [Rujukan Perintah Kubectl](/id/docs/reference/generated/kubectl/kubectl/) +* [Rujukan API Kubernetes](/id/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) + + From 5495c88a20809a62b4721553476a47b54e299ff7 Mon Sep 17 00:00:00 2001 From: Guyllaume Doyer Date: Fri, 24 Jul 2020 12:11:48 +0200 Subject: [PATCH 52/86] Update install-kubectl.md Fixed a typo in french translation of install kubectl page --- content/fr/docs/tasks/tools/install-kubectl.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/fr/docs/tasks/tools/install-kubectl.md b/content/fr/docs/tasks/tools/install-kubectl.md index 8d60357aea..2a88388374 100644 --- a/content/fr/docs/tasks/tools/install-kubectl.md +++ b/content/fr/docs/tasks/tools/install-kubectl.md @@ -121,7 +121,7 @@ kubectl version --client curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl ``` -2. Rendrez le binaire kubectl exécutable. +2. Rendez le binaire kubectl exécutable. ``` chmod +x ./kubectl From 7f71c6c053758c48abb5227888c7631d2c8c4870 Mon Sep 17 00:00:00 2001 From: Michael Weibel Date: Fri, 24 Jul 2020 12:25:58 +0200 Subject: [PATCH 53/86] windows: update link to docker engine installation the existing link unfortunately is a dead link and doesn't redirect to the new place properly. Linking directly probably makes sense. --- .../tasks/administer-cluster/kubeadm/adding-windows-nodes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md index e82c53f3a6..c3498fce61 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md @@ -140,7 +140,7 @@ curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/dow ### Joining a Windows worker node {{< note >}} You must install the `Containers` feature and install Docker. Instructions -to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://docs.docker.com/ee/docker-ee/windows/docker-ee/#install-docker-engine---enterprise). +to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://docs.mirantis.com/docker-enterprise/v3.1/dockeree-products/docker-engine-enterprise/dee-windows.html). {{< /note >}} {{< note >}} From 39ad302c826b90f597c9a21b098ef76f4e093a6a Mon Sep 17 00:00:00 2001 From: Eric Briand <1011902+ebriand@users.noreply.github.com> Date: Fri, 24 Jul 2020 13:54:08 +0200 Subject: [PATCH 54/86] Use more real container examples --- .../manage-resources-containers.md | 21 +++++++------------ 1 file changed, 8 insertions(+), 13 deletions(-) diff --git a/content/en/docs/concepts/configuration/manage-resources-containers.md b/content/en/docs/concepts/configuration/manage-resources-containers.md index db78a8304e..275b70866a 100644 --- a/content/en/docs/concepts/configuration/manage-resources-containers.md +++ b/content/en/docs/concepts/configuration/manage-resources-containers.md @@ -132,11 +132,9 @@ metadata: name: frontend spec: containers: - - name: db - image: mysql + - name: app + image: super.mycompany.com/app:v4 env: - - name: MYSQL_ROOT_PASSWORD - value: "password" resources: requests: memory: "64Mi" @@ -144,8 +142,8 @@ spec: limits: memory: "128Mi" cpu: "500m" - - name: wp - image: wordpress + - name: log-aggregator + image: super.mycompany.com/log-aggregator:v6 resources: requests: memory: "64Mi" @@ -330,18 +328,15 @@ metadata: name: frontend spec: containers: - - name: db - image: mysql - env: - - name: MYSQL_ROOT_PASSWORD - value: "password" + - name: app + image: super.mycompany.com/app:v4 resources: requests: ephemeral-storage: "2Gi" limits: ephemeral-storage: "4Gi" - - name: wp - image: wordpress + - name: log-aggregator + image: super.mycompany.com/log-aggregator:v6 resources: requests: ephemeral-storage: "2Gi" From b0d3fb3144743796c9664e4c558fe05c9d4ae475 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Sat, 25 Jul 2020 01:49:14 +0900 Subject: [PATCH 55/86] Fix markdown errors of unordered list in blog posts. --- .../2015-05-00-Kubernetes-On-Openstack.md | 42 ++--- ...The-Distributed-System-Toolkit-Patterns.md | 12 +- ...-Weekly-Kubernetes-Community-Hangout_23.md | 150 ++++++------------ ...00-Elasticbox-Introduces-Elastickube-To.md | 27 +--- ...-Kubernetes-In-Enterprise-With-Fujitsus.md | 33 ++-- ...-State-Of-Container-World-February-2016.md | 15 +- ...ner-Runtime-Interface-Cri-In-Kubernetes.md | 12 +- .../2016-12-00-Five-Days-Of-Kubernetes-1-5.md | 15 +- ...12-00-Windows-Server-Support-Kubernetes.md | 11 +- .../2017-05-00-Kubernetes-Monitoring-Guide.md | 12 +- ...ay-Ansible-Collaborative-Kubernetes-Ops.md | 12 +- ...-07-00-Happy-Second-Birthday-Kubernetes.md | 57 +++---- ...7-07-00-How-Watson-Health-Cloud-Deploys.md | 27 ++-- ...00-Kompose-Helps-Developers-Move-Docker.md | 40 ++--- ...9-00-Kubernetes-Statefulsets-Daemonsets.md | 15 +- 15 files changed, 161 insertions(+), 319 deletions(-) diff --git a/content/en/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md b/content/en/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md index 35918b5dbe..1e2b4ce3a5 100644 --- a/content/en/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md +++ b/content/en/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md @@ -19,34 +19,20 @@ The entries in the catalog include not just the ability to [start a Kubernetes c -- -Apache web server -- -Nginx web server -- -Crate - The Distributed Database for Docker -- -GlassFish - Java EE 7 Application Server -- -Tomcat - An open-source web server and servlet container -- -InfluxDB - An open-source, distributed, time series database -- -Grafana - Metrics dashboard for InfluxDB -- -Jenkins - An extensible open source continuous integration server -- -MariaDB database -- -MySql database -- -Redis - Key-value cache and store -- -PostgreSQL database -- -MongoDB NoSQL database -- -Zend Server - The Complete PHP Application Platform +- Apache web server +- Nginx web server +- Crate - The Distributed Database for Docker +- GlassFish - Java EE 7 Application Server +- Tomcat - An open-source web server and servlet container +- InfluxDB - An open-source, distributed, time series database +- Grafana - Metrics dashboard for InfluxDB +- Jenkins - An extensible open source continuous integration server +- MariaDB database +- MySql database +- Redis - Key-value cache and store +- PostgreSQL database +- MongoDB NoSQL database +- Zend Server - The Complete PHP Application Platform diff --git a/content/en/blog/_posts/2015-06-00-The-Distributed-System-Toolkit-Patterns.md b/content/en/blog/_posts/2015-06-00-The-Distributed-System-Toolkit-Patterns.md index d8c3c59a08..f5a050bd19 100644 --- a/content/en/blog/_posts/2015-06-00-The-Distributed-System-Toolkit-Patterns.md +++ b/content/en/blog/_posts/2015-06-00-The-Distributed-System-Toolkit-Patterns.md @@ -12,14 +12,10 @@ In many ways the switch from VMs to containers is like the switch from monolithi The benefits of thinking in terms of modular containers are enormous, in particular, modular containers provide the following: -- -Speed application development, since containers can be re-used between teams and even larger communities -- -Codify expert knowledge, since everyone collaborates on a single containerized implementation that reflects best-practices rather than a myriad of different home-grown containers with roughly the same functionality -- -Enable agile teams, since the container boundary is a natural boundary and contract for team responsibilities -- -Provide separation of concerns and focus on specific functionality that reduces spaghetti dependencies and un-testable components +- Speed application development, since containers can be re-used between teams and even larger communities +- Codify expert knowledge, since everyone collaborates on a single containerized implementation that reflects best-practices rather than a myriad of different home-grown containers with roughly the same functionality +- Enable agile teams, since the container boundary is a natural boundary and contract for team responsibilities +- Provide separation of concerns and focus on specific functionality that reduces spaghetti dependencies and un-testable components Building an application from modular containers means thinking about symbiotic groups of containers that cooperate to provide a service, not one container per service.  In Kubernetes, the embodiment of this modular container service is a Pod.  A Pod is a group of containers that share resources like file systems, kernel namespaces and an IP address.  The Pod is the atomic unit of scheduling in a Kubernetes cluster, precisely because the symbiotic nature of the containers in the Pod require that they be co-scheduled onto the same machine, and the only way to reliably achieve this is by making container groups atomic scheduling units. diff --git a/content/en/blog/_posts/2015-07-00-Weekly-Kubernetes-Community-Hangout_23.md b/content/en/blog/_posts/2015-07-00-Weekly-Kubernetes-Community-Hangout_23.md index 753e2250be..9703dd6141 100644 --- a/content/en/blog/_posts/2015-07-00-Weekly-Kubernetes-Community-Hangout_23.md +++ b/content/en/blog/_posts/2015-07-00-Weekly-Kubernetes-Community-Hangout_23.md @@ -14,121 +14,71 @@ Here are the notes from today's meeting: -- -Eric Paris: replacing salt with ansible (if we want) +- Eric Paris: replacing salt with ansible (if we want) - - -In contrib, there is a provisioning tool written in ansible - - -The goal in the rewrite was to eliminate as much of the cloud provider stuff as possible - - -The salt setup does a bunch of setup in scripts and then the environment is setup with salt + - In contrib, there is a provisioning tool written in ansible + - The goal in the rewrite was to eliminate as much of the cloud provider stuff as possible + - The salt setup does a bunch of setup in scripts and then the environment is setup with salt - - -This means that things like generating certs is done differently on GCE/AWS/Vagrant - - -For ansible, everything must be done within ansible - - -Background on ansible + - This means that things like generating certs is done differently on GCE/AWS/Vagrant + - For ansible, everything must be done within ansible + - Background on ansible - - -Does not have clients - - -Provisioner ssh into the machine and runs scripts on the machine - - -You define what you want your cluster to look like, run the script, and it sets up everything at once - - -If you make one change in a config file, ansible re-runs everything (which isn’t always desirable) - - -Uses a jinja2 template - - -Create machines with minimal software, then use ansible to get that machine into a runnable state + - Does not have clients + - Provisioner ssh into the machine and runs scripts on the machine + - You define what you want your cluster to look like, run the script, and it sets up everything at once + - If you make one change in a config file, ansible re-runs everything (which isn’t always desirable) + - Uses a jinja2 template + - Create machines with minimal software, then use ansible to get that machine into a runnable state - - -Sets up all of the add-ons - - -Eliminates the provisioner shell scripts - - -Full cluster setup currently takes about 6 minutes + - Sets up all of the add-ons + - Eliminates the provisioner shell scripts + - Full cluster setup currently takes about 6 minutes - - -CentOS with some packages - - -Redeploy to the cluster takes 25 seconds - - -Questions for Eric + - CentOS with some packages + - Redeploy to the cluster takes 25 seconds + - Questions for Eric - - -Where does the provider-specific configuration go? + - Where does the provider-specific configuration go? - - -The only network setup that the ansible config does is flannel; you can turn it off - - -What about init vs. systemd? + - The only network setup that the ansible config does is flannel; you can turn it off + - What about init vs. systemd? - - -Should be able to support in the code w/o any trouble (not yet implemented) - - -Discussion + - Should be able to support in the code w/o any trouble (not yet implemented) + - Discussion - - -Why not push the setup work into containers or kubernetes config? + - Why not push the setup work into containers or kubernetes config? - - -To bootstrap a cluster drop a kubelet and a manifest - - -Running a kubelet and configuring the network should be the only things required. We can cut a machine image that is preconfigured minus the data package (certs, etc) + - To bootstrap a cluster drop a kubelet and a manifest + - Running a kubelet and configuring the network should be the only things required. We can cut a machine image that is preconfigured minus the data package (certs, etc) - - -The ansible scripts install kubelet & docker if they aren’t already installed - - -Each OS (RedHat, Debian, Ubuntu) could have a different image. We could view this as part of the build process instead of the install process. - - -There needs to be solution for bare metal as well. - - -In favor of the overall goal -- reducing the special configuration in the salt configuration - - -Everything except the kubelet should run inside a container (eventually the kubelet should as well) + - The ansible scripts install kubelet & docker if they aren’t already installed + - Each OS (RedHat, Debian, Ubuntu) could have a different image. We could view this as part of the build process instead of the install process. + - There needs to be solution for bare metal as well. + - In favor of the overall goal -- reducing the special configuration in the salt configuration + - Everything except the kubelet should run inside a container (eventually the kubelet should as well) - - -Running in a container doesn’t cut down on the complexity that we currently have - - -But it does more clearly define the interface about what the code expects - - -These tools (Chef, Puppet, Ansible) conflate binary distribution with configuration + - Running in a container doesn’t cut down on the complexity that we currently have + - But it does more clearly define the interface about what the code expects + - These tools (Chef, Puppet, Ansible) conflate binary distribution with configuration - - -Containers more clearly separate these problems - - -The mesos deployment is not completely automated yet, but the mesos deployment is completely different: kubelets get put on top on an existing mesos cluster + - Containers more clearly separate these problems + - The mesos deployment is not completely automated yet, but the mesos deployment is completely different: kubelets get put on top on an existing mesos cluster - - -The bash scripts allow the mesos devs to see what each cloud provider is doing and re-use the relevant bits - - -There was a large reverse engineering curve, but the bash is at least readable as opposed to the salt - - -Openstack uses a different deployment as well - - -We need a well documented list of steps (e.g. create certs) that are necessary to stand up a cluster + - The bash scripts allow the mesos devs to see what each cloud provider is doing and re-use the relevant bits + - There was a large reverse engineering curve, but the bash is at least readable as opposed to the salt + - Openstack uses a different deployment as well + - We need a well documented list of steps (e.g. create certs) that are necessary to stand up a cluster - - -This would allow us to compare across cloud providers - - -We should reduce the number of steps as much as possible - - -Ansible has 241 steps to launch a cluster -- -1.0 Code freeze + - This would allow us to compare across cloud providers + - We should reduce the number of steps as much as possible + - Ansible has 241 steps to launch a cluster +- 1.0 Code freeze - - -How are we getting out of code freeze? - - -This is a topic for next week, but the preview is that we will move slowly rather than totally opening the firehose + - How are we getting out of code freeze? + - This is a topic for next week, but the preview is that we will move slowly rather than totally opening the firehose - - -We want to clear the backlog as fast as possible while maintaining stability both on HEAD and on the 1.0 branch - - -The backlog of almost 300 PRs but there are also various parallel feature branches that have been developed during the freeze - - -Cutting a cherry pick release today (1.0.1) that fixes a few issues + - We want to clear the backlog as fast as possible while maintaining stability both on HEAD and on the 1.0 branch + - The backlog of almost 300 PRs but there are also various parallel feature branches that have been developed during the freeze + - Cutting a cherry pick release today (1.0.1) that fixes a few issues - Next week we will discuss the cadence for patch releases diff --git a/content/en/blog/_posts/2016-03-00-Elasticbox-Introduces-Elastickube-To.md b/content/en/blog/_posts/2016-03-00-Elasticbox-Introduces-Elastickube-To.md index 1a67c9334e..e1df83d3e2 100644 --- a/content/en/blog/_posts/2016-03-00-Elasticbox-Introduces-Elastickube-To.md +++ b/content/en/blog/_posts/2016-03-00-Elasticbox-Introduces-Elastickube-To.md @@ -16,17 +16,10 @@ Fundamentally, ElasticKube delivers a web console for which compliments Kubernet ElasticKube enables organizations to accelerate adoption by developers, application operations and traditional IT operations teams and shares a mutual goal of increasing developer productivity, driving efficiency in container management and promoting the use of microservices as a modern application delivery methodology. When leveraging ElasticKube in your environment, users need to ensure the following technologies are configured appropriately to guarantee everything runs correctly: -- -Configure Google Container Engine (GKE) for cluster installation and management - -- -Use Kubernetes to provision the infrastructure and clusters for containers   - -- -Use your existing tools of choice to actually build your containers -- - -Use ElasticKube to run, deploy and manage your containers and services +- Configure Google Container Engine (GKE) for cluster installation and management +- Use Kubernetes to provision the infrastructure and clusters for containers   +- Use your existing tools of choice to actually build your containers +- Use ElasticKube to run, deploy and manage your containers and services [![](https://cl.ly/0i3M2L3Q030z/Image%202016-03-11%20at%209.49.12%20AM.png)](http://cl.ly/0i3M2L3Q030z/Image%202016-03-11%20at%209.49.12%20AM.png) @@ -39,14 +32,10 @@ Getting Started with Kubernetes and ElasticKube (this is a 3min walk through video with the following topics) -1. -Deploy ElasticKube to a Kubernetes cluster -2. -Configuration -3. -Admin: Setup and invite a user -4. -Deploy an instance +1. Deploy ElasticKube to a Kubernetes cluster +2. Configuration +3. Admin: Setup and invite a user +4. Deploy an instance diff --git a/content/en/blog/_posts/2016-03-00-Kubernetes-In-Enterprise-With-Fujitsus.md b/content/en/blog/_posts/2016-03-00-Kubernetes-In-Enterprise-With-Fujitsus.md index 3bfa309fd1..b02f089cac 100644 --- a/content/en/blog/_posts/2016-03-00-Kubernetes-In-Enterprise-With-Fujitsus.md +++ b/content/en/blog/_posts/2016-03-00-Kubernetes-In-Enterprise-With-Fujitsus.md @@ -13,24 +13,18 @@ Today, we want to take you on a short tour explaining the background of our offe In mid 2014 we looked at the challenges enterprises are facing in the context of digitization, where traditional enterprises experience that more and more competitors from the IT sector are pushing into the core of their markets. A big part of Fujitsu’s customers are such traditional businesses, so we considered how we could help them and came up with three basic principles: -- -Decouple applications from infrastructure - Focus on where the value for the customer is: the application. -- -Decompose applications - Build applications from smaller, loosely coupled parts. Enable reconfiguration of those parts depending on the needs of the business. Also encourage innovation by low-cost experiments. -- -Automate everything - Fight the increasing complexity of the first two points by introducing a high degree of automation. +- Decouple applications from infrastructure - Focus on where the value for the customer is: the application. +- Decompose applications - Build applications from smaller, loosely coupled parts. Enable reconfiguration of those parts depending on the needs of the business. Also encourage innovation by low-cost experiments. +- Automate everything - Fight the increasing complexity of the first two points by introducing a high degree of automation. We found that Linux containers themselves cover the first point and touch the second. But at this time there was little support for creating distributed applications and running them managed automatically. We found Kubernetes as the missing piece. **Not a free lunch** The general approach of Kubernetes in managing containerized workload is convincing, but as we looked at it with the eyes of customers, we realized that it’s not a free lunch. Many  customers are medium-sized companies whose core business is often bound to strict data protection regulations. The top three requirements we identified are: -- -On-premise deployments (with the option for hybrid scenarios) -- -Efficient operations as part of a (much) bigger IT infrastructure -- -Enterprise-grade support, potentially on global scale +- On-premise deployments (with the option for hybrid scenarios) +- Efficient operations as part of a (much) bigger IT infrastructure +- Enterprise-grade support, potentially on global scale We created Cloud Load Control with these requirements in mind. It is basically a distribution of Kubernetes targeted for on-premise use, primarily focusing on operational aspects of container infrastructure. We are committed to work with the community, and contribute all relevant changes and extensions upstream to the Kubernetes project. **On-premise deployments** @@ -39,12 +33,9 @@ As Kubernetes core developer Tim Hockin often puts it in his[talks](https://spea Cloud Load Control addresses these issues. It enables customers to reliably and readily provision a production grade Kubernetes clusters on their own infrastructure, with the following benefits: -- -Proven setup process, lowers risk of problems while setting up the cluster -- -Reduction of provisioning time to minutes -- -Repeatable process, relevant especially for large, multi-tenant environments +- Proven setup process, lowers risk of problems while setting up the cluster +- Reduction of provisioning time to minutes +- Repeatable process, relevant especially for large, multi-tenant environments Cloud Load Control delivers these benefits for a range of platforms, starting from selected OpenStack distributions in the first versions of Cloud Load Control, and successively adding more platforms depending on customer demand.  We are especially excited about the option to remove the virtualization layer and support Kubernetes bare-metal on Fujitsu servers in the long run. By removing a layer of complexity, the total cost to run the system would be decreased and the missing hypervisor would increase performance. @@ -53,10 +44,8 @@ Right now we are in the process of contributing a generic provider to set up Kub Reducing operation costs is the target of any organization providing IT infrastructure. This can be achieved by increasing the efficiency of operations and helping operators to get their job done. Considering large-scale container infrastructures, we found it is important to differentiate between two types of operations: -- -Platform-oriented, relates to the overall infrastructure, often including various systems, one of which might be Kubernetes. -- -Application-oriented, focusses rather on a single, or a small set of applications deployed on Kubernetes. +- Platform-oriented, relates to the overall infrastructure, often including various systems, one of which might be Kubernetes. +- Application-oriented, focusses rather on a single, or a small set of applications deployed on Kubernetes. Kubernetes is already great for the application-oriented part. Cloud Load Control was created to help platform-oriented operators to efficiently manage Kubernetes as part of the overall infrastructure and make it easy to execute Kubernetes tasks relevant to them. diff --git a/content/en/blog/_posts/2016-03-00-State-Of-Container-World-February-2016.md b/content/en/blog/_posts/2016-03-00-State-Of-Container-World-February-2016.md index 27f84d3e7b..025c311606 100644 --- a/content/en/blog/_posts/2016-03-00-State-Of-Container-World-February-2016.md +++ b/content/en/blog/_posts/2016-03-00-State-Of-Container-World-February-2016.md @@ -11,15 +11,12 @@ Hello, and welcome to the second installment of the Kubernetes state of the cont In January, 71% of respondents were currently using containers, in February, 89% of respondents were currently using containers. The percentage of users not even considering containers also shrank from 4% in January to a surprising 0% in February. Will see if that holds consistent in March.Likewise, the usage of containers continued to march across the dev/canary/prod lifecycle. In all parts of the lifecycle, container usage increased: -- -Development: 80% -\> 88% -- -Test: 67% -\> 72% -- -Pre production: 41% -\> 55% -- -Production: 50% -\> 62% -What is striking in this is that pre-production growth continued, even as workloads were clearly transitioned into true production. Likewise the share of people considering containers for production rose from 78% in January to 82% in February. Again we’ll see if the trend continues into March. +- Development: 80% -\> 88% +- Test: 67% -\> 72% +- Pre production: 41% -\> 55% +- Production: 50% -\> 62% + +What is striking in this is that pre-production growth continued, even as workloads were clearly transitioned into true production. Likewise the share of people considering containers for production rose from 78% in January to 82% in February. Again we’ll see if the trend continues into March. ## Container and cluster sizes diff --git a/content/en/blog/_posts/2016-12-00-Container-Runtime-Interface-Cri-In-Kubernetes.md b/content/en/blog/_posts/2016-12-00-Container-Runtime-Interface-Cri-In-Kubernetes.md index 061a39c196..721b217c47 100644 --- a/content/en/blog/_posts/2016-12-00-Container-Runtime-Interface-Cri-In-Kubernetes.md +++ b/content/en/blog/_posts/2016-12-00-Container-Runtime-Interface-Cri-In-Kubernetes.md @@ -215,14 +215,10 @@ CRI is being actively developed and maintained by the Kubernetes [SIG-Node](http -- -Post issues or feature requests on [GitHub](https://github.com/kubernetes/kubernetes) -- -Join the #sig-node channel on [Slack](https://kubernetes.slack.com/) -- -Subscribe to the [SIG-Node mailing list](mailto:kubernetes-sig-node@googlegroups.com) -- -Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates +- Post issues or feature requests on [GitHub](https://github.com/kubernetes/kubernetes) +- Join the #sig-node channel on [Slack](https://kubernetes.slack.com/) +- Subscribe to the [SIG-Node mailing list](mailto:kubernetes-sig-node@googlegroups.com) +- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates diff --git a/content/en/blog/_posts/2016-12-00-Five-Days-Of-Kubernetes-1-5.md b/content/en/blog/_posts/2016-12-00-Five-Days-Of-Kubernetes-1-5.md index 14eae43fc6..fa30aba5f7 100644 --- a/content/en/blog/_posts/2016-12-00-Five-Days-Of-Kubernetes-1-5.md +++ b/content/en/blog/_posts/2016-12-00-Five-Days-Of-Kubernetes-1-5.md @@ -21,13 +21,8 @@ This progress is our commitment in continuing to make Kubernetes best way to man Connect -- -[Download](http://get.k8s.io/) Kubernetes -- -Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes) -- -Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) -- -Connect with the community on [Slack](http://slack.k8s.io/) -- -Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates +- [Download](http://get.k8s.io/) Kubernetes +- Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes) +- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) +- Connect with the community on [Slack](http://slack.k8s.io/) +- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates diff --git a/content/en/blog/_posts/2016-12-00-Windows-Server-Support-Kubernetes.md b/content/en/blog/_posts/2016-12-00-Windows-Server-Support-Kubernetes.md index 7f58071940..ba87948d3c 100644 --- a/content/en/blog/_posts/2016-12-00-Windows-Server-Support-Kubernetes.md +++ b/content/en/blog/_posts/2016-12-00-Windows-Server-Support-Kubernetes.md @@ -36,12 +36,11 @@ Most of the Kubernetes constructs, such as Pods, Services, Labels, etc. work wit | What doesn’t work yet? | -- -Pod abstraction is not same due to networking namespaces. Net result is that Windows containers in a single POD cannot communicate over localhost. Linux containers can share networking stack by placing them in the same network namespace. -- -DNS capabilities are not fully implemented -- -UDP is not supported inside a container + +- Pod abstraction is not same due to networking namespaces. Net result is that Windows containers in a single POD cannot communicate over localhost. Linux containers can share networking stack by placing them in the same network namespace. +- DNS capabilities are not fully implemented +- UDP is not supported inside a container + | | When will it be ready for all production workloads (general availability)? diff --git a/content/en/blog/_posts/2017-05-00-Kubernetes-Monitoring-Guide.md b/content/en/blog/_posts/2017-05-00-Kubernetes-Monitoring-Guide.md index 87a26f14b4..c5f1147072 100644 --- a/content/en/blog/_posts/2017-05-00-Kubernetes-Monitoring-Guide.md +++ b/content/en/blog/_posts/2017-05-00-Kubernetes-Monitoring-Guide.md @@ -78,11 +78,7 @@ _--Jean-Mathieu Saponaro, Research & Analytics Engineer, Datadog_ -- -Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes)  -- -Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)  -- -Connect with the community on [Slack](http://slack.k8s.io/) -- -Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates +- Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes)  +- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)  +- Connect with the community on [Slack](http://slack.k8s.io/) +- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates diff --git a/content/en/blog/_posts/2017-05-00-Kubespray-Ansible-Collaborative-Kubernetes-Ops.md b/content/en/blog/_posts/2017-05-00-Kubespray-Ansible-Collaborative-Kubernetes-Ops.md index 8c63574864..c6e4007d9a 100644 --- a/content/en/blog/_posts/2017-05-00-Kubespray-Ansible-Collaborative-Kubernetes-Ops.md +++ b/content/en/blog/_posts/2017-05-00-Kubespray-Ansible-Collaborative-Kubernetes-Ops.md @@ -113,11 +113,7 @@ _-- Rob Hirschfeld, co-founder of RackN and co-chair of the Cluster Ops SIG_ -- -Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes) -- -Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) -- -Connect with the community on [Slack](http://slack.k8s.io/) -- -Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates +- Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes) +- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) +- Connect with the community on [Slack](http://slack.k8s.io/) +- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates diff --git a/content/en/blog/_posts/2017-07-00-Happy-Second-Birthday-Kubernetes.md b/content/en/blog/_posts/2017-07-00-Happy-Second-Birthday-Kubernetes.md index 774bbffad7..7f3c6ebee9 100644 --- a/content/en/blog/_posts/2017-07-00-Happy-Second-Birthday-Kubernetes.md +++ b/content/en/blog/_posts/2017-07-00-Happy-Second-Birthday-Kubernetes.md @@ -26,87 +26,69 @@ Kubernetes has also earned the trust of many [Fortune 500 companies](https://kub July 2016 -- -Kubernauts celebrated its [first anniversary](https://kubernetes.io/blog/2016/07/happy-k8sbday-1) of the Kubernetes 1.0 launch with 20 [#k8sbday](https://twitter.com/search?q=k8sbday&src=typd) parties hosted worldwide -- -Kubernetes [v1.3 release](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/) +- Kubernauts celebrated its [first anniversary](https://kubernetes.io/blog/2016/07/happy-k8sbday-1) of the Kubernetes 1.0 launch with 20 [#k8sbday](https://twitter.com/search?q=k8sbday&src=typd) parties hosted worldwide +- Kubernetes [v1.3 release](https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads/) September 2016 -- -Kubernetes [v1.4 release](https://kubernetes.io/blog/2016/09/kubernetes-1-4-making-it-easy-to-run-on-kuberentes-anywhere/) -- -Launch of [kubeadm](https://kubernetes.io/blog/2016/09/how-we-made-kubernetes-easy-to-install), a tool that makes Kubernetes dramatically easier to install -- -[Pokemon Go](https://www.sdxcentral.com/articles/news/google-dealt-pokemon-go-traffic-50-times-beyond-expectations/2016/09/) - one of the largest installs of Kubernetes ever +- Kubernetes [v1.4 release](https://kubernetes.io/blog/2016/09/kubernetes-1-4-making-it-easy-to-run-on-kuberentes-anywhere/) +- Launch of [kubeadm](https://kubernetes.io/blog/2016/09/how-we-made-kubernetes-easy-to-install), a tool that makes Kubernetes dramatically easier to install +- [Pokemon Go](https://www.sdxcentral.com/articles/news/google-dealt-pokemon-go-traffic-50-times-beyond-expectations/2016/09/) - one of the largest installs of Kubernetes ever October 2016 -- -Introduced [Kubernetes service partners program](https://kubernetes.io/blog/2016/10/kubernetes-service-technology-partners-program) and a redesigned [partners page](https://kubernetes.io/partners/) +- Introduced [Kubernetes service partners program](https://kubernetes.io/blog/2016/10/kubernetes-service-technology-partners-program) and a redesigned [partners page](https://kubernetes.io/partners/) November 2016 -- -CloudNativeCon/KubeCon [Seattle](https://www.cncf.io/blog/2016/11/17/cloudnativeconkubecon-2016-wrap/) -- -Cloud Native Computing Foundation partners with The Linux Foundation to launch a [new Kubernetes certification, training and managed service provider program](https://www.cncf.io/blog/2016/11/08/cncf-partners-linux-foundation-launch-new-kubernetes-certification-training-managed-service-provider-program/) +- CloudNativeCon/KubeCon [Seattle](https://www.cncf.io/blog/2016/11/17/cloudnativeconkubecon-2016-wrap/) +- Cloud Native Computing Foundation partners with The Linux Foundation to launch a [new Kubernetes certification, training and managed service provider program](https://www.cncf.io/blog/2016/11/08/cncf-partners-linux-foundation-launch-new-kubernetes-certification-training-managed-service-provider-program/) December 2016 -- -Kubernetes [v1.5 release](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/) +- Kubernetes [v1.5 release](https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/) January 2017 -- -[Survey](https://www.cncf.io/blog/2017/01/17/container-management-trends-kubernetes-moves-testing-production/) from CloudNativeCon + KubeCon Seattle showcases the maturation of Kubernetes deployment +- [Survey](https://www.cncf.io/blog/2017/01/17/container-management-trends-kubernetes-moves-testing-production/) from CloudNativeCon + KubeCon Seattle showcases the maturation of Kubernetes deployment March 2017 -- -CloudNativeCon/KubeCon [Europe](https://www.cncf.io/blog/2017/04/17/highlights-cloudnativecon-kubecon-europe-2017/) -- -Kubernetes[v1.6 release](https://kubernetes.io/blog/2017/03/kubernetes-1-6-multi-user-multi-workloads-at-scale) +- CloudNativeCon/KubeCon [Europe](https://www.cncf.io/blog/2017/04/17/highlights-cloudnativecon-kubecon-europe-2017/) +- Kubernetes[v1.6 release](https://kubernetes.io/blog/2017/03/kubernetes-1-6-multi-user-multi-workloads-at-scale) April 2017 -- -The [Battery Open Source Software (BOSS) Index](https://www.battery.com/powered/boss-index-tracking-explosive-growth-open-source-software/) lists Kubernetes as #33 in the top 100 popular open-source software projects +- The [Battery Open Source Software (BOSS) Index](https://www.battery.com/powered/boss-index-tracking-explosive-growth-open-source-software/) lists Kubernetes as #33 in the top 100 popular open-source software projects May 2017 -- -[Four Kubernetes projects](https://www.cncf.io/blog/2017/05/04/cncf-brings-kubernetes-coredns-opentracing-prometheus-google-summer-code-2017/) accepted to The [Google Summer of Code](https://developers.google.com/open-source/gsoc/) (GSOC) 2017 program -- -Stutterstock and Kubernetes appear in [The Wall Street Journal](https://blogs.wsj.com/cio/2017/05/26/shutterstock-ceo-says-new-business-plan-hinged-upon-total-overhaul-of-it/): “On average we [Shutterstock] deploy 45 different releases into production a day using that framework. We use Docker, Kubernetes and Jenkins [to build and run containers and automate development,” said CTO Marty Brodbeck on the company’s IT overhaul and adoption of containerization. +- [Four Kubernetes projects](https://www.cncf.io/blog/2017/05/04/cncf-brings-kubernetes-coredns-opentracing-prometheus-google-summer-code-2017/) accepted to The [Google Summer of Code](https://developers.google.com/open-source/gsoc/) (GSOC) 2017 program +- Stutterstock and Kubernetes appear in [The Wall Street Journal](https://blogs.wsj.com/cio/2017/05/26/shutterstock-ceo-says-new-business-plan-hinged-upon-total-overhaul-of-it/): “On average we [Shutterstock] deploy 45 different releases into production a day using that framework. We use Docker, Kubernetes and Jenkins [to build and run containers and automate development,” said CTO Marty Brodbeck on the company’s IT overhaul and adoption of containerization. June 2017 -- -Kubernetes [v1.7 release](https://kubernetes.io/blog/2017/06/kubernetes-1-7-security-hardening-stateful-application-extensibility-updates) -- -[Survey](https://www.cncf.io/blog/2017/06/28/survey-shows-kubernetes-leading-orchestration-platform/) from CloudNativeCon + KubeCon Europe shows Kubernetes leading as the orchestration platform of choice -- -Kubernetes ranked [#4](https://github.com/cncf/velocity) in the [30 highest velocity open source projects](https://www.cncf.io/blog/2017/06/05/30-highest-velocity-open-source-projects/) +- Kubernetes [v1.7 release](https://kubernetes.io/blog/2017/06/kubernetes-1-7-security-hardening-stateful-application-extensibility-updates) +- [Survey](https://www.cncf.io/blog/2017/06/28/survey-shows-kubernetes-leading-orchestration-platform/) from CloudNativeCon + KubeCon Europe shows Kubernetes leading as the orchestration platform of choice +- Kubernetes ranked [#4](https://github.com/cncf/velocity) in the [30 highest velocity open source projects](https://www.cncf.io/blog/2017/06/05/30-highest-velocity-open-source-projects/) ![](https://lh5.googleusercontent.com/tN_M9v5pFyr3uzwAXTliSKofTGz9DUSMotLHWgy2vl2VSsfIfysagv7h5VRkMA5L9TsNBTMX4dWr-V3O1S9d3dw9IctSj4bAyzblXCAe4xjAhnNJEA3vjSq4Cw79SfoRWfnW-zYY) @@ -116,8 +98,7 @@ Figure 2: The 30 highest velocity open source projects. Source: [https://github. July 2017 -- -Kubernauts celebrate the second anniversary of the Kubernetes 1.0 launch with [#k8sbday](https://twitter.com/search?q=k8sbday&src=typd) parties worldwide! +- Kubernauts celebrate the second anniversary of the Kubernetes 1.0 launch with [#k8sbday](https://twitter.com/search?q=k8sbday&src=typd) parties worldwide! diff --git a/content/en/blog/_posts/2017-07-00-How-Watson-Health-Cloud-Deploys.md b/content/en/blog/_posts/2017-07-00-How-Watson-Health-Cloud-Deploys.md index de516c17a8..b931ec336a 100644 --- a/content/en/blog/_posts/2017-07-00-How-Watson-Health-Cloud-Deploys.md +++ b/content/en/blog/_posts/2017-07-00-How-Watson-Health-Cloud-Deploys.md @@ -92,14 +92,10 @@ Usage of UCD in the Process Flow: UCD is used for deployment and the end-to end deployment process is automated here. UCD component process involves the following steps: -- -Download the required artifacts for deployment from the Gitlab. -- -Login to Bluemix and set the KUBECONFIG based on the Kubernetes cluster used for creating the pods. -- -Create the application pod in the cluster using kubectl create command. -- -If needed, run a rolling update to update the existing pod. +- Download the required artifacts for deployment from the Gitlab. +- Login to Bluemix and set the KUBECONFIG based on the Kubernetes cluster used for creating the pods. +- Create the application pod in the cluster using kubectl create command. +- If needed, run a rolling update to update the existing pod. @@ -150,13 +146,8 @@ To expose our services to outside the cluster, we used Ingress. In IBM Cloud Kub -- -Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) -- -Join the community portal for advocates on [K8sPort](http://k8sport.org/) -- -Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates -- -Connect with the community on [Slack](http://slack.k8s.io/) -- -Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes) +- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) +- Join the community portal for advocates on [K8sPort](http://k8sport.org/) +- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates +- Connect with the community on [Slack](http://slack.k8s.io/) +- Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes) diff --git a/content/en/blog/_posts/2017-08-00-Kompose-Helps-Developers-Move-Docker.md b/content/en/blog/_posts/2017-08-00-Kompose-Helps-Developers-Move-Docker.md index b266497707..b94ac8b693 100644 --- a/content/en/blog/_posts/2017-08-00-Kompose-Helps-Developers-Move-Docker.md +++ b/content/en/blog/_posts/2017-08-00-Kompose-Helps-Developers-Move-Docker.md @@ -129,14 +129,10 @@ With our graduation, comes the release of Kompose 1.0.0, here’s what’s new: -- -Docker Compose Version 3: Kompose now supports Docker Compose Version 3. New keys such as ‘deploy’ now convert to their Kubernetes equivalent. -- -Docker Push and Build Support: When you supply a ‘build’ key within your `docker-compose.yaml` file, Kompose will automatically build and push the image to the respective Docker repository for Kubernetes to consume. -- -New Keys: With the addition of version 3 support, new keys such as pid and deploy are supported. For full details on what Kompose supports, view our [conversion document](http://kompose.io/conversion/). -- -Bug Fixes: In every release we fix any bugs related to edge-cases when converting. This release fixes issues relating to converting volumes with ‘./’ in the target name. +- Docker Compose Version 3: Kompose now supports Docker Compose Version 3. New keys such as ‘deploy’ now convert to their Kubernetes equivalent. +- Docker Push and Build Support: When you supply a ‘build’ key within your `docker-compose.yaml` file, Kompose will automatically build and push the image to the respective Docker repository for Kubernetes to consume. +- New Keys: With the addition of version 3 support, new keys such as pid and deploy are supported. For full details on what Kompose supports, view our [conversion document](http://kompose.io/conversion/). +- Bug Fixes: In every release we fix any bugs related to edge-cases when converting. This release fixes issues relating to converting volumes with ‘./’ in the target name. @@ -145,28 +141,18 @@ What’s ahead? As we continue development, we will strive to convert as many Docker Compose keys as possible for all future and current Docker Compose releases, converting each one to their Kubernetes equivalent. All future releases will be backwards-compatible. -- -[Install Kompose](https://github.com/kubernetes/kompose/blob/master/docs/installation.md) -- -[Kompose Quick Start Guide](https://github.com/kubernetes/kompose/blob/master/docs/installation.md) -- -[Kompose Web Site](http://kompose.io/) -- -[Kompose Documentation](https://github.com/kubernetes/kompose/tree/master/docs) +- [Install Kompose](https://github.com/kubernetes/kompose/blob/master/docs/installation.md) +- [Kompose Quick Start Guide](https://github.com/kubernetes/kompose/blob/master/docs/installation.md) +- [Kompose Web Site](http://kompose.io/) +- [Kompose Documentation](https://github.com/kubernetes/kompose/tree/master/docs) --Charlie Drage, Software Engineer, Red Hat -- -Post questions (or answer questions) on[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) -- -Join the community portal for advocates on[K8sPort](http://k8sport.org/) -- -Follow us on Twitter[@Kubernetesio](https://twitter.com/kubernetesio) for latest updates -- -Connect with the community on[Slack](http://slack.k8s.io/) -- -Get involved with the Kubernetes project on[GitHub](https://github.com/kubernetes/kubernetes) -- +- Post questions (or answer questions) on[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) +- Join the community portal for advocates on[K8sPort](http://k8sport.org/) +- Follow us on Twitter[@Kubernetesio](https://twitter.com/kubernetesio) for latest updates +- Connect with the community on[Slack](http://slack.k8s.io/) +- Get involved with the Kubernetes project on[GitHub](https://github.com/kubernetes/kubernetes) diff --git a/content/en/blog/_posts/2017-09-00-Kubernetes-Statefulsets-Daemonsets.md b/content/en/blog/_posts/2017-09-00-Kubernetes-Statefulsets-Daemonsets.md index fe156e00df..67f3e084cc 100644 --- a/content/en/blog/_posts/2017-09-00-Kubernetes-Statefulsets-Daemonsets.md +++ b/content/en/blog/_posts/2017-09-00-Kubernetes-Statefulsets-Daemonsets.md @@ -987,13 +987,8 @@ Rolling updates and roll backs close an important feature gap for DaemonSets and -- -Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) -- -Join the community portal for advocates on [K8sPort](http://k8sport.org/) -- -Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates -- -Connect with the community on [Slack](http://slack.k8s.io/) -- -Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes) +- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) +- Join the community portal for advocates on [K8sPort](http://k8sport.org/) +- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates +- Connect with the community on [Slack](http://slack.k8s.io/) +- Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes) From 6eaacd54cd174ee2459cf2e11ea211966f57a0dd Mon Sep 17 00:00:00 2001 From: Anynou <62398733+Anynou@users.noreply.github.com> Date: Fri, 24 Jul 2020 19:30:22 +0200 Subject: [PATCH 56/86] Add content/es/docs/concepts/configuration/configmap.md content/es/docs/reference/glossary/configmap.md (#22576) * configmap * Apply suggestions from code review Changes accepted Co-authored-by: Rael Garcia * Apply suggestions from code review error solved Co-authored-by: Rael Garcia * Fix broken link to glossary Co-authored-by: Rael Garcia --- .../docs/concepts/configuration/configmap.md | 253 ++++++++++++++++++ .../es/docs/reference/glossary/configmap.md | 18 ++ 2 files changed, 271 insertions(+) create mode 100644 content/es/docs/concepts/configuration/configmap.md create mode 100644 content/es/docs/reference/glossary/configmap.md diff --git a/content/es/docs/concepts/configuration/configmap.md b/content/es/docs/concepts/configuration/configmap.md new file mode 100644 index 0000000000..b607f0b82d --- /dev/null +++ b/content/es/docs/concepts/configuration/configmap.md @@ -0,0 +1,253 @@ +--- +title: ConfigMaps +content_type: concept +weight: 20 +--- + + + +{{< glossary_definition term_id="configmap" prepend="Un configmap es " length="all" >}} + +{{< caution >}} +ConfigMap no proporciona encriptación. +Si los datos que quieres almacenar son confidenciales, utiliza un +{{< glossary_tooltip text="Secret" term_id="secret" >}} en lugar de un ConfigMap, +o utiliza otras herramientas externas para mantener los datos seguros. +{{< /caution >}} + + + + +## Motivo + +Utiliza un ConfigMap para crear una configuración separada del código de la aplicación. + +Por ejemplo, imagina que estás desarrollando una aplicación que puedes correr en +tu propio equipo (para desarrollo) y en el cloud (para mantener tráfico real). +Escribes el código para configurar una variable llamada `DATABASE_HOST`. +En tu equipo configuras la variable con el valor `localhost`. +En el cloud, la configuras con referencia a un kubernetes +{{< glossary_tooltip text="Service" term_id="service" >}} que expone el componente +de la base de datos en tu cluster. + +Esto permite tener una imagen corriendo en un cloud y +tener el mismo código localmente para checkearlo si es necesario. + +## Objeto ConfigMap + +Un ConfigMap es un [objeto](/docs/concepts/overview/working-with-objects/kubernetes-objects/) de la API +que permite almacenar la configuración de otros objetos utilizados. Aunque muchos +objetos de kubernetes que tienen un `spec`, un ConfigMap tiene una sección `data` para +almacenar items, identificados por una clave, y sus valores. + +El nombre del ConfigMap debe ser un +[nombre de subdominio DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido. + +## ConfigMaps y Pods + +Puedes escribir un Pod `spec` y referenciarlo a un ConfigMap y configurar el contenedor(es) +de ese {{< glossary_tooltip text="Pod" term_id="pod" >}} en base a los datos del ConfigMap. El {{< glossary_tooltip text="Pod" term_id="pod" >}} y el ConfigMap deben estar en +el mismo {{< glossary_tooltip text="Namespace" term_id="namespace" >}}. + +Este es un ejemplo de ConfigMap que tiene algunas claves con un valor simple, +y otras claves donde el valor tiene un formato de un fragmento de configuración. + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: game-demo +data: + # property-like keys; each key maps to a simple value + player_initial_lives: "3" + ui_properties_file_name: "user-interface.properties" + # + # file-like keys + game.properties: | + enemy.types=aliens,monsters + player.maximum-lives=5 + user-interface.properties: | + color.good=purple + color.bad=yellow + allow.textmode=true +``` +Hay cuatro maneras diferentes de usar un ConfigMap para configurar +un contenedor dentro de un {{< glossary_tooltip text="Pod" term_id="pod" >}}: + +1. Argumento en la linea de comandos como entrypoint de un contenedor +1. Variable de enorno de un contenedor +1. Como fichero en un volumen de solo lectura, para que lo lea la aplicación +1. Escribir el código para ejecutar dentro de un {{< glossary_tooltip text="Pod" term_id="pod" >}} que utiliza la API para leer el ConfigMap + +Estos diferentes mecanismos permiten utilizar diferentes métodos para modelar +los datos que se van a usar. +Para los primeros tres mecanismos, el +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} utiliza la información +del ConfigMap cuando lanza un contenedor (o varios) en un {{< glossary_tooltip text="Pod" term_id="pod" >}}. + +Para el cuarto método, tienes que escribir el código para leer el ConfigMap y sus datos. +Sin embargo, como estás utilizando la API de kubernetes directamente, la aplicación puede +suscribirse para obtener actualizaciones cuando el ConfigMap cambie, y reaccionar +cuando esto ocurra. Accediendo directamente a la API de kubernetes, esta +técnica también permite acceder al ConfigMap en diferentes namespaces. + +En el siguiente ejemplo el Pod utiliza los valores de `game-demo` para configurar el contenedor: +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: configmap-demo-pod +spec: + containers: + - name: demo + image: game.example/demo-game + env: + # Define the environment variable + - name: PLAYER_INITIAL_LIVES # Notice that the case is different here + # from the key name in the ConfigMap. + valueFrom: + configMapKeyRef: + name: game-demo # The ConfigMap this value comes from. + key: player_initial_lives # The key to fetch. + - name: UI_PROPERTIES_FILE_NAME + valueFrom: + configMapKeyRef: + name: game-demo + key: ui_properties_file_name + volumeMounts: + - name: config + mountPath: "/config" + readOnly: true + volumes: + # You set volumes at the Pod level, then mount them into containers inside that Pod + - name: config + configMap: + # Provide the name of the ConfigMap you want to mount. + name: game-demo + # An array of keys from the ConfigMap to create as files + items: + - key: "game.properties" + path: "game.properties" + - key: "user-interface.properties" + path: "user-interface.properties" +``` + + +Un ConfigMap no diferencia entre las propiedades de una linea individual y +un fichero con múltiples lineas y valores. +Lo importante es como los {{< glossary_tooltip text="Pods" term_id="pod" >}} y otros objetos consumen estos valores. + +Para este ejemplo, definimos un {{< glossary_tooltip text="Volumen" term_id="volume" >}} y lo montamos dentro del contenedor +`demo` como `/config` creando dos ficheros, +`/config/game.properties` y `/config/user-interface.properties`, +aunque haya cuatro claves en el ConfigMap. Esto es debido a que enla definición +del {{< glossary_tooltip text="Pod" term_id="pod" >}} se especifica el array `items` en la sección `volumes`. +Si quieres omitir el array `items` entero, cada clave del ConfigMap se convierte en +un fichero con el mismo nombre que la clave, y tienes 4 ficheros. + +## Usando ConfigMaps + +Los ConfigMaps pueden montarse como volúmenes. También pueden ser utilizados por otras +partes del sistema, sin ser expuestos directamente al {{< glossary_tooltip text="Pod" term_id="pod" >}}. Por ejemplo, +los ConfigMaps pueden contener información para que otros elementos del sistema utilicen +para su configuración. + +{{< note >}} +La manera más común de usar los Configmaps es para configurar +los contenedores que están corriendo en un {{< glossary_tooltip text="Pod" term_id="pod" >}} en el mismo {{< glossary_tooltip text="Namespace" term_id="namespace" >}}. +También se pueden usar por separado. + +Por ejemplo, +quizá encuentres {{< glossary_tooltip text="AddOns" term_id="addons" >}} +u {{< glossary_tooltip text="Operadores" term_id="operator-pattern" >}} que +ajustan su comportamiento en base a un ConfigMap. +{{< /note >}} + +### Usando ConfigMaps como ficheros en un Pod + +Para usar un ConfigMap en un volumen en un {{< glossary_tooltip text="Pod" term_id="pod" >}}: + +1. Crear un ConfigMap o usar uno que exista. Múltiples {{< glossary_tooltip text="Pods" term_id="pod" >}} pueden utilizar el mismo ConfigMap. +1. Modifica la configuración del {{< glossary_tooltip text="Pod" term_id="pod" >}} para añadir el volumen en `.spec.volumes[]`. Pon cualquier nombre al {{< glossary_tooltip text="Volumen" term_id="volume" >}}, y tienes un campo `.spec.volumes[].configMap.name` configurado con referencia al objeto ConfigMap. +1. Añade un `.spec.containers[].volumeMounts[]` a cada contenedor que necesite el ConfigMap. Especifica `.spec.containers[].volumeMounts[].readOnly = true` y `.spec.containers[].volumeMounts[].mountPath` en un directorio sin uso donde quieras que aparezca el ConfigMap. +1. Modifica la imagen o el comando utilizado para que el programa busque los ficheros en el directorio. Cada clave del ConfigMap `data` se convierte en un un fichero en el `mountPath`. + +En este ejemplo, el {{< glossary_tooltip text="Pod" term_id="pod" >}} monta un ConfigMap como un {{< glossary_tooltip text="volumen" term_id="volume" >}}: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + readOnly: true + volumes: + - name: foo + configMap: + name: myconfigmap +``` + +Cada ConfigMap que quieras utilizar debe estar referenciado en `.spec.volumes`. + +Si hay múltiples contenedores en el {{< glossary_tooltip text="Pod" term_id="pod" >}}, cada contenedor tiene su propio +bloque `volumeMounts`, pero solo un `.spec.volumes` es necesario por cada ConfigMap. + +#### ConfigMaps montados son actualizados automáticamente + +Cuando un ConfigMap está siendo utilizado en un {{< glossary_tooltip text="volumen" term_id="volume" >}} y es actualizado, las claves son actualizadas también. +El {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} comprueba si el ConfigMap montado está actualizado cada periodo de sincronización. +Sin embargo, el {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} utiliza su caché local para obtener el valor actual del ConfigMap. +El tipo de caché es configurable usando el campo `ConfigMapAndSecretChangeDetectionStrategy` en el +[KubeletConfiguration struct](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go). +Un ConfigMap puede ser propagado por vista (default), ttl-based, o simplemente redirigiendo +todas las consultas directamente a la API. +Como resultado, el retraso total desde el momento que el ConfigMap es actualizado hasta el momento +que las nuevas claves son proyectadas en el {{< glossary_tooltip text="Pod" term_id="pod" >}} puede ser tan largo como la sincronización del {{< glossary_tooltip text="Pod" term_id="pod" >}} ++ el retraso de propagación de la caché, donde la propagación de la caché depende del tipo de +caché elegido (es igual al retraso de propagación, ttl de la caché, o cero correspondientemente). + +{{< feature-state for_k8s_version="v1.18" state="alpha" >}} + +La característica alpha de kubernetes _Immutable Secrets and ConfigMaps_ provee una opción para configurar +{{< glossary_tooltip text="Secrets" term_id="secret" >}} individuales y ConfigMaps como inmutables. Para los {{< glossary_tooltip text="Clústeres" term_id="cluster" >}} que usan ConfigMaps como extensión +(al menos decenas o cientos de un único ConfigMap montado en {{< glossary_tooltip text="Pods" term_id="pod" >}}), previene cambios en sus +datos con las siguientes ventajas: + +- protección de actualizaciones accidentales (o no deseadas) que pueden causar caídas de aplicaciones +- mejora el rendimiento del {{< glossary_tooltip text="Clúster" term_id="cluster" >}} significativamente reduciendo la carga del {{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}}, +cerrando las vistas para el ConfigMap marcado como inmutable. + +Para usar esta característica, habilita el `ImmutableEmphemeralVolumes` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) y configura +el campo del {{< glossary_tooltip text="Secret" term_id="secret" >}} o ConfigMap `immutable` como `true`. Por ejemplo: +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + ... +data: + ... +immutable: true +``` + +{{< note >}} +Una vez que un ConfigMap o un {{< glossary_tooltip text="Secret" term_id="secret" >}} es marcado como inmutable, _no_ es posible revertir el cambio +ni cambiar el contenido del campo `data`. Solo se puede eliminar y recrear el ConfigMap. +Los {{< glossary_tooltip text="Pods" term_id="pod" >}} existentes mantiene un punto de montaje del ConfigMap eliminado - es recomendable +recrear los {{< glossary_tooltip text="Pods" term_id="pod" >}}. +{{< /note >}} + + +## {{% heading "whatsnext" %}} + + +* Leer sobre [Secrets](/docs/concepts/configuration/secret/). +* Leer [Configure a Pod to Use a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/). +* Leer [The Twelve-Factor App](https://12factor.net/) para entender el motivo de separar + el código de la configuración. diff --git a/content/es/docs/reference/glossary/configmap.md b/content/es/docs/reference/glossary/configmap.md new file mode 100644 index 0000000000..577e24dc1f --- /dev/null +++ b/content/es/docs/reference/glossary/configmap.md @@ -0,0 +1,18 @@ +--- +title: Configmap +id: configmap +date: 2020-07-11 +full_link: /docs/concepts/configuration/configmap/ +short_description: > + Almacena información no sensible. + +aka: +tags: +- workload +--- +Un objeto de la API utilizado para almacenar datos no confidenciales en el formato clave-valor. Los {{< glossary_tooltip text="Pods" term_id="pod" >}} pueden utilizar los ConfigMaps como variables de entorno, argumentos de la linea de comandos o como ficheros de configuración en un {{< glossary_tooltip text="Volumen" term_id="volume" >}}. + +Un ConfigMap te permite desacoplar la configuración de un entorno específico de una imagen de contenedor, así las aplicaciones son fácilmente portables. + + + From d3074e3134ed8fe1b7a31a17e53ece4db64cb2ec Mon Sep 17 00:00:00 2001 From: craigbox Date: Fri, 24 Jul 2020 22:10:51 +0100 Subject: [PATCH 57/86] Add 1.17 release interview blog post --- ...07-27-kubernetes-1-17-release-interview.md | 219 ++++++++++++++++++ 1 file changed, 219 insertions(+) create mode 100644 content/en/blog/_posts/2020-07-27-kubernetes-1-17-release-interview.md diff --git a/content/en/blog/_posts/2020-07-27-kubernetes-1-17-release-interview.md b/content/en/blog/_posts/2020-07-27-kubernetes-1-17-release-interview.md new file mode 100644 index 0000000000..e76d72bb49 --- /dev/null +++ b/content/en/blog/_posts/2020-07-27-kubernetes-1-17-release-interview.md @@ -0,0 +1,219 @@ +--- +layout: blog +title: "Music and math: the Kubernetes 1.17 release interview" +date: 2020-07-27 +--- + +**Author**: Adam Glick (Google) + +Every time the Kubernetes release train stops at the station, we like to ask the release lead to take a moment to reflect on their experience. That takes the form of an interview on the weekly [Kubernetes Podcast from Google](https://kubernetespodcast.com/) that I co-host with [Craig Box](https://twitter.com/craigbox). If you're not familiar with the show, every week we summarise the new in the Cloud Native ecosystem, and have an insightful discussion with an interesting guest from the broader Kubernetes community. + +At the time of the 1.17 release in December, we [talked to release team lead Guinevere Saenger](https://kubernetespodcast.com/episode/083-kubernetes-1.17/). We have [shared](https://kubernetes.io/blog/2018/07/16/how-the-sausage-is-made-the-kubernetes-1.11-release-interview-from-the-kubernetes-podcast/) [the](https://kubernetes.io/blog/2019/05/13/cat-shirts-and-groundhog-day-the-kubernetes-1.14-release-interview/) [transcripts](https://kubernetes.io/blog/2019/12/06/when-youre-in-the-release-team-youre-family-the-kubernetes-1.16-release-interview/) of previous interviews on the Kubernetes blog, and we're very happy to share another today. + +Next week we will bring you up to date with the story of Kubernetes 1.18, as we gear up for the release of 1.19 next month. [Subscribe to the show](https://kubernetespodcast.com/subscribe/) wherever you get your podcasts to make sure you don't miss that chat! + +--- + +**ADAM GLICK: You have a nontraditional background for someone who works as a software engineer. Can you explain that background?** + +GUINEVERE SAENGER: My first career was as a [collaborative pianist](https://en.wikipedia.org/wiki/Collaborative_piano), which is an academic way of saying "piano accompanist". I was a classically trained pianist who spends most of her time onstage, accompanying other people and making them sound great. + +**ADAM GLICK: Is that the piano equivalent of pair-programming?** + +GUINEVERE SAENGER: No one has said it to me like that before, but all sorts of things are starting to make sense in my head right now. I think that's a really great way of putting it. + +**ADAM GLICK: That's a really interesting background, as someone who also has a background with music. What made you decide to get into software development?** + +GUINEVERE SAENGER: I found myself in a life situation where I needed more stable source of income, and teaching music, and performing for various gig opportunities, was really just not cutting it anymore. And I found myself to be working really, really hard with not much to show for it. I had a lot of friends who were software engineers. I live in Seattle. That's sort of a thing that happens to you when you live in Seattle — you get to know a bunch of software engineers, one way or the other. + +The ones I met were all lovely people, and they said, hey, I'm happy to show you how to program in Python. And so I did that for a bit, and then I heard about this program called [Ada Developers Academy](https://adadevelopersacademy.org/). That's a year long coding school, targeted at women and non-binary folks that are looking for a second career in tech. And so I applied for that. + +**CRAIG BOX: What can you tell us about that program?** + +GUINEVERE SAENGER: It's incredibly selective, for starters. It's really popular in Seattle and has gotten quite a good reputation. It took me three tries to get in. They do two classes a year, and so it was a while before I got my response saying 'congratulations, we are happy to welcome you into Cohort 6'. I think what sets Ada Developers Academy apart from other bootcamp style coding programs are three things, I think? The main important one is that if you get in, you pay no tuition. The entire program is funded by company sponsors. + +**CRAIG BOX: Right.** + +GUINEVERE SAENGER: The other thing that really convinced me is that five months of the 11-month program are an industry internship, which means you get both practical experience, mentorship, and potential job leads at the end of it. + +**CRAIG BOX: So very much like a condensed version of the University of Waterloo degree, where you do co-op terms.** + +GUINEVERE SAENGER: Interesting. I didn't know about that. + +**CRAIG BOX: Having lived in Waterloo for a while, I knew a lot of people who did that. But what would you say the advantages were of going through such a condensed schooling process in computer science?** + +GUINEVERE SAENGER: I'm not sure that the condensed process is necessarily an advantage. I think it's a necessity, though. People have to quit their jobs to go do this program. It's not an evening school type of thing. + +**CRAIG BOX: Right.** + +GUINEVERE SAENGER: And your internship is basically a full-time job when you do it. One thing that Ada was really, really good at is giving us practical experience that directly relates to the workplace. We learned how to use Git. We learned how to design websites using [Rails](https://rubyonrails.org/). And we also learned how to collaborate, how to pair-program. We had a weekly retrospective, so we sort of got a soft introduction to workflows at a real workplace. Adding to that, the internship, and I think the overall experience is a little bit more 'practical workplace oriented' and a little bit less academic. + +When you're done with it, you don't have to relearn how to be an adult in a working relationship with other people. You come with a set of previous skills. There are Ada graduates who have previously been campaign lawyers, and veterinarians, and nannies, cooks, all sorts of people. And it turns out these skills tend to translate, and they tend to matter. + +**ADAM GLICK: With your background in music, what do you think that that allows you to bring to software development that could be missing from, say, standard software development training that people go through?** + +GUINEVERE SAENGER: People tend to really connect the dots when I tell them I used to be a musician. Of course, I still consider myself a musician, because you don't really ever stop being a musician. But they say, 'oh, yeah, music and math', and that's just a similar sort of brain. And that makes so much sense. And I think there's a little bit of a point to that. When you learn a piece of music, you have to start recognizing patterns incredibly quickly, almost intuitively. + +And I think that is the main skill that translates into programming-- recognizing patterns, finding the things that work, finding the things that don't work. And for me, especially as a collaborative pianist, it's the communicating with people, the finding out what people really want, where something is going, how to figure out what the general direction is that we want to take, before we start writing the first line of code. + +**CRAIG BOX: In your experience at Ada or with other experiences you've had, have you been able to identify patterns in other backgrounds for people that you'd recommend, 'hey, you're good at music, so therefore you might want to consider doing something like a course in computer science'?** + +GUINEVERE SAENGER: Overall, I think ultimately writing code is just giving a set of instructions to a computer. And we do that in daily life all the time. We give instructions to our kids, we give instructions to our students. We do math, we write textbooks. We give instructions to a room full of people when you're in court as a lawyer. + +Actually, the entrance exam to Ada Developers Academy used to have questions from the [LSAT](https://en.wikipedia.org/wiki/Law_School_Admission_Test) on it to see if you were qualified to join the program. They changed that when I applied, but I think that's a thing that happened at one point. So, overall, I think software engineering is a much more varied field than we give it credit for, and that there are so many ways in which you can apply your so-called other skills and bring them under the umbrella of software engineering. + +**CRAIG BOX: I do think that programming is effectively half art and half science. There's creativity to be applied. There is perhaps one way to solve a problem most efficiently. But there are many different ways that you can choose to express how you compiled something down to that way.** + +GUINEVERE SAENGER: Yeah, I mean, that's definitely true. I think one way that you could probably prove that is that if you write code at work and you're working on something with other people, you can probably tell which one of your co-workers wrote which package, just by the way it's written, or how it is documented, or how it is styled, or any of those things. I really do think that the human character shines through. + +**ADAM GLICK: What got you interested in Kubernetes and open source?** + +GUINEVERE SAENGER: The honest answer is absolutely nothing. Going back to my programming school— and remember that I had to do a five-month internship as part of my training— the way that the internship works is that sponsor companies for the program get interns in according to how much they sponsored a specific cohort of students. + +So at the time, Samsung and SDS offered to host two interns for five months on their [Cloud Native Computing team](https://samsung-cnct.github.io/) and have that be their practical experience. So I go out of a Ruby on Rails full stack web development bootcamp and show up at my internship, and they said, "Welcome to Kubernetes. Try to bring up a cluster." And I said, "Kuber what?" + +**CRAIG BOX: We've all said that on occasion.** + +**ADAM GLICK: Trial by fire, wow.** + +GUINEVERE SAENGER: I will say that that entire team was absolutely wonderful, delightful to work with, incredibly helpful. And I will forever be grateful for all of the help and support that I got in that environment. It was a great place to learn. + +**CRAIG BOX: You now work on GitHub's Kubernetes infrastructure. Obviously, there was GitHub before there was a Kubernetes, so a migration happened. What can you tell us about the transition that GitHub made to running on Kubernetes?** + +GUINEVERE SAENGER: A disclaimer here-- I was not at GitHub at the time that the transition to Kubernetes was made. However, to the best of my knowledge, the decision to transition to Kubernetes was made and people decided, yes, we want to try Kubernetes. We want to use Kubernetes. And mostly, the only decision left was, which one of our applications should we move over to Kubernetes? + +**CRAIG BOX: I thought GitHub was written on Rails, so there was only one application.** + +GUINEVERE SAENGER: [LAUGHING] We have a lot of supplementary stuff under the covers. + +**CRAIG BOX: I'm sure.** + +GUINEVERE SAENGER: But yes, GitHub is written in Rails. It is still written in Rails. And most of the supplementary things are currently running on Kubernetes. We have a fair bit of stuff that currently does not run on Kubernetes. Mainly, that is GitHub Enterprise related things. I would know less about that because I am on the platform team that helps people use the Kubernetes infrastructure. But back to your question, leadership at the time decided that it would be a good idea to start with GitHub the Rails website as the first project to move to Kubernetes. + +**ADAM GLICK: High stakes!** + +GUINEVERE SAENGER: The reason for this was that they decided if they were going to not start big, it really wasn't going to transition ever. It was really not going to happen. So they just decided to go all out, and it was successful, for which I think the lesson would probably be commit early, commit big. + +**CRAIG BOX: Are there any other lessons that you would take away or that you've learned kind of from the transition that the company made, and might be applicable to other people who are looking at moving their companies from a traditional infrastructure to a Kubernetes infrastructure?** + +GUINEVERE SAENGER: I'm not sure this is a lesson specifically, but I was on support recently, and it turned out that, due to unforeseen circumstances and a mix of human error, a bunch of the namespaces on one of our Kubernetes clusters got deleted. + +**ADAM GLICK: Oh, my.** + +GUINEVERE SAENGER: It should not have affected any customers, I should mention, at this point. But all in all, it took a few of us a few hours to almost completely recover from this event. I think that, without Kubernetes, this would not have been possible. + +**CRAIG BOX: Generally, deleting something like that is quite catastrophic. We've seen a number of other vendors suffer large outages when someone's done something to that effect, which is why we get #hugops on Twitter all the time.** + +GUINEVERE SAENGER: People did send me #hugops, that is a thing that happened. But overall, something like this was an interesting stress test and sort of proved that it wasn't nearly as catastrophic as a worst case scenario. + +**CRAIG BOX: GitHub [runs its own data centers](https://githubengineering.com/githubs-metal-cloud/). Kubernetes was largely built for running on the cloud, but a lot of people do choose to run it on their own, bare metal. How do you manage clusters and provisioning of the machinery you run?** + +GUINEVERE SAENGER: When I started, my onboarding project was to deprovision an old cluster, make sure all the traffic got moved to somewhere where it would keep running, provision a new cluster, and then move website traffic onto the new cluster. That was a really exciting onboarding project. At the time, we provisioned bare metal machines using Puppet. We still do that to a degree, but I believe the team that now runs our computing resources actually inserts virtual machines as an extra layer between the bare metal and the Kubernetes notes. + +Again, I was not intrinsically part of that decision, but my understanding is that it just makes for a greater reliability and reproducibility across the board. We've had some interesting hardware dependency issues come up, and the virtual machines basically avoid those. + +**CRAIG BOX: You've been working with Kubernetes for a couple of years now. How did you get involved in the release process?** + +GUINEVERE SAENGER: When I first started in the project, I started at the [special interest group for contributor experience](ttps://github.com/kubernetes/community/tree/master/sig-contributor-experience), namely because one of my co-workers at the time, Aaron Crickenberger, was a big Kubernetes community person. Still is. + +**CRAIG BOX: We've [had him on the show](https://kubernetespodcast.com/episode/046-kubernetes-1.14/) for one of these very release interviews!** + +GUINEVERE SAENGER: In fact, this is true! So Aaron and I actually go way back to Samsung SDS. Anyway, Aaron suggested that I should write up a contribution to the Kubernetes project, and I said, me? And he said, yes, of course. You will be [speaking at KubeCon](https://www.youtube.com/watch?v=TkCDUFR6xqw), so you should probably get started with a PR or something. So I tried, and it was really, really hard. And I [complained about it in a public GitHub issue](https://github.com/kubernetes/community/issues/141), and people said, yeah. Yeah, we know it's hard. Do you want to help with that? + +And so I started getting really involved with the [process for new contributors to get started](https://github.com/kubernetes/community/tree/master/contributors/guide) and have successes, kind of getting a foothold into a project that's as large and varied as Kubernetes. From there on, I began to talk to people, get to know people. The great thing about the Kubernetes community is that there is so much mentorship to go around. + +**ADAM GLICK: Right.** + +GUINEVERE SAENGER: There are so many friendly people willing to help. It's really funny when I talk to other people about it. They say, what do you mean, your coworker? And I said, well, he's really a colleague. He really works for another company. + +**CRAIG BOX: He's sort-of officially a competitor.** + +GUINEVERE SAENGER: Yeah. + +**CRAIG BOX: But we're friends.** + +GUINEVERE SAENGER: But he totally helped me when I didn't know how to get-- patch my borked pull request. So that happened. And eventually, somebody just suggested that I start following along in the release process and shadow someone on their release team role. And that, at the time, was Tim Pepper, who was bug triage lead, and I shadowed him for that role. + +**CRAIG BOX: Another [podcast guest](https://kubernetespodcast.com/episode/010-kubernetes-1.11/) on the interview train.** + +GUINEVERE SAENGER: This is a pattern that probably will make more sense once I explain to you about the shadow process of the release team. + +**ADAM GLICK: Well, let's turn to the Kubernetes release and the release process. First up, what's new in this release of 1.17?** + +GUINEVERE SAENGER: We have only a very few new things. The one that I'm most excited about is that we have moved [IPv4 and IPv6 dual stack](https://github.com/kubernetes/enhancements/issues/563) support to alpha. That is the most major change, and it has been, I think, a year and a half in coming. So this is the very first cut of that feature, and I'm super excited about that. + +**CRAIG BOX: The people who have been promised IPv6 for many, many years and still don't really see it, what will this mean for them?** + +**ADAM GLICK: And most importantly, why did we skip IPv5 support?** + +GUINEVERE SAENGER: I don't know! + +**CRAIG BOX: [Please see the appendix to this podcast](https://softwareengineering.stackexchange.com/questions/185380/ipv4-to-ipv6-where-is-ipv5) for technical explanations.** + +GUINEVERE SAENGER: Having a dual stack configuration obviously enables people to have a much more flexible infrastructure and not have to worry so much about making decisions that will become outdated or that may be over-complicated. This basically means that pods can have dual stack addresses, and nodes can have dual stack addresses. And that basically just makes communication a lot easier. + +**CRAIG BOX: What about features that didn't make it into the release? We had a conversation with Lachie in the [1.16 interview](https://kubernetespodcast.com/episode/072-kubernetes-1.16/), where he mentioned [sidecar containers](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/sidecarcontainers.md). They unfortunately didn't make it into that release. And I see now that they haven't made this one either.** + +GUINEVERE SAENGER: They have not, and we are actually currently undergoing an effort of tracking features that flip multiple releases. + +As a community, we need everyone's help. There are a lot of features that people want. There is also a lot of cleanup that needs to happen. And we have started talking at previous KubeCons repeatedly about problems with maintainer burnout, reviewer burnout, have a hard time finding reviews for your particular contributions, especially if you are not an entrenched member of the community. And it has become very clear that this is an area where the entire community needs to improve. + +So the unfortunate reality is that sometimes life happens, and people are busy. This is an open source project. This is not something that has company mandated OKRs. Particularly during the fourth quarter of the year in North America, but around the world, we have a lot of holidays. It is the end of the year. Kubecon North America happened as well. This makes it often hard to find a reviewer in time or to rally the support that you need for your enhancement proposal. Unfortunately, slipping releases is fairly common and, at this point, expected. We started out with having 42 enhancements and [landed with roughly half of that](https://docs.google.com/spreadsheets/d/1ebKGsYB1TmMnkx86bR2ZDOibm5KWWCs_UjV3Ys71WIs/edit#gid=0). + +**CRAIG BOX: I was going to ask about the truncated schedule due to the fourth quarter of the year, where there are holidays in large parts of the world. Do you find that the Q4 release on the whole is smaller than others, if not for the fact that it's some week shorter?** + +GUINEVERE SAENGER: Q4 releases are shorter by necessity because we are trying to finish the final release of the year before the end of the year holidays. Often, releases are under pressure of KubeCons, during which finding reviewers or even finding the time to do work can be hard to do, if you are attending. And even if you're not attending, your reviewers might be attending. + +It has been brought up last year to make the final release more of a stability release, meaning no new alpha features. In practice, for this release, this is actually quite close to the truth. We have four features graduating to beta and most of our features are graduating to stable. I am hoping to use this as a precedent to change our process to make the final release a stability release from here on out. The timeline fits. The past experience fits this model. + +**ADAM GLICK: On top of all of the release work that was going on, there was also KubeCon that happened. And you were involved in the [contributor summit](https://github.com/kubernetes/community/tree/master/events/2019/11-contributor-summit). How was the summit?** + +GUINEVERE SAENGER: This was the first contributor summit where we had an organized events team with events organizing leads, and handbooks, and processes. And I have heard from multiple people-- this is just word of mouth-- that it was their favorite contributor summit ever. + +**CRAIG BOX: Was someone allocated to hat production? [Everyone had sailor hats](https://flickr.com/photos/143247548@N03/49093218951/).** + +GUINEVERE SAENGER: Yes, the entire event staff had sailor hats with their GitHub handle on them, and it was pretty fantastic. You can probably see me wearing one in some of the pictures from the contributor summit. That literally was something that was pulled out of a box the morning of the contributor summit, and no one had any idea. But at first, I was a little skeptical, but then I put it on and looked at myself in the mirror. And I was like, yes. Yes, this is accurate. We should all wear these. + +**ADAM GLICK: Did getting everyone together for the contributor summit help with the release process?** + +GUINEVERE SAENGER: It did not. It did quite the opposite, really. Well, that's too strong. + +**ADAM GLICK: Is that just a matter of the time taken up?** + +GUINEVERE SAENGER: It's just a completely different focus. Honestly, it helped getting to know people face-to-face that I had currently only interacted with on video. But we did have to cancel the release team meeting the day of the contributor summit because there was kind of no sense in having it happen. We moved it to the Tuesday, I believe. + +**CRAIG BOX: The role of the release team leader has been described as servant leadership. Do you consider the position proactive or reactive?** + +GUINEVERE SAENGER: Honestly, I think that depends on who's the release team lead, right? There are some people who are very watchful and look for trends, trying to detect problems before they happen. I tend to be in that camp, but I also know that sometimes it's not possible to predict things. There will be last minute bugs sometimes, sometimes not. If there is a last minute bug, you have to be ready to be on top of that. So for me, the approach has been I want to make sure that I have my priorities in order and also that I have backups in case I can't be available. + +**ADAM GLICK: What was the most interesting part of the release process for you?** + +GUINEVERE SAENGER: A release lead has to have served in other roles on the release team prior to being release team lead. To me, it was very interesting to see what other roles were responsible for, ones that I hadn't seen from the inside before, such as docs, CI signal. I had helped out with CI signal for a bit, but I want to give a big shout out to CI signal lead, Alena Varkockova, who was able to communicate effectively and kindly with everyone who was running into broken tests, failing tests. And she was very effective in getting all of our tests up and running. + +So that was actually really cool to see. And yeah, just getting to see more of the workings of the team, for me, it was exciting. The other big exciting thing, of course, was to see all the changes that were going in and all the efforts that were being made. + +**CRAIG BOX: The release lead for 1.18 has just been announced as Jorge Alarcon. What are you going to put in the proverbial envelope as advice for him?** + +GUINEVERE SAENGER: I would want Jorge to be really on top of making sure that every Special Interest Group that enters a change, that has an enhancement for 1.18, is on top of the timelines and is responsive. Communication tends to be a problem. And I had hinted at this earlier, but some enhancements slipped simply because there wasn't enough reviewer bandwidth. + +Greater communication of timelines and just giving people more time and space to be able to get in their changes, or at least, seemingly give them more time and space by sending early warnings, is going to be helpful. Of course, he's going to have a slightly longer release, too, than I did. This might be related to a unique Q4 challenge. Overall, I would encourage him to take more breaks, to rely more on his release shadows, and split out the work in a fashion that allows everyone to have a turn and everyone to have a break as well. + +**ADAM GLICK: What would your advice be to someone who is hearing your experience and is inspired to get involved with the Kubernetes release or contributer process?** + +GUINEVERE SAENGER: Those are two separate questions. So let me tackle the Kubernetes release question first. Kubernetes SIG Release has, in my opinion, a really excellent onboarding program for new members. We have what is called the [Release Team Shadow Program](https://github.com/kubernetes/sig-release/blob/master/release-team/shadows.md). We also have the Release Engineering Shadow Program, or the Release Management Shadow Program. Those are two separate subprojects within SIG Release. And each subproject has a team of roles, and each role can have two to four shadows that are basically people who are part of that role team, and they are learning that role as they are doing it. + +So for example, if I am the lead for bug triage on the release team, I may have two, three or four people that I closely work with on the bug triage tasks. These people are my shadows. And once they have served one release cycle as a shadow, they are now eligible to be lead in that role. We have an application form for this process, and it should probably be going up in January. It usually happens the first week of the release once all the release leads are put together. + +**CRAIG BOX: Do you think being a member of the release team is something that is a good first contribution to the Kubernetes project overall?** + +GUINEVERE SAENGER: It depends on what your goals are, right? I believe so. I believe, for me, personally, it has been incredibly helpful looking into corners of the project that I don't know very much about at all, like API machinery, storage. It's been really exciting to look over all the areas of code that I normally never touch. + +It depends on what you want to get out of it. In general, I think that being a release team shadow is a really, really great on-ramp to being a part of the community because it has a paved path solution to contributing. All you have to do is show up to the meetings, ask questions of your lead, who is required to answer those questions. + +And you also do real work. You really help, you really contribute. If you go across the issues and pull requests in the repo, you will see, 'Hi, my name is so-and-so. I am shadowing the CI signal lead for the current release. Can you help me out here?' And that's a valuable contribution, and it introduces people to others. And then people will recognize your name. They'll see a pull request by you, and they're like oh yeah, I know this person. They're legit. + +--- + +_[Guinevere Saenger](https://twitter.com/guincodes) is a software engineer for GitHub and served as the Kubernetes 1.17 release team lead._ + +_You can find the [Kubernetes Podcast from Google](http://www.kubernetespodcast.com/) at [@KubernetesPod](https://twitter.com/KubernetesPod) on Twitter, and you can [subscribe](https://kubernetespodcast.com/subscribe/) so you never miss an episode._ From a8b09e6b1bc54d58e34bc5620d84ba6538ebf3ed Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sat, 25 Jul 2020 16:50:52 +0800 Subject: [PATCH 58/86] [zh] Drop federation related contents These contents are removed from English site. --- .../concepts/cluster-administration/_index.md | 136 ++++- .../cluster-administration-overview.md | 145 ----- .../cluster-administration/federation.md | 118 ---- .../connect-applications-service.md | 16 +- .../concepts/services-networking/ingress.md | 2 - content/zh/docs/reference/_index.md | 72 +-- content/zh/docs/reference/tools.md | 9 - .../dns-debugging-resolution.md | 29 +- content/zh/docs/tasks/federation/_index.md | 4 - .../administer-federation/_index.md | 4 - .../administer-federation/configmap.md | 148 ----- .../administer-federation/daemonset.md | 136 ----- .../administer-federation/deployment.md | 177 ------ .../administer-federation/events.md | 87 --- .../federation/administer-federation/job.md | 191 ------- .../administer-federation/namespaces.md | 158 ------ .../administer-federation/replicaset.md | 220 -------- .../administer-federation/secret.md | 164 ------ .../federation-service-discovery.md | 509 ------------------ .../set-up-coredns-provider-federation.md | 254 --------- .../set-up-placement-policies-federation.md | 331 ------------ 21 files changed, 170 insertions(+), 2740 deletions(-) delete mode 100644 content/zh/docs/concepts/cluster-administration/cluster-administration-overview.md delete mode 100644 content/zh/docs/concepts/cluster-administration/federation.md delete mode 100755 content/zh/docs/tasks/federation/_index.md delete mode 100644 content/zh/docs/tasks/federation/administer-federation/_index.md delete mode 100644 content/zh/docs/tasks/federation/administer-federation/configmap.md delete mode 100644 content/zh/docs/tasks/federation/administer-federation/daemonset.md delete mode 100644 content/zh/docs/tasks/federation/administer-federation/deployment.md delete mode 100644 content/zh/docs/tasks/federation/administer-federation/events.md delete mode 100644 content/zh/docs/tasks/federation/administer-federation/job.md delete mode 100644 content/zh/docs/tasks/federation/administer-federation/namespaces.md delete mode 100644 content/zh/docs/tasks/federation/administer-federation/replicaset.md delete mode 100644 content/zh/docs/tasks/federation/administer-federation/secret.md delete mode 100644 content/zh/docs/tasks/federation/federation-service-discovery.md delete mode 100644 content/zh/docs/tasks/federation/set-up-coredns-provider-federation.md delete mode 100644 content/zh/docs/tasks/federation/set-up-placement-policies-federation.md diff --git a/content/zh/docs/concepts/cluster-administration/_index.md b/content/zh/docs/concepts/cluster-administration/_index.md index f901bc55f1..a494f4f42b 100644 --- a/content/zh/docs/concepts/cluster-administration/_index.md +++ b/content/zh/docs/concepts/cluster-administration/_index.md @@ -1,4 +1,136 @@ --- -title: "计算、存储和网络扩展" -weight: 30 +title: "集群管理" +weight: 100 +content_type: concept +description: > + 关于创建和管理 Kubernetes 集群的底层细节。 +no_list: true --- + + + + + +集群管理概述面向任何创建和管理 Kubernetes 集群的读者人群。 +我们假设你对一些核心的 Kubernetes [概念](/zh/docs/concepts/)大概了解。 + + + + +## 规划集群 + +查阅[安装](/zh/docs/setup/)中的指导，获取如何规划、建立以及配置 Kubernetes 集群的示例。本文所列的文章称为*发行版* 。 + +{{< note >}} +并非所有发行版都是被积极维护的。 +请选择使用最近 Kubernetes 版本测试过的发行版。 +{{< /note >}} + +在选择一个指南前，有一些因素需要考虑： + + +- 你是打算在你的计算机上尝试 Kubernetes，还是要构建一个高可用的多节点集群？请选择最适合你需求的发行版。 +- 您正在使用类似 [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) 这样的**被托管的 Kubernetes 集群**, 还是**管理您自己的集群**？ +- 你的集群是在**本地**还是**云（IaaS）**上？Kubernetes 不能直接支持混合集群。作为代替，你可以建立多个集群。 +- **如果你在本地配置 Kubernetes**，需要考虑哪种[网络模型](/zh/docs/concepts/cluster-administration/networking/)最适合。 +- 你的 Kubernetes 在**裸金属硬件**上还是**虚拟机（VMs）**上运行？ +- 你**只想运行一个集群**，还是打算**参与开发 Kubernetes 项目代码**？如果是后者，请选择一个处于开发状态的发行版。某些发行版只提供二进制发布版，但提供更多的选择。 +- 让你自己熟悉运行一个集群所需的[组件](/zh/docs/admin/cluster-components)。 + + +## 管理集群 + +* [管理集群](/zh/docs/tasks/administer-cluster/cluster-management/)叙述了和集群生命周期相关的几个主题： +创建新集群、升级集群的控制节点和工作节点、执行节点维护（例如内核升级）以及升级运行中的集群的 Kubernetes API 版本。 + +* 学习如何[管理节点](/zh/docs/concepts/nodes/node/)。 + +* 学习如何设定和管理集群共享的[资源配额](/zh/docs/concepts/policy/resource-quotas/) 。 + + +## 保护集群 + +* [证书](/zh/docs/concepts/cluster-administration/certificates/)节描述了使用不同的工具链生成证书的步骤。 +* [Kubernetes 容器环境](/zh/docs/concepts/containers/container-environment-variables/)描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。 +* [控制到 Kubernetes API 的访问](/zh/docs/reference/access-authn-authz/controlling-access/)描述了如何为用户和 service accounts 建立权限许可。 +* [认证](/zh/docs/reference/access-authn-authz/authentication/)节阐述了 Kubernetes 中的身份认证功能，包括许多认证选项。 +* [鉴权](/zh/docs/admin/authorization/)从认证中分离出来，用于控制如何处理 HTTP 请求。 +* [使用准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers) 阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。 +* [在 Kubernetes 集群中使用 Sysctls](/zh/docs/concepts/cluster-administration/sysctl-cluster/) 描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。 +* [审计](/zh/docs/tasks/debug-application-cluster/audit/)描述了如何与 Kubernetes 的审计日志交互。 + + +### 保护 kubelet + +* [主控节点通信](/zh/docs/concepts/cluster-administration/master-node-communication/) +* [TLS 引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) +* [Kubelet 认证/授权](/zh/docs/admin/kubelet-authentication-authorization/) + + + +## 可选集群服务 + +* [DNS 集成](/zh/docs/concepts/services-networking/dns-pod-service/)描述了如何将一个 DNS 名解析到一个 Kubernetes service。 +* [记录和监控集群活动](/zh/docs/concepts/cluster-administration/logging/)阐述了 Kubernetes 的日志如何工作以及怎样实现。 + diff --git a/content/zh/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/zh/docs/concepts/cluster-administration/cluster-administration-overview.md deleted file mode 100644 index 365ed8f7ac..0000000000 --- a/content/zh/docs/concepts/cluster-administration/cluster-administration-overview.md +++ /dev/null @@ -1,145 +0,0 @@ ---- -title: 集群管理概述 -content_type: concept -weight: 10 ---- - - - - - -集群管理概述面向任何创建和管理 Kubernetes 集群的读者人群。 -我们假设你对[用户指南](/docs/user-guide/)中的概念大概了解。 - - - - - - -## 规划集群 - -查阅[安装](/docs/setup/)中的指导，获取如何规划、建立以及配置 Kubernetes 集群的示例。本文所列的文章称为*发行版* 。 - -在选择一个指南前，有一些因素需要考虑： - - - - - 你是打算在你的电脑上尝试 Kubernetes，还是要构建一个高可用的多节点集群？请选择最适合你需求的发行版。 - - **如果你正在设计一个高可用集群**，请了解[在多个 zones 中配置集群](/docs/concepts/cluster-administration/federation/)。 - - 您正在使用类似 [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) 这样的 **被托管的Kubernetes集群**, 还是 **管理您自己的集群**？ - - 你的集群是在 **本地** 还是 **云（IaaS）** 上？Kubernetes 不能直接支持混合集群。作为代替，你可以建立多个集群。 - - **如果你在本地配置 Kubernetes**，需要考虑哪种[网络模型](/docs/concepts/cluster-administration/networking/)最适合。 - - 你的 Kubernetes 在 **裸金属硬件** 还是 **虚拟机（VMs）** 上运行？ - - 你 **只想运行一个集群**，还是打算 **活动开发 Kubernetes 项目代码**？如果是后者，请选择一个活动开发的发行版。某些发行版只提供二进制发布版，但提供更多的选择。 - - 让你自己熟悉运行一个集群所需的[组件](/docs/admin/cluster-components)。 - - - -请注意：不是所有的发行版都被积极维护着。请选择测试过最近版本的 Kubernetes 的发行版。 - - - -## 管理集群 - -* [管理集群](/docs/concepts/cluster-administration/cluster-management/)叙述了和集群生命周期相关的几个主题：创建一个新集群、升级集群的 master 和 worker 节点、执行节点维护（例如内核升级）以及升级活动集群的 Kubernetes API 版本。 - -* 学习如何[管理节点](/docs/concepts/nodes/node/)。 - -* 学习如何设定和管理集群共享的[资源配额](/docs/concepts/policy/resource-quotas/) 。 - - - -## 集群安全 - -* [Certificates](/docs/concepts/cluster-administration/certificates/) 描述了使用不同的工具链生成证书的步骤。 - -* [Kubernetes 容器环境](/docs/concepts/containers/container-environment-variables/)描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。 - -* [控制到 Kubernetes API 的访问](/docs/reference/access-authn-authz/controlling-access/)描述了如何为用户和 service accounts 建立权限许可。 - -* [用户认证](/docs/reference/access-authn-authz/authentication/)阐述了 Kubernetes 中的认证功能，包括许多认证选项。 - -* [授权](/docs/admin/authorization)从认证中分离出来，用于控制如何处理 HTTP 请求。 - -* [使用 Admission Controllers](/docs/admin/admission-controllers) 阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。 - -* [在 Kubernetes Cluster 中使用 Sysctls](/docs/concepts/cluster-administration/sysctl-cluster/) 描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。 - -* [审计](/docs/tasks/debug-application-cluster/audit/)描述了如何与 Kubernetes 的审计日志交互。 - - - -### 保护 kubelet - - * [Master 节点通信](/docs/concepts/cluster-administration/master-node-communication/) - * [TLS 引导](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) - * [Kubelet 认证/授权](/docs/admin/kubelet-authentication-authorization/) - - - -## 可选集群服务 - -* [DNS 与 SkyDNS 集成](/docs/concepts/services-networking/dns-pod-service/)描述了如何将一个 DNS 名解析到一个 Kubernetes service。 - -* [记录和监控集群活动](/docs/concepts/cluster-administration/logging/)阐述了 Kubernetes 的日志如何工作以及怎样实现。 - - diff --git a/content/zh/docs/concepts/cluster-administration/federation.md b/content/zh/docs/concepts/cluster-administration/federation.md deleted file mode 100644 index e0f86e8823..0000000000 --- a/content/zh/docs/concepts/cluster-administration/federation.md +++ /dev/null @@ -1,118 +0,0 @@ ---- -title: 联邦 -content_type: concept ---- - - -本页面阐明了为何以及如何使用联邦创建Kubernetes集群。 - - - -## 为何使用联邦 - -联邦可以使多个集群的管理简单化。它提供了两个主要构件模块： - - * 跨集群同步资源：联邦能够让资源在多个集群中同步。例如，你可以确保在多个集群中存在同样的部署。 - * 跨集群发现：联邦能够在所有集群的后端自动配置DNS服务和负载均衡。例如，通过多个集群的后端，你可以确保全局的VIP或DNS记录可用。 - -联邦技术的其他应用场景： - -* 高可用性：通过跨集群分摊负载，自动配置DNS服务和负载均衡，联邦将集群失败所带来的影响降到最低。 -* 避免供应商锁定：跨集群使迁移应用程序变得更容易，联邦服务避免了供应商锁定。 - - -只有在多个集群的场景下联邦服务才是有帮助的。这里列出了一些你会使用多个集群的原因： - -* 降低延迟：在多个区域含有集群，可使用离用户最近的集群来服务用户，从而最大限度降低延迟。 -* 故障隔离：对于故障隔离，也许有多个小的集群比有一个大的集群要更好一些（例如：一个云供应商的不同可用域里有多个集群）。详细信息请参阅[多集群指南](/docs/admin/multi-cluster)。 -* 可伸缩性：对于单个kubernetes集群是有伸缩性限制的（但对于大多数用户来说并非如此。更多细节参考[Kubernetes扩展和性能目标](https://git.k8s.io/community/sig-scalability/goals.md)）。 -* [混合云](#混合云的能力)：可以有多个集群，它们分别拥有不同的云供应商或者本地数据中心。 - -### 注意事项 - -虽然联邦有很多吸引人的场景，但这里还是有一些需要关注的事项： - -* 增加网络的带宽和损耗：联邦控制面会监控所有的集群，来确保集群的当前状态与预期一致。那么当这些集群运行在一个或者多个云提供者的不同区域中，则会带来重大的网络损耗。 -* 降低集群的隔离：当联邦控制面中存在一个故障时，会影响所有的集群。把联邦控制面的逻辑降到最小可以缓解这个问题。 无论何时，它都是kubernetes集群里控制面的代表。设计和实现也使其变得更安全,避免多集群运行中断。 -* 完整性：联邦项目相对较新，还不是很成熟。不是所有资源都可用，且很多资源才刚刚开始。[Issue 38893](https://github.com/kubernetes/kubernetes/issues/38893) 列举了一些团队正忙于解决的系统已知问题。 - -### 混合云的能力 - -Kubernetes集群里的联邦包括运行在不同云供应商上的集群（例如，谷歌云、亚马逊），和本地部署的集群（例如，OpenStack）。只需在适当的云供应商和/或位置创建所需的所有集群，并将每个集群的API endpoint和凭据注册到您的联邦API服务中（详情参考[联邦管理指南](/docs/admin/federation/)）。 - -在此之后，您的[API资源](#api资源)就可以跨越不同的集群和云供应商。 - -## 建立联邦 - -若要能联合多个集群，首先需要建立一个联邦控制面。参照[安装指南](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) 建立联邦控制面。 - -## API资源 - -控制面建立完成后，就可以开始创建联邦API资源了。 -以下指南详细介绍了一些资源： - -* [Cluster](/docs/tasks/administer-federation/cluster/) -* [ConfigMap](/docs/tasks/administer-federation/configmap/) -* [DaemonSets](/docs/tasks/administer-federation/daemonset/) -* [Deployment](/docs/tasks/administer-federation/deployment/) -* [Events](/docs/tasks/administer-federation/events/) -* [Ingress](/docs/tasks/administer-federation/ingress/) -* [Namespaces](/docs/tasks/administer-federation/namespaces/) -* [ReplicaSets](/docs/tasks/administer-federation/replicaset/) -* [Secrets](/docs/tasks/administer-federation/secret/) -* [Services](/docs/concepts/cluster-administration/federation-service-discovery/) - -[API参考文档](/docs/reference/federation/)列举了联邦API服务支持的所有资源。 - -## 级联删除 - -Kubernetes1.6版本支持联邦资源级联删除。使用级联删除，即当删除联邦控制面的一个资源时，也删除了所有底层集群中的相应资源。 - -当使用REST API时，级联删除功能不是默认开启的。若使用REST API从联邦控制面删除一个资源时，要开启级联删除功能，即需配置选项 `DeleteOptions.orphanDependents=false`。使用`kubectl delete`使级联删除功能默认开启。使用`kubectl delete --cascade=false`禁用级联删除功能。 - -注意：Kubernetes1.5版本开始支持联邦资源子集的级联删除。 - -## 单个集群的范围 - -对于IaaS供应商如谷歌计算引擎或亚马逊网络服务，一个虚拟机存在于一个[域](https://cloud.google.com/compute/docs/zones)或[可用域](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)中。 -我们建议一个Kubernetes集群里的所有虚机应该在相同的可用域里，因为： - - - 与单一的全局Kubernetes集群对比，该方式有较少的单点故障。 - - 与跨可用域的集群对比，该方式更容易推断单区域集群的可用性属性。 - - 当Kubernetes开发者设计一个系统(例如，对延迟、带宽或相关故障进行假设)，他们也会假设所有的机器都在一个单一的数据中心，或者以其他方式紧密相连。 - -每个可用区域里包含多个集群当然是可以的，但是总的来说我们认为集群数越少越好。 -偏爱较少集群数的原因是： - - - 在某些情况下，在一个集群里有更多的节点，可以改进Pods的装箱问题（更少的资源碎片）。 - - 减少操作开销（尽管随着OPS工具和流程的成熟而降低了这块的优势）。 - - 为每个集群的固定资源花费降低开销，例如，使用apiserver的虚拟机（但是在全体集群开销中，中小型集群的开销占比要小的多）。 - -多集群的原因包括： - - - 严格的安全性策略要求隔离一类工作与另一类工作（但是，请参见下面的集群分割）。 - - 测试集群或其他集群软件直至最优的新Kubernetes版本发布。 - -## 选择合适的集群数 - -Kubernetes集群数量选择也许是一个相对静止的选择，因为对其重新审核的情况很少。相比之下，一个集群中的节点数和一个服务中的pods数可能会根据负载和增长频繁变化。 - -选择集群的数量，首先，需要决定哪些区域对于将要运行在Kubernetes上的服务，可以有足够的时间到达所有的终端用户（如果使用内容分发网络，则不需要考虑CDN-hosted内容的延迟需求）。法律问题也可能影响这一点。例如，拥有全球客户群的公司可能会对于在美国、欧盟、亚太和南非地区拥有集群起到决定权。使用`R`代表区域的数量。 - -其次，决定有多少集群在同一时间不可用，而一些仍然可用。使用`U`代表不可用的数量。如果不确定，最好选择1。 - -如果允许负载均衡在集群故障发生时将通信引导到任何区域，那么至少需要较大的`R`或`U + 1`集群。若非如此（例如，若要在集群故障发生时确保所有用户的低延迟），则需要`R * (U + 1)`集群(在每一个`R`区域里都有`U + 1`)。在任何情况下，尝试将每个集群放在不同的区域中。 - -最后，如果你的集群需求超过一个Kubernetes集群推荐的最大节点数，那么你可能需要更多的集群。Kubernetes1.3版本支持多达1000个节点的集群规模。 - - - -## {{% heading "whatsnext" %}} - -* 进一步学习[联邦提案](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)。 -* 集群联邦参考该[配置指导](/docs/tutorials/federation/set-up-cluster-federation-kubefed/)。 -* 查看[Kubecon2016浅谈联邦](https://www.youtube.com/watch?v=pq9lbkmxpS8) - - - - diff --git a/content/zh/docs/concepts/services-networking/connect-applications-service.md b/content/zh/docs/concepts/services-networking/connect-applications-service.md index d49d61294b..a4985549c1 100644 --- a/content/zh/docs/concepts/services-networking/connect-applications-service.md +++ b/content/zh/docs/concepts/services-networking/connect-applications-service.md @@ -602,15 +602,11 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el ## {{% heading "whatsnext" %}} - - -Kubernetes 也支持联合 Service，能够跨多个集群和云提供商，为 Service 提供逐步增强的可用性、更优的容错、更好的可伸缩性。 -查看 [联合 Service 用户指南](/docs/concepts/cluster-administration/federation-service-discovery/) 获取更进一步信息。 - +* 进一步了解如何[使用 Service 访问集群中的应用](/zh/docs/tasks/access-application-cluster/service-access-application-cluster/) +* 进一步了解如何[使用 Service 将前端连接到后端](/zh/docs/tasks/access-application-cluster/connecting-frontend-backend/) +* 进一步了解如何[创建外部负载均衡器](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/) diff --git a/content/zh/docs/concepts/services-networking/ingress.md b/content/zh/docs/concepts/services-networking/ingress.md index 24b2acd5dc..502abfcbc4 100644 --- a/content/zh/docs/concepts/services-networking/ingress.md +++ b/content/zh/docs/concepts/services-networking/ingress.md @@ -4,13 +4,11 @@ content_type: concept weight: 40 --- diff --git a/content/zh/docs/reference/_index.md b/content/zh/docs/reference/_index.md index 2c49c689d1..64091816a7 100644 --- a/content/zh/docs/reference/_index.md +++ b/content/zh/docs/reference/_index.md @@ -7,7 +7,6 @@ content_type: concept --- @@ -25,20 +23,8 @@ This section of the Kubernetes documentation contains references. --> 这是 Kubernetes 文档的参考部分。 - - -## API 参考 - -* [Kubernetes API 概述](/docs/reference/using-api/api-overview/) - Kubernetes API 概述。 -* Kubernetes API 版本 - * [1.17](/docs/reference/generated/kubernetes-api/v1.17/) - * [1.16](/docs/reference/generated/kubernetes-api/v1.16/) - * [1.15](/docs/reference/generated/kubernetes-api/v1.15/) - * [1.14](/docs/reference/generated/kubernetes-api/v1.14/) - * [1.13](/docs/reference/generated/kubernetes-api/v1.13/) - +## API 参考 -## API 客户端库 - -如果您需要通过编程语言调用 Kubernetes API，您可以使用 -[客户端库](/docs/reference/using-api/client-libraries/)。以下是官方支持的客户端库： - -- [Kubernetes Go 语言客户端库](https://github.com/kubernetes/client-go/) -- [Kubernetes Python 语言客户端库](https://github.com/kubernetes-client/python) -- [Kubernetes Java 语言客户端库](https://github.com/kubernetes-client/java) -- [Kubernetes JavaScript 语言客户端库](https://github.com/kubernetes-client/javascript) +* [Kubernetes API 概述](/docs/reference/using-api/api-overview/) - Kubernetes API 概述。 +* Kubernetes API 版本 + * [1.17](/docs/reference/generated/kubernetes-api/v1.17/) + * [1.16](/docs/reference/generated/kubernetes-api/v1.16/) + * [1.15](/docs/reference/generated/kubernetes-api/v1.15/) + * [1.14](/docs/reference/generated/kubernetes-api/v1.14/) + * [1.13](/docs/reference/generated/kubernetes-api/v1.13/) +## API 客户端库 -## CLI 参考 +如果您需要通过编程语言调用 Kubernetes API，您可以使用 +[客户端库](/docs/reference/using-api/client-libraries/)。以下是官方支持的客户端库： -* [kubectl](/docs/user-guide/kubectl-overview) - 主要的 CLI 工具，用于运行命令和管理 Kubernetes 集群。 - * [JSONPath](/docs/user-guide/jsonpath/) - 通过 kubectl 使用 [JSONPath 表达式](http://goessner.net/articles/JsonPath/) 的语法指南。 -* [kubeadm](/docs/admin/kubeadm/) - 此 CLI 工具可轻松配置安全的 Kubernetes 集群。 -* [kubefed](/docs/admin/kubefed/) - 此 CLI 工具可帮助您管理集群联邦。 +- [Kubernetes Go 语言客户端库](https://github.com/kubernetes/client-go/) +- [Kubernetes Python 语言客户端库](https://github.com/kubernetes-client/python) +- [Kubernetes Java 语言客户端库](https://github.com/kubernetes-client/java) +- [Kubernetes JavaScript 语言客户端库](https://github.com/kubernetes-client/javascript) +## CLI 参考 -## 配置参考 - -* [kubelet](/docs/admin/kubelet/) - 在每个节点上运行的主 *节点代理* 。kubelet 采用一组 PodSpecs 并确保所描述的容器健康地运行。 -* [kube-apiserver](/docs/admin/kube-apiserver/) - REST API，用于验证和配置 API 对象（如 pod，服务，副本控制器）的数据。 -* [kube-controller-manager](/docs/admin/kube-controller-manager/) - 一个守护进程，它嵌入到了 Kubernetes 的附带的核心控制循环。 -* [kube-proxy](/docs/admin/kube-proxy/) - 可以跨一组后端进行简单的 TCP/UDP 流转发或循环 TCP/UDP 转发。 -* [kube-scheduler](/docs/admin/kube-scheduler/) - 一个调度程序，用于管理可用性、性能和容量。 -* [federation-apiserver](/docs/admin/federation-apiserver/) - 联邦集群的 API 服务器。 -* [federation-controller-manager](/docs/admin/federation-controller-manager/) - 一个守护进程，它嵌入到了 Kubernetes 联邦的附带的核心控制循环。 +* [kubectl](/docs/user-guide/kubectl-overview) - 主要的 CLI 工具，用于运行命令和管理 Kubernetes 集群。 + * [JSONPath](/docs/user-guide/jsonpath/) - 通过 kubectl 使用 [JSONPath 表达式](http://goessner.net/articles/JsonPath/) 的语法指南。 +* [kubeadm](/docs/admin/kubeadm/) - 此 CLI 工具可轻松配置安全的 Kubernetes 集群。 +* [kubefed](/docs/admin/kubefed/) - 此 CLI 工具可帮助您管理集群联邦。 +## 配置参考 -## 设计文档 - -Kubernetes 功能的设计文档归档，不妨考虑从 [Kubernetes 架构](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) 和 [Kubernetes 设计概述](https://git.k8s.io/community/contributors/design-proposals)开始阅读。 +* [kubelet](/docs/admin/kubelet/) - 在每个节点上运行的主 *节点代理* 。kubelet 采用一组 PodSpecs 并确保所描述的容器健康地运行。 +* [kube-apiserver](/docs/admin/kube-apiserver/) - REST API，用于验证和配置 API 对象（如 pod，服务，副本控制器）的数据。 +* [kube-controller-manager](/docs/admin/kube-controller-manager/) - 一个守护进程，它嵌入到了 Kubernetes 的附带的核心控制循环。 +* [kube-proxy](/docs/admin/kube-proxy/) - 可以跨一组后端进行简单的 TCP/UDP 流转发或循环 TCP/UDP 转发。 +* [kube-scheduler](/docs/admin/kube-scheduler/) - 一个调度程序，用于管理可用性、性能和容量。 +## 设计文档 + +Kubernetes 功能的设计文档归档，不妨考虑从 [Kubernetes 架构](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) 和 [Kubernetes 设计概述](https://git.k8s.io/community/contributors/design-proposals)开始阅读。 diff --git a/content/zh/docs/reference/tools.md b/content/zh/docs/reference/tools.md index fa41dcaf8c..caec8028c9 100644 --- a/content/zh/docs/reference/tools.md +++ b/content/zh/docs/reference/tools.md @@ -38,15 +38,6 @@ Kubernetes 包含一些内置工具，可以帮助用户更好的使用 Kubernet --> [`kubeadm`](/docs/tasks/tools/install-kubeadm/) 是一个命令行工具，可以用来在物理机、云服务器或虚拟机（目前处于 alpha 阶段）上轻松部署一个安全可靠的 Kubernetes 集群。 -## Kubefed - - -[`kubefed`](/docs/tasks/federation/set-up-cluster-federation-kubefed/) 是一个命令行工具，可以用来帮助用户管理联邦集群。 - - ## Minikube - Kubernetes 的安装并不会默认配置节点的 `resolv.conf` 文件来使用集群的 DNS 服务，因为这个配置对于不同的发行版本是不一样的。这个问题应该迟早会被解决的。 Linux 的 libc 会在仅有三个 DNS 的 `nameserver` 和六个 DNS 的`search` 记录时会不可思议的卡死 ([详情请查阅这个2005年的bug](https://bugzilla.redhat.com/show_bug.cgi?id=168253))。Kubernetes 需要占用一个 `nameserver` 记录和三个`search`记录。这意味着如果一个本地的安装已经使用了三个`nameserver`或者使用了超过三个的 `search`记录，那有些配置很可能会丢失。有一个不完整的解决方案就是在节点上使用`dnsmasq`来提供更多的`nameserver`配置，但是无法提供更多的`search`记录。您也可以使用kubelet 的 `--resolv-conf` 标签来解决这个问题。 @@ -532,24 +529,6 @@ Linux 的 libc 会在仅有三个 DNS 的 `nameserver` 和六个 DNS 的`search` 如果您是使用 Alpine 3.3 或者更早版本作为您的基础镜像，DNS 可能会由于Alpine 一个已知的问题导致无法正常工作，请查看[这里](https://github.com/kubernetes/kubernetes/issues/30215)获取更多资料。 - -## Kubernetes Federation (支持多区域部署) - -自从 1.3 版本支持了多个 Kubernetes 的联邦集群后，集群 DNS 服务在处理 DNS 请求时需要有一些微弱的调整 (这是向下兼容的)，从而可以使用跨越多个 Kubernetes 集群的联邦服务。请看 [联邦集群管理向导](/docs/concepts/cluster-administration/federation/) 获取更多关于联邦集群和多点支持的信息。 - - +--> ## 参考 @@ -572,6 +548,3 @@ for more details on Cluster Federation and multi-site support. - [集群里自动伸缩 DNS Service](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/). - - - diff --git a/content/zh/docs/tasks/federation/_index.md b/content/zh/docs/tasks/federation/_index.md deleted file mode 100755 index 41b5f58674..0000000000 --- a/content/zh/docs/tasks/federation/_index.md +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: "联邦 - 在多个集群上运行一个应用" -weight: 120 ---- diff --git a/content/zh/docs/tasks/federation/administer-federation/_index.md b/content/zh/docs/tasks/federation/administer-federation/_index.md deleted file mode 100644 index 72d12f92fc..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/_index.md +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: "管理联邦控制平面" -weight: 160 ---- diff --git a/content/zh/docs/tasks/federation/administer-federation/configmap.md b/content/zh/docs/tasks/federation/administer-federation/configmap.md deleted file mode 100644 index 0c2e619338..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/configmap.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -title: 联邦 ConfigMap -content_type: task ---- - - - - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - -本指南介绍如何在联邦控制平面中使用 ConfigMap。 - -联邦 ConfigMap 与传统 [Kubernetes -ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) 非常相似且提供相同的功能。 -在联邦控制平面中创建它们可以确保它们在联邦的所有集群中同步。 - - - -## {{% heading "prerequisites" %}} - - -* {{< include "federated-task-tutorial-prereqs.md" >}} - -* 通常我们还期望您拥有基本的 [Kubernetes 应用知识](/docs/tutorials/kubernetes-basics/)， -特别是 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) 相关的应用知识。 - - - - - -## 创建联邦 ConfigMap - -联邦 ConfigMap 的 API 100% 兼容传统 Kubernetes ConfigMap 的 API。您可以通过向联邦 apiserver 发送请求来创建 ConfigMap。 -您可以通过使用 [kubectl](/docs/user-guide/kubectl/) 运行下面的指令来创建联邦 ConfigMap： - -``` shell -kubectl --context=federation-cluster create -f myconfigmap.yaml -``` - -`--context=federation-cluster` 参数告诉 kubectl 将请求提交到联邦 apiserver 而不是发送给某一个 Kubernetes 集群。 - -一旦联邦 ConfigMap 被创建，联邦控制平面就会在所有底层 Kubernetes 集群中创建匹配的 ConfigMap。 -您可以通过检查底层每个集群来对其进行验证，例如： - -``` shell -kubectl --context=gce-asia-east1a get configmap myconfigmap -``` - -上面的命令假定您在客户端中配置了一个叫做 ‘gce-asia-east1a’ 的上下文。 - -这些底层集群中的 ConfigMap 将与 联邦 ConfigMap 相匹配。 - - -## 更新联邦 ConfigMap - -您可以像更新 Kubernetes ConfigMap 一样更新联邦 ConfigMap。 -但是对于联邦 ConfigMap，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。 -联邦控制平面会确保每当联邦 ConfigMap 更新时，它会更新所有底层集群中的 ConfigMap 来和更新后的内容保持一致。 - - -## 删除联邦 ConfigMap - -您可以像删除 Kubernetes ConfigMap 一样删除联邦 ConfigMap。 -但是，对于联邦 ConfigMap，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。 -例如，您可以使用 kubectl 运行下面的命令来删除联邦 ConfigMap： - -```shell -kubectl --context=federation-cluster delete configmap -``` - -{{< note >}} - -要注意的是这时删除联邦 ConfigMap 并不会删除底层集群中对应的 ConfigMap。您必须自己手动删除底层集群中的 ConfigMap。 -{{< /note >}} - - - - diff --git a/content/zh/docs/tasks/federation/administer-federation/daemonset.md b/content/zh/docs/tasks/federation/administer-federation/daemonset.md deleted file mode 100644 index 88ed66d090..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/daemonset.md +++ /dev/null @@ -1,136 +0,0 @@ ---- -title: 联邦 DaemonSet -content_type: task ---- - - - - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - - -本指南说明了如何在联邦控制平面中使用 DaemonSet。 - -联邦控制平面中的 DaemonSet（在本指南中称为 “联邦 DaemonSet”）与传统的 Kubernetes [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) 非常类似，并提供相同的功能。在联邦控制平面中创建联邦 DaemonSet 可以确保它们同步到联邦的所有集群中。 - - - -## {{% heading "prerequisites" %}} - - -* {{< include "federated-task-tutorial-prereqs.md" >}} - -* 你还应该具备基本的 [Kubernetes 应用知识](/docs/tutorials/kubernetes-basics/)，特别是 [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) 相关的应用知识。 - - - - - - -## 创建联邦 Daemonset - -联邦 Daemonset 的 API 和传统的 Kubernetes Daemonset API 是 100% 兼容的。您可以通过向联邦 apiserver 发送请求来创建一个 DaemonSet。 - -您可以通过使用 [kubectl](/docs/user-guide/kubectl/) 运行下面的指令来创建联邦 Daemonset： - -``` shell -kubectl --context=federation-cluster create -f mydaemonset.yaml -``` - -`--context=federation-cluster` 参数告诉 kubectl 发送请求到联邦 apiserver 而不是某个 Kubernetes 集群。 - -一旦联邦 Daemonset 被创建，联邦控制平面就会在所有底层 Kubernetes 集群中创建匹配的 Daemonset。您可以通过检查底层每个集群来对其进行验证，例如： - -``` shell -kubectl --context=gce-asia-east1a get daemonset mydaemonset -``` - -上面的命令假定您在客户端中配置了一个叫做 ‘gce-asia-east1a’ 的上下文。 - - - -## 更新联邦 Daemonset - -您可以像更新 Kubernetes Daemonset 一样更新联邦 Daemonset。但是，对于联邦 Daemonset，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。联邦控制平面会确保每当联邦 Daemonset 更新时，它会更新所有底层集群中的 Daemonset 来和更新后的内容保持一致。 - - -## 删除联邦 Daemonset - -您可以像删除 Kubernetes Daemonset 一样删除联邦 Daemonset。但是，对于联邦 Daemonset，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。 - -例如，您可以使用 kubectl 运行下面的命令来删除联邦 Daemonset： - -```shell -kubectl --context=federation-cluster delete daemonset mydaemonset -``` - - - - diff --git a/content/zh/docs/tasks/federation/administer-federation/deployment.md b/content/zh/docs/tasks/federation/administer-federation/deployment.md deleted file mode 100644 index 1d4e53ffa4..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/deployment.md +++ /dev/null @@ -1,177 +0,0 @@ ---- -title: 联邦 Deployment -content_type: task ---- - - - - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - - -本指南说明了如何在联邦控制平面中使用 Deployment。 - -联邦控制平面中的 Deployment（在本指南中称为 “联邦 Deployment”）与传统的 [Kubernetes -Deployment](/docs/concepts/workloads/controllers/deployment/) 非常类似，并提供相同的功能。在联邦控制平面中创建联邦 Deployment 确保所需的副本数存在于注册的群集中。 - -{{< feature-state for_k8s_version="1.5" state="alpha" >}} - - -一些特性（例如完整的 rollout 兼容性）仍在开发中。 - - -## {{% heading "prerequisites" %}} - - -* {{< include "federated-task-tutorial-prereqs.md" >}} - -* 您还应当拥有基本的 [Kubernetes 应用知识](/docs/tutorials/kubernetes-basics/)，特别是在 [Deployments](/docs/concepts/workloads/controllers/deployment/) 方面。 - - - - - -## 创建联邦 Deployment - -联邦 Deployment 的 API 和传统的 Kubernetes Deployment API 是兼容的。 您可以通过向联邦 apiserver 发送请求来创建一个 Deployment。 - -您可以通过使用 [kubectl](/docs/user-guide/kubectl/) 运行下面的指令： - -``` shell -kubectl --context=federation-cluster create -f mydeployment.yaml -``` - -`--context=federation-cluster` 参数告诉 kubectl 发送请求到联邦 apiserver 而不是某个 Kubernetes 集群。 - -一旦联邦 Deployment 被创建，联邦控制平面会在所有底层 Kubernetes 集群中创建一个 Deployment。 您可以通过检查底层每个集群来对其进行验证，例如： - -``` shell -kubectl --context=gce-asia-east1a get deployment mydep -``` - -上面的命令假定您在客户端中配置了一个叫做 ‘gce-asia-east1a’ 的上下文， - -底层集群中的这些 Deployment 会匹配联邦 Deployment 中副本数和修订版本相关注解_之外_的信息。 联邦控制平面确保所有集群中的副本总数与联邦 Deployment 中请求的副本数量匹配。 - - -### 在底层集群中分布副本 - -默认情况下，副本会被平均分布到所有的底层集群中。例如：如果您有 3 个注册的集群并且创建了一个副本数为 9(`spec.replicas = 9`) 的联邦 Deployment，那么这 3 个集群中的每个 Deployment 都将有 3 个副本 (`spec.replicas=3`)。 -为修改每个集群中的副本数，您可以在联邦 Deployment 中以注解的形式指定 [FederatedReplicaSetPreference](https://github.com/kubernetes/federation/blob/{{< param "githubbranch" >}}/apis/federation/types.go)，其中注解的键为 `federation.kubernetes.io/deployment-preferences`。 - - - -## 更新联邦 Deployment - -您可以像更新 Kubernetes Deployment 一样更新联邦 Deployment。但是，对于联邦 Deployment，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。联邦控制平面会确保每当联邦 Deployment 更新时，它会更新所有底层集群中相应的 Deployment 来和更新后的内容保持一致。 所以如果（在联邦 Deployment 中）选择了滚动更新，那么底层集群会独立地进行滚动更新，并且联邦 Deployment 中的 `maxSurge` 和 `maxUnavailable` 只会应用于独立的集群中。将来这种行为可能会改变。 - -如果您的更新包括副本数量的变化，联邦控制平面会改变底层集群中的副本数量，以确保它们的总数等于联邦 Deployment 中请求的数量。 - - -## 删除联邦 Deployment - -您可以像删除 Kubernetes Deployment 一样删除联邦 Deployment。但是，对于联邦 Deployment，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。 - -例如，您可以使用 kubectl 运行下面的命令来删除联邦 Deployment： - -```shell -kubectl --context=federation-cluster delete deployment mydep -``` - - - - diff --git a/content/zh/docs/tasks/federation/administer-federation/events.md b/content/zh/docs/tasks/federation/administer-federation/events.md deleted file mode 100644 index 56f0a644f6..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/events.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -title: 联邦事件 -content_type: concept ---- - - - - - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - - -本指南介绍如何在联邦控制平面中使用事件来帮助调试。 - - - - - - - - -## 先决条件 - - - -本指南假定您正在运行 Kubernetes 集群联邦安装。 -如果没有，请转到[联邦管理员指南](/docs/concepts/cluster-administration/federation/)，了解如何启动集群联邦（或让集群管理员为您执行此操作）。 -其他教程，例如[这个](https://github.com/kelseyhightower/kubernetes-cluster-federation)由 Kelsey Hightower，也可为您提供帮助。 - - -你还应该具备 [kubernetes 基本工作知识](/docs/tutorials/kubernetes-basics/)。 - - - -## 查看联邦事件 - - -联邦控制平面中的事件（本指南中称为“联邦事件”）与提供相同功能的传统 Kubernetes 事件非常相似。 -联邦事件仅存储在联邦控制平面中，不会传递给基础 Kubernetes 集群。 - - -联邦控制器在处理 API 资源时创建事件，以便向用户显示它们所处的状态。您可以通过运行以下命令从联邦 apiserver 获取所有事件： - -```shell -kubectl --context=federation-cluster get events -``` - - -标准的 kubectl get，update，delete 命令都可以正常工作。 - - diff --git a/content/zh/docs/tasks/federation/administer-federation/job.md b/content/zh/docs/tasks/federation/administer-federation/job.md deleted file mode 100644 index 27983d7924..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/job.md +++ /dev/null @@ -1,191 +0,0 @@ ---- -title: 联邦 Job -content_type: task ---- - - - - - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - - -本指南解释了如何在联邦控制平面中使用 job。 - -联邦控制平面中的一次性任务（在本指南中称为“联邦一次性任务”）类似于传统的 [Kubernetes 一次性任务](/docs/concepts/workloads/controllers/job/)，并且提供相同的功能。 -在联邦控制平面中创建 job 可以确保在已注册的集群中存在所需的并行性和完成数。 - - - -## {{% heading "prerequisites" %}} - - -* {{< include "federated-task-tutorial-prereqs.md" >}} -* 你需要具备基本的 [Kubernetes 的工作知识](/docs/tutorials/kubernetes-basics/)，特别是 [job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)。 - - - - - - - - - -## 创建一个联邦 job - - - -用于联邦 job 的 API 与用于传统 Kubernetes job 的 API 完全兼容。您可以通过向联邦 apiserver 发送请求来创建 job。 - -你可以使用 [kubectl](/docs/user-guide/kubectl/) 来运行： - -``` shell -kubectl --context=federation-cluster create -f myjob.yaml -``` - - -`--context=federation-cluster` 参数告诉 kubectl 将请求提交到联邦 API 服务器，而不是发送到 Kubernetes 集群。 - - -一旦创建了联邦 job，联邦控制平面将在所有底层 Kubernetes 集群中创建一个 job。 -你可以通过检查每个集群底层来验证这一点，例如： - -``` shell -kubectl --context=gce-asia-east1a get job myjob -``` - - -前面的示例假设你的客户端中为该区域中的集群配置了一个名为 `gce-asia-east1a` 的上下文。 - - -集群底层中的 job 与联邦 job 匹配，但并行性和完成数不匹配。 -联邦控制平面确保每个集群中的并行性和完成数之和与联合作业中所需的并行度和完成数匹配。 - - - -### 将 job 任务分散到集群底层中 - - -默认情况下，并行性和完成数在所有底层集群中平均分布。例如： -如果你有 3 个已注册的集群，并且创建了一个联邦 job -`spec.parallelism = 9` 和 `spec.completions = 18`，那么 3 个集群中的每个 job 都有 `spec.parallelism = 3` 和 `spec.completions = 6`。 -要修改每个集群中的并行性和完成数，可以指定 [ReplicaAllocationPreferences](https://github.com/kubernetes/federation/blob/{{< param "githubbranch" >}}/apis/federation/types.go) -作为 `federation.kubernetes.io/job-preferences` 联邦 job 上的 key 的注释。 - - - -## 更新联邦 job - - -可以像更新 Kubernetes job 一样更新联邦 job；但是，对于联邦 job，必须将请求发送到联邦 API 服务器，不是发送到指定的 Kubernetes 集群。 -联邦控制平面确保无论何时更新联邦 job，它都会更新所有集群底层中的相应 job 以匹配它。 - - -如果您的更新包含并行性和完成数的更改，则联邦控制平面将更改集群底层中的并行性和完成数， -确保它们的总和仍然等于联邦 job 中所需的并行性和完成数。 - - - -## 删除联邦 job - - -可以删除联邦 job，就像删除 Kubernetes job 一样;但是，对于联邦 job，必须将请求发送到联邦 API 服务器，不是发送到指定的 Kubernetes 集群。 - - -例如，使用 kubectl： - -```shell -kubectl --context=federation-cluster delete job myjob -``` - -{{< note >}} - - -删除联邦作业不会从基础集群中删除相应的 job。 -您必须手动删除基础 job。 - -{{< /note >}} - - - - diff --git a/content/zh/docs/tasks/federation/administer-federation/namespaces.md b/content/zh/docs/tasks/federation/administer-federation/namespaces.md deleted file mode 100644 index f5032b52f3..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/namespaces.md +++ /dev/null @@ -1,158 +0,0 @@ ---- -title: 联邦命名空间 -content_type: task ---- - - - - - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - - -本指南介绍如何在联邦控制平面中使用命名空间。 - - -联邦控制平面中的命名空间（本指南中称为“联邦命名空间”）与提供相同功能的传统 Kubernetes 命名空间非常相似。 -在联邦控制平面中创建它们可确保它们在联邦中的所有集群之间同步 - - - -## {{% heading "prerequisites" %}} - - -* {{< include "federated-task-tutorial-prereqs.md" >}} -* 您还需要具备基本的 [Kubernetes 工作知识](/docs/tutorials/Kubernetes-basics/)， -特别是[命名空间](/docs/concepts/overview/working-objects/Namespaces/)。 - - - - - - - - - -## 创建联邦命名空间 - - -联邦命名空间的 API 与传统 Kubernetes 命名空间的 API 100％ 兼容。您可以通过向联邦身份验证程序发送请求来创建命名空间。 - - -您可以通过运行以下命令使用 kubectl 执行此操作： - -``` shell -kubectl --context=federation-cluster create -f myns.yaml -``` - - -`--context=federation-cluster` 参数通知 kubectl 将请求提交给联邦 apiserver，而不是将其发送到 Kubernetes 集群。 - - -创建联邦命名空间后，联邦控制平面将在所有基础 Kubernetes 集群中创建匹配的命名空间。您可以通过检查每个基础集群来验证这一点，例如： - -``` shell -kubectl --context=gce-asia-east1a get namespaces myns -``` - - -以上假设您在客户端中为该区域中的集群配置了名为 “gce-asia-east1a” 的上下文。 -基础命名空间的名称和规范将与您在上面创建的联邦命名空间的名称和规范相匹配。 - - - -## 更新联邦命名空间 - - -您可以像更新 Kubernetes 命名空间一样更新联邦命名空间，只需将请求发送到联邦身份验证程序，而不是将其发送到指定的 Kubernetes 集群。 -联邦控制平面将确保每当更新联邦命名空间时，它都会更新所有基础集群中的相应命名空间以与其匹配。 - - - -## 删除联邦命名空间 - - -你可以删除联邦命名空间，就像删除 Kubernetes 命名空间一样，只需将请求发送到联邦身份验证器，而不是发送到指定的 Kubernetes 群集。 - - -例如，您可以通过运行以下命令使用 kubectl 执行此操作： - -```shell -kubectl --context=federation-cluster delete ns myns -``` - - -与在 Kubernetes 中一样，删除联邦命名空间将从联邦控制平面中删除该命名空间中的所有资源。 - -{{< note >}} - - -此时，删除联邦命名空间，不会从底层集群中删除相应的命名空间或这些命名空间中的资源。用户必须手动删除它们。我们打算将来解决这个问题。 - -{{< /note >}} - - - - diff --git a/content/zh/docs/tasks/federation/administer-federation/replicaset.md b/content/zh/docs/tasks/federation/administer-federation/replicaset.md deleted file mode 100644 index af7ae0efe9..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/replicaset.md +++ /dev/null @@ -1,220 +0,0 @@ ---- -title: 联邦 ReplicaSet -content_type: task ---- - - - - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - - -本指南阐述了如何在联邦控制平面中使用 ReplicaSet。 -在联邦控制平面中的 ReplicaSet (在本指南中称为”联邦 ReplicaSet”) 和传统的 [Kubernetes -ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) 很相似，提供了一样的功能。在联邦控制平面中创建联邦 ReplicaSet 可以确保在联邦的所有集群中都有预期数量的副本。 - - -## {{% heading "prerequisites" %}} - - -* {{< include "federated-task-tutorial-prereqs.md" >}} - -* 你还应该具备基本的 [Kubernetes 应用知识](/docs/tutorials/kubernetes-basics/)，特别是 [ReplicaSets](/docs/concepts/workloads/controllers/replicaset/) 相关的应用知识。 - - - - - - -## 创建联邦 ReplicaSet - -联邦 ReplicaSet 的 API 和传统的 Kubernetes ReplicaSet API 是 100% 兼容的。您可以通过请求联邦 apiserver 来创建联邦 ReplicaSet。 - -您可以通过使用 [kubectl](/docs/user-guide/kubectl/) 运行下面的指令来创建联邦 ReplicaSet： - -``` shell -kubectl --context=federation-cluster create -f myrs.yaml -``` - -`--context=federation-cluster` 参数告诉 kubectl 发送请求到联邦 apiserver 而不是某个 Kubernetes 集群。 - -一旦联邦 ReplicaSet 被创建了，联邦控制平面就会在所有底层 Kubernetes 集群中创建一个 ReplicaSet。您可以通过检查底层每个集群来对其进行验证，例如： - -``` shell -kubectl --context=gce-asia-east1a get rs myrs -``` - -上面的命令假定您在客户端中配置了一个叫做 ‘gce-asia-east1a’ 的上下文。 - -底层集群中的 ReplicaSet 的副本数将会和联邦 ReplicaSet 的副本数保持一致。联邦控制平面将确保联邦的所有集群都和联邦 ReplicaSet 有同样的副本数。 - - -### 底层集群中副本的分布 - -默认情况下，副本在所有底层集群中是均匀分布的。例如：如果您有 3 个注册的集群并且用 `spec.replicas = 9` 参数创建了一个联邦 ReplicaSet，然后在这 3 个集群中每个 ReplicaSet 的副本数会是 `spec.replicas=3`。 -如果要修改每个集群中的副本数，您可以在联邦 ReplicaSet 中使用 `federation.kubernetes.io/replica-set-preferences` 作为注解键值来修改联合副本集。 -注解的键值是序列化的 JSON，其中包含以下示例中显示的字段： - -``` -{ - "rebalance": true, - "clusters": { - "foo": { - "minReplicas": 10, - "maxReplicas": 50, - "weight": 100 - }, - "bar": { - "minReplicas": 10, - "maxReplicas": 100, - "weight": 200 - } - } -} -``` -`rebalance` 布尔字段指定是否可以移动已调度和正在运行的副本，以便将当前状态与指定的首选项相匹配。 -`clusters` 对象字段包含一个映射，用户可以在其中指定跨集群的副本放置的约束（示例中为 `foo` 和 `bar`）。 -对于每个集群，您可以指定应分配给它的最小副本数（默认值为零），集群可以接受的最大副本数（默认为无限制）以及表示要添加该群集的副本的首选项的相对权重的数字。 - - -## 更新联邦 ReplicaSet - -您可以像更新 Kubernetes ReplicaSet 一样更新联邦 ReplicaSet。但是对于联邦 ReplicaSet，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。联邦控制平面会确保任何时候联邦 ReplicaSet 更新后，它会将对应的 ReplicaSet 更新到所有的底层集群中来和它保持一致。 - -如果您做了包含副本数量的更改，联邦控制平面将会更改底层集群中的副本数以确保它们的总数和联邦 ReplicaSet 期望的副本数保持一致。 - - -## 删除联邦 ReplicaSet - -您可以像删除 Kubernetes ReplicaSet 一样删除联邦 ReplicaSet。但是对于联邦 ReplicaSet ，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。 - -例如，您可以使用 kubectl 运行下面的命令来删除联邦 ReplicaSet： - -```shell -kubectl --context=federation-cluster delete rs myrs -``` - -{{< note >}} - -要注意的是这时删除联邦 ReplicaSet 并不会删除底层集群中对应的 ReplicaSet。您必须自己手动删除底层集群中的 ReplicaSet。我们打算在将来修复这个问题。 -{{< /note >}} - - - - diff --git a/content/zh/docs/tasks/federation/administer-federation/secret.md b/content/zh/docs/tasks/federation/administer-federation/secret.md deleted file mode 100644 index 5b185ddb29..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/secret.md +++ /dev/null @@ -1,164 +0,0 @@ ---- -title: 联邦 Secret -content_type: concept ---- - - - - - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - - -本指南解释了如何在联邦控制平面中使用 secret。 - -联邦控制平面中的 Secret（在本指南中称为“联邦 secret”）与提供相同功能的传统 [Kubernetes Secret](/docs/concepts/configuration/secret/) 非常相似。 -在联邦控制平面中创建它们可以确保它们跨联邦中的所有集群同步。 - - - - - - - - -## 先决条件 - - -本指南假设你有一个正在运行的 Kubernetes 集群联邦安装。 -如果没有，请访问[联邦管理指南](/docs/admin/federation/)，了解如何启动联邦集群（或者让集群管理员为你做这件事）。 -其他教程，例如[这里](https://github.com/kelseyhightower/kubernetes-cluster-federation) Kelsey Hightower，也可以帮助您。 - - -你还应该具有一个基本的 [Kubernetes 工作知识](/docs/tutorials/kubernetes-basics/)， -特别是 [Secret](/docs/concepts/configuration/secret/)。 - - - -## 创建联邦 Secret - - -用于联邦 Secret 的 API 与用于传统的 Kubernetes Secret 的 API 100% 兼容。 -您可以通过向联邦 apiserver 发送请求来创建一个 Secret。 - - -你可以使用 [kubectl](/docs/user-guide/kubectl/) 来运行： - -``` shell -kubectl --context=federation-cluster create -f mysecret.yaml -``` - - -`--context=federation-cluster` 参数通知 kubectl 将请求提交给联邦 apiserver，而不是将其发送到 Kubernetes 集群。 - - -创建联邦命名空间后，联邦控制平面将在所有基础 Kubernetes 集群中创建匹配的命名空间。您可以通过检查每个基础集群来验证这一点，例如： - -``` shell -kubectl --context=gce-asia-east1a get secret mysecret -``` - - -以上假设您在客户端中为该区域中的集群配置了名为 “gce-asia-east1a” 的上下文。 -集群底层中的这些 secret 将与联邦 secret 匹配。 - - - -## 更新联邦 Secret - - -您可以像更新 Kubernetes secret 一样更新联邦 secret，但是，对于联邦 secret 必须将请求发送到联邦 apiserver， -而不是将其发送到指定的 Kubernetes 集群。联邦控制平面将确保每当更新联邦 secret 时，它都会更新所有基础集群中的相应 secret 以与其匹配。 - - - -## 删除联邦 Secret - - -你可以删除一个联邦 secret，就像删除一个 Kubernetes secret 一样；但是， -对于联邦 secret，必须将请求发送到联邦 apiserver，而不是发送到指定的 Kubernetes 集群。 - - -例如，您可以通过运行以下命令使用 kubectl 执行此操作： - -```shell -kubectl --context=federation-cluster delete secret mysecret -``` - -{{< note >}} - - -此时，删除联邦 secret 不会从集群底层中删除相应的 secret。你必须手动删除底层 secret。我们打算将来解决这个问题。 - -{{< /note >}} - - diff --git a/content/zh/docs/tasks/federation/federation-service-discovery.md b/content/zh/docs/tasks/federation/federation-service-discovery.md deleted file mode 100644 index b3237e0122..0000000000 --- a/content/zh/docs/tasks/federation/federation-service-discovery.md +++ /dev/null @@ -1,509 +0,0 @@ ---- -title: 使用联合服务来实现跨集群的服务发现 -content_type: task -weight: 140 ---- - - - - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - - -本指南说明了如何使用 Kubernetes 联合服务跨多个 Kubernetes 集群部署通用服务。这样可以轻松实现 Kubernetes 应用程序的跨集群服务发现和可用区容错。 - - - -联合服务的创建与传统服务几乎相同 [Kubernetes Services](/docs/concepts/services-networking/service/) 即通过 API 调用来指定所需的服务属性。对于联合服务，此 API 调用定向到联合身份验证 API 接入点，而不是 Kubernetes 集群 API 接入点。联合服务的 API 与传统 Kubernetes 服务的 API 是 100% 兼容的。 - - -创建后，联合服务会自动: - - -1. 在基础集群联合的每个集群中创建匹配的 Kubernetes 服务, -2. 监视那些服务 "分片"(及其驻留的集群)的运行状况,以及 -3. 在公共 DNS 提供商(例如 Google Cloud DNS 或 AWS Route 53)中管理一组 DNS 记录,即使在集群可用区域中断的情况下，也能确保您联合服务的客户端始终可以无缝地定位合适的健康服务接入点。 - - -如果存在健康的分片，联合 Kubernetes 集群(即 Pods )中的客户端将自动在其中找到联合服务的本地分片集群或者集群中最接近的健康分片;如果不存在，则使用最接近的其他集群的健康分片。 - - - -{{< toc >}} - -## {{% heading "prerequisites" %}} - - -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - - - - - -## 前提 - - -本指南假设您已经安装 Kubernetes 联合集群。如果没有，则访问 [联合集群管理指南](/docs/admin/federation/)了解如何建立联合集群(或让您的集群管理员为您执行此操作)。其他教程，例如 Kelsey Hightower 编写的 [案例](https://github.com/kelseyhightower/kubernetes-cluster-federation)或许有用。 - - -一般而言，您应该还有基本的 [Kubernetes 工作常识](/docs/tutorials/kubernetes-basics/)，特别是 [Services](/docs/concepts/services-networking/service/)。 - - -## 混合云功能 - - -Kubernetes 联合集群需要可以在不同的云提供商(例如 Google Cloud 或 AWS)和本地(例如 OpenStack)环境中运行。只需在合适的云提供商创建所需的所有集群，向您的联合身份验证 API 服务器注册每个集群的 API 接入点和凭据(有关详细信息，请参见 [联合管理指南](/docs/admin/federation/))。 - - -此后，您的应用程序和服务可以跨越不同的集群和云提供商，如下所述。 - - -## 创建联合服务 - - -常见方式创建，例如: - -``` shell -kubectl --context=federation-cluster create -f services/nginx.yaml -``` - - -'--context=federation-cluster' 标志通知 kubectl 使用合适的凭据将请求提交到联合 API 接入点。如果您尚未配置此类上下文，请访问 [联合管理指南](/docs/admin/federation/)或者 [管理教程](https://github.com/kelseyhightower/kubernetes-cluster-federation)找出解决方案。 - - -如上所述，联合服务将自动创建并在所有集群中维护匹配的 Kubernetes 服务以支持联合。 - - -您可以通过核对每个基础集群的信息来验证这一点, 例如: - -``` shell -kubectl --context=gce-asia-east1a get services nginx -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -nginx ClusterIP 10.63.250.98 104.199.136.89 80/TCP 9m -``` - - -以上假设您有一个名为 'gce-asia-east1a' 上下文在客户端中为该区域中的集群配置。基础服务的名称和命名空间将自动与您在上面创建的联合服务匹配(如果服务的名称和命名空间与集群中任意一个服务器的名称和命名空间相同，它们将被联合并更新为符合您的规范联合服务 - 无论哪种方式，最终结果都是相同的)。 - - -联合服务的状态将自动反映基础 Kubernetes 服务的实时状态，例如: - -``` shell -kubectl --context=federation-cluster describe services nginx -``` -``` -Name: nginx -Namespace: default -Labels: run=nginx -Annotations: -Selector: run=nginx -Type: LoadBalancer -IP: 10.63.250.98 -LoadBalancer Ingress: 104.197.246.190, 130.211.57.243, 104.196.14.231, 104.199.136.89, ... -Port: http 80/TCP -Endpoints: -Session Affinity: None -Events: -``` - - -{{< note >}} -联合服务的 'LoadBalancer Ingress' 地址与所有基础 Kubernetes 服务的 'LoadBalancer Ingress' 地址相对应(一旦分配了这些地址，这可能需要几秒钟)。为了使服务分片之间的集群和云提供商之间的网络正常工作，您的服务需要具有一个外部可见的 IP 地址。[Service Type:Loadbalancer](/docs/concepts/services-networking/service/#loadbalancer)。尽管存在其他选项(例如 [外部 IP](/docs/concepts/services-networking/service/#external-ips)),但通常会使用 [Service 类型:Loadbalancer](/docs/concepts/services-networking/service/#loadbalancer)。 -{{< /note >}} - - -还要注意，我们尚未设置任何后端 Pod 来接收定向到这些地址的网络流量(即 'Service Endpoints')，因此联合服务尚未将它们视为健康的服务分片，并且尚未将其地址添加到联合服务的 DNS 记录中(稍后在此方面进行介绍)。 - - -## 添加后端 pods - - -为了使基础服务分片健康，我们需要在它们后面添加后端 Pod。当前，这是直接针对基础集群 API 接入点完成的(尽管将来，联合服务将能够通过单个命令为您完成所有这些操作，从而省去了麻烦)。例如，在13个基础集群中创建后端 Pod: - -``` shell -for CLUSTER in asia-east1-c asia-east1-a asia-east1-b \ - europe-west1-d europe-west1-c europe-west1-b \ - us-central1-f us-central1-a us-central1-b us-central1-c \ - us-east1-d us-east1-c us-east1-b -do - kubectl --context=$CLUSTER run nginx --image=nginx:1.11.1-alpine --port=80 -done -``` - - -注意，`kubectl run` 会自动添加 `run=nginx` 标签，这是将后端 pod 与其服务关联起来所必需的。 - - -## 验证公共 DNS 记录 - - -一旦上述 Pod 成功启动并开始侦听连接，Kubernetes 就会将它们报告为该集群中服务的正常接入点(通过自动运行状况检查)。反过来，联合集群会将这些服务 '分片' 中的每一个视为健康，并通过自动配置相应的公共 DNS 记录将其置于服务中。您可以使用首选接口访问已配置的 DNS 提供程序来进行验证。例如，如果您的联邦配置为使用 Google Cloud DNS 和托管 DNS 域名 'example.com'。 - -``` shell -gcloud dns managed-zones describe example-dot-com -``` -``` -creationTime: '2016-06-26T18:18:39.229Z' -description: Example domain for Kubernetes Cluster Federation -dnsName: example.com. -id: '3229332181334243121' -kind: dns#managedZone -name: example-dot-com -nameServers: -- ns-cloud-a1.googledomains.com. -- ns-cloud-a2.googledomains.com. -- ns-cloud-a3.googledomains.com. -- ns-cloud-a4.googledomains.com. -``` - -```shell -gcloud dns record-sets list --zone example-dot-com -``` -``` -NAME TYPE TTL DATA -example.com. NS 21600 ns-cloud-e1.googledomains.com., ns-cloud-e2.googledomains.com. -example.com. OA 21600 ns-cloud-e1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 1209600 300 -nginx.mynamespace.myfederation.svc.example.com. A 180 104.197.246.190, 130.211.57.243, 104.196.14.231, 104.199.136.89,... -nginx.mynamespace.myfederation.svc.us-central1-a.example.com. A 180 104.197.247.191 -nginx.mynamespace.myfederation.svc.us-central1-b.example.com. A 180 104.197.244.180 -nginx.mynamespace.myfederation.svc.us-central1-c.example.com. A 180 104.197.245.170 -nginx.mynamespace.myfederation.svc.us-central1-f.example.com. CNAME 180 nginx.mynamespace.myfederation.svc.us-central1.example.com. -nginx.mynamespace.myfederation.svc.us-central1.example.com. A 180 104.197.247.191, 104.197.244.180, 104.197.245.170 -nginx.mynamespace.myfederation.svc.asia-east1-a.example.com. A 180 130.211.57.243 -nginx.mynamespace.myfederation.svc.asia-east1-b.example.com. CNAME 180 nginx.mynamespace.myfederation.svc.asia-east1.example.com. -nginx.mynamespace.myfederation.svc.asia-east1-c.example.com. A 180 130.211.56.221 -nginx.mynamespace.myfederation.svc.asia-east1.example.com. A 180 130.211.57.243, 130.211.56.221 -nginx.mynamespace.myfederation.svc.europe-west1.example.com. CNAME 180 nginx.mynamespace.myfederation.svc.example.com. -nginx.mynamespace.myfederation.svc.europe-west1-d.example.com. CNAME 180 nginx.mynamespace.myfederation.svc.europe-west1.example.com. -... etc. -``` - - -{{< note >}} -如果您的联邦配置为使用 AWS Route53，则可以使用类似的 AWS 工具，例如: - -``` shell -aws route53 list-hosted-zones -``` -和 - -``` shell -aws route53 list-resource-record-sets --hosted-zone-id Z3ECL0L9QLOVBX -``` -{{< /note >}} - - -无论使用哪种 DNS 提供商，任何 DNS 查询工具(例如 'dig' 或者 'nslookup')都将允许您查看联邦会为您创建的记录。请注意，您应该将这些工具直接指向您的 DNS 提供商(例如 `dig @ ns-cloud-e1.googledomains.com ...`),或者由于中间 DNS 服务器进行了缓存，因此在看到更新之前，预计延迟会按照配置的 TTL 顺序(默认为 180 秒)进行。 - - -### 有关上述示例的一些注意事项 - - -1. 请注意，每个具有至少一个正常后端端点的服务分片都有一条正常('A')记录。例如，在 us-central1-a 中，104.197.247.191 是该区域中服务分片的外部 IP 地址，在 asia-east1-a 中，该地址是 130.211.56.221。 -2. 同样，也有区域 'A' 记录，其中包括该区域中所有健康的分片。例如，'us-central1'。这些区域记录对于没有特定区域首选项的客户很有用，并且作为下文所述的自动位置和故障转移机制的基础。 -3. 对于当前没有健康后端终结点的区域，将使用 CNAME ('Canonical Name') 记录将这些查询别名(自动重定向)到下一个最接近的健康区域。在此示例中，us-central1-f 中的服务分片当前没有健康的后端端点(即Pods)，因此已创建 CNAME 记录来自动将查询重定向到该区域中的其他分片(在本例中为 us-central1)。 -4. 类似地，如果封闭区域中不存在健康分片，则搜索将进一步进行。在 europe-west1-d 可用性区域中,没有健康的后端,因此查询将重定向到更广阔的 Europe-west1 区域(也没有健康的后端),然后再重定向到全局的健康地址集('nginx.mynamespace.myfederation.svc.example.com.')。 - - -上面的 DNS 记录集由联邦服务系统自动与全球所有服务分片的当前健康状况保持同步。DNS 解析库(由所有客户端调用)自动遍历 'CNAME' 与 'A' 记录的层次结构，以返回正确健康的 IP 地址集。然后，客户端可以选择任何返回的地址来启动网络连接(并根据需要自动故障转移到其他等效地址之一)。 - - -## 发现联合服务 - - -### 从联合集群内的 Pods 来发现 - - -默认情况下，Kubernetes 集群预先配置了本地集群 DNS 服务器('KubeDNS')以及智能构建的 DNS 搜索路径，这些路径共同确保由 Pods 内部运行软件发出的 DNS 查询如 "myservice", "myservice.mynamespace","bobsservice.othernamespace" 等，会自动扩展并正确解析为本地集群运行服务的相应服务 IP。 - - -随着联合服务和跨集群服务发现的引入，该概念已扩展到涵盖在全球集群联盟中任何其他集群中运行的 Kubernetes 服务。要利用此扩展范围，您可以使用形式稍有不同的 DNS 名称，形式为 ```".."``` 来解析联合服务。例如，您可以使用 `myservice.mynamespace.myfederation`。使用不同的 DNS 名称还可以避免现有应用程序意外穿越跨区域或跨区域网络，并且可能招致不必要的网络费用或延迟，而无需您明确选择采取这种行为。 - - -因此，使用上面的 NGINX 示例服务和刚才描述的联合服务 DNS 名称表单，让我们考虑一个示例:`us-central1-f` 可用性区域集群中的 Pod 需要联系我们的 NGINX 服务。现在，可以使用服务的联合 DNS 名称，而不是使用服务的传统集群本地 DNS 名称(`"nginx.mynamespace"` 会自动扩展为 `"nginx.mynamespace.svc.cluster.local"`)。无论位于世界何处，它都会自动扩展并解析为我的 NGINX 服务中最接近的健康分片。如果本地集群中存在健康的分片，则将返回该服务的集群本地(通常为10.x.y.z)的 IP 地址(由集群本地的 KubeDNS)。这几乎完全等同于非联合服务解析(几乎是因为 KubeDNS 实际上为本地联合服务返回了 CNAME 和 A 记录，但是应用程序将忽略这种微小的技术差异)。 - - -但是，如果服务在本地集群中不存在(或者存在但没有正常的后端 Pod),则 DNS 查询会自动扩展为 ```"nginx.mynamespace.myfederation.svc.us-central1-f.example.com"```(也就是说，从逻辑上 "找到最接近我可用区的一个分片的外部 IP")。此扩展由 KubeDNS 自动执行，它返回关联的 CNAME 记录。这将导致在上面的示例中自动遍历 DNS 记录的层次结构，并最终到达本地 us-central1 区域中联合服务的外部 IP 之一(即 104.197.247.191, 104.197.244.180 或 104.197.245.170 )。 - - -当然，可以通过明确地指定合适的 DNS 名称而不依赖于自动 DNS 扩展，在 Pod 本地的可用区域和可用区域之外的区域中明确地定位服务分片。例如，即使发出查询的 Pod 位于美国，"nginx.mynamespace.myfederation.svc.europe-west1.example.com" 也将解析欧洲目前所有健康的服务分片,并且无论美国是否有健康的服务分片。这对于远程监视和其他类似应用程序很有用。 - - -### 来自联合集群之外的其他客户端 - - -上面大部分讨论都同样适用于外部客户端，除了不再描述所描述的自动 DNS 扩展。因此，外部客户端需要指定联合服务的标准 DNS 名称，可以是地带名称，区域名称或者全局名称。为了方便起见，通常最好在服务中手动配置其他静态 CNAME 记录，例如: - -``` shell -eu.nginx.acme.com CNAME nginx.mynamespace.myfederation.svc.europe-west1.example.com. -us.nginx.acme.com CNAME nginx.mynamespace.myfederation.svc.us-central1.example.com. -nginx.acme.com CNAME nginx.mynamespace.myfederation.svc.example.com. -``` - -这样，您的客户就可以始终使用左侧的缩写形式，并始终被自动路由到其本国大陆上最接近的健康分片。Kubernetes 联邦集群自动为您处理所有必需的故障转移。将来的发行版将对此进行进一步改进。 - - -## 处理后端 Pod 和整个集群的故障 - - -标准的 Kubernetes 服务集群 IP 已确保无响应的单个 Pod 端点以低延迟(几秒钟)自动退出服务。此外，如上所述，Kubernetes 联邦集群系统会自动监视集群的状态以及联合服务的所有分片后面的端点，并根据需要使分片进入和退出服务(例如，当服务后面的所有端点或者整个集群或可用性区域出现故障时，或者相反地从中断中恢复时)。由于 DNS 缓存固有的延迟(默认情况下,缓存超时或联合服务 DNS 记录的 TTL 配置为3分钟，可以调整),在灾难性故障的情况下，所有客户端可能要花费很长时间才能完全故障转移到备用集群。但是，鉴于每个区域服务端点可以返回的离散 IP 地址数量(例如上面的 us-central1，它有三个替代方案),与给定的合适配置相比，许多客户端将在更少的时间内自动故障转移到其他 IP。 - - - - - - -## 故障排除 - - -### 我无法连接到联合集群 API - -检查您的 - - -1. 客户端(通常是 kubectl)已正确配置(包括 API 端点和登录凭据)。 -2. 联合集群 API 服务器正在运行并且可以访问网络。 - - -请参阅 [联合集群管理员指南](/docs/admin/federation/)了解如何正确启动联邦集群(或让您的集群管理员为您执行此操作),以及如何正确配置客户端。 - - -### 我可以针对联合集群 API 成功创建联合服务,但是在我的基础集群中没有创建匹配的服务。 - -检查: - - -1. 您的集群已在联合集群 API 中正确注册(`kubectl describe clusters`)。 -2. 您的集群都是 "活跃的"。这意味着集群联合身份验证系统能够针对集群的端点进行连接和身份验证。如果不是，请查阅federation-controller-manager pod 的日志，以确定可能是什么故障。 - ``` - kubectl --namespace=federation logs $(kubectl get pods --namespace=federation -l module=federation-controller-manager -o name) - ``` -3. 集群提供给联合集群 API 的登录凭据具有正确的授权和配额，可以在集群的相关命名空间中创建服务。如果不是这种情况，您将再次在上述日志文件中看到相关的错误消息，以提供更多详细信息。 -4. 是否有其他错误阻止服务创建操作成功(请在 `kubectl logs federation-controller-manager --namespace federation` 的输出中查找 `service-controller` 错误)。 - - -### 我可以成功创建联合服务，但是在我的 DNS 提供程序中没有创建匹配的 DNS 记录。 -检查: - - -1. 您的联邦集群名称，DNS 提供程序，DNS 域名已正确配置。请参阅 [联邦集群管理指南](/docs/admin/federation/)或者 [教程](https://github.com/kelseyhightower/kubernetes-cluster-federation)了解如何配置联合集群系统的 DNS 提供程序(或让您的集群管理员为您执行此操作)。 -2. 确认联合集群的服务控制器已成功连接到所选的 DNS 提供程序并对其进行身份验证(在 `kubectl logs federation-controller-manager --namespace federation` 的输出中查找 `service-controller` 错误或者成功)。 -3. 确认联合集群的服务控制器已在您的 DNS 提供程序中成功创建了 DNS 记录(或在其日志中输出错误，以更详细地解释失败原因)。 - - -### 在我的 DNS 提供程序中创建了匹配的 DNS 记录，但是客户端无法根据这些名称进行解析 -检查: - - -1. 已正确配置用于管理联合 DNS 域名的 DNS 注册器，使其指向已配置的 DNS 提供程序的名称服务器。例如，请参见 [Google Domains 文档](https://support.google.com/domains/answer/3290309?hl=en&ref_topic=3251230)与 [Google Cloud DNS 文档](https://cloud.google.com/dns/update-name-servers),或者域名注册商和 DNS 提供商的等效指南。 - - -### 此疑难解答指南没有帮助我解决问题 - - -1. 请使用我们的 [支持渠道](/docs/tasks/debug-application-cluster/troubleshooting/)寻求帮助。 - - -## 更多信息 - - - * [联合提议](https://git.k8s.io/community/contributors/design-proposals/multicluster/federation.md) 详细介绍了促进这项工作的用例。 - diff --git a/content/zh/docs/tasks/federation/set-up-coredns-provider-federation.md b/content/zh/docs/tasks/federation/set-up-coredns-provider-federation.md deleted file mode 100644 index 8193d928dc..0000000000 --- a/content/zh/docs/tasks/federation/set-up-coredns-provider-federation.md +++ /dev/null @@ -1,254 +0,0 @@ ---- -title: 将 CoreDNS 设置为联邦集群的 DNS 提供者 -content_type: tutorial -weight: 130 ---- - - - - - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - - -此页面显示如何配置和部署 CoreDNS，将其用作联邦集群的 DNS 提供者 - - - - -## {{% heading "objectives" %}} - - - - -* 配置和部署 CoreDNS 服务器 -* 使用 CoreDNS 作为 dns 提供者设置联邦 -* 在 nameserver 查找链中设置 CoreDNS 服务器 - - - - -## {{% heading "prerequisites" %}} - - - - -* 你需要有一个正在运行的 Kubernetes 集群（作为主机集群引用）。请参阅[入门指南](/docs/setup/)，了解平台的安装说明。 -* 必须在联邦的集群成员中支持 `LoadBalancer` 服务，用来支持跨联邦集群的 `CoreDNS` 服务发现。 - - - - - - - - -## 部署 CoreDNS 和 etcd 图表 - - -CoreDNS 可以部署在各种配置中。下面解释的是一个参考，可以根据平台和联邦集群的需要进行调整。 - - -为了部署 CoreDNS，我们将利用图表。 -CoreDNS 将部署 [etcd](https://coreos.com/etcd) 作为后端，并且应该预先安装。etcd 也可以使用图表进行部署。下面显示了部署 etcd 的说明。 - - helm install --namespace my-namespace --name etcd-operator stable/etcd-operator - helm upgrade --namespace my-namespace --set cluster.enabled=true etcd-operator stable/etcd-operator - - -*注意：etcd 默认部署配置可以被覆盖，适合主机集群。* - - -部署成功后，可以使用主机集群中的 [http://etcd-cluster.my-namespace:2379](http://etcd-cluster.my-namespace:2379) 端点访问 etcd。 - - -应该定制 CoreDNS 默认配置适应联邦。 -下面显示的是 Values.yaml，它覆盖了 CoreDNS 图表上的默认配置参数。 - -```yaml -isClusterService: false -serviceType: "LoadBalancer" -plugins: - kubernetes: - enabled: false - etcd: - enabled: true - zones: - - "example.com." - endpoint: "http://etcd-cluster.my-namespace:2379" -``` - - -以上配置文件需要说明： - - - - `isClusterService` 指定是否应该将 CoreDNS 部署为集群服务，这是默认值。 -你需要将其设置为 false，以便将 CoreDNS 部署为 Kubernetes 应用程序服务。 - - `serviceType` 指定为核心用户创建的 Kubernetes 服务的类型。 -你需要选择 `LoadBalancer` 或 `NodePort`，以便在 Kubernetes 集群之外访问 CoreDNS 服务。 - - 禁用 `plugins.kubernetes`，默认情况下通过设置 `plugins.kubernetes.enabled` 为 false。 - - 启用 `plugins.etcd`，通过设置 `plugins.etcd.enabled` 为 true。 - - 通过设置 `plugins.etcd.zones` 来配置 CoreDNS 具有权威性的 DNS 域（联邦域）。如上所示。 - - 通过设置 `plugins.etcd.endpoint` 来配置早期部署的 etcd 端点 - - -现在部署 CoreDNS 来运行 - - helm install --namespace my-namespace --name coredns -f Values.yaml stable/coredns - -验证 etcd 和 CoreDNS，pod 都按预期运行。 - - - -## 使用 CoreDNS 作为 DNS 提供者部署联邦 - - -可以使用 `kubefed init` 部署联邦控制平面。通过指定两个附加参数，可以选择 CoreDNS 作为 DNS 提供者。 - - --dns-provider=coredns - --dns-provider-config=coredns-provider.conf - - -coredns-provider.conf 的格式如下： - - [Global] - etcd-endpoints = http://etcd-cluster.my-namespace:2379 - zones = example.com. - coredns-endpoints = : - - - - - `etcd-endpoints` 是访问 etcd 的端点。 - - `zones` 是 CoreDNS 具有权威性的联邦域，它与 `kubefed init` 的 --dns-zone-name 参数相同。 - - `coredns-endpoints` 是访问 CoreDNS 服务器的端点。这是从 v1.7 开始引入的一个可选参数。 - -{{< note >}} - -CoreDNS 配置中的 `plugins.etcd.zones` 和 `kubefed init` 的 `--dns-zone-name` 参数应该匹配。 -{{< /note >}} - - - -## 在 nameserver resolv.conf 链中设置 CoreDNS 服务器 - -{{< note >}} - -下面的部分只适用于 v1.7 之前的版本，如果 `coredns-endpoint` 参数是 -在 `coredns-provider.conf` 中配置的，就会自动处理。 - -{{< /note >}} - - -一旦部署了联邦控制平面并将联邦集群连接到联邦， -你需要将 CoreDNS 服务器添加到所有联邦集群中 pod 的 nameserver resolv.conf 链，因为这个自托管的 CoreDNS 服务器是不可公开发现的。 -这可以通过在 `kube-dns` 部署中将下面的行添加到 `dnsmasq` 容器的参数中来实现。 - - - --server=/example.com./ - - -将上面的 `example.com` 替换为联邦域。 - - -现在联邦集群已经为跨集群服务发现做好了准备！ - - - - diff --git a/content/zh/docs/tasks/federation/set-up-placement-policies-federation.md b/content/zh/docs/tasks/federation/set-up-placement-policies-federation.md deleted file mode 100644 index 1dfc62e3fd..0000000000 --- a/content/zh/docs/tasks/federation/set-up-placement-policies-federation.md +++ /dev/null @@ -1,331 +0,0 @@ ---- -title: 在联邦中设置放置策略 -content_type: task ---- - - - - - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - - -此页面显示如何使用外部策略引擎对联邦资源强制执行基于策略的放置决策。 - - - -## {{% heading "prerequisites" %}} - - - -您需要一个正在运行的 Kubernetes 集群(它被引用为主机集群)。有关您的平台的安装说明，请参阅[入门](/docs/setup/)指南。 - - - - - - -## Deploying 联邦并配置外部策略引擎 - - -可以使用 `kubefed init` 部署联邦控制平面。 - - -Deploying 联邦控制平面之后，必须在联邦 API 服务器中配置一个准入控制器，该控制器强制执行从外部策略引擎接收到的放置决策。 - - - kubectl create -f scheduling-policy-admission.yaml - - -下图是准入控制器的 ConfigMap 示例： - -{{< codenew file="federation/scheduling-policy-admission.yaml" >}} - - -ConfigMap 包含三个文件： - - -* `config.yml` 指定 `调度策略` 准入控制器配置文件的位置。 -* `scheduling-policy-config.yml` 指定与外部策略引擎联系所需的 kubeconfig 文件的位置。 -该文件还可以包含一个 `retryBackoff` 值，该值以毫秒为单位控制初始重试 backoff 延迟。 -* `opa-kubeconfig` 是一个标准的 kubeconfig，包含联系外部策略引擎所需的 URL 和凭证。 - - -编辑联邦 API 服务器部署以启用 `SchedulingPolicy` 准入控制器。 - - kubectl -n federation-system edit deployment federation-apiserver - - -更新 Federation API 服务器命令行参数以启用准入控制器， -并将 ConfigMap 挂载到容器中。如果存在现有的 `-enable-admissionplugins` 参数，则追加 `SchedulingPolicy` 而不是添加另一行。 - - - --enable-admission-plugins=SchedulingPolicy - --admission-control-config-file=/etc/kubernetes/admission/config.yml - - -将以下卷添加到联邦 API 服务器 pod： - - - name: admission-config - configMap: - name: admission - - -添加以下卷挂载联邦 API 服务器的 `apiserver` 容器： - - volumeMounts: - - name: admission-config - mountPath: /etc/kubernetes/admission - - - -## Deploying 外部策略引擎 - - -[Open Policy Agent (OPA)](http://openpolicyagent.org) 是一个开源的通用策略引擎， -您可以使用它在联邦控制平面中执行基于策略的放置决策。 - - -在主机群集中创建服务以联系外部策略引擎： - - kubectl create -f policy-engine-service.yaml - - -下面显示的是 OPA 的示例服务。 - -{{< codenew file="federation/policy-engine-service.yaml" >}} - - -使用联邦控制平面在主机群集中创建部署： - - kubectl create -f policy-engine-deployment.yaml - - -下面显示的是 OPA 的部署示例。 - -{{< codenew file="federation/policy-engine-deployment.yaml" >}} - - - -## 通过 ConfigMaps 配置放置策略 - - -外部策略引擎将发现在 Federation API 服务器的 `kube-federation-scheduling-policy` -命名空间中创建的放置策略。 - - -如果命名空间尚不存在，请创建它： - - kubectl --context=federation create namespace kube-federation-scheduling-policy - - -配置一个示例策略来测试外部策略引擎: - -``` -# 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 . -# 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 -# if where is true if AND AND ... -# 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] -} -``` - - -下面显示的是创建示例策略的命令： - - kubectl --context=federation -n kube-federation-scheduling-policy create configmap scheduling-policy --from-file=policy.rego - - -这个示例策略说明了一些关键思想： - - - -* 位置策略可以引用联邦资源中的任何字段。 -* 放置策略可以利用外部上下文(例如，集群元数据)来做出决策。 -* 管理策略可以集中管理。 -* 策略可以定义简单的接口(例如 `requirements -pci` 注解)，以避免在清单中重复逻辑。 - - - -## 测试放置政策 - - -注释其中一个集群以表明它是经过 PCI 认证的。 - - kubectl --context=federation annotate clusters cluster-name-1 pci-certified=true - - -部署联邦副本来测试放置策略。 - -{{< codenew file="federation/replicaset-example-policy.yaml" >}} - - -下面显示的命令用于部署与策略匹配的副本集。 - - kubectl --context=federation create -f replicaset-example-policy.yaml - - -检查副本集以确认已应用适当的注解： - - kubectl --context=federation get rs nginx-pci -o jsonpath='{.metadata.annotations}' - - - - From 75b8566c9d87f1c087ac71bd6265b679064bdc51 Mon Sep 17 00:00:00 2001 From: Weiping Cai Date: Sat, 25 Jul 2020 18:49:42 +0800 Subject: [PATCH 59/86] fix svc type error Signed-off-by: Weiping Cai --- content/en/docs/tutorials/services/source-ip.md | 2 +- content/zh/docs/tutorials/services/source-ip.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/tutorials/services/source-ip.md b/content/en/docs/tutorials/services/source-ip.md index 03a9bb097c..e6b1feeadd 100644 --- a/content/en/docs/tutorials/services/source-ip.md +++ b/content/en/docs/tutorials/services/source-ip.md @@ -177,7 +177,7 @@ service/nodeport exposed ```shell NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport) -NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="ExternalIP")].address }') +NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="InternalIP")].address }') ``` If you're running on a cloud provider, you may need to open up a firewall-rule diff --git a/content/zh/docs/tutorials/services/source-ip.md b/content/zh/docs/tutorials/services/source-ip.md index d44eb358a0..bd0fdc9629 100644 --- a/content/zh/docs/tutorials/services/source-ip.md +++ b/content/zh/docs/tutorials/services/source-ip.md @@ -150,7 +150,7 @@ service/nodeport exposed ```console NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport) -NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="ExternalIP")].address }') +NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="InternalIP")].address }') ``` 如果你的集群运行在一个云服务上，你可能需要为上面报告的 `nodes:nodeport` 开启一条防火墙规则。 From d817393e5b1c9c8aa3e225de4b5b7d253842964a Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Sat, 25 Jul 2020 12:46:36 +0100 Subject: [PATCH 60/86] Fix front matter --- .../command-line-tools-reference/kube-controller-manager.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/reference/command-line-tools-reference/kube-controller-manager.md b/content/zh/docs/reference/command-line-tools-reference/kube-controller-manager.md index cf7ca4a28a..602d0bdbfa 100644 --- a/content/zh/docs/reference/command-line-tools-reference/kube-controller-manager.md +++ b/content/zh/docs/reference/command-line-tools-reference/kube-controller-manager.md @@ -1,6 +1,6 @@ --- title: kube-controller-manager -content_template: templates/tool-reference +content_type: tool-reference weight: 30 --- From ee02334f5ed7b8eb81a9786c49812e9ea1123671 Mon Sep 17 00:00:00 2001 From: Sai Harsha Kottapalli Date: Sat, 25 Jul 2020 22:16:26 +0530 Subject: [PATCH 61/86] add languagedirection in config.toml --- config.toml | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/config.toml b/config.toml index 96e88a2135..c880baa504 100644 --- a/config.toml +++ b/config.toml @@ -274,6 +274,7 @@ description = "Production-Grade Container Orchestration" languageName ="English" # Weight used for sorting. weight = 1 +languagedirection = "ltr" [languages.zh] title = "Kubernetes" @@ -281,6 +282,7 @@ description = "生产级别的容器编排系统" languageName = "中文 Chinese" weight = 2 contentDir = "content/zh" +languagedirection = "ltr" [languages.zh.params] time_format_blog = "2006.01.02" @@ -292,6 +294,7 @@ description = "운영 수준의 컨테이너 오케스트레이션" languageName = "한국어 Korean" weight = 3 contentDir = "content/ko" +languagedirection = "ltr" [languages.ko.params] time_format_blog = "2006.01.02" @@ -303,6 +306,7 @@ description = "プロダクショングレードのコンテナ管理基盤" languageName = "日本語 Japanese" weight = 4 contentDir = "content/ja" +languagedirection = "ltr" [languages.ja.params] time_format_blog = "2006.01.02" @@ -314,6 +318,7 @@ description = "Solution professionnelle d’orchestration de conteneurs" languageName ="Français" weight = 5 contentDir = "content/fr" +languagedirection = "ltr" [languages.fr.params] time_format_blog = "02.01.2006" @@ -326,6 +331,7 @@ description = "Orchestrazione di Container in produzione" languageName = "Italiano" weight = 6 contentDir = "content/it" +languagedirection = "ltr" [languages.it.params] time_format_blog = "02.01.2006" @@ -338,6 +344,7 @@ description = "Production-Grade Container Orchestration" languageName ="Norsk" weight = 7 contentDir = "content/no" +languagedirection = "ltr" [languages.no.params] time_format_blog = "02.01.2006" @@ -350,6 +357,7 @@ description = "Produktionsreife Container-Orchestrierung" languageName ="Deutsch" weight = 8 contentDir = "content/de" +languagedirection = "ltr" [languages.de.params] time_format_blog = "02.01.2006" @@ -362,6 +370,7 @@ description = "Orquestación de contenedores para producción" languageName ="Español" weight = 9 contentDir = "content/es" +languagedirection = "ltr" [languages.es.params] time_format_blog = "02.01.2006" @@ -374,6 +383,7 @@ description = "Orquestração de contêineres em nível de produção" languageName ="Português" weight = 9 contentDir = "content/pt" +languagedirection = "ltr" [languages.pt.params] time_format_blog = "02.01.2006" @@ -386,6 +396,7 @@ description = "Orkestrasi Kontainer dengan Skala Produksi" languageName ="Bahasa Indonesia" weight = 10 contentDir = "content/id" +languagedirection = "ltr" [languages.id.params] time_format_blog = "02.01.2006" @@ -398,6 +409,7 @@ description = "Production-Grade Container Orchestration" languageName = "Hindi" weight = 11 contentDir = "content/hi" +languagedirection = "ltr" [languages.hi.params] time_format_blog = "01.02.2006" @@ -409,6 +421,7 @@ description = "Giải pháp điều phối container trong môi trường produc languageName = "Tiếng Việt" contentDir = "content/vi" weight = 12 +languagedirection = "ltr" [languages.ru] title = "Kubernetes" @@ -416,6 +429,7 @@ description = "Первоклассная оркестрация контейн languageName = "Русский" weight = 12 contentDir = "content/ru" +languagedirection = "ltr" [languages.ru.params] time_format_blog = "02.01.2006" @@ -428,6 +442,7 @@ description = "Produkcyjny system zarządzania kontenerami" languageName = "Polski" weight = 13 contentDir = "content/pl" +languagedirection = "ltr" [languages.pl.params] time_format_blog = "01.02.2006" @@ -440,6 +455,7 @@ description = "Довершена система оркестрації конт languageName = "Українська" weight = 14 contentDir = "content/uk" +languagedirection = "ltr" [languages.uk.params] time_format_blog = "02.01.2006" From e53298d4252b77701d25dcf7249ecc102f164c30 Mon Sep 17 00:00:00 2001 From: Irvi Firqotul Aini Date: Sat, 25 Jul 2020 19:37:02 +0700 Subject: [PATCH 62/86] feat: Add ID translation for run stateless application deployment --- .../id/docs/tasks/run-application/_index.md | 5 + .../run-stateless-application-deployment.md | 158 ++++++++++++++++++ .../application/deployment-scale.yaml | 19 +++ .../application/deployment-update.yaml | 19 +++ 4 files changed, 201 insertions(+) create mode 100644 content/id/docs/tasks/run-application/_index.md create mode 100644 content/id/docs/tasks/run-application/run-stateless-application-deployment.md create mode 100644 content/id/examples/application/deployment-scale.yaml create mode 100644 content/id/examples/application/deployment-update.yaml diff --git a/content/id/docs/tasks/run-application/_index.md b/content/id/docs/tasks/run-application/_index.md new file mode 100644 index 0000000000..7c5e073f2b --- /dev/null +++ b/content/id/docs/tasks/run-application/_index.md @@ -0,0 +1,5 @@ +--- +title: "Menjalankan" +description: Menjalankan dan mengatur aplikasi stateless dan stateful. +weight: 40 +--- diff --git a/content/id/docs/tasks/run-application/run-stateless-application-deployment.md b/content/id/docs/tasks/run-application/run-stateless-application-deployment.md new file mode 100644 index 0000000000..a069188de6 --- /dev/null +++ b/content/id/docs/tasks/run-application/run-stateless-application-deployment.md @@ -0,0 +1,158 @@ +--- +title: Menjalankan Aplikasi Stateless Menggunakan Deployment +min-kubernetes-server-version: v1.9 +content_type: tutorial +weight: 10 +--- + + + +Dokumen ini menunjukkan cara bagaimana cara menjalankan sebuah aplikasi menggunakan objek Deployment Kubernetes. + + + + +## {{% heading "objectives" %}} + + +* Membuat sebuah Deployment Nginx. +* Menggunakan kubectl untuk mendapatkan informasi mengenai Deployment. +* Mengubah Deployment. + + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + + + +## Membuat dan Menjelajahi Deployment Nginx + +Kamu dapat menjalankan aplikasi dengan membuat sebuah objek Deployment Kubernetes, dan kamu +dapat mendeskripsikan sebuah Deployment di dalam berkas YAML. Sebagai contohnya, berkas +YAML berikut mendeskripsikan sebuah Deployment yang menjalankan _image_ Docker nginx:1.14.2: + +{{< codenew file="application/deployment.yaml" >}} + + +1. Buatlah sebuah Deployment berdasarkan berkas YAML: + + kubectl apply -f https://k8s.io/examples/application/deployment.yaml + +2. Tampilkan informasi dari Deployment: + + kubectl describe deployment nginx-deployment + + Keluaran dari perintah tersebut akan menyerupai: + + user@computer:~/website$ kubectl describe deployment nginx-deployment + Name: nginx-deployment + Namespace: default + CreationTimestamp: Tue, 30 Aug 2016 18:11:37 -0700 + Labels: app=nginx + Annotations: deployment.kubernetes.io/revision=1 + Selector: app=nginx + Replicas: 2 desired | 2 updated | 2 total | 2 available | 0 unavailable + StrategyType: RollingUpdate + MinReadySeconds: 0 + RollingUpdateStrategy: 1 max unavailable, 1 max surge + Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.14.2 + Port: 80/TCP + Environment: + Mounts: + Volumes: + Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable + OldReplicaSets: + NewReplicaSet: nginx-deployment-1771418926 (2/2 replicas created) + No events. + +3. Lihatlah daftar Pod-Pod yang dibuat oleh Deployment: + + kubectl get pods -l app=nginx + + Keluaran dari perintah tersebut akan menyerupai: + + NAME READY STATUS RESTARTS AGE + nginx-deployment-1771418926-7o5ns 1/1 Running 0 16h + nginx-deployment-1771418926-r18az 1/1 Running 0 16h + +4. Tampilkan informasi mengenai Pod: + + kubectl describe pod + + dimana `` merupakan nama dari Pod kamu. + +## Mengubah Deployment + +Kamu dapat mengubah Deployment dengan cara mengaplikasikan berkas YAML yang baru. +Berkas YAML ini memberikan spesifikasi Deployment untuk menggunakan Nginx versi 1.16.1. + +{{< codenew file="application/deployment-update.yaml" >}} + +1. Terapkan berkas YAML yang baru: + + kubectl apply -f https://k8s.io/examples/application/deployment-update.yaml + +2. Perhatikan bahwa Deployment membuat Pod-Pod dengan nama baru dan menghapus Pod-Pod lama: + + kubectl get pods -l app=nginx + +## Meningkatkan Jumlah Aplikasi dengan Meningkatkan Ukuran Replika + +Kamu dapat meningkatkan jumlah Pod di dalam Deployment dengan menerapkan +berkas YAML baru. Berkas YAML ini akan meningkatkan jumlah replika menjadi 4, +yang nantinya memberikan spesifikasi agar Deployment memiliki 4 buah Pod. + +{{< codenew file="application/deployment-scale.yaml" >}} + +1. Terapkan berkas YAML: + + kubectl apply -f https://k8s.io/examples/application/deployment-scale.yaml + +2. Verifikasi Deployment kamu saat ini yang memiliki empat Pod: + + kubectl get pods -l app=nginx + + Keluaran dari perintah tersebut akan menyerupai: + + NAME READY STATUS RESTARTS AGE + nginx-deployment-148880595-4zdqq 1/1 Running 0 25s + nginx-deployment-148880595-6zgi1 1/1 Running 0 25s + nginx-deployment-148880595-fxcez 1/1 Running 0 2m + nginx-deployment-148880595-rwovn 1/1 Running 0 2m + +## Menghapus Deployment + +Menghapus Deployment dengan nama: + + kubectl delete deployment nginx-deployment + +## Cara Lama Menggunakan: ReplicationController + +Cara yang dianjurkan untuk membuat aplikasi dengan replika adalah dengan menggunakan Deployment, +yang nantinya akan menggunakan ReplicaSet. Sebelum Deployment dan ReplicaSet ditambahkan +ke Kubernetes, aplikasi dengan replika dikonfigurasi menggunakan [ReplicationController](/id/docs/concepts/workloads/controllers/replicationcontroller/). + + + + +## {{% heading "whatsnext" %}} + + +* Pelajari lebih lanjut mengenai [objek Deployment](/id/docs/concepts/workloads/controllers/deployment/). + + diff --git a/content/id/examples/application/deployment-scale.yaml b/content/id/examples/application/deployment-scale.yaml new file mode 100644 index 0000000000..84e326eee1 --- /dev/null +++ b/content/id/examples/application/deployment-scale.yaml @@ -0,0 +1,19 @@ +apiVersion: apps/v1 # untuk versi sebelum 1.9.0 gunakan apps/v1beta2 +kind: Deployment +metadata: + name: nginx-deployment +spec: + selector: + matchLabels: + app: nginx + replicas: 4 # Memperbarui replica dari 2 menjadi 4 + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 diff --git a/content/id/examples/application/deployment-update.yaml b/content/id/examples/application/deployment-update.yaml new file mode 100644 index 0000000000..63fbdb69cf --- /dev/null +++ b/content/id/examples/application/deployment-update.yaml @@ -0,0 +1,19 @@ +apiVersion: apps/v1 # untuk versi sebelum 1.9.0 gunakan apps/v1beta2 +kind: Deployment +metadata: + name: nginx-deployment +spec: + selector: + matchLabels: + app: nginx + replicas: 2 + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.16.1 # Memperbarui versi nginx dari 1.14.2 ke 1.16.1 + ports: + - containerPort: 80 From 9c83a485119f3ff96324e347a71afa45c7981358 Mon Sep 17 00:00:00 2001 From: GoodGameZoo Date: Sat, 25 Jul 2020 21:21:45 -0700 Subject: [PATCH 63/86] update zh description what-is-kubernetes.md --- content/zh/docs/concepts/overview/what-is-kubernetes.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/content/zh/docs/concepts/overview/what-is-kubernetes.md b/content/zh/docs/concepts/overview/what-is-kubernetes.md index d4c9bfc47b..4aab8132f1 100644 --- a/content/zh/docs/concepts/overview/what-is-kubernetes.md +++ b/content/zh/docs/concepts/overview/what-is-kubernetes.md @@ -1,6 +1,8 @@ --- title: Kubernetes 是什么？ content_type: concept +description: > + Kubernetes 是一个可移植的，可扩展的开源平台，用于管理容器化的工作负载和服务，方便了声明式配置和自动化。它拥有一个庞大且快速增长的生态系统。Kubernetes 的服务，支持和工具广泛可用。 weight: 10 card: name: concepts @@ -74,7 +76,7 @@ Each VM is a full machine running all the components, including its own operatin 每个 VM 是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。 **容器部署时代：** @@ -214,4 +216,4 @@ Kubernetes： * Ready to [Get Started](/docs/setup/)? --> * 查阅 [Kubernetes 组件](/zh/docs/concepts/overview/components/) -* 开始 [Kubernetes 入门](/zh/docs/setup/)? \ No newline at end of file +* 开始 [Kubernetes 入门](/zh/docs/setup/)? From 0ad63be15e2c7990b76be22c3fa679de7858ca9c Mon Sep 17 00:00:00 2001 From: Arhell Date: Sun, 26 Jul 2020 10:13:15 +0300 Subject: [PATCH 64/86] indent fix on video block --- content/ru/_index.html | 1 - 1 file changed, 1 deletion(-) diff --git a/content/ru/_index.html b/content/ru/_index.html index 4466b3b210..7298da03f4 100644 --- a/content/ru/_index.html +++ b/content/ru/_index.html @@ -41,7 +41,6 @@ Kubernetes — это проект с открытым исходным кодо

-
Посетите KubeCon в Амстердаме, с 30 марта по 2 апреля 2020

From 4b7883e7e1af657c297e14673f04497a1a2e7705 Mon Sep 17 00:00:00 2001 From: craigbox Date: Sun, 26 Jul 2020 10:37:19 +0100 Subject: [PATCH 65/86] Update 2020-07-27-kubernetes-1-17-release-interview.md Changed suggested by review. --- ...07-27-kubernetes-1-17-release-interview.md | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/content/en/blog/_posts/2020-07-27-kubernetes-1-17-release-interview.md b/content/en/blog/_posts/2020-07-27-kubernetes-1-17-release-interview.md index e76d72bb49..01e95c5c68 100644 --- a/content/en/blog/_posts/2020-07-27-kubernetes-1-17-release-interview.md +++ b/content/en/blog/_posts/2020-07-27-kubernetes-1-17-release-interview.md @@ -80,7 +80,7 @@ GUINEVERE SAENGER: I will say that that entire team was absolutely wonderful, de **CRAIG BOX: You now work on GitHub's Kubernetes infrastructure. Obviously, there was GitHub before there was a Kubernetes, so a migration happened. What can you tell us about the transition that GitHub made to running on Kubernetes?** -GUINEVERE SAENGER: A disclaimer here-- I was not at GitHub at the time that the transition to Kubernetes was made. However, to the best of my knowledge, the decision to transition to Kubernetes was made and people decided, yes, we want to try Kubernetes. We want to use Kubernetes. And mostly, the only decision left was, which one of our applications should we move over to Kubernetes? +GUINEVERE SAENGER: A disclaimer here— I was not at GitHub at the time that the transition to Kubernetes was made. However, to the best of my knowledge, the decision to transition to Kubernetes was made and people decided, yes, we want to try Kubernetes. We want to use Kubernetes. And mostly, the only decision left was, which one of our applications should we move over to Kubernetes? **CRAIG BOX: I thought GitHub was written on Rails, so there was only one application.** @@ -102,23 +102,23 @@ GUINEVERE SAENGER: I'm not sure this is a lesson specifically, but I was on supp GUINEVERE SAENGER: It should not have affected any customers, I should mention, at this point. But all in all, it took a few of us a few hours to almost completely recover from this event. I think that, without Kubernetes, this would not have been possible. -**CRAIG BOX: Generally, deleting something like that is quite catastrophic. We've seen a number of other vendors suffer large outages when someone's done something to that effect, which is why we get #hugops on Twitter all the time.** +**CRAIG BOX: Generally, deleting something like that is quite catastrophic. We've seen a number of other vendors suffer large outages when someone's done something to that effect, which is why we get [#hugops](https://twitter.com/hashtag/hugops) on Twitter all the time.** GUINEVERE SAENGER: People did send me #hugops, that is a thing that happened. But overall, something like this was an interesting stress test and sort of proved that it wasn't nearly as catastrophic as a worst case scenario. **CRAIG BOX: GitHub [runs its own data centers](https://githubengineering.com/githubs-metal-cloud/). Kubernetes was largely built for running on the cloud, but a lot of people do choose to run it on their own, bare metal. How do you manage clusters and provisioning of the machinery you run?** -GUINEVERE SAENGER: When I started, my onboarding project was to deprovision an old cluster, make sure all the traffic got moved to somewhere where it would keep running, provision a new cluster, and then move website traffic onto the new cluster. That was a really exciting onboarding project. At the time, we provisioned bare metal machines using Puppet. We still do that to a degree, but I believe the team that now runs our computing resources actually inserts virtual machines as an extra layer between the bare metal and the Kubernetes notes. +GUINEVERE SAENGER: When I started, my onboarding project was to deprovision an old cluster, make sure all the traffic got moved to somewhere where it would keep running, provision a new cluster, and then move website traffic onto the new cluster. That was a really exciting onboarding project. At the time, we provisioned bare metal machines using Puppet. We still do that to a degree, but I believe the team that now runs our computing resources actually inserts virtual machines as an extra layer between the bare metal and the Kubernetes nodes. Again, I was not intrinsically part of that decision, but my understanding is that it just makes for a greater reliability and reproducibility across the board. We've had some interesting hardware dependency issues come up, and the virtual machines basically avoid those. **CRAIG BOX: You've been working with Kubernetes for a couple of years now. How did you get involved in the release process?** -GUINEVERE SAENGER: When I first started in the project, I started at the [special interest group for contributor experience](ttps://github.com/kubernetes/community/tree/master/sig-contributor-experience), namely because one of my co-workers at the time, Aaron Crickenberger, was a big Kubernetes community person. Still is. +GUINEVERE SAENGER: When I first started in the project, I started at the [special interest group for contributor experience](https://github.com/kubernetes/community/tree/master/sig-contributor-experience#readme), namely because one of my co-workers at the time, Aaron Crickenberger, was a big Kubernetes community person. Still is. **CRAIG BOX: We've [had him on the show](https://kubernetespodcast.com/episode/046-kubernetes-1.14/) for one of these very release interviews!** -GUINEVERE SAENGER: In fact, this is true! So Aaron and I actually go way back to Samsung SDS. Anyway, Aaron suggested that I should write up a contribution to the Kubernetes project, and I said, me? And he said, yes, of course. You will be [speaking at KubeCon](https://www.youtube.com/watch?v=TkCDUFR6xqw), so you should probably get started with a PR or something. So I tried, and it was really, really hard. And I [complained about it in a public GitHub issue](https://github.com/kubernetes/community/issues/141), and people said, yeah. Yeah, we know it's hard. Do you want to help with that? +GUINEVERE SAENGER: In fact, this is true! So Aaron and I actually go way back to Samsung SDS. Anyway, Aaron suggested that I should write up a contribution to the Kubernetes project, and I said, me? And he said, yes, of course. You will be [speaking at KubeCon](https://www.youtube.com/watch?v=TkCDUFR6xqw), so you should probably get started with a PR or something. So I tried, and it was really, really hard. And I complained about it [in a public GitHub issue](https://github.com/kubernetes/community/issues/141), and people said, yeah. Yeah, we know it's hard. Do you want to help with that? And so I started getting really involved with the [process for new contributors to get started](https://github.com/kubernetes/community/tree/master/contributors/guide) and have successes, kind of getting a foothold into a project that's as large and varied as Kubernetes. From there on, I began to talk to people, get to know people. The great thing about the Kubernetes community is that there is so much mentorship to go around. @@ -132,7 +132,7 @@ GUINEVERE SAENGER: Yeah. **CRAIG BOX: But we're friends.** -GUINEVERE SAENGER: But he totally helped me when I didn't know how to get-- patch my borked pull request. So that happened. And eventually, somebody just suggested that I start following along in the release process and shadow someone on their release team role. And that, at the time, was Tim Pepper, who was bug triage lead, and I shadowed him for that role. +GUINEVERE SAENGER: But he totally helped me when I didn't know how to git patch my borked pull request. So that happened. And eventually, somebody just suggested that I start following along in the release process and shadow someone on their release team role. And that, at the time, was Tim Pepper, who was bug triage lead, and I shadowed him for that role. **CRAIG BOX: Another [podcast guest](https://kubernetespodcast.com/episode/010-kubernetes-1.11/) on the interview train.** @@ -148,7 +148,7 @@ GUINEVERE SAENGER: We have only a very few new things. The one that I'm most exc GUINEVERE SAENGER: I don't know! -**CRAIG BOX: [Please see the appendix to this podcast](https://softwareengineering.stackexchange.com/questions/185380/ipv4-to-ipv6-where-is-ipv5) for technical explanations.** +**CRAIG BOX: Please see [the appendix to this podcast](https://softwareengineering.stackexchange.com/questions/185380/ipv4-to-ipv6-where-is-ipv5) for technical explanations.** GUINEVERE SAENGER: Having a dual stack configuration obviously enables people to have a much more flexible infrastructure and not have to worry so much about making decisions that will become outdated or that may be over-complicated. This basically means that pods can have dual stack addresses, and nodes can have dual stack addresses. And that basically just makes communication a lot easier. @@ -168,7 +168,7 @@ It has been brought up last year to make the final release more of a stability r **ADAM GLICK: On top of all of the release work that was going on, there was also KubeCon that happened. And you were involved in the [contributor summit](https://github.com/kubernetes/community/tree/master/events/2019/11-contributor-summit). How was the summit?** -GUINEVERE SAENGER: This was the first contributor summit where we had an organized events team with events organizing leads, and handbooks, and processes. And I have heard from multiple people-- this is just word of mouth-- that it was their favorite contributor summit ever. +GUINEVERE SAENGER: This was the first contributor summit where we had an organized events team with events organizing leads, and handbooks, and processes. And I have heard from multiple people— this is just word of mouth— that it was their favorite contributor summit ever. **CRAIG BOX: Was someone allocated to hat production? [Everyone had sailor hats](https://flickr.com/photos/143247548@N03/49093218951/).** @@ -192,7 +192,7 @@ GUINEVERE SAENGER: A release lead has to have served in other roles on the relea So that was actually really cool to see. And yeah, just getting to see more of the workings of the team, for me, it was exciting. The other big exciting thing, of course, was to see all the changes that were going in and all the efforts that were being made. -**CRAIG BOX: The release lead for 1.18 has just been announced as Jorge Alarcon. What are you going to put in the proverbial envelope as advice for him?** +**CRAIG BOX: The release lead for 1.18 has just been announced as [Jorge Alarcon](https://twitter.com/alejandrox135). What are you going to put in the proverbial envelope as advice for him?** GUINEVERE SAENGER: I would want Jorge to be really on top of making sure that every Special Interest Group that enters a change, that has an enhancement for 1.18, is on top of the timelines and is responsive. Communication tends to be a problem. And I had hinted at this earlier, but some enhancements slipped simply because there wasn't enough reviewer bandwidth. @@ -200,7 +200,7 @@ Greater communication of timelines and just giving people more time and space to **ADAM GLICK: What would your advice be to someone who is hearing your experience and is inspired to get involved with the Kubernetes release or contributer process?** -GUINEVERE SAENGER: Those are two separate questions. So let me tackle the Kubernetes release question first. Kubernetes SIG Release has, in my opinion, a really excellent onboarding program for new members. We have what is called the [Release Team Shadow Program](https://github.com/kubernetes/sig-release/blob/master/release-team/shadows.md). We also have the Release Engineering Shadow Program, or the Release Management Shadow Program. Those are two separate subprojects within SIG Release. And each subproject has a team of roles, and each role can have two to four shadows that are basically people who are part of that role team, and they are learning that role as they are doing it. +GUINEVERE SAENGER: Those are two separate questions. So let me tackle the Kubernetes release question first. Kubernetes [SIG Release](https://github.com/kubernetes/sig-release/#readme) has, in my opinion, a really excellent onboarding program for new members. We have what is called the [Release Team Shadow Program](https://github.com/kubernetes/sig-release/blob/master/release-team/shadows.md). We also have the Release Engineering Shadow Program, or the Release Management Shadow Program. Those are two separate subprojects within SIG Release. And each subproject has a team of roles, and each role can have two to four shadows that are basically people who are part of that role team, and they are learning that role as they are doing it. So for example, if I am the lead for bug triage on the release team, I may have two, three or four people that I closely work with on the bug triage tasks. These people are my shadows. And once they have served one release cycle as a shadow, they are now eligible to be lead in that role. We have an application form for this process, and it should probably be going up in January. It usually happens the first week of the release once all the release leads are put together. From 85c46ab152d50fa28a6b736cc62fb9bc43d58c55 Mon Sep 17 00:00:00 2001 From: craigbox Date: Sun, 26 Jul 2020 10:42:28 +0100 Subject: [PATCH 66/86] missed an em dash. --- .../blog/_posts/2020-07-27-kubernetes-1-17-release-interview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2020-07-27-kubernetes-1-17-release-interview.md b/content/en/blog/_posts/2020-07-27-kubernetes-1-17-release-interview.md index 01e95c5c68..c61def44be 100644 --- a/content/en/blog/_posts/2020-07-27-kubernetes-1-17-release-interview.md +++ b/content/en/blog/_posts/2020-07-27-kubernetes-1-17-release-interview.md @@ -54,7 +54,7 @@ When you're done with it, you don't have to relearn how to be an adult in a work GUINEVERE SAENGER: People tend to really connect the dots when I tell them I used to be a musician. Of course, I still consider myself a musician, because you don't really ever stop being a musician. But they say, 'oh, yeah, music and math', and that's just a similar sort of brain. And that makes so much sense. And I think there's a little bit of a point to that. When you learn a piece of music, you have to start recognizing patterns incredibly quickly, almost intuitively. -And I think that is the main skill that translates into programming-- recognizing patterns, finding the things that work, finding the things that don't work. And for me, especially as a collaborative pianist, it's the communicating with people, the finding out what people really want, where something is going, how to figure out what the general direction is that we want to take, before we start writing the first line of code. +And I think that is the main skill that translates into programming— recognizing patterns, finding the things that work, finding the things that don't work. And for me, especially as a collaborative pianist, it's the communicating with people, the finding out what people really want, where something is going, how to figure out what the general direction is that we want to take, before we start writing the first line of code. **CRAIG BOX: In your experience at Ada or with other experiences you've had, have you been able to identify patterns in other backgrounds for people that you'd recommend, 'hey, you're good at music, so therefore you might want to consider doing something like a course in computer science'?** From 7e10eb67da7b817a84eabd6629d11c932a1d287c Mon Sep 17 00:00:00 2001 From: Naoki Oketani Date: Sun, 26 Jul 2020 20:15:28 +0900 Subject: [PATCH 67/86] paraphrase master to control plane --- content/en/docs/concepts/cluster-administration/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/cluster-administration/_index.md b/content/en/docs/concepts/cluster-administration/_index.md index 39af4fb779..c3b51f3acf 100644 --- a/content/en/docs/concepts/cluster-administration/_index.md +++ b/content/en/docs/concepts/cluster-administration/_index.md @@ -64,7 +64,7 @@ Before choosing a guide, here are some considerations: * [Auditing](/docs/tasks/debug-application-cluster/audit/) describes how to interact with Kubernetes' audit logs. ### Securing the kubelet - * [Master-Node communication](/docs/concepts/architecture/master-node-communication/) + * [Control Plane-Node communication](/docs/concepts/architecture/control-plane-node-communication/) * [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) * [Kubelet authentication/authorization](/docs/admin/kubelet-authentication-authorization/) From 0f032d6d44af800f451f1b0af67730449579dd78 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sun, 26 Jul 2020 20:37:12 +0800 Subject: [PATCH 68/86] [zh] Sync PR wranglers reorg The PR wanglers section was reorganized in 22284. This PR syncs the changes to Chinese localization. --- content/zh/docs/contribute/advanced.md | 126 -------------- .../contribute/participate/pr-wranglers.md | 154 ++++++++++++++++++ .../participate/roles-and-responsibilties.md | 18 +- 3 files changed, 167 insertions(+), 131 deletions(-) create mode 100644 content/zh/docs/contribute/participate/pr-wranglers.md diff --git a/content/zh/docs/contribute/advanced.md b/content/zh/docs/contribute/advanced.md index 771f75b98b..d7a4624438 100644 --- a/content/zh/docs/contribute/advanced.md +++ b/content/zh/docs/contribute/advanced.md @@ -27,132 +27,6 @@ client and other tools for some of these tasks. - -## 做一周的 PR 管理者 - - -SIG Docs 的[批准人（Approvers）](/zh/docs/contribute/participating/#approvers)们每周轮流负责 -[管理仓库的 PRs](https://github.com/kubernetes/website/wiki/PR-Wranglers)。 - -PR 管理者的工作职责包括： - - -- 每天检查[悬决的 PR](https://github.com/kubernetes/website/pulls) 的质量并确保它们遵守[样式指南](/zh/docs/contribute/style/style-guide/)和[内容指南](/zh/docs/contribute/style/content-guide/)。 - - 首先查看最小的 PR（`size/XS`），然后逐渐扩展到最大的 PR（`size/XXL`）。 - - 尽可能多地审阅 PR。 -- 确保每个贡献者完成 CLA 签署。 - - 指导新的贡献者签署 [CLA](https://github.com/kubernetes/community/blob/master/CLA.md)。 - - 使用[此脚本](https://github.com/zparnold/k8s-docs-pr-botherer)自动提醒尚未签署 CLA 的贡献者签署 CLA。 -- 针对所建议的更改提供反馈，并帮助协调其他 SIG 成员进行技术审核。 - - 为 PR 所建议的内容更改提供在线反馈。 - - 如果您需要验证内容，请在 PR 上发表评论并要求贡献者提供更多细节。 - - 设置相关的 `sig/` 标签。 - - 如果需要，请从文件开头的 `reviewers:` 块中指定审阅者。 - - 设置 `Docs Review` 和 `Tech Review` 标签以标示 PR 的审阅状态。 - - 为尚未审阅的 PR 设置 `Needs Doc Review` 或者 `Needs Tech Review` 标签。 - - 为已审阅的但在合并前需要更多信息的或采取措施的 PR 设置 `Doc Review: Open Issues` 或者 `Tech Review: Open Issues` 标签。 - - 为可以合并的 PR 添加 `/lgtm` 和 `/approve` 标签。 -- 合并已经就绪的，或关闭不应该接受的 PR。 -- 每天对新增的 Issue 报告进行分类和判别。有关 SIG 文档如何使用 metadata 的准则，请参见 - [对 Issue 进行分类](/zh/docs/contribute/review/for-approvers/#triage-and-categorize-issues)。 - - -### 对于管理人有用的 GitHub 查询 - -执行管理操作时，以下查询很有用。完成以下三个查询后，剩余的要审阅的 PR 列表通常很小。 -这些查询都排除了本地化的 PR，并仅包含 `master` 分支上的 PR（除了最后一个查询）。 - - -- [没有签署 CLA, 不能合并](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen): - 提醒贡献者签署 CLA。如果机器人和审阅者都已经提醒他们，请关闭 PR，并提醒他们在签署 CLA 后可以重新提交。 - **在作者没有签署 CLA 之前，不要审阅他们的 PR！** -- [需要 LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+): - 如果需要技术审查，请告知机器人所建议的审阅者。如果 PR 需要文档审查或复制编辑，提交更改建议或向 PR 提交一个 copyedit 以使之进入下一步。 -- [有 LGTM ，需要批准](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm): - 确定 PR 是否需要进行其他更改或更新才能合并。如果您认为 PR 已准备好合并，请输入 `/approve`。 -- [快速批阅](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+)：对于针对 master 分支的小规模 PR，可以快速审阅。 - 在浏览 PR 时，可以注意到 size 标签为 "XS" 的 PRs。 -- [非 master 分支的 PR](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster)： - 如果 PR 针对 `dev-` 分支，则表示它适用于即将发布的版本。请添加带有 `/assign @<负责人的 github 账号>` 的注释，确保[发行版本负责人](https://github.com/kubernetes/sig-release/tree/master/release-team)注意到该 PR。如果 PR 是针对旧分支，请帮助 PR 作者确定是否所针对的是最合适的分支。 - - -### 什么时候关闭 PR - -审查和批准是缩短和更新我们的 PR 队列的一种方式；另一种方式是关闭 PR。 - - -- 关闭两个星期未签署 CLA 的 PR。 - PR 作者可以在签署 CLA 后重新打开 PR，因此这是确保未签署 CLA 的 PR 不会被合并的一种风险较低的方法。 - -- 如果作者在两周或更长时间内未回复评论或反馈，请关闭 PR。 - -不要害怕关闭 PR。贡献者可以轻松地重新打开并继续工作。通常，关闭通知会激励作者继续完成其贡献。 - -要关闭 PR，请在 PR 上输入 `/close`。 - - - -{{< note >}} -一项名为 [`fejta-bot`](https://github.com/fejta-bot) 的自动服务会在 Issue 停滞 90 -天后自动将其标记为过期；然后再等 30 天，如果仍然无人过问，则将其关闭。 -PR 管理者应该在 issues 处于无人过问状态 14-30 天后关闭它们。 -{{< /note >}} - + + + +SIG Docs 的[批准人（Approvers）](/zh/docs/contribute/participating/#approvers)们每周轮流负责 +[管理仓库的 PRs](https://github.com/kubernetes/website/wiki/PR-Wranglers)。 + +本节介绍 PR 管理者的职责。关于如何提供较好的评审意见，可参阅 +[评审变更](/zh/docs/contribute/review/). + + + + +## 职责 {#duties} +在为期一周的轮值期内，PR 管理者要： + +- 每天对新增的 Issues 判定和打标签。参见 + [对 Issues 进行判定和分类](/zh/docs/contribute/review/for-approvers/#triage-and-categorize-issues) + 以了解 SIG Docs 如何使用元数据的详细信息。 +- 检查[悬决的 PR](https://github.com/kubernetes/website/pulls) 的质量并确保它们符合 + [样式指南](/zh/docs/contribute/style/style-guide/)和 + [内容指南](/zh/docs/contribute/style/content-guide/)要求。 + + - 首先查看最小的 PR（`size/XS`），然后逐渐扩展到最大的 + PR（`size/XXL`），尽可能多地评审 PR。 +- 确保贡献者完成 [CLA](https://github.com/kubernetes/community/blob/master/CLA.md) 签署。 + - 使用[此脚本](https://github.com/zparnold/k8s-docs-pr-botherer)自动提醒尚未签署 + CLA 的贡献者签署 CLA。 +- 针对提供提供反馈，请求其他 SIG 的成员进行技术审核。 + - 为 PR 所建议的内容更改提供就地反馈。 + - 如果您需要验证内容，请在 PR 上发表评论并要求贡献者提供更多细节。 + - 设置相关的 `sig/` 标签。 + - 如果需要，从文件开头的 `reviewers:` 块中指派评阅人。 +- 使用 `/approve` 评论来批准可以合并的 PR，在 PR 就绪时将其合并。 + - PR 在被合并之前，应该有来自其他成员的 `/lgtm` 评论。 + - 可以考虑接受那些技术上准确，但文风上不满足 + [风格指南](/zh/docs/contribute/style/style-guide/)要求的 PR。 + 可以登记一个新的 Issue 来解决文档风格问题，并将其标记为 `good first issue`。 + + +### 对于管理人有用的 GitHub 查询 + +执行管理操作时，以下查询很有用。完成以下这些查询后，剩余的要审阅的 PR 列表通常很小。 +这些查询都不包含本地化的 PR，并仅包含主分支上的 PR（除了最后一个查询）。 + + +- [未签署 CLA，不可合并的 PR](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen)： + 提醒贡献者签署 CLA。如果机器人和审阅者都已经提醒他们，请关闭 PR，并提醒他们在签署 CLA 后可以重新提交。 + **在作者没有签署 CLA 之前，不要审阅他们的 PR！** + +- [需要 LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+)： + 列举需要来自成员的 LGTM 评论的 PR。 + 如果需要技术审查，请告知机器人所建议的审阅者。 + 如果 PR 继续改进，就地提供更改建议或反馈。 +- [已有 LGTM标签，需要 Docs 团队批准](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm)： + 列举需要 `/approve` 评论来合并的 PR。 +- [快速批阅](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+)： + 列举针对主分支的、没有明确合并障碍的 PR。 + 在浏览 PR 时，可以将 "XS" 尺寸标签更改为 "S"、"M"、"L"、"XL"、"XXL"。 +- [非主分支的 PR](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster)： + 如果 PR 针对 `dev-` 分支，则表示它适用于即将发布的版本。 + 请添加带有 `/assign @<负责人的 github 账号>`，将其指派给 + [发行版本负责人](https://github.com/kubernetes/sig-release/tree/master/release-team)。 + 如果 PR 是针对旧分支，请帮助 PR 作者确定是否所针对的是最合适的分支。 + + +### 何时关闭 PR {#when-to-close-pull-requests} + +审查和批准是缩短和更新我们的 PR 队列的一种方式；另一种方式是关闭 PR。 + +当以下条件满足时，可以关闭 PR： + +- 作者两周内未签署 CLA。 + PR 作者可以在签署 CLA 后重新打开 PR，因此这是确保未签署 CLA 的 PR 不会被合并的一种风险较低的方法。 + +- 作者在两周或更长时间内未回复评论或反馈。 + +不要害怕关闭 PR。贡献者可以轻松地重新打开并继续工作。 +通常，关闭通知会激励作者继续完成其贡献。 + +要关闭 PR，请在 PR 上输入 `/close` 评论。 + + +{{< note >}} +一个名为 [`fejta-bot`](https://github.com/fejta-bot) 的自动服务会在 Issue 停滞 90 +天后自动将其标记为过期；然后再等 30 天，如果仍然无人过问，则将其关闭。 +PR 管理者应该在 issues 处于无人过问状态 14-30 天后关闭它们。 +{{< /note >}} + diff --git a/content/zh/docs/contribute/participate/roles-and-responsibilties.md b/content/zh/docs/contribute/participate/roles-and-responsibilties.md index 313c1ff5a4..5fa2a43832 100644 --- a/content/zh/docs/contribute/participate/roles-and-responsibilties.md +++ b/content/zh/docs/contribute/participate/roles-and-responsibilties.md @@ -133,7 +133,7 @@ After submitting at least 5 substantial pull requests and meeting the other [req 2. Open a GitHub issue in the [`kubernetes/org`](https://github.com/kubernetes/org/) repository. Use the **Organization Membership Request** issue template. --> 1. 找到两个[评审人](#reviewers)或[批准人](#approvers)为你的成员身份提供 - [担保](/docs/contribute/advanced#sponsor-a-new-contributor)。 + [担保](/zh/docs/contribute/advanced#sponsor-a-new-contributor)。 通过 [Kubernetes Slack 上的 #sig-docs 频道](https://kubernetes.slack.com) 或者 [SIG Docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) @@ -277,7 +277,8 @@ in the `kubernetes/website` repository. 2. Assign the PR to one or more SIG-Docs approvers (user names listed under `sig-docs-{language}-owners`). -If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests. +If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, +[@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests. --> 1. 发起 PR，将你的 GitHub 用户名添加到 `kubernetes/website` 仓库中 [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) @@ -291,7 +292,7 @@ If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added 下列举的用户名）。 请求被批准之后，SIG Docs Leads 之一会将你添加到合适的 GitHub 团队。 -一旦添加完成， [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) +一旦添加完成， [@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) 会在处理未来的 PR 时，将 PR 指派给你或者建议你来评审某 PR。 +- 阅读[管理 PR](/zh/docs/contribute/participate/pr-wranglers/)，了解所有批准人轮值的一个角色。 + From e6274238373ce40367bef96ba9ee9ae6bf4c1594 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sun, 26 Jul 2020 22:20:37 +0800 Subject: [PATCH 69/86] [zh] Sync blog post guide This PR syncs the changes made in 22176 into Chinese localization. --- .../new-content/blogs-case-studies.md | 202 ++++++++++++++---- .../zh/docs/contribute/style/content-guide.md | 2 +- 2 files changed, 160 insertions(+), 44 deletions(-) diff --git a/content/zh/docs/contribute/new-content/blogs-case-studies.md b/content/zh/docs/contribute/new-content/blogs-case-studies.md index 6a77064953..3df67c02d9 100644 --- a/content/zh/docs/contribute/new-content/blogs-case-studies.md +++ b/content/zh/docs/contribute/new-content/blogs-case-studies.md @@ -22,63 +22,181 @@ Case studies require extensive review before they're approved. 案例分析则在被批准之前需要更多的评阅。 + -## 撰写博文 {#write-a-blog-post} +## Kubernetes 博客 -博客内容不可以是销售用语。 -其中的内容必须是对整个 Kubernetes 社区中很多人都有参考意义。 -SIG Docs [blog 子项目](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject) -负责管理博客的评阅过程。 +Kubernetes 博客用于项目发布新功能特性、社区报告以及其他一些可能对整个社区 +很重要的新闻。 +其读者包括最终用户和开发人员。 +大多数博客的内容是关于核心项目中正在发生的事情，不过我们也鼓励你提交一些 +关于生态系统中其他地方发生的事情的博客。 + +任何人都可以撰写博客并提交评阅。 + + +### 指导原则和期望 {#guidelines-and-expectations} + +- 博客内容不可以是销售用语。 + - 文章内容必须是对整个 Kubernetes 社区中很多人都有参考意义。 + 例如，所提交的文章应该关注上游的 Kubernetes 项目本身，而不是某个厂商特定的配置。 + 请参阅[文档风格指南](/zh/docs/contribute/style/content-guide/#what-s-allowed) + 以了解哪些内容是 Kubernetes 所允许的。 + - 链接应该主要指向官方的 Kubernetes 文档。 + 当引用外部信息时，链接应该是多样的。 + 例如，所提交的博客文章中不可以只包含指向某个公司的博客的链接。 + - 有些时候，这是一个比较棘手的权衡过程。 + [博客团队](https://kubernetes.slack.com/messages/sig-docs-blog/)的存在目的即是为 + Kubernetes 博客提供文章是否合适的指导意见。 + 所以，需要帮助的时候不要犹豫。 + +- 博客内容并非在某特定日期发表。 + - 文章会交由社区自愿者评阅。我们会尽力满足特定的时限要求，只是无法就此作出承诺。 + - Kubernetes 项目的很多核心组件会在发布窗口期内提交博客文章，导致发表时间被推迟。 + 因此，请考虑在发布周期内较为平静的时间段提交博文。 + - 如果你希望就博文发表日期上进行较大范围的协调，请联系 + [CNCF 推广团队](https://www.cncf.io/about/contact/)。 + 这也许是比提交博客文章更合适的一种选择。 + - 有时，博客的评审可能会堆积起来。如果你觉得你的文章没有引起该有的重视， + 你可以通过[此 Slack 频道](https://kubernetes.slack.com/messages/sig-docs-blog/) + 联系博客团队，以获得实时反馈。 + +- 博客内容应该对 Kubernetes 用户有用。 + - 与参与 Kubernetes SIGs 活动相关，或者与这类活动的结果相关的主题通常是切题的。 + 请参考[上游推广团队](https://github.com/kubernetes/community/blob/master/communication/marketing-team/blog-guidelines.md#upstream-marketing-blog-guidelines)的工作以获得对此类博文的支持。 + - Kubernetes 的组件都有意设计得模块化，因此使用类似 CNI、CSI 等集成点的工具 + 通常都是切题的。 + - 关于其他 CNCF 项目的博客可能切题也可能不切题。 + 我们建议你在提交草稿之前与博客团队联系。 + - 很多 CNCF 项目有自己的博客。这些博客通常是更好的选择。 + 有些时候，某个 CNCF 项目的主要功能特性或者里程碑的变化可能是用户有兴趣在 + Kubernetes 博客上阅读的内容。 + +- 博客文章应该是原创内容。 + - 官方博客的目的不是将某第三方已发表的内容重新作为新内容发表。 + - 博客的[授权协议](https://github.com/kubernetes/website/blob/master/LICENSE) + 的确允许出于商业目的来使用博客内容；但并不是所有可以商用的内容都适合在这里发表。 +- 博客文章的内容应该在一段时间内不过期。 + - 考虑到项目的开发速度，我们希望读者看到的是不必更新就能保持长期准确的内容。 + - 有时候，在官方文档中添加一个教程或者进行内容更新都是比博客更好的选择。 + - 可以考虑在博客文章中将较长技术内容的重点放在鼓励读者自行尝试上，或者 + 放在问题域本身或者为什么读者应该关注某个话题上。 + + +### 提交博客的技术考虑 + +所提交的内容应该是 Markdown 格式的，以便能够被[Hugo](https://gohugo.io/) 生成器来处理。 +关于如何使用相关技术，有[很多可用的资源](https://gohugo.io/documentation/)。 + +我们知道这一需求可能给那些对此过程不熟悉的朋友们带来不便， +我们也一直在寻找降低难度的解决方案。 +如果你有降低难度的好主意，请自荐帮忙。 + + +SIG Docs [博客子项目](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject) 负责管理博客的评阅过程。 更多信息可参考[提交博文](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post)。 + +要提交博文，你可以遵从以下指南： -要提交博文，你可以： - -- 使用 [Kubernetes 博客提交表单](https://docs.google.com/forms/d/e/1FAIpQLSdMpMoSIrhte5omZbTE7nB84qcGBy8XnnXhDFoW0h7p2zwXrw/viewform) -- [发起一个包含博文的 PR](/zh/docs/contribute/new-content/new-content/#fork-the-repo)。 +- [发起一个包含博文的 PR](/zh/docs/contribute/new-content/open-a-pr/#fork-the-repo)。 新博文要创建于 [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts) 目录下。 -如果你要发起一个 PR，请确保所提交的博文遵从正确的命名规范和前言信息： +- 确保你的博文遵从合适的命名规范，并带有下面的引言（元数据）信息： -- Markdown 文件名必须遵从 `YYY-MM-DD-Your-Title-Here.md` 格式。 - 例如，`2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md`. -- 前言部分必须包含以下内容： + - Markdown 文件名必须符合格式 `YYYY-MM-DD-Your-Title-Here.md`。 + 例如，`2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md`。 + - **不要**在文件名中包含多余的句点。类似 `2020-01-01-whats-new-in-1.19.md` + 这类文件名会导致文件无法正确打开。 + - 引言部分必须包含以下内容： + ```yaml + --- + layout: blog + title: "Your Title Here" + date: YYYY-MM-DD + slug: text-for-URL-link-here-no-spaces + --- + ``` -```yaml ---- -layout: blog -title: "博文标题" -date: YYYY-MM-DD -slug: text-for-URL-link-here-no-spaces ---- -``` + - 第一个或者最初的提交的描述信息中应该包含一个所作工作的简单摘要， + 并作为整个博文的一个独立描述。 + 请注意，对博文的后续修改编辑都会最终合并到此主提交中，所以此提交的描述信息 + 应该尽量有用。 + - 较好的提交消息（Commit Message）示例： + - _Add blog post on the foo kubernetes feature_ + - _blog: foobar announcement_ + - 较差的提交消息示例： + - _Add blog post_ + - _._ + - _initial commit_ + - _draft post_ + - 博客团队会对 PR 内容进行评阅，为你提供一些评语以便修订。 + 之后，机器人会将你的博文合并并发表。 - ## 控制平面组件（Control Plane Components） - 控制平面的组件对集群做出全局决策(比如调度)，以及检测和响应集群事件（例如，当不满足部署的 `replicas` 字段时，启动新的 {{< glossary_tooltip text="pod" term_id="pod">}}）。 - -##容器运行时 +## 容器运行时 {{< glossary_definition term_id="container-runtime" length="all" >}} From d9f1580ff6b4a9ca764cb6bfda699960d00fb1df Mon Sep 17 00:00:00 2001 From: GoodGameZoo Date: Sun, 26 Jul 2020 20:02:40 -0700 Subject: [PATCH 77/86] Update concepts/architecture/_index.md --- content/zh/docs/concepts/architecture/_index.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/content/zh/docs/concepts/architecture/_index.md b/content/zh/docs/concepts/architecture/_index.md index a68ed48a45..5e707ed397 100755 --- a/content/zh/docs/concepts/architecture/_index.md +++ b/content/zh/docs/concepts/architecture/_index.md @@ -1,4 +1,6 @@ --- title: "Kubernetes 架构" weight: 30 +description: > + Kubernetes 背后的架构概念。 --- From c80c9c40c11ef0e9b299ef5d7cae8ebe54240e77 Mon Sep 17 00:00:00 2001 From: Cweiping Date: Mon, 27 Jul 2020 11:16:16 +0800 Subject: [PATCH 78/86] fix page configure-multiple-schedulers/#enable-leader-election style error (#22642) * fix https://kubernetes.io/docs/tasks/extend-kubernetes/configure-multiple-schedulers/#enable-leader-election style error Signed-off-by: Weiping Cai * fix https://kubernetes.io/docs/tasks/extend-kubernetes/configure-multiple-schedulers/#enable-leader-election style error Signed-off-by: Weiping Cai --- .../configure-multiple-schedulers.md | 41 +------------------ .../en/examples/admin/sched/clusterrole.yaml | 37 +++++++++++++++++ 2 files changed, 39 insertions(+), 39 deletions(-) create mode 100644 content/en/examples/admin/sched/clusterrole.yaml diff --git a/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md b/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md index 4afbee21c8..b14777111e 100644 --- a/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md +++ b/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md @@ -129,45 +129,8 @@ If RBAC is enabled on your cluster, you must update the `system:kube-scheduler` ``` kubectl edit clusterrole system:kube-scheduler ``` -```yaml -apiVersion: rbac.authorization.k8s.io/v1 -kind: ClusterRole -metadata: - annotations: - rbac.authorization.kubernetes.io/autoupdate: "true" - labels: - kubernetes.io/bootstrapping: rbac-defaults - name: system:kube-scheduler -rules: -- apiGroups: - - coordination.k8s.io - resources: - - leases - verbs: - - create -- apiGroups: - - coordination.k8s.io - resourceNames: - - kube-scheduler - - my-scheduler - resources: - - leases - verbs: - - get - - update -- apiGroups: - - "" - resourceNames: - - kube-scheduler - - my-scheduler - resources: - - endpoints - verbs: - - delete - - get - - patch - - update -``` + +{{< codenew file="admin/sched/clusterrole.yaml" >}} ## Specify schedulers for pods diff --git a/content/en/examples/admin/sched/clusterrole.yaml b/content/en/examples/admin/sched/clusterrole.yaml new file mode 100644 index 0000000000..554b8659db --- /dev/null +++ b/content/en/examples/admin/sched/clusterrole.yaml @@ -0,0 +1,37 @@ +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + annotations: + rbac.authorization.kubernetes.io/autoupdate: "true" + labels: + kubernetes.io/bootstrapping: rbac-defaults + name: system:kube-scheduler +rules: + - apiGroups: + - coordination.k8s.io + resources: + - leases + verbs: + - create + - apiGroups: + - coordination.k8s.io + resourceNames: + - kube-scheduler + - my-scheduler + resources: + - leases + verbs: + - get + - update + - apiGroups: + - "" + resourceNames: + - kube-scheduler + - my-scheduler + resources: + - endpoints + verbs: + - delete + - get + - patch + - update From 49eee8fd3d9eba5e7390c9014ac05d036ced3ca6 Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Mon, 27 Jul 2020 04:18:16 +0100 Subject: [PATCH 79/86] Revise Pod concept (#22603) * Revise Pod concept Adapt the existing Pod documentation to suit the Docsy theme, by promoting the Pod concept itself to /docs/concepts/workloads/pods/ Following on from this, update the Pod Lifecycle page to cover the lifecycle of a Pod and follow on directly from the Pod concept, for readers keen to understand things in detail. This change also removes the automatic contents list from the Pod overview page. Instead, the new page links to all the pages inside the Pod section. * Update links to Pod concept Link to updated content * Incorporate Pod concept suggestions Co-authored-by: Celeste Horgan * Revise StatefulSet suggestion for Pod concept Co-authored-by: Celeste Horgan Co-authored-by: Celeste Horgan --- .../cluster-administration/networking.md | 2 +- .../configuration/pod-priority-preemption.md | 4 +- .../containers/container-lifecycle-hooks.md | 2 +- .../kubernetes-objects.md | 2 +- .../workloads/controllers/daemonset.md | 2 +- .../workloads/controllers/deployment.md | 9 +- .../concepts/workloads/controllers/job.md | 2 +- .../controllers/replicationcontroller.md | 2 +- .../en/docs/concepts/workloads/pods/_index.md | 268 +++++++- .../concepts/workloads/pods/disruptions.md | 66 +- .../concepts/workloads/pods/pod-lifecycle.md | 630 +++++++++--------- .../concepts/workloads/pods/pod-overview.md | 123 ---- .../pods/pod-topology-spread-constraints.md | 2 +- .../en/docs/concepts/workloads/pods/pod.md | 209 ------ .../docs/concepts/workloads/pods/podpreset.md | 51 +- content/en/docs/reference/glossary/pod.md | 2 +- .../windows/intro-windows-in-kubernetes.md | 4 +- .../service-access-application-cluster.md | 11 +- .../namespaces-walkthrough.md | 2 +- .../tasks/administer-cluster/namespaces.md | 2 +- .../administer-cluster/safely-drain-node.md | 2 +- .../attach-handler-lifecycle-event.md | 2 +- .../configure-pod-container/static-pod.md | 2 +- .../debug-pod-replication-controller.md | 3 +- .../run-application/delete-stateful-set.md | 2 +- .../force-delete-stateful-set-pod.md | 2 +- content/en/docs/tutorials/hello-minikube.md | 2 +- .../deploy-app/deploy-interactive.html | 2 +- .../expose/expose-intro.html | 2 +- .../expose-external-ip-address.md | 10 +- static/_redirects | 16 +- 31 files changed, 704 insertions(+), 736 deletions(-) mode change 100755 => 100644 content/en/docs/concepts/workloads/pods/_index.md delete mode 100644 content/en/docs/concepts/workloads/pods/pod-overview.md delete mode 100644 content/en/docs/concepts/workloads/pods/pod.md diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md index 29044be250..6779ee984a 100644 --- a/content/en/docs/concepts/cluster-administration/networking.md +++ b/content/en/docs/concepts/cluster-administration/networking.md @@ -12,7 +12,7 @@ understand exactly how it is expected to work. There are 4 distinct networking problems to address: 1. Highly-coupled container-to-container communications: this is solved by - [pods](/docs/concepts/workloads/pods/pod/) and `localhost` communications. + {{< glossary_tooltip text="Pods" term_id="pod" >}} and `localhost` communications. 2. Pod-to-Pod communications: this is the primary focus of this document. 3. Pod-to-Service communications: this is covered by [services](/docs/concepts/services-networking/service/). 4. External-to-Service communications: this is covered by [services](/docs/concepts/services-networking/service/). diff --git a/content/en/docs/concepts/configuration/pod-priority-preemption.md b/content/en/docs/concepts/configuration/pod-priority-preemption.md index 9bfc514257..295a029d90 100644 --- a/content/en/docs/concepts/configuration/pod-priority-preemption.md +++ b/content/en/docs/concepts/configuration/pod-priority-preemption.md @@ -255,7 +255,7 @@ makes Pod P eligible to preempt Pods on another Node. #### Graceful termination of preemption victims When Pods are preempted, the victims get their -[graceful termination period](/docs/concepts/workloads/pods/pod/#termination-of-pods). +[graceful termination period](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination). They have that much time to finish their work and exit. If they don't, they are killed. This graceful termination period creates a time gap between the point that the scheduler preempts Pods and the time when the pending Pod (P) can be @@ -268,7 +268,7 @@ priority Pods to zero or a small number. #### PodDisruptionBudget is supported, but not guaranteed -A [Pod Disruption Budget (PDB)](/docs/concepts/workloads/pods/disruptions/) +A [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) (PDB) allows application owners to limit the number of Pods of a replicated application that are down simultaneously from voluntary disruptions. Kubernetes supports PDB when preempting Pods, but respecting PDB is best effort. The scheduler tries diff --git a/content/en/docs/concepts/containers/container-lifecycle-hooks.md b/content/en/docs/concepts/containers/container-lifecycle-hooks.md index 386e4d00bb..c8e93e93db 100644 --- a/content/en/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/en/docs/concepts/containers/container-lifecycle-hooks.md @@ -42,7 +42,7 @@ so it must complete before the call to delete the container can be sent. No parameters are passed to the handler. A more detailed description of the termination behavior can be found in -[Termination of Pods](/docs/concepts/workloads/pods/pod/#termination-of-pods). +[Termination of Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination). ### Hook handler implementations diff --git a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 1f4f4e7509..ab447cdcd6 100644 --- a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -92,7 +92,7 @@ and the `spec` format for a Deployment can be found in ## {{% heading "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 the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/). * Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes diff --git a/content/en/docs/concepts/workloads/controllers/daemonset.md b/content/en/docs/concepts/workloads/controllers/daemonset.md index 7f1b5c4630..c3d8cf36d8 100644 --- a/content/en/docs/concepts/workloads/controllers/daemonset.md +++ b/content/en/docs/concepts/workloads/controllers/daemonset.md @@ -60,7 +60,7 @@ A DaemonSet also needs a [`.spec`](https://git.k8s.io/community/contributors/dev The `.spec.template` is one of the required fields in `.spec`. -The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [Pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`. +The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`. In addition to required fields for a Pod, a Pod template in a DaemonSet has to specify appropriate labels (see [pod selector](#pod-selector)). diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md index 82f0d7b060..2c2fd8c7c2 100644 --- a/content/en/docs/concepts/workloads/controllers/deployment.md +++ b/content/en/docs/concepts/workloads/controllers/deployment.md @@ -13,8 +13,8 @@ weight: 30 -A _Deployment_ provides declarative updates for [Pods](/docs/concepts/workloads/pods/pod/) and -[ReplicaSets](/docs/concepts/workloads/controllers/replicaset/). +A _Deployment_ provides declarative updates for {{< glossary_tooltip text="Pods" term_id="pod" >}} +{{< glossary_tooltip term_id="replica-set" text="ReplicaSets" >}}. You describe a _desired state_ in a Deployment, and the Deployment {{< glossary_tooltip term_id="controller" >}} changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments. @@ -23,8 +23,6 @@ Do not manage ReplicaSets owned by a Deployment. Consider opening an issue in th {{< /note >}} - - ## Use Case @@ -1053,8 +1051,7 @@ A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contrib The `.spec.template` and `.spec.selector` are the only required field of the `.spec`. -The `.spec.template` is a [Pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [Pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an -`apiVersion` or `kind`. +The `.spec.template` is a [Pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`. In addition to required fields for a Pod, a Pod template in a Deployment must specify appropriate labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See [selector](#selector)). diff --git a/content/en/docs/concepts/workloads/controllers/job.md b/content/en/docs/concepts/workloads/controllers/job.md index 21e8aceb64..81c1280943 100644 --- a/content/en/docs/concepts/workloads/controllers/job.md +++ b/content/en/docs/concepts/workloads/controllers/job.md @@ -122,7 +122,7 @@ A Job also needs a [`.spec` section](https://git.k8s.io/community/contributors/d The `.spec.template` is the only required field of the `.spec`. -The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [pod](/docs/user-guide/pods), except it is nested and does not have an `apiVersion` or `kind`. +The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`. In addition to required fields for a Pod, a pod template in a Job must specify appropriate labels (see [pod selector](#pod-selector)) and an appropriate restart policy. diff --git a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md index 2cc8284940..d59c09fc6b 100644 --- a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md @@ -126,7 +126,7 @@ A ReplicationController also needs a [`.spec` section](https://git.k8s.io/commun The `.spec.template` is the only required field of the `.spec`. -The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`. +The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`. In addition to required fields for a Pod, a pod template in a ReplicationController must specify appropriate labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See [pod selector](#pod-selector). diff --git a/content/en/docs/concepts/workloads/pods/_index.md b/content/en/docs/concepts/workloads/pods/_index.md old mode 100755 new mode 100644 index a105f18fb3..c7408721b7 --- a/content/en/docs/concepts/workloads/pods/_index.md +++ b/content/en/docs/concepts/workloads/pods/_index.md @@ -1,5 +1,271 @@ --- -title: "Pods" +reviewers: +- erictune +title: Pods +content_type: concept weight: 10 +no_list: true +card: + name: concepts + weight: 60 --- + + +_Pods_ are the smallest deployable units of computing that you can create and manage in Kubernetes. + +A _Pod_ (as in a pod of whales or pea pod) is a group of one or more +{{< glossary_tooltip text="containers" term_id="container" >}}, with shared storage/network resources, and a specification +for how to run the containers. A Pod's contents are always co-located and +co-scheduled, and run in a shared context. A Pod models an +application-specific "logical host": it contains one or more application +containers which are relatively tightly coupled. +In non-cloud contexts, applications executed on the same physical or virtual machine are analogous to cloud applications executed on the same logical host. + +As well as application containers, a Pod can contain +[init containers](/docs/concepts/workloads/pods/init-containers/) that run +during Pod startup. You can also inject +[ephemeral containers](/docs/concepts/workloads/pods/ephemeral-containers/) +for debugging if your cluster offers this. + + + +## What is a Pod? + +{{< note >}} +While Kubernetes supports more +{{< glossary_tooltip text="container runtimes" term_id="container-runtime" >}} +than just Docker, [Docker](https://www.docker.com/) is the most commonly known +runtime, and it helps to describe Pods using some terminology from Docker. +{{< /note >}} + +The shared context of a Pod is a set of Linux namespaces, cgroups, and +potentially other facets of isolation - the same things that isolate a Docker +container. Within a Pod's context, the individual applications may have +further sub-isolations applied. + +In terms of Docker concepts, a Pod is similar to a group of Docker containers +with shared namespaces and shared filesystem volumes. + +## Using Pods + +Usually you don't need to create Pods directly, even singleton Pods. Instead, create them using workload resources such as {{< glossary_tooltip text="Deployment" +term_id="deployment" >}} or {{< glossary_tooltip text="Job" term_id="job" >}}. +If your Pods need to track state, consider the +{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} resource. + +Pods in a Kubernetes cluster are used in two main ways: + +* **Pods that run a single container**. The "one-container-per-Pod" model is the + most common Kubernetes use case; in this case, you can think of a Pod as a + wrapper around a single container; Kubernetes manages Pods rather than managing + the containers directly. +* **Pods that run multiple containers that need to work together**. A Pod can + encapsulate an application composed of multiple co-located containers that are + tightly coupled and need to share resources. These co-located containers + form a single cohesive unit of service—for example, one container serving data + stored in a shared volume to the public, while a separate _sidecar_ container + refreshes or updates those files. + The Pod wraps these containers, storage resources, and an ephemeral network + identity together as a single unit. + + {{< note >}} + Grouping multiple co-located and co-managed containers in a single Pod is a + relatively advanced use case. You should use this pattern only in specific + instances in which your containers are tightly coupled. + {{< /note >}} + +Each Pod is meant to run a single instance of a given application. If you want to +scale your application horizontally (to provide more overall resources by running +more instances), you should use multiple Pods, one for each instance. In +Kubernetes, this is typically referred to as _replication_. +Replicated Pods are usually created and managed as a group by a workload resource +and its {{< glossary_tooltip text="controller" term_id="controller" >}}. + +See [Pods and controllers](#pods-and-controllers) for more information on how +Kubernetes uses workload resources, and their controllers, to implement application +scaling and auto-healing. + +### How Pods manage multiple containers + +Pods are designed to support multiple cooperating processes (as containers) that form +a cohesive unit of service. The containers in a Pod are automatically co-located and +co-scheduled on the same physical or virtual machine in the cluster. The containers +can share resources and dependencies, communicate with one another, and coordinate +when and how they are terminated. + +For example, you might have a container that +acts as a web server for files in a shared volume, and a separate "sidecar" container +that updates those files from a remote source, as in the following diagram: + +{{< figure src="/images/docs/pod.svg" alt="example pod diagram" width="50%" >}} + +Some Pods have {{< glossary_tooltip text="init containers" term_id="init-container" >}} as well as {{< glossary_tooltip text="app containers" term_id="app-container" >}}. Init containers run and complete before the app containers are started. + +Pods natively provide two kinds of shared resources for their constituent containers: +[networking](#pod-networking) and [storage](#pod-storage). + +## Working with Pods + +You'll rarely create individual Pods directly in Kubernetes—even singleton Pods. This +is because Pods are designed as relatively ephemeral, disposable entities. When +a Pod gets created (directly by you, or indirectly by a +{{< glossary_tooltip text="controller" term_id="controller" >}}), the new Pod is +scheduled to run on a {{< glossary_tooltip term_id="node" >}} in your cluster. +The Pod remains on that node until the Pod finishes execution, the Pod object is deleted, +the Pod is *evicted* for lack of resources, or the node fails. + +{{< note >}} +Restarting a container in a Pod should not be confused with restarting a Pod. A Pod +is not a process, but an environment for running container(s). A Pod persists until +it is deleted. +{{< /note >}} + +When you create the manifest for a Pod object, make sure the name specified is a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). + +### Pods and controllers + +You can use workload resources to create and manage multiple Pods for you. A controller +for the resource handles replication and rollout and automatic healing in case of +Pod failure. For example, if a Node fails, a controller notices that Pods on that +Node have stopped working and creates a replacement Pod. The scheduler places the +replacement Pod onto a healthy Node. + +Here are some examples of workload resources that manage one or more Pods: + +* {{< glossary_tooltip text="Deployment" term_id="deployment" >}} +* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} +* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}} + +### Pod templates + +Controllers for {{< glossary_tooltip text="workload" term_id="workload" >}} resources create Pods +from a _pod template_ and manage those Pods on your behalf. + +PodTemplates are specifications for creating Pods, and are included in workload resources such as +[Deployments](/docs/concepts/workloads/controllers/deployment/), +[Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and +[DaemonSets](/docs/concepts/workloads/controllers/daemonset/). + +Each controller for a workload resource uses the `PodTemplate` inside the workload +object to make actual Pods. The `PodTemplate` is part of the desired state of whatever +workload resource you used to run your app. + +The sample below is a manifest for a simple Job with a `template` that starts one +container. The container in that Pod prints a message then pauses. + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: hello +spec: + template: + # This is the pod template + spec: + containers: + - name: hello + image: busybox + command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600'] + restartPolicy: OnFailure + # The pod template ends here +``` + +Modifying the pod template or switching to a new pod template has no effect on the +Pods that already exist. Pods do not receive template updates directly. Instead, +a new Pod is created to match the revised pod template. + +For example, the deployment controller ensures that the running Pods match the current +pod template for each Deployment object. If the template is updated, the Deployment has +to remove the existing Pods and create new Pods based on the updated template. Each workload +resource implements its own rules for handling changes to the Pod template. + +On Nodes, the {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} does not +directly observe or manage any of the details around pod templates and updates; those +details are abstracted away. That abstraction and separation of concerns simplifies +system semantics, and makes it feasible to extend the cluster's behavior without +changing existing code. + +## Resource sharing and communication + +Pods enable data sharing and communication among their constituent +containters. + +### Storage in Pods {#pod-storage} + +A Pod can specify a set of shared storage +{{< glossary_tooltip text="volumes" term_id="volume" >}}. All containers +in the Pod can access the shared volumes, allowing those containers to +share data. Volumes also allow persistent data in a Pod to survive +in case one of the containers within needs to be restarted. See +[Storage](/docs/concepts/storage/) for more information on how +Kubernetes implements shared storage and makes it available to Pods. + +### Pod networking + +Each Pod is assigned a unique IP address for each address family. Every +container in a Pod shares the network namespace, including the IP address and +network ports. Inside a Pod (and **only** then), the containers that belong to the Pod +can communicate with one another using `localhost`. When containers in a Pod communicate +with entities *outside the Pod*, +they must coordinate how they use the shared network resources (such as ports). +Within a Pod, containers share an IP address and port space, and +can find each other via `localhost`. The containers in a Pod can also communicate +with each other using standard inter-process communications like SystemV semaphores +or POSIX shared memory. Containers in different Pods have distinct IP addresses +and can not communicate by IPC without +[special configuration](/docs/concepts/policy/pod-security-policy/). +Containers that want to interact with a container running in a different Pod can +use IP networking to comunicate. + +Containers within the Pod see the system hostname as being the same as the configured +`name` for the Pod. There's more about this in the [networking](/docs/concepts/cluster-administration/networking/) +section. + +## Privileged mode for containers + +Any container in a Pod can enable privileged mode, using the `privileged` flag on the [security context](/docs/tasks/configure-pod-container/security-context/) of the container spec. This is useful for containers that want to use operating system administrative capabilities such as manipulating the network stack or accessing hardware devices. +Processes within a privileged container get almost the same privileges that are available to processes outside a container. + +{{< note >}} +Your {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} must support the concept of a privileged container for this setting to be relevant. +{{< /note >}} + +## Static Pods + +_Static Pods_ are managed directly by the kubelet daemon on a specific node, +without the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} +observing them. +Whereas most Pods are managed by the control plane (for example, a +{{< glossary_tooltip text="Deployment" term_id="deployment" >}}), for static +Pods, the kubelet directly supervises each static Pod (and restarts it if it fails). + +Static Pods are always bound to one {{< glossary_tooltip term_id="kubelet" >}} on a specific node. +The main use for static Pods is to run a self-hosted control plane: in other words, +using the kubelet to supervise the individual [control plane components](/docs/concepts/overview/components/#control-plane-components). + +The kubelet automatically tries to create a {{< glossary_tooltip text="mirror Pod" term_id="mirror-pod" >}} +on the Kubernetes API server for each static Pod. +This means that the Pods running on a node are visible on the API server, +but cannot be controlled from there. + +## {{% heading "whatsnext" %}} + +* Learn about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/). +* Learn about [PodPresets](/docs/concepts/workloads/pods/podpreset/). +* Lean about [RuntimeClass](/docs/concepts/containers/runtime-class/) and how you can use it to + configure different Pods with different container runtime configurations. +* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/). +* Read about [PodDisruptionBudget](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions. +* Pod is a top-level resource in the Kubernetes REST API. + The [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) + object definition describes the object in detail. +* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container. + +To understand the context for why Kubernetes wraps a common Pod API in other resources (such as {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} or {{< glossary_tooltip text="Deployments" term_id="deployment" >}}, you can read about the prior art, including: + * [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema) + * [Borg](https://research.google.com/pubs/pub43438.html) + * [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html) + * [Omega](https://research.google/pubs/pub41684/) + * [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/). diff --git a/content/en/docs/concepts/workloads/pods/disruptions.md b/content/en/docs/concepts/workloads/pods/disruptions.md index 589bde5668..0810b6fec7 100644 --- a/content/en/docs/concepts/workloads/pods/disruptions.md +++ b/content/en/docs/concepts/workloads/pods/disruptions.md @@ -11,17 +11,15 @@ weight: 60 This guide is for application owners who want to build highly available applications, and thus need to understand -what types of Disruptions can happen to Pods. +what types of disruptions can happen to Pods. -It is also for Cluster Administrators who want to perform automated +It is also for cluster administrators who want to perform automated cluster actions, like upgrading and autoscaling clusters. - - -## Voluntary and Involuntary Disruptions +## Voluntary and involuntary disruptions Pods do not disappear until someone (a person or a controller) destroys them, or there is an unavoidable hardware or system software error. @@ -48,7 +46,7 @@ Administrator. Typical application owner actions include: - updating a deployment's pod template causing a restart - directly deleting a pod (e.g. by accident) -Cluster Administrator actions include: +Cluster administrator actions include: - [Draining a node](/docs/tasks/administer-cluster/safely-drain-node/) for repair or upgrade. - Draining a node from a cluster to scale the cluster down (learn about @@ -68,7 +66,7 @@ Not all voluntary disruptions are constrained by Pod Disruption Budgets. For exa deleting deployments or pods bypasses Pod Disruption Budgets. {{< /caution >}} -## Dealing with Disruptions +## Dealing with disruptions Here are some ways to mitigate involuntary disruptions: @@ -90,58 +88,58 @@ of cluster (node) autoscaling may cause voluntary disruptions to defragment and Your cluster administrator or hosting provider should have documented what level of voluntary disruptions, if any, to expect. -Kubernetes offers features to help run highly available applications at the same -time as frequent voluntary disruptions. We call this set of features -*Disruption Budgets*. - -## How Disruption Budgets Work +## Pod disruption budgets {{< feature-state for_k8s_version="v1.5" state="beta" >}} -An Application Owner can create a `PodDisruptionBudget` object (PDB) for each application. -A PDB limits the number of pods of a replicated application that are down simultaneously from -voluntary disruptions. For example, a quorum-based application would +Kubernetes offers features to help you run highly available applications even when you +introduce frequent voluntary disruptions. + +As an application owner, you can create a PodDisruptionBudget (PDB) for each application. +A PDB limits the number of Pods of a replicated application that are down simultaneously from +voluntary disruptions. For example, a quorum-based application would like to ensure that the number of replicas running is never brought below the number needed for a quorum. A web front end might want to ensure that the number of replicas serving load never falls below a certain percentage of the total. Cluster managers and hosting providers should use tools which -respect Pod Disruption Budgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api) -instead of directly deleting pods or deployments. Examples are the `kubectl drain` command -and the Kubernetes-on-GCE cluster upgrade script (`cluster/gce/upgrade.sh`). +respect PodDisruptionBudgets by calling the [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api) +instead of directly deleting pods or deployments. -When a cluster administrator wants to drain a node -they use the `kubectl drain` command. That tool tries to evict all -the pods on the machine. The eviction request may be temporarily rejected, -and the tool periodically retries all failed requests until all pods -are terminated, or until a configurable timeout is reached. +For example, the `kubectl drain` subcommand lets you mark a node as going out of +service. When you run `kubectl drain`, the tool tries to evict all of the Pods on +the Node you're taking out of service. The eviction request that `kubectl` submits on +your behalf may be temporarily rejected, so the tool periodically retries all failed +requests until all Pods on the target node are terminated, or until a configurable timeout +is reached. A PDB specifies the number of replicas that an application can tolerate having, relative to how many it is intended to have. For example, a Deployment which has a `.spec.replicas: 5` is supposed to have 5 pods at any given time. If its PDB allows for there to be 4 at a time, -then the Eviction API will allow voluntary disruption of one, but not two pods, at a time. +then the Eviction API will allow voluntary disruption of one (but not two) pods at a time. The group of pods that comprise the application is specified using a label selector, the same as the one used by the application's controller (deployment, stateful-set, etc). -The "intended" number of pods is computed from the `.spec.replicas` of the pods controller. -The controller is discovered from the pods using the `.metadata.ownerReferences` of the object. +The "intended" number of pods is computed from the `.spec.replicas` of the workload resource +that is managing those pods. The control plane discovers the owning workload resource by +examining the `.metadata.ownerReferences` of the Pod. PDBs cannot prevent [involuntary disruptions](#voluntary-and-involuntary-disruptions) from occurring, but they do count against the budget. Pods which are deleted or unavailable due to a rolling upgrade to an application do count -against the disruption budget, but controllers (like deployment and stateful-set) -are not limited by PDBs when doing rolling upgrades -- the handling of failures -during application updates is configured in the controller spec. -(Learn about [updating a deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment).) +against the disruption budget, but workload resources (such as Deployment and StatefulSet) +are not limited by PDBs when doing rolling upgrades. Instead, the handling of failures +during application updates is configured in the spec for the specific workload resource. -When a pod is evicted using the eviction API, it is gracefully terminated (see -`terminationGracePeriodSeconds` in [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).) +When a pod is evicted using the eviction API, it is gracefully +[terminated](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination), honoring the +`terminationGracePeriodSeconds` setting in its [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).) -## PDB Example +## PodDisruptionBudget example {#pdb-example} Consider a cluster with 3 nodes, `node-1` through `node-3`. The cluster is running several applications. One of them has 3 replicas initially called @@ -272,4 +270,6 @@ the nodes in your cluster, such as a node or system software upgrade, here are s * Learn more about [draining nodes](/docs/tasks/administer-cluster/safely-drain-node/) +* Learn about [updating a deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment) + including steps to maintain its availability during the rollout. diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md index d72265faf5..9075bf1a8b 100644 --- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md @@ -6,16 +6,60 @@ weight: 30 -{{< comment >}}Updated: 4/14/2015{{< /comment >}} -{{< comment >}}Edited and moved to Concepts section: 2/2/17{{< /comment >}} - -This page describes the lifecycle of a Pod. +This page describes the lifecycle of a Pod. Pods follow a defined lifecycle, starting +in the `Pending` [phase](#pod-phase), moving through `Running` if at least one +of its primary containers starts OK, and then through either the `Succeeded` or +`Failed` phases depending on whether any container in the Pod terminated in failure. +Whilst a Pod is running, the kubelet is able to restart containers to handle some +kind of faults. Within a Pod, Kubernetes tracks different container +[states](#container-states) and handles +In the Kubernetes API, Pods have both a specification and an actual status. The +status for a Pod object consists of a set of [Pod conditions](#pod-conditions). +You can also inject [custom readiness information](#pod-readiness-gate) into the +condition data for a Pod, if that is useful to your application. +Pods are only [scheduled](/docs/concepts/scheduling-eviction/) once in their lifetime. +Once a Pod is scheduled (assigned) to a Node, the Pod runs on that Node until it stops +or is [terminated](#pod-termination). +## Pod lifetime + +Like individual application containers, Pods are considered to be relatively +ephemeral (rather than durable) entities. Pods are created, assigned a unique +ID ([UID](/docs/concepts/overview/working-with-objects/names/#uids)), and scheduled +to nodes where they remain until termination (according to restart policy) or +deletion. +If a {{< glossary_tooltip term_id="node" >}} dies, the Pods scheduled to that node +are [scheduled for deletion](#pod-garbage-collection) after a timeout period. + +Pods do not, by themselves, self-heal. If a Pod is scheduled to a +{{< glossary_tooltip text="node" term_id="node" >}} that then fails, +or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't +survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a +higher-level abstraction, called a +{{< glossary_tooltip term_id="controller" text="controller" >}}, that handles the work of +managing the relatively disposable Pod instances. + +A given Pod (as defined by a UID) is never "rescheduled" to a different node; instead, +that Pod can be replaced by a new, near-identical Pod, with even the same name i +desired, but with a different UID. + +When something is said to have the same lifetime as a Pod, such as a +{{< glossary_tooltip term_id="volume" text="volume" >}}, +that means that the thing exists as long as that specific Pod (with that exact UID) +exists. If that Pod is deleted for any reason, and even if an identical replacement +is created, the related thing (a volume, in this example) is also destroyed and +created anew. + +{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}} + +*A multi-container Pod that contains a file puller and a +web server that uses a persistent volume for shared storage between the containers.* + ## Pod phase A Pod's `status` field is a @@ -24,7 +68,7 @@ object, which has a `phase` field. The phase of a Pod is a simple, high-level summary of where the Pod is in its lifecycle. The phase is not intended to be a comprehensive rollup of observations -of Container or Pod state, nor is it intended to be a comprehensive state machine. +of container or Pod state, nor is it intended to be a comprehensive state machine. The number and meanings of Pod phase values are tightly guarded. Other than what is documented here, nothing should be assumed about Pods that @@ -34,188 +78,106 @@ Here are the possible values for `phase`: Value | Description :-----|:----------- -`Pending` | The Pod has been accepted by the Kubernetes system, but one or more of the Container images has not been created. This includes time before being scheduled as well as time spent downloading images over the network, which could take a while. -`Running` | The Pod has been bound to a node, and all of the Containers have been created. At least one Container is still running, or is in the process of starting or restarting. -`Succeeded` | All Containers in the Pod have terminated in success, and will not be restarted. -`Failed` | All Containers in the Pod have terminated, and at least one Container has terminated in failure. That is, the Container either exited with non-zero status or was terminated by the system. -`Unknown` | For some reason the state of the Pod could not be obtained, typically due to an error in communicating with the host of the Pod. +`Pending` | The Pod has been accepted by the Kubernetes cluster, but one or more of the containers has not been set up and made ready to run. This includes time a Pod spends waiting to bescheduled as well as the time spent downloading container images over the network. +`Running` | The Pod has been bound to a node, and all of the containers have been created. At least one container is still running, or is in the process of starting or restarting. +`Succeeded` | All containers in the Pod have terminated in success, and will not be restarted. +`Failed` | All containers in the Pod have terminated, and at least one container has terminated in failure. That is, the container either exited with non-zero status or was terminated by the system. +`Unknown` | For some reason the state of the Pod could not be obtained. This phase typically occurs due to an error in communicating with the node where the Pod should be running. + +If a node dies or is disconnected from the rest of the cluster, Kubernetes +applies a policy for setting the `phase` of all Pods on the lost node to Failed. + +## Container states + +As well as the [phase](#pod-phase) of the Pod overall, Kubernetes tracks the state of +each container inside a Pod. You can use +[container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/) to +trigger events to run at certain points in a container's lifecycle. + +Once the {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} +assigns a Pod to a Node, the kubelet starts creating containers for that Pod +using a {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}. +There are three possible container states: `Waiting`, `Running`, and `Terminated`. + +To the check state of a Pod's containers, you can use +`kubectl describe pod `. The output shows the state for each container +within that Pod. + +Each state has a specific meaning: + +### `Waiting` {#container-state-waiting} + +If a container is not in either the `Running` or `Terminated` state, it `Waiting`. +A container in the `Waiting` state is still running the operations it requires in +order to complete start up: for example, pulling the container image from a container +image registry, or applying {{< glossary_tooltip text="Secret" term_id="secret" >}} +data. +When you use `kubectl` to query a Pod with a container that is `Waiting`, you also see +a Reason field to summarize why the container is in that state. + +### `Running` {#container-state-running} + +The `Running` status indicates that a container is executing without issues. If there +was a `postStart` hook configured, it has already executed and executed. When you use +`kubectl` to query a Pod with a container that is `Running`, you also see information +about when the container entered the `Running` state. + +### `Terminated` {#container-state-terminated} + +A container in the `Terminated` state has begin execution and has then either run to +completion or has failed for some reason. When you use `kubectl` to query a Pod with +a container that is `Terminated`, you see a reason, and exit code, and the start and +finish time for that container's period of execution. + +If a container has a `preStop` hook configured, that runs before the container enters +the `Terminated` state. + +## Container restart policy {#restart-policy} + +The `spec` of a Pod has a `restartPolicy` field with possible values Always, OnFailure, +and Never. The default value is Always. + +The `restartPolicy` applies to all containers in the Pod. `restartPolicy` only +refers to restarts of the containers by the kubelet on the same node. After containers +in a Pod exit, the kubelet restarts them with an exponential back-off delay (10s, 20s, +40s, …), that is capped at five minutes. Once a container has executed with no problems +for 10 minutes without any problems, the kubelet resets the restart backoff timer for +that container. ## Pod conditions A Pod has a PodStatus, which has an array of [PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core) -through which the Pod has or has not passed. Each element of the PodCondition -array has six possible fields: +through which the Pod has or has not passed: -* The `lastProbeTime` field provides a timestamp for when the Pod condition - was last probed. +* `PodScheduled`: the Pod has been scheduled to a node. +* `ContainersReady`: all containers in the Pod are ready. +* `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers/) + have started successfully. +* `Ready`: the Pod is able to serve requests and should be added to the load + balancing pools of all matching Services. -* The `lastTransitionTime` field provides a timestamp for when the Pod - last transitioned from one status to another. - -* The `message` field is a human-readable message indicating details - about the transition. - -* The `reason` field is a unique, one-word, CamelCase reason for the condition's last transition. - -* The `status` field is a string, with possible values "`True`", "`False`", and "`Unknown`". - -* The `type` field is a string with the following possible values: - - * `PodScheduled`: the Pod has been scheduled to a node; - * `Ready`: the Pod is able to serve requests and should be added to the load - balancing pools of all matching Services; - * `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers) - have started successfully; - * `ContainersReady`: all containers in the Pod are ready. +Field name | Description +:--------------------|:----------- +`type` | Name of this Pod condition. +`status` | Indicates whether that condition is applicable, with possible values "`True`", "`False`", or "`Unknown`". +`lastProbeTime` | Timestamp of when the Pod condition was last probed. +`lastTransitionTime` | Timestamp for when the Pod last transitioned from one status to another. +`reason` | Machine-readable, UpperCamelCase text indicating the reason for the condition's last transition. +`messsage | Human-readable message indicating details about the last status transition. - -## Container probes - -A [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) is a diagnostic -performed periodically by the [kubelet](/docs/admin/kubelet/) -on a Container. To perform a diagnostic, -the kubelet calls a -[Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core) implemented by -the Container. There are three types of handlers: - -* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core): - Executes a specified command inside the Container. The diagnostic - is considered successful if the command exits with a status code of 0. - -* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core): - Performs a TCP check against the Container's IP address on - a specified port. The diagnostic is considered successful if the port is open. - -* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core): - Performs an HTTP Get request against the Container's IP - address on a specified port and path. The diagnostic is considered successful - if the response has a status code greater than or equal to 200 and less than 400. - -Each probe has one of three results: - -* Success: The Container passed the diagnostic. -* Failure: The Container failed the diagnostic. -* Unknown: The diagnostic failed, so no action should be taken. - -The kubelet can optionally perform and react to three kinds of probes on running -Containers: - -* `livenessProbe`: Indicates whether the Container is running. If - the liveness probe fails, the kubelet kills the Container, and the Container - is subjected to its [restart policy](#restart-policy). If a Container does not - provide a liveness probe, the default state is `Success`. - -* `readinessProbe`: Indicates whether the Container is ready to service requests. - If the readiness probe fails, the endpoints controller removes the Pod's IP - address from the endpoints of all Services that match the Pod. The default - state of readiness before the initial delay is `Failure`. If a Container does - not provide a readiness probe, the default state is `Success`. - -* `startupProbe`: Indicates whether the application within the Container is started. - All other probes are disabled if a startup probe is provided, until it succeeds. - If the startup probe fails, the kubelet kills the Container, and the Container - is subjected to its [restart policy](#restart-policy). If a Container does not - provide a startup probe, the default state is `Success`. - -### When should you use a liveness probe? - -{{< feature-state for_k8s_version="v1.0" state="stable" >}} - -If the process in your Container is able to crash on its own whenever it -encounters an issue or becomes unhealthy, you do not necessarily need a liveness -probe; the kubelet will automatically perform the correct action in accordance -with the Pod's `restartPolicy`. - -If you'd like your Container to be killed and restarted if a probe fails, then -specify a liveness probe, and specify a `restartPolicy` of Always or OnFailure. - -### When should you use a readiness probe? - -{{< feature-state for_k8s_version="v1.0" state="stable" >}} - -If you'd like to start sending traffic to a Pod only when a probe succeeds, -specify a readiness probe. In this case, the readiness probe might be the same -as the liveness probe, but the existence of the readiness probe in the spec means -that the Pod will start without receiving any traffic and only start receiving -traffic after the probe starts succeeding. -If your Container needs to work on loading large data, configuration files, or migrations during startup, specify a readiness probe. - -If you want your Container to be able to take itself down for maintenance, you -can specify a readiness probe that checks an endpoint specific to readiness that -is different from the liveness probe. - -Note that if you just want to be able to drain requests when the Pod is deleted, -you do not necessarily need a readiness probe; on deletion, the Pod automatically -puts itself into an unready state regardless of whether the readiness probe exists. -The Pod remains in the unready state while it waits for the Containers in the Pod -to stop. - -### When should you use a startup probe? - -{{< feature-state for_k8s_version="v1.16" state="alpha" >}} - -If your Container usually starts in more than `initialDelaySeconds + failureThreshold × periodSeconds`, you should specify a startup probe that checks the same endpoint as the liveness probe. The default for `periodSeconds` is 30s. -You should then set its `failureThreshold` high enough to allow the Container to start, without changing the default values of the liveness probe. This helps to protect against deadlocks. - -For more information about how to set up a liveness, readiness, startup probe, see -[Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/). - -## Pod and Container status - -For detailed information about Pod Container status, see -[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) -and -[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core). -Note that the information reported as Pod status depends on the current -[ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core). - -## Container States - -Once Pod is assigned to a node by scheduler, kubelet starts creating containers using container runtime.There are three possible states of containers: Waiting, Running and Terminated. To check state of container, you can use `kubectl describe pod [POD_NAME]`. State is displayed for each container within that Pod. - -* `Waiting`: Default state of container. If container is not in either Running or Terminated state, it is in Waiting state. A container in Waiting state still runs its required operations, like pulling images, applying Secrets, etc. Along with this state, a message and reason about the state are displayed to provide more information. - - ```yaml - ... - State: Waiting - Reason: ErrImagePull - ... - ``` - -* `Running`: Indicates that the container is executing without issues. The `postStart` hook (if any) is executed prior to the container entering a Running state. This state also displays the time when the container entered Running state. - - ```yaml - ... - State: Running - Started: Wed, 30 Jan 2019 16:46:38 +0530 - ... - ``` - -* `Terminated`: Indicates that the container completed its execution and has stopped running. A container enters into this when it has successfully completed execution or when it has failed for some reason. Regardless, a reason and exit code is displayed, as well as the container's start and finish time. Before a container enters into Terminated, `preStop` hook (if any) is executed. - - ```yaml - ... - State: Terminated - Reason: Completed - Exit Code: 0 - Started: Wed, 30 Jan 2019 11:45:26 +0530 - Finished: Wed, 30 Jan 2019 11:45:26 +0530 - ... - ``` - -## Pod readiness {#pod-readiness-gate} +### Pod readiness {#pod-readiness-gate} {{< feature-state for_k8s_version="v1.14" state="stable" >}} Your application can inject extra feedback or signals into PodStatus: -_Pod readiness_. To use this, set `readinessGates` in the PodSpec to specify -a list of additional conditions that the kubelet evaluates for Pod readiness. +_Pod readiness_. To use this, set `readinessGates` in the Pod's `spec` to +specify a list of additional conditions that the kubelet evaluates for Pod readiness. Readiness gates are determined by the current state of `status.condition` -fields for the Pod. If Kubernetes cannot find such a -condition in the `status.conditions` field of a Pod, the status of the condition +fields for the Pod. If Kubernetes cannot find such a condition in the +`status.conditions` field of a Pod, the status of the condition is defaulted to "`False`". Here is an example: @@ -258,152 +220,226 @@ For a Pod that uses custom conditions, that Pod is evaluated to be ready **only* when both the following statements apply: * All containers in the Pod are ready. -* All conditions specified in `ReadinessGates` are `True`. +* All conditions specified in `readinessGates` are `True`. When a Pod's containers are Ready but at least one custom condition is missing or -`False`, the kubelet sets the Pod's condition to `ContainersReady`. +`False`, the kubelet sets the Pod's [condition](#pod-condition) to `ContainersReady`. -## Restart policy +## Container probes -A PodSpec has a `restartPolicy` field with possible values Always, OnFailure, -and Never. The default value is Always. -`restartPolicy` applies to all Containers in the Pod. `restartPolicy` only -refers to restarts of the Containers by the kubelet on the same node. Exited -Containers that are restarted by the kubelet are restarted with an exponential -back-off delay (10s, 20s, 40s ...) capped at five minutes, and is reset after ten -minutes of successful execution. As discussed in the -[Pods document](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof), -once bound to a node, a Pod will never be rebound to another node. +A [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) is a diagnostic +performed periodically by the [kubelet](/docs/admin/kubelet/) +on a Container. To perform a diagnostic, +the kubelet calls a +[Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core) implemented by +the container. There are three types of handlers: +* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core): + Executes a specified command inside the container. The diagnostic + is considered successful if the command exits with a status code of 0. -## Pod lifetime +* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core): + Performs a TCP check against the Pod's IP address on + a specified port. The diagnostic is considered successful if the port is open. -In general, Pods remain until a human or +* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core): + Performs an HTTP `GET` request against the Pod's IP + address on a specified port and path. The diagnostic is considered successful + if the response has a status code greater than or equal to 200 and less than 400. + +Each probe has one of three results: + +* `Success`: The container passed the diagnostic. +* `Failure`: The container failed the diagnostic. +* `Unknown`: The diagnostic failed, so no action should be taken. + +The kubelet can optionally perform and react to three kinds of probes on running +containers: + +* `livenessProbe`: Indicates whether the container is running. If + the liveness probe fails, the kubelet kills the container, and the container + is subjected to its [restart policy](#restart-policy). If a Container does not + provide a liveness probe, the default state is `Success`. + +* `readinessProbe`: Indicates whether the container is ready to respond to requests. + If the readiness probe fails, the endpoints controller removes the Pod's IP + address from the endpoints of all Services that match the Pod. The default + state of readiness before the initial delay is `Failure`. If a Container does + not provide a readiness probe, the default state is `Success`. + +* `startupProbe`: Indicates whether the application within the container is started. + All other probes are disabled if a startup probe is provided, until it succeeds. + If the startup probe fails, the kubelet kills the container, and the container + is subjected to its [restart policy](#restart-policy). If a Container does not + provide a startup probe, the default state is `Success`. + +For more information about how to set up a liveness, readiness, or startup probe, +see [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/). + +### When should you use a liveness probe? + +{{< feature-state for_k8s_version="v1.0" state="stable" >}} + +If the process in your container is able to crash on its own whenever it +encounters an issue or becomes unhealthy, you do not necessarily need a liveness +probe; the kubelet will automatically perform the correct action in accordance +with the Pod's `restartPolicy`. + +If you'd like your container to be killed and restarted if a probe fails, then +specify a liveness probe, and specify a `restartPolicy` of Always or OnFailure. + +### When should you use a readiness probe? + +{{< feature-state for_k8s_version="v1.0" state="stable" >}} + +If you'd like to start sending traffic to a Pod only when a probe succeeds, +specify a readiness probe. In this case, the readiness probe might be the same +as the liveness probe, but the existence of the readiness probe in the spec means +that the Pod will start without receiving any traffic and only start receiving +traffic after the probe starts succeeding. +If your container needs to work on loading large data, configuration files, or +migrations during startup, specify a readiness probe. + +If you want your container to be able to take itself down for maintenance, you +can specify a readiness probe that checks an endpoint specific to readiness that +is different from the liveness probe. + +{{< note >}} +If you just want to be able to drain requests when the Pod is deleted, you do not +necessarily need a readiness probe; on deletion, the Pod automatically puts itself +into an unready state regardless of whether the readiness probe exists. +The Pod remains in the unready state while it waits for the containers in the Pod +to stop. +{{< /note >}} + +### When should you use a startup probe? + +{{< feature-state for_k8s_version="v1.16" state="alpha" >}} + +Startup probes are useful for Pods that have containers that take a long time to +come into service. Rather than set a long liveness interval, you can configure +a separate configuration for probing the container as it starts up, allowing +a time longer than the liveness interval would allow. + +If your container usually starts in more than +`initialDelaySeconds + failureThreshold × periodSeconds`, you should specify a +startup probe that checks the same endpoint as the liveness probe. The default for +`periodSeconds` is 30s. You should then set its `failureThreshold` high enough to +allow the container to start, without changing the default values of the liveness +probe. This helps to protect against deadlocks. + +## Termination of Pods {#pod-termination} + +Because Pods represent processes running on nodes in the cluster, it is important to +allow those processes to gracefully terminate when they are no longer needed (rather +than being abruptly stopped with a `KILL` signal and having no chance to clean up). + +The design aim is for you to be able to request deletion and know when processes +terminate, but also be able to ensure that deletes eventually complete. +When you request deletion of a Pod, the cluster records and tracks the intended grace period +before the Pod is allowed to be forcefully killed. With that forceful shutdown tracking in +place, the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} attempts graceful +shutdown. + +Typically, the container runtime sends a a TERM signal is sent to the main process in each +container. Once the grace period has expired, the KILL signal is sent to any remainig +processes, and the Pod is then deleted from the +{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}. If the kubelet or the +container runtime's management service is restarted while waiting for processes to terminate, the +cluster retries from the start including the full original grace period. + +An example flow: + +1. You use the `kubectl` tool to manually delete a specific Pod, with the default grace period + (30 seconds). +1. The Pod in the API server is updated with the time beyond which the Pod is considered "dead" + along with the grace period. + If you use `kubectl describe` to check on the Pod you're deleting, that Pod shows up as + "Terminating". + On the node where the Pod is running: as soon as the kubelet sees that a Pod has been marked + as terminating (a graceful shutdown duration has been set), the kubelet begins the local Pod + shutdown process. + 1. If one of the Pod's containers has defined a `preStop` + [hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), the kubelet + runs that hook inside of the container. If the `preStop` hook is still running after the + grace period expires, the kubelet requests a small, one-off grace period extension of 2 + seconds. + {{< note >}} + If the `preStop` hook needs longer to complete than the default grace period allows, + you must modify `terminationGracePeriodSeconds` to suit this. + {{< /note >}} + 1. The kubelet triggers the container runtime to send a TERM signal to process 1 inside each + container. + {{< note >}} + The containers in the Pod receive the TERM signal at different times and in an arbitrary + order. If the order of shutdowns matters, consider using a `preStop` hook to synchronize. + {{< /note >}} +1. At the same time as the kubelet is starting graceful shutdown, the control plane removes that + shutting-down Pod from Endpoints (and, if enabled, EndpointSlice) objects where these represent + a {{< glossary_tooltip term_id="service" text="Service" >}} with a configured + {{< glossary_tooltip text="selector" term_id="selector" >}}. + {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} and other workload resources + no longer treat the shutting-down Pod as a valid, in-service replica. Pods that shut down slowly + cannot continue to serve traffic as load balancers (like the service proxy) remove the Pod from + the list of endpoints as soon as the termination grace period _begins_. +1. When the grace period expires, the kubelet triggers forcible shutdown. The container runtime sends + `SIGKILL` to any processes still running in any container in the Pod. + The kubelet also cleans up a hidden `pause` container if that container runtime uses one. +1. The kubelet triggers forcible removal of Pod object from the API server, by setting grace period + to 0 (immediate deletion). +1. The API server deletes the Pod's API object, which is then no longer visible from any client. + +### Forced Pod termination {#pod-termination-forced} + +{{< caution >}} +Forced deletions can be potentially disruptiove for some workloads and their Pods. +{{< /caution >}} + +By default, all deletes are graceful within 30 seconds. The `kubectl delete` command supports +the `--grace-period=` option which allows you to override the default and specify your +own value. + +Setting the grace period to `0` forcibly and immediately deletes the Pod from the API +server. If the pod was still running on a node, that forcible deletion triggers the kubelet to +begin immediate cleanup. + +{{< note >}} +You must specify an additional flag `--force` along with `--grace-period=0` in order to perform force deletions. +{{< /note >}} + +When a force deletion is performed, the API server does not wait for confirmation +from the kubelet that the Pod has been terminated on the node it was running on. It +removes the Pod in the API immediately so a new Pod can be created with the same +name. On the node, Pods that are set to terminate immediately will still be given +a small grace period before being force killed. + +If you need to force-delete Pods that are part of a StatefulSet, refer to the task +documentation for +[deleting Pods from a StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/). + +### Garbage collection of failed Pods {#pod-garbage-collection} + +For failed Pods, the API objects remain in the cluster's API until a human or {{< glossary_tooltip term_id="controller" text="controller" >}} process explicitly removes them. + The control plane cleans up terminated Pods (with a phase of `Succeeded` or `Failed`), when the number of Pods exceeds the configured threshold (determined by `terminated-pod-gc-threshold` in the kube-controller-manager). This avoids a resource leak as Pods are created and terminated over time. -There are different kinds of resources for creating Pods: - -- Use a {{< glossary_tooltip term_id="deployment" >}}, - {{< glossary_tooltip term_id="replica-set" >}} or {{< glossary_tooltip term_id="statefulset" >}} - for Pods that are not expected to terminate, for example, web servers. - -- Use a {{< glossary_tooltip term_id="job" >}} - for Pods that are expected to terminate once their work is complete; - for example, batch computations. Jobs are appropriate only for Pods with - `restartPolicy` equal to OnFailure or Never. - -- Use a {{< glossary_tooltip term_id="daemonset" >}} - for Pods that need to run one per eligible node. - -All workload resources contain a PodSpec. It is recommended to create the -appropriate workload resource and let the resource's controller create Pods -for you, rather than directly create Pods yourself. - -If a node dies or is disconnected from the rest of the cluster, Kubernetes -applies a policy for setting the `phase` of all Pods on the lost node to Failed. - -## Examples - -### Advanced liveness probe example - -Liveness probes are executed by the kubelet, so all requests are made in the -kubelet network namespace. - -```yaml -apiVersion: v1 -kind: Pod -metadata: - labels: - test: liveness - name: liveness-http -spec: - containers: - - args: - - /server - image: k8s.gcr.io/liveness - livenessProbe: - httpGet: - # when "host" is not defined, "PodIP" will be used - # host: my-host - # when "scheme" is not defined, "HTTP" scheme will be used. Only "HTTP" and "HTTPS" are allowed - # scheme: HTTPS - path: /healthz - port: 8080 - httpHeaders: - - name: X-Custom-Header - value: Awesome - initialDelaySeconds: 15 - timeoutSeconds: 1 - name: liveness -``` - -### Example states - - * Pod is running and has one Container. Container exits with success. - * Log completion event. - * If `restartPolicy` is: - * Always: Restart Container; Pod `phase` stays Running. - * OnFailure: Pod `phase` becomes Succeeded. - * Never: Pod `phase` becomes Succeeded. - - * Pod is running and has one Container. Container exits with failure. - * Log failure event. - * If `restartPolicy` is: - * Always: Restart Container; Pod `phase` stays Running. - * OnFailure: Restart Container; Pod `phase` stays Running. - * Never: Pod `phase` becomes Failed. - - * Pod is running and has two Containers. Container 1 exits with failure. - * Log failure event. - * If `restartPolicy` is: - * Always: Restart Container; Pod `phase` stays Running. - * OnFailure: Restart Container; Pod `phase` stays Running. - * Never: Do not restart Container; Pod `phase` stays Running. - * If Container 1 is not running, and Container 2 exits: - * Log failure event. - * If `restartPolicy` is: - * Always: Restart Container; Pod `phase` stays Running. - * OnFailure: Restart Container; Pod `phase` stays Running. - * Never: Pod `phase` becomes Failed. - - * Pod is running and has one Container. Container runs out of memory. - * Container terminates in failure. - * Log OOM event. - * If `restartPolicy` is: - * Always: Restart Container; Pod `phase` stays Running. - * OnFailure: Restart Container; Pod `phase` stays Running. - * Never: Log failure event; Pod `phase` becomes Failed. - - * Pod is running, and a disk dies. - * Kill all Containers. - * Log appropriate event. - * Pod `phase` becomes Failed. - * If running under a controller, Pod is recreated elsewhere. - - * Pod is running, and its node is segmented out. - * Node controller waits for timeout. - * Node controller sets Pod `phase` to Failed. - * If running under a controller, Pod is recreated elsewhere. - - - ## {{% heading "whatsnext" %}} - * Get hands-on experience [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). * Get hands-on experience - [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/). - -* Learn more about [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/). - + [configuring Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/). +* Learn more about [container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/). +* For detailed information about Pod / Container status in the API, see [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) +and +[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core). diff --git a/content/en/docs/concepts/workloads/pods/pod-overview.md b/content/en/docs/concepts/workloads/pods/pod-overview.md deleted file mode 100644 index e963b7ace6..0000000000 --- a/content/en/docs/concepts/workloads/pods/pod-overview.md +++ /dev/null @@ -1,123 +0,0 @@ ---- -reviewers: -- erictune -title: Pod Overview -content_type: concept -weight: 10 -card: - name: concepts - weight: 60 ---- - - -This page provides an overview of `Pod`, the smallest deployable object in the Kubernetes object model. - - - - -## Understanding Pods - -A *Pod* is the basic execution unit of a Kubernetes application--the smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod represents processes running on your {{< glossary_tooltip term_id="cluster" text="cluster" >}}. - -A Pod encapsulates an application's container (or, in some cases, multiple containers), storage resources, a unique network identity (IP address), as well as options that govern how the container(s) should run. A Pod represents a unit of deployment: *a single instance of an application in Kubernetes*, which might consist of either a single {{< glossary_tooltip text="container" term_id="container" >}} or a small number of containers that are tightly coupled and that share resources. - -[Docker](https://www.docker.com) is the most common container runtime used in a Kubernetes Pod, but Pods support other [container runtimes](/docs/setup/production-environment/container-runtimes/) as well. - - -Pods in a Kubernetes cluster can be used in two main ways: - -* **Pods that run a single container**. The "one-container-per-Pod" model is the most common Kubernetes use case; in this case, you can think of a Pod as a wrapper around a single container, and Kubernetes manages the Pods rather than the containers directly. -* **Pods that run multiple containers that need to work together**. A Pod might encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers might form a single cohesive unit of service--one container serving files from a shared volume to the public, while a separate "sidecar" container refreshes or updates those files. The Pod wraps these containers and storage resources together as a single manageable entity. - -Each Pod is meant to run a single instance of a given application. If you want to scale your application horizontally (to provide more overall resources by running more instances), you should use multiple Pods, one for each instance. In Kubernetes, this is typically referred to as _replication_. -Replicated Pods are usually created and managed as a group by a workload resource and its {{< glossary_tooltip text="_controller_" term_id="controller" >}}. -See [Pods and controllers](#pods-and-controllers) for more information on how Kubernetes uses controllers to implement workload scaling and healing. - -### How Pods manage multiple containers - -Pods are designed to support multiple cooperating processes (as containers) that form a cohesive unit of service. The containers in a Pod are automatically co-located and co-scheduled on the same physical or virtual machine in the cluster. The containers can share resources and dependencies, communicate with one another, and coordinate when and how they are terminated. - -Note that grouping multiple co-located and co-managed containers in a single Pod is a relatively advanced use case. You should use this pattern only in specific instances in which your containers are tightly coupled. For example, you might have a container that acts as a web server for files in a shared volume, and a separate "sidecar" container that updates those files from a remote source, as in the following diagram: - -{{< figure src="/images/docs/pod.svg" alt="example pod diagram" width="50%" >}} - -Some Pods have {{< glossary_tooltip text="init containers" term_id="init-container" >}} as well as {{< glossary_tooltip text="app containers" term_id="app-container" >}}. Init containers run and complete before the app containers are started. - -Pods provide two kinds of shared resources for their constituent containers: *networking* and *storage*. - -#### Networking - -Each Pod is assigned a unique IP address for each address family. Every container in a Pod shares the network namespace, including the IP address and network ports. Containers *inside a Pod* can communicate with one another using `localhost`. When containers in a Pod communicate with entities *outside the Pod*, they must coordinate how they use the shared network resources (such as ports). - -#### Storage - -A Pod can specify a set of shared storage {{< glossary_tooltip text="volumes" term_id="volume" >}}. All containers in the Pod can access the shared volumes, allowing those containers to share data. Volumes also allow persistent data in a Pod to survive in case one of the containers within needs to be restarted. See [Volumes](/docs/concepts/storage/volumes/) for more information on how Kubernetes implements shared storage in a Pod. - -## Working with Pods - -You'll rarely create individual Pods directly in Kubernetes--even singleton Pods. This is because Pods are designed as relatively ephemeral, disposable entities. When a Pod gets created (directly by you, or indirectly by a {{< glossary_tooltip text="_controller_" term_id="controller" >}}), it is scheduled to run on a {{< glossary_tooltip term_id="node" >}} in your cluster. The Pod remains on that node until the process is terminated, the pod object is deleted, the Pod is *evicted* for lack of resources, or the node fails. - -{{< note >}} -Restarting a container in a Pod should not be confused with restarting a Pod. A Pod is not a process, but an environment for running a container. A Pod persists until it is deleted. -{{< /note >}} - -Pods do not, by themselves, self-heal. If a Pod is scheduled to a Node that fails, or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a higher-level abstraction, called a controller, that handles the work of managing the relatively disposable Pod instances. Thus, while it is possible to use Pod directly, it's far more common in Kubernetes to manage your pods using a controller. - -### Pods and controllers - -You can use workload resources to create and manage multiple Pods for you. A controller for the resource handles replication and rollout and automatic healing in case of Pod failure. For example, if a Node fails, a controller notices that Pods on that Node have stopped working and creates a replacement Pod. The scheduler places the replacement Pod onto a healthy Node. - -Here are some examples of workload resources that manage one or more Pods: - -* {{< glossary_tooltip text="Deployment" term_id="deployment" >}} -* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} -* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}} - - -## Pod templates - -Controllers for {{< glossary_tooltip text="workload" term_id="workload" >}} resources create Pods -from a pod template and manage those Pods on your behalf. - -PodTemplates are specifications for creating Pods, and are included in workload resources such as -[Deployments](/docs/concepts/workloads/controllers/deployment/), -[Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and -[DaemonSets](/docs/concepts/workloads/controllers/daemonset/). - -Each controller for a workload resource uses the PodTemplate inside the workload object to make actual Pods. The PodTemplate is part of the desired state of whatever workload resource you used to run your app. - -The sample below is a manifest for a simple Job with a `template` that starts one container. The container in that Pod prints a message then pauses. - -```yaml -apiVersion: batch/v1 -kind: Job -metadata: - name: hello -spec: - template: - # This is the pod template - spec: - containers: - - name: hello - image: busybox - command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600'] - restartPolicy: OnFailure - # The pod template ends here -``` - -Modifying the pod template or switching to a new pod template has no effect on the Pods that already exist. Pods do not receive template updates directly; instead, a new Pod is created to match the revised pod template. - -For example, a Deployment controller ensures that the running Pods match the current pod template. If the template is updated, the controller has to remove the existing Pods and create new Pods based on the updated template. Each workload controller implements its own rules for handling changes to the Pod template. - -On Nodes, the {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} does not directly observe or manage any of the details around pod templates and updates; those details are abstracted away. That abstraction and separation of concerns simplifies system semantics, and makes it feasible to extend the cluster's behavior without changing existing code. - - - -## {{% heading "whatsnext" %}} - -* Learn more about [Pods](/docs/concepts/workloads/pods/pod/) -* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container -* Learn more about Pod behavior: - * [Pod Termination](/docs/concepts/workloads/pods/pod/#termination-of-pods) - * [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/) - diff --git a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index 2b16894e6b..c48b2aa5d0 100644 --- a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -1,7 +1,7 @@ --- title: Pod Topology Spread Constraints content_type: concept -weight: 50 +weight: 40 --- diff --git a/content/en/docs/concepts/workloads/pods/pod.md b/content/en/docs/concepts/workloads/pods/pod.md deleted file mode 100644 index d87dc92cb2..0000000000 --- a/content/en/docs/concepts/workloads/pods/pod.md +++ /dev/null @@ -1,209 +0,0 @@ ---- -reviewers: -title: Pods -content_type: concept -weight: 20 ---- - - - -_Pods_ are the smallest deployable units of computing that can be created and -managed in Kubernetes. - - - - - - -## What is a Pod? - -A _Pod_ (as in a pod of whales or pea pod) is a group of one or more -{{< glossary_tooltip text="containers" term_id="container" >}} (such as -Docker containers), with shared storage/network, and a specification -for how to run the containers. A Pod's contents are always co-located and -co-scheduled, and run in a shared context. A Pod models an -application-specific "logical host" - it contains one or more application -containers which are relatively tightly coupled — in a pre-container -world, being executed on the same physical or virtual machine would mean being -executed on the same logical host. - -While Kubernetes supports more container runtimes than just Docker, Docker is -the most commonly known runtime, and it helps to describe Pods in Docker terms. - -The shared context of a Pod is a set of Linux namespaces, cgroups, and -potentially other facets of isolation - the same things that isolate a Docker -container. Within a Pod's context, the individual applications may have -further sub-isolations applied. - -Containers within a Pod share an IP address and port space, and -can find each other via `localhost`. They can also communicate with each -other using standard inter-process communications like SystemV semaphores or -POSIX shared memory. Containers in different Pods have distinct IP addresses -and can not communicate by IPC without -[special configuration](/docs/concepts/policy/pod-security-policy/). -These containers usually communicate with each other via Pod IP addresses. - -Applications within a Pod also have access to shared {{< glossary_tooltip text="volumes" term_id="volume" >}}, which are defined -as part of a Pod and are made available to be mounted into each application's -filesystem. - -In terms of [Docker](https://www.docker.com/) constructs, a Pod is modelled as -a group of Docker containers with shared namespaces and shared filesystem -volumes. - -Like individual application containers, Pods are considered to be relatively -ephemeral (rather than durable) entities. As discussed in -[pod lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/), Pods are created, assigned a unique ID (UID), and -scheduled to nodes where they remain until termination (according to restart -policy) or deletion. If a {{< glossary_tooltip term_id="node" >}} dies, the Pods scheduled to that node are -scheduled for deletion, after a timeout period. A given Pod (as defined by a UID) is not -"rescheduled" to a new node; instead, it can be replaced by an identical Pod, -with even the same name if desired, but with a new UID (see [replication -controller](/docs/concepts/workloads/controllers/replicationcontroller/) for more details). - -When something is said to have the same lifetime as a Pod, such as a volume, -that means that it exists as long as that Pod (with that UID) exists. If that -Pod is deleted for any reason, even if an identical replacement is created, the -related thing (e.g. volume) is also destroyed and created anew. - -{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}} - -*A multi-container Pod that contains a file puller and a -web server that uses a persistent volume for shared storage between the containers.* - -## Motivation for Pods - -### Management - -Pods are a model of the pattern of multiple cooperating processes which form a -cohesive unit of service. They simplify application deployment and management -by providing a higher-level abstraction than the set of their constituent -applications. Pods serve as unit of deployment, horizontal scaling, and -replication. Colocation (co-scheduling), shared fate (e.g. termination), -coordinated replication, resource sharing, and dependency management are -handled automatically for containers in a Pod. - -### Resource sharing and communication - -Pods enable data sharing and communication among their constituents. - -The applications in a Pod all use the same network namespace (same IP and port -space), and can thus "find" each other and communicate using `localhost`. -Because of this, applications in a Pod must coordinate their usage of ports. -Each Pod has an IP address in a flat shared networking space that has full -communication with other physical computers and Pods across the network. - -Containers within the Pod see the system hostname as being the same as the configured -`name` for the Pod. There's more about this in the [networking](/docs/concepts/cluster-administration/networking/) -section. - -In addition to defining the application containers that run in the Pod, the Pod -specifies a set of shared storage volumes. Volumes enable data to survive -container restarts and to be shared among the applications within the Pod. - -## Uses of pods - -Pods can be used to host vertically integrated application stacks (e.g. LAMP), -but their primary motivation is to support co-located, co-managed helper -programs, such as: - -* content management systems, file and data loaders, local cache managers, etc. -* log and checkpoint backup, compression, rotation, snapshotting, etc. -* data change watchers, log tailers, logging and monitoring adapters, event publishers, etc. -* proxies, bridges, and adapters -* controllers, managers, configurators, and updaters - -Individual Pods are not intended to run multiple instances of the same -application, in general. - -For a longer explanation, see [The Distributed System ToolKit: Patterns for -Composite -Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns). - -## Alternatives considered - -_Why not just run multiple programs in a single (Docker) container?_ - -1. Transparency. Making the containers within the Pod visible to the - infrastructure enables the infrastructure to provide services to those - containers, such as process management and resource monitoring. This - facilitates a number of conveniences for users. -1. Decoupling software dependencies. The individual containers may be - versioned, rebuilt and redeployed independently. Kubernetes may even support - live updates of individual containers someday. -1. Ease of use. Users don't need to run their own process managers, worry about - signal and exit-code propagation, etc. -1. Efficiency. Because the infrastructure takes on more responsibility, - containers can be lighter weight. - -_Why not support affinity-based co-scheduling of containers?_ - -That approach would provide co-location, but would not provide most of the -benefits of Pods, such as resource sharing, IPC, guaranteed fate sharing, and -simplified management. - -## Durability of pods (or lack thereof) - -Pods aren't intended to be treated as durable entities. They won't survive scheduling failures, node failures, or other evictions, such as due to lack of resources, or in the case of node maintenance. - -In general, users shouldn't need to create Pods directly. They should almost -always use controllers even for singletons, for example, -[Deployments](/docs/concepts/workloads/controllers/deployment/). -Controllers provide self-healing with a cluster scope, as well as replication -and rollout management. -Controllers like [StatefulSet](/docs/concepts/workloads/controllers/statefulset.md) -can also provide support to stateful Pods. - -The use of collective APIs as the primary user-facing primitive is relatively common among cluster scheduling systems, including [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema), and [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997). - -Pod is exposed as a primitive in order to facilitate: - -* scheduler and controller pluggability -* support for pod-level operations without the need to "proxy" them via controller APIs -* decoupling of Pod lifetime from controller lifetime, such as for bootstrapping -* decoupling of controllers and services — the endpoint controller just watches Pods -* clean composition of Kubelet-level functionality with cluster-level functionality — Kubelet is effectively the "pod controller" -* high-availability applications, which will expect Pods to be replaced in advance of their termination and certainly in advance of deletion, such as in the case of planned evictions or image prefetching. - -## Termination of Pods - -Because Pods represent running processes on nodes in the cluster, it is important to allow those processes to gracefully terminate when they are no longer needed (vs being violently killed with a KILL signal and having no chance to clean up). Users should be able to request deletion and know when processes terminate, but also be able to ensure that deletes eventually complete. When a user requests deletion of a Pod, the system records the intended grace period before the Pod is allowed to be forcefully killed, and a TERM signal is sent to the main process in each container. Once the grace period has expired, the KILL signal is sent to those processes, and the Pod is then deleted from the API server. If the Kubelet or the container manager is restarted while waiting for processes to terminate, the termination will be retried with the full grace period. - -An example flow: - -1. User sends command to delete Pod, with default grace period (30s) -1. The Pod in the API server is updated with the time beyond which the Pod is considered "dead" along with the grace period. -1. Pod shows up as "Terminating" when listed in client commands -1. (simultaneous with 3) When the Kubelet sees that a Pod has been marked as terminating because the time in 2 has been set, it begins the Pod shutdown process. - 1. If one of the Pod's containers has defined a [preStop hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), it is invoked inside of the container. If the `preStop` hook is still running after the grace period expires, step 2 is then invoked with a small (2 second) one-time extended grace period. You must modify `terminationGracePeriodSeconds` if the `preStop` hook needs longer to complete. - 1. The container is sent the TERM signal. Note that not all containers in the Pod will receive the TERM signal at the same time and may each require a `preStop` hook if the order in which they shut down matters. -1. (simultaneous with 3) Pod is removed from endpoints list for service, and are no longer considered part of the set of running Pods for replication controllers. Pods that shutdown slowly cannot continue to serve traffic as load balancers (like the service proxy) remove them from their rotations. -1. When the grace period expires, any processes still running in the Pod are killed with SIGKILL. -1. The Kubelet will finish deleting the Pod on the API server by setting grace period 0 (immediate deletion). The Pod disappears from the API and is no longer visible from the client. - -By default, all deletes are graceful within 30 seconds. The `kubectl delete` command supports the `--grace-period=` option which allows a user to override the default and specify their own value. The value `0` [force deletes](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) the Pod. -You must specify an additional flag `--force` along with `--grace-period=0` in order to perform force deletions. - -### Force deletion of pods - -Force deletion of a Pod is defined as deletion of a Pod from the cluster state and etcd immediately. When a force deletion is performed, the API server does not wait for confirmation from the kubelet that the Pod has been terminated on the node it was running on. It removes the Pod in the API immediately so a new Pod can be created with the same name. On the node, Pods that are set to terminate immediately will still be given a small grace period before being force killed. - -Force deletions can be potentially dangerous for some Pods and should be performed with caution. In case of StatefulSet Pods, please refer to the task documentation for [deleting Pods from a StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/). - -## Privileged mode for pod containers - -Any container in a Pod can enable privileged mode, using the `privileged` flag on the [security context](/docs/tasks/configure-pod-container/security-context/) of the container spec. This is useful for containers that want to use Linux capabilities like manipulating the network stack and accessing devices. Processes within the container get almost the same privileges that are available to processes outside a container. With privileged mode, it should be easier to write network and volume plugins as separate Pods that don't need to be compiled into the kubelet. - -{{< note >}} -Your container runtime must support the concept of a privileged container for this setting to be relevant. -{{< /note >}} - -## API Object - -Pod is a top-level resource in the Kubernetes REST API. -The [Pod API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) definition -describes the object in detail. -When creating the manifest for a Pod object, make sure the name specified is a valid -[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). - - diff --git a/content/en/docs/concepts/workloads/pods/podpreset.md b/content/en/docs/concepts/workloads/pods/podpreset.md index f77e34a3f9..9cbb7bdff8 100644 --- a/content/en/docs/concepts/workloads/pods/podpreset.md +++ b/content/en/docs/concepts/workloads/pods/podpreset.md @@ -1,7 +1,7 @@ --- reviewers: - jessfraz -title: Pod Preset +title: Pod Presets content_type: concept weight: 50 --- @@ -32,20 +32,20 @@ specific service do not need to know all the details about that service. In order to use Pod presets in your cluster you must ensure the following: -1. You have enabled the API type `settings.k8s.io/v1alpha1/podpreset`. For - example, this can be done by including `settings.k8s.io/v1alpha1=true` in - the `--runtime-config` option for the API server. In minikube add this flag - `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` while - starting the cluster. -1. You have enabled the admission controller `PodPreset`. One way to doing this - is to include `PodPreset` in the `--enable-admission-plugins` option value specified - for the API server. In minikube, add this flag - - ```shell - --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset - ``` - - while starting the cluster. +1. You have enabled the API type `settings.k8s.io/v1alpha1/podpreset`. For + example, this can be done by including `settings.k8s.io/v1alpha1=true` in + the `--runtime-config` option for the API server. In minikube add this flag + `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` while + starting the cluster. +1. You have enabled the admission controller named `PodPreset`. One way to doing this + is to include `PodPreset` in the `--enable-admission-plugins` option value specified + for the API server. For example, if you use Minikube, add this flag: + + ```shell + --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset + ``` + + while starting your cluster. ## How it works @@ -64,31 +64,28 @@ When a pod creation request occurs, the system does the following: modified by a `PodPreset`. The annotation is of the form `podpreset.admission.kubernetes.io/podpreset-: ""`. -Each Pod can be matched by zero or more Pod Presets; and each `PodPreset` can be -applied to zero or more pods. When a `PodPreset` is applied to one or more -Pods, Kubernetes modifies the Pod Spec. For changes to `Env`, `EnvFrom`, and -`VolumeMounts`, Kubernetes modifies the container spec for all containers in -the Pod; for changes to `Volume`, Kubernetes modifies the Pod Spec. +Each Pod can be matched by zero or more PodPresets; and each PodPreset can be +applied to zero or more Pods. When a PodPreset is applied to one or more +Pods, Kubernetes modifies the Pod Spec. For changes to `env`, `envFrom`, and +`volumeMounts`, Kubernetes modifies the container spec for all containers in +the Pod; for changes to `volumes`, Kubernetes modifies the Pod Spec. {{< note >}} A Pod Preset is capable of modifying the following fields in a Pod spec when appropriate: -- The `.spec.containers` field. -- The `initContainers` field (requires Kubernetes version 1.14.0 or later). +- The `.spec.containers` field +- The `.spec.initContainers` field {{< /note >}} -### Disable Pod Preset for a Specific Pod +### Disable Pod Preset for a specific pod There may be instances where you wish for a Pod to not be altered by any Pod -Preset mutations. In these cases, you can add an annotation in the Pod Spec +preset mutations. In these cases, you can add an annotation in the Pod's `.spec` of the form: `podpreset.admission.kubernetes.io/exclude: "true"`. ## {{% heading "whatsnext" %}} - See [Injecting data into a Pod using PodPreset](/docs/tasks/inject-data-application/podpreset/) For more information about the background, see the [design proposal for PodPreset](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md). - - diff --git a/content/en/docs/reference/glossary/pod.md b/content/en/docs/reference/glossary/pod.md index f14393072c..b551dead19 100755 --- a/content/en/docs/reference/glossary/pod.md +++ b/content/en/docs/reference/glossary/pod.md @@ -2,7 +2,7 @@ title: Pod id: pod date: 2018-04-12 -full_link: /docs/concepts/workloads/pods/pod-overview/ +full_link: /docs/concepts/workloads/pods/ short_description: > A Pod represents a set of running containers in your cluster. diff --git a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md index 09a74d1450..0192cfeb5e 100644 --- a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md @@ -17,7 +17,7 @@ Windows applications constitute a large portion of the services and applications ## Windows containers in Kubernetes -To enable the orchestration of Windows containers in Kubernetes, simply include Windows nodes in your existing Linux cluster. Scheduling Windows containers in [Pods](/docs/concepts/workloads/pods/pod-overview/) on Kubernetes is as simple and easy as scheduling Linux-based containers. +To enable the orchestration of Windows containers in Kubernetes, simply include Windows nodes in your existing Linux cluster. Scheduling Windows containers in {{< glossary_tooltip text="Pods" term_id="pod" >}} on Kubernetes is as simple and easy as scheduling Linux-based containers. In order to run Windows containers, your Kubernetes cluster must include multiple operating systems, with control plane nodes running Linux and workers running either Windows or Linux depending on your workload needs. Windows Server 2019 is the only Windows operating system supported, enabling [Kubernetes Node](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) on Windows (including kubelet, [container runtime](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/containerd), and kube-proxy). For a detailed explanation of Windows distribution channels see the [Microsoft documentation](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19). @@ -56,7 +56,7 @@ Windows containers with process isolation have strict compatibility rules, [wher Key Kubernetes elements work the same way in Windows as they do in Linux. In this section, we talk about some of the key workload enablers and how they map to Windows. -* [Pods](/docs/concepts/workloads/pods/pod-overview/) +* [Pods](/docs/concepts/workloads/pods/) A Pod is the basic building block of Kubernetes–the smallest and simplest unit in the Kubernetes object model that you create or deploy. You may not deploy Windows and Linux containers in the same Pod. All containers in a Pod are scheduled onto a single Node where each Node represents a specific platform and architecture. The following Pod capabilities, properties and events are supported with Windows containers: diff --git a/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md index fe90981432..1194288386 100644 --- a/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md +++ b/content/en/docs/tasks/access-application-cluster/service-access-application-cluster.md @@ -45,13 +45,14 @@ Here is the configuration file for the application Deployment: kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml ``` The preceding command creates a - [Deployment](/docs/concepts/workloads/controllers/deployment/) - object and an associated - [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) - object. The ReplicaSet has two - [Pods](/docs/concepts/workloads/pods/pod/), + {{< glossary_tooltip text="Deployment" term_id="deployment" >}} + and an associated + {{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}. + The ReplicaSet has two + {{< glossary_tooltip text="Pods" term_id="pod" >}} each of which runs the Hello World application. + 1. Display information about the Deployment: ```shell kubectl get deployments hello-world diff --git a/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md b/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md index 2bf0de8231..1d3d34867c 100644 --- a/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md +++ b/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md @@ -36,7 +36,7 @@ This example demonstrates how to use Kubernetes namespaces to subdivide your clu This example assumes the following: 1. You have an [existing Kubernetes cluster](/docs/setup/). -2. You have a basic understanding of Kubernetes _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, and _[Deployments](/docs/concepts/workloads/controllers/deployment/)_. +2. You have a basic understanding of Kubernetes {{< glossary_tooltip text="Pods" term_id="pod" >}}, {{< glossary_tooltip term_id="service" text="Services" >}}, and {{< glossary_tooltip text="Deployments" term_id="deployment" >}}. ## Understand the default namespace diff --git a/content/en/docs/tasks/administer-cluster/namespaces.md b/content/en/docs/tasks/administer-cluster/namespaces.md index eabf58ff0b..3266f06602 100644 --- a/content/en/docs/tasks/administer-cluster/namespaces.md +++ b/content/en/docs/tasks/administer-cluster/namespaces.md @@ -13,7 +13,7 @@ This page shows how to view, work in, and delete {{< glossary_tooltip text="name ## {{% heading "prerequisites" %}} * Have an [existing Kubernetes cluster](/docs/setup/). -* Have a basic understanding of Kubernetes _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, and _[Deployments](/docs/concepts/workloads/controllers/deployment/)_. +2. You have a basic understanding of Kubernetes {{< glossary_tooltip text="Pods" term_id="pod" >}}, {{< glossary_tooltip term_id="service" text="Services" >}}, and {{< glossary_tooltip text="Deployments" term_id="deployment" >}}. diff --git a/content/en/docs/tasks/administer-cluster/safely-drain-node.md b/content/en/docs/tasks/administer-cluster/safely-drain-node.md index e18b2ed87d..ed1b9657c8 100644 --- a/content/en/docs/tasks/administer-cluster/safely-drain-node.md +++ b/content/en/docs/tasks/administer-cluster/safely-drain-node.md @@ -34,7 +34,7 @@ This task assumes that you have met the following prerequisites: You can use `kubectl drain` to safely evict all of your pods from a node before you perform maintenance on the node (e.g. kernel upgrade, hardware maintenance, etc.). Safe evictions allow the pod's containers -to [gracefully terminate](/docs/concepts/workloads/pods/pod/#termination-of-pods) +to [gracefully terminate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) and will respect the `PodDisruptionBudgets` you have specified. {{< note >}} diff --git a/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md b/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md index f5116e7691..00b9251be8 100644 --- a/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md +++ b/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md @@ -75,7 +75,7 @@ set to RUNNING until the postStart handler completes. Kubernetes sends the preStop event immediately before the Container is terminated. Kubernetes' management of the Container blocks until the preStop handler completes, unless the Pod's grace period expires. For more details, see -[Termination of Pods](/docs/concepts/workloads/pods/pod/#termination-of-pods). +[Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/). {{< note >}} Kubernetes only sends the preStop event when a Pod is *terminated*. diff --git a/content/en/docs/tasks/configure-pod-container/static-pod.md b/content/en/docs/tasks/configure-pod-container/static-pod.md index 5189fdb882..cf31d822d6 100644 --- a/content/en/docs/tasks/configure-pod-container/static-pod.md +++ b/content/en/docs/tasks/configure-pod-container/static-pod.md @@ -14,7 +14,7 @@ without the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} observing them. Unlike Pods that are managed by the control plane (for example, a {{< glossary_tooltip text="Deployment" term_id="deployment" >}}); -instead, the kubelet watches each static Pod (and restarts it if it crashes). +instead, the kubelet watches each static Pod (and restarts it if it fails). Static Pods are always bound to one {{< glossary_tooltip term_id="kubelet" >}} on a specific node. diff --git a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md index 9793b472e0..8fb5bffd37 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md @@ -17,7 +17,8 @@ This page shows how to debug Pods and ReplicationControllers. {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * You should be familiar with the basics of - [Pods](/docs/concepts/workloads/pods/pod/) and [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/). + {{< glossary_tooltip text="Pods" term_id="pod" >}} and with + Pods' [lifecycles](/docs/concepts/workloads/pods/pod-lifecycle/). diff --git a/content/en/docs/tasks/run-application/delete-stateful-set.md b/content/en/docs/tasks/run-application/delete-stateful-set.md index 7a4a94fab4..57e54e6797 100644 --- a/content/en/docs/tasks/run-application/delete-stateful-set.md +++ b/content/en/docs/tasks/run-application/delete-stateful-set.md @@ -58,7 +58,7 @@ kubectl delete pods -l app=myapp ### Persistent Volumes -Deleting the Pods in a StatefulSet will not delete the associated volumes. This is to ensure that you have the chance to copy data off the volume before deleting it. Deleting the PVC after the pods have left the [terminating state](/docs/concepts/workloads/pods/pod/#termination-of-pods) might trigger deletion of the backing Persistent Volumes depending on the storage class and reclaim policy. You should never assume ability to access a volume after claim deletion. +Deleting the Pods in a StatefulSet will not delete the associated volumes. This is to ensure that you have the chance to copy data off the volume before deleting it. Deleting the PVC after the pods have terminated might trigger deletion of the backing Persistent Volumes depending on the storage class and reclaim policy. You should never assume ability to access a volume after claim deletion. {{< note >}} Use caution when deleting a PVC, as it may lead to data loss. diff --git a/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md index 48a61a260d..e706c6179a 100644 --- a/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -37,7 +37,7 @@ You can perform a graceful pod deletion with the following command: kubectl delete pods ``` -For the above to lead to graceful termination, the Pod **must not** specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. The practice of setting a `pod.Spec.TerminationGracePeriodSeconds` of 0 seconds is unsafe and strongly discouraged for StatefulSet Pods. Graceful deletion is safe and will ensure that the [Pod shuts down gracefully](/docs/concepts/workloads/pods/pod/#termination-of-pods) before the kubelet deletes the name from the apiserver. +For the above to lead to graceful termination, the Pod **must not** specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. The practice of setting a `pod.Spec.TerminationGracePeriodSeconds` of 0 seconds is unsafe and strongly discouraged for StatefulSet Pods. Graceful deletion is safe and will ensure that the Pod [shuts down gracefully](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) before the kubelet deletes the name from the apiserver. Kubernetes (versions 1.5 or newer) will not delete Pods just because a Node is unreachable. The Pods running on an unreachable Node enter the 'Terminating' or 'Unknown' state after a [timeout](/docs/admin/node/#node-condition). Pods may also enter these states when the user attempts graceful deletion of a Pod on an unreachable Node. The only ways in which a Pod in such a state can be removed from the apiserver are as follows: diff --git a/content/en/docs/tutorials/hello-minikube.md b/content/en/docs/tutorials/hello-minikube.md index 9ba2de1abf..f0aa44369e 100644 --- a/content/en/docs/tutorials/hello-minikube.md +++ b/content/en/docs/tutorials/hello-minikube.md @@ -65,7 +65,7 @@ This tutorial provides a container image that uses NGINX to echo back all the re ## Create a Deployment -A Kubernetes [*Pod*](/docs/concepts/workloads/pods/pod/) is a group of one or more Containers, +A Kubernetes [*Pod*](/docs/concepts/workloads/pods/) is a group of one or more Containers, tied together for the purposes of administration and networking. The Pod in this tutorial has only one Container. A Kubernetes [*Deployment*](/docs/concepts/workloads/controllers/deployment/) checks on the health of your diff --git a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html index 6d7e15a7c4..fb782458de 100644 --- a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html +++ b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html @@ -20,7 +20,7 @@ weight: 20

- A Pod is the basic execution unit of a Kubernetes application. Each Pod represents a part of a workload that is running on your cluster. Learn more about Pods. + A Pod is the basic execution unit of a Kubernetes application. Each Pod represents a part of a workload that is running on your cluster. Learn more about Pods.

diff --git a/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html index 8a7d60dd87..c610b6e9f4 100644 --- a/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -28,7 +28,7 @@ weight: 10

Overview of Kubernetes Services

-

Kubernetes Pods are mortal. Pods in fact have a lifecycle. When a worker node dies, the Pods running on the Node are also lost. A ReplicaSet might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are exchangeable; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.

+

Kubernetes Pods are mortal. Pods in fact have a lifecycle. When a worker node dies, the Pods running on the Node are also lost. A ReplicaSet might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are exchangeable; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.

A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. Services enable a loose coupling between dependent Pods. A Service is defined using YAML (preferred) or JSON, like all Kubernetes objects. The set of Pods targeted by a Service is usually determined by a LabelSelector (see below for why you might want a Service without including selector in the spec).

diff --git a/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md index 2974c77c94..5babc2c0b0 100644 --- a/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md +++ b/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md @@ -52,11 +52,11 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml The preceding command creates a - [Deployment](/docs/concepts/workloads/controllers/deployment/) - object and an associated - [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) - object. The ReplicaSet has five - [Pods](/docs/concepts/workloads/pods/pod/), + {{< glossary_tooltip text="Deployment" term_id="deployment" >}} + and an associated + {{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}. + The ReplicaSet has five + {{< glossary_tooltip text="Pods" term_id="pod" >}} each of which runs the Hello World application. 1. Display information about the Deployment: diff --git a/static/_redirects b/static/_redirects index 0279c38ce9..dc3b2c9442 100644 --- a/static/_redirects +++ b/static/_redirects @@ -72,7 +72,7 @@ /docs/concepts/abstractions/controllers/statefulsets/ /docs/concepts/workloads/controllers/statefulset/ 301 /docs/concepts/abstractions/init-containers/ /docs/concepts/workloads/pods/init-containers/ 301 /docs/concepts/abstractions/overview/ /docs/concepts/overview/working-with-objects/kubernetes-objects/ 301 -/docs/concepts/abstractions/pod/ /docs/concepts/workloads/pods/pod-overview/ 301 +/docs/concepts/abstractions/pod/ /docs/concepts/workloads/pods/ 301 /docs/concepts/api-extension/apiserver-aggregation/ /docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/ 301 /docs/concepts/api-extension/custom-resources/ /docs/concepts/extend-kubernetes/api-extension/custom-resources/ 301 /docs/concepts/containers/overview/ /docs/concepts/containers/ 301 @@ -126,12 +126,14 @@ /docs/concepts/overview/object-management-kubectl/imperative-config/ /docs/tasks/manage-kubernetes-objects/imperative-config/ 301 /docs/concepts/overview/object-management-kubectl/kustomization/ /docs/tasks/manage-kubernetes-objects/kustomization/ 301 /docs/concepts/workloads/controllers/cron-jobs/deployment/ /docs/concepts/workloads/controllers/cron-jobs/ 301 -/docs/concepts/workloads/controllers/daemonset/docs/concepts/workloads/pods/pod/ /docs/concepts/workloads/pods/pod/ 301 -/docs/concepts/workloads/controllers/deployment/docs/concepts/workloads/pods/pod/ /docs/concepts/workloads/pods/pod/ 301 +/docs/concepts/workloads/controllers/daemonset/docs/concepts/workloads/pods/pod/ /docs/concepts/workloads/pods/ 301 +/docs/concepts/workloads/controllers/deployment/docs/concepts/workloads/pods/pod/ /docs/concepts/workloads/pods/ 301 /docs/concepts/workloads/controllers/jobs-run-to-completion/ /docs/concepts/workloads/controllers/job/ 301 /docs/concepts/workloads/controllers/statefulsets/ /docs/concepts/workloads/controllers/statefulset/ 301 /docs/concepts/workloads/controllers/statefulset.md /docs/concepts/workloads/controllers/statefulset/ 301! +/docs/concepts/workloads/pods/pod/ /docs/concepts/workloads/pods/ 301 +/docs/concepts/workloads/pods/pod-overview/ /docs/concepts/workloads/pods/ 301 /docs/concepts/workloads/pods/init-containers/Kubernetes/ /docs/concepts/workloads/pods/init-containers/ 301 /docs/consumer-guideline/pod-security-coverage/ /docs/concepts/policy/pod-security-policy/ 301 @@ -383,14 +385,14 @@ /docs/user-guide/persistent-volumes/index /docs/concepts/storage/persistent-volumes/ 301 /docs/user-guide/persistent-volumes/index.md /docs/concepts/storage/persistent-volumes/ 301 /docs/user-guide/persistent-volumes/walkthrough/ /docs/tasks/configure-pod-container/configure-persistent-volume-storage/ 301 -/docs/user-guide/pod-preset/ /docs/tasks/inject-data-application/podpreset/ 301 +/docs/user-guide/pod-preset/ /docs/concepts/workloads/pods/podpreset/ 301 /docs/user-guide/pod-security-policy/ /docs/concepts/policy/pod-security-policy/ 301 /docs/user-guide/pod-states/ /docs/concepts/workloads/pods/pod-lifecycle/ 301 -/docs/user-guide/pod-templates/ /docs/concepts/workloads/pods/pod-overview/ 301 +/docs/user-guide/pod-templates/ /docs/concepts/workloads/pods/#pod-templates 301 /docs/user-guide/pods/ /docs/concepts/workloads/pods/pod/ 301 /docs/user-guide/pods/init-container/ /docs/concepts/workloads/pods/init-containers/ 301 -/docs/user-guide/pods/multi-container/ /docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/ 301 -/docs/user-guide/pods/single-container/ /docs/tasks/run-application/run-stateless-application-deployment/ 301 +/docs/user-guide/pods/multi-container/ /docs/concepts/workloads/pods/#using-pods 301 +/docs/user-guide/pods/single-container/ /docs/concepts/workloads/pods/#using-pods 301 /docs/user-guide/prereqs/ /docs/tasks/tools/install-kubectl/ 301 /docs/user-guide/production-pods/ /docs/tasks/ 301 /docs/user-guide/projected-volume/ /docs/tasks/configure-pod-container/configure-projected-volume-storage/ 301 From 078acc058c812b40c245a4d97ef09d044afe89ed Mon Sep 17 00:00:00 2001 From: xieyanker Date: Mon, 27 Jul 2020 11:18:39 +0800 Subject: [PATCH 80/86] Remove redundant container-environment-variables page --- .../container-environment-variables.md | 63 ------------------- 1 file changed, 63 deletions(-) delete mode 100644 content/zh/docs/concepts/containers/container-environment-variables.md diff --git a/content/zh/docs/concepts/containers/container-environment-variables.md b/content/zh/docs/concepts/containers/container-environment-variables.md deleted file mode 100644 index 5f797a856c..0000000000 --- a/content/zh/docs/concepts/containers/container-environment-variables.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -approvers: -- mikedanese -- thockin -title: 容器环境变量 -content_type: concept ---- - - - -本文介绍容器环境中对容器可用的资源。 - - - -{{< toc >}} - - - -## 容器环境 - -Kubernetes 容器环境为容器提供了几类重要的资源： - -* 一个文件系统，其中包含一个[镜像](/docs/concepts/containers/images/)和一个或多个[卷](/docs/concepts/storage/volumes/)。 -* 容器本身相关的信息。 -* 集群中其他对象相关的信息。 - -### 容器信息 - -容器的 *hostname* 是容器所在的 Pod 名称。 可以通过 `hostname` 命令或调用 libc 中的 -[`gethostname`](http://man7.org/linux/man-pages/man2/gethostname.2.html) -函数来获取。 - -Pod 名称和名字空间可以通过 -[downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) 以环境变量方式访问。 - -与 Docker 镜像中静态指定的环境变量一样，Pod 中用户定义的环境变量也可用于容器。 - -### 集群信息 - -容器创建时运行的所有服务的列表都会作为环境变量提供给容器。 -这些环境变量与 Docker 链接语法相匹配。 - -对一个名为 *foo* ，映射到名为 *bar* 的容器端口的服务， -会定义如下变量： - -```shell -FOO_SERVICE_HOST=<服务所在的主机地址> -FOO_SERVICE_PORT=<服务所启用的端口> -``` - -服务具有专用 IP 地址，如果启用了 [DNS 插件](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)，还可以在容器中通过 DNS 进行访问。 - - - -## {{% heading "whatsnext" %}} - - -* 查看[容器生命周期挂钩（hooks）](/docs/concepts/containers/container-lifecycle-hooks/)了解更多。 -* 获取[为容器生命周期事件附加处理程序](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)的实践经验。 - - - - From bdfc63c541b8c621daeee226db037f1bb3244a26 Mon Sep 17 00:00:00 2001 From: xieyanker Date: Mon, 27 Jul 2020 11:38:00 +0800 Subject: [PATCH 81/86] Fix zh translate --- content/zh/docs/concepts/workloads/pods/disruptions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/concepts/workloads/pods/disruptions.md b/content/zh/docs/concepts/workloads/pods/disruptions.md index 7c53f556bd..e47577bfe1 100644 --- a/content/zh/docs/concepts/workloads/pods/disruptions.md +++ b/content/zh/docs/concepts/workloads/pods/disruptions.md @@ -87,7 +87,7 @@ actions initiated by the application owner and those initiated by a Cluster Administrator. Typical application owner actions include: --> -我们称其他情况为*自愿干扰*。包括由应用程序所有者发起的操作和由集群管理员发起的操作。典型的应用程序所有者的 +我们称其他情况为*自愿干扰*。包括由应用程序所有者发起的操作和由集群管理员发起的操作。典型的应用程序所有者的操 作包括： -{{< /note >}} - 默认情况下，`kubectl get` 和 `kubectl describe` 避免显示密码的内容。 这是为了防止机密被意外地暴露给旁观者或存储在终端日志中。 +{{< /note >}} + From 9c24d968856372a428174accd476fd8c8371c56b Mon Sep 17 00:00:00 2001 From: Richard Mokua Date: Mon, 27 Jul 2020 12:54:43 +0200 Subject: [PATCH 84/86] Update audit.md volume mount indentation correction --- .../docs/tasks/debug-application-cluster/audit.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/content/en/docs/tasks/debug-application-cluster/audit.md b/content/en/docs/tasks/debug-application-cluster/audit.md index 3addb29be2..de4f965932 100644 --- a/content/en/docs/tasks/debug-application-cluster/audit.md +++ b/content/en/docs/tasks/debug-application-cluster/audit.md @@ -142,12 +142,13 @@ then mount the volumes: ``` -- mountPath: /etc/kubernetes/audit-policy.yaml - name: audit - readOnly: true -- mountPath: /var/log/audit.log - name: audit-log - readOnly: false +volumeMounts: + - mountPath: /etc/kubernetes/audit-policy.yaml + name: audit + readOnly: true + - mountPath: /var/log/audit.log + name: audit-log + readOnly: false ``` finally the hostPath: From 052b7fb852a1af162c3e5c041429785732345a13 Mon Sep 17 00:00:00 2001 From: Eric Briand <1011902+ebriand@users.noreply.github.com> Date: Mon, 27 Jul 2020 16:09:07 +0200 Subject: [PATCH 85/86] Renamed super.mycompany.com into images.my-company.example --- .../concepts/configuration/manage-resources-containers.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/en/docs/concepts/configuration/manage-resources-containers.md b/content/en/docs/concepts/configuration/manage-resources-containers.md index 275b70866a..f791510b39 100644 --- a/content/en/docs/concepts/configuration/manage-resources-containers.md +++ b/content/en/docs/concepts/configuration/manage-resources-containers.md @@ -133,7 +133,7 @@ metadata: spec: containers: - name: app - image: super.mycompany.com/app:v4 + image: images.my-company.example/app:v4 env: resources: requests: @@ -143,7 +143,7 @@ spec: memory: "128Mi" cpu: "500m" - name: log-aggregator - image: super.mycompany.com/log-aggregator:v6 + image: images.my-company.example/log-aggregator:v6 resources: requests: memory: "64Mi" @@ -329,14 +329,14 @@ metadata: spec: containers: - name: app - image: super.mycompany.com/app:v4 + image: images.my-company.example/app:v4 resources: requests: ephemeral-storage: "2Gi" limits: ephemeral-storage: "4Gi" - name: log-aggregator - image: super.mycompany.com/log-aggregator:v6 + image: images.my-company.example/log-aggregator:v6 resources: requests: ephemeral-storage: "2Gi" From 0e1678f78b543581327759d804854f281769d7c4 Mon Sep 17 00:00:00 2001 From: micnncim Date: Tue, 28 Jul 2020 04:35:12 +0900 Subject: [PATCH 86/86] Fix typo in pod-lifecycle.md --- content/en/docs/concepts/workloads/pods/pod-lifecycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md index 9075bf1a8b..2b292d376d 100644 --- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md @@ -164,7 +164,7 @@ Field name | Description `lastProbeTime` | Timestamp of when the Pod condition was last probed. `lastTransitionTime` | Timestamp for when the Pod last transitioned from one status to another. `reason` | Machine-readable, UpperCamelCase text indicating the reason for the condition's last transition. -`messsage | Human-readable message indicating details about the last status transition. +`message` | Human-readable message indicating details about the last status transition. ### Pod readiness {#pod-readiness-gate}