jiebi/CodeConvo huggingface dataset:
### Default deny all ingress traffic <del> You can create a "default" isolation policy for a namespace by creating a NetworkPolicy that selects all pods but does not allow any ingress traffic to those pods. </del> <ins> You can create a "default" ingress isolation policy for a namespace by creating a NetworkPolicy that selects all pods but does not allow any ingress traffic to those pods. </ins> {{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}} <del> This ensures that even pods that aren't selected by any other NetworkPolicy will still be isolated. This policy does not change the default egress isolation behavior. </del> <ins> This ensures that even pods that aren't selected by any other NetworkPolicy will still be isolated for ingress. This policy does not affect isolation for egress from any pod. </ins> <del> ### Default allow all ingress traffic </del> <ins> ### Allow all ingress traffic </ins> <del> If you want to allow all traffic to all pods in a namespace (even if policies are added that cause some pods to be treated as "isolated"), you can create a policy that explicitly allows all traffic in that namespace. </del> <ins> If you want to allow all incoming connections to all pods in a namespace, you can create a policy that explicitly allows that. </ins> {{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}} <ins> With this policy in place, no additional policy or policies can cause any incoming connection to those pods to be denied.  This policy has no effect on isolation for egress from any pod. </ins> ### Default deny all egress traffic You can create a "default" egress isolation policy for a namespace by creating a NetworkPolicy that selects all pods but does not allow any egress traffic from those pods.
{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}} This ensures that even pods that aren't selected by any other NetworkPolicy will not be allowed egress traffic. This policy does not <del> change the default ingress isolation behavior. </del> <ins> change the ingress isolation behavior of any pod. </ins> <del> ### Default allow all egress traffic </del> <ins> ### Allow all egress traffic </ins> <del> If you want to allow all traffic from all pods in a namespace (even if policies are added that cause some pods to be treated as "isolated"), you can create a policy that explicitly allows all egress traffic in that namespace. </del> <ins> If you want to allow all connections from all pods in a namespace, you can create a policy that explicitly allows all outgoing connections from pods in that namespace. </ins> {{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}} <ins> With this policy in place, no additional policy or policies can cause any outgoing connection from those pods to be denied.  This policy has no effect on isolation for ingress to any pod. </ins> ### Default deny all ingress and all egress traffic You can create a "default" policy for a namespace which prevents all ingress AND egress traffic by creating the following NetworkPolicy in that namespace.
If you don't specify a registry hostname, Kubernetes assumes that you mean the Docker public registry. <del> After the image name part you can add a _tag_ (as also using with commands such as `docker` and `podman`). </del> <ins> After the image name part you can add a _tag_ (in the same way you would when using with commands like `docker` or `podman`). </ins> Tags let you identify different versions of the same series of images. Image tags consist of lowercase and uppercase letters, digits, underscores (`_`),
replace `<image-name>:<tag>` with `<image-name>@<digest>` (for example, `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`). <del> When using image tags, if the image registry were to change the code that the tag on that image represents, you might end up with a mix of Pods running the old and new code. An image digest uniquely identifies a specific version of the image, so Kubernetes runs the same code every time it starts a container with that image name and digest specified. Specifying an image fixes the code that you run so that a change at the registry cannot lead to that mix of versions. </del> <ins> When using image tags, if the image registry were to change the code that the tag on that image represents, you might end up with a mix of Pods running the old and new code. An image digest uniquely identifies a specific version of the image, so Kubernetes runs the same code every time it starts a container with that image name and digest specified. Specifying an image by digest fixes the code that you run so that a change at the registry cannot lead to that mix of versions. </ins> There are third-party [admission controllers](/docs/reference/access-authn-authz/admission-controllers/) that mutate Pods (and pod templates) when they are created, so that the
common use cases and suggested solutions. 1. Cluster running only non-proprietary (e.g. open-source) images.  No need to hide images. <del> - Use public images on the Docker hub. </del> <ins> - Use public images from a public registry </ins> - No configuration required. - Some cloud providers automatically cache or mirror public images, which improves availability and reduces the time to pull images. 1. Cluster running some proprietary images which should be hidden to those outside the company, but visible to all cluster users. <del> - Use a hosted private [Docker registry](https://docs.docker.com/registry/). - It may be hosted on the [Docker Hub](https://hub.docker.com/signup), or elsewhere. - Manually configure .docker/config.json on each node as described above. </del> <ins> - Use a hosted private registry - Manual configuration may be required on the nodes that need to access to private registry </ins> - Or, run an internal private registry behind your firewall with open read access. - No Kubernetes configuration is required. - Use a hosted container image registry service that controls image access
[the design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md). ### Summary API Source <del> The [Kubelet](/docs/reference/command-line-tools-reference/kubelet/) gathers stats at node, volume, pod and container level, and omits them in the [Summary API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go) </del> <ins> The [Kubelet](/docs/reference/command-line-tools-reference/kubelet/) gathers stats at node, volume, pod and container level, and emits their statistics in the [Summary API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go) </ins> for consumers to read. Pre-1.23, these resources have been primarily gathered from [cAdvisor](https://github.com/google/cadvisor). However, in 1.23 with the
A partir de Kubernetes 1.8, el servidor de métricas se despliega por defecto como un objeto de tipo [Deployment](https://github.com/docs/concepts/workloads/controllers/deployment/) en clústeres creados con el script `kube-up.sh`. Si usas otro mecanismo de configuración de Kubernetes, puedes desplegarlo <del> usando los [yamls de despliegue](https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy) </del> <ins> usando los [yamls de despliegue](https://github.com/kubernetes-sigs/metrics-server/releases) </ins> proporcionados. Está soportado a partir de Kubernetes 1.7 (más detalles al final). El servidor reune métricas de la Summary API, que es expuesta por el [Kubelet](/docs/admin/kubelet/) en cada nodo.
1. The kubelet on a node self-registers to the control plane 2. You (or another human user) manually add a Node object <del> After you create a Node object, or the kubelet on a node self-registers, the </del> <ins> After you create a Node {{< glossary_tooltip text="object" term_id="object" >}}, or the kubelet on a node self-registers, the </ins> control plane checks whether the new Node object is valid. For example, if you try to create a Node from the following JSON manifest:
## Targeting a Namespace by its name <del> {{< feature-state state="beta" for_k8s_version="1.21" >}} </del> <ins> {{< feature-state for_k8s_version="1.22" state="stable" >}} </ins> The Kubernetes control plane sets an immutable label `kubernetes.io/metadata.name` on all namespaces, provided that the `NamespaceDefaultLabelName`
EOF ``` <del> 1. Configure your kubelet on the node to use this directory by running it with </del> <ins> 1. Configure the kubelet on that node to set a `staticPodPath` value in the [kubelet configuration file](/docs/reference/config-api/kubelet-config.v1beta1/). See [Set Kubelet Parameters Via A Configuration File](/docs/tasks/administer-cluster/kubelet-config-file/) for more information. An alternative and deprecated method is to configure the kubelet on that node to look for static Pod manifests locally, using a command line argument. To use the deprecated approach, start the kubelet with the </ins> `--pod-manifest-path=/etc/kubernetes/manifests/` argument. <del> On Fedora, edit `/etc/kubernetes/kubelet` to include this line: ``` KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubernetes/manifests/" ``` or add the `staticPodPath: <the directory>` field in the [kubelet configuration file](/docs/reference/config-api/kubelet-config.v1beta1/). </del> 1. Restart the kubelet. On Fedora, you would run: ```shell
## インフラストラクチャ * [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation)は仮想マシンをKubernetes上で実行するためのアドオンです。通常、ベアメタルのクラスタで実行します。 <ins> * [node problem detector](https://github.com/kubernetes/node-problem-detector)はLinuxノード上で動作し、システムの問題を[Event](/docs/reference/kubernetes-api/cluster-resources/event-v1/)または[ノードのCondition](/ja/docs/concepts/architecture/nodes/#condition)として報告します。 </ins> ## レガシーなアドオン
## Create a CustomResourceDefinition When you create a new CustomResourceDefinition (CRD), the Kubernetes API Server <del> creates a new RESTful resource path for each version you specify. The CRD can be either namespaced or cluster-scoped, as specified in the CRD's `scope` field. As with existing built-in objects, deleting a namespace deletes all custom objects in that namespace. CustomResourceDefinitions themselves are non-namespaced and are available to all namespaces. </del> <ins> creates a new RESTful resource path for each version you specify. The custom resource created from a CRD object can be either namespaced or cluster-scoped, as specified in the CRD's `spec.scope` field. As with existing built-in objects, deleting a namespace deletes all custom objects in that namespace. CustomResourceDefinitions themselves are non-namespaced and are available to all namespaces. </ins> For example, if you save the following CustomResourceDefinition to `resourcedefinition.yaml`:
locality, inter-workload interference, and so on. --> 在做调度决定时需要考虑的因素包括：单独和整体的资源请求、硬件/软件/策略限制、 <del> 亲和以及反亲和要求、数据局域性、负载间的干扰等等。 </del> <ins> 亲和以及反亲和要求、数据局部性、负载间的干扰等等。 </ins> <!-- ## Scheduling with kube-scheduler {#kube-scheduler-implementation}
{{% /tab %}} {{< /tabs >}} <ins> The preceding commands don't remove images, containers, volumes, or customized configuration files on your host. To delete them, follow Docker's instructions to [Uninstall Docker Engine](https://docs.docker.com/engine/install/ubuntu/#uninstall-docker-engine). {{< caution >}} Docker's instructions for uninstalling Docker Engine create a risk of deleting containerd. Be careful when executing commands. {{< /caution >}} </ins>
{{< note >}} To learn more about contributing to Kubernetes in general, see the [contributor documentation](https://www.kubernetes.dev/docs/). <ins> You can also read the {{< glossary_tooltip text="CNCF" term_id="cncf" >}} [page](https://contribute.cncf.io/contributors/projects/#kubernetes) about contributing to Kubernetes. </ins> {{< /note >}} <ins> --- </ins> This website is maintained by [Kubernetes SIG Docs](/docs/contribute/#get-involved-with-sig-docs). Kubernetes documentation contributors:
[javascript_required] other = "JavaScript must be [enabled](https://www.enable-javascript.com/) to view this content" <del> [katacoda_removal_warning] other = """This online tutorial on this page uses functionality that will [not be available](https://www.oreilly.com/online-learning/leveraging-katacoda-technology.html) past <time datetime="2022-06-15">June 15th, 2022</time>.""" </del> [latest_release] other = "Latest Release:"
{{ block "deprecated" . }} {{ partial "deprecation-warning.html" . }} {{ end }} <del> {{ if or ( .HasShortcode "kat-button" ) ( .HasShortcode "katacoda-tutorial" ) }} {{ block "katacoda-removal" . }} {{ partial "katacoda-removal.html" . }} {{ end }} {{ end }} </del> {{ block "main" . }}{{ end }} {{- if .HasShortcode "thirdparty-content" -}} {{ block "thirdparty-disclaimer" . }}
The Gateway API introduces a few new resource types: <del> - **[GatewayClasses](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.GatewayClass)** are cluster-scoped resources that act as templates to explicitly define behavior for Gateways derived from them. This is similar in concept to StorageClasses, but for networking data-planes. - **[Gateways](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.Gateway)** are the deployed instances of GatewayClasses. They are the logical representation of the data-plane which performs routing, which may be in-cluster proxies, hardware LBs, or cloud LBs. - **Routes** are not a single resource, but represent many different protocol-specific Route resources. The [HTTPRoute](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.HTTPRoute) has matching, filtering, and routing rules that get applied to Gateways that can process HTTP and HTTPS traffic. Similarly, there are [TCPRoutes](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.TCPRoute), [UDPRoutes](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.UDPRoute), and [TLSRoutes](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.TLSRoute) which also have protocol-specific semantics. This model also allows the Gateway API to incrementally expand its protocol support in the future. </del> <ins> - **[GatewayClasses](https://gateway-api.sigs.k8s.io/concepts/api-overview/#gatewayclass)** are cluster-scoped resources that act as templates to explicitly define behavior for Gateways derived from them. This is similar in concept to StorageClasses, but for networking data-planes. - **[Gateways](https://gateway-api.sigs.k8s.io/concepts/api-overview/#gateway)** are the deployed instances of GatewayClasses. They are the logical representation of the data-plane which performs routing, which may be in-cluster proxies, hardware LBs, or cloud LBs. - **Routes** are not a single resource, but represent many different protocol-specific Route resources. The [HTTPRoute](https://gateway-api.sigs.k8s.io/concepts/api-overview/#httproute) has matching, filtering, and routing rules that get applied to Gateways that can process HTTP and HTTPS traffic. Similarly, there are [TCPRoutes](https://gateway-api.sigs.k8s.io/concepts/api-overview/#tcproute-and-udproute), [UDPRoutes](https://gateway-api.sigs.k8s.io/concepts/api-overview/#tcproute-and-udproute), and [TLSRoutes](https://gateway-api.sigs.k8s.io/concepts/api-overview/#gateway) which also have protocol-specific semantics. This model also allows the Gateway API to incrementally expand its protocol support in the future. </ins> ![The resources of the Gateway API](gateway-api-resources.png)
{{< note >}} Certificates created using the `certificates.k8s.io` API are signed by a <del> [dedicated CA](#a-note-to-cluster-administrators). It is possible to configure your cluster to use the cluster root </del> <ins> [dedicated CA](#configuring-your-cluster-to-provide-signing). It is possible to configure your cluster to use the cluster root </ins> CA for this purpose, but you should never rely on this. Do not assume that these certificates will validate against the cluster root CA. {{< /note >}}
## Trusting TLS in a cluster <del> Trusting the [custom CA](#a-note-to-cluster-administrators) from an application running as a pod usually requires </del> <ins> Trusting the [custom CA](#configuring-your-cluster-to-provide-signing) from an application running as a pod usually requires </ins> some extra application configuration. You will need to add the CA certificate bundle to the list of CA certificates that the TLS client or server trusts. For example, you would do this with a golang TLS config by parsing the certificate
requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: <del> - key: topology.kubernetes.io/zone </del> <ins> - key: kubernetes.io/os </ins> operator: In values: <del> - antarctica-east1 - antarctica-west1 </del> <ins> - linux </ins> preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference:
requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: <del> - key: kubernetes.io/os </del> <ins> - key: topology.kubernetes.io/zone </ins> operator: In values: <del> - linux </del> <ins> - antarctica-east1 - antarctica-west1 </ins> preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference:
* Cloning support is only available for dynamic provisioners. * CSI drivers may or may not have implemented the volume cloning functionality. * You can only clone a PVC when it exists in the same namespace as the destination PVC (source and destination must be in the same namespace). <del> * Cloning is only supported within the same Storage Class. - Destination volume must be the same storage class as the source - Default storage class can be used and storageClassName omitted in the spec </del> <ins> * Cloning is supported with a different Storage Class. - Destination volume can be the same or a different storage class as the source. - Default storage class can be used and storageClassName omitted in the spec. </ins> * Cloning can only be performed between two volumes that use the same VolumeMode setting (if you request a block mode volume, the source MUST also be block mode)
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-$basearch enabled=1 gpgcheck=1 <del> gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg </del> <ins> gpgkey=https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg </ins> exclude=kubelet kubeadm kubectl EOF
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-$basearch enabled=1 gpgcheck=1 <del> gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg </del> <ins> gpgkey=https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg </ins> EOF sudo yum install -y kubectl ```
## kind [`kind`](https://kind.sigs.k8s.io/) lets you run Kubernetes on <del> your local computer. This tool requires that you have [Docker](https://docs.docker.com/get-docker/) installed and configured. </del> <ins> your local computer. This tool requires that you have either [Docker](https://www.docker.com/) or [Podman](https://podman.io/) installed. </ins> The kind [Quick Start](https://kind.sigs.k8s.io/docs/user/quick-start/) page shows you what you need to do to get up and running with kind.
- [CSI provisioner](#vsphere-provisioner-csi): `csi.vsphere.vmware.com` - [vCP provisioner](#vcp-provisioner): `kubernetes.io/vsphere-volume` <del> In-tree provisioners are [deprecated](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#why-are-we-migrating-in-tree-plugins-to-csi). For more information on the CSI provisioner, see [Kubernetes vSphere CSI Driver](https://vsphere-csi-driver.sigs.k8s.io/) and [vSphereVolume CSI migration](/docs/concepts/storage/volumes/#csi-migration-5). </del> <ins> In-tree provisioners are [deprecated](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#why-are-we-migrating-in-tree-plugins-to-csi). For more information on the CSI provisioner, see [Kubernetes vSphere CSI Driver](https://vsphere-csi-driver.sigs.k8s.io/) and [vSphereVolume CSI migration](/docs/concepts/storage/volumes/#vsphere-csi-migration). </ins> #### CSI Provisioner {#vsphere-provisioner-csi}
The value for this annotation must be **true** to take effect. This annotation indicates that pods running as this service account may only reference Secret API objects specified in the service account's `secrets` field. <ins> ### node.kubernetes.io/exclude-from-external-load-balancer Example: `node.kubernetes.io/exclude-from-external-load-balancer` Used on: Node Kubernetes automatically enables the `ServiceNodeExclusion` feature gate on the clusters it creates. With this feature gate enabled on a cluster, you can add labels to particular worker nodes to exclude them from the list of backend servers. The following command can be used to exclude a worker node from the list of backend servers in a backend set- `kubectl label nodes <node-name> node.kubernetes.io/exclude-from-external-load-balancers=true` </ins> ### controller.kubernetes.io/pod-deletion-cost {#pod-deletion-cost} Example: `controller.kubernetes.io/pod-deletion-cost: "10"`
Example: `node.kubernetes.io/out-of-service:NoExecute` <del> A user can manually add the taint to a Node marking it out-of-service. If the `NodeOutOfServiceVolumeDetach` </del> <ins> A user can manually add the taint to a Node marking it out-of-service. If the `NodeOutOfServiceVolumeDetach` </ins> [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled on <del> `kube-controller-manager`, and a Node is marked out-of-service with this taint, the pods on the node will be forcefully deleted if there are no matching tolerations on it and volume detach operations for the pods terminating on the node will happen immediately. This allows the Pods on the out-of-service node to recover quickly on a different node. </del> <ins> `kube-controller-manager`, and a Node is marked out-of-service with this taint, the pods on the node will be forcefully deleted if there are no matching tolerations on it and volume detach operations for the pods terminating on the node will happen immediately. This allows the Pods on the out-of-service node to recover quickly on a different node. </ins> {{< caution >}} Refer to
{{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}} is being created from a VolumeSnapshot. <del> Refer to [Converting the volume mode of a Snapshot](/docs/concepts/storage/volume-snapshots/#convert-volume-mode) </del> <ins> Refer to [Converting the volume mode of a Snapshot](/docs/concepts/storage/volume-snapshots/#convert-volume-mode) </ins> and the [Kubernetes CSI Developer Documentation](https://kubernetes-csi.github.io/docs/) for more information. ## Annotations used for audit
title: 코드 컨트리뷰터(Code Contributor) id: code-contributor date: 2018-04-12 <del> full_link: /ko/docs/community/devel/ </del> <ins> full_link: https://github.com/kubernetes/community/tree/master/contributors/devel </ins> short_description: > 쿠버네티스 오픈소스 코드베이스에 코드를 개발하고 기여하는 사람.