Use code_sample shortcode instead of code shortcode

Author: Mengjiao Liu

content/en/docs/concepts/cluster-administration/flow-control.md

@@ -470,7 +470,7 @@ traffic, you can configure rules to block any health check requests
 that originate from outside your cluster.
 {{< /caution >}}
 
-{{% code file="priority-and-fairness/health-for-strangers.yaml" %}}
+{{% code_sample file="priority-and-fairness/health-for-strangers.yaml" %}}
 
 ## Diagnostics
 
@@ -885,7 +885,7 @@ from other requests.
 
 Example FlowSchema object to isolate list event requests:
 
-{{% code file="priority-and-fairness/list-events-default-service-account.yaml" %}}
+{{% code_sample file="priority-and-fairness/list-events-default-service-account.yaml" %}}
 
 - This FlowSchema captures all list event calls made by the default service
   account in the default namespace. The matching precedence 8000 is lower than the

content/en/docs/concepts/cluster-administration/logging.md

@@ -39,7 +39,7 @@ Kubernetes captures logs from each container in a running Pod.
 This example uses a manifest for a `Pod` with a container
 that writes text to the standard output stream, once per second.
 
-{{% code file="debug/counter-pod.yaml" %}}
+{{% code_sample file="debug/counter-pod.yaml" %}}
 
 To run this pod, use the following command:
 
@@ -255,7 +255,7 @@ For example, a pod runs a single container, and the container
 writes to two different log files using two different formats. Here's a
 manifest for the Pod:
 
-{{% code file="admin/logging/two-files-counter-pod.yaml" %}}
+{{% code_sample file="admin/logging/two-files-counter-pod.yaml" %}}
 
 It is not recommended to write log entries with different formats to the same log
 stream, even if you managed to redirect both components to the `stdout` stream of
@@ -265,7 +265,7 @@ the logs to its own `stdout` stream.
 
 Here's a manifest for a pod that has two sidecar containers:
 
-{{% code file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" %}}
+{{% code_sample file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" %}}
 
 Now when you run this pod, you can access each log stream separately by
 running the following commands:
@@ -332,7 +332,7 @@ Here are two example manifests that you can use to implement a sidecar container
 The first manifest contains a [`ConfigMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/)
 to configure fluentd.
 
-{{% code file="admin/logging/fluentd-sidecar-config.yaml" %}}
+{{% code_sample file="admin/logging/fluentd-sidecar-config.yaml" %}}
 
 {{< note >}}
 In the sample configurations, you can replace fluentd with any logging agent, reading
@@ -342,7 +342,7 @@ from any source inside an application container.
 The second manifest describes a pod that has a sidecar container running fluentd.
 The pod mounts a volume where fluentd can pick up its configuration data.
 
-{{% code file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" %}}
+{{% code_sample file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" %}}
 
 ### Exposing logs directly from the application
 

content/en/docs/concepts/cluster-administration/manage-deployment.md

@@ -22,7 +22,7 @@ Many applications require multiple resources to be created, such as a Deployment
 Management of multiple resources can be simplified by grouping them together in the same file
 (separated by `---` in YAML). For example:
 
-{{% code file="application/nginx-app.yaml" %}}
+{{% code_sample file="application/nginx-app.yaml" %}}
 
 Multiple resources can be created the same way as a single resource:
 

content/en/docs/concepts/configuration/configmap.md

@@ -113,7 +113,7 @@ technique also lets you access a ConfigMap in a different namespace.
 
 Here's an example Pod that uses values from `game-demo` to configure a Pod:
 
-{{% code file="configmap/configure-pod.yaml" %}}
+{{% code_sample file="configmap/configure-pod.yaml" %}}
 
 A ConfigMap doesn't differentiate between single line property values and
 multi-line file-like values.

content/en/docs/concepts/overview/working-with-objects/_index.md

@@ -77,7 +77,7 @@ request.
 
 Here's an example `.yaml` file that shows the required fields and object spec for a Kubernetes Deployment:
 
-{{% code file="application/deployment.yaml" %}}
+{{% code_sample file="application/deployment.yaml" %}}
 
 One way to create a Deployment using a `.yaml` file like the one above is to use the
 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) command

content/en/docs/concepts/policy/limit-range.md

@@ -54,12 +54,12 @@ A `LimitRange` does **not** check the consistency of the default values it appli
 
 For example, you define a `LimitRange` with this manifest:
 
-{{% code file="concepts/policy/limit-range/problematic-limit-range.yaml" %}}
+{{% code_sample file="concepts/policy/limit-range/problematic-limit-range.yaml" %}}
 
 
 along with a Pod that declares a CPU resource request of `700m`, but not a limit:
 
-{{% code file="concepts/policy/limit-range/example-conflict-with-limitrange-cpu.yaml" %}}
+{{% code_sample file="concepts/policy/limit-range/example-conflict-with-limitrange-cpu.yaml" %}}
 
 
 then that Pod will not be scheduled, failing with an error similar to:
@@ -69,7 +69,7 @@ Pod "example-conflict-with-limitrange-cpu" is invalid: spec.containers[0].resour
 
 If you set both `request` and `limit`, then that new Pod will be scheduled successfully even with the same `LimitRange` in place:
 
-{{% code file="concepts/policy/limit-range/example-no-conflict-with-limitrange-cpu.yaml" %}}
+{{% code_sample file="concepts/policy/limit-range/example-no-conflict-with-limitrange-cpu.yaml" %}}
 
 ## Example resource constraints
 

content/en/docs/concepts/policy/resource-quotas.md

@@ -687,7 +687,7 @@ plugins:
 
 Then, create a resource quota object in the `kube-system` namespace:
 
-{{% code file="policy/priority-class-resourcequota.yaml" %}}
+{{% code_sample file="policy/priority-class-resourcequota.yaml" %}}
 
 ```shell
 kubectl apply -f https://k8s.io/examples/policy/priority-class-resourcequota.yaml -n kube-system

content/en/docs/concepts/scheduling-eviction/assign-pod-node.md

@@ -121,7 +121,7 @@ your Pod spec.
 
 For example, consider the following Pod spec:
 
-{{% code file="pods/pod-with-node-affinity.yaml" %}}
+{{% code_sample file="pods/pod-with-node-affinity.yaml" %}}
 
 In this example, the following rules apply:
 
@@ -171,7 +171,7 @@ scheduling decision for the Pod.
 
 For example, consider the following Pod spec:
 
-{{% code file="pods/pod-with-affinity-anti-affinity.yaml" %}}
+{{% code_sample file="pods/pod-with-affinity-anti-affinity.yaml" %}}
 
 If there are two possible nodes that match the
 `preferredDuringSchedulingIgnoredDuringExecution` rule, one with the
@@ -287,7 +287,7 @@ spec.
 
 Consider the following Pod spec:
 
-{{% code file="pods/pod-with-pod-affinity.yaml" %}}
+{{% code_sample file="pods/pod-with-pod-affinity.yaml" %}}
 
 This example defines one Pod affinity rule and one Pod anti-affinity rule. The
 Pod affinity rule uses the "hard"

content/en/docs/concepts/scheduling-eviction/pod-scheduling-readiness.md

@@ -31,7 +31,7 @@ each schedulingGate can be removed in arbitrary order, but addition of a new sch
 
 To mark a Pod not-ready for scheduling, you can create it with one or more scheduling gates like this:
 
-{{% code file="pods/pod-with-scheduling-gates.yaml" %}}
+{{% code_sample file="pods/pod-with-scheduling-gates.yaml" %}}
 
 After the Pod's creation, you can check its state using:
 
@@ -61,7 +61,7 @@ The output is:
 To inform scheduler this Pod is ready for scheduling, you can remove its `schedulingGates` entirely
 by re-applying a modified manifest:
 
-{{% code file="pods/pod-without-scheduling-gates.yaml" %}}
+{{% code_sample file="pods/pod-without-scheduling-gates.yaml" %}}
 
 You can check if the `schedulingGates` is cleared by running:
 

content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md

@@ -64,7 +64,7 @@ tolerations:
 
 Here's an example of a pod that uses tolerations:
 
-{{% code file="pods/pod-with-toleration.yaml" %}}
+{{% code_sample file="pods/pod-with-toleration.yaml" %}}
 
 The default value for `operator` is `Equal`.