Second Korean l10n work for release-1.14 (#13970)
* Update outdated files in dev-1.14-ko.2 partly (#13879) * Update outdated files in dev-1.14-ko.2 partly-concepts-contribute-ref (#13890) * ko: update dev-1.14-ko.2 for docs/tutorials/configuration/configure-redis-using-configmap.md #13738 (#13891) * Ko trans: translate contribute/participating.md in Korean (#13812) * Update outdated files of setup and tasks in dev-1.14-ko.2 partly (#13893) * ko-trans: Fix typo in install-minikube (#13894) * ko: Add tutorials/stateful-application/zookeeper #12452 (#13523) * ko: Add tutorials/services/source-ip #12457 (#13524) Co-authored-by: Yoon <learder@gmail.com> Co-authored-by: June Yi <june.yi@samsung.com> Co-authored-by: Seokho <shsongist@gmail.com>
This commit is contained in:
Claudia J.Kang
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
81f251b16f
commit
d831aa23ac
@@ -8,7 +8,7 @@ cid: home
|
||||
|
||||
{{< blocks/section id="oceanNodes" >}}
|
||||
{{% blocks/feature image="flower" %}}
|
||||
### [쿠버네티스 (K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}})는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다.
|
||||
### [쿠버네티스(K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}})는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다.
|
||||
|
||||
애플리케이션을 구성하는 컨테이너들의 쉬운 관리 및 발견을 위해서 컨테이너들을 논리적인 단위로 그룹화합니다. 쿠버네티스는 [Google에서 15년간 프로덕션 워크로드 운영한 경험](http://queue.acm.org/detail.cfm?id=2898444)을 토대로 구축되었으며, 커뮤니티에서 제공한 최상의 아이디어와 방법들이 결합되어 있습니다.
|
||||
{{% /blocks/feature %}}
|
||||
|
||||
@@ -6,10 +6,7 @@ case_study_styles: true
|
||||
cid: caseStudies
|
||||
css: /css/style_case_studies.css
|
||||
logo: ibm_featured_logo.svg
|
||||
featured: true
|
||||
weight: 2
|
||||
quote: >
|
||||
We see CNCF as a safe haven for cloud native open source, providing stability, longevity, and expected maintenance for member projects—no matter the originating vendor or project.
|
||||
featured: false
|
||||
---
|
||||
|
||||
<div class="banner1" style="background-image: url('/images/CaseStudy_ibm_banner1.jpg')">
|
||||
@@ -34,7 +31,7 @@ quote: >
|
||||
</div>
|
||||
|
||||
<div class="col2" style="width:95%">
|
||||
|
||||
|
||||
|
||||
<h2>Impact</h2>
|
||||
IBM's intention in offering a managed Kubernetes container service and image registry is to provide a fully secure end-to-end platform for its enterprise customers. "Image signing is one key part of that offering, and our container registry team saw Notary as the de facto way to implement that capability in the current Docker and container ecosystem," Hough says. The company had not been offering image signing before, and Notary is the tool it used to implement that capability. "We had a multi-tenant Docker Registry with private image hosting," Hough says. "The Docker Registry uses hashes to ensure that image content is correct, and data is encrypted both in flight and at rest. But it does not provide any guarantees of who pushed an image. We used Notary to enable users to sign images in their private registry namespaces if they so choose."
|
||||
|
||||
@@ -6,10 +6,7 @@ case_study_styles: true
|
||||
cid: caseStudies
|
||||
css: /css/style_case_studies.css
|
||||
logo: naic_featured_logo.png
|
||||
featured: true
|
||||
weight: 3
|
||||
quote: >
|
||||
Our culture and technology transition is a strategy embraced by our top leaders. It has already proven successful by allowing us to accelerate our value pipeline by more than double while decreasing our costs by more than half.
|
||||
featured: false
|
||||
---
|
||||
|
||||
<div class="banner1" style="background-image: url('/images/CaseStudy_naic_banner1.jpg')">
|
||||
@@ -36,7 +33,7 @@ quote: >
|
||||
</div>
|
||||
|
||||
<div class="col2">
|
||||
|
||||
|
||||
|
||||
<h2>Impact</h2>
|
||||
Leveraging Kubernetes, "our development teams can create rapid prototypes far faster than they used to," Barker said. Applications running on Kubernetes are more resilient than those running in other environments. The deployment of open source solutions is helping influence company culture, as NAIC becomes a more open and transparent organization.
|
||||
@@ -57,7 +54,7 @@ quote: >
|
||||
<div class="fullcol">
|
||||
NAIC—which was created and overseen by the chief insurance regulators from the 50 states, the District of Columbia and five U.S. territories—provides a means through which state insurance regulators establish standards and best practices, conduct peer reviews, and coordinate their regulatory oversight. Their staff supports these efforts and represents the collective views of regulators in the United States and internationally. NAIC members, together with the organization’s central resources, form the national system of state-based insurance regulation in the United States.<br><br>
|
||||
The organization has been using the cloud for years, and wanted to find more ways to quickly deliver new services that provide more value for members and staff. They looked to Kubernetes for a solution. Within NAIC, several groups are leveraging Kubernetes, one being the Platform Engineering Team. "The team building out these tools are not only deploying and operating Kubernetes, but they’re also using them," Barker says. "In fact, we’re using GitLab to deploy Kubernetes with a pipeline using <a href="https://github.com/kubernetes/kops">kops</a>. This team was created from developers, operators, and quality engineers from across the company, so their jobs have changed quite a bit."<br><br>
|
||||
In addition, NAIC is onboarding teams to the new platform, and those teams have seen a lot of change in how they work and what they can do. "They now have more power in creating their own infrastructure and deploying their own applications," Barker says. They also use pipelines to facilitate their currently manual processes. NAIC has consumers who are using GitLab heavily, and they’re starting to use Kubernetes to deploy simple applications that help their internal processes.
|
||||
In addition, NAIC is onboarding teams to the new platform, and those teams have seen a lot of change in how they work and what they can do. "They now have more power in creating their own infrastructure and deploying their own applications," Barker says. They also use pipelines to facilitate their currently manual processes. NAIC has consumers who are using GitLab heavily, and they’re starting to use Kubernetes to deploy simple applications that help their internal processes.
|
||||
|
||||
|
||||
</div>
|
||||
@@ -71,7 +68,7 @@ In addition, NAIC is onboarding teams to the new platform, and those teams have
|
||||
<div class="fullcol">
|
||||
"We needed greater agility to enable our own productivity internally," he says. "We decided it was right for us to move everything to the public cloud [Amazon Web Services] to help with that process and be able to access many of the native tools that allows us to move faster by not needing to build everything."
|
||||
The NAIC also wanted to be cloud-agnostic, "and Kubernetes helps with this for our compute layer," Barker says. "Compute is pretty standard across the clouds, and now we can take advantage of any of them while getting all of the other features Kubernetes offers."<br><br>
|
||||
The NAIC currently hosts internal systems and development systems on Kubernetes, and has already seen how impactful it can be. "Our development teams can create rapid prototypes in minutes instead of weeks," Barker says. "This recently happened with an internal tool that had no measurable wait time on the infrastructure. It was solely development bound. There is now a central shared resource that lives in AWS, which means it can grow as needed."
|
||||
The NAIC currently hosts internal systems and development systems on Kubernetes, and has already seen how impactful it can be. "Our development teams can create rapid prototypes in minutes instead of weeks," Barker says. "This recently happened with an internal tool that had no measurable wait time on the infrastructure. It was solely development bound. There is now a central shared resource that lives in AWS, which means it can grow as needed."
|
||||
The native integrations into Kubernetes at NAIC has made it easy to write code and have it running in minutes instead of weeks. Applications running on Kubernetes have also proven to be more resilient than those running in other environments. "We even have teams using this to create more internal tools to help with communication or automating some of their current tasks," Barker says.
|
||||
<br><br>
|
||||
"We knew that Kubernetes had become the de facto standard for container orchestration," he says. "Two major factors for selecting this were the three major cloud vendors hosting their own versions and having it hosted in a neutral party as fully open source."
|
||||
@@ -89,7 +86,7 @@ As for other CNCF projects, NAIC is using Prometheus on a small scale and hopes
|
||||
|
||||
<section class="section5" style="padding:0px !important">
|
||||
<div class="fullcol">
|
||||
|
||||
|
||||
The open governance and broad industry participation in CNCF provided a comfort level with the technology, Barker says. "We also see it as helping to influence our own company culture," he says. "We’re moving to be a more open and transparent company, and we are encouraging our staff to get involved with the different working groups and codebases. We recently became CNCF members to help further our commitment to community contribution and transparency."<br><br>
|
||||
Factors such as vendor-neutrality and cross-industry investment were important in the selection. "In our experience, vendor lock-in and tooling that is highly specific results in less resilient technology with fewer minds working to solve problems and grow the community," Barker says.<br><br>
|
||||
NAIC is a largely Oracle shop, Barker says, and has been running mostly Java on JBoss. "However, we have years of history with other applications," he says. "Some of these have been migrated by completely rewriting the application, while others are just being modified slightly to fit into this new paradigm."<br><br>
|
||||
@@ -106,7 +103,7 @@ All of its databases are currently running within public cloud services, but the
|
||||
</div>
|
||||
</div>
|
||||
<div class="fullcol">
|
||||
|
||||
|
||||
NAIC has seen a significant business impact from its efforts. "We have been able to move much faster at lower cost than we were able to in the past," Barker says. "We were able to complete one of our projects in a year, when the previous version took over two years. And the new project cost $500,000 while the original required $3 million, and with fewer defects. We are also able to push out new features much faster."
|
||||
He says the organization is moving toward continuous deployment "because the business case makes sense. The research is becoming very hard to argue with. We want to reduce our batch sizes and optimize on delivering value to customers and not feature count. This is requiring a larger cultural shift than just a technology shift."
|
||||
NAIC is "becoming more open and transparent, as well as more resilient to failure," Barker says. "Even our customers are wanting more and more of this and trying to figure out how they can work with us to accomplish our mutual goals faster. Members of the insurance industry have reached out so that we can better learn together and grow as an industry."
|
||||
|
||||
@@ -45,8 +45,8 @@ quote: >
|
||||
|
||||
</section>
|
||||
<div class="banner2" style="text-align:center">
|
||||
<iframe width="500" height="260" src="https://www.youtube.com/embed/I36NNJH1xQY" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
<div class="banner2text"><br><br>
|
||||
<iframe width="500" height="260" src="https://www.youtube.com/embed/I36NNJH1xQY" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
<div class="banner2text"><br><br>
|
||||
"So far it’s been good, especially the elasticity around how we can configure our Jenkins workloads on that Kubernetes shared cluster. That is the win we were pushing for." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Micheal Benedict, Product Manager for the Cloud and the Data Infrastructure Group at Pinterest</span>
|
||||
|
||||
</div>
|
||||
|
||||
@@ -6,7 +6,7 @@ weight: 70
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="1.12" >}}
|
||||
{{< feature-state for_k8s_version="1.14" state="beta" >}}
|
||||
|
||||
Kube-scheduler는 쿠버네티스의 기본 스케줄러이다. 그것은 클러스터의
|
||||
노드에 파드를 배치하는 역할을 한다. 파드의 스케줄링 요건을 충족하는
|
||||
@@ -24,16 +24,24 @@ API 서버에 해당 결정을 통지한다.
|
||||
|
||||
쿠버네티스 1.12 이전 버전에서, Kube-scheduler는 클러스터의 모든 노드에
|
||||
대한 적합성(feasibility)을 확인한 후에 적합한 노드들에 대해서 점수를 측정했다.
|
||||
쿠버네티스 1.12는 새로운 특징을 가지고 있으며, 이 특징은 스케줄러가 특정
|
||||
쿠버네티스 1.12는 새로운 특징을 추가했으며, 이 특징은 스케줄러가 특정
|
||||
숫자의 적합한 노드를 찾은 이후에 추가적인 적합 노드를 찾는 것을 중단하게 한다.
|
||||
이것은 대규모 클러스터에서 스케줄러 성능을 향상시킨다. 해당 숫자는 클러스터
|
||||
크기에 대한 비율로 지정되며 `percentageOfNodesToScore` 구성 옵션으로
|
||||
제어된다. 값의 범위는 1과 100 사이여야 한다. 그 이외의 값은 100%로 간주한다.
|
||||
이 옵션의 기본 값은 50%이다. 클러스터 관리자는 이 값은 스케줄러 구성에 다른
|
||||
값을 지정함으로써 기본 값을 변경할 수 있다. 그러나, 이 값을 변경할 필요는 없을 것이다.
|
||||
크기에 대한 비율로 지정된다. 그 비율은 `percentageOfNodesToScore` 구성
|
||||
옵션으로 제어될 수 있다. 값의 범위는 1과 100 사이여야 한다. 더 높은 값은
|
||||
100%로 간주된다. 0은 구성 옵션을 제공하지 않는 것과 동일하다.
|
||||
점수를 측정할 노드의 비율이 구성 옵션에 명시되지 않은 경우를 대비하여, 쿠버네티스 1.14는
|
||||
클러스터의 크기에 기반하여 해당 비율 값을 찾는 로직을 가지고 있다. 이 로직은
|
||||
100-노드 클러스터에 대해 50%를 값으로 출력하는 선형 공식을 사용한다. 해당 공식은 5000-노드
|
||||
클러스터에 대해서는 10%를 값으로 출력한다. 자동으로 지정되는 값의 하한값은 5%이다. 다시
|
||||
말해, 사용자가 구성 옵션에 5 보다 낮은 값은 지정하지 않은 한, 스케줄러는
|
||||
클러스터의 크기와 무관하게 적어도 5%의 클러스터에 대해서는 항상 점수를
|
||||
측정한다.
|
||||
|
||||
아래는 `percentageOfNodesToScore`를 50%로 설정하는 구성 예제이다.
|
||||
|
||||
```yaml
|
||||
apiVersion: componentconfig/v1alpha1
|
||||
apiVersion: kubescheduler.config.k8s.io/v1alpha1
|
||||
kind: KubeSchedulerConfiguration
|
||||
algorithmSource:
|
||||
provider: DefaultProvider
|
||||
@@ -43,40 +51,36 @@ algorithmSource:
|
||||
percentageOfNodesToScore: 50
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
클러스터에서 적합한 노드가 0 또는 50 미만인 경우,
|
||||
스케줄러는 여전히 모든 노드를 확인한다. 이는 스케줄러가 탐색을 조기
|
||||
중단하기에는 적합한 노드의 수가 충분하지 않기 때문이다.
|
||||
{{< /note >}}
|
||||
{{< note >}} 클러스터에서 적합한 노드가 50 미만인 경우, 스케줄러는 여전히
|
||||
모든 노드를 확인한다. 그 이유는 스케줄러가 탐색을 조기 중단하기에는 적합한
|
||||
노드의 수가 충분하지 않기 때문이다. {{< /note >}}
|
||||
|
||||
**이 특징을 비활성화하려면**, `percentageOfNodesToScore`를 100으로 지정한다.
|
||||
|
||||
### percentageOfNodesToScore 튜닝
|
||||
|
||||
`percentageOfNodesToScore`는 1과 100 사이의 값이어야하며
|
||||
기본 값은 50이다. 또한 50%의 노드로 하드 코딩된 최소 값이 내부적으로
|
||||
적용된다. 스케줄러는 `percentageOfNodesToScore` 값과 상관없이
|
||||
적어도 50%의 노드 탐색을 수행한다. 이는 수백 개 정도의 노드가 있는
|
||||
기본 값은 클러스터 크기에 따라 계산된다. 또한 50 노드로 하드 코딩된
|
||||
최소 값도 있다. 이는 수백 개 정도의 노드가 있는
|
||||
클러스터에서는 해당 옵션을 더 낮은 값으로 변경하더라도 스케줄러가
|
||||
찾으려는 적합한 노드의 개수에는 크게 영향을 주지 않는다는
|
||||
뜻이다. 이것은 규모가 작은 클러스터에서는 이 옵션의 조정이 성능을
|
||||
눈에 띄게 향상시키지 않는 것을 감안하여 의도적으로 설계되었다. 1000 노드
|
||||
이상의 큰 규모의 클러스터에서는 이 값을 낮은 수로 설정하면 눈에 띄는 성능
|
||||
향상을 보일 수도 있다.
|
||||
찾으려는 적합한 노드의 개수에는 크게 영향을 주지 않는다는 뜻이다.
|
||||
이것은 규모가 작은 클러스터에서는 이 옵션의 조정이 성능을 눈에 띄게 향상시키지 않는
|
||||
것을 감안하여 의도적으로 설계되었다. 1000 노드 이상의 큰 규모의 클러스터에서는 이 값을
|
||||
낮은 수로 설정하면 눈에 띄는 성능 향상을 보일 수도 있다.
|
||||
|
||||
이 값을 세팅할 때 중요하게 고려해야 할 사항은, 클러스터에서
|
||||
적은 수의 노드에 대해서만 적합성을 확인하면, 주어진 파드에 대해서
|
||||
일부 노드의 점수는 측정이되지 않는다는 것이다. 결과적으로, 주어진 파드를 실행하는데
|
||||
가장 높은 점수를 가질 가능성이 있는 노드가 점수 측정 단계로 조차 넘어가지
|
||||
않을 수 있다. 이것은 파드의 이상적인 배치보다 낮은 결과를 초래할 것이다.
|
||||
그 이유로, 이 값은 너무 낮은 비율로 설정되면 안 된다. 대략의 경험적 법칙은 30 이하의
|
||||
그 이유로, 이 값은 너무 낮은 비율로 설정되면 안 된다. 대략의 경험적 법칙은 10 이하의
|
||||
값으로는 설정하지 않는 것이다. 더 낮은 값은 사용자의 애플리케이션에서 스케줄러의
|
||||
처리량이 치명적이고 노드의 점수가 중요하지 않을 경우에만 사용해야 한다. 다시 말해서, 파드의
|
||||
실행에 적합하기만 하다면 어느 노드가 선택되어도 사용자에게 상관없는 경우를 말한다.
|
||||
|
||||
만약 사용자의 클러스터가 단지 백여 개의 노드를 가지고 있는 경우 기본 값보다 낮은 값으로의
|
||||
변경을 추천하지 않는다. 그것은 스케줄러의 성능을
|
||||
크게 향상시키지 않을 것이다.
|
||||
만약 사용자의 클러스터가 단지 백여 개 또는 더 적은 노드를 가지고 있는 경우, 이 구성 옵션의
|
||||
기본 값보다 낮은 값으로의 변경을 추천하지 않는다. 그것이 스케줄러의 성능을 크게
|
||||
향상시키지는 않을 것이다.
|
||||
|
||||
### 스케줄러가 노드 탐색을 반복(iterate)하는 방법
|
||||
|
||||
|
||||
@@ -202,7 +202,7 @@ Docker는 프라이빗 레지스트리를 위한 키를 `$HOME/.dockercfg` 또
|
||||
프라이빗 이미지를 사용하는 파드를 생성하여 검증한다. 예를 들면 다음과 같다.
|
||||
|
||||
```yaml
|
||||
kubectl create -f - <<EOF
|
||||
kubectl apply -f - <<EOF
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
@@ -275,8 +275,19 @@ GCE 및 자동 노드 교체를 수행하는 다른 클라우드 제공자에
|
||||
대문자 값을 적절히 대체하여, 다음 커맨드를 실행한다.
|
||||
|
||||
```shell
|
||||
kubectl create secret docker-registry myregistrykey --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
|
||||
secret/myregistrykey created.
|
||||
cat <<EOF > ./kustomization.yaml
|
||||
secretGenerator:
|
||||
- name: myregistrykey
|
||||
type: docker-registry
|
||||
literals:
|
||||
- docker-server=DOCKER_REGISTRY_SERVER
|
||||
- docker-username=DOCKER_USER
|
||||
- docker-password=DOCKER_PASSWORD
|
||||
- docker-email=DOCKER_EMAIL
|
||||
EOF
|
||||
|
||||
kubectl apply -k .
|
||||
secret/myregistrykey-66h7d4d986 created
|
||||
```
|
||||
|
||||
만약 Docer 자격 증명 파일이 이미 존재한다면, 위의 명령을 사용하지 않고,
|
||||
@@ -296,7 +307,8 @@ secret/myregistrykey created.
|
||||
이제, `imagePullSecrets` 섹션을 파드의 정의에 추가함으로써 해당 시크릿을
|
||||
참조하는 파드를 생성할 수 있다.
|
||||
|
||||
```yaml
|
||||
```shell
|
||||
cat <<EOF > pod.yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
@@ -308,6 +320,12 @@ spec:
|
||||
image: janedoe/awesomeapp:v1
|
||||
imagePullSecrets:
|
||||
- name: myregistrykey
|
||||
EOF
|
||||
|
||||
cat <<EOF >> ./kustomization.yaml
|
||||
resources:
|
||||
- pod.yaml
|
||||
EOF
|
||||
```
|
||||
|
||||
이것은 프라이빗 레지스트리를 사용하는 각 파드에 대해서 수행될 필요가 있다.
|
||||
|
||||
@@ -107,3 +107,5 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드
|
||||
[클러스터-레벨 로깅](/docs/concepts/cluster-administration/logging/) 메커니즘은 검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 가진다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/referenc
|
||||
|
||||
경험에 따르면, 성공적인 시스템은 새로운 유스케이스의 등장과 기존의 유스케이스의 변경에 맞춰 성장하고 변경될 필요가 있다. 그래서, 쿠버네티스 API가 지속적으로 변경되고 성장하기를 바란다. 그러나, 일정 기간 동안은 현존하는 클라이언트와의 호환성을 깨지 않으려고 한다. 일반적으로, 새로운 API 리소스와 새로운 리소스 필드가 주기적으로 추가될 것이다. 리소스나 필드를 없애는 일은 다음의 [API deprecation policy](/docs/reference/using-api/deprecation-policy/)를 따른다.
|
||||
|
||||
호환되는 변경에 어떤 내용이 포함되는지, 어떻게 API를 변경하는지에 대한 자세한 내용은 [API change document](https://git.k8s.io/community/contributors/devel/api_changes.md)에 있다.
|
||||
호환되는 변경에 어떤 내용이 포함되는지, 어떻게 API를 변경하는지에 대한 자세한 내용은 [API change document](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md)에 있다.
|
||||
|
||||
## OpenAPI 및 Swagger 정의
|
||||
|
||||
@@ -67,12 +67,12 @@ GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github
|
||||
필드를 없애거나 리소스 표현을 재구성하기 쉽도록, 쿠버네티스는 `/api/v1`이나
|
||||
`/apis/extensions/v1beta1`과 같이 각각 다른 API 경로에서 복수의 API 버전을 지원한다.
|
||||
|
||||
리소스나 필드 수준보다는 API 수준에서 버전을 선택했는데, API가 명료하고, 시스템 리소스와 행위 관점에서 일관성있으며, 더 이상 사용하지 않는 API나 실험적인 API에 접근을 제어할 수 있도록 하기 위함이다. 스키마 변경에 대해서 JSON과 Protobuf 직렬화 스키마 모두 동일한 가이드라인을 따른다. 다음에 이어지는 설명 모두는 이 두 가지 형식에 모두 해당한다.
|
||||
리소스나 필드 수준보다는 API 수준에서 버전을 선택했는데, API가 명료하고, 시스템 리소스와 행위 관점에서 일관성있으며, 더 이상 사용되지 않는 API나 실험적인 API에 접근을 제어할 수 있도록 하기 위함이다. 스키마 변경에 대해서 JSON과 Protobuf 직렬화 스키마 모두 동일한 가이드라인을 따른다. 다음에 이어지는 설명 모두는 이 두 가지 형식에 모두 해당한다.
|
||||
|
||||
API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관되어 있음을 알아두자. [API and release versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는 API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다.
|
||||
|
||||
|
||||
API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르다는 것을 암시한다. 각각의 수준에 대한 조건은 [API Changes documentation](https://git.k8s.io/community/contributors/devel/api_changes.md#alpha-beta-and-stable-versions)에서 상세히 다룬다. 요약하자면 다음과 같다.
|
||||
API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르다는 것을 암시한다. 각각의 수준에 대한 조건은 [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서 상세히 다룬다. 요약하자면 다음과 같다.
|
||||
|
||||
- 알파(Alpha) 수준:
|
||||
- 버전 이름에 `alpha`가 포함된다. (예: `v1alpha1`)
|
||||
|
||||
@@ -7,7 +7,8 @@ weight: 10
|
||||
{{% capture overview %}}
|
||||
`kubectl` 커맨드라인 툴은 쿠버네티스 오브젝트를 생성하고 관리하기 위한
|
||||
몇 가지 상이한 방법을 지원한다. 이 문서는 여러가지 접근법에 대한 개요을
|
||||
제공한다.
|
||||
제공한다. Kubectl으로 오브젝트 관리하기에 대한 자세한 설명은
|
||||
[Kubectl 서적](https://kubectl.docs.kubernetes.io)에서 확인한다.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
@@ -179,6 +180,7 @@ kubectl apply -R -f configs/
|
||||
- [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기 (명령형)](/docs/concepts/overview/object-management-kubectl/imperative-config/)
|
||||
- [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기 (선언형)](/docs/concepts/overview/object-management-kubectl/declarative-config/)
|
||||
- [Kubectl 명령어 참조](/docs/reference/generated/kubectl/kubectl-commands/)
|
||||
- [Kubectl 서적](https://kubectl.docs.kubernetes.io)
|
||||
- [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
||||
|
||||
{{< comment >}}
|
||||
|
||||
@@ -41,7 +41,7 @@ card:
|
||||
|
||||
{{< codenew file="application/deployment.yaml" >}}
|
||||
|
||||
위 예시와 같이 .yaml 파일을 이용하여 디플로이먼트를 생성하기 위한 하나의 방식으로는 `kubectl` 커맨드-라인 인터페이스에 인자값으로 `.yaml` 파일를 건네 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 명령을 이용하는 것이다. 다음 예시와 같다.
|
||||
위 예시와 같이 .yaml 파일을 이용하여 디플로이먼트를 생성하기 위한 하나의 방식으로는 `kubectl` 커맨드-라인 인터페이스에 인자값으로 `.yaml` 파일를 건네 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 커맨드를 이용하는 것이다. 다음 예시와 같다.
|
||||
|
||||
|
||||
```shell
|
||||
|
||||
@@ -183,7 +183,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 두 가지
|
||||
|
||||
## 파드의 준비성 게이트(readiness gate)
|
||||
|
||||
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
|
||||
{{< feature-state for_k8s_version="v1.14" state="stable" >}}
|
||||
|
||||
파드의 준비성에 대한 확장성을 추가하기 위해서
|
||||
추가적인 피드백이나 신호를 `PodStatus`에 주입하는 방법인,
|
||||
|
||||
@@ -106,5 +106,5 @@ spec:
|
||||
{{% capture whatsnext %}}
|
||||
* 파드의 다른 동작들을 더 배워보자.
|
||||
* [파드 종료](/docs/concepts/workloads/pods/pod/#termination-of-pods)
|
||||
* [파드 라이프사이클](../pod-lifecycle)
|
||||
* [파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -47,7 +47,7 @@ weight: 80
|
||||
시작하는 데에 도움이 될 것이다.
|
||||
|
||||
- [누구나](/docs/contribute/start/)
|
||||
- 조치 가능한 버그 리포트 제출
|
||||
- 조치 가능한 이슈 열기
|
||||
- [멤버](/docs/contribute/start/)
|
||||
- 기존 문서 개선
|
||||
- [Slack](http://slack.k8s.io/) 또는 [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에서 개선을 위한 아이디어 제시
|
||||
|
||||
@@ -0,0 +1,263 @@
|
||||
---
|
||||
title: SIG Docs에 참여하기
|
||||
content_template: templates/concept
|
||||
card:
|
||||
name: contribute
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
SIG Docs는 쿠버네티스 프로젝트의
|
||||
[분과회(special interest group)](https://github.com/kubernetes/community/blob/master/sig-list.md)
|
||||
중 하나로, 쿠버네티스 전반에 대한 문서를 작성하고, 업데이트하며 유지보수하는 일을 주로 수행한다.
|
||||
분과회에 대한 보다 자세한 정보는
|
||||
[커뮤니티 GitHub 저장소 내 SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs)
|
||||
를 참조한다.
|
||||
|
||||
SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다. 누구나 풀 리퀘스트(PR)를 요청할 수 있고,
|
||||
누구나 콘텐츠에 대해 이슈를 등록하거나 진행 중인 풀 리퀘스트에 코멘트를 등록할 수 있다.
|
||||
|
||||
SIG Docs 내에서, [멤버](#멤버), [리뷰어](#리뷰어), 또는 [승인자](#승인자)가 될 수도 있다.
|
||||
이런 역할은 변경을 승인하고 커밋할 수 있도록 보다 많은 접근 권한과 이에 상응하는 책임이 수반된다.
|
||||
쿠버네티스 커뮤니티 내에서 멤버십이 운영되는 방식에 대한 보다 많은 정보를 확인하려면
|
||||
[커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md)
|
||||
문서를 확인한다. 문서의 나머지에서는 대외적으로 쿠버네티스를 가장 잘 드러내는 수단 중 하나인 쿠버네티스
|
||||
웹사이트와 문서를 관리하는 책임을 가지는 SIG Docs에서, 이런 체계가 작동하는 특유의 방식에 대한 윤곽을
|
||||
잡아보겠다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 역할과 책임
|
||||
|
||||
풀 리퀘스트가 콘텐츠를 게재하는데 사용되는 브랜치(현재는 `master`)에 머지되면, 해당 콘텐츠가 세상에
|
||||
발행되어 널리 읽힐 수 있게 된다. 발행된 콘텐츠가 높은 품질을 유지하도록, SIG Docs 승인자만
|
||||
풀 리퀘스트를 머지할 수 있도록 제한한다. 다음과 같이 진행된다.
|
||||
|
||||
- 풀 리퀘스트에 `lgtm`과 `approve` 레이블이 부여되고 `hold` 레이블이 없는 경우에, 해당
|
||||
풀 리퀘스트가 자동으로 머지된다.
|
||||
- 쿠버네티스 조직 멤버와 SIG Docs 승인자는 코멘트를 추가해서(`/hold` 코멘트를 추가하거나
|
||||
`/lgtm` 코멘트를 달지 않아서) 주어진 풀 리퀘스트가 자동으로 머지되는 것을 막을 수 있다.
|
||||
- 쿠버네티스 멤버 누구나 `/lgtm` 코멘트를 달아서 `lgtm` 레이블을 추가할 수 있다.
|
||||
- `/approve` 코멘트를 달아서 풀 리퀘스트를 머지할 수 있는 SIG Docs 멤버는 승인자 뿐이다.
|
||||
일부 승인자는 추가로 [PR Wrangler](#pr-wrangler) 또는
|
||||
[SIG Docs chairperson](#sig-docs-chairperson) 같이 특화된 역할을 수행한다.
|
||||
|
||||
쿠버네티스 조직 멤버와 SIG Docs 승인자 역할 사이의 기대와 차이에 대한 보다 많은 정보는
|
||||
[컨트리뷰터 유형](/docs/contribute#types-of-contributor) 문서를 참고한다.
|
||||
다음 섹션에서는 이런 역할과 SIG Docs에서 이들이 작동하는 방식에 대해 보다 상세한 내용을
|
||||
다룬다.
|
||||
|
||||
### 모든 사람
|
||||
|
||||
문서를 포함해서, 쿠버네티스의 모든 부분에 대해서 누구나 이슈를 제기할 수 있다.
|
||||
|
||||
CLA에 서명한 누구나 풀 리퀘스트를 제출할 수 있다. CLA에 서명할 수 없다면,
|
||||
쿠버네티스 프로젝트는 컨트리뷰션을 수용할 수 없다.
|
||||
|
||||
### 멤버
|
||||
|
||||
[쿠버네티스 조직](https://github.com/kubernetes)의 모든 멤버가 풀 리퀘스트를 리뷰할 수 있고,
|
||||
기술적 정확도를 기하기 위해 SIG Docs 팀 멤버가 다른 분과회 멤버의 리뷰를 요청하는 일도 자주
|
||||
발생한다.
|
||||
SIG Docs는 쿠버네티스 조직의 멤버십 상태와 상관없이 보내주는 리뷰와 피드백 또한 환영한다.
|
||||
풀 리퀘스트에 `/lgtm` 코멘트를 달아서 찬성 의사를 표시할 수 있다. 쿠버네티스 조직의 멤버가 아니라면,
|
||||
`/lgtm` 코멘트는 자동화 시스템에 유효하지는 않다.
|
||||
|
||||
쿠버네티스 조직의 모든 멤버는 `/hold` 코멘트를 달아서 풀 리퀘스트가 머지되는 것을 막을 수 있다.
|
||||
또한 모든 멤버가 `/hold` 코멘트를 삭제해서 PR이 머지될 수 있도록 할 수도 있다. 해당 PR이 이미
|
||||
적임자로부터 `/lgtm`과 `/approve`를 받은 경우라면 말이다.
|
||||
|
||||
#### 멤버 되기
|
||||
|
||||
최소 5개의 실질적인 풀 리퀘스트를 성공적으로 제출한 경우, 쿠버네티스 조직의
|
||||
[멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을
|
||||
요청할 수 있다. 다음의 단계를 따른다.
|
||||
|
||||
1. 멤버십을 [후원](/docs/contribute/advanced#sponsor-a-new-contributor)해 줄 두 명의 리뷰어 또는 승인자를
|
||||
찾는다.
|
||||
|
||||
[쿠버네티스 Slack 인스턴스의 #sig-docs 채널](https://kubernetes.slack.com) 또는
|
||||
[SIG Docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에서
|
||||
후원을 요청한다.
|
||||
|
||||
{{< note >}}
|
||||
SIG Docs 멤버 개인에게 직접 email을 보내거나 Slack 다이렉트 메시지를 보내지 않는다.
|
||||
{{< /note >}}
|
||||
|
||||
2. `kubernetes/org` 리포지터리에 멤버십을 요청하는 GitHub 이슈를 등록한다.
|
||||
[커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md)
|
||||
문서의 가이드라인을 따라서 양식을 채운다.
|
||||
|
||||
3. 해당 GitHub 이슈에 후원자를 at-mentioning(`@<GitHub-username>`을 포함한 코멘트를 추가)하거나
|
||||
링크를 직접 보내주어서 후원자가 해당 GitHub 이슈를 확인하고 `+1` 표를 줄 수 있도록 한다.
|
||||
|
||||
4. 멤버십이 승인되면, 요청에 할당된 GitHub 관리자 팀 멤버가 승인되었음을 업데이트해주고 해당 GitHub 이슈를 종료한다.
|
||||
축하한다, 이제 멤버가 되었다!
|
||||
|
||||
어떤 이유에서 멤버십 요청이 즉시 수용되지 않는 경우, 멤버십 위원회에서 재지원 전에 필요한 정보나 단계를 알려준다.
|
||||
|
||||
### 리뷰어
|
||||
|
||||
리뷰어는
|
||||
[@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews)
|
||||
GitHub 그룹의 멤버이다. [SIG Docs의 팀과 그룹](#teams-and-groups-within-sig-docs) 문서를 참고한다.
|
||||
|
||||
리뷰어는 문서 풀 리퀘스트를 리뷰하고 제안받은 변경에 대한 피드백을 제공한다.
|
||||
|
||||
자동화 시스템은 풀 리퀘스트에 대해 리뷰어를 할당하고, 컨트리뷰터는 해당 풀 리퀘스트에
|
||||
`/assign [@_github_handle]` 코멘트를 남겨서 특정 리뷰어에게 리뷰를 요청할 수 있다.
|
||||
풀 리퀘스트가 기술적으로 정확하고 더 변경이 필요하지 않다는 의미로, 리뷰어는 `/lgtm` 코멘트를
|
||||
해당 풀 리퀘스트에 추가할 수 있다.
|
||||
|
||||
할당된 리뷰어가 내용을 아직 리뷰하지 않은 경우, 다른 리뷰어가 나설 수 있다. 추가로, 기술 리뷰어를
|
||||
할당해서 그들이 `/lgtm`을 주기를 기다릴 수도 있다.
|
||||
|
||||
사소한 변경이나 기술적 리뷰가 필요한 PR의 경우, SIG Docs [승인자](#승인자)가 `/lgtm`을 줄
|
||||
수도 있다.
|
||||
|
||||
리뷰어의 `/approve` 코멘트는 자동화 시스템에서 무시된다.
|
||||
|
||||
SIG Docs 리뷰어가 되는 방법과 수반되는 책임과 시간 할애에 대한 보다 많은 정보는
|
||||
[리뷰어나 승인자 되기](#리뷰어나-승인자-되기) 문서를 참조한다.
|
||||
|
||||
#### 리뷰어 되기
|
||||
|
||||
[요건](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer)을
|
||||
충족하면, SIG Docs 리뷰어가 될 수 있다. 다른 SIG의 리뷰어는 SIG Docs의 리뷰어 자격에
|
||||
반드시 별도로 지원해야 한다.
|
||||
|
||||
지원하려면, `kubernetes/website` 저장소의
|
||||
[최상위 OWNERS 파일](https://github.com/kubernetes/website/blob/master/OWNERS)
|
||||
내 `reviewers` 섹션에 자신을 추가하는 풀 리퀘스트를 연다. PR을 한 명 이상의 현재 SIG Docs
|
||||
승인자에게 할당한다.
|
||||
|
||||
풀 리퀘스트가 승인되면, 이제 SIG Docs 리뷰어가 된다.
|
||||
[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이
|
||||
새로운 풀 리퀘스트에 대한 리뷰어로 당신을 추천하게 된다.
|
||||
|
||||
일단 승인되면, 현재 SIG Docs 승인자가
|
||||
[@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews)
|
||||
GitGub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-admins` GitHub 그룹의
|
||||
멤버만이 신규 멤버를 GitHub 그룹에 추가할 수 있다.
|
||||
|
||||
### 승인자
|
||||
|
||||
승인자는
|
||||
[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
|
||||
GitHub 그룹의 멤버이다. [SIG Docs의 팀과 그룹](#teams-and-groups-within-sig-docs) 문서를 참조한다.
|
||||
|
||||
승인자는 PR을 머지할 수 있으므로, 쿠버네티스 웹사이트에 콘텐츠를 게재할 수 있다.
|
||||
PR을 승인하려면, 승인자는 `/approve` 코멘트를 해당 PR에 남긴다. 승인자가 아닌 누군가가 승인
|
||||
코멘트를 남기더라도, 자동화 시스템은 이를 무시한다.
|
||||
|
||||
PR이 이미 `/lgtm`을 받았거나, 승인자가 `/lgtm`을 포함한 코멘트를 남긴 경우에는
|
||||
해당 PR이 자동으로 머지된다. SIG Docs 승인자는 추가적인 기술 리뷰가 필요하지 않은 변경에 대해서만
|
||||
`/lgtm`을 남겨야한다.
|
||||
|
||||
SIG Docs 승인자가 되는 방법과 수반되는 책임과 시간 할애에 대한 보다 많은 정보는
|
||||
[리뷰어나 승인자 되기](#리뷰어나-승인자-되기) 문서를 참조한다.
|
||||
|
||||
#### 승인자 되기
|
||||
|
||||
[요건](https://github.com/kubernetes/community/blob/master/community-membership.md#approver)을
|
||||
충족하면, SIG Docs 승인자가 될 수 있다. 다른 SIG의 승인자는 SIG Docs의 승인자 자격에
|
||||
반드시 별도로 지원해야 한다.
|
||||
|
||||
지원하려면, `kubernetes/website` 저장소의
|
||||
[최상위 OWNERS 파일](https://github.com/kubernetes/website/blob/master/OWNERS)
|
||||
내 `approvers` 섹션에 자신을 추가하는 풀 리퀘스트를 연다. PR을 한 명 이상의 현재 SIG Docs
|
||||
승인자에게 할당한다.
|
||||
|
||||
풀 리퀘스트가 승인되면, 이제 SIG Docs 승인자가 된다.
|
||||
[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이
|
||||
새로운 풀 리퀘스트에 대한 리뷰어로 당신을 추천하게 된다.
|
||||
|
||||
일단 승인되면, 현재 SIG Docs 승인자가
|
||||
[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
|
||||
GitGub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-admins` GitHub 그룹의
|
||||
멤버만이 신규 멤버를 GitHub 그룹에 추가할 수 있다.
|
||||
|
||||
#### 웹사이트 관리자 되기
|
||||
|
||||
`kubernetes-website-admins` GitHub 그룹의 멤버는 GitHub 그룹의 멤버십을 관리할 수 있고
|
||||
리포지터리를 세팅하거나 웹훅(webhook)을 추가, 삭제하고 트러블슈팅하는 것을 포함한 모든 관리 권한을
|
||||
가질 수 있다. 모든 SIG Docs 승인자가 이 수준의 액세스를 할 필요는 없다.
|
||||
|
||||
만약 이 수준의 접근 권한이 필요하다면, 현재 웹사이트 관리자나
|
||||
[쿠버네티스 Slack](https://kubernetes.slack.com) #sig-docs 채널에서 말한다.
|
||||
|
||||
#### PR Wrangler
|
||||
|
||||
SIG Docs 승인자는
|
||||
[PR Wrangler 로테이션 스케줄러](https://github.com/kubernetes/website/wiki/PR-Wranglers)에
|
||||
올라서 주 단위로 돌아가며 역할을 수행한다. 모든 SIG Docs 승인자는 이 로테이션에 참여하게 된다. 보다 자세한 내용은
|
||||
[일주일 간 PR Wrangler 되기](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week)
|
||||
문서를 참고한다.
|
||||
|
||||
#### SIG Docs chairperson
|
||||
|
||||
SIG Docs를 포함한 각 SIG는, 한 명 이상의 SIG 멤버가 의장 역할을 하도록 선정한다. 이들은 SIG Docs와
|
||||
다른 쿠버네티스 조직 간 연락책(point of contact)이 된다. 이들은 쿠버네티스 프로젝트 전반의 조직과
|
||||
그 안에서 SIG Docs가 어떻게 운영되는지에 대한 폭넓은 지식을 갖추어야한다. 현재 의장의 목록을 확인하려면
|
||||
[리더십](https://github.com/kubernetes/community/tree/master/sig-docs#leadership)
|
||||
문서를 참조한다.
|
||||
|
||||
## SIG Docs 팀과 자동화
|
||||
|
||||
SIG Docs의 자동화는 다음의 두 가지 자동화 메커니즘에 의존한다.
|
||||
GitHub 그룹과 OWNERS 파일이다.
|
||||
|
||||
### GitHub 그룹
|
||||
|
||||
GitHub의 SIG Docs 그룹은 두 팀을 정의한다.
|
||||
|
||||
- [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
|
||||
- [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews)
|
||||
|
||||
그룹의 전원과 의사소통하기 위해서 각각 GitHub 코멘트에서 그룹의 `@name`으로 참조할 수 있다.
|
||||
|
||||
이 팀은 중복되지만, 정확히 일치하지는 않으며, 이 그룹은 자동화 툴에서 사용된다.
|
||||
이슈, 풀 리퀘스트를 할당하고, PR 승인을 지원하기 위해서 자동화 시스템이 OWNERS 파일의 정보를 활용한다.
|
||||
|
||||
### OWNERS 파일과 전문(front-matter)
|
||||
|
||||
쿠버네티스 프로젝트는 GitHub 이슈와 풀 리퀘스트 자동화와 관련해서 prow라고 부르는 자동화 툴을 사용한다.
|
||||
[쿠버네티스 웹사이트 리포지터리](https://github.com/kubernetes/website)는 다음의 두
|
||||
[prow 플러그인](https://github.com/kubernetes/test-infra/blob/master/prow/plugins.yaml#L210)을
|
||||
사용한다.
|
||||
|
||||
- blunderbuss
|
||||
- approve
|
||||
|
||||
이 두 플러그인은 `kubernetes/website` GitHub 리포지터리 최상위 수준에 있는
|
||||
[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS)와
|
||||
[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES)
|
||||
파일을 사용해서 해당 리포지터리에 대해 prow가 작동하는 방식을 제어한다.
|
||||
|
||||
OWNERS 파일은 SIG Docs 리뷰어와 승인자의 목록을 포함한다. OWNERS 파일은 하위 디렉터리에 있을 수
|
||||
있고, 해당 하위 디렉터리와 그 이하의 파일에 대해 리뷰어와 승인자 역할을 수행할 사람을 새로 지정할 수 있다.
|
||||
일반적인 OWNERS 파일에 대한 보다 많은 정보는
|
||||
[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md)
|
||||
문서를 참고한다.
|
||||
|
||||
추가로, 개별 마크다운(Markdown) 파일 내 전문에 리뷰어와 승인자를 개별 GitHub 사용자 이름이나 GitHub
|
||||
그룹으로 열거할 수 있다.
|
||||
|
||||
OWNERS 파일과 마크다운 파일 내 전문의 조합은 자동화 시스템이 누구에게 기술적, 편집적 리뷰를 요청해야 할지를
|
||||
PR 소유자에게 조언하는데 활용된다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
쿠버네티스 문서화에 기여하는 일에 대한 보다 많은 정보는 다음 문서를 참고한다.
|
||||
|
||||
- [기여 시작하기](/docs/contribute/start/)
|
||||
- [문서 스타일](/docs/contribute/style/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -16,29 +16,29 @@ content_template: templates/concept
|
||||
|
||||
## API 레퍼런스
|
||||
|
||||
* [Kubernetes API Overview](/docs/reference/using-api/api-overview/) - 쿠버네티스 API에 대한 개요
|
||||
* [쿠버네티스 API 개요](/docs/reference/using-api/api-overview/) - 쿠버네티스 API에 대한 개요
|
||||
* 쿠버네티스 API 버전
|
||||
* [1.14](/docs/reference/generated/kubernetes-api/v1.14/)
|
||||
* [1.13](/docs/reference/generated/kubernetes-api/v1.13/)
|
||||
* [1.12](/docs/reference/generated/kubernetes-api/v1.12/)
|
||||
* [1.11](/docs/reference/generated/kubernetes-api/v1.11/)
|
||||
* [1.10](https://v1-10.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/)
|
||||
* [1.9](https://v1-9.docs.kubernetes.io/docs/api-reference/v1.9/)
|
||||
* [1.10](/docs/reference/generated/kubernetes-api/v1.10/)
|
||||
|
||||
## API 클라이언트 라이브러리
|
||||
|
||||
프로그래밍 언어에서 쿠버네티스 API를 호출하기 위해서,
|
||||
[client libraries](/docs/reference/using-api/client-libraries/)를 사용할 수 있다.
|
||||
[클라이언트 라이브러리](/docs/reference/using-api/client-libraries/)를 사용할 수 있다.
|
||||
공식적으로 지원되는 클라이언트 라이브러리는 다음과 같다.
|
||||
|
||||
- [Kubernetes Go client library](https://github.com/kubernetes/client-go/)
|
||||
- [Kubernetes Python client library](https://github.com/kubernetes-client/python)
|
||||
- [Kubernetes Java client library](https://github.com/kubernetes-client/java)
|
||||
- [Kubernetes JavaScript client library](https://github.com/kubernetes-client/javascript)
|
||||
- [쿠버네티스 Go 클라이언트 라이브러리](https://github.com/kubernetes/client-go/)
|
||||
- [쿠버네티스 Python 클라이언트 라이브러리](https://github.com/kubernetes-client/python)
|
||||
- [쿠버네티스 Java 클라이언트 라이브러리](https://github.com/kubernetes-client/java)
|
||||
- [쿠버네티스 JavaScript 클라이언트 라이브러리](https://github.com/kubernetes-client/javascript)
|
||||
|
||||
## CLI 레퍼런스
|
||||
|
||||
* [kubectl](/docs/user-guide/kubectl-overview) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구.
|
||||
* [JSONPath](/docs/user-guide/jsonpath/) - kubectl에서 [JSONPath expressions](http://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드.
|
||||
* [JSONPath](/docs/user-guide/jsonpath/) - kubectl에서 [JSONPath 표현](http://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드.
|
||||
* [kubeadm](/docs/admin/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구.
|
||||
* [kubefed](/docs/admin/kubefed/) - 연합된(federated) 클러스터 관리를 도와주는 CLI 도구.
|
||||
|
||||
@@ -54,6 +54,6 @@ content_template: templates/concept
|
||||
|
||||
## 설계 문서
|
||||
|
||||
쿠버네티스 기능에 대한 설계 문서의 아카이브. [Kubernetes Architecture](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md)와 [Kubernetes Design Overview](https://git.k8s.io/community/contributors/design-proposals)가 좋은 출발점이다.
|
||||
쿠버네티스 기능에 대한 설계 문서의 아카이브. [쿠버네티스 아키텍처](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md)와 [쿠버네티스 디자인 개요](https://git.k8s.io/community/contributors/design-proposals)가 좋은 출발점이다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -4,14 +4,14 @@ id: taint
|
||||
date: 2019-01-11
|
||||
full_link: /docs/concepts/configuration/taint-and-toleration/
|
||||
short_description: >
|
||||
파드가 노드나 노드 그룹에 스케줄링되는 것을 방지하는 키-값 쌍 및 효과이다.
|
||||
세 가지 필수 속성: 키(key), 값(value), 효과(effect)로 구성된 코어 오브젝트. 테인트는 파드가 노드나 노드 그룹에 스케줄링되는 것을 방지한다.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
- fundamental
|
||||
---
|
||||
파드가 노드나 노드 그룹에 스케줄링되는 것을 방지하는 키-값 쌍 및 효과이다.
|
||||
세 가지 필수 속성: 키(key), 값(value), 효과(effect)로 구성된 코어 오브젝트. 테인트는 파드가 노드나 노드 그룹에 스케줄링되는 것을 방지한다.
|
||||
|
||||
<!--more-->
|
||||
|
||||
|
||||
@@ -4,15 +4,15 @@ id: toleration
|
||||
date: 2019-01-11
|
||||
full_link: /docs/concepts/configuration/taint-and-toleration/
|
||||
short_description: >
|
||||
매칭되는 테인트(taint)를 가진 노드나 노드 그룹에 파드가 스케줄링되는 것을 활성화하는 키-값 쌍 및 효과이다.
|
||||
세 가지 필수 속성: 키(key), 값(value), 효과(effect)로 구성된 코어 오브젝트. 톨러레이션은 매칭되는 테인트(taint)를 가진 노드나 노드 그룹에 파드가 스케줄링되는 것을 활성화한다.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
- fundamental
|
||||
---
|
||||
매칭되는 {{< glossary_tooltip text="테인트(taint)" term_id="taint" >}}를 가진 노드나 노드 그룹에 파드가 스케줄링되는 것을 활성화하는 키-값 쌍 및 효과이다.
|
||||
세 가지 필수 속성: 키(key), 값(value), 효과(effect)로 구성된 코어 오브젝트. 톨러레이션은 매칭되는 {{< glossary_tooltip text="테인트(taints)" term_id="taint" >}}를 가진 노드나 노드 그룹에 파드가 스케줄링되는 것을 활성화한다.
|
||||
|
||||
<!--more-->
|
||||
|
||||
톨러레이션 및 {{< glossary_tooltip text="테인트" term_id="taint" >}}는 함께 작동하며, 파드가 적절하지 못한 노드에 스케줄되는 것을 방지한다. 하나 이상의 톨러레이션이 {{< glossary_tooltip text="파드" term_id="pod" >}}에 적용될 수 있으며, 이것은 매칭되는 {{< glossary_tooltip text="테인트" term_id="taint" >}}를 가진 노드나 노드 그룹에 파드가 스케줄링되는 것을 허용(그러나 필수는 아님)하도록 표시한다.
|
||||
톨러레이션 및 {{< glossary_tooltip text="테인트" term_id="taint" >}}는 함께 작동하며, 파드가 적절하지 못한 노드에 스케줄되는 것을 방지한다. 하나 이상의 톨러레이션이 {{< glossary_tooltip text="파드" term_id="pod" >}}에 적용될 수 있다. 톨러레이션은 매칭되는 {{< glossary_tooltip text="테인트" term_id="taint" >}}를 가진 노드나 노드 그룹에 {{< glossary_tooltip text="파드" term_id="pod" >}}가 스케줄링되는 것을 허용(그러나 필수는 아님)하도록 표시한다.
|
||||
|
||||
@@ -62,12 +62,16 @@ KUBECONFIG=~/.kube/config:~/.kube/kubconfig2 kubectl config view
|
||||
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'
|
||||
|
||||
kubectl config view -o jsonpath='{.users[].name}' # 사용자 리스트 조회
|
||||
kubectl config current-context # 현재 컨텍스트 확인
|
||||
kubectl config get-contexts # 컨텍스트 리스트 출력
|
||||
kubectl config current-context # 현재 컨텍스트 출력
|
||||
kubectl config use-context my-cluster-name # my-cluster-name를 기본 컨텍스트로 설정
|
||||
|
||||
# 기본 인증을 지원하는 새로운 클러스터를 kubeconf에 추가한다
|
||||
kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword
|
||||
|
||||
# 해당 컨텍스트에서 모든 후속 kubectl 커맨드에 대한 네임스페이스를 영구적으로 저장한다
|
||||
kubectl config set-context --current --namespace=ggckad-s2
|
||||
|
||||
# 특정 사용자와 네임스페이스를 사용하는 컨텍스트 설정
|
||||
kubectl config set-context gce --user=cluster-admin --namespace=foo \
|
||||
&& kubectl config use-context gce
|
||||
@@ -84,15 +88,15 @@ kubectl config unset users.foo # foo 사용자 삭제
|
||||
, `.yml`, `.json` 이 사용된다.
|
||||
|
||||
```bash
|
||||
kubectl create -f ./my-manifest.yaml # 리소스(들) 생성
|
||||
kubectl create -f ./my1.yaml -f ./my2.yaml # 여러 파일로 부터 생성
|
||||
kubectl create -f ./dir # dir 내 모든 매니페스트 파일에서 리소스(들) 생성
|
||||
kubectl create -f https://git.io/vPieo # url로부터 리소스(들) 생성
|
||||
kubectl apply -f ./my-manifest.yaml # 리소스(들) 생성
|
||||
kubectl apply -f ./my1.yaml -f ./my2.yaml # 여러 파일로 부터 생성
|
||||
kubectl apply -f ./dir # dir 내 모든 매니페스트 파일에서 리소스(들) 생성
|
||||
kubectl apply -f https://git.io/vPieo # url로부터 리소스(들) 생성
|
||||
kubectl create deployment nginx --image=nginx # nginx 단일 인스턴스를 시작
|
||||
kubectl explain pods,svc # 파드와 서비스 매니페스트 문서를 조회
|
||||
|
||||
# stdin으로 다수의 YAML 오브젝트 생성
|
||||
cat <<EOF | kubectl create -f -
|
||||
cat <<EOF | kubectl apply -f -
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
@@ -119,7 +123,7 @@ spec:
|
||||
EOF
|
||||
|
||||
# 여러 개의 키로 시크릿 생성
|
||||
cat <<EOF | kubectl create -f -
|
||||
cat <<EOF | kubectl apply -f -
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
@@ -141,6 +145,8 @@ kubectl get pods --all-namespaces # 모든 네임스페이스 내
|
||||
kubectl get pods -o wide # 네임스페이스 내 모든 파드의 상세 목록 조회
|
||||
kubectl get deployment my-dep # 특정 디플로이먼트의 목록 조회
|
||||
kubectl get pods --include-uninitialized # 초기화되지 않은 것을 포함하여 네임스페이스 내 모든 파드의 목록 조회
|
||||
kubectl get pod my-pod -o yaml # 파드의 YAML 조회
|
||||
kubectl get pod my-pod -o yaml --export # 클러스터 명세 없이 파드의 YAML 조회
|
||||
|
||||
# 상세 출력을 위한 Describe 커맨드
|
||||
kubectl describe nodes my-node
|
||||
|
||||
@@ -12,12 +12,13 @@ weight: 100
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
|
||||
{{< caution >}}
|
||||
컨테이너를 실행할 때 runc가 시스템 파일 디스크립터를 처리하는 방식에서 결함이 발견되었다.
|
||||
악성 컨테이너는 이 결함을 사용하여 runc 바이너리의 내용을 덮어쓸 수 있으며
|
||||
따라서 컨테이너 호스트 시스템에서 임의의 명령을 실행할 수 있다.
|
||||
|
||||
이 문제에 대한 자세한 내용은
|
||||
이 문제에 대한 자세한 내용은
|
||||
[cve-2019-5736 : runc 취약점 ] (https://access.redhat.com/security/cve/cve-2019-5736) 참고하자.
|
||||
{{< /caution >}}
|
||||
|
||||
@@ -25,7 +26,7 @@ weight: 100
|
||||
|
||||
{{< note >}}
|
||||
이 문서는 Linux에 CRI를 설치하는 사용자를 위해 작성되었다.
|
||||
다른 운영 체제의 경우, 해당 플랫폼과 관련된 문서를 찾아보자.
|
||||
다른 운영 체제의 경우, 해당 플랫폼과 관련된 문서를 찾아보자.
|
||||
{{< /note >}}
|
||||
|
||||
이 가이드의 모든 명령은 `root`로 실행해야 한다.
|
||||
@@ -61,23 +62,20 @@ Control group은 프로세스에 할당된 리소스를 제한하는데 사용
|
||||
{{< tabs name="tab-cri-docker-installation" >}}
|
||||
{{< tab name="Ubuntu 16.04" codelang="bash" >}}
|
||||
# Docker CE 설치
|
||||
## 저장소 설정
|
||||
### apt 패키지 인덱스 업데이트
|
||||
apt-get update
|
||||
|
||||
### apt가 HTTPS 저장소를 사용할 수 있도록 해주는 패키지 설치
|
||||
apt-get update && apt-get install apt-transport-https ca-certificates curl software-properties-common
|
||||
## 리포지터리 설정
|
||||
### apt가 HTTPS 리포지터리를 사용할 수 있도록 해주는 패키지 설치
|
||||
apt-get update && apt-get install apt-transport-https ca-certificates curl software-properties-common
|
||||
|
||||
### Docker의 공식 GPG 키 추가
|
||||
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
|
||||
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
|
||||
|
||||
### Docker apt 저장소 추가.
|
||||
add-apt-repository \
|
||||
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
|
||||
$(lsb_release -cs) \
|
||||
stable"
|
||||
### Docker apt 리포지터리 추가.
|
||||
add-apt-repository \
|
||||
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
|
||||
$(lsb_release -cs) \
|
||||
stable"
|
||||
|
||||
## Docker ce 설치.
|
||||
## Docker CE 설치.
|
||||
apt-get update && apt-get install docker-ce=18.06.2~ce~3-0~ubuntu
|
||||
|
||||
# 데몬 설정.
|
||||
@@ -101,19 +99,19 @@ systemctl restart docker
|
||||
{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
|
||||
|
||||
# Docker CE 설치
|
||||
## 저장소 설정
|
||||
## 리포지터리 설정
|
||||
### 필요한 패키지 설치.
|
||||
yum install yum-utils device-mapper-persistent-data lvm2
|
||||
yum install yum-utils device-mapper-persistent-data lvm2
|
||||
|
||||
### Docker 저장소 추가
|
||||
### Docker 리포지터리 추가
|
||||
yum-config-manager \
|
||||
--add-repo \
|
||||
https://download.docker.com/linux/centos/docker-ce.repo
|
||||
--add-repo \
|
||||
https://download.docker.com/linux/centos/docker-ce.repo
|
||||
|
||||
## Docker ce 설치.
|
||||
## Docker CE 설치.
|
||||
yum update && yum install docker-ce-18.06.2.ce
|
||||
|
||||
## /etc/docker 디렉토리 생성.
|
||||
## /etc/docker 디렉터리 생성.
|
||||
mkdir /etc/docker
|
||||
|
||||
# 데몬 설정.
|
||||
@@ -220,36 +218,63 @@ EOF
|
||||
sysctl --system
|
||||
```
|
||||
|
||||
### containerd 설치
|
||||
|
||||
{{< tabs name="tab-cri-containerd-installation" >}}
|
||||
{{< tab name="Ubuntu 16.04+" codelang="bash" >}}
|
||||
apt-get install -y libseccomp2
|
||||
{{< tab name="Ubuntu 16.04" codelang="bash" >}}
|
||||
# containerd 설치
|
||||
## 리포지터리 설정
|
||||
### apt가 HTTPS로 리포지터리를 사용하는 것을 허용하기 위한 패키지 설치
|
||||
apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common
|
||||
|
||||
### Docker의 공식 GPG 키 추가
|
||||
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
|
||||
|
||||
### Docker apt 리포지터리 추가.
|
||||
add-apt-repository \
|
||||
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
|
||||
$(lsb_release -cs) \
|
||||
stable"
|
||||
|
||||
## containerd 설치
|
||||
apt-get update && apt-get install -y containerd.io
|
||||
|
||||
# containerd 설정
|
||||
mkdir -p /etc/containerd
|
||||
containerd config default > /etc/containerd/config.toml
|
||||
|
||||
# containerd 재시작
|
||||
systemctl restart containerd
|
||||
{{< /tab >}}
|
||||
{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
|
||||
yum install -y libseccomp
|
||||
# containerd 설치
|
||||
## 리포지터리 설정
|
||||
### 필요한 패키지 설치
|
||||
yum install yum-utils device-mapper-persistent-data lvm2
|
||||
|
||||
### Docker 리포지터리 추가리
|
||||
yum-config-manager \
|
||||
--add-repo \
|
||||
https://download.docker.com/linux/centos/docker-ce.repo
|
||||
|
||||
## containerd 설치
|
||||
yum update && yum install containerd.io
|
||||
|
||||
# containerd 설정
|
||||
mkdir -p /etc/containerd
|
||||
containerd config default > /etc/containerd/config.toml
|
||||
|
||||
# containerd 재시작
|
||||
systemctl restart containerd
|
||||
{{< /tab >}}
|
||||
{{< /tabs >}}
|
||||
|
||||
### Containerd 설치
|
||||
### systemd
|
||||
|
||||
[Containerd 릴리스](https://github.com/containerd/containerd/releases)는 주기적으로 출판된다. 아래의 값들은 작성 당시에 가용한 최신 버전을 기준으로 하드코드 되었다. 새로운 버전과 해시는 [여기](https://storage.googleapis.com/cri-containerd-release)에서 참고한다.
|
||||
|
||||
```shell
|
||||
# 요구되는 환경 변수 export.
|
||||
export CONTAINERD_VERSION="1.1.2"
|
||||
export CONTAINERD_SHA256="d4ed54891e90a5d1a45e3e96464e2e8a4770cd380c21285ef5c9895c40549218"
|
||||
|
||||
# containerd tar 다운로드.
|
||||
wget https://storage.googleapis.com/cri-containerd-release/cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz
|
||||
|
||||
# 해시 확인.
|
||||
echo "${CONTAINERD_SHA256} cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz" | sha256sum --check -
|
||||
|
||||
# 풀기.
|
||||
tar --no-overwrite-dir -C / -xzf cri-containerd-${CONTAINERD_VERSION}.linux-amd64.tar.gz
|
||||
|
||||
# containerd 시작.
|
||||
systemctl start containerd
|
||||
```
|
||||
`systemd` cgroup driver를 사용하려면, `/etc/containerd/config.toml`의 `plugins.cri.systemd_cgroup = true`을 설정한다.
|
||||
kubeadm을 사용하는 경우에도 마찬가지로, 수동으로
|
||||
[cgroup driver for kubelet](/docs/setup/independent/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)을
|
||||
설정해준다.
|
||||
|
||||
## 다른 CRI 런타임: frakti
|
||||
|
||||
|
||||
@@ -185,7 +185,7 @@ kubernetes-minion-wf8i Ready <none> 2m v1.13.0
|
||||
Create a volume using the dynamic volume creation (only PersistentVolumes are supported for zone affinity):
|
||||
|
||||
```json
|
||||
kubectl create -f - <<EOF
|
||||
kubectl apply -f - <<EOF
|
||||
{
|
||||
"kind": "PersistentVolumeClaim",
|
||||
"apiVersion": "v1",
|
||||
@@ -236,7 +236,7 @@ Because GCE PDs / AWS EBS volumes cannot be attached across zones,
|
||||
this means that this pod can only be created in the same zone as the volume:
|
||||
|
||||
```yaml
|
||||
kubectl create -f - <<EOF
|
||||
kubectl apply -f - <<EOF
|
||||
kind: Pod
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
@@ -303,7 +303,7 @@ kubectl get nodes --show-labels
|
||||
Create the guestbook-go example, which includes an RC of size 3, running a simple web app:
|
||||
|
||||
```shell
|
||||
find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl create -f {}
|
||||
find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl apply -f {}
|
||||
```
|
||||
|
||||
The pods should be spread across all 3 zones:
|
||||
|
||||
@@ -64,7 +64,7 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다
|
||||
|
||||
* [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)는 Terraform/Packer/BASH 기반의 리눅스 호스트 상의 LXD 클러스터에 7개의 노드(부트 1개, 마스터 1개, 관리 1개, 프록시 1개 그리고 워커 3개)를 생성하기 위한 Infrastructure as Code (IaC) 스크립트이다.
|
||||
|
||||
* [Ubuntu on LXD](/docs/getting-started-guides/ubuntu/local/)는 로컬 호스트에서 9개의 인스턴스 배포를 지원한다.
|
||||
* [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local)는 로컬 호스트에서 9개의 인스턴스 배포를 지원한다.
|
||||
|
||||
## 호스트 된 솔루션
|
||||
|
||||
@@ -102,7 +102,7 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다
|
||||
|
||||
* [Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)](https://docs.us-phoenix-1.oraclecloud.com/Content/ContEng/Concepts/contengoverview.htm)는 컨테이너 애플리케이션을 클라우드에 배포하는 데 사용할 수 있는 완벽하게 관리되고, 확장 가능하며, 가용성이 높은 서비스이다.
|
||||
|
||||
* [Platform9](https://platform9.com/products/kubernetes/)는 온-프레미스 또는 모든 퍼블릭 클라우드에서 관리형 쿠버네티스를 제공한다. 또한, 24/7 상태 모니터링 및 알람 및 경고 서비스를 제공한다.(Kube2go는 웹 UI 기반의 쿠버네티스 클러스터 배포 서비스인 Platform9가 Platform9 Sandbox에 통합된 형태로 출시되었다.)
|
||||
* [Platform9](https://platform9.com/products/kubernetes/)는 온-프레미스 또는 모든 퍼블릭 클라우드에서 99.9% SLA를 보장하는 관리형 쿠버네티스를 제공한다.
|
||||
|
||||
* [Stackpoint.io](https://stackpoint.io)는 다중 퍼블릭 클라우드에서 쿠버네티스 인프라 자동화 및 관리 기능을 제공한다.
|
||||
|
||||
@@ -122,7 +122,7 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다
|
||||
* [AWS](/docs/setup/turnkey/aws/)
|
||||
* [Azure](/docs/setup/turnkey/azure/)
|
||||
* [CenturyLink Cloud](/docs/setup/turnkey/clc/)
|
||||
* [Conjure-up Kubernetes with Ubuntu on AWS, Azure, Google Cloud, Oracle Cloud](/docs/getting-started-guides/ubuntu/)
|
||||
* [Conjure-up Kubernetes with Ubuntu on AWS, Azure, Google Cloud, Oracle Cloud](https://www.ubuntu.com/kubernetes/docs/quickstart)
|
||||
* [Containership](https://containership.io/containership-platform)
|
||||
* [Docker Enterprise](https://www.docker.com/products/docker-enterprise)
|
||||
* [Gardener](https://gardener.cloud/)
|
||||
@@ -137,6 +137,7 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다
|
||||
* [Nutanix Karbon](https://www.nutanix.com/products/karbon/)
|
||||
* [Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)](https://docs.us-phoenix-1.oraclecloud.com/Content/ContEng/Concepts/contengprerequisites.htm)
|
||||
* [Pivotal Container Service](https://pivotal.io/platform/pivotal-container-service)
|
||||
* [Platform9 Managed Kubernetes as a Service](https://platform9.com/managed-kubernetes/)
|
||||
* [Rancher 2.0](https://rancher.com/docs/rancher/v2.x/en/)
|
||||
* [Stackpoint.io](/docs/setup/turnkey/stackpoint/)
|
||||
* [Supergiant.io](https://supergiant.io/)
|
||||
@@ -161,6 +162,7 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다
|
||||
* [Nirmata](https://nirmata.com/)
|
||||
* [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) by [Red Hat](https://www.redhat.com)
|
||||
* [Pivotal Container Service](https://pivotal.io/platform/pivotal-container-service)
|
||||
* [Platform9 Managed Kubernetes as a Service](https://platform9.com/managed-kubernetes/)
|
||||
* [Rancher 2.0](https://rancher.com/docs/rancher/v2.x/en/)
|
||||
* [SUSE CaaS Platform](https://www.suse.com/products/caas-platform)
|
||||
* [SUSE Cloud Application Platform](https://www.suse.com/products/cloud-application-platform/)
|
||||
@@ -184,7 +186,7 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다
|
||||
* [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/)
|
||||
* [Gardener](https://gardener.cloud/)
|
||||
* [Kublr](www.kublr.com/kubernetes.io/setup-hosted-solution)
|
||||
* [Kubernetes on Ubuntu](/docs/getting-started-guides/ubuntu/)
|
||||
* [Kubernetes on Ubuntu](https://www.ubuntu.com/kubernetes/docs/quickstart)
|
||||
* [Kubespray](/docs/setup/custom-cloud/kubespray/)
|
||||
* [Rancher Kubernetes Engine (RKE)](https://github.com/rancher/rke)
|
||||
* [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-PKS)
|
||||
@@ -197,9 +199,10 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다
|
||||
* [Nutanix AHV](https://www.nutanix.com/products/acropolis/virtualization/)
|
||||
* [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) Kubernetes platform by [Red Hat](https://www.redhat.com)
|
||||
* [oVirt](/docs/setup/on-premises-vm/ovirt/)
|
||||
* [Platform9 Managed Kubernetes as a Service](https://platform9.com/managed-kubernetes/) works on any infrastructure: on-premises, bare metal, or private/hybrid cloud.
|
||||
* [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-PKS)
|
||||
* [VMware vSphere](https://github.com/kubernetes/cloud-provider-vsphere)
|
||||
* [VMware vSphere, OpenStack, or Bare Metal](/docs/getting-started-guides/ubuntu/) (uses Juju, Ubuntu and flannel)
|
||||
* [VMware vSphere, OpenStack, or Bare Metal](https://www.ubuntu.com/kubernetes/docs/quickstart) (uses Juju, Ubuntu and flannel)
|
||||
|
||||
### 베어 메탈
|
||||
|
||||
@@ -207,8 +210,9 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다
|
||||
* [Docker Enterprise](https://www.docker.com/products/docker-enterprise)
|
||||
* [Fedora (Single Node)](/docs/getting-started-guides/fedora/fedora_manual_config/)
|
||||
* [Fedora (Multi Node)](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/)
|
||||
* [Kubernetes on Ubuntu](/docs/getting-started-guides/ubuntu/)
|
||||
* [Kubernetes on Ubuntu](https://www.ubuntu.com/kubernetes/docs/quickstart)
|
||||
* [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) Kubernetes platform by [Red Hat](https://www.redhat.com)
|
||||
* [Platform9 Managed Kubernetes as a Service](https://platform9.com/managed-kubernetes/) works on any infrastructure: on-premises, bare metal, or private/hybrid cloud.
|
||||
* [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-PKS)
|
||||
|
||||
### 통합
|
||||
@@ -228,7 +232,7 @@ IaaS 공급자 | 구성 관리 | OS | 네트워킹 | 문서
|
||||
Agile Stacks | Terraform | CoreOS | multi-support | [docs](https://www.agilestacks.com/products/kubernetes) | Commercial
|
||||
Alibaba Cloud Container Service For Kubernetes | ROS | CentOS | flannel/Terway | [docs](https://www.aliyun.com/product/containerservice) | Commercial
|
||||
any | any | multi-support | any CNI | [docs](/docs/setup/independent/create-cluster-kubeadm/) | Project ([SIG-cluster-lifecycle](https://git.k8s.io/community/sig-cluster-lifecycle))
|
||||
any | any | any | any | [docs](/docs/setup/scratch/) | Community ([@erictune](https://github.com/erictune))
|
||||
any | any | any | any | [docs](/docs/setup/release/building-from-source/) | Community ([@erictune](https://github.com/erictune))
|
||||
any | any | any | any | [docs](http://docs.projectcalico.org/v2.2/getting-started/kubernetes/installation/) | Commercial and Community
|
||||
any | RKE | multi-support | flannel or canal | [docs](https://rancher.com/docs/rancher/v2.x/en/quick-start-guide/) | [Commercial](https://rancher.com/what-is-rancher/overview/) and [Community](https://github.com/rancher/rancher)
|
||||
any | [Gardener Cluster-Operator](https://kubernetes.io/blog/2018/05/17/gardener/) | multi-support | multi-support | [docs](https://gardener.cloud) | [Project/Community](https://github.com/gardener) and [Commercial]( https://cloudplatform.sap.com/)
|
||||
@@ -236,22 +240,22 @@ AppsCode.com | Saltstack | Debian | multi-support | [docs](https://ap
|
||||
AWS | CoreOS | CoreOS | flannel | [docs](/docs/setup/turnkey/aws/) | Community
|
||||
AWS | Saltstack | Debian | AWS | [docs](/docs/setup/turnkey/aws/) | Community ([@justinsb](https://github.com/justinsb))
|
||||
AWS | kops | Debian | AWS | [docs](https://github.com/kubernetes/kops/) | Community ([@justinsb](https://github.com/justinsb))
|
||||
AWS | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
|
||||
Azure | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
|
||||
AWS | Juju | Ubuntu | flannel/calico/canal | [docs](https://www.ubuntu.com/kubernetes/docs/quickstart) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
|
||||
Azure | Juju | Ubuntu | flannel/calico/canal | [docs](https://www.ubuntu.com/kubernetes/docs/quickstart) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
|
||||
Azure (IaaS) | | Ubuntu | Azure | [docs](/docs/setup/turnkey/azure/) | [Community (Microsoft)](https://github.com/Azure/acs-engine)
|
||||
Azure Kubernetes Service | | Ubuntu | Azure | [docs](https://docs.microsoft.com/en-us/azure/aks/) | Commercial
|
||||
Bare-metal | custom | CentOS | flannel | [docs](/docs/getting-started-guides/centos/centos_manual_config/) | Community ([@coolsvap](https://github.com/coolsvap))
|
||||
Bare-metal | custom | Fedora | _none_ | [docs](/docs/getting-started-guides/fedora/fedora_manual_config/) | Project
|
||||
Bare-metal | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | Community ([@aveshagarwal](https://github.com/aveshagarwal))
|
||||
Bare Metal | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
|
||||
Bare-metal | custom | Ubuntu | flannel | [docs](/docs/getting-started-guides/ubuntu/) | Community ([@resouer](https://github.com/resouer), [@WIZARD-CXY](https://github.com/WIZARD-CXY))
|
||||
Bare Metal | Juju | Ubuntu | flannel/calico/canal | [docs](https://www.ubuntu.com/kubernetes/docs/quickstart) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
|
||||
Bare-metal | custom | Ubuntu | flannel | [docs](https://www.ubuntu.com/kubernetes/docs/quickstart) | Community ([@resouer](https://github.com/resouer), [@WIZARD-CXY](https://github.com/WIZARD-CXY))
|
||||
CloudStack | Ansible | CoreOS | flannel | [docs](/docs/getting-started-guides/cloudstack/) | Community ([@sebgoa](https://github.com/sebgoa))
|
||||
DCOS | Marathon | CoreOS/Alpine | custom | [docs](/docs/getting-started-guides/dcos/) | Community ([Kubernetes-Mesos Authors](https://github.com/mesosphere/kubernetes-mesos/blob/master/AUTHORS.md))
|
||||
Digital Rebar | kubeadm | any | metal | [docs](/docs/setup/on-premises-metal/krib/) | Community ([@digitalrebar](https://github.com/digitalrebar))
|
||||
Docker Enterprise | custom | [multi-support](https://success.docker.com/article/compatibility-matrix) | [multi-support](https://docs.docker.com/ee/ucp/kubernetes/install-cni-plugin/) | [docs](https://docs.docker.com/ee/) | Commercial
|
||||
Giant Swarm | | CoreOS | flannel and/or Calico | [docs](https://docs.giantswarm.io/) | Commercial
|
||||
GCE | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/coreos/) | Community ([@pires](https://github.com/pires))
|
||||
GCE | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
|
||||
GCE | Juju | Ubuntu | flannel/calico/canal | [docs](https://www.ubuntu.com/kubernetes/docs/quickstart) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
|
||||
GCE | Saltstack | Debian | GCE | [docs](/docs/setup/turnkey/gce/) | Project
|
||||
Google Kubernetes Engine | | | GCE | [docs](https://cloud.google.com/kubernetes-engine/docs/) | Commercial
|
||||
IBM Cloud Kubernetes Service | | Ubuntu | IBM Cloud Networking + Calico | [docs](https://cloud.ibm.com/docs/containers?topic=containers-container_index#container_index) | Commercial
|
||||
@@ -261,10 +265,10 @@ Kublr | custom | multi-support | multi-support | [docs](htt
|
||||
Kubermatic | | multi-support | multi-support | [docs](http://docs.kubermatic.io/) | Commercial
|
||||
KVM | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | Community ([@aveshagarwal](https://github.com/aveshagarwal))
|
||||
libvirt | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | Community ([@aveshagarwal](https://github.com/aveshagarwal))
|
||||
lxd | Juju | Ubuntu | flannel/canal | [docs](/docs/getting-started-guides/ubuntu/local/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
|
||||
lxd | Juju | Ubuntu | flannel/canal | [docs](https://www.ubuntu.com/kubernetes/docs/quickstart) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
|
||||
Madcore.Ai | Jenkins DSL | Ubuntu | flannel | [docs](https://madcore.ai) | Community ([@madcore-ai](https://github.com/madcore-ai))
|
||||
Mirantis Cloud Platform | Salt | Ubuntu | multi-support | [docs](https://docs.mirantis.com/mcp/) | Commercial
|
||||
Oracle Cloud Infrastructure | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
|
||||
Oracle Cloud Infrastructure | Juju | Ubuntu | flannel/calico/canal | [docs](https://www.ubuntu.com/kubernetes/docs/quickstart) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
|
||||
Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) | | | multi-support | [docs](https://docs.cloud.oracle.com/iaas/Content/ContEng/Concepts/contengoverview.htm) | Commercial
|
||||
oVirt | | | | [docs](/docs/setup/on-premises-vm/ovirt/) | Community ([@simon3z](https://github.com/simon3z))
|
||||
Platform9 | | multi-support | multi-support | [docs](https://platform9.com/managed-kubernetes/) | Commercial
|
||||
@@ -273,7 +277,7 @@ Red Hat OpenShift | Ansible & CoreOS | RHEL & CoreOS | [multi-support](http
|
||||
Stackpoint.io | | multi-support | multi-support | [docs](https://stackpoint.io/) | Commercial
|
||||
Vagrant | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/coreos/) | Community ([@pires](https://github.com/pires), [@AntonioMeireles](https://github.com/AntonioMeireles))
|
||||
VMware vSphere | any | multi-support | multi-support | [docs](https://github.com/kubernetes/cloud-provider-vsphere/tree/master/docs) | [Community](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/contactus.html)
|
||||
VMware vSphere | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
|
||||
VMware vSphere | Juju | Ubuntu | flannel/calico/canal | [docs](https://www.ubuntu.com/kubernetes/docs/quickstart) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
|
||||
VMware Cloud PKS | | Photon OS | Canal | [docs](https://docs.vmware.com/en/VMware-Kubernetes-Engine/index.html) | Commercial
|
||||
VMware Enterprise PKS | BOSH | Ubuntu | VMware NSX-T/flannel | [docs](https://docs.vmware.com/en/VMware-Enterprise-PKS/) | Commercial
|
||||
VMware Essential PKS | any | multi-support | multi-support | [docs](https://cloud.vmware.com/vmware-essential-PKS) | Commercial
|
||||
|
||||
@@ -72,7 +72,7 @@ sudo mv minikube /usr/local/bin
|
||||
이 문서는 Minikube를 리눅스에 정적 바이너리를 사용해서 설치하는 방법을 설명한다. 리눅스에 설치하는 다른 방법은, 공식 Minikube GitHub 저장소의 [Other Ways to Install](https://github.com/kubernetes/minikube#other-ways-to-install)를 참조한다.
|
||||
{{< /note >}}
|
||||
|
||||
정적 바이너리를 내려받아서 리눅스에 Minikube를 설치할 수 있따.
|
||||
정적 바이너리를 내려받아서 리눅스에 Minikube를 설치할 수 있다.
|
||||
|
||||
```shell
|
||||
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \
|
||||
|
||||
@@ -11,16 +11,18 @@ content_template: templates/tutorial
|
||||
|
||||
{{% capture objectives %}}
|
||||
|
||||
* 컨피그 맵을 생성한다.
|
||||
* 컨피그 맵을 사용해서 파드 명세를 생성한다.
|
||||
* 파드를 생성한다.
|
||||
* 설정이 올바르게 적용되었는지 검증한다.
|
||||
* 다음을 포함하는 `kustomization.yaml` 파일을 생성한다.
|
||||
* 컨피그 맵 생성자
|
||||
* 컨피그 맵을 사용하는 파드 리소스
|
||||
* `kubectl apply -k ./`를 실행하여 작업한 디렉토리를 적용한다.
|
||||
* 구성이 잘 적용되었는지 확인한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
* 예시는 `kubectl` 1.14 이상 버전에서 동작한다.
|
||||
* [컨피그 맵을 사용해서 컨테이너 설정하기](/docs/tasks/configure-pod-container/configure-pod-configmap/)를 이해한다.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -32,49 +34,48 @@ content_template: templates/tutorial
|
||||
|
||||
아래의 단계를 통해서 컨피그 맵에 저장된 데이터를 사용해서 Redis 캐시를 설정할 수 있다.
|
||||
|
||||
첫째, `redis-config` 파일에서 컨피그 맵을 생성한다.
|
||||
첫째, `redis-config` 파일에서 컨피그 맵을 포함한 `kustomization.yaml`를 생성한다.
|
||||
|
||||
{{< codenew file="pods/config/redis-config" >}}
|
||||
|
||||
```shell
|
||||
curl -OL https://k8s.io/examples/pods/config/redis-config
|
||||
kubectl create configmap example-redis-config --from-file=redis-config
|
||||
|
||||
cat <<EOF >./kustomization.yaml
|
||||
configMapGenerator:
|
||||
- name: example-redis-config
|
||||
files:
|
||||
- redis-config
|
||||
EOF
|
||||
```
|
||||
|
||||
```shell
|
||||
configmap/example-redis-config created
|
||||
```
|
||||
|
||||
생성된 컨피그 맵을 점검한다.
|
||||
|
||||
```shell
|
||||
kubectl get configmap example-redis-config -o yaml
|
||||
```
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
data:
|
||||
redis-config: |
|
||||
maxmemory 2mb
|
||||
maxmemory-policy allkeys-lru
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
creationTimestamp: 2016-03-30T18:14:41Z
|
||||
name: example-redis-config
|
||||
namespace: default
|
||||
resourceVersion: "24686"
|
||||
selfLink: /api/v1/namespaces/default/configmaps/example-redis-config
|
||||
uid: 460a2b6e-f6a3-11e5-8ae5-42010af00002
|
||||
```
|
||||
|
||||
이제, 컨피그 맵에 저장된 설정 데이터를 사용하는 파드 명세를 생성한다.
|
||||
`kustomization.yaml`에 파드 리소스 구성을 추가한다.
|
||||
|
||||
{{< codenew file="pods/config/redis-pod.yaml" >}}
|
||||
|
||||
파드를 생성한다.
|
||||
```shell
|
||||
curl -OL https://k8s.io/examples/pods/config/redis-pod.yaml
|
||||
|
||||
cat <<EOF >>./kustomization.yaml
|
||||
resources:
|
||||
- redis-pod.yaml
|
||||
EOF
|
||||
```
|
||||
|
||||
컨피그 맵과 파드 개체를 생성하도록 kustomization 디렉토리를 적용한다.
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/pods/config/redis-pod.yaml
|
||||
kubectl apply -k .
|
||||
```
|
||||
|
||||
생성된 오브젝트를 확인한다.
|
||||
```shell
|
||||
> kubectl get -k .
|
||||
NAME DATA AGE
|
||||
configmap/example-redis-config-dgh9dg555m 1 52s
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
pod/redis 1/1 Running 0 52s
|
||||
```
|
||||
|
||||
이 예제에서는 설정 볼륨이 `/redis-master`에 마운트되어 있다.
|
||||
@@ -82,7 +83,8 @@ kubectl create -f https://k8s.io/examples/pods/config/redis-pod.yaml
|
||||
따라서, Redis 설정을 위한 파일 경로는 `/redis-master/redis.conf`이다.
|
||||
이곳이 이미지가 Redis 마스터를 위한 설정 파일을 찾는 곳이다.
|
||||
|
||||
설정이 올바르게 적용되었는지 확인하기 위해서, `kubectl exec`를 사용해 파드 속에서 `redis-cli` 툴을 실행해 본다.
|
||||
설정이 올바르게 적용되었는지 확인하기 위해서,
|
||||
`kubectl exec`를 사용해 파드 속에서 `redis-cli` 툴을 실행해 본다.
|
||||
|
||||
```shell
|
||||
kubectl exec -it redis redis-cli
|
||||
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
title: "서비스"
|
||||
weight: 70
|
||||
---
|
||||
|
||||
@@ -0,0 +1,342 @@
|
||||
---
|
||||
title: 소스 IP 주소 이용하기
|
||||
content_template: templates/tutorial
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
쿠버네티스 클러스터에서 실행 중인 애플리케이션은 서로 간에 외부 세계와
|
||||
서비스 추상화를 통해 찾고 통신한다. 이 문서는
|
||||
다른 종류의 서비스로 보내진 패킷의 소스 IP 주소에 어떤 일이 벌어지는지와
|
||||
이 동작을 요구에 따라 토글할 수 있는지 설명한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
## 용어
|
||||
|
||||
이 문서는 다음 용어를 사용한다.
|
||||
|
||||
* [NAT](https://en.wikipedia.org/wiki/Network_address_translation): 네트워크 주소 변환
|
||||
* [소스 NAT](https://en.wikipedia.org/wiki/Network_address_translation#SNAT): 패킷 상의 소스 IP 주소를 변경함, 보통 노드의 IP 주소
|
||||
* [대상 NAT](https://en.wikipedia.org/wiki/Network_address_translation#DNAT): 패킷 상의 대상 IP 주소를 변경함, 보통 파드의 IP 주소
|
||||
* [VIP](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies): 가상 IP 주소, 모든 쿠버네티스 서비스에 할당된 것 같은
|
||||
* [Kube-proxy](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies): 네트워크 데몬으로 모든 노드에서 서비스 VIP 관리를 관리한다.
|
||||
|
||||
|
||||
## 전제 조건
|
||||
|
||||
이 문서의 예시를 실행하기 위해서 쿠버네티스 1.5 이상의 동작하는 클러스터가 필요하다.
|
||||
이 예시는 HTTP 헤더로 수신한 요청의 소스 IP 주소를 회신하는
|
||||
작은 nginx 웹 서버를 이용한다. 다음과 같이 생성할 수 있다.
|
||||
|
||||
```console
|
||||
$ kubectl run source-ip-app --image=k8s.gcr.io/echoserver:1.4
|
||||
deployment.apps/source-ip-app created
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture objectives %}}
|
||||
|
||||
* 간단한 애플리케이션을 다양한 서비스 종류로 노출하기
|
||||
* 각 서비스 유형에 따른 소스 IP NAT 의 동작 이해하기
|
||||
* 소스 IP 주소 보존에 관한 절충 사항 이해
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture lessoncontent %}}
|
||||
|
||||
## Type=ClusterIP인 서비스에서 소스 IP
|
||||
|
||||
쿠버네티스 1.2부터 기본으로 제공하는
|
||||
[iptables 모드](/docs/concepts/services-networking/service/#proxy-mode-iptables)로 운영하는 경우
|
||||
클러스터 내에서 클러스터 IP로 패킷을 보내면 소스 NAT를 통과하지 않는다.
|
||||
Kube-proxy는 이 모드를 `proxyMode` 엔드포인트를 통해 노출한다.
|
||||
|
||||
```console
|
||||
$ kubectl get nodes
|
||||
NAME STATUS ROLES AGE VERSION
|
||||
kubernetes-minion-group-6jst Ready <none> 2h v1.13.0
|
||||
kubernetes-minion-group-cx31 Ready <none> 2h v1.13.0
|
||||
kubernetes-minion-group-jj1t Ready <none> 2h v1.13.0
|
||||
|
||||
kubernetes-minion-group-6jst $ curl localhost:10249/proxyMode
|
||||
iptables
|
||||
```
|
||||
|
||||
소스 IP 애플리케이션을 통해 서비스를 생성하여 소스 IP 주소 보존 여부를 테스트할 수 있다.
|
||||
|
||||
```console
|
||||
$ kubectl expose deployment source-ip-app --name=clusterip --port=80 --target-port=8080
|
||||
service/clusterip exposed
|
||||
|
||||
$ kubectl get svc clusterip
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
clusterip ClusterIP 10.0.170.92 <none> 80/TCP 51s
|
||||
```
|
||||
|
||||
그리고 동일한 클러스터의 파드에서 `클러스터IP`를 치면:
|
||||
|
||||
```console
|
||||
$ kubectl run busybox -it --image=busybox --restart=Never --rm
|
||||
Waiting for pod default/busybox to be running, status is Pending, pod ready: false
|
||||
If you don't see a command prompt, try pressing enter.
|
||||
|
||||
# ip addr
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue
|
||||
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
|
||||
inet 127.0.0.1/8 scope host lo
|
||||
valid_lft forever preferred_lft forever
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc noqueue
|
||||
link/ether 0a:58:0a:f4:03:08 brd ff:ff:ff:ff:ff:ff
|
||||
inet 10.244.3.8/24 scope global eth0
|
||||
valid_lft forever preferred_lft forever
|
||||
inet6 fe80::188a:84ff:feb0:26a5/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
|
||||
# wget -qO - 10.0.170.92
|
||||
CLIENT VALUES:
|
||||
client_address=10.244.3.8
|
||||
command=GET
|
||||
...
|
||||
```
|
||||
client_address는 클라이언트 파드와 서버 파드가 같은 노드 또는 다른 노드에 있는지 여부에 관계없이 항상 클라이언트 파드의 IP 주소이다.
|
||||
|
||||
## Type=NodePort인 서비스에서 소스 IP
|
||||
|
||||
쿠버네티스 1.5부터 [Type=NodePort](/docs/concepts/services-networking/service/#nodeport)인 서비스로 보내진 패킷은
|
||||
소스 NAT가 기본으로 적용된다. `NodePort` 서비스를 생성하여 이것을 테스트할 수 있다.
|
||||
|
||||
```console
|
||||
$ kubectl expose deployment source-ip-app --name=nodeport --port=80 --target-port=8080 --type=NodePort
|
||||
service/nodeport exposed
|
||||
|
||||
$ NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport)
|
||||
$ NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="ExternalIP")].address }')
|
||||
```
|
||||
|
||||
클라우드 공급자 상에서 실행한다면,
|
||||
위에 보고된 `nodes:nodeport`를 위한 방화벽 규칙을 열어주어야 한다.
|
||||
이제 위에 노드 포트로 할당받은 포트를 통해 클러스터 외부에서
|
||||
서비스에 도달할 수 있다.
|
||||
|
||||
```console
|
||||
$ for node in $NODES; do curl -s $node:$NODEPORT | grep -i client_address; done
|
||||
client_address=10.180.1.1
|
||||
client_address=10.240.0.5
|
||||
client_address=10.240.0.3
|
||||
```
|
||||
|
||||
명심할 것은 정확한 클라이언트 IP 주소가 아니고, 클러스터 내부 IP 주소이다. 왜 이런 일이 발생했는지 설명한다.
|
||||
|
||||
* 클라이언트는 `node2:nodePort`로 패킷을 보낸다.
|
||||
* `node2`는 소스 IP 주소(SNAT)를 패킷 상에서 자신의 IP 주소로 교체한다.
|
||||
* `noee2`는 대상 IP를 패킷 상에서 파드의 IP로 교체한다.
|
||||
* 패킷은 node 1로 라우팅 된 다음 엔드포인트로 라우팅 된다.
|
||||
* 파드의 응답은 node2로 다시 라우팅된다.
|
||||
* 파드의 응답은 클라이언트로 다시 전송된다.
|
||||
|
||||
시각적으로
|
||||
|
||||
```
|
||||
client
|
||||
\ ^
|
||||
\ \
|
||||
v \
|
||||
node 1 <--- node 2
|
||||
| ^ SNAT
|
||||
| | --->
|
||||
v |
|
||||
endpoint
|
||||
```
|
||||
|
||||
|
||||
이를 피하기 위해 쿠버네티스는 클라이언트 소스 IP 주소를 보존하는 기능이 있다.
|
||||
[(기능별 가용성은 여기에)](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip).
|
||||
`service.spec.externalTrafficPolicy`을 `Local`로 하면
|
||||
오직 로컬 엔드포인트로만 프록시 요청하고 다른 노드로 트래픽 전달하지 않으므로,
|
||||
원본 소스 IP 주소를 보존한다.
|
||||
만약 로컬 엔드 포인트가 없다면, 그 노드로 보내진 패킷은 버려지므로
|
||||
패킷 처리 규칙에서 정확한 소스 IP 임을 신뢰할 수 있으므로,
|
||||
패킷을 엔드포인트까지 전달할 수 있다.
|
||||
|
||||
다음과 같이 `service.spec.externalTrafficPolicy` 필드를 설정하자.
|
||||
|
||||
```console
|
||||
$ kubectl patch svc nodeport -p '{"spec":{"externalTrafficPolicy":"Local"}}'
|
||||
service/nodeport patched
|
||||
```
|
||||
|
||||
이제 다시 테스트를 실행해보자.
|
||||
|
||||
```console
|
||||
$ for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; done
|
||||
client_address=104.132.1.79
|
||||
```
|
||||
|
||||
엔드포인트 파드가 실행 중인 노드에서 *올바른* 클라이언트 IP 주소인
|
||||
딱 한 종류의 응답만 수신한다.
|
||||
|
||||
어떻게 이렇게 되었는가:
|
||||
|
||||
* 클라이언트는 패킷을 엔드포인트가 없는 `node2:nodePort` 보낸다.
|
||||
* 패킷은 버려진다.
|
||||
* 클라이언트는 패킷을 엔드포인트를 가진 `node1:nodePort` 보낸다.
|
||||
* node1은 패킷을 올바른 소스 IP 주소로 엔드포인트로 라우팅 한다.
|
||||
|
||||
|
||||
시각적으로
|
||||
|
||||
```
|
||||
client
|
||||
^ / \
|
||||
/ / \
|
||||
/ v X
|
||||
node 1 node 2
|
||||
^ |
|
||||
| |
|
||||
| v
|
||||
endpoint
|
||||
```
|
||||
|
||||
|
||||
|
||||
## Type=LoadBalancer인 서비스에서 소스 IP
|
||||
|
||||
쿠버네티스 1.5 부터 [Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)인 서비스로
|
||||
보낸 패킷은 소스 NAT를 기본으로 하는데, `Ready` 상태로 모든 스케줄된 모든 쿠버네티스 노드는
|
||||
로드 밸런싱 트래픽에 적합하다. 따라서 엔드포인트가 없는 노드에
|
||||
패킷이 도착하면 시스템은 엔드포인트를 *포함한* 노드에 프록시를
|
||||
수행하고 패킷 상에서 노드의 IP 주소로 소스 IP 주소를 변경한다
|
||||
(이전 섹션에서 기술한 것처럼).
|
||||
|
||||
로드밸런서를 통해 source-ip-app을 노출하여 테스트할 수 있다.
|
||||
|
||||
```console
|
||||
$ kubectl expose deployment source-ip-app --name=loadbalancer --port=80 --target-port=8080 --type=LoadBalancer
|
||||
service/loadbalancer exposed
|
||||
|
||||
$ kubectl get svc loadbalancer
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
loadbalancer LoadBalancer 10.0.65.118 104.198.149.140 80/TCP 5m
|
||||
|
||||
$ curl 104.198.149.140
|
||||
CLIENT VALUES:
|
||||
client_address=10.240.0.5
|
||||
...
|
||||
```
|
||||
|
||||
그러나 구글 클라우드 엔진/GCE 에서 실행 중이라면 동일한 `service.spec.externalTrafficPolicy` 필드를 `Local`로 설정하면
|
||||
서비스 엔드포인트가 *없는* 노드는 고의적으로 헬스 체크에 실패하여
|
||||
강제로 로드밸런싱 트래픽을 받을 수 있는 노드 목록에서
|
||||
자신을 스스로 제거한다.
|
||||
|
||||
시각적으로:
|
||||
|
||||
```
|
||||
client
|
||||
|
|
||||
lb VIP
|
||||
/ ^
|
||||
v /
|
||||
health check ---> node 1 node 2 <--- health check
|
||||
200 <--- ^ | ---> 500
|
||||
| V
|
||||
endpoint
|
||||
```
|
||||
|
||||
이것은 어노테이션을 설정하여 테스트할 수 있다.
|
||||
|
||||
```console
|
||||
$ kubectl patch svc loadbalancer -p '{"spec":{"externalTrafficPolicy":"Local"}}'
|
||||
```
|
||||
|
||||
쿠버네티스에 의해 `service.spec.healthCheckNodePort` 필드가
|
||||
즉각적으로 할당되는 것을 봐야 한다.
|
||||
|
||||
```console
|
||||
$ kubectl get svc loadbalancer -o yaml | grep -i healthCheckNodePort
|
||||
healthCheckNodePort: 32122
|
||||
```
|
||||
|
||||
`service.spec.healthCheckNodePort` 필드는 `/healthz`에서 헬스 체크를 제공하는
|
||||
모든 노드의 포트를 가르킨다. 이것을 테스트할 수 있다.
|
||||
|
||||
```
|
||||
$ kubectl get pod -o wide -l run=source-ip-app
|
||||
NAME READY STATUS RESTARTS AGE IP NODE
|
||||
source-ip-app-826191075-qehz4 1/1 Running 0 20h 10.180.1.136 kubernetes-minion-group-6jst
|
||||
|
||||
kubernetes-minion-group-6jst $ curl localhost:32122/healthz
|
||||
1 Service Endpoints found
|
||||
|
||||
kubernetes-minion-group-jj1t $ curl localhost:32122/healthz
|
||||
No Service Endpoints Found
|
||||
```
|
||||
|
||||
마스터에서 실행 중인 서비스 컨트롤러는 필요시에 클라우드 로드밸런서를 할당할 책임이 있다.
|
||||
또한, 각 노드에 HTTP 헬스 체크를 이 포트와 경로로 할당한다.
|
||||
헬스체크가 실패한 엔드포인트를 포함하지 않은 2개 노드에서 10초를 기다리고
|
||||
로드밸런서 IP 주소로 curl 하자.
|
||||
|
||||
```console
|
||||
$ curl 104.198.149.140
|
||||
CLIENT VALUES:
|
||||
client_address=104.132.1.79
|
||||
...
|
||||
```
|
||||
|
||||
__크로스 플랫폼 지원__
|
||||
|
||||
쿠버네티스 1.5부터 Type=LoadBalancer 서비스를 통한
|
||||
소스 IP 주소 보존을 지원하지만,
|
||||
이는 클라우드 공급자(GCE, Azure)의 하위 집합으로 구현되어 있다. 실행중인 클라우드 공급자에서
|
||||
몇 가지 다른 방법으로 로드밸런서를 요청하자.
|
||||
|
||||
1. 클라이언트 연결을 종료하고 새 연결을 여는 프록시를 이용한다.
|
||||
이 경우 소스 IP 주소는 클라이언트 IP 주소가 아니고
|
||||
항상 클라우드 로드밸런서의 IP 주소이다.
|
||||
|
||||
2. 로드밸런서의 VIP에 전달된 클라이언트가 보낸 요청을
|
||||
중간 프록시가 아닌 클라이언트 소스 IP 주소가 있는 노드로
|
||||
끝나는 패킷 전달자를 이용한다.
|
||||
|
||||
첫 번째 범주의 로드밸런서는 진짜 클라이언트 IP를 통신하기 위해
|
||||
HTTP [X-FORWARDED-FOR](https://en.wikipedia.org/wiki/X-Forwarded-For) 헤더나
|
||||
[프록시 프로토콜](http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt)같이 로드밸런서와
|
||||
백엔드 간에 합의된 프로토콜을 사용해야 한다.
|
||||
두 번째 범주의 로드밸런서는 서비스의 `service.spec.healthCheckNodePort` 필드의 저장된 포트를 가르키는
|
||||
간단한 HTTP 헬스 체크를 생성하여
|
||||
위에서 설명한 기능을 활용할 수 있다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture cleanup %}}
|
||||
|
||||
서비스를 삭제하자.
|
||||
|
||||
```console
|
||||
$ kubectl delete svc -l run=source-ip-app
|
||||
```
|
||||
|
||||
디플로이먼트와 리플리카 셋과 파드를 삭제하자.
|
||||
|
||||
```console
|
||||
$ kubectl delete deployment source-ip-app
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
* [서비스를 통한 애플리케이션 연결하기](/docs/concepts/services-networking/connect-applications-service/)에 대해 더 공부하기
|
||||
* [부하분산](/docs/user-guide/load-balancer)에 대해 더 공부하기
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,133 @@
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: zk-hs
|
||||
labels:
|
||||
app: zk
|
||||
spec:
|
||||
ports:
|
||||
- port: 2888
|
||||
name: server
|
||||
- port: 3888
|
||||
name: leader-election
|
||||
clusterIP: None
|
||||
selector:
|
||||
app: zk
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: zk-cs
|
||||
labels:
|
||||
app: zk
|
||||
spec:
|
||||
ports:
|
||||
- port: 2181
|
||||
name: client
|
||||
selector:
|
||||
app: zk
|
||||
---
|
||||
apiVersion: policy/v1beta1
|
||||
kind: PodDisruptionBudget
|
||||
metadata:
|
||||
name: zk-pdb
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: zk
|
||||
maxUnavailable: 1
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: StatefulSet
|
||||
metadata:
|
||||
name: zk
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: zk
|
||||
serviceName: zk-hs
|
||||
replicas: 3
|
||||
updateStrategy:
|
||||
type: RollingUpdate
|
||||
podManagementPolicy: Parallel
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: zk
|
||||
spec:
|
||||
affinity:
|
||||
podAntiAffinity:
|
||||
requiredDuringSchedulingIgnoredDuringExecution:
|
||||
- labelSelector:
|
||||
matchExpressions:
|
||||
- key: "app"
|
||||
operator: In
|
||||
values:
|
||||
- zk
|
||||
topologyKey: "kubernetes.io/hostname"
|
||||
containers:
|
||||
- name: kubernetes-zookeeper
|
||||
imagePullPolicy: Always
|
||||
image: "k8s.gcr.io/kubernetes-zookeeper:1.0-3.4.10"
|
||||
resources:
|
||||
requests:
|
||||
memory: "1Gi"
|
||||
cpu: "0.5"
|
||||
ports:
|
||||
- containerPort: 2181
|
||||
name: client
|
||||
- containerPort: 2888
|
||||
name: server
|
||||
- containerPort: 3888
|
||||
name: leader-election
|
||||
command:
|
||||
- sh
|
||||
- -c
|
||||
- "start-zookeeper \
|
||||
--servers=3 \
|
||||
--data_dir=/var/lib/zookeeper/data \
|
||||
--data_log_dir=/var/lib/zookeeper/data/log \
|
||||
--conf_dir=/opt/zookeeper/conf \
|
||||
--client_port=2181 \
|
||||
--election_port=3888 \
|
||||
--server_port=2888 \
|
||||
--tick_time=2000 \
|
||||
--init_limit=10 \
|
||||
--sync_limit=5 \
|
||||
--heap=512M \
|
||||
--max_client_cnxns=60 \
|
||||
--snap_retain_count=3 \
|
||||
--purge_interval=12 \
|
||||
--max_session_timeout=40000 \
|
||||
--min_session_timeout=4000 \
|
||||
--log_level=INFO"
|
||||
readinessProbe:
|
||||
exec:
|
||||
command:
|
||||
- sh
|
||||
- -c
|
||||
- "zookeeper-ready 2181"
|
||||
initialDelaySeconds: 10
|
||||
timeoutSeconds: 5
|
||||
livenessProbe:
|
||||
exec:
|
||||
command:
|
||||
- sh
|
||||
- -c
|
||||
- "zookeeper-ready 2181"
|
||||
initialDelaySeconds: 10
|
||||
timeoutSeconds: 5
|
||||
volumeMounts:
|
||||
- name: datadir
|
||||
mountPath: /var/lib/zookeeper
|
||||
securityContext:
|
||||
runAsUser: 1000
|
||||
fsGroup: 1000
|
||||
volumeClaimTemplates:
|
||||
- metadata:
|
||||
name: datadir
|
||||
spec:
|
||||
accessModes: [ "ReadWriteOnce" ]
|
||||
resources:
|
||||
requests:
|
||||
storage: 10Gi
|
||||
Reference in New Issue
Block a user