jiebi/CodeConvo huggingface dataset:
image again: ```shell <del> kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"gcr.io/google_containers/nginx-slim:0.8"}]' </del> <ins> kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"registry.k8s.io/nginx-slim:0.8"}]' </ins> ``` ``` statefulset.apps/web patched
__Important: You must have your own Ceph server running with the share exported before you can use it__ <del> See the [CephFS example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/cephfs/) for more details. </del> <ins> See the [CephFS example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/cephfs/) for more details. </ins> ### gitRepo
[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. This guide uses an [Ansible playbook](https://github.com/runseb/ansible-kubernetes). <del> This is a completely automated, a single playbook deploys Kubernetes based on the coreOS [instructions](/docs/getting-started-guides/coreos/coreos_multinode_cluster). </del> <ins> This is completely automated, a single playbook deploys Kubernetes. </ins> This [Ansible](http://ansibleworks.com) playbook deploys 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.
These guides are maintained by community members, cover specific platforms and use cases, and experiment with different ways of configuring Kubernetes on CoreOS. <del> [**Multi-node Cluster**](/docs/getting-started-guides/coreos/coreos_multinode_cluster) Set up a single master, multi-worker cluster on your choice of platform: AWS, GCE, or VMware Fusion. <hr/> </del> [**Easy Multi-node Cluster on Google Compute Engine**](https://github.com/rimusz/coreos-multi-node-k8s-gce/blob/master/README.md) Scripted installation of a single master, multi-worker cluster on GCE. Kubernetes components are managed by [fleet](https://github.com/coreos/fleet).
$ kubectl logs -f my-pod -c my-container              # stream pod container logs (stdout, multi-container case) $ kubectl run -i --tty busybox --image=busybox -- sh  # Run pod as interactive shell $ kubectl attach my-pod -i                            # Attach to Running Container <del> $ kubectl port-forward my-pod 5000:6000               # Forward port 6000 of Pod to your to 5000 on your local machine </del> <ins> $ kubectl port-forward my-pod 5000:6000               # Listen on port 5000 on the local machine and forward to port 6000 on my-pod </ins> $ kubectl exec my-pod -- ls /                         # Run command in existing pod (1 container case) $ kubectl exec my-pod -c my-container -- ls /         # Run command in existing pod (multi-container case) $ kubectl top pod POD_NAME --containers               # Show metrics for a given pod and its containers
* GCEPersistentDisk * AWSElasticBlockStore <ins> * AzureFile * FC (Fibre Channel) </ins> * NFS * iSCSI * RBD (Ceph Block Device) <ins> * CephFS * Cinder (OpenStack block storage) </ins> * Glusterfs <ins> * VsphereVolume </ins> * HostPath (single node testing only -- local storage is not supported in any way and WILL NOT WORK in a multi-node cluster)
### Access Modes <del> A `PersistentVolume` can be mounted on a host in any way supported by the resource provider.  Providers will have different capabilities and each PV's access modes are set to the specific modes supported by that particular volume.  For example, NFS can support multiple read/write clients, but a specific NFS PV might be exported on the server as read-only.  Each PV gets its own set of access modes describing that specific PV's capabilities. </del> <ins> A `PersistentVolume` can be mounted on a host in any way supported by the resource provider.  As shown in the table below, providers will have different capabilities and each PV's access modes are set to the specific modes supported by that particular volume.  For example, NFS can support multiple read/write clients, but a specific NFS PV might be exported on the server as read-only.  Each PV gets its own set of access modes describing that specific PV's capabilities. </ins> The access modes are:
> __Important!__ A volume can only be mounted using one access mode at a time, even if it supports many.  For example, a GCEPersistentDisk can be mounted as ReadWriteOnce by a single node or ReadOnlyMany by many nodes, but not at the same time. <ins> | Volume Plugin        | ReadWriteOnce| ReadOnlyMany| ReadWriteMany| | :---                 |     :---:    |    :---:    |    :---:     | | AWSElasticBlockStore | x            | -           | -            | | AzureFile            | x            | x           | x            | | CephFS               | x            | x           | x            | | Cinder               | x            | -           | -            | | FC                   | x            | x           | -            | | FlexVolume           | x            | x           | -            | | GCEPersistentDisk    | x            | x           | -            | | Glusterfs            | x            | x           | x            | | HostPath             | x            | -           | -            | | iSCSI                | x            | x           | -            | | NFS                  | x            | x           | x            | | RDB                  | x            | x           | -            | | VsphereVolume        | x            | -           | -            | </ins> ### Recycling Policy Current recycling policies are:
This page shows how to create an External Load Balancer. When creating a service, you have the option of automatically creating a <del> cloud network load balancer. This provides an externally-accessible IP address that sends traffic to the correct port on your cluster nodes _provided your cluster runs in a supported environment and is configured with the correct cloud load balancer provider package_. </del> <ins> cloud network load balancer. This provides an externally-accessible IP address that sends traffic to the correct port on your cluster nodes _provided your cluster runs in a supported environment and is configured with the correct cloud load balancer provider package_. For information on provisioning and using an Ingress resource that can give services externally-reachable URLs, load balance the traffic, terminate SSL etc., please check the [Ingress](/docs/concepts/services-networking/ingress/) documentation. </ins> {% endcapture %}
1. Create the Pod: <del> kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/pod-redis.yaml </del> <ins> kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/pod-redis.yaml </ins> 1. Verify that the Pod's Container is running, and then watch for changes to the Pod: <del> kubectl get --watch pod redis </del> <ins> kubectl get --watch pod redis </ins> The output looks like this: <del> NAME      READY     STATUS    RESTARTS   AGE redis     1/1       Running   0          13s </del> <ins> NAME      READY     STATUS    RESTARTS   AGE redis     1/1       Running   0          13s </ins> 1. In another terminal, get a shell to the running Container: <del> kubectl exec -it redis -- /bin/bash </del> <ins> kubectl exec -it redis -- /bin/bash </ins> 1. In your shell, go to `/data/redis`, and create a file: <del> root@redis:/data/redis# echo Hello > test-file </del> <ins> root@redis:/data/redis# echo Hello > test-file </ins> 1. In your shell, list the running processes: <del> root@redis:/data/redis# ps aux </del> <ins> root@redis:/data/redis# ps aux </ins> The output is similar to this: <del> USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND redis        1  0.1  0.1  33308  3828 ?        Ssl  00:46   0:00 redis-server *:6379 root        12  0.0  0.0  20228  3020 ?        Ss   00:47   0:00 /bin/bash root        15  0.0  0.0  17500  2072 ?        R+   00:48   0:00 ps aux </del> <ins> USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND redis        1  0.1  0.1  33308  3828 ?        Ssl  00:46   0:00 redis-server *:6379 root        12  0.0  0.0  20228  3020 ?        Ss   00:47   0:00 /bin/bash root        15  0.0  0.0  17500  2072 ?        R+   00:48   0:00 ps aux </ins> 1. In your shell, kill the redis process: <del> root@redis:/data/redis# kill <pid> </del> <ins> root@redis:/data/redis# kill <pid> </ins> where `<pid>` is the redis process ID (PID). 1. In your original terminal, watch for changes to the redis Pod. Eventually, you will see something like this: <del> NAME      READY     STATUS     RESTARTS   AGE redis     1/1       Running    0          13s redis     0/1       Completed  0         6m redis     1/1       Running    1         6m </del> <ins> NAME      READY     STATUS     RESTARTS   AGE redis     1/1       Running    0          13s redis     0/1       Completed  0         6m redis     1/1       Running    1         6m </ins> At this point, the Container has terminated and restarted. This is because the redis Pod has a
<!-- overview --> Many applications rely on configuration which is used during either application initialization or runtime. Most of the times there is a requirement to adjust values assigned to configuration parameters. <del> ConfigMaps is the kubernetes way to inject application pods with configuration data. </del> <ins> ConfigMaps are the Kubernetes way to inject application pods with configuration data. </ins> ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable. This page provides a series of usage examples demonstrating how to create ConfigMaps and configure Pods using data stored in ConfigMaps.
You can project keys to specific paths and specific permissions on a per-file basis. The [Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod) user guide explains the syntax. <del> ### Optional References A ConfigMap reference may be marked "optional".  If the ConfigMap is non-existent, the mounted volume will be empty. If the ConfigMap exists, but the referenced key is non-existent the path will be absent beneath the mount point. ### Mounted ConfigMaps are updated automatically When a mounted ConfigMap is updated, the projected content is eventually updated too.  This applies in the case where an optionally referenced ConfigMap comes into existence after a pod has started. Kubelet checks whether the mounted ConfigMap is fresh on every periodic sync. However, it uses its local TTL-based cache for getting the current value of the ConfigMap. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as kubelet sync period (1 minute by default) + TTL of ConfigMaps cache (1 minute by default) in kubelet. {{< note >}} A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes/#using-subpath) volume will not receive ConfigMap updates. {{< /note >}} </del> <!-- discussion -->
### Restrictions <del> - You must create a ConfigMap before referencing it in a Pod specification (unless you mark the ConfigMap as "optional"). If you reference a ConfigMap that doesn't exist, the Pod won't start. Likewise, references to keys that don't exist in the ConfigMap will prevent the pod from starting. </del> <ins> - You must create a ConfigMap before referencing it in a Pod specification, or mark the ConfigMap as "optional" (see [Optional ConfigMaps](#optional-configmaps)). If you reference a ConfigMap that doesn't exist, or hasn't been marked as "optional" the Pod won't start. Likewise, references to keys that don't exist in the ConfigMap will prevent the pod from starting. </ins> - If you use `envFrom` to define environment variables from ConfigMaps, keys that are considered invalid will be skipped. The pod will be allowed to start, but the invalid names will be recorded in the event log (`InvalidVariableNames`). The log message lists each skipped key. For example:
- You can't use ConfigMaps for {{< glossary_tooltip text="static pods" term_id="static-pod" >}}, because the Kubelet does not support this. <ins> ### Optional ConfigMaps In a Pod, or pod template, you can mark a reference to a ConfigMap as _optional_. If the ConfigMap is non-existent, the configuration for which it provides data in the Pod (e.g. environment variable, mounted volume) will be empty. If the ConfigMap exists, but the referenced key is non-existent the data is also empty. #### Optional ConfigMap in environment variables There might be situations where environment variables are not always required. You can mark an environment variables for a container as optional, like this: ```yaml apiVersion: v1 kind: Pod metadata: name: dapi-test-pod spec: containers: - name: test-container image: gcr.io/google_containers/busybox command: [ "/bin/sh", "-c", "env" ] env: - name: SPECIAL_LEVEL_KEY valueFrom: configMapKeyRef: name: a-config key: akey optional: true # mark the variable as optional restartPolicy: Never ``` If you run this pod, and there is no ConfigMap named `a-config`, the output is empty. If you run this pod, and there is a ConfigMap named `a-config` but that ConfigMap doesn't have a key named `akey`, the output is also empty. If you do set a value for `akey` in the `a-config` ConfigMap, this pod prints that value and then terminates. #### Optional ConfigMap via volume plugin Volumes and files provided by a ConfigMap can be also be marked as optional. The ConfigMap or the key specified does not have to exist. The mount path for such items will always be created. ```yaml apiVersion: v1 kind: Pod metadata: name: dapi-test-pod spec: containers: - name: test-container image: gcr.io/google_containers/busybox command: [ "/bin/sh", "-c", "ls /etc/config" ] volumeMounts: - name: config-volume mountPath: /etc/config volumes: - name: config-volume configMap: name: no-config optional: true # mark the source ConfigMap as optional restartPolicy: Never ``` If you run this pod, and there is no ConfigMap named `no-config`, the mounted volume will be empty. ### Mounted ConfigMaps are updated automatically When a mounted ConfigMap is updated, the projected content is eventually updated too.  This applies in the case where an optionally referenced ConfigMap comes into existence after a pod has started. The kubelet checks whether the mounted ConfigMap is fresh on every periodic sync. However, it uses its local TTL-based cache for getting the current value of the ConfigMap. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as kubelet sync period (1 minute by default) + TTL of ConfigMaps cache (1 minute by default) in kubelet. {{< note >}} A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes/#using-subpath) volume will not receive ConfigMap updates. {{< /note >}} </ins> ## {{% heading "whatsnext" %}}
- architecture - operation --- <del> Cloud Controller Manager is an alpha feature in 1.8. In upcoming releases it will be the preferred way to integrate Kubernetes with any cloud. </del> <ins> Cloud Controller Manager is a Kubernetes component that embeds cloud-specific control logic. </ins> <!--more--> <del> Kubernetes v1.6 contains a new binary called cloud-controller-manager. cloud-controller-manager is a daemon that embeds cloud-specific control loops. These cloud-specific control loops were originally in the kube-controller-manager. Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the cloud-controller-manager binary allows cloud vendors to evolve independently from the core Kubernetes code. </del> <ins> Originally part of the kube-controller-manager, the cloud-controller-manager is responsible to decoupling the interoperability logic between Kubernetes and the underlying cloud infrastructure, enabling cloud providers to release features at a different pace compared to the main project. </ins>
title: HostAliases id: HostAliases date: 2019-01-31 <del> full_link: /docs/reference/generated/kubernetes-api/v1.13/#hostalias-v1-core </del> <ins> full_link: /docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core </ins> short_description: > A HostAliases is a mapping between the IP address and hostname to be injected into a Pod's hosts file.
<!--more--> <del> [HostAliases](/docs/reference/generated/kubernetes-api/v1.13/#hostalias-v1-corev) is an optional list of hostnames and IP addresses that will be injected into the Pod's hosts file if specified. This is only valid for non-hostNetwork Pods. </del> <ins> [HostAliases](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core) is an optional list of hostnames and IP addresses that will be injected into the Pod's hosts file if specified. This is only valid for non-hostNetwork Pods. </ins>
## Metric lifecycle <del> Alpha metric →  Stable metric →  Deprecated metric →  Hidden metric → Deletion </del> <ins> Alpha metric →  Stable metric →  Deprecated metric →  Hidden metric → Deleted metric </ins> <del> Alpha metrics have no stability guarantees; as such they can be modified or deleted at any time. </del> <ins> Alpha metrics have no stability guarantees. These metrics can be modified or deleted at any time. </ins> <del> Stable metrics can be guaranteed to not change; Specifically, stability means: </del> <ins> Stable metrics are guaranteed to not change. This means: * A stable metric without a deprecated signature will not be deleted or renamed * A stable metric's type will not be modified </ins> <del> * the metric itself will not be deleted (or renamed) * the type of metric will not be modified </del> <ins> Deprecated metrics are slated for deletion, but are still available for use. These metrics include an annotation about the version in which they became deprecated. </ins> <del> Deprecated metric signal that the metric will eventually be deleted; to find which version, you need to check annotation, which includes from which kubernetes version that metric will be considered deprecated. </del> <ins> For example: </ins> <del> Before deprecation: </del> <ins> * Before deprecation </ins> <del> ``` # HELP some_counter this counts things # TYPE some_counter counter some_counter 0 ``` </del> <ins> ``` # HELP some_counter this counts things # TYPE some_counter counter some_counter 0 ``` </ins> <del> After deprecation: </del> <ins> * After deprecation </ins> <del> ``` # HELP some_counter (Deprecated since 1.15.0) this counts things # TYPE some_counter counter some_counter 0 ``` </del> <ins> ``` # HELP some_counter (Deprecated since 1.15.0) this counts things # TYPE some_counter counter some_counter 0 ``` </ins> <del> Once a metric is hidden then by default the metrics is not published for scraping. To use a hidden metric, you need to override the configuration for the relevant cluster component. </del> <ins> Hidden metrics are no longer published for scraping, but are still available for use. To use a hidden metric, please refer to the [Show hidden metrics](#show-hidden-metrics) section. </ins> <del> Once a metric is deleted, the metric is not published. You cannot change this using an override. </del> <ins> Deleted metrics are no longer published and cannot be used. </ins> <del> ## Show Hidden Metrics </del> <ins> ## Show hidden metrics </ins> As described above, admins can enable hidden metrics through a command-line flag on a specific binary. This intends to be used as an escape hatch for admins if they missed the migration of the metrics deprecated in the last release.
## IBM Cloud Kubernetes Service ### Compute nodes <del> By using the IBM Cloud Kubernetes Service provider, you can create clusters with a mixture of virtual and physical (bare metal) nodes in a single zone or across multiple zones in a region. For more information, see [Planning your cluster and worker node setup](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters#plan_clusters). </del> <ins> By using the IBM Cloud Kubernetes Service provider, you can create clusters with a mixture of virtual and physical (bare metal) nodes in a single zone or across multiple zones in a region. For more information, see [Planning your cluster and worker node setup](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodes). </ins> The name of the Kubernetes Node object is the private IP address of the IBM Cloud Kubernetes Service worker node instance.
title: 클러스터(Cluster) id: cluster date: 2019-06-15 <del> full_link: </del> <ins> full_link: </ins> short_description: > <del> 컨테이너화된 애플리케이션을 실행하는 {{< glossary_tooltip text="노드" term_id="node" >}}라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다. </del> <ins> 컨테이너화된 애플리케이션을 실행하는 노드라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다. </ins> aka: tags: - fundamental - operation --- <del> 컨테이너화된 애플리케이션을 실행하는 노드라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다. </del> <ins> 컨테이너화된 애플리케이션을 실행하는 {{< glossary_tooltip text="노드" term_id="node" >}}라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다. </ins> <del> <!--more--> </del> <ins> <!--more--> </ins> 워커 노드는 애플리케이션의 구성요소인 {{< glossary_tooltip text="파드" term_id="pod" >}}를 호스트한다. {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}은 워커 노드와
<table> <tr><th>String</th><th>API Object</th></tr> <tr><td>"pods"</td><td>Pod</td></tr> <del> <tr><td>"services</td><td>Service</td></tr> </del> <ins> <tr><td>"services"</td><td>Service</td></tr> </ins> <tr><td>"replicationcontrollers"</td><td>ReplicationController</td></tr> <tr><td>"resourcequotas"</td><td>ResourceQuota</td></tr> <tr><td>"secrets"</td><td>Secret</td></tr>
{{- $prepend := .Get "prepend" }} {{- $glossaryBundle := site.GetPage "page" "docs/reference/glossary" -}} {{- $glossaryItems :=  $glossaryBundle.Resources.ByType "page" -}} <del> {{- $term_info := $glossaryItems.GetMatch (printf "%s*" $id ) -}} </del> <ins> {{- $term_info := $glossaryItems.GetMatch (printf "%s.md" $id ) -}} </ins> {{- 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 -}}
- Assign `Doc Review: Open Issues` or `Tech Review: Open Issues` for PRs that have been reviewed and require further input or action before merging. - Assign `/lgtm` and `/approve` labels to PRs that can be merged. - Merge PRs when they are ready, or close PRs that shouldn’t be accepted. <ins> - Consider accepting accurate technical content even if the content meets only some of the docs' [style guidelines](/docs/contribute/style/style-guide/). Open a new issue with the label `good first issue` to address style concerns. </ins> - Triage and tag incoming issues daily. See [Triage and categorize issues](/docs/contribute/review/for-approvers/#triage-and-categorize-issues) for guidelines on how SIG Docs uses metadata. ### Helpful GitHub queries for wranglers
* `TYPE`: Specifies the [resource type](#resource-types). Resource types are case-insensitive and you can specify the singular, plural, or abbreviated forms. For example, the following commands produce the same output: <del> ```shell kubectl get pod pod1 kubectl get pods pod1 kubectl get po pod1 ``` </del> <ins> ```shell kubectl get pod pod1 kubectl get pods pod1 kubectl get po pod1 ``` </ins> * `NAME`: Specifies the name of the resource. Names are case-sensitive. If the name is omitted, details for all resources are displayed, for example `kubectl get pods`.
## {{% heading "whatsnext" %}} <del> [Cron expression format](https://pkg.go.dev/github.com/robfig/cron?tab=doc#hdr-CRON_Expression_Format) </del> <ins> [Cron expression format](https://en.wikipedia.org/wiki/Cron) </ins> documents the format of CronJob `schedule` fields. For instructions on creating and working with cron jobs, and for an example of CronJob