[ko] Update outdated files dev-1.25-ko.1 (M90-M126)

Apply suggestions from code review Co-authored-by: Jihoon Seo <46767780+jihoon-seo@users.noreply.github.com>

Author: Seo-yul

content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md

@@ -9,12 +9,9 @@ weight: 10
 
 <!-- overview -->
 
-쿠버네티스 버전 1.21에서 {{< glossary_tooltip text="크론잡" term_id="cronjob" >}}이 GA (General Availability)로 승격되었다.
-이전 버전의 쿠버네티스를 사용하고 있다면, 해당 쿠버네티스 버전의 문서를 참고하여 정확한 정보를 확인할 수 있다.
-이전 버전의 쿠버네티스는 `batch/v1` 크론잡 API를 지원하지 않는다.
-
-시간 기반의 스케줄에 따라 {{< glossary_tooltip text="크론잡" term_id="cronjob" >}}을 이용해서 {{< glossary_tooltip text="잡(Job)" term_id="job" >}}을 실행할 수 있다.
-이러한 자동화된 잡은 리눅스 또는 유닉스 시스템에서 [크론](https://ko.wikipedia.org/wiki/Cron) 작업처럼 실행된다.
+{{< glossary_tooltip text="크론잡" term_id="cronjob" >}}을 이용하여
+{{< glossary_tooltip text="잡(Job)" term_id="job" >}}을 시간 기반의 스케줄에 따라 실행할 수 있다.
+이러한 자동화된 잡은 리눅스 또는 유닉스 시스템의 [크론](https://ko.wikipedia.org/wiki/Cron) 작업처럼 실행된다.
 
 크론 잡은 백업을 수행하거나 이메일을 보내는 것과 같이 주기적이고 반복적인 작업들을 생성하는 데 유용하다.
 크론 잡은 시스템 사용이 적은 시간에 잡을 스케줄하려는 경우처럼 특정 시간에 개별 작업을 스케줄할 수도 있다.
@@ -25,15 +22,10 @@ weight: 10
 
 제한 사항에 대한 자세한 내용은 [크론잡](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 참고한다.
 
-
-
 ## {{% heading "prerequisites" %}}
 
-
 * {{< include "task-tutorial-prereqs.md" >}}
 
-
-
 <!-- steps -->
 
 ## 크론잡(CronJob) 생성 {#creating-a-cron-job}
@@ -96,8 +88,7 @@ NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
 hello */1 * * * * False 0 50s 75s
 ```
 
-크론 잡 `hello` 가 지정된 시간에 성공적으로 잡을 스케줄했는지 
-`LAST SCHEDULE`에서 확인해야 한다. 
+크론 잡 `hello` 가 `LAST SCHEDULE` 열에 명시된 시간에 잡을 성공적으로 스케줄링한 것을 볼 수 있다.
 현재는 0개의 활성 잡이 있고, 이는 작업이 완료되었거나 실패했음을 의미한다.
 
 이제, 마지막으로 스케줄된 잡이 생성한 파드를 찾고 생성된 파드 중 하나의 표준 출력을 확인한다.
@@ -135,19 +126,25 @@ kubectl delete cronjob hello
 
 ## 크론잡(CronJob) 명세 작성 {#writing-a-cron-job-spec}
 
-다른 모든 쿠버네티스 오브젝트들과 마찬가지로, 크론잡은 `apiVersion`, `kind` 그리고 `metadata` 필드가 반드시 필요하다. Kubernetes 개체 작업과 {{< glossary_tooltip text="매니페스트" term_id="manifest" >}} 대한 자세한 내용은 [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)와
+다른 모든 쿠버네티스 오브젝트들과 마찬가지로,
+크론잡은 `apiVersion`, `kind` 그리고 `metadata` 필드가 반드시 필요하다.
+쿠버네티스 오브젝트 및 그 {{< glossary_tooltip text="매니페스트" term_id="manifest" >}} 다루기에 대한
+자세한 내용은 [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)와
 [kubectl을 사용하여 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다.
 
 크론잡(CronJob)의 각 매니페스트에는 [`.spec`](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#오브젝트-명세-spec-와-상태-status) 섹션도 필요하다.
 
 {{< note >}}
-크론잡(CronJob)을 수정한 경우, 수정 후 새로 실행하는 작업부터 적용된다. 이미 시작된 작업(및 해당 파드)은 변경 없이 계속 실행된다. 즉, 크론잡(CronJob)은 기존 작업이 계속 실행 중이라면, 작업을 변경하지 _않는다._
+크론잡(CronJob)을 수정한 경우, 수정 후 새로 실행하는 작업부터 적용된다.
+이미 시작된 작업(및 해당 파드)은 변경 없이 계속 실행된다.
+즉, 크론잡(CronJob)은 기존 작업이 계속 실행 중이라면, 작업을 변경하지 _않는다._
 {{< /note >}}
 
 ### 스케줄
 
 `.spec.schedule` 은 `.spec` 의 필수 필드이다.
-이는 해당 잡이 생성되고 실행되는 스케줄 시간으로 `0 * * * *` 또는 `@hourly` 와 같이 [크론](https://ko.wikipedia.org/wiki/Cron) 형식의 문자열을 받아들인다.
+이 필드는 `0 * * * *` 또는 `@hourly`와 같은 [크론](https://ko.wikipedia.org/wiki/Cron) 형식의 문자열을 받아, 
+해당 잡이 생성 및 실행될 스케줄 시간으로 설정한다.
 
 이 형식은 확장된 "Vixie cron" 스텝(step) 값도 포함한다. 이 내용은
 [FreeBSD 매뉴얼](https://www.freebsd.org/cgi/man.cgi?crontab%285%29)에 설명되어 있다.
@@ -160,13 +157,15 @@ kubectl delete cronjob hello
 > "2시간마다"라고 지정하고 싶으면, 간단히 `*/2` 를 사용하면 된다.
 
 {{< note >}}
-스케줄에서 물음표(`?`)는 별표 `*` 와 동일한 의미를 가지며, 주어진 필드에 대해 사용할 수 있는 모든 값을 나타낸다.
+스케줄에서 물음표(`?`)는 별표 `*` 와 동일한 의미를 가지며,
+주어진 필드에 대해 사용할 수 있는 모든 값을 나타낸다.
 {{< /note >}}
 
 ### 잡 템플릿
 
 `.spec.jobTemplate` 은 잡에 대한 템플릿이며, 이것은 필수 필드다.
-이것은 중첩되고 `apiVersion` 이나 `kind` 가 없는 것을 제외하고 [잡](/ko/docs/concepts/workloads/controllers/job/)과 정확히 같은 스키마를 가진다.
+이것은 중첩되어(nested) 있고 `apiVersion` 이나 `kind` 가 없다는 것을 제외하면,
+[잡](/ko/docs/concepts/workloads/controllers/job/)과 정확히 같은 스키마를 가진다.
 잡 `.spec` 을 작성하는 것에 대한 내용은 [잡 명세 작성하기](/ko/docs/concepts/workloads/controllers/job/#잡-사양-작성하기)를 참고한다.
 
 ### 시작 기한
@@ -178,10 +177,11 @@ kubectl delete cronjob hello
 이 필드를 지정하지 않으면, 잡에 기한이 없다.
 
 `.spec.startingDeadlineSeconds` 필드가 (null이 아닌 값으로) 설정되어 있다면,
-크론잡 컨트롤러는 잡 생성 완료 예상 시각과 현재 시각의 차이를 측정하고,
+크론잡 컨트롤러는 예상 잡 생성 시각과 현재 시각의 차이를 측정하고,
 시각 차이가 설정한 값보다 커지면 잡 생성 동작을 스킵한다.
 
-예를 들어, `200` 으로 설정되었다면, 잡 생성 완료 예상 시각으로부터 200초까지는 잡이 생성될 수 있다.
+예를 들어, `200` 으로 설정되었다면,
+예상 잡 생성 시각으로부터 200초까지는 잡이 생성될 수 있다.
 
 ### 동시성 정책
 
@@ -190,8 +190,10 @@ kubectl delete cronjob hello
 명세는 다음의 동시성 정책 중 하나만 지정할 수 있다.
 
 * `Allow`(기본값): 크론 잡은 동시에 실행되는 잡을 허용한다.
-* `Forbid`: 크론 잡은 동시 실행을 허용하지 않는다. 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론 잡은 새로운 잡 실행을 건너뛴다.
-* `Replace`: 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론 잡은 현재 실행 중인 잡 실행을 새로운 잡 실행으로 대체한다.
+* `Forbid`: 크론 잡은 동시 실행을 허용하지 않는다.
+ 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론 잡은 새로운 잡 실행을 건너뛴다.
+* `Replace`: 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우,
+ 크론 잡은 현재 실행 중인 잡 실행을 새로운 잡 실행으로 대체한다.
 
 참고로 동시성 정책은 동일한 크론 잡에 의해 생성된 잡에만 적용된다.
 크론 잡이 여러 개인 경우, 각각의 잡은 항상 동시에 실행될 수 있다.
@@ -205,11 +207,13 @@ kubectl delete cronjob hello
 
 {{< caution >}}
 스케줄된 시간 동안 잡이 일시 정지되어 있다면 누락된 잡으로 간주한다.
-[시작 기한](#시작-기한) 없이 기존의 크론 잡에 대해 `.spec.suspend` 가 `true` 에서 `false` 로 변경되면, 누락된 잡들이 즉시 스케줄된다.
+[시작 기한](#시작-기한) 없이 기존의 크론 잡에 대해 `.spec.suspend` 가 `true` 에서 `false` 로 변경되면,
+누락된 잡들이 즉시 스케줄된다.
 {{< /caution >}}
 
 ### 잡 히스토리 한도
 
 `.spec.successfulJobsHistoryLimit` 와 `.spec.failedJobsHistoryLimit` 필드는 선택 사항이다.
 이들 필드는 기록을 보관해야 하는 완료 및 실패한 잡의 개수를 지정한다.
-기본적으로, 각각 3과 1로 설정된다. 한도를 `0` 으로 설정하는 것은 잡 완료 후에 해당 잡 유형의 기록을 보관하지 않는다는 것이다.
+기본적으로, 각각 3과 1로 설정된다.
+한도를 `0` 으로 설정하는 것은 잡 완료 후에 해당 잡 유형의 기록을 보관하지 않는다는 것이다.

content/ko/docs/tasks/job/indexed-parallel-processing-static.md

@@ -19,7 +19,7 @@ weight: 30
 파드 인덱스는 10진수 값을 문자열로 표현한 {{< glossary_tooltip text="어노테이션" term_id="annotation" >}}
 `batch.kubernetes.io/job-completion-index` 를 통해
 사용할 수 있다. 컨테이너화된 태스크 프로세스가 이 인덱스 정보를 가져갈 수 있도록,
-[downward API](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api)
+[다운워드(downward) API](/ko/docs/concepts/workloads/pods/downward-api/)
 메커니즘을 사용하여 어노테이션의 값을 발행할 수 있다.
 편의상, 컨트롤 플레인은 downward API를 자동 설정하여
 `JOB_COMPLETION_INDEX` 환경변수에 인덱스를 노출할 수 있도록 한다.

content/ko/docs/tasks/manage-daemon/update-daemon-set.md

@@ -39,7 +39,7 @@ weight: 10
 [`.spec.minReadySeconds`](/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec)
 (기본값은 0),
 [`.spec.updateStrategy.rollingUpdate.maxSurge`](/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec)
-(베타 기능, 기본값은 0)를 
+(기본값은 0)를
 설정할 수도 있다.
 
 ### `RollingUpdate` 업데이트 전략으로 데몬셋 생성

content/ko/docs/tasks/manage-gpus/scheduling-gpus.md

@@ -6,8 +6,6 @@ title: GPU 스케줄링
 description: 클러스터의 노드별로 리소스로 사용할 GPU를 구성하고 스케줄링한다.
 ---
 
-
-
 <!-- overview -->
 
 {{< feature-state state="beta" for_k8s_version="v1.10" >}}
@@ -65,7 +63,7 @@ spec:
  containers:
  - name: cuda-vector-add
  # https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile
- image: "k8s.gcr.io/cuda-vector-add:v0.1"
+ image: "registry.k8s.io/cuda-vector-add:v0.1"
  resources:
  limits:
  nvidia.com/gpu: 1 # GPU 1개 요청하기
@@ -208,7 +206,7 @@ spec:
  containers:
  - name: cuda-vector-add
  # https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile
- image: "k8s.gcr.io/cuda-vector-add:v0.1"
+ image: "registry.k8s.io/cuda-vector-add:v0.1"
  resources:
  limits:
  nvidia.com/gpu: 1

content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md

@@ -86,20 +86,12 @@ metadata:
  name: example-configmap-1-8mbdf7882g
 ```
 
-env 파일에서 컨피그맵을 생성하려면, `configMapGenerator`의 `envs` 리스트에 항목을 추가한다. `=` 및 값을 생략하여 로컬 환경 변수로부터 값을 설정할 수도 있다.
-
-{{< note >}}
-로컬 환경 변수 채우기 기능은 꼭 필요한 경우에만 사용하는 것이 좋은데, 이는 패치를 할 수 있는 오버레이가 있는 편이 유지 관리에 더 유리하기 때문이다. 로컬 환경 변수 채우기 기능은 git SHA와 같이 그 값을 쉽게 예측할 수 없는 경우에 유용할 수 있다.
-{{< /note >}}
-
-다음은 `.env` 파일의 데이터 항목으로 컨피그맵을 생성하는 예시를 보여준다.
+env 파일에서 컨피그맵을 생성하려면, `configMapGenerator`의 `envs` 리스트에 항목을 추가한다. 다음은 `.env` 파일의 데이터 항목으로 컨피그맵을 생성하는 예시를 보여준다.
 
 ```shell
 # .env 파일 생성
-# BAZ 에는 로컬 환경 변수 $BAZ 의 값이 입력될 것이다
 cat <<EOF >.env
 FOO=Bar
-BAZ
 EOF
 
 cat <<EOF >./kustomization.yaml
@@ -113,19 +105,18 @@ EOF
 생성된 컨피그맵은 다음 명령어로 검사할 수 있다.
 
 ```shell
-BAZ=Qux kubectl kustomize ./
+kubectl kustomize ./
 ```
 
 생성된 컨피그맵은 다음과 같다.
 
 ```yaml
 apiVersion: v1
 data:
- BAZ: Qux
  FOO: Bar
 kind: ConfigMap
 metadata:
- name: example-configmap-1-892ghb99c8
+ name: example-configmap-1-42cfbf598f
 ```
 
 {{< note >}}
@@ -1020,3 +1011,4 @@ deployment.apps "dev-my-nginx" deleted
 * [Kubectl 문서](https://kubectl.docs.kubernetes.io)
 * [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/)
 * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
+

content/ko/docs/tasks/network/validate-dual-stack.md

@@ -39,7 +39,7 @@ kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .
 ```
 ```
 10.244.1.0/24
-a00:100::/24
+2001:db8::/64
 ```
 단일 IPv4 블록과 단일 IPv6 블록이 할당되어야 한다.
 
@@ -50,8 +50,8 @@ kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .
 ```
 ```
 Hostname: k8s-linuxpool1-34450317-0
-InternalIP: 10.240.0.5
-InternalIP: 2001:1234:5678:9abc::5
+InternalIP: 10.0.0.5
+InternalIP: 2001:db8:10::5
 ```
 
 ### 파드 어드레싱 검증
@@ -63,7 +63,7 @@ kubectl get pods pod01 -o go-template --template='{{range .status.podIPs}}{{prin
 ```
 ```
 10.244.1.4
-a00:100::4
+2001:db8::4
 ```
 
 `status.podIPs` fieldPath를 통한 다운워드(downward) API로 파드 IP들을 검증할 수도 있다. 다음 스니펫은 컨테이너 내 `MY_POD_IPS` 라는 환경 변수를 통해 파드 IP들을 어떻게 노출시킬 수 있는지 보여준다.
@@ -82,7 +82,7 @@ a00:100::4
 kubectl exec -it pod01 -- set | grep MY_POD_IPS
 ```
 ```
-MY_POD_IPS=10.244.1.4,a00:100::4
+MY_POD_IPS=10.244.1.4,2001:db8::4
 ```
 
 파드의 IP 주소는 또한 컨테이너 내 `/etc/hosts` 에 적힐 것이다. 다음 커맨드는 이중 스택 파드의 `/etc/hosts` 에 cat을 실행시킨다. 출력 값을 통해 파드의 IPv4 및 IPv6 주소 모두 검증할 수 있다.
@@ -99,7 +99,7 @@ fe00::0 ip6-mcastprefix
 fe00::1 ip6-allnodes
 fe00::2 ip6-allrouters
 10.244.1.4 pod01
-a00:100::4 pod01
+2001:db8::4 pod01
 ```
 
 ## 서비스 검증
@@ -161,9 +161,9 @@ metadata:
  app.kubernetes.io/name: MyApp
  name: my-service
 spec:
- clusterIP: fd00::5118
+ clusterIP: 2001:db8:fd00::5118
  clusterIPs:
- - fd00::5118
+ - 2001:db8:fd00::5118
  ipFamilies:
  - IPv6
  ipFamilyPolicy: SingleStack
@@ -210,7 +210,7 @@ Type: ClusterIP
 IP Family Policy: PreferDualStack
 IP Families: IPv4,IPv6
 IP: 10.0.216.242
-IPs: 10.0.216.242,fd00::af55
+IPs: 10.0.216.242,2001:db8:fd00::af55
 Port: <unset> 80/TCP
 TargetPort: 9376/TCP
 Endpoints: <none>
@@ -233,6 +233,8 @@ kubectl get svc -l app.kubernetes.io/name: MyApp
 서비스가 IPv6 주소 블록에서 `CLUSTER-IP` 주소 및 `EXTERNAL-IP` 주소를 할당받는지 검증한다. 그리고 나서 IP 및 포트로 서비스 접근이 가능한지 검증할 수 있다.
 
 ```shell
-NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
-my-service LoadBalancer fd00::7ebc 2603:1030:805::5 80:30790/TCP 35s
+NAME TYPE CLUSTER-IP  EXTERNAL-IP PORT(S) AGE
+my-service LoadBalancer 2001:db8:fd00::7ebc 2603:1030:805::5 80:30790/TCP 35s
 ```
+
+

content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md

@@ -54,31 +54,8 @@ Metrics Server를 실행하는 방법을 보려면
 
 ## php-apache 서버 구동 및 노출
 
-HorizontalPodAutoscaler 예시에서, 
-먼저 도커 허브의 `php-apache` 이미지를 베이스로 하는 커스텀 컨테이너 이미지를 만들어 시작점으로 삼을 것이다. 
-`Dockerfile`은 미리 준비되어 있으며, 내용은 다음과 같다.
-
-```dockerfile
-FROM php:5-apache
-COPY index.php /var/www/html/index.php
-RUN chmod a+rx index.php
-```
-
-아래의 코드는 CPU 과부하 연산을 수행하는 간단한 `index.php` 페이지를 정의하며,
-이를 이용해 클러스터에 부하를 시뮬레이트한다.
-
-```php
-<?php
- $x = 0.0001;
- for ($i = 0; $i <= 1000000; $i++) {
- $x += sqrt($x);
- }
- echo "OK!";
-?>
-```
-
-컨테이너 이미지를 만들었다면, 
-방금 만든 이미지로부터 컨테이너를 실행하는 디플로이먼트를 시작하고, 다음의 매니페스트를 사용하여 디플로이먼트를 
+HorizontalPodAutoscaler 시연을 위해, `hpa-example` 이미지를 사용하여 컨테이너를 실행하는 디플로이먼트를 시작하고,
+다음의 매니페스트를 사용하여 디플로이먼트를
 {{< glossary_tooltip term_id="service" text="서비스">}}로 노출한다.
 
 {{< codenew file="application/php-apache.yaml" >}}

content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md

@@ -362,3 +362,4 @@ CSR이 다음 두 가지 요구 사항을 충족하는지 확인하는 것이다
 활성화하려면 인증 기관(CA)의 키 쌍에 대한 경로와 함께 `--cluster-signing-cert-file` 와 
 `--cluster-signing-key-file` 매개 변수를 
 컨트롤러 관리자에 전달한다.
+

content/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md

@@ -31,12 +31,12 @@ source /usr/share/bash-completion/bash_completion
 이제 kubectl 자동 완성 스크립트가 모든 셸 세션에서 제공되도록 해야 한다. 이를 수행할 수 있는 두 가지 방법이 있다.
 
 {{< tabs name="kubectl_bash_autocompletion" >}}
-{{{< tab name="현재 사용자에만 적용" codelang="bash" >}}
+{{< tab name="현재 사용자에만 적용" codelang="bash" >}}
 echo 'source <(kubectl completion bash)' >>~/.bashrc
 {{< /tab >}}
 {{< tab name="시스템 전체에 적용" codelang="bash" >}}
 kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl > /dev/null
-{{< /tab >}}}
+{{< /tab >}}
 {{< /tabs >}}
 
 kubectl에 대한 앨리어스(alias)가 있는 경우, 해당 앨리어스로 작업하도록 셸 자동 완성을 확장할 수 있다.
@@ -51,3 +51,7 @@ bash-completion은 `/etc/bash_completion.d` 에 있는 모든 자동 완성 스
 {{< /note >}}
 
 두 방법 모두 동일하다. 셸을 다시 로드하면, kubectl 자동 완성 기능이 작동할 것이다.
+셸의 현재 세션에서 bash 자동 완성을 활성화하려면 `exec bash`를 실행한다.
+```bash
+exec bash
+```

content/ko/docs/tutorials/hello-minikube.md

@@ -94,7 +94,7 @@ minikube dashboard --url
 파드는 제공된 Docker 이미지를 기반으로 한 컨테이너를 실행한다.
 
  ```shell
- kubectl create deployment hello-node --image=k8s.gcr.io/echoserver:1.4
+ kubectl create deployment hello-node --image=registry.k8s.io/echoserver:1.4
  ```
 
 2. 디플로이먼트 보기
@@ -155,7 +155,7 @@ minikube dashboard --url
  `--type=LoadBalancer`플래그는 클러스터 밖의 서비스로 노출하기
  원한다는 뜻이다.
 
- `k8s.gcr.io/echoserver` 이미지 내의 애플리케이션 코드는 TCP 포트 8080에서만 수신한다. `kubectl expose`를
+ `registry.k8s.io/echoserver` 이미지 내의 애플리케이션 코드는 TCP 포트 8080에서만 수신한다. `kubectl expose`를
  사용하여 다른 포트를 노출한 경우, 클라이언트는 다른 포트에 연결할 수 없다.
 
 2. 생성한 서비스 살펴보기
@@ -303,3 +303,4 @@ minikube delete
 * [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해서 더 배워 본다.
 * [애플리케이션 배포](/ko/docs/tasks/run-application/run-stateless-application-deployment/)에 대해서 더 배워 본다.
 * [서비스 오브젝트](/ko/docs/concepts/services-networking/service/)에 대해서 더 배워 본다.
+