jiebi/CodeConvo huggingface dataset:
A cluster consists of a master API server and a set of worker VMs called nodes. <del> Create a cluster via the Console: *Compute > Container Engine > Container Clusters > New container cluster*. Leave all the options default, and you should get a Kubernetes cluster with three nodes, ready to receive your container image. </del> <ins> Create a cluster via the Console: *Compute > Container Engine > Container Clusters > New container cluster*. Set the name to 'hello-world', leaving all other options default.  You should get a Kubernetes cluster with three nodes, ready to receive your container image. </ins> ![image](/images/hellonode/image_11.png)
Hopefully I can do some more posts about advanced Kubernetes topics such as changing the cluster size and number of Node.js web server replicas, using different environments (dev, staging, prod) on the same cluster, and doing rolling updates. Thanks to [Mark Mandel](https://medium.com/@markmandel), [Aja Hammerly](https://medium.com/@thagomizer), and [Jack Wilber](https://medium.com/@jack.g.wilber). [Some rights reserved](http://creativecommons.org/licenses/by/4.0/) by the author.
#### Dockerfile ```conf <del> FROM node:0.12 </del> <ins> FROM node:4.4 </ins> EXPOSE 8080 COPY server.js . CMD node server.js ``` <del> This "recipe" for the Docker image will start from the Node 0.12 image found on the Docker registry, expose port 8080, copy our `server.js` file to the image and start the Node server. </del> <ins> This "recipe" for the Docker image will start from the official Node.js LTS image found on the Docker registry, expose port 8080, copy our `server.js` file to the image and start the Node server. </ins> Now build an image of your container by running `docker build`, tagging the image with the Google  Container Registry repo for your `PROJECT_ID`:
{ type: 0, name: 'ASM Technologies Limited', <del> logo: 'asmtech', </del> <ins> logo: 'asm', </ins> link: 'http://www.asmtech.com/', <del> blurb: 'http://www.asmtech.com/audience-channels/software_publisher/' </del> <ins> blurb: 'Our technology supply chain portfolio enables your software products to be accessible, viable and available more effectively.' </ins> }, { type: 1,
- Subject-matching properties: - `user`, type string; the user-string from `--token-auth-file`. If you specify `user`, it must match the username of the authenticated user. - `group`, type string; if you specify `group`, it must match one of the groups of the authenticated user. `system:authenticated` matches all authenticated requests. `system:unauthenticated` matches all unauthenticated requests. <del> - `readonly`, type boolean, when true, means that the policy only applies to get, list, and watch operations. </del> - Resource-matching properties: <del> - `apiGroup`, type string; an API group, such as `extensions`. `*` matches all API groups. - `namespace`, type string; a namespace string. `*` matches all resource requests. - `resource`, type string; a resource, such as `pods`. `*` matches all resource requests. </del> <ins> - `apiGroup`, type string; an API group. - Ex: `extensions` - Wildard: `*` matches all API groups. - `namespace`, type string; a namespace. - Ex: `kube-system` - Wildard: `*` matches all resource requests. - `resource`, type string; a resource type - Ex: `pods` - Wildcard: `*` matches all resource requests. </ins> - Non-resource-matching properties: <del> - `nonResourcePath`, type string; matches the non-resource request paths (like `/version` and `/apis`). `*` matches all non-resource requests. `/foo/*` matches `/foo/` and all of its subpaths. </del> <ins> - `nonResourcePath`, type string; non-resource request paths. - Ex: `/version` or `/apis` - Wildcard: - `*` matches all non-resource requests. - `/foo/*` matches `/foo/` and all of its subpaths. - `readonly`, type boolean, when true, means that the policy only applies to get, list, and watch operations. </ins> <del> An unset property is the same as a property set to the zero value for its type </del> <ins> **NOTES:** An unset property is the same as a property set to the zero value for its type </ins> (e.g. empty string, 0, false). However, unset should be preferred for readability.
We also allow users to customize garbage collection policy through the following kubelet flags: 1. `minimum-container-ttl-duration`, minimum age for a finished container before it is <del> garbage collected. Default is 0 minute, which means any finished container will be garbaged collected. 2. `maximum-dead-containers-per-container`, maximum number of old instances to retain </del> <ins> garbage collected. Default is 0 minute, which means every finished container will be garbaged collected. 2. `maximum-dead-containers-per-container`, maximum number of old instances to be retained </ins> per container. Default is 1. 3. `maximum-dead-containers`, maximum number of old instances of containers to retain globally. Default is -1, which means there is no global limit.
<div class="row"> <div class="col-md-8"> <p><b>The Master is responsible for managing the cluster.</b> The master coordinates all activities in your cluster, such as scheduling applications, maintaining applications' desired state, scaling applications, and rolling out new updates.</p> <del> <p><b>A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster.</b> Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes master. The node should also have tools for handling container operations, such as <a href="https://www.docker.com/">Docker</a> or <a href="https://coreos.com/rkt/">rtk</a>. A Kubernetes cluster that handles production traffic should have a minimum of three nodes.</p> </del> <ins> <p><b>A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster.</b> Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes master. The node should also have tools for handling container operations, such as <a href="https://www.docker.com/">Docker</a> or <a href="https://coreos.com/rkt/">rkt</a>. A Kubernetes cluster that handles production traffic should have a minimum of three nodes.</p> </ins> </div> <div class="col-md-4">
Now, re-run the test: ```console <del> $ for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; do </del> <ins> $ for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; done </ins> client_address=104.132.1.79 ```
(backward-compatible) changes to the way the Kubernetes cluster DNS server processes DNS queries, to facilitate the lookup of federated services (which span multiple Kubernetes clusters). <del> See the [Cluster Federation Administrators' Guide](/docs/admin/federation/index.md) for more </del> <ins> See the [Cluster Federation Administrators' Guide](/docs/admin/federation) for more </ins> details on Cluster Federation and multi-site support. ## References
are certain circumstances where two jobs might be created, or no job might be created. We attempt to make these rare, but do not completely prevent them. Therefore, jobs should be _idempotent_. <del> The job is responsible for retrying pods, parallelism among pods it creates, and determining the success or failure of the set of pods. A cron job does not examine pods at all. </del> <ins> If `startingDeadlineSeconds` is set to a large value or left unset (the default) and if `concurrentPolicy` is set to `AllowConcurrent`, the jobs will always run at least once. Jobs may fail to run if the CronJob controller is not running or broken for a span of time from before the start time of the CronJob to start time plus `startingDeadlineSeconds`, or if the span covers multiple start times and `concurrencyPolicy` does not allow concurrency. For example, suppose a cron job is set to start at exactly `08:30:00` and its `startingDeadlineSeconds` is set to 10, if the CronJob controller happens to be down from `08:29:00` to `08:42:00`, the job will not start. Set a longer `startingDeadlineSeconds` if starting later is better than not starting at all. The job is only responsible for creating Jobs that match its schedule, and the the Job in turn is responsible for the management of the Pods it represents. </ins> ## Writing a Cron Job Spec
38s        37s        2    {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}                Warning        FailedSync    Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1" 1m         22s         2     {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}    spec.containers{main}    Warning        FailedPostStartHook ``` <ins> ## What's Next - See an example of [using container lifecycle hooks](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) </ins>
kubectl exec -ti cassandra-0 -- nodetool status # cleanup <del> grace=$(kubectl get po cassandra-0 --template '{{.spec.terminationGracePeriodSeconds}}')  </del> <ins> grace=$(kubectl get po cassandra-0 -o=jsonpath='{.spec.terminationGracePeriodSeconds}')  </ins> && kubectl delete statefulset,po -l app=cassandra  && echo "Sleeping $grace"  && sleep $grace
Use the following commands to delete the StatefulSet. ```console <del> $ grace=$(kubectl get po cassandra-0 --template '{{.spec.terminationGracePeriodSeconds}}')  </del> <ins> $ grace=$(kubectl get po cassandra-0 -o=jsonpath='{.spec.terminationGracePeriodSeconds}')  </ins> && kubectl delete statefulset -l app=cassandra  && echo "Sleeping $grace"  && sleep $grace
/docs/admin/     /docs/concepts/cluster-administration/cluster-administration-overview/ 301 /docs/admin/add-ons/     /docs/concepts/cluster-administration/addons/ 301 <ins> /docs/admin/addons/     /docs/concepts/cluster-administration/addons/ 301 </ins> /docs/admin/apparmor/     /docs/tutorials/clusters/apparmor/ 301 /docs/admin/audit/     /docs/tasks/debug-application-cluster/audit/ 301 /docs/admin/authorization/rbac.md     /docs/admin/authorization/rbac/ 301
* One or more machines running Ubuntu 16.04+, Debian 9, CentOS 7, RHEL 7, Fedora 25/26 (best-effort) or HypriotOS v1.0.1+ * 1GB or more of RAM per machine (any less will leave little room for your apps) * Full network connectivity between all machines in the cluster (public or private network is fine) <del> * Unique MAC address and product_uuid for every node </del> <ins> * Unique hostname, MAC address, and product_uuid for every node </ins> * Certain ports are open on your machines. See the section below for more details * Swap disabled. You must disable swap in order for the kubelet to work properly. * Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1`
* [Daemon Sets](http://kubernetes.io/docs/admin/daemons/) which ensure that all or some of the nodes in your cluster run a copy of a Pod. * [Deployments](http://kubernetes.io/docs/user-guide/deployments/) which provide declarative updates for Pods and Replica Sets (the next-generation [Replication Controller](http://kubernetes.io/docs/user-guide/replication-controller/)) The Details page for a Deployment lists resource details, as well as new and old Replica Sets. The resource details also include information on the [RollingUpdate](http://kubernetes.io/docs/user-guide/rolling-updates/) strategy, if any. <del> * [Pet Sets](http://kubernetes.io/docs/user-guide/load-balancer/) (nominal Services, also known as load-balanced Services) for legacy application support. </del> <ins> * [Pet Sets](http://kubernetes.io/docs/user-guide/petset/) (nominal Services, also known as load-balanced Services) for legacy application support. </ins> * [Replica Sets](http://kubernetes.io/docs/user-guide/replicasets/) for using label selectors. * [Jobs](http://kubernetes.io/docs/user-guide/jobs/) for creating one or more Pods, ensuring that a specified number of them successfully terminate, and tracking the completions. * [Replication Controllers](http://kubernetes.io/docs/user-guide/replication-controller/)
/docs/tasks/administer-cluster/certificate-rotation/     /docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/ 301 /docs/tasks/administer-cluster/cilium-network-policy/     /docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy/ 301 /docs/tasks/administer-cluster/configure-namespace-isolation/     /docs/concepts/services-networking/network-policies/ 301 <ins> /docs/tasks/administer-cluster/configure-multiple-schedulers/     /docs/tasks/extend-kubernetes/configure-multiple-schedulers/ 301 </ins> /docs/tasks/administer-cluster/configure-pod-disruption-budget/     /docs/tasks/run-application/configure-pdb/ 301 /docs/tasks/administer-cluster/cpu-constraint-namespace/     /docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/ 301 /docs/tasks/administer-cluster/cpu-default-namespace/     /docs/tasks/administer-cluster/manage-resources/cpu-default-namespace 301
flag in the `docker run` command. - The `spec.containers[].resources.limits.cpu` is converted to its millicore value and <del> multiplied by 100. The resulting value is the total amount of CPU time that a container can use every 100ms. A container cannot use more than its share of CPU time during this interval. </del> <ins> multiplied by 100. The resulting value is the total amount of CPU time in microseconds that a container can use every 100ms. A container cannot use more than its share of CPU time during this interval. </ins> {{< note >}} The default quota period is 100ms. The minimum resolution of CPU quota is 1ms.
These controllers include: <del> * Node Controller * Responsible for noticing & responding when nodes go down. * Replication Controller * Responsible for maintaining the correct number of pods for every replication controller object in the system. * Endpoints Controller * Populates the Endpoints object (i.e., join Services & Pods). * Service Account & Token Controllers * Create default accounts and API access tokens for new namespaces. </del> <ins> * Node Controller: Responsible for noticing & responding when nodes go down. * Replication Controller: Responsible for maintaining the correct number of pods for every replication controller object in the system. * Endpoints Controller: Populates the Endpoints object (i.e., join Services & Pods). * Service Account & Token Controllers: Create default accounts and API access tokens for new namespaces. </ins> * ... and others. ### kube-scheduler
kubectl get svc my-nginx ``` ``` <del> NAME       TYPE        CLUSTER-IP     EXTERNAL-IP        PORT(S)               AGE my-nginx   ClusterIP   10.0.162.149   162.222.184.144    80/TCP,81/TCP,82/TCP  21s </del> <ins> NAME       TYPE           CLUSTER-IP     EXTERNAL-IP        PORT(S)               AGE my-nginx   LoadBalancer   10.0.162.149     xx.xxx.xxx.xxx     8080:30163/TCP        21s </ins> ``` ``` curl https://<EXTERNAL-IP> -k
<ins> --- title: Kindを使用してKubernetesをインストールする weight: 40 content_type: concept --- <!-- overview --> Kindは、Dockerコンテナをノードとして使用して、ローカルのKubernetesクラスターを実行するためのツールです。 <!-- body --> ## インストール [Kindをインストールする](https://kind.sigs.k8s.io/docs/user/quick-start/)を参照してください。 </ins>
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads) <del> {{< note >}} minikubeは、VMではなくホストでKubernetesコンポーネントを実行する`--vm-driver=none`オプションもサポートしています。 </del> <ins> Minikubeは、VMではなくホストでKubernetesコンポーネントを実行する`--vm-driver=none`オプションもサポートしています。 </ins> このドライバーを使用するには、[Docker](https://www.docker.com/products/docker-desktop)とLinux環境が必要ですが、ハイパーバイザーは不要です。 <del> noneドライバーを使用する場合は、[Docker](https://www.docker.com/products/docker-desktop)からdockerのaptインストールを使用することをおすすめします。 dockerのsnapインストールは、minikubeでは機能しません。 {{< /note >}} </del> <ins> Debian系のLinuxで`none`ドライバーを使用する場合は、snapパッケージではなく`.deb`パッケージを使用してDockerをインストールしてください。snapパッケージはMinikubeでは機能しません。 [Docker](https://www.docker.com/products/docker-desktop)から`.deb`パッケージをダウンロードできます。 {{< caution >}} `none` VMドライバーは、セキュリティとデータ損失の問題を引き起こす可能性があります。 `--vm-driver=none`を使用する前に、詳細について[このドキュメント](https://minikube.sigs.k8s.io/docs/reference/drivers/none/) を参照してください。 {{< /caution >}} MinikubeはDockerドライバーと似たような`vm-driver=podman`もサポートしています。Podmanを特権ユーザー権限(root user)で実行することは、コンテナがシステム上の利用可能な機能へ完全にアクセスするための最もよい方法です。 {{< caution >}} `podman` ドライバーは、rootでコンテナを実行する必要があります。これは、通常のユーザーアカウントが、コンテナの実行に必要とされるすべてのOS機能への完全なアクセスを持っていないためです。 {{< /caution >}} </ins> ### パッケージを利用したMinikubeのインストール
sudo install minikube /usr/local/bin/ ``` <ins> ### Homebrewを利用したMinikubeのインストール 別の選択肢として、Linux [Homebrew](https://docs.brew.sh/Homebrew-on-Linux)を利用してインストールできます。 ```shell brew install minikube ``` </ins> {{% /tab %}} {{% tab name="macOS" %}} ### kubectlのインストール
{{% /capture %}} <ins> ## インストールの確認 ハイパーバイザーとMinikube両方のインストール成功を確認するため、以下のコマンドをローカルKubernetesクラスターを起動するために実行してください: {{< note >}} `minikube start`で`--vm-driver`の設定をするため、次の`<driver_name>`の部分では、インストールしたハイパーバイザーの名前を小文字で入力してください。`--vm-driver`値のすべてのリストは、[specifying the VM driver documentation](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver)で確認できます。 {{< /note >}} ```shell minikube start --vm-driver=<driver_name> ``` `minikube start`が完了した場合、次のコマンドを実行してクラスターの状態を確認します。 ```shell minikube status ``` クラスターが起動していると、`minikube status`の出力はこのようになります。 ``` host: Running kubelet: Running apiserver: Running kubeconfig: Configured ``` 選択したハイパーバイザーでMinikubeが動作しているか確認した後は、そのままMinikubeを使い続けることもできます。また、クラスターを停止することもできます。クラスターを停止するためには、次を実行してください。 ```shell minikube stop ``` </ins> ## ローカル状態のクリーンアップ {#cleanup-local-state} もし以前に　Minikubeをインストールしていたら、以下のコマンドを実行します。
- A user who can create a Pod that uses a secret can also see the value of that secret. Even if the API server policy does not allow that user to read the Secret, the user could run a Pod which exposes the secret. <del> - Currently, anyone with root permission on any node can read _any_ secret from the API server, by impersonating the kubelet. It is a planned feature to only send secrets to nodes that actually require them, to restrict the impact of a root exploit on a single node. </del> ## {{% heading "whatsnext" %}}
<ins> --- title: Secret id: secret date: 2018-04-12 full_link: /ja/docs/concepts/configuration/secret/ short_description: > パスワードやOAuthトークン、SSHキーのような機密の情報を保持します。 aka: tags: - core-object - security --- パスワードやOAuthトークン、SSHキーのような機密の情報を保持します。 <!--more--> 機密情報の取り扱い方法を細かく制御することができ、保存時には[暗号化](/ja/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted)するなど、誤って公開してしまうリスクを減らすことができます。{{< glossary_tooltip text="Pod" term_id="pod" >}}は、ボリュームマウントされたファイルとして、またはPodのイメージをPullするkubeletによって、Secretを参照します。Secretは機密情報を扱うのに最適で、機密でない情報には[ConfigMap](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)が適しています。 </ins>
Example: <del> If `kube-proxy` version is **{{< skew latestVersion >}}**: </del> <ins> If `kube-proxy` version is **{{< skew oldestMinorVersion >}}**: </ins> <del> * `kubelet` version must be at the same minor version as **{{< skew latestVersion >}}**. </del> <ins> * `kubelet` version must be at the same minor version as **{{< skew oldestMinorVersion >}}**. </ins> * `kube-apiserver` version must be between **{{< skew oldestMinorVersion >}}** and **{{< skew latestVersion >}}**, inclusive.
英語 | 日本語 --------- | --------- <del> cluster|クラスター orchestrate(動詞)|オーケストレーションする Persistent Volume|KubernetesリソースとしてのPersistentVolumeはママ表記、一般的な用語としての場合は、永続ボリューム Deployment/Deploy|KubernetesリソースとしてのDeploymentはママ表記、一般的な用語としてのdeployの場合は、デプロイ </del> Addon/Add-on|アドオン <del> Quota|クォータ For more information|さらなる情報(一時的) prefix | プレフィックス container | コンテナ directory | ディレクトリ </del> <ins> Aggregation Layer | アグリゲーションレイヤー architecture | アーキテクチャ </ins> binary | バイナリ <ins> cluster|クラスター community | コミュニティ container | コンテナ </ins> controller | コントローラー <del> operator | オペレーター Aggregation Layer | アグリゲーションレイヤー </del> <ins> Deployment/Deploy|KubernetesリソースとしてのDeploymentはママ表記、一般的な用語としてのdeployの場合は、デプロイ directory | ディレクトリ For more information|さらなる情報(一時的) GitHub | GitHub (ママ表記) </ins> Issue | Issue (ママ表記) <ins> operator | オペレーター orchestrate(動詞)|オーケストレーションする Persistent Volume|KubernetesリソースとしてのPersistentVolumeはママ表記、一般的な用語としての場合は、永続ボリューム prefix | プレフィックス </ins> Pull Request | Pull Request (ママ表記) <del> GitHub | GitHub (ママ表記) </del> <ins> Quota|クォータ </ins> registry | レジストリ <del> architecture | アーキテクチャ </del> secure | セキュア <del> stacked | 積層(例: stacked etcd clusterは積層etcdクラスター) </del> a set of ~ | ～の集合 <del> community | コミュニティ </del> <ins> stacked | 積層(例: stacked etcd clusterは積層etcdクラスター) </ins> ### 備考
* 클라이언트는 `node2:nodePort`로 패킷을 보낸다. * `node2`는 소스 IP 주소(SNAT)를 패킷 상에서 자신의 IP 주소로 교체한다. <del> * `noee2`는 대상 IP를 패킷 상에서 파드의 IP로 교체한다. </del> <ins> * `node2`는 대상 IP를 패킷 상에서 파드의 IP로 교체한다. </ins> * 패킷은 node 1로 라우팅 된 다음 엔드포인트로 라우팅 된다. * 파드의 응답은 node2로 다시 라우팅된다. * 파드의 응답은 클라이언트로 다시 전송된다.
Kubernetes has a "hub-and-spoke" API pattern. All API usage from nodes (or the pods they run) terminate at the apiserver (none of the other control plane components are designed to expose remote services). The apiserver is configured to listen for remote connections on a secure HTTPS port (typically 443) with one or more forms of client [authentication](/docs/reference/access-authn-authz/authentication/) enabled. One or more forms of [authorization](/docs/reference/access-authn-authz/authorization/) should be enabled, especially if [anonymous requests](/docs/reference/access-authn-authz/authentication/#anonymous-requests) or [service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens) are allowed. <del> Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. For example, on a default GKE deployment, the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates. </del> <ins> Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. A good approach is that the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates. </ins> Pods that wish to connect to the apiserver can do so securely by leveraging a service account so that Kubernetes will automatically inject the public root certificate and a valid bearer token into the pod when it is instantiated. The `kubernetes` service (in all namespaces) is configured with a virtual IP address that is redirected (via kube-proxy) to the HTTPS endpoint on the apiserver.
## {{% heading "whatsnext" %}} <del> - [RuntimeClass Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) - [RuntimeClass Scheduling Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md) </del> <ins> - [RuntimeClass Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md) - [RuntimeClass Scheduling Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling) </ins> - Read about the [Pod Overhead](/docs/concepts/configuration/pod-overhead/) concept - [PodOverhead Feature Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
_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 <del> {{< glossary_tooltip text="containers" term_id="container" >}}, with shared storage/network resources, and a specification </del> <ins> [containers](/docs/concepts/containers/), with shared storage/network resources, and a specification </ins> 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