Merge pull request #28174 from seokho-son/dev-1.21-ko.3-out.28
[ko] Update outdated files in dev-1.21-ko.3(M28-M36)
This commit is contained in:
commit
cf2d39aae9
|
@ -111,7 +111,6 @@ min-kubernetes-server-version: v1.10
|
|||
```shell
|
||||
# mongo-75f59d57f4-4nd6q 를 당신의 파드 이름으로 대체한다.
|
||||
kubectl get pod mongo-75f59d57f4-4nd6q --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
|
||||
|
||||
```
|
||||
|
||||
출력은 파드 내 MongoDB 포트 번호를 보여준다.
|
||||
|
@ -124,7 +123,7 @@ min-kubernetes-server-version: v1.10
|
|||
|
||||
## 파드의 포트를 로컬 포트로 포워딩하기
|
||||
|
||||
1. `kubectl port-forward` 명령어는 파드 이름과 같이 리소스 이름을 사용하여 일치하는 파드를 선택해 포트 포워딩하는 것을 허용한다.
|
||||
1. `kubectl port-forward` 명령어는 파드 이름과 같이 리소스 이름을 사용하여 일치하는 파드를 선택해 포트 포워딩하는 것을 허용한다.
|
||||
|
||||
|
||||
```shell
|
||||
|
@ -177,7 +176,7 @@ min-kubernetes-server-version: v1.10
|
|||
|
||||
3. MongoDB 커맨드라인 프롬프트에 `ping` 명령을 입력한다.
|
||||
|
||||
```shell
|
||||
```
|
||||
db.runCommand( { ping: 1 } )
|
||||
```
|
||||
|
||||
|
|
|
@ -1,4 +1,8 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
|
||||
title: 웹 UI (대시보드)
|
||||
content_type: concept
|
||||
weight: 10
|
||||
|
@ -30,12 +34,11 @@ card:
|
|||
대시보드 UI는 기본으로 배포되지 않는다. 배포하려면 다음 커맨드를 동작한다.
|
||||
|
||||
```
|
||||
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/aio/deploy/recommended.yaml
|
||||
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.2.0/aio/deploy/recommended.yaml
|
||||
```
|
||||
|
||||
## 대시보드 UI 접근
|
||||
|
||||
|
||||
클러스터 데이터를 보호하기 위해, 대시보드는 기본적으로 최소한의 RBAC 설정을 제공한다.
|
||||
현재, 대시보드는 Bearer 토큰으로 로그인 하는 방법을 제공한다.
|
||||
본 시연을 위한 토큰을 생성하기 위해서는,
|
||||
|
|
|
@ -229,7 +229,7 @@ serverTLSBootstrap: true
|
|||
|
||||
만약 이미 클러스터를 생성했다면 다음을 따라 이를 조정해야 한다.
|
||||
- `kube-system` 네임스페이스에서 `kubelet-config-{{< skew latestVersion >}}` 컨피그맵을 찾아서 수정한다.
|
||||
해당 컨피그맵에는 `config` 키가
|
||||
해당 컨피그맵에는 `kubelet` 키가
|
||||
[KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
|
||||
문서를 값으로 가진다. `serverTLSBootstrap: true` 가 되도록 KubeletConfiguration 문서를 수정한다.
|
||||
- 각 노드에서, `serverTLSBootstrap: true` 필드를 `/var/lib/kubelet/config.yaml` 에 추가한다.
|
||||
|
|
|
@ -1,6 +1,8 @@
|
|||
---
|
||||
title: 크론잡(CronJob)으로 자동화된 작업 실행
|
||||
min-kubernetes-server-version: v1.21
|
||||
|
||||
|
||||
content_type: task
|
||||
weight: 10
|
||||
---
|
||||
|
@ -144,7 +146,7 @@ kubectl delete cronjob hello
|
|||
`.spec.schedule` 은 `.spec` 의 필수 필드이다.
|
||||
이는 해당 잡이 생성되고 실행되는 스케줄 시간으로 `0 * * * *` 또는 `@hourly` 와 같이 [크론](https://ko.wikipedia.org/wiki/Cron) 형식의 문자열을 받아들인다.
|
||||
|
||||
이 형식은 확장된 `vixie cron` 스텝(step) 값도 포함한다. 이 내용은
|
||||
이 형식은 확장된 "Vixie cron" 스텝(step) 값도 포함한다. 이 내용은
|
||||
[FreeBSD 매뉴얼](https://www.freebsd.org/cgi/man.cgi?crontab%285%29)에 설명되어 있다.
|
||||
|
||||
> 스텝 값은 범위(range)와 함께 사용할 수 있다. 범위 뒤에 `/<number>` 를
|
||||
|
@ -172,8 +174,8 @@ kubectl delete cronjob hello
|
|||
이러한 방식으로 기한을 맞추지 못한 잡은 실패한 작업으로 간주된다.
|
||||
이 필드를 지정하지 않으면, 잡에 기한이 없다.
|
||||
|
||||
`.spec.startingDeadlineSeconds` 필드가 (null이 아닌 값으로) 설정되어 있다면,
|
||||
크론잡 컨트롤러는 잡 생성 완료 예상 시각과 현재 시각의 차이를 측정하고,
|
||||
`.spec.startingDeadlineSeconds` 필드가 (null이 아닌 값으로) 설정되어 있다면,
|
||||
크론잡 컨트롤러는 잡 생성 완료 예상 시각과 현재 시각의 차이를 측정하고,
|
||||
시각 차이가 설정한 값보다 커지면 잡 생성 동작을 스킵한다.
|
||||
|
||||
예를 들어, `200` 으로 설정되었다면, 잡 생성 완료 예상 시각으로부터 200초까지는 잡이 생성될 수 있다.
|
||||
|
|
|
@ -86,6 +86,43 @@ metadata:
|
|||
name: example-configmap-1-8mbdf7882g
|
||||
```
|
||||
|
||||
env 파일에서 컨피그맵을 생성하려면, `configMapGenerator`의 `envs` 리스트에 항목을 추가한다. 다음은 `.env` 파일의 데이터 항목으로 컨피그맵을 생성하는 예시를 보여준다.
|
||||
|
||||
```shell
|
||||
# .env 파일 생성
|
||||
cat <<EOF >.env
|
||||
FOO=Bar
|
||||
EOF
|
||||
|
||||
cat <<EOF >./kustomization.yaml
|
||||
configMapGenerator:
|
||||
- name: example-configmap-1
|
||||
envs:
|
||||
- .env
|
||||
EOF
|
||||
```
|
||||
|
||||
생성된 컨피그맵은 다음 명령어로 검사할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl kustomize ./
|
||||
```
|
||||
|
||||
생성된 컨피그맵은 다음과 같다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
data:
|
||||
FOO=Bar
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: example-configmap-1-8mbdf7882g
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
`.env` 파일의 각 변수는 생성한 컨피그맵에서 분리된 키가 된다. `.properties` 라는 이름의 파일을 내장하는 이전 예시(그리고 모든 항목들)는 단일 키를 위한 값이므로 이 예시와는 다르다.
|
||||
{{< /note >}}
|
||||
|
||||
컨피그맵은 문자로된 키-값 쌍들로도 생성할 수 있다. 문자로된 키-값 쌍에서 컨피그맵을 생성하려면, configMapGenerator 내의 `literals` 리스트에 항목을 추가한다. 다음은 키-값 쌍을 데이터 항목으로 받는 컨피그맵을 생성하는 예제이다.
|
||||
|
||||
```shell
|
||||
|
|
|
@ -1,4 +1,10 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
title: 스테이트풀셋(StatefulSet) 삭제하기
|
||||
content_type: task
|
||||
weight: 60
|
||||
|
@ -37,14 +43,14 @@ kubectl delete statefulsets <statefulset-name>
|
|||
kubectl delete service <service-name>
|
||||
```
|
||||
|
||||
kubectl을 통해 스테이트풀셋을 삭제하면, 스테이트풀셋의 크기가 0으로 설정되고 이로 인해 스테이트풀셋에 포함된 모든 파드가 삭제된다. 파드가 아닌 스테이트풀셋만 삭제하려면, `--cascade=false` 옵션을 사용한다.
|
||||
kubectl을 통해 스테이트풀셋을 삭제하면, 스테이트풀셋의 크기가 0으로 설정되고 이로 인해 스테이트풀셋에 포함된 모든 파드가 삭제된다. 파드가 아닌 스테이트풀셋만 삭제하려면, `--cascade=orphan` 옵션을 사용한다.
|
||||
예시는 다음과 같다.
|
||||
|
||||
```shell
|
||||
kubectl delete -f <file.yaml> --cascade=false
|
||||
kubectl delete -f <file.yaml> --cascade=orphan
|
||||
```
|
||||
|
||||
`kubectl delete` 에 `--cascade=false` 를 사용하면 스테이트풀셋 오브젝트가 삭제된 후에도 스테이트풀셋에 의해 관리된 파드는 남게 된다. 만약 파드가 `app=myapp` 레이블을 갖고 있다면, 다음과 같이 파드를 삭제할 수 있다.
|
||||
`kubectl delete` 에 `--cascade=orphan` 를 사용하면 스테이트풀셋 오브젝트가 삭제된 후에도 스테이트풀셋에 의해 관리된 파드는 남게 된다. 만약 파드가 `app=myapp` 레이블을 갖고 있다면, 다음과 같이 파드를 삭제할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl delete pods -l app=myapp
|
||||
|
|
|
@ -8,11 +8,11 @@ host="redis"
|
|||
# import os
|
||||
# host = os.getenv("REDIS_SERVICE_HOST")
|
||||
|
||||
q = rediswq.RedisWQ(name="job2", host="redis")
|
||||
q = rediswq.RedisWQ(name="job2", host=host)
|
||||
print("Worker with sessionID: " + q.sessionID())
|
||||
print("Initial queue state: empty=" + str(q.empty()))
|
||||
while not q.empty():
|
||||
item = q.lease(lease_secs=10, block=True, timeout=2)
|
||||
item = q.lease(lease_secs=10, block=True, timeout=2)
|
||||
if item is not None:
|
||||
itemstr = item.decode("utf-8")
|
||||
print("Working on " + itemstr)
|
||||
|
|
|
@ -18,6 +18,7 @@ spec:
|
|||
# this toleration is to have the daemonset runnable on master nodes
|
||||
# remove it if your masters can't run pods
|
||||
- key: node-role.kubernetes.io/master
|
||||
operator: Exists
|
||||
effect: NoSchedule
|
||||
containers:
|
||||
- name: fluentd-elasticsearch
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와
|
||||
통신할 수 있도록 설정되어 있어야 한다.
|
||||
만약, 아직 클러스터를 가지고 있지 않다면,
|
||||
통신할 수 있도록 설정되어 있어야 한다. 이 튜토리얼은 컨트롤 플레인 호스트가 아닌 노드가 적어도 2개 포함된 클러스터에서 실행하는 것을 추천한다. 만약, 아직 클러스터를 가지고
|
||||
있지 않다면,
|
||||
[minikube](/ko/docs/tasks/tools/#minikube)를 사용해서 생성하거나
|
||||
다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.
|
||||
|
||||
|
|
Loading…
Reference in New Issue