[ko] Update outdated files dev-1.25-ko.1 (M11-M16)
parent
77b688c8f6
commit
a6bf3f006d
|
@ -566,7 +566,7 @@ metadata:
|
|||
spec:
|
||||
containers:
|
||||
- name: test-container
|
||||
image: k8s.gcr.io/busybox
|
||||
image: registry.k8s.io/busybox
|
||||
command: [ "/bin/sh", "-c", "env" ]
|
||||
envFrom:
|
||||
- secretRef:
|
||||
|
@ -794,7 +794,7 @@ spec:
|
|||
secretName: dotfile-secret
|
||||
containers:
|
||||
- name: dotfile-test-container
|
||||
image: k8s.gcr.io/busybox
|
||||
image: registry.k8s.io/busybox
|
||||
command:
|
||||
- ls
|
||||
- "-l"
|
||||
|
|
|
@ -103,9 +103,9 @@ Kubelet이 구동된 후에 해당 훅은 재전송될 것이다.
|
|||
|
||||
훅 핸들러의 로그는 파드 이벤트로 노출되지 않는다.
|
||||
만약 핸들러가 어떠한 이유로 실패하면, 핸들러는 이벤트를 방송한다.
|
||||
`PostStart`의 경우, 이것은 `FailedPostStartHook` 이벤트이며,
|
||||
`PreStop`의 경우, 이것은 `FailedPreStopHook` 이벤트이다.
|
||||
실패한 `FailedPreStopHook` 이벤트를 직접 생성하려면, [lifecycle-events.yaml](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/lifecycle-events.yaml) 파일을 수정하여 postStart 명령을 "badcommand"로 변경하고 이를 적용한다.
|
||||
`PostStart`의 경우 `FailedPostStartHook` 이벤트이며,
|
||||
`PreStop`의 경우 `FailedPreStopHook` 이벤트이다.
|
||||
실패한 `FailedPostStartHook` 이벤트를 직접 생성하려면, [lifecycle-events.yaml](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/lifecycle-events.yaml) 파일을 수정하여 postStart 명령을 "badcommand"로 변경하고 이를 적용한다.
|
||||
다음은 `kubectl describe pod lifecycle-demo` 를 실행하여 볼 수 있는 이벤트 출력 예시이다.
|
||||
|
||||
```
|
||||
|
|
|
@ -24,8 +24,8 @@ weight: 10
|
|||
## 이미지 이름
|
||||
|
||||
컨테이너 이미지는 일반적으로 `pause`, `example/mycontainer` 또는 `kube-apiserver` 와 같은 이름을 부여한다.
|
||||
이미지는 또한 레지스트리 호스트 이름을 포함할 수 있다. 예를 들면, `fictional.registry.example/imagename`
|
||||
과 같다. 그리고 포트 번호도 포함할 수 있다. 예를 들면, `fictional.registry.example:10443/imagename` 과 같다.
|
||||
이미지는 또한 레지스트리 호스트 이름을 포함할 수 있다. 예를 들어 `fictional.registry.example/imagename`
|
||||
와 같다. 그리고 `fictional.registry.example:10443/imagename` 와 같이 포트 번호도 포함할 수 있다.
|
||||
|
||||
레지스트리 호스트 이름을 지정하지 않으면, 쿠버네티스는 도커 퍼블릭 레지스트리를 의미한다고 가정한다.
|
||||
|
||||
|
@ -275,6 +275,8 @@ kubelet은 크리덴셜을 순차적으로 사용하여 풀을 시도한다.
|
|||
{{< /note >}}
|
||||
|
||||
쿠버네티스는 파드에 컨테이너 이미지 레지스트리 키를 명시하는 것을 지원한다.
|
||||
`imagePullSecrets`은 모두 파드와 동일한 네임스페이스에 있어야 한다.
|
||||
참조되는 시크릿의 타입은 `kubernetes.io/dockercfg` 이거나 `kubernetes.io/dockerconfigjson` 이어야 한다.
|
||||
|
||||
#### 도커 구성으로 시크릿 생성
|
||||
|
||||
|
|
|
@ -26,7 +26,7 @@ weight: 10
|
|||
동적 등록을 통해 실행 중인 클러스터에서 커스텀 리소스가 나타나거나 사라질 수 있으며
|
||||
클러스터 관리자는 클러스터 자체와 독립적으로 커스텀 리소스를 업데이트 할 수 있다.
|
||||
커스텀 리소스가 설치되면 사용자는 *파드* 와 같은 빌트인 리소스와 마찬가지로
|
||||
[kubectl](/ko/docs/reference/kubectl/)을 사용하여 해당 오브젝트를 생성하고
|
||||
{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}을 사용하여 해당 오브젝트를 생성하고
|
||||
접근할 수 있다.
|
||||
|
||||
## 커스텀 컨트롤러
|
||||
|
@ -99,7 +99,7 @@ _선언적(declarative) API_ 를 제공하게 된다.
|
|||
* 파일이 업데이트될 때 디플로이먼트 등을 통해 롤링 업데이트를 수행하려고 한다.
|
||||
|
||||
{{< note >}}
|
||||
민감한 데이터에는 [시크릿](/ko/docs/concepts/configuration/secret/)을 사용하자. 이는 컨피그맵과 비슷하지만 더 안전한다.
|
||||
민감한 데이터에는 {{< glossary_tooltip text="시크릿" term_id="secret" >}}을 사용하자. 이는 컨피그맵과 비슷하지만 더 안전하다.
|
||||
{{< /note >}}
|
||||
|
||||
다음 중 대부분이 적용되는 경우 커스텀 리소스(CRD 또는 애그리게이트 API(aggregated API))를 사용하자.
|
||||
|
|
|
@ -68,7 +68,7 @@ metadata:
|
|||
spec:
|
||||
containers:
|
||||
- name: demo-container-1
|
||||
image: k8s.gcr.io/pause:2.0
|
||||
image: registry.k8s.io/pause:2.0
|
||||
resources:
|
||||
limits:
|
||||
hardware-vendor.example/foo: 2
|
||||
|
|
|
@ -15,7 +15,7 @@ weight: 30
|
|||
|
||||
## 동기 부여
|
||||
|
||||
오퍼레이터 패턴은 서비스 또는 서비스 셋을 관리하는 운영자의
|
||||
_오퍼레이터 패턴_은 서비스 또는 서비스 셋을 관리하는 운영자의
|
||||
주요 목표를 포착하는 것을 목표로 한다. 특정 애플리케이션 및
|
||||
서비스를 돌보는 운영자는 시스템의 작동 방식, 배포 방법 및 문제가 있는 경우
|
||||
대처 방법에 대해 깊이 알고 있다.
|
||||
|
|
Loading…
Reference in New Issue