diff --git a/content/ko/_index.html b/content/ko/_index.html index c8d9d593c1..cde99ff2d3 100644 --- a/content/ko/_index.html +++ b/content/ko/_index.html @@ -41,7 +41,6 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준

-
Attend KubeCon in Amsterdam on August 13-16, 2020

diff --git a/content/ko/case-studies/adform/index.html b/content/ko/case-studies/adform/index.html index e9a8acc7a2..be35a2d837 100644 --- a/content/ko/case-studies/adform/index.html +++ b/content/ko/case-studies/adform/index.html @@ -12,7 +12,7 @@ quote: > Kubernetes enabled the self-healing and immutable infrastructure. We can do faster releases, so our developers are really happy. They can ship our features faster than before, and that makes our clients happier. --- -
+

CASE STUDY:
Improving Performance and Morale with Cloud Native

@@ -66,7 +66,7 @@ The company has a large infrastructure: Ope
-
+
"The fact that Cloud Native Computing Foundation incubated Kubernetes was a really big point for us because it was vendor neutral. And we can see that a community really gathers around it. Everyone shares their experiences, their knowledge, and the fact that it’s open source, you can contribute."

— Edgaras Apšega, IT Systems Engineer, Adform
@@ -83,7 +83,7 @@ The first production cluster was launched in the spring of 2018, and is now up t
-
+
"Releases are really nice for them, because they just push their code to Git and that’s it. They don’t have to worry about their virtual machines anymore."

— Andrius Cibulskis, IT Systems Engineer, Adform
diff --git a/content/ko/case-studies/capital-one/index.html b/content/ko/case-studies/capital-one/index.html index 773db4869e..f95fb2acc7 100644 --- a/content/ko/case-studies/capital-one/index.html +++ b/content/ko/case-studies/capital-one/index.html @@ -5,7 +5,7 @@ cid: caseStudies css: /css/style_case_studies.css --- -
+

CASE STUDY:
Supporting Fast Decisioning Applications with Kubernetes

@@ -55,7 +55,7 @@ css: /css/style_case_studies.css
-
+
"We want to provide the tools in the same ecosystem, in a consistent way, rather than have a large custom snowflake ecosystem where every tool needs its own custom deployment. Kubernetes gives us the ability to bring all of these together, so the richness of the open source and even the license community dealing with big data can be corralled." @@ -69,7 +69,7 @@ css: /css/style_case_studies.css
-
+
With Kubernetes, "a team can come to us and we can have them up and running with a basic decisioning app in a fortnight, which before would have taken a whole quarter, if not longer. Kubernetes is a manifold productivity multiplier."
diff --git a/content/ko/case-studies/ibm/index.html b/content/ko/case-studies/ibm/index.html index 54e941c9cb..e9a78a9443 100644 --- a/content/ko/case-studies/ibm/index.html +++ b/content/ko/case-studies/ibm/index.html @@ -9,7 +9,7 @@ logo: ibm_featured_logo.svg featured: false --- -
+

CASE STUDY:
Building an Image Trust Service on Kubernetes with Notary and TUF

@@ -58,7 +58,7 @@ The availability of image signing "is a huge benefit to security-conscious custo
-
+
"Image signing is one key part of our Kubernetes container service offering, and our container registry team saw Notary as the de facto way to implement that capability in the current Docker and container ecosystem"

- Michael Hough, a software developer with the IBM Cloud Container Registry team
@@ -75,7 +75,7 @@ The availability of image signing "is a huge benefit to security-conscious custo
-
+
"With our IBM Cloud Kubernetes as-a-service offering and the admission controller we have made available, it allows both IBM services as well as customers of the IBM public cloud to use security policies to control service deployment."

- Michael Hough, a software developer with the IBM Cloud Container Registry team
diff --git a/content/ko/case-studies/ing/index.html b/content/ko/case-studies/ing/index.html index 6e2648a455..943daec2de 100644 --- a/content/ko/case-studies/ing/index.html +++ b/content/ko/case-studies/ing/index.html @@ -11,7 +11,7 @@ quote: > --- -
+

CASE STUDY:
Driving Banking Innovation with Cloud Native

@@ -58,7 +58,7 @@ quote: >
-
+
"We decided to standardize ING on a Kubernetes framework." Everything is run on premise due to banking regulations, he adds, but "we will be building an internal public cloud. We are trying to get on par with what public clouds are doing. That’s one of the reasons we got Kubernetes."

— Thijs Ebbers, Infrastructure Architect, ING @@ -72,7 +72,7 @@ quote: >
-
+
"We have to run the complete platform of services we need, many routing from different places. We need this Kubernetes framework for deploying the containers, with all those components, monitoring, logging. It’s complex."

— Onno Van der Voort, Infrastructure Architect, ING
diff --git a/content/ko/case-studies/naic/index.html b/content/ko/case-studies/naic/index.html index d40dd19c77..3deb91e480 100644 --- a/content/ko/case-studies/naic/index.html +++ b/content/ko/case-studies/naic/index.html @@ -9,7 +9,7 @@ logo: naic_featured_logo.png featured: false --- -
+

CASE STUDY:
A Culture and Technology Transition Enabled by Kubernetes

@@ -59,7 +59,7 @@ In addition, NAIC is onboarding teams to the new platform, and those teams have
-
+
"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."

- Dan Barker, Chief Enterprise Architect, NAIC
@@ -77,7 +77,7 @@ As for other CNCF projects, NAIC is using Prometheus on a small scale and hopes
-
+
"We knew that Kubernetes had become the de facto standard for container orchestration. 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."

- Dan Barker, Chief Enterprise Architect, NAIC
diff --git a/content/ko/case-studies/nordstrom/index.html b/content/ko/case-studies/nordstrom/index.html index 5385c2473d..788453de35 100644 --- a/content/ko/case-studies/nordstrom/index.html +++ b/content/ko/case-studies/nordstrom/index.html @@ -5,7 +5,7 @@ cid: caseStudies css: /css/style_case_studies.css --- -
+

CASE STUDY:
Finding Millions in Potential Savings in a Tough Retail Climate @@ -60,7 +60,7 @@ css: /css/style_case_studies.css
-
+
"We made a bet that Kubernetes was going to take off, informed by early indicators of community support and project velocity, so we rebuilt our system with Kubernetes at the core,"
@@ -77,7 +77,7 @@ The benefits were immediate for the teams that came on board. "Teams running on
-
+
"Teams running on our Kubernetes cluster loved the fact that they had fewer issues to worry about. They didn’t need to manage infrastructure or operating systems," says Grigoriu. "Early adopters loved the declarative nature of Kubernetes. They loved the reduced surface area they had to deal with."
diff --git a/content/ko/case-studies/northwestern-mutual/index.html b/content/ko/case-studies/northwestern-mutual/index.html index dac0ef0d66..47b4bbc7be 100644 --- a/content/ko/case-studies/northwestern-mutual/index.html +++ b/content/ko/case-studies/northwestern-mutual/index.html @@ -5,7 +5,7 @@ cid: caseStudies css: /css/style_case_studies.css --- -
+

CASE STUDY:
Cloud Native at Northwestern Mutual @@ -22,7 +22,7 @@ css: /css/style_case_studies.css

Challenge

- In the spring of 2015, Northwestern Mutual acquired a fintech startup, LearnVest, and decided to take "Northwestern Mutual’s leading products and services and meld it with LearnVest’s digital experience and innovative financial planning platform," says Brad Williams, Director of Engineering for Client Experience, Northwestern Mutual. The company’s existing infrastructure had been optimized for batch workflows hosted on on-prem networks; deployments were very traditional, focused on following a process instead of providing deployment agility. "We had to build a platform that was elastically scalable, but also much more responsive, so we could quickly get data to the client website so our end-customers have the experience they expect," says Williams. + In the spring of 2015, Northwestern Mutual acquired a fintech startup, LearnVest, and decided to take "Northwestern Mutual’s leading products and services and meld it with LearnVest’s digital experience and innovative financial planning platform," says Brad Williams, Director of Engineering for Client Experience, Northwestern Mutual. The company’s existing infrastructure had been optimized for batch workflows hosted on on-prem networks; deployments were very traditional, focused on following a process instead of providing deployment agility. "We had to build a platform that was elastically scalable, but also much more responsive, so we could quickly get data to the client website so our end-customers have the experience they expect," says Williams.

Solution

The platform team came up with a plan for using the public cloud (AWS), Docker containers, and Kubernetes for orchestration. "Kubernetes gave us that base framework so teams can be very autonomous in what they’re building and deliver very quickly and frequently," says Northwestern Mutual Cloud Native Engineer Frank Greco Jr. The team also built and open-sourced Kanali, a Kubernetes-native API management tool that uses OpenTracing, Jaeger, and gRPC. @@ -53,7 +53,7 @@ In order to give the company’s 4.5 million clients the digital experience they
-
+
"Kubernetes has definitely been the right choice for us. It gave us that base framework so teams can be autonomous in what they’re building and deliver very quickly and frequently." @@ -63,12 +63,12 @@ In order to give the company’s 4.5 million clients the digital experience they
Williams and the rest of the platform team decided that the first step would be to start moving from private data centers to AWS. With a new microservice architecture in mind—and the freedom to implement what was best for the organization—they began using Docker containers. After looking into the various container orchestration options, they went with Kubernetes, even though it was still in beta at the time. "There was some debate whether we should build something ourselves, or just leverage that product and evolve with it," says Northwestern Mutual Cloud Native Engineer Frank Greco Jr. "Kubernetes has definitely been the right choice for us. It gave us that base framework so teams can be autonomous in what they’re building and deliver very quickly and frequently."

As early adopters, the team had to do a lot of work with Ansible scripts to stand up the cluster. "We had a lot of hard security requirements given the nature of our business," explains Bryan Pfremmer, App Platform Teams Manager, Northwestern Mutual. "We found ourselves running a configuration that very few other people ever tried." The client experience group was the first to use the new platform; today, a few hundred of the company’s 1,500 engineers are using it and more are eager to get on board. -The results have been dramatic. Before, infrastructure deployments could take two weeks; now, it is done in a matter of minutes. Now with a focus on Infrastructure automation, and self-service, "You can take an app to production in that same day if you want to," says Pfremmer. +The results have been dramatic. Before, infrastructure deployments could take two weeks; now, it is done in a matter of minutes. Now with a focus on Infrastructure automation, and self-service, "You can take an app to production in that same day if you want to," says Pfremmer.
-
+
"Now, developers have autonomy, they can use this whenever they want, however they want. It becomes more valuable the more instrumentation downstream that happens, as we mature in it."
diff --git a/content/ko/case-studies/ocado/index.html b/content/ko/case-studies/ocado/index.html index 6a930f945c..79ac9bf3a8 100644 --- a/content/ko/case-studies/ocado/index.html +++ b/content/ko/case-studies/ocado/index.html @@ -11,7 +11,7 @@ weight: 4 quote: > People at Ocado Technology have been quite amazed. They ask, ‘Can we do this on a Dev cluster?’ and 10 minutes later we have rolled out something that is deployed across the cluster. The speed from idea to implementation to deployment is amazing. --- -
+

CASE STUDY:
Ocado: Running Grocery Warehouses with a Cloud Native Platform

@@ -32,7 +32,7 @@ quote: >
- +

Impact

With Kubernetes, "the speed from idea to implementation to deployment is amazing," says Bryant. "I’ve seen features go from development to production inside of a week now. In the old world, a new application deployment could easily take over a month." And because there are no longer restrictive deployment windows in the warehouses, the rate of deployments has gone from as few as two per week to dozens per week. Ocado has also achieved cost savings because Kubernetes gives the team the ability to have more fine-grained resource allocation. Says DevOps Team Leader Kevin McCormack: "We have more confidence in the resource allocation/separation features of Kubernetes, so we have been able to migrate from around 10 fleet clusters to one Kubernetes cluster." The team also uses Prometheus and Grafana to visualize resource allocation, and makes the data available to developers. "The increased visibility offered by Prometheus means developers are more aware of what they are using and how their use impacts others, especially since we now have one shared cluster," says McCormack. "I’d estimate that we use about 15-25% less hardware resources to host the same applications in Kubernetes in our test environments." @@ -54,7 +54,7 @@ Bryant had already been using Kubernetes with +
"We were looking for a platform with wide adoption, and that was where the momentum was, the two paths converged, and we didn’t even go through any proof-of-concept stage. The Code for Life work served that purpose,"

- Kevin McCormack, DevOps Team Leader, Ocado
@@ -68,7 +68,7 @@ Bryant had already been using Kubernetes with +
"The unified API of Kubernetes means this is all in one place, and it’s one flow for approval and rollout. I’ve seen features go from development to production inside of a week now. In the old world, a new application deployment could easily take over a month."

- Mike Bryant, Platform Engineer, Ocado
diff --git a/content/ko/case-studies/openAI/index.html b/content/ko/case-studies/openAI/index.html index 040f704efa..1b95ec5f35 100644 --- a/content/ko/case-studies/openAI/index.html +++ b/content/ko/case-studies/openAI/index.html @@ -5,7 +5,7 @@ cid: caseStudies css: /css/style_case_studies.css --- -
+

CASE STUDY:
Launching and Scaling Up Experiments, Made Simple

@@ -56,7 +56,7 @@ css: /css/style_case_studies.css
-
+
OpenAI’s experiments take advantage of Kubernetes’ benefits, including portability. "Because Kubernetes provides a consistent API, we can move our research experiments very easily between clusters..." @@ -69,7 +69,7 @@ css: /css/style_case_studies.css
-
+
"One of our researchers who is working on a new distributed training system has been able to get his experiment running in two or three days," says Berner. "In a week or two he scaled it out to hundreds of GPUs. Previously, that would have easily been a couple of months of work."
diff --git a/content/ko/case-studies/pearson/index.html b/content/ko/case-studies/pearson/index.html index ddb567afb3..78f70228e5 100644 --- a/content/ko/case-studies/pearson/index.html +++ b/content/ko/case-studies/pearson/index.html @@ -8,7 +8,7 @@ featured: false quote: > We’re already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure. But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online. --- -
+

CASE STUDY:
Reinventing the World’s Largest Education Company With Kubernetes

@@ -47,7 +47,7 @@ quote: > The team adopted Kubernetes when it was still version 1.2 and are still going strong now on 1.7; they use Terraform and Ansible to deploy it on to basic AWS primitives. "We were trying to understand how we can create value for Pearson from this technology," says Ben Somogyi, Principal Architect for the Cloud Platforms. "It turned out that Kubernetes’ benefits are huge. We’re trying to help our applications development teams that use our platform go faster, so we filled that gap with a CI/CD pipeline that builds their images for them, standardizes them, patches everything up, allows them to deploy their different environments onto the cluster, and obfuscating the details of how difficult the work underneath the covers is."
-
+
"Your internal customers need to feel like they are choosing the very best option for them. We are experiencing this first hand in the growth of adoption. We are seeing triple-digit, year-on-year growth of the service."

— Chris Jackson, Director for Cloud Platforms & SRE at Pearson
@@ -60,7 +60,7 @@ quote: > Jackson estimates they’ve achieved a 15-20% boost in productivity for developer teams who adopt the platform. They also see a reduction in the number of customer-impacting incidents. Plus, says Jackson, "Teams who were previously limited to 1-2 releases per academic year can now ship code multiple times per day!"
-
+
"Teams who were previously limited to 1-2 releases per academic year can now ship code multiple times per day!"

— Chris Jackson, Director for Cloud Platforms & SRE at Pearson
diff --git a/content/ko/case-studies/pinterest/index.html b/content/ko/case-studies/pinterest/index.html index 0aa2381aa1..e4be7031bb 100644 --- a/content/ko/case-studies/pinterest/index.html +++ b/content/ko/case-studies/pinterest/index.html @@ -11,7 +11,7 @@ quote: > --- -
+

CASE STUDY:
Pinning Its Past, Present, and Future on Cloud Native

@@ -60,7 +60,7 @@ The first phase involved moving to Docker. "Pinterest has been heavily running o
-
+
"Though Kubernetes lacked certain things we wanted, we realized that by the time we get to productionizing many of those things, we’ll be able to leverage what the community is doing."

— MICHEAL BENEDICT, PRODUCT MANAGER FOR THE CLOUD AND THE DATA INFRASTRUCTURE GROUP AT PINTEREST
@@ -75,7 +75,7 @@ At the beginning of 2018, the team began onboarding its first use case into the
-
+
"So far it’s been good, especially the elasticity around how we can configure our Jenkins workloads on Kubernetes shared cluster. That is the win we were pushing for."

— MICHEAL BENEDICT, PRODUCT MANAGER FOR THE CLOUD AND THE DATA INFRASTRUCTURE GROUP AT PINTEREST
diff --git a/content/ko/case-studies/slingtv/index.html b/content/ko/case-studies/slingtv/index.html index a11527c2d9..349ed8c2de 100644 --- a/content/ko/case-studies/slingtv/index.html +++ b/content/ko/case-studies/slingtv/index.html @@ -11,7 +11,7 @@ quote: > --- -
+

CASE STUDY:
Sling TV: Marrying Kubernetes and AI to Enable Proper Web Scale

@@ -62,7 +62,7 @@ Led by the belief that “the cloud native architectures and patterns really giv
-
+
“We needed the flexibility to enable our use case versus just a simple orchestrater. Enabling our future in a way that did not give us vendor lock-in was also a key part of our strategy. I think that is part of the Rancher value proposition.”

— Brad Linder, Cloud Native & Big Data Evangelist for Sling TV
@@ -75,7 +75,7 @@ With the emphasis on common tooling, “We are getting to the place where we can
-
+
“We have to be able to react to changes and hiccups in the matrix. It is the foundation for our ability to deliver a high-quality service for our customers."

— Brad Linder, Cloud Native & Big Data Evangelist for Sling TV
diff --git a/content/ko/case-studies/squarespace/index.html b/content/ko/case-studies/squarespace/index.html index d2b2a18c92..27340835f4 100644 --- a/content/ko/case-studies/squarespace/index.html +++ b/content/ko/case-studies/squarespace/index.html @@ -5,7 +5,7 @@ cid: caseStudies css: /css/style_case_studies.css --- -
+

CASE STUDY:
Squarespace: Gaining Productivity and Resilience with Kubernetes

@@ -51,7 +51,7 @@ Since Squarespace moved to Kubernetes, in conjunction with modernizing its netwo
-
+
After experimenting with another container orchestration platform and "breaking it in very painful ways," Lynch says, the team began experimenting with Kubernetes in mid-2016 and found that it "answered all the questions that we had." @@ -68,7 +68,7 @@ Since Squarespace moved to Kubernetes, in conjunction with modernizing its netwo
-
+
"We switched to Kubernetes, a new world....It allowed us to streamline our process, so we can now easily create an entire microservice project from templates," Lynch says. And the whole process takes only five minutes, an almost 85% reduction in time compared to their VM deployment.
diff --git a/content/ko/case-studies/workiva/index.html b/content/ko/case-studies/workiva/index.html index 95f323d5ae..1c09503bfb 100644 --- a/content/ko/case-studies/workiva/index.html +++ b/content/ko/case-studies/workiva/index.html @@ -11,7 +11,7 @@ quote: > With OpenTracing, my team was able to look at a trace and make optimization suggestions to another team without ever looking at their code. --- -
+

CASE STUDY:
Using OpenTracing to Help Pinpoint the Bottlenecks

@@ -30,12 +30,12 @@ quote: > Workiva offers a cloud-based platform for managing and reporting business data. This SaaS product, Wdesk, is used by more than 70 percent of the Fortune 500 companies. As the company made the shift from a monolith to a more distributed, microservice-based system, "We had a number of people working on this, all on different teams, so we needed to identify what the issues were and where the bottlenecks were," says Senior Software Architect MacLeod Broad. With back-end code running on Google App Engine, Google Compute Engine, as well as Amazon Web Services, Workiva needed a tracing system that was agnostic of platform. While preparing one of the company’s first products utilizing AWS, which involved a "sync and link" feature that linked data from spreadsheets built in the new application with documents created in the old application on Workiva’s existing system, Broad’s team found an ideal use case for tracing: There were circular dependencies, and optimizations often turned out to be micro-optimizations that didn’t impact overall speed.
- +

Solution

- Broad’s team introduced the platform-agnostic distributed tracing system OpenTracing to help them pinpoint the bottlenecks. + Broad’s team introduced the platform-agnostic distributed tracing system OpenTracing to help them pinpoint the bottlenecks.

Impact

Now used throughout the company, OpenTracing produced immediate results. Software Engineer Michael Davis reports: "Tracing has given us immediate, actionable insight into how to improve our service. Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix." @@ -61,14 +61,14 @@ The challenges faced by Broad’s team may sound familiar to other companies tha
-
+
"A tracing system can at a glance explain an architecture, narrow down a performance bottleneck and zero in on it, and generally just help direct an investigation at a high level. Being able to do that at a glance is much faster than at a meeting or with three days of debugging, and it’s a lot faster than never figuring out the problem and just moving on."
— MACLEOD BROAD, SENIOR SOFTWARE ARCHITECT AT WORKIVA
- + Simply put, it was an ideal use case for tracing. "A tracing system can at a glance explain an architecture, narrow down a performance bottleneck and zero in on it, and generally just help direct an investigation at a high level," says Broad. "Being able to do that at a glance is much faster than at a meeting or with three days of debugging, and it’s a lot faster than never figuring out the problem and just moving on."

With Workiva’s back-end code running on Google Compute Engine as well as App Engine and AWS, Broad knew that he needed a tracing system that was platform agnostic. "We were looking at different tracing solutions," he says, "and we decided that because it seemed to be a very evolving market, we didn’t want to get stuck with one vendor. So OpenTracing seemed like the cleanest way to avoid vendor lock-in on what backend we actually had to use."

Once they introduced OpenTracing into this first use case, Broad says, "The trace made it super obvious where the bottlenecks were." Even though everyone had assumed it was Workiva’s existing code that was slowing things down, that wasn’t exactly the case. "It looked like the existing code was slow only because it was reaching out to our next-generation services, and they were taking a very long time to service all those requests," says Broad. "On the waterfall graph you can see the exact same work being done on every request when it was calling back in. So every service request would look the exact same for every response being paged out. And then it was just a no-brainer of, ‘Why is it doing all this work again?’"

@@ -78,7 +78,7 @@ Using the insight OpenTracing gave them, "My team was able to look at a trace an
-
+
"We were looking at different tracing solutions and we decided that because it seemed to be a very evolving market, we didn’t want to get stuck with one vendor. So OpenTracing seemed like the cleanest way to avoid vendor lock-in on what backend we actually had to use."
— MACLEOD BROAD, SENIOR SOFTWARE ARCHITECT AT WORKIVA
@@ -90,7 +90,7 @@ Using the insight OpenTracing gave them, "My team was able to look at a trace an Some teams were won over quickly. "Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service," says Software Engineer Michael Davis. "Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix."

Most of Workiva’s major products are now traced using OpenTracing, with data pushed into Google StackDriver. Even the products that aren’t fully traced have some components and libraries that are.

Broad points out that because some of the engineers were working on App Engine and already had experience with the platform’s Appstats library for profiling performance, it didn’t take much to get them used to using OpenTracing. But others were a little more reluctant. "The biggest hindrance to adoption I think has been the concern about how much latency is introducing tracing [and StackDriver] going to cost," he says. "People are also very concerned about adding middleware to whatever they’re working on. Questions about passing the context around and how that’s done were common. A lot of our Go developers were fine with it, because they were already doing that in one form or another. Our Java developers were not super keen on doing that because they’d used other systems that didn’t require that."

-But the benefits clearly outweighed the concerns, and today, Workiva’s official policy is to use tracing." +But the benefits clearly outweighed the concerns, and today, Workiva’s official policy is to use tracing." In fact, Broad believes that tracing naturally fits in with Workiva’s existing logging and metrics systems. "This was the way we presented it internally, and also the way we designed our use," he says. "Our traces are logged in the exact same mechanism as our app metric and logging data, and they get pushed the exact same way. So we treat all that data exactly the same when it’s being created and when it’s being recorded. We have one internal library that we use for logging, telemetry, analytics and tracing." @@ -98,7 +98,7 @@ In fact, Broad believes that tracing naturally fits in with Workiva’s existing
- "Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service. Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix."
— Michael Davis, Software Engineer, Workiva + "Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service. Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix."
— Michael Davis, Software Engineer, Workiva
diff --git a/content/ko/case-studies/ygrene/index.html b/content/ko/case-studies/ygrene/index.html index 498dc0ec73..c07443249a 100644 --- a/content/ko/case-studies/ygrene/index.html +++ b/content/ko/case-studies/ygrene/index.html @@ -12,7 +12,7 @@ quote: > We had to change some practices and code, and the way things were built, but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That’s very fast for a finance company. --- -
+

CASE STUDY:
Ygrene: Using Cloud Native to Bring Security and Scalability to the Finance Industry

@@ -61,7 +61,7 @@ By 2017, deployments and scalability had become pain points. The company was uti
-
+
"CNCF has been an amazing incubator for so many projects. Now we look at its webpage regularly to find out if there are any new, awesome, high-quality projects we can implement into our stack. It’s actually become a hub for us for knowing what software we need to be looking at to make our systems more secure or more scalable."

— Austin Adams, Development Manager, Ygrene Energy Fund
@@ -78,7 +78,7 @@ Notary, in particular, "has been a godsend," says Adams. "We need to know that o
-
+
"We had to change some practices and code, and the way things were built," Adams says, "but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That’s very fast for a finance company."
diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index 54782a20e3..7fb92302f9 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -324,7 +324,7 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 {{< feature-state state="alpha" for_k8s_version="v1.16" >}} `TopologyManager` -[기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)를 +[기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 시켜두면, kubelet이 리소스 할당 결정을 할 때 토폴로지 힌트를 사용할 수 있다. 자세한 내용은 [노드의 컨트롤 토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)을 본다. diff --git a/content/ko/docs/concepts/cluster-administration/logging.md b/content/ko/docs/concepts/cluster-administration/logging.md index 5c7ce6cd8d..4f516ed41e 100644 --- a/content/ko/docs/concepts/cluster-administration/logging.md +++ b/content/ko/docs/concepts/cluster-administration/logging.md @@ -78,7 +78,8 @@ kubectl logs counter 전자의 접근 방식은 다른 환경에서 사용된다. 두 경우 모두, 기본적으로 로그 파일이 10MB를 초과하면 로테이션이 되도록 구성된다. -예를 들어, `kube-up.sh` 가 해당 [스크립트][cosConfigureHelper]에서 +예를 들어, `kube-up.sh` 가 해당 +[스크립트](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)에서 GCP의 COS 이미지 로깅을 설정하는 방법에 대한 자세한 정보를 찾을 수 있다. 기본 로깅 예제에서와 같이 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs)를 @@ -93,8 +94,6 @@ GCP의 COS 이미지 로깅을 설정하는 방법에 대한 자세한 정보를 그 후 `kubectl logs` 는 빈 응답을 반환한다. {{< /note >}} -[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh - ### 시스템 컴포넌트 로그 시스템 컴포넌트에는 컨테이너에서 실행되는 것과 컨테이너에서 실행되지 않는 두 가지 유형이 있다. @@ -106,7 +105,7 @@ GCP의 COS 이미지 로깅을 설정하는 방법에 대한 자세한 정보를 systemd를 사용하는 시스템에서, kubelet과 컨테이너 런타임은 journald에 작성한다. systemd를 사용하지 않으면, `/var/log` 디렉터리의 `.log` 파일에 작성한다. 컨테이너 내부의 시스템 컴포넌트는 기본 로깅 메커니즘을 무시하고, -항상 `/var/log` 디렉터리에 기록한다. 그것은 [klog][klog] +항상 `/var/log` 디렉터리에 기록한다. 그것은 [klog](https://github.com/kubernetes/klog) 로깅 라이브러리를 사용한다. [로깅에 대한 개발 문서](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)에서 해당 컴포넌트의 로깅 심각도(severity)에 대한 규칙을 찾을 수 있다. @@ -115,8 +114,6 @@ systemd를 사용하지 않으면, `/var/log` 디렉터리의 `.log` 파일에 로그는 매일 또는 크기가 100MB를 초과하면 `logrotate` 도구에 의해 로테이트가 되도록 구성된다. -[klog]: https://github.com/kubernetes/klog - ## 클러스터 레벨 로깅 아키텍처 쿠버네티스는 클러스터-레벨 로깅을 위한 네이티브 솔루션을 제공하지 않지만, 고려해야 할 몇 가지 일반적인 접근 방법을 고려할 수 있다. 여기 몇 가지 옵션이 있다. diff --git a/content/ko/docs/concepts/cluster-administration/monitoring.md b/content/ko/docs/concepts/cluster-administration/monitoring.md new file mode 100644 index 0000000000..440da51dd8 --- /dev/null +++ b/content/ko/docs/concepts/cluster-administration/monitoring.md @@ -0,0 +1,129 @@ +--- +title: 쿠버네티스 컨트롤 플레인에 대한 메트릭 +content_type: concept +weight: 60 +aliases: +- controller-metrics.md +--- + + + +시스템 컴포넌트 메트릭으로 내부에서 발생하는 상황을 더 잘 파악할 수 있다. 메트릭은 대시보드와 경고를 만드는 데 특히 유용하다. + +쿠버네티스 컨트롤 플레인의 메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)으로 출력되며 사람이 읽기 쉽다. + + + + + +## 쿠버네티스의 메트릭 + +대부분의 경우 메트릭은 HTTP 서버의 `/metrics` 엔드포인트에서 사용할 수 있다. 기본적으로 엔드포인트를 노출하지 않는 컴포넌트의 경우 `--bind-address` 플래그를 사용하여 활성화할 수 있다. + +해당 컴포넌트의 예는 다음과 같다. + +* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} +* {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} +* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} +* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}} +* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} + +프로덕션 환경에서는 이러한 메트릭을 주기적으로 수집하고 시계열 데이터베이스에서 사용할 수 있도록 +[프로메테우스 서버](https://prometheus.io/) 또는 다른 메트릭 수집기(scraper)를 구성할 수 있다. + +참고로 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}도 `/metrics/cadvisor`, `/metrics/resource` 그리고 `/metrics/probes` 엔드포인트에서 메트릭을 노출한다. 이러한 메트릭은 동일한 라이프사이클을 가지지 않는다. + +클러스터가 {{< glossary_tooltip term_id="rbac" text="RBAC" >}}을 사용하는 경우, 메트릭을 읽으려면 `/metrics` 에 접근을 허용하는 클러스터롤(ClusterRole)을 가지는 사용자, 그룹 또는 서비스어카운트(ServiceAccount)를 통한 권한이 필요하다. +예를 들면, 다음과 같다. +``` +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: prometheus +rules: + - nonResourceURLs: + - "/metrics" + verbs: + - get +``` + +## 메트릭 라이프사이클 + +알파 메트릭 → 안정적인 메트릭 → 사용 중단된 메트릭 → 히든(hidden) 메트릭 → 삭제 + +알파 메트릭은 안정성을 보장하지 않는다. 따라서 언제든지 수정되거나 삭제될 수 있다. + +안정적인 메트릭은 변경되지 않는다는 보장을 할 수 있다. 특히 안정성은 다음을 의미한다. + +* 메트릭 자체는 삭제되거나 이름이 변경되지 않는다 +* 메트릭 유형은 수정되지 않는다 + +사용 중단된 메트릭은 메트릭이 결국 삭제된다는 것을 나타낸다. 어떤 버전을 찾으려면, 해당 메트릭이 어떤 쿠버네티스 버전에서부터 사용 중단될 것인지를 고려하는 내용을 포함하는 어노테이션을 확인해야 한다. + +사용 중단되기 전에는 아래와 같다. + +``` +# HELP some_counter this counts things +# TYPE some_counter counter +some_counter 0 +``` + +사용 중단된 이후에는 아래와 같다. + +``` +# HELP some_counter (Deprecated since 1.15.0) this counts things +# TYPE some_counter counter +some_counter 0 +``` + +메트릭이 일단 숨겨지면 기본적으로 메트릭은 수집용으로 게시되지 않는다. 히든 메트릭을 사용하려면, 관련 클러스터 컴포넌트의 구성을 오버라이드(override)해야 한다. + +메트릭이 삭제되면, 메트릭이 게시되지 않는다. 오버라이드해서 이를 변경할 수 없다. + + +## 히든 메트릭 표시 + +위에서 설명한 것처럼, 관리자는 특정 바이너리의 커맨드 라인 플래그를 통해 히든 메트릭을 활성화할 수 있다. 관리자가 지난 릴리스에서 사용 중단된 메트릭의 마이그레이션을 놓친 경우 관리자를 위한 임시방편으로 사용된다. + +`show-hidden-metrics-for-version` 플래그는 해당 릴리스에서 사용 중단된 메트릭을 보여주려는 버전을 사용한다. 버전은 xy로 표시되며, 여기서 x는 메이저(major) 버전이고, y는 마이너(minor) 버전이다. 패치 릴리스에서 메트릭이 사용 중단될 수 있지만, 패치 버전은 필요하지 않다. 그 이유는 메트릭 사용 중단 정책이 마이너 릴리스에 대해 실행되기 때문이다. + +플래그는 그 값으로 이전의 마이너 버전만 사용할 수 있다. 관리자가 이전 버전을 `show-hidden-metrics-for-version` 에 설정하면 이전 버전의 모든 히든 메트릭이 생성된다. 사용 중단 메트릭 정책을 위반하기 때문에 너무 오래된 버전은 허용되지 않는다. + +1.n 버전에서 사용 중단되었다고 가정한 메트릭 `A` 를 예로 들어보겠다. 메트릭 사용 중단 정책에 따르면, 다음과 같은 결론에 도달할 수 있다. + +* `1.n` 릴리스에서는 메트릭이 사용 중단되었으며, 기본적으로 생성될 수 있다. +* `1.n+1` 릴리스에서는 기본적으로 메트릭이 숨겨져 있으며, `show-hidden-metrics-for-version=1.n` 커맨드 라인에 의해서 생성될 수 있다. +* `1.n+2` 릴리스에서는 코드베이스에서 메트릭이 제거되어야 한다. 더이상 임시방편은 존재하지 않는다. + +릴리스 `1.12` 에서 `1.13` 으로 업그레이드 중이지만, `1.12` 에서 사용 중단된 메트릭 `A` 를 사용하고 있다면, 커맨드 라인에서 `--show-hidden-metrics=1.12` 플래그로 히든 메트릭을 설정해야 하고, `1.14` 로 업그레이드하기 전에 이 메트릭을 사용하지 않도록 의존성을 제거하는 것을 기억해야 한다. + +## 컴포넌트 메트릭 + +### kube-controller-manager 메트릭 + +컨트롤러 관리자 메트릭은 컨트롤러 관리자의 성능과 상태에 대한 중요한 인사이트를 제공한다. +이러한 메트릭에는 go_routine 수와 같은 일반적인 Go 언어 런타임 메트릭과 +etcd 요청 대기 시간 또는 Cloudprovider(AWS, GCE, OpenStack) API 대기 시간과 같은 컨트롤러 특정 메트릭이 포함되어 +클러스터의 상태를 측정하는 데 사용할 수 있다. + +쿠버네티스 1.7부터 GCE, AWS, Vsphere 및 OpenStack의 스토리지 운영에 대한 상세한 Cloudprovider 메트릭을 사용할 수 있다. +이 메트릭은 퍼시스턴트 볼륨 동작의 상태를 모니터링하는 데 사용할 수 있다. + +예를 들어, GCE의 경우 이러한 메트릭을 다음과 같이 호출한다. + +``` +cloudprovider_gce_api_request_duration_seconds { request = "instance_list"} +cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"} +cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"} +cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"} +cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"} +cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} +``` + + + +## {{% heading "whatsnext" %}} + +* 메트릭에 대한 [프로메테우스 텍스트 형식](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format)에 대해 읽어본다 +* [안정적인 쿠버네티스 메트릭](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml) 목록을 참고한다 +* [쿠버네티스 사용 중단 정책](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)에 대해 읽어본다 diff --git a/content/ko/docs/concepts/configuration/configmap.md b/content/ko/docs/concepts/configuration/configmap.md index 5031b06cf5..3b339ca18f 100644 --- a/content/ko/docs/concepts/configuration/configmap.md +++ b/content/ko/docs/concepts/configuration/configmap.md @@ -225,7 +225,7 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최 - immutable로 표시된 컨피그맵에 대한 감시를 중단하여, kube-apiserver의 부하를 크게 줄임으로써 클러스터의 성능을 향상시킴 이 기능을 사용하려면 `ImmutableEmphemeralVolumes` -[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하고 +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하고 시크릿 또는 컨피그맵의 `immutable` 필드를 `true` 로 한다. 다음은 예시이다. ```yaml apiVersion: v1 diff --git a/content/ko/docs/concepts/configuration/manage-resources-containers.md b/content/ko/docs/concepts/configuration/manage-resources-containers.md index 3c1414fcd6..42036c7da8 100644 --- a/content/ko/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ko/docs/concepts/configuration/manage-resources-containers.md @@ -292,7 +292,7 @@ kubelet은 사용 중인 로컬 스토리지 양을 측정할 수 있다. 이것 제공한다. - `LocalStorageCapacityIsolation` - [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)(이 + [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)(이 기능이 기본적으로 설정되어 있음)를 활성화하고, - 로컬 임시 스토리지에 대한 지원되는 구성 중 하나를 사용하여 노드를 설정한다. @@ -441,7 +441,7 @@ kubelet은 각 `emptyDir` 볼륨, 컨테이너 로그 디렉터리 및 쓰기 프로젝트 쿼터를 사용하려면, 다음을 수행해야 한다. * kubelet 구성에서 `LocalStorageCapacityIsolationFSQuotaMonitoring=true` - [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 + [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화한다. * 루트 파일시스템(또는 선택적인 런타임 파일시스템)에 diff --git a/content/ko/docs/concepts/configuration/pod-overhead.md b/content/ko/docs/concepts/configuration/pod-overhead.md index d4888ecbfb..2a08de53fb 100644 --- a/content/ko/docs/concepts/configuration/pod-overhead.md +++ b/content/ko/docs/concepts/configuration/pod-overhead.md @@ -32,7 +32,7 @@ _파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파 ## 파드 오버헤드 활성화하기 {#set-up} 기능 활성화를 위해 클러스터에서 -`PodOverhead` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 가 활성화 되어 있고 (1.18 버전에서는 기본적으로 활성화), +`PodOverhead` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있고(1.18 버전에서는 기본적으로 활성화), `overhead` 필드를 정의하는 `RuntimeClass` 가 사용되고 있는지 확인해야 한다. ## 사용 예제 diff --git a/content/ko/docs/concepts/configuration/pod-priority-preemption.md b/content/ko/docs/concepts/configuration/pod-priority-preemption.md index ac39ed6c94..e0d6317b29 100644 --- a/content/ko/docs/concepts/configuration/pod-priority-preemption.md +++ b/content/ko/docs/concepts/configuration/pod-priority-preemption.md @@ -160,7 +160,7 @@ description: "이 프라이어리티 클래스는 XYZ 서비스 파드에만 사 해당 프라이어리티클래스의 파드는 비-선점될 것이다. `PreemptionPolicy` 필드를 사용하려면 `NonPreemptingPriority` -[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)가 +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어야 한다. 예제 유스케이스는 데이터 과학 관련 워크로드이다. @@ -408,4 +408,3 @@ kubelet 리소스 부족 축출은 사용량이 요청을 초과하지 않는 ## {{% heading "whatsnext" %}} * 프라이어리티클래스와 관련하여 리소스쿼터 사용에 대해 [기본적으로 프라이어리티 클래스 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을 읽어보자. - diff --git a/content/ko/docs/concepts/containers/runtime-class.md b/content/ko/docs/concepts/containers/runtime-class.md index ea661af0c6..3da41dfde0 100644 --- a/content/ko/docs/concepts/containers/runtime-class.md +++ b/content/ko/docs/concepts/containers/runtime-class.md @@ -33,7 +33,7 @@ weight: 20 ## 셋업 런타임클래스 기능 게이트가 활성화(기본값)된 것을 확인한다. -기능 게이트 활성화에 대한 설명은 [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 +기능 게이트 활성화에 대한 설명은 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 참고한다. `RuntimeClass` 기능 게이트는 apiservers _및_ kubelets에서 활성화되어야 한다. 1. CRI 구현(implementation)을 노드에 설정(런타임에 따라서) @@ -135,9 +135,7 @@ https://github.com/containerd/cri/blob/master/docs/config.md runtime_path = "${PATH_TO_BINARY}" ``` -더 자세한 것은 CRI-O의 [설정 문서][100]를 본다. - -[100]: https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md +더 자세한 것은 CRI-O의 [설정 문서](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md)를 본다. ## 스케줄 @@ -146,7 +144,8 @@ https://github.com/containerd/cri/blob/master/docs/config.md 쿠버네티스 v1.16 부터, 런타임 클래스는 `scheduling` 필드를 통해 이종의 클러스터 지원을 포함한다. 이 필드를 사용하면, 이 런타임 클래스를 갖는 파드가 이를 지원하는 노드로 스케줄된다는 것을 보장할 수 있다. 이 스케줄링 기능을 사용하려면, -[런타임 클래스 어드미션(admission) 컨트롤러][]를 활성화(1.16 부터 기본값)해야 한다. +[런타임 클래스 어드미션(admission) 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#runtimeclass)를 +활성화(1.16 부터 기본값)해야 한다. 파드가 지정된 런타임클래스를 지원하는 노드에 안착한다는 것을 보장하려면, 해당 노드들은 `runtimeClass.scheduling.nodeSelector` 필드에서 선택되는 공통 레이블을 가져야한다. @@ -162,15 +161,13 @@ https://github.com/containerd/cri/blob/master/docs/config.md 노드 셀렉터와 톨러레이션 설정에 대해 더 배우려면 [노드에 파드 할당](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)을 참고한다. -[런타임클래스 어드미션 컨트롤러]: /docs/reference/access-authn-authz/admission-controllers/#runtimeclass - ### 파드 오버헤드 {{< feature-state for_k8s_version="v1.18" state="beta" >}} 파드 실행과 연관되는 _오버헤드_ 리소스를 지정할 수 있다. 오버헤드를 선언하면 클러스터(스케줄러 포함)가 파드와 리소스에 대한 결정을 내릴 때 처리를 할 수 있다. -PodOverhead를 사용하려면, PodOverhead [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) +PodOverhead를 사용하려면, PodOverhead [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 를 활성화 시켜야 한다. (기본으로 활성화 되어 있다.) 파드 오버헤드는 런타임 클래스에서 `overhead` 필드를 통해 정의된다. 이 필드를 사용하면, diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md index 53d925f891..db2eddb3d1 100644 --- a/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md +++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -27,7 +27,7 @@ Extension-apiserver는 kube-apiserver로 오가는 연결의 레이턴시가 낮 kube-apiserver로 부터의 디스커버리 요청은 왕복 레이턴시가 5초 이내여야 한다. extention API server가 레이턴시 요구 사항을 달성할 수 없는 경우 이를 충족할 수 있도록 변경하는 것을 고려한다. -`EnableAggregatedDiscoveryTimeout=false` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 설정해서 타임아웃 +`EnableAggregatedDiscoveryTimeout=false` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 설정해서 타임아웃 제한을 비활성화 할 수 있다. 이 사용 중단(deprecated)된 기능 게이트는 향후 릴리스에서 제거될 예정이다. @@ -39,4 +39,3 @@ extention API server가 레이턴시 요구 사항을 달성할 수 없는 경 * 다음에, [확장 API 서버를 구성해서](/docs/tasks/extend-kubernetes/setup-extension-api-server/) 애그리게이션 레이어와 연계한다. * 또한, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)를 배워본다. * [API 서비스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)의 사양을 읽어본다. - diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index bf4eb55898..bfdb7ef8c3 100644 --- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -181,7 +181,7 @@ gRPC 서비스는 `/var/lib/kubelet/pod-resources/kubelet.sock` 의 유닉스 `/var/lib/kubelet/pod-resources` 를 {{< glossary_tooltip text="볼륨" term_id="volume" >}}으로 마운트해야 한다. -"PodResources 서비스"를 지원하려면 `KubeletPodResources` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. 쿠버네티스 1.15부터 기본적으로 활성화되어 있다. +"PodResources 서비스"를 지원하려면 `KubeletPodResources` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. 쿠버네티스 1.15부터 기본적으로 활성화되어 있다. ## 토폴로지 관리자와 장치 플러그인 통합 @@ -229,6 +229,6 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi. * 장치 플러그인을 사용한 [GPU 리소스 스케줄링](/ko/docs/tasks/manage-gpus/scheduling-gpus/)에 대해 알아보기 -* 노드에서의 [확장 리소스 알리기](/docs/tasks/administer-cluster/extended-resource-node/)에 대해 배우기 +* 노드에서의 [확장 리소스 알리기](/ko/docs/tasks/administer-cluster/extended-resource-node/)에 대해 배우기 * 쿠버네티스에서 [TLS 수신에 하드웨어 가속](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) 사용에 대해 읽기 * [토폴로지 관리자](/docs/tasks/adminster-cluster/topology-manager/)에 대해 알아보기 diff --git a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md index c9125cbe3d..8abdacb09d 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md @@ -35,7 +35,7 @@ kubectl과 대시보드와 같은 많은 도구들로 쿠버네티스 오브젝 | Key | Description | Example | Type | | ----------------------------------- | --------------------- | -------- | ---- | | `app.kubernetes.io/name` | 애플리케이션 이름 | `mysql` | 문자열 | -| `app.kubernetes.io/instance` | 애플리케이션의 인스턴스를 식별하는 고유한 이름 | `wordpress-abcxzy` | 문자열 | +| `app.kubernetes.io/instance` | 애플리케이션의 인스턴스를 식별하는 고유한 이름 | `mysql-abcxzy` | 문자열 | | `app.kubernetes.io/version` | 애플리케이션의 현재 버전 (예: a semantic version, revision hash 등.) | `5.7.21` | 문자열 | | `app.kubernetes.io/component` | 아키텍처 내 구성요소 | `database` | 문자열 | | `app.kubernetes.io/part-of` | 이 애플리케이션의 전체 이름 | `wordpress` | 문자열 | @@ -49,7 +49,7 @@ kind: StatefulSet metadata: labels: app.kubernetes.io/name: mysql - app.kubernetes.io/instance: wordpress-abcxzy + app.kubernetes.io/instance: mysql-abcxzy app.kubernetes.io/version: "5.7.21" app.kubernetes.io/component: database app.kubernetes.io/part-of: wordpress diff --git a/content/ko/docs/concepts/policy/pod-security-policy.md b/content/ko/docs/concepts/policy/pod-security-policy.md index aa3e786af7..c0ccaea504 100644 --- a/content/ko/docs/concepts/policy/pod-security-policy.md +++ b/content/ko/docs/concepts/policy/pod-security-policy.md @@ -299,7 +299,7 @@ kubectl-user delete pod pause 약간 다르게 다시 시도해보자. ```shell -kubectl-user run pause --image=k8s.gcr.io/pause +kubectl-user create deployment pause --image=k8s.gcr.io/pause deployment "pause" created kubectl-user get pods diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md index 46ac05bf8e..3f5a05f4ee 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -162,13 +162,13 @@ DNS 정책은 파드별로 설정할 수 있다. - "`Default`": 파드는 파드가 실행되고 있는 노드로부터 네임 해석 설정(the name resolution configuration)을 상속받는다. 자세한 내용은 - [관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node)에서 + [관련 논의](/ko/docs/tasks/administer-cluster/dns-custom-nameservers/)에서 확인할 수 있다. - "`ClusterFirst`": "`www.kubernetes.io`"와 같이 클러스터 도메인 suffix 구성과 일치하지 않는 DNS 쿼리는 노드에서 상속된 업스트림 네임서버로 전달된다. 클러스터 관리자는 추가 스텁-도메인(stub-domain)과 업스트림 DNS 서버를 구축할 수 있다. 그러한 경우 DNS 쿼리를 어떻게 처리하는지에 대한 자세한 내용은 - [관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#effects-on-pods)에서 + [관련 논의](/ko/docs/tasks/administer-cluster/dns-custom-nameservers/)에서 확인할 수 있다. - "`ClusterFirstWithHostNet`": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인 "`ClusterFirstWithHostNet`"을 명시적으로 설정해야 한다. @@ -272,4 +272,4 @@ options ndots:5 DNS 구성 관리에 대한 지침은 -[DNS 서비스 구성](/docs/tasks/administer-cluster/dns-custom-nameservers/)에서 확인할 수 있다. +[DNS 서비스 구성](/ko/docs/tasks/administer-cluster/dns-custom-nameservers/)에서 확인할 수 있다. diff --git a/content/ko/docs/concepts/services-networking/dual-stack.md b/content/ko/docs/concepts/services-networking/dual-stack.md index a94aaad2d1..6efe70de75 100644 --- a/content/ko/docs/concepts/services-networking/dual-stack.md +++ b/content/ko/docs/concepts/services-networking/dual-stack.md @@ -39,7 +39,7 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음 ## IPv4/IPv6 이중 스택 활성화 -IPv4/IPv6 이중 스택을 활성화 하려면, 클러스터의 관련 구성요소에 대해 `IPv6DualStack` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 를 활성화 하고, 이중 스택 클러스터 네트워크 할당을 설정한다. +IPv4/IPv6 이중 스택을 활성화 하려면, 클러스터의 관련 구성요소에 대해 `IPv6DualStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 를 활성화 하고, 이중 스택 클러스터 네트워크 할당을 설정한다. * kube-apiserver: * `--feature-gates="IPv6DualStack=true"` @@ -105,5 +105,3 @@ IPv6가 활성화된 외부 로드 밸런서를 지원하는 클라우드 공급 * [IPv4/IPv6 이중 스택 확인](/docs/tasks/network/validate-dual-stack) 네트워킹 - - diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md index f10552c703..adcf9f9e9a 100644 --- a/content/ko/docs/concepts/services-networking/network-policies.md +++ b/content/ko/docs/concepts/services-networking/network-policies.md @@ -99,7 +99,7 @@ __egress__: 각 네트워크폴리시에는 화이트리스트 `egress` 규칙 * 172.17.0.0–172.17.0.255 와 172.17.2.0–172.17.255.255 의 범위를 가지는 IP 주소(예: 172.17.0.0/16 전체에서 172.17.1.0/24 를 제외) 3. (이그레스 규칙)은 "role=db" 레이블이 있는 "default" 네임스페이스의 모든 파드에서 TCP 포트 5978의 CIDR 10.0.0.0/24 로의 연결을 허용한다. -자세한 설명과 추가 예시는 [네트워크 정책 선언](/docs/tasks/administer-cluster/declare-network-policy/)을 본다. +자세한 설명과 추가 예시는 [네트워크 정책 선언](/ko/docs/tasks/administer-cluster/declare-network-policy/)을 본다. ## `to` 및 `from` 셀럭터의 동작 @@ -203,7 +203,7 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C {{< feature-state for_k8s_version="v1.12" state="alpha" >}} -이 기능을 사용하려면 사용자(또는 클러스터 관리자가) API 서버에 `--feature-gates=SCTPSupport=true,…` 를 사용해서 `SCTPSupport` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다. +이 기능을 사용하려면 사용자(또는 클러스터 관리자가) API 서버에 `--feature-gates=SCTPSupport=true,…` 를 사용해서 `SCTPSupport` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다. 기능 게이트가 활셩화 되면, 네트워크폴리시의 `protocol` 필드를 `SCTP` 로 설정할 수 있다. {{< note >}} @@ -217,5 +217,5 @@ SCTP 프로토콜 네트워크폴리시를 지원하는 {{< glossary_tooltip tex - 자세한 설명과 추가 예시는 - [네트워크 정책 선언](/docs/tasks/administer-cluster/declare-network-policy/)을 본다. + [네트워크 정책 선언](/ko/docs/tasks/administer-cluster/declare-network-policy/)을 본다. - 네트워크폴리시 리소스에서 사용되는 일반적인 시나리오는 [레시피](https://github.com/ahmetb/kubernetes-network-policy-recipes)를 본다. diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index 4779d0504c..429708e4bf 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -208,7 +208,7 @@ AppProtocol 필드는 각 서비스 포트에 사용될 애플리케이션 프 지정하는 방법을 제공한다. 알파 기능으로 이 필드는 기본적으로 활성화되어 있지 않다. 이 필드를 사용하려면, -[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)에서 +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에서 `ServiceAppProtocol` 을 활성화해야 한다. ## 가상 IP와 서비스 프록시 diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index 0e418f414b..c5a09d23e9 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -132,7 +132,7 @@ Events: #### Delete(삭제) -`Delete` 반환 정책을 지원하는 볼륨 플러그인의 경우, 삭제는 쿠버네티스에서 퍼시스턴트볼륨 오브젝트와 외부 인프라(예: AWS EBS, GCE PD, Azure Disk 또는 Cinder 볼륨)의 관련 스토리지 자산을 모두 삭제한다. 동적으로 프로비저닝된 볼륨은 [스토리지클래스의 반환 정책](#반환-정책)을 상속하며 기본값은 `Delete`이다. 관리자는 사용자의 기대에 따라 스토리지클래스를 구성해야 한다. 그렇지 않으면 PV를 생성한 후 PV를 수정하거나 패치해야 한다. [퍼시스턴트볼륨의 반환 정책 변경](/docs/tasks/administer-cluster/change-pv-reclaim-policy/)을 참고하길 바란다. +`Delete` 반환 정책을 지원하는 볼륨 플러그인의 경우, 삭제는 쿠버네티스에서 퍼시스턴트볼륨 오브젝트와 외부 인프라(예: AWS EBS, GCE PD, Azure Disk 또는 Cinder 볼륨)의 관련 스토리지 자산을 모두 삭제한다. 동적으로 프로비저닝된 볼륨은 [스토리지클래스의 반환 정책](#반환-정책)을 상속하며 기본값은 `Delete`이다. 관리자는 사용자의 기대에 따라 스토리지클래스를 구성해야 한다. 그렇지 않으면 PV를 생성한 후 PV를 수정하거나 패치해야 한다. [퍼시스턴트볼륨의 반환 정책 변경](/ko/docs/tasks/administer-cluster/change-pv-reclaim-policy/)을 참고하길 바란다. #### Recycle(재활용) @@ -228,7 +228,7 @@ FlexVolume은 파드 재시작 시 크기를 조정할 수 있다. {{< feature-state for_k8s_version="v1.15" state="beta" >}} {{< note >}} -사용 중인 PVC 확장은 쿠버네티스 1.15 이후 버전에서는 베타로, 1.11 이후 버전에서는 알파로 제공된다. `ExpandInUsePersistentVolumes` 기능을 사용하도록 설정해야 한다. 베타 기능의 경우 여러 클러스터에서 자동으로 적용된다. 자세한 내용은 [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 문서를 참고한다. +사용 중인 PVC 확장은 쿠버네티스 1.15 이후 버전에서는 베타로, 1.11 이후 버전에서는 알파로 제공된다. `ExpandInUsePersistentVolumes` 기능을 사용하도록 설정해야 한다. 베타 기능의 경우 여러 클러스터에서 자동으로 적용된다. 자세한 내용은 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 문서를 참고한다. {{< /note >}} 이 경우 기존 PVC를 사용하는 파드 또는 디플로이먼트를 삭제하고 다시 만들 필요가 없다. diff --git a/content/ko/docs/concepts/storage/storage-limits.md b/content/ko/docs/concepts/storage/storage-limits.md new file mode 100644 index 0000000000..302161dbd7 --- /dev/null +++ b/content/ko/docs/concepts/storage/storage-limits.md @@ -0,0 +1,75 @@ +--- +title: 노드 별 볼륨 한도 +content_type: concept +--- + + + +이 페이지는 다양한 클라우드 공급자들이 제공하는 노드에 연결할 수 있는 +최대 볼륨 수를 설명한다. + +Google, Amazon 그리고 Microsoft와 같은 클라우드 공급자는 일반적으로 노드에 +연결할 수 있는 볼륨 수에 제한이 있다. 쿠버네티스가 이러한 제한을 +준수하는 것은 중요하다. 그렇지 않으면, 노드에서 예약된 파드가 볼륨이 +연결될 때까지 멈추고 기다릴 수 있다. + + + + + +## 쿠버네티스 기본 한도 + +쿠버네티스 스케줄러에는 노드에 연결될 수 있는 볼륨 수에 대한 +기본 한도가 있다. + + + + + + +
클라우드 서비스노드 당 최대 볼륨
Amazon Elastic Block Store (EBS)39
Google Persistent Disk16
Microsoft Azure Disk Storage16
+ +## 사용자 정의 한도 + +`KUBE_MAX_PD_VOLS` 환경 변수의 값을 설정한 후, +스케줄러를 시작하여 이러한 한도를 변경할 수 있다. +CSI 드라이버는 절차가 다를 수 있으므로, 한도를 사용자 정의하는 +방법에 대한 문서를 참고한다. + +기본 한도보다 높은 한도를 설정한 경우 주의한다. 클라우드 +공급자의 문서를 참조하여 노드가 실제로 사용자가 설정한 한도를 +지원할 수 있는지 확인한다. + +한도는 전체 클러스터에 적용되므로, 모든 노드에 영향을 준다. + +## 동적 볼륨 한도 + +{{< feature-state state="stable" for_k8s_version="v1.17" >}} + +다음 볼륨 유형에 대해 동적 볼륨 한도가 지원된다. + +- Amazon EBS +- Google Persistent Disk +- Azure Disk +- CSI + +인-트리(in-tree) 볼륨 플러그인으로 관리되는 볼륨의 경우, 쿠버네티스는 자동으로 노드 유형을 +결정하고 노드에 적절한 최대 볼륨 수를 적용한다. 예를 들면, 다음과 같다. + +* Google Compute Engine에서는, +[노드 유형에 따라](https://cloud.google.com/compute/docs/disks/#pdnumberlimits) +최대 127개의 볼륨까지 +노드에 연결할 수 있다. + +* M5, C5, R5, T3와 Z1D 인스턴스 유형의 Amazon EBS 디스크의 경우, 쿠버네티스는 25개의 볼륨만 노드에 +연결할 수 있도록 허용한다. +Amazon Elastic Compute Cloud (EC2)의 +다른 인스턴스 유형의 경우, 쿠버네티스는 노드에 39개의 볼륨을 연결할 수 있도록 허용한다. + +* Azure에서는, 노드 유형에 따라 최대 64개의 디스크를 노드에 연결할 수 있다. 더 자세한 내용은 [Azure의 가상 머신 크기](https://docs.microsoft.com/ko-kr/azure/virtual-machines/windows/sizes)를 참고한다. + +* CSI 스토리지 드라이버가 `NodeGetInfo` 를 사용해서 노드에 대한 최대 볼륨 수를 알린다면, {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}는 그 한도를 따른다. + +자세한 내용은 [CSI 명세](https://github.com/container-storage-interface/spec/blob/master/spec.md#nodegetinfo)를 참고한다. + +* CSI 드라이버로 마이그레이션된 인-트리 플러그인으로 관리되는 볼륨의 경우, 최대 볼륨 수는 CSI 드라이버가 보고한 개수이다. diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index ce31b183a4..c93cc5018e 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -779,7 +779,7 @@ iSCSI 볼륨와 같은)를 "클레임" 할 수 있는 방법이다. 서비스 어카운트 토큰의 프로젝션은 쿠버네티스 1.11에 기능이 도입되었고 1.12에서 베타로 승격되었다. 1.11에서 이 기능을 활성화 하려면 `TokenRequestProjection` -[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 True로 명시적인 설정이 필요하다. #### 시크릿, downward API 그리고 configmap이 있는 파드 예시. @@ -1197,7 +1197,7 @@ spec: `subPathExpr` 필드를 사용해서 Downward API 환경 변수로부터 `subPath` 디렉터리 이름을 구성한다. -이 기능을 사용하려면 `VolumeSubpathEnvExpansion` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다. 쿠버네티스 1.15에서는 시작 시 기본적으로 활성화되어 있다. +이 기능을 사용하려면 `VolumeSubpathEnvExpansion` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다. 쿠버네티스 1.15에서는 시작 시 기본적으로 활성화되어 있다. `subPath` 와 `subPathExpr` 속성은 상호 배타적이다. 이 예제는 파드가 `subPathExpr` 을 사용해서 Downward API로부터 파드 이름을 사용해서 hostPath 볼륨 `/var/log/pods` 내에 `pod1` 디렉터리를 생성한다. 호스트 디렉터리 `/var/log/pods/pod1` 은 컨테이너의 `/logs` 에 마운트 된다. diff --git a/content/ko/docs/concepts/workloads/controllers/job.md b/content/ko/docs/concepts/workloads/controllers/job.md index f203befbad..7b48a96c67 100644 --- a/content/ko/docs/concepts/workloads/controllers/job.md +++ b/content/ko/docs/concepts/workloads/controllers/job.md @@ -211,9 +211,9 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고 이렇게 하려면 `.spec.backoffLimit` 에 잡을 실패로 간주하기 이전에 재시도할 횟수를 설정한다. 백오프 제한은 기본적으로 6으로 설정되어 있다. 잡과 관련한 실패한 파드는 최대 6분안에서 기하급수적으로 증가하는 백-오프 지연 (10초, 20초, 40초 ...) -한도가 되어 잡 컨트롤러에 의해 재생성 된다. 잡의 다음 상태 -확인 이전에 새로 실패한 파드가 표시되지 않으면 백 오프 -카운트가 재설정 된다. +한도가 되어 잡 컨트롤러에 의해 재생성된다. 잡의 파드가 삭제되거나 +해당 시간 동안 잡에 대한 다른 파드가 실패 없이 성공했을 때 백 오프 +카운트가 재설정된다. {{< note >}} 1.12 이전 버전의 쿠버네티스 버전에 대해 여전히 [#54870](https://github.com/kubernetes/kubernetes/issues/54870) 이슈가 있다. diff --git a/content/ko/docs/concepts/workloads/controllers/replicaset.md b/content/ko/docs/concepts/workloads/controllers/replicaset.md index 18c618a6b1..a23c3605cf 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ko/docs/concepts/workloads/controllers/replicaset.md @@ -346,7 +346,7 @@ kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50 ### 잡 -스스로 종료되는 것이 예상되는 파드의 경우에는 레플리카셋 대신 [`잡`](/docs/concepts/jobs/run-to-completion-finite-workloads/)을 이용한다 +스스로 종료되는 것이 예상되는 파드의 경우에는 레플리카셋 대신 [`잡`](/ko/docs/concepts/workloads/controllers/job/)을 이용한다 (즉, 배치 잡). ### 데몬셋 diff --git a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md index 53ff69b288..c2414d9fdd 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md @@ -269,7 +269,7 @@ API 오브젝트에 대한 더 자세한 것은 ### 잡 자체적으로 제거될 것으로 예상되는 파드 (즉, 배치 잡)의 경우 -레플리케이션 컨트롤러 대신 [`잡`](/docs/concepts/jobs/run-to-completion-finite-workloads/)을 사용하라. +레플리케이션 컨트롤러 대신 [`잡`](/ko/docs/concepts/workloads/controllers/job/)을 사용하라. ### 데몬셋 diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md index 06cdbdc5e3..d588276b25 100644 --- a/content/ko/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md @@ -134,6 +134,18 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있 일치되는 DNS 서브도메인을 가지며, 여기서 거버닝 서비스(governing service)는 스테이트풀셋의 `serviceName` 필드에 의해 정의된다. +클러스터에서 DNS가 구성된 방식에 따라, 새로 실행된 파드의 DNS 이름을 +즉시 찾지 못할 수 있다. 이 동작은 클러스터의 다른 클라이언트가 +파드가 생성되기 전에 파드의 호스트 이름에 대한 쿼리를 이미 보낸 경우에 발생할 수 있다. +네거티브 캐싱(DNS에서 일반적)은 이전에 실패한 조회 결과가 +파드가 실행된 후에도 적어도 몇 초 동안 기억되고 재사용됨을 의미한다. + +파드를 생성한 후 즉시 파드를 검색해야 하는 경우, 몇 가지 옵션이 있다. + +- DNS 조회에 의존하지 않고 쿠버네티스 API를 직접(예를 들어 watch 사용) 쿼리한다. +- 쿠버네티스 DNS 공급자의 캐싱 시간(일반적으로 CoreDNS의 컨피그맵을 편집하는 것을 의미하며, 현재 30초 동안 캐시함)을 줄인다. + + [제한사항](#제한사항) 섹션에서 언급한 것처럼 사용자는 파드의 네트워크 신원을 책임지는 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 생성할 책임이 있다. diff --git a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md index 99d274a00d..3d110ee6c6 100644 --- a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -16,7 +16,7 @@ TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을 알파(Alpha) 고지 사항: 이 기능은 현재 알파이고, kube-apiserver와 kube-controller-manager와 함께 -[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)로 `TTLAfterFinished` 를 활성화할 수 있다. +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)로 `TTLAfterFinished` 를 활성화할 수 있다. diff --git a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md index 1e8a54fff9..20977e4e94 100644 --- a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md @@ -8,9 +8,9 @@ weight: 80 {{< feature-state state="alpha" for_k8s_version="v1.16" >}} -이 페이지는 임시 컨테이너에 대한 개요를 제공한다: 이 특별한 유형의 컨테이너는 -트러블 슈팅과 같은 사용자가 시작한 작업을 완료하기위해 기존 {{< glossary_tooltip text="파드" term_id="pod" >}} 에서 -임시적으로 실행된다. 사용자는 애플리케이션 빌드보다는 서비스를 점검할 때 임시 +이 페이지는 임시 컨테이너에 대한 개요를 제공한다: 이 특별한 유형의 컨테이너는 +트러블 슈팅과 같은 사용자가 시작한 작업을 완료하기위해 기존 {{< glossary_tooltip text="파드" term_id="pod" >}} 에서 +임시적으로 실행된다. 사용자는 애플리케이션 빌드보다는 서비스를 점검할 때 임시 컨테이너를 사용한다. {{< warning >}} @@ -82,7 +82,7 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지 {{< note >}} 이 섹션의 예시는 `EphemeralContainers` [기능 -게이트](/docs/reference/command-line-tools-reference/feature-gates/)의 +게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)의 활성화를 필요로 하고, 쿠버네티스 클라이언트와 서버는 v1.16 또는 이후의 버전이어야 한다. {{< /note >}} diff --git a/content/ko/docs/concepts/workloads/pods/init-containers.md b/content/ko/docs/concepts/workloads/pods/init-containers.md index 10baf43a7c..8d0ca2008a 100644 --- a/content/ko/docs/concepts/workloads/pods/init-containers.md +++ b/content/ko/docs/concepts/workloads/pods/init-containers.md @@ -322,4 +322,4 @@ myapp-pod 1/1 Running 0 9m * [초기화 컨테이너를 가진 파드 생성하기](/ko/docs/tasks/configure-pod-container/configure-pod-initialization/#초기화-컨테이너를-갖는-파드-생성) -* [초기화 컨테이너 디버깅](/docs/tasks/debug-application-cluster/debug-init-containers/) 알아보기 +* [초기화 컨테이너 디버깅](/ko/docs/tasks/debug-application-cluster/debug-init-containers/) 알아보기 diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index 470970f284..379266e351 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -90,7 +90,7 @@ kubelet은 컨테이너에 의해서 구현된 * [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core) 은 지정한 포트 및 경로에서 컨테이너의 IP주소에 - 대한 HTTP Get 요청을 수행한다. 응답의 상태 코드가 200보다 크고 400보다 작으면 + 대한 HTTP Get 요청을 수행한다. 응답의 상태 코드가 200 이상 400 미만이면 진단이 성공한 것으로 간주한다. 각 probe는 다음 세 가지 결과 중 하나를 가진다. diff --git a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index 8a81e708dd..d92b18a1bf 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -20,7 +20,7 @@ weight: 50 를 참조한다. {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} **와** {{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}에 대해 -`EvenPodsSpread` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)가 +`EvenPodsSpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어야 한다. ### 노드 레이블 @@ -244,5 +244,3 @@ profiles: - 디플로이먼트를 스케일링 다운하면 그 결과로 파드의 분포가 불균형이 될 수 있다. - 파드와 일치하는 테인트(taint)가 된 노드가 존중된다. [이슈 80921](https://github.com/kubernetes/kubernetes/issues/80921)을 본다. - - diff --git a/content/ko/docs/contribute/_index.md b/content/ko/docs/contribute/_index.md index 9034f3d98b..714ae70f36 100644 --- a/content/ko/docs/contribute/_index.md +++ b/content/ko/docs/contribute/_index.md @@ -28,41 +28,62 @@ card: ## 시작하기 -누구든지 문서에 대한 이슈를 오픈 또는 풀 리퀘스트(PR)를 사용해서 [`kubernetes/website` GitHub 리포지터리](https://github.com/kubernetes/website)에 변경하는 기여를 할 수 있습니다. 당신이 쿠버네티스 커뮤니티에 효과적으로 기여하려면 [git](https://git-scm.com/)과 [GitHub](https://lab.github.com/)에 익숙해야 합니다. +누구든지 문서에 대한 이슈를 오픈 또는 풀 리퀘스트(PR)를 사용해서 +[`kubernetes/website` GitHub 리포지터리](https://github.com/kubernetes/website)에 +변경하는 기여를 할 수 있습니다. +쿠버네티스 커뮤니티에 효과적으로 기여하려면 +[git](https://git-scm.com/)과 +[GitHub](https://lab.github.com/)에 +익숙해야 합니다. 문서에 참여하려면 1. CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md)에 서명합니다. -2. [문서 리포지터리](https://github.com/kubernetes/website) 와 웹사이트의 [정적 사이트 생성기](https://gohugo.io)를 숙지합니다. -3. [풀 리퀘스트 열기](/ko/docs/contribute/new-content/new-content/)와 [변경 검토](/ko/docs/contribute/review/reviewing-prs/)의 기본 프로세스를 이해하도록 합니다. +1. [문서 리포지터리](https://github.com/kubernetes/website)와 웹사이트의 + [정적 사이트 생성기](https://gohugo.io)를 숙지합니다. +1. [풀 리퀘스트 열기](/ko/docs/contribute/new-content/new-content/)와 + [변경 검토](/ko/docs/contribute/review/reviewing-prs/)의 + 기본 프로세스를 이해하도록 합니다. 일부 작업에는 쿠버네티스 조직에서 더 많은 신뢰와 더 많은 접근이 필요할 수 있습니다. 역할과 권한에 대한 자세한 내용은 -[SIG Docs 참여](/ko/docs/contribute/participating/)를 봅니다. +[SIG Docs 참여](/ko/docs/contribute/participate/)를 봅니다. ## 첫 번째 기여 -- [기여 개요](/ko/docs/contribute/new-content/overview/)를 읽고 기여할 수 있는 다양한 방법에 대해 알아봅니다. -- [kubernetes/website에 기여하기](https://github.com/kubernetes/website/contribute)를 참조하여 좋은 진입점이 되는 이슈를 찾을 수 있습니다. -- 기존 문서에 대해 [GitHub을 사용해서 풀 리퀘스트 열거나](/ko/docs/contribute/new-content/new-content/#github을-사용하여-변경하기) GitHub에서의 이슈 제기에 대해 자세히 알아봅니다. -- 정확성과 언어에 대해 다른 쿠버네티스 커뮤니티 맴버의 [풀 리퀘스트 검토](/ko/docs/contribute/review/reviewing-prs/)를 합니다. -- 쿠버네티스 [콘텐츠](/docs/contribute/style/content-guide/)와 [스타일 가이드](/docs/contribute/style/style-guide/)를 읽고 정보에 대한 코멘트를 남길 수 있습니다. -- [페이지 템플릿 사용](/docs/contribute/style/page-content-types/)과 [휴고(Hugo) 단축코드(shortcodes)](/docs/contribute/style/hugo-shortcodes/)를 사용해서 큰 변경을 하는 방법에 대해 배워봅니다. +- [기여 개요](/ko/docs/contribute/new-content/overview/)를 읽고 + 기여할 수 있는 다양한 방법에 대해 알아봅니다. +- [kubernetes/website에 기여하기](https://github.com/kubernetes/website/contribute)를 + 참조하여 좋은 진입점이 되는 이슈를 찾을 수 있습니다. +- 기존 문서에 대해 [GitHub을 사용해서 풀 리퀘스트 열거나](/ko/docs/contribute/new-content/new-content/#github을-사용하여-변경하기) + GitHub에서의 이슈 제기에 대해 자세히 알아봅니다. +- 정확성과 언어에 대해 다른 쿠버네티스 커뮤니티 맴버의 + [풀 리퀘스트 검토](/ko/docs/contribute/review/reviewing-prs/)를 합니다. +- 쿠버네티스 [콘텐츠](/docs/contribute/style/content-guide/)와 + [스타일 가이드](/docs/contribute/style/style-guide/)를 읽고 정보에 대한 코멘트를 남길 수 있습니다. +- [페이지 콘텐츠 유형](/docs/contribute/style/page-content-types/)과 + [휴고(Hugo) 단축코드(shortcodes)](/docs/contribute/style/hugo-shortcodes/)에 대해 배워봅니다. ## 다음 단계 -- 리포지터리의 [로컬 복제본에서 작업](/ko/docs/contribute/new-content/new-content/#fork-the-repo)하는 방법을 배워봅니다. +- 리포지터리의 [로컬 복제본에서 작업](/ko/docs/contribute/new-content/new-content/#fork-the-repo)하는 + 방법을 배워봅니다. - [릴리스된 기능](/docs/contribute/new-content/new-features/)을 문서화 합니다. -- [SIG Docs](/ko/docs/contribute/participating/)에 참여하고, [멤버 또는 검토자](/ko/docs/contribute/participating/#역할과-책임)가 되어봅니다. +- [SIG Docs](/ko/docs/contribute/participate/)에 참여하고, + [멤버 또는 검토자](/ko/docs/contribute/participate/roles-and-responsibilities/)가 되어봅니다. + - [현지화](/ko/docs/contribute/localization_ko/)를 시작하거나 도와줍니다. ## SIG Docs에 참여 -[SIG Docs](/ko/docs/contribute/participating/)는 쿠버네티스 문서와 웹 사이트를 게시하고 관리하는 기여자 그룹입니다. SIG Docs에 참여하는 것은 쿠버네티스 기여자(기능 개발 및 다른 여러가지)가 쿠버네티스 프로젝트에 가장 큰 영향을 미칠 수 있는 좋은 방법입니다. +[SIG Docs](/ko/docs/contribute/participate/)는 쿠버네티스 문서와 웹 사이트를 게시하고 +관리하는 기여자 그룹입니다. SIG Docs에 참여하는 것은 +쿠버네티스 기여자(기능 개발 및 다른 여러가지)가 쿠버네티스 프로젝트에 가장 큰 영향을 +미칠 수 있는 좋은 방법입니다. SIG Docs는 여러가지 방법으로 의견을 나누고 있습니다. -- [쿠버네티스 슬랙 인스턴스에서 `#sig-docs` 에 가입](http://slack.k8s.io/)을 하고, +- [쿠버네티스 슬랙 인스턴스에서 `#sig-docs` 에 가입](https://slack.k8s.io/)하고, 자신을 소개하세요! - 더 광범위한 토론이 이루어지고 공식적인 결정이 기록이 되는 [`kubernetes-sig-docs` 메일링 리스트에 가입](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) 하세요. diff --git a/content/ko/docs/contribute/advanced.md b/content/ko/docs/contribute/advanced.md index 55661a6734..21337a785e 100644 --- a/content/ko/docs/contribute/advanced.md +++ b/content/ko/docs/contribute/advanced.md @@ -19,7 +19,8 @@ weight: 98 ## 개선 제안 -SIG Docs [멤버](/ko/docs/contribute/participating/#멤버)는 개선을 제안할 수 있다. +SIG Docs [멤버](/ko/docs/contribute/participate/roles-and-responsibilities/#멤버)는 +개선을 제안할 수 있다. 한 동안 쿠버네티스 문서에 기여한 후에, [스타일 가이드](/docs/contribute/style/style-guide/), @@ -42,12 +43,12 @@ website 스타일, 풀 리퀘스트 리뷰와 병합 ## 쿠버네티스 릴리스를 위한 문서 조정 -SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 쿠버네티스 -릴리스에 대한 문서를 조정할 수 있다. +SIG Docs [승인자](/ko/docs/contribute/participate/roles-and-responsibilities/#승인자)는 +쿠버네티스 릴리스에 대한 문서를 조정할 수 있다. 각 쿠버네티스 릴리스는 sig-release SIG(Special Interest Group)에 참여하는 사람들의 팀에 의해 조정된다. 특정 릴리스에 대한 릴리스 팀의 다른 구성원에는 -전체 릴리스 리드와 sig-pm, sig-testing 및 기타 담당자가 +전체 릴리스 리드와 sig-testing 및 기타 담당자가 포함된다. 쿠버네티스 릴리스 프로세스에 대한 자세한 내용은 [https://github.com/kubernetes/sig-release](https://github.com/kubernetes/sig-release)를 참고한다. @@ -73,8 +74,8 @@ SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 쿠버네 ## 새로운 기여자 홍보대사로 봉사 -SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 새로운 기여자 -홍보대사로 활동할 수 있다. +SIG Docs [승인자](/ko/docs/contribute/participate/roles-and-responsibilities/#승인자)는 +새로운 기여자 홍보대사로 활동할 수 있다. 새로운 기여자 홍보대사는 SIG-Docs에 기여한 새 기여자를 환영하고, 새 기여자에게 PR을 제안하고, 첫 몇 번의 PR 제출을 통해 @@ -92,12 +93,12 @@ SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 새로운 ## 새로운 기여자 후원 -SIG Docs [리뷰어](/ko/docs/contribute/participating/#리뷰어)는 새로운 기여자를 -후원할 수 있다. +SIG Docs [리뷰어](/ko/docs/contribute/participate/roles-and-responsibilities/#리뷰어)는 +새로운 기여자를 후원할 수 있다. 새로운 기여자가 하나 이상의 쿠버네티스 리포지터리에 5개의 실질적인 풀 리퀘스트를 성공적으로 제출한 후에는 -쿠버네티스 조직의 [멤버십](/ko/docs/contribute/participating#멤버)을 +쿠버네티스 조직의 [멤버십](/ko/docs/contribute/participate/roles-and-responsibilities/#멤버)을 신청할 수 있다. 기여자의 멤버십은 이미 리뷰어인 두 명의 스폰서가 후원해야 한다. @@ -111,7 +112,8 @@ SIG Docs [리뷰어](/ko/docs/contribute/participating/#리뷰어)는 새로운 ## SIG 공동 의장으로 봉사 -SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 SIG Docs의 공동 의장 역할을 할 수 있다. +SIG Docs [승인자](/ko/docs/contribute/participate/roles-and-responsibilities/#승인자)는 +SIG Docs의 공동 의장 역할을 할 수 있다. ### 전제 조건 @@ -120,7 +122,12 @@ SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 SIG Docs - 6개월 이상 SIG Docs 승인자로 활동한다. - [쿠버네티스 문서 릴리스 주도](/ko/docs/contribute/advanced/#쿠버네티스-릴리스를-위한-문서-조정) 또는 두 개의 릴리스에서 섀도잉을 수행한다. - SIG Docs 워크플로와 툴링을 이해한다(git, Hugo, 현지화, 블로그 하위 프로젝트). -- [k/org의 팀](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), [k/community의 프로세스](https://github.com/kubernetes/community/tree/master/sig-docs), [k/test-infra](https://github.com/kubernetes/test-infra/)의 플러그인 및 [SIG 아키텍처](https://github.com/kubernetes/community/tree/master/sig-architecture)의 역할을 포함하여 다른 쿠버네티스 SIG와 리포지터리가 SIG Docs 워크플로에 미치는 영향을 이해한다. +- [k/org의 팀](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), + [k/community의 프로세스](https://github.com/kubernetes/community/tree/master/sig-docs), + [k/test-infra](https://github.com/kubernetes/test-infra/)의 플러그인 및 + [SIG 아키텍처](https://github.com/kubernetes/community/tree/master/sig-architecture)의 + 역할을 포함하여 다른 쿠버네티스 SIG와 리포지터리가 SIG Docs 워크플로에 미치는 + 영향을 이해한다. - 최소 6개월 동안 일주일에 5시간 이상(대부분 더)을 역할에 책임진다. ### 책임 diff --git a/content/ko/docs/contribute/localization_ko.md b/content/ko/docs/contribute/localization_ko.md index f6e0ae13b7..59cde62dea 100644 --- a/content/ko/docs/contribute/localization_ko.md +++ b/content/ko/docs/contribute/localization_ko.md @@ -187,7 +187,7 @@ API 오브젝트의 필드 이름, 파일 이름, 경로와 같은 내용은 독 ### 기능 게이트(feature gate) 한글화 방침 -쿠버네티스의 [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 +쿠버네티스의 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 의미하는 용어는 한글화하지 않고 원문 형태를 유지한다. 기능 게이트의 예시는 다음과 같다. @@ -198,7 +198,7 @@ API 오브젝트의 필드 이름, 파일 이름, 경로와 같은 내용은 독 - ... 전체 기능 게이트 목록은 -[여기](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates)를 참고한다. +[여기](/ko/docs/reference/command-line-tools-reference/feature-gates/#feature-gates)를 참고한다. {{% note %}} 단, 해당 원칙에는 예외가 있을 수 있으며, 이 경우에는 가능한 diff --git a/content/ko/docs/contribute/new-content/open-a-pr.md b/content/ko/docs/contribute/new-content/open-a-pr.md index 82c72e2ce8..516c22bfea 100644 --- a/content/ko/docs/contribute/new-content/open-a-pr.md +++ b/content/ko/docs/contribute/new-content/open-a-pr.md @@ -1,6 +1,5 @@ --- title: 풀 리퀘스트 열기 -slug: new-content content_type: concept weight: 10 card: diff --git a/content/ko/docs/contribute/new-content/overview.md b/content/ko/docs/contribute/new-content/overview.md index f86bbb841f..00dc7e0251 100644 --- a/content/ko/docs/contribute/new-content/overview.md +++ b/content/ko/docs/contribute/new-content/overview.md @@ -20,8 +20,12 @@ weight: 5 - 마크다운(Markdown)으로 쿠버네티스 문서를 작성하고 [Hugo](https://gohugo.io/)를 사용하여 쿠버네티스 사이트를 구축한다. - 소스는 [GitHub](https://github.com/kubernetes/website)에 있다. 쿠버네티스 문서는 `/content/ko/docs/` 에서 찾을 수 있다. 일부 참조 문서는 `update-imported-docs/` 디렉터리의 스크립트에서 자동으로 생성된다. - [페이지 템플릿](/docs/contribute/style/page-content-types/)은 Hugo에서 문서 콘텐츠의 프리젠테이션을 제어한다. -- 표준 Hugo 단축코드(shortcode) 이외에도 설명서에서 여러 [사용자 정의 Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 사용하여 콘텐츠 표시를 제어한다. -- 문서 소스는 `/content/` 에서 여러 언어로 제공된다. 각 언어는 [ISO 639-1 표준](https://www.loc.gov/standards/iso639-2/php/code_list.php)에 의해 결정된 2문자 코드가 있는 자체 폴더가 있다. 예를 들어, 한글 문서의 소스는 `/content/ko/docs/` 에 저장된다. +- 표준 Hugo 단축코드(shortcode) 이외에도 설명서에서 여러 + [사용자 정의 Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 사용하여 콘텐츠 표시를 제어한다. +- 문서 소스는 `/content/` 에서 여러 언어로 제공된다. 각 + 언어는 [ISO 639-1 표준](https://www.loc.gov/standards/iso639-2/php/code_list.php)에 + 의해 결정된 2문자 코드가 있는 자체 폴더가 있다. 예를 들어, + 한글 문서의 소스는 `/content/ko/docs/` 에 저장된다. - 여러 언어로 문서화에 기여하거나 새로운 번역을 시작하는 방법에 대한 자세한 내용은 [현지화](/ko/docs/contribute/localization_ko/)를 참고한다. ## 시작하기 전에 {#before-you-begin} diff --git a/content/ko/docs/contribute/participate/_index.md b/content/ko/docs/contribute/participate/_index.md index 610815e65b..f66c7f952b 100644 --- a/content/ko/docs/contribute/participate/_index.md +++ b/content/ko/docs/contribute/participate/_index.md @@ -20,7 +20,9 @@ SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다. 누구나 풀 리퀘스트(PR)를 요청할 수 있고, 누구나 콘텐츠에 대해 이슈를 등록하거나 진행 중인 풀 리퀘스트에 코멘트를 등록할 수 있다. -[멤버](/ko/docs/contribute/participating/roles-and-responsibilities/#멤버), [리뷰어](/ko/docs/contribute/participating/roles-and-responsibilities/#리뷰어), 또는 [승인자](/ko/docs/contribute/participating/roles-and-responsibilities/#승인자)가 될 수 있다. +[멤버](/ko/docs/contribute/participate/roles-and-responsibilities/#멤버), +[리뷰어](/ko/docs/contribute/participate/roles-and-responsibilities/#리뷰어), 또는 +[승인자](/ko/docs/contribute/participate/roles-and-responsibilities/#승인자)가 될 수 있다. 이런 역할은 변경을 승인하고 커밋할 수 있도록 보다 많은 접근 권한과 이에 상응하는 책임이 수반된다. 쿠버네티스 커뮤니티 내에서 멤버십이 운영되는 방식에 대한 보다 많은 정보를 확인하려면 [커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md) @@ -30,8 +32,6 @@ SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다. 문서를 관리하는 책임을 가지는 SIG Docs에서, 이런 체계가 작동하는 특유의 방식에 대한 윤곽을 잡아보겠다. - - ## SIG Docs 의장 @@ -58,7 +58,8 @@ GitHub의 SIG Docs [팀]에는 두 분류가 있다. 그룹의 전원과 의사소통하기 위해서 각각 GitHub 코멘트에서 그룹의 `@name`으로 참조할 수 있다. -가끔은 Prow와 GitHub 팀은 정확히 일치하지 않고 중복된다. 이슈, 풀 리퀘스트를 할당하고, PR 승인을 지원하기 위해서 +가끔은 Prow와 GitHub 팀은 정확히 일치하지 않고 중복된다. +이슈, 풀 리퀘스트를 할당하고, PR 승인을 지원하기 위해서 자동화 시스템이 `OWNERS` 파일의 정보를 활용한다. ### OWNERS 파일과 전문(front-matter) diff --git a/content/ko/docs/contribute/participate/roles-and-responsibilties.md b/content/ko/docs/contribute/participate/roles-and-responsibilties.md index e5dbfb85ff..252d07b332 100644 --- a/content/ko/docs/contribute/participate/roles-and-responsibilties.md +++ b/content/ko/docs/contribute/participate/roles-and-responsibilties.md @@ -6,7 +6,8 @@ weight: 10 -누구나 쿠버네티스에 기여할 수 있다. SIG Docs에 대한 기여가 커짐에 따라, 커뮤니티의 다양한 멤버십을 신청할 수 있다. +누구나 쿠버네티스에 기여할 수 있다. SIG Docs에 대한 기여가 커짐에 따라, +커뮤니티의 다양한 멤버십을 신청할 수 있다. 이러한 역할을 통해 커뮤니티 내에서 더 많은 책임을 질 수 있다. 각 역할마다 많은 시간과 노력이 필요하다. 역할은 다음과 같다. @@ -23,10 +24,13 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D 모든 사람은 다음의 작업을 할 수 있다. -- [`kubernetes/website`](https://github.com/kubernetes/website)를 포함한 모든 [쿠버네티스] 리포지터리에서 이슈를 올린다. +- [`kubernetes/website`](https://github.com/kubernetes/website)를 포함한 모든 + [쿠버네티스](https://github.com/kubernetes/) 리포지터리에서 + 이슈를 올린다. - 풀 리퀘스트에 대해 구속력 없는 피드백을 제공한다. - 현지화에 기여한다. -- [슬랙](http://slack.k8s.io/) 또는 [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선을 제안한다. +- [슬랙](http://slack.k8s.io/) 또는 + [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선을 제안한다. [CLA에 서명](/ko/docs/contribute/new-content/overview/#sign-the-cla) 후에 누구나 다음을 할 수 있다. @@ -37,16 +41,19 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D ## 멤버 -멤버는 `kubernetes/website` 에 여러 개의 풀 리퀘스트를 제출한 사람이다. 멤버는 [쿠버네티스 GitHub 조직](https://github.com/kubernetes)의 회원이다. +멤버는 `kubernetes/website` 에 여러 개의 풀 리퀘스트를 제출한 +사람이다. 멤버는 +[쿠버네티스 GitHub 조직](https://github.com/kubernetes)의 회원이다. 멤버는 다음의 작업을 할 수 있다. - [모든 사람](#모든-사람)에 나열된 모든 것을 한다. - 풀 리퀘스트에 `/lgtm` 코멘트를 사용하여 LGTM(looks good to me) 레이블을 추가한다. - {{< note >}} - `/lgtm` 사용은 자동화를 트리거한다. 만약 구속력 없는 승인을 제공하려면, 단순히 "LGTM" 코멘트를 남기는 것도 좋다! - {{< /note >}} + {{< note >}} + `/lgtm` 사용은 자동화를 트리거한다. 만약 구속력 없는 승인을 제공하려면, 단순히 "LGTM" 코멘트를 남기는 것도 좋다! + {{< /note >}} + - `/hold` 코멘트를 사용하여 풀 리퀘스트에 대한 병합을 차단한다. - `/assign` 코멘트를 사용하여 풀 리퀘스트에 리뷰어를 지정한다. - 풀 리퀘스트에 구속력 없는 리뷰를 제공한다. @@ -55,46 +62,56 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D ### 멤버 되기 -최소 5개의 실질적인 풀 리퀘스트를 제출하고 다른 [요구 사항](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을 충족시킨 후, 다음의 단계를 따른다. +최소 5개의 실질적인 풀 리퀘스트를 제출하고 다른 +[요구 사항](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을 충족시킨 후, 다음의 단계를 따른다. -1. 멤버십을 [후원](/docs/contribute/advanced#sponsor-a-new-contributor)해 줄 두 명의 [리뷰어](#리뷰어) 또는 [승인자](#승인자)를 찾는다. +1. 멤버십을 [후원](/docs/contribute/advanced#sponsor-a-new-contributor)해줄 두 명의 + [리뷰어](#리뷰어) 또는 [승인자](#승인자)를 + 찾는다. - [슬랙의 #sig-docs 채널](https://kubernetes.slack.com) 또는 - [SIG Docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에서 후원을 요청한다. + [슬랙의 #sig-docs 채널](https://kubernetes.slack.com) 또는 + [SIG Docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에서 후원을 요청한다. - {{< note >}} - SIG Docs 멤버 개인에게 직접 email을 보내거나 - 슬랙 다이렉트 메시지를 보내지 않는다. 반드시 지원서를 제출하기 전에 후원을 요청해야 한다. - {{< /note >}} + {{< note >}} + SIG Docs 멤버 개인에게 직접 email을 보내거나 + 슬랙 다이렉트 메시지를 보내지 않는다. 반드시 지원서를 제출하기 전에 후원을 요청해야 한다. + {{< /note >}} -2. [`kubernetes/org`](https://github.com/kubernetes/org/) 리포지터리에 GitHub 이슈를 등록한다. **Organization Membership Request** 이슈 템플릿을 사용한다. +1. [`kubernetes/org`](https://github.com/kubernetes/org/) 리포지터리에 + GitHub 이슈를 등록한다. + **Organization Membership Request** 이슈 템플릿을 사용한다. -3. 후원자에게 GitHub 이슈를 알린다. 다음 중 하나를 수행할 수 있다. - - 이슈에서 후원자의 GitHub 사용자 이름을 코멘트로 추가한다. (`@`) - - 슬랙 또는 이메일을 사용해 이슈 링크를 후원자에게 보낸다. +1. 후원자에게 GitHub 이슈를 알린다. 다음 중 하나를 수행할 수 있다. + - 이슈에서 후원자의 GitHub 사용자 이름을 코멘트로 추가한다. (`@`) + - 슬랙 또는 이메일을 사용해 이슈 링크를 후원자에게 보낸다. - 후원자는 `+1` 투표로 여러분의 요청을 승인할 것이다. 후원자가 요청을 승인하면, 쿠버네티스 GitHub 관리자가 여러분을 멤버로 추가한다. 축하한다! + 후원자는 `+1` 투표로 여러분의 요청을 승인할 것이다. 후원자가 요청을 승인하면, + 쿠버네티스 GitHub 관리자가 여러분을 멤버로 추가한다. + 축하한다! - 만약 멤버십이 수락되지 않으면 피드백을 받게 될 것이다. 피드백의 내용을 해결한 후, 다시 지원하자. + 만약 멤버십이 수락되지 않으면 피드백을 받게 될 것이다. 피드백의 내용을 해결한 후, 다시 지원하자. -4. 여러분의 이메일 계정으로 수신된 쿠버네티스 GitHub 조직으로의 초대를 수락한다. +1. 여러분의 이메일 계정으로 수신된 쿠버네티스 GitHub 조직으로의 초대를 수락한다. - {{< note >}} - GitHub은 초대를 여러분 계정의 기본 이메일 주소로 보낸다. - {{< /note >}} + {{< note >}} + GitHub은 초대를 여러분 계정의 기본 이메일 주소로 보낸다. + {{< /note >}} ## 리뷰어 -리뷰어는 열린 풀 리퀘스트를 리뷰할 책임이 있다. 멤버 피드백과는 달리, 여러분은 리뷰어의 피드백을 반드시 해결해야 한다. 리뷰어는 [@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs) GitHub 팀의 멤버이다. +리뷰어는 열린 풀 리퀘스트를 리뷰할 책임이 있다. 멤버 피드백과는 달리, +여러분은 리뷰어의 피드백을 반드시 해결해야 한다. 리뷰어는 +[@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs) +GitHub 팀의 멤버이다. 리뷰어는 다음의 작업을 수행할 수 있다. - [모든 사람](#모든-사람)과 [멤버](#멤버)에 나열된 모든 것을 수행한다. - 풀 리퀘스트 리뷰와 구속력 있는 피드백을 제공한다. - {{< note >}} - 구속력 없는 피드백을 제공하려면, 코멘트에 "선택 사항: "과 같은 문구를 접두어로 남긴다. - {{< /note >}} + {{< note >}} + 구속력 없는 피드백을 제공하려면, 코멘트에 "선택 사항: "과 같은 문구를 접두어로 남긴다. + {{< /note >}} - 코드에서 사용자 화면 문자열 편집 - 코드 코멘트 개선 @@ -107,37 +124,45 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D [@_github_handle]` 코멘트를 남겨 특정 사람에게 리뷰를 요청할 수 있다. -지정된 리뷰어가 PR에 코멘트를 남기지 않는다면, 다른 리뷰어가 개입할 수 있다. 필요에 따라 기술 리뷰어를 지정할 수도 있다. +지정된 리뷰어가 PR에 코멘트를 남기지 않는다면, 다른 리뷰어가 개입할 수 +있다. 필요에 따라 기술 리뷰어를 지정할 수도 있다. ### `/lgtm` 사용하기 -LGTM은 "Looks good to me"의 약자이며 풀 리퀘스트가 기술적으로 정확하고 병합할 준비가 되었음을 나타낸다. 모든 PR은 리뷰어의 `/lgtm` 코멘트가 필요하고 병합을 위해 승인자의 `/approve` 코멘트가 필요하다. +LGTM은 "Looks good to me"의 약자이며 풀 리퀘스트가 기술적으로 +정확하고 병합할 준비가 되었음을 나타낸다. 모든 PR은 리뷰어의 `/lgtm` 코멘트가 +필요하고 병합을 위해 승인자의 `/approve` 코멘트가 필요하다. 리뷰어의 `/lgtm` 코멘트는 구속력 있고 자동화 시스템이 `lgtm` 레이블을 추가하도록 트리거한다. ### 리뷰어 되기 [요건](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer)을 -충족하면, SIG Docs 리뷰어가 될 수 있다. 다른 SIG의 리뷰어는 SIG Docs의 리뷰어 자격에 반드시 별도로 지원해야 한다. +충족하면, SIG Docs 리뷰어가 될 수 있다. 다른 SIG의 리뷰어는 SIG Docs의 리뷰어 자격에 +반드시 별도로 지원해야 한다. 지원하려면, 다음을 수행한다. 1. `kubernetes/website` 리포지터리 내 -[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) 파일의 섹션에 -여러분의 GitHub 사용자 이름을 추가하는 풀 리퀘스트를 연다. + [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) 파일의 섹션에 + 여러분의 GitHub 사용자 이름을 추가하는 풀 리퀘스트를 연다. {{< note >}} 자신을 추가할 위치가 확실하지 않으면, `sig-docs-ko-reviews` 에 추가한다. {{< /note >}} -2. PR을 하나 이상의 SIG-Docs 승인자(`sig-docs-{language}-owners` 에 나열된 사용자 이름)에게 지정한다. +1. PR을 하나 이상의 SIG-Docs 승인자(`sig-docs-{language}-owners` 에 + 나열된 사용자 이름)에게 지정한다. -승인되면, SIG Docs 리더가 적당한 GitHub 팀에 여러분을 추가한다. 일단 추가되면, [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이 새로운 풀 리퀘스트에서 리뷰어로 여러분을 할당하고 제안한다. +승인되면, SIG Docs 리더가 적당한 GitHub 팀에 여러분을 추가한다. 일단 추가되면, +[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이 +새로운 풀 리퀘스트에서 리뷰어로 여러분을 할당하고 제안한다. ## 승인자 승인자는 병합하기 위해 풀 리퀘스트를 리뷰하고 승인한다. 승인자는 -[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs) GitHub 팀의 멤버이다. +[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs) +GitHub 팀의 멤버이다. 승인자는 다음의 작업을 할 수 있다. @@ -147,22 +172,27 @@ LGTM은 "Looks good to me"의 약자이며 풀 리퀘스트가 기술적으로 - 문서 테스트 개선을 제안한다. - 쿠버네티스 웹사이트 또는 다른 도구 개선을 제안한다. -PR에 이미 `/lgtm` 이 있거나, 승인자도 `/lgtm` 코멘트를 남긴다면, PR은 자동으로 병합된다. SIG Docs 승인자는 추가적인 기술 리뷰가 필요치 않는 변경에 대해서만 `/lgtm` 을 남겨야 한다. +PR에 이미 `/lgtm` 이 있거나, 승인자도 `/lgtm` 코멘트를 남긴다면, +PR은 자동으로 병합된다. SIG Docs 승인자는 추가적인 기술 리뷰가 필요치 않는 변경에 대해서만 +`/lgtm` 을 남겨야 한다. ### 풀 리퀘스트 승인 -승인자와 SIG Docs 리더는 website 리포지터리로 풀 리퀘스트를 병합할 수 있는 유일한 사람들이다. 이것은 특정한 책임이 따른다. +승인자와 SIG Docs 리더는 website 리포지터리로 풀 리퀘스트를 병합할 수 있는 +유일한 사람들이다. 이것은 특정한 책임이 따른다. - 승인자는 PR들을 리포지터리에 병합하는 `/approve` 명령을 사용할 수 있다. - {{< warning >}} - 부주의한 머지로 인해 사이트를 파괴할 수 있으므로, 머지할 때에 그 의미를 확인해야 한다. - {{< /warning >}} + {{< warning >}} + 부주의한 머지로 인해 사이트를 파괴할 수 있으므로, 머지할 때에 그 의미를 확인해야 한다. + {{< /warning >}} -- 제안된 변경이 [컨트리뷰션 가이드 라인](/docs/contribute/style/content-guide/#contributing-content)에 적합한지 확인한다. +- 제안된 변경이 + [컨트리뷰션 가이드 라인](/docs/contribute/style/content-guide/#contributing-content)에 적합한지 확인한다. - 질문이 생기거나 확실하지 않다면 자유롭게 추가 리뷰를 요청한다. + 질문이 생기거나 확실하지 않다면 자유롭게 + 추가 리뷰를 요청한다. - PR을 `/approve` 하기 전에 Netlify 테스트 결과를 검토한다. @@ -170,17 +200,24 @@ PR에 이미 `/lgtm` 이 있거나, 승인자도 `/lgtm` 코멘트를 남긴다 - 승인 전에 PR에 대한 Netlify 프리뷰 페이지를 방문하여, 제대로 보이는지 확인한다. -- 주간 로테이션을 위해 [PR Wrangler 로테이션 스케줄](https://github.com/kubernetes/website/wiki/PR-Wranglers)에 참여한다. SIG Docs는 모든 승인자들이 이 로테이션에 참여할 -것으로 기대한다. 자세한 내용은 [PR 랭글러(PR wrangler)](/ko/docs/contribute/participating/pr-wranglers/)를 -참고한다. +- 주간 로테이션을 위해 + [PR Wrangler 로테이션 스케줄](https://github.com/kubernetes/website/wiki/PR-Wranglers)에 + 참여한다. SIG Docs는 모든 승인자들이 이 로테이션에 참여할 것으로 기대한다. 자세한 내용은 + [PR 랭글러(PR wrangler)](/ko/docs/contribute/participating/pr-wranglers/)를 + 참고한다. ## 승인자 되기 -[요구 사항](https://github.com/kubernetes/community/blob/master/community-membership.md#approver)을 충족하면 SIG Docs 승인자가 될 수 있다. 다른 SIG의 승인자는 SIG Docs의 승인자 자격에 대해 별도로 신청해야 한다. +[요구 사항](https://github.com/kubernetes/community/blob/master/community-membership.md#approver)을 +충족하면 SIG Docs 승인자가 될 수 있다. +다른 SIG의 승인자는 SIG Docs의 승인자 자격에 대해 +별도로 신청해야 한다. 지원하려면 다음을 수행한다. -1. `kubernetes/website` 리포지터리 내 [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) 파일의 섹션에 자신을 추가하는 풀 리퀘스트를 연다. +1. `kubernetes/website` 리포지터리 내 + [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) + 파일의 섹션에 자신을 추가하는 풀 리퀘스트를 연다. {{< note >}} 자신을 추가할 위치가 확실하지 않으면, `sig-docs-ko-owners` 에 추가한다. @@ -188,7 +225,9 @@ PR에 이미 `/lgtm` 이 있거나, 승인자도 `/lgtm` 코멘트를 남긴다 2. PR에 한 명 이상의 현재 SIG Docs 승인자를 지정한다. -승인되면, SIG Docs 리더가 적당한 GitHub 팀에 여러분을 추가한다. 일단 추가되면, [@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이 새로운 풀 리퀘스트에서 승인자로 여러분을 할당하고 제안한다. +승인되면, SIG Docs 리더가 적당한 GitHub 팀에 여러분을 추가한다. 일단 추가되면, +[@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이 +새로운 풀 리퀘스트에서 승인자로 여러분을 할당하고 제안한다. ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/contribute/review/for-approvers.md b/content/ko/docs/contribute/review/for-approvers.md index 9b6c01d739..2e76e101be 100644 --- a/content/ko/docs/contribute/review/for-approvers.md +++ b/content/ko/docs/contribute/review/for-approvers.md @@ -8,7 +8,9 @@ weight: 20 -SIG Docs [리뷰어](/ko/docs/contribute/participating/#리뷰어)와 [승인자](/ko/docs/contribute/participating/#승인자)는 변경 사항을 리뷰할 때 몇 가지 추가 작업을 수행한다. +SIG Docs [리뷰어](/ko/docs/contribute/participate/roles-and-responsibilities/#리뷰어)와 +[승인자](/ko/docs/contribute/participate/roles-and-responsibilities/#승인자)는 변경 사항을 +리뷰할 때 몇 가지 추가 작업을 수행한다. 매주 특정 문서 승인자 역할의 지원자가 풀 리퀘스트를 심사하고 리뷰한다. 이 @@ -19,9 +21,6 @@ SIG Docs [리뷰어](/ko/docs/contribute/participating/#리뷰어)와 [승인자 로테이션 외에도, 봇은 영향을 받는 파일의 소유자를 기반으로 PR에 대한 리뷰어와 승인자를 할당한다. - - - ## PR 리뷰 @@ -201,9 +200,9 @@ SIG Docs가 처리 방법을 문서화할 정도로 다음과 같은 유형의 ```none 이 이슈는 지원 요청과 비슷하지만 문서 관련 이슈와는 관련이 없는 것 같습니다. -[쿠버네티스 슬랙](http://slack.k8s.io/)의 +[쿠버네티스 슬랙](https://slack.k8s.io/)의 `#kubernetes-users` 채널에서 질문을 하시기 바랍니다. 또한, -[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)와 +[Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)와 같은 리소스를 검색하여 유사한 질문에 대한 답변을 얻을 수도 있습니다. diff --git a/content/ko/docs/contribute/review/reviewing-prs.md b/content/ko/docs/contribute/review/reviewing-prs.md index ca3d38a752..f0a164de00 100644 --- a/content/ko/docs/contribute/review/reviewing-prs.md +++ b/content/ko/docs/contribute/review/reviewing-prs.md @@ -16,10 +16,9 @@ weight: 10 리뷰하기 전에, 다음을 수행하는 것이 좋다. - 적합한 코멘트를 남길 수 있도록 [콘텐츠 가이드](/docs/contribute/style/content-guide/)와 -[스타일 가이드](/docs/contribute/style/style-guide/)를 읽는다. -- 쿠버네티스 문서화 커뮤니티의 다양한 [역할과 책임](/ko/docs/contribute/participating/#역할과-책임)을 이해한다. - - + [스타일 가이드](/docs/contribute/style/style-guide/)를 읽는다. +- 쿠버네티스 문서화 커뮤니티의 다양한 + [역할과 책임](/ko/docs/contribute/participating/#역할과-책임)을 이해한다. diff --git a/content/ko/docs/contribute/style/write-new-topic.md b/content/ko/docs/contribute/style/write-new-topic.md index 9bff308df1..7441882615 100644 --- a/content/ko/docs/contribute/style/write-new-topic.md +++ b/content/ko/docs/contribute/style/write-new-topic.md @@ -10,7 +10,7 @@ weight: 20 ## {{% heading "prerequisites" %}} -[기여 시작하기](/docs/contribute/start/)에 설명된 대로 쿠버네티스 +[PR 열기](/ko/docs/contribute/new-content/open-a-pr/)에 설명된 대로 쿠버네티스 문서 저장소의 포크(fork)를 생성하자. diff --git a/content/ko/docs/reference/issues-security/security.md b/content/ko/docs/reference/issues-security/security.md index 986af01cf1..6db604665e 100644 --- a/content/ko/docs/reference/issues-security/security.md +++ b/content/ko/docs/reference/issues-security/security.md @@ -13,7 +13,7 @@ weight: 20 보안 및 주요 API 공지에 대한 이메일을 위해 [kubernetes-security-announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce)) 그룹에 가입하세요. -[이 링크](https://groups.google.com/forum/feed/kubernetes-announce/msgs/rss_v2_0.xml?num=50)를 사용하여 RSS 피드를 구독할 수 있다. +[이 링크](https://groups.google.com/forum/feed/kubernetes-security-announce/msgs/rss_v2_0.xml?num=50)를 사용하여 RSS 피드를 구독할 수 있다. ## 취약점 보고 diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index 42d761ee93..3446c11a06 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -162,6 +162,10 @@ kubectl get pv --sort-by=.spec.capacity.storage kubectl get pods --selector=app=cassandra -o \ jsonpath='{.items[*].metadata.labels.version}' +# 예를 들어 'ca.crt'와 같이 점이 있는 키값을 검색한다 +kubectl get configmap myconfig \ + -o jsonpath='{.data.ca\.crt}' + # 모든 워커 노드 조회 (셀렉터를 사용하여 'node-role.kubernetes.io/master' # 으로 명명된 라벨의 결과를 제외) kubectl get node --selector='!node-role.kubernetes.io/master' diff --git a/content/ko/docs/reference/setup-tools/_index.md b/content/ko/docs/reference/setup-tools/_index.md new file mode 100644 index 0000000000..268a280c50 --- /dev/null +++ b/content/ko/docs/reference/setup-tools/_index.md @@ -0,0 +1,6 @@ +--- +title: 설치 도구 레퍼런스 +weight: 50 +toc-hide: true +--- + diff --git a/content/ko/docs/reference/setup-tools/kubeadm/_index.md b/content/ko/docs/reference/setup-tools/kubeadm/_index.md new file mode 100644 index 0000000000..085b1e1ef9 --- /dev/null +++ b/content/ko/docs/reference/setup-tools/kubeadm/_index.md @@ -0,0 +1,6 @@ +--- +title: "Kubeadm" +weight: 10 +toc-hide: true +--- + diff --git a/content/ko/docs/reference/setup-tools/kubeadm/kubeadm.md b/content/ko/docs/reference/setup-tools/kubeadm/kubeadm.md new file mode 100644 index 0000000000..f011459dd6 --- /dev/null +++ b/content/ko/docs/reference/setup-tools/kubeadm/kubeadm.md @@ -0,0 +1,28 @@ +--- +title: kubeadm 개요 +weight: 10 +card: + name: reference + weight: 40 +--- +Kubeadm은 쿠버네티스 클러스터를 "빠른 경로"로 생성하기 위한 모범 사례인 `kubeadm init`과 `kubeadm join`을 제공하기 위해 구성된 도구이다. + +kubeadm은 최소 기능 클러스터(minimum viable cluster)를 시작하고 실행하는 데 필요한 작업을 수행한다. 설계상, 부트스트랩만 다루며, 머신을 프로비저닝하지는 않는다. 마찬가지로, 쿠버네티스 대시보드, 모니터링 솔루션 및 클라우드 별 애드온과 같은 다양한 기능을 갖춘 애드온을 설치하는 것은 범위에 포함되지 않는다. + +대신, kubeadm 위에 있는 더 높은 수준의 맞춤형 도구가 구축될 것으로 예상되며, 모든 배포의 기초로서 kubeadm을 사용하면 적합한 클러스터를 보다 쉽게 만들 수 있다. + +## 설치하는 방법 + +kubeadm을 설치하려면 [설치 가이드](/docs/setup/production-environment/tools/kubeadm/install-kubeadm)를 참조한다. + +## 다음 내용 + +* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init): 쿠버네티스 컨트롤 플레인 노드를 부트스트랩 함 +* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join): 쿠버네티스 워커 노드를 부트스트랩 후 클러스터에 결합시킴 +* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade): 쿠버네티스 클러스터를 최신 버전으로 업그레이드 +* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config): kubeadm v1.7.x이하의 버전을 사용하여 클러스터를 초기화한 경우, 클러스터를 설정하여 `kubeadm upgrade`하기 위해 사용 +* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token): `kubeadm join`을 위한 토큰 관리 +* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset): `kubeadm init`나 `kubeadm join`를 의한 호스트에 대해서 변경된 사항을 되돌림 +* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version): kubeadm 버전을 출력 +* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha): 커뮤니티의 피드백 수집을 위해서 기능 미리 보기를 제공 + diff --git a/content/ko/docs/setup/best-practices/certificates.md b/content/ko/docs/setup/best-practices/certificates.md index e152e378c5..42b94acf5e 100644 --- a/content/ko/docs/setup/best-practices/certificates.md +++ b/content/ko/docs/setup/best-practices/certificates.md @@ -26,7 +26,7 @@ weight: 40 * API 서버에서 etcd 간의 통신을 위한 클라이언트 인증서 * 컨트롤러 매니저와 API 서버 간의 통신을 위한 클라이언트 인증서/kubeconfig * 스케줄러와 API 서버간 통신을 위한 클라이언트 인증서/kubeconfig -* [front-proxy][proxy]를 위한 클라이언트와 서버 인증서 +* [front-proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)를 위한 클라이언트와 서버 인증서 {{< note >}} `front-proxy` 인증서는 kube-proxy에서 [API 서버 확장](/docs/tasks/extend-kubernetes/setup-extension-api-server/)을 지원할 때만 kube-proxy에서 필요하다. @@ -52,7 +52,7 @@ etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다. |------------------------|---------------------------|----------------------------------| | ca.crt,key | kubernetes-ca | 쿠버네티스 일반 CA | | etcd/ca.crt,key | etcd-ca | 모든 etcd 관련 기능을 위해서 | -| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | [front-end proxy][proxy] 위해서 | +| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | [front-end proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 위해서 | 위의 CA외에도, 서비스 계정 관리를 위한 공개/개인 키 쌍인 `sa.key` 와 `sa.pub` 을 얻는 것이 필요하다. @@ -72,10 +72,10 @@ etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다. | kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | | | front-proxy-client | kubernetes-front-proxy-ca | | client | | -[1]: 클러스터에 접속한 다른 IP 또는 DNS 이름([kubeadm][kubeadm] 이 사용하는 로드 밸런서 안정 IP 또는 DNS 이름, `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`, +[1]: 클러스터에 접속한 다른 IP 또는 DNS 이름([kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) 이 사용하는 로드 밸런서 안정 IP 또는 DNS 이름, `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`, `kubernetes.default.svc.cluster`, `kubernetes.default.svc.cluster.local`) -`kind`는 하나 이상의 [x509 키 사용][usage] 종류를 가진다. +`kind`는 하나 이상의 [x509 키 사용](https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage) 종류를 가진다. | 종류 | 키 사용 | |--------|---------------------------------------------------------------------------------| @@ -97,7 +97,7 @@ kubeadm 사용자만 해당: ### 인증서 파일 경로 -인증서는 권고하는 파일 경로에 존재해야 한다([kubeadm][kubeadm]에서 사용되는 것처럼). 경로는 위치에 관계없이 주어진 파라미터를 사용하여 지정되야 한다. +인증서는 권고하는 파일 경로에 존재해야 한다([kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)에서 사용되는 것처럼). 경로는 위치에 관계없이 주어진 파라미터를 사용하여 지정되야 한다. | 기본 CN | 권고되는 키 파일 경로 | 권고하는 인증서 파일 경로 | 명령어 | 키 파라미터 | 인증서 파라미터 | |------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------| @@ -158,8 +158,3 @@ KUBECONFIG= kubectl config use-context default-system | controller-manager.conf | kube-controller-manager | 반드시 매니페스트를 `manifests/kube-controller-manager.yaml`에 추가해야한다. | | scheduler.conf | kube-scheduler | 반드시 매니페스트를 `manifests/kube-scheduler.yaml`에 추가해야한다. | -[usage]: https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage -[kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/ -[proxy]: /docs/tasks/extend-kubernetes/configure-aggregation-layer/ - - diff --git a/content/ko/docs/setup/release/notes.md b/content/ko/docs/setup/release/notes.md index a0cd9168a1..740d468acc 100644 --- a/content/ko/docs/setup/release/notes.md +++ b/content/ko/docs/setup/release/notes.md @@ -62,12 +62,10 @@ card: ## v1.17.0 이후 체인지로그 -릴리스 노트의 전체 체인지로그는 이제 [https://relnotes.k8s.io][1]에서 사용자 정의 가능한 +릴리스 노트의 전체 체인지로그는 이제 [https://relnotes.k8s.io](https://relnotes.k8s.io/?releaseVersions=1.18.0)에서 사용자 정의 가능한 형식으로 호스팅된다. 확인하고 의견을 보내주기 바란다! -[1]: https://relnotes.k8s.io/?releaseVersions=1.18.0 - ## 새로운 소식 (주요 테마) ### 쿠버네티스 토폴로지 매니저가 베타로 전환 - 정렬! diff --git a/content/ko/docs/tasks/access-application-cluster/access-cluster.md b/content/ko/docs/tasks/access-application-cluster/access-cluster.md index c17458a912..c28c51ea16 100644 --- a/content/ko/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/access-cluster.md @@ -15,12 +15,12 @@ content_type: concept ## 처음이라면 kubectl을 사용하여 액세스 -최초로 쿠버네티스 API에 액세스할 때 우리는 +최초로 쿠버네티스 API에 액세스할 때 우리는 쿠버네티스 CLI인 `kubectl`을 사용하는 것을 추천한다. -클러스터에 액세스하려면 클러스터의 위치정보를 알아야 하고 클러스터에 접속하기 위한 -인증정보를 가져야 한다. 일반적으로 이는 당신이 -[Getting started guide](/ko/docs/setup/)를 다 진행했을 때 자동으로 구성되거나, +클러스터에 액세스하려면 클러스터의 위치정보를 알아야 하고 클러스터에 접속하기 위한 +인증정보를 가져야 한다. 일반적으로 이는 당신이 +[Getting started guide](/ko/docs/setup/)를 다 진행했을 때 자동으로 구성되거나, 다른 사람이 클러스터를 구성하고 당신에게 인증정보와 위치정보를 제공할 수도 있다. kubectl이 인지하는 위치정보와 인증정보는 다음 커맨드로 확인한다. @@ -29,13 +29,13 @@ kubectl이 인지하는 위치정보와 인증정보는 다음 커맨드로 확 kubectl config view ``` -많은 [예제들](/ko/docs/reference/kubectl/cheatsheet/)에서 kubectl을 사용하는 것을 소개하고 있으며 +많은 [예제들](/ko/docs/reference/kubectl/cheatsheet/)에서 kubectl을 사용하는 것을 소개하고 있으며 완전한 문서는 [kubectl manual](/docs/user-guide/kubectl-overview)에서 찾아볼 수 있다. ## REST API에 직접 액세스 -kubectl은 apiserver의 위치 파악과 인증을 처리한다. -만약 당신이 curl, wget 또는 웹브라우저와 같은 http 클라이언트로 +kubectl은 apiserver의 위치 파악과 인증을 처리한다. +만약 당신이 curl, wget 또는 웹브라우저와 같은 http 클라이언트로 REST API에 직접 액세스하려고 한다면 위치 파악과 인증을 하는 몇 가지 방법이 존재한다. - kubectl을 proxy 모드로 실행. @@ -51,8 +51,8 @@ REST API에 직접 액세스하려고 한다면 위치 파악과 인증을 하 ### kubectl proxy 사용 -다음 커맨드는 kubectl을 reverse proxy처럼 동작하는 모드를 실행한다. 이는 -apiserver의 위치지정과 인증을 처리한다. +다음 커맨드는 kubectl을 reverse proxy처럼 동작하는 모드를 실행한다. 이는 +apiserver의 위치지정과 인증을 처리한다. 다음과 같이 실행한다. ```shell @@ -61,7 +61,7 @@ kubectl proxy --port=8080 상세 내용은 [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands/#proxy)를 참조한다 -이후에 당신은 curl, wget, 웹브라우저로 다음과 같이 API를 탐색할 수 있다. localhost는 +이후에 당신은 curl, wget, 웹브라우저로 다음과 같이 API를 탐색할 수 있다. localhost는 IPv6 주소 [::1]로도 대체할 수 있다. ```shell @@ -142,22 +142,22 @@ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure } ``` -위 예제에서는 `--insecure` flag를 사용했다. 이는 MITM 공격을 받을 수 있는 상태로 -두는 것이다. kubectl로 클러스터에 접속할 때 저장된 root 인증서와 클라이언트 인증서들을 +위 예제에서는 `--insecure` flag를 사용했다. 이는 MITM 공격을 받을 수 있는 상태로 +두는 것이다. kubectl로 클러스터에 접속할 때 저장된 root 인증서와 클라이언트 인증서들을 서버 접속에 사용한다. -(이들은 `~/.kube` 디렉터리에 설치된다.) -일반적으로 self-signed 인증서가 클러스터 인증서로 사용되므로 당신의 http 클라이언트가 +(이들은 `~/.kube` 디렉터리에 설치된다.) +일반적으로 self-signed 인증서가 클러스터 인증서로 사용되므로 당신의 http 클라이언트가 root 인증서를 사용하려면 특수한 설정을 필요로 할 것이다. -localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터들에서는 apiserver가 인증을 -요구하지 않지만 이는 표준이 아니다. +localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터들에서는 apiserver가 인증을 +요구하지 않지만 이는 표준이 아니다. [Configuring Access to the API](/docs/reference/access-authn-authz/controlling-access/) -는 클러스터 관리자가 이를 어떻게 구성할 수 있는지를 설명한다. +는 클러스터 관리자가 이를 어떻게 구성할 수 있는지를 설명한다. 이 방식들은 미래의 고가용성 지원과 충돌될 수 있다. ## API에 프로그래밍 방식으로 액세스 -쿠버네티스는 공식적으로 [Go](#go-클라이언트)와 [Python](#python-클라이언트) +쿠버네티스는 공식적으로 [Go](#go-클라이언트)와 [Python](#python-클라이언트) 클라이언트 라이브러리를 지원한다. ### Go 클라이언트 @@ -165,7 +165,7 @@ localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터 * 라이브러리를 취득하려면 `go get k8s.io/client-go@kubernetes-` 커맨드를 실행한다. [INSTALL.md](https://github.com/kubernetes/client-go/blob/master/INSTALL.md#for-the-casual-user)에서 상세한 설치 방법을 알 수 있다. [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go#compatibility-matrix)에서 어떤 버젼이 지원되는지 확인할 수 있다. * client-go 클라이언트 위에 애플리케이션을 작성하자. client-go는 자체적으로 API 오브젝트를 정의하므로 필요하다면 main 레포지터리보다는 client-go에서 API 정의들을 import하기를 바란다. 정확하게 `import "k8s.io/client-go/kubernetes"`로 import하는 것을 예로 들 수 있다. -Go 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다. +Go 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다. [예제](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)를 참고한다. 만약 애플리케이션이 클러스터 내에 파드로 배포되었다면 [다음 장](#파드에서-api-액세스)을 참조하기를 바란다. @@ -174,7 +174,7 @@ Go 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동 Python 클라이언트를 사용하려면 `pip install kubernetes` 커맨드를 실행한다. 설치 옵션에 대한 상세 사항은 [Python Client Library page](https://github.com/kubernetes-client/python)를 참조한다. -Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다. +Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다. [예제](https://github.com/kubernetes-client/python/tree/master/examples)를 참조한다. ### 다른 언어 @@ -184,44 +184,44 @@ Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 ## 파드에서 API 액세스 -파드에서 API를 접속한다면 apiserver의 +파드에서 API를 접속한다면 apiserver의 위치지정과 인증은 다소 다르다. -파드 내에서 apiserver의 위치를 지정하는데 추천하는 방식은 -`kubernetes.default.svc` DNS 네임을 사용하는 것이다. +파드 내에서 apiserver의 위치를 지정하는데 추천하는 방식은 +`kubernetes.default.svc` DNS 네임을 사용하는 것이다. 이 DNS 네임은 apiserver로 라우팅되는 서비스 IP로 resolve된다. -apiserver 인증에 추천되는 방식은 -[서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/) -인증정보를 사용하는 것이다. kube-system에 의해 파드는 서비스 어카운트와 연계되며 -해당 서비스 어카운트의 인증정보(토큰)은 파드 내 각 컨테이너의 파일시스템 트리의 +apiserver 인증에 추천되는 방식은 +[서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/) +인증정보를 사용하는 것이다. kube-system에 의해 파드는 서비스 어카운트와 연계되며 +해당 서비스 어카운트의 인증정보(토큰)은 파드 내 각 컨테이너의 파일시스템 트리의 `/var/run/secrets/kubernetes.io/serviceaccount/token`에 위치한다. -사용 가능한 경우, 인증서 번들은 각 컨테이너 내 파일시스템 트리의 -`/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`에 위치하며 +사용 가능한 경우, 인증서 번들은 각 컨테이너 내 파일시스템 트리의 +`/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`에 위치하며 apiserver의 인증서 제공을 검증하는데 사용되어야 한다. -마지막으로 네임스페이스 한정의 API 조작에 사용되는 기본 네임스페이스는 각 컨테이터 내의 +마지막으로 네임스페이스 한정의 API 조작에 사용되는 기본 네임스페이스는 각 컨테이터 내의 `/var/run/secrets/kubernetes.io/serviceaccount/namespace` 파일로 존재한다. 파드 내에서 API에 접근하는데 권장되는 방식은 다음과 같다. - - 파드의 sidecar 컨테이너 내에서 `kubectl proxy`를 실행하거나, - 컨테이너 내부에서 백그라운드 프로세스로 실행한다. - 이는 쿠버네티스 API를 파드의 localhost 인터페이스로 proxy하여 + - 파드의 sidecar 컨테이너 내에서 `kubectl proxy`를 실행하거나, + 컨테이너 내부에서 백그라운드 프로세스로 실행한다. + 이는 쿠버네티스 API를 파드의 localhost 인터페이스로 proxy하여 해당 파드의 컨테이너 내에 다른 프로세스가 API에 접속할 수 있게 해준다. - - Go 클라이언트 라이브러리를 이용하여 `rest.InClusterConfig()`와 `kubernetes.NewForConfig()` 함수들을 사용하도록 클라이언트를 만든다. + - Go 클라이언트 라이브러리를 이용하여 `rest.InClusterConfig()`와 `kubernetes.NewForConfig()` 함수들을 사용하도록 클라이언트를 만든다. 이는 apiserver의 위치지정과 인증을 처리한다. [예제](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go) 각각의 사례에서 apiserver와의 보안 통신에 파드의 인증정보가 사용된다. ## 클러스터에서 실행되는 서비스로 액세스 -이전 장은 쿠버네티스 API server 접속에 대한 내용을 다루었다. 이번 장은 -쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. 쿠버네티스에서 -[노드들](/ko/docs/concepts/architecture/nodes/), [파드들](/ko/docs/concepts/workloads/pods/pod/), [서비스들](/docs/user-guide/services)은 -모두 자신의 IP들을 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는 -클러스터 상의 노드 IP들, 파드 IP들, 서비스 IP들로 라우팅되지 않아서 접근을 +이전 장은 쿠버네티스 API server 접속에 대한 내용을 다루었다. 이번 장은 +쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. 쿠버네티스에서 +[노드들](/ko/docs/concepts/architecture/nodes/), [파드들](/ko/docs/concepts/workloads/pods/pod/), [서비스들](/docs/user-guide/services)은 +모두 자신의 IP들을 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는 +클러스터 상의 노드 IP들, 파드 IP들, 서비스 IP들로 라우팅되지 않아서 접근을 할 수 없을 것이다. ### 통신을 위한 방식들 @@ -229,33 +229,33 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다. 클러스터 외부에서 노드들, 파드들, 서비스들에 접속하는 데는 몇 가지 선택지들이 있다. - 공인 IP를 통해 서비스에 액세스. - - 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의 - 서비스를 사용한다. [서비스](/docs/user-guide/services)와 + - 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의 + 서비스를 사용한다. [서비스](/docs/user-guide/services)와 [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참조한다. - - 당신의 클러스터 환경에 따라 회사 네트워크에만 서비스를 노출하거나 - 인터넷으로 노출할 수 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다. + - 당신의 클러스터 환경에 따라 회사 네트워크에만 서비스를 노출하거나 + 인터넷으로 노출할 수 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다. 해당 서비스는 자체적으로 인증을 수행하는가? - - 파드들은 서비스 뒤에 위치시킨다. 레플리카들의 집합에서 특정 파드 하나에 debugging 같은 목적으로 접근하려면 + - 파드들은 서비스 뒤에 위치시킨다. 레플리카들의 집합에서 특정 파드 하나에 debugging 같은 목적으로 접근하려면 해당 파드에 고유의 레이블을 붙이고 셀렉터에 해당 레이블을 선택한 신규 서비스를 생성한다. - - 대부분의 경우에는 애플리케이션 개발자가 노드 IP를 통해 직접 노드에 + - 대부분의 경우에는 애플리케이션 개발자가 노드 IP를 통해 직접 노드에 액세스할 필요는 없다. - Proxy Verb를 사용하여 서비스, 노드, 파드에 액세스. - - 원격 서비스에 액세스하기에 앞서 apiserver의 인증과 인가를 받아야 한다. - 서비스가 인터넷에 노출하기에 보안이 충분하지 않거나 노드 IP 상의 port에 + - 원격 서비스에 액세스하기에 앞서 apiserver의 인증과 인가를 받아야 한다. + 서비스가 인터넷에 노출하기에 보안이 충분하지 않거나 노드 IP 상의 port에 액세스를 취득하려고 하거나 debugging을 하려면 이를 사용한다. - 어떤 web 애플리케이션에서는 proxy가 문제를 일으킬 수 있다. - HTTP/HTTPS에서만 동작한다. - [여기](#수작업으로-apiserver-proxy-url들을-구축)에서 설명하고 있다. - 클러스터 내 노드 또는 파드에서 액세스. - - 파드를 Running시킨 다음 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 해당 파드의 셸로 접속한다. + - 파드를 Running시킨 다음 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 해당 파드의 셸로 접속한다. 해당 셸에서 다른 노드들, 파드들, 서비스들에 연결한다. - - 어떤 클러스터는 클러스터 내의 노드에 ssh 접속을 허용하기도 한다. 이런 클러스터에서는 - 클러스터 서비스에 액세스도 가능하다. 이는 비표준 방식으로 특정 클러스터에서는 동작하지만 + - 어떤 클러스터는 클러스터 내의 노드에 ssh 접속을 허용하기도 한다. 이런 클러스터에서는 + 클러스터 서비스에 액세스도 가능하다. 이는 비표준 방식으로 특정 클러스터에서는 동작하지만 다른 클러스터에서는 동작하지 않을 수 있다. 브라우저와 다른 도구들이 설치되지 않았거나 설치되었을 수 있다. 클러스터 DNS가 동작하지 않을 수도 있다. ### 빌트인 서비스들의 발견 -일반적으로 kube-system에 의해 클러스터 상에서 start되는 몇 가지 서비스들이 존재한다. +일반적으로 kube-system에 의해 클러스터 상에서 start되는 몇 가지 서비스들이 존재한다. `kubectl cluster-info` 커맨드로 이 서비스들의 리스트를 볼 수 있다. ```shell @@ -273,15 +273,15 @@ grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/servic heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy ``` -이는 각 서비스에 액세스하기 위한 proxy-verb URL을 보여준다. -예를 들어 위 클러스터는 클러스터 수준의 logging(Elasticsearch 사용)이 활성화되었으므로 적절한 인증을 통과하여 -`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`로 액세스할 수 있다. 예를 들어 kubectl proxy로 +이는 각 서비스에 액세스하기 위한 proxy-verb URL을 보여준다. +예를 들어 위 클러스터는 클러스터 수준의 logging(Elasticsearch 사용)이 활성화되었으므로 적절한 인증을 통과하여 +`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`로 액세스할 수 있다. 예를 들어 kubectl proxy로 `http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`를 통해 logging에 액세스할 수도 있다. -(인증을 통과하는 방법이나 kubectl proxy를 사용하는 것은 [쿠버네티스 API를 사용해서 클러스터에 접근하기](/docs/tasks/administer-cluster/access-cluster-api/)을 참조한다.) +(인증을 통과하는 방법이나 kubectl proxy를 사용하는 것은 [쿠버네티스 API를 사용해서 클러스터에 접근하기](/ko/docs/tasks/administer-cluster/access-cluster-api/)을 참조한다.) #### 수작업으로 apiserver proxy URL을 구축 -위에서 언급한 것처럼 서비스의 proxy URL을 검색하는데 `kubectl cluster-info` 커맨드를 사용할 수 있다. 서비스 endpoint, 접미사, 매개변수를 포함하는 proxy URL을 생성하려면 단순하게 해당 서비스에 +위에서 언급한 것처럼 서비스의 proxy URL을 검색하는데 `kubectl cluster-info` 커맨드를 사용할 수 있다. 서비스 endpoint, 접미사, 매개변수를 포함하는 proxy URL을 생성하려면 단순하게 해당 서비스에 `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy` 형식의 proxy URL을 덧붙인다. 당신이 port에 이름을 지정하지 않았다면 URL에 *port_name* 을 지정할 필요는 없다. @@ -300,7 +300,7 @@ URL의 네임 부분에 지원되는 양식은 다음과 같다. * Elasticsearch 서비스 endpoint `_search?q=user:kimchy`에 액세스하려면 `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`를 사용할 수 있다. * Elasticsearch 클러스터 상태 정보 `_cluster/health?pretty=true`에 액세스하려면 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`를 사용할 수 있다. - + ```json { "cluster_name" : "kubernetes_logging", @@ -320,9 +320,9 @@ URL의 네임 부분에 지원되는 양식은 다음과 같다. 브라우저의 주소창에 apiserver proxy url을 넣을 수도 있다. 하지만 - - 웹브라우저는 일반적으로 토큰을 전달할 수 없으므로 basic (password) auth를 사용해야 할 것이다. basic auth를 수용할 수 있도록 apiserver를 구성할 수 있지만, + - 웹브라우저는 일반적으로 토큰을 전달할 수 없으므로 basic (password) auth를 사용해야 할 것이다. basic auth를 수용할 수 있도록 apiserver를 구성할 수 있지만, 당신의 클러스터가 basic auth를 수용할 수 있도록 구성되어 있지 않을 수도 있다. - - 몇몇 web app은 동작하지 않을 수도 있다. 특히 proxy path prefix를 인식하지 않는 방식으로 url을 + - 몇몇 web app은 동작하지 않을 수도 있다. 특히 proxy path prefix를 인식하지 않는 방식으로 url을 구성하는 client side javascript를 가진 web app은 동작하지 않을 수 있다. ## 요청 redirect @@ -373,7 +373,5 @@ redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) proxy - UDP/TCP 만 사용한다 - cloud provider마다 구현된 내용이 상이하다 -일반적으로 쿠버네티스 사용자들은 처음 두 타입이 아닌 다른 방식은 고려할 필요가 없지만 클러스터 관리자는 +일반적으로 쿠버네티스 사용자들은 처음 두 타입이 아닌 다른 방식은 고려할 필요가 없지만 클러스터 관리자는 나머지 타입을 적절하게 구성해줘야 한다. - - diff --git a/content/ko/docs/tasks/access-application-cluster/configure-dns-cluster.md b/content/ko/docs/tasks/access-application-cluster/configure-dns-cluster.md index eaace61131..5dde43a4f9 100644 --- a/content/ko/docs/tasks/access-application-cluster/configure-dns-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/configure-dns-cluster.md @@ -8,6 +8,4 @@ content_type: concept 쿠버네티스는 지원하는 모든 환경에서 기본으로 활성화된 DNS 클러스터 애드온을 제공한다. 쿠버네티스 1.11과 이후 버전에서는, CoreDNS가 권장되고 기본적으로 kubeadm과 함께 설치 된다. -쿠버네티스 클러스터의 CoreDNS 설정에 대한 더 많은 정보는, [DNS 서비스 사용자화 하기](/docs/tasks/administer-cluster/dns-custom-nameservers/)을 본다. kube-dns와 함께 쿠버네티스 DNS를 사용하는 방법을 보여주는 예시는 [쿠버네티스 DNS 샘플 플러그인](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)을 본다. - - +쿠버네티스 클러스터의 CoreDNS 설정에 대한 더 많은 정보는, [DNS 서비스 사용자화 하기](/ko/docs/tasks/administer-cluster/dns-custom-nameservers/)을 본다. kube-dns와 함께 쿠버네티스 DNS를 사용하는 방법을 보여주는 예시는 [쿠버네티스 DNS 샘플 플러그인](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)을 본다. diff --git a/content/ko/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/ko/docs/tasks/access-application-cluster/service-access-application-cluster.md new file mode 100644 index 0000000000..7565152bf0 --- /dev/null +++ b/content/ko/docs/tasks/access-application-cluster/service-access-application-cluster.md @@ -0,0 +1,158 @@ +--- +title: 클러스터 내 애플리케이션에 접근하기 위해 서비스 사용하기 +content_type: tutorial +weight: 60 +--- + + + +이 문서는 외부 클라이언트가 클러스터에서 실행 중인 애플리케이션에 접근하기 +위해 사용하는 쿠버네티스 서비스 오브젝트를 생성하는 방법을 설명한다. 서비스는 +실행 중인 두 개의 인스턴스를 갖는 애플리케이션에 대한 로드 밸런싱을 제공한다. + + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + +## {{% heading "objectives" %}} + + +* Hello World 애플리케이션 인스턴스 두 개를 실행한다. +* 노드 포트를 노출하는 서비스 오브젝트를 생성한다. +* 실행 중인 애플리케이션에 접근하기 위해 서비스 오브젝트를 사용한다. + + + + + + +## 두 개의 파드에서 실행 중인 애플리케이션에 대한 서비스 생성하기 + +다음은 애플리케이션 디플로이먼트(Deployment) 설정 파일이다. + +{{< codenew file="service/access/hello-application.yaml" >}} + +1. 클러스터 내 Hello World 애플리케이션을 실행하자. + 위 파일을 사용하여 애플리케이션 디플로이먼트를 생성하자. + ```shell + kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml + ``` + 앞의 명령은 + [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/) + 오브젝트와 연관된 + [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/) + 오브젝트를 생성한다. 레플리카셋은 두 개의 + [파드](/ko/docs/concepts/workloads/pods/pod/)를 갖고, + 각각은 Hello World 애플리케이션을 실행한다. + +1. 디플로이먼트에 대한 정보를 보여준다. + ```shell + kubectl get deployments hello-world + kubectl describe deployments hello-world + ``` + +1. 레플리카셋 오브젝트에 대한 정보를 보여준다. + ```shell + kubectl get replicasets + kubectl describe replicasets + ``` + +1. 디플로이먼트를 노출하는 서비스 오브젝트를 생성한다. + ```shell + kubectl expose deployment hello-world --type=NodePort --name=example-service + ``` + +1. 서비스에 대한 정보를 보여준다. + ```shell + kubectl describe services example-service + ``` + 결과는 아래와 같다. + ```shell + Name: example-service + Namespace: default + Labels: run=load-balancer-example + Annotations: + Selector: run=load-balancer-example + Type: NodePort + IP: 10.32.0.16 + Port: 8080/TCP + TargetPort: 8080/TCP + NodePort: 31496/TCP + Endpoints: 10.200.1.4:8080,10.200.2.5:8080 + Session Affinity: None + Events: + ``` + 서비스의 노드포트(NodePort) 값을 메모하자. 예를 들어, + 앞선 결과에서, 노드포트 값은 31496이다. + +1. Hello World 애플리케이션이 실행 중인 파드를 나열한다. + ```shell + kubectl get pods --selector="run=load-balancer-example" --output=wide + ``` + 결과는 아래와 같다. + ```shell + NAME READY STATUS ... IP NODE + hello-world-2895499144-bsbk5 1/1 Running ... 10.200.1.4 worker1 + hello-world-2895499144-m1pwt 1/1 Running ... 10.200.2.5 worker2 + ``` +1. Hello World 파드가 실행 중인 노드들 중 하나의 노드에 대해 공용 + IP 주소를 얻자. 이 주소를 얻는 방법은 어떻게 클러스터를 설치했는지에 + 따라 다르다. 예를 들어, Minikube를 사용하면, `kubectl cluster-info`를 + 실행하여 노드 주소를 알 수 있다. Google Compute Engine 인스턴스를 + 사용하면, `gcloud compute instances list` 명령어를 + 사용하여 노드들의 공용 주소를 알 수 + 있다. + +1. 선택한 노드에서 노드 포트에 대해 TCP 통신을 허용하도록 방화벽 규칙을 + 생성하자. 예를 들어, 서비스의 노드포트 값이 31568인 경우, + 31568 포트로 TCP 통신을 허용하도록 방화벽 규칙을 생성하자. 다른 + 클라우드 공급자는 방화벽 규칙을 설정하는 다른 방법을 제공한다. + +1. Hello World 애플리케이션 접근을 위해 노드 주소와 노드 포트를 사용하자. + ```shell + curl http://: + ``` + ``는 노드의 공용 IP 주소이고, + ``는 서비스의 노드포트 값이다. + 성공적인 요청에 대한 응답은 hello 메시지이다. + ```shell + Hello Kubernetes! + ``` + +## 서비스 설정 파일 사용하기 + +`kubectl expose`를 사용하는 대신, +[서비스 설정 파일](/ko/docs/concepts/services-networking/service/)을 사용해 +서비스를 생성할 수 있다. + + + + +## {{% heading "cleanup" %}} + + +서비스를 삭제하기 위해 다음 명령어를 입력하자. + + kubectl delete services example-service + +디플로이먼트, 레플리카셋, Hello World 애플리케이션이 실행 중인 파드를 +삭제하기 위해 다음 명령어를 입력하자. + + kubectl delete deployment hello-world + + + + +## {{% heading "whatsnext" %}} + + +[서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에 +대해 더 알아본다. + diff --git a/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md b/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md index 5af4ea94b0..0e5a87bc82 100644 --- a/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md +++ b/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md @@ -258,4 +258,4 @@ kube-dns를 CoreDNS로 교체하여 적용하는 방법에 대한 상세 정보 ## {{% heading "whatsnext" %}} -- [DNS 변환 디버깅하기](/docs/tasks/debug-application-cluster/dns-debugging-resolution/) 읽기 +- [DNS 변환 디버깅하기](/docs/tasks/administer-cluster/dns-debugging-resolution/) 읽기 diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index 5e9c61d3e6..ac3ac3f695 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -10,15 +10,11 @@ weight: 10 [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)으로 생성된 클라이언트 인증서는 1년 후에 만료된다. 이 페이지는 kubeadm으로 인증서 갱신을 관리하는 방법을 설명한다. - - ## {{% heading "prerequisites" %}} [쿠버네티스의 PKI 인증서와 요구 조건](/ko/docs/setup/best-practices/certificates/)에 익숙해야 한다. - - ## 사용자 정의 인증서 사용 {#custom-certificates} @@ -153,33 +149,29 @@ HA 클러스터를 실행 중인 경우, 모든 컨트롤 플레인 노드에서 ### 서명자 설정 쿠버네티스 인증 기관(Certificate Authority)은 기본적으로 작동하지 않는다. -[cert-manager][cert-manager-issuer] 와 같은 외부 서명자를 설정하거나, 빌트인 서명자를 사용할 수 있다. +[cert-manager](https://docs.cert-manager.io/en/latest/tasks/issuers/setup-ca.html)와 같은 외부 서명자를 설정하거나, 빌트인 서명자를 사용할 수 있다. -빌트인 서명자는 [`kube-controller-manager`][kcm] 의 일부이다. +빌트인 서명자는 [`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/)의 일부이다. 빌트인 서명자를 활성화하려면, `--cluster-signing-cert-file` 와 `--cluster-signing-key-file` 플래그를 전달해야 한다. -새 클러스터를 생성하는 경우, kubeadm [구성 파일][config]을 사용할 수 있다. +새 클러스터를 생성하는 경우, kubeadm [구성 파일](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)을 사용할 수 있다. - ```yaml - apiVersion: kubeadm.k8s.io/v1beta2 - kind: ClusterConfiguration - controllerManager: - extraArgs: - cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt - cluster-signing-key-file: /etc/kubernetes/pki/ca.key - ``` - -[cert-manager-issuer]: https://docs.cert-manager.io/en/latest/tasks/issuers/setup-ca.html -[kcm]: /docs/reference/command-line-tools-reference/kube-controller-manager/ -[config]: https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2 +```yaml +apiVersion: kubeadm.k8s.io/v1beta2 +kind: ClusterConfiguration +controllerManager: + extraArgs: + cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt + cluster-signing-key-file: /etc/kubernetes/pki/ca.key +``` ### 인증서 서명 요청(CSR) 생성 `kubeadm alpha certs renew --use-api` 로 쿠버네티스 인증서 API에 대한 인증서 서명 요청을 만들 수 있다. -[cert-manager][cert-manager] 와 같은 외부 서명자를 설정하면, 인증서 서명 요청(CSR)이 자동으로 승인된다. -그렇지 않으면, [`kubectl certificate`][certs] 명령을 사용하여 인증서를 수동으로 승인해야 한다. +[cert-manager](https://github.com/jetstack/cert-manager)와 같은 외부 서명자를 설정하면, 인증서 서명 요청(CSR)이 자동으로 승인된다. +그렇지 않으면, [`kubectl certificate`](/ko/docs/setup/best-practices/certificates/) 명령을 사용하여 인증서를 수동으로 승인해야 한다. 다음의 kubeadm 명령은 승인할 인증서 이름을 출력한 다음, 승인이 발생하기를 차단하고 기다린다. ```shell @@ -195,7 +187,7 @@ sudo kubeadm alpha certs renew apiserver --use-api & 외부 서명자를 설정하면, 인증서 서명 요청(CSR)이 자동으로 승인된다. -그렇지 않으면, [`kubectl certificate`][certs] 명령을 사용하여 인증서를 수동으로 승인해야 한다. 예를 들어 다음과 같다. +그렇지 않으면, [`kubectl certificate`](/ko/docs/setup/best-practices/certificates/) 명령을 사용하여 인증서를 수동으로 승인해야 한다. 예를 들어 다음과 같다. ```shell kubectl certificate approve kubeadm-cert-kube-apiserver-ld526 @@ -227,20 +219,14 @@ CSR과 함께 제공되는 개인 키가 모두 출력된다. `kubeadm init` 과 마찬가지로 출력 디렉터리를 `--csr-dir` 플래그로 지정할 수 있다. CSR에는 인증서 이름, 도메인 및 IP가 포함되지만, 용도를 지정하지는 않는다. -인증서를 발행할 때 [올바른 인증서 용도][cert-table]를 지정하는 것은 CA의 책임이다. +인증서를 발행할 때 [올바른 인증서 용도](/ko/docs/setup/best-practices/certificates/#모든-인증서)를 지정하는 것은 CA의 책임이다. -* `openssl` 의 경우 [`openssl ca` command][openssl-ca] 명령으로 수행한다. -* `cfssl` 의 경우 [설정 파일에 용도][cfssl-usages]를 지정한다. +* `openssl` 의 경우 + [`openssl ca` 명령](https://superuser.com/questions/738612/openssl-ca-keyusage-extension)으로 수행한다. +* `cfssl` 의 경우 [설정 파일에 용도](https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170)를 지정한다. 선호하는 방법으로 인증서에 서명한 후, 인증서와 개인 키를 PKI 디렉터리(기본적으로 `/etc/kubernetes/pki`)에 복사해야 한다. -[cert-manager]: https://github.com/jetstack/cert-manager -[openssl-ca]: https://superuser.com/questions/738612/openssl-ca-keyusage-extension -[cfssl-usages]: https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170 -[certs]: /ko/docs/setup/best-practices/certificates/ -[cert-cas]: /ko/docs/setup/best-practices/certificates/#단일-루트-ca -[cert-table]: /ko/docs/setup/best-practices/certificates/#모든-인증서 - ## 인증 기관(CA) 순환(rotation) {#certificate-authority-rotation} Kubeadm은 CA 인증서의 순환이나 교체 기능을 기본적으로 지원하지 않는다. diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md index 44f57b3b58..bee3c94069 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md @@ -49,5 +49,4 @@ Kubeadm을 이용해서 15분 이내에 지역 단일 호스트 캘리코 클러 ## {{% heading "whatsnext" %}} 클러스터가 동작하면, 쿠버네티스 네트워크 폴리시(NetworkPolicy)를 시도하기 위해 -[네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. - +[네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md index fed25bc169..f41b5cd716 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md @@ -102,9 +102,6 @@ cilium-6rxbd 1/1 Running 0 1m 클러스터가 동작하면, 실리움으로 쿠버네티스 네트워크 폴리시를 시도하기 위해 -[네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. +[네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. 재미있게 즐기고, 질문이 있다면 [실리움 슬랙 채널](https://cilium.herokuapp.com/)을 이용하여 연락한다. - - - diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md index 1fbc5e4455..4c16cb7385 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md @@ -22,7 +22,4 @@ weight: 30 ## {{% heading "whatsnext" %}} -큐브 라우터 애드온을 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. - - - +큐브 라우터 애드온을 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md index 70f0ec1aae..d59cdd3e15 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md @@ -38,4 +38,4 @@ Kubeadm을 위한 [컨테이너화된 설치 안내서](https://github.com/roman ## {{% heading "whatsnext" %}} -로마나를 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. +로마나를 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md index 484a8d58cd..3aea719c56 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md @@ -52,8 +52,4 @@ weave-net-pmw8w 2/2 Running 0 9d ## {{% heading "whatsnext" %}} -위브넷 애드온을 설치하고 나서, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. 질문이 있으면 [슬랙 #weave-community 이나 Weave 유저그룹](https://github.com/weaveworks/weave#getting-help)에 연락한다. - - - - +위브넷 애드온을 설치하고 나서, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/ko/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. 질문이 있으면 [슬랙 #weave-community 이나 Weave 유저그룹](https://github.com/weaveworks/weave#getting-help)에 연락한다. diff --git a/content/ko/docs/tasks/configure-pod-container/configure-pod-initialization.md b/content/ko/docs/tasks/configure-pod-container/configure-pod-initialization.md index d973b42f99..ee7d5a9f82 100644 --- a/content/ko/docs/tasks/configure-pod-container/configure-pod-initialization.md +++ b/content/ko/docs/tasks/configure-pod-container/configure-pod-initialization.md @@ -88,4 +88,4 @@ init-demo 파드 내 실행 중인 nginx 컨테이너의 셸을 실행한다. 대해 배우기. * [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)에 대해 배우기. * [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 배우기. -* [초기화 컨테이너 디버깅](/docs/tasks/debug-application-cluster/debug-init-containers/)에 대해 배우기. +* [초기화 컨테이너 디버깅](/ko/docs/tasks/debug-application-cluster/debug-init-containers/)에 대해 배우기. diff --git a/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md b/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md index edb0edb08f..515b9c2cdd 100644 --- a/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md +++ b/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md @@ -115,4 +115,4 @@ glossary_tooltip text="kubelet" term_id="kubelet" >}} 및 {{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}} (`--feature-gates=HugePageStorageMediumSize=true`)의 `HugePageStorageMediumSize` [기능 -게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 활성화할 수 있다. +게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 활성화할 수 있다. diff --git a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md index 03cfdf88c6..c7d57d8633 100644 --- a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md @@ -119,7 +119,7 @@ web-1 1/1 Running 0 18s ``` 참고로 `web-1` 파드는 `web-0` 파드가 _Running_ ([파드의 단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계-phase) 참고) -및 _Ready_ ([파드의 조건](/docs/concepts/workloads/pods/pod-lifecycle/#파드의-조건-condition)에서 `type` 참고) 상태가 되기 전에 시작하지 않음을 주의하자. +및 _Ready_ ([파드의 조건](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-조건-condition)에서 `type` 참고) 상태가 되기 전에 시작하지 않음을 주의하자. ## 스테이트풀셋 안에 파드 diff --git a/content/ko/examples/service/access/hello-application.yaml b/content/ko/examples/service/access/hello-application.yaml new file mode 100644 index 0000000000..1cf41313c5 --- /dev/null +++ b/content/ko/examples/service/access/hello-application.yaml @@ -0,0 +1,20 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: hello-world +spec: + selector: + matchLabels: + run: load-balancer-example + replicas: 2 + template: + metadata: + labels: + run: load-balancer-example + spec: + containers: + - name: hello-world + image: gcr.io/google-samples/node-hello:1.0 + ports: + - containerPort: 8080 + protocol: TCP