Merge pull request #46829 from YanyChoi/dev-1.27-ko.1-yanychoi-10-to-15
[ko] Update outdated files in dev-1.27-ko.1 [M10-15]dev-1.27-ko.1
Kubernetes Prow Robot
GitHub
commit
836f431939
|
|
@ -10,42 +10,66 @@ weight: 120
|
|||
|
||||
애드온은 쿠버네티스의 기능을 확장한다.
|
||||
|
||||
이 페이지는 사용 가능한 일부 애드온과 관련 설치 지침 링크를 나열한다. 이 목차에서 전체를 다루지는 않는다.
|
||||
이 페이지는 사용 가능한 일부 애드온과 관련 설치 지침 링크를 나열한다.
|
||||
이 목차에서 전체를 다루지는 않는다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 네트워킹과 네트워크 폴리시
|
||||
|
||||
* [ACI](https://www.github.com/noironetworks/aci-containers)는 Cisco ACI로 통합 컨테이너 네트워킹 및 네트워크 보안을 제공한다.
|
||||
* [Antrea](https://antrea.io/)는 레이어 3/4에서 작동하여 쿠버네티스를 위한 네트워킹 및 보안 서비스를 제공하며, Open vSwitch를 네트워킹 데이터 플레인으로 활용한다.
|
||||
* [Calico](https://docs.projectcalico.org/latest/introduction/)는 네트워킹 및 네트워크 폴리시 제공자이다. Calico는 유연한 네트워킹 옵션을 지원하므로 BGP 유무에 관계없이 비-오버레이 및 오버레이 네트워크를 포함하여 가장 상황에 맞는 옵션을 선택할 수 있다. Calico는 동일한 엔진을 사용하여 서비스 메시 계층(service mesh layer)에서 호스트, 파드 및 (이스티오(istio)와 Envoy를 사용하는 경우) 애플리케이션에 대한 네트워크 폴리시를 적용한다.
|
||||
* [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel)은 Flannel과 Calico를 통합하여 네트워킹 및 네트워크 폴리시를 제공한다.
|
||||
* [Cilium](https://github.com/cilium/cilium)은 네트워킹, 관측 용의성(Observability), 보안 특징을 지닌 eBPF 기반 데이터 플레인을 갖춘 솔루션입니다. Cilium은 기본 라우팅 및 오버레이/캡슐화 모드를 모두 지원하며, 여러 클러스터를 포괄할 수 있는 단순한 플랫(flat) Layer 3 네트워크를 제공합니다. 또한, Cilium은 (네트워크 주소 지정 방식에서 분리된) 신원 기반 보안 모델(identity-based security model)을 사용하여 L3-L7에서 네트워크 정책을 시행할 수 있습니다. Cilium은 kube-proxy를 대체하는 역할을 할 수 있습니다. 또한 부가적으로, 옵트인(opt-in) 형태로 관측 용의성(Observability) 및 보안 기능을 제공합니다.
|
||||
* [CNI-Genie](https://github.com/cni-genie/CNI-Genie)를 사용하면 쿠버네티스는 Calico, Canal, Flannel, Romana 또는 Weave와 같은 CNI 플러그인을 완벽하게 연결할 수 있다.
|
||||
* [Contiv](https://contivpp.io/)는 다양한 유스케이스와 풍부한 폴리시 프레임워크를 위해 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 그리고 Cisco-SDN/ACI)을 제공한다. Contiv 프로젝트는 완전히 [오픈소스](https://github.com/contiv)이다. [인스톨러](https://github.com/contiv/install)는 kubeadm을 이용하거나, 그렇지 않은 경우에 대해서도 설치 옵션을 모두 제공한다.
|
||||
* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 [Tungsten Fabric](https://tungsten.io)을 기반으로 하며, 오픈소스이고, 멀티 클라우드 네트워크 가상화 및 폴리시 관리 플랫폼이다. Contrail과 Tungsten Fabric은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어 메탈 워크로드에 대한 격리 모드를 제공한다.
|
||||
* [Antrea](https://antrea.io/)는 레이어 3/4에서 작동하여 쿠버네티스를 위한 네트워킹 및 보안 서비스를 제공하며, Open vSwitch를 네트워킹 데이터 플레인으로
|
||||
활용한다. Antrea는 현재 [샌드박스 단계의 CNCF 프로젝트](https://www.cncf.io/projects/antrea/)이다.
|
||||
* [Calico](https://www.tigera.io/project-calico/)는 네트워킹 및 네트워크 폴리시 제공자이다. Calico는 유연한 네트워킹 옵션을 지원하므로 BGP 유무에
|
||||
관계없이 비-오버레이 및 오버레이 네트워크를 포함하여 가장 상황에 맞는 옵션을 선택할 수 있다. Calico는 동일한 엔진을 사용하여 서비스 메시 계층(service mesh
|
||||
layer)에서 호스트, 파드 및 (이스티오(istio)와 Envoy를 사용하는 경우) 애플리케이션에 대한 네트워크 폴리시를 적용한다.
|
||||
* [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel)은 Flannel과 Calico를 통합하여 네트워킹 및
|
||||
네트워크 폴리시를 제공한다.
|
||||
* [Cilium](https://github.com/cilium/cilium)은 네트워킹, 관측 용의성(Observability), 보안 특징을 지닌 eBPF 기반 데이터 플레인을 갖춘 솔루션이다.
|
||||
Cilium은 기본 라우팅 및 오버레이/캡슐화 모드를 모두 지원하며, 여러 클러스터를 포괄할 수 있는 단순한 플랫(flat) Layer 3 네트워크를 제공한다. 또한, Cilium은
|
||||
(네트워크 주소 지정 방식에서 분리된) 신원 기반 보안 모델(identity-based security model)을 사용하여 L3-L7에서 네트워크 정책을 시행할 수 있다. Cilium은
|
||||
kube-proxy를 대체하는 역할을 할 수 있다. 또한 부가적으로, 옵트인(opt-in) 형태로 관측 용의성(Observability) 및 보안 기능을 제공한다. Cilium은 현재 [인큐베이션 단계의 CNCF 프로젝트](https://www.cncf.io/projects/cilium/)이다.
|
||||
* [CNI-Genie](https://github.com/cni-genie/CNI-Genie)를 사용하면 쿠버네티스는 Calico, Canal, Flannel, Romana 또는 Weave와 같은 CNI
|
||||
플러그인을 완벽하게 연결할 수 있다. CNI-Genie는 현재 [샌드박스 단계의 CNCF 프로젝트](https://www.cncf.io/projects/cni-genie/)이다.
|
||||
* [Contiv](https://contivpp.io/)는 다양한 유스케이스와 풍부한 폴리시 프레임워크를 위해 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는
|
||||
오버레이, 클래식 L2 그리고 Cisco-SDN/ACI)을 제공한다. Contiv 프로젝트는 완전히 [오픈소스](https://github.com/contiv)이다.
|
||||
[인스톨러](https://github.com/contiv/install)는 kubeadm을 이용하거나, 그렇지 않은 경우에 대해서도 설치 옵션을 모두 제공한다.
|
||||
* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은
|
||||
[Tungsten Fabric](https://tungsten.io)을 기반으로 하며, 오픈소스이고, 멀티 클라우드 네트워크 가상화 및 폴리시 관리 플랫폼이다. Contrail과 Tungsten
|
||||
Fabric은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어 메탈 워크로드에 대한
|
||||
격리 모드를 제공한다.
|
||||
* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually)은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다.
|
||||
* [Knitter](https://github.com/ZTE/Knitter/)는 쿠버네티스 파드에서 여러 네트워크 인터페이스를 지원하는 플러그인이다.
|
||||
* [Multus](https://github.com/k8snetworkplumbingwg/multus-cni)는 쿠버네티스의 다중 네트워크 지원을 위한 멀티 플러그인이며, 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)과 쿠버네티스 상의 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드를 지원한다.
|
||||
* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/)는 Open vSwitch(OVS) 프로젝트에서 나온 가상 네트워킹 구현인 [OVN(Open Virtual Network)](https://github.com/ovn-org/ovn/)을 기반으로 하는 쿠버네티스용 네트워킹 제공자이다. OVN-Kubernetes는 OVS 기반 로드 밸런싱과 네트워크 폴리시 구현을 포함하여 쿠버네티스용 오버레이 기반 네트워킹 구현을 제공한다.
|
||||
* [Nodus](https://github.com/akraino-edge-stack/icn-nodus)는 클라우드 네이티브 기반 서비스 기능 체인(SFC)을 제공하는 OVN 기반 CNI 컨트롤러 플러그인이다.
|
||||
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다.
|
||||
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)는 가시성과 보안 모니터링 기능을 통해 쿠버네티스 파드와 비-쿠버네티스 환경 간에 폴리시 기반 네트워킹을 제공하는 SDN 플랫폼이다.
|
||||
* [Romana](https://github.com/romana)는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다.
|
||||
* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/)은 네트워킹 및 네트워크 폴리시를 제공하고, 네트워크 파티션의 양면에서 작업을 수행하며, 외부 데이터베이스는 필요하지 않다.
|
||||
* [Multus](https://github.com/k8snetworkplumbingwg/multus-cni)는 쿠버네티스의 다중 네트워크 지원을 위한 멀티 플러그인이며,
|
||||
모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)과 쿠버네티스 상의 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드를 지원한다.
|
||||
* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/)는 Open vSwitch(OVS) 프로젝트에서 나온 가상 네트워킹 구현인
|
||||
[OVN(Open Virtual Network)](https://github.com/ovn-org/ovn/)을 기반으로 하는 쿠버네티스용 네트워킹 제공자이다. OVN-Kubernetes는 OVS 기반
|
||||
로드 밸런싱과 네트워크 폴리시 구현을 포함하여 쿠버네티스용 오버레이 기반 네트워킹 구현을 제공한다.
|
||||
* [Nodus](https://github.com/akraino-edge-stack/icn-nodus)는 클라우드 네이티브 기반 서비스 기능 체인(SFC)을 제공하는 OVN 기반 CNI 컨트롤러
|
||||
플러그인이다.
|
||||
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은
|
||||
컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다.
|
||||
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)는 가시성과 보안
|
||||
모니터링 기능을 통해 쿠버네티스 파드와 비-쿠버네티스 환경 간에 폴리시 기반 네트워킹을 제공하는 SDN 플랫폼이다.
|
||||
* [Romana](https://github.com/romana)는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드
|
||||
네트워크용 Layer 3 네트워킹 솔루션이다.
|
||||
* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/)은 네트워킹 및 네트워크 폴리시를 제공하고, 네트워크 파티션의
|
||||
양면에서 작업을 수행하며, 외부 데이터베이스는 필요하지 않다.
|
||||
|
||||
## 서비스 검색
|
||||
|
||||
* [CoreDNS](https://coredns.io)는 유연하고 확장 가능한 DNS 서버로, 파드를 위한 클러스터 내 DNS로 [설치](https://github.com/coredns/deployment/tree/master/kubernetes)할 수 있다.
|
||||
* [CoreDNS](https://coredns.io)는 유연하고 확장 가능한 DNS 서버로, 파드를 위한 클러스터 내 DNS로
|
||||
[설치](https://github.com/coredns/deployment/tree/master/kubernetes)할 수 있다.
|
||||
|
||||
## 시각화 & 제어
|
||||
|
||||
* [대시보드](https://github.com/kubernetes/dashboard#kubernetes-dashboard)는 쿠버네티스를 위한 대시보드 웹 인터페이스이다.
|
||||
* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s)는 컨테이너, 파드, 서비스 등을 그래픽으로 시각화하는 도구이다. [Weave Cloud 어카운트](https://cloud.weave.works/)와 함께 사용하거나 UI를 직접 호스팅한다.
|
||||
* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s)는 컨테이너, 파드, 서비스 등을 그래픽으로 시각화하는
|
||||
도구이다. [Weave Cloud 어카운트](https://cloud.weave.works/)와 함께 사용하거나 UI를 직접 호스팅한다.
|
||||
|
||||
## 인프라스트럭처
|
||||
|
||||
* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation)는 쿠버네티스에서 가상 머신을 실행하기 위한 애드온이다. 일반적으로 베어 메탈 클러스터에서 실행한다.
|
||||
* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation)는 쿠버네티스에서 가상 머신을 실행하기 위한 애드온이다. 일반적으로 베어메탈 클러스터에서 실행한다.
|
||||
* [node problem detector](https://github.com/kubernetes/node-problem-detector)는
|
||||
리눅스 노드에서 실행되며,
|
||||
시스템 이슈를
|
||||
|
|
|
|||
|
|
@ -81,7 +81,8 @@ kubectl logs counter -c count
|
|||
|
||||
|
||||
|
||||
컨테이너화된 애플리케이션의 `stdout(표준 출력)` 및 `stderr(표준 에러)` 스트림에 의해 생성된 모든 출력은 컨테이너 런타임이 처리하고 리디렉션 시킨다.
|
||||
컨테이너화된 애플리케이션의 `stdout(표준 출력)` 및 `stderr(표준 에러)` 스트림에 의해 생성된 모든 출력은
|
||||
컨테이너 런타임이 처리하고 리디렉션 시킨다.
|
||||
다양한 컨테이너 런타임들은 이를 각자 다른 방법으로 구현하였지만,
|
||||
kubelet과의 호환성은 _CRI 로깅 포맷_ 으로 표준화되어 있다.
|
||||
|
||||
|
|
@ -103,7 +104,7 @@ kubelet은 이 정보를 컨테이너 런타임에 전송하고(CRI를 사용),
|
|||
|
||||
[kubelet 설정 파일](/docs/tasks/administer-cluster/kubelet-config-file/)을 사용하여
|
||||
두 개의 kubelet 파라미터
|
||||
[`containerLogMaxSize` 및 `containerLogMaxFiles`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)를 설정 가능하다.
|
||||
[`containerLogMaxSize` 및 `containerLogMaxFiles`](/docs/reference/config-api/kubelet-config.v1beta1/)를 설정 가능하다.
|
||||
이러한 설정을 통해 각 로그 파일의 최대 크기와 각 컨테이너에 허용되는 최대 파일 수를 각각 구성할 수 있다.
|
||||
|
||||
기본 로깅 예제에서와 같이 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs)를
|
||||
|
|
@ -201,7 +202,8 @@ etcd와 etcd의 로그를 기록하는 방식에 대한 자세한 정보는 [etc
|
|||
|
||||
## 클러스터-레벨 로깅 아키텍처 {#cluster-level-logging-architectures}
|
||||
|
||||
쿠버네티스는 클러스터-레벨 로깅을 위한 네이티브 솔루션을 제공하지 않지만, 고려해야 할 몇 가지 일반적인 접근 방법을 고려할 수 있다. 여기 몇 가지 옵션이 있다.
|
||||
쿠버네티스는 클러스터-레벨 로깅을 위한 네이티브 솔루션을 제공하지 않지만,
|
||||
고려해야 할 몇 가지 일반적인 접근 방법을 고려할 수 있다. 여기 몇 가지 옵션이 있다.
|
||||
|
||||
* 모든 노드에서 실행되는 노드-레벨 로깅 에이전트를 사용한다.
|
||||
* 애플리케이션 파드에 로깅을 위한 전용 사이드카 컨테이너를 포함한다.
|
||||
|
|
@ -211,7 +213,9 @@ etcd와 etcd의 로그를 기록하는 방식에 대한 자세한 정보는 [etc
|
|||
|
||||
|
||||
|
||||
각 노드에 _노드-레벨 로깅 에이전트_ 를 포함시켜 클러스터-레벨 로깅을 구현할 수 있다. 로깅 에이전트는 로그를 노출하거나 로그를 백엔드로 푸시하는 전용 도구이다. 일반적으로, 로깅 에이전트는 해당 노드의 모든 애플리케이션 컨테이너에서 로그 파일이 있는 디렉터리에 접근할 수 있는 컨테이너이다.
|
||||
각 노드에 _노드-레벨 로깅 에이전트_ 를 포함시켜 클러스터-레벨 로깅을 구현할 수 있다.
|
||||
로깅 에이전트는 로그를 노출하거나 로그를 백엔드로 푸시하는 전용 도구이다.
|
||||
일반적으로, 로깅 에이전트는 해당 노드의 모든 애플리케이션 컨테이너에서 로그 파일이 있는 디렉터리에 접근할 수 있는 컨테이너이다.
|
||||
|
||||
로깅 에이전트는 모든 노드에서 실행되어야 하므로, 에이전트를
|
||||
`DaemonSet` 으로 동작시키는 것을 추천한다.
|
||||
|
|
|
|||
|
|
@ -1,20 +1,25 @@
|
|||
---
|
||||
# reviewers:
|
||||
# - janetkuo
|
||||
title: 리소스 관리
|
||||
content_type: concept
|
||||
# reviewers:
|
||||
# - janetkuo
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
애플리케이션을 배포하고 서비스를 통해 노출했다. 이제 무엇을 해야 할까? 쿠버네티스는 확장과 업데이트를 포함하여, 애플리케이션 배포를 관리하는 데 도움이 되는 여러 도구를 제공한다. 더 자세히 설명할 기능 중에는 [구성 파일](/ko/docs/concepts/configuration/overview/)과 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)이 있다.
|
||||
애플리케이션을 배포하고 서비스를 통해 노출했다. 이제 무엇을 해야 할까? 쿠버네티스는 확장과 업데이트를 포함하여,
|
||||
애플리케이션 배포를 관리하는 데 도움이 되는 여러 도구를 제공한다. 더 자세히 설명할 기능 중에는
|
||||
[구성 파일](/ko/docs/concepts/configuration/overview/)과
|
||||
[레이블](/ko/docs/concepts/overview/working-with-objects/labels/)이 있다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 리소스 구성 구성하기
|
||||
|
||||
많은 애플리케이션들은 디플로이먼트 및 서비스와 같은 여러 리소스를 필요로 한다. 여러 리소스의 관리는 동일한 파일에 그룹화하여 단순화할 수 있다(YAML에서 `---` 로 구분). 예를 들면 다음과 같다.
|
||||
많은 애플리케이션들은 디플로이먼트 및 서비스와 같은 여러 리소스를 필요로 한다.
|
||||
여러 리소스의 관리는 동일한 파일에 그룹화하여 단순화할 수 있다
|
||||
(YAML에서 `---` 로 구분). 예를 들면 다음과 같다.
|
||||
|
||||
{{% codenew file="application/nginx-app.yaml" %}}
|
||||
|
||||
|
|
@ -24,48 +29,45 @@ weight: 40
|
|||
kubectl apply -f https://k8s.io/examples/application/nginx-app.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
```none
|
||||
service/my-nginx-svc created
|
||||
deployment.apps/my-nginx created
|
||||
```
|
||||
|
||||
리소스는 파일에 표시된 순서대로 생성된다. 따라서, 스케줄러가 디플로이먼트와 같은 컨트롤러에서 생성한 서비스와 관련된 파드를 분산시킬 수 있으므로, 서비스를 먼저 지정하는 것이 가장 좋다.
|
||||
리소스는 파일에 표시된 순서대로 생성된다. 따라서, 스케줄러가 디플로이먼트와 같은 컨트롤러에서
|
||||
생성한 서비스와 관련된 파드를 분산시킬 수 있으므로, 서비스를 먼저 지정하는 것이 가장 좋다.
|
||||
|
||||
`kubectl apply` 는 여러 개의 `-f` 인수도 허용한다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/nginx/nginx-svc.yaml -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml
|
||||
kubectl apply -f https://k8s.io/examples/application/nginx/nginx-svc.yaml \
|
||||
-f https://k8s.io/examples/application/nginx/nginx-deployment.yaml
|
||||
```
|
||||
|
||||
그리고 개별 파일 대신 또는 추가로 디렉터리를 지정할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/nginx/
|
||||
```
|
||||
|
||||
`kubectl` 은 접미사가 `.yaml`, `.yml` 또는 `.json` 인 파일을 읽는다.
|
||||
|
||||
동일한 마이크로서비스 또는 애플리케이션 티어(tier)와 관련된 리소스를 동일한 파일에 배치하고, 애플리케이션과 연관된 모든 파일을 동일한 디렉터리에 그룹화하는 것이 좋다. 애플리케이션의 티어가 DNS를 사용하여 서로 바인딩되면, 스택의 모든 컴포넌트를 함께 배포할 수 있다.
|
||||
동일한 마이크로서비스 또는 애플리케이션 티어(tier)와 관련된 리소스를 동일한 파일에 배치하고,
|
||||
애플리케이션과 연관된 모든 파일을 동일한 디렉터리에 그룹화하는 것이 좋다. 애플리케이션의 티어가 DNS를 사용하여 서로 바인딩되면,
|
||||
스택의 모든 컴포넌트를 함께 배포할 수 있다.
|
||||
|
||||
URL을 구성 소스로 지정할 수도 있다. 이는 GitHub에 체크인된 구성 파일에서 직접 배포하는 데 편리하다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/application/nginx/nginx-deployment.yaml
|
||||
kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
```none
|
||||
deployment.apps/my-nginx created
|
||||
```
|
||||
|
||||
## kubectl에서의 대량 작업
|
||||
|
||||
`kubectl` 이 대량으로 수행할 수 있는 작업은 리소스 생성만이 아니다. 또한 다른 작업을 수행하기 위해, 특히 작성한 동일한 리소스를 삭제하기 위해 구성 파일에서 리소스 이름을 추출할 수도 있다.
|
||||
`kubectl` 이 대량으로 수행할 수 있는 작업은 리소스 생성만이 아니다. 또한 다른 작업을 수행하기 위해,
|
||||
특히 작성한 동일한 리소스를 삭제하기 위해 구성 파일에서 리소스 이름을 추출할 수도 있다.
|
||||
|
||||
```shell
|
||||
kubectl delete -f https://k8s.io/examples/application/nginx-app.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
```none
|
||||
deployment.apps "my-nginx" deleted
|
||||
service "my-nginx-svc" deleted
|
||||
```
|
||||
|
|
@ -82,7 +84,7 @@ kubectl delete deployments/my-nginx services/my-nginx-svc
|
|||
kubectl delete deployment,services -l app=nginx
|
||||
```
|
||||
|
||||
```shell
|
||||
```none
|
||||
deployment.apps "my-nginx" deleted
|
||||
service "my-nginx-svc" deleted
|
||||
```
|
||||
|
|
@ -94,19 +96,22 @@ kubectl get $(kubectl create -f docs/concepts/cluster-administration/nginx/ -o n
|
|||
kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service | xargs -i kubectl get {}
|
||||
```
|
||||
|
||||
```shell
|
||||
```none
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
my-nginx-svc LoadBalancer 10.0.0.208 <pending> 80/TCP 0s
|
||||
```
|
||||
|
||||
위의 명령을 사용하여, 먼저 `examples/application/nginx/` 에 리소스를 생성하고 `-o name` 출력 형식으로 생성한 리소스를 출력한다(각 리소스를 resource/name으로 출력).
|
||||
위의 명령을 사용하여, 먼저 `examples/application/nginx/` 에 리소스를 생성하고 `-o name` 출력 형식으로 생성한 리소스를 출력한다
|
||||
(각 리소스를 resource/name으로 출력).
|
||||
그런 다음 "service"만 `grep` 한 다음 `kubectl get` 으로 출력한다.
|
||||
|
||||
특정 디렉터리 내의 여러 서브 디렉터리에서 리소스를 구성하는 경우, `--filename,-f` 플래그와 함께 `--recursive` 또는 `-R` 을 지정하여, 서브 디렉터리에 대한 작업을 재귀적으로 수행할 수도 있다.
|
||||
특정 디렉터리 내의 여러 서브 디렉터리에서 리소스를 구성하는 경우, `--filename,-f` 플래그와 함께 `--recursive` 또는 `-R` 을 지정하여,
|
||||
서브 디렉터리에 대한 작업을 재귀적으로 수행할 수도 있다.
|
||||
|
||||
예를 들어, 리소스 유형별로 구성된 개발 환경에 필요한 모든 {{< glossary_tooltip text="매니페스트" term_id="manifest" >}}를 보유하는 `project/k8s/development` 디렉터리가 있다고 가정하자.
|
||||
예를 들어, 리소스 유형별로 구성된 개발 환경에 필요한 모든 {{< glossary_tooltip text="매니페스트" term_id="manifest" >}}를 보유하는
|
||||
`project/k8s/development` 디렉터리가 있다고 가정하자.
|
||||
|
||||
```
|
||||
```none
|
||||
project/k8s/development
|
||||
├── configmap
|
||||
│ └── my-configmap.yaml
|
||||
|
|
@ -116,13 +121,14 @@ project/k8s/development
|
|||
└── my-pvc.yaml
|
||||
```
|
||||
|
||||
기본적으로, `project/k8s/development` 에서 대량 작업을 수행하면, 서브 디렉터리를 처리하지 않고, 디렉터리의 첫 번째 레벨에서 중지된다. 다음 명령을 사용하여 이 디렉터리에 리소스를 생성하려고 하면, 오류가 발생할 것이다.
|
||||
기본적으로, `project/k8s/development` 에서 대량 작업을 수행하면, 서브 디렉터리를 처리하지 않고, 디렉터리의 첫 번째 레벨에서 중지된다.
|
||||
다음 명령을 사용하여 이 디렉터리에 리소스를 생성하려고 하면, 오류가 발생할 것이다.
|
||||
|
||||
```shell
|
||||
kubectl apply -f project/k8s/development
|
||||
```
|
||||
|
||||
```shell
|
||||
```none
|
||||
error: you must provide one or more resources by argument or filename (.json|.yaml|.yml|stdin)
|
||||
```
|
||||
|
||||
|
|
@ -132,13 +138,14 @@ error: you must provide one or more resources by argument or filename (.json|.ya
|
|||
kubectl apply -f project/k8s/development --recursive
|
||||
```
|
||||
|
||||
```shell
|
||||
```none
|
||||
configmap/my-config created
|
||||
deployment.apps/my-deployment created
|
||||
persistentvolumeclaim/my-pvc created
|
||||
```
|
||||
|
||||
`--recursive` 플래그는 `kubectl {create,get,delete,describe,rollout}` 등과 같이 `--filename,-f` 플래그를 허용하는 모든 작업에서 작동한다.
|
||||
`--recursive` 플래그는 `kubectl {create,get,delete,describe,rollout}` 등과 같이
|
||||
`--filename,-f` 플래그를 허용하는 모든 작업에서 작동한다.
|
||||
|
||||
`--recursive` 플래그는 여러 개의 `-f` 인수가 제공될 때도 작동한다.
|
||||
|
||||
|
|
@ -146,7 +153,7 @@ persistentvolumeclaim/my-pvc created
|
|||
kubectl apply -f project/k8s/namespaces -f project/k8s/development --recursive
|
||||
```
|
||||
|
||||
```shell
|
||||
```none
|
||||
namespace/development created
|
||||
namespace/staging created
|
||||
configmap/my-config created
|
||||
|
|
@ -160,30 +167,31 @@ persistentvolumeclaim/my-pvc created
|
|||
|
||||
지금까지 사용한 예는 모든 리소스에 최대 한 개의 레이블만 적용하는 것이었다. 세트를 서로 구별하기 위해 여러 레이블을 사용해야 하는 많은 시나리오가 있다.
|
||||
|
||||
예를 들어, 애플리케이션마다 `app` 레이블에 다른 값을 사용하지만, [방명록 예제](https://github.com/kubernetes/examples/tree/master/guestbook/)와 같은 멀티-티어 애플리케이션은 각 티어를 추가로 구별해야 한다. 프론트엔드는 다음의 레이블을 가질 수 있다.
|
||||
예를 들어, 애플리케이션마다 `app` 레이블에 다른 값을 사용하지만,[방명록 예제](https://github.com/kubernetes/examples/tree/master/guestbook/)와
|
||||
같은 멀티-티어 애플리케이션은 각 티어를 추가로 구별해야 한다. 프론트엔드는 다음의 레이블을 가질 수 있다.
|
||||
|
||||
```yaml
|
||||
labels:
|
||||
app: guestbook
|
||||
tier: frontend
|
||||
labels:
|
||||
app: guestbook
|
||||
tier: frontend
|
||||
```
|
||||
|
||||
Redis 마스터와 슬레이브는 프론트엔드와 다른 `tier` 레이블을 가지지만, 아마도 추가로 `role` 레이블을 가질 것이다.
|
||||
|
||||
```yaml
|
||||
labels:
|
||||
app: guestbook
|
||||
tier: backend
|
||||
role: master
|
||||
labels:
|
||||
app: guestbook
|
||||
tier: backend
|
||||
role: master
|
||||
```
|
||||
|
||||
그리고
|
||||
|
||||
```yaml
|
||||
labels:
|
||||
app: guestbook
|
||||
tier: backend
|
||||
role: slave
|
||||
labels:
|
||||
app: guestbook
|
||||
tier: backend
|
||||
role: slave
|
||||
```
|
||||
|
||||
레이블은 레이블로 지정된 차원에 따라 리소스를 분할하고 사용할 수 있게 한다.
|
||||
|
|
@ -193,7 +201,7 @@ kubectl apply -f examples/guestbook/all-in-one/guestbook-all-in-one.yaml
|
|||
kubectl get pods -Lapp -Ltier -Lrole
|
||||
```
|
||||
|
||||
```shell
|
||||
```none
|
||||
NAME READY STATUS RESTARTS AGE APP TIER ROLE
|
||||
guestbook-fe-4nlpb 1/1 Running 0 1m guestbook frontend <none>
|
||||
guestbook-fe-ght6d 1/1 Running 0 1m guestbook frontend <none>
|
||||
|
|
@ -208,7 +216,8 @@ my-nginx-o0ef1 1/1 Running 0 29m nginx
|
|||
```shell
|
||||
kubectl get pods -lapp=guestbook,role=slave
|
||||
```
|
||||
```shell
|
||||
|
||||
```none
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
guestbook-redis-slave-2q2yf 1/1 Running 0 3m
|
||||
guestbook-redis-slave-qgazl 1/1 Running 0 3m
|
||||
|
|
@ -216,45 +225,46 @@ guestbook-redis-slave-qgazl 1/1 Running 0 3m
|
|||
|
||||
## 카나리(canary) 디플로이먼트
|
||||
|
||||
여러 레이블이 필요한 또 다른 시나리오는 동일한 컴포넌트의 다른 릴리스 또는 구성의 디플로이먼트를 구별하는 것이다. 새 릴리스가 완전히 롤아웃되기 전에 실제 운영 트래픽을 수신할 수 있도록 새로운 애플리케이션 릴리스(파드 템플리트의 이미지 태그를 통해 지정됨)의 *카나리* 를 이전 릴리스와 나란히 배포하는 것이 일반적이다.
|
||||
여러 레이블이 필요한 또 다른 시나리오는 동일한 컴포넌트의 다른 릴리스 또는 구성의 디플로이먼트를 구별하는 것이다.
|
||||
새 릴리스가 완전히 롤아웃되기 전에 실제 운영 트래픽을 수신할 수 있도록 새로운 애플리케이션 릴리스(파드 템플리트의 이미지 태그를 통해 지정됨)의
|
||||
_카나리_ 를 이전 릴리스와 나란히 배포하는 것이 일반적이다.
|
||||
|
||||
예를 들어, `track` 레이블을 사용하여 다른 릴리스를 구별할 수 있다.
|
||||
|
||||
기본(primary), 안정(stable) 릴리스에는 값이 `stable` 인 `track` 레이블이 있다.
|
||||
|
||||
```yaml
|
||||
name: frontend
|
||||
replicas: 3
|
||||
...
|
||||
labels:
|
||||
app: guestbook
|
||||
tier: frontend
|
||||
track: stable
|
||||
...
|
||||
image: gb-frontend:v3
|
||||
```none
|
||||
name: frontend
|
||||
replicas: 3
|
||||
...
|
||||
labels:
|
||||
app: guestbook
|
||||
tier: frontend
|
||||
track: stable
|
||||
...
|
||||
image: gb-frontend:v3
|
||||
```
|
||||
|
||||
그런 다음 서로 다른 값(예: `canary`)으로 `track` 레이블을 전달하는 방명록 프론트엔드의 새 릴리스를 생성하여, 두 세트의 파드가 겹치지 않도록 할 수 있다.
|
||||
|
||||
```yaml
|
||||
name: frontend-canary
|
||||
replicas: 1
|
||||
...
|
||||
labels:
|
||||
app: guestbook
|
||||
tier: frontend
|
||||
track: canary
|
||||
...
|
||||
image: gb-frontend:v4
|
||||
```none
|
||||
name: frontend-canary
|
||||
replicas: 1
|
||||
...
|
||||
labels:
|
||||
app: guestbook
|
||||
tier: frontend
|
||||
track: canary
|
||||
...
|
||||
image: gb-frontend:v4
|
||||
```
|
||||
|
||||
|
||||
프론트엔드 서비스는 레이블의 공통 서브셋을 선택하여(즉, `track` 레이블 생략) 두 레플리카 세트에 걸쳐 있으므로, 트래픽이 두 애플리케이션으로 리디렉션된다.
|
||||
|
||||
```yaml
|
||||
selector:
|
||||
app: guestbook
|
||||
tier: frontend
|
||||
selector:
|
||||
app: guestbook
|
||||
tier: frontend
|
||||
```
|
||||
|
||||
안정 및 카나리 릴리스의 레플리카 수를 조정하여 실제 운영 트래픽을 수신할 각 릴리스의 비율을 결정한다(이 경우, 3:1).
|
||||
|
|
@ -271,7 +281,7 @@ guestbook-redis-slave-qgazl 1/1 Running 0 3m
|
|||
kubectl label pods -l app=nginx tier=fe
|
||||
```
|
||||
|
||||
```shell
|
||||
```none
|
||||
pod/my-nginx-2035384211-j5fhi labeled
|
||||
pod/my-nginx-2035384211-u2c7e labeled
|
||||
pod/my-nginx-2035384211-u3t6x labeled
|
||||
|
|
@ -283,7 +293,8 @@ pod/my-nginx-2035384211-u3t6x labeled
|
|||
```shell
|
||||
kubectl get pods -l app=nginx -L tier
|
||||
```
|
||||
```shell
|
||||
|
||||
```none
|
||||
NAME READY STATUS RESTARTS AGE TIER
|
||||
my-nginx-2035384211-j5fhi 1/1 Running 0 23m fe
|
||||
my-nginx-2035384211-u2c7e 1/1 Running 0 23m fe
|
||||
|
|
@ -292,11 +303,13 @@ my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe
|
|||
|
||||
그러면 파드 티어의 추가 레이블 열(`-L` 또는 `--label-columns` 로 지정)과 함께, 모든 "app=nginx" 파드가 출력된다.
|
||||
|
||||
더 자세한 내용은, [레이블](/ko/docs/concepts/overview/working-with-objects/labels/) 및 [kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label)을 참고하길 바란다.
|
||||
더 자세한 내용은, [레이블](/ko/docs/concepts/overview/working-with-objects/labels/) 및
|
||||
[kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label)을 참고하길 바란다.
|
||||
|
||||
## 어노테이션 업데이트
|
||||
|
||||
때로는 어노테이션을 리소스에 첨부하려고 할 수도 있다. 어노테이션은 도구, 라이브러리 등과 같은 API 클라이언트가 검색할 수 있는 임의의 비-식별 메타데이터이다. 이는 `kubectl annotate` 으로 수행할 수 있다. 예를 들면 다음과 같다.
|
||||
때로는 어노테이션을 리소스에 첨부하려고 할 수도 있다. 어노테이션은 도구, 라이브러리 등과 같은 API 클라이언트가 검색할 수 있는 임의의 비-식별 메타데이터이다.
|
||||
이는 `kubectl annotate` 으로 수행할 수 있다. 예를 들면 다음과 같다.
|
||||
|
||||
```shell
|
||||
kubectl annotate pods my-nginx-v4-9gw19 description='my frontend running nginx'
|
||||
|
|
@ -312,7 +325,8 @@ metadata:
|
|||
...
|
||||
```
|
||||
|
||||
더 자세한 내용은, [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/) 및 [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate) 문서를 참고하길 바란다.
|
||||
더 자세한 내용은, [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/) 및
|
||||
[kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate) 문서를 참고하길 바란다.
|
||||
|
||||
## 애플리케이션 스케일링
|
||||
|
||||
|
|
@ -322,7 +336,7 @@ metadata:
|
|||
kubectl scale deployment/my-nginx --replicas=1
|
||||
```
|
||||
|
||||
```shell
|
||||
```none
|
||||
deployment.apps/my-nginx scaled
|
||||
```
|
||||
|
||||
|
|
@ -332,7 +346,7 @@ deployment.apps/my-nginx scaled
|
|||
kubectl get pods -l app=nginx
|
||||
```
|
||||
|
||||
```shell
|
||||
```none
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
my-nginx-2035384211-j5fhi 1/1 Running 0 30m
|
||||
```
|
||||
|
|
@ -343,14 +357,15 @@ my-nginx-2035384211-j5fhi 1/1 Running 0 30m
|
|||
kubectl autoscale deployment/my-nginx --min=1 --max=3
|
||||
```
|
||||
|
||||
```shell
|
||||
```none
|
||||
horizontalpodautoscaler.autoscaling/my-nginx autoscaled
|
||||
```
|
||||
|
||||
이제 nginx 레플리카가 필요에 따라 자동으로 확장되거나 축소된다.
|
||||
|
||||
더 자세한 내용은, [kubectl scale](/docs/reference/generated/kubectl/kubectl-commands/#scale), [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) 및 [horizontal pod autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale/) 문서를 참고하길 바란다.
|
||||
|
||||
더 자세한 내용은, [kubectl scale](/docs/reference/generated/kubectl/kubectl-commands/#scale),
|
||||
[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) 및
|
||||
[horizontal pod autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale/) 문서를 참고하길 바란다.
|
||||
|
||||
## 리소스 인플레이스(in-place) 업데이트
|
||||
|
||||
|
|
@ -367,14 +382,20 @@ horizontalpodautoscaler.autoscaling/my-nginx autoscaled
|
|||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml
|
||||
```
|
||||
|
||||
```none
|
||||
deployment.apps/my-nginx configured
|
||||
```
|
||||
|
||||
참고로 `kubectl apply` 는 이전의 호출 이후 구성의 변경 사항을 판별하기 위해 리소스에 어노테이션을 첨부한다. 호출되면, `kubectl apply` 는 리소스를 수정하는 방법을 결정하기 위해, 이전 구성과 제공된 입력 및 리소스의 현재 구성 간에 3-way diff를 수행한다.
|
||||
참고로 `kubectl apply` 는 이전의 호출 이후 구성의 변경 사항을 판별하기 위해 리소스에 어노테이션을 첨부한다. 호출되면, `kubectl apply` 는 리소스를 수정하는
|
||||
방법을 결정하기 위해, 이전 구성과 제공된 입력 및 리소스의 현재 구성 간에 3-way diff를 수행한다.
|
||||
|
||||
현재, 이 어노테이션 없이 리소스가 생성되므로, `kubectl apply` 의 첫 번째 호출은 제공된 입력과 리소스의 현재 구성 사이의 2-way diff로 대체된다. 이 첫 번째 호출 중에는, 리소스를 생성할 때 설정된 특성의 삭제를 감지할 수 없다. 이러한 이유로, 그 특성들을 삭제하지 않는다.
|
||||
현재, 이 어노테이션 없이 리소스가 생성되므로, `kubectl apply` 의 첫 번째 호출은 제공된 입력과 리소스의 현재 구성 사이의 2-way diff로 대체된다. 이 첫 번째
|
||||
호출 중에는, 리소스를 생성할 때 설정된 특성의 삭제를 감지할 수 없다. 이러한 이유로, 그 특성들을 삭제하지 않는다.
|
||||
|
||||
`kubectl apply` 에 대한 모든 후속 호출, 그리고 `kubectl replace` 및 `kubectl edit` 와 같이 구성을 수정하는 다른 명령은, 어노테이션을 업데이트하여, `kubectl apply` 에 대한 후속 호출이 3-way diff를 사용하여 삭제를 감지하고 수행할 수 있도록 한다.
|
||||
`kubectl apply` 에 대한 모든 후속 호출, 그리고 `kubectl replace` 및 `kubectl edit` 와 같이 구성을 수정하는 다른 명령은, 어노테이션을 업데이트하여,
|
||||
`kubectl apply` 에 대한 후속 호출이 3-way diff를 사용하여 삭제를 감지하고 수행할 수 있도록 한다.
|
||||
|
||||
### kubectl edit
|
||||
|
||||
|
|
@ -411,20 +432,22 @@ JSON 병합 패치 그리고 전략적 병합 패치를 지원한다.
|
|||
|
||||
## 파괴적(disruptive) 업데이트
|
||||
|
||||
경우에 따라, 한 번 초기화하면 업데이트할 수 없는 리소스 필드를 업데이트해야 하거나, 디플로이먼트에서 생성된 손상된 파드를 고치는 등의 재귀적 변경을 즉시 원할 수도 있다. 이러한 필드를 변경하려면, `replace --force` 를 사용하여 리소스를 삭제하고 다시 만든다. 이 경우, 원래 구성 파일을 수정할 수 있다.
|
||||
경우에 따라, 한 번 초기화하면 업데이트할 수 없는 리소스 필드를 업데이트해야 하거나, 디플로이먼트에서 생성된 손상된 파드를 고치는 등의 재귀적 변경을
|
||||
즉시 원할 수도 있다. 이러한 필드를 변경하려면, `replace --force` 를 사용하여 리소스를 삭제하고 다시 만든다. 이 경우, 원래 구성 파일을 수정할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl replace -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml --force
|
||||
```
|
||||
|
||||
```shell
|
||||
```none
|
||||
deployment.apps/my-nginx deleted
|
||||
deployment.apps/my-nginx replaced
|
||||
```
|
||||
|
||||
## 서비스 중단없이 애플리케이션 업데이트
|
||||
|
||||
언젠가는, 위의 카나리 디플로이먼트 시나리오에서와 같이, 일반적으로 새 이미지 또는 이미지 태그를 지정하여, 배포된 애플리케이션을 업데이트해야 한다. `kubectl` 은 여러 가지 업데이트 작업을 지원하며, 각 업데이트 작업은 서로 다른 시나리오에 적용할 수 있다.
|
||||
언젠가는, 위의 카나리 디플로이먼트 시나리오에서와 같이, 일반적으로 새 이미지 또는 이미지 태그를 지정하여, 배포된 애플리케이션을 업데이트해야 한다.
|
||||
`kubectl` 은 여러 가지 업데이트 작업을 지원하며, 각 업데이트 작업은 서로 다른 시나리오에 적용할 수 있다.
|
||||
|
||||
디플로이먼트를 사용하여 애플리케이션을 생성하고 업데이트하는 방법을 안내한다.
|
||||
|
||||
|
|
@ -434,7 +457,7 @@ nginx 1.14.2 버전을 실행한다고 가정해 보겠다.
|
|||
kubectl create deployment my-nginx --image=nginx:1.14.2
|
||||
```
|
||||
|
||||
```shell
|
||||
```none
|
||||
deployment.apps/my-nginx created
|
||||
```
|
||||
|
||||
|
|
@ -444,7 +467,7 @@ deployment.apps/my-nginx created
|
|||
kubectl scale deployment my-nginx --current-replicas=1 --replicas=3
|
||||
```
|
||||
|
||||
```
|
||||
```none
|
||||
deployment.apps/my-nginx scaled
|
||||
```
|
||||
|
||||
|
|
@ -454,12 +477,12 @@ deployment.apps/my-nginx scaled
|
|||
kubectl edit deployment/my-nginx
|
||||
```
|
||||
|
||||
이것으로 끝이다! 디플로이먼트는 배포된 nginx 애플리케이션을 배후에서 점차적으로 업데이트한다. 업데이트되는 동안 특정 수의 이전 레플리카만 중단될 수 있으며, 원하는 수의 파드 위에 특정 수의 새 레플리카만 생성될 수 있다. 이에 대한 더 자세한 내용을 보려면, [디플로이먼트 페이지](/ko/docs/tasks/debug/debug-application/debug-running-pod/)를 방문한다.
|
||||
|
||||
이것으로 끝이다! 디플로이먼트는 배포된 nginx 애플리케이션을 배후에서 점차적으로 업데이트한다. 업데이트되는 동안 특정 수의 이전 레플리카만 중단될 수 있으며,
|
||||
원하는 수의 파드 위에 특정 수의 새 레플리카만 생성될 수 있다. 이에 대한 더 자세한 내용을 보려면,
|
||||
[디플로이먼트 페이지](/ko/docs/concepts/workloads/controllers/deployment/)를 방문한다.
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
- [애플리케이션 검사 및 디버깅에 `kubectl` 을 사용하는 방법](/ko/docs/tasks/debug/debug-application/debug-running-pod/)에 대해 알아본다.
|
||||
- [구성 모범 사례 및 팁](/ko/docs/concepts/configuration/overview/)을 참고한다.
|
||||
|
|
|
|||
|
|
@ -231,6 +231,42 @@ systemd를 사용하는 시스템에서는, kubelet과 컨테이너 런타임은
|
|||
`kube-up.sh` 스크립트로 생성된 쿠버네티스 클러스터에서는, `logrotate` 도구로 로그가 로테이트되도록 설정된다.
|
||||
`logrotate` 도구는 로그가 매일 또는 크기가 100MB 보다 클 때 로테이트된다.
|
||||
|
||||
## 로그 쿼리
|
||||
|
||||
{{< feature-state for_k8s_version="v1.27" state="alpha" >}}
|
||||
|
||||
노드에서 문제를 디버깅하는 데 유용하도록, 쿠버네티스 v1.27은 노드에서 실행 중인 서비스의 로그를 볼 수 있는 기능을 도입했다. 이 기능을 사용하려면, 해당 노드에 대해 `NodeLogQuery` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있고, kubelet 구성 옵션 `enableSystemLogHandler` 및 `enableSystemLogQuery`가 모두 true로 설정되어 있는지 확인해야 한다. 리눅스에서는 journald를 통해 서비스 로그를 사용할 수 있다고 가정한다. 윈도우에서는 애플리케이션 로그 공급자에서 서비스 로그를 사용할 수 있다고 가정한다. 두 운영 체제 모두에서 `/var/log/` 내의 파일을 읽어서 로그를 사용할 수도 있다.
|
||||
|
||||
노드 오브젝트와 상호 작용할 수 있는 권한이 있는 경우, 모든 노드 또는 하위 집합에서 이 알파 기능을 사용할 수 있다. 다음은 노드에서 kubelet 서비스 로그를 검색하는 예제이다.
|
||||
```shell
|
||||
# node-1.example 노드의 kubelet 로그를 가져온다.
|
||||
kubectl get --raw "/api/v1/nodes/node-1.example/proxy/logs/?query=kubelet"
|
||||
```
|
||||
|
||||
파일이 kubelet이 로그 반환을 허용하는 디렉터리에 있는 경우 파일을 가져올 수도 있다. 예를 들어, 리눅스 노드의 `/var/log`에서 로그를 가져올 수 있다.
|
||||
```shell
|
||||
kubectl get --raw "/api/v1/nodes/<노드 이름>/proxy/logs/?query=/<로그 파일 이름>"
|
||||
```
|
||||
|
||||
Kubelet은 휴리스틱 기법을 활용하여 로그를 검색한다.이는 특정 시스템 서비스가 로그를 journald와 같은 운영 체제의 네이티브 로거에 기록하는지 아니면 `/var/log/`의 로그 파일에 기록하는지 알 수 없는 경우에 유용하다. 휴리스틱은 먼저 네이티브 로거를 확인하고 사용할 수 없는 경우 `/var/log/<서버 이름>` 또는 `/var/log/<서버 이름>.log` 또는 `/var/log/<서버 이름>/<서버 이름>.log`에서 첫 번째 로그를 검색하려고 시도한다.
|
||||
|
||||
사용할 수 있는 전체 옵션 목록은 다음과 같다.
|
||||
|
||||
옵션 | 설명
|
||||
------ | -----------
|
||||
`boot` | boot는 특정 시스템 부팅 메시지를 표시한다.
|
||||
`pattern` | 패턴은 제공된 PERL 호환 정규식으로 로그 항목을 필터링한다.
|
||||
`query` | 쿼리는 로그를 반환할 서비스 또는 파일을 지정한다. (필수)
|
||||
`sinceTime` | 로그를 표시할 [RFC3339](https://www.rfc-editor.org/rfc/rfc3339) 타임스탬프 (포함)
|
||||
`untilTime` | 로그를 표시할 때까지의 [RFC3339](https://www.rfc-editor.org/rfc/rfc3339) 타임스탬프 (포함)
|
||||
`tailLines` | 로그 끝에서 몇 줄을 검색할지 지정한다. 기본값은 전체 로그를 가져오는 것이다.
|
||||
|
||||
다음은 복잡한 쿼리의 예시이다.
|
||||
```shell
|
||||
# node-1.example 노드에서 단어 "error"가 포함되어 있는 로그를 가져온다.
|
||||
kubectl get --raw "/api/v1/nodes/node-1.example/proxy/logs/?query=kubelet&pattern=error"
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [쿠버네티스 로깅 아키텍처](/ko/docs/concepts/cluster-administration/logging/) 알아보기
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ weight: 90
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.27" state="beta" >}}
|
||||
|
||||
시스템 컴포넌트 추적은 클러스터 내에서 수행된 동작들 간의 지연(latency)과 관계(relationship)를 기록한다.
|
||||
|
||||
|
|
@ -59,14 +59,12 @@ kube-apiserver는 자주 퍼블릭 엔드포인트로 이용되기 때문에,
|
|||
|
||||
#### kube-apiserver 에서의 추적 활성화
|
||||
|
||||
추적을 활성화하기 위해서는, kube-apiserve에서 `APIServerTracing`
|
||||
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화한다.
|
||||
또한, kube-apiserver의 추적 설정 파일에
|
||||
`--tracing-config-file=<path-to-config>`을 추가한다.
|
||||
추적을 활성화하기 위해서는, kube-apiserver의 추적 설정 파일에
|
||||
`--tracing-config-file=<path-to-config>`을 추가한다.
|
||||
다음은 10000개 요청 당 1개에 대한 span을 기록하는 설정에 대한 예시이고, 이는 기본 OpenTelemetry 엔드포인트를 이용한다.
|
||||
|
||||
```yaml
|
||||
apiVersion: apiserver.config.k8s.io/v1alpha1
|
||||
apiVersion: apiserver.config.k8s.io/v1beta1
|
||||
kind: TracingConfiguration
|
||||
# 기본값
|
||||
#endpoint: localhost:4317
|
||||
|
|
@ -74,11 +72,11 @@ samplingRatePerMillion: 100
|
|||
```
|
||||
|
||||
`TracingConfiguration` 구조체에 대해 더 많은 정보를 얻고 싶다면
|
||||
[API server config API (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/#apiserver-k8s-io-v1alpha1-TracingConfiguration)를 참고한다.
|
||||
[API server config API (v1beta1)](/docs/reference/config-api/apiserver-config.v1beta1/#apiserver-k8s-io-v1beta1-TracingConfiguration)를 참고한다.
|
||||
|
||||
### kubelet 추적
|
||||
|
||||
{{< feature-state for_k8s_version="v1.25" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.27" state="beta" >}}
|
||||
|
||||
kubelet CRI 인터페이스와 인증된 http 서버는 추적(trace) 스팬(span)을 생성하도록 설정 할수 있다.
|
||||
apiserver와 마찬가지로 해당 엔드포인트 및 샘플링률을 구성할 수 있다.
|
||||
|
|
@ -88,11 +86,8 @@ apiserver와 마찬가지로 해당 엔드포인트 및 샘플링률을 구성
|
|||
|
||||
#### kubelet tracing 활성화
|
||||
|
||||
추적을 활성화하려면 kubelet에서 `KubeletTracing`
|
||||
[기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)을 활성화한다.
|
||||
또한 kubelet에서
|
||||
[tracing configuration](https://github.com/kubernetes/component-base/blob/release-1.25/tracing/api/v1/types.go)을 제공한다.
|
||||
[tracing 구성](https://github.com/kubernetes/component-base/blob/release-1.25/tracing/api/v1/types.go)을 참조한다.
|
||||
추적을 활성화하려면,
|
||||
[tracing 구성](https://github.com/kubernetes/component-base/blob/release-1.25/tracing/api/v1/types.go)을 적용한다.
|
||||
다음은 10000개 요청 중 1개에 대하여 스팬(span)을 기록하고, 기본 OpenTelemetry 앤드포인트를 사용하도록 한 kubelet 구성 예시이다.
|
||||
|
||||
```yaml
|
||||
|
|
@ -106,6 +101,13 @@ tracing:
|
|||
samplingRatePerMillion: 100
|
||||
```
|
||||
|
||||
만약 `samplingRatePerMillion`이 100만 (`1000000`)으로 설정되어 있으면, 모든 스팬이 exporter로 전송될 것이다.
|
||||
|
||||
쿠버네티스 v{{< skew currentVersion >}}의 kubelet은 가비지 콜렉팅, 파드 동기화 루틴, 그리고 모든 gRPC 메서드에서 스팬을 수집한다.
|
||||
CRI-O 및 containerd와 같은 연결된 컨테이너 런타임은 추적을 export한 스팬에 연결하여 추가 정보 컨텍스트를 제공할 수 있다.
|
||||
|
||||
스팬을 export하면 시스템의 전체 구성에 따라 네트워킹 및 CPU 측에서 항상 약간의 성능 오버헤드가 발생한다는 점에 유의하자. 추적을 활성화한 상태에서 실행 중인 클러스터에서 이와 같은 문제가 발생하면, `samplingRatePerMillion`을 줄이거나 구성을 제거하여 추적을 완전히 비활성화하여 문제를 완화시킨다.
|
||||
|
||||
## 안정성
|
||||
|
||||
추적의 계측화(tracing instrumentation)는 여전히 활발히 개발되는 중이어서 다양한 형태로 변경될 수 있다.
|
||||
|
|
|
|||
Loading…
Reference in New Issue